Configure Calls to AUTOSAR Function Inhibition Manager Service

For the AUTOSAR Classic Platform, the AUTOSAR standard defines important services as part of Basic Software (BSW) that runs in the AUTOSAR Runtime Environment (RTE). Examples include services provided by the Diagnostic Event Manager (Dem), the Function Inhibition Manager (FiM), and the NVRAM Manager (NvM). In the AUTOSAR RTE, AUTOSAR software components typically access BSW services using client-server or sender-receiver communication.

To support system-level modeling of AUTOSAR components and services, AUTOSAR Blockset provides an AUTOSAR Basic Software block library. The library contains preconfigured blocks for modeling component calls to AUTOSAR BSW services and reference implementations of the BSW services. For information about using the blocks to model client calls to AUTOSAR BSW service interfaces, see Model AUTOSAR Basic Software Service Calls.

For live-script examples of simulating AUTOSAR BSW services, see examples Simulate AUTOSAR Basic Software Services and Run-Time Environment and Configure and Simulate AUTOSAR Function Inhibition Service Calls.

As defined in the AUTOSAR specification, the FiM provides a control mechanism for selectively inhibiting (that is, deactivating) function execution in software component runnables, based on function identifiers (FIDs) with inhibition conditions. For example, an FID can represent functionality that must be stopped if a specific failure occurs.

The FiM is closely related to the Dem, because inhibition conditions can be based on the status of diagnostic events. For example, if a sensor failure event is reported to the Dem, the FiM can inhibit the associated function identifier and stop execution of the corresponding functionality.

AUTOSAR Blockset provides FiM and Dem blocks that allow you to query the status of function inhibition conditions and configure function inhibition criteria based on diagnostic event status.

Model Function Inhibition

AUTOSAR software components use function inhibition to switch functions on or off depending on the state of Diagnostic Event Manager (Dem) events. Software components can react to an event such as a sensor success or failure by allowing or preventing execution of an associated function.

Consider an AUTOSAR software component model in which a DiagnosticMonitorCaller block serves as a monitor for new functionality within the component. Dem events passed by using the DiagnosticMonitorCaller block indicate whether conditions such as sensor failure have occurred. Event status determines whether execution of associated downstream functions can proceed. The functions run only if no failure events are reported.

To implement function inhibition for new functionality in the component:

Consider the DiagnosticMonitorCaller block dialog box. Examine the client port name and operation values. Confirm that the client port and its client interface are defined in the AUTOSAR Dictionary.
The new functionality is modeled such that it will only execute if event status indicates no sensor failures. This example places the new functionality in an enabled subsystem.
Add a Function Inhibition Caller block to the model. Open the block dialog box and configure the block to request a GetFunctionPermission operation from the FiM FunctionInhibition service interface. Specify a client port name and a sample time.
Open the Code Mappings editor and click the Update button. The software creates the specified client port and interface in the AUTOSAR Dictionary, and maps the Get Permission caller block to the specified AUTOSAR client port and operation.
Connect the Get Permission block to the enable port of the subsystem that contains the new functionality. The block represents evaluation of the function inhibition conditions for the new functionality. If the functionality is not inhibited and therefore has permission to run, the Get Permission block returns true, enabling the subsystem.
Here is the revised software component model.
Place the software component model in a test harness.
In the test harness model, to provide reference implementations of the Dem Get Status and FiM Get Permission services for simulation, add a Diagnostic Service Component block. Update the model.
Open the Diagnostic Service Component block dialog box. To refresh RTE and FiM tables in the dialog box at any point, update the model.
On the RTE tab, you configure event and function identifiers for events that can trigger function inhibition. In this example, the model hierarchy contains only one event port and one FID port, so the RTE tab requires no further configuration.
If the model hierarchy contains additional ports for multiple Get Permission blocks, with functionality distributed across multiple components, you can use the RTE tab to assign ports to the same FID to group them or separate FIDs to address them individually. For a function inhibition example with multiple ports and distributed functionality, see Configure and Simulate AUTOSAR Function Inhibition Service Calls.
After event and function identifiers are configured, switch to the FiM tab. On the FiM tab, you add and configure the inhibition conditions that determine when Get Permission blocks allow functionality to operate.
The FiM tab lists function identifiers representing functions in the model hierarchy for which function inhibition is implemented. In this example, the model hierarchy contains one FID.
To add an inhibition condition for the FID, select the FID and click the Add inhibition condition button. A row for the inhibition condition appears under the FID.
In the row, select an event ID value (matching an event ID listed in the RTE tab). Then, for the FID and event ID pair, select an inhibition mask value. The AUTOSAR specifications define mask values in a FiMInhibitionMask values table.
In this example, the function represented by FID 1 is inhibited if the event represented by event ID 1 is LAST_FAILED.
Update and simulate the harness model.

Next steps in developing the software component include:

Addressing how to trigger the event.
Adding the functionality to inhibit.

For a larger-scale example of modeling AUTOSAR function inhibition, see Configure and Simulate AUTOSAR Function Inhibition Service Calls.

Scope Failures to Operation Cycles

In an AUTOSAR software component, operation cycles represent automotive cycles, such as ignition cycles, power cycles, warm up cycles, or on-board diagnostic (OBD) cycles. A cycle can be started, stopped, or queried by using Diagnostic Event Manager services. You can use operation cycles to determine if a given event has failed within a given time.

Operation cycles split a simulation into periods of time, such as one minute cycles. In each cycle, the software can check if a diagnostic condition (event) has been TESTED (a FiM condition) during that cycle and inhibit functions accordingly.

The BSW block DiagnosticOperationCycleCaller supports the SetOperationCycleState and GetOperationCycleState services. A component calls the services to control component operation cycles, which are used to scope failures to a time period. Calling SetOperationCycleState with the value Dem_OperationCycleStateType.DEM_CYCLE_STATE_START starts an operation cycle. Passing in the value Dem_OperationCycleStateType.DEM_CYCLE_STATE_END ends an operation cycle. Calling GetOperationCycleState queries the current state of an operation cycle.

For an example use of the DiagnosticOperationCycleCaller block and the SetOperationCycleState service, see Configure and Simulate AUTOSAR Function Inhibition Service Calls.

Control Function Availability During Failure or For Testing

The Function Inhibition Manager supports inhibition criteria for restricting functional blocks from executing until logical and functional predecessors have run, or for restricting execution of a safety system until a failure is verified. However, you can restrict use of functionality independently of inhibition criteria. For example, a sensor component can disable reading of its sensor data during a failure or during testing of other system functionality.

The BSW block Control Function Available Caller supports the SetFunctionAvailable service, which provides a granular mechanism to inhibit specific functionality. A component uses SetFunctionAvailable with an input signal value of false to inhibit associated functionality, so that the Get Permission block for the functionality returns 0. In this example, a sensor monitor uses SetFunctionAvailable to inform a central monitor component whether sensor measurements are available.

The central monitor uses Function Inhibition Caller blocks and the GetFunctionPermission service to decide whether to account for measurements coming from each sensor. The central monitor has as many Get Permission blocks as there are sensors.

The FiM tab of the DIagnostic Service Component block configures the details of failure events. If a function is available, the FiM tab ID and mask settings control function inhibition. If a function is not available, GetFunctionPermission always returns false.

Configure Service Calls for Function Inhibition

As part of implementing function inhibition, you configure client calls to FiM-related service interfaces in your AUTOSAR software component. Here is an example of configuring client calls to query the status of function inhibition conditions.

Open a model that is configured for AUTOSAR code generation. This example uses example model autosar_bsw_fimmonitor, which is associated with the example Configure and Simulate AUTOSAR Function Inhibition Service Calls. Using the Library Browser or by typing block names in the model window, add FiM block Function Inhibition Caller to the model.
For the purposes of this example, connect the block outputs to Terminator blocks.
Open the new block and examine the parameters. For the FiM service call, the Client port name is FiM_FunctionInhibition and the Operation is GetFunctionPermission. The Operation parameter must be set to an operation supported by the schema currently specified by the model. The list of operations reflects the operations supported by the current schema. Set Sample time to 0.005, which matches the other GetFunctionPermission caller blocks in the model.
Open the Code Mappings editor. To update the Simulink^® to AUTOSAR mapping of the model with changes to Simulink function callers, click the Update button . The software creates AUTOSAR client-service interfaces, operations, and ports, and maps each Simulink function caller to an AUTOSAR client port and operation.
For example, for the Function Inhibition Caller block in this example, for which the GetFunctionPermission operation is selected:
- The software creates C-S interface FiM_FunctionInhibition, and under FiM_FunctionInhibition, its supported operation, GetFunctionPermission. Operation arguments are provided with read-only properties. In the AUTOSAR Dictionary, here are the arguments for the FiM_FunctionInhibition operation GetFunctionPermission.
- The software creates a client port with the default name FiM_FunctionInhibition. Unlike the C-S-interface, operation, and argument names, the client port name can be customized. The client port is mapped to the FiM_FunctionInhibition interface.
- The Code Mappings editor maps the Function Inhibition Caller function caller block to AUTOSAR client port FiM_FunctionInhibition and AUTOSAR operation GetFunctionPermission.

Optionally, build your component model and examine the generated C and ARXML code. The C code includes the client calls to the BSW services, for example:

  /* FunctionCaller: '<Root>/Function Inhibition Caller' */
  Rte_Call_FiM_FunctionInhibition_GetFunctionPermission
    (&rtb_FunctionInhibitionCaller_o1);

Generated RTE include files define the server operation call points, such as Rte_Call_FiM_FunctionInhibition_GetFunctionPermission.

The ARXML code defines the BSW service operations called by the component as server call points, for example:

<SERVER-CALL-POINTS>
    <SYNCHRONOUS-SERVER-CALL-POINT UUID="...">
        <SHORT-NAME>SC_FiM_Function_60fb8d34c7807f7b</SHORT-NAME>
        <OPERATION-IREF>
            <CONTEXT-R-PORT-REF DEST="R-PORT-PROTOTYPE">
             /ThrottlePositionMonitorCompo_pkg/ThrottlePositionMonitorCompo_swc
             /ThrottlePositionMonitor/FiM_FunctionInhibition
            </CONTEXT-R-PORT-REF>
            <TARGET-REQUIRED-OPERATION-REF DEST="CLIENT-SERVER-OPERATION">
             /AUTOSAR/Services/FiM/FiM_FunctionInhibition/GetFunctionPermission
            </TARGET-REQUIRED-OPERATION-REF>
        </OPERATION-IREF>
        <TIMEOUT>1.0E-06</TIMEOUT>
    </SYNCHRONOUS-SERVER-CALL-POINT>
    ...
</SERVER-CALL-POINTS>

To simulate the component model, create a containing composition, system, or test harness model. In that containing model, insert a reference implementation of the FiM GetFunctionPermission service operation.
The AUTOSAR Basic Software block library provides a Diagnostic Service Component block, which provides reference implementations of Dem and FiM service operations. You can manually insert the block into a containing composition, system, or harness model, or automatically insert the block by creating a Simulink Test™ harness model.
For more information, see Configure AUTOSAR Basic Software Service Implementations for Simulation.

Example Configure and Simulate AUTOSAR Function Inhibition Service Calls provides a set of example models, which together illustrate key aspects of implementing function inhibition, including:

Query the status of inhibition conditions (FunctionInhibition operation GetFunctionPermission).
Configure inhibition criteria based on event status (Diagnostic Service Component block dialog, RTE and FiM tabs).
Define operation cycles to scope failures to a time period (Dem OperationCycle operation SetOperationCycleState).