4.2 eTrice Models and Their Relations

eTrice comprises several models:

In the following diagram the models and their relations are depicted. The meaning of the arrows is: uses/references.

PIC

In the following sections we will describe those models with emphasis of their cross relations.

4.2.1 The ROOM Model

The ROOM model defines DataClasses, ProtocolClasses, ActorClasses, SubSystemClasses and LogicalSystems. Thereby the three latter form a hierarchy. The LogicalSystem is the top level element of the structure. It contains references to SubSystemClass elements. The SubSystemClass in turn contains references to ActorClass elements which again contain (recursively) references to ActorClass elements. The complete structural hierarchy implies a tree which has the LogicalSystem as root and where each reference stands for a new node with possibly further branches.

Let’s consider a simple example. It doesn’t implement anything meaningful and completely omits behavioral and other aspects.

 
RoomModel test { 
 LogicalSystem Main { 
   SubSystemRef subA: SubA 
   SubSystemRef subB: SubB 
 } 
 
 SubSystemClass SubA { 
   ActorRef actA: ActA 
   ActorRef actB: ActB 
 
   LogicalThread dflt 
   LogicalThread extra 
   ActorInstanceMapping actA/actB1 -> extra { 
    ActorInstanceMapping actC1 -> dflt 
   } 
   ActorInstanceMapping actA/actB2 -> extra 
 } 
 
 SubSystemClass SubB { 
   ActorRef actA: ActA 
   ActorRef actB: ActB 
 
   LogicalThread dflt 
   LogicalThread extra 
   ActorInstanceMapping actB -> extra 
 } 
 
 ActorClass ActA { 
   Structure { 
    Attribute val: int 
    ActorRef actB1: ActB 
    ActorRef actB2: ActB 
   } 
 } 
 
 ActorClass ActB { 
   Structure { 
    Attribute val: int 
    ActorRef actC1: ActC 
    ActorRef actC2: ActC 
   } 
 } 
 
 ActorClass ActC {} 
 
 PrimitiveType int: ptInteger -> int (Integer) default "0" 
}
Listing 4.1: ROOM example code

When a LogicalSystem is instantiated then recursively all of the contained referenced elements are instantiated as instances of the corresponding class. Thus the instance tree of the above example looks like in figure 4.5 (the third line in the white boxes shows some mapping information, see section 4.2.4 The Mapping Model):


PIC

Figure 4.5: Instances of a ROOM system

4.2.2 The Config Model

Once we have the ROOM class model we can configure values using the Config model. This can be done on the class level and/or on the instance level. Values defined for class attributes are used for all instances unless there is an instance value configured for the same attribute.

 
ConfigModel test { 
 
 import test.* from "room-example.room" 
 
 ActorClassConfig ActA { 
   Attr val = 1 
 } 
 
 ActorClassConfig ActB { 
   Attr val = 2 
 } 
 
 ActorInstanceConfig Main/subA/actA { 
   Attr val = 12 
 } 
 
 ActorInstanceConfig Main/subA/actB { 
   Attr val = 13 
 } 
 
 ActorInstanceConfig Main/subA/actA/actB2 { 
   Attr val = 14 
 } 
}
Listing 4.2: Config example code

4.2.3 The Physical Model

The physical model defines the physical resources onto which the logical system will be deployed. It is possible to define runtime classes which (currently) only define the overall execution model of the platform.

 
PhysicalModel runtimes { 
 
 RuntimeClass PCRuntime { 
   model = multiThreaded 
 } 
 
 RuntimeClass MSP430Runtime { 
   model = singleThreaded 
 } 
}
Listing 4.3: etPhys runtime definition

The PhysicalSystem is composed of NodeReferences which are instances of NodeClasses. Each NodeClass is referencing a RuntimeClass and is defining Threads.

 
PhysicalModel test { 
 
 import test.* from "etphys-runtimes.etphys" 
 
 PhysicalSystem MainPhys { 
   NodeRef pc1: PC_Node 
   NodeRef pc2: PC_Node 
   NodeRef mc: MSP430_Node 
 } 
 
 NodeClass PC_Node { 
   runtime = runtimes.PCRuntime 
   priomin = 1 
   priomax = 10 
   DefaultThread thread1 { 
    execmode = blocked 
    prio = 10 
    stacksize = 1024 
    msgblocksize = 64 
    msgpoolsize = 50 
   } 
   Thread thread2 { 
    execmode = polled 
    interval = 1 ms 
    prio = 10 
    stacksize = 1024 
    msgblocksize = 64 
    msgpoolsize = 50 
   } 
 } 
 
 NodeClass MSP430_Node { 
   runtime = runtimes.MSP430Runtime 
   priomin = 1 
   priomax = 10 
   DefaultThread main { 
    execmode = polled 
    interval = 10 us 
    prio = 10 
    stacksize = 256 
    msgblocksize = 64 
    msgpoolsize = 50 
   } 
 } 
}
Listing 4.4: etPhys example code

4.2.4 The Mapping Model

The last model finally combines all this information by mapping logical to physical entities.

 
MappingModel test { 
 
 import test.* from "etphys-example.etphys" 
 import test.* from "room-example.room" 
 
 Mapping Main -> MainPhys { 
   SubSystemMapping subA -> pc1 { 
    ThreadMapping dflt -> thread1 
    ThreadMapping extra -> thread2 
   } 
   SubSystemMapping subB -> mc { 
    ThreadMapping dflt -> main 
    ThreadMapping extra -> main 
   } 
 } 
}
Listing 4.5: etMap example code

The result of the mapping is also depicted in above tree diagram (figure 4.5) of the instances. All actor instances (the white boxes) are mapped to a node and a thread running on this node (shown as @node : thread).