3 façons pratiques de pérenniser vos appareils IoT

Malgré le potentiel des appareils embarqués dans le contexte de l'IdO, de nombreux appareils ne sont actuellement pas tenus de se conformer aux normes de sûreté ou de sécurité. Mais dans le monde Agile du développement IoT, les exigences de conformité peuvent venir beaucoup plus tard, une fois que le code a déjà été écrit et testé. Alors, comment préparer l'avenir de vos appareils IoT embarqués?

Le terme Internet des objets (IoT) fait référence à un système d'appareils, de composants ou de services connectés au réseau qui publient et/ou consomment des données. Applications IoT font désormais partie intégrante de notre vie : des robots industriels et instruments chirurgicaux aux voitures autonomes et aux drones volants de manière autonome. Aujourd’hui, bon nombre de ces appareils peuvent déjà avoir un impact sur la sécurité, la confidentialité et la sécurité de leurs utilisateurs. Dans certains cas, le coût d’une panne est mortel, il est donc essentiel de construire ces appareils conformément aux normes en vigueur.

S'il est préférable de commencer à intégrer les activités de conformité dans la conception de logiciels dès le début, il est bien connu que des processus de développement rigoureux (en particulier sans l'aide de l'automatisation) peuvent avoir un impact sur le délai de mise sur le marché. Peu de développeurs aiment faire des tests supplémentaires et documenter la traçabilité en dehors des heures de travail normales, donc les équipes pragmatiques, agiles et rapides ne peuvent souvent pas se permettre de perdre leur élan en intégrant la conformité dans le calendrier en partant du principe qu'elles «pourraient en avoir besoin» dans le futur. Au lieu de cela, de nombreuses équipes choisissent de «traverser ce pont lorsqu'elles y parviennent».

Malheureusement, il n’existe pas de baguette magique ou de solution miracle qui «rende» le code rétroactif. Ce que ces organisations apprennent à leurs dépens, c'est que le coût de l'ajout de la conformité à la fin du projet est d'un ordre de grandeur plus élevé que le coût de développement du produit de travail initial.

Alors, quelles actions à faible impact pouvez-vous prendre aujourd'hui pour vous préparer à satisfaire les exigences de conformité strictes de demain?

Action 1: Gagnez en visibilité sur votre dette technique

Il est important de comprendre où en est votre projet en ce momentL’ montant de la dette technique est le coût d'une refonte potentielle due à la complexité du code combinée à toute norme de codage restante et aux violations de sécurité qui existent actuellement dans le code. Cette dette est due au nettoyage, à la correction et aux tests ultérieurs du code. L'une des façons de bien comprendre où en est un projet aujourd'hui est d'utiliser l'analyse de code statique automatisée. L'analyse statique donne un aperçu de la qualité et de la sécurité d'une base de code et énumère les violations des normes de codage, le cas échéant.

Malheureusement, de nombreuses équipes développant des applications embarquées en C et C ++ s'appuient toujours sur leur compilateur ou sur des revues de code manuelles pour détecter les problèmes, au lieu d'adopter une analyse statique. Certaines équipes ont du mal à adopter des outils d'analyse statique pour diverses raisons, comme les trouver bruyantes et difficiles à utiliser (cela ne devrait pas être un problème si vous apprenez à bien démarrer) ou à défaut de l'intégrer dans le processus de développement quotidien en raison de problèmes quotidiens urgents. Une perception (erronée) courante est que le temps passé à déterminer quelles violations méritent d'être corrigées est supérieur à la valeur de la correction réelle.

Mais nous constatons que les équipes qui ont adopté un petit ensemble de règles critiques et obligatoires ont passé beaucoup moins de temps à retravailler le code face à des audits de sécurité fonctionnelle plus tard dans le projet. Il est beaucoup plus facile de créer des systèmes sûrs et sécurisés à partir de zéro en intégrant la sécurité en implémentant, par exemple, les directives de codage sécurisé CERT C. Vous pouvez commencer petit. CERT dispose d'un système de hiérarchisation sophistiqué (utilisant la gravité, la probabilité et le coût de la correction, chacun en 3 niveaux, 27 niveaux au total), et si vous utilisez les outils Parasoft, vous pouvez facilement afficher l'état de la conformité dans un tableau de bord préconfiguré.

L'analyse statique aide également les organisations à comprendre leur dette technique en collectant des points de données qui aident la direction à respecter la sûreté et la sécurité. Les gestionnaires peuvent facilement évaluer les questions importantes, telles que:

• Quelle est ma ligne de base? Combien de violations de normes de codage non critiques existent dans ma base de code?
• Données de tendance: de nouvelles violations et des violations corrigées sont-elles signalées à chaque build? Allons-nous mieux ou pire?
• Quelle est la complexité de mon code aujourd'hui? Est-ce que ça grandit?

Certaines normes nécessitent de mesurer la complexité cyclomatique, pour la maintenir en dessous d'un certain seuil. Les métriques de complexité peuvent également être utilisées pour estimer un effort de test - par exemple, le nombre de cas de test dont vous avez besoin pour démontrer une couverture de niveau de branche à 100% pour se conformer à la norme CEI 61508 SIL 2 sera proportionnel à la complexité cyclomatique McCabe d'une fonction.

Voici un exemple d'un tableau de bord montrant la conformité MISRA d'un projet dans Parasoft DTP, le hub de reporting et d'analyse de Parasoft:

Et voici la même chose pour CERT C:

La valeur de voir les métriques de code peut aider à exposer des zones plus complexes pour une révision de code supplémentaire et à surveiller dans quelle mesure ces zones sont couvertes par les tests. Voici un exemple de tableau de bord des mesures:

Vous pouvez donc commencer par les bases. Une fois que l'équipe est à l'aise avec la gestion des erreurs les plus critiques, vous pouvez augmenter l'ampleur des violations des normes. Toutes les règles ne sont pas «gravées dans le marbre», il est donc important de décider quelles règles sont dans ou hors de la norme de codage du projet. Au minimum, l'adoption de l'ensemble de règles obligatoires dans quelques normes de codage clés (par exemple, les règles MISRA obligatoires ou CERT C) facilite l'argumentation future de la sûreté et de la sécurité d'un appareil connecté.

Action 2: Mettre en place un cadre de test unitaire qualifiable et mesurer la couverture du code

La plupart des ingénieurs pragmatiques ont tendance à convenir que la création aveugle de tests unitaires pour toutes vos fonctions ne fournit pas un bon retour sur investissement. Cependant, si votre équipe a accès à un cadre de test unitaire dans le cadre du bac à sable du projet, il s'agit d'un investissement précieux. Les tests unitaires peuvent être utilisés de manière intelligente lorsque les ingénieurs estiment avoir besoin de tester certains algorithmes complexes ou manipulations de données de manière isolée. Il y a aussi une valeur significative dans le processus de développement de tests unitaires - ce que nous avons vu des organisations, c'est que la pratique d'écrire et d'exécuter simplement un test unitaire rend le code plus robuste et mieux conçu.

Lorsque des exigences de sécurité ou de conformité se posent, une organisation peut rapidement intensifier l'effort de test unitaire en ajoutant temporairement des membres du personnel. Mais pour faire évoluer rapidement cet effort, le cadre et le processus de test unitaire doivent déjà être compris et documentés au cours du projet. Les caractéristiques communes d'un cadre de test unitaire évolutif en tenant compte de la conformité future sont les suivantes:

• Qualifié pour l'utilisation prévue pour une norme de sécurité donnée (par exemple via un certificat TÜV)
• Intégré dans un système de construction automatisé
• Indique la métrique de couverture de code requise (par exempleMC / DC)
• Enregistrez les résultats et la couverture des tests exécutés par build et au fil du temps
• Vendable pour plusieurs projets et équipes

La clé à retenir est de déployer toutes les techniques de test requises par une future norme de sécurité, mais à une échelle minimale. Il est plus facile pour cela d'évoluer quand et si un besoin de certification apparaît plutôt que de repartir de zéro.

Action 3: isoler les fonctionnalités critiques

L'architecture des systèmes embarqués nécessite de prendre en compte de nombreuses «ilités»: simplicité, portabilité, maintenabilité, évolutivité et fiabilité tout en résolvant les compromis entre la latence, le débit, la consommation d'énergie et les contraintes de taille. Lors de la conception d'un système qui sera potentiellement connecté à un vaste écosystème IoT, de nombreuses équipes ne donnent pas la priorité sécurité et sécurité sur certains de ces autres facteurs de qualité.

Pour faciliter la conformité future en matière de sécurité (et suivre les bonnes pratiques architecturales), vous pouvez séparer les composants dans le temps et dans l'espace. Par exemple, vous pouvez concevoir un système dans lequel toutes les opérations critiques sont exécutées sur un processeur dédié séparé, tout en exécutant toutes les opérations non critiques sur un autre - offrant ainsi une séparation physique. Une autre option consiste à utiliser un hyperviseur de noyau de séparation et des concepts de micro-noyau. Il existe d'autres options disponibles, mais la clé est d'adopter des approches architecturales clés séparation des préoccupations, défense en profondeur, et séparation pour criticité mixte le plus tôt possible. Ces approches réduisent non seulement la quantité de travail requise pour se conformer aux normes de sûreté et de sécurité, mais elles améliorent également la qualité et la résilience de l'application. Par exemple, voici quelques moyens d'isoler le code critique:

• Domaine spatial:
  • Fichiers
  • Modules
  • Partages de fichiers
  • Bibliothèques
• Domaine d'exécution:
  • Threads, tâches RTOS, hyperviseurs
  • Cœurs de processeur, processeur séparé

La séparation des fonctions critiques des fonctions non critiques réduit la portée des efforts de vérification futurs pour démontrer la conformité.

Résumé

De nombreux appareils de périphérie de l'écosystème IoT fournissent des services critiques susceptibles de relever de futures normes de sûreté et de sécurité. Bien entendu, essayer de se conformer aux exigences des normes, sans savoir si c'est nécessaire ou non, n'est pas une stratégie rentable. Pour se préparer à l'avenir, les organisations peuvent adopter des techniques de conception clés, des approches de test unitaire et des outils d'analyse statique, et collecter des mesures pour répondre aux besoins futurs. Les équipes logicielles peuvent adopter ces approches de manière transparente dans leurs processus existants si elles ont été lancées suffisamment tôt. Commencer tôt avec la bonne approche qui peut être mise à l'échelle plus tard pour éviter la nécessité d'un effort presque herculéen pour mettre le code logiciel en conformité lorsqu'il a été développé, testé et déployé.

« 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.