System Engineering for Development of Requirements and Architecture

The ascending branch of the V-model has not always been intensively and systematically implemented in the development process of vehicle components. Crucial indicators for the automobile industry are methods such as statistical design of experiments (DoE) or an intensive validation. The descending area of the V-model has often been neglected. Writing specifications is not strength of automobile manufacturers. 

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. 

For the software development one more level is illustrated (Fig. 4.2). It shows an architecture level and a level, which is assigned to the software unit or the design of the software unit. 

In the final version the arrows and the keys are changed according to Fig. 4.3. The essential input for the definition of the vehicle system (ITEM) is the functional concept. Since ISO 26262 does not cover the hazards, which result from a correct functioning system, the functional concept itself is required to completely describe the free from danger of intended function and its structure. This won t be possible at an early stage of the product development. Therefore, we are forced to see all activities as continuous iterations for which the obtained insights have to be proven 

Furthermore, each system element should show as low as possible error modes (ideally in a degraded safe state). It is a challenge to define system components in a way that they show a low amount of possible error modes. However, the acceptable system degradations have to be clearly specified. This fact will be used in a higher ASIL as the basis for architecture development. Without barriers, which limit the number of possible error modes, such a system is no longer analyzable and the variance and the possible error propagations will no longer be controllable. 

---