| <?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-10-21 12:44: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 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. |
| </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 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-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. |
| </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#x23-990004">4<!--tex4ht:ref: sec:room_concepts --></a> <a |
| href="etrice-docch4.html#x23-990004">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. 77--><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. 77--><p class="noindent" ><a |
| id="tailetrice-docse2.html"></a> </p> |
| </body></html> |