>> Simulink.Bus.createObject('simplebusdemo', 'simplebusdemo/Bus Creator');
Name Size Bytes Class Attributes
ans 1x1 272 struct
bus1 1x1 Simulink.Bus
bus2 1x1 Simulink.Bus
main_bus 1x1 Simulink.Bus
To look at bus objects, use the buseditor. (click to enlarge)
As of R2008a Simulink has a new bus editor, so unless you
are using this release, your version will look different. The left pane shows
all bus objects in the workspace. The selected node in the tree displays its
children in the center pane, and on the right, you have the details for each
selected element. The information about dimensions, datatype and signal name
are all a part of the bus object. For hierarchical bus signals, the element
datatype is the name of another bus. Looking at the main_bus, it has two
signals, bus1 of type bus1, and bus2 of type bus2. The name and type do not
have to match, but they do in this case.
If you are happy with your bus objects, I recommend saving
them to a MAT-file so you do not have to regenerate them every time. Some
people prefer to generate an M-file and call that as part of their initialization
routines, instead of loading the MAT-file. I have automatically generated this
M-file during the call to Simulink.Bus.createObject. Given an output file
name, Simulink.bus.createObject also outputs the code you need to make that bus
Bus specification in action
If I change my constant input signal to be type int8 instead
of double Simulink will throw an error during update diagram (Ctrl-D).
As you can see, the bus object has locked down the
specification for the signals fed into the bus creator. When something does
not match Simulink reports an error.
Bus objects can be specified on ports
In addition to the bus creators, Inports and Outports can
also be fully specified with a bus object. When a bus object is used on a port
you are asserting that only that special type of connector can be used with
that port. This port could be a root level Inport or Outport, or a port on a
subsystem. If the subsystem is in a library, you have defined its interface,
and all instances of the library block must match the specification.
Getting back to the comment that “[bus objects] are one of
the most important parts of the whole bus concept: allowing you to lock down an
interface.” The concept of locking down an interface is important to
developing reusable components as well as working with others on large modeling
projects. This is a very powerful concept I have seen used in conjunction with
an interface control document (ICD) to define the interface to a system. The
document specifies the characteristics of the bus signals, and the bus object
enforces that those characteristics are true.
I have also seen a Simulink model specify the interface, with a script used
to generate the ICD from the model. This makes the Simulink model the single
source of truth. Your model will always be in sync with the specification if
this is your workflow.
Now it’s your turn
What do you think about bus objects? Do you use them? I
still have not had anyone volunteer to show off their use of bus signals with a
screen capture from their model. Leave a comment
and then send
me an e-mail with the image. I will post it for you and we can all marvel
at your work.
The input bus to block
'simplebusdemo_bo_error/Bus Creator1' does not match the bus specified by the
bus object 'bus1' on the block dialog. The following errors were detected :
Bus element 'Constant' of bus
object 'bus1' is specified to be of datatype 'double', but the incoming signal
has a datatype of 'int8'.
To leave a comment, please click here to sign in to your MathWorks Account or create a new one.