CONSENS Methode

Im Systems Engineering fällt häufig der Begriff „CONSENS Methode“. Doch was ist das eigentlich und warum ist diese Methode so wichtig im Systems Engineering? Diese Frage erörtere ich in diesem Artikel und gehe auf das Thema „Systemmodell“ und „Systemarchitektur“ ein. Die CONSENS Methode kann übrigens in iQUAVIS umgesetzt werden, wir haben dazu einen separaten Beitrag geschrieben.

CONSENS Methode – was ist das?

CONSENS steht für CONceptual design Specification technique for the ENgineering of complex Systems und ist eine Spezifikationstechnik für die fachdisziplinübergreifende Zusammenarbeit in der Entwicklung mechatronischer Systeme.

CONSENS ist eine der wenigen bekannten MBSE-Modellierungsmethoden, die aus einem maschinenbaulichen Umfeld stammen und damit nicht nur software-lastige Produkte in den Mittelpunkt der Betrachtung stellt, sondern maschinenbauliche Systeme und Anlagen. Die Methode gibt eine Anleitung zur Erstellung eines Systemmodells, das (wie erwähnt) auf die Spezifikation eines mechatronischen Systems zielt.

Die klare Definition einzelner Partialmodelle erlaubt eine gute Orientierung und Unterstützung bei der Modellierung. Die besondere visuelle Syntax (das sind insbesondere die Farben und Formen der Modellelemente), die nach arbeitspsychologischen Prinzipien ausgelegt wurde, hilft in der täglichen Arbeit. Besonders hervorzuheben ist die Skalierbarkeit des Ansatzes – vom Kartenset in Workshops bis zur softwaregestützten Umsetzung in iQUAVIS kann CONSENS auf allen Ebenen der Zusammenarbeit seine Stärken entfalten.

Dreh- und Angelpunkt von CONSENS ist das sogenannte Systemmodell – häufig nennen wir es auch die „Mechatronische Zeichnung“. Dieses wird innerhalb von zwei Phasen entwickelt: Die Analyse-Phase dient dem Planen und Klären der Aufgabenstellung, mithin also dem Problemverständnis und der Identifikation der Anforderungen. In der Synthese-Phase wird das eigentliche mechatronische Produkt aus funktionaler und statischer Sicht definiert. Diese Aspekte zusammen bilden die Systemarchitektur.

Das Vorgehen ist iterativ: Mit fortschreitendem Projektverlauf ergeben sich Änderungen oder Konkretisierungen. Änderungen an einer Lösung induzieren neue Anforderungen und so weiter. Das prinzipielle Vorgehen von CONSENS, konkrete Anleitungen und Hilfestellungen zur Planung der Modellierung, Erzeugung und zur Nutzung der Partialmodelle und der möglichen Analysen unterstützen den Systems Engineering Prozess und ermöglichen einen pragmatischen Einsatz für unterschiedliche Zwecke. FMEA, Produktmanagement, Sales, Systemsimulation – ganz neue Wege sind möglich.

In der ersten Erarbeitung bietet es sich an, in Workshops zu agieren, um das geplante Produkt aus unterschiedlichsten Blickwinkeln zu analysieren – z.B. auch Service, Einkauf, Produktion.

Analyse-Phase

Die Analyse-Phase dient vor allem dem Planen und Klären der Aufgabenstellung. Der Fokus liegt daher bewusst nicht auf der Lösungsfindung, sondern auf den Anforderungen an ebendiese Lösung. Die Phase gliedert sich in die drei Sichten: Umfeld, Anwendungsszenarien und Anforderungen, die nachfolgend beschrieben werden.

Umfeldmodell

Beim Umfeldmodell wird das zu entwickelnde System als Blackbox angenommen und das Umfeld des Systems betrachtet. Ziel ist es, die relevanten Umfeldelemente zu identifizieren und ihre Beziehung zum System zu bestimmen. Im Beispiel sieht man ein mögliches System in einem Auto: Das Fensterheber-System. Es ist eingebettet in übergeordnete Systeme und weist zahlreiche Beziehungen dazu auf.

In CONSENS werden Lösungselemente grundsätzlich mit sechseckigen Modellelementen dargestellt, um sie visuell schnell von anderen Modellelementen unterscheiden zu können. Von diesen sechseckigen Modellelementen gibt es zwei Arten: Umfeldelemente werden gelb dargestellt, Systemelemente werden blau dargestellt. Darüber hinaus können auch Beziehungen visuell unterschieden werden. Gewünschte Beziehungen werden schwarz gefärbt, unerwünschte oder gefährlich Beziehungen können rot gefärbt werden. Im Beispiel ist dies der Fall für einen Fahrzeuginsassen, der durch das Fenster eingeklemmt werden könnte.

Das Umfeldmodell wird intuitiv eigentlich immer für die Betriebsphase des Produkts entworfen, hierhin führt fast immer der erste Gedanke. Doch auch andere Lebensphasen sollten in den Blick genommen werden. Ein Klassiker ist dabei zum Beispiel der Test im Rahmen der Produktion, der möglicherweise ein ganz anderes Umfeld für das zu entwickelnde System darstellt. Andere mögliche Lebensphasen sind Installation/Inbetriebnahme, Wartung oder Recycling.

Anwendungsszenarien

Anwendungsszenarien beschreiben verschiedene Situationen und das gewünschte Verhalten des Systems in dieser Situation. Dabei werden die Anwendungsszenarien typischerweise mit einer Beschreibung der Ausgangssituation und des gewünschten Verhaltens definiert. Auch Skizzen oder ähnliches sind möglich. Die Beschreibung erfolgt in dieser Phase textuell – sei es in Fließtext oder mittels Stichpunkten. Ein Anwendungsszenario ergibt sich aus einer Interaktion eines Umfeldelements mit dem System. Dementsprechend dient das zuvor erarbeitete Umfeldmodell als Grundlage für die systematische Erarbeitung der Anwendungsszenarien, die in Summe dann das gewünschte Verhalten des zu entwickelnden Systems beschreiben.

Wie schon zuvor im Fall des Umfeldmodells gilt es, den gesamten Produkt-Lebenszyklus in Betracht zu ziehen. Die konkret zu betrachtenden Aspekte hängen vom Produkt ab. Beispielsweise gibt es Unterschiede Produkten für die kundenanonyme Massenproduktion und kundenindividuellen Projekten. Typischerweise sollte aber berücksichtigt werden:

• Produktion und Logistig
• Vertrieb
• Installation / Inbetriebnahme
• Betriebsphase (inkl. Wartung)
• Entsorgung / Recycling

Anforderungen

Auf Basis des Umfeldmodells und der Anwendungsszenarien werden Anforderungen abgeleitet. Dabei sind natürlich auch weitere Quellen wie der Kunde, der Vertrieb oder das Produktmanagement zu berücksichtigen. Eine Unterscheidung in funktionale und nicht-funktionale Anforderungen hat sich schon häufig bewährt. Damit kann ein besseres Verständnis der Anforderung erreicht werden. Außerdem ist eine Möglichkeit, die Eindeutigkeit einer Anforderung sicherzustellen.

Grundsätzlich müssen Anforderungen eindeutig und messbar formuliert werden. Dabei helfen auch Satzschablonen und die Verwendung standardisierter Schlüsselwörter wie Muss / Soll.

Zahlreiche bewährte Methoden und bekannte Literatur beschreiben den Umgang mit Anforderung weit detaillierter als er durch die Methode CONSENS definiert wird. Sie stellen eine sinnvolle Ergänzung dar. Aus Sicht des Systems Engineerings und der Idee eines Systemmodells ist entscheidend, das Requirements Engineering als integralen Bestandteil anzusehen und Anforderung daher in das Systemmodell zu integrieren.

Synthese-Phase

Die Synthese-Phase dient der Lösungsfindung auf Basis der zuvor erarbeiten Anforderungen. Sie gliedert sich in die drei Aspekte: Funktionen, Wirkstruktur, Verhalten, die nachfolgend beschrieben werden:

Funktionen

In diesem Schritt werden alle funktionalen Anforderungen in Funktionen in der Form „Substantiv Verb“ übersetzt und in der Funktionshierarchie abgebildet. Dabei sollte stets beachtet werden, dass eine Funktion möglichst lösungsneutral sein sollte. Die „oberste Funktion“ die Gesamtfunktion des Systems. Darunter liegen die Hauptfunktionen. Die Funktionen werden dann soweit heruntergebrochen, bis zu jeder Funktion eine Lösung zugeordnet werden kann. Beim Herunterbrechen einer Funktion gilt, dass die Summe der untergeordneten Funktionen genau die übergeordnete Funktion realisiert.

Diese Methode kann als Kreativitätsmethode genutzt werden, um vielfältige mögliche Lösungen zu erkennen. Dieser Schritt erfolgt meistens über einen Morphologischen Kasten, der jedoch nicht Bestandteil der Spezifikationstechnik CONSENS ist.

Entscheidend im Sinne des Systemmodells ist die beschriebene Ausleitung der Funktionen aus den zuvor erarbeiteten Modellelemente sowie die Weiterverknüpfung auf die Lösungselemente, die durch Systemelemente beschrieben werden. So wird die letztlich die Traceability von den Anforderungen und deren Herkunft bis zur Lösung sichergestellt.

Wirkstruktur

Die für eine Systemarchitektur charakteristische Darstellung der Wirkzusammenhänge in einem System erfolgt in dem Partialmodell Wirkstruktur. Diese stellt den Blick in das System dar. In der Wirkstruktur werden der grundsätzliche Aufbau und die prinzipielle Wirkungsweise eines mechatronischen Systems definiert.

Die Wirkstruktur ergibt sich zum Einen aus der Ausdetaillierung des Umfeldmodells. Die zuvor beschriebenen Schnittstellen des Systems sind entsprechend zum berücksichtigen. Zum Anderen ergeben sich die Systemelemente aus der Erfüllung der geforderten Funktionen. Ein Systemelemente ist dabei prinzipiell ein Bestandteil des Systems, der aus Software, Hardware oder anderem bestehen kann. Hier wird ausdrücklich die Systemebene adressiert. Systemelemente können auch hierarchisiert werden, das bedeutet, dass ein Systemelement beliebig viel Systemelemente beinhalten kann, die ihrerseits auch durch eine Wirkstruktur dargestellt werden können. Allein der Übersicht wegen empfiehlt sich, auf einer Ebene bis zu 9 Systemelemente zu verwenden; sollten es mehr werden, ist eine Zusammenfassung bzw. Strukturierung zu prüfen.

Damit das zu entwickelnde System funktionieren kann, müssen die Systemelemente miteinander in Beziehung gesetzt werden. CONSENS unterscheidet dabei drei Beziehungstypen: Stoff- oder Materialfluss, Energiefluss und Informationsfluss. Jeder der drei Flusstypen hat einen anderen Strichtyp, sodass sie optisch leicht unterscheidbar sind.

Die Wechselwirkungen zwischen Systemelementen können übrigens auf physikalische Grundprinzipien (Energieerhaltungssatz, Massenerhaltungssatz) überprüft und korrigiert werden – ein Set an Regeln unterstützt die Modellierung einer plausiblen Systemstruktur als Summe aus Umfeldmodell und Wirkstruktur.

Verhalten

Für die Beschreibung des Verhaltens werden Zustands- und Aktivitäts- sowie Sequenzdiagramme verwendet. Mit Zuständen werden die Betriebszustände des Systems oder eines Systemelements definiert. Innerhalb eines Zustands werden Abläufe ausgelöst, die durch Aktivitätsdiagramme beschrieben werden. Sollen konkrete Szenarien herausgegriffen werden, kann dies mit einem Sequenzdiagramm gemacht werden. Damit eignet sich das Sequenzdiagramm typischerweise dazu, die Anwendungsszenarien formal abzubilden, während Zustände und Aktivitäten des Gesamtverhalten abbilden.

Traceability

Die Stärke eines Systemmodells ergibt sich nicht allein aus den Informationen der jeweiligen Sichten, sondern auch durch die hinterlegten Referenzen. Die Möglichkeit, bspw. nachvollziehen zu können, woher eine Anforderung abgeleitet wurde oder wie sie umgesetzt wird, ist die Grundlage um Change-Impact Analysen durchzuführen. So kann man im Fall von späten Änderungen die Auswirkungen verlässlich erfassen. Auch andere Methoden wie bspw. eine FMEA können auf den erarbeiteten Informationen aufgebaut werden.

Bei mechatronischen Systemen spielt die Gestalt häufig noch eine zentrale Rolle – Hüllkurven oder erste Skizzen helfen, die Ideen zu veranschaulichen. Ziel ist  die  Abstimmung  der  Bauräume,  Anordnung,  Lage,  Art  der  Wirkflächen. Die Gestalt ist nach CONSENS jedoch nicht als zentraler Bestandteil definiert sondern wird als Referenz in CAD Werkzeuge verstanden.

Umsetzung von CONSENS

CONSENS kann als erste Ausbaustufe als Workshop-Technik eingesetzt werden. Dabei werden die Modelle mit Hilfe von vorgefertigten Karten auf Pinnwände aufgebracht und die Modelle letztlich mit Stiften und von Hand erzeugt. Diese Technik ist sinnvoll für Projekt-KickOffs oder Teamabstimmungen. Gut denkbar ist auch, zentrale Modelle wie die Wirkstruktur als Zeichnung aufzubereiten und im Projektraum an eine Wand zu heften. CONSENS Modelle können damit der Kommunikation und Kooperation zwischen den Projektbeteiligten dienen.

Soll die Anwendung von Systems Engineering jedoch systematischer und umfassender erfolgen, wird eine Softwareunterstütztung benötigt. Sie leistet unter anderem:

• Die Wiederverwendung von Modellelementen
• Die Umsetztung von Traceability innerhalb des Modells sowie zu anderen Werkzeugen
• Automatische Generierung von Sichten
• Zugriff von verschiedenen Orten
• Gleichzeitigen Arbeiten an Modellen mit individuellen Berechtigungen
• Automatische Archivierung und sicheres Informationsmanagement

iQUAVIS setzt als MBSE-Plattform CONSENS um und bietet für die Modellierungssprache ein vordefiniertes Profil, mit dem Anwender unverzüglich starten können. Die CONSENS Methode kann übrigens in iQUAVIS umgesetzt werden, wir haben dazu einen separaten Beitrag geschrieben.

Mehr über unser Systems-Engineering-Tool iQUAVIS erfahren Sie hier.