Define Interfaces of Model Components

Step 3 of 3 in Component-Based Modeling Guidelines

Defining the interface of a model component, such as a Simulink^® subsystem, subsystem reference, or model reference, is a key first step before others can use it.

Agreeing on a component interface helps determine how to break down the functionality of a large system into components.
After you define interfaces between components, you can develop the components in parallel. If the interface remains stable, then it is easy to integrate those components into a larger system.
Changing the interface between components is expensive. Changing a component interface requires changes to at least two components (the source and sink) and to test harnesses. The change also makes the previous versions of those components incompatible with the current and future versions.

Changing a component interface is much easier if the components are stored under configuration management. You can track configurations of compatible component versions to prevent incompatible combinations of components.

Note

This topic focuses on component interfaces for modeling and simulation. To configure an interface for code generation and deployment, see:

Design Data Interface by Configuring Inport and Outport Blocks (Simulink Coder)
Choose Storage Class for Controlling Data Representation in Generated Code (Simulink Coder)
C Data Code Interface Configuration for Model Interface Elements (Simulink Coder)
Interactively Configure C++ Interface (Embedded Coder)
Programmatically Configure C++ Interface (Embedded Coder)

Identify Component Boundaries

Base the boundaries of the components upon the boundaries of the corresponding real systems. This guideline is especially useful when the model contains:

Both physical (plant and environment) and control systems
Algorithms that run at different rates
A system that you want to reuse multiple times

If you intend to add sensors or other components as you elaborate your model, create components to represent them. You can configure these components to pass signals straight through or perform a unit delay or name conversion.

Author Component Interfaces

To view and author component interfaces and trace the usage of the elements of the interfaces, use the Component Interface View. In the Simulink Toolstrip, on the Modeling tab, in the Design gallery, select Interface View.

For more information, see Trace Connections and Author Ports Using Component Interface View.

Simplify Component Interfaces with Buses

To simplify interfaces, group signals and messages into buses. Buses simplify subsystem and model interfaces by letting you associate multiple signals or messages with one port. They reduce line complexity and clutter in a block diagram and make it easier to change the interface incrementally. For example, if you must add or remove elements from a component interface, modifying a bus can be simpler than adding or removing ports. To logically group or define the properties of a portion of the interface, use multiple bus ports.

Buses are well suited for components that have many input and output signals and use a subset of the available signals. Buses pass only the required data to each component from the inputs and outputs. If you define the bus at the interface with a Simulink.Bus object, the interface requires data for the entire bus.

To access an element from an input bus, use an In Bus Element block. To create an output bus, use Out Bus Element blocks. For more information, see Simplify Subsystem and Model Interfaces with Bus Element Ports.

How you implement buses at an interface depends on your requirements.

Requirement	Bus Implementation
Provide name-based matching among elements at the interface and simplify line routing	Use buses. Virtual buses meet most modeling requirements. For more information, see Composite Interface Guidelines.
Enable robust component integration with defined interfaces	Use In Bus Element blocks and Out Bus Element blocks to define the properties of the buses at the interface. Use a rigorous naming convention for the buses and bus elements. Optionally, use `Simulink.Bus` objects. To place the bus objects under revision control, save them in a data dictionary, function, script, or MAT file.
Replicate structure type in generated code	Use nonvirtual buses to describe a structured data type for an element in the interface.
Package signals or parameters into structures that correspond to a `struct` type definition that your external C code defines	Import the type as a bus object and use the object as a data type for buses and MATLAB^® structures. To create the object, use the `Simulink.importExternalCTypes` function.

Partition Interface Data for Components

Explicitly control the scope of data for your components with global and nonglobal parameters.

Global parameters — A common approach in the automotive world is to completely separate parameter storage from model storage. The parameters for a model come from a database of calibration data, and the specific calibration file used becomes part of the configuration. The calibration data is treated as global data, and resides in the base MATLAB workspace. You can migrate base workspace data to a data dictionary for more control.
Nonglobal parameters — Combining components that store their own parameter data has the risk of parameter name collisions. If you do not use a naming convention for parameters or a list of unique parameter names and definitions, then two components may use a parameter with the same name but with different meanings.

To store local parameter data:

Partition data into reference dictionaries for each component.
For referenced models, you can use model workspaces.
Use parameter files (.m or .mat) and callbacks of the individual Simulink models (for example, the preload function).
You can also automatically load required data using project shortcuts.
Use mask workspaces with or without the use of mask initialization functions.
For subsystems, you can control the scope of data for a subsystem using the Permit hierarchical resolution parameter of the Subsystem block.

Configure Data Interfaces

Explicitly configure design attributes of the interface, such as data type and numeric complexity, to prevent modeling errors and make component integration easier. You can configure the interface of a component before you develop the internal algorithm, in which case the component contains unconnected blocks.

After you create the blocks that correspond to the component interface:

To configure the design attributes of the blocks, use the Model Data Editor.
To specify a reusable set of design attributes at component interfaces instead of individually specifying each attribute, use the Type Editor.

To open the Model Data Editor, in the Simulink Toolstrip, on the Modeling tab, in the Design gallery, click Model Data Editor.

On the Inports/Outports tab of the Model Data Editor, each row corresponds to an input or output block and the columns correspond to attributes that you can set for the blocks.
By default, the Change view list of the Model Data Editor is set to Design, which configures the columns to correspond to design attributes. Use the columns to explicitly configure the design attributes of the interface. For example, specify minimum and maximum values for each block with the Min and Max columns.
To display the input and output blocks of the subsystems, select the Change Scope button . Alternatively, view only the input and output blocks at the root level of the model by excluding the blocks inside the subsystems.

To open the Type Editor, in the Simulink Toolstrip, on the Modeling tab, in the Design gallery, click Type Editor.

To assign or validate the properties of a signal based on application-specific value types such as wind velocity, tire pressure, or water temperature, use a Simulink.ValueType object.
To assign or validate the properties of each element of a bus, use a Simulink.Bus object.