Introduction
Les solutions logicielles jouent un rôle de plus en plus important dans les systèmes critiques pour la sécurité et liés à la sécurité en général, de sorte qu'un dysfonctionnement logiciel entraîne une responsabilité et une menace réelle qui peut se manifester sous la forme de blessures, de pertes de vies, d'interruption de services essentiels ou de dommages au environnement. En conséquence, des organismes internationaux de normalisation tels que l'ISO (Organisation internationale de normalisation) et la CEI (Commission électrotechnique internationale) ont publié des normes largement reconnues et adoptées qui aident les développeurs de logiciels à certifier la sécurité de leurs logiciels. Quelques exemples sont ISO 26262 (Véhicules routiers – Sécurité fonctionnelle) pour l'automobile, EN 50128 (Systèmes de communication, de signalisation et de traitement - Logiciels pour les systèmes de contrôle et de protection ferroviaires) pour le transport ferroviaire et CEI 61508 (Sécurité fonctionnelle des systèmes électriques, électroniques et électroniques programmables) pour les applications industrielles.
La responsabilité de démontrer que le logiciel d'application et les méthodes, processus et chaînes d'outils logiciels utilisés pour son développement respectent les normes de sécurité fonctionnelle correspondantes incombe clairement au développeur de l'application. Cependant, il est un fait que des parties importantes de la chaîne d'outils échappent au contrôle du développeur. C'est l'une des raisons pour lesquelles la validation des compilateurs, un segment dans lequel Solid Sands est déjà un leader mondial, est devenue un enjeu crucial pour les développeurs de systèmes critiques pour la sécurité. En pratique, aucun compilateur n'est exempt d'erreurs, il est donc extrêmement important de savoir où un compilateur échoue afin d'éviter les erreurs de compilation.
Il est également vrai qu'une partie importante du code qui fait partie de l'application complète sera probablement compilée avec des cas d'utilisation, des ensembles d'options du compilateur et des environnements de construction différents de ceux utilisés par le développeur. En effet, une partie du code qui se retrouve souvent dans une application est constituée de fonctions de bibliothèque précompilées, telles que la bibliothèque standard de C (libc), qui est souvent fournie sous forme binaire au sein d'un kit de développement logiciel (SDK).
Contrairement à ce que l'on pense habituellement, qu'une bibliothèque fournie au format binaire est insensible à tout cas d'utilisation spécifique, c'est-à-dire que le code est invariant, en pratique il n'en est rien. L'incorporation de modèles de types génériques et de macros rend souvent les composants de bibliothèque sensibles au cas d'utilisation. Ainsi, même si la bibliothèque avait été pré-validée par le fournisseur du SDK à l'aide du même compilateur fourni avec le SDK, les exigences du cas d'utilisation, les options du compilateur et l'environnement matériel cible n'auraient presque certainement pas correspondu, ce qui rend difficile la démonstration de la conformité. avec la norme de sécurité fonctionnelle.
Pour surmonter cette limitation, Solid Sands a introduit un nouvel outil de validation de bibliothèque appelé SuperGuard C Library Safety Qualification Suite. Il s'agit d'un package de test basé sur les exigences pour la bibliothèque standard C avec une traçabilité complète des résultats de chaque test aux exigences dérivées de la spécification du langage ISO C. SuperGuard peut être utilisé pour valider les implémentations de la bibliothèque standard C dans les applications critiques pour la sécurité. , à la fois dans les implémentations de bibliothèques tierces non modifiées et auto-développées et maintenues. Son rôle dans le modèle V pour le développement de logiciels est illustré ci-dessous.
Objectif de validation
La validation d'une bibliothèque de logiciels est essentielle car le code de la bibliothèque est lié à l'application et installé sur l'appareil cible. Si un composant de la bibliothèque est défectueux, la sécurité fonctionnelle de l'ensemble de l'application sera compromise. Chaque norme de sécurité fonctionnelle a ses propres objectifs spécifiques lorsqu'il s'agit d'utiliser des bibliothèques de logiciels, mais en général, elles partagent toutes un objectif commun : vérifier que l'implémentation de la bibliothèque est conforme à sa spécification. L'ISO 26262 offre deux façons de valider la bibliothèque, détaillées séparément dans l'ISO 26262 Partie 8 et l'ISO 26262 Partie 6. SuperGuard C Library Safety Qualification Suite peut être utilisé dans les deux cas.
ISO 26262 Partie 8, Clause 12 : Validation des composants logiciels
Pour la classification en tant que produits COTS (commercial off-the-shelf), les bibliothèques sont couvertes par la Partie 8, Clause 12 : « Validation des composants logiciels ». Cette clause répond à la nécessité de valider les composants logiciels existants, tels que les bibliothèques, "afin de démontrer qu'ils peuvent être réutilisés". Il mentionne spécifiquement les "bibliothèques de logiciels fournies par des tiers", qui incluent clairement les bibliothèques standard fournies avec les SDK commerciaux. La clause s'applique également aux logiciels internes réutilisés et aux logiciels open source.
La partie 8, clause 12 stipule qu'une condition préalable à la validation est un énoncé des exigences du composant logiciel. Il suggère également que tester qu'un composant logiciel répond à ces exigences devrait "se référer principalement aux tests basés sur les exigences", qui peuvent être accomplis par "l'application d'un ensemble de tests de validation spécialisé" qu'il devrait "couvrir à la fois les conditions de fonctionnement normales et la réponse si une défaillance survient » et ne doit pas « montrer des erreurs qui pourraient conduire à la non-conformité aux exigences de sécurité ».
Heureusement, la spécification de la bibliothèque pour les langages C et C++ existe et est accessible au public, il existe donc déjà un point de départ pour des tests rigoureux basés sur les exigences. En fait, l'existence et la testabilité du langage et de la spécification de la bibliothèque sont l'une des raisons pour lesquelles les langages de programmation C et C++ sont si répandus dans la communauté des développeurs. Maintenant, la spécification du langage n'est pas écrite comme une liste d'exigences. Une caractéristique clé de la suite de tests Solid Sands SuperGuard est que tous ses tests de bibliothèque sont fermement basés sur les exigences dérivées de la définition du langage C ISO.
Pour répondre à l'exigence selon laquelle le package de test couvre à la fois les conditions normales et les conditions de panne, vous devez implémenter chaque fonction à l'intérieur et à l'extérieur de ses conditions limites, et vérifier la gestion des erreurs de la fonction. Parmi les exigences dérivées de la spécification ISO C pour créer SuperGuard figurent la vérification de la réponse requise en cas de panne telle que définie dans la spécification.
La preuve fiable de l'absence d'erreurs que le non-respect des exigences de sécurité peut entraîner dépend non seulement de tests efficaces basés sur les exigences, mais également de la couverture du code structurel jusqu'à ASIL D (Automotive Safety Integrity Level D), le plus haut niveau d'intégrité pour les applications automobiles . Pour garantir la preuve de l'intégrité, SuperGuard fournit une couverture élevée du code structurel et une couverture MC/DC élevée (condition modifiée/couverture de décision).
SuperGuard intègre également l'analyse et la vérification des classes d'équivalence et des valeurs limites, ainsi que l'estimation des erreurs en fonction des meilleures connaissances et expériences disponibles pour répondre à une fonction de bibliothèque.
ISO 26262 Partie 6 : Développement de produits au niveau logiciel
La partie 26262 de l'ISO 6 adopte une approche parallèle en traitant le code de la bibliothèque de la même manière que les autres codes d'application exécutés sur la cible. Il est intéressant de noter qu'il ne mentionne pas les bibliothèques en tant que catégorie distincte de code et c'est peut-être la raison pour laquelle la nécessité d'une validation de bibliothèque est souvent négligée.
La validation de la bibliothèque standard C telle que détaillée dans la partie 26262 de l'ISO 6 est plus complète que celle détaillée dans la partie 8, car la partie 6 traite de toutes les phases du développement logiciel.
Partie 6, tableau 7 : « Méthodes de vérification des unités logicielles » inclut la vérification basée sur les exigences comme l'une de ses recommandations pour tous les niveaux ASIL. Comme indiqué ci-dessus pour la "validation des composants logiciels" (ISO 26262 partie 8, clause 12), SuperGuard assume tous les tests basés sur les exigences, bien qu'en pratique, il soit recommandé aux développeurs d'utiliser plus d'une des méthodes indiquées dans le tableau pour vérifier un implémentation de la bibliothèque standard C.
SuperGuard utilise également toutes les méthodes répertoriées dans la partie 6, tableau 8 : « Méthodes des cas de test pour tester les unités logicielles ». La méthode 1a, « Analyse des exigences », est utilisée pour décomposer la spécification de la bibliothèque standard C en exigences testables. La description de la bibliothèque standard C est un mélange de définitions (parfois implicites) et de restrictions sur l'utilisation des fonctions, ainsi que des définitions de réponse de fonction. Dans SuperGuard, elles sont également devenues des exigences testables qui constituent la base du package de test, y compris les exigences de traitement des cas anormaux définies dans la norme de langage.
Les méthodes 1b, « Génération et analyse des classes d'équivalence », et 1c, « Analyse des valeurs limites », font référence au partitionnement des domaines des valeurs d'entrée des fonctions et sont couvertes par les spécifications de test SuperGuard, qui fournissent les lien entre les exigences et les tests.
La méthode 1d, « Estimation d'erreur à partir des connaissances et de l'expérience », est basée sur la connaissance de Solid Sands des domaines d'implémentation difficiles pour la bibliothèque C, ainsi que sur des tests de régression effectués depuis le développement initial du package de test et de vérification de Solid Sands. Compilateur SuperTest il y a plus de 30 ans.
Avec cette approche, SuperGuard joue un rôle de premier plan sur le côté droit du modèle V pour le développement de logiciels. En relation avec la norme ISO 26262 Partie 6, Clause 9 : « Vérification de l'unité du logiciel », elle couvre les éléments suivants :
- Réalisation de l'implémentation de la bibliothèque standard C selon vos besoins
- Vérification de l'interface matériel-logiciel par des tests sur le matériel cible
- Confiance en l'absence de fonctionnalités inattendues en vérifiant les cas d'échec et en surveillant la couverture du code
- Vérification des ressources nécessaires par des tests sur le matériel cible
Comment les tests sont développés avec SuperGuard
Lors de la mise en œuvre des vérifications basées sur les exigences recommandées dans les parties 8 et 6 de la norme de sécurité fonctionnelle ISO 26262, le principal problème avec les spécifications de la bibliothèque standard C et C++ est que, bien qu'elles fournissent une description détaillée de la réponse pour chaque fonction, aucune des définissent un ensemble clair d'exigences. Par conséquent, les exigences nécessaires pour chaque fonction doivent être créées à partir des descriptions des réponses.
SuperGuard C Library Safety Qualification Suite intègre la suite de tests éprouvée pour la bibliothèque standard C déjà incluse dans SuperTest, la suite de test et de vérification de compilateur Solid Sands leader au monde, qui suit les spécifications du langage (ISO) depuis plus de 30 ans. Cependant, SuperGuard va beaucoup plus loin que SuperTest dans ses capacités de rapport, ses exigences de documentation, ses tests individuels et ses résultats de test conformément aux normes de sécurité fonctionnelle telles que ISO 26262, EN 50128 et CEI 61508.
Les tests du package de test SuperGuard sont conçus selon les principes suivants, ce qui les rend adaptés à une grande variété d'environnements de développement.
Les tests de SuperGuard sont basés sur la réponse, c'est-à-dire qu'ils vérifient que l'implémentation répond en respectant les spécifications de la bibliothèque. Chaque test exécute la construction ou la fonction testée et compare les résultats de l'exécution avec les résultats attendus ("modèle") définis dans la spécification de la bibliothèque. Le test lui-même indique s'il a été transmis au contrôleur.
Ces tests sont compilés et exécutés dans un environnement d'exécution afin de vérifier la réponse de l'implémentation, ce qui signifie que toute la chaîne d'outils, y compris le processeur cible, est sollicitée pour chaque test. Cela rend SuperGuard adapté à la vérification du matériel de bouclage de la bibliothèque.
Les tests pour la partie autonome de la bibliothèque (généralement utilisée sur des systèmes bare metal) nécessitent un minimum de ressources. La plupart des tests SuperGuard peuvent être exécutés sur des systèmes avec moins de 4K de mémoire, il est donc possible d'utiliser SuperGuard sur de très petits systèmes embarqués.
Pour implémenter des tests basés sur les exigences, SuperGuard fournit une ventilation détaillée des spécifications de la bibliothèque standard C en exigences d'implémentation testables ainsi que des spécifications de test qui décrivent comment chaque exigence est testée. En liant les résultats de chaque exécution de test à la spécification de test correspondante, à l'exigence de test et à la fonction de bibliothèque standard, SuperGuard fournit la traçabilité complète nécessaire pour les tests basés sur les exigences. Pour démontrer qu'il a été réalisé, il fournit une couverture de code structurel proche de 100% pour plus de 80% des fonctions avec un MC/DC (Modified Condition/Decision Coverage) élevé. Notez que cela concerne l'implémentation de la bibliothèque elle-même, et non la couche sous-jacente du système d'exploitation.
Un exemple
Chaque test de bibliothèque dans SuperGuard est développé selon une méthodologie cohérente, comme illustré par la fonction strncpy indiqué ci-dessous. Voici la spécification de la section 7.21.2.4 de la définition du langage C99 :
7.21.2.4 La fonction strncpy
Synopsis
1. #comprendrechaîne.h>
char * strncpy(char * restreindre s1, const char * restreindre s2, size_t n);
Description
2. La fonction strncpy copier pas plus de n caractères (les caractères après un caractère nul ne sont pas copiés) du tableau pointé par s2 à la matrice pointée par s1. Si la copie a lieu entre des objets qui se chevauchent, la réponse est indéfinie.
3. Si la matrice pointée par s2 est une chaîne avec moins de n caractères, des caractères nuls sont ajoutés à la copie dans le tableau pointé par s1 jusqu'à ce qu'ils soient écrits n personnages.
Résultats
4. La fonction strncpy donne la valeur de s1.
L'aspect le plus curieux de cette spécification est que le paragraphe 2 ne spécifie pas de limite inférieure sur le nombre de caractères qu'il copie. strncpy (). dit ainsi : "copier pas plus de n caractères”. La spécification n'exige à aucun moment qu'un caractère soit copié à partir de s2 a s1. Au paragraphe 3, une action est indiquée, en particulier que s1 est rempli de caractères nuls. Pris au pied de la lettre, une implémentation correcte suivant cette spécification consisterait simplement à écrire n caractères nuls dans s1.
En effet, la fonction n'a pas été créée pour cela et ce n'est pas non plus ce qu'elle est censée faire. L'interprétation générale est que la fonction copie autant de caractères que possible à partir de s2 a s1 jusqu'à la chaîne s2 o n ils ont été consommés. Il n'y a pas de confusion à ce sujet et apparemment personne ne s'est plaint de cette phrase depuis ANSI C89 car les mêmes mots sont toujours présents dans C18. Mais pour définir les exigences, nous devons être un peu plus précis.
La première étape de notre processus de développement de tests consiste à extraire un ensemble d'exigences (REQ) de cette description en tenant compte de ce à quoi la fonctionnalité est réellement destinée :
Chaîne de copie REQ: Si s2 pointe vers une chaîne de longueur 'l2' (tel que défini par strlen()) qui est inférieur à n, strncpy () va copier l2 caractères, dans l'ordre, du tableau s2 jusqu'au ventre s1.
REQ-copie: Oui s2 ne pointe pas vers une chaîne de longueur inférieure à n, strncpy () copiera le premier n caractères, dans l'ordre, du tableau s2 jusqu'au ventre s1.
REQ-plus court: Si s2 pointe vers une chaîne de longueur inférieure à n, strncpy () ajoutera des caractères nuls ('\0') après les caractères copiés dans le tableau s1 jusqu'à ce qu'ils soient écrits n personnages tout à fait.
REQ-plus: strncpy () n'écrira pas dans le tableau de destination s1 après le premier n personnages.
REQ-pas de changement: strncpy () ne modifiera pas le tableau s2.
REQ-retour: strncpy () fournira la valeur de s1.
L'exigence REQ-pas de changement suivre la déclaration s2 en tant que matrice constante, mais la déclaration seule ne garantit pas qu'une mise en œuvre de strncpy () n'écris pas dessus s2.
Une spécification de test a été élaborée pour chacune de ces exigences. La spécification de test définit comment un test vérifie si l'exigence est vraie. Une seule spécification de test conduit généralement à un certain nombre de cas d'utilisation couvrant les domaines d'entrée et de sortie de la fonction. Les cas de test sont implémentés par le test. La spécification de test relie l'exigence aux tests.
Par exemple, les spécifications d'essai pour les exigences de DEMANDE-chaîne de copie y DEMANDE-nomore sont les suivants:
Spécification d'essai pour Chaîne de copie REQ: appliquer la fonction strncpy () avec différentes valeurs de paramètres n (inclus n==0) égal et supérieur à la longueur de la chaîne source. Vérifiez que la chaîne source a été copiée dans le tableau de destination jusqu'au dernier caractère nul.
Spécification d'essai pour REQ-plus: Dans tous les cas, vérifiez que le caractère avec index n dans le tableau de destination s1 n'a pas été modifié. Si cela concorde avec le test, vérifiez qu'aucun caractère n'a été modifié après n.
Dans ce cas, la spécification de test est mise en œuvre REQ-plus dans le même fichier de test que les autres cas de test pour strncpy (). Étant donné que l'exigence doit être maintenue inconditionnellement chaque fois qu'elle est appliquée strncpy (), au lieu de créer de nouveaux tests pour cette spécification de test est implémentée en effectuant simplement une vérification supplémentaire sur chaque cas de test pour les autres exigences au lieu de créer de nouveaux tests pour celui-ci.
Gestion des fichiers de démarrage et des macros de type fonction
Le langage C complique la vie du testeur de plusieurs manières. C'est pourquoi toutes les fonctions de la bibliothèque standard C ne sont pas implémentées uniquement sous forme binaire précompilée. Beaucoup s'appuient également fortement sur les informations contenues dans les fichiers source de démarrage.
Ces fichiers de démarrage, qui définissent des éléments tels que les types, les variables globales et les macros, font partie de la bibliothèque au même titre que les fonctions (précompilées) de la bibliothèque. De nombreuses fonctions sont implémentées à la fois en tant que fonction réelle et en tant que macro, et pour augmenter leur vitesse et leur efficacité, il est courant d'utiliser leur implémentation en tant que macro. Les deux cas sont vérifiés par SuperGuard.
Contrairement aux binaires correspondants, les macros de type fonction ne sont pas précompilées. Ils sont compilés par le compilateur SDK avec le code source de l'application. Il est donc important que, avec les autres contenus des fichiers de démarrage, ils soient vérifiés pour les cas d'utilisation spécifiques d'une application critique pour la sécurité. Dans la bibliothèque C++, l'utilisation des macros est portée à un niveau encore plus élevé en utilisant des modèles de type génériques qui n'existent que dans l'en-tête.
Lorsque les tests basés sur les exigences sont conformes à la clause 26262 de la partie 8 de la norme ISO 12
Grâce à ces méthodologies de test basées sur les exigences, SuperGuard assure la disponibilité des éléments fondamentaux suivants inclus dans la norme ISO 26262 : Partie 8, Clause 12.4.1 pour considérer un élément logiciel validé :
12.4.1 a) la spécification du composant logiciel
La spécification des bibliothèques standard C et C++ est basée sur des normes ISO accessibles au public, et SuperGuard ajoute des exigences fonctionnelles claires aux descriptions de réponse qui contiennent ces normes.
12.4.1 b) preuve que le composant logiciel répond à ses exigences
En convertissant les exigences fonctionnelles extraites des descriptions de réponse des spécifications de la bibliothèque en spécifications de test et en conceptions de test, et en réunissant les tests résultants en un ensemble complet de tests exécutables, SuperGuard fournit la démonstration qu'une implémentation de la bibliothèque C Standard Library répond aux exigences extraites et ainsi la description de la réponse.
12.4.1 c) la preuve que le composant logiciel est adapté à l'usage auquel il est destiné
Lorsque SuperGuard est utilisé pour tester une implémentation de la bibliothèque standard C, il génère un rapport détaillé de l'état PASS/FAIL de tous les tests avec une traçabilité complète jusqu'aux exigences fonctionnelles extraites des descriptions de réponse de spécification.
SuperGuard répond également aux exigences de la norme ISO 26262 partie 8, clause 12, paragraphes 12.4.2.2, 12.4.2.3 et 12.4.2.4, qui sont liées à 12.4.1b ci-dessus. La clause 12.4.2.2 stipule que la vérification d'un composant logiciel peut être effectuée à l'aide d'une vérification basée sur les exigences et d'un package de test spécialisé, ce que fournit SuperGuard. Il stipule également que la vérification doit "couvrent à la fois les conditions de fonctionnement normales et la réponse en cas de défautet ne devrait pas "afficher des erreurs pouvant entraîner des violations des exigences de sécurité attribuées à ce composant logiciel." SuperGuard vérifie les exigences fonctionnelles pour tous les dysfonctionnements définis dans la norme de langage ISO C.
La clause 12.4.2.3 définit une exigence supplémentaire pour l'utilisation de composants logiciels dans les applications ASIL-D et stipule que la couverture structurelle doit être mesurée afin d'évaluer que les cas de test ont été terminés.
La Clause 12.4.2.4 stipule que le processus de vérification détaillé à la Clause 12 ne peut être appliqué qu'à une implémentation inchangée du Composant logiciel. Alors que certains développeurs remplacent les fonctions de bibliothèque par leurs propres implémentations spécialisées, ces modifications ne s'appliquent généralement qu'à quelques fonctions. Étant donné que la bibliothèque standard C est hautement modulaire et que pratiquement toutes les implémentations de fonctions sont indépendantes du reste de la bibliothèque, la plupart des fonctions de la bibliothèque peuvent toujours être vérifiées comme indiqué dans la partie 8, clause 12, permettant ainsi au développeur d'applications de se concentrer uniquement sur la validation. les fonctions qui ont été modifiées conformément aux dispositions de la partie 6.
Analyse de couverture de code
Tout au long de la création du package de test SuperGuard, une attention particulière a été accordée à la couverture du code afin qu'une implémentation open source mature et bien connue de la bibliothèque standard C réponde à l'exigence ASIL D de la clause 12.4.2.3. SuperGuard offre une couverture à 100 % pour de nombreuses fonctions de la bibliothèque, ainsi qu'une couverture MC/DC élevée. Les domaines où SuperGuard a une couverture moindre sont souvent ceux liés à la réponse définie par la mise en œuvre, pour lesquels aucune exigence ne peut être dérivée de la spécification du langage.
Bien que chaque implémentation de la bibliothèque soit différente, toutes devraient finalement gérer l'analyse de cas similaires. Cela signifie que la couverture de code élevée de SuperGuard bénéficie de la couverture de code pour toutes les implémentations de la bibliothèque standard C.
cas anormaux
SuperGuard peut gérer les cas anormaux de deux manières. Le premier est lié à la réponse définie à partir d'une entrée anormale ; Par exemple, lors de la saisie d'un nombre négatif dans la fonction sqrt() le résultat doit être la valeur NaN (en supposant l'arithmétique CEI 60559). Bien qu'il s'agisse d'un cas anormal, la réponse de la fonction est entièrement définie et peut être vérifiée comme n'importe quelle autre.
La seconde est liée aux exigences qui peuvent être vérifiées par le compilateur. Par exemple, si une fonction doit renvoyer un résultat de type vide, un test peut tenter d'utiliser la valeur fournie en s'attendant à ce qu'elle génère une erreur de compilation. Un test de ce type s'appelle un test X dans SuperGuard et le nom de fichier de ces tests commence par un x. La
X-Test PASS si le compilateur indique une erreur de compilation et FAIL si ce n'est pas le cas. Les X-Tests ne sont jamais exécutés.
Résumé et conclusions
Les applications critiques pour la sécurité exigent que les développeurs de logiciels fassent tout ce qui est en leur pouvoir pour s'assurer que leurs processus de développement, leurs chaînes d'outils et leur code d'application ne présentent aucun risque de blessure, de perte de vie, de perturbation des services essentiels ou de dommages à l'environnement. Lors de l'utilisation d'outils et de composants tiers et/ou commerciaux prêts à l'emploi (COTS), tels que des compilateurs et des bibliothèques standard, les développeurs ne doivent pas supposer que ces outils et composants sont exempts de bogues ou que leur prévalidation implique qu'ils le sont. . La validation n'est vraiment valide que si elle est effectuée dans le même environnement de développement et dans les mêmes conditions de cas d'utilisation que dans l'application.
Utilisant le même package de test inclus dans SuperTest, la solution de Solid Sands pour les tests et la vérification du compilateur, sa suite de qualification de sécurité SuperGuard C Library ajoute la traçabilité nécessaire pour lier les résultats des tests en fonction des exigences, méthode recommandée pour tester les exigences de sécurité fonctionnelles telles que ISO 26262, par rapport à la spécification de la bibliothèque standard C. Une traçabilité complète est obtenue en décomposant les spécifications fonctionnelles de la bibliothèque standard ISO C en exigences clairement définies, en développant des spécifications de test appropriées pour vérifier ces exigences et en les mettant en œuvre conformément aux recommandations de la norme ISO 26262. Cela permet également aux développeurs de logiciels pour effectuer ces tests dans le même environnement de développement dans les mêmes conditions de cas d'utilisation et sur le même matériel cible utilisé dans leur application, avec une couverture de code structurel proche de 100 % . En générant un rapport de validation complet spécialement adapté aux besoins des organisations certifiées ISO 26262, SuperGuard simplifie considérablement la démonstration de l'intégrité des composants de bibliothèque utilisés dans les applications critiques pour la sécurité.
