Documentation Center

  • Trial Software
  • Product Updates


Virtual and Nonvirtual Buses

About Virtual and Nonvirtual Buses

A bus signal can be virtual, meaning that it is just a graphical convenience that has no functional effect, or nonvirtual, meaning that the signal occupies its own storage.

Bus Storage

During simulation:

  • A block connected to a virtual bus reads inputs and writes outputs by accessing the memory allocated to the component signals. These signals are typically noncontiguous, and no intermediate memory exists.

  • A block connected to a nonvirtual bus reads inputs and writes outputs by accessing copies of the component signals. The copies are maintained in a contiguous area of memory allocated to the bus.

Compared with nonvirtual buses, virtual buses reduce memory requirements because they do not require a separate contiguous storage block, and execute faster because they do not require copying data to and from that block.

A nonvirtual bus is represented by a structure in generated code, which can be helpful when tracing the correspondence between the model and the code.

Simulation Results and Generated Code

For a virtual bus, simulation results and generated code are exactly the same as if the bus did not exist, which functionally it does not.

Generated code for a nonvirtual bus represents the bus data with a structure. The use of a structure in the generated code can be helpful when tracing the correspondence between the model and the code. For example, below is the generated code for Bus Creator block in the ex_bus_loggingex_bus_logging model.

Choosing Between Virtual and Nonvirtual Buses

Whether to use a virtual or nonvirtual bus depends on your modeling goal. Frequently, model contain both virtual and nonvirtual buses.

Modeling GoalType of Bus

Use bus signals within a functional units, such as within a referenced model


Use signals with different sample rates in a bus

Virtual (required)

Have bus data packaged as data structures in the generated code


Have bus data cross model reference, MATLAB Function block, or Stateflow® chart boundaries


Not all blocks can accept buses. See Bus-Capable Blocks for more about which blocks can handle which types of buses. Virtual buses are the default except where nonvirtual buses are explicitly required. See Use Buses for Inports and Outports Inside a Model for more information.

For additional guidelines for generated code for buses, see About Buses and Code Generation.

Creating Nonvirtual Buses

Bus signals do not specify whether they are virtual or nonvirtual; they inherit that specification from the block in which they originate. Every block that creates or requires a nonvirtual bus must have an associated bus object. Those blocks are:

To specify that a bus is nonvirtual:

  1. Associate the block with a bus object, as described in Associating Bus Objects with Simulink Blocks.

  2. For the block that creates the bus, open the Block Parameters dialog box.

  3. Set the data type to Bus: <object name> and replace <object name> with the bus object name.

    • For Inport, Outport, and Data Store Memory blocks, use the Data type parameter to set the data type.

    • For Bus Creator and Constant blocks, use the Output data type parameter to set the data type.

  4. For any Bus Creator, Inport, or Outport blocks that have an associated bus object, enable the output as a nonvirtual bus.

    • For Bus Creator and Inport blocks, use the Output as nonvirtual bus parameter.

    • For Outport blocks, use the Output as nonvirtual bus in parent model parameter.

  5. Click OK or Apply.

The Signal Attributes parameter is applicable only to root Inport and Outport blocks, and does not appear in the parameters of a subsystem Inport or Outport block. In a root Outport block, setting Signal Attributes > Output as nonvirtual bus in parent model specifies that the bus emerging in the parent model is nonvirtual. The bus that is input to the root Outport can be virtual or nonvirtual.

Nonvirtual Bus Sample Times

All signals in a nonvirtual bus must have the same sample time, even if the elements of the associated bus object specify inherited sample times. Any bus operation that would result in a nonvirtual bus that violates this requirement generates an error.

All buses and signals input to a Bus Creator block that outputs a nonvirtual bus must therefore have 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, to allow the signal or bus to be included in a nonvirtual bus.

Automatic Bus Conversion

When updating a diagram prior to simulation or code generation, Simulink® automatically converts a virtual bus to a nonvirtual bus (or vice versa) in cases such as when the virtual bus is an input to, or output from:

  • A referenced model

  • An S-Function block

  • A Stateflow chart

The conversion consists of inserting hidden Signal Conversion blocks into the model where needed. Conversion to a nonvirtual bus fails if no bus object is specified at the port to which the virtual bus connects.

Explicit Bus Conversion

You can eliminate the need for the automatic conversion by using one of these approaches:

  • Specify a nonvirtual bus in the block where the bus originates. For example, if you use a Bus Creator block to create a bus, then to specify a nonvirtual bus, set the Bus Creator block Data type parameter to use a Simulink.Bus object.

  • Manually insert a Signal Conversion block. Using a Signal Conversion block can reduce memory usage, support modeling constructs such as Model blocks that require that input buses be nonvirtual, and reduce generated code. For details, see the Signal Conversion documentation.

Was this topic helpful?