eTrice User Guide

eTrice provides an implementation of the ROOM modeling language (Real Time Object Oriented Modeling) together with editors, code generators for Java, C++ and C code and exemplary target middleware.

The model is defined in textual form (Xtext) with graphical editors (Graphiti) for the structural and behavioral (i.e. state machine) parts.

Basically everyone who develops eventdriven realtime or embedded systems.

If you have other ideas how to use it, tell us!

TODO

TODO

This chapter will give a rough overview of what ROOM ( R eal time O bject O riented M odeling) is and what it is good for. It will try to answer the following questions:

Since from ROOM models executable code can be generated, it is important to define the way the actors are executed and communicate with each other. The combination of communication and execution is called the Execution Model. Currently the eTrice tooling only supports the message driven and parts of the data driven execution model. In future releases more execution models will be supported, depending on the requirements of the community.

In this tutorial you will build your first very simple eTrice model. The goal is to learn the work flow of eTrice and to understand a few basic features of ROOM. You will perform the following steps:

Make sure that you have set up the workspace as described in [Setting up the workspace].

video: hello world

The easiest way to create a new eTrice Project is to use the eclipse project wizard. From the eclipse file menu select [File->New->Project] and create a new eTrice project and name it [HelloWorld]

The wizard creates everything that is needed to create, build and run an eTrice model. The resulting project should look like this:

Within the model directory the model file [HelloWorld.room] was created. Open the [HelloWorld.room] file and delete the contents of the file. Open the content assist with Ctrl+Space and select [model skeleton].

Edit the template variables by typing the new names and jumping with Tab from name to name.

The resulting model code should look like this:

The goal of eTrice is to describe distributed systems on a logical level. In the current version not all elements will be supported. But as prerequisite for further versions the following elements are mandatory for an eTrice model:

The [LogicalSystem] represents the complete distributed system and contains at least one [SubSystemRef]. The [SubSystemClass] represents an address space and contains at least one [ActorRef]. The [ActorClass] is the building block of which an application will be built of. It is in general a good idea to define a top level actor that can be used as reference within the subsystem.

The outline view of the textual ROOM editor shows the main modeling elements in an easy to navigate tree.

We will implement the Hello World code on the initial transition of the [HelloWorldTop] actor. Therefore open the state machine editor by right clicking the [HelloWorldTop] actor in the outline view and select [Edit Behavior].

The state machine editor will be opened. Drag and drop an [Initial Point] from the tool box to the diagram into the top level state. Drag and drop a [State] from the tool box to the diagram. Confirm the dialogue with [ok]. Select the [Transition] in the tool box and draw the transition from the [Initial Point] to the State. Open the transition dialogue by double clicking the caption of the transition and fill in the action code.

The result should look like this:

Save the diagram and inspect the model file. Note that the textual representation was created after saving the diagram.

Now the model is finished and source code can be generated. The project wizard has created a launch configuration that is responsible for generating the source code. From [HelloWorld/] right click [gen_HelloWorld.launch] and run it as gen_HelloWorld. All model files in the model directory will be generated.

The code will be generated to the src-gen directory. The main function will be contained in [SubSystem_HelloWorldRunner.java]. Select this file and run it as Java application.

The Hello World application starts and the string will be printed on the console window. To stop the application the user must type [quit] in the console window.

During runtime the application produced a MSC and wrote it to a file. Open HelloWorld/tmp/log/SubSystem_HelloWorld_Async.seq using Trace2UML (it is open source and can be obtained from http://trace2uml.tigris.org/). You should see something like this:

Now you have generated your first eTrice model from scratch. You can switch between diagram editor and model (.room file) and you can see what will be generated during editing and saving the diagram files. You should take a look at the generated source files to understand how the state machine is generated and the life cycle of the application. The next tutorials will deal with more complex hierarchies in structure and behavior.

This tutorial describes how to use the [TimingService], how to combine a generated model with manual code and how to model a hierarchical state machine. The idea of the tutorial is to switch a LED on and off. The behavior of the LED should be: blinking in a one second interval for 5 seconds, stop blinking for 5 seconds, blinking, stop,... For this exercise we will use a little GUI class that will be used in more sophisticated tutorials too. The GUI simulates a pedestrian traffic crossing. For now, just a simple LED simulation will be used from the GUI.

After the exercise is created you must copy the GUI to your src directory (see below).

The package contains four java classes which implements a small window with a 3-light traffic light which simulates the signals for the car traffic and a 2-light traffic light which simulates the pedestrian signals.

The GUI looks like this:

Within this tutorial we will just toggle the yellow light.

You will perform the following steps:

Remember exercise [HelloWorld]. Create a new eTrice project and name it [Blinky]

To use the GUI please copy the package [org.eclipse.etrice.tutorials.PedLightGUI] from „org.eclipse.etrice.tutorials/src” to your [src] directory „Blinky/src”. For this tutorial you must remove the error markers by editing the file [PedestrianLightWndNoTcp.java]. Appropriate comments are provided to remove the error marker for this turorial.

Open the [Blinky.room] file and copy the following code into the file or use content assist to create the model.

Position the cursor outside any class definition and right click the mouse within the editor window. From the context menu select [Content Assist]

Select [ActorClass – actor class skeleton] and name it [Blinky].

Repeat the described procedure and name the new actor [BlinkyController].

With Ctrl+Shift+F you can beautify the model code.

Save the model and visit the outline view.

With the help of [Content Assist] create a [ProtocolClass] and name it [BlinkyControlProtocol]. Inside the brackets use the [Content Assist] (CTRL+Space) to create two incoming messages called [start] and [stop].

The resulting code should look like this:

With Ctrl-Shift+F or selecting [Format] from the context menu you can format the text. Note that all elements are displayed in the outline view.

Switching on and off the LED is timing controlled. The timing service is provided from the model library and must be imported before it can be used from the model.

This is the first time you use an element from the modellib. Make sure that your Java Build Path has the appropriate entry to the modellib. Otherwise the jave code, which will be generated from the modellib, can not be referenced. (right click to [Blinky] and select properties. Select the [Java Build Path] tab)

After the build path is set up return to the model and navigate the cursor at the beginning of the model and import the timing service:

Make sure that the path fits to your folder structure.

Now it can be used within the model. Right click to [SubSystem_Blinky] within the outline view. Select [Edit Structure]. The [application] is already referenced in the subsystem. Drag and Drop an [ActorRef] to the [SubSystem_Blinky] and name it [timingService]. From the actor class drop down list select [room.basic.service.timing.ATimingService]. Draw a [LayerConnection] from [application] to each service provision point (SPP) of the [timingService]. The resulting structure should look like this:

The current version of eTrice does not provide a graphical element for a service access point (SAP). Therefore the SAPs to access the timing service must be added in the .room file. Open the [Blinky.room] file and navigate to the [Blinky] actor. Add the following line to the structure of the actor:

Do the same thing for [BlinkyController].

The resulting code should look like this:

From the outline view right click to [Blinky] and select [Edit Structure]. Drag and Drop an [Interface Port] to the boarder of the [Blinky] actor. Note that an interface port is not possible inside the actor. Name the port [ControlPort] and select [BlinkyControlProtocol] from the drop down list. Uncheck [Conjugated] and [Is Relay Port]. Klick [ok]. The resulting structure should look like this:

Repeat the above steps for the [BlinkyController]. Make the port [Conjugated]

Keep in mind that the protocol defines [start] and [stop] as incoming messages. [Blinky] receives this messages and therefore [Blinky]'s [ControlPort] must be a regular port and [BlinkyController]'s [ControlPort] must be a conjugated port.

From the outline view right click [BlinkyTop] and select [Edit Structure].

Drag and Drop an [ActorRef] inside the [BlinkyTop] actor. Name it [blinky]. From the actor class drop down list select [Blinky]. Do the same for [controller]. Connect the ports via the binding tool. The resulting structure should look like this:

The application should switch on and off the LED for 5 seconds in a 1 second interval, than stop blinking for 5 seconds and start again. To implement this behavior we will implement two FSMs. One for the 1 second interval and one for the 5 second interval. The 1 second blinking should be implemented in [Blinky]. The 5 second interval should be implemented in [BlinkyController]. First implement the Controller.

Right click to [BlinkyController] and select [Edit Behavior]. Drag and Drop the [Initial Point] and two [States] into the top state. Name the states [on] and [off]. Use the [Transition] tool to draw transitions from [init] to [on] from [on] to [off] and from [off] to [on].

Open the transition dialog by double click the arrow to specify the trigger event and the action code of each transition. Note that the initial transition does not have a trigger event.

The transition dialog should look like this:

The defined ports will be generated as a member attribute of the actor class from type of the attached protocol. So, to send e message you must state [port.message(param);]. In this example [ControlPort.start()] sends the [start] message via the [ControlPort] to the outside world. Assuming that [Blinky] is connected to this port, the message will start the one second blinking FSM. It is the same thing with the [timer]. The SAP is also a port and follows the same rules. So it is clear that [timer.Start(5000);] will send the [Start] message to the timing service. The timing service will send a [timeoutTick] message back after 5000ms.

Within each transition the timer will be restarted and the appropriate message will be sent via the [ControlPort].

The resulting state machine should look like this: (Note that the arrows peak changes if the transition contains action code.)

Save the diagram and inspect the [Blinky.room] file. The [BlinkyController] should look like this:

Now we will implement [Blinky]. Due to the fact that [Blinky] interacts with the GUI class a view things must to be done in the model file.

Double click [Blinky] in the outline view to navigate to [Blinky] within the model file. Add the following code: (type it or simply copy it from the tutorial project)

[usercode1] will be generated at the beginning of the file, outside the class definition. [usercode2] will be generated within the class definition. The code imports the GUI class and instantiates the window class. Attributes for the carLights and pedLights will be declared to easily access the lights in the state machine. The Operation [destroyUser()] is a predefined operation that will be called during shutdown of the application. Within this operation, cleanup of manual coded classes can be done.

Now design the FSM of [Blinky]. Remember, as the name suggested [blinking] is a state in which the LED must be switched on and off. We will realize that by an hierarchical FSM in which the [blinking] state has two sub states.

Open the behavior diagram of [Blinky] by right clicking the [Blinky] actor in the outline view. Create two states named [blinking] and [off]. Right click to [blinking] and create a subgraph.

Create the following state machine. The trigger events between [on] and [off] are the [timeoutTick] from the [timer] port.

Create entry code for both states by right clicking the state and select [Edit State...]

Entry code of [on] is:

Entry code of [off] is:

Navigate to the Top level state by double clicking the [/blinking] state. Create the following state machine:

The trigger event from [off] to [blinking] is the [start] event from the [ControlPort].The trigger event from [blinking] to [off] is the [stop] event from the [ControlPort]. Note: The transition from [blinking] to [off] is a so called group transition. This is a outgoing transition from a super state (state with sub states) without specifying the concrete leave state (state without sub states). An incoming transition to a super state is called history transition.

Action code of the init transition is:

Action code from [blinking] to [off] is:

The model is complete now. You can run and debug the model as described in getting started. Have fun.

The complete model can be found in /org.eclipse.etrice.tutorials/model/Blinky.

Run the model and take a look at the generated MSCs. Inspect the generated code to understand the runtime model of eTrice. Within this tutorial you have learned how to create a hierarchical FSM with group transitions and history transitions and you have used entry code. You are now familiar with the basic features of eTrice. The further tutorials will take this knowledge as a precondition.

This tutorial shows how data will be sent in a eTrice model. Within the example you will create two actors (MrPing and MrPong). MrPong will simply loop back every data it received. MrPing will send data and verify the result.

You will perform the following steps:

Remember exercise [HelloWorld]. Create a new eTrice project and name it [SendingData] Open the [SendingData.room] file and copy the following code into the file or use content assist to create the model.

Position the cursor outside any class definition and right click the mouse within the editor window. From the context menu select [Content Assist] (or Ctrl+Space).

Select [DataClass – data class skeleton] and name it [DemoData]. Remove the operations and add the following Attributes:

Save the model and visit the outline view. Note that the outline view contains all data elements as defined in the model.

With the help of [Content Assist] create a [ProtocolClass] and name it [PingPongProtocol]. Create the following messages:

With the help of [Content Assist] create two new actor classes and name them [MrPing] and [MrPong]. The resulting model should look like this:

The outline view should look like this:

Save the model and visit the outline view. Within the outline view, right click on the [MrPong] actor and select [Edit Structure]. Select an [Interface Port] from the toolbox and add it to MrPong. Name the Port [PingPongPort] and select the [PingPongProtocol]

Do the same with MrPing but mark the port as [conjugated]

Open the Structure from SendingDataTop and add MrPing and MrPong as a reference. Connect the ports.

The model is finished now and can be found in /org.eclipse.etrice.tutorials/model/SendingData.

Generate the code by right click to [gen_SendingData.launch] and run it as [gen_SendingData]. Run the model. The output should look like this:

Within the first loop an integer value will be incremented by [MrPong] and sent back to [MrPing]. As long as the guard is true [MrPing] sends back the value.

Within the [next] transition, [MrPing] creates a data class and sends the default values. Then [MrPing] changes the values and sends the class again. At this point you should note that during the send operation, a copy of the data class will be created and sent. Otherwise it would not be possible to send the same object two times, even more it would not be possible to send a stack object at all. This type of data passing is called [sending data by value]. However, for performance reasons some applications requires [sending data by reference]. In this case the user is responsible for the life cycle of the object. In Java the VM takes care of the life cycle of an object. This is not the case for C/C++. Consider that a object which is created within a transition of a state machine will be destroyed when the transition is finished. The receiving FSM would receive an invalid reference. Therefore care must be taken when sending references.

For sending data by reference you simply have to add the keyword [ref] to the protocol definition.

Make the test and inspect the console output.

The scope of this tutorial is to demonstrate how to receive model messages from outside the model. Calling methods which are not part of the model is simple and you have already done this within the blinky tutorial (this is the other way round: model => external code). Receiving events from outside the model is a very common problem and a very frequently asked question. Therefore this tutorial shows how an external event (outside the model) can be received by the model.

This tutorial is not like hello world or blinky. Being familiar with the basic tool features is mandatory for this tutorial. The goal is to understand the mechanism not to learn the tool features.

The idea behind the exercise is, to control a Pedestrian crossing light. We will use the same GUI as for the blinky tutorial but now we will use the [REQUEST] button to start a FSM, which controls the traffic lights.

The [REQUEST] must lead to a model message which starts the activity of the lights.

There are several possibilities to receive external events (e.g. TCP/UDP Socket, using OS messaging mechanism), but the easiest way is, to make a port usable from outside the model. To do that a few steps are necessary:

The [GuiAdapter] represents the interface to the external code. It registers its [ControlPort] by the external code.

Visit the initial transition to understand the registration. The actor handles the incoming messages as usual and controls the traffic lights as known from blinky.

The [Controller] receives the [start] message and controls the timing of the lights. Note that the [start] message will be sent from the external code whenever the [REQUEST] button is pressed.

The tutorial shows that it is generally possible to use every port from outside the model as long as the port knows its peer. This is guaranteed by describing protocol and the complete structure (especially the bindings) within the model. The only remaining question is: Why is it safe and does not violate the „run to completion” semantic. To answer this question, take a look at the [MessageService.java] from the runtime environment. There you will find the receive method which puts each message into the queue.

This method is synchronized. That means, regardless who sends the message, the queue is secured. If we later on (e.g. for performance reasons in C/C++) distinguish between internal and external senders (same thread or not), care must be taken to use the external (secure) queue.