Re: OROCOS remarks

On Wed, 19 Sep 2001, Cezary Zielinski wrote:

[... about making components without imposing an architecture...]

> OK - this makes the task more clear to me. You want to deliver just
> the building blocks without specifying the overall structure of the
> controller. I am not in favour of this approach, but can go on with
> it and find out what will come of it. With this approach you give
> more space for the creativity of users, but on the other hand make
> the task of building a controller more difficult for them.

I think that is a good summary of the decision we took to separate
architecture from component building. Of course, the decision doesn't
mean _at all_ that architectural design is not allowed within Orocos
:-) It just means we try to get focused on components first.
As Orocos is an open source project, we have no reasons not to accept
good ideas  and contributions that aim beyond the current low-level
focus of the project. Of course, the link between both levels must be
there.

Hence, you are very welcome to add architectural ideas, of tools to compose
controllers! In fact, the Genom tool that was presented by LAAS goes a
lot in that direction. When we say `decouple architecture from
components' we don't mean that we don't do any architecture at all:
each component will have a certain micro-architecture, i.e., how the
threads and IPC are done internally.

So, personally, I have no objection against your proposal:
> Maybe a middle of the road approach would be valid - at least we
> should hint to the users what an exemplary structure should look
> like? Although you can build very diverse structures out of LEGO
> blocks, the company delivers plans how to build something specific.

[... about coping with errors in components...]

> My experience shows that monitoring errors is not an add on. It is
> interwined with the normal mode of operation. The components have to
> detect their own error states, transmit them to upper control
> layers, and those layers have to be able to retransmit the errors
> whilst adding some information of their own. Finally the information
> should reach the user interface, and thus the operator.

I think your suggestion is completely in agreement with the path that
we wanted to follow, i.e., something based on the good ideas of Genom
and Smartsoft: we found out that the concept of a finite state machine
as the structural skeleton for a component is quite valid and mature
(in contrast to the hybrid systems skeleton which is not quite matur
yet, in terms of software engineering). So, the error recovery mode
fits nicely in the structure. Probably we didn't mention or discussed
it sufficiently explicitly. So, thanks for bringing this under the
attention!

A concrete question in this respect from my side: do you think it is
sufficient to
 (i) design an error mode in each component (and only one
     single one, that has to catch _all_ error situations),
(ii) return an error code to the user of the component?

Or do you think a more elaborate design is needed. For example, ane
dedicated error module for a set of closely cooperating components?

[...after occurrence of non-fatal error...]
> After the ocurrance of those errors you can try some error recovery
> procedure. Surely the system should not disintegrate due to them.

Which part of the system should decide how to ``fail safely'' in case
of fatal errors? Each component individually, by going to a safe state
itself? Or a `supervisor component' that takes the decision for the
whole system? My preliminary thoughts about it is that we need both
things: each component fails safely, warns the supervisor, and waits
for commands from the supervisor _only_ (i.e., returns other `user'
requests with a `service not available' reply (or something of this
kind).

[...]
> b) operating system error
> Those errors cause the malfunction of the "brain", which at the same
> time is the main means of internal communication. Here partial
> disintegration of the system is inevitable. What to do then -
> personally I don't know! This is a quetion for discussion.

Thinking along the lines I presented above, I would say that the best
thing to do is to make sure that all individual components fail
safely. And that they go to the `configuration' mode, waiting for new
orders from the supervisor. Of course, they should be able to keep the
state of their actions.

> > I am speaking about notification of the operator rather than
> > "artificial intelligence" methods of solving the problems as they arrise.
> > Moreover it is anticipated that the user will be putting the components
> > together to create a control program suting his/her needs. Here errors can
> > arrise, so detecting them is of paramount importance. The easier you can do
> > it the greater the value of the created software.
>
> Indeed. And this is, in my opinion, one of the functions of the
> supervisor mode: check on-line wether the components are connected in
> meaningful ways. I have no idea yet how to do this in practice, though
> :-)
>
> C.Z.:
> This can be done by some kind of initial "simulation" of the
> behaviour of the connected components. I am speaking about something
> happening at run-time. This makes it necessary for the components to
> perform some kind of self diagnostics (rather continually than
> periodically) and be able to communicate their findings to the
> others.

I might not understand this completely (e.g., the `simulation' is not
clear to me), but I do know that the motion control framework we are
now putting together in Leuven has provisions for this self-diagnosis.
The idea at this moment is to have one `thread' doing the diagnosis
and related error handling, the reporting to the `outside world', and
makes sure the local system fails safely.

Herman