Étude de cas : maîtriser la complexité et garantir la sécurité du firmware embarqué avec CppDepend

Étude de cas : maîtriser la complexité et garantir la sécurité du firmware embarqué avec CppDepend

Secteur : Systèmes embarquésProfil client : société d’automatisation industrielle développant du firmware pour contrôleurs intelligentsDomaine : logiciel embarqué temps réel pour la surveillance de capteurs et le contrôle d’actionneursTaille de l’équipe : 20 développeurs et testeurs embarquésLangages : C et C++Normes clés : MISRA C, CERT C, ISO/IEC TS 17961Cibles matérielles : ARM Cortex-M, RTOS (basé sur FreeRTOS)

Le défi

Le client conçoit des contrôleurs intelligents utilisés dans l’automatisation industrielle et les machines lourdes. Le firmware était responsable d’opérations sensibles au timing comme le contrôle de pression, la détection de pannes et la communication avec les systèmes amont via des protocoles industriels (CANopen, Modbus).

À mesure que le firmware évoluait, l’équipe a rencontré plusieurs difficultés :

• Des modules complexes et fortement couplés étaient difficiles à tester ou à réutiliser d’une gamme de produits à l’autre.
• La conformité à MISRA C et aux règles de fiabilité internes était appliquée manuellement via des tableurs et des checklists.
• Les développeurs introduisaient fréquemment des risques mémoire, des récursions profondes et des conversions de types dangereuses qui n’étaient détectées qu’aux tests tardifs.
• Les drivers legacy et middlewares de fournisseurs tiers violaient les frontières architecturales et alourdissaient la complexité du système.
• Les managers n’avaient aucune visibilité sur la dette technique ou les tendances de santé du code, ce qui compliquait la planification des sprints et la maîtrise des risques.

L’équipe avait besoin d’un outil pour automatiser l’application des règles de sécurité et de conception, mesurer la maintenabilité et fournir un retour précoce sur le code risqué — sans surcharge ni perturbation des contraintes temps réel du système.

La solution : CppDepend

CppDepend a été introduit pour aider l’équipe à reprendre le contrôle d’une complexité croissante du firmware et à garantir la sûreté du code sur de longs cycles de vie produit. Il a été préféré à des linters plus simples grâce à ses capacités d’application d’architecture, ses tableaux de bord de tendances et son intégration CI flexible.

Objectifs clés :

• Automatiser la détection des violations MISRA C et CERT C
• Identifier les dépendances cycliques cachées et les fuites d’architecture
• Suivre la dette technique, la complexité et le churn du code dans le temps
• Orienter les efforts de refactoring vers la modularité et la réutilisation
• Soutenir la testabilité et la documentation de certification système

Approche de mise en œuvre

Semaines 1–2 : baseline du firmware

• Firmware analysé (~300 K lignes)
• Détecté :
• 800+ violations MISRA
• Plusieurs dépendances circulaires entre I/O et logique métier
• 60+ fonctions avec une complexité cyclomatique élevée ou une imbrication excessive

Semaines 3–4 : définition des règles personnalisées

• Règles CQLinq créées pour détecter :
• Utilisation interdite de mémoire dynamique ou de malloc
• Récursion profonde au-delà de 2 niveaux
• Utilisation de volatile en dehors de la couche d’abstraction matérielle
• Règles de couches définies (ex. : la HAL ne doit pas dépendre de la logique applicative)

Semaines 5–6 : intégration CI & reporting

• CppDepend ajouté aux builds nocturnes dans Jenkins
• Tableaux de bord HTML générés pour revue par la QA et les leads firmware
• Rapports de tendances utilisés pour détecter la complexité rampante entre composants

Résultats après 6 semaines

Résultats & bénéfices

• Architecture plus propre : les développeurs pouvaient désormais refactorer et découpler les modules en confiance, accélérant la réutilisation entre variantes de produits.
• Sûreté du code améliorée : les motifs à haut risque comme l’imbrication profonde, les casts dangereux ou les includes inattendus étaient détectés tôt.
• Testabilité accrue : en appliquant couches et modularité, les équipes pouvaient mieux isoler les unités pour les tests embarqués.
• Documentation prête pour audit : les rapports ont été réutilisés dans les audits qualité internes et les revues clients externes.
• Fatigue des développeurs réduite : au lieu de se surveiller mutuellement en revue de code, les équipes se reposaient sur CppDepend pour appliquer les règles de manière cohérente.

Pourquoi CppDepend ?

CppDepend n’était pas qu’un analyseur statique — c’était un outil de gouvernance de la conception. Il a permis à l’équipe de passer d’une conformité réactive basée sur des checklists à une assurance qualité proactive et automatisée.

Son intégration fluide, son modèle de code riche et ses règles personnalisables le rendaient adapté aux logiciels profondément embarqués avec support produit à long terme.

Conclusion

CppDepend a aidé l’équipe à reprendre le contrôle de son firmware embarqué. Il a réduit le temps de revue, augmenté la modularité et donné aux ingénieurs comme aux managers la visibilité nécessaire pour construire des systèmes embarqués sûrs, évolutifs et testables — prêts pour un déploiement dans des environnements industriels à haute fiabilité.

← Retour à la présentation Systèmes embarqués