Referenced models in Simulink - Deep Dive

Overview - Referenced models

What is it?

Referenced models in Simulink are separate model files that you can include inside a main model. They let you reuse parts of a system without copying the whole design. This helps keep models organized and makes it easier to update shared components. Think of them as building blocks you can plug into bigger projects.

Why it matters

Without referenced models, you would have to duplicate the same system parts in many places. This wastes time and causes errors when you update one copy but forget others. Referenced models solve this by letting you maintain one version that all projects use. This saves effort, reduces mistakes, and helps teams work together smoothly.

Where it fits

Before learning referenced models, you should understand basic Simulink modeling and how to build simple systems. After mastering referenced models, you can explore model hierarchy, variant models, and model referencing for code generation and simulation acceleration.

Mental Model

Core Idea

Referenced models are like reusable Lego blocks that you build once and then plug into many larger models to save time and keep designs consistent.

Think of it like...

Imagine building a city with Lego. Instead of building every house from scratch, you create a few house designs and reuse them throughout the city. If you want to change a house style, you update the design once, and all houses change automatically.

Main Model
  ├─ Reference Model A (separate file)
  ├─ Reference Model B (separate file)
  └─ Other blocks

Each Reference Model is a self-contained unit plugged into the main model.

Build-Up - 7 Steps

1

Foundation

What is a referenced model

Concept: Introduces the idea of a referenced model as a separate Simulink file used inside another model.

A referenced model is a Simulink model saved as its own file. Instead of copying its blocks into a big model, you insert a reference to it. This means the main model uses the referenced model as a black box, showing only its input and output connections.

Result

You can see the referenced model inside the main model as a single block. Changes to the referenced model file affect all main models that use it.

Understanding referenced models as separate files helps you organize complex systems and avoid duplication.

2

Foundation

Creating and adding referenced models

Concept: How to create a referenced model and add it to a main model in Simulink.

First, build a small model and save it as a separate file. Then, in your main model, use the Model block to insert this file as a reference. Connect inputs and outputs as needed. Simulink treats this block as a window into the referenced model.

Result

The main model now includes the referenced model block, which behaves like the original model but is managed separately.

Knowing how to add referenced models lets you build modular systems that are easier to manage.

3

Intermediate

Benefits of referenced models

🤔Before reading on: Do you think referenced models only save disk space or also improve collaboration? Commit to your answer.

Concept: Explains the advantages of referenced models beyond reuse, including collaboration and simulation speed.

Referenced models allow multiple engineers to work on different parts of a system independently. They also enable faster simulation because Simulink can simulate referenced models separately and reuse results. Plus, updating one referenced model updates all main models that use it.

Result

Teams can work in parallel, simulations run faster, and maintenance is simpler.

Understanding these benefits shows why referenced models are essential for large projects and teamwork.

4

Intermediate

Parameterizing referenced models

🤔Before reading on: Can you change parameters inside a referenced model from the main model? Guess yes or no.

Concept: Shows how to customize referenced models by passing parameters from the main model.

You can define parameters in the referenced model and override them from the main model using Model block parameters or variant configurations. This lets you reuse the same model with different settings without changing the referenced model file.

Result

One referenced model can behave differently depending on the parameters set in each main model instance.

Knowing parameterization unlocks flexible reuse and reduces the need for multiple similar models.

5

Intermediate

Managing data and signal interfaces

Concept: How inputs, outputs, and data are handled between main and referenced models.

Referenced models have defined input and output ports. Signals and data must match these ports. You can use Inport and Outport blocks inside the referenced model to define interfaces. Data dictionaries can also manage shared data between models.

Result

Clear interfaces ensure referenced models connect correctly and data flows properly during simulation.

Understanding interfaces prevents connection errors and supports modular design.

6

Advanced

Simulation and code generation with referenced models

🤔Before reading on: Do you think referenced models slow down or speed up code generation? Choose one.

Concept: Explains how referenced models affect simulation speed and code generation workflows.

Simulink can simulate referenced models separately, which can speed up simulations by reusing results. For code generation, referenced models can generate separate code units, enabling modular code and easier integration into larger software projects.

Result

Simulation becomes more efficient, and generated code is modular and maintainable.

Knowing this helps optimize performance and software architecture in real projects.

7

Expert

Advanced referencing: Model referencing vs Model linking

🤔Before reading on: Do you think model referencing and model linking are the same? Commit to yes or no.

Concept: Distinguishes between model referencing and model linking, two ways to reuse models with different trade-offs.

Model referencing uses separate model files linked by Model blocks, supporting independent simulation and code generation. Model linking embeds a model inside another but keeps a link to the original file, mainly for editing convenience. Referencing is better for large projects and code generation; linking is simpler but less powerful.

Result

Choosing the right method affects project scalability, simulation speed, and code modularity.

Understanding these differences prevents misuse and helps design scalable, maintainable systems.

Under the Hood

When you add a referenced model block, Simulink loads the referenced model file separately. During simulation, Simulink treats the referenced model as a separate simulation unit with its own solver and workspace. Data and signals pass through defined interfaces. For code generation, Simulink generates separate code files for each referenced model, which can be compiled independently and linked later.

Why designed this way?

Referenced models were designed to handle complexity and team collaboration in large systems. By separating models into files, engineers can work independently and avoid conflicts. The separate simulation units improve performance by enabling parallel or incremental simulation. Modular code generation supports integration into larger software projects and reuse of components.

Main Model
┌─────────────────────┐
│                     │
│  ┌───────────────┐  │
│  │ Referenced    │  │
│  │ Model A       │  │
│  └───────────────┘  │
│                     │
│  ┌───────────────┐  │
│  │ Referenced    │  │
│  │ Model B       │  │
│  └───────────────┘  │
│                     │
└─────────────────────┘

Simulation Engine
┌───────────────┐  ┌───────────────┐
│ Simulate      │  │ Simulate      │
│ Model A       │  │ Model B       │
└───────────────┘  └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does changing a referenced model inside the main model change the original file? Commit yes or no.

Common Belief: Many think editing a referenced model block inside the main model changes the original referenced model file automatically.

Reality: Editing a referenced model block opens the referenced model file separately. Changes only save to the original file if explicitly saved. The main model block is just a link, not a copy.

Why it matters: Assuming automatic changes can cause confusion and lost work if edits are not saved properly.

Quick: Do you think referenced models always speed up simulation? Commit yes or no.

Common Belief: Some believe referenced models always make simulations faster.

Reality: Referenced models can speed up simulation by enabling separate execution, but if the referenced model is small or tightly coupled, overhead may slow simulation.

Why it matters: Misusing referenced models expecting speed gains can lead to worse performance.

Quick: Can you pass parameters directly into a referenced model without setup? Commit yes or no.

Common Belief: People often think you can change any parameter inside a referenced model from the main model without configuration.

Reality: Parameters must be explicitly set up for override or passed via model arguments; otherwise, referenced models use their own internal parameters.

Why it matters: Incorrect assumptions cause parameter mismatches and unexpected simulation results.

Quick: Is model linking the same as model referencing? Commit yes or no.

Common Belief: Many assume model linking and model referencing are identical ways to reuse models.

Reality: Model linking embeds a model for editing convenience but does not support separate simulation or code generation like model referencing.

Why it matters: Confusing these leads to wrong choices for large projects and code reuse.

Expert Zone

1

Referenced models can have their own solver settings, allowing different parts of a system to use different simulation methods.

2

Using data dictionaries with referenced models enables centralized data management across multiple models and teams.

3

Model referencing supports incremental builds and simulation caching, which can drastically reduce simulation time in large projects.

When NOT to use

Avoid referenced models for very small or simple systems where the overhead of separate files and simulation units outweighs benefits. Instead, use normal subsystems or model linking. Also, if you need tight coupling or shared internal states, referenced models may be too isolated.

Production Patterns

In industry, referenced models are used to separate software components by teams, enable modular code generation for embedded systems, and manage large automotive or aerospace models with hundreds of engineers working in parallel.

Connections

Modular programming

Referenced models apply the same principle of modularity by breaking systems into reusable parts.

Understanding modular programming helps grasp why referenced models improve maintainability and collaboration.

Object-oriented design

Referenced models resemble objects encapsulating behavior and data, promoting reuse and abstraction.

Knowing object-oriented design clarifies how referenced models hide complexity and expose interfaces.

Microservices architecture

Both referenced models and microservices break large systems into independent units that communicate via defined interfaces.

Seeing this connection helps appreciate how system decomposition aids scalability and team workflows across domains.

Common Pitfalls

#1 Editing a referenced model block directly without saving changes to the referenced file.

Wrong approach:

Open referenced model block in main model, make changes, close without saving.

Correct approach:

Open referenced model file separately, make changes, save file explicitly.

Root cause:

Misunderstanding that the block is a link, not a copy, so changes must be saved in the referenced file.

#2 Passing parameters to referenced models without configuring parameter overrides.

Wrong approach:

Set parameters in main model workspace expecting referenced model to use them automatically.

Correct approach:

Configure Model block parameters or use variant subsystems to pass parameters explicitly.

Root cause:

Assuming parameter scope is shared between main and referenced models without setup.

#3 Using referenced models for very small components causing simulation overhead.

Wrong approach:

Reference tiny models unnecessarily, leading to slower simulation.

Correct approach:

Use normal subsystems for small parts and reserve referencing for larger reusable components.

Root cause:

Not considering simulation overhead and complexity trade-offs.

Key Takeaways

Referenced models let you reuse Simulink models as separate files inside bigger models, improving organization and collaboration.

They enable teams to work independently on parts of a system and simplify updates by maintaining one source of truth.

Parameterizing referenced models allows flexible reuse with different settings without duplicating files.

Simulation and code generation benefit from modularity, speeding up workflows and producing maintainable code.

Understanding the difference between model referencing and linking is crucial for choosing the right reuse strategy.

Practice

1. What is the main purpose of using Referenced models in Simulink?

easy

A. To reuse parts of models and simplify large projects

B. To create new Simulink blocks from scratch

C. To export models as images

D. To run simulations faster by skipping blocks

Solution

1. Step 1: Understand the role of referenced models

   Referenced models allow you to include one model inside another, making reuse possible.

2. Step 2: Connect reuse to project management

   By reusing parts, you keep big projects organized and easier to update.

3. Final Answer:

   To reuse parts of models and simplify large projects -> Option A

4. Quick Check:

   Referenced models = reuse and simplify [OK]

Hint: Think reuse and organization for big Simulink projects [OK]

Common Mistakes:

• Confusing referenced models with creating new blocks
• Thinking referenced models speed up simulation by skipping
• Assuming referenced models export images

2. Which of the following is the correct way to add a referenced model in Simulink?

easy

A. Drag a Model block and set its Model name parameter to the referenced model file

B. Use the MATLAB command add_block('model') without parameters

C. Copy and paste the entire model into the current model

D. Create a new subsystem and name it after the referenced model

Solution

1. Step 1: Recall how to include referenced models

   Simulink uses Model blocks to include referenced models by specifying the model file name.

2. Step 2: Check options for correctness

   Drag a Model block and set its Model name parameter to the referenced model file correctly describes dragging a Model block and setting its Model name parameter.

3. Final Answer:

   Drag a Model block and set its Model name parameter to the referenced model file -> Option A

4. Quick Check:

   Model block + Model name = referenced model [OK]

Hint: Use Model block and set model name to reference [OK]

Common Mistakes:

• Using add_block without parameters causes errors
• Copy-pasting duplicates instead of referencing
• Naming subsystems does not create references

3. Given a Simulink model with a Model block referencing subsystemA, what happens if subsystemA is updated externally and saved before simulation?

medium

A. Simulation fails with an error about missing blocks

B. The main model ignores changes and uses the old version

C. The main model uses the updated subsystemA during simulation

D. The referenced model is duplicated inside the main model automatically

Solution

1. Step 1: Understand referenced model behavior on update

   Referenced models reflect changes made externally when saved before simulation.

2. Step 2: Analyze simulation effect

   The main model uses the latest saved version of the referenced model during simulation.

3. Final Answer:

   The main model uses the updated subsystemA during simulation -> Option C

4. Quick Check:

   Referenced models update = main model uses latest [OK]

Hint: Referenced models always use saved latest version at simulation [OK]

Common Mistakes:

• Assuming main model caches old referenced model version
• Thinking simulation fails if referenced model changes
• Believing referenced models duplicate automatically

4. You added a referenced model block but get an error: Model file not found. What is the most likely cause?

medium

A. The simulation time is set to zero

B. The referenced model file path is incorrect or missing

C. The referenced model has no input ports

D. The main model is not saved

Solution

1. Step 1: Identify cause of 'Model file not found'

   This error usually means Simulink cannot locate the referenced model file due to wrong or missing path.

2. Step 2: Check other options for relevance

   Saving main model, input ports, or simulation time do not cause this error.

3. Final Answer:

   The referenced model file path is incorrect or missing -> Option B

4. Quick Check:

   File not found = wrong or missing path [OK]

Hint: Check referenced model file path if 'not found' error appears [OK]

Common Mistakes:

• Ignoring file path issues
• Blaming simulation time or ports incorrectly
• Not saving main model but error is unrelated

5. You want to create a large Simulink project with multiple teams working on different parts. How do referenced models help in this scenario?

hard

A. Referenced models run simulations independently without integration

B. Referenced models automatically merge all team changes into one file

C. Referenced models prevent any changes once included in the main model

D. Each team works on separate referenced models that are included in the main model, easing collaboration

Solution

1. Step 1: Understand team collaboration with referenced models

   Referenced models allow teams to work on separate model files independently.

2. Step 2: Connect referenced models to main model integration

   The main model includes these referenced models, making integration easier and organized.

3. Final Answer:

   Each team works on separate referenced models that are included in the main model, easing collaboration -> Option D

4. Quick Check:

   Referenced models = team collaboration and modular design [OK]

Hint: Use referenced models for modular teamwork in big projects [OK]

Common Mistakes:

• Thinking referenced models merge files automatically
• Assuming referenced models lock changes
• Believing referenced models simulate independently without integration