CONTEXTE & ENVIRONNEMENT => ASE

29/06/2022 H.ARNANAS
Plan

1. Structure d’ingénierie

2. Entrées & Sorties

3. Métiers connexes (Safety, diag, cyber, etc)

2
STRUCTURE D’INGENIERIE

Pourquoi on a besoin de la structure d’ingénierie ?

 La stratégie du groupe :
❑ Concurrence
1. La montée en gamme
❑ Complexité
2. L’internationalisation
STRUCTURE D’INGENIERIE

L’approche system

C’est à la fois une manière de penser et un standard méthodologique international d’ingénierie dont l’objet est de
maîtriser la complexité des systèmes pour améliorer la qualité, le coût, le time to market et la performance.
STRUCTURE D’INGENIERIE

La structure de données:

Operational Why the system is

View designed for?
(Why?) System outside
Use cases

System Boundary

Function System inside

Functional What does the
View Function system do?
(What?)
Function

Function

Constructional
View How do we
physical physical physical physical
(How?) concretely
constituents constituents constituents constituents
implement the
functions?
STRUCTURE D’INGENIERIE

La structure de données:
STRUCTURE D’INGENIERIE

La structure d’ingénierie à Stellantis (organisation)

STRUCTURE D’INGENIERIE

La référence de la structure d’ingénierie

Ref
Stockage dans le Docinfo : 20061_14_01139
Multigamme product line dans PLM:
ENTRÉE & SORTIES

Les exigences sont généralement les I/O de chaque couche

1. Les exigences clients
2. SSP (Service Specification)
3. SSD (SubSystem Design) et architecture fonctionnelle
4. DCI (Dossier de Conception Interfaces)/EEAD (Electric Electronic Architecture Design)
5. CDC (Cahier Des Charges) ou STO (Specification Technique Organe)
6. Code
7. Les rapports de tests

Autres livrables :

1. Safety :
**HARA (Hasards And Risk Analysis)
**FSC (Functional Safety Concept)
**TSC (Technical Safety Cocept)
2.Diag
**TSD (Tableau Synthese Diagnosticabilité)
**F4C (Fichier 4 colonnes) ou DNF (Diagnosis Need File)
**Matrice Diag
LES MÉTIERS CONNEXES

Safety : ISO26262

❑ Sévérité : de S0 (aucune blessure) à S3 (blessures mortelles avec survie incertaine ou décès)

❑ Exposition : ded’ASIL
Les niveaux E0 (probabilité invraisemblable)
(Automotive à E4
System Integrity (probabilité
Level) : élevée)
❑ Contrôle (la probabilité que le conducteur puisse agir de lui-même pou prévenir le danger ou
la blessure) : de C0 (contrôlable en général) à C3 (difficilement contrôlable ou impossible)

ASIL B

ASIL A ASIL D

QM = ASIL
0
ASIL C
LES MÉTIERS CONNEXES

Process Stellantis (Sécurisation)

1. Le besoin sera décrit dans TSC (Technical Safety Concept) or FSC (Functional Safety Concept) =>
exigence amont TSR (Technical Safety Requirement) ou exprimée en anticipation par RAMS
Designer de sous systèmes.
2. FTL: Créer une ISSUE de type demande d’évolution avec EC.
3. CA SS impacté: Insérer la TSR dans la RSP (parag Operational Req -> Op Safety -> Mainteability)
[Actions -> medini data import -> template (TSC)]
4. Si ASIL QM => rien à faire
Si ASIL A => Bit de parité
Si ASIL B+ => Sécurisation E2E
5. CA EEAD Infra (E2E) : Pour E2E il faut demander la sécurisation de la trame (si n’est pas sécurisé)
selon standard PSA (si trame <=8bits donc checksum(4b) et CPT (4b) ou AUTOSAR (si trame >8) et on
aura un CRC(8b) et CPT(4b)) au CA de l’EEAD E2E.
6. Le CA de EEAD E2E : créer les interfaces suivantes dans CATIA (domaine SAFETY_MANAGE_E2E):

*SFT : ECUp_E2E *SFT : ECUc_E2E

** FA : ECUp_PSA_PROD **FA : ECUc_PSA_PROD
***Flux: ECUp_PROD_CHECKSUM_TO_ECUc ***Flux: ECUc_PROD_COUNTER_TO_ECUp
** FA: ECUp_PSA_RECEIVE **FA: ECUc_RECEIVER
***Flux: ECUc_PROD_COUNTER_TO_ECUp **Flux: ECUp_PROD_CHECKSUM_TO_ECUc
LES MÉTIERS CONNEXES

Process Stellantis (Sécurisation d’un signal)

7. Le CA E2E: demander la création des signaux (s’ils n’existent pas) :

CHECKSUM_TRAME_NBB_ID & CPT_PROCESS_NBB_ID
8. Le CA E2E : créer des exigences EEAD
9. Le CA du SS impacté prod & conso): ajouter les fcts ECUp_E2E & ECUc_E2E comme fct de transfert et
ajoute les ref suivantes dans les doc applicables (EEAD) :
[SECURISATION_TRAMES] 01554_10_00970 9659842699 ind_H STE Sécurisation Trames par Checksum et Compteur de Processus
[END2END] 02016_16_01039 Adaptation of Sw-C End-to-end Communication Protection

NB: on a cité le cas de standard PSA, en cas de AUTOSAR il faut juste remplacer checksum par CRC et CPT par
ALIVE
LES MÉTIERS CONNEXES

Diagnostic

Le diagnostic est une étape indispensable pour assurer la sécurité et la santé de véhicule. Il
permet de détecter un éventuel dysfonctionnement au sein de la voiture et de le corriger.

Un diagnostic électrique et électronique : les capteurs, l'ensemble du système électrique liée

à la batterie de véhicule (perte de com [NW, trame], circuit ouvert, court circuit, sous tension,
sur tension, défaut interne électronique, fils dysfonctionnel, etc)
Un diagnostique fonctionnel: concerne le comportement des flux (out of range, valeur
invalide, défaut interne de l’ECU, etc)
Un diagnostic des pièces mécaniques non liées à des capteurs : certaines informations
peuvent être manquantes en connectique. Il faut donc procéder à une vérification manuelle
des pièces mécaniques concernées. => n’est pas assuré à notre niveau.
LES MÉTIERS CONNEXES

Diagnostic

▪ 3 différentes défaillances: Détection – les modes dégradés – l’enregistrement DTC

Failure detection Degraded mode

DTC recording

▪ Detection des defauts est spécifiée par EE architecte pour les défauts EE et par le spécifieur
fonctionnel pour les défauts fonctionnels.
▪ Les modes degrades sont specifiés par le fonctionnel, sauf pour la valeur de signal à appliquer en
cas d’une défaillance réseau.
▪ DTC recording est spécifiée par EE architecte pour les défauts EE et par le spécifieur fonctionnel
pour les défauts fonctionnels.
LES MÉTIERS CONNEXES

Diagnostic
Failure OI SSD/INFRA EE FUNCT/EE Comment

Absence flow (EE et/ou méca) SSD TBC by SSD Architect Caused by : Loss of frame or wired connexion default or ECU
component failure

Calibration INFRA EE EE Caused by :failed and/or corrupted calibration

fuse failure : To delete from DNF Infra EE EE Archi Electrique

Loss of power supply : To delete from DNF Infra EE EE Archi Electrique

Power supply failure (too low or high level) SSD EE

loss of communication : Loss of Network Infra EE EE

loss of frame / Loss of ECU SSD EE

BUS OFF (integrated in loss of network) SSD EE Archi réseau

ECU MUTE (integrated in loss of network) SSD EE Archi réseau

ECU RESET(No DTC required for aftersales & Factory) SSD EE or fct Component

Internal failure SSD Fct Sensor/actuator embedded in the ECU

Internal failure SSD EE complete internal failure (electronic ko)

invalid value / out of range on functional flow SSD Fct

out of range on EE signal SSD EE

Loss of telecoding INFRA EE EE Caused by :failed and/or corrupted telecoding

soft download fault INFRA EE EE

touch command / push blocked SSD fct

Short circuit / Open circuit SSD EE

Checksum invalid SSD EE

Rolling Counter frozen SSD EE

Flow values incoherence SSD Fct

LES MÉTIERS CONNEXES

Telediag

Le diag à distance de chaque ECU => les requettes de diag sont envoyées par BSRF aux ECUS
(via une passerelle VSM). Ces ECUs envoient à leur tour une réponse au BSRF qui sera
consommé par l’offboard.

=> Pour chaque ECU, il y a un couple Trame Requete/réponse.

LES MÉTIERS CONNEXES

Cyber Securité

La cybersécurité est la mise en œuvre d’un ensemble de techniques et de solutions de

sécurité pour protéger la confidentialité, l’intégrité et la disponibilité des informations. Cette
protection doit couvrir tout le cycle de vie des données, de leur génération et traitement, à
leur transfert, stockage et élimination.
LES MÉTIERS CONNEXES

Cyber Securité : MASCOM

MASCOM est un protocol PSA qui vise à authentifier des événements CAN échangés entre 2 ECUs
(Généralement entre BSRF/VSM => offboard) . La clé principale est :
Un message commande (aka ‘order’) est envoyé en CAN. Sa signature est envoyé dans le prochain
message CAN. Le destinataire passe la commande à son client de couche supérieure uniquement si la
signature est vérifiée avec succés.

Le protocol est compose de 4 étapes:

❖ L’authentification mutuelle
❑ TX ECU authenitife RX ECU
❑ RX ECU authentifie TX ECU
❖ Session clé etablie
❑ Une session clé est calculée à la fois par TX et RX ECU
❖ Packet signé échangé
❑ Pour chaque CAN commande envoyée, une commande CAN additionnelle signee est générée
❖ Fin de session
❑ La clé de session doit être actualise
❑ Le nombre maximum de messages est atteint
LES MÉTIERS CONNEXES

Cyber Securité : SEACOM

SEACOM est un protocol PSA qui vise à authentifier des événements CAN échangés entre 2 ECUs
(généralement entre HFASM/SDCM & VSM => onboard).
ANNEXE
Connected System
FCT
Vehicle and device management
Remote vehicle interaction
Vehicle and user assistance
Vehicle and user data
Vehicle to everything
_Stubs
Connectivity and time management
Description
The “Vehicle and device management” domain covers the systems that manage the vehicle and the ECUs’
configurations and updates.
The “Remote vehicle interaction” domain covers the systems that allow an interaction with the vehicle over
the Internet or a wireless local area network.
The “Vehicle and user assistance” domain covers the systems that assist the user of the vehicle in case of
emergency or breakdown, or provide the user various services like informational requests and travel
arrangements (a.k.a. concierge service).
The “Vehicle and user data” domain covers the systems that are capturing, storing, analyzing, and sharing
data either issued by the vehicle from various sources like sensors and ECUs, or data belonging to the user of
the vehicle.
The “Vehicle to everything” domain covers the HM2IC system that contributes to the complete V2X system
of the extended vehicle.
Stub domain for stub functions for flows not covered by the PLM v2 engineering structure.
The “Connectivity and time management” domain covers the systems that:
- manage the connectivity of the vehicle with the cloud platform.
- supply time to the vehicle, from various external sources.
ANNEXE
Vehicle and user data
FA
BIGDATA_COLLECT_AND_SEND
RMS_COLLECT_AND_SEND
REM_CONNECTED_SERVICE
SLI_CONNECTED_SERVICE
EI_BIGDATA_RECORDING_DEFECT_EVENT
DK_CONNECTED_SERVICE
EI_MSG_ROUTING
Description
Support for the Big Data system with:
- Data retrieval strategy (by signal, by frame, periodically, on change)
- Data history buffer management
- Data telemetry based on a fixed datablock set
- Data telemetry based on a variable datablock set that can be configured from the offboard side
Data telemetry used for the regulatory chinese "Remote Monitoring System"
Contribute to the Road Experience Management feature by:
- Accumulating RSD and RSD Summary “chunks”
- Assembling RSD and RSD Summary
- Managing and maintaining a ACK/Request state machine
- Validating CRC on the complete RSD buffer
- Maintaining the relationship between RSD Summary and the RSD data it relates to
- Uploading the RSD Summary to the cloud
- Uploading the complete RSD to the cloud
Contribute to the GSR SLI feature by:
- Retrieving the position of the vehicle
- Requesting the current speed limit to the offboard cloud platform
Infra EE fonction that present the amount and number of frames to avoid the superposition of other signals (deect event recorded)
Contribute to the Digital Key feature mainly by:
- Trigerring the primary user authorization sequence
- Downloading the vehicle certificate
- Downloading the vehicle key certificate
Infra EE FA that contribute to the following services:
- Conversion MQTT <--> CAN
- Message routing