KR101966626B1 - 차량용 무선 소프트웨어 업데이트 방법 및 장치 - Google Patents

차량용 무선 소프트웨어 업데이트 방법 및 장치 Download PDF

Info

Publication number
KR101966626B1
KR101966626B1 KR1020170018667A KR20170018667A KR101966626B1 KR 101966626 B1 KR101966626 B1 KR 101966626B1 KR 1020170018667 A KR1020170018667 A KR 1020170018667A KR 20170018667 A KR20170018667 A KR 20170018667A KR 101966626 B1 KR101966626 B1 KR 101966626B1
Authority
KR
South Korea
Prior art keywords
message
update
diagnostic
vehicle
controller
Prior art date
Application number
KR1020170018667A
Other languages
English (en)
Other versions
KR20170094765A (ko
Inventor
박승욱
하재준
정인용
조아람
Original Assignee
현대자동차주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 현대자동차주식회사 filed Critical 현대자동차주식회사
Priority to PCT/KR2017/001509 priority Critical patent/WO2017138787A1/ko
Publication of KR20170094765A publication Critical patent/KR20170094765A/ko
Priority to US16/048,692 priority patent/US10768922B2/en
Application granted granted Critical
Publication of KR101966626B1 publication Critical patent/KR101966626B1/ko
Priority to US16/943,061 priority patent/US11422787B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9566—URL specific, e.g. using aliases, detecting broken or misspelled links
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Abstract

본 발명은 차량용 소프트웨어 업데이트 방법 및 장치에 관한 것으로, 보다 상세히는 보다 효율적으로 차량용 전자 장치의 소프트웨어를 무선으로 업데이트하기 위한 방법 및 장치에 관한 것이다. 본 발명의 일 실시예에 따른 차량용 게이트웨이의 무선 소프트웨어 업데이트 방법은, 적어도 하나의 제어기로부터 소프트웨어 모듈 리스트를 포함하는 제 1 메시지를 수신하는 단계; 및 상기 적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 포함하는 제 2 메시지를 업데이트 서버로 전송하는 단계를 포함하되, 상기 제 1 메시지는 하드웨어 버전 정보를 포함하고, 상기 제 2 메시지는 차량의 지역정보를 포함할 수 있다.

Description

차량용 무선 소프트웨어 업데이트 방법 및 장치{METHOD AND APPARATUS FOR UPDATING SOFTWARE OF ELECTRONIC DEVICES IN A VEHICLE}
본 발명은 차량용 소프트웨어 업데이트 방법 및 장치에 관한 것으로, 보다 상세히는 보다 효율적으로 차량용 전자 장치의 소프트웨어를 무선으로 업데이트하기 위한 방법 및 장치에 관한 것이다.
지능형 운송 시스템(ITS: Intelligent Transportation System)이 발전하고, 무선 통신(예를 들어, WiFi, 3G, LTE 등)이 가능한 차량의 비율이 증가함에 따라, 차량에서 다른 차량이나 인프라와 같은 외부 개체와의 통신도 보편화되고 있다.
또한, 차량에 전자 제어기(ECU: Electronic Control Units)의 숫자도 증가하고 있는 추세이다. 이러한 전자 제어기의 구조 및 기능이 점점 복잡해짐에 따라, 해당 전자 제어기 내부의 소프트웨어 모듈 또한 버그 픽스, 성능 향상, 보안성 향상 등의 이유로 업데이트될 필요가 있다.
일반적으로 전자 제어기 내부의 소프트웨어 모듈의 업데이트는 차량과 진단기 간의 유선 연결을 통한 진단 통신을 이용하나, 진단 통신의 속도가 느리고 업데이트가 필요할 때마다 정비소 등 진단기 장비가 구비된 장소에 방문해야 하는 불편함이 있다.
본 발명은 보다 효율적으로 차량용 전자 제어기의 소프트웨어 업데이트를 무선으로 수행할 수 있는 방법 및 장치를 제공하기 위한 것이다.
특히, 본 발명은 무선 소프트웨어 업데이트를 위한 절차와, 절차 내에서 사용될 수 있는 메시지 포맷을 제공하기 위한 것이다.
본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
상기와 같은 기술적 과제를 해결하기 위하여, 본 발명의 일 실시예에 따른 차량용 게이트웨이의 무선 소프트웨어 업데이트 방법은, 적어도 하나의 제어기로부터 소프트웨어 모듈 리스트를 포함하는 제 1 메시지를 수신하는 단계; 및 상기 적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 포함하는 제 2 메시지를 업데이트 서버로 전송하는 단계를 포함하되, 상기 제 1 메시지는 하드웨어 버전 정보를 포함하고, 상기 제 2 메시지는 차량의 지역정보를 포함할 수 있다.
또한, 본 발명의 일 실시예에 따른 무선 소프트웨어 업데이트를 수행하는 차량용 게이트웨이는, 적어도 하나의 제어기와 통신하는 유선 통신 모듈; 업데이트 서버와 통신하는 무선 통신 모듈; 및 상기 유선 통신 모듈을 통해 상기 적어도 하나의 제어기로부터 소프트웨어 모듈 리스트를 포함하는 제 1 메시지를 수신하고, 상기 적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 포함하는 제 2 메시지가 상기 무선 통신 모듈을 통해 상기 업데이트 서버로 전송되도록 제어하는 프로세서를 포함하되, 상기 제 1 메시지는 하드웨어 버전 정보를 포함하고, 상기 제 2 메시지는 차량의 지역정보를 포함할 수 있다.
아울러, 본 발명의 일 실시예에 따른 무선 소프트웨어 업데이트를 수행하는 차량은, 적어도 하나의 제어기; 및 상기 적어도 하나의 제어기로부터 소프트웨어 모듈 리스트를 포함하는 제 1 메시지를 수신하고, 상기 적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 포함하는 제 2 메시지를 업데이트 서버로 전송하는 게이트웨이를 포함하되, 상기 제 1 메시지는 하드웨어 버전 정보를 포함하고, 상기 제 2 메시지는 차량의 지역정보를 포함할 수 있다.
상기와 같이 구성되는 본 발명의 적어도 하나의 실시예에 따르면 보다 효율적으로 차량용 전자 제어기의 소프트웨어 업데이트가 무선으로 수행될 수 있다.
또한, 무선 소프트웨어 업데이트 절차 및 해당 절차에서 단계별로 사용되는 메시지의 포맷이 정의될 수 있다. 특히, 소프트웨어 모듈의 하드웨어 버전 정보와 차량의 지역 정보가 관련 메시지에 포함되므로, 보다 정확한 업데이트가 수행될 수 있다.
본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 발명의 일 실시예에 따른 무선 소프트웨어 업데이트 과정의 일례를 나타내는 순서도이다.
도 2는 본 발명의 일 실시예에 따른 세션 및 그에 따른 메시지의 일례를 나타낸 표이다.
도 3은 본 발명의 일 실시예에 따른 업데이트 소프트웨어 전송 과정의 일례를 나타낸다.
도 4는 본 발명의 일 실시예에 따른 진단 요청 메시지 구조의 일례를 나타낸다.
도 5는 본 발명의 일 실시예에 따른 진단 요청 메시지 코딩의 일례를 나타낸다.
도 6은 본 발명의 일 실시예에 따른 진단 보고 메시지 구조의 일례를 나타낸다.
도 7은 본 발명의 일 실시예에 따른 진단 보고 메시지 코딩의 일례를 나타낸다.
도 8은 본 발명의 일 실시예에 따른 진단 제출 메시지 구조의 일례를 나타낸다.
도 9는 본 발명의 일 실시예에 따른 진단 제출 메시지 코딩의 일례를 나타낸다.
도 10은 본 발명의 일 실시예에 따른 진단 영수 메시지 코딩의 일례를 나타낸다.
도 11은 본 발명의 일 실시예에 따른 업데이트 확인 요청 메시지 구조의 일례를 나타낸다.
도 12는 본 발명의 일 실시예에 따른 업데이트 확인 요청 메시지 코딩의 일례를 나타낸다.
도 13은 본 발명의 일 실시예에 따른 업데이트 확인 응답 메시지 구조의 일례를 나타낸다.
도 14는 본 발명의 일 실시예에 따른 업데이트 확인 응답 메시지 코딩의 일례를 나타낸다.
도 15는 본 발명의 일 실시예에 따른 코드베이스 필드를 통해 백업 주소를 제공하는 업데이트 확인 응답 메시지 코딩의 일례를, 도 16은 본 발명의 일 실시예에 따른 코드베이스2 필드를 통해 백업 주소를 제공하는 업데이트 확인 응답 메시지 코딩의 일례를 각각 나타낸다.
도 17은 본 발명의 일 실시예에 따른 업데이트 알림 메시지 코딩의 일례를 나타낸다.
도 18은 본 발명의 일 실시예에 따른 업데이트 알림 메시지 코딩의 다른 일례를 나타낸다.
도 19는 본 발명의 일 실시예에 따른 업데이트 컨펌 메시지 코딩의 일례를 나타낸다.
도 20은 본 발명의 일 실시예에 따른 업데이트 적용 메시지 구조의 일례를 나타낸다.
도 21은 본 발명의 일 실시예에 따른 업데이트 적용 메시지 코딩의 일례를 나타낸다.
도 22는 본 발명의 일 실시예에 따른 업데이트 결과 메시지 구조의 일례를 나타낸다.
도 23은 본 발명의 일 실시예에 따른 업데이트 결과 메시지 코딩의 일례를 나타낸다.
도 24는 본 발명의 일 실시예에 따른 업데이트 보고 제출 메시지 코딩의 일례를 나타낸다.
도 25는 본 발명의 일 실시예에 따른 업데이트 보고 영수 메시지 코딩의 일례를 나타낸다.
아래에서는 첨부한 도면을 참고로 하여 본 발명의 실시 예에 대하여 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 발명은 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다. 그리고 도면에서 본 발명을 명확하게 설명하기 위해서 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.
명세서 전체에서, 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성 요소를 더 포함할 수 있는 것을 의미한다. 또한, 명세서 전체에 걸쳐서 동일한 참조번호로 표시된 부분들은 동일한 구성요소들을 의미한다.
도 1은 본 발명의 일 실시예에 따른 무선 소프트웨어 업데이트 과정의 일례를 나타내는 순서도이다.
도 1을 참조하면, 먼저 소프트웨어 공급자(supplier)가 업데이트 서버(update server)로 업데이트 소프트웨어(업데이트 모듈)를 제공한다(S1). 여기서 소프트웨어 공급자 및 업데이트 서버의 운영주체는 차량 제조사일 수도 있고, 차량에 장착되는 디바이스 또는 그에 포함되는 부품의 제조사일 수 있으나, 본 발명은 이러한 공급자나 서버의 운영주체의 범위에 한정되지 아니한다. 또한, 본 단계는 이하의 과정들의 수행 순서와 반드시 선후 관계를 가지지는 아니한다.
차량 게이트웨이(VMG)는 그에 연결된 각 제어기(ECU)에 소프트웨어 리스트를 요청하기 위해 진단 요청(diagnose (request)) 메시지를 전송한다(S2).
진단 요청 메시지에 대한 응답으로, 각 제어기는 소프트웨어 상태를 체크하고, 소프트웨어 모듈 리스트를 생성하여 이를 게이트웨이로 게이트웨이로 진단 보고(diagnose (report)) 메시지를 통해 전송한다(S3).
그에 따라, 게이트웨이는 해당 차량에 대한 소프트웨어 업데이트가 있는지 여부를 확인하기 위해 각 제어기로부터 획득한 리스트를 업데이트 서버로 진단 제출(diagnose (submit)) 메시지를 통해 전송한다(S4).
업데이트 서버는 게이트웨이가 제출한 리스트에 대한 영수 확인으로, 게이트웨이에 진단 영수(diagnose (receipt)) 메시지를 전송한다(S5).
리스트에 따라, 업데이트 서버는 해당 차량에 설치된 소프트웨어의 상태를 조사하고, 전자 제어기들에 대한 업데이트 필요성을 결정한다(S6).
이러한 조사에는 긴 시간이 소요될 수 있기 때문에, 게이트웨이는 해당 차량에 대한 업데이트 필요성을 주기적으로 확인하기 위해 업데이트 확인 요청(update_check (request)) 메시지를 업데이트 서버로 전송한다(S7).
업데이트가 있는 경우, 업데이트 서버는 업데이트 모듈의 다운로드 위치 정보를 포함하는 업데이트 확인 응답(update_check (response)) 메시지를 게이트웨이로 전송한다(S8).
업데이트가 있는 경우, 게이트웨이는 다운로드 위치 정보로 접속하여 업데이트 모듈을 다운로드할 수 있다(S9).
게이트웨이는 업데이트를 각 제어기에 적용하기 전에, 업데이트 적용을 확인받기 위해 사용자 인터페이스를 통해 운전자에 알릴 수 있다(S10). 이를 위해 업데이트 알림(update (notification)) 메시지가 사용될 수 있다.
운전자가 업데이트 적용을 확인하고 수락하면, 업데이트 컨펌(update (confirm)) 메시지가 게이트웨이로 전송된다(S11).
운전자의 수락에 따라, 게이트웨이는 업데이트 모듈 파일을 해당 제어기로 전송하고, 업데이트를 적용할 것을 요청할 수 있다(S12). 이를 위해 업데이트 적용(update (application)) 메시지가 사용될 수 있다.
그에 따라, 업데이트 모듈 파일을 수신한 각 제어기는 업데이트를 적용하고, 적용 결과를 게이트웨이로 전송한다(S13). 이를 위해 업데이트 결과(updatet (result)) 메시지가 사용될 수 있다.
게이트웨이는 업데이트 적용 결과를 업데이트 보고 제출(update_report (submit)) 메세지를 통해 업데이트 서버로 제출한다(S14).
업데이트 서버는 업데이트 보고 제출 메시지에 대한 응답으로, 업데이트 보고 영수(update_report (receipt)) 메시지를 게이트웨이로 전송한다(S15). 만일, 업데이트의 적용이 실패하거나 남아있는 업데이트가 발견된 경우, 업데이트 서버는 S6 단계부터 S14 단계를 업데이트 적용이 성공할 때까지 반복할 수 있다.
전술한 단계들 중, S2 단계 내지 S5, 및 S7 단계 내지 S8 단계 및 S10단계 내지 S15 단계는 특정 포맷의 메시지 교환을 통해 수행되며, 총 내 개의 세션으로 구분될 수 있다. 이를 정리한 표가 도 2에 도시된다.
도 2는 본 발명의 일 실시예에 따른 세션 및 그에 따른 메시지의 일례를 나타낸 표이다.
도 2를 참조하면, 본 실시예에 따른 업데이트 과정에 사용되는 메시지는 타입과 서브 타입으로 구분될 수 있으며, 타입은 세션에 대응될 수 있다. 보다 상세히, 본 실시예에 따른 세션은 진단(diagnose), 업데이트 확인(update_check), 업데이트(update) 및 업데이트 보고(update_report)로 분류될 수 있다. 하나의 세션은 두 개 이상의 서로 다른 서브 타입을 갖는 메시지 교환을 통해 수행될 수 있으며, 하나의 세션에 해당하는 메시지들은 후술할 세션식별자(sessionid) 필드에 동일한 값을 사용한다.
도 2에서 메시지의 송수신 주체로 기재된 Usvr 및 U/I는 업데이트 서버 및 사용자 인터페이스(user interface)를 각각 나타내며, 각 메시지에 대한 전송단/수신단 및 목적은 전술한 바와 같으므로, 명세서의 간명함을 위해 중복되는 기재는 생략하기로 한다.
한편, 각 단계에서 개체들 간에 교환되는 메시지는 디지털 서명이나 메시지 인증 코드(MAC: Message Authentication Code) 방식 등을 통해 보호될 수 있다. 이러한 방식 외에도, ID/패스워드 인증, 생체 인증(시그니쳐 다이내믹스, 홍채 스캔, 지문 인식, 음성 인식, 얼굴 인식 등), 아웃 오브 밴드 인증(Out-of-band verification) 방법 등도 적용될 수 있다.
다음으로, 각 단계를 상세히 설명하기 앞서, 개체별로 파일 전송이 수행되는 경우 정합성 확인(integrity check) 절차를 도 3을 참조하여 설명한다.
도 3은 본 발명의 일 실시예에 따른 업데이트 소프트웨어 전송 과정의 일례를 나타낸다.
도 3에 도시된 과정은 업데이트 소프트웨어의 전송 과정에서 우발적으로, 또는 공격자의 의도에 따른 소프트웨어 파일 손상(corruption)을 방지하기 위한 것으로, md5와 같은 정합성 확인 방법(integrity checking method)이 사용될 수 있다. 업데이트 소프트웨어의 전송 과정을 송신단(Transmitting End)과 수신단(Receiving End) 관점에서 볼 경우, 송신단이 공급자인 경우 수신단은 업데이트 서버가 되며, 송신단이 업데이트 서버인 경우 수신단은 게이트웨이일 수 있다.
구체적으로, 송신단에서는 업데이트 소프트웨어에 소정의 해시 알고리즘 연산을 적용하여 제 1 해쉬값(HASH value 1)을 생성하고, 이를 업데이트 소프트웨어와 다중화하여 수신단으로 전송한다. 수신단에서는 송신단에서 전송한 파일을 역다중화하여 제 1 해쉬값(HASH value 1) 및 업데이트 소프트웨어를 복원한다. 이후 수신단에서 복원된 업데이트 소프트웨어에 소정의 해시 알고리즘 연산을 적용하여 제 2 해쉬값(HASH value 2)을 생성하고, 이를 제 1 해쉬값과 비교한다. 비교 결과, 두 값이 동일한 경우 수신단은 해당 업데이트 소프트웨어 파일이 정합성 체크를 만족한 것으로 판단하며, 동일하지 않은 경우 정합성 체크에 실패한 것으로 판단하여 송신단에 파일 재전송을 요청할 수 있다.
이하에서 설명하는 메시지들은 복수의 엘레멘트(element)를 포함하는데, 이러한 엘레멘트의 대표적인 예로 차량(vehicle) 엘레멘트와 모듈(module) 엘레멘트를 들 수 있다. 차량 엘레멘트는 차량에 대한 정보를 정의하는 복수의 필드(또는 속성: attribute)로 구성되며, 모듈 엘레멘트는 차량에 포함되는 하나 이상의 디바이스에 포함되는 소프트웨어 모듈 각각에 대한 정보를 정의하는 복수의 필드로 구성된다.
먼저, 모듈 엘레멘트의 구성을 설명한다. 모듈 엘레멘트는 모듈식별자(moduleid) 필드, 버전(version) 필드, 및 다음버전(nextversion) 필드 중 적어도 하나를 포함한다.
모듈식별자 필드는 차량 제조사나 모듈 공급자가 제공하는 모듈의 고유 식별자를 나타낸다. 버전 필드는 해당 소프트웨어 모듈의 버전 정보를, 다음버전 필드는 업데이트가 수행되는 모듈의 버전 정보를 각각 나타내며, 다음버전 필드는 업데이트 수행 중 응답 메시지를 전송하는데 주로 사용될 수 있다.
그런데, 특정 모듈의 업데이트 여부를 보다 정확히 결정하기 위해서는 소프트웨어의 버전뿐만 아니라, 해당 소프트웨어 모듈을 포함하는 하드웨어의 버전 정보도 중요하다. 따라서, 본 실시예에서는 모듈 엘레멘트에 하드웨어의 버전 정보를 나타내는 하드웨어버전(hwversion) 필드를 포함시킬 것을 제안한다.
그에 따른 모듈 엘레멘트의 구성의 일례는 아래 표 1과 같다.
Module - Container of module information, which contains a Hash element.
moduleid Module id is a unique id provided by a car manufacture / a supplier.
version Version of this software module.
hwversion Version of H/W including this software module
nextversion The version of the module update in progress, which is mainly used for sending response message during an update.
실시예에 따라, 하드웨어버전 필드는 후술할 디바이스 엘레멘트에 포함될 수도 있다. 이러한 경우 본 필드의 설명은 본 하드웨어 모듈의 버전(Version of this hardware module)일 수 있다.
다음으로, 차량 엘레멘트는 이름(name) 필드, 모델(model) 필드, 모델식별자(modelid) 필드, 차량식별자(vehicleid) 필드 중 적어도 하나를 포함할 수 있다. 이름 필드는 차량의 이름을, 모델 필드는 차량 제조사가 제공한 차량의 타이프 네임(Type name)을, 모델식별자 필드는 차량의 모델명을, 차량식별자 필드는 차량 제조사에서 정의한 차량의 식별자를 각각 나타낸다.
그런데, 동일 차량이라고 하더라도 지역(특히, 생산지)에 따라 하드웨어나 소프트웨어 모듈의 구성이 상이할 수 있다. 따라서, 업데이트 여부를 보다 정확히 특정하기 위해 본 실시예에서는 차량 엘레멘트에 차량의 지역 정보를 나타내는 지역(locale) 필드를 포함시킬 것을 제안한다.
그에 따른 차량 엘레멘트의 구성의 일례는 아래 표 2와 같다.
Vehicle - Container of vehicle information. It contains multiple Module elements.
name Name of the vehicle, if any.
model Type name of the vehicle provided by the car manufacture.
modelid Model name of the vehicle
vehicleid Vehicle id defined by a car manufacture.
locale Locale information of the vehicle
이하에서는, 전술한 각 단계와, 해당 단계별로 사용되는 메시지의 구조, 내용 및 코딩 포맷을 보다 상세히 설명한다.
진단 요청(S2): diagnose (request)
본 단계는 실질적으로 업데이트 과정의 개시 절차로, 차량 게이트웨이(VMG)는 제어기들에 그들의 소프트웨어 리스트 제출을 요청하게 된다. 이를 위해, 진단 요청 메시지가 사용될 수 있다.
진단 요청 메시지의 구조가 도 4에 도시된다. 도 4는 본 발명의 일 실시예에 따른 진단 요청 메시지 구조의 일례를 나타낸다.
도 4를 참조하면, 진단 요청 메시지는 메시지 엘레멘트, 발행시간(IssuedTime) 엘레멘트 및 만료시간(ExpirationTime) 엘레멘트를 포함할 수 있다.
진단 요청 메시지의 포맷의 일례는 아래 표 3과 같다.
Element
Attribute in Element
Description
Message
 - Container of the message
protocol Always "1.0"
version The version number of the message sender
type Message type (always "diagnose")
subtype Message subtype (always "request")
sessionid Session ID is a random GUID associated with the diagnose session. An identical session ID is applied to a set of diagnose request, report and submit messages.
trustlevel Trustlevel is determined based on security capability and safety requirement of device that generated this message.
messageid Message ID is a random GUID associated with individual message.
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
표 3을 참조하면, 메시지 엘레멘트는 프로토콜(protocol) 필드, 버전(version) 필드, 타입(type) 필드, 서브타입(subtype) 필드, 세션식별자(sessionid) 필드, 신뢰레벨(trustlevel) 필드, 메시지식별자(messageid) 필드 중 적어도 하나를 포함할 수 있다.
프로토콜 필드는 고정된 값(예컨대, 1.0)으로 설정될 수 있으며, 버전 필드는 메지시 전송자의 버전 정보를 나타낸다. 진단 요청 메시지에서, 타입 필드는 항상 "diagnose"로 설정되며, 서브타입 필드는 항상 "request"로 설정될 수 있다. 세션식별자 필드는 진단 세션에 대한 랜덤 GUID(Globally Unique ID)로 설정되며, 하나의 진단 세션에 해당되는 진단 요청, 진단 보고 및 진단 제출 메시지 모두에 동일한 값이 적용된다. 신뢰레벨 필드는 본 메시지를 생성하는 디바이스의 보안 능력과 안전 요구사항에 기반하여 결정된다. 메시지식별자 필드는 개별 메시지에 대한 랜덤 GUID로 설정된다.
발행 시간 엘레멘트는 본 메시지의 생성 시간을 나타내며, 만료시간 엘레멘트는 본 메시지의 만료시간을 나타낸다.
본 메시지에 대한 XML 코딩의 일례는 도 5와 같다. 도 5는 본 발명의 일 실시예에 따른 진단 요청 메시지 코딩의 일례를 나타낸다.
진단 보고(S3): diagnose (report)
진단 요청 메시지에 대한 응답으로, 각 제어기는 자신의 소프트웨어 상태를 체크하고, 소프트웨어 모듈 리스트를 생성하여 게이트웨이로 전송한다. 이를 위해 진단 보고(diagnose (report)) 메시지가 사용될 수 있다.
진단 보고 메시지의 구조가 도 6에 도시된다. 도 6은 본 발명의 일 실시예에 따른 진단 보고 메시지 구조의 일례를 나타낸다.
도 6을 참조하면, 진단 보고 메시지는 전술한 메시지 엘레멘트, 발행시간(IssuedTime) 엘레멘트 및 만료시간(ExpirationTime) 엘레멘트 외에, 적어도 하나의 디바이스 엘레멘트를 포함할 수 있다. 디바이스 엘레멘트는 다시 하나 이상의 모듈 엘레멘트를 포함하며, 각 모듈 엘레멘트는 해쉬 엘레멘트를 포함할 수 있다.
진단 보고 메시지의 포맷의 일례는 아래 표 4와 같다.
Element Attribute in Element Description
Message - Container of the message
protocol Always "1.0"
version The version number of the message sender
type Message type (always "diagnose")
subtype Message subtype (always "report")
sessionid Session ID is a random GUID associated with the diagnose session. An identical session ID is applied to a set of diagnose request, report and submit messages.
trustlevel Trustlevel is determined based on security capability and safety requirement of device that generated this message.
ownerid Owner ID provided by a car manufacture / supplier.
messageid Message ID is a random GUID associated with individual message.
Device - Container of device information. It contains multiple Module elements.
name Name of the device, if any.
type Type name of the device, such as "Power management ECU", "Seat belt control ECU", etc.
model Model name of the device.
deviceid Device id defined by a car manufacture / supplier.
Module
 - Container of module information, which contains a Hash element.
moduleid Module id is a unique id provided by a car manufacture / a supplier.
version Version of this software module.
hwversion Version of H/W including this software module
nextversion The version of the module update in progress, which is mainly used for sending response message during an update.
Hash - Hash is a container of a hash value and information of its hash algorithm.
algorithm Algorithm of the hash function (e.g., SHA-3, SHA-256, etc.)
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
표 4의 설명을 포함한 이하의 기재에서는, 기 설명된 엘레멘트 및 필드에 대한 설명은 생략하기로 하며, 생략된 기재에 대한 설명은 관련 표 및 도면의 참조에 의해 보충될 수 있음은 당업자에 자명하다.
표 4를 참조하면, 진단 요청 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "diagnose"로 설정되며, 서브타입 필드는 항상 "report"로 설정될 수 있다. 또한, 메시지 엘레멘트에는 차량 제조사나 공급자로부터 제공되는 오너 식별자(Owner ID)를 나타내는 오너식별자(ownerid) 필드가 더 포함될 수 있다.
디바이스 엘레멘트는 이름(name) 필드, 타입(type) 필드, 모델(model) 필드 및 디바이스식별자(deviceid) 중 적어도 하나의 필드를 포함할 수 있으며, 실시 예에 따라 표 4와 달리 하드웨어버전 필드를 모듈 엘레멘트 대신 더 포함할 수도 있다. 이름 필드는 디바이스의 이름을, 타입 필드는 "Power management ECU", "Seat belt control ECU" 등 해당 디바이스의 타이프 네임(type name)을 각각 나타낼 수 있다. 또한, 모델 필드는 본 디바이스의 모델명을, 디바이스식별자 필드는 차량 제조사/공급자로부터 정의된 디바이스의 식별자 정보를 각각 나타낸다.
해쉬 엘레멘트는 각 모듈에 대한 해쉬 값과 그에 사용된 해쉬 알고리즘에 대한 정보를 나타낸다.
본 메시지에 대한 XML 코딩의 일례는 도 7과 같다. 도 7은 본 발명의 일 실시예에 따른 진단 보고 메시지 코딩의 일례를 나타낸다.
진단 제출(S4): diagnose (submit)
게이트웨이는 해당 차량에 대한 소프트웨어 업데이트가 있는지 여부를 확인하기 위해 각 제어기로부터 획득한 리스트를 업데이트 서버로 전송한다. 이를 위해 진단 제출(diagnose (submit)) 메시지가 사용될 수 있다.
진단 제출 메시지의 구조가 도 8에 도시된다. 도 8은 본 발명의 일 실시예에 따른 진단 제출 메시지 구조의 일례를 나타낸다.
도 8을 참조하면, 진단 제출 메시지의 구조는 전술한 도 6에 나타난 진단 보고 메시지의 구조와 유사하되, 차량(Vehicle) 엘레멘트를 더 포함한다.
진단 제출 메시지의 포맷의 일례는 아래 표 5와 같다.
Element Attribute in Element Description
Message - Container of the message
protocol Always "1.0"
version The version number of the message sender
type Message type (always "diagnose")
subtype Message subtype (always "submit")
sessionid Session ID is a random GUID associated with the diagnose session. An identical session ID is applied to a set of diagnose request, report and submit messages.
trustlevel Trustlevel is determined based on security capability and safety requirement of device that generated this message.
ownerid Owner ID provided by a car manufacture / supplier.
messageid Message ID is a random GUID associated with individual message.
Vehicle - Container of vehicle information. It contains multiple Module elements.
name Name of the vehicle, if any.
model Type name of the vehicle provided by the car manufacture.
modelid Model name of the vehicle
locale Locale information of the vehicle
modelyear Year of the vehicle manufactured
vehicleid Vehicle id defined by a car manufacture / supplier.
Device - Container of device information. It contains multiple Module elements.
name Name of the device, if any.
type Type name of the device, such as "Power management ECU", "Seat belt control ECU", etc.
model Model name of the device.
deviceid Device id defined by a car manufacture / supplier.
Module - Container of module information, which contains a Hash element.
moduleid Module id is a unique id provided by a car manufacture / a supplier.
version Version of this software module.
hwversion Version of H/W including this software module
nextversion The version of the module update in progress, which is mainly used for sending response message during an update.
Hash - Hash is a container of a hash value and information of its hash algorithm.
algorithm Algorithm of the hash function (e.g., SHA-3, SHA-256, etc.)
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
표 5를 참조하면, 진단 제출 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "diagnose"로 설정되며, 서브타입 필드는 항상 "submit"로 설정될 수 있다. 전술된 바와 같이, 차량 엘레멘트는 지역 필드를 포함할 수 있으며, 선택적으로 차량의 제조년도를 나타내는 연식(modelyear) 필드를 더 포함할 수도 있다.
본 메시지에 대한 XML 코딩의 일례는 도 9와 같다. 도 9는 본 발명의 일 실시예에 따른 진단 제출 메시지 코딩의 일례를 나타낸다.
진단 영수(S5): diagnose (receipt)
업데이트 서버는 게이트웨이가 제출한 리스트에 대한 영수 확인으로, 게이트웨이에 진단 영수(diagnose (receipt)) 메시지를 전송한다. 이를 통해, 게이트웨이는 리스트 제출이 성공적으로 수행됨을 인식(recognize)할 수 있다.
이때, 업데이트 서버는 각 소프트웨어 모듈 각각에 대하여 가능한 업데이트를 체크하지 않고 본 메시지를 게이트웨이로 전송한다. 따라서, 본 메시지에서는 소프트웨어 모듈 별 업데이트 가부에 대한 정보가 포함되지 않아 차량, 디바이스 및 모듈 엘레멘트가 불필요하다. 이러한 이유로 본 메시지는 도 4와 같은 형태를 가질 수 있다. 대신, 진단 제출 메시지의 성공적 수신 여부를 나타내는 상태(status) 필드가 메시지 엘레멘트에 포함될 수 있다. 상태 필드를 포함하는 메시지 엘레멘트의 구성의 일례가 아래 표 6에 나타나 있다.
Element Attribute in Element Description
Message - Container of the message


protocol Always "1.0"
version The version number of the message sender
type Message type (always "diagnose")
subtype Message subtype (always "receipt")
sessionid Session ID is a random GUID associated with the diagnose session. An identical session ID is applied to a set of diagnose request, report and submit messages.
trustlevel Trustlevel is determined based on security capability and safety requirement of device that generated this message.
ownerid Owner ID provided by a car manufacture / supplier.
messageid Message ID is a random GUID associated with individual message.
status Acknowledgement of report for diagnose (submit)
표 6을 참조하면, 진단 영수 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "diagnose"로 설정되며, 서브타입 필드는 항상 "receipt"로 설정될 수 있다. 또한, 상태 필드는 진단 제출 메시지가 성공적으로 수신된 경우 "yes"로 설정될 수 있다.
본 메시지에 대한 XML 코딩의 일례는 도 10과 같다. 도 10은 본 발명의 일 실시예에 따른 진단 영수 메시지 코딩의 일례를 나타낸다.
업데이트 서버의 업데이트 소프트웨어 확인(S6)
진단 제출 메시지에 포함된 하드웨어 및 소프트웨어 정보 리스트에 따라, 업데이트 서버는 해당 차량에 설치된 소프트웨어의 상태를 조사하고, 전자 제어기들에 대한 업데이트 필요성을 결정한다.
업데이트 확인 요청(S7): update_check (request)
S6 단계의 조사에는 긴 시간이 소요될 수 있기 때문에, 게이트웨이는 해당 차량에 대한 업데이트 필요성을 업데이트 서버에 주기적으로 확인하는 것이 바람직하다. 이를 위해 업데이트 확인 요청(update_check (request)) 메시지가 사용될 수 있다.
업데이트 확인 요청 메시지의 구조가 도 11에 도시된다. 도 11은 본 발명의 일 실시예에 따른 업데이트 확인 요청 메시지 구조의 일례를 나타낸다.
도 11을 참조하면, 업데이트 확인 요청 메시지의 구조는 전술한 도 8에 나타난 진단 제출 메시지의 구조와 유사하되, 모듈별 해쉬 엘레멘트가 생략된 형태일 수 있다.
업데이트 확인 요청 메시지의 포맷의 일례는 아래 표 7과 같다.
Element Attribute in Element Description
Message - Container of the message
protocol Always "1.0"
version The version number of the message sender
type Message type (always "update_check")
subtype Message subtype (always "request")
sessionid Session ID is a random GUID associated with the update_check session. An identical session ID is applied to a set of update_check, request and report messages.
trustlevel Trustlevel is determined based on security capability and safety requirement of device that generated this message.
ownerid Owner ID provided by a car manufacture / supplier.
messageid Message ID is a random GUID associated with individual message.
Vehicle - Container of vehicle information. It contains multiple Module elements.
name Name of the vehicle, if any.
model Type name of the vehicle provided by the car manufacture.
modelid Model name of the vehicle
locale Locale information of the vehicle
modelyear Year of the vehicle manufactured
vehicleid Vehicle id defined by a car manufacture / supplier.
Device

 - Container of device information. It contains multiple Module elements.
name Name of the device, if any.
type Type name of the device, such as "Power management ECU", "Seat belt control ECU", etc.
model Model name of the device.
deviceid Device id defined by a car manufacture / supplier.
Module

 - Container of module information, which contains a Hash element.
moduleid Module id is a unique id provided by a car manufacture / a supplier.
version Version of this software module.
hwversion Version of H/W including this software module
nextversion The version of the module update in progress, which is mainly used for sending response message during an update.
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
표 7을 참조하면, 업데이트 확인 요청 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "update_check"로 설정되며, 서브타입 필드는 항상 "request"로 설정될 수 있다. 또한, 메시지 엘레멘트의 세션식별자 필드는 업데이트 확인 세션에 대한 랜덤 GUID(Globally Unique ID)로 설정되며, 하나의 업데이트 확인 세션에 해당되는 업데이트 확인 요청 및 업데이트 확인 응답 메시지 모두에 동일한 값이 적용된다.
전술된 바와 같이, 모듈 엘레멘트의 하드웨어버전 필드는 모듈 엘레멘트 대신 디바이스 엘레멘트에 포함될 수 있음은 물론이다.
본 메시지에 대한 XML 코딩의 일례는 도 12와 같다. 도 12는 본 발명의 일 실시예에 따른 업데이트 확인 요청 메시지 코딩의 일례를 나타낸다.
업데이트 확인 응답(S8): update_check (response)
업데이트가 있는 경우, 업데이트 서버는 업데이트 모듈의 다운로드 위치 정보(예컨대, URL: Uniform Resource Locator)를 게이트웨이에 제공한다. 이를 위해 업데이트 확인 응답(update_check (response)) 메시지가 사용될 수 있다.
업데이트 확인 요청 메시지의 구조가 도 13에 도시된다. 도 13은 본 발명의 일 실시예에 따른 업데이트 확인 응답 메시지 구조의 일례를 나타낸다.
도 13을 참조하면, 업데이트 확인 응답 메시지의 기본적인 구조는 전술한 도 11에 나타난 업데이트 확인 요청 메시지의 구조와 유사하되, 모듈 엘레멘트의 하위 엘레멘트로 URLs 엘레멘트와 매니페스트(Manifest) 엘레멘트가 포함된다.
업데이트 확인 응답 메시지의 포맷의 일례는 아래 표 8과 같다.
Element Attribute Description
Message - Container of the message
protocol Always "1.0"
version The version number of the message sender
type Message type (always "update_check")
subtype Message subtype (always "response")
sessionid Session ID is a random GUID associated with the update_check session. An identical session ID is applied to a set of update_check request, report and submit messages.
trustlevel Trustlevel is determined based on security capability and safety requirement of device that generated this message.
ownerid Owner ID provided by a car manufacture / supplier.
messageid Message ID is a random GUID associated with individual message.
Vehicle - Container of vehicle information. It contains multiple Module elements.
name Name of the vehicle, if any.
model Type name of the vehicle provided by the car manufacture.
modelid Model name of the vehicle
locale Locale information of the vehicle
modelyear Year of the vehicle manufactured
vehicleid Vehicle id defined by a car manufacture / supplier.
Device - Container of device information. It contains multiple Module elements.
name Name of the device, if any.
type Type name of the device, such as "Power management ECU", "Seat belt control ECU", etc.
model Model name of the device.
deviceid Device id defined by a car manufacture / supplier.
Module - Container of module information, which contains a Hash element.
moduleid Module id is a unique id provided by a car manufacture / a supplier.
version Version of this software module.
hwversion Version of H/W including this software module
nextversion The version of the module update in progress, which is mainly used for sending response message during an update.
status Status of the inspection of update. "noupdate" is set if there are no updates, while "ok" is set if there are any update for this module.
URLs - Container of URL elements if there are any updates. This element is contained in a Module element where its status is ok.
URL - URL of update file.
codebase Location of the update file.
codebase2 Backup location of the update file.
Manifest

 - Describes the module needed to be installed, and the actions needed to be taken with those files.
version Specific newer version number of this software module.
Packages - A set of files needed to be installed. Contains no attribution. Contains one or more Package child elements.
Package

 - A single file to be installed for the module.
name Describes the filename of the update module.
size Contains the size in bytes of the update module.
Hash
 - Container of a hash value and information of its hash algorithm.
algorithm Algorithm of the hash function (e.g., SHA-3, SHA-256, etc.)
Actions - Actions to be performed to install the module once all required files in the packages element have been successfully downloaded.
Action - A single action to perform as part of the install process
event A fixed string denoting when this action should be run. One of "preinstall", "install", "postinstall" and "update".
arguments Arguments to be passed to the installation process.
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
표 8을 참조하면, 업데이트 확인 요청 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "update_check"로 설정되며, 서브타입 필드는 항상 "response"로 설정될 수 있다.
모듈 엘레멘트는 상태(status) 필드를 포함하며, 상태 필드는 업데이트 조사 결과 해당 모듈에 대한 업데이트가 없으면 "noupdate"로 설정되고, 업데이트가 있는 경우 "ok"로 설정될 수 있다.
한편, URLs 엘레멘트는 모듈 엘레멘트의 하위 엘레멘트로, 업데이트가 있는 경우 해당 업데이트 파일의 주소를 나타낸다. 실제 주소는 그의 하위 엘레멘트인 URL 엘레멘트의 코드 베이스(codebase) 필드에 포함된다. 해당 모듈에 대한 업데이트 파일의 주소가 두 개 준비되는 경우, 하나의 URL 엘레멘트는 두 개의 코드 베이스 필드를 포함할 수도 있고, 하나의 코드 베이스 필드와 하나의 codebase2 필드가 사용될 수도 있다. 이는 보다 상세히 후술하기로 한다.
매니페스트 엘레멘트는 인스톨될 모듈 및 파일들에 대해 수행될 액션을 기술하며, 해당 소프트웨어 모듈의 특정 신규 버전 넘버를 나타내는 버전 필드를 포함한다. 매니페스트 엘레멘트는 그 하위 엘레멘트로 인스톨될 파일 세트에 대한 정보를 나타내는 Packages 엘레멘트를 포함하며, Pakages 엘레멘트는 그 하위 엘레멘트로 Package 엘레멘트와 Actions 엘레멘트를 포함한다.
Package 엘레멘트는 해당 모듈에 인스톨될 개별 파일에 대한 정보를 나타내며, 파일명을 나타내는 이름(name) 필드와 바이트 단위로 파일 크기를 나타내는 사이즈(size) 필드를 포함한다. Package 엘레멘트는 다시 하위 엘레멘트로 해쉬 엘레멘트를 포함한다.
Actions 엘레멘트는 Packages 엘레멘트에 정의된 모든 필요한 파일이 성공적으로 다운로드된 경우 해당 모듈을 인스톨하기 위해 수행될 액션에 대한 정보를 나타내며, 하위 엘레멘트로 Action 엘레멘트를 포함한다. Action 엘레멘트는 인스톨 과정의 일부분으로 수행되는 개별 동작에 대한 정보를 나타내며, 기 설정된 4가지 동작 중 하나를 지시하는 이벤트(event) 필드와 인스톨 프로세스에 전달될 아규먼트를 나타내는 아규먼트(arguments) 필드를 포함한다.
본 메시지에 대한 XML 코딩의 일례는 도 14와 같다. 도 14는 본 발명의 일 실시예에 따른 업데이트 확인 응답 메시지 코딩의 일례를 나타낸다.
한편, 업데이트 확인 요청/응답 메시지는 업데이트 서버의 업데이트 조사가 수행되는 동안 여러번 교환될 수 있으며, 이러한 과정에서 플레이백(playback) 공격에 노출될 염려도 있다. 따라서, 업데이트 확인 요청 메시지와 업데이트 확인 응답 메시지의 정확한 매칭이 보장되는 것이 바람직하다. 이를 위해, 일 실시예에 의하면, 논스(nonce) 엘레멘트가 본 메시지에 적용될 수 있다.
논스 엘레멘트가 적용된 업데이트 확인 응답 메시지 포맷의 일례는 아래 표 9와 같다.
Element Attribute in Element Description
Message

 - Container of the message
protocol Always "1.0"
version The version number of the message sender
type Message type (always "update_check")
subtype Message subtype (always "request")
sessionid
 Session ID is a random GUID associated with the update_check session. An identical session ID is applied to a set of update_check, request and report messages.
trustlevel
 Trustlevel is determined based on security capability and safety requirement of device that generated this message.
ownerid Owner ID provided by a car manufacture / supplier.
messageid Message ID is a random GUID associated with individual message.
... ... ...
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
Nonce Random generated code for nonce method
표 9를 참조하면, 업데이트 확인 응답 메시지에 논스 기법을 위한 랜덤 생성 코드를 나타내는 논스 엘레멘트가 포함될 수 있다.
전술된 바와 같이, 업데이트 확인 응답 메시지에는 게이트웨이가 업데이트 소프트웨어 모듈을 다운로드할 수 있는 URL 링크 정보가 포함된다. 그런데, 업데이트 서버 자체나 해당 주소에 접속이 불가한 경우가 있을 수 있다. 예컨대, 이러한 접속 불가 상황으로 1) 업데이트 서버가 서비스거부(DoS) 공격이나 하드웨어 문제(NIC 또는 디스크 손상 등)로 일시적/영구적으로 다운되거나, 2) 업데이트 소프트웨어 모듈의 검증(validation) 문제가 바이러스 감염 등 파일 코럽션에 의해 발생하거나 3) 업데이트 서버에 다수의 동시 접속으로 인한 지나친 트래픽이 발생한 경우 등을 들 수 있다.
따라서, 강건한 소프트웨어 다운로드 환경을 제공하기 위하여, 백업 URL 링크 주소가 업데이트 확인 응답 메시지를 통해 제공되는 것이 바람직하다. 이를 위해, 전술된 바와 같이 코드베이스 필드 두개를 이용하여 하나에 백업 URL 정보를 제공하는 방법과, 코드베이스2 필드를 이용하여 백업 URL 정보를 제공하는 방법이 고려될 수 있다. 각각의 경우가 도 15 및 도 16에 도시된다.
도 15는 본 발명의 일 실시예에 따른 코드베이스 필드를 통해 백업 주소를 제공하는 업데이트 확인 응답 메시지 코딩의 일례를, 도 16은 본 발명의 일 실시예에 따른 코드베이스2 필드를 통해 백업 주소를 제공하는 업데이트 확인 응답 메시지 코딩의 일례를 각각 나타낸다.
도 15를 참조하면, URLs 엘레멘트 하위에 두 개의 URL 엘레멘트가 존재하며, 각 URL 엘레멘트에는 하나의 코드베이스 필드가 포함된다. 여기서, 첫 번째 URL 엘레멘트의 코드베이스 필드에는 디폴트 URL 주소 정보가 포함되고, 두 번째 URL 엘레멘트의 코드베이스 필드에는 백업 URL 주소 정보가 포함된다.
다음으로, 도 16을 참조하면, URLs 엘레멘트 하나의 URL 엘레멘트가 존재하며, 해당 URL 엘레멘트에는 코드베이스 필드와 코드베이스2 필드가 포함된다. 여기서, 코드베이스 필드에는 디폴트 URL 주소 정보가 포함되고, 코드베이스2 필드에는 백업 URL 주소 정보가 포함된다.
백업 URL 정보는 동일 서버의 다른 폴더의 주소일 수도 있고, 다른 서버의 주소일 수도 있다. 동일 서버의 다른 폴더인 경우 해당 파일의 코럽션이나 디스크 손상 등의 사유에 대처할 수 있으며, 다른 서버인 경우 원래 서버의 트래픽 부하 문제나 연결 실패 등의 사유에 대처할 수 있는 장점이 있다.
업데이트 소프트웨어 다운로드(S9): download update S/W
업데이트가 있는 경우, 게이트웨이는 다운로드 위치(URL/Backup URL) 정보로 접속하여 업데이트 모듈을 다운로드할 수 있다.
업데이트 알림(S10): update (notification)
게이트웨이는 업데이트를 각 제어기에 적용하기 전에, 업데이트 적용을 확인받기 위해 사용자 인터페이스를 통해 운전자에 알릴 수 있다(S10). 이를 위해 업데이트 알림(update (notification)) 메시지가 사용될 수 있다.
업데이트 확인 요청 메시지의 엘레멘트 구조는 자체는 전술한 도 13에 나타난 업데이트 확인 응답 메시지 구조와 유사하다. 다만, 일반적인 운전자는 업데이트 소프트웨어의 간단한 설명을 원하는 경우가 있으므로, 업데이트 소프트웨어에 대한 설명이 사용자 인터페이스를 통해 출력될 수 있도록 그에 대한 정보가 본 메시지에 포함될 수 있다.
업데이트 알림 메시지의 포맷의 일례는 아래 표 10과 같다.
Element Attribute in Element Description
Message - Container of the message
protocol Always "1.0"
version The version number of the message sender
type Message type (always "update")
subtype Message subtype (always "notification")
sessionid
 Session ID is a random GUID associated with the update session. An identical session ID is applied to a set of update notification, confirmation, application and result messages.
trustlevel Trustlevel is determined based on security capability and safety requirement of device that generated this message.
ownerid Owner ID provided by a car manufacture / supplier.
messageid Message ID is a random GUID associated with individual message.
Device

 - Container of device information. It contains multiple Module elements.
name Name of the device, if any.
type Type name of the device, such as "Power management ECU", "Seat belt control ECU", etc.
model Model name of the device.
deviceid Device id defined by a car manufacture / supplier.
Module

 - Container of module information, which contains a Hash element.
moduleid Module id is a unique id provided by a car manufacture / a supplier.
version Version of this software module.
hwversion Version of H/W including this software module
nextversion The version of the module update in progress, which is mainly used for sending response message during an update.
status Status of the inspection of update. Always "ok" is set.
URLs
 -
 Container of URL elements if there are any updates. This element is contained in a Module element where its status is ok.
URL - URL of update file.
codebase Location of the update file.
codebase2 Backup location of the update file.
Manifest - Describes the module needed to be installed, and the actions needed to be taken with those files.
version Specific newer version number of this software module.
Packages - A set of files needed to be installed. Contains no attribution. Contains one or more Package child elements.
Package - A single file to be installed for the module.
name Describes the filename of the update module.
description Description of update module
size Contains the size in bytes of the update module.
Hash

 - Container of a hash value and information of its hash algorithm.
algorithm Algorithm of the hash function (e.g., SHA-3, SHA-256, etc.)
Actions - Actions to be performed to install the module once all required files in the packages element have been successfully downloaded.
Action - A single action to perform as part of the install process
event A fixed string denoting when this action should be run. One of "preinstall", "install", "postinstall" and "update".
arguments Arguments to be passed to the installation process.
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
표 10을 참조하면, 업데이트 알림 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "update"로 설정되며, 서브타입 필드는 항상 "notification"로 설정될 수 있다.
세션식별자 필드는 업데이트 세션에 대한 랜덤 GUID(Globally Unique ID)로 설정되며, 하나의 업데이트 세션에 해당되는 업데이트 알림, 업데이트 컨펌, 업데이트 적용 및 업데이트 결과 메시지 모두에 동일한 값이 적용된다.
한편, Package 엘레멘트에는 업데이트 모듈에 대한 설명을 나타내는 description 필드가 포함될 수 있다.,
본 메시지에 대한 XML 코딩의 일례는 도 17과 같다. 도 17은 본 발명의 일 실시예에 따른 업데이트 알림 메시지 코딩의 일례를 나타낸다. 도 17을 참조하면, description 필드에는 해당 소프트웨어 모듈을 설명하는 텍스트 정보가 포함될 수 있다.
다른 실시예에 의하면, description 필드에 텍스트 자체 대신 해당 정보를 포함하는 URL 주소가 포함될 수도 있다. 이러한 경우, 아래 표 11과 같이 Package 엘레멘트에는 description 필드 대신 descriptionurl 필드가 포함될 수 있다.
Packages - A set of files needed to be installed. Contains no attribution. Contains one or more Package child elements.
Package - A single file to be installed for the module.
name Describes the filename of the update module.
size Contains the size in bytes of the update module.
descriptionurl Location of update description (text or html file)
위의 표 11과 같은 메시지에 대한 XML 코딩의 일례는 도 18과 같다. 도 18은 본 발명의 일 실시예에 따른 업데이트 알림 메시지 코딩의 다른 일례를 나타낸다.
업데이트 컨펌 (S11): update (confirmation)
운전자가 업데이트 적용을 확인하고 수락하면, 업데이트 컨펌(update (confirm)) 메시지가 게이트웨이로 전송된다.
업데이트 컨펌 메시지의 구조는 도 4에 도시된 진단 요청 메시지의 구조와 유사하며, 포맷의 일례는 아래 표 12와 같다.
Element Attribute in Element Description
Message - Container of the message
protocol Always "1.0"
version The version number of the message sender
type Message type (always "update")
subtype Message subtype (always "confirmation")
sessionid Session ID is a random GUID associated with the update session. An identical session ID is applied to a set of update notification, confirmation, application and result messages.
trustlevel Trustlevel is determined based on security capability and safety requirement of device that generated this message.
ownerid Owner ID provided by a car manufacture / supplier.
messageid Message ID is a random GUID associated with individual message.
status A driver's preference of application of the updates. "ok" or "no" is set.
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
표 12를 참조하면, 표 10을 참조하면, 업데이트 알림 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "update"로 설정되며, 서브타입 필드는 항상 "confirmation"으로 설정될 수 있다.
또한, 메시지 엘레멘트에 업데이트 적용의 수락 여부를 나타내는 status 필드가 포함된다. status 필드는 운전자가 업데이트 적용을 수락한 경우 "Yes" 또는 "ok"로, 그렇지 않은 경우 "no"로 설정될 수 있다.
본 메시지에 대한 XML 코딩의 일례는 도 19와 같다. 도 19는 본 발명의 일 실시예에 따른 업데이트 컨펌 메시지 코딩의 일례를 나타낸다.
업데이트 적용(S12): update (application)
운전자의 수락에 따라, 게이트웨이는 업데이트 모듈 파일을 해당 제어기로 전송하고, 업데이트를 적용할 것을 요청할 수 있다. 이를 위해 업데이트 적용(update (application)) 메시지가 사용될 수 있다.
업데이트 적용 메시지의 구조가 도 20에 도시된다. 도 20은 본 발명의 일 실시예에 따른 업데이트 적용 메시지 구조의 일례를 나타낸다.
도 20을 참조하면, 업데이트 적용 메시지는 게이트웨이에서 개별 제어기로 전송되는 메시지이므로, 차량 엘레멘트가 없고 해당 제어기에 대응되는 디바이스 엘레멘트를 포함하되, 그 하위 엘레멘트로 모듈 엘레멘트를 포함한다. 모듈 엘레멘트는 다시 매니페스트 엘레멘트를 포함하고, 매니페스트 엘레멘트는 Packages엘레멘트를 포함한다.
업데이트 적용 메시지의 포맷의 일례는 아래 표 13과 같다.
Element Attribute Description
Message - Container of the message
protocol Always "1.0"
version The version number of the message sender
type Message type (always "update")
subtype Message subtype (always "application")
sessionid
 Session ID is a random GUID associated with the update session. An identical session ID is applied to a set of update notification, confirmation, application and result messages.
trustlevel Trustlevel is determined based on security capability and safety requirement of device that generated this message.
ownerid Owner ID provided by a car manufacture / supplier.
messageid Message ID is a random GUID associated with individual message.
Device - Container of device information. It contains multiple Module elements.
name Name of the device, if any.
type Type name of the device, such as "Power management ECU", "Seat belt control ECU", etc.
model Model name of the device.
deviceid Device id defined by a car manufacture / supplier.
Module - Container of module information, which contains a Hash element.
moduleid Module id is a unique id provided by a car manufacture / a supplier.
version Version of this software module.
hwversion Version of H/W including this software module
nextversion The version of the module update in progress, which is mainly used for sending response message during an update.
Manifest - Describes the module needed to be installed, and the actions needed to be taken with those files.
version Specific newer version number of this software module.
Packages - A set of files needed to be installed. Contains no attribution. Contains one or more Package child elements.
Package - A single file to be installed for the module.
name Describes the filename of the update module.
size Contains the size in bytes of the update module.
Target - Encoded binary data as an update module.
encode Specification of encodings ("base64Binary" or "hexBinary")
Hash - Container of a hash value and information of its hash algorithm.
algorithm Algorithm of the hash function (e.g., SHA-3, SHA-256, etc.)
Actions - Actions to be performed to install the module once all required files in the packages element have been successfully downloaded.
Action

 -
 A single action to perform as part of the install process
event A fixed string denoting when this action should be run. One of "preinstall", "install", "postinstall" and "update"
arguments Arguments to be passed to the installation process.
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
표 13을 참조하면, 업데이트 적용 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "update"로 설정되며, 서브타입 필드는 항상 "application"으로 설정될 수 있다.
한편, Package 엘레멘트에는 업데이트 모듈을 인코딩된 바이너리 데이터로 나타낸 타켓(Target) 엘레멘트가 포함되며, 인코드(encode) 필드를 통해 인코딩 방식이 지시될 수 있다.
본 메시지에 대한 XML 코딩의 일례는 도 21과 같다. 도 21은 본 발명의 일 실시예에 따른 업데이트 적용 메시지 코딩의 일례를 나타낸다.
업데이트 결과(S13): update (result)
업데이트 모듈 파일을 수신한 각 제어기는 업데이트를 적용하고, 적용 결과를 게이트웨이로 전송한다. 이를 위해 업데이트 결과(updatet (result)) 메시지가 사용될 수 있다.
업데이트 결과 메시지의 구조가 도 22에 도시된다. 도 22는 본 발명의 일 실시예에 따른 업데이트 결과 메시지 구조의 일례를 나타낸다.
도 22를 참조하면, 업데이트 결과 메시지는 개별 제어기에서 게이트웨이로 전송되는 메시지이므로, 차량 엘레멘트가 없고 해당 제어기에 대응되는 디바이스 엘레멘트를 포함하되, 그 하위 엘레멘트로 모듈 엘레멘트를 포함한다.
업데이트 결과 메시지의 포맷의 일례는 아래 표 14와 같다.
Element Attribute in Element Description
Message

 - Container of the message
protocol Always "1.0"
version The version number of the message sender
type Message type (always "update")
subtype Message subtype (always "result")
sessionid Session ID is a random GUID associated with the update session. An identical session ID is applied to a set of diagnose request, report and submit messages.
trustlevel Trustlevel is determined based on security capability and safety requirement of device that generated this message.
ownerid Owner ID provided by a car manufacture / supplier.
messageid Message ID is a random GUID associated with individual message.
Device - Container of device information. It contains multiple Module elements.
name Name of the device, if any.
type Type name of the device, such as "Power management ECU", "Seat belt control ECU", etc.
model Model name of the device.
deviceid Device id defined by a car manufacture / supplier.
Module

 - Container of module information, which contains a Hash element.
moduleid Module id is a unique id provided by a car manufacture / a supplier.
version Version of this software module.
hwversion Version of H/W including this software module
nextversion The version of the module update in progress, which is mainly used for sending response message during an update.
status Result of update process in the ECU.
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
표 14를 참조하면, 업데이트 결과 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "update"로 설정되며, 서브타입 필드는 항상 "result"으로 설정될 수 있다.
한편, Package 엘레멘트에는 업데이트 모듈을 인코딩된 바이너리 데이터로 나타낸 타켓(Target) 엘레멘트가 포함되며, 인코드(encode) 필드를 통해 인코딩 방식이 지시될 수 있다.
본 메시지에 대한 XML 코딩의 일례는 도 23과 같다. 도 23은 본 발명의 일 실시예에 따른 업데이트 결과 메시지 코딩의 일례를 나타낸다.
업데이트 보고 제출(S14): update_report (submit)
게이트웨이는 업데이트 적용 결과를 업데이트 보고 제출(update_report (submit)) 메세지를 통해 업데이트 서버로 제출한다.
업데이트 보고 제출 메시지의 구조는 도 8에 도시된 진단 제출 메시지 구조와 유사하며, 그 포맷의 일례는 아래 표 15와 같다.
Element Attribute in Element Description
Message - Container of the message
protocol Always "1.0"
version The version number of the message sender
type Message type (always "update_report")
subtype Message subtype (always "submit")
sessionid Session ID is a random GUID associated with the update_report session. An identical session ID is applied to a set of update_report submit and receipt messages.
trustlevel Trustlevel is determined based on security capability and safety requirement of device that generated this message.
ownerid Owner ID provided by a car manufacture / supplier.
messageid Message ID is a random GUID associated with individual message.
Vehicle

 - Container of vehicle information. It contains multiple Module elements.
name Name of the vehicle, if any.
model Type name of the Vehicle provided by the car manufacture.
modelid Model name of the vehicle
locale Locale information of the vehicle
modelyear Year of the vehicle manufactured
vehicleid Vehicle id defined by a car manufacture / supplier.
Device

 - Container of device information. It contains multiple Module elements.
name Name of the device, if any.
type Type name of the device, such as "Power management ECU", "Seat belt control ECU", etc.
model Model name of the device.
deviceid Device id defined by a car manufacture / supplier.
Module

 - Container of module information, which contains a Hash element.
moduleid Module id is a unique id provided by a car manufacture / a supplier.
version Version of this software module.
hwversion Version of H/W including this software module
nextversion
 The version of the module update in progress, which is mainly used for sending response message during an update.
status Result of application of this module.
Hash - Hash is a container of a hash value and information of its hash algorithm.
algorithm Algorithm of the hash function (e.g., SHA-3, SHA-256, etc.)
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
표 15를 참조하면, 업데이트 보고 제출 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "update_report"로 설정되며, 서브타입 필드는 항상 "submit"으로 설정될 수 있다.
업데이트 보고 제출 메시지의 모듈 엘레멘트는 status 필드를 포함하며, 본 필드를 통해 해당 모듈의 업데이트 적용 결과가 지시될 수 있다.
본 메시지에 대한 XML 코딩의 일례는 도 24와 같다. 도 24는 본 발명의 일 실시예에 따른 업데이트 보고 제출 메시지 코딩의 일례를 나타낸다.
업데이트 보고 영수(S15): update_report (receipt)
업데이트 서버는 업데이트 보고 제출 메시지에 대한 응답으로, 업데이트 보고 영수(update_report (receipt)) 메시지를 게이트웨이로 전송한다.
업데이트 보고 영수 메시지의 구조는 도 11에 도시된 업데이트 확인 요청 메시지 구조와 유사하며, 그 포맷의 일례는 아래 표 16와 같다.
Element Attribute in Element Description
Message - Container of the message
protocol Always "1.0"
version The version number of the message sender
type Message type (always "update_report")
subtype Message subtype (always "receipt")
sessionid Session ID is a random GUID associated with the update_report session. An identical session ID is applied to a set of update_report submit and receipt messages.
trustlevel Trustlevel is determined based on security capability and safety requirement of device that generated this message.
ownerid Owner ID provided by a car manufacture / supplier.
messageid Message ID is a random GUID associated with individual message.
Vehicle - Container of vehicle information. It contains multiple Module elements.
name Name of the vehicle, if any.
model Type name of the vehicle provided by the car manufacture.
modelid Model name of the vehicle
locale Locale information of the vehicle
modelyear Year of the vehicle manufactured
vehicleid Vehicle id defined by a car manufacture / supplier.
Device - Container of device information. It contains multiple Module elements.
name Name of the device, if any.
type Type name of the device, such as "Power management ECU", "Seat belt control ECU", etc.
model Model name of the device.
deviceid Device id defined by a car manufacture / supplier.
Module - Container of module information, which contains a Hash element.
moduleid Module id is a unique id provided by a car manufacture / a supplier.
version Version of this software module.
hwversion Version of H/W including this software module
nextversion The version of the module update in progress, which is mainly used for sending response message during an update.
status Acknowledgement of report for this module.
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
표 15를 참조하면, 업데이트 보고 영수 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "update_report"로 설정되며, 서브타입 필드는 항상 "receipt"로 설정될 수 있다.
업데이트 보고 영수 메시지의 모듈 엘레멘트는 status 필드를 포함하며, 본 필드를 통해 해당 모듈의 보고 ACK(Acknowledgement) 여부가 지시될 수 있다.
본 메시지에 대한 XML 코딩의 일례는 도 25와 같다. 도 25는 본 발명의 일 실시예에 따른 업데이트 보고 영수 메시지 코딩의 일례를 나타낸다.
한편, 본 실시예에 따른 게이트웨이는 적어도 유선통신부, 무선통신부, 메모리 및 프로세서를 포함할 수 있다(미도시).
유선통신부는 게이트웨이와 연결되어 진단 세션 및 업데이트 세션을 수행하는 제어기들과의 통신 기능을 제공한다. 유선 통신은 CAN(Controller Area Network), Ethernet, LIN 프로토콜 중 적어도 하나의 방식을 따를 수 있으나, 반드시 이에 한정되는 것은 아니다.
무선통신부는 업데이트 서버와의 무선 통신 기능을 제공하며, 무선 기지국이나 텔레메틱스 센터를 경유하여 업데이트 서버와 연결될 수도 있다.
메모리는 프로세서의 처리 및 제어를 위한 프로그램이 저장될 수도 있고, 입/출력되는 데이터들의 임시 저장을 위한 기능을 수행할 수도 있다.
프로세서는 통상적으로 게이트웨이 구성요소의 전반적인 동작을 제어한다. 예를 들어, 상술한 본 발명의 실시예들, 예컨대 S2 단계 내지 S14 단계를 수행하기 위한 콘트롤러 기능, 메시지 생성 및 해석 기능, 인증 및 암호화 기능 등이 수행될 수 있다.
아울러, 본 실시예에 따른 차량은 상술한 게이트웨이 및 그와 연결된 적어도 하나의 제어기를 포함할 수 있다.
전술한 본 발명은, 프로그램이 기록된 매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 매체는, 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 매체의 예로는, HDD(Hard Disk Drive), SSD(Solid State Disk), SDD(Silicon Disk Drive), ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장 장치 등이 있다.
따라서, 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.

Claims (28)

  1. 차량용 게이트웨이의 무선 소프트웨어 업데이트 방법에 있어서,
    적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 획득하는 단계; 및
    상기 적어도 하나의 제어기에 설치된 소프트웨어 모듈의 업데이트가 요구되는지를 확인하기 위해, 상기 적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 포함하는 진단 제출 메시지를 업데이트 서버로 전송하는 단계; 및
    업데이트가 요구되는 제어기의 업데이트 모듈을 다운로드하기 위한 다운로드 위치 정보를 포함하는 업데이트 확인 응답 메시지를 상기 업데이트 서버로부터 수신하는 단계를 포함하되,
    상기 진단 제출 메시지는, 상기 업데이트 서버가 상기 차량에 탑재된 상기 적어도 하나의 제어기 각각에 대응하는 소프트웨어 모듈의 업데이트 여부를 확인할 수 있도록, 차량의 지역정보 및 상기 적어도 하나의 제어기 각각의 하드웨어 버전 정보를 포함하는, 무선 소프트웨어 업데이트 방법.
  2. 제 1항에 있어서,
    상기 하드웨어 버전 정보는,
    상기 진단 제출 메시지의 장치(Device) 엘레멘트에 포함되는, 무선 소프트웨어 업데이트 방법.
  3. 제 1항에 있어서,
    상기 차량의 지역정보는,
    상기 진단 제출 메시지의 차량(Vehicle) 엘레멘트에 포함되는, 무선 소프트웨어 업데이트 방법.
  4. 제 1항에 있어서,
    상기 업데이트 서버로부터 상기진단 제출 메시지의 성공적 수신 여부를 지시하는 진단 영수 메시지를 수신하는 단계를 더 포함하는, 무선 소프트웨어 업데이트 방법.
  5. 제 4항에 있어서,
    상기 진단 영수 메시지는,
    상기 진단 제출 메시지의 성공적 수신 여부를 지시하는 필드를 메시지 엘레멘트에 포함하는, 무선 소프트웨어 업데이트 방법.
  6. 제 4항에 있어서,
    상기 진단 제출 메시지 및 상기 진단 영수 메시지 각각은,
    세션식별자(sessionid) 정보를 포함하고, 동일한 값을 상기 세션식별자 정보로 갖는, 무선 소프트웨어 업데이트 방법.
  7. 삭제
  8. 제 1항에 있어서,
    상기 다운로드 위치 정보는,
    둘 이상의 URL 주소를 포함하는, 무선 소프트웨어 업데이트 방법.
  9. 제 8항에 있어서,
    상기 둘 이상의 URL 주소 중 적어도 하나는 백업 URL 주소인, 무선 소프트웨어 업데이트 방법.
  10. 제 1항 내지 제6항 및 제8항 내지 제 9항 중 어느 한 항에 따른 무선 소프트웨어 업데이트 방법을 실행시키기 위한 프로그램을 기록한 컴퓨터 해독 가능 기록 매체.
  11. 무선 소프트웨어 업데이트를 수행하는 차량용 게이트웨이에 있어서,
    적어도 하나의 제어기와 통신하는 유선 통신 모듈;
    업데이트 서버와 통신하는 무선 통신 모듈; 및
    상기 적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 획득하고, 상기 적어도 하나의 제어기에 설치된 소프트웨어 모듈의 업데이트가 요구되는지를 확인하기 위해 상기 적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 포함하는 진단 제출 메시지를 상기 업데이트 서버로 전송하도록 제어하며, 업데이트가 요구되는 제어기의 업데이트 모듈을 다운로드하기 위한 다운로드 위치 정보를 포함하는 업데이트 확인 응답 메시지를 상기 업데이트 서버로부터 수신하도록 제어하는 프로세서를 포함하되,
    상기 진단 제출 메시지는, 상기 업데이트 서버가 상기 차량에 탑재된 상기 적어도 하나의 제어기 각각에 대응하는 소프트웨어 모듈의 업데이트 여부를 확인할 수 있도록, 차량의 지역정보 및 상기 적어도 하나의 제어기 각각의 하드웨어 버전 정보를 포함하는, 차량용 게이트웨이.
  12. 제 11항에 있어서,
    상기 하드웨어 버전 정보는,
    상기 진단 제출 메시지의 장치(Device) 엘레멘트에 포함되는, 차량용 게이트웨이.
  13. 제 11항에 있어서,
    상기 차량의 지역정보는,
    상기 진단 제출 메시지의 차량(Vehicle) 엘레멘트에 포함되는, 차량용 게이트웨이.
  14. 제 11항에 있어서,
    상기 프로세서는,
    상기 무선 통신 모듈을 통해 상기 업데이트 서버로부터 상기 진단 제출 메시지의 성공적 수신 여부를 지시하는 진단 영수 메시지가 수신되도록 제어하는, 차량용 게이트웨이.
  15. 제 14항에 있어서,
    상기 진단 영수 메시지는,
    상기 진단 제출 메시지의 성공적 수신 여부를 지시하는 필드를 메시지 엘레멘트에 포함하는, 차량용 게이트웨이.
  16. 제 14항에 있어서,
    상기 진단 제출 메시지 및 상기 진단 영수 메시지 각각은,
    세션식별자(sessionid) 정보를 포함하고, 동일한 값을 상기 세션식별자 정보로 갖는, 차량용 게이트웨이.
  17. 삭제
  18. 제 11항에 있어서,
    상기 다운로드 위치 정보는,
    둘 이상의 URL 주소를 포함하는, 차량용 게이트웨이.
  19. 제 18항에 있어서,
    상기 둘 이상의 URL 주소 중 적어도 하나는 백업 URL 주소인, 차량용 게이트웨이.
  20. 무선 소프트웨어 업데이트를 수행하는 차량에 있어서,
    적어도 하나의 제어기; 및
    상기 적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 획득하고, 상기 적어도 하나의 제어기에 설치된 소프트웨어 모듈의 업데이트가 요구되는지를 확인하기 위해 상기 적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 포함하는 진단 제출 메시지를 업데이트 서버로 전송하며, 업데이트가 요구되는 제어기의 업데이트 모듈을 다운로드하기 위한 다운로드 위치 정보를 포함하는 업데이트 확인 응답 메시지를 상기 업데이트 서버로부터 수신하는 게이트웨이를 포함하되,
    상기 진단 제출 메시지는, 상기 업데이트 서버가 상기 차량에 탑재된 상기 적어도 하나의 제어기 각각에 대응하는 소프트웨어 모듈의 업데이트 여부를 확인할 수 있도록, 차량의 지역정보 및 상기 적어도 하나의 제어기 각각의 하드웨어 버전 정보를 포함하는, 차량.
  21. 제 20항에 있어서,
    상기 하드웨어 버전 정보는,
    상기 진단 제출 메시지의 장치(Device) 엘레멘트에 포함되는, 차량.
  22. 제 20항에 있어서,
    상기 차량의 지역정보는,
    상기 진단 제출 메시지의 차량(Vehicle) 엘레멘트에 포함되는, 차량.
  23. 제 20항에 있어서,
    상기 게이트웨이는,
    상기 업데이트 서버로부터 상기 진단 제출 메시지의 성공적 수신 여부를 지시하는 진단 영수 메시지를 수신하는, 차량.
  24. 제 23항에 있어서,
    상기 진단 영수 메시지는,
    상기 진단 제출 메시지의 성공적 수신 여부를 지시하는 필드를 메시지 엘레멘트에 포함하는, 차량.
  25. 제 23항에 있어서,
    상기 진단 제출 메시지 및 상기 진단 영수 메시지 각각은,
    세션식별자(sessionid) 정보를 포함하고, 동일한 값을 상기 세션식별자 정보로 갖는, 차량.
  26. 삭제
  27. 제 20항에 있어서,
    상기 다운로드 위치 정보는,
    둘 이상의 URL 주소를 포함하는, 차량.
  28. 제 27항에 있어서,
    상기 둘 이상의 URL 주소 중 적어도 하나는 백업 URL 주소인, 차량.
KR1020170018667A 2016-02-11 2017-02-10 차량용 무선 소프트웨어 업데이트 방법 및 장치 KR101966626B1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/KR2017/001509 WO2017138787A1 (ko) 2016-02-11 2017-02-10 차량용 무선 소프트웨어 업데이트 방법 및 장치
US16/048,692 US10768922B2 (en) 2016-02-11 2018-07-30 Method and device for wirelessly updating software for vehicle
US16/943,061 US11422787B2 (en) 2016-02-11 2020-07-30 Method and device for wirelessly updating software for vehicle

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201662293842P 2016-02-11 2016-02-11
US62/293,842 2016-02-11
US201662297422P 2016-02-19 2016-02-19
US62/297,422 2016-02-19

Publications (2)

Publication Number Publication Date
KR20170094765A KR20170094765A (ko) 2017-08-21
KR101966626B1 true KR101966626B1 (ko) 2019-04-09

Family

ID=59757484

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020170018667A KR101966626B1 (ko) 2016-02-11 2017-02-10 차량용 무선 소프트웨어 업데이트 방법 및 장치

Country Status (4)

Country Link
US (2) US10768922B2 (ko)
EP (1) EP3416052B1 (ko)
KR (1) KR101966626B1 (ko)
CN (1) CN108701039B (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102585388B1 (ko) * 2022-11-30 2023-10-23 펜타시큐리티 주식회사 차량 ota 업데이트의 효율성 향상을 위한 oma-dm 프로토콜의 메시지 노드 확장 방법 및 이를 이용하는 장치

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101966626B1 (ko) 2016-02-11 2019-04-09 현대자동차주식회사 차량용 무선 소프트웨어 업데이트 방법 및 장치
US10360017B1 (en) * 2018-01-02 2019-07-23 Microsoft Technology Licensing, Llc Updating program packages at distribution endpoint
US10744937B2 (en) * 2018-01-15 2020-08-18 Ford Global Technologies, Llc Automated vehicle software update feedback system
JP7408937B2 (ja) * 2018-08-10 2024-01-09 株式会社デンソー センター装置，配信パッケージの生成方法及び配信パッケージ生成用プログラム
US11449327B2 (en) 2018-11-30 2022-09-20 Paccar Inc Error-resilient over-the-air software updates for vehicles
US11356425B2 (en) 2018-11-30 2022-06-07 Paccar Inc Techniques for improving security of encrypted vehicle software updates
CN110138840B (zh) * 2019-04-22 2022-04-19 浙江合众新能源汽车有限公司 一种基于车载以太网的并行刷新方法
KR102391007B1 (ko) * 2019-07-15 2022-04-27 현대자동차주식회사 차량의 부품 교체 서비스 제공 시스템 및 방법
CN110618826A (zh) * 2019-08-16 2019-12-27 深圳市元征科技股份有限公司 一种应用程序更新的方法、装置及终端设备
CN111679846A (zh) * 2020-05-20 2020-09-18 北京海博思创科技股份有限公司 应用的更新方法和装置
CN112035145B (zh) * 2020-09-08 2023-05-26 Oppo广东移动通信有限公司 设备升级方法及相关装置
CN113238790B (zh) * 2021-05-28 2023-08-29 成都新易盛通信技术股份有限公司 基于sd卡和eeprom的固件程序更新方法及系统
JP2023002161A (ja) * 2021-06-22 2023-01-10 トヨタ自動車株式会社 センタ、ｏｔａマスタ、方法、プログラム、及び車両
US20230351019A1 (en) * 2022-04-27 2023-11-02 Dell Products L.P. Secure smart network interface controller firmware update
WO2024000354A1 (zh) * 2022-06-30 2024-01-04 华为技术有限公司 一种节点升级方法以及装置
CN115080299B (zh) * 2022-07-20 2022-11-25 深圳市星卡软件技术开发有限公司 软件故障反馈处理方法、装置、介质及设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012101788A (ja) * 2011-12-01 2012-05-31 Hitachi Automotive Systems Ltd 車載ゲートウェイ装置
US20130318541A1 (en) * 2012-05-22 2013-11-28 Avaya Inc. System and method for dynamic influencing of sequence vector by sequenced applications

Family Cites Families (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6161071A (en) * 1999-03-12 2000-12-12 Navigation Technologies Corporation Method and system for an in-vehicle computing architecture
JP2003131885A (ja) * 2001-10-24 2003-05-09 Denso Corp 車載電子制御装置のプログラム書込システム
JP2003308211A (ja) * 2002-04-15 2003-10-31 Mitsubishi Electric Corp 移動端末、サービス配信サーバ及びサービス配信システム
KR100943935B1 (ko) * 2005-03-24 2010-02-24 노키아 코포레이션 후속 송신 세션에 대한 수신 장치로의 통보
US7818403B2 (en) * 2007-09-17 2010-10-19 Gm Global Technology Operations, Inc. System for using non-standard transfer protocol from software received at client device for exchanging data with in-vehicle communications gateway
US7849224B2 (en) * 2007-09-17 2010-12-07 Gm Global Technology Operations, Inc. Method and apparatus for implementing a mobile server
CN101651669A (zh) * 2008-08-15 2010-02-17 国际商业机器公司 业务箱集成服务器和业务箱集成方法
US9214085B2 (en) 2009-11-06 2015-12-15 Toyota Jidosha Kabushiki Kaisha Vehicle gateway device
KR20110071788A (ko) * 2009-12-21 2011-06-29 한국전자통신연구원 차량 정보 전송 방법
KR20110092007A (ko) * 2010-02-08 2011-08-17 주식회사 만도 차량의 소프트웨어 다운로드 시스템 및 방법
JP5527270B2 (ja) * 2011-04-12 2014-06-18 株式会社デンソー 車載用電子制御装置
CN102736925A (zh) * 2011-04-14 2012-10-17 比亚迪股份有限公司 一种车辆的软件更新方法和系统
US9288270B1 (en) * 2011-04-22 2016-03-15 Angel A. Penilla Systems for learning user preferences and generating recommendations to make settings at connected vehicles and interfacing with cloud systems
JP5829839B2 (ja) * 2011-06-16 2015-12-09 富士通テン株式会社 サーバ装置、プログラム提供システム、プログラム提供方法、及び、プログラム
US8949823B2 (en) * 2011-11-16 2015-02-03 Flextronics Ap, Llc On board vehicle installation supervisor
GB2508235A (en) * 2012-11-27 2014-05-28 Ibm Software asset management using browser plug-in
US20140245278A1 (en) * 2013-02-22 2014-08-28 Panasonic Automotive Systems Company Of America, Division Of Panasonic Corpor Automotive component self update via software version control
KR20150043732A (ko) 2013-10-15 2015-04-23 현대자동차주식회사 자동차 제어기의 소프트웨어 업데이트 시스템 및 방법
KR101548953B1 (ko) * 2013-12-24 2015-09-01 현대자동차주식회사 차량용 정보 갱신 방법 및 장치
KR20150076846A (ko) * 2013-12-27 2015-07-07 기아자동차주식회사 전자제어유닛의 데이터 수집 시스템 및 방법
US9524156B2 (en) * 2014-01-09 2016-12-20 Ford Global Technologies, Llc Flexible feature deployment strategy
US9398397B2 (en) * 2014-01-09 2016-07-19 Ford Global Technologies, Llc Secure manipulation of embedded modem connection settings through short messaging service communication
US10140109B2 (en) * 2014-02-25 2018-11-27 Ford Global Technologies, Llc Silent in-vehicle software updates
EP2924964B1 (en) * 2014-03-26 2019-03-06 Alcatel Lucent Safe handling of text messages
US9229704B2 (en) * 2014-04-01 2016-01-05 Ford Global Technologies, Llc Smart vehicle reflash with battery state of charge (SOC) estimator
US20150331686A1 (en) * 2014-05-15 2015-11-19 Ford Global Technologies, Llc Over-the-air vehicle issue resolution
JP6618480B2 (ja) * 2014-11-12 2019-12-11 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 更新管理方法、更新管理システム及び制御プログラム
US9639344B2 (en) * 2014-12-11 2017-05-02 Ford Global Technologies, Llc Telematics update software compatibility
US9648023B2 (en) * 2015-01-05 2017-05-09 Movimento Group Vehicle module update, protection and diagnostics
US9794070B2 (en) * 2015-01-07 2017-10-17 Cyph, Inc. Method of ephemeral encrypted communications
JP6659220B2 (ja) * 2015-01-27 2020-03-04 ルネサスエレクトロニクス株式会社 通信装置、半導体装置、プログラムおよび通信システム
US9762454B2 (en) * 2015-05-08 2017-09-12 Rockwell Automation Technologies, Inc. System and method to capture and document cross-product compatibility status information for industrial devices
DE102015209116A1 (de) * 2015-05-19 2016-11-24 Robert Bosch Gmbh Verfahren und Aktualisierungsgateway zum Aktualisieren eines eingebetteten Steuergerätes
US20160360557A1 (en) * 2015-06-08 2016-12-08 GM Global Technology Operations LLC Collaborative mptcp
WO2017002611A1 (ja) * 2015-06-30 2017-01-05 日立オートモティブシステムズ株式会社 車両データ書換制御装置および車両データ書換認証システム
CA3019911A1 (en) * 2015-07-27 2017-02-02 Datagrid Systems, Inc. Techniques for evaluating server system reliability, vulnerability and component compatibility using crowdsourced server and vulnerability data
US10229137B2 (en) * 2015-08-12 2019-03-12 Blackberry Limited Management of upgradeable endpoints
US9916151B2 (en) * 2015-08-25 2018-03-13 Ford Global Technologies, Llc Multiple-stage secure vehicle software updating
KR20170025085A (ko) * 2015-08-27 2017-03-08 삼성전자주식회사 외부 기기 및 서버와 무선 통신 가능한 무선 단말기 및 이의 소프트웨어의 업데이트 방법
KR101966626B1 (ko) 2016-02-11 2019-04-09 현대자동차주식회사 차량용 무선 소프트웨어 업데이트 방법 및 장치
US20170308365A1 (en) * 2016-04-26 2017-10-26 General Motors Llc Facilitating mobile device application installation using a vehicle
US20170315797A1 (en) * 2016-05-02 2017-11-02 Ford Global Technologies, Llc Vehicle connection location regional software delivery
US20180107473A1 (en) * 2016-10-13 2018-04-19 GM Global Technology Operations LLC Determining whether to install a vehicle system update in a vehicle
DE112017005439T5 (de) * 2016-10-27 2019-08-14 Sumitomo Electric Industries, Ltd. Steuervorrichtung, Programmaktualisierungsverfahren und Computerprogramm

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012101788A (ja) * 2011-12-01 2012-05-31 Hitachi Automotive Systems Ltd 車載ゲートウェイ装置
US20130318541A1 (en) * 2012-05-22 2013-11-28 Avaya Inc. System and method for dynamic influencing of sequence vector by sequenced applications

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102585388B1 (ko) * 2022-11-30 2023-10-23 펜타시큐리티 주식회사 차량 ota 업데이트의 효율성 향상을 위한 oma-dm 프로토콜의 메시지 노드 확장 방법 및 이를 이용하는 장치

Also Published As

Publication number Publication date
US20200356356A1 (en) 2020-11-12
EP3416052B1 (en) 2020-11-25
CN108701039A (zh) 2018-10-23
EP3416052A1 (en) 2018-12-19
KR20170094765A (ko) 2017-08-21
EP3416052A4 (en) 2019-09-25
US11422787B2 (en) 2022-08-23
US10768922B2 (en) 2020-09-08
CN108701039B (zh) 2021-12-07
US20180336026A1 (en) 2018-11-22

Similar Documents

Publication Publication Date Title
KR101966626B1 (ko) 차량용 무선 소프트웨어 업데이트 방법 및 장치
US11662991B2 (en) Vehicle-mounted device upgrade method and related device
EP3623939A1 (en) Method and apparatus for wirelessly updating software for vehicle
US10360018B2 (en) Update control apparatus, software update system, and update control method
US20190057214A1 (en) Update control device, terminal, and method of controlling
US11159658B2 (en) Homogenization of telematics data through unified messaging protocol
US9648023B2 (en) Vehicle module update, protection and diagnostics
JP6585019B2 (ja) ネットワーク監視装置、ネットワークシステムおよびプログラム
US11321074B2 (en) Vehicle-mounted device upgrade method and related apparatus
CN110764807B (zh) 一种升级方法、系统、服务器及终端设备
EP3537740B1 (en) Hash based device configuration management
US20060282497A1 (en) Software defined radio download
US8646070B1 (en) Verifying authenticity in data storage management systems
US9049012B2 (en) Secured cryptographic communication system
WO2017124736A1 (zh) 一种升级异常信息的传输方法、设备和系统
KR20200019565A (ko) 차량용 무선 소프트웨어 업데이트 방법 및 장치
CN101453479A (zh) 一种快速的文件传输系统
CN112131041A (zh) 用于管理数据放置的方法、设备和计算机程序产品
WO2022099683A1 (zh) 一种数据传输方法、装置、设备、系统及存储介质
CN110708311A (zh) 下载权限授权方法、装置和服务器
CN107645357B (zh) 传输文件不完整的恢复方法及装置
JP4631668B2 (ja) 電子文書管理装置および電子文書管理プログラム
CN110769065A (zh) 一种远程管理方法、系统、终端设备及服务器
CN115333937B (zh) 数据下载方法、装置及电子设备
US20230368585A1 (en) Method and system for data transfer from a vehicle

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant