CONSENS – Das bedeutet klare Rahmenbedingungen, realistische Ziele und ein gemeinsames Verständnis der Entwicklungsaufgabe!
CONSENS
Disziplinübergreifende Modellierung mechatronischer Systeme
In der frühen Phase der Produktentwicklung ist die disziplinübergreifende Festlegung des Produktkonzepts und das gemeinsame Verständnis der Entwicklungsaufgabe der zentrale Erfolgsfaktor. Unsere Spezifikationstechnik CONSENS setzt genau hier an und überführt die Produktidee in eine fundierte technische Leistungsbeschreibung. In der Analyse-Phase können klare Rahmenbedingungen (Kontext), Anwenderverhalten (Anwendungsszenarien) und realistische Ziele (Anforderungen) schnell, effizient und leicht verständlich erhoben werden. In der Synthese-Phase werden die Funktionalitäten (Funktionshierarchie), die inneren Strukturen (Wirkstruktur) und das Systemverhalten allgemeinverständlich festgelegt.
Einsatzbereiche der Methode
Umsetzung der Methode
Die Umsetzung von CONSENS erfolgt in einer sehr effizienten, kurzen Workshop-Reihe. Je nach Produkt reichen hier schon zwei bis drei Termine. Die Methode ist intuitiv und wird am ersten Workshop-Tag von allen Teilnehmern erlernt.
Sie, als Auftraggeber, bringen die mit dem Produkt befassten Personen zusammen. Dies sind normalerweise Ansprechpartner aus den Bereichen Produktmanagement, Produktentwicklung, Vertrieb, Marketing, Produktion und ggf. Logistik. Sofern strategische Zulieferer eingebunden sind, sollten auch diese mitwirken. Häufig nimmt die oberste Führungsebene oder Geschäftsführung ebenfalls an unseren Workshops teil. Darüber hinaus stellen Sie möglicherweise bereits vorliegende Unterlagen, wie Anforderungen, erste Skizzen, Produktbeschreibungen, Konzepte, bereit. Gestartet werden kann jedoch auch auf Basis einer Idee oder einer einfachen Produktskizze auf dem berühmten Bierdeckel.
Wir, als Smart Mechatronics, bringen die Methode mit, unsere Erfahrung in der Moderation von heterogenen Workshop-Gruppen und die notwendigen Werkzeuge der späteren Dokumentation. Darüber hinaus – je nach Produkt – unsere technische Expertise für mögliche technische Lösungen. Unser Projektteam besteht aus mindestens zwei, selten mehr als vier Kollegen.
Mit entsprechender Nachbereitung der Workshops liefern wir die Projektergebnisse nach zwei bis drei Wochen. Für Ihre Planungssicherheit bieten wir diese Phase als Festpreis oder auf Basis von vorher festgelegten Tagessätzen an. Kleinere Projekte starten hier schon bei ca. 12 bis 14 Personentagen.
Ihr Nutzen
- Gesteigerte Effizienz im Entwicklungsprozess und kürzere Time-to-Market
- Ganzheitliches Verständnis des Projekts über alle Stakeholder
- Systematische Ermittlung und Rückverfolgbarkeit der Anforderungen
- Verbesserte Lastenhefte durch strukturiertes Requirements Engineering
- Reduzierung von Änderungen im Entwicklungsprozess
- Transparenz über die Auswirkung von Entscheidungen in komplexen Entwicklungsprojekten
- Effiziente Abstimmung zwischen den Entwicklungsbereichen anhand des Systemmodells
„Der Start in das MBSE mit CONSENS bietet den Vorteil, dass alle Ansprechpartner in der frühestmöglichen Projektphase in wenigen Workshops an einen Tisch kommen. Hier sprechen sie dieselbe Sprache und entwickeln ein gemeinsames Produkt- und Projektverständnis. Spätere Kosten durch Fehler nach Missverständnissen oder späten Änderungen in der Entwicklung werden hierdurch nachweislich deutlich gesenkt.“
Sebastian Triesch, Teamleiter Systems Engineering & Project Management
Disziplinübergreifende Modellierung in 6 Phasen
CONSENS steht für CONceptual design Specification technique for the ENgineering of mechatronic Systems.
Model-based Systems Engineering (MBSE) ist die Antwort auf die gestiegene Komplexität und Interdisziplinarität bei der Entwicklung mechatronischer Systeme. Im Mittelpunkt der Entwicklungsmethodik CONSENS steht das Systemmodell, welches dann den gesamten Entwicklungsprozess begleitet:
1. Umfeldanalyse
Das zu entwickelnde System wird zunächst als „Blackbox“ betrachtet, d.h. in diesem Schritt werden die Schnittstellen des Systems nach Außen untersucht und der innere Aufbau zunächst außer Acht gelassen. Das Systemumfeld wird definiert und die Schnittstellen zwischen System und Umfeld-Elementen spezifiziert. Im Model wird zwischen Energie-, Information-, Stoff-Fluss und den Störeinflüssen unterschieden.
Die Umfeldanalyse ermöglicht es uns, direkt zu Beginn ein gemeinsames Systemverständnis für alle Stakeholder zu generieren. Zudem ist die Umfeldanalyse die Basis, um Anwendungsszenarien und Requirements abzuleiten.
2. Anwendungsszenarien
Die Anwendungsszenarien beinhalten Verhaltensbeschreibungen des Systems, die die Nutzungssituationen allgemeinverständlich beschreiben und die Funktionalität des Systems festlegen. Die Beschreibung erfolgt in Textform, Grafiken oder auch ersten SysML-Diagrammen. Der gesamte Produktlebenszyklus wird untersucht und Benutzergruppen und Personas analysiert, damit alle Stakeholder des Systems berücksichtigt werden.
Das Ergebnis ist eine eindeutige Beschreibung der Systemfunktionen sowie eine Verdeutlichung der Produktnutzung und der unterschiedlichen Anwendergruppen über den gesamten Produktlebenszyklus.
3. Requirements
Aus den beiden zuvor erstellten Partialmodellen werden die Anforderungen an das System unter Berücksichtigung des Sophisten-Schemas systematisch erstellt. Die Dokumentation erfolgt je nach Komplexität und Kundenwunsch in Excel, Polarion oder einem anderen Requirements Engineering Werkzeug. Die Traceability zum Umfeldmodell und den Anwendungsszenarien wird hergestellt.
Es entsteht ein Anforderungsdokument, welches die Traceability gewährleistet, und aus dem sich, für die weitere Bearbeitung, die Haupt- und Subfunktionen ableiten lassen.
4. Funktionshierarchie
Aus der Analyse der Anforderungen wird das System zunächst funktional beschrieben. Den technischen Funktionen wird eine eindeutige Bezeichnung zugewiesen und sie werden in eine hierarchische Gliederung (Funktionsbaum) überführt. Mit Hilfe des Funktionsbaums lassen sich sowohl Module identifizieren und Redundanzen vermeiden als auch erste Überlegungen zur Priorisierung und Planung der zu entwickelnden Funktionen vornehmen.
Dieser Schritt liefert eine hierarchische Gliederung der Systemfunktionalität. Zudem ist eine Rückverfolgbarkeit der Anforderungen (z.B. aus Umfeldmodell, Anwendungsszenarien etc.) zu jeder Zeit gegeben.
5. Wirkstruktur
Jeder Funktion werden Lösungen (Systemelemente) in Form von Elektronik, Software oder mechanischen Bauteilen zugeordnet und zu einer Wirkstruktur verknüpft. Die einzelnen Systemelemente werden mit Stoff-, Energie- und Signalflüssen verbunden (Struktur des Systems inkl. Schnittstellen). Dabei werden Hierarchie- und Modulrelationen des Produkts berücksichtigt. Auf dieser Basis lässt sich sowohl eine Release-Planung aufbauen als auch Kostenreduzierungen identifizieren (Cost Improvement). Die Wirkstruktur stellt den ersten Übergangspunkt in die domänenspezifische Entwicklung und deren Tools dar.
Wir erhalten eine erste grobe Architektur mit der eindeutigen Darstellung der Schnittstellen/Module/Flüsse unter Berücksichtigung der beteiligten Domänen, z.B. Mechanik, Leistungs-, Steuerungselektronik, HMI, Software.
6. Verhaltensdefinition
Das Verhalten des Systems wird in Sequenz- oder Aktivitäts-Diagrammen oder in Zustandsautomaten modelliert. Diese werden in geeigneten Tools (z.B. Enterprise Achitekt mit SysML) beschrieben, um sie den umsetzenden Teams zur Verfügung zu stellen.
Die Verhaltensdefinition liefert eine verständliche Beschreibung der Abläufe innerhalb des Systems und bietet zusammen mit der Wirkstruktur den Übergang in die domänenspezifische Entwicklung und deren Tools.
Erfahren Sie mehr über CONSENS
Sehen Sie sich den Ausschnitt aus unserem Online Seminar an zur disziplinübergreifende Modellierung in 6 Phasen.
Ansprechpartner und Standorte
Dortmund
Paderborn
Köln
