Sprache:
deutsch

Zielgruppe:
Entwickler, Architekten, Projektmanager

Voraussetzungen:
Grundlagen des Agilen Software Engineering und Funktionale Sicherheit

Überblick und Zusammenfassungen:
Agile Methoden stehen per Definition im Widerspruch zum statischen Entwicklungsmodell eines typischen Projekts welches nach Standards der funktionalen Sicherheit zertifiziert werden soll. Safety Standards wie die IEC 61508 oder die ISO 26262 definieren einen Entwicklungsprozess in Anlehnung an ein V-Modell. Das bedeutet, bei einer Änderung der Top-Level Requirements muss der gesamt V-Model Zyklus vollständig durchlaufen werden bevor man eine neue Release erstellen kann. Dieser Ansatz passt nicht zum Agilen Manifest, welches zum Beispiel flexible Reaktion auf sich ändernde Anforderungen und regelmäßige Releases befürwortet. Trotzdem gibt es Möglichkeiten Safety Projekte nach Agilen Methoden zu entwickeln.
Dieser Vortrag ist ein Erfahrungsbericht basierend auf mehreren Safety Projekten bei denen Agile Methoden an spezifischen Stellen angewendet wurden. Es wird erklärt welche Aspekte der Agilen Entwicklung an welchen Stellen des V-Modells passen und welche nicht, und welche Lektionen bei der Anwendung gelernt wurden.



Art der Vermittlung:
Erfahrungsbericht

Nutzen:
Wenn Sie im Bereich Funktionale Sicherheit arbeiten und gerne mit Agilen Methoden arbeiten möchten, können Sie in diesem Vortrag aus den Erfahrungen von verschiedenen Projekten lernen.

Sprache:
Deutsch

Zielgruppe:
Entwickler, Tester, Qualitätsmanagement, Projektmanagement

Voraussetzungen:
Interesse an embedded SW Entwicklung und/oder Test, Interesse an SW-Qualität

Überblick und Zusammenfassungen:
Auch wenn die Schlagzeilen in jüngster Zeit anderes vermuten lassen ist die Avionik doch der Industriezweig mit den höchsten Anforderungen an die Produktqualität. Mit der allgegenwärtigen Tendenz zu immer mehr Software war und ist auch die Luftfahrt konfrontiert, und das schon seit über 40 Jahren. Kein Wunder also, dass eine erste Version des Softwareentwicklungsstandards DO-178 schon sehr früh, nämlich 1982 verpflichtend wurde, und damit weit vor anderen Standards wie IEC 61508 (1998). Und wenn IEC 61508 gerne als die Mutter aller funktionalen Sicherheitsnormen bezeichnet wird, dann wird DO-178 damit zur Großmutter, denn viele Konzepte der DO-178 finden sich in IEC 61508 wieder. Doch deshalb ist DO-178 nicht veraltet, sondern wird kontinuierlich weiterentwickelt und verbessert. Mit DO-178C wurde zum Beispiel die dynamische Verifikation von "Data-Coupling" und "Control-Coupling" (DCC) verpflichtend, ein Konzept, das zur Software Kapselung beiträgt und damit größere Systeme besser beherrschbar macht.
In diesem Vortrag wird auf diese und andere Anforderungen eingegangen, die in der Avionik schon heute gang und gäbe sind und die in anderen Industriezweigen möglicherweise in naher Zukunft auch eingeführt werden. Erfahren Sie mehr über Theorie und Praxis hinter Tool Qualifizierung, Requirements Traceability, Object Code Verification, Masking MC/DC oder einem verpflichtenden embedded Unittest und wie diese dazu beitragen können, die Softwarequalität langfristig zu verbessern.

Art der Vermittlung:
Präsentation und praktische Demo

Nutzen:
Der Vortrag geht auf Strategien der Softwareentwicklung und des Softwaretests ein, wie sie in der Avionik angewandt werden, um Softwarequalität zu gewährleisten und zu verbessern. Ich berichte aus über 10 Jahren Erfahrung in der Zusammenarbeit mit Kunden aus verschiedenen Industrien, vornehmlich Avionik.
Es werden neue Methoden erläutert, wie zum Beispiel Data-Coupling/Control-Coupling (DCC) oder Masking MC/DC, die auch in anderen Industrien Verwendung finden können und sollten. Die Interpretation des Standards DO-178 sowie dessen praktische Umsetzung wird auch für Besucher aus der Avionik-Industrie Neues bieten, insbesondere die Informationen zum Thema DCC und Object Code Verification.

Sprache:
Deutsch

Zielgruppe:
Entwickler, Tester, Nutzer statischer Analysewerkzeuge

Voraussetzungen:
grundsätzliche Kenntnisse der Softwareentwicklung, grundsätzliche Kenntnisse von QA Methoden und statischer Analyse

Überblick und Zusammenfassungen:
Bei der Entwicklung sicherheitskritischer Software kommen diverse Techniken und Verfahren zur Qualitätssicherung zum Einsatz. Ein typisches Beispiel ist die statische Codeanalyse. Mit dieser kann Quelltext automatisiert auf Laufzeitfehler überprüft oder die Übereinstimmung mit gegebenen Programmierrichtlinien wie MISRA sichergestellt werden.

Eine Schwäche der statische Codeanalyse ist Unentscheidbarkeit. Diese hat zur Folge, dass bestimmte Prüfungen fundamental nicht präzise durchgeführt werden kann. Es kommt zu vielzähligen Fehlmeldungen, langen Laufzeiten und anderen durch die fehlende Präzision verursachten Einschränkungen.

Im Vortrag wollen wir zunächst Unentscheidbarkeit präzise definieren und ihre Ursachen beschreiben. Darauf aufbauend diskutieren wir die Konsequenzen von Unentscheidbarkeit und mögliche Wege, um diese abzufedern. Dabei gehen wir auch darauf ein wie gängige Richtlinien wie MISRA mit Unentscheidbarkeit umgehen und wie eigene (projektspezifische) Richtlinien möglichst prüfbar formuliert werden können.


Art der Vermittlung:
Vortrag, Projektbeispiel, kleine Interaktive Übungen

Nutzen:
Die Teilnehmer
- verstehen was Unentscheidbarkeit ist und wie sie entsteht,
- kennen die Konsequenzen von Unentscheidbarkeit,
- kennen verschiedene Techniken zur Vermeidung von Unentscheidbarkeit,
- können diese Techniken in Projekten anwenden,
- können eigene Programmierrichtlinien entwerfen, die Unentscheidbarkeit vermeiden.

Sprache:
Deutsch (oder auch Englisch bei Bedarf)

Zielgruppe:
Systemarchitekten, Software Engineers, Test Engineers, Projektmanager, Safety Manager

Voraussetzungen:
Grundwissen zu Embedded Systemen und funktionaler Sicherheit

Überblick und Zusammenfassungen:
Die Kluft zwischen der täglichen Arbeit von Entwicklungsteams und den formalen Anforderungen von Assessoren ist oft immens. Unterschiedliche Perspektiven – Praxis und Konformität – prallen aufeinander. Während die Entwicklungsteams unter Zeitdruck Produkt-Funktionalitäten implementieren müssen, fokussieren sich Assessoren auf Qualitätsaspekte (ASPICE, ISO 9001 etc.), Sicherheit (IEC 61508, ISO 26262) oder andere Produkt-Charakteristika.

Am besten lernt man aus den Fehlern anderer. Es werden in unserem Vortrag eine Reihe anonymisierter Fälle entlang des Produktlebenszyklus präsentiert. Dabei laden wir das Publikum ein, ihre Meinung durch Abstimmung in den Vortrag mit einzubringen. Im Anschluss werden die verschiedenen Lösungen unter den Aspekten der Safety, Compliance und Praktikabilität betrachtet und diskutiert.

Themen aus dieser Kategorie sind:
Case #1 Softwarearchitektur – Kartographische Erfassung der Safety?
Ein Kunde präsentiert als Softwarearchitektur ein Labyrinth von Software Units mit ihren Interfaces (was schon nicht immer zu erwarten ist). Die Safety Wirkketten verstecken sich jedoch und sind ohne Ariadnes Faden nicht zu finden.
Case #2 Zwischen Unit Designs und „100% Statement Coverage“
Ein Kunde hat seine Unit Designs basierend auf dem bereits geschriebenen und doku-mentierten Code erstellt. Daher werden die Unit Tests direkt gegen den Softwarecode ge-schrieben, anstatt gegen eine separate Spezifikation.
Case #3 Verifikation von Timing Anforderungen abkürzen?
Ein Kunde möchte sich kostenintensive Tests über die Einhaltung von Timing Require-ments sparen. Anstelle von dynamischen Tests plant er deshalb eine Rechnung über die Ausführungszeiten der Sicherheitsfunktion. Spoiler: Es ist nicht so einfach, wie es klingt!
Case #4 Fehlerinjektionen – im Produkt lassen oder nicht?
Ein Kunde testet umfangreich seine embedded Software und darin enthaltene Sicher-heitsfunktionen mit Hilfe von Fehlerinjektionen. Um eine Fehlauslösung zu verhindern und Speicherplatz zu sparen werden diese jedoch entfernt. Das nicht getestete Produkt landet so auf der Teststrecke „öffentlicher Straßenverkehr“.

Diese und weitere Fälle werden wir zusammen mit der Zuhörerschaft bearbeiten und dadurch helfen dem Fachpublikum im Projektalltag sicherere und effizientere Entscheidungen zu treffen.

Art der Vermittlung:
Als Vortrag entlang einiger Praxis Beispiele aus vergangenen Assessment Projekten

Nutzen:
Anhand von Beispielen aus dem Assessment Alltag, werden die Risiken und Lösungen dieser Fälle praxisnah diskutiert. Dies ermöglicht ein nicht nur ein gegenseitiges Verständnis der beiden Parteien beim nächsten Audit/Assessment, sondern sorgt auch für effektivere und effizientere Engineering Ansätze.