Conformité MISRA : 5 Conseils pour réussir
Il exite de nombreux outils permettant de détecter les violations des règles MISRA dans un code C ou C ++. Cependant, si identifier et corriger les violations signalées par un outil d'analyse constitue un défi de taille pour les développeurs, il ne représente qu'une partie du processus de conformité pour l'ensemble de l'équipe de développement.
En fait, beaucoup sont surpris que le document MISRA C: 2012 contienne six chapitres de directives avant que les directives elles-mêmes ne soient définies. Il serait facile de mal comprendre la nature de la conformité à la MISRA, et de supposer qu'un nombre de violations réduit au minimum garantit une sécurité optimale des applications. En fait pour être efficaces, les directives MISRA doivent être appliquées au sein d’un cadre qualité global qui exploite les avantages d’un code conforme et gère les écarts nécessaires pour que le concept de conformité soit crédible.
Le document MISRA Compliance: 2016 compte 33 pages et un article aussi court que celui-ci ne peut couvrir tout ce dont il traite, mais il permet d’avoir une première idée de ce à quoi un projet conforme peut ressembler, et les principes énoncés, basés sur beaucoup de bon sens et de sagesse technique, reprennent l’esprit du document de conformité MISRA.
En fait, beaucoup sont surpris que le document MISRA C: 2012 contienne six chapitres de directives avant que les directives elles-mêmes ne soient définies. Il serait facile de mal comprendre la nature de la conformité à la MISRA, et de supposer qu'un nombre de violations réduit au minimum garantit une sécurité optimale des applications. En fait pour être efficaces, les directives MISRA doivent être appliquées au sein d’un cadre qualité global qui exploite les avantages d’un code conforme et gère les écarts nécessaires pour que le concept de conformité soit crédible.
Le document MISRA Compliance: 2016 compte 33 pages et un article aussi court que celui-ci ne peut couvrir tout ce dont il traite, mais il permet d’avoir une première idée de ce à quoi un projet conforme peut ressembler, et les principes énoncés, basés sur beaucoup de bon sens et de sagesse technique, reprennent l’esprit du document de conformité MISRA.
Conseil N°1 : La conformité MISRA nécessite un processus de développement logiciel documenté
Les directives MISRA sont destinées à être utilisées dans le cadre d’un processus de développement logiciel formel (voir Figure 1). Un tel processus garantit des exigences logicielles complètes, non ambiguës et correctes, et que toutes ces exigences soient couvertes par des artefacts créés à chaque phase du cycle de vie du développement.
Figure 1: Un cycle de développement structuré est essentiel à la conformité MISRA, comme illustré par «Uniview» dans le composant TBmanager de la suite d'outils LDRA. (Source: LDRA)
En effet si votre code ne comporte aucune violation MISRA mais qu’il ne réalise pas la fonction voulue, cela reste un mauvais code.
Conseil N°2 : Toutes les règles MISRA ne sont pas vérifiables par un outil d’analyse
Le standard MISRA C: 2012 est basé sur un système de « Règles » et de « Directives ». De manière générale, les règles sont suffisamment bien définies pour être vérifiables par un outil automatisé, alors que les directives peuvent être un plus subjectives.
Dans MISRA C: 2012, certaines règles sont intitulées «Indécidables», ce qui signifie qu’il est fondamentalement impossible d’avoir une méthode qui puisse généralement dire avec certitude si une violation est présente ou non. Un outil peut éventuellement avertir de la possibilité d'un problème mais dans les deux cas, un certain niveau d’intervention manuelle est requis.
Tous les outils ne sont pas identiques et certains prétendent couvrir plus de règles que d’autre. Mais en réalité un outil indiquant « pas de violation trouvée » devrait en réalité indiquer « pas de violation trouvée sauf celles que je n'ai pas repérées ». Un outil aide et assiste à la réalisation d’un travail mais il ne le fait pas à notre place
Dans MISRA C: 2012, certaines règles sont intitulées «Indécidables», ce qui signifie qu’il est fondamentalement impossible d’avoir une méthode qui puisse généralement dire avec certitude si une violation est présente ou non. Un outil peut éventuellement avertir de la possibilité d'un problème mais dans les deux cas, un certain niveau d’intervention manuelle est requis.
Tous les outils ne sont pas identiques et certains prétendent couvrir plus de règles que d’autre. Mais en réalité un outil indiquant « pas de violation trouvée » devrait en réalité indiquer « pas de violation trouvée sauf celles que je n'ai pas repérées ». Un outil aide et assiste à la réalisation d’un travail mais il ne le fait pas à notre place
Conseil N°3 : Une « recommandation » n’est intéressante que s’il existe un plan pour l’appliquer
Pour la plupart des recommandations MISRA C, le moyen le plus simple, le plus fiable et le plus économique de vérifier leur bonne application est d’utiliser un outils d’analyse statique.
Figure 2: Utilisation d'un outil d'analyse statique LDRA pour imposer la conformité à MISRA C:2012 (Source: LDRA)
Mais il est important de s’assurer que le ou les outils utilisés sont appropriés et que leur type et leur version sont spécifiés et validés.
Pour toutes les « directives » non analysables automatiquement par des outils, des plans de vérification manuelle doivent être définis et appliqués.
Pour toutes les « directives » non analysables automatiquement par des outils, des plans de vérification manuelle doivent être définis et appliqués.
Conseil N°4 : « Déviation » n’est pas un « gros mot »
Quelque soit l’application embarquée développée, il est très probable que certaines violations seront inévitables. La gestion de ces violations doit être autorisée selon un processus clairement défini, et étayée par une documentation appropriée « d'enregistrement des écarts » si l'on veut qu'une demande de conformité soit acceptée Ces écarts doivent inclure les directives violées, la justification de cette (ces) violation(s), les circonstances dans lesquelles la déviation s'applique et où dans le code, elle s'applique.
Conseil N°5 : Les code tiers ne peuvent pas être ignorés
La plupart des standards ou normes traitant de la sureté fonctionnelle et de la sécurité partent de l’hypothése que l’application démarre de « zéro ». Or dans bon nombre de cas, un logiciel embarqué vas regrouper à la fois du code propriétaire et des codes tiers. Bien qu’il ne soit pas toujours possible d’appliquer les règles de conformité MISRA sur ces codes adoptés, il est néanmoins nécessaire, voire obligatoire de vérifier que ces codes tiers ne peuvent compromettre la sûreté et la sécurité du système dans son ensemble.
Conclusion :
Plusieurs normes de sûreté comme l’ISO26262, l’IEC61508 ou la DO-178C exploitent le MISRA (totallement ou partiellement) mais il serait faux de croire que l’utilisation du MISRA ne s’arrête qu’à celles-ci. En fait, une majorité des directives MISRA et de ses sous-ensembles nécessaires pour atteindre la conformité MISRA, relèvent du bon sens et ne poussent qu’à « bien faire les choses ». Il n’est pas nécessaire non plus qu’un logiciel soit critique pour faire cela, car un logiciel, sécuritaire ou non, doit avant tout fonctionner correctement.
Plusieurs normes de sûreté comme l’ISO26262, l’IEC61508 ou la DO-178C exploitent le MISRA (totallement ou partiellement) mais il serait faux de croire que l’utilisation du MISRA ne s’arrête qu’à celles-ci. En fait, une majorité des directives MISRA et de ses sous-ensembles nécessaires pour atteindre la conformité MISRA, relèvent du bon sens et ne poussent qu’à « bien faire les choses ». Il n’est pas nécessaire non plus qu’un logiciel soit critique pour faire cela, car un logiciel, sécuritaire ou non, doit avant tout fonctionner correctement.
