---
title: Simulink Fault Analyzer for CPS FMEA
url: https://www.emergentmind.com/topics/simulink-fault-analyzer
type: topic
---

# Simulink Fault Analyzer for CPS FMEA

Searching arXiv for the cited papers to ground the response.
{"query":"arXiv 2509.15893 Simulink Fault Analyzer e-bike FMEA", "max_results": 5}
{"query":"arXiv 1903.12468 CPSDebug Simulink Stateflow failure explanation", "max_results": 5}
{"query":"arXiv 2401.15417 MATLAB Simulink induction motor fault diagnosis", "max_results": 5}
Simulink Fault Analyzer is an industrial tool that supports engineers with simulation-driven Functional Failure Mode and Effects Analysis (FMEA) on Cyber-Physical Systems. In the reported e-bike study, it was used to define faults on signals/components, attach triggers, execute faulted simulations, and inspect whether a fault leads to unsafe behavior such as overspeed, abnormal currents, controller saturation, or system stop. Its defining characteristic in that study is that fault logic is integrated into the model while remaining separate from nominal design logic, so the tool functions as support for both Failure Mode modeling (FM) and Effect Analysis (EA), rather than as a generic perturbation mechanism alone [2509.15893].

## 1. Functional role in simulation-driven FMEA

In the e-bike domain experience report, Simulink Fault Analyzer supported two FMEA activities: **Failure Mode modeling (FM)** and **Effect Analysis (EA)**. FM consisted of defining faults on signals/components in the e-bike model. EA consisted of simulating the model with faults enabled and observing the resulting system behavior. The study emphasizes that the tool integrates fault logic into the model in a way that keeps fault behavior separate from nominal design logic; this separation matters because it prevents the fault logic from accidentally becoming part of the model itself [2509.15893].

The same study explicitly distinguishes the tool from a narrow notion of fault injection. Simulink Fault Analyzer was the mechanism used to define failure modes, attach triggers, execute faulted simulations, and inspect the resulting effects. In that workflow, the objective was not only to perturb a model, but to compare observed behavior with domain-engineer expectations and thereby support safety analysis. This suggests a broader operational definition: the tool acts as an FMEA-oriented simulation layer over a Simulink/Simscape model, where failure semantics, activation conditions, and observed consequences are organized as analyzable artifacts rather than embedded ad hoc in controller logic.

A common misconception is to treat Simulink Fault Analyzer as if it were interchangeable with any Simulink fault-injection block or debugging utility. The reported usage does not support that equivalence. The tool was used in a structured safety-analysis process involving realistic fault selection, expert review of fault semantics, and systematic comparison of expected versus simulated effects. In that sense, it occupies a specific methodological niche within model-based safety engineering.

## 2. Fault behaviors, triggers, and persistence semantics

The e-bike study reports a finite set of fault behaviors and trigger types available in Simulink Fault Analyzer. The modeling pattern was to choose a fault behavior, attach it to a signal or component, and choose a trigger to activate it. Faults are graphically marked with a lightning symbol [2509.15893].

| Type | Name | Description |
|---|---|---|
| Fault behavior | Add Noise | Adds random noise to the signal. |
| Fault behavior | Negate Value | Negates the value of a signal. |
| Fault behavior | Absolute Value | Transforms the signal into its absolute value. |
| Fault behavior | Stuck-at-Ground | Sets the signal to the ground. |
| Fault behavior | Gain | Adds a gain to the signal. |
| Fault behavior | Offset-by-1 | Adds an offset to the input signal. |
| Fault behavior | Unit Delay | Delays the signal by a single time unit. |
| Fault behavior | Stuck-at-Constant | Sets the signal to a constant value. |
| Trigger type | Conditional | Activates a fault when a specific condition, on any of the signals or measures available in the model, is satisfied. |
| Trigger type | Timed | Activates a fault after the specified simulation time. |
| Trigger type | Manual | Activates a fault manually during the simulation by clicking on a button. |

A central modeling nuance in the report concerns event persistence. A conditional trigger normally turns the fault on only while the condition holds, but some real faults should persist after activation. For such cases, the tool provides the flag **“Trigger stays on once activated”**. The authors initially missed this and then corrected their model. The correction was especially important for event-like faults such as a sensor breakage that should remain active after it first occurs [2509.15893].

This persistence issue is methodologically significant because it separates transient-condition semantics from failure-latching semantics. A conditional predicate can denote the moment of occurrence, whereas the physical failure mode may require continued effect after that moment. The study treats this as a practical lesson rather than a theoretical limitation, but it is directly relevant to the fidelity of fault models.

## 3. Industrial workflow on an e-bike motor controller

The industrial case study used a realistic CPS model: an e-bike controller model developed in a project context involving industrial partners. The model includes **Environment**, **BLDC Motor**, **Sensor**, **Battery**, **Three-Phase Inverter**, **Commutation Logic**, **Buck Converter**, and **(Software) Controller**. The controller regulates speed by setting duty cycles so that measured speed matches the desired speed [2509.15893].

The workflow reported in the study proceeded in seven steps. First, the authors selected the e-bike CPS model. Second, two authors initially identified **15 faults** spanning sensor, controller, and inverter-related issues. Third, these candidate faults were filtered for realism through a structured interview with the e-bike controller designer, who scored each fault for **plausibility**, **frequency**, and **criticality**; a fault was considered plausible/frequent/critical if the score was **≥ 3**. Two faults, **F3** and **F8**, were excluded because they were judged non-realistic on all three dimensions, leaving **13 realistic faults**. Fourth, the faults were modeled in Simulink Fault Analyzer using one of the tool’s fault behaviors and one or more trigger types. Fifth, the expert reviewed whether the modeled fault behavior and trigger matched the intended semantics, and minor inaccuracies were corrected. Sixth, the authors ran faulted simulations and compared simulated effects with expert expectations. Seventh, they discussed results and lessons learned with MathWorks experts [2509.15893].

The benchmark retained the following 13 realistic faults: **F1 Breakage of the speed sensor**, **F2 Noisy speed sensor**, **F4 Delayed speed sensor**, **F5 Speed sensor with constant value**, **F6 Breakage of the sector sensor**, **F7 Noisy sector sensor**, **F9 Delayed sector sensor**, **F10 Sector sensor with constant value**, **F11 PID controller design error**, **F12 Noise on the output of the PID**, **F13 Amplification of the output of the PID**, **F14 Inverted PID output**, and **F15 Constant output of the PID**. Among the initial fault set, the study reports that the majority were **66% plausible**, **74% critical**, and **74% not frequent** [2509.15893].

The reported modeling choices were semantically aligned with intended failure modes. Sensor breakage was modeled using **Stuck-at-Ground**; noisy sensor faults using **Add Noise**; delay faults using **Unit Delay**; constant sensor faults using **Stuck-at-Constant**; and PID design problems using **Stuck-at-Ground**, **Add Noise**, **Gain**, **Negate Value**, or **Stuck-at-Constant**, depending on the intended defect. For several faults, both **Timed** and **Conditional** triggers were considered, and the domain expert selected the semantically correct activation pattern [2509.15893].

## 4. Effect analysis and safety-relevant behavior

The effect-analysis phase compared simulated behavior with expert expectations. The expert had described anticipated effects such as higher duty cycle, longer regulation time, oscillatory phase currents, motor stopping, acceleration beyond the legal limit, and inverter/sensor-driven system shutdown. The study gives concrete examples: **F5** was expected to cause the PID to increase duty cycle, causing actual speed higher than desired; **F10** was expected to yield very high phase currents, then slowing and stopping; **F12** was expected to make phase currents oscillate; and **F15** was expected to cause acceleration until equilibrium or fault deactivation [2509.15893].

Some observed behaviors were explicitly safety-relevant. The report points out that certain faults caused speed exceeding the legal limit of **25 km/h**, aggressive oscillations, uncontrolled acceleration or deceleration, motor stopping unexpectedly, and invalid sector values causing simulation abortion. One concrete example is the fault **Constant_PID**, which could push the vehicle above the legal speed limit; the study notes that **25 km/h** corresponds to about **170 rpm wheel speed** for a 28-inch wheel [2509.15893].

The paper’s most informative mismatches occurred when simulation outcomes did not conform to expert expectations. In **F7: noisy sector sensor**, the expert expected extremely high currents and the motor eventually stopping. Instead, the simulation stopped with an error message because the sector signal became **0**, which is outside the allowed range **[1–6]**. The reported interpretation is that this revealed a modeling bug in the three-phase inverter / sector handling: the system did not gracefully handle invalid sector values, and the model lacked a realistic emergency-stop or safe fallback behavior. The paper explicitly states that in a real system the correct response should be a controlled emergency stop and deceleration, rather than simulation failure [2509.15893].

Additional mismatches in **F10**, **F12**, **F13**, and **F15** also exposed unanticipated dynamics. These included very high phase currents and aggressive control after fault deactivation, slight but constant oscillations in phase currents, significant oscillations in PID output not anticipated by the expert, and duty cycle saturation at 1 followed by a drop to 0, causing alternating very high and very low speeds and currents. The report interprets these discrepancies as evidence that simulation-driven FMEA can uncover effects that engineers overlooked or did not expect [2509.15893].

## 5. Accuracy of fault models, mismatch analysis, and lessons learned

The expert review phase produced a quantitative assessment of fault-model adequacy. For **RQ1**, the study reports that **53.8% (7/13)** of the fault models were directly correct, while **46.2% (6/13)** were correct except for minor imprecision, which the authors fixed after expert feedback. The result is interpreted as showing that Simulink Fault Analyzer was capable of expressing all 13 realistic faults, but that domain knowledge remained necessary to choose the right trigger semantics and remove small modeling mistakes [2509.15893].

The effect-analysis phase likewise produced a quantitative comparison against expectations. The study reports that **61.6% (8/13)** of faults matched expert expectations, whereas **38.4% (5/13)** did **not** match expectations. The paper treats this as a central finding: simulation did not merely confirm prior beliefs, but exposed gaps between the engineers’ mental model and the actual model behavior. The authors further state that FMEA helps engineers improve their models, and that the output provided by the simulation-driven support for **38.4% (5 out of 13)** of the faults did not match the engineers' expectations, helping them discover unexpected effects of the faults [2509.15893].

The report derives **10 lessons learned**, split into tool-specific and tool-agnostic categories. Tool-specific lessons include: **triggers matter**; **faults are usually applied to components, not signals**; **multiple faults on the same signal are awkward**; **the same fault may need to be applied to multiple signals**; and **Accelerator mode is not supported**. On the last point, the authors estimated about **30 seconds saved per simulation** if accelerator mode were available. Tool-agnostic lessons include: **explicit fault modeling improves reasoning**; **fault simulation enables systematic safety analysis**; **fault analysis supports mitigation design**; **safety mindset is essential**; and **e-bike development must treat software as central** [2509.15893].

These findings also delimit the practical scope of the tool. The main limitations observed were that some fault scenarios required workarounds, faults are typically attached to components rather than arbitrary signals, multiple simultaneous faults on the same signal are not straightforward, a fault affecting multiple signals required extra modeling infrastructure, and lack of accelerator-mode support reduced simulation efficiency. The study therefore portrays Simulink Fault Analyzer as powerful but not frictionless for industrial-scale, realistic CPS fault analysis.

## 6. Relation to adjacent Simulink fault-analysis research

Simulink Fault Analyzer belongs to a broader ecosystem of Simulink-based methods for diagnosis, debugging, verification, and fault injection, but the adjacent literature addresses different technical objectives. **"Automatic Failure Explanation in CPS Models"** presents **CPSDebug**, an automatic failure explanation and fault localization approach for Simulink/Stateflow models. Its pipeline combines testing, specification mining, and failure analysis to explain not only that a model failed, but also why it failed, where the likely fault is, and what evidence supports that conclusion. The output is a ranked set of suspicious locations and supporting evidence from the trace, which is conceptually related to fault analysis but distinct from FMEA-oriented fault modeling and effect simulation [1903.12468].

A different line of work focuses on embedded fault injection rather than FMEA workflow support. **"Model-based Fault Injection Experiments for the Safety Analysis of Exoskeleton System"** introduces **FIBlock**, a highly customizable Simulink block for injecting typical faults of heterogeneous CPS components, including sensors, computing hardware, and network. FIBlock supports configurable fault type, fault activation time, and fault exposure duration, as well as conditional and chained faults. This makes it a flexible model-based fault injection tool, whereas the e-bike study positions Simulink Fault Analyzer as industrial support for FM and EA within simulation-driven FMEA [2101.01283].

Other research emphasizes detection or formal assurance rather than FMEA orchestration. **"Fault Diagnosis on Induction Motor using Machine Learning and Signal Processing"** describes a complete Simulink-to-machine-learning pipeline in which MATLAB Simulink is the physics-based data generator, Fast Fourier Transform provides discriminative features, and a Decision Tree achieves about **92%** accuracy on the test set; the paper states that the resulting workflow can be understood as a practical “Fault Analyzer” for industrial induction motors [2401.15417]. **"Credible Autocoding of Fault Detection Observers"** instead starts from a fault detector model expressed in a synchronous modeling environment such as Simulink and generates both code and analyzable annotations, using ellipsoidal quadratic invariants to verify safety and correctness properties such as boundedness of states and absence of false alarms [1311.2064].

This broader context clarifies what Simulink Fault Analyzer is and is not. It is not, in the reported industrial usage, a general-purpose specification miner, a ranked fault-localization engine, an observer-verification framework, or a machine-learning diagnosis pipeline. Its documented role is narrower and more operational: explicit fault modeling, triggered activation, simulation of faulty behavior, and comparison of simulated effects with safety expectations inside an FMEA workflow. A plausible implication is that these strands are complementary rather than competing: failure explanation, fault injection, formal verification, and FMEA-oriented effect analysis address different points in the lifecycle of model-based CPS engineering.

Source: https://www.emergentmind.com/topics/simulink-fault-analyzer