Types of Composite Signals

To reduce visual complexity in a model, you can combine signals into composite signals. The signals that a composite signal contains are called elements. Elements retain their separate identities, which let you extract them from the composite signal.

You can access composite signal elements by name or index, depending on the composite signal type.

Name-based composite signals allow for signal hierarchy. They are generically called buses.
Index-based composite signals are flat, regardless of whether you create them in stages. They require that all input signals have the same data type.

When you group signals into a composite signal, you can decide whether they affect simulation and code generation.

A virtual composite signal simplifies the visual appearance of a model by combining two or more signal lines into one line. It does not group the signals in any functional sense and, therefore, does not affect simulation or code generation. By accessing elements directly, virtual composite signals execute faster than nonvirtual composite signals in simulations and generated code.
A nonvirtual composite signal visually and functionally groups signals, affecting both simulation and code generation.

Models can use a combination of these composite signal types.

Composite Signal Feature	Name-Based Access	Index-Based Access
Visual Grouping	Virtual Bus	Mux Signal
Functional Grouping	Nonvirtual Bus	Concatenated Signal

You can identify composite signal types by their line style after compiling or simulating the model.

Line Style	Composite Signal Type
	Virtual bus
	Nonvirtual bus
	Nonscalar signal when the Nonscalar Signals information overlay is enabled (includes index-based composite signals)
	Index-based composite signal that contains nonvirtual buses

Virtual Bus

This model shows a virtual bus that contains signals a, b, and c.

Bus Creator blocks create buses within a subsystem or model. Bus Selector blocks extract specified elements of the bus.

This model shows an equivalent virtual bus passing through a subsystem boundary.

Out Bus Element blocks create a bus at a subsystem or model interface. In Bus Element blocks extract specified elements of a bus at a subsystem or model interface.

You can use virtual buses to:

Contain bus elements that have different sample rates.
Cross model reference boundaries.

To specify and validate the properties of a virtual bus, you can specify a Simulink.Bus object.

To create a virtual bus, see Group Signal Lines into Virtual Buses.

Nonvirtual Bus

This model shows a nonvirtual bus that contains signals a, b, and c.

Bus Creator blocks create buses within a subsystem or model. Bus Selector blocks extract specified elements of the bus.

You can use nonvirtual buses to:

Package bus data as structures in the generated C code.
Construct an array of buses.
Interface with external code through an S-function.
Have bus data cross MATLAB Function block or Stateflow^® chart boundaries.
Display and log buses with a Scope block.

All elements of a nonvirtual bus must use the same sample time. You can use a Rate Transition block to change the sample time of an individual signal or of all signals in a bus.

A Simulink.Bus object must define the bus you want to make nonvirtual. A bus becomes nonvirtual when you select the Output as nonvirtual bus parameter. Selecting this parameter causes simulation and code generation to apply the structure defined by the Bus object. When this parameter is cleared, the Bus object only validates the properties of the bus.

The type of bus can make a significant difference in the efficiency, size, and readability of the generated code. For a bus to appear in the generated code, it must be nonvirtual. Only the elements of a virtual bus appear in the generated code.

For example, suppose a bus passes through a Unit Delay block. For simplicity, the bus contains only three elements: a, b, and c. This table shows the effect of the Output as nonvirtual bus parameter on the generated code.

Generated Code Virtual Bus Nonvirtual Bus

Generated Code	Virtual Bus	Nonvirtual Bus
`model``_types.h` file	Virtual buses do not require type definitions.	`Bus` objects appear in the generated code as structures. typedef struct { real_T a; real_T b; real_T c; } BusObject;
`model``.h` file	The generated code defines one Unit Delay block for each element of the virtual bus. typedef struct { real_T UnitDelay_1_DSTATE; /* '<Root>/Unit Delay' / real_T UnitDelay_2_DSTATE; / '<Root>/Unit Delay' / real_T UnitDelay_3_DSTATE; / '<Root>/Unit Delay' */ } DW_model_T;	The generated code defines one Unit Delay block for the nonvirtual bus, using the `BusObject` structure. typedef struct { BusObject UnitDelay_DSTATE; /* '<Root>/Unit Delay' */ } DW_model_T;

model_types.h file

Virtual buses do not require type definitions.

Bus objects appear in the generated code as structures.

typedef struct {
  real_T a;
  real_T b;
  real_T c;
} BusObject;

model.h file

The generated code defines one Unit Delay block for each element of the virtual bus.

typedef struct {
  real_T UnitDelay_1_DSTATE;  /* '<Root>/Unit Delay' */
  real_T UnitDelay_2_DSTATE;  /* '<Root>/Unit Delay' */
  real_T UnitDelay_3_DSTATE;  /* '<Root>/Unit Delay' */
} DW_model_T;

The generated code defines one Unit Delay block for the nonvirtual bus, using the BusObject structure.

typedef struct {
  BusObject UnitDelay_DSTATE;  /* '<Root>/Unit Delay' */
} DW_model_T;

To create a nonvirtual bus, see Create Nonvirtual Buses.

If you intend to generate code for a model that uses buses, see Generate Efficient Code for Bus Signals (Simulink Coder). Generating code for nonvirtual buses can result in multiple copies of some buses.

Concatenated Signal

This model shows a concatenated signal that places the input matrices side by side.

The Matrix Concatenate block creates concatenated signals. Elements can be either vectors or matrices, depending on how you configure this block. The Selector block extracts signals based on specified indices. The extracted signals can be grouped differently than the input signals.

You can use concatenated signals in mathematical operations.

To group signals with a Vector Concatenate or Matrix Concatenate block, the signals must have the same data type. When the data type is a Bus object, the inputs must be nonvirtual buses.

Concatenated nonvirtual buses are also known as an array of buses. In an array of buses, all elements are nonvirtual buses that use the same Bus object to specify properties. An array of buses is equivalent to an array of structures in MATLAB^®. You can use an array of buses to model a multichannel system. While all the channels have the same properties, each of the channels may have a different value.

In this model, a Vector Concatenate block creates an array of buses.

For more information on arrays of buses, see Combine Buses into an Array of Buses.

Mux Signal

This model shows a mux signal that places the three input signals side by side.

The Mux block creates mux signals. The Demux block extracts all signals, which may be grouped differently than the input signals. The Selector block extracts signals based on specified indices. The extracted signals can be grouped differently than the input signals.

You can use a mux signal to perform computations on multiple vectors. You can also use a Mux block to create a vector of function calls.

Input signals for a Mux block can be any combination of scalars, vectors, and mux signals, but they must have the same data type and numeric type. The signals in the output mux signal appear in the same order as the input signals for the Mux block. You can use multiple Mux blocks to create a mux signal in stages, but the result is flat as if you used a single Mux block.

Documentation