About component architectures...

Herman Bruyninckx <[email protected]>
Newsgroups gmane.science.robotics.orocos.user
Message-ID <Pine.LNX.4.44.0204251001380.1054-100000@pc25-213.mech.kuleuven.ac.be>
Some thoughts about component architectures...
(Feedback is _very_ welcome!)

Some initial description about the set of generic Orocos component
architectures has already been given in the minutes of the Toulouse
meeting, but more discussion and fine-tuning is necessary, I think.

In the three component architectures we mentioned (Feedback control,
Robotic service, Autonomous system), we always seem to come up with a
`supervisor': the subcomponent that ``knows all'' about the component,
and that configures the other sub-components, and gives them work to
do.

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. For
example, I think that, in terms of Software Patterns, the `supervisor'
is really two things:

- Configurator (what the people in LAAS call ``control flow'' I guess),
  which takes care of the proper initialization of its internal
  sub-components and their communication.
  A key property of a configurator  is that it intervenes _only once_
  (per configuration action) for the objects or components that it
  configures.

- Mediator (``data flow'') that accepts service requests from
  the user and divides those into actions for its sub-components.
  A key property of a Mediator is that it intervenes in _every_
  interaction between the objects or components it mediates. This seems
  the case to me for all service requests that enter the component.

Maybe it's even more, but I hope not, in order to keep things simple.

Should we make separate sub-component for each of these ``roles'' or
should we do just that: call it supervisor, and give it different
roles (Configurator, Mediator) to play?

I hope (and am quite sure) to be able to use existing Software Pattern
names as much as possible, because this helps a lot in documenting
what we mean.

How much of all this is really generic for _all_ the components we need?

Herman

-- 
K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://www.mech.kuleuven.ac.be/~bruyninc>  +32 16 322480
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.