SOME/IP?
SOME/IP(Scalable service-Oriented MiddlewarE over IP)는 Ethernet을 통해 제어 명령을 주고받을 수 있도록 고안된 차량 환경용 미들웨어입니다. 최근 주행 보조 기술과 자율주행 기술이 점점 발전함에 따라, 기존에 차량용 제어기 간 네트워크 통신에 주로 사용되었던 CAN과 같은 통신 방식으로는 점점 늘어가는 통신량을 감당하기 힘들어졌습니다. 이에, 대용량 데이터의 고속 송수신에 적합한 Ethernet과 IP를 이용하는 SOME/IP라는 프로토콜이 제안되었습니다. 특히, AUTOSAR AP(Adaptive Platform)의 애플리케이션 간 통신을 담당하는 미들웨어인 ara::com이 기본적으로 SOME/IP를 사용하는 것으로 정의되어 있어, 앞으로 더욱 널리 쓰이게 될 차량 제어기용 통신 기술이 될 것으로 보입니다.
SOME/IP 프로토콜의 특징은 그 이름에 아주 잘 드러나 있습니다. SOME/IP의 풀 네임을 통해 그 특징을 알아봅시다.
Scalable
SOME/IP는 동적인 구성으로 초소형 플랫폼에서부터 대형 플랫폼에까지 모두 적용이 가능합니다.
'동적 구성'에 대해 더 알아보기 위해, CAN의 경우를 살펴봅시다.
CAN에서는 CAN Bus 상에서 ECU의 ID가 정적으로 할당되어 있습니다. 즉, 어떤 ECU A가 CAN 네트워크 상에서 특정한 기능 F를 담당하는 다른 ECU B를 찾고자 한다면, 개발 시점에서부터 ECU B가 특정되어 있어야 합니다. 이 경우, 기능 F를 담당하는 ECU가 ECU C로 변경되거나, 기능 F가 비대해져 ECU B, C, D를 비롯한 여러 ECU에서 분산 처리하게 될 경우, ECU A는 소스 코드의 대대적인 변경 없이는 이를 제대로 처리하지 못할 것입니다.
이와 반대로, SOME/IP에서는 기능 F를 담당하는 ECU가 B라는 것을 A는 처음에는 모르고 있습니다. 하지만 뒤에 설명할 SOME/IP-SD를 이용하여, A는 F를 담당하는 ECU가 B라는 것을 인식할 수 있습니다. 만약 F를 담당하는 ECU가 C로 변경되더라도, A는 역할의 변경을 동적으로 인지할 수 있을 것입니다.
service-Oriented
SOME/IP는 Service-Oriented(서비스 지향) 통신 방식을 적용하였습니다. Service-oriented는 기존의 signal-based 통신 방식과 비교되는 방식으로, 기존 방식이 CAN, LIN, FlexRay와 같이 통신 매체를 통하여 전달되는 메시지 내용 그 자체에 초점을 두는 방식이었다면, Service-oriented 방식은 네트워크의 각 인스턴스가 서비스를 제공하는 Server와 서비스를 제공받는 Client로 구분되어, 이들이 사용하는 서비스를 중심으로 통신이 구성됩니다.
MiddlewarE
미들웨어란, 두 시스템을 연결하여 서로 데이터 통신 및 관리가 가능하도록 하는 소프트웨어 및 서비스
를 의미합니다. SOME/IP는 차량 제어기 내부의 각 인스턴스, 또는 서로 다른 제어기 사이의 연결을 높은 호환성 레벨로 구현하는 것을 목표로 합니다.
over IP
SOME/IP는 위 그림과 같이 OSI 7계층의 5~7계층에 해당하며, Ethernet, IP, 그리고 TCP/UDP 프로토콜 상위에 구성됩니다. 따라서, 기존에 차량용 제어기 네트워크로 주로 사용되었던 CAN 등과 비교하였을 때, SOME/IP는 자율주행 시스템의 도입에 따라 발생하는 대용량의 데이터를 더 빠른 속도로 전송할 수 있는 능력을 확보할 수 있었습니다.
SOME/IP-SD
SOME/IP는 service-oriented 통신 방식을 사용한다고 하였습니다. 이를 실제로 적용하기 위해서는, (Server의 입장에서) 내가 가지고 있는 서비스를 필요로 하는 곳이 있는지, 그리고 (Client의 입장에서) 내가 필요로 하는 서비스를 가지고 있는 곳이 있는지를 먼저 찾아야 합니다. 이 작업을 해 주는 프로토콜이 바로 SOME/IP-SD(Service Discovery)입니다. SOME/IP-SD의 존재로 인해, 네트워크의 각 인스턴스는 자신의 서비스를 필요로 하는, 혹은 자신이 필요한 서비스를 가지고 있는 인스턴스를 동적으로 탐색하고 연결할 수 있습니다. 즉, 개발자는 자신이 만들고 있는 서비스가 어디에서 쓰이는지, 또는 자신이 만들고 있는 모듈이 필요로 하는 서비스가 어디에 위치하는지를 개발 단계에서는 신경쓰지 않아도 된다는 의미입니다.
SOME/IP-SD는 위 그림과 같이 SOME/IP 프로토콜보다 상위 계층에 정의되어 있습니다. 즉, SOME/IP-SD의 메시지 내용은 SOME/IP 메시지의 payload에 실리게 됩니다. SOME/IP-SD는 UDP 멀티캐스트를 이용하여, 같은 멀티캐스트 그룹 내에 있는 모든 노드에 메시지를 전달합니다.
SOME/IP Behaviors
본격적으로 SOME/IP의 동작을 알아봅시다.
SOME/IP-SD Behaviors
SOME/IP로 통신을 수행하려면, 먼저 네트워크의 서비스 제공자(Server)와 서비스 사용자(Client)가 네트워크 상에서 서로의 존재를 인식해야 합니다. 이는 SOME/IP-SD의 FindService와 OfferService 메시지로 이루어집니다. 애플리케이션이 서비스를 제공받을, 또는 제공할 준비가 되었다면, UDP 멀티캐스트에 SOME/IP-SD 프로토콜을 이용하여 FindService, OfferService 메시지를 송신합니다. 당연히 서비스를 제공받는 쪽이 보내는 메시지가 FindService, 서비스를 제공하는 쪽이 보내는 메시지가 OfferService가 되겠죠. 이 메시지에는 자신이 필요로 하는, 또는 제공하는 서비스의 ID와, 송신자의 IPv4 주소 등의 정보가 담기게 됩니다.
Client 측에서 내가 찾고 있는 서비스의 ID와 같은 ID를 가진 OfferService 메시지를 수신하면, 클라이언트는 해당 서비스의 정보와 서비스를 제공하는 Server의 주소 등 필요한 정보를 저장합니다.
FindService와 OfferService가 매칭되면, Client에서는 Service가 제공하는 여러 Event 중 어떤 것을 받아올지 결정합니다. 이를 Eventgroup Subscribe 과정이라고 합니다. Event의 Subscribe는 항상 Eventgroup 단위로 이루어집니다. 그래서, 만약 하나의 Service에서 Subscribe하려는 Event가 하나밖에 없다고 할지라도 Server는 그 Event를 Eventgroup으로 묶어서 제공하여야 합니다.
Server 측에서 Subscribe 메시지를 수신하면 Server는 해당 Eventgroup의 개체들이 유효한 것인지 확인합니다. 확인이 완료되면, Server는 Client에 SubscribeAck로 응답합니다.
위의 그림에서, 점선 윗부분이 SOME/IP-SD에서 진행되는 과정입니다. 아래쪽에 있는 Event와 Request/Respond에 대해서는 뒤에서 계속 설명을 진행하도록 하겠습니다.
이제 준비가 완료되었습니다. Client는 SOME/IP를 통해 Server가 제공하는 Event / Method call / Field와 같은 서비스 기능을 사용할 수 있습니다.
SOME/IP Service Implementation
What is Service?
지금까지의 내용을 살펴보면, '서비스'라는 개념을 상당히 중요하게 다루고 있음을 확인할 수 있습니다. 지금까지는 서비스라는 용어를 '네트워크 상에서 애플리케이션이 제공하는 기능' 정도의 두루뭉실한 의미로 사용하였는데, 이제는 공식 문서를 참조하여 엄밀하게 정의해 보도록 하겠습니다.
Service (서비스): 0개 혹은 그 이상의 Method(메소드), Event(이벤트), 그리고 Field(필드)의 논리적 조합
3개의 새로운 용어 Method, Event, 그리고 Field가 등장하였습니다. 이 용어들의 정의 역시 찾아보도록 합시다.
Method (메소드): 호출(call/invoke)되는 메소드, 프로시저, 함수 또는 서브루틴
Event (이벤트): 주기적으로 혹은 값의 변화가 있을 때에만 이루어지는 단방향 데이터 전송.
Field (필드): 상태를 나타내는 값. notifier, getter, setter가 동작하는 동안 항상 유효한 값을 가짐.
이번에도 Notifier, Getter, Setter라는 3개의 새로운 용어가 등장하였습니다. 이 용어들은 나중에 Field에 대해 알아볼 때 더 자세히 살펴보도록 하겠습니다.
위와 같이, Service의 정확한 정의에 대해 탐색해 보았습니다. 정리하자면, Service는 Event / Method / Field의 조합에 의해 논리적으로 정의되는 추상적인 개념임을 알 수 있습니다. 즉, Event, Method, 그리고 Field의 동작을 살펴보면, SOME/IP Service의 동작에 대해 알 수 있을 것입니다.
Event
먼저, Event에 대해 살펴봅시다. 위에서 Event는 주기적으로, 혹은 값의 변화가 있을 때에만 이루어지는 단방향 데이터 전송이라고 설명하였습니다. 즉, Event는 Server로부터 Client에게로 진행되는, (Client 입장에서 봤을 때) 수동적인 데이터 전송을 의미합니다.
Method
다음으로, Method에 대해 살펴봅시다. Method는 여러분이 알고 계시는 함수, 메소드, 혹은 프로시저 등등 어떤 용어를 떠올리시든 바로 그것이라고 생각하시면 되겠습니다. 다만 호출이 로컬이 아닌 네트워크를 이용해 이루어진다는 점에만 차이가 있겠습니다.
위 용어들은 Method 기반 통신에 관한 용어들입니다.
Client가 Server가 가지고 있는 Method를 사용하려면, 먼저 서버에 Request 메시지를 전송합니다. 이렇게 네트워크를 이용하여 원격으로 메소드를 호출하는 것을 RPC(Remote Procedure Call) 라고 합니다. 서버는 Request를 받은 후, 자신이 가지고 있는 Method를 실행하고 그 결과를 Response 메시지에 담아서 Client에 전송합니다. RPC call 중에는 Client가 Request를 보낸 후 Server의 Response를 기다리지 않는 경우도 있는데, 이를 Fire & Forget이라고 합니다.
위 두 그림은 각각 Request / Response, Fire & Forget 방식 RPC를 나타낸 것입니다.
Field
공식 매뉴얼을 보면, Field는 '상태를 나타내는 값'으로 정의가 되어 있습니다. 저는 Field를 Client와 Server가 공유하며, Getter, Setter, 그리고 Notifier에 의해 정의되는, Service의 상태 등을 나타낼 수 있는 변수로 정의하도록 하겠습니다.
위에서, Field에는 getter, setter, notifier가 있다고 설명하였습니다. 이들은 Server 측에서 Field의 값을 다루기 위한 일종의 메소드라고 생각하시면 되겠습니다. Field에는 적어도 하나의 Getter, Setter, 또는 Notifier가 존재해야 합니다.
Getter는 Client가 현재 Field의 값을 얻으려고 할 때 쓰이는 것으로, Server에서는 Client의 Request가 들어오면 Field의 값을 담은 Respond 메시지를 Client에게 전송합니다. Setter는 Client가 현재 Field의 값을 바꾸려고 할 때 쓰이는 것으로, Client가 새롭게 바꾸려고 하는 Field 값을 Request 메시지에 담아 전송하면 Server는 Field의 값을 Client의 요청에 맞게 변경하고, 변경된 값을 Respond 메시지에 담아 Client에 전송합니다. 마지막으로, Notifier는 Field의 값이 바뀌었거나, 미리 설정한 주기에 따라 주기적으로 Client에 현재 Field 값을 전송합니다.
Event와 Method call에 대해 잘 이해하셨다면, Getter와 Setter는 Request/Response Call의 형식을 따르고, Notifier는 Event의 형식을 따른다는 것을 파악하셨을 것입니다. 실제로, Getter와 Setter는 Request/Response 메시지 형식을 이용하고, Notifier는 Event 메시지 형식을 이용합니다.
지금까지 서비스를 구성하는 3가지 요소인 Event, Method, Field에 대해 살펴보았습니다. SOME/IP는 이 3가지 요소를 조합하는 것으로 Service라는 추상적 개념을 구체화합니다. 하나의 Service는 여러 개의 Event, Method, Field를 가질 수 있으며, 아무것도 가지지 않는 것도 가능합니다 (Service가 어떠한 Event/Method/Field도 가지지 않을 경우, 이는 non-SOME/IP Service로 취급됩니다).
Conclusion
이번 시간에는 SOME/IP란 무엇인가, 그리고 SOME/IP는 어떻게 동작하는가를 Service 개념을 중심으로 살펴보았습니다. 다음에는 SOME/IP와 SOME/IP-SD의 메시지 포맷에 대해 분석해 보도록 하겠습니다.
References
- SOME/IP (https://some-ip.com/)
- vsomeip in 10 minutes (https://github.com/COVESA/vsomeip/wiki/vsomeip-in-10-minutes)
- SOME/IP Standard Documentations (https://some-ip.com/standards.shtml)
- SOME/IP in a Nutshell, Vector Informatik GmbH (https://cdn.vector.com/cms/content/events/2019/VH/VIC2019/Track_1_5_Glancing_Ethernet_communication_for_Automotive_4.pdf)
정리를 너무 깔끔하게 잘하셔서 잘봤습니다.