RE: Design draft for kinematics/dynamics library...

On Mon, 12 May 2003 [email protected] wrote:

[...]
> > The big difference between Modelica and my design is that the latter 
> > focuses on the _software engineering_ aspects, and Modelica only on
> > the modelling. Both are complementary, of course.
> 
> But what you describe in that document seems to me to be almost exclusively
> on the modeling.  

Then you are mistaken :-)

> I get the impression from reading your "Object-component
> decoupling" section that you think the software engineering should be
> completely decoupled from the physical representations
Not at all: I want to have a good software engineering, _also_ at the
level of representations.

> But on the other
> hand, much of what you talk about seems to be in building in domain/problem
> specific details into the underlying framework 

I don't understand what you mean.

[...]
> > Another difference is that we need a much larger set of geometric
> > primitives; for example, I don't think that Modelica will want to
> > include the concept of logarithm and exponential of position and
> > velocity, respectively.
> 
> I'm still not clear why this is an issue.  In Modelica, the only built-in
> types are "Real", "String", "Boolean" and "Integer".  All other types are
> derived through inheritance from these.  So if you want to define a data
> type for the logarithm of position, you can do it easily enough as:
> 
> type PositionLogarithm=Real(quantity="Logarithm of position", unit="...");

Of course. But how does that help me in my real-time control software?
And why would I want to connect the fate of Orocos on 

[...]
> Now that you mention graphics, I would point out that this is yet another
> area of Modelica that you could potentially leverage since the specification
> includes a description of how graphical annotations should be specified.
> Furthermore, the graphical annotations are just a special case use of the
> general purpose annotation system for handling meta-data within your model
> (which might also be useful to you).
You cannot be serious to take Modelica's annotation system serious :-)
I so flexible that it allows to describe anything in annotations.
Which is a step backwards in my opinion: the annotations don't add
_any_ systematic structure to information.

[...]
> I mention all this because you are emphasizing the software engineering
> aspect and it seems to me that the software engineering plays a major role
> only in the second phase whereas the web page I was commenting on seems to
> be describing larging the physical domain details.
Then you are wrong :-) But of course, I may probably not have been
clear enough.

[...]
> Yes, modeling.  Writing software in Modelica itself isn't really a practical
> option (at least at this point in the language development).
So, that's why I think there is a need for something "more"...

[...]
> > > My guess is that what you are looking for is
> > > perhaps a way of describing state charts or perhaps a general
> > > discrete event modeling system.
> 
> > This is indeed one of the components that we need.
> 
> This is an area where only a little work has been done in Modelica.  Other
> groups I know of have adopted UML for activities like this.  While Modelica
> allows you to express discrete event behavior, it isn't clear to me that you
> would necessarily want to apply it to embedded systems (if that is your
> goal).  

Why not? Why shouldn't embedded systems have a need to describe the
logic of the progress of their activities? I think whether or not an
application is embedded changes anything at all for the things we are
discussing.


> It may even be necessarily to capture this kind of behavior with
> some higher-level modeling formalism specifically for state charts, etc. and
> then have a way of exporting it as Modelica code if you want to integrate it
> into a model of a system.  These are interesting topics and represent an
> area where the Modelica Association would be interested in
> feedback/participation.
I think Modelica should not try to integrate hybrid systems into its
modelling language: let these difficult things out of the language,
and just make sure that you introduce the "event" concept inside of
Modelica. Events are the basic building blocks with which you can
implement all kinds of discrete behaviour.

[...]
> > > I am quite confident that there
> > > is no way that the Modelica Association could be any more "open".
> > 
> > Well... I get a different impression when I read things like "The
> > Modelica Association owns and administrates incorporeal rights related
> > to Modelica, including but not limited to trademarks, the Modelica
> > Language Specification, Modelica Standard Libraries, etc., which
> > should be generally available for the promotion of industrial
> > development and research."
> 
> All that is saying is that we protect the rights to the name so that another
> company cannot come along and assume control of all software/projects using
> the name.

That's the trademark part of thic clause. And that's the one I have
not problem with. But the other statements worry me much more: does
that mean I am not allowed to make a Modelica drawing and publish it,
or use it in my project? The least you can say is that the statement
sounds like a very "closed" one to my free software ears :-)

[...]
> Honestly, I don't think it is really fair to claim that we aren't "open"
> based on the language you are quoting.  Look at OMG, they do the same thing
> (and I don't blame them).  You don't have an issue using CORBA 
Not at all. And I don't have an issue using Modelica. It's just that I
don't think either OMG or the Modelica Association are real supporters
of open source _software_. (I also don't think they are hostile to
it.)

[...]
> If you judge us by our actions, I cannot see how you could fault us.
I don't fault you ! But I am prepared to judge you from your actions:
where is the open source Modelica implementation? :-)
Just a joke! But I do have the very strong feeling that the Swedish
companies (Dynasim in particular) are still the number one force
behind Modelica, and that makes me be careful. 
[...]
> > That's exactly what I tried to do: I think that there is nothing in
> > Modelica that I don't cover also. But I paid more atention to the
> > software engineering, and not just the modelling.
> 
> I guess I'd be more satisfied if you used the language itself.  

You answered this "problem" yourself: Modelica is a modelling _language_,
so, you can use Modelica to store and transmit models, which can then
be processed by _any software_ that cares to  write an interpreter for
it. The language, however, is not part of the design I presented,
because it is obvious that the sofware and the language can be made
compatible with minor efforts.
There _is_ a big problem though: Modelica is mature, I don't have any
code at all yet :-) But that's my problem, not yours :-)

[...]
> Ultimately, the choice is yours and I will respect whatever you decide to
> do.  My point in this discussion is really just to make it clear that I
> think that Modelica compliments what you are doing 

We agree on that!

> and to give you a point of contact in case you are interested in
> pursuing that.
I know. And I knew before you told me. But that's not important: I
appreciate your dicussions, because I did learn from them :-)

Herman Bruyninckx

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