Guy on Simulink

Simulink & Model-Based Design

Model-Based Design Dilemma 15

Posted by Guy Rouleau,

I am currently working on a model and I have a dilemma. There are two ways I could model my system. I need you to tell me which approach is best and why.

I need your help!

The Goal

I am building a model to drive a small robot made of Lego blocks. The system is similar to the NXTWay-GS submission on the MATLAB Central.


Following a Model-Based Design approach, I want to setup my files so that I can easily develop my controller in simulation and generate code to test my algorithm on the real hardware. This means that in simulation I need to send my actuator commands to an LTI system approximating the system dynamics; and for code generation I need to send and receive signals from hardware drivers.

Hardware drivers and simulation model

My question now is: What is the best way to include these 2 sets of blocks in my model architecture?

Option 1: Two Top Models

My first option is to create 2 top models that will both refer to the same controller using model referencing.

I would have one top model for simulation:

Model for simulation

and one top model for code generation:

model for code generation

Option 2: Subsystem Variants

My second option is to create one top model. In this top model, use Subsystem Variants to switch between the simulation and the hardware drivers:

One top model with 2 variant

Now it's your turn

What architecture do you prefer? For which reasons? Do you see other options? I am very interested to hear your comments and ideas. Please leave a comment here.

15 CommentsOldest to Newest

Peter Stubberfield replied on : 2 of 15

I would consider carefully which option would give me the best control over the artefacts in my versioning system and lend itself best to parallel development. I suspect the first option would be better in this respect, at least in the way they are structured currently.

A third way would be to have your controller in a library which is linked to by your two top-level context models. Traditionally I would have done it that way, but you don’t mention this option.

Guy Rouleau replied on : 3 of 15

Thank you for the comments

@Paul: I could have provided more details on that. Inside the controller, I have different options to receive or generate reference signals. The 2 references are a forward velocity in m/s and an angular velocity around the vertical in rad/s. Depending on the test, they can come from basic Simulink source blocks, a Stateflow Chart, or through a Bluetooth communication link. I will consider making another post in the future showing more details on that.

@Peter: Your points about version control and work in parallel are good things to consider.

I agree with you that, traditionally, libraries have been used to componentize models to allow development in parallel. However, in recent releases model referencing is more appropriate for this task. It offers multiple advantages, for example incremental build.

I prefer to use libraries to create utilities (masked atomic subsystems) to be placed in the library browser and that users are not supposed to modify.

Bob replied on : 4 of 15

I’m behind the times.

Most of the time I use one library model referenced from two top level models, as suggested by Peter.

This works well in the version control system. This makes it easy to handle different initialization and model settings for the two uses. It also makes it easy to handle multiple code gen models.

(We don’t yet use Model Reference. We have a chicken & egg problem with our custom target. Nobody uses it because when they started it wasn’t an option. We didn’t add it as an option because nobody used it. Now its an option, but nobody uses it because it doesn’t have a long track record of success like libraries, and our implementation of it may have bugs because nobody uses it. Guy’s comments about model referencing being more appropriate are something several users have heard, and a couple would like to experiment, when they have the time.)

One time I did something like Option 2. The differences were it was in R2009b and so I used Configurable Subsytems and that I didn’t have the I/O all grouped together (some of it was in a function call subsystem triggered during an interrupt). I’d advise anyone to use Variant Subsystems instead, MATLAB crashed regularly with the Configurable Subsystems. But generally it just feels hard to get a consistent interface with the simulation and code gen, and so option 1 feels more natural.

Gwenolé LE PACHE replied on : 5 of 15

We’ve had a similar dilemma a short while ago when we had to compile our model for real-time use on a bench. However, our goal is to run the simulation model in real time, not the controller (compiled through a different procedure).

The previous model was still using Matlab 6.1 R12 (2001 !), and back then the process was as follow :
– Create a new library dedicated to hardware interfaces (for source control reasons)
– Implement everything through switch-based logic, ie the source is either the simulated system or the driver ports and the source can be changed through a single variable.
– Run a script to remove the unused subsystems before compilation.
Obviously this technique was quite demanding. I don’t know the full history, but I think it was done that way due to the limited knowledge they had at the time. Its only useful side is that you can switch from real inputs to simulated inputs while the model is running.

We’ve had to rethink the process in our last model. Matlab 2009b was used, and the vast majority of our subsystems are now referenced models.
We went with something similar to option 2, except that Configurable Subsytems are used as Variant Subsystems were introduced in 2010. Given that we are working on the simulation model and not the controller, we needed multiple points of entry and thus used more than one configurable subsystem. Actually, instead of putting the whole model inside the configurable subsystem, we added a configurable subsystem on each bus from one referenced model to an other. The “normal” mode is just an output connected to the input, and the “real-time” mode usually redirect the signals to a bench input/output, possibly with some conversions or transformations.
So why didn’t we use option 1 ?
– We’ve had difficulties transforming the whole model into a referenced model due to some very surprising behaviors coming from our level-2 S-function (fortran + C).
– Our target doesn’t allow us to see/use anything inside of referenced models. Our configurable subsystems are on the buses and thus not inside a referenced subsystem.

The downsides are the need to launch a script to switch the configurable subsystems and delete the controller, but we’ll probably put the controller inside another configurable subsystem for easy replacement. In the end, it’ll be quite similar to option 2, just with more subsystems.

Paul replied on : 6 of 15

I find this topic of discussion very interesting, and I hope this theme can continue in future posts. This topic could perhaps be summarized as ‘Improvements to the Model Based Design *Workflow*’? The *Workflow* is heavily dependent on the available tools. For example, I just realized that Configuration Reference is currently incompatible with IDE Link targets. Thusly my workflow must be modified as a result and model files duplicated. Ideally, the tool options should be mature enough to complete the entire workflow without having to duplicate model files. I don’t think we’re there yet. Duplicating model files (or any data for that matter) for the purposes of design verification, system test, code generation, PIL etc is never a good idea. A versioning system for model files only really works when that file doesn’t need to be duplicated in the workflow. Using model reference will no doubt be part of the solution, but probably not the whole solution… Perhaps some smart Simulink templates are needed to provide the necessary contexts to the different parts of the Model Based Design Workflow? Users would link via model reference their plant, control, test structures into the higher level structure?

Guy Rouleau replied on : 7 of 15

Thanks for all the comments, we really appreciate your feedback.


– I agree that 2 top models make it easy to handle initialization and configuration. In my example, the simulation model uses a continuous solver and the hardware model a discrete solver.
– I agree with your comment on using Variant Subsystems instead of Configurable subsystems. Variant Subsystems offer more functionality and the usability is improved significantly.


– I totally agree with you that it should be possible to complete the entire workflow without having to duplicate model files.
– Linking components of a system using model reference is in general a good way to avoid duplication. With this approach, the same model file can be used within different top-level models for verification, system test, simulation, generate code, etc.

Since this topic seems to generate great interest, I will try to follow up with more posts on related topics.

To everybody: If you have dilemmas in your MBD workflow that you would like to share, please feel free to post a comment or contact me directly!

Mike Tocci replied on : 9 of 15

Hello, I’m a Simulink developer and these comments are very interesting. I do have a few questions,

@Gwenolé LE PACHE: Can you give any more details on this comment,

“We’ve had difficulties transforming the whole model into a referenced model due to some very surprising behaviors coming from our level-2 S-function (fortran + C).”

What was the surprising behavior?

@Paul: I like your comment on “smart Simulink templates”. Would you expect the context to include more than just the configuration set? Should it include data types, sample times, etc?

Gwenolé LE PACHE replied on : 10 of 15

@Mike Tocci : When trying to use our s-function inside an accelerated model, Simulink raises an exception. It seems to be a Fortran error related to opening a log file. Whatever the root is, our s-function can create, open and write a log just fine outside of an accelerated model. We didn’t investigate the problem too much as my department is not in charge of writing the fortran code.

We’ve had other problematic behaviors with it : the classic “The results from 2 consecutive runs are different” but also some things which can’t be anything but Matlab bugs (it has been submitted to the support)… Thus, we tend not to trust it any longer.

Paul Metcalf replied on : 11 of 15

Sorry for the late reply. I should offer a little bit of background. We are only starting out in Model Based Design (MBD) with no existing microprocessor expertise or procedures to work from. On the plus side, we have no legacy requirements holding us back either! Progress on the workflow has been excellent but very much trial and error. I am still working through the nuts and bolts of workflow design, configuration management, PIL testing and so forth. Any comments, recommendations or ideas by me must be considered in this relatively inexperienced context.
I have yet to use Simulink Project, but am very interested about this. I haven’t yet had the time to figure out how to convert an existing project into Simulink Project, or fully understand the benefits Simulink Project may have to the MBD workflow.
As previously mentioned, expanding support between Configuration Reference and IDE Link would seem to be an obvious improvement. Project Generator support for TICCS v.4/5 would also be highly welcomed. Tabbed browsing in Simulink would also be fantastic to switch between different model views quickly, improving window management.
Getting back to the MBD workflow, the best I can gather so far is the following:
•Various configuration files necessary for each task in workflow.
•Model files kept in base workspace alongside configuration files.
•Simulink/Simulink Project used to manage contexts in workflow by reference including data management: test vector, coverage, code etc.

On the topic of MDB workflow, this is the university course or textbook I never had, mainly because I haven’t found a good one yet that even exists!
I will be in Boston in June. If you are interested in further discussing these and other topics over a beer, send me an email.
Keep up the good work.

Paul replied on : 12 of 15

Sorry for spamming this thread, but I after converting a model to referencing, I also found that right clicking on a model block doesn’t allow for code generation such as PLC Coder or Embedded Coder. Please consider expanding support for this as well to improve the usefulness of model referencing in the MBD workflow.

Ratish Punnoose replied on : 13 of 15

I would very much like to use model references, but find that they are limited in the following respects (in addition to those already mentioned by previous posters):

* Prevent hierarchical resolution: This is something can be set on blocks in simulink libraries (it is unfortunate that even in libraries this is not the default). With large models and systems, with multiple developers it is useful to have controlled namespaces. Preventing access to the matlab global workspace is needed for this.

* Using structures as model arguments.

MikeT replied on : 14 of 15

Hi Ratish,

Starting in R2010a, structures are allowed as model arguments.
For hierarchical resolution, you can use the Model Workspace to limit access to the global workspace. But, it doesn’t work hierarchically, so a referenced model won’t resolve in the model workspace of the parent model.


Juan Jimenez replied on : 15 of 15

There is something about the option 1 I don’t understand. In this approach, you have two top models but are there in two different simulink model files (.mdl)? If not, how do you avoid the code generation for the simulated Plant subsystem when it is not neccesary?


Add A Comment

Your email address will not be published. Required fields are marked *


Preview: hide