Hello, everyone. Welcome to MAE Learning. In this article, we will go through different types of Subsystems are used in Simulink.

Different types of Subsystems

There are many types of subsystems in Simulink, and each is used for a different purpose. Subsystems help organize and simplify models by grouping blocks together.

Special Subsystem Blocks

Enabled Subsystem: Only runs when a certain input signal allows it.

An Enabled Subsystem in Simulink is a part of the model. It runs only when a specific input signal tells it to. This input signal is called the “enable” signal. If this signal is positive or “on,” the subsystem works; if it is zero or “off,” the subsystem stops working.

Points about Enabled Subsystem:

  • It runs only when the enable input signal is positive.
  • It pauses or stops when the enable signal is zero.
  • You can set what happens to the subsystem output when it is off. You can either keep the last value or reset it to the start value.
  • You can also decide if the subsystem “remembers” its state or resets when enabled again.
  • Enabled Subsystems can contain any blocks like continuous or discrete blocks.
  • They help model systems where some parts run only in certain conditions.

Example:

Imagine a water pump system that turns on only when the water level is low. The Enabled Subsystem will run the pump control only when the low water level signal is true (1). When water is enough (signal is 0), the subsystem stops the pump control.

Triggered Subsystem: Runs only when a trigger event happens, like a rising or falling signal.

Triggered Subsystem in Simulink runs only when a specific event, called a trigger, happens. This trigger can be a signal that rises (goes up), falls (goes down), or both.

Points to Understand Triggered Subsystem

  • It starts running only when the trigger signal changes in a particular way.
  • The trigger signal can be rising (going from low to high), falling (high to low), or either.
  • The output keeps its last value between triggers (it holds the output until triggered again).
  • It cannot reset its internal states when executed; any stored data stays until the next trigger.
  • Usually contains discrete blocks (blocks that operate in steps rather than continuously).

Example

  • Imagine a subsystem that records temperature only when a sensor signal rises from zero to a positive value. This subsystem will run and record temperature at each rising trigger.
  • In engine control, a triggered subsystem could simulate the ignition spark event. This simulation happens only when the crankshaft reaches a certain position, known as the trigger.
  • Another example is counting water overflow events in a tank, where the subsystem runs when an overflow signal rises.

Enabled and Triggered Subsystem: Needs both signal and trigger to work.

An Enabled and Triggered Subsystem in Simulink works only under two conditions. It receives a positive enable signal, like a “go” signal. It also gets a trigger event, like an “action” signal. Both signals must be active for the subsystem to run. If one is missing, the subsystem does not work.

Explanation Points:

  • The enable signal lets the subsystem know it is allowed to run (like an ON/OFF switch).
  • The trigger signal tells the subsystem exactly when to run (like pressing a button).
  • The subsystem runs only once when both signals agree to run.
  • It helps model systems that need both permission and a timed action to operate.

Example:

Imagine controlling a water tank:

  • The enable signal turns ON the water flow control.
  • The trigger signal acts when water level reaches a certain point.
    The subsystem runs only when the water system is enabled AND the water reaches the trigger level. Then actions like counting overflow events happen.

This type of subsystem is used to add extra control and safety checks to models.

Resettable Subsystem: Can restart its operations when a reset signal arrives.

Resettable Subsystem in Simulink is a special type of subsystem. It can restart its work when it receives a reset signal. This means it can return all the blocks inside it to their starting state whenever the reset signal comes. Here are some key points and an example to understand it better:

  • A resettable subsystem runs at every time step but resets its blocks only when the reset signal arrives.
  • It is useful when you want to restart the operations of several blocks inside the subsystem all at once.
  • Compared to resetting each block separately, using a resettable subsystem makes the model cleaner and easier to manage.
  • It can reset blocks that do not have their own reset controls.
  • Unlike an enabled subsystem that needs to be turned off before resetting, a resettable subsystem resets blocks instantly. It happens on the reset signal.

Example:
Imagine a subsystem that counts numbers using an integrator block (an element that adds numbers over time). If you send a reset signal, the counter will go back to 0 and start counting again from the beginning. This reset happens exactly when the reset signal is received without delays.

If Action Subsystem: Runs if a certain condition is true (like in “if-else” statements).

An If Action Subsystem is a special part of a Simulink model. It runs only when a certain condition is true. This is similar to “if” or “if-else” statements in programming.

Key Points:

  • It works with an “If” block that checks a condition.
  • If the condition is true, the subsystem runs.
  • If the condition is false, the subsystem does not run.
  • It helps to control which parts of the model run depending on signals.
  • It is useful to model decision-making in systems.

Example:

Imagine a simple temperature control system:

  • If the temperature is above 30 degrees, a cooling system turns on.
  • The “If” block checks if the temperature > 30.
  • If true, the If Action Subsystem that controls the cooler runs.
  • If false, the cooler stays off because the subsystem does not run.

Another example:

  • If a car is moving faster than 60 km/h, activate cruise control.
  • The If block checks speed > 60.
  • The If Action Subsystem starts managing the cruise control system only when the speed is higher.

This method keeps the model clear and efficient. It runs only the parts needed at any time. This approach saves power or processing time.

Function-Call Subsystem: Starts only when a function-call event happens.

Function-Call Subsystem in Simulink is a special type of subsystem. It starts its work only when it receives a function-call event. This means it does not run all the time but waits until something tells it to start.

Points to understand Function-Call Subsystem:

  • It runs only when a signal or block sends a “function-call” to it.
  • It is like a function in programming: called when needed, not continuously run.
  • The function-call event can come from another block, like a Stateflow chart, a function generator, or a special trigger block.
  • This type of subsystem helps control when parts of the model should do their work, improving order and efficiency.
  • It can have input and output ports like other subsystems.
  • If the subsystem has memory or states, there are settings available. These settings decide if the states keep their values when the function-call happens. Alternatively, the states may reset.

Example:

Suppose you have a model that calculates engine parameters only when the engine starts. Use a Function-Call Subsystem. This ensures the calculation block runs only when an engine start signal sends a function-call event. When the engine is off, this subsystem stays idle and does not waste computing time.

For Iterator Subsystem: Runs several times in one step, for a set number of repetitions (like “for loops”).

  • It runs the blocks inside it many times within a single simulation step.
  • The number of times it runs is set before or during the simulation.
  • This is similar to a “for loop” in programming, which repeats actions a fixed number of times.
  • It is beneficial for repeating the same operation multiple times. This can be done without enlarging or complicating your model.

Points to Know

  • The blocks inside the subsystem execute repeatedly.
  • The number of repetitions is controlled by a block called the For Iterator block inside the subsystem.
  • You can use inputs and outputs inside the subsystem, just like a normal system.
  • The system repeats until it reaches the set number of iterations.

Example

Imagine you want to add the number 10, twenty times:

  • Start with zero as the initial sum.
  • In each iteration of the For Iterator, add 10 to the sum.
  • After 20 repetitions, the result will be 200.

This is like writing a simple program:

sum = 0;

for i = 1 to 20

    sum = sum + 10;

end

But in Simulink, this is visual and uses blocks instead of text code. The For Iterator Subsystem lets you do this repeated task easily inside your model.

While Iterator Subsystem: Repeats as long as a condition is true (like “while loops”).

  • This subsystem repeats its part of the model as long as a condition stays true.
  • It works like a “while loop” in programming. If the condition is false, the loop (subsystem) stops running.
  • You set the starting point (initial condition) and the rule (condition) to check for each repeat.

How it Works:

  • At first, it checks if the initial condition is true. If yes, the subsystem runs once.
  • After that, it checks the condition signal; if it is still true, it runs again.
  • This repeats until the condition becomes false.

Simple Example:

Imagine a subsystem that adds 10 to a total number, starting from 0. The condition is to keep adding as long as the total is less than or equal to 100.

  • Start: total = 0
  • Add 10 → total = 10 (condition true, keep going)
  • Add 10 → total = 20 (condition true)
  • … Repeat until total becomes 100
  • When total > 100, condition is false, stop running

This subsystem keeps adding in steps until the rule (condition) says stop.

For Each Subsystem: Runs for each part of an input, one after another.

  • It runs the same set of blocks (inside the subsystem) for each part of the input one by one.
  • This means if the input has multiple elements, each one is handled separately but inside the same subsystem.
  • It helps when doing repeated calculations on different parts of data without making many copies of the system.
  • The output combines results after running for each part.

Simple Example

Imagine you have a signal with 3 numbers:. The For Each Subsystem will process 4 first. Then it will process 7 and then 2 using the same logic inside it. For example, it multiplies each by 2. So, the output will be.

Why Use It?

  • Makes models neat by avoiding many repeated blocks.
  • Useful for working on each part of input data separately.
  • Better for code reuse if the same task runs multiple times for different inputs.

Say you want to control temperature in 3 rooms with the same controller design. Instead of making 3 controllers, you use one For Each Subsystem. It runs the controller for each room separately, one after another.

Variant Subsystem: Holds many design options, and the active choice can change during simulation.

Variant Subsystem in Simulink is a special block that holds different design options inside it. Only one of these options is active during a simulation. You can easily switch the active one depending on conditions.

Points about Variant Subsystem:

  • It helps to have many designs or versions in one place without making the model complex.
  • You can create different subsystems inside the Variant Subsystem, each with its own design or algorithm.
  • The active design is chosen by simple rules or conditions during model running.
  • You can switch designs automatically based on variables or manually before running.
  • This is useful when you want to test or compare different methods quickly without making separate models.

Simple Example:

Imagine controlling the speed of a motor with two types of controllers. One type is a “simple PID controller,” and the other is an “advanced PID controller.” Instead of making two separate models, put both controllers inside a Variant Subsystem. Then, depending on a variable like “ControllerType”:

  • If ControllerType = 1, the simple PID runs.
  • If ControllerType = 2, the advanced PID runs.

During simulation, only one controller is active, but you can switch designs easily by changing the value of ControllerType.

How to Recognize Subsystems

  • Virtual subsystems have thin borders.
  • Nonvirtual (atomic) subsystems have thick borders.
  • Some subsystems (like mask or variant) may show special marks or allow switching options.

These types help to keep models neat and allow for complex logic without making things hard to read or understand.