KR102673331B1

KR102673331B1 - V2v 통신을 통한 차량들로의 소프트웨어 업데이트 분산 및 차량들의 컴뮤니티에 의한 검증

Info

Publication number: KR102673331B1
Application number: KR1020217030100A
Authority: KR
Inventors: 코비 미쉘손; 알렉산더 아쉬키나지
Original assignee: 레드 밴드 리미티드
Priority date: 2019-02-19
Filing date: 2019-02-19
Publication date: 2024-06-10
Also published as: KR20210128469A; WO2020170233A1; EP3928197A1; CN113454584A; US20220147337A1

Abstract

차량 간(V2V) 통신 채널(들)을 통해 수신된 업데이트들을 사용하여 차량들의 전자 제어 유닛들(ECU들)을 업데이트 하는 방법은 V2V 통신 채널(들)을 통해 주변 차량(들)로부터, 복수의 차량들에 배치된 복수의 ECU들을 업데이트하기 위해 분산된 복수의 업데이트 패키지들 중 하나 이상을 수신하는 단계로서, 주변 차량(들) 각각은 V2V 통신 채널(들)의 수신 범위 내에 있는, 상기 수신하는 단계, 각 업데이트 패키지로부터 추출된 식별자를 분석하여 업데이트 패키지가 차량의 ECU(들)로 향하는지 여부를 결정하는 단계, 긍정의 결정의 경우, V2V 통신 채널(들)을 통해, 각 업데이트 패키지를 각각의 검증 코드와 연관시키는 로컬 로그를 각각 유지하는 차량 서브셋과 통신하여 서브셋의 컨센서스에 따라 업데이트 패키지로부터 추출된 검증 코드를 검증하는 단계, 및 성공적인 검증의 경우, 업데이트 패키지(들)을 사용하여 ECU(들)의 업데이트를 개시하는 단계를 포함한다.

Description

V2V 통신을 통한 차량들로의 소프트웨어 업데이트 분산 및 차량들의 컴뮤니티에 의한 검증

본원에 설명된 일부 실시예들은 차량의 전자 제어 유닛들(ECU들)을 업데이트하는 것에 관한 것으로, 보다 구체적으로는, 전적인 것은 아니지만, 차량 간(Vehicle to Vehicle; V2V) 통신 채널들을 통해 수신되고 차량 커뮤니티의 컨센서스에 따라 검증된 업데이트 패키지들을 사용하여 차량들의 ECU들을 업데이트하는 것에 관한 것이다.

자동차 산업의 지속적인 발전으로 인해, 자동차, 트럭, 오토바이 등과 같은 현대식 차량의 동작은 차량 동작의 거의 모든 측면을 제어하기 위해 차량에 배치된 여러 전자 제어 유닛들(ECU)을 활용하는 자동화 시스템에 크게 의존하고 있다.

이러한 ECU들은 예를 들어, 엔진 제어 시스템, 전송 제어 시스템, 제동 시스템, 조명 시스템, 인포테인먼트 시스템, 내비게이션 시스템, 통신 시스템, 도어록 시스템, 윈도우 리프트 시스템 등과 같은 중요 시스템에서 사용자 경험 시스템에 이르기까지 차량의 다양한 시스템들을 제어할 수 있다.

ECU들은 필요한 기능 및 특징들을 제공하기 위해 소프트웨어, 펌웨어 및/또는 미들웨어 모듈(들)을 실행하는 하나 이상의 프로세서들을 포함하는 처리 장치들일 수 있다. ECU들은 또한 예를 들어, 필요한 기능 및 특징들을 제공하기 위해 필드 프로그램 가능 게이트 어레이(FPGA)의 논리 게이트들을 매핑하기 위해 펌웨어와 함께 로드될 수 있는 FPGA 등과 같은, 하나 이상의 프로그램 가능 로직 장치들을 포함할 수 있다.

자동차 산업의 동적 특성과 차량들에 의해 지원되는 특징들로 인해, ECU들은 차량들이 생산 및 배송 센터를 떠난 후 종종 업데이트되어야 할 수 있다. 따라서, ECU들은 배치된 차량에 전달된 업데이트 패키지들을 사용하여 소프트웨어, 펌웨어 및/또는 미들웨어 모듈(들)의 동적 업데이트를 지원하도록 구성될 수 있다.

본원에 설명된 제1 양태에 따르면, 다음을 위한 코드를 실행하는 차량의 하나 이상의 프로세서들을 사용하는 것을 포함하여, 차량 간(V2V) 통신 채널들을 통해 수신되고 차량 컨센서스에 의해 검증된 업데이트들을 사용하여 차량들의 전자 제어 유닛들(ECU들)을 업데이트 하는 방법이 제공된다:

- 하나 이상의 주변 차량들로부터 하나 이상의 V2V 통신 채널들을 통해, 복수의 차량들에 배치된 복수의 ECU들을 업데이트하기 위해 분산된 복수의 업데이트 패키지들 중 하나 이상을 수신하는 것. 주변 차량(들) 각각은 V2V 통신 채널(들)의 수신 영역 내에 있음.

- 업데이트 패키지(들)로부터 추출된 식별자를 분석하여 업데이트 패키지(들)이 차량의 하나 이상의 ECU들로 향하는지 여부를 결정함.

- 긍정의 결정의 경우, V2V 통신 채널(들)을 통해, 복수의 업데이트 패키지들 각각과 각각의 검증 코드를 연관시키는 로컬 로그를 각각 유지하는 적어도 복수의 차량들의 서브셋과 통신하여 차량들의 서브셋의 컨센서스에 따라 업데이트 패키지(들)로부터 추출된 검증 코드를 검증함.

- 성공적인 검증의 경우, 업데이트 패키지(들)을 사용하여 ECU(들)의 업데이트를 개시함.

본원에 설명된 제2 양태에 따르면, 차량 간(V2V) 통신 채널들을 통해 수신되고 차량 컨센서스에 의해 검증된 업데이트들을 사용하여 차량들의 전자 제어 유닛들(ECU들)을 업데이트하는 시스템으로서, 다음을 포함하는 상기 시스템이 제공된다:

- 하나 이상의 V2V 통신 채널들에 연결하기 위한 차량에 배치된 하나 이상의 V2V 통신 인터페이스.

- 하나 이상의 V2V 통신 인터페이스들에 결합된 차량의 하나 이상의 프로세서들. 프로세스들 중 하나 이상은 다음을 포함하는 코드를 실행한다:

ㆍ 하나 이상의 주변 차량들로부터, 하나 이상의 V2V 통신 채널(들)을 통해, 복수의 차량들에 배치된 복수의 ECU들을 업데이트하기 위해 분산된 복수의 업데이트 패키지들 중 하나 이상을 수신하기 위한 코드 인스트럭션들. 주변 차량(들)은 V2V 통신 채널(들)의 수신 영역 내에 있다.

ㆍ 업데이트 패키지(들) 각각으로부터 추출된 식별자를 분석하여 업데이트 패키지가 차량의 하나 이상의 ECU들로 향하는지 여부를 결정하기 위한 코드 인스트럭션들.

ㆍ 긍정의 결정의 경우, V2V 통신 채널(들)을 통해, 복수의 업데이트 패키지들 각각과 각각의 검증 코드를 연관시키는 로컬 로그를 각각 유지하는 적어도 복수의 차량들의 서브셋과 통신하여 차량들의 서브셋의 컨센서스에 따라 각 업데이트 패키지(들)로부터 추출된 검증 코드를 검증하기 위한 코드 인스트럭션들.

ㆍ 성공적인 검증의 경우, 업데이트 패키지(들) 중 하나 이상을 사용하여 ECU(들) 중 하나 이상의 업데이트를 개시하기 위한 코드 인스트럭션들.

제1 및/또는 제2 양태의 추가 구현 형태에서, V2V 통신 채널(들) 각각은 근접하게 위치된 차량들 사이의 통신을 설정하기 위한 근거리 통신 채널이다.

제1 및/또는 제2 양태들의 추가 구현 형태에서, 복수의 업데이트 패키지들 각각은, 펌웨어 업데이트, 미들웨어 업데이트 및 소프트웨어 업데이트로 구성된 그룹의 멤버이다.

제1 및/또는 제2 양태의 선택적 구현 형태에서, 복수의 업데이트 패키지들 각각은 만료 시간 태그와 연관되고 이후에는 각각의 업데이트 패키지가 무효화된다.

제1 및/또는 제2 양태의 추가 구현 형태에서, 복수의 업데이트 패키지들 각각은 복수의 업데이트 패키지들을 복수의 차량들 중 적어도 일부로 전송하도록 적응된 적어도 하나의 신뢰할 수 있는 분산 시스템들로부터 비롯된다.

제1 및/또는 제2 양태들의 추가 구현 형태에서, 각 업데이트 패키지는 업데이트 패키지(들)에 대해 추출된 하나 이상의 패키지 속성들과 각각의 ECU(들)과 연관된 하나 이상의 ECU 속성들을 비교하여 각각의 ECU(들)로 향하는 것으로 결정된다.

제1 및/또는 제2 양태의 추가 구현 형태에서, 복수의 차량들 각각은 복수의 차량들의 적어도 일부 다른 차량들과 통신하여 그 각각의 로컬 로그를 지속적으로 업데이트 및 동기화한다.

제1 및/또는 제2 양태들의 선택적 구현 형태에서, 차량 서브셋 각각에 의해 유지되는 로컬 로그는 복수의 변경할 수 없는 비가역적 블록들을 포함하는 블록체인에 의해 구현되며, 복수의 업데이트 패키지들 중 각각의 하나에 대한 하나 이상의 신뢰할 수 있는 분산 시스템들에 의해 생성된 상기 복수의 변경할 수 없는 비가역적 블록들 각각은 상기 각각의 업데이트 패키지의 상기 식별자를 상기 각각의 업데이트 패키지의 상기 검증 코드와 관련시킨다.

제1 및/또는 제2 양태들의 추가 구현 형태에서, 하나 이상의 주변 차량들 각각의 아이덴티티 및 차량 서브셋 각각의 아이덴티티는 추가 데이터 교환 전에 신뢰할 수 있는 통신 세션을 설정하도록 우선 인증된다.

제1 및/또는 제2 양태들의 추가 구현 형태에서, 검증 코드는 복수의 업데이트 패키지들 각각의 각 식별자가 차량 서브셋 각각의 로그에서 각각의 해시 값과 연관되도록 적어도 하나 이상의 해시 함수들을 사용하여 하나 이상의 업데이트 패키지들 각각에 대해 계산된 해시 값이다.

제1 및/또는 제2 양태의 추가 구현 형태에서, 서브셋의 차량 수는 하나 이상의 보안 파라미터들에 다라 설정된다.

제1 및/또는 제2 양태들의 추가 구현 형태에서, 수신된 업데이트 패키지(들) 중 하나 이상은 V2V 통신 채널(들)을 통해 복수의 차량들 중 하나 이상의 다른 주변 차량들로 전송된다.

제1 및/또는 제2 양태들의 추가 구현 형태에서, 업데이트 패키지들의 전송은 기록되지 않는다.

제1 및/또는 제2 양태들의 추가 구현 형태에서, 수신된 업데이트 패키지(들)은 미리 정의된 시간 기간 동안 로컬로 저장되고 하나 이상의 다른 주변 차량들로의 전송에 이용 가능하다. 업데이트 패키지(들)은 미리 정의된 시간 기간의 만료 시 폐기된다.

제1 및/또는 제2 양태들의 선택적 구현 형태에서, 미리 정의된 시간 기간은 차량의 하나 이상의 동작 파라미터들에 따라 조정된다. 동작 파라미터들은 차량의 지리적 영역, 주변 지형, 차량의 온/오프 상태 및 차량의 속도를 포함할 수 있다.

제1 및/또는 제2 양태들의 선택적 구현 형태에서, 미리 정의된 비-전송 기간이 업데이트 패키지(들)이 전송되지 않는 동안 업데이트 패키지(들)의 후속 전송들 사이에 적용된다.

제1 및/또는 제2 양태들의 선택적 구현 형태에서, 미리 정의된 비-수신 기간은 업데이트 패키지들의 수신이 금지되는 동안 업데이트 패키지(들)의 수신 후에 적용된다.

제1 및/또는 제2 양태들의 선택적 구현 형태에서, 업데이트 패키지들 중 하나 이상은 복수의 개별 수신 세션들에 누적식으로 수신된다. 복수의 차량들 중 하나 이상과 설정된 복수의 수신 세션 각각 동안, 각각의 업데이트 패키지의 수신은 각각의 업데이트 패키지의 하나 이상의 추가 부분을 수신하도록 재개된다.

제1 및/또는 제2 양태들의 선택적 구현 형태에서, 차량과 연관된 하나 이상의 모바일 장치들은 업데이트 패키지들 중 하나 이상을 수신하고, 업데이트 패키지(들)이 연관된 차량의 하나 이상의 ECU를 향하는지 여부를 결정하고, 업데이트 패키지(들) 각각을 검증하고, 업데이트 패키지(들) 중 하나 이상을 사용하여 업데이트를 개시한다.

달리 정의되지 않는 한, 본원에 사용된 모든 기술적 및/또는 과학적 용어들은 본원에서 설명된 실시예들이 속하는 기술 분야의 당업자에 의해 일반적으로 이해되는 것과 동일한 의미를 갖는다. 본원에 설명된 것과 유사하거나 등가인 방법들 및 재료들이 본원에 설명된 실시예들의 실시 또는 테스트에 사용될 수 있지만, 예시적인 방법들 및/또는 재료들이 아래에 설명되어 있다. 상충되는 경우, 정의들을 포함한 본 명세서가 우선한다. 추가로, 재료들, 방법들 및 예들은 예시일 뿐이며 반드시 제한하려는 것은 아니다.

본원에 설명된 일부 실시예들의 방법 및/또는 시스템의 구현은 선택된 태스크들을 수동으로, 자동으로, 또는 이들의 조합으로 수행하거나 완료하는 것을 포함할 수 있다. 게다가, 본원에 설명된 실시예들의 방법 및/또는 시스템의 실시예들의 실제 계측 및 장비에 따르면, 몇몇 선택된 태스크들은 하드웨어에 의해, 소프트웨어 또는 펌웨어에 의해 또는 운영 체제를 사용하는 이들의 조합에 의해 구현될 수 있다.

예를 들어, 본원에 설명된 실시예들에 따른 선택된 태스크들을 수행하기 위한 하드웨어는 칩 또는 회로로서 구현될 수 있다. 소프트웨어로서, 본원에 설명된 실시예들에 따른 선택된 태스크들은 임의의 적절한 운영 체제를 사용하여 컴퓨터에 의해 실행되는 복수의 소프트웨어 인스트럭션들으로서 구현될 수 있다. 본원에 설명된 일부 예시적인 실시예들에서, 방법 및/또는 시스템의 하나 이상의 태스크들은 복수의 인스트럭션들을 실행하기 위한 컴퓨팅 플랫폼과 같은 데이터 프로세서에 의해 수행된다. 선택적으로, 데이터 프로세서는 인스트럭션들 및/또는 데이터를 저장하기 위한 휘발성 메모리 및/또는 인스트럭션들 및/또는 데이터를 저장하기 위한 비휘발성 저장 장치, 예를 들어 자기 하드 디스크 및/또는 이동식 매체를 포함한다. 선택적으로, 네트워크 연결도 제공된다. 디스플레이 및/또는 키보드나 마우스와 같은 사용자 입력 장치도 선택적으로 제공된다.

일부 실시예들이 첨부 도면들을 참조하여 예시로서만 본원에서 설명된다. 이제 도면들을 상세하게 참조하면, 도시된 세부 사항들은 예시적인 것이며 본원에 설명된 실시예들의 예시적인 논의를 위한 것임을 강조한다. 이와 관련하여, 도면들과 함께 취해진 설명은 본원에 설명된 실시예들이 어떻게 실시될 수 있는지 당업자에게 명백해지도록 한다.
도면들에서,
도 1은 본 명세서에 설명된 일부 실시예에 따른, 차량 간(V2V) 통신 채널들을 통해 수신되고 차량 컨센서스에 의해 검증된 업데이트 패키지들을 사용하여 차량들의 전자 제어 유닛들(ECU들)을 업데이트하는 예시적인 프로세스의 흐름도이다;
도 2는 본원에 설명된 일부 실시예들에 따른, V2V 통신 채널들을 통해 수신되고 차량 컨센서스에 의해 검증된 업데이트들을 사용하여 차량들의 ECU들을 업데이트하는 예시적인 시스템의 개략도이다;
도 3a 및 도 3b는 본원에 설명된 일부 실시예들에 따른, V2V 통신 채널들을 통해 수신되고 차량 컨센서스에 의해 검증된 업데이트들을 사용하여 차량들의 ECU들을 업데이트하기 위해 연관 모바일 장치를 사용하는 시스템의 예시적인 실시예들의 개략도들이다;
도 4는 본원에 설명된 일부 실시예들에 따른, 차량들의 ECU들에 대한 업데이트 패키지들을 분산하고 검증하기 위해 V2V 통신 채널들을 사용하는 네트워크 차량들의 예시적인 커뮤니티의 개략도이다; 그리고
도 5a 및 도 5b는 본원에 설명된 일부 실시예들에 따른, 차량들의 ECU들에 대한 업데이트 패키지들을 전송 및 검증하기 위해 네트워크 차량들의 커뮤니티에 의해 사용되는 예시적인 제어 평면 및 데이터 평면의 개략도들이다.

본원에 설명된 일부 실시예들은 차량들의 ECU들을 업데이트하는 것에 관한 것으로, 보다 구체적으로는, 전적인 것은 아니지만, V2V 통신 채널들을 통해 수신되고 차량 커뮤니티의 컨센서스에 따라 검증된 업데이트 패키지들을 사용하여 차량들의 ECU들을 업데이트하는 것에 관한 것이다.

본원에 설명된 일부 실시예들에 따르면, V2V 통신 채널들을 통해 수신되고 복수의 차량들을 포함하는 커뮤니티의 적어도 일부 차량들의 컨센서스에 의해 검증된 업데이트 패키지들을 사용하여 차량들의 ECU들을 업데이트하기 위한 방법들, 시스템들 및 컴퓨터 프로그램 제품들이 제공된다. 이러한 차량 커뮤니티는 커뮤니티의 차량들 간에 업데이트 패키지들을 분산하기 위한 데이터 평면과 차량 서브셋의 적어도 과반수의 컨센서스에 기초하여 수신된 업데이트 패키지들을 검증하기 위한 제어 평면 둘 다의 역할을 하여 수신된 업데이트 패키지들이 정품(진품)이고 변조되지 않았으며 ECU들을 업데이트하는 데 사용하기에 적합하다고 보장하도록 한다.

예를 들어, 차량 커뮤니티에 분산되는 펌웨어 업데이트, 미들웨어 업데이트, 소프트웨어 업데이트 등과 같은, 업데이트 패키지들은 일반적으로 예를 들어, 자동차 제조사, 자동차 정비 서비스 제공자, ECU 제공자, 소프트웨어 제공자 등과 같은, 하나 이상의 신뢰할 수 있는 공급업체와 관련된 하나 이상의 신뢰할 수 있는 분산 시스템들에서 비롯될 수 있다.

커뮤니티의 하나 이상의 차량들은 각각의 차량에 배치된 하나 이상의 ECU들을 업데이트하기 위한 하나 이상의 업데이트 패키지들을 수신할 수 있다. 특히, 차량들은 하나 이상의 다른 차량들로부터의 하나 이상의 V2V 통신 채널들을 통해 업데이트 패키지들을 수신할 수 있다.

V2V 통신 채널들은 일반적으로 제한된 수신 범위 및 이에 따라 제한된 수신 영역을 갖는 근거리 통신 채널들이므로, 차량들은 V2V 통신 채널(들)의 수신 영역(범위) 내에 있는 하나 이상의 마주치는 주변 차량들로부터 업데이트 패키지들을 수신할 수 있다. V2V 통신 채널(들)의 짧은 범위와 차량들의 동적 특성으로 인해, 두 대 이상의 주변 차량들 사이의 접촉 동안 로컬 애드혹(Ad-Hoc) 네트워크, 연결 및/또는 세션(이하 본원에서는 애드혹 네트워크로 지정됨)는 주변 차량들이 서로 통신할 수 있는 주변 차량들 사이에 설정될 수 있으며, 특히 하나 이상의 업데이트 패키지들을 전송할 수 있다.

선택적으로, 차량들 중 하나 이상은 하나 이상의 주변 차량들과 설정된 복수의 개별 수신 세션 동안 누적 방식으로 하나 이상의 업데이트 패키지들을 수신할 수 있다. 각각의 복수의 수신 세션 동안, 차량은 업데이트 패키지의 수신을 재개하고 업데이트 패키지의 하나 이상의 추가 부분들을 수신할 수 있다. 차량에 전체 업데이트 패키지가 누적될 때까지 수신 세션들이 반복될 수 있다.

업데이트 패키지를 수신한 후, 차량, 구체적으로는 차량의 하나 이상의 업데이트 시스템들에 의해 실행된 업데이트 에이전트는 수신된 업데이트 패키지가 차량에 적용 가능한지 여부를 확인할 수 있다. 업데이트 에이전트는 먼저 수신된 업데이트 패키지가 차량에 배치된 ECU들 중 하나 이상(타겟들)로 향하는지 여부를 확인하고, 수신된 업데이트 패키지가 차량의 ECU(들)로 향하는 경우 타겟 ECU(들)가 수신된 업데이트 패키지를 사용하여 업데이트되어야 하는지 여부를 확인할 수 있다.

수신된 업데이트 패키지가 차량의 ECU(들)에 적용 가능한 것으로 결정된 경우, 업데이트 에이전트는 수신된 업데이트 패키지가 유효한지 검증하기 위해 커뮤니티의 적어도 일부 다른 차량들을 포함하는 그룹(서브셋)과 통신할 수 있다. 유효한 업데이트 패키지는 신뢰할 수 있는 분산 시스템에서 비롯된(릴리즈된) 정품(진품)이고 신뢰할 수 있는 분산 시스템(들)에 의해 릴리즈된 이후 변조되지 않은 신뢰할 수 있는 업데이트 패키지이다.

업데이트 패키지를 수신하는 차량들로부터 수신된 쿼리들에 응답하여 업데이트 패키지들을 검증하는 데 필수적인 업데이트 패키지들에 대한 제어 평면을 용이하게 하기 위해, 차량 커뮤니티는 하나 이상의 분산 컴퓨팅 방법들, 알고리즘들 및/또는 프로토콜들을 사용할 수 있다. 게다가, 커뮤니티의 대부분의 차량들은 커뮤니티의 진실하고 정직한 구성원들로 신뢰될 수 있지만, 커뮤니티의 차량들 중 적어도 일부는 신뢰될 수 없으며, 예를 들어, 하나 이상의 악의적인 당사자들에 의해 운영, 하이재킹 및/또는 손상되어 차량 커뮤니티를 하나 이상의 사이버 위협들에 노출시킨다. 따라서, 차량의 분산 컴퓨팅 커뮤니티가 이러한 신뢰할 수 없는 차량들에 영향을 받지 않는지 확인하기 위해, 차량 커뮤니티는 신뢰할 수 없는 커뮤니티 구성원 간에 신뢰할 수 있는 플랫폼, 예를 들어 블록체인 등을 설정하도록 지시된 하나 이상의 분산 컴퓨팅 방법들, 알고리즘들 및/또는 프로토콜들을 사용할 수 있다.

따라서, 신뢰할 수 있는 플랫폼 제어 평면의 일부로서, 커뮤니티의 차량들 각각은 신뢰할 수 있는 분산 시스템(들)에 의해 릴리즈된 모든 업데이트 패키지들이 각각의 검증 데이터, 예를 들어, 검증 코드 등과 관련된 로컬 로그(블록체인 구현의 분산 원장)를 유지할 수 있다. 검증 코드는 예를 들어, 각 업데이트 패키지가 각자의 해시 값과 고유하게 연관되도록 하나 이상의 해시 함수들을 사용하여 업데이트 패키지들 각각에 대해 계산된 해시 값을 포함할 수 있다. 게다가, 분산 컴퓨팅 패러다임에 따라, 커뮤니티의 복수의 차량들은 대다수의 차량들(및 잠재적으로 모두)에 의해 유지된 모든 로그들이 릴리즈된 업데이트 패키지들에 대해 동일한 검증 데이터를 반영할 수 있도록 로컬 로그들을 지속적으로 업데이트하고 서로 동기화한다.

신뢰할 수 있는 분산 시스템(들)에 의해서만 업데이트 패키지들이 릴리즈되므로, 신뢰할 수 있는 분산 시스템(들)은 커뮤니티의 모든 차량들에 전파될 수 있는 검증 데이터를 생성하고 그에 따라 로컬 로그들을 업데이트하고 동기화할 수 있는 시스템들이다. 게다가, 로컬 로그들의 악의적인 조작 및/또는 변경을 방지하기 위해, 신뢰할 수 있는 분산 시스템(들)은 하나 이상의 단방향 암호화 알고리즘을 적용하여 복수의 분산 로컬 로그들에서 불변 데이터 블록들, 예를 들어, 블록체인의 분산 원장을 생성할 수 있다.

이와 같이, 수신된 업데이트 패키지를 검증하기 위해, 업데이트 에이전트 차량은 각각 자신의 로컬 로그를 유지하는 차량 서브셋과 통신할 수 있으며 모든 로그들은 커뮤니티의 모든 다른 차량들의 로컬 로그들과 동기화된다.

이러한 차량들의 동기화된 로컬 로그들로부터 추출된 검증 데이터에 따라 달성된(결정된) 적어도 차량 서브셋의 다수의 컨센서스에 기초하여, 업데이트 에이전트는 수신된 업데이트 패키지가 유효한지 유효하지 않은 지 여부를 결정할 수 있다. 컨센서스를 설정하는 데 필요한 서브셋의 차량 수는 미리 정의된 임계값, 즉 커뮤니티의 하나 이상의 보안 파라미터들에 따라 설정될 수 있는 미리 정의된 차량 수 이상이어야 한다. 이러한 보안 파라미터들은 예를 들어 커뮤니티의 전체 차량 수, 차량의 지리적 분포, 커뮤니티 유형(예를 들어, 개인 소유 차량들, 조직 차량들 등), 차량들 간에 교환되는 데이터의 보안 레벨(예를 들어, 암호화, 인증 등), 제어 평면 프로토콜(들)의 유형, 쿼리된 업데이트 패키지의 중요도 등을 포함할 수 있다.

수신된 업데이트 패키지가 유효한 것으로 결정되는 경우, 업데이트 에이전트는 업데이트 패키지를 사용하여 검증된 업데이트 패키지가 타겟으로 하는 ECU(들)를 업데이트하기 위한 업데이트 세션을 개시할 수 있다. 그러나, 수신된 업데이트 패키지가 유효하지 않은 것으로 결정되는 경우, 업데이트 에이전트는 업데이트 패키지를 폐기할 수 있다.

수신된 업데이트 패키지가 차량의 ECU(들)로 향하는지 향하지 않는지 여부에 관계없이, 업데이트 에이전트는 커뮤니티의 하나 이상의 다른 차량들, 특히 V2V 통신 채널(들)을 통한 통신이 설정된 부딪히는 주변 차량들에 전송하기 위해 업데이트 패키지를 일시적으로 저장한다.

게다가, 예를 들어 블록체인과 같은 신뢰할 수 있는 플랫폼 제어 평면은 차량들의 식별 정보, 예를 들어 커뮤니티의 일부인 차량들의 아이덴티티(ID)를 기록하는 데 더 사용될 수 있다. 예를 들어, 각 차량의 차량 식별 번호(VIN)는 차량 아이덴티티가 신뢰할 수 있는 분산 시스템들 중 하나 이상에 의해 적절히 검증된 후 신뢰할 수 있는 플랫폼에 등록될 수 있다.

이와 같이, 각 차량에 의해 저장된 로컬 로그는 커뮤니티의 차량들의 식별 정보를 포함할 수 있다. 로컬 로그에서 로컬로 이용 가능한 식별 정보를 사용하여, 차량들 중 하나 이상은 업데이트 패키지(들)를 수신하기 위해 및/또는 업데이트 패키지(들)를 검증하기 위해 설정된 통신 세션 동안 서로를 인증하여 다른 차량이 커뮤니티의 진정한 구성원인지 검증할 수 있다.

현대의 차량들은 차량 시스템을 제어하기 위한 다양한 유형의 매우 많은 수의 ECU들을 포함할 수 있으므로 차량 커뮤니티에서 매우 많은 수의 업데이트 패키지들이 릴리즈되고 순환될 수 있다. 추가로, 커뮤니티의 차량들은 동적이고 이동적이므로 이들은 인근 많은 주변 차량들과 마주칠 수 있다. 이러한 이유들로 인해, 업데이트 패키지들을 주변 차량들로 전송하기 위해 차량이 관여할 수 있는 전송 세션의 수는 매우 클 수 있다.

그러나, 차량 ECU들, 특히 업데이트 에이전트를 실행하는 업데이트 시스템들은 일반적으로 제한된 저장 장치(예를 들어, 저장 용량)을 가질 수 있으므로, 이러한 매우 많은 수의 업데이트 패키지 전송 세션들을 추적(로깅, 기록)하는 것은 실제로 불가능할 수 있다. 이러한 업데이트 패키지 전송을 추적하고 어떤 업데이트 패키지들이 어떤 차량들에 전송되었는지 결정할 수 없는 것은 동일한 업데이트 패키지가 불필요하게 여러 번 전송되는 다수의 중복 전송 세션들로 이어질 수 있다. 예를 들어, 특정 차량은 동일한 업데이트 패키지(들)를 동일한 주변 차량(들)에 여러 번 전송할 수 있다. 또한, 특정 차량은 다수의 주변 차량들로부터 동일한 업데이트 패키지를 여러 번 수신할 수 있다.

이러한 중복되고 불필요한 전송 세션들은 V2V 통신 채널(들)의 네트워크 활용을 크게 증가시켜 차량 간의 통신 세션의 효율성을 크게 감소시킬 수 있다. 이는 업데이트 에이전트들이 동일한 업데이트 패키지(들)의 복제된 복사본들을 처리하는 데 필요한 컴퓨팅 리소스들의 상당한 증가로 더 이어질 수 있다.

V2V 통신 채널(들)의 네트워크 성능을 최적화하기 위해, 업데이트 패키지들의 복제본들을 전송하기 위한 중복 및 불필요한 전송 세션들을 크게 줄이고 잠재적으로 방지하기 위해 커뮤니티의 차량들에 의해 여러 네트워크 최적화 조치들이 적용될 수 있다.

전송 측에서, 차량들 중 하나 이상에 의해 실행되는 업데이트 에이전트는 동일한 업데이트 패키지의 전송을 여러 번 비활성화하도록 구성될 수 있다. 예를 들어, 특정 업데이트 패키지를 전송한 후, 업데이트 에이전트는 특정 업데이트 패키지가 전송되지 않는 미리 정의된 비전송 시간 기간 동안 비전송 상태에 들어갈 수 있다.

수신 측에서, 차량들 중 하나 이상에 의해 실행되는 업데이트 에이전트는 업데이트 패키지를 수신한 후 미리 정의된 비수신 시간 기간 동안 추가 업데이트 패키지들의 수신을 비활성화하도록 구성될 수 있다.

비-전송 시간 기간 및/또는 비-수신 시간 기간은 업데이트 에이전트를 실행하는 차량의 하나 이상의 동작 파라미터들, 예를 들어 차량이 위치되는 지리적 영역, 차량의 주변 지형, 차량의 온/오프 상태, 차량(202)의 속도 등에 따라 조정될 수 있다.

선택적으로, 특정 업데이트 패키지를 수신하기 위해 하나 이상의 다른 차량들과 통신할 때, 업데이트 에이전트는 특정 업데이트 패키지가 이전에 이미 수신되었는지 여부를 확인하기 위해 일시적으로 저장된 로컬 업데이트 패키지들(이 존재함)을 확인할 수 있다. 특정 업데이트 패키지가 로컬에서 사용 가능한 경우, 업데이트 에이전트는 중복 전송 세션을 피하기 위해 특정 업데이트 패키지의 수신을 거부할 수 있다.

차량 ECU들에 대한 업데이트 패키지들을 분산하고 차량 커뮤니티의 컨센서스에 따라 이러한 업데이트 패키지들을 검증하는 것은 차량의 ECU들에 업데이트들을 전달하는 현재 기존 방법들 및 시스템들에 비해 상당한 이점들을 제시할 수 있다.

우선, 업데이트 패키지들의 분산은 기존 방법들로 수행될 수 있는 제한된 수의 중앙 집중식 분산 시스템들로부터 업데이트 패키지들을 전달하는 대신 차량 간에 업데이트 패키지들의 직접 전달에 의존한다.

중앙 집중식 접근 방식으로, 차량들 각각은 중앙 집중식 분산 시스템(들)에 개별적으로 액세스할 수 있다. 매우 많은 수의 차량들로 인해, 이러한 개별 액세스는 차량들을 중앙 집중식 분산 시스템(들)에 연결하는 네트워크에 상당한 부하를 줄 수 있다. 이 제한은 업데이트가 필요할 수 있는 ECU들의 수가 많고 매우 다양하기 때문에 더욱 증가될 수 있다. 네트워크 과부하는 당연히 서비스 불량, 높은 레이턴시 및 선택적으로 수신된 업데이트 패키지들의 신뢰성 감소로 이어질 수 있다. 게다가, 기존 방법들에 의해 수행될 수 있는 중앙 집중식 분산 시스템(들)과 통신하려면 차량들에 인프라 네트워크 기능들이 필요할 수 있다. 예를 들어, 차량들에는 장거리 네트워크 기능들, 예를 들어 셀룰러 네트워크 등이 장착될 수 있으며, 이는 비용이 많이 들고 따라서 차량들에 배치된 업데이트 시스템의 비용을 증가시킬 수 있다. 추가로, 이러한 셀룰러 네트워크 링크들의 서비스 비용은 상당히 높을 수 있으므로 업데이트 패키지들을 전달하는 비용을 더욱 증가시킬 수 있다. 다른 예에서, 차량들은 근거리 무선 인프라 네트워크 기능들, 예를 들어 근거리 무선 통신망(WLAN) 등이 장착될 수 있다. 이러한 네트워크 연결들은 유선 네트워크의 경우 네트워크에 대한 차량의 물리적 연결 및/또는 근거리 무선 인프라의 액세스 포인트에 근접하게 차량을 배치하는 것을 요구할 수 있다. 이는 차량들이 이러한 위치들에 위치된 특정 위치들 및 시간들에 업데이트 패키지 전달을 당연히 제한한다.

그에 반해, V2V 통신 채널들을 통해 차량 간에 업데이트 패키지들을 분산하는 것은 기존 방법들로 수행될 수 있는 중앙 집중식 분산 시스템(들)과 통신하기 위한 네트워크 과부하를 상당히 줄이고 잠재적으로 방지할 수 있다. 게다가, V2V 통신 채널들의 비용과 복잡도는 중앙 집중식 분산 시스템(들)과 통신하는 데 필요한 통신 수단들보다 상당히 낮을 수 있다. V2V 통신 채널들을 통한 통신에 대한 서비스 비용은 또한 중앙 집중식 분산 시스템(들)과 통신하는 데 필요한 통신 수단들의 서비스 비용에 비해 무시할 수 있다.

업데이트 패키지들은 차량들의 통신 범위가 제한되어 있다는 사실에도 불구하고 차량 커뮤니티 내에서 빠르고 효율적으로 확산 및 분산될 수 있다. 이는 차량과 커뮤니티에 내재된 두 가지 주요 사실 때문이다. 첫째, 차량들은 이동적이며 지리적 영역과 위치 사이를 이동하므로 커뮤니티의 다른 차량들과 자주 마주친다. 둘째, 많은 수의 차량들은 차량들이 마주치는 빈도를 더욱 증가시킨다. 매우 많은 수의 차량들 각각이 업데이트 패키지(들)의 캐리어 역할을 할 수 있기 때문에, 이러한 매우 빈번한 마주침 동안 업데이트 패키지들은 커뮤니티의 차량 간에 빠르게 확산되도록 교환될 수 있다.

더욱이, 커뮤니티에서 신뢰할 수 없는 차량들 사이에 신뢰할 수 있는 플랫폼을 설정하도록 지시된 분산 컴퓨팅 방법들, 알고리즘들 및/또는 프로토콜들을 적용하면 기존 방법들에 의해 수행될 수 있는 업데이트 패키지들의 유효성을 확인하는 데 사용될 수 있는 중앙 집중식의 신뢰할 수 있는 엔티티의 부족을 극복할 수 있다.

커뮤니티의 차량들 각각은 로컬 로그를 유지해야 할 수 있지만, 로컬 로그는 이가 각자의 검증 데이터, 특히 제한된 크기의 해시 값과 관련된 각 릴리즈된 업데이트 패키지의 식별자만 포함하므로 크기(볼륨)가 매우 제한될 수 있다. 이와 같이, 각 차량의 로컬 로그를 마리네이드하는 데 필요한 저장 리소스들은 매우 제한적이며 상당히 작을 수 있다.

추가로, 네트워크 최적화 조치들을 적용하면 V2V 통신 채널들을 통해 설정된 네트워크의 최소 활용도와 이에 따른 높은 성능 및/또는 낮은 레이턴시를 보장할 수 있지만, 업데이트 패키지 전송 세션의 추적(기록)을 방지하여 업데이트 패키지 추적 및 로깅을 위해 높은 저장 리소스들을 할당할 필요성을 피할 수 있다. 더욱이, 네트워크 최적화 조치들을 적용하면 업데이트 패키지들의 복제 사본들을 전송하기 위한 중복 전송 세션들을 처리하기 위해 차량들에 필요한 계산 리소스들을 크게 줄일 수 있다.

본원에 설명된 적어도 하나의 실시예를 상세하게 설명하기 전에, 실시예들은 구성의 세부 사항 및 다음의 설명에 제시되고/되거나 도면들 및/또는 예들에 예시된 컴포넌트들 및/또는 방법들의 배열에 그 적용으로 반드시 제한되지 않는다는 것을 이해해야 한다. 본원에 설명된 실시예들은 다른 실시예들이 가능하거나 다양한 방식들로 실시 또는 수행될 수 있다.

본원에 설명된 실시예는 시스템, 방법 및/또는 컴퓨터 프로그램 제품을 포함할 수 있다. 컴퓨터 프로그램 제품은 프로세서가 본원에 설명된 실시예의 양태들을 수행하게 하기 위한 컴퓨터 판독 가능 프로그램 인스트럭션들을 갖는 컴퓨터 판독 가능 저장 매체(또는 매체들)를 포함할 수 있다.

컴퓨터 판독 가능 저장 매체는 인스트럭션 실행 장치에 의해 사용하기 위한 인스트럭션들을 보유하고 저장할 수 있는 유형의 장치일 수 있다. 컴퓨터 판독 가능 저장 매체는, 예를 들어, 이에 제한되는 것은 아니나, 전자 저장 장치, 자기 저장 장치, 광학 저장 장치, 전자기 저장 장치, 반도체 저장 장치, 또는 전술한 것들의 임의의 적절한 조합일 수 있다. 컴퓨터 판독 가능 저장 매체의 보다 구체적인 예들의 비포괄적인 목록은 다음을 포함한다: 휴대용 컴퓨터 디스켓, 하드 디스크, 랜덤 액세스 메모리(RAM), 읽기 전용 메모리(ROM), 소거 가능한 프로그램 가능 읽기 전용 메모리(EPROM 또는 플래시 메모리), 정적 랜덤 액세스 메모리(SRAM), 휴대용 컴팩트 디스크 읽기 전용 메모리(CD-ROM), 디지털 다목적 디스크(DVD), 메모리 스틱, 플로피 디스크, 인스트럭션들이 기록된 홈의 돌출 구조 또는 펀치 카드와 같은 기계적으로 인코딩된 장치, 및 전술한 것의 임의의 적절한 조합. 본원에 사용된 컴퓨터 판독 가능 저장 매체는 전파 또는 기타 자유롭게 전파하는 전자기파, 도파관 또는 기타 전송 매체를 통해 전파하는 전자기파(예를 들어, 광섬유 케이블을 통해 통과하는 광 펄스들) 또는 전선을 통해 전송되는 전기 신호들과 같은, 일시적 신호들 그 자체로 해석되어서는 안된다.

본원에 설명된 컴퓨터 판독 가능 프로그램 인스트럭션들은 컴퓨터 판독 가능 저장 매체로부터 각각의 컴퓨팅/처리 장치들로, 또는 네트워크, 예를 들어, 인터넷, 근거리 통신망, 광역 통신망 및/또는 무선 네트워크를 통해 외부 컴퓨터 또는 외부 저장 장치로 다운로드될 수 있다. 네트워크는 구리 전송 케이블, 광 전송 섬유, 무선 전송, 라우터, 방화벽, 스위치, 게이트웨이 컴퓨터 및/또는 에지 서버를 포함할 수 있다. 각 컴퓨팅/처리 장치의 네트워크 어댑터 카드 또는 네트워크 인터페이스는 네트워크로부터 컴퓨터 판독 가능한 프로그램 인스트럭션들을 수신하고 각자의 컴퓨팅/처리 장치 내의 컴퓨터 판독 가능한 저장 매체에 저장하기 위해 컴퓨터 판독 가능 프로그램 인스트럭션들을 포워딩한다.

본원에 설명된 실시예의 동작들을 수행하기 위한 컴퓨터 판독 가능 프로그램 인스트럭션들은 어셈블러 인스트럭션들, 인스트럭션 세트 아키텍처(ISA) 인스트럭션들, 기계 인스트럭션들, 기계 인스트럭션들, 마이크로코드, 펌웨어 인스트럭션들, 상태 설정 데이터, 또는 소스 코드 또는 스몰토크, C++ 등과 같은 객체 지향 프로그래밍 언어와 "C" 프로그래밍 언어 또는 유사한 프로그래밍 언어와 같은 기존의 절차형 프로그래밍 언어들을 포함하는 하나 이상의 프로그래밍 언어들의 임의의 조합으로 작성된 객체 코드일 수 있다.

컴퓨터 판독 가능한 프로그램 인스트럭션들은 사용자의 컴퓨터에서, 부분적으로 사용자의 컴퓨터에서, 독립형 소프트웨어 패키지로서, 부분적으로 사용자의 컴퓨터에서, 그리고 부분적으로 원격 컴퓨터에서, 또는 전체적으로 원격 컴퓨터 또는 서버에서 실행될 수 있다. 후자의 시나리오에서, 원격 컴퓨터는 근거리 통신망(LAN) 또는 광역 통신망(WAN)을 포함한 모든 유형의 네트워크를 통해 사용자의 컴퓨터에 연결될 수 있거나, 또는 (예를 들어, 인터넷 서비스 공급자를 사용하여 인터넷을 통해) 외부 컴퓨터에 연결이 이루어질 수 있다. 일부 실시예들에서, 예를 들어, 프로그램 가능 로직 회로부, 필드 프로그램 가능 게이트 어레이(FPGA), 또는 프로그램 가능 로직 어레이(PLA)를 포함하는 전자 회로부는, 본원에 설명된 실시예의 양태들을 수행하기 위해, 전자 회로를 개인화하기 위해 컴퓨터 판독 가능 프로그램 인스트럭션들의 상태 정보를 활용함으로써 컴퓨터 판독 가능 프로그램 인스트럭션들을 실행할 수 있다.

본원에 설명된 실시예의 양태들은 방법들, 장치들(시스템들) 및 컴퓨터 프로그램 제품들의 흐름도들 및/또는 블록도들을 참조하여 설명된다. 흐름도들 및/또는 블록도들의 각 블록, 및 흐름도들 및/또는 블록도들의 블록들의 조합들은 컴퓨터 판독 가능 프로그램 인스트럭션들에 의해 구현될 수 있음이 이해될 것이다.

도면들의 흐름도 및 블록도는 본원에 설명된 다양한 실시예들에 따른 시스템들, 방법들 및 컴퓨터 프로그램 제품들의 가능한 구현예들의 아키텍처, 기능 및 동작을 예시한다. 이와 관련하여, 흐름도 또는 블록도의 각 블록은 지정된 논리 기능(들)을 구현하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 인스트럭션들의 일부를 나타낼 수 있다. 일부 대안적인 구현예들에서, 블록에 언급된 기능들은 도면들에 언급된 순서를 벗어나서 발생할 수 다. 예를 들어, 연속으로 도시된 2 개의 블록들은 실제로 실질적으로 동시에 실행될 수 있으며, 또는 수반되는 기능들에 따라 상기 블록들이 때때로 역순으로 실행될 수 있다. 또한, 블록도들 및/또는 흐름도의 각 블록 및 블록도들 및/또는 흐름도의 블록들의 조합은 특정 기능들 또는 동작들을 수행하거나 특수 목적 하드웨어와 컴퓨터 인스트럭션들의 조합을 수행하는 특수 목적의 하드웨어 기반 시스템들에 의해 구현될 수 있음이 주목될 것이다.

이제 도면들을 참조하면, 도 1은 본원에 설명된 일부 실시예에 따른, V2V 통신 채널들을 통해 수신되고 차량 컨센서스에 의해 검증된 업데이트 패키지들을 사용하여 차량들의 ECU들을 업데이트하는 예시적인 프로세스의 흐름도이다. 예시적인 프로세스(100)는 하나 이상의 다른 차량들, 특히, V2V 통신 채널(들)의 수신 범위 내에 있는 주변 차량들로부터 하나 이상의 V2V 통신 채널들을 통해 수신된 업데이트 패키지들을 사용하여 각각의 차량에 배치된 하나 이상의 ECU들을 업데이트하기 위한 복수의 차량들을 포함하는 커뮤니티의 하나 이상의 차량들에 의해 실행될 수 있다. 예를 들어, 차량들에 분산되는 펌웨어 업데이트, 미들웨어 업데이트, 소프트웨어 업데이트 등과 같은, 업데이트 패키지들은 일반적으로 예를 들어, 자동차 제조사, 자동차 정비 서비스 제공자, ECU 제공자, 소프트웨어 제공자 등과 같은, 하나 이상의 신뢰할 수 있는 공급업체와 관련된 하나 이상의 신뢰할 수 있는 분산 시스템들에서 비롯될 수 있다.

V2V 통신 채널들은 일반적으로 제한된 수신 범위(예를 들어, 400미터) 및 이에 따라 제한된 수신 영역을 갖는 근거리 통신 채널들이다. 따라서 업데이트 패키지들은 V2V 통신 채널들의 수신 범위 내에 있는 주변 차량들 간에 전송될 수 있다.

그러나, 업데이트 패키지들은 차량들의 통신 범위가 제한되어 있다는 사실에도 불구하고 차량 커뮤니티 내에서 빠르고 효율적으로 확산 및 분산될 수 있다. 이는 차량 자체와 차량 커뮤니티에 내재된 두 가지 주요 사실 때문이다. 첫째, 차량들은 이동적이며 지리적 영역과 위치 사이를 이동하므로 커뮤니티의 다른 차량들과 자주 마주친다. 둘째, 많은 수의 차량들은 차량들이 마주치는 빈도를 더욱 증가시킨다. 여기서, 마주침은 커뮤니티의 두 대 이상의 차량들이 서로 가까이 있는 시간 기간으로서, 즉 서로의 V2V 통신 채널(들) 수신 영역(범위) 내에 있다. 이러한 마주침 동안 주변 차량들은 V2V 통신 채널들을 통해 서로 통신 세션을 설정하여, 서로 데이터를 교환하며, 특히 하나 이상의 업데이트 패키지들을 전송한다. 선택적으로, 차량들 중 하나 이상은 하나 이상의 주변 차량들과 설정된 복수의 수신 통신 세션 동안 업데이트 패키지의 하나 이상의 부분들을 수신함으로써 누적 방식으로 업데이트 패키지 중 하나 이상을 수신한다.

차량이 업데이트 패키지를 수신할 때마다 먼저 수신된 업데이트 패키지가 적용 가능한지 여부, 즉 수신된 업데이트 패키지가 차량에 배치된 하나 이상의 ECU들(즉, 타겟들)로 향하는지 여부를 확인하며, 그렇다면 타겟 ECU(들)가 수신된 업데이트 패키지를 사용하여 업데이트되어야 하는지 여부를 확인한다. 업데이트 패키지가 차량의 ECU(들)를 타겟으로 하는 것으로 결정된 경우, 차량은 수신된 업데이트 패키지가 유효한지, 즉 정품인지 그리고 신뢰할 수 있는 분산 시스템(들)에 의해 원래 릴리즈된 대로 변조되지 않는지를 확인하기 위해 다른 차량들 중 적어도 일부를 포함하는 그룹(서브셋)과 통신할 수 있다.

업데이트 패키지 검증을 용이하게 하기 위해, 커뮤니티의 차량들 각각은 신뢰할 수 있는 분산 시스템(들)에 의해 릴리즈된 모든 업데이트 패키지들, 특히 릴리즈된 업데이트 패키지들의 식별 정보를 기록하는 로컬 로그를 유지한다. 로컬 로그는 릴리즈된 업데이트 패키지들 각각을 검증 코드와 추가로 연관시킨다. 커뮤니티의 모든 차량들의 로컬 로그들은 모든 로그들이 동일한 업데이터 페이지 및 관련 검증 코드들을 반영하도록 지속적으로 업데이트되고 서로 동기화된다.

그 로컬 로그들에 기초하여, 업데이트 패키지의 유효성을 요청하는 차량에 의해 접근된 차량 그룹은 업데이트 패키지가 유효한지 유효하지 않은 지 여부를 의 유효 여부를 명시하는 차량에 응답할 수 있다. 그런 다음, 차량은 차량 그룹 구성원 간의 컨센서스에 기초하여 업데이트 패키지가 유효한지 여부를 결정 수 있다. 업데이트 패키지가 유효한 것으로 결정되는 경우, 차량은 타겟 ECU(들)을 업데이트하는 데 이를 사용할 수 있다. 그렇지 않은 경우, 차량은 업데이트 패키지를 폐기할 수 있다.

업데이트 패키지가 차량의 ECU(들)로 향하는지 여부에 관계없이, 차량은 특정 시간 기간 내에 마주친 커뮤니티의 하나 이상의 다른 차량들로의 전송을 위해 업데이트 패키지를 일시적으로 저장할 수 있다.

본원에 설명된 일부 실시예들에 따른, V2V 통신 채널들을 통해 수신되고 차량 컨센서스에 의해 검증된 업데이트들을 사용하여 차량들의 ECU들을 업데이트하는 예시적인 시스템의 개략도인, 도 2에 대한 참조가 이루어진다. 예시적인 업데이트 시스템(200)은 프로세스(100)와 같은 프로세스를 실행하기 위해 차량(202) 커뮤니티의 하나 이상의 차량들(202)에 배치될 수 있다. 업데이트 시스템(200)은 네트워크 인터페이스(210), 프로세서(들)(212), 저장 장치(214) 및 입력/출력(I/O) 인터페이스(216)를 포함할 수 있다.

네트워크 인터페이스(210)는 하나 이상의 인터페이스, 특히 하나 이상의 V2V 통신 채널들, 예를 들어 근거리 무선 통신망(WLAN, 예를 들어 Wi-Fi), 전용 근거리 통신(DSRC), 5G(5세대) 셀룰러 네트워크 직접 장치 간(Device-to-Device; D2D) 사이드 링크 등에 연결하기 위한 무선 인터페이스들을 포함할 수 있다. 네트워크 인터페이스(210)는 하나 이상의 인프라 네트워크, 예를 들어, 셀룰러 네트워크, WLAN, 근거리 통신망(LAN), 인터넷 등에 연결하기 위한 하나 이상의 인터페이스들을 더 포함할 수 있다.

동종 또는 이종 프로세서(들)(212)는 클러스터로서 및/또는 하나 이상의 멀티 코어 프로세서(들)로서 병렬 처리를 위해 배열된 하나 이상의 프로세서들을 포함할 수 있다. 프로그램 코드(프로그램 저장소) 및/또는 데이터를 저장하는 데 사용되는 저장 장치(214)는 하나 이상의 비일시적 영구 저장 장치들, 예를 들어 읽기 전용 메모리(ROM) 컴포넌트, 하드 드라이브, 플래시 어레이 등을 포함할 수 있다. 저장 장치(212)는 하나 이상의 휘발성 장치들, 예를 들어 랜덤 액세스 메모리(RAM) 컴포넌트, 캐시 메모리 등을 더 포함할 수 있다.

I/O 인터페이스(216)는 차량(202)에 배치된 하나 이상의 ECU(230)에 연결하기 위한 하나 이상의 유선 및/또는 무선 인터페이스들을 포함할 수 있다. I/O 인터페이스(216)는 하나 이상의 네트워크 인터페이스들, 예를 들어, WLAN 인터페이스, LAN 인터페이스, 제어 영역 네트워크(Control Area Network; CAN) 버스, 항공 무선 인코포레이티(Aeronautical Radio Incorporated; ARINC) 네트워크, 블루투스 저 에너지(BLE) 인터페이스, 무선 주파수(RF) 인터페이스 등을 포함할 수 있다. I/O 인터페이스(216)는 하나 이상의 유선 상호접속, 예를 들어 직렬 버스, 범용 직렬 버스(USB) 등을 연결하기 위한 하나 이상의 유선 인터페이스들을 포함할 수 있다.

차량(202)에 배치된 ECU들(230)은 차량(202) 시스템, 예를 들어, 엔진 제어 시스템, 전송 제어 시스템, 제동 시스템, 조명 시스템, 인포테인먼트 시스템, 내비게이션 시스템, 통신 시스템, 도어록, 윈도우 리프트 시스템 중 하나 이상을 제어할 수 있다. ECU들(230) 각각은 프로세서(212)와 같은 프로세서(들), 저장 장치(214)와 같은 저장 장치, I/O 인터페이스(218)와 같은 I/O 인터페이스 및 선택적으로 네트워크 인터페이스(210)와 같은 네트워크 인터페이스를 포함할 수 있다.

프로세서(들)(212)는 예를 들어 저장 장치(214)와 같은 비일시적 매체(프로그램 저장소)에 저장되고 프로세서(들)(212)와 같은 하나 이상의 프로세서들에 의해 실행된 복수의 프로그램 인스트럭션들을 각각 포함하는 프로세스, 스크립트, 애플리케이션, 에이전트, 유틸리티, 도구 등과 같은 하나 이상의 소프트웨어 모듈들을 실행할 수 있다. 예를 들어, 프로세서(들)(212)는 프로세스(100)를 실행하기 위한 업데이트 에이전트(220)를 실행하여 하나 이상의 주변 차량들(202)으로부터 수신되고 유효한 업데이트 패키지인 것으로 확인된 패키지 업데이트에 의해 타겟이 되는 ECU들(230) 중 하나 이상에 업데이트하기 시작할 수 있다. 업데이트 에이전트(220)는 프로세스(100)를 실행하기 위해 하나 이상의 하드웨어 요소들, 예를 들어, 회로, 컴포넌트, 집적 회로(IC), 주문형 반도체(ASIC), 필드 프로그램 가능 게이트 어레이(FPGA), 디지털 신호 프로세서(DSP) 등을 더 활용할 수 있다.

프로세서(들)(212)는 추가로 하나 이상의 데이터 세트들, 예를 들어, 저장 장치(214)에 저장된 파일, 레코드, 테이블 등에 추가로 액세스, 유지 및/또는 업데이트할 수 있다. 특히, 로컬 로그 데이터 세트(222)는 업데이트 패키지들 각각을 업데이트 패키지들의 유효성을 확인하는 데 사용되는 각각의 검증 코드와 연관시키기 위해 저장 장치(214)에 저장될 수 있다. 로컬 로그(222)는 식별 정보, 예를 들어 커뮤니티의 구성원들인 모든 차량들(202)의 VIN을 더 포함할 수 있다. 따라서, 프로세서(들)(212)는 하나 이상의 소프트웨어 모듈들, 예를 들어 업데이트 에이전트(220), 전용 소프트웨어 모듈 및/또는 이들의 조합을 실행하여 로컬 로그(222)에 액세스, 유지 및/또는 업데이트할 수 있다.

업데이트 시스템(200)은 차량(202)에 배치된 전용 시스템일 수 있다. 선택적으로, 업데이트 시스템(200)은 통합 ECU(들)(230)가 프로세스(100)를 실행하기 위해 업데이트 에이전트(220)를 실행하도록 ECU들(230) 중 하나 이상에 통합될 수 있다.

본원에 설명된 일부 실시예들에 따르면, 차량(202)과 물리적으로 독립적인 모바일 장치는 하나 이상의 업데이트 패키지들을 수신하고, 이들을 검증하고, 검증된 업데이트 패키지(들)를 사용하여 각각의 타겟 ECU(들)의 업데이트를 시작하기 위한 프로세스(100)의 실행을 지원하는 데 활용될 수 있다.

본원에 설명된 일부 실시예들에 따른, V2V 통신 채널들을 통해 수신되고 차량 컨센서스에 의해 검증된 업데이트들을 사용하여 차량들의 ECU들을 업데이트하기 위해 연관 모바일 장치를 사용하는 시스템의 예시적인 실시예들의 개략도들인, 도 3a 및 3b에 대한 참조가 이제 이루어진다. 차량(202)과 같은 하나 이상의 차량들은 프로세스(100)와 같은 프로세스의 실행을 지원하기 위해 각각의 차량(202)로부터 물리적으로 독립적인 하나 이상의 모바일 장치들(240), 예를 들어 스마트폰, 태블릿, 랩탑 컴퓨터, 스마트 시계, 웨어러블 장치 등과 연관될 수 있다.

모바일 장치(240)는 통신 인터페이스(210)와 같은 통신 인터페이스, 프로세서(들)(212)와 같은 프로세서(들) 및 저장 장치(214)와 같은 저장 장치를 포함한다. 모바일 장치(240)의 프로세서(들)는 모바일 장치(240)의 저장 장치로부터 하나 이상의 소프트웨어 모듈들을 실행할 수 있다.

특정 차량(202)과 연관된 모바일 장치(240)는 하나 이상의 업데이트 패키지들을 수신하고, 업데이트 패키지(들)를 검증하고, ECU들(230)과 같은 하나 이상의 ECU들에서 업데이트 프로세스를 시작하는 데 적극적으로 참여할 수 있다. 그러나, 특정 차량(202)과 연관된 모바일 장치(240)는 하나 이상의 네트워크들, 특히 다른 차량들(202)과 통신하기 위한 V2V 통신 채널들에 대한 액세스를 업데이트 시스템(200)과 같은 업데이트 시스템에 제공하기 위해 중개자, 즉 프록시, 게이트웨이 등의 역할만 할 수 있다.

도 3a에 보이는 바와 같이, 차량(202)과 물리적으로 독립적인 모바일 장치(240)는 업데이트 시스템(200)과 같은 업데이트 시스템의 역할을 하도록 차량(202)과 연관(페어링)될 수 있으며, 업데이트 에이전트(220)와 같은 업데이트 에이전트를 실행할 수 있다. 연관된 모바일 장치(240)는 로컬 로그(222)와 같은 로컬 로그를 더 저장할 수 있다. 업데이트 에이전트(220)를 실행하는 각각의 모바일 장치(240)는 이러한 특정 모바일 장치(240)가 특정 차량(202)과 고유하게 페어링(일대일 관계)되고 따라서 특정 모바일 장치(240)가 특정 차량(202)의 부분 또는 확장으로 간주되는 특정 차량(202)에 대응한다.

모바일 장치(240)에 의해 실행되는 업데이트 에이전트(220)는 다른 차량들(202) 중 하나 이상과 통신할 수 있다. 업데이트 에이전트(220)는 차량(202)에 배치되고 ECU들(230)과 같은 복수의 ECU들과 통신할 수 있는 액세스 시스템(250)과 추가로 통신할 수 있다. 선택적으로, 액세스 시스템(250)은 차량(202)의 ECU들(230) 중 하나 이상에 의해 활용된다. 모바일 장치(240)는 하나 이상의 유선 및/또는 무선 통신 채널들을 통해 액세스 시스템(250)과 통신할 수 있다. 예를 들어, 모바일 장치(240)는 그들 사이에 설정된 WLAN 네트워크를 통해 액세스 시스템(250)과 통신할 수 있다. 다른 예에서, 모바일 장치(240)는 유선 상호접속 인터페이스, 예를 들어 액세스 시스템(250)의 USB 포트에 연결될 수 있는 USB 포트를 포함할 수 있다. 선택적으로, 모바일 장치(240)는 모바일 장치(240)와 ECU(들)(230) 사이에 설정된 하나 이상의 유선 및/또는 무선 채널들을 통해 ECU들(230) 중 하나 이상과 직접 통신한다. 예를 들어, 모바일 장치(240)는 BLE 채널을 통해 ECU들(230) 중 하나 이상에 연결할 수 있다. 다른 예에서, 모바일 장치(240)의 직렬 인터페이스는 ECU들(230) 중 하나 이상을 연결하는 차량(202)의 하나 이상의 직렬 채널들에 연결될 수 있다.

모바일 장치(240)는 ECU들(230) 중 하나 이상에 대한 액세스를 모바일 장치(240)에 제공하기 위해 모바일 장치(230)와 액세스 시스템(250) 사이에 신뢰할 수 있고 안전한 통신 링크가 설정되도록 차량(202)과 연관(페어링)될 수 있다. 특히, 모바일 장치(240)에 의해 실행되는 업데이트 에이전트(220)와 액세스 시스템(250)에 의해 실행되는 차량 에이전트(260) 사이에 신뢰할 수 있고 안전한 통신 링크가 설정된다.

모바일 장치(240)를 차량(202)과 페어링하는 것은 액세스 시스템(250)과의 신뢰할 수 있고 안전한 통신 링크를 설정하기 위해 당업계에 알려진 하나 이상의 보안 방법들, 기술들 및/또는 구현들을 사용하여 수행될 수 있다. 예를 들어, 차량(202)의 사용자(예를 들어, 운전자, 소유자 등)가 모바일 장치(240) 및 액세스 시스템(250) 모두에 암호를 삽입하는 암호 기반 프로토콜이 적용될 수 있다. 그런 다음, 패스워드는 모바일 장치(240)와 액세스 시스템(250) 사이의 신뢰할 수 있고 안전한 통신 링크를 설정하기 위해 사용될 수 있다.

도 3b에 보이는 바와 같이, 모바일 장치(240)는 하나 이상의 네트워크들, 특히 다른 차량들(202)과 통신하기 위한 V2V 통신 채널들에 대한 액세스를 업데이트 시스템(200)에 제공하기 위해 업데이트 시스템(200)과 같은 업데이트 시스템에 대한 프록시 서버의 역할을 할 수 있다. 이러한 배치에서, 업데이트 시스템(200)은 업데이트 에이전트(220)를 실행하고 일반적으로 로컬 로그(222)를 저장한다. 이를 위해, 모바일 장치(240)는 업데이트 시스템(200)에 의해 실행되는 업데이트 에이전트(220)와 다른 차량들(202) 사이에서 교환되는 네트워크 트래픽을 지시하기 위해 프록시 에이전트(270)를 실행할 수 있다.

이제 본원에 설명된 일부 실시예들에 따른, 차량들의 ECU들에 대한 업데이트 패키지들을 분산하고 검증하기 위해 V2V 통신 채널들을 사용하는 네트워크 차량들의 예시적인 커뮤니티의 개략도인, 도 4에 대한 참조가 이루어진다. 차량 커뮤니티(400)는 V2V 통신 채널들 중 하나 이상을 통해 서로 통신할 수 있는 차량(202)과 같은 복수의 차량들을 포함할 수 있다.

커뮤니티(400)의 차량들(202)은 서로 통신하여 두 개의 데이터 분산 평면들을 설정할 수 있으며, 첫 번째는 업데이트 패키지들을 전송하고 커뮤니티(400)의 차량들(202) 간에 이들을 분산하기 위한 데이터 평면으로 간주될 수 있고, 두 번째는 업데이트 패키지가 정품이고 변조되지 않았는지 확인하는 데 사용할 수 있는 업데이트 패키지들과 관련된 검증 데이터를 전송하기 위한 제어 평면으로 간주될 수 있다.

커뮤니티(400)의 차량들(202)은 하나 이상의 차량 제조업체들에 의해 제조된 차량들일 수 있다. 더욱이, 업데이트 패키지들은 하나 이상의 공급업체들에 의해 설계 및/또는 생성되고 커뮤니티(400)의 복수의 차량들(202)에 분산될 수 있다.

차량들(202)에 분산되는 업데이트 패키지들은 예를 들어, 자동차 제조사, 자동차 정비 서비스 제공자, ECU 제공자, 소프트웨어 제공자 등과 같은, 하나 이상의 신뢰할 수 있는 공급업체와 관련된 하나 이상의 신뢰할 수 있는 분산 시스템들(402)에서 비롯될 수 있다.

선택적으로, 업데이트 패키지들 중 하나 이상은 각각의 업데이트 패키지가 유효한 각각의 업데이트 패키지의 생성 및/또는 분산 이후의 시간 기간을 나타내는 만료 및/또는 TTL(Time To Live) 시간 태그와 연관될 수 있으며, ECU(230)와 같은 하나 이상의 ECU들을 업데이트하기 위해 차량들(202) 중 하나 이상에 의해 적용될 수 있다. 차량들(202) 중 하나 이상, 구체적으로는 각각의 차량(들)(202)에 의해 실행되는 업데이트 에이전트(220)와 같은 업데이트 에이전트는 예를 들어, 로컬 실시간 클록(RTC), 방송 RTC, 위성 위치 확인 시스템(GPS) 등에 기초하여 현재 시간 및 날짜와 같은 타이밍 정보에 액세스할 수 있다. 수신된 업데이트 패키지의 만료 시간 태그의 분석과 결합된 현재 시간/데이터에 기초하여, 업데이트 에이전트(220)는 수신된 업데이트 패키지의 유효성 여부를 결정할 수 있다. 업데이트 패키지의 만료 시간이 아직 도달하지 않은 경우, 업데이트 에이전트(220)는 수신된 업데이트 패키지가 아직 유효하다고 결정할 수 있는 반면, 만료 시간 태그에 따라 업데이트 패키지가 만료된 경우, 업데이트 에이전트(220)는 업데이트 패키지가 더 이상 유효하지 않다고 결정할 수 있다.

업데이트 패키지들 각각은 검증 데이터, 특히 검증 코드가 각각의 업데이트 패키지가 정품이고 변조되지 않았음을 검증하는 데 사용될 수 있도록 각각의 업데이트 패키지의 콘텐트를 고유하게 인코딩하기 위해 각각의 업데이트 패키지에 대해 생성된 검증 코드와 연관된다. 업데이트 패키지들에 대한 검증 데이터를 생성하는 것은 업데이트 패키지들을 생성 및/또는 분산하는 것과 관련된 당사자들 중 하나 이상이 수행될 수 있다. 예를 들어, 업데이트 패키지들 중 하나 이상의 검증 코드는 각각의 업데이트 패키지의 공급업체에 의해 생성될 수 있으며, 차량 커뮤니티(400)로의 분산을 위해 각각의 업데이트 패키지와 함께 신뢰할 수 있는 분산 시스템(들)(402)에 전달될 수 있다. 선택적으로, 업데이트 패키지 중 하나 이상의 검증 코드는 차량 커뮤니티(400)에 각각의 업데이트 패키지를 분산하기 전에 하나 이상의 신뢰할 수 있는 분산 시스템들(402) 중 하나 이상이 생성될 수 있다.

검증 코드는 당업계에 알려진 하나 이상의 방법들, 기술들 및/또는 알고리즘들을 사용하여 생성될 수 있다. 예를 들어, 검증 코드는 하나 이상의 해시 함수를 사용하여 각각의 업데이트 패키지에 대한 해시 값을 계산함으로써 생성될 수 있다.

커뮤니티(400)의 차량들(202) 각각은 차량(202)으로의 분산을 위해 신뢰할 수 있는 분산 시스템(들)(402)에 의해 릴리즈된 복수의 업데이트 패키지들 각각이 그 각각의 검증 코드와 연관되는 로컬 로그(222)와 같은 로컬 로그를 유지할 수 있다. 특히, 로컬 로그(222)는 업데이트 패키지들 각각에 할당된 고유 식별자를 각각의 검증 코드와 연관시킨다. 식별자는 하나 이상의 속성들, 예를 들어 기능, 타겟 ECU, 기능 세트, 버전, 빌드, 릴리즈 날짜 등과 관련하여 각각의 업데이트 패키지를 구별하기 위해 각 업데이트 패키지에 할당될 수 있다. 검증 데이터(즉, 식별자 및 관련 검증 코드)는 주로 검증 코드들을 생성하는 데 사용되는 알고리즘들에 따라 작은 데이터 볼륨(예를 들어, <1KB)으로 크게 제한될 수 있다. 로컬 로그(222)에서 업데이트될 검증 데이터는 특히 새로 릴리즈된 업데이트 패키지가 커뮤니티(400)의 차량들(202)의 로컬 로그(222)에 기록되어야 하기 때문에 각각의 새로운 업데이트 패키지의 릴리즈 시, 신뢰할 수 있는 분산 시스템(들)(402)에 의해서만 생성될 수 있다.

게다가, 로컬 로그(222)는 커뮤니티(400)의 차량들(202)의 식별 정보, 예를 들어 차량들(202) 각각의 (VIN)을 저장하는 데 사용될 수 있다.

분산된 업데이트 패키지들을 검증하기 위한 제어 평면을 설정하기 위해, 커뮤니티(400)의 차량들(202)은 지속적으로 동기화된 모든 로컬 로그들(222)을 유지하기 위해 그 로컬 로그들(222)을 업데이트하도록 서로 그리고 선택적으로는 신뢰할 수 있는 분산 시스템(들)(402)과 통신할 수 있다. 구체적으로, 차량들(202)은 그에 따라 로컬 로그들(222)을 업데이트하기 위해 새로 릴리즈된 업데이트 패키지들과 관련된 검증 데이터를 교환하도록 서로 그리고 선택적으로는 신뢰할 수 있는 분산 시스템(들)(402)과 통신할 수 있다.

커뮤니티(400)의 차량들(202)은 하나 이상의 통신 조건들 및/또는 규칙들에 따라 서로 그리고 선택적으로는 신뢰할 수 있는 분산 시스템(들)(402)과 통신을 시도할 수 있다. 예를 들어, 차량들(202)은 하나 이상의 다른 차량들(202) 및/또는 신뢰할 수 있는 분산 시스템(들)(402)과의 통신 세션을 지속적으로 설정하려고 시도할 수 있다. 다른 예에서, 차량들(202)은 하나 이상의 다른 차량들(202) 및/또는 신뢰할 수 있는 분산 시스템(들)(402)과 사전 정의된 시간 간격으로, 예를 들어 사전 정의된 시간 주기마다, 사전 정의된 시간에, 사전 정의된 위치 등에서 통신 세션을 설정하려고 시도할 수 있다. 다른 예에서, 차량들(202)은 예를 들어, 차량(202)의 소유자에 의해, 정비사 등에 의해 하나 이상의 다른 차량들(202) 및/또는 신뢰할 수 있는 분산 시스템(들)(402)과의 통신 세션을 설정하도록 수동으로 지시 및/또는 동작될 수 있다.

커뮤니티(400)의 차량들(202)은 교환된 검증 데이터가 진짜인지 확인하기 위해 서로 신뢰를 구축할 필요가 있으므로, 커뮤니티(400)의 차량들(202)은 제어 평면을 활용하고 중앙 집중식 신뢰할 수 있는 엔티티 없이 동기화된 로컬 로그들(222)을 유지하는 기술에 알려진 바와 같은 하나 이상의 분산 컴퓨팅 방법들, 알고리즘들 및/또는 프로토콜들을 적용할 수 있다. 예를 들어, 커뮤니티(400)의 차량들(202)은 블록체인의 블록들을 변경하기 위한 불가능한 계산 문제를 제시하는 당업계에 알려진 하나 이상의 단방향 암호화 알고리즘들을 사용하여 생성된 복수의 불변의 비가역적 블록들을 포함하는 블록체인을 유지하기 위해 블록체인 네트워크를 구성할 수 있다. 이와 같이 커뮤니티(400)의 차량들(202) 각각에 의해 유지되는 로컬 로그들(222)은 분산 블록체인의 로컬 사본들(원장들)로 활용된다. 불변의 되돌릴 수 없는 블록들 각각은 신뢰할 수 있는 분산 시스템(들)(402)에 의해 릴리즈된 업데이트 패키지들 중 특정 하나의 식별자를 각각의 업데이트 패키지에 대해 생성된 검증 코드와 연관시킨다. 이 블록체인 방식에서, 검증되고 신뢰할 수 있는 엔티티인 신뢰할 수 있는 분산 시스템(들)(402)만 블록체인에 새 블록을 추가(커밋)할 수 있다. 블록체인의 각 블록은 암호화 서명을 사용하여 이전 블록들 중 적어도 일부에 연결되어 있어 커밋된 블록을 조작 및/또는 손상시키려는 악의적인 당사자가 블록을 변경하는 것을 비현실적으로 만드는 극단적인 컴퓨팅 리소스들을 필요로 할 수 있기 때문에 커밋된 블록을 실질적으로 변경 불가능하고 되돌릴 수 없도록 만든다. 게다가, 블록을 손상시키기 위해 악의적인 당사자는 상당한 수의 차량들(202), 잠재적으로 대부분의 차량들(202)을 손상시켜야 할 수 있다. 이러한 큰 그룹의 차량들(202)을 손상시키는 것도 불가능할 수 있으므로 블록체인의 블록들이 변경 불가능하고 되돌릴 수 없음을 추가로 보장한다.

이전에 본원에 설명된 바와 같이, 다른 차량들(202) 및 선택적으로 신뢰할 수 있는 분산 시스템(들)(402)과 통신하여 로컬 로그(222)를 지속적으로 업데이트하기 위해, 커뮤니티(400)의 차량들(202) 각각은 하나 이상의 소프트웨어 모듈들, 예를 들어, 업데이트 에이전트(220), 전용 소프트웨어 모듈 및/또는 이들의 조합을 실행할 수 있다.

커뮤니티(400)는 이동성과 간헐적인 ON/OFF 상태로 인해 애드혹 기반으로 서로 연결되는 복수의 차량들(202)을 포함하므로, 차량들(202)에 의해 형성되는 네트워크는 항상 완전히 연결되지 않을 수 있고 그 구조와 레이아웃을 빠르게 변경될 수 있다. 따라서 하나 이상의 로컬 애드혹 네트워크들, 연결들 및/또는 세션들(이하 애드혹 네트워크로 지정됨)(410)은 주변 차량들(202)의 V2V 통신 채널(들)의 수신 범위에 의해 정의된 수신 영역 내에 있는 커뮤니티(400)의 둘 이상의 주변 차량들(202) 사이에 설정될 수 있다. 따라서, 수신 영역은 일반적으로 수백 미터, 예를 들어 400미터의 범위에 있을 수 있는 V2V 통신 채널(들)의 수신 범위에 의해 제한된다. 예를 들어, 주차장에서 운전 및/또는 주차하는 둘 이상의 차량들(202)은 이러한 로컬 애드혹 네트워크(410)를 형성할 수 있다. 다른 예에서, 거리, 도로 등에서 실질적으로 동일한 속도로 주행하는 둘 이상의 차량들은 이러한 로컬 애드혹 네트워크(410)를 형성할 수 있다. 다른 예에서, 하나 이상의 교통 상황들, 예를 들어 적색 신호등, 교통 체증 등으로 인해 각각 옆에 일시적으로 정지하는 둘 이상의 차량들은 이러한 로컬 애드혹 네트워크(410)를 형성할 수 있다. 특정 로컬 애드혹 네트워크(410)가 설정되면, 특정 로컬 애드혹 네트워크(410)에 연결된 차량들(202)은 서로 통신할 수 있다.

선택적으로, 차량들(202) 중 하나 이상은 검증 데이터를 교환하고 그 로컬 로그들(202)을 업데이트하기 위해 하나 이상의 다른 차량들(202) 및 선택적으로는 신뢰할 수 있는 분산 시스템들(402) 중 하나 이상과 하나 이상의 인프라 네트워크들, 예를 들어, 셀룰러 네트워크, LAN, 인터넷 등을 통해 통신할 수 있다. 예를 들어, 특정 차량(202)은 네트워크 인터페이스(210)와 같은 네트워크 인터페이스를 통해 하나 이상의 셀룰러 기지국들에 연결하고 다른 차량들(202) 중 하나 이상 및/또는 신뢰할 수 있는 분산 시스템들(402)과 통신할 수 있다. 다른 예에서, 특정 차량(202)은 네트워크 인터페이스(210)를 통해 인터넷에 대한 액세스를 제공하는 하나 이상의 무선 액세스 포인트들(예를 들어, Wi-Fi 액세스 포인트)에 연결할 수 있다. 일단 인터넷에 연결되면, 특정 차량(202)은 하나 이상의 다른 차량들(202) 및/또는 신뢰할 수 있는 분산 시스템(들)(402)과 통신할 수 있다. 액세스 포인트에 대한 이러한 연결은 예를 들어 차량(202)이 하나 이상의 액세스 포인트가 배치된 주차장에 위치하는 동안 설정될 수 있다. 다른 예에서, 차량(202)의 운전자 및/또는 소유자의 거주지 및/또는 사무실 근처에 위치하는 동안, 차량(202)은 거주지 및/또는 사무실에 각각 배치된 하나 이상의 액세스 포인트들에 연결할 수 있다. 다른 예에서, 운전자/소유자의 거주지 및/또는 사무실에 주차하는 동안, 네트워크 인터페이스(210)에 의해 제공되는 유선 네트워크 인터페이스, 예를 들어 LAN 인터페이스는 인터넷 및/또는 신뢰할 수 있는 분산 시스템(들)(402)에 대한 액세스를 제공하는 거주지 및/또는 사무실에서 사용 가능한 LAN 인프라에 연결될 수 있다.

게다가, 서로 통신하는 차량들(202) 사이의 신뢰를 설정하기 위해, 하나 이상의 다른 차량들(202)과 통신하는 차량(202)은 먼저 다른 차량(들)(202)이 예를 들어, 비공개-공개 키 쌍 등을 이용한 비대칭 암호화를 사용하여 인코딩된 메시지들을 교환하는 것과 같은 당업계에 공지된 바와 같은 하나 이상의 인증 방법들, 기술들 및/또는 알고리즘들을 사용하여 자신을 인증하도록 요구할 수 있다. 이를 지원하기 위해, 각 차량(202)은 교환된 데이터 메시지들의 발신자로서 자신을 인증하기 위한 고유한 서명을 가질 수 있다. 더욱이, 고유한 서명은 메시지가 변조되지 않았는지 확인하는 데 사용될 수 있다. 식별 정보를 저장하는 로컬 로그(222), 예를 들어 커뮤니티(400)의 모든 차량들(202)의 VIN은 각각의 차량(202)의 VIN을 고유 서명, 예를 들어 각각의 차량(202)의 공개 키와 연관시키는 데 추가로 사용될 수 있다. 서로 통신할 때, 통신하는 차량들(202) 각각은 다른 차량(202)의 공개 키를 검색하고 공개 키를 사용하여 각자의 개인 키를 사용하여 다른 차량(202)에 의해 암호화된 수신된 메시지(들)를 복호화할 수 있다. 이 방식으로, 통신하는 차량들(202)은 교환된 메시지(들)의 내용뿐만 아니라 서로를 인증할 수 있다.

이제 본원에 설명된 일부 실시예들에 따른, 차량들의 ECU들에 대한 업데이트 패키지들을 전송 및 검증하기 위해 네트워크 차량들의 커뮤니티에 의해 사용되는 예시적인 제어 평면 및 데이터 평면의 개략도들인, 도 5a 및 5b에 대한 참조가 이루어진다.

도 5a에서 보이는 바와 같이, 예시적인 분산 블록체인(502)은 커뮤니티(400)의 복수의 차량들(202)에 의해 채택되어 차량들(202) 각각이 블록체인(502)의 로컬 사본을 포함하는 로컬 로그(222)와 같은 로컬 로그를 유지하도록 한다. 블록체인(502)은 신뢰할 수 있는 분산 시스템(들)(402)에 의해 생성되고 블록체인(502)에 추가되고 신뢰할 수 있는 분산 시스템(들)(402)에 의해 커뮤니티(400)에 분산된 복수의 업데이트 패키지들(514)과 연관된 복수의 변경되지 않는 비가역적 블록들(512)을 포함할 수 있다. 블록들(512) 각각은 업데이트 패키지들(514) 중 각각과 연관되며, 예를 들어, 블록 1은 업데이트 패키지 1과 연관될 수 있고, 블록 2는 업데이트 패키지 2과 연관될 수 있고, 계속해서 블록 N은 업데이트 패키지 N과 연관될 수 있다. 업데이트 패키지들(514) 각각은 하나 이상의 세그먼트들, 예를 들어 서명 역할을 할 수 있는 헤더, 바디(데이터 콘텐트) 및 푸터로 구성될 수 있다.

차량들(202)은 서로 및/또는 신뢰할 수 있는 분산 시스템(들)(402)과 통신하여 블록체인(502)의 로컬 사본들을 복수의 전송들을 통해 서로 동기화할 수 있으며, 이 복수의 전송들은 제어 평면으로 간주될 수 있지만 업데이트 패키지들(514)의 전송 자체가 제어 평면으로 간주될 수 있다. 블록들(512) 각각에 포함된 데이터 볼륨은 상당히 작을 수 있고, 따라서 제어 평면은 대용량 업데이트 패키지들(514)을 전송하는 데 사용되는 데이터 평면과 비교하여 상당히 낮은 통신 대역폭을 활용할 수 있다.

블록(512) 각각은 각각의 업데이트 패키지(514)와 관련된 하나 이상의 패키지 속성들을 포함할 수 있다. 패키지 속성들은 각각의 업데이트 패키지의 속성들, 예를 들어, 식별자(ID), 개정판, 버전, 출시일 등을 포함할 수 있다. 다른 예에서, 패키지 속성들은 각각의 업데이트 패키지(514)가 대상으로 하는 ECU(230)와 같은 ECU와 관련된 속성들, 예를 들어 모델, 부품 번호(P/N), 일련 번호(S/N) 등을 포함할 수 있다.

블록들(512) 각각은 각각의 업데이트 패키지(514)가 유효한지, 즉 정품 및 변조되지 않는 지, 그리고 선택적으로 그 TTL이 유효한지 여부를 검증하는 데 사용될 수 있는 각각의 업데이트 패키지(514)의 검증 코드를 포함한다. 검증 코드는 당업계에 알려진 하나 이상의 방법들을 사용하여 구현될 수 있다. 예를 들어, 검증 코드는 하나 이상의 해시 함수들을 사용하여 각각의 업데이트 패키지(514)에 대해 계산된 해시 값일 수 있다.

선택적으로, 충분히 복잡한 해시 함수가 사용된다고 가정하면 업데이트 패키지들(514) 각각에 대해 계산된 해시 값이 각각의 업데이트 패키지(514)에 고유하기 때문에 해시 값은 각각의 업데이트 패키지(514)의 식별자 역할을 할 수 있다. 이러한 경우, 특정 업데이트 패키지(514)의 수신 시, 업데이트 에이전트(220)와 같은 업데이트 에이전트는 수신된 특정 업데이트 패키지(514)의 해시 값을 계산할 수 있으며, 이를 특정 업데이트 패키지(514)와 연관된 각각의 블록(512)에 기록된 해시 값과 비교할 수 있다.

도 5b에 보이는 바와 같이, 다른 예시적인 분산 블록체인(504)은 커뮤니티(400)의 진정한 구성원인 차량들(202)을 기록하기 위해 커뮤니티(400)의 복수의 차량들(202)에 의해 사용될 수 있다. 차량들(202) 각각은 상기에 본원에 설명된 바와 같이 차량 블록체인(504)을 그 로컬 로그(222)의 일부로 유지할 수 있다. 차량 블록체인(504)은 신뢰할 수 있는 분산 시스템(들)(402)에 의해서만 생성되고 차량 블록체인(504)에 추가될 수 있는 복수의 블록들(522)을 포함할 수 있다. 블록들(522) 각각은 각각의 차량의 하나 이상의 속성들, 예를 들어 VIN, 모델, 제조 연도, 커뮤니티(400) 가입 연도 등을 포함할 수 있다.

블록체인(502)에 대해 설명된 바와 같이, 차량들(202)은 커뮤니티(400)에 합류된 차량들(202) 및/또는 커뮤니티(400)에서 제거된 차량들(202)을 반영하기 위해 차량 블록체인(504)의 로컬 사본들을 지속적으로 업데이트 및 동기화하기 위해 제어 평면을 통해 신뢰할 수 있는 분산 시스템(들)(402)은 물론 서로 통신할 수 있다. 다른 차량(202)과의 통신을 설정할 때, 업데이트 에이전트(220)는 먼저 다른 차량(202)이 커뮤니티(400)의 진정한 구성원이고 따라서 신뢰할 수 있는지 확인하기 위해 다른 차량(202)의 아이덴티티를 인증할 수 있다.

다시 한번 도 1에 대한 참조가 이루어진다.

102에 도시된 바와 같이, 프로세스(100)는 네트워크 인터페이스(210) 및/또는 모바일 장치(240)에 의해 제공되는 V2V 통신 채널들 중 하나 이상을 통해 커뮤니티(400)와 같은 커뮤니티의 하나 이상의 차량들(202)로부터 하나 이상의 업데이트 패키지들을 수신하는 차량들(202) 중 하나 이상에 의해 실행되는 업데이트 에이전트(220)로 시작한다. 특히, 업데이트 에이전트(220)는 각각의 차량(202)의 V2V 통신 채널(들)의 수신 영역 내에 있고 애드혹 네트워크(410)과 같은 애드혹 네트워크가 설정되는 하나 이상의 주변 차량들(202)로부터 업데이트 패키지(들)를 수신할 수 있다.

이전에 본원에 설명된 바와 같이, 특정 차량(202)은 특정 차량(202)의 V2V 통신 채널(들)의 수신 영역 내에 위치될 때 하나 이상의 다른 주변 차량들과 애드혹 네트워크(410)를 설정할 수 있다. 예를 들어, 특정 차량(202)이 주차장에 들어갈 때, 커뮤니티(400)의 하나 이상의 주변 차량들(202)을 식별할 수 있고 애드혹 네트워크(410)를 설정할 수 있다. 다른 예에서, 예를 들어, 특정 차량(202)은 특정 차량(202)이 근처에서 주행하는 이 차량(들)(202)과 애드혹 네트워크(410)를 설정할 수 있도록 하는 특정 시간 기간 동안 실질적으로 동일한 속도로 주행하는 하나 이상의 주변 차량들을 식별할 수 있다. 다른 예에서, 특정 차량(202)은 하나 이상의 교통 상황들, 예를 들어 빨간 신호등, 교통 체증 등으로 인해 상당한 시간 기간 동안 하나 이상의 주변 차량들(202) 옆에서 일시적으로 정지 및/또는 상당히 느리게 운전할 수 있다. 이러한 경우에, 특정 차량(202)은 이러한 주변 차량들(202)과 로컬 애드폭 네트워크(410)를 설정할 수 있다.

선택적으로, 주변 차량(들)(202)로부터 업데이트 패키지(들)을 수신하기 전에, 업데이트 에이전트(220)는 예를 들어, 이전에 본원에 설명된 비공개-공개 키 암호화 방식을 사용하여 그들의 아이덴티티를 확인하기 위해 먼저 주변 차량(들)(202)을 인증한다. 주변 차량(들)(202)을 인증하기 위해, 업데이트 에이전트(220)는 주변 차량(들)(202)로부터 수신된 VIN을 로컬 로그(222), 특히 차량 블록체인(506)에 로깅된 VIN과 비교할 수 있다.

선택적으로, 업데이트 에이전트(220)는 업데이트 패키지들 중 하나 이상의 누적 수신을 지원한다. 업데이트 에이전트(220)는 하나 이상의 주변 차량들과 복수의 개별 수신 통신 세션들을 설정하고 특정 업데이트 패키지 전체가 누적될 때까지 특정 업데이트 패키지의 하나 이상의 부분들을 수신할 수 있다. 예를 들어, 특정 차량(202)의 업데이트 에이전트(220)는 제1 주변 차량(202)과 제1 수신 통신 세션을 설정할 수 있다. 제1 수신 통신 세션 동안 업데이트 에이전트(220)는 제1 수신 통신 세션이 종료되기 전에 특정 업데이트 패키지의 제1 부분을 수신할 수 있다. 나중에, 예를 들어, 30초, 2분, 하루, 일주일 등의 시간에, 특정 차량(202)의 업데이트 에이전트(220)는 제1 주변 차량(202) 및/또는 다른 주변 차량(202)일 수 있는 다른 주변 차량(202)과 제2 수신 통신 세션을 설정할 수 있다. 제2 수신 통신 세션 동안 업데이트 에이전트(220)는 제2 수신 통신 세션이 종료되기 전에 특정 업데이트 패키지의 수신을 재개하고 특정 업데이트 패키지의 제2 부분을 수신할 수 있다. 업데이트 에이전트는 완전한 특정 업데이트 패키지를 구성하기 위해 누적된 특정 업데이트 패키지의 모든 부분을 수신할 때까지 수신 통신 세션을 반복할 수 있다.

각 업데이트 패키지는 하나 이상의 실행 가능한 모듈들, 예를 들어 소프트웨어, 펌웨어, 미들웨어 등 및/또는 하나 이상의 타겟 ECU들(230)의 하나 이상의 실행 불가능한 모듈들(예를 들어, 맵 데이터, 교정 정보 등)을 업데이트하도록 지시될 수 있다. 하나 이상의 업데이트 패키지들은 예를 들어, ECU들(230) 중 하나 이상의 FPGA, ASIC 등과 같은 하나 이상의 하드웨어 컴포넌트들의 게이트 맵을 업데이트하도록 더 지시될 수 있다. 업데이트 패키지 각각은 각각의 ECU(230)에 대한 전체 개정 업데이트(예를 들어, 새로운 개정, 이전 개정, 업데이트된 개정 등) 또는 각각의 ECU(230)에 이미 설치된 실행 가능 및/또는 비실행 가능 모듈(들)에 대한 차등 업데이트를 포함할 수 있다.

업데이트 패키지들 각각은 차량(202)의 커뮤니티(400)에 업데이트 패키지들을 릴리즈하는 데 적격인 유일한 엔티티들인 신뢰할 수 있는 분산 시스템(402)과 같은 신뢰할 수 있는 분산 시스템들 중 하나 이상으로부터 비롯된다. 따라서, 업데이트 패키지들은 하나 이상의 소프트웨어, 펌웨어 및/또는 미들웨어 공급업체들에 의해 설계, 생산 및/또는 제공될 수 있지만, 업데이트 패키지들은 먼저 커뮤니티(400)에 이러한 업데이트 패키지들을 릴리즈할 수 있는 신뢰할 수 있는 분산 시스템(들)(402)에 제공되어야 한다.

선택적으로, 업데이트 패키지 중 하나 이상은 커뮤니티(400)에 분산하는 동안 업데이트 패키지의 보안을 증가시키기 위해 당업계에 알려진 하나 이상의 암호화 키들을 사용하여 인코딩 및/또는 암호화될 수 있다.

104에 도시된 바와 같이, 업데이트 에이전트(220)는 수신된 업데이트 패키지(들) 각각이 특정 차량(202)의 ECU들(230) 중 하나 이상으로 향하는지(타겟되는지) 여부를 결정한다.

업데이트 패키지들(230) 각각은 타겟 ECU(들)(230)의 하나 이상의 패키지 속성들, 예를 들어 유형, 변형, 공급업체, (현재) 개정 등에 따라 구성될 수 있다. 예를 들어, 특정 업데이트 패키지는 특정 유형의 복수의 ECU들(230) 및/또는 특정 공급업체에 의해 생산된 ECU들(230)울 업그레이드하도록 구성될 수 있다. 다른 예에서, 특정 업데이트 패키지는 특정 개정 이전에 개정의 특정 소프트웨어 모듈이 로드된 모든 ECU(230)를 업그레이드하도록 구성될 수 있다. 다른 예에서, 특정 ECU(230)는 각각의 변형들이 상이한 기능, 특징 및/또는 능력을 가질 수 있는 다수의 변형들을 가질 수 있다. 이러한 경우에, 각각의 업데이트 패키지의 여러 버전은 공급업체에 의해 생성되고 특정 유형의 ECU(230)에 대해 신뢰할 수 있는 분산 시스템(들)(402)에 의해 릴리즈될 수 있으며, 여기서 업데이트 패키지 버전들 각각은 ECU(230)의 변형들 중 하나 이상에 대해 적응 및/또는 구성될 수 있다.

릴리즈된 업데이트 패키지들 각각을 고유하게 식별하기 위해, 각 업데이트 패키지는 각각의 업데이트 패키지의 패키지 속성(들)을 고유하고 배타적으로 식별하는 고유 식별자가 할당된다. 식별자는 예를 들어, 각각의 업데이트 패키지가 대상으로 하는 ECU(들)(230)의 유형, 즉, 각각의 업데이트 패키지가 향하는 ECU(들)(230)의 유형을 식별할 수 있다. 다른 예에서, 식별자는 각각의 업데이트 패키지가 대상으로 하는 ECU(들)(230)의 변형을 식별하기 위해 각각의 업데이트 패키지의 버전을 식별할 수 있다. 다른 예에서, 식별자는 각각의 업데이트 패키지의 개정을 식별할 수 있다. 식별자는 하나 이상의 방법들, 기술들 및/또는 구현들을 사용하여 업데이트 패키지에 포함될 수 있다. 예를 들어, 하나 이상의 업데이트 패키지들은 각각의 업데이트 패키지의 식별자를 포함하는 헤더를 포함할 수 있다. 다른 예에서, 하나 이상의 업데이트 패키지들의 식별자는 각각의 업데이트 패키지의 메타데이터로서 포함될 수 있다. 게다가, 헤더 및/또는 메타데이터는 당업계에 알려진 바와 같이 하나 이상의 암호화 키를 사용하여 암호화될 수 있다. 다른 예에서, 식별자는 각각의 업데이트 패키지에 대해 고유한 해시 값을 생성하도록 구성된 하나 이상의 해시 함수들을 사용하여 각각의 업데이트 패키지에 대해 계산된 해시 값에 의해 구현될 수 있다.

업데이트 에이전트(220)는 수신된 업데이트 패키지(들)의 식별자를 추출하고 차량(202)에 배치된 ECU(들)(230)과 관련하여 추출된 식별자를 분석하여 수신된 업데이트 패키지(들)가 특정 차량(202)의 ECU(230) 중 하나 이상으로 향하는지(타겟되는지) 여부를 결정할 수 있다. 예를 들어, 수신된 업데이트 패키지의 식별자가 해시 값이라고 가정하면 업데이트 에이전트(220)는 수신된 업데이트 패키지의 해시 값을 계산하고 계산된 해시 값을 로컬 로그(222)의 블록체인(502)과 같은 블록체인에 로컬로 저장된 해시 값들과 비교할 수 있다. 그런 다음, 업데이트 에이전트는 계산된 해시 값으로 블록체인(502)의 각각의 블록(512)과 연관된 타겟 ECU(들)(230)를 식별할 수 있다. 다른 예에서, 업데이트 패키지의 헤더에 수신된 업데이트 패키지의 식별자가 임베디드되어 있다고 가정하면, 업데이트 에이전트(220)는 식별자를 검색하고 식별자를 로컬 로그(222)의 블록체인(502)에 로컬로 저장된 식별자와 비교할 수 있다. 그런 다음, 업데이트 에이전트는 검색된 식별자를 사용하여 블록체인(502)의 각 블록(512)과 연관된 타겟 ECU(들)(230)를 식별할 수 있다.

예를 들어, 식별자의 분석에 기초하여, 업데이트 에이전트(220)는 수신된 특정 업데이트 패키지가 특정 유형의 ECU(230), 예를 들어 스티어링 휠 제어 시스템, 제동 시스템을 제어하는 특정 ECU, 헤드 라이트의 동작을 제어하는 특정 ECU 등으로 향한다고 결정할 수 있다. 다른 예에서, 업데이트 에이전트(220)는 수신된 특정 업데이트 패키지가 수신된 업데이트 패키지의 개정에 선행하는 이전 소프트웨어 패키지 개정으로 로드된 특정 ECU(230)로 향한다고 결정할 수 있다.

업데이트 에이전트(220)는 수신된 업데이트 패키지가 대상으로 하는 하나 이상의 ECU들(230)이 차량(202)에 배치되었는지 여부를 확인하기 위해 하나 이상의 방법들을 적용할 수 있다. 예를 들어, 가장 기본 구현에서, 업데이트 에이전트(220)는 차량(202)에 배치된 ECU들(230) 각각에 액세스하여 배치된 ECU들(230) 각각의 속성들(파라미터)들, 예를 들어 유형, 변형, 특징 세트, 소프트웨어 개정, 가장 최근 업데이트 날짜, 저장 용량 등을 식별할 수 있다. 그런 다음, 업데이트 에이전트(220)는 수신된 업데이트 패키지가 차량(202)에 배치된 ECU들(230) 중 하나 이상으로 향함을 나타내는 일치를 검사하기 위해 ECU 속성들과 관련하여 수신된 업데이트 패키지의 식별자에 의해 식별된 패키지 속성들을 분석할 수 있다. 보다 효율적인 구현에서, 업데이트 에이전트(220)는 차량(202)에 배치된 모든 ECU들(230)을 나열하고 나열된 ECU들(230) 각각을 그 각각의 ECU 속성들과 연관시키는 기록, 예를 들어 파일, 테이블, 목록, 데이터베이스 등을 유지할 수 있다. 이러한 경우에, 업데이트 에이전트(220)는 레코드에 나열된 모든 ECU들(230)의 ECU 속성들과 관련하여 수신된 업데이트 패키지의 식별자에 의해 식별된 패키지 속성들을 분석하고 수신된 업데이트 패키지가 차량(202)에 배치된 ECU들(230) 중 하나 이상으로 향함을 나타내는 일치를 확인할 수 있다.

수신된 업데이트 패키지들 각각에 대한 조건부 단계인 106에 도시된 바와 같이, 업데이트 에이전트(220)가 업데이트 패키지가 차량(202)에 배치된 ECU들(230) 중 하나 이상으로 향한다고 결정하는 경우, 프로세스(100)는 단계(108)로 분기하고, 그렇지 않으면 프로세스(100)는 단계(114)로 분기한다.

108에 도시된 바와 같이, 업데이트 에이전트(220)가 수신된 업데이트 패키지(들) 중 하나 이상이 차량(202)에 배치된 ECU(들)(230)로 향한다고 결정한 후, 업데이트 에이전트(220)는 수신된 업데이트 패키지(들) 각각이 유효한지 검증하기 위해 커뮤니티(400)의 차량들(202) 중 적어도 일부와 통신한다. 유효한 업데이트 패키지는 신뢰할 수 있는 분산 시스템(들)(402)에서 시작되고 변조되지 않은 정품 업데이트 패키지이다. 즉, 업데이트 패키지의 내용은 신뢰할 수 있는 분산 시스템(들)(402)에 의해 릴리즈된 후 변경되지 않았다.

업데이트 에이전트(220)는 차량(202)의 V2V 통신 채널(들)을 통해 커뮤니티(400)의 차량들(202)의 서브셋과 통신할 수 있다. 따라서, 서브셋은 V2V 통신 채널(들)의 수신 영역에 위치되고 로컬 애드혹 네트워크(410)를 형성하는 복수의 주변 차량들(202)을 포함할 수 있다.

선택적으로, 업데이트 에이전트(220)는 수신된 업데이트 패키지의 검증을 진행하기 전에 주변 차량(들)(202)의 서브셋 각각을 인증한다.

당연히, 업데이트 패키지(들)이 단계(102)에서 설명된 바와 같이 수신된 주변 차량들(202) 중 적어도 일부와 업데이트 에이전트(220)가 수신된 업데이트 패키지를 검증하기 위해 상호 작용하는 서브셋의 주변 차량들(202) 사이에 중첩이 있을 수 있다. 그러나, 그러한 중첩은 차량(202)(업데이트 에이전트(220)를 실행함)이 모바일이고 특정 업데이트 패키지를 수신하는 기간과 수신된 특정 업데이트 패키지를 검증하는 시간 사이의 지리적 위치들 및 영역들 사이에서 이동할 수 있기 때문에 반드시 발생하지 않을 수 있다. 차량들(202)이 이동함에 따라, 차량(202)의 V2V 통신 채널(들)의 수신 영역에서 이전에 하나 이상의 다른 주변 차량들(202)을 만날 수 있다. 따라서, 하나 이상의 새로운 로컬 애드혹 네트워크들(410)이 설정(형성)될 수 있으며, 업데이트 에이전트(220)는 새로 형성된 애드혹 네트워크(들)(410)에 연결된 주변 차량(들)(202)과 통신할 수 있다.

이전에 본원에 설명된 바와 같이, 커뮤니티(400)의 차량들(202) 각각은 커뮤니티(400)의 차량들(202)에 분산하기 위해 신뢰할 수 있는 분산 시스템(들)(402)에 의해 릴리즈된 복수의 업데이트 패키지들 각각이 각각의 검증 데이터, 예들 들어, 각각의 검증 코드와 연관되는 각자의 로컬 로그(222)를 유지한다. 설명된 바와 같이, 업데이트 패키지들과 그들의 검증 코드들 사이의 연관은 각 업데이트 패키지의 각 식별자가 로컬 로그(222)에서 각각의 검증 코드, 예를 들어, 각각의 업데이트 패키지에 대해 계산된 해시 값과 연관되도록 설명된 바와 같이 업데이트 패키지들 각각에 고유하게 할당된 식별자들을 기반으로 한다.

커뮤니티(400)의 차량들(202)은 분산 컴퓨팅 알고리즘들 및/또는 프로토콜들 중 하나 이상, 예를 들어 블록체인 등을 적용하여 서로(제어 평면)와 통신하여 로컬 로그들(222)을 지속적으로 동기화하므로, 이러한 동기화된 로컬 로그들(222)은 릴리즈된 업데이트 패키지들에 대한 유사한 검증 데이터(검증 코드들)를 반영할 수 있다.

업데이트 에이전트(220)는 쿼리된 수신된 업데이트 패키지에 대해 차량 서브셋(202) 사이에서 협상된 컨센서스 결정에 따라 수신된 업데이트 패키지를 검증할 수 있다. 업데이트 패키지가 유효한지 여부에 대한 컨센서스는 하나 이상의 방법들, 알고리즘들 및/또는 프로토콜들을 사용하여 차량 서브셋(202) 간에 협상되고 도달될 수 있다. 예를 들어, 업데이트 에이전트(220)를 실행하는 차량(202)이 커뮤니티(400)의 일부이기 때문에, 업데이트 에이전트(220)는 분산 컴퓨팅 프로토콜, 예를 들어 컨센서스 결정을 생성하기 위해 당업계에 공지된 비밀 공유 알고리즘들을 사용하여 일반적으로 설정된 차량 서브셋(202)과 함께 MPC(Multi-Party Computation)에 참여할 수 있다. 그 로컬 로그(222)를 각각 갖는 차량 서브셋(202)은 차량 서브셋(202) 각각의 로컬 로그들(222) 각각에서 쿼리된 업데이트 패키지에 대해 이용가능한 검증 데이터에 따라 차량 서브셋(202)의 대부분에 의해 동의된 컨센서스 결정을 생성하기 위해 MPC 세션을 수행할 수 있다.

서브셋의 차량들(202)의 수 및 선택적으로 컨센서스 결정에 도달하는 데 필요한 대부분(예를 들어, 절대 다수, 관계 다수 등)의 유형은 커뮤니티(400)의 하나 이상의 보안 파라미터들에 따라 정의될 수 있다. 커뮤니티(400)에 대해 정의된 보안 파라미터들은 예를 들어 커뮤니티(400)의 차량들(202)의 수, 차량들(202)의 지리적 분포(즉, 마주침의 밀도 또는 빈도), 커뮤니티(400)의 유형(즉, 개인 소유 차량(202), 회사 차량 등), 차량들(202) 간에 교환되는 데이터의 보안 레벨(예를 들어, 암호화, 인증 등), 제어 평면을 유지하는 데 사용된 프로토콜(들)의 유형(즉, 동기화된 로컬 로그(222))(예를 들어, 블록체인 등), 쿼리된 업데이트 패키지의 임계값 등을 포함할 수 있다. 예를 들어, 커뮤니티(400)는 매우 많은 수의 차량(202)을 포함한다고 가정한다. 이러한 경우, 업데이트 에이전트(220)는 상당히 많은 수의 차량들(202)을 포함하는 차량 서브셋(202)과 통신하도록 구성 및/또는 지시될 수 있다. 다른 예에서, 커뮤니티(400)의 차량들(202) 중 적어도 일부의 지리적 분포는 적어도 일부 차량들(202) 간의 마주침이 매우 빈번하도록 상당히 작은 지리적 영역으로 제한된다고 가정한다. 다시, 이러한 경우, 업데이트 에이전트(220)는 상당히 많은 수의 차량들(202)을 포함하는 차량 서브셋(202)과 통신하도록 구성될 수 있다. 다른 예에서, 커뮤니티(400)가 기업 소유의 복수의 차량들(202)을 포함하고 외부 사람들이 접근할 수 없다고 가정한다. 이러한 커뮤니티(400)는 악의적인 공격에 대해 상당히 강건할 수 있기 때문에, 업데이트 에이전트(220)는 비교적 적은 수의 차량들(202)을 포함하는 차량 서브셋(202)과 통신하도록 구성될 수 있다. 다른 예에서, 커뮤니티(400)의 차량들(202)은 고도로 안전한 통신 프로토콜들을 사용하여 서로 통신한다고 가정한다. 이러한 경우, 업데이트 에이전트(220)는 비교적 적은 수의 차량들(202)을 포함하는 차량 서브셋(202)과 통신하도록 구성될 수 있다. 다른 예에서, 서브셋에 필요한 차량들(202)의 수는 쿼리된 업데이트 패키지의 중요도에 따라 달라진다. 중요도가 높은 업데이트 패키지들은 중요 시스템, 예를 들어 스티어링 휠 시스템, 제동 시스템, 가속 시스템, 에어백 시스템 등을 제어하는 ECU(들)(230)로 향할 수 있다. 중요도가 낮은 업데이트 패키지들은 중요하지 않은 시스템, 예를 들어 인포테인먼트 차단 시스템, 기후 제어 시스템 등을 제어하는 ECU(들)(230)로 향할 수 있다. 따라서, 쿼리된 업데이트 패키지가 더 중요할수록 업데이트 에이전트(220)가 업데이트 패키지를 검증하기 위해 통신하는 서브셋에 대해 더 많은 차량들(202)이 필요하다. 그에 반해, 쿼리된 업데이트 패키지가 덜 중요할수록 서브셋에 필요한 차량(202)이 더 적다.

업데이트 에이전트(220)는 수신된 업데이트 패키지(들)가 만료 시간과 관련하여 유효한지 더 확인할 수 있다. 업데이트 에이전트(220)는 수신된 업데이트 패키지(들) 중 하나 이상에 할당된 만료 시간 태그를 분석하고 현재 시간 및 날짜와의 비교에 기초하여 수신된 업데이트 패키지(들)가 여전히 유효한지 여부 또는 수신된 업데이트 패키지(들)가 만료되었는지 여부를 결정할 수 있다. 업데이트 에이전트(220)는 하나 이상의 외부 타이밍 소스들로부터 현재 시간 및 날짜를 획득할 수 있다. 예를 들어, 업데이트 에이전트(220)는 GPS 시스템에 대한 현재 시간 및 날짜를 수신하는 GPS 센서로부터 현재 시간 및 날짜를 획득할 수 있다. 다른 예에서, 업데이트 에이전트(220)는 네트워크 인터페이스(210)를 통해 차량(202)의 환경에 배치된 하나 이상의 인프라 컴포넌트들과 통신하여 현재 시간 및 날짜를 획득할 수 있다. 다른 예에서, 업데이트 에이전트(220)는 하나 이상의 시간 유지 모듈들, 예를 들어 외부 타이밍 소스들 중 하나 이상과 지속적으로 또는 주기적으로 동기화되는 RTC로부터 현재 시간 및 날짜를 획득할 수 있다.

조건부 단계인 110에 도시된 바와 같이, 수신된 업데이트 패키지(들) 각각에 대해, 업데이트 에이전트(220)가 차량 서브셋(202)의 컨센서스 및 선택적으로 만료 시간에 기초하여, 수신된 업데이트가 패키지가 유효하다고 결정하는 경우, 프로세스(100)는 단계(112)로 분기하고, 그렇지 않은 경우 프로세스(100)는 단계(116)로 분기한다.

112에 도시된 바와 같이, 업데이트 에이전트(220)가 수신된 업데이트 패키지(들) 중 하나 이상이 유효하다고 검증한 후, 업데이트 에이전트(220)는 검증된 업데이트 패키지(들)을 사용하여 타겟 ECU(들)(230)의 업데이트를 개시할 수 있다. 예를 들어, 업데이트 에이전트(220)는 특정 업데이트 패키지가 향하는 타겟 ECU(들)(230)에 특정 검증된 업데이트 패키지를 전송할 수 있다. 그런 다음, 타겟 ECU(들)(230)는 특정 업데이트 패키지의 콘텐트에 의해 지시된 바와 같이 소프트웨어, 펌웨어 및/또는 미들웨어를 업데이트하기 위해 특정 업데이트 패키지를 사용할 수 있다. 다른 예에서, 업데이트 에이전트(220)는 업데이트 패키지를 타겟 ECU들(230)에 분산하도록 구성된 중앙 디스패처 ECU(230)에 특정 검증된 업데이트 패키지를 전송할 수 있다. 그런 다음, 중앙 디스패처 ECU(230)는 특정 업데이트 패키지를 사용할 수 있는 타겟 ECU(들)(230)에 특정 업데이트 패키지를 전송할 수 있다. 다른 예에서, 업데이트 에이전트(220)는 특정 업데이트 패키지를 사용하여 하나 이상의 타겟 ECU들(230)을 업데이트하도록 구성된 업데이트 ECU(230)에 특정 검증된 업데이트 패키지를 전송할 수 있다.

114에 도시된 바와 같이, 업데이트 에이전트(220)는 커뮤니티(400)의 하나 이상의 차량들(202)로의 수신된 업데이트 패키지(들)의 전송을 지원하기 위해, 예를 들어 저장 장치(214)에 수신된 업데이트 패키지(들) 중 하나 이상을 로컬로 저장할 수 있다. 프로세스(100)에서 보이는 바와 같이, 업데이트 에이전트(220)는 업데이트 패키지(들)가 차량(202)의 (타겟) ECU들(230)로 향하는지 여부에 관계없이 수신된 업데이트 패키지(들) 중 하나 이상을 로컬로 저장할 수 있다. 이는 업데이트 에이전트(220)가 차량(202)의 ECU들(230)로 향하지 않는 업데이트 패키지들 중 하나 이상을 로컬로 저장할 수 있음을 의미한다.

그러나, 현대 차량들(202)의 많은 수의 ECU들(230)로 인해, 커뮤니티(400)에 릴리즈된 업데이트 패키지들의 수는 잠재적으로 매우 클 수 있으며, 예를 들어 저장 장치(214)에 많은 수의 업데이트 패키지들을 로컬로 저장하는 것은 주요 저장 리소스들을 소비할 수 있다. 저장 장치(214)의 저장 리소스들의 지나친 활용을 방지하기 위해, 업데이트 에이전트(220)는 수신된 업데이트 패키지(들)를 제한된 미리 정의된(저장) 기간 동안 저장할 수 있으며, 그 후 각각의 업데이트 패키지는 저장 장치(214)로부터 폐기 및 제거(삭제)된다.

미리 정의된 저장 시간 기간 동안, 차량(202), 특히 프로세서(212)와 같은 차량(202)의 프로세서(들)에 의해 실행되는 소프트웨어 모듈, 예를 들어, 업데이트 에이전트(220)는 저장된 업데이트 패키지(들) 중 하나 이상을 차량(202)의 V2V 통신 채널(들)의 수신 영역에서 마주친 하나 이상의 주변 차량(들)(202)로 전송할 수 있다. 이러한 주변 차량(들)(202)을 마주칠 때, 업데이트 에이전트(220)는 저장된 업데이트 패키지(들) 중 하나 이상을 근처 차량(들)(202)과 V2V 통신 채널(들)을 통해 설정된 로컬 애드혹 네트워크(410)를 통해 주변 차량(들)(202)에 전송할 수 있다.

미리 정의된 저장 시간 기간은 차량(202)의 하나 이상의 동작 파라미터들, 예를 들어, 차량(202)이 위치되는 지리적 영역, 차량(202)의 주변 지형, 차량(200)의 온/오프 상태, 차량(202)의 속도 등에 따라 조정될 수 있다. 예를 들어, 차량(202)이 현재 하나 이상의 업데이트 패키지들을 저장하고 오프 상태로 들어가는 경우, 즉 차량(202)이 꺼진 경우, 미리 정의된 시간 기간이 연장될 수 있다. 미리 정의된 시간 기간을 연장하는 것은 차량(202)이 움직이지 않는 동안 저장된 업데이트 패키지(들)를 폐기하는 것을 방지할 수 있으며 저장된 업데이트 패키지(들)를 다른 차량들(202)과 효과적으로 순환 및 공유할 수 없을 수 있다. 다른 예에서, 차량(202)이 밀집된 도시 지역에서 움직이고 따라서 많은 수의 주변 차량들(202)을 마주친다고 가정한다. 이러한 차량 밀집 지역에서, 업데이트 패키지(들)는 이 지역에서 운전하는 다수의 차량들(202)에 의해 쉽게 순환될 수 있다. 따라서, 업데이트 패키지들이 다른 차량들(202)과 신속하고 빠르게 공유(전송)될 수 있기 때문에 미리 정의된 시간 기간이 상당히 감소될 수 있다. 그에 반해, 차량(202)이 시골 지역, 예를 들어 주간 고속도로에서 움직이고 있으므로, 다른 차량들(202)과 거의 마주치지 않는다고 가정한다. 이러한 경우, 미리 정의된 시간 기간은 업데이트 패키지들이 고속도로에서 잠재적으로 긴 운전 동안 저장되고 차량(202)의 목적지에서 다른 차량들(202)에 분산되는 것을 보장하기 위해 연장될 수 있으므로 업데이트 패키지(들)의 순환을 실질적으로 원격의 지리적 영역으로 확장할 수 있다. 다른 예에서, 차량(202)이 고속으로 운전하고 있다고 가정한다. 이러한 속도에서, 다른 인접 차량(202)이 업데이트 패키지(들)를 전송하기에 충분한 시간 기간 동안 차량(202)과 애드혹 로컬 네트워크(410)를 유지할 수 있을 가능성은 매우 낮다. 이러한 경우, 이러한 고속에서는 업데이트 패키지(들)가 다른 주변 차량(들)(202)에 효과적으로 분산되지 않을 수 있기 때문에 미리 정의된 시간 기간이 감소될 수 있다.

미리 정의된 기간은 저장 장치(214)의 저장 용량에 따라 더 조정될 수 있다. 당연히, 저장 장치(214)의 용량이 클수록 업데이트 패키지(들)를 저장하기 위한 미리 정의된 시간 기간이 더 길 수 있다. 보완적으로, 저장 장치(214)의 용량이 작을수록 업데이트 패키지(들)를 저장하기 위한 미리 정의된 시간 기간이 더 짧을 수 있다. 게다가, 미리 정의된 시간 기간은 업데이트 패키지들의 중요도에 따라 조정될 수 있다. 이와 같이 중요한 것으로 식별된 하나 이상의 업데이트 패키지들은 더 긴 미리 정의된 시간 기간 동안 저장될 수 있는 반면 덜 중요한 업데이트 패키지는 더 짧은 미리 정의된 시간 기간 동안 저장될 수 있다.

저장 장치(214)의 과도한 사용을 추가로 방지하기 위해, 업데이트 에이전트(220)는 업데이트 패키지들이 어떤 차량들(202)로 전송되었는지를 업데이트 에이전트(220)가 기록하지 않는다는 것을 의미하는 저장된 업데이트 패키지들의 주변 차량(202)으로의 전송 이벤트들을 추적하기 위한 로그들을 기록 및/또는 유지하지 않는다. 최신 차량들(202)에 있는 많은 수의 ECU들(230)로 인해, 커뮤니티(400)에 릴리즈된 업데이트 패키지들의 수는 잠재적으로 매우 클 수 있다. 게다가, 각 차량(202)에 의해 마주칠 수 있는 차량들(202)의 수는 매우 많을 수 있다. 따라서, 모든 마주침 동안 업데이트 패키지들의 모든 전송에 대한 로그들을 유지 관리하는 데 주요 저장 리소스들이 소모될 수 있다. 이와 같이, 업데이트 에이전트(220)가 전송 이벤트들을 기록하기 위한 이러한 상당한 저장 리소스들의 할당을 피하기 위해, 업데이트 에이전트(220)는 이러한 전송 이벤트들을 기록, 추적 및/또는 로그하지 않는다.

그러나, 어떤 업데이트 패키지들이 어떤 차량들(202)에 전송되었는지에 대한 기록이나 로그가 만들어지지 않기 때문에, 많은 시나리오에서 다수의 주변 차량(202)이 동일한 업데이트 패키지(들)를 동일한 차량(들)(202) 및 선택적으로 서로에게 전송할 가능성이 매우 높으므로 업데이트 패키지(들)의 중복 전송에 필요한 네트워크 리소스들의 활용도를 크게 증가시킨다. 업데이트 패키지(들)의 중복 전송은 동일한 업데이트 패키지(들)의 전송 및/또는 수신에 관여하는 차량들(202)의 하나 이상에서 컴퓨팅 리소스들을 더 소모할 수 있다.

예를 들어, 제1 차량(202)이 주차장에 진입하여 제2 및 제3 주변 차량들(202)과 애드혹 네트워크(410)를 구축하고 특정 업데이트 패키지를 제2 및 제3 주변 차량들(202)에 전송한다고 가정한다. 특정 업데이트 패키지를 수신한 후, 제2 및 제3 주변 차량들(202)은 제1 차량(202)으로부터 특정 업데이트 패키지를 처음 수신했기 때문에 자연스럽게 이미 특정 업데이트 패키지를 갖고 있는 제1 차량(202)으로 특정 업데이트 패키지를 다시 전송할 수 있다. 다른 예에서, 제1 차량(202)이 여러 차량들(202) 옆의 교통 체증으로 정지한다고 가정하면, 제2 및 제3 주변 차량들(202)과 애드혹 네트워크(410)를 설정하고 특정 업데이트 패키지를 제2 및 제3 주변 차량들(202)에 전송한다. 특정 업데이트 패키지를 수신한 후, 제2 및 제3 주변 차량들(202)은 특정 업데이트 패키지를 제4 주변 차량(202)으로 전송할 수 있다. 게다가, 제1 차량(202)은 또한 제4 주변 차량(202)과 통신할 수 있고 특정 업데이트 패키지를 제4 주변 차량(202)으로 전송하려고 시도할 수 있다. 이와 같이 제4 주변 차량(202)은 제1, 제2 및 제3 차량들(202)로부터 동일한 업데이트 패키지를 수신할 수 있다.

차량들(202) 중 하나 이상이 전송 세션을 기록 및/또는 추적할 필요 없이 각각의 차량(202)에 이미 이용 가능한 업데이트 패키지들을 전송하기 위해 시작된 중복 전송 세션들에 참여하는 것을 방지하기 위해 하나 이상의 조치들이 적용될 수 있다. 이러한 조치들은 차량들(202) 사이에 설정된 네트워크들의 성능을 개선하고 선택적으로 여러 번 수신된 동일한 업데이트 패키지들을 처리하기 위해 업데이트 에이전트(220)에 할당된 차량들(202)에서 컴퓨팅 리소스들을 줄이기 위해 적용될 수 있다.

차량들(202) 중 하나 이상에 의해 실행되는 업데이트 에이전트(220)에 의해 적용될 수 있는 제1 조치는 업데이트 패키지의 수신에 이어 추가 업데이트 패키지들의 수신을 금지하도록 지시될 수 있다. 업데이트 에이전트(220)는 하나 이상의 업데이트 패키지들의 수신에 이어 미리 정의된 비수신 시간 기간 동안 대기하도록 구성될 수 있다. 비수신 시간 기간 동안, 업데이트 에이전트(220)는 추가 업데이트 패키지들을 수신하지 못할 수 있다. 비수신 시간 기간은 차량(202)의 동작 파라미터들 중 하나 이상, 예를 들어, 차량(202)이 위치되는 지리적 영역, 차량(202)의 주변 지형, 차량(200)의 온/오프 상태, 차량(202)의 속도 등에 따라 조정될 수 있다. 예를 들어, 차량(202)이 밀집된 도시 지역에서 움직이고 있고 다수의 주변 차량들(202)과 마주칠 것으로 예상되다고 가정한다. 이러한 경우, 비수신 시간 기간은 차량(202)이 다수의 주변 차량들(202)으로부터 동일한 업데이트 패키지를 및/또는 주변 차량(들)(202)로부터 동일한 업데이트 패키지를 여러 번 수신할 가능성이 높기 때문에 상당히 길게 조정될 수 있다. 비수신 시간 기간을 상당히 길게 연장하면 차량(202)이 동일한 업데이트 패키지(들)가 순환되는 지리적 영역을 떠날 수 있다. 게다가, 연장된 비수신 시간 기간 동안, 업데이트 패키지(들)를 전송하려고 시도하는 주변 차량들(202)은 미리 정의된 저장 시간 기간의 만료로 인해 저장된 업데이트 패키지(들)를 폐기할 수 있고 따라서 업데이트 패키지(들)의 반복 전송을 중지할 수 있다. 다른 예에서, 차량(202)이 고속으로 운전하고 있다고 가정한다. 이러한 속도에서, 동일한 인접 차량(202)이 장기간 동안 차량(202)의 수신 영역 내에 있을 가능성이 매우 낮으며, 따라서 비수신 시간 기간이 단축될 수 있다.

업데이트 에이전트(220)에 의해 적용될 수 있는 두 번째 조치는 동일한 업데이트 패키지(들)의 반복적인 후속 전송들을 금지하는 것이다. 업데이트 에이전트(220)는 각각의 업데이트 패키지의 전송에 이어 미리 정의된 비전송 시간 기간 동안 대기하도록 구성될 수 있다. 비전송 시간 기간 동안, 업데이트 에이전트(220)는 각각의 업데이트 패키지를 전송하지 못할 수 있다. 비전송 시간 기간은 차량(202)의 동작 파라미터들 중 하나 이상, 예를 들어, 차량(202)이 위치되는 지리적 영역, 차량(202)의 주변 지형, 차량(200)의 온/오프 상태, 차량(202)의 속도 등에 따라 조정될 수 있다. 예를 들어, 차량(202)이 주차장 내에서 비교적 저속으로 이동하여 차량(202)이 장기간 동일한 주변 차량(202)과 마주칠 예상된다고 가정한다. 이런 경우, 전송 이벤트들을 기록하거나 추적하지 않는 업데이트 에이전트(220)는 동일한 업데이트 패키지(들)를 동일한 주변 차량(202)에 전송하기 위해 다수의 전송 세션들을 개시할 수 있다. 이런 경우, 비전송 시간 기간은 이러한 전송 세션들 중 적어도 일부가 동일한 주변 차량(202)과 함께 수행될 가능성이 있기 때문에 업데이트 에이전트(220)가 다수의 전송 세션 동안 동일한 업데이트 패키지를 여러 번 전송하는 것을 방지하기 위해 상당히 길게 조정될 수 있다. 다른 예에서, 차량(202)이 장시간 동안 차량(202)의 수신 영역 내에 있을 가능성이 매우 낮은 확률로 차량(202)이 고속으로 주행하고 있다고 가정한다. 이러한 경우, 각각의 전송 세션이 다른 주변 차량(202)과 함께 수행될 가능성이 매우 높기 때문에 업데이트 에이전트(220)가 주변 차량(202)과 설정된 복수의 전송 세션들에서 동일한 업데이트 패키지(들)를 반복적으로 전송할 수 있도록 비전송 시간 기간이 상당히 감소될 수 있다.

선택적으로, 특정 업데이트 패키지를 수신하기 위해 하나 이상의 다른 차량들(202)과 통신할 때, 업데이트 에이전트(220)는 특정 업데이트 패키지가 이전에 수신되어 다른 차량들(202)로의 잠재적인 전송을 위해 저장된 후 차량(202)에 현재 로컬로 저장되어 있는지 여부를 확인할 수 있다. 업데이트 에이전트(220)는 특정 업데이트 패키지의 식별자와 현재 로컬에 저장된 업데이트 패키지 각각의 식별자를 비교하여 특정 업데이트 패키지가 차량(202)에서 이미 수신되었는지 여부를 확인할 수 있다. 업데이트 에이전트(220)가 특정 업데이트 패키지가 이전에 수신된 바와 같이 로컬로 이용 가능하다고 결정하는 경우, 업데이트 에이전트(220)는 중복 전송을 줄이기 위해 통신 세션을 종료하고 특정 업데이트 패키지의 수신을 거부할 수 있다.

116에 도시된 바와 같이, 업데이트 에이전트(220)는 수신된 업데이트 패키지(들)을 폐기한다. 수신된 업데이트 패키지(들)는 프로세스(100)의 하나 이상의 이유들 및 실행 경로들로 인해 폐기될 수 있다. 예를 들어, 업데이트 에이전트(220)는 단계 110에서 설명된 바와 같이 유효하지 않은 것으로 결정된 업데이트 패키지들 중 하나 이상을 폐기할 수 있다. 다른 예에서, 업데이트 에이전트(220)는 미리 정의된 저장 시간 기간이 만료된 로컬에 저장된 업데이트 패키지들 중 하나 이상을 폐기할 수 있다.

이 응용 프로그램에서 만료되는 특허 기간 동안 많은 관련 시스템들, 방법들 및 컴퓨터 프로그램들이 개발되고 ECU 및 V2V 통신 채널들이라는 용어의 범위는 이러한 모든 신기술을 선험적으로 포함하도록 의도된다.

본원에 사용된 바와 같이, "약" 이라는 용어는 ㅁ 10 %를 말한다.

"포함하다(comprises)", "포함하는(comprising)", "포함하다(include)", "포함하는(including)", "갖는(having)" 및 그 접합어는 "이에 제한되는 것은 아니나 ~을 포함하는"을 의미한다. 이 용어는 "~로 구성된" 및 "본질적으로 구성되는"이라는 용어를 포함한다.

"본질적으로 구성되는"이라는 문구는 조성물 또는 방법이 추가 성분 및/또는 단계를 포함할 수 있지만, 추가 성분 및/또는 단계가 청구된 조성물 또는 방법의 기본 및 신규 특성을 실질적으로 변경하지 않는 경우만을 의미한다.

본원에 사용된 바와 같이, 단수 형태 "하나(a)", "하나(an)"및 "상기(the)"는 문맥상 명백하게 달리 지시하지 않는 한 복수의 지시 대상들을 포함한다. 예를 들어, "화합물" 또는 "적어도 하나의 화합물"이라는 용어는 이들의 혼합물을 포함하여 복수의 화합물들을 포함할 수 있다.

본 출원 전반에 걸쳐, 본원에 설명된 다양한 실시예들은 범위 형식으로 제시될 수 있다. 범위 형식의 설명은 단지 편의성과 간결성을 위한 것이며 본원에 설명된 실시예들의 범위에 대한 변경할 수 없는 제한으로 해석되어서는 안된다는 것을 이해해야 한다. 따라서, 범위에 대한 설명은 가능한 모든 하위 범위들뿐만 아니라 해당 범위 내의 개별 수치 값들을 구체적으로 개시한 것으로 간주되어야 한다. 예를 들어, 1 내지 6과 같은 범위의 설명은 구체적으로 예를 들어, 1, 2, 3, 4, 5 및 6 내의 개별 숫자들뿐만 아니라, 1 내지 3, 1 내지 4, 1 내지 5, 2 내지 4, 2 내지 6, 3 내지 6 등과 같은 개시된 하위 범위들을 갖는 것으로 간주되어야 한다. 이는 범위의 폭에 관계없이 적용된다.

수치 범위가 본원에 표시될 때마다, 이는 표시된 범위 내의 임의의 인용된 숫자(분수 또는 정수)를 포함하는 것을 의미한다. 제1 표시 번호 및 제2 표시 번호 "사이의 범위/범위"라는 문구 및 제1 표시 번호 "내지" 제2 표시 번호의 "범위/범위"는 본원에 상호 교환 가능하게 사용되며, 제1 및 제2 표시 번호들 및 그들 사이의 모든 분수 및 정수를 포함하는 것을 의미한다.

"예시적인(exemplary)"이라는 단어는 본원에서 "예, 실례 또는 예시로서 제공하는"을 의미하는데 사용된다. "예시적인" 것으로 설명된 임의의 실시예는 다른 실시예들보다 바람직하거나 유리한 것으로 해석되고/되거나 다른 실시예들로부터의 특징들의 통합을 배제할 필요는 없다.

"선택적으로"라는 단어는 본원에서 "일부 다른 실시예에서 제공되며 다른 실시예들에서는 제공되지 않는"것을 의미하는 데 사용된다. 본원에 설명된 임의의 특정 실시예는 이러한 특징이 충돌하지 않는 한 복수의 "선택적" 특징들을 포함할 수 있다.

명료함을 위해 별도의 실시예들과 관련하여 설명된 본 명세서에 설명된 실시예들의 특정 특징들은 단일 실시예에서 조합하여 제공될 수도 있다는 것이 이해된다. 반대로, 간결함을 위해 단일 실시예의 맥락에서 설명된 본원에 설명된 실시예들의 다양한 특징들은 또한 개별적으로 또는 임의의 적절한 하위 조합으로 또는 임의의 다른 설명된 실시예에서 적절한 것으로 제공될 수 있다. 다양한 실시예들과 관련하여 설명된 특정 특징들은, 실시예가 이러한 요소들 없이 작동하지 않는 경우를 제외하고는, 이러한 실시예들의 필수 특징들로 간주되지 않는다.

본원에 설명된 실시예들이 그 특정 실시예들과 관련하여 설명되었지만, 많은 대안들, 수정들 및 변형들이 당업자에게 명백할 것임이 명백하다. 따라서, 첨부된 청구범위의 정신과 넓은 범위에 속하는 그러한 모든 이러한 대안들, 수정들 및 변형들을 포함하도록 의도된다.

본 명세서에 언급된 모든 간행물, 특허 및 특허 출원은 각각의 개별 간행물, 특허 또는 특허 출원이 참조에 의해 본원에 통합되는 것으로 구체적이고 개별적으로 표시된 것과 동일한 정도로, 그 전체가 참조로서 본원에 통합된다. 추가로, 본 출원에서 참조의 인용 또는 식별은 이러한 참조가 본원에 설명된 실시예들에 대한 선행 기술로서 이용 가능하다는 것을 인정하는 것으로 해석되어서는 안된다. 섹션 제목이 사용되는 한, 반드시 제한적인 것으로 해석되어서는 안된다. 추가로, 본 출원의 모든 우선권 문서(들)는 그 전체가 참조로서 본원에 통합된다.

Claims

차량 간(V2V) 통신 채널들을 통해 수신되고 차량 컨센서스에 의해 검증된 업데이트들을 사용하여 차량들의 전자 제어 유닛들(ECU들)을 업데이트하는 방법에 있어서,
차량의 적어도 하나의 프로세서를 사용하여,
적어도 하나의 V2V 통신 채널을 통해, 상기 적어도 하나의 V2V 통신 채널의 수신 영역 내에 있는 적어도 하나의 주변 차량으로부터, 복수의 차량들에 배치된 복수의 ECU들을 업데이트하기 위해 분산된 복수의 업데이트 패키지들 중 적어도 하나를 수신하고;
상기 적어도 하나의 업데이트 패키지로부터 추출된 식별자를 분석하고;
상기 분석에 기초하여 상기 적어도 하나의 업데이트 패키지가 상기 차량의 적어도 하나의 ECU로 향하는지 여부를 결정하고;
긍정의 결정의 경우, 상기 적어도 하나의 V2V 통신 채널을 통해, 상기 복수의 업데이트 패키지들 각각을 각각의 검증 코드와 연관시키는 로컬 로그를 각각 유지하는, 상기 복수의 차량들 중 적어도 일부인, 서브셋의 차량들과 통신하여 상기 서브셋의 차량들의 컨센서스에 따라 상기 적어도 하나의 업데이트 패키지로부터 추출된 상기 검증 코드를 검증하고;
성공적인 검증의 경우, 상기 적어도 하나의 업데이트 패키지를 사용하여 상기 적어도 하나의 ECU의 업데이트를 개시하기 위한 코드를 실행하는 단계를 포함하는, 방법.
제1항에 있어서, 상기 적어도 하나의 V2V 통신 채널은 근접하게 위치된 차량들 간의 통신을 설정하기 위한 근거리 통신 채널인, 방법.
제1항에 있어서, 상기 복수의 업데이트 패키지들 각각은 펌웨어 업데이트, 미들웨어 업데이트 및 소프트웨어 업데이트로 구성된 그룹의 멤버인, 방법.
제1항에 있어서, 복수의 업데이트 패키지들 각각이 만료 시간 태그와 연관되고 이후에는 각각의 업데이트 패키지가 무효화되는 단계를 더 포함하는, 방법.
제1항에 있어서, 상기 복수의 업데이트 패키지들 각각은 상기 복수의 업데이트 패키지들을 상기 복수의 차량들 중 적어도 일부로 전송하도록 적응된 적어도 하나의 신뢰할 수 있는 분산 시스템으로부터 비롯되는, 방법.
제1항에 있어서, 상기 적어도 하나의 업데이트 패키지는 상기 적어도 하나의 업데이트 패키지들에 대해 추출된 적어도 하나의 패키지 속성과 상기 적어도 하나의 ECU와 연관된 적어도 하나의 ECU 속성을 비교하여 상기 적어도 하나의 ECU로 향하도록 결정되는, 방법.
제1항에 있어서, 상기 복수의 차량들 각각은 상기 복수의 차량들 중 적어도 일부 다른 차량들과 통신하여 그 각각의 로컬 로그를 지속적으로 업데이트하고 동기화하는, 방법.
제1항에 있어서, 상기 서브셋의 차량들 각각에 의해 유지되는 상기 로컬 로그가 복수의 변경할 수 없는 비가역적 블록들을 포함하는 블록체인에 의해 구현되며, 상기 복수의 업데이트 패키지들 중 각각에 대하여 적어도 하나의 신뢰할 수 있는 분산 시스템에 의해 생성된 상기 복수의 변경할 수 없는 비가역적 블록들 각각은 상기 각각의 업데이트 패키지의 상기 식별자를 상기 각각의 업데이트 패키지의 상기 검증 코드와 관련시키는 단계를 더 포함하는, 방법.
제1항에 있어서, 상기 적어도 하나의 주변 차량의 아이덴티티 및 상기 서브셋의 차량들 각각의 아이덴티티는 추가 데이터 교환 전에 신뢰할 수 있는 통신 세션을 설정하도록 우선 인증되는, 방법.
제1항에 있어서, 상기 검증 코드는 상기 복수의 업데이트 패키지들 각각의 각 식별자가 상기 서브셋의 차량들 각각의 로그에서 각각의 해시 값과 연관되도록 적어도 하나의 해시 함수를 사용하여 상기 적어도 하나의 업데이트 패키지에 대해 계산된 해시 값인, 방법.
제1항에 있어서, 상기 서브셋의 차량들의 수는 적어도 하나의 보안 파라미터들에 따라 설정되는, 방법.
제1항에 있어서, 상기 수신된 적어도 하나의 업데이트 패키지는 상기 적어도 하나의 V2V 통신 채널을 통해 상기 복수의 차량들 중 적어도 하나의 다른 주변 차량으로 전송되는, 방법.
제12항에 있어서, 상기 적어도 하나의 업데이트 패키지의 전송은 기록되지 않는, 방법.
제12항에 있어서, 상기 수신된 적어도 하나의 업데이트 패키지는 미리 정의된 시간 기간 동안 로컬에 저장되고, 적어도 하나의 다른 주변 차량으로의 전송에 이용 가능하며, 상기 적어도 하나의 업데이트 패키지는 상기 미리 정의된 시간 기간의 만료 시 폐기되는, 방법.
제14항에 있어서, 상기 차량의 적어도 하나의 동작 파라미터에 따라 상기 미리 정의된 시간 기간을 조정하는 단계를 더 포함하며, 상기 적어도 하나의 동작 파라미터는, 상기 차량의 지리적 영역, 주변 지형, 상기 차량의 온/오프 상태 및 상기 차량의 속도로 구성된 그룹의 멤버인, 방법.
제12항에 있어서, 상기 적어도 하나의 업데이트 패키지의 후속 전송들 사이의 미리 정의된 비-전송 기간 동안 대기하는 단계를 더 포함하고, 그 동안 상기 적어도 하나의 업데이트 패키지가 전송되지 않는, 방법.
제1항에 있어서, 상기 적어도 하나의 업데이트 패키지의 수신 이후 미리 정의된 비-수신 기간 동안 대기하는 단계를 더 포함하고, 그 동안 업데이트 패키지들의 수신이 금지되는, 방법.
제1항에 있어서, 복수의 개별 수신 세션들에서 상기 적어도 하나의 업데이트 패키지를 누적식으로 수신하는 단계를 더 포함하며, 상기 복수의 차량들 중 적어도 하나와 설정된 상기 복수의 수신 세션들 각각 동안, 상기 적어도 하나의 업데이트 패키지의 수신은 상기 적어도 하나의 업데이트 패키지의 적어도 하나의 추가 부분을 수신하도록 재개되는, 방법.
제1항에 있어서, 상기 차량과 연관된 적어도 하나의 모바일 장치가 상기 적어도 하나의 업데이트 패키지를 수신하고, 상기 적어도 하나의 업데이트 패키지가 상기 연관된 차량의 상기 적어도 하나의 ECU로 향하는지 여부를 결정하고, 상기 적어도 하나의 업데이트 패키지를 검증하고 상기 적어도 하나의 업데이트 패키지를 사용하여 상기 업데이트를 개시하는 단계를 더 포함하는, 방법.
차량 간(V2V) 통신 채널들을 통해 수신되고 차량 컨센서스에 의해 검증된 업데이트들을 사용하여 차량들의 전자 제어 유닛들(ECU들)을 업데이트하는 시스템에 있어서,
적어도 하나의 V2V 통신 채널에 연결하기 위해 차량에 배치된 적어도 하나의 V2V 통신 인터페이스; 및
상기 적어도 하나의 V2V 통신 인터페이스에 결합된 상기 차량의 적어도 하나의 프로세서로서, 상기 적어도 하나의 프로세서는,
적어도 하나의 V2V 통신 채널을 통해, 상기 적어도 하나의 V2V 통신 채널의 수신 영역 내에 있는 적어도 하나의 주변 차량으로부터, 복수의 차량들에 배치된 복수의 ECU들을 업데이트하기 위해 배포된 복수의 업데이트 패키지들 중 적어도 하나를 수신하기 위한 코드 인스트럭션들;
상기 적어도 하나의 업데이트 패키지로부터 추출된 식별자를 분석하기 위한 코드 인스트럭션들;
상기 분석에 기초하여 상기 적어도 하나의 업데이트 패키지가 상기 차량의 적어도 하나의 ECU로 향하는지 여부를 결정하기 위한 코드 인스트럭션들;
긍정의 결정의 경우, 상기 적어도 하나의 V2V 통신 채널을 통해, 상기 복수의 업데이트 패키지들 각각을 각각의 검증 코드와 연관시키는 로컬 로그를 각각 유지하는, 상기 복수의 차량들 중 적어도 일부인, 서브셋의 차량들과 통신하여 상기 서브셋의 차량들의 컨센서스에 따라 상기 적어도 하나의 업데이트 패키지로부터 추출된 상기 검증 코드를 검증하기 위한 코드 인스트럭션들; 및
성공적인 검증의 경우, 상기 적어도 하나의 업데이트 패키지를 사용하여 상기 적어도 하나의 ECU의 업데이트를 개시하기 위한 코드 인스트럭션들을 포함하는 코드를 실행하는, 상기 적어도 하나의 프로세서를 포함하는, 시스템.