La sûreté et la sécurité des dispositifs médicaux intégrant du logiciel nécessitent une réflexion et un choix de plateforme matérielle et logicielle très tôt dans le cycle de conception. Fournisseur de solutions dans ce domaine, Mentor Graphics explique ici les critères essentiels à considérer.

Eric Faure, Senior Field Application Engineer chez Mentor Graphics

Les fabricants de dispositifs médicaux sont face à de nombreux défis : des cycles d’innovation de plus en plus courts, une concurrence croissante, une diminution des coûts, une réglementation toujours plus stricte... L'intégration de logiciels dans les DM (connectés notamment) rajoute un nouveau défi : la sécurisation des logiciels pour assurer leur intégrité, garantir leur fiabilité et protéger les données. Un défi majeur qui influence les temps de mise sur le marché et les coûts de développement.

Du point de vue de la sécurité et de la sûreté, les plateformes matérielles (processeurs) et logicielles (système d’exploitation (OS)) utilisées pour le développement des applications sont indissociables. Leur choix devra se faire en s’assurant que le matériel fournit les services attendus. Le processeur doit notamment offrir des fonctions matérielles de codage/décodage accélérées des données permettant leur stockage sûr et leur transmission sécurisée. Quant aux services de l’OS, ils doivent utiliser ces accélérations matérielles pour minimiser l’utilisation des ressources de calcul du processeur. L’authentification des logiciels exécutés doit aussi être prise en charge par le support du démarrage sécurisé, en utilisant des clés d’authentification uniques pour chaque étape du démarrage : l’amorçage de la plateforme, l’exécution de l’OS et l’exécution des applications. Ces clés devront être stockées et gérées dans un espace sécurisé comme le permet la technologie ARM TrustZone.

Certification des logiciels embarqués

La publication récente du règlement (UE) 2017/745 renforce les attentes relatives à la certification des logiciels embarqués dans les DM. Les logiciels actuels qui satisfont aux exigences des dispositifs de Classe I devront vraisemblablement répondre aux exigences des dispositifs de Classe IIa ou IIb.

Les coûts associés à la certification croissent de façon substantielle en fonction du niveau de certification à atteindre. Il faut donc apporter une attention particulière aux choix d’architecture afin d’assurer qu’à la fois le logiciel sera certifiable et que les coûts de certification seront contenus.

Dans le cas des dispositifs les plus simples, l’utilisation d’un OS tel que Nucleus, conçu en respect de la norme IEC 62304 et fourni avec les documents associés, répondra aux exigences des organismes notifiés. Mais de nombreux DM nécessitent l’utilisation de composants logiciels difficiles à certifier: USB, interface homme-machine, communication sans fil… Il est alors pertinent d'envisager d’isoler la partie "safe" (sécurisée) du logiciel de la partie "non safe". Plusieurs solutions existent : les process, le moniteur ARM TrustZone ou la virtualisation.

Les process permettent une isolation spatiale simple, pertinente lorsqu’il est possible démontrer que ces parties  "non safe" n’ont pas d’influence sur la partie "safe" du point de vue de la certification.

Une architecture basée sur le moniteur ARM TrustZone permet de créer deux partitions strictement isolées par le biais du processeur, empêchant la partition "non safe" d’accéder aux ressources matérielles critiques de la partition "safe".  La partition "safe" peut accueillir un OS certifiable et la partition "non safe" un OS différent, riche en fonctionnalités tel que Mentor Embedded Linux.

Enfin, un hyperviseur comme Mentor Embedded Hypervisor offre une grande latitude pour la définition de l’architecture : partitionnement du système au-delà de deux partitions, ségrégation et/ou partage des ressources matérielles. Pour que cette solution soit efficace, le processeur doit fournir des mécanismes d’accélération matérielle de virtualisation.

www.mentor.com