Systems Engineering

Standardisierung ist mehr als Erbsen zählen

Der zunehmende Funktionsumfang mechatronischer Produkte und ihre Vernetzung mit anderen Systemen erfordert einen ganzheitlichen Ansatz der Produktentwicklung. Das soll Systems Engineering (SE) leisten. Ohne Standards lassen sich die Werkzeugen und Methoden des SE jedoch nur schwer in die Produktentstehungsprozesse einbinden. Was der Prostep iViP-Verein und die Gesellschaft für Systems Engineering (GfSE) auf dem Gebiet der Standarisierung unternehmen, beschreibt Teil 4 unserer Serie.

Der größte Handlungsbedarf in punkto Standardisierung besteht bei der Schaffung einheitlicher Austauschformate und der Einbindung der SE-Werkzeuge in die PDM/PLM-Lösungen. Das ist nicht nur die Meinung von Sven-Olaf Schulze, dem Vorsitzenden der GfSE (siehe Interview), sondern deckt sich auch mit den Aussagen von Anwenderunternehmen und Softwareherstellern. Der Prostep iViP-Verein, in dem Hersteller und Zulieferer der Fertigungsindustrie gemeinsam mit IT-Anbietern und Vertretern der Wissenschaft und Forschung praxistaugliche Lösungen und Standards für Produktdatenmanagement und virtuelle Produktentwicklung entwickeln, beschäftigt sich deshalb schon seit einigen Jahren mit SE und der Frage, welche Informationen bei der(modellbasierten) Entwicklung komplexer mechatronischer Systeme eigentlich zwischen den Partnern ausgetauscht werden müssen.

Die Frage ist nicht leicht zu beantworten, weil die Methoden und Werkzeuge des SE selbst in den unternehmensinternen Entwicklungsprozessen noch nicht fest verankert sind. Von daher tun sich die Anwender schwer zu beurteilen, welche Informationen sie in welcher Form von den Partnern benötigen, um ihre Prozesse durchgängiger zu gestalten. „Große Probleme gab es in der Vergangenheit beim Spezifikationsaustausch im Requirements Engineering, das heißt ganz links oben im V-Modell der Produktentwicklung“, sagt Achim Seibertz, der auf Seiten der Prostep AG die SE-Aktivitäten des Vereins betreut. Im Rahmen des ersten SE-Projekts hat der Verein deshalb das ursprünglich von der Hersteller Initiative Software (HIS) definierte RIF-Format (Requirements Interchange Format) weiterentwickelt und als ReqIF-Standard in die OMG (Object Management Group) eingebracht. Aktueller Stand ist die Release 1.1, an der es laut Seibertz keine großen Änderungen mehr geben wird, um den Investitionsschutz der Implementoren sicherzustellen. Derzeit werden die ersten vier Implementierungen von namhaften IT-Anbietern im Implementor-Forum des Arbeitskreises gegeneinander getestet. Die Ergebnisse sollen im nächsten Workshop vorgestellt werden.

Anzeige

ReqIF ermöglicht den Austausch von Anforderungsspezifikationen zwischen verschiedenen IT-Lösungen, beispielsweise zwischen Doors beziehungsweise Doors Next und Integrity, und zwar in beide Richtungen: „Ziel der Implementierungen ist es, den Roundtrip zu unterstützen, das heißt die Übergabe der Spezifikation des OEM an den Lieferanten, der sie einliest und bearbeitet und mit seinen Änderungen wieder an den Auftraggeber zurückspielt“, betont Seibertz. „Wie mit den Delta-Informationen umgegangen wird, ist dabei nicht im Standard beschrieben, sondern in den Implementierungsrichtlinien, die Grundlage der Schnittstellenentwicklung sind.“

Austausch von Verhaltensmodellen

Während es für das Requirements Engineering inzwischen so etwas wie einen gemeinsamen Nenner gibt, der natürlich noch der Umsetzung in die Praxis harrt, klafft zwischen der Anforderungssicht und den disziplinenspezifischen Sichten auf das Produkt in den SE-Prozessen eine Lücke. Es gibt keinen verbindlichen Zwischenschritt, wie man von den Anforderungen zu einer abstrakteren Form der Produktbeschreibung, beispielsweise einer Funktionssicht kommt. „Die Modelliersprache SysML könnte diese Lücke schließen, ist aber aufgrund ihrer Wurzeln in der Softwareentwicklung für die Mechanikentwickler relativ komplex zu handhaben“, sagt Seibertz. Derzeit wird die Lücke in vielen Unternehmen bottom-up geschlossen, indem die einzelnen Disziplinen das Systemverhalten und die Logik der Software mit Werkzeugen wie Modelica oder Matlab Simulink abbilden und simulieren.

Um die Prioritäten für die nächsten Standardisierungsschritte festzulegen, hat der Prostep iViP-Verein Interviews mit Keyplayern in der Automobil- und Zulieferindustrie geführt und ausgehend vom V-Modell untersucht, welche Daten überhaupt in welchen Phasen anfallen und ausgetauscht werden müssen. „Wir haben uns gewissermaßen eine Landkarte erarbeitet, wo in den Prozessen welche Werkzeuge eingesetzt werden und wo wir die Welten besser zusammenbringen können“, erläutert Seibertz. Dabei hat sich unter anderem gezeigt, dass die Unternehmen bei der Beschreibung der Systemarchitekturen mit Hilfe von SysML oder ähnlichen Modelliersprachen noch ziemlich am Anfang stehen und deshalb auch keinen konkreten Handlungsbedarf für den Austausch dieser SE-Artefakte sehen.

Großes Interesse zeigten die Vereinsmitglieder hingegen an der Verbesserung der Austauschmöglichkeiten für Verhaltens- beziehungsweise Simulationsmodelle. Der Verein hat deshalb im Oktober letzten Jahres ein Projekt namens Smart Systems Engineering gestartet, mit dem Ziel, die im Rahmen des EU-Forschungsprojektes Modelisar entwickelte und zur Pflege an die Modelica Association übergebene Schnittstellenbeschreibung FMI (Functional Mockup Interface) in den SE-Prozessen zu verankern. FMI erlaubt es unter anderem, ein Modelica-Modell zu kompilieren und als Functional Mockup Unit (FMU) an einen Partner in der Zulieferkette zu übergeben. Der Partner kann in das Modell zwar nicht reinschauen, es aber in seine Modelica- oder Simulink-Umgebung einbinden und im Kontext simulieren. Ein ganz wichtiger Aspekt, um das in den Verhaltensmodellen steckende Know-how bei der unternehmensübergreifenden Collaboration zu schützen.

Da es den Standard schon gibt, stellt sich die Frage, was sich der Verein beim Smart Engineering Project konkret vorgenommen hat. Seibertz erläutert die Zielsetzung: „Mit der Beschreibung der Schnittstelle ist es nicht getan. Um sie in den Prozessen zu verankern, braucht man best practices. FMI-Format beziehungsweise die FMUs sind ja nur der Träger des Modells, aber definieren nicht, welche Informationen im einzelnen ausgetauscht werden. Man kann beispielsweise verschiedene Modelltiefen haben und muss festlegen, welche Modelltiefen für welche Simulationen benötigt werden. Wir wollen einen Referenzprozess mit entsprechenden Use Cases aufsetzen und Konventionen definieren, wann welche Modellinformationen ausgetauscht werden müssen, um den Prozess sauber zu unterstützen.“

Die Arbeitsgruppe des Vereins hat inzwischen die Use Cases für den Austausch von Verhaltensmodellen definiert und die Deliverables festgelegt, die Ende des Jahres zu Verfügung stehen sollen. Außerdem hat sie eine Roadmap für die weiteren Projektschritte definiert. Vorgesehen ist zum einen, die Lücke zwischen Anforderungsmanagement und Verhaltensmodellierung zu schließen. Zum anderen will sich die Arbeitsgruppe darüber Gedanken machen, wie eigentlich ein integriertes Informationsmodell aussehen muss, das die Integration der Verhaltensmodelle und anderer SE-Artefakte in das Product Lifecycle Management beziehungsweise die PLM-unterstützten Prozesse ermöglicht.

Die bislang definierten Use Cases sehen den Austausch der Verhaltensmodelle völlig losgelöst von den PLM-Lösungen vor. Das ist insofern kurios, als die FMI/PLM-Integration eigentlich schon bei der Entwicklung des Schnittstelleformats angedacht war. Sie ist nämlich zwingend erforderlich, um die Nachvollziehbarkeit (Traceability) sicherzustellen, wie Seibertz betont: „ Ohne PLM-Integration sind weder die Abhängigkeiten zu den Anforderungen, noch der Lebenszyklus der Verhaltensmodelle nachvollziehbar, was zugleich ihre Wiederverwendung erschwert.“ Das PLM-Integrationsthema wurde jedoch erst einmal zurückgestellt und soll nun in einer zweiten Projektstufe wieder aufgegriffen werden.

Integriertes Datenmodell für SE

Die Schwierigkeit bei der PLM-Integration von Verhaltensmodellen und anderen SE-Artefakten besteht darin festzulegen, welche Informationen eigentlich ins PLM-System propagiert werden sollen und welche gekapselt in den Autorensystemen beziehungsweise einem autorennahem Verwaltungstool verbleiben können. Dafür wäre es hilfreich, ein allgemein akzeptiertes Informationsmodell zu haben, das zu entwickeln jedoch nicht Aufgabe des Vereins sein kann beziehungsweise ihn überfordern würde.

Seibertz appelliert deshalb an die PLM-Hersteller, nicht nur abzuwarten, was Standardisierungsgremien wie das International Council on Systems Engineering (Incose) macht, sondern sich selbst darüber Gedanken zu machen, was in so ein Informationsmodell alles reingehört und wie das Themen wie Variantenmanagement und Abhängigkeiten dort abgebildet werden können.

Als Orientierungshilfe für ein solches Informationsmodell mag immerhin die von der Incose vorangetriebene Erweiterung des Step-Datenmodells in Richtung SE (AP 233) dienen, die in Anlehnung beziehungsweise zur Unterstützung des SE-Prozesses entwickelt wurde, wie er im Incose-Handbuch beschrieben ist. „Die AP 233 muss aber nicht der Weisheit letzter Schluss sein“, sagt Seibertz. „Zumindest in der Automobilindustrie sind mir noch keine relevanten Implementierungen bekannt.“ Eine der wichtigen Aufgaben für die Zukunft des Vereins sieht Seibertz darin, die Interessen der Automobilindustrie auf dem Gebiet des Systems Engineerings stärker zu artikulieren, die in Standardisierungsgremien wie Incose noch nicht gebührend berücksichtigt werden. -sg-

Michael Wendenburg, Sevilla (www.wendenburg.net)

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...