Un processus de conception des logiciels distribués pour l’automobile

Présentation au sujet: "Un processus de conception des logiciels distribués pour l’automobile"— Transcription de la présentation:

1 Un processus de conception des logiciels distribués pour l’automobile
Le contexte du logiciel automobile embarqué Du système à l ’inter-systèmes Les évolutions processus Les projets coopératifs qui supportent ces évolutions Un exemple Application aux systèmes critiques et conclusion

2 Caractéristiques des logiciels embarqués automobiles
Réseaux de Bord Multimédia Réseaux critiques Défense/Espace Chassis Contrôle Moteur X-by-Wire Compléxité temps-réel réel Télécommunications Traitement de signal Réseau Medical, Aviation contraintes de sécurité Logiciel automobile embarqué Grand Public Automatisation Acquisition de données Contrôle Volume de Production (x ) Sensibilité au coût Régulations moteur, chassis Internationalisation forte concurrence Coût récurrent Diversité (x 100) Mix gamme/Taux de monte et d ’options

3 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és Spécification câblage Validation - Intégration Diagnostic

4 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 volume L ’interface entre composants est la plus simple et la plus standard/petite possible afin de permettre une validation et une intégration rapide La 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)

5 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és La 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)

6 Réduction des délais de conception Que faut-il réutiliser?
Comportement prestation Architecture Fonctions Commandes, Captures Perennité Spécificité Projet Capteurs, Actionneurs Calculateurs Cablage

7 Processus actuel: orienté pièces
F3: GB ECU 3 F2: EC ECU 2 F1: ABS Model ECU 1 Implem- entation Specifi- cation 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, Diag Pour chaque calculateur 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

8 Processus favorisant la capitalisation: orienté prestation
Prestation pour le client (demande du produit, du projet véhicule) Capitalisable Réutilisable sur plusieurs projets Véhicule Spécification de la prestation: com-portement, architecture fonctionnelle interface, phases de fonctionnement, analyse SdF fonctionnelle, Diagnostic fonctionnel Function Model Database Functions 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 Flexible Appliqué sur un projet Véhicule ECU ECU Implémentation des prestations visibles du client sur différents ECUs La spécificaiton d’une ECU est pas nécessairement capitalisable

9 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_transport Développement d ’un « middleware » permettant la portabilité des composants logiciels Outils de conception et de vérification prototypes Démonstrateurs Le projet EAST-EEA qui est l ’extension de AEE au niveau européen

10 Un exemple

11 Application aux systèmes critiques
Déclinaison des caractéristiques de tolérance aux fautes sur un langage de description d ’architecture Prise 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 candidates Vérifications a posteriori de l ’atteinte des objectifs (taux de défaillance par unité de temps) par prestation

12 Conclusion L ’introduction d ’un processus « orienté prestation »
permet de gérer l ’inter-système Le processus touche d ’abord les fonctions distribuées et nomades Cette approche « top down » devrait s ’étendre naturellement au développement des systèmes critiques