Main Content

Define Interfaces of Model Components

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 an 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 an interface requires changes to at least two components (the source and any sinks) and to any test harnesses. It also makes all previous versions of those components incompatible with the current and future versions.

Changing an 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 design interfaces for modeling and simulation. To configure an interface for code generation and deployment, see:

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.

Simplify 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 do not use all 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 Buses.

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

Modeling RequirementBus Implementation
Provide name-based matching among elements at the interface and simplify line routingUse virtual buses. While nonvirtual buses also satisfy this modeling requirement, virtual buses provide a simpler solution. For more information, see Types of Composite Signals.
Enable robust component integration with defined interfaces

Use Simulink.Bus objects to define the properties of the virtual buses at the interface. Use a rigorous naming convention for the bus elements and 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 codeUse 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 definesImport 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

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, use:

  • The Model Data Editor to configure the design attributes of the blocks.

    To open the Model Data Editor, on the Modeling tab of the Simulink Toolstrip, 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.

  • The interface display perspective to view the component interface in its entirety and trace elements of the interface to usage points in the internal block algorithm.

    To open the interface display perspective, on the Modeling tab, in the Design gallery, click Model Interface. For more information, see Trace Connections Using Interface Display.

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.

Alternatively, you can specify a reusable set of design attributes at component interfaces instead of individually specifying each attribute.

  • Use Simulink.ValueType objects to assign or validate properties of a signal based on application-specific value types such as wind velocity, tire pressure, or water temperature.

  • Use Simulink.Bus objects to assign or validate the properties of each element of a bus.

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.

Related Topics