simulink-manage-variant-configuration

---

name: simulink-manage-variant-configuration description: > Manage Simulink Variant Manager and Variant Configurations workflows — examine, list, and explore variant configurations, variant control variables, and variant model structure; create, modify, and delete variant configurations; validate variant constraints; generate valid variant configurations; apply, activate, or update models with variant configurations; compare variant configurations and analyze which blocks are active or different; open or close the Variant Manager UI; set up non-intrusive variant configuration specific simulation and testing with variant configurations; show/hide variant control variable usage. Use when working with variant configurations, variant manager, VCS objects (VariantConfigurationData / VariantConfigurations), variant control variables, preferred configuration, activation of variant choices, or reducing a variant model to selected variant configurations. license: https://www.mathworks.com/content/dam/mathworks/license/pmrl/license.md metadata: author: MathWorks version: "1.0"

When to Use

• Examining, listing, or exploring variant configurations, control variables, or variant structure of a Simulink model
• Creating, modifying, or deleting variant configurations
• Validating variant configurations against constraints
• Generating valid valid configurations automatically
• Applying, activating, or updating a model with a variant configuration
• Comparing or analysing different variant configurations — which blocks are active, which differ, which are always active
• Reducing a variant model to lock down specific designs i.e a model free from variants as much as possible (reduceModel)
• Setting up non-intrusive simulation with variant configurations
• Setting up non-intrusive testing with variant configurations
• Setting or querying the preferred configuration
• Showing or hiding variant control variable usage in a model
• Opening or closing the Variant Manager UI

When NOT to Use

• General simulation or testing workflows that do not involve variant configurations → use simulating-simulink-models, simulink-run-parallel-simulations, or testing-simulink-models
• General Simulink model building or block-level editing, including creating or editing variant blocks (Variant Subsystem, Variant Source/Sink) → use building-simulink-models
• Code generation for variant models → use simulink-configure-model-for-code-generation
• Changing ActiveConfigurationSet or ConfigSet parameters (Simulink configuration sets, not variant configurations) → use building-simulink-models

Hard Rules

• Onboard immediately. As soon as this skill is invoked, run Onboarding before doing anything else. Do NOT skip onboarding, as this will setup necessary context for other workflows. Onboarding is per model — if the user switches to a different model or changes attached variant configurations object, onboard again for that model.
• Read the data model before touching configurations. Before any task that requires CRUD operations on variant configurations, constraints, or control variable values, read references/variant-configurations-data-model.md — including before following references/variant-configurations-operations.md. It defines the object structure, value unwrapping, and model-level control variable rules those tasks depend on.
• One question at a time. Ask a single question, give your recommended answer with a one-line reason, and wait for the reply before asking the next. Continue until shared understanding is reached.
• Finding facts is YOUR job, never the user's. Use tools to discover model state, variable names, enum values, dictionary contents, etc. Never ask the user to look something up that you can determine programmatically.
• Never guess function syntax. Only use syntax documented in the reference files of this skill. If the function is not covered in a reference file, run help <functionName> in MATLAB to confirm the exact syntax before using it. Do NOT invent arguments or assume parameter names.
• Never assume names exist — always verify first. Before using ANY property name, field name, class name, enum class name, method name, or parameter setting, verify it programmatically in MATLAB (e.g., using fieldnames, properties, methods, class, which, get_param). If you have not confirmed a name exists in the current session, you MUST NOT use it. Inspect first, act second. Exception: syntax and names explicitly documented in this skill's reference files can be assumed to be present.
• Reload the UI once after all VCS mutations are complete. Changes made via evalin — adding, removing, or modifying configurations, constraints, or control variable values — are not visible in an open Variant Manager until reloadVariantConfigurationsInUI runs. Call it exactly once, at the end of the whole mutation sequence: adding three configurations means one reload, not three. Never call it per operation, inside a loop, after read-only operations, after applyConfiguration (which does not change the VCS), or after variantConfigActivateModel / variantConfigUpdateModel (which already sync the UI). Reload discards any unapplied edits in the UI and re-reads the VCS from its source. Changing which VCS is attached is not a state change and reload does not handle it — close and reopen the UI instead.
• Never let unsaved VCS changes be discarded silently. Changes to the VCS live only in memory until they are saved: in a data dictionary they stay in the open dictionary until saveChanges is called, and in the base workspace they last only for the current MATLAB session. Do not save on your own initiative. Before running any code that closes data dictionaries with '-discard' — every simulation and testing workflow in this skill does — check for unsaved work and ask the user, one question at a time:
  • VCS in a data dictionary (vcsSource is 'data dictionary'): if Simulink.data.dictionary.open(slddFile).HasUnsavedChanges is true, ask whether to save the dictionary first. Call saveChanges only after the user confirms; if they decline, tell them the changes will be lost when the dictionary is discarded.
  • VCS in the base workspace: if it was modified in this session, recommend saving it to a MAT-file (for example save('<file>.mat', '<vcsName>') in the base workspace) so it can be reused in a later MATLAB session, and save only after the user confirms.
• Suggest the Variant Manager UI for exploration. When the user is exploring variant structure (model hierarchy, variant components, configurations, control variables), suggest opening the Variant Manager UI. On R2026a+, use Simulink.VariantManager.open(model). On older releases, use the launchVariantManagerUI script. To close the UI, use the closeVariantManagerUI script. The UI displays model hierarchy, variant components, and configuration details far more effectively than programmatic inspection alone.
• Preferred configuration is only a label. PreferredConfiguration records which configuration is regarded as preferred and has no functional effect: it does not activate, seed, or influence any variant operation. Never describe it as a default — its legacy name, DefaultConfiguration, invites that mistake.
• Respect the MATLAB release. This is non-negotiable. Before calling any API, check its "Introduced" annotation in the reference files against the onboarded releaseVersion. If it is newer, do NOT use it — use the documented fallback or tell the user it is unavailable. Use Name=Value syntax only on R2026a+ and positional arguments on earlier releases; never mix the two.

---

Onboarding

Run this when the skill starts, and again whenever the target model changes. It establishes the facts every later step relies on: the MATLAB release, the target model, the variant configurations object (VCS) attached to the model, the data source that holds it, and the other VCS objects in that source. Determine them from MATLAB; ask the user only when no model, or more than one, is loaded.

Step 1: Release and Target Model

releaseVersion = version('-release');
modelNames = find_system('SearchDepth', 0);

if isempty(modelNames)
    error('No loaded Simulink model was found. Ask the user which model to open or use.');
elseif numel(modelNames) == 1
    modelName = modelNames{1};
else
    disp('Loaded models:');
    disp(modelNames(:));
    error('Multiple loaded models were found. Ask the user which model to use and store it as modelName.');
end

If several models are loaded, ask which one to use, store it in modelName, and continue with Step 2.

Step 2: Attached VCS, Its Source, and Peer VCS Objects

if ~isMATLABReleaseOlderThan('R2026b')
    vcsModelParam = 'VariantConfigurations';
    ddSectionName = 'Design Data';
    vcsClassName = 'Simulink.VariantConfigurations';
else
    vcsModelParam = 'VariantConfigurationObject';
    ddSectionName = 'Configurations';
    vcsClassName = 'Simulink.VariantConfigurationData';
end

vcsName = get_param(modelName, vcsModelParam);
slddFile = get_param(modelName, 'DataDictionary');

vcsLocation = '';
vcsSource = '';
availableVcsNames = {};

if ~isempty(char(slddFile))
    dictObj = Simulink.data.dictionary.open(slddFile);
    ddSection = getSection(dictObj, ddSectionName);
    entries = find(ddSection);

    for i = 1:numel(entries)
        if isa(getValue(entries(i)), vcsClassName)
            availableVcsNames{end+1} = entries(i).Name; %#ok<AGROW>
        end
    end

    if ismember(vcsName, availableVcsNames)
        vcsLocation = slddFile;
        vcsSource = 'data dictionary';
    end
end

% Check base workspace if the attached VCS was not found in the dictionary.
if isempty(vcsLocation) && ~isempty(vcsName)
    if evalin('base', sprintf('exist(''%s'', ''var'')', vcsName))
        if evalin('base', sprintf('isa(%s, ''%s'')', vcsName, vcsClassName))
            vcsLocation = 'base workspace';
            vcsSource = 'base workspace';
            if ~ismember(vcsName, availableVcsNames)
                availableVcsNames{end+1} = vcsName; %#ok<AGROW>
            end
        end
    end
end

otherVcsNames = setdiff(availableVcsNames, {vcsName}, 'stable');

fprintf('MATLAB release: %s\n', releaseVersion);
fprintf('Model: %s\n', modelName);
fprintf('Data dictionary: %s\n', slddFile);
fprintf('Attached VCS: %s\n', vcsName);
fprintf('Attached VCS location: %s\n', vcsLocation);
fprintf('Attached VCS source: %s\n', vcsSource);
fprintf('Other VCS objects in same source: %s\n', strjoin(otherVcsNames, ', '));

Report

Report the onboarding facts to the user in this format:

## Model: <modelName>

| Property | Value |
|----------|-------|
| MATLAB Release | <releaseVersion> |
| Model Name | <modelName or none> |
| Data Dictionary | <slddFile or none> |
| Attached Variant Configurations | <vcsName or none> |
| Attached VCS Location | <vcsLocation or not found> |
| Attached VCS Source | <vcsSource or not found> |
| Other VCS Objects In Same Source | <comma-separated names or none> |

Do not include configuration tables, constraints, or control-variable details in this report unless the user explicitly asked for them.

---

Workflow Router

After onboarding, determine user intent and route to the appropriate reference.

Disambiguation: Simulation vs Analysis vs Testing

| User's focus | Route to | |---|---| | What output is produced for a named or implied variant configuration — signal values, behavior, plotting results | Simulation | | What variants are active — which blocks differ, active paths, structural comparison | Analysis | | Pass/fail verification — benchmarking, regression, baseline, test reports | Testing |

**Preconditi