SNIP_CLASSIC_STD_SECTION_5_6_10_Rte_Read

5.6.10 Rte_Read Purpose: Performs an “explicit” read on a sender-receiver communication data element with “data” semantics (swImplPolicy != queued). By compatibility, the port may also have a ParameterInterface or a NvDataInterface. The Rte_Read API is used for explicit read by argument. Signature: [SWS_Rte_01091] Upstream requirements: SRS_BSW_00310, SRS_Rte_00141, SRS_Rte_- 00028, SRS_Rte_00131 ⌈ If returnValueProvision of the related dataReceivePointByArgument(s) is not set to noReturnValueProvided: Std_ReturnType Rte_[Byps_]Read_<p>_<o>( [IN Rte_Instance <instance>], [IN/OUT|OUT] <data>, [OUT Rte_ComErrorInfo* comErrorInfo], [OUT Std_TransformerError transformerError], [OUT uint8* metaDataPtr]) If returnValueProvision of the related dataReceivePointByArgument(s) is set to noReturnValueProvided: void Rte_[Byps_]Read_<p>_<o>( [IN Rte_Instance <instance>], [IN/OUT|OUT] <data>, [OUT Rte_ComErrorInfo* comErrorInfo], [OUT Std_TransformerError transformerError], [OUT uint8* metaDataPtr]) Where <p> is the port name and <o> the VariableDataPrototype within the sender-receiver interface categorizing the port. [Byps_] is an optional infix used when component wrapper method for bypass support is enabled for the related software component type.⌋ Existence: [SWS_Rte_01289] Upstream requirements: SRS_Rte_00051 ⌈A non-blocking Rte_Read API shall be generated if a VariableAccess in the dataReceivePointByArgument role references a required VariableDataPrototype with ‘data’ semantics.⌋ A WaitPoint cannot reference a DataReceivedEvent that in turn references a required VariableDataPrototype with ‘data’ semantics shall be considered an invalid configuration (see [SWS_Rte_03018]). Hence there are no blocking Rte_Read API. [SWS_Rte_CONSTR_09021] Rte_Read API may only be used by the runnable that describe its usage ⌈The Rte_Read API may only be used by the runnable that contains the corresponding VariableAccess in the dataReceivePointByArgument role⌋ [SWS_Rte_01313] Upstream requirements: SRS_Rte_00051, SRS_Rte_00018 ⌈A DataReceivedEvent that references a runnable entity and is referenced by a WaitPoint shall be an invalid configuration.⌋ The RTE generator shall take into account the kind of provide port which might not be just a variable but also a Parameter (fixed, const or standard), a standard sender (i.e. a variable) or a NV data. The table 4.5 gives an overview of compatibility rules. [SWS_Rte_08563] Upstream requirements: SRS_Rte_00249 ⌈The optional OUT parameter transformerError of the API shall be generated if the PortPrototype of port <p> is referenced by a PortAPIOption which has the attribute errorHandling set to transformerErrorHandling.⌋ [SWS_Rte_04682] Existence of OUT parameter comErrorInfo ⌈The optional OUT parameter Rte_ComErrorInfo of the API shall be generated if the one of the following attributes is defined for the PortPrototype <p>: • transportErrorCountEnabled. • valueErrorCountEnabled. ⌋ The optional OUT parameter metaDataPtr contains a pointer to the meta data byte array which is to be forwarded from COM. See [SWS_Rte_03620]. Description: The Rte_Read API call includes the IN/OUT|OUT parameter <data> to pass back the received data. For each ImplementationDataTypeElement of <data> where an arrayImplPolicy is set to payloadAsPointerToArray, the SWC has to allocate an array of sufficient size and set the respective pointer to it. In that case, <data> is treated as an IN/OUT parameter, otherwise its direction is OUT. If an Rte_Read API is called before any reception of data has occurred then the rules for returning initial values as outlined in section 4.3.1.3.1 apply for the <data> parameter. Note that if no initial value is provided the API may return undefined values if no data has been received. The pointer to the IN/OUT|OUT parameter <data> must remain valid until the API call returns. This also applies to all sub elements of a Structure Implementation Data Type or Union Implementation Data Type that are pointers (e.g. due to payloadAsPointerToArray). The OUT parameter transformerError contains the transformer error which occured during execution of the transformer chain. See chapter 4.10.5. The OUT parameter Rte_ComErrorInfo is a structure that contains the data and transport error counts. See chapter 4.3.9 Return Value: None in case returnValueProvision of the related dataReceivePointByArgument(s) is set to noReturnValueProvided. Otherwise, the return value is used to indicate errors detected by the RTE during execution of the Rte_Read API call or errors detected by the communication system. • [SWS_Rte_01093] Upstream requirements: SRS_Rte_00094 ⌈RTE_E_OK – data read successfully.⌋ • [SWS_Rte_02626] Upstream requirements: SRS_Rte_00078 ⌈RTE_E_INVALID – data element invalid.⌋ • [SWS_Rte_02703] Upstream requirements: SRS_Rte_00147 ⌈RTE_E_MAX_AGE_EXCEEDED – data element outdated. This Overlayed Error can be combined with any other error code.⌋ • [SWS_Rte_07643] Upstream requirements: SRS_Rte_00184 ⌈RTE_E_NEVER_RECEIVED – No data received since system start.⌋ • [SWS_Rte_01371] Upstream requirements: SRS_Rte_00180 ⌈RTE_E_OUT_OF_RANGE – data element out of range.⌋ • [SWS_Rte_01391] Upstream requirements: SRS_Rte_00246 ⌈RTE_E_COM_BUSY – The read request is rejected due to a currently ongoing reception. No received data can be provided.⌋ Note: API call can be retried after the currently ongoing request has finished. • [SWS_Rte_06830] Upstream requirements: SRS_Rte_00094 ⌈RTE_E_COM_STOPPED – The RTE could not perform the operation because the COM service is currently not available (inter ECU communication only). RTE shall return RTE_E_COM_STOPPED when the corresponding COM service returns COM_SERVICE_NOT_AVAILABLE. In case of stopped I-PDUS the last known value (or init value) is given back as data.⌋