Topbeiträge

Code auf Kollisionskurs

Anzeige
Durch vereinheitlichte Steuergeräte können sich Sicherheitslevels überschneiden. Eine neue Software soll solche Kollisionen bereits dem Programmierer aufzeigen. Bisher waren solche Fehler schwer oder erst spät festzustellen – häufig waren Applikationen schon so weit entwickelt, dass eine Änderung nur sehr mühsam nachgepflegt werden konnte.

Der Autor: Jan Schlemminger, Field Application Engineer für Tasking-Produkte bei Altium, Karlsruhe

Wenn sich perfekt generierter Code mit anderem perfekt generierten Code überschneidet
Altium/Tasking ist seit über 30 Jahren darauf spezialisiert, Compiler und Entwicklungsumgebungen für den Embedded-Processing-Markt anzubieten, insbesondere für das Automotive-Segment. Seitdem hat sich der Schwerpunkt in der Wettbewerbslandschaft für Embedded-Tools in diesem Bereich verschoben. In einer früheren Marktphase konzentrierten sich die Alleinstellungsmerkmale sehr stark auf Performance-Kennzahlen, auf den Codeumfang, auf die Speichernutzung und auf die Verarbeitungsgeschwindigkeit – also auf die Resultate von Optimierungen während des Compilierungsprozesses. In gewissem Maß kam zu diesen Aspekten die Leistungsaufnahme des Systems hinzu. Diese mag zwar im Automotive-Bereich kein so entscheidendes Kriterium sein wie auf anderen Märkten. Wichtig ist sie aber gleichwohl, da die Zahl der prozessorbasierten Systeme im Auto zunimmt und die endlichen Energieressourcen immer weiter ausgereizt werden. Überwogen werden alle diese Gesichtspunkte jedoch von einem Aspekt, dem immer mehr Aufmerksamkeit gewidmet wird. Gemeint sind die Korrektheit des erzeugten Codes sowie die Sicherheitsrelevanz.
Mehr ECUs, höhere Komplexität
In den zurückliegenden 30 Jahren gab es mehrere parallele Trends. So war in den 1980er Jahren in der Automobilindustrie eine markante Zunahme der (allgemeinen) Qualitätsniveaus zu beobachten, und in den 1990er Jahren wurden viele bis dato mechanische Systeme durch elektrische Lösungen ersetzt oder zumindest ergänzt. Die elektronische Kraftstoffeinspritzung und das Antiblockiersystem sind hier zwei herausragende Beispiele. Auf Mikrocontrollern basierende elektronische Steuergeräte (Electronic Control Units – ECUs) wurden der Standard für die Steuerung von Subsystemen im Auto und die Zahl der ECUs pro Fahrzeug vervielfachte sich. Nach dem Jahr 2000 stieg die Komplexität steil an. Multi-Core-Prozessoren waren erforderlich, um den Rechen- und Sicherheitsanforderungen von Antriebsstrang-Anwendungen gerecht zu werden. Darüber hinaus ist eine entsprechende, weiter anhaltende Komplexitätszunahme der Algorithmen zu beobachten, die in Chassissteuerungs- und Fahrerassistenzsystemen zum Einsatz kommen.
Im größeren Kontext der Generierung von Embedded-Code wurde man sich gleichzeitig immer mehr bewusst, dass es eines strukturierten und disziplinierten Ansatzes bei der Softwareentwicklung bedurfte, denn die Anfälligkeit jeglicher Arten sicherheitskritischer Systeme gegen Softwarefehler war nicht mehr zu übersehen.
Das Bekenntnis zu Fehlern
In diesem Zeitraum vollzog sich in der Automobilindustrie ein ebenso rapider Umschwung hin zu mehr Produktqualität. Über die intern aufgestellten Qualitätsprogramme und den Wettbewerbsdruck hinaus kamen externe Qualitätsstandards ins Spiel, deren Einhaltung nachgewiesen werden musste. Ein herausragendes Beispiel ist hier die Norm ISO 26262 „Road vehicles – Functional safety“: Sie wurde mit dem Ziel geschaffen, die Sicherheit elektrischer und elektronischer Systeme in Straßenfahrzeugen zu gewährleisten. Ebenso wie andere sicherheitsrelevante ISO-Normen strebt auch die ISO 26262 nicht das Erstellen von Systemen an, die nicht ausfallen können und werden. Stattdessen wird die Tatsache, dass Fehler auftreten werden, explizit anerkannt. Deshalb soll sichergestellt werden, dass die Reaktion des gesamten Systems auf einen Ausfall unter allen Umständen zu einem sicheren Resultat führt. Die Norm soll also gewährleisten, dass der angewandte Designprozess so angelegt ist, dass er ein sicheres System hervorbringt.
Während für die Tasking Compiler ein strukturiertes Programm in Form vom ISO 26262 Safety Kit angeboten wird, muss der Anwender auch für seine Applikation nachweisen, dass diese den Richtlinien der ISO 26262 entspricht. Insbesondere ein Nachweis der „Freedom from interference“ ist bislang nicht oder nur eingeschränkt automatisiert möglich.
Der Nachweis, dass ein Fehler in einem Element sich nicht auf andere Elemente ausweitet, ist nur durch Betrachtung des Gesamtsystems möglich. Klassisches Unit-Testing deckt dies teilweise durch System- bzw. Integrationstests ab, jedoch erfolgt stets eine Instrumentierung und es müssen sehr viele Testfälle ausgearbeitet werden. Dies führt zu Einschränkungen:
Die Applikation wird für die Tests modifiziert und Tests auf der Hardware sind durch Einflüsse von Peripherie wie einem Watchdog und zusätzlichem Flash- und RAM-Bedarf nur eingeschränkt oder generell nicht möglich.
Der Systemtest erfordert eine hohe Anzahl an Testcases und wird daher erst durchgeführt, wenn ein großer Teil der Applikation bereits fertig ist. Für substanzielle Anpassungen der Applikation ist es dann bereits zu spät.
In der Praxis wird daher der Nachweis bislang händisch durch ein Review der Designspezifikationen durchgeführt sowie im laufenden Betrieb durch eine Memory Protection Unit (MPU) überwacht. Die manuelle Prüfung ist fehleranfällig, aufwendig und es besteht die Möglichkeit, dass die Applikation von der Spezifikation abweicht. Weiterhin erlaubt die MPU nur eine begrenzte Anzahl an Speicherbereichen und erkennt Fehler erst, wenn diese auftreten. Für Tests ist stets eine Instrumentierung notwendig und die MPU wird erst bei der finalen Integration eingeschaltet. Um unvorhersehbare Fehler während der Laufzeit abzufangen, ist die MPU essentiell. Im Umkehrschluss sollte sie jedoch nicht als Testwerkzeug verwendet werden, um Designfehler während der Entwicklung aufzuspüren.
Inspiration durch OpenSource-Betriebssystem
In einem komplett anderen Kontext erlaubt das Prinzip der Vergabe von Zugriffsrechten und Eigentümern unter Linux seit Jahrzehnten, mehrere Nutzer auf einem Rechner getrennt voneinander ohne Sicherheitsrisiken arbeiten zu lassen. Klar definierte Zugriffsrechte, wer welche Dateielemente ausführen, lesen oder schreiben kann, verhindern unautorisierte Zugriffe bevor sie auftreten. Tasking hat dieses Prinzip für den Nachweis der „Freedom from Interference“ adaptiert und daraus den Safety Checker entwickelt.
Dieses auf Safety Level spezialisierte Tool ist eine gute Ergänzung zu bestehenden Testtools, da es ermöglicht, bereits in der Entwicklung Verletzungen zu detektieren. Dazu wird die Applikation in Sicherheitsklassen unterteilt und Zugriffsrechte zugewiesen. Bereits der Compilierungsprozess zeigt Verletzungen an, ohne dass Testfälle oder Instrumentierungen nötig wären. Das Tool selbst modifiziert die Applikation nicht, sämtliche zur Auswertung erforderlichen Informationen werden als Debuginformationen gespeichert. Auch Multicore-Applikationen können ohne Einschränkungen geprüft werden.
Im Einzelnen bietet der Safety Checker folgende Möglichkeiten:
Hardwarenahe Entwicklung verbunden mit der Fähigkeit, die Einhaltung der übergeordneten Sicherheitsanforderungen zu überprüfen.
Lückenschluss zwischen den Anforderungen der ISO 26262 und traditionellen Softwaretests, die begleitend zu statischen Analysetools verwendet werden.
Zuordnung von Linker-Abschnitten zu applikationsspezifischen Sicherheitsklassen, auch für existierende Objektdateien, für die kein Quellcode verfügbar ist.
Verwendung unmodifizierter Applikationen zur Durchführung von Tests bei gleichzeitiger sofortiger Darstellung von Zugriffen zwischen verschiedenen Sicherheitsklassen und etwaigen Verletzungen.
Altium Europe GmbH
Tel.: +49 721 8244 108
Anzeige

Aktuelle Ausgabe

Newsletter

Unsere Dosis Wissensvorsprung für Sie. Jetzt kostenlos abonnieren!

Webinare & Webcasts

Technisches Wissen aus erster Hand

Whitepaper

Hier finden Sie aktuelle Whitepaper

Video-Tipps

Unser aktueller Video-Tipp: BMW Studie Vision Next 100 - 100 Jahre BMW

Weiterbildung

Weiterbildungsangebote für den Konstruktions- und Entwicklungsingenieur

Anzeige

Industrie.de Infoservice

Vielen Dank für Ihre Bestellung!
Sie erhalten in Kürze eine Bestätigung per E-Mail.
Von Ihnen ausgesucht:
Weitere Informationen gewünscht?
Einfach neue Dokumente auswählen
und zuletzt Adresse eingeben.
Wie funktioniert der Industrie.de Infoservice?
Zur Hilfeseite »
Ihre Adresse:














Die Konradin Verlag Robert Kohlhammer GmbH erhebt, verarbeitet und nutzt die Daten, die der Nutzer bei der Registrierung zum Industrie.de Infoservice freiwillig zur Verfügung stellt, zum Zwecke der Erfüllung dieses Nutzungsverhältnisses. Der Nutzer erhält damit Zugang zu den Dokumenten des Industrie.de Infoservice.
AGB
datenschutz-online@konradin.de