Pleading for open modular architectures - Lirmm

More documents

Recommendations

Info

First National Workshop on Control Architectures of Robots - April 6,7 2006 - Montpellier - the hardware description phase (graphs of nodes, communication networks) allows to define operating system (OS) resources available to execute components, - the component placement phase allows to define the different OS processes (named containers) executing one or more control components and to define the scheduling of these processes on each node. At the deployment stage, configurations incorporate the description used to install and configure components. This mechanism allows to treat the deployment of an architecture independently of the control behaviour it defines. We chose to treat the organization of a control architecture into layers (hierarchy) during the deployment phase. A container is the unity that is useful to (parts of) layer’s description. The relationships between layers are translated into container execution configuration: container’s process execution priorities are set depending on layer’s relationship (the upper is the layer represented by the container, the higher is its priority of reaction). One future research is to find a multi-criteria scheduling algorithm (dealing with temporal constraints in addition to containers priorities) which will be more adapted to the management of layers hierarchy, in order to ensure maximal reactivity of low layers without sacrificing pre-emption of upper layers. IV. DEPLOYMENT & EXECUTION MODEL The CoSARC language is not only a design but also a programming language. Then, it needs a framework to execute components. This framework is a middleware application that runs on top of an OS. It provides standardized access to OS functionalities, and a set of functionalities specific to the CoSARC components execution. It is also in charge of configuration deployment (i.e. the deployment of control components and connectors corresponding to the description made) by creating containers and by managing their scheduling on each processing node. Threaded Threaded Operation Threaded Operation Operation parallel operation programming token emission operation ending events Token Player Interaction Engine time events token reception Figure 7: Container’s internal structure Timer Timer Timer timer programming A container is in charge of the execution of a set of control components and the set of all the roles played by these components. Any number of control components and roles can be placed into one container, and many containers can be deployed on the same processing node. It supports OPN execution and roles communications by the mean of two software processes that interact with an asynchronous communication model (Fig. 7): the Token Player (TP) and the Interaction 156
First National Workshop on Control Architectures of Robots - April 6,7 2006 - Montpellier Engine (IE). The TP is a kind of OPN inference engine that executes the byte code in which is compiled the OPN resulting from the composition of all the asynchronous behaviours of roles and control components contained in the container. During its execution, it can program threads for parallel operation execution and timers for timed transition management. During execution, the TP communicates with the Interaction Engine (IE) for emission and reception of external messages. The IE manages run-time communications of control components that are contained in the corresponding container. These communications between control components are configured depending on the connection of the roles they play. At run-time the IE of a given container exchanges messages with IE of others containers according to roles connection information. Given a container, its IE unpacks received messages to give corresponding tokens to the Token Player. And vice-versa its IE packs up tokens arriving from its TP to send the corresponding messages (Fig. 8). Figure 8: container communications In the next subsections we first present components deployment model and we focus on OPN execution mechanism in the second one. A. Deployment Model Overview Container Container TP Token Inference Token reception Token unpacking IE Message transmission The execution of CoSARC components is completely configured by their deployment. The description of configuration deployment is useful to describe precisely components execution issues. It is used to configure containers priorities, but it also helps determining where and how OPN are executed. The deployment is realized by the following steps: • The component placement step consists in creating each container on nodes and placing components code inside containers, corresponding to deployment description (Fig.6). • The role assignment step consists in defining where roles are executed. This is automatically deduced from the preceding step by applying the following rule: when a control component plays a role, this role is executed in the same container as the control component. Fig.9 shows that VehiclePositionCommand and RequesterRole are placed inside the same container. A connector can be then distributed among different containers. • The behaviour execution model definition step consists in producing a global OPN that will be executed by the TP. A container OPN model can be made of the disjoined union of the complete control component behaviour. A complete behaviour is an OPN model of the fusion of a control component’s and role’s asynchronous behaviours. This fusion is deduced from each connection between a control component and a role it plays: each place concerned with message exchanges, of a 157 Token Inference IE Token packing TP Token emission
Page 4 and 5:
Organization This first national wo
Page 6 and 7:
Contents Organization…………
Page 8 and 9:
Program April 6, 2006 8:30-9:00 Rec
Page 10 and 11:
First National Workshop on Control
Page 12 and 13:
Page 14 and 15:
1 User requirements defined 2 Syste
Page 16 and 17:
Page 18 and 19:
Page 20 and 21:
Page 22 and 23:
Page 24 and 25:
Page 26 and 27:
Page 28 and 29:
Figure 6. Interface for local map (
Page 30 and 31:
Figure 8. Map and robot trajectory
Page 32 and 33:
Page 34 and 35:
Page 36 and 37:
Page 38 and 39:
Decision Planning Navigation Guidan
Page 40 and 41:
Page 42 and 43:
• Three Petri nets model level 3:
Page 44 and 45:
Page 46 and 47:
Page 48 and 49:
Abstract First National Workshop on
Page 50 and 51:
eginning of the next one. A guidanc
Page 52 and 53:
Figure 5 - Supervision interface Fi
Page 54 and 55:
On-going tests First National Works
Page 56 and 57:
Page 58 and 59:
Page 60 and 61:
Page 62 and 63:
Page 64 and 65:
Page 66 and 67:
Page 68 and 69:
Page 70 and 71:
Page 72 and 73:
Page 74 and 75:
Page 76 and 77:
DES (Data Exchange System), a publi
Page 78 and 79:
Page 80 and 81:
Page 82 and 83:
Page 84 and 85:
Page 86 and 87:
Page 88 and 89:
Page 90 and 91:
Page 92 and 93:
Page 94 and 95:
Pilote Expérimenté:Télépilote F
Page 96 and 97:
Page 98 and 99:
Page 100 and 101:
A multi-level architecture controll
Page 102 and 103:
Page 104 and 105:
Page 106 and 107: The autonomous parts Basic levels F
Page 108 and 109: First National Workshop on Control
Page 110 and 111: cluster of the perception part of t
Page 118 and 119: An ultrasound probe of a sonographe
Page 120 and 121: Abstract First National Workshop on
Page 126 and 127: nombre de branches dans le parallé
Page 132 and 133: 2 The Orccad architecture 2.1 Basic
Page 140 and 141: 5.3 Real-time structures At compile
Page 142 and 143: From a software engineering perspec
Page 186 and 187: Stopped destination reached destina
Page 188 and 189: � ��
Page 192 and 193: Abstract Horocol language and Hardw
Page 196 and 197: • langage.xml which describe the
Page 198 and 199: Coordination programming in Horocol
Page 200 and 201: [F8] resume [F9] restart [F10] reev
Page 202 and 203: References First National Workshop
Page 206 and 207:
TABLE I PROBABILITY VALUES FOR PERC
Page 208 and 209:
show all

Pleading for open modular architectures - Lirmm

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?