Configure Postbuild Variant Conditions for AUTOSAR Software Components

AUTOSAR software components use variants to enable or disable AUTOSAR interfaces or implementations in the execution path based on defined conditions. Variation points in a component present a choice between two or more variants. Postbuild variant binding enables you to configure AUTOSAR variants modeled in Simulink^® to activate on or after the AUTOSAR software component startup by using an AUTOSAR run-time environment (RTE) function call. You can now:

• Import AUTOSAR software components that contain postbuild variation points from ARXML files.

• Import shared PostBuildVariantCriterion and PostBuildVariantCondition definitions from ARXML files.

• Model AUTOSAR postbuild variation points in component models.

• Export ARXML variant descriptions that define PostBuildVariantCriterions and PostBuildVariantConditions.

• Generate C code with AUTOSAR Rte_PbCon function calls.

You can create postbuild variants at startup for AUTOSAR component models as long as the components contain Simulink variant blocks that model AUTOSAR variants. Alternatively, you can import ARXML files that contain PostBuild conditions and have AUTOSAR blockset create the parameter objects for each defined PostBuildVariantCriterion and the relevant Variant Source and Variant Sink blocks with startup variant activation times.

For an example of how to create and configure postbuild conditions, open the model:

openExample('mAutosarVariantSubsystem.slx')

To specify the startup variant activation time, open the Block Parameters of the variant blocks in the component model and configure the Variant activation time to Startup. For this model, configure the Variant Subsystem block.

To model a postbuild condition, create a MATLAB variable. This model already defines a variant condition as a AUTOSAR.Parameter data object, rainSensor. Configure this object as a MATLAB variable postbuild condition:

rainSensor = 2;

The Variant Subsystem block dialog box defines the variant condition logic, which is based on the postbuild constant value. You can specify an expression or a Simulink.VariantExpression object containing an expression.

When you generate code and export ARXML for the model:

• The exported ARXML includes PostBuildVariantCriterion and PostBuildVariantCondition descriptions for the postbuild variant criteria and conditions that you defined.

  <POST-BUILD-VARIANT-CONDITIONS>
      <POST-BUILD-VARIANT-CONDITION>
          <MATCHING-CRITERION-REF DEST="POST-BUILD-VARIANT-CRITERION">
            /vss_pkg/vss_dt/PostBuildCriterions/rainSensor
          </MATCHING-CRITERION-REF>
          <VALUE>1</VALUE>
      </POST-BUILD-VARIANT-CONDITION>
  </POST-BUILD-VARIANT-CONDITIONS>

  You can use the AUTOSAR Dictionary XML Options to generate the PostBuildVariantCriterions and associated ValueSets as a package.

• The generated AUTOSAR C code includes Rte_PbCon function calls to resolve postbuild conditions for variant binding.

  void Runnable_Step(void)
  {
  ...
    /* Outputs for Atomic SubSystem: '<Root>/Variant Subsystem' */
    if (Rte_PbCon_mAutosarVariantSubsystem_c0()) {
  ...
    } else if (Rte_PbCon_mAutosarVariantSubsystem_c1()) {
  ...
    }
    /* End of Outputs for SubSystem: '<Root>/Variant Subsystem' */
  ...
  }

  For software-in-the-loop (SIL) simulation, in the stub folder, the model build generates stub implementations of the Rte_PbCon functions used to resolve the post-build conditions.