1 / 31

Relating CARM 2G DSLs and EAST-ADL Midterm presentation

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. Domain: process control.

dora-aguilar
Download Presentation

Relating CARM 2G DSLs and EAST-ADL Midterm presentation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Relating CARM 2G DSLsand EAST-ADLMidterm presentation CSE graduation project at ASML Frank Razenberg Supervisor: Ramon Schiffelers Coach: Yanja Dajsuren

  2. Outline • Project overview • Domains • Process control & CARM 2G • EAST-ADL • Goals • Approach • Future work / department of computer science

  3. 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

  4. Modeling the control application: application model • CARM 2G: ASML’s multi-disciplinary model-based development environment • Application model • TransducerGroupsdescribe a set of sensors or actuators • Describes mechanical and electrical transducers • ServoGroupsdescribe a controller • Calculations made using logical blocks / department of computer science

  5. Available execution platform • Physical platformrepresents available hardware • IOBoards; sensors and actuators • HPPCs; processors • Communication network (RIO, HSSL, switches) / department of computer science

  6. Mapping application to platform Sensor Control task Control task Actuator Control application Sensor Control task Control task Control task Actuator Control task Sensor Mapping Processor Processor Core 1 Core 5 Core 2 Core 6 Execution platform Core 3 Core 7 Core 4 Core 8 Communication network IOBoard IOBoard / department of computer science

  7. CARM language stack Application Conforms to PGAPP PGSG PGWB Application AppMap Transducer Logical platform Application Mapping Mapping Platform mapping Logical Platform Platform Mapping Platform Physical Platform Physical platform / department of computer science CARM Model

  8. 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

  9. EAST-ADL architecture EAST-ADL PREEvision • features observed from the outside • abstract functionality of components • concrete functions, allocations to hardware

  10. EAST-ADL architecture EAST-ADL PREEvision

  11. Meta-meta model EAST-ADL metamodel CARM 2G metamodel LCW Temperature controller LCW_TC.carm2g Temp. ctrl LCW_TC.east-adl Ecore Project goals Meta model Model (2) Determine ontological commitment of EAST-ADL to CARM domain (1) Relate CARM 2G architecture & concepts to EAST-ADL

  12. High-level mapping CARMPREEvision Product Goals Application Logical Function Arch AppMap Software Arch Logical platform Hardware Arch Platform mapping Physical platform Geometrical topology CARM Model / department of computer science

  13. 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

  14. Application in PREEvision LA System Diagram App SG inst. : BBT SG inst. : SG SG Def SG: BuildingBlock A : PGWB A : LogicalFunc B : PGWB B : LogicalFunc LFType PGWB PGWB … relating counterpart instantiation • Application: PGAPP language • Servo groups: PGSG • Blocks: PGWB • PREEvisionLogical Architecture • LA System Diagram: connects building blocks • Building block: composition of logical functions • Logical Function type: elementary block / department of computer science

  15. Logical Platform overview / department of computer science • 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

  16. Example Logical Platform for TC / department of computer science • 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

  17. High-level mapping of CARM2G layers to PREEvision layers Product Goals Application Logical Function Arch AppMap Hardware Arch Logical platform Choosing HW architecture for logical platform enables the use of PREEvisionbuilt-in mapping mechanism, including niceties such as Traceability views, complete Mapping View Implementation level Platform mapping Physical platform / department of computer science

  18. AppMap hierarchical overview (alt. 1) LogicalFunctionArchitecture Logical System Diagram Application TG1 SG1 TG2 LA-NET:Mapping IOW1 TG1 IOW1 TG2 W1 SG1 HardwareArchitecture NetworkDiagram LogicalPlatform W1 IOW1 / department of computer science

  19. Alternative 1:Logical Platform in HW Architecture Hardware Architecture Network Diagram LogicalPlatform ECU ECU IOWorker1 ECU PU PU PU PU PU PU PU PU Worker1 PU IOWorker2 PU relating counterpart instantiation • 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 / department of computer science

  20. AppMap + 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 • Built-in mapping has elements in Logical Architecture map to Process Unit of an ECU in Hardware Architecture

  21. High-level mapping of CARM2G layers to PREEvision layers Product Goals Application Logical Function Arch AppMap Hardware Arch Logical platform Implementation level Platform mapping Physical platform / department of computer science CARM Model

  22. Alternative 2:Logical Platform in Logical Architecture LogicalPlatform LogicalArchitecture System Diagram IOWorker1 IOW1 PU PU Worker1 W1 PU IOWorker2 IOW2 PU LogicalFunctionType IOW1 LogicalFunctionType W1 LogicalFunctionType IOW2 relating counterpart instantiation • 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 / department of computer science

  23. AppMapalternative 2A / department of computer science • 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

  24. AppMap alternative 2B / department of computer science • 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

  25. Recap: CARM.Application in PREEvision.LogicalArchitecture / department of computer science • 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

  26. Recap: CARM.LogicalPlatform in PREEvision / department of computer science • 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: • Model in Hardware Architecture + can use built-in mapping mechanism - no type safety, not flexible • 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

  27. Meta-meta model EAST-ADL metamodel CARM 2G metamodel LCW Temperature controller LCW_TC.carm2g Temp. ctrl LCW_TC.east-adl Ecore Project goals Meta model Model (2) Determine ontological commitment of EAST-ADL to CARM domain (1) Relate CARM 2G architecture & concepts to EAST-ADL

  28. Expressivity and domains TWINSCAN domain ? EAST-ADL EAST-ADL EAST-ADL CARM 2G

  29. 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

  30. 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

  31. 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

More Related