Horizontal Level of Abstraction

Abstraction is often paraphrased as the omission of individual component and the transfer to something more general and simple. Depth is considered to be the horizontal level of abstraction in which we practically look into a car. The idiom To miss the forest for the trees can be used as an appropriate description of the challenges for the development of vehicle functions. 

When describing the behavior of a vehicle there are dependencies that can be broken down all the way into the individual lines of a software code, the resistor or joints of components on the printed circuit board. If those dependencies are not recognized we have to ask what other elements are needed. 

Consequently, in vehicle and aircraft engineering we speak about the airplane level, the system level and the components level. If this were a developed requirement for the stmcmre the development of vehicle functions would most definitely be a lot easier. Ofiicially, these levels are not mentioned in ISO 26262 but the norm helps to better understand when would be a good time to take such levels in considerations (Fig. 3.7). 

Here we can see that the environment for a vehicle and an airplane has an essential influence on the development of a system. The degrees of variance for the vehicle alone are a lot less for the steering system than for an airplane. However, even for a vehicle the degrees of variance are very different. A motorcycle wiU fall easily while a car won t, unless we refer to an elk test. This comparison shows that certain events have a design related probability of occurrence. On the system level, which shows the interaction of the components, also mechanic, electronic and software components are applied but based on different requirements and environmental parameters they wiU lead to extremely different system designs. 

If we consider the components level we will find a similar simation for electric hardware and software. In this case the differences will mainly show in the architecture. 

---

How and in what order these elements should be integrated rather depends mosdy on organizational interfaces or availability of the elements than the technical aspects. Integration should be accompanied by continues verifications and adequate tests to confirm the fulfilment of the given requirements for the relevant horizontal level of abstraction. 

This analysis is based on flie function net of the VDA-FMEA. In animated SYSML-tools the function net of the VDA-FMEA could be even used more effectively. The relevant functions need to be decomposed and allocated to stiucture elements in the stiucture net of the VDA-FMEA. The stiucture net could be any decomposition of the architecture based on technical, functional or logical blocks. The functional decomposition should be performed only on a defined horizontal level of abstraction. 

For these analyses we consider the pure functions without any allocation to elements. Maybe this analysis could be performed before the previous described analysis, but if it could be done independently no systematic errors lead to common failme. An already verified function in a higher horizontal level of abstraction have to be completely derived to a lower level (e.g. from vehicle level to system level or from higher system level to lower or component levels). In a VDA-FMEA we could again test through the function net, whether the functions in the lower level (e.g. components in SW or HW) are completely displayed at the system level (if you could show all signal chains of the system level, completeness of the specification... 

As a consequence, three horizontal system levels have to be developed, in which elements are integrated hierarchically up until the vehicle integration. The following two objectives are directed to methods how to integrate in the dedicated horizontal level of abstraction. 

The MDE methodology in MetaMORP(h)OSY is enacted by means of two main components Observer and Translators Observers are used in order to evaluate properties both on (abstract) models and (real) nmning systems. Translators implement both vertical and horizontal transformation [30]. Horizontal transformations translate models into other (formal) ones at the same level of abstraction they are used in order to create analyzable models from descriptive ones (for example real time properties are verified on design models translating UML models into timed automata). Vertical transformation are usually used in MetaMORP(h)OSY in order to translate abstract models into finer grained models. This kind of transformation usually usually is not fully automated. Requirements tracing in vertical transformations requires the creation of proper Observers able to verify abstract requirements on finer grained models. 

Intent specifications are organized along three dimensions intent abstraction, part-whole abstraction, and refinement. Hiese dimensions constitute the problem space in which the human navigates. Part-whole abstraction (along the horizontal dimension) and refinement (within each level) allow users to change then-focus of attention to more or less detailed views within each level or model. The vertical dimension specifies the level of intent at which the problem is being considered. 

Abstract. Safety critical systems are used to reduce the probabihty of failure that could cause danger to person, equipment or environment. The increasing level of vertical and horizontal integration increases the security risks in automation. Since the risk of security attacks can not be treated as negligible anymore, there is a need to investigate possible security attacks on safety critical communication. 

As we have previously seen in the architectural views and abstraction levels of architecture, horizontal and vertical interfaces and also other differing views are stmcmring criteria. This applies particularly to the development of requirements. If we determine functional, technical and logical elements we also need to describe and specify them. If such elements are combined in order to function together as desired and create an intended function, they have to show compatihle interfaces that are specified sufficiently. ISO 26262 [1] covers the specification of interfaces but does not clearly illustrate the respective requirements. However, the correlation between the work results such as requirement specifications in part 10, are shown based on information flows. In this case only the general abstraction levels system and components are covered and also the differing views on how a system can be described are not covered. 

F. 4.42 2 level of horizontal abstraction including potential error causes... 

Interfaces of elements are always given by the nature of electronic systems. Those interfaces must be specified in order to assure, that systems could realize the intended functions. A mere software component only exists because it is defined like that. The low level driver (e.g. MCAL microcontroller abstraction layer), which read the information from the microcontroller hardware and provide the data interface to further software components, these software elements built the hardware-software-interface (HSI). Mere electronic parts could not be considered without their interfaces to mechanical elements, such as PCB, connectors etc. This means, no matter at what horizontal abstraction level electronic are considered, there will always be mechanical intersections. Even the bonding (connection between the silicon and the pin) in a microcontroller or ASIC primarily depends on the production process, which creates the mechanical connection. The example of the hardware software interface shows how deep we have to go into the details of the components in order to ensure sufficient coverage and sufficient unique level of specification. 

System model The focuses of a system model are the interfaces to the components. A system model can describe the different horizontal levels, this is why the levels at which the models is abstracted, should be defined clearly (Fig. 6.4). 

In the Formal Graph in the case study abstract, two circular paths formed by the system constitutive and space properties can be seen. They represent the relations D6.2 and D6.3 and each loop contains the relation of mutual influence between the two poles distributed spatially that constitute the two magnetic impulses. The loop in dotted lines features the influence of pole 2 on pole 1 and the loop in solid line features the other influence. The horizontal npper paths express the influences between state variables (global level) and the slanted lower paths express the reciprocal influences... 

Also for basic software or in AutoSar abstraction levels are addressed but in this case we don t mean horizontal abstraction levels but functional (perspectival) abstraction levels (e.g. hardware abstraction or microcontroller abstraction layer (MCAL)). Nevertheless, the interface between application software and microcontroller still play an important role in the definition of the abstraction level. In early revisions of ISO 26262 the hardware software interface (HSl) was implemented in part 5 (Product development at the hardware level) and 6 (Product development at the software level) and only after the CD version of ISO 26262 it moved into part 4 (Product development at the system level). What is special about this is that the microcontroller as a hardware element, similar to the electronics housing, predetermines essential design characteristics for the software. In order for these two components to interact properly, those characteristics and their potential flaws as well as the functions and their potential failure functions need to be considered. This obviously goes for all component interfaces. In the case of HSl we find a lot of relevant interface parameters. This means, that it is not only about the correct functions of the so-called low-level drivers, which provide information on microcontrollers to the software, the operating system, peripheral (DMA, I/O, bus etc.), internal communication, logic unit, memory or function libraries, which are provided by the computer, but also the systematic protection of potential failure or malftmction at this interface. 

The architecture should also display the structure of requirements. With the help of the horizontal abstraction levels described the upper and lower interfaces are predetermined for the details, which the architecture should illustrate. By determining the logical and technical elements, further interfaces within the horizontal abstraction level are displayed. In a system, logical and technical elements are defined, which have the task of carrying or also implementing the required functions. The logical or technical elements have to be clearly specified so that a correct behavior can be expected for safety relevant systems (Fig. 3.12). 

These questions build the foundation for the verification of the functional safety concept. In each individual level, in which requirements can be verified, a similar approach can be used for the requirement verification. The figure above shows that if functions or the elements, which those functions should realize, do not have common interfaces, the number of interfaces will explode exponentially. If also a situation related failure analysis had to be made on the basis of such heterogenic positive descriptions and perhaps correlations had to be described through several horizontal abstraction levels, completeness, transparently, comprehensibility, consistence and correctness would no longer be given. Such an amount of interfaces would not be analyzable and therefore no longer controllable. 

Safety Goals are defined on the vehicle level (ITEM) according to ISO 26262. In this context there is no guideline to how complex or at which horizontal abstraction level is described. A safety goal can be formulated as follows Avoid an inadmissible pressure build-up of the brake pressure on one wheel , Avoid an inadmissible torque build-up on one wheel or Avoid a defective blockade of one wheel . Basically, aU three formulations could be correct. However, if we use such differing description levels for a vehicle system or multiple vehicle systems that have to be integrated into a vehicle, it could start to become confusing, since the interfaces will not match one another (compare also to Fig. 4.9). 

Generally, we also speak of deductive and inductive analyses, whereby the general induction infers from the details to the commonalities and the deduction aims to explain the details from the commonalities through certain premises or general conclusions. In order to take those terms in the context of a technical system analysis, we have to get back to speaking about a horizontal abstraction level in the system stmcture. 

In a FMEA (compare Fig. 4.37) fault can be assigned to the cause of failure, an error to a failure type and failure to failure effect. If we distinguish the causative level, failure level and failure effect level also as different horizontal abstraction levels, we easily fulfill the requirements of ISO 26262, part 9, Chap. 8. In this part it is required that the safety analyses are oriented at the architecture, just like the FMEAs. 

This definition of dependability is also called the Kolmogorov s zero-one law. It is one of the laws of large numbers, since according to the definition only two cases exist, either there are dependencies or there aren t. Since we already learned that a complete independency could rarely be achieved, ISO 26262 speaks of a sufficient independency. Failures of common causes or failure dependencies between functions, which can affect through different mechanisms, are often no longer analyz-able with the classical methods. In this case we can often only rely on experience. For functional dependencies we can systematically analyze a lot of things firom the functional chains and their derivation in the different horizontal abstraction levels. A barrier, independent if it is a functional or technical barrier, or whatever technology it is, could be only assessed for its sufficiency or effectiveness, in the specific context and for possible failure effects (Fig. 5.59). 

Are all safety mechanisms completely described by technical elements (Complete description of safety mechanisms regarding a horizontal abstraction level including all technical interfaces)... 

In this context, the verification is seen as the completion of a higher level activity and the lower level activities usually begins with a requirement analysis. ISO 26262 considers also tests especially in the lower horizontal abstraction levels, particularly during component design as verifications. However, methodical, the method for the correct derivation from a higher level would need to be a validation. What is important though is that this verification regarding correctness, completeness and... 

In the deductive safety analysis all possible variances and consequently the entire specifiable space should be analyzed. In the inductive safety analysis the specified elements are considered at the respective horizontal abstraction level and the possible error influences or impacts are evaluated. As a result a systematic falsification of the specified space could lead to completeness regarding possible error behavior. Influences and combinations, which the developer cannot imagine or not systematically evaluate, are also not verifiable. The characteristics of the product should be ensured at the end of such horizontal development activities after their verification. 

V. For higher voltage than 60 V DC or 25 V AC, legal requirements have to be considered due to touch protection. However, for the description of the requirements for electronics ISO 26262 still chose a V-model as reference model. The question for the horizontal abstraction level is now Where does the electronic development start and where does the system development end ... 

---