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

On Tue, 4 Dec 2001, Daniel Simon wrote:

Daniel, thanks a lot for your documents.  I'm now going to read them in
more detail, but I have lots of burning questions :-)

[...]
> 1. oldcontrol runs, listening for a begin switching signal;
> 2. newcontrol resumes and initializes, while oldcontrol still runs, maybe in
> degraded mode (e.g. servo-loops running and trajectory generator frozen);
> 3. when signal end-init received, oldcontrol output is disabled, newcontrol
> loop runs and sends its first output
> 4. oldcontrol executes its end code and suspends, while newcontrol runs  (and
> listening for events)

Some more implementation-oriented questions:
- do you make distinction between signals and events?
- what is a typical implementation of this material: single thread,
  multiple threads, distribution over network?
- any suggestions about implementation on top of a POSIX API?
- what is the determinacy of the Orccad transition implementation?
  (In the context of hard real-time, or ``critical real-time
   application'' as you describe it on your web page.)
- 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)?
- 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?
- 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?
- Any suggestions about an object-oriented (re)design of Orccad? That
  is, events are objects/messages exchanged between components.
- Have you found the need to distinguish between `events' (`signals')
  and `commands'? Could they be implemented in the same class tree?

Some general questions:
- are the Orccad ideas suitable for supporting _general_ hybrid
  control systems? Or `only' for one particular sub-class?
- what are the fundamental differences between FSM/Petri-nets and the
  new vogue UML? (I think there are none: UML moves from
  object-orientation to dynamic agents and synchronisation, (Coloured)
  Petri nets move from dynamic agents and synchronisation to object
  orientation :-) The advantage of Petri nets/FSMs is that lots of
  implementation examples and experiences exist.

> The output of the two control laws are never merged!
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?

> >Can you refer to one particular publication where these specific
> >topics are explained in detail?
>
> Try that one:
> http://www.inrialpes.fr/bip/people/simon/rtcsa99.ps.gz
>
Thanks! BTW, you have already offered to give a seminar or so on this
topic; maybe there happens to be a similar event (organised at your
lab or somewhere else) in the not so far future and which Orocos people
could attend? I for one am quite interested in such an event... :-)

The `official' partners of the EU-sponsored Orocos project are
preparing a first Deliverable for the project, in which the major
components and design issues will be explained. I think it would be a
good occasion to see whether and where the Orccad experiences
could/should be integrated in these design..


Herman