K5 SW Requirements Packs for Request for Quotation

IDENTIFICATION IND PROJECT PAGE
01552_17_06898
1.0 EPS_K5
1
32
THIS DOCUMENT IS THE PROPERTY OF PSA AND MAY NOT BE REPRODUCED OR DISCLOSED WITHOUT ITS
AUTHORIZATION
Identification :
01552_17_06898
Applicable to project :
EPS_K5
RFQ SOFTWARE REQUIREMENTS NOTEBOOK for
EPS_K5
SCOPE :
Author(s) :
Name :
M. CHAFFI
DSEE/MCAD/CDAD/CDDC
Date
30th
October 2017
Signature:
Inspector(s) :
Name :
S. HAGUET
DSEE/MCAD/CDAD/CDDC
Date Signature:
Approved By :
Name :
M. CHAFFI
DSEE/MCAD/CDAD/CDDC
Date
30th
October 2017
Signature:

01552_17_06898 1.0 EPS_K5 2 / 32
THIS DOCUMENT IS THE PROPERTY OF PSA AND MAY NOT BE REPRODUCED OR DISCLOSED WITHOUT ITS AUTHORIZATION
Table of contents
Table of contents.......................................................................................................................................... 2
1 Table of updates................................................................................................................................... 5
2 PURPOSE AND SCOPE OF APPLICATION.................................................................................... 6
2.1 PURPOSE.................................................................................................................................... 6
2.2 SCOPE OF APPLICATION........................................................................................................ 6
2.2.1 DEVELOPMENT CONTEXT .............................................................................................. 6
2.2.2 GENERAL SYSTEM DESCRIPTION ................................................................................. 6
3 QUOTED DOCUMENTS AND TERMINOLOGY ........................................................................... 6
3.1 Reference documents................................................................................................................... 6
3.2 Applicable documents.................................................................................................................. 6
3.3 REQUIREMENTS DOCUMENTS ORGANISATION.............................................................. 7
3.4 DOCUMENT RULE ................................................................................................................... 8
3.4.1 Requirements identification................................................................................................... 8
3.4.2 specific case of instanciated requirements on a project......................................................... 8
3.5 Glossary ....................................................................................................................................... 9
3.6 Acronyms................................................................................................................................... 12
4 OPERATIONAL ANALYSIS........................................................................................................... 15
4.1 Component missions.................................................................................................................. 15
4.2 Input requirements summary ..................................................................................................... 15
4.2.1 Assembly requirements........................................................................................................ 15
4.2.2 Quality objectives ................................................................................................................ 15
4.3 Component context diagram & external interfaces ................................................................... 15
4.3.1 Technical external systems .................................................................................................. 15
4.3.2 Organizational external systems .......................................................................................... 16
4.3.3 Input / output flows of the component................................................................................. 16
4.4 Component lifecycle .................................................................................................................. 16
4.5 Component uses cases................................................................................................................ 16
4.6 Component operational scenarios.............................................................................................. 16
5 COMPONENT ARCHITECTURE ................................................................................................... 16
5.1 General design constraints......................................................................................................... 16
5.2 Configuration and diversity ....................................................................................................... 16
5.3 Physical characteristics .............................................................................................................. 16
5.4 Functional architecture............................................................................................................... 16
5.4.1 Static functional architecture ............................................................................................... 16
5.4.1.1 Functional breakdown structure ................................................................................... 16
5.4.1.2 Functional interfaces..................................................................................................... 16
5.4.1.2.1 Functional external interfaces .................................................................................. 16
5.4.1.2.2 Functional internal interfaces................................................................................... 16
5.4.1.3 Functional architecture ................................................................................................. 16
5.4.2 Dynamic functional analysis................................................................................................ 17
5.4.2.1 Functional state machine .............................................................................................. 17
5.4.2.2 Functional scenario....................................................................................................... 17
5.5 Physical architecture .................................................................................................................. 17
5.5.1 Product Breakdown Structure.............................................................................................. 17
5.5.2 Static physical architecture .................................................................................................. 17
5.5.3 Dynamic physical analysis................................................................................................... 17

01552_17_06898 1.0 EPS_K5 3 / 32
5.5.3.1 Component state machine............................................................................................. 17
5.5.3.2 Physical scenario .......................................................................................................... 17
5.5.4 Physical interfaces ............................................................................................................... 17
5.5.4.1 Physical external interfaces .......................................................................................... 17
5.5.4.2 Physical internal interfaces........................................................................................... 17
5.5.5 Logical architecture ............................................................................................................. 17
5.6 Component weight..................................................................................................................... 17
5.6.1 Overall weight of the Component........................................................................................ 17
5.6.2 Weight breakdown and allocation matrix............................................................................ 17
6 COMPONENT OUTPUT REQUIREMENTS.................................................................................. 18
6.1 FUNCTIONAL REQUIREMENTS .......................................................................................... 18
6.1.1 Functional specifications list................................................................................................ 19
6.1.2 Software components list from PSA.................................................................................... 20
6.1.3 Bugfixes list ......................................................................................................................... 20
6.1.4 Exception sheets list............................................................................................................. 20
6.2 PERFORMANCE REQUIREMENTS...................................................................................... 20
6.2.1 CPU load.............................................................................................................................. 20
6.2.2 Memories occupancy ........................................................................................................... 21
6.2.3 Stack management ............................................................................................................... 22
6.3 EXTERNAL INTERFACES REQUIREMENTS ..................................................................... 22
6.3.1 Context Diagram.................................................................................................................. 22
6.3.1.1 Purpose of the control unit............................................................................................ 23
6.3.1.2 Global overview ........................................................................................................... 23
6.3.2 CAN network(s)................................................................................................................... 23
6.3.3 FLEXRAY network(s)......................................................................................................... 23
6.3.4 Serial links ........................................................................................................................... 23
6.3.5 Wired inputs/outputs............................................................................................................ 23
6.3.6 Bypass links ......................................................................................................................... 23
6.4 OPERATIONAL REQUIREMENTS........................................................................................ 23
6.4.1 Mission profile..................................................................................................................... 23
6.4.2 Software life cycle ............................................................................................................... 23
6.4.3 Lifetime................................................................................................................................ 24
6.4.4 Ergonomics and human factors............................................................................................ 24
6.4.5 RAMS requirements ............................................................................................................ 24
6.4.5.1 Reliability..................................................................................................................... 24
6.4.5.2 Maintainability............................................................................................................. 25
6.4.5.3 Availability ................................................................................................................... 25
6.4.5.4 Safety........................................................................................................................... 25
6.4.6 Product quality..................................................................................................................... 25
6.4.7 Protection against hostility................................................................................................... 25
6.4.8 Resources reserve capacity of the system............................................................................ 26
6.4.9 Document requirements....................................................................................................... 26
6.5 CONSTRAINT REQUIREMENTS .......................................................................................... 26
6.5.1 Regulation and consumerism............................................................................................... 26
6.5.2 Weight and other physical characteristics............................................................................ 26
6.5.3 Design and Manufacturing................................................................................................... 26
6.5.3.1 Design process........................................................................................................... 26
6.5.3.2 Software components................................................................................................ 27
6.5.3.3 Software architecture ................................................................................................ 27
6.5.3.4 Coding tools and language....................................................................................... 28

01552_17_06898 1.0 EPS_K5 4 / 32
6.5.3.5 Calibration and prototyping tools............................................................................. 28
6.5.3.6 Studies and/or imposed solutions ........................................................................... 28
6.5.3.7 Materials...................................................................................................................... 29
6.5.3.8 Manufacturing............................................................................................................. 29
6.5.3.9 Marking of the Components or Parts...................................................................... 29
6.5.4 Product identification........................................................................................................... 29
6.5.4.1 Generic software identification .................................................................................... 29
6.5.4.2 Master software identification...................................................................................... 29
6.5.5 Traceability and configuration............................................................................................. 30
6.5.6 Transportability, storage, and packaging............................................................................. 30
6.5.7 Flexibility and extension...................................................................................................... 31
6.5.8 End of life ............................................................................................................................ 31
6.5.9 Withdrawal........................................................................................................................... 31
6.5.10 Environment conditions....................................................................................................... 31
6.5.11 Planning ............................................................................................................................... 31
6.5.11.1 Global software development planning........................................................................ 31
6.6 INTEGRATION AND VALIDATION REQUIREMENTS..................................................... 32
6.6.1 INTEGRATION .................................................................................................................. 32
6.6.2 Tests and Validation ............................................................................................................ 32
7 PARAMETERS................................................................................................................................. 32
8 TRACEABILITY MATRIX.............................................................................................................. 32

01552_17_06898 1.0 EPS_K5 5 / 32
1 Table of updates
Index Date Author Modification account
OR (1.0) 30 October 2017 M. Chaffi Creation

IDENTIFICATION IND PROJET PAGE
01552_17_06898 1.0 EPS_K5 6 / 32
2 PURPOSE AND SCOPE OF APPLICATION
2.1 PURPOSE
L’objet de ce document est de définir les exigences PSA du développement des logiciels de l’organe
EPS_K5.
Ce document fait partie du dossier contractuel de consultation.
The purpose of this document is to specify the PSA requirements related to the software development of
the part EPS_K5.
This document belongs to the contractual documentation of consultation.
2.2 SCOPE OF APPLICATION
2.2.1 DEVELOPMENT CONTEXT
2.2.2 GENERAL SYSTEM DESCRIPTION
3 QUOTED DOCUMENTS AND TERMINOLOGY
3.1 Reference documents
Ces documents ont permis l’élaboration de celui-ci. Ils ne sont pas transmissibles systématiquement.
The documents listed below helped elaborating the present one. They are not communicated
systematically.
Title Link or Reference
[001] Reserved
[100] Reserved
[103] Reserved
[104] Dossier de justification de ce document 01552_17_06905
[107] Modèle de cdc logiciel 01552_17_06352
[200] Reserved
3.2 Applicable documents
Ces documents contribuent avec celui-ci à un ensemble documentaire cohérent. Ils sont transmissibles
systématiquement sur simple demande.

01552_17_06898 1.0 EPS_K5 7 / 32
The following documents, as well as the present one are part of a consistent set. They can be provided on
request.
Identification Title Link or Reference
[003] reserved
[004] reserved
[005] reserved
[007] SQM
[008] SW Guidelines 01552_17_06340
[009] reserved
[010] reserved
[011] reserved
[012] reserved
[013]
PSA Cyber Security Assurance
Requirements 02016_16_05952
3.3 REQUIREMENTS DOCUMENTS ORGANISATION
Le document présent est le document [006].
The present document is the document [006].

01552_17_06898 1.0 EPS_K5 8 / 32
[006]
[007]
[008]
[005] CDC HW
HW SPECIFICATION SHEET
Contraintes HW
Tenue environnement
Contraintes dimensionnement
Définition des E/S du système
Profils de mission
Contraintes mécaniques
Diagnostique HW
CDC SW
SW SPECIFICATION SHEET
Contraintes temps réél CMM
Fonctions de service EOBD / APV
Téléchargement
Diagnostique fonctionnel
Diagnostique SW
Prototypage et mise au point
SW Guidelines
SW Guidelines
DOCUMENTS
APPLICABLES
APPLICABLE
DOCUMENTS
[003
DOCUMENTS
APPLICABLES
APPLICABLE
DOCUMENTS
3.4 DOCUMENT RULE
3.4.1 Requirements identification
Les exigences sont identifiées comme suit :
Throughout the document, the requirements are identified as following:
[Numéro] Libellé de l’exigence. / [Number] Requirement text
3.4.2 specific case of instanciated requirements on a project
Les variables contenues dans les exigences sont décrites par des paramètres (texte repéré entre < > dans
les exigences concernées).
Le Tableau des paramètres liste ces paramètres et leur valeur associée.
Variables in the requirement are described by parameters (text inside <> in the requirements).
Parameters and values are listed in Table of parameters.

01552_17_06898 1.0 EPS_K5 9 / 32
3.5 Glossary
Les termes techniques spécifiques suivants seront utilisés dans ce document :
Term Definition
Autodiagnostic
Les calculateurs sont pourvus d’une fonction d’autodiagnostic du dispositif, c’est à dire
que le bon fonctionnement des capteurs, des actionneurs, du bus CAN, et du calculateur
lui-même est surveillé par le logiciel. Cette fonction a pour objectifs de :
- Détecter les défaillances ou anomalies de fonctionnement
- Assurer la sécurité des occupants par des stratégies de secours
- Eviter la propagation de pannes par des modes dégradés permettant de rejoindre un
garage
- Mémoriser et signaler les défauts pour faciliter le dépannage et avertir le conducteur si
nécessaire.
Bypass fonctionnel Le bypass fonctionnel s’attache à bypasser toutes les sorties d’une fonction clairement
délimitée dans l’architecture fonctionnelle du calculateur. Exemple : régulation/limitation
de vitesse
Bypass logiciel Le bypass logiciel s’attache à bypasser différentes variables du logiciel du calculateur, sans
nécessairement y raccorder une fonctionnalité précise. Exemple : bypasser la consigne de
position EGR en degrés
Bypass en mode standalone Le bypass logiciel est activé automatiquement à la mise sous tension des calculateurs ECU
et RPU, sans intervention de l’utilisateur.
Cahier des Charges
Document qui rassemble toutes les exigences d'une partie prenante pour un système.
Il est issu du dossier de conception du sur-système.
Le CdC est la composante technique du dossier de consultation.
Calculateur bypassable Calculateur de développement équipé d’une interface de bypass et programmé avec un
logiciel intégrant des variables de bypass
Calibration Un jeu de calibration est l’ensemble des valeurs des paramètres
CAN IS
Réseau CAN intersystèmes dédié aux fonctions de roulage (moteur, boite, freinage,
châssis, …)
CAN HY Réseau CAN dédié aux fonctions hybride (HCU, TBMU)
CAN LAS Réseau CAN dédié aux fonctions Liaison Au Sol (ESP, molette hybride)
Composant logiciel Code source en C ANSI et spécification détaillée des API fournie par PSA.
Composant logiciel tiers Composant logiciel utilisé par le FNR mais développé par un tiers
Document de référence
Document (norme, document de spécification, d’architecture et de conception internes)
utilisé pour rédiger la spécification technique
Document applicable
Document contenant une partie spécifiante, à savoir une partie de la spécification
technique et les documents appelés par la spécification technique.
Fichier A2L - Le fichier de description ASAP, ou fichier A2L, est utilisé pour décrire la configuration
mémoire interne d’un calculateur. Il contient des informations sur les différentes structures
et allocations mémoire des données dans l’ECU, les procédures de conversion pour la
représentation en unités physiques, les descriptions des canaux de mesure (measurements)
et de paramétrage (characteristics) et des descriptions des moyens d’accès à l’ECU via le
bus CAN.
FLEXRAY Réseau de communication par BUS utilisé certaines fonctions (exemple : ADAS).
Fonctions Core
Terme anglais pour désigner les fonctions partagées entre les partenaires de
développement d’un logiciel
LIN BUS de communication (Local Interconnect Network)
Fonctions Spécifiques
Dans le cadre des coopérations entre constructeurs, désigne les fonctions spécifiques aux
partenaires de développement d’un logiciel de contrôle moteur

01552_17_06898 1.0 EPS_K5 10 / 32
Logiciel
Ensemble des programmes, procédés, règles et éventuellement documentation relative au
fonctionnement d'un ensemble de traitement de données. Le logiciel regroupe en
particulier le logiciel applicatif et la calibration.
Logiciel applicatif
Logiciel exécutable qui associé à la calibration permet de remplir les fonctions du
calculateur
Logiciel générique
Logiciel utilisé pour la mise au point et le développement. Il ne peut pas être officialisé.
Il s’agit d’un logiciel applicatif avec une calibration à mettre au point
Logiciel Master
Il s’agit du fichier binaire au format final téléchargeable par les outils UT ou APV PSA
(ulp ou .cal). Il contient entre autres les données d’identification du logiciel dans son
environnement calculateur. Ce logiciel est spécifique à une application, il est
officialisable.
Macro module
Ensemble de l’applicatif PSA livré sous la forme d’une composition de SW-C
AUTOSAR.
Partenariat Organe Désigne un partenariat mis en place pour le développement d’un organe
Réveil du CMM Le CMM est considéré comme réveillé après la commutation du relais principal.
Pile
La pile (en anglais stack) est une structure de données basée sur le principe « Dernier
arrivé, premier sorti » ou LIFO (Last In, First Out). Ici, la pile est en fait la pile d'appel
qui est une pile particulière dans laquelle sont poussés tout ou partie des paramètres
d'appel des procédures ou fonctions, ainsi que l'adresse de retour. Par ailleurs, on y crée
un espace pour des variables locales. La pile est ainsi formée de cadres de piles (stack
frames) comprenant pour chaque procédure en cours d'appel imbriqué ses paramètres,
ses variables locales et son point de retour. La pile système sert à sauver le contexte
(valeur des registres, point de retour...) lors des exceptions et des interruptions. Devant
pouvoir être lue comme écrite, la pile se trouve donc en RAM.
Point de bypass = variable de
bypass
Variable logicielle ayant été préparée pour être modifiable en temps réel par un calculateur
extérieur de bypass.
Prototypes Produit répondant aux spécifications réalisé sur des moyens de production non de série.
Partenariat Véhicule Désigne un partenariat mis en place pour le développement d’un véhicule
Spécification technique
Document qui rassemble pour un système les exigences techniques spécifiées et mises en
cohérence de toutes les parties prenantes. Il exprime ce que doit faire le système, non
comment il doit le faire. Il fait appel à des Spécifications d'interface.
La ST est la composante technique du contrat.
Téléchargement
Opération permettant d’effectuer des mises à niveau du logiciel applicatif et/ou des
calibrations dans un calculateur.
Télécodage
Opération permettant d’associer un calculateur à une configuration véhicule donnée.
L'ensemble des paramètres liés à cette configuration est sélectionné.
Tests
On distingue 4 types de tests :
- tests unitaires
- tests d’intégration
- tests fonctionnels
- tests de non régression
L’ensemble des tests à effectuer pour valider une fonction logicielle est répertorié dans
une procédure de tests, qui contient également les résultats attendus.
Tests fonctionnels FNR
Tests fonctionnels déroulés par le FNR pour s’assurer que le logiciel respecte les choix
de conception effectués par le FNR.
Tests fonctionnels PSA
Tests fonctionnels déroulés par le FNR pour s’assurer que le logiciel respecte les
exigences formulées par PSA

01552_17_06898 1.0 EPS_K5 11 / 32
Validation
Ensemble des activités à mener afin de déterminer si l’objet (fonction logicielle) est
conforme ou non à l’attendu
The following terms are used throughout the documents.
Term Definition
Autodiagnostic
The ECUs own an auto diagnostic function. It means that the monitoring of the sensors,
actuators, the CAN bus and the ECU itself is done by the software. The purpose of the
function is:
- To detect the failures or functional anomalies
- Ensure the safety of the passengers using emergency strategies
- Avoid the failure propagation by using degraded modes which gives the possibility to
reach a garage.
- Record and raise the defaults in order to make the reparation more efficient and alert
the driver if necessary
Functional bypass The purpose of the functional bypass is to bypass all the outputs of a function clearly
delimited in the ECU functional architecture. Example : speed regulation/limitation.
Software bypass The purpose of the software bypass is to bypass different variables of the ECU software,
which are not necessarily related to a specific function. Example : the order of the EGR
position, in degrees
Bypass in “standalone” mode The software bypass is automatically activated at the ECU and RPU power on, without
any intervention of the user.
Specification sheet
Document gathering all the requirements of the system or a part of the system.
It results from the design file of the upper-level system.
The specification sheet is the technical component of the RfQ file.
Bypassable ECU Development ECU equipped with a bypass interface and programmed with a software
implementing bypass variables.
Calibration Set of parameter values
CAN IS
Inter-system CAN network dedicated to driving functions(engine, gearbox, braking
system, suspension, …)
CAN HY CAN network dedicated to Hybrid functions (HCU, TBMU)
CAN LAS CAN network dedicated to chassis (ESP, hybride roller)
ECU Wake-Up The ECU is « woken up » once the main relay is switched on.
Software component Source code in C ANSI and detailed specification of the API supplied by PSA.
Third party software component Software component used by the supplier but developed by a third party
Reference document
Document (standard, specification, architecture and internal design document) used to
write the technical specification.
Document applicable
Document containing a specifying part, which can be a part of the technical
specificaiton and the document called by the technical specification.
FLEXRAY BUS communication network used for some functions (example : ADAS).
A2L file The description file ASAP, or A2L file, is used to describe the ECU internal memory
configuaration. It includes information about the different memory structures and
allocations, the conversion procedures for the representation physical units, the
descriptions of the measurement and characteristics channels and the description of the
means to access to the ECU by the CAN bus.
Core functions Functions shared between the software development partners
Specific functions
In the context of partnership between car manufacturers, functions specific to the
software development partners
LIN BUS communication network (Local Interconnect Network)

01552_17_06898 1.0 EPS_K5 12 / 32
Software
Set of programs, process, rules and documentation related to a data processing system.
The software includes in particular the applicative software and the calibration.
Applicative software Executable software, when associated to the calibration executes the ECU functions.
Generic software
Software used for tuning and development. It cannot be industrialised. It is an
applicative software with a development calibration.
Master software
Binary file in the download format used by the PSA plants or after-sales (.ulp or .cal). It
contains particularly the software identification data in the ECU environment. This
software is specific to a vehicle application and it can be industrialised.
Macro module PSA ASW delivered as a SW-C AUTOSAR composition.
Part partnership Partnership for the development of an automotive part.
Stack
The stack is a data structure based on the concept “Last In, First Out” (LIFO). Here, the
stack is actually the call stack which contains whole or part of the call arguments of
functions and procedures, as well as return addresses. It contains also a dedicated area
for local variables. The stack is then composed of stack frames which contain, for each
imbricated procedure in execution, the arguments, the local variables and the return
point. The system stack saves the context (registry values, return point, …) when
exceptions and interruptions occur. In order to be read and written, the stack is located
in RAM.
Bypass point = bypass variable Software variable prepared to be modifiable in real time by an external bypass ECU.
Prototypes
Product compliant with the specifications which has been realized on non-serial
production means.
Vehicle partnership Partnership for a vehicle development.
Technical specification
Document gathering all the coherent requirements of the specified system.
The technical specification describes what the system shall do. It does not describe how it
shall do it. The technical specification is the final result of the specification process
It refers to interface specifications.
The technical specification is the technical component of the contract
Download
Operation performing upgrades of the applicative software and/or calibrations in the
ECU.
Variant coding
Operation associating a given vehicle-specific configuration to the TCU. The set of
parameters related to this configuration is selected.
Tests
4 types of tests are identified:
 Unit tests
 Integration tests
 Functional tests
 Non-regression tests
A test procedure gathers all the tests that must be performed to validate a software
function, as well as the expected results.
Supplier functional tests
Functional tests run by the supplier to ensure that the software respects the design
choices done by the supplier.
PSA functional tests
Functional tests run by the supplier to ensure that the software respects the PSA
requirements
Validation
Activities to perform in order to determine if the object (software function) is conform to
the expectations.
3.6 Acronyms
Les abréviations qui seront utilisées dans ce document sont définies dans le tableau suivant :

01552_17_06898 1.0 EPS_K5 13 / 32
Acronym Definition
ACCP Advanced Common Rail Combustion Process
AD A Définir
ADC Anti Démarrage Codé
APC APrès Contact
API Application Programm Interface
APV APrès-Vente
MCD
ASAM-MCD 1MC ou ASAP 1
pour Measurement, Calibration and Diagnostics
- ASAP 1 relève du protocole
- ASAP 2 relève du format de description des données. ex : fichier A2L
- ASAP 3 relève d’une interface logicielle.
AQMPP Assurance Qualité par la Maîtrise du Produit et du Processus
BSI Boîtier de Servitude Intelligent
CAN Controller Area Network
CC Contrôle Commande
CCP Can Calibration Protocol : protocole de calibration utilisant le bus CAN comme vecteur
de transmission
CDC Cahier Des Charges
CMM Contrôle Moteur Multifonction
CPPR Clauses Particulières et Planning de Résultat
CRCPP Can Rapid Control Prototyping Protocol. Protocole de communication basé sur le CCP
pour bypass développé par Ford.
CPU Central Processing Unit
CRQ Change Request (demande d’évolution)
DMS DéMarrage Série
E/S Entrées / Sorties
ECCS Extreme Conventional Combustion System
ECU Electronic Control Unit
EE Electricité Electronique
EOBD European On Board Diagnostic
ETK Emulator TastKopf (ETAS) : interface de mesure/calibration et prototypage rapide de la
société ETAS.
FNR FourNisseuR
FRIC Fonction de Refroidissement Intégré au Calculateur
FXD Fault Exchange Data
GAP Gestion d'Alternateur Piloté
HW HardWare
ISA Ingénierie Système Automobile
IT InTerruption

01552_17_06898 1.0 EPS_K5 14 / 32
LDA Logiciel D’Application
LDB Logiciel De Base
LVV Limiteur Vitesse Véhicule
MIL Malfunction Indicator Lamp
MPO Mulet Porte Organe
MRF Document Management Relation Fournisseur
NVRAM Mémoire non volatile
PMH Point Mort Haut
POD / GSI Plug On Device / Generic Serial Interface (dSPACE): interface de mesure/calibration et
prototypage rapide de la société dSPACE.
PRSEL PRototype Série En Ligne
PRSHL PRototype Série Hors Ligne
RCD Réveil Commandé à Distance
RTE Run Time Environment
RPU Rapid Prototyping Unit : calculateur de prototypage rapide
RVV Régulateur Vitesse Véhicule
SDF Sûreté De Fonctionnement
SOP Start Of Production
SRU Stade Représentatif Unique
SW SoftWare
TBD To Be Defined
TI Temps d'Injection
UCE Unité de Commande Electronique
UP Usine de Production
WCET Worst Case Execution Time
XCP X Calibration Protocol : protocole de calibration remplaçant et standardisant le CCP.
utilise plusieurs vecteurs de transmission possibles : USB, CAN, Ethernet. CCP et XCP
on CAN sont standardisés par ASAM MCD 1a
ZA Zone d’Authentification
ZI Zone d’Identification
The abbreviations that are used throughout the document are listed in the table below:
Acronym Definition
ADC Immobilizer
API Application Program Interface
AQMPP PSA quality assurance methodology in the development phase (Assurance Qualité par la
Maîtrise du Produit et du Processus)
CAN Controller Area Network
CDC Specification notebook (Cahier Des Charges)

01552_17_06898 1.0 EPS_K5 15 / 32
CMM Engine Control Unit (Contrôle Moteur Multifonction)
CMQ Quality Management Clauses
CPU Central Processing Unit
CRQ Change Request
DMS SOP (DéMarrage Série)
I/O Input/Output
ECU Electronic Control Unit
FXD Fault Exchange Data
GAP Smart Alternator management (Gestion d'Alternateur Piloté)
HW HardWare
MPO Mule vehicle (Mulet Porte Organe)
PRSEL PRototype Série En Ligne
PRSHL PRototype Série Hors Ligne
SOP Start Of Production
SRU First functionally representative prototype (Stade Représentatif Unique)
TBD To Be Defined
AZ Authentication Zone
IZ Identification Zone
4 OPERATIONAL ANALYSIS
4.1 Component missions
4.2 Input requirements summary
4.2.1 Assembly requirements
4.2.2 Quality objectives
4.3 Component context diagram & external interfaces
4.3.1 Technical external systems

01552_17_06898 1.0 EPS_K5 16 / 32
4.3.2 Organizational external systems
4.3.3 Input / output flows of the component
4.4 Component lifecycle
4.5 Component uses cases
4.6 Component operational scenarios
5 COMPONENT ARCHITECTURE
5.1 General design constraints
5.2 Configuration and diversity
5.3 Physical characteristics
5.4 Functional architecture
5.4.1 Static functional architecture
5.4.1.1 Functional breakdown structure
5.4.1.2 Functional interfaces
5.4.1.2.1 Functional external interfaces
5.4.1.2.2 Functional internal interfaces
5.4.1.3 Functional architecture

01552_17_06898 1.0 EPS_K5 17 / 32
5.4.2 Dynamic functional analysis
5.4.2.1 Functional state machine
5.4.2.2 Functional scenario
5.5 Physical architecture
5.5.1 Product Breakdown Structure
5.5.2 Static physical architecture
5.5.3 Dynamic physical analysis
5.5.3.1 Component state machine
5.5.3.2 Physical scenario
5.5.4 Physical interfaces
5.5.4.1 Physical external interfaces
5.5.4.2 Physical internal interfaces
5.5.5 Logical architecture
5.6 Component weight
5.6.1 Overall weight of the Component
5.6.2 Weight breakdown and allocation matrix

01552_17_06898 1.0 EPS_K5 18 / 32
6 COMPONENT OUTPUT REQUIREMENTS
Les exigences applicables pour le développement du logiciel sont décrites dans ce chapitre.
The applicable requirements for the SW development are listed in this chapter.
Requirement no. (v) Description of the requirement Input requirement (v)
GEN-SW-ORG-CDC-5-
5-80(1.2)
L’offre doit présenter l’effort de développement
du logiciel pour chacune des exigences et
préciser la répartition par type d’activité.
The supplier’s bid shall include the software
development workload for each requirement and
specifies spreading for each activity type.
6.1 FUNCTIONAL REQUIREMENTS
Les exigences logicielles PSA décrivant les fonctionnalités applicatives (en mode nominal et modes
dégradés correspondants) ainsi que les fonctionnalités de services applicables à ce logiciel sont décrites
dans ce chapitre.
PSA software requirements that described the applicative functions (in nominal mode and degraded mode)
and services functions are listed in this chapter.
La liste des documents applicables définie dans ce chapitre (paragraphes « Liste des spécifications
fonctionnelles » et « Liste des anomalies») est contractuelle. Chaque document applicable est à voir
comme une exigence à part entière.
The applicable specifications list that is communicated in this chapter is contractual. Each applicable
document must be seen as a requirement.
La colonne "Type" indique le type de spécification selon le tableau suivant:
Type Signification
T0 Indique qu'une spécification fournisseur est attendue. La fonctionnalité ne
devra pas présenter de régression fonctionnelle par rapport aux solutions
fournisseur déjà intégrées pour PSA.
T1 Indique qu'il s'agit d'une spécification technique de besoin PSA et qu'une
spécification fournisseur est attendue.
T2 Indique qu’il s’agit d’une spécification de conception.
T3 Indique qu'il s'agit d'une spécification détaillée.
T4 Indique qu’il s’agit d’un composant logiciel
The "Type" column describes the type of specification according to the table below:

01552_17_06898 1.0 EPS_K5 19 / 32
Type Meaning
T0 A supplier specification is expected. The functionality shall not cause any
functional regression to the supplier’s solution already integrated for PSA.
T1 PSA technical need expression: macroscopic requirements. A supplier spec
is expected.
T2 Design specification: detailed requirements are defined.
T3 Detailed specification with solution.
T4 Software component
GEN-SW-ORG-CDC-5-
5-1-78(1.0)
Le logiciel doit intégrer un diagnostic embarqué
de détection de la perte d'intégrité de données en
mémoire Flash.
The software shall integrate an embedded
diagnosis to detect the loss of data integrity in
the Flash memory.
6.1.1 Functional specifications list
La liste des spécifications Electrique et Electronique applicables au logiciel figure dans le tableau ci-
dessous :
Electric & Electronic applicable specification for software are listed in the table below :
Specification Reference Vers. In zip
01552_17_07115
TS_CAN_Communication_rules 00948_10_01988 2.0 x
STE_SECURISATION_TRAMES_9659842699_G 01554_10_00970 2.0 x
EMP2V3_EPS_CAN_ApplicationMatrix_01988v2 02016_15_04846 5.0 x
K5 EPS CAN Messaging and FH 01552_17_06896 1.0 x
K5 EPS Annex CAN Messaging and FH 01552_17_06897 1.0 x
ST_generique_Gerer_les_Phases_de_vie_organes_EE_SC CSEE_APPT09_0282 6.0 x
SWC_RCD 01552_09_00779 2.3 x
STIL_RCD_DD 01552_09_00553 2.4 x
K5 EPS RCD Applicative specification 01552_17_06899 1.0 x
DC_TI_20_Mechanisms_of_the_AEE2010_JDD […] 02016_15_04616 2.0 x
DC_TI_701_TS_Application_Layer_for_Diagnostic 02016_15_04617 1.0 x
DC_TI_702_TS_UDS_generic_mechanisms 02016_15_04618 2.0 x
DC_TI_703_TS_UDS_Configuration 02016_15_04619 1.0 x
DC_TI_705_TS_Reprogrammation_ECU 02016_15_04620 4.0 x
DC_TI_706_TS_Flash_Eprom_Application 02016_15_04621 1.0 x
DC_TI_707_TS_Electronic_Integration_and_putting_ECUs_into_operation 02016_15_04622 2.0 x
Fonctions de cryptage - partie 1* 96.298.009.99 x
Fonctions de cryptage - partie 2* 96.298.108.99 x
K5 EPS AN diagnoses services and communications 01552_17_06901 1.0 x
CANdelaPSATemplate_ODX_Reference 0000002901_02 5.0 x

01552_17_06898 1.0 EPS_K5 20 / 32
DAE_EMP2V3_UDS2_V7 0000003365_00 1.0 x
ST diag et DTC DAE 01452_12_00134 3.0
K5 EPS Preliminary Diagnosis Matrix 01552_17_06902 1.0 x
K5 EPS
TS_EPS_Produce_RCA_with_estimated_and_memorized_offset_(CAV3_virtual)
01552_17_06900 1.0 x
EN_Note_technique_AVA 01554_10_04507 2.0
ST Démarrage/Arret Assistance 01452_12_00155
STT EPS Steering monitoring strategy
ST Limitation de courant 01142_15_01159
LXA/HAD function TS
ST ACT DAE 02016_15_07876
PSA_ECU_Cybersecurity_Requirements_for_authentication_and_cryptology** 02016_15_05135 3.0 x
NB*: les documents "confidentiel" sont transmissibles au FNR avec un engagement de confidentialité.
NB: confidential documents can be transmitted with a confidentiality commitment.
NB**: le document ECU Cybersecurity Requirements for authentication and cryptology pourra devenir
caduque avec l’application du document [013]. Sera rediscuté durant la RFQ.
NB**: the document ECU Cybersecurity Requirements for authentication and cryptology might become
obsolete and superseded by the document [013]. To be discussed durint RFQ.
6.1.2 Software components list from PSA
Pour la fonction “RCD”, PSA fournit un module logiciel (SW-C), compatible du standard Autosar mais
qui ne requiert pas nécessairement une plateforme Autosar.
For the « RCD » function, PSA provides a software component (SW-C), compliant with the Autosar
standard but can be integrated in a non-Autosar platform.
6.1.3 Bugfixes list
6.1.4 Exception sheets list
6.2 PERFORMANCE REQUIREMENTS
Les exigences de performance sont intégrées dans les spécifications fonctionnelles du paragraphe 6.1.1 et
dans les exigences opérationnelles et de contraintes.
The performance requirements are integrated in the functional specifications listed in §6.1.1 and in the
operational & constraints requirements.
Le logiciel doit pouvoir évoluer suite à l’introduction de nouvelles fonctionnalités ou pour des besoins de
mise au point, avant et après le premier démarrage série.
New features or modifications could be implemented in the SW before and after the first SOP.
6.2.1 CPU load

01552_17_06898 1.0 EPS_K5 21 / 32
GEN-SW-ORG-CDC-5-
5-2-10(1.1)
Le FNR doit prévoir dans son logiciel un moyen
de mesurer en temps réel la charge CPU.
The supplier shall implement in its software a
way to measure in real time the consumed CPU
load.
GEN-SW-ORG-CDC-5-
5-2-30(1.1)
La lecture du taux de charge CPU doit être
inhibée sur un logiciel destiné à la
commercialisation. (logiciel MASTER à partir
du stade véhicule PRSEL2).
CPU load reading access shall be inhibited on
commercialized software (master software after
the PRSEL2 milestone).
GEN-SW-ORG-CDC-5-
5-2-40(1.1)
Dans la phase de vie du produit
« développement jusqu’à ADLC » la charge
CPU maximale d’un logiciel livré à PSA ne doit
pas dépasser 80% par cœur de processeur.
For product phase “development until ADLC”,
the maximum CPU load used by any software
delivered to PSA shall not be over 80 % for each
processing core.
GEN-SW-ORG-CDC-5-
5-2-50(1.3)
Dans les phases de vie du produit « vie série,
dont maintenance » la charge CPU maximale
d’un logiciel livré à PSA ne doit pas dépasser
90% par cœur de processeur.
For product phase “serial production,
maintenance”, the maximum CPU load used by
any software delivered to PSA shall not be over
90 % for each processing core.
GEN-SW-ORG-CDC-5-
5-2-71(1.0)
En aucune phase de vie du produit des
glissements de tâches (perte d'occurrence
d'exécution) ne doivent se produire dans le
système.
Task overrun (loss of execution occurrence)
shall never occur in the system whatever the life
situation of the product.
6.2.2 Memories occupancy

01552_17_06898 1.0 EPS_K5 22 / 32
GEN-SW-ORG-CDC-5-
5-2-112(2.2)
Le logiciel, pour le contenu fonctionnel décrit
dans le paragraphe 6.1 et pour toutes les versions
avant l’ADLC, ne doit pas utiliser plus de 95 %
de la RAM globale du calculateur.
For the functional content that is described in
§6.1and for all release until ADLC, the software
shall not use more than 95 % of each type/zone
of RAM memory.
GEN-SW-ORG-CDC-5-
5-2-114(2.2)
de la NVRAM globale du calculateur.
shall not use more than 95 % of ECU NVRAM
memory.
GEN-SW-ORG-CDC-5-
5-2-116(2.2)
de la ROM globale du calculateur.
shall not use more than 95 % of ECU ROM
memory.
6.2.3 Stack management
GEN-SW-ORG-CDC-5-
5-2-101(2.0)
Le FNR doit garantir l'absence de débordement
de pile quelles que soient les conditions de vie
du produit. A ce titre une réserve de pile d’au
moins 30% doit être prévue.
Supplier shall guarantee no stack overflow
whatever the life situation. As a consequence, at
least 30% of spare space shall be reserved.
6.3 EXTERNAL INTERFACES REQUIREMENTS
6.3.1 Context Diagram

01552_17_06898 1.0 EPS_K5 23 / 32
6.3.1.1 Purpose of the control unit
6.3.1.2 Global overview
6.3.2 CAN network(s)
Le calculateur est connecté à d’autres calculateurs du véhicule ainsi qu’aux outils fin de chaîne et après-
vente par une ou des liaison(s) CAN.
Les protocoles de communications ainsi que les trames et paramètres sont définies dans les spécifications
applicable (voir §6.1).
Le protocole de bypass par le réseau CAN est spécifié dans le document [010]
The ECU is connected to others vehicle control units and also to end of line and after sales tools via CAN.
The requirements related to communication (protocol, frames and parameters) are defined in the list of
functional specifications (see §6.1)
Requirements related to protocol communication for bypass via CAN are defined in document [010]
6.3.3 FLEXRAY network(s)
6.3.4 Serial links
6.3.5 Wired inputs/outputs
Le traitement du signal des entrées filaires ainsi que les diagnostics électriques à réaliser sont définies
dans les spécifications du §6.1
Signal processing of wired inputs and electrical diagnosis to realize are defined in specification of §6.1
6.3.6 Bypass links
6.4 OPERATIONAL REQUIREMENTS
6.4.1 Mission profile
6.4.2 Software life cycle
L’environnement du logiciel est défini par les quatre situations de vie principales suivantes :
 La phase de développement du logiciel où le logiciel est intégré dans des calculateurs de
développement et des calculateurs représentatifs de la série par le FNR ou par téléchargement
par PSA avec les outils de développement.

01552_17_06898 1.0 EPS_K5 24 / 32
 Les phases de préséries et série, pour lesquelles :
 Le logiciel est masqué et physiquement intégré au calculateur ;
 Le logiciel applicatif et les calibrations sont téléchargés en fin de chaîne chez le FNR ;
 Le logiciel applicatif est téléchargé en fin de chaîne chez le FNR, les calibrations sont
téléchargées chez PSA ;
 Le logiciel est téléchargé en fin de chaîne chez PSA.
 La phase d’utilisation clientèle où le logiciel est utilisé au sein des véhicules des clients.
 La phase APV où le logiciel est diagnostiqué et mis à jour.
Les phases de vie propres au logiciel (boot, réveil, téléchargement, diagnostic…) sont décrites dans
le paragraphe 6.1.
Software environment is defined by the 4 following states:
 Development phase during which software is integrated into development ECUs and
representative ECUs to industrialized products. The software can also be downloaded by
PSA with development tools.
 Preproducion and mass production phase for which:
 The software is masked and physically integrated to the hardware
 The application software and the calibration file are downloaded by the supplier
 The application software is downloaded by the supplier and the calibration file is
downloaded by the car maker in end of line
 The application software and the calibration file are downloaded by the car maker in
end of line.
 The “customer use” phase, where the software is used within vehicles by customers.
 The after-sales phase, where the software is diagnosed and updated.
The software phases (boot, wake-up, download, diagnostics…) are described in § 6.1.
6.4.3 Lifetime
La durée de vie du logiciel (des logiciels) commence dès la première livraison à PSA jusqu'à la fin de la
période de maintenance du calculateur réceptacle (cf. document [005]).
Software lifetime starts by the first delivery to PSA until end of maintenance of the associated ECU.(see
document [005])
6.4.4 Ergonomics and human factors
6.4.5 RAMS requirements
6.4.5.1 Reliability

01552_17_06898 1.0 EPS_K5 25 / 32
6.4.5.2 Maintainability
6.4.5.3 Availability
6.4.5.4 Safety
GEN-SW-ORG-CDC-5-
5-4-10(1.0)
Le développement du logiciel et le logiciel lui-
même doivent respecter le standard de sécurité
ISO26262.
Regarding safety, the software development as
well as the software itself shall respect the
ISO26262 standard.
6.4.6 Product quality
En dehors des aspects sûreté de fonctionnement définis dans le chapitre 6.4.5.4, les exigences sur la qualité
du logiciel sont exprimées dans les documents [007] et [008].
Apart from the safety aspects defined in chapter 6.4.5.4, the software quality requirements are specified
into the documents [007] and [008].
6.4.7 Protection against hostility
GEN-SW-ORG-CDC-5-
5-4-50(1.1)
Afin de se prémunir contre le piratage du
logiciel, PSA demande l’implémentation d’une
fonction d’accès sécurisé à la mémoire
reprogrammable. La description de cette
fonction repose sur deux documents
confidentiels non transmis sur support
informatique ni photocopiés et qui sont
transmissibles sur demande à partir de la phase
de consultation.
In order to avoid software hacking, PSA
requests that the supplier implements a function
to secure the access to programmable memory.
This function is described in two confidential
documents that are not transmitted on electronic
support. They are transmitted upon request
during the “request for quotation” phase

01552_17_06898 1.0 EPS_K5 26 / 32
6.4.8 Resources reserve capacity of the system
Les exigences de ressources sont couvertes par le CDC HW [005].
The resources requirements are included in the Hardware specification.
6.4.9 Document requirements
Les exigences documentaires sont définies dans le document [008]
Requirement related to document to provide are defined in document [008]
6.5 CONSTRAINT REQUIREMENTS
6.5.1 Regulation and consumerism
6.5.2 Weight and other physical characteristics
Cf. CDC HW [005].
6.5.3 Design and Manufacturing
6.5.3.1 Design process
GEN-SW-ORG-CDC-5-
5-5-58 (1.0)
Le fournisseur doit garantir qu’en cas d’une
modification de l’adressage mémoire, chaque
fichier de calibration reste compatible avec le
nouveau software développé.
The supplier shall guarantee that in case of no
memory mapping modification, each calibration
file is still compatible with a newly developed
software.
GEN-SW-ORG-CDC-5-
5-5-59 (1.0)
Le fournisseur doit garantir que chaque software
est configurable par le téléchargement d’un
fichier de calibration.
The supplier shall guarantee that each software
is configurable by downloading a calibration
file.

01552_17_06898 1.0 EPS_K5 27 / 32
GEN-SW-ORG-CDC-5-
5-5-60 (1.0)
Le fournisseur doit développer sur une branche
logicielle maximum par hardware.
The supplier shall develop one software branch
maximum per hardware.
GEN-SW-ORG-CDC-5-
5-5-70 (1.0)
Le fournisseur doit respecter les contraintes de
cybersécurité énnoncées dans le document
[013].
The supplier shall respect the cybersecurity
constraints as written in document [013].
6.5.3.2 Software components
6.5.3.3 Software architecture
Les valeurs des paramètres de ces exigences sont listées dans le §7
Parameters Values of this requirement are listed in §7
GEN-SW-ORG-CDC-5-
5-5-130(1.1)
Le FNR doit concevoir l'architecture logicielle
de manière à pouvoir inhiber individuellement
chacune des fonctions spécifiées par PSA à
l’exception de la fonction ADC. L'inhibition
signifie que la fonction n'est pas exécutée et que
les messages CAN associés sont émis avec des
valeurs par défaut.
The supplier shall design its software
architecture so that any PSA function could be
individually inhibited, except from the
immobilization function. Inhibiting a function
means that the function is not executed and the
associated CAN data are fixed to their default
values.

01552_17_06898 1.0 EPS_K5 28 / 32
GEN-SW-ORG-CDC-5-
5-5-140(1.1)
L’architecture du logiciel doit permettre la
suppression de fonctions PSA sans surcoût autre
que ceux concernant la mise à jour
documentaire, les tests de non régression et les
tests d’intégration.
The software architecture shall provide a mean
to delete any PSA function without any other
cost than those required for documentation
update and non regression test.
6.5.3.4 Coding tools and language
GEN-SW-ORG-CDC-5-
5-5-180(1.2)
Pour générer la version logicielle, le FNR doit
utiliser uniquement les outils et langages de
programmation décrits dans son plan de
développement.
To generate the software release, the supplier
shall only use the coding tools and languages
described in his development plan
6.5.3.5 Calibration and prototyping tools
Les exigences sur les outils de mise au point et de calibration sont exprimées dans les documents [008] et
[011].
The software quality requirements on calibration and prototyping tools are specified into the documents
[008] and [011].
GEN-SW-ORG-CDC-5-
5-5-370(1.1)
Pour chaque logiciel livré, le FNR doit intégrer
les calibrations des fonctions telles que prévues
lors de la revue de confirmation.
In each delivered software version, the supplier
has to implement the calibrations that have been
defined during the confirmation review
6.5.3.6 Studies and/or imposed solutions

01552_17_06898 1.0 EPS_K5 29 / 32
6.5.3.7 Materials
6.5.3.8 Manufacturing
6.5.3.9 Marking of the Components or Parts
6.5.4 Product identification
6.5.4.1 Generic software identification
GEN-SW-ORG-CDC-5-
5-5-400(1.1)
Un logiciel générique doit être identifié par le
FNR par une référence unique.
A generic software shall be identified by the
supplier with a unique reference.
GEN-SW-ORG-CDC-5-
5-5-410(1.2)
La référence unique du logiciel générique doit
apparaître dans le nom du fichier du logiciel
livré.
The unique reference of the generic software
shall appear shall appear in the file name of the
SW delivered.
6.5.4.2 Master software identification
GEN-SW-ORG-CDC-5-
5-5-450(1.1)
Le logiciel Master doit être identifié par le FNR
en utilisant la référence PSA décrite dans la
fiche d’officialisation.
Master software has to be identified using the
reference communicated to the supplier via an
officialisation sheet.

01552_17_06898 1.0 EPS_K5 30 / 32
GEN-SW-ORG-CDC-5-
5-5-460(1.2)
La référence unique du logiciel Master doit
apparaître dans le nom du fichier du logiciel
livré.
The unique reference of the master software
shall appear in the file name of the SW
delivered.
6.5.5 Traceability and configuration
GEN-SW-ORG-CDC-5-
5-5-570(1.1)
Chaque module logiciel (fichier) constitutif doit
être identifié par une référence unique, un indice
d’évolution et une date.
Each software module (file) shall be identified
by a unique reference and a version number and
a date.
GEN-SW-ORG-CDC-5-
5-5-580(1.1)
Chaque spécification d’un module logiciel doit
être identifiée par une référence unique, un
indice d’évolution et une date.
Each specification of a software module shall be
identified by a unique reference and a version
number or a date.
GEN-SW-ORG-CDC-5-
5-5-590(1.1)
Chaque exigence de chaque spécification FNR
doit être identifiée par une référence unique.
Each requirement of each supplier specification
shall be identified by a unique reference.
6.5.6 Transportability, storage, and packaging

01552_17_06898 1.0 EPS_K5 31 / 32
GEN-SW-ORG-CDC-5-
5-5-730(1.2)
La livraison du logiciel se fait via un outil B2B.
Software delivery shall be done by B2B tool.
6.5.7 Flexibility and extension
GEN-SW-ORG-CDC-5-
5-5-740(1.1)
Le logiciel doit être, par défaut, compatible avec
deux versions matérielles successives (en
particulier lors du passage des prototypes B vers
les prototypes C). Toute dérogation à cette
exigence doit être discutée lors de la revue de
figeage de la version logicielle au plus tard.
The software shall be compatible with two
consecutive hardware versions. (Especially
between B sample and C sample) Should there
be derogation to this requirement, it has to be
discussed no later than during the software
content freeze review
6.5.8 End of life
6.5.9 Withdrawal
6.5.10 Environment conditions
6.5.11 Planning
6.5.11.1 Global software development planning

01552_17_06898 1.0 EPS_K5 32 / 32
GEN-SW-ORG-CDC-5-
5-5-810(2.0)
Le développement du logiciel doit être cohérent
avec le planning global du projet, dont les jalons
majeurs APQP.
The software development shall be consistent
with the overall project schedule, including
APQP milestones.
6.6 INTEGRATION AND VALIDATION REQUIREMENTS
6.6.1 INTEGRATION
GEN-SW-ORG-CDC-5-
5-6-10(1.0)
Le calculateur devra pouvoir supporter le
protocole XCP_on_CAN sur les versions de
developpement (« calculateur ouvert ») sur
demande PSA.
The ECU shall be able to stand the
XCP_on_CAN protocol on development
version (“open ECU”) on PSA request.
6.6.2 Tests and Validation
Les exigences sur les tests et la validation du logiciel sont exprimées dans le document [008].
The requirements on tests and validation of the software are specified into the documents [008].
Le processus de validation et les moyens humains et techniques associés doivent être décrits dans le plan
de développement.
The validation process and associated human and technical resources shall be described in the
development plan.
7 PARAMETERS
8 TRACEABILITY MATRIX

K5 SW Requirements Packs for Request for Quotation

Recommandé

Recommandé

Contenu connexe

Similaire à K5 SW Requirements Packs for Request for Quotation

Similaire à K5 SW Requirements Packs for Request for Quotation (20)

Plus de azrfdstgdgdfh

Plus de azrfdstgdgdfh (20)

K5 SW Requirements Packs for Request for Quotation