Fallstudie: Komplexitätsmanagement und Sicherheit in Embedded-Firmware mit CppDepend

Fallstudie: Komplexitätsmanagement und Sicherheit in Embedded-Firmware mit CppDepend

Branche: Eingebettete SystemeKundenprofil: Industrieautomatisierungsunternehmen, das Firmware für intelligente Steuerungen entwickeltBereich: Echtzeit-Embedded-Software für Sensorüberwachung und AktorsteuerungTeamgröße: 20 Embedded-Entwickler und TesterSprachen: C und C++Zentrale Normen: MISRA C, CERT C, ISO/IEC TS 17961Hardware-Ziele: ARM Cortex-M, RTOS (FreeRTOS-basiert)

Die Herausforderung

Der Kunde entwickelt intelligente Steuerungen für Fabrikautomation und Schwermaschinen. Die Firmware war für zeitkritische Vorgänge wie Druckregelung, Fehlererkennung und die Kommunikation mit übergeordneten Systemen über industrielle Protokolle (CANopen, Modbus) verantwortlich.

Mit der Weiterentwicklung der Firmware stand das Team vor mehreren Problemen:

• Komplexe, eng gekoppelte Module waren schwer zu testen oder produktlinienübergreifend wiederzuverwenden.
• Die Einhaltung von MISRA C und internen Zuverlässigkeitsregeln wurde manuell über Tabellen und Checklisten durchgesetzt.
• Entwickler führten häufig Speicherrisiken, tiefe Rekursionen und unsichere Typumwandlungen ein, die erst in späten Tests entdeckt wurden.
• Legacy-Treiber und Middleware von Drittanbietern verletzten Architekturgrenzen und blähten die Systemkomplexität auf.
• Manager hatten keine Transparenz über technische Schulden oder Code-Gesundheitstrends, was Sprint-Planung und Risikominderung erschwerte.

Das Team benötigte ein Tool, um Sicherheits- und Designregeln zu automatisieren, Wartbarkeit zu messen und frühzeitig Feedback zu riskantem Code zu geben — ohne zusätzlichen Overhead oder Beeinträchtigung der Echtzeit-Anforderungen.

Die Lösung: CppDepend

CppDepend wurde eingeführt, um dem Team die Kontrolle über die wachsende Firmware-Komplexität zu geben und Code-Sicherheit über lange Produktlebenszyklen zu gewährleisten. Es wurde aufgrund seiner Architektur-Durchsetzungsfähigkeiten, Trend-Dashboards und flexiblen CI-Integration gegenüber einfacheren Lintern bevorzugt.

Zentrale Ziele:

• Automatisierung der Erkennung von MISRA-C- und CERT-C-Verstößen
• Identifizierung versteckter zyklischer Abhängigkeiten und Architektur-Leaks
• Tracking von technischen Schulden, Komplexität und Code-Churn über die Zeit
• Unterstützung bei Refactoring-Maßnahmen für Modularität und Wiederverwendung
• Unterstützung von Testbarkeit und Systemzertifizierungs-Dokumentation

Umsetzungsansatz

Woche 1–2: Firmware-Baseline

• Firmware gescannt (~300K LOC)
• Erkannt:
• 800+ MISRA-Verstöße
• Mehrere zirkuläre Abhängigkeiten zwischen I/O und Geschäftslogik
• 60+ Funktionen mit hoher zyklomatischer Komplexität oder übermäßiger Verschachtelung

Woche 3–4: Definition benutzerdefinierter Regeln

• CQLinq-Regeln erstellt zur Erkennung von:
• Verbotene Nutzung von dynamischem Speicher oder malloc
• Tiefe Rekursion über 2 Ebenen hinaus
• Volatile-Nutzung außerhalb der Hardware-Abstraktionsschicht
• Design-Schichtregeln definiert (z. B. HAL darf nicht von App-Logik abhängen)

Woche 5–6: CI-Integration & Reporting

• CppDepend zu den Nightly Builds in Jenkins hinzugefügt
• HTML-Dashboards für Reviews durch QA- und Firmware-Leads generiert
• Trendberichte genutzt, um schleichende Komplexität über Komponenten hinweg zu erkennen

Ergebnisse nach 6 Wochen

Ergebnisse & Vorteile

• Sauberere Architektur: Entwickler konnten nun Module mit Zuversicht refaktorieren und entkoppeln, was zu schnellerer Wiederverwendung über Produktvarianten hinweg führte.
• Verbesserte Code-Sicherheit: Hochrisikomuster wie tiefe Verschachtelung, unsichere Casts oder unerwartete Includes wurden früh erkannt.
• Erhöhte Testbarkeit: Durch die Durchsetzung von Schichtung und Modularität konnten Teams Einheiten für Embedded-Tests besser isolieren.
• Audit-fähige Dokumentation: Berichte wurden in internen Qualitätsaudits und externen Kundenreviews wiederverwendet.
• Reduzierte Entwickler-Ermüdung: Statt sich gegenseitig in Code-Reviews zu kontrollieren, verließen sich Teams auf CppDepend für konsistente Regeldurchsetzung.

Warum CppDepend?

CppDepend war nicht nur ein statischer Analyzer — es war ein Design-Governance-Tool. Es ermöglichte dem Team den Übergang von reaktiver, checklistenbasierter Compliance zu proaktiver, automatisierter Qualitätssicherung.

Seine reibungsarme Integration, das reichhaltige Codemodell und die anpassbaren Regeln machten es ideal für tief eingebettete Software mit langfristigem Produktsupport.

Fazit

CppDepend half dem Team, die Kontrolle über seine Embedded-Firmware zurückzugewinnen. Es reduzierte Review-Zeit, erhöhte Modularität und gab Ingenieuren wie Managern die Transparenz, die sie benötigten, um sichere, skalierbare und testbare eingebettete Systeme zu bauen — bereit für den Einsatz in hochzuverlässigen industriellen Umgebungen.

← Zurück zur Übersicht Eingebettete Systeme