SomeIpTp (SOME/IP Transport Protocol)

Introduction

The SomeIpTp module based on AUTOSAR SOME/IP Transport Protocol provides the following services :

• Segments SOME/IP packets which do not fit into one single UDP packet.
• Reassembles the received SOME/IP segments.
• Detection of errors during segmentation and reassembly.

Architecture Overview

The following figure shows where the SomeIpTp is located in the AUTOSAR architecture.

The next figure shows the interfaces to adjacent modules of the SomeIpTp. These interfaces are described in chapter 5.

Functional Description

Features

The features listed in the following tables cover the complete functionality specified for the SomeIpTp.

The AUTOSAR standard functionality is specified in [1], the corresponding features are listed in the tables

• Table 3-1 Supported AUTOSAR standard conform features
• Table 3-2 Not supported AUTOSAR standard conform features

Vector Informatik provides further SomeIpTp functionality beyond the AUTOSAR standard. The corresponding features are listed in the table

• Table 3-3 Features provided beyond the AUTOSAR standard

The following features specified in [1] are supported:

Deviations

The following features specified in [1] are not supported:

Additions/ Extensions

The following features are provided beyond the AUTOSAR standard:

Transmit Queue

If several TX SDUs are requested by the upper layer, they will be added to a queue. Supervision of timeouts and transmission of further segments of these SDUs is based on the order of elements stored in the Queue.

Monitoring Transmission Confirmation timeout

To be compatible with the other modules, SomeIpTp_TxConfirmation() is implemented only with the parameter TxPduId. Since negative TX Confirmation is currently not supported, if there is no call to SomeIpTp_TxConfirmation() within a specified time, the segmentation process for the corresponding TX SDU is aborted.

In the Vector SomeIpTp, this timeout is configurable by the parameter SomeIpTpTxConfirmationTimeoutTime per SomeIpTpChannel.

Initialization

The API SomeIpTp_Init() uses the given configuration set to initialize all global variables of SomeIpTp and brings each SDU to state Idle, where segmentation and reassembly can be started.

States

After initialization, all the TX and RX SDUs are set to Idle (SOMEIPTP_TX_STATUS_IDLE, SOMEIPTP_RX_STATUS_IDLE). Segmentation or reassembly is possible only in this state.

During the segmentation process, the TX SDU state is either wait for confirmation (SOMEIPTP_TX_STATUS_WAIT_TXCONF_SF) or wait for separation time (SOMEIPTP_TX_STATUS_WAIT_ST).The state is reset to Idle if the disassembly process is aborted or is finished.

During the reassembly process, the RX SDU state is set to wait for next segment (SOMEIPTP_RX_STATUS_WAIT_NEXT_SF).The state is reset to Idle after the complete frame is received or reassembly process is interrupted.

Main Functions

The functions SomeIpTp_MainfunctionTx()and SomeIpTp_MainfunctionRx() perform all the tasks that should be done cyclically.

The timing parameters like SomeIpTpSeparationTime and SomeIpTpRxTimeoutTime are calculated based on the configured SomeIpTpTxMainfunctionPeriod and SomeIpTpRxMainfunctionPeriod respectively.

Error Handling

Development Error Reporting

By default, development errors are reported to the DET using the service Det_ReportError() as specified in [2], if development error reporting is enabled (i.e. precompile parameter SOMEIPTP_DEV_ERROR_DETECT==STD_ON).

If another module is used for development error reporting, the function prototype for reporting the error can be configured by the integrator, but must have the same signature as the service Det_ReportError().

The reported SomeIpTp ID is 177.

The reported service IDs identify the services which are described in 5.1. The following table presents the service IDs and the related services:

The errors reported to DET are described in the following table:

Runtime Error Reporting

By default, Runtime related errors are reported to the to the DET using the service Det_ReportRuntimeError() as specified in [2], if runtime error reporting is enabled (i.e. pre-compile parameter SOMEIPTP_RUNTIME_ERROR_REPORT==STD_ON).

If another module is used for runtime error reporting, the function prototype for reporting the error can be configured by the integrator, but must have the same signature as the service Det_ReportRuntimeError().

The runtime errors reported to DET are described in the following table:

References

MICROSAR SOME/IP Transport Protocol Technical Reference (Version 1.0.1)