Renault/ Direction de la Recherche / Département Electronique / S. Boutin

Un processus de conception des logiciels distribués pour

l’automobile

Le contexte du logiciel automobile embarquéDu système à l ’inter-systèmesLes évolutions processusLes projets coopératifs qui supportent ces

évolutionsUn exempleApplication aux systèmes critiques et conclusion

Renault/ Direction de la Recherche / Département Electronique / S. Boutin

Caractéristiques des logiciels embarqués automobiles

Défense/Espace

Compléxité temps-réelréel

Diversité (x 100)Mix gamme/Taux de monte

et d ’options

Logicielautomobileembarqué

Medical, Aviation

contraintes de sécurité

Télécommunications

Traitement de signalRéseau

Automatisation

Acquisition de donnéesContrôle

Internationalisationforte concurrence

Grand Public

Volume de Production (x 100 000)

Sensibilité aucoûtcoût

ChassisContrôle MoteurX-by-Wire

Réseaux de BordMultimédiaRéseaux critiques

Régulationsmoteur, chassis

Coût récurrent

Renault/ Direction de la Recherche / Département Electronique / S. Boutin

Le modèle « ensemblier »

Entrée (Définition produit): « Cahier des Charges Prestations Quantifiées »

Sortie (vers les équipementiers, usines, après-vente):Spécifications des différents sous-systèmes ou composants

qui seront ensuite intégrésSpécification câblageValidation - IntégrationDiagnostic

Renault/ Direction de la Recherche / Département Electronique / S. Boutin

Le modèle d ’échange constructeurs - équipementiers

suscite une approche « orientée pièce »

Forte externalisation (métier d ’ensemblier)L ’équipementier et le constructeurs recherchent des équipements standards pour bénéficier d ’effet volumeL ’interface entre composants est la plus simple et la plus standard/petite possible afin de permettre une validation et une intégration rapideLa spécialisation des différents secteurs contribue à conserver une architecture figée (chassis, habitacle, contrôle moteur-

BVA, télématique-multimédia)Délais de développement très courts, dépendances (shrink)

Renault/ Direction de la Recherche / Département Electronique / S. Boutin

Vers une conception électronique « orientée prestation »

L ’optimisation (cablage, composants) incite à concentrer différentes prestations sur le même calculateur Les modes (opérationnels, dégradés, énergie) doivent être coordonnésLa gestion réseau répond à des exigences transverses (notamment dans les phases d ’init) Il faut maintenir de nombreuses variantes (mix

gamme/options) Les fonctions nomades sont plus nombreuses Les fonctions distribuées sont plus nombreuses (Arbitrage couple, Interface conducteur, Chassis, X-by-Wire, Multimédia)

Renault/ Direction de la Recherche / Département Electronique / S. Boutin

Réduction des délais de conceptionQue faut-il réutiliser?

Comportement prestation

Commandes, Captures

Capteurs, Actionneurs

Calculateurs

Cablage

Architecture Fonctions

Spécifi

citéPro

jet P

ere

nnit

é

Renault/ Direction de la Recherche / Département Electronique / S. Boutin

ECU ECU

- Lorsque l’architecture des ECUs est modifiée, pour un nouveau projet véhicule,par l’arrivée de fonctions transversales, l’impact global des modifications est difficileà mesurer; capitalisation difficile pour les fonctions transversales ou nomades+ La gestion de projet pour chaque système est facilitée car locale

Prestation pour le client (définition produit)

Spécification des interfaces calculateurs (les “Electronic Control Units” ou ECU), description fonctionelle quand le constructeur est maître d’ouvrage, messagerie, gestion des phases de fonctionnement, analyse SdF, DiagPour chaque calculateur

F3: GB

ECU 3

F2: EC

ECU 2

F1: ABS

Model

ECU 1

Implem-entation

Specifi-cation

Processus actuel: orienté pièces

Renault/ Direction de la Recherche / Département Electronique / S. Boutin

Function Model Database

Functions

ECU ECU

Implémentation des prestations visibles du client sur différents ECUsLa spécificaiton d’une ECU est pas nécessairement capitalisable

Prestation pour le client (demande du produit, du projet véhicule)

Spécification de la prestation: com-portement, architecture fonctionnelleinterface, phases de fonctionnement, analyse SdF fonctionnelle, Diagnostic fonctionnel

Les éléments suivants sont générés en partie automatiquement: spécification des calculateurs (comportement, spec fonctionnelle), messagerie, spec interfaces, gestion des phases de fonctionnement, analyse SdF, Diagnostic

Capita

lisab

le

Réutil

isabl

e su

r

plus

ieur

s pr

ojet

s

Véhicul

e

Flex

ible

Appliq

ué sur

un p

rojet

Véhicul

e

Processus favorisant la capitalisation: orienté prestation

Renault/ Direction de la Recherche / Département Electronique / S. Boutin

Les projets coopératifs dans lesquels cette approche est développée

Le projet Architecture Electronique Embarquée Développement d ’un langage de description d ’architecture (AIL_transport)Développement du C_transportDéveloppement d ’un « middleware » permettant la portabilité des composants logicielsOutils de conception et de vérification prototypesDémonstrateurs

Le projet EAST-EEA qui est l ’extension de AEE au niveaueuropéen

Renault/ Direction de la Recherche / Département Electronique / S. Boutin

Un exemple

Renault/ Direction de la Recherche / Département Electronique / S. Boutin

Application aux systèmes critiques

Déclinaison des caractéristiques de tolérance auxfautes sur un langage de description d ’architecturePrise en compte de facteurs de tolérance aux fautes au niveau prestation (modèle comportemental + modèles des capteurs et actionneurs)Placement et déclinaisons des prestations sur des architectures matérielles candidatesVérifications a posteriori de l ’atteinte des objectifs (taux de défaillance par unité de temps) par prestation

Renault/ Direction de la Recherche / Département Electronique / S. Boutin

Conclusion

L ’introduction d ’un processus « orienté prestation »

permet de gérer l ’inter-systèmeLe processus touche d ’abord les fonctions

distribuées et nomadesCette approche « top down » devrait s ’étendre

naturellement au développement des systèmes critiques