Re: A working document

On Fri, 14 Dec 2001, Anthony Mallet wrote:

[... LAAS document ...]

Here are some of my questions and comments. They are mostly signals of
possible misunderstanding or things that are not too clear.  They are
(at this stage, at least :-) ) not to be interpreted as devastating
critical remarks :-)

- The Executive ``controls and coordinates the execution of the
  functions distributed in the components of the functional layer,
  according to the task requirements'', and ``the decision layer [...]
  supervises the execution of the task''.

  At first sight, this seems to be twice the same thing...?

- I agree with your focus on ``the functional layer, since Orocos
  focuses only on it as of today''.
  But I think the ideas in your draft apply to the other levels also.
  They do apply at least to what we've been doing in Leuven the last
  months with the real-time motion control components :-)
  And they apply to what we have in mind with our sensor processing
  components too.

- How do you think the designs of Leuven and LAAS will best meet, in
  order to implement the ``logical sensors''? What support do you
  expect/need from the real-time/kernel drivers and components?
  Do you consider these logical sensors to live already on top of the
  CORBA layer that Stockholm is preparing? (This layer could be
  short-circuited, if things are running on the same CPU, of course.)

- In your Figure 1, I would add also `events/reports' between the
  logical layer and the functional one.
  (There is also a small typo: ``Consitency checks'' -> ``ConsiStency
  checks''.)

- I like your terminology ``reporting''. We use ``monitoring'' or
  ``diagnosis'', but reporting seems to be more generic and neutral.

- You have ``Consistency checks,'' ``Resource management,'' and
  ``Data flow management'' in the ``Execution control layer'': in our
  design, we consider these to be supporting functionality of the
  functionality layer, and call it the layer's ``runtime''. (By lack of
  a better name...)
  Is this indeed what you mean also? I.e., in one layer, one has
  functional components (those that really perform the interesting work)
  and supporting components (that help the functional ones to achieve
  their goals, and that hide the details of event/exception handling and
  data flow/communication).
  (Our motivation to put these together is that they cannot live
  without each other anyway...)
  If the above interpretation of mine corresponds to your
  interpretation, then I miss a ``runtime'' feature which is
  ``scheduling'' and (dynamic) re-configuration of the active functional
  components. Or maybe that's include in what you call ``Resource
  management''?
  I think you mean the same thing as what I mean, because, on page 3,
  you write ``A consequence is that both the control ow and the data ow
  must be defined outside the components. For instance, in the LAAS
  architecture, this is done at the Executive level.''

- I do not fully understand the sentence (page 3): ``The code
  contained in the components thus becomes naturally independent of
  the particular robot on which it will execute.''
  The thing I don't quite understand is the ``thus''... It refers to
  the previous sentences, which are cited in the previous paragraph of
  this mail. How does the separation between execution and functional
  layers make sure that your functional layer becomes independent of the
  robot system?

- Codels. Reading the first paragraph of this section reminds me of
  the ``Monitor'' software pattern: the events are ``serialized''
  before they are given to the functional component, and hence each
  codel should worry only about the event that caused this codel to
  become active. In still other words: a codel is the actions done in
  one single node of the FSM (or other synchronization tool).
  Is this a correct understanding of the message you want to convey in
  this section?
  If so, I would prefer to use the Software Pattern names, because
  that's what software patterns are good for :-)

- A related question: are your codels the same thing as
  ``transaction'', i.e., things that take place atomically, or not at
  all? Probably not, because it is impossible to guarantee the four
  classical ACID conditions for transactions, I guess?
  A brief definition of ACID can be found on
  <http://searchdatabase.techtarget.com/sDefinition/0,,sid13_gci213756,00.html>

- Page 4: ``codels should be totally independent of the communication
  libraries.'' And also of the FSM, isn't it? They encode the smallest
  parts of functionality, and this does not depend on how their
  sequencing and synchronization is being done. Or does it?

- I don't quite understand ``Note that this is much stronger
  than simply relying on standard libraries (and defining standard
  functions for communication).''...
  Or ``codels should only interface libraries with the component's
  structure.''
  Or ``a prototype is naturally defined, and all data
  can be directly passed to the function.''

- Stop the execution of a service: you mention three situations, but
  isn't there a fourth one: the codel itself raises an ``exception''
  that requires immediate servicing (by the runtime/executive).

- The ``inter'' codel is what we call an exeption handler, I guess. It
  would be nice to reach a common terminology... In our design, we
  have an ``exception handler component'' at each layer, whose
  responsibility it is to bring the whole layer in a consistent state
  again.
  When writing down these sentences, I realise that what you call a
  ``layer'' we call a ``framework component''. Both names are not
  sufficiently expressive, I think... We need a better (i.e., more
  specific) name. What it is is a set of components that are connected
  together in one particular architecture, and, in this form and
  together, make up a new component. Calling this a layer is too
  suggestive for a hierarchical architecture.

- Page 5: I do not quite understand the exact difference between a
  ``description language'' and a ``programming language''. (At least
  not in this codel context; I do understand the difference between,
  say, an XML file and a Pascal program :-)
  Or do you mean that the language described the data structure
  (``object'') that is exchanged through the interface of the component?
  This is the way we describe it in our motion control framework. That
  is, all communication between component takes place through
  ``objects''.
  I place ``objects'' between parentheses, because it are objecs
  without any ``methods'': just data structures. And hence, fully
  specifiable by a description language such as XML. As shown by your
  figure on page 5.

Enough comments for now: I go to bed :-)

More will follow later one, but also now already I get a warm feeling,
because I think we are designing along very compatible ways; this
should lead to the synergies in implementation and code maturity that
we've been hoping to reach in this project.

Herman