KR102561411B1

KR102561411B1 - Oma-dm 표준 확장 구조를 이용하는 ota 기반 차량 긴급 업데이트 알림 배포 방법 및 장치

Info

Publication number: KR102561411B1
Application number: KR1020220164975A
Authority: KR
Inventors: 오진혁; 윤건; 윤선우; 이상민; 임명철; 김태균; 심상규; 김의석; 김덕수
Original assignee: 펜타시큐리티시스템 주식회사; 아우토크립트 주식회사
Priority date: 2022-11-30
Filing date: 2022-11-30
Publication date: 2023-07-31

Abstract

OMA-DM 표준 확장 구조를 이용하는 OTA 기반 차량 긴급 업데이트 알림 배포 방법 및 장치가 개시된다. 차량 긴급 업데이트 알림 배포 방법은, 차량의 클라이언트로부터 기기정보(DevInfo)를 포함한 패키지를 수신하는 단계, 및 서버가 자체 보유한 긴급 소프트웨어 업데이터 버전과, DevInfo에 포함된 대상 소프트웨어 현재 버전, 긴급 업데이트 알림 정보, 서버로 업로드된 긴급 업데이트 소프트웨어 버전, 및 긴급 업데이트 알림 수신 시간에 기초하여, 클라이언트의 긴급 업데이트 알림 상태를 확인하는 단계를 포함한다.

Description

OMA-DM 표준 확장 구조를 이용하는 OTA 기반 차량 긴급 업데이트 알림 배포 방법 및 장치{DISTRIBUTION METHOD AND APPARATUS FOR OTA-BASED VEHICLE EMERGENCY UPDATE ALERT USING OMA-DM STABDARD EXTENSION STRUCTURE}

본 발명은 OMA-DM(device management) 표준 확장 구조를 이용하는 OTA(over-the air) 기반 차량 긴급 업데이트 알림 배포 방법 및 장치에 관한 것이다.

오픈 모바일 얼라이언스(open mobile alliance, OMA)는 무선 산업 분야에 관련된 공개 표준을 제정하는 기구이다. 이 기구의 임무는 국가 간, 사업자 간, 이동 단말기 간에 상호 운용 가능한 서비스를 제공하는 것이다. OMA는 실용적인 프로토콜의 표준화에만 관심을 가지고 있으며, 외부 기구에 의해서 규정된 네트워킹 기술의 존재를 가정한다. OMA 규격들은 네트워킹이나 실제적인 데이터 트랜스포트를 제공하는 데 사용되고 있는 특정 셀룰러 네트워크 기술은 무엇이든 상관하지 않는다.

오버 디 에어(over-the air, OTA)는 펌웨어 업데이트 방식들 중 하나이다. OTA는 컴퓨터에 연결되지 않고 Wi-Fi, 이동통신망 등의 무선으로 펌웨어를 업데이트하는 기술을 의미한다. 최근, 차량 OTA 업데이트 기술은 새로운 소프트웨어, 펌웨어, 설정, 암호화 키에 관한 업데이트를 오프라인 간섭 없이 원격으로 배포하는 차량 원격 관리에 적용되고 있다.

차량 OTA 업데이트를 사용하면, 차량 소프트웨어 업데이트를 위한 방문수리, USB 배송 등에 대한 비용이나 시간을 생략하거나 줄일 수 있고, 차량 결함 대부분을 소프트웨어 업데이트로 해결하거나 차량 소프트웨어 업데이트를 통해 차량에 대한 새로운 기능을 효율적으로 제공할 수 있다.

한편, 차량 OTA 업데이트를 사용하는 경우, 공격자는 퍼스널 컴퓨터(PC) 또는 스마트폰에 대한 공격 기법을 자율주행차량에 그대로 적용할 수 있으므로, 이러한 공격자의 악의적인 공격을 방어하거나 예방할 필요가 있다. 이러한 악의적인 공격에 대한 방어나 예방 방안 중 가장 효율적인 방법은 차량 소프트웨어의 빠른 업데이트로 알려져 있다.

공개특허공보 제10-2021-0133587호(2021.11.08)

본 발명의 목적은 OTA(over-the air)를 이용한 차량 긴급 업데이트 알림을 위한 OMA(open mobile alliance)-DM(device management) 표준 확장 구조를 이용하는 OTA 기반 차량 긴급 업데이트 알림 배포 방법 및 장치를 제공하는 데 있다.

본 발명의 다른 목적은 OMA-DM 표준에서 기기 상태 정보를 동기화하는 DevInfo 항목이 자율주행차량 업데이트에 부적합한 문제를 해결하여 자율주행차량의 OTA 업데이트시 충분한 차량 정보 동기화를 위한 DevInfo 노드를 제공할 수 있고, 차량 긴급 업데이트 알림을 위한 DevInfo 노드를 제공할 수 있는 OMA-DM 표준 확장 구조를 이용하는 OTA 기반 차량 업데이트 방법 및 장치를 제공하는데 있다.

본 발명의 또 다른 목적은 대용량 OTA 업데이트 시 발생할 수 있는 문제점을 해결할 수 있는, 즉 대용량 OTA 업데이트시 업데이트 시간을 단축하고 데이터 용량 및 통신 비용을 절감할 수 있는, OMA-DM 표준 확장 구조를 이용하는 OTA 기반 차량 업데이트 방법 및 장치를 제공하는데 있다.

본 발명의 또 다른 목적은 관리 서버가 자율주행차량의 관리 정보를 정확하게 파악할 수 있도록 표준 규격을 확장하여 정의함으로써 자율주행차량에 적합한 기기 관리 객체 정의와 자율주행차량 상태에 따른 차분 업데이트를 수행할 수 있는, OMA-DM 표준 확장 구조를 이용하는 OTA 기반 차량 업데이트 방법 및 장치를 제공하는데 있다.

본 발명의 또 다른 목적은 OMA-DM 표준 내 OTA 기반 자율주행차량의 긴급 업데이트 알림을 위한 DevInfo 항목을 제공하기 위해 차량 긴급 업데이트 알림을 위한 DevInfo 노드를 추가하는, OMA-DM 표준 확장 구조를 이용하는 OTA 기반 차량 긴급 업데이트 알림 배포 방법 및 장치를 제공하는데 있다.

본 발명의 또 다른 목적은 긴급 OTA 업데이트 시 발생할 수 있는 문제점을 해결할 수 있는, 즉 긴급 보안 패치 등 특수한 상화에서의 빠른 대응을 지원하고, 업데이트 소프트웨어 배포 시간을 단축하며, 업데이트 시간을 단축할 수 있는, OMA-DM 표준 확장 구조를 이용하는 OTA 기반 차량 긴급 업데이트 알림 배포 방법 및 장치를 제공하는데 있다.

본 발명의 또 다른 목적은 관리 서버가 자율주행차량의 긴급 업데이트 정보를 알릴 수 있도록 표준 규격을 확장하여 정의함으로써 자율주행차량에 적합한 긴급 알림 객체 정의와 긴급 업데이트 발생 시 자율주행차량으로의 빠른 알림 정보를 배포할 수 있는, OMA-DM 표준 확장 구조를 이용하는 OTA 기반 차량 긴급 업데이트 알림 배포 방법 및 장치를 제공하는데 있다.

상기 기술적 과제를 해결하기 위한 본 발명의 일 측면에 따른 차량 긴급 업데이트 알림 배포 방법은, OMA(open mobile alliance)-DM(device management) 표준 확장 포맷을 이용하는 OTA(over-the air) 기반 차량 긴급 업데이트 알림 배포 방법으로서, 차량의 클라이언트로부터 기기정보(device information, DevInfo)를 포함한 패키지를 수신하는 단계; 및 자체 보유한 긴급 소프트웨어 업데이터 버전과, 상기 DevInfo에 포함된 대상 소프트웨어 현재 버전, 긴급 업데이트 알림 정보, 서버로 업로드된 긴급 업데이트 소프트웨어 버전, 및 긴급 업데이트 알림 수신 시간에 기초하여, 상기 클라이언트의 긴급 업데이트 알림 상태를 확인하는 단계를 포함한다.

상기 업데이트 알림 배포 방법은, 상기 긴급 업데이트 알림 정보가 기본 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전에 비해 상기 긴급 소프트웨어 업데이트 버전이 최신 버전일 때, 긴급 업데이트 정보를 상기 클라이언트로 전송하는 단계를 더 포함할 수 있다.

상기 업데이트 알림 배포 방법은, 상기 긴급 업데이트 알림 정보가 긴급 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전이 상기 긴급 소프트웨어 업데이트 버전과 동일하며, 상기 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전이 긴급 소프트웨어 업데이트 버전에 비해 이전 버전일 때, 상기 클라이언트의 주변 차량으로 긴급 업데이트 정보 전송과 업데이트를 권고하는 메시지를 상기 클라이언트로 전송하는 단계를 더 포함할 수 있다.

상기 업데이트 알림 배포 방법은, 상기 긴급 업데이트 알림 정보가 긴급 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전 및 상기 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전이 상기 긴급 소프트웨어 업데이트 버전과 동일할 때, 상기 클라이언트의 주변 차량으로 긴급 업데이트 정보 전송을 요청하는 메시지를 상기 클라이언트로 전송하는 단계를 더 포함할 수 있다.

상기 DevInfo는 Ext 필드, Bearer 필드, VeID 필드, VeMan 필드, VeMod 필드, VeLoc 필드, VeYear 필드, DmV 필드, Lang 필드, SwID 필드, SwV 필드, LastV 필드, LastUpdate 필드, EmN 필드, EmV 필드 및 EmNRT 필드를 포함할 수 있다.

상기 기술적 과제를 해결하기 위한 본 발명의 다른 측면에 따른 차량 긴급 업데이트 알림 배포 방법은, OTA(over-the air)를 이용한 차량 긴급 업데이트 알림을 위해 차량의 클라이언트에 의해 수행되는 OMA(open mobile alliance)-DM(device management) 프로토콜의 업데이트 알림 배포 방법으로서, 기기정보(DevInfo)를 포함한 패키지를 생성하는 단계; 상기 패키지를 서버로 전송하는 단계-상기 서버는, 자체 보유한 긴급 소프트웨어 업데이터 버전과, 상기 DevInfo에 포함된 대상 소프트웨어 현재 버전, 긴급 업데이트 알림 정보, 서버로 업로드된 긴급 업데이트 소프트웨어 버전, 및 긴급 업데이트 알림 수신 시간에 기초하여, 상기 클라이언트의 긴급 업데이트 알림 상태를 확인함-; 및 상기 서버로부터 상기 긴급 업데이트 알림 상태에 따른 긴급 업데이트 정보를 수신하는 단계를 포함한다.

상기 긴급 업데이트 정보를 수신하는 단계는, 상기 DevInfo 내 상기 긴급 업데이트 알림 정보가 기본 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전에 비해 상기 긴급 소프트웨어 업데이트 버전이 최신 버전일 때, 수행될 수 있다.

상기 긴급 업데이트 정보를 수신하는 단계는, 상기 DevInfo 내 상기 긴급 업데이트 알림 정보가 긴급 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전이 상기 긴급 소프트웨어 업데이트 버전과 동일하며, 상기 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전이 긴급 소프트웨어 업데이트 버전에 비해 이전 버전일 때, 상기 클라이언트의 주변 차량으로 긴급 업데이트 정보 전송과 업데이트를 권고하는 메시지를 수신할 수 있다.

상기 업데이트 알림 배포 방법은, 상기 긴급 업데이트 정보를 주변 차량으로 V2V(vehicle to vehicle) 통신 기반으로 브로드캐스팅하는 단계를 더 포함할 수 있다.

상기 긴급 업데이트 정보를 수신하는 단계는, 상기 DevInfo 내 상기 긴급 업데이트 알림 정보가 긴급 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전 및 상기 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전이 상기 긴급 소프트웨어 업데이트 버전과 동일할 때, 상기 클라이언트의 주변 차량으로 긴급 업데이트 정보 전송을 요청하는 메시지를 수신할 수 있다.

상기 기술적 과제를 해결하기 위한 본 발명의 또 다른 측면에 따른 차량 긴급 업데이트 알림 배포 장치는, OMA(open mobile alliance)-DM(device management) 표준 확장 포맷을 이용하는 OTA(over-the air) 기반 차량 긴급 업데이트 알림 배포 장치로서, 차량의 클라이언트로부터 기기정보(device information, DevInfo)를 포함한 패키지를 수신하는 송수신 장치; 및 자체 보유한 긴급 소프트웨어 업데이터 버전과, 상기 DevInfo에 포함된 대상 소프트웨어 현재 버전, 긴급 업데이트 알림 정보, 서버로 업로드된 긴급 업데이트 소프트웨어 버전, 및 긴급 업데이트 알림 수신 시간에 기초하여, 상기 클라이언트의 긴급 업데이트 알림 상태를 확인하는 프로세서를 포함한다.

상기 기술적 과제를 해결하기 위한 본 발명의 또 다른 측면에 따른 차량 긴급 업데이트 알림 배포 장치는, OMA(open mobile alliance)-DM(device management) 표준 확장 포맷을 이용하는 OTA(over-the air) 기반 차량 긴급 업데이트 알림 배포 장치로서, 기기정보(DevInfo)를 포함한 패키지를 생성하는 프로세서; 및 상기 패키지를 서버로 전송하고, 상기 서버로부터 긴급 업데이트 알림 상태에 따른 긴급 업데이트 정보를 수신하는 송수신 장치를 포함한다. 상기 클라이언트의 상기 긴급 업데이트 알림 상태는, 상기 서버가 자체 보유한 긴급 소프트웨어 업데이터 버전과, 상기 DevInfo에 포함된 대상 소프트웨어 현재 버전, 긴급 업데이트 알림 정보, 서버로 업로드된 긴급 업데이트 소프트웨어 버전, 및 긴급 업데이트 알림 수신 시간에 기초하여, 상기 서버에서 확인될 수 있다.

상기 기술적 과제를 해결하기 위한 본 발명의 또 다른 측면에 따른 차량 긴급 업데이트 알림 배포 방법은, 차량의 클라이언트로부터 차량기기정보(DevInfo)를 포함한 패키지를 수신하는 단계; 및 상기 DevInfo에 포함된 차량 등록 지역에 대한 정보를 정의하는 VeLoc 필드, 차량 연식에 대한 정보를 정의하는 VeYear 필드, 및 소프트웨어 확장을 정의하는 SW 필드로부터의 정보에 기초하여, 상기 클라이언트가 보유한 소프트웨어의 업데이트 상태를 확인하는 단계를 더 포함한다.

상기 SW 필드는, 대상 소프트웨어 식별자를 정의하는 SwID 필드, 대상 소프트웨어 현재 버전을 정의하는 SwV 필드, 가장 마지막에 다운로드한 소프트웨어 버전을 정의하는 LastV 필드, 및 마지막 업데이트 날짜를 정의하는 LastUpdate 필드를 포함할 수 있다.

상기 확인하는 단계는, 서버에 저장된 소프트웨어 최신 버전과 상기 차량의 소프트웨어 설치 버전인 상기 DevInfo의 대상 소프트웨어 현재 버전과 비교하는 단계를 포함할 수 있다.

상기 확인하는 단계는, 상기 비교하는 단계에서의 비교 결과, 상기 서버가 보유하는 소프트웨어 최신 버전과 상기 대상 소프트웨어 현재 버전이 같지 않은 경우, 상기 서버가 보유하는 소프트웨어 최신 버전과 상기 DevInfo의 가장 마지막에 다운로드한 소프트웨어 버전을 비교 검증하는 단계를 더 포함할 수 있다.

상기 차량 긴급 업데이트 알림 배포 방법은, 업데이트가 필요한 소프트웨어 파일만을 상기 클라이언트로 전송하는 단계를 더 포함할 수 있다. 여기서, 상기 클라이언트는 상기 소프트웨어 파일을 통해 차량에서 업데이트가 필요한 소프트웨어만을 업데이트할 수 있다.

상기 기술적 과제를 해결하기 위한 본 발명의 또 다른 측면에 따른 차량 긴급 업데이트 알림 배포 장치에서, 상기 프로세서는, 상기 DevInfo에 포함된 차량 등록 지역에 대한 정보를 정의하는 VeLoc 필드, 차량 연식에 대한 정보를 정의하는 VeYear 필드, 및 소프트웨어 확장을 정의하는 SW 필드로부터의 정보에 기초하여, 상기 클라이언트가 보유한 소프트웨어의 업데이트 상태를 확인하는 단계를 더 수행하도록 구성될 수 있다.

상기 프로세서는, 상기 확인하는 단계에서, 상기 서버에 저장된 소프트웨어 최신 버전과 상기 차량의 소프트웨어 설치 버전인 상기 DevInfo의 대상 소프트웨어 현재 버전을 비교하도록 구성될 수 있다.

상기 프로세서는, 비교 결과에서, 상기 서버가 보유하는 소프트웨어 최신 버전과 상기 대상 소프트웨어 현재 버전이 같지 않은 경우, 상기 서버가 보유하는 소프트웨어 최신 버전과 상기 DevInfo의 가장 마지막에 다운로드한 소프트웨어 버전을 비교 검증하도록 구성될 수 있다.

상기 프로세서는, 업데이트가 필요한 소프트웨어 파일을 상기 클라이언트로 전송하도록 구성될 수 있다. 여기서, 상기 소프트웨어 파일은 상기 클라이언트에 의해 상기 차량에서 업데이트가 필요한 소프트웨어만을 업데이트하는데 이용될 수 있다.

상기 프로세서는, 기저장된 소프트웨어 최신 버전과 상기 차량의 소프트웨어 설치 버전인 상기 DevInfo의 대상 소프트웨어 현재 버전을 비교하고, 비교 결과에서 상기 서버가 보유하는 소프트웨어 최신 버전과 상기 대상 소프트웨어 현재 버전이 다른 경우, 상기 서버가 보유하는 소프트웨어 최신 버전과 상기 DevInfo의 가장 마지막에 다운로드한 소프트웨어 버전을 비교 검증할 수 있다.

상기 프로세서는, 상기 송수신 장치를 통해 상기 서버로부터 업데이트가 필요한 소프트웨어 파일을 받도록 구성될 수 있다.

상기 프로세서는, 상기 소프트웨어 파일을 통해 차량에서 업데이트가 필요한 소프트웨어만을 업데이트하도록 구성될 수 있다.

본 발명에 의하면, OMA-DM(device management)의 표준 확장을 통해 차량 OTA(over-the air) 업데이트의 효율성을 향상시킬 수 있다.

또한, 본 발명에 의하면, OMA-DM 표준에서 기기 상태 정보를 동기화하는 DevInfo 항목을 확장시켜 정의함으로써 자율주행차량의 OTA 업데이트시 충분한 차량 정보 동기화를 위한 DevInfo 노드를 제공할 수 있다.

또한, 본 발명에 의하면, DevInfo 항목의 확장을 통해 대용량 OTA 업데이트시 발생할 수 있는 문제점을 해결할 수 있다. 즉, 대용량 OTA 업데이트시 업데이트 시간을 단축하고 데이터 용량 및 통신 비용을 절감할 수 있다.

또한, 본 발명에 의하면, 관리 서버가 자율주행차량의 관리 정보를 정확하게 파악할 수 있는 표준 규격을 확장하여 정의함으로써 자율주행차량에 적합한 기기 관리 객체 정의와 자율주행차량 상태에 따른 차분 업데이트를 효과적으로 수행할 수 있다.

또한, 본 발명에 의하면, DevInfo 포맷에 대한 데이터 포맷을 기반으로 자율주행차량 등의 차량에 대한 긴급 업데이트 알림 정보를 대상 차량이나 주변 차량들로 배포하는 방안을 제공할 수 있다. 즉, OMA-DM 프로토콜의 메시지 내 DevInfo 항목의 Data Format을 확장시켜 각 소프트웨어 업데이트 상태에 따른 긴급 업데이트 알림을 효과적으로 배포할 수 있다. 또한, 긴급 업데이트 알림이 필요한 클라이언트에게 선택적으로 알림 정보를 전송하므로 통신 비용을 절감하고 긴급 알림의 배포 시간을 단축할 수 있다. 또한, 업데이트가 필요한 소프트웨어로만 선택적으로 구성한 소프트웨어 파일을 DM 클라이언트로 전송하므로 데이터 용량을 감소시키고 통신 비용을 절감할 수 있으며, 업데이트에 필요한 지연 시간을 최소화할 수 있다.

또한, 본 발명에 의하면, 긴급 업데이트 정보를 수신한 차량을 긴급 업데이트 알림 정보의 확산 매개체로 활용할 수 있다. 즉, 긴급 업데이트 정보를 수신한 차량이 해당 정보를 가까운 주변 차량에 확산하도록 지원하므로 긴급 업데이트 알림의 배포 시간을 단축하고, 소프트웨어 업데이트 상태에 따른 OTA 업데이트 지원 및 자체 업데이트 권고로 빠른 패치 지원을 수행할 수 있다.

도 1은 OMA(open mobile alliance)에서 제안하는 OMA-DM(device management) 프로토콜의 설정 단계(setup phase)를 설명하기 위한 도면이다.
도 2는 OMA-DM 프로토콜의 관리 단계(management phase)를 설명하기 위한 도면이다.
도 3은 OMA-DM 프로토콜을 따르는 단말기 내 데이터에 서버가 원격으로 접근할 수 있는 규격을 SyncML 형식으로 정의한 예시도이다.
도 4는 OMA-DM 프로토콜에 따른 대용량 객체 취급(large object handling)을 위한 대용량 객체 추가의 DM 패키지 흐름을 나타낸 예시도이다.
도 5는 도 4의 패키지#1의 알림(Alert) 1201, 대체(replace) 메시지의 기기정보(DevInfo) 항목에 대한 주소지정 체계(addressing scheme)를 나타낸 도면이다.
도 6은 본 발명의 일실시예에 따른 OMA(open mobile alliance)-DM(device management) 표준 확장 구조를 이용하는 OTA(over-the air) 기반 차량 긴급 업데이트 알림 배포 방법(간략히 '업데이트 알림 배포 방법')에 채용할 수 있는 기기정보(DevInfo)의 확장 구조(간략히 '확장 DevInfo')를 설명하기 위한 도면이다.
도 7은 도 6의 확장 DevInfo를 이용하는 업데이트 알림 배포 방법을 설명하기 위한 흐름도이다.
도 8은 본 발명의 다른 실시예에 따른 업데이트 알림 배포 방법을 설명하기 위한 순서도이다.
도 9는 도 8의 확인 과정에 채용할 수 있는 상세 과정에 대한 흐름도이다.
도 10은 도 8의 업데이트 알림 배포 방법에서 긴급 업데이트 알림을 수신한 차량이 주변 차량에게 알림 정보를 전달하는 과정을 설명하기 위한 예시도이다.
도 11은 본 발명의 또 다른 실시예에 따른 업데이트 알림 배포 방법을 설명하기 위한 순서도이다.
도 12는 본 발명의 또 다른 실시예에 따른 OMA-DM 표준 확장 구조를 이용하는 OTA 기반 차량 긴급 업데이트 알림 배포 장치(간략히 '업데이트 알림 배포 장치')에 채용할 수 있는 구성에 대한 개략도이다.

본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.

제1, 제2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. '및/또는'이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.

본 출원의 실시예들에서, 'A 및 B 중에서 적어도 하나'는 'A 또는 B 중에서 적어도 하나' 또는 'A 및 B 중 하나 이상의 조합들 중에서 적어도 하나'를 의미할 수 있다. 또한, 본 출원의 실시예들에서, 'A 및 B 중에서 하나 이상'은 'A 또는 B 중에서 하나 이상' 또는 'A 및 B 중 하나 이상의 조합들 중에서 하나 이상'을 의미할 수 있다.

어떤 구성요소가 다른 구성요소에 '연결되어' 있다거나 '접속되어' 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 '직접 연결되어' 있다거나 '직접 접속되어'있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, '포함한다' 또는 '가진다' 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가진 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

이하, 첨부한 도면들을 참조하여, 본 발명의 바람직한 실시예를 보다 상세하게 설명하고자 한다. 이하의 상세한 설명은 단지 예시적인 목적으로 제공되는 것이며, 본 발명의 개념을 임의의 특정된 물리적 구성에 한정하는 것으로 해석되어서는 안 될 것이다. 본 발명을 설명함에 있어 전체적인 이해를 용이하게 하기 위하여 도면상의 동일한 구성요소에 대해서는 동일한 참조부호를 사용하고 동일한 구성요소에 대해서 중복된 설명은 생략한다.

도 1은 OMA(open mobile alliance)에서 제안하는 OMA-DM(device management) 프로토콜의 설정 단계(setup phase)를 설명하기 위한 도면이다.

도 1을 참조하면, OMA-DM 프로토콜의 설정 단계에서, 클라이언트(20)는 서버(10)로부터 패키지 0(package 0)을 받는다(S11). 패키지 0은 관리 초기화 알림(management initiation alert) 메시지를 포함한다. 패키지는 적어도 하나 이상의 메시지를 포함한다. 그리고 서버(10)는 OMA-DM 프로토콜을 따르는 DM 서버일 수 있고, 클라이언트(20)는 OMA-DM 프로토콜을 따르는 DM 클라이언트일 수 있다.

다음, 클라이언트(20)는 패키지 1(package 1)을 서버(10)로 전송한다(S13). 패키지 1은 DM 클라이언트의 클라이언트 초기화를 위한 초기화 패키지(initialization package)로서, 클라이언트 자격 증명(client credentials)과 기기 정보(device information)에 대한 메시지를 포함한다.

다음, 클라이언트(20)는 서버(10)로부터 패키지 2(package 2)를 수신한다(S15). 패키지 2는, DM 서버의 서버 초기화(server initialization)를 위한 초기화 패키지로서, 서버 자격 증명(server credentials)과, 서버(10)로부터의 초기 관리 동작(initial management operations) 또는 사용자 상호작용 명령(user interaction commands)에 대한 메시지를 포함한다.

도 2는 OMA-DM 프로토콜의 관리 단계(management phase)를 설명하기 위한 도면이다.

도 2를 참조하면, OMA-DM 프로토콜의 관리 단계에서, 클라이언트(20)는 패키지 3(package 3)을 서버(10)로 전송한다(S17). 패키지 3은 DM 서버로 전송되는 DM 클라이언트 응답으로서, 관리 동작에 대한 메시지를 포함한다.

다음, 클라이언트(20)는 서버(10)로부터 패키지 4(package 4)를 수신한다(S19). 패키지 4는 DM 서버의 추가 관리 작을 위한 패키지로서, 세션이 계속될 때 추가적인 사용자 상호작용 및 관리 작업에 대한 적어도 하나 이상의 메시지를 포함한다.

도 3은 OMA-DM 프로토콜을 따르는 단말기 내 데이터에 서버가 원격으로 접근할 수 있는 규격을 SyncML 형식으로 정의한 예시도이다.

도 3을 참조하면, OMA-DM 프로토콜을 따르는 DM 서버는, SyncML 메시지를 통해 DM 클라이언트 내 데이터에 원격으로 접근할 수 있다. 이러한 SyncML 메시지는 플랫폼 독립적인 데이터 동기화 표준으로서, 마이크로소프트 윈도우를 사용하는 퍼스널 컴퓨터(PC), 리눅스(linux)를 사용하는 PC, 팜(Palm) PDA(personal digital assistant), 휴대전화, 아이팟, 아이폰, 차량 등의 어떤 기기와도 자유롭게 데이터를 동기화할 수 있다. SyncML은 XML(extensible markup language)을 기반으로 한다. 또한, SyncML 메시지는 DM 클라이언트로부터 전송되는 패키지 1이나, DM 클라이언트로부터 전송되는 패키지 2 등에 적용될 수 있다. 메시지는 하나 이상의 명령을 포함할 수 있다.

각 메시지는 SyncHdr 요소(element)로 지정된 헤더와 SyncBody 요소로 지정된 메시지 본문으로 구성된다. 즉, 메시지 컨테이너 엘리먼트는 <SyncML>, <SyncHdr> 및 <SyncBody>를 포함한다.

<SyncML>은 최상위 엘리먼트로서 MIME 컨텐트 타입을 포함할 수 있다.

<SyncHdr>은 DM 서비스를 위해 필요한 인증 정보, 문서 타입 정의(document type definition, DTD)(VerDTD), 프로토콜 유형(VerProto), 세션 식별자(SessionID), 메시지 식별자(MsgID), 대상(target) 경로 정보 등을 명세하기 위한 엘리먼트들을 포함한다. <SyncHdr>은 데이터 동기화 서비스와 동일한 의미로 사용된다.

<SyncBody>는 실제 수행이 필요한 명령어들을 담고 있는 엘리먼트로서, 명령어 식별자(CmdID), 데이터(Data) 등의 엘리먼트들을 포함할 수 있다.

도 4는 OMA-DM 프로토콜에 따른 대용량 객체 취급(large object handling)을 위한 대용량 객체 추가의 DM 패키지 흐름을 나타낸 예시도이다.

도 4를 참조하면, OMA-DM 프로토콜은 여러 DM 메시지를 사용하여 하나의 SyncML 패키지를 전송하는 기능을 제공한다. 이는 하나의 SyncML 패키지가 너무 커서 하나의 SyncML 메시지로 전송할 수 없을 때 필요하다. 예를 들어, 이러한 제한은 전송 프로토콜 또는 소형 풋프린트 장치의 제한으로 인해 발생할 수 있다.

OMA-DM 프로토콜에서 항목의 논리적 그룹화로서 패키지의 역할은 매우 제한적이다. 대부분의 제한은 패키지가 아닌 메시지에서 발생한다. 예를 들어 명령은 하나의 메시지에 완전히 맞아야 한다. 여기에는 순차적 명령(sequence command) 및 원자적 명령(atomic command)이 포함되며 각 명령은 하나의 메시지에 완전히 맞아야 한다.

제한된 자원으로 DM 클라이언트를 압도하는 것을 피하기 위해, DM 서버가 이전 명령에 대한 상태를 아직 반환하지 않은 클라이언트로 새 명령을 보내는 것은 허용되지 않는다. 즉, DM 서버에서 DM 클라이언트로 보내는 대부분의 메시지는 적어도 하나의 메시지를 포함한 패키지에 해당한다. 단, DM 서버가 큰 개체를 보내거나 더 많은 메시지를 요청하는 경우 즉, 알림(alert) 1222 사용하는 경우는 예외이다. 대용량 개체 데이터를 포함하는 패키지는 큰 개체를 전송하는 데 필요한 만큼의 메시지에 걸쳐 있다.

DM 서버는 패키지 경계와 관련하여 항상 다음의 1) 내지 3) 상태들 중 하나의 상태를 가진다.

1) DM 서버가 완전한 패키지를 보낸다(S42, S44c, S46, S48). 이 상태에서 DM 서버는 패키지로 전송된 명령에 대해 DM 클라이언트의 상태를 기다린다. Get 명령의 결과와 같이 상태 및 결과가 클 수 있기 때문에, DM 클라이언트는 응답을 완료하기 전에 여러 메시지를 DM 서버로 다시 보낼 수 있다.

2) DM 서버가 DM 클라이언트로부터 완전한 패키지 즉, 패키지 응답을 받는다(S41, S43b, S45b, S47). 이 상태에서 DM 서버는 DM 클라이언트에 새로운 명령을 보낼 수 있다.

3) DM 서버가 동일한 패키지의 일부인 하나 이상의 메시지를 보내고, 아직 현재 패키지의 최종 메시지를 보내지 않았다(S44a, S44b). 이 상태는 DM 서버가 큰 개체를 보내는 경우에만 유효하며 큰 개체의 마지막 청크가 보내지면 패키지가 종료된다.

한편, DM 서버는 DM 클라이언트로부터 최종 메시지를 포함하지 않은 불완전한 패키지 응답을 받을 수 있다(S43a, S45a).

DM 메시지에 대한 기본 전송에는 요청/응답 형식이 있기 때문에 DM 클라이언트 또는 DM 서버는 요청/응답 주기를 계속 유지하기 위해 새 명령이나 최종 플래그를 포함하지 않는 메시지를 보낼 수도 있다. 예를 들어, DM 서버가 상태 1 즉, 위의 1) 상태에 있을 때, 상태 및 결과를 포함하는 DM 클라이언트로부터 많은 메시지를 받을 수 있다. DM 서버는 DM 클라이언트가 보낸 각 메시지에 응답하지만 해당 응답에 새 명령을 포함하지 않을 수 있다. 이 상태에서 DM 서버가 보낸 메시지에는 DM 클라이언트가 보낸 SyncHdr에 대한 상태와 알림(alert) 1222 메시지 즉, 추가 메시지가 포함될 수 있다. 상태는 알림에 대한 응답으로 전송되어야 하지만 결과에 대한 응답으로 전송되지는 않는다. DM 서버가 세션을 중단하려는 경우, 알림 1222 메시지가 알림 1223 메시지 즉, 세션 중단 메시지로 대체될 수 있다.

이와 같이, 도 4는 전술한 여러 메시지를 사용할 수 있는 방법을 예시한다.

도 5는 도 4의 패키지#1의 알림(Alert) 1201 메시지인 대체(replace) 메시지의 기기정보(DevInfo) 항목에 대한 주소지정 체계(addressing scheme)를 나타낸 도면이다.

도 5를 참조하면, 기존의 메시지 내 기기정보(DevInfo, 50)는 Ext 필드(51), Bearer 필드(52), DevID 필드(53), Man 필드(54), Mod 필드(55), DmV 필드(56), Lang 필드(57)로 구성된다.

여기서, Ext 필드(51)는 선택적(optional, ?) 필드로서, DevInfo 포맷에서 확장 가능한 서브트리를 정의한다. Bearer 필드(52)는 선택적 필드로서, 네트워크 베어러 관련 항목을 정의한다. DevID 필드(53)는 기기 식별자를 정의한다. Man 필드(54)는 기기 제조사를 정의한다. Mod 필드(55)는 기기 모델 ID를 정의한다. DmV 필드(56)는 기기가 지원하는 DM 버전 정보를 정의한다. Lang 필드(57)는 기기에 나타나는 사용자 인터페이스 언어를 정의한다.

전술한 OMA-DM 프로토콜은 DM 트리 변경 알림(DM tree change alert) 메시지를 통해 DM 트리 변경을 DM 서버가 DM 클라이언트로, 혹은 DM 클라이언트가 DM 서버로 알리도록 구성될 수 있다.

도 6은 본 발명의 일실시예에 따른 OMA(open mobile alliance)-DM(device management) 표준 확장 구조를 이용하는 OTA(over-the air) 기반 차량 긴급 업데이트 알림 배포 방법(간략히 '업데이트 알림 배포 방법')에 채용할 수 있는 기기정보(DevInfo)의 확장 구조(간략히 '확장 DevInfo')를 설명하기 위한 도면이다.

도 6을 참조하면, 업데이트 알림 배포 방법은 확장 DevInfo 포맷을 사용할 수 있다. 확장 DevInfo 포맷은 차량 OTA 업데이트시, 클라이언트가 서버에 차량 기기의 상태 정보를 동기화하기 위해 사용될 수 있고, DM 서버에서 긴급 업데이트 발생 시, 다수의 클라이언트에 긴급 알림 정보를 빠르게 동기화하기 위해 사용될 수 있다.

여기서, 클라이언트는 기기 관리(device management, DM)를 지원하는 DM 클라이언트에 대응되고, 클라이언트 기기 또는 차량 기기로 지칭될 수 있다. 또한, 서버는 기기 관리(DM)를 지원하는 DM 서버에 대응되고, 서버 장치 등으로 지칭될 수 있다.

확장 DevInfo(60)는 Ext 필드(61), Bearer 필드(62), VeID 필드(63), VeMan 필드(64), VeMod 필드(65), VeLoc 필드(66), VeYear 필드(67), DmV 필드(68), Lang 필드(69), SW 필드(70), SwID 필드(71), SwV 필드(72), LastV 필드(73), LastUpdate 필드(74), Em 필드(75), EmN 필드(76), EmV 필드(77) 및 EmNRT 필드(78)를 포함하여 구성될 수 있다.

여기서, Ext 필드(61)는 선택적(optional, op) 필드로서, DevInfo 포맷에서 확장 가능한 서브트리를 정의할 수 있다. Bearer 필드(62)는 선택적(op) 필드로서, 네트워크 베어러 관련 항목을 정의할 수 있다. VeID 필드(63)는 차량 식별자를 정의할 수 있다. VeMan 필드(64)는 차량 제조사를 정의할 수 있다. VeMod 필드(65)는 차량 모델 ID를 정의할 수 있다.

VeLoc 필드(66)는 차량 등록 지역을 정의할 수 있다. VeYear 필드(67)는 차량 연식을 정의할 수 있다. DmV 필드(68)는 차량의 DM 클라이언트가 지원하는 DM 버전 정보를 정의할 수 있다. Lang 필드(69)는 차량의 DM 클라이언트에 나타나는 사용자 인터페이스 언어를 정의할 수 있다.

SW 필드(70)는 소프트웨어 확장을 정의할 수 있다. SwID 필드(71)는 대상 소프트웨어 식별자를 정의할 수 있다. SwV 필드(72)는 대상 소프트웨어 현재 버전을 정의할 수 있다. LastV 필드(73)는 가장 마지막에 다운로드한 소프트웨어 버전을 정의할 수 있다. 그리고 LastUpdate 필드(74)는 마지막 업데이트 날짜를 정의할 수 있다.

또한, Em 필드(75)는 긴급 알림(emergency notification) 확장을 정의할 수 있다. EmN 필드(76)는 긴급 업데이트 알림 정보를 정의할 수 있다. EmV 필드(77)는 서버로 업로드된 긴급 업데이트 소프트웨어 버전을 정의할 수 있다. 그리고 EmNRT 필드(78)는 긴급 업데이트 알림 수신 시간을 정의할 수 있다.

전술한 확장 DevInfo 포맷을 나타내면 다음의 표 1과 같다.

Field	설명
Ext (op)	확장 가능한 서브 트리
Bearer (op)	네트워크 베어러 관련 항목
VeID	차량 식별자 (차량번호)
VeMan	차량 제조사
VeMod	차량 모델 ID
VeLoc	차량 등록 지역
VeYear	차량 연식
DmV	차량의 DM 클라이언트가 지원하는 DM 버전 정보
Lang	차량의 DM 클라이언트에 나타나는 사용자 인터페이스 언어
SW	소프트웨어 확장
SwID	대상 소프트웨어 식별자
SwV	대상 소프트웨어 현재 버전
LastV	가장 마지막에 다운로드한 소프트웨어 버전
LastUpdate	마지막 업데이트 날짜
Em	긴급 알림 확장
EmN	긴급 업데이트 알림 정보
EmV	서버에 업로드된 긴급 업데이트 소프트웨어 버전
EmNRT	긴급 업데이트 알림 수신 시간

전술한 VeLoc 필드(66)가 차량 등록 지역으로서 '서울'을 정의하는 경우, 이를 SyncML(synchronization markup language) 형식으로 나타내면 다음과 같다.

<Item>

<Source><LocURI> ./DevInfo/VeLoc </LocURI><Source>

<Meta>

<Type xmlns=""syncml:metinf"> text/plain </Type>

</Meta>

</Item>

또한, 전술한 VeYear 필드(67)가 차량 연식으로서 '2020년12월12일'을 정의하는 경우, 이를 SyncML 형식으로 나타내면 다음과 같다.

<Item>

<Source><LocURI> ./DevInfo/VeYear </LocURI><Source>

<Meta>

<Type xmlns=""syncml:metinf"> text/plain </Type>

</Meta>

</Item>

또한, 전술한 SW 필드(70)의 SwID 필드(71)가 대상 소프트웨어 식별자로서 '880f36570'을 정의하는 경우, 이를 SyncML 형식으로 나타내면 다음과 같다.

<Item>

<Source><LocURI> ./DevInfo/SW/SwID </LocURI><Source>

<Meta>

<Type xmlns=""syncml:metinf"> text/plain </Type>

</Meta>

</Item>

또한, 전술한 SW 필드(70)의 SwV 필드(72)가 대상 소프트웨어 현재 버전로서 'version 1(v1)'을 정의하는 경우, 이를 SyncML 형식으로 나타내면 다음과 같다.

<Item>

<Source><LocURI> ./DevInfo/SW/SwV </LocURI><Source>

<Meta>

<Type xmlns=""syncml:metinf"> text/plain </Type>

</Meta>

</Item>

또한, 전술한 SW 필드(70)의 LastV 필드(73)가 차량 기기에서 가장 마지막에 다운로드한 소프트웨어 버전으로서 'version 1(v1)'을 정의하는 경우, 이를 SyncML 형식으로 나타내면 다음과 같다.

<Item>

<Source><LocURI> ./DevInfo/SW/LastV </LocURI><Source>

<Meta>

<Type xmlns=""syncml:metinf"> text/plain </Type>

</Meta>

</Item>

또한, 전술한 SW 필드(70)의 LastUpdate 필드(74)가 마지막 업데이트 날짜로서 '2020년12월24일'을 정의하는 경우, 이를 SyncML 형식으로 나타내면 다음과 같다.

<Item>

<Source><LocURI> ./DevInfo/SW/LastUpdate </LocURI><Source>

<Meta>

<Type xmlns=""syncml:metinf"> text/plain </Type>

</Meta>

</Item>

또한, 전술한 Em 필드(75)의 EmN 필드(76)가 긴급 업데이트 알림 정보로서 '0'을 정의하는 경우, 이를 SyncML 형식으로 나타내면 다음과 같다.

<Item>

<Source><LocURI> ./DevInfo/Em/EmN </LocURI><Source>

<Meta>

<Type xmlns=""syncml:metinf"> text/plain </Type>

</Meta>

</Item>

여기서, 긴급 업데이트 알림 정보의 '0'은 기본 상태(basic status)를, '1'은 긴급 상태(emergency status)를 나타낼 수 있다.

또한, 전술한 Em 필드(75)의 EmV 필드(77)가 서버에 업로드된 긴급 업데이트 소프트웨어 버전으로서 'v1'을 정의하는 경우, 이를 SyncML 형식으로 나타내면 다음과 같다.

<Item>

<Source><LocURI> ./DevInfo/Em/EmV </LocURI><Source>

<Meta>

<Type xmlns=""syncml:metinf"> text/plain </Type>

</Meta>

</Item>

또한, 전술한 Em 필드(75)의 EmNRT 필드(78)가 긴급 업데이트 알림 수신 시간으로서 '2022년10월17일 00시00분00초'를 정의하는 경우, 이를 SyncML 형식으로 나타내면 다음과 같다.

<Item>

<Source><LocURI> ./DevInfo/Em/EmNRT </LocURI><Source>

<Meta>

<Type xmlns=""syncml:metinf"> text/plain </Type>

</Meta>

</Item>

본 실시예에 의하면, OMA-DM 표준에서 자율주행차량의 기기 상태 정보를 동기화하는 DevInfo 항목을 확장시켜 정의함으로써, 자율주행차량의 OTA 업데이트시 충분한 차량 정보 동기화를 위한 DevInfo 노드를 제공할 수 있고, 긴급 업데이트 발생 시 DM 서버가 다수의 클라이언트에 긴급 알림 정보를 빠르게 전파할 수 있다.

도 7은 도 6의 확장 DevInfo를 이용하는 업데이트 알림 배포 방법을 설명하기 위한 흐름도이다.

도 7을 참조하면, 업데이트 알림 배포 방법은 자율주행차량의 DM 클라이언트(client)(200)과 DM 서버(server)(100) 간의 패키지 송수신과, DM 서버(100) 및 DM 클라이언트(200) 각각의 동작에 의해 구현될 수 있다.

DM 클라이언트(200)를 중심으로 업데이트 알림 배포 방법을 설명하면, DM 클라이언트(200)는 먼저 차량기기정보(DevInfo)를 포함한 패키지#1을 생성할 수 있다. 여기서, 차량기기정보(DevInfo)는 간략히 기기정보 또는 DevInfo로 지칭될 수 있다.

다음, DM 클라이언트(200)는 차량기기정보(DevInfo)를 포함한 패키지#1을 DM 서버(100)로 전송할 수 있다(S71). 패키지#1은 알림 1201, 대체 최종(Alert 1201, replace final) 메시지를 포함할 수 있다.

본 실시예에서 차량기기정보(DevInfo)는 차량 등록 지역에 대한 정보를 정의하는 필드(VeLoc 필드), 차량 연식에 대한 정보를 정의하는 필드(VeYear 필드), 소프트웨어 확장을 정의하는 필드(SW 필드)에 대한 정보를 포함할 수 있다. 또한, 차량기기정보(DevInfo)는 [표 1]에 열거한 필드들을 구비할 수 있고, 이러한 DevInfo는 자율주행차량 등의 차량의 DM 클라이언트(200)가 보유한 소프트웨어의 업데이트 상태를 DM 서버(100)에서 확인하는데 이용될 수 있다.

다음, DM 클라이언트(200)는 DM 서버(100)로부터 패키지#2를 수신할 수 있다(S72). 패키지#2는 기본적으로 DM 서버(100)로부터 DM 클라이언트(200)으로 전송되는 초기화를 위한 패키지이다. 패키지#2는 SyncHdr 엘리먼트의 상태, 알림(Alert)과 대체(replace) 엘리먼트, 명령(commands) 엘리먼트, 최종(finals) 엘리먼트에 대한 상태 정보를 포함할 수 있다.

여기서, DM 클라이언트(200)는 DM 서버(100)로부터 패키지#2를 통해 업데이트가 필요한 소프트웨어 파일만을 수신할 수 있다.

다음, DM 클라이언트(200)는 수신한 소프트웨어 파일을 이용하여 업데이트가 필요한 소프트웨어 파일만을 업데이트할 수 있다.

도 8은 본 발명의 다른 실시예에 따른 업데이트 알림 배포 방법을 설명하기 위한 순서도이다.

도 8을 참조하면, 업데이트 알림 배포 방법은, DM 서버에 의해 수행되는 방법으로서, 차량의 DM 클라이언트(client)로부터 차량기기정보를 포함한 패키지#1(package#1)을 수신할 수 있다(S81). 차량기기정보는 OMA-DM 표준에서 정의하고 있는 기기정보(device information, DevInfo)로서 본 실시예에서 새롭게 제안되는 확장 DevInfo를 지칭할 수 있다. 본 실시예에서 차량기기정보는 간략히 기기정보 또는 DevInfo로 지칭될 수 있다.

다음, DM 서버는 DevInfo 내 정보를 확인하여 DM 클라이언트가 보유한 소프트웨어(software, SW)의 업데이트 상태를 확인할 수 있다(S83). DevInfo는 차량 등록 지역에 대한 정보를 정의하는 필드(VeLoc 필드), 차량 연식에 대한 정보를 정의하는 필드(VeYear 필드), 소프트웨어 확장을 정의하는 필드(SW 필드) 등을 포함할 수 있다. 그리고, SW 필드는, 대상 소프트웨어 식별자를 정의하는 필드(SwID 필드), 대상 소프트웨어 현재 버전을 정의하는 필드(SwV 필드), 가장 마지막에 다운로드한 소프트웨어 버전을 정의하는 필드(LastV 필드), 및 마지막 업데이트 날짜를 정의하는 필드(LastUpdate 필드)를 포함할 수 있다.

다음, DM 서버는 DevInfo 내 정보를 통해 확인된 차량 예컨대, 자율주행차량의 소프트웨어 업데이트 상태에 따라 추가로 업데이트가 필요한 소프트웨어에 대한 업데이트용 소프트웨어 파일만을 추출하고 추출한 소프트웨어 파일을 DM 클라이언트로 전송할 수 있다(S85).

도 9는 도 8의 확인 과정에 채용할 수 있는 상세 과정에 대한 흐름도이다.

도 9를 참조하면, DM 서버는, DevInfo 내 정보에 기초하여 DM 클라이언트가 보유한 소프트웨어의 업데이트 상태를 확인한 후, DM 서버(server)에 저장되거나 보유하고 있는 소프트웨어(SW) 최신 버전과 차량의 소프트웨어 설치 버전인 DevInfo의 SwV 필드 내 대상 소프트웨어 현재 버전과 비교할 수 있다(S91).

다음, 위의 비교 단계(S91)에서의 비교 결과, DM 서버가 보유한 소프트웨어 최신 버전과 대상 소프트웨어 현재 버전이 동일하지 않은 경우(S93의 No), DM 서버는, DM 서버가 보유한 소프트웨어 최신 버전과 DevInfo의 LastV 필드 내 가장 마지막에 다운로드한 소프트웨어 버전을 비교 검증할 수 있다(S95).

한편, 위의 비교 단계(S91)에서의 비교 결과, DM 서버가 보유한 소프트웨어 최신 버전과 대상 소프트웨어 현재 버전이 동일한 경우(S93의 Yes), DM 서버는, DevInfo 내 정보를 통해 확인된 차량 예컨대, 자율주행차량의 소프트웨어 업데이트 상태에 따라 추가로 업데이트가 필요한 소프트웨어에 대한 업데이트용 소프트웨어 파일만을 추출하고 추출한 소프트웨어 파일을 DM 클라이언트로 전송할 수 있다(도 8의 S85 참조).

다음, DM 서버는, 위의 비교 검증 단계(S95)에서의 비교 검증 결과, DM 서버가 보유한 소프트웨어 최신 버전과 DevInfo의 LastV 필드 내 가장 마지막에 다운로드한 소프트웨어 버전이 다른 경우, DM 서버는, 대상 소프트웨어에 대하여 DM 서버가 보유한 소프트웨어 최신 버전의 소프트웨어를 추출하여 DM 클라이언트로 전송할 수 있다.

한편, 위의 비교 검증 단계(S95)에서의 비교 검증 결과, DM 서버가 보유한 소프트웨어 최신 버전과 DevInfo의 LastV 필드 내 가장 마지막에 다운로드한 소프트웨어 버전이 동일한 경우, DM 서버는, 대상 소프트웨어가 정상적으로 혹은 최신 버전인 것으로 확인하고 본 프로세스를 종료할 수 있다.

본 실시예의 업데이트 알림 배포 방법의 적용 과정을 예를 들어 설명하면, 자율주행차량의 DM 클라이언트가 제1 SW, 제2 SW 및 제3 SW를 보유하고, 제1 SW의 현재 버전(SwV)이 v1이고 제1 SW의 가장 마지막에 다운로드한 소프트웨어 버전(LastV)이 v1이며, 제2 SW의 현재 버전이 v1이고 제2 SW의 가장 마지막에 다운로드한 소프트웨어 버전이 v2이며, 제3 SW의 현재 버전이 v2이고 제3 SW의 가장 마지막에 다운로드한 소프트웨어 버전이 v3으로 확인된 경우, 그리고 자체 보유한 최신 소프트웨어 업데이터 버전이 v2인 경우, DM 서버는 제1 SW를 업데이트 하기 위한 업데이트 파일(v2)를 전송하고, 제2 SW에 대한 업데이트 권고를 전송하도록 동작할 수 있다.

도 10은 도 8의 업데이트 알림 배포 방법에서 긴급 업데이트 알림을 수신한 차량이 주변 차량에게 알림 정보를 전달하는 과정을 설명하기 위한 예시도이다. 그리고 도 11은 본 발명의 또 다른 실시예에 따른 업데이트 알림 배포 방법을 설명하기 위한 순서도이다.

도 11을 참조하면, 차량 예컨대 자율주행차량에 탑재된 DM 클라이언트(client)와 네트워크를 통해 연결되는 DM 서버에 의해 수행되는 업데이트 알림 배포 방법으로서, DM 서버는 DM 클라이언트(client)로부터 기기정보(DevInfo)를 포함한 패키지#1(package#1)을 수신할 수 있다(S1110). 기기정보는 OMA-DM 표준에서 정의하고 있는 기기정보(device information, DevInfo)로서 본 실시예에서 새롭게 제안되는 확장 DevInfo를 가리킬 수 있다. 본 실시예에서 기기정보는 전술한 차량기기정보에 대응되고 간략히 DevInfo로 지칭될 수 있다.

다음, DM 서버는 DevInfo 내 정보를 확인하여 DM 클라이언트가 보유한 소프트웨어(software, SW)의 업데이트 상태를 확인할 수 있다(S1130). DevInfo는 차량 등록 지역에 대한 정보를 정의하는 필드(VeLoc 필드), 차량 연식에 대한 정보를 정의하는 필드(VeYear 필드), 소프트웨어 확장을 정의하는 필드(SW 필드) 등을 포함할 수 있다. 그리고, SW 필드는, 대상 소프트웨어 식별자를 정의하는 필드(SwID 필드), 대상 소프트웨어 현재 버전을 정의하는 필드(SwV 필드), 가장 마지막에 다운로드한 소프트웨어 버전을 정의하는 필드(LastV 필드), 및 마지막 업데이트 날짜를 정의하는 필드(LastUpdate 필드)를 포함할 수 있다.

위의 확인 단계(S1130)에서 DM 서버는 DevInfo 내 정보를 확인하여 DM 클라이언트의 긴급 업데이트 알림 상태를 확인할 수 있다. 이를 위해, DevInfo는 긴급 알림(emergency notification) 확장을 정의하는 필드(Em 필드), 긴급 업데이트 알림 정보를 정의하는 필드(EmN 필드), 서버로 업로드된 긴급 업데이트 소프트웨어 버전을 정의하는 필드(EmV 필드), 긴급 업데이트 알림 수신 시간을 정의하는 필드(EmNRT 필드)를 더 포함할 수 있다.

DM 클라이언트의 긴급 업데이트 알림 상태를 확인하는 과정에서, DM 서버는 DM 서버가 보유한 긴급 업데이트 소프트웨어 최신 버전과 DevInfo 내 EmV 필드의 정보를 비교하거나 확인할 수 있다. 또한, DM 서버는 DevInfo 내 EmN 필드나 EmNRT 필드의 정보를 통해 최신 긴급 업데이트 알림 수신 여부를 확인할 수 있다.

다음, DM 서버는 긴급 업데이트 알림이 필요한 DM 클라이언트에 긴급 알림 정보를 전송할 수 있다(S1150).

다음 DM 서버는 긴급 업데이트가 필요한 소프트웨어(SW)를 위한 소프트웨어 파일만을 포함한 패키지를 DM 클라이언트로 전송하고, DM 클라이언트에서 긴급 업데이트가 필요한 소프트웨어(SW)에 대한 업데이트를 수행하도록 할 수 있다(S1170).

한편, 긴급 업데이트 알림을 받은 DM 클라이언트(200)는 OTA 업데이트를 대기하거나, 온라인을 통해 DM 서버나 DM 서버의 저장소(storage)에 접근하여 긴급 업데이트에 필요한 소프트웨어를 직접 다운로드할 수 있다.

또한, 긴급 업데이트 알림을 받은 DM 클라이언트(200)는 도 10에 예시한 바와 같이 긴급 업데이트 정보를 주변의 차량들의 DM 클라이언트들(201, 202, 203, 204, 205)로 전달할 수 있다(S1190). DM 클라이언트(200)는 V2V(vehicle to vehicle) 통신 기반으로 브로드캐스팅 방식으로 직접 혹은 다른 DM 클라이언트들을 통해 긴급 업데이트 정보를 전파할 수 있다.

전술한 긴급 업데이트 알림 과정을 예를 들어 설명하면, 자율주행차량의 DM 클라이언트가 제1 SW, 제2 SW 및 제3 SW를 보유하고, DM 서버가 자체 보유한 최신 소프트웨어 업데이터 버전이 v2할 때, 제1 SW의 현재 버전(SwV)이 'v1'이고, 제1 SW의 긴급 업데이트 알림 정보(EmN)가 '0'이고, 제1 SW와 관련하여 서버에 업로드된 긴급 소프트웨어 버전(EmV)이 'v1'이며; 제2 SW의 SwV가 'v2'이고, 제2 SW의 EmN이 '1'이고, EmV가 'v2'이고, 제2 SW와 관련하여 가장 마지막에 다운로드한 소프트웨어 버전(LastV)이 'v1'이며; 제3 SW의 SwV가 'v2'이고, 제3 SW의 EmN이 '1'이고, EmV가 'v2'이고, LastV가 'v2'로 확인된 경우, DM 서버는 제1 SW를 긴급 업데이트하기 위한 긴급 업데이트 정보를 DM 클라이언트로 전송하고, 제2 SW와 관련해서는 주변 차량에 긴급 업데이트 정보 전송 및 업데이트를 권고하는 메시지를 DM 클라이언트로 전송하고, 제3 SW와 관련해서는 주변 차량에 긴급 업데이트 정보를 전송하도록 요청하는 알림 메시지를 DM 클라이언트로 전송할 수 있다. 이들 메시지들은 단일 패키지에 포함될 수 있다.

도 12는 본 발명의 또 다른 실시예에 따른 OMA-DM 표준 확장 구조를 이용하는 OTA 기반 차량 긴급 업데이트 알림 배포 장치(간략히 '업데이트 알림 배포 장치')에 채용할 수 있는 구성에 대한 개략도이다.

도 12를 참조하면, 업데이트 알림 배포 장치(1000)는 차량 OTA 업데이트의 효율성 향상을 위한 OMA-DM 프로토콜의 업데이트 알림 배포 방법을 구현하는 적어도 하나의 프로세서(1100)를 포함할 수 있다. 적어도 하나의 프로세서(1100)는 DM 클라이언트에 탑재되거나 DM 서버에 탑재될 수 있다.

또한, 업데이트 알림 배포 장치(1000)는 메모리(1200), 송수신 장치(1300), 입력 인터페이스 장치(1400), 출력 인터페이스 장치(1500), 저장 장치(1600) 또는 이들의 조합 구성을 더 구비할 수 있다. 업데이트 알림 배포 장치(1000)에 포함된 각각의 구성 요소들은 버스(bus, 1700)에 의해 연결되어 서로 통신을 수행할 수 있다.

또한, 업데이트 알림 배포 장치(1000)에 포함된 구성요소들은 공통 버스(1700)가 아니라, 프로세서(1100)를 중심으로 개별 인터페이스 또는 개별 버스를 통하여 연결될 수 있다. 예를 들어, 프로세서(1100)는 메모리(1200), 송수신 장치(1300), 입력 인터페이스 장치(1140), 출력 인터페이스 장치(1500), 저장 장치(1600) 중의 적어도 하나와 전용 인터페이스를 통하여 연결될 수 있다.

전술한 프로세서(1100)는 중앙 처리 장치(central processing unit, CPU), 그래픽 처리 장치(graphics processing unit, GPU), 또는 본 발명의 실시예들에 따른 방법들이 수행되는 전용의 프로세서를 의미할 수 있다. 그리고 메모리(1200) 및 저장 장치(1600) 각각은 휘발성 저장 매체 및 비휘발성 저장 매체 중에서 적어도 하나로 구성될 수 있다. 예를 들어, 메모리(1200)는 읽기 전용 메모리(read only memory, ROM) 및 랜덤 액세스 메모리(random access memory, RAM) 중에서 적어도 하나로 구성될 수 있다.

송수신 장치(1300)는 네트워크를 통해 DM 서버와 신호 및 데이터를 주고받는 통신을 지원하거나, 네트워크를 통해 DM 클라이언트와 신호 및 데이터를 주고받은 통신을 지원하기 위한 서브통신시스템을 포함할 수 있다. 서브통신시스템은 무선 통신 방식을 지원하거나 무선과 유선 통신 방식이 혼합된 하이브리드 통신 방식을 지원하도록 구성될 수 있다.

여기서, 네트워크는 D2D(device to device) 통신, 사이드링크(sidelink) 통신, NR(new radio) V2X(vehicular to everything) 통신 등을 지원하는 네트워크를 포함할 수 있다. 또한, 네트워크는 코어 네트워크나 에지 네트워크 상의 DM 서버 또는 DM 서버를 포함하는 특정 서비스 서버와 이동 통신망, 무선 통신망, 위성망 또는 이들의 조합을 통해 연결되는 DM 클라이언트 또는 DM 클라이언트가 탑재된 차량 간에 형성가능한 모든 통신망을 포함할 수 있다. 차량은 자율주행차량을 포함할 수 있다.

입력 인터페이스 장치(1400)는 키보드, 마이크, 터치패드, 터치스크린, 원격 제어 수단 등에서 선택되는 적어도 하나의 입력 수단과, 적어도 하나의 입력 수단을 통해 입력되는 신호를 기저장된 명령과 매핑하거나 처리하는 입력 신호 처리부를 포함할 수 있다.

출력 인터페이스 장치(1500)는 프로세서(1100)의 제어에 따라 출력되는 신호를 기저장된 신호 형태나 레벨로 매핑하거나 처리하는 출력 신호 처리부와, 출력 신호 처리부의 신호에 따라 진동, 빛, 소리, 열 등의 형태로 신호나 정보를 출력하는 적어도 하나의 출력 수단을 포함할 수 있다. 적어도 하나의 출력 수단은 스피커, 디스플레이 장치, 프린터, 광 출력 장치, 진동 출력 장치 등의 출력 수단들에서 선택되는 적어도 하나를 포함할 수 있다.

전술한 프로세서(1100)는 메모리(1200) 및 저장 장치(1600) 중에서 적어도 하나에 저장된 프로그램 명령(program command)이나 프로그램 명령을 가진 소프트웨어 모듈을 실행할 수 있다. 즉, 프로세서(1100)가 실행될 때, 프로그램 명령에 의해 프로세서(1100)는, 도 7 내지 도 9, 및 도 11 중 어느 하나에 도시한 바와 같은 업데이트 알림 배포 방법을 수행할 수 있다.

본 실시예에 의하면, DevInfo 포맷에 대한 데이터 포맷을 기반으로 자율주행차량 등의 차량에 탑재된 DM 클라이언트의 각 소프트웨어 업데이트 상태를 확인하고, 업데이트가 필요한 소프트웨어를 위한 소프트웨어 파일만 선택적으로 DM 클라이언트로 전송할 수 있고, 그에 의해 데이터 용량 및 통신 비용을 절감할 수 있으며, 아울러 전체 소프트웨어를 업데이트하는 경우에 비해 업데이트에 필요한 지연 시간을 크게 감소시킬 수 있고, OTA 업데이트의 효율성을 크게 향상시킬 수 있다.

또한, 본 실시예에 의하면, DevInfo 포맷에 대한 데이터 포맷을 기반으로 자율주행차량 등의 차량에 대한 긴급 업데이트 알림 정보를 대상 차량이나 주변 차량들로 배포하는 방안을 제공할 수 있다. 그리고, 긴급 업데이트 정보를 수신한 차량을 긴급 업데이트 알림 정보의 확산 매개체로 활용할 수 있다.

한편, 전술한 차량 긴급 업데이트 알림 배포 방법은 간략히 차량 업데이트 알림 방법이나 업데이트 알림 배포 방법으로 지칭될 수 있다. 이와 유사하게, 전술한 차량 긴급 업데이트 알림 배포 장치는 차량 업데이트 알림 장치나 업데이트 알림 배포 장치로 지칭될 수 있다.

본 발명의 실시예에 따른 방법의 동작은 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 프로그램 또는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의해 읽혀질 수 있는 정보가 저장되는 모든 종류의 기록장치를 포함한다. 또한 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어 분산 방식으로 컴퓨터로 읽을 수 있는 프로그램 또는 코드가 저장되고 실행될 수 있다.

또한, 컴퓨터가 읽을 수 있는 기록매체는 롬(rom), 램(ram), 플래시 메모리(flash memory) 등과 같이 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치를 포함할 수 있다. 프로그램 명령은 컴파일러(compiler)에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터(interpreter) 등을 사용해서 컴퓨터에 의해 실행될 수 있는 고급 언어 코드를 포함할 수 있다.

본 발명의 일부 측면들은 장치의 문맥에서 설명되었으나, 그것은 상응하는 방법에 따른 설명 또한 나타낼 수 있고, 여기서 블록 또는 장치는 방법 단계 또는 방법 단계의 특징에 상응한다. 유사하게, 방법의 문맥에서 설명된 측면들은 또한 상응하는 블록 또는 아이템 또는 상응하는 장치의 특징으로 나타낼 수 있다. 방법 단계들의 몇몇 또는 전부는 예를 들어, 마이크로프로세서, 프로그램 가능한 컴퓨터 또는 전자 회로와 같은 하드웨어 장치에 의해(또는 이용하여) 수행될 수 있다. 몇몇의 실시 예에서, 가장 중요한 방법 단계들의 적어도 하나 이상은 이와 같은 장치에 의해 수행될 수 있다.

실시 예들에서, 프로그램 가능한 로직 장치(예를 들어, 필드 프로그래머블 게이트 어레이)가 여기서 설명된 방법들의 기능의 일부 또는 전부를 수행하기 위해 사용될 수 있다. 실시 예들에서, 필드 프로그래머블 게이트 어레이(field-programmable gate array)는 여기서 설명된 방법들 중 하나를 수행하기 위한 마이크로프로세서(microprocessor)와 함께 작동할 수 있다. 일반적으로, 방법들은 어떤 하드웨어 장치에 의해 수행되는 것이 바람직하다.

이상 본 발명의 바람직한 실시 예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

Claims

OMA(open mobile alliance)-DM(device management) 표준 확장 포맷을 이용하는 OTA(over-the air) 기반 차량 긴급 업데이트 알림 배포 방법으로서,
DM 서버가, 차량의 클라이언트로부터 기기정보(device information, DevInfo)를 포함한 패키지(패키지#1)를 수신하는 단계-상기 DevInfo는 소프트웨어(software, SW) 확장을 정의하는 필드(SW 필드)와 긴급 알림 확장을 정의하는 필드(Em 필드)를 포함하고, 상기 SW 필드는 상기 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전에 대한 정보를 정의하는 서브필드를 구비하고, 상기 Em 필드는 긴급 업데이트 알림 정보, 서버에 업로드된 긴급 업데이트 소프트웨어 버전 및 긴급 업데이트 알림 수신 시간을 포함함-;
상기 DM 서버가, 자체 보유한 긴급 소프트웨어 업데이터 버전과, 상기 DevInfo에 포함된 대상 소프트웨어 현재 버전, 긴급 업데이트 알림 정보, 서버로 업로드된 긴급 업데이트 소프트웨어 버전, 및 긴급 업데이트 알림 수신 시간에 기초하여, 상기 클라이언트의 긴급 업데이트 알림 상태를 확인하는 단계; 및
상기 DM 서버가, 상기 클라이언트로 패키지(패키지#2)를 전송하는 단계-상기 패키지#2는 DM 서버로부터 상기 클라이언트로 전송되는 초기화를 위한 패키지이고, SyncML(synchronization markup language) 메시지를 포함할 때, SyncML의 싱크헤더(SyncHdr) 엘리먼트의 상태, 알림(Alert)과 대체(replace) 엘리먼트, 명령(commands) 엘리먼트, 최종(finals) 엘리먼트에 대한 상태 정보를 포함하며, 여기서, 상기 클라이언트는 상기 DM 서버로부터 상기 패키지#2를 통해 업데이트가 필요한 소프트웨어 파일만을 수신함-;
를 포함하며,
상기 클라이언트는 수신한 소프트웨어 파일을 이용하여 업데이트가 필요한 소프트웨어만을 업데이트하는, 차량 긴급 업데이트 알림 배포 방법.
청구항 1에 있어서,
상기 긴급 업데이트 알림 정보가 기본 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전에 비해 상기 긴급 소프트웨어 업데이트 버전이 최신 버전일 때, 긴급 업데이트 정보를 상기 클라이언트로 전송하는 단계를 더 포함하는, 차량 긴급 업데이트 알림 배포 방법.
청구항 1에 있어서,
상기 긴급 업데이트 알림 정보가 긴급 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전이 상기 긴급 소프트웨어 업데이트 버전과 동일하며, 상기 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전이 긴급 소프트웨어 업데이트 버전에 비해 이전 버전일 때, 상기 클라이언트의 주변 차량으로 긴급 업데이트 정보 전송과 업데이트를 권고하는 메시지를 상기 클라이언트로 전송하는 단계를 더 포함하는, 차량 긴급 업데이트 알림 배포 방법.
청구항 1에 있어서,
상기 긴급 업데이트 알림 정보가 긴급 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전 및 상기 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전이 상기 긴급 소프트웨어 업데이트 버전과 동일할 때, 상기 클라이언트의 주변 차량으로 긴급 업데이트 정보 전송을 요청하는 메시지를 상기 클라이언트로 전송하는 단계를 더 포함하는, 차량 긴급 업데이트 알림 배포 방법.
청구항 1에 있어서,
상기 DevInfo는 Ext 필드, Bearer 필드, VeID 필드, VeMan 필드, VeMod 필드, VeLoc 필드, VeYear 필드, DmV 필드, Lang 필드, SwID 필드, SwV 필드, LastV 필드, LastUpdate 필드, EmN 필드, EmV 필드 및 EmNRT 필드를 포함하는, 차량 긴급 업데이트 알림 배포 방법.
OMA(open mobile alliance)-DM(device management) 표준 확장 포맷을 이용하는 OTA(over-the air) 기반 차량 긴급 업데이트 알림 배포 방법으로서,
차량의 클라이언트가, 기기정보(DevInfo)를 포함한 패키지(패키지#1)를 생성하는 단계-상기 DevInfo는 소프트웨어(software, SW) 확장을 정의하는 필드(SW 필드)와 긴급 알림 확장을 정의하는 필드(Em 필드)를 포함하고, 상기 SW 필드는 상기 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전에 대한 정보를 정의하는 서브필드를 구비하고, 상기 Em 필드는 긴급 업데이트 알림 정보, 서버에 업로드된 긴급 업데이트 소프트웨어 버전 및 긴급 업데이트 알림 수신 시간을 포함함-;
상기 차량의 클라이언트가, 상기 패키지(패키지#1)를 서버로 전송하는 단계-상기 서버는, 자체 보유한 긴급 소프트웨어 업데이터 버전과, 상기 DevInfo에 포함된 대상 소프트웨어 현재 버전, 긴급 업데이트 알림 정보, 서버로 업로드된 긴급 업데이트 소프트웨어 버전, 및 긴급 업데이트 알림 수신 시간에 기초하여, 클라이언트의 긴급 업데이트 알림 상태를 확인함-; 및
상기 서버로부터 상기 긴급 업데이트 알림 상태에 따른 긴급 업데이트 정보를 포함한 패키지(패키지#2)를 수신하는 단계-상기 패키지#2는 DM 서버로부터 상기 클라이언트로 전송되는 초기화를 위한 패키지이고, SyncML(synchronization markup language) 메시지를 포함할 때, SyncML의 싱크헤더(SyncHdr) 엘리먼트의 상태, 알림(Alert)과 대체(replace) 엘리먼트, 명령(commands) 엘리먼트, 최종(finals) 엘리먼트에 대한 상태 정보를 포함함-;
를 포함하며,
상기 클라이언트는, 상기 DM 서버로부터 상기 패키지#2를 통해 업데이트가 필요한 소프트웨어 파일만을 수신하고, 수신한 소프트웨어 파일을 이용하여 업데이트가 필요한 소프트웨어만을 업데이트하는, 차량 긴급 업데이트 알림 배포 방법.
청구항 6에 있어서,
상기 긴급 업데이트 정보를 수신하는 단계는, 상기 DevInfo 내 상기 긴급 업데이트 알림 정보가 기본 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전에 비해 상기 긴급 소프트웨어 업데이트 버전이 최신 버전일 때, 수행되는, 차량 긴급 업데이트 알림 배포 방법.
청구항 6에 있어서,
상기 긴급 업데이트 정보를 수신하는 단계는, 상기 DevInfo 내 상기 긴급 업데이트 알림 정보가 긴급 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전이 상기 긴급 소프트웨어 업데이트 버전과 동일하며, 상기 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전이 긴급 소프트웨어 업데이트 버전에 비해 이전 버전일 때, 상기 클라이언트의 주변 차량으로 긴급 업데이트 정보 전송과 업데이트를 권고하는 메시지를 수신하는, 차량 긴급 업데이트 알림 배포 방법.
청구항 8에 있어서,
상기 긴급 업데이트 정보를 주변 차량으로 V2V(vehicle to vehicle) 통신 기반으로 브로드캐스팅하는 단계를 더 포함하는, 차량 긴급 업데이트 알림 배포 방법.
청구항 6에 있어서,
상기 긴급 업데이트 정보를 수신하는 단계는, 상기 DevInfo 내 상기 긴급 업데이트 알림 정보가 긴급 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전 및 상기 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전이 상기 긴급 소프트웨어 업데이트 버전과 동일할 때, 상기 클라이언트의 주변 차량으로 긴급 업데이트 정보 전송을 요청하는 메시지를 수신하는, 차량 긴급 업데이트 알림 배포 방법.
OMA(open mobile alliance)-DM(device management) 표준 확장 포맷을 이용하는 OTA(over-the air) 기반 차량 긴급 업데이트 알림 배포 장치로서,
차량의 클라이언트로부터 기기정보(device information, DevInfo)를 포함한 패키지를 수신하는 송수신 장치-상기 DevInfo는 소프트웨어(software, SW) 확장을 정의하는 필드(SW 필드)와 긴급 알림 확장을 정의하는 필드(Em 필드)를 포함하고, 상기 SW 필드는 상기 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전에 대한 정보를 정의하는 서브필드를 구비하고, 상기 Em 필드는 긴급 업데이트 알림 정보, 서버에 업로드된 긴급 업데이트 소프트웨어 버전 및 긴급 업데이트 알림 수신 시간을 포함함-; 및
자체 보유한 긴급 소프트웨어 업데이터 버전과, 상기 DevInfo에 포함된 대상 소프트웨어 현재 버전, 긴급 업데이트 알림 정보, 서버로 업로드된 긴급 업데이트 소프트웨어 버전, 및 긴급 업데이트 알림 수신 시간에 기초하여, 상기 클라이언트의 긴급 업데이트 알림 상태를 확인하는 프로세서;
를 포함하고,
상기 프로세서는 상기 송수신 장치를 통해 상기 클라이언트로 패키지(패키지#2)를 전송하며, 여기서 상기 패키지#2는 DM 서버로부터 상기 클라이언트로 전송되는 초기화를 위한 패키지이고, SyncML(synchronization markup language) 메시지를 포함할 때, SyncML의 싱크헤더(SyncHdr) 엘리먼트의 상태, 알림(Alert)과 대체(replace) 엘리먼트, 명령(commands) 엘리먼트, 최종(finals) 엘리먼트에 대한 상태 정보를 포함하고,
상기 클라이언트는 상기 프로세서로부터 상기 패키지#2를 통해 업데이트가 필요한 소프트웨어 파일만을 받고, 받은 소프트웨어 파일을 이용하여 업데이트가 필요한 소프트웨어만을 업데이트하는, 차량 긴급 업데이트 알림 배포 장치.
청구항 11에 있어서,
상기 프로세서는, 상기 긴급 업데이트 알림 정보가 기본 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전에 비해 상기 긴급 소프트웨어 업데이트 버전이 최신 버전일 때, 긴급 업데이트 정보를 상기 클라이언트로 전송하는, 차량 긴급 업데이트 알림 배포 장치.
청구항 11에 있어서,
상기 프로세서는, 상기 긴급 업데이트 알림 정보가 긴급 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전이 상기 긴급 소프트웨어 업데이트 버전과 동일하며, 상기 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전이 긴급 소프트웨어 업데이트 버전에 비해 이전 버전일 때, 상기 클라이언트의 주변 차량으로 긴급 업데이트 정보 전송과 업데이트를 권고하는 메시지를 상기 클라이언트로 전송하는, 차량 긴급 업데이트 알림 배포 장치.
청구항 11에 있어서,
상기 프로세서는, 상기 긴급 업데이트 알림 정보가 긴급 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전 및 상기 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전이 상기 긴급 소프트웨어 업데이트 버전과 동일할 때, 상기 클라이언트의 주변 차량으로 긴급 업데이트 정보 전송을 요청하는 메시지를 상기 클라이언트로 전송하는, 차량 긴급 업데이트 알림 배포 장치.
청구항 11에 있어서,
상기 DevInfo는 Ext 필드, Bearer 필드, VeID 필드, VeMan 필드, VeMod 필드, VeLoc 필드, VeYear 필드, DmV 필드, Lang 필드, SwID 필드, SwV 필드, LastV 필드, LastUpdate 필드, EmN 필드, EmV 필드 및 EmNRT 필드를 포함하는, 차량 긴급 업데이트 알림 배포 장치.
OMA(open mobile alliance)-DM(device management) 표준 확장 포맷을 이용하는 OTA(over-the air) 기반 차량 긴급 업데이트 알림 배포 장치로서,
기기정보(DevInfo)를 포함한 패키지(패키지#1)를 생성하는 프로세서-상기 DevInfo는 소프트웨어(software, SW) 확장을 정의하는 필드(SW 필드)와 긴급 알림 확장을 정의하는 필드(Em 필드)를 포함하고, 상기 SW 필드는 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전에 대한 정보를 정의하는 서브필드를 구비하고, 상기 Em 필드는 긴급 업데이트 알림 정보, 서버에 업로드된 긴급 업데이트 소프트웨어 버전 및 긴급 업데이트 알림 수신 시간을 포함함-; 및
상기 패키지(패키지#1)를 서버로 전송하고, 상기 서버로부터 긴급 업데이트 알림 상태에 따른 긴급 업데이트 정보를 포함한 패키지(패키지#2)를 수신하는 송수신 장치;
를 포함하고,
상기 서버가 자체 보유한 긴급 소프트웨어 업데이터 버전과, 상기 DevInfo에 포함된 대상 소프트웨어 현재 버전, 긴급 업데이트 알림 정보, 서버로 업로드된 긴급 업데이트 소프트웨어 버전, 및 긴급 업데이트 알림 수신 시간에 기초하여, 상기 클라이언트의 상기 긴급 업데이트 알림 상태가 상기 서버에서 확인되며,
상기 패키지#2는 DM 서버로부터 상기 클라이언트로 전송되는 초기화를 위한 패키지이고, SyncML(synchronization markup language) 메시지를 포함할 때, SyncML의 싱크헤더(SyncHdr) 엘리먼트의 상태, 알림(Alert)과 대체(replace) 엘리먼트, 명령(commands) 엘리먼트, 최종(finals) 엘리먼트에 대한 상태 정보를 포함하고,
상기 클라이언트는 상기 프로세서를 구비한 DM 서버로부터 상기 패키지#2를 통해 업데이트가 필요한 소프트웨어 파일만을 수신하고, 수신한 소프트웨어 파일을 이용하여 업데이트가 필요한 소프트웨어만을 업데이트하는, 차량 긴급 업데이트 알림 배포 장치.
청구항 16에 있어서,
상기 프로세서는, 상기 DevInfo 내 상기 긴급 업데이트 알림 정보가 기본 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전에 비해 상기 긴급 소프트웨어 업데이트 버전이 최신 버전일 때, 상기 서버로부터 상기 송수신 장치를 통해 상기 긴급 업데이트 정보를 수신하는, 차량 긴급 업데이트 알림 배포 장치.
청구항 16에 있어서,
상기 프로세서는, 상기 DevInfo 내 상기 긴급 업데이트 알림 정보가 긴급 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전이 상기 긴급 소프트웨어 업데이트 버전과 동일하며, 상기 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전이 긴급 소프트웨어 업데이트 버전에 비해 이전 버전일 때, 상기 송수신 장치를 통해 상기 클라이언트의 주변 차량으로 긴급 업데이트 정보 전송과 업데이트를 권고하는 메시지를 상기 서버로부터 수신하는, 차량 긴급 업데이트 알림 배포 장치.
청구항 18에 있어서,
상기 프로세서는, 상기 송수신 장치를 통해 상기 긴급 업데이트 정보를 주변 차량으로 V2V(vehicle to vehicle) 통신 기반으로 브로드캐스팅하는, 차량 긴급 업데이트 알림 배포 장치.
청구항 16에 있어서,
상기 프로세서는, 상기 DevInfo 내 상기 긴급 업데이트 알림 정보가 긴급 상태이고, 상기 대상 소프트웨어 현재 버전과 상기 긴급 업데이트 소프트웨어 버전 및 상기 클라이언트가 가장 마지막에 다운로드한 소프트웨어 버전이 상기 긴급 소프트웨어 업데이트 버전과 동일할 때, 상기 클라이언트의 주변 차량으로 긴급 업데이트 정보 전송을 요청하는 메시지를 상기 서버로부터 수신하는, 차량 긴급 업데이트 알림 배포 장치.