oose
Komm am 21.06. auf unseren oose.campus zum perspectives.festival 🥳
DeutschDeutsch

Werkzeugintegration im MBSE mit SLIM: reicht das?

Blog offline

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Bei den Recherchen im Rahmen unseres durch das ZIM (Zentrales Innovationsprogramm Mittelstand) geförderten Forschungsprojekts FASforM (Functional Architectures of Systems for Mechanical Engineers) bin ich auf das Produkt SLIM des US-amerikanischen Herstellers interCAX LLC aufmerksam geworden.

In vielen Beratungssituationen bei Organisationen, die modellbasiertes Systems Engineering (MBSE) betreiben, hören wir den Wunsch der Entwickler nach einer besseren Integration aller Entwicklungswerkzeuge. Dafür gibt es gute Gründe: es geht vor allem um Konsistenz! Bilden die verfügbaren Tools lediglich Insellösungen für bestimmte Teilaspekte des SE-Prozesses ab, sind aber untereinander nicht vernetzt, so kommt die Datensynchronisation zwischen diesen Werkzeugen häufig einer Herkulesaufgabe gleich. Wird beispielsweise eine Anforderung in einem Anforderungswerkzeug geändert, so müssen natürlich die Auswirkungen dieser Änderungen auf das SysML-Systemmodell, die Konstruktionsdaten (CAD), das Simulationsmodell, etc., analysiert werden. Muss der dazu erforderliche Datenabgleich zwischen den Werkzeugen manuell und umständlich durchgeführt werden, so ist das natürlich sehr zeitraubend und fehleranfällig.

SLIM steht für Systems LIfecycle Management und ist eine Software, die als Integrationsplattform für Werkzeuge zur Systementwicklung dient. Im Zentrum steht das so genannte TSM, das Total System Model. Das TSM stellt quasi das zentrale Repository aller Modelldaten bzw. eines Verbunds von mehreren Modellen dar. interCAX bezeichnet es als digitale Blaupause ("digital blueprint") des Systems über den gesamten Lebenszyklus. Zu jedem Zeitpunkt enthält das TSM das interdisziplinäre SysML-Modell des zu entwickelnden Systems, sowie die domänenspezifischen Modelle, und natürlich die für die Traceability so wichtigen Referenzen zwischen diesen Modellen.

Aus technischer Sicht ist eine solche Integrationslösung natürlich sehr interessant und sicher auch enorm hilfreich, um das Konsistenzproblem in den Griff zu bekommen. Ähnliche Produkte gibt es auch von anderen Herstellern, z.B. PHX ModelCenter® von Phoenix Integration. Für uns als tool-unabhängiges Beratungshaus mit methodischem Schwerpunkt ist aber eine wesentliche Herausforderung damit noch nicht gemeistert.

Verschiedene, zweckgebundene Modelle eines zu entwickelnden Systems befinden sich naturgemäß auf unterschiedlichen Abstraktionsstufen. Die SysML ist ja auch zunächst nur eine Sprache, und diese Sprache kann auch auf unterschiedlichen Abstraktionsniveaus eingesetzt werden. Daher gibt es auch gar nicht das SysML-Modell, sondern mit der Sprache SysML kann ich beispielsweise eine funktionale, eine logische und eine physische Architektur ein- und desselben Systems modellieren - drei unterschiedlich abstrakte Modelle desselben Produkts.

Einen besonders großen Abstraktionssprung - oder vielmehr eine Lücke - gibt es beim Übergang von einer funktionalen Systemarchitektur in SysML zum Maschinenbau und der Konstruktion. Auf der einen Seite haben wir ein sehr abstraktes, technologie- und implementierungsneutrales Modell, bestehend aus funktionalen Systembausteinen. Auf der anderen Seite haben wir beispielsweise das CAD-Modell mit sehr konkret ausgestalteten, detailreichen Bauelementen des Systems, z.B. die exakt designten Karosseriebauteile eines Fahrzeugs.

Rein technisch lassen sich Brücken zwischen Werkzeugen mit Lösungen, wie z.B. SLIM, bauen, aber das reicht oft nicht. Der methodisch saubere Übergang, z.B. von den Funktionen zur Gestalt, wie er im Mechanical Engineering notwendig ist, lässt sich damit alleine nicht lösen. Vieles passiert dabei implizit in den Köpfen der Konstrukteure und Maschinenbauer, wobei diese viel Erfahrungswissen einbringen. Die Traceability geht dabei leider oft verloren. Warum sieht das Bauteil genau so aus, wie es aussieht? Welche Systemfunktionen wurden bei dessen Gestaltung realisiert? Diese Frage lässt sich später nur noch unzureichend beantworten.

Genau dieser Übergang vom funktionalen SysML-Modell zur gestaltgebenden Konstruktion ist zentraler Gegenstand der Forschung in unserem FASforM-Projekt. Derzeit läuft das Projekt an, erste Recherchen wurden durchgeführt und eine eigene Projektwebsite ist in Vorbereitung. Dazu später mehr.