-<p>The basic elements of ROOM are the actors with their ports and protocols. The protocol provides a formal interface description. The port is an interaction point where the actor interacts with its outside world. Each port has exactly one protocol attached. The sum of all ports builds up the complete interface of an actor. Each port can receive messages, with or without data, which are defined in the attached protocol. Each message will be handled by the actors behavior (state machine) or will be delegated to the actors internal structure.</p>

-<p>The actor provides access protection for its own attributes (including complex types (classical objects)), including concurrency protection. An actor has neither public attributes nor public operations. The only interaction with the outside world takes place via interface ports. This ensures a high degree of reusability on actor level and provides an effective and safe programming model to the developer. </p>

-<p>Receiving a message via a port will trigger the internal state machine. A transition will be executed depending on the message and the current state. Within this transition, detail level code will be executed and response messages can be sent.</p>

-<p>With this model, a complex behavior can be divided into many relatively simple, linked actors. To put it the other way round: The complex behavior will be provided by a network of relatively simple components which are communicating with each other via well defined interfaces.</p>

-</div>

-<div class="section" title="Hierarchy in Structure and Behavior">

-<div class="titlepage">

-<div>

-<div>

-<h3 class="title">

-<a name="HierarchyinStructureandBehavior"></a>Hierarchy in Structure and Behavior</h3>

-</div>

-</div>

-</div>

-<p>ROOM provides two types of hierarchy. Behavioral hierarchy and structural hierarchy. Structural hierarchy means that actors can be nested to arbitrary depth. Usually you will add more and more details to your application with each nesting level. That means you can focus yourself on any level of abstraction with always the same element, the actor. Structural hierarchy provides a powerful mechanism to divide your problem in smaller pieces, so that you can focus on the level of abstraction you want to work on. </p>

-<p>The actor&rsquo;s behavior will be described with a state machine. A state in turn may contain sub states. This is another possibility to focus on an abstraction level. Take the simple FSM from the blinky actor from the blinky tutorial. </p>

-<p>Top level:

-

- </p>

-<div class="mediaobject">

-<img src="images/020-Blinky15.png"></div>

-<p>

-

-</p>

-<p>

-

-<span class="emphasis"><em>blinking</em></span> Sub machine:

-

- </p>

-<div class="mediaobject">

-<img src="images/020-Blinky151.png"></div>

-<p>

-

-</p>

-<p>From an abstract point of view there is a state

- <span class="emphasis"><em>blinking</em></span>. But a simple LED is not able to blink autonomously. Therefore you have to add more details to your model to make a LED blinking, but for the current work it is not of interest how the blinking is realized. This will be done in the next lower level of the hierarchy.

-<p>The Actor that provides a service implements an SPP and the client of that service implements an SAP. The Layer Connection connects all SAPs of a specific Protocol within an Actor hierarchy with an SPP that implements the service. From the Actors point of view, SAPs and SPPs behave almost like regular ports.</p>

-<p>

-

-</p>

-<div class="mediaobject">

-<img src="images/010-LayerExample.png"></div>

-<p>

-

-</p>

-<p>The Example shows a layered model. The Layer Connections define e.g. that the

- <span class="emphasis"><em>ApplicationLayer</em></span> can only use the services of the

- <span class="emphasis"><em>ApplicationLayer</em></span> that implement an SAP for those services are connected directly to the implementation of the services.

- Layering and actor hierarchies with port to port connections can be mixed on every level of granularity.

- </p>

-</div>

-<div class="section" title="Run to Completion">

-<div class="titlepage">

-<div>

-<div>

-<h3 class="title">

-<a name="RuntoCompletion"></a>Run to Completion</h3>

-</div>

-</div>

-</div>

-<p>

-

-<span class="bold"><strong>Run to completion</strong></span> (RTC) is a very central concept of ROOM. It enables the developer to concentrate on the functional aspects of the system. The developer doesn&rsquo;t have to care about concurrency issues all the time. This job is concentrated to the system designer in a very flexible way.

- What does

- <span class="bold"><strong>run to completion</strong></span> mean:

- RTC means that an actor, which is processing a message, can not receive the next message as long as the processing of the current message has been finished. Receiving of the next message will be queued from the underlying run time system.

- </p>

-<p>Note: It is very important not to confuse run to completion and preemption. Run to completion means that an actor will finish the processing of a message before he can receive a new one (regardless of its priority). That does not mean that an actor cannot be preempted from an higher priority thread of control. But even a message from this higher prior thread of control will be queued until the current processing has been finished. </p>

-<p>With this mechanism all actor internal attributes and data structures are protected. Due to the fact that multiple actors share one thread of control, all objects are protected which are accessed from one thread of control but multiple actors. This provides the possibility to decompose complex functionality to several actors without the risk to produce access violations or dead locks.</p>

-<p>The goal of eTrice is to describe distributed systems on a logical level. In the current version not all elements will be used. But as prerequisite for further versions the following elements can be defined:</p>

- <span class="emphasis"><em>LogicalSystem</em></span> represents the complete distributed system and contains at least one

- <span class="emphasis"><em>SubSystemRef</em></span>. The

- <span class="emphasis"><em>SubSystemClass</em></span> represents an address space and contains at least one

- <span class="emphasis"><em>ActorRef</em></span>. The

- <span class="emphasis"><em>ActorClass</em></span> 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.

- </p>

-<p>The outline view of the textual ROOM editor shows the main modeling elements in an easy to navigate tree.</p>

-<p>The DataClass enables the modeling of hierarchical complex datatypes and operations on them. The DataClass is the equivalent to a Class in languages like Java or C++, but has less features. The content of a DataClass can always be sent via message between actors (defined as message data in ProtocolClass).</p>

-<p>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

- <span class="bold"><strong>message driven</strong></span> and parts of the

- <span class="bold"><strong>data driven</strong></span> execution model. In future releases more execution models will be supported, depending on the requirements of the community.

- </p>

-<div class="section" title="Communication Methods">

-<div class="titlepage">

-<div>

-<div>

-<h3 class="title">

-<a name="CommunicationMethods"></a>Communication Methods</h3>

-</div>

-</div>

-</div>

-<div class="itemizedlist">

-<ul class="itemizedlist" type="disc">

-<li class="listitem">

-<p>

-

-<span class="bold"><strong>message driven</strong></span> (asynchronous, non blocking, no return value): Usually the message driven communication is implemented with message queues. Message queues are inherently asynchronous and enable a very good decoupling of the communicating parties.

- </p>

-</li>

-<li class="listitem">

-<p>

-

-<span class="bold"><strong>data driven</strong></span> (asynchronous, non blocking, no return value): In data driven communication sender and receiver often have a shared block of data. The sender writes the data and the receiver polls the data.

- A finite-state machine (FSM) or finite-state automaton (plural: automata), or simply a state machine, is a mathematical model used to design computer programs and digital logic circuits. It is conceived as an abstract machine that can be in one of a finite number of states. The machine is in only one state at a time; the state it is in at any given time is called the current state. It can change from one state to another when initiated by a triggering event or condition, this is called a transition. A particular FSM is defined by a list of the possible states it can transition to from each state, and the triggering condition for each transition.</p>

-</blockquote>

-</div>

-<p>In ROOM each actor class can implement its behavior using a state machine. Events occurring at the end ports of an actor will be forwarded to and processed by the state machine. Events possibly trigger state transitions.</p>

-</div>

-<div class="section" title="Motivation">

-<div class="titlepage">

-<div>

-<div>

-<h3 class="title">

-<a name="Motivation4"></a>Motivation</h3>

-</div>

-</div>

-</div>

-<p>For event driven systems a finite state machine is ideal for processing the stream of events. Typically during processing new events are produced which are sent to peer actors.</p>

-<p>We distinguish flat and hierarchical state machines.</p>

-</div>

-<div class="section" title="Notation">

-<div class="titlepage">

-<div>

-<div>

-<h3 class="title">

-<a name="Notation6"></a>Notation</h3>

-</div>

-</div>

-</div>

-<div class="section" title="Flat Finite State Machine">

-<div class="titlepage">

-<div>

-<div>

-<h4 class="title">

-<a name="FlatFiniteStateMachine"></a>Flat Finite State Machine</h4>

-</div>

-</div>

-</div>

-<p>The simpler flat finite state machines are composed of the following elements:</p>

-<p>The application should switch on and off the LED for 5 seconds in a 1 second interval, then 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

- <span class="emphasis"><em>Blinky</em></span>. The 5 second interval should be implemented in

-<span class="emphasis"><em>usercode1</em></span> will be generated at the beginning of the file, outside the class definition.

- <span class="emphasis"><em>usercode2</em></span> 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

- <span class="emphasis"><em>destroyUser()</em></span> is a predefined operation that will be called during shutdown of the application. Within this operation, cleanup of manual coded classes can be done.

- </p>

-<p>Now design the FSM of

- <span class="emphasis"><em>Blinky</em></span>. Remember, as the name suggested

- <span class="emphasis"><em>blinking</em></span> is a state in which the LED must be switched on and off. We will realize that by an hierarchical FSM in which the

- <span class="emphasis"><em>blinking</em></span> state has two sub states.

- </p>

-<p>Open the behavior diagram of

- <span class="emphasis"><em>Blinky</em></span> by right clicking the

- <span class="emphasis"><em>Blinky</em></span> actor in the outline view. Create two states named

- <span class="emphasis"><em>off</em></span> 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.

- </p>

-<p>Action code of the init transition is:</p>

-<div class="literallayout">

-<p>

-<code class="code">carLights&nbsp;=&nbsp;light.getCarLights();<br>

-pedLights&nbsp;=&nbsp;light.getPedLights();<br>

-carLights.setState(TrafficLight3.OFF);<br>

-pedLights.setState(TrafficLight2.OFF);<br>

-

-</code>

-</p>

-</div>

-<div class="blockquote">

-<blockquote class="blockquote">

-<p></p>

-</blockquote>

-</div>

-<p>Action code from

- <span class="emphasis"><em>blinking</em></span> to

- <span class="emphasis"><em>off</em></span> is:

- </p>

-<div class="literallayout">

-<p>

-<code class="code">timer.Kill();<br>

-carLights.setState(TrafficLight3.OFF);&nbsp;<br>

-

-</code>

-</p>

-</div>

-<div class="blockquote">

-<blockquote class="blockquote">

-<p></p>

-</blockquote>

-</div>

-<p>The model is complete now. You can run and debug the model as described in getting started. Have fun.</p>

-<p>The complete model can be found in /org.eclipse.etrice.tutorials/model/Blinky.</p>

-<p>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.</p>

-<p>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.

- <span class="bold"><strong>M</strong></span> odeling) is and what it is good for. It will try to answer the following questions:

- </p>

-<div class="itemizedlist">

-<ul class="itemizedlist" type="disc">

-<li class="listitem">

-<p>Where does it come from?</p>

-</li>

-<li class="listitem">

-<p>Which kind of SW-Systems will be addressed?</p>

-</li>

-<li class="listitem">

-<p>What is the relation between OOP and ROOM?</p>

-</li>

-<li class="listitem">

-<p>What are the benefits of ROOM?</p>

-</li>

-<li class="listitem">

-<p>Which consequences must be taken into account?</p>

-</li>

-</ul>

-</div>

-<div class="section" title="Where does it come from?">

-<div class="titlepage">

-<div>

-<div>

-<h3 class="title">

-<a name="Wheredoesitcomefrom"></a>Where does it come from?</h3>

-</div>

-</div>

-</div>

-<p>Room was developed in the 1990th on the background of the upcoming mobile applications with the goal to manage the complexity of such huge SW-Systems. From the very beginning ROOM has focused on a certain type of SW-Systems and is, in contrast to the UML, well suited for this kind of systems. In this sense, ROOM is a DSL (Domain Specific Language) for distributed, event driven, real time systems. </p>

-<p>Bran Selic, Garth Gullekson and Paul T. Ward have published the concepts 1994 in the book

- <span class="emphasis"><em>object time</em></span> &trade; developed a ROOM tool which was taken over by

- <span class="emphasis"><em>Rational SW</em></span> &trade; and later on by

- <span class="emphasis"><em>IBM</em></span> &trade;.

- The company

- <span class="emphasis"><em>Protos Software Gmbh</em></span> &trade; also developed a ROOM tool called

- <span class="emphasis"><em>Trice</em></span> &trade; for control software for production machines and automotive systems.

- <span class="emphasis"><em>Trice</em></span> &trade; is the predecessor of eTrice (see Introduction to eTrice).

- </p>

-<p>From our point of view ROOM provides still the clearest, simplest, most complete and best suited modeling concepts for the real time domain. All later proposals like the UML do not fit as well to this kind of problems.</p>

-</div>

-<div class="section" title="Which kind of SW-Systems will be addressed?">

-<div class="titlepage">

-<div>

-<div>

-<h3 class="title">

-<a name="WhichkindofSWSystemswillbeaddressed"></a>Which kind of SW-Systems will be addressed?</h3>

-</div>

-</div>

-</div>

-<p>As mentioned before ROOM addresses distributed, event driven, real time systems. But what is a

- <span class="bold"><strong>real time system</strong></span>? ROOM defines a set of properties which are typical for a real time system. These properties are:

- </p>

-<div class="itemizedlist">

-<ul class="itemizedlist" type="disc">

-<li class="listitem">

-<p>Timeliness</p>

-</li>

-<li class="listitem">

-<p>Dynamic internal structure</p>

-</li>

-<li class="listitem">

-<p>Reactiveness</p>

-</li>

-<li class="listitem">

-<p>Concurrency</p>

-</li>

-<li class="listitem">

-<p>Distribution</p>

-</li>

-<li class="listitem">

-<p>Reliability</p>

-</li>

-</ul>

-</div>

-<p>Each of these properties has potential to make SW development complex. If a given system can be characterized with a combination of or all of these properties, ROOM might be applied to such a system. </p>

-<p>As an example take a look at a washing machine. The system has to react on user interactions, has to handle some error conditions like a closed water tap or a defective lye pump. It has to react simultaneously to all these inputs. It has to close the water valve in a certain time to avoid flooding the basement.

- So, the system can be characterized as timely, concurrent and reactive. As long as the washing machine does not transform to a laundry drier by itself, the system has no dynamic internal structure and as long as all functions are running on a single micro controller the (SW)-system is not distributed.

- ROOM fits perfect to such a system.</p>

-<p>A SW system which mainly consists of data transformations like signal/image processing or a loop controller (e.g. a PID controller) cannot be characterized with any of the above mentioned properties. However, in the real world most of the SW systems will be a combination of both. ROOM can be combined with such systems, so that for example an actor provides a

- <span class="bold"><strong>run to completion</strong></span> context for calculating an image processing algorithm or a PID controller.

- </p>

-</div>

-<div class="section" title="What is the relation between OOP and ROOM?">

-<div class="titlepage">

-<div>

-<div>

-<h3 class="title">

-<a name="WhatistherelationbetweenOOPandROOM"></a>What is the relation between OOP and ROOM?</h3>

-</div>

-</div>

-</div>

-<p>The relation between classical object oriented programming and ROOM is comparable to the relation between assembler programming and C programming. It provides a shift of the object paradigm. As the picture shows, the classic object paradigm provides some kind of information hiding. Attributes can be accessed via access methods. Logical higher level methods provide the requested behavior to the user. </p>

-<p>

-

-</p>

-<div class="mediaobject">

-<img src="images/010-RoomIntroduction01.png"></div>

-<p>

-

-</p>

-<p>As the figure illustrates, the classical object paradigm does not care about concurrency issues. The threads of control will be provided by the underlying operating system and the user is responsible to avoid access violations by using those operating system mechanisms directly (semaphore, mutex).</p>

-<p>

-

-</p>

-<div class="mediaobject">

-<img src="images/010-RoomIntroduction02.png"></div>

-<p>

-

-</p>

-<p>ROOM provides the concept of a logical machine (called actor) with its own thread of control. It provides some kind of cooperative communication infrastructure with

-<p>This thinking of an object is much more general than the classic one. </p>

-</div>

-<div class="section" title="What are the benefits of ROOM?">

-<div class="titlepage">

-<div>

-<div>

-<h3 class="title">

-<a name="WhatarethebenefitsofROOM"></a>What are the benefits of ROOM?</h3>

-</div>

-</div>

-</div>

-<p>ROOM has a lot of benefits and it depends on the users point of view which is the most important one. From a general point of view the most important benefit is, that ROOM allows to create SW systems very efficient, robust and safe due to the fact that it provides some abstract, high level modeling concepts combined with code generation and a small efficient runtime environment. </p>

-<p>In detail:</p>

-<div class="itemizedlist">

-<ul class="itemizedlist" type="disc">

-<li class="listitem">

-<p>ROOM models contain well defined interfaces (protocols), which makes it easy to reuse components in different applications or e.g. in a test harness. </p>

-</li>

-<li class="listitem">

-<p>Graphical modeling makes it easy to understand, maintain and share code with other developers</p>

-</li>

-<li class="listitem">

-<p>Higher abstraction in combination with automated code generation provides very efficient mechanisms to the developer. </p>

-</li>

-<li class="listitem">

-<p>ROOM provides graphical model execution, which makes it easy to understand the application or find defects in a very early phase. </p>

-</li>

-</ul>

-</div>

-</div>

-<div class="section" title="Which consequences must be taken into account?">

-<div class="titlepage">

-<div>

-<div>

-<h3 class="title">

-<a name="Whichconsequencesmustbetakenintoaccount"></a>Which consequences must be taken into account?</h3>

-</div>

-</div>

-</div>

-<p>Generating code from models will introduce some overhead in terms of memory footprint as well as performance. For most systems the overhead will be negligible. However, the decision for using ROOM should be made explicitly and it is always a trade off between development costs, time to market and costs in terms of a little bit more of memory and performance. Thanks to the powerful component model, ROOM is especially well suited for the development of software product lines with their need for reusable core assets. </p>

-<p>Care must be taken during the introduction of the new methodology. Due to the fact that ROOM provides a shift of the object paradigm, developers and teams need a phase of adaption. Every benefit comes at a price.</p>

-<p>In addition to the Actor containment hierarchies, Layering provides another method to hierarchically structure a software system. Layering and actor hierarchies with port to port connections can be mixed on every level of granularity.</p>

-<div class="orderedlist">

-<ol class="orderedlist" type="1">

-<li class="listitem">

-<p>an ActorClass can define a Service Provision Point (SPP) to publish a specific service, defined by a ProtocolClass</p>

-</li>

-<li class="listitem">

-<p>an ActorClass can define a Service Access Point (SAP) if it needs a service, defined by a ProtocolClass</p>

-</li>

-<li class="listitem">

-<p>for a given Actor hierarchy, a LayerConnection defines which SAP will be satisfied by (connected to) which SPP</p>

-<p>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:</p>

-<p>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.</p>

-<p>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.</p>

- <span class="emphasis"><em>MrPing</em></span>. As long as the guard is true

- <span class="emphasis"><em>MrPing</em></span> sends back the value.

- </p>

-<p>Within the

- <span class="emphasis"><em>next</em></span> transition,

- <span class="emphasis"><em>MrPing</em></span> creates a data class and sends the default values. Then

- <span class="emphasis"><em>MrPing</em></span> 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

- <span class="emphasis"><em>sending data by value</em></span>.

- However, for performance reasons some applications requires

- <span class="emphasis"><em>sending data by reference</em></span>. 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.

-<p>You are now familiar with all necessary steps to create, build and run an eTrice C model from scratch. You are able to create a launch configuration to start the code generator and to perform all necessary settings to compile and link the application. </p>

-<p>The next tutorial provides an exercise to get more familiar with these working steps.</p>

- <span class="emphasis"><em>TimingService</em></span>, 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.

- </p>

-<p>After the exercise is created you must copy the GUI to your src directory (see below).</p>

-<p>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.</p>

-<span class="section"><a href="Whydoesitworkandwhyisitsafe.html">Why does it work and why is it safe?</a></span>

-</dt>

-</dl>

-</div>

-<div class="section" title="Scope">

-<div class="titlepage">

-<div>

-<div>

-<h2 class="title" style="clear: both">

-<a name="Scope4"></a>Scope</h2>

-</div>

-</div>

-</div>

-<p>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 =&gt; 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.</p>

-<p>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.</p>

-<p>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

- <span class="emphasis"><em>REQUEST</em></span> button to start a FSM, which controls the traffic lights.

- </p>

-<p>

-

-</p>

-<div class="mediaobject">

-<img src="images/020-Blinky08.png"></div>

-<p>

-

-</p>

-<p>The

- <span class="emphasis"><em>REQUEST</em></span> must lead to a model message which starts the activity of the lights.

- </p>

-<p>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:</p>

-<div class="orderedlist">

-<ol class="orderedlist" type="1">

-<li class="listitem">

-<p>specify the messages (within a protocol) which should be sent into the model</p>

-</li>

-<li class="listitem">

-<p>model an actor with a port (which uses the specified protocol) and connect the port to the receiver </p>

-</li>

-<li class="listitem">

-<p>the external code should know the port (import of the port class)</p>

-</li>

-<li class="listitem">

-<p>the external code should provide a registration method, so that the actor is able to allow access to this port</p>

-<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Why does it work and why is it safe?</h1>

-<div class="section" title="Why does it work and why is it safe?">

-<div class="titlepage">

-<div>

-<div>

-<h2 class="title" style="clear: both">

-<a name="Whydoesitworkandwhyisitsafe"></a>Why does it work and why is it safe?</h2>

-</div>

-</div>

-</div>

-<p>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

- <span class="bold"><strong>run to completion</strong></span> semantic. To answer this question, take a look at the

- <span class="emphasis"><em>MessageService.java</em></span> from the runtime environment. There you will find the receive method which puts each message into the queue.

-<p>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.</p>

-<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Working with the eTrice Tutorials</h1>

-<div class="chapter" title="Working with the eTrice Tutorials">

-<div class="titlepage">

-<div>

-<div>

-<h2 class="title">

-<a name="WorkingwiththeeTriceTutorials"></a>Working with the eTrice Tutorials</h2>

-</div>

-</div>

-</div>

-<p>The eTrice Tutorials will help you to learn and understand the eTrice tool and concepts. ETrice supports several target languages. The concepts will not be explained for each language. </p>

-<p>Most of the common concepts will be described for Java as target language. To start with a new language the first steps to setup the workspace and to generate and run the first model will be described also. Target language specific aspects will be described as well.</p>

-<p>Therefore the best way to start with eTrice is to follow the Java Tutorials and after that switch to your target language. </p>