Soutenance mémoire
La mécatronique dans l’automobile
Définition
Depuis la fin des années 1990, l’industrie automobile a adapté sa manière de concevoir un véhicule. Le déferlement des innovations électroniques et informatiques conduit à l’introduction de composants électroniques pilotés par l’informatique, en remplacement de composants mécaniques et hydrauliques : c’est l’émergence de la mécatronique.
Définition 1.1. La mécatronique est la démarche visant l’intégration en synergie de la mécanique, l’électronique, l’automatique et l’informatique dans la conception et la fabrication d’un produit en vue d’augmenter et/ou d’optimiser sa fonctionnalité (NF E 01-010, 2008).
L’intérêt de ce domaine d’ingénierie interdisciplinaire est de concevoir des systèmes automatiques pour permettre le contrôle de systèmes complexes. Il permet également de minimiser les coûts de développement et/ou développer rapidement de nouvelles fonctions. Les domaines ouverts à la mécatronique sont variés. Dans l’automobile, on les retrouve par exemple pour le contrôle du moteur (e.g. injection, turbocompresseur, recyclage des échappements, refroidissement), l’habitacle (e.g. airbags), le freinage (e.g. antiblocage ABS, freinage d’urgence), la direction (e.g. assistance de direction, contrôle de trajectoire ESP). Plus précisément, la mécatronique est composée de divers constituants qui interagissent :
– Les composants mécaniques, hydrauliques et de câblage sont les entités qui permettent le contrôle physique des différents organes du véhicule ;
– Le système de contrôle électrique/électronique (i.e. le système E/E) regroupe les entités matérielles et logicielles qui permettent de piloter de manière intelligente les composants mécaniques et hydrauliques en vue de remplir les fonctions du cahier des charges.
Cette nouvelle architecture permet également l’intégration et la mise en réseau des différents composants en vue de multiplexer les fonctions distribuées, de mettre en place des structures de pilotage hiérarchisées, d’intégrer des systèmes d’aide à la conduite ou encore de disposer de systèmes pour les diagnostics. Le nombre de composants électroniques (e.g. le nombre de calculateurs) a beaucoup augmenté ces 20 dernières années.
L’architecture électrique/électronique (E/E)
L’architecture E/E peut être divisée en quatre niveaux, Parmi ces niveaux, nous retrouvons les architectures fonctionnelle, logicielle, matérielle et opérationnelle. Une architecture E/E automobile s’exécute sur un ensemble de calculateurs appelés ECUs (Electronic Control Units), répartis dans le véhicule. Ces ECUs offrent des accès d’entrées/ sorties vers les autres composants du système mécatronique en vue d’interagir avec eux. Les capteurs récupèrent des signaux logiques ou analogiques à partir de l’environnement pour les fournir aux calculateurs (e.g. valeur d’un régime moteur, niveau des fluides, débit des injecteurs). Les calculateurs déduisent les commandes qu’il faut appliquer aux actionneurs pour que la fonction soit remplie.
Pour décrire le comportement requis pour l’ensemble des calculateurs, une analyse fonctionnelle de l’application est nécessaire. L’architecture fonctionnelle qui en est dérivée est une description à haut niveau des fonctionnalités attendues (fonctions applicatives). Celles-ci sont souvent découpées en blocs fonctionnels, ce qui permet de spécifier chaque composant indépendamment puis de décrire le comportement de l’ensemble. La description de cette architecture est réalisée très tôt dans le processus de développement et se conforme aux spécifications techniques des systèmes. La connaissance de l’architecture fonctionnelle permet de spécifier l’architecture logicielle. Celle-ci décrit les éléments du système, leurs interrelations et leurs interactions. Contrairement à l’architecture fonctionnelle qui décrit ce que le système fait, l’architecture logicielle décrit comment l’application est conçue pour qu’elle puisse réaliser les fonctions. Le découpage prévu doit permettre, après codage, de répondre aux contraintes temps réel dur qui sont requises. L’architecture matérielle est la description des composants matériels utilisés pour que l’application puisse remplir sa mission. Plusieurs critères sont étudiés : le nombre d’entrées/sorties, la puissance calculatoire, le nombre de cœurs, l’adéquation des calculateurs au domaine de fonctionnement, le nombre de contrôleurs CAN, etc. L’architecture matérielle décrit également la manière dont les ECUs communiquent entre eux via les réseaux (e.g. Control Area Network – CAN, Local Interconnect Network – LIN) dans le cas où des prestations complexes nécessitent l’intervention de plusieurs ECUs.
Enfin, l’application codée et déployée correspond au niveau opérationnel. Il est le résultat de la combinaison des niveaux d’architectures précédents.
De l’architecture fédérée à l’architecture intégrée
L’avènement des réseaux multiplexés dans l’automobile a conduit à la mise en place d’une architecture opérationnelle fédérée. Elle limite la complexité de l’implantation du logiciel puisqu’une ECU est dédiée à un type de travail (une ECU = une prestation) et un canal de communication est fourni pour permettre l’échange des messages. Ce type d’architecture facilite la démonstration de la sûreté puisqu’il limite naturellement le nombre de canaux de propagation d’erreurs en instaurant une séparation physique entre les prestations. En revanche, l’ajout d’une nouvelle prestation impose l’ajout d’une nouvelle ECU. De plus, la mise en place de prestations complexes peut malgré tout nécessiter le partage d’informations entre les ECUs (e.g. capteurs) et imposer la mise en place d’une infrastructure physique importante pour la communication (e.g. câblage, réseau).
L’évolution a conduit à l’introduction d’un second type d’architecture : l’architecture intégrée. Elle autorise l’implantation de plusieurs sous-systèmes distribués (DAS – Distributed Application Subsystem) au sein d’une unique ECU, ce qui a pour effet d’en diminuer le nombre ainsi que la quantité de points de connexion. Il en résulte un coût d’infrastructure moins élevé et une maintenance plus aisée. En revanche, autoriser plusieurs types de prestations à s’exécuter sur une même ECU supprime la barrière physique que l’on avait avec la précédente architecture. Il en résulte un accroissement de la complexité du logiciel, nécessaire pour assurer la maîtrise du comportement et un effort supplémentaire pour répondre aux problématiques de sûreté de fonctionnement est donc nécessaire. Ces objectifs sont concrétisés par l’élaboration du standard de développement logiciel AUTOSAR et de la norme de sûreté de fonctionnement ISO 26262 .
L’industrie automobile utilise depuis quelques années ce dernier type d’architecture pour intégrer des sous-systèmes différents sur le même calculateur.
Processus de développement d’une architecture E/E
L’ingénierie système
L’ingénierie système, définie par l’Association Française d’Ingénierie Système (AFIS, 2013), est la démarche méthodologique progressive prenant en compte l’ensemble des activités, pour contrôler la conception de systèmes complexes. Il s’agit d’un processus de haut niveau qui englobe l’ensemble du cycle de vie. Le cycle de vie d’un système désigne ses différentes phases de vie, regroupées dans les catégories suivantes : conception, production, distribution, exploitation, élimination. L’ingénierie système se focalise sur la définition des besoins exprimés par le client au début de la phase de conception (i.e. exigences fonctionnelles), et sur les architectures. Une fois les exigences analysées, elle assure le suivi du processus global de mise au point, de la conception à l’intégration : i.e. l’environnement, le contexte, les enjeux, les coûts, la planification et la répartition des tâches, le pilotage du projet, la conception, la maintenance et la fin de vie. En particulier, la conception du système fait appel à l’ensemble des domaines appelés IVVQ (Intégration, Vérification, Validation, Qualification), mettant en place les stratégies nécessaires à l’atteinte de la conformité et de la qualité, tout en optimisant au mieux les objectifs QCD (Qualité, Coût, Délais). Ce processus nécessite l’utilisation d’outils logiciels (e.g. dSpace, Simulink) et la mise en place d’un atelier de développement spécifique. Ceci a pour but de rationaliser la production d’un système et son suivi.
Chez Renault, le processus de conception est rythmé par une logique de développement visant à gérer les acteurs de l’entreprise de façon coordonnée. Ce processus est décomposable en trois phases : la phase d’avant projet (e.g. étude de faisabilité), la phase projet (i.e. conception) et la phase d’industrialisation. Les spécificités du secteur automobile nécessitent également de gérer les interactions entre OEM (Original Equipment Manufacturer – le constructeur) et les équipementiers de rangs 1, 2 et 3 (i.e. respectivement Tier-1, Tier-2, Tier-3). Dans l’ingénierie système (exigences et architectures) mise en œuvre chez Renault, les spécifications des constituants issus de l’architecture des systèmes (i.e. spécifications ECUs) sont confiées aux Tiers-1 pour le développement. Les Tiers-1 peuvent eux-mêmes faire appel à des équipementiers de rang 2 (Tier-2), etc. La mise en pratique de l’ingénierie système est réalisée tout au long du processus de développement. Le cycle en V décrit ci-après en est un exemple.
|
Table des matières
Introduction générale
Partie I — Introduction
Chapitre 1 — Contexte industriel automobile
1.1 La mécatronique dans l’automobile
1.1.1 Définition
1.1.2 L’architecture électrique/électronique (E/E)
1.1.3 De l’architecture fédérée à l’architecture intégrée
1.2 Processus de développement d’une architecture E/E
1.2.1 L’ingénierie système
1.2.2 Le cycle de développement en V
1.2.3 La sûreté de fonctionnement (SdF) logicielle
1.3 Contexte « normatif »
1.3.1 Vers la nécessité de standardiser et normaliser
1.3.2 AUTOSAR : le standard pour l’architecture logicielle
1.3.3 De la CEI 61508 à l’ISO 26262, la norme de référence pour la sûreté de fonctionnement automobile
1.4 Tendances de développement des systèmes E/E
1.4.1 Accroissement des besoins en ressources CPUs
1.4.2 Limitations de l’évolution des architectures monocœur
1.4.3 L’étude des architectures multicœur
1.4.4 Conclusions sur les besoins industriels
Chapitre 2 — Contexte scientifique
2.1 Taxonomie des architectures matérielles multicœur
2.1.1 Les architectures homogènes, uniformes et hétérogènes
2.1.2 Un exemple d’architecture : le Leopard MPC 5643L
2.2 Complexité des systèmes temps réel multicœur
2.2.1 Ordonnancement temps réel
2.2.2 Partage des ressources
2.3 Modèle de fautes pour les systèmes temps réel multicœur
2.3.1 Activation des fautes liées aux accès à la mémoire commune
2.3.2 Activation des fautes liées à la non-maîtrise de l’ordonnancement multicœur
2.4 Vers la tolérance aux fautes
2.4.1 Généralités sur la tolérance aux fautes
2.4.2 Taxonomie des mécanismes logiciels pour la tolérance aux fautes
Chapitre 3 — Contributions de la thèse
3.1 Hypothèses et problématique
3.1.1 Architectures ciblées
3.1.2 Modèle de fautes considéré
3.1.3 Problématique et approche suivie
3.2 Vérification en-ligne de propriétés intertâches
3.3 Synchronisation non bloquante pour le partage de données
Partie II — Vérification en-ligne de propriétés inter-tâches
Chapitre 4 — Introduction à la vérification en ligne
4.1 Vers la vérification en ligne des systèmes
4.1.1 Le problème de la vérification des systèmes
4.1.2 Positionnement de la vérification en ligne
4.2 Architecture d’un mécanisme de vérification en ligne
4.3 État de l’art des mécanismes pour la vérification en ligne
4.3.1 Classification des mécanismes pour la vérification en ligne
4.3.2 Mécanismes logiciels pour la vérification en ligne basés sur des propriétés écrites en LTL
4.3.3 Mécanismes logiciels pour la vérification en ligne basés sur l’utilisation de langages dédiés
4.4 Périmètre de l’étude
4.4.1 Objectifs et contraintes
4.4.2 Approche suivie
Chapitre 5 — Synthèse de moniteurs à partir d’une formule LTL
5.1 Fondements théoriques
5.1.1 Alphabets, mots et langages
5.1.2 Définitions de base sur les automates
5.1.3 La logique temporelle LTL
5.2 Processus de génération d’un moniteur à partir d’une formule LTL
5.2.1 Classification des propriétés LTL pour la vérification en ligne
5.2.2 Génération d’un moniteur à partir d’une propriété exprimée en LTL
5.2.3 Applicabilité de la solution
5.2.4 Illustration de la synthèse du moniteur d’une formule LTL par un exemple
5.3 Synthèse du moniteur final
5.3.1 Topologie du moniteur final
5.3.2 Synthèse du moniteur final sous la forme d’une table de transitions
5.3.3 Synthèse finale d’un moniteur sur un exemple
Chapitre 6 — Implémentation et évaluation
6.1 Comportement en ligne du service de vérification
6.2 Synthèse des moniteurs avec Enforcer
6.2.1 Schéma de principe du fonctionnement d’Enforcer
6.2.2 Chaîne de compilation d’Enforcer
6.3 Intégration du mécanisme de vérification en ligne dans le RTOS Trampoline
6.3.1 Principe de l’intégration dans le noyau de Trampoline
6.3.2 Extension du langage OIL pour Enforcer
6.4 Évaluation des surcoûts mémoire et temporel
6.4.1 Évaluation et minimisation de l’empreinte mémoire des moniteurs
6.4.2 Évaluation et minimisation du surcoût temporel
Chapitre 7 — Étude de cas
7.1 Le projet PROTOSAR
7.1.1 Contexte du projet
7.1.2 Objectifs
7.2 Détails sur la topologie de l’architecture de PROTOSAR
7.3 Écriture des exigences pour PROTOSAR, dans la phase de développement, pour le calculateur
7.3.1 Exigences sur les productions et consommations de données
7.3.2 Exigences sur la propagation des données
7.3.3 Exigences sur la cohérence des données
7.3.4 Nombre de moniteurs à synthétiser
7.4 Évaluation du coût associé à la synthèse hors-ligne des moniteurs
7.4.1 Taille des tables de transitions
7.4.2 Taille des descripteurs de moniteurs et du code
7.4.3 Taille du gestionnaire d’évènements
7.4.4 Taille des tables d’évènements
7.5 Bilan et améliorations
7.5.1 Composition des moniteurs
7.5.2 Hypothèses liées à l’implémentation
7.5.3 Conclusion
Chapitre 8 — Discussion
Partie III — STM-HRT : un protocole logiciel wait-free à base de mémoire transactionnelle pour les systèmes temps réel embarqués multicœur critiques
Chapitre 9 — Introduction au partage de ressources non bloquants
9.1 Garanties de progression des processus manipulant des ressources partagées
9.2 Protocoles de synchronisation multicœur non bloquants
9.3 Les mécanismes à mémoire transactionnelle
9.3.1 Qu’est-ce qu’une transaction ?
9.3.2 Choix de conception d’un mécanisme à mémoire transactionnelle
9.4 Implémentation des mécanismes à mémoire transactionnelle
9.4.1 Taxonomie des instructions matérielles pour l’atomicité dans les cibles embarquées
9.4.2 Types d’implémentations
9.4.3 Exemples d’implémentations logicielles de type Lock-Free
9.5 Périmètre de l’étude
9.5.1 Objectifs et contraintes
9.5.2 Approche suivie
Chapitre 10 — STM-HRT : un protocole non bloquant pour le partage de données
10.1 Modèles et hypothèses
10.1.1 Modèle du système
10.1.2 Hypothèses considérées
10.2 Structures de données de STM-HRT
10.2.1 Configuration hors-ligne
10.2.2 Descripteur des transactions
10.2.3 En-tête des objets
10.2.4 Illustration sur une configuration transactionnelle
10.3 Algorithmes du protocole STM-HRT
10.3.1 Description de l’API interne
10.3.2 Définition des tableaux, des types et des macros
10.3.3 Algorithmes pour l’ouverture des objets
10.3.4 Algorithmes pour le commit des transactions
10.3.5 Le mécanisme d’aide
10.3.6 Exemple d’illustration
10.4 Intégration de STM-HRT dans le RTOS Trampoline
10.4.1 Architecture du service de communication
10.4.2 Configuration statique du protocole
10.4.3 Comportement en-ligne du service
10.4.4 Détails d’implémentation du service
Chapitre 11 — Analyse du protocole STM-HRT
11.1 Modélisation et vérification du protocole avec SPIN
11.1.1 Principe de modélisation
11.1.2 Protocole de test et résultats
11.2 Analyse fonctionnelle de STM-HRT
11.3 Analyse temporelle de STM-HRT
11.3.1 Surcoût d’exécution des transactions en totale isolation
11.3.2 Surcoût d’exécution des transactions en concurrence
11.3.3 Borne supérieure sur le temps d’exécution des tâches
11.4 Analyse de l’empreinte mémoire de STM-HRT
11.4.1 Espace mémoire dédié à la gestion des objets
11.4.2 Espace mémoire dédié à la gestion des transactions
11.4.3 Bilan de l’empreinte mémoire de STM-HRT
11.4.4 Exemple
Chapitre 12 — Discussion
Conclusion
