SommR가 다가오고 있습니다
uProtocol의 임베디드 자동차 분야 진출 첫걸음
이 (아주 짧은) 시리즈의 첫 부분에서는 커뮤니케이션 의미론과 구문론의 영역에 발을 담그며, 이 두 가지가 소프트웨어 정의 차량(SDV)의 맥락에서 가질 수 있는 의미를 살펴보았습니다. 잠재적 솔루션 옵션의 지형이 방대하고 계속 확장되는 환경에서, 차량 제품 범위 내 엔지니어링 문화의 다양성까지 더해져 실제 제품 구축과 관련된 도전 과제를 조심스럽게 살펴보았습니다. 마지막으로 Eclipse uProtocol 프로젝트가 이러한 맥락에서 어떻게 가치를 더하고자 하는지 살펴보며 내용을 마무리했습니다.
이제 uProtocol 비전의 성공 요인을 좀 더 깊이 살펴보겠습니다. 한 가지 기회를 좀 더 깊이 탐구하며, 몇 가지 요소가 예상대로 맞아떨어진다면 올해 어떤 일이 벌어질지 전망해 보겠습니다.
uProtocol 성공 요인
uProtocol 자체는 차량 세계의 모든 통신 문제를 포괄적으로 해결하는 만능 솔루션이 아닙니다. 오히려 현대적인 차량-클라우드-앱 시나리오에 관여하는 기술적으로 다양한 영역 간의 서비스 간 통신을 가능하게 하는 접착제와 공통 개념을 제공하는 '메타 미들웨어'라 할 수 있습니다.
이러한 소프트웨어 인프라의 경우 진정한 성공을 거두기 위해서는 여러 영역이 복합적으로 작용해야 합니다. 첫 번째 글에서 암시한 바와 같이, 그 대부분은 기술적 성격이 아닙니다. 본 논의의 배경으로 성공의 몇 가지 차원을 정의해 보겠습니다.
기술적 성공은 특정 기술적 문제를 해결하는 동시에, 주어진 시나리오에서 관련성이 있는 기술적 KPI로 측정했을 때 목적에 부합할 만큼 충분히 잘 수행하는 기준점이다.
성숙도 성공은 순수한 코드를 넘어서는 '비기술적' 요구사항을 충족하는 데 있습니다: 개발 커뮤니티의 목표와 마인드셋이 생산 환경에 바로 투입 가능한 소프트웨어를 구축하고 유지하는 것인가? 이는 품질 프로세스 준수 지표와 관련되고 기여하는 비코드 산출물의 생성 및 진화로 이어지는가?
도입 성공은 본질적으로 프로젝트의 가치 증대 배율로, 여기서 제기되는 질문은 "이 코드가 한 개 이상의 조직에서 생산적으로 사용되고 있는가?"입니다. 이 속성은 실제로 두 번째로 더 암묵적이지만 여전히 매우 바람직한 효과를 지닙니다: 코드베이스의 모든 적극적인 도입자와 기여자는 정의상 '시스템 작동 방식'을 알고 있으며 동일한 용어를 사용합니다. 이는 상업적 협업에 있어 중대한 이점입니다. 관련 당사자들이 개념적·기술적 조율 단계를 건너뛰고 바로 가치 창출 단계로 진입할 수 있기 때문입니다.
생태계의 성공은 위의 모든 요소가 조화를 이루고 핵심 기술이 확장성을 허용하며 모든 형태의 기여를 장려할 때 이루어집니다 . 성공적인 생태계는 참여자들이 핵심 요소의 채택 성공을 활용하여 자체 확장 및 기여를 가능하게 합니다. 이는 오픈소스 및 상업적 모델 모두에 해당됩니다. 생태계는 특정 문제 영역 해결을 위한 놀라울 정도로 성공적인 도구 상자를 창출할 수 있습니다. 극히 성공적인 사례로, 쿠버네티스(k8s)의 핵심 개념(및 구현)을 중심으로 성장한 클라우드 네이티브 컴퓨팅 재단 (CNCF) 생태계를 비교해 보십시오.
uProtocol이 k8s 수준의 규모로 성장한다면 (기쁘게도) 놀라겠지만, 이 소규모 프로젝트에 대해서도 위의 성공 단계를 구상할 수 있으며 그 길을 따라가는데 도움이 될 아이디어를 논의할 수 있습니다.
uProtocol 개념
uProtocol 개념을 설명하기 위해, 스마트폰 동반 앱에서 특정 차량의 속도 정보를 요청하는 사용 사례를 상상해 보겠습니다. 이로 인해 속도 데이터그램 구독 요청이 앱에서 시작되어 여러 백엔드 서비스를 거쳐 해당 차량으로 전달되고, 차량 내부에서는 요청된 데이터 포인트를 실제로 제공할 수 있는 도메인 및 제어 장치로 전달됩니다. 구독 엔드포인트는 구독 요청을 처리한 후 속도 정보를 "네트워크 이웃"에 게시합니다. 이 정보는 uProtocol 서비스 메시에 의해 전체 체인에 걸쳐 수신 및 전달되어, 결국 동반 앱에 (거의) 실시간 차량 속도가 표시됩니다.
uProtocol은 이를 달성하기 위해 몇 가지 구성 요소를 정의합니다:
- uProtocol의 하위/하위 및 명령/응답 메시징을 특정 전송 프로토콜에 적용하는 uPClient 구현체. 예를 들어, MQTT 프로토콜용 Rust 기반 uPClient 구현체가 존재할 수 있다.
- uStreamer는 서로 다른 전송 프로토콜 영역 간에 메시지(게시/구독 데이터, 명령/응답 메시지)를 라우팅할 수 있습니다. 이를 위해 uStreamer는 최소 두 개의 uPClient에 연결하고, 어느 메시지가 어느 쪽에서 다른 쪽으로 전달되어야 하는지 추적합니다.
- uSubscription 서비스는 도메인 간 구독을 관리합니다. 예를 들어, 두 개의 서로 다른 pub/sub 네트워크가 더 큰 솔루션의 일부인 경우, 각 네트워크의 uSubscription 구성 요소는 한 네트워크의 클라이언트로부터 다른 네트워크에 원래 게시된 메시지에 대한 구독 요청을 추적하고 전달합니다.
더 자세한 내용과 몇 가지 추가 구성 요소(예: uTwins)가 있습니다. uTwins는 도메인 내 또는 도메인 집합(예: 차량 전체)을 위한 데이터 캐싱/버퍼링/저장에 사용할 수 있습니다. 그러나 본 문서에서는 핵심 구성 요소에 집중하겠습니다.
이 확장 지점이 설계된 컴포넌트 아키텍처는 생태계 구축의 핵심 특성을 보여줍니다: 핵심 프로그래밍 모델(API, 의미론)의 정의를 커뮤니티 내 채택과 더 큰 도구 상자 구축만이 진정한 비전을 실현할 수 있다는 명확한 이해와 결합합니다. uProtocol은 이 도구 상자에 기여하는 채택자가 늘어날수록 기하급수적으로 유용해집니다. 예를 들어, 단 하나의 뉴스형 uPClient 어댑터를 추가하는 것만으로도 다른 모든 uProtocol 구성 요소의 가치가 상승합니다. 이는 모든 구성 요소의 적용 범위를 새로운 환경으로 확장하기 때문입니다.
내장된 연결
uProtocol이 자동차 서비스 메시로 유용하게 사용되려면 자동차 프로토콜, 즉 메카트로닉스 영역의 차량 내 통신 네트워크에 연결되어야 합니다. 이 부분이 일반적으로 복잡해지는 지점인데, 그 이유는 별도의 글 한 편을 채울 만큼 많습니다. 따라서 본 문서에서는 개념적·생태계 수준에서 유용한 시나리오를 제시할 것이며, 실제 구현은 본 문서 작성 시점에는 공개할 수 없음에도 불구하고1 이를 설명하고자 한다.
위에서 제시한 주제와 일관되게, uProtocol이 임베디드 자동차 분야로 진출하기 위한 좋은 첫걸음은 스펙트럼 양단의 퍼블리시/서브스크라이브(pub/sub) 네트워크를 연결하는 것입니다. 자동차 측면에서 관련 후보 프로토콜로는 자동차 네트워크 인프라 위에 구축된 퍼블리시/서브스크라이브 방식 통신을 위한 사양인 AUTOSAR® SOME/IP가 있습니다. SOME/IP uPClient 구현체를 개발함으로써, SOME/IP 네트워크 세그먼트를 더 큰 uProtocol 서비스 메시의 일부로 통합할 수 있습니다. 이는 앞서 설명한 예시 사용 사례를 가능하게 할 것입니다. 즉, 차량 내 SOME/IP 네트워크 2 내의 엔티티가 속도 데이터그램을 게시하면, uProtocol 메커니즘을 통해 네트워크/프로토콜 인프라의 다른 세그먼트로 라우팅되는 방식입니다.
이 아이디어의 주요 과제는 다시 한번 기술적 문제가 아닌 점입니다: SOME/IP는 AUTOSAR® 사양으로, 이는 현재 사양 버전의 오픈소스 구현이 AUTOSAR IP 라이선스 3에 의해 금지됨을 의미합니다. 따라서 오픈소스 프로젝트 내에서 uProtocol-SOME/IP 연결 구현은 불가능합니다.
SommR에 대한 기대
현재 Eclipse SDV 작업 그룹에서는 SommR의 출시를 기다리고 있습니다. SommR은 Rust로 구현된 SOME/IP의 완전한 신규 구현체로, uProtocol 브릿지 구축에 완벽한 기반이 될 것입니다. 2022년 중반 프로젝트 발표 이후, 프로젝트 기여자는 AUTOSAR® IP 정책 관련 승인을 얻기 위해 노력해 왔으며, 아직 결실을 맺지는 못했지만 올해 안에 긍정적인 결과가 나올 가능성이 있습니다.
SommR가 출시되면 uPClient가 이를 연결하여 SOME/IP를 uProtocol 서비스 메시에 통합할 수 있게 될 것입니다. 이를 통해 위에서 언급한 동반자 앱 시나리오와 SOME/IP 제어 장치를 포함한 유사한 설정을 구축할 수 있습니다. 오픈소스 세계와 기존 자동차 산업 간의 첫 번째 가교가 마련되기를 기대합니다.
이 맥락에서 흥미로울 수 있는 한 가지 더: SommR와 uProtocol 프로젝트 모두 자동차 제품에 사용하기 위한 생산 준비 완료 코드를 제공하고 유지하는 것을 목표로 합니다. 세부 사항과 범위는 아직 진화 중이지만, 프로세스 정의( Eclipse 재단 개발 프로세스를 통해), 프로젝트 요구사항 명세서, 문서화, 테스트 커버리지 및 관련 KPI 등과 같은 관심사들이 상당 부분 다루어질 것이라고 말해도 무방합니다. 이 프로젝트들은 (마찬가지로 아직 개발 중인) Eclipse SDV 품질/성숙도 프로그램의 초기 도입 사례가 될 가능성이 높습니다. 해당 프로그램은 상용 자동차 제품 엔지니어링 프로세스에서 이 소프트웨어를 활용할 수 있는 기반을 제공하는 것을 목표로 합니다.
테이크아웃
요약하자면, Eclipse uProtocol과 곧 출시될 Eclipse SommR 프로젝트는 오픈 소스가 자동차 소프트웨어 인프라 구축의 핵심 촉진제 역할을 할 수 있는 방식을 보여주는 사례가 될 수 있습니다. 이 사례에는 다음이 포함될 것입니다:
기존 자동차 도메인 기술과 IT 스타일 네트워크 스택의 완벽한 통합을 통해 더 큰 전체를 구축한다.
자동차 가치 사슬 내 파트너 간 1차적이며 낮은 오버헤드의 협업을 가능케 하는 개방형 개발 모델과 오픈소스 재단의 실증 사례
OSS 프로젝트가 어떻게 자동차 등급 소프트웨어 품질을 제공할 수 있는지에 대한 인큐베이터이자 시험장이며, 따라서 그것이 실제로 무엇을 의미하는지에 대한 어떤 아이디어조차도 제공할 수 있을지 모릅니다...
여기서 언급된 내용이 귀하와 관련이 있다고 생각되신다면, Eclipse SDV Slack 공간, uProtocol 프로젝트 회의, 메일링 리스트 또는 커뮤니티 행사에 참여해 주시면 매우 기쁘겠습니다(참여 방법에 대한 자세한 내용은 Eclipse SDV 정보 페이지를 참조해 주세요).
경계를 넘어선 협력이 기존의 제로섬 기업 경쟁에서 벗어나는 최선의 방법이다.
1: 그러나 해당 글의 마지막 부분을 참조하십시오.
2: 아니요, uProtocol 메쉬는 고처리량, 최저 지연 실시간 통신에 최적화된 전용 솔루션을 대체하지 않습니다. 예, 그럼에도 여전히 고객이 기대하고 관련성이 있는 많은 사용 사례 시나리오가 존재합니다(사실 고객에게 훨씬 더 잘 보이는 경우가 많습니다). 아니요, uProtocol 전체는 자동차 안전 인증 논의를 위한 유용한 대상이 아닐 가능성이 높습니다. 다만 하위 구성 요소나 전용 어댑터는 그럴 가능성이 매우 높습니다.
3: 저희는 vsomeip 프로젝트를 인지하고 있습니다. 그러나 기존 AUTOSAR® 사양의 공개 구현과 관련된 논란이 지속되는 상황에서, 해당 프로젝트에 대한 저희의 입장을 명확히 정립하지 못한 상태입니다.
문의하기
궁금하신 사항은 언제든지 문의해 주시기 바랍니다.