Allen Regeln folgen?

Sicherheit

Bild 1: Das Tool C-STAT von IAR Systems unterstützt eine Prüfung der Regeln beispielsweise von MISRA oder von CERT-C und CERT-C++. IAR Systems

Viele Tools für die statische Analyse bieten MISRA-C-Checks für Quellcodes an. Viele gehen sogar darüber hinaus und bieten weitere Prüfungen an. Zum Beispiel führt das statische Analysetool C-STAT von IAR Systems Prüfungen der Regeln der Common Weakness Enumeration (CWE) sowie CERT-C und CERT-C++ aus (Bild 1). Diese stellen allerdings nur Richtlinien dar, sie sollten also nicht blind befolgt werden. Vielmehr wäre es ratsam zu überprüfen, was die einzelnen Regeln besagen und ob sie für das vorliegende Projekt geeignet sind, zum Beispiel ob die Speicherallokation dynamisch über den Heap erfolgen darf. Außerdem sollten diese Regeln am besten zu Projektbeginn berücksichtigt und nicht erst am Projektende abgeprüft werden. Im Extremfall werden hier möglicherweise Tausende von Regelverletzungen angezeigt – was den frustrierten Entwickler nur dazu verleiten wird, diese Regelchecks generell zu deaktivieren.

Muss eine statische Analyse durchgeführt werden, nachdem der Code erstellt worden ist (beispielsweise in Legacy-Projekten), sollte zunächst festgelegt werden, welche die „einfachsten“ Regeln sind und den Code auf entsprechende Verstöße überprüfen. Als „einfach“ gelten Regeln, für die sich leicht und sicher Veränderungen am Code vornehmen lassen, wenn ein Verstoß vorliegt – das minimiert den Aufwand bei den erforderlichen erneuten Tests. Je mehr Regeln im Legacy-Code implementiert werden, desto robuster wird die Anwendung. Und auch wenn nicht alle Regeln abgeprüft werden können, gilt trotzdem die alte Regel: Wenig ist besser als nichts!

Sicherheit

Bild 2: Laufzeitanalyse-Tools wie C-RUN von IAR Systems helfen dabei, Fehler bei der Ausführung des Codes zu finden. IAR Systems

Das Gegenstück zur statischen Analyse ist die Laufzeitanalyse. Manche Verhaltensweisen sind vollständig dynamisch und treten erst während der Laufzeit auf. Beispielsweise wenn ein Wert von einem Analog-Digital-Converter ausgelesen und für die Berechnung eines Array-Index genutzt wird, der dann einen Out-of-Bounds-Zugriff des Arrays erzeugt, der nicht statisch erfasst werden kann. Datenzugriffe außerhalb der vorgesehenen Bereiche führen zu unbestimmten Ergebnissen, denn es wird quasi ein Zufallswert ausgelesen, der dazu führt, dass die Anwendung falsche Ergebnisse liefert oder wegen eines fehlerhaften Zeigers „ins Kraut schießt“. Diese Art von potenziellen Fehlern beim Bound-Checking sind in der Embedded-Software weit verbreitet, weshalb Analysetools wie das Laufzeitanalysetool C-RUN von IAR Systems (Bild 2) so hilfreich sind. Sie helfen auch dabei, den Heapspeicher des Codes zu prüfen und andere Datenmanipulationen oder arithmetische Fehler bei der Codeausführung zu lokalisieren.

Entscheidend ist, dass sowohl die statische als auch Laufzeitanalyse des Codes dabei hilft, Fehler noch während der Entwicklung zu finden, also noch bevor sie in den formalen Build einfließen. Fehler, die in diesem Stadium der Entwicklung entdeckt und behoben werden, sind damit quasi niemals entstanden.

Wird aber ein Fehler in die Build-Phase übernommen, beeinträchtigt er die „Release Metrics“ des Projektes, wie Mean Time to Failure (MTTF) oder Mean Time Between Failures (MTBF). Dies verlängert den Test- und Debugging-Zyklus im Projekt, was wiederum zu erhöhten Entwicklungskosten und auch demotivierten Entwicklungsteams führt. Mit dem Einsatz eines Codeanalysetools lässt sich aber nicht nur ein langwieriger Debugging-Prozess verhindern. Vielmehr lässt es die Softwareentwicklung des Unternehmens für einen Reviewer bei der Zertifizierung für funktionale Sicherheit insgesamt auch sehr viel ausgereifter aussehen, wenn der Code offensichtlich eine niedrige Fehlerrate hat. Durch die Nutzung dieser Tools und Prozesse lässt sich also auch viel schneller eine Zertifizierung für funktionale Sicherheit erzielen.

Tools für die beschleunigte Zertifizierung

Um die Zertifizierung noch weiter zu beschleunigen, ist es ratsam Tools zu nutzen, die bereits eine eigene Zertifizierung für funktionale Sicherheit nachweisen können. Beim Einsatz eines nicht zertifizierten Tools ist es erforderlich, sehr strengere Anwendungstests durchzuführen, um nachzuweisen, dass es keine nachhaltigen Fehlerquellen in der Toolchain gibt. Das ist zwar grundsätzlich möglich, bedeutet aber einen Zusatzaufwand, weil dies bedeutet, dass die Tools für jedes einzelne Projekt wieder zertifiziert werden müssen. Das kann gut und gerne bis zu fünf Mitarbeiter für bis zu sechs Monate beschäftigen, was einen hohen finanziellen Aufwand und einen Verlust in der Produktivität bedeutet. Wird eine Toolchain eingesetzt, die diese Zertifizierung bereits vorweisen kann – wie die Functional-Safety-Version der IAR Embedded Workbench mit einer zertifizierten kompletten Build-Chain – wird sich der Zertifizierer bei seiner Prüfung auf die Anwendung konzentrieren.

Eck-DATEN

Mit vorqualifizierten Entwicklungs- und Analysetools lässt sich der Zertifizierungsprozess für funktionale Sicherheit erheblich beschleunigen. Grundsätzlich kommen dabei Werkzeuge sowohl für die statische Analyse als auch für die Laufzeitanalyse. Speziell für den Bereich Automotive hat IAR Systems erst kürzlich eine neue Functional-Safety-Version ihrer Toolchain vorgestellt: die IAR Embedded Workbench für die RH850 Mikrocontrollerfamilie von Renesas.

Seite 2 von 212