Startseite > Automotive > Software + Tools > Die fünf wichtigsten Regeln

System-Software für Assistenzsysteme

Die fünf wichtigsten Regeln

4. Mai 2015, 10:20 Uhr | Von Peter Hoogenboom

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

3. Konsumelektronik-Software vorsichtig einsetzen

Die nächste ADAS-Generation wird High-End-Grafiken und andere fortschrittliche Software und Algorithmen nutzen. Hinzu kommen Multimedia-Neuerungen aus dem Bereich der Konsumelektronik. Entwickler müssen daher auf dem neuesten Stand bezüglich Standards wie OpenGL, OpenVG, OpenVX und OpenCL sein.

Eine große Herausforderung ist jedoch das Abstimmen komplexer Konsumelektronik-Software-Pakete mit den Sicherheitsanforderungen (z.B. nach ISO 26262). Eine Möglichkeit, universelle Software, einschließlich Open Source, in ein sicherheitskritisches System einzubringen, ist die Virtualisierung. Damit werden sicherheitskritische Komponenten von den Software-Paketen getrennt, die sicherheitskritische Standards nicht erfüllen. Mit einer Virtualisierung werden diese komplexen Subsysteme zu vollständigen Gast-Betriebssystemen, die unter der Kontrolle eines sicheren Hypervisor auf einer virtuellen Maschine laufen.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Im Gegensatz zu einem herkömmlichen Hypervisor kann ein Automotive-qualifizierter Hypervisor native Echtzeit-Sicherheitsanwendungen sowie Gastsysteme hosten. Die strenge Ressourcenplanung und die Schutzmechanismen des Hypervisor garantieren, dass die virtuelle Maschine und ihre Anwendungen die Ausführung kritischer Anwendungen nicht beeinträchtigt (Bild 1).

Leider müssen bei einem ADAS die komplexen Subsysteme sehr oft in einem sicherheitskritischen Kontext verwendet werden. Eine leistungsstarke 3D-Anzeige kann den Fahrer zum Beispiel über Gefahren im Straßenverkehr informieren. Nur wenige Echtzeit-Software-Plattformen unterstützen die Kombination aus ISO 26262 ASIL D und 3D-Grafik. Green Hills‘ Echtzeit-Betriebssystem Integrity ist eine bekannte Plattform für Automotive-Sicherheitssysteme, die OpenGL unterstützt und beschleunigte Grafik-Software sowie Treiber für eine Reihe bewährter Automotive-SoCs wie Freescales i.MX-Serie, TIs Jacinto-Reihe, Renesas’ R-Car-Serie und Intels Atom-Prozessor-E3800-Reihe bereitstellt.

Noch einmal zurück zu den ISO-26262-Anforderungen: ASIL D ist zwar der höchste Sicherheitsgrad, aber nicht jedes Bauteil oder Subsystem im Auto muss diesem Grad entsprechen. ISO 26262 bietet das Konzept der ASIL-Dekomposition über Software-Partitionierung. So kann ein ASIL-C-Subsystem aus einer ASIL-B- und einer ASIL-A-Partition bestehen, solange die Partitionierung und Störsicherheit garantiert und die Gesamtsicherheit des Subsystems auf ASIL C validiert und verifiziert werden kann. Ein hochsicheres Partitionierungs-Betriebssystem oder ein Hypervisor, der selbst nach ASIL D zertifiziert ist, kann die Gesamtsystemkosten verringern, indem die ASIL-Anforderungen zugehöriger Komponenten verringert werden und der (vorsichtige) Einsatz komplexer Software-Pakete, die nicht für höhere Sicherheitsgrade qualifiziert werden können, erlaubt wird (Bild 2).

4. Nur hochsichere logische Trennungen einsetzen

Eines der dominierenden Themen im Jahr 2014 war das vernetzte Auto und die verbundenen Sicherheitsrisiken, die bei der drahtlosen Kommunikation – vor allem bei WANs – mit dem Fahrzeug einhergehen. Auch 2015 wird dieses Thema eine große Rolle spielen. Im Idealfall sind sicherheitskritische Subsysteme im Fahrzeug physisch isoliert von Multimedia- oder Telematik-Subsystemen, die eine solche Art der Datenanbindung nutzen. Entwickler ersetzen die physische jedoch zunehmend durch eine logische Trennung und erzwingen eine Subsystem-Isolierung durch Software Firewalls.

Forscher haben jedoch demonstriert, dass, sobald die Leitungen miteinander verbunden sind, Schwachstellen in verschiedenen Subsystemen ausgenutzt werden können, um die logische Trennung zwischen sicherheitskritischen und nicht sicherheitskritischen Systemen zu überspringen. Das Problem scheint einfach lösbar zu sein (die physische Trennung beibehalten!); in der Praxis werden entsprechende Verbindungen jedoch immer häufiger gefordert. Die gewünschte Reduzierung von Größe, Gewicht und Kosten verlangt nach weniger Verkabelung und Hardware-Komponenten. Diese Konsolidierung zwingt Entwickler, eine logische Isolation einzuführen. Ein weiterer Trend wurde bereits erwähnt: Upgrades im Feld. Um ein sicherheitskritisches Subsystem zu aktualisieren, muss ein Pfad vom Patch-Programmierer über das Netz in das zu aktualisierende Subsystem im Auto bestehen.

Ironischerweise ermöglicht gerade der Remote-Access-Pfad für Software Updates, Diagnostik und andere kritische Datenerfassungsfunktionen, dass Hacker vorhandene Schwachstellen in der Software ausnutzen können. Genau darin besteht das größte Sicherheitsrisiko für das Internet der Dinge. Auch hier kann eine hochsichere logische Trennung viele dieser Probleme lösen. „Hohe Sicherheit“ ist jedoch sehr selten in moderner Elektronik. Lediglich die US-Regierung hat eine hochsichere Software-Zertifizierung unter dem Sicherheitsstandard ISO 15408 Common Criteria für ein einziges Produkt vergeben: Green Hills Softwares Integrity-178B. Das Regierungsprogramm zur Förderung dieser hochsicheren Common-Criteria-Zertifizierung wurde wegen zu hoher Kosten und Terminüberschreitungen vor Jahren gestoppt. Automobilhersteller und Tier-1-Zulieferer müssen sich daher auf unabhängige Bewertungen von Sicherheitsberatern sowie auf die Erfahrung ihrer Zulieferer verlassen. Die Branche muss auch die Vertraulichkeit von Informationen im ADAS und in anderen intelligenten Subsystemen schützen, da diese über die Cloud zur weiteren Analyse, Ertragssteigerung usw. verteilt werden. Die Besitzer solcher Daten sollten eine Null-Vertrauen-Haltung einnehmen, mit der die Kontrolle der privaten Schlüssel zum Schutz der Informationen gewahrt bleibt. Eine SSL-Verbindung (oder andere Datenübertragungsprotokolle) ist jedenfalls keine Strategie für Datenschutz im Internet der Dinge. Dafür gab es 2014 zu viele SSL-Unzulänglichkeiten mit zahlreichen Ausfällen: POODLE, Heartbleed, Apples „goto-fail“-Fehler usw.

5. Hardware erst festlegen, wenn die Punkte 1 bis 4 erfüllt sind

Allzu oft werden unumkehrbare Hardware-Entscheidungen getroffen, ohne die oben genannten Aspekte in Betracht zu ziehen. FLOPS und Stücklisten dominieren weiterhin die Kaufentscheidungen und lassen System- und Software-Entwickler verzweifeln. Der Tag wird hoffentlich bald kommen, wenn bei der Wahl des ADAS-SoC auch die SoC-Sicherheitsfunktionen (TrustZone, ARM-Virtualisierungserweiterungen, MMUs, IOMMUs, geschützter On-Chip-Schlüsselspeicher, qualitative Zufallszahlengeneratoren, Debug-Funktionen wie Trace usw.), das Software-Ökosystem, das diese Funktionen unterstützt, sowie die SoC-Datenverarbeitungsleistung pro Dollar mit berücksichtigt werden.

Der Autor

Peter Hoogenboom
ist EMEA Engineering Manager am holländischen Standort von Green Hills Software mit über 30 Jahren Erfahrung in der Embedded-Software-Entwicklung: von Compilern über Debugger (1984), Echtzeitbetriebssysteme (1998), Debug Hardware (2000) bis zu Integrity RTOS Board Support Packages und sicheren Workstations. Seit 2008 verantwortet Peter Hoogenboom die Projekte für funktionale Sicherheit.