Can I decouple a time-consuming Simulink function block or Function-call subsystem from Simulink fundamental sample time?

I have a Simulink model performing fixed-step control algorithm in 0.1 second fundamental sample time. However when the control logic enters a certain mode, I want to carry out a time consuming calculation that will run in 100% cpu time for approximately 2 seconds. If I place this computation under any Simulink time step, it will definitely make the model overrun at that certain time step. But the result from this time consuming computation will first be needed when the normal 0.1 second fixed-step control algorithm executes for 1 minute. Can I place this time consuming computation in a Simulink function block or Function-call subsystem and decouple it from the Simulink solver? Such that the result from this time consuming computation will be placed in a data store whenever it finishes, but reading of that data store by the main algorithm will first occur after one minute? The main algorithm execution of once every 0.1 second will thus not be clogged by this time consuming computation module.

[Jonas]

There is no such thing as model overrun in simulation mode. Your computer just calculates what it needs to calculate, if it is computationally heavy it just takes longer.

Or are you talking about code generation? I would think not since you say 'Simulink solver'.

[Yingao Zhang]

Exactly, Jonas, I'm using Simulink for embedded algorithm development. And this will be deployed for real-time applications. Additionally, overrun can still be observed if one turns on simulation pacing, Simulink will notify you on the bottom left corner that the target pacing cannot be achieved when that time-consuming computation module activates. :)

Answer 1

[Jonas]

You need a background task to put those heavy calculations inside.

Depends heavily on your target if it will be easy or hard to implement the background task with code generation. Some hardware support packages may support it.

I generate code with two real-time tasks in Simulink, and then manually attach each task to either a real-time timer or an infinite background while-loop in code.

[Yingao Zhang]

Hi, Jonas, thanks for your suggestion, but that is what I truly want to avoid. Actually this goal can easily be achieved by multi-treading in C++ outside of Simulink. But with that I'm losing all the benefits of model based design. Especially the automated testing, such as SIL, PIL, and HIL. Do you still use the automated testing functions when generating two real-time tasks?

[Jonas]

• SIL is possible because it is basically the same as MIL but with the algorithms being generated code.
• PIL is indeed not possible.
• HIL is possible because the target hardware runs the generated code and hardware abstraction layer. The HIL device runs everything but the controller itself. It has no impact.

PIL is only possible if you create a custom target and integrate everything into Simulink. This on its own is a huge effort. I have decided to generate code from the controller, and then integrate into a HAL.

[Yingao Zhang]

Dear Jonas, that sounds exhilarating! May I get from you a dummy sample modeling of what do you mean by "two real-time tasks in simulink"? Do you mean enable concurrent executions in solver section under configuration panel? Thank you so much in advance:)

[Jonas]

Check this section in the documentation. It explains how a simple Stateflow can call function-call subsystems in a fixed order. The connected subsystems will be called once, every time the Stateflow is called. The trick is now to set a sample time for the Stateflow chart. All connected subsystems will now be executed with that sample time.

For code generation, you could create two of those Stateflows. One for the real-time task, and one for the background task. Give the Stateflow which is calling the real-time subsystems a certain sample time. Then, the other Stateflow calling the background task, give it a sample time which is for example half of the sample time of the real-time task. In generated code, two step-functions will be generated, one for each task. But then attach the step-function of the 'slower' sample time to a while-loop instead of a timer. Now it has become an actual background task.

[Yingao Zhang]

Thanks, Jonas. Let me just try to confirm again if this is what you suggest: what you are suggesting is actually export function call system as described in https://www.mathworks.com/help/simulink/ug/export-function-models.html The stateflow in your comment above is solely for simulation scheduling purpose and could be equally substituted by the Simulink schedule editor, right? The real production code integration merely schedules the two exported functions in C++ by hand, right?

[Jonas]

Yes.

[Yingao Zhang]

Thanks, Jonas. I'll tentatively accept your idea. Since I'm working with a model with 10k+ individuals blocks and 10min+ code generation time with 6 parallel cores enabled, refactoring every Simulink scheduled algorithm captured by ModelName.step() under rt_OneStep() is not a light work. Additionally, I have already used export function call subsystems several times in the model, however they are all interfacing with external I/O, instead of with Simulink generated functionalities internally. I believe there should be some mechanism from Simulink internally that enables calling function call subsystem under a different thread or a different task being preemptible by periodical tasks with higher sample rates.

[Yingao Zhang]

Dear, Jonas, I think your hint "hardware support packages" in your answer helps me solve the problem. I actually discovered these 3 blocks that can achieve the modeling goal with some adaption:

• Spawn task function as separate Linux Thread - Simulink (mathworks.com)
• Spawn task function as separate VxWorks thread - Simulink (mathworks.com)
• Run code of downstream function-call subsystem or Stateflow chart by spawning an example RTOS (VxWorks) task - Simulink (mathworks.com)

I hope that in the further, the C++ 11 std::thread, std::async ,etc. could be complemented as the fourth to the above three.