MESCONF 2019
The Modeling Conference
- Tag 1
- Tag 2
- Alle
- Raum 1
- Raum 2
- Raum 3
- Raum 4
- Pausenbereich
Empfang, Kaffee, Teilnehmer kennenlernen
Eröffnung der 5. MESCONF durch das MESCONF-Team
Vortrag unseres Gastgebers Infineon über modellbasierte Entwicklung.
Aktuelles rund um das Manifest Modeling of Embedded Systems
Dieser Vortrag soll einen Einblicke und Erfahrungen bei der Einführung modellbasierter Methoden in einen Systems Engineering Prozess im Kontext von Automotiv geben.
Die Anpassung von akademischen Modellierungstechniken und Frameworks birgt immer neue Herausforderungen, die sich aus den realen praktischen Arbeitsweisen in Form von zusätzliche organisatorische und technische Anforderungen ergeben. Exemplarisch müssen akademische Modellierungsartefakte auf technische Artefakte abgebildet werden, und ein bekanntes Hauptthema ist die Erfassung mehrerer verschiedener Entwicklungsdisziplinen wie Systems Engineering, Software Engineering, Mechanik, Elektrik und Elektronik in einem Modell.
Mit diesen Aspekten im Fokus präsentieren wir den aktuellen Stand im Projekt SEED (Systems Engineering Enhancement@Daimler) und diskutieren unsere Erfahrungen.
Zeit zum Entspannen, Diskutieren und Networken.
Der Beitrag setzt sich mit den „Weltmodellen“ autonomer, kognitiver Automaten auseinander, die Kernfunktionen hochautomatisierter Systeme (Drohnen, Fahrzeuge, Waffen, …) ausmachen. Insbesondere interessiert der Aspekt ihrer Wechselwirkung mit den Menschen, die mit solchen Automaten kooperieren sowie der Grad ihrer Emanzipation von menschlichen Wahrnehmungen im Rahmen gültiger Werte und Normen.
Die Überlegungen setzen voraus, dass autonome Assistenzsysteme auf kognitiven Deep-Learning Funktionen sowie umfangreichen Sensor- und Daten-Netzwerken aufbauen. Damit werden sie im Betrieb nach sehr kurzer Zeit Situationsanalysen und –prädiktionen – basierend auf selbst generierten „Weltmodellen“ mit eigener Semantik – hervorbringen, die dem Menschen sowohl in ihrer Interpretation, wie in ihrer Logik und Zielsetzung zunehmend unverständlich werden. Die „Übersetzung“ des Automatenverhaltens – bspw. eine Vermeidungsstrategie – in eine „humane“ Semantik, dürfte nur noch am Anfang der Entwicklung und dann auch nur mit hohem Aufwand und Risiko möglich sein. Dennoch wird die Automatenstrategie in der überwiegenden Zahl der Situationen optimal und insbesondere besser als jegliche menschliche Strategie sein.
Der Mensch ist deshalb gut beraten, nicht zu intervenieren und die Entscheidungshoheit dem Automaten zu überlassen. Die Frage der Schnittstelle zwischen Mensch und Automat (MMS) reduziert sich damit notwendigerweise auf schlichte Elementarfunktionen, wie bspw. die Eingabe von Zielwünschen, Start- und Ankunftszeiten, Streckeninformationen oder ähnlich unkritischer Kommunikation. Interaktive Betriebseingriffe oder gar spontane Notfallübernahmen sind so gut wie ausgeschlossen, da dem Menschen weder die laufende modale Einstellung noch die situativ-strategische Disposition (eben das jeweilige „Weltmodell“) der Automatik vermittelt – sprich „übersetzt“ – werden kann. Ein „Human-in-the-Loop“ Betrieb ist nur denkbar, wenn alle kognitiven Funktionen weitgehend ausgeschaltet sind.
Da kognitive Funktionen permanent lernen, ggf. auch noch über Datenverbindungen („Cloud“) mit anderen Funktionen „gelernte Erfahrung“ innerhalb weniger (milli-)Sekunden austauschen und diese zeitnah in ihrem „Weltmodell“ verarbeiten, ist eine nachhaltig sichere „Human-in-the-Loop“ Integration aufgrund der hohen Adaptionsdynamik sowieso aussichtslos.
Die über diesen Mechanismus vom Menschen operativ entkoppelten Automaten werden konsequenterweise auch eine eigene, vom Menschen emanzipierte, Entwicklungsevolution verfolgen. Es steht zu erwarten, dass dabei auch die Gesetze von Mutation und Selektion keine unerhebliche Rolle spielen werden. Menschliche Intervention wird daher fast zwangsläufig zu eher unterlegenen Mutationen führen, die sich sehr bald von alleine aussortieren.
Der Beitrag erhärtet die vorstehenden Thesen an leicht nachvollziehbaren Fakten und Zusammenhängen. Er zeigt darüber hinaus, welche Konsequenzen diese Entwicklung für die Anwendung unserer rechtlichen und ethischen Normen haben wird.
Henning Butz war von 1988 bis 2009 in mehreren leitenden Funktionen der Systementwicklung und der Prozesstechnik bei Airbus in Hamburg, Bremen und Toulouse tätig. Seine Aufgaben betrafen alle mechanischen, elektrischen und elektronischen Systeme des Flugzeugs. Außerdem die Einrichtung der notwendigen Entwicklungsmethoden, -prozesse und –werkzeuge. Zuletzt leitete er den Unternehmensbereich „Aircraft Information Management & Electronic Networks“, mit Verantwortung für Entwicklung, Integration, Fertigung und Nachweis von Cockpit-Systemen und Avionik Plattformen sowie von Diagnose- und Wartungsfunktionen des Flugzeugs. Seit Anfang 2010 arbeitet Henning Butz als freiberuflicher Berater und Interim-Manager international in Technologie- und Entwicklungsprojekten für verschiedene Branchen der Transport- und Systemindustrie. Seine thematischen Schwerpunkte sind: Systemsicherheit, System-Architekturen und -Diagnose, Mensch-Maschine-Interaktion, Human Factors, RBE, MBD sowie neue Methoden, Prozesse, Werkzeuge des Systems Engineering. Henning Butz hat Physik, Elektrotechnik und Systemtechnik in Bochum und Karlsruhe studiert. Er ist Mitglied bei DFK, DGLR und GfSE.
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-Konferenzen wurden diese Sessions von den Teilnehmern immer wieder als besonders lohnenswert hervorgehoben.
Wir erklären Ihnen vor Ort, wie das Format funktioniert. Jeder hat dort die Möglichkeit ein Thema vorzuschlagen. Sie haben jetzt schon ein Thema? Schicken Sie Ihren Vorschlag an: tim.weilkiens@oose.de
Der Open-Space auf der MESCONF war ein toller Austausch von Wissen und Erfahrung. Die Beteiligten finden hier die Protokolle der Sessions. Sie dienen als Gedächtnisstütze, um sich an die Diskussionen zu erinnern und sind für Nicht-Beteiligte nicht geeignet.
 Open-Space Zeit-, Raumplan und Teilnehmerliste |
Open-Space-Protokolle |
Auswahl der Themenvorschläge für die MESCONF 2019:
Andreas Willert – Modelle als Digitales Lastenheft
In wie weit eignen sich Modelle um rein textbasierte Lastenhefte und Pflichtenhefte zu ergänzen oder zu ersetzen?
Was ist der Nutzen? (Frühzeitige Verifikation, Bessere Traceability …)
Wie ist der reifegrad in der praktischen Anwendung? Gibt es funktionierende Austauschformate für Modelle, z.B. wie ReqIF für Reqirements?
Phil Alder
Als Systems Engineer kämpfe ich oft mit 3 Tools gleichzeitig: DOORs für die Requirements, Rhapssody/EA für die Systemmodellierung und Eclipse/VS für die Quellverwaltung.
Nein, meistens kommt noch ein 4. Tool wie JIRA oder Redmine für das Bugtracking und die Planung hinzu. Geht das nicht irgendwie besser und voll integriert?
Alexander Huwaldt
Modellgetriebene Dokumentation in embedded Projekten
Auch das Projektmanagement bei der Entwicklung eingebetteter Systeme wird, vor allem bei schweren Softwareprozessen, oft durch das Vorlegen von Dokumentationen getriggert. Sind
Meilensteine erreicht manifestiert sich das in Dokumenten. Für das Controlling der Projekte stellen die in Word und Excel verfassten Darlegungen die Projektwahrheit dar. Tatsächlich sind solche Dokumente oft alles andere als ein echtes Abbild der Projektrealität.
Modellgetriebene Projekte bieten die Möglichkeit Dokumentationen aus dem Repository zu erstellen. Dabei gibt es nur eine Quelle und das ist immer das Modell (single source of truth).
Alexander Schneider
Abgrenzung zwischen Informal, Semi-Formal und Formal In Standards wie der ISO 26262 werden je nach Safety Integrity Level verschiedene Notationen empfohlen, bzw. verlangt. Unter Informal und Formal kann man sich noch etwas vorstellen. Aber was bedeutet Semi-Formal? Irgend etwas dazwischen, aber wo genau liegen die Grenzen? Und kann eine Modellierungssprache Formal sein, auch wenn sie nicht rein Mathematisch ist?
Michael Brahm
Im Rahmen unserer Systems Enginnering Arbeit sind viele verschiedenen Aspekte des Gesamtsystems abzubilden, wie etwa: Mechanische & Strukturmodelle, Verkabelung, Massenbudgets, Funktionale Anforderungen und Beschreibungen, Thermalmodelle und Beschreibungen, Beschreibung der verfügbaren Telemetriedaten, Beschreibung der Kommunikationsschnittstellen der Hardware, Beschreibung von Echtzeiteigenschaften, …
Für die meisten dieser Aspekte werden separate Datenformate und teilweise Modelle verwendet, obwohl es zwischen diesen Aspekten
durchaus Abhängigkeiten gibt. Ich wäre sehr daran interessiert zu erfahren wie andere Firmen die Komplexität solcher System handhaben und eventuell sogar in
einem gemeinsamen Modell oder einer gemeinsamen Datenbasis abbilden.
Rebecca Reuter & Jürgen Mottok
Eignung eines Lehrinstruments für die Modellierung mit der UML
Leckeres Essen und Zeit zum Austausch
Kaffee und Diskussion mit den anderen Teilnehmern über ihre Open-Space-Erfahrungen
Kaffee und Diskussion mit den anderen Teilnehmern über ihre Open-Space-Erfahrungen
Abendprogramm inklusive Abendessen
12.000 Jahre hat es gedauert, bis die Menschheit Ackerbau und Viehzucht überall zur Basis der Gesellschaft gemacht hat. Dann kamen vor 250 Jahren James Watt und seine Dampfmaschine. Mit der Industrie ernähren wir mehr als 7 Milliarden Menschen besser als zuvor eine, während wir die Erde an den Rand ihrer Existenz bringen. Und schon stehen wir vor einem ähnlich grundstürzenden Wandel. Nahezu alle Produkte verfügen künftig über eine eigene IP und werden zu Systemen unter Systemen. Die Maschinen lernen immer besser und schneller. Lernen wir schnell genug mit, welche maschinelle Intelligenz wir wofür brauchen und gebrauchen können? Und was an menschlichen Anstrengungen dafür nötig ist?
Ulrich Sendler, Jahrgang 1951, Werkzeugmacher, Dipl.-Ing. (FH) der Feinwerktechnik, CAD-Softwareentwickler, seit 1989 unabhängiger Journalist, Buchautor, Technologieanalyst und Redner im Umfeld virtueller Produktentwicklung und Digitalisierung. Autor von mehr als 15 Büchern und einer großen Zahl von Artikeln und Aufsätzen in unzähligen Zeitschriften. Unter den Büchern das „PLM-Kompendium“, 2009, „Industrie 4.0“, 2013, das ein Bestseller in China wurde, „Industrie 4.0 unbegrenzt“, 2017. Aktuelles Sachbuch: „Das Gespinst der Digitalisierung – Menschheit im Umbruch – Auf dem Weg zu einer neuen Weltanschauung“.
Gründer und Organisator des sendler\circle, einer Interessengmeinschaft der Anbieter von Software und Services für die Industrie. Herausgeber des Nachrichtenportals https://www.plmportal.org. Keynote-Sprecher zu Industrie 4.0 in Europa, China and Taiwan.
Keynote-Sprecher zu Industrie 4.0 in Europa, China and Taiwan.
Eröffnung der 5. MESCONF durch das MESCONF-Team
Vortrag unseres Gastgebers Infineon über modellbasierte Entwicklung.
Aktuelles rund um das Manifest Modeling of Embedded Systems
Dieser Vortrag soll einen Einblicke und Erfahrungen bei der Einführung modellbasierter Methoden in einen Systems Engineering Prozess im Kontext von Automotiv geben.
Die Anpassung von akademischen Modellierungstechniken und Frameworks birgt immer neue Herausforderungen, die sich aus den realen praktischen Arbeitsweisen in Form von zusätzliche organisatorische und technische Anforderungen ergeben. Exemplarisch müssen akademische Modellierungsartefakte auf technische Artefakte abgebildet werden, und ein bekanntes Hauptthema ist die Erfassung mehrerer verschiedener Entwicklungsdisziplinen wie Systems Engineering, Software Engineering, Mechanik, Elektrik und Elektronik in einem Modell.
Mit diesen Aspekten im Fokus präsentieren wir den aktuellen Stand im Projekt SEED (Systems Engineering Enhancement@Daimler) und diskutieren unsere Erfahrungen.
Der Beitrag setzt sich mit den „Weltmodellen“ autonomer, kognitiver Automaten auseinander, die Kernfunktionen hochautomatisierter Systeme (Drohnen, Fahrzeuge, Waffen, …) ausmachen. Insbesondere interessiert der Aspekt ihrer Wechselwirkung mit den Menschen, die mit solchen Automaten kooperieren sowie der Grad ihrer Emanzipation von menschlichen Wahrnehmungen im Rahmen gültiger Werte und Normen.
Die Überlegungen setzen voraus, dass autonome Assistenzsysteme auf kognitiven Deep-Learning Funktionen sowie umfangreichen Sensor- und Daten-Netzwerken aufbauen. Damit werden sie im Betrieb nach sehr kurzer Zeit Situationsanalysen und –prädiktionen – basierend auf selbst generierten „Weltmodellen“ mit eigener Semantik – hervorbringen, die dem Menschen sowohl in ihrer Interpretation, wie in ihrer Logik und Zielsetzung zunehmend unverständlich werden. Die „Übersetzung“ des Automatenverhaltens – bspw. eine Vermeidungsstrategie – in eine „humane“ Semantik, dürfte nur noch am Anfang der Entwicklung und dann auch nur mit hohem Aufwand und Risiko möglich sein. Dennoch wird die Automatenstrategie in der überwiegenden Zahl der Situationen optimal und insbesondere besser als jegliche menschliche Strategie sein.
Der Mensch ist deshalb gut beraten, nicht zu intervenieren und die Entscheidungshoheit dem Automaten zu überlassen. Die Frage der Schnittstelle zwischen Mensch und Automat (MMS) reduziert sich damit notwendigerweise auf schlichte Elementarfunktionen, wie bspw. die Eingabe von Zielwünschen, Start- und Ankunftszeiten, Streckeninformationen oder ähnlich unkritischer Kommunikation. Interaktive Betriebseingriffe oder gar spontane Notfallübernahmen sind so gut wie ausgeschlossen, da dem Menschen weder die laufende modale Einstellung noch die situativ-strategische Disposition (eben das jeweilige „Weltmodell“) der Automatik vermittelt – sprich „übersetzt“ – werden kann. Ein „Human-in-the-Loop“ Betrieb ist nur denkbar, wenn alle kognitiven Funktionen weitgehend ausgeschaltet sind.
Da kognitive Funktionen permanent lernen, ggf. auch noch über Datenverbindungen („Cloud“) mit anderen Funktionen „gelernte Erfahrung“ innerhalb weniger (milli-)Sekunden austauschen und diese zeitnah in ihrem „Weltmodell“ verarbeiten, ist eine nachhaltig sichere „Human-in-the-Loop“ Integration aufgrund der hohen Adaptionsdynamik sowieso aussichtslos.
Die über diesen Mechanismus vom Menschen operativ entkoppelten Automaten werden konsequenterweise auch eine eigene, vom Menschen emanzipierte, Entwicklungsevolution verfolgen. Es steht zu erwarten, dass dabei auch die Gesetze von Mutation und Selektion keine unerhebliche Rolle spielen werden. Menschliche Intervention wird daher fast zwangsläufig zu eher unterlegenen Mutationen führen, die sich sehr bald von alleine aussortieren.
Der Beitrag erhärtet die vorstehenden Thesen an leicht nachvollziehbaren Fakten und Zusammenhängen. Er zeigt darüber hinaus, welche Konsequenzen diese Entwicklung für die Anwendung unserer rechtlichen und ethischen Normen haben wird.
Henning Butz war von 1988 bis 2009 in mehreren leitenden Funktionen der Systementwicklung und der Prozesstechnik bei Airbus in Hamburg, Bremen und Toulouse tätig. Seine Aufgaben betrafen alle mechanischen, elektrischen und elektronischen Systeme des Flugzeugs. Außerdem die Einrichtung der notwendigen Entwicklungsmethoden, -prozesse und –werkzeuge. Zuletzt leitete er den Unternehmensbereich „Aircraft Information Management & Electronic Networks“, mit Verantwortung für Entwicklung, Integration, Fertigung und Nachweis von Cockpit-Systemen und Avionik Plattformen sowie von Diagnose- und Wartungsfunktionen des Flugzeugs. Seit Anfang 2010 arbeitet Henning Butz als freiberuflicher Berater und Interim-Manager international in Technologie- und Entwicklungsprojekten für verschiedene Branchen der Transport- und Systemindustrie. Seine thematischen Schwerpunkte sind: Systemsicherheit, System-Architekturen und -Diagnose, Mensch-Maschine-Interaktion, Human Factors, RBE, MBD sowie neue Methoden, Prozesse, Werkzeuge des Systems Engineering. Henning Butz hat Physik, Elektrotechnik und Systemtechnik in Bochum und Karlsruhe studiert. Er ist Mitglied bei DFK, DGLR und GfSE.
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-Konferenzen wurden diese Sessions von den Teilnehmern immer wieder als besonders lohnenswert hervorgehoben.
Wir erklären Ihnen vor Ort, wie das Format funktioniert. Jeder hat dort die Möglichkeit ein Thema vorzuschlagen. Sie haben jetzt schon ein Thema? Schicken Sie Ihren Vorschlag an: tim.weilkiens@oose.de
Der Open-Space auf der MESCONF war ein toller Austausch von Wissen und Erfahrung. Die Beteiligten finden hier die Protokolle der Sessions. Sie dienen als Gedächtnisstütze, um sich an die Diskussionen zu erinnern und sind für Nicht-Beteiligte nicht geeignet.
Open-Space Zeit-, Raumplan und Teilnehmerliste |
Open-Space-Protokolle |
Auswahl der Themenvorschläge für die MESCONF 2019:
Andreas Willert – Modelle als Digitales Lastenheft
In wie weit eignen sich Modelle um rein textbasierte Lastenhefte und Pflichtenhefte zu ergänzen oder zu ersetzen?
Was ist der Nutzen? (Frühzeitige Verifikation, Bessere Traceability …)
Wie ist der reifegrad in der praktischen Anwendung? Gibt es funktionierende Austauschformate für Modelle, z.B. wie ReqIF für Reqirements?
Phil Alder
Als Systems Engineer kämpfe ich oft mit 3 Tools gleichzeitig: DOORs für die Requirements, Rhapssody/EA für die Systemmodellierung und Eclipse/VS für die Quellverwaltung.
Nein, meistens kommt noch ein 4. Tool wie JIRA oder Redmine für das Bugtracking und die Planung hinzu. Geht das nicht irgendwie besser und voll integriert?
Alexander Huwaldt
Modellgetriebene Dokumentation in embedded Projekten
Auch das Projektmanagement bei der Entwicklung eingebetteter Systeme wird, vor allem bei schweren Softwareprozessen, oft durch das Vorlegen von Dokumentationen getriggert. Sind
Meilensteine erreicht manifestiert sich das in Dokumenten. Für das Controlling der Projekte stellen die in Word und Excel verfassten Darlegungen die Projektwahrheit dar. Tatsächlich sind solche Dokumente oft alles andere als ein echtes Abbild der Projektrealität.
Modellgetriebene Projekte bieten die Möglichkeit Dokumentationen aus dem Repository zu erstellen. Dabei gibt es nur eine Quelle und das ist immer das Modell (single source of truth).
Alexander Schneider
Abgrenzung zwischen Informal, Semi-Formal und Formal In Standards wie der ISO 26262 werden je nach Safety Integrity Level verschiedene Notationen empfohlen, bzw. verlangt. Unter Informal und Formal kann man sich noch etwas vorstellen. Aber was bedeutet Semi-Formal? Irgend etwas dazwischen, aber wo genau liegen die Grenzen? Und kann eine Modellierungssprache Formal sein, auch wenn sie nicht rein Mathematisch ist?
Michael Brahm
Im Rahmen unserer Systems Enginnering Arbeit sind viele verschiedenen Aspekte des Gesamtsystems abzubilden, wie etwa: Mechanische & Strukturmodelle, Verkabelung, Massenbudgets, Funktionale Anforderungen und Beschreibungen, Thermalmodelle und Beschreibungen, Beschreibung der verfügbaren Telemetriedaten, Beschreibung der Kommunikationsschnittstellen der Hardware, Beschreibung von Echtzeiteigenschaften, …
Für die meisten dieser Aspekte werden separate Datenformate und teilweise Modelle verwendet, obwohl es zwischen diesen Aspekten
durchaus Abhängigkeiten gibt. Ich wäre sehr daran interessiert zu erfahren wie andere Firmen die Komplexität solcher System handhaben und eventuell sogar in
einem gemeinsamen Modell oder einer gemeinsamen Datenbasis abbilden.
Rebecca Reuter & Jürgen Mottok
Eignung eines Lehrinstruments für die Modellierung mit der UML
Abendprogramm inklusive Abendessen
12.000 Jahre hat es gedauert, bis die Menschheit Ackerbau und Viehzucht überall zur Basis der Gesellschaft gemacht hat. Dann kamen vor 250 Jahren James Watt und seine Dampfmaschine. Mit der Industrie ernähren wir mehr als 7 Milliarden Menschen besser als zuvor eine, während wir die Erde an den Rand ihrer Existenz bringen. Und schon stehen wir vor einem ähnlich grundstürzenden Wandel. Nahezu alle Produkte verfügen künftig über eine eigene IP und werden zu Systemen unter Systemen. Die Maschinen lernen immer besser und schneller. Lernen wir schnell genug mit, welche maschinelle Intelligenz wir wofür brauchen und gebrauchen können? Und was an menschlichen Anstrengungen dafür nötig ist?
Ulrich Sendler, Jahrgang 1951, Werkzeugmacher, Dipl.-Ing. (FH) der Feinwerktechnik, CAD-Softwareentwickler, seit 1989 unabhängiger Journalist, Buchautor, Technologieanalyst und Redner im Umfeld virtueller Produktentwicklung und Digitalisierung. Autor von mehr als 15 Büchern und einer großen Zahl von Artikeln und Aufsätzen in unzähligen Zeitschriften. Unter den Büchern das „PLM-Kompendium“, 2009, „Industrie 4.0“, 2013, das ein Bestseller in China wurde, „Industrie 4.0 unbegrenzt“, 2017. Aktuelles Sachbuch: „Das Gespinst der Digitalisierung – Menschheit im Umbruch – Auf dem Weg zu einer neuen Weltanschauung“.
Gründer und Organisator des sendler\circle, einer Interessengmeinschaft der Anbieter von Software und Services für die Industrie. Herausgeber des Nachrichtenportals https://www.plmportal.org. Keynote-Sprecher zu Industrie 4.0 in Europa, China and Taiwan.
Keynote-Sprecher zu Industrie 4.0 in Europa, China and Taiwan.
Empfang, Kaffee, Teilnehmer kennenlernen
Zeit zum Entspannen, Diskutieren und Networken.
Leckeres Essen und Zeit zum Austausch
Kaffee und Diskussion mit den anderen Teilnehmern über ihre Open-Space-Erfahrungen
Kaffee und Diskussion mit den anderen Teilnehmern über ihre Open-Space-Erfahrungen
- Alle
- Raum 1
- Raum 2
- Raum 3
- Pausenbereich
Am Beispiel realer embedded Projekte werden die Möglichkeiten der modellgetriebenen Dokumentation aufgezeigt und die Arbeitsweise des Dokumentationsgenerators anhand von einzelnen Reports erläutert
- Struktur eines typischen SiSy Modells (Teilmodelle)
- SysML Perspektive
- Anwendungsfälle
- Requirements
- Hardware Resource Modell (HRM)
- UML Perspektive
- Projektmanagementperspektive
- Dokumentations Perspektive
- SysML Perspektive
- Rolle des Hardware Resource Model (HRM) für die Dokumentation
- Struktur eines HRM in SiSy
- Verknüpfung des HRM mit externen Resourcen/Modellen
- Rolle narativer Darstellungen im HRM
- Struktur typischer Dokumente (Generatorskripte)
- Dokumentationsgliederung
- Standardauswertungen
- Individualisierte Generatorskripte
- Übergang von der SysML zur UML-Perspektive
- Nutzen der SysML Perspektive
- Rückkopplungen der UML in die SysML-Perspektive
- Nutzen der UML
- Rolle der generierten Dokumente im Projekt
- Single source of truth Problematik
- Dokument Lifecycle
- verschiedene Projektbeispiele
- Diskussion
- Fazit
Systems Engineering und insbesondere MBSE wird in vielen Unternehmen zunehmend wichtiger, aber oft mit vielen Fragezeichen versehen. Wir wollen das ändern und zeigen MBSE live und erklären nicht nur was
- Anforderungsanalyse,
- funktionale Analyse,
- System Architektur Definition,
- Übergabe als digitales Lastenheft an die SW Entwicklung
bedeuten sondern auch wie es mit der richtigen Kombination aus Tool und Methode effizient geht.
Dieser Vortrag ist der Einstieg in eine Folge von drei Workshops, die einen modellgetriebenen Engineering Ansatz durch das V-Modell zeigen, vom Systems Engineering über die Verifikation bis zum Target-Code.
Die meisten Embedded Systeme werden zu spät oder nur unzureichend getestet. Fakt ist: Je später Fehler entdeckt werden, desto teurer ist die Behebung – die Kosten steigen exponentiell mit Fortschreiten des Projekts an. Hinzu kommen im Bereich von sicherheitsrelevanten Funktionen die hohen gesetzlichen Qualitätsanforderungen, welche mit Tests ausschließlich in den späten Phasen eines Projekts nicht erfüllt werden können.
Im Workshop wird eine entwicklungsbegleitende HIL Testmethodik für Microcontroller Systeme vorgestellt. Anders als bei herkömmlichen HIL Systemen erlaubt die Methodik bereits während der Entwicklung den Aufbau und die Durchführung automatisierter HIL Tests durch den Entwickler (Test First). Ermöglicht wird dies durch die Verwendung von kostengünstiger Standardhardware als Hardware in the Loop (HIL) Plattform in Kombination mit leistungsfähigen Modellierungswerkzeugen.
Der Vortrag endet mit einer Live Demonstration der Toolchain und einer anschließenden Diskussion.
Model-driven software or system development (MDE) is no longer an experimental method at Infineon today, but has established itself as an accepted standard for covering traceability requirements as well as for describing architecture and design. During a product development cycle the different models go through various iterations of changes and releases. Apart from baselining and variant management, configuration management enables product releases, analyses of design as well as further development happening all at the same time with different configurations.
For these purposes, the advantages of versioning systems have been successfully used for decades in the development of the source code. Infineon’s goal was therefore to reuse these established configuration management processes from software development for all artifacts, including models.
In this presentation, Infineon will present its requirements and challenges for the modeling tools regarding configuration management and will present its tool chain together with LieberLieber Software.
Es gibt einen immer stärker werdenden Trend hin zu digitalen Lastenheften. Einer der erwarteten Vorteile ist die Möglichkeit der frühzeitigen Verifikation (Shift Left gegenüber rein textbasierten Lastenheften). Aber nicht nur im Systems Engineering, auch im Software Engineering ist eine frühest mögliche Verifikation hilfreich.
In diesem Vortrag wird gezeigt wie eine frühe Verifikation von Modellen in der Praxis aussehen kann und welche Vorteile sich daraus ergeben. Es werden auch die Ansätze von TDD (Test Driven Development) aufgegriffen.
Dieser Vortrag ist der zweite in einer Folge von drei Workshops, die einen modellgetrieben Engineering Ansatz durch das V-Modell zeigen, vom Systems Engineering über die Verifikation bis zum Target-Code.
In unseren Projekten beobachten wir oft eine gewisse Unsicherheit in Bezug auf den Einsatz modellbasierter Testverfahren. Die erste Hürde beginnt schon bei der Definition. Die einen denken bei MBT sofort an MATLAB/Simulink-Modelle. Die anderen wenden zustandsbasierte Testentwurfsverfahren an, ohne dies explizit modellbasierten Test (MBT) zu nennen. Wieder andere nutzen Ablaufdiagramme für den System- und Abnahmetest.
Neben den vielfältigen Ausprägungen gibt es auch hinsichtlich der zu erwartenden Vor- und Nachteile immer wieder Fragen. Insbesondere wenn es um eine durchgängige Automatisierung der Testfallerstellung und Testdurchführung geht, sind die Erwartung oft sehr hoch gesteckt. Hier stößt MBT auch schon mal an seine Grenzen. Andererseits eröffnet der Ansatz Horizonte, die ohne MBT gar nicht sichtbar wären:
- Reduktion der Komplexität, welche dadurch überhaupt erst beherrschbar wird,
- automatische Erstellung und Pflege der Testfälle,
- Visualisierung von Zusammenhängen zwischen verschiedenen Anforderungen,
- verbesserte Kommunikation und damit auch verbesserte Qualität (sowohl der Anforderungen als auch der Tests),
- Messbarkeit der Testabdeckung
- u.v.a.m.
In einer gemeinsamen und offenen Vorstellung und Diskussion werden wir klären, welcher der vielen MBT-Ansätze sich in Ihrem Zusammenhang anbieten und worauf Sie unseres Erachtens den Fokus legen sollten.
Existiert nun ein Verifiziertes Modell (auch im Sinn eines Digital Twin), dann stellt sich die Frage: Wie wird daraus nun ein reales Produkt?
Hier kommt die automatisierte Codegenerierung ins Spiel. Ihr kommt in mehrfacher Hinsicht ein großer Stellenwert zu. Abgesehen von Arbeitseinsparungen über der Absicherung von Kongruenz zwischen Modell und Code ist der Ausschluss von Fehlern ein Hauptgrund.
Ist das Modell bereits in vielen Gesichtspunkten verifiziert, macht es keinen Sinn die Transformation in Code durch einen Arbeitsschritt durchzuführen, der den erreichten Reifegrad wieder in Frage stellt, sprich fehlerträchtig ist. Auch wenn viele Entwickler es nicht hören wollen, die Transformation durch menschliche Gehirne ist nachweislich um ein Vielfaches fehlerträchtiger als durch einen Automaten (Codegenerator).
Soll also die Qualitätsstufe der verifizierten Modelle beibehalten werden hat sich die automatisierte Transformation als sinnvoll herausgestellt.
Aber dazu muss der generierte Code Ansprüchen genügen, die über die reine Ausführbarkeit hinausgehen. Produktivcode muss performant und sicher sein. Dies wird oft als eines der Hauptargumente gegen die Codegenerierung genannt – zu unrecht. Dieser Vortrag wird sich mit den verschiedenen Möglichkeiten der Codegenerierung, deren Vorteilen und Grenzen auseinandersetzen.
Abschließend wird gezeigt, wie die Verifikation der Modelle nun auch zur Verifikation des Codes wiederverwendet werden kann.
Dieser Vortrag ist der letzte in einer Folge von drei Workshops, die einen modellgetrieben Engineering Ansatz durch das V-Modell zeigen, vom Systems Engineering über die Verifikation bis zum Target-Code.
Modellierung, Codegenerierung und Portabilität von Mikrocontrolleranwendungen wird oft im Widerspruch mit Effizienz und Performance gesehen. In diesem Workshop modellieren und realisieren die Teilnehmer eine IoT Lösung mit Erfassung von Sensorwerten und einer Fernsteuerung von Aktoren über das Intranet. Der embedded Webserver wird mit der UML modelliert und auf einem Infineon XMC4500 implementiert. Nach der erfolgreichen Realisierung auf dem 32 Bit ARM Cortex M4 wird die Anwendung mit wenigen Handgriffen auf einen wesentlich kleineren und leistungsschwächeren 8 Bit Microcontroller portiert und die Performance der modellgetriebenen Applikation getestet. Teilnehmer, die den Workshop aktiv als Hands On Training nutzen wollen müssen ein Notebook mit folgenden Systemanforderungen mitbringen:
- mindestens zwei USB Anschlüsse
- Netzwerkanschluss RJ45
- Windows Betriebssystem, ab XP
- mindestens 2 GB RAM
- mindestens 1 GB frei verfügbaren Platz auf der Festplatte
- Administratorrechte für die Installation von Software und Treibern
Die im Workshop verwendete Modellierungssoftware kann auch bereits vorher installiert werden. Wenden Sie sich dazu per Mail an k.esche@sisy.de.
Die Zeit ist reif für die nächste Generation der Systems Modeling Language (OMG SysML). Vor über 10 Jahren wurde die SysML Version 1.0 von der Object Management Group (OMG) veröffentlicht. Das Ziel war eine einfache, aber mächtige Modellierungssprache für ein breites Spektrum an Systems Engineering Aufgaben.
Wir haben in der Zwischenzeit viel über SysML aus ihrem Einsatz in der Industrie gelernt. Dazu gehören ihre Stärken, aber auch ihre Schwächen. Gleichzeitig wird das modellbasierte Systems Engineering (MBSE) immer beliebter und wichtiger für eine Vielzahl an Unternehmen der Produktentwicklung. Das führt zu immer mehr Anforderungen an die SysML.
Im Dezember 2017 hat die OMG das RFP for SysML v2 veröffentlicht. Es ist eine lange Liste von Anforderungen an eine neue Version 2.0 der SysML. Nun liegt es an sogenannten Submission Teams, mit einer neuen Modellierungssprache auf das RFP zu antworten. Aktuell arbeiten zwei – leider konkurrierende – Teams an der SysML v2.
Im Juni 2018 hat die OMG noch das SysML API & Services RFP veröffentlicht. Es startet die Entwicklung an einem bahnbrechenden Standard für die Modellierung mit SysML und somit für MBSE.
Der Vortrag stellt die Anforderungen an die neue SysML vor und zeigt auf was uns demnächst erwartet.
Am Beispiel realer embedded Projekte werden die Möglichkeiten der modellgetriebenen Dokumentation aufgezeigt und die Arbeitsweise des Dokumentationsgenerators anhand von einzelnen Reports erläutert
- Struktur eines typischen SiSy Modells (Teilmodelle)
- SysML Perspektive
- Anwendungsfälle
- Requirements
- Hardware Resource Modell (HRM)
- UML Perspektive
- Projektmanagementperspektive
- Dokumentations Perspektive
- SysML Perspektive
- Rolle des Hardware Resource Model (HRM) für die Dokumentation
- Struktur eines HRM in SiSy
- Verknüpfung des HRM mit externen Resourcen/Modellen
- Rolle narativer Darstellungen im HRM
- Struktur typischer Dokumente (Generatorskripte)
- Dokumentationsgliederung
- Standardauswertungen
- Individualisierte Generatorskripte
- Übergang von der SysML zur UML-Perspektive
- Nutzen der SysML Perspektive
- Rückkopplungen der UML in die SysML-Perspektive
- Nutzen der UML
- Rolle der generierten Dokumente im Projekt
- Single source of truth Problematik
- Dokument Lifecycle
- verschiedene Projektbeispiele
- Diskussion
- Fazit
Model-driven software or system development (MDE) is no longer an experimental method at Infineon today, but has established itself as an accepted standard for covering traceability requirements as well as for describing architecture and design. During a product development cycle the different models go through various iterations of changes and releases. Apart from baselining and variant management, configuration management enables product releases, analyses of design as well as further development happening all at the same time with different configurations.
For these purposes, the advantages of versioning systems have been successfully used for decades in the development of the source code. Infineon’s goal was therefore to reuse these established configuration management processes from software development for all artifacts, including models.
In this presentation, Infineon will present its requirements and challenges for the modeling tools regarding configuration management and will present its tool chain together with LieberLieber Software.
Modellierung, Codegenerierung und Portabilität von Mikrocontrolleranwendungen wird oft im Widerspruch mit Effizienz und Performance gesehen. In diesem Workshop modellieren und realisieren die Teilnehmer eine IoT Lösung mit Erfassung von Sensorwerten und einer Fernsteuerung von Aktoren über das Intranet. Der embedded Webserver wird mit der UML modelliert und auf einem Infineon XMC4500 implementiert. Nach der erfolgreichen Realisierung auf dem 32 Bit ARM Cortex M4 wird die Anwendung mit wenigen Handgriffen auf einen wesentlich kleineren und leistungsschwächeren 8 Bit Microcontroller portiert und die Performance der modellgetriebenen Applikation getestet. Teilnehmer, die den Workshop aktiv als Hands On Training nutzen wollen müssen ein Notebook mit folgenden Systemanforderungen mitbringen:
- mindestens zwei USB Anschlüsse
- Netzwerkanschluss RJ45
- Windows Betriebssystem, ab XP
- mindestens 2 GB RAM
- mindestens 1 GB frei verfügbaren Platz auf der Festplatte
- Administratorrechte für die Installation von Software und Treibern
Die im Workshop verwendete Modellierungssoftware kann auch bereits vorher installiert werden. Wenden Sie sich dazu per Mail an k.esche@sisy.de.
Systems Engineering und insbesondere MBSE wird in vielen Unternehmen zunehmend wichtiger, aber oft mit vielen Fragezeichen versehen. Wir wollen das ändern und zeigen MBSE live und erklären nicht nur was
- Anforderungsanalyse,
- funktionale Analyse,
- System Architektur Definition,
- Übergabe als digitales Lastenheft an die SW Entwicklung
bedeuten sondern auch wie es mit der richtigen Kombination aus Tool und Methode effizient geht.
Dieser Vortrag ist der Einstieg in eine Folge von drei Workshops, die einen modellgetriebenen Engineering Ansatz durch das V-Modell zeigen, vom Systems Engineering über die Verifikation bis zum Target-Code.
Es gibt einen immer stärker werdenden Trend hin zu digitalen Lastenheften. Einer der erwarteten Vorteile ist die Möglichkeit der frühzeitigen Verifikation (Shift Left gegenüber rein textbasierten Lastenheften). Aber nicht nur im Systems Engineering, auch im Software Engineering ist eine frühest mögliche Verifikation hilfreich.
In diesem Vortrag wird gezeigt wie eine frühe Verifikation von Modellen in der Praxis aussehen kann und welche Vorteile sich daraus ergeben. Es werden auch die Ansätze von TDD (Test Driven Development) aufgegriffen.
Dieser Vortrag ist der zweite in einer Folge von drei Workshops, die einen modellgetrieben Engineering Ansatz durch das V-Modell zeigen, vom Systems Engineering über die Verifikation bis zum Target-Code.
Existiert nun ein Verifiziertes Modell (auch im Sinn eines Digital Twin), dann stellt sich die Frage: Wie wird daraus nun ein reales Produkt?
Hier kommt die automatisierte Codegenerierung ins Spiel. Ihr kommt in mehrfacher Hinsicht ein großer Stellenwert zu. Abgesehen von Arbeitseinsparungen über der Absicherung von Kongruenz zwischen Modell und Code ist der Ausschluss von Fehlern ein Hauptgrund.
Ist das Modell bereits in vielen Gesichtspunkten verifiziert, macht es keinen Sinn die Transformation in Code durch einen Arbeitsschritt durchzuführen, der den erreichten Reifegrad wieder in Frage stellt, sprich fehlerträchtig ist. Auch wenn viele Entwickler es nicht hören wollen, die Transformation durch menschliche Gehirne ist nachweislich um ein Vielfaches fehlerträchtiger als durch einen Automaten (Codegenerator).
Soll also die Qualitätsstufe der verifizierten Modelle beibehalten werden hat sich die automatisierte Transformation als sinnvoll herausgestellt.
Aber dazu muss der generierte Code Ansprüchen genügen, die über die reine Ausführbarkeit hinausgehen. Produktivcode muss performant und sicher sein. Dies wird oft als eines der Hauptargumente gegen die Codegenerierung genannt – zu unrecht. Dieser Vortrag wird sich mit den verschiedenen Möglichkeiten der Codegenerierung, deren Vorteilen und Grenzen auseinandersetzen.
Abschließend wird gezeigt, wie die Verifikation der Modelle nun auch zur Verifikation des Codes wiederverwendet werden kann.
Dieser Vortrag ist der letzte in einer Folge von drei Workshops, die einen modellgetrieben Engineering Ansatz durch das V-Modell zeigen, vom Systems Engineering über die Verifikation bis zum Target-Code.
Die meisten Embedded Systeme werden zu spät oder nur unzureichend getestet. Fakt ist: Je später Fehler entdeckt werden, desto teurer ist die Behebung – die Kosten steigen exponentiell mit Fortschreiten des Projekts an. Hinzu kommen im Bereich von sicherheitsrelevanten Funktionen die hohen gesetzlichen Qualitätsanforderungen, welche mit Tests ausschließlich in den späten Phasen eines Projekts nicht erfüllt werden können.
Im Workshop wird eine entwicklungsbegleitende HIL Testmethodik für Microcontroller Systeme vorgestellt. Anders als bei herkömmlichen HIL Systemen erlaubt die Methodik bereits während der Entwicklung den Aufbau und die Durchführung automatisierter HIL Tests durch den Entwickler (Test First). Ermöglicht wird dies durch die Verwendung von kostengünstiger Standardhardware als Hardware in the Loop (HIL) Plattform in Kombination mit leistungsfähigen Modellierungswerkzeugen.
Der Vortrag endet mit einer Live Demonstration der Toolchain und einer anschließenden Diskussion.
In unseren Projekten beobachten wir oft eine gewisse Unsicherheit in Bezug auf den Einsatz modellbasierter Testverfahren. Die erste Hürde beginnt schon bei der Definition. Die einen denken bei MBT sofort an MATLAB/Simulink-Modelle. Die anderen wenden zustandsbasierte Testentwurfsverfahren an, ohne dies explizit modellbasierten Test (MBT) zu nennen. Wieder andere nutzen Ablaufdiagramme für den System- und Abnahmetest.
Neben den vielfältigen Ausprägungen gibt es auch hinsichtlich der zu erwartenden Vor- und Nachteile immer wieder Fragen. Insbesondere wenn es um eine durchgängige Automatisierung der Testfallerstellung und Testdurchführung geht, sind die Erwartung oft sehr hoch gesteckt. Hier stößt MBT auch schon mal an seine Grenzen. Andererseits eröffnet der Ansatz Horizonte, die ohne MBT gar nicht sichtbar wären:
- Reduktion der Komplexität, welche dadurch überhaupt erst beherrschbar wird,
- automatische Erstellung und Pflege der Testfälle,
- Visualisierung von Zusammenhängen zwischen verschiedenen Anforderungen,
- verbesserte Kommunikation und damit auch verbesserte Qualität (sowohl der Anforderungen als auch der Tests),
- Messbarkeit der Testabdeckung
- u.v.a.m.
In einer gemeinsamen und offenen Vorstellung und Diskussion werden wir klären, welcher der vielen MBT-Ansätze sich in Ihrem Zusammenhang anbieten und worauf Sie unseres Erachtens den Fokus legen sollten.
Die Zeit ist reif für die nächste Generation der Systems Modeling Language (OMG SysML). Vor über 10 Jahren wurde die SysML Version 1.0 von der Object Management Group (OMG) veröffentlicht. Das Ziel war eine einfache, aber mächtige Modellierungssprache für ein breites Spektrum an Systems Engineering Aufgaben.
Wir haben in der Zwischenzeit viel über SysML aus ihrem Einsatz in der Industrie gelernt. Dazu gehören ihre Stärken, aber auch ihre Schwächen. Gleichzeitig wird das modellbasierte Systems Engineering (MBSE) immer beliebter und wichtiger für eine Vielzahl an Unternehmen der Produktentwicklung. Das führt zu immer mehr Anforderungen an die SysML.
Im Dezember 2017 hat die OMG das RFP for SysML v2 veröffentlicht. Es ist eine lange Liste von Anforderungen an eine neue Version 2.0 der SysML. Nun liegt es an sogenannten Submission Teams, mit einer neuen Modellierungssprache auf das RFP zu antworten. Aktuell arbeiten zwei – leider konkurrierende – Teams an der SysML v2.
Im Juni 2018 hat die OMG noch das SysML API & Services RFP veröffentlicht. Es startet die Entwicklung an einem bahnbrechenden Standard für die Modellierung mit SysML und somit für MBSE.
Der Vortrag stellt die Anforderungen an die neue SysML vor und zeigt auf was uns demnächst erwartet.