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

Hi again Herman, and others,

>>>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 :-)
> 
Useful and better, yes, but I guess I'm not able to provide convincing arguments
(via email). We would need no work out more complete examples in detail and have
discussions around it (when and where is the next orocos workshop?). Basically I
agree with Michael, and he already expressed many things better than I would
have been able to do, but the way you two don't quite understand each other is
kind of typical (experienced also in other cases). We simply have to build
systems and platforms that permit us together exploring these
issues/tools/principles.

>>
>>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.
> 
You are right, but wouldn't it be fine to generate that code from a declarative
description such as Modelica (into orocos components as I suggested in my first
mail). Not quite simple, however.

>>>>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.
No, you have to split the implementation bugs in two (or more) cases:
1. bugs that result in wrong results or in exceptions (or bugs that do not matter).
2. bugs that (additionally) result in platform instability or system crash
('blue-screen' intead of an exception that can be handled within the application).
With a safe language like Java, item 2 cannot be the case. Or, if it happends
anyway, it is a bug in the platform (OS/VM/compiler/..) and _not_in_your_code_.

> 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? 
> 
No, no; this is the most common misconception I know. On the other hand we have
to be carefule about the meaning of "influence" here: Yes, bugs will influence
other components, even so that the application can fail (complex systems as you
point out), but error/exception handling and the platform itself will continue
to work. Thus, with a safe language recovery is meaningful. With an unsafe
language, you need so much more engineering (as when ensuring that a JVM is
correct) to make a reliable system. With the manpower of Micro$oft, and for
major applications/components, it could be acceptable, but for orocos it would
be desirable to have components/interfaces providing Java-APIs (but to handle
real time has been a research issue, so the approach so far is OK).
> 
>>>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!
> 
Well, I'm not that positive to patterns, but I agree. In addition, however, a
safe laguage simplifies the development of advanced developments tool that still
permits handwritten code (since there is control over what that code can do).
IBM understands that (see www.eclipse.org, which is open source).

>>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 :-)

Well, note my comments above and also that I'm considering the "careless
application programmer": A safe language protects the careful expert!

> 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? 

An OutOfMemoryException resulting in a recovery to basic control is better than
a blue-screen requiring Ctrl-Alt-Del etc. But in a way you are right: with Linux
(or win2k but not win9x) and MMU support you can develop reliable systems. The
best is, however, a combination (i.e. a safe language on a robust platform).

> 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...
> 
Yes, including development tools and a JVM you need Mbytes. But compiled and
embedded, we only need a few Kbytes (including the RTGC). (Not yet available for
download, but very soon now ;-)

> 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...
> 
Correct, but they should not be able to kill others.....

> Herman
> 
-- Klas
-----------------------------------------------------------------------
    o--<    mail: Klas Nilsson, Department of Computer Science
     \      Lund Institute of Technology, Box 118, S-221 00 LUND, Sweden
      O     phone: +46-(0)46-2224304 (work), +46-(0)46-370160 (home)
+->>[_]    mailto:[email protected]   http://www.cs.lth.se/~klas
|
+-------<< Real-time << components << control << users << languages.