Systemarchitektur

Im Bereich des Systems Engineering gibt es eine Vielzahl von Normen und Standards, die verschiedene Aspekte des Systementwurfs und -managements abdecken. Diese Normen dienen als Referenz und Leitfaden für Ingenieure, um effektive und zuverlässige Systeme zu entwickeln. Aus unserer Perspektive ist die ISO/IEC/IEEE 42010 die wichtigste: Sie ist von Ihrer Denkweise und Art die ungewöhnlichste und gleichzeitig der größten Hebelwirkung auf die Verbesserung der digitalisierten Zusammenarbeit. Die ISO/IEC/IEEE 42010 präsentiert Best Practices, um eine Systemarchitektur zu beschreiben – egal ob Mechatronik, Software oder von Unternehmen. Die ISO/IEC/IEEE 42010 Ceci n’est pas une pipe – das bekannte Ölbild des Malers René Magritte zeigt ein (für das Erscheinungsjahr nahezu photorealistisches) Abbild einer Pfeife, untertitelt mit dem französischen Satz „Ceci n’est pas une pipe“, zu Deutsch: Dies ist keine Pfeife. Magritte beschreibt mit seinem Bild die Beziehung zwischen dem tatsächlichen Objekt, seiner Bezeichnung und seiner graphischen Repräsentation – Sie sehen keine Pfeife, sondern nur ihr Bild. Genauigkeit der Begriffe Warum dieser kleine Exkurs? Gerade beim Thema „Architektur“ ist Genauigkeit gefragt. Die ISO/IEC/IEEE 42010 Systems and Software Engineering – Architecture Description schafft ein einheitliches Verständnis für die Begriffe im Kontext einer Systemarchitektur. Das Bild der Pfeife deutet da auf ein häufiges Missverständnis hin: Wir sagen meist Architektur – meinen aber die Architekturbeschreibung eines Systems. Konzept der ISO 42010 ISO 42010, mit dem Titel „Systems and software engineering – Architecture description“, konzentriert sich speziell auf die Beschreibung von Architekturen. Sie legt Prinzipien und Konzepte fest, um sicherzustellen, dass Architekturbeschreibungen klar, konsistent und verständlich sind. Die Norm bietet Anleitungen zur Strukturierung, Dokumentation und Kommunikation von Architekturen und ermöglicht es Ingenieuren, die Architektur eines Systems umfassend zu verstehen und zu analysieren. Die ISO/IEC/IEEE 42010 liefert also ein Rahmenwerk für die Beschreibung, Organisation und Darstellung von Architekturbeschreibungen. Sie löste 2007 die IEEE 1471 Recommended Practice for Architectural Description of Software-Intensive Systems ab und adressiert seitdem jegliche Systeme – insbesondere natürlich technischer Art. Die ISO 42010 wird unabhängig von technischen Konzepten, Modellierungssprachen oder Werkzeugen beschrieben. Diese Neutralität ermöglicht die Übertragung auf das eigene Unternehmen und schafft somit eine einheitliche Arbeitsgrundlage. Unter einer Systemarchitektur versteht die Norm die fundamentalen Konzepte oder Eigenschaften eines Systems, also beispielsweise wie es in seine Umgebung eingebettet ist, was seine konstituierenden Elemente und ihre Interaktionen sind sowie die Prinzipien, nach denen es entwickelt und organisiert wird. Eine Architektur ist etwas Abstraktes, ihre Beschreibung dagegen ein konkretes Arbeitsprodukt in der Produktentwicklung. Das Modell der Architekturbeschreibung Kern der ISO ist eine Ontologie. Elementar ist hier das Zusammenspiel zwischen einem Stakeholder, dem betrachteten System (‚System-of-Interest’) und der Architekturbeschreibung: Einer oder viele Stakeholder der Architekturbeschreibung haben unterschiedliche Interessen an einem System. Die daraus abgeleiteten Concerns finden dann Berücksichtigung in der der Architekturbeschreibung. Der Begriff Concern ist etwas ungelenk definiert als ‚any topic of interest’ – beispielsweise die Funktionalität, die Struktur, das Verhalten des Systems (weitere Concerns in der Infobox). Zur Befriedigung eines Concerns wendet die ISO 42010 das Konzept der ‚Separation of Concerns’ an – jeder Concern wird durch eine einzelne View (Sicht) dargestellt, also einen konkreten Ausschnitt der Architekturbeschreibung in einer hierfür geeigneten Darstellungsweise. Das kann etwa für den Systemingenieur eine Wirkkette sein, für den Elektrotechniker das Blockschaltbild und für den Projektmanager durchaus eine N2-Matrix. Die in den verschiedenen Views zum Ausdruck gebrachten Inhalte können sich durchaus überschneiden – da sie jeweils ausdrücken, was für den konkreten Stakeholder ‚von Interesse’ ist. Wie die View dargestellt und erarbeitet wird, wird durch den Viewpoint (Standpunkt) bestimmt. Dieser definiert die Konventionen zur Erstellung, Interpretation und Analyse der Views. Das sind etwa Sprachen, Notationen, Modellart, Modellierungsmethoden oder Analysetechniken. Ein Architecture Viewpoint ist somit im Prinzip eine Beschreibung der Methode zur Erstellung einer konkreten View. Verwendung von Architekturbeschreibungen Eine konsistente Architekturbeschreibung, über die verschiedenen Views hinweg, ist oberstes Ziel in der Produktentwicklung. Modellbasiertes Systems Engineering (MBSE) bietet hierfür in vielen Fällen die notwendige Herangehensweise. Die Architekturbeschreibung als solches ist kein Selbstzweck und stiftet für sämtliche Stakeholder und zu unterschiedlichen Zeitpunkten im Systemlebenszyklus erheblichen Nutzen. Die ISO nennt hierfür zahlreiche Beispiele. Diese zeigen auch, warum die Architekturbeschreibung ein solch kritischer Punkt in einem Projekt ist. Die Architekturbeschreibung… Das Konzept der ISO 42010 erscheint zunächst sehr abstrakt. Wenn man sich allerdings ein wenig mit ihrer Darstellungsform und Intention beschäftigt, erkennt man, dass die ISO wirklich ein hervorragendes Gerüst ist, um die Zusammenarbeit vieler Stakeholder, ihrer Aufgaben und Darstellungsweisen zu organisieren und verständlich zu machen. Im Kern müssen Entwicklungsorganisationen erkennen, dass eine Architekturbeschreibung zentraler Ausgangspunkt der Zusammenarbeit ist und dass es viele gültige Darstellungsformen gibt – nur müssen sie organisiert und klar strukturiert sein. Den richtigen Zugang bietet die ISO 42010. Weitere Normen im Systems Engineering Eine weitere Norm im Systems Engineering, die ISO 15288, beschäftigt sich mit dem System-Lebenszyklus-Prozess. Unsere Software iQUAVIS berücksichtigt beide Normen. Christian TschirnerSystems Engineering ist eine Lebensart – wer sie einmal kennt, kommt nicht von ihr los! Ich brenne dafür, das Engineering zu verändern. Weg von verwirrenden Lasten- und Pflichtenheften hin zu einer modellbasierten Spezifikation. Das hilft mir, viele Aufgaben eines Projekts besser zu bewältigen, mit Kollegen ein gemeinsames eindeutiges Systemverständnis zu bilden und immer die relevanten Aufgaben im Blick zu haben. Und außerdem: Ich bin überzeugt, dass innovative Geschäftsmodelle nur mit einem solchen Ansatz möglich werden: Smarte Services, Things that think, … Let’s go together! www.two-pillars.de/

Was ist eigentlich MBSE? In diesem Artikel gehen wir auf die Grundlagen des Modul Based Systems Engineering ein und erklären das Grundprinzip dahinter. Traditionell basiert Produktentwicklung im Idealfall auf gut gelenkten Dokumenten, wie z.B. dem Lastenheft in Word – was jedoch an die Grenzen der Leistungsfähigkeit in heutigen Entwicklungsprojekten und -organisationen stößt. Die voranschreitende Entwicklung der Informations- und Kommunikationstechnik hat in Verbindung mit den für die verteilte globale Wertschöpfung nicht geeigneten Ansätzen der „Powerpoint-Entwicklung“ die Idee eines modellbasierten Systems Engineerings hervorgebracht: Model-Based Systems Engineering (MBSE). MBSE: Model-Based Systems Engineering Anders als in der weitgehend etablierten modellbasierten Entwicklung – repräsentiert beispielsweise durch CAD, FEM und auch durchaus Ansätzen wie Modelica – stehen im MBSE nicht fachdisziplinspezifische Artefakte im Mittelpunkt, sondern eine fachdisziplinübergreifende Beschreibung des Systems: das Systemmodell. Je nach Ausgestaltung soll dies von allen Disziplinen für unterschiedliche Zwecke genutzt werden. Meistens wird es für das Anforderungsmanagement als Hauptanwendungszweck genutzt, aber im Kern geht es um die Systemarchitektur zur Beschreibung der Wirkungsweise eines mechatronischen Systems inkl. seines Verhaltens. MBSE ist damit die Weiterentwicklung des klassischen Systems Engineering – häufig wird es kurz definiert als „die formalisierte Anwendung von Modellen zur Unterstützung sämtlicher Aufgaben im Produktlebenszyklus“. Das Systemmodell unterstützt dabei grundsätzlich die Zusammenarbeit und Kommunikation aller im Projekt vertretenen Disziplinen; und das bereits sehr früh im Projekt – im Prinzip von der ersten Sekunde an. Aber langsam: Model-Based Systems Engineering liefert Methoden, mit denen Systemdenken wirksam unterstützt werden kann und auch abstraktes Wissen gesichert werden kann. Mit dem Systemmodell soll von Beginn des Lebenszyklus eine fachdisziplinübergreifende Systemspezifikation konsistent beschrieben und genutzt werden. Laut INCOSE ist MBSE “the formalized application of modeling to support system requirements, design, analysis, verification, and validation, beginning in the conceptual design phase and continuing throughout development and later life cycle phases” [INC07] Anwendung von MBSE Damit ist der Anwendungszweck des MBSE sehr breit gefasst. Zunächst kann es dazu dienen, das Planen und Klären der Aufgabe zu unterstützen. Wir empfehlen, bereits mit dem Produktmanager oder dem Vertrieb im Sinne des MBSE zusammenzuarbeiten. So können Kundenbedürfnisse viel leichter und eindeutiger in erste technische Spezifikationen übersetzt werden. So wird sukzessive eine Systemarchitektur entwickelt und die Modul- und Komponentenspezifikation vorangetrieben – und hierauf aufbauend wieder neue Aufgaben in der Projektarbeit ausgesteuert werden. Nach obiger Definition müsste das Systemmodell sich im Verlauf eines Lebenszyklus jedoch auch weiterentwickeln – je nach verfolgtem Zweck. Die möglichen Anwendungszwecke sind mannigfaltig! Ein guter Freund von uns – Rob Cloutier – sagt immer: Modellierung als Grundlage des MBSE ermöglicht Mit diesem Verständnis wird deutlich: MBSE ersetzt nicht die Modelle der Fachdisziplinen, sondern ergänzt sie. Zudem ist über die rein technische Sicht auch eine sozio-technische Komponente des MBSE erkennbar. INCOSE ist überzeugt, dass sich das MBSE als zentrales Paradigma der Systementwicklung etablieren wird. Versteht man MBSE als logische Weiterentwicklung des klassischen Systems Engineerings ist es im Einklang mit den Normen wie z.B. der ISO/IEC15288 auch Grundlage für die zahlreichen technischen oder techniknahen Managementaktivitäten im Lebenszyklus und damit viel stärker an den Entwicklungsprozess gekoppelt als häufig diskutiert. Damit werden die zwei Säulen des Systems Engineering, schön dargestellt mit dem „SE-Männchen“, auch nachvollziehbar, auf denen komplexe Projekte erfolgreich aufbauen: Systemarchitekturentwicklung und Projektmanagement. Wie geht MBSE eigentlich? – TUN ist unsere Antwort. So leicht ist es natürlich nicht, daher hier einmal noch ein Einblick in die absoluten Basics der Ansätze: Zur Erstellung des Systemmodells als Kern des MBSE bedarf es einer Beschreibungssprache, einer Methode und eines Werkzeug – z.B. iQUAVIS. Und motivierte Mitarbeiter, die etwas verändern und verbessern wollen! Trotz einiger Unklarheiten hinsichtlich des Begriffs „Systemmodell“ – über die Inhalte des Systemmodells herrscht weitgehend Einigkeit: Systemanforderungen, Systemarchitektur und Systemverhalten, nachfolgend noch einmal kurz erklärt. Systemanforderungen Es werden funktionale und nichtfunktionale Anforderungen unterschieden. Funktionale Anforderungen spezifizieren das Verhalten des Systems und dessen Komponenten. Nichtfunktionale Anforderungen definieren Eigenschaften eines Systems wie Zuverlässigkeit, Benutzbarkeit oder Änderbarkeit. Systemarchitektur Die Architektur beschreibt die Struktur des Systems und seiner Komponenten, ebenso die Schnittstellen zwischen den Komponenten und zu den Systemgrenzen. Für den Bereich des Maschinenbaus umfasst das häufig auch erste Gestaltinformationen, z.B. in Form von Hüllkurven oder Skizzen. Systemverhalten Durch die Architektur und die funktionalen Anforderungen ist das System beschrieben. Anforderungen sind jedoch häufig informale Textdokumente. Durch eine Formalisierung könnten Informationen rechnergestützt abgeleitet werden. Dies ist Aufgabe der Modellierung des Systemverhaltens. Inhaltlich sollte das Systemmodell mindestens die fachdisziplinübergreifend relevanten Informationen der Entwicklungsaufgabe enthalten. Genau genommen müssten das auch die für mehrere Disziplinen relevanten fachdisziplinspezifischen Daten sein – also sämtliche vom Systems Engineering betroffenen Disziplinen. Modellierungssprachen des MBSE Wie in einer echten Sprache unterliegt der Aufbau einer Modellierungssprache gewissen Regeln. Dies sind die entsprechende Syntax und Semantik: Syntax Die Syntax legt fest, wie die einzelnen Systemelemente in ihrer Art und in ihrem strukturellen Aufbau gestaltet sind. Die abstrakte Syntax ist das Regelsystem, das die Elemente und Bezeichnungen der Sprache definiert. Ähnlich zur natürlichen Sprache (Wörter, Buchstaben, …) sind es in den Modellierungssprachen Systemelemente, Ports, Merkmale der Elemente und die Beziehungen der Elemente untereinander. Die konkrete Syntax ist die grafische Repräsentation der abstrakten Syntax. Mit ihr werden grafische Modelle erstellt, deren Elemente auf die Elemente der abstrakten Syntax verweisen. Semantik Die Semantik legt fest, wie Modellkonstrukte miteinander verknüpft werden müssen, um eine Bedeutung zu haben (statische Semantik). Dies geschieht durch Bedingungen gegen die abstrakte Syntax. Die Bedeutung der Modellkonstrukte ist in der dynamischen Semantik enthalten. Modellierungsmethoden des MBSE („MBSE-Methoden“) Eine Modellierungsmethode definiert die Abfolge von Operationen, die zur Erstellung der einzelnen Modelle durchgeführt werden. Der Ablauf der meisten MBSE-Methoden orientiert sich an den Schritten Anforderungsdefinition, Design, Analyse, Verifikation und Validierung. Die Modellierungsmethode muss klar definieren, welche Informationen zu welchem Zeitpunkt wie detailliert notwendig sind – was jedoch eher die Ausnahme ist, da die Tiefe der Modellierung weder in Sprache noch in Methode vorgegeben sind. Grundsätzlich muss daher neben der Leistungsfähigkeit einer Modellierungsmethode auch immer ihre Wirtschaftlichkeit berücksichtigt werden. Sie enden mit der Erstellung der Architektur. Werkzeuge im MBSE Mit dem zur Erstellung des Systemmodells notwendigen Werkzeug wird häufig eine Software-Lösung in Verbindung gebracht. Und auch wenn ein „Fool with a Tool still a Fool“ ist – am Ende ist das