Table 3.12.: Table for situation classification by autonomous vehicle systems. System Classification Critical Non-Critical Realit y Critical True Positive False Positive Non-Critical False Positive True Negative
The final impact of the safety analysis is on the safety assessment. In the safety
assessment, independent assessors have to inspect and evaluate the safety argumentation
by car manufacturers for their systems. The impact of the safety analysis on the safety assessment for the lane change assistant is described in the following.
3.4.4.4.3. Safety Assessment
For the lane change assistant, the safety assessment has not yet been done because the system is still in development. A safety assessment is commonly performed at near the end of the system development when most of the verification and validation activities have provided sufficient safety-related results. The safety standard ISO 26262 expects a safety assessment for systems and their parts with a classification of ASIL B or higher. The safety assessment must justify that the achieved level of functional safety for these systems is sufficient for the operation of these systems in the real world (cf. [Bir+13]). The safety assessment evaluates all activities and their results in the development of systems and results in the definition of safety cases. Safety cases document the complete and sufficient consideration of safety requirements throughout all safety-related development activities for the system. This safety argumentation supports the certification process of the systems by national authorities.
Definition 3.14 (Safety Assessment). In a safety assessment, independent assessors
inspect and evaluate the argumentation for the safety of systems (cf. [Bir+13]).
The following sections give a more detailed description of the implementation, verification, and validation of the lane change assistant.
3.5. Implementation
After the addition of requirements from the safety analysis (cf. Section 3.4) and the revision of the system design, the revised functionality of the lane change assistant and additional safety measures are implemented (cf. Fig. 3.2). Furthermore, hardware components have to be selected and implemented. Finally, all implementation artifacts are verified. Following the system design, the implementation of the lane change assistant
separates itself in the implementation of the functional architecture and the implementa- tion of the technical architecture. Both implementations are described in the following section in more detail.
3.5.1. Implementation of the Functional Architecture
The implementation of the functional architecture focuses on the implementation of the specified functionality for the lane change assistant. Functional components are commonly implemented as software components and are implemented only in exceptional case as hardware components, e.g., in field programmable gate arrays (FPGAs). The behavior emerging from software components are validated by engineers using rapid prototyping and verified in software unit tests.
3.5.1.1. Implementation of Software Components
For the implementation of the lane change assistant, the atomic functional components of the functional architecture (cf. Section 3.3.1) are refined and implemented as software components. The refinement also applies to the specification of atomic functional components; each requirement of a functional component is refined and allocated to the different software components, which implement the complete or a part of the required functionality. As a result, an architecture of software components is defined for each atomic functional component.
Each software componento f the software architecture is implemented in C/C++ source code and consists of several classes with multiple C/C++ functions. Each function imple- ments an algorithm as part of the overall functionality of the functional component. The source code of software components is either manually written by engineers or generated from models, e.g., signal flow graphs (cf. [FPE14]) or statecharts (cf. [Har87]). In the Automotive Domain, commercial tools, e.g., ASCET (cf. [Lef+97]) and MatLab/Simulink (cf. [Bis96]), are used for the model-based implementation of software components. The code generators of these commercial tools allow generating the necessary C/C++ source code from signal flow graphs resp. statecharts. For the deployment of software implemen- tations on ECUs of the technical hardware architecture, the source code of all software components for a system is compiled and linked with necessary libraries as executables (cf. [Ste14]).
The functionality of the lane change assistant is implemented in ADTF. ADTF is a commercial framework for the development and execution of ADAS functions (cf. [Sch07]). The implementation of ADAS in ADTF follows the pipes-and-filters pattern (cf. [Mon+97]). (Sub) functions which are defined in the architecture of the lane change assistant (cf. Fig. 3.18) are implemented as filters. A filter in ADTF consists of one ore more C/C++ classes that implemented the functionality of corresponding component and the necessary framework related elements, e.g., ports. In a filter graph, all filters for the lane change assistant are connected and with the input and outputs filters for sensors and actuators. At runtime, ADTF provides itself as a runtime environment that manages the control and data flow between filters in the filter graph.
3.5. Implementation
3.5.1.2. Rapid Prototyping
This implementation of the software for the lane change assistant also includes rapid prototyping. Rapid prototyping allows engineers to validate and adapt their algorithms at early stages of the implementation. Algorithms are deployed as source code or models on special rapid prototyping hardware, e.g., the MicroAutoBox3. The prototyping hardware
is then either deployed in simulations or prototype vehicles. Simulations are the cost and time efficient rapid prototyping environment, while prototype vehicles offer a more realistic validation in the real world. As rapid prototyping is employed from the early stages of the implementation, not all components and functions of the lane change assistant might already be implemented. Therefore, prototype systems offer to simulate the behavior of missing system parts by corresponding models (cf. Section 2.2).
For the lane change assistant, the software implementation in ADTF can be used for rapid prototyping identically in simulations and prototype vehicles. Changes to the implementation are not necessary because ADTF already manages the control and data flow within the lane changes assistant, with other vehicle systems, and with simulation frameworks. The prototype vehicle in the case study was equipped with customer electronic components in order to allow rapid prototyping with ADTF (cf. Section 3.3.2). Nevertheless, rapid prototyping does not address the verification or validation of the lane change assistant regarding its safety assessment. The verification of lane change assistant, commence with unit tests for individual software components. Software unit testing is described in the next section in more detail.
3.5.1.3. Software Unit Tests
A common method for the verification of implementation artifacts in the automotive domain is testing (cf. Section 2.2. Other occasionally used methods include, e.g., static code analysis and code reviews (cf. [Lig09]). In unit tests, each software component of the lane change assistant is verified in isolation — independent from other related and connected software components. Unit tests will evaluate if the implemented behavior of classes, functions, and algorithms are consistent with the specification and requirements of the software components. All software components, which interact with the software component under test, are replaced by mock objects (cf. [TH02]) or completely omitted from the tests in order to avoid any side effects on the artifact under test. Mock objects model the external behavior of the mocked implementation artifact. The substitution of related and connect components ensures a consistent interaction for the artifact under
test with its environment for reproducible tests.
The classes and functions of each software component are verified for a set of test cases. The test cases are derived from the component’s specification and requirements. A test case consists of the input data for the artifact under test, the response of mock objects in the communication with the artifact, and the expected response (output) of the artifact. All test cases for a artifact under test are combined in a test suite. In unit tests, artifacts
3MicroAutoBox: https://www.dspace.com/de/gmb/home/products/hw/micautob/microautobox2.cfm
under test are triggered by the input data of the test cases, and a test oracle evaluates the response of the artifacts (cf. [Lig09]). Artifact responses have to match the expected result defined by the test cases. Metrics, e.g., statement coverage or decision coverage (cf. [Lig09]), quantify the coverage of artifact’s source code by its test suite. All necessary activities and responsibilities for the unit testing of software components are documented in a test plan. This plan includes the definition of the test cases, the setup of the test environment, the execution of the tests, and the evaluation of test results (cf. [Lig09]). For the lane change assistant, the unit tests of ADTF filter implementations utilize special test filters or the C-unit testing framework4. The test filters trigger the filter under test
via its input ports with manually defined input data. The output of the filter under test is evaluated in comparison to predefined expected results for the test case by the test filter. Test filter and the filter under test are integrated into one filter graph isolated from other ADTF filters of the lane change assistant. In this configuration, the filter behavior including the correct implementation of interfaces to the ADTF runtime environment is verified. C-Unit tests do not verify the ADTF filter, but the implementation of algorithms in term of classes and C/C++ functions. For each C/C++ function, a set of test cases is defined. Each test case defines the input values for the function under test and the expected response by the function as assertions. In the execution of c-unit test suites, the input values stimulate the function under test, and the assertions assess the function’s outputs. Mock objects replace function called within the function under tests in order to enable testing in isolation and avoiding side effects.
Beside the functional architecture also the technical architecture has to be implemented. Car manufacturers do not implement hardware components themselves (cf. Section 3.3.2) but commonly acquire the components from various suppliers. The implementation of the technical architecture for the lane change assistant is described in the following.
3.5.2. Implementation of the Technical Architecture
Besides the functional architecture also the technical architecture has to be implemented. However, hardware components are not constructed and implemented by car manufac- turers but are acquired from multiple vendors. These vendors also verify the resilience and robustness of these hardware components. Car manufactures only integrate the third-party hardware components into their execution platform and deploy the execution platform in their vehicles (cf. Section 3.6.3).
3.5.2.1. Procurement of Hardware Components
As described in Section 3.3.2.2, the execution platform for the prototype vehicle uses two customer computer, a gateway, and Ethernet bus in order to enable the efficient development of the lane change assistant. The hardware components, e.g., sensor, actuators, ECUs, and communication buses, used in the technical architecture (cf. Section 3.3.2), are acquired from suppliers and are integrated into the execution platform.
3.5. Implementation
The execution of the software components on each ECU and their access to the hardware components, e.g., communication bus or CPU, require the configuration of an operating system (OS) and its services. Similar to hardware components, services of the OS are obtained as off-the-shelf components from suppliers (cf. [SZ13]).
The standard AUTOSAR (cf. [Für+09]) defines an architecture for ECUs with stan- dardized interfaces between application software, e.g., the lane change assistant, and services of the OS — named basis software in the standard. The standardized interfaces of the AUTOSAR architecture enable the application software to access basis software components without any knowledge about the possible diverse implementations from various suppliers. A configuration of the operating system for the lane change assistant is not necessary. The customer computers run a standard Linux OS that inherently provides all necessary services for the processing of data and the access to the Ethernet bus.
The result of the safety analysis for the environment perception (cf. Fig. 3.19) require the deployment of a multi-sensor platform for prototype vehicles. Therefore, existing sensors of the prototype vehicle are complemented by additional sensors, e.g., the side and rear RADAR sensors in Fig. 3.19. These additional sensors are installed in the prototype vehicle for the lane change assistant and the highway pilot. The sensors are connected with the execution platform for the lane change assistant via the gateway in order to guarantee a redundant 360◦ view around the prototype vehicle for the lane change assistant (cf Fig. 3.16).
Sensors, actuators, and their corresponding software components often require calibrations. The correct perception of sensors, e.g., stereo cameras, LIDAR, and RADAR sensors, depending on the correct calibration for their mounting location inside the vehicle. For example, a false exit angle of radio waves or LIDAR beams can lead to false reflection points at a position where no object is present resp. to missing reflection points for existing objects. For stereo cameras, the calibration is essential in order to estimate the distances of objects correctly. Car manufacturers have to calibrate sensors themselves or provide sensor suppliers with these parameters in order for the suppliers to calibrate the sensors for them. The same applies to actuators whose ranges of set values have to be calibrated. For example, the possible turn angle has to be calibrated for an electrical steering system.
3.5.2.2. Hardware Unit Tests
Car manufacturers do not perform the verification of hardware components themselves but require suppliers to verify the sustainability and resilience of hardware components in their development process. Failures rates of hardware components have to be sufficiently low and comply with relevant standards, like the safety standard ISO 26262 (cf. [Int09e]). The resilience and robustness of hardware components is commonly evaluated in endurance run using HIL tests or prototype vehicle (cf. Sections 2.2.2 and 2.2.2.7).
However, car manufacturers may randomly test a limited number of provided hardware components in order to ratify the suppliers’ statements about the component’s sustain- ability, resilience, and correct calibration. For example, image-based sensor, e.g., stereo
cameras, can be verified in simulations. Traffic situations are generated in simulations and projected onto a screen from which the camera perceives these situations. The identified objects by the camera are compared to the objects used in the simulation. The displayed traffic situations have to be sufficiently realistic for valid verification results. For the prototype vehicle, no dedicated verification for the sustainability of the computer hardware, gateway, and Ethernet network has been performed. The necessary evidence about the sustainability and resilience of hardware components by legal authorities and safety standards, e.g., the safety standard ISO 26262, only apply to production vehicles but not to the prototype vehicles. The hardware configuration of the prototype vehicle is used for the development, prototyping, and testing of the lane change assistant and is not supposed to be used in production vehicles. However, the original components of the initial production vehicle have already been verified in their development processes and have proven themselves in usage by customers in public traffic.
The software and hardware components, which have already been verified in isolation, have to be integrated in order to complete the system. This integration requires additional verification and validation activities. The following sections describe the right side of the v-model development process (cf. Fig. 3.2) addressing the integration, verification, and validation of the lane change assistant.