* Ada automatic code generation for Simulink models @ 2002-05-29 20:27 John Kern 2002-05-30 6:35 ` Robert C. Leif ` (3 more replies) 0 siblings, 4 replies; 12+ messages in thread From: John Kern @ 2002-05-29 20:27 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Ada automatic code generation for Simulink models 2002-05-29 20:27 Ada automatic code generation for Simulink models John Kern @ 2002-05-30 6:35 ` Robert C. Leif 2002-05-30 8:59 ` Rod Chapman ` (2 subsequent siblings) 3 siblings, 0 replies; 12+ messages in thread From: Robert C. Leif @ 2002-05-30 6:35 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ada automatic code generation for Simulink models 2002-05-29 20:27 Ada automatic code generation for Simulink models John Kern 2002-05-30 6:35 ` Robert C. Leif @ 2002-05-30 8:59 ` Rod Chapman 2002-05-30 15:20 ` Stephen Leake 2002-05-31 19:21 ` Simon Wright 3 siblings, 0 replies; 12+ messages in thread From: Rod Chapman @ 2002-05-30 8:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ada automatic code generation for Simulink models 2002-05-29 20:27 Ada automatic code generation for Simulink models John Kern 2002-05-30 6:35 ` Robert C. Leif 2002-05-30 8:59 ` Rod Chapman @ 2002-05-30 15:20 ` Stephen Leake 2002-05-31 19:21 ` Simon Wright 3 siblings, 0 replies; 12+ messages in thread From: Stephen Leake @ 2002-05-30 15:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ada automatic code generation for Simulink models 2002-05-29 20:27 Ada automatic code generation for Simulink models John Kern ` (2 preceding siblings ...) 2002-05-30 15:20 ` Stephen Leake @ 2002-05-31 19:21 ` Simon Wright 2002-05-31 20:19 ` John Kern 3 siblings, 1 reply; 12+ messages in thread From: Simon Wright @ 2002-05-31 19:21 UTC (permalink / raw) 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 .. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ada automatic code generation for Simulink models 2002-05-31 19:21 ` Simon Wright @ 2002-05-31 20:19 ` John Kern 2002-05-31 20:59 ` Simon Wright 2002-06-01 15:11 ` Stephen Leake 0 siblings, 2 replies; 12+ messages in thread From: John Kern @ 2002-05-31 20:19 UTC (permalink / raw) 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 .. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ada automatic code generation for Simulink models 2002-05-31 20:19 ` John Kern @ 2002-05-31 20:59 ` Simon Wright 2002-06-01 15:11 ` Stephen Leake 1 sibling, 0 replies; 12+ messages in thread From: Simon Wright @ 2002-05-31 20:59 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ada automatic code generation for Simulink models 2002-05-31 20:19 ` John Kern 2002-05-31 20:59 ` Simon Wright @ 2002-06-01 15:11 ` Stephen Leake 2002-06-01 17:09 ` Simon Wright 2002-06-03 9:41 ` Dmitry A. Kazakov 1 sibling, 2 replies; 12+ messages in thread From: Stephen Leake @ 2002-06-01 15:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ada automatic code generation for Simulink models 2002-06-01 15:11 ` Stephen Leake @ 2002-06-01 17:09 ` Simon Wright 2002-06-01 18:23 ` Vinzent Hoefler 2002-06-03 9:41 ` Dmitry A. Kazakov 1 sibling, 1 reply; 12+ messages in thread From: Simon Wright @ 2002-06-01 17:09 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ada automatic code generation for Simulink models 2002-06-01 17:09 ` Simon Wright @ 2002-06-01 18:23 ` Vinzent Hoefler 2002-06-01 19:38 ` Stephen Leake 0 siblings, 1 reply; 12+ messages in thread From: Vinzent Hoefler @ 2002-06-01 18:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ada automatic code generation for Simulink models 2002-06-01 18:23 ` Vinzent Hoefler @ 2002-06-01 19:38 ` Stephen Leake 0 siblings, 0 replies; 12+ messages in thread From: Stephen Leake @ 2002-06-01 19:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ada automatic code generation for Simulink models 2002-06-01 15:11 ` Stephen Leake 2002-06-01 17:09 ` Simon Wright @ 2002-06-03 9:41 ` Dmitry A. Kazakov 1 sibling, 0 replies; 12+ messages in thread From: Dmitry A. Kazakov @ 2002-06-03 9:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2002-06-03 9:41 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-05-29 20:27 Ada automatic code generation for Simulink models John Kern 2002-05-30 6:35 ` Robert C. Leif 2002-05-30 8:59 ` Rod Chapman 2002-05-30 15:20 ` Stephen Leake 2002-05-31 19:21 ` Simon Wright 2002-05-31 20:19 ` John Kern 2002-05-31 20:59 ` Simon Wright 2002-06-01 15:11 ` Stephen Leake 2002-06-01 17:09 ` Simon Wright 2002-06-01 18:23 ` Vinzent Hoefler 2002-06-01 19:38 ` Stephen Leake 2002-06-03 9:41 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox