große simulink-modelle mit bus objects effizienter gestalten€¦ · 6 objekte der klassen...
TRANSCRIPT
© TESIS DYNAware GmbH, www.tesis-dynaware.com 1
Große Simulink-Modelle mit Bus Objects effizienter gestalten Sebastian Bewersdorff Product Manager, TESIS DYNAware GmbH, München
Matlab Expo 2015, 12.05.2015
© TESIS DYNAware GmbH, www.tesis-dynaware.com 2
Überblick § Motivation § Herausforderung Komponentenschnittstellen § Bus Objects als Schnittstellenbeschreibung § Gestaltung der „optimalen“ Modellarchitektur § 3 Architektur-Varianten im Vergleich
3
■ Virtuelle Entwicklung mit Matlab/Simulink ist in der Automobilindustrie etabliert
■ Modelle sind ebenso komplex wie die Realität ■ Abbildung vieler Domänen und Disziplinen ■ Mechanik, Hydraulik, Thermodynamik, … ■ Fahrdynamik, Motor, Antrieb, … ■ Elektronik, Software, Bus-Kommunikation, …
■ Modellbaukasten mit modularen Komponenten ■ Wiederverwendbarkeit ■ Austauschbarkeit ■ Arbeitsteilung ■ Flexibilität in der Anwendung
Motivation
4
■ Komponenten (Subsysteme) eines Modells tauschen Signale aus
■ Signale haben Werte und Eigenschaften ■ Wichtige Signaleigenschaften: ■ Name ■ Dimension ■ Datentyp ■ Einheit
■ Starke Abhängigkeit zwischen Komponenten
Herausforderung Komponentenschnittstellen
5
■ Voraussetzung zur Austauschbarkeit von Komponenten: ■ Gleiche Signaleigenschaften ■ Eingangssignale müssen bedient werden ■ Ausgangssignale müssen erzeugt werden ■ Inhalte können unterschiedlich sein
■ Schnittstellendefinition außerhalb der Komponente erleichtert die Austauschbarkeit
■ Zentraler Schnittstellenstandard notwendig
Lösungsansatz: standardisierte Schnittstellendefinition außerhalb des Modells mit Simulink.Bus Objects
Herausforderung Komponentenschnittstellen (Forts.)
6
Objekte der Klassen Simulink.Bus und Simulink.BusElement beschreiben detailliert die Eigenschaften von Bus-Signalen ■ Objekte können mit Matlab-Skripten erzeugt werden ■ Bus Objects als Datentyp für Bus Creator, Inport oder Outport ■ Automatische Überprüfung der Signale im Bus bzgl. ■ Anzahl ■ Datentyp ■ Name ■ Dimension
■ Quellen für Signaldefinition z.B. ■ CAN-DBC ■ XML (FIBEX) ■ MS Excel
Bus Objects als Schnittstellenbeschreibung
% Bus Object erzeugen bo_Flexray = Simulink.Bus(); bo_Flexray.Elements(1) = Simulink.BusElement(); bo_Flexray.Elements(1).Name = 'PDU01';
bo_Flexray.Elements(1).DataType = 'Bus: bo_PDU01'; ... % Initialisierungsstruktur erzeugen
init_Flexray = Simulink.Bus.createMATLABStruct('bo_Flexray');
7
■ Komponentenmodelle sollen vielseitig einsetzbar sein ■ Varianten von Gesamtmodellen je nach
Produktvariante, z.B. ■ Anzahl und Art von Steuergeräten ■ Ausprägungen von Baugruppen
■ Varianten von Gesamtmodellen je nach Anwendungsfall, z.B. ■ Komponentenentwicklung ■ Unit/System-Tests ■ Integrations-Tests
Gestaltung der „optimalen“ Modellarchitektur
Kombination der Komponenten
Erstellung von Komponentenmodellen
8
■ Komponenten erzeugen alle Bus-Signale selbst ■ Komponenten-Busse werden zu einem
Gesamt-Bus mittels Bus Creator zusammengefasst
■ Gute Performance durch virtuelle Busse ■ Wenig Flexibilität ■ Alle Komponenten müssen enthalten sein ■ Jede Komponente muss ihre Ausgangs-
Schnittstelle vollständig bedienen
Architektur-Variante mit Bus Creator
9
■ Erzeugung und Initialisierung des gesamten Busses außerhalb der Komponenten
■ Trennung von Haupt-Bussen sinnvoll, z.B. ■ Physikalische Zustände von Streckenmodellen ■ Kommunikation realer Bus-Systeme
(CAN, Flexray etc.) ■ Komponenten lesen und schreiben Signalwerte vom
bzw. auf den bestehenden Bus ■ Definierte maximale Belegung eines Gesamt-Modells
(Anzahl und Art der Komponenten) ■ Einzelne Komponenten können ohne großen
Anpassungsbedarf entfernt werden ■ Komponenten können Subsets von Signalen senden ■ Default-Werte von Signalen nutzbar
Alternativer Architekturansatz
Gateway
CAN-ECU 2
FR-ECU 2
CAN-ECU 1
FR-ECU 1
10
■ Gesamt-Bus mit einem einzigen Constant-Block und Bus Object erzeugt
■ Initialisierung der Bus-Werte über Matlab-Struktur ■ Schreiben mit Bus Assignment ■ Lesen mit Bus Selector ■ Flexibel ■ Komponenten können entfernt werden ■ Komponenten müssen nicht alle
Signale senden ■ Performance ■ Sehr breite Busse im Modell (>5000 Signale) ■ Häufiger algebraische Schleifen
bei großen Modellen
Architektur-Variante mit Bus Assignment und Selector
11
■ Erzeugung Gesamt-Bus mit Data Store Memory ■ Initialisierung der Bus-Werte über Matlab-Struktur ■ Schreiben mit Data Store Write ■ Lesen mit Data Store Read ■ Flexibel (Komponenten vollständig entkoppelt) ■ „synchronisierte Co-Simulation“ ■ Realtime Performance: Data Store Write deutlich
schneller als Bus Assignment ■ Datentransfer zwischen Komponenten über
kompakte Datenstruktur ■ Reihenfolge der Komponenten muss bewusst
gesetzt werden!
Architektur-Variante mit Data Store Memory
12
Gemeinsamkeiten ■ Vor- und Nachteile ■ Komponenten ■ beinhalten Modellierung ■ haben definierte Schnittstellen ■ sind inhaltlich abhängig
■ Schnittstellen ■ vollständig vorhanden ■ dynamische und statische Signale
Unterschiede ■ Vor- und Nachteile ■ Technologie der Datenübertragung ■ Zeitliche Abhängigkeit der Komponenten
Vergleich der 3 Varianten
W
W
R
R
Bus
13
■ Schnittstellenspezifikation außerhalb des Modells unterstützt Zusammenarbeit
■ Bus Objects helfen bei Erzeugung und Überprüfung von Bus-Signalen
■ Bus Objects eröffnen zusätzliche Möglichkeiten zur Modellgestaltung
■ Trennung von Modellarchitektur und Schnittstellentechnologie steigert Effizienz in Modellentwicklung und Modellausführung
■ Die „optimale“ Modellarchitektur hängt stets vom Anwendungsfall ab
Zusammenfassung