SOME/IP Protocol

Overview

SOME/IP는 네트워크를 통한 Service 지향 통신으로 Service 리스트로 구성되어 있다.

각 Service는 Service를 제공하는 Provider(Server)와 Service를 이용하는 Consumer(Client)로 구분되어 있다.

 

Service

• Events: Server가 Client(subscriber)한테 주기적또는 변경되었을 때 보내는 데이터이다.
• Methods: Client가 Server에 있는 프로그램을 실행시킬 수 있도록 한다.
• Fields는 아래 3개 내용 중에 하나 이상이 들어간다.
  • notifier: 설정에 따라 값이 업데이트되었을 때 Subscriber에게 데이터를 전송한다. Event는 변경 시에만 보내고, notifier는 등록 직후에도 데이터를 보낸다.
  • getter: 특정 값을 server에게 요청할 수 있는 메시지
  • setter: 특정 값을 변경하고 싶을 때 server에 요청할 수 있는 메시지

 

메시지 포맷

Header

 

Message ID (Service ID / Method ID) [32 bit]

Application 함수를 호출하기 위한 PRC(Remote Procedure Call)나 event를 식별하기 위해 사용되고 Service ID와 Method ID를 함께 사용한다.

• Service ID [16 bit]
• Method ID [16 bit]
  • Methods: 0x0000 ~ 0x7FFF
  • Events/Notifications: 0x8000 ~ 0x8FFF

 

 

Length [32 bit]

Request ID 부터의 메시지 끝까지의 길이를 나타낸다.

 

Request ID (Client ID / Session ID) [32 bit]

Server와 Client가 사용하는 동일한 methods, getter, setter의 구분하기 위해 사용한다.

Request-Response가 한 쌍이 되어 여러 번 호출되기 때문에 고유한 값을 사용한다. Response 메시지를 생성할 때는 Request 메시지에 있는 Request ID를 복사하여 사용하기 때문에, Client가 여러 Request 메시지를 생성하여Response 메시지를 수신하더라도 구분할 수 있다.

Request ID는 절대 재사용 하면 안된다. 응답이 도착했거나, timeout이 발생했을 경우 재사용된다.

 

Session ID를 사용하지 않을 시 0x00, 사용시 0x0001 ~ 0xFFFF 범위 값을 사용한다. Seesion ID는 0x0001에서 시작하며 통신할 때마다 증가하며, 0xFFFF에 도달하면 0x0001부터 다시 시작한다.

 

Protocol Version [8 bit]

프로토콜 버전 (Default: 0x01)

 

Interface Version [8 bit]

주요 Service 인터페이스 버전

 

Message Type [8 bit]

메시지 타입을 분류하기 위한 값

Number	Value	Description
0x00	REQUEST	response를 보내야 하는 요청
0x01	REQUEST_NO_RETURN	fire&forget 통신 요청
0x02	NOTIFICATION	notification/event callback 요청
0x80	RESPONSE	response 메시지
0x81	ERROR	error 값이 있는 response 메시지
0x20	TP_REQUEST	TP 방식에 대한 메시지 기능은 위와 동일
0x21	TP_REQUEST_NO_RETURN
0x22	TP_NOTIFICATION
0xa0	TP_RESPONSE
0xa1	TP_ERROR

 

 

Return Code [8 bit]

요청이 성공적으로 처리 되었는지 확인하기 위한 값

Return Codes for specific Message Types
Message Type	Allowed Return codes
REQEUST	Not Use -> N/A set to 0x00
REQUEST_NO_RETURN
NOTIFICATION
RESPONSE	Return Codes
ERROR	0x00이 아닌 다른 Return Codes 값

 

Return Codes
Message Type	Allowed Return codes	Description
0x00	E_OK	오류 없음
0x01	E_NOT_OK	정의 되지 않은 오류
0x02	E_UNKNOWN_SERVICE	알 수 없는 Service ID를 요청할 때
0x03	E_UNKNOWN_METHOD	Service ID는 알지만, Method ID는 알 수 없을 때
0x04	E_NOT_READY	Service ID, Method ID는 알지만, Application이 작동 중이 아닐 때
0x05	E_NOT_REACHABLE	Service를 실행하는 시스템에 연결 할 수 없을 때
0x06	E_TIMEOUT	타임 아웃 발생했을 때
0x07	E_WRONG_PROTOCOL_VERSION	지원되지 않는 protocol 버전을 사용할 때
0x08	E_WRONG_INTERFACE_VERSION	interface 버전이 일치하지 않을 때
0x09	E_MALFORMED_MESSAGE	payload 데이터를 deserialization (재구 조화)할 수 없을 때
0x0a	E_WRONG_MESSAGE_TYPE	예상치 못한 메시지 타입을 수신 했을 때
0x0b	E_E2E_REPEATED	반복되는 E2E 계산 오류
0x0c	E_E2E_WRONG_SEQUENCE	잘못된 E2E 시퀀스 오류
0x0d	E_E2E	지정되지 않은 E2E 오류
0x0e	E_E2E_NOT_AVAILABLE	E2E를 사용할 수 없을 때
0x0f	E_E2E_NOT_NEW_DATA	E2E 계산을 위한 새로운 데이터가 없 을 때
0x10 - 0x1f	RESERVED	이후 버전에 대한 오류
0x20 - 0x5e	RESERVED	service 및 method에 대한 오류

 

 

Payload

Payload의 데이터들은 serialization 되어 있으며, Payload의 크기는 프로토콜(UDP, TCP)에 따라 다르다.

• UDP: 0 - 1400 Bytes의 제한이 있다.
• TCP: TCP segment로 인해 큰 사이즈의 Payload를 사용할 수 있다.

 

 

Endian 처리

Header와 아래 fields의 값들은 big endian를 따른다.

 

 

Serialization of Data Structure

• Payload의 데이터는 직렬화되어 들어간다. 따라서 데이터를 넣을 때 위치를 고려하여 정렬해야 한다.
• 각 데이터가 특정 메모리 주소에서 시작할 수 있도록 패딩을 요소를 넣어 정렬한다.
• 아래 예와 같이 32비트의 배수로 데이터가 시작하도록 패딩을 넣어 정렬한다.

 

 

통신 종류

SOME/IP는 UDP(User Datagram Protocol)와 TCP(Transmission control Protocol)모두 사용가능하다. 보내야하는 상황에 따라 UDP나 TCP를 선택해서 보내게 된다.

한 패킷에 두개 이상의 SOME/IP 메시지를 전송할 수 있다. 따라서 Header의 length 값을 통해 SOME/IP를 구분한 후 추가 메시지가 있는지 확인해야 한다.

• 데이터가 1400 Bytes보다 크면 TCP를 사용한다.
• 100ms 이하의 high latency가 필요로 할 경우 UDP를 사용한다.
• 데이터가 1400 Bytes보다 크고, high latency가 필요한 상황에서는 UDP와 SOME/IP-TP를 같이 사용한다.
• 사용자에 따라 더 적합한 외부 통신이나 여러 다른 통신 방법을(Network File System, APIX link, 1722, …) 사용하기도 한다.

 

1. Request/Response Communication

가장 일반적인 통신 패턴이다. Client가 request message를 보내고, Server가 응답하는 방식이다.

Request/Response

 

 

2. Fire & Forget Communication

Response가 없는 Request 방식이다.

Fire & Forget

 

 

3. Notification Events

Publish/Subscribe 컨셉을 가진다. Server가 자신을 등록한 Client에게 service를 보내는 방식이다. 업데이트된 값이 있거나 event가 발생했을 경우 Client에게 보내게된다.

Notification

3-1. Strategy for sending notifications

사용 방법에 따라 notification를 보내는 방법을 달리할 수 있다.

• Cyclic update: 주기적으로 업데이트된 값을 보내는 방법
• Update on change: 값이 업데이트 되면 보내는 방법
• Epsilon change: 업데이트된 값의 차이가 특정 값(epsilon)보다 클 때 보내는 방법

 

4. Fields

field는 status(상태)를 나타내며, valid value(유효 값)을 가지고 Client는 field를 등록하면 field의 값을 initial event로 받는다. field는 getter, setter, notification event로 구성된다.

• getter: request 메시지에는 empty payload를 가지고 있으며, response 메시지에 field 값이 포함되어 있다.
• setter: response 메시지에는 변경하고 싶은 field 값이 포함되어 있으며, response 메시지에 field에 설정된 값이 포함되어 있다.
• notifier :  Client가 field를 등록하면 해당 field의 값을 보내는 Event 메시지를 생성한다. Notification Event와 같은 전송 방법을 사용한다.

Fields

 

에러 처리 방법

에러 처리는 아래 두 방법 중에 사용된다.

• methods의 response 메시지안에 Return Codes를 넣는 방법
• Explicit Error Messages

Explicit Error Message는 application 오류, reponse data 오류, 일반적인 SOME/IP 오류가 발생했을 때 Server가 Client한테 보낼 때 사용된다. 오류 정보를 payload에 추가하여 보낼 수 있다.

 

Return Code

response 메시지안에 Return Codes를 넣는 방법은 Server가 Client한테 보낼 때 사용된다. Return Code는 메시지 타입이 0x80, 0x81일 경우에만 사용한다. Return Code가 0x01 - 0x1f 일 경우는 Error 메시지를 함께 사용하지 않아도 된다.

 

Error Message

유연한 오류 처리를 위해 아래 값들을 사용할 수 있다. (Server와 Clint 간의 약속이 있어야 한다.)

• Union
• 예외 설명을 위한 문자열

 

Error Processing Overview

 

 

참고자료

https://www.autosar.org/fileadmin/standards/R22-11/FO/AUTOSAR_PRS_SOMEIPProtocol.pdf

https://some-ip.com/papers/cache/AUTOSAR_TR_SomeIpExample_4.2.1.pdf