Simulate AUTOSAR component calls to Basic Software memory and diagnostic services by using reference implementations.
The AUTOSAR standard defines Basic Software (BSW) services that run in the AUTOSAR run-time environment. The services include NVRAM Manager (NvM) Diagnostic Event Manager (Dem), and Function Inhibition Manager (FiM) services. In the AUTOSAR run-time environment, AUTOSAR software components typically access BSW services using client-server or sender-receiver communication.
In your AUTOSAR software component model, to implement client calls to NvM, Dem, and FiM service interfaces, you drag and drop preconfigured NvM, Dem, and FiM caller blocks. Each block has prepopulated parameters, such as Client port name and Operation. You configure the block parameters, for example, to select a service operation to call. To configure the added caller blocks in the AUTOSAR software component, you synchronize the model. The software creates AUTOSAR client-service interfaces, operations, and ports, and maps each Simulink function call to an AUTOSAR client port and operation. For more information, see Configure Calls to AUTOSAR NVRAM Manager Service, Configure Calls to AUTOSAR Diagnostic Event Manager Service, and Configure Calls to AUTOSAR Function Inhibition Manager Service.
Here is a throttle position integration model, which integrates two throttle position sensor components and a throttle position monitor component. The sensor components take a raw throttle position sensor (TPS) value and convert it to a TPS percent value. The monitor component takes the TPS percent values provided by the primary and secondary sensor components and decides which TPS signal to pass through. The sensor components call BSW NvM and Dem services, and the monitor component calls BSW Dem services.
autosar_bsw_sensor2 each contain an Initialize Function block, which calls the NvM service interface
NvMService. The calls are implemented using the Basic Software library block NvMServiceCaller. Each block is configured to call the
ReadBlock calls use client ports
S2LowSetPoint. Here is the Initialize Function block for
Here is the NvMServiceCaller block dialog box for the
ReadBlock call in the Initialize Function block. For more information, see NvMServiceCaller.
autosar_bsw_sensor2 each contain two calls to the Dem service interface
DiagnosticMonitor. Both calls are implemented using the Basic Software library block DiagnosticMonitorCaller. Each block is configured to call the
SetEventStatus calls use client ports
Here is the DiagnosticMonitorCaller block dialog box for the
StuckLow call in the first sensor component. For more information, see DiagnosticMonitorCaller.
autosar_bsw_monitor contains a call to the Dem service interface
DiagnosticMonitor and four calls to the Dem service interface
As in the sensor component, a
DiagnosticMonitorCaller block implements the
DiagnosticMonitor call, and it is configured to call the
SetEventStatus operation. The client port name is
DiagnosticInfo calls are implemented using the Basic Software library block DiagnosticInfoCaller. Each block is configured to call the
GetEventFailed calls use client ports
Here is the
DiagnosticinfoCaller block dialog box for the
TPS1StuckLow call. For more information, see DiagnosticInfoCaller.
If you have Simulink Coder and Embedded Coder software, you can generate C code and export ARXML descriptions for the NvM and Dem service calls. Open and build each component model. For example, to build model
autosar_bsw_monitor, open the model. Press Ctrl+B or enter the MATLAB command
To see the results of the model build, examine the code generation report.
To simulate an AUTOSAR component model that calls BSW services, create a containing composition, system, or harness model. In that containing model, provide reference implementations of the NvM, Dem, and FiM service operations called by the component.
The AUTOSAR Basic Software block library includes an NVRAM Service Component block and a Diagnostic Service Component block. The blocks provide reference implementations of NvM, Dem, and FiM service operations. To support simulation of component calls to the NvM, Dem, and FiM services, include the blocks in the containing model. You can insert the blocks in either of two ways:
Automatically insert the blocks by creating a Simulink Test harness model
Manually insert the blocks into a containing composition, system, or harness model
To automatically insert Service Component blocks for a model that calls BSW NvM, Dem, and FiM services, open the model (or a containing model) and create a Simulink Test test harness (requires Simulink Test). For more information, see Create a Test Harness (Simulink Test). Creating a test harness compiles the model, adds the Service Component blocks, and creates ports and other elements required for simulation.
This example manually inserts Service Component blocks for NvM and Dem service calls. Open the integration model
autosar_bsw_presim. Using the Library Browser or
add_block commands, or by typing block names in the model window, add the NVRAM and Diagnostic Service Component blocks to the model.
open_system('autosar_bsw_presim'); add_block('autosarlibnvm/NVRAM Service Component','autosar_bsw_presim/NVRAM Service Component'); add_block('autosarlibdem/Diagnostic Service Component','autosar_bsw_presim/Diagnostic Service Component'); set_param('autosar_bsw_presim','SimulationCommand','update');
The NVRAM Service Component block has prepopulated parameters, including run-time environment (RTE) parameters and NVRAM Properties parameters. Examine the parameter settings and consider if any require modifying, based on how you are using the NvM service operations. For more information, see NVRAM Service Component.
The RTE tab table lists component client ports and their mapping to NvM service block IDs. Each row in the table represents a call into NvM services from a Basic Software caller block. Calls that act on the same NvM block typically use the same block ID. This example maps the NvM
ReadBlock client ports to different block IDs.
The Diagnostic Service Component block has prepopulated parameters, including RTE parameters and Dem Counter-Based Debouncing parameters. Examine the parameter settings and consider if any require modifying, based on how you are using the Dem service operations.
The Counter-Based Debouncing parameters control the counter-based debounce algorithm provided by the Dem service reference implementations. During multiple simulation runs, you can tune event step size and threshold parameters and observe the effects. For more information, see Diagnostic Service Component.
The RTE tab table lists component client ports and their mapping to Dem or FiM service IDs (in this example, event IDs). Each row in the table represents a call into Dem services from a Basic Software caller block. Calls that act on the same event typically use the same event ID. This example maps the Dem
SetEventStatus client ports to different event IDs, and then maps the Dem
GetEventFailed client ports to event IDs that are shared with
SetEventStatus ports. For example,
TPS1StuckHigh share event ID 1;
TPS1StuckLow share event ID 2; and so on.
After configuring NVRAM and Diagnostic Service Component blocks in the integration model, simulate the model. The simulation exercises the AUTOSAR NvM and Dem service calls in the throttle position sensor and monitor component models.
open_system('autosar_bsw_simulation'); simOutIntegration = sim('autosar_bsw_simulation');