Nous sommes nominés pour le prix Embedded Award 2026 dans la catégorie Outils et nous serions ravis de recevoir votre soutien ! Votez pour C/C++test CT >>
Livre blanc
Vous souhaitez un aperçu rapide avant de vous lancer ? Commencez ci-dessous.
Le développement de logiciels pour dispositifs médicaux est confronté à une complexité croissante, notamment en raison des contraintes réglementaires liées aux tests de couverture de code. La directive 510(k) de la FDA impose des indicateurs de couverture de code pour les dispositifs de classe II et III, bien que les exigences varient selon la classification.
Les solutions de test automatisées comme Parasoft C / C ++test et Parasoft DTP mesurer automatiquement la couverture du code Ces outils s'intègrent aux processus modernes du cycle de vie du développement logiciel (SDLC), réduisant ainsi les risques et renforçant la confiance dans la sécurité des dispositifs. Ils aident les équipes à respecter les recommandations de la FDA et à simplifier la préparation de la documentation réglementaire, l'Europe s'appuyant de plus en plus sur les normes de la FDA américaine à mesure que le développement des produits médicaux se mondialise.
La plupart d'entre nous avons bénéficié de dispositifs médicaux : des tensiomètres classiques aux oxymètres de pouls bon marché disponibles en pharmacie, en passant par les scanners CT utilisés par les médecins et les appareils d'IRM. Tous sont soumis à la réglementation du gouvernement américain, via la FDA.
La classification d'un dispositif dépend de son usage prévu et de ses indications. Elle repose également sur une évaluation des risques : le risque que le dispositif présente pour le patient et/ou l'utilisateur est un facteur déterminant dans sa classification. La classe I regroupe les dispositifs présentant le risque le plus faible, tandis que la classe III comprend ceux présentant le risque le plus élevé. Comme indiqué précédemment, toutes les classes de dispositifs sont soumises aux Contrôles généraux. Ces Contrôles généraux constituent les exigences minimales de la loi fédérale américaine sur les aliments, les médicaments et les cosmétiques (FD&C Act) et s'appliquent à tous les dispositifs médicaux, de classes I, II et III. L'équivalence des dispositifs médicaux est établie dans le cadre de la notification préalable à la commercialisation 510(k).
La plupart des dispositifs médicaux nécessitent une notification préalable à la commercialisation (510(k)) auprès de la FDA ou un simple enregistrement s'ils en sont exemptés. Cependant, si un dispositif est implantable ou présente un risque potentiellement inacceptable de maladie ou de blessure, il s'agit probablement d'un dispositif de classe III nécessitant une autorisation de mise sur le marché (AMM). Les nouveaux dispositifs innovants sans précédent (« dispositifs de référence ») sont automatiquement classés en classe III, mais peuvent être éligibles à la procédure De Novo au lieu d'une AMM. Seuls 10 % des dispositifs réglementés par la FDA sont de classe III, mais ce sont ceux qui présentent le plus de risques.
La classification utilisée par la FDA est largement basée sur le risque. Tous les appareils électriques sont conformes à la norme CEI 60601 en matière de sécurité électrique, mais les dispositifs médicaux contiennent de plus en plus de logiciels importants.
La norme logicielle la plus associée au processus de la FDA est IEC 62304. Ce document décrit le cycle de vie du développement logiciel pour les dispositifs médicaux, en détaillant les activités et les tâches nécessaires à une conception et une maintenance sûres. Le logiciel peut être intégré au dispositif ou constituer lui-même un dispositif médical.
La norme IEC 62304 spécifie les exigences relatives aux logiciels en tant que sous-ensemble des exigences relatives à un système médical électrique programmable (PEMS). Les logiciels font clairement partie du processus de vérification de la FDA, depuis la spécification des exigences logicielles jusqu'à l'intégration des éléments logiciels dans un système logiciel.
Personne ne serait satisfait si des dispositifs ou équipements médicaux causaient des douleurs, des souffrances ou des situations mettant la vie en danger. Or, cela arrive parfois, malgré tous les efforts des concepteurs, ingénieurs, programmeurs, chefs de produit, responsables de la conformité et de tous les autres intervenants dans la conception de dispositifs complexes.
Les classifications ont évolué au fil des ans : la télésanté, autrefois classée en catégorie II, est désormais reléguée en catégorie I dans de nombreux cas. Parallèlement, les recommandations en matière de sécurité ont été renforcées en raison des menaces de prise de contrôle par des botnets via l’Internet des objets.
Il existe au moins deux raisons de vouloir réduire les risques :
Dans les dispositifs médicaux modernes, les logiciels prennent une place de plus en plus importante dans les fonctionnalités, de la connexion internet au stockage et à l'analyse des données. Le développement des cas d'utilisation matériels doit désormais intégrer les cas d'utilisation logiciels, et bien souvent, le nombre de combinaisons possibles devient considérable.
Comment pouvons-nous être sûrs de disposer de cas de test pour toutes les situations ? Mesurer la proportion de code logiciel réellement testée est le rôle des outils de couverture de code. Les outils manuels d'analyse des modes de défaillance et de leurs effets (AMDE) ont leurs limites. Un logiciel non testé est un logiciel non fiable. Cela pourrait potentiellement engendrer des dispositifs médicaux dangereux et non sécurisés.
Le processus FDA 510(k) exige la mise en œuvre de la norme IEC 62304, qui impose les processus suivants : développement logiciel, maintenance logicielle, résolution des problèmes, gestion des risques et gestion de la configuration.
Face à une complexité toujours croissante et à l'apparition de nouveaux langages et technologies informatiques, l'automatisation maximale du processus de développement et de test est essentielle pour améliorer la qualité.
L'un des facteurs clés est le test. La difficulté réside dans la rédaction de scénarios de test qui couvrent non seulement les cas courants, mais aussi les cas limites. Comme mentionné précédemment, la FDA considère la vérification comme essentielle.
Les règles d'autorisation de mise sur le marché de classe II et de classe III de la FDA sont complexes, car cette dernière n'a pas mis à jour ses directives depuis plusieurs années. Elles n'imposent pas le cycle de vie du développement logiciel proprement dit, mais elles exigent une gestion des risques et se réfèrent à une norme CEI à cet effet.
On oublie parfois de comprendre le rôle que peuvent jouer les outils d'analyse de couverture de code. Cette analyse facilite la production de données de test, l'automatisation des analyses et la génération de certains rapports sur l'état du dispositif médical testé. Elle permet également de garantir à la FDA, ainsi qu'à vous-même, que tous les chemins critiques et les cas limites ont été testés.
On pourrait s'attendre à ce que la FDA publie des règles claires concernant les types d'analyses et, surtout, la couverture de code requis pour les dispositifs de classe II et III, mais malheureusement, ce n'est pas le cas. Elle propose un document assez ancien intitulé « Principes généraux de validation des logiciels », qui décrit les principes de validation des logiciels pour dispositifs médicaux, ainsi que des logiciels utilisés pour concevoir, développer ou fabriquer ces dispositifs. Si vous fabriquez un dispositif ou un équipement médical, vous devez respecter les exigences et les directives de ce document. Les produits classés en classe II ou III doivent également faire l'objet de contrôles rigoureux en matière de conception, de développement, de tests, de gestion des modifications et d'analyse des risques.
Si votre logiciel est utilisé (intégré à) un produit, il doit être validé. Si le logiciel constitue le produit dans son intégralité, vous devez bien entendu démontrer, dans votre dossier 510(k), comment il a été validé. De façon surprenante, les logiciels utilisés pour la création du logiciel doivent également être validés ; c’est pourquoi il est important de choisir des chaînes d’outils de compilation et des outils associés certifiés pour le développement de systèmes critiques. Les produits Parasoft C/C++test et C/C++test CT sont certifiés TÜV SÜD.
Les meilleures pratiques, telles qu'expliquées par la FDA, comprennent :
L'amélioration de la fiabilité des dispositifs médicaux présente non seulement des avantages évidents, mais aussi d'autres atouts. Par exemple, lors du développement, l'outil de couverture de code permet de repérer les portions de code introduites mais non testées. Le suivi des modifications apportées au code source au fil du temps améliore la visibilité du produit.
Cela renforcera non seulement la confiance de la FDA dans votre produit, augmentant ainsi les chances d'obtenir une autorisation de mise sur le marché ou une approbation, mais cela réduira également la charge de travail liée au développement, à la qualité, à la conformité et aux autres fonctions. C'est la bonne chose à faire : une démarche qui vise à améliorer l'efficacité et à réduire les coûts.
Il n'y a pas de substitut pour adoption de solutions de test logiciel automatisées qui ont déjà été utilisés dans des environnements critiques pour la sécurité. C'est là qu'intervient Parasoft. Les logiciels embarqués d'un grand nombre de dispositifs médicaux, d'équipements médicaux et d'autres applications exigeant une sécurité maximale ont été testés par Parasoft C/C++test. Solution de test entièrement intégrée pour le développement de logiciels C/C++ Les logiciels Parasoft DTP sont certifiés par TÜV SÜD, ce qui garantit leur conformité à la norme IEC 62304 pour les applications hôtes et les applications cibles embarquées. Ils répondent ainsi aux exigences des réglementations nationales, régionales et internationales en matière de sécurité fonctionnelle.
En mettant en place une solution performante de tests automatisés et de reporting analytique, les développeurs de logiciels en charge des tests (SDET) n'ont plus besoin de recourir à des méthodes manuelles fastidieuses et sources d'erreurs. Ils peuvent ainsi se concentrer sur leurs activités de développement principales et approfondir leurs tests afin de fournir des logiciels de haute qualité. Conforme aux exigences de la FDA et facile d'utilisation, une solution comme C/C++test utilise des tests statiques et dynamiques, tandis que DTP assure le suivi de la conformité grâce à un tableau de bord centralisé de reporting et d'analyse.
Automatisation de la génération des cas de tests unitaires C/C++test est idéal pour les tests de dispositifs médicaux dans le cadre de méthodologies agiles comme Scrum et DevOps, car l'une des exigences est que les ingénieurs de développement rédigent des tests unitaires. Lors du processus de compilation, avant l'intégration du code, C/C++test exécute automatiquement les tests unitaires afin de garantir un code exempt de régressions et autres bogues. De plus, grâce à un ensemble d'options configurables, Parasoft collecte les indicateurs de couverture de code requis.
Les équipes peuvent également exécuter les solutions Parasoft depuis un environnement de développement intégré (IDE) ainsi que depuis la ligne de commande ou le shell. Consultez la documentation complète. Liste des chaînes d'outils prises en charge ici.
Test C/C++ : couverture de code surlignée en vert et options de couverture de code.
Les équipes peuvent consulter des analyses exploitables dans n'importe quel navigateur. DTP centralise les résultats des tests dans des tableaux de bord intelligents et des rapports détaillés.
Tableau de bord complet de la couverture de code de Parasoft DTP.
Les outils de couverture de code comme ceux de Parasoft peuvent être intégrés à un pipeline d'intégration continue/déploiement continu, permettant ainsi à la solution de prendre en charge la majeure partie du travail. Les dispositifs médicaux étant de plus en plus ciblés par les attaques, la pression exercée sur les équipes de développement et d'ingénierie qui tentent d'adopter les pratiques DevOps et doivent désormais également prendre en compte le DevSecOps est considérable.
Heureusement, la capacité de Parasoft à fonctionner dans un grand nombre d'IDE et/ou à partir de la ligne de commande signifie que l'intégration est déjà assurée et ne nécessite que peu ou pas de configuration.
Les solutions de Parasoft permettent de tester les applications exécutées sur les systèmes suivants :
Si votre dispositif médical est de classe III selon la FDA, bien que cela exige davantage d'efforts, il est recommandé de le tester sur le matériel cible, car les normes y sont beaucoup plus strictes. Un dispositif de classe II peut être considéré comme acceptable pour une utilisation sur le système hôte.
Voici cinq étapes pour aborder la mise en œuvre.
Prêt à plonger plus profondément ?
