Template Document DMOV_ELE06_0050

Project document 01552_17_06929

DIA

Software development rules and software safety mana

Version (DocInfo) Date Author Mod

V1 26/10/2017 Malik CHAFFI Creation for the K5 EPS project bid
nd software safety management

Modifications
on for the K5 EPS project bid
 Software development rules and software safety managem
This document is applied to all embedded software developed for PSA. The supplier must apply each requirement. Howeve
an alternative solution or explain the reason why it cannot fulfill the requirement. The aim is not to get all requirements appli
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 les
ensure the robustness of its product.
Even if PSA answer is "OK", the supplier stays responsible of its technical choices, implementation and tests.

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
- "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 informations on implementation and va

For RFQ, only columns C, E, H and J must be filled.

e safety management
ach requirement. However the supplier can propose
get all requirements applied but to get a consistent set

example based on its lessons learned, which can

n and tests.

- "LC : Largely Compliant" - "PC : Partially Compliant"

irement is planned.
ed.

nt is planned.

on implementation and validation progression.


Project:
Date:
Requirement
REGLESSW-ST-5-003(1)
REGLESSW-ST-5-002(2)
REGLESSW-ST-5-001(1)
REGLESSW-ST-61-001(2)
REGLESSW-ST-61-002(2)
REGLESSW-ST-62-001(2)
REGLESSW-ST-62-003(2)
REGLESSW-ST-63-001(1)
REGLESSW-ST-63-002(3)
REGLESSW-ST-63-003(3)
REGLESSW-ST-63-004(0)
REGLESSW-ST-63-005(0)
file:///conversion/tmp/activity_task_scratch/753102565.xlsx
COMPLIANCE MATRIX Page 5 to 55
Answer to PSA SW dev. rules
Please see sheet "Explanations" to fill correctly this document
Supplier answer
Description Implementation Verification &
Conformity Status Answer Conformity Status
Status Validation Status
Generic rules
The reason for the last reset must be memorized and accessible to the supplier.
A mechanism must be developed to detect microcontroller continuously resetting
(succession of wake up / reset).
Once detected, the associated behaviour should:
• First assure security,
• Then protect the rest of the car against battery failure,
• Last avoid system failure
For any usage of CRC mechanism, the choice of the polynomial (size and degree) should be
justified.
Memory management
Tests during initialisation
After wake up, RAM must be tested.
This test could consist in writing then reading a pattern (0x55AA classically), in every RAM
address. In case of error, a reset must be forced.
If the complete test is not compatible with the init timing required for the component, test can
be reduced to critical variables.
After wake up, flash must be tested.
This test could consist in reading flash and calculate a CRC, which CRC must be equal to a
CRC already written in flash.
If the complete test is not compatible with the init timing required for the component, test can
be reduced to critical code areas.
RAM must be initialized at each wake up with a justified value.
If this is not possible (RAM_NO_INIT mechanism for example), supplier must justify its
choice.
Supplier must provide to PSA the list of data stored in the non initialized memory.
If microcontroller contains some non used FLASH or ROM, this one must be initialized with
the code of an instruction forcing a reset.
Executable code loading from FLASH, EEPROM or ROM to RAM must be justified and
protected (specific CRC for example).
EEPROM data blocks must be protected with CRC. This CRC must be calculated at each
writing and checked at each reading. Every non protected area must be justified.
Supplier must manage two constraints :
- Ageing EEPROM memory cells after many writings (number of writings depends upon the
EEPROM used).
- Power off during writing in EEPROM
Supplier will provide to PSA mechanisms used to manage these two cases.
A similar mechanism must be put in place in case of EEPROM emulation in flash.
Copying an EEPROM block into RAM memory, in order to increase response time at runtime
or to reduce EEPROM access is possible.
Supplier will provide to PSA mechanism used to guarantee a safe behavior at the init time
after the reset.
A similar mechanism must be put in place in case of EEPROM emulation in flash.
Dynamic memory allocation is forbidden.
If microcontroller allows ECC (Error Correction Code) management in flash and/or RAM it
must be activated.
Interrupts management
05/10/2024

REGLESSW-ST-7-001(1)
REGLESSW-ST-7-002(0)
Requirement
REGLESSW-ST-7-003(3)
REGLESSW-ST-7-004(0)
REGLESSW-ST-7-005(1)
REGLESSW-ST-7-006(1)
REGLESSW-ST-7-007(1)
REGLESSW-ST-7-008(0)
REGLESSW-ST-7-009(0)
REGLESSW-ST-8-001(4)
REGLESSW-ST-8-002(2)
REGLESSW-ST-8-003(3)
REGLESSW-ST-8-004(0)
REGLESSW-ST-8-005(0)
REGLESSW-ST-8-006(0)
REGLESSW-ST-8-007(0)
REGLESSW-ST-9-001(2)
REGLESSW-ST-9-002(1)
REGLESSW-ST-9-003(0)
REGLESSW-ST-10-001(0)
REGLESSW-ST-10-002(0)
file:///conversion/tmp/activity_task_scratch/753102565.xlsx
COMPLIANCE MATRIX Page 6 to 55
Answer to PSA SW dev. rules
Supplier answer
An interrupt function must be associated with every interrupt vectors. If an interrupt is not
used, it is associated with a function forcing a reset and keeping a trace of the reset
A non used interrupt must be masked Description
A protection mechanism must be developed against inopportune interrupts (more than x
execution of the interrupt in less than y ms) to protect the execution of the rest of the
program.
This mechanism is mandatory when the interrupt is due to an external event (edge on an
input, network message, …)
This mechanism must not be developed for critical input (i.e. input directly linked with a
feared event).
In case of error detection, the supplier must provide a safe behavior of microcontroller (reset,
IT inhibition, …)
Non maskable interrupt usage (except for the watchdog) must be justified. Especially, every
parts of code developed to normally run with masked interrupts must be designed to be
interruptible by these non maskable interrupts.
Changing interrupt priority at runtime is forbidden.
Executing parts of code with interrupts masked or partially masked must be justified and be
as short as possible (typically 50µs). Supplier must calculate all critical sections in its code
and must guarantee that every real time requirements are fulfilled.
Possibility to enable disable interrupt « by cascading » must not be used:
This example must not be followed :
DISABLE IT1 // IT1 disabled
… // code execution
DISABLE IT2 // IT2 disabled
… // code execution
ENABLE IT // All ITs enabled
Use of nesting of disable and enable interrupts must be justified. In case of its use, a counter
must be used: counter must be incremented each time interrupts are disabled and
decremented each time interrupts are enabled. Interrupts will be really enabled when counter
will be equal to 0.
Use of interrupt nesting must be justified.
Microcontroller management
If microcontroller has an auto test, this mode must be used
Ports configuration registers must be reprogrammed or checked periodically. In case of error
detected, supplier must propose a safe mode (reset or register reconfiguration for example).
Definition of CPU modes (Sleep, run, standby, ...) and transition (IT mask, Watchdog, ...)
must be provided. In particular, supplier must justify the link between theses modes and
supply/life phase requirements from PSA.
Outputs must be refreshed periodically with a justification of the periodicity.
Inputs must be read periodically with a justification of the periodicity.
All communications between microcontroller and external components like ASIC or another
microcontroller must be described. In particular, a specific behavior must be described in
case of loss of communication.
Low level software depending on microcontroller must be reviewed and approved by
microcontroller maker.
Stack management
Static computation of maximum usage of the stack must be performed and results must be
provided to PSA. Supplier must also provide computation method to PSA.
Checking on real case of stack usage is required (simulation with representative network
load and interrupt usage).
During the development, PSA must be able to access to the maximum usage of the stack via
diagnostic.
Stack overflow detection mechanism is required, with a forced reset in case of detection.
Watchdog management
A Watchdog mechanism (hardware and/or software) is required.
Watchdog mechanism must be described to PSA (simple, windowed. Period and localization
into the code of the WD counter update).
05/10/2024

REGLESSW-ST-10-003(0)
Requirement
REGLESSW-ST-11-001(1)
REGLESSW-ST-11-002(2)
REGLESSW-ST-11-003(1)
REGLESSW-ST-11-004(2)
REGLESSW-ST-11-005(1)
REGLESSW-ST-11-006(0)
REGLESSW-ST-11-007(0)
REGLESSW-ST-15-000(0)
REGLESSW-ST-12-003(1)
REGLESSW-ST-12-004(0)
REGLESSW-ST-12-005(0)
REGLESSW-ST-12-006(0)
REGLESSW-ST-12-007(0)
REGLESSW-ST-12-008(0)
REGLESSW-ST-12-009(2)
REGLESSW-ST-12-010(0)
REGLESSW-ST-13-001(1)
REGLESSW-ST-13-002(1)
REGLESSW-ST-13-003(1)
REGLESSW-ST-13-004(0)
REGLESSW-ST-13-005(0)
REGLESSW-ST-14-001(1)
REGLESSW-ST-14-002(1)
REGLESSW-ST-14-003(2)
file:///conversion/tmp/activity_task_scratch/753102565.xlsx
COMPLIANCE MATRIX Page 7 to 55
Answer to PSA SW dev. rules
Supplier answer
Supplier must never refresh watchdog in a loop without using a time-out.
Operating system
Function re-entry (calling the same function from two different tasks or from a task and an
Description
interrupt at the same time) should not be used. If used, this must be justified.
Supplier must describe software behavior in case of high CPU load, whereas watchdog is
still refreshed (multiplication by two of CAN received frames frequency or/and limp home
mode application for examples).
Conception must assure that no deadlock will occur.
Deadlock detection mechanism is required. In case of dead lock detection, the system must
stay in a safe state. A reset can be a solution.
The system should not dynamically allocate operating system elements: tasks, events,
queues,...
All shared variables (between pre-emptive tasks, between tasks and interrupts or between
interrupts in case of nesting of interrupts) must be listed and secured if necessary.
In case of use of pre-emptive operating system, a mechanism must be put in place to avoid
priority inversion like Priority Inheritance Protocol (PIP) or Priority Ceiling Protocol (PCP).
Software safety
In case of ASIL A or more, sheet "ISO 26262 Checklist" must also be filled by the supplier.
Coding rules
Pointer use is forbidden in functional layer and must be justified for the remaining software.
Address computation on pointers must be justified.
Casting of pointer must be justified.
Use of function pointer must be justified.
Before any array access, the addressing range must be checked.
Before any division, the denominator must be tested different from zero.
Before any pointer access, the pointer value must be tested different from NULL.
Arithmetic computation should not use implicit cast, in order to avoid, among other problem,
data overflow.
Variable type used in the software must be explicitly defined (not relying on the
microcontroller architecture).
Software should be compiled with every warning activated. The remaining warning should be
justified.
For every function that returns an error code, the returned value must be tested.
Every loop on an external condition should be protected with a timeout.
Software metrics must be calculated (examples: number of lines of code vs number of lines
of comments, cyclomatic complexity, Myer’s interval, nesting of conditions, number of logical
operator, number of lines of code …). For each metric, thresholds must be defined. Each
result beyond thresholds must be justified.
Used programming rules must be described and validated by PSA.
A mechanism must be developed to assume respect of the programming rules:
• using Tools (compiler option or QAC tool for example) for automatic verification
• by code review for the others (comments or naming rules for example)
The supplier must prove that lessons learned from PSA projects or other car makers are
taken into account. In particular, no major defect encountered in PSA projects, must be
present in a new project for PSA.
This proof can be a code review, new tests, conception rules...
05/10/2024
 Number ISO 26262 reference

Initiation of product development at the software level

ISO26262-6.5_10 5.4.1 & 5.4.2

ISO26262-6.5_20 5.4.4

ISO26262-6.5_30 5.4.6
ISO26262-6.5_40 5.4.7
ISO26262-6.5_50 5.4.7
ISO26262-6.5_60 5.4.7
Specification of SW safety requirements
ISO26262-6.6_10 6.4.1
ISO26262-6.6_20 6.4.2
ISO26262-6.6_30 6.4.3
ISO26262-6.6_40 6.4.4
ISO26262-6.6_50 6.4.8
SW architectural design
ISO26262-6.7_10 7.4.1
ISO26262-6.7_20 7.4.2

7.4.3 Table 3
ISO26262-6.7_30 7.4.4
7.4.5
7.4.3
ISO26262-6.7_40
Table 3
ISO26262-6.7_50 7.4.3 Table 3
ISO26262-6.7_60 7.4.3 Table 3
ISO26262-6.7_70 7.4.3 Table 3
ISO26262-6.7_80 7.4.5
ISO26262-6.7_90 7.4.6

ISO26262-6.7_100 7.4.6

7.4.12
ISO26262-6.7_110
7.4.13
ISO26262-6.7_120 7.4.11

ISO26262-6.7_130 7.4.14

ISO26262-6.7_140 7.4.15

ISO26262-6.7_150 7.4.18 Table 6

ISO26262-6.7_160 7.4.18 Table 6

ISO26262-6.7_170 7.4.18 Table 6

ISO26262-6.7_180 7.4.18 Table 6

ISO26262-6.7_190 7.4.18 Table 6

ISO26262-6.7_200 7.4.17
Software unit design and implementation
ISO26262-6.8_10 8.4.2 Table 7
ISO26262-6.8_20 8.4.3
ISO26262-6.8_30 8.4.4 Table 8

ISO26262-6.8_40 8.4.4 Table 8

ISO26262-6.8_50 8.4.4 Table 8
ISO26262-6.8_60 8.4.4 Table 8
ISO26262-6.8_70 8.4.4 Table 8
ISO26262-6.8_80 8.4.4 Table 8
ISO26262-6.8_90 8.4.4 Table 8
ISO26262-6.8_100 8.4.4 Table 8
SW unit testing

ISO26262-6.9_10 9.4.3

ISO26262-6.9_20 9.4.3 Table 10

ISO26262-6.9_30 9.4.4 Table 11

ISO26262-6.9_40 9.4.5 Table 12
ISO26262-6.9_50 9.4.6
ISO26262-6.9_60
Software integration and testing
ISO26262-6.10_10 10.4.1

ISO26262-6.10_20 10.4.3

ISO26262-6.10_30 10.4.3 Table 13

ISO26262-6.10_40 10.4.4 Table 14

ISO26262-6.10_50 10.4.5 & 10.4.6

ISO26262-6.10_60 10.4.8

ISO26262-6.10_70
Verification of SW requirements
ISO26262-6.11_10 11.4.2 & 10.4.3

ISO26262-6.11_20 11.4.4
Annex - C
ISO26262-6.C_10 Annex - C
ISO26262-6.C_20 Annex - C
 Question

Initiation of product development at the software level

Are software safety activities scheduled?
Are software safety activities described?
Especially, are all chapters of the Part 6 concerned by this description and are
supplier deliverables mentionned?
What is the modelling language if any and what is the coding language?
Is software complexity managed?
Are coding guidelines described and applied?
Are tooling guidelines described and applied?
Specification of SW safety requirements
Are software functions related to safety identified?
Are software safety requirements clear and complete?
Is ASIL level for software justified? Are different ASIL levels managed?
Does Hardware Software Interface document exist and is complete?
Are software safety requirement reviewed (functional and HW/SW)?
SW architectural design
What is the notation to describe software architecture?
Is software architecture justified to guarantee verifiability, suitability, feasibility,
testability and maintainability?

Is static decomposition in layers and modules done?

Are component sizes restricted?

Are interface sizes limited?
Is scheduling justified?
Is number of interrupts restricted?
Is dynamic architecture justified?
Are new modules, reused modules with modification and reused modules without
modification identified?
What is the strategy regarding ISO 26262 for each category of modules (new,
reused with or without modifications)?

What are the safety analyses applied at the architectural level? Describe the
methodologies and the link with the architecture justification and safety mechanisms.
 How freedom from interference or sufficient independence between software
components is managed to analyse the dependent failures?
Which failures do you consider and what are the related safety mechanisms?
What are the mechanisms implemented for error detections at software architecture
level?
What are the safety mechanisms for handling error at software architecture level?
Are there sw components or functions safety related left without any technical safety
measures?

What is the strategy for software architectural design (walkthrough or inspection)?

Is dynamic part simulated?

Is a prototype generated?

Is control flow analysis performed? If yes, how is it performed?

Is data flow analysis performed? If yes, how is it performed?

Are resources consumptions estimated and which one?

Software unit design and implementation
What is the notation to describe software unit design?
What is the level of description in the specification of the software units?
What are the design principles that are not fulfilled in ISO 26262-Part 6 - Table 8?

What is the strategy for software unit design review (walkthrough or inspection)?
What is the strategy for code review (walkthrough or inspection)?
Is semi-formal verification performed?
Is control flow analysis performed? If yes, how is it performed?
Is data flow analysis performed? If yes, how is it performed?
Is static code analysis performed? If yes, how is it performed?
Is semantic code analysis performed? If yes, how is it performed?
SW unit testing
Do unit testing methods demonstrate that the software units achieve:
- Compliance with the software unit design and hardware-software interface
specifications
- Confidence in the absence of unintended functionality
- Robustness?

What are the methods for software unit testing (see ISO 26262-Part 6 - Table 10)?
What are the methods for deriving test cases for software unit testing (see ISO
26262-Part 6 - Table 11)?
What is the structural coverage target?
What is the test environment for software unit testing?
Are resources consumptions measured and which ones?
Software integration and testing
What is the strategy applied for software integration?

Do software integration test methods demonstrate that both the software

components and the embedded software achieve:
- Compliance with the software architectural design and hardware-software interface
specifications
- Robustness?
What are the methods for software integration testing (see ISO 26262-Part 6 - Table
13)?
What are the methods for deriving test cases for software integration testing (see
ISO 26262-Part 6 - Table 14)?
What is the structural coverage target at software architecture level?

What is the test environment for software integration testing?

Are resources consumptions measured and which ones?

Verification of SW requirements
What is the test environment to verify software safety requirements?

Are all software safety requirement validated and tested OK?

Annex - C
What is the strategy to manage configuration data?
What is the strategy to manage calibration data?
 ISO 26262 part 6 check
1
45
Supplier answer

Conformity Implementation / Verification &

Level application status Validation status
26262 part 6 checklist

lier answer

Conformity
Answer
Level
 PSA answer

Verification &
Implementation
Validation
Level
Level
PSA answer

Comments
Workproducts or meeting minutes
associated
NA Not Applicable 0
NC Non Compliant 0
PC Partly compliant 0
LC Largely compliant 0
FC Fully compliant 0

OK OK 0
NOK NOK 0

NA 0
Not Applicable

OK OK 0
NOK NOK 0
TBA To Be Assessed 0
NA Not Applicable 0
DIA

Number ISO26262 SW Work products

6-5 Initiation of product development at the software level

6-5.5.1 Safety plan(refined)

6-5.5.2 Software verification plan

Design and coding guidelines for modeling and programming
6-5.5.3
languages (resulting from 6-5.4.6 and 6-5.4.7)
6-5.5.4 Tool application guidelines
6-6 Specification of software safety requirements
6-6.5.1 Software safety requirements specification
6-6.5.2 Hardware-software interface specification (refined)
6-6.5.3 Software verification plan
6-6.5.4 Software verification report
6-7 Software architectural design
6-7.5.1 Software architectural design specification
6-7.5.2 Safety plan (refined)
6-7.5.3 Software safety requirements specification (refined)
6-7.5.4 Safety analysis report
6-7.5.5 Dependent failures analysis report
6-7.5.6 Software verification report (refined)
6-8 Software unit design and implementation
6-8.5.1 Software unit design specification
6-8.5.2 Software unit implementation
6-8.5.3 Software verification report
6-9 Software unit testing
6-9.5.1 Software verification plan (refined)
6-9.5.2 Software verification specification)
6-9.5.3 Software verification report
6-10 Software integration and testing
6-10.5.1 Software verification plan (refined)
6-10.5.2 Software verification specification (refined)
6-10.5.3 Embedded software
6-10.5.4 Software verification report
6-11 Verification of software safety requirements
6-11.5.1 Software verification plan (refined)
6-11.5.2 Software verification specification (refined)
6-11.5.3 Software verification report
 Supplier

corresponding document Names Conformity status Verification Status

- Safety Plan : 02016_14_00525

- SW development Plan = PM Plan :
ref. xxxxx
-
er PSA
Verification &
Comments Conformity status
Validation Status
PSA

Comments DIA Naming

Exchange mode

OK
Conclusion
Level Current Global Evaluation
to be filled by PSA (mandatory)

(O)

Initiation of product development at the software level Evaluat

Specification of SW safety requirements Evaluation
SW architectural design Evaluation
Software unit design and implementation Evaluation
SW unit testing Evaluation
Software integration and testing Evaluation
Verification of SW requirements Evaluation
Annex - C Evaluation
aluation

are level Evaluation

ts Evaluation
ation
on Evaluation
n
valuation
valuation
NA
(G)
(O)

(R)
nov.-13 juin-14 déc.-14 juil.-15 janv.-16 août-16 mars-17 sept.-17
140%
JAI / JINV JEOS Jnum2 JHLa JEL AMC

120%
Vf-2 Vf-1 Vf Vc1 Vc2 Vc3

100%

80%
Target Conf

60%

Target Impl 40%

20%
Target V&V

0%
Theoritical Forecasted Safety (pre-)Assessment Dates at JST, JRO and JML

PSA Pre assessement => JST JSTB

PSA Pre assessement => JRO / RDFNURDFNUB
PSA Final assessement => JML JMLB

Vehicle or organic project milestones

1.3 1.3 1.3
JAI / JINV JEOS Jnum2
2/26/2014 9/24/2014 3/13/2015

SW versions (names + delivery dates)

1 0 1.1 1.1 1.1
today today Vf-2 Vf-1 Vf
5/10/2024 5/10/2024 9/19/2014 12/3/2014 6/1/2015
Target Conf 75% 100% 100%
Target Impl 40% 100%
Target V&V 15% 75%
 1.3 1.3 1.3
JHLa JEL AMC
9/23/2015 9/22/2016 3/13/2017

1.1 1.1 1.1

Vc1 Vc2 Vc3
1/15/2016 5/12/2016 8/5/2016
100% 100% 100%
100% 100% 100%
90% 95% 100%
Answers to PSA SW development rules

SUPPLIER ANSWER
Conformity Implementation
NA 0 #DIV/0! OK 0 #DIV/0!
NC 0 #DIV/0! NOK 0 #DIV/0!
PC 0 #DIV/0! NA 0 #DIV/0!
LC 0 #DIV/0!
FC 0 #DIV/0!
Total 0 0

Conformity Impl
NA
NC
PC
LC
FC

PSA DECISION
Conformity Implementation
OK 0 #DIV/0! OK 0 #DIV/0!
NOK 0 #DIV/0! NOK 0 #DIV/0!
TBA 0 #DIV/0! TBA 0 #DIV/0!
NA 0 #DIV/0! NA 0 #DIV/0!

Total 0 0

Conformity Imple
OK
NOK
TBA
 OK
NOK
TBA

SW DEVELOPMENT SUPPLIER ANSWER

Conformity
GenRules Memories Interrupts uC
Progress 0.0% 0.0% 0.0% 0.0%
Implementation
GenRules Memories Interrupts uC
Progress 0% 0% 0% 0%
V&V
GenRules Memories Interrupts uC
Progress 0.0% 0.0% 0.0% 0.0%

0.0% 0.0% 0.0% 0.0%

SW DEVELOPMENT PCA ANSWER
Sw Dvpt Rules Conformity
GenRules Memories Interrupts uC
NA 0% 0% 0% 0%
NOK 0% 0% 0% 0%
TBA 0% 0% 0% 0%
OK 0% 0% 0% 0%
Vides -100% -100% -100% -100%
Progress 0% 0% 0% 0%
Sw Dvpt Rules Implementation
GenRules Memories Interrupts uC
Progress 0% 0% 0% 0%
Sw Dvpt Rules V&V
GenRules Memories Interrupts uC
Progress 0% 0% 0% 0%

SW Rules Conformity for PCA

CODE

OS

Watchdog NA
NOK
Stack TBA
uC OK
Vides
Interrupts

Memories

GenRules

-120% -100% -80% -60% -40% -20% 0%

Answers to ISO 26262 Checklist

SUPPLIER ANSWER
Conformity Implementation
NA 0 #DIV/0! OK 0 #DIV/0!
NC 0 #DIV/0! NOK 0 #DIV/0!
PC 0 #DIV/0! NA 0 #DIV/0!
LC 0 #DIV/0!
FC 0 #DIV/0!
Total 0 0

Conformity Impl
NA
NC
PC
LC
FC

PSA DECISION
Conformity Implementation
OK 0 #DIV/0! OK 0 #DIV/0!
NOK 0 #DIV/0! NOK 0 #DIV/0!
TBA 0 #DIV/0! TBA 0 #DIV/0!
NA 0 #DIV/0! NA 0 #DIV/0!

Total 0 0

Conformity Imple
OK
NOK
TBA
 OK
NOK
TBA

ISO26262 SUPPLIER ANSWER

26262 SUPPLIER Conformity
§5 §6 §7 §8
Progress 0.0% #DIV/0! #DIV/0! #DIV/0!
26262 SUPPLIER Implementation
§5 §6 §7 §8
Progress 0.0% 0.0% 0.0% 0.0%
26262 SUPPLIER V&V
§5 §6 §7 §8
Progress 0.0% 0.0% 0.0% 0.0%

0.0% 0.0% 0.0% 0.0%

ISO26262 PCA ANSWER
26262 Conformity
§5 §6 §7 §8
Progress 0.0% 0.0% 0.0% 0.0%
26262 Impl.
§5 §6 §7 §8
Progress 0.0% 0.0% 0.0% 0.0%
26262 V&V
§5 §6 §7 §8
Progress 0.0% 0.0% 0.0% 0.0%

ISO Conf. Status for PCA IS

§C

§11

§10 TBA
NA
§9 OK
NOK
§8 Vides
§7

§6

§5

-120% -100% -80% -60% -40% -20% 0% -120% -100%

 Validation
OK 0 #DIV/0!
NOK 0 #DIV/0!
NA 0 #DIV/0!

Implementation Validation
OK
NOK
NA

Validation
OK 0 #DIV/0!
NOK 0 #DIV/0!
TBA 0 #DIV/0!
NA 0 #DIV/0!

Implementation Validation
OK
NOK
TBA
 OK
NOK
TBA

ENT SUPPLIER ANSWER

onformity
Stack Watchdog OS CODE
0.0% 0.0% 0.0% 0.0%
lementation
Stack Watchdog OS CODE
0% 0% 0% 0%
V&V
Stack Watchdog OS CODE
0.0% 0.0% 0.0% 0.0%

0.0% 0.0% 0.0% 0.0%

PMENT PCA ANSWER
Rules Conformity Moyenne
Stack Watchdog OS CODE
0% 0% 0% 0%
0% 0% 0% 0%
0% 0% 0% 0%
0% 0% 0% 0%
-100% -100% -100% -100%
0% 0% 0% 0% 0%
ules Implementation
Stack Watchdog OS CODE
0% 0% 0% 0% 0%
vpt Rules V&V
Stack Watchdog OS CODE
0% 0% 0% 0% 0%

r PCA SW Rules Impl. for PCA

CODE CODE

OS OS

Watchdog NA Watchdog NA
NOK NOK
Stack TBA Stack TBA
OK uC OK
uC
Vides Vides
Interrupts Interrupts

Memories Memories

GenRules GenRules

-20% 0% -120% -100% -80% -60% -40% -20% 0%

 Validation
OK 0 #DIV/0!
NOK 0 #DIV/0!
NA 0 #DIV/0!

Implementation Validation
OK
NOK
NA

Validation
OK 0 #DIV/0!
NOK 0 #DIV/0!
TBA 0 #DIV/0!
NA 0 #DIV/0!

Implementation Validation
OK
NOK
TBA
 OK
NOK
TBA

SUPPLIER ANSWER
PPLIER Conformity Moyenne
§9 §10 §11 §C
#DIV/0! #DIV/0! #DIV/0! #DIV/0! #DIV/0!
LIER Implementation
§9 §10 §11 §C
0.0% 0.0% 0.0% 0.0% 0.0%
SUPPLIER V&V
§9 §10 §11 §C
0.0% 0.0% 0.0% 0.0% 0.0%

0.0% 0.0% 0.0% 0.0%

62 PCA ANSWER
2 Conformity Moyenne
§9 §10 §11 §C
0.0% 0.0% 0.0% 0.0% 0.0%
6262 Impl.
§9 §10 §11 §C
0.0% 0.0% 0.0% 0.0% 0.0%
6262 V&V
§9 §10 §11 §C
0.0% 0.0% 0.0% 0.0% 0.0%

ISO Impl. Status for PCA ISO V&V S

§C

§11

§10 TBA
NA
§9 OK
NOK
§8 Vides
§7

§6

§5

-120% -100% -80% -60% -40% -20% 0% -120% -100% -80% -60
Validation
OK
NOK
NA

Validation
OK
NOK
TBA
 OK
NOK
TBA

SW Rules V&V for PCA

DE CODE

OS OS

dog NA Watchdog NA
NOK NOK
ack TBA Stack TBA
OK uC OK
uC
Vides Vides
pts Interrupts

ies Memories

les GenRules

0% -120% -100% -80% -60% -40% -20% 0%

Validation
OK
NOK
NA

Validation
OK
NOK
TBA
 OK
NOK
TBA

ISO V&V Status for PCA

§C

§11

§10 TBA
NA
§9 OK
NOK
§8 Vides
§7

§6

§5

20% -100% -80% -60% -40% -20% 0%

DE

OS

og NA
NOK
ck TBA
C OK
Vides
ts

es

es

0%