Critical Software Follow-Up Fabrice Bedoucha [PDF]

Zitiervorschau

CRITICAL SOFTWARE FOLLOW-UP Author: Fabrice Bédoucha Training reference: 0741159 Last update: 26th August 2021

ROUNDTABLE

 Self introduction (first name, surname, current position)  Your area of expertise / your background  What are your expectations regarding this training ?

2

CONTEXT



More and more Electronic Control Unit (ECU) are embedded in automotive.



Software is present in almost all ECU and has become essential



For ECU where software has an impact on safety (lock of the steering column, unattended acceleration of the vehicle, unwanted deployment of the airbag...) suppliers must be followed carefully.



There are several tools and methods available in Stellantis in order to follow the supplier, based notably on our lessons learned and ISO 26262. 3

PREREQUISITES





Facultative 

741061 (formerly named QM1579): Embedded software in automotive



0871229 (formerly named QM1544: Introduction to safety and ISO 26262

Necessary 

741060 (formerly named QM1500): Software safety and ISO 26262



The knowledge is supposed to be acquired but will nevertheless be refreshed, especially for ISO 26262 part 6.

5

AT THE END OF THE TRAINING YOU WILL…



have an overview of Stellantis process to follow ECUs with software safety



understand software development rules



know ISO 26262 expectations about software safety



be familiar with the way to quote suppliers’ answers about software development rules and ISO 26262 checklist



Presentation link:

http://docinfogroupe.inetpsa.com/ead/doc/ref.01272_19_02292/v.vc/pj 5

TRAINING RULES

No phone calls nor text messages

No delay

E-mail reading only during the break 6

CRITICAL SOFTWARE FOLLOW-UP



DIA and Software Guidelines



Software development rules



Refresh: ISO 26262 standard for software



ISO 26262 checklist



Supplier assessment



Conclusion

7

CRITICAL SOFTWARE FOLLOW-UP



DIA and Software Guidelines



Software development rules



Refresh: ISO 26262 standard for software



ISO 26262 checklist



Supplier assessment



Conclusion

8

DIA AND SOFTWARE GUIDELINES



DIA (Development Interface Agreement) defines

FROM QM1544 TRAINING

9

DIA AND SOFTWARE GUIDELINES



DIA (Development Interface Agreement) defines    



The sharing of responsibilities between PSA and the supplier Documentation exchanged between PSA and the supplier The milestones associated with the deliverables All the details necessary for the good work between PSA and the supplier

DIA template

http://docinfogroupe.inetpsa.com/ead/doc/document_view.action?ref=02016_13_02411&v=vc

FROM QM1544 TRAINING

10

DIA AND SOFTWARE GUIDELINES

ISO 26262

CPPR (Clauses Particulières et Planning de Résultats – Specific Clauses and Planning of Results) CPPR HW EE

DIA Defines the jobshare and interfaces between PSA and the supplier.  Generic DIA for black box ECU must be adapted for other ECUs (Engine Control, Body Controller, ESP…)

FROM QM1544 TRAINING

• • •

Application of ISO 26262 standard Demand for DIA to be filled before supplier choice Specific safety clauses CPPR SW EE

•

Software guidelines

11

DIA AND SOFTWARE GUIDELINES



DIA examples:

http://docinfogroupe.inetpsa.com/ead/doc/ref.20824_18_00245/v.vc/fiche http://docinfogroupe.inetpsa.com/ead/doc/ref.02016_18_01692/v.vc/fiche

12

DIA AND SOFTWARE GUIDELINES



Software guidelines document replaces CPPR (Clauses Particulières et Planning de Résultats – Specific Clauses and Planning of Results)



It must be sent to suppliers at each RFQ



It contains software requirements to be applied by suppliers on each ECU



Link to the Software guidelines:

CPPR SW

http://docinfogroupe.inetpsa.com/ead/doc/ref.00949_14_05687/v.vc/fiche SW Guidelines

13

Software guidelines Exercise DIA AND SOFTWARE GUIDELINES

Work: Groups of 2 persons

30’

Instructions: Check supplier answers of the 4 documents

Timing: Brainstorming : Restitution :

20 minutes 10 minutes

To go further: Open discussion with examples taken from trainees’ experience. 14

APQP / PPAP* grid for software

DIA AND SOFTWARE GUIDELINES



ECU developments are followed with APQP grid



For some projects, especially for white box ECU, software must be followed with APQP grid



Working group has defined APQP grid including software:

http://docinfogroupe.inetpsa.com/ead/doc/ref.01276_15_00086/v.vc/fiche

APQP grid

*APQP / PPAP: Advanced Product Quality Planning / Production Part Approval Process

15

CRITICAL SOFTWARE FOLLOW-UP



DIA and Software Guidelines



Software development rules



Refresh: ISO 26262 standard for software



ISO 26262 checklist



Supplier assessment

16

SOFTWARE DEVELOPMENT RULES



Capitalization of good and bad practices collected from suppliers and internally.



There are 61 rules divided in 9 categories: Generic rules Memory management Interrupts management Microcontroller management Stack management Watchdog management Operating system Software safety Coding rules 17

SOFTWARE DEVELOPMENT RULES

Generic rules Memory management Interrupts management Microcontroller management Stack management Watchdog management Operating system Software safety Coding rules



Reset reason storage



Continuous reset management



CRC mechanism

18

SOFTWARE DEVELOPMENT RULES

Generic rules Memory management Interrupts management Microcontroller management Stack management Watchdog management Operating system Software safety Coding rules



RAM check at start-up



Flash check at start-up



RAM initialization



Code executed in RAM



Dynamic allocation



EEPROM management



ECC in RAM and Flash 19

SOFTWARE DEVELOPMENT RULES

Generic rules Memory management Interrupts management Microcontroller management Stack management Watchdog management Operating system Software safety Coding rules



Interrupts initialization



Protection against many external interrupts



Interrupts priority change



Management when interrupts are disabled



Nesting of interrupts 20

SOFTWARE DEVELOPMENT RULES

Generic rules Memory management Interrupts management



Auto test



Input / Output ports configuration



CPU mode definition



Periodical inputs reading



Periodical outputs setting



Management of communication between microcontroller and other electronic components



Low level software review

Microcontroller management Stack management Watchdog management Operating system Software safety Coding rules

21

SOFTWARE DEVELOPMENT RULES

Generic rules Memory management Interrupts management Microcontroller management Stack management Watchdog management Operating system Software safety Coding rules



Stack usage computation



Stack usage measurement



Stack overflow management

22

SOFTWARE DEVELOPMENT RULES

Generic rules Memory management Interrupts management Microcontroller management Stack management Watchdog management Operating system Software safety Coding rules



Watchdog management



No watchdog refresh in infinite loop

23

SOFTWARE DEVELOPMENT RULES

Generic rules Memory management Interrupts management Microcontroller management Stack management Watchdog management Operating system Software safety Coding rules



Function re-entry



Deadlock detection



Dynamic allocation



Shared variables management



Priority inversion management

24

SOFTWARE DEVELOPMENT RULES

Generic rules Memory management Interrupts management Microcontroller management Stack management Watchdog management Operating system Software safety Coding rules



Coding rules related to pointers, arrays, arithmetic computation etc.



Software metrics management



Checking of coding rules



Lessons learned

25

SOFTWARE DEVELOPMENT RULES



Document DMOV_ELE06_0050 is applicable for each ECU that contains software.



Link to the document:

http://docinfogroupe.inetpsa.com/ead/doc/ref.DMOV_ELE06_0050/v.vc/fiche

Template

Example

26

SOFTWARE DEVELOPMENT RULES



This document is applied to all embedded software. The supplier must apply each requirement. However the supplier can propose an alternative solution or explain the reason why it cannot fulfill the requirement. The aim is not to get all the requirements applied but to get a consistent set of applied requirements, especially in term of software safety.



These requirements are not exhaustive and it is up to the supplier to apply other requirements, for example based on its lessons learned, which can ensure the robustness of its product.



Even if Stellantis’ answers "OK", the supplier stays responsible of its technical choices, implementation and tests. 27

SOFTWARE DEVELOPMENT RULES



How to fill the document : - In column C, the supplier indicates the expected level of conformity. if it is "FC : Fully Compliant" "LC : Largely Compliant" - "PC : Partially Compliant" - "NC: No Compliant" or if the requirement is "NA: Not Applicable". - In column D, the supplier indicates the current implementation status. - In column E, the supplier indicates the software version for which the implementation of the requirement is planned. - In column F, the supplier indicates in which software version the requirement is really implemented. - In column G, the supplier indicates the current validation status. - In column H, the supplier indicates the software version for which the validation of the requirement is planned. - In column I, the supplier indicates in which software version the requirement is really validated. - In column J, the supplier adds a comment to explain its choices, and all necessary information on implementation and validation progression For RFQ, only columns C, E, H and J must be filled.

28

SOFTWARE DEVELOPMENT RULES



Conformity status is not enough. We want to know also if the requirement is really implemented and validated, and in which version. 29

SOFTWARE DEVELOPMENT RULES



Conformity status is based on ASPICE notation. 

FC: Fully Compliant



LC: Largely Compliant



PC: Partially Compliant



NC: No Compliant



NA: Not Applicable 30

SOFTWARE DEVELOPMENT RULES



A document explains the expectation, evaluation criteria and examples:

http://docinfogroupe.inetpsa.com/ead/doc/ref.00949_12_05790/v.vc/fiche 

This document can help most of the time to evaluate supplier’s answer but if it is not enough, software expertise network can intervene on demand.

31

SOFTWARE DEVELOPMENT RULES SOFTWAREExercise DEVELOPMENT RULES

Work: Groups of 2 persons

60’

Instructions: Check supplier answers of the 6 documents

Timing: Document review: 30 minutes Restitution: 30 minutes

To go further: Open discussion with examples taken from trainees experience.

32

SOFTWARE DEVELOPMENT RULES SOFTWARE DEVELOPMENT RULES

We have seen that

Synthesis



61 rules usually well accepted by suppliers



The suppliers stay responsible for its development



Supplier’s answer must be followed until the end of the project



A document exists to help to analyze supplier’s answer



For more complicate cases, software expertise network can intervene. 33

CRITICAL SOFTWARE FOLLOW-UP



DIA and Software Guidelines



Software development rules



Refresh: ISO 26262 standard for software



ISO 26262 checklist



Supplier assessment



Conclusion

34

ISO 26262 ORIGINS AND ASIL DECOMPOSITION (PART 3)

CEI 61508 ISO 61508

CEI 61511

    

CEI 61513

CEI 62061

EN 50126 EN 50128 EN 50129

ISO 26262

CEI 61511 (2003): industrial processes. CEI 61513 (2001): nuclear safety. CEI 62061 (2005): machines safety. EN 50126 / EN 50128 / EN 50129 (1999/2001/2003): railroad safety. ISO 26262 (2011): automotive.  

First version in 2011, second version in 2018 (ISO 26262:2018) ISO 26262 norm is applied on electrical and electronics equipments for massproduced cars.

35

ISO 26262 ORIGINS AND ASIL DECOMPOSITION (PART 3)



Example: gear box ECU

HW (actuator)

HW + SW (ECU)

HW (actuator) 36

ISO 26262 ORIGINS AND ASIL DECOMPOSITION (PART 3)

37

ISO 26262 ORIGINS AND ASIL DECOMPOSITION (PART 3)

 

ASIL = Automotive Safety Integrated Level ASIL level is determined according to 3 criteria: 1. Severity 2. Probability of exposure 3. Controllability

38

ISO 26262 ORIGINS AND ASIL DECOMPOSITION (PART 3)

1. SEVERITY

39

ISO 26262 ORIGINS AND ASIL DECOMPOSITION (PART 3)

2. PROBABILITY OF EXPOSURE

40

ISO 26262 ORIGINS AND ASIL DECOMPOSITION (PART 3)

3. CONTROLLABILITY

41

ISO 26262 ORIGINS AND ASIL DECOMPOSITION (PART 3)



ASIL is determined through the following table:



QM < A < B < C < D, with QM = Quality Management 42

ISO 26262 ORIGINS AND ASIL DECOMPOSITION (PART 3)



Examples: ASIL A:





Loss of wiper

ASIL B:



 

Loss of lights Reverse lighting of the indicators

ASIL C:



 

Unexpected increase of velocity Unexpected opening of electrical doors while driving

ASIL D:



 

Unexpected airbag explosion Blocking of direction column while driving

Note : ASIL can be different from one car manufacturer to another

SIL

43

ISO 26262 ORIGINS AND ASIL DECOMPOSITION (PART 3) – SLIDE FROM N. BECKER Probability of exposure

S

Every time

Car accident gravity

E

Sometimes

C

E

Probability to be exposed to a life situation where a car accident can potentially occur

C

Risk reduction due to the controllability of the situation

not acceptable

Rarely QM

Safety class (ASIL A)

Safety class (ASIL B)

Supplementary risk reduction due safety class (ASIL) = Liability or non Systematic failure

Very rarely Residual risk

acceptable Residual risk

Extremely unlikely

Gravity

Low

Medium

Dangerous

Catastrophic

44

ISO 26262 ORIGINS AND ASIL DECOMPOSITION (PART 3)

45

ISO 26262 ORIGINS AND ASIL DECOMPOSITION (PART 3)



ASIL decomposition - Example: undesired lights switch off – ASIL B 

There are 4 different ECU to manage the lights:    

Motor engine control – direct command to switch off the lights Body controller – command to switch off the lights through CAN message Top column - command to switch off the lights through CAN message Light sensor - command to switch off the lights through CAN message Undesired lights switch off ASIL B

Motor engine control ASIL B



Body controller ASIL B

Top column

Light sensor

ASIL B

ASIL B

If one of these ECU decides to switch off the lights, the lights are switched off. So there is no possibility to decrease the ASIL attributed to each ECU.

46

ISO 26262 ORIGINS AND ASIL DECOMPOSITION (PART 3)



ASIL decomposition - Example: undesired blocking of direction column while driving 

There are 4 different ECU to manage the direction:    

Electrical anti-theft – direct command of direction Body controller – blocking command can be sent to electrical anti-theft Hand-free door opening – Manages power supply of electrical anti-theft Brake control unit – blocks direction if speed is equal to zero Undesired blocking command of direction ASIL D

Electrical anti-theft ASIL D



Body controller ASIL A

Hand free door opening ASIL A

Brake control unit ASIL A

Only electrical anti-theft can directly block the direction. The other ECU cannot alone decide to block the direction. So ASIL attributed to the 3 ECU can be decreased. 47

ISO 26262 ORIGINS AND ASIL DECOMPOSITION (PART 3)

Usually suppliers avoid having ASIL higher than B for SW 

Example: Airbag  



Airbag P8&20

Example: Electrical door module  



ASIL D : Unexpected airbag explosion  ASIL B for software. Software alone cannot launch airbag explosion.

ASIL C : Unexpected opening of electrical doors while driving  ASIL B for software. Software alone cannot open the door.

Example : Power steering 

ASIL D  ASIL B

TSC P8

ASIL D -> 2B

ASIL C P578

48

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)



After system specification, the safety requirements are decomposed in Hardware and Software requirements.



In the following part, we will see how software safety requirements are managed.

49

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

Notes before going further 





On the ISO 26262 tables: ‘++’ means highly recommended ‘+’ means recommended 'o' means no recommendation Due to the voluntary freedom left by the writers, often only requirements marked as ‘++’ are followed. Example: As a reminder, the ISO 26262 standard concerns only ASIL A, B, C and D. ASIL QM is not concerned.

50

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 5: General topics for the product development at the software level

51

ISO26262 STANDARD FOR SOFTWARE Part 6 – Clauses 5 to ISO 26262 FOR SOFTWARE (PART 6 –11 CLAUSES 5 TO 11)

Work :

Groups of 2 persons

20’

Instructions: Describe briefly each step of the V cycle Targets: ISO 26262 refresh Timing : Description: 15 minutes Restitution: 5 minutes

52

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

6.5: Software development process definition and tailored to the context - Coding, modeling and tools guidelines - Schedule of the software safety activities, synchronized with system (safety) activities. 6.6: Software requirement elicitation from Technical Safety Concept, Hardware Software Interface, system…, copy / reformulate / refine them. 6.7: Software architecture: decomposition in layers and modules, interface definitions, tasks definition, safety mechanisms description according to software safety requirements and architecture analysis in order to get evidences that safety mechanisms are correctly in place to stop hardware or software fault propagation 6.8: Detail the design (Detailed Design Specification) and its implementation following coding rules.

53

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

6.9: Software module testing based on design requirements and with structural coverage targets. 6.10: Integration of the modules to check the correct behavior of the software once all modules integrated: CPU load, RAM consumption, flash consumption, stack consumption, timing constraints etc. Integration testing is based on architecture requirements and with structural coverage targets. 6.11: Test of software compliancy with software safety requirement. Requirement coverage is monitored.

54

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 5: General topics for the product development at the software level 

The objective of this clause are:  



To ensure a suitable and consistent software development process To ensure a suitable software development environment

Inputs:    

Qualified software tools available Design and coding guidelines for modelling, design and programming languages Guidelines for the application of methods Guidelines for the application of tools

55

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 5: General topics for the product development at the software level 

What is expected in this part: To have guidelines on the methods and tools used To make a choice of the programming language:

     

Clear syntax and semantics Can be used for real time Modularity, abstraction and structured construction Application of table 1

56

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 5: Complement – Language choice 

Criteria to be taken into account:   



Additional criteria:    



Unambiguous language – Existence of standard definition Strong typing Supports for the real-time aspects and error handling Maturity Easy to learn Experience of the company and developers Existence of tools

To meet these criteria, guidelines and coding rules should exist and followed. 

The assembly code can be used when the use of a high-level language is not possible, for example Interface with the hardware, interrupt handling...

57

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 5: Complement – Cyclomatic complexity Example:



Structural complexity (Mac Cabe)    

n: number of nodes e: number of branches v: cyclomatic complexity v = e – n + 2 (if 1 entry point and 1 exit point)

if (x > 5) { while (x50

Simple function – Low risk More complex function – Medium risk Complex function – High risk Not stable function – Very high risk

HIS

Application ISO 9126

QA C metrics

Examples 61

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 5: General topics for the product development at the software level 

Work products     

Documentation of the software development environment Safety plan (refined) Software verification plan Design and coding guidelines for modelling and programming languages Tool application guidelines

62

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 6: Specification of software safety requirements

63

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 6: Specification of software safety requirements 

Inputs    



Technical safety concept System architecture design specification Hardware-software interface (HIS) specification Documentation of the software development environment

Further supporting information  

Hardware design specification Specification of non-safety functions

64

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 6: Specification of software safety requirements 

Software safety requirements apply to software components which an error can lead to an undesired event. 



From the undesired event, determination of the software modules that are impacted.

Software safety requirements are derived from system safety requirements. 

For example if system requirement is: “Output X shall not open the relay when driving" can become applied to the software: “Software shall not drive output X when variable SpeedVehicle is different from 0.”



Hardware Software Interface must be completed if necessary



Other software modules unrelated to safety must be described.

65

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 6: Specification of software safety requirements 

Work products   

Software safety requirements specification Hardware-software interface specification (refined) Software verification report

66

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 7: Software architectural design

67

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 7: Software architectural design 

Inputs   



Documentation of the software development environment Hardware-software interface specification Software safety requirements specification

Further supporting information    

Technical safety concept System architecture design specification Qualified software components available Specification of non-safety functions

68

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 7: Software architectural design Software architecture is almost half of the part 6 

What is expected in this part: (1/6) 

Application of table 2

69

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 7: Software architectural design 

What is expected in this part: (2/6)   

Bidirectional traceability between software safety requirements and software architecture requirements. The requirements of software architecture must be feasible, testable and maintainable Application of table 3

70

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 7: Software architectural design 

What is expected in this part: (3/6) Static architecture description

 

Software layers, internal interfaces, external interfaces

Dynamic architecture description

 

Operation and real-time behavior, priority tasks, timing constraints...

Characterization of software modules

 

New, reused with changes, reused without modification

The new or modified software components must be developed in compliance with the standard ISO 26262 Reused components without modification must be qualified according to the standard ISO 26262 (Part 8 - Clause 12) Each software component should be developed in accordance with the highest level of ASIL allocated.

   

If a software component shall handle ASIL A and ASIL B, it must be developed in accordance with an ASIL B. 71

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 7: Software architectural design 

What is expected in this part: (4/6) Either all the software is developed according to the highest ASIL level attributed or safety-related parts of the software are developed “Freedom from interference”. Analysis of software architecture to identify or confirm the parts of the software related to safety. Depending of the results of the safety-oriented analyses at the software architecture level, safety mechanisms for error detection. Examples:

         

Range check of input and output data Plausibility check (assertion, comparing signals from different sources…) Detection of data errors (error detecting code, multiple data storage) Monitoring of program execution (logical and/or temporal) using ASIC or another software Temporal monitoring of program execution Diverse redundancy 72

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 7: Complement – Memory management 

MPU: Memory Protection Unit



Many microcontrollers offer the possibility to protect configured memory zones.

Example

73

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 7: Complement – Memory management If properly configured, a system using MPU can manage “freedom from interference” for memory. When MPU is not used, other methods must be put in place to be compliant with “freedom from interference”. For example: mirroring of critical data. 

Consequence for a microcontroller without MPU:  



FFI example

Tasks work in the same memory space (direct access to the memory) Errors in memory access are not automatically detected by microcontroller and it is possible to erase code (if code is executed from RAM) or data of another task. Example: int tab[100]; for (i=0;i 10

Tests to do to check the behavior of the function: * Call of the function with n = 3 * Call of the function with n = 12 for example * Call of the function with another value of n, 10 for example.

Then function returns 10 Else Function returns 0 EndIf 94

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 9: Complement – Unit tests 

How to do the good tests and how to limit the tests? Equivalence classes: Partitioning of space of values in equivalence classes Limitation of the number of test cases Complete test set: a try in each class

  



Example: let’s take D, an interval of integer between 0 and 10 One partition for correct values



 One value between 0 and 10 (and only one)

Two partitions for incorrect values:

  

Negative value Value higher than 10

 3 tests are necessary

95

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 9: Complement – Unit tests

1. « Functions » coverage measures the number of functions (in term of software) that are called during tests compared with the total number of functions. 2. « Statement Block » coverage measures the number of lines of code executed during tests compared with the total number of lines of code. 3. « Decision » coverage measures the number of decisions (if, switch…) executed during tests compared with the total number of decisions. 4. « MC/DC : Modified Condition / Decision Coverage » measures the fact that a minimum set of conditions in decision have been performed. 96

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 9: Complement – Unit tests

1/ « Function » void ReadBatteryVoltage(tBYTE *VBat) { … } tBYTE SpeedDisplay(void) { … }

97

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 9: Complement – Unit tests

2/ « Statement block » void Test_Value(void) { if ((x > 1) && (y == 0)) { z = z / x; } if (z == 2) || (y > 1) { z = z + 1; } }



With x = 2, y = 0 and z = 4 statement block coverage is equal to 100%. 98

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 9: Complement – Unit tests

3/ « Decision » if ((A == TRUE) && (B == TRUE)) { … }

It requires 2 tests to get 100% Decision coverage: - One test to set the condition at TRUE - One test to set the condition at FALSE Example: (A,B) = (TRUE,TRUE) et (A,B) = (TRUE, FALSE) 

99

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 9: Complement – Unit tests

4/ MC/DC if ((A == TRUE) && (B == TRUE)) { … }

3 tests are necessary to get 100% MC/DC coverage:   

(A,B) = (TRUE, TRUE) (A,B) = (FALSE, TRUE) (A,B) = (TRUE, FALSE)

if ((A == TRUE) && (B == TRUE) && (C == TRUE)) { … } How many tests are necessary here to get 100% coverage?

100

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 9: Complement – Unit tests 

Unit tests objectives at each delivery

- The aim is not to get 100% at each metric but to have a clear objective taking into account complexity of the product and safety requirements. - 100% coverage does not mean that there is no bug. 101

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 9: Complement – Unit tests



Unit tests are usually performed on computer.

Unit tests coverage

Unit tests coverage 102

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 9: Software unit verification 

Work products  

Software verification specification Software verification report

103

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 10: Software integration and verification

104

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 10: Software integration and verification 

Inputs       



Hardware-software interface specification (refined) Software architectural design specification Safety analysis report Dependent failures analysis report Software unit implementation Documentation of the software development environment Software verification specification

Further supporting information 

Qualified software components available 105

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 10: Software integration and verification 

What is expected in this part: (1/3) Integration must be done step by step, module after module. Integration tests must be planned, specified and executed. Application of table 10 in order to ensure:

       

Compliance with software architecture Compliance with the HSI The verification of the tested function The robustness The resources are sufficient

106

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 10: Software integration and verification 

What is expected in this part: (2/3) 

Apply the table 11 to make sure to write the appropriate test cases

107

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 10: Software integration and verification 

What is expected in this part: (3/3) Assess the completeness of integration tests and check for unwanted functions

   

Measurement of test coverage Traceability between integration tests and software architecture requirements Application of table 12

108

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 10: Software integration and verification 

The test environment must as close as possible to the target 



If not, the differences between the test environment and the target must be evaluated in order to specify additional tests to cover the differences.

The unspecified functions present (debug and instrumentation for example) must not deteriorate compliance with the safety requirements

109

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 10: Complement – Integration tests 

Integration tests check that software modules developed independently work together.



Different methodologies are possible: layer integration, stack integration, « big-bang » integration.



Integration tests allow validation of dynamic architecture and interfaces between software components.

110

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 10: Complement – Integration tests 

Once software completely assembled, a set of tests must be realized:           

CPU load measurement Stack sizes measurement Memory sizes RAM/Flash/EEPROM Shared variables Tasks, sequences, interrupts (if periodical) periodicity Tasks, sequences and interrupts durations Critical sections and priority inversions duration Performances Start-up duration Stop duration Specific project performances

Integration tests results

111

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 10: Software integration and verification 

Work products   

Software verification specification (refined) Embedded software Software verification report (refined)

112

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 11: Testing of the embedded software

113

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 11: Testing of the embedded software 

Inputs     



Software architectural design specification Software safety requirements specification Embedded software Documentation of the software development environment Software verification specification (refined)

Further supporting information    

Technical safety concept System architecture design specification Integration and test strategy Integration test report 114

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 11: Testing of the embedded software 

What is expected in this part: (1/3)   

Verification of software safety requirements must be planned, specified and executed. The tests must be performed on target. Application of table 13

115

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 11: Testing of the embedded software 

What is expected in this part: (2/3) 

Application of table 14 to provide evidence that the embedded software fulfils the software requirements as required by their respective ASIL

116

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 11: Testing of the embedded software 

What is expected in this part: (3/3) 

Tests cases shall be derived using the methods as listed in Table 15

117

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)

PART 6 / CLAUSE 11: Testing of the embedded software 

Work products  

Software verification specification (refined) Software verification report (refined)

Validation strategy 10-26

118

ISO 26262 FOR SOFTWARE (PART 6 – CLAUSES 5 TO 11)



ISO 26262:2018:

http://docinfogroupe.inetpsa.com/ead/doc/ref.02013_19_00646/v.vc/fiche



ISO 26262-6:2018 checklist:

http://docinfogroupe.inetpsa.com/ead/doc/ref.DMOV_ELE06_0050/v.vc/fiche



Suppliers compliance matrix FNR1

FNR2

FNR3

119

ISO 26262 STANDARD FOR SOFTWARE: CHAPTER PLAN

      

ISO 26262 origins and ASIL decomposition (Part 3) Requirement management (Part 8 - Clause 6) Configuration management (Part 8 - Clause 7) ISO 26262 for software (Part 6 – Clauses 5 to 11) ISO 26262 for software (Part 6 – Annex A to E) Tools qualification (Part 8 – Clause 11) Software component qualification (Part 8 – Clause 12)

120

ISO 26262 FOR SOFTWARE (PART 6 – ANNEXES)



Annex A: Overview of and workflow of management of product development at the software level



Annex B: Model-based development approaches



Annex C: Software configuration



Annex D: Freedom from interference between software elements



Annex E: Application of safety analyses and analyses of dependent failures at the software architecture level 121

TOOLS QUALIFICATION (PART 8 – CLAUSE 11)



« Tool Impact » (TI): a defect in the tool can have an impact on safety  



TI1: No impact (justification must be given) TI2: Other cases

« Tool error Detection » (TD): it is possible to estimate the probability to detect a defect   

TD1: high confidence that a defect is detected TD2: medium confidence TD3: low confidence

122

TOOLS QUALIFICATION (PART 8 – CLAUSE 11)



TCL1: no qualification and nothing to put in place Tools qualification





TCL2

TCL3

123

SOFTWARE QUALIFICATION (PART 8 – CLAUSE 12)



The specification of the software component to qualify must include:      



Requirements (including behavior in case of failure, time response… The description of the configuration The description of the interfaces The behavior in case of improper use The description of the known bugs …

The qualification requires to show   

The software component covers requirements The component covers the nominal mode and behavior in case of failure That no known bug can cause a non-compliance with the safety requirements.

124

SOFTWARE QUALIFICATION (PART 8 – CLAUSE 12)



Qualification file must contain the following information:      

A unique identifier of the software component A unique configuration of the software component The person or organization who conducted the qualification The environment used for the qualification The results of the verifications The maximum ASIL level where the software component can be use

SW Component Qualification

125

ISO 26262 FOR SOFTWARE / SYNTHESIS

 

ISO 26262 standard describes a complete process for the control of the implementation of a system with safety requirements. The standard proposes:  



 

A list of the documents to produce; A list of the requirements at each step.

In addition, it gives an important place to quality of the processes and validation activities (including the verification that the safety requirements are correctly implemented). All requirements of ISO 26262 for ASIL A and B level are compatible the state of art in automotive. For the case of ASIL C and D development constraints are strongest, but these cases are much fewer due to the possibility of choice of safety concept to reduce the level of ASIL applied to software modules (e.g. redundancy HW/SW, E-gas monitoring concept...). 126

CRITICAL SOFTWARE FOLLOW-UP



DIA and Software Guidelines



Software development rules



Refresh: ISO 26262 standard for software



ISO 26262 checklist



Supplier assessment



Conclusion

127

ISO 26262 CHECKLIST





Observations: 

Difficult to follow suppliers based on work products.



How to be sure that the work products presented by the supplier answers safety requirements.

Necessity to have an overview of the work of the suppliers with the possibility to go further if necessary.

 Creation of the ISO 26262 checklist 128

ISO 26262 CHECKLIST





Compared with software development rules, it is more difficult to judge point one by one independently. 

ISO 26262 is based on recommendations but does not impose methodology.



Some recommendations are dependant to the ASIL.

ISO 26262 checklist is also included in document DMOV_ELE06_0050 but in another sheet: http://docinfogroupe.inetpsa.com/ead/doc/ref.DMOV_ELE06_0050/v.vc/fiche

Template

Example 129

ISO 26262 CHECKLIST

Initiation of product development at the software level Specification of SW safety requirements SW architectural design Software unit design and implementation SW unit testing Software integration and testing Verification of SW requirements Annex - C Part 8 - Confidence in the use of software tools Part 8 - Qualification of software components



Safety activities description



Safety schedule



Modeling language



Coding language



Software complexity



Coding guidelines



Tooling guidelines 130

ISO 26262 CHECKLIST

Initiation of product development at the software level Specification of SW safety requirements SW architectural design Software unit design and implementation SW unit testing Software integration and testing Verification of SW requirements Annex - C Part 8 - Confidence in the use of software tools Part 8 - Qualification of software components



Software safety parts identification



Software safety requirements



ASIL level(s) identification



Hardware Software Interface document complete



Software safety requirements review

131

ISO 26262 CHECKLIST

Initiation of product development at the software level Specification of SW safety requirements SW architectural design Software unit design and implementation SW unit testing Software integration and testing Verification of SW requirements Annex - C Part 8 - Confidence in the use of software tools Part 8 - Qualification of software components



Architecture description: static, dynamic, components, interfaces, scheduling, interrupts etc.



Safety analysis



Freedom from interference



Safety mechanisms



Simulation, prototyping



Control flow, data flow 132

ISO 26262 CHECKLIST

Initiation of product development at the software level Specification of SW safety requirements SW architectural design Software unit design and implementation SW unit testing Software integration and testing Verification of SW requirements Annex - C Part 8 - Confidence in the use of software tools Part 8 - Qualification of software components



Design description



Design review



Code implementation



Code review



Simulation, prototyping



Control flow, data flow



Static code analysis 133

ISO 26262 CHECKLIST

Initiation of product development at the software level Specification of SW safety requirements SW architectural design Software unit design and implementation SW unit testing Software integration and testing Verification of SW requirements Annex - C Part 8 - Confidence in the use of software tools Part 8 - Qualification of software components



Methodology to create unit tests



Unit test review



Structural coverage



Test environment



Resource consumption

134

ISO 26262 CHECKLIST

Initiation of product development at the software level Specification of SW safety requirements SW architectural design Software unit design and implementation SW unit testing Software integration and testing Verification of SW requirements Annex - C Part 8 - Confidence in the use of software tools Part 8 - Qualification of software components



Methodology to create integration tests



Integration test review



Structural coverage



Test environment



Resource consumption

135

ISO 26262 CHECKLIST

Initiation of product development at the software level Specification of SW safety requirements SW architectural design Software unit design and implementation SW unit testing Software integration and testing Verification of SW requirements Annex - C Part 8 - Confidence in the use of software tools Part 8 - Qualification of software components



Test environment



Requirements coverage



Tests result

136

ISO 26262 CHECKLIST

Initiation of product development at the software level Specification of SW safety requirements SW architectural design Software unit design and implementation SW unit testing Software integration and testing Verification of SW requirements Annex - C Part 8 - Confidence in the use of software tools Part 8 - Qualification of software components



Configuration data management



Calibration data management

137

ISO 26262 CHECKLIST

Initiation of product development at the software level Specification of SW safety requirements SW architectural design Software unit design and implementation SW unit testing Software integration and testing Verification of SW requirements Annex - C Part 8 - Confidence in the use of software tools Part 8 - Qualification of software components



Process to qualify tools



Tools planned to be qualified

138

ISO 26262 CHECKLIST

Initiation of product development at the software level Specification of SW safety requirements SW architectural design Software unit design and implementation SW unit testing Software integration and testing Verification of SW requirements Annex - C Part 8 - Confidence in the use of software tools Part 8 - Qualification of software components



Process to qualify software components



Software components planned to be qualified

139

ISO 26262 CHECKLIST

ISO 26262 CHECKLIST HELP 

A document explains the expectation, evaluation criteria and examples:

http://docinfogroupe.inetpsa.com/ead/doc/ref.01272_19_01633/v.vc/fiche 

This document can help most of the time to evaluate supplier’s answer but if it is not enough, software safety experts can intervene on demand. 140

ISO 26262 CHECKLIST



Other sheets in DMOV document 

WP Mapping



Answer to security rules



Evaluation Status



Metrics



Graph progress



Planning Info

141

ISO 26262 checklist Exercise ISO 26262 CHECKLIST

Work: Groups of 2 persons

60’

Instructions: Check supplier answers of the 4 documents

Timing:

Documents review: 30 minutes Restitution: 30 minutes

To go further: Open discussion with examples taken from trainees experience. 142

ISO 26262 checklist ISO 26262 CHECKLIST / SYNTHESIS

We have seen that

Synthesis



61 questions that the suppliers must answer



The supplier stays responsible for its development



Supplier’s answer must be followed until the end of the project



A document exists to help to analyze supplier’s answer



For more complicate cases, software safety experts can intervene.

143

CRITICAL SOFTWARE FOLLOW-UP



DIA and Software Guidelines



Software development rules



Refresh: ISO 26262 standard for software



ISO 26262 checklist



Supplier assessment



Conclusion

144

Software audit SUPPLIER ASSESSMENT



In some cases, a software audit can be useful for: 

New supplier



Supplier with which we have bad lessons learned



Software with high ASIL level (>= ASIL B)



Difficult project: many subcontractors, high number of requirements from PSA, high number of software team members



Supplier which has delivered with quality problems: high number of defects, several deliveries to converge, delay of the delivery

145

Software audit SUPPLIER ASSESSMENT



Software audit grid:

http://docinfogroupe.inetpsa.com/ead/doc/ref.DMOV_ELE06_0073/v.vc/pj





Software audit is similar to ASPICE assessment. 

Process check



Documentation check

Technical points are also included in the assessment 

Document DMOV is integrated in the audit grid.

Software audit grid

SW audit example

SW audit example

146

CRITICAL SOFTWARE FOLLOW-UP



DIA and Software Guidelines



Software development rules



Refresh: ISO 26262 standard for software



ISO 26262 checklist



Supplier assessment



Conclusion

147

TRAINING CONCLUSION CONCLUSION





After this training: 

You know PSA process to follow ECUs with software safety



You are able to quote suppliers’ answers about software development rules and ISO 26262 checklist. 

You can refer to documents written to help to analyze suppliers’ answers



For most complicate cases, do not hesitate to ask the software expertise network

Synthesis

In any cases, suppliers are responsible for their developments 148

THANK YOU FOR YOUR ATTENTION

An online satisfaction assessment questionnaire will be offered to you at the end of this session. The email you will receive will direct you to your Learn’in summary and give you access to the Evaluate button. This button is already available if you wish to complete this questionnaire at the end of the session before leaving.

Please answer the questionnaires. Your returns remain anonymous and allow continuous progress.

CRITICAL SOFTWARE FOLLOW-UP