Warum Standards-basierte Development Practices wichtig sind – auch wenn nicht mandatory

Error Types und Tools to Address Them

Software Defects fallen in zwei breite Kategorien, each requiring distinct Mitigation Techniques:

• Coding Errors – z. B. Out-of-Bounds Array Accesses – können früh mit Static Analysis detektiert werden.
• Application Errors entstehen, wenn Code seine Specifications nicht trifft; diese werden nur durch Requirements-Driven Testing uncovered.

Coding Errors und Code Review

Static Analysis ist mächtige First Line of Defense, besonders wenn integrated at Start eines Projects. Es identifiziert Violations von Coding Rules, die sonst zu hard-to-debug Bugs werden könnten. Komplementär zu Static Analysis prüft ein rigoroser Code Review, dass Code einem gewählten Coding Standard compliant, wie MISRA C:2012.

Theoretisch würde eine für Safety designte Language – Ada beispielsweise – viele Pitfalls durch Strong Typing und Explicit Constructs eliminieren. In Practice rely die meisten Embedded Teams auf C oder C++, die Flexibilität bieten, aber Developer auch subtilen Traps aussetzen wie Undefined, Unspecified und Implementation-Defined Behaviors. Durch Restriktion verwendeter Language Features und Verbieten riskanter Constructs (z. B. goto, malloc, Mixing Signed/Unsigned Arithmetic) kann ein Coding Standard die Bar für Defect Prevention raisen.

Hier ein paar Common Pitfalls illustriert in der C/C++ Welt:

1. Implementation-Defined Shift eines Signed Integers: füllt Right Shift High-Order Bit mit Zeros oder Ones?
2. Unspecified Order of Function Argument Evaluation, was Result einer simplen Routine wie rollDice() alterieren kann.
3. Mixing Signed und Unsigned Values, was zu subtilen Overflows führen kann.

Abbildungen 1 und 2 unten demonstrieren, wie derselbe Code across Compilers unterschiedlich verhalten kann, underscoring die Importance eines disziplinierten Coding Approach.

Abbildung 1: Das Verhalten mancher C/C++ Constructs hängt vom verwendeten Compiler ab. (Quelle: LDRA)

Abbildung 2: Das Verhalten mancher C/C++ Constructs ist von den Languages unspecified. (Quelle: LDRA)

Adopting eines well-established Coding Standards wie MISRA C:2012 hilft, diese Pitfalls zu vermeiden. Die Standards Rules decken über 300 spezifische Coding Practices ab, each backed by Explanations, die die Languages Undefined und Unspecified Behaviors referenzieren. Most Guidelines sind „decidable“, meaning ein Static Analysis Tool kann Violations automatisch detektieren; wenige sind „undecidable“, wo das Tool potenzielle Issues flaggen muss und Developer entscheiden, ob sie reale Probleme sind.

Im April 2016 expandierte MISRA seinen Scope, um Security-Critical Software zu adressieren, indem 14 neue Guidelines hinzugefügt wurden. Directive 4.14 zielt beispielsweise explizit auf Undefined Behavior ab, providing extra Layer of Protection für Security-Oriented Projects. Abbildung 4 zeigt, wie MISRAs Security Considerations mit dem breiteren Safety Framework alignieren.

Abbildung 4: MISRA und Security Considerations. (Quelle: LDRA)

Application Errors und Requirements Testing

Während Coding Standards gegen Low-Level Bugs guarden, entstehen Application Bugs, wenn Software ihr Intended Behavior nicht trifft. Detecting diese erfordert solide Requirements Base und traceable Linkage zwischen Requirements, Design und Code.

Bidirektionale Traceability stellt sicher, dass jedes Requirement implemented ist und jede Implementation zurück zu einem Requirement traced werden kann. Abbildungen 5 und 6 illustrieren dieses Two-Way Mapping, revealing Missing oder Redundant Functionality früh im Lifecycle.

Abbildung 5: Bidirektionale Traceability, mit Function selected. (Quelle: LDRA)

Zum Vergrößern klicken

Abbildung 6: Bidirektionale Traceability, mit Requirement selected. (Quelle: LDRA)

Once Traceability in Place, können Test Cases von Low-Level Requirements derived werden. Abbildung 7 zeigt ein typisches Low-Level Requirement, das ein einzelnes Functions Behavior fully specifies, und Tabelle 1 demonstriert, wie Test Cases zu diesen Requirements map.

Abbildung 7: Beispiel Low-Level Requirement. (Quelle: LDRA)

Tabelle 1: Test Cases derived from Low-Level Requirements. (Quelle: LDRA)

Executing diese Tests mit Unit-Testing Framework auf Host und Target bestätigt, dass Implementation das Requirement matcht. Abbildung 8 zeigt eine Regression Suite, wo alle Test Cases passen. Nach Test Execution verifizieren Structural Coverage Metrics, dass gesamte Code Base exercised wurde; Gaps prompten Additional Tests oder Code Refactoring.

Abbildung 8: Performing Unit Tests. (Quelle: LDRA)

Fazit

Software Complexity steigt, und damit Defekt-Risiko. Best-Practice Development – grounded in modernem Coding Standard wie MISRA C:2012, rigorosen Metriken, traceable Requirements und Requirements-Based Testing – provides proven Path zu High-Quality, Reliable, Robust Code. Ob Ihr Project formalen Safety Regulations unterliegt oder nicht, die Discipline und Transparenz diese Practices bringen sind Net Benefit für jedes Development Team.