Ada automatic code generation for Simulink models

Ada automatic code generation for Simulink models

[John Kern]

I see that the Mathworks is dropping support for automatically
generating Ada code from Simulink models.  Has anyone from this group
tried this product for developing control software and found it to be
less than useful?  There seems to be a big push in the automotive
industry for auto code generation of embedded controllers.  Too bad that
we seem to be stuck with C.

RE: Ada automatic code generation for Simulink models

[Robert C. Leif]

From: Bob Leif
To: John Kern et al.

One long term solution is to create an Ada parser for MathML. I believe
most of the mathematics applications will eventually produce MathML.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of John Kern
Sent: Wednesday, May 29, 2002 1:28 PM
To: comp.lang.ada@ada.eu.org
Subject: Ada automatic code generation for Simulink models

I see that the Mathworks is dropping support for automatically
generating Ada code from Simulink models.  Has anyone from this group
tried this product for developing control software and found it to be
less than useful?  There seems to be a big push in the automotive
industry for auto code generation of embedded controllers.  Too bad that
we seem to be stuck with C.

Re: Ada automatic code generation for Simulink models

[Rod Chapman]

John Kern <jkern3@NOSPAM.visteon.com> wrote in message news:<3CF539BA.32BE0D15@NOSPAM.visteon.com>...
> I see that the Mathworks is dropping support for automatically
> generating Ada code from Simulink models...

I believe ADI's Beacon toolset has support for Ada (and SPARK... :-) )
code generation from Simulink models.  See www.adi.com
 - Rod Chapman, SPARK Team, Praxis Critical Systems

Re: Ada automatic code generation for Simulink models

[Stephen Leake]

John Kern <jkern3@NOSPAM.visteon.com> writes:

> I see that the Mathworks is dropping support for automatically
> generating Ada code from Simulink models.  

While I remain an ardent Ada fan, I actually don't have a problem with
this. 

What Mathworks is recognizing is that the user language is _Simulink_
(sorry, I don't know if it has another name), not either Ada or C. The
output format is irrelevant; it should not be read by people anyway.
Given that, and given that they don't want to write assembler or
object code, C is a good choice, since it is available for a wider
range of systems than Ada is.

If you want to incorporate the Simulink output in an otherwise Ada
product, define a stable interface and import it. That can be a pain,
I suppose, but you should only have to do it once. You need the stable
interface between the Simulink part and the non-Simulink part anyway;
clearly Ada is the best tool for defining that interface.

What we need to do is show that Ada is _as_ _good_ as Simulink, for
some class of applications. Clearly Simulink (and similar languages)
have niche markets where they are the right tool. I believe Ada is the
right tool for a wide range of markets.

-- 
-- Stephe

Re: Ada automatic code generation for Simulink models

[Simon Wright]

John Kern <jkern3@NOSPAM.visteon.com> writes:

> I see that the Mathworks is dropping support for automatically
> generating Ada code from Simulink models.  Has anyone from this
> group tried this product for developing control software and found
> it to be less than useful?  There seems to be a big push in the
> automotive industry for auto code generation of embedded
> controllers.  Too bad that we seem to be stuck with C.

I don't see quite why it matters, if you trust the generator? The C is
likely to be pretty readable (well, I guess I mean regularly
structured). Unless you get to modify the generated code ..

Re: Ada automatic code generation for Simulink models

[John Kern]

I guess what your are saying is to go ahead and allow code generators to
use the "Universal Assembly" language, and use Ada for only the parts
that cannot be modeled.  The auto industry is endeavoring to model the
whole ECU in either Simulink or UML, leaving no room or need for
generated Ada code.  However we still get bogged down with the
standardization and modeling of the tasking kernel, the unsafe C
constructs and MISRA compliance, weak typing and the representations of
variables, etc. which didn't seem to be that big a problem when using
Ada.

Simon Wright wrote:
> 
> John Kern <jkern3@NOSPAM.visteon.com> writes:
> 
> > I see that the Mathworks is dropping support for automatically
> > generating Ada code from Simulink models.  Has anyone from this
> > group tried this product for developing control software and found
> > it to be less than useful?  There seems to be a big push in the
> > automotive industry for auto code generation of embedded
> > controllers.  Too bad that we seem to be stuck with C.
> 
> I don't see quite why it matters, if you trust the generator? The C is
> likely to be pretty readable (well, I guess I mean regularly
> structured). Unless you get to modify the generated code ..

Re: Ada automatic code generation for Simulink models

[Simon Wright]

John Kern <jkern3@NOSPAM.visteon.com> writes (reordered to convention):

> Simon Wright wrote:
> > 
> > John Kern <jkern3@NOSPAM.visteon.com> writes:
> > 
> > > I see that the Mathworks is dropping support for automatically
> > > generating Ada code from Simulink models.  Has anyone from this
> > > group tried this product for developing control software and found
> > > it to be less than useful?  There seems to be a big push in the
> > > automotive industry for auto code generation of embedded
> > > controllers.  Too bad that we seem to be stuck with C.
> > 
> > I don't see quite why it matters, if you trust the generator? The C is
> > likely to be pretty readable (well, I guess I mean regularly
> > structured). Unless you get to modify the generated code ..
> 
> I guess what your are saying is to go ahead and allow code generators to
> use the "Universal Assembly" language, and use Ada for only the parts
> that cannot be modeled.  The auto industry is endeavoring to model the
> whole ECU in either Simulink or UML, leaving no room or need for
> generated Ada code.  However we still get bogged down with the
> standardization and modeling of the tasking kernel, the unsafe C
> constructs and MISRA compliance, weak typing and the representations of
> variables, etc. which didn't seem to be that big a problem when using
> Ada.

I did say "if you trust the generator". Clearly generating Ada
provides some external check on the generated code.

I would personally have little problem with a generated C model called
up by Ada (though your mention of "tasking kernel" does give me
pause. Does the generated code use this tasking kernel? perhaps that's
a new can of worms).

Re: Ada automatic code generation for Simulink models

[Stephen Leake]

John Kern <jkern3@NOSPAM.visteon.com> writes:

> I guess what your are saying is to go ahead and allow code generators to
> use the "Universal Assembly" language, and use Ada for only the parts
> that cannot be modeled.  The auto industry is endeavoring to model the
> whole ECU in either Simulink or UML, leaving no room or need for
> generated Ada code.  

What you are saying is that people are using Simulink or UML as the
source code, rather than C or Ada. There are real reasons for this;
controls engineers like to think in graphical diagrams. I think we
need to focus on getting the MathWorks and UML tool vendors to
appreciate the features of Ada that we like, and get them integrated
into Simulink and UML.

> However we still get bogged down with the standardization 

Standardization of what? The graphical modeling language? yes, that is
a problem, and a reason to use Ada instead of a graphical modeling
language. UML is a standard, but the standard language is _not_
powerful enough to generate a whole system, so people use non-standard
extensions.

Improving the UML standard is the best way forward from here;
hopefully, it will incorporate some of the software engineering
features of Ada.

> and modeling of the tasking kernel, 

If it's not an Ada kernel, you have this problem anyway.

> the unsafe C constructs 

What do you mean, precisely, by "unsafe"? Usually, in the context of
"writing C code", this means "constructs that are easily mis-used,
leading to maintenance problems". That's irrelevant if Simulink or UML
is the source language. 

Of course, there may be "unsafe Simulink constructs" or "unsafe UML
constructs". That would be a reason for using Ada instead, or for
fixing the Simulink or UML languages.

> and MISRA compliance, 

Don't know what this is; some industry standard, I guess.

> weak typing 

C weak typing or Simulink weak typing? C weak typing you don't care
about. Simulink weak typing is a problem (I haven't used it, so I
don't really know if it is weak). I believe UML has fairly strong
typing; on a par with C++ (not quite as good as Ada, but not "weak").

> and the representations of variables, etc. 

I can imagine that defining a "type" in Simulink or UML that matches
some hardware register would be hard, if not impossible.

> which didn't seem to be that big a problem when using Ada.

If the Simulink generated Ada, you still wouldn't be able to define a
Simulink "type" that matched hardware registers. Simulink is _not_
going to generate a representation clause for a bit-mapped record type.

If Simulink did let you define a bit-mapped hardware register, it
could generate a bit-mapped C struct, and hope the C compiler has a
"pack structs" flag; most do. So generated Ada would still not be
necessary. 


Make sure you are fighting the right battle; you need Simulink to be
more like Ada, not just Simulink to generate Ada.

-- 
-- Stephe

Re: Ada automatic code generation for Simulink models

[Simon Wright]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> John Kern <jkern3@NOSPAM.visteon.com> writes:

> > and MISRA compliance, 
> 
> Don't know what this is; some industry standard, I guess.

Motor Industry "standard" for writing safety-related software in C (and
C++? not sure)

Re: Ada automatic code generation for Simulink models

[Vinzent Hoefler]

Simon Wright <simon@pushface.org> wrote:

>Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
>
>> John Kern <jkern3@NOSPAM.visteon.com> writes:
>
>> > and MISRA compliance, 
>> 
>> Don't know what this is; some industry standard, I guess.
>
>Motor Industry "standard" for writing safety-related software in C (and
>C++? not sure)

Motor Industry Software Reliability Association

And yes, there's a MISRA-C too, see:

http://www.misra.org.uk/misra-c.htm

(Well, I haven't tried the link yet, but I've read, even they
recommend Ada or Modula for that...)


Vinzent.

Re: Ada automatic code generation for Simulink models

[Stephen Leake]

Vinzent Hoefler <JeLlyFish.software@gmx.net> writes:

> Motor Industry Software Reliability Association
> 
> And yes, there's a MISRA-C too, see:
> 
> http://www.misra.org.uk/misra-c.htm

Ok. There's a "preview" available for free; I looked thru that. It
looks like a good set of guidelines for writing C code for
safety-critical systems.

However, this came up in the context of using Simulink to generate C
code. In that context, insisting that the C code follow the MISRA
guidelines is silly. It's the Simulink code that needs to follow the
MISRA guidelines, since that' what the people are writing.

Apparently the MISRA guidelines were initially published in
lanuage-independent form; that publication is listed as out of print.

So now there needs to be a MISRA-UML and MISRA-Simulink.

-- 
-- Stephe

Re: Ada automatic code generation for Simulink models

[Dmitry A. Kazakov]

On 01 Jun 2002 11:11:32 -0400, Stephen Leake
<stephen.a.leake.1@gsfc.nasa.gov> wrote:

>John Kern <jkern3@NOSPAM.visteon.com> writes:
>
>> weak typing 
>
>C weak typing or Simulink weak typing? C weak typing you don't care
>about. Simulink weak typing is a problem (I haven't used it, so I
>don't really know if it is weak).

Typing is pretty strong when there is only one type... (:-))

>> and the representations of variables, etc. 
>
>I can imagine that defining a "type" in Simulink or UML that matches
>some hardware register would be hard, if not impossible.

In Simulink you should write a so-called S-function which is
responsible to implement a block that does something that Simulink
cannot do [=almost everything (:-))]. This S-function is written in a
"normal" language, like C.

It is no problem to have an Ada interface as long all is running in a
"simulation" mode under some OS. The real problem is the "real" mode
when your code linked with Simulink generated one runs on some
embedded system.

>> which didn't seem to be that big a problem when using Ada.
>
>If the Simulink generated Ada, you still wouldn't be able to define a
>Simulink "type" that matched hardware registers. Simulink is _not_
>going to generate a representation clause for a bit-mapped record type.

You do not need that, because Simulink is not a universal purpose
language. An engineer draws his diagrams and  gets some code
implementing the controlling loop [*]. That's it. The inputs, outputs
and parameters, all that cannot be implemented in Simulink, if they
are not built-in. In a really big concurrent system communicating over
ethernet, field buses, having unconvetional hardware etc., you really
really need Ada. Otherwise you have to implement all that stuff in C
meeting real-time conditions ...

... which brave engineers are doing so far!

>If Simulink did let you define a bit-mapped hardware register, it
>could generate a bit-mapped C struct, and hope the C compiler has a
>"pack structs" flag; most do. So generated Ada would still not be
>necessary. 
>
>Make sure you are fighting the right battle; you need Simulink to be
>more like Ada, not just Simulink to generate Ada.

The best way would be to abadon Simulink, but do not even think to say
that engineers!
---------------------------------

[*]  Once I asked an engineer to write manually a formula implementing
the bunch of blocks he was busily drawing on the blackboard. To that
time moment he had almost consumed all available space. After a
lengthy pause, he produced an expression containing pair +,- and one
*.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de