Re: FSM vs. Petri nets for component modelling...

Hi Herman, lot of questions this afternoon!

>- do you make distinction between signals and events?
no, but events are classified in pre-conditions, post-conditions, exceptions 
(3 sub-classes) and synchro-signals.

>-what is a typical implementation of this material: single thread,
>  multiple threads, distribution over network?

the current implementation is a single thread for the control law + automaton 
thread + clock-generator thread + system threads

a multi-thread (and thus multi-rate) implementation of the control laws is 
under debug and test

distributed implementation is foreseen, at unknown horizon (funding 
resquested!!!!). It is however possible to manually distribute the code 
(control functions + pieces of automaton) on a distributed target, and connect 
with sockets as we already did in: http://www.inrialpes.fr/bip/people/simon/ise
r97.ps.gz

>- any suggestions about implementation on top of a POSIX API?
the run-time library for linux and solaris already uses the pthread library. 
However, even if the API is the same, it is not implemented the same way, and 
the run time behaviour (e.g. under linux vs solaris) can be very different. We 
are working to fix that, and make the application behaviour system independant.

>- what is the determinacy of the Orccad transition implementation?

It is under control of the automaton and of the OS, and it is as deterministic 
as the OS! A problem is the avoidance of transient cpu overload. It is 
currently done by relaxing the deadline, and a better solution is studied.

>- any ideas about how easy/necessary it is to decouple the _runtime execution_
>  of the synchronization functionality from the specific language
>  chosen to _specify_ the synchronization (i.c., Esterel)?

Esterel is nice because the compiler translates your specification (written in 
source language, with no FSM structure in your brain) into an executable FSM 
(usually in C, but possibly in Java, Ada...). It also provides some formal 
verification tools.
The two difficult steps are: 
i) design, checking and encoding a supervisor (FSM or others)  which meets 
your requirements (strl is nice for that)
ii) interfacing the supervisor with the control code through system calls 
(Orccad binds the I/O functions of the automaton with system calls, and it is 
easier to do that from the standard interface provided by a compiler).

>- any ideas about the `best' specification language? I mean: go for a
>  specialised custom-made language, or use already existing(?) XML
>  based functional specification languages?
Some of my colleagues have design Maestro, a "robotics-oriented" language 
which handles our model of control tasks and compile into Esterel (in 
particular because directly using a synchronous language like Esterel can be 
harmfull). IMO most of the semantics of the robot controller resides in the 
control algorithms (on which the user must have access, not only through a 
blind Move() statement). Thus I consider that the control tasks are activities 
which must be started, stopped, suspended... upon the occurence of events, and 
a general purpose language is able to specify that.

>- I guess each of the Orccad tasks has a default `fail safe' state, to
>  which the system will move when an event occurs for which no
>  `handler' has been foreseen?
Yes, all "T3" exception drives the controller in this state. The default one 
is simply stopping the controller, which is clearly dangerous for most robots. 
A custom fatal handler must be written for every application (or at least for 
every robot).

>- Any suggestions about an object-oriented (re)design of Orccad? That
>  is, events are objects/messages exchanged between components.

The components of Orccad (modules, control tasks, procedures) "are" objects! 
(they have an identity, a behaviour, a state and an interface...). But all is 
statically defined. In particular, I think that dynamically swapping modules 
in a control task would be highly risked, both for the control algorithm and 
the real-time point of view.

>- Have you found the need to distinguish between `events' (`signals')
>  and `commands'? Could they be implemented in the same class tree?

Yes, it is not the same time scale and underlying tools, sampling and control 
theory on one side, discrete events systems (FSM, PNs...) on the other, 
probably with two kind of users.
The frontier between the two sides is the discrete event based behaviour of 
the control task.

>- are the Orccad ideas suitable for supporting _general_ hybrid
> control systems? Or `only' for one particular sub-class?
Although they have been developped and tested in robotics, I guess that these 
ideas are suitable for control systems in general.

>- what are the fundamental differences between FSM/Petri-nets and the
>  new vogue UML? 
tools for implementing probably. and the real-time extensions of UML seems 
very weak.

>I guess that you require the user to provide an explicit transition
>control algorithm if merging is desired for whatever reason?
>(At least, that would be my suggestion :-) )
>Have you had systems where merging would have been really helpful? Do
>you think it is overkill?

The gluing algorithm depends on the application (the robot and the two control 
laws), and user should provide it, if necessary.

But it is necessary only if you need to accurately control the transient 
phase. Exporting the end-point of oldcontrol as init-point of newcontrol 
(while emitting post-conditions) can be often enough. For example, I did not 
worried about that with the submarine because we had enough space in the pool. 
I will be more interesting with our expensive and fragile biped.

> maybe there happens to be a similar event (organised at your
>lab or somewhere else) in the not so far future

We can think about that

Hope this help

	Daniel