Transcript EAST-ADL2 Example model

Relating CARM 2G DSLs
and EAST-ADL
Midterm presentation
CSE graduation project at ASML
Frank Razenberg
Supervisor: Ramon Schiffelers
Coach: Yanja Dajsuren
Outline
• Project overview
• Domains
− Process control & CARM 2G
− EAST-ADL
• Goals
• Approach
• Future work
/ department of computer science
17-7-2015
PAGE 1
Domain: process control
• Process control: engineering discipline that deals with maintaining
output of a specific process within a desired range.
• Example: cruise control, thermostat, ABS
/ department of computer science
17-7-2015
PAGE 2
Modeling the control application:
application model
• CARM 2G: ASML’s multi-disciplinary model-based development
environment
• Application model
• TransducerGroups describe a set of sensors or actuators
− Describes mechanical and electrical transducers
• ServoGroups describe a controller
• Calculations made using logical blocks
/ department of computer science
17-7-2015
PAGE 3
Available execution platform
• Physical platform represents available hardware
• IOBoards; sensors and actuators
• HPPCs; processors
• Communication network (RIO, HSSL, switches)
/ department of computer science
17-7-2015
PAGE 4
Mapping application to platform
Control
task
Sensor
Sensor
Control
task
Control
task
Control
task
Sensor
Control
task
Control
task
Actuator
Control
application
Actuator
Mapping
Processor
Core 1 Core 5
Core 2 Core 6
Core 3 Core 7
Core 4 Core 8
IOBoard
/ department of computer science
Processor
Execution
platform
Communication
network
IOBoard
17-7-2015
PAGE 5
CARM language stack
PGAPP PGSGPGWB
AppMap
Transducer
Application
Application
Application
Mapping
Platform mapping
Logical Platform
Platform Mapping
Physical Platform
Physical platform
/ department of computer science
CARM Model
17-7-2015
PAGE 6
Platform
Logical platform
Mapping
Conforms to
EAST-ADL standard
• EAST-ADL: approach to describe automotive electronic systems
though an information model in standardized form
• Aspects covered: vehicle features, functions, requirements, variability,
software components, hardware components, communication.
• Increasing interest from automotive industry, but still seen as research
effort
• Tool support: limited
•
•
•
•
Different vendors implement different subsets of the standard
Eclipse/Papyrus (open source, plugins closed-source)
MetaCase: MetaEdit+ (commercial)
PREEvision (commercial)
/ department of computer science
17-7-2015
PAGE 7
EAST-ADL architecture
EAST-ADL
PREEvision
features observed
from the outside
abstract functionality
of components
concrete functions,
allocations to hardware
17-7-2015
PAGE 8
EAST-ADL architecture
EAST-ADL
PREEvision
17-7-2015
PAGE 9
Project goals
Ecore
CARM 2G
metamodel
LCW_TC.carm2g
Temp. ctrl
(2) Determine
ontological commitment
of EAST-ADL to CARM
domain
(1) Relate CARM 2G
architecture &
concepts to EAST-ADL
Meta-meta model
EAST-ADL
metamodel
LCW_TC.eastadl
Meta model
Model
LCW Temperature
controller
17-7-2015
PAGE 10
High-level mapping CARMPREEvision
Application
Product Goals
AppMap
Logical Function Arch
Logical platform
Software Arch
Platform mapping
Hardware Arch
Physical platform
Geometrical topology
/ department of computer science
CARM Model
17-7-2015
PAGE 11
Example application
• Application: temperature controller IHxTC_LCW1
• For IH lens water cooling
• Contains
− Transducer group of 9 sensors
− Servo group: controller
− Transducer group with 1 heater actuator
/ department of computer science
17-7-2015
PAGE 12
Application in PREEvision
• Application: PGAPP language
• Servo groups: PGSG
− Blocks: PGWB
• PREEvision Logical Architecture
• LA System Diagram: connects
building blocks
• Building block: composition of
logical functions
• Logical Function type:
elementary block
LA System Diagram
App
SG inst. : SG
SG Def
SG inst. : BBT
SG: BuildingBlock
A : PGWB
A : LogicalFunc
B : PGWB
PGWB
PGWB
B : LogicalFunc
LFType
…
relating counterpart
instantiation
/ department of computer science
17-7-2015
PAGE 13
Logical Platform overview
• Logical platform abstracts from the physical properties but contains
the configuration of the hardware
• Contains Workers (abstracts from HPPC) and IOWorkers (abstracts from
IOBoard)
• Workers and IOWorkers contain a number of processing units
• ServoGroups are assigned to Workers
• TransducerGroups are assigned to IOWorkers
• Connections between Workers and IOWorkers
/ department of computer science
17-7-2015
PAGE 14
Example Logical Platform for TC
• Small example Logical Platform for this temperature controller:
•
•
•
•
2 IOWorkers; one for the sensors group, and one for actuator group
1 Worker for the servo group
Some processing units on the IOWorker/Workers
Connections between Worker and IOWorkers
/ department of computer science
17-7-2015
PAGE 15
High-level mapping of CARM2G layers to
PREEvision layers
Application
Product Goals
AppMap
Logical Function Arch
Logical platform
Hardware Arch
Platform mapping
Choosing HW architecture for logical
platform enables the use of PREEvision builtin mapping mechanism, including niceties
such as Traceability views, complete
Mapping View
Implementation level
Physical platform
/ department of computer science
17-7-2015
PAGE 16
AppMap hierarchical overview (alt. 1)
LogicalFunctionArchitecture
Logical System Diagram
Application
TG1
LA-NET:Mapping
SG1
TG2
TG1
IOW1
TG2
IOW1
SG1
W1
HardwareArchitecture
NetworkDiagram
LogicalPlatform
W1
/ department of computer science
IOW1
17-7-2015
PAGE 17
Alternative 1:
Logical Platform in HW Architecture
• Hardware Architecture
contains a Network Diagram
which can contain components
closely resembling those found
in CARM2G’s Logical Platform
• ECU component represents
Worker and IOWorker
• ECU’s contain Processing
Units that Logical Functions
can be mapped to
+ Straightforward and intuitive
mapping
- No typechecking possible
LogicalPlatform
Hardware Architecture
Network Diagram
IOWorker1
PU
ECU
PU
PU
Worker1
PU
IOWorker2
PU
PU
ECU
PU
PU
ECU
PU
PU
relating counterpart
instantiation
/ department of computer science
17-7-2015
PAGE 18
AppMap
• Built-in mapping has elements in Logical Architecture map to
Process Unit of an ECU in Hardware Architecture
+ Fit seems to be intuitive, but:
- Need one dedicated Process Unit per ECU for SG/TG to map to
- Not very flexible; no intuitive way of coupling (say) a schedule
/ department of computer science
17-7-2015
PAGE 19
High-level mapping of CARM2G layers to
PREEvision layers
Application
Product Goals
AppMap
Logical Function Arch
Logical platform
Hardware Arch
Platform mapping
Implementation level
Physical platform
/ department of computer science
CARM Model
17-7-2015
PAGE 20
Alternative 2:
Logical Platform in Logical Architecture
• IOWorker and Worker modeled as
Logical Function Type
• Ports represent ProcessingUnits
• Attribute on port specifies whether PU
is signal-, background or
controlProcessing
• Worker: one additional port for SG’s to
assign to
• IOWorker: one additional port for TG
instances to assign to
• Ontological instantiation: Workers and
IOWorkers represented by instances of
user-defined type instead of a an
instance of some language-defined
type
LogicalPlatform
IOWorker1
PU
LogicalArchitecture
System Diagram
IOW1
PU
W1
Worker1
PU
IOWorker2
PU
IOW2
LogicalFunctionType
IOW1
LogicalFunctionType
W1
LogicalFunctionType
IOW2
relating counterpart
instantiation
/ department of computer science
17-7-2015
PAGE 21
AppMap alternative 2A
• AppMap as separate diagram containing TG’s, SG’s, (IO)Workers
• Connections between their ports indicate mapping
− ServoGroup  Worker, TransducerGroup IOWorker
• One port dedicated to mapping SG’s to every Worker
• One port dedicated to mapping TG’s to every IOWorker
+ Type safety ensured through interface assignments on ports
- Indeed this approach is not intuitive, feels hacked, but a 1:1 -------- transformation is shown to be feasible
/ department of computer science
17-7-2015
PAGE 22
AppMap alternative 2B
• AppMap as logical function block
+ No dedicated ports for PU’s
• Connect only SG’s, TG’s and Workers, IOWorkers, but not their inner
HBG’s and transducer instances
• Mapping of elements done using a table
- No type safety modeling possible
/ department of computer science
17-7-2015
PAGE 23
Recap: CARM.Application in
PREEvision.LogicalArchitecture
• Application (PGAPP) consists of SG’s and TG’s, modeled as
diagram in Logical Architecture
• ServoGroups (PGSG) modeled as BuildingBlockTypes
• TransducerGroups (DVTG) consist of devices, modeled as
BuildingBlockTypes
• PGWB blocks and devices are modeled as LogicalFunctionTypes,
stored in PREEvision library
• How well can we model CARM application in PREEvision?
-
+
?
CARM port data types difficult to deduce – info not in model
CARM block parameters have no intuitive PREEvision equivalent
Transformation for most concepts intuitive
User-defined datatypes
/ department of computer science
17-7-2015
PAGE 24
Recap: CARM.LogicalPlatform in
PREEvision
• Despite the Logical Platform’s small size, a suitable way of
constructing a perfectly similar model in PREEvision is hard
• There are no built-in concepts differentiating Worker and IOWorker
• Strong typing of properties mostly lost
• Two alternatives:
1. Model in Hardware Architecture
+ can use built-in mapping mechanism
- no type safety, not flexible
2. Model in Logical Architecture
+ type safety through ports, flexibility
- mapping is difficult due to inability to use built-in mechanisms
- intuitivity/hacks; ports used for multiple purposes
/ department of computer science
17-7-2015
PAGE 25
Project goals
Ecore
CARM 2G
metamodel
LCW_TC.carm2g
Temp. ctrl
(2) Determine
ontological
commitment of EASTADL to CARM domain
(1) Relate CARM 2G
architecture & concepts
to EAST-ADL
Meta-meta model
EAST-ADL
metamodel
LCW_TC.eastadl
Meta model
Model
LCW Temperature
controller
17-7-2015
PAGE 26
Expressivity and domains
TWINSCAN
domain
?
EASTADL
EAST-ADL
EAST-ADL
CARM 2G
17-7-2015
PAGE 27
Ontological commitment
• Determine ontological commitment of EAST-ADL for CARM 2G
domain
• Ontological commitment captures how well an ontology (or metamodel)
fits its problem domain
• Research/define suitable metrics
• Carry out analysis, analyze metrics
• Find deficiencies/points of improvement
/ department of computer science
17-7-2015
PAGE 28
Model transformation
• Define CARM 2G languages in terms of EAST-ADL
• Relate CARM 2G and EAST-ADL metamodels
• Using results, combined with those from (1), examine relevant model
transformations
• If feasible, implement model-to-model transformation from CARM to
PREEvision in QVTo
/ department of computer science
17-7-2015
PAGE 29
Future work
• What’s next?
• Finalize transformation details of
− Application
− Logical platform
− Appmap
• Model CARM Physical Platform in PREEvision
• Research ontological commitment
− Express ontological commitment of PREEvision for CARM domain
• Implement model-to-model transformation in QVTo
/ department of computer science
17-7-2015
PAGE 30