Conformité à IEC 62304 avec la suite d’outils LDRA®

Éléments principaux de la suite d’outils LDRA

La clause 5 de l’IEC 62304 détaille le processus de développement de logiciel du produit. Elle aborde spécifiquement:

• 5.1 Planification de développement de logiciel
• 5.2 Analyse des exigences de logiciel
• 5.3 Conception architecturale de logiciel
• 5.4 Conception détaillée de logiciel
• 5.5 Implémentation et vérification d’unité de logiciel
• 5.6 Intégration et test d’intégration de logiciel
• 5.7 Test de système de logiciel
• 5.8 Diffusion du logiciel

La clause 6 de l’IEC 62304 détaille le processus de maintenance de logiciel comme suit:

• 6.1 Établir le plan de maintenance de logiciel
• 6.2 Analyse des problèmes et modification
• 6.3 Implémentation de modification

En outre, la clause 7 de l’IEC 62304 détaille le processus de gestion des risques liés au logiciel comme suit:

• 7.1 Analyse de logiciel contribuant aux situations dangereuses
• 7.2 Mesures de CONTRÔLE DES RISQUES
• Mesures de VÉRIFICATION du CONTRÔLE DES RISQUES
• 7.4 GESTIN DES RISQUES des changements de logiciel

Au fur et à mesure que ces thèmes sont développés dans cette partie de la norme, il devient clair que quel que soit la Classe (A, B et C) de l’appareil en question, la suite d’outils LDRA est en mesure de vous aider à n'importe quelle étape du processus.

Le diagramme V suivant illustre comment la suite d’outils LDRA peut être bénéfique au processus de développement de logiciel, décrit par l’IEC 62304:

5.1 Planification de développement de logiciel

Cette ACTIVITÉ exige la planification de la vérification de logiciel, ici TBreq /TBmanager vous aide par le biais de TBmanager qui permet de générer un plan de vérification de logiciel pour les exigences de logiciel ; le plan de vérification de logiciel inclut les tâches à réaliser pendant la vérification du logiciel et les attribuer à un utilisateur spécifique. Pour aider à réaliser le processus de planification de la vérification, la suite d’outils fournit divers planificateurs, par exemple le planificateur de test élémentaire LCSAJ.

5.2 Analyse des exigences de logiciel

Cette activité exige la vérification des exigences de logiciel pour le logiciel d’appareil médical. Toutes les exigences de logiciel doivent être identifiées de manière à pouvoir démontrer la traçabilité entre l’exigence et le test de système de logiciel.

Ici TBreq/TBmanager vous aide grâce à ses fonctions de traçabilité et d’ingénierie des exigences qui accompagnent la création des exigences et de la traçabilité entre les documents de conception à diverses phases de conception et de développement au cours du projet.

TBreq/TBmanager gère automatiquement tout changement dans les documents associés ou code logiciel, afin que tout test devant être réexaminés en conséquence de ces changements, est automatiquement mis en évidence et peut être traité en fonction.

Cette traçabilité est aussi importante entre les spécifications de niveau plus élevé, qu’entre les spécifications et le code source. La suite d’outils LDRA indiquera les révisions sur un document, qui mettent en évidence le besoin d’en réexaminer d’autres.

5.4 Conception détaillée de logiciel

La norme mentionne le fait que la conception doit être vérifiée. Les artéfacts graphiques générés par la suite d’outils LDRA conviennent parfaitement à l’examen de la conception implémentée par rapport aux artéfacts de conception par le biais de revues de projet ou d'inspections. Elle permettra également de trouver les anomalies dans la conception. Ce support nécessite que l’architecture de logiciel soit prototypée dans un langage de programmation (Java, C, C++ or Ada).

LDRA Testbed peut réaliser l’examen de la conception et générer des rapports de flux de données, qui fournissent des informations sur la spécification de l’interface, les anomalies variables et les informations d'appel de procédure.

En fonction de l'examen de la conception, il est possible de réaliser le test de l'unité/d'intégration pour contrôler la fonctionnalité ou procéder à l’analyse de couverture structurelle.

La suite d’outils LDRA génère des artéfacts graphiques tels que des graphes d’appel, diagrammes de flux, diagrammes à barres et diagrammes de Kiviat, qui sont adaptés à l’examen de la conception par inspection visuelle.

5.5 Implémentation et vérification d’unité de logiciel

Cette activité exige l’utilisation de normes de codage lors de l’implémentation des unités de logiciel. Le code pour chaque unité doit être vérifié pour veiller à ce qu’il fonctionne comme spécifié par la conception détaillée et qu’il soit conforme aux normes de codage spécifiées.

LDRA Testbed et TBvision possèdent tous deux ces capacités puissantes de vérification des normes, y compris la conformité aux normes industrielles de pointe MISRA C et C++, HIS, CERT C et plus.

La capacité d’analyse statique peut appliquer près de 100 règles de codage spéciales, basées sur des méthodes officielles, qui détectent le type de défaillances survenant principalement lors de l’intégration de logiciel.

La norme exige également l’établissement de stratégies, méthodes et procédures pour vérifier chaque unité de logiciel. Lorsque la vérification est faite par des tests, l’exactitude des procédures de test sera évaluée.  Les critères d’acception incluront les flux de données et de contrôle, la détection de dépassement de mémoire et la vérification de toutes les conditions de limite de logiciel.

TBrun fournit une interface graphique pour les spécifications de test de l’unité, permettant de créer des tests conformément aux spécifications définies, valeurs de condition de limite et pour présenter une liste de tous les tests élémentaires définis, avec le statut de réussite/échec pertinent. Il fournit une présentation visuelle des graphiques de flux de contrôle.

La création automatique du logiciel de test, des fonctions de bouchon et même des vecteurs de test (si souhaité) signifie que l’exécution du test de l’unité se transforme en un processus rapide et facile, nécessitant un minimum de connaissances spécialisées.

L’Analyseur de flux des données statiques documente les informations telles que les informations d’appel de procédure, les anomalies de flux de données, l’analyse de l’interface de procédure et les violations des normes de flux de données. La Couverture de flux de données dynamique produit une liste de référence croisée des variables, qui indique où ceux-ci sont utilisés dans le/les fichiers source ou dans le système testé, ainsi que leur type. Le module établit la correspondance des informations de couverture avec chaque entrée de variable dans le tableau pour les ensembles de données actuels et combinés.

5.6 Intégration de logiciel et test d’intégration et 5.7 Test de système de logiciel

Le test d’intégration de logiciel se concentre sur le transfert des données et du contrôle sur les interfaces internes et externes d’un élément logiciel. Le test d’intégration démontre le comportement du programme aux limites de ses domaines d’entrée et de sortie et confirme les réponses du programme en fonction d'entrée invalides, prévues et spéciales.

Le test de système de logiciel démontre que la fonctionnalité spécifiée existe. Ce test vérifie la fonctionnalité et la performance du programme tel qu’il a été construit, relativement aux exigences pour le logiciel.

Les instructions telles que la couverture structurelle, branche, état, procédures/appel de fonction, LCSAJ et couverture de flux de données sont fournies par les fonctionnalités de test d'unité et de test de système dans la suite d'outils LDRA. Ces ensembles peuvent également fonctionner en tandem, afin que (par exemple) la couverture puisse être générée pour la majeure partie du code source par le biais d'un test de système dynamique et que ceci puisse être complété à l’aide de tests d’unité pour exercer le code défensif et d’autres aspects. TBrun génère un Rapport de réussite/échec du test contenant une description détaillée du dernier test élémentaire dans la séquence avant la mise en mémoire. Le fichier, l’unité et les valeurs des entrées et des sorties seront détaillées pour les tests élémentaires. Il documente également les résultats Réels et Prévus et fournit une analyse de régression basée sur les critères d’échec/réussite entre ces résultats.

La suite d’outils LDRA maintient l'ensemble de la séquence de test et des tests préliminaires, afin qu’ils puissent être répétés ; l’outil réalise automatiquement l’analyse de régression et génère un rapport de régression qui indique les critères d'échec/réussite pour les tests de régression réalisés.

La clause 6 d’IEC 62304 détaille le processus de maintenance de logiciel

Étant donné que de nombreux incidents sur le terrain sont liés à l’entretien ou à la maintenance des systèmes d’appareil médicaux, y compris des mise à jour ou mises à niveau de logiciel inadéquates, le processus de maintenance de logiciel est considéré comme étant aussi important que le processus de développement de logiciel. Ceci est dû au fait qu’un pourcentage élevé de défaillances des logiciels d’appareil médical sont introduits après la diffusion du produit (c.-à-d. pendant la maintenance du logiciel). Le processus de maintenance de logiciel est très similaire au processus de développement de logiciel.

Les exigences spécifiques pour le Plan de maintenance de logiciel peuvent être créées dans TBmanager Les exigences déclarées peuvent ensuite être utilisées pour générer automatiquement un document avec un format spécifié en utilisant les capacités de génération de rapport de TBmanager.

La suite d’outils LDRA mémorise un grand nombre des actifs (exigences, code, tests, etc.) produit au cours du processus de développement de logiciel et les rend disponibles à la modification. En outre, la suite d’outils LDRA procure des fonctionnalités de test de régression étendues pour assurer la cohérence avec les exigences.

La clause 7 d’IEC 62304 détaille le processus d’analyse des risques du logiciel

Cette norme nécessite l’utilisation d’un PROCESSUS DE GESTION DES RISQUES conforme à ISO 14971. La GESTION DES RISQUES, telle que définie dans ISO 14971 traite spécifiquement d’un cadre pour la gestion efficace des RISQUES associés à l’utilisation des APPAREILS MÉDICAUX.

Comme indiqué dans la Figure 4, la suite d’outils LDRA adopte une approche compréhensive et systématique à la gestion et à l'évaluation des risques en incorporant des objectifs de gestion des risques en un modèle des exigences vérifiables. Dans ce modèle, les exigences réglementaires peuvent être incorporées directement dans la spécification des exigences et les activités d’atténuation des risques peuvent être spécifiées.

Les activités d’atténuation des risques peuvent être définies et catégorisées pour répondre à des critères spécifiques. Comme indiqué dans la Figure 5, les techniques de gestion du risque définie par l’utilisateur peuvent être employées dans le Modèle de gestion des risques.

Les capacités d’analyse et de test de la suite d’outils LDRA peuvent être utilisées pour vérifier les mesures de contrôle des risques implémentées dans le logiciel. Les fonctions de traçabilité automatisées de TBmanager permettront de documenter et d’assurer la traçabilité des dangers liés au logiciel.

La suite d’outils LDRA et TBmanager peuvent aider à déterminer l’impact du logiciel modifié par le biais de l’introduction potentielle des défaillances dangereuses. Cet impact peut être déterminé par l’analyse d’examen de la conception dans LDRA Testbed et l’application des règles de codage essentielles à la sécurité également dans LDRA Testbed. La suite d’outils LDRA aidera également à gérer l’impact global des changements proposés sur les mesures de gestion des risques existantes. Ceci est accompli en maintenant les matrices de traçabilité multiples parmi les actifs suivants (comme illustré dans la Figure 4, modèle de gestion des risques ci-dessus).

• Exigences utilisateur (URS)
• Spécifications fonctionnelles (FS)
• Spécifications de conception (DS)
• Matrice de traçabilité URS-FS et URS-DS
• Facteurs de risque associés à FS ou RS (analyse des risques ascendante)
• Facteurs de risque de système (analyse des risques descendante)
• Catalogue de test IQ
• Catalogue de test OQ
• PQ catalogue de test PQ
• Traçabilité d’OQ/PQ par rapport aux tests URS/FS.

Informations supplémentaires

Pour d’autres informations sur la conformité à IEC 62304 et la disponibilité, veuillez remplir le formulaire de réponse LDRA ou envoyez un e-mail à info@ldra.com.