I never used SystemBuild, but what you describe seems close to the behavior of Atomic Subsystems in Simulink.

Atomic Subsystems have a “Sample Time” property, which is by default set to -1. The value of -1 does not impose any constraints on the sample time of the blocks inside the Atomic Subsystem. As you describe, this gives you the possibility to shoot yourself in the foot.

If your application requires strict usage of sample times, you can specify a positive value for the sample time of the Atomic Subsystem. When a positive value is specified, all the blocks inside the Atomic Subsystem will run at this rate. You will receive an error if blocks inside the Atomic Subsystem are configured to run at a different rate.

There are also ways to enforce models to be single-rate.

In the solver section of the model configuration, by default the “Periodic sample time constraint” is set to ‘Unconstrained’ to allow more flexibility. If your model needs to contain only specific rates, you can change it to “specified” and specify the allowed rates. You can find information on this topic here:

http://www.mathworks.com/help/toolbox/simulink/gui/bq7cmsp-1.html#bq99059-1

http://www.mathworks.com/help/toolbox/simulink/gui/bq7cmsp-1.html#bq99059-1

In Simulink, you typically handle sample times by specifying the sample time of an individual block (say, an integrator) and then having the sample time propagate to individual blocks. The problem is that if you mess up the sample time on one block, it can affect lots of blocks, which is what Guy is showing. Simulink’s design makes it relatively easy to shoot yourself in the foot, sample-time-wise.

In the almost-extinct SystemBuild (part of MATRIXx, which was actually the leader in graphical modeling and code generation until about 2001 or so; that’s a whole ‘nother story), timing attributes were specified at the SuperBlock level (a SuperBlock is similar to Simulink’s Subsystem block, except somewhat less virtual). So every non-SuperBlock inside a given SuperBlock would share the same timing attributes. This greater level of structure to timing attributes makes it substantially more difficult to mess up timing in a SystemBuild model.

I don’t know if this architecture was covered by patent or not, but since AFAIK the Mathworks kept the rights to all patents covering MATRIXx/SystemBuild when they were forced to divest themselves of their purchase of that tool (that’s part of the story alluded to above), there should be no legal problem with allowing the SystemBuild-style timing attributes in Simulink. I am assuming that the Mathworks prefers their design; I do not in this case. My preference would be to allow (not enforce) a Model block to act like a SystemBuild-style SuperBlock and specify timing attributes for the entire contents of the Model block (including inheriting them from a higher-level Model block, for the case of nested Model blocks). Maybe I’m unusual, but for all of my use cases, I always design my Model blocks to be single-rate; that’s what is required to integrate my generated code into an existing real-time framework.

Can you expand on your concerns with how Simulink handles sample times?

Not saying that I want to go back to SystemBuild, but it is frustrating that there are still these places where Simulink makes it easy to shoot yourself in the foot.