Guy and Seth on Simulink

November 19th, 2010

By Guy Rouleau

The first time I used buses in Simulink, it was version 3.0 (R11). Bus signals and the way we use them in Simulink have evolved over time. In this post I want to give you a historical tour of how the bus has changed since R11. To start, in R11 I'm not even sure I should call it a bus. Why? Let's look at the Signal & Systems section of the R11 Simulink Library Browser:

If you have good eyes, you probably noticed there is a Bus Selector block in R11, but no Bus Creator block. At that time, the way to create a bus was using the Mux block.

Since that time, buses and muxes are slowly moving away from each other. To illustrate this, I went through the Archived MathWorks Documentation.

R13sp2
This is the oldest documentation available in the archive. The Bus Creator is now available.

R14sp2
A new diagnostic is introduced: Mux blocks used to create bus signals. Setting this diagnostic to error enforces what is called strict bus behavior. To help users receiving errors when enabling this diagnostic, a Model Advisor check and the function slreplace_mux is introduced.

R2007a
Now the differences become more significant:

• A documentation section titled Intermixing Composite Signal Types is created.
• A new diagnostic is introduced: Bus signal treated as vector.
• A paragraph titled Avoiding Mixed Composite Signals When Developing Models states the following:
  
  

  "The MathWorks discourages the use of mixed composite signals, and may cease to support them at some future time. The MathWorks therefore recommends upgrading existing models to eliminate any mixed composite signals, and permanently setting Mux blocks used to create bus signals and Bus signal treated as vector to error in all new models and all existing models that may undergo further development."

R2008b
The documentation page titled Intermixing Composite Signal Types is renamed Avoiding Mux/Bus Mixtures. Can it be clearer?

R2010a
One more diagnostic is introduced to help avoiding Bus/Mux mixture: Non-bus signals treated as bus signals

R2010b
Starting in R2010b, the diagnostics Mux blocks used to create bus signals is set to error by default when creating a new model. This is one more step toward the deprecation of mixed composite signals.

The Future
I cannot really predict the future, but I know that when implementing new features, Simulink developers now take into account that Mux blocks will not be used to create buses. This is why many new features require the Mux blocks used to create bus signals diagnostics being set to error. These features include for example:

• Array of buses
• Specifying Initial Conditions for Buses
• Support of bus object data type for Constant blocks
• Converting a Subsystem to a Referenced Model
• Getting information about type and hierarchy of a bus using the CompiledBusType and SignalHierarchy properties.
• Bus Support in Signal Specification block
• Simplified detection of underspecified initialization
• More robust and consistent behavior for the Discrete-Time Integrator block.

The number of features in this list increases every release, so if you don't avoid mux/bus mixture in your models, you will miss a lot of cool stuff!

Conclusion
The settings we recommend are:

Now it's your turn

Have you already converted to strict bus mode? If not, let us know why by posting a comment here.

By Guy Rouleau

21:24 UTC | Posted in Model-Based Design, Signals, Simulink Tips | Permalink | 4 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.

4 Responses to “Bus Signals: Past, Present and Future”

1. Thierry replied on December 6th, 2010 at 12:11 UTC :
   

   About bus/mux, i have some difficulties to know clearly when it is better to use bus and when it is better to use mux in a model.
   What are the main rules? i think it will allow to avoid mixing the both :)

2. Guy Rouleau replied on December 6th, 2010 at 14:10 UTC :
   

   Hi Thierry,

   First, I recommend looking at the other posts made by Seth in the Signals category. There is a lot of useful information there:

   http://blogs.mathworks.com/seth/category/signals/

   As far as I know, there are no “hard” rules about when using a Mux and when using a Bus. In R11, I was using the Mux block all the time. Now I almost never use this block anymore.

   Every time I want to combine multiple signals carrying different information into one line in my model, I use buses. The only situation where buses are not appropriate is to combine multiple signals into vector, for math operations. In that case, I use the Vector Concatenate block.

   Guy

3. Yogananda Jeppu replied on January 5th, 2011 at 10:18 UTC :
   

   We are qualifying Simulink for 2008b for aerospace control V&V. I see that 2010 has bus initialisation. Is it (was it :-)) possible to initialze a bus to any value in an enabled subsystem?

4. Paul replied on January 11th, 2011 at 02:45 UTC :
   

   Hi,
   I still find the implementation of buses somewhat confusing, and I suspect this is to do with the less than ideal introduction of buses into SIMULINK which you have explained. I really like the concept of buses, and it’s good to see that you are heading in the right direction with them. But I still have a concern. For me, the main benefit for buses is to assign bus signals in different parts of the model, not necessarily try to combine them all within the one block. The Bus Assignment block works excellently here. However, at some point somewhere, the bus needs to be created and it is here where I think there are still problems. Trying to create the bus object in the first place using Bus Creater causes error unless you supply all the bus signals at the point of creation. This removes the whole benefit of having a bus, and also creates ambiguity, since the signals can be re-assigned elsewhere in the model… This is bad practice.
   My recommendation is to allow the Bus Creater to create a bus even when only one signal is being assigned. Then you should check at compile that all bus signals have been assigned once and only once acrosss the whole model (either at the orignal bus creater block, or later in a Bus Assignment.

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.