Artemis-AAL day 7 May , Budapest

1. Guaranteed Component Assembly with Round Trip Analysis for Energy Efficient High-integrity Multi-core Systems Artemis-AALday 7May, Budapest

2. CONCERTO A direct continuation of the CHESS project furtherenhance MDE based design and analysistechniuesformultipledomains Partners: Presentation Title and/or Meeting Reference

3. Whatdomainsareweaiming? • Original CHESS domains mainlysafetycritical • Telecom • Ethernet Microwavesystem • AeroSpace • Avionics – AIRBUS casestudy • Space – ATRIUM satelite • Automotive • AUTOSAR • New domains wouldbenefitfromverification • Petroleum • Safety/Risk management system • Medical • Telecare Presentation Title and/or Meeting Reference

4. Building Upon CHESS Achievements • Definition of a Multi-Concern Component Methodology and Toolset • Provide a Multi-Concern Component Modeling Language and a Graphical Modelling Environment that fits multiple industrial domains • Enable the specification of extra-functional properties of software components • Integrate tools for the verification of extra-functional properties • Preserve verified properties at run time • Adaptation of standards and open sources • OMG modeling languages • Eclipse Environment CONCERTO Project Overview

5. The CHESS approach • Model-driven engineering • Models as the central development artifacts • Tool assisted automated development • Component based development • Specialized to capture the extra-functional requirements of components • Extra-functional properties of interest • Real Time • Dependability and Safety CONCERTO Project Overview

6. Initial vision: MDA with separation of concerns and back-propagation 1. You construct a PIM to represent your solution to your problem, independent of any specific implementation 2. You complement the PIM with information on the target platform and the deployment plan Platform description PIM Deployment information Design space 3. The design environment generates a PSM automatically via model transformation Implementation / analysis space PSM The PSM is read-only! - This assures the relative consistency of PIM and PSM - And it shifts the responsibility of correctness from the designer to the transformation designer 4. A back-end tool extracts information from the PSM to feed specialized analysis tools (schedulability, dependability, etc…) Analysis tool 5. The back-end tool reports the analysis results back on to the PSM and attaches them to the corresponding entities in the PIM 6. You change entities’ attributes in the PIM as needed and iterate the analysis until the system is satisfactory in all the functional and extra-functional dimensions of interest CONCERTO Project Overview

7. CONCERTO Advancements and Objectives Presentation Title and/or Meeting Reference

8. A Methodology defines Design space Modelinglanguage MARTE SysML Model validation User model Component model UML CONCERTO Profile • Analysis view • Domain – specificviews • Analysis view Deployment view B Analysis tools E Model Transformation Back-propagation PIM HW DescriptionResources, #nodes, #cores, … Model Transformation Model Transformation Read-only PSM source code parsing Code generation Implementationspace C Property – preserving Implementation monitoring executes on Executionenvironment D Executionplatforms Functionalview Extra-functional

9. Cross-domain challenges • Furthering separation of concerns enacted by design views • Enriching the component model at the center of the software architecture • Support for component hierarchies • Support for event-based integration with platform middleware • Support for modeling (and analysing) operation modes • Augmenting back-propagation capabilities from run-time observations • What run-time information is useful to capture • How to back propagate it to the user model space for model assessment CONCERTO Project Overview

10. Specialized needs • Enriching safety modeling and analysis • Support for error simulation and enrichment of behavioral models • Support for instance-level safety modeling and refinement of metamodel • Model execution • Provision of a PIM-level environment for the verification of model behavior • Bridging the gap to system level • Essential to increase take up of CONCERTO solutions in production CONCERTO Project Overview

11. Platform-specific challenges • Support for multicore targets • How should the user be aware of multicore platforms • What code to generate for multicores • What solutions for multicore scheduling and analysis • Run-time monitoring • For property preservation (enforcement) • Support for isolation via resource partitioning • Directlyonmodellevel CONCERTO Project Overview

12. Telecare Presentation Title and/or Meeting Reference

13. Overview – Telecaredemonstrator Middleware – ODroid Sensor 1 – 3rd party ANT+ Sever –Drools HL7 MQTT Sensor 2 - Android Sensor 3 – ownconstr. BT - HDP HL7 3rd party – Smarthome Sensor 4 – prop. Prop.

14. Overview – Telecaredemonstrator Commoninterfacefromsensordatatomanipulation Middleware – ODroid Sensor 1 Sensor 1 – 3rd party ANT+ Sever –Drools HL7 MQTT Sensor 2 - Android Sensor 2 Sensor 3 – ownconstr. Sensor 3 BT - HDP Data migration and conversion HL7 M2M Data Server Alarmmannen – Smarthome Sensor 4 Sensor 4 – prop. Prop. Prop.

15. Ourgoals • First steps to a round-trip model based design and analysis approach for telecare • Availablity/Timing analysis • WCRT execution time estimation  MAST • Safety-barrieranalysis • Back-annotation using query-driven traceability • Allocation and reconfiguration of components run-time reallocation of tasks • Domain Specific Language for the telecare domain • Direct code and configuration generation • CONCERTO Tooling • Workflow based transformation chains