Re: [Core] Components design

On Wed, 5 Sep 2001, Anthony Mallet wrote:

Thanks for getting us started :-) My comments in this email are just
that: comments. So, I am open to other opinions.

[...]
> Something on which we should agree is: what's a module?
> We can start with this very general and incomplete definition:
>
> "a component is a black box, that will offer services to other
> components. The services are actually algorithms that are grouped within
> the same module because they provide to the rest of the system the
> necessary functions to access or control a given physical or logical
> resource".

I would add: a component's behaviour is fully specified by its
interface (API).  That means that users of the component need not know
anything about the internals of the component. And that the component
has no undocumented side effects!

> The first observation I can make regarding the modules design is
> that we will need to agree on a formal description of the services
> offered by the various components we'll want.

Formal _and_ documented. "Formal" means that the API is given in one
specific language' "documented" means that each component comes with a
``man page''.

Next to this "specification" face of components, I think there is also a
"framework" aspect: components should have a prescribed set of
"meta/supervisor" functionalities: able to identify themselves and
their configuration (in order to allow dynamic (re)configuration), and
their internal state (for monitoring and diagnosis purposes). The
latter seems to contradict the requirement for "encapsulation" via
only the specification, but I tend to suggest that our components
should have two faces: one with their user functionality, another one
to allow the "supervisor" in the system to make the system dynamically
reconfigurable.

> This description [...] should also be generic
> enough to fit in the requirements of every module (ranging from
> rtlinux in-kernel tasks to any-time userland processes).

I don't quite understand what you mean with this last sentence...

> To help focusing ideas on that description, I propose to set up a
> working document. I will disseminate a first draft within a couple of
> weeks ("soft real-time" ;).

Great! Each of the four "core" groups should/will do the same.

> The communication library we will design will have at least two main
> goals: to exchange data between components and to trigger the execution
> of the services.
> Since the architectures we'll want to address range from hard real time
> to any time ones, I feel like it will be hard to come up with one,
> generic, universal library.

Indeed. But we should be able to come up with a small set of software
patterns for communication and event handling (producer-consumer and
the like), but with different implementations according to the
requirements: hard real-time (e.g., exchange between trajectory
interpolator and servo threads), soft real-time (e.g. for on-line
estimators or task execution monitors), non-real-time (e.g., for user
interfacing or data logging over the network).

In other words, we will implement some "architectures in the small",
but no "architectures in the large". The former are proven solutions
to well-defined sub-problems. They allow a configurability as we've
seen in the talks by Sara and Christian: the micro-architecture is
fixed (and implemented in very thoroughly inpected and debugged code)
but the user fills in the functionality needed in a specific task.

In summary, the "good ideas" should be portable, the code
"transportable" (i.e., portable with some recoding).


> To achieve this, we'll have to specify the messaging format. And not only
> the structure of the messages but also the "protocol" we'll want. For
> instance, a client server protocol, with the notion of "request",
> "acknowledgment", and "reply".

Indeed: each "software pattern" will have an appropriate protocol
(independent of the implementation), and a set of message formats
(dependent on the implementation). The protocol should change much
less than the message format. (Although we don't like the latter to
change too much either, of course.)


Herman

PS Minutes of the meeting will follow soon... I've been too busy with
   helping our students to write open source drivers :-)

-- 
"I decry the current tendency to seek patents on algorithms. There are
 better ways to earn a living than to prevent other people from making
 use of one's contributions to computer science."  D.E. Knuth, TAoCP 3