Compare Capabilities of Model Components - MATLAB & Simulink (original) (raw)

Main Content

Before you implement a piece of your system using a specific type of model component, consider whether the type of component satisfies your modeling requirements. To identify which component types to consider based on high-level guidelines and use cases, see Explore Types of Model Components.

Popular modeling requirements can be grouped into these categories.

Collaboration — Avoid merge conflicts and share files with third parties.
Reuse — Define a component or its data once and reuse it.
Performance — Simulate and build components faster.
Testing and Certification — Verify the behavior of components.
Interface Design — Specify properties of inputs and outputs.
Custom Behavior — Configure how components behave and when they execute.

Collaboration

Modeling Requirement	Subsystems	Linked Subsystems	Subsystem References	Model References
Separate Files	Not supportedYou save a subsystem in the same file as its parent.To create or change a subsystem, you must edit the parent file, which can lead to file contention and merge problems.	SupportedYou save the parent library block of a linked block in a separate file.Using separate files helps to avoid file contention.	SupportedYou save a referenced subsystem in a separate file.Using separate files helps to avoid file contention.	SupportedYou save a referenced model in a separate file.Using separate files helps to avoid file contention.
Standalone Behavior	Not supportedSubsystems depend on models to provide a context for execution.	Not supportedSame behavior as subsystems.	Not supportedSame behavior as subsystems.	SupportedYou can develop a referenced model independently from the models that use it.To simulate a referenced model as a standalone model, open the referenced model as the top model in a new window. The referenced model must have the data required to execute in a standalone context. For example, the referenced model must have the variables and data types that define parameters and signals.
Version Control and Configuration Management	Not supportedYou cannot directly place subsystems in a source control system.To reduce file contention and use separate version control for each subsystem, use a subsystem reference.	SupportedYou can place library files in a source control system.To provide individual version control for each library block, use subsystem references and model references in the library. When you drag these blocks from the library into your model, they reference the subsystem file or model file.Forwarding tables allow you to map old library blocks to new versions of the blocks.	SupportedYou can place subsystem files in a source control system.	SupportedYou can place model files in a source control system.
Intellectual Property Protection	Not supportedUse model references instead.	Not supportedSame behavior as subsystems.	Not supportedSame behavior as subsystems.	SupportedProtected models obscure model contents, which can be useful when distributing models.Creating a protected model requires aSimulink® Coder™ license. For more information, see Protect Models to Conceal Contents (Simulink Coder).Using a protected model does not require a Simulink Coder license. For more information, see Reference Protected Models from Third Parties.

Reuse

Modeling Requirement	Subsystems	Linked Subsystems	Subsystem References	Model References
Component Reuse	Not supportedWhile you can copy a subsystem to reuse it in a model, the copies are independent of each other.	SupportedYou can link to the same parent library block multiple times in multiple models without creating copies.Managing library links adds some overhead, such as managing broken, disabled, or parameterized links.	SupportedYou can reference the same subsystem multiple times in multiple models without creating copies.	SupportedYou can reference the same model multiple times in multiple models without creating copies. SeeModel Reuse.
Shared Data	SupportedYou can share data among instances by defining the data outside the component. For example, by using a data store in a common parent subsystem.	SupportedSame behavior as subsystems.	SupportedSame behavior as subsystems.	SupportedYou can share data among instances of the referenced model by creating a data store inside the model. See Share Data Among Referenced Model Instances.
Instance-Specific Parameter Values	SupportedSubsystem copies are independent of each other.	SupportedWhen you edit a parent library block, the changes apply to the library file and propagate to the blocks that link to that block.To edit an instance of the block, you can disable the library link.You cannot disable library links when the parent library block has restricted write access.	Not supportedWhen you edit an instance of a referenced subsystem, the changes apply to the subsystem file and propagate to the other instances of the referenced subsystem.	SupportedWhen you edit an instance of a referenced model, the changes apply to the model file and propagate to the other instances of the referenced model.To specify instance-specific parameter values for referenced models, see Configure Instance-Specific Values for Block Parameters in a Referenced Model.
Variants	SupportedAdd subsystem variants to a Variant Subsystem or Variant Model block.For more information, seeImplement Variations in Separate Hierarchy Using Variant Subsystems.	SupportedSame behavior as subsystems.	SupportedSame behavior as subsystems.	SupportedAdd model variants to aVariant Subsystem or Variant Model block.For more information, seeImplement Variations in Separate Hierarchy Using Variant Subsystems.

Performance

Modeling Requirement	Subsystems	Linked Subsystems	Subsystem References	Model References
Incremental Model Loading	Not supportedLoading a model loads the subsystem contents that are saved in the model.	SupportedThe software incrementally loads a library at the point needed during editing, updating a diagram, or simulating a model.	SupportedThe software incrementally loads a referenced subsystem at the point needed during editing, updating a diagram, or simulating a model.	SupportedThe software incrementally loads a referenced model at the point needed during editing, updating a diagram, or simulating a model.
Incremental Model Compilation	Not supportedSubsystems compile as part of their parent model.	Not supportedSame behavior as subsystems.	Not supportedSame behavior as subsystems.	SupportedA referenced model that simulates in accelerator mode compiles according to the value of its Rebuild configuration parameter. Whether a model compiles is independent of other models.
Build Artifact Reuse	Not supportedBuild artifacts, such as simulation targets, are not generated for subsystems.	Not supportedSame behavior as subsystems.	Not supportedSame behavior as subsystems.	SupportedTeam members and continuous integration (CI) systems can generate Simulink cache files for models that you use. These files let you reuse build artifacts, such as simulation targets, which can speed up simulation and code generation. For more information, see Share Simulink Cache Files for Faster Simulation.
Reduced Memory Usage for Large Models	Not supportedSubsystems do not reduce memory usage for simulation and code generation.	Not supportedLinked subsystems do not reduce memory usage for simulation and code generation.Simulink duplicates library block instances during block update.	Not supportedSubsystem references do not reduce memory usage for simulation and code generation.Simulink duplicates subsystem reference instances during block update.	SupportedModels referenced in accelerator mode reduce memory usage for simulation and code generation because Simulink incrementally loads compiled versions of them.
Artificial Algebraic Loop Elimination	SupportedSubsystems that are not atomic avoid artificial algebraic loops.If a subsystem is atomic, you can try to eliminate artificial algebraic loops by enabling theSubsystem block parameter Minimize algebraic loop occurrences.	SupportedSame behavior as subsystems.	SupportedSame behavior as subsystems.	SupportedYou can try to eliminate artificial algebraic loops by enabling > > .
Local Solvers	Not supportedSubsystems inherit the solver of their parent model.	Not supportedSame behavior as subsystems.	Not supportedSame behavior as subsystems.	SupportedYou can use a local solver in a referenced model to solve a model reference as a separate set of differential equations. The local solver can use a different, smaller (since R2024a) or larger step size. The choice of solver and solver settings involves a trade off between speed and accuracy in simulation. For more information, see Use Local Solvers in Referenced Models.
Parallel Builds	Not supportedSubsystems are built as part of their parent model.	Not supportedSame behavior as subsystems.	Not supportedSame behavior as subsystems.	SupportedWith Parallel Computing Toolbox™ software, you can distribute the code generation and compilation for referenced models across a parallel pool of MATLAB® workers.For large model reference hierarchies, you can increase the speed of diagram updates and code generation by building the model reference targets in parallel. For more information, see Reduce Update Time for Referenced Models by Using Parallel Builds and Reduce Build Time for Referenced Models by Using Parallel Builds (Simulink Coder).

Testing and Certification

Modeling Requirement	Subsystems	Linked Subsystems	Subsystem References	Model References
Unit Testing	SupportedIf the context of a subsystem changes, such as the data type of an input signal, the related test harness must be updated.For subsystems that are not atomic, the test harness may use different block execution orders, due to virtual boundaries.For tools that support authoring, managing, and executing systematic, simulation-based tests of subsystems, see Create or Import Test Harnesses and Select Properties (Simulink Test).To measure how thoroughly model components are tested, see Model Coverage (Simulink Coverage).	SupportedSame behavior as subsystems.	SupportedA test harness for a referenced subsystem has the same behavior as a test harness for a subsystem that is not stored in a separate file.While you can create a test harness for a referenced subsystem, you cannot create a test harness for blocks within a referenced subsystem.	SupportedYou can test a referenced model independently to isolate behavior by simulating it as a top model.You can use a data-defined test harness, with MATLAB test vectors and direct coverage collection.For tools that support authoring, managing, and executing systematic, simulation-based tests of subsystems, see Create or Import Test Harnesses and Select Properties (Simulink Test).To measure how thoroughly model components are tested, see Model Coverage (Simulink Coverage).
SIL/PIL Testing	Not supportedWhile you can perform SIL/PIL testing for a model that contains subsystems, you cannot simulate a subsystem independently.	Not supportedSame behavior as subsystems.	Not supportedSame behavior as subsystems.	SupportedTo perform SIL/PIL testing for a model reference hierarchy, see SIL and PIL Simulations (Embedded Coder).
Single-Sourced Code	SupportedBy default, subsystem code is not reusable. To generate reusable subsystem code when possible, see Generate Subsystem Code as Separate Function and Files (Simulink Coder).	SupportedBy default, subsystem code is not reusable. To generate reusable subsystem code when possible, see Generate Reusable Code from Library Subsystems Shared Across Models (Simulink Coder).	SupportedSame behavior as subsystems.	SupportedEach referenced model has one set of source code, regardless of how many times a model hierarchy includes the referenced model. Having single-sourced code can reduce the cost of verification.
Generated Code Traceability	SupportedWhile you can trace the generated code for a subsystem, if the subsystem context changes, the generated code changes. For example, a change to an input signal data type affects the subsystem code.	SupportedSame behavior as subsystems.	SupportedSame behavior as subsystems.	SupportedYou can trace the generated code for a referenced model independent of other models, which reduces the cost of verification.With a Simulink Code Inspector™ license, you can create a traceability matrix for each referenced model. The traceability matrix provides the traceability among model objects, generated code, and model requirements. For more information, see Generate Traceability Matrices (Simulink Code Inspector).

Interface Design

Modeling Requirement	Subsystems	Linked Subsystems	Subsystem References	Model References
Signal Property Specification at Interfaces	SupportedYou can specify signal properties at a subsystem interface.For signal properties that you do not specify, subsystems inherit the signal properties from their context. Propagation of signal properties can lead to Simulink using signal properties that you do not anticipate.	SupportedSame behavior as subsystems.	SupportedSame behavior as subsystems.	SupportedYou must specify most signal properties at a referenced model interface.Referenced models are context-independent with a defined boundary, so they do not inherit most signal properties.Referenced models can inherit discrete sample times when the referenced model is sample-time independent.
Physical Connections at Interfaces	SupportedYou can specify physical connections at a subsystem interface.	SupportedSame behavior as subsystems.	SupportedSame behavior as subsystems.	Not supportedPhysical connections must be fully contained within a referenced model. They cannot cross the model interface.
Bus Specification at Interfaces	SupportedYou can use aSimulink.Bus object, In Bus Element block, orOut Bus Element block to specify the hierarchy and properties of a bus that passes into or out of a subsystem.Subsystems do not require the use of bus objects for virtual buses.	SupportedSame behavior as subsystems.	SupportedSame behavior as subsystems.	SupportedYou can use aSimulink.Bus object, In Bus Element block, orOut Bus Element block to specify the hierarchy and properties of a bus that passes into or out of a referenced model.Model references do not require the use of bus objects for virtual buses when you use In Bus Element and Out Bus Element blocks.

Custom Behavior

Modeling Requirement	Subsystems	Linked Subsystems	Subsystem References	Model References
Unique Configuration Parameter Settings	Not supportedSubsystems use the configuration parameter settings of the model that contains them.	Not supportedSame behavior as subsystems.	Not supportedSame behavior as subsystems.	SupportedConfiguration parameter settings can generally be different for a parent model and its referenced models. For compatibility information, see Set Configuration Parameters for Model Hierarchies.
State Initialization	SupportedYou can initialize states of subsystems.	SupportedSame behavior as subsystems.	SupportedSame behavior as subsystems.	SupportedYou can initialize states from the top model using either the structure format or structure-with-time format.
Conditional Execution	SupportedSubsystems support conditional execution. For more information, see Conditionally Executed Subsystems Overview.	SupportedSame behavior as subsystems.	SupportedSame behavior as subsystems.	SupportedReferenced models support conditional execution. For more information, see Conditionally Execute Referenced Models.
Event-Based Behavior	SupportedSubsystems support event-based behavior. For more information, see Using Initialize, Reinitialize, Reset, and Terminate Functions.	SupportedSame behavior as subsystems.	SupportedSame behavior as subsystems.	SupportedReferenced models support event-based behavior. For more information, see Using Initialize, Reinitialize, Reset, and Terminate Functions.
Independent Functions	SupportedYou can define independent functions in subsystems. For more information, see Simulink Functions Overview.	SupportedSame behavior as subsystems.	SupportedSame behavior as subsystems.	SupportedYou can define independent functions in a referenced model. For more information, see Export-Function Models Overview.