System Integration and Verification

After the implementation and unit testing of all software and hardware components, the development of the lane change assistant proceeds with the integration of these components to larger system parts until the complete lane change assistant is integrated. The integration reverses the decomposition of the lane change assistant in the system design and implementation (cf. Sections 3.3 and 3.5). All compositions of components introduce new functionalities which have not yet been verified by the unit test of the software components (cf. Section 3.5.2). Additional verification is required for composite components in order to guarantee the correctness and safety of the complete lane change assistant. The following section describes the integration and verification of the software for the lane change assistant.

3.6.1. Software Integration

Following the functional architecture (cf. Section 3.3.1), implemented (atomic) software components are integrated with each other to form composite components which are further integrated with other components — composite and atomic software components — to form even larger composite components. This integration continues until the lane change assistant and all its functional components, like the environment perception, situation

assessment, and behavior planning are implemented (cf. Fig. 3.3). Every composite component introduces novel functionalities which emerge from the intercommunication of

its internal components. None of the inherent components has exhibited these emerging functionalities in the isolation of the unit tests (cf. Section 3.5.1.3). For example, the

3.6. System Integration and Verification

detection and classification of environment objects are only possible because individual components for the object detection and object classification are integrated with the vehicle sensors.

Safety measures defined in the safety analysis (cf. Section 3.4) can be implemented as dedicated software components independently from the original functions of the lane change assistant. In the integration, the components for the safety measures and the component for the original function are integrated into composite components. The composites exhibit the original functionality as long as no faults are present. Safety measure will only intervene with the original functionality if an identified fault from the safety analysis is present.

3.6.2. Software Integration Testing

The emerging behavior of composite components has not yet been verified because the interaction between components has been excluded from unit tests (cf. Section 3.5.1.3). All composites have to be verified in integration tests in order to ensure the correctness and safety of emerging functionalities. Similar to unit test (cf. Section 3.5.1.3), sets of test cases verify the behavior of composites components. Test cases define the test input for composite components and the expected behavior for these components based on specifications and requirements.

Integration tests of composite components include the verification of safety measures

which have been defined for these components in the safety analysis (cf. Section 3.4). The verification of safety measures might require the definition of additional specialized test cases. These tests do not have to verify the correct functionalities of original functions but to verify the detection and mitigation of faults by safety measures. Integration tests of safety measures may incorporate fault injection methods in order to stimulate the emergence of faults (cf. [Ise11]).

For the lane change assistant, the ADTF filter as implementation of software components are integrated in an ADTF filter graph and verified by the simulation framework Virtual Test Drive (VTD) (cf. [Neu14]) in closed-loop simulations (cf. Section 2.2). The framework VTD simulates the environment of the vehicle — the virtual world — with its scenery and dynamic objects, e.g., vehicle and pedestrians. The simulation interacts with the ADTF implementation of composite components by their external interfaces. All remaining components of the lane change assistant, e.g., sensors and actuators, have to be simulated by the simulation framework.

The simulation framework VTD allows the verification of the lane change assistant for a set of defined test cases. Test cases represent concrete parametrization of a test scenarios. A test scenario models the environment by defining the scenery — the static objects of the environment, e.g., road, markings, and sign, as well as the behavior of dynamic objects, e.g., maneuvers of vehicles and paths of pedestrians (cf. Section 7.2.2). A test case will be passed if the engineer or an oracle evaluate the behavior of the lane change assistant in the corresponding simulations as compliant with the intended behavior defined by the test case.

The execution of a test case in the simulation framework results in a sequence of environmental situations. These situations are used as input for the lane change assistant. Objects from situations are either directly fed into the scene modeling as input for the lane change assistant or they are processed by sensor models to incorporate the uncertainty of real sensors into the input for the lane change assistant (cf. Fig. 3.3). The outputs of the lane change assistant are fed back into the simulations in order to update the state of the simulated world and generate new inputs for the lane change assistant in the next processing cycle (cf. Section 2.2). The changes of objects in the simulated world can occur autonomously or as a direct reaction to the output of the lane change assistant. The overall correctness and safety of the lane change assistant depend on the correctness and safety of its software and hardware. Therefore, the integration of hardware and software has to be verified. The hardware platform must not alter the verified behavior and functionalities of the software. The integration of software and hardware as E/E system and the verification of the system integration are described in the following section.

3.6.3. Integration of the Hardware / Software System

Car manufacturers obtain hardware components from multiple supplier and integrate these components for the E/E architecture of production vehicles (cf. Section 3.5.2.1). The integration includes the connection of ECUs and DCUs to communication systems, e.g., CAN or FlexRay buses, and the power supply of the vehicles.

After the integration and deployment of the E/E architecture, software components are deployed on the ECUs and DCUs. The software deployment includes the definition of timing and scheduling of software components on ECUs and DCUs and of messages on communication buses. For each communication bus, a communication matrices defines the content of all messages of the specific bus and their routing between connected ECUs. The scheduling for each ECU defines the execution order and execution duration of deployed software components and their functions.

For the hardware platform of the prototype vehicles, the two customer computers have been installed in the trunks. The computers are connected and the gateway via an Ethernet bus (cf. Fig. 3.16). The gateway connects the computers to the additionally installed sensors and existing communication buses of the prototype vehicles.

The software of the highway pilot is deployed and executed on the two customer computers as ADTF filters in two distributed ADTF instances. The environment perception of the lane change assistant is deployed on the first computer while the situation assessment,

decision making, and other ADAS functions are installed on the second computer (cf.

Fig. 3.16). The communication between the distributed ADTF instances and with the gateway is implemented by predefined messages in ADTF and organized by the Ethernet controllers and OS services of the two computers without any predefined message scheduling. The gateway connects the lane change assistant with original sensors and actuators of the prototype vehicles by transforming messages of the original communication buses to and from ADTF messages of the Ethernet network.

3.6. System Integration and Verification

3.6.4. Verification of the Hardware / Software System

The hardware platform has not been systematically verified because the hardware used in the simulations of the lane change assistant and the prototype vehicle is similar. Knowledge about the hardware setup obtained in simulations of the system verification can be directly transferred to the setup of the prototype vehicles. Nevertheless, the original hardware components of the production vehicles have been verified in the development processes of these vehicles. The only unverified part of this setup is the connection of the gateway to the original vehicle hardware and additional installed sensors. The connectivity of the gateway has been randomly checked at its deployment but has not been systematically verified by a defined set of test cases.

The integration of hardware components, e.g., ECUs, sensor, actuators, and communica- tion buses, is generally verified in HIL tests for production vehicles (cf. Section 2.2.2.4). Hardware components or subsystems are integrated into simulations of their real environ- ments. All connect hardware components are modeled and simulated by the simulation frameworks. For a test of, e.g., an exhaust system, the complete exhaust system is integrated and verified in HIL tests. The control of the exhaust system, as well as the real world, are simulated. The stimuli for each HIL test are defined in test cases along with the expected behavior of the verified hardware components resp. subsystem as acceptance criteria in these tests. The resilience and robustness of hardware components and subsystems can be evaluated in endurance runs (cf. Section 3.5.2.2).

The integration of software and hardware is also verified in HIL tests (cf. Section 2.2.2.4). Therefore, software components are deployed on the corresponding ECUs, sensors, and actuators. Even though the software components have been verified in isolation and as composites (cf. Section 3.6.2), the integration of software and hardware components can reveal faults which have not yet been encountered. These faults are primarily timing and scheduling faults due to the limited resources of ECUs and communication buses. Test cases from software integration tests can be reused to verified the integration of software and hardware (cf. Section 3.6.2). The software-hardware-integration has to exhibit the identical functionality as in MIL and MIL tests of the software (cf. Section 3.6.2). Tests of fully integrated systems, e.g., the complete highway pilot, are denoted as system

tests. These system tests have to be performed with the highway pilot installed in a

prototype vehicle because the lane change assistant and other ADAS of the highway pilot require the perception of the vehicle’s real environment. Engineers verify the system on test tracks and public roads and evaluate if the system meets all requirements in the specification of the highway pilot. The complexity of the real world makes it challenging to define comprehensive sets of realistic test cases. Test cases would have to be costly build on test tracks with real vehicles and dummy objects. The system tests of the lane change assistant has been solely performed as unsystematic test drives on public roads. The verification in test drives correlates with the validation of the lane change assistant. The trade-off between verification and validation impacts the efficiency and costs of the system development (cf. [TMJ12; Zha16]). The validation of the lane change assistant is described in the following section.