CONSENS Methode + iQUAVIS-Software macht effizientes Engineering möglich

Veröffentlicht am

CONSENS – CONceptual design Specification technique for the Engineering of complex Systems 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 klare Definition einzelner Partialmodelle erlaubt eine gute Orientierung und Unterstützung bei der Modellierung, die besondere Visual Syntax, 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 ausgezeichneten 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 „die Zeichnung der Mechatronik“. Dieses wird innerhalb von zwei Phasen entwickelt: Analyse des Problems und Definition der Systemarchitektur. Das Vorgehen ist iterativ: Das prinzipielle Vorgehen, konkrete Anleitungen und Hilfestellungen zur Planung der Modellierung, Erzeugung und zur Nutzung der Partialmodelle und der möglichen Analysen unterstützen den Prozess und ermöglichen einen pragmatischen Einsatz für unterschiedliche Zwecke. FMEA, Produktmanagement, Sales, Systemsimulation – ganz neue Wege sind möglich. In der Analysephase bietet es sich an in Workshops zu agieren, um das geplante Produkt aus unterschiedlichsten Blickwinkeln zu analysieren – z.B. auch Service, Einkauf, Produktion.

 

Abbildung des mechatronischem Systemmodells CONSENS

Das Systemmodell umfasst nach CONSENS verschiedene Aspekte, die rechnerintern abgebildet ein kohärentes System von Partialmodellen ergeben:

  • Zu Beginn wird im Umfeldmodell die Systemgrenze festgelegt. Dabei wird das System als Black-Box betrachtet. Elemente aus dem Umfeld, die mit dem System in Beziehung stehen, werden identifiziert und die Wechselwirkung modelliert. Es bietet sich an, ein solches Umfeldmodell zu strukturieren und für jede einzelne Lebenszyklusphase zu modellieren. Häufig werden dabei die Phasen Maintenance oder auch Entsorgung vergessen.
  • Anwendungsszenarien beschreiben verschiedene Situationen und das gewünschte Verhalten des Systems in dieser Situation. Use Cases stehen hierarchisch über Anwendungsszenarien und definieren eine Kundenanwendung. Die Anwendungsszenarien brechen die Use Case auf die Systemebene herunter.
  • Auf Basis des  Umfeldmodells  und  der  Anwendungsszenarien  werden  Anforderungen  Diese werden in funktionale und nichtfunktionale Anforderungen unterschieden. Unglücklicherweise beginnt man in vielen Entwicklungsprojekten direkt mit der Identifikation und Dokumentation der Anforderungen. Dabei werden wichtige Dinge übersehen, die sich nur aus der Analyse des Umfelds und Anwendungsszenarien und Use Cases ergeben.
Abbildung der Analyse des Umfelds und Anwendungsszenarien
  • Im nächsten Schritt werden alle funktionalen Anforderungen in Funktionen in der Form „Substantiv Verb“ übersetzt und in der Funktionshierarchie abgebildet. Eine Unterteilung der Gesamtfunktion in Teilfunktionen erfolgt fortlaufend, bis für die untersten Funktionen Lösungsmuster oder Wirkprinzipien ausgewählt werden. Aus der Summe aller Wirkprinzipien   und   Lösungsmuster wird   eine   geeignete   Kombination   zur   Wirkstruktur synthetisiert. Dieser Schritt erfolgt meistens über einen Morphologischen Kasten, der jedoch nicht Bestandteil der Spezifikationstechnik CONSENS ist – und sich ehrlich gesagt nur auf sehr abstrakte Art bislang überhaupt einsetzen lässt.
  • Die Definition der Systemarchitektur erfolgt in dem Partialmodell Wirkstruktur. Diese stellt den Blick in das System dar. In der Wirkstruktur werden somit der grundsätzliche Aufbau und die prinzipielle Wirkungsweise eines mechatronischen Systems definiert.
  • Für das Verhalten werden die Anwendungsszenarien als Ausgangsbasis genommen. Im Partialmodell Verhalten/Zustände wird nun festgelegt, welche Ereignisse einen Zustandsübergang bewirken. Ist ein Regelkreis vorhanden, kann die Regelung als eine Abfolge von Aktivitäten im Partialmodell Verhalten-Aktivitäten beschrieben 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  und  Werden weitere Systemelemente benötigt, sind sowohl das Partialmodell Wirkstruktur als auch Gestalt anzupassen.
Mock-Up zur Anwendung von Methoden auf Basis des Systemmodells

Bei CONSENS wird also von einem „BlackBox“-Prinzip ausgehend, eine konkrete Darstellung der inneren Subsysteme als „WhiteBox“ erzeugt. Diese Subsysteme und ihre Wechselwirkungen werden in der Wirkstruktur modelliert. Die Wechselwirkungen können 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.

« Zur Beitrags-Übersicht