Découvrez comment la solution Parasoft Continuous Quality permet de contrôler et de gérer les environnements de test pour fournir des logiciels de haute qualité en toute confiance. Inscrivez-vous pour la démo >>

BLOG

5 conseils pour l'analyse statique et dynamique dans les logiciels de dispositifs médicaux

5 conseils pour l'analyse statique et dynamique dans les logiciels de dispositifs médicaux Temps de lecture : 6 minutes

Alors que la cybersécurité devient un axe fort de la FDA avec des exigences spécifiques autour de l'analyse de code statique et dynamique, les ingénieurs doivent automatiser ces pratiques et les intégrer dans les flux de travail de développement existants. Dans ce blog invité, Andrey Shastin d'Auriga partage quelques astuces du métier.

Chez Auriga, nous réalisons de nombreux projets de développement de logiciels pour les dispositifs médicaux depuis près de 2 décennies - des lecteurs de glycémie relativement simples aux systèmes plus complexes tels que les pompes à perfusion, les moniteurs patient et les unités de ventilation pulmonaire. La mise en œuvre de pratiques d'analyse de code statique et dynamique et leur déploiement sur ces projets font partie intégrante de notre processus, et ici, je vais discuter analyse de code statique vs dynamique et partager quelques conseils tirés de notre expérience pratique et de nos défis.

Analyse de code statique

L'analyse statique est une pratique consistant à vérifier automatiquement la conformité aux directives de codage bien connues (c'est-à-dire MISRA, CERT, AUTOSAR, JSF) et à détecter des bogues potentiels tels que le déréférencement de pointeur nul, la division par zéro et les dépassements de tampon. Les outils modernes d'analyse statique complètent également la pratique traditionnelle de révision de code en réduisant l'effort manuel d'au moins 30%.

Dans la plupart des cas, la première exécution d'un outil d'analyse statique par rapport à votre code actuel montrera des milliers d'erreurs (nous en avons même rencontré plus de 20,000 lors de la première exécution), ce qui peut bien sûr être incroyablement écrasant, car il semble que cela prendrait ans pour les réparer tous. Voici donc quelques conseils de nos experts pour faire face au problème.

Astuce n ° 1: le compilateur est votre ami

Les équipes de développement disciplinées compilent généralement avec –Wall et –Werror (dans GCC), ou / Wall / WX (dans Visual Studio), ou en utilisant des options similaires dans d'autres compilateurs. La correction des avertissements du compilateur est un moyen simple et peu coûteux de se préparer à l'exécution de l'analyse statique. Nous avons vu que revoir la sortie de votre compilateur en mode «paranoïaque» peut réduire le volume global des violations d'analyse statique.

Bien qu'ayant corrigé tous les avertissements du compilateur est une bonne chose, il existe de nombreux projets où l'utilisation d'un seul compilateur ne sera pas suffisante et même une option acceptable pour des raisons de conformité.

Après avoir vidé votre compilateur à sec, utilisez des outils d'analyse statique destinés à approfondir le code et à vous donner beaucoup plus d'indices.

Astuce n ° 2: Adoptez l'analyse statique au début du processus

Si vous développez actuellement un logiciel de dispositif médical, vous devez être prêt à aborder la question d'une pratique d'analyse de code statique automatisée. Il est presque garanti que l'analyse statique fera l'objet d'une discussion lors d'un audit interne / externe ou même d'une soumission préalable à la mise sur le marché.

La clé est de déployer l'outil de manière à ce que le développement ne perde pas la vitesse tout en se concentrant sur l'amélioration de la qualité et sans traiter les particularités des outils et le bruit. Il s'agit d'un exercice d'équilibre, nécessitant de la pratique et de l'expertise que les ingénieurs d'Auriga ont acquises au fil des ans, mais ce que nous avons constaté, c'est qu'en découvrant la cause première des erreurs signalées, vous découvrirez probablement que beaucoup d'entre elles sont faciles à corriger. .

Voici quelques exemples de rapport d'analyse statique qui peuvent facilement être corrigés par un simple script ou des stagiaires bien formés:

1) Appel de fonctions claires dans les destructeurs:

une. Le destructeur '~ CTitle' ne doit pas appeler la fonction 'clear_' qui n'est pas dans le contexte try

b. Le destructeur '~ THelper' ne doit pas appeler la fonction 'removeModule' qui n'est pas dans le contexte d'essai

2) Vérifiez NULL:

une. «PMP» peut éventuellement être nul

b. «((NPage *) this) -> pSysCfg_» peut éventuellement être nul

3) Éventuellement déclaration dans la mauvaise section:

une. Les données membres "D_FILE_1" sont déclarées comme "publiques"

4) Arguments non constants:

une. La chaîne littérale «MCollection» est passée à la fonction «FixedBlockHeap» en tant que pointeur vers un objet non const

De nombreuses violations du code existant que vous pouvez mettre de côté et les traiter lorsque vous avez un temps d'arrêt. Cependant, il est important de NE PAS introduire de nouvelles violations (service technique) lorsque vous développez du code. Par example, Parasoft C / C ++test  possède des fonctionnalités qui permettent aux ingénieurs de filtrer le bruit et de se concentrer sur la résolution des violations récentes de l'analyse statique les plus critiques.

Analyse dynamique

Alors que l'analyse statique interprète le code source comme du texte et tire toutes les conclusions basées sur la sortie de l'analyseur sans exécuter une seule instruction, test dynamique de sécurité des applications ou DAST fournit une perspective différente sur le code. Il examine le fonctionnement code, montrant la couverture du code, la suffisance et la qualité des tests unitaires, les fuites de mémoire et d'autres problèmes potentiels de faiblesses.

Astuce n ° 3: Soyez flexible avec votre environnement d'exécution

Le terme «embarqué» couvre de nombreux appareils: du MCU 8 bits avec kilo-octets de RAM et flash au processeur multicœur 64 bits avec gigaoctets de RAM et SSD haute vitesse. Dans le cas où le fonctionnement quotidien de l'appareil nécessite une mémoire et une puissance de traitement minimales, les fabricants opteront probablement pour un matériel uniquement axé sur ses besoins en tenant compte des contraintes de taille, de poids ou de coût. Bien qu'ils laissent généralement une certaine capacité pour les mises à jour et la maintenance logicielles, cela peut encore être insuffisant en ce qui concerne l'outil d'analyse dynamique instrumentant le logiciel, car le processus nécessitera une énorme quantité de RAM (par rapport au mode de fonctionnement normal) et un espace de stockage pour recueillir les résultats des tests et de la couverture du code.

Par conséquent, lorsque la quantité de mémoire sur l'appareil est trop faible pour exécuter les tests et collecter la couverture de code, la plate-forme cible peut ne pas convenir pour collecter la couverture de code pour les tests unitaires et d'intégration.

Si votre plate-forme cible principale n'est pas prise en charge par défaut, recherchez des alternatives valides. Il pourrait y avoir une plate-forme sœur avec plus d'interfaces et de mémoire prises en charge par un outil d'analyse dynamique afin que vous puissiez l'utiliser pour des tests unitaires et d'intégration. Une autre alternative consiste à utiliser des simulateurs matériels qui exécutent ARM Fast Models et QEMU.

Bien que l'exécution de tests sur la plate-forme cible soit la plus souhaitable, les équipes choisissent souvent d'effectuer des tests unitaires et d'intégration d'applications sur le poste de travail du développeur (tel que Linux, Mac, Windows) pour bénéficier d'un cycle de développement plus rapide et d'un plus grand nombre d'outils disponibles. pour les plates-formes de développement générales. Dans ce cas, vous devrez porter votre code embarqué pour compiler avec un compilateur hôte, ce qui peut présenter des défis.

Il existe de nombreux compilateurs, outils de construction, frameworks et méthodes pour les exécuter. Les outils d'analyse dynamique prennent en charge certaines techniques de construction courantes avec des présomptions internes sur la façon dont les développeurs peuvent les appliquer. Par conséquent, même si le code est portable, l'équipe de projet aura probablement besoin de plus de temps pour aligner les paramètres d'un outil d'analyse dynamique en fonction du fonctionnement du système de génération du projet.

Il est fortement recommandé d'estimer à l'avance tous les efforts afin de choisir la meilleure approche pour le développement futur et le soutien dans une perspective à long terme.

Conseil n ° 4: Ne vous fiez pas trop aux cas de test générés automatiquement

Les outils d'analyse dynamique modernes génèrent automatiquement des ensembles de tests unitaires pour augmenter la couverture du code. Mais les outils ne sont que des outils - ils sont indépendants de divers scénarios d'utilisation du code de production, en particulier lorsque vous essayez d'augmenter la couverture du code et de franchir une frontière entre les tests unitaires purs et les tests d'intégration. Vous devrez toujours mettre à jour manuellement les tests unitaires générés, et même en écrire de nouveaux, car vous seul savez ce que le code est censé faire en ce qui concerne les résultats de tests positifs et négatifs.

D'après notre expérience, un ensemble de fichiers sélectionnés dans une zone critique peut avoir des tests unitaires générés automatiquement couverts dans une plage allant de 40% à 100% pour chaque fichier. Mais en moyenne, pour l'ensemble du projet, les chiffres peuvent varier de 25% à 60%.

De plus, les tests unitaires générés automatiquement en utilisant uniquement le code source comme entrée peuvent souvent fonctionner parfaitement sur un code bogué. La génération automatique doit être utilisée comme un bon moyen de démarrer le processus de test unitaire. Le processus de création de cas de test améliore manuellement la qualité du code car il force une révision supplémentaire du code et fournit un point de vue différent sur la conception.

Conseil n ° 5: ne sous-estimez pas l'effort de qualification / validation des outils

La FDA exige que tout outil utilisé pendant le développement formel soit valide pour l'utilisation prévue afin de garantir qu'il exécute les actions attendues et produit les bons résultats. Habituellement, il s'agit d'un protocole de test spécial appelé IUV (Intended Use Validation).

Les principaux fournisseurs d'outils d'analyse statique et dynamique aident à produire les procédures et la documentation nécessaires, ce qui est extrêmement utile pour minimiser vos efforts. Parasoft est particulièrement précieux car il automatise une grande partie du processus. Comme pour tout autre package générique, vous souhaiterez peut-être réserver certains de vos efforts pour réviser et ajuster les documents afin de les synchroniser avec vos propres procédures QMS. Par exemple, le logiciel de qualification d'outil de Parasoft fournit un ensemble de cas de test à exécuter sur votre environnement pour valider les capacités d'analyse statique et dynamique.

En résumé

  1. Traitez les avertissements du compilateur comme des erreurs. Les avertissements peuvent devenir des erreurs plus tard pour la version la plus récente du même compilateur. Les avertissements signifient souvent que le compilateur fait quelque chose de manière implicite.
  2. Exécutez les outils d'analyse statique au début du projet et résolvez les problèmes au fur et à mesure qu'ils apparaissent.
  3. Gardez le code portable. Même si vous ne prévoyez pas de porter votre produit sur une autre plate-forme, cela pourrait être une option à l'avenir. D'un autre côté, cela aidera également à garder votre code propre, maintenable et lisible, ce qui est toujours bon pour la révision et le soutien supplémentaire.
  4. Ne vous fiez pas trop aux cas de test générés automatiquement pour améliorer la qualité du code.
  5. Ne sous-estimez pas la nécessité et l'effort pour valider l'outil pour une utilisation prévue.

Si vous souhaitez obtenir de l'aide pour l'adoption de l'analyse statique et dynamique, veuillez nous contacter à Auriga.

Test de développement unifié pour les applications C et C ++

« MISRA », « MISRA C » et le logo triangulaire sont des marques déposées de The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Tous droits réservés.

Écrit par

Andreï Shastin

En tant que responsable des partenariats technologiques et commerciaux chez Auriga, Andrey élabore une stratégie de son offre de R&D logicielle pour résoudre les défis SDLC embarqués des fabricants de dispositifs électroniques, y compris l'assurance de la qualité et de la cybersécurité.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.