Re: About component architectures...

On Thu, 25 Apr 2002, Christian Schlegel wrote:

[...]
Thanks for the feedback on my terminology struggles!:-) I add a new
round of feedback from my side, inviting even newer rebuttals or
additions from your side.

> sequencing mechanism: This is the component, which is responsible
> for restricted resources and which enables / configures only those
> configurations which can work in parallel without needing to much
> processing power, without using resources in conflicting modes etc.
> It can be implemented as a task net interpreter, as a hierarchical
> finite state automaton etc.

Your phrasing ``sequencing mechanism: this is the component...'' is a
bit unfortunate: I think there is a distinction to be made between a
`mechanism' and a `component'. A component is an interface, and
mechanisms are used to implement this interface, but both things are
not the same.

I agree about ``can be implemented as a task net interpreter, as a
hierarchical finite state automaton etc'' but I don't see the
relevance of mentioning ``restricted resources,'' ``can work in
parallel without needing to much processing power''. These features
are not fundamental for a sequencing mechanism.

(BTW Christian: could you give a two line description of a task net? I
didn' really manage to extract this information out of the Videre
paper you sent some days ago...)

So, I would rephrase your definitions of the generic responsibilities
within every Orocos component as follows:

Resource scheduling
Alloting resources to components, allowing them to progress in
parallel, and making sure they don't use the resources in conflicting
modes.

Sequencer
The sub-component within a component that is responsible for the
synchronized execution of a service by other sub-components within
that component. Possible mechanisms for sequencing are: finite state
machines, Petri nets, task nets, declarative programs, etc.


Execution control
The Execution control structure is the structure (``architecture'') in
which components are connected in order to perform a certain type of
service.  The structure depends on the type of the service that is
delivered, but not on a particular service request.  It consists of
configuration (laying the structure, determining the responsibilities
of the components in the structure), and of execution (sending of
events to signal progress or failures).


Configuration
Setting up the parameters of a system (component, object,
architecture, communication, ...). This includes activating events,
enabling states, adding functionality to states, setting attributes,
checking constraints, setting up communication, etc.

All these things above are `roles' for the supervisor. Or separate
sub-components, that are woken up by the command interpretation of the
service requests that enter the component. I'm for a `command
interpreter' as Orocos concept, because it's clear what it means, and
it allows us to get rid of the `supervisor' name :-)

The following two things are not `roles' of the supervisor, but
definitions we should use consistently in ou documentation and mail
exchanges:

Communication
Communication is inter-component exchange of data, i.e.,
<em>configuration</em> messages and task-dependent <em>data
transfer</em>. Orocos standardizes on the following set of
communication patterns: ...


Data flow:
The data flow is the task-dependent information that streams through
the communication connection between various components. For example:
maps, laser scans, images, etc.

Herman

-- 
K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://www.mech.kuleuven.ac.be/~bruyninc>  +32 16 322480