MESCONF 2023
The Modeling Conference
22. Juni 2023 - 23. Juni 2023
Infineon Campeon, München
- 22. Juni 2023
- 23. Juni 2023
- Hauptraum
- Raum 1
- Raum 2
- Raum 3
Eröffnung der Veranstaltung durch das MESCONF-Team
With the OPS-SAT missions ESA has started a new approach building satellites based on off-the-shelf components for experimental purposes. The expectations were faster development cycles with most advanced technologies at lower costs.
With OPS-SAT in orbit ESA did a “lessons learned” analysis. Despite their very well organized and structured documentation of their missions, the fast development and the many OTS components lead to major challenges to keep the documentation consistent and up to date.
With their general strategy to move to MBSE ESA decided to do a reverse engineering of the OPS-SAT and feed the results into a model. This model will be used as input for further OPS-SAT missions.
GPP Communication retrieved information from existing documents and from many interviews with the engineers who had been involved in the OPS-SAT development. This information was entered into the OPS-SAT Model, which was later reviewed by ESA and the engineers.
The presentation will include some example-diagrams of the OPS-SAT reverse engineering project to discuss the structure and the methodology. It will also highlight, how ESA utilized the reverse engineering project to phase in MBSE methodologies in the organization – in hindsight an excellent approach, which might be applicable for other larger organizations as well.
Peter Gersing is a senior engineering manager at GPP Communication. Throughout his career Peter hold many engineering and management positions in the communication industry at Siemens and Nokia. He joined GPP Communication to run the MBSE project SPEDiT together with the TUM and other German universities. Based on this experience he supported many companies in training and coaching for the introduction of MBSE in their organizations.
Zeit zum Entspannen, Diskutieren und Networken.
Zum Entwicklungsstart einer nächsten Generation von elektrischen Servoantrieben wechselte das MotionControl Team bei FAULHABER auf die Modellierung der Software. Entwurf und Implementierung der neuen Gerätegeneration wurden komplett in Rhapsody umgesetzt. Die nötige Umstellung von bisher rein prozeduralem C in OO in C war erheblich, die Toolkette neu. Kommunikationsstacks wurden integriert, der Code für die Signalverarbeitung größtenteils über TargetLink ebenfalls modellbasiert erstellt. Inzwischen sind die Produkte seit deutlich über 5 Jahren im Markt und haben mehrere Pflegezyklen hinter sich und weitere Plattformen begonnen. Gezeigt werden soll, wie sich das Team dazu organisiert hat, welche speziellen Vorteile die Orientierung im Komponentenbaum für die Wartbarkeit hat und welche Erfahrungen – besser von Beginn an – berücksichtigt werden sollten.
Dr. Andreas Wagener studierte Anfang der 1990er Jahre in Erlangen elektrische Antriebstechnik. Bereits während der Arbeit an den Prüfständen für Hybridantriebe während der Promotionszeit trat Embedded Software Engineering neben die Energietechnik bis hin zu einer selbst erstellten, vollständigen Anbindung von C-Code aus Simulink in die in den Prüfständen verwendete Embedded-Umgebung. Fünf Jahre als Senior Application Engineer bei dSPACE waren eine Konsequenz daraus, bevor mit dem Wechsel in die Elektronikentwicklung bei der Dr. Fritz Faulhaber GmbH & Co KG die Antriebstechnik wieder der Schwerpunkt wurde. In der konsequenten Nutzung modellbasierte Werkzeuge für die dritte Generation FAULHABER MotionController konnten beide Themenschwerpunkte ideal verbunden werden. Dr. Wagener verantwortete die Entwicklung der Geräteplattform.
C-Code stellt mittlerweile die Ausnahme dar, da er als Bereichsleiter für Systems-Engineering einen abstrakteren Blick auf Geräteentwurf und -weiterentwicklung wahrnimmt.
Nicht nur die eingeladenen Speaker haben ein hervorragendes Wissen, auch jeder Teilnehmer ist ein Experte auf seinem Gebiet und der gemeinsame Austausch auf Augenhöhe ist für alle ein großer Gewinn. Der Open-Space ist dafür ein sehr schönes Format. Auf den vergangenen MESCONF-Veranstaltungen wurden diese Sessions von den Teilnehmern immer wieder als besonders lohnenswert hervorgehoben.
Wir erklären Ihnen vor Ort im Detail, wie das Format funktioniert. Jeder hat dort die Möglichkeit ein Thema vorzuschlagen. Sie haben jetzt schon ein Thema? Schicken Sie Ihren Vorschlag direkt an unseren Co-Organisator: tim.weilkiens@oose.de.
Bisher vorgeschlagene Themen finden Sie weiter unten.
Ein kurzer Einblick: Wie funktioniert open space?
Im open space wird unserer Fähigkeit zur Selbstorganisation bewusst Raum gegeben. Es kommen Menschen zusammen, die einen Beitrag leisten wollen und bereit sind, Verantwortung für die Umsetzung eines Themas zu übernehmen. Es gibt keine vorbereitete Tagesordnung und keine Redner mit Vorträgen oder Folienpräsentationen. Es gibt zunächst nur eine leere Wand, an der die Teilnehmenden ihre Anliegen / Themen veröffentlichen.
Ein Anliegen ist ein ganz bestimmter Aspekt oder eine Fragestellung im Zusammenhang mit dem Leitthema, das Einzelnen auf den Nägeln brennt und das mit anderen bearbeitet werden soll. Jedes dieser Anliegen bildet dann den Anlass für die Arbeit einer kleinen Gruppe, die sich zu einer vereinbarten Zeit an einem bestimmten Ort trifft. Größe, Arbeitsweise und Zusammensetzung der Gruppe sind selbstorganisiert.
Es gibt auch keine Gesprächsleitung oder Moderation, außer die Gruppe organisiert sie sich selbst. Kein spezielles Training muss absolviert werden, um an einer open space-Veranstaltung teilnehmen zu können. Erfahrungen, Wissen, Fertigkeiten und Gefühle sind die
Voraussetzungen, die erforderlich und in jedem Menschen vorhanden sind. Die Anliegen- / Themenwand bietet ein Raster aus Räumen und Zeiteinheiten. Alle, die ein Anliegen einbringen, ordnen dieses in das Raster ein, so dass allen klar ist, zu welcher Zeit und an welchem Ort das Anliegen bearbeitet wird.
Bereits vorgeschlagene Themen:
Empirical Software Engineering with Eye-Tracking
Insights in Model Based Software Engineering
Lisa Grabinger, Timur Ezer, Dominik Bittner, Jürgen Mottok
Software Engineering Laboratory for Safe and Secure Systems (LaS³)
OTH Regensburg
Eye-Tracking wird oft in der empirischen Forschung eingesetzt, um menschliches Verhalten und Aufmerksamkeitsmuster zu messen. Im Kontext der modellbasierten Softwareentwicklung können Eye-Tracking-Methoden dazu beitragen, die Benutzerfreundlichkeit und die Benutzererfahrung von Softwaremodellen zu verbessern.
Ein Beispiel für den Einsatz von Eye-Tracking in der modellbasierten Softwareentwicklung wäre die Analyse der visuellen Wahrnehmung von Benutzern bei der Interaktion mit einem Softwaremodell. Durch die Verfolgung der Augenbewegungen der Benutzer kann analysiert werden, welche Teile des Modells am meisten Aufmerksamkeit erregen und welche Teile möglicherweise übersehen werden. Diese Informationen können dann genutzt werden, um das Design des Modells zu optimieren und die Benutzerfreundlichkeit zu verbessern.
Ein weiterer möglicher Einsatz von Eye-Tracking in der modellbasierten Softwareentwicklung ist die Analyse von Benutzerverhalten bei der Durchführung bestimmter Aufgaben. Durch die Beobachtung der Augenbewegungen kann analysiert werden, welche Teile des Modells die Benutzer bei der Durchführung bestimmter Aufgaben unterstützen oder behindern. Diese Informationen können dann genutzt werden, um das Modell zu verbessern und die Leistung der Benutzer zu optimieren.
Zusammenfassend lässt sich sagen, dass Eye-Tracking ein wertvolles Werkzeug für die empirische Forschung in der modellbasierten Softwareentwicklung ist, da es dazu beitragen kann, die Benutzerfreundlichkeit und die Benutzererfahrung von Softwaremodellen zu verbessern.Dazu bietet das Eye-Tracking Labor, das im Rahmen des FHInvest-Projekts „Eyes on Future“ an der OTH Regensburg eingerichtet wurde, die Möglichkeit, statistisch signifikante Feldstudien durchzuführen und so wertvolle Erkenntnisse über das Verhalten und die Wahrnehmung von Benutzern bei der Nutzung von Softwaremodellen zu gewinnen.
Jenseits von Hype: Wo kann uns KI in Produktentwicklung und MBSE helfen?
Michael Jastram, Formal Mind GmbH
Klar, alle Welt spricht im Moment von KI. Doch wo sind die Anwendungen im Systems Engineering, die uns wirklich Zeit sparen, Qualität verbessern oder allgemein helfen, die Komplexität zu beherrschen? Um dieses Thema geht es: Was müsste eine KI können, um für Euch eine “Killer-App” im MBSE zu sein?
In diesem Open Space wollen wir konstruktive, spezifische Ideen sammeln. Ihr bringt Ideen und Pain Points, wir bringen KI-Domänen-Expertise. Zu KI gehört viel: “Langweilige” Technologien wie Bild- oder Textverarbeitung, aber auch noch nicht verfügbare wie Decision Intelligence oder Physics-Informed AI. Die im Moment gehypte generative KI (wie ChatGPT) ist schließlich nur eine von vielen KI-Technologien.
Über die Entwicklung der KI-Plattform Semiant haben wir viel Erfahrung gesammelt, wie wir konkrete Anwendungsfälle KI-gestützt umsetzen können. Insbesondere können wir helfen abzuschätzen, wie aufwändig es wäre, einen bestimmten Anwendungsfall umzusetzen. Oder über unser Verständnis von APIs und Integrationstechniken die Reichweite einer Idee zu untersuchen. Insbesondere eröffnet auch die SysML v2 API neue Wege der Integration, um KI und MBSE zusammenzubringen.
Die Ergebnisse aus dieser hoffentlich spannenden und engagierten Session werden wir hinterher zusammentragen und an die Teilnehmer verteilen.
Feature Branching / Varianten in ALM Tools? Was bieten die Tools und wie werden diese Mechanismen (in Bezug auf das Modell) eingesetzt?
Philipp Kalenda, LieberLieber
Hintergrund dazu ist, dass wir zwar Konzepte aus unterschiedlichen Tools kennen, diese aber teilweise nicht zu gängigen Konzepten aus Entwicklung (Branching, Versionierung, etc. passen). Da würden wir gerne Erfahrungen hören und evtl. Diskussionen Richtung Toolhersteller anstoßen.
Generative Methoden sind ein aktuell sehr präsenter Bereich der künstlichen Intelligenz. Spätestens seit der Veröffentlichung von Sprachmodellen wie GPT-3 und ChatGPT sowie darauf basierenden Text-to-Image Modellen wie DALL-E 2, Midjourney oder Stable Diffusion ist dieses Thema auch in der Öffentlichkeit angekommen.
Der Vortrag erkundet das Potential welches sich durch die Kombination von generativem, evolutionären Design und KI Modellen für die Entwicklung von technischen Komponenten und den Maschinenbau ergeben kann. Erste Forschungsergebnisse werden gezeigt und anhand dieser Ergebnisse werden auch Herausforderungen diskutiert.
Am Ende ergibt sich für die Zuhörer ein klareres Bild zu der Frage ob künstliche Intelligenz Maschinen bauen kann.
Jan Seyler hat in Heidelberg Scientific Computing studiert – ein Studiengang, der Mathematik, Physik und Informatik verbindet. Seine Promotion bearbeitete er bei Daimler und der Universität Erlangen-Nürnberg zum Thema „Formal Analysis of the Timing Behaviour of Ethernet for In-Car Communication“. Seit 2015 arbeitet der stolze Vater eines Sohnes bei Festo. Er begann als embedded Programmierer, baute dann die Semantische Datenplattform für Festo Produkte mit auf. Im Jahr 2018 war er einer der Verantwortlichen des Festo AI Competence Teams und leitet seit 2020 die Abteilung für Regelungstechnik und künstliche Intelligenz in der Festo Forschung und Vorentwicklung. Außerdem ist Jan Dozent für IoT und KI an der DHBW in Stuttgart und der Hochschule in Esslingen.
- Hauptraum
- Raum 1
- Raum 2
- Raum 3
In 2007 – also vor rund 16 Jahren – erblickte die Systems Modeling Language™ (SysML) 1.0 das Licht der Welt. In den folgenden Jahren hielt die Disziplin des Model-Based Systems Engineering (MBSE) mit der SysML zunehmend Einzug in viele Unternehmen aus allen Industrien und Branchen.
10 Jahre später konnte man dann auf einen breiten Erfahrungsschatz blicken und kannte die Stärken und auch Schwächen der Sprache. Damit wurde es auch Zeit für eine grundlegende Überarbeitung. 2017 hat das Standardisierungsgremium hinter der Sprache, die Object Management Group (OMG), eine Liste von Anforderungen, das sogenannte Request for Proposal (RFP), für eine Systems Modeling Language Version 2 veröffentlicht. Rund sechs Jahre später, Im März diesen Jahres, schloss das sogenannten SysML v2 Submission Team – ein Zusammenschluss von Vertretern aus diversen Unternehmen, Regierungsorganisationen und Hochschulen – seine Arbeit ab und übergab die Spezifikationsentwürfe an die OMG Finalization Task Forces (FTF). Das heißt, dass mit einer Veröffentlichung der SysML v2 spätestens im 1. Quartal 2025 zu rechnen ist.
Daher wird es höchste Zeit, sich einmal mit den Änderungen und Neuerungen der SysML v2 auseinander zu setzen. Was kommt da auf die Anwender zu? Was sind die neuen Features? Was ändert sich „unter der Haube“? Was passiert mit den bereits existierenden Systemmodellen, die auf der SysML 1.x basieren? Welche neuen Möglichkeiten bietet die SysML v2 in Bezug auf Simulation, Digital Twin/Digital Thread, PLM und künstlicher Intelligenz (AI4SE)? Auf diese Fragen versucht dieser Vortrag Antworten zu geben.
Als Trainer und Berater bei der oose Innovative Informatik eG unterstützt Stephan Roth Organisationen dabei, fit für das Komplexitätszeitalter zu werden. Seine thematischen Schwerpunkte sind das modellbasierte Systems Engineering (MBSE), Softwarearchitektur, Software Craft und Clean Code Development. Zudem arbeitet er in Standardisierungsgremien bei ISO mit und ist Mitglied in der Arbeitsgruppe zur Ausarbeitung eines Zertifizierungsprogramms für das Unified Architecture Framework® (UAF®) bei der OMG. Sein interdisziplinäres Wissen gibt er gerne in Trainings, Workshops, unterstützend im Projekt, oder auch in Buchform weiter.
Wie kann man Embedded Systeme möglichst effizient und gründlich testen? Kann model-based-testing (MBT) helfen? Was ist MBT überhaupt und wie kann ich es anwenden?
Im Vortrag betrachten wir zunächst, was Modelle sind und welchen Vorteil sie grundsätzlich in Entwicklung und Test bringen können. Durch die Abstraktion in den Modellen erreicht man ein besseres Verständnis für den Menschen. Durch Automatisierung können viele Schritte wesentlich beschleunigt und Fehler vermieden werden.
Anschließend sehen wir uns an welche Modellierungsmethoden fürs Testen von Embedded Systemen sinnvoll sind. In der Regel benötigt man für den Test von Embedded Systemen sowohl Methoden für die Ableitung und Generierung von Test-Cases als auch Methoden zur Umgebungssimulation. Bei beiden Aufgaben können Modelle helfen.
Abschließend wird anhand von Beispielen demonstriert, wie MBT in der Praxis aussehen kann.
Erst durch Beziehungen und Verlinkungen wird ein Modell intelligent. Durch diese Referenzen ist es möglich das Modell zu analysieren, zu validieren oder Information zu extrahieren (wie z.B. Reports, Code Generierung, etc.). Da Requirements oft aus ALM Tools stammen, wird eine Integration verwendet um einen Bezug zwischen Anforderungen und Architekturelement herzustellen. Wir von LieberLieber bieten mit LemonTree Automation und unseren LemonTree.Connect Integrationen eine Möglichkeit, in einer Build-Pipeline Verknüpfungen zwischen Anforderungen und Architektur automatisiert zu synchronisieren und dadurch konsistent zu halten.
Der Vortrag widmet sich zuerst der Erläuterung der LieberLieber ALM Integrationen und dem Prinzip „one leading system for data“. Danach wird erklärt wie Modelle in einer Build-Pipeline automatisiert überprüft und für Reviews bereitgestellt werden können. Als Abschluss wird in einer Live-Demo gezeigt, wie die Verknüpfungen zwischen Anforderungen und Modell über die Build Pipeline konsistent und aktuell gehalten werden.
Philipp Kalenda beschäftigt sich seit 2009 mit Software-Entwicklung und seit 2013 mit Enterprise Architect und modellbasierter Entwicklung. Er ist spezialisiert auf den Einsatz von UML, SysML und die Anpassung, Konfiguration und Erweiterung von Enterprise Architect (EA), für den Einsatz einer maßgeschneiderten Modellierungsmethodik. Neben der Modellierung ist sein zweites Spezialgebiet die Versionskontrolle mit Git oder SVN, in Kombination mit EA Modellen. Philipp Kalenda betreut Unternehmen aus verschiedensten Branchen bei der Einführung von MBSE, bei dem Aufsetzen einer entsprechenden Toolkette und schult den Einsatz diverser Tools wie Enterprise Architect, LemonTree, uvm.
Jeder Teilnehmer ist eingeladen, an der Eye-Tracking-Studie teilzunehmen.
Jeder Teilnehmer ist eingeladen, an der Eye-Tracking-Studie teilzunehmen.
Jeder Teilnehmer ist eingeladen, an der Eye-Tracking-Studie teilzunehmen.
In diesem Workshop zeigen wir live wie ein SW Design UML Modell erstellt und abgesichert werden kann um anschliessend mittels Codegenerierung für Embedded Systeme die Konsistenz zw. Design und Implementierung sicher zu stellen.
Wir zeigen mit IBM Rhapsody:
- Einführung: Welche Features werden für die Modellierung und Target Codegenerierung benötigt
- Modellierung: UML Modellierung eines Reaktionsspiels
- Funktionstest: Verifizieren der Funktionalität in virtueller HW Umgebung
- Target-Implementierung: HW Abstraktion und Portzugriffe entwickeln und Target Code generieren
- Test: Testen des Spiels auf dem Target
- Spiel: Wer reagiert am schnellsten?
- Gewinn: Die schnellsten bekommen als Gewinn ein Geschenk
Peter Schedl ist seit mehr als 20 Jahren im Bereich der Entwicklung mechatronischer Systeme tätig. Bereits in seinen Anfängen erkannte er den Wert eines ganzheitlichen System-, HW- & SW-Architekturdesigns. Er hat Erfahrung in der Anwendung von Methoden und Werkzeugen in der Luft- und Raumfahrt sowie in der Automobilindustrie über den gesamten Anwendungslebenszyklus. Derzeit konzentriert er sich darauf, Kunden bei ihrer digitalen Transformation einschließlich KI-Technologie zu unterstützen.
Patrick Weber ist ein erfahrener Systemingenieur. Er verfügt über mehr als 15 Jahre Erfahrung in der Entwicklung eingebetteter Systeme, insbesondere im Automobilbereich, wo er als Entwickler und Architekt tätig war. Patrick kam 2008 zu IBM und arbeitet seitdem als technischer Vertrieb für Model Based Systems Engineering in den Bereichen Luft- und Raumfahrt & Verteidigung, Automobilindustrie und Medizin.
Voraussetzungen für agiles Model Based Systems Engineering
Beim Model Based Systems-Engineering verwenden wir eine formale, strukturierte Sprache wie die SysML, um allen beteiligten Stakeholdern im Systems-Engineering Prozess die notwendigen Antworten auf ihre Fragen liefern zu können.
Dabei müssen wir uns unterschiedlichen Herausforderungen stellen, wie z. B. den Fragen: wer braucht welche Information zu welcher Zeit auf welchem Abstraktionsniveau mit wie vielen Details?
Diese Fragen sind wichtig, um ein Über-Engineering oder schlicht weg das Erfassen von unnötigen Informationen und Details zu vermeiden.
In dem Workshop zeigen wir unseren Best Practice Ansatz, um einen MBSE-Ansatz zu entwickeln.
Umsetzen von agilem Model Based Systems Engineering mit dem Enterprise Architect
Agiles Arbeiten heißt nicht zwangsläufig ohne Regeln mit allen Freiheiten zu arbeiten, eher im Gegenteil. Haben wir Regeln, können wir Modelle teilweise automatisch erstellen, validieren und voll- oder zumindest teilautomatisch umbauen und refactorn.
In diesem Workshop zeigen wir unsere Best Practices die Möglichkeiten des EA so auszuschöpfen, um ein möglichst agiles Arbeiten im MBSE zu ermöglichen.
Warum die unterschiedlichen (funktional, logisch und physikalisch) Architektursichten Sinn ergeben.
Das Architektur-Design heutiger komplexer (orthogonal vernetzter) Systeme ist nicht mehr auf Basis von einfacher ‚Hierarchischer Dekomposition‘ möglich. Verschiedene Sichten (Funktional, Logisch, Physikalisch) auf die Architektur ermöglichen eine mehrdimensionale orthogonale Darstellung.
Aber wie lassen sich die Zusammenhänge (Vernetzung) dieser Sichten managen? Das Vorgehen HarmonyMBE liefert hier Ansätze, die in der Präsentation gezeigt werden.
Die Nutzung von Software-intensiven Produkten verspricht den Anbietern neue Geschäftsmodelle. Wobei der immer weiter ansteigende Softwareanteil in Fahrzeugen eines der prominentesten Beispiele darstellt, dieser Trend jedoch auch in anderen Branchen zu beobachten ist. Mit dem erhöhten Softwareanteil steigt gleichzeitig auch die Komplexität und führt zudem zu erheblichen Änderungen in der E/E-Architektur.
In großen Projekten, bei denen unterschiedliche Ingenieurteams aus unterschiedlichen Disziplinen in getrennten Silos arbeiten, treten in der Regel Herausforderungen auf, wie das Arbeiten mit unverbundenen Anforderungen sowie nach Disziplin getrennten Ingenieursdaten und Modellen. Diese erhöhen das Risiko, den steigenden Inhalt in erwarteter, zertifizierbarer Qualität rechtzeitig und innerhalb des Budgets zu liefern.
In dieser Session diskutieren wir, wie man vertikale Designebenen und Ingenieurdisziplinen miteinander verbindet, angefangen bei den Anforderungen auf Systemebene bis hin zu den Engineering-Designs auf Komponentenebene, und horizontal von der Designphase bis zur Verifizierung und Validierung. Ein besonderes Augenmerk wird daraufgelegt, die Softwareentwicklungsprozesse mit den Prozessen der E/E-Architektur zu verbinden, während zu beobachten ist, dass sich die Architektur von dezentralisiert, über domänenzentralisiert bis hin zu zentralisierter Ausführung weiterentwickelt.
AUTOSAR Adaptive etabliert sich als Standard in der Automobilindustrie. Dieser Standard beeinflusst in einem Projekt alle unterschiedlichen Domänen wie Softwarearchitektur, Ecu Integration, Softwareimplementierung, Testen und muss für einen Erfolg des Projekts beherrscht werden. Hinzu kommt nun immer öfter die Anforderung einen insbesondere hinsichtlich Traceability geeigneten Übergang zwischen Systemmodellen und Softwaremodellen zu schaffen.
Diese Tooldemonstration soll einen Ansatz zeigen, wie man mit Rhapsody die einzelnen Domänen durchgängig adressieren kann. Dabei sollen anhand eines kleinen Beispielprojektes alle relevanten Teilschritte beleuchtet werden, wie mit Rhapsody ausgehend von einem gegebenen Systemmodel eine ausführbare und getestete Software entstehen kann.
Dabei wird insbesondere darauf eingegangen, welche unterschiedlichen Kopplungsmodelle es zwischen System und Software-Modellen gibt und wie sich der herkömmliche Einsatz von UML in der Softwareentwicklung unterscheidet zu dem Einsatz im AUTOSAR Kontext und was diese Unterschiede für das Testen bedeuten.
Vortragende: Dr. Hartmut Wittke (BTC Embedded Systems AG), Johannes Trageser (SodiusWillert).