- SPES 2020

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