Journal Première approche des systèmes embarqués sur véhicules automobiles

Sommaire

• Introduction
• OBD
  • Données OBD
    • Données OBD générales
  • Mémoire des défauts
    • Détection des défauts
    • Mémorisation des défauts Pending DTC (mode $07)
    • Mémorisation des défauts Stored DTC (mode $03)
  • Défaut consécutif
  • Affichage des défauts
• ECU
• AUTOSAR
• OSEK
  • Innovations :
    • Au niveau logiciel
    • Au niveau matériel

Introduction

Les véhicules personnels plus ou moins récent sont dotés de composants électroniques permettant la gestion de différents éléments du véhicule. Depuis 1996 en Californie, 2002 en Europe pour les véhicule essence et 2004 pour les véhicules diesel, il est devenu obligatoire de permettre l’accès aux données de gestion de polluants par l’intermédiaire d’une prise parfois appelée OBD II et ce dans le but de limiter la pollution en diagnostiquant de manière aisée les éléments défaillants.

Sources:
Wikipedia OBD (anglais et français)
OBD: FORUM MERCEDES (Énormément d'informations)
Wikipedia ECU (anglais)
Wikipedia AUTOSAR (anglais et français)
AUTOSAR anglais
Wikipedia OSEK (anglais et français)
Mesure (pour Pharos)
et quelques autres…

OBD

Le système de diagnostic OBD intégré au calculateur moteur (PCM = Powertrain Control Module) surveille en permanence tous les composants et systèmes du véhicule, concernés par les gaz d'échappement.
Si un défaut apparaît, celui-ci est signalé au conducteur par l'intermédiaire d'un témoin de défaut MIL (témoin de défaut).
Simultanément, le défaut est enregistré dans la mémoire des défauts du calculateur moteur et peut être lu et effacé au moyen de tout appareil de diagnostic du commerce.
Cette prise est donc en connexion directe avec le calculateur moteur aussi appelé ECU.
L'accès aux données OBD générales du calculateur moteur est possible avec tout appareil de diagnostic du commerce (Generic Scan Tool) selon "SAE J1978“ ou "ISO 15031-4“. L'emplacement, la forme et la dotation de la prise de diagnostic répondent à la norme "SAE J1962“ ou "ISO 15031-3“. Les données OBD sont transmises dans les deux sens (transmission bidirectionnelle) via une interface sérielle selon "ISO14230-4“ ou via une interface CAN selon "ISO15765-4“.
Les constructeurs automobiles doivent rendre les données de réparation et de diagnostic disponibles et accessibles aux utilisateurs étrangers au réseau de distribution. N'est pas comprise dans cette règle la "propriété intellectuelle" du constructeur, telle que les brevets.
Tous les codes de calculateur ou paramètres de service programmables (par exemple courbes caractéristiques de moteur) doivent être protégées des interventions non autorisées et présenter un niveau de protection au moins conforme à "SAE J2186 ou ISO 15031-7“. Ceci n'est cependant valable que dans le cas où l'échange des données a lieu au moyen des protocoles de transmission décrits, via la prise de diagnostic (coupleur de diagnostic).

Données OBD

Données OBD générales

Constituent des données OBD générales, dont l'accessibilité doit être garantie pour tous, toutes les données OBD requises pour la révision, le diagnostic, la maintenance ou la réparation des composants et systèmes du véhicule concernés par les gaz d'échappement.
Les données suivantes peuvent être lues selon "SAE J1979“ ou "ISO 15031-5“ :
• Mode $01 : valeurs réelles concernées par les gaz d'échappement et données de diagnostic du système OBD
• Mode $02 : Freeze Frame Data (données environnantes du défaut)
• Mode $03 : Stored DTCs (codes défauts d'anomalies actuelles, mémorisées, concernées par les gaz d'échappement)
• Mode $04 : effacement de tous les codes défauts concernés par les gaz d'échappement
• Mode $05 : valeurs du circuit de régulation lambda
• Mode $06 : résultats de test de systèmes à surveillance cyclique
• Mode $07 : Pending DTCs (codes défauts de défauts détectés, pas encore enregistrés, concernés par les gaz d'échappement, du cycle de conduite actuel et précédent)
• Mode $08 : codes défauts et fonctionnalités de diagnostic spécifiques du véhicule (par exemple lancement de contrôles cycliques)
• Mode $09 : caractéristiques d'identification du véhicule
Code défaut
Les défauts détectés sont enregistrés sous forme de codes défauts (DTCs) selon "SAE J2012 ou ISO 15031-6“. Le code défaut est une valeur alphanumérique à 5 caractères (1 lettre et 4 chiffres).
Les codes P0xxx (modes $03 et $07) sont des codes normés concernés par les gaz d'échappement.
Chaque constructeur automobile peut toujours utiliser en plus des codes P1xxx (mode $08). Tel est le cas lorsque le constructeur automobile (au-delà des exigences de la législation) intègre des fonctions supplémentaires dans le calculateur moteur, et que celles-ci doivent être également aptes au diagnostic.
Les codes P1xxx ne peuvent le plus souvent être décodés qu'avec un appareil de diagnostic spécifique du constructeur

Mémoire des défauts

Détection des défauts

Le calculateur moteur contrôle en permanence la plausibilité des ses signaux entrants et sortants et reconnaît d'éventuels défauts. La reconnaissance du défaut et sa mise en mémoire se distingue ainsi :
• Défaut présent en permanence
• Faux-contact apparu au cours d'une marche
Les défauts suivants sont détectés selon leur fréquence et leur durée :
• Signaux au-dessus ou en-dessous d'une valeur seuil (p.ex. coupure de câble, court-circuit, capteur défectueux)
• Combinaison non logique de signaux différents
• Circuit de régulation (par exemple régulation lambda) à la limite inférieure ou supérieure de l'intervalle de régulation
• Défauts dans les chaînes d'effets (déroulements erronés du contrôle, par exemple lors de l'insufflation d'air secondaire ou de la régénération)
• Messages de défauts via le bus de données CAN (par exemple depuis le calculateur VGS, ESP ou KLA)

Mémorisation des défauts Pending DTC (mode $07)

Les défauts concernés par les gaz d'échappement, des cycles de conduite actuel et précédent, venant d'être détectés, sont des Pending DTCs. Ils sont enregistrés sous forme de code défaut dans le mode $07, jusqu'à leur confirmation (apparition lors de deux cycles de conduite consécutifs).

Mémorisation des défauts Stored DTC (mode $03)

Si un défaut détecté apparaît lors de deux cycles de conduite consécutifs, le Pending DTC devient un Stored DTC, qui est enregistré dans la mémoire des défauts du calculateur moteur.

Défaut consécutif

Si un signal défectueux est détecté et enregistré, tous les contrôles pour lesquels ce signal est nécessaire en tant que grandeur comparative, sont stoppés (verrouillage transversal). On évite ainsi la mise en mémoire de défauts consécutifs.

Affichage des défauts

Si un défaut apparaît lors de deux cycles de conduite consécutifs, le témoin de défaut MIL s'allume.
L'affichage des défauts par MIL s'éteint de lui-même au bout de 3 cycles de conduite consécutifs sans défaut.
Effacement de défaut (mode $04)
Les défauts enregistrés ne sont effacés automatiquement de la mémoire des défauts qu'après 40 cycles de conduite consécutifs sans défaut.
Ils peuvent cependant être également effacés (après réparation réussie) au moyen de tout appareil de diagnostic du commerce ou du DAS.

ECU

ECU correspond à electronic control unit (unité de contrôle électronique). Cela désigne un système embarqué contrôlant un ou plusieurs système ou sous système dans un véhicule motorisé.
Il existe différents types d’ECU :
* Contrôle de l’airbag (Airbag control unit) (ACU)
* Contrôle de l’habitacle (Body control module) (BCU) contrôle la fermeture des portes, les vitres électriques, les lumières intérieures, etc.
* Contrôle du moteur (Engine control unit) (ECU) — ne pas confondre avec electronic control unit, qui est le terme générique pour ces appareils
* Contrôle des freins (Brake Control Module) (BCM; ABS or ESC)
* …
Les véhicules modernes peuvent avoir plus de 80 ECU.

AUTOSAR

Dans le domaine des systèmes embarqués, de nouveaux outils, partagés par tous les acteurs de la chaîne de valeur sont ainsi devenus nécessaires pour respecter l’ensemble des spécifications imposées par les réglementations (norme ISO 26262, AUTOSAR3…) et pour assurer la fiabilité de conception et la sûreté de fonctionnement
Dans le but de développer et d’établir une architecture logicielle standardisée et ouverte pour les véhicules, une association internationale de développement regroupant des constructeurs automobiles, des équipementiers et des sociétés spécialisées dans l’électronique et l’informatique, fut créée en 2003 : AUTOSAR (AUTomotive Open System ARchitecture)
Les principaux partenaires d’AUTOSAR sont BMW Group, Bosch, Continental, Daimler Chrysler, Ford, Opel, PSA Peugeot Citroën, Siemens VDO (rachetés fin 2007 par Continental), Toyota et Volkswagen AG.

Structure logicielle pour un ECU

L’image ci-dessus montre la structure du logiciel pour un ECU. Les différentes couches et les éléments principaux sont décrits en dessous.
L’Ecu se décompose donc ainsi :
* Logiciels AUTOSAR
* Environnement en temps réel AUTOSAR
* Logiciels de base AUTOSAR
Le consortium AUTOSAR réutilisa les spécifications OSEK : Le système opérationnel est donc rétrocompatible avec OSEK OS lequel couvre les fonctionnalités d'OSEKtime et le module de communication est dérivé d'OSEK COM.

OSEK

OSEK a été créé en 1993 par un consortium de constructeurs et équipementiers automobiles allemands (BMW, Bosch, DaimlerChrysler, Opel, Siemens, et VW) ainsi qu’un département de l’université de Karlsruhe. Leur but était de développer un standard pour une architecture ouverte reliant les divers contrôleurs électroniques d’un véhicule. En 1994, les constructeurs français Renault et PSA qui développaient un projet similaire, VDX (Vehicle Distributed eXecutive), rejoignirent le consortium.

L’architecture ouverte présentée par OSEK/VDX comprend trois parties :

La communication (échange de données entre unités de contrôle)
La gestion de réseau
Le système d’exploitation temps réel

Le système d'exploitation en temps réel OSEK bénéficie d'une attention toute particulière en raison des contraintes matérielles et logicielles.
Si OSEK OS constitue l'implémentation de base des systèmes d'exploitation pour l’électronique embarqué, il en existe de nombreux autres ainsi qu'une suite d'outils permettant la réalisation de noyaux particulièrement adaptés aux ECU en accord avec le standard OSEK.
Arctic Core (GPL/commercial)
ERIKA Enterprise (ERIKA Enterprise)

FreeOSEK Implémentation open source de OSEK-VDX
mKernel implémentation open source (GPL)
nxtOSEK implémentation open source pour Mindstorms NXT robots
openOSEK implémentation libre et open source (LGPL)
PICOS18 implémentation open source (GPL) pour Microchip PIC18.
RTA-OSEK implémentation commercial de OSEK RTOS
Trampoline LGPL, pour Infineon C166, PowerPC
Trioz OSEK RTOS implémentation commerciale de OSEK RTOS
Vector’s osCAN implémentation commerciale de OSEK RTOS

Innovations :

Au niveau logiciel

Pour concilier performances et sûreté de fonctionnement, le CEA-List a proposé un nouveau système d’exploitation, PharOS, adapté aux systèmes embarqués multicoeurs. Cette solution, qui permet de garantir la sûreté de fonctionnement, autorise également l’intégration de tâches critiques et non critiques sur un même calculateur, ce qui constitue une innovation majeure. En réduisant le nombre global de calculateurs utilisés, PharOS permet de diminuer le coût de l’électronique embarquée dans les véhicules.
Sur un premier démonstrateur architecturé autour du micro-contrôleur 16 bits S12XE de Freescale, l’empreinte mémoire de PharOS ne dépassait pas 5 Ko en 2010 (http://www.electroniques.biz/editorial/414592/systeme-d%E2%80%99exploitation-pharos-developpe-par-le-cea-et-delphi/) 

Au niveau matériel

En partenariat avec la société Scaleo chip et Continental, le CEA-List contribue au développement du micro-contrôleur OLEA qui apportera des solutions innovantes aux problématiques de l’efficacité énergétique du moteur, de la complexité croissante des systèmes électroniques et de l’extension du réseau embarqué intra-véhicule. Il intégrera notamment des technologies autorisant un contrôle moteur matériel flexible, une protection contre les dysfonctionnements de l’électronique (intégrité système) et une communication Ethernet déterministe.