Utilisation de l'approche Model-Based Design pour développer et tester des applications SOA pour les systèmes d'exploitation embarqués

L'industrie automobile est en pleine transformation, les véhicules évoluant des systèmes mécaniques traditionnels aux Software-Defined Vehicles (SDV). Ce changement exige de nouvelles approches en matière de développement logiciel, l'architecture orientée services (SOA) s'imposant comme le paradigme privilégié pour le design d'applications automobiles flexibles et évolutives. Chez ZEEKR, nous avons adopté cette transition en établissant un workflow complet basé sur l'approche Model-Based Design pour le développement d'applications SOA qui fonctionnent sur notre système d'exploitation embarqué.

Le développement traditionnel de logiciels automobiles utilisant l'approche Model-Based Design s'est principalement concentré sur les implémentations d’AUTOSAR^® Classic Platform, où les composants logiciels (SW-C) interagissent via des interfaces d'environnement d'exécution (RTE) standardisées. Cependant, l'architecture SOA introduit de nouveaux patterns de communication tels que les appels client-serveur et les interactions par messages, ce qui nécessite des ajustements importants des pratiques de développement établies. Le défi consiste non seulement à modéliser ces nouveaux patterns de communication, mais aussi à gérer la complexité accrue des architectures logicielles dans un environnement non normalisé AUTOSAR.

Notre équipe chez ZEEKR a relevé ces défis grâce à un workflow basé sur l'approche Model-Based Design pour le développement d'applications SOA. Cet article décrit trois domaines clés de ce workflow :

• Modélisation du comportement SOA à l'aide des fonctionnalités d'interface client-serveur de Simulink^®
• Maintenance d'architectures logicielles complexes grâce à des outils personnalisés basés sur System Composer™
• Implémentation d'une vérification et d'une validation efficaces pour les applications SOA

Notre expérience démontre comment les ingénieurs peuvent utiliser l'approche Model-Based Design pour accélérer la transition des systèmes embarqués traditionnels vers des architectures logicielles modernes basées sur l'architecture SOA pour les SDV.

Modélisation d'applications orientées services dans Simulink

L'architecture SOA introduit de nouveaux patterns de communication qui diffèrent fondamentalement de ceux des systèmes embarqués traditionnels. Les applications AUTOSAR classiques communiquent via des interfaces RTE simples, qui facilitent des interactions étroitement couplées et définies statiquement entre les composants logiciels. En revanche, les patterns de communication SOA, tels que les appels de procédure à distance et les interactions par messages, sont plus flexibles et sophistiqués. Ils permettent également le découplage du matériel et du logiciel, ainsi que le design hiérarchique du logiciel. Pour exploiter pleinement ces patterns, nous suivons un workflow de développement basé sur l'approche Model-Based Design, qui comprend la modélisation des applications SOA dans Simulink et la génération de code C++ avec Embedded Coder^®, en créant du code d'intégration middleware avec un générateur de wrapper que nous avons construit, et en fusionnant le code de l'application et le code d'intégration dans des packages d'application déployables. Ce workflow automatisé ne nécessite aucun code C++ écrit à la main. Le code wrapper généré automatiquement fait le lien entre le code d'application que nous avons généré à partir de nos modèles Simulink et l'environnement d’exécution ZEEKR ARK OS.

Un modèle SOA typique dans notre workflow comprend des fournisseurs de services et des clients, tous deux modélisés dans Simulink (Figure 1). Cette structure capture le comportement essentiel de l'architecture SOA : invocation de service découplée, échange de messages explicite et séparation claire entre communication et calcul. Il nous permet d'exprimer clairement les concepts SOA au sein de Simulink et de préparer ces modèles pour un déploiement dans un environnement distribué et orienté services.

Nos scénarios de déploiement couvrent à la fois les environnements informatiques centralisés et distribués (Figure 2). Les applications orientées services, modélisées dans Simulink, s'exécutent sur une unité de calcul centrale haute performance. Parallèlement, les composants Classic AUTOSAR, également développés sous Simulink, s'exécutent sur un microcontrôleur et interagissent directement avec les actionneurs du véhicule. Ce déploiement mixte reflète la tendance plus générale vers des architectures de domaine centralisées, où les contrôleurs de domaine gèrent le traitement de haut niveau tandis que les nœuds périphériques gèrent le contrôle de bas niveau. Avec Simulink, nous pouvons supporter les deux aspects de cette architecture, en utilisant un environnement de développement unifié pour modéliser, simuler et générer du code pour des systèmes automobiles hétérogènes.

Gestion des architectures logicielles complexes avec System Composer

À mesure que les applications orientées services gagnent en ampleur et en complexité, la gestion de leur structure devient un défi crucial. Avec de multiples services interagissant à travers de multiples unités logicielles, il n'est plus suffisant de traiter chaque modèle de manière isolée. Nous avons plutôt besoin d'une représentation architecturale claire de la façon dont les composants logiciels sont liés les uns aux autres, notamment de la manière dont ils sont regroupés, dont ils communiquent et où ils sont déployés. De nombreux outils d'architecture logicielle automobile disponibles dans le commerce, y compris les outils de création AUTOSAR, supposent souvent un environnement basé sur AUTOSAR et ne supportent pas la flexibilité du déploiement de modèles de communication basés sur les services pour les systèmes d'exploitation personnalisés. Pour répondre aux besoins de notre framework SOA et de notre système d'exploitation embarqué, nous avons construit notre propre environnement de modélisation d'architecture. SOA Model Composer (SOMOC) s'appuie sur les capacités d'ingénierie système basée sur les modèles (MBSE) et les éléments de design architectural de System Composer, ainsi que sur les capacités de programmation orientée objet de MATLAB^®. Pour faciliter l'utilisation, nous avons créé une interface utilisateur personnalisée avec MATLAB et App Designer (Figure 3).

SOMOC supporte une approche structurée pour définir et gérer les SOA à travers quatre niveaux clés : architecture système, processus, composant logiciel et définition de service (Figure 4). Cette organisation hiérarchique utilise les fonctionnalités de composants de référence de System Composer pour établir une traçabilité claire, des systèmes de haut niveau jusqu'aux services individuels.

SOMOC étend les modèles d'architecture avec des profils et des stéréotypes personnalisés qui capturent des métadonnées spécifiques à l'architecture SOA telles que les identifiants de service, les namespaces et les informations de version. Les architectes système de ZEEKR utilisent SOMOC pour traduire les exigences fonctionnelles (importées à partir de fichiers ARXML générés lors du design du système) en architectures déployables en définissant les limites des processus, les interfaces de service et les composants logiciels. À partir de ces modèles d'architecture, SOMOC génère automatiquement des modèles Simulink de type shell avec des interfaces cohérentes, offrant aux développeurs un point de départ fiable pour implémenter un comportement ou une logique interne (Figure 5). Cette automatisation standardise le workflow entre l'architecture et l’implémentation, assure la synchronisation des interfaces et offre à nos équipes un point de référence commun tout au long du développement.

Tests multiniveaux pour les applications SOA

Chez ZEEKR, nous validons nos applications orientées services grâce à une combinaison de tests au niveau du modèle et au niveau du code. Nous commençons par des tests unitaires et de modèles dans Simulink avec Simulink Test™, en utilisant des bancs d'essai pour isoler les composants individuels et vérifier les interactions de service (Figure 6). Pour chaque modèle, les ingénieurs peuvent simuler la communication avec les composants homologues (par exemple, un fournisseur simulé pour un modèle de consommateur) et vérifier les réponses attendues et le comportement de l'interface. Cette validation en amont permet d'identifier les erreurs de logique ou les incompatibilités d'interface avant la génération du code.

Après avoir généré le code de l'application et l'avoir intégré à notre système d'exploitation embarqué, nous effectuons des tests d'exécution à l'aide de notre Service Verification Toolkit (SVT), un plugin léger intégré à Visual Studio Code (Figure 7). SVT permet aux équipes d'importer des définitions d'interface de service à partir de fichiers ARXML, puis de tester les interfaces de méthode et de sujet en simulant la communication de service au niveau de l'application. Il peut agir soit en tant que consommateur, soit en tant que fournisseur : en envoyant des requêtes de méthode, en traitant les réponses, en publiant des données sur un sujet ou en s’abonnant à des messages. SVT affiche les valeurs échangées entre les interfaces de service, aidant ainsi les ingénieurs à confirmer que l'application déployée se comporte correctement dans différents scénarios d'interaction.

A venir

Alors que nous continuons à développer de nouvelles applications orientées services pour notre déploiement embarqué, nous affinons et élargissons également notre workflow basé sur l'approche Model-Based Design avec MATLAB, Simulink, System Composer et Embedded Coder. Ce workflow a déjà prouvé sa valeur en accélérant le développement et en minimisant les difficultés inhérentes à l'écriture manuelle de code. Grâce à notre capacité à réaliser la modélisation d'architecture, la modélisation de services, la simulation, la génération de code et les tests d'applications orientées services et basées sur AUTOSAR dans un seul environnement, nous disposons d'une base logicielle évolutive pour soutenir le développement SDV qui continue de remodeler le paysage automobile.