1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
|
<?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="2015-06-16 18:34: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-60002"></a>Introduction to the ROOM Language</h3>
<a
id="x5-6001r5"></a>
<h4 class="subsectionHead"><span class="titlemark">1.2.1 </span> <a
id="x5-70001"></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>
<a
id="Q1-5-8"></a>
<h5 class="likesubsubsectionHead"><a
id="x5-80001"></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 Object-Oriented</span>
<span
class="ec-lmssbx-10">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.
<a
id="Q1-5-10"></a>
</p>
<h5 class="likesubsubsectionHead"><a
id="x5-90001"></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 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.
<a
id="Q1-5-12"></a>
</p>
<h5 class="likesubsubsectionHead"><a
id="x5-100001"></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-130002">1.2.2<!--tex4ht:ref: sec:basic_concepts --></a> <a
href="#x5-130002">Basic Concepts<!--tex4ht:ref: sec:basic_concepts --></a>). The logical machine provides an encapsulation shell including concurrency issues (see
<a
href="#x5-170002">1.2.2<!--tex4ht:ref: sec:run_to_completion --></a> <a
href="#x5-170002">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.
<a
id="Q1-5-14"></a>
</p>
<h5 class="likesubsubsectionHead"><a
id="x5-110001"></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>
<a
id="Q1-5-16"></a>
<h5 class="likesubsubsectionHead"><a
id="x5-120001"></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.
<a
id="x5-12001r7"></a>
</p>
<h4 class="subsectionHead"><span class="titlemark">1.2.2 </span> <a
id="x5-130002"></a>Basic Concepts</h4>
<a
id="Q1-5-19"></a>
<h5 class="likesubsubsectionHead"><a
id="x5-140002"></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-14001r1"></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-14001r1 -->
<div class="tabular"> <table id="TBL-1" class="tabular"
cellspacing="0" cellpadding="0" rules="groups"
><colgroup id="TBL-1-1g"><col
id="TBL-1-1" /></colgroup><colgroup id="TBL-1-2g"><col
id="TBL-1-2" /></colgroup><tr
class="hline"><td><hr /></td><td><hr /></td></tr><tr
style="vertical-align:baseline;" id="TBL-1-1-"><td style="white-space:nowrap; text-align:left;" id="TBL-1-1-1"
class="td11"> <img
src="images/040-ActorClass.png" alt="PIC"
/> </td><td style="white-space:nowrap; text-align:left;" id="TBL-1-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-1-2-"><td style="white-space:nowrap; text-align:left;" id="TBL-1-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-1-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-1-3-"><td style="white-space:nowrap; text-align:left;" id="TBL-1-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.
<a
id="Q1-5-22"></a>
</p>
<h5 class="likesubsubsectionHead"><a
id="x5-150002"></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-docch5.html#x25-1050005">5<!--tex4ht:ref: sec:room_concepts --></a> <a
href="etrice-docch5.html#x25-1050005">ROOM Concepts<!--tex4ht:ref: sec:room_concepts --></a>).
<a
id="Q1-5-24"></a>
</p>
<h5 class="likesubsubsectionHead"><a
id="x5-160002"></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.
<a
id="Q1-5-26"></a>
</p>
<h5 class="likesubsubsectionHead"><a
id="x5-170002"></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.
<a
id="x5-17001r18"></a>
</p>
<h4 class="subsectionHead"><span class="titlemark">1.2.3 </span> <a
id="x5-180003"></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.
<a
id="Q1-5-29"></a>
</p>
<h5 class="likesubsubsectionHead"><a
id="x5-190003"></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.
<a
id="Q1-5-31"></a>
</p>
<h5 class="likesubsubsectionHead"><a
id="x5-200003"></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.
<a
id="Q1-5-33"></a>
</p>
<h5 class="likesubsubsectionHead"><a
id="x5-210003"></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:
<a
id="Q1-5-35"></a>
<span
class="ec-lmssbx-10">message driven </span><br
class="newline" />
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.
<a
id="Q1-5-36"></a>
<span
class="ec-lmssbx-10">data driven </span><br
class="newline" />
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.
<a
id="Q1-5-37"></a>
<span
class="ec-lmssbx-10">synchronous </span><br
class="newline" />
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. 93--><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>
<a
id="tailetrice-docse2.html"></a>
</body></html>
|
