RE: Modelica

On Mon, 30 Jul 2001, Tiller, Michael (M.M.) wrote:

[...]
> > So, back to the real subject of the message: your remarks about Modelica
> > represent my personal questions and uncertainties quite well too (and
> > that of most others, I think): what exactly can Modelica bring us?
> > What exactly are its deficiencies? (If any.) What exactly is
> > available/needed/desirable as computer tools to work with Modelica?
> >
> If you can provide me with more detail about what it is you would
> like to do, I can attempt to provide you with additional information
> about how those details may be related to Modelica.

An attempt to answer this question:
for the mechatronic part of the modelling of robot systems,
I think Modelica is suitable (as proven by the examples of Martin Otter).
But for other modelling parts, Modelica is not suitable (I think): I
mentioned already trajectory specification and component configuration
in another email.

[... `embed' Modelica into XML...]
I think you give interesting examples!

> A tool reading this XML may not care about the actual contents of
> the model "MyRobots.Experiment1.MinimumPower" but if they do, there
> is nothing that prevents them from using a Modelica parser to
> extract additional information about that model.

Indeed. So, one part of the modelling language discussion seems to
focus on this key question: what is the trade-off between the `cost'
of
 (i) developing an XML-based modelling language for the mechatronics of
     robot systems to replace Modelica,
and
(ii) maintaining tools and documentation for two modelling languages.

The fact that Modelica is taken care of by a competent set of
independent people and companies can be both an advantage (reduced
development cost) as well as a disadvantage (difficult to get into
Modelica exactly what we want; updates forced onto Orocos externally,
i.e. when the Modelica specification changes).

I don't have a thought-out answer to this question at this moment :-)

> My suspicion is that you deal, in robotics, with many of the same
> issues that we deal with in powertrain modeling and simulation.

Indeed: dealing with complex systems...

> The problem I see with trying to encompass all of this with an XML
> schema is that I would be concerned with the resources necessary to
> recreate all the intellectual content of the various existing pieces
> (e.g. Modelica).  Obviously, this has to be weighed against the
> awkwardness of using/creating a patchwork of existing tools and
> technologies which are not very coherent when "integrated".

I tried to express the similar trade-off above. Maybe others can judge
better whether we are really talking about the same trade-off :-)

[...Four Modelica features:...]
1.:
> This gives you the structured data and validation capabilities.
> I just point this out as an example, not to advocate it for your
> particular application.
My evaluation: XML wins in this field.

2.:
> First, it is clear from the data what the types of the elements are
> (i.e. not need to look back at the schema to find out whether
> something is a real or a string).
My evaluation: this is a good feature for human interaction,
but irrelevant for the software.

3.:
> In addition, Modelica has fairly elaborate array specification
> syntax which is quite convenient.
My evaluation: I should take a closer look at this issue...

4.:
> Finally, Modelica has a mechanism for redeclaring/replacing
> components and types.  The best thing I can compare this to is the
> "template" system in C++.  Extending the example above, you might
> define some addition records of the form:
>
> record WelderBase
>   extends Base;
>   Boolean has_GFI "Has a ground fault interrupt circuit";
> end WelderBase;

I have the impression that this is more similar to inheritance than to
templates? Anyway, it is definitely an interesting feature, and I
should check my XML references to see what is available at the XML
front.

[...]
> > But having a DTD allows for quick checking of (formal) correctness of
> > data, which is a valuable, although minimal requirement for the
> > consistency of an orocos system.
>
> My only comment would be that you may want to limit the depth of
> this validation.

This is an interesting remark which I have not considered before. I'll
keep it in mind for further reflection :-)

Herman