diff options
Diffstat (limited to 'plugins/org.eclipse.etrice.doc/html/etrice-docse2.html')
| -rw-r--r-- | plugins/org.eclipse.etrice.doc/html/etrice-docse2.html | 868 |
1 files changed, 434 insertions, 434 deletions
diff --git a/plugins/org.eclipse.etrice.doc/html/etrice-docse2.html b/plugins/org.eclipse.etrice.doc/html/etrice-docse2.html index d4db5d87a..e9e97ec8d 100644 --- a/plugins/org.eclipse.etrice.doc/html/etrice-docse2.html +++ b/plugins/org.eclipse.etrice.doc/html/etrice-docse2.html @@ -1,434 +1,434 @@ -<?xml version="1.0" encoding="iso-8859-1" ?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<!--http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd-->
-<html xmlns="http://www.w3.org/1999/xhtml"
->
-<head><title>Introduction to the ROOM Language</title>
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
-<meta name="generator" content="TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)" />
-<meta name="originator" content="TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)" />
-<!-- xhtml,3,next,html -->
-<meta name="src" content="etrice-doc.tex" />
-<meta name="date" content="2013-06-21 12:20:00" />
-<link rel="stylesheet" type="text/css" href="etrice-doc.css" />
-</head><body
->
-<!--l. 1--><div class="crosslinks"><p class="noindent">[<a
-href="etrice-docch2.html" >next</a>] [<a
-href="etrice-docse1.html" >prev</a>] [<a
-href="etrice-docse1.html#tailetrice-docse1.html" >prev-tail</a>] [<a
-href="#tailetrice-docse2.html">tail</a>] [<a
-href="etrice-docch1.html#etrice-docse2.html" >up</a>] </p></div>
-<h3 class="sectionHead"><span class="titlemark">1.2 </span> <a
- id="x5-60001.2"></a>Introduction to the ROOM Language</h3>
-<!--l. 3--><p class="noindent" >
-</p>
-<h4 class="subsectionHead"><span class="titlemark">1.2.1 </span> <a
- id="x5-70001.2.1"></a>Scope of ROOM</h4>
-<!--l. 5--><p class="noindent" >This chapter will give a rough overview of what ROOM (<span
-class="ec-lmssbx-10">R</span>eal-time <span
-class="ec-lmssbx-10">O</span>bject-<span
-class="ec-lmssbx-10">O</span>riented <span
-class="ec-lmssbx-10">M</span>odeling) is and what it
-is good for. It will try to answer the following questions:
-</p>
-
-
- <ul class="itemize1">
- <li class="itemize">Where does it come from?
- </li>
- <li class="itemize">Which kind of SW-Systems will be addressed?
- </li>
- <li class="itemize">What is the relation between object oriented programming and ROOM?
- </li>
- <li class="itemize">What are the benefits of ROOM?
- </li>
- <li class="itemize">Which consequences must be taken into account?</li></ul>
-<!--l. 17--><p class="noindent" >
-</p>
-<h5 class="subsubsectionHead"><a
- id="x5-80001.2.1"></a>Where does it come from?</h5>
-<!--l. 19--><p class="noindent" >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><!--l. 24--><p class="noindent" >Bran Selic, Garth Gullekson and Paul T. Ward have published the concepts 1994 in the book <span
-class="ec-lmssbx-10">Real-Time</span>
-<span
-class="ec-lmssbx-10">Object-Oriented Modeling</span>. The company <span
-class="ec-lmsso-10">ObjecTime</span><sup class="textsuperscript"><span
-class="ec-lmss-9">TM</span></sup> developed a ROOM tool which was taken over by
-<span
-class="ec-lmsso-10">Rational SW</span><sup class="textsuperscript"><span
-class="ec-lmss-9">TM</span></sup> and later on by <span
-class="ec-lmsso-10">IBM</span><sup class="textsuperscript"><span
-class="ec-lmss-9">TM</span></sup>. The company <span
-class="ec-lmsso-10">Protos Software GmbH</span><sup class="textsuperscript"><span
-class="ec-lmss-9">TM</span></sup> also developed a ROOM
-tool called <span
-class="ec-lmsso-10">Trice</span><sup class="textsuperscript"><span
-class="ec-lmss-9">TM</span></sup> for control software for production machines and automotive systems. <span
-class="ec-lmsso-10">Trice</span><sup class="textsuperscript"><span
-class="ec-lmss-9">TM</span></sup> is the
-predecessor of eTrice (see Introduction to eTrice).
-</p><!--l. 32--><p class="noindent" >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><!--l. 36--><p class="noindent" >
-</p>
-<h5 class="subsubsectionHead"><a
- id="x5-90001.2.1"></a>Which kind of SW-Systems will be addressed?</h5>
-<!--l. 38--><p class="noindent" >As mentioned before ROOM addresses distributed, event driven, real time systems. But what is a <span
-class="ec-lmsso-10">real time</span>
-<span
-class="ec-lmsso-10">system</span>? ROOM defines a set of properties which are typical for a real time system. These properties
-are:
-</p>
- <ul class="itemize1">
- <li class="itemize">Timeliness
- </li>
- <li class="itemize">Dynamic internal structure
- </li>
- <li class="itemize">Reactiveness
- </li>
- <li class="itemize">Concurrency
-
-
- </li>
- <li class="itemize">Distribution
- </li>
- <li class="itemize">Reliability</li></ul>
-<!--l. 51--><p class="noindent" >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><!--l. 54--><p class="noindent" >As an example take a look at a washing machine. The system has to react to 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 within 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><!--l. 62--><p class="noindent" >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="ec-lmsso-10">run to completion </span>context for calculating an image processing
-algorithm or a PID controller.
-</p><!--l. 68--><p class="noindent" >
-</p>
-<h5 class="subsubsectionHead"><a
- id="x5-100001.2.1"></a>What is the relation between OOP and ROOM?</h5>
-<!--l. 70--><p class="noindent" >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. The classical 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><!--l. 75--><p class="noindent" >But 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><!--l. 79--><p class="noindent" ><img
-src="images/010-RoomIntroduction02.png" alt="PIC"
- />
-</p><!--l. 81--><p class="noindent" >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 <span
-class="ec-lmsso-10">run to completion </span>semantics. That makes
-developing of business logic easy and safe (see <a
-href="#x5-130001.2.2">1.2.2<!--tex4ht:ref: sec:basic_concepts --></a> <a
-href="#x5-130001.2.2">Basic Concepts<!--tex4ht:ref: sec:basic_concepts --></a>). The logical machine provides an
-encapsulation shell including concurrency issues (see <a
-href="#x5-170001.2.2">1.2.2<!--tex4ht:ref: sec:run_to_completion --></a> <a
-href="#x5-170001.2.2">Run to Completion<!--tex4ht:ref: sec:run_to_completion --></a>).
-</p><!--l. 86--><p class="noindent" ><img
-src="images/010-RoomIntroduction03.png" alt="PIC"
- />
-</p><!--l. 88--><p class="noindent" >This thinking of an object is much more general than the classic one.
-</p><!--l. 90--><p class="noindent" >
-</p>
-<h5 class="subsubsectionHead"><a
- id="x5-110001.2.1"></a>What are the benefits of ROOM?</h5>
-<!--l. 92--><p class="noindent" >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><!--l. 97--><p class="noindent" >In detail: </p>
-
-
- <ul class="itemize1">
- <li class="itemize">ROOM models contain well defined interfaces (protocols), which makes it easy to re-use
- components in different applications or e.g. in a test harness.
- </li>
- <li class="itemize">Graphical modeling makes it easy to understand, maintain and share code with other developers
- </li>
- <li class="itemize">Higher abstraction in combination with automated code generation provides very efficient
- mechanisms to the developer.
- </li>
- <li class="itemize">ROOM provides graphical model execution, which makes it easy to understand the application or
- find defects in a very early phase.</li></ul>
-<!--l. 108--><p class="noindent" >
-</p>
-<h5 class="subsubsectionHead"><a
- id="x5-120001.2.1"></a>Which consequences must be taken into account?</h5>
-<!--l. 110--><p class="noindent" >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><!--l. 116--><p class="noindent" >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><!--l. 119--><p class="noindent" >
-</p>
-<h4 class="subsectionHead"><span class="titlemark">1.2.2 </span> <a
- id="x5-130001.2.2"></a>Basic Concepts</h4>
-<!--l. 122--><p class="noindent" >
-</p>
-<h5 class="subsubsectionHead"><a
- id="x5-140001.2.2"></a>Actor, Port, Protocol</h5>
-<!--l. 124--><p class="noindent" >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 actor’s behavior (state machine) or will be delegated to the actor’s internal
-structure.
-</p>
-<div class="table">
-
-
-<!--l. 132--><p class="noindent" ><a
- id="x5-140011"></a></p><hr class="float" /><div class="float"
->
-
-
- <div class="caption"
-><span class="id">Table 1.1: </span><span
-class="content">Actor and Protocol Class Example</span></div><!--tex4ht:label?: x5-140011 -->
-<div class="tabular"> <table id="TBL-2" class="tabular"
-cellspacing="0" cellpadding="0" rules="groups"
-><colgroup id="TBL-2-1g"><col
-id="TBL-2-1" /></colgroup><colgroup id="TBL-2-2g"><col
-id="TBL-2-2" /></colgroup><tr
-class="hline"><td><hr /></td><td><hr /></td></tr><tr
- style="vertical-align:baseline;" id="TBL-2-1-"><td style="white-space:nowrap; text-align:left;" id="TBL-2-1-1"
-class="td11"> <img
-src="images/040-ActorClass.png" alt="PIC"
- /> </td><td style="white-space:nowrap; text-align:left;" id="TBL-2-1-2"
-class="td11"> <img
-src="images/040-ProtocolClassTextualNotation.png" alt="PIC"
- /> </td>
-</tr><tr
-class="hline"><td><hr /></td><td><hr /></td></tr><tr
- style="vertical-align:baseline;" id="TBL-2-2-"><td style="white-space:nowrap; text-align:left;" id="TBL-2-2-1"
-class="td11"> <span
-class="ec-lmssbx-10">Actor with sub actors </span></td><td style="white-space:nowrap; text-align:left;" id="TBL-2-2-2"
-class="td11"> <span
-class="ec-lmssbx-10">Protocol definition </span></td>
-</tr><tr
-class="hline"><td><hr /></td><td><hr /></td></tr><tr
- style="vertical-align:baseline;" id="TBL-2-3-"><td style="white-space:nowrap; text-align:left;" id="TBL-2-3-1"
-class="td11"> </td></tr></table>
-</div>
-
-
-</div><hr class="endfloat" />
-</div>
-<!--l. 140--><p class="noindent" >The actor provides access protection for its own attributes (including complex types, i.e. 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 re-usability on the actor level and provides an effective and safe programming model to the
-developer.
-</p><!--l. 145--><p class="noindent" >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><!--l. 149--><p class="noindent" >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>
-<h5 class="subsubsectionHead"><a
- id="x5-150001.2.2"></a>Hierarchy in Structure and Behavior</h5>
-<!--l. 156--><p class="noindent" >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><!--l. 162--><p class="noindent" >The actor’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><!--l. 166--><p class="noindent" >Top level:
-</p><!--l. 168--><p class="noindent" ><img
-src="images/020-Blinky15.png" alt="PIC"
- />
-</p><!--l. 170--><p class="noindent" ><span
-class="ec-lmsso-10">blinking </span>Sub machine:
-</p><!--l. 172--><p class="noindent" ><img
-src="images/020-Blinky151.png" alt="PIC"
- />
-</p><!--l. 174--><p class="noindent" >From an abstract point of view there is a state <span
-class="ec-lmsso-10">blinking</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><!--l. 179--><p class="noindent" >This simple example might give an idea how powerful this mechanisms is.
-</p><!--l. 181--><p class="noindent" >The hierarchical FSM provides a rich tool box to describe real world problems (see chapter <a
-href="etrice-docch7.html#x35-790007">7<!--tex4ht:ref: sec:room_concepts --></a> <a
-href="etrice-docch7.html#x35-790007">ROOM
-Concepts<!--tex4ht:ref: sec:room_concepts --></a>).
-</p><!--l. 183--><p class="noindent" >
-</p>
-<h5 class="subsubsectionHead"><a
- id="x5-160001.2.2"></a>Layering</h5>
-<!--l. 185--><p class="noindent" >Layering is another well known form of abstraction to reduce complexity in the structure of systems. ROOM is
-probably the only language that supports layering directly as a language feature. Layering can be expressed in
-ROOM by actors with specialized ports, called <span
-class="ec-lmsso-10">Service Access Points </span>(SAP) and <span
-class="ec-lmsso-10">Service Provision Points</span>
-(SPP).
-</p><!--l. 190--><p class="noindent" >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 actor’s point of view, SAPs and SPPs behave almost like
-
-
-ports.
-</p><!--l. 194--><p class="noindent" ><img
-src="images/010-LayerExample.png" alt="PIC"
- />
-</p><!--l. 196--><p class="noindent" >The example shows a layered model. The layer connections define e.g. that the <span
-class="ec-lmsso-10">ApplicationLayer </span>can only use
-the services of the <span
-class="ec-lmsso-10">ServiceLayer </span>and the <span
-class="ec-lmsso-10">CommunicationLayer</span>. Actors inside the <span
-class="ec-lmsso-10">ApplicationLayer</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><!--l. 202--><p class="noindent" >
-</p>
-<h5 class="subsubsectionHead"><a
- id="x5-170001.2.2"></a>Run to Completion</h5>
-<!--l. 205--><p class="noindent" ><span
-class="ec-lmsso-10">Run to completion </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’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="ec-lmsso-10">run to completion </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 by the
-underlying run time system.
-</p><!--l. 213--><p class="noindent" >Note: It is very important not to confuse <span
-class="ec-lmsso-10">run to completion </span>and <span
-class="ec-lmsso-10">cooperative multi threading</span>. 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 <span
-class="ec-lmsso-10">not </span>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><!--l. 220--><p class="noindent" >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 into several actors
-without the risk to produce access violations or dead locks.
-</p><!--l. 225--><p class="noindent" >
-</p>
-<h4 class="subsectionHead"><span class="titlemark">1.2.3 </span> <a
- id="x5-180001.2.3"></a>Execution Models</h4>
-<!--l. 227--><p class="noindent" >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
-<span
-class="ec-lmsso-10">execution model</span>. Currently the eTrice tooling supports the <span
-class="ec-lmssbx-10">message driven</span>, the <span
-class="ec-lmssbx-10">data driven </span>and a mixture of
-both execution models. In future releases maybe also a synchronous execution model will be supported,
-depending on the requirements of the community.
-</p><!--l. 235--><p class="noindent" >
-</p>
-<h5 class="subsubsectionHead"><a
- id="x5-190001.2.3"></a>Communication Methods</h5>
- <ul class="itemize1">
- <li class="itemize"><span
-class="ec-lmssbx-10">message driven </span>– asynchronous, non blocking, no return value:<br
-class="newline" />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.
-
-
- </li>
- <li class="itemize"><span
-class="ec-lmssbx-10">data driven </span>– asynchronous, non blocking, no return value:<br
-class="newline" />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.
- </li>
- <li class="itemize"><span
-class="ec-lmssbx-10">function call </span>– synchronous, blocking, return value:<br
-class="newline" />Regular function call as known in most programming languages.</li></ul>
-<!--l. 251--><p class="noindent" >eTrice currently supports the two former communication methods.
-</p><!--l. 253--><p class="noindent" >
-</p>
-<h5 class="subsubsectionHead"><a
- id="x5-200001.2.3"></a>Execution Methods</h5>
- <ul class="itemize1">
- <li class="itemize"><span
-class="ec-lmssbx-10">execution by receive event</span>: The message queue or the event dispatcher calls a <span
-class="ec-lmssbx-10">receive event</span>
- function of the message receiver and thereby executes the processing of the event.
- </li>
- <li class="itemize"><span
-class="ec-lmssbx-10">polled execution</span>: The objects are processed by a cyclic <span
-class="ec-lmssbx-10">execute </span>call
- </li>
- <li class="itemize"><span
-class="ec-lmssbx-10">execution by function call</span>: The caller executes the called object via function call</li></ul>
-<!--l. 262--><p class="noindent" >eTrice currently supports the two former execution methods.
-</p><!--l. 264--><p class="noindent" >
-</p>
-<h5 class="subsubsectionHead"><a
- id="x5-210001.2.3"></a>Execution Models</h5>
-<!--l. 266--><p class="noindent" >In present-day’s embedded systems in most cases one or several of the following execution models are
-used:
-</p>
-<!--l. 268--><p class="noindent" ><span class="paragraphHead"><a
- id="x5-220001.2.3"></a><span
-class="ec-lmssbx-10">message driven</span></span>
-<br
-class="newline" />
-</p><!--l. 270--><p class="noindent" >The message driven execution model is a combination of message driven communication and execution by
-receive event. This model allows for distributed systems with a very high throughput. It can be deterministic
-but the determinism is hard to proof. This execution model is often found in telecommunication systems and
-high performance automation control systems.
-</p>
-<!--l. 277--><p class="noindent" ><span class="paragraphHead"><a
- id="x5-230001.2.3"></a><span
-class="ec-lmssbx-10">data driven</span></span>
-<br
-class="newline" />
-
-
-</p><!--l. 279--><p class="noindent" >The data driven execution model is a combination of data driven communication and polled execution. This
-model is highly deterministic and very robust, but the polling creates a huge performance overhead. The
-determinism is easy to proof (simple mathematics). The execution model is also compatible with the
-execution model of control software generated by Tools like Matlab(TM) and LabView(TM). This
-model is usually used for systems with requirements for safety, such as automotive and avionic
-systems.
-</p>
-<!--l. 286--><p class="noindent" ><span class="paragraphHead"><a
- id="x5-240001.2.3"></a><span
-class="ec-lmssbx-10">synchronous</span></span>
-<br
-class="newline" />
-</p><!--l. 288--><p class="noindent" >The synchronous execution model could also be called <span
-class="ec-lmsso-10">function calls</span>. This model in general is not very well
-suited to support the <span
-class="ec-lmsso-10">run to completion </span>semantics typical for ROOM models, but could also be generated from
-ROOM models. With this execution model also lower levels of a software system, such as device drivers, could
-be generated from ROOM models.
-
-
-</p>
-<!--l. 59--><div class="crosslinks"><p class="noindent">[<a
-href="etrice-docch2.html" >next</a>] [<a
-href="etrice-docse1.html" >prev</a>] [<a
-href="etrice-docse1.html#tailetrice-docse1.html" >prev-tail</a>] [<a
-href="etrice-docse2.html" >front</a>] [<a
-href="etrice-docch1.html#etrice-docse2.html" >up</a>] </p></div>
-<!--l. 59--><p class="noindent" ><a
- id="tailetrice-docse2.html"></a> </p>
-</body></html>
+<?xml version="1.0" encoding="iso-8859-1" ?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> +<!--http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd--> +<html xmlns="http://www.w3.org/1999/xhtml" +> +<head><title>Introduction to the ROOM Language</title> +<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> +<meta name="generator" content="TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)" /> +<meta name="originator" content="TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)" /> +<!-- xhtml,3,next,html --> +<meta name="src" content="etrice-doc.tex" /> +<meta name="date" content="2013-07-04 15:04:00" /> +<link rel="stylesheet" type="text/css" href="etrice-doc.css" /> +</head><body +> +<!--l. 1--><div class="crosslinks"><p class="noindent">[<a +href="etrice-docch2.html" >next</a>] [<a +href="etrice-docse1.html" >prev</a>] [<a +href="etrice-docse1.html#tailetrice-docse1.html" >prev-tail</a>] [<a +href="#tailetrice-docse2.html">tail</a>] [<a +href="etrice-docch1.html#etrice-docse2.html" >up</a>] </p></div> +<h3 class="sectionHead"><span class="titlemark">1.2 </span> <a + id="x5-60001.2"></a>Introduction to the ROOM Language</h3> +<!--l. 3--><p class="noindent" > +</p> +<h4 class="subsectionHead"><span class="titlemark">1.2.1 </span> <a + id="x5-70001.2.1"></a>Scope of ROOM</h4> +<!--l. 5--><p class="noindent" >This chapter will give a rough overview of what ROOM (<span +class="ec-lmssbx-10">R</span>eal-time <span +class="ec-lmssbx-10">O</span>bject-<span +class="ec-lmssbx-10">O</span>riented <span +class="ec-lmssbx-10">M</span>odeling) is and what it +is good for. It will try to answer the following questions: +</p> + + + <ul class="itemize1"> + <li class="itemize">Where does it come from? + </li> + <li class="itemize">Which kind of SW-Systems will be addressed? + </li> + <li class="itemize">What is the relation between object oriented programming and ROOM? + </li> + <li class="itemize">What are the benefits of ROOM? + </li> + <li class="itemize">Which consequences must be taken into account?</li></ul> +<!--l. 17--><p class="noindent" > +</p> +<h5 class="subsubsectionHead"><a + id="x5-80001.2.1"></a>Where does it come from?</h5> +<!--l. 19--><p class="noindent" >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><!--l. 24--><p class="noindent" >Bran Selic, Garth Gullekson and Paul T. Ward have published the concepts 1994 in the book <span +class="ec-lmssbx-10">Real-Time</span> +<span +class="ec-lmssbx-10">Object-Oriented Modeling</span>. The company <span +class="ec-lmsso-10">ObjecTime</span><sup class="textsuperscript"><span +class="ec-lmss-9">TM</span></sup> developed a ROOM tool which was taken over by +<span +class="ec-lmsso-10">Rational SW</span><sup class="textsuperscript"><span +class="ec-lmss-9">TM</span></sup> and later on by <span +class="ec-lmsso-10">IBM</span><sup class="textsuperscript"><span +class="ec-lmss-9">TM</span></sup>. The company <span +class="ec-lmsso-10">Protos Software GmbH</span><sup class="textsuperscript"><span +class="ec-lmss-9">TM</span></sup> also developed a ROOM +tool called <span +class="ec-lmsso-10">Trice</span><sup class="textsuperscript"><span +class="ec-lmss-9">TM</span></sup> for control software for production machines and automotive systems. <span +class="ec-lmsso-10">Trice</span><sup class="textsuperscript"><span +class="ec-lmss-9">TM</span></sup> is the +predecessor of eTrice (see Introduction to eTrice). +</p><!--l. 32--><p class="noindent" >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><!--l. 36--><p class="noindent" > +</p> +<h5 class="subsubsectionHead"><a + id="x5-90001.2.1"></a>Which kind of SW-Systems will be addressed?</h5> +<!--l. 38--><p class="noindent" >As mentioned before ROOM addresses distributed, event driven, real time systems. But what is a <span +class="ec-lmsso-10">real time</span> +<span +class="ec-lmsso-10">system</span>? ROOM defines a set of properties which are typical for a real time system. These properties +are: +</p> + <ul class="itemize1"> + <li class="itemize">Timeliness + </li> + <li class="itemize">Dynamic internal structure + </li> + <li class="itemize">Reactiveness + </li> + <li class="itemize">Concurrency + + + </li> + <li class="itemize">Distribution + </li> + <li class="itemize">Reliability</li></ul> +<!--l. 51--><p class="noindent" >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><!--l. 54--><p class="noindent" >As an example take a look at a washing machine. The system has to react to 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 within 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><!--l. 62--><p class="noindent" >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="ec-lmsso-10">run to completion </span>context for calculating an image processing +algorithm or a PID controller. +</p><!--l. 68--><p class="noindent" > +</p> +<h5 class="subsubsectionHead"><a + id="x5-100001.2.1"></a>What is the relation between OOP and ROOM?</h5> +<!--l. 70--><p class="noindent" >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. The classical 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><!--l. 75--><p class="noindent" >But 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><!--l. 79--><p class="noindent" ><img +src="images/010-RoomIntroduction02.png" alt="PIC" + /> +</p><!--l. 81--><p class="noindent" >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 <span +class="ec-lmsso-10">run to completion </span>semantics. That makes +developing of business logic easy and safe (see <a +href="#x5-130001.2.2">1.2.2<!--tex4ht:ref: sec:basic_concepts --></a> <a +href="#x5-130001.2.2">Basic Concepts<!--tex4ht:ref: sec:basic_concepts --></a>). The logical machine provides an +encapsulation shell including concurrency issues (see <a +href="#x5-170001.2.2">1.2.2<!--tex4ht:ref: sec:run_to_completion --></a> <a +href="#x5-170001.2.2">Run to Completion<!--tex4ht:ref: sec:run_to_completion --></a>). +</p><!--l. 86--><p class="noindent" ><img +src="images/010-RoomIntroduction03.png" alt="PIC" + /> +</p><!--l. 88--><p class="noindent" >This thinking of an object is much more general than the classic one. +</p><!--l. 90--><p class="noindent" > +</p> +<h5 class="subsubsectionHead"><a + id="x5-110001.2.1"></a>What are the benefits of ROOM?</h5> +<!--l. 92--><p class="noindent" >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><!--l. 97--><p class="noindent" >In detail: </p> + + + <ul class="itemize1"> + <li class="itemize">ROOM models contain well defined interfaces (protocols), which makes it easy to re-use + components in different applications or e.g. in a test harness. + </li> + <li class="itemize">Graphical modeling makes it easy to understand, maintain and share code with other developers + </li> + <li class="itemize">Higher abstraction in combination with automated code generation provides very efficient + mechanisms to the developer. + </li> + <li class="itemize">ROOM provides graphical model execution, which makes it easy to understand the application or + find defects in a very early phase.</li></ul> +<!--l. 108--><p class="noindent" > +</p> +<h5 class="subsubsectionHead"><a + id="x5-120001.2.1"></a>Which consequences must be taken into account?</h5> +<!--l. 110--><p class="noindent" >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><!--l. 116--><p class="noindent" >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><!--l. 119--><p class="noindent" > +</p> +<h4 class="subsectionHead"><span class="titlemark">1.2.2 </span> <a + id="x5-130001.2.2"></a>Basic Concepts</h4> +<!--l. 122--><p class="noindent" > +</p> +<h5 class="subsubsectionHead"><a + id="x5-140001.2.2"></a>Actor, Port, Protocol</h5> +<!--l. 124--><p class="noindent" >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 actor’s behavior (state machine) or will be delegated to the actor’s internal +structure. +</p> +<div class="table"> + + +<!--l. 132--><p class="noindent" ><a + id="x5-140011"></a></p><hr class="float" /><div class="float" +> + + + <div class="caption" +><span class="id">Table 1.1: </span><span +class="content">Actor and Protocol Class Example</span></div><!--tex4ht:label?: x5-140011 --> +<div class="tabular"> <table id="TBL-2" class="tabular" +cellspacing="0" cellpadding="0" rules="groups" +><colgroup id="TBL-2-1g"><col +id="TBL-2-1" /></colgroup><colgroup id="TBL-2-2g"><col +id="TBL-2-2" /></colgroup><tr +class="hline"><td><hr /></td><td><hr /></td></tr><tr + style="vertical-align:baseline;" id="TBL-2-1-"><td style="white-space:nowrap; text-align:left;" id="TBL-2-1-1" +class="td11"> <img +src="images/040-ActorClass.png" alt="PIC" + /> </td><td style="white-space:nowrap; text-align:left;" id="TBL-2-1-2" +class="td11"> <img +src="images/040-ProtocolClassTextualNotation.png" alt="PIC" + /> </td> +</tr><tr +class="hline"><td><hr /></td><td><hr /></td></tr><tr + style="vertical-align:baseline;" id="TBL-2-2-"><td style="white-space:nowrap; text-align:left;" id="TBL-2-2-1" +class="td11"> <span +class="ec-lmssbx-10">Actor with sub actors </span></td><td style="white-space:nowrap; text-align:left;" id="TBL-2-2-2" +class="td11"> <span +class="ec-lmssbx-10">Protocol definition </span></td> +</tr><tr +class="hline"><td><hr /></td><td><hr /></td></tr><tr + style="vertical-align:baseline;" id="TBL-2-3-"><td style="white-space:nowrap; text-align:left;" id="TBL-2-3-1" +class="td11"> </td></tr></table> +</div> + + +</div><hr class="endfloat" /> +</div> +<!--l. 140--><p class="noindent" >The actor provides access protection for its own attributes (including complex types, i.e. 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 re-usability on the actor level and provides an effective and safe programming model to the +developer. +</p><!--l. 145--><p class="noindent" >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><!--l. 149--><p class="noindent" >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> +<h5 class="subsubsectionHead"><a + id="x5-150001.2.2"></a>Hierarchy in Structure and Behavior</h5> +<!--l. 156--><p class="noindent" >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><!--l. 162--><p class="noindent" >The actor’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><!--l. 166--><p class="noindent" >Top level: +</p><!--l. 168--><p class="noindent" ><img +src="images/020-Blinky15.png" alt="PIC" + /> +</p><!--l. 170--><p class="noindent" ><span +class="ec-lmsso-10">blinking </span>Sub machine: +</p><!--l. 172--><p class="noindent" ><img +src="images/020-Blinky151.png" alt="PIC" + /> +</p><!--l. 174--><p class="noindent" >From an abstract point of view there is a state <span +class="ec-lmsso-10">blinking</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><!--l. 179--><p class="noindent" >This simple example might give an idea how powerful this mechanisms is. +</p><!--l. 181--><p class="noindent" >The hierarchical FSM provides a rich tool box to describe real world problems (see chapter <a +href="etrice-docch4.html#x18-720004">4<!--tex4ht:ref: sec:room_concepts --></a> <a +href="etrice-docch4.html#x18-720004">ROOM +Concepts<!--tex4ht:ref: sec:room_concepts --></a>). +</p><!--l. 183--><p class="noindent" > +</p> +<h5 class="subsubsectionHead"><a + id="x5-160001.2.2"></a>Layering</h5> +<!--l. 185--><p class="noindent" >Layering is another well known form of abstraction to reduce complexity in the structure of systems. ROOM is +probably the only language that supports layering directly as a language feature. Layering can be expressed in +ROOM by actors with specialized ports, called <span +class="ec-lmsso-10">Service Access Points </span>(SAP) and <span +class="ec-lmsso-10">Service Provision Points</span> +(SPP). +</p><!--l. 190--><p class="noindent" >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 actor’s point of view, SAPs and SPPs behave almost like + + +ports. +</p><!--l. 194--><p class="noindent" ><img +src="images/010-LayerExample.png" alt="PIC" + /> +</p><!--l. 196--><p class="noindent" >The example shows a layered model. The layer connections define e.g. that the <span +class="ec-lmsso-10">ApplicationLayer </span>can only use +the services of the <span +class="ec-lmsso-10">ServiceLayer </span>and the <span +class="ec-lmsso-10">CommunicationLayer</span>. Actors inside the <span +class="ec-lmsso-10">ApplicationLayer</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><!--l. 202--><p class="noindent" > +</p> +<h5 class="subsubsectionHead"><a + id="x5-170001.2.2"></a>Run to Completion</h5> +<!--l. 205--><p class="noindent" ><span +class="ec-lmsso-10">Run to completion </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’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="ec-lmsso-10">run to completion </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 by the +underlying run time system. +</p><!--l. 213--><p class="noindent" >Note: It is very important not to confuse <span +class="ec-lmsso-10">run to completion </span>and <span +class="ec-lmsso-10">cooperative multi threading</span>. 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 <span +class="ec-lmsso-10">not </span>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><!--l. 220--><p class="noindent" >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 into several actors +without the risk to produce access violations or dead locks. +</p><!--l. 225--><p class="noindent" > +</p> +<h4 class="subsectionHead"><span class="titlemark">1.2.3 </span> <a + id="x5-180001.2.3"></a>Execution Models</h4> +<!--l. 227--><p class="noindent" >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 +<span +class="ec-lmsso-10">execution model</span>. Currently the eTrice tooling supports the <span +class="ec-lmssbx-10">message driven</span>, the <span +class="ec-lmssbx-10">data driven </span>and a mixture of +both execution models. In future releases maybe also a synchronous execution model will be supported, +depending on the requirements of the community. +</p><!--l. 235--><p class="noindent" > +</p> +<h5 class="subsubsectionHead"><a + id="x5-190001.2.3"></a>Communication Methods</h5> + <ul class="itemize1"> + <li class="itemize"><span +class="ec-lmssbx-10">message driven </span>– asynchronous, non blocking, no return value:<br +class="newline" />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. + + + </li> + <li class="itemize"><span +class="ec-lmssbx-10">data driven </span>– asynchronous, non blocking, no return value:<br +class="newline" />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. + </li> + <li class="itemize"><span +class="ec-lmssbx-10">function call </span>– synchronous, blocking, return value:<br +class="newline" />Regular function call as known in most programming languages.</li></ul> +<!--l. 251--><p class="noindent" >eTrice currently supports the two former communication methods. +</p><!--l. 253--><p class="noindent" > +</p> +<h5 class="subsubsectionHead"><a + id="x5-200001.2.3"></a>Execution Methods</h5> + <ul class="itemize1"> + <li class="itemize"><span +class="ec-lmssbx-10">execution by receive event</span>: The message queue or the event dispatcher calls a <span +class="ec-lmssbx-10">receive event</span> + function of the message receiver and thereby executes the processing of the event. + </li> + <li class="itemize"><span +class="ec-lmssbx-10">polled execution</span>: The objects are processed by a cyclic <span +class="ec-lmssbx-10">execute </span>call + </li> + <li class="itemize"><span +class="ec-lmssbx-10">execution by function call</span>: The caller executes the called object via function call</li></ul> +<!--l. 262--><p class="noindent" >eTrice currently supports the two former execution methods. +</p><!--l. 264--><p class="noindent" > +</p> +<h5 class="subsubsectionHead"><a + id="x5-210001.2.3"></a>Execution Models</h5> +<!--l. 266--><p class="noindent" >In present-day’s embedded systems in most cases one or several of the following execution models are +used: +</p> +<!--l. 268--><p class="noindent" ><span class="paragraphHead"><a + id="x5-220001.2.3"></a><span +class="ec-lmssbx-10">message driven</span></span> +<br +class="newline" /> +</p><!--l. 270--><p class="noindent" >The message driven execution model is a combination of message driven communication and execution by +receive event. This model allows for distributed systems with a very high throughput. It can be deterministic +but the determinism is hard to proof. This execution model is often found in telecommunication systems and +high performance automation control systems. +</p> +<!--l. 277--><p class="noindent" ><span class="paragraphHead"><a + id="x5-230001.2.3"></a><span +class="ec-lmssbx-10">data driven</span></span> +<br +class="newline" /> + + +</p><!--l. 279--><p class="noindent" >The data driven execution model is a combination of data driven communication and polled execution. This +model is highly deterministic and very robust, but the polling creates a huge performance overhead. The +determinism is easy to proof (simple mathematics). The execution model is also compatible with the +execution model of control software generated by Tools like Matlab(TM) and LabView(TM). This +model is usually used for systems with requirements for safety, such as automotive and avionic +systems. +</p> +<!--l. 286--><p class="noindent" ><span class="paragraphHead"><a + id="x5-240001.2.3"></a><span +class="ec-lmssbx-10">synchronous</span></span> +<br +class="newline" /> +</p><!--l. 288--><p class="noindent" >The synchronous execution model could also be called <span +class="ec-lmsso-10">function calls</span>. This model in general is not very well +suited to support the <span +class="ec-lmsso-10">run to completion </span>semantics typical for ROOM models, but could also be generated from +ROOM models. With this execution model also lower levels of a software system, such as device drivers, could +be generated from ROOM models. + + +</p> +<!--l. 59--><div class="crosslinks"><p class="noindent">[<a +href="etrice-docch2.html" >next</a>] [<a +href="etrice-docse1.html" >prev</a>] [<a +href="etrice-docse1.html#tailetrice-docse1.html" >prev-tail</a>] [<a +href="etrice-docse2.html" >front</a>] [<a +href="etrice-docch1.html#etrice-docse2.html" >up</a>] </p></div> +<!--l. 59--><p class="noindent" ><a + id="tailetrice-docse2.html"></a> </p> +</body></html> |