The development of complex cyber-physical systems relies heavily on elaborate domain specific languages, agile processes, and tools. A quasi-standard in multiple engineering domains is Simulink, a component & connector modeling tool by MathWorks. In this paper we present a versatile integrated development environment for EmbeddedMontiArc, a textual alternative for component & connector modeling. In order to deliver an agile and test-driven modeling experience, we integrate the complete tool-chain including code generators, compilers, as well as a variety of target runtime environments such as simulators behind a single user interface facilitating the creation, execution, and validation of cyber-physical system models.
EmbeddedMontiArc is a Component & Connector (C&C) modeling
language family developed with an emphasis on the needs of the
embedded and cyber-physical systems domain [
EmbeddedMontiArc provides an elaborate tool-chain
transforming the original user-defined model to an executable binary. Its
main steps include a parser, code generators for a series of target
languages such as C++ and WebAssembly as well as compilation
and linking [
EMAS bundles all the features of EmbeddedMontiArc to a portable Windows 10 64-bit application or a Ubuntu 16.04 64-bit virtual machine enabling us to use EmbeddedMontiArc and its tool collection out-of-the-box. EMAS is publicly available under: http://www.se-rwth.de/materials/embeddedmontiarc/
Similar to Simulink the main purpose of EmbeddedMontiArc is C&C modeling for embedded and/or cyber-physical systems. In contrast to Simulink, which is a graphical modeling language and stores multiple components (subsystems) in the same file, EmbeddedMontiArc is a textual modeling language family that, similar to Java classes, stores each component in its own file. Compared to graphical modeling, the textual modeling concept of EmbeddedMontiArc exhibits multiple advantages:
(1) All model information is directly available in files, and can be found and replaced by standard text programs. In graphical modeling tools such as Simulink, Enterprise Architect, or PTC Integrity Modeler this information is hidden behind a multitude of tabs or dialog boxes and often stored in proprietary binary formats. Integrated search speed for large models is slow.
(2) Text-based versioning tools like SVN and git featuring model diferencing as well as merging and branching can be used out-ofthe-box. Graphical tools allow one to export their graph structure as XML files, but reading an XML diference is hard since links between graphical elements are represented as links between unique identifiers.
(3) In large projects where multiple teams work together on the same model but on diferent files or even folders according to their responsibilities, EmbeddedMontiArc follows the separation of artifacts principle to enable modeling in the large. Having diferent ifles for diferent components enables a better integration into version control software since single components can be merged or reverted independently.
(4) Test driven development increases the code quality dramatically. EmbeddedMontiArc has an easy to use first level integration of unit tests for components whereas Simulink uses a graphical testing framework based on the signal builder. In Simulink executing multiple unit tests for one component is achieved by copying the signal builder and the component under test several times.
(5) In agile development, software is often updated to better ift customer needs. But updating large graphical models (e.g. inserting and reconnecting components) is very time consuming as the existing graphical layout needs to be rearranged manually. In EmbeddedMontiArc the graphical layout is generated automatically based on the textual files, serving a better understanding of the C&C architecture. This way, the modeler can focus on the main task by only adding, changing, or removing textual lines.
Figure 1 shows screenshots of the six main features of EmbeddedMontiArc: ○ A An interactive IDE with syntax highlighting, outline and parse error messages. The IDE support for all the languages of the EmbeddedMontiArc language family is automatically generated using the MontiCore framework.
○ B A quality report for all EmbeddedMontiArc models. The tool shows all parse, resolve, and testing errors with its console output; it is a continuous integration/deployment CI/CD front-end for our modeling family. The tool can also be used stand-alone (without EMAS) on a CI/CD server (e.g., travis-ci or gitlab runners) to perform model-based regression tests.
○ C The simplest simulator of EmbeddedMontiArc is the image clusterer; it allows one to select pictures and converts them into a third order tensor object (the first two tensor degrees represent the height and the width of the image, respectively, while the third degree contains the color channels red, green, and blue) which is passed to the C&C model; finally, the simulator converts the resulting 2d matrix of the C&C model back to a gray-scale image.
○ D The visualization generator produces a graphical representation of the textual EmbeddedMontiArc models as HTML and SVG ifles. A special feature of this generator is to produce graphical models with diferent abstraction levels, e.g. only showing the connected components but no ports up to drawing the complete model including all ports with their respective names and types. Since the layouts are computed automatically unlike in Simulink where only names or lines are hidden, the abstract graphical visualization is much smaller than the complete one and thus well suited to obtain an overview of large C&C models.
○ E The car simulator [
○ F The image classifier simulator works similarly to the image clusterer. It allows to drag (or to select your own) pictures into the analyze zone (white box) and then analyzes the content in the images and returns a predicted class (such as dog, cat, truck, and so on). The image classifier is a trained CNN (Convolutional Neural Network) component where the test images of the simulator are of course diferent from the training data.
All three simulators ○ C , ○ E , and ○ F have in common that a C++ compiler toolchain translates the textual EMA models to native code (dynamically linked libraries or standalone executables) before the respective simulator can execute the model. A feature of the toolchain is that it includes the highly optimized Armadillo mathematics framework guaranteeing an eficient model execution of computationally intensive software. This enables the simulation of diferent cars at the same time and on the same laptop, the execution of expensive algebraic algorithms in our image clustering example, as well as the classification of images at nearly real-time on standard customer hardware. Fast simulation results are a key to keep students motivated to test their models and thus improve them continually. For instance, our vehicle visualization works at 30 fps, image classification is executed without a noticeable delay. 3
EMBEDDEDMONTIARC MODEL EXAMPLES Figure 2 presents code snippets used in three of our executable model examples: the Autopilot ○ E model snippet ○ 1 belongs to the Autopilot model. This component checks whether the car is still in the track. This component has two input ports (ll. 2-3) for the car position relatively to the track accepting values between -200 meters and +200 meters, and one Boolean output port (l. 4) returning true when the car is outside the track boundaries. The implementation part of the atomic component (ll. 5-8) contains code defining how sensor inputs are mapped onto a Boolean output.
Testing: ○ 2 is a blackbox unit test based on the stream
semantics. The concept is very similar to JUnit. A stream test operates
EmbeddedMontiArc (Tool Demonstration)
9 stream StatusControllerTest for StatusController {
10 x: 0m tick 200m tick -200m tick 250m;
11 y: 0m tick 120m tick -50m tick 50m;
12 status: false tick false tick false tick true; }
1 component CheckTrackBoundaries { ① 31 component SpectralClusterer {
2 ports in Q(-200m:200m) x, 32 ports in Q(-oo:oo)^{50,50} img[
③
21 component NormalizedLaplacian {
22 ports in diag Q^{2500,2500} degree,
23 in Q^{2500,2500} W,
24 out Q^{2500,2500} nLaplacian;
25 implementation Math{
26 nLaplacian = degree^-0.5*W*
27 degree^-0.5; }}
④
value matrix
range dimensions
Q(0:255)^{50,50}[
U
array size EigenSolver
matrix eigenvectors img ...
Similarity similarity degree
KmeansClustering vectors cluster
SpectralClusterer
W D
Q^{2500,2500} NormalizedLaplacian nLaplacian degree
similarity cluster id of each pixel cluster
C&C ⑥ D W on exactly one component specified after the for key word (l. 9).
Of course, multiple stream tests can exist for each component. The ifrst lines (ll. 10-11) provide the values for the input ports of the components while the last line (l. 12) specifies the expected values of the output port. The stream language also supports underspecification, e.g. by defining ranges for output values. If the component is executed and the calculated output values satisfy the expected values of the stream, then the test will be considered as pass.
Deep Learning Classifier ○ F : In ○ 3 a component using an alternative implemention language, namely CNNArch is presented. It supports a compact description of layered artificial neural networks which become more and more ubiquitous in intelligent software systems. The CNN model describes the layers of the network as well as their interconnections. A generator then generates the target network architecture, trains the network on a given labeled data set and encapsulates the software in a standard EmbeddedMontiArc component. Using a simulator similar to the clusterer users can check the quality of the classification on their own images.
SpectralCluster ○ C : the model snippets ○ 4 and ○ 5 belong to the spectral clusterer model, which can be used to detect objects in a picture. Since EmbeddedMontiArc is a textual modeling language the developer writes down the model shown in ○ 5 , which is semantically equivalent to the C&C model displayed in ○ 6 . The SpectralCluster component is decomposed into four subcomponents (ll. 35-38). The information between these four subcomponents is exchanged via unidirectional connectors (ll. 40-45). Model ○ 4 shows the implementation of the subcomponent normalizedLaplacian (l. 36) having the type NormalizedLaplacian. Lines 26 and 27 show that the implementation part of EmbeddedMontiArc models support normal matrix-vector expressions similar to MATLAB code.