Code generation - Alternative to Simulink API

Question

This is about a typical problem in larger embedded system projects: Data from a text-file/database must be hard coded to C-code. The data will change the control flow, table dimension etc. What is the solution of choice?

Background: In our (large) embedded software we have to connect hundreds of signals (outputs of finite state machines) with busses (e.g. a CAN-bus). We are using Simulink/Stateflow as model-based development tool (state machines) and auto-coding.

The connection will have to scale, do dataype conversions etc. Usually all the information for the conversion/connection is stored in a database or file (e.g. dbc-text-file).

Apparently the usual dynamic way: reading the database and dynamically connect/convert accordingly is not indicated if hard deterministic realtime capability must be ensured. This data has to be hard coded.

We have not found a realistic and more practical way other than to use the Simulink API: write external m-code which reads the data from file and automates "drawing a picture" of the entangeld connections into the Simulink model! This is finally auto-coded to C. Needless to say, that this scripted "painting-code" - while effective - is not very reusable, maintainable etc. I can't find an effective solution even taking : compiler/code generation, model driven architecture, Autosar, model transformations, into consideration. Constructing for each external data-document an own compiler, which transforms the data to C-code, seems to be unrealistic ...

Is there a practical alternative? Is this a fundamental weakness of Simulink "language" (i.e. it has no underlying high level language like other model driven embedded-tools like modelica) ?

Answer 1

Your actual problem isn't really well described by your question.

The way I read it is that you have a complex set of data, that requires a complex code generation process. Whenever one needs a complex translation, you'll end up building complicated analysis and code generation machinery. That's generally not an easy task.

You've done it in two stages: 1) read the database and make Simulink, 2) let MATLAB compile the Simulink to source code. Your "database" content is in effect a specification (e.g., a DSL). You have a front end that reads the "spec" and interprets it into a Simulink model; you seem to be complaining that there is no underlying semantics for Simulink. Well... is there an underlying robust semantics for your specification DSL? That is probably part of your problem. Simulink itself has poorly defined semantics, too. The combination means that whatever ad hoc transformations you are doing from your DSL to Simulink, and from Simulink to C, is in effect ad hoc and likely difficult to maintain. We can argue about whether C has cleanly defined semantics; it sort of does but it isn't easy to see in the standards documents.

In any case, you are building a staged translator. Your first stage probably needs more structure and better analyses. Ideally you'd transform to an intermediate represention that was more formal; I always thought that Colored Petri nets were much better than Simulink, partly because they do have clear, formal semantics. (Modelica is pretty nice, too). Ideally you'd transform the intermediate stage into C using transformation rules you can control, rather that what Simulink happens to do.

This is easier if you have good foundation machinery on which to build translators. The best class of machinery for this purpose IMHO are program transformation systems. (I happen to build one of them [see bio], that knows C and Simulink already, and could be taught Modelica). You can read a bit more about what is needed in this SO answer on what it takes to build translators.

Answer 2

It's difficult to make out what your exact question is, but here are two suggestions:

If you're looking for a code generator that can generate code from your state diagrams which you can understand try fsmpro.io

For making individual logic, you'll have to paste code rather than using any inbuilt utilities to design units.