Getting Started with Buses

You can combine signals into a bus signal and then access the bus as a whole or select specific signals from the bus. These examples show the fundamentals of creating and using buses in models and in generated code. For additional information, see Buses.

Create and Use Virtual BusesVirtual buses provide the simplest approach for using buses to reduce signal clutter in a block diagram.
Create and Use Nonvirtual BusesNonvirtual buses support modeling components (such as S-functions or MATLAB Function blocks) that require explicitly specified interfaces.
Generate Code for BusesGenerated code for virtual and nonvirtual buses differs. Code generation for a nonvirtual buse produces a structure, which can be helpful for tracing the correspondence between a model and its generated code.
slexBusExampleSimple examples that introduce using bus-related blocks, including animations for smart editing of bus signals.


For models that include bus signals composed of many bus elements that feed subsystems, consider using the In Bus Element and Out Bus Element blocks. You can use these bus element port blocks instead of Inport with Bus Selector blocks for inputs, and Outport with Bus Creator blocks for outputs. These bus element port blocks:

  • Reduce signal line complexity and clutter in a block diagram.

  • Make it easier to change the interface incrementally.

  • Allow access to a bus element closer to the point of usage, avoiding the use of a Bus Selector and Goto block configuration.

For more information, see Simplify Subsystem Bus Interfaces.

These examples are simple, to focus on the basic steps in creating and using buses. Buses are most useful when you have many signals that make sense to combine to reduce visual complexity. The examples also include steps to label blocks and signals, to clarify the relationship between signals and buses and between blocks. If you choose to build the example models step-by-step, you can skip those steps if you like.

Create and Use Virtual Buses

This example shows how to combine signals into virtual buses. The model selects individual signals (bus elements) from a virtual bus and uses the bus elements as individual signals.


To change bus element values without adding Bus Selector and Bus Creator blocks that select bus elements and reassemble them into a bus, you can use a Bus Assignment block. For details, see Assign Signal Values to a Bus.

To see the completed model, open the ex_bus_tutorial_virtual model. When you simulate the model, the bus signal lines indicate that the buses are virtual.

Perform these steps to gain experience creating and using virtual buses.

  1. From the Simulink® Start Page, select a blank model template.

  2. In the Simulink Editor, add a Chirp Signal block and a Sine Wave block.

  3. Create a bus for the signals from the two blocks. Drag to select the blocks and in the action bar that appears, click Create Bus.

    Simulink adds a Bus Creator block and connects the input signals to that block.

  4. By default, the Bus Creator block name does not appear. To add a block name, select the block and from the action bar that appears, select Show Block Name. Then edit the name, changing it from Bus Creator to SubBus.

  5. You do not have to label the signals in a bus. However, labeling makes it easier to see the relationship between bus element signals and bus signals. Label the output signal for the Chirp Signal block. Right-click the signal and select Properties. In the Signal name property, enter chirp. Similarly, set the Sine Wave signal name to sine.


    Inputs to a Bus Creator block must have unique names. If there are duplicate names, the Bus Creator block appends (signal#) to all input signal names, where # is the input port index.

  6. Add a Step block below the Sine Wave block.

  7. To create a nested bus, add a Bus Creator block to the right of the current blocks. Connect the signal from the SubBus block and the signal from the Step block to the second Bus Creator block.

  8. Label the output signal from the SubBus block subBus and the signal from the Step block step.

  9. Show the block name for the Bus Creator block that creates the nested bus. Change the name to NestedBus.

  10. Attach a Scope block to the nestedBus signal.

  11. To the right of the NestedBus block, add a Subsystem block and connect the NestedBus output signal to the subsystem.

  12. Connect the Subsystem block output port to a Scope block.

  13. In the subsystem, disconnect the Inport and Outport blocks and insert a Bus Selector block to the right of the Inport block. Connect the Inport block to a Bus Selector block.

  14. Show the Bus Selector block name. Change the name to BusSelector.

  15. To the right of the Bus Selector block, add a Saturation block and set its Lower limit parameter to -inf.

  16. Combine the chirp signal and the Saturation block output signal into a bus.

  17. Combine the bus signal and the step signal into a nested bus.

  18. Connect the nested bus to the Outport block.

  19. To see the simulation results, simulate the model and open the Scope blocks.

Create and Use Nonvirtual Buses

This example changes the virtual buses used in the ex_bus_tutorial_virtual model to nonvirtual buses. To see the completed model, open the ex_bus_tutorial_nonvirtual model. Nonvirtual buses are required for certain modeling situations. Generating code for a nonvirtual bus represents the bus as a structure. For more information about when to use nonvirtual buses, see Nonvirtual Bus Usage Guidelines.

When you simulate the model, the bus signal lines indicate that the virtual are converted to nonvirtual buses.

Perform these steps to gain experience creating and using nonvirtual buses.

  1. Open the ex_bus_tutorial_virtual model.

  2. 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.

    For the SubBus block, specify to produce nonvirtual bus output. In the Block Parameters dialog box, set Output data type to Bus: subBus. This setting uses the subBus bus object, which provides bus properties that Simulink uses to validate the bus signal.

    Also, select the Output as nonvirtual bus parameter.


    When you use bus objects to create nonvirtual buses, the bus object must be in the base workspace before simulating the model. You need to define the bus object or use an already defined bus object. To simplify this example, when you open the model, a model callback loads the necessary bus objects into the base workspace. To see the callback, open File > Model Properties > Model Properties and open the Callbacks tab.

    For information about creating bus objects, see Create Bus Objects.

  3. In the NestedBus block, set Output data type to Bus: topBus and select the Output as nonvirtual bus parameter.

  4. The subBus bus object expects the second input signal in the bus to be called sine. Although the Bus Selector block selected the sine signal from the bus, the default name of the output signal of the Saturation block is not sine. Use the Signal Properties dialog box to name the Saturation block output signal sine.

  5. The topBus bus object expects the first input signal in the bus to be called subSignal. Use the Signal Properties dialog box to name the bus signal subSignal.

  6. To see the simulation results, simulate the model and open the Scope blocks. The results are the same as when you simulate the ex_bus_tutorial_virtual model that you used as a base for this model.

Generate Code for Buses

The simulation results are the same for the model that uses virtual buses (ex_bus_tutorial_virtual) and for the model that uses nonvirtual buses (ex_bus_tutorial_nonvirtual). However, the generated code is different.

Adding a Unit Delay block and an Outport block after the Subsystem block in each of the models helps to highlight the differences in the generated code.

Generated Code for the Virtual Bus Model

Generate code from the ex_bus_tutorial_virtual_code_gen model.

The virtual buses do not affect the generated code. For example, in the generated file ex_bus_tutorial_virtual_code_gen.c, the algorithm in the model step function effectively implements three Unit Delay blocks (one for each meaningful signal, such as chirp, that passes through the block).

  /* UnitDelay: '<Root>/Unit Delay' */
  rtb_chirp = ex_bus_tutorial_virtual_code_DW.UnitDelay_1_DSTATE;

  /* UnitDelay: '<Root>/Unit Delay' */
  rtb_signal2 = ex_bus_tutorial_virtual_code_DW.UnitDelay_2_DSTATE;

  /* UnitDelay: '<Root>/Unit Delay' */
  rtb_step = ex_bus_tutorial_virtual_code_DW.UnitDelay_3_DSTATE;

Generated Code for the Nonvirtual Bus Model

For the nonvirtual bus model, the Output data type is set to Bus: topBus and Scope blocks are commented out, because Scope blocks are not needed for the generated code and do not support code generation.

Generate code from the ex_bus_tutorial_nonvirtual_code_gen model.

The nonvirtual buses appear in the generated code as structures. Each Simulink.Bus object appears as a structure type. The type definitions appear in ex_bus_tutorial_nonvirtual_code_gen_types.h.

typedef struct {
  real_T chirp;
  real_T sine;
} subBus;

typedef struct {
  subBus subSignal;
  real_T step;
} topBus;

The algorithm in the model step function can implement the Unit Delay block as a single line of code. The block state and output are structures of type topBus.

  /* UnitDelay: '<Root>/Unit Delay' */
  rtb_UnitDelay = ex_bus_tutorial_nonvirtual_c_DW.UnitDelay_DSTATE;

See Also




Related Topics

Was this topic helpful?