Software

Grundlagen des Model Based Systems Engineerings

Aufgrund der Funktionsvielfalt technischer Produkte, insbesondere von solchen mit eingebetteter Software, erhöht sich die Interdisziplinarität der Produktentwicklung. Das Systems Engineering ist gefragt und mit ihm Methoden und Prozesse für eine durchgehende interdisziplinäre Produktentwicklung. Teil 2 unserer Serie zu dieser Thematik greift noch einmal die Grundlagen auf und erläutert an einem einfachen Beispiel, wie der Ansatz des Model Based Systems Engineerings (MBSE) in der Praxis genutzt werden kann, um ein disziplinübergreifendes Modell zu erstellen – und vor allem zu kontrollieren.
Abbildung 5: Anbindung der ersten Simulation an das Systemmodell.

Martin Eigner, Torsten Gilz, Radoslav Zafirov Lehrstuhl für Virtuelle Produktentwicklung (VPE), TU Kaiserslautern

Technische Produkte aus allen Branchen werden ständig um neue Funktionalitäten erweitert. Besonders aktuell sind neue Funktionen, die sich aus der Vernetzung von Produkten untereinander (beispielsweise über das Internet) ergeben. Dies bedingt vor allem einen größeren Umfang der in technischen Systemen eingebetteten Software und führt dadurch zu einer weiteren Erhöhung der Interdisziplinarität der Produktentwicklung. Für die einzelnen Entwickler ist es nicht mehr möglich, alle Aspekte des Systems zu verstehen und zu kontrollieren. Es fehlt somit in allen beteiligten Entwicklungsdisziplinen an einem Überblick über das gesamte System. Das ist einer der wesentlichen Gründe für eine aufwändige und fehleranfällige Integration von Software, Mechanik und Elektronik in den späteren Phasen von Entwicklung und Test. Es fehlen eine übergreifende Systembeschreibung sowie Methoden und IT-Werkzeuge zur Unterstützung interdisziplinärer Kollaboration.

Anzeige

Heute werden in der Regel disziplinspezifische Partialmodelle definiert. Daraus abgeleitete, oft nicht mehr aktuelle Dokumente dienen zum Informationsaustausch unter den Entwicklungsdisziplinen (Abbildung 1). Dadurch wird aber keine effektive, fehlerfreie Weiternutzung und Nachverfolgbarkeit der Entwicklungsergebnisse gewährleistet. Der Ansatz des Systems Engineerings adressiert diese Problemstellung aus der Produktentwicklung durch eine interdisziplinäre Betrachtung des Produkts über den kompletten Produktlebenszyklus. Dabei sind die klare Definition von Anforderungen an das zu entwickelnde System und die ständige Verifizierung und Validierung der Entwicklungsstände gegen diese Anforderungen von zentraler Bedeutung. Das daraus abgeleitete ‚Model Based Systems Engineering‘ (MBSE) erweitert den Ansatz durch die Modellierung eines Systemmodells in der frühen Konzeptphase über die Simulation zur Validierung der Systemanforderungen bis hin zum Test und weiteren nachgelagerten Phasen des Produktlebenszyklus. Die Kollaboration zwischen den beteiligten Disziplinen soll hier nicht mehr über Dokumente gesteuert werden, sondern sich auf zentral verfügbare und daher immer aktuelle, semantisch reiche Modelle stützen (siehe ebenfalls Abbildung 1).

Der MBSE-Ansatz ist aus dem Bedarf entstanden, ein Zusammenspiel der diversen Entwicklungswerkzeuge zu ermöglichen und Diskrepanzen zwischen disziplinspezifischen Dokumenten und Modellen zu eliminieren. Dabei soll von Anfang an mit der Aufnahme und Erfassung der Systemanforderungen in der Planungsphase ein zentrales Systemmodell angelegt werden. Es soll direkt auf den Anforderungen aufbauen, unter Mitwirkung aller Entwicklungsdisziplinen weiterentwickelt und validiert sowie als Referenz für die Detailentwicklung in jeder Disziplin weitergenutzt werden.

Im Folgenden wird eine Erweiterung des V-Modells aus der VDI-Richtlinie 2206 als Vorgehensmodell zum MBSE vorgeschlagen, in die das Systemmodell eingegliedert ist (Abbildung 2). Wie erläutert, soll das Systemmodell als erste Beschreibung und Spezifikation des Systems unmittelbar nach der Erfassung der Systemanforderungen angelegt werden. Entlang der linken Flanke des V-Modells sind die wesentlichen Systembeschreibungsartefakte des Entwicklungsprozesses eingegliedert. Dies sind: Anforderungen (A), Funktionen (F), logische (L) und physikalische (P) Systemelemente. Parallel dazu existieren drei einander überlappende Ebenen der Modellbildung:

Modellbildung u. Spezifikation

Modellbildung und erste Simulation

Disziplinspezifische Modellbildung und Simulation

Im Folgenden soll anhand eines überschaubaren Beispiels eines multidisziplinären technischen Systems das Vorgehen zum MBSE durchgespielt und jeweils vertieft auf die drei Ebenen eingegangen werden. Dabei werden neue Konzepte zur Systemmodellierung und zur Verwaltung von Systemmodellen aufgezeigt.
Ein inverses Pendel auf einem Schlitten (Abbildung 3) ist ein einfaches mechatronisches Beispiel, welches sich konstruktiv nur durch die Verwendung von Elektronik und Software umsetzen lässt. Das Ziel des Systems ist es, das Pendel entgegen der Gravitation in inverser Lage durch Bewegen des Schlittens auszubalancieren. Es wird an dieser Stelle repräsentativ für ein mechatronisches System verwendet. Entgegen der Anwendungsabsicht des MBSE ist der Komplexitätsgrad hier gering, jedoch dient das Beispiel an dieser Stelle der Veranschaulichung der neuen Konzepte.

1. Modellbildung und Spezifikation

Das Systemmodell auf dieser Ebene deckt das interdisziplinäre Spektrum der Systembeschreibung durch Anforderungen, Funktionen, Verhalten und logische Systemelemente ab und beinhaltet daher keine physikalischen Elemente (wie etwa Baugruppen oder Bauteile als detaillierte 3D-Geometrie).

Zur Erstellung des Systemmodells werden speziell dafür konzipierte Systemmodellierungssprachen eingesetzt, die das System mit seiner Struktur und seinem Verhalten, inklusive der Anforderungen, Systemumgebung und seiner Interaktion mit dieser Umgebung abbilden können. Es existieren heutzutage mehrere einsetzbare Systemmodellierungssprachen. Die bisher einzige offene und weltweit standardisierte Systemmodellierungssprache ist dabei die grafische ‚Systems Modeling Language‘ (SysML). Sie ist standardisiert und wird ständig durch die weltweit agierende ‚Object Management Group‘ (OMG) erweitert. SysML bietet aufgrund der einfachen Integration in bestehende UML-Autorenwerkzeuge einen hohen industriellen Verbreitungsgrad. Die Modellierung erfolgt grafisch über spezifische Diagramme für Anforderungen, Parameter, Verhalten und Struktur. Die resultierenden Modelle sind nicht direkt simulierbar, können jedoch simulationsrelevante Parameter, Gleichungen und die Topologie wiedergeben. Die grafische Modellierung über Diagramme hilft dem Ersteller, eine definierte Sicht oder einen Ausschnitt auf das System darzustellen und die verwendeten Elemente mit anderen Modellierungselementen in Bezug zu setzen.

Zur Unterstützung der Modellierung mit SysML wurde am Lehrstuhl für Virtuelle Produktentwicklung ein SysML-Profil (SE-VPE-Profil) entwickelt. Dieses bildet eine reduzierte, an die virtuelle Produktentwicklung angepasste Menge an Modellierungselementen ab. Hierzu zählen wie oben schon erwähnt Anforderungen, Funktionen und logische Systemelemente.

Ein mit einer Systemmodellierungssprache entwickeltes Systemmodell bringt große Vorteile im Hinblick auf die Durchgängigkeit im Entwicklungsprozess. Die Beschreibung der Systemstruktur zusammen mit den Systemanforderungen ermöglicht eine Nachverfolgbarkeit der Beeinflussung aller Systembeschreibungsartefakte (A-F-L-P) untereinander, was die Transparenz und Validierung des Systems in Hinblick auf seine Anforderungen erheblich erleichtert.

Beispielhaft zeigt Abbildung 4 verschiedene Modellelemente in einer Diagrammsicht. Erkennbar wird, dass sich die Zusammenhänge innerhalb des Systemmodells visualisieren lassen (traceability). Die Systemanforderung, dass das Pendel in mindestens 10 s in die aufrechte Position gebracht und gehalten werden soll, ist mit der Systemfunktion ‚Stabilisieren‘ querverbunden. Diese Systemfunktion ist wiederum mit dem Controller für die Bewegung verbunden, welcher das logische Systemelement als konstruktive Lösung repräsentiert.

Die Systemfunktionen dienen somit der funktionalen Strukturierung des Systems und ermöglichen eine funktionale Partitionierung. Die logischen Systemelemente realisieren diese Systemfunktionen und unterstützen die funktionale Partitionierung durch die Festlegung der konstruktiven Umsetzung.

Systemfunktionen und logische Systemelemente unterscheiden sich dadurch, dass Systemfunktionen realisierungsneutral sind (etwa ‚Messe Rotationswinkel‘), während logische Systemelemente implizit auf einer physikalischen Wirkung oder einer IT-technischen Ausprägung basieren. In diesem Fall ist dies ein optischer Rotationssensor mit maximal 100 Schritten für eine volle Umdrehung. Ein weiteres Beispiel ist die Stabilisierungsfunktion, welche durch eine elektronische PI-Regler-Schaltung realisiert werden kann. Eine alternative Realisierung wäre auch über einen entsprechenden Softwarealgorithmus denkbar. Die logischen Systemelemente bilden somit logische Einheiten, die in Entwicklungsteams fokussiert bearbeitet werden können.

Darüber hinaus unterstützt die Beschreibung des Verhaltens einer Funktion oder eines logischen Systemelements zusammen mit der Struktur im Systemmodell den Übergang zu der zweiten Ebene der Systemabbildung entlang des Vorgehensmodells (‚Modellbildung und erste Simulation‘, vergleiche Abbildung 2).

2. Modellbildung und erste Simulation

Auf der Ebene der Modellbildung und ersten Simulation kommen die sogenannten multiphysikalischen Simulationssprachen zum Einsatz. Sie erlauben es, primär das Verhalten – aber auch die Topologie – eines technischen Systems bis auf die Ebene mathematischer Gleichungen zu beschreiben und das System unter diversen Bedingungen zu simulieren. Beispiele für solche Sprachen sind Matlab, Simscape oder Modelica. Dabei ist Modelica die einzige nicht proprietäre Simulationssprache. Sie wird von der ‚Modelica Association‘ weiterentwickelt. Hierfür sind viele kommerzielle Tools verfügbar. Für Modelica und SysML existiert bereits eine Transformationsspezifikation (SysML4Modelica), die gemeinsam zwischen OMG und der Modelica Association abgestimmt wurde und somit einen Modelltransfer zwischen erster und zweiter Ebene ermöglicht.

Eine erste Simulation auf Systemmodellebene hat den großen Vorteil, dass verschiedene Lösungsalternativen quantitativ verglichen werden können, bevor wichtige Entscheidungen über die Partitionierung der weiteren Entwicklung in die einzelnen Disziplinen getroffen werden. Dadurch wird auch das Systemmodell konkreter, das später für eine Nachverfolgbarkeit der Systemanforderungen im Entwicklungsprozess bis auf die Ebene einzelner Eigenschaften (properties) eingesetzt werden soll.

Aufbauend auf dem in SysML beschriebenen Systemdesign des Pendels können Simulationen des Systems oder von Subsystemen weitergehende Aussagen über die Eigenschaften und das dynamische Verhalten liefern. Sie werden meist von Simulationsspezialisten entwickelt und bieten durch Parametermodifikation ein breites Anwendungsspektrum. Abbildung 5 zeigt das Systemmodell in SysML und die Verbindung zu einer Simulation, beispielsweise in Matlab/Simulink. Das Simulationsmodell erweitert die logischen Systemelemente mit Hilfe von simulierbaren Elementen aus der Bibliothek.

Für die interdisziplinäre Zusammenarbeit werden relevante Informationen in das Systemmodell integriert. Bezugnehmend auf das angeführte Beispiel könnten dies etwa Parameter für den Regler in Matlab/Simulink sein, die in das Systemmodell aufgenommen werden, um so die Spezifikation zu vervollständigen. Weiterhin ist es denkbar, dass Systemanforderungen – beispielsweise die maximale Pendelstrecke – sowie das definierte Verhalten zum Aufschwingen des Pendels aus SysML Eingangsinformation für eine Systemsimulation sind. Diese müssen entsprechend in die Simulationsumgebung überführt werden, um dann validiert zu werden.

3. Disziplinspezifische Modellbildung und Simulation

Die dritte Ebene der ‚disziplinspezifischen Modellbildung‘ im Vorgehensmodell (vergleiche Abbildung 2) umfasst die Modelle aus allen bekannten CAx-Tools für Modellbildung und Simulation der einzelnen Entwicklungsdisziplinen. Nach dem MBSE-Ansatz soll ‚top-down‘ entwickelt werden. Daher müssen die Modelle auf dieser dritten Ebene direkt auf dem gemeinsamen Systemmodell aufbauen und alle vereinbarten Randbedingungen aus dem Systemmodell einhalten. Auf diese Weise wird eine problemlose Integration der Entwicklungsergebnisse verschiedener Disziplinen für interdisziplinäre Simulationen in der Detailentwicklung ermöglicht.

Die disziplinspezifische Modellbildung unterliegt eigenen disziplinspezifischen Vorgehensmodellen. Die M-CAD-, E-CAD- und CASE-Autorensysteme (CASE – Computer Aided Software Engineering) haben eine hohe industrielle Verbreitung. Aus diesem Grund werden sie hier nicht im Detail behandelt, sondern als gegeben angeführt.

Abbildung 6 zeigt die Anbindung von disziplinspezifischen Modellen an ein Systemmodell. Über verschiedene Diagramme ist es möglich, entsprechende Sichten beispielsweise für Mechanik und Elektronik darzustellen. So könnten etwa geometrische Parameter wie die Länge des Pendels aus einem disziplinspezifischen M-CAD-Modell an das Systemmodell weitergegeben werden, um so auch die Auslegung des Reglers darauf abzustimmen. Ebenso sollte die Systemanforderung, dass die Anschlussspannung der Stromversorgung zwischen 11 und 13 V liegen soll, an die disziplinspezifische Entwicklung übergeben werden. Die Anbindung der disziplinspezifischen Modelle an das Systemmodell ist für das Systemdesign von großem Interesse. Ein transparenterer Bezug der im Systemdesign festgelegten Anforderungen, Systemelemente und Parameter auf disziplinspezifische Modelle verbessert die Konsistenz der disziplinspezifischen Entwicklungsergebnisse.

Modellverwaltung

Wird die disziplinspezifische Modellierung betrachtet, existieren neben den Autorensystemen (E-CAD, M-CAD, CAE, …) eine Vielzahl von Infrastrukturwerkzeugen zur Verwaltung der Modelle. Das Product Lifecycle Management (PLM) stellt das grundlegende Konzept zur Verwaltung der Modelle über den gesamten Lebenszyklus. Die in der frühen Phase erstellten Systemmodelle hängen eng mit den Produktmodellen zusammen. Die Verwaltung der Systemmodelle ist durch ihren interdisziplinären Charakter von großer Bedeutung und muss administrativ in die typischen Produktentwicklungsprozesse wie Freigabe, Änderung und Konfiguration eingebunden werden.

Abbildung 7 zeigt einen ersten konzeptionellen Prototyp zur Verwaltung der relevanten Systemelemente. Hierfür wurde auf Basis des SE-VPE-Profils ein Datenmodell entwickelt, welches in einem PLM-System implementiert wurde. Durch die Querbeziehungen zwischen den Systembeschreibungsartefakten A-F-L-P kann etwa die Verbindung einer Systemanforderung zu einem Teil oder die funktionale Zuordnung eines Teils abgefragt werden. Die A-F-L-Elemente des Systemmodells können an PDM/PLM-Stücklistenstrukturen (EBOM, MBOM) angebunden werden, welche die physikalischen Teile (P) des zu realisierenden Systems beinhalten. Der Einfluss einer Änderung – beispielsweise einer Anforderung – kann auf die in Beziehung dazu stehenden Funktionen, logischen Systemelemente und physikalischen Teile eingegrenzt und analysiert werden.

Zusammenfassung und Ausblick

Die innovative interdisziplinäre Produktentwicklung erfordert ein Überdenken von heutigen Methoden, Prozessen, IT-Lösungen und Organisationsformen. In diesem Beitrag wurde eine Erweiterung des V-Modells nach VDI 2206 aufgezeigt, welche auf die Herausforderungen der virtuellen modellbasierten Produktentwicklung näher eingeht. Des Weiteren wurde ein Beispiel für die funktionale Produktbeschreibung vorgestellt, welches einen leichteren Zugang zu den Methoden des modellbasierten Systems Engineerings für Organisationen ermöglichen soll, um eine interdisziplinäre Produktentwicklung zu unterstützen. Der Anwendungsbereich ist auf hierarchische und interne Strukturen sowie Querverweise zwischen Modell-Elementen fokussiert. Eine Integration des Systemmodells in ein PLM-Konzept beinhaltet die Verfolgung von Änderungen und Einflüssen auf Anforderungen, Funktionen, logische und physikalische Systemelemente.

Ein Management des Systemmodells ermöglicht erst die frühe Produktdokumentation und Qualitätssicherung. PLM wird hiermit durch die Einbeziehung einer systemorientierten Sichtweise zu einem System-Lifecycle-Management-Konzept (SysLM; nicht zu verwechseln mit SysML für die Systems Modeling Language!) erweitert. Die Integration des Systemmodells in PDM/PLM ermöglicht die Unterstützung aller Prozesse, die zur Definition der Systemarchitektur beitragen oder diese voraussetzen. Viele PDM/PLM-Hersteller haben damit begonnen, Lösungen hierfür anzubieten.

Die heutzutage verfügbaren Autorenwerkzeuge für die frühe Modellierung haben allerdings noch Defizite. Sie bieten unzureichende Schnittstellen beispielsweise zu Simulationswerkzeugen, disziplinspezifischen Modellierungsumgebungen oder Verwaltungssystemen. Das auf XML basierende Austauschformat XMI, spezifiziert durch die OMG, wird nur unzureichend implementiert, so dass ein Modellaustausch zwischen SysML-Autorenwerkzeugen nur bedingt möglich ist. Oft sind die Bedienoberflächen überladen und die Visualisierung der Diagramme ist nicht intuitiv. Dies führt zu einer geringen Akzeptanz solcher Werkzeuge bei den Entwicklungsingenieuren. Darüber hinaus setzen die Methoden des modellbasierten Systems Engineerings ein abstraktes Denken in Systemen voraus, welches insbesondere in der universitären Ausbildung stärker geschult werden muss.

Lehrstuhl für Virtuelle Produktentwicklung (VPE), TU Kaiserslautern Tel. 0631/205-3787, http://www.mv.uni-kl.de

Anzeige

Das könnte Sie auch interessieren

Anzeige

Systems Engineering

Komplexität einfach gemacht

Um einen durchgehend digitalisierten Produktionsprozess von der Planung bis zum fertigen Produkt zu gewährleisten und ein Produkt sogar darüber hinaus bis hin zum Recycling zu begleiten, bedarf es modernster Technologien.

mehr...

Studie

Wie Arbeit 4.0 funktioniert

Das Beratungsunternehmen Unity hat eine neue Studie mit dem Titel „Digitale Geschäftsprozesse und modelle verändern die Arbeitswelt“ vorgestellt. Diese soll Antworten auf die Fragen geben, die Manager und Führungskräfte derzeit umtreiben.

mehr...

PLM

Industrie 4.0: In der Realisierungsphase angekommen

Industrie 4.0 gilt als das zentrale Zukunftsthema produzierender Unternehmen. Vergleichbar ist die Situation in der Industrie heute mit der im Handel vor 15 Jahren. Auch hier bedrohte das Internet die etablierten Geschäftsmodelle der Unternehmen.

mehr...
Anzeige

Produktionssysteme

Openness for Global Success

Am 16. und 17. April 2013 findet in Hannover das 16. internationale ProStep-iViP-Symposium für Fach- und Führungskräfte aus aller Welt statt. Themenschwerpunkte sind Offenheit im PLM, Kollaboration und Systems Engineering.

mehr...

Newsletter bestellen

Immer auf dem Laufenden mit dem SCOPE Newsletter

Aktuelle Unternehmensnachrichten, Produktnews und Innovationen kostenfrei in Ihrer Mailbox.

AGB und Datenschutz gelesen und bestätigt.
Zur Startseite