Interoperabilität ist kein Technikproblem

Interoperabilität entsteht nicht dadurch, dass Systeme technisch verbunden sind, sondern dadurch, dass sie dieselben Begriffe, Formate und Zuständigkeiten verstehen. Entschieden wird das nicht in der Integration, sondern Jahre vorher im Requirements Engineering. Denn jedes System tut exakt das, was in seiner Spezifikation steht. Nur steht in den Spezifikationen verschiedener Vorhaben oft nicht dasselbe.

Im Video zeigt Stefan Wellhausen, Branchenaccount Manager für Defense und Aerospace bei der SOPHIST GmbH, an einem Szenario aus Aufklärungsdrohne, Gefechtsstand, Raketenartillerie und Kampfpanzer, an welchen Stellen ein Systemverbund bricht, obwohl alle Systeme technisch einwandfrei funktionieren.

Video: Interoperabilität ist kein Technikproblem · SOPHIST GmbH

Das Wichtigste aus dem Video

  • Der Satz „Das System muss interoperabel mit anderen Systemen der Partner sein“ ist keine Anforderung, sondern ein Wunsch, weil er Information, Format, Zeitverhalten und Ausfallverhalten offen lässt.
  • Jede offene Stelle in einer Spezifikation füllt der Auftragnehmer selbst, und zwar so, wie es für sein System am einfachsten ist.
  • Koordinatensystem, Zeitbasis, Klassifikationsstufen und Nachrichtentypen sind die Stellen, an denen ein Systemverbund typischerweise bricht.
  • Systeme aus getrennten Vorhaben arbeiten nur dann zusammen, wenn sich die Menschen, die sie spezifiziert haben, vorher über Begriffe, Formate und Verantwortlichkeiten verständigt haben.
  • „Interoperabilität entsteht nicht, wenn Systeme verbunden sind, sondern wenn sie sich verstehen.“

Häufige Fragen

Was bedeutet Interoperabilität in Multi-Domain Operations?

Dass Systeme verschiedener Nationen und Domänen Informationen so austauschen, dass sie beim Empfänger dieselbe Bedeutung haben. Eine technische Verbindung allein reicht dafür nicht aus.

Reicht „Das System muss interoperabel sein“ als Anforderung?

Nein. Der Satz nennt weder die auszutauschenden Informationen noch Format, Zeitverhalten oder Ausfallverhalten. Damit verlagert er jede Festlegung auf den Auftragnehmer.

Was hat Systems Engineering mit Requirements Engineering zu tun?

Systems Engineering koordiniert die interdisziplinäre Entwicklung komplexer Systeme. Requirements Engineering liefert dafür die abgestimmten Anforderungen, ohne die Schnittstellen zwischen Disziplinen und Partnern nicht zusammenpassen.

Die Broschüre Systems Engineering kostenlos nutzen

Wie Requirements Engineering und Architektur bei komplexen Systemen zusammenspielen und welche Sichten dabei helfen, Schnittstellen früh sauber zu klären, steht in unserer kostenlosen Broschüre:

Ihr spezifiziert gerade ein Vorhaben, das später in einem Verbund laufen muss, und seid unsicher, wie tief die Schnittstellenanforderungen gehen müssen? Sprecht uns an, wir schauen uns eure Ausgangslage im Gespräch an.

Dieses Video ist der erste Teil einer vierteiligen Reihe. Auf dem SOPHIST YouTube-Kanal erklären wir regelmäßig Requirements Engineering und Systems Engineering aus der Praxis. Abonniere den Kanal, dann verpasst du keinen Teil.

Grundlage: SOPHIST-Broschüre „Systems Engineering – mit RE und Architektur zum Erfolg“ aus SOPHIST WISSEN-for-free und das Buch „Requirements-Engineering und -Management“ (7. Auflage, Chris Rupp und die SOPHISTen, Hanser).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert