AUTOMOBIL-ELEKTRONIK: In welchen Bereichen ist Green Hills hauptsächlich aktiv?

Jeremy Flann: Green Hills Software begann im Jahr 1982 als Entwicklungsfirma für Embedded-Software. Damals lag der Fokus auf Compilern und später auf Debugging- und Entwicklungsumgebungen. 1997 stiegen wir in den Markt für Betriebssysteme ein, mit dem Ziel, ein Betriebssystem anzubieten, das speziell darauf ausgerichtet ist, die Anforderungen in punkto Safety und Security zu erfüllen. Vor einiger Zeit haben wir unsere Security-Aktivitäten ausgedehnt und hierfür unser Tochterunternehmen „INTEGRITY Security Services“ gegründet.

Wie laufen die Geschäfte bei Green Hills Software?

Jeremy Flann: Das Business läuft sehr gut. Die Firma wächst weiterhin konservativ und konsistent. Unsere Expansion finanzieren wir selbst, und wir haben unsere Ressourcen in den europäischen Engineering-Teams in den letzten beiden Jahren mehr als verdoppelt. Viele der Top-10-Automotive-OEMs sind mit unseren Produkten und Dienstleistungen in Serie: mit optimierten Compilierungen von Powertrain-Code oder adaptiven Safety-Systemen bis hin zur Konsolidierung multipler Funktionen inklusive Virtualisierung von Embedded-Linux oder -Android in Kombination mit Safety-Systemen auf komplexen Multicore-Prozessoren für Bedienistrumente und Infotainmentsystem oder Zentralrechnern. Ein großer Teil unseres Wachstums im Automotive-Bereich kam in diesem Jahr durch unsere Securitylösungen. Wir arbeiten mit den meisten OEMs an der Entwicklung neuer Systeme, oftmals über deren Tier-1.

Jeremy Flann (Mitte) und Jörg Zimmer (rechts) im Gespräch mit AUTOMOBIL-ELEKTRONIK-Chefredakteur Alfred Vollmer: Security muss vom ersten Tag an eingebaut sein, denn man kann Security nicht nachträglich einbauen.

Jeremy Flann (Mitte) und Jörg Zimmer (rechts) im Gespräch mit AUTOMOBIL-ELEKTRONIK-Chefredakteur Alfred Vollmer: Security muss vom ersten Tag an eingebaut sein, denn man kann Security nicht nachträglich einbauen. Alfred Vollmer

Wie sprechen Sie das Thema Safety und Security auf System-ebene an?

Jeremy Flann: Ich bevorzuge es, von belegbarer Funktionalität zu sprechen. Wir versuchen, es so auszudrücken: „Wenn dieser Code genau so, und nur so, seinen Dienst verrichten muss, dann muss man nachweisen, dass er auch genau in dieser Art und Weise arbeitet.” Es gibt zahlreiche Techniken, die wir im Laufe der Jahre eingeführt haben und bei denen wir auch Pionierarbeitet geleistet haben, um dies zu ermöglichen.
Darüber hinaus haben wir eine Suite entwickelt, die ich „Functional Safety Middleware“ nenne, und die unseren Kunden ganz wesentlich dabei hilft, ihre Applikationen zu zertifizieren.

Wie entstand eigentlich Ihr Betriebssystem?

Jörg Zimmer: Mitte der 90er Jahre wurde es für uns offensichtlich, dass es einen Bedarf für Betriebssysteme geben wird, die safe und secure sind. Es war uns wichtig, dass sich dies auch nachweisen lässt – und zwar nicht nur von Green Hills sondern auch von externen Gutachtern und Zertifizierungsstellen. Das ist eines der ganz wesentlichen Unterscheidungsmerkmale zwischen uns und anderen Anbietern von Betriebssystemen. Dies war auch eine der Grundvorraussetzungen bei der Architektur des Betriebssystems INTEGRITY.

Garantiert denn ein als „safe and secure“ gelabeltes Betriebssystem auch die Funktions- und Datensicherheit eines Systems?

Jörg Zimmer: „Mit dem exponentiellen Anstieg der Anzahl der Codezeilen im Fahrzeug können auch viel mehr Programmierfehler auftreten, die dann als Schwachstelle ausgenutzt werden können.“

Jörg Zimmer: „Mit dem exponentiellen Anstieg der Anzahl der Codezeilen im Fahrzeug können auch viel mehr Programmierfehler auftreten, die dann als Schwachstelle ausgenutzt werden können.“ Alfred Vollmer

Jörg Zimmer: Es ist wichtig, das richtige Betriebssystem auszuwählen und die passenden Tools, die bereits den Zertifizierungsprozess durchlaufen haben, denn das senkt das Kundenrisiko in beachtlichem Umfang. Aber letztendlich hängt auch vieles vom verwendeten Entwicklungsprozess und den Methodiken ab. Noch bevor man die erste Zeile Code schreibt, muss man sicherstellen können, dass man alles auch testen, belegen und dokumentieren kann. Dies erfordert eine entsprechende Systemarchitektur und und einen geeigneten Entwicklungsprozess.

Wie unterstützen Sie Safety-Standards und ISO26262?

Jörg Zimmer: Jenseits der Avionik, für die wir im Jahr 2002 zertifiziert wurden, erhielten wir 2007 unsere erste Zertifizierung für INTEGRITY nach IEC61508; die ISO26262 existierte zu diesem Zeitpunkt noch gar nicht. Inzwischen ist natürlich auch INTEGRITY nach der ISO26262 zertifiziert. Aber zu einer Zertifizierung gehört mehr als nur das Betriebssystem. So ist unser Compiler, der Bestandteil der Entwicklungsumgebung MULTI ist, nach der ISO 26262:2011 ASIL D qualifiziert. Darüber hinaus unterstützen wir unsere Kunden dabei, ihr eigenes Produkt gemäß ISO 26262 zu zertifizieren.

Warum sehen Sie Ihr Unternehmen als eine Art Pionier im Bereich Embedded-Software an?

Jeremy Flann: Wir haben eine Historie von Industry-Firsts: Mit dem ersten 32-Bit-Embedded-Compiler in 1983, der ersten Entwicklungsumgebung in 1993, dem ersten kommerziellen partitionierenden Echtzeitbetriebssystem in 1997 und den ersten Backwards-in-Time-Debuggern in 2003 beginnt die Liste. Für unsere Kunden sind oft auch unterschiedliche Metriken von Bedeutung; für einige ist die Größe des Codes von kritischer Bedeutung, für andere ist die Performance das Maß der Dinge. Allen gemeinsam ist der Druck in punkto Entwicklungsdauer und Produktionskosten, welche unsere Produkte und Dienstleistungen positiv beeinflussen können.

Welche Bedeutung hat Security für die Automotive-Industrie?

Jeremy Flann: Während der letzten Jahre, besonders seitdem Hacker die Risiken im Bereich Automotive-Security aufgezeigt haben, wurde die Branche äußerst sensitiv in punkto Security und wie man sie umsetzt; die Connectivity über die Luftschnittstelle verstärkt diesen Trend weiter. Die OEMs müssen sicherstellen, dass ihr Fahrzeug vor bösartigen Attacken geschützt ist, denn ansonsten könnte es sich um eine Frage von Leben oder Tod handeln und den Ruf der Hersteller schädigen.
Elektronik im Auto besteht aus einem komplexen Netzwerk von Computern, auf denen immer mehr Software läuft. Security muss dabei vom ersten Tag an eingebaut sein, denn man kann Security nicht nachträglich einbauen; das haben die Bereiche Desktop- und Enterprise-Computer bereits bestätigt.

Jeremy Flann: „Safety ist bestens verstanden, aber Security benötigt den Fokus der Aufmerksamkeit.“

Jeremy Flann: „Safety ist bestens verstanden, aber Security benötigt den Fokus der Aufmerksamkeit.“ Alfred Vollmer

Wie können OEMs und Tier-1s Security implementieren?

Jörg Zimmer: In punkto Safety- und Security-Anforderungen im Automobilbereich ist es elementar, über die Trennung von Komponenten nachzudenken. Das gleiche Prinzip, das in der Luftfahrt auch für Security sorgt, kommt somit auch im Automobilbereich zum Einsatz. Hierfür gibt es eine spezielle Variante des Betriebssystems, die auf die automobilen Anforderungen zugeschnitten ist.
Wir stellen unseren Kunden mit unserem Betriebssystem und dem Board-Support-Package eine solide Basis zur Verfügung, so dass sie ihre Produkte entwickeln und sich vom Wettbewerb differenzieren können.
Jeremy Flann: Ein sehr wichtiger Aspekt ist das Device Live-Cycle-Management, das mit den kryptographischen Schlüsseln beginnt. In einem Steuergerät benötigt man Schlüssel, die zum Zeitpunkt der Herstellung sicher eingebunden sind, so dass jedes einzelne Device seinen eigenen Schlüsselsatz bekommt. Hierfür ist es erforderlich, Schlüssel mit hoher Qualität zu erzeugen, während der Fertigung zu injizieren und sicher zu verwalten. Für die ECU gibt es dann auch noch verschiedene Security-Middleware.
Es gibt viele Möglichkeiten, ein Fahrzeug anzugreifen. Deshalb muss man das Gesamtbild betrachten und Security so implementiert haben, dass sowohl das Image der Marke als auch die Menschen, die in den Fahrzeugen unterwegs sind, vor Security-Angriffen sicher sind.

Wie verändern sich Systeme innerhalb des Fahrzeugs? Macht sie das stärker verwundbar?

Jörg Zimmer: Es gab einen großen Anstieg bei der Nutzung von Embedded-Linux und Android, besonders in den Infotainment-Systemen. So steht dem Fahrer eine vertraute Benutzerumgebung zur Verfügung. Es gibt aber in den großen, offenen Betriebssystemen viele Sicherheitslücken beziehungsweise Schwachstellen, die für Angriffe genutzt werden können.
Mit der Nutzung des INTEGRITY Multivisor – unsere Hochleistungs-Virtualisierung für eingebettete Systeme – kann man Linux oder Android in seinem eigenen separaten Bereich ablaufen lassen, und das wie bei INTEGRITY: safe und secure abgetrennt von anderen Applikationen auf denselben Cores.
Sichergestellt durch die garantierte Separierung kann man die beiden Welten verbinden: Die Anforderungen an Safety durch das Echtzeitbetriebsystem INTEGRITY sowie an Connectivity und User-Experience unter Verwendung von Linux oder Android. Wir versuchen nicht, Linux oder Android zu ersetzen. Wir kennen deren Stärken und Schwächen, aber wir wissen auch, wie man das Fahrzeug vor deren verwundbaren Stellen schützt und den Schaden minimiert.

Es ist bestens bekannt, wie man ein Safety-System definiert, aber wie definiert man ein Security-System?

Jeremy Flann (links, neben Jörg Zimmer): „Ein sehr wichtiger Aspekt ist das Device Live-Cycle-Management, das mit den kryptographischen Schlüsseln beginnt.“

Jeremy Flann (links, neben Jörg Zimmer): „Ein sehr wichtiger Aspekt ist das Device Live-Cycle-Management, das mit den kryptographischen Schlüsseln beginnt.“ Alfred Vollmer

Jeremy Flann: Wir haben ja schon über unsere Security-Herkunft und die Tatsache gesprochen, dass das Betriebssystem INTEGRITY-178 das erste und einzige kommerziell verfügbare Betriebssystem war, das nach vielen Jahren genauer Überprüfung die Zertifizierung gemäß EAL6+/High Robustness Common Criteria erhielt. Common Criteria ist eine internationale Zertifizierung für Computer-Security, kein Standard für Automotive-Security. Jetzt brauchen wir einen systemweiten Standard für Automotive-Security.
In einem Automotive-Safety-System sagt man „hier ist mein Anwendungsfall“. Aus diesem Use-Case ergeben sich diese Safety-Cases. Das gleiche müssen wir mit der Security machen: Hier ist mein Use-Case, aus dem ich meine Security-Cases ableite; hier sind all die Orte, wo jemand versuchen kann, sich Zugang zu verschaffen. Durch eine systematische Analyse des Gesamtsystems und seiner Umgebung kann ich die Security Cases bewerten und Strategien zur Vermeidung oder Abschwächung umsetzen.
Safety ist bestens verstanden, aber Security benötigt den Fokus der Aufmerksamkeit. Allerdings erzielt man nur mit einer End-to-End-Architektur und dem dazugehörigen Prozess auch Security. Mit einem einmaligen nachträglichen Einfall lässt sich da nichts machen.
Bei der Safety muss man annehmen, dass eine ECU im Fahrzeug ausfällt – vielleicht nach einer langen Zeitspanne, aber sie wird letztendlich versagen. Wenn sie ausfällt, muss man sicherstellen, dass das Fahrzeug dann in einen für die Insassen sicheren Zustand zurückfällt. Bei der Security gibt es keine sichere Rückfallebene: Wenn etwas gehackt ist, dann ist es gehackt. Man kann die Auswirkungen eines Angriffs mithilfe der Separierung begrenzen, aber die beste Methode besteht darin, dafür zu sorgen, dass der Angreifer überhaupt keinen Zugang bekommt und das System in einer unzulässigen Weise verändert.

Das bringt uns zum Thema Car-to-Car-Kommunikation. Welche Aktivitäten haben Sie im C2C-Markt?

Jeremy Flann: Wir sind aktiv in die Entwicklung der C2C-Kommunikation involviert: sowohl in den USA als auch in Europa, und weltweit stellen wir Safety- und Security-Lösungen für Steuerungs-Elektroniken und Public-Key-Infrastruktur-Beglaubigungen zur Verfügung.
Wir arbeiten mit der Automobilindustrie, damit die Unternehmen vorbereitet sind, wenn das DOT (US Department of Transportation), also das Verkehrsministerium der USA, bald fordert, dass alle neuen Fahrzeuge mit einem Transponder ausgerüstet sein müssen, der einfache Safety-Nachrichten über eine Kurzstrecken-Funkverbindung mit einer Reichweite von bis zu 1000 Fuß (etwa 300 m) aussendet. Das ADAS wertet empfangene Nachrichten aus, um so die Safety des Fahrzeugs zu erhöhen. INTEGRITY Security Services ist die Automotive-Root-Zertifizierungs-Autorität und stellt digitale Produktions-Zertifikate für V2x und C2x zur Verfügung.

Ist die zunehmende Komplexität und der immer größer werdende Software-Anteil in Fahrzeugen auch eine potenzielle Gefahr für Safety und Security?

Jörg Zimmer: Absolut! Mit dem exponentiellen Anstieg der Anzahl der Codezeilen im Fahrzeug, die nötig sind, um all diese neueren Funktionalitäten zu ermöglichen, können auch viel mehr Programmierfehler auftreten, die dann als Schwachstelle ausgenutzt werden können. Das bringt uns zurück zum Thema Software-Entwicklungsprozess und Eigenschaften der Entwicklungsumgebung, Fehler zügig und effizient zu identifizieren und zu eliminieren und auch die Software zu optimieren; genau das ist seit über 30 Jahren unsere Expertise.

In welchen anderen Bereichen arbeitet Green Hills?

Jeremy Flann: Auch die Produktivität der Entwickler ist wichtig. Betrachtet man den globalen Markt der Softwareentwickler, dann sind die Gehälter in Europa nicht gerade die niedrigsten. Diese Ingenieure konkurrieren mit Ingenieuren in Ländern, wo die Gehälter gerade einmal ein Drittel und weniger betragen. Das bedeutet, dass unsere europäischen Ingenieure eine mindestens dreimal so hohe Produktivität liefern müssen. Ihre Entscheidungsfindung muss jedes Mal schnell und exakt sein.
Im Laufe der Zeit haben wir mehrere Werkzeuge, Prozesse und Techniken entwickelt, die uns intern eine drei- bis vierfache Produktivitätsverbesserung in unserem internen Software-Entwicklungsprozess gegeben haben. Wir nutzen natürlich unsere eigenen Werkzeuge, um unsere Produkte zu entwickelt. In diesem Jahr haben wir begonnen, dies einigen weltweiten Schlüsselkunden zu zeigen und herauszufinden, ob sie genauso von den Produktivitätssteigerungen profitieren können wie wir intern. Das kann die auf den Unternehmen ruhende Last in punkto Personalfindung und Training beachtlich verringern, und gleichzeitig können sie Produkte früher auf den Markt bringen.

Wie erzielen Sie diesen Anstieg der Produktivität?

Jeremy Flann: Eines der Features in unserem Ansatz ist die Hilfe bei Integration, Test und Debugging von Code, der vielleicht von unterschiedlichen Anbietern oder aus verschiedenen geographischen Regionen stammt. Wenn jemand an einem Ort, zum Beispiel in Deutschland, einen Fehler findet, dann hilft das Werkzeug ihm dabei, dies zurück an die Person zu kommunizieren, die ursprünglich den Code geschrieben hat – und zwar in einem garantiert reproduzierbaren Format. So erhält der Entwickler einen Fehler, den er schnell beseitigen kann. Wir sprechen daher davon, dass wir ihm die Fehler auf einem Silbertablett servieren können.

Was denken Sie über den Kongress „Fortschritte in der Automobil-Elektronik“ in Ludwigsburg?

Jörg Zimmer: Die Leute, mit denen ich in Ludwigsburg gesprochen habe, sind absolute Schlüsselpersonen in der Automotive-Branche. Mir gefällt an dieser Konferenz, dass man dort Menschen trifft, die die Richtung der Branche festlegen. Was ich aber an Ludwigsburg wirklich liebe, ist die Tatsache, Leute zu treffen, die wir kennen; aber wir treffen sie jenseits des normalen Geschehens, so dass wir ohne Agenda einmal über wichtige Branchentrends und Strömungen sprechen können. Außerdem gibt es dort immer eine offene und nützliche Diskussion.