download - SPES 2020
download - SPES 2020
download - SPES 2020
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Der <strong>SPES</strong> Modellierungsansatz<br />
Dr. Thorsten Weyer<br />
Universität Duisburg-Essen<br />
GEFÖRDERT VOM<br />
Prof. Dr. Holger Schlingloff<br />
Fraunhofer FIRST
Ausgangssituation zu Projektbeginn<br />
• Fehlende Integration von Techniken, Methoden und Werkzeugen<br />
• Vorliegende Ansätze basieren auf verschiedenen und weitgehend isolierten<br />
Modellierungstheorien<br />
• Unklare Semantik der Beziehungen zwischen Modelltypen und dadurch<br />
vage und fehleranfälliger Übergang zwischen Modellen verschiedenen Typs<br />
• Steigender Umfang und steigende Komplexität von Embedded Systems,<br />
und der funktionalen Abhängigkeiten in Systemverbünden<br />
2
Vision des <strong>SPES</strong>-Modellierungsansatzes<br />
• Verwendung von Modellen als die primären Artefakte in allen „Stadien“<br />
des Entwicklungsprozesses von Embedded Systems<br />
• Erhöhung des Automatisierungsgrades über die verschiedenen „Stadien“<br />
des Entwicklungsprozesses hinweg<br />
• Verbesserung der Entwicklungsproduktivität und der Qualität der<br />
konstruierten Embedded Systems<br />
• Systematische Beherrschung des steigenden Umfangs und der<br />
steigenden Komplexität von Embedded Systems und der Beziehungen<br />
in Systemverbünden<br />
3
Prinzipien des <strong>SPES</strong>-Modellierungsansatzes<br />
• Modellbasierung und Durchgängigkeit der Entwicklung<br />
• Differenzierung zwischen Problem und Lösung<br />
• Explizite Berücksichtigung der Dekomposition („Teile-und-Herrsche“)<br />
• Differenzierung zwischen logischer Lösung und technischer Lösung<br />
• Durchgängige Betrachtung übergreifender Systemeigenschaften<br />
(z.B. Echtzeit, Safety)<br />
4
Umsetzung der <strong>SPES</strong> <strong>2020</strong>-Prinzipien<br />
• Betrachtung verschiedener Viewpoints (nach IEEE 1471) zur<br />
Differenzierung und zum strukturierten Übergang zwischen:<br />
… Problemanalyse und Lösungskonstruktion<br />
… logischer Lösung und technischer Lösung<br />
• Explizite Unterscheidung von Granularitätsebenen der<br />
Systembetrachtung und zugehöriger Dekompositionsbeziehungen<br />
• Artefaktmodell mit definierter genereller Semantik der Artefakt(typen)<br />
und der Beziehung zwischen Artefakttypen<br />
• Betrachtung übergreifender Systemeigenschaften<br />
… durchgängig über die Viewpoints<br />
… konsistent über die Granularitätsebenen<br />
5
Der <strong>SPES</strong>-Modellierungsframework<br />
abstrakt<br />
konkret<br />
A b s t r a c t i o n L a y e r s<br />
Requirements Functional Logical Technical<br />
...<br />
V i e w p o i n t s<br />
...<br />
...<br />
...<br />
...<br />
...<br />
6
Viewpoint „Requirements“<br />
Modellierungsziele<br />
• Dokumentation der operationellen Umgebung des Systems<br />
• Dokumentation der Ziel des Systems und zugehöriger Szenarien<br />
• Spezifikation der zur Zielerreichung notwendigen fachlichen Eigenschaften<br />
Modelle<br />
User<br />
SensorSignal<br />
«flow»<br />
UserInput<br />
«flow»<br />
Env ironment<br />
«flowPort»<br />
SensorSignal<br />
«flowPort»<br />
UserInput<br />
Unterstützte<br />
Aktivitäten<br />
Kontext<br />
Zylinderkopffertigungsanlage<br />
environment<br />
model<br />
Crane2 (extern) Crane1 (extern)<br />
«flowPort»<br />
SystemOutput<br />
Deliv eryBand (extern) SupplyBand (extern)<br />
«flowPort»<br />
Crane1ActionSignal<br />
«flowPort»<br />
Crane2ActionSignal<br />
«flowPort»<br />
DeliveryBandSignal<br />
«flowPort»<br />
SupplyBandSignal<br />
SystemOutput<br />
«flow»<br />
Crane1ActionSignal<br />
«flow»<br />
Crane2ActionSignal<br />
«flow»<br />
DeliveryBandSignal<br />
«flow»<br />
SupplyBandSignal<br />
«flow»<br />
><br />
Zeitgleiche<br />
bearbeitung ()<br />
--<br />
«Contribution»<br />
+<br />
«Contribution»<br />
><br />
Vermessen von<br />
Produktionsstoffen ()<br />
Ziele<br />
><br />
Kollilsionen<br />
vermeiden ()<br />
++<br />
«Contribution»<br />
><br />
Transport von Werkstücken<br />
gewährleisten ()<br />
><br />
Werkstücke<br />
erkennen ()<br />
><br />
Produktionsstofftransport<br />
gewährleisten ()<br />
><br />
Rohstoff<br />
transportieren ()<br />
><br />
Werkstück<br />
transportieren ()<br />
UserInteraction<br />
UserInteraction<br />
loop SupplyBand ansteuern<br />
[OperationOn] loop SupplyBand ansteuern<br />
[!OperationOn]<br />
[!OperationOn]<br />
(from 2.3.2. (from Ziele 2.3.2. / Szenarien Ziele / Szenarien "UserInteraction") "UserInteraction")<br />
Szenarien<br />
UserInteraction<br />
OperationOn()<br />
[OperationOn]<br />
loop SupplyBand ansteuern<br />
[OperationOn]<br />
[!OperationOn]<br />
(from 2.3.2. Ziele / Szenarien "UserInteraction")<br />
OperationOn()<br />
SupplyBand IOAdapter<br />
eingeschaltet<br />
OperationOn()<br />
eingeschaltet<br />
Ansteuerung<br />
berechnen<br />
Ansteuerung eingeschaltet<br />
berechnen<br />
Ansteuerung<br />
berechnen<br />
!OperationOn()<br />
!OperationOn() system<br />
ausgeschaltet<br />
ausgeschaltet<br />
!OperationOn()<br />
ausgeschaltet scenarios<br />
SupplyBand IOAdapter<br />
SupplyBand IOAdapter<br />
Sensor()<br />
Sensor()<br />
SupplyBand()<br />
Sensor()<br />
SupplyBand()<br />
SupplyBand()<br />
(from 2.1.2. Ziele / (from Szenarien 2.1.2. "IOAdapter")<br />
Ziele / Szenarien "IOAdapter")<br />
(from 2.1.2. Ziele / Szenarien "IOAdapter")<br />
Initial<br />
R1<br />
RN<br />
Final<br />
Lösungsbezogene<br />
Anforderungen<br />
Initial<br />
AutoMode<br />
[UserInput:<br />
einschalten]<br />
AutoMode<br />
OperationOn<br />
Bewegungsauftrag<br />
Crane1<br />
Sensordaten v erarbeiten<br />
AutoMode<br />
Funktionen des TransportationController<br />
Bewegungsauftrag<br />
Crane1<br />
Sensor<br />
Sensor<br />
Bewegungsauftrag<br />
OperationOn Crane2<br />
OperationOn<br />
Wegpunkte für Crane1<br />
berechnen<br />
Crane1Action<br />
Crane1Action<br />
Wegpunkte für Crane2<br />
berechnen<br />
Bewegungsauftrag<br />
Crane2Action<br />
Crane2<br />
Crane2Action<br />
Förderbandbewegungen<br />
berechnen<br />
SupplyBand SupplyBand<br />
DeliveryBand DeliveryBand<br />
Anlage eingeschaltet<br />
+Bus-conformant Data<br />
translated by IOAdapter<br />
«block»<br />
Action<br />
[UserInput = !AutoMode] ManualMode solution-oriented<br />
[UserInput = AutoMode]<br />
«block»<br />
«block»<br />
«block»<br />
«block»<br />
Crane1Action Crane2Action SupplyBandAction Deliv eryBandAction<br />
Determination<br />
Representation<br />
system<br />
+Displayed data<br />
«block»<br />
SystemOuput<br />
requirements<br />
[UserInput: [UserInput: einschalten]<br />
terminieren]<br />
Anlage ausgeschaltet<br />
+Raw Signal<br />
«block»<br />
+represented Information ActionSignal<br />
«block»<br />
«block»<br />
«block»<br />
«block»<br />
Crane1ActionSignal Crane2ActionSignal SupplyBandActionSignal Deliv eryBandActionSignal<br />
«block»<br />
+determins UserInput<br />
«block»<br />
OperationOn<br />
«block»<br />
«block»<br />
Sensor +Raw Data translated by IOAdapter +Translated Signal SensorSignal<br />
«block»<br />
AutoMode<br />
«block»<br />
«block»<br />
«block»<br />
«block»<br />
«block»<br />
«block»<br />
«block»<br />
«block»<br />
Crane1Sensor Crane2Sensor SupplyBandSensor Deliv eryBandSensor<br />
Crane1SensorSignal Crane2SensorSignal SupplyBandSensorSignal Deliv eryBandSensorSignal<br />
• Systematische Gewinnung von Anforderungen<br />
• Durchgängige Dokumentation / Spezifikation von Anforderungen<br />
• Validierung von Anforderungen<br />
+determined<br />
7
Viewpoint „Functional“<br />
Modellierungsziele<br />
• Integration der funktionalen Anforderungen in eine umfassende Systemspezifikation<br />
• Präzise Modellierung des Black Box Verhalten an ein System<br />
• Modellierung von Abhängigkeiten zwischen funktionalen Anforderungen<br />
Modelle<br />
Unterstützte<br />
Aktivitäten<br />
Black Box Sicht<br />
(aus VP RE)<br />
User<br />
SensorSignal<br />
«flow»<br />
UserInput<br />
«flow»<br />
Env ironment<br />
«flowPort»<br />
SensorSignal<br />
«flowPort»<br />
UserInput<br />
Zylinderkopffertigungsanlage<br />
Crane2 (extern) Crane1 (extern)<br />
«flowPort»<br />
SystemOutput<br />
Deliv eryBand (extern) SupplyBand (extern)<br />
«flowPort»<br />
Crane1ActionSignal<br />
«flowPort»<br />
Crane2ActionSignal<br />
«flowPort»<br />
DeliveryBandSignal<br />
«flowPort»<br />
SupplyBandSignal<br />
SystemOutput<br />
«flow»<br />
Crane1ActionSignal<br />
«flow»<br />
Crane2ActionSignal<br />
«flow»<br />
DeliveryBandSignal<br />
«flow»<br />
SupplyBandSignal<br />
«flow»<br />
Projektion<br />
System Funktion<br />
• Validierung von Anforderungen<br />
• Generierung von Testfällen und Verifikationsbedingungen<br />
• Funktionale Prototypen<br />
Funktions-Hierarchie<br />
8
Viewpoint „Logical“<br />
Modellierungsziele<br />
• Logische Beschreibung der Lösung durch Zerlegung in Teilsysteme<br />
• Plattformunabhängigkeit der beschriebenen Lösung<br />
• Wiederverwendbarkeit von logischen Teilsystemen<br />
Modelle<br />
Unterstützte<br />
Aktivitäten<br />
Teilsystem<br />
Schnittstelle<br />
Teilsystem<br />
Verhalten<br />
• Verifikation des Systemverhaltens<br />
• Simulation<br />
Teilsystem Architektur<br />
9
Viewpoint „Technical“<br />
Modellierungsziele<br />
• Beschreibung der Ziel-Hardware (ECUs, Busse, Speicher, …)<br />
• Definition von (Software-)Tasks und Scheduler<br />
• Beschreibung der verteilungsspezifischen Kommunikation<br />
• Plattformspezifische Beschreibung der Spezifikation<br />
Logisches<br />
Teilsystem<br />
Mapping<br />
Unterstützte<br />
Aktivitäten<br />
temp<br />
Ziel-Hardware<br />
Capture<br />
Logical Perspective<br />
Temp<br />
Data<br />
<br />
AirTempControl<br />
control<br />
tempVal<br />
Capture<br />
Task<br />
Technical Perspective<br />
temp<br />
temp control<br />
Data<br />
Var1<br />
Scheduler<br />
ECU<br />
airTemp<br />
CtrlTask<br />
Var2<br />
tempSel<br />
Task und<br />
Scheduler<br />
ProcessingResource<br />
:Concurrency<br />
Resource<br />
:Concurrency<br />
Resource<br />
:SchedulerSlot :SchedulerSlot<br />
• Verifikation (Echtzeitanalysen, Scheduling, …)<br />
• (Plattformspezifische) Verfeinerung der logischen Teilsysteme<br />
(Logical Viewpoint)<br />
• Deployment<br />
:Scheduler<br />
:SchedulerSlot<br />
:Scheduler<br />
:Concurrency<br />
Resource<br />
:SchedulerSlot<br />
ComputingResource<br />
header<br />
header<br />
app-task1:Task<br />
app-task2:Task<br />
Kommunikation<br />
Signal1<br />
com:Task<br />
Signal2<br />
Signal1 Signal2<br />
payload<br />
Message1 Frame1<br />
Message1<br />
payload Frame1<br />
bus-drv:Task<br />
10
Integration der Viewpoints (beispielhaft)<br />
Voraussetzung für die Durchgängigkeit (insb. methodisch) ist, dass die Modelle der<br />
verschiedenen Viewpoints semantisch zueinander in Beziehung gesetzt werden<br />
VP „Requirements“<br />
VP „Functional“<br />
F 1<br />
System<br />
F 2<br />
VP „Logical“<br />
C1<br />
C3<br />
C2<br />
VP „Technical“<br />
ECU 1<br />
Bus<br />
ECU 2<br />
11
Mögliche Entwicklungssystematiken (A)<br />
A b s t r a c t i o n L a y e r s<br />
Requirements Functional Logical Technical<br />
1 2 3 4<br />
...<br />
5 6<br />
...<br />
V i e w p o i n t s<br />
...<br />
9 10 11<br />
12<br />
...<br />
7<br />
...<br />
...<br />
8<br />
12
Mögliche Entwicklungssystematik (B)<br />
A b s t r a c t i o n L a y e r s<br />
V i e w p o i n t s<br />
Requirements Functional Logical Technical<br />
1<br />
...<br />
2 3<br />
...<br />
...<br />
...<br />
...<br />
4 5<br />
6<br />
...<br />
7<br />
8<br />
13
<strong>SPES</strong> Modeling Framework –<br />
Transversale Fragestellungen<br />
abstrakter<br />
konkreter<br />
Abstraction Layers<br />
Viewpoints<br />
Requirements Functional Logical Technical<br />
Safety-spezifische Herausforderungen:<br />
...<br />
• Entwicklung modularer, ... hierarchischer Sicherheitsanalysen ...<br />
um mit den<br />
Methoden einer modernen modellbasierten Entwicklung „schrittzuhalten“<br />
• Sicherstellung der Konsistenz und Nachverfolgbarkeit zwischen<br />
Sicherheitsanalysen auf unterschiedlichen Abstraktionsebenen und Views<br />
• Sicherstellung der Konsistenz ... zwischen modellbasierter<br />
...<br />
...<br />
Sicherheitsanalyse<br />
und anderen modellbasierten Entwicklungsartefakten<br />
14
Abstraction Layers<br />
Durchgängige modellbasierte<br />
Sicherheitsanalyse<br />
Beispiel Viewpoint<br />
Komponentenfehlerbäume CFTs<br />
• ermöglichen die Modularisierung und<br />
Hierarchisierung von Sicherheitsanalysen<br />
• erlauben den Schutz geistigen Eigentums durch die<br />
Unterscheidung von Spezifikation und Realisierung<br />
• Algorithmen prüfen die Konsistenz der Module über<br />
Hierarchie- und Abstraktionsebenen hinweg<br />
Komponenten-integrierte Fehlerbäume C²FTs<br />
• sind eine Erweiterung der Komponentenfehlerbäume<br />
• ermöglichen die Integration von Sicherheitsanalysen<br />
in modellbasierte Entwicklungsartefakte<br />
• verbessern die Konsistenz von Sicherheitsanalysen<br />
und modellbasierter Entwicklung<br />
15
Safety-fokussierte Deployment Analyse<br />
Logical<br />
Viewpoint<br />
C1<br />
C3<br />
C2<br />
Technical<br />
Viewpoint<br />
ECU 1<br />
Bus<br />
ECU 2<br />
Herausforderungen<br />
• Es muss geprüft werden ob die Sicherheitsanforderungen<br />
der logischen Komponenten erfüllt sind<br />
• Die Erfüllung der Sicherheitsanforderungen muss<br />
nachgewiesen werden<br />
• Zusätzliche Kosten (Rezertifizierung) müssen<br />
minimiert werden<br />
Methoden zum effizienten Deployment<br />
• modulare Spezifikation von Sicherheitsanforderungen<br />
und Sicherheitsgarantien zwischen logischen<br />
Komponenten und Rechenknoten<br />
• Methode zur Prüfung der Sicherheitsanforderungen<br />
auf logischer und technischer Ebene<br />
• Teilautomatisierte Nachweiserstellung<br />
• Bewertung eines Deployments<br />
16
Abstraction Layers<br />
Überschneidung von Safety und Echtzeit<br />
Beispiel Viewpoint<br />
Probabilistische Worst-Case Zeitanalyse pWCET<br />
• Unterschiedliche Fehler eines Systems können die<br />
Ausführungszeit mitunter stark beeinflussen.<br />
• Durch die Integration von Komponentenfehlerbäumen<br />
in Entwicklungsmodelle sind diese Fehler leicht für<br />
jede Komponente zu identifizieren und können so für<br />
eine pWCET Analyse nutzbar gemacht werden.<br />
Diagrammtyp zur automatisierten pWCET Analyse<br />
• beinhaltet Modellelemente von CFTs und<br />
funktionalen Entwicklungsmodellen.<br />
• vereinfacht die Kombination von Fehlern die die<br />
Laufzeit beeinflussen und den dazugehörigen<br />
Komponenten.<br />
• erlaubt eine automatisierte pWCET Analyse.<br />
17
<strong>SPES</strong> Modeling Framework –<br />
Transversale Fragestellungen<br />
abstrakter<br />
konkreter<br />
Abstraction Layers<br />
Viewpoints<br />
Requirements Functional Logical Technical<br />
...<br />
...<br />
Echtzeit-spezifische Herausforderungen:<br />
...<br />
...<br />
• Mapping von Prozessen auf Prozessoren (räumliche Planung)<br />
• Scheduling der Ausführung der Tasks (zeitliche Planung)<br />
• Verifikation des Verhaltens der Applikation (Korrektheit)<br />
...<br />
...<br />
18
Realzeit-Anforderungen<br />
Platform-independent Model<br />
Platform-specific Model<br />
Task-specific<br />
Real-Time Requirements<br />
(High-Level)<br />
Real-Time Requirements<br />
Real-Time Engineering<br />
Hardware-specific<br />
Real-Time Capabilities<br />
• ZP-AP5 befasst sich mit „Paralleler Echtzeit“<br />
• „Cross-Cutting-Concern“ im <strong>SPES</strong> Meta Modell<br />
• Verbindung zwischen Requirements Viewpoint und Technical Viewpoint<br />
19
Allokation in Raum und Zeit<br />
Software Anforderungen<br />
Hardware Ressourcen<br />
Konstruktion<br />
einer Verteilung<br />
Konstruktion<br />
eines Schedules<br />
Validierung<br />
Deployment-Schema<br />
(Scheduling und Mapping)<br />
• Modellbasiertes Deployment<br />
auf komplexen, parallelen<br />
Hardware-Architekturen<br />
• Beachtung von harten<br />
Echtzeitanforderungen<br />
• „Correctness by Construction“<br />
– Konstruktion statt Analyse<br />
20
Konstruktion einer Verteilung<br />
Herausforderung:<br />
• Mehrstufige Avionik Hardware-Architekturen<br />
– Cabinets, Boxes, Boards, Prozessoren, Cores<br />
– Ca. 1000 Applikationen und ca. 100<br />
Prozessoren<br />
• Effiziente Verteilung finden, so dass<br />
Ansatz:<br />
– Zuverlässigkeitsanforderungen erfüllt werden<br />
– Ressourcen nicht überbucht werden und<br />
– die Kommunikation minimiert wird.<br />
• Spezifikation mit Hilfe einer DSL<br />
• Entwicklung spezieller Algorithmen und<br />
Heuristiken für große Mapping-Probleme<br />
21
Konstruktion eines statischen Schedules<br />
Problem:<br />
• Statische Schedules aufwändig zu erstellen<br />
• Parallele Architekturen erhöhen die<br />
Komplexität zusätzlich<br />
Ansatz:<br />
• Modellbasierte Konstruktion fehlerfreier und<br />
ausführbarer Schedules<br />
• die Berücksichtigung aller Anforderungen<br />
wird garantiert<br />
Nutzen:<br />
• frühe Validierung des Softwaredesigns und<br />
Bewertung von verschiedenen Architekturen<br />
22
Validation<br />
• Eine dissimilare Technik für die<br />
Überprüfung des generierten Schedules.<br />
• Basiert auf Model Checking mit UPPAAL<br />
• Erstellt automatisch ein formales Modell<br />
aus dem generierten Schedule<br />
• Erlaubt die Prüfung von Modell-<br />
Eigenschaften, z.B.:<br />
"Ist es immer wahr, dass Task 1<br />
mindestens 1.3ms CPU Zeit bekommt?"<br />
23
Evaluation Highlights: Industrie Studien<br />
Automotive<br />
Energy<br />
Avionics<br />
Automotive<br />
Automotive<br />
Automation<br />
eHealth<br />
Automation<br />
Avionics<br />
Automotive<br />
Avionics<br />
Energy<br />
Avionics<br />
24
abstrakter<br />
konkreter<br />
Der <strong>SPES</strong> Marketplace<br />
Abstraction Layers<br />
3<br />
5<br />
1<br />
7<br />
2<br />
Viewpoints<br />
18<br />
6<br />
25
abstrakter<br />
konkreter<br />
Der <strong>SPES</strong> Marketplace – cont.<br />
Abstraction Layers<br />
8, 14b<br />
4, 14,<br />
17<br />
16<br />
14 a/c<br />
10 - 13<br />
Viewpoints<br />
15<br />
16<br />
26
Change language