Keywords

1 The Plug in Concept of Automotive SPICE 3.1

Figure 1 below illustrates the plugin concept in Automotive SPICE 3.1 [1]. The system V-model includes the processes SYS.1 Requirements Elicitation, SYS.2 System Requirements Analysis, SYS.3 System Architectural Design, SYS.4 System Integration and Integration Test, and SYS.5 System Qualification Test.

Fig. 1.
figure 1

The plugin concept of Automotive SPICE 3.1

Full size image

The software V-model includes the processes SWE.1 software requirements analysis, SWE.2 SW architectural design, SWE.3 SW detailed design and unit construction, SWE.4 software unit verification, SWE.4 software integration and integration test, SWE.5 SW qualification test.

Figure 2 below shows the traceability concept of Automotive SPICE which in Annex D describes the traceability concept for system and software level but still not for the hardware or mechanics level.

Fig. 2.
figure 2

Bidirectional traceability and consistency concept of ASPICE 3.1

Full size image

Automotive SPICE 3.1 (see Fig. 1) does not contain a description and base practices for the HWE.1 to HWE.6 processes. However, Automotive SPICE 3.1 foresees a plug in model that can be used for an extended assessment including hardware. The SOQRATES working group developed a first version of this HWE.1 – HWE.6 processes and base practices.

HWE Spice includes the following processes

  • HWE.1 Hardware Requirements Analysis

  • HWE.2 Hardware Architectural Design

  • HWE.3 Hardware Detailed Design

  • HWE.4 Hardware Unit Verification

  • HWE.5 Hardware Integration and Integration Test

  • HWE.6 Hardware Qualification Test.

2 Research Method

The European Commission directive 2001/95/EC on General Product Safety and the decision 768/2008 of the European Parliament forced the Automotive industry -

  • to report any safety critical issue to a publicly available database. These news are also used by journalists to report about large recall actions of Automotive manufacturers.

  • to either solve the safety critical issue or to withdraw the products from the market.

Automotive manufacturers are not liable if they apply the state of the art in their developments and consider the safety norms appropriately. However, there is no clear definition of what a state of the art really is. Research papers might be used but they are not strong enough to withstand in court because you always find papers with contradictory views.

Therefore task forces like SOQRATES [7] (www.soqrates.de, formed in 2003 and with a large group of leading suppliers in Automotive) agreed a research method to define a state of the art. Best practices for analysis methods, design approaches, assessment model understanding etc. are compared among the group of the largest suppliers and joint best practices are agreed and published. This way these best practices are declared as a state of the art. This paper publishes such a consensus of a group of experts from leading suppliers in Automotive industry.

3 Extended Hardware SPICE Terminology

In Automotive SPICE the smallest part into which a software is decomposed is called SW unit. One of the research questions was: What is a hardware unit and the smallest part we will look at in an assessment?

The functional safety (ISO 26262) norm already included a hardware assessment and therefore the terminology of the ISO 26262 norm has been re-used. However, also the ISO 26262 norm did not define hardware unit, but hardware element and hardware part. Below you find the terminology from the ISO 26262 as well as the hardware unit definition which was agreed in the SOQRATES working party.

HW Element (ISO 26262):

  • ISO 26262: “system (1.129) or part of a system including components (1.15), hardware, software, hardware parts (1.55), and software units (1.125)” NOTE A component is a part of a system.” The numbers 1.xx in this paragraph refer to definitions in part 1 of ISO 26262:2011.

  • The top level of HWE in this scope

  • HWE.1 requirements are related to this level

  • HWE.2 describes the architecture of the element

HW Unit (New Definition):

  • “A hardware unit is the smallest block of hardware to which a specific hardware sub-function can be assigned.”

  • HWE.2 describes an architecture, where the HW units of the HW element are defined

  • HWE.3 describes the detailed design of these HW units, that consist of HW parts

  • Example: Electrical power supply

In Fig. 3. Above the function of this module is to convert the 230 V to a circuit supply of 9 V. This includes different hardware parts and integrates them to a hardware unit. The hardware unit has a function which can be mapped onto unit testing including e.g. equivalence class test:

Fig. 3.
figure 3

Example of a hardware unit – electric power supply

Full size image

  • Testing above 240 V, the fuses F1 shall fire, no voltage output

  • Testing in 230 ± 10 V range, the system operates and delivers 9v

Hardware units can also include diagnose outputs such as a connection to an ADC that then writes the measured voltage to a register.

HW part (ISO 26262):

  • Lowest level of HW

  • Parts that are considered not to be sub-divided in this application scope

  • E.g. a resistor or an IC.

4 Integrating Functional Safety Aspects in the Hardware Assessment Model

In ISO 26262 [2,3,4, 6, 8,9,10,11,12,13] two forms of assessment are done, a safety audit and a safety assessment. While the safety audit is a process assessment like Automotive SPICE the safety assessment is an assessment and evaluation of the product. Also the safety audit includes further aspects which need to be considered when assessing hardware.

Because ISO 26262:2011 assessments are used since years the members of the SOQRATES group expected an integration of both approaches. Therefore in the assessment model in chapter 5 of the paper safety related clauses are listed per Hardware SPICE base practice.

Below you find some specific work products which are additionally needed. The below is just an overview, more details have been described in previous safety related publications.

Safety Selects Parts that are Affected by a Safety Goal:

All hardware parts that are affected by a safety goal inherit the ASIL (Automotive Safety integrity level, ASIL A – D) from the safety goal. E.g. In a steering system to not create more torque then demanded by the driver. The driver steering torque is measured by a torque sensor, and this torque is calculated by an ECU (Electronic Control Unit) and used to control an e-motor to provide this torque on the steering rack/system. Every hardware part in this functional chain and which is affected by the safety goal is marked with the proper ASIL A-D level. In steering the above mentioned safety goals is rated as ASIL – D. This includes e.g.

  • The controller

  • The torque sensor

  • The connector from the torque sensor to the ASIC

  • The ASIC/IC to convert the torque sensor

  • The connection/bus between the ASIC and the controller

  • The memory on the ECU

  • The bridge to actuate the motor

  • the bridge to connect to the motor and the IC to provide the phase currents.

Safety Looks at a FIT Rate:

FIT stands for Failure in Time which is measured in hazardous errors occurring in 109 operating hours. 1 Fit is 10−9, so one hazardous error in 109 operating hours. The higher the ASIL the higher the reliability of a hardware part has to become. And a safety goal rated ASIL D e.g. needs to achieve 10 FIT, which is 10−8. 109 h observation time can easily be reached nowadays because cars are nowadays estimated with 104 h life time and a fleet of cars might by more than one million (106) using that component, making a total of 104 * 106 = 1010 h. When looking at single hardware units which are affected by the safety goal the ISO 26262 norm assumes around 100 such components in average and each having 10−10 h, so that 100 * 10−10 = 10−8 (meeting 10−8 ASIL – D goal).

Safety Uses Diagnostic Coverage to Reduce the FIT:

The annex D of part 5 of the safety norm ISO 26262 includes guidance material to address 60%, 90%, or 99% diagnostic coverage. A simplified understanding is the following for signals:

  • 60% - only values within range are accepted, so that the system only calculates with valid values.

  • 90% - drift can be identified, so if the sensor starts to drift, the deviation can be detected. This usually requires a second separate channel and sensor to compare with.

  • 99% - spiked and impact of oscillation is detected.

  • 99.9% - together with the hardware manufacturer all known field issues are tested and the faults are detected.

The diagnostic coverage is then used to reduce the fit. E.g. if a controller has 400 FIT but in the architecture a second diverse controller is used to compare with the diagnostic coverage increases to 99%. If all known controller errors are detected (e.g. that both diverse controllers have not the same faults) the diagnostif coverage increases to 99.9%. The probability that the hazardous error is not detected is then decreasing to only 1 – 0.999 = 0.001. The 400 FIT are then reduced to 400 * 0.001 = 0.4 FIT.

Safety Looks at Single Point Faults and Latent Faults:

The FIT rate is to be considered for single point and latent faults. A single point fault means that if a single hardware part is failing the hazardous error will appear. The latent fault means that the hardware part fails, the diagnose does detect the fault, and then the latent fault appears. The single point fault metric uses the FIT and the diagnose coverage as outlined above.

Safety Uses Decomposition Strategy:

If you assign an ASIL – D to a hardware unit a design decision needs to be taken because

  • mostly the hardware units/parts cannot be acquired at ASIL-D quality

  • by using two different independent and diverse channels helps to increase the diagnostic coverage to 99.9% to get rid of the FIT.

Therefore in most ASIL ranked systems a decomposition into parallel independent parts/channels takes place.

Safety Uses an HSI – Hardware Software Interface:

The HSI specifies safety critical hardware interfaces and assigns raw software variables (base software, physical values, registers) and functional software variables. This allows to monitor and test safety critical physical and software parameters influencing the safe system behaviour.

Safety Expects an FMEDA - Failure Modes, Effects, and Diagnostic Analysis, and an FTA [5]:

For each safety goal the affected hardware parts and their related diagnostic coverage are used to calculate a total FIT for single point faults. For each safety goal the affected hardware parts and their related diagnostic coverage are used to calculate a total FIT for latent point faults. There are many more such design strategies and they were integrated (using clauses from part 5 of ISO 26262) into the hardware SPICE assessment model.

5 The Hardware SPICE Assessment Model

Below you find an example HWE process as it is defined in the hardware SPICE assessment model. The whole model can be provided by the SOQRATES working party, under the condition that the materials are properly referenced and review input is provided back to the model developers in the SOQRATES group. This model then includes all 6 HWE processes with all base practices and ISO 26262 additional checklists. See example parts of the HWE.3 process below (the complete HWE.3 process is in the appendix (Table 1):

Table 1. Selected example of the HWE.3 Hardware Detailed Design Process
Full size table

For each base practice the companies in the working party SOQRATES assigned content of the ISO 26262 norm. This includes assignment of ISO 26262 clauses as well as additional questions that should be asked in case of a safety relevant development project. e.g. the additional questions asked by hardware safety exerts when joining the HWE SPICE assessment for HWE.3.BP1: Develop hardware detailed design are (Table 2):

Table 2. Example of additional safety related questions
Full size table

For example, the assignment of clauses for HWE.3.BP1: Develop hardware detailed design is shown below (Table 3):

Table 3. Example of ISO 26262 clauses assigned to a base practice
Full size table

6 Expected Impact and Outlook

The AQUA [18, 19] (Knowledge alliance for Quality in Automotive engineering) integrates different norms and standards related to Functional safety, Automotive SPICE, APQP, Cybersecurity to manage the complexity of the systems and to achieve quality, safety, and security in the vehicle. AQUA created a new job role of a quality engineer that can integrate these methods and standards. AQUA will integrate the hardware SPICE into their educational program.

Major Tier 1 in SOQRATES [6] have co-developed to create a first version of the hardware SPICE plugin model. It can be used as a first draft to assess not inly the system and software but also the hardware in Automotive SPICE assessments. Since functional safety (ISO 26262 [2,3,4, 6, 8,9,10,11,12,13]) already does hardware assessment the hardware SPICE assessment model builds the bridge between the safety and the Automotive SPICE understanding.

7 The SPI Manifesto Revisited

The SPI manifesto [14,15,16,17] describes values and principles which need to be considered to make improvements work in an organisation. One of the approaches is to start with an assessment and to derive an improvement list. This is then used to set up an improvement program.

The principle “Use dynamic and adaptable models as needed” means that depending on the need of organisations specific models can be adapted. The hardware SPICE assessment model is such a new model which is needed in the Automotive domain.

The principle “Base improvement on experience and measurements” means that best practice experiences need to be shared and the usage must be tracked and measured. Since the model was developed in a group of Tier 1 in the SOQRATES working group the model development was based on such an experience and best practice sharing approach.

An additional principle proposed for the SPI manifesto is: “Observe new trends and state of the art practices on the market and adopt”. The product liability law and the RAPEX (www.rapex.com) database changed the market because hazardous faults as well as legal violations in cars lead to a mandatory recall action and all cars must be repaired. This creates huge cost and thus new state of the art standards like functional safety, cybersecurity etc. became an important issue.