SPES XT Projektabschluss - TUMspes2020.informatik.tu-muenchen.de/praesentationen... · • Parameterization & Varianten in IBM Rhapsody • Rhapsody API und JAVA • Eclipse IDE •

D. Sander Airbus

München - Ottobrunn, 10.07.2015

SPES_XT ProjektabschlussEC2 Optimales Deployment

SPES 2020_XT – Projektabschluss

Partner der EC

2

• Airbus Group Innovations

• Airbus Operations

• FORTISS

• Fraunhofer FOKUS

• Fraunhofer IESE

• Inchron

• Liebherr Aerospace

• OFFIS

• Robert Bosch / ETAS

• Siemens

• TUM


Ziele EC2

3

Optimale Verteilung (Deployment) von Funktionen auf eine Rechnerarchitektur

Reduzierung der Rechnerkapazität / Hardwarekosten

Gewicht-, Platz- und Energiebedarf

für konkurrenzfähigere, ressourcenschonendere und umweltfreundlichere

Produkte.

Innovationsbedarf besteht in der Methodik zur Verteilung als auch in der

praktischen Anwendbarkeit der Methodik durch geeignete Software-

Werkzeuge.

Methodik umfasst funktionale und nicht-funktionale SW/HW-Modelle und

Randbedingungen, modellierte Designalternativen, formalisierte multi-kriterielle

Zielfunktionen und Entscheidungsabhängigkeiten.

Vision: Erweiterung von Deploymentszenarien auf Multi-Aspekte


EC2-Konzepte im SPES-Kontext

4

• SPES-Methodik konform zur Abbildung von Deploymentaspekten

• Erweiterungen des MM (Constraints, Metriken, Optimierungskriterien) zur

• Definition des Design Spaces (Modellierungsbereich)

• Optimierungsmethoden mit Tools und Plattformen (Lösungsbereich)

• Entwicklung eines Deploymentprozesses

• Evaluation an Fallbeispielen

Viewpoint-Konzept bildet

den Modellierungsbereich ab:

4


Generischer Prozess

5

Parameter &

Kriterien QT1Anforderungen

an die Methodik

QT3

EC4

Technical Viewpoint

Logical Viewpoint

Functional Viewpoint

DSE Parameters / Goals

Initial System

Task StructureConstraints

Optimization Goals

Process Parameters

Result

Design Space Exploration

Define DSE Parameters

Desired Solution?

Task Structure Creation

yesno

Define Require-ments/Goals

Functional Model

Define Initial System

(Partial) Solutions

Result Status

optional

Requirements/GoalsRequirements Viewpoint

Methodiken

QT2

Modelle


Methoden

EC2 Fallstudien

6

Siemens, Liebherr, Airbus, Bosch

mit akademischen Partnern

Solver Methoden:

‚Find one deployment & iterate‘

‚Find all deployments & rank‘

‚Optimize local & global‘

Anwendungsgebiete:

Spatial & temporal deployment

Static / dynamic schedule

‚Non-functional resource allocation‘

(SMT, constraint solver, metrics)

‚Non-funtional & functional resource

Allocation‘ (ILP/SAT-solver, metrics)


EC2 Fallstudien

Fallstudie Kriterien Methoden

Kommunikationssystem

Flugzeugkabine (CIDS)

Resourcen (HW, Netzwerk,

Anzahl), Energieverbrauch

Bewertungsmetriken,

manuelle Iteration

Integrierte Modulare Avionik

Netzwerk (IMA)

Schnittstellen,

Energieverbrauch, Safety,

Position

Constraint Programming

Flugsteuerung Resourcen, Safety,

Schnittstellen,

Wiederverwendung

Linear Programming,

genetische Algos

Entsalzungsanlage Schnittstellen,

Energieverbrauch, Anzahl

Komponenten, Kabelkosten

Linear Programming,

genetische Algos

Fahrspurassistent Schedulability, Hardware

Modifikationen,

Kommunikationsverhalten,

Signalgrößen

Mehrstufiger, iterativer

Ansatz

7


Fallbeispiel: Kontext CIDS

8

• CIDS System Model

• Parameterization & Varianten in IBM Rhapsody

• Rhapsody API und JAVA

• Eclipse IDE

• JAVA Code für ausführbare Bewertungsmetriken

Cabin Functions:

Lighting, Audio Functions,

Smoke Detection,

Signalling …


Fallbeispiel: CIDS Design Methoden

9

Model

Metric

Result

NOK

OK

Java-Code

Design Verbesserung mit Assessment Metrics – Fraunhofer IESE

Airbus Rhapsody Ansatz


Fallbeispiel: IMA Design Methoden

10

Constraint Programming –

Fraunhofer FIRST/FOKUSComputer Properties:

Type RDC A,

power, location..

Interface

Component

Interface

Component

Interface

Component

Interface

Component

I/F to System VCS 1

I/F to System VCS 1

I/F to System VCS 1

Interface

Adapter

Interface

Adapter

Interface

Adapter

Interface

Adapter

Computer Properties:

Type CRDC A,

power, location..

Sensor (flow,

pressure…)

Actuator

(valve, pump..)

I/F to System VCS 1

I/F to System VCS 1

I/F to System VCS 1

Properties:

Location,

Properties:

Location, power

Board=StringManufacturer=String

RAM=Integer

ROM=Integer

Side=String

Route=String

IOAdapter=StringType= CustomizeType1…40

UnitsAvailable=Integer

Application (Eq-Ebene)=String_EQ1DevelopedBy=String

CoreUtilization=Integer

RequiredRAM=Integer

RequiredROM=Integer

RequiredIOAdapterType=CustomizeType1…40+

Exclusive+Units=Integer

PositionEqX=Integer

PositionEqY=Integer

Automated and

manual grouping

Manual defined

constraints

Technischer Kontext:

• 2000 Interfaces, 35 Typen

• 30 Computer, 2 Typen

• Eigenschaften: Position, Power,

Groupen, DAL, Seite

• Safety & Mapping Constraints

• Bewertungsmetriken

Ergebnisse:

• Begrenzte Lösbarkeit: ~ 500

Interfaces, ~35 Typen,

constraintabhängig

• Anwendbarkeit nachgewiesen

• Nicht ausreichende Performance


Fallbeispiel Design Space Exploration

11

HW Execution Platforms

OS

class MM_TechnicalArchitecture

«MetaModel»

TechnicalHWComponent

+ RadiationsSensibil ity :RadiationSensibil ityType

«Safety»

+ Location :LocationType

+ PSEOtherApplications :Hours

+ PSESafetyApplications :Hours

+ Reliabil ity :HazardPerHourExponent

«Resource»

+ PowerConsumptionAverage :Watt

+ PowerConsumptionPeak :Watt

A

«MetaModel»

OnChipComponent

«MetaModel»

Interconnect

+ Arbitration :ArbitrationSet

«Performance»

+ Bandwidth :KiloBitPerSecond

«Interface»

+ Protocol :CommunicationProtocol

+ Type :CommunicationType«MetaModel»

Memory

«Resource»

+ Size :KiloByte

+ Type :StorageType

+ Width :Bit

«Performance»

+ Speed :KiloBytePerSecond

«MetaModel»

IOModule

+ NChannels :int

+ NControllers :int

«Performance»

+ BandWidth :KiloBitPerSecond

+ Latency :Time

«DataInterface»

+ Direction :DirectionType

+ Function :IOType

«MetaModel»

Processor

«Timing, Safety, Performance»

+ NCompleteBus :Integer

«MetaModel»

MasterComponent

«MetaModel»

Core

«Resource, Performance»

+ FloatingPoint :FP_Set

«Performance»

+ Footprint :AverageInstructionsPerStatementOfCCode

+ Speed :MIPS

+ RelativeRate :float

«Safety»

+ IsIndependent :Boolean

«Safety, Resource»

+ ResourceAccessCounter :Integer

«MetaModel»

AddressSpaceProtectionUnit

+ Granularity :Bytes

+ Mode_distinction :boolean

+ NoOfRegions :int

+ RW_distinction :boolean

+ Task_distinction :boolean

«MetaModel»

HardwareAccelerator

«MetaModel»

MasterIOModule

«MetaModel»

SupportModule

+ Speed :MHz

HWSafetyAspect

+ HWDiagnosticCoverage :Percentage

«MetaModel»

Board

«MetaModel»

BoardComponents

«MetaModel»

onChipMemory

«MetaModel»

offChipMemory

«MetaModel»

customHardware

«MetaModel»

reconfigurableHardware

«MetaModel»

GPU

«MetaModel»

offChipGPU«MetaModel»

onChipGPU

«MetaModel»

Computer

«MetaModel»

Cache

«MetaModel»

Display

«MetaModel»

TechnicalSWComponent

«MetaModel»

TechnicalComponent

+ Name :String

«Safety»

+ Fabricator :FabricatorType

+ SafetyLevel :SafetyLevelType

«MetaModel»

FailureManagement

«FaultIsolation»

+ BlockFurtherAccess()

+ DegradeComponent()

+ VoteDataCorrectness()

«FaultRecording»

+ LogFailure()

«FaultDetection»

+ MonitorDataCorrectness()

+ MonitorPeriodicity()

+ MonitorPower()

+ MonitorResourceConsumption()

+ MonitorSWStack()

+ MonitorTemperatur()

«FaultCorrection»

+ RestoreViaRedundancy()

+ RestoreViaReload()

«MetaModel»

ResourceSharingMechanisms

«MetaModel»

Security

+ CheckAuthorization()

+ CheckAuthenticity()

+ CheckIntegrity()

«MetaModel»

Services

«Safety»

+ Fabricator :FabricatorType

+ SafetyLevel :SafetyLevelType

«Performance»

+ CostsPerformance :MIPS

«Resource»

+ CostsMemoryVolatile :KiloByte

+ CostsMemoryPersistent :KiloByte

+ CostsMemoryPermanent :KiloByte

+ CostsCommunicationAmount :KiloBitPerSecond

+ CostsCommunicationProtocol :CommunicationProtocol

+ CostsCommunicationType :CommunicationType

«Development»

+ CostsImplementation :Hours

+ CostsCertification :Hours

«MetaModel»

Serv iceComponent

«MetaModel»

RedundancyManagement

«MetaModel»

Configuration«MetaModel»

ConfigurationParameter

+ Configurability :{FixProperty, StartUpConfigurable, RuntimeConfigurable}

+ ParameterName :String

+ ParameterValue

«MetaModel»

ApplicationSWC

«MetaModel»

MiddlewareSWC

«MetaModel»

API

«use»

*

1..*

1..*

0..1 1..*1..*

1..*

1..*

*

RHF_independence

1..*

1..*

class MM_LogicalArchitecture

«MetaModel»

Application

A

«MetaModel»LogicalComponent

+ Name :String+ ApplicationDomain :DomainList

«Deployment»+ AbstractionLevel :AbstractionLevelType

«MetaModel»

Communication

«Deployment»+ Type :CommunicationType

+ Protocol :CommunicationProtocoll+ CommunicationTime :MicroSecond+ SignalValidity :MicroSecond

+ Delay :MicroSecond+ Synchronous :Boolean

+ Bandwidth :KiloBitPerSecond+ SamplingRate :KiloHertz

+ Deterministic :Boolean

«MetaModel»IO

«Deployment»

+ Type :IOType+ Bandwidth :KiloBitPerSecond

+ SamplingRate :KiloHertz

«MetaModel»Storage

«Deployment»

+ Type :StorageType+ Size :KiloBytes

+ Speed :KiloBytePerSecond+ LatencyMaxWrite :MicroSecond

+ LatencyMaxRead :MicroSecond+ Endurance :WriteLifeCycle+ WorkloadPeak :AccessPerFrame

«MetaModel»

Safety

«Deployment, Decomposition»+ SafetyLevel :SafetyLevelType

+ FaultIsolationRequired :FaultIsolationTypeList+ FaultIsolationKind :FaultIsolationKindType+ FaultIsolationGranularity :FaultIsolationGranularityType

«Deployment»+ DislocalityList :LogicalComponentList

+ DissimilarityList :LogicalComponentList+ Duplicatable :Boolean

+ Reliability :HazardPerHourExponent

«Decomposition»

+ RedundanceMultiplicity :Integer A

«MetaModel»PerformanceTiming

«Deployment»

+ Period :MicroSecond+ ExpectedMaxDuration :Microsecond

+ Jitter :Microsecond+ AllowPartitionSharing :Boolean

+ EventMinimalInterface :MicroSecond+ EventReactionTime :Microsecond

+ SignalCalculationTime :Microsecond+ Deadline :Microsecond+ Priority :CriticalityType

«Decomposition, Deployment»~ Complexity :EvaluatedLinesOfCode

+ TypeOfDeadline :DeadlineType

«MetaModel»

ValidationVerification

«Decomposition, Deployment»+ Diagnostic :DiagnosticTypeList

«Deployment»+ XBIT :Boolean

«MetaModel»

Reusability

«Decomposition, Deployment»+ ReuseCertification :ReuseCertificationType

+ ReuseServices :ReuseServicesType+ ReuseExecutionUnit :ReuseExecutionUnitType

«Deployment»+ CheckAbstractionLevel :Boolean

«MetaModel»

Maintainability

«Deployment»+ ExtensionRate :Percent+ Propageable :Booelan

«MetaModel»

Security

«Deployment»

+ DislocationList :LogicalComponentList

«Deployment, Decomposition»+ SecurityLevel :SecurityLevelType

«MetaModel»Function

«Decomposition»

+ FunctionName :String+ FaultIsolationRequired :Boolean

«Deployment»+ ConcurrentUsage :Boolean

«MetaModel»

Signal

+ SignalName :String

«Decomposition, Deployment»+ VerificationRequirement :Boolean

«Deployment»+ IntegrityCheck :IntegrityCheckTypeList

1..*

1

0..*1

0..*1

0..*1

0..*

1

0..*

1

0..*

1

1

1

1..*

1

1..*

1

1..*

1

0..*

1

SW Applications

(SWAs)

Formalization / Abstraction

via instances

of SPES-Metamodel

Execution Units

(EXUs)

Mapping RulesResource: Performance, Memory, IO, …

Safety: Safety Level, Reliability,

Dissimilarity, Redundancy, …

Verifiability: Interface Availability, …

Reuseability: Functionalities, Certification, …

Network of

System Functions

Optimal Mappings

Generic

Logical Component

Generic

Technical Component

Avionics ExpertsSWA-1

SWA-i

SWA-n

SWA-2

EXU-1

EXU-2

EXU-j

EXU-p

Flight Control System: > 50 SW-Applications, today: ~ 1 Computer per SW-Application

Objective: Reduce the number of computers thanks to optimal deployment

Design Space

ExplorationTUM, Fokus, fortiss, …


Design Space Exploration: Liebherr / TUM

12

bdd [Package] ACL [ActuatorControlLoop]

A_ACL_RHIB :Application

Name = Aileron_ActuatorControlLoop_RightHandInBoard

A_ACLRHIB_Code :Storage

Type = PERMANENTSize = 1000KB

A_ACLRHIB_PerfTim :PerformanceTiming

Complexity = 5000 LoLCPeriod = 3msExpectedMaxDuration = 1,5ms

A_ACLRHIB_Safety :Safety

DissimilarityList = A_ACL_RHIB-M, A_ACL_RHOB, A_ACL_RHOB-MDuplicatable = YESFaultIsolationRequired = YESReliability = 10^-6SafetyLevel = DAL-CDislocalityList = A_ACL_RHOB

A_ACLRHIB_Reusability :Reusability

ReuseCertification = OPTIONAL

A_ACLRHIB_Maint :Maintainability

ExtensionRate = 20%

A_ACLRHIB_ARINC :Communication

Type = ARINCDeterministic = YESBandwidth => 10Kb/sCommunicationTime = 100us

A_ACLRHIB_Data :Storage

Type = VOLATILESize = 2000KBSpeed = 1MB/s

A_ACLRHIB_Calibration :Storage

Type = PERSISTENTSize = 100KBSpeed = 100Kb/sEndurance = 100000 WR-Cycles

A_ACLRHIB_CAN1 :Communication

Type = CANDeterministic = YESBandwidth => 512Kb/sCommunicationTime = 10us


Type = CANDeterministic = NOBandwidth => 512Kb/sCommunicationTime = 10us













ExtensionRate = 20%























ExtensionRate = 20%























ExtensionRate = 20%























ExtensionRate = 20%











SW-App needs modeled in E.A.

bdd [Package] Platform2 [Platform2]

P2_Core1 :Core

Variant = TricoreV1.6

RelativeRate = 28,37Reliability = 10^-6

SingleCoreProc :Processor

Fabricator = INFINEON

PSESafetyApplications = 125000 Hours

PSEOtherApplications = 5200000 Hours

P2_RAM :Memory

Type = RAM

Size = 256KB

P2_CAN-A :Interconnect

Type = CAN

Bandwidth = 500Kb/s

IsDeterminist = TRUE P2_ARINC2 :

Interconnect

Fabricator = LEG

Type = ARINC

Bandwidth = 100Kb/s

IsDeterminist = TRUE

P2_CAN-B :Interconnect

Type = CAN

Bandwidth = 500Kb/s


P2_ARINC1 :

Interconnect

Fabricator = LEG

Type = ARINC

Bandwidth = 100Kb/s


P2_FLASH :

Memory

Type = FLASH

Size = 4MB

Platform2 :Board

Fabricator = CES

P2_DFLASH-EEPROM :

Memory

Type = DFLASH

Size = 192KB

P2_RAM-External :

Memory

Fabricator = STM

Type = RAM

Size = 1MB


P2_Core1 :Core







P2_RAM :Memory

Type = RAM

Size = 256KB


Type = CAN

Bandwidth = 500Kb/s


Interconnect

Fabricator = LEG

Type = ARINC

Bandwidth = 100Kb/s



Type = CAN

Bandwidth = 500Kb/s


P2_ARINC1 :

Interconnect

Fabricator = LEG

Type = ARINC

Bandwidth = 100Kb/s


P2_FLASH :

Memory

Type = FLASH

Size = 4MB

Platform2 :Board

Fabricator = CES

P2_DFLASH-EEPROM :

Memory

Type = DFLASH

Size = 192KB

P2_RAM-External :

Memory

Fabricator = STM

Type = RAM

Size = 1MB


P2_Core1 :Core







P2_RAM :Memory

Type = RAM

Size = 256KB


Type = CAN

Bandwidth = 500Kb/s


Interconnect

Fabricator = LEG

Type = ARINC

Bandwidth = 100Kb/s



Type = CAN

Bandwidth = 500Kb/s


P2_ARINC1 :

Interconnect

Fabricator = LEG

Type = ARINC

Bandwidth = 100Kb/s


P2_FLASH :

Memory

Type = FLASH

Size = 4MB

Platform2 :Board

Fabricator = CES

P2_DFLASH-EEPROM :

Memory

Type = DFLASH

Size = 192KB

P2_RAM-External :

Memory

Fabricator = STM

Type = RAM

Size = 1MB

Exec. Units capabilities modeled in E.A.

Check DAL

Check Dissimilarity

Check Dislocality

Check Storage Size

…

Mapping rules algorithms

...

...

LLI Objective:

“Reduce the number of

Computers“

Result of Mapping showed in MOEA

SW-Applications described in the MOEA tool

Constraint expressed in SAOL for MOEA

Execution Units described in the MOEA tool

Objectives expressed in SAOL for MOEA


Fallbeispiel:

Entsalzungsanlage Siemens / TUM

Überblick: Bestandteile:

• 5 Anlagenbereiche

• 25 DIO Gruppen

• 200 Sensoren

• 300 Ventile

• 100 Pumpen

• 28 Inverter

13

Sea Water

Tank

Sand

Filters

Cartridge

Filters

Reverse

Osmosis

Desalined

water Tank

Drinking

Water Tank

Drinking

Water netBeachwells

1..4

Drinking

Water Pump

Station

Engineering Station + Emergency

Operator Station Operator Station

Large Display

Rack UR2

S7-400H

Scalance X208

Industrial EthernetRedundant

PCS 7 Servers

Report Printer Alarm Printer

Scalance X208Scalance X208

SERVER ROOM CONTROL ROOM

Power

Ditribution

Wash

Water

Tank

Sea

Water

Sea

Water

Purging Air

Wa

sh

Wa

ter

Ta

nk (

RO

)

Neutraliza

tion Tank

Dilution Water

Tank Reactive

Tank

Waste

Water Net

Service water

Service water

network

Turbine

High Pressure

Pumps

Meerwasserentsalzungsanlage

Al Hidd, Bahrain


Fallbeispiel:

Entsalzungsanlage Siemens / TUM

Rahmenbedingungen:

C1 Sensors & Ventile sind zu DIOs

im selben Bereich verbunden.

C2 Beachtung von Schnittstellentypen

C3 Beachtung von Schnittstellenanzahl

C4 Beachtung von Stromverbrauch

Optimierungsziele:

O1 Minimiere # DIOs

O2 Minimiere # Inverter

O3 Minimiere Kosten für

Stromkabel

14

600

verteilbare Einheiten

216

Deploymentziele Anlagengeometrie

Problemstellung:

„Optimale Verbindung von Sensoren und Ventilen zu DIOs und Pumpen zu

Inverter unter Berücksichtigung von Rahmenbedingungen“.

In System Architect:

• Systemmodellierung

• Optimierungskriterien

• Rahmenbedingungen

• Optimierung

Lösung:ILP Solver: 3 s

ILP (Pareto): 11,6 min

34% weniger DIOs

11% weniger Inverter


System Architect

• Integriertes Werkzeug zur

durchgängigen Modellierung und

Optimierung von Systemen

– Flugkontrollsystem mit Liebherr

– Entsalzungsanlage mit Siemens

• Spezifikation der Optimierungsziele

und Rahmenbedingungen mittels

SAOL (System Architecture

Optimization Language)

• Verwendete Lösungsverfahren:

– MOEA (genetischer Algorithmus)

– SMT (Constraint-Solver)

– ILP (Lineare Optimierung)

– Pareto-Optimierung (SMT, ILP)

15


Anwendung des Fallbeispiels

• Aufgabe des Fahrspurassistenten

– Erkennen und halten der Fahrspur, z.B. bei Nachtfahrten

– Unfallrisiko minimieren, Fahrsicherheit erhöhen

• Die Anwendung des Fahrspurassistenten wird durch das

Zusammenspiel mehrere Steuergeräte, Sensoren und Aktoren als

verteilte Anwendung in einem Steuergerätenetzwerk realisiert

• Bosch als Zulieferer bietet die Anwendung Fahrspurassistent an

– Unterschiedliche Setups an involvierten Steuergeräten und

vorhandener Peripherie bei unterschiedlichen Automobilherstellern

– Gemeinsame Plattform, jedoch müssen individuelle Kundenwünsche

(Features, Qualität, Preis) von Automobilherstellern realisiert werden

16


Fahrspurassistent Anwendung

• Modellierung der Kommunikation mit Ausführungszeiten &

Hardwarestruktur

• Constraints

– EndToEnd-Deadlines

– Safety / Redundanz

• Optimierungsziele

– Anzahl ECUs, Kosten

– Gewicht, Busauslastung

• Deployment-Parameter

– WCETs für Schedulability

– Hardware Modifikationen

– Kommunikationsverhalten

– Signalgrößen

17

SubsystemSubsystem

CAN

FlexRay

GWECU

ECUECU

CAN

ECU

ECUECU

GWECU


Synthese / Optimierung

Lösungsansatz

• Modellierung

– Funktionsnetzwerk + Signale

– Hardware (Steuergeräte + Busse)

– Constraints + Optimierungsziele

• Mehrstufiger, iterativer Ansatz

1. Vorplatzierung auf Subsysteme

2. Lokal optimale Platzierung auf

Steuergeräte im Subsystem

3. Backtracking falls unvollständiges

Deployment

• Evaluation

– Weitere Qualitätseigenschaften

mittels INProVe

– Ergebnisvergleich mit

verschiedenen Visualisierungen

18

Modellierung

Evaluation

SubsystemSubsystem

CAN

FlexRay

GWECU

ECUECU

CAN

ECU

ECUECU

GWECU

Constraints

costs in Euroweight in g

# of ECUs in #

85

90

95

100

105

110

920

940

960

980

1000

1020

1040

3

4

5

INProVe

Optimierungsziele

Deployment-Parameter


Architekturwizard

• Unterstützt Ingenieure bei der Durchführung des DSE-Prozesses

– Hilfe bei einzelnen Schritten durch Task Wizards:

• Unterstützung bei einem/mehreren Tasks einer Aktivität im Prozess

• z.B. Bestimmung von Optimierungskriterien und –metriken. Architecture

Wizard

Early Validation/

Modular Safety

System Function Networks

DSE Parameters

Task Structure(s)

Constraints

Optimization Objectives

Deployment Parameters

Result

Design Space

Exploration

Define DSE

Parameters

Desired

Solution?

Determine

Task Structure

yes

no

Requirements/Goals

Define Require-

ments/GoalsFunctional Model

optional

(Partial) Solutions

Result Status

EvaluationEvaluation

Results

Evaluation Parameters

Target Architecture(s)

+ (Partial) Deployment

Define Target

Architecture

Process Parameters

Technical Viewpoint

Logical Viewpoint

Functional Viewpoint

Requirements Viewpoint

SelectionDecision

Hardware

Architecture

Wizard

DSE Method

Decision Wizard

Optimization

Objective Wizard

Graphical Decision

Support Wizard

AHP Wizard

19


Resultate & Demos

• Durchgängige Methodik innerhalb von EC2 erreicht durch

– SPES Meta-Model Konzept

– werkzeugtechnische Umsetzungen

• Bosch Fahrspurassistent:

– Iterativ multi-kriteriell optimiertes Deployment

– Unterstützung durch Architekturwizard

– Mehrere Analyse-Backends durch QT3 Werkzeugplattform integriert

• TUM & FORTISS Optimierungsmethoden:

– Mapping Interface- und Rechnerresourcen

– Anwendung: Flugkontrollsystem und Entsalzungsanlage

20

Documents

SPES XT Projektabschluss - TUMspes2020.informatik.tu-muenchen.de/praesentationen... · • Parameterization & Varianten in IBM Rhapsody • Rhapsody API und JAVA • Eclipse IDE •