Analyse statique et conformité aux normes de codage pour les logiciels de conduite autonome

L'écriture de code pour des fonctionnalités complexes telles que la conduite autonome nécessite de grandes équipes de personnes talentueuses, qui ont très souvent leur propre point de vue sur la manière de garantir un code de haute qualité. Mais il n'est pas si facile de construire un processus de développement logiciel efficace qui inclut des initiatives de qualité telles que l'analyse statique et la conformité aux normes de codage, qui permettront la certification réussie de la voiture autonome.

La conduite autonome est un espace très compétitif et la vitesse du développeur est un mantra. Celui qui peut le premier mettre un produit certifié sur le marché aura un avantage significatif sur la concurrence, et il est donc facile pour les développeurs de considérer l'analyse statique et d'autres initiatives de qualité comme un obstacle. Surtout parce que le domaine de la conduite autonome a soif de talents, les organisations recrutent des développeurs intelligents, même s'ils n'ont aucune expérience en matière de sécurité. Mais les développeurs qui viennent d'un milieu sans culture de sécurité fonctionnelle ne sont pas conscients de tous les processus de qualité requis pour le développement de logiciels critiques pour la sécurité. Cela peut faire de l'adhésion culturelle un défi.

Obtenir l'adhésion interne

Parfois, il semble que la construction d'un consensus interne pour des pratiques axées sur la qualité nécessite une maîtrise en psychologie, ou les compétences d'un négociateur qualifié ... Dans des projets antérieurs, j'ai été responsable de l'introduction de l'analyse statique et de la conformité aux normes de codage AUTOSAR C ++ 14 en tant que traiter. Le logiciel de conduite autonome est très innovant et les composants logiciels qui y sont utilisés sont développés en utilisant le C ++ moderne. Dans cet esprit, la norme de codage AUTOSAR C ++ 14 est la norme la plus appropriée pour les logiciels de conduite autonome, car elle prend en charge le C ++ moderne et a été créée pour un développement axé sur la sécurité.

Pour convaincre ceux qui ne sont pas convaincus, j'ai fait plusieurs présentations traitant de plusieurs aspects différents. Mais malgré toutes ces discussions et accords, certains développeurs résistent à analyser tout le code qu'ils créent. Voici quelques-uns des principaux points sur lesquels je me concentre pour mettre en place les bons processus:

• Certifications - Les logiciels de voitures autonomes doivent être approuvés et certifiés avant de passer à la production de masse. Ce processus semble différent dans différentes régions du monde, mais toutes les organisations automobiles reconnaissent ISO 26262 comme la principale norme de sécurité fonctionnelle qui simplifie l'approbation et la certification. L'analyse statique et la conformité aux normes de codage sont exigées par l'ISO 26262, et le manque de conformité aux normes de codage pour le code source sera un énorme obstacle dans le processus d'approbation. Aucune organisation commerciale sérieuse ne tolérera ce risque.
• Meilleure qualité à faible coût - Lorsque vous créez du code conforme de haute qualité dès le début, en testant le plus tôt possible, il est plus facile (c'est-à-dire plus rapide) de résoudre les problèmes et vous éviterez les pièges courants car les développeurs commenceront à adopter les meilleures pratiques dès le début. Les développeurs (même ceux qui sont nouveaux dans la culture critique de sécurité) apprendront et il y aura moins de violations de l'analyse statique. Il est essentiel de tester pendant l'écriture du code, pour créer des logiciels complexes à un rythme rapide. L'analyse statique est l'une des méthodes qui s'intègre très bien dans ce tableau, établissant une base essentielle pour la sûreté et la sécurité en éliminant les classes de problèmes qui peuvent conduire à des comportements imprévisibles. Donner aux développeurs un outil qui produira les résultats dans une courte boucle de rétroaction, avec un faible nombre de faux positifs, augmente l'acceptation de cette technologie de test. Et avec le temps, les développeurs commencent à y voir un filet de sécurité, c'est-à-dire quelque chose qui les aide à créer un code fiable. Sans oublier que cela est essentiel pour Agile / DevOps car si vous attendez de faire l'analyse juste avant la sortie, vous passerez des mois à réparer le code.
• Questions juridiques - La conformité aux normes de codage est un bouclier pour d'éventuels problèmes juridiques. Avec des millions de voitures sur les routes, des accidents vont se produire. Certains d'entre eux seront attribués à des erreurs logicielles, qui sont inévitables. Les organisations doivent être en mesure de démontrer qu'elles ont fait tout ce qui est pratiquement possible pour prévenir les risques pour la sécurité. Ne pas avoir un processus de conformité aux normes de codage documenté sera certainement un problème en cas de défaut logiciel qui a contribué à une tragédie. Ainsi, lorsque je discute de cet aspect avec les développeurs, pour renforcer l'effet, j'aime inclure certains accidents réels causés par des défauts logiciels, tels que la tristement célèbre accélération involontaire de Toyota.

Convaincre les développeurs les plus résistants…

La technologie de conduite autonome n'en est qu'à ses débuts. Une grande partie du code source créé n'est qu'un prototype pour tester de nouvelles idées. Certains développeurs ne veulent pas «perdre» de temps à le rendre conforme à la norme de codage - ils veulent juste écrire quelque chose rapidement et le tester. Une histoire typique que j'ai entendue est: "Je veux juste tester ce nouvel algorithme, s'il fonctionne, je réécrirai le code pour le rendre propre." Cela semble assez innocent, mais la réalité est qu'il ne s'agit que d'une dette technique croissante.

Lorsque nous passons d'un prototype à l'autre, nous emportons généralement beaucoup de code avec nous, statistiquement, cela peut représenter jusqu'à 80% du code. Nous ne pouvons donc pas nous permettre de prototyper quelque chose avec du mauvais code et de le réparer plus tard, car depuis le début, nous savons que nous n'aurons pas le temps pour cela. Donc, même si quelque chose est un prototype, le code doit être conforme car le produit final va contenir une quantité importante de code qui a été initialement créé sous forme de prototype.

Si au lieu de vous concentrer sur le faire maintenant au lieu de le faire plus tard, vous pouvez vous concentrer sur le faire maintenant pour éviter de passer un temps inconnu à la fin, les développeurs commencent à y voir une amélioration du processus au lieu d'introduire un ralentissement. Si vous pouvez intégrer efficacement le processus dans le flux de travail du développeur sans ralentir la vitesse ou la créativité, il devient beaucoup plus facile de travailler avec. Il est beaucoup plus facile de garder quelque chose en ordre et de nettoyer au fur et à mesure que de nettoyer un énorme gâchis, à la fin. Construire des pratiques cohérentes et maintenables pour écrire du code conforme vous aidera à trouver moins de gâchis plus tard.

Ce sacré code hérité…

Mais même si vous parvenez à introduire avec succès un processus de conformité aux normes de codage dès le début, il y aura inévitablement déjà une quantité (significative) de code qui a déjà été créée par l'équipe, et une autre qui a été héritée. Et pendant que vous sélectionnez l'outil d'analyse statique (test Parasoft C / C ++) et choisissez le standard (AUTOSAR), en attendant, l'équipe crée beaucoup de code sans aucune politique de conformité! Il est donc important de créer également une stratégie pour le code hérité. Deux grandes politiques sont:

• "Zéro nouvelle violation" - dans lequel vous ne pouvez pas terminer la création d'un nouveau code tant qu'il n'est pas conforme
• «Nettoyer au fur et à mesure» - dans lequel, si vous touchez le fichier, vous devez le nettoyer

Avec ces stratégies, vous pouvez traiter le code hérité, introduire un nouveau code et continuer à garder le lieu bien rangé.

Résumé

Pour réussir à adopter des processus d'analyse statique et de conformité aux normes de codage dans l'ensemble de l'organisation de développement, vous bénéficierez des avantages suivants:

1. Assurez-vous que tout le monde comprend pourquoi vous le faites (sans y passer du temps, vous ne pouvez pas être certifié et ne pourrez pas réussir sur le marché automobile)
2. Abordez le coût des versions retardées si vous n'abordez pas la qualité comme un effort continu et montrez à l'équipe ce qui se passe lorsque vous le laissez jusqu'à la fin
3. Rendre l'adoption aussi pertinente et fluide que possible. Soyez intentionnel lorsque vous implémentez votre outil d'analyse statique, en veillant à sélectionner les bonnes règles et vérificateurs et à disposer d'un flux de travail qui s'intègre dans le flux de travail existant des développeurs.