simulink-test-sequence-from-ears

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 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 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.