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

On Mon, 3 Dec 2001, Daniel Simon wrote:

[... I'm also answering to Cielinski's reply...]
> We have such kind of reconfiguration in Orccad, where the whole running
> control law can be stopped and replaced by a new one during task execution.
> Thus control laws are encapsulated in a logical behaviour stating starting,
> stopping and exception handling. As hand writting of FSMs by hand  is
> difficult and error prone, this logical behaviour is specified with Esterel,
> thus most of the job is done by the strl compiler. Obviously this model can
> handle control tasks running in parallel.

Thanks for the insights! Seems that there is quite some prior
experience in this point, which is great. One question I still have is
this: I would imagine that one needs _more_ than a logical behaviour,
in the sense that many control laws have _dynamic_ implications, such
that time and smoothness constraints are, in general, important. Any
experience with including these into Esterel (or other) descriptions?
Any idea how much of this functionality can/should be visible to the
`normal' user? (That is, not the designer of the framework, but the
guys that implement the control law and trajectory generation
components.)

Herman