Guy on Simulink

Simulink & Model-Based Design

Defining Model Interfaces Using Bus Element Ports

Today I want to talk about Bus Element Ports. More specifically, I will share examples illustrating how Bus Element Ports can simplify the process of specifying the properties of bus signals entering and exiting referenced models.

Bus Element Ports

In this post, I will not cover in detail all the basics of Bus Element Ports; we have great documentation pages for that. If you are not familiar with this feature, I recommend getting started with these pages:
If you ask me to describe it in one sentence, I would say that a Bus Element Port is a combination of an Inport block and a Bus Selector, or a combination of a Bus Creator and an Outport block. For example, let's take this model:
Inside subsystem MySub, you can access the bus elements in two ways. On the left, the traditional way is to use a Bus Selector, and on the right the equivalent using Bus Element Ports

Simplified Wiring and Signal Names Management

Here is an example illustrating two additional benefits of Bus Element Ports:
  • The same signal can be accessed multiple times. Here I am accessing the bus element "A" at two places. In a large subsystem, this helps minimize wiring and avoid the need for Goto and From blocks.
  • The names of the bus elements are decoupled from the signal names. Without Bus Element Ports, I would have needed to insert a block to create a bus element with a name different from the incoming signal, or to rename the signal coming out of a bus.

Converting to Bus Element Ports

If you have existing models and would like to start using Bus Element Ports, we have added plenty of affordances to facilitate the process. For the above example, I was able to simply select the Bus Selector and click "Bus Ports" in the quick action menu to do the conversion.
I recommend going through Simplify Subsystem and Model Interfaces with Bus Element Ports for an exhaustive list of all those affordances to help the conversion.

Bus Element Ports and Model Referencing

The main thing I want to cover in this post is how Bus Element Ports can be used to fully define the interface of a model, without the need for Bus Objects.
If you are familiar with Model Referencing and Bus Signals, you probably know that historically, Bus Objects were required to provide to the referenced model the definition of the bus. And those could be a pain to manage. For the above example, I would have created the necessary bus objects using the Type Editor and specified them in the Inport block dialog.
Let's now look at 3 different ways the same functionality can be implemented using Bus Element Ports.

Example 1 - Complete definition using individual Bus Element Ports

For the above example, if I use the Model Reference Conversion Advisor to convert subsystem MySub to a referenced model, the entire incoming bus will be re-created using Bus Element Ports and then passed to the subsystem:
That's one way to do it, but for large buses this can result in a large tree of Bus Element Ports and Bus Creator blocks. Let's look at two other ways to specify the model interface using Bus Element Ports.

Example 2 - Partial definition using individual Bus Element Ports

If you prefer, you don't need to fully recreate the entire incoming bus. You can include only Bus Element Ports for the elements being consumed inside the referenced model. By double-clicking on the label of the Bus Element Port, you can simply type, for example, bus1.Chirp to select the element Chirp from the sub-bus bus1, which is part of the incoming main_bus.

Example 3 - Definition using a single Bus Element Port

A third option is to define all the elements that will be used in the referenced model using a single Bus Element Port. This can be done by double-clicking on the Bus Selector to open its dialog or from the Property Inspector. You can select the node under which you want to add an element and select Add element without block. Once the element is added, you can edit its name by double-clicking on its name:
This is especially useful if you don't need to access the individual signals at the top level of the referenced model. For our previous example, this looks like this:

Bonus: Variants Using Different Bus Elements

Let's keep building on the previous examples and replace the subsystem receiving the bus with a Variant Subsystem that references two models. Thanks to the flexibility offered by Bus Element Ports, the two referenced models don't need to be aware of all the elements in the incoming bus. As long as the incoming bus contains the elements accessed in the referenced model, things will work, and you will be able to use one model or the other as active variant.
That way you can keep developing one of the referenced models without caring if the incoming bus gets modified by someone else, as long as the signals you need did not change.

Now it's your turn

Are you leveraging Bus Element Ports in your models? Let us know what you consider being their most useful characteristic in the comments below.
|
  • print

Comments

To leave a comment, please click here to sign in to your MathWorks Account or create a new one.