Extending Automotive SPICE to cover Functional Safety Requirements and a Safety Architecture

Richard MESSNARZ1, Ivan Sokic, Stephan Habel2, Frank König3, Ovi Bachmann4

1ISCN GesmbH, Schieszstattgasse 4, A-8010 Graz, Austria Tel: +43 316 811198, Fax: + 43 316 811312, Email: rmess@iscn.com

2Continental Automotive, Germany 3ZF Friedrichshafen AG, Friedrichshafen, Germany

4SIBAC GmbH, Mittelbiberach, Germany

Abstract. This paper discusses (based on Automotive industry examples) how the functional and requirements traceability concepts in Automotive SPICE had to be extended to cover the criteria and content demanded by ISO 26262. In a second section the paper describes how these new concepts are considered in the integrated Automotive SPICE and Safety assessment approach which was proposed by the SOQRATES initiative (www.soqrates.de) where more than 20 leading German firms collaborate in cross company task forces. See previous papers about the integration approach and assessment method proposed in [4]

Keywords: Automotive SPICE, Functional Safety Requirements, Safety Architecture

1 Functional and Requirements Traceability in Automotive SPICE

Systems became more and more complex over the last 20 years. Most manufacturers in aerospace, cars, trains, etc. illustrate an exponential increase in functionality controlled by a combination of mechanics, electronics, and software. E.g. a function inside a car nowadays is distributed among subsystems (brake, motor, gear system, ESP, etc.) which communicate via a bus and report to a joint failure storage in the car.

To manage the increasing complexity most manufacturers pushed certain methodologies which allow to monitor the functionality, to track the progress of completion and to ensure the coverage in testing [1], [2], [3]. If you are a supplier in fields like automotive, medical, aerospace, etc. you will be asked to implement a requirements management method.

Requirements have to be defined on different levels and linked. This creates a functional / requirements tree.

Car manufacturers link car requirements to systems (delivered by suppliers), system requirements are linked to component requirements (mechanical component, hydraulic component, etc.), and in case of a SW component it is expected that more

detailed SW module requirements will be derived and traced as well [5], [8]. The idea underlying this requirement tree is to create a structure which allows to do an impact analysis. You have an impact network and if the manufacturer sees a malfunctioning of one of the car functions they can directly address the different components which are affected and influence the fault situation.

Fig. 1. Example for Analyzing Customer Requirements and Deriving a Linked System Specification

Figure 1 shows an example of an all-wheel-drive system where a dynamic

requirement (how fast the system can actuate) is analyzed, mapped onto a system test, and the impact on subsystems is illustrated.

Figure 2 shows an example of how this system requirement impacts the

functionality of the mechanical, ECU, and Software subsystems leading to changes in more than one subsystem to satisfy this one system requirement.

Automotive SPICE demands that we can trace the impact of customer to system

and down to subsystem functions and vice versa (bilateral traceability).

In practice this means that we have a clear understanding of the functional decomposition and dependencies in the system.

Usually in Automotive industry this is supported by a DOORS or MKS RM tool

set which allow to store these documents, link content, and create reports about requirements coverage.

This situation was the starting point when we had to implement the ISO 26262

concepts.

Fig. 2. Example for Analyzing System Requirements and Deriving Linked

Software, ECU, Mechanics Requirements

2 Extensions of Automotive SPICE Implemented for ISO 26262

The idea was to add further content and safety related design on the basis of the existing functional understanding and traceability mechanisms of Automotive SPICE [4], [9], [10].

In Figure 3 an Automotive example is illustrated in which the extension is based on

a hazard which is derived from an over - temperature of the system.

The customer requirement would generally state that in case of a system temperature > 120 degrees Celsius the system must reduce power by a degradation function. The hazard analysis (an extension of risk management in Automotive SPICE!) would deliver a safety goal “No uncontrolled actuation of the steering system”, and would state that an uncontrolled actuation can happen with a system temperature > 130 °C.

The hazard analysis could lead to an extension of the Automotive SPICE process MAN.5 Risk management. MAN.5 normally addresses project risks but by including FMEAs and FMEDAs and hazard analysis prevention / mitigation actions on product level can be added.

The FMEA and FMEDA (FMEA is already mentioned in MAN.5 Risk management in Automotive SPICE, the tracing of signal paths and analyzing diagnostics software in the FMEA has been added in safety analysis) would deliver a more detailed analysis of the error situation and propose a measure “to implement a redundant temperature control and a safe state to be reached in case the two temperature values differ”. An analysis of the signal-paths showing the severity of a failure in this path together with a required diagnosis will lead logically lead to the redundancy.

Fig. 3. Strategy Extensions in the process to Derive System Requirements from Customer Requirements

Fig. 4. Extensions in the process to Derive a System Architecture from System Requirements

In Figure 4 the previously shown Automotive example illustrates the extension based on a technical safety concept as an integrated part of the overall systems architecture and linked to the system safety requirements.

The system requirements specification would contain safety requirements (new in

comparison to Automotive SPICE!) dealing with e.g. the plausibility check of the temperature running in an independent diagnosis control function, while in the technical safety concept (new in comparison to Automotive SPICE!) the details of the control cycle with plausibility check, tolerance values, will be designed, e.g. two analogue temperature sensors with one on the electrical circuit, one on the power amplifier component, a system evaluation that both positions allow a maximum difference of 5 °C, and a plausibility check which leads to a safe state if the difference is above the tolerance threshold for more than a certain time.

Fig. 5. Part 1 – Overall Picture of the Extensions in the Process to Derive Sub-System Requirements (see also Part 2)

New to Automotive SPICE is the consideration of ASIL levels A – D and a method

to reduce the ASIL levels and to decrease the probability that the hazard will occur and cannot be controlled. If e.g. a signal is declared ASIL – D it is possible to reduce the ASIL level by making an independent parallel control of that signal and to check whether the signal is plausible or not. Usually an ASIL – D requires to independent processors in the ECU, an ASIL – C requires two independent signals and plausibility checks for important values, and this way an ASIL decomposition usually requires a more expensive design with more parallel independent controls and plausibility checks.

Figure 5 Part 1 and Part 2 illustrates an Automotive example with such an extension based on a set of safety sub-system requirements as well as a HSI (Hardware-Software-Interface) specification.

In the HW safety requirements specification there will be e.g. two temperature sensors (independent control of temperature and plausibility check), one on the circuit board, and one on the power amplifier. Both would be analogue, with a Volt-Out range from 0.1 to 2 V, and a temperature range from -40 to 130 °C. The ECU would reserve pins 21 and 24 for the 2 sensors.

In the HSI (new in comparison to Automotive SPICE!) specification the signal flow from sensors to the software is described in detail so that we can test and assure the signals. E.g. for the temperature signal 1 we describe the type of sensor (analogue), Volt range, temperature range, scaling algorithm used to calculate the temperature, cycle times to read updates for the software, etc.

In the software requirements a special diagnosis function (control function

independent from the functional software) is defined which can do the plausibility check of the 2 temperature variables s_temp1 and s_temp2 and switch to a safe state if the difference sustains over e.g. a period of 5 minutes (new in comparison to Automotive SPICE!).

Fig. 5. Part 2 – Details of the Overall Picture of the Extensions in the Process to dDerive Sub-System Requirements (see also Part 1)

The advantage of the HSI is that it contains a mapping between messages and signals on system level to signal names and variables on software side, thus building a bridge for tracking signal flows from system to software level. In almost all projects where we started to create a specific HSI specification we could solve a number of misunderstandings between system and software level preventively.

This extended structure in Automotive SPICE also has direct impact on the testing

strategy. Figure 6 illustrates the impact on e.g. Software Test.

Fig. 6. Extension of SW Testing Procedures based on Safety

The additional extended HSI specification leads to a more intensive testing approach for the safety critical signal flows. Usually a white box (not black box) test was required to demonstrate the correct signals at the following 4 measurement points.

See M1, M2, M3, M4 marks in the above Figure 6. M1: Sensor is working, signal is produced with correct (voltage) range and

resolution.

M2: The scaling algorithm is working and signals are correctly transferred into variables, and updated in the correct cycle times in ms.

M3: The plausibility check is working and the correct tolerance is applied within

correct latency time. M4: The correct diagnosis level and program is started to solve the risk, leading to

a safe state.

3 Assessment of Specific Safety Content based on the Extensions

In [4] and [10] we described how we mapped Automotive SPICE towards IEC 61508 and ISO 26262.

During an assessment the “Functional Safety View” can be activated with the following effects:

Base practices will have additional criteria. Generic practices include additional criteria. New safety practices will appear. A safety methods table per process can be opened to consider the use of

methods when assessing the practices. In the functional assessment view we ask about extended safety practices which

relate to the previously described strategy of extending Automotive SPICE to cover safety as well.

Fig. 7. Activated Functional Safety Views – ISO 26262 Extensions

For instance, in Figure 7 a new safety base practice ENG.3.BP7 has been added by additional requirements originating from IEC 61508 and ISO 26262.

The overall text for ENG.3.BP7 derives from general safety requirements from IEC 61508, while the specific element related text (reference ISO 26262 Part 6.6, chapter 6.6.4.2) describes specific safety requirements stemming from the Automotive specific functional safety standard ISO 26262.

The ISO 26262 part of the question asks about the aspect illustrated in Figure 5

where software safety requirements are derived from technical safety requirements. The IEC 61508 part of the question asks about the independence of the control

function as described in the technical safety concept as part of the systems architecture in Figure 4.

All extended or new safety base practices in the integrated safety and SPICE

assessment are derived from such extensions needed to move from Automotive SPICE to cover safety aspects, as well.

For further assessment approach details please read the articles [5], [10].

4 Lessons Learned

There is a step by step approach to extend existing Automotive SPICE based processes and system designs to also cover aspects and requirements demanded by functional safety standards. It needs consequent extensions of requirements specification, architectures, control mechanisms and tests.

Integrated SPICE and safety assessments become possible if we can create a

complete understanding of how to extend systems and specifications from Automotive SPICE to safety architectures and traceability in safety systems as outlined in chapter 2 of this paper.

5 Acknowledgements & SOQRATES membership

We are grateful to the experts who have contributed to the Design AK and Safety AK: O. Bachmann (SIBAC), S. Habel, Leo Ross, I. Sokic, R. Dreves (Continental Automotive), F. König, A. Koundoussi (ZF), Bernhard Krammer (Takata Petri AG), G. Spork (Magna Powertrain), M. Haimerl (IMBUS), K. Dussa-Zieger (Methodpark), A. Riel (Grenoble INP), J. Unterreitmayer (SQS), and D. Ekert, R. Messnarz (ISCN).

6 References

[1] R. Messnarz, et. al, Assessment Based Learning Centers, in : Proceedings of the EuroSPI 2006 Conference, Joensuu, Finland, Oct 2006, also published in Wiley SPIP Journal (Software Process Improvement in Practice), Volume 12 Issue 6 , Pages 505 – 610, November/December 2007 [2] R. Messnarz, et.al, Better Software Practice for Business Benefit, IEEE Computer Society Press, 1999, Washington, Tokyo, Berlin [3] R. Messnarz, From process improvement to learning organisations (p 287-294), Wiley SPIP Journal (Software Process Improvement in Practice), Volume 11 Issue 3 , Pages 213 - 335 (May/June 2006) [4] SOQRATES Safety Team, Richard Messnarz, Hans-Leo Ross, Stephan Habel, Frank König, Abdelhadi Koundoussi, Jürgen Unterrreitmayer, Damjan Ekert, Integrated Automotive SPICE and safety assessments (p 279-288), in Wiley SPIP, Volume 14 Issue 5, September 2009 [5] Automotive SPICE, www.automotivespice.com [6] ISO 26262, Road vehicles — Functional safety [7] SOQRATES Initiative, www.sowrates.de [8] HIS, www.his-automotive.de [9] Volker, Bachmann, Richard, Messnarz: “Improving the Software-Development for multiple Projects by applying a Platform Strategy for Mechatronic Systems”, in: Proceedings of the EuroSPI 2009 Conference, Wiley SPIP Journal, August 2010 [10] SOQRATES Safety Team, R. Messnarz, H.-L. Ross & S. Habel, F. König & A. Koundoussi, J. Unterreitmayer, D. Ekert, Integrated Approach for Automotive SPICE and ISO 26262 Assessments, in: Proceedings of the EuroSPI 2009 Conference, Wiley SPIP Journal, August 2010