der spes modellierungsansatz - spes 2020spes2020.informatik.tu-muenchen.de/praesentationen/spes...
TRANSCRIPT
GEFÖRDERT VOM
Dr. Thorsten Weyer
Universität Duisburg-Essen
Der SPES Modellierungsansatz
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
6
Requirements Functional Logical Technical
...
...
...
...
...
...
abstrakt
konkret
Ab
st
ra
ct
io
n
La
ye
rs
V i e w p o i n t s
Viewpoint „Requirements“
7
• Dokumentation der operationellen Umgebung des Systems
• Dokumentation der Ziel des Systems und zugehöriger Szenarien
• Spezifikation der zur Zielerreichung notwendigen fachlichen Eigenschaften
Modellierungsziele
Kontext
environment
model
«flowPort»
Crane1ActionSignal
«flowPort»
Crane2ActionSignal
«flowPort»
DeliveryBandSignal
«flowPort»
SensorSignal
«flowPort»
SupplyBandSignal
«flowPort»
SystemOutput
«flowPort»
UserInput
Zylinderkopffertigungsanlage
«flowPort»
Crane1ActionSignal
«flowPort»
Crane2ActionSignal
«flowPort»
DeliveryBandSignal
«flowPort»
SensorSignal
«flowPort»
SupplyBandSignal
«flowPort»
SystemOutput
«flowPort»
UserInput
User
Env ironment
Crane1 (extern)Crane2 (extern)
SupplyBand (extern)Deliv eryBand (extern)
SensorSignal
«flow»
DeliveryBandSignal
«flow»SupplyBandSignal
«flow»
Crane2ActionSignal
«flow»
Crane1ActionSignal
«flow»
SystemOutput
«flow»
UserInput
«flow»
Ziele
<< hardgoal >>
Transport von Werkstücken
gewährleisten ()
<< softgoal >>
Kolli lsionen
vermeiden ()
<< hardgoal >>
Werkstück
transportieren ()
<< hardgoal >>
Produktionsstofftransport
gewährleisten ()
<< hardgoal >>
Werkstücke
erkennen ()
<< hardgoal >>
Vermessen von
Produktionsstoffen ()
<< hardgoal >>
Zeitgleiche
bearbeitung ()
<< hardgoal >>
Rohstoff
transportieren ()
+
«Contribution»
++
«Contribution»
--
«Contribution»
Szenarien
system
scenarios
SupplyBand IOAdapter
(from 2.1.2. Ziele / Szenarien "IOAdapter")
UserInteraction
(from 2.3.2. Ziele / Szenarien "UserInteraction")
eingeschaltet
Ansteuerung
berechnen
loop SupplyBand ansteuern
[OperationOn]
[!OperationOn]
ausgeschaltet
OperationOn()
Sensor()
SupplyBand()
!OperationOn()
SupplyBand IOAdapter
(from 2.1.2. Ziele / Szenarien "IOAdapter")
UserInteraction
(from 2.3.2. Ziele / Szenarien "UserInteraction")
eingeschaltet
Ansteuerung
berechnen
loop SupplyBand ansteuern
[OperationOn]
[!OperationOn]
ausgeschaltet
OperationOn()
Sensor()
SupplyBand()
!OperationOn()
SupplyBand IOAdapter
(from 2.1.2. Ziele / Szenarien "IOAdapter")
UserInteraction
(from 2.3.2. Ziele / Szenarien "UserInteraction")
eingeschaltet
Ansteuerung
berechnen
loop SupplyBand ansteuern
[OperationOn]
[!OperationOn]
ausgeschaltet
OperationOn()
Sensor()
SupplyBand()
!OperationOn()
Lösungsbezogene
Anforderungen
solution-oriented
system
requirements
R1
RN
Sensor
AutoMode
OperationOn
Crane1Action
Crane2Action
SupplyBand
DeliveryBand
Funktionen des TransportationController
Sensor
AutoMode
OperationOn
Crane1Action
Crane2Action
SupplyBand
DeliveryBand
Sensor
AutoMode
Bewegungsauftrag
Crane1
Bewegungsauftrag
Crane2OperationOn
Sensordaten v erarbeiten
Sensor
AutoMode
Bewegungsauftrag
Crane1
Bewegungsauftrag
Crane2OperationOn
SupplyBand
DeliveryBandOperationOn
Förderbandbewegungen
berechnenSupplyBand
DeliveryBandOperationOn
Crane1ActionBewegungsauftrag
Crane1
Wegpunkte für Crane1
berechnen
Crane1ActionBewegungsauftrag
Crane1
Crane2ActionBewegungsauftrag
Crane2
Wegpunkte für Crane2
berechnen
Crane2ActionBewegungsauftrag
Crane2
«block»
UserInput
«block»
OperationOn
«block»
AutoMode
«block»
Sensor
«block»
Crane1Sensor
«block»
Crane2Sensor«block»
SupplyBandSensor
«block»
Deliv eryBandSensor
«block»
SensorSignal
«block»
Crane1SensorSignal
«block»
Crane2SensorSignal«block»
SupplyBandSensorSignal
«block»
Deliv eryBandSensorSignal
«block»
SystemOuput
«block»
Action
«block»
Crane1Action
«block»
Crane2Action
«block»
SupplyBandAction
«block»
Deliv eryBandAction
«block»
ActionSignal
«block»
Crane1ActionSignal
«block»
Crane2ActionSignal
«block»
SupplyBandActionSignal
«block»
Deliv eryBandActionSignal
+Raw Data translated by IOAdapter +Translated Signal
+determins
Determination
+determined
+Bus-conformant Data translated by IOAdapter +Raw Signal
+represented Information
Representation
+Displayed data
Initial
Anlage eingeschaltet
Anlage ausgeschaltet
Final
AutoMode ManualMode
Initial
[UserInput = AutoMode]
[UserInput = !AutoMode]
[UserInput: einschalten][UserInput:
terminieren]
[UserInput:
einschalten]
• Systematische Gewinnung von Anforderungen
• Durchgängige Dokumentation / Spezifikation von Anforderungen
• Validierung von Anforderungen
Unterstützte
Aktivitäten
Modelle
Viewpoint „Functional“
8
System Funktion
• 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
Modellierungsziele
• Validierung von Anforderungen
• Generierung von Testfällen und Verifikationsbedingungen
• Funktionale Prototypen
Black Box Sicht
(aus VP RE)
«flowPort»
Crane1ActionSignal
«flowPort»
Crane2ActionSignal
«flowPort»
DeliveryBandSignal
«flowPort»
SensorSignal
«flowPort»
SupplyBandSignal
«flowPort»
SystemOutput
«flowPort»
UserInput
Zylinderkopffertigungsanlage
«flowPort»
Crane1ActionSignal
«flowPort»
Crane2ActionSignal
«flowPort»
DeliveryBandSignal
«flowPort»
SensorSignal
«flowPort»
SupplyBandSignal
«flowPort»
SystemOutput
«flowPort»
UserInput
User
Env ironment
Crane1 (extern)Crane2 (extern)
SupplyBand (extern)Deliv eryBand (extern)
SensorSignal
«flow»
DeliveryBandSignal
«flow»SupplyBandSignal
«flow»
Crane2ActionSignal
«flow»
Crane1ActionSignal
«flow»
SystemOutput
«flow»
UserInput
«flow»
Projektion
Funktions-Hierarchie Modelle
Unterstützte
Aktivitäten
Viewpoint „Logical“
9
Teilsystem Architektur
• Logische Beschreibung der Lösung durch Zerlegung in Teilsysteme
• Plattformunabhängigkeit der beschriebenen Lösung
• Wiederverwendbarkeit von logischen Teilsystemen
Modellierungsziele
• Verifikation des Systemverhaltens
• Simulation
Teilsystem
Verhalten
Teilsystem
Schnittstelle
Modelle
Unterstützte
Aktivitäten
Viewpoint „Technical“
10
Ziel-Hardware
Technical Perspective
Capture
Task
airTemp
CtrlTask
Scheduler
temp control
Var1
tempVal
Var2
tempSel
ECU
temp
Data
Logical Perspective
AirTempControl
control
Capture
temp
Temp
Data
<<allocate>>
Modellierungsziele
• Beschreibung der Ziel-Hardware (ECUs, Busse, Speicher, …)
• Definition von (Software-)Tasks und Scheduler
• Beschreibung der verteilungsspezifischen Kommunikation
• Plattformspezifische Beschreibung der Spezifikation
Logisches
Teilsystem
• Verifikation (Echtzeitanalysen, Scheduling, …)
• (Plattformspezifische) Verfeinerung der logischen Teilsysteme
(Logical Viewpoint)
• Deployment
Mapping
ProcessingResource
:Concurrency
Resource
:Concurrency
Resource
:SchedulerSlot :SchedulerSlot
:Scheduler
:Concurrency
Resource
:Scheduler
:SchedulerSlot
:SchedulerSlot
Task und
Scheduler
ComputingResource
app-task1:Taskcom:Task
app-task2:Task
bus-drv:Task
Signal1
Signal2
Message1 Frame1
payload Frame1header
Message1payloadheader
Signal1 Signal2
Kommuni-
kation
Unterstützte
Aktivitäten
VP „Technical“
VP „Logical“
VP „Functional“
VP „Requirements“
Integration der Viewpoints (beispielhaft)
11
System
F2 F1
C1
C2
C3
Bus
ECU1 ECU2
Voraussetzung für die Durchgängigkeit (insb. methodisch) ist, dass die Modelle der
verschiedenen Viewpoints semantisch zueinander in Beziehung gesetzt werden
Mögliche Entwicklungssystematiken (A)
12
Requirements Functional Logical Technical
...
...
...
...
...
...
1 2 3 4
5 6 7 8
9 10 12 11
V i e w p o i n t s A
bs
tr
ac
ti
on
L
ay
er
s
13
V i e w p o i n t s
Requirements Functional Logical Technical
...
...
...
...
...
...
Ab
st
ra
ct
io
n
La
ye
rs
1
2 3
4 6 5
8 7
Mögliche Entwicklungssystematik (B)
SPES Modeling Framework –
Transversale Fragestellungen
14
Viewpoints
Requirements Functional Logical Technical
...
...
...
...
...
...
Abstr
action L
aye
rs
abstrakter
konkreter
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
Durchgängige modellbasierte
Sicherheitsanalyse
15
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
Abstr
action L
aye
rs
Beispiel Viewpoint
Safety-fokussierte Deployment Analyse
16
Herausforderungen
• Es muss geprüft werden ob die Sicherheits-
anforderungen der logischen Komponenten erfüllt sind
• Die Erfüllung der Sicherheitsanforderungen muss
nachgewiesen werden
• Zusätzliche Kosten (Rezertifizierung) müssen
minimiert werden
Technical
Viewpoint
Logical
Viewpoint
C1
C2
C3 Bus
ECU1 ECU2
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
Überschneidung von Safety und Echtzeit
17
Abstr
action L
aye
rs
Beispiel Viewpoint Probabilistische Worst-Case Zeitanalyse pWCET
• 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.
SPES Modeling Framework –
Transversale Fragestellungen
18
Viewpoints
Requirements Functional Logical Technical
...
...
...
...
...
...
Abstr
action L
aye
rs
abstrakter
konkreter
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)
Realzeit-Anforderungen
• ZP-AP5 befasst sich mit „Paralleler Echtzeit“
• „Cross-Cutting-Concern“ im SPES Meta Modell
• Verbindung zwischen Requirements Viewpoint und Technical Viewpoint
19
Platform-specific Model
Platform-independent Model(High-Level)
Real-Time Requirements
Task-specific Real-Time Requirements
Hardware-specific Real-Time Capabilities
Real-Time Engineering
Allokation in Raum und Zeit
20
• Modellbasiertes Deployment
auf komplexen, parallelen
Hardware-Architekturen
• Beachtung von harten
Echtzeitanforderungen
• „Correctness by Construction“
– Konstruktion statt Analyse
Konstruktion
eines Schedules
Software Anforderungen
Hardware Ressourcen
Konstruktion
einer Verteilung
Deployment-Schema
(Scheduling und Mapping)
Validierung
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 Modell-
Eigenschaften, z.B.:
"Ist es immer wahr, dass Task 1
mindestens 1.3ms CPU Zeit bekommt?"
23
Evaluation Highlights: Industrie Studien
24
Automotive
Auto
motive
Automotive
Automotive
Automation
Automation
Energy
Energ
y
Avionics
Avio
nic
s
Avionics
Avionics
eHealth