The future of CPSoS: Bridging the gap between Model Driven Engineering and Parallel Programming Models

The future of CPSoS: Bridging the gap between Model Driven Engineering and Parallel Programming Models
Sara Royuela (BSC)

AMPERE aims at developing a new generation of programming environments for low energy and highly parallel computing, capable of implementing correct-by-construction Cyber-Physical Systems of Systems (CPSoS). To that end, the consortium has considered three different layers:

  • Model-Driven Engineering (MDE) techniques are typically used in automotive and railway industries to design software because they allow abstracting the complexities of the SW and HW while providing early verification and validation capabilities.
  • Code synthesis tools and compilers are the tools that, based on the system description, have to implement a holistic optimization approach to generate parallel code that still fulfills the non-functional requirements expressed at design-time, and is optimized for the target architecture, either heterogeneous platforms or FPGA-based accelerators.
  • The runtime system, as well as the OS and hypervisor, are in charge of keeping, at execution time, all the requirements of the system.


Figure 1. AMPERE software components.
Figure 1. AMPERE software components

The coupling of MDE approaches and parallel systems entails an interesting challenge. On one hand, Domain Specific Modelling Languages used in MDE, like AMALTHEA [1] and CAPELLA [2], do not support the parallelism expressed by high-level parallel programming models like OpenMP [3] and CUDA [4]. On the other hand, those parallel programming models do not provide features to capture the non-functional requirements of the CPS (e.g., energy, time, and fault tolerance constraints).

In order to provide model transformation and parallel programming model support to express functional and non-functional requirements, AMPERE has started analyzing the compatibility between AMALTHEA and OpenMP. These two components are described next:

  • AMALTHEA is an open-source platform, by Bosch and their partners, for engineering embedded multi- and many-core systems proven in the automotive sector. The system model provided in AMALTHEA allows defining: (1) the functionalities implemented in the system, i.e., runnables, (in terms of execution time, memory access, etc.), and the units of work, i.e., tasks, (in terms of activations, and activity graphs, etc.); (2) the elements of the hardware platform (e.g., processors, memories, etc.); and (3) the mapping between the software and the hardware elements (i.e., schedulers, work mapping, etc.).
  • OpenMP is a parallel programming model that has become the de-facto standard for exploiting shared-memory systems. It provides a high-level API that allows data- and task-parallelism, as well as support for accelerator devices, that has proven programmability and performance capabilities. As a result, it is a portable platform implemented by many chip and compiler vendors. Furthermore, several extensions have already been proposed to include support for non-functional requirements like safety, resiliency, time, and energy.

Table 1 shows the envisioned relationship between the different aspects exposed in AMALTHEA, and the features available in OpenMP.


Table 1. Compatibility between components in AMALTHEA and OpenMP
Table 1. Compatibility between components in AMALTHEA and OpenMP


Most of the features needed to express with AMALTHEA the fine grained parallelism exposed with OpenMP are already part of the model. However, many of these features are solely used for analysis purposes. The code synthesis tools used to transform the DSML into actual C code do not consider these aspects. AMPERE is currently working on the extension of the AMALTHEA code synthesis tool to enrich the transformed code with annotations that describe the parallel behavior of runnables (e.g., data inputs and outputs in a runnable, device type, etc.) as well as information about non-functional requirements (e.g., energy consumption, time-related properties, etc.). This information will be later used by the compiler and the analysis tools to implement a holistic approach to generate (sub)optimal code considering performance, energy, time and resiliency.