Cas d'utilisation : Validation d’architectures AUTOSAR

Bien qu’AUTOSAR fournisse un standard pour l’échange de fichiers de description de système, des difficultés surviennent souvent lors de l’échange de données. Ceci concerne aussi bien l’échange de données entre constructeurs et fournisseurs que l’échange de données entre différents outils AUTOSAR. Il arrive souvent que la cohérence des données ne soit pas contrôlée au début du processus de développement. Cela signifie que des fichiers ARXML incomplets ou incohérents pourraient être échangés. Il en résulte des pertes de temps, un surcroît de travail puisque les erreurs doivent en effet être notifiées, corrigées à la source et l’échange de données doit être réitéré.

Afin d’atteindre un niveau de qualité plus élevé avant l’échange de données, il est nécessaire d’effectuer une validation manuelle ou automatique des données. L’idéal est de le faire bien avant l’échange de données.

Exemples d’échange de données

Entre constructeurs et fournisseurs

Les données échangées entre constructeurs et fournisseurs sont habituellement composées de fichiers de description du système. Avant qu’un fichier soit transmis, son exhaustivité doit être vérifiée selon un processus propre à la société. Des données incomplètes sont par exemple des types de données ou des valeurs d’initialisation manquantes ou encore des éléments manquants dans la spécification du bus. Pour cet échange de données, les données sont habituellement spécifiées jusqu’à un certain niveau de détail variable d’une société à l’autre.

En plus de l’exhaustivité, la cohérence sémantique doit être contrôlée. Ceci peut être effectué à l’aide des contraintes AUTOSAR qui définissent des règles sémantiques basées sur le schéma AUTOSAR. Il est ainsi judicieux d’inclure des contrôles sémantiques pouvant être également partiellement spécifiques à votre société. Les contrôles sémantiques peuvent être, par exemple, utilisés pour vérifier que les valeurs initiales sont bien comprises dans la plage dynamique autorisée pour le type de données concerné.

Entre outil d’architecture et générateur RTE

Dès qu’il y a échange de données entre des outils, différentes conditions s’appliquent. Un générateur RTE, par exemple, nécessite des données complètes pour tout ce qui concerne le RTE. Cela signifie qu’un type de données d’implémentation doit être défini pour chaque type de données d’application, qu’une spécification détaillée de l’accès de données des « runnables » aux variables est nécessaire, etc.

A l’image des interfaces entre les différentes parties, en plus de l’exhaustivité, l’exactitude sémantique est également un facteur déterminant pour l’échange de données entre un outil d’architecture et un générateur RTE. Dans ce cas, les contraintes AUTOSAR sont également un point de départ dans la recherche d’erreurs sémantiques et peuvent être complétées afin d’inclure des contrôles supplémentaires.

Validation automatique et manuelle

Pour le développement basé sur AUTOSAR, dSPACE propose l’outil puissant SystemDesk. Il fournit des fonctionnalités de validation complètes permettant d’éviter des corrections répétitives et fastidieuses. En général, la validation devrait être effectuée aussi souvent que possible pendant la création des données ce qui permettrait aux utilisateurs de détecter et d’éliminer les erreurs très tôt dans le développement.

SystemDesk présente un jeu de règles standard complet qui couvre une grande partie des cas d’utilisation quotidiens. Les règles incluses comprennent de nombreuses contraintes relatives aux modèles de composants logiciels et au modèle du système selon AUTOSAR ainsi que les vérifications d’exhaustivité pour la génération du RTE.

Les utilisateurs peuvent dès lors lancer directement la validation, sans difficulté. Il est également possible de sélectionner seulement quelques-unes des règles définies afin de les utiliser dans un scénario particulier. De plus, les utilisateurs peuvent facilement ajouter leurs propres règles à celles déjà existantes au moyen de scripts Python. Ceci est très pratique pour deux raisons : Premièrement, c’est la seule possibilité de garantir l’exhaustivité dans un processus spécifique à une société. Deuxièmement, cette option permet de créer des règles pour un outil particulier : p. ex., pour un générateur RTE spécifique qui exige des données spécifiques.

Une opération de validation complète détecte et élimine les erreurs de façon fiable et ce très tôt. Pour des scénarios d’utilisation restreints, la validation peut être lancée manuellement ce qui donne aux utilisateurs le contrôle complet de chaque étape. Pour les cas d’utilisation plus étendus impliquant un grand nombre d’acteurs et de fichiers, SystemDesk offre un processus automatisé qui valide les fichiers à chaque enregistrement.

Dans les deux cas, un rapport de validation fournit des informations sur toutes les erreurs détectées, y compris des informations détaillées avec des messages d’erreur précis et utiles ainsi que des liens directs entre la description d’erreur et le composant concerné.

En plus de ses capacités de validation, SystemDesk est très ouvert dès qu’il s’agit d’importer des fichiers ARXML. Tous les fichiers qui ont été générés d’après le schéma AUTOSAR, sont importés et exportés dans leur intégralité. Ainsi, SystemDesk ne crée pas de nouvelles difficultés à l’import de fichiers. Le fait d’utiliser SystemDesk pour la validation ne crée donc pas de goulot d’étranglement nécessitant d’adapter la chaîne d’outils.