La fusion de MISRA C ++ et AUTOSAR C ++: une table ronde

La Motor Industry Software Reliability Association (MISRA) a annoncé la future fusion de MISRA C++ et AUTOSAR C++, les deux principales normes de codage C++ critiques pour la sécurité. Qu'est-ce que cela signifie pour les utilisateurs de la norme et quel impact cela aura-t-il sur la mise en conformité des organisations ?

Nous avons réuni un groupe d'experts de l'industrie ici à Parasoft pour une discussion de style table ronde sur ce que l'avenir réserve à MISRA C ++ et sur l'impact et les avantages attendus de cette nouvelle norme fusionnée.

Les participants sont:

• Andreï Madan, Lead Solutions Architect chez Parasoft
• Piotr Pepek, Responsable du développement logiciel pour le test Parasoft C / C ++
• Michal Rozenau, Ingénieur logiciel chef de projet chez Parasoft et membre du groupe de travail MISRA C et C ++
• Mirosław Zielinski, Chef de produit pour le test Parasoft C / C ++

Table ronde

Comment les normes MISRA C ++ et AUTOSAR C ++ sont-elles utilisées aujourd'hui et quels sont certains des problèmes généraux que vous rencontrez dans l'industrie automobile?

Mirek: Bien que ces deux normes aient une origine automobile, il est très courant pour nous de les voir utilisées dans le processus de conformité non seulement avec ISO 26262 pour l'automobile, mais aussi avec CEI 61508, la norme d'automatisation industrielle, et avec les dispositifs médicaux et CEI 62304. Donc, quand on parle de MISRA et AUTOSAR, ce n'est pas seulement pour l'industrie automobile.

En termes de problèmes, sur la base de mon expérience de travail avec différents clients dans plusieurs secteurs, je dirais que les parties les plus difficiles de la conformité à une norme de codage sont:

• Mise en place de la norme dans les outils d'analyse statique de l'équipe
• La phase initiale après la première analyse
• Faire face à un grand nombre de violations

Le succès dépend définitivement de la manière dont la norme est introduite dans l'organisation, et la mise en place du processus de conformité est essentielle pour le succès de l'adoption de toute norme de sécurité fonctionnelle, y compris les deux.

Andrey: Je suis tout à fait d'accord. Un problème courant que nous constatons avec l'utilisation de l'analyse statique pour les règles MISRA C ++ et AUTOSAR C ++ est le nombre de violations signalées. Si vous activez toutes les règles, vous aurez beaucoup de violations, et je veux dire beaucoup, en particulier pour une base de code héritée.

Donc, à l'heure actuelle, je pense que l'approche adoptée par la plupart des clients consiste à essayer de trouver un terrain d'entente. Pas tous des règles sont obligatoires ou obligatoires. Ils doivent donc développer un bon processus. Par exemple, ils exécutent des vérificateurs et effectuent des analyses sur le code et déterminent quel serait le sous-ensemble de règles applicable à leur développement et à la documentation de ce sous-ensemble. Ils comprennent qu'ils n'ont pas besoin de se conformer à toutes les règles - ils doivent simplement avoir une justification pour expliquer pourquoi la règle n'a pas été utilisée, la documenter, et c'est parfaitement normal.

Une fois qu'ils ont compris le processus, ils exécutent une analyse et même avec un arriéré de milliers d'avertissements, ces clients peuvent tracer une ligne dans le sable et avancer avec un arriéré de problèmes, avec l'intention de les contacter et de les résoudre à quelque point.

Michael: Oui - Je pense qu'une raison supplémentaire de la lutte ici est que, pour les entreprises qui tentent enfin de se conformer à une norme de codage comme MISRA, même si elles commencent le développement d'un nouveau code, elles recherchent la conformité vers la fin du cycle de vie du développement, plutôt que d’essayer de commencer par le début. Commencer tard est l'une des principales raisons pour lesquelles ils peuvent rencontrer un grand nombre de violations en premier lieu.

Qu'est-ce qui empêche les organisations de faire appliquer ces normes de codage dans la pratique?

Andrey: De nombreuses organisations utilisent déjà leur propre standard de codage interne pour C et C ++ qui a été développé en interne et utilisé depuis des années. Ces entreprises ont un document interne et des politiques qu'elles suivent, et elles doivent se moderniser à un standard comme MISRA, mais la dynamique de l'entreprise est si grande qu'il faut beaucoup de temps pour changer.

La stratégie de ces organisations consiste à passer en revue les violations, en examinant leur propre norme de codage, puis en mappant les vérificateurs d'analyse statique de Parasoft à leur propre norme de codage tout en examinant où leur propre norme de codage doit être Langage C.

Avec C ++, la situation est en fait pire actuellement en raison des anciennes normes de codage. Ils ne prennent pas en charge les nouvelles constructions de langage telles que les pointeurs automatiques et d'autres éléments que le nouveau C ++ moderne apporte à la table, de sorte que le processus prend plus de temps.

Mirek: J'ai mentionné que nous voyons AUTOSAR C ++ et MISRA C ++ fréquemment utilisés dans le cadre du processus de conformité des normes de sécurité fonctionnelle comme ISO 26262 et CEI 61508. La conformité à ces normes de sécurité fonctionnelle nécessite un processus de développement discipliné, qui comprend la préparation de la documentation. Les clients ont besoin d'un moyen de prouver formellement qu'ils sont conformes aux normes de sécurité fonctionnelle, ainsi qu'à une norme de codage, qui fait partie du processus de conformité pour la sécurité fonctionnelle.

Avec MISRA C++ et AUTOSAR C++, les outils Parasoft fournissent un support dédié pour ce côté formel du processus de conformité. Notre cadre de reporting génère une documentation spéciale conforme aux exigences définies dans le document MISRA Compliance : 2016 "Achieving Compliance with MISRA Coding Guidelines". Cela finit par être très important. Les clients qui tentent de se conformer à la norme voient cette partie du processus de conformité automatisée à l'aide des outils Parasoft.

normes, c'est que les normes elles-mêmes fournissent également des mécanismes de catégorisation pour leurs règles, ce qui aide grandement l'organisation à introduire la norme. Pour MISRA C ++ par exemple, il existe différentes catégories pour les directives (obligatoires, obligatoires et consultatives). Idem pour l'ensemble AUTOSAR C ++, et il existe également un cadre supplémentaire pour les catégorisations. Ce mécanisme peut également être utilisé pour faciliter l'ensemble du processus de mise en œuvre et aider essentiellement les gens à le faire par étapes, en commençant par la catégorie la plus critique et en nettoyant le code, puis en allant plus loin.

Les organisations qui commencent avec ces normes comprennent-elles l'importance de la catégorisation et de la priorisation?

Andrey: Les organisations n'y ont pas forcément pensé. La plus grande demande que je reçois en tant qu'architecte de solutions est quelque chose comme: «D'accord, Parasoft, nous voyons que vous avez des milliers de règles, et nous avons cette grande base de code. Aidez-nous à sélectionner les règles qui nous aident à trouver de vrais bugs, à trouver réellement quelque chose d'intéressant, quelque chose de valeur, quelque chose qui mérite d'être corrigé. »

À ce stade, nous prenons du recul pour déterminer quels sont leurs objectifs spécifiques. Mais nous voyons souvent des clients démarrer plus généralement, car malgré la nécessité de se conformer à une norme de codage, ils n'ont pas le temps de parcourir toutes les règles et de les analyser. C'est donc là qu'interviennent la catégorisation et la priorisation générale.

Nous pouvons également demander à la direction de l'équipe si elle nécessite ou non une approche stricte de la conformité, par exemple, en suivant toutes les règles requises et obligatoires. La plupart du temps, la direction ne tracera pas cette ligne et laissera plutôt la décision à ses ingénieurs, qui sont «assez intelligents» pour déterminer quelles règles sont nécessaires pour se conformer. On s'attend à ce que l'équipe de développement documente sa justification des raisons pour lesquelles les règles ont été activées ou désactivées.

Donc, de ce point de vue, je n'ai pas vu de gens «appliquer». C'est plus une approche pédagogique. Par exemple, lorsque j'explique qu'il y a des règles obligatoires et obligatoires, et que vous pouvez déroger aux règles (mais vous devez documenter comme spécifié par le document de conformité MISRA 2016), cela peut en fait être assez révélateur pour beaucoup de gens. D'après mon expérience, il y a certainement une courbe d'apprentissage et un besoin de consultation dans cet espace.

Mirek: Je suis d'accord - nous voyons ici un besoin important, non seulement dans l'industrie automobile, mais également dans d'autres organisations critiques pour la sécurité, d'obtenir des services de conseil pour appliquer plus concrètement la norme et hiérarchiser les actions pour y parvenir. Nous avons plusieurs partenaires qui aident à servir nos clients dans cet espace, mais le besoin est clairement là pour obtenir plus d'éducation et d'application.

Selon vous, quelle a été la force motrice de l'intégration des directives AUTOSAR C ++ et MISRA C ++? Y a-t-il des pièces importantes manquantes dans une norme ou une autre?

Piotr: La principale raison de la fusion des standards était simplement d'avoir un standard unique pour C ++. Historiquement, MISRA C ++ 2008 était basé sur C ++ 2003, et MISRA C ++ a presque 10 ans. AUTOSAR C ++ était fortement basé sur MISRA C ++ 2008 au début, mais a ensuite ajouté de nombreuses nouvelles règles qui sont plus pertinentes pour le C ++ moderne, y compris des fonctionnalités de C ++ 11 et C ++ 14. Ainsi, le principal moteur de l'intégration des deux normes a été de prendre ce que le groupe AUTOSAR C ++ a fait et de le transformer dans le prochain standard MISRA C ++.

La norme de codage AUTOSAR C ++ est-elle remplacée en tant que norme par MISRA C ++?

Michael: Oui, c'est le plan. Les annotations de la version actuelle d'AUTOSAR C ++ font référence aux futurs deltas aux directives de codage qui doivent être pilotées par MISRA. Nous pouvons donc penser à AUTOSAR C ++, comme l'a dit Piotr, comme une version mise à jour du standard MISRA C ++, basé sur MISRA C ++, avec un certain nombre de règles tirées littéralement de MISRA. Certaines de ces règles ont été mises à jour et des règles ont été ajoutées. Donc, le plan est de prendre ces règles mises à jour et de les ramener à MISRA C ++.

De quelle manière cette nouvelle norme intégrée aidera-t-elle les utilisateurs?

Mirek: Je pense qu'il est très utile d'avoir une norme sur le marché. Nous avons discuté avec de nombreuses organisations qui hésitaient à adopter une norme de conformité car elles ne savaient pas s'il y aurait une mise à jour venant de MISRA et envisageaient plutôt d'adopter AUTOSAR C ++. Alors ils reportaient cette décision. La fusion clarifie donc la situation et l'avantage évident est qu'il n'y a qu'une seule norme sur le marché et, fondamentalement, il n'y a aucun doute sur la voie à suivre - la nouvelle norme MISRA C ++ devient le premier choix pour la conformité.

L'intégration MISRA C ++ et AUTOSAR C ++ aura-t-elle un impact sur les utilisateurs existants?

Mirek: Il y aura certainement un impact. Par exemple, si une organisation qui s'appuie sur MISRA C ++ 2008 souhaite passer à AUTOSAR C ++, elle doit gérer environ 200 nouvelles règles (car dans la version actuelle d'AUTOSAR C ++ 18.10, environ 45% des règles ont été directement héritées de MISRA C ++ 2008 ).

Ainsi, si une organisation s'appuie sur MISRA C ++ 2008, la migration vers AUTOSAR C ++ représente un effort important pour elle. Mais, il y a aussi une énorme valeur à le faire, car le delta entre MISRA C ++ 2008 et AUTOSAR C ++ résout les changements dans le langage C ++ depuis 2003. Ainsi, toutes les nouveautés en C ++ 11 et C ++ 14 sont incluses dans AUTOSAR C ++. Alors oui, il y a un impact, mais il y a aussi beaucoup de valeur à mettre à jour vers la nouvelle norme.

Andrey: Si un client change de MISRA C ++ et qu'il se conformait déjà à sa norme de codage établie, et qu'il change de norme pour dire, AUTOSAR C ++, l'impact peut aussi parfois être plus logistique.

Ces clients ont déjà justifié en interne, documenté et supprimé les avertissements, et potentiellement même passé par des audits. Par exemple, disons que la règle 11.5 de MISRA C ++ a été violée mais que l'écart a été enregistré et documenté. C'est un exemple de suppression, ou dans ce cas d'écart, et cela nécessite des rapports et de la paperasse. Maintenant, si je passe à AUTOSAR C ++, cette règle de MISRA C ++ peut être la même règle sous le capot, mais le fournisseur de l'outil signale cela comme la règle AUTOSAR C ++ 17.6. C'est un nom différent, mais c'est la seule différence - juste l'étiquette. Cependant, l'outil d'analyse statique le signale à nouveau comme une erreur et ignore la suppression. La suppression a été marquée avec un numéro de règle différent et maintenant ils ont un grand nombre de violations.

Et la sécurité? AUTOSAR C ++ et probablement le nouveau MISRA C ++ couvrent-ils la sécurité?

Mirek: Eh bien, c'est avant tout une norme de sécurité fonctionnelle, mais la sûreté et la sécurité sont liées. Les deux consistent à créer un logiciel exempt de constructions menant à un comportement imprévisible, ce qui signifie que les organisations qui suivent AUTOSAR C ++ ou MISRA C ++ pour la sécurité fonctionnelle sont généralement assez bien couvertes pour la sécurité. La sécurité consiste à éliminer l'imprévisibilité du programme, ce qui, bien entendu, favorise également la sécurité.

Mais les directives de sécurité comme CERT sont plus complètes et incluent plus de directives spécifiquement liées à la sécurité. Actuellement, ce que nous constatons dans de nombreuses organisations, en particulier dans les entreprises automobiles matures, c'est qu'elles choisissent leur norme de sécurité fonctionnelle comme source principale, puis améliorent leur ensemble de règles en incluant des directives sélectionnées supplémentaires à partir d'une norme de sécurité telle que CERT C ++.

Y a-t-il une force motrice pour obtenir plus de sécurité dans ces normes critiques de sécurité, comme la fusion d'une norme de sécurité comme CERT C ++? Ou pensez-vous que les entreprises continueront à fusionner elles-mêmes des règles?

Mirek: Personnellement, je ne prédirais pas que CERT sera intégré ou fusionné avec MISRA ou AUTOSAR de si tôt. Parce que la sécurité a une portée plus large et moins stricte, en termes de sous-ensemble de langues, il y aura toujours un besoin de normes axées sur la sécurité, distinctes des normes de sécurité.

Ainsi, par exemple, dans MISRA C ++ 2008, vous avez une règle qui vous empêche d'utiliser l'allocation de mémoire dynamique. Vous ne pouvez pas l'utiliser si vous voulez être conforme à MISRA C ++ 2008. Cependant, pour CERT C ++, c'est parfaitement normal. Vous pouvez utiliser l'allocation de mémoire dynamique et il existe des règles sur la façon de le faire de manière sécurisée.

Piotr: Oui, et sur le site Web de MISRA, vous pouvez trouver des documents officiels qui fournissent des informations sur le mappage entre MISRA C 2012 et CERT C, par exemple, et ces mappages vous montrent clairement la différence de ce qui manque. Ainsi, les développeurs ont des informations sur les directives à inclure à partir de CERT C / C ++ à inclure dans leur sélection de règles. Et il existe également un mappage de traçabilité entre AUTOSAR C ++ et CERT C ++. Je pense qu'environ 50% de toutes les directives CERT C ++ ont une règle similaire dans AUTOSAR C ++ lui-même.

Mirek: De plus, je pense qu'il y a un aspect régional à l'adoption de ces normes. Comme nous l'avons vu avec l'adoption de MISRA au fil du temps, nous voyons maintenant un modèle similaire avec CERT C et C ++. Par exemple, nos clients au Japon adoptent très rapidement les dernières normes et semblent être en avance sur le reste du monde. Nos clients japonais ont été les premiers à demander le support MISRA C 2012 avec au moins un an d'avance sur les autres régions, et à l'heure actuelle, nous voyons un modèle similaire avec CERT C et C ++, avec plus de demandes du marché automobile japonais qui souhaitent une prise en charge CERT C / C ++ .

AUTOSAR C ++ est un standard très dynamique, avec deux versions par an. Quel est l'impact des mises à jour fréquentes sur les organisations qui tentent de se conformer? Pensez-vous que le nouveau standard MISRA C ++ respecte ce calendrier?

Piotr: Il est important de se rappeler que les directives AUTOSAR C ++ font partie du Plateforme adaptative AUTOSAR, donc ces deux versions par an sont le cycle de publication pour l'ensemble de la plate-forme. S'ils veulent garder les directives C ++ synchronisées avec la plate-forme, alors oui, cela doit être géré d'une manière ou d'une autre à long terme. Mais ce n'est pas nécessairement le cas que beaucoup de choses auront changé à chaque sortie.

Mirek: Comme nous l'avons déjà mentionné, il y a des problèmes avec les normes changeantes. Avec des changements fréquents dans la norme, vous avez tous les problèmes dont Andrey a parlé liés à la logistique. Lorsqu'une directive a changé, les clients doivent mettre à jour leur cadre de conformité, car ils auront tous les problèmes de violations re-signalées qui ne sont plus supprimés soudainement. C'est un défi de taille et coûte beaucoup d'argent. Si vous avez 50, 70 ou 100 développeurs et que vous avez déjà introduit un processus de conformité dans votre processus de développement, mais que vous avez une exigence commerciale selon laquelle votre produit doit être conforme à la dernière édition de la norme, alors vous avez ce défi.

Si la norme évolue rapidement avec des changements importants dans la norme, les clients doivent y remédier d'une manière ou d'une autre. Cela signifie souvent des heures supplémentaires dérivées du calendrier et du budget. C'est un problème, mais comme le disait Piotr, je pense qu'à long terme, le standard va se stabiliser et les changements entre chaque version ne seront pas si significatifs, comme on l'a vu par exemple dans la transition entre AUTOSARC ++ version 17.32 et 18.10 , par example.

L'évolution du langage C ++ s'est accélérée au cours des deux dernières années. AUTOSAR C ++ est actuellement basé sur C ++ 14. Quelle est l'attente de l'évolution de MISRA C ++ par rapport au langage C ++?

Michael: Actuellement, le plan de la prochaine version de MISRA C ++ est d'incorporer AUTOSAR C ++ 14 et de couvrir également C ++ 17, la version actuelle du langage. Cependant, je ne peux pas dire à quelle vitesse il évoluera dans le futur ou comment ces nouvelles versions seraient publiées. Personnellement, je m'attendrais à ce qu'une nouvelle version du standard soit créée pour chaque nouvelle version du langage, l'idée de base étant de mettre à jour le standard lorsqu'il est suffisamment mature. Cela devrait éviter le cas que nous avons eu avec AUTOSAR C ++, qui est basé sur C ++ 14, mais qui change encore deux fois par an.

Combien de temps prévoyez-vous le nouveau délai entre la mise à jour de la norme MISRA C ++ et la sortie du langage par le comité ISO C ++?

Michael: C'est difficile à dire, car dans le cas d'AUTOSAR C ++, la standardisation a commencé plus tard que la sortie de C ++ 14. La sortie de AUTSAR C ++ n'était pas liée à la sortie de la version du langage ou à l'apparition du langage.

AUTOSAR C ++ était basé sur C ++ 14 depuis le début. Lorsque AUTOSAR a publié la plate-forme adaptative, ils ont vu qu'il n'y avait pas de normes de codage qui couvraient C ++ 14, ils ont donc décidé de baser la norme sur MISRA C ++ 2008 et de mettre à jour avec de nouvelles règles et un support pour C ++ 14.

Les mises à jour AUTOSAR C ++ sont-elles dictées par le calendrier de publication de la plate-forme adaptative plutôt que par le langage?

Piotr: Oui, je le dirais.

Mirek: Il est important de souligner que le nouveau standard MISRA C ++ fusionné sera mis à jour au-delà d'AUTOSAR C ++. La nouvelle norme intégrée a été déclarée mise à jour pour inclure toutes les innovations introduites dans les nouvelles versions du langage C ++, y compris C ++ 17 et C ++ 20. Pour de nombreuses organisations, cela était d'une importance capitale. Les fonctionnalités C ++ modernes sont importantes dans les systèmes utilisant l'IA, par exemple, qui reposent sur des architectures modernes, des plates-formes modernes et une bibliothèque moderne qui sont fréquemment développées dans les dernières éditions de C ++. La déclaration selon laquelle la norme suivra l'évolution de la langue est donc très importante.

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