Folien zum Vortrag
Folien zum Vortrag
Folien zum Vortrag
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Wenn das Auto selbst lenkt<br />
Sicherheitskritische Software in<br />
der Automobilindustrie<br />
Dr. Alexander Mattausch<br />
31.01.2013
Wenn das Auto selbst lenkt<br />
Inhalt<br />
• Vorstellung und Lebenslauf<br />
• EB – Wer sind wir, was machen wir?<br />
• Echtzeit-Betriebssysteme:<br />
AUTOSAR – Automotive-Standard für Embedded Software<br />
• Entwicklung sicherheitskritischer Systeme:<br />
Was braucht man alles für den Sicherheitsnachweis?<br />
• Physiker in der Software-Entwicklung?<br />
© Elektrobit (EB), 2012 / Confidential 2
Lebenslauf<br />
Informatik oder Physik?<br />
Physik!<br />
Warum?<br />
• Allgemeinere Ausrichtung<br />
• Grundlagen-orientierter<br />
• Große Themenvielfalt<br />
…und in die Informatik kann man<br />
hinterher immer noch.<br />
Studium<br />
• Nebenfächer: Chemie/Informatik<br />
• Auslandsaufenthalt: Norwich (UK)<br />
• Seminare: Nichtlineare Optik und<br />
Theoretische Festkörperphysik<br />
• FSI, Fachschaft<br />
• Diplomarbeit:<br />
‒ Prof. Pankratov<br />
‒ Dichtefunktionaltheorie<br />
‒ Leerstellen-Defekte in Silizium<br />
• Diplom: 1999<br />
© Elektrobit (EB), 2012 / Confidential 3
Lebenslauf<br />
Theoretische Festkörperphysik - SiC<br />
• Promotion bei Prof. Pankratov<br />
• Defekte und Diffusion in SiC<br />
• Dichtefunktionaltheorie<br />
‒ Migrationsbarrieren<br />
‒ Ladungsniveaus<br />
‒ Resonanzspektren<br />
• Arbeitsumfeld<br />
‒ SFB / Forschergruppe<br />
‒ Internationale Konferenzen<br />
‒ Viel Numerik auf (damals) großen<br />
Computern<br />
Phys. Rev. B 73, 161201 (2006).<br />
• Promotion: 2005<br />
© Elektrobit (EB), 2012 / Confidential 4
Lebenslauf<br />
Theoretische Festkörperphysik - Graphen<br />
• 2 weitere Jahre Post-Doc<br />
• Thema: Graphen auf SiC<br />
• Start: 2005 – ganz zu Beginn des<br />
Graphen-Hypes<br />
• Veröffentlichung in „Physical Review<br />
Letters“ 2007<br />
Glück braucht man manchmal auch…!<br />
Phys. Rev. Lett. 99, 076802 (2007).<br />
© Elektrobit (EB), 2012 / Confidential 5
Lebenslauf<br />
Nebenjob: Freier c‘t-Autor<br />
• 3 c‘t-Artikel über<br />
‒ NFS (2000)<br />
‒ NIS (2001)<br />
‒ RPM (2005)<br />
• Zweitverwertung des Admin-Wissens<br />
vom Lehrstuhl-Netzwerk<br />
• Erstkontakt…?<br />
Eine kurze Anfrage per Mail!<br />
Fragen kostet nichts!<br />
© Elektrobit (EB), 2012 / Confidential 6
Lebenslauf<br />
Uni oder Industrie?<br />
Vorteile Uni<br />
• Forschung und Lehre<br />
• Freies Arbeiten<br />
Nachteile Uni<br />
• Befristete Verträge<br />
• „Wanderjahre“<br />
• „Alles-oder-Nichts“-Spiel<br />
Vorteile Industrie<br />
• Unbefristete Verträge bei i.d.R.<br />
besserer Bezahlung<br />
• Größere Stellenauswahl<br />
Nachteile Industrie<br />
• Mehr Stress<br />
• Weniger Freiheiten<br />
Uni so lange wie möglich, aber die Industrie hat gewonnen.<br />
Entscheidungskriterien für den Job:<br />
• Fachliches Interesse<br />
• Arbeitsklima<br />
© Elektrobit (EB), 2012 / Confidential 7
Vorstellung EB<br />
Elektrobit Automotive GmbH<br />
• Teil der finnischen Elektrobit Corporation (Wireless und Automotive)<br />
• EB Automotive: Mehr als 1200 Mitarbeiter (ca. 700 in Erlangen)<br />
• Als ich anfing (Mitte 2007): 550 Mitarbeiter<br />
• Fächer sind bunt gemischt: Informatik, E-Technik, Mathematik, Physik…<br />
• Gegründet 1988 als<br />
• 14 Niederlassungen in 7 Ländern:<br />
Deutschland, Finnland, Österreich, Frankreich, USA, Japan, China<br />
• Kunden sind praktisch alle führenden Firmen der Automobilindustrie<br />
© Elektrobit (EB), 2012 / Confidential 8
Vorstellung EB<br />
Arbeitsbereiche bei EB Automotive<br />
• Infotainment (HMI)<br />
‒ EB GUIDE<br />
‒ Benutzeroberflächen, Spracherkennung/-ausgabe…<br />
• Navigation (NAVI)<br />
‒ EB street director<br />
‒ „White label“ On-/Offboard-Navigationslösung<br />
• Fahrerassistenzsysteme (DA)<br />
‒ EB ADTF<br />
‒ Assistenzsysteme und Entwicklungswerkzeuge<br />
• Steuergeräte (ECU)<br />
‒ EB tresos<br />
‒ Basissoftware und Tools für Steuergeräte aller Art<br />
© Elektrobit (EB), 2012 / Confidential 9
Vorstellung EB<br />
Arbeitsklima<br />
• Offene Türen und flache Hierarchien<br />
• Wir sind alle „per Du“<br />
• Flexible Arbeitszeiten<br />
• Motivierte Kollegen<br />
• Genaue Arbeitszeiterfassung<br />
• Internationales Flair<br />
• Freie Getränke<br />
• Admin-Rechte auf dem Computer<br />
• Keine Großraumbüros<br />
• Team-Events, Schafkopf-Turniere, gute Stimmung…<br />
…fast wie an der Uni!<br />
© Elektrobit (EB), 2012 / Confidential 11
AUTOSAR – Automotive Embedded Software<br />
Die AUTOSAR Software-Architektur<br />
http://www.autosar.org<br />
© Elektrobit (EB), 2012 / Confidential 12
AUTOSAR – Automotive Embedded Software<br />
Echtzeit-Betriebssysteme: OSEK<br />
• „Echtzeit“ bedeutet:<br />
‒ Antwortzeiten im unteren µs-Bereich<br />
‒ Sowohl periodische als auch ereignisgesteuerte Prozess-Aktivierung<br />
• Der OSEK-Standard<br />
‒ Teil der AUTOSAR-Spezifikation<br />
‒ Statisches Betriebssystem<br />
• Alle Prozesse sind zur Kompilier-Zeit bekannt<br />
• Keine dynamische Speicherverwaltung<br />
‒ Prioritätsgesteuertes Scheduling<br />
‒ Betriebssystem-Objekte:<br />
• Tasks, Interrupts, Alarme und Timer, Counter, Events, selektive Locks<br />
Das OS muss ein vorhersagbares System ermöglichen!<br />
© Elektrobit (EB), 2012 / Confidential ISO 17356, http://www.osek-vdx.org 13
AUTOSAR – Automotive Embedded Software<br />
Unsere Betriebssysteme<br />
• ProOSEK: ältestes System, seit 1997, reines OSEK<br />
• EB tresos AutoCore OS: OSEK mit AUTOSAR-Erweiterungen<br />
• EB tresos Safety OS: AUTOSAR für sicherheitskritische Systeme (SIL-3/ASIL-D)<br />
• Jeweils bestehend aus zwei Teilen:<br />
‒ Konfigurationsabhängiger, generierter Code<br />
‒ Statischer, konfigurationsunabhängiger Code<br />
• Prozessor-Architekturen (SoC‘s):<br />
‒ 32 Bit: PowerPC, Infineon TriCore, ARM Cortex-R/A, Renesas V850, …<br />
‒ 16 Bit: Freescale S12X, Infineon XC2000, …<br />
‒ Hohe Portabilität der Betriebssysteme!<br />
© Elektrobit (EB), 2012 / Confidential 14
AUTOSAR – Automotive Embedded Software<br />
Der Arbeitsalltag in der OS-Entwicklung… 1<br />
• Portierungen auf neue CPU-Derivate und Architekturen (ab 2007)<br />
‒ 16-Bitter: Freescale S12X, Infineon XC2000<br />
‒ 32-Bitter: PowerPC<br />
‒ Support: letzter Anlaufpunkt bei technischen Problemen<br />
• Entwicklung von AUTOSAR-Modulen und Eclipse-Plugins (2008)<br />
‒ z.B. Betriebssystem-Generator, CanTP-Treiber<br />
‒ Programmiersprachen: Java, C, Assembler, (Perl, Make, Bash, XML,…)<br />
• Projektleitungsaufgaben: ProOSEK, AutoCore OS (2009)<br />
‒ Abstimmung mit Verkauf, Kunden, Produktmanagement, anderen Entwicklungsteams<br />
• Start der Sicherheitsentwicklung: Safety OS (seit 2010)<br />
‒ Erstellung des technischen Konzepts<br />
‒ Aufsetzen der Prozesse für die Entwicklung sicherheitskritischer Software<br />
1<br />
Aus meiner persönlichen Sicht… <br />
© Elektrobit (EB), 2012 / Confidential 15
Sicherheitskritische Systeme<br />
Beispiele sicherheitskritischer Steuergeräte<br />
• Servolenkung<br />
• Airbag<br />
• ESP/ABS<br />
• Elektronisches Gaspedal<br />
• Bremsassistenten<br />
• Automatischer Tempomat<br />
• Aktive Spurhalte-Assistenten<br />
• Batterie-Ladekontrolle<br />
• …<br />
Außerhalb der Automobilindustrie:<br />
• Industriesteuerungen<br />
• Motorsteuerungen<br />
• Landwirtschaft/Baumaschinen<br />
• Medizintechnik<br />
• …<br />
Immer mehr sicherheitskritische Steuergeräte<br />
werden von Software kontrolliert!<br />
© Elektrobit (EB), 2012 / Confidential 16
Safety Assessment – Sicherheitseigenschaften<br />
Was ist „Safety“?<br />
Definitionen:<br />
• „Safety“ bedeutet die Abwesenheit<br />
unangemessener Risiken.<br />
(Bekannter Begriff: „Restrisiko“)<br />
• „Unangemessenes“ Risiko: gemäß<br />
gesellschaftlicher und moralischer<br />
Werte nicht akzeptables Risiko<br />
• Risiko: Kombination aus<br />
Auftrittswahrscheinlichkeit und<br />
Schwere eines Schadens oder<br />
Verletzung<br />
Eigenschaften sicherer Systeme:<br />
• Fehlertolerant (durch Überwachung<br />
o.ä.)<br />
• Unter allen Umständen<br />
wohldefiniertes Verhalten<br />
• Sicherer Zustand im Fehlerfall<br />
‒ „Fail safe“: Abschalten<br />
‒ „Fail operational“: Notbetrieb muss<br />
weiterlaufen<br />
Philosophie des Risikomanagements:<br />
<strong>Vortrag</strong> von Rafaela Hillerbrand, SS2013<br />
© Elektrobit (EB), 2012 / Confidential 17
Sicherheitskritische Systeme<br />
Was braucht man alles für sichere Software?<br />
• Wichtig:<br />
Safety ≠ Security<br />
• Folgende Punkte sind relevant für<br />
die Entwicklung:<br />
‒ „Unterstützende“ Prozesse<br />
‒ Technische Dokumentation<br />
‒ Sicherheits-Eigenschaften<br />
• All dies wird in einem Safety<br />
Assessment geprüft<br />
Sicherheit lässt sich nicht nachträglich integrieren!<br />
© Elektrobit (EB), 2012 / Confidential 18
Safety Assessment – Unterstützende Prozesse<br />
Software-Entwicklungsprozesse<br />
© Elektrobit (EB), 2012 / Confidential 19
Safety Assessment – Unterstützende Prozesse<br />
Software-Entwicklung: Einfachste Methode<br />
Hack<br />
Ship<br />
© Elektrobit (EB), 2012 / Confidential 20
Safety Assessment – Unterstützende Prozesse<br />
Software-Entwicklung: Bessere Methode<br />
Hack<br />
Test<br />
Ship<br />
© Elektrobit (EB), 2012 / Confidential 21
Safety Assessment – Unterstützende Prozesse<br />
Software-Entwicklung: Noch bessere Methode<br />
Specify<br />
Test<br />
Ship<br />
Hack<br />
© Elektrobit (EB), 2012 / Confidential 22
Safety Assessment – Unterstützende Prozesse<br />
Software-Entwicklung: Das V-Modell<br />
Requirements<br />
„Was?“<br />
Tracing<br />
Integration Tests<br />
„Ist alles da?“<br />
Tracing<br />
Design<br />
„Wie?“, „Warum?“<br />
Tracing<br />
Analyse<br />
Unit Tests<br />
„Funktioniert‘s?“<br />
Tracing<br />
Coverage<br />
Code<br />
© Elektrobit (EB), 2012 / Confidential 23
Safety Assessment – Unterstützende Prozesse<br />
Umsetzung: Iterativer Entwicklungsprozess<br />
• Aufteilen des Gesamtsystems in einzelne kleine Module<br />
• Kleine Teams, die für ihr gesamtes „V“ verantwortlich sind<br />
• Iterative Entwicklung mit ca. 4-Wochen-Zyklen<br />
• Letzte Iteration muss in sich konsistent sein<br />
• Vorteile:<br />
‒ Schnelles Feedback, ob Spezifikation funktioniert<br />
‒ Abwechslungsreicheres Arbeiten<br />
‒ Schnelle Anpassung des Funktionsumfangs möglich<br />
‒ i.d.R. pünktliche Auslieferungen<br />
© Elektrobit (EB), 2012 / Confidential 24
Safety Assessment – Unterstützende Prozesse<br />
Welche Hilfsprozesse gibt es?<br />
• Configuration Management<br />
‒ Was ist in einem Release enthalten?<br />
‒ Welche Versionen gibt es?<br />
• Change Management<br />
‒ Wie ändere ich die Software?<br />
‒ Funktioniert sie noch?<br />
• Project Management<br />
‒ Wer macht was wann?<br />
‒ Schaffen wir es rechtzeitig?<br />
‒ Was brauchen die anderen Teams?<br />
© Elektrobit (EB), 2012 / Confidential 25
Safety Assessment – Technische Dokumente<br />
Wie komme ich an „Safety Requirements“?<br />
Beispiel: Fiktive Servolenkung<br />
• Wenige „Safety Goals“ beschreiben<br />
die übergeordneten Sicherheitsziele.<br />
• Funktionale und technische<br />
Requirements beschreiben die<br />
Umsetzung im System<br />
• Software Requirements beschreiben<br />
die Anforderungen an den Software-<br />
Sicherheitsmechanismus.<br />
Safety Goal<br />
Functional<br />
Requirements<br />
Technical<br />
Requirements<br />
• Die Lenkung darf nicht selbst<br />
lenken.<br />
• Die Lenkung darf nicht blockieren.<br />
• Der Servomotor muss den<br />
Lenkbewegungen exakt folgen.<br />
• Eine Software-Komponente muss<br />
den Zustand der Lenkung<br />
kontinuierlich überwachen.<br />
⇒ Ergibt einen großen Requirements-<br />
Baum<br />
⇒ Tracing hilft bei der Analyse!<br />
Software<br />
Requirements<br />
• Das Betriebssystem muss den<br />
Überwachungsprozess aktivieren.<br />
© Elektrobit (EB), 2012 / Confidential 26
Safety Assessment – Technische Dokumente<br />
Design – die Anfänge<br />
© Elektrobit (EB), 2012 / Confidential 27
Safety Assessment – Technische Dokumente<br />
Design – im fertigen Dokument<br />
• Beschreibungssprachen<br />
‒ Informeller Text nach vorgegebenem<br />
Schema<br />
‒ UML (semiformale Methode)<br />
cmp Safety_OS_components<br />
«thread»<br />
Hook<br />
{0..4}<br />
«thread»<br />
OS Application::Task<br />
{0..*}<br />
OS Application<br />
OS Application::Application Data:<br />
MemProtBoundary::Application Data<br />
«thread»<br />
OS Application::ISR<br />
{0..*}<br />
{0..*}<br />
• Beschreibt…<br />
‒ Enthaltene Komponenten<br />
‒ Schnittstellen<br />
‒ Interne Abläufe<br />
MK_OS<br />
Hook Data :<br />
LocalData<br />
Stack :LocalData<br />
AUTOSAR_OS<br />
AUTOSAR_OS<br />
«delegate»<br />
SafetyOS_API<br />
«delegate»<br />
Task Data :LocalData<br />
Stack :LocalData<br />
AUTOSAR_OS<br />
QM-OS_delegated<br />
Safety OS<br />
ISR Data :LocalData<br />
Stack :LocalData<br />
AUTOSAR_OS<br />
Microkernel<br />
MK_OS<br />
«thread»<br />
QM-OS<br />
MK Data :LocalData<br />
Stack :LocalData<br />
QM-OS<br />
OS Data :LocalData<br />
Stack :LocalData<br />
A<br />
© Elektrobit (EB), 2012 / Confidential 28
Safety Assessment – Technische Dokumente<br />
Gute Designs sind eine Kunst<br />
• Es gibt keine Software ohne Design<br />
‒ Gutes oder schlechtes Design<br />
‒ Aufgeschriebenes oder nicht<br />
aufgeschriebenes Design<br />
• Die Fähigkeit, gute Designs zu<br />
erstellen, unterscheidet den<br />
Software-Architekten vom<br />
Programmierer!<br />
• Sicherheitskritische Software<br />
benötigt ein sehr gutes Design.<br />
© Elektrobit (EB), 2012 / Confidential 29
Safety Assessment – Sicherheitseigenschaften<br />
Safety-Klassifizierung nach Risiko<br />
• Klassifizierung der Safety-<br />
Eigenschaften nach:<br />
‒ Schadenshöhe<br />
‒ Eintrittswahrscheinlichkeit<br />
‒ Kontrollierbarkeit<br />
• Normen<br />
‒ IEC 61508<br />
Safety Integrity Levels (SIL):<br />
Industrietechnik, Medizintechnik,<br />
Kerntechnik, …<br />
jedoch nicht: Luftfahrt (andere Norm)<br />
‒ ISO 26262<br />
Automotive SIL:<br />
Automobil-Industrie<br />
ASIL SIL<br />
4<br />
D<br />
3<br />
C<br />
2<br />
B<br />
A 1<br />
Kernkraftwerke<br />
Mehrere Tote<br />
Schwere Verletzungen<br />
Leichte Verletzungen<br />
Nicht sicherheitskritisch<br />
© Elektrobit (EB), 2012 / Confidential 30
Safety Assessment – Sicherheitseigenschaften<br />
Safety-Analyse – „Warum ist das alles sicher?“<br />
• Safety-Analyse unterscheidet<br />
sicherheitskritische von normaler<br />
Software-Entwicklung<br />
Unterscheidung von „Fehlern“:<br />
• Fault: Ursache eines Fehlers<br />
• Error: Fehlverhalten des Systems<br />
• Failure: Ausfall<br />
• Safety-Analyse ist das Aufstellen und<br />
Untersuchen von Fehlerszenarien.<br />
Wann führt man die Analyse durch?<br />
• Zu Beginn der Entwicklung<br />
‒ Erstellen eines sicheren Konzepts<br />
• Während der Entwicklung<br />
‒ Kontinuierliches Hinterfragen<br />
• Am Ende der Entwicklung<br />
‒ Dokumentation des Systemverhaltens<br />
⇒ Alles so klein und einfach wie<br />
möglich!<br />
⇒ Prozesse alleine reichen nicht!<br />
Man weiß unter allen Umständen, wie sich das System verhält!<br />
© Elektrobit (EB), 2012 / Confidential 31
Safety Assessment<br />
Inhalt eines Safety Assessments<br />
• Fokus auf Safety-Eigenschaften<br />
‒ Technisches Konzept<br />
‒ Qualität der Umsetzung<br />
‒ Verifikation<br />
• Persönliches Assessment der<br />
Entwickler<br />
‒ Fachliche Kompetenz<br />
‒ Integrität 1<br />
• Prozesse<br />
‒ Umgang mit Fehlern<br />
‒ Behandlung von Änderungen<br />
Ablauf<br />
• Mehrtägiges Frage-Antwort-Spiel mit<br />
dem Assessor<br />
• Dokumenten-Review<br />
Ergebnis<br />
• Assessment-Report<br />
• Zertifikat<br />
Gute Argumentation ist der Schlüssel <strong>zum</strong> Erfolg!<br />
1<br />
Taz Daughtry, Integrity in Software Process Improvement, EuroSPI 2 2012<br />
http://2012.eurospi.net/images/Conference_Pictures/key_note_2.mp4<br />
© Elektrobit (EB), 2012 / Confidential 32
Fazit<br />
Physiker in der Software-Entwicklung?<br />
• Professionelle Software-Entwicklung<br />
ist mehr als nur Programmieren<br />
• Benötigte Fähigkeiten:<br />
‒ Abstraktionsvermögen<br />
‒ Logisches Denken<br />
‒ Gute Argumentationsfähigkeit<br />
‒ Teamfähigkeit<br />
• Programmiererfahrung ist natürlich<br />
trotzdem nötig…<br />
• Zukunftsaussichten<br />
‒ Sicherheitskritische Funktionen<br />
werden immer mehr in Software<br />
implementiert werden<br />
‒ Auch außerhalb der Auto-Industrie<br />
wird mehr sicherheitskritische<br />
Software eingesetzt werden<br />
⇒ Der Markt wächst!<br />
Ja, da die Anforderungen immer breiter werden!<br />
© Elektrobit (EB), 2012 / Confidential 33
Vielen Dank für Eure<br />
Aufmerksamkeit!<br />
Kontakt:<br />
Automotive.elektrobit.com<br />
Alexander.Mattausch@elektrobit.com<br />
Ein besonderer Dank geht an Geek & Poke: http://www.geek-and-poke.com<br />
Lizenz: Creative Commons - http://creativecommons.org/licenses/by/3.0/deed.en_US
Change language