This paper presents a ThingML implementation of the MDETools'18 challenge. ThingML is a textual modeling language that implements a sub-set of the UML (components and state-machines) and complements it with a rst-class action language. ThingML also comes with a set of compilers targeting a large variety of platforms and programming languages. Using ThingML, we have been able to 1) fully model the MDETools'18 challenge, 2) automatically compile this speci cation it to two distinct programming languages, and 3) successfully execute the resulting programs and achieve reasonable results in the simulation.
⋆ The research leading to these results has received funding from the European Commission's H2020 programme under grant agreement no 780351 (ENACT). 1 https://github.com/SINTEF-9012/mdetools18-challenge-thingml
The remainder of this paper is organized as follows. Section 2 details how the challenge is modeled in ThingML. Section 3 presents how the platformindependent speci cations from Section 2 can be specialized and compiled to di erent platforms. Section 4 concludes and discusses the strengths and weaknesses of ThingML when implementing this challenge. 2
Modeling the MDETools'18 Challenge with ThingML The simulated environment of the posed challenge exposes two TCP ports for the external application (challenge solution) to 1) poll for the current state of the environment, and 2) send control signals to the follower rover. Not depicted in the gure, is a le containing parameters which describe both how the leader rover moves, the target distance for the follower rover, and the endpoints of the TCP ports.
The proposed solution to the problem, is an application consisting of: a) A settings parser, b) Communication with the simulator, c) State estimation, d) A control system, and e) A timer. Figure 1 shows how these parts are connected and interact with the simulated environment. A more detailed view into the actual components composing the application is given in Figure 3. The following sections will detail each part. The settings parser is implemented with a single component. It reads the lineformatted le of parameters, parses them into suitable ThingML datatypes and when the whole le is read, sends a message out to the listening components containing the parsed parameters. In the proposed solution, the following parameters are used: { simulationIP, controlPort, observationPort: for the communication part that needs to open TCP sockets to the simulator. { minDistance, maxDistance: for the control system to calculate the target distance. { runTime: for the control system to know when it is done and apply the brakes. 2.2
This part of the application is implemented with three components. There are two instances of a generic line-based TCP socket that 1) forwards ThingML messages containing a single string to the simulator as lines, and 2) reads lines coming from the simulator and sends them out as ThingML messages. The third component implements the communication protocol of the simulator, acting as the ThingML proxy to the simulator. It implements the parsing and formatting of strings and the ThingML messages shown in Listing 1.1, and uses two regions to handle the communication with both the leader and follower rovers concurrently, shown in Figure 2. message SetRoverLRPower(left : Integer, right : Integer) message SetBrake(brake : Integer) message GetRoverPosition() message GetRoverCompass() message RoverPosition(x : Double, y : Double) message RoverCompass(phi : Double) 2.3
The simulated environment only provides the position of the leader and follower, the heading of the follower, and the distance between the leader and follower rovers. To implement a decent control system, derivatives of these quantities are also needed. This part therefore contains two components that estimate the rst and second order derivatives, using a nite di erence scheme with 2nd order accuracy, one for each of the rovers. At a xed time interval each estimator requests the current position of its assigned rover. When the response arrives, the last three position values are used to estimate the derivatives.
A third component bu ers the received state estimates from each of the rover estimators, and calculates values that are passed on to the control system: 1. The angle from the follower to the leader, the heading. 2. The distance between the leader and follower. 3. The speed of the leader. 4. The speed of the rover, projected onto the speed of the leader. This is used to prevent the follower from going full in the wrong direction. 2.4
The control system consists of three components responsible for controlling different aspects of the system, and a fourth component for coordinating and composing the nal inputs to the follower rover. The implemented control components are: 1. Distance controller. A P-controller that tries to keep the follower at a distance of (minDistance + maxDistance)~2 from the leader. 2. Heading controller. A P-controller that tries to point the follower directly towards the leader. 3. Speed controller. A PI-controller with anti-windup, that tries to match the projected speed of the follower with the speed of the leader.
These control systems receive state estimates from the estimation component, and bu er the last received values. At a con gurable time interval the control multiplexer component sends a message to the rst controller with (0; 0) as the inputs for the left and right wheels of the follower. Each of the controllers add their own control input on top of the received input, and pass it on to the next controller, and nally back to the control multiplexer. When the control multiplexer gets the combined input from all the controllers back, it scales the values to make sure it is within the allowed range of [−100; 100], and sends it to the communication component to be passed to the simulated environment. The timer is a single component that receives requests to start a countdown for a speci c ID, and when the countdown has elapsed sends a noti cation to all listening components with the corresponding ID. Although the component is very simple, it is essential since the rest of system operates asynchronously without any notion of time.
Generating and Executing Code for Two Languages ThingML comes with a rich platform-independent action language, and compilers targeting C (for microcontrollers and Linux), Java, JavaScript (Node.JS and Browser) and Go. This means that generating complete and executable code for multiple platforms, in many cases, comes at no extra cost to the developer. However, as very specialized functionality (like ad hoc communication protocols) are not included in the ThingML modeling language, some situations require platform speci c models. There are three ways to accomplish this using ThingML: 1. Using plug-ins that come bundled with the ThingML compilers. These plugins are specialized for each target language, and generate code for exchanging ThingML messages across network protocols (such as MQTT and WebSockets) with other ThingML or legacy applications. 2. Using standard libraries that come bundled with ThingML. These libraries provide commonly used functions (e.g. mathematical functions or string formatting and parsing) as both platform independent abstract declarations, and platform speci c concrete implementations. 3. Manually mix in platform speci c code using the \kick-down" mechanism, or applying compiler speci c options using annotations.
To demonstrate how platform independent and platform speci c models are speci ed and mixed in ThingML, the proposed solution was implemented with models to generate code for both Java and Go. The nal models consist of mainly platform independent components, while the following parts of the ThingML model is implemented in a platform speci c way: a) Mathematical functions, b) String formatting and parsing, c) The timer component, d) Line-based messaging over TCP, and e) Reading the con guration le line-by-line.
The following sections rst demonstrate how platform independent and speci c models may be combined by showing the ThingML implementation of the con guration le parser, then compare the implementation of the proposed solution using the two languages. 3.1
The settings parser component is responsible for converting a specially formatted le of parameters to ThingML datatypes, and notifying listening components about their values. Reading les and parsing strings are not functionalities that is supported in the ThingML action language directly, so this component requires platform speci c implementations using the mechanisms provided by ThingML.
Listing 1.2 shows the platform independent partial (indicated by fragment) implementation of the component. This model de nes the relatively simple behavior of the component. Once started, the ReadConfigFile function is called, which again is supposed to call HandleLine for each line in the le, and after all lines are read, the parsed parameters are sent out over the Loaded port.
The model uses two ways of de ning platform independent behavior without the platform speci c implementation. The ReadConfigFile function is declared as an abstract function, leaving all the details up to the nal implementation of the component. The HandleLine function calls abstract functions declared in the platform independent String component from the ThingML Strings library, shown in Listing 1.4. To implement these functions, one may simply include the appropriate *Strings component from the library. statechart Loader init LoadConfiguration { state LoadConfiguration { on entry do
ReadConfigFile(ConfigPath)
Loaded!Settings(controlPort, ...) end } }
The nal implementation of the settings parser component for Java is shown in Listing 1.3. It includes the JavaStrings component from the Strings library that implements the abstract functions for Java (wrapping methods from the Java String class in a straightforward manner), while the ReadConfigFile is manually implemented with Java-code using the \kick-down" mechanism. The java import annotation instructs the ThingML Java compiler to include these additional imports at the top of the generated Java source les. To evaluate the performance of the proposed solution, and to ensure that the generated code for both Java and Go perform equally well and consistently, an experiment was conducted. The experiment consists of ve scenarios corresponding to ve randomly generated leader rover paths. For each scenario, both the generated Java and Go controllers were executed during ve runs alongside the simulated environment. The resulting power input to the follower rover and the distance between the leader and follower rover were recorded over time, as well as the nal percentage of time in the zone.
Table 1 shows the nal percentage of time in the zone for all runs of the experiment. Overall, the performance of the two languages are similar for each scenario, and quite consistent across the runs within each scenario. For a couple of runs, the Go controller performed signi cantly worse than the other runs of the same scenario (highlighted with gray cells). The reason for this is still unclear, but since it does not seem to happen for the Java, it might be a manifestation of a bug in the ThingML Go compiler, which warrants further investigation.
Figure 4 provides a more detailed view of the execution of the controllers for both Java and Go. It shows the power input to the follower rover and the distance between leader and follower rover over time for the two controllers, for randomly selected runs in a randomly selected scenario. In general, the two controllers produce quite similar input, and perform equally well. The slight di erences are likely caused by timing di erences (since the setup is not a hard real-time system), and potential oating point number inaccuracies. The jaggedness of the power input is probably a result of the sampling of position of the rovers from the simulated environment, either that the sampling rate is too high, the sampling time being non-uniform, or the low-order nite di erentiation scheme implemented. As the controllers performed satisfactory, this issue has not been further investigated.
100 50 0 −50 100 50 0 −50
In this work, we have proposed a solution to the MDETools'18 Challenge problem using the ThingML modeling language and accompanying tools. Leveraging the ThingML language and tools, we were able to generate executable code in two languages (Java and Go) that in our experiments produced similar and reasonably good results.
The resulting ThingML models for both languages consist of 767 lines of platform-independent code, and 71 (8%) and 88 (10%) lines of platform speci c code for Java and Go respectively. In addition, 157 lines of code for new libraries has been written for the two languages that is to be contributed to the ThingML standard libraries.
This small amount of platform speci c code, substantiates the claim that the ThingML modeling language is useful in practical applications, such as the posed challenge. Coupled with the wide range of platforms targeted by the ThingML compilers, it also means that generating code for suitable targets comes at little extra cost to the developer.
In terms of the control system implemented in the proposed solution of this work, the performance is far from optimal. However, as ThingML o ers no speci c support for control systems, the authors consider this as outside the main scope of this challenge, and leave further improvements for future work. Such improvements (such as limiting the rate of change of applied power to void wheel-spin) could with ease be implemented with platform independent models. Extending the proposed solution to other languages (e.g. C and JavaScript) is also reserved for future work.
During the work with solving the posed challenge, some bugs and shortcomings of the ThingML modeling language and tools was discovered, despite the already strong test suite in place for the compilers. Most have already been xed and contributed to the o cial ThingML repository, while some (particularly related to the inconsistent behavior of the Go controller) requires further investigation, and will de nitely be dealt with by the ThingML developers. As such, the posed challenge has both been a good exercise to assure the practicality of ThingML, as well as providing substantial input for the future development.