Entraînées par des réglementations sur l'environnement et sur la sécurité en évolution constante, les automobiles actuelles intègrent un niveau exceptionnel de fonctionnalités. L'infrastructure électrique du véhicule suit cette tendance, car composants électroniques et logiciel embarqué doivent être intégrés dans une structure en réseau, tout en assurant le niveau requis de performances et de fiabilité. Malheureusement, les solutions généralement utilisées pour implanter les développements électroniques et électriques automobiles sont propriétaires, ce qui rend difficile l'échange de fonctions et d'applications entre les équipementiers et les constructeurs. Si cette situation perdure, maintenir la croissance de la complexité fonctionnelle demandera un investissement excessif en ressources, sans aucune garantie de maintenir le contrôle du processus de développement.

Face à cette situation, le Consortium Autosar (Automotive open system architecture) a été officiellement créé en juillet 2003 par un groupe de constructeurs automobiles et d'équipementiers européens : BMW Group, Bosch, Continental, DaimlerChrysler, Siemens VDO et Volkswagen. Ils ont été rejoints plus tard par Ford Motor Company, General Motors, PSA Peugeot Citroën et Toyota Motor Company. Cette initiative vise à définir des standards sur lesquels les futures applications automobiles, pour ce qui a trait au développement logiciel, seront basées. Ces spécifications sont notamment prévues pour mieux gérer la croissance de la complexité des systèmes électriques/électroniques mis en oeuvre pour accroître les fonctionnalités d'une automobile. Elles sont également destinées à générer une meilleure flexibilité des ensembles matériel/logiciel afin d'améliorer la maintenance et la mise à jour des systèmes embarqués. In fine, les solutions basées sur l'approche Autosar sont censées pouvoir être dimensionnées de bout en bout des process de production.

En sus, il sera aussi possible d'échanger des fonctions logicielles entre les constructeurs et les équipementiers, et ce dans tous les domaines impliqués dans la conception automobile comme le groupe motopropulseur, le châssis, la sécurité, les équipements multimédia/télématique, l'habitacle (avec la notion de confort) et les interfaces homme-machine.

Jusqu'à présent, en termes techniques, Autosar adresse trois domaines principaux : un coeur de logiciel de base, des interfaces fonctionnelles standardisées et des méthodes pour l'intégration du logiciel. Ce standard décrit notamment une infrastructure logicielle commune basée sur des interfaces normalisées, intégrant notamment diverses API qui séparent les différentes couches logicielles. L'encapsulation des composants logiciels et leurs types de données associés sont prédéfinis de façon à assurer leur fonctionnement. En outre, l'infrastructure logicielle qui intègre les modules du logiciel de base est identifiée et spécifiée. Ces modules de logiciel de base ont également leurs propres interfaces standardisées autorisant le partitionnement et un meilleur usage des ressources, tout en maintenant l'optimisation locale pour respecter les contraintes non fonctionnelles spécifiques.

L'architecture logicielle Autosar est donc basée sur une structure en couches (figure 1). Dans cette approche, le logiciel de base, qui fournit les fonctions et les services pour les composants logiciels Autosar, repose sur les couches matérielles spécifiques du calculateur (ECU, Electronic control unit). Il est subdivisé en différents éléments. L'élément « services » comprend les services du noyau temps réel (quel que soit l'OS utilisé, car l'initiative Autosar ne vise pas à en définir un) et les fonctions de communication pour tous les bus véhicule comme FlexRay, CAN, MOST et LIN. L'élément d' « abstraction microcontrôleur » quant à lui s'interface avec un élément d' « abstraction ECU » . Dans cette approche, les pilotes de l'ECU (pilotes de périphériques complexes) permettent aux composants logiciels d'accéder directement au matériel lié au microcontrôleur, autorisant l'implémentation de capteurs complexes avec des exigences fonctionnelles spécifiques.

Le concept général de conception selon la philosophie Autosar est aussi caractérisé par la séparation des applications de l'infrastructure. Une application est donc décrite via l'interconnexion et l'interaction des composants logiciels impliquées (figure 2). Ici, les composants logiciels Autosar SAR (SW-C) sont des éléments structurels très importants car, comme dans le formalisme UML 2.0, ils possèdent des ports qui interagissent avec le monde extérieur. Ainsi dans UML et dans Autosar, les interfaces requises et fournies peuvent être modélisées. Cependant, en ce qui concerne les types de port, Autosar va plus loin qu'UML. En effet, dans ce standard, les données sont transmises au travers des ports via le stéréotype << SenderPort >> et les données sont reçues au travers des ports via le stéréotype << ReceiverPort >>. Les Services sont alors rendus disponibles par les ports << ServerPort >>, utilisables par d'autres ports à l'aide du stéréotype << ClientPort >>. On se trouve donc ici en face d'une véritable communication de type client-serveur (figure 3).

Au-delà, Autosar permet également de travailler avec une communication de type émetteur-récepteur (figure 4). L'échange de données est ici toujours asynchrone et, par nature, sans blocage. Afin de distinguer cette approche de celle de la communication client-serveur, des symboles différents sont utilisés pour les ports, laissant les concepteurs saisir clairement le type de communication utilisée par le biais d'un stéréotypage graphique. Ainsi, contrairement aux précédents modes de représentation, les ports sont directement connectés au lieu de l'être par l'intermédiaire de symboles d'interfaçage. Ce qui explique pourquoi, avec Autosar, le stéréotypage graphique des ports est plus significatif que l'emploi des symboles d'interfaçage.

Autre caractéristique d'Autosar, la taille des composants logiciels n'est pas définie. Les « SW-C » << compositionType >> contenant des SW-C additionnels sont, dans le standard, différenciés des composants stéréotypés << atomicSoftwareComponentType >> qui, eux, ne peuvent être décomposés davantage. On peut constater ici que cette approche, en tant que telle, ne peut fonctionner sur plusieurs calculateurs, alors que dans un modèle UML ceci peut être réalisé en définissant une relation spécifique entre le composant logiciel et l'ECU approprié.

Dans l'architecture Autosar, les composants logiciels sont développés indépendamment du matériel disponible ou de l'infrastructure réelle utilisée dans un véhicule. On trouve là l'idée d'introduire une stricte séparation entre logiciel et matériel, facilitant ainsi la réutilisation de composants logiciels sur diverses plates-formes matérielles. Toutefois, une description complète d'un SW-C doit contenir ses interfaces (fournies ou requises) ainsi que chaque état d'environnement fonctionnel et non fonctionnel. Le format et la structure des descriptions des composants logiciels Autosar sont établis à l'aide de ce que l'on nomme le « Software Component Template » (encadré). Un moyen de s'assurer que les descriptions finales d'un projet contiennent toutes les informations nécessaires, telles que les opérations ou les attributs qu'un composant échangera avec les autres composants. Les requêtes de l'infrastructure des composants, les ressources matérielles requises et les détails spécifiques d'implémentation dont il faut tenir compte complètent l'ensemble.

En conséquence, chaque implémentation d'un composant logiciel Autosar est normalement indépendante de l'ECU ciblé (ou de l'architecture du microcontrôleur dans l'ECU) sur lequel elle fonctionnera. Mieux, les composants logiciels fournissant les données ou services requis pour un ECU n'impliquent pas qu'ils s'exécutent sur un même ECU. Ce qui signifie qu'il est théoriquement possible avec Autosar d'exécuter sur plusieurs calculateurs d'un véhicule diverses instances du même composant logiciel.

Au-delà des liens directs avec les ECU, Autosar définit aussi des SW-C avec le stéréotypage << sensorActuatorSoftwareComponentType >>. Ces composants logiciels sont dédiés à l'utilisation directe de capteurs et d'actionneurs (figure 5). Normalement non transférables aux autres ECU, ces derniers encapsulent les propriétés physiques des entrées des capteurs ou des sorties des actionneurs, permettant aux fonctions du véhicule de mettre en oeuvre les propriétés matérielles spécifiques des ECU. L'interaction avec ces composants logiciels a ainsi lieu sans avoir accès directement au matériel. De la même façon, lorsque les détails techniques de l'ECU et de son (ses) microcontrôleur(s) sont inconnus du SW-C (étant uniquement disponibles comme services), ces fonctions sont accessibles à un niveau de composant logiciel.

Afin de rendre les composants logiciels Autosar valides sur des systèmes distribués, le concept de bus fonctionnel virtuel (Virtual functional bus - VFB) a été développé au sein des spécifications Autosar. Utilisant les descriptions des composants logiciels comme points d'entrée, le VFB valide l'interaction de tous les composants et interfaces avant l'implémentation du logiciel. Ce qui permet les opérations de test et d'intégration logicielle beaucoup plus tôt qu'avec un processus de conception classique.

A l'intérieur du VFB, toutes les connexions de données nécessaires entre les composants logiciels Autosar sont abstraites et ne font pas référence à leur future localisation dans le véhicule. Donc, par exemple, deux ou plus SW-C Autosar ayant besoin de communiquer peuvent être spécifiés sans avoir la connaissance du matériel précis sur lequel ils s'exécuteront. Ceci est possible grâce aux services de communications du VFB réclamés par les composants logiciels qui sont définis comme abstractions. Leur implantation se déroule ensuite sur la couche logicielle située « au-dessous » de l'environnement d'exécution, baptisé RTE (runtime environment).

Des modèles de conception bien organisés pour la communication au-dessus du VFB fournissent dans cette optique les services abstraits de communication. Ils sont implantés dans les différents ECU par le RTE une fois qu'ils ont été affectés au matériel réel. Dans le RTE, les fonctions de communication sont implantées via le logiciel de base et ses mécanismes de communication (figure 6).

Pour faciliter la description des différents éléments Autosar, un méta-modèle spécifique à ce nouveau standard a été développé par le Consortium éponyme. Le méta-modèle détermine en fait le vocabulaire pour écrire un modèle. Il est décrit au moyen du langage UML. Une approche standardisée pour décrire et définir ces langages de modélisation eux-mêmes existe au sein de l'Object management group (OMG), le consortium industriel responsable de la spécification UML. Il s'agit du Meta object facility (MOF) qui sert en quelque sorte de « méta-méta modèle » .

De son côté, UML lui-même est de plus en plus utilisé comme le langage de modélisation graphique standard pour les systèmes où le logiciel est prépondérant. La clé de son succès réside dans son concept d'extensibilité. En effet, des ajouts spéciaux d'un métier peuvent être aisément intégrés dans un modèle UML et employés conjointement avec des éléments standard du méta-modèle UML. L'OMG a par exemple défini des extensions standard pour UML, comme celles dédiées à la modélisation temps réel grâce à un profil spécifique pour les performances de l'ordonnancement et du temps, ou comme celles relatives à la modélisation de fichiers de test grâce au profil « UML for testing » . Au-delà d'UML, l'OMG a aussi récemment standardisé son langage de modélisation système, appelé SysML, et qui est basé sur la sémantique d'UML. SysML offre notamment la possibilité de modéliser les exigences, une caractéristique très intéressante pour l'automobile où bon nombre de projets actuels sont pilotés par les exigences.

En conservant son extensibilité par le biais de profils UML, le Consortium Autosar a donc développé et publié un profil UML qui intègre une correspondance entre le méta-modèle Autosar et l'UML 2.0. Ce profil définit non seulement les stéréotypes et les valeurs des propriétés mais également les règles résultant du méta-modèle. Par exemple, les classes ayant le stéréotype << senderReceiverInterface >> ne peuvent pas contenir d'opérations parce qu'elles sont uniquement prévues pour le transport de données. Toutefois, en utilisant des ateliers de modélisation UML, tels qu'Artisan Studio(*), ces règles peuvent être liées directement à l'utilisation des stéréotypes grâce à une fonctionnalité nommée « Profilage métier » . Ce « Profilage métier » permet non seulement de contrôler l'aspect des éléments du modèle, mais aussi de définir de nouveaux diagrammes basés sur des diagrammes UML existants avec toutes les règles afférentes. Celles-ci sont directement liées aux propriétés de l'outil assurant ainsi que le modélisateur métier est guidé par les règles inhérentes au profil tout en travaillant avec l'outil (photo).

Un autre avantage de l'emploi d'UML comme base de modélisation pour Autosar tient dans le fait qu'un grand nombre d'outils éprouvés existent déjà. Qui plus est, si un outil de modélisation est aussi extensible que le prédestine la spécification UML, les modélisateurs d'électronique automobile y gagneront une synergie additionnelle. Par exemple, Autosar et UML peuvent être mis en oeuvre côte à côte pour décrire et simuler le comportement des objets dans les diagrammes d'états. Les concepteurs sont alors susceptibles de définir des profils, en utilisant et déposant des informations de gestion de projet dans le modèle (figure 7). Dans les applications automobiles, l'emploi de SysML est, en outre, d'un intérêt particulier car il peut combler les lacunes non couvertes par Autosar.

(*) Le logiciel Artisan Studio d'Artisan Software est distribué en France par MondiTech.