AutoSAR SOME/IP协议入门学习：4.2.1版本示例

需积分: 47 50 浏览量更新于2024-07-16 5 收藏 1.82MB PDF 举报

"AUTOSAR_TR_SomeIpExample_4.2.1.pdf 是一份关于AutoSAR中的Service Data Object over Ethernet (SOME/IP) 协议的初级学习资料，适用于车载网络环境。文档由AUTOSAR发布，版本4.2.1，包括了对SOME/IP序列化协议的示例介绍，涵盖了协议的更新历史和一些关键特性。" 在AutoSAR（AUTomotive Open System ARchitecture）架构中，SOME/IP（Service-Oriented MiddlewarE over IP）是一种关键的通信协议，它允许不同软件组件之间通过IP网络交换服务数据。这份文档提供了SOME/IP协议的基础知识，适合初学者入门学习。 SOME/IP协议的核心功能是提供服务导向的通信，使得软件组件可以跨ECU（电子控制单元）交换数据。其主要特点包括： 1. **服务发现（Service Discovery）**：SOME/IP-SD（Service Discovery）部分允许节点动态地发现网络上的可用服务，客户端可以找到并连接到相应的服务器。 2. **消息结构**：SOME/IP消息分为两种类型：请求(Request)和响应(Response)，以及单播(Unicast)和多播(Multicast)传输方式。这种设计支持异步和同步通信模式。 3. **错误处理**：文档中提到了扩展的错误处理机制，确保在通信过程中能有效识别和处理错误，如添加了SD Peer Identification以跟踪服务发现过程中的问题。 4. **位字段支持**：从4.1.3版本开始，SOME/IP增加了对位字段的支持，使得数据包能更灵活地表示和处理位级别的数据。 5. **客户端ID配置**：客户端ID可以在配置阶段进行设置，提供了更大的灵活性。 6. **SOME/IP-SD选项的应用**：定义了SOME/IP-SD选项对不同入口类型的有效性，确保正确配置和服务的兼容性。文档还详细介绍了如何序列化和反序列化SOME/IP消息，这是通信过程中的重要环节，确保数据在传输过程中的正确性。此外，文档中可能还包含了实际案例和示例代码，帮助读者更好地理解和应用SOME/IP协议。通过这份学习资料，读者将能够理解SOME/IP协议的基本原理，掌握其在车载网络中的应用，并具备基础的配置和实现能力。对于汽车电子系统开发者来说，深入理解SOME/IP有助于优化系统性能，提高通信效率和可靠性。

Example for a Serialization Protocol (SOME/IP)

AUTOSAR Release 4.2.1

[TR_SOMEIP_00024] d When using UDP as transport protocol SOME/IP messages

shall use up to 1416 Bytes for the SOME/IP header and payload, so that 1400 Bytes

are available for the payload. c()

The usage of TCP allows for larger streams of data to transport SOME/IP header

and payload. However, current transport protocols for CAN and FlexRay as well as

AUTOSAR limit messages to 4095 Bytes. When compatibility to those has to be

achieved, SOME/IP messages including the SOME/IP header shall not exceed 4095

Bytes.

[TR_SOMEIP_00026] d See also [TR_SOMEIP_00061] and [TR_SOMEIP_00139] for

payload length. c()

6.2.1.1.1 AUTOSAR restrictions

[TR_SOMEIP_00027] d See AUTOSAR SWS COM Chapter 7.6. c()

6.2.2 Endianess

[TR_SOMEIP_00028] d All RPC-Headers shall be encoded in network byte order (big

endian) [RFC 791]. The byte order of the parameters inside the payload shall be de-

ﬁned by the interface deﬁnition (i.e. FIBEX or ARXML) and shall be in network byte

order when possible and if no other byte order is speciﬁed. c()

[TR_SOMEIP_00029] d This means that Length and Type ﬁelds shall be always in

network byte order. c()

6.2.3 Header

[TR_SOMEIP_00030] d For interoperability reasons the header layout shall be identical

for all implementations of SOME/IP and is shown in the Figure 6.1. The ﬁelds are

presented in transmission order; i.e. the ﬁelds on the top left are transmitted ﬁrst. In

the following sections the different header ﬁelds and their usage is being described. c()

[TR_SOMEIP_00031] d

16 of 104

— AUTOSAR CONFIDENTIAL —

Document ID 637: AUTOSAR_TR_SomeIpExample

Example for a Serialization Protocol (SOME/IP)

AUTOSAR Release 4.2.1

6.2.3.4 Request ID [32 Bit]

[TR_SOMEIP_00043] d The Request ID allows a client to differentiate multiple calls

to the same method. Therefore, the Request ID has to be unique for a single client

and server combination only. When generating a response message, the server has to

copy the Request ID from the request to the response message. This allows the client

to map a response to the issued request even with more than one request outstanding.

c()

[TR_SOMEIP_00044] d Request IDs might be reused as soon as the response arrived

or is not expected to arrive anymore (timeout). In most automotive use cases a very low

number of outstanding requests are expected. For small systems without the possibility

of parallel requests, the Request ID might always set to the same value. c()

[TR_SOMEIP_00045] d For AUTOSAR systems the Request ID needs to be structured

as shown in the next section. Even for non-AUTOSAR systems it is required to encode

the callers Client ID as shown in the next section. c()

6.2.3.4.1 Structure of the Request ID

[TR_SOMEIP_00046] d In AUTOSAR the Request ID is constructed of the Client ID

and Session ID:

Client ID [16 Bits] Session ID [16 Bits]

c()

Note:

This means that the implementer of an ECU can deﬁne the Client-IDs as required by

his implementation and the Server does not need to know this layout or deﬁnitions

because he just copies the complete Request-ID in the response.

[TR_SOMEIP_00047] d The Client ID is the unique identiﬁer for the calling client inside

the ECU. The Session ID is a unique identiﬁer chosen by the client for each call. If

session handling is not used, the Session ID shall be set to 0x0000. c()

[TR_SOMEIP_00532] d The Client ID shall also support being unique in the over-

all vehicle by having a conﬁgurable preﬁx or ﬁxed value (e.g. the most signiﬁcant

byte of Client ID being the diagnostics address or a conﬁgured Client ID for a given

application/SW-C). c()

For example:

Client ID Preﬁx

[8 Bits]

Client ID [8 Bits] Session ID [16 Bits]

19 of 104

— AUTOSAR CONFIDENTIAL —

Document ID 637: AUTOSAR_TR_SomeIpExample

剩余103页未读，继续阅读

cook_fish

粉丝: 4
资源: 1

AutoSAR SOME/IP协议入门学习：4.2.1版本示例

车载以太网SOMEIP服务发现协议规范AUTOSAR_SWS_ServiceDiscovery_4.2.1.pdf

AUTOSAR_TR_SomeIpExample.pdf

SOME/IP Protocol Specification

AUTOSAR_TR_FrancaIntegration.pdf

AUTOSAR_TR_FoundationReleaseOverview.pdf

AUTOSAR_TR_Glossary.pdf

AUTOSAR_TR_BSWModuleList.pdf

AUTOSAR_TR_PredefinedNames.pdf

AUTOSAR_TR_AdaptivePlatformReleaseOverview.pdf

AUTOSAR_TR_GeneralBlueprintsSupplement.pdf

最新资源