Faire le lien entre système et logiciel : une approche unifiée pour le développement de fonctionnalités des architectures distribuées SDV

Comment les équipes de développement de Software-Defined Vehicles (SDV) peuvent-elles prendre les bonnes décisions architecturales et logicielles dès le début, ainsi que les valider en continu, lorsque les fonctionnalités s'étendent aux ordinateurs centraux, aux contrôleurs zonaux et aux dispositifs périphériques, mêlant des architectures orientées services et basées sur les signaux à travers des frontières d'intégration complexes ?

Les SDV redéfinissent l'ingénierie automobile, et pas seulement en ajoutant du code. Ils sont en train de remodeler où le logiciel fonctionne, comment les caractéristiques sont composées, et ce que « l’intégration » signifie réellement… À mesure que les fonctionnalités s'étendent sur plusieurs domaines de calcul, protocoles de communication, voire différentes organisations, les équipes ont besoin d'approches qui permettent de maintenir l'alignement entre l'intention architecturale et le comportement du logiciel dès le premier jour.

Cependant, cette liberté architecturale a un prix : il y a plus d'interfaces, plus de chemins temporels, plus de modes de défaillance et plus de possibilités pour que de petits décalages apparaissent tardivement, surtout lorsque les véhicules, les fournisseurs et les calendriers sont déjà verrouillés. Dans ce contexte, les ingénieurs systèmes et logiciels doivent prendre les bonnes décisions au plus tôt et les valider en permanence à l'aide de modèles et de simulations.

Pour aider les entreprises à relever ce défi, KPIT et MathWorks associent l'application de méthodologies éprouvées, une expertise approfondie du domaine automobile et une chaîne d'outils intégrée qui relie l'intention du système à des modèles exécutables. Il en résulte un workflow de bout en bout et traçable qui supporte les premières décisions architecturales et logicielles, ainsi que la validation continue par simulation, reliant l'intention des parties prenantes (en tant que source unique de vérité) aux choix d'architecture, aux logiciels déployables et aux preuves de vérification.

Principaux défis liés aux fonctionnalités SDV distribuées

Le développement des fonctionnalités SDV échoue rarement parce qu'une équipe a écrit du « mauvais code ». Elle échoue car la fonctionnalité franchit les limites de l'ECU, mélange les interactions orientées service et celles basées sur les signaux, et expose des écarts entre le design et l’implémentation. Ces lacunes ont tendance à rester cachées jusqu'à une intégration tardive ; par conséquent, les défis suivants déterminent souvent si un programme peut fournir des fonctionnalités complexes rapidement et avec assurance :

• Ambiguïté des exigences à grande échelle : Les exigences fonctionnelles et non fonctionnelles doivent prendre en compte la distribution, le calendrier, les défaillances partielles, la sécurité et la cybersécurité.
• Les décisions architecturales se répercutent en aval : Choix de services par rapport aux choix de signaux et aux interfaces de pilotage de l'allocation ECU, partitionnement logiciel et effort de vérification.
• Alignement inter-équipes : Les équipes multidomaines ont besoin de modèles partagés et traçables pour éviter les retouches tardives.
• Fragmentation de la chaîne d'outils : Les outils déconnectés entravent la traçabilité et la validation « à gauche » ; l’intégration virtuelle exige des modèles d’architecture et de comportement cohérents.

Un workflow unifié combinant l’approche Model-Based Systems Engineering et l'approche Model-Based Design

Cet article présente une approche d'ingénierie axée sur les fonctionnalités qui combine l'approche Model-Based Systems Engineering (intention du système/des fonctionnalités, exigences et architecture) avec l'approche Model-Based Design (modèles de logiciels exécutables, simulation et génération de code). Le workflow suit une approche systématique et descendante du développement de l'architecture et des exigences, avec le niveau d'abstraction approprié appliqué à chaque étape. Il peut être appliqué pour développer des fonctionnalités SDV qui couvrent des calculateurs hétérogènes et mélangent des interactions orientées services et basées sur les signaux.

Cette approche accélère la livraison des fonctionnalités en intégrant et en validant les fonctionnalités distribuées dans un environnement simulé à l'aide de modèles de composants ECU et logiciels connectés. Elle améliore également la traçabilité de bout en bout pour l'analyse d'impact et la conformité, réduisant ainsi les retouches de dernière minute lors du déploiement sur les unités de contrôle centrales, zonales et périphériques.

En pratique, les équipes ont besoin d'un moyen de prendre des décisions architecturales testables tôt : cette fonctionnalité peut-elle répondre aux exigences de synchronisation entre les zones, résister aux pannes partielles, satisfaire aux contraintes de sécurité et de cybersécurité, et être implémentée de manière cohérente sur les cibles classiques/adaptatives AUTOSAR^® ? Un workflow unifié combinant l’approche Model-Based Systems Engineering et l'approche Model-Based Design permet de poser ces questions de manière explicite et d'y répondre avant l'intégration du hardware et du véhicule complet.

Passons en revue les principales étapes du workflow de l'approche axée sur les fonctionnalités :

1. Définition du périmètre des fonctionnalités : Recueillir les besoins des parties prenantes, définir les limites des fonctionnalités, les acteurs et les dépendances.
2. Configuration requise : Définir les cas d'utilisation et les comportements, et dériver les exigences du système (fonctionnelles et non fonctionnelles) avec des critères d'acceptation clairs.
3. Architecture du système : Créer et valider l'architecture fonctionnelle (fonctions et interactions), l'identification et l'architecture des sous-systèmes indépendants de la plateforme, et l'architecture système dépendante de la plateforme (ECU/réseaux et décisions de service versus signal).
4. Architecture logicielle : Déterminer les exigences logicielles et l'architecture logicielle par ECU (HPC/zonal/edge), alignées sur les besoins AUTOSAR Classic/Adaptive ou personnalisés.
5. Design logiciel détaillé : Développer des modèles exécutables pour les algorithmes et le comportement des composants et réutiliser les ressources existantes lorsque cela est possible.
6. Vérification fonctionnelle : Effectuer des simulations en boucle fermée pour valider le comportement avant que le hardware ne soit disponible.
7. Génération et intégration de code : Générer du code AUTOSAR Classic/Adaptive ou personnalisé prêt pour la production, avec une intégration transparente dans les workflows CI et de vérification.

Voici les principaux avantages que procure l'approche proposée :

• Détection précoce des défauts : Les modèles exécutables et les simulations permettent de mettre en évidence les problèmes d'intégration et de synchronisation avant l'intégration hardware et l'intégration complète du véhicule.
• Itérations plus rapides : Les tests d'intégration virtuelle réduisent les cycles de reprise et accélèrent la livraison des fonctionnalités.
• Ingénierie traçable : Des liens cohérents entre les artefacts permettent des contrôles de couverture et une analyse d'impact efficace lorsque les exigences changent.
• Ressources architecturales réutilisables : L'architecture logique propose une référence indépendante de la plateforme pour les systèmes réutilisables dans les différents programmes de véhicules.
• Résultats prêts pour le déploiement : L'architecture logicielle et la génération de code sont alignées sur AUTOSAR Classic/Adaptive et la communication mixte SOA/signal.

Dans la suite de cet article, nous illustrerons cette approche par un cas d'utilisation réel.

Exemple : Développement d'une fonction de gestion des volets de chargement

Pour illustrer ce processus, nous allons examiner une fonctionnalité réelle qui touche les utilisateurs, le hardware, le réseau et les contraintes de sécurité : la gestion du volet de charge d’un véhicule électrique. Cet exemple montre comment un processus axé sur les fonctionnalités passe de la définition du périmètre et des exigences à l'allocation de l'architecture, à la simulation et à la génération du code de production, sans perdre la traçabilité en cours de route.

Un système de gestion des volets contrôle le volet d'entrée de charge du véhicule (Figure 1). Il concilie en permanence le monde physique (par exemple, la détection de position, l'état de l'actionneur et le retour d'information sur le verrouillage) avec le contexte de charge (par exemple, l'état du véhicule, l'état du chargeur embarqué) pour décider quand le volet peut s'ouvrir, doit se fermer ou doit se verrouiller. Le système publie ensuite des mises à jour d'état et des avertissements à destination du conducteur et des autres fonctions du véhicule. En couvrant la détection, l'actionnement et la coordination de l'ECU, le système de gestion des volets propose un proxy petit mais réaliste pour le développement plus large des fonctionnalités distribuées SDV.

Définition du périmètre des fonctionnalités

Nous définissons les limites des fonctionnalités (acteurs, entrées/sorties et dépendances) afin d'établir un périmètre commun et d'alimenter la collecte et l'analyse des exigences.

Dans cet exemple, nous supposons que le véhicule utilise une architecture zonale électrique/électronique (E/E) existante composée d'un ordinateur central haute performance (HPC), d'un calculateur zonal qui sert également de passerelle et de calculateurs périphériques responsables de la détection et de l'actionnement en temps réel.

À ce stade, nous effectuons une analyse d'impact et utilisons System Composer™ pour établir un diagramme de limites de fonctionnalités qui capture les fonctionnalités affectées par la gestion du volet et les informations échangées entre ces fonctionnalités. La vue de la limite clarifie quelles fonctions du véhicule et quels acteurs externes interagissent avec la fonction de gestion du volet et quelles informations sont échangées (Figure 2).

Niveau fonctionnel

Nous identifions les principaux cas d'utilisation et déduisons le comportement des fonctionnalités à travers un diagramme de cas d'utilisation, puis nous traduisons ce comportement en exigences système claires. Nous avons identifié deux cas d'utilisation : « Démarrer une session de charge » et « Arrêter une session de charge » (Figure 3).

Une fois les deux cas d'utilisation identifiés, l'étape suivante consiste à définir les différentes activités réalisées par la fonctionnalité dans chaque cas d'utilisation. Cela permettra de décrire le comportement de la fonctionnalité et de définir un ensemble initial d'exigences système pour la gestion des volets. Ensuite, nous utilisons System Composer pour créer des diagrammes d'activité (Figure 4).

Sur la base de l'analyse et des diagrammes précédents, nous pouvons maintenant créer les exigences au niveau du système à l'aide de l'éditeur d'exigences, qui fait partie de Requirements Toolbox™ (Figure 5). Nous avons des exigences relatives aux opérations, telles que l'ouverture et la fermeture du volet et la notification de l'état du volet.

Ensuite, nous créons une architecture fonctionnelle et répartissons les exigences entre les fonctions afin de maintenir la traçabilité. Cela inclut la définition de :

• Fonctions du système : unités fonctionnelles techniques qui réalisent collectivement la fonctionnalité
• Interactions : comment ces fonctions communiquent et collaborent

Sur la base de l'analyse des exigences du système, nous décomposons la fonction de volet de chargement en quatre fonctions (Figure 6) :

• Mesurer le courant de la prise de charge
• Obtenir l'état du volet et notifier l'utilisateur
• Rabat fermé
• Rabat ouvert

Dans le cadre de la définition de l'architecture fonctionnelle, nous attribuons chaque exigence système à la ou aux fonctions chargées de la satisfaire et, le cas échéant, à l'interaction qui véhicule les informations nécessaires. Cette répartition garantit que chaque exigence est couverte par les éléments de design, rend les lacunes/chevauchements visibles au début et assure la traçabilité des exigences aux fonctions pour la design et la vérification logiques/physiques en aval. Concrètement, cette répartition peut être effectuée efficacement en faisant glisser et en déposant les exigences sur les composants du System Composer (Figure 7).

Identification et architecture des sous-systèmes indépendants de la plateforme

Nous attribuons des fonctions à des sous-systèmes logiques et définissons les interfaces logiques entre eux afin de créer une vue d'architecture réutilisable et indépendante de la plateforme (Figure 8) :

• Un sous-système d'interface de charge, chargé d'ouvrir et de fermer le volet et de notifier l'état du volet.
• Un sous-système de contrôle de charge, chargé d'orchestrer les requêtes provenant de l'interface de communication et de gérer toutes les opérations de charge.
• Un sous-système de communication de facturation, qui gère les communications avec l'utilisateur et le reste du système

Architecture système dépendante de la plateforme

Nous attribuons maintenant les sous-systèmes logiques à une architecture E/E cible (par exemple, ECU périphérique, contrôleur zonal et ordinateur central/HPC) et définissons les interfaces principales, y compris les interactions qui sont implémentées sous forme de services ou de signaux.

Une fois que nous avons identifié les différents composants, nous pouvons créer un diagramme d'architecture système dans System Composer, qui met en évidence les limites des composants et les informations que les composants doivent échanger pour implémenter la fonction de gestion des volets (Figure 9).

Architecture logicielle, simulation et génération de code

À partir des exigences et de l'architecture du système, nous déduisons les exigences et l'architecture logicielles par ECU (HPC, zonale, périphérique) et les affinons en composants logiciels déployables. Sur le HPC, la fonctionnalité est décomposée en services et applications (par exemple, AUTOSAR Adaptive, le cas échéant), tandis que les nœuds zonaux/périphériques hébergent des fonctions de détection/actionnement critiques en temps réel (par exemple, AUTOSAR Classic ou équivalent). Les interfaces (services, signaux et types de données) sont transportées de manière cohérente de l'architecture physique vers les ports et connecteurs logiciels, permettant des contrôles de cohérence précoces, une modélisation du comportement exécutable et l'intégration de points d'ancrage de simulation (pour les tests MIL/SIL et les exécutions en boucle fermée) avant que le hardware cible ne soit disponible.

Pour commencer, nous créons l'architecture logicielle de haut niveau pour les compositions HPC, ECU zonal et ECU périphérique, qui sont liées à l'architecture du système (Figure 10).

Nous avons défini et modélisé les composants logiciels pour chaque composition architecturale au sein du canevas de modélisation d'architecture dans System Composer. La composition HPC comprend trois composants de service adaptatif AUTOSAR implémentés dans Simulink^® en utilisant un paradigme SOA (Figure 11).

Une fois que nous avons modélisé l’implémentation de la fonctionnalité sur les trois calculateurs, nous pouvons créer un modèle de simulation en boucle fermée qui connecte les calculateurs à un modèle de l'installation du volet , y compris des modèles du capteur de courant, du capteur de position et de l'actionneur, permettant ainsi une vérification rapide du comportement fonctionnel dans des conditions réalistes. Par exemple, nous pouvons utiliser la simulation pour évaluer comment le système réagit à une demande de l’utilisateur d’ouvrir le volet à différentes vitesses du véhicule (Figure 12).

Une fois la vérification terminée, l'étape suivante du workflow consiste à utiliser Embedded Coder® pour générer un code prêt pour la production en vue de l'intégration et du déploiement (Figure 13). Simulink offre un support prêt à l'emploi pour la génération de code conforme à AUTOSAR Classic et à AUTOSAR Adaptive, permettant une intégration et un déploiement plus poussés.

De plus, lorsqu'une nouvelle exigence est introduite, elle peut être prise en compte au niveau des exigences du système et soumise à une analyse d'impact afin d'identifier les éléments affectés. Les modifications qui en résultent sont visualisées et propagées aux interfaces système et logicielles concernées, après quoi le workflow est itéré pour s'adapter à l'évolution des besoins. Ce processus est rendu possible grâce à une traçabilité de bout en bout, utilisant le diagramme de traçabilité (Figure 14) pour gérer les changements dynamiques tout au long du cycle de vie du développement SDV.

Migration des applications existantes

Au-delà du développement de nouvelles fonctionnalités, ce même workflow intégré supporte également la migration systématique des fonctions existantes, basées sur des signaux, vers des architectures logicielles distribuées et orientées services. En pratique, les fonctions existantes initialement implémentées sous forme de chaînes exécutables étroitement couplées échangeant des signaux CAN ou des données locales à l'ECU peuvent être analysées aux niveaux fonctionnel et logique, décomposées en responsabilités plus claires et restructurées en fournisseurs de services, consommateurs et logique d'orchestration avec des interfaces, des événements et des contrats de données explicitement définis. Cela permet de préserver un comportement fonctionnel validé tout en réattribuant les responsabilités entre les HPC, les contrôleurs de zone et les ECU périphériques. Cela permet également d'évaluer l'impact des changements de communication sur le calendrier, la sécurité et l'intégration. Étant donné que les exigences, les éléments d'architecture, les composants logiciels et les artefacts de vérification restent liés de manière traçable, les équipes peuvent moderniser progressivement les implémentations existantes, en réutilisant les cas de test et les preuves de conformité tout en maintenant l'alignement entre les services migrés et l'intention de design d'origine.

Conclusion

L'intégration de l'approche Model-Based Systems Engineering et de l'approche Model-Based Design offre un workflow pratique et complet pour le développement des fonctionnalités SDV, permettant une intention système plus claire, une vérification plus précoce par simulation et des artefacts logiciels déployables. Cette approche est explicitement axée sur les fonctionnalités et structurée pour exploiter au mieux la traçabilité à toutes les étapes du design, afin que les décisions d'ingénierie restent cohérentes entre l'intention et le déploiement. Les avantages sont tangibles, car le workflow permet des itérations plus rapides, moins de surprises lors de l'intégration en phase finale et une implémentation plus cohérente sur des calculateurs hétérogènes et des architectures SOA/signal mixtes.

Alors que l'industrie explore des méthodologies de développement pilotées par l’IA, y compris les nouvelles approches d'IA agentique, des questions se posent quant au rôle des pratiques d'ingénierie établies. Dans ce nouveau contexte, la valeur des approches Model-Based Systems Engineering et Model-Based Design apparaît encore plus évidente : dans un cycle de développement où les humains et l'IA collaborent de plus en plus, ces approches offrent la rigueur nécessaire pour ancrer les exigences, clarifier l'intention du système et maintenir l'alignement de l'architecture, du comportement et de la vérification. Cela en fait un fondement essentiel pour développer des logiciels SDV non seulement innovants, mais aussi fiables et maintenables.

En utilisant l'expertise automobile de KPIT et la continuité de la chaîne d'outils offerte par MathWorks, le cadre proposé renforce la collaboration entre les architectes, les développeurs de logiciels et les ingénieurs d'intégration, améliore la traçabilité des exigences à l'architecture et supporte des définitions de systèmes de plus en plus complexes sans sacrifier la faisabilité.

En savoir plus