Safety Systems Engineering

Safety ist eine Systemqualität.
Man kann Safety nicht hineinprüfen, analysieren oder administrieren.

Doch der Eindruck, man könne Safety hineinprüfen, entsteht durch Safetynormen und Compliancestandards: Sie legen fest, was nachzuweisen ist — aber nicht, in welchem Kontext und wie man überhaupt zu einem Design gelangt, das man prüfen könnte:

Safetynormen und Compliancestandards formalisieren den Nachweis (rechts), während Safety in der Systemgestaltung (links) umgesetzt wird.
(Quelle: Eigene Darstellung)

Zudem gelten viele Standards, die in sich umfangreich sind und für das Gleiche unterschiedliche Begriffe verwenden:

  • ISO 26262 — Functional Safety
  • ISO 21448 — Safety of the Intended Functionality (SOTIF)
  • ISO/PAS 8800 — KI Safety
  • IEC 61508 — Produktsicherheit
  • DO-178C — Sicherheitsrelevante Avionic-Software
  • Automotive SPICE
  • SEBOK, SWEBOK, PMBOK
  • ISO 9001, IATF 16949
  • E-Gas-Konzept
  • und viele mehr …

Die Folge: Safety Engineering läuft neben dem Projekt und am Projekt vorbei.
Inkonsistente Konzepte. Kostspielige Fehler. Verzögerungen. Vor allem aber: Safetyrisiken!

Wie lösen wir das? Safety Engineering ist Systems Engineering für die Systemqualität Safety.

Daraus ergeben sich vier Schwerpunkte:


Kontext:

Safetynormen legen fest, was nachzuweisen ist, aber nicht, wie oder wodurch sich unzulässig hohe Risiken systematisch vermeiden lassen. Fehlerfreie Software und Hardware garantieren keine Sicherheit. Die Safety-Kybernetik setzt hier an: Systemisch werden die Freiheitsgrade der Teile — technisch wie organisatorisch — so eingegrenzt, dass Gefährdungen idealerweise gar nicht erst entstehen.

Ihr Nutzen:

 Klare Ziele für Ihre Domänen. Designziele und -anforderungen definieren, was technisch erforderlich ist. Safety Plan und Methoden legen fest, was, wann, wie und durch wen umgesetzt wird. So können Ihre Domänen zielstrebig und effizient entwickeln, ohne zu sehr in ihren Fachlösungen eingeschränkt zu werden.

Das entsteht im Projekt:

 Für Ihr Produkt und Ihr Team entsteht ein organisatorischer und technischer Regelkreis zur Gewährleistung der Safety: ein abgestimmtes Zusammenspiel von Anforderungen, Architektur und Design, Safety-Analysen, Verifikation und Validation sowie Safety Management.

Das bringe ich ein:

 Ich unterstütze Ihr Projekt als System-Safety-Experte, erarbeite gemeinsam mit Ihrem Team die technischen Leitplanken, binde die Fachdomänen ein und sorge für eine konsistente Umsetzung des Safety Plans.


Kontext:

 In der Praxis sind viele funktionale und technische Sicherheitskonzepte überladen und unklar. Ihr eigentlicher Zweck: festzulegen, wie das System im Fehlerfall oder unter kritischen Umweltbedingungen geordnet in einen degradierten oder sicheren Zustand übergeht. Gleichzeitig darf ein gutes Sicherheitskonzept die Verfügbarkeit und Performance des Systems nicht unzulässig einschränken.

Ihr Nutzen:

 Ein klares Sicherheitskonzept, das als „virtuelle Sicherheitsschnittstelle“ fungiert. Die Fachdomänen können ihre Funktionen und Entwürfe so gestalten, dass systemweit eine geordnete und rechtzeitige Degradation oder der sichere Zustand ausgelöst wird. Das Testing erhält eindeutige Anforderungen und Kriterien, was zu verifizieren ist.

Das entsteht im Projekt:

 Anforderungen, Design, Dokumentation und Analysen, die das Sicherheitskonzept vollständig spezifizieren und ein abgestimmtes Detailed Design sowie gezieltes Testing ermöglichen.

Das bringe ich ein:

 Langjährige Erfahrung in der Auslegung und Umsetzung von Sicherheitskonzepten in der funktionalen und produktspezifischen Sicherheit — von QM bis ASIL D bzw. SIL 3. Breites Wissen zu Sicherheitsmechanismen, Safety Patterns und Software Architektur für eine effektive Systemgestaltung.


Kontext:

 Safetynormen sind umfangreiche Regelwerke, in denen je nach (A)SIL unterschiedliche Designkriterien, Prozessanforderungen sowie Methoden zur Analyse, Verifikation und Validierung vorgegeben sind. Doch das Entscheidende fehlt: unter welchen fachlichen Bedingungen diese Vorgaben tatsächlich sinnvoll angewendet werden.

Ihr Nutzen:

 Wir übersetzen Methoden- und Kriterienkataloge in einfache, alltagstaugliche Entscheidungsbäume. So können auch Entwickler, die keine Safety Engineers sind, Sicherheitsaspekte schnell, korrekt und angemessen entscheiden.

Das entsteht im Projekt:

 Fast-and-Frugal-Bäume, die komplexe Safetynormen gezielt mit Ihrer Systemrealität kreuzen. Wir entwickeln diese Entscheidungsbäume für die jeweiligen Fachdomänen und pilotieren ihren Einsatz im Entwicklungsalltag.

Das bringe ich ein:

 Umfassende Normen- und Methodenkenntnisse sowie langjährige Erfahrung in ihrer praktischen Anwendung.


Kontext:

 Safety Management wird häufig auf Checklisten und Dokumentation reduziert. So wird der Safety Manager zum Störfaktor und Safety zum lästigen „Add-on“. Doch so kann Safety Engineering nicht gelingen. Ein Safety Manager ist Werttreiber: Er begleitet das Projektteam kontinuierlich, zeigt Safety-Bedarfe auf, unterstützt deren Erfüllung und kümmert sich um sicherheitsrelevante Problemlösungen.

Ihr Nutzen:

 Safety Engineering kann nur gelingen, wenn es inhärenter Bestandteil des Projektteams ist. Der Safety Manager strukturiert die sicherheitsrelevanten Arbeitspakete — als Ergänzung des normalen Engineerings —, führt die Ergebnisse im Safety Case zusammen und erstellt Freigabeempfehlungen sowie Gefährdungsbeurteilungen.

Das entsteht im Projekt:

 Ein Safety Plan mit Work Breakdown Structure, ein abgestimmter und freigegebener Safety Case, Risikobewertungen, Freigabeempfehlungen sowie Safety-Assessment- und Audit-Berichte.

Das bringe ich ein:

 Langjährige Erfahrung im Safety Management von QM(S) bis ASIL D sowie in der Produktsicherheit. Und, wenn Sie gestatten, die Triebkraft eines Selbstständigen mit Erfahrung aus internationalen Großprojekten.


Lassen Sie uns sprechen

Erzählen Sie mir von Ihrem Projekt und wie wir Ihre Produktentwicklung voranbringen können.

Ihr Nico Litschke