Optez pour une voie plus rapide et plus intelligente vers l'automatisation des tests C/C++ pilotée par l'IA. Découvrez comment >>
Livre blanc
Vous vous demandez ce que contient le livre blanc ? Commencez par la présentation ci-dessous.
Dans l'automatisation industrielle, les fonctions de sécurité sont de plus en plus souvent assurées par des systèmes électriques, électroniques et électroniques programmables complexes. Tester ces systèmes est essentiel, mais difficile en raison de leur complexité. La norme IEC 61508 fournit des recommandations pour réduire les risques de défaillance matérielle systématique et aléatoire à des niveaux acceptables.
Ce livre blanc détaille comment Parasoft aide les équipes de développement logiciel à répondre aux exigences SIL, en présentant le concept de SIL tel que défini par la norme IEC 61508, en décrivant la solution intégrée de Parasoft pour l'automatisation des meilleures pratiques et en montrant comment satisfaire aux exigences du processus de développement logiciel pour des niveaux SIL spécifiques.
Niveau d'intégrité de sécurité (SIL) — défini par Norme CEI 61508Le niveau d'intégrité de sécurité (SIL) est l'un des quatre niveaux (SIL1 à SIL4) correspondant à la probabilité cible de défaillances dangereuses d'une fonction de sécurité donnée. Chaque fonction de sécurité d'un système critique pour la sécurité doit se voir attribuer un niveau d'intégrité de sécurité approprié. Un système critique pour la sécurité électrique, électronique et physique (E/E/PE) met généralement en œuvre plusieurs fonctions de sécurité. Si les exigences d'intégrité de sécurité de ces fonctions diffèrent, et sauf en cas d'indépendance suffisante de leur mise en œuvre, les exigences applicables au niveau d'intégrité de sécurité le plus élevé s'appliquent à l'ensemble du système critique pour la sécurité électrique, électronique et physique (E/E/PE).
Selon la norme IEC 61508, le niveau d'intégrité de sécurité d'une fonction donnée est évalué soit en fonction de la probabilité moyenne de défaillance de sa fonction nominale sur demande (pour un mode de fonctionnement à faible demande), soit en fonction de la probabilité d'une défaillance dangereuse par heure (pour un mode de fonctionnement à forte demande ou continu).
La norme CEI 61508 spécifie les exigences pour atteindre chaque niveau d'intégrité de sécurité. Ces exigences sont plus rigoureuses aux niveaux d'intégrité de sécurité les plus élevés afin de réduire au minimum la probabilité de défaillances dangereuses.
Parasoft C/C++test est une solution intégrée C/C++test permet d'automatiser un large éventail de bonnes pratiques éprouvées pour améliorer la productivité des équipes de développement logiciel et la qualité des logiciels.
Cela offre aux équipes un moyen pratique de prévenir, de détecter et de corriger les erreurs afin de garantir le bon fonctionnement de leur code C et C++. Pour une résolution rapide, chaque problème détecté est priorisé selon un niveau de gravité configurable, automatiquement attribué au développeur ayant écrit le code concerné et intégré à son EDI avec des liens directs vers le code problématique et une description de la procédure de correction.
Pour le développement embarqué et multiplateforme, C/C++test peut être utilisé dans les flux d'analyse et de test de code basés sur l'hôte et sur la cible.
L'automatisation de Parasoft C/C++test accroît considérablement l'efficacité des tests de correction et de fiabilité du code, qu'il soit nouveau ou existant. C/C++test génère automatiquement des tests complets, incluant les pilotes et les cas de test pour chaque fonction, exclusivement en C ou C++. Ces tests, avec ou sans modifications, servent à la validation initiale du comportement fonctionnel du code. En exploitant les cas limites, ces cas de test générés automatiquement vérifient également la réponse des fonctions à des entrées inattendues, révélant ainsi d'éventuels problèmes de fiabilité.
Les rapports HTML, PDF et aux formats personnalisés de Parasoft C/C++test sont configurables via l'interface graphique ou un fichier d'options. Les rapports standard incluent un résumé des résultats d'analyse et de test (réussite/échec), la liste des fichiers analysés et un résumé de la couverture de code. Ils peuvent être personnalisés pour inclure la liste des analyses statiques actives, des résultats de test détaillés avec le statut de réussite/échec de chaque test, les paramètres des graphiques de tendance des indicateurs clés et le code source complet avec un code couleur pour tous les résultats de couverture.
Les résultats d'analyse de code et de tests, l'analyse de couverture et d'autres données de test C/C++ peuvent être envoyés à PAO Parasoft Ces données sont corrélées avec celles générées par des analyseurs tiers, le contrôle de version, le suivi des anomalies et d'autres composants d'infrastructure, puis traitées par DTP. Il en résulte des analyses intelligentes et exploitables qui offrent non seulement une visibilité sur les risques associés à l'application testée, mais aussi la traçabilité requise pour satisfaire aux exigences SIL.
Les tableaux suivants décrivent comment Parasoft C/C++test prend en charge les méthodes du cycle de vie du développement logiciel requises pour les fonctions de sécurité afin d'atteindre un niveau SIL donné. Veuillez noter que les informations présentées ici visent à introduire brièvement l'utilisation de C/C++test dans le processus de vérification et de test lié au SIL. Veuillez vous référer à la norme et consulter des experts en sécurité fonctionnelle pour toute clarification des exigences définies par la norme IEC 61508. Si vous avez des questions supplémentaires concernant l'utilisation de C/C++test dans le processus de certification IEC 61508, veuillez contacter votre représentant Parasoft.
Les marqueurs suivants sont utilisés dans les tableaux présentés ci-dessous pour indiquer :
Les techniques et mesures définies dans les annexes A et B de la norme IEC 61508-3 édition 2.0 2010, qui sont satisfaites par la fonctionnalité C/C++test, ont été répertoriées dans les tableaux ci-dessous.
| Fonctionnalités de test C/C++ | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|
| Normes de conception et de codage | ||||
| Utilisation d'une norme de codage pour réduire la probabilité d'erreurs (Tableau B.1 : 1) | - | R | HR | HR |
| Aucun objet dynamique (Tableau B.1 : 2) | R | HR | HR | HR |
| Aucune variable dynamique (Tableau B.1 : 3a) | - | R | HR | HR |
| Vérification en ligne de l'installation des variables dynamiques (Tableau B.1 : 3b) | - | R | HR | HR |
| Utilisation limitée des interruptions (Tableau B.1 : 4) | R | R | HR | HR |
| Utilisation limitée des pointeurs (Tableau B.1 : 5) | - | R | HR | HR |
| Utilisation limitée de la récursivité (Tableau B.1 : 6) | - | R | HR | HR |
| Absence de flux de contrôle non structuré dans les programmes écrits dans des langages de haut niveau (Tableau B.1 : 7). | R | HR | HR | HR |
| Aucune conversion automatique de type (Tableau B.1 : 8) | R | HR | HR | HR |
| Analyse et essais dynamiques | ||||
| Exécution des cas de test à partir de l'analyse des valeurs limites (Tableau B.2 : 1) | R | HR | HR | HR |
| Exécution des cas de test à partir de la prédiction des erreurs (Tableau B.2 : 2) | R | R | R | R |
| Exécution des cas de test à partir de l'amorçage des erreurs (Tableau B.2 : 3) | - | R | R | R |
| Classes d’équivalence et tests de partitionnement des entrées (Tableau B.2 : 6) | R | R | R | HR |
| Couverture des essais structurels (points d'entrée) 100 % (Tableau B.2 : 7a) | HR | HR | HR | HR |
| Couverture des essais structurels (déclarations) 100 % (Tableau B.2 : 7b) | R | HR | HR | HR |
| Couverture des essais structurels (branches) 100 % (Tableau B.2 : 7c) | R | R | HR | HR |
| Couverture des essais structuraux (conditions, MC/DC) 100 % (Tableau B.2 : 7d) | R | R | R | HR |
| Tests fonctionnels et tests de boîte noire | ||||
| Classes d’équivalence et tests de partitionnement des entrées, y compris l’analyse des valeurs limites (Tableau B.3 : 4) | R | HR | HR | HR |
| Test de performance | ||||
| Essais d’avalanche/de contrainte (Tableau B.6 : 1) | R | R | HR | HR |
| Analyse statique | ||||
| Analyse des valeurs limites (Tableau B.8 : 1) | R | R | HR | HR |
| Listes de contrôle (Tableau B.8 : 2) | R | R | R | R |
| Analyse du flux de contrôle (Tableau B.8 : 3) | R | HR | HR | HR |
| Analyse des flux de données (Tableau B.8 : 4) | R | HR | HR | HR |
| Deviner par erreur (Tableau B.8 : 5) | R | R | R | R |
| Inspections formelles, y compris des critères spécifiques (Tableau B.8 : 6a) | R | R | HR | HR |
| Procédure pas à pas (logiciel) (Tableau B.8 : 6b) | R | R | R | R |
| Exécution symbolique (Tableau B.8 : 7) | - | - | R | R |
| Revue de conception (Tableau B.8 : 8) | HR | HR | HR | HR |
| Analyse statique du comportement des erreurs d'exécution (Tableau B.8 : 9) | R | R | R | HR |
| Approche modulaire | ||||
| Limite de taille des modules logiciels (Tableau B.9 : 1) | HR | HR | HR | HR |
| Contrôle de la complexité logicielle (Tableau B.9 : 2) | R | R | HR | HR |
| Fonctionnalités de test C/C++ | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|
| Conception d'architecture logicielle | ||||
| Détection des défauts (Tableau A.2 : 1) | - | R | HR | HR |
| Diverses techniques de surveillance (avec séparation entre l'ordinateur de surveillance et l'ordinateur surveillé) (Tableau A.2 : 3c) | - | R | R | HR |
| Redondance diversifiée, mettant en œuvre la même spécification d'exigences de sécurité logicielle (Tableau A.2 : 3e) | - | - | - | R |
| Utilisation d’éléments logiciels fiables/vérifiés (le cas échéant) (Tableau A.2 : 8) | R | HR | HR | HR |
| Outils de support et langage de programmation | ||||
| Langage de programmation approprié (Tableau A.3 : 1) | HR | HR | HR | HR |
| Langage de programmation fortement typé (Tableau A.3 : 2) | HR | HR | HR | HR |
| Sous-ensemble de langues (Tableau A.3 : 3) | - | - | HR | HR |
| Outils certifiés et traducteurs certifiés (Tableau A.3 : 4a) | R | HR | HR | HR |
| Outils et traducteurs : confiance accrue grâce à l’utilisation (Tableau A.3 : 4b) | HR | HR | HR | HR |
| La conception de détail | ||||
| Méthodes structurées (Tableau A.4 : 1a) | HR | HR | HR | HR |
| Méthodes formelles de conception et d'amélioration (Tableau A.4 : 1c) | - | R | R | HR |
| Programmation défensive (Tableau A.4 : 3) | - | R | HR | HR |
| Approche modulaire (Tableau A.4 : 4) | HR | HR | HR | HR |
| Normes de conception et de codage (Tableau A.4 : 5) | R | HR | HR | HR |
| Programmation structurée (Tableau A.4 : 6) | HR | HR | HR | HR |
| Utilisation d’éléments logiciels fiables/vérifiés (Tableau A.4 : 7) | R | HR | HR | HR |
| Traçabilité ascendante entre la spécification des exigences de sécurité du logiciel et la conception du logiciel (Tableau A.4 : 8) | R | R | HR | HR |
| Tests et intégration de modules logiciels | ||||
| Analyse et essais dynamiques (Tableau A.5 : 2), (Tableau A.9 : 4) | R | HR | HR | HR |
| Enregistrement et analyse des données (Tableau A.5 : 3) | HR | HR | HR | HR |
| Tests fonctionnels et tests boîte noire (Tableau A.5 : 4) (Tableau A.7 : 4) | HR | HR | HR | HR |
| Tests d'interface (Tableau A.5 : 7) | R | R | HR | HR |
| Outils de gestion et d'automatisation des tests (Tableau A.5 : 8) | R | HR | HR | HR |
| Traçabilité ascendante entre la spécification de conception du logiciel et les spécifications des tests de module et d'intégration (Tableau A.5 : 9) | R | R | HR | HR |
| Vérification formelle (Tableau A.5 : 10) | - | - | R | R |
| Modification | ||||
| Revérifier le module logiciel modifié (Tableau A.8 : 2) | HR | HR | HR | HR |
| Revérifier le module logiciel concerné (Tableau A.8 : 3) | R | HR | HR | HR |
| Revalider le système complet (Tableau A.8 : 3) | - | R | HR | HR |
| Validation de la régression | R | HR | HR | HR |
| Vérification logicielle | ||||
| Preuve formelle | - | R | R | HR |
| Analyse statique | R | HR | HR | HR |
| Analyse et essais dynamiques (Tableau A.5 : 2), (Tableau A.9 : 4) | R | HR | HR | HR |
| Traçabilité ascendante entre les spécifications de conception du logiciel et le plan de vérification du logiciel (y compris la vérification des données) | R | R | HR | HR |
| Traçabilité ascendante entre le plan de vérification du logiciel (y compris la vérification des données) et les spécifications de conception du logiciel | R | R | HR | HR |
| Fonctionnalités de test C/C++ | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|
| Hardware et Software | ||||
| Tests fonctionnels et tests de boîte noire (Tableau A.6 : 1) | HR | HR | HR | HR |
| Traçabilité ascendante entre les exigences de conception du système et du logiciel pour l'intégration matérielle/logicielle et la spécification de test d'intégration matérielle/logicielle (Tableau A.6 : 3) | R | R | HR | HR |
| Fonctionnalités de test C/C++ | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|
| Tableau de bord de reporting et d'analyse de Parasoft DTP | ||||
| Traçabilité ascendante entre les exigences de sécurité du système et les exigences de sécurité du logiciel (Tableau A.1:2) | R | R | HR | HR |
| Traçabilité ascendante entre les exigences de sécurité et les besoins de sécurité perçus (Tableau A.1:3) | R | R | HR | HR |
| Outils de spécification assistés par ordinateur pour soutenir les techniques/mesures appropriées ci-dessus (Tableau A.1:4) | R | R | HR | HR |
Parasoft C/C++test aide les équipes de développement logiciel à respecter les exigences de sécurité fonctionnelle de la norme IEC 61508. Il propose une large gamme de types d'analyses, notamment : analyse de conformité aux normes de codageL'analyse des flux de données et de contrôle, les tests unitaires, la surveillance des applications, les composants de flux de travail et le processus de revue de code par les pairs, associés aux rapports de test configurables contenant un haut niveau de détails, facilitent considérablement le travail requis pour le processus de vérification des logiciels.
Prêt à plonger plus profondément ?
