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");
Referenced Subsystems
From the top model, double-click the Subsystem block named Plant
. This subsystem contains Subsystem Reference blocks named MassSpringDamperLeft
and MassSpringDamperRight
.
Both Subsystem Reference blocks reference a subsystem file named BasicModelingPlant.slx
.
refss = "BasicModelingPlant";
open_system(refss)
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
.
The Model block references a model file named BasicModelingController.slx
.
refmdl = "BasicModelingController";
open_system(refmdl)
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 namedBasicModelingDataController.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.