Pragmatisches Schnittstellendesign eines mechatronischen Systems

Eine Architektur kennen viele vom Hausbau. Ohne Architektur kann kein Haus gebaut werden. Die Architektur bestimmt, wie groß die Baugrube sein soll und welcher Raum wo hin gemauert wird. Genauso verhält es sich bei mechatronischen Systemen: Ohne Systemarchitektur können die Entwicklungsdomänen nur raten, welche Teilsysteme benötigt werden. Beim Hausbau stellt die Architektur allerdings vorwiegend die Struktur des Gebäudes in den Vordergrund. Im Kontext eines mechatronischen Systems geht die Architektur über die Darstellung des rein statischen Zusammenhangs der Teilelemente hinaus. Es müssen viele unterschiedliche Schnittstellen betrachtet, dargestellt und evtl. spezifiziert werden.

Die Architektur eines mechatronischen Systems entsteht in den meisten Fällen aus den Funktionen, die ein System zu erfüllen hat, und der Zuordnung dieser Funktionen zu logischen Elementen. Durch das Definieren der logischen Elemente eines Systems entsteht die statische Architektur. Statisch deswegen, weil Systemelemente eine fest definierte Beziehung untereinander haben. Die Verbindungen zwischen den Funktionen der Systemelementen stellen die internen Schnittstellen des System dar, über die Stoffe, Energien oder Informationen ausgetauscht werden. Die externen Schnittstellen werden ebenfalls in diesem Arbeitsschritt gefunden, da das System in irgendeiner Form mit der Umwelt interagieren muss.

Zielgruppen benötigen unterschiedliche Detaillierungsgrade

Nicht jede(r) Beteiligte(r) an der Entwicklung eines Systems ist an jedem Detail der Architektur interessiert. Daher ist es wichtig, Darstellungen zielgruppenorientiert aufzubereiten. Welche Zielgruppen ein System hat, zeigt ein Blick in die Stakeholderanalyse. Dort finden sich Mitarbeiter und Mitarbeiterinnen aus den Bereichen Vertrieb, Produktmanagement, Projektleitung aber auch der Geschäftsführung. All diesen Personengruppen liegt es fern, sich um die Details wie den Aufbau von Protokollinhalten einer Schnittstellen zu kümmern. Vielmehr muss der der Vertrieb dem Kunden erklären können, welche Features einer Schnittstelle realisiert und welche in einer späteren Version bereitstehen werden. Dagegen sind die Mitarbeiter und Mitarbeiterinnen aus den Entwicklungsdomänen notwendigerweise sehr stark an den Details interessiert und auch beteiligt, da hier die Entscheidungen getroffen werden, wie Schnittstellen zu realisieren sind.

Ein wichtiger Aspekt  beim Architekturentwurf von mechatronischen Systemen ist der Detaillierungsgrad. Ich stelle mir beim Entwurf oft folgende Fragen:

• Sind die anzuschließenden Dritt-Systeme im Umfeld des eigenen Systems mit zu betrachten, reicht ein großer Kasten für mein eigenes System aus oder müssen systeminterne Teilsysteme ebenfalls dargestellt werden?
• Reicht eine simple Relation zwischen zwei Elementen für das Verständnis aus oder muss auch dargestellt werden, welches Systemelement die Schnittstelle anbietet und welches Systemelement sie verwendet?

Stehen Sie vor solchen Fragen, sollten Sie den Fokus auf das Verständnis legen, denn nicht jedes Detail muss in das Schnittstellendiagramm aufgenommen werden, zumal die meisten Funktionen heutzutage schon in den vielen verfügbaren Standards dokumentiert sind.

Tipps zum Schnittstellendesign

Es gibt einige Tipps, die beim Schnittstellendesign nützlich sind:

Pragmatisch und einfach im Team

Die ersten Schritte bei der Erstellung der Systemarchitektur sollten unbedingt im Team erfolgen. Dazu empfiehlt es sich, ganz pragmatisch anzufangen und mit einem Stift auf dem Flipchart oder dem Whiteboard für alle Beteiligten sichtbar die ersten Skizzen des Systems zu erstellen. So können die vielen unterschiedlichen Blickwinkel auf das System sofort auf- und mitgenommen und während der Reise durch die Produktentstehung verfeinert werden.

Die Diskussionen im Team fördern das Verständnis, um den Sinn und Nutzen der Schnittstellen. Oftmals werden sogar Schnittstellen gefunden, die ein(e) einzelne(r) damit beauftragte(r) Mitarbeiter(in) nicht gefunden hätte.

Bei der Modellierung die Wiederverwendung im Blick

Als nächstes sollten Sie die ersten Skizzen mit einem geeigneten Modellierungs-Werkzeug in eine digitale Form überführen. Nur so bietet sich die Chance, diese Darstellungen als Bild oder vielleicht sogar als Modell wiederzuverwenden, Änderungen daran vorzunehmen und erneut zu veröffentlichen.

Ohne eine Digitalisierung der Ergebnisse wird die Architektur bei jedem Treffen neu skizziert. Dabei werden neue Schnittstellen entdeckt, andere dafür weggelassen oder die semantische Gleichheit von Schnittstellen übersehen. Im weiteren Verlauf des Entwicklungsprozesses führt das dazu, dass Schnittstellen gar nicht realisiert oder doppelt eingeplant werden.

Vorhandene Spezifikationen und Standards nutzen

Nicht jede Schnittstelle muss vom Systemarchitekten oder dem Entwicklungsteam in Eigenleistung spezifiziert werden. Durch die Referenz auf vorhandene Spezifikation von Normungsgremien ergibt sich die Chance, dass für die Realisierung der Schnittstellen auf bekannte Systemelemente zurückgegriffen werden kann. Dies beginnt beim Schuko- oder CEE-Stecker und hört bei den Software-Modulen für Protokollstacks wie zum Beispiel Bluetooth oder PROFInet auf. So können recht schnell neue Schnittstellen eingebaut und neue Funktionalitäten realisiert werden. Dieses Vorgehen unterstützt die Entscheidungen bzgl. „Make-or-Buy“ und reduziert gleichzeitig das Risiko von Fehlentwicklungen mit einhergehendem Zeitverzug.

Vergeben Sie Schnittstellen-IDs

IDs sind eindeutiger als Namen. Deswegen sollten die Schnittstellen des Systems durchnummeriert werden. Behalten Sie die IDs mindestens für die Lebensdauer des Systems bei, im Idealfall sogar darüber hinaus, da Sie so die Modularität des Systems fördern. Durch die Nutzung von IDs kann die Bezeichnung einer Schnittstelle geändert werden, ohne dass die Referenzen auf diese Schnittstelle und deren Spezifikation in den Realisierungen brechen.

Detaillieren Sie da, wo es nötig ist oder wo Unklarheiten herrschen

Die Schnittstellen und Verbindungen eines Systems zu finden und festzuhalten, sprich deren Existenz zu dokumentieren, ist vielleicht der wichtigste Schritt. Wurden alle Schnittstellen im Workshop von den Beteiligten gefunden, können die Spezifikationslücken bzgl. der Schnittstellen identifiziert werden. Diese Menge an noch zu spezifizierenden Schnittstellen sollte priorisiert werden, um Festlegungen für die Schnittstellen zu treffen, die bei der Realisierung die größten Risiken beinhalten können. Diese Schnittstellen sollten gezielt detailliert ausgearbeitet werden, damit klare Vorgaben an die Fachdomänen erfolgen können, um später die Integration der Systemelemente einfacher zu gestalten.

Lassen Sie Änderungen zu

Viele Systeme verändern sich während des Entwicklungsprozesses und teilweise auch im Anschluss. Das wirkt sich auch auf die Schnittstellen aus. Der Designprozess muss auf diese Änderungen, sowie auf neue oder geänderte Anforderungen vorbereitet sein. Die Systemarchitektur muss daher so gestaltet sein, dass die Änderungen, die akzeptiert werden, mit möglichst geringem Aufwand eingearbeitet werden können.

Inhalte einer Schnittstellen-Spezifikation

In einem Unternehmen sollte für jede Schnittstelle auch eine Schnittstellen-Spezifikation vorliegen. Entweder dient sie als Container für Referenzen auf die anzuwendenden Standards oder beinhaltet die proprietären Details der Schnittstelle.

Generell ist festzuhalten, dass alle Aspekte, die eine Schnittstelle ausmachen, gefunden werden müssen. Dazu gehört zuallererst der mechanische Aufbau, gefolgt von den Angaben zu Stoffen und den jeweiligen Mengen oder zur Art der übertragenen Energie. Die Schnittstellen der Informationstechnik müssen dazu noch Angaben zu den Protokolleinheiten beinhalten.

Je nachdem wie stark der Detaillierungsgrad der Schnittstellen in der Systemarchitektur ist, sind unterschiedlich viele Informationen in einer Spezifikation enthalten. In der oben genannten Reihenfolge (Stoffe, Energie, Daten) kann auch am ehesten auf Standards Bezug genommen werden. Je spezieller die Informationen sind, die eine Schnittstelle übertragen muss, desto weniger existieren dafür Standards. Hier drei Beispiele:

• Für die Spezifikation der PROFInet-Schnittstelle des eigenen Systems ist nur ein minimaler Aufwand nötig, da die Technik weitestgehend bekannt ist.
• Beim Auslesen von Wechselrichterdaten mittels Bluetooth müssen Sie hingegen auf den zugrunde liegenden BT-Standard und das genutzte Profil referenzieren, und zusätzlich die selbst definierten Protokolleinheiten beschreiben.
• Und bei bei der Neuentwicklung eines internen Hochgeschwindigkeitsnetzwerk zum Austausch von Prozessdaten müssen  Sie allen oben genannten Ebenen spezifizieren.

Fazit

Ein System ohne eine geeignete Architektur zu entwickeln, ist ein Risiko, das Sie unbedingt vermeiden sollten. Die Schnittstellen zu finden und zu spezifizieren ist besonders hilfreich, wenn es darum geht, Funktionen zu kapseln und die Architektur des Systems zu modularisieren. Durch eine gute Architektur und das dazugehörige Schnittstellendesign können im späteren Verlauf des Produktlebenszyklus einzelnen Systemelemente ausgetauscht, korrigiert oder verbessert werden. Dies unterstützt den Einkauf bei der Auswahl von Kaufteilen, reduziert Testaufwände und senkt auf lange Sicht das Risiko einer teuren Fehlentwicklung.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Benötigen Sie Hilfe beim Thema Systems Engineering, der Erstellung einer Systemarchitektur oder beim Schreiben von Lastenheften? Dann schauen Sie bei gerne https://bjoernschorre.de vorbei. Dort finden Sie weitere Informationen zum Mentoring-Programm im Systems Engineering und der Erstellung von Lastenheften.

Björn Schorre hat einen weiteren Beitrag im t2informatik Blog veröffentlicht:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.