Choose Among Composite Interfaces

Step 1 of 2 in Composite Interface Guidelines

To reduce visual complexity in a model, you can group multiple signals, messages, or conserving connections into a composite interface for a block or model component. The grouped elements retain their separate identities, and you can extract them.

As you create composite interfaces, consider these potential requirements:

Name-based element access — Meaningful element names and hierarchy can simplify element selection and mapping.
Reusability — Bus objects provide a reusable interface definition that you can apply as long as the definition is available to the model.
Code generation — The type of composite interface can make a significant difference in the efficiency, size, and readability of the generated code. For a bus to appear in the generated code, it must be nonvirtual. Only the elements of a virtual bus appear in the generated code.

Composite Interfaces

The different types of composite interfaces serve a variety of modeling requirements.

Type of Composite Interface	Definition	Appearance in Model
Virtual bus	A virtual bus is a flexible group of named elements.
Nonvirtual bus	A nonvirtual bus is a defined group of named elements.
Array of buses	An array of buses is an array of nonvirtual buses that have the same interface definition.
Mux signal	A mux signal is a virtual vector.	(default) (Wide nonscalar lines information overlay enabled)
Concatenated signal	A concatenated signal is a nonvirtual vector, matrix, or array.	(default) (Wide nonscalar lines information overlay enabled)

Models can use any combination of these interfaces.

You can identify composite interfaces by their line style after you compile the model. When you create a composite interface or open a model that contains composite interfaces, the composite interfaces have the same line style as scalar signals. To compile the model and show the composite interface line styles, in the Simulink^® Toolstrip, on the Modeling tab, select Update Model.

High-Level Composite Interface Selection Guidelines

Each type of composite interface has an ideal use case:

Virtual bus — Ideal for flexible interfaces and incremental changes
Nonvirtual bus — Ideal for defined interfaces in code generation
Array of buses — Ideal for iterative processing of multiple elements
Mux signal — Ideal for grouping multiple callers to function-call subsystems
Concatenated signal — Ideal for iterative processing of individual elements

The ideal use cases are a subset of the possible use cases for each type of composite interface. For example, you can use a virtual bus that specifies a Simulink.Bus object to define an interface.

This flow chart helps you choose a composite interface type to consider.

The flow chart visualizes the ideal use cases.

The flow chart identifies whether you have one of these specialized use cases for a composite interface:

If the interface will provide multiple signals for a subsystem to iteratively process, consider an array of buses.
If the interface will provide one signal for a subsystem to iteratively process, consider a concatenated signal.
If the interface will provide multiple callers to a function-call subsystem, consider a mux signal.
If you will require the generated code to use a data structure to represent the interface, consider a nonvirtual bus.

For all other use cases, consider a virtual bus.

Modeling Requirement Considerations

Before implementing a composite interface based on the high-level guidelines, consider additional modeling requirements. For example, if you want to group messages, you must use a virtual bus.

When possible, use buses instead of mux signals and concatenated signals. To determine whether a virtual bus, nonvirtual bus, or array of buses meets your modeling requirements, see Compare Capabilities of Composite Interfaces.