Re: Opinions about HyCharts...

I have just finished reading the paper "A Modular Visual Model for Hybrid
Systems" by R. Grosou, T. Stauner and M. Broy. The paper presents a very
interesting piece of research, but I am not sure that it will advance us
significantly on our road to a robotics framework (as defined by the
Glossary). Here are my comments and doubts. Please note that we need to
design a robotics framework and the authors of the quoted paper deal with
hybrid  control systems. My comments are from the robotics perspective and
are not meant to criticise their work which is in somewhat different field.

1) First, the method of specifying semantics. Denotational semantics is
computationally based. The concept of computation is its foundation. Thus
recursion is of significant relevance. This results in the theory of domains
and fixed point equations that need to be solved. Usually denotational
semantics is used as a tool for proving program correctness. In our case we
can at the most prove that our program is correct in relation to the assumed
system model. But there still is no proof that the assumed model is correct,
and that is where we can expect to encounter major problems. If we need
denotational semantics only for the specification of component activity I
would rather stick to operational semantics which is more obvious, thus
easier to understand for the users. Bear in mind that we are designing a
tool that wil be used by people not necessarily well versed in theory of
computer science. Operational semantics still requires a model of the
machine (our system) but it operates on well understood (by engineers)
concept of the state of the machine rather than on domains and fixed point
equations.

2) Second, structure of the component. If we neglect for a moment the analog
functionality of the hybrid machine (presented in Fig.5 of the paper) and
concentrate on its discrete (digital) functionality we have an asynchronous
automaton (Moore type). What the authors call an idle state should be called
a stable state. Transitions take place through unstable states. I think that
one of the reasons the authors underscore the necessity of delays in the
feedback loops is that this requirement is inherent in the theory of
asynchronous automatons. Anyway those delays are always present - circuits
are designed with the use of physical elements that introduce lag. So their
term feedback inertia is this delay. When they speak of total mappings in
the firld of logical circuits we have complete functions (automatons). I do
not understand why the authors try to distinguish only the combinational
part of this otherwise asynchronous automaton, and do not treat it as a
whole. I think they would not encounter the theoretical difficulties they
have with the feedback delays then, and the description of the discrete part
of the system would be simplified - they could rely on state transition
tables or graphs.

3) Third, why an asynchronous automaton at all? It is difficult to see any
benefit in employing an asynchronous automaton here as the component itself
is synchronous anyway. I would rather make Com not combinational but rather
synchronous automaton (thus with memory). In this way the analog part and
the digital would not have to be merged.
All robotics systems are synchronous in nature as there is an underlying
freqency dictated by the servo sampling time. Thus synchronous automatons,
that are simpler to handle from the design perspective, should be prefared.

4) I did not read other works of the authors, so not all is clear to me. I
am not sure if the discrete part is binary in nature or is it discrete but
multivalued.

5) The authors claim that Com is non-deterministic. This is because more
than one guard (precondition) can be fulfilled, thus it is to some unknown
device to decide which action will be taken in such a case. I don't see any
benefit in this. Moreover the theory of automatons deals with
non-deterministic automatons (and even with probabilistic ones), but this
pertains only to the next state (this state may be determined
non-deterministically). Still there are algorithms for transforming those
automatons into deterministic versions. Com is a combinational automaton
(i.e. from the theoretical point of view you can say it has only one state),
so it would be difficult to implement this kind of indeterminism within the
realm of combinational automatons. Nondeterminism of the Com function would
make it a general mapping with the choice of one of the solutions made by
some device that is not specified by the authors. This device would be a
kind of memory, so is Com only combinational after all?

6) The last comment is more phylosophical in nature. How general do we want
to make our framework? If it will be so general that it will habdle not only
robotics systems but any control systems how easy it will be to implement
robotic systems using it? THe implementation of a robotic system might not
be obvious at all then, hence not many people involved in robotics will be
inclined to use our tool. I would rather stick to robotics and have only
robots in mind when devising the structure of the framework.

Cezary


----- Original Message -----
From: "Herman Bruyninckx" <[email protected]>
To: "Open RObot COntrol Software" <[email protected]>
Sent: Saturday, December 29, 2001 10:55 AM
Subject: [Orocos] Opinions about HyCharts...


> About the problem we discussed before, regarding a good modelling of
> system architecture and behaviour, I found some interesting reading on
> the concept of HyCharts, with more details on the home page of Thomas
> Stauner <http://www4.informatik.tu-muenchen.de/~stauner/>, and with
> an extensive document (PhD Thesis) on
>  <http://www4.in.tum.de/~stauner/papers/stauner-diss.ps.gz>.
>
> What are your opinions about this HyCharts approach? I like the
> explicit decomposition in architectural (structural) decomposition on
> the one hand, and the modelling of component behaviour on the other
> hand, because this is _very_ similar to the current state of the
> designs presented by LAAS and (not yet presented :-( ) by Leuven.
>
> Herman
>
>
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos