mcpbeat Sign in

Inject Faults Agent Skill

Add, configure, and manage faults on Simulink, Simscape, and System Composer model signals for robustness analysis and safety validation. Use when injecting faults (stuck, noise, gain, offset) onto block inports/outports, enabling fault simulation, or analyzing fault effects. Covers sensor failures, signal corruptions, actuator faults, FMEA validation, and robustness testing. Requires Simulink Fault Analyzer.

11k tokens
context cost
the whole folder, loaded on every use
8
files
instructions only
0
copies elsewhere
how many repositories repackaged it
900
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/matlab/simulink-agentic-toolkit --skill inject-faults

The instruction itself

13 sections, as written by the author

Fault Injection

Use evaluate_matlab_code with the Simulink.fault API to programmatically inject faults into Simulink models. Faults override signal values at block ports to simulate hardware failures, sensor faults, and actuator malfunctions.

When to Use

  • Injecting sensor stuck-at faults, noise, or bias for safety analysis (Simulink, Simscape, System Composer)
  • Validating FMEA failure modes through simulation
  • Testing controller robustness against actuator or sensor failures
  • Adding fault placeholders (without behavior) for FMEA traceability before defining fault logic
  • Configuring fault trigger conditions (timed, conditional, always-on)
  • Creating fault scenarios for automated testing
  • Comparing nominal vs. faulted behavior
  • Linking faults to FMEA failure mode cells
  • Generating fault specification reports
  • Exporting models with embedded fault behavior for teams without Simulink Fault Analyzer
  • Registering custom fault behavior libraries
  • Synchronizing (also called resync / sync / synchronize faults / update fault references) fault information from referenced models, subsystems, or linked libraries into a parent model

When NOT to Use

  • Creating FMEA spreadsheets or safety analysis documents -> use manage-safety-analysis
  • Building or editing model structure -> use building-simulink-models
  • Running standard (non-faulted) simulations -> use simulating-simulink-models
  • Writing pass/fail tests -> use testing-simulink-models

Probe

hasFA = ~isempty(which('Simulink.fault.addFault'));
fprintf('Simulink Fault Analyzer available: %d\n', hasFA);

Key Concepts

  • Fault: A modification applied to a block port (inport or outport) that overrides the signal value.
  • Fault without Behavior: A placeholder that documents a failure point but cannot be simulated.
  • Fault with Behavior: A fault with an associated behavior model that can be simulated (see references/fault-behaviors.md).
  • Fault Model: The .slx file containing fault behavior subsystem(s).
  • Trigger: When the fault activates (Always On, Timed, Conditional, Manual).
  • Fault Info File: <ModelName>_faultInfo.xml stores all fault metadata alongside the model.

Critical Constraints

  • Faults attach to block PORTS, not blocks. You must get the port handle via get_param(blockPath, 'PortHandles').
  • NEVER directly edit _faultInfo.xml files. Always use MATLAB APIs to modify fault definitions.
  • Fault names must be valid MATLAB identifiers (no spaces, slashes, or special characters). Use camelCase or PascalCase.
  • The fault behavior model name (first arg to addBehavior) must also be a valid MATLAB identifier.
  • NEVER use Simulink.fault.deleteAll or Simulink.fault.deleteFault to toggle faults on/off for simulation. Deleting faults destroys fault objects, their behavior models (.slx files), and their traceability links permanently. Use Simulink.fault.injection(model, false) to disable ALL fault injection for a nominal run, and Simulink.fault.injection(model, true) to re-enable. Use Simulink.fault.enable(modelElement, false) to disable faults on specific elements.
  • Not supported: Faults inside Stateflow charts, fault models, or observer models.

Workflow

  • Understand the model. Use model_overview and model_read to identify fragile signal paths -- single-point actuators, sensor feedback, computed quantities with wide fan-out.
  • Pre-flight check. Query compiled port properties to confirm signal compatibility. If the model is not already compiled, ask the user before compiling. See references/preflight-and-adding-faults.md.
  • Get port handles. Faults attach to port handles, not block paths. Use get_param(blk, 'PortHandles').
  • Add fault. Call Simulink.fault.addFault(portHandle, Name=..., Description=...). See references/preflight-and-adding-faults.md.
  • Add behavior. Call addBehavior(fault, modelName, FaultBehavior='mwfaultlib/...'). See references/fault-behaviors.md.
  • Configure trigger. Set fault.TriggerType and the corresponding properties (e.g., StartTime for Timed, Conditional for Conditional, TriggerActive for Manual). See references/triggers-and-conditionals.md.
  • Save. Call Simulink.fault.save('ModelName').
  • Simulate. Enable injection with Simulink.fault.injection(mdl, true) then sim(...). See references/simulation-workflows.md.

Guardrails

Always

  • Use model_read to identify target blocks before injecting faults
  • Check compiled port info before creating faults (see references/preflight-and-adding-faults.md)
  • Add behavior BEFORE setting trigger properties
  • Save with Simulink.fault.save('ModelName') after any fault changes
  • Verify fault is active before running faulted simulation with activate(fault)
  • Disable fault injection after analysis with Simulink.fault.injection(mdl, false)
  • Verify test input signals are non-zero at fault injection points
  • Check bus compatibility before choosing a mwfaultlib behavior

Never

  • Use the Simulink.fault.Fault() constructor -- use Simulink.fault.addFault() instead
  • Pass library block paths (e.g., mwfaultlib/Stuck-at-Ground) as the fault model name argument to addBehavior -- use the FaultBehavior name-value pair
  • Assume fault simulation is off -- verify before each nominal run
  • Violate any item in the Critical Constraints section

Ask First

  • Before modifying the design model for any reason (adding blocks, changing sample times, reconnecting signals)
  • Before enabling faults on a model that may be shared (it modifies model behavior)
  • Before deleting existing faults (the behavior model .slx is also deleted)
  • Before enabling fault.Persistent = true -- it makes the fault irreversible during simulation

Troubleshooting

| Issue | Cause | Fix |

|-------|-------|-----|

| Assertion failed in Simulink.fault.Fault() | Do not use the Fault() constructor directly | Use Simulink.fault.addFault(portHandle, Name=..., Description=...) instead |

| Fault name must follow MATLAB variable naming conventions | Name contains spaces or special chars | Use camelCase/PascalCase with no spaces (e.g., SensorStuckAtZero) |

| Invalid name for a fault model | Behavior model name has invalid characters | Use a simple MATLAB identifier (e.g., StuckAtZero, not Stuck-at-Zero) |

| Unable to add fault... only to block input or output ports | Passed a block path/handle instead of port handle | Use ph = get_param(blockPath, 'PortHandles'); ph.Outport(1) |

| Target signal is a continuous-time signal | Fault Analyzer cannot inject on continuous signals going to continuous blocks | See Continuous-Time Signal Decision Tree in references/advanced-operations.md |

| Output dimensions do not match or Data type mismatch | Fault constant size/type ≠ target signal | See "Vector and Matrix Fault Values" in references/fault-behaviors.md |

| Bus signal fault fails with non-Ground behavior | Most mwfaultlib behaviors are scalar-only | Use Stuck-at-Ground for full bus, or use BusElement to target individual elements |

| Multiple faults on same port but only one fires | Only one fault per port is active at a time | Use activate(fault) to select, or use different StartTime values |

| Fault exists but simulation runs nominally | Fault injection not enabled or fault not active | Call Simulink.fault.injection('Model', true) and activate(f) |

Reference Files

| File | Contents |

|------|----------|

| references/preflight-and-adding-faults.md | Port inspection, compile checks, adding faults, port handle resolution, fault object properties/methods |

| references/fault-behaviors.md | Built-in behaviors, custom behaviors, bus faults, vector/matrix faults, discovery, data inport source |

| references/triggers-and-conditionals.md | Trigger types, conditional creation, conditional/symbol object properties |

| references/simulation-workflows.md | Running simulations, nominal vs. faulted comparison, selective fault isolation |

| references/advanced-operations.md | FMEA linking, reports, export, deletion, continuous-time workarounds, synchronizing faults from referenced models/subsystems/libraries |

| references/test-case-integration.md | Adding fault sets to Simulink Test cases (R2024a+) |

----

Copyright 2026 The MathWorks, Inc.

----

Other skills for the same job

different authors, same section of the catalogue
Webapp Testing
by anthropics
vendor ×12

Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.

6k tokens scripts
Finishing A Development Branch
by ZhanlinCui
×7

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

1k tokens
Test Driven Development
by w95
×7

Use when implementing any feature or bugfix, before writing implementation code

2k tokens
Systematic Debugging
by ratacat
×7

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

10k tokens scripts
Verification Before Completion
by ZhanlinCui
×6

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

1k tokens
Backtest Expert
by BaggaT236
×3

Expert guidance for systematic backtesting of trading strategies. Use when developing, testing, stress-testing, or validating quantitative trading strategies. Covers "beating ideas to death" methodology, parameter robustness testing, slippage modeling, bias prevention, and interpreting backtest results. Applicable when user asks about backtesting, strategy validation, robustness testing, avoiding overfitting, or systematic trading development.

15k tokens scripts
Adaptyv
by christophacham
×3

Cloud laboratory platform for automated protein testing and validation. Use when designing proteins and needing experimental validation including binding assays, expression testing, thermostability measurements, enzyme activity assays, or protein sequence optimization. Also use for submitting experiments via API, tracking experiment status, downloading results, optimizing protein sequences for better expression using computational tools (NetSolP, SoluProt, SolubleMPNN, ESM), or managing protein design workflows with wet-lab validation.

16k tokens
Aeon
by christophacham
×3

This skill should be used for time series machine learning tasks including classification, regression, clustering, forecasting, anomaly detection, segmentation, and similarity search. Use when working with temporal data, sequential patterns, or time-indexed observations requiring specialized algorithms beyond standard ML approaches. Particularly suited for univariate and multivariate time series analysis with scikit-learn compatible APIs.

19k tokens

How to use it

Copy the folder

Take matlab/inject-faults from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.