Cette page a été traduite automatiquement.
Merci de bien vouloir compléter un sondage de 1 minute concernant la qualité de cette traduction.
Passer d'architectures orientées signal à des architectures orientées service pour les SDV
Migration des fonctionnalités existantes dans une approche à criticité mixte
« Nous utilisons un modèle Simulink existant que nous avons développé pour la transmission du couple… et commençons ensuite à adapter l'entrée/sortie vers une entrée/sortie orientée services. Dans ce cadre, il est nécessaire d’utiliser le dictionnaire AUTOSAR pour configurer les attributs du modèle. Une fois cela fait, nous utilisons Embedded Coder pour générer le code. »
Principaux résultats
- Les outils MATLAB® et Simulink permettent la réutilisation des designs basées sur les signaux AUTOSAR Classic, aidant les équipes à les migrer vers l'architecture orientée services AUTOSAR Adaptive
- Embedded Coder a permis à l'équipe de générer du code C++ orienté services pour les SDV
- Simulink permet aux OEM de valider leurs applications SDV HPC à l'aide d'une portail développé
L’industrie automobile se concentre de plus en plus sur le développement de software-defined vehicles (SDV ou véhicules conçus autour du logiciel). Les architectures électriques/électroniques (E/E) de ces véhicules sont dotées d'ordinateurs centraux et de contrôleurs de zone hautes performances qui supportent les architectures orientées services (SOA). Le principal avantage de ces architectures est qu’elles peuvent être mises à jour en continu sans avoir à reprogrammer l’ensemble de l’ECU.
Plutôt que de les concevoir de nouveau à partir de zéro, les constructeurs automobiles préfèrent utiliser leur inventaire existant de composants logiciels critiques, testés et validés, ainsi que des composants logiciels non critiques, dans les nouvelles architectures E/E. Basée en Allemagne, FEV a mis en place un démonstrateur pour montrer comment migrer des fonctionnalités existantes dans une approche à criticité mixte.
Le démonstrateur utilise des machines virtuelles pour héberger des fonctions pour différents domaines. Ces machines virtuelles communiquent avec un hyperviseur QNX® et Android® Automobile via un bus virtuel ; elles sont connectées à un contrôleur de jeu et à plusieurs écrans pour visualiser la simulation CARLA. Le système fonctionne sur un SoC Renesas® R-Car et un processeur NXP™ iMX 8.
Un composant de cette configuration implique que FEV migre une fonction de gestion du couple initialement implémentée en C en utilisant AUTOSAR® Classic. L'équipe FEV a utilisé le modèle Simulink® original avec AUTOSAR Component Designer et a transformé la fonction pour qu’elle utilise des services au lieu de signaux en définissant des événements d'envoi/réception. Par la suite, un code C++ compatible AUTOSAR Adaptive a été généré à l'aide Embedded Coder®.
Cette preuve de concept démontre que la transition vers de nouvelles architectures E/E est réalisable tout en maximisant la réutilisation de la propriété intellectuelle existante et en conservant une chaîne d’outils familière aux ingénieurs. Cela a également servi de point de départ pour une plateforme de développement SDV, permettant à FEV de soutenir un OEM majeur, en aidant à valider le calcul haute performance (HPC) pour le développement SDV. L'OEM a fourni à FEV un véhicule doté de son architecture E/E actuelle, ainsi que de ses contrôleurs HPC et de zone. Plutôt que de construire une nouvelle architecture E/E à partir de zéro, FEV a aidé à intégrer le HPC et les contrôleurs de zone dans l'architecture E/E existante. Avec Simulink, l’équipe a utilisé l’interface FEV pour faciliter l’interfaçage et la traduction des messages entre les contrôleurs de zone et les anciens ECU.