Why should a model not contain continuous states for production code generation?

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?

[yogesh s]

https://www.mathworks.com/matlabcentral/answers/36663-what-are-continuous-and-discrete-states-in-simulink#answer_45872

Does this help you ?

[René Schwarz]

@yogesh s Thank you for you comment. The difference between continuous and discrete states is clear to me. The justification why models with continuous states should not be used for production code generation (with a fixed-step solver, of course), however, is not.

Answer 1

[Fangjun Jiang]

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.

[Paul]

Why is C2D in the discussion? The first part of your answer suggested that, in principal, ode4 could be implemented in the embedded code. Would doing that be a problem for some reason?

[Fangjun Jiang]

I got your point.

ode4 solution for a continuous state could be implemented in the embedded code, so is ode2 or ode3. There is no problem for that. But the "generated code" for using ode2 would be different than using ode4. I was afraid that not everybody would understand why the "generated code" would be different between ode4 and ode2.

So I used c2d() and its example to explain and visualize the difference. Simulink use sldiscmdl() to discretize a continuous model but the underline function is c2d().

Once a model is discretized, the "generated code" would not be different between ode2, ode4 or discrete solver. (ode2 or ode4 could be used for a discrete model, or a mix of discrete and continuous model).

[Paul]

The results would be different between ode2 and ode4. But the original question, at least as I understand it, is why can't embedded code be generated with a fixed step ODE solver, which would be whatever solver is specified in the Simulink model? I'm not saying that it could be (or even should be), but the question is if there is a fundamental reason why it can't be done or if it's just something TMW chose not to provide?

[René Schwarz]

Thank you for your answer. Just to make my question a bit more clear: Simulink Coder & Embedded Coder are actually able to generate code from models with fixed-step, continuous (non-discrete) solvers such as ode4 or ode1be. The aforementioned guideline, however, requires to use a fixed-step, discrete solver for developing high-integrity systems. The justification for this is not clear to me.

I could speculate about the background for this recommendation: As continuous solvers use numerical integration to compute the model's continuous states, it might be related to the stability/convergence of integration (and, in consequence, determinism of the software execution) or that a certain numerical accuracy cannot be guaranteed within the assigned execution rate (= step size) of the generated code. But as I said, these are just speculations from my side.

[Fangjun Jiang]

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.