AUTOSAR
Prise en charge complète pour tester les modèles et le code de production.
Vos interfaces AUTOSAR sont définies dans le code. Votre modèle n’en a pas connaissance.
Tester des composants Classic et Adaptive impose de résoudre manuellement cet écart et de remplacer par des stubs chaque dépendance RTE ou ARA avant de pouvoir exécuter le moindre cas de test.
Une norme pensée pour la réutilisation.
AUTOSAR, abréviation de Automotive Open System Architecture, est un cadre d’architecture logicielle standardisé qui améliore l’efficacité, l’évolutivité et la réutilisabilité des logiciels dans l’industrie automobile. Il fournit des lignes directrices et des spécifications pour développer des composants logiciels automobiles capables de s’intégrer et d’interagir sur différents calculateurs.
En favorisant une approche modulaire et en couches, AUTOSAR gère la complexité et sépare les fonctions logicielles du matériel, permettant ainsi la flexibilité et l’interopérabilité. Les interfaces et protocoles de communication standardisés favorisent la compatibilité entre les systèmes automobiles, facilitant la réutilisation des logiciels entre les modèles et les générations de véhicules.
- Modulaire et en couches
- Indépendant du matériel
- Interfaces standardisées
- Réutilisable d’un calculateur à l’autre
Deux plateformes, une norme.
AUTOSAR Classic et AUTOSAR Adaptive partagent le même objectif global — standardiser les logiciels automobiles —, mais répondent à des exigences différentes.
AUTOSAR Classic
Conçu principalement pour les systèmes de contrôle en temps réel dur, tels que les systèmes de gestion moteur et de freinage, qui exigent un comportement déterministe et des réponses à faible latence.
AUTOSAR Adaptive
Cible les systèmes de calcul haute performance généralement utilisés pour l’infodivertissement, la télématique et les systèmes avancés d’aide à la conduite, en s’appuyant sur les mises à jour logicielles dynamiques, la communication orientée services et la prise en charge du système d’exploitation POSIX.
Deux écarts apparaissent lorsque vous testez aux deux niveaux.
AUTOSAR offre de nombreux avantages, mais pose aussi des défis spécifiques lorsqu’il s’agit de tester le logiciel au niveau du modèle Simulink comme au niveau du code de production.
Correspondance entre les éléments du modèle et du code
Les tests sont nécessaires au niveau du modèle comme au niveau du code. Or, si les interfaces AUTOSAR sont définies dans le code, elles n’existent pas au niveau du modèle. Le générateur de code comble cette lacune et, selon l’outil utilisé — dSPACE TargetLink ou MathWorks Embedded Coder —, l’architecture du modèle d’un même composant AUTOSAR peut varier considérablement. L’outil de test doit comprendre automatiquement cette correspondance afin que les tests puissent s’exécuter aux deux niveaux sans préparation manuelle du harnais de test.
Création de stubs pour les tests SIL
Tester des composants logiciels AUTOSAR ou des applications Adaptive au niveau du code de production (SIL) exige de compiler le code. Or ces composants sont encore moins autonomes que les applications non AUTOSAR classiques. Les dépendances à la RTE (Classic) ou à ARA (Adaptive) doivent être remplacées par des stubs pour permettre la compilation et le test des unités individuelles.
Tester AUTOSAR avec BTC TestStack.
BTC Embedded Systems est membre du consortium AUTOSAR et met à profit de nombreuses années d’expérience dans la prise en charge de la plateforme.
Prise en charge complète d’AUTOSAR Classic et AUTOSAR Adaptive
AUTOSAR Classic et AUTOSAR Adaptive sont entièrement pris en charge pour dSPACE TargetLink et MathWorks Embedded Coder.
Compréhension automatique de l’architecture
BTC TestStack analyse et comprend automatiquement l’architecture AUTOSAR, en extrayant une interface de test correspondante — par exemple, un appel client/serveur avec une sémantique « Get » est interprété comme un signal d’entrée pour l’architecture de test.
Exécution des tests aux deux niveaux, sans préparation manuelle du harnais de test
BTC TestStack comprend la correspondance entre les éléments du modèle et ceux du code ; les tests peuvent ainsi s’exécuter aux deux niveaux sans préparation manuelle d’un harnais de test.
Gestion automatique des stubs
Toutes les références externes sont correctement remplacées par des stubs, soit au moyen des implémentations fournies par le générateur de code, soit par l’ajout automatique des éléments manquants.
BTC TestStack
est certifié ISO 26262
Le certificat porte sur des normes de sécurité fonctionnelle dans plusieurs secteurs :
Pour ISO 26262, BTC TestStack est certifié selon le niveau de confiance dans l’outil (TCL) le plus élevé, valable pour tous les niveaux ASIL, y compris ASIL D. Sur demande, nous fournissons gratuitement le certificat et le rapport aux clients, ce qui supprime l’essentiel de leur effort de qualification des outils.
Découvrir le reste de la suite.
Tests basés sur les exigences
Tests basés sur les exigences pour Simulink, TargetLink, Embedded Coder, code écrit à la main et généré par IA.
Test back-to-back
Les tests back-to-back entre modèle et code sont fortement recommandés par la norme ISO 26262.
ISO 26262
L’exhaustivité des activités de test ne peut être évaluée sans mesurer la couverture structurelle de l’unité logicielle.
Échangez avec notre équipe d’ingénierie.
Expliquez-nous où se situe réellement votre difficulté d’ingénierie. Nous vous indiquerons si la prochaine étape la plus pertinente est une licence d’évaluation, un atelier ou un échange.