Quality Assurance and Certification of Software Modules
in Safety Critical Automotive Electronic Control Units
Using a CASE-Tool Integration Platform
comfort functions in a car. Communicating over different bus systems most ECU\u2019s perform close loop control functions and reactive functions and have to fulfill hard real time constraints. Some ECU\u2019s controlling on board entertainment/office systems are software intensive, incorporating millions of lines of code. The challenge for the design of those distributed and networked control units is to define all requirements and constraints, understand and analyze those manifold interactions between the control units, the car and the environment (driver, road, weather) in normal as well as stress situations (crash). To improve the design of safety critical ECU\u2019s we propose an enhanced development process (double-V-model). The use of different modeling descriptions for closed loop control, reactive systems and software intensive systems requires a CASE-tool integration platform. We have developed \u201cGeneralStore\u201d as a platform to support model driven design with hetero- geneous models in a design process which is concurrent and distributed between the automotive manufacturer and several suppliers.
More than 70 electronic control units (ECU\u2019s) serve for safety and comfort functions in a luxury car. Communicating over different bus systems (e.g. CAN class C and B  , LIN , MOST , Bluetooth , ). Many ECU\u2019s are dealing with close loop control functions as well as reactive functions, they are interfacing to sensors and actuators and have to fulfill safety critical hard real time constraints (thus the software is running under a real time operating and network management system like OSEK/VDX  on a standard hardware platform). Other ECU\u2019s controlling the onboard infotainment system (video- and audio-entertainment, office-in-the-car with according internet and voice communication, navigation) are really software intensive, incorporating millions of lines of code. All ECU\u2019s are connected to the
As new functions in future cars require communication to traffic guidance systems, road condition information systems as well as car to car communication, the software intensive infotainment ECU\u2019s will be directly coupled to power train and body control ECU\u2019s, even forming closed loop control. Thus, the design of these future systems need to combine methodologies and computer aided design tools for reactive systems and closed loop control systems as well as software intensive systems.
The challenge for the design of those distributed and networked control units is to find and define all requirements and constraints, to understand and analyze those manifold interactions between the many control units, the car and the environment (road, weather etc.) in normal as well as in stress situations (crash), to perform failure mode and effects analysis and to ensure fail safe and fail operational units for safety critical functions. The development process, which is concurrent and distributed between the automotive manufacturer and several suppliers, requires a well understood life-cycle model and a strictly controlled design methodology and using computer aided engineering and design tools to its largest extent.
Design methodologies used today in the automotive industry are focused on the design of distributed functions. Currently, safety and reliability issues are not taken into account from the very beginning of the development process. In the automotive industry the V-model  is a well recognized and widely used life cycle model. To include safety and reliability issues from the very beginning we propose in chapter 2 to extend the V-model into a double-V-model where the existing first V describes the development of functions complemented by and interrelated to the second V which handles safety and reliability issues. A well defined information exchange between the activities and products of the two Vs take care of the system safety assessment process, fault tree analysis and failure mode and effects analysis. The methodology is based on certification considerations of complex aircraft systems (SAE ARP 4754 standard  and IEC 61508 standard ) tailored for automotive applications.
Handling safety issues earlier in the design cycle is just one of the major challenges in automotive electronics. Due to the different description methods preferred for the development of closed loop control functions (power train control), reactive functions (body functions) and software intensive functions (car-infotainment) support is needed to handle heterogeneous models in a model based design methodology. For that purpose we have developed the CASE tool integration platform \u201cGeneralStore\u201d. As described in chapter 3 GeneralStore is a MOF, XMI based repository to couple heterogeneous models developed with tools like Matlab/Simulink/Stateflow, Statemate, UML based tools and generic XMI tools. GeneralStore uses commercial code generators as well as a proprietary code generator for handling structural and behavioral descriptions in UML. GeneralStore is developed using Java and the MySQL or Oracle database system. GeneralStore offers functions for check-in/check- out, automatic wrapping, code generation, compile and link as well as versioning and configuration of software modules. Using the double-V development model and GeneralStore we will enhance the development process for safety critical applications and provide more efficiency in model based design.
The standard process for the development of automotive electronic systems is based on the \u201dV Model \u201997\u201d, a life cycle process model that is the development standard for embedded electronic systems of the Federal Republic of Germany . Originally intended for information and communication systems it was adapted for other domains, including the automotive domain. However the sequences of design and verification steps is neither standardized nor formalized throughout the automotive domain. Almost every OEM and supplier uses a slightly different design method. In the automotive industry currently large efforts are made to enhance the development of safety critical electronic systems. The aerospace industry (a domain with very standardized and formal development processes) has a lot more experience with safety-critical systems. Aerospace development processes have both function and safety of an aerospace system as the center of focus  (Fig.1).
However, the aerospace processes cannot be used directly in the automotive domain, as the boundary conditions and the requirements for safety and reliability in these two domains are different. For example hazard analysis for an airplane explicitly distinguishes between different flight phases (start, cruise, landing). The according phases for cars (start, accelerate, cruise, braking) generally don\u2019t make sense. For cars different driving situations are more relevant e.g. for a steer-by-wire system: driving straight ahead, driving curve, pass maneuver, reversing etc., in principle distinguish whether or not the steering wheel needs to be turned or not. Also road conditions should be considered (rain, aquaplaning, ice, off road, gravel, sand, road hole, flange groove).
Besides different analysis processes the most important differentiation is the very low production volume of electronic control units in an airplane in comparison to automotive electronic systems (several thousands vs. several millions), therefore, cost for more hardware components in an airplane preponderate much less than labor- intensive and protracted development and test of a new concept. Safety and reliability requirements in airplanes allow for expensive redundancy concepts. Redundancy is necessary in both domains, however, the triple-triple modular hardware redundancy for the primary flight control in a large passenger plane, e.g. the Boeing 777, is by far too expensive in automotive applications, so, double hardware redundancy is common in cars.
A basic property of system development in aerospace domain is the certification of both, the design process and the designed system (usually by a third party like the Federal Aviation Association FAA). We propose a similar approach to an adapted methodology for the automotive domain which considers safety equally with function and can be described as \u201ddouble V model\u201d. It is based on the V-model  (Fig.2 shows the V-model with focus on software development), however, a second V with elements that have a special focus on safety and reliability is added to the original V and connected to it at several appropriate places in the development process. The concepts underlying the additional elements were taken from the aerospace domain and adapted to automotive conditions. Figure 3 gives an overview on the proposed design methodology.
Now bringing you back...
Does that email address look wrong? Try again with a different email.