Safety Lifecycle for Automotive Control Systems

Transcription

1 Safety Lifecycle for Automotive Control Systems Introduction Dipl. Ing. (FH) Melanie Cossy, MSc STZ Softwaretechnik Im Gaugenmaier Esslingen Germany Automotive control systems are increasingly used to perform so-called safety functions, which achieve or maintain a safe state in respect of a specific hazardous event. The international standard IEC sets out a generic safety lifecycle for electrical, electronic or programmable electronic systems (E/E/PE systems) that perform safety functions. This paper demonstrates how the software safety of a safety-related automotive control system can be developed in accordance with this safety lifecycle and it shows through an example how the recommendations of the IEC can be satisfied. Overall Safety Lifecycle The safety lifecycle of an embedded control system - the E/E/PE system - must always be part of the overall safety lifecycle of the vehicle, because design decisions related to the overall system architecture generally affect the safety of the embedded system. Figure 1 shows the overall safety lifecycle proposed by the IEC that can be used as technical framework to deal systematically with the different activities that are necessary to ensure the functional safety of a safety-related system. The overall safety lifecycle encompasses three different risk reduction measures: - E/E/PE safety-related systems (phase 9) - Safety-related systems other technology (phase 10) - External risk reduction measures (phase 11) Phase 9 of the overall safety lifecycle deals with the realization of the E/E/PE system and is termed E/E/PES safety lifecycle. Figure 2 visualizes the details of the E/E/PES safety lifecycle. To reduce the complexity of Figure 1 and Figure 2 the lifecycles do not show all the iterations between different the phases, which are an essential part of a development process. In addition the figure excludes the following three activities that are required for most of the phases of the safety lifecycle: - Management of functional safety: An important objective of this activity is to specify the responsibilities of the persons, departments and organization, which are carrying out or reviewing the different safety lifecycle phases. In addition it must be defined which procedures and techniques must be used during the different lifecycle phases and in which way the outputs must be structured and documented. - Verification: Through verification activities it must be demonstrated that the outputs of each phase of the safety lifecycle meet the objectives and specified for this phase.

2 - Functional safety assessment: The objective of the functional safety assessment activity is to investigate and arrive at a judgement on the functional safety achieved. The persons appointed to carry out the assessment must be competent and shall have access to all persons, all relevant information and equipment involved in any safety lifecycle activity. In addition the IEC recommends different levels of independents - independent persons, independent departments or independent organizations. 1. Concept 2. Overall scope definition 3. Hazard and risk analysis 4. Overall safety 5. Safety allocation Description of the overall concept; Information about the current national and international safety regulations Definition of the scope of the hazard and risk analysis Documentation of a qualitative or quantitative hazard and risk analysis Specification of the overall safety Safety allocation 6. Overall operation and maintenance planning 7. Overall safety validation planning 8. Overall installation and commissioning planning 9. Realization safety-related E/E/PE system 10. Realization safety-related system other technology 11. Realization external risk reduction facility 12. Overall installation and commissioning 13. Overall safety validation back to appropriate phase 14. Overall operation and maintenance 15. Overall modification and retrofit 16. Decommissioning or disposal Figure 1 Overall safety lifecycle

3 from box 5 in figure E/E/PES safety specification 9.2 E/E/PES safety validation planning 9.3 E/E/PES design and development E/E/PES architecture software safety specification hardware safety specification software design and development hardware design and development 9.4 E/E/PES integration 9.6 E/E/PES safety validation 9.5 E/E/PES installation, commissioning, operation and maintenance procedures to box 12 in figure 1 Figure 2 E/E/PES safety lifecycle Lifecycle phases Figure 1 and Figure 2 show that there are various activities that must be executed before the design and development of the E/E/PE system can be started. These activities produce the input information that is required during the design and development of the software and hardware of the embedded safety-related systems. The following paragraphs shortly present the lifecycle phases that must be executed before the development of the E/E/PE system can be started. Concept The objective of this activity is to develop and document a sufficient understanding of the equipment under control - the automobile, the required control functions and the physical and legislative environment. Overall scope definition The objective of this activity is the determination of the system boundaries and the scope of the following hazard and risk analysis. It must be defined which accident-initiating events need to be considered - for example component failures, procedural faults or human error - and which physical equipment must be taken into account. Hazard and risk analysis The objective of this activity is the determination of the hazardous events for all reasonably foreseeable circumstances. The likelihood and potential consequences of these events or event sequences are evaluated and the risk arising from the automobile is estimated as a combination of the probability of occurrence of harm and the severity of that harm.

4 Overall safety During this activity the required safety functions and the safety integrity are specified. The safety functions are those functions that achieve or maintain a safe state for the automobile, in respect of a specific hazardous event. The safety integrity is the probability that the required safety functions are performed satisfactorily. The safety functions and their safety integrity must be specified such that the risk arising from a hazardous event is reduced to a risk, which is accepted in the given context (Figure 3). tolerable risk risk without designated safety protective features necessary risk reduction increasing risk actual risk reduction risk covered by other technology systems risk covered by E/E/PE systems risk covered by external risk reduction facilities Figure 3 Risk reduction Safety allocations During this activity both the safety functions and the safety integrity are allocated to E/E/PE safety-related systems, other technology safety-related systems or external risk reduction facilities. When the allocation has sufficiently progressed, the safety integrity for each safety function can be specified in terms of a safety integrity level. (The IEC defines 4 discrete safety integrity levels.) E/E/PES safety specification The E/E/PES safety must be derived from the overall safety allocated to the E/E/PE system. During this activity the E/E/PES safety must be set out in detail and all information, which may influence the E/E/PE system design, must be defined. In particular the relevant modes of behavior of the E/E/PE system and the required failure responses (alarms, automatic shutdowns, etc.) must be specified. E/E/PES architecture The objective of this phase is to design an E/E/PES architecture (hardware and software) that fulfills all safety (Table 1). Software Safety Requirements Specification The software safety specification defines all required software safety functions: - Functions that enable the system to achieve or maintain a safe state - Functions related to the detection, annunciation and management - of faults in the programmable electronic hardware - of sensor and actuator faults - of faults in the software itself - Functions related to the periodic testing of safety functions (on-line and off-line)

5 Hardware safety integrity Systematic safety integrity Architectural constraints Probability of dangerous random hardware failures Avoidance of failures Control of systematic faults System behavior on detection of faults Table 1 Safety Requirements The highest safety integrity level that can be claimed for a safety function depends on the hardware fault tolerance and the safe failure faction of the architecture. (The safe failure faction is the ratio of the average rate of safe failures plus dangerous detected failures to the total average failure rate.) The probability of failure of a safety function due to random hardware failures must be less than the specified target failure measure. In accordance with the required safety integrity level an appropriate group of techniques and measures must be used to prevent the introduction of faults during design and development. The E/E/PES design must be tolerant against any residual hardware or software design fault, environmental stresses, mistakes made by the driver and errors arising from any data communication processes. The detection of a dangerous fault shall result in either a specified action to achieve or maintain a safe state or the isolation of the faulty part, to allow continued safe operation whilst the faulty part is repaired. Example: Electronic throttle control system The following example of an electronic throttle control system illustrates the activities during the different safety lifecycle phases described before. Scope Electronic throttle control systems are controlling the airflow in the engine of the vehicle and remove the mechanical linkage between the pedal and the throttle. With an electronic throttle control system it is possible to give the car engine in every moment exactly the necessary mixture of air, fuel, and ignition angle. Due to this exact and consistent engine control, electronic throttle control systems reduce fuel consumption. In addition, electronic throttle control systems facilitate the integration of comfort functions like cruise control and environmental measures, like heating the catalyst. The electronic throttle control systems are considered to be safety-related and therefore an adequate development process must be used. Hazard and risk analysis An undesired event associated with an electronic throttle control system is for example that the vehicle accelerates autonomously. - Severity Level An autonomously accelerating vehicle could result in an accident, which could kill or seriously injure the occupants of both the affected vehicle and any other vehicle, or pedestrians. - Probability Exposure to Danger: In order for the undesired event to result an accident of this severity certain conditions must be true. For example there must be another vehicle or a stationary object in the path of the affected vehicle. Avoidance of Danger: If a failure of the electronic throttle control system causes an autonomous acceleration of the vehicle the driver can try to avoid an accident by using the brake. Through a detailed analysis of the severity level and the probability of the undesired event it is possible to define its risk level.

6 E/E/PES Safety Requirements The E/E/PES safety must be derived from the results of a hazard and risk analysis and can be structured into safety function and safety integrity. For every undesired event with a risk level higher than the tolerable risk level a safety function must be defined. - Undesired event "autonomous acceleration": To handle the undesired event "autonomous acceleration" the electronic throttle control system must implement safety functions that achieve or maintain a safe state of the vehicle. The safety functions must detect an implausible acceleration and must enforce as adequate failure handling strategy an engine stop. - Undesired event "car does not react to pedal requests": The engine must kept running as long as possible, to be able to maintain servo functions and heating available. After the definition of the required safety functions it is necessary to specify the safety integrity by analyzing for every undesired event the necessary required risk reduction. The probability that the safety function is executed successfully must be so high, that the risk of undesired event can be reduced below the tolerable risk level. E/E/PES Architecture With the information of the required safety functions and their integrity the E/E/PES architecture can be designed. Figure 4 shows the main hardware components of an electronic throttle control system [1]. throttle position sensor 1 throttle position sensor 2 processor A fuel delivery function pedal position sensor 1 pedal position sensor 2 processor B throttle actuator driver Figure 4 Main hardware components of the electronic throttle control system The architecture contains two processors. Processor A contains the standard engine control function of spark, fuel etc. and is responsible for calculating the desired throttle position based on the pedal position and other inputs such as the gear state or the cruise control input. The processor B is responsible for positioning the throttle. The two processors measure all pedal and throttle sensors redundantly and continuously monitor the status of the other processor. The main software functions and there partitioning into application functions can be seen in Figure 5. Table 2 shows the alternative modes of operation of these application functions that are necessary to ensure safe system operation.

7 Figure 5 Application functions of the electronic throttle control system application function determinate pedal position determinate throttle position calculate desired throttle position control throttle position Table 2 Alternative modes of operation mode of operation normal mode (both sensor signals are used) sensor 1 mode (only the signal of pedal sensor 1 is used) sensor 2 mode (only the signal of pedal sensor 2 is used) forced idle mode (the driver intend cannot be reliably detected and therefore the pedal position is assumed to be zero) normal mode (the average of both sensor signals is used) sensor 1 mode (only the signal of pedal sensor 1 is used) sensor 2 mode (only the signal of pedal sensor 2 is used) max mode (the maximum value of sensor 1 and 2 is used) functionality not available normal mode forced idle mode (desired throttle position is equal to the default position) limited throttle authority mode (the maximum throttle position is limited) functionality not available normal mode start-up mode (to learn the minimum throttle position) ice mode (mode to remove a blockage) throttle actuator default mode (throttle motor is de-energized and throttle is driven to its default position by the return springs) engine shutdown mode (most severe remedial action) The design of the electronic throttle control system must ensure that all specified safety functions - for example the safety function that an autonomous acceleration must be detected with a sufficiently high probability - can be realized. Different architectures must be analyzed and evaluated through Failure Mode and Effects Analyses (FMEA). A detailed comparison of different E/E/PES architectures for electronic throttle control systems can be found in [2]. Software Safety Requirements The software safety are specified after the definition of an adequate E/E/PES architecture. During the specification of the software safety the software safety functions that detect faults and the safety functions, which achieve or maintain a safe state after the detection of a dangerous fault, must be defined in detail. An adequate way to structure and express the software safety is to model that system components of the E/E/PES architecture together with their failure modes of the FMEA as state machines. Figure 6 shows an example of such a component status function that determines the current status of the pedal position sensor.

8 Figure 6 Component Status Function To achieve or maintain a safe state after a failure of a safety-related component the application software has to adapt its working principle. This means that the operation modes of the affected application functions must be changed. Figure 7 shows how the correct operation mode of an application function can be specified with the help of a state machine. Each state corresponds to an operation mode of a application function and state transitions are triggered by component failures. Summary Figure 7 Reconfiguration Control Modul The lifecycle phases E/E/PES safety specification, E/E/PES architecture and software safety specification are closely related and normally many iterations are required between these phases, to find an optimal solution. During these iterations the specification of the safety is set out in detail, such that all safety functions are finally expressed as state machines in a clear, precise, unambiguous, verifiable, testable, maintainable and feasible way. The IEC recommends different techniques and measures for the verification of the safety : - Inspection of the specification, e.g. with the help of checklists - Computer aided specification tools - Application of formal methods

9 By using state machines for the specification of the software safety it is possible to formally analyze and verify the correctness of the specification [3]. This is a mayor advantage of the presented verification form. References 1. Costin, Schaller, Maiorana, Purcell, Simon, Bauerle, Stockbridge; An Architecture for Electronic Throttle Control Systems; SAE World Congress 2003; Paper Hans Mauser, Erwin Thurner; Electronic Throttle Control A Dependability Case Study; Journal of Universal Computer Science, vol. 5, no. 10 (1999), Melanie Cossy; Formale Spezifikation der Sicherheitssoftware für die Rekonfiguration von elektronischen Systemen im Fahrzeug; Safetronic 2003 Sichere Software und Hardware im Automobil; München Standards safety-related systems - Part 1: General ; International Electronic Commission; IEC :1998 safety-related systems - Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems; International Electronic Commission; IEC :2000 safety-related systems - Part 3: Software ; International Electronic Commission; IEC :1998 safety-related systems - Part 4: Definitions and abbreviations; International Electronic Commission; IEC :1998 safety-related systems - Part 5: Examples of methods for the determination of safety integrity levels; International Electronic Commission; IEC :1998 safety-related systems - Part 6: Guidelines on the application of IEC and IEC ; International Electronic Commission; IEC :2000 safety-related systems - Part 7: Overview of techniques and measures; International Electronic Commission; IEC : MISRA Report 2 Integrity; The Motor Industry Software Reliability Association, DIN 25448: "Ausfalleffektanalyse (Fehler-Möglichkeits- und -Einfluß-Analyse)". 1990