본문 바로가기
자동차 임베디드 SW/Adaptive Autosar

Adaptive Autosar SOME/IP 및 SD

by 존버매니아.임베디드 개발자 2024. 7. 10.
반응형


어댑티브 오토사는 Service Oriented Architecture를 갖는다.

어댑티브 오토사에서는 외부 제어기에 어떤 서비스를 요청하는 동작 방식이 마련돼있는데,
이때 SOME/IP 라는 프로토콜을 활용하게 된다.

Ex) 제어기1이 제어기2에게 와이퍼 동작 요청

이게 가능하려면 결국 제어기1이 제어기2에게 외부 통신을 통해서 뭔가를 전달해야하는데..


어댑티브에서는 제어기 끼리 통신을 이더넷 기반의 TCP/IP or UDP 통신으로 소통하는걸 전제하고 있다.


이때 Tcp ip 이더넷 udp 와 같은 통신프로토콜은 사실 단지 데이터를 전달할 뿐인거고..

그것보다 더 상위 레이어에서 서비스를 요청하고, 상호 작용 할 수 있게 마련해놓은 프로토콜이 SOME/IP 이다.

SOME/IP 는 Tcp나 udp 보다 더 상위 Layer이다.

UDS 진단통신이 캔통신보다 상위 Layer에서 적용되는 프로토콜인것과 비슷한 개념이다.

app에서 서비스 포트를 통해 서비스 요청하면 결국은 some ip를 거쳐서 tcp ip 이더넷 거쳐서 메세지가 송신될 것이다.

더 정확히는 app -> com -> SOME/IP -> tcp ip 이더넷 순으로 동작한다.

서비스 인터페이스는 크게 3가지. Method , Event , Field 인데 이게 뭔지는 다른 글 참고
Adaptive Autosar Com 및 인터페이스 (tistory.com)


한편, SD(Service Discovery)라는 프로토콜이 있는데 이것은 사실 SOME/IP 보다도 더 상위 Layer의 프로토콜이다.

사실 어댑티브의 서비스 오리엔티드 아키텍처에서는 서비스 요청. 서비스 응답을 위한 제어기간의  통신 유무(?) 통신 관계(?)가 런타임에 연결된다.

무슨말이냐면
제어기1에서 제어기2에 정의된 와이퍼 동작 요청을 하는 상황을 좀 더 자세히 얘기해보자.

사실 제어기1은 와이퍼 동작 서비스를 어떤 제어기가 제공하는지는 모르는 상태에서 그냥 요청한다.

어느 제어기가 해당 서비스를 제공하는지. 찾는 과정이 SD 이다.

클라이언트 측은 SD 프로토콜로 멀티캐스트로 FindService 요청을 날린다.

내가 와이퍼서비스 쓰고싶은데 누가 제공하니?
하고 멀티캐스트로 메세지를 날리는거다.

한편, 서버측은 본인이 제공하는 서비스가 있을 경우 이것을 멀티캐스트로 날린다.
(Offer service)

위 과정을 통해서 클라이언트는 와이퍼 서비스를 어떤 제어기가 제공하는지 알게되고, 그래서 이제 해당 제어기에게 유니캐스트로 서비스를 요청 할 수 있게 된다.




반응형