In the automotive domain, the basic development process follows the V-model consisting of a design and implementation part and a verification and validation part (cf. [RB08]).
3.1. Running Example: Lane Change Assistant Requirements Analysis System Design Verification Test & Simulation
Validation Field Test
Implementation Safety Analysis
Figure 3.2.: Activities in the development, verification and validation of the lane change assistant.
The activities for the development of the lane change assistant follow this development process (cf. Fig. 3.2). Sections 3.2 to 3.7 describe each development activity in more detail.
As shown in Fig. 3.2, the first activity in the development process of the lane change assistant is the requirements analysis. in the requirement analysis, requirements from relevant stakeholders are elected for the system specification of the lane change assistant (cf. Definition 3.2) . The specification is the first documented definition of the lane change assistant’s functionality and restrictions. The majority of requirements for the lane change assistant emerge from the development of the superior highway pilot. In the system design (cf. Fig. 3.2), the lane change assistant is designed based on the requirements in the system specification by defining an architecture of functional components. Each component addresses one or more basic functions required by the system specification of the lane change assistant. In the course of the development, the system specification is further detailed for its subsystems. A technical concept defines each component, the algorithms and communication techniques used for realizing the components’ functionality. The lane change assistant is divided into the processing of sen- sor data for the scene representation, the situation assessment of the scene representation and the behavior planning for lane changes. Additional to the functional architecture, a hardware architecture is defined incorporation a network of ECUs for the execution of the functional components as well as sensor and actuator hardware components for the perception and interaction with the vehicle’s environment.
The system specification and system architecture allow analyzing the proposed system under safety aspects. The safety analysis as third activity in the development process (cf. Fig. 3.2) evaluates the concept of the lane change assistant from the system design in different operation modes. A operation mode encompasses the states of software functions, hardware components, and the environment of the system — the real world. Critical operational modes are identified in which the behavior of the lane change assistant
impose a potential safety risks for its passengers, other vehicles, and their passengers. For each critical operation mode, safety measures are defined (cf. Definition 3.1). The safety measures are intended to mitigate the safety risks of the lane change assistant in the operation mode. These measures are incorporated into the system development as additional requirements. These safety requirements are added to the system specification resulting in a revision of the system design and its components. The correct and effective implementation of all identified safety requirements, including their measures, have to be addressed in the verification and validation. In the automotive domain, the safety analysis commonly proceeds following the ISO 26262 [Int09d].
Definition 3.1 (Safety Measure). “The activity or technical solution to avoid or
control systematic failures and to detect random hardware failures or control random hardware failures, or mitigate their harmful effects” [Int09a].
Following the revision of requirements and system design, the lane change assistant is implemented. In the implementation activity (cf. Fig. 3.2), the functionality and safety measures of each functional component are primarily realized in software and in minor cases solely as hardware. For the lane change assistant, the atomic functional components — the lowest components in the hierarchy of the functional system architecture — are refined as software-components and implemented as C/C++ code. The code is written manually or generated from models, e.g., signal flow diagrams using modeling tools e.g., Matlab/Simulink (cf. [Bis96]) or Ascet (cf. [Lef+97]). The correct implementation of each atomic functional component is addressed in unit tests. Each implementation artifact of a atomic component — e.g., its classes and functions — is independently stimulated by the test inputs of corresponding test cases in order to reveal bugs and faults (cf. Section 2.2). The response of the implementation artifact — its output data — is compared with the envisaged response of the executed test case. Additional hardware required for the functional components, e.g., sensors or ECUs, are realized and tested simultaneously.
Following the system architecture, atomic implementation artifacts are integrated into compositional components. Compositional components might be further integrated with other atomic or compositional components. This way larger parts of the system are realized. The integration of functional components may lead to the emergence of more complex functionality. For example, the combination of sensor preprocessing and modeling enables the system to generate an internal representation of the current vehicle environment.
In the verification activity (cf. Fig. 3.2), the functional correctness of composite com- ponents is verified in integration tests with regard to the requirements of the system specification. Integration tests presume the correct implementation of each subordinate component — as it is verified in unit tests for atomic functional components — and therefore focus on the communication and interaction between subordinate components and emerging functionalities. For the lane change assistant, simulations are used for integration testing — from MIL, SIL, HIL to VIL (cf. Section 2.2.2). These simulation methods are differentiated based on the SUT — e.g., if it is a model, implementation, or