Why should a model not contain continuous states for production code generation?
22 views (last 30 days)
Show older comments
In the "Simulink Modeling Guidelines for High-Integrity Systems", guideline hisl_0041 ("Configuration Parameters > Solver > Solver options") mandates to configure the solver in the model configuration parameters to a fixed-step type and the specific solver to "discrete (no continuous states)". This is justified by "Generating code for production requires a fixed-step, discrete solver.".
While I can understand that using a fixed-step solver is necessary for code generation, I am struggling with the reasoning behind having a discrete solver (and, in consequence, no continuous states within the model).
Can someone explain this reasoning to me?
Answers (1)
Fangjun Jiang
on 2 Feb 2021
Edited: Fangjun Jiang
on 2 Feb 2021
On a model with continuous states, you can run a simulation with fixed step size using a solver, e.g. ode4. In fact, the simulation is run on a digital computer. All the arithmatic operations are discrete step by step operations. Code can be generated to match those operations and can be used in an embedded micro-controller.
At issue is the consistency or determinstic of the generated code. When you run c2d() on continuous state 1/s, the resulting discrete transfer function is quite different depending on the discretization method. The discrete transfer function determines the arithmatic operation in the generated code. Thus, the generated code would look drastically different.
For a model with continuous states, Mathworks could apply the c2d() automatically with some default settings and then generate code. There is no techincal difficulites here. But the code will look quite different depending on some settings. The generated code doesn't match with a continuous transfer function as well as with a discrete transfer function.
So Mathworks chose not to do this. They want the users to do the c2d() discretization by themselves and put the discrete states directly in the model.
>> c2d(tf(1,[1,0]),0.1,'zoh')
ans =
0.1
-----
z - 1
Sample time: 0.1 seconds
Discrete-time transfer function.
>> c2d(tf(1,[1,0]),0.1,'tustin')
ans =
0.05 z + 0.05
-------------
z - 1
Sample time: 0.1 seconds
Discrete-time transfer function.
5 Comments
Fangjun Jiang
on 3 Feb 2021
That is a good point too.
The short answer to this is that it could be done but the Mathworks chose not to do it.
The rational behind it is that it has many un-deterministics. Industry experts on embedded application, safety, etc. agreed with it.
See Also
Categories
Find more on Simulink Coder in Help Center and File Exchange
Products
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!