Search code examples
autosar

What is the range of `out` variable in a call to Rte_Read?

Assuming I have a call to the Rte_Read function of some element, I'm trying to understand what are the possibles the ranges of the out variable after this call, depending on the various constraints. I'm assuming that the return value of the call is always RTE_E_OK and no compuMethod.

If the associated ApplicationDataType of the variable has only a physical constraint, with lowerLimit = 0 and upperLimit = 10, no constraint on the associated ImplementationDataType and a base type of uint16. Is the possible range for the out parameter [0-10] or [0-65535] ?

If the associated ApplicationDataType of the variable has an internal constraint, with lowerLimit = 0 and upperLimit = 10, no constraint on the associated ImplementationDataType and a base type of uint16. Is the possible range for the out parameter [0-10] or [0-65535] ?

From my understanding of AUTOSAR_TPS_SoftwareComponentTemplate 5.2.4, the constraints of the ImplementationDataTypes should always override (and be larger) the constraints of the ApplicationDataTypes. Is it correct?

Solution

  • First of all, you would have to check about the supported RTE features of your Vendor.

    In the AUTOSAR_SWS_RTE.pdf, there is the Return Value part of Rte_Read API, and there a link at the RTE_E_INVALID and RTE_E_OUT_OF_RANGE. When you follow this, you come to chapter 4.3.8 Range Checks during Runtime.

    4.3.8 Range Checks during Runtime

    A software component might try to send a value that is outside the range that is specified at a dataElement or ISignal. In case of different ranges the result of a data conversion might also be a value that is out of range of the target representation. For a safe handling of these use cases the RTE provides range checks during runtime. For an overview see figure 4.46.

    [SWS_Rte_08024] Range checks during runtime shall occur after data invalidation, i.e. first the handleNeverReceived check, then the invalidation check and lastly the range check shall be effected.c(SRS_Rte_00180)

    ...

    Range checks at receiver’s side

    Range checks during runtime for intra ECU communication at the receiver’s side are described in the following requirements:

    [SWS_Rte_08028] dThe RTE shall implement a range check in the receiving path of a particular component if the handleOutOfRange is defined at the ReceiverComSpec and has any value other than none. In this case the range check applies only for data received by the particular component. c(SRS_Rte_00180)

    [SWS_Rte_08041] dThe RTE shall use the preceding limits ([SWS_Rte_07196]) from the DataPrototype in the rPort for the range check of received data in the receiving path of a particular component if the handleOutOfRange is defined at the ReceiverComSpec.c(SRS_Rte_00180)

    Here it also refers to SWS_Rte_07196 which specifies the precedence of the usage of DataConstrs (upper/lowerLimits).

    Depending on the ReceiverComSpec's handleOutOfRange and handleOutOfRangeStatus it depends if you get out data with:

    • last valid value
    • no value
    • saturated value (== upperLimit or lowerLimit)
    • initValue or invalidValue

    and you get either RTE_E_OUT_OF_RANGE or RTE_E_INVALID as return/error value.

    The precedence requirement in ch 4.1.3 is as following:

    [SWS_Rte_07196] dThe RTE Generator shall respect the precedence of data properties defined via SwDataDefProps as defined in the Software Component Template [2].c()

    Requirement [SWS_Rte_07196] means that:

    1. SwDataDefProps defined on ApplicationDataType which may be overwritten by
    2. SwDataDefProps defined on ImplementationDataType which may be overwritten by
    3. SwDataDefProps defined on AutosarDataPrototype which may be overwritten by
    4. SwDataDefProps defined on InstantiationDataDefProps which may be overwritten by
    5. SwDataDefProps defined on AccessPoint respectively Argument which may be overwritten by
    6. SwDataDefProps defined on FlatInstanceDescriptor which may be overwritten by
    7. SwDataDefProps defined on McDataInstance

    The SwDataDefProps defined on McDataInstance are not relevant for the RTE generation but rather the documentation of the generated RTE.

    Especially the attributes swAddrMethod, swCalibrationAccess, swImplPolicy and dataConstr do have an impact on the generated RTE. In the following document only the attribute names are mentioned with the semantic that this refers to the most significant one.

    That means, if your ApplicationDataType has a DataConstr, but your ImplementationDataType has not, and also the following do not have it, then the ApplicationDataType DataConstr limits are used for the check. I read this as:

    • if ApplicationDataType DataConstr = [0, 10] and
    • if ImplememtationDataType DataConstr = (unset) and
    • even the ImplementationDataType = uint16 with range [0,65535]

    the range check will be done with [0,10].