Main Content

Reuse Model Components from Files

When working on a large model, you can separate it into multiple files so that team members can develop different model components at the same time. You can reuse these components multiple times in a model and in other models.

Model, subsystem, and library files provide a single source for multiple instances of the same model component. To learn when you should use each of these componentization methods, see Component-Based Modeling Guidelines.

In this example, the model hierarchy contains subsystems, referenced subsystems, and referenced models. The referenced subsystems and models are stored in separate files.

The model named BasicModelingComponents contains subsystems at its top level.

topmdl = "BasicModelingComponents";
open_system(topmdl)
set_param(topmdl,SimulationCommand="Update");

Top level of model with Subsystem blocks

Referenced Subsystems

From the top model, double-click the Subsystem block named Plant. This subsystem contains Subsystem Reference blocks named MassSpringDamperLeft and MassSpringDamperRight.

Plant subsystem with two Subsystem Reference blocks

Both Subsystem Reference blocks reference a subsystem file named BasicModelingPlant.slx.

refss = "BasicModelingPlant";
open_system(refss)

Referenced subsystem opened separately

The PreloadFcn callback loads the related variables from a script named BasicModelingDataPlant.m.

While you can define a subsystem for reuse in either a library or subsystem file, subsystem files allow for easier editing. When you edit a referenced subsystem, the changes apply to the subsystem file and all instances of the referenced subsystem.

Referenced Models

From the top model, double-click the Subsystem block named Controller. This subsystem contains a Model block named Controller.

Controller subsystem with a Model block

The Model block references a model file named BasicModelingController.slx.

refmdl = "BasicModelingController";
open_system(refmdl)

Referenced model opened separately

The PreloadFcn callback loads the related variables from a script named BasicModelingDataController.m.

Controller code is often deployed on embedded systems, so having a standalone controller model is useful.

An embedded processor might not support default properties for the controller. Since a controller model might be used to generate code for an embedded processor, these constraints apply to the referenced controller model and the interface with its parent model:

  • Fixed signal attributes — To require that buses at model interfaces share the same signal attributes, bus objects specify signal attributes at the three sets of input and output ports.

  • Discrete sample time — To specify a discrete sample time, the model file named BasicModelingController.slx specifies a discrete execution domain and the script named BasicModelingDataController.m specifies discrete PID controller values.

  • Fixed data type — To apply the single-precision data type required by the embedded processor, Data Type Conversion blocks convert the data types of the bus elements before the elements reach the model interface.

Related Topics