Current Middleware Approaches and Paradigms

• System organization/decomposition - Player is a device server (application server) with the collection of dynamically loadable device shared libraries. The main portion of this server is custom communication protocol which enables client-server communication model. Player is implemented in C++ and uses POSIX compliant pthread interface for multithreaded applications. Player can be viewed as a multithreaded application server providing applications/services to client programs. Here application/services are devices which are used by client programs. Since devices (applications/services that is) can be loaded dynamically, Player can be considered as "some way in between monolithic application and modular middleware+services" approach. A main Player server thread listens to client side connections and spawns threads whenever the client program asks a service from some specific device. Each device (device program) has its own thread of execution. As can be seen from the figure 1, the threads communicate via a shared global address space. Each device has an associated command and data buffer. Whenever the client needs to access some specific device, it sends a command which is queued in a command buffer and then read by the device. The same applies to the data buffer: The device writes the data to the buffer and the client side program reads it. Since Player does not implement any device locking mechanism whenever multiple clients are connected to a Player server, one can overwrite the commands of other clients. This applies to commands and data (it is noteworthy to mention that data and commands are implemented as asynchronous one-way continuous streams) but not to configuration requests which can be used to access specific hardware features (this mechanism is implemented as a two-way synchronous request-reply interaction). One can also define the frequencies at which a particular device provides data to the client, by default this value is 10 Hz. Depending on the needs of a client data can be served in PUSH or PULL modes, by default the mode is PUSH, so server/devices send all data available to the client.

• Communication approach - Player , of current version, decomposed into two main parts: Player core, which is the core Player API, device drivers, driver loading code, configuration parsing code and driver registry. Transport layer, this part is independent of device drivers and can be any type of transport system, of current version it is implemented as two libraries, libplayertcp and libplayerxdr, and is based on TCP communication protocol using sockets (and message queues). Other transport types which can be used are JINI and CORBA based (means there is support for RMI and RPC).

• Platform/language support and other system features - Support for plugin drivers and simulation environments Stage and Gazebo. No device locking mechanism, client side data is always older than server side data because of the "buffer sit" times. Devices are treated as files with read/write access. Most of the devices adopt character device model. On the client side, programs communicate with server/devices through their respective local proxycies. There is no considerable support for fault tolerant capabilities. One of the features which can be accounted for is the “libplayererror” library, which can be used to perform error reporting. Also, there are some procedures to perform thread locking in order to avoid conflicts. Player is supported on most of the UNIX flavors and under Windows using Cygwin. Client programs can be written in any language providing socket mechanism, e.i. TCL, Python, C, C++, Java etc.

• Fault tolerance and robustness aspects: Though the Player project has been active for quite a long time, there have been no considerable developments to improve its fault tolerant capabilities. One of the features which can be accounted for is the libplayererror library, which can be used to perform error reporting. Also, there are some procedures to perform thread locking in order to avoid conflicts. From the perspective of robustness, it should be possible to implement planning, learning, state estimation or similar functionalities for an application based on Player. In the future the authors want to implement a resource awareness attribute, i.e. enable the programs to perform resource discovery and change their behavior according to the availability of resources.

• System organization/decomposition

Orca is an open-source framework for developing component-based robotic systems. Each component is typically a binary deployment unit and is a standalone process at runtime. Orca does not impose any architectural constraints on any individual component or the system as a whole.

• Communication

All inter-component communication in Orca2 is handled by Internet Communication Engine (Ice) from ZeroC. Ice is a general-purpose communication middleware. It is a contract-based middleware which requires that all interfaces are explicitly defined in an Interface Definition Language called Slice. These definitions serve as contracts between components at run-time, describing what services are provided by some components and required by others. Internally, Ice can be configured to use TCP, UDP, or SSL as transport mechanisms. Custom transport mechanisms can be added.

Earlier versions Orca supported several transport mechanisms (CORBA Ace/Tao and two custom comms libraries). The transition to using a single commercial general-purpose middleware was prompted by the difficulties of using CORBA and limitations of custom comms.

• OS and language support

In principle, Orca can be deployed as widely as CMake (the build system) and Ice (the comms middleware). Operating systems: Linux, MacOS X, several flavors of Windows. Programming languages: C++, Java, C#, Python and other. Note that there is no distinction between servers and clients in terms langauge/OS limitatations.

In practice, the majority of currently existing components are written in C++ are deployed on Linux. Some compile in Windows. There is example code in Java and Python.

• Fault tolerance and robustness aspects:

1. Automated interface stub generation
2. Automated marshalling/demarshalling
3. Remote Ice exception

• Utilities and Services

Orca extensively uses services shipped with Ice.

1. IceGrid Registry - centralized registry (naming service)
2. IceGrid Node - sophisticated software activation service
3. IceBox - application server
4. IceStorm - event service with publish/subscribe semantics
5. IcePatch2 - software distribution service

Orca distribution includes utilities written specifically for the robotic interfaces

1. 2D visualization GUI
2. Logging and log replaying
3. Remote debugging tools

• System organization/decomposition - MIRO uses an abstract machine model, i.e. the system is divided into several distinct layers, as depicted in figure [?????]. The higher layers can only access the lower layers via their interfaces. In case of MIRO, these layers are:

1. MIRO device layer - this layer provides classes to interface hardware and abstract the low level hardware details This classes enable access to hardware resources via simple procedure calls.
2. MIRO service layer - this layer provides service abstractions for sensors and actuators by means of the CORBA interface definition language (IDL). These services are implemented as network transparent objects/CORBA objects. The classes in this layer present the sensors and actuators as generic services. For example the RangeSensor class defines functionality common to the sensors which return range readings such as sonars, lidars and other type of range finders.
3. MIRO framework layer - on this level functional modules specific to robotics are provided. Examples are mapping, localization, path planning and similar facilities.

• Communication approach - For communication purposes MIRO relies on a TAO middleware C++ implementation of the CORBA standard. Subsystems/Objects communicate according to a client-server model, which is an example for a distribution model. With respect to the time properties both synchronous and asynchronous modes of communication are utilized. The system also supports event driven communication. Both push and pull models are used [????], [????], [????]. A comprehensive overview on the layout and accessibility of each respective layer is depicted in figure [?????]

• Platform/language support and other system features

• Fault tolerance and robustness aspects - MIRO does not provide any explicit fault tolerant capabilities on the system level, not considering the ones provided by the underlying middleware and the operating system (resource management, conflict resolution etc). There are some exception handling capabilities apart from the ones provided by the underlying middleware, though, and there is a list of MIRO exceptions which indicate hardware problems, service call failures or malfunction and load problems. In addition, a post- or predevelopment phase capability which may improve reliability of the software is a so-called “logging service” with several levels of notification. To increase the reliability of the software and minimize the number of errors, a partially automated code generation is provided. This comes automatically when using the IDL compiler, which helps to generate all the code for the communication and underlying middleware services. But again, most of the features mentioned are not part of the SIS itself but rather facilities it relies on. As defined in [????] robustness can be considered as the superset of fault tolerance and defined as the capability of handling adverse external conditions. The use of a BAP (behaviors, action patterns, policy) framework can contribute to the robustness of the applications based on MIRO. The BAP proposes ways of combining simple behaviors to form complex ones. The principle used for creating complex behavior hierarchies is similar to the finite state machine (FSM) principle, represented in figure [?????]. Action patterns, represented in figure [??????], are composed of behaviors and “guards” which can notify about some external event. Apart from this, the authors claim that a dynamic reconfiguration of policies is possible. This feature also may contribute to robustness. On the other hand, there are no implications whether it is possible to implement any planning or learning capabilities.

• System organization/decomposition -

OpenRDK is a modular software framework focused on rapid development of distributed robotic systems. It has been designed following users' advice and has been in use within our group for several years. By now OpenRDK has been successfully applied in diverse applications with heterogeneous robots and as we believe it is fruitfully usable by others we are releasing it as open source.

• In our framework the main entity is a software process called agent. A module is a single thread inside the agent process; modules can be loaded and started dynamically once the agent process is running. In the figure below we see an example. Two agents are executed on two different machines and three modules run inside them: hwInterface retrieves data from a laser range finder and the odometry from a robotic base; given this data, scanMatcher uses a scan-matching algorithm in order to estimate the robot positions over time; mapper uses the estimated robot positions, together with the laser scans, to build a map of the environment.
• An agent configuration is the list of which modules are instantiated, together with the values of their parameters and their interconnection layout. It is initially specified in a configuration file.

• Communication approach -

• Modules communicate using a blackboard-type object, called repository (see figure below), in which they publish some of their internal variables (parameters, inputs and outputs), called properties. A module defines its properties during initialization, after that, it can access its own and other modules' data, within the same agent or on other ones, through a global URL-like addressing scheme. Access to remote properties is transparent from a module perspective; on the other hand, it reduces to shared memory (OpenRDK provides easy built-ins for concurrency management) in the case of local properties.
• Special queue objects also reside in the repository and they share the same global URL-like addressing scheme of other properties.
• In the figure below, the hwInterface module pushes laser scan and odometry objects into queues, that are remotely accessed by the scanMatcher module, which, in turn, pushes the estimated poses in another queue, for the mapper to access to them. Finally, the mapper updates a property which contains a map.

• Tools -

OpenRDK comprises also RConsole (RDK Console), which allows for remote operations, inspection, parameter updates, etc.

• System organization/decomposition -

Marie is developed by the Mobile Robotics and Intelligent Systems Laboratory, University of Sherbrooke, Canada. As many systems so far described it is also based on component-oriented engineering approach to software. It advocates the idea of code reuse from already existing robotic projects. Up-to-date the following libraries/packages have been integrated into Marie: Player/Stage/Gazebo, FlowDesigner/RobotFlow, CARMEN/PMAP/Map Manager Library, Radish, ACE, MPICH2, ARIA/ARNL, libxml2, Qt/WxWidgets, Expression Toolkit, CPPUnit/MockPP.

Marie achieves abstractions and design concepts by adopting abstract machine approach (figure 10). But this more of developer perspective to a system. With respect to this, authors identify the following three layers:

1. Application layer - consists of integration tools to build applications using available components.
2. Component layer - consists of framework(s) used to implement components.
3. Core layer - consists of low level utilities for communication, data handling, I/O devices and OS related issues.

From the architectural perspective Marie uses Mediator Design Pattern (MDP) as the core design concept (figure 9). MDP creates a centralized control unit(mediator) which interacts with each application/component independently. Additionally mediator coordinates how these applications interact with each other. There are several advantages to using such design solution:

• It helps to decouple components, limiting interactions among them only through the mediator itself.
• It simplifies communication protocols, by reducing many-to-many relationship(which would be there among components) to one-to-many(between mediator and components). It also means that each application can use its own communication mechanism as long as the central control unit knows how to interact with it.
• It limits subclassing, to change the global behavior of the system one would modify only interactions between central control unit and the applications.

But there are also some drawbacks which are related to the usage of MDP (this will be discussed in comparison/evaluation section). To implement these design items Marie developers identified four main elements composing the core of Marie (Mediator unit also referred as Mediator Interoperability Layer(MIL) ). That is,

1. Application adapter (AA)- responsible for sending/receiving service requests and communication from MIL->applications and applications->MIL using application proxy. Each application should have its own AA. AAs encapsulate application specific communication mechanisms, services, configurations. Communication to other subcomponents of MIL/other application and an application is established through AA.
2. Communication adapter (CA) - responsible for converting data/info between different communication mechanisms. It allows different applications to exchange data correctly. The common types of communication adapters are:
   • Mailbox - serves as data buffer between asynchronous components.
   • SharedMap - forwards incoming data to multiple outputs.
   • Splitter - a push-in/pull-out data structure used to store system states that can be accessed by many components.
   • Switch - sends only one of its inputs to output port.
3. Communication manager (CM)- responsible for creating and managing communication links between AAs that need to be connected, i.e, they are used to connect CA. There should be one CM for the processing node in a distributed system (figure 9).
4. Application manager (AM)- responsible for control and management of the whole system, by coordinating system states. They also configure and control all components available in the system. There should be one AM per processing node in the distributed system.

The global execution of Marie based application is asynchronous, where applications and AAs push their data at a different rates. Marie doesn't provide any synchronization means.

• Communication approach - From the perspective of the middleware support, Marie does not stick to some specific communication mechanism, but rather tries to support as many as possible. This achieved by abstraction framework, "port", provided for communication protocols and component interconnections (figures 11 and 12). Marie uses ACE library to implement communication. Therefore it can provide for different types of communication media, though it is mostly TCP protocol based using sockets. Some other concepts used in the implementation of communication in Marie are

• Abstract port - this object implements communication interfaces to be used between components. It is responsible for data formating and data management before sending them to abstract communication object, which responsible for the execution of the communication.
• Concrete port - are used to decouple data is managed and represented from how it is communicated. They are responsible for the communication issues and are mediator between components.
• Abstract communication strategy - are abstract objects responsible for the communication protocol execution.
• Concrete communication strategy - are concrete instances of the abstract communication strategy. This can be Socket, Shared Memory, I/O stream, serial port etc.

• Platform/language support and other system features

• Fault tolerance and robustness aspects -

• System organization/decomposition

SmartSoft is a component based software framework to implement sensori-motor systems based on the concept of communication patterns. To achieve complete decoupling of components, implementation of component interfaces is based on these predefined communication patterns. The communication patterns allow to decouple internal and external behaviors of a component. Authors identify several "requirements/features" that a robotic software framework should implement. Some of them are:

• Dynamic wiring - this feature allows dynamic configuration of connections between services of components at runtime, allowing dynamic data and control flows.
• Component internal structure - authors claim that the framework should not constrain developer to one particular component implementation model but rather offer many different models. But the framework also has to ensure interoperability of these different implementations.

To achieve these (and other not listed here) requirements, it is suggested that all component interactions are fulfilled through the predefined set of communication patterns. This ensures decoupling of components and related items at appropriate levels of abstractions. The following is the list of abstractions which can be found in SmartSoft.

• Components - can contain several execution threads and interact with other components via communication patterns. They can also be dynamically wired at runtime.
• Communication patterns - define communication mode, provide predefined access methods and hide all the communication and synchronization issues. It is always composed of two parts (a) service requestor and (b) service provider. They can represent client/server, master/slave and publisher/subscriber relationships. Table below summarizes available generic communication patterns.

  Pattern name	Communication mode	Relationship
  send	one-way communication	client/server
  query	two-way request/response	client/server
  push newest	1-to-n communication	publisher/subscriber
  push timed	1-to-n communication	subscriber/publisher
  event	asynchronous conditioned notification	client/server
  wiring	dynamic component wiring	master/slave
  state	state management utility	client/server

• Communication objects - represent the content to be transmitted via a communication patterns. They are always transmitted by value. These objects are ordinary objects with some additional member functions.
• Service - each instantiation of a communication pattern provides a service. Generic communication patterns become services by binding the templates by types of communication objects.

External interfaces of a component give info on provided and required services whereas communication patterns underlying provide info on usage and semantics of these services. Authors state that the proposed approach interweaves components at the level of services rather than the level of member functions.

• Communication approach

Predefined member functions of the communication patterns provide both synchronous and asynchronous service invocations or handler based request handling. Communication patterns ensure decoupling of components since the interactions are always asynchronous regardless of the access modes used(figure 16). The wiring pattern makes service requestors visible as ports and connectable at runtime from the outside of the requestor. Service wiring is based on "names". Here service providers have to register their services with the broker (aslo known as "Naming service/registry"). The communication mechanism internally is based on messaging it can be mapped onto any standard middleware systems such as CORBA implementations, or raw TCP/IP.

• Other unique system features -

• System organization/decomposition - the goal of this project is to develop a general purpose modular framework for robot and machine control. It is organized in the form four C++ libraries:

1. the Real-Time Toolkit(RTT) - provides infrastructure and functionality to build component based real-time application.
2. the Kinematics and Dynamics(KDL) library - provides primitives to calculate kinematic chains.
3. the Bayesian Filtering library(BFL) - provides a framework to perform inference using Dynamic Bayesian Networks.
4. the OROCOS component library(OCL) - provides some ready to use components.

OROCOS components are built using RTT but also can use functionalities provided by other libraries. Users can interface/interact with the component through its predefined set of interfaces. As can be seen from the figure 17, there are five ways to interface with the component. In addition to defining component interface and communication mechanisms, OROCOS allows application builder to implement hierarchical state machines using these mechanisms. The state machines can be loaded at runtime in any component. All OROCOS components are implemented using the "TaskContext" class. TaskContext (figure 19) defines a "context" in which the component task is executed, where a task is a basic unit of functionality which executed one or more programs(a C function, script or state machine) in a single thread. All the operations performed within this context are free of locks, priority-inversions, i.e. thread-safe deterministic.

1. Commands - are sent a component to other components(receivers) to instruct them to achieve a particular goal. They are asynchronous, i.e caller does not wait till it returns.
2. Methods - are called by other components on a particular components to perform some calculations. They return immediately.
3. Properties - are runtime modifiable parameters of a component which are stored in XML format.
4. Events - are executed by a component which a particular change occurs (event/signal is received).
5. Data ports - are thread-safe data transport mechanism to communicate (un)buffered data among components.

Figure 19 depicts internal infrastructure of the component/TaskContext. A component accepts commands/events using its Execution Engine. It will check periodically for new commands and execute programs for a particular task. Execution process goes several states such as start, update and shutdown (This approach is to similar to that in LAAS/GenoM modules). The Execution Engine uses Activity interface classes from the CoreLib library which is part of the RTT and responsible for the communication infrastructure. Activity interface classes define both periodic and non-periodic activities.

• Communication approach - For distributed applications OROCOS uses ACE/TAO CORBA implementation as the transport mechanism. In OROCOS Data-flow is implemented with the Port-Connector software pattern. Each task defines its data exchange ports and inter-task connectors transmit data from one port to another. Here a port is defined by a unique name, the data type it transmits and the transmission method (buffered/unbuffered). Buffered transmission is performed by "buffer ports" and unbuffered by "data ports". To perform inter-component/TaskContext data exchange, components should be connected using addPeer and connectPeer functions. This establishes the Execution Flow. The Data Flow of a system is established by connectPorts method.

• Other unique system features - On a single machine/OS system OROCOS supports real-time application through RTAI/LXRT and also Xenomai. To facilitate component development OROCOS comes with the set of tools, i.e. scripting language, TaskBrowser (similar to LAAS/GenoM module test components).

• System features
  • System organization/decomposition -
  • Communication approach - socket based, using TCP protocol, custom.
  • Other unique system features -

• System features
  • System organization/decomposition -
  • Communication approach - socket based, using TCP protocol, custom.
  • Other unique system features -

• System organization/decomposition - The system is organized an object oriented programming interface for robot control. Objects corresponds to robot devices: differential wheels, camera, distance sensor, range-finder, accelerometer, servo, etc. For every object, a number of methods are defined. For example, there are methods for enabling and disabling sensor measurements, retrieving sensor information, setting parameters, sending commands to a motor, etc.

• OS and language support - This object oriented API is available in a number of programming languages, including C, C++, Java, Python (under development). There is also a TCP/IP relay interface (written in C) allowing to program a robot using the Webots API from any third party program supporting TCP/IP (i.e., Matlab with the TCP/IP toolbox, Labview, Lisp, etc.).

• Communication approach - The communication protocol between the API and the robot uses 3 different transport technologies depending if you use the Webots API for simulation, for remote control or as a cross-compiled program:
  • Simulation: using pipes (Inter-Process Communication) between the controller program and the simulator.
  • Remote-control: using the robot dependent communication system (i.e., serial port for the Khepera and Hemisson robots, wifi for Aibo, serial communication over Bluetooth for the e-puck robot, etc.).
  • Cross-compilation: using C/C++/Java static or dynamic linking between the Webots API and the robot specific operating system.
  These three different transport technologies share the same protocol and guarantee an optimal execution speed:

• Other unique system features - The Webots API support a large number of devices and robots. It is fully documented, so that it is easily expandable and adaptable to your very own robot. Cyberbotics provide user support to help developers adapt the Webots API for controlling new robots (for both remote-control and cross-compilation). The specifications and all the robot implementations of the Webots API are open source free software.

• Reference - The documentation of the Webots API is included in the Webots reference manual (HTML version, PDF version). You are welcome to contribute to this open source project by developing your own robot implementation or your own API extension!

• System organization/decomposition

RoboComp is an open-source robotic software framework. It uses software component technology to achieve its goals: efficiency, simplicity and reusability. Its components can be distributed over several cores and CPU's. Existing software components, can be easily integrated with new components made by RoboComp users. However, RoboComp is not just a set of software components, it also provides a set of tools that makes component creation and management a pleasant experience. RoboComp does not impose any architectural constraints on any individual component or the system as a whole.

• Communication approach

All inter-component communication in RoboComp is handled by Internet Communication Engine (Ice) from ZeroC, following the approach taken by the Orca2 robotics system. Ice is a general-purpose communication middleware. It is a contract-based middleware which requires that all interfaces are explicitly defined in an Interface Definition Language called Slice. These definitions serve as contracts between components at run-time, describing what services are provided by some components and required by others. Internally, Ice can be configured to use TCP, UDP, or SSL as transport mechanisms. Custom transport mechanisms can be added.

• Platform/language support

RoboComp can be deployed to any computer system supporting Ice (the communications middleware) and Python (the language in which the main RoboComp's applications are written). The supported programming languages are those supported by Ice: C++, Java, Python, C#, Ruby, PHP and Objective-C. The supported operating systems are Linux, MacOS X, and Windows. Note that there is no distinction between servers and clients in terms langauge/OS limitations.

• Fault tolerance and robustness aspects

1. Automated marshalling/demarshalling
2. Remote Ice exception
3. Automatic deploying through the managerComp utility

• Utilities and Services

1. Automated marshalling/demarshalling
2. Remote Ice exception
3. Automatic deploying through the managerComp utility

• Other unique system features -

1. Automatic deploying through the managerComp utility
2. Advanced component generator
3. Support for the Gazebo simulator. Components can run whether using simulated or real hardware.
4. Logging and replaying capabilities. Components can also run using a recorded sensorial sequence through replayComp.

• System organization/decomposition - The organization of the LAAS system is based on an abstract machine model with three functional layers. The simplified view of the system is depicted in figure [??].

The decisional layer possesses high level autonomy capabilities represented in terms of the deliberative planner and event-driven supervisor. It is able not only to generate a sequence of tasks for execution but also to be reactive to events from the lower level. Generally, plans generated by the planner are used as an input resource to the supervisor which actually controls the plan execution, interacts with lower level entities and handles events incoming from them. We want to remark that both LAAS (Section ??) and CLARAty (Section ??) have adopted similar concepts for this layer). The supervisor is also responsible for receiving goals/tasks from the user via a user interface. The LAAS planner is based on an IxTeT temporal planner and the supervisor is based on a Procedural Reasoning System (OpenPRS). In figure [??] one can see a simplified form of the decisional layer. Authors also claim that the number of sublayers on this level is application dependent and can be more than one. But again, each layer is organized in the form of a planner-supervisor pair. We refer to [??] for such an example. The mediating layer of LAAS, the execution control level, takes a step further than just serving as a transition between a level of slow declarative reasoning and a fast reactive layer. It assures the safe execution of task sequences delegated by the supervisor from the decisional layer and the handling of resource/service requests from the functional layer.

LAAS implements the executive in form of a request and resource checker, R2C, as it is called by the authors. Figure ?? depicts a general view of R2C. As is visible, R2C can be divided into four major subunits: Input buffer - the buffer holds all the requests to R2C from the other levels of the system. With regard to the decisional layer these are requests to the services of the functional layer. With regard to the functional layer these are reports on resource modifications, service terminations, and handling of inter-module service requests (in the previous version the functionality of this unit was reflected by request/reply monitors) [??], [??].

1. System state database – the database reflects the information on the current, the past system states and system resources.
2. Model checker – this unit together with the System State database keeps the system consistent. A model checker performs the required actions according to the received requests and the current state of the system.
3. Effector buffer – all the commands issued by the model checker are queued in this buffer which then delegates them to the appropriate receivers and particular layers.

To achieve a higher degree of reliability in the software, the R2C is implemented by means of the special specification language ExoGen which in our view offers similar functionalities and can be used for the same purpose as such languages as Esterel in the ORCCAD system [??], [??], [??] and RMPL in Livingstone [??], [??], [??]. The functional level is responsible to interface hardware and to abstract routine robotic tasks, e.g. localization, etc. It is implemented using GenoM which is the collection development tools, libraries and environment (in the form of emacs-mode for the emacs). The idea of GenoM is to use formal methods to develop robotic applications. One can identify the following key concepts related to GenoM:

1. GenoM module/component specification language is used to describe module/component entities (its interfaces, services, threads, database, execution model).
2. GenoM module generation tool is a command line tool used to parse module specification files to generate module skeletons according to the generic module template. The files generated can be mainly divided into "client" and "server" files. Here the "server" files are most communication related to definitions, whereas "client" files are the ones a developer should work with. The latter are a collection of empty function definitions (they are also called codels and defined as the smallest execution unit in module. This ensures the "finiteness" of the execution time.) as given in module specification. These functions are related to two types of "requests": execution rqst, and control rqst. Module processing is performed by issuing execution requests and module behavior (start, stop, interrupt, recovery etc) is handled by control request issued. These requests compose the control flow of the system. Also, the services of a module are activated and parameterized asynchronously through a non-blocking client-server protocol. The processing of the requests by a module is called an activity of the given module. Upon the termination of the processing the module returns a reply in form of an execution report.
3. Another concept associated with module is posters these are shared memory regions which enable data exchange among modules. The posters have rd/wr access which defines who can write to a poster and who can read. It also needs to be mentioned that GenoM modules/components are themselves responsible for resource handling, and recovery actions.

To keep consistency in the implementation model, all modules descend from the base generic module. The generic module, as depicted in figure [??], is composed of two major parts:

1. The controller - it manages the modules according to external requests. It is implemented as an asynchronous process which reacts upon requests or internal events.
2. The execution engines - they perform the activities required by the controller. Each engine is implemented in the form of either a periodic or an aperiodic process.

The controller and execution engines interact through asynchronous events and two databases.

1. Functional database - it includes all the data relevant to the controlled module: parameters, results, etc.
2. Control database - it includes the state of the module activities in form of commands from the controller and reports from the execution engines. This database has the same structure for all modules.

The execution model for any module follows the automaton depicted in figure [??]. (Here the EXEC state is the state where activity processing is performed. For further details on automaton model refer to [??]). The execution process adopts an interesting and a very important concept described as the decomposition of the executable code into non interruptible code parts defined as codels (see the subsection on Fault tolerance and robustness aspects for details [??]).

• Communication approach - To build up more complex system, modules can be combined into a network, where they exchange information among each other. Note the similarity between ORCA and LAAS, both deploying communicating components to achieve the goal. But unlike ORCA which uses ICE middleware for communication, GenoM modules communicate using custom shared memory based middleware called Hilare. Actually, there are two levels of communication involved, "among the modules" (which is similar to inter device communication in Player) and "between client programs and modules". The former uses Hilare env, whereas the latter is socket based over TCP protocol. To simplify client programming GenoM offers TCL mappings (similar to device proxies in Player client space) to all the modules (this is generated by GenoM tool). These proxies use "tclserv" application server to communicate with the devices. The approach is similar to the use of Player server and IceBox app. server in ORCA.

• Platform/language support and other system features - Since GenoM uses UNIX shared memory system it runs on UNIX/Linux/Solaris systems, client programs can be written in TCL, Ruby or C/C++. Components are written in C/C++. Among other features are automated code generation, shared memory based communication, module recovery procedures.

• Fault tolerance and robustness aspects:

On the level of modules LAAS adopts the concept of codels, i.e non interruptible code blocks. An activity of a module is the execution of a sequence of such dynamically selected codels. This form of decomposing an executable code assists in monitoring the program run and performing recoveries in case of failures. The process of recovery can, for instance, be based on a backward recovery technique, where the system tries to put itself into a non erroneous state which is the latest state the system had before the occurrence of the failure. The empty set of codels is generated automatically by only providing a formal description of a module to the GenOM module generator. Figure [??] shows the internals of the generator and the process of code generation. We also once more underline that each module follows the execution model represented in [??], this also assists in monitoring the system state [??], [??], [??], [??], [??].

The other aspect of LAAS which contributes to the dependability of the system is the process of safe execution which is achieved with the aid of R2C. We have already briefly described the functionality of R2C in the previous section. The important subunit, in the structure of R2C, which performs inference on whether the system runs correctly, is the Model Checker (MC). It is represented in the form of an Ordered Binary Decision Diagram OBDD which is used for model validation. This approach offers the opportunity to check the automaton describing the system state evolution in the view of safety constraints imposed [??]. Apart from these features, the LAAS planner/supervisor pair supports all the standard functionalities provided by planner/executive pairs of 3 tiered architectures. We also want to note that the LAAS planner/supervisor approach is a tighter integration of declarative and reactive system capabilities into one layer. This also gives more flexibility in plan execution (refer to CLARAty (Section ??) for a similar approach).

• System features
  • System organization/decomposition -
  • Communication approach - socket based, using TCP protocol, custom.
  • Other unique system features -

• System features
  • System organization/decomposition -
  • Communication approach - socket based, using TCP protocol, custom.
  • Other unique system features -

• System features
  • System organization/decomposition -
  • Communication approach - socket based, using TCP protocol, custom.
  • Other unique system features -

• System features
  • System organization/decomposition -
  • Communication approach - socket based, using TCP protocol, custom.
  • Other unique system features -

• System features
  • System organization/decomposition -
  • Communication approach - socket based, using TCP protocol, custom.
  • Other unique system features -

• System features
  • System organization/decomposition -
  • Communication approach - socket based, using TCP protocol, custom.
  • Other unique system features -

• System features
  • System organization/decomposition -
  • Communication approach - socket based, using TCP protocol, custom.
  • Other unique system features -

• System features
  • System organization/decomposition -
  • Communication approach - socket based, using TCP protocol, custom.
  • Other unique system features -

• System features
  • System organization/decomposition -
  • Communication approach - socket based, using TCP protocol, custom.
  • Other unique system features -

• System features
  • System organization/decomposition -
  • Communication approach - socket based, using TCP protocol, custom.
  • Other unique system features -

• System features
  • System organization/decomposition -
  • Communication approach - socket based, using TCP protocol, custom.
  • Other unique system features -