Cross-Release Code Integration - MATLAB & Simulink (original) (raw)

If you have an Embedded Coder® license, you can integrate generated C code from previous releases with generated code from the current release when the source models are single-rate and the generated C code is from:

• Top-model or subsystem build processes that use the nonreusable function code interface.
• Single or multiple instance model reference build processes that suppress error status monitoring (SuppressErrorStatus ison).

If you can reuse existing code without modification, you can reduce the cost of reverification.

Note

crossReleaseImport supports the import of generated code from only the previous eight releases.

Workflow

Consider this control system model.

The Controller Model block references a model that consists of three components:

• P1 is a Model block, which references a model developed with a previous release, for example, R20XXb. The generated model code, with the standalone code interface, is in the folder P1_ert_rtw.
• C1 is a Model block, which references a model that you are developing in the current release.
• P2 is a subsystem block developed with a previous release, for example, R20YYa. The generated subsystem code is in the folderP2_ert_rtw.
• P3 is a Model block, which references a model developed with a previous release, for example, R20YYb. The generated model code, with the model reference code interface, is in the folder slprj/ert/P3.

To integrate code from previous releases with generated code from the current release, use this workflow:

1. Specify an existing shared code folder
   You can specify the reuse of shared code from an existing folder, for example, a library of verified code that an administrator maintains and updates. Specify the shared code folder for model components that require code generation in the current release, for example,Controller and C1.
   In the Configuration Parameters dialog box, in the field, enter the full path to the shared code folder.
2. Import components into current release
   From the current release, import generated component code from previous releases as software-in-the-loop (SIL) blocks or processor-in-the-loop (PIL) blocks. For example:
   crossReleaseImport(folderPathForP1_ert_rtw,'Controller', ...
   'SimulationMode','SIL');
   crossReleaseImport(folderPathForP2_ert_rtw,'Controller', ...
   'SimulationMode','SIL');
   crossReleaseImport(folderPathForP3,'Controller', ...
   'SimulationMode','SIL');
   In the current working folder, the crossReleaseImport function creates the xrel subfolder that contains software-in-the-loop (SIL) blocks and subfolders:
   • P1_R20XXb_sil andP1_R20XXb_sil_resources
   • P2_R20YYa_sil andP2_R20YYa_sil_resources
   • P3_R20YYb_sil andP3_R20YYb_sil_resources
3. Incorporate components into current release model
   To replace components with SIL or PIL blocks, use the Simulink® Editor or the pil_block_replace command. For example, replace:
   • P1 with P1_R20XXb_sil.
   • P2 with P2_R20YYa_sil.
   • P3 with P3_R20YYb_sil.
     When you run a model simulation, the simulation runs the previous release code through the SIL or PIL blocks.
     When you build the Controller model (slbuild('Controller')), the code generator does not generate new code for the components represented by the SIL or PIL blocks. The model code calls code generated by previous releases.
     The Simulink Code Inspector™ supports call-site validation for a cross-release SIL or PIL block. The block provides a specification of the expected function call, which is derived from the generated code. During analysis, the Simulink Code Inspector compares the expected function call with the block behavior. For information about analysis limitations, see S-Function (Simulink Code Inspector).

Limitations

The cross-release code integration workflow does not support:

• Export-function models for ERT code.
• Simulink Function and Function Caller blocks across the boundaries of ERT code generated by different releases.
• The import of generated code from the current release into a previous release (forward compatibility).
• The export of files located in the MATLAB® root folder of the previous release, for example, blockset library files.
• The export and import of generated code from models with noninlined S-functions.
• C-API.

At the end of the model build process, the code generation report displays shared files that are directly used by the integration model, for example, Controller. The report does not display shared files used by the components of the model, for example,P1 and P2.

If your model has:

• A cross-release SIL or PIL block, you cannot run rapid accelerator mode simulations.
• A Model block that references a model containing a cross-release SIL or PIL block, you cannot run accelerator mode or rapid accelerator mode simulations.

You can run:

• Top-model SIL simulations of models that contain cross-release SIL or PIL blocks. The models must not contain cross-release AUTOSAR Model blocks.
• Model block SIL simulations of referenced models that contain cross-release SIL or PIL blocks. The referenced models must not contain cross-release AUTOSAR Model blocks.

For information about other cross-release AUTOSAR code integration limitations, see Import AUTOSAR Code from Previous Releases.

Simulink.Bus Support

To use a bus object as a data type in cross-release ERT code integration, use one of these approaches.

Root-Level I/O Through Global Variables in Generated Code

When imported ERT code from a previous release implements an input or output port through a global variable, the code that is generated from the integration model depends on the properties of the signal connected to the port in the integration model.

If the integration model signal does not map to a generated code variable that has the same name as the signal in the imported code, the generated code:

• Defines the variable if it is declared but undefined in the imported code.
• Creates additional code to copy data between the variable generated from the integration model and the variable in the imported code.

If the integration model signal maps to a variable with the same name as the signal in the imported code, the variable used by the imported code is also used by the code generated from the integration model. You must use a compatible storage class for the signal.

Communicate Between Current and Previous Release Components Through Global Data Stores

Current and previous release components can communicate through global data stores associated with Simulink.Signal objects in the MATLAB base workspace or a Simulink data dictionary. The workflow described here applies to cross-release ERT code integration.

Code Generation Configuration

Before generating model component code in the old release, configure data store memory to use a storage class that imports external code.

If a top-model or subsystem build process generates the code, set theStorage class property of the Simulink.Signal objects to one of these classes:

• ImportedExtern
• ImportedExternPointer
• ImportFromFile custom storage class

If a model reference build process generates the code, you can also use these classes:

• ExportedGlobal
• ExportToFile custom storage class

Import Configuration

In the current release, before you run crossReleaseImport, define aSimulink.Signal object in the MATLAB base workspace or a Simulink data dictionary for each global data store of the component that you want to import:

1. For the object name and the Data type,Complexity, and Dimensions object properties, specify values that match values of the corresponding object in the component that you want to import.
2. For the Storage class property, specify a value that is compatible. If the previous release value isImportedExtern, specify one of these values for the current release:
   • ImportedExtern
   • ExportedGlobal
   • ImportFromFile orExportToFile custom storage class.
     If the previous release value isImportedExternPointer, then specifyImportedExternPointer for the current release.
3. For the Identifier property, specify a matching value only if the property is specified for the object in the component that you want to import.
4. Save the Simulink.Signal objects. The objects are required each time you simulate or build the imported SIL or PIL block.

For more information, see Data Stores in Generated Code.

Parameter Tuning

The cross-release ERT code integration workflow supports parameter tuning in an integration model that contains component code with tunable parameters from previous releases.

In the current release, before you run crossReleaseImport, for each tunable parameter of the component that you want to import:

1. Define a Simulink.Parameter object in the MATLAB base workspace or a Simulink data dictionary.
2. For the object name and the Data type,Complexity, and Dimensions object properties, specify values that match the previous release object values. If the variable in the imported source code does not have the same name as the object, for the Identifier property, specify a value that matches the variable name.
3. If the previous release object uses the GetSet custom storage class, specify:
   • A matching value for the Storage class object property.
   • The header file that defines the get andset access functions. For details, see Control Data Representation by Configuring Storage Class Properties and Access Data Through Functions with Storage Class GetSet.

For code generated by a top-model or subsystem build process in a previous release, these limitations apply:

• If a tunable parameter specified by a Simulink.Parameter object in the previous release has storage class set to ExportedGlobal and the storage class of the Simulink.Parameter object in the current release is also ExportedGlobal, an error occurs when you build the integration model.
• On a Mac operating system, if a tunable parameter specified by aSimulink.Parameter object in the previous release has storage class set to ExportedGlobal, you cannot build the integration model if the storage class of the Simulink.Parameter object in the current release (with the same name or alias) is ImportedExtern. To work around this limitation, modify the default settings:
  1. Get the build tool from the default toolchain.
     tc = coder.make.getDefaultToolchain;
     cComp = tc.getBuildTool('C Compiler');
  2. Extract the C compiler standard options.
     stdMaps = cComp.SupportedStandard.getLangStandardMaps;
     optionValues = stdMaps.getCompilerOptions('*');
  3. Remove -fno-common from the standard options for the C and C++ compilers.
     optionToRemove = '-fno-common';
     optionsToKeep = strrep(optionValues, optionToRemove, '');
     c_standard_opts_id = '$(C_STANDARD_OPTS)';
     custToolChainOpts = get_param(model,'CustomToolchainOptions');
     custToolChainOpts{2} = ...
     strrep(custToolChainOpts{2}, c_standard_opts_id, optionsToKeep);
     set_param(model, 'CustomToolchainOptions',custToolChainOpts);

Use Multiple Instances of Code Generated from Reusable Referenced Model

Using a reusable referenced model, you can specify unique model argument values for each instance of the referenced model in a parent model. Import previously generated code for the reusable referenced model into the current release as a parameterized cross-release SIL or PIL block, and then insert multiple instances of the block into an integration model. For each block instance, you can specify unique model argument values.

1. Update existing shared code folder.
   sharedCodeUpdate(sourceFolder,destinationFolder)
2. Import generated code for the reusable referenced model into the current release as a parameterized cross-release block, for example, a SIL block.
   handleSILBlock = crossReleaseImport(reusableReferencedModelcodeLocation, ...
   configSetIntegrationModel, 'SimulationMode', 'SIL');
3. In the integration model, replace, for example, two instances of the referenced model with instances of the cross-release SIL block.
   open_system(integrationModel);
   blockInstanceName1 = 'refModelInstanceName1';
   blockinstanceName2 = 'refModelInstanceName2';
   SILBlockFullName = getfullname(handleSILBlock);
   replace_block(integrationModel, 'Name', blockInstanceName1, ...
   SILBlockFullName, 'noprompt');

replace_block(integrationModel, 'Name', blockInstanceName2, ...
SILBlockFullName, 'noprompt'); 4. Suppose the reusable referenced model has model arguments_`paramA`_ and_`paramB`_, and the values for the referenced model instances,_`refModelInstanceName1`_ and_`refModelInstanceName2`_, are workspace variables. In this case, you can specify argument values for the cross-release block instances that are workspace variables.
pathToBlockInstanceName1 = [integrationModel, '/', blockInstanceName1];
pathToBlockInstanceName2 = [integrationModel, '/', blockInstanceName2];
set_param(pathToBlockInstanceName1, 'paramA', 'paramAinstName1');
set_param(pathToBlockInstanceName1, 'paramB', 'paramBinstName1');
set_param(pathToBlockInstanceName2, 'paramA', 'paramAinstName2');
set_param(pathToBlockInstanceName2, 'paramB', 'paramBinstName2'); 5. To specify unique model argument values for the block instances in the integration model, assign values to the workspace variables,_`paramAinstName1`_,_`paramBinstName1`_,_`paramAinstName2`_, and_`paramBinstName2`_.

Compare Simulation Behavior of Model Component in Current Release and Generated Code from Previous Release

In a previous release, suppose that you developed a model component, generated code for the component, and tested and deployed the generated code. Now, in the current release, you want to add features to the model component and use the model component in system development and code generation. Before you proceed, you can compare the functional behavior of the model component and the generated code from the previous release.

To test the numerical equivalence between the model component and the generated code from the previous release, use Simulink Test™. With the Test Manager (Simulink Test), you can perform back-to-back tests and output comparisons:

1. Bring the model component into the current release as a Model block with the Simulation mode block parameter set toNormal.
2. With the Model block, create a top model that specifies test input data.
3. Import the code generated in the previous release into the current release as a SIL block.
4. With the SIL block, create another top model that specifies the same the test input data.
5. In the Test Manager, create an equivalence test case that runs simulations of the top models and compares outputs.
6. Run the test case and review results.

For more information, see .

Note

If you want to compare the behavior of generated code from the current and previous release, in step 1, specify these Model block parameters:

• Set Simulation mode to Software-in-the-loop (SIL) or Processor-in-the-loop (PIL).
• Set Code interface to Top model.

Import AUTOSAR Code from Previous Releases

If you install the Embedded Coder Support Package for AUTOSAR Standard, you can import into the current release AUTOSAR component code that you generated in a previous release.

When you run crossReleaseImport, the function imports the AUTOSAR code as a cross-release Model block instead of a SIL or PIL block. TheSimulation mode parameter of the Model block is set toSoftware-in-the-loop (SIL) orProcessor-in-the-loop (PIL). Incorporate theModel block into the current release model.

These limitations apply:

• The cross-release workflow does not support per-instance memory that accesses NVRAM.
• Tunable parameters must be mapped to AUTOSAR calibration parameters or AUTOSAR internal calibration parameters.
• If the original model uses variants or symbolic dimensions (dimension variants), the imported model can use only the same variant and symbolic dimension configuration that was used when generating the code in the previous release.

See Also

sharedCodeMATLABVersions | sharedCodeUpdate | crossReleaseImport

Topics

• Cross-Release Shared Utility Code Reuse
• Generate Shared Utility Code
• Generate Shared Utility Code for Fixed-Point Functions
• Generate Shared Utility Code for Custom Data Types
• Integrate Generated Code by Using Cross-Release Workflow