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

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 or don't understand what you mean, or you have not 
grasped Michael's comments (before and after this mail).
> 
>>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).
> 
>>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?

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

>>Hence, scalability is limited.  That is why
>>orocos also need a real-time Java (or in any other accepted compiled
>>safe programming language without constructs preventing 
>>hard real time) programming interface, but that is another story. DS
> 
> I do not follow this jump to RT Java... :-) (Java is also using the
> Factory pattern internally, as far as I know.)
> 
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.

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