Compare Capabilities of Model Components

Step 2 of 3 in Component-Based Modeling Guidelines

Before you implement a piece of your system using a specific type of model component, consider whether the component type satisfies your modeling requirements.

Tip

To identify which component types to consider based on high-level guidelines and use cases, see Choose Among Types of Model Components.

Component Consideration	Modeling Requirements
Development Process	Separate files Component reuse Shared data Instance-specific edits Variants Version control and configuration management Intellectual property protection Unit testing
Performance Requirements	Incremental model loading Build artifact reuse Reduced memory usage for large models Artificial algebraic loop elimination
Features	Compatible configuration parameter settings Signal property specification at interfaces Physical connections at interfaces Bus specification State initialization Conditional execution Event-based behavior Independent functions

Note

For code generation considerations, see:

Subsystems (Simulink Coder)
Generate Code for Model Reference Hierarchy (Simulink Coder)
Map System Architecture to Simulink Modeling Environment (Simulink Coder)
Map Embedded System Architecture to Simulink Modeling Environment (Embedded Coder)

Development Process

Modeling Requirement	Subsystems	Linked Subsystems	Subsystem References	Model References
Separate Files	Not supported You 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.	Supported You save the parent library block of a linked block in a separate file. Using separate files helps to avoid file contention.	Supported You save a referenced subsystem in a separate file. Using separate files helps to avoid file contention.	Supported You save a referenced model in a separate file. Using separate files helps to avoid file contention.
Component Reuse	Not supported While you can copy a subsystem to reuse it in a model, the copies are independent of each other.	Supported You 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.	Supported You can reference the same subsystem multiple times in multiple models without creating copies.	Supported You can reference the same model multiple times in multiple models without creating copies. See Model Reuse.
Shared Data	Supported You can share data among instances by defining the data outside the component. For example, by using a data store in a common parent subsystem.	Supported Same behavior as subsystems.	Supported Same behavior as subsystems.	Supported You 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 Edits	Supported Subsystem copies are independent of each other.	Supported When you edit a parent library block, the changes apply to the library file and propagate to all 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 supported When you edit an instance of a referenced subsystem, the changes apply to the subsystem file and propagate to all other instances of the referenced subsystem.	Not supported When you edit an instance of a referenced model, the changes apply to the model file and propagate to all other instances of the referenced model. You can specify instance-specific parameter values for referenced models. For more information, see Parameterize Instances of a Reusable Referenced Model.
Variants	Supported Add subsystem variants to a Variant Subsystem or Variant Model block. For more information, see Implement Variations in Separate Hierarchy Using Variant Subsystems.	Supported Same behavior as subsystems.	Supported Same behavior as subsystems.	Supported Add model variants to a Variant Subsystem or Variant Model block. For more information, see Implement Variations in Separate Hierarchy Using Variant Subsystems.
Version Control and Configuration Management	Not supported You 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.	Supported You 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.	Supported You can place subsystem files in a source control system.	Supported You can place model files in a source control system.
Intellectual Property Protection	Not supported Use model references instead.	Not supported Same behavior as subsystems.	Not supported Same behavior as subsystems.	Supported Protected models obscure model contents, which can be useful when distributing models. Creating a protected model requires a Simulink^® 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.
Unit Testing	Supported Subsystems are dependent on their context in a model. If 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).	Supported Same behavior as subsystems.	Supported A 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.	Supported You 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).

Modeling Requirement

Subsystems

Linked Subsystems

Subsystem References

Model References

Separate Files

Not supported

You 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.

Supported

You save the parent library block of a linked block in a separate file.

Using separate files helps to avoid file contention.

Supported

You save a referenced subsystem in a separate file.

Using separate files helps to avoid file contention.

Supported

You save a referenced model in a separate file.

Using separate files helps to avoid file contention.

Component Reuse

Not supported

While you can copy a subsystem to reuse it in a model, the copies are independent of each other.

Supported

You 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.

Supported

You can reference the same subsystem multiple times in multiple models without creating copies.

Supported

You can reference the same model multiple times in multiple models without creating copies. See Model Reuse.

Shared Data

Supported

You can share data among instances by defining the data outside the component. For example, by using a data store in a common parent subsystem.

Supported

Same behavior as subsystems.

Supported

Same behavior as subsystems.

Supported

You 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 Edits

Supported

Subsystem copies are independent of each other.

Supported

When you edit a parent library block, the changes apply to the library file and propagate to all 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 supported

When you edit an instance of a referenced subsystem, the changes apply to the subsystem file and propagate to all other instances of the referenced subsystem.

Not supported

When you edit an instance of a referenced model, the changes apply to the model file and propagate to all other instances of the referenced model.

You can specify instance-specific parameter values for referenced models. For more information, see Parameterize Instances of a Reusable Referenced Model.

Variants

Supported

Add subsystem variants to a Variant Subsystem or Variant Model block.

For more information, see Implement Variations in Separate Hierarchy Using Variant Subsystems.

Supported

Same behavior as subsystems.

Supported

Same behavior as subsystems.

Supported

Add model variants to a Variant Subsystem or Variant Model block.

For more information, see Implement Variations in Separate Hierarchy Using Variant Subsystems.

Version Control and Configuration Management

Not supported

You 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.

Supported

You 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.

Supported

You can place subsystem files in a source control system.

Supported

You can place model files in a source control system.

Intellectual Property Protection

Not supported

Use model references instead.

Not supported

Same behavior as subsystems.

Not supported

Same behavior as subsystems.

Supported

Protected models obscure model contents, which can be useful when distributing models.

Creating a protected model requires a Simulink^® 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.

Unit Testing

Supported

Subsystems are dependent on their context in a model. If 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).

Supported

Same behavior as subsystems.

Supported

A 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.

Supported

You 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).

Performance Requirements

Modeling Requirement	Subsystems	Linked Subsystems	Subsystem References	Model References
Incremental Model Loading	Not supported Loading a model loads all subsystem contents that are saved in the model.	Supported Simulink incrementally loads a library at the point needed during editing, updating a diagram, or simulating a model.	Supported Simulink incrementally loads a referenced subsystem at the point needed during editing, updating a diagram, or simulating a model.	Supported Simulink incrementally loads a referenced model at the point needed during editing, updating a diagram, or simulating a model.
Build Artifact Reuse	Not supported Build artifacts, such as simulation targets, are not generated for subsystems.	Not supported Same behavior as subsystems.	Not supported Same behavior as subsystems.	Supported You can share and reuse build artifacts, such as simulation targets, using Simulink cache files. For more information, see Share Simulink Cache Files for Faster Simulation.
Reduced Memory Usage for Large Models	Not supported Subsystems do not reduce memory usage for simulation and code generation.	Not supported Linked subsystems do not reduce memory usage for simulation and code generation. Simulink duplicates library block instances during block update.	Not supported Subsystem references do not reduce memory usage for simulation and code generation. Simulink duplicates subsystem reference instances during block update.	Supported Models referenced in accelerator mode reduce memory usage for simulation and code generation because Simulink incrementally loads compiled versions of them.
Artificial Algebraic Loop Elimination	Supported Subsystems that are not atomic avoid artificial algebraic loops. If a subsystem is atomic, you can try to eliminate artificial algebraic loops by enabling the Subsystem block parameter Minimize algebraic loop occurrences.	Supported Same behavior as subsystems.	Supported Same behavior as subsystems.	Supported You can try to eliminate artificial algebraic loops by enabling Configuration Parameters > Model Referencing > Minimize algebraic loop occurrences.

Modeling Requirement

Subsystems

Linked Subsystems

Subsystem References

Model References

Incremental Model Loading

Not supported

Loading a model loads all subsystem contents that are saved in the model.

Supported

Simulink incrementally loads a library at the point needed during editing, updating a diagram, or simulating a model.

Supported

Simulink incrementally loads a referenced subsystem at the point needed during editing, updating a diagram, or simulating a model.

Supported

Simulink incrementally loads a referenced model at the point needed during editing, updating a diagram, or simulating a model.

Build Artifact Reuse

Not supported

Build artifacts, such as simulation targets, are not generated for subsystems.

Not supported

Same behavior as subsystems.

Not supported

Same behavior as subsystems.

Supported

You can share and reuse build artifacts, such as simulation targets, using Simulink cache files. For more information, see Share Simulink Cache Files for Faster Simulation.

Reduced Memory Usage for Large Models

Not supported

Subsystems do not reduce memory usage for simulation and code generation.

Not supported

Linked subsystems do not reduce memory usage for simulation and code generation.

Simulink duplicates library block instances during block update.

Not supported

Subsystem references do not reduce memory usage for simulation and code generation.

Simulink duplicates subsystem reference instances during block update.

Supported

Models referenced in accelerator mode reduce memory usage for simulation and code generation because Simulink incrementally loads compiled versions of them.

Artificial Algebraic Loop Elimination

Supported

Subsystems that are not atomic avoid artificial algebraic loops.

If a subsystem is atomic, you can try to eliminate artificial algebraic loops by enabling the Subsystem block parameter Minimize algebraic loop occurrences.

Supported

Same behavior as subsystems.

Supported

Same behavior as subsystems.

Supported

You can try to eliminate artificial algebraic loops by enabling Configuration Parameters > Model Referencing > Minimize algebraic loop occurrences.

Features

Modeling Requirement Subsystems Linked Subsystems Subsystem References Model References

Modeling Requirement	Subsystems	Linked Subsystems	Subsystem References	Model References
Compatible Configuration Parameter Settings	Supported Subsystems use the configuration parameter settings of the model that contains them.	Supported Same behavior as subsystems.	Supported Same behavior as subsystems.	Supported Configuration parameter settings can generally be different for a parent model and its referenced models. For compatibility information, see Set Configuration Parameters for Model Hierarchies.
Signal Property Specification at Interfaces	Supported You 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.	Supported Same behavior as subsystems.	Supported Same behavior as subsystems.	Supported You 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	Supported You can specify physical connections at a subsystem interface.	Supported Same behavior as subsystems.	Supported Same behavior as subsystems.	Not supported Physical connections must be fully contained within a referenced model. They cannot cross the model interface.
Bus Specification	Supported You can use a `Simulink.Bus` object to specify the data type of a bus that passes into a subsystem. Subsystems do not require the use of `Bus` objects for virtual buses.	Supported Same behavior as subsystems.	Supported Same behavior as subsystems.	Supported You can use a `Simulink.Bus` object to specify the data type of a bus that passes into 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.
State Initialization	Supported You can initialize states of subsystems.	Supported Same behavior as subsystems.	Supported Same behavior as subsystems.	Supported You can initialize states from the top model using either the structure format or structure-with-time format.
Conditional Execution	Supported Subsystems support conditional execution. For more information, see Conditionally Executed Subsystems Overview.	Supported Same behavior as subsystems.	Supported Same behavior as subsystems.	Supported Referenced models support conditional execution. For more information, see Conditionally Execute Referenced Models.
Event-Based Behavior	Supported Subsystems support event-based behavior. For more information, see Using Initialize, Reinitialize, Reset, and Terminate Functions.	Supported Same behavior as subsystems.	Supported Same behavior as subsystems.	Supported Referenced models support event-based behavior. For more information, see Using Initialize, Reinitialize, Reset, and Terminate Functions.
Independent Functions	Supported You can define independent functions in subsystems. For more information, see Simulink Functions Overview.	Supported Same behavior as subsystems.	Supported Same behavior as subsystems.	Supported You can define independent functions in a referenced model. For more information, see Export-Function Models Overview.

Compatible Configuration Parameter Settings

Supported

Subsystems use the configuration parameter settings of the model that contains them.

Supported

Same behavior as subsystems.

Supported

Same behavior as subsystems.

Supported

Configuration parameter settings can generally be different for a parent model and its referenced models. For compatibility information, see Set Configuration Parameters for Model Hierarchies.

Signal Property Specification at Interfaces

Supported

You 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.

Supported

Same behavior as subsystems.

Supported

Same behavior as subsystems.

Supported

You 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

Supported

You can specify physical connections at a subsystem interface.

Supported

Same behavior as subsystems.

Supported

Same behavior as subsystems.

Not supported

Physical connections must be fully contained within a referenced model. They cannot cross the model interface.

Bus Specification

Supported

You can use a Simulink.Bus object to specify the data type of a bus that passes into a subsystem.

Subsystems do not require the use of Bus objects for virtual buses.

Supported

Same behavior as subsystems.

Supported

Same behavior as subsystems.

Supported

You can use a Simulink.Bus object to specify the data type of a bus that passes into 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.

State Initialization

Supported

You can initialize states of subsystems.

Supported

Same behavior as subsystems.

Supported

Same behavior as subsystems.

Supported

You can initialize states from the top model using either the structure format or structure-with-time format.

Conditional Execution

Supported

Subsystems support conditional execution. For more information, see Conditionally Executed Subsystems Overview.

Supported

Same behavior as subsystems.

Supported

Same behavior as subsystems.

Supported

Referenced models support conditional execution. For more information, see Conditionally Execute Referenced Models.

Event-Based Behavior

Supported

Subsystems support event-based behavior. For more information, see Using Initialize, Reinitialize, Reset, and Terminate Functions.

Supported

Same behavior as subsystems.

Supported

Same behavior as subsystems.

Supported

Referenced models support event-based behavior. For more information, see Using Initialize, Reinitialize, Reset, and Terminate Functions.

Independent Functions

Supported

You can define independent functions in subsystems. For more information, see Simulink Functions Overview.

Supported

Same behavior as subsystems.

Supported

Same behavior as subsystems.

Supported

You can define independent functions in a referenced model. For more information, see Export-Function Models Overview.

External Websites

11 Best Practices for Developing ISO 26262 Applications with Simulink

Component-Based Modeling Guidelines