Configure AUTOSAR Scheduling and Simulation

You can simulate the behavior of the aggregated components in an AUTOSAR classic architecture model or an adaptive architecture model. To test the model, you can connect a test harness model that provides input values and other modeling elements. To simulate, go to the top level of the architecture model and click Run.

As an example of configuring scheduling and simulation for an AUTOSAR classic architecture model, you can:

Add Basic Software (BSW) blocks to simulate calls to BSW services.
Create a test harness model to connect inputs and plant elements to the architecture model.
Use the Schedule Editor to schedule and specify the execution order of component runnables.

Simulate Basic Software Service Calls

For the AUTOSAR Classic Platform, AUTOSAR Blockset provides Basic Software (BSW) blocks, which allow you to model software component calls to BSW services that run in the AUTOSAR run-time environment. BSW services include NVRAM Manager (NvM), Diagnostic Event Manager (Dem), and Function Inhibition Manager (FiM). In the run-time environment, AUTOSAR software components typically access BSW services using client-server or sender-receiver communication.

To simulate AUTOSAR components that call BSW services, you create a containing architecture, composition, or test harness model and add preconfigured BSW service component blocks. The blocks provide reference implementations of BSW service operations.

If the components in your architecture model use BSW caller blocks, make sure that the architecture model contains BSW service implementations. For more information, see Model AUTOSAR Basic Software Service Calls and Simulate AUTOSAR Basic Software Services and Run-Time Environment.

For an example of using BSW blocks in an AUTOSAR architecture model, see Author AUTOSAR Compositions and Components in Architecture Model.

Connect a Test Harness

After you develop an architecture model, you can connect it to a test harness model that provides meaningful input values and plant model elements. For example, consider the architecture model autosar_tpc_composition from example Author AUTOSAR Compositions and Components in Architecture Model. The model has three require (input) ports and one provide (output) port.

Here is a test harness model for simulating the architecture model autosar_tpc_composition. The test harness contains a plant model with a pedal input block and signals that correspond with the architecture model require and provide ports. This model was adapted from example model autosar_tpc_system.

To connect the architecture model to the test harness:

Insert a Model block.
Configure the Model block to reference the architecture model.
In the Model block dialog box, select the option Schedule rates. For the associated parameter Schedule rates with, select Schedule Editor. The architecture model components have explicit partitions that you can schedule with the Schedule Editor.
Connect the architecture model ports to the test harness signals.

To view and run the completed test harness model, open example model autosar_tpc_system. (To open the model in a local working folder, use openExample('autosar_tpc_system').)

Schedule Component Runnables

For AUTOSAR Classic Platform software components that contain multiple runnables, the AUTOSAR Timing Extensions specification defines execution order constraints. These constraints specify the execution order of runnable entities within a component. You can view and manipulate the constraints at the component level or, in AUTOSAR architecture models, at the Virtual Function Bus (VFB) level.

In architecture models, you can:

Import VFB-level execution order constraints from ARXML files.
Use the Schedule Editor to modify the execution order of AUTOSAR component runnables. The editor displays every runnable in every component in the composition hierarchy.
As part of composition export, export VFB-level execution order constraints to an ARXML timing module, modelname_timing.arxml.

To schedule and specify the execution order of AUTOSAR component runnables, use the Schedule Editor. From a standalone component model or an architecture model, you can:

View a graphical representation of component runnables as partitions in an AUTOSAR component or architecture model.
Create partitions and map them to AUTOSAR runnables.
Directly specify the execution order of runnables.

The Schedule Editor supports multiple modeling styles, including rate-based and export-function modeling. For more information, see Using the Schedule Editor and Create Partitions. For AUTOSAR component model examples, see Configure AUTOSAR Runnable Execution Order.

In an AUTOSAR architecture model, to open the Schedule Editor, open the Modeling tab and select Design Tools > Schedule Editor. The editor displays every runnable in every component in the composition hierarchy. Here is the execution order view when you open the Schedule Editor from the example architecture model autosar_tpc_composition. Use the editor controls to modify the execution order of the runnables.

Exporting a composition from an AUTOSAR architecture model exports VFB-level execution order constraints into the file modelname_timing.arxml. The ARXML module aggregates timing information from the entire composition hierarchy. This ARXML code shows the execution order constraint exported for the runnables in autosar_tpc_composition, based on the Schedule Editor configuration.

<VFB-TIMING UUID="...">
  <SHORT-NAME>TPC_Composition</SHORT-NAME>
  <TIMING-REQUIREMENTS>
    <EXECUTION-ORDER-CONSTRAINT UUID="...">
      <SHORT-NAME>EOC</SHORT-NAME>
      <BASE-COMPOSITION-REF DEST="COMPOSITION-SW-COMPONENT-TYPE">
        /Components/TPC_Composition
      </BASE-COMPOSITION-REF>
      <ORDERED-ELEMENTS>
        <EOC-EXECUTABLE-ENTITY-REF UUID="...">
          <SHORT-NAME>PedalSensor_PedalSensor_Step</SHORT-NAME>
          <COMPONENT-IREF>
            <TARGET-COMPONENT-REF DEST="SW-COMPONENT-PROTOTYPE">
              /Components/Sensors/PedalSensor
            </TARGET-COMPONENT-REF>
          </COMPONENT-IREF>
          <EXECUTABLE-REF DEST="RUNNABLE-ENTITY">
            /Components/PedalSensor/PedalSensor_IB/PedalSensor_Step
          </EXECUTABLE-REF>
          <SUCCESSOR-REFS>
            <SUCCESSOR-REF DEST="EOC-EXECUTABLE-ENTITY-REF">
              /Timing/TPC_Composition/EOC/TPS_Primary_ThrottleSensor1_Step
            </SUCCESSOR-REF>
          </SUCCESSOR-REFS>
        </EOC-EXECUTABLE-ENTITY-REF>
        <EOC-EXECUTABLE-ENTITY-REF UUID="...">
          <SHORT-NAME>TPS_Primary_ThrottleSensor1_Step</SHORT-NAME>
          ...
        </EOC-EXECUTABLE-ENTITY-REF>
        <EOC-EXECUTABLE-ENTITY-REF UUID="...">
          <SHORT-NAME>TPS_Secondary_ThrottleSensor2_Step</SHORT-NAME>
        ...
        </EOC-EXECUTABLE-ENTITY-REF>
        <EOC-EXECUTABLE-ENTITY-REF UUID="...">
          <SHORT-NAME>Monitor_ThrottleSensorMonitor_Step</SHORT-NAME>
          ...
        </EOC-EXECUTABLE-ENTITY-REF>
        <EOC-EXECUTABLE-ENTITY-REF UUID="...">
          <SHORT-NAME>Ctrl_Controller_Step</SHORT-NAME>
          ...
        </EOC-EXECUTABLE-ENTITY-REF>
        <EOC-EXECUTABLE-ENTITY-REF UUID="...">
          <SHORT-NAME>Actuator_Actuator_Step</SHORT-NAME>
          <COMPONENT-IREF>
            <TARGET-COMPONENT-REF DEST="SW-COMPONENT-PROTOTYPE">
              /Components/TPC_Composition/Actuator
            </TARGET-COMPONENT-REF>
          </COMPONENT-IREF>
          <EXECUTABLE-REF DEST="RUNNABLE-ENTITY">
            /Components/Actuator/Actuator_IB/Actuator_Step
          </EXECUTABLE-REF>
        </EOC-EXECUTABLE-ENTITY-REF>
      </ORDERED-ELEMENTS>
    </EXECUTION-ORDER-CONSTRAINT>
  </TIMING-REQUIREMENTS>
  <COMPONENT-REF DEST="COMPOSITION-SW-COMPONENT-TYPE">
    /Components/TPC_Composition
  </COMPONENT-REF>
</VFB-TIMING>