/simulink-test-sequence-from-ears

name: simulink-test-sequence-from-ears
description: Generate Simulink Test Sequence blocks and harnesses from EARS requirements. Use when asked to create a test case from a requirement, generate tests from a .slreqx file, or verify a Simulink model with requirement-based tests.
license: MathWorks license (see LICENSE.md)
compatibility: Requires MATLAB, Simulink, Simulink Test, and Requirements Toolbox. Stateflow is needed for chart discovery and the ModeLogic demo. The supplied example targets R2026a or newer.
metadata:
  author: MathWorks
  version: "1.0"

Simulink Test Sequences from EARS Requirements

Map requirement phrases to model signals, review the mappings, and generate Test Sequence harnesses with the bundled MATLAB helpers.

Core rules

• Start with a YAML mapping review. Use an existing explicit approval when

available; do not infer approval from a filename or from a mapping appearing obvious.

• Scope the review and generation to the requested requirement IDs.
• Resolve open questions about signals, units, enum values, precondition paths,

and timing before generating tests. Include complete initialization, stimulus, and `verify()` statements.

• Associated harness creation saves registration metadata on the owner model.

Use a writable working copy for demos. Explain this effect when preparing generation against a user's model.

• Inspect per-requirement warnings and compile results. The generator can

continue after a harness fails; the final completion message and presence of a `.slx` file do not establish success.

• Compilation is not test execution. Run the generated test when requested,

and distinguish a compile check from simulation and assertion results.

Setup and inputs

Identify the model under test, the `.slreqx` requirement set, and any `.sldd` dictionaries or enumeration classes. Resolve the folder containing this file as `skillRoot`, then add `fullfile(skillRoot, "scripts")` to the MATLAB path.

Run MATLAB from the model artifacts folder (or set the evaluation tool's working-folder option). Discovery scans that folder for dictionaries and enum classes. Verify `which("analyzeRequirements")` resolves to this installation. The older `analizeRequirements` spelling remains a compatibility alias.

Phase 1: Review the mappings

Use `analyzeRequirements(modelName, reqSetPath)` for requirement and model discovery. For a review of selected requirements:

review = generateMappingReviewFromRequirements( ...
    'ModeLogic', 'HLR_ModeLogic_EARS.slreqx', ...
    'mapping_review_req17.yaml', 'RequirementIds', "17");

Read [workflow-details.md](references/workflow-details.md) when constructing or editing the YAML. Lead with `phrase_mappings` containing the requirement phrase, model element, and interpretation. Keep generation fields in the same file: `init_assignments`, `precondition_path`, `stimulus_assignments`, and `verify_statements`.

Record assumptions in `test_assumptions`, unresolved meanings in `open_questions`, and approval in `status`. Show the final review file in the MATLAB Editor when available, unless the user requests otherwise. For headless operation or intermediate files, pass `'OpenInEditor', false`.

Present a short mapping summary and request review when approval is missing. After the user approves, set the accepted entries to `status: 'approved'`. Edits with unresolved questions do not constitute approval.

Phase 2: Generate and inspect

result = buildHarnessesFromApprovedYaml( ...
    'ModeLogic', 'mapping_review_req17.yaml');

The default creates externally saved harnesses in `test_harnesses/` and registers them on the source model. If the requested output is standalone harness files, the staged alternative is:

result = buildHarnessesFromApprovedYaml( ...
    'ModeLogic', 'mapping_review_req17.yaml', ...
    'AssociateWithSourceModel', false);

That alternative generates in a temporary workspace and copies harness files back; it does not register them on the source model. Inspect the reported build folder when troubleshooting dictionary or model shadowing.

Open the generated harness and relevant `result.test_sequence_blocks` when a desktop session is available and the user has not requested headless work. Use the returned paths to inspect the Test Sequence. Do not recreate the bundled helpers.

Supported patterns and limits

| EARS pattern | Form | Generated steps | |---|---|---| | Ubiquitous | The system shall ... | Initialize and verify | | Event-driven | When ..., the system shall ... | Establish preconditions, trigger, verify | | State-driven | While ..., the system shall ... | Establish the state and check behavior | | Unwanted behavior | If ..., then the system shall ... | Apply the condition and check the response | | Optional | Where ..., the system shall ... | Use the event-driven configurator |

The parser recognizes these sentence forms; arbitrary natural-language requirements may need clarification. Automated phrase and precondition inference includes ModeLogic-specific heuristics, so review mappings against the actual system. The bundled timing defaults and one scenario per requirement do not establish exhaustive verification.

Requirements Toolbox traceability links must be added separately through Simulink Test Manager. Do not claim certification, standards compliance, or complete requirement coverage from generated harnesses.

Supporting functions

[Workflow details](references/workflow-details.md) includes the YAML schema, a ModeLogic example, the low-level `signalMappings` struct, and the helper catalog. Use it for custom mappings and multi-step preconditions.

Copyright 2026 The MathWorks, Inc.