-Executable modeling of complex embedded systems more complex the interpretation of diagnosis results. On the is essential for bug discovery and safety validation at early design other hand, it is relatively difficult to prove the equivalence stages. A relatively large number of tools enable early design between all these models because each one is defined in terms dmioadgneloisnistoaanfdormvaalildsaettitoinng.bHyo wtreavnesrf,otrhmisintrganasnfodrmaantaiolynziinngdutchees of a different language with different semantics. In summary, a semantic gap rendering diagnosis more difficult. Moreover, on we notice that the root cause of these problems is the use the way to deployment, executable models are transformed into of multiple definitions of the language semantics defined by low level executable code. Existence of this second transformation transformations towards different formalisms. similarly renders diagnosis of the deployed system more difficult, oafndcrailtsiocailncsryesatesmessv:aalidnaotniontrcivoisatls oeqfuthiveaalepnpcreoarcehlaitniotnheneceodnstetxot To solve these issues, we propose an approach based on be established between the formally analyzed model and the a single semantics definition that overcomes the equivalence executable code. In this paper, we introduce a first step towards issue and guarantees the absence of semantic gap. Transaddressing these problems with a bare-metal UML interpreter, formations that modify the semantics should be avoided to which uniquely defines the executable semantics for both design preserve the uniqueness of this definition. In fact, our solution oaunrd dinetpelropyrmeteenrt.oTfofefrascialitdaitaegtnhoesdisiaignnteorsfisacaendthvraoluidgahtiownhpicrhoctehses consists of using a unified semantics for both design and semantics is shared with diagnosis tools. The tools rely on this deployment. This unique definition has been implemented in interface to interact with (observe and control) the executing a bare-metal interpreter of models. To ensure executability of model either locally on a PC during early design phases or these models, the selected semantics should be complete and remotely on the target embedded system after deployment. We without inconsistencies. For this interpreter, we have chosen itlolutswtroateemobuerdadpepdrotaacrhgeotsn (aatr9a1ilswamay7slevaenldcrsotsmsi3n2g),sytostewmhipcohrtwede tUML [2, 3], a textual notation for a subset of UML, that connect a remote high-level simulator for interactive execution fits these requirements. This interpreter enables to execute control and exhaustive state-space exploration. software applications at a higher level of abstraction. While Index Terms-UML, Model Interpretation, Model Verification, this approach solves semantic issues, a lack of diagnosis tools Embedded Systems. appears. To fix this problem, our idea is to share the unified semantics of the language with diagnosis tools (e.g., simulator, I. INTRODUCTION debugger). A generic communication interface enables the connection of these tools to the interpreter to observe and control model execution.
Physical Systems) provides more powerful features to meet
emerging needs in numerous fields (e.g., automotive, avionics,
robotics, smart cities). With the development of IoT (Internet
of Things), they now tend to be connected and to collaborate
with other systems on networks. This increasing complexity
creates more difficulties for engineers to check and ensure
safety, or simply to avoid bugs. Not only are behaviors of these
systems more uncertain but they are also more vulnerable to
cyber attacks, due to their network connections. To prevent
the introduction of bugs during development of such systems,
there is a need to execute, simulate, and verify models.
In the industrial world, the common approach [
This common approach has two main issues. On the one hand, the semantic gap created by transformations renders
tem show that our approach is on the way towards feasibility. Our UML execution engine can be deployed on a PC (to be used during the design phase) as well as on two embedded targets: at91sam7s and stm32. To control the interpreter, a communication link has been developed to connect different diagnosis tools. For the moment, we have a simulator that enables users to observe and control the execution of the model. We illustrate this feature by computing the exhaustive state-space of the level crossing model.
approach and our main contribution: a bare-metal UML model interpreter. In Section III, we show results of our experimentations on the level crossing example. Finally, related works are discussed in Section IV and we conclude in Section V.
implemented in C language, which has the specificity to use a single definition of the semantics for both the design phase and the execution. To perceive the innovative aspect of this technique, it is important to understand the common approach used by engineers to develop software systems (Figure 1). First of all, engineers model the system using the semantics definition of dedicated modeling languages (e.g., UML, fUML, SysML). At this stage, many diagrams are typically produced to describe the system under multiple points of view. Some of them are dedicated to system execution while others are used for alternative purposes (e.g., testing, engineers understanding of the system). Diagrams required for execution are transformed into code using manual or automatic code generation. This transformation may change the semantics definition of the model and creates a semantic gap between the design model and the code. Hence, it is more difficult to identify an element of the design model in code and conversely. In parallel of this first activity, the design model is also transformed into other formalisms to be used by diagnosis tools for different purposes (e.g., simulation, exploration, formal verification). With this second transformation, a new issue appears. It is now more difficult to prove the equivalence between these models used for diagnosis and validation, and the deployed code.
Our approach (Figure 2) consists of modeling a system
using the tUML language, that offers a clear and complete
definition of a model without inconsistencies [
This interpreter solves the three main drawbacks of the common approach. Firstly, the problem of equivalence between the design model and the code has been overcome thanks to the single definition of the semantics. Secondly, the semantic gap has been removed because no transformation, which alters or changes the semantics, is used. Thirdly, this unique definition facilitates the understanding of diagnosis results in terms of design model concepts. This solution has also other advantages. It may contribute to save time during the design phase by modeling only needed points of view of the system. Like code generation, the coding step requires no effort and the risk to introduce bugs is reduced. In our approach, this goal will be addressed by simulating and deploying the model directly on the interpreter embedded on the target.
Nevertheless, the execution of a DSL like tUML, introduced
in [
implemented in C, a low level and general purpose language perfectly suited for embedded systems. The goal of this interpreter is to define a unique semantics definition that will be used for both design and deployment, and to execute models according to this semantics.
We will now give an overview of the interpreter architecture
(Figure 3) rather than a detailed description that exceeds the
scope of this article. The Interpreter class is composed of a
collection of ActiveObjects and of the user model conformant
to the tUML semantics. tUML basically corresponds to a
subset of the class, state machines, and composite structure
diagrams from UML. This last diagram defines a composite
class, called SUS (for System Under Study), which goal is
to specify the part played by each ActiveObject as well as
links between them. Every ActiveObject has a state machine
that defines its behavior, the current state of its state machine,
and the list of all fireable transitions from its current state.
It can compute fireable transitions, and fire a transition to
make its current state evolve. An ActiveObject also owns an
EventPool to store occurrences of events that it receives. The
EventPool is currently designed as a bits field, which offers
some advantages (e.g., a bounded representation of events)
and defines a particular execution semantics. This specific
semantics can be modified by using other data structures (e.g.,
FIFO) to implement different features (e.g., storage of multiple
occurrences of a given event, preservation of events reception
order). The EventPool has three principal operations: one to
signal an event, one to consume an event, and the last one
to check if an event has occurred. An ActiveObject also has
a Store where values of its attributes are stored. The Store
has only two operations: one to assign a value to an attribute,
and another to get the value of an attribute. To have a generic
representation of attributes, we used a generic pointer, which
points to the suitable value of the attribute, and an integer to
store the size of its data type. Furthermore, an ActiveObject
needs to evaluate guards on transitions of its state machine.
The class GuardEval has been designed for this purpose.
Currently this class involves Flex and Bison to parse guard
expressions, but future works will improve that evaluation
using offline preprocessing to reduce the memory footprint
and enhance execution performances. The last class is the
EffectBehavior that executes effects associated to transitions
when one of them is fired. Two kinds of effects are available
yet with the simplified version of the ABCD language [
This interpreter has been designed to be portable on different targets. At the moment, this interpreter can be executed on a PC but is also supported on two embedded targets: at91sam7s and stm32. Other targets could be easily added because we designed the interpreter to be linked with targetspecific libraries of the chosen target at build time. This specificity helps to fit embedded systems requirements, which involve limited computation and memory resources.
DSLs, we take into account the possibility to connect the interpreter with existing tools (e.g., simulator, debugger, profiler, model-checker). Our idea is to provide a generic API to be able to control remotely the execution of the interpreter. This simple interface is composed of four requests. Get configuration: collects the current configuration (memory state) of the interpreter. A configuration is composed of the current state, the EventPool and values of attributes, of each ActiveObject. Set configuration: loads a configuration as the current memory state of the interpreter. Get fireable transitions: gets transitions from ActiveObject instances that have their trigger and their guard satisfied in the current state. A fireable transition is identified by its id and the ActiveObject to which it belongs. Fire a transition: fires a fireable transition of an ActiveObject. When firing, the event of the trigger is consumed, the current state is updated, and effects attached to this transition are processed.
With only four requests, this simple interface offers several
possibilities. Indeed, the model interpreted can be executed
step by step. A specific execution path can be chosen with
the ”Get fireable transitions” request. This feature enables to
check a property or find a bug in a specific path. However, the
most powerful functionality is the ability to make back-in-time
execution [
This generic API gives the possibility to use several kinds of tools in an easy way. Indeed, to connect an existing tool, you just need to add a TCP client and to implement the communication interface. In our point of view, it is better to use existing tools than implementing ad-hoc tools. One reason is that existing tools have been tested, used and approved for many years. Engineers are familiar with these tools and no formation will be required to teach them how to use them.
even if only TCP connection for PC, and RS232 connection
for at91sam7s and stm32 have been developed for the moment.
With a strategy pattern [
To illustrate our approach we use a level crossing system, presented in Figure 4. A level crossing is a system built at the intersection of a railroad and a road. It is responsible for ensuring the safety of all road users during the passage of the train. In this case study, a UML model of a level crossing has been designed (Figure 5 and Figure 6). The Controller controls the activation of the RoadSign (e.g, lights, alarm) and the closure of the Gate according to signals received from TrackCircuits. TrackCircuits are sensors able to detect the Train on the railroad. Each one sends a signal when the Train is detected and another one when the detection ends. The level crossing counts three TrackCircuits: one for the entrance, one for the approach, and one for the exit of the level crossing.
All these objects are active, so their behaviors are described
by state machines. A state machine is composed of states
linked together with directed transitions. Transitions can be
fired to change the state of an ActiveObject. A transition
is fireable if the event associated with its trigger has been
received by this state machine and if its guard is satisfied.
When a transition is fired, its effect is processed. The language
used to parse guards defined as OpaqueExpressions and effects
defined as OpaqueBehaviors is a simplified version of ABCD
[
We will now describe behaviors of ActiveObjects (Figure 6) to better understand these interactions. The Train state machine triggers sequentially the detection of the entrance TrackCircuit (tcEntrance), of the approach TrackCircuit (tcApproach) and of the exit TrackCircuit (tcExit). This linear state machine considers the passage of a single train on the level crossing. TrackCircuits state machines have only two states Detection and NoDetection that transmit signals to the controller at the beginning and at the end of train detection. State machines for tcApproach and tcExit are similar to the state machine of tcEntrance presented on Figure 6. The Controller state machine has the most important role in the system. When the train is detected by tcEntrance, it is in charge of sending a signal to switch on lights of the roadSign. Then, it sends a signal to close the gate when the train begins to be detected by tcApproach. At the end of the detection, we consider that the train is passing until the detection of tcExit, which sends a signal to open the gate. Finally, a signal is send to switch off lights of the roadSign when the train quits the detection zone of tcExit, and the controller returns in its idle state. The state machine of the RoadSign can alternate between Inactive and Active states thanks to switchOn and switchOff signal events. In the same way, the state machine of the Gate is driven by open and close events to go in the Opened or Closed state.
This example model is not connected with its real environment because the link of the interpreter with inputs and outputs of the embedded board have not been implemented yet. However, the level crossing of our case study has sensors (TrackCircuits) and actuators (RoadSign and Gate) that have been integrated to the design model. This enables to simulate the level crossing example as if it was executing on the real system, which uses inputs and outputs of the board. In fact, only the controller will need to be deployed on the real system because other entities are active elements of the environment.
The level crossing case study has been deployed on our interpreter of UML models. This experimentation has been made on a PC with a Linux operating system, and on both at91sam7s and stm32 targets without operating systems (baremetal). The level crossing model has been designed using tUML before being serialized into Eclipse UML, and finally into C. It has been successfully executed on the interpreter by firing the first fireable transition on active objects in turns. Without any optimizations, the memory footprint of the binary executable file containing the model, the interpreter, and specific libraries of the board for the stm32 is only 131 ko, which is sufficiently small to be embedded.
We have also connected two diagnosis tools to control remotely the execution of the level crossing model. A simulator has been developed to explore some execution paths of this model. It can be connected to the interpreter using either a TCP connection or a serial connection. Indeed, a serial port communication using a UART peripheral of the PC was developed to communicate directly with the embedded interpreter for debug purpose but this functionality has become useless with the communication converter. The simple user interface (Figure 7) provides four buttons to apply each request of the API and directly control the model execution. This gives the possibility to the user to get information on the execution and to make the model evolve by firing transitions. To observe the model execution, the simulator has also the ability to decode the configuration and to display its content in an understandable way for humans.
Another diagnosis tool has also been connected to the model interpreter for state-space exploration. For this purpose, the communication unit developed in the simulator has been integrated into this state-space explorer. This tool has computed the state-space of the level crossing model using a breadth first search algorithm connected with the interpreter via the TCP diagnosis interface. This results in a state-space constituted of 1,825 different configurations linked to one another with 5,793 transitions (This state-space exploration has been performed with 3 events preloaded in the EventPool of the controller: entranceBegin, exitBegin, and exitEnd.). The associated statespace graph shown in Figure 8 gives an overview of the extent of this model exploration.
To sum up, these experimentations show the ability of our interpreter to be remotely controlled by diagnosis tools for simulation and exploration purposes.
Some generic tools are able to build an interpreter, and
execute models designed with a given DSL. GEMOC studio
is an Eclipse plugin that integrates a language workbench,
and a modeling workbench to define a DSML as well as
design models conforming to this language. This environment
can be used to build a model interpreter, and other diagnosis
tools (e.g., a graphical model animator, a trace manager) [
Another essential problem for the execution of models is
the lack of tools after deployment. This issue has not been
completely addressed yet. For UML, some simulators and
interpreters begin to appear without being widely used at the
moment. For other DSLs, only generic frameworks or the use
of a design pattern dedicated for monitoring [
Numerous related works have also been achieved on real
time virtual machines (VMs) [
In this paper, we have introduced an interpreter of UML models with the specificity to use a single semantics definition for both the design phase and the deployment. This approach eliminates the problem of the equivalence between models, and the semantic gap created by model transformations. The use of tUML enables to define complete executable models that can be directly executed on the interpreter by serializing the model into C language. A first step to solve the lack of diagnosis toolboxes for DSLs has been made with the implementation of a generic communication interface that enables the use of existing tools. This enables to control remotely the execution of the interpreter step by step or in a back-in-time way. We illustrate this functionality by implementing a simple simulator that communicates with the interpreter running on an embedded board. This simulator can be used to simulate a model and to explore some execution paths. We have also confirmed that we can explore a full state-space.
LTSmin [