DefaultConfiguration property will be removed. Use the PreferredConfiguration property instead.

Setting a default variant configuration for a variant configuration data object is not recommended. Previously, if you had set a default configuration, compiling or simulating the model automatically activated the default configuration irrespective of the variant control variable values in the base workspace or data dictionary used by the model. Now, this behavior is not applicable and setting the DefaultConfiguration property has no effect.

You can set any of the named configurations defined for a model as the PreferredConfiguration. You can use this property to indicate the configuration that is suited for the model for common workflows. This configuration is not applied automatically when compiling or simulating a model. You must apply the preferred configuration explicitly on the model, if required.

If the variant configuration data object (vcd) for your model has an existing DefaultConfiguration, you can convert it to PreferredConfiguration using this command:

vcd.convertDefaultToPreferred(model);

You can use this syntax to additionally update the PostLoadFcn or InitFcn callbacks of the model or both, to activate the preferred configuration on the model:

vcd.convertDefaultToPreferred(model, ...
 AddActivateToPostLoadFcn=true,AddActivateToInitFcn=true);

To apply the PreferredConfiguration on your model before compiling or simulating the model, use this command:

Simulink.VariantManager.applyConfiguration ...
(model,'Configuration',vcd.getPreferredConfigurationName());

SubModelConfigurations property will be removed.

The variant configurations for a top-level model must also define the variant control variables used by any referenced components in the model hierarchy, such as referenced models. This approach helps to maintain a single consistent definition for a variant control across the hierarchy.

If the referenced component has named variant configurations of its own, you can use them to set up the corresponding variant control variables in the top-level model configuration. For more information, see Compose Variant Configurations for Top Model Using Referenced Model Configurations.

validateModel method will be removed. Use the Simulink.VariantManager.activateModel method instead to validate and activate a variant configuration on the model.

Calling the validateModel method is equivalent to calling the activateModel method, but the validateModel method returns a logical value that indicates success or failure, whereas the activateModel method throws an error if the activation fails.

Change in the format of errors output argument of validateModel method — The fields Type, Source, PathInModel, and PathInHierarchy have been removed from the structure named Errors within the second output argument, errors.

This example shows the fields available in the structure Errors for a model named myModel with activation errors.

[success,errors] = Simulink.VariantConfigurationData.validateModel('myModel')

success =

  logical

   0

errors =

  1×2 cell array

    {1×1 struct}    {1×1 struct}

errors{1}

ans = 

  struct with fields:

     Model: 'myModel'
    Errors: {1×16 cell}

errors{1}.Errors{1}

ans = 

  struct with fields:

      Message: 'Variant control 'V==1' used by block 'myModel/Variant Source' 
      must return a logical value.
      Caused by: Unrecognized function or variable 'V'.'
      MessageID: 'Simulink:Variants:ErrorInEvalOfVarControl'