Re: About component architectures...

Herman Bruyninckx wrote:

> On Thu, 25 Apr 2002, Anthony Mallet <Anthony Mallet wrote:
>
> > Herman Bruyninckx wrote :
> > | I am not too happy with a `supervisor' because that is such a general
> > | name that covers too many different things we want to separate.
> >
> > I think what you really want is an "execution control layer", which can
> > be made of several components: 'configurator', 'resource management',
> > 'consistency checks' (e.g. checking that you are not doing things with
> > the 'functional components' that are not allowed), 'communication
> > management' (e.g. some of the functionalities of an ORB), etc...
>
> These are all part of configuration, aren't they? But I agree that
> they represent different aspects (`roles') of configuration.
>
> > | - Configurator (what the people in LAAS call ``control flow'' I guess),
> >
> > Not really: the control flow is much more general. With our terminology,
> > the control flow represents all the service requests that are made to the
> > 'functional components'.
> > | - Mediator (``data flow'') that accepts service requests from
> > |   the user and divides those into actions for its sub-components.
> >
> > [ Services requests are part of the control flow ]
>

Hi,

Just another wording .... :-)

communication:
every kind of communication based on the communication patterns. Normally,
communication patterns are only applied at the external interface of a
component (they can be applied internally as well !) and therefore
communication normally is inter-component exchange of any kind of data.
Communication includes configuration messages as well as data transfer between
components.

control flow:
Depending on the currently executed tasks, several components form a
hierarchy. This is even true when you use distributed decision making since
you then at least set up the involved components into a mode where they are
said to resolve conflicts by negotiation. Events are typically (but not only)
used between different levels of a hierarchy since they report on execution
progress or on execution failures and problems. The control flow therefore
describes which component is responsible in what situation.

configuration:
The configuration sets up the parameters of a component. This includes
activating events, enabling states etc. If a state gets enabled, the component
can e.g. subscribe for laser scans. The configuration comprises the complete
set of parameters under which the components work till the next configuration
arrives. The configuration sets up the constraints under which a component can
do what it wants since the constraints make sure that the components
activitites do no conflict with activities of other components. The state
class e.g. provides handlers which are executed when a state is entered. Those
handlers typically contain calls to subscribe for a laser scan etc and the
exit handler of the state unsubscribes the laser scans.

data flow:
The data flow is used to exchange maps, laser scans, images etc. between
various components. This is normally (but not restricted to) done between
components at the same level. The data flow (which component is subscribed to
a component, where the results are sent to etc.) is set up by the
configuration or results from the activated states of a component.

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.

component automaton:
The sequencing mechanism must be distinguished from the component internal
organization. One possible appoach is the Genom structure, another one a
simple automaton and yet another one a threaded structure depending on the
state class of SmartSoft.

Christian

---------------------------------------------------------------------
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/
---------------------------------------------------------------------