BMW SOME/IP

https://voib.tistory.com/2

 

 

글쓴이는 현재 유럽 OEM 관련 SOME/IP Project를 진행 중이며 진행 하면서 배운 것들을 정리 할 겸 글을 써 보았다.

(AUTOSAR 1.5.1 SOME/IP 규격 기반)

https://www.autosar.org/standards/foundation/

 

1. SOME/IP(Scalable service-Oriented MiddlewarE over IP) Overview

BMW 주도하에 Automotive 영역에서 Device(ECU)간 Ethernet 기반 Data 통신을 지원하기 위해 만들어진 Protocol이다.

 

SOME/IP 는 SOA(Service Oriented Architecture)기반으로 설계 된 Protocol이다.

각 기능이 Service별로 구별 되어 있으며,

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

 

2. SOME/IP 

Device 끼리 SOME/IP Protocol을 통해 Data를 주고 받는 것이 주 목적이다.

SOME/IP 관련 Header 가 존재하며 data 가 Serializatoin 된 Payload가 존재 한다.

Header 와 Payload는 Byte형태이다.

- SOME/IP Header

닫기

Service ID : 서비스 unique ID
Method ID : 0-32767(Method), 32768-65535 (Event)
Length : Payload length
Client ID : ECU 내의 unique ID=> 하나의 Service ID 안에 여러 Client 가 존재 할 수 있다.
Session ID : Session ID, SOME/IP 통신 마다 증가해야 하며, SOME/IP sequence를 구별 하기 위해 사용한다.
Protocol Version : 0x01 (현재 default 값은 1이다)
Interface Version : Service Interface의 Major 버전이다.

Message Type : 
-- REQUEST (0x00) Response를 기다리는 요청
-- REQUEST_NO_RETURN (0x01) A fire&forget 요청  
-- NOTIFICATION (0x02) Response 기대 없이 이벤트 형식의 data 만 전송
-- RESPONSE (0x80) Response message

Return Code :  
-- E_OK (0x00) 정상
-- E_NOT_OK (0x01) 비정상 return

-- E_UNKNOWN_SERVICE (0x02) Service 못 찾음

-- E_UNKNOWN_METHOD(0x03) Method 못 찾음

-- E_NOT_READY (0x04) Application 미 준비 상태

-- E_NOT_REACHABLE (0x05) System 이 비정상 상태

-- E_TIMEOUT (0x06) Timeout

-- E_WRONG_PROTOCOL_VERSION (0x07) Protocl version 불 일치

-- E_WRONG_INTERFACE_VERSION (0x08) Interface version 불 일치

-- E_MALFORMED_MESSAGE (0x09) 비정상 Packet 형태
-- E_WRONG_MESSAGE_TYPE (0x0a) Message Type 불 일치 
-- RESERVED (0x0b - 0x1f) 페이로드의 크기를 줄일 수 없도록 감도화 오류 
-- RESERVED (0x020 - 0x5e) 예상치 못한 메시지 유형 수신 (예를 들어 RE-QUEST_NO_RETURN)

 

- Payload Serialization

  규격 참고

보통 Protocol의 Header 및 Serilization 부분은 규격을 자세히 읽어 보는 것이 좋은것 같다.

그리고 직접 PCAP과 비교해보면서 보면 훨씬 이해가 빠를 것이다.

 

- Transport Protocol

SOME/IP 는 UDP 또는 TCP 기반으로 통신을 하게 된다. 

보통 Packet 크기 MTU 사이즈 이상 되게 되면 TCP를 사용하게 되며

현재는 Runtime 시점에 동적으로UDP <->TCP 전환 내용은 요구사항에 없다.

규격에서 제안 하는 Transprot Protocol 선택 가이드라인 

닫기

     #Use TCP only if very large chunks of data need to be transported (> 1400 Bytes) and no hard latency requirements in the case of errors exists

#Use UDP if very hard latency requirements (<100ms) in case of errors is needed

#Use UDP together with SOME/IP-TP if very large chunks of data need to be transported (> 1400 Bytes) and hard latency requirements in the case of errors exists

#Try using external transport or transfer mechanisms (Network File System, APIX link, 1722, ...) when they are more suited for the use case. In this case SOME/IP can transport a file handle or a comparable identifier. This gives the designer additional freedom (e.g. in regard to caching).

 

TCP 사용 시 중요한 것은 Nagle's Algorithm이 off 되야 된다는 것이다.

SOME/IP 중요성 중에 하나가 실시간 성이기 때문이다.

 

Consumer 와 Provider 간은 하나의 Connection을 기반으로 통신해야 한다.(TCP는 Heavy 한 Protocol 이며 TCP Connection은 최소화 해야 한다.)

 

UDP 기반으로 MTU 이상 Packet을 전송 하기 위해서는 SOME/IP-TP라는 것을 이용해 보내게 된다.

결국 Data를 Segment하며 Header에 offset 정보를 담아서 보내게 되는 형식이다.

 

- Communication 

규격에서 제안 하는 SOME/IP 통신 방법은 Request/Response(Method), Fire&Forget, Events, Field 총 4가지 이다.

아래 그림으로 충분히 설명이 가능 할 것이다.

 

- Error Handling

Error 발생 시 규격에서 제안 하는 방법은 총 2가지 존재한다.

• Return codes in the Response Messages of methods.
• Explicit Error Messgaes

Response Message의 Returen code에 Error code를 Returne 해주는 방법 과 Paload에 Error mesage(Message Type 0x81)을 담아서 보내는 방법이 있다.

후자는 Consumer Provider 간의 Error message 약속이 존재해야 한다.

글쓴이가 느끼기엔 Error Handling 관련 부분이 타 Protocol Spec(RFC, 3GPP) 대비 많이 부족한 부분인것 같다.

앞으로 많은 부분이 Update 될 것 같다.

 

3. SOME/IP Service Discovery(SOME/IP-SD)

각 Provider 와 Consumer는 시작 전 서로의 정보(Version, IP address, Port ...)들을 알고 있지 않는다.

SOME/IP Service Discovery라는 Step을 통해서 Provider 와 Consumer간 서로의 정보를 교환하게 된다.

 

경험상 SOME/IP-SD flow 다음과 같이 2가지가 존재 할 수 있다.

1) TTL 안에 OfferService가 오는 경우

2) TTL expired 된 후 FindService가 전송 되는 경우

Concept OfferService와 FindService를 통해 서로의 IP addres, Port 등등을 주고 받는 것이며,

주고 받은 정보 기반으로 SOME/IP 통신을 하게 된다.

 

SOME/IP-SD는 Mulitcast를 이용하기 때문에 무조건 UDP 를 사용해야 한다.

이와 관련된 자세한 내용을 알기 위해서는 규격의 StateMachine Diagram을 이해 하는 것이 좋다.

 

여기서 주의 할 것은 Subscribe는 Mandatory가 아니다, Event 혹의 Field의 Notication이 필요 없을 경우는 Subscription 과정을 생략 해도 된다.

1) TTL 안에 OfferService가 오는 경우	2) TTL expired 된 후 FindService가 전송 되는 경우

 

 

- Message format

SOME/IP의 Payload에 SOME/IP-SD Header와 Option이 위치하게 된다.

각 Header들은 규격을 읽어 보길 추천한다.

아래는 중요한 것들만 요약 하였다.

Type = SD Type

닫기

[0x00] = FindService

[0x01] = OfferService

[0x02] = RequestService
[0x03] = RequestServiceAck
[0x04] = FindEventgroup
[0x05] = PublishEventgroup
[0x06] = SubscribeEventgroup
[0x07] = SubscribeEventgroupAck

Index 1st options = option reference index

Service ID = Vehicle에서 Service Unique ID

Instance ID = Service 하위의 Instance ID 

TTL = OfferService lifetime,  Note : TTL Timer Expired 시 Client에서 FindService가 전송 됨

Type = option type, ( [0x06] = "IPv6 Endpoint Option”=>IPv6 사용)

IPv4/6 Address = SOME/IP 를 수신 받기 위한 Local IP

L4-Proto = Transport Layer Protocol, (0x06(TCP), 0x11(UDP))

Port Number = SOME/IP 를 수신 받기 위한 Port

 

- State Machine

가장 중요한 그림이다.

아래 그림만 이해 할 수 있으면 SOME/IP-SD 반은 이해 한다고 볼 수 있다.

머리속으로 상상해 가며 State Machine을 따라 가보 기를 권장한다.

Provider(Server)	Consumer(Client)