renault/ direction de la recherche / département electronique / s. boutin un processus de...
TRANSCRIPT
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