Re: Mini meeting Toulouse 22-23 april / Execution Engine

Herman Bruyninckx wrote:

> On Thu, 18 Apr 2002, Christian Schlegel wrote:
>
> [...]
> > What I think is important to consider is that there are several ways of
> > organizing the internal strucuture of a component despite the use of a
> > particular "execution engine".

Independent of the internal structure of a component, it should behave in a
specific way with respect to its interface. As we do it in Orocos, this can be
best achieved by providing predefined patterns which are the only external
interfaces. This prevents the component builder from introducing methods at
the external interface where a component user does not know how such user
defined methods e.g. behave in a multithreaded environment. However, the
internal structure of a component may vary completely depending on what the
component is doing. Some components have to meet hard real time constraints
and perform short cyclic tasks, other components have time consuming loops to
adjust parameters in a vision system based on example images.

Independently of the internal structure of a component, there are still some
common aspects of how to organize a component. This is independent of what
kind of execution engine is used within a component. One example of organizing
a component is given by the automaton of the Genom framework, another one is
the SmartConfigurationClass described in the communication patterns document.
The point now is to allow the component builder to use that kind of component
structure which best fits his needs. However, a common requirement of the
component structure is to be able to abort pending communication calls due to
a state change.

Example:

A component is waiting in a blocking query and there is a request from outside
to deactivate the components activities. In this case the component has to be
able to abort the pending query due to the requested state change. This is
important since reconfiguration of several components which together perform a
specific task, can always result in transient states during state changes. If
two components A and B have to be deactivated, A is waiting for the answer
from B, we first deactivate B, we would not be able to unblock the pending
wait in component A if we don't have a mechanism to enforce the component to
reach at least one "neutral" state from where every other state can be
reached.

Transient states in the above sense are very common when task execution
engines reconfigure components in an arbitrary order. Our experience is that
it makes life much easier if you don't have to consider constraints on the
order of deactivation of a configuration.

My hint simply is to think on that kind of interaction between a task
execution mechanism (which decides what to do next in case of conflicting
ressource requests) and on the influence of that execution mechanism on a
component's capabilities with respect to reconfiguration. One example of how
one can do this is given by the SmartConfigurationClass described in the
communication pattern document. Of course, there are many other solutions as
well ....

>
> > For example, the state mechanism provided
> > by the "SmartConfiguration" class has also been used successfully in
> > three layer architectures with a task net execution mechanism on top of
> > the various components. That state mechanism works different to the Genom
> > approach and I think both have their particular strengths and weaknesses.
>
> What I would like to come to is a further decomposition of the Genom
> work into a pure sequencing library (that can indeed be used
> ``everywhere'', independent of the task) and task-dependent libraries
> that implement the functionality. So, I think this is also what you
> are trying to do (implicitly)?

Yes !

In our architecture I have a completely separate task execution engine which
is responsible for interpreting task nets. That is a very powerful interpreter
which coordinates the overall task agenda and sets up various components to
fulfill a specific task. That task net interpreter is not what is inside every
component to coordinate the internals of a path planner e.g.. However
components have to provide several kinds of configuration mechanisms to glue
the task net interpreter as execution engine with the components providing
various basic skills. One of that glue components are the "events" and another
part is the configuration class which makes sure that a component is
interruptable even if it is waiting in a blocking communication call. The
configuration class is related to the communication patterns since both can be
accessed from outside a component respectively provide the external interface.
The execution engine inside many of the components is simply a finite state
automation and not the full-fledged task-net interpreter.

>
> > The key with respect to configuration has been the fact that one can
> > abort blocking communication calls if one wants to enforce a component to
> > reach a particular state. Therefore I am always pointing out that there
> > is a relationship between the state change mechanism and the
> > communication patterns.
>
> Indeed. This observation holds for _all_ activities in the system, so
> that's why it's useful to have a library dedicated to it.

Yes !

Christian

>
>
> Herman
>
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos

--

---------------------------------------------------------------------
Christian Schlegel
FAW Ulm (Research Institute for Applied Knowledge Processing)
PO Box 2060
D-89010 Ulm
Germany

Tel. : ++49 (731) 501 8949
Fax  : ++49 (731) 501 999
email: [email protected]
WWW  : http://www.faw.uni-ulm.de/
---------------------------------------------------------------------