der spes modellierungsansatz - spes 2020spes2020.informatik.tu-muenchen.de/praesentationen/spes...

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()



UserInteraction


eingeschaltet

Ansteuerung

berechnen


[OperationOn]

[!OperationOn]

ausgeschaltet

OperationOn()

Sensor()

SupplyBand()

!OperationOn()



UserInteraction


eingeschaltet

Ansteuerung

berechnen


[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


Crane1


Crane2

Wegpunkte für Crane2

berechnen


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


...

...

...

...

...

...

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


...

...

...

...

...

...

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


...

...

...

...

...

...

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


...

...

...

...

...

...

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

Der SPES Marketplace

25

Viewpoints A

bstr

action L

aye

rs

abstrakter

konkreter

3

2

6 5

1

18

7

Der SPES Marketplace – cont.

26

Viewpoints A

bstr

action L

aye

rs

abstrakter

konkreter

14 a/c

15

16

8, 14b

10 - 13

16 4, 14,

17

der spes modellierungsansatz - spes 2020spes2020.informatik.tu-muenchen.de/praesentationen/spes...

Documents