Re: Re: dynamics: comment about MBdyn...

On Wed, 16 Jul 2003, Klas Nilsson wrote:

> Herman, all fine until:
> 
> >>* Flexible or intelligent control systems need a dynamically on-line
> >>changing structure, including a lot of code that are not very
> >>suitable to express in Modelica, that does not fit with the
> >>declarative nature of Modelica (unless you want to embedd Dymola in
> >>your system..).
> > 
> > No, but:
> > - Modelica is just an input/output format. 
> > - internally, the models and their physical meaning and mathematical
> >   representations are available in efficient compiled code, so
> >   real-time model switching _is_ possible.
> > - As I said in a previous mail, I am quite confident that this same
> >   "real-time structure" is useable for _all_ sorts of hybrid systems,
> >   such as controllers, and "behaviour based agent systems".
> > 
> Hmm, I disagree 
Nice to know :-) But it would be more useful to know why excatly you
don't agree :-)

[...]
> >>Also from Scilab (the only free tool I know that includes features
> >>corresponding to simulink) generation of orocos components would be
> >>desirable (to comply with the same execution interface as from
> >>Modelica), but for the case of composing control blocks internally
> >>expressed in imperative form, thus preserving the model/design
> >>structure during execution.
> > 
> > I do not understand what you mean with this last sentence...
> > 
> In tools/systems such as Scilab without the symbolic capabilities like 
> in Dymola, already the model (possible except for some ordering) defines 
> the executable code (as defined in the used imperative language like C).

Ok, I can indeed imagine that a (large) subset of all systems have a
natural causality, such that they can be translated into code in one
pass. Most controllers are like this, and that's the fundamental
reason why you can do real-time motion control :-)

But "hybrid" systems have changing causalities. And that means that
_somewhere_ you have to "solve loops", i.e., to look at a part of the
system that is much larger than one single connection between two
components in the system, and determine when and how the causality
changes. This can be done during parsing, if one has full knowledge
about how the system _can_ change; the result is a FSM-like
controller, where each hybrid transition results in the execution of
the controller in another state.

> > 
> >>Note that in the two cases (Modelica and Scilab) above, composition
> >>cannot result in components damaging data (or code) for other
> >>components, but if the user writes application code in e.g. C/C++
> >>anything can happen. 
> > 
> > Not true if you use the Factory pattern! (If correctly coded) this can
> > only produce consisten models. (THe burden of correctly coding the
> > Factory is with the framework builders (i.e., the experts, and they
> > have to do it only once), and not with the users when they model.
> > 
> As you say: "If correctly coded", but that is never(?) the case for a 
> large system. I'm talking about the real case when there are some bugs 
> in some components: will they damage other parts of the system and 
> finally end with a blue screen, or should bugs stay in their sandbox so 
> the can be found with limited engineering efforts?

There are two sorts of bugs:
- syntactical: you made a wrong implementation of a correct design.
- semantical: you made a wrong design; or a wrong model of the world.
I think that, almost by definition, you cannot have a "sandbox"
security, for either of these bugs, because all components are
interconnected and an error (of whatever origin) _will_ influence the other components. That's the essence of a complex system, ins't it? 

> > I am really beginning these (by now already) classical Software
> > Patterns enormously, because they avoid making all these stupid
> > design errors over and over again.
> > 
> Design errors are different: those are not avoided by a safe language, 
> and patterns help....

Patterns are all about _design_ :-) I know that pattern won't help you
to 100% avoid errors, but they are definitely the most helpful
software engineering concept that I have seen in my 20 years of
computer science experience!

[...]
> Using Java (the language; not the standard JVM which is not real time) 
> you cannot access memory outside your component, except for objects that 
> have been provided from outside (via method arguments etc, and then only 
> those objects can be referenced and in a safe and controlled manner). 
> For generated code, for device drivers, and for standard/optimized 
> blocks in code libraries, you should use C since Java is 
> unsuitable/impossible to use. For the rest, a safe insdustrially 
> accepted object-oriented RT-suitable language should be used, and Java 
> is the only such language that I have found.
I agree to a large extent. But what is the difference between relying
on somebody else's correctness of the Java implementation versus
relying on somebody else's correctness of implementation of the system
model components with which we build our complex controllers or system
simulations? Both have to be debugged by the experts, such that no
semantic or syntactic errors exist in the building blocks anymore;
both can and will be misused by careless application programmers :-)
What is worse: a stray pointer in C that causes your application to
crash, or a badly programmed Java code that makes and destroys so many
new objects behind the screens that you fill up your memory and slow
down your system to a creeping halt? What I see in the practice of our
CS students is that all need at least 512 MB on their computers to
model and run simple Java programs...

But basically you are right of course :-) The only thing I am very
sure about: no tool or design can prevent stupid users from killing
their application...

Herman

-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480