Norme Autosar : un exemple de standardisation des ... - Mesures

Solutions
LOGICIELS EMBARQUÉS
Norme Autosar : un exemple
de standardisation
des logiciels embarqués
78
L’industrie automobile est confrontée, comme beaucoup d’autres, à une augmentation quasi exponentielle de la complexité
des architectures électroniques. Pour y faire face, les constructeurs du monde entier se sont associés aux fabricants de calculateurs
et aux éditeurs d’outils logiciels pour créer le consortium Autosar (AUTomotive Open System ARchitecture). Le rôle
de cette organisation est de spécifier une méthode de travail permettant de s’affranchir du matériel lors de la conception des
applications embarquées. La question se pose donc : tous les systèmes électroniques complexes devront-ils passer par des
standards de ce type ?
embarquée est
devenue depuis le début des
années 80 le moteur de l’in-
L’électronique
novation automobile. Si
auparavant les mécaniciens créaient les nouvelles
fonctions, on estime aujourd’hui que
75 % de l’évolution d’une voiture est liée à
l’électronique. C’est pourquoi on voit se
multiplier le nombre
des calculateurs (ou
L’essentiel
ECU, Electronic Control
Unit) à bord des véhi-
Les membres du consortium cules. Ils sont devenus
Autosar travaillent sur un véritable challenge
l'établissement d’un pour tous les acteurs
standard de conception pour de l’industrie automo-
les fonctions embarquées à bile. Cependant, l’élec-
bord des véhicules. tronique est arrivée
Constructeurs, équipemen- sur ce marché avec ses
tiers et fabricants de contraintes et ses pro-
calculateurs viennent blèmes. Des problèmes
d’achever la première phase de complexité, dus à la
du projet, la plus importante,
diversité des réseaux et
qui consistait à valider les
des calculateurs… Et
spécifications d’Autosar.
des problèmes d’obso-
L'abstraction du calculateur
lescence, car les calcu-
dans les programmes embarlateurs
comptent
qués permet de réduire les
coûts, de faciliter la
parmi les organes à
portabilité des fonctions plus faible durée de vie
d’un véhicule à un autre, et d’une voiture. Là où
d’améliorer la fiabilité des un constructeur ga-
applications.
rantit à un client un
suivi sur dix à quin-
ze ans de son véhicule, ce dernier comporte
des calculateurs dont la durée de vie n’excède
jamais cinq ans. Sans compter que les
logiciels qui y sont embarqués sont le plus
souvent obsolètes au bout d’un an. On a
donc chez les constructeurs de véritables
problèmes de gestion de l’obsolescence, des
problèmes de temps de mise sur le marché
(TTM, ou Time To Market), sans parler des
problèmes de qualité ni des coûts liés aux
campagnes de rappels pour certains modèles.
Enfin, l’implantation de nouvelles fonctions
(ou programmes) dans les calculateurs
des véhicules n’est pas aisée, car chaque logiciel
est prévu pour fonctionner sur un
certain modèle d’ECU. Des opérations qui
devraient être simples en théorie, comme la
migration de certaines options d’un modèle
de véhicule à un autre, deviennent de véritables
casse-tête pour les constructeurs. La
Une voiture moderne, c’est avant tout un réseau informatique, avec 50 à 70 calculateurs embarqués en moyenne.
MESURES 796 - JUIN 2007 - www.mesures.com

Exemple de calculateur pour la gestion moteur, ici en test chez dSPACE, à Paderborn en Allemagne.
création de composants logiciels standard,
réutilisables quel que soit le modèle de voiture
et indépendants du calculateur embarqué,
s’impose donc comme une solution
aux problèmes d’obsolescence et de complexité
posés par les calculateurs.
Le besoin d’un standard
se fait sentir
En 2000, quelques constructeurs ont commencé
à se réunir pour travailler sur la possibilité
de créer un standard ouvert, basé sur
le bus CAN (standard actuel de communication
automobile) mais compatible avec les
bus plus récents, tels que le FlexRay (fonctions
critiques) ou le MOST (fonctions d’infotainment).
Pour la plupart, il s’agissait des
membres du HIS (HerstellerInitiative
Software), groupe de travail fondé par Audi,
BMW, DaimlerChrysler, Porsche et Volkswagen sur le
sujet de l’innovation logicielle. Mais ils se
sont vite rendus compte que leur volonté de
standardiser les logiciels de base des calculateurs
ne devait pas se limiter au marché germano-allemand
et ne pouvait s’effectuer
sans une coopération solide entre tous les
acteurs du monde de l’automobile. C’est
pourquoi ils ouvrent alors leurs groupes de
travail, d’abord à Siemens VDO et Bosch, deux
des principaux équipementiers sur le marché
des ECU. La volonté est alors de concevoir
des logiciels de base communs aux ECU
de tous les fabricants (abstraction du matériel),
en conservant des applications propriétaires.
Mais cela n’est pas encore suffisant.
Pour répondre aux besoins, les logiciels doi-
MESURES 796 - JUIN 2007 - www.mesures.com
Solutions
vent eux aussi être standardisés pour s’affranchir
de la configuration du système
d’exploitation. Plus simplement, le logiciel
ne doit plus dépendre du matériel sur lequel
il est installé, mais de surcroît il ne doit plus
tenir compte de la manière dont il communique
avec les autres logiciels, qu’ils soient
sur le même ECU ou à l’autre extrémité du
véhicule.
Cette réflexion aboutit en 2003 avec la création
du consortium Autosar (AUTomotive
Open System Architecture). D’autres constructeurs
viennent alors apporter leur contribution
aux groupes de travail, puis ce sont
d’autres équipementiers, et enfin des éditeurs
de logiciels et d’outils de conception
pour programmes embarqués. Les membres
travaillent à l’élaboration d’un standard de
conception réellement sain, qui permette de
se concentrer sur les applications et non plus
sur la manière de les intégrer à un véhicule.
Il faut concilier simplicité de conception et
fiabilité d’exécution. La méthode proposée :
réorganiser et standardiser les couches basses
des logiciels ECU sous forme de modules.
Cela passe par deux étapes importantes, que
sont le développement d’une couche d’abstraction
du matériel (modèle d’ECU, type de
réseau, couches basses spécifiques) et la définition
de l’architecture logicielle de base.
Le principe d’Autosar
La démarche établie par les membres du
consortium consiste à spécifier une architecture
logicielle à plusieurs couches, pour arriver
à une abstraction totale du matériel (à
79

Solutions
80
Des fonctions indépendantes de l’architecture
Autosar va apporter des changements
importants dans la manière de programmer les
calculateurs. L’implémentation de fonctions
automobiles se fera en trois étapes :
Tout d'abord, les fonctions sont décrites de
manière formelle en tant que “Software
Components” (SWC). On déclare bien sûr les
variables d’entrée et de sortie dont les
fonctions ont besoin, mais le code doit être
indépendant du matériel.
Une fois toutes les fonctions définies, on
génère un Virtual Fonctional Bus (VFB).
Élément crucial de la méthodologie Autosar,
ce bus virtuel relie entre elles toutes les
entrées et les sorties des différentes fonctions.
Il permet de vérifier qu’il n’y a pas de “trou”
dans l’architecture, et que chaque fonction
dispose bien de toutes les informations dont
elle a besoin.
Enfin, en ajoutant au VFB la description
physique des calculateurs qui seront
embarqués ainsi que les contraintes du
système, on génère une véritable architecture
automobile. Le VFB se transforme alors soit en
une liaison réseau, soit en une liaison directe
entre deux fonctions (si elles sont embarquées
sur le même calculateur). Le principal
avantage est de pouvoir revenir aisément en
arrière. On peut décider à tout moment de
regrouper plusieurs fonctions (changer les
contraintes), il suffit ensuite de générer une
nouvelle architecture.
Le principal aspect “contraignant” de ce
standard est le fait qu’il soit statique : les
composants ne peuvent pas être insérés ou
modifiés une fois l’architecture globale générée.
De plus, les deux dernières étapes nécessitent
l’utilisation d’outils certifiés par le consortium
Autosar. En revanche, les constructeurs auront
davantage de libertés dans la création de
nouvelles fonctions, puisqu’ils ne dépendront
plus de la partie électronique.
l’intérieur d’un ECU). La couche la plus
haute, le RTE (Runtime Environment), permettra
à une fonction d’être programmée et
exécutée sans tenir compte, par exemple, du
fait que le microcontrôleur est un 8 bits ou
un 16 bits. D’autre part, la méthode s’appuie
aussi sur des environnements de développement
certifiés Autosar pour la création du
réseau de communication entre les calculateurs.
« Ces outils, déjà opérationnels chez la plupart
des éditeurs du monde de l’embarqué, permettent de créer
un réseau virtuel représentant toute la voiture, déclare
Salah Aksas, directeur de dSPACE. On ne passe à
la génération de l’application réelle qu’en phase finale,
une fois que tous les tests ont été effectués et que l’architecture
est validée. Cela permet de travailler sur le portage
des fonctions. Aucun programme n’étant lié à un calculateur,
on peut faire autant de regroupements de fonctions
que nécessaire, et on travaille sur le véhicule en le considérant
comme un système ».
Car c’est cela l’apport majeur du standard
Autosar : arriver à une représentation logicielle
complète du véhicule en tant que système
immergé dans son environnement. Et
si les modèles environnementaux continuent
à se perfectionner, on pourra arriver à une
conception automobile entièrement logicielle.
« En réalité, c’est tout le business model des industries
automobiles qui est amené à se réorganiser,
ajoute Eliane Fourgeau, directeur général de
TNI Software. Étant donné qu’il sera possible de créer des
couches basses de calculateurs relativement simplement, de
nouveaux acteurs ne tarderont certainement pas à faire
leur apparition ». Le rôle des équipementiers,
qui sont situés entre les fournisseurs de matériel
et les constructeurs, se verra probablement
impacté, car Autosar accorde une importance
capitale au rôle des intégrateurs. En
effet, l’essentiel des outils devenant standard
et automatiques, la valeur ajoutée viendra de
la manière de configurer ces systèmes.
La standardisation,
un problème récurrent ?
La première phase du projet Autosar s’est
terminée au mois de janvier 2007. La partie
la plus complexe du travail de standardisation
a donc été effectuée, et elle a abouti à la
spécification Autosar 2.1. Après trois ans de
collaboration entre les industriels, toutes les
couches basses ont été définies, ainsi que les
règles de conception des modules logiciels.
Des environnements de développement
conforme à Autosar ont été validés, aussi
bien pour les modules fonctionnels que
pour les architectures globales. Jean-Philippe
Dehaene, directeur technique chez Vector
France, affirme que « des démonstrations ont déjà eu
lieu devant les constructeurs, et que les logiciels permettant
le déplacement d’une application d’un ECU à l’autre sont
MESURES 796 - JUIN 2007 - www.mesures.com

L’architecture d’un calculateur Autosar
Le standard Autosar prévoit que chaque calculateur soit fourni
avec ses propres couches basses. Celles-ci sont dépendantes du
matériel. Mais pour être compatible Autosar, l’empilement de ces
tout à fait opérationnels ». Cependant, l’arrivée sur
le marché d’un véhicule entièrement conforme
à Autosar n’est toujours pas d’actualité.
Ajoutons que le projet n’est pas terminé,
car la phase 2 vient d’être lancée. Cette nouvelle
étape permettra d’une part de maintenir
et d’enrichir les standards et les outils
existants, et d’autre part d’approfondir un
aspect qui avait été très peu évoqué jusquelà,
à savoir toutes les fonctions critiques ou
de sécurité du véhicule (à l’instar de la
norme DO-178B en aéronautique).
On s’aperçoit donc que ce besoin de standardisation
dépasse le seul secteur automobile.
Quel que soit le marché que l’on considère
(aérospatial, naval, ferroviaire,
défense…), on retrouve une nécessité de
standardiser les logiciels pour améliorer la
fiabilité des échanges et la réutilisation des
applications. Et ces secteurs sont parfois plus
avancés que celui de l’automobile. « Nous
disposions déjà d’environnements de développement similaires
à Autosar dans l’esprit, explique Eliane
Fourgeau, mais il s’agissait d’outils spécifiques, adaptés
par exemple au secteur de l’aéronautique (norme IMA,
Integrated Modular Avionics) ou encore du ferroviaire
(norme EN50128). Nous nous sommes donc immédiatement
attelés à l’adaptation de notre logiciel à Autosar.
Et nous ferons de même si un nouveau standard voit le
jour dans un autre domaine ». On peut penser au
marché des camions, pour lesquels les logiciels
embarqués sont toujours basés sur des
solutions propriétaires, ou encore au secteur
médical qui utilise essentiellement des protocoles
libres. Aujourd’hui, chaque secteur
ayant recours à l’électronique embarquée
est plus ou moins engagé sur la voie d’une
MESURES 796 - JUIN 2007 - www.mesures.com
standardisation des communications. Avec
toujours le même constat : si hier la complexité
venait de la multiplication des ECU,
couches basses doit amener à une couche d’abstraction
standard, définie de manière rigoureuse par le consortium.
Il s’agit de l’Autosar Runtime Environment, ou RTE.
Pierre angulaire de la méthode de développement
Autosar, il sert de base commune à toutes les installations
de logiciels embarqués, et ne peut être généré que
par des outils spécifiques certifiés Autosar.
Sous le RTE, on trouve plusieurs types de couches
basses. En premier lieu, il faut concevoir toutes celles qui
concernent l’abstraction du microcontrôleur (processeur
de l’ECU). Elles sont représentées en rose sur le schéma.
En vert, on trouve les couches qui permettent l’abstraction
du calculateur global (processeur et chipsets), en
s’affranchissant par exemple de la taille ou du type de
mémoire, ou encore du type de réseau de communication.
Enfin, la dernière couche, représentée en bleu,
correspond à un certain nombre de services (par
exemple les services liés à la communication sur le bus CAN) qu’il
est possible d’intégrer au calculateur.
Solutions
demain les efforts devront être recentrés sur
les métiers de l’intégration.
Frédéric Parisot
81