Couverture ElectroniqueS n°127

dSpace, avec sa solution SystemDesk, associée au générateur de code TargetLink, se lance sur le marché des outils de développement d'applications logicielles conformes au standard Autosar. La relative complexité de la mise en place d'une application logicielle conforme au standard Autosar impose, de facto, aux utilisateurs de s'appuyer sur un environnement de programmation fourni par des éditeurs d'outils logiciels. D'ailleurs, dès le départ, les promoteurs d'Autosar avaient indiqué que cette spécification prendrait tout son sens uniquement si des outils étaient disponibles. D'où l'implication très en amont de plusieurs éditeurs, comme Vector, Etas, Telelogic, Geensys ou encore dSpace, en tant que« premium members » au sein du Consortium Autosar, piloté par les constructeurs automobiles à l'origine du projet.Rappelons que la spécification Autosar vise à découpler la partie logicielle d'une application embarquée pour l'automobile de son implantation physique sur des calculateurs spécifiques, via la programmation de modules fonctionnels appelés SW-C (Software components), dotés chacun d'une interface strictement définie par la norme Autosar. Et c'est par le biais d'une couche d'exécution logicielle, baptisée RTE (Runtime environment), spécifiée dans Autosar, que ces composants communiquent et interagissent entre eux, indépendamment des choix matériels ultérieurs.Sur ce marché émergent, en cours de maturation, la société allemande dSpace, focalisée depuis sa création sur le marché automobile et notamment réputée pour ses solutions de simulation logicielles/matérielles de type HIL (Hardware in the loop) et de génération automatique de code C à partir de modèles Simulink (de The MathWorks), a décidé de se lancer sur le marché des outils de développement Autosar en s'appuyant sur deux piliers : l'environnement de développement SystemDesk et le générateur de code TargetLink.SystemDesk, produit entièrement nouveau chez dSpace, a pour vocation de décrire de manière formelle et de modéliser l'architecture logicielle d'une application conformément à la norme Autosar, dans sa version 2.1 actuelle. A partir d'une librairie de composants logiciels, développés notamment avec TargetLink, l'utilisateur construit son application, de manière graphique, en liant les composants entre eux via la spécification de leurs ports et leur interface, définis selon la norme. A partir de cette description, en tirant parti du savoir-faire de la société en termes de génération de code, l'outil génère automatiquement le RTE associé, sous forme de code C optimisé.Tout du moins pour les couches hautes de l'application. Car, pour les couches basses, tout ce qui a trait à la configuration des calculateurs et à la mise en place des composants logiciels de base (les « basic softwares », c'est-à-dire la gestion des entrées/sorties, du réseau, des systèmes d'exploitation…), dSpace s'est associé à la société allemande Elektrobit et à son outil Tresos. L'objectif est de fournir une chaîne complète, qui va de la description formelle de l'architecture logicielle jusqu'à son allocation sur un ou plusieurs calculateurs, reliés entre eux par un réseau, CAN ou LIN dans la plupart des cas. Avec, comme fil conducteur, la volonté de masquer le plus possible à l'utilisateur la complexité inhérente au standard Autosar.Parallèlement, l'outil Target-Link, qui, dans sa version 2.3, est conforme aux dernières spécifications Autosar, peut être associé efficacement à SystemDesk. En effet, le module TargetLink Autosar est capable de générer automatiquement la trame d'un composant logiciel Autosar directement au sein de l'environnement Simulink de The Math-Works. Cette trame intègre notamment les ports logiciels, les entités de calcul (les runnables) et les interfaces, écrites conformément à la norme. Il suffit alors à l'utilisateur d'introduire, au sein de ces composants, les algorithmes de contrôle préalablement développés pour obtenir un composant Autosar complet. Celui-ci peut être ensuite intégré à l'environnement SystemDesk. Cette approche permet, en particulier, de réutiliser des modèles Simulink déjà écrits (et ils sont très nombreux dans le monde de l'automobile), pour les rendre compatibles Autosar (*).On le voit, la solution proposée par dSpace est donc centrée sur la formalisation de l'architecture logicielle d'une application, sans, pour le moment, s'intéresser à la partie simulation fonctionnelle de l'ensemble, la plupart du temps réalisée avec les outils de The MathWorks.(*) The MathWorks n'a pas encore fait d'annonce officielle sur la compatibilité des modèles Simulink par rapport à Autosar.

Architecture logicielle et génération de code Autosar : les chaînes d’outils se structurent

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure

Architecture logicielle et génération de code Autosar : les chaînes d’outils se structurent

Dans la même rubrique

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure