Dieser Vortrag besteht aus 2 Teilen

1. Übersicht über IBM Engineering Lifecycle Management (ELM) in 7 Folien
2. Live-Demo eines in der ELM-Lösung behandelten Fehlers mit Rückverfolgbarkeit und Modellausführung

Sprecher:
Peter Schedl, IBM Engineering Architekt
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, IBM Engineering TechSales
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.

Dieser Vortrag besteht aus 2 Teilen

1. Übersicht über IBM Engineering Lifecycle Management (ELM) in 7 Folien
2. Live-Demo eines in der ELM-Lösung behandelten Fehlers mit Rückverfolgbarkeit und Modellausführung

Sprecher:
Peter Schedl, IBM Engineering Architekt
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, IBM Engineering TechSales
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.

Wie fügt sich der Test ins Modell ein

Die Idee von MBSE, ein gesamtes System in einem (UML/SysML) Modell zu beschreiben, ist sehr überzeugend. Die Vorteile, die sich daraus für alle Beteiligten in Hinblick auf Dokumentation, Darstellung der Zusammenhänge und Abhängigkeiten, sowie die Ableitung von Code oder die Nutzung zur Validierung durch Simulation ergeben, wurden schon oft dargestellt. Zumindest ist das so für die Entwicklungsseite.

Dass auch der Test in hohem Maße von einem Modell profitieren kann, wird dagegen oft nicht wahrgenommen. Insbesondere ist vielen nicht klar, wie viel an Qualität gewonnen und wie viel Aufwand eingespart werden kann, wenn man das Testdesign modelliert und die Testmodelle zur Testfallgenerierung nutzt.

Anhand eines komplett modellierten, fiktiven Precrash-Erkennungssystems für Fahrzeuge wird aufgezeigt, wie man ein entsprechendes Modell aufbaut. Von den ersten User-Stories ausgehend, über die Anforderungen bezüglich Safety und Security, über Risiko- und Bedrohungsanalysen bis hin zu den davon abgeleiteten Testmodellen wird gezeigt, wie ein solches Modell aussehen kann.

Der Nutzen für den Test ist, neben den bekannten Vorteilen einer Modellbeschreibung, eine automatische Ableitung von konkreten Testfällen zur manuellen oder automatischen Durchführung. Gleichzeitig lassen sich aus dem Modell quantitative Aussagen zur Testabdeckung machen.

Wie fügt sich der Test ins Modell ein

Die Idee von MBSE, ein gesamtes System in einem (UML/SysML) Modell zu beschreiben, ist sehr überzeugend. Die Vorteile, die sich daraus für alle Beteiligten in Hinblick auf Dokumentation, Darstellung der Zusammenhänge und Abhängigkeiten, sowie die Ableitung von Code oder die Nutzung zur Validierung durch Simulation ergeben, wurden schon oft dargestellt. Zumindest ist das so für die Entwicklungsseite.

Dass auch der Test in hohem Maße von einem Modell profitieren kann, wird dagegen oft nicht wahrgenommen. Insbesondere ist vielen nicht klar, wie viel an Qualität gewonnen und wie viel Aufwand eingespart werden kann, wenn man das Testdesign modelliert und die Testmodelle zur Testfallgenerierung nutzt.

Anhand eines komplett modellierten, fiktiven Precrash-Erkennungssystems für Fahrzeuge wird aufgezeigt, wie man ein entsprechendes Modell aufbaut. Von den ersten User-Stories ausgehend, über die Anforderungen bezüglich Safety und Security, über Risiko- und Bedrohungsanalysen bis hin zu den davon abgeleiteten Testmodellen wird gezeigt, wie ein solches Modell aussehen kann.

Der Nutzen für den Test ist, neben den bekannten Vorteilen einer Modellbeschreibung, eine automatische Ableitung von konkreten Testfällen zur manuellen oder automatischen Durchführung. Gleichzeitig lassen sich aus dem Modell quantitative Aussagen zur Testabdeckung machen.

1. Besonderheiten in kleinen Teams
2. Modellgetriebene Anforderungsdefinition
3. Modellgetriebener Architekturentwurf
4. Modellgetriebene Realisierung, Rapide Applikationen Development
5. Modellbasiertes Testen
6. Modellgetriebene Dokumentation

1. Besonderheiten in kleinen Teams
2. Modellgetriebene Anforderungsdefinition
3. Modellgetriebener Architekturentwurf
4. Modellgetriebene Realisierung, Rapide Applikationen Development
5. Modellbasiertes Testen
6. Modellgetriebene Dokumentation

Hinter den SysML-Diagrammen verbirgt sich eine Welt voller wertvoller Daten. Es ist mehr als eine Organisation von grafischen Elementen. Lassen Sie uns darüber sprechen, SysML auch als Datenwerkzeug und nicht nur als Zeichenwerkzeug zu verwenden. Zusätzlich zu den Werten enthalten die SysML-Daten auch semantische Informationen über wesentliche Konzepte des Systems Engineering.

Die Daten innerhalb der SysML sind bereits Teil der SysML v1 und werden von der nächsten Generation der Modellierungssprache SysML v2 wesentlich besser unterstützt werden.

Hinter den SysML-Diagrammen verbirgt sich eine Welt voller wertvoller Daten. Es ist mehr als eine Organisation von grafischen Elementen. Lassen Sie uns darüber sprechen, SysML auch als Datenwerkzeug und nicht nur als Zeichenwerkzeug zu verwenden. Zusätzlich zu den Werten enthalten die SysML-Daten auch semantische Informationen über wesentliche Konzepte des Systems Engineering.

Die Daten innerhalb der SysML sind bereits Teil der SysML v1 und werden von der nächsten Generation der Modellierungssprache SysML v2 wesentlich besser unterstützt werden.

Mehrere Jahre der Systemmodellierung führen oft dazu, dass ein monolithisches Modell entsteht, was zu großen Herausforderungen für das Lifecycle-Management der einzelnen Modellbereiche führt. In dieser Präsentation möchten wir Ihnen einen Ansatz vorstellen, bei dem das Modell nicht länger als Gesamtheit betrachtet wird, sondern bei dem individuelle Modell-Komponenten definiert und verwaltet werden können. Dabei ist das Verständnis von Abhängigkeiten, deren Handhabung, sowie ein richtiges Werkzeug relevant und notwendig, welches Sie bei dem Erstellen und Versionieren der Modell-Komponenten unterstützt. Dieser Ansatz soll schlussendlich die Basis für eine saubere Produktlinienentwicklung bilden, die auf einem Plattformkonzept aufbauen kann.

Mehrere Jahre der Systemmodellierung führen oft dazu, dass ein monolithisches Modell entsteht, was zu großen Herausforderungen für das Lifecycle-Management der einzelnen Modellbereiche führt. In dieser Präsentation möchten wir Ihnen einen Ansatz vorstellen, bei dem das Modell nicht länger als Gesamtheit betrachtet wird, sondern bei dem individuelle Modell-Komponenten definiert und verwaltet werden können. Dabei ist das Verständnis von Abhängigkeiten, deren Handhabung, sowie ein richtiges Werkzeug relevant und notwendig, welches Sie bei dem Erstellen und Versionieren der Modell-Komponenten unterstützt. Dieser Ansatz soll schlussendlich die Basis für eine saubere Produktlinienentwicklung bilden, die auf einem Plattformkonzept aufbauen kann.

MBSE using UML or SysML is quite widely spread nowadays, only in the automotive world it is used very limited. Mostly only to draw pictures to increase the understanding of the project but nothing really integrated.
Still Automotive Spice and ISO26262 require traceabilty of engineering data in the project to ensure safety.

This presentation shows how you can model in a UML / SysML Tool and keep your model in sync with an AUTOSAR model that contains the information you need for your RTE/Authorizing tool (Vector DaVinci but also others like Mentor, Dspace, Electrobit). Create multiple views that deliver exactly the information needed (and allow you to always edit your data in the right context!) and keep all other views up-to-date.

Creating code for an ECU involves mostly hand-coding or, at best, code generation from MatLab using Embedded Coder or TargetLink. For a lot of applications this is not the optimal solution since it is actually decision logic or something else not really mappable to mathematic algorithms. In that case code generation from statemachines or activity diagrams is a much better solution, I will tell you how to integrate that in an AUTOSAR environment.

This then allows for much easier automatic testing and much safer software.

MBSE using UML or SysML is quite widely spread nowadays, only in the automotive world it is used very limited. Mostly only to draw pictures to increase the understanding of the project but nothing really integrated.
Still Automotive Spice and ISO26262 require traceabilty of engineering data in the project to ensure safety.

This presentation shows how you can model in a UML / SysML Tool and keep your model in sync with an AUTOSAR model that contains the information you need for your RTE/Authorizing tool (Vector DaVinci but also others like Mentor, Dspace, Electrobit). Create multiple views that deliver exactly the information needed (and allow you to always edit your data in the right context!) and keep all other views up-to-date.

Creating code for an ECU involves mostly hand-coding or, at best, code generation from MatLab using Embedded Coder or TargetLink. For a lot of applications this is not the optimal solution since it is actually decision logic or something else not really mappable to mathematic algorithms. In that case code generation from statemachines or activity diagrams is a much better solution, I will tell you how to integrate that in an AUTOSAR environment.

This then allows for much easier automatic testing and much safer software.

Nach über 20 Jahren und hunderten realisierter Projekte in unterschiedlichsten Branchen, wird der aktuellen Stand der Technik bezüglich Modellierung und Generierung mit der Toolsuite radCASE vorgestellt.

Im Fokus stehen konkrete Kundenprojekte, die die Möglichkeiten der Modellierung, die daraus generierbaren Ergebnisse sowie die Adaption auf die Zielsysteme demonstrieren.

Modellierung:

• Architektur, Strukturierung und Wiederverwendung und Abdeckungsgrad
• Modellumfang: (Daten, Metadaten, Funktionalitäten, HMI, Anlagenverhalten, Hardware, Ressourcen)
• Editoren und Modellaustausch mit anderen Systemen

Generierungsergebnisse:

• Pflichtenheft, Spezifikation
• C/C++ Code (Daten Funktionen, GUI, (Internet-)Kommunikation) für das Zielsystem
• Tools für Service und Monitoring, Debugging
• PC-Tools zur System-Simulation, Test und Energie-/Ressourcen-Bedarf
• Dokumentation für Entwickler, Bedienungsanleitung für Endkunden
• PC-Tools für Service, Parametrierung, Monitoring Debugging
• Konstrukte zur Kommunikation/Kopplung an das (I)IoT)

Adaption an Zielsysteme und deren Toolchains:

• Aufbau und Struktur des API
• Anforderungen an das Zielsystem
• Einbindung in IDEs und Toolchains

Nach über 20 Jahren und hunderten realisierter Projekte in unterschiedlichsten Branchen, wird der aktuellen Stand der Technik bezüglich Modellierung und Generierung mit der Toolsuite radCASE vorgestellt.

Im Fokus stehen konkrete Kundenprojekte, die die Möglichkeiten der Modellierung, die daraus generierbaren Ergebnisse sowie die Adaption auf die Zielsysteme demonstrieren.

Modellierung:

• Architektur, Strukturierung und Wiederverwendung und Abdeckungsgrad
• Modellumfang: (Daten, Metadaten, Funktionalitäten, HMI, Anlagenverhalten, Hardware, Ressourcen)
• Editoren und Modellaustausch mit anderen Systemen

Generierungsergebnisse:

• Pflichtenheft, Spezifikation
• C/C++ Code (Daten Funktionen, GUI, (Internet-)Kommunikation) für das Zielsystem
• Tools für Service und Monitoring, Debugging
• PC-Tools zur System-Simulation, Test und Energie-/Ressourcen-Bedarf
• Dokumentation für Entwickler, Bedienungsanleitung für Endkunden
• PC-Tools für Service, Parametrierung, Monitoring Debugging
• Konstrukte zur Kommunikation/Kopplung an das (I)IoT)

Adaption an Zielsysteme und deren Toolchains:

• Aufbau und Struktur des API
• Anforderungen an das Zielsystem
• Einbindung in IDEs und Toolchains

Durchgängige Testautomatisierung und Continuous Integration (CI) über alle Teststufen hinweg ist bei der Entwicklung von Embedded Systemen immer noch sehr wenig verbreitet.

Warum ist das so? Wie kann man das verbessern?

Im Vortrag wird zunächst beleuchtet warum sich viele Embedded Projekte schwer tun mit Testautomatisierung zu starten, während Continuous Integration in vielen anderen Bereichen sehr weit verbreitet ist. Anschließend werden verschiedene Methoden vorgestellt, mit welchen über alle Test Ebenen hinweg automatisiert werden kann (Komponenten-, Integrations-, System- und Akzeptanz-Tests). Zum Abschluss wird in einer Live Demonstration gezeigt wie eine solche CI Toolchain in der Praxis funktioniert vom Komponententest über Hardware in the Loop Tests bis hin zur Lieferung der Software (Continuous Delivery).

Was lernen die Zuhörer?

• Warum ist es schwer Embedded Systeme zu testen?
• Wie kann man das verbessern?
• Wie kann man auch Hardware in the Loop Tests automatisieren*
• Wie kann man die Tests mit Continuous Integration vollständig automatisieren?

Durchgängige Testautomatisierung und Continuous Integration (CI) über alle Teststufen hinweg ist bei der Entwicklung von Embedded Systemen immer noch sehr wenig verbreitet.

Warum ist das so? Wie kann man das verbessern?

Im Vortrag wird zunächst beleuchtet warum sich viele Embedded Projekte schwer tun mit Testautomatisierung zu starten, während Continuous Integration in vielen anderen Bereichen sehr weit verbreitet ist. Anschließend werden verschiedene Methoden vorgestellt, mit welchen über alle Test Ebenen hinweg automatisiert werden kann (Komponenten-, Integrations-, System- und Akzeptanz-Tests). Zum Abschluss wird in einer Live Demonstration gezeigt wie eine solche CI Toolchain in der Praxis funktioniert vom Komponententest über Hardware in the Loop Tests bis hin zur Lieferung der Software (Continuous Delivery).

Was lernen die Zuhörer?

• Warum ist es schwer Embedded Systeme zu testen?
• Wie kann man das verbessern?
• Wie kann man auch Hardware in the Loop Tests automatisieren*
• Wie kann man die Tests mit Continuous Integration vollständig automatisieren?