Die vier wichtigsten Standards des Systems Engineering

Gerade im sicherheitskritischen Bereich spielen Standards eine große Rolle und werden vom Auftraggeber oder Gesetzgeber eingefordert. Daher möchte ich im Folgenden einen Überblick über die wichtigsten Standards geben.

Es gibt eine Reihe von Organisationen, die Standards herausgeben. Neben der bekannten ISO (International Organization for Standardization) gibt es viele weitere, die oft mit ISO kooperieren, oder sogar zusammen Standards veröffentlichen. Dazu gehören, DIN, IEC, DOT, IEEE und viele mehr.

Im folgenden kürze ich die Bezeichner der Standards ab und wähle nur eine Organisation und lasse Jahreszahlen, Sprache und ähnliches weg. Also „ISO 15288“ statt der eigentlich korrekten Bezeichnung „ISO/IEC/IEEE 15288:2015(en)“.

Weiterhin gibt es viele domänenspezifische Standards, zum Beispiel den recht bekannten ISO 26262 „Road vehicles – Functional safety“. Statt dessen beschreibe ich lieber den Domänen-neutralen Standard (wenn es ihn gibt), in diesem Fall IEC 61508.

Und zuletzt: die Liste ist nicht komplett, und „wichtig“ ist subjektiv. Und es gibt natürlich auch viel Literatur zu dem Thema. Ein guter Einstiegspunkt ist jeder relevante Standard, da diese immer auch andere verwandte Standards zitieren. Außerdem hat die INCOSE eine Übersicht über SE-Standards und ein Sonderheft (Insight Connect, April 2014). Auch Forschung wird in diesem Bereich betrieben. Beispielsweise enthält das Papier „A review of systems engineering standards and processes“ (2008) einen spannenden historischen Abriss.

Alles klar? Dann los!

ISO 15288 Systementwicklung – Der Systemlebenszyklus und seine Prozesse

Zu ISO 15288 habe ich bereits etwas geschrieben und werde das in der Zukunft sicher noch häufiger tun, denn dies ist eigentlich der Einstiegspunkt für ernsthaftes Systems Engineering. Das hat die INCOSE auch schon erkannt, weshalb das SE-Handbuch der INCOSE auch auf Konformität zu ISO 15288 großen Wert legt. Daher ist auch meine Empfehlung, neben dem ISO 15288 auch das SE-Handbuch zu studieren, welches etwas leichter verdaulich ist.

Was im Standard steht, sagt der Titel eigentlich schon aus: Es geht primär um die Prozesse, die es geben muss, um Systems Engineering betreiben zu können. Und das sind viele: 25 Prozesse, 123 Artefakte und 403 Aktivitäten (bezieht sich auf eine ältere Version). Da nicht alle Projekte diesen Umfang benötigen, ist die Anpassung des Prozesses ein wichtiger Aspekt, der ebenfalls beschrieben wird.

Wichtig ist auch, was nicht drin steht. Insbesondere wird kaum auf Methodik eingegangen. Das macht ja auch Sinn, da es ja viele verschiedene Entwicklungsmethoden gibt. Weiterhin werden die Themen Qualität und Projektmanagement nur angerissen, da es dafür eigene Standards gibt.

Zuletzt: Es gibt noch ein paar „verwandte“ Standards. Interessant ist hier der ISO 29110, der das selbe Thema für kleine Organisationen abdeckt. Und der ANSI/EIA-632 (Processes for Engineering a System) ist ein älterer Standard, der sich inzwischen mit ISO 15288 koordiniert. Und der ISO 12207 entspricht dem 15288 für Software (und nicht Systeme). Er wurde harmonisiert, so dass Softwareentwicklung nach ISO 12207 auch konform mit ISO 15288 ist.

ISO 9000 ff.Normenreihe zum Qualitätsmanagement

Aus dieser Normenreihe ist der ISO 9001 wohl der bekannteste. Dieser legt die Mindestanforderungen an das Qualitätsmanagement einer Organisation fest. Es ist kaum vorstellbar, dass eine Organisation komplexe Systeme entwickeln kann, ohne die Anforderungen von 9001 umgesetzt zu haben. Bei sicherheitskritischen Entwicklungen gehen die Anforderungen jedoch weit über ISO 9001 hinaus. Dort kommt dann IEC 61508 ins Spiel (siehe unten).

Die Normenreihe ist zunächst neutral gestaltet. Für die verschiedenen Domänen und Branchen gibt es normalerweise weitere Standards, wie zum Beispiel die ISO 10006 für das Qualitätsmanagement in Projekten.

IEC 61508 Entwicklung von elektrischen Systemen mit sicherheitskritischen Funktionen

Dieser Standard stellt die Grundlage für eine Reihe branchenspezifischer Anpassungen dar. Zu den bekannteren gehört sicher der ISO 26262 aus dem Automobilbereich.

In der heutigen Zeit gewinnt Sicherheit zunehmend an Bedeutung, sowohl im Sinne von funktionaler Sicherheit (Safety) und Gefahrenabwehr (Security). Hier höre ich in letzter Zeit öfter, dass der Standard nicht (mehr) adäquat für die heutigen Entwicklungen ist. Das geht auch schon aus dem Namen (elektrische Systeme) hervor: Moderne Systeme bestehen typischerweise aus Mechanik, Elektronik und Software. Gerade hinsichtlich der durchgängigen Sicherheitsüberprüfung über diese drei Bereiche fehlt dem Standard Präzision und Detaillierungsgrad.

Nicht alle Standards zur funktionalen Sicherheit sind vom IEC 61508 abgeleitet. Der DO178 (Luftfahrt) ist eigenständig. Hier ist eine Übersicht der Sicherheitsstandards verschiedener Branchen.

ISO 21500 Leitfaden zum Projektmanagement

Ein professionelles Projektmanagement ist ebenfalls für ein erfolgreiches Systems Engineering unerlässlich. Daher finden sich in den anderen Standards auch regelmäßig Referenzen auf den Projektmanager und den Projektplan. Das Projektmanagement ist jedoch so umfangreich, dass es dafür einen eigenen Standard gibt.

Als Leitfaden bezieht sich der ISO 21500 auf eine Anzahl anderer Standards. Wichtig ist da insbesondere in Deutschland die DIN 69901, die nicht nur Prozesse, sondern auch Methoden abdeckt.

Fehlt etwas? Diskutieren Sie mit!

Damit haben wir die wichtigsten Standards kennengelernt und uns einen groben Überblick über den Dschungel der Standards verschafft. Habe ich etwas wichtiges vergessen? Oder haben Sie Anregungen oder weitere Informationen? Dann starten Sie doch einfach eine Diskussion.

Dieser Artikel erschien zuerst bei se-trends.de.

2 Pingbacks/Trackbacks

  • Pingback: Wichtigste Standards des Systems Engineering | LieberLieber Software TeamBlog()

  • Peter Schmitz

    Hallo Herr Jastram,

    Ich glaube, das ihre Auswahl im Bereich Sicherheit sich stark aufs Elektrotechnische beschränkt. Ad hoc fielen mir hier noch ein:

    – DIN EN ISO 12100 -Sicherheit von Maschinen – Allgemeine Gestaltungsleitsätze – Risikobeurteilung und Risikominderung (ISO 12100:2010); Deutsche Fassung EN ISO 12100:2010

    – DIN EN ISO 13849 : Sicherheit von Maschinen – Sicherheitsbezogene Teile von Steuerungen (Nachfolger von 61508/511)

    Empfehlen kann ich auch die Lektüre der VDI-Denkschrift: http://www.vdtuev.de/themen/industrie_und_anlagensicherheit/erfahrungsaustausch_zues/vdi-denkschrift-zur-technischen-sicherheit resp. https://www.vdi.de/technik/fachthemen/technische-sicherheit/

    Desweiteren gibt es auch im Bereich des Systems Engineering den Punkt der Dokumentation. i.e.

    – DIN EN IEC/ISO 82079-1 : Erstellen von Gebrauchsanleitungen – Gliederung, Inhalt und Darstellung – Teil 1: Allgemeine Grundsätze und ausführliche Anforderungen

    – DIN Fachbericht 146

    Soviel zu Sparten-Aspekten um nicht zu weit auszuholen.

    Was das Systems Engineering meiner Meinung nach braucht sind Darstellungsmethoden und Klassifizierungssysteme um die Abhängigkeiten und Schnittstellen des Systems von und zu den beteiligten Disziplinen und Rahmenbedingungen einordnen und beschreiben zu können.

    Hier sind die meisten Methoden und Werkzeuge einfach zu linear, lassen zu wenig Dimensionen eines komplexen Systems abbilden.

    Hilfsmittel, die mir auf meiner Suche nach der noch nicht gefundenen Lösung begegnet sind, sind: Mindmapping, Colon Classification, BPMN, UML, Anlagenkennzeichnungssysteme.

    • Hallo Herr Schmitz,

      > Ich glaube, das ihre Auswahl im Bereich Sicherheit sich stark aufs Elektrotechnische beschränkt.

      Stimmt. Das hat sicher etwas mit meiner erfahrungsbedingten „Betriebsblindheit“ zu tun. Zum anderen würde ich aber auch behaupten, dass diese Art von Systemen um Größenordnungen schwieriger ist (Stichwort: Therac-20 -> Therac-25).

      > DIN EN ISO 13849 : Sicherheit von Maschinen – Sicherheitsbezogene Teile von Steuerungen (Nachfolger von 61508/511)

      Diese DIN hatte ich noch nicht auf dem Radar, hab‘ gerade einen Vergleich gefunden. 61508 und 13849 scheinen ja komplett unabhängig voneinander zu sein, das ist ja eigentlich blöd.

      > Empfehlen kann ich auch die Lektüre der VDI-Denkschrift: http://www.vdtuev.de/themen/industrie_und_anlagensicherheit/erfahrungsaustausch_zues/vdi-denkschrift-zur-technischen-sicherheit resp. https://www.vdi.de/technik/fachthemen/technische-sicherheit/

      Werde ich mir bei der nächsten Bahnfahrt mal anschauen, sieht sehr interessant aus, danke.

      > Desweiteren gibt es auch im Bereich des Systems Engineering den Punkt der Dokumentation. i.e.

      Da war für mich die Frage, wo ich aufhöre: Schließlich schreibt ja 15288 vor, dass Dokumentation abgedeckt werden muss, halt nur nicht wie. Zu dem Thema könnte man wahrscheinlich auch wieder ein ganzes Buch schreiben.

      > Was das Systems Engineering meiner Meinung nach braucht sind Darstellungsmethoden und Klassifizierungssysteme um die Abhängigkeiten und Schnittstellen des Systems von und zu den beteiligten Disziplinen und Rahmenbedingungen einordnen und beschreiben zu können.

      > Hier sind die meisten Methoden und Werkzeuge einfach zu linear, lassen zu wenig Dimensionen eines komplexen Systems abbilden.

      Dem stimme ich voll und ganz zu. Das ist sicher auch der Grund, warum im Moment so viel im SE passiert. Die Ansätze, die wir bisher genutzt haben, skalieren nicht sonderlich gut.

      > Hilfsmittel, die mir auf meiner Suche nach der noch nicht gefundenen Lösung begegnet sind, sind: Mindmapping, Colon Classification, BPMN, UML, Anlagenkennzeichnungssysteme.

      Colon Classification kenne ich noch nicht, muss ich mir mal anschauen.

      Ich sehe drei Lagen, die wir noch nicht optimal beherrschen: (1) Prozesse (Was muss ich tun?), (2) Sprachen (Womit muss ich es tun?), (3) Methoden (Wie muss ich es tun?). Werkzeuge sitzen oben drauf und unterstützen das ganze. Gerade im Bereich Methodik gibt es noch viel zu tun.

  • Pingback: Formal Mind - The Four Events That You Should Not Miss At ReConf 2016()