MISRA-C++ bietet Richtlinien und Konformität auch für neuen Sprachstandard C++20

Inhaltsverzeichnis

C++ wird oft für technische Systeme eingesetzt, die zuverlässig funktionieren müssen. Ein Fehlverhalten einer solchen C++-Software durch Programmierfehler, zum Beispiel im Auto, kann damit eine Gefahr für Leib und Leben darstellen. Diese Gefahr wird durch funktionale Sicherheit (Safety) adressiert. Aus diesem Grund existieren Programmierrichtlinien und statische Prüfwerkzeuge. Ziel ist es, das Risiko durch typische Programmierfehler, die zum Beispiel Undefined Behavior verursachen, zu reduzieren. Dieser Artikel thematisiert die entsprechenden Richtlinien mit dem Fokus auf die gerade aktualisierten MISRA-C++-Regeln.

Oft steht die Informationssicherheit (Security) im Fokus und selten die funktionale Sicherheit. Bei vernetzten technischen Systemen ist Informationssicherheit jedoch eine Voraussetzung für funktionale Sicherheit. Zum Beispiel konnten Hacker schon aus der Ferne Fahrzeuge manipulieren, wie beim sogenannten Chrysler Jeep Hack.

Notwendigkeit für Regelwerke ergibt sich häufig aus der Praxis

Allgemeine Regelwerke, wie die Norm EN 61508 "Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/ programmierbarer elektronischer Systeme", fordern "gute Ingenieurspraxis", wie umfassende Dokumentation und Validierung, sowie sinngemäß die Nutzung des "Stands der Technik", also keine überholten Verfahren und Technologien. Speziellere Regelwerke, zum Beispiel für Luftfahrzeuge, versuchen Dinge zu verhindern, die früher passiert sind.

Zum Beispiel haben Großflugzeuge heute in der Kabine durchweg abgerundete Fenster. Diese wurden vorgeschrieben, nachdem die de Havilland Comet 1, ein früher Passagierjet in den 1950er-Jahren, mit Druckkabine und eckigen Fenstern abstürzte. Als Absturzursache konnte man Risse im Rumpf feststellen, die sich von den Fensterecken her ausbreiteten. Das zeigt in vielen Fällen, vor allem beim Einsatz neuer Technologien, wie damals der Flugzeugdruckkabine, dass man Sicherheit erst durch schlechte Erfahrungen erlangt. Darum können sich neuere Programmiersprachen und Sprachversionen (C++20) nicht in den entsprechenden Richtlinien wiederfinden. Es fehlt schlicht die Erfahrung, was bei der Anwendung neuer Dinge, beispielsweise Coroutinen, schiefgehen kann.

Weitere Artikel wie diesen im C++-Sonderheft

Die Programmiersprache C++ gibt es seit 1979. Über vier Millionen aktive Entwicklerinnen und Entwickler nutzen sie heute. Das iX-Developer-Sonderheft "Modernes C++" bietet zahlreiche Artikel zum neuen Sprachstandard C++20 und eine Sammlung der iX-Artikel zu C++ aus den vergangenen zwei Jahren. Zu den Highlights zählen ein Interview mit Bjarne Stroustrup, dem Erfinder von C++, der Artikel über MISRA-C++ von Peter Sommerlad und Basiswissen für den Entwickleralltag.

Das führt auch dazu, dass für sicherheitskritische Systeme oft eigentlich überholte Technologien genutzt werden, obwohl das im Widerspruch zum von den Normen ebenfalls geforderten Aktualitätsgrad der Technologien steht. Letztlich geht es darum, bewusst abzuwägen, welche Kombination von Technologien in einem sicherheitsrelevanten System sinnvoll ist, und diese dann auch ordentlich einzusetzen.

Leider zeigen sich manche Fehler, die ein Hersteller dabei macht, oft erst, wenn das System bereits fertig ist. Im schlimmsten Fall machen sie sich erst bemerkbar, wenn das System abstürzt. Wenn sich Fehler erst nach Jahren, teilweise nach einer umfangreichen Testzeit, in echten Gefahren oder Unfällen niederschlagen, ist es teuer oder gar zu spät, diese noch zu beheben. Die Flugzeuge der Comet-Serie wurden außer Betrieb genommen und der englische Passagierjet-Pionier de Havilland vom amerikanischen Unternehmen Boeing überholt. Umso wichtiger ist es, aus Fehlern zu lernen und das Lernergebnis in zukünftige Sicherheitsnormen und -praktiken einfließen zu lassen. Je früher das passiert, desto besser. Aber auch solche Verfahren zur kontinuierlichen Verbesserung und Weiterbildung werden von den entsprechenden Sicherheitsnormen gefordert.

Sichere Autosoftware

Im Bereich der Kraftfahrzeugtechnik spezialisiert die Norm ISO 26262 den Bereich der durch EN 61508 vorgegebenen Maßnahmen. Da sich die eingesetzten Technologien, wie die der sogenannten Steuergeräte (ECU – Embedded Control Unit), aber auch der darauf laufenden Software, ständig weiterentwickeln, wird auch in dieser Norm vorwiegend auf den Ablauf eines Entwicklungsvorhabens geschaut, ohne in technologische Details zu gehen. Da nicht jeder Teil einer in einem Fahrzeug eingesetzten Software gleich relevant für die funktionale Sicherheit des Gesamtsystems ist, definieren die Normen wie ISO 26262 sogenannte Sicherheitsstufen. Diese Automotive Safety Integrity Levels reichen von ASIL-D (hochkritisches System) bis ASIL-A (wenig kritisches System), für unkritische Systeme in Fahrzeugen ergänzt durch das Level QM (Quality Management).

Allgemein gilt für die jeweiligen Sicherheitsstufen, dass die Anforderungen an die Maßnahmen, das Risiko zu reduzieren, umso höher sind, je wahrscheinlicher und gefährlicher ein Fehlverhalten des Systems ist. Damit wird versucht, das Gesamtrisiko für die Gefährdung von Personen auf ein erträgliches Maß zu senken.

Heute baut ein Großteil der Innovationen im Fahrzeugbereich auf Software auf. Diese läuft in der Regel auf entsprechenden Steuergeräten, die miteinander vernetzt sind. Da ECUs zum Teil Fahrzeugfunktionen steuern – wie Lenkung oder Bremsen – die für die Sicherheit der Insassen und der anderen Verkehrsteilnehmer relevant sind, muss sich auch die Softwareentwicklung dafür entsprechenden Risikobewertungen und -überprüfungen unterwerfen.

Aus diesem Grund hat das MISRA-Konsortium (Motor Industry Software Reliability Association) ab 1998 Programmierrichtlinien für die Sprache C bereitgestellt, mit der aktuellen Version MISRA-C:2012. 2008 wurden mit MISRA-C++:2008 auch entsprechende darauf aufbauende Richtlinien für C++ veröffentlicht. Seither hat sich die C++-Norm allerdings deutlich weiterentwickelt (C++11, C++14, C++17, C++20), sodass viele der bisherigen Regeln veraltet wirken und die neueren, eindeutig besseren Sprachmittel nicht abgedeckt sind.

Modernere komplexe Systeme im Automobilbereich lassen sich mit der dort dominanten Programmiersprache C kaum noch beherrschen, weil C vergleichbar gute Abstraktionsmöglichkeiten fehlen – wie C++ sie beispielsweise bietet. Das hat das AUTOSAR- Konsortium (AUTomotive Open System ARchitecture – Entwicklungspartnerschaft im Automobilbereich) bewogen, auf C++ für die neue "AUTOSAR Adaptive"-Plattform zu setzen. Sie wird mit dem Ziel entwickelt, umfangreichere Fahrerassistenzsysteme bis hin zum selbstfahrenden Fahrzeug zu unterstützen.