Guy and Seth on Simulink

May 14th, 2011

In Simulink R2011a, it is possible to pass asynchronous function-call signals through Inports of a model. This enables the asynchronous function call to cross the bounary of Model block. Such function-call signals are typically used in Simulink models to capture interrupt-driven processing that is asynchronous with the time-driven processing in that model.

In this post I want to provide an overview of the effects this enhancement could have on your models.

Simulink models can be structured in multiple ways. If you work in the automotive industry your model probably looks like one of the 2 types shown in this image, taken from the MAAB Control Algorithm Modeling Guidelines.

In type A, when you open a model you see a trigger layer. The trigger layer groups algorithmic components into common rates subgroups. This trigger layer can be componentized using Function-Call Model Reference. When opening your model, what you see looks like this:

When you open a model of type B, you see the functional structure of the model. In my opinion, type B has many advantages over type A, for instance type B accurately captures both the timing and data dependencies between components more explicitly.

Before R2011a, componentizing the structural layer of a type B model using referenced models was not possible if the model contains asynchronous events. Now that asynchronuous function-call can be passed through input ports of referenced models, this type of componentization becomes possible:

Converting the structural layer to use model reference has the benefit that you have more rigorous componentization of this layer.

To learn more on that topic, I recommend going through the documentation section titled Converting an Asynchronous Subsystem into a Model Reference. After you converted the subsystem into a referenced model and configured it properly, you need to insert the Asynchronous Task Specification block, set its priority to the same as the incoming function-call, and configure the Inport block to output a function call:

Are you going to take advantage of the possibility to pass asynchronous function call through referenced models inputs? Leave a comment here.

By Guy Rouleau

21:59 UTC | Posted in Model Reference, Model-Based Design, Standards and Guidelines, What's new? | Permalink | 2 Comments »

You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

2 Responses to “Asynchronous Function-Call Inputs to Models”

1. Peter Murphy replied on December 14th, 2011 at 13:50 UTC :
   

   Hi Guy, thanks for posting this.

   I currently have a Type A structure for an automotive engine controller. It has tasks that are periodic in both time and in angle. Of course I also have asynchronous event type triggers as you show here. For this reason, I have implemented all of my tasks as asynchronous in order to interface to my embedded RTOS. My question is, can a reference model still be function-call triggered, yet still have asynchronous event function-call signals at its Inports? A simple example would be an event generated from a communications link to clear a variable that is otherwise processed in the periodic task. Would the event get processed immediately, or only when the periodic task runs?

   If this is possible, then this scheme might be useful to me.

2. Dan Humke replied on January 18th, 2012 at 23:56 UTC :
   

   I am interested in using root level asynchronous function call inputs as shown in the Type B format above with the referenced models. However, I would like to build stand-alone code for each of the referenced models (i.e. Sensor Processing, State Machine, etc. above), but not have to generate code for the parent model. For my case, it is because the parent model is simulating behavior found in the hardware that the generated code is to run on, and therefore that behvaior is not needed in the generated code. I am wondering why stand-alone code is not allowed for models that contain root level asynchronous function call inputs, and what is being done to address this workflow gap.

Leave a Reply

<pre class="code">
a = magic(3);
sum(a)
</pre>

These postings are the author's and don't necessarily represent the opinions of The MathWorks.