Main Content

Compatibility Considerations When Using Variant Manager for Simulink Support Package

Starting in R2022b, the variant manager functionality in Simulink® is available as a support package named Variant Manager for Simulink.

The next sections describe compatibility considerations when using the new Variant Manager functionality.

Changes to the Simulink.VariantConfigurationData class

These class members will be removed in a future release. Scripts that use these class members continue to work with a warning.

To be Removed

Recommended Replacement

DefaultConfiguration propertyPreferredConfiguration property
SubModelConfigurations property

The variant configurations for a top-level model must also define the variant control variables used by any referenced components in the model hierarchy.

validateModel methodSimulink.VariantManager.activateModel method
getFor methodSimulink.VariantManager.getConfigurationData method
addSubModelConfigurations methodSimulink.VariantConfigurationData.addComponentConfiguration method
removeSubModelConfiguration methodSimulink.VariantConfigurationData.removeComponentConfiguration method
getDefaultConfiguration methodSimulink.VariantConfigurationData.getPreferredConfiguration method
setDefaultConfigurationName methodSimulink.VariantConfigurationData.setPreferredConfiguration method

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

    Note

    For existing models with an associated variant configuration object, variant control variables in the referenced model configuration will be automatically migrated to the variant configuration of the top-level model. You must save the variant configuration object using Variant Manager to fix related warnings.

  • 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'
    

Changes to the Simulink.VariantManager class

New Methods

Purpose

Simulink.VariantManager.activateModelValidate and activate a variant configuration on a model.
Simulink.VariantManager.applyConfigurationApply a variant configuration on a model.
Simulink.VariantManager.generateConfigurationsGenerate variant configurations for a model automatically
Simulink.VariantManager.getPreferredConfigurationNameGet the name of the preferred variant configuration for a model.
Simulink.VariantManager.getConfigurationDataGet the variant configuration data object for a model.

Variant Reducer and Variant Analyzer

Variant Reducer and Variant Analyzer no longer require a Simulink Design Verifier™ license.

See Also

|

Related Topics