Documentation Center

  • Trial Software
  • Product Updates

Componentization Guidelines

Componentization

A component is a piece of your design, a unit level item, or a subassembly, that you can work on without needing the higher level parts of the model.

Componentization involves organizing your model into components. Componentization provides many benefits for organizations that develop large Simulink® models that consist of many functional pieces. The benefits include:

  • Meeting development process requirements, such as:

    • Component reuse

    • Team-based development

    • Intellectual property protection

    • Unit testing

  • Improving performance for:

    • Model loading

    • Simulation speed

    • Memory usage

Componentization Techniques

Key componentization techniques that you can use with Simulink include:

  • Subsystems

  • Libraries

  • Model referencing

These componentization techniques support a wide range of modeling requirements for models that vary in size and complexity. Most large models use a combination of componentization techniques. For example, you can include subsystems in referenced models, and include referenced models in subsystems. As another example, a large model might use model reference Accelerator blocks at the top level component partitions and blend model reference Accelerator and atomic subsystem libraries at lower levels.

Simulink provides tools to convert from subsystems to model referencing. Because of the differences between subsystems and model referencing, switching from subsystems to model referencing can involve several steps (see Converting a Subsystem to a Referenced Model). Consider scalability and support for anticipated future modeling requirements, such as how a model is likely to grow in size and complexity and possible code generation requirements. Designing a scalable architecture can avoid later conversion costs.

General Componentization Guidelines

This table provides high-level guidelines about the kinds of modeling goals and models for which subsystems, libraries, and model referencing are each particularly well suited.

Componentization TechniqueModeling Goals for Which the Technique Is Well Suited

Subsystems

  • Add hierarchy to organize and visually simplify a model.

  • Maximize design reuse with inherited attributes for context-dependent behavior.

Libraries

  • Provide a frequently used, and infrequently changed, modeling utility.

  • Reuse components repeatedly in a model or in multiple models.

Model referencing

  • Develop a referenced model independently from the models that use it.

  • Obscure the contents of a referenced model, allowing you to distribute it without revealing the intellectual property that it embodies.

  • Reference a model multiple times without having to make redundant copies.

  • Facilitate changes by multiple people, with defined interfaces for top-level components.

  • Improve the overall performance by using incremental model loading, update diagram, simulation, and code generation for large models (for example, a model with 10,000 blocks).

  • Perform unit testing.

  • Simplify debugging for large models.

  • Generate code that reflects the model structure.

For a more detailed comparison of these modeling techniques, see Summary of Componentization Techniques.

Summary of Componentization Techniques

This section compares subsystems, libraries, and model referencing. The table includes recommendations and notes about a range of modeling requirements and features.

Modeling Requirement or FeatureSubsystemsLibrariesModel Referencing

Development Process

Component reuse

 Not supported

 Well suited

 Well suited

Team-based development

 Not supported

 Supported, with limitations

 Well suited

Intellectual property protection

 Not supported

 Not supported

 Well suited

Unit testing

 Supported, with limitations

 Supported, with limitations

 Well suited

Performance

Model loading speed

 Supported, with limitations

 Well suited

 Well suited

Simulation speed for large models

 Supported, with limitations

 Supported, with limitations

 Well suited

Memory

 Supported, with limitations

 Supported, with limitations

 Well suited

Artificial algebraic loop avoidance

 Well suited

 Well suited

 Supported, with limitations

Features

Signal property inheritance

 Well suited

 Well suited

 Supported, with limitations

State initialization

 Well suited

 Well suited

 Supported, with limitations

Tunability

 Well suited

 Well suited

 Supported, with limitations

Buses

 Well suited

 Well suited

 Supported, with limitations

S-functions

 Well suited

 Well suited

 Supported, with limitations

Model configuration settings

 Well suited

 Well suited

 Supported, with limitations

Tools

 Well suited

 Supported, with limitations

 Supported, with limitations

Code generation

 Supported, with limitations

 Supported, with limitations

 Well suited

For each modeling technique, you can see a summary table that includes the more detailed information included in the links in the above summary table of componentization techniques:

Subsystems Summary

This section provides guidelines for using subsystems for each of the modeling requirements and features highlighted in the Summary of Componentization Techniques.

For additional information about subsystems, see:

Modeling Requirement or FeatureGuidelines for Subsystems

Development Process

Component reuse

Not supported

  • Copy a subsystem to reuse it in a model.

  • Subsystem copies are independent of each other.

  • Save a subsystem by saving the model that contains the subsystem.

  • Configuration management for subsystems is difficult.

Team-based development

Not supported

  • For subsystems in a model, Simulink provides no direct interface with source control tools.

  • To create or change a subsystem, you need to open the parent model's file. This can lead to file contention when multiple people want to work on multiple subsystems in a model.

Intellectual property protection

Not supported

Use model referencing protected models instead.

Unit testing

Supported, with limitations

  • For coverage testing, use Signal Builder and source blocks.

  • Each time a subsystem changes, you need to copy the subsystem to a harness model.

  • The test harness may have different Simulink sort orders, due to virtual boundaries.

  • Test harness files require configuration management overhead.

Performance

Model loading speed

Supported, with limitations

Loading a model loads all subsystems at one time. There is no incremental loading.

Simulation speed for large models

Supported, with limitations

  • To speed simulation, use Accelerator or Rapid Accelerator simulation mode.

  • Simulation mode applies to the whole model. Model referencing provides a finer level of control for simulation modes.

Memory

Supported, with limitations

Memory use for simulation and code generation is comparable for subsystems and libraries. For models with over 500 blocks, model reference Accelerator mode can significantly reduce memory usage for simulation and code generation.

Artificial algebraic loop avoidance

Well suited

  • Virtual subsystems avoid artificial algebraic loops.

  • For nonvirtual subsystems, consider enabling the Subsystem block parameter Minimize algebraic loop occurrences.

Features

Signal property inheritance

Well suited

  • Inheriting signal properties from outside of the subsystem boundary avoids your having to specify properties for every signal.

  • Propagation of signal properties can lead to Simulink using signal properties that you did not anticipate.

State initialization

Well suited

You can initialize states of subsystems.

Tunability

Well suited

  • Tune subsystems using a block parameterization or masked subsystems.

  • Control tunability using Configuration Parameters > Optimization > Signals and Parameters > Inline parameters.

Buses

Well suited

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

S-functions

Well suited

Subsystems support inlined or noninlined S-functions.

Model configuration settings

Well suited

A subsystem uses the model configuration settings of the model that contains the subsystem.

Tools

Well suited

Subsystems provide extensive support for Simulink tools.

Code generation

Supported, with limitations

  • To generate code for a subsystem by itself, right-click the Subsystem block and select a code generation option.

  • As an optimization, Simulink attempts to recognize identical subsystems. For detected identical subsystems, the generated code includes only one copy of code for the multiple subsystems.

  • For virtual subsystems, you cannot specify file or function code partitions for code generation.

Libraries Summary

This section provides guidelines for using libraries for each of the modeling requirements and features highlighted in the Summary of Componentization Techniques.

For additional information about libraries, see Libraries.

Modeling Requirement or FeatureGuidelines for Libraries

Development Process

Component reuse

Well suited

  • Access a collection of well-defined utility blocks.

  • Create a component once and reuse it in models.

  • Link to the same library block multiple times without creating multiple copies.

  • Link to the same library block from multiple models.

  • Restrict write access to library components.

  • Maintain one truth: propagate changes from a single library block to all blocks that link to that library.

  • Disable a link to allow independent changes to a linked block.

  • Managing library links adds some overhead.

  • Save library in a file similar to a Simulink model, but you cannot simulate the file contents.

Team-based development

Supported, with limitations

  • Place library files in source control for version control and configuration management.

  • Maintain one truth: propagate changes from a single library block to all blocks that link to that library.

  • To reduce file contention, use one subsystem per library.

  • Link to the same library block from multiple models.

  • Restrict write access to library component.

  • See General Reusability Limitations.

Intellectual property protection

Not supported

Use model referencing protected models instead.

Unit testing

Supported, with limitations

  • For coverage testing, use Signal Builder and source blocks.

  • Test harness may have different Simulink sort orders, due to virtual boundaries.

  • Test harness files require configuration management overhead.

Performance

Model loading speed

Well suited

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

Simulation speed for large models

Supported, with limitations

  • To speed simulation, use Accelerator or Rapid Accelerator simulation mode.

  • Simulation mode applies to the whole model. Model referencing provides a finer level of control for simulation modes.

Memory

Supported, with limitations

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

  • Simulink duplicates library block instances during block update.

  • Memory usage for simulation and code generation is comparable for subsystems and libraries. For models with over 500 blocks, model reference Accelerator mode can significantly reduce memory usage for simulation and code generation.

Artificial algebraic loop avoidance

Well suited

  • Virtual subsystems avoid artificial algebraic loops.

  • For nonvirtual subsystems, consider enabling the Subsystem block parameter Minimize algebraic loop occurrences.

Features

Signal property inheritance

Well suited

  • Inheriting signal properties from outside of the library block boundary avoids your having to specify properties for every signal.

  • Propagation of signal properties can lead to Simulink using signal properties that you did not anticipate.

State initialization

Well suited

You can initialize states of library blocks.

Tunability

Well suited

  • Tune library blocks using block parameterization or masked subsystems.

  • Control tunability using Configuration Parameters > Optimization > Signals and Parameters > Inline parameters.

Buses

Well suited

Libraries do not require the use of bus objects for virtual buses.

S-functions

Well suited

Libraries support inlined and noninlined S-functions.

Model configuration settings

Well suited

  • Library models do not have model configuration settings.

  • A referenced library block uses the model configuration setting of the model that contains that block.

Tools

Supported, with limitations

There are some limitations for using some Simulink tools, such as the Model Advisor, with libraries.

Code generation

Supported, with limitations

  • As an optimization, Simulink attempts to recognize identical subsystems. For detected identical subsystems, the generated code includes only one copy of code for the multiple subsystems.

  • For virtual subsystems, you cannot specify file or function code partitions for code generation.

Model Referencing Summary

This section provides guidelines for using model referencing for each of the modeling requirements and features highlighted in the Summary of Componentization Techniques.

For additional information about model referencing, see:

Modeling Requirement or FeatureGuidelines for Model Referencing

Development Process Requirements

Component reuse

Well suited

  • Create a standalone component once and reuse it in multiple models.

  • Reference the same model multiple times without creating multiple copies.

  • Reference the same model from multiple models.

  • Model referencing uses specified boundaries for preserving component integrity.

Team-based development

Well suited

  • For version control and configuration management, you can place model reference files in a source control system.

  • Design, create, simulate, and test a referenced model independently from the model that references it.

  • Link to the same model reference from multiple models.

  • Changes made to a referenced model apply to all instances of that referenced model.

  • Simulink does not limit access for changing a model reference.

  • You save a referenced model in a separate file from the model that references it. Using separate files helps to avoid file contention.

Intellectual property protection

Well suited

  • Use the protected model feature to obscure contents of a referenced model in a distributed model.

  • Creating a protected model feature requires a Simulink Coder license. Using a protected model does not require a Simulink Coder license.

Unit testing

Well suited

  • Test components independently to isolate behaviors, by simulating them standalone.

  • You can eliminate unit retest for unchanged components.

  • Use a data-defined test harness, with MATLAB test vectors and direct coverage collection.

  • For coverage testing, use root inports and outports.

Performance

Model loading speed

Well suited

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

  • If a simulation target build is required, first-time loading can be slow.

Simulation speed for large models

Well suited

Memory

Well suited

  • Simulink loads a referenced model at the point that model is needed for navigation during editing, updating a diagram, or simulating a model.

  • Use model reference Accelerator mode to reduce memory usage, incrementally loading a compiled version of a referenced model.

Artificial algebraic loop avoidance

Supported, with limitations

Consider enabling Configuration Parameters > Model Referencing > Minimize algebraic loop occurrences.

Features

Signal property inheritance

Supported, with limitations

  • Inherit sample time when the referenced model is sample-time independent. You cannot propagate a continuous sample time to a Model block that is sample-time independent.

  • Model block is context-independent, so it cannot inherit signal properties. Explicitly set input and output signal properties.

  • Use a bus object to define the signal data type of a bus signal that is passed into a referenced model.

  • Goto and From block lines cannot cross model referencing boundaries.

  • See Index Base Limitations.

State initialization

Supported, with limitations

  • You can initialize states from the top model.

  • Use either the structure format or structure with time format to initialize the states of a top model and the models that it references.

  • To use the SimState (simulation state) feature with model referencing, simulate all Model blocks in Normal mode.

  • See Import and Export State Information for Referenced Models.

Tunability

Supported, with limitations

  • To have each instance of a referenced model use different values, use model arguments in the Model block.

  • To have each instance of a referenced model use the same values, use Simulink.Parameter objects.

  • To have each instance of a referenced model use the same values, use Simulink.Parameter objects.

    By default, all other parameters are inlined.

Buses

Supported, with limitations

You must use bus objects for bus signals that cross referenced model boundaries (for example, global data stores, root inports, root outports).

S-functions

Supported, with limitations

Model referencing generally supports inlined or noninlined S-functions. See S-Function Limitations.

Model configuration settings

Supported, with limitations

  • To apply the same model configuration settings to all models in a model hierarchy, use a referenced configuration set.

  • Configuration settings for the root model and referenced models must be consistent. However, not all configuration settings need to be the same across the model hierarchy.

Tools

Supported, with limitations

  • There are some limitations for using some Simulink tools, such as the Simulink Debugger, with model referencing.

  • For details, see Simulink Tool Limitations.

Code generation

Well suited

  • By default, model referencing generates code incrementally.

  • You can improve rebuild performance by selecting the appropriate setting for the Configuration Parameters > Model Referencing > Rebuild parameter.

  • Model referencing requires the use of bus objects. For information about the impact of bus objects for code generation, in the Embedded Coder documentation, see Buses.

Related Examples

More About

Was this topic helpful?