Folien zum Vortrag

physik.uni.erlangen.de

Folien zum Vortrag

Wenn das Auto selbst lenkt

Sicherheitskritische Software in

der Automobilindustrie

Dr. Alexander Mattausch

31.01.2013


Wenn das Auto selbst lenkt

Inhalt

• Vorstellung und Lebenslauf

• EB – Wer sind wir, was machen wir?

• Echtzeit-Betriebssysteme:

AUTOSAR – Automotive-Standard für Embedded Software

• Entwicklung sicherheitskritischer Systeme:

Was braucht man alles für den Sicherheitsnachweis?

• Physiker in der Software-Entwicklung?

© Elektrobit (EB), 2012 / Confidential 2


Lebenslauf

Informatik oder Physik?

Physik!

Warum?

• Allgemeinere Ausrichtung

• Grundlagen-orientierter

• Große Themenvielfalt

…und in die Informatik kann man

hinterher immer noch.

Studium

• Nebenfächer: Chemie/Informatik

• Auslandsaufenthalt: Norwich (UK)

• Seminare: Nichtlineare Optik und

Theoretische Festkörperphysik

• FSI, Fachschaft

• Diplomarbeit:

‒ Prof. Pankratov

‒ Dichtefunktionaltheorie

‒ Leerstellen-Defekte in Silizium

• Diplom: 1999

© Elektrobit (EB), 2012 / Confidential 3


Lebenslauf

Theoretische Festkörperphysik - SiC

• Promotion bei Prof. Pankratov

• Defekte und Diffusion in SiC

• Dichtefunktionaltheorie

‒ Migrationsbarrieren

‒ Ladungsniveaus

‒ Resonanzspektren

• Arbeitsumfeld

‒ SFB / Forschergruppe

‒ Internationale Konferenzen

‒ Viel Numerik auf (damals) großen

Computern

Phys. Rev. B 73, 161201 (2006).

• Promotion: 2005

© Elektrobit (EB), 2012 / Confidential 4


Lebenslauf

Theoretische Festkörperphysik - Graphen

• 2 weitere Jahre Post-Doc

• Thema: Graphen auf SiC

• Start: 2005 – ganz zu Beginn des

Graphen-Hypes

• Veröffentlichung in „Physical Review

Letters“ 2007

Glück braucht man manchmal auch…!

Phys. Rev. Lett. 99, 076802 (2007).

© Elektrobit (EB), 2012 / Confidential 5


Lebenslauf

Nebenjob: Freier c‘t-Autor

• 3 c‘t-Artikel über

‒ NFS (2000)

‒ NIS (2001)

‒ RPM (2005)

• Zweitverwertung des Admin-Wissens

vom Lehrstuhl-Netzwerk

• Erstkontakt…?

Eine kurze Anfrage per Mail!

Fragen kostet nichts!

© Elektrobit (EB), 2012 / Confidential 6


Lebenslauf

Uni oder Industrie?

Vorteile Uni

• Forschung und Lehre

• Freies Arbeiten

Nachteile Uni

• Befristete Verträge

• „Wanderjahre“

• „Alles-oder-Nichts“-Spiel

Vorteile Industrie

• Unbefristete Verträge bei i.d.R.

besserer Bezahlung

• Größere Stellenauswahl

Nachteile Industrie

• Mehr Stress

• Weniger Freiheiten

Uni so lange wie möglich, aber die Industrie hat gewonnen.

Entscheidungskriterien für den Job:

• Fachliches Interesse

• Arbeitsklima

© Elektrobit (EB), 2012 / Confidential 7


Vorstellung EB

Elektrobit Automotive GmbH

• Teil der finnischen Elektrobit Corporation (Wireless und Automotive)

• EB Automotive: Mehr als 1200 Mitarbeiter (ca. 700 in Erlangen)

• Als ich anfing (Mitte 2007): 550 Mitarbeiter

• Fächer sind bunt gemischt: Informatik, E-Technik, Mathematik, Physik…

• Gegründet 1988 als

• 14 Niederlassungen in 7 Ländern:

Deutschland, Finnland, Österreich, Frankreich, USA, Japan, China

• Kunden sind praktisch alle führenden Firmen der Automobilindustrie

© Elektrobit (EB), 2012 / Confidential 8


Vorstellung EB

Arbeitsbereiche bei EB Automotive

• Infotainment (HMI)

‒ EB GUIDE

‒ Benutzeroberflächen, Spracherkennung/-ausgabe…

• Navigation (NAVI)

‒ EB street director

‒ „White label“ On-/Offboard-Navigationslösung

• Fahrerassistenzsysteme (DA)

‒ EB ADTF

‒ Assistenzsysteme und Entwicklungswerkzeuge

• Steuergeräte (ECU)

‒ EB tresos

‒ Basissoftware und Tools für Steuergeräte aller Art

© Elektrobit (EB), 2012 / Confidential 9


Vorstellung EB

Arbeitsklima

• Offene Türen und flache Hierarchien

• Wir sind alle „per Du“

• Flexible Arbeitszeiten

• Motivierte Kollegen

• Genaue Arbeitszeiterfassung

• Internationales Flair

• Freie Getränke

• Admin-Rechte auf dem Computer

• Keine Großraumbüros

• Team-Events, Schafkopf-Turniere, gute Stimmung…

…fast wie an der Uni!

© Elektrobit (EB), 2012 / Confidential 11


AUTOSAR – Automotive Embedded Software

Die AUTOSAR Software-Architektur

http://www.autosar.org

© Elektrobit (EB), 2012 / Confidential 12


AUTOSAR – Automotive Embedded Software

Echtzeit-Betriebssysteme: OSEK

• „Echtzeit“ bedeutet:

‒ Antwortzeiten im unteren µs-Bereich

‒ Sowohl periodische als auch ereignisgesteuerte Prozess-Aktivierung

• Der OSEK-Standard

‒ Teil der AUTOSAR-Spezifikation

‒ Statisches Betriebssystem

• Alle Prozesse sind zur Kompilier-Zeit bekannt

• Keine dynamische Speicherverwaltung

‒ Prioritätsgesteuertes Scheduling

‒ Betriebssystem-Objekte:

• Tasks, Interrupts, Alarme und Timer, Counter, Events, selektive Locks

Das OS muss ein vorhersagbares System ermöglichen!

© Elektrobit (EB), 2012 / Confidential ISO 17356, http://www.osek-vdx.org 13


AUTOSAR – Automotive Embedded Software

Unsere Betriebssysteme

• ProOSEK: ältestes System, seit 1997, reines OSEK

• EB tresos AutoCore OS: OSEK mit AUTOSAR-Erweiterungen

• EB tresos Safety OS: AUTOSAR für sicherheitskritische Systeme (SIL-3/ASIL-D)

• Jeweils bestehend aus zwei Teilen:

‒ Konfigurationsabhängiger, generierter Code

‒ Statischer, konfigurationsunabhängiger Code

• Prozessor-Architekturen (SoC‘s):

‒ 32 Bit: PowerPC, Infineon TriCore, ARM Cortex-R/A, Renesas V850, …

‒ 16 Bit: Freescale S12X, Infineon XC2000, …

‒ Hohe Portabilität der Betriebssysteme!

© Elektrobit (EB), 2012 / Confidential 14


AUTOSAR – Automotive Embedded Software

Der Arbeitsalltag in der OS-Entwicklung… 1

• Portierungen auf neue CPU-Derivate und Architekturen (ab 2007)

‒ 16-Bitter: Freescale S12X, Infineon XC2000

‒ 32-Bitter: PowerPC

‒ Support: letzter Anlaufpunkt bei technischen Problemen

• Entwicklung von AUTOSAR-Modulen und Eclipse-Plugins (2008)

‒ z.B. Betriebssystem-Generator, CanTP-Treiber

‒ Programmiersprachen: Java, C, Assembler, (Perl, Make, Bash, XML,…)

• Projektleitungsaufgaben: ProOSEK, AutoCore OS (2009)

‒ Abstimmung mit Verkauf, Kunden, Produktmanagement, anderen Entwicklungsteams

• Start der Sicherheitsentwicklung: Safety OS (seit 2010)

‒ Erstellung des technischen Konzepts

‒ Aufsetzen der Prozesse für die Entwicklung sicherheitskritischer Software

1

Aus meiner persönlichen Sicht…

© Elektrobit (EB), 2012 / Confidential 15


Sicherheitskritische Systeme

Beispiele sicherheitskritischer Steuergeräte

• Servolenkung

• Airbag

• ESP/ABS

• Elektronisches Gaspedal

• Bremsassistenten

• Automatischer Tempomat

• Aktive Spurhalte-Assistenten

• Batterie-Ladekontrolle

• …

Außerhalb der Automobilindustrie:

• Industriesteuerungen

• Motorsteuerungen

• Landwirtschaft/Baumaschinen

• Medizintechnik

• …

Immer mehr sicherheitskritische Steuergeräte

werden von Software kontrolliert!

© Elektrobit (EB), 2012 / Confidential 16


Safety Assessment – Sicherheitseigenschaften

Was ist „Safety“?

Definitionen:

• „Safety“ bedeutet die Abwesenheit

unangemessener Risiken.

(Bekannter Begriff: „Restrisiko“)

• „Unangemessenes“ Risiko: gemäß

gesellschaftlicher und moralischer

Werte nicht akzeptables Risiko

• Risiko: Kombination aus

Auftrittswahrscheinlichkeit und

Schwere eines Schadens oder

Verletzung

Eigenschaften sicherer Systeme:

• Fehlertolerant (durch Überwachung

o.ä.)

• Unter allen Umständen

wohldefiniertes Verhalten

• Sicherer Zustand im Fehlerfall

‒ „Fail safe“: Abschalten

‒ „Fail operational“: Notbetrieb muss

weiterlaufen

Philosophie des Risikomanagements:

Vortrag von Rafaela Hillerbrand, SS2013

© Elektrobit (EB), 2012 / Confidential 17


Sicherheitskritische Systeme

Was braucht man alles für sichere Software?

• Wichtig:

Safety ≠ Security

• Folgende Punkte sind relevant für

die Entwicklung:

‒ „Unterstützende“ Prozesse

‒ Technische Dokumentation

‒ Sicherheits-Eigenschaften

• All dies wird in einem Safety

Assessment geprüft

Sicherheit lässt sich nicht nachträglich integrieren!

© Elektrobit (EB), 2012 / Confidential 18


Safety Assessment – Unterstützende Prozesse

Software-Entwicklungsprozesse

© Elektrobit (EB), 2012 / Confidential 19


Safety Assessment – Unterstützende Prozesse

Software-Entwicklung: Einfachste Methode

Hack

Ship

© Elektrobit (EB), 2012 / Confidential 20


Safety Assessment – Unterstützende Prozesse

Software-Entwicklung: Bessere Methode

Hack

Test

Ship

© Elektrobit (EB), 2012 / Confidential 21


Safety Assessment – Unterstützende Prozesse

Software-Entwicklung: Noch bessere Methode

Specify

Test

Ship

Hack

© Elektrobit (EB), 2012 / Confidential 22


Safety Assessment – Unterstützende Prozesse

Software-Entwicklung: Das V-Modell

Requirements

„Was?“

Tracing

Integration Tests

„Ist alles da?“

Tracing

Design

„Wie?“, „Warum?“

Tracing

Analyse

Unit Tests

„Funktioniert‘s?“

Tracing

Coverage

Code

© Elektrobit (EB), 2012 / Confidential 23


Safety Assessment – Unterstützende Prozesse

Umsetzung: Iterativer Entwicklungsprozess

• Aufteilen des Gesamtsystems in einzelne kleine Module

• Kleine Teams, die für ihr gesamtes „V“ verantwortlich sind

• Iterative Entwicklung mit ca. 4-Wochen-Zyklen

• Letzte Iteration muss in sich konsistent sein

• Vorteile:

‒ Schnelles Feedback, ob Spezifikation funktioniert

‒ Abwechslungsreicheres Arbeiten

‒ Schnelle Anpassung des Funktionsumfangs möglich

‒ i.d.R. pünktliche Auslieferungen

© Elektrobit (EB), 2012 / Confidential 24


Safety Assessment – Unterstützende Prozesse

Welche Hilfsprozesse gibt es?

• Configuration Management

‒ Was ist in einem Release enthalten?

‒ Welche Versionen gibt es?

• Change Management

‒ Wie ändere ich die Software?

‒ Funktioniert sie noch?

• Project Management

‒ Wer macht was wann?

‒ Schaffen wir es rechtzeitig?

‒ Was brauchen die anderen Teams?

© Elektrobit (EB), 2012 / Confidential 25


Safety Assessment – Technische Dokumente

Wie komme ich an „Safety Requirements“?

Beispiel: Fiktive Servolenkung

• Wenige „Safety Goals“ beschreiben

die übergeordneten Sicherheitsziele.

• Funktionale und technische

Requirements beschreiben die

Umsetzung im System

• Software Requirements beschreiben

die Anforderungen an den Software-

Sicherheitsmechanismus.

Safety Goal

Functional

Requirements

Technical

Requirements

• Die Lenkung darf nicht selbst

lenken.

• Die Lenkung darf nicht blockieren.

• Der Servomotor muss den

Lenkbewegungen exakt folgen.

• Eine Software-Komponente muss

den Zustand der Lenkung

kontinuierlich überwachen.

⇒ Ergibt einen großen Requirements-

Baum

⇒ Tracing hilft bei der Analyse!

Software

Requirements

• Das Betriebssystem muss den

Überwachungsprozess aktivieren.

© Elektrobit (EB), 2012 / Confidential 26


Safety Assessment – Technische Dokumente

Design – die Anfänge

© Elektrobit (EB), 2012 / Confidential 27


Safety Assessment – Technische Dokumente

Design – im fertigen Dokument

• Beschreibungssprachen

‒ Informeller Text nach vorgegebenem

Schema

‒ UML (semiformale Methode)

cmp Safety_OS_components

«thread»

Hook

{0..4}

«thread»

OS Application::Task

{0..*}

OS Application

OS Application::Application Data:

MemProtBoundary::Application Data

«thread»

OS Application::ISR

{0..*}

{0..*}

• Beschreibt…

‒ Enthaltene Komponenten

‒ Schnittstellen

‒ Interne Abläufe

MK_OS

Hook Data :

LocalData

Stack :LocalData

AUTOSAR_OS

AUTOSAR_OS

«delegate»

SafetyOS_API

«delegate»

Task Data :LocalData

Stack :LocalData

AUTOSAR_OS

QM-OS_delegated

Safety OS

ISR Data :LocalData

Stack :LocalData

AUTOSAR_OS

Microkernel

MK_OS

«thread»

QM-OS

MK Data :LocalData

Stack :LocalData

QM-OS

OS Data :LocalData

Stack :LocalData

A

© Elektrobit (EB), 2012 / Confidential 28


Safety Assessment – Technische Dokumente

Gute Designs sind eine Kunst

• Es gibt keine Software ohne Design

‒ Gutes oder schlechtes Design

‒ Aufgeschriebenes oder nicht

aufgeschriebenes Design

• Die Fähigkeit, gute Designs zu

erstellen, unterscheidet den

Software-Architekten vom

Programmierer!

• Sicherheitskritische Software

benötigt ein sehr gutes Design.

© Elektrobit (EB), 2012 / Confidential 29


Safety Assessment – Sicherheitseigenschaften

Safety-Klassifizierung nach Risiko

• Klassifizierung der Safety-

Eigenschaften nach:

‒ Schadenshöhe

‒ Eintrittswahrscheinlichkeit

‒ Kontrollierbarkeit

• Normen

‒ IEC 61508

Safety Integrity Levels (SIL):

Industrietechnik, Medizintechnik,

Kerntechnik, …

jedoch nicht: Luftfahrt (andere Norm)

‒ ISO 26262

Automotive SIL:

Automobil-Industrie

ASIL SIL

4

D

3

C

2

B

A 1

Kernkraftwerke

Mehrere Tote

Schwere Verletzungen

Leichte Verletzungen

Nicht sicherheitskritisch

© Elektrobit (EB), 2012 / Confidential 30


Safety Assessment – Sicherheitseigenschaften

Safety-Analyse – „Warum ist das alles sicher?“

• Safety-Analyse unterscheidet

sicherheitskritische von normaler

Software-Entwicklung

Unterscheidung von „Fehlern“:

• Fault: Ursache eines Fehlers

• Error: Fehlverhalten des Systems

• Failure: Ausfall

• Safety-Analyse ist das Aufstellen und

Untersuchen von Fehlerszenarien.

Wann führt man die Analyse durch?

• Zu Beginn der Entwicklung

‒ Erstellen eines sicheren Konzepts

• Während der Entwicklung

‒ Kontinuierliches Hinterfragen

• Am Ende der Entwicklung

‒ Dokumentation des Systemverhaltens

⇒ Alles so klein und einfach wie

möglich!

⇒ Prozesse alleine reichen nicht!

Man weiß unter allen Umständen, wie sich das System verhält!

© Elektrobit (EB), 2012 / Confidential 31


Safety Assessment

Inhalt eines Safety Assessments

• Fokus auf Safety-Eigenschaften

‒ Technisches Konzept

‒ Qualität der Umsetzung

‒ Verifikation

• Persönliches Assessment der

Entwickler

‒ Fachliche Kompetenz

‒ Integrität 1

• Prozesse

‒ Umgang mit Fehlern

‒ Behandlung von Änderungen

Ablauf

• Mehrtägiges Frage-Antwort-Spiel mit

dem Assessor

• Dokumenten-Review

Ergebnis

• Assessment-Report

• Zertifikat

Gute Argumentation ist der Schlüssel zum Erfolg!

1

Taz Daughtry, Integrity in Software Process Improvement, EuroSPI 2 2012

http://2012.eurospi.net/images/Conference_Pictures/key_note_2.mp4

© Elektrobit (EB), 2012 / Confidential 32


Fazit

Physiker in der Software-Entwicklung?

• Professionelle Software-Entwicklung

ist mehr als nur Programmieren

• Benötigte Fähigkeiten:

‒ Abstraktionsvermögen

‒ Logisches Denken

‒ Gute Argumentationsfähigkeit

‒ Teamfähigkeit

• Programmiererfahrung ist natürlich

trotzdem nötig…

• Zukunftsaussichten

‒ Sicherheitskritische Funktionen

werden immer mehr in Software

implementiert werden

‒ Auch außerhalb der Auto-Industrie

wird mehr sicherheitskritische

Software eingesetzt werden

⇒ Der Markt wächst!

Ja, da die Anforderungen immer breiter werden!

© Elektrobit (EB), 2012 / Confidential 33


Vielen Dank für Eure

Aufmerksamkeit!

Kontakt:

Automotive.elektrobit.com

Alexander.Mattausch@elektrobit.com

Ein besonderer Dank geht an Geek & Poke: http://www.geek-and-poke.com

Lizenz: Creative Commons - http://creativecommons.org/licenses/by/3.0/deed.en_US

Weitere Magazine dieses Users
Ähnliche Magazine