Component-Based Modeling Guidelines

Component-based modeling helps organizations develop Simulink^® models that consist of many functional pieces. Each Simulink component you create is a piece of your design that has an interface and facilitates assembly of a system or a larger component. Useful model components have a well-defined scope, perform functionality defined by requirements, and form part of a larger system.

Model components can enable:

Team-based development — Reduce file contention and elaborate components independently through well-defined interfaces.
Reduced design complexity — Each component solves smaller problems.
Component reuse — Reuse algorithms and environment models within a project and across multiple projects.
Unit testing — Eliminate retesting for unchanged components and reduce the cost of verification.
Performance benefits that scale — Reduce memory usage and the time required to load and simulate models.
Component variants — Choose among multiple implementations of a component.
Intellectual property protection — Limit functionality and content visibility for components that you share with third parties.

Should You Create Model Components?

Considering the work required to define and manage components, you should use component-based modeling only when the benefits outweigh the cost.

Separating an existing Simulink model into components is analogous to taking a large piece of code (C, Java^®, or MATLAB^® code) and breaking it down into multiple functions. The conversion can require significant effort and extensive modifications if the design is not modular from the beginning.

Considering model scalability and potential requirements upfront makes separating a Simulink model into components easier. Identifying components upfront can help you avoid these difficulties:

Poor component definition — The scope of subsystems that are grown over time can fail to meet component requirements. For example, they might contain too much or too little functionality to be reused, to generate code that integrates with legacy functionality, or to support hardware-in-the-loop tests.
Merge conflicts — If additional engineers begin to work on a model that was originally designed for development by a single engineer, they can encounter time-consuming and error-prone merges.
Algebraic loops — If a single engineer develops a model from the bottom up, they are likely to group blocks into subsystems as model complexity increases. The subsystems within the model are likely visual groupings that do not affect model execution. When you make these subsystems atomic, or convert them to referenced models, you can introduce unwanted algebraic loops that are difficult to diagnose and fix.

Components are also useful when a design becomes too complicated for one person to manage all of the details. For example, a complicated model can be a model that has:

Thousands of blocks
Hundreds of logical decisions
Multiple variant configurations of the same functionality

Projects and source control can help you manage components. For more information, see What Are Projects? and Configuration Management.

Define Model Components

1. Explore Types of Model Components	Identify Simulink components that align with your high-level modeling requirements.
2. Compare Capabilities of Model Components	Investigate which types of model components meet your low-level modeling requirements.
3. Define Interfaces of Model Components	Configure design attributes at interfaces and manage data for model components.