This paper is an experience report on how we conducted research in run-time model monitoring with Open Source Software (OSS) and low-cost hardware. We demonstrate our experience using a Rover system case study, where we modelled its control logic, generated code, and collected traces of the running code to visually monitor the execution. We used open source tools throughout the project: Papyrus-RT for modeling and animation, LTTng for collecting execution traces, and Trace Compass for parsing the collected traces.
Page 37
Despite the acceptance of MDE by the community, it is noteworthy that
companies mostly use commercial and proprietary tools [
This paper details an experience report using and extending Open Source Software (OSS) and self-made, low-cost hardware in the context of an industrial research project on run-time model monitoring. It encourages and promotes the use of open source software and hardware for building real industrial case studies.
The rest of this paper is structured as follows: Section 2 gives an overview on the use of open source modelling solutions in the context of real-time embedded system design; Section 3 gives an overview of the research we conducted on runtime model monitoring; Section ?? details the modelling and the assembly of an industrial case study, the Rover model, using open source solutions only, and the lessons we learned; Section 6 discusses other works based on open source for real-time embedded system design; Section 7 concludes. 2
Using open source tools and platforms in the context of Model Driven
Engineering (MDE) projects becomes critical. MDE tools developed by single companies
cannot satisfy the very diverse and sometimes even con icting expectations and
requirements of the industrial and academic communities. Further, dependency
on proprietary tooling platforms can limit the innovation in companies.
Papyrus [
In addition to OSS, Open-Source Hardware (OSH) [
Examples of such inexpensive platforms are Raspberry Pi [
In the following, we show how we took advantage of OSS and OSH to build a prototype for monitoring the execution of real-time embedded systems. 3
Nowadays, determining and evaluating the run-time behaviour and performance of models of embedded systems using commercial MDE tools is a challenging task. Such tools provide little support to observe, at model-level, the execution of the code generated from the model, and to collect the run-time information necessary to, e.g., check whether timing constraints are met or not.
To address this issue, we proposed an approach to modelling and to
monitoring real-time embedded systems at run-time [
As illustrated in Fig. 1, the entire approach relies on the integration of OSS and open source standards. LTTng produces Common Trace Format (CTF) les, which are sent to Trace Compass for trace analysis. Trace Compass is a framework which provides views and graphs to depict extracted information from the produced traces. This shows an example of successful collaborations enabling the use of open source solutions for run-time model monitoring. Our monitoring framework consists of several Papyrus-RT plugins, which were appealing to our industry partners and we will soon merge them into the main source code repository of Papyrus-RT. In the following, we detail our experience and lessons learned during this project. This section is an experience report on the use of open source software and platforms to conduct research in the context of MDE. It is divided up into four parts. The rst part introduces a running example, the Rover system case study, we modelled and assembled in order to perform run-time model monitoring; the second part presents the rationals behind the modelling of this system; the third part describes the assembly of the Rover platform using low-cost hardware; the last part draws the conclusions and presents the lessons learned. The rover is a small vehicle driven by two motors to move forward and backwards, as well as to rotate. It embeds a set of sensors to detect obstacles and to collect data from the environment (temperature and humidity). The main processing element is a Raspberry Pi platform running a real-time version of Linux, where the generated code from the UML-RT models is deployed and executed.
The behavior of the Rover system is the following. In the initial state, it moves forward until an obstacle is detected. To avoid the obstacle, it turns 90 degrees, and then starts again moving forward. During all the execution, temperature and humidity information are collected from the environment. The behavior of the Rover has been modelled in UML-RT using Papyrus-RT. The UML-RT model is composed of inter-connected capsules, ports, and protocols to model the structure of the system, and statemachines encapsulated in each capsule to model its behavior.
The whole architecture of the Rover system consists of ve layers of
abstractions (see Fig. 2). From the bottom, the Hardware layer corresponds to the
Raspberry Pi, which embeds 26 GPIO pins, among them 17 are used to
connect external devices (sensors and actuators). The File System layer is the le
system powered by a real-time version of Linux. Each GPIO pin in the
Raspberry Pi corresponds to a le in the le system. The user can interact with a
pin by reading the les value or writing into the le. The GPIO layer is a C++
wrapper class to ease the mentioned le accesses for controlling GPIO pins. The
wrapper constitutes a GPIOClass, which includes methods to set and get the
values of pins, set the direction of GPIO pins (make them as in or out) as well as
clearing the value of pins [
Assembling the Rover Platform Choosing the right components for assembling the physical platform is an important step. It depends on several requirements including processor speed, memory, and interfaces used to connect digital and analog devices. For the Rover system, we considered two potential candidates: Arduino UNO and Raspberry Pi.
Arduino UNO is a micro-controller, which can be easily connected to sensors and actuators. For our scenario, one advantage of Arduino over Raspberry Pi was the support for Pulse Width Modulation (PWM), which allows for connecting analog devices. This is particularly useful for controlling the speed of the motors, which would allow the rover to make more gradual turns. However, Arduino UNO does not support Linux, which it was a requirement in our project as it has to support the Papyrus-RT RunTime Service (RTS) library which is only developed for Linux environments. For this reason, and despite its lack of support for analog devices, we chose to use a Raspberry Pi 3.
Fig. 3 illustrates the assembly of the Rover platform. The core component is the Raspberry Pi 3 platform (component A). It embeds two steps motors (which are electrical motors that convert electrical pulses into mechanical shaft rotations) attached to wheels (components D), whose the control is ensured by a motor controller (component E) connected to the Raspberry Pi. An ultrasonic distance sensor (component G) is used to measure the distance with obstacles and a breadboard is used to connect the di erent components. Finally, two sets of batteries (component B and F) are used to power both the Raspberry Pi and the two motors, a voltage regulator (component C) ensures the Raspberry Pi is 1 All developed source codes and models could be found in https://github.com/ reza-ahmadi/rover getting the 5 volts it needs to be powered on. Regarding the time investments for the project, the hardware took about 5 hours to assemble.
The rationale behind our multilayered architecture is to facilitate modularity and as a result maintainability in the future. For instance, the GPIO library is there to abstract away le operations needed to interact with GPIO pins through the le system. It is speci c to GPIO pins but it is much easier to modify the GPIO library than it is to modify every occurrence of a le operation in the Rover library. 5
During our project we gained valuable insights into using open source MDE
tools and low-cost hardware. To build our demonstrator, we spent just less than
$50 for all components of the rover (mentioned before), which could show the
possibility of MDE research using low-cost hardware. Due to an active
community and available online resources we could nd answers to our many questions.
In particular we found Bran Selic's papers [
There are some other ongoing research projects with a focus on MDE research
with low cost hardware, such as PolarSys rover [
There are prior work done in the area of model monitoring and animation. For
instance, Moka is a Papyrus module which integrates with Eclipse and enables
model animation and debugging [
Pesu et al. [
In this work, we assembled a rover using inexpensive hardware components to
conduct MDE research in the context of an approach for run-time model
monitoring for Papyrus-RT models we formalized in a previous project [
We envision that our work could be leveraged in some ways. We think we can add symbolic execution to our system to generate test inputs and use the test inputs to exercise the model and ultimately uncover various violation of properties. Another extension point would be to add a methodology to our run-time monitoring to validate model changes such as certain kind of model re nements.
Some other future work would be to support model-level debugging and animation using 3D/2D environments such as Unity. The former is to support adding breakpoints on the model level, watching values, and transition between the generated code and model. The latter one allows a two-way interaction with the model, so to not only watch the model in the animation, but also triggering rover movements while watching the animation.