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.
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.
Name-based composite signals allow for signal hierarchy. They are generically called buses.
A Simulink® bus is analogous to a bundle of wires held together by tie wraps. A Simulink bus is not analogous to a hardware bus, such as the bus in computer hardware architecture.
Not all blocks can accept buses and some blocks implicitly convert buses to vectors. To learn which blocks support which types of buses, see Bus-Capable Blocks. To learn how to identify implicit bus-to-vector conversions, see Manage Bus-to-Vector Conversions.
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.
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||Index-Based Access||Name-Based Access|
You can identify composite signal types by their line style.
|Line Style||Composite Signal Type|
|Nonscalar signal when the Nonscalar Signals information overlay is enabled (includes index-based composite signals)|
|Index-based composite signal that contains nonvirtual buses|
This model shows a virtual bus that contains signals
This model shows an equivalent virtual bus passing through a subsystem boundary.
You can use virtual buses to:
Contain bus elements that have different sample rates.
Cross model reference boundaries, if the referenced model only uses a few of the bus elements.
Using a virtual bus is simpler and can be more efficient than using a nonvirtual bus. By accessing elements directly, virtual buses execute faster than nonvirtual buses in simulations and generated code. Only the elements of a virtual bus appear in generated code, even when the virtual bus is associated with test points.
To specify and validate the properties of a virtual bus, you can specify a
Some modeling features require nonvirtual buses, such as MATLAB Function blocks and Stateflow® charts.
This model shows a nonvirtual bus that contains signals
For nonvirtual buses at subsystem or model interfaces, use Outport and Inport blocks.
You can use nonvirtual buses to:
Display and log bus signals with a Scope block.
Construct an array of buses.
Have bus data cross MATLAB Function block or Stateflow chart boundaries.
Interface with external code through an S-function.
Package bus data as structures in the generated C code.
Simulink.Bus object must define the
bus you want to make nonvirtual. The bus object specifies only the architectural
properties of a bus. For example, a bus object can specify element names, hierarchy,
order, and data types. A bus object does not specify the values of the signals in a
bus. For more information, see Specify Bus Properties with Bus Objects.
Since a virtual bus can specify a bus object, a bus becomes nonvirtual when you also select the Output as nonvirtual bus parameter.
All elements of a nonvirtual bus must use the same sample time, even if the associated bus object specifies inherited sample times. You can use a Rate Transition block to change the sample time of an individual signal or of all signals in a bus.
The type of bus can make a significant difference in the efficiency, size, and readability of generated code. Generated code represents a nonvirtual bus as a structure. The structure can be helpful for tracing the correspondence between the model and code. Generating code for nonvirtual buses can result in multiple copies of some buses. If you intend to generate code for a model that uses buses, see Generate Efficient Code for Bus Signals (Simulink Coder). For an example of the difference between virtual and nonvirtual buses in generated code, see Generate Code for Buses.
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.
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. For examples, see Extract Vector Elements Using the Demux Block. 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 anywhere that you use an ordinary contiguous vector. For example, you can perform calculations on a mux signal. The computation affects each constituent value in the mux signal, as if the values existed in a contiguous vector. Using a mux signal to perform computations on multiple vectors avoids the overhead of copying the separate values to contiguous storage. 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. 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.