Simulink Fault Analyzer for CPS FMEA

• Simulink Fault Analyzer is an industrial tool for simulation-driven FMEA that integrates fault logic into CPS models while maintaining separation from nominal design.
• It supports explicit fault modeling by defining failure modes, attaching triggers, and executing faulted simulations to compare outcomes with expert expectations.
• The tool’s structured workflow and quantitative analysis enhance safety assessments in complex systems, as demonstrated in e-bike motor controller studies.

Searching arXiv for the cited papers to ground the response. {"query":"arXiv (Bombarda et al., 19 Sep 2025) Simulink Fault Analyzer e-bike FMEA", "max_results": 5} {"query":"arXiv (Bartocci et al., 2019) CPSDebug Simulink Stateflow failure explanation", "max_results": 5} {"query":"arXiv (Samiullah et al., 2024) 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 (Bombarda et al., 19 Sep 2025).

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 (Bombarda et al., 19 Sep 2025).

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 (Bombarda et al., 19 Sep 2025).

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 (Bombarda et al., 19 Sep 2025).

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 (Bombarda et al., 19 Sep 2025).

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 (Bombarda et al., 19 Sep 2025).

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 (Bombarda et al., 19 Sep 2025).

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 (Bombarda et al., 19 Sep 2025).

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 (Bombarda et al., 19 Sep 2025).

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 (Bombarda et al., 19 Sep 2025).

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 (Bombarda et al., 19 Sep 2025).

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 (Bombarda et al., 19 Sep 2025).

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 (Bombarda et al., 19 Sep 2025).

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 (Bombarda et al., 19 Sep 2025).

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 (Bombarda et al., 19 Sep 2025).

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 (Bartocci et al., 2019).

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 (Fabarisov et al., 2021).

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 (Samiullah et al., 2024). "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 (Wang et al., 2013).

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.