Guy on Simulink

Simulink & Model-Based Design

What is a Composite Signal? 9

Posted by Seth Popinchalk,

The answer is short and sweet. A composite signal is a mux or a bus signal. These can be thought of as a collection of other component signals. The subtleties of using bus signals and mux signals are a common source of modeling questions, and in 2006 The MathWorks published a new section of Simulink documentation to specifically discuss Composite Signals. In this post I will start to share my mental model of the mux and bus. It started with mux The basic concept for the Mux Block is the idea of bundling signals together. This bundle of signals can be routed through the model, and then operated upon as a collective unit. (Mux actually stands for multiplex.) Along with the Mux Block is the Demux Block, which breaks signals apart into their components to be operated on individually. Take a look at this example. Simple Mux Example The Mux is putting the three signals, (x,y,z) into a single line of width 3. The Demux Block is used to break apart the signals into their basic elements. The Mux and Demux do not change the signals, and are considered virtual. When the model is run, it is as if the blocks don’t exist, and only the connections from source to destination remain, like this: Simple mux model virtual blocks, just connections An important mental model to use for the mux is the idea of creating a vector. This means you can do things to the output signal that you would do with a vector. For example, multiply the vector by 2. Mux model with gain These types of vector operations impose an important requirement that all signals passed into a Mux Block are the same data type. In my mental model of the mux, it only makes sense to lump signals together if they make sense as a vector. Usually the elements have the same units or they are useful as a group. The only specification you need for a Mux Block is the number of inputs. Mux block dialog Another benefit of using the mental model of a vector is that you can index with the selector block to pick off signals or rewire your connections. Mux model with selector Later on came the bus When I need to bundle together signals of different types or I can’t naturally express my diagram with a vector, I use a bus. Bus signals can really clean up your diagram. Bus Creators and Bus Selectors provide a graphically convenient way to manage signals and organize your model. In my mental model of the bus, I imagine a rainbow of wires bundled together with a tie-wrap. Without that tie-wrap holding it together I would quickly loose my ability to keep the signals organized. To demonstrate this, I want to look at an example model of the DeHaviland Beaver from the Aerospace Blockset: DeHaviland Beaver Model Top Level At the top level of the model, everything is nice and orderly because all the information calculated by each subsystem is bundled up into a bus. Each system packages all the relevant signals into a bus using a Bus Creator, and then passes the bus along to the systems that consume those signals. Aerospace 6DOF block and bus creator Can you imagine if the signals were not bused together? This is a relatively modest model, but it would be a mess! DeHaviland Beaver Model with no bus signals Most of the component systems in this model use bus signals to provide simplified interface. I have noticed that some people will place signals in the bus, just in case they might be needed in another system. Here is an example of a system whose interface is defined with bus signals. Calculate flight params system With a quick glance at this diagram you can determine that the flight parameters (FltParams) can be calculated from environmental signals (EnvirBus) and aircraft signals (ACBus). Inside the system you can see Bus Selectors used to pull specific elements from the bundle of signals. The computed flight parameters are combined with a Bus Creator to define the FltParams Bus. Calculate parameters system with bus creator Bus signals can represent hierarchy Let’s look at the hierarchy found in the Environment Bus. This is a simple example of a bus being fed into another bus. The environmental signals for gravity (g), pressure (rho), and wind bus (Vwind) are passed into the Bus Creator. The wind bus is defined by the body velocities (uvw_wind) and body rates (pqr_wind). Environment system bus creator with annotations This leads to an organized collection of signals in the bus, as shown by the Bus Creator dialog. Bus creator dialog At its most basic level, you only need specify the number of inputs to your bus creator. The names of elements are derived from the signal names. Like the Mux Blocks, these bus creators have not changed the signals at all, so we can call them virtual. It doesn’t end here We are just starting to get into this topic. Next week we will talk about more advanced maneuvers with Mux and Demux Blocks, specifying interfaces with Bus Objects, and nonvirtual buses. Now it’s your turn How do you use bus and mux signals? What kinds of modeling questions about composite signals do you have? Care to share? Post a comment below. If you want to show off the complicated bus hierarchy from your model, e-mail me a picture of your bus and I’ll post it for you (image tags are stripped from comments).

9 CommentsOldest to Newest

mansour replied on : 1 of 9

Hello Seth,
Thank you very much for your post.
Can you please explain how RTW generate code for composite signals?

Best Regards

Bob replied on : 2 of 9

Pretty good post. Hope to forward it on to a few people who’ve asked me about the difference between Mux and Bus.

With the section title “It started with mux” I was hoping to see a little history of the mux/bus confusion and source of the “Mux blocks used to create bus signals” diagnostic. I’m not entirely clear on this, having not used versions of Simulink without the Bus very extensively.

Also, in my mental model I think of the Bus Creator and Selector blocks disappearing and the bus being transformed into a bundle of lines. However, I don’t think of the Mux and Demux blocks in this way. And I think the reason for this is experience with how RTW generates code for muxed signals:
– I thought they showed up as arrays in the code
– I know I’ve had trouble routing individual elements from a Demux to separate root outports controlled by Simulink.Signal objects. The error is usally something like “The Simulink signal object specified on the line originating from output port 1 of ‘model/subsystem with demux’ is invalid because it cannot be uniquely mapped to a valid signal in the model.” In these situations we’ve dropped in a Signal Conversion block before the root outport.

KMR replied on : 3 of 9

Well, my first experience with Simulink was actually SimuLAB 1.1. There were Mux and Demux blocks, but no Selector blocks yet. I abandoned Simulink for SystemBuild (much more mature for what I needed to do at the time) and didn’t really come back to Simulink until R13 in 2002, at which time I discovered Buses.

I hope you get into bus objects in this series, since they are one of the most important parts of the whole bus concept: allowing you to lock down an interface. Maybe you can tell us why you can’t annotate bus elements with, say, units fields the way that you can signal objects. I would dearly like to document units and general free-form descriptions with my bus objects and bus elements but I can’t do this currently. I did turn in a bug report / enhancement request on this.

Seth replied on : 4 of 9

@Mansour – I plan to show some code generated from mux and bus as part of this series. Thanks for the request.

@Bob – I’m glad you liked the post. I have to admit, when I wrote that section title, I too was thinking about the history of the mux/bus… you are on to us. The two blocks have a shared and interesting past. I have been talking to some of the developers who were part of the team that made the early design decisions, and when I fill in more details I’ll post about it.
I’m intrigued by your Simulink.Signal error. Would you send me an example I can include in the blog? If I get a chance, I’ll take a shot at reproducing this. I think I have seen this before.

@KMR – Thanks for the comment. You are right on about the benefits of bus objects as an interface specification. We will be going into that. You are not the only one to ask for the ability to add documentation to bus elements. That would be an ideal way to further incorporate elements from an Interface Control Document (ICD) into the model… or better yet, allow the model to generate the ICD.

iera replied on : 5 of 9

i just want to ask about serial to parallel and parallel to serial block in simulink communication blockset.
how to design it in simulink??

Felix Carlos replied on : 6 of 9


Very interesting your articles. I am new in Matlab and I need help about serial to parallel signal conversion in Matlab. Specifically convert 1 dimensional signal to 2 or more 1 dimensional signals. Could you help me?

Felix Carlos replied on : 7 of 9

I forgot to told you that I’m working in Simulink and in this context I need this help.

Juliana Bezerra replied on : 8 of 9

Hi Seth,

In my model, I have a bus creator composed by signals of different types. This bus passes through an enable subsystem to be discretized. This model raises the following error: “Input port cannot accept mixed data type”.

The help of the Inport block comments this error, as explained bellow. But I don’t understand why it is not possible. Will Mathworks improve this issue?

In Inport help:
“Signal elements connected to a subsystem input port can be of differing numeric and data types except in the following circumstance: If the subsystem contains an Enable or Trigger block or is an Atomic Subsystem and the input port, or an element of the input port, is connected directly to an output port, the input elements must be of the same type. For example, consider the follow enabled subsystem.”

Kathleen replied on : 9 of 9

I know that this is an older “blog”. Nevertheless, the idiosyncrasy one encounters when trying to demux a vector into individual signals entering outports remains. There ought not be a need to make a copy of a signal after you extract it from a vector. However, in order to satisfy the requirements of “Valid outport connections”, one is obligated to do so.

Two types of errors are encountered, depending upon the style of implementation.
One error has been cited in the text above. (“The Simulink signal object specified on the line originating from output port 1 of ‘model/subsystem with demux’ is invalid because it cannot be uniquely mapped to a valid signal in the model.”)
The alternate type of error is: “Warning: Invalid root Outport block connection in the referenced model ‘mdlName’. Only 1 element(s) of output port ## of block “contained libray block” drive the root Outport ###.

To be a valid connection, all of the signal’s
elements must drive the root Outport block to which it is connected. Simulink inserts a hidden Signal Conversion block (with the
‘Exclude this block…’ option enabled) before the root Outport block.”

Yet, the connections which promt this diagnostic are structurally quite similar to any of the demux illustations shown above.

Add A Comment

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


Preview: hide