WO2017138787A1 - Method and device for wirelessly updating software for vehicle - Google Patents

Method and device for wirelessly updating software for vehicle Download PDF

Info

Publication number
WO2017138787A1
WO2017138787A1 PCT/KR2017/001509 KR2017001509W WO2017138787A1 WO 2017138787 A1 WO2017138787 A1 WO 2017138787A1 KR 2017001509 W KR2017001509 W KR 2017001509W WO 2017138787 A1 WO2017138787 A1 WO 2017138787A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
update
vehicle
information
module
Prior art date
Application number
PCT/KR2017/001509
Other languages
French (fr)
Korean (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 EP17750479.2A priority Critical patent/EP3416052B1/en
Priority to CN201780011103.XA priority patent/CN108701039B/en
Priority claimed from KR1020170018667A external-priority patent/KR101966626B1/en
Publication of WO2017138787A1 publication Critical patent/WO2017138787A1/en
Priority to US16/048,692 priority patent/US10768922B2/en
Priority to US16/943,061 priority patent/US11422787B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor

Definitions

  • the present invention relates to a vehicle software update method and apparatus, and more particularly, to a method and apparatus for wirelessly updating software of a vehicle electronic device more efficiently.
  • ITS Intelligent Transportation System
  • the proportion of vehicles capable of wireless communication e.g., WiFi, 3G, LTE, etc.
  • the vehicle can interact with external entities such as other vehicles or infrastructure. Communication is also becoming common.
  • ECUs electronice control units
  • the software modules inside the electronic controllers also need to be updated for reasons such as bug fixes, performance improvements, and security.
  • the update of the software module inside the electronic controller uses diagnostic communication through a wired connection between the vehicle and the diagnostic device.
  • the diagnostic communication is slow and needs to be updated, it is inconvenient to visit the place equipped with the diagnostic equipment such as a garage. There is this.
  • the present invention is to provide a method and apparatus that can more efficiently perform a software update of the on-vehicle electronic controller.
  • the present invention is directed to providing a procedure for wireless software update and a message format that can be used within the procedure.
  • the wireless software update method of the vehicle gateway receiving a first message including a software module list from at least one controller; And transmitting a second message including a software module list for each of the at least one controller to an update server, wherein the first message includes hardware version information, and the second message includes local information of the vehicle. It may include.
  • the vehicle gateway for performing a wireless software update according to an embodiment of the present invention, a wired communication module for communicating with at least one controller; A wireless communication module in communication with the update server; And receive a first message from the at least one controller via the wired communication module, the first message including a list of software modules, wherein the second message comprises a list of software modules for each of the at least one controller.
  • a processor may be configured to control transmission to the update server, wherein the first message includes hardware version information, and the second message may include local information of the vehicle.
  • the vehicle performing the wireless software update at least one controller; And a gateway for receiving a first message including a list of software modules from the at least one controller and for transmitting a second message including a list of software modules for each of the at least one controller to an update server.
  • the first message may include hardware version information
  • the second message may include regional information of the vehicle.
  • the software update of the on-vehicle electronic controller can be performed wirelessly.
  • a wireless software update procedure and a format of a message used step by step in the procedure may be defined.
  • the hardware version information of the software module and the region information of the vehicle are included in the related message, more accurate update can be performed.
  • FIG. 1 is a flowchart illustrating an example of a wireless software update process according to an embodiment of the present invention.
  • FIG. 2 is a table showing an example of a session and a message according to an embodiment of the present invention.
  • FIG 3 illustrates an example of an update software transmission process according to an embodiment of the present invention.
  • FIG. 4 illustrates an example of a diagnosis request message structure according to an embodiment of the present invention.
  • FIG. 5 illustrates an example of diagnostic request message coding according to an embodiment of the present invention.
  • FIG. 6 illustrates an example of a diagnostic report message structure according to an embodiment of the present invention.
  • FIG. 7 illustrates an example of diagnostic report message coding according to an embodiment of the present invention.
  • FIG. 8 illustrates an example of a diagnosis submission message structure according to an embodiment of the present invention.
  • FIG. 9 illustrates an example of diagnostic submission message coding according to an embodiment of the present invention.
  • FIG. 10 illustrates an example of diagnostic receipt message coding according to an embodiment of the present invention.
  • FIG 11 illustrates an example of an update confirmation request message structure according to an embodiment of the present invention.
  • FIG 13 illustrates an example of an update confirmation response message structure according to an embodiment of the present invention.
  • FIG. 15 illustrates an example of an update acknowledgment message coding providing a backup address through a codebase field according to an embodiment of the present invention
  • FIG. 16 illustrates a backup address through a codebase2 field according to an embodiment of the present invention.
  • Each of the examples of the update acknowledgment message coding provided is shown.
  • FIG. 17 illustrates an example of update notification message coding according to an embodiment of the present invention.
  • FIG 20 shows an example of an update application message structure according to an embodiment of the present invention.
  • 21 illustrates an example of update applied message coding according to an embodiment of the present invention.
  • FIG 22 illustrates an example of an update result message structure according to an embodiment of the present invention.
  • 25 illustrates an example of update report receipt message coding according to an embodiment of the present invention.
  • FIG. 1 is a flowchart illustrating an example of a wireless software update process according to an embodiment of the present invention.
  • a software supplier provides update software (update module) to an update server (S1).
  • the operating provider of the software supplier and the update server may be a vehicle manufacturer or a manufacturer of a device mounted on the vehicle or a component included therein, but the present invention is not limited to the scope of the operating agent of such a supplier or server.
  • this step is not necessarily related to the order of execution of the following processes.
  • the vehicle gateway VMG transmits a diagnostic (request) message to each controller ECU connected thereto to request a list of software (S2).
  • each controller checks the software status, generates a list of software modules, and sends them to the gateway through a diagnostic (report) message (S3).
  • the gateway transmits a list obtained from each controller to the update server through a diagnostic (submit) message to check whether there is a software update for the vehicle (S4).
  • the update server sends a diagnostic receipt (receipt) message to the gateway as a receipt confirmation for the list submitted by the gateway (S5).
  • the update server examines the state of software installed in the vehicle and determines the need for updating the electronic controllers (S6).
  • the gateway sends an update check request (update_check (request)) message to the update server to periodically check the need for updating the vehicle (S7).
  • the update server sends an update check response (update_check (response)) message including the download location information of the update module to the gateway (S8).
  • update check response update_check (response)
  • the gateway may access the download location information and download the update module (S9).
  • the gateway may inform the driver through the user interface to confirm the application of the update (S10).
  • an update (notification) message may be used.
  • an update confirmation message is transmitted to the gateway (S11).
  • the gateway may transmit an update module file to the controller and request to apply the update (S12).
  • an update (application) message may be used.
  • each controller receiving the update module file applies the update and transmits the application result to the gateway (S13).
  • an update result (updatet (result)) message may be used.
  • the gateway submits the update application result to the update server through an update report submit (update_report (submit)) message (S14).
  • the update server transmits an update report receipt (update_report (receipt)) message to the gateway in response to the update report submission message (S15). If the application of the update fails or a remaining update is found, the update server may repeat the steps S6 to S14 until the update application is successful.
  • steps S2 to S5, and steps S7 to S8 and steps S10 to S15 may be performed through message exchange in a specific format, and may be divided into a total of four sessions.
  • a table summarizing this is shown in FIG. 2.
  • FIG. 2 is a table showing an example of a session and a message according to an embodiment of the present invention.
  • a message used in an update process according to the present embodiment may be classified into a type and a subtype, and the type may correspond to a session.
  • a session according to the present embodiment may be classified into a diagnosis, an update check, an update, and an update report.
  • One session may be performed through message exchange having two or more different subtypes, and messages corresponding to one session use the same value in a sessionid field to be described later.
  • the messages exchanged between the entities at each step may be protected through a digital signature or a message authentication code (MAC) method.
  • MAC message authentication code
  • ID / password authentication biometric authentication (signature dynamics, iris scan, fingerprint recognition, voice recognition, face recognition, etc.), out-of-band verification, etc. may be applied.
  • FIG 3 illustrates an example of an update software transmission process according to an embodiment of the present invention.
  • the process shown in FIG. 3 is intended to prevent software file corruption due to an intentional or attacker's intention during the transmission of the update software, and an integrity checking method such as md5 may be used.
  • the receiving end may be an update server when the transmitting end is a provider, and the receiving end may be a gateway when the transmitting end is an update server.
  • the transmitting end generates a first hash value 1 by applying a predetermined hash algorithm operation to the updating software, and multiplexes it with the updating software to transmit to the receiving end.
  • the receiving end demultiplexes the file transmitted by the transmitting end to restore the first hash value 1 and the update software.
  • a predetermined hash algorithm operation is applied to the reconstructed update software to generate a second hash value (HASH value 2), and the second hash value is compared with the first hash value.
  • HASH value 2 second hash value
  • the receiver determines that the corresponding update software file satisfies the consistency check. If not, the receiver determines that the consistency check has failed and may request the file to be retransmitted to the transmitter.
  • the messages described below include a plurality of elements, and examples of such elements include vehicle elements and module elements.
  • vehicle element is composed of a plurality of fields (or attributes) defining information about the vehicle
  • module element is composed of a plurality of fields defining information about each software module included in at least one device included in the vehicle. do.
  • the module element includes at least one of a moduleid field, a version field, and a nextversion field.
  • the module identifier field indicates a unique identifier of the module provided by the vehicle manufacturer or the module supplier.
  • the version field indicates version information of the corresponding software module
  • the next version field indicates version information of the module on which the update is performed
  • the next version field may be mainly used to transmit a response message while performing the update.
  • the present embodiment proposes to include a hardware version (hwversion) field indicating the version information of the hardware in the module element.
  • 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.
  • the hardware version field may be included in a device element to be described later.
  • the description of this field may be a version of this hardware module.
  • the vehicle element may include at least one of a name field, a model field, a modelid field, and a vehicleid field.
  • the name field indicates the name of the vehicle
  • the model field indicates the type name of the vehicle provided by the vehicle manufacturer
  • the model identifier field indicates the model name of the vehicle
  • the vehicle identifier field indicates the identifier of the vehicle defined by the vehicle manufacturer.
  • this embodiment proposes to include a locale field indicating local information of the vehicle in the vehicle element.
  • Vehicle - Container of vehicle information contains multiple Module elements.
  • This step is substantially the start of the update process, where the vehicle gateway (VMG) will ask the controllers to submit their software list. For this purpose, a diagnostic request message can be used.
  • FIG. 4 illustrates an example of a diagnosis request message structure according to an embodiment of the present invention.
  • the diagnostic request message may include a message element, an IssuedTime element, and an ExpirationTime element.
  • 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.
  • a message element includes a protocol field, a version field, a type field, a subtype field, a session identifier field, a trustlevel field, and a message identifier. It may include at least one of the (messageid) field.
  • the protocol field may be set to a fixed value (eg, 1.0), and the version field indicates version information of the message sender.
  • the type field may always be set to "diagnose” and the subtype field may always be set to "request”.
  • the session identifier field is set to a random Globally Unique ID (GUID) for a diagnostic session, and the same value is applied to all of the diagnostic request, diagnostic report, and diagnostic submission message corresponding to one diagnostic session.
  • the confidence level field is determined based on the security capabilities and security requirements of the device generating this message.
  • the message identifier field is set to a random GUID for an individual message.
  • the issue time element indicates the creation time of the message and the expiration time element indicates the expiration time of the message.
  • FIG. 5 illustrates an example of diagnostic request message coding according to an embodiment of the present invention.
  • each controller checks its software status, generates a list of software modules, and sends them to the gateway. For this purpose a diagnostic (report) message can be used.
  • FIG. 6 illustrates an example of a diagnostic report message structure according to an embodiment of the present invention.
  • the diagnostic report message may include at least one device element in addition to the aforementioned message element, issuedTime element, and expiration time element.
  • the device element may again comprise one or more module elements, and each module element may comprise a hash element.
  • Hash - Hash is a container of a hash value and information of its hash algorithm.
  • algorithm Algorithm of the hash function (eg, SHA-3, SHA-256, etc.) IssuedTime - Time of generation of this message. ExpirationTime - Expiration time of this message.
  • the type field of the message element may always be set to "diagnose”, and the subtype field may always be set to "report”.
  • the message element may further include an owner identifier field indicating an owner ID provided from a vehicle manufacturer or a supplier.
  • the device element may include at least one of a name field, a type field, a model field, and a deviceid, and according to an embodiment, the hardware version field may be different from the table 4 according to an embodiment. It can also contain more elements instead.
  • the name field may indicate the name of the device
  • the type field may indicate a type name of the corresponding device, such as "Power management ECU" and "Seat belt control ECU”.
  • the model field indicates the model name of the device
  • the device identifier field indicates the identifier information of the device defined by the vehicle manufacturer / supplier, respectively.
  • the hash element represents the hash value for each module and information about the hash algorithm used.
  • FIG. 7 illustrates an example of diagnostic report message coding according to an embodiment of the present invention.
  • the gateway sends a list obtained from each controller to the update server to check whether there is a software update for the vehicle.
  • a diagnostic (submit) message can be used for this.
  • FIG. 8 illustrates an example of a diagnosis submission message structure according to an embodiment of the present invention.
  • the structure of the diagnosis submission message is similar to that of the diagnosis report message shown in FIG. 6, but further includes a vehicle element.
  • 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.
  • deviceid Device id defined by a car manufacture / supplier.
  • moduleid Module id is a unique id provided by a car manufacture / a supplier. version Version of this software module.
  • Hash - Hash is a container of a hash value and information of its hash algorithm.
  • algorithm Algorithm of the hash function (eg, SHA-3, SHA-256, etc.) IssuedTime - Time of generation of this message. ExpirationTime - Expiration time of this message.
  • the type field of the message element may be always set to "diagnose”, and the subtype field may be always set to "submit”.
  • the vehicle element may include a regional field, and may optionally further include a modelyear field indicating the year of manufacture of the vehicle.
  • FIG. 9 illustrates an example of diagnostic submission message coding according to an embodiment of the present invention.
  • the update server sends a diagnostic (receipt) message to the gateway as a receipt confirmation for the list submitted by the gateway. This allows the gateway to recognize that list submission is successful.
  • the update server sends this message to the gateway without checking for possible updates for each software module. Therefore, the message does not include information on whether to update each software module, so the vehicle, device and module elements are unnecessary. For this reason, the message may have a form as shown in FIG. Instead, a status field indicating whether the diagnosis submission message has been successfully received may be included in the message element.
  • a status field indicating whether the diagnosis submission message has been successfully received may be included in the message element.
  • Table 6 An example of the configuration of a message element including a status field is shown in Table 6 below.
  • 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 Acknowledgment of report for diagnose (submit)
  • the type field of the message element may always be set to "diagnose”, and the subtype field may always be set to "receipt”.
  • the status field may be set to "yes" when the diagnostic submission message is successfully received.
  • FIG. 10 illustrates an example of diagnostic receipt message coding according to an embodiment of the present invention.
  • the update server examines the status of software installed in the vehicle and determines the need for updating the electronic controllers.
  • Update check request (S7): update_check (request)
  • step S6 Since the investigation in step S6 may take a long time, it is preferable that the gateway periodically checks the update server for the need for updating the vehicle. To this end, an update check request (update_check (request)) message may be used.
  • FIG. 11 illustrates an example of an update confirmation request message structure according to an embodiment of the present invention.
  • the structure of the update confirmation request message may be similar to that of the diagnosis submission message shown in FIG. 8, but the hash element for each module may be omitted.
  • 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.
  • deviceid Device id defined by a car manufacture / supplier.
  • moduleid Module id is a unique id provided by a car manufacture / a supplier. version Version of this software module.
  • the type field of the message element may always be set to "update_check” and the subtype field may be always set to "request” in the update check request message.
  • the session identifier field of the message element is set to a random GUID (Globally Unique ID) for the update confirmation session, and the same value is applied to both the update confirmation request and the update confirmation response message corresponding to one update confirmation session.
  • the hardware version field of the module element may be included in the device element instead of the module element.
  • FIG. 12 illustrates an example of update confirmation request message coding according to an embodiment of the present invention.
  • Update check response (S8): update_check (response)
  • the update server provides the gateway with download location information (eg, Uniform Resource Locator) of the update module.
  • download location information eg, Uniform Resource Locator
  • an update_check (response) message may be used.
  • FIG. 13 illustrates an example of an update confirmation response message structure according to an embodiment of the present invention.
  • the basic structure of the update confirmation response message is similar to that of the update confirmation request message shown in FIG. 11, but includes a URLs element and a manifest element as sub-elements of the module element.
  • Table 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.
  • deviceid Device id defined by a car manufacture / supplier.
  • 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.
  • 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.
  • 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 (eg, 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.
  • the type field of the message element may always be set to "update_check”, and the subtype field may always be set to "response”.
  • the module element includes a status field, and the status field may be set to "noupdate” if there is no update for the corresponding module as a result of the update investigation, and to "ok” if there is an update.
  • the URLs element is a lower element of the module element and indicates the address of the update file when there is an update.
  • the actual address is included in the codebase field of the URL element, its subelement. If two update file addresses for the module are prepared, one URL element may include two codebase fields, and one codebase field and one codebase2 field may be used. This will be described later in more detail.
  • the manifest element describes the action to be performed on the module and files to be installed and includes a version field indicating the specific new version number of the software module.
  • the manifest element contains a Packages element that represents information about the set of files to be installed as its subelements, and the Pakages element contains the Package and Actions elements as its subelements.
  • the Package element indicates information on individual files to be installed in the module, and includes a name field indicating a file name and a size field indicating a file size in bytes.
  • the Package element in turn, contains a hash element as its child element.
  • the Actions element indicates information about the action to be performed to install the module when all necessary files defined in the Packages element have been successfully downloaded.
  • the Actions element contains the Action element as a child element.
  • the Action element represents information about individual actions performed as part of the installation process, and includes an event field indicating one of four preset actions and an argument field indicating an argument to be passed to the installation process. .
  • FIG. 14 illustrates an example of update confirmation response message coding according to an embodiment of the present invention.
  • the update confirmation request / response message may be exchanged several times during the update investigation of the update server, and may be exposed to a playback attack in this process. Therefore, it is desirable to ensure accurate matching of the update confirmation request message and the update confirmation response message.
  • a nonce element may be applied to the message.
  • the update confirmation response message may include a nonce element indicating a random generation code for the nonce technique.
  • the update confirmation response message includes URL link information from which the gateway can download the update software module.
  • the update server is temporarily / permanently down due to a denial of service (DoS) attack or hardware problem (such as NIC or disk damage), or 2) a validation problem of the update software module is a virus infection. For example, file corruption, or excessive traffic due to multiple simultaneous connections to the update server.
  • DoS denial of service
  • NIC disk damage
  • a validation problem of the update software module is a virus infection. For example, file corruption, or excessive traffic due to multiple simultaneous connections to the update server.
  • a backup URL link address be provided via an update confirmation response message.
  • a method of providing backup URL information to one using two codebase fields and a method of providing backup URL information using a codebase2 field may be considered. Each case is shown in FIGS. 15 and 16.
  • FIG. 15 illustrates an example of an update acknowledgment message coding providing a backup address through a codebase field according to an embodiment of the present invention
  • FIG. 16 illustrates a backup address through a codebase2 field according to an embodiment of the present invention.
  • Each of the examples of the update acknowledgment message coding provided is shown.
  • each URL element includes one codebase field.
  • the codebase field of the first URL element includes default URL address information
  • the codebase field of the second URL element includes backup URL address information.
  • the URL element includes a codebase field and a codebase2 field.
  • the codebase field includes default URL address information
  • the codebase2 field includes backup URL address information.
  • the backup URL information may be an address of another folder of the same server or may be an address of another server. In the case of other folders on the same server, it can cope with the cause of corruption or disk corruption of the file, and in the case of other servers, it can cope with traffic load problems or connection failures of the original server.
  • Download update software (S9): download update S / W
  • the gateway may access the download location (URL / Backup URL) information and download the update module.
  • the gateway may inform the driver through the user interface to confirm the application of the update (S10).
  • an update (notification) message may be used.
  • the element structure of the update confirmation request message is itself similar to the update confirmation response message structure shown in FIG. 13 described above. However, since a general driver may want a brief description of the update software, information about the update software may be included in the message so that the description of the update software may be output through the user interface.
  • 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 is a Module element where its status is ok.
  • 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.
  • the type field of the message element may always be set to "update”, and the subtype field may always be set to "notification”.
  • the session identifier field is set to a random globally unique ID (GUID) for an update session.
  • GUID globally unique ID
  • the Package element may include a description field indicating a description of the update module.
  • FIG. 17 illustrates an example of update notification message coding according to an embodiment of the present invention.
  • the description field may include text information describing a corresponding software module.
  • the description field may include a URL address including corresponding information instead of the text itself.
  • the Package element may include the descriptionurl field instead of the description field.
  • Packages - A set of files needed to be installed. Contains no attribution. Contains one or more Package child elements.
  • FIG. 18 illustrates another example of updating notification message coding according to an embodiment of the present invention.
  • an update confirm message is sent to the gateway.
  • the structure of the update confirm message is similar to that of the diagnostic request message shown in FIG. 4, and an example of the format is shown in Table 12 below.
  • the type field of the message element may be always set to "update”, and the subtype field may be always set to "confirmation”.
  • the message element includes a status field indicating whether to accept the update application.
  • the status field may be set to "Yes” or “ok” if the driver accepts the update application, or "no” otherwise.
  • FIG. 19 illustrates an example of update confirm message coding according to an embodiment of the present invention.
  • the gateway may send an update module file to the controller and request to apply the update.
  • an update (application) message may be used.
  • FIG. 20 shows an example of an update application message structure according to an embodiment of the present invention.
  • the update application message is a message transmitted from an gateway to an individual controller, there is no vehicle element and includes a device element corresponding to the controller, and includes a module element as a lower element.
  • the module element again contains a manifest element, and the manifest element contains a Packages element.
  • Table 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.
  • 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.
  • 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 (eg, 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.
  • the type field of the message element may always be set to "update”, and the subtype field may always be set to "application”.
  • the package element includes a target element representing the update module as encoded binary data, and an encoding scheme may be indicated through an encode field.
  • FIG. 21 illustrates an example of update applied message coding according to an embodiment of the present invention.
  • Each controller receiving the update module file applies the update and sends the application result to the gateway.
  • an update result (updatet (result)) message may be used.
  • FIG. 22 illustrates an example of an update result message structure according to an embodiment of the present invention.
  • the update result message is a message transmitted from an individual controller to a gateway, there is no vehicle element and includes a device element corresponding to the controller, and includes a module element as a lower element.
  • 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.
  • the type field of the message element may always be set to "update”, and the subtype field may always be set to "result”.
  • the package element includes a target element representing the update module as encoded binary data, and an encoding scheme may be indicated through an encode field.
  • FIG. 23 illustrates an example of update result message coding according to an embodiment of the present invention.
  • the gateway submits the update application result to the update server through an update_report (submit) message.
  • the structure of the update report submission message is similar to that of the diagnosis submission message shown in FIG. 8, and an example of the format thereof is shown in Table 15 below.
  • Table 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.
  • deviceid Device id defined by a car manufacture / supplier.
  • moduleid Module id is a unique id provided by a car manufacture / a supplier. version Version of this software module.
  • Hash - Hash is a container of a hash value and information of its hash algorithm.
  • algorithm Algorithm of the hash function (eg, SHA-3, SHA-256, etc.) IssuedTime - Time of generation of this message. ExpirationTime - Expiration time of this message.
  • the type field of the message element may always be set to "update_report", and the subtype field may always be set to "submit”.
  • the module element of the update report submission message includes a status field, and the result of applying the update of the corresponding module may be indicated through this field.
  • FIG. 24 illustrates an example of update report submission message coding according to an embodiment of the present invention.
  • the update server sends an update report receipt (update_report (receipt)) message to the gateway in response to the update report submission message.
  • the structure of the update report receipt message is similar to that of the update confirmation request message shown in FIG. 11, and an example of the format thereof is shown in Table 16 below.
  • deviceid Device id defined by a car manufacture / supplier.
  • moduleid Module id is a unique id provided by a car manufacture / a supplier. version Version of this software module.
  • the type field of the message element may always be set to "update_report", and the subtype field may always be set to "receipt”.
  • the module element of the update report receipt message includes a status field, and this field may indicate whether the corresponding module reports ACK (Acknowledgement).
  • FIG. 25 illustrates an example of update report receipt message coding according to an embodiment of the present invention.
  • the gateway according to the present embodiment may include at least a wired communication unit, a wireless communication unit, a memory, and a processor (not shown).
  • the wired communication unit provides a communication function with controllers connected to the gateway to perform a diagnostic session and an update session.
  • Wired communication may follow at least one of CAN (Controller Area Network), Ethernet, and LIN protocols, but is not necessarily limited thereto.
  • the wireless communication unit provides a wireless communication function with the update server and may be connected to the update server via a wireless base station or a telematics center.
  • the memory may store a program for processing and controlling the processor, and may perform a function for temporarily storing input / output data.
  • the processor typically controls the overall operation of the gateway component.
  • the above-described embodiments of the present invention for example, a controller function, a message generation and interpretation function, an authentication and encryption function, etc. for performing steps S2 to S14 may be performed.
  • the vehicle according to the present embodiment may include the above-described gateway and at least one controller connected thereto.
  • the present invention described above can be embodied as computer readable codes on a medium in which a program is recorded.
  • the computer-readable medium includes all kinds of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable media include hard disk drives (HDDs), solid state disks (SSDs), silicon disk drives (SDDs), ROMs, RAMs, CD-ROMs, magnetic tapes, floppy disks, optical data storage devices, and the like. There is this.
  • a procedure of wireless update of an on-vehicle electronic controller may be defined, and the defined procedure may be applied to a vehicle gateway, various electronic controllers connected to the gateway, and an update software server.
  • the wireless software update procedure and the format of the message used step by step in the procedure can be defined.
  • the hardware version information of the software module and the region information of the vehicle are included in the related message, more accurate update can be performed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

The present invention relates to a method and a device for wirelessly updating software for a vehicle and, more specifically, to a method and a device for wirelessly updating software of an electronic device for a vehicle with higher efficiency. A method for wirelessly updating software of a gateway for a vehicle, according to one embodiment of the present invention, comprises the steps of: receiving a first message comprising a software module list from at least one controller; and transmitting, to an update server, a second message comprising a software module list with respect to each of the at least one controller, wherein the first message comprises hardware version information, and the second message may comprise region information of the vehicle.

Description

차량용 무선 소프트웨어 업데이트 방법 및 장치Vehicle wireless software update method and device
본 발명은 차량용 소프트웨어 업데이트 방법 및 장치에 관한 것으로, 보다 상세히는 보다 효율적으로 차량용 전자 장치의 소프트웨어를 무선으로 업데이트하기 위한 방법 및 장치에 관한 것이다.The present invention relates to a vehicle software update method and apparatus, and more particularly, to a method and apparatus for wirelessly updating software of a vehicle electronic device more efficiently.
지능형 운송 시스템(ITS: Intelligent Transportation System)이 발전하고, 무선 통신(예를 들어, WiFi, 3G, LTE 등)이 가능한 차량의 비율이 증가함에 따라, 차량에서 다른 차량이나 인프라와 같은 외부 개체와의 통신도 보편화되고 있다. As the Intelligent Transportation System (ITS) evolves and the proportion of vehicles capable of wireless communication (e.g., WiFi, 3G, LTE, etc.) increases, the vehicle can interact with external entities such as other vehicles or infrastructure. Communication is also becoming common.
또한, 차량에 전자 제어기(ECU: Electronic Control Units)의 숫자도 증가하고 있는 추세이다. 이러한 전자 제어기의 구조 및 기능이 점점 복잡해짐에 따라, 해당 전자 제어기 내부의 소프트웨어 모듈 또한 버그 픽스, 성능 향상, 보안성 향상 등의 이유로 업데이트될 필요가 있다.In addition, the number of electronic control units (ECUs) in vehicles is increasing. As the structure and function of such electronic controllers become more complicated, the software modules inside the electronic controllers also need to be updated for reasons such as bug fixes, performance improvements, and security.
일반적으로 전자 제어기 내부의 소프트웨어 모듈의 업데이트는 차량과 진단기 간의 유선 연결을 통한 진단 통신을 이용하나, 진단 통신의 속도가 느리고 업데이트가 필요할 때마다 정비소 등 진단기 장비가 구비된 장소에 방문해야 하는 불편함이 있다.In general, the update of the software module inside the electronic controller uses diagnostic communication through a wired connection between the vehicle and the diagnostic device. However, when the diagnostic communication is slow and needs to be updated, it is inconvenient to visit the place equipped with the diagnostic equipment such as a garage. There is this.
본 발명은 보다 효율적으로 차량용 전자 제어기의 소프트웨어 업데이트를 무선으로 수행할 수 있는 방법 및 장치를 제공하기 위한 것이다.The present invention is to provide a method and apparatus that can more efficiently perform a software update of the on-vehicle electronic controller.
특히, 본 발명은 무선 소프트웨어 업데이트를 위한 절차와, 절차 내에서 사용될 수 있는 메시지 포맷을 제공하기 위한 것이다.In particular, the present invention is directed to providing a procedure for wireless software update and a message format that can be used within the procedure.
본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.The technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned above will be clearly understood by those skilled in the art from the following description. Could be.
상기와 같은 기술적 과제를 해결하기 위하여, 본 발명의 일 실시예에 따른 차량용 게이트웨이의 무선 소프트웨어 업데이트 방법은, 적어도 하나의 제어기로부터 소프트웨어 모듈 리스트를 포함하는 제 1 메시지를 수신하는 단계; 및 상기 적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 포함하는 제 2 메시지를 업데이트 서버로 전송하는 단계를 포함하되, 상기 제 1 메시지는 하드웨어 버전 정보를 포함하고, 상기 제 2 메시지는 차량의 지역정보를 포함할 수 있다.In order to solve the above technical problem, the wireless software update method of the vehicle gateway according to an embodiment of the present invention, receiving a first message including a software module list from at least one controller; And transmitting a second message including a software module list for each of the at least one controller to an update server, wherein the first message includes hardware version information, and the second message includes local information of the vehicle. It may include.
또한, 본 발명의 일 실시예에 따른 무선 소프트웨어 업데이트를 수행하는 차량용 게이트웨이는, 적어도 하나의 제어기와 통신하는 유선 통신 모듈; 업데이트 서버와 통신하는 무선 통신 모듈; 및 상기 유선 통신 모듈을 통해 상기 적어도 하나의 제어기로부터 소프트웨어 모듈 리스트를 포함하는 제 1 메시지를 수신하고, 상기 적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 포함하는 제 2 메시지가 상기 무선 통신 모듈을 통해 상기 업데이트 서버로 전송되도록 제어하는 프로세서를 포함하되, 상기 제 1 메시지는 하드웨어 버전 정보를 포함하고, 상기 제 2 메시지는 차량의 지역정보를 포함할 수 있다.In addition, the vehicle gateway for performing a wireless software update according to an embodiment of the present invention, a wired communication module for communicating with at least one controller; A wireless communication module in communication with the update server; And receive a first message from the at least one controller via the wired communication module, the first message including a list of software modules, wherein the second message comprises a list of software modules for each of the at least one controller. A processor may be configured to control transmission to the update server, wherein the first message includes hardware version information, and the second message may include local information of the vehicle.
아울러, 본 발명의 일 실시예에 따른 무선 소프트웨어 업데이트를 수행하는 차량은, 적어도 하나의 제어기; 및 상기 적어도 하나의 제어기로부터 소프트웨어 모듈 리스트를 포함하는 제 1 메시지를 수신하고, 상기 적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 포함하는 제 2 메시지를 업데이트 서버로 전송하는 게이트웨이를 포함하되, 상기 제 1 메시지는 하드웨어 버전 정보를 포함하고, 상기 제 2 메시지는 차량의 지역정보를 포함할 수 있다.In addition, the vehicle performing the wireless software update according to an embodiment of the present invention, at least one controller; And a gateway for receiving a first message including a list of software modules from the at least one controller and for transmitting a second message including a list of software modules for each of the at least one controller to an update server. The first message may include hardware version information, and the second message may include regional information of the vehicle.
상기와 같이 구성되는 본 발명의 적어도 하나의 실시예에 따르면 보다 효율적으로 차량용 전자 제어기의 소프트웨어 업데이트가 무선으로 수행될 수 있다.According to at least one embodiment of the present invention configured as described above, the software update of the on-vehicle electronic controller can be performed wirelessly.
또한, 무선 소프트웨어 업데이트 절차 및 해당 절차에서 단계별로 사용되는 메시지의 포맷이 정의될 수 있다. 특히, 소프트웨어 모듈의 하드웨어 버전 정보와 차량의 지역 정보가 관련 메시지에 포함되므로, 보다 정확한 업데이트가 수행될 수 있다.In addition, a wireless software update procedure and a format of a message used step by step in the procedure may be defined. In particular, since the hardware version information of the software module and the region information of the vehicle are included in the related message, more accurate update can be performed.
본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.The effects obtainable in the present invention are not limited to the above-mentioned effects, and other effects not mentioned above may be clearly understood by those skilled in the art from the following description. will be.
도 1은 본 발명의 일 실시예에 따른 무선 소프트웨어 업데이트 과정의 일례를 나타내는 순서도이다.1 is a flowchart illustrating an example of a wireless software update process according to an embodiment of the present invention.
도 2는 본 발명의 일 실시예에 따른 세션 및 그에 따른 메시지의 일례를 나타낸 표이다.2 is a table showing an example of a session and a message according to an embodiment of the present invention.
도 3은 본 발명의 일 실시예에 따른 업데이트 소프트웨어 전송 과정의 일례를 나타낸다.3 illustrates an example of an update software transmission process according to an embodiment of the present invention.
도 4는 본 발명의 일 실시예에 따른 진단 요청 메시지 구조의 일례를 나타낸다.4 illustrates an example of a diagnosis request message structure according to an embodiment of the present invention.
도 5는 본 발명의 일 실시예에 따른 진단 요청 메시지 코딩의 일례를 나타낸다.5 illustrates an example of diagnostic request message coding according to an embodiment of the present invention.
도 6은 본 발명의 일 실시예에 따른 진단 보고 메시지 구조의 일례를 나타낸다.6 illustrates an example of a diagnostic report message structure according to an embodiment of the present invention.
도 7은 본 발명의 일 실시예에 따른 진단 보고 메시지 코딩의 일례를 나타낸다.7 illustrates an example of diagnostic report message coding according to an embodiment of the present invention.
도 8은 본 발명의 일 실시예에 따른 진단 제출 메시지 구조의 일례를 나타낸다.8 illustrates an example of a diagnosis submission message structure according to an embodiment of the present invention.
도 9는 본 발명의 일 실시예에 따른 진단 제출 메시지 코딩의 일례를 나타낸다.9 illustrates an example of diagnostic submission message coding according to an embodiment of the present invention.
도 10은 본 발명의 일 실시예에 따른 진단 영수 메시지 코딩의 일례를 나타낸다.10 illustrates an example of diagnostic receipt message coding according to an embodiment of the present invention.
도 11은 본 발명의 일 실시예에 따른 업데이트 확인 요청 메시지 구조의 일례를 나타낸다.11 illustrates an example of an update confirmation request message structure according to an embodiment of the present invention.
도 12는 본 발명의 일 실시예에 따른 업데이트 확인 요청 메시지 코딩의 일례를 나타낸다.12 illustrates an example of update confirmation request message coding according to an embodiment of the present invention.
도 13은 본 발명의 일 실시예에 따른 업데이트 확인 응답 메시지 구조의 일례를 나타낸다.13 illustrates an example of an update confirmation response message structure according to an embodiment of the present invention.
도 14는 본 발명의 일 실시예에 따른 업데이트 확인 응답 메시지 코딩의 일례를 나타낸다.14 illustrates an example of update confirmation response message coding according to an embodiment of the present invention.
도 15는 본 발명의 일 실시예에 따른 코드베이스 필드를 통해 백업 주소를 제공하는 업데이트 확인 응답 메시지 코딩의 일례를, 도 16은 본 발명의 일 실시예에 따른 코드베이스2 필드를 통해 백업 주소를 제공하는 업데이트 확인 응답 메시지 코딩의 일례를 각각 나타낸다.15 illustrates an example of an update acknowledgment message coding providing a backup address through a codebase field according to an embodiment of the present invention, and FIG. 16 illustrates a backup address through a codebase2 field according to an embodiment of the present invention. Each of the examples of the update acknowledgment message coding provided is shown.
도 17은 본 발명의 일 실시예에 따른 업데이트 알림 메시지 코딩의 일례를 나타낸다.17 illustrates an example of update notification message coding according to an embodiment of the present invention.
도 18은 본 발명의 일 실시예에 따른 업데이트 알림 메시지 코딩의 다른 일례를 나타낸다.18 illustrates another example of updating notification message coding according to an embodiment of the present invention.
도 19는 본 발명의 일 실시예에 따른 업데이트 컨펌 메시지 코딩의 일례를 나타낸다. 19 illustrates an example of update confirm message coding according to an embodiment of the present invention.
도 20은 본 발명의 일 실시예에 따른 업데이트 적용 메시지 구조의 일례를 나타낸다.20 shows an example of an update application message structure according to an embodiment of the present invention.
도 21은 본 발명의 일 실시예에 따른 업데이트 적용 메시지 코딩의 일례를 나타낸다. 21 illustrates an example of update applied message coding according to an embodiment of the present invention.
도 22는 본 발명의 일 실시예에 따른 업데이트 결과 메시지 구조의 일례를 나타낸다.22 illustrates an example of an update result message structure according to an embodiment of the present invention.
도 23은 본 발명의 일 실시예에 따른 업데이트 결과 메시지 코딩의 일례를 나타낸다. 23 illustrates an example of update result message coding according to an embodiment of the present invention.
도 24는 본 발명의 일 실시예에 따른 업데이트 보고 제출 메시지 코딩의 일례를 나타낸다. 24 illustrates an example of update report submission message coding according to an embodiment of the present invention.
도 25는 본 발명의 일 실시예에 따른 업데이트 보고 영수 메시지 코딩의 일례를 나타낸다.25 illustrates an example of update report receipt message coding according to an embodiment of the present invention.
아래에서는 첨부한 도면을 참고로 하여 본 발명의 실시 예에 대하여 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 발명은 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다. 그리고 도면에서 본 발명을 명확하게 설명하기 위해서 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present invention. As those skilled in the art would realize, the described embodiments may be modified in various different ways, all without departing from the spirit or scope of the present invention. In the drawings, parts irrelevant to the description are omitted in order to clearly describe the present invention, and like reference numerals designate like parts throughout the specification.
명세서 전체에서, 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성 요소를 더 포함할 수 있는 것을 의미한다. 또한, 명세서 전체에 걸쳐서 동일한 참조번호로 표시된 부분들은 동일한 구성요소들을 의미한다.Throughout the specification, when a part is said to "include" a certain component, it means that it can further include other components, without excluding other components unless specifically stated otherwise. In addition, parts denoted by the same reference numerals throughout the specification means the same components.
도 1은 본 발명의 일 실시예에 따른 무선 소프트웨어 업데이트 과정의 일례를 나타내는 순서도이다.1 is a flowchart illustrating an example of a wireless software update process according to an embodiment of the present invention.
도 1을 참조하면, 먼저 소프트웨어 공급자(supplier)가 업데이트 서버(update server)로 업데이트 소프트웨어(업데이트 모듈)를 제공한다(S1). 여기서 소프트웨어 공급자 및 업데이트 서버의 운영주체는 차량 제조사일 수도 있고, 차량에 장착되는 디바이스 또는 그에 포함되는 부품의 제조사일 수 있으나, 본 발명은 이러한 공급자나 서버의 운영주체의 범위에 한정되지 아니한다. 또한, 본 단계는 이하의 과정들의 수행 순서와 반드시 선후 관계를 가지지는 아니한다.Referring to FIG. 1, first, a software supplier provides update software (update module) to an update server (S1). Here, the operating provider of the software supplier and the update server may be a vehicle manufacturer or a manufacturer of a device mounted on the vehicle or a component included therein, but the present invention is not limited to the scope of the operating agent of such a supplier or server. In addition, this step is not necessarily related to the order of execution of the following processes.
차량 게이트웨이(VMG)는 그에 연결된 각 제어기(ECU)에 소프트웨어 리스트를 요청하기 위해 진단 요청(diagnose (request)) 메시지를 전송한다(S2). The vehicle gateway VMG transmits a diagnostic (request) message to each controller ECU connected thereto to request a list of software (S2).
진단 요청 메시지에 대한 응답으로, 각 제어기는 소프트웨어 상태를 체크하고, 소프트웨어 모듈 리스트를 생성하여 이를 게이트웨이로 게이트웨이로 진단 보고(diagnose (report)) 메시지를 통해 전송한다(S3).In response to the diagnostic request message, each controller checks the software status, generates a list of software modules, and sends them to the gateway through a diagnostic (report) message (S3).
그에 따라, 게이트웨이는 해당 차량에 대한 소프트웨어 업데이트가 있는지 여부를 확인하기 위해 각 제어기로부터 획득한 리스트를 업데이트 서버로 진단 제출(diagnose (submit)) 메시지를 통해 전송한다(S4).Accordingly, the gateway transmits a list obtained from each controller to the update server through a diagnostic (submit) message to check whether there is a software update for the vehicle (S4).
업데이트 서버는 게이트웨이가 제출한 리스트에 대한 영수 확인으로, 게이트웨이에 진단 영수(diagnose (receipt)) 메시지를 전송한다(S5).The update server sends a diagnostic receipt (receipt) message to the gateway as a receipt confirmation for the list submitted by the gateway (S5).
리스트에 따라, 업데이트 서버는 해당 차량에 설치된 소프트웨어의 상태를 조사하고, 전자 제어기들에 대한 업데이트 필요성을 결정한다(S6).According to the list, the update server examines the state of software installed in the vehicle and determines the need for updating the electronic controllers (S6).
이러한 조사에는 긴 시간이 소요될 수 있기 때문에, 게이트웨이는 해당 차량에 대한 업데이트 필요성을 주기적으로 확인하기 위해 업데이트 확인 요청(update_check (request)) 메시지를 업데이트 서버로 전송한다(S7).Since such a survey may take a long time, the gateway sends an update check request (update_check (request)) message to the update server to periodically check the need for updating the vehicle (S7).
업데이트가 있는 경우, 업데이트 서버는 업데이트 모듈의 다운로드 위치 정보를 포함하는 업데이트 확인 응답(update_check (response)) 메시지를 게이트웨이로 전송한다(S8).If there is an update, the update server sends an update check response (update_check (response)) message including the download location information of the update module to the gateway (S8).
업데이트가 있는 경우, 게이트웨이는 다운로드 위치 정보로 접속하여 업데이트 모듈을 다운로드할 수 있다(S9).If there is an update, the gateway may access the download location information and download the update module (S9).
게이트웨이는 업데이트를 각 제어기에 적용하기 전에, 업데이트 적용을 확인받기 위해 사용자 인터페이스를 통해 운전자에 알릴 수 있다(S10). 이를 위해 업데이트 알림(update (notification)) 메시지가 사용될 수 있다.Before applying the update to each controller, the gateway may inform the driver through the user interface to confirm the application of the update (S10). For this purpose, an update (notification) message may be used.
운전자가 업데이트 적용을 확인하고 수락하면, 업데이트 컨펌(update (confirm)) 메시지가 게이트웨이로 전송된다(S11).If the driver confirms and accepts the update application, an update confirmation message is transmitted to the gateway (S11).
운전자의 수락에 따라, 게이트웨이는 업데이트 모듈 파일을 해당 제어기로 전송하고, 업데이트를 적용할 것을 요청할 수 있다(S12). 이를 위해 업데이트 적용(update (application)) 메시지가 사용될 수 있다.According to the driver's acceptance, the gateway may transmit an update module file to the controller and request to apply the update (S12). For this purpose, an update (application) message may be used.
그에 따라, 업데이트 모듈 파일을 수신한 각 제어기는 업데이트를 적용하고, 적용 결과를 게이트웨이로 전송한다(S13). 이를 위해 업데이트 결과(updatet (result)) 메시지가 사용될 수 있다.Accordingly, each controller receiving the update module file applies the update and transmits the application result to the gateway (S13). To this end, an update result (updatet (result)) message may be used.
게이트웨이는 업데이트 적용 결과를 업데이트 보고 제출(update_report (submit)) 메세지를 통해 업데이트 서버로 제출한다(S14).The gateway submits the update application result to the update server through an update report submit (update_report (submit)) message (S14).
업데이트 서버는 업데이트 보고 제출 메시지에 대한 응답으로, 업데이트 보고 영수(update_report (receipt)) 메시지를 게이트웨이로 전송한다(S15). 만일, 업데이트의 적용이 실패하거나 남아있는 업데이트가 발견된 경우, 업데이트 서버는 S6 단계부터 S14 단계를 업데이트 적용이 성공할 때까지 반복할 수 있다.The update server transmits an update report receipt (update_report (receipt)) message to the gateway in response to the update report submission message (S15). If the application of the update fails or a remaining update is found, the update server may repeat the steps S6 to S14 until the update application is successful.
전술한 단계들 중, S2 단계 내지 S5, 및 S7 단계 내지 S8 단계 및 S10단계 내지 S15 단계는 특정 포맷의 메시지 교환을 통해 수행되며, 총 내 개의 세션으로 구분될 수 있다. 이를 정리한 표가 도 2에 도시된다.Among the above-described steps, steps S2 to S5, and steps S7 to S8 and steps S10 to S15 may be performed through message exchange in a specific format, and may be divided into a total of four sessions. A table summarizing this is shown in FIG. 2.
도 2는 본 발명의 일 실시예에 따른 세션 및 그에 따른 메시지의 일례를 나타낸 표이다.2 is a table showing an example of a session and a message according to an embodiment of the present invention.
도 2를 참조하면, 본 실시예에 따른 업데이트 과정에 사용되는 메시지는 타입과 서브 타입으로 구분될 수 있으며, 타입은 세션에 대응될 수 있다. 보다 상세히, 본 실시예에 따른 세션은 진단(diagnose), 업데이트 확인(update_check), 업데이트(update) 및 업데이트 보고(update_report)로 분류될 수 있다. 하나의 세션은 두 개 이상의 서로 다른 서브 타입을 갖는 메시지 교환을 통해 수행될 수 있으며, 하나의 세션에 해당하는 메시지들은 후술할 세션식별자(sessionid) 필드에 동일한 값을 사용한다. Referring to FIG. 2, a message used in an update process according to the present embodiment may be classified into a type and a subtype, and the type may correspond to a session. In more detail, a session according to the present embodiment may be classified into a diagnosis, an update check, an update, and an update report. One session may be performed through message exchange having two or more different subtypes, and messages corresponding to one session use the same value in a sessionid field to be described later.
도 2에서 메시지의 송수신 주체로 기재된 Usvr 및 U/I는 업데이트 서버 및 사용자 인터페이스(user interface)를 각각 나타내며, 각 메시지에 대한 전송단/수신단 및 목적은 전술한 바와 같으므로, 명세서의 간명함을 위해 중복되는 기재는 생략하기로 한다.Usvr and U / I described in FIG. Duplicate descriptions will be omitted.
한편, 각 단계에서 개체들 간에 교환되는 메시지는 디지털 서명이나 메시지 인증 코드(MAC: Message Authentication Code) 방식 등을 통해 보호될 수 있다. 이러한 방식 외에도, ID/패스워드 인증, 생체 인증(시그니쳐 다이내믹스, 홍채 스캔, 지문 인식, 음성 인식, 얼굴 인식 등), 아웃 오브 밴드 인증(Out-of-band verification) 방법 등도 적용될 수 있다. On the other hand, the messages exchanged between the entities at each step may be protected through a digital signature or a message authentication code (MAC) method. In addition to this method, ID / password authentication, biometric authentication (signature dynamics, iris scan, fingerprint recognition, voice recognition, face recognition, etc.), out-of-band verification, etc. may be applied.
다음으로, 각 단계를 상세히 설명하기 앞서, 개체별로 파일 전송이 수행되는 경우 정합성 확인(integrity check) 절차를 도 3을 참조하여 설명한다.Next, before describing each step in detail, an integrity check procedure when a file transfer is performed for each object will be described with reference to FIG. 3.
도 3은 본 발명의 일 실시예에 따른 업데이트 소프트웨어 전송 과정의 일례를 나타낸다.3 illustrates an example of an update software transmission process according to an embodiment of the present invention.
도 3에 도시된 과정은 업데이트 소프트웨어의 전송 과정에서 우발적으로, 또는 공격자의 의도에 따른 소프트웨어 파일 손상(corruption)을 방지하기 위한 것으로, md5와 같은 정합성 확인 방법(integrity checking method)이 사용될 수 있다. 업데이트 소프트웨어의 전송 과정을 송신단(Transmitting End)과 수신단(Receiving End) 관점에서 볼 경우, 송신단이 공급자인 경우 수신단은 업데이트 서버가 되며, 송신단이 업데이트 서버인 경우 수신단은 게이트웨이일 수 있다.The process shown in FIG. 3 is intended to prevent software file corruption due to an intentional or attacker's intention during the transmission of the update software, and an integrity checking method such as md5 may be used. In view of the transmitting end and the receiving end, the receiving end may be an update server when the transmitting end is a provider, and the receiving end may be a gateway when the transmitting end is an update server.
구체적으로, 송신단에서는 업데이트 소프트웨어에 소정의 해시 알고리즘 연산을 적용하여 제 1 해쉬값(HASH value 1)을 생성하고, 이를 업데이트 소프트웨어와 다중화하여 수신단으로 전송한다. 수신단에서는 송신단에서 전송한 파일을 역다중화하여 제 1 해쉬값(HASH value 1) 및 업데이트 소프트웨어를 복원한다. 이후 수신단에서 복원된 업데이트 소프트웨어에 소정의 해시 알고리즘 연산을 적용하여 제 2 해쉬값(HASH value 2)을 생성하고, 이를 제 1 해쉬값과 비교한다. 비교 결과, 두 값이 동일한 경우 수신단은 해당 업데이트 소프트웨어 파일이 정합성 체크를 만족한 것으로 판단하며, 동일하지 않은 경우 정합성 체크에 실패한 것으로 판단하여 송신단에 파일 재전송을 요청할 수 있다.Specifically, the transmitting end generates a first hash value 1 by applying a predetermined hash algorithm operation to the updating software, and multiplexes it with the updating software to transmit to the receiving end. The receiving end demultiplexes the file transmitted by the transmitting end to restore the first hash value 1 and the update software. Thereafter, a predetermined hash algorithm operation is applied to the reconstructed update software to generate a second hash value (HASH value 2), and the second hash value is compared with the first hash value. As a result of the comparison, if the two values are the same, the receiver determines that the corresponding update software file satisfies the consistency check. If not, the receiver determines that the consistency check has failed and may request the file to be retransmitted to the transmitter.
이하에서 설명하는 메시지들은 복수의 엘레멘트(element)를 포함하는데, 이러한 엘레멘트의 대표적인 예로 차량(vehicle) 엘레멘트와 모듈(module) 엘레멘트를 들 수 있다. 차량 엘레멘트는 차량에 대한 정보를 정의하는 복수의 필드(또는 속성: attribute)로 구성되며, 모듈 엘레멘트는 차량에 포함되는 하나 이상의 디바이스에 포함되는 소프트웨어 모듈 각각에 대한 정보를 정의하는 복수의 필드로 구성된다.The messages described below include a plurality of elements, and examples of such elements include vehicle elements and module elements. The vehicle element is composed of a plurality of fields (or attributes) defining information about the vehicle, and the module element is composed of a plurality of fields defining information about each software module included in at least one device included in the vehicle. do.
먼저, 모듈 엘레멘트의 구성을 설명한다. 모듈 엘레멘트는 모듈식별자(moduleid) 필드, 버전(version) 필드, 및 다음버전(nextversion) 필드 중 적어도 하나를 포함한다.First, the configuration of the module element will be described. The module element includes at least one of a moduleid field, a version field, and a nextversion field.
모듈식별자 필드는 차량 제조사나 모듈 공급자가 제공하는 모듈의 고유 식별자를 나타낸다. 버전 필드는 해당 소프트웨어 모듈의 버전 정보를, 다음버전 필드는 업데이트가 수행되는 모듈의 버전 정보를 각각 나타내며, 다음버전 필드는 업데이트 수행 중 응답 메시지를 전송하는데 주로 사용될 수 있다.The module identifier field indicates a unique identifier of the module provided by the vehicle manufacturer or the module supplier. The version field indicates version information of the corresponding software module, the next version field indicates version information of the module on which the update is performed, and the next version field may be mainly used to transmit a response message while performing the update.
그런데, 특정 모듈의 업데이트 여부를 보다 정확히 결정하기 위해서는 소프트웨어의 버전뿐만 아니라, 해당 소프트웨어 모듈을 포함하는 하드웨어의 버전 정보도 중요하다. 따라서, 본 실시예에서는 모듈 엘레멘트에 하드웨어의 버전 정보를 나타내는 하드웨어버전(hwversion) 필드를 포함시킬 것을 제안한다. However, in order to more accurately determine whether to update a particular module, not only the version of the software but also the version information of the hardware including the software module is important. Therefore, the present embodiment proposes to include a hardware version (hwversion) field indicating the version information of the hardware in the module element.
그에 따른 모듈 엘레멘트의 구성의 일례는 아래 표 1과 같다.An example of the configuration of the module element according to it is shown in Table 1 below.
표 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.
Table 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)일 수 있다.According to an embodiment, the hardware version field may be included in a device element to be described later. In this case, the description of this field may be a version of this hardware module.
다음으로, 차량 엘레멘트는 이름(name) 필드, 모델(model) 필드, 모델식별자(modelid) 필드, 차량식별자(vehicleid) 필드 중 적어도 하나를 포함할 수 있다. 이름 필드는 차량의 이름을, 모델 필드는 차량 제조사가 제공한 차량의 타이프 네임(Type name)을, 모델식별자 필드는 차량의 모델명을, 차량식별자 필드는 차량 제조사에서 정의한 차량의 식별자를 각각 나타낸다.Next, the vehicle element may include at least one of a name field, a model field, a modelid field, and a vehicleid field. The name field indicates the name of the vehicle, the model field indicates the type name of the vehicle provided by the vehicle manufacturer, the model identifier field indicates the model name of the vehicle, and the vehicle identifier field indicates the identifier of the vehicle defined by the vehicle manufacturer.
그런데, 동일 차량이라고 하더라도 지역(특히, 생산지)에 따라 하드웨어나 소프트웨어 모듈의 구성이 상이할 수 있다. 따라서, 업데이트 여부를 보다 정확히 특정하기 위해 본 실시예에서는 차량 엘레멘트에 차량의 지역 정보를 나타내는 지역(locale) 필드를 포함시킬 것을 제안한다.However, even in the same vehicle, the configuration of the hardware or the software module may be different depending on the region (particularly the production location). Therefore, in order to more accurately specify whether to update, this embodiment proposes to include a locale field indicating local information of the vehicle in the vehicle element.
그에 따른 차량 엘레멘트의 구성의 일례는 아래 표 2와 같다.An example of the configuration of the vehicle element according to it is shown in Table 2 below.
표 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
TABLE 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
이하에서는, 전술한 각 단계와, 해당 단계별로 사용되는 메시지의 구조, 내용 및 코딩 포맷을 보다 상세히 설명한다. Hereinafter, each step described above and the structure, content, and coding format of the message used in each step will be described in more detail.
진단 요청(S2): diagnose (request)Diagnostic request (S2): diagnose (request)
본 단계는 실질적으로 업데이트 과정의 개시 절차로, 차량 게이트웨이(VMG)는 제어기들에 그들의 소프트웨어 리스트 제출을 요청하게 된다. 이를 위해, 진단 요청 메시지가 사용될 수 있다.This step is substantially the start of the update process, where the vehicle gateway (VMG) will ask the controllers to submit their software list. For this purpose, a diagnostic request message can be used.
진단 요청 메시지의 구조가 도 4에 도시된다. 도 4는 본 발명의 일 실시예에 따른 진단 요청 메시지 구조의 일례를 나타낸다.The structure of the diagnostic request message is shown in FIG. 4 illustrates an example of a diagnosis request message structure according to an embodiment of the present invention.
도 4를 참조하면, 진단 요청 메시지는 메시지 엘레멘트, 발행시간(IssuedTime) 엘레멘트 및 만료시간(ExpirationTime) 엘레멘트를 포함할 수 있다.Referring to FIG. 4, the diagnostic request message may include a message element, an IssuedTime element, and an ExpirationTime element.
진단 요청 메시지의 포맷의 일례는 아래 표 3과 같다.An example of the format of the diagnostic request message is shown in Table 3 below.
표 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.
TABLE 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) 필드 중 적어도 하나를 포함할 수 있다. Referring to Table 3, a message element includes a protocol field, a version field, a type field, a subtype field, a session identifier field, a trustlevel field, and a message identifier. It may include at least one of the (messageid) field.
프로토콜 필드는 고정된 값(예컨대, 1.0)으로 설정될 수 있으며, 버전 필드는 메지시 전송자의 버전 정보를 나타낸다. 진단 요청 메시지에서, 타입 필드는 항상 "diagnose"로 설정되며, 서브타입 필드는 항상 "request"로 설정될 수 있다. 세션식별자 필드는 진단 세션에 대한 랜덤 GUID(Globally Unique ID)로 설정되며, 하나의 진단 세션에 해당되는 진단 요청, 진단 보고 및 진단 제출 메시지 모두에 동일한 값이 적용된다. 신뢰레벨 필드는 본 메시지를 생성하는 디바이스의 보안 능력과 안전 요구사항에 기반하여 결정된다. 메시지식별자 필드는 개별 메시지에 대한 랜덤 GUID로 설정된다.The protocol field may be set to a fixed value (eg, 1.0), and the version field indicates version information of the message sender. In the diagnostic request message, the type field may always be set to "diagnose" and the subtype field may always be set to "request". The session identifier field is set to a random Globally Unique ID (GUID) for a diagnostic session, and the same value is applied to all of the diagnostic request, diagnostic report, and diagnostic submission message corresponding to one diagnostic session. The confidence level field is determined based on the security capabilities and security requirements of the device generating this message. The message identifier field is set to a random GUID for an individual message.
발행 시간 엘레멘트는 본 메시지의 생성 시간을 나타내며, 만료시간 엘레멘트는 본 메시지의 만료시간을 나타낸다.The issue time element indicates the creation time of the message and the expiration time element indicates the expiration time of the message.
본 메시지에 대한 XML 코딩의 일례는 도 5와 같다. 도 5는 본 발명의 일 실시예에 따른 진단 요청 메시지 코딩의 일례를 나타낸다.An example of XML coding for this message is shown in FIG. 5 illustrates an example of diagnostic request message coding according to an embodiment of the present invention.
진단 보고(S3): diagnose (report)Diagnostic report (S3): diagnose (report)
진단 요청 메시지에 대한 응답으로, 각 제어기는 자신의 소프트웨어 상태를 체크하고, 소프트웨어 모듈 리스트를 생성하여 게이트웨이로 전송한다. 이를 위해 진단 보고(diagnose (report)) 메시지가 사용될 수 있다. In response to the diagnostic request message, each controller checks its software status, generates a list of software modules, and sends them to the gateway. For this purpose a diagnostic (report) message can be used.
진단 보고 메시지의 구조가 도 6에 도시된다. 도 6은 본 발명의 일 실시예에 따른 진단 보고 메시지 구조의 일례를 나타낸다.The structure of the diagnostic report message is shown in FIG. 6 illustrates an example of a diagnostic report message structure according to an embodiment of the present invention.
도 6을 참조하면, 진단 보고 메시지는 전술한 메시지 엘레멘트, 발행시간(IssuedTime) 엘레멘트 및 만료시간(ExpirationTime) 엘레멘트 외에, 적어도 하나의 디바이스 엘레멘트를 포함할 수 있다. 디바이스 엘레멘트는 다시 하나 이상의 모듈 엘레멘트를 포함하며, 각 모듈 엘레멘트는 해쉬 엘레멘트를 포함할 수 있다.Referring to FIG. 6, the diagnostic report message may include at least one device element in addition to the aforementioned message element, issuedTime element, and expiration time element. The device element may again comprise one or more module elements, and each module element may comprise a hash element.
진단 보고 메시지의 포맷의 일례는 아래 표 4와 같다.An example of the format of the diagnostic report message is shown in Table 4 below.
표 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.
Table 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 (eg, SHA-3, SHA-256, etc.)
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
표 4의 설명을 포함한 이하의 기재에서는, 기 설명된 엘레멘트 및 필드에 대한 설명은 생략하기로 하며, 생략된 기재에 대한 설명은 관련 표 및 도면의 참조에 의해 보충될 수 있음은 당업자에 자명하다.In the following description including the description of Table 4, the description of the elements and fields previously described will be omitted, and it will be apparent to those skilled in the art that the description of the omitted description may be supplemented by reference to related tables and drawings. .
표 4를 참조하면, 진단 요청 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "diagnose"로 설정되며, 서브타입 필드는 항상 "report"로 설정될 수 있다. 또한, 메시지 엘레멘트에는 차량 제조사나 공급자로부터 제공되는 오너 식별자(Owner ID)를 나타내는 오너식별자(ownerid) 필드가 더 포함될 수 있다.Referring to Table 4, in the diagnostic request message, the type field of the message element may always be set to "diagnose", and the subtype field may always be set to "report". In addition, the message element may further include an owner identifier field indicating an owner ID provided from a vehicle manufacturer or a supplier.
디바이스 엘레멘트는 이름(name) 필드, 타입(type) 필드, 모델(model) 필드 및 디바이스식별자(deviceid) 중 적어도 하나의 필드를 포함할 수 있으며, 실시 예에 따라 표 4와 달리 하드웨어버전 필드를 모듈 엘레멘트 대신 더 포함할 수도 있다. 이름 필드는 디바이스의 이름을, 타입 필드는 "Power management ECU", "Seat belt control ECU" 등 해당 디바이스의 타이프 네임(type name)을 각각 나타낼 수 있다. 또한, 모델 필드는 본 디바이스의 모델명을, 디바이스식별자 필드는 차량 제조사/공급자로부터 정의된 디바이스의 식별자 정보를 각각 나타낸다. The device element may include at least one of a name field, a type field, a model field, and a deviceid, and according to an embodiment, the hardware version field may be different from the table 4 according to an embodiment. It can also contain more elements instead. The name field may indicate the name of the device, and the type field may indicate a type name of the corresponding device, such as "Power management ECU" and "Seat belt control ECU". In addition, the model field indicates the model name of the device, and the device identifier field indicates the identifier information of the device defined by the vehicle manufacturer / supplier, respectively.
해쉬 엘레멘트는 각 모듈에 대한 해쉬 값과 그에 사용된 해쉬 알고리즘에 대한 정보를 나타낸다. The hash element represents the hash value for each module and information about the hash algorithm used.
본 메시지에 대한 XML 코딩의 일례는 도 7과 같다. 도 7은 본 발명의 일 실시예에 따른 진단 보고 메시지 코딩의 일례를 나타낸다.An example of XML coding for this message is shown in FIG. 7 illustrates an example of diagnostic report message coding according to an embodiment of the present invention.
진단 제출(S4): diagnose (submit)S4 submission: diagnose (submit)
게이트웨이는 해당 차량에 대한 소프트웨어 업데이트가 있는지 여부를 확인하기 위해 각 제어기로부터 획득한 리스트를 업데이트 서버로 전송한다. 이를 위해 진단 제출(diagnose (submit)) 메시지가 사용될 수 있다. The gateway sends a list obtained from each controller to the update server to check whether there is a software update for the vehicle. A diagnostic (submit) message can be used for this.
진단 제출 메시지의 구조가 도 8에 도시된다. 도 8은 본 발명의 일 실시예에 따른 진단 제출 메시지 구조의 일례를 나타낸다.The structure of the diagnostic submission message is shown in FIG. 8 illustrates an example of a diagnosis submission message structure according to an embodiment of the present invention.
도 8을 참조하면, 진단 제출 메시지의 구조는 전술한 도 6에 나타난 진단 보고 메시지의 구조와 유사하되, 차량(Vehicle) 엘레멘트를 더 포함한다.Referring to FIG. 8, the structure of the diagnosis submission message is similar to that of the diagnosis report message shown in FIG. 6, but further includes a vehicle element.
진단 제출 메시지의 포맷의 일례는 아래 표 5와 같다.An example of the format of the diagnosis submission message is shown in Table 5 below.
표 5
Element Attribute 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.
Table 5
Element Attribute 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 (eg, SHA-3, SHA-256, etc.)
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
표 5를 참조하면, 진단 제출 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "diagnose"로 설정되며, 서브타입 필드는 항상 "submit"로 설정될 수 있다. 전술된 바와 같이, 차량 엘레멘트는 지역 필드를 포함할 수 있으며, 선택적으로 차량의 제조년도를 나타내는 연식(modelyear) 필드를 더 포함할 수도 있다.Referring to Table 5, in the diagnosis submission message, the type field of the message element may be always set to "diagnose", and the subtype field may be always set to "submit". As described above, the vehicle element may include a regional field, and may optionally further include a modelyear field indicating the year of manufacture of the vehicle.
본 메시지에 대한 XML 코딩의 일례는 도 9와 같다. 도 9는 본 발명의 일 실시예에 따른 진단 제출 메시지 코딩의 일례를 나타낸다.An example of XML coding for this message is shown in FIG. 9 illustrates an example of diagnostic submission message coding according to an embodiment of the present invention.
진단 영수(S5): diagnose (receipt)Diagnostic receipt (S5): diagnose (receipt)
업데이트 서버는 게이트웨이가 제출한 리스트에 대한 영수 확인으로, 게이트웨이에 진단 영수(diagnose (receipt)) 메시지를 전송한다. 이를 통해, 게이트웨이는 리스트 제출이 성공적으로 수행됨을 인식(recognize)할 수 있다.The update server sends a diagnostic (receipt) message to the gateway as a receipt confirmation for the list submitted by the gateway. This allows the gateway to recognize that list submission is successful.
이때, 업데이트 서버는 각 소프트웨어 모듈 각각에 대하여 가능한 업데이트를 체크하지 않고 본 메시지를 게이트웨이로 전송한다. 따라서, 본 메시지에서는 소프트웨어 모듈 별 업데이트 가부에 대한 정보가 포함되지 않아 차량, 디바이스 및 모듈 엘레멘트가 불필요하다. 이러한 이유로 본 메시지는 도 4와 같은 형태를 가질 수 있다. 대신, 진단 제출 메시지의 성공적 수신 여부를 나타내는 상태(status) 필드가 메시지 엘레멘트에 포함될 수 있다. 상태 필드를 포함하는 메시지 엘레멘트의 구성의 일례가 아래 표 6에 나타나 있다.At this time, the update server sends this message to the gateway without checking for possible updates for each software module. Therefore, the message does not include information on whether to update each software module, so the vehicle, device and module elements are unnecessary. For this reason, the message may have a form as shown in FIG. Instead, a status field indicating whether the diagnosis submission message has been successfully received may be included in the message element. An example of the configuration of a message element including a status field is shown in Table 6 below.
표 6
Element Attribute 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)
Table 6
Element Attribute 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 Acknowledgment of report for diagnose (submit)
표 6을 참조하면, 진단 영수 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "diagnose"로 설정되며, 서브타입 필드는 항상 "receipt"로 설정될 수 있다. 또한, 상태 필드는 진단 제출 메시지가 성공적으로 수신된 경우 "yes"로 설정될 수 있다.Referring to Table 6, in the diagnostic receipt message, the type field of the message element may always be set to "diagnose", and the subtype field may always be set to "receipt". In addition, the status field may be set to "yes" when the diagnostic submission message is successfully received.
본 메시지에 대한 XML 코딩의 일례는 도 10과 같다. 도 10은 본 발명의 일 실시예에 따른 진단 영수 메시지 코딩의 일례를 나타낸다.An example of XML coding for this message is shown in FIG. 10 illustrates an example of diagnostic receipt message coding according to an embodiment of the present invention.
업데이트 서버의 업데이트 소프트웨어 확인(S6)Check for update software on the update server (S6)
진단 제출 메시지에 포함된 하드웨어 및 소프트웨어 정보 리스트에 따라, 업데이트 서버는 해당 차량에 설치된 소프트웨어의 상태를 조사하고, 전자 제어기들에 대한 업데이트 필요성을 결정한다. According to the hardware and software information list included in the diagnostic submission message, the update server examines the status of software installed in the vehicle and determines the need for updating the electronic controllers.
업데이트 확인 요청(S7): update_check (request)Update check request (S7): update_check (request)
S6 단계의 조사에는 긴 시간이 소요될 수 있기 때문에, 게이트웨이는 해당 차량에 대한 업데이트 필요성을 업데이트 서버에 주기적으로 확인하는 것이 바람직하다. 이를 위해 업데이트 확인 요청(update_check (request)) 메시지가 사용될 수 있다.Since the investigation in step S6 may take a long time, it is preferable that the gateway periodically checks the update server for the need for updating the vehicle. To this end, an update check request (update_check (request)) message may be used.
업데이트 확인 요청 메시지의 구조가 도 11에 도시된다. 도 11은 본 발명의 일 실시예에 따른 업데이트 확인 요청 메시지 구조의 일례를 나타낸다.The structure of the update confirmation request message is shown in FIG. 11 illustrates an example of an update confirmation request message structure according to an embodiment of the present invention.
도 11을 참조하면, 업데이트 확인 요청 메시지의 구조는 전술한 도 8에 나타난 진단 제출 메시지의 구조와 유사하되, 모듈별 해쉬 엘레멘트가 생략된 형태일 수 있다.Referring to FIG. 11, the structure of the update confirmation request message may be similar to that of the diagnosis submission message shown in FIG. 8, but the hash element for each module may be omitted.
업데이트 확인 요청 메시지의 포맷의 일례는 아래 표 7과 같다.An example of the format of the update confirmation request message is shown in Table 7 below.
표 7
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 "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.
TABLE 7
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 "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)로 설정되며, 하나의 업데이트 확인 세션에 해당되는 업데이트 확인 요청 및 업데이트 확인 응답 메시지 모두에 동일한 값이 적용된다. Referring to Table 7, the type field of the message element may always be set to "update_check" and the subtype field may be always set to "request" in the update check request message. In addition, the session identifier field of the message element is set to a random GUID (Globally Unique ID) for the update confirmation session, and the same value is applied to both the update confirmation request and the update confirmation response message corresponding to one update confirmation session.
전술된 바와 같이, 모듈 엘레멘트의 하드웨어버전 필드는 모듈 엘레멘트 대신 디바이스 엘레멘트에 포함될 수 있음은 물론이다. As described above, the hardware version field of the module element may be included in the device element instead of the module element.
본 메시지에 대한 XML 코딩의 일례는 도 12와 같다. 도 12는 본 발명의 일 실시예에 따른 업데이트 확인 요청 메시지 코딩의 일례를 나타낸다.An example of XML coding for this message is shown in FIG. 12 illustrates an example of update confirmation request message coding according to an embodiment of the present invention.
업데이트 확인 응답(S8): update_check (response)Update check response (S8): update_check (response)
업데이트가 있는 경우, 업데이트 서버는 업데이트 모듈의 다운로드 위치 정보(예컨대, URL: Uniform Resource Locator)를 게이트웨이에 제공한다. 이를 위해 업데이트 확인 응답(update_check (response)) 메시지가 사용될 수 있다.If there is an update, the update server provides the gateway with download location information (eg, Uniform Resource Locator) of the update module. For this purpose, an update_check (response) message may be used.
업데이트 확인 요청 메시지의 구조가 도 13에 도시된다. 도 13은 본 발명의 일 실시예에 따른 업데이트 확인 응답 메시지 구조의 일례를 나타낸다.The structure of the update confirmation request message is shown in FIG. 13 illustrates an example of an update confirmation response message structure according to an embodiment of the present invention.
도 13을 참조하면, 업데이트 확인 응답 메시지의 기본적인 구조는 전술한 도 11에 나타난 업데이트 확인 요청 메시지의 구조와 유사하되, 모듈 엘레멘트의 하위 엘레멘트로 URLs 엘레멘트와 매니페스트(Manifest) 엘레멘트가 포함된다.Referring to FIG. 13, the basic structure of the update confirmation response message is similar to that of the update confirmation request message shown in FIG. 11, but includes a URLs element and a manifest element as sub-elements of the module element.
업데이트 확인 응답 메시지의 포맷의 일례는 아래 표 8과 같다.An example of the format of the update confirmation response message is shown in Table 8 below.
표 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.
Table 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 (eg, 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"로 설정될 수 있다. Referring to Table 8, in the update check request message, the type field of the message element may always be set to "update_check", and the subtype field may always be set to "response".
모듈 엘레멘트는 상태(status) 필드를 포함하며, 상태 필드는 업데이트 조사 결과 해당 모듈에 대한 업데이트가 없으면 "noupdate"로 설정되고, 업데이트가 있는 경우 "ok"로 설정될 수 있다.The module element includes a status field, and the status field may be set to "noupdate" if there is no update for the corresponding module as a result of the update investigation, and to "ok" if there is an update.
한편, URLs 엘레멘트는 모듈 엘레멘트의 하위 엘레멘트로, 업데이트가 있는 경우 해당 업데이트 파일의 주소를 나타낸다. 실제 주소는 그의 하위 엘레멘트인 URL 엘레멘트의 코드 베이스(codebase) 필드에 포함된다. 해당 모듈에 대한 업데이트 파일의 주소가 두 개 준비되는 경우, 하나의 URL 엘레멘트는 두 개의 코드 베이스 필드를 포함할 수도 있고, 하나의 코드 베이스 필드와 하나의 codebase2 필드가 사용될 수도 있다. 이는 보다 상세히 후술하기로 한다.Meanwhile, the URLs element is a lower element of the module element and indicates the address of the update file when there is an update. The actual address is included in the codebase field of the URL element, its subelement. If two update file addresses for the module are prepared, one URL element may include two codebase fields, and one codebase field and one codebase2 field may be used. This will be described later in more detail.
매니페스트 엘레멘트는 인스톨될 모듈 및 파일들에 대해 수행될 액션을 기술하며, 해당 소프트웨어 모듈의 특정 신규 버전 넘버를 나타내는 버전 필드를 포함한다. 매니페스트 엘레멘트는 그 하위 엘레멘트로 인스톨될 파일 세트에 대한 정보를 나타내는 Packages 엘레멘트를 포함하며, Pakages 엘레멘트는 그 하위 엘레멘트로 Package 엘레멘트와 Actions 엘레멘트를 포함한다. The manifest element describes the action to be performed on the module and files to be installed and includes a version field indicating the specific new version number of the software module. The manifest element contains a Packages element that represents information about the set of files to be installed as its subelements, and the Pakages element contains the Package and Actions elements as its subelements.
Package 엘레멘트는 해당 모듈에 인스톨될 개별 파일에 대한 정보를 나타내며, 파일명을 나타내는 이름(name) 필드와 바이트 단위로 파일 크기를 나타내는 사이즈(size) 필드를 포함한다. Package 엘레멘트는 다시 하위 엘레멘트로 해쉬 엘레멘트를 포함한다.The Package element indicates information on individual files to be installed in the module, and includes a name field indicating a file name and a size field indicating a file size in bytes. The Package element, in turn, contains a hash element as its child element.
Actions 엘레멘트는 Packages 엘레멘트에 정의된 모든 필요한 파일이 성공적으로 다운로드된 경우 해당 모듈을 인스톨하기 위해 수행될 액션에 대한 정보를 나타내며, 하위 엘레멘트로 Action 엘레멘트를 포함한다. Action 엘레멘트는 인스톨 과정의 일부분으로 수행되는 개별 동작에 대한 정보를 나타내며, 기 설정된 4가지 동작 중 하나를 지시하는 이벤트(event) 필드와 인스톨 프로세스에 전달될 아규먼트를 나타내는 아규먼트(arguments) 필드를 포함한다.The Actions element indicates information about the action to be performed to install the module when all necessary files defined in the Packages element have been successfully downloaded. The Actions element contains the Action element as a child element. The Action element represents information about individual actions performed as part of the installation process, and includes an event field indicating one of four preset actions and an argument field indicating an argument to be passed to the installation process. .
본 메시지에 대한 XML 코딩의 일례는 도 14와 같다. 도 14는 본 발명의 일 실시예에 따른 업데이트 확인 응답 메시지 코딩의 일례를 나타낸다.An example of XML coding for this message is shown in FIG. 14 illustrates an example of update confirmation response message coding according to an embodiment of the present invention.
한편, 업데이트 확인 요청/응답 메시지는 업데이트 서버의 업데이트 조사가 수행되는 동안 여러번 교환될 수 있으며, 이러한 과정에서 플레이백(playback) 공격에 노출될 염려도 있다. 따라서, 업데이트 확인 요청 메시지와 업데이트 확인 응답 메시지의 정확한 매칭이 보장되는 것이 바람직하다. 이를 위해, 일 실시예에 의하면, 논스(nonce) 엘레멘트가 본 메시지에 적용될 수 있다.Meanwhile, the update confirmation request / response message may be exchanged several times during the update investigation of the update server, and may be exposed to a playback attack in this process. Therefore, it is desirable to ensure accurate matching of the update confirmation request message and the update confirmation response message. To this end, according to one embodiment, a nonce element may be applied to the message.
논스 엘레멘트가 적용된 업데이트 확인 응답 메시지 포맷의 일례는 아래 표 9와 같다.An example of an update acknowledgment message format to which a nonce element is applied is shown in Table 9 below.
표 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
Table 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.
Nonnce Random generated code for nonce method
표 9를 참조하면, 업데이트 확인 응답 메시지에 논스 기법을 위한 랜덤 생성 코드를 나타내는 논스 엘레멘트가 포함될 수 있다.Referring to Table 9, the update confirmation response message may include a nonce element indicating a random generation code for the nonce technique.
전술된 바와 같이, 업데이트 확인 응답 메시지에는 게이트웨이가 업데이트 소프트웨어 모듈을 다운로드할 수 있는 URL 링크 정보가 포함된다. 그런데, 업데이트 서버 자체나 해당 주소에 접속이 불가한 경우가 있을 수 있다. 예컨대, 이러한 접속 불가 상황으로 1) 업데이트 서버가 서비스거부(DoS) 공격이나 하드웨어 문제(NIC 또는 디스크 손상 등)로 일시적/영구적으로 다운되거나, 2) 업데이트 소프트웨어 모듈의 검증(validation) 문제가 바이러스 감염 등 파일 코럽션에 의해 발생하거나 3) 업데이트 서버에 다수의 동시 접속으로 인한 지나친 트래픽이 발생한 경우 등을 들 수 있다.As described above, the update confirmation response message includes URL link information from which the gateway can download the update software module. However, there may be a case where it is impossible to access the update server itself or the corresponding address. For example, due to such an inaccessibility situation, 1) the update server is temporarily / permanently down due to a denial of service (DoS) attack or hardware problem (such as NIC or disk damage), or 2) a validation problem of the update software module is a virus infection. For example, file corruption, or excessive traffic due to multiple simultaneous connections to the update server.
따라서, 강건한 소프트웨어 다운로드 환경을 제공하기 위하여, 백업 URL 링크 주소가 업데이트 확인 응답 메시지를 통해 제공되는 것이 바람직하다. 이를 위해, 전술된 바와 같이 코드베이스 필드 두개를 이용하여 하나에 백업 URL 정보를 제공하는 방법과, 코드베이스2 필드를 이용하여 백업 URL 정보를 제공하는 방법이 고려될 수 있다. 각각의 경우가 도 15 및 도 16에 도시된다.Therefore, in order to provide a robust software download environment, it is desirable that a backup URL link address be provided via an update confirmation response message. To this end, as described above, a method of providing backup URL information to one using two codebase fields and a method of providing backup URL information using a codebase2 field may be considered. Each case is shown in FIGS. 15 and 16.
도 15는 본 발명의 일 실시예에 따른 코드베이스 필드를 통해 백업 주소를 제공하는 업데이트 확인 응답 메시지 코딩의 일례를, 도 16은 본 발명의 일 실시예에 따른 코드베이스2 필드를 통해 백업 주소를 제공하는 업데이트 확인 응답 메시지 코딩의 일례를 각각 나타낸다.15 illustrates an example of an update acknowledgment message coding providing a backup address through a codebase field according to an embodiment of the present invention, and FIG. 16 illustrates a backup address through a codebase2 field according to an embodiment of the present invention. Each of the examples of the update acknowledgment message coding provided is shown.
도 15를 참조하면, URLs 엘레멘트 하위에 두 개의 URL 엘레멘트가 존재하며, 각 URL 엘레멘트에는 하나의 코드베이스 필드가 포함된다. 여기서, 첫 번째 URL 엘레멘트의 코드베이스 필드에는 디폴트 URL 주소 정보가 포함되고, 두 번째 URL 엘레멘트의 코드베이스 필드에는 백업 URL 주소 정보가 포함된다.Referring to FIG. 15, two URL elements exist under the URLs element, and each URL element includes one codebase field. Here, the codebase field of the first URL element includes default URL address information, and the codebase field of the second URL element includes backup URL address information.
다음으로, 도 16을 참조하면, URLs 엘레멘트 하나의 URL 엘레멘트가 존재하며, 해당 URL 엘레멘트에는 코드베이스 필드와 코드베이스2 필드가 포함된다. 여기서, 코드베이스 필드에는 디폴트 URL 주소 정보가 포함되고, 코드베이스2 필드에는 백업 URL 주소 정보가 포함된다.Next, referring to FIG. 16, one URL element is present, and the URL element includes a codebase field and a codebase2 field. Here, the codebase field includes default URL address information, and the codebase2 field includes backup URL address information.
백업 URL 정보는 동일 서버의 다른 폴더의 주소일 수도 있고, 다른 서버의 주소일 수도 있다. 동일 서버의 다른 폴더인 경우 해당 파일의 코럽션이나 디스크 손상 등의 사유에 대처할 수 있으며, 다른 서버인 경우 원래 서버의 트래픽 부하 문제나 연결 실패 등의 사유에 대처할 수 있는 장점이 있다.The backup URL information may be an address of another folder of the same server or may be an address of another server. In the case of other folders on the same server, it can cope with the cause of corruption or disk corruption of the file, and in the case of other servers, it can cope with traffic load problems or connection failures of the original server.
업데이트 소프트웨어 다운로드(S9): download update S/WDownload update software (S9): download update S / W
업데이트가 있는 경우, 게이트웨이는 다운로드 위치(URL/Backup URL) 정보로 접속하여 업데이트 모듈을 다운로드할 수 있다.If there is an update, the gateway may access the download location (URL / Backup URL) information and download the update module.
업데이트 알림(S10): update (notification)Update notification (S10): update (notification)
게이트웨이는 업데이트를 각 제어기에 적용하기 전에, 업데이트 적용을 확인받기 위해 사용자 인터페이스를 통해 운전자에 알릴 수 있다(S10). 이를 위해 업데이트 알림(update (notification)) 메시지가 사용될 수 있다.Before applying the update to each controller, the gateway may inform the driver through the user interface to confirm the application of the update (S10). For this purpose, an update (notification) message may be used.
업데이트 확인 요청 메시지의 엘레멘트 구조는 자체는 전술한 도 13에 나타난 업데이트 확인 응답 메시지 구조와 유사하다. 다만, 일반적인 운전자는 업데이트 소프트웨어의 간단한 설명을 원하는 경우가 있으므로, 업데이트 소프트웨어에 대한 설명이 사용자 인터페이스를 통해 출력될 수 있도록 그에 대한 정보가 본 메시지에 포함될 수 있다.The element structure of the update confirmation request message is itself similar to the update confirmation response message structure shown in FIG. 13 described above. However, since a general driver may want a brief description of the update software, information about the update software may be included in the message so that the description of the update software may be output through the user interface.
업데이트 알림 메시지의 포맷의 일례는 아래 표 10과 같다.An example of the format of the update notification message is shown in Table 10 below.
표 10
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 "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.
Table 10
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 "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 (eg, 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"로 설정될 수 있다. Referring to Table 10, in the update notification message, the type field of the message element may always be set to "update", and the subtype field may always be set to "notification".
세션식별자 필드는 업데이트 세션에 대한 랜덤 GUID(Globally Unique ID)로 설정되며, 하나의 업데이트 세션에 해당되는 업데이트 알림, 업데이트 컨펌, 업데이트 적용 및 업데이트 결과 메시지 모두에 동일한 값이 적용된다. The session identifier field is set to a random globally unique ID (GUID) for an update session. The same value is applied to all update notifications, update confirmations, update application, and update result messages corresponding to one update session.
한편, Package 엘레멘트에는 업데이트 모듈에 대한 설명을 나타내는 description 필드가 포함될 수 있다.,Meanwhile, the Package element may include a description field indicating a description of the update module.
본 메시지에 대한 XML 코딩의 일례는 도 17과 같다. 도 17은 본 발명의 일 실시예에 따른 업데이트 알림 메시지 코딩의 일례를 나타낸다. 도 17을 참조하면, description 필드에는 해당 소프트웨어 모듈을 설명하는 텍스트 정보가 포함될 수 있다. An example of XML coding for this message is shown in FIG. 17 illustrates an example of update notification message coding according to an embodiment of the present invention. Referring to FIG. 17, the description field may include text information describing a corresponding software module.
다른 실시예에 의하면, description 필드에 텍스트 자체 대신 해당 정보를 포함하는 URL 주소가 포함될 수도 있다. 이러한 경우, 아래 표 11과 같이 Package 엘레멘트에는 description 필드 대신 descriptionurl 필드가 포함될 수 있다.According to another embodiment, the description field may include a URL address including corresponding information instead of the text itself. In this case, as shown in Table 11 below, the Package element may include the descriptionurl field instead of the description field.
표 11
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)
Table 11
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은 본 발명의 일 실시예에 따른 업데이트 알림 메시지 코딩의 다른 일례를 나타낸다.An example of XML coding for a message as shown in Table 11 above is shown in FIG. 18. 18 illustrates another example of updating notification message coding according to an embodiment of the present invention.
업데이트 컨펌(S11): update (confirmation)Update confirmation (S11): update (confirmation)
운전자가 업데이트 적용을 확인하고 수락하면, 업데이트 컨펌(update (confirm)) 메시지가 게이트웨이로 전송된다.When the driver confirms and accepts the update application, an update confirm message is sent to the gateway.
업데이트 컨펌 메시지의 구조는 도 4에 도시된 진단 요청 메시지의 구조와 유사하며, 포맷의 일례는 아래 표 12와 같다.The structure of the update confirm message is similar to that of the diagnostic request message shown in FIG. 4, and an example of the format is shown in Table 12 below.
표 12
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 "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.
Table 12
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 "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를 참조하면, 업데이트 알림 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "update"로 설정되며, 서브타입 필드는 항상 "confirmation"으로 설정될 수 있다. Referring to Table 12, in the update notification message, the type field of the message element may be always set to "update", and the subtype field may be always set to "confirmation".
또한, 메시지 엘레멘트에 업데이트 적용의 수락 여부를 나타내는 status 필드가 포함된다. status 필드는 운전자가 업데이트 적용을 수락한 경우 "Yes" 또는 "ok"로, 그렇지 않은 경우 "no"로 설정될 수 있다. In addition, the message element includes a status field indicating whether to accept the update application. The status field may be set to "Yes" or "ok" if the driver accepts the update application, or "no" otherwise.
본 메시지에 대한 XML 코딩의 일례는 도 19와 같다. 도 19는 본 발명의 일 실시예에 따른 업데이트 컨펌 메시지 코딩의 일례를 나타낸다. An example of XML coding for this message is shown in FIG. 19 illustrates an example of update confirm message coding according to an embodiment of the present invention.
업데이트 적용(S12): update (application)Update (application) (S12): update (application)
운전자의 수락에 따라, 게이트웨이는 업데이트 모듈 파일을 해당 제어기로 전송하고, 업데이트를 적용할 것을 요청할 수 있다. 이를 위해 업데이트 적용(update (application)) 메시지가 사용될 수 있다.Upon acceptance of the driver, the gateway may send an update module file to the controller and request to apply the update. For this purpose, an update (application) message may be used.
업데이트 적용 메시지의 구조가 도 20에 도시된다. 도 20은 본 발명의 일 실시예에 따른 업데이트 적용 메시지 구조의 일례를 나타낸다.The structure of the update application message is shown in FIG. 20 shows an example of an update application message structure according to an embodiment of the present invention.
도 20을 참조하면, 업데이트 적용 메시지는 게이트웨이에서 개별 제어기로 전송되는 메시지이므로, 차량 엘레멘트가 없고 해당 제어기에 대응되는 디바이스 엘레멘트를 포함하되, 그 하위 엘레멘트로 모듈 엘레멘트를 포함한다. 모듈 엘레멘트는 다시 매니페스트 엘레멘트를 포함하고, 매니페스트 엘레멘트는 Packages엘레멘트를 포함한다. Referring to FIG. 20, since the update application message is a message transmitted from an gateway to an individual controller, there is no vehicle element and includes a device element corresponding to the controller, and includes a module element as a lower element. The module element again contains a manifest element, and the manifest element contains a Packages element.
업데이트 적용 메시지의 포맷의 일례는 아래 표 13과 같다.An example of the format of the update application message is shown in Table 13 below.
표 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.
Table 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 (eg, 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"으로 설정될 수 있다. Referring to Table 13, in the update application message, the type field of the message element may always be set to "update", and the subtype field may always be set to "application".
한편, Package 엘레멘트에는 업데이트 모듈을 인코딩된 바이너리 데이터로 나타낸 타켓(Target) 엘레멘트가 포함되며, 인코드(encode) 필드를 통해 인코딩 방식이 지시될 수 있다.The package element includes a target element representing the update module as encoded binary data, and an encoding scheme may be indicated through an encode field.
본 메시지에 대한 XML 코딩의 일례는 도 21과 같다. 도 21은 본 발명의 일 실시예에 따른 업데이트 적용 메시지 코딩의 일례를 나타낸다. An example of XML coding for this message is shown in FIG. 21 illustrates an example of update applied message coding according to an embodiment of the present invention.
업데이트 결과(S13): update (result)Update result (S13): update (result)
업데이트 모듈 파일을 수신한 각 제어기는 업데이트를 적용하고, 적용 결과를 게이트웨이로 전송한다. 이를 위해 업데이트 결과(updatet (result)) 메시지가 사용될 수 있다.Each controller receiving the update module file applies the update and sends the application result to the gateway. To this end, an update result (updatet (result)) message may be used.
업데이트 결과 메시지의 구조가 도 22에 도시된다. 도 22는 본 발명의 일 실시예에 따른 업데이트 결과 메시지 구조의 일례를 나타낸다.The structure of the update result message is shown in FIG. 22 illustrates an example of an update result message structure according to an embodiment of the present invention.
도 22를 참조하면, 업데이트 결과 메시지는 개별 제어기에서 게이트웨이로 전송되는 메시지이므로, 차량 엘레멘트가 없고 해당 제어기에 대응되는 디바이스 엘레멘트를 포함하되, 그 하위 엘레멘트로 모듈 엘레멘트를 포함한다.Referring to FIG. 22, since the update result message is a message transmitted from an individual controller to a gateway, there is no vehicle element and includes a device element corresponding to the controller, and includes a module element as a lower element.
업데이트 결과 메시지의 포맷의 일례는 아래 표 14와 같다.An example of the format of the update result message is shown in Table 14 below.
표 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.
Table 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"으로 설정될 수 있다. Referring to Table 14, in the update result message, the type field of the message element may always be set to "update", and the subtype field may always be set to "result".
한편, Package 엘레멘트에는 업데이트 모듈을 인코딩된 바이너리 데이터로 나타낸 타켓(Target) 엘레멘트가 포함되며, 인코드(encode) 필드를 통해 인코딩 방식이 지시될 수 있다.The package element includes a target element representing the update module as encoded binary data, and an encoding scheme may be indicated through an encode field.
본 메시지에 대한 XML 코딩의 일례는 도 23과 같다. 도 23은 본 발명의 일 실시예에 따른 업데이트 결과 메시지 코딩의 일례를 나타낸다. An example of XML coding for this message is shown in FIG. 23 illustrates an example of update result message coding according to an embodiment of the present invention.
업데이트 보고 제출(S14): update_report (submit)Submit update report (S14): update_report (submit)
게이트웨이는 업데이트 적용 결과를 업데이트 보고 제출(update_report (submit)) 메세지를 통해 업데이트 서버로 제출한다.The gateway submits the update application result to the update server through an update_report (submit) message.
업데이트 보고 제출 메시지의 구조는 도 8에 도시된 진단 제출 메시지 구조와 유사하며, 그 포맷의 일례는 아래 표 15와 같다.The structure of the update report submission message is similar to that of the diagnosis submission message shown in FIG. 8, and an example of the format thereof is shown in Table 15 below.
표 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.
Table 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 (eg, SHA-3, SHA-256, etc.)
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
표 15를 참조하면, 업데이트 보고 제출 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "update_report"로 설정되며, 서브타입 필드는 항상 "submit"으로 설정될 수 있다. Referring to Table 15, in the update report submission message, the type field of the message element may always be set to "update_report", and the subtype field may always be set to "submit".
업데이트 보고 제출 메시지의 모듈 엘레멘트는 status 필드를 포함하며, 본 필드를 통해 해당 모듈의 업데이트 적용 결과가 지시될 수 있다.The module element of the update report submission message includes a status field, and the result of applying the update of the corresponding module may be indicated through this field.
본 메시지에 대한 XML 코딩의 일례는 도 24와 같다. 도 24는 본 발명의 일 실시예에 따른 업데이트 보고 제출 메시지 코딩의 일례를 나타낸다. An example of XML coding for this message is shown in FIG. 24 illustrates an example of update report submission message coding according to an embodiment of the present invention.
업데이트 보고 영수(S15): update_report (receipt)Receive update report (S15): update_report (receipt)
업데이트 서버는 업데이트 보고 제출 메시지에 대한 응답으로, 업데이트 보고 영수(update_report (receipt)) 메시지를 게이트웨이로 전송한다. The update server sends an update report receipt (update_report (receipt)) message to the gateway in response to the update report submission message.
업데이트 보고 영수 메시지의 구조는 도 11에 도시된 업데이트 확인 요청 메시지 구조와 유사하며, 그 포맷의 일례는 아래 표 16와 같다.The structure of the update report receipt message is similar to that of the update confirmation request message shown in FIG. 11, and an example of the format thereof is shown in Table 16 below.
표 16
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_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.
Table 16
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_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 Acknowledgment of report for this module.
IssuedTime - Time of generation of this message.
ExpirationTime - Expiration time of this message.
표 16을 참조하면, 업데이트 보고 영수 메시지에서 메시지 엘레멘트의 타입 필드는 항상 "update_report"로 설정되며, 서브타입 필드는 항상 "receipt"로 설정될 수 있다. Referring to Table 16, in the update report receipt message, the type field of the message element may always be set to "update_report", and the subtype field may always be set to "receipt".
업데이트 보고 영수 메시지의 모듈 엘레멘트는 status 필드를 포함하며, 본 필드를 통해 해당 모듈의 보고 ACK(Acknowledgement) 여부가 지시될 수 있다.The module element of the update report receipt message includes a status field, and this field may indicate whether the corresponding module reports ACK (Acknowledgement).
본 메시지에 대한 XML 코딩의 일례는 도 25와 같다. 도 25는 본 발명의 일 실시예에 따른 업데이트 보고 영수 메시지 코딩의 일례를 나타낸다.An example of XML coding for this message is shown in FIG. 25 illustrates an example of update report receipt message coding according to an embodiment of the present invention.
한편, 본 실시예에 따른 게이트웨이는 적어도 유선통신부, 무선통신부, 메모리 및 프로세서를 포함할 수 있다(미도시). Meanwhile, the gateway according to the present embodiment may include at least a wired communication unit, a wireless communication unit, a memory, and a processor (not shown).
유선통신부는 게이트웨이와 연결되어 진단 세션 및 업데이트 세션을 수행하는 제어기들과의 통신 기능을 제공한다. 유선 통신은 CAN(Controller Area Network), Ethernet, LIN 프로토콜 중 적어도 하나의 방식을 따를 수 있으나, 반드시 이에 한정되는 것은 아니다.The wired communication unit provides a communication function with controllers connected to the gateway to perform a diagnostic session and an update session. Wired communication may follow at least one of CAN (Controller Area Network), Ethernet, and LIN protocols, but is not necessarily limited thereto.
무선통신부는 업데이트 서버와의 무선 통신 기능을 제공하며, 무선 기지국이나 텔레메틱스 센터를 경유하여 업데이트 서버와 연결될 수도 있다. The wireless communication unit provides a wireless communication function with the update server and may be connected to the update server via a wireless base station or a telematics center.
메모리는 프로세서의 처리 및 제어를 위한 프로그램이 저장될 수도 있고, 입/출력되는 데이터들의 임시 저장을 위한 기능을 수행할 수도 있다.The memory may store a program for processing and controlling the processor, and may perform a function for temporarily storing input / output data.
프로세서는 통상적으로 게이트웨이 구성요소의 전반적인 동작을 제어한다. 예를 들어, 상술한 본 발명의 실시예들, 예컨대 S2 단계 내지 S14 단계를 수행하기 위한 콘트롤러 기능, 메시지 생성 및 해석 기능, 인증 및 암호화 기능 등이 수행될 수 있다. The processor typically controls the overall operation of the gateway component. For example, the above-described embodiments of the present invention, for example, a controller function, a message generation and interpretation function, an authentication and encryption function, etc. for performing steps S2 to S14 may be performed.
아울러, 본 실시예에 따른 차량은 상술한 게이트웨이 및 그와 연결된 적어도 하나의 제어기를 포함할 수 있다.In addition, the vehicle according to the present embodiment may include the above-described gateway and at least one controller connected thereto.
전술한 본 발명은, 프로그램이 기록된 매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 매체는, 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 매체의 예로는, HDD(Hard Disk Drive), SSD(Solid State Disk), SDD(Silicon Disk Drive), ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장 장치 등이 있다. The present invention described above can be embodied as computer readable codes on a medium in which a program is recorded. The computer-readable medium includes all kinds of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable media include hard disk drives (HDDs), solid state disks (SSDs), silicon disk drives (SDDs), ROMs, RAMs, CD-ROMs, magnetic tapes, floppy disks, optical data storage devices, and the like. There is this.
따라서, 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.Accordingly, the above detailed description should not be construed as limiting in all aspects and should be considered as illustrative. The scope of the invention should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of the invention are included in the scope of the invention.
본 발명의 적어도 하나의 실시예에 따르면 차량용 전자 제어기의 무선 업데이트의 절차가 정의될 수 있으며, 정의된 절차는 차량용 게이트웨이, 게이트웨이에 연결된 각종 전자 제어기 및 업데이트 소프트웨어 서버 등에 적용될 수 있다. 특히, 무선 소프트웨어 업데이트 절차 및 해당 절차에서 단계별로 사용되는 메시지의 포맷이 정의될 수 있다. 특히, 소프트웨어 모듈의 하드웨어 버전 정보와 차량의 지역 정보가 관련 메시지에 포함되므로, 보다 정확한 업데이트가 수행될 수 있다.According to at least one embodiment of the present invention, a procedure of wireless update of an on-vehicle electronic controller may be defined, and the defined procedure may be applied to a vehicle gateway, various electronic controllers connected to the gateway, and an update software server. In particular, the wireless software update procedure and the format of the message used step by step in the procedure can be defined. In particular, since the hardware version information of the software module and the region information of the vehicle are included in the related message, more accurate update can be performed.

Claims (28)

  1. 차량용 게이트웨이의 무선 소프트웨어 업데이트 방법에 있어서,In the wireless software update method of the vehicle gateway,
    적어도 하나의 제어기로부터 소프트웨어 모듈 리스트를 포함하는 제 1 메시지를 수신하는 단계; 및Receiving a first message comprising a list of software modules from at least one controller; And
    상기 적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 포함하는 제 2 메시지를 업데이트 서버로 전송하는 단계를 포함하되,Transmitting to the update server a second message comprising a list of software modules for each of the at least one controller,
    상기 제 1 메시지는 하드웨어 버전 정보를 포함하고,The first message includes hardware version information,
    상기 제 2 메시지는 차량의 지역정보를 포함하는, 무선 소프트웨어 업데이트 방법. And the second message includes local information of the vehicle.
  2. 제 1항에 있어서,The method of claim 1,
    상기 하드웨어 버전 정보는,The hardware version information,
    상기 제 1 메시지의 장치(Device) 엘레멘트에 포함되는, 무선 소프트웨어 업데이트 방법. The wireless software update method included in the device element of the first message.
  3. 제 1항에 있어서,The method of claim 1,
    상기 차량의 지역정보는,Area information of the vehicle,
    상기 제 2 메시지의 차량(Vehicle) 엘레멘트에 포함되는, 무선 소프트웨어 업데이트 방법.And included in the vehicle element of the second message.
  4. 제 1항에 있어서,The method of claim 1,
    상기 업데이트 서버로부터 상기 제 2 메시지의 성공적 수신 여부를 지시하는 제 3 메시지를 수신하는 단계를 더 포함하는, 무선 소프트웨어 업데이트 방법.Receiving a third message indicating whether the second message has been successfully received from the update server.
  5. 제 4항에 있어서,The method of claim 4, wherein
    상기 제 3 메시지는,The third message is,
    상기 제 2 메시지의 성공적 수신 여부를 지시하는 필드를 메시지 엘레멘트에 포함하는, 무선 소프트웨어 업데이트 방법.And a field in the message element indicating whether the second message has been successfully received.
  6. 제 4항에 있어서,The method of claim 4, wherein
    상기 제 1 메시지, 상기 제 2 메시지 및 상기 제 3 메시지 각각은,Each of the first message, the second message, and the third message,
    세션식별자(sessionid) 정보를 포함하고, 동일한 값을 상기 세션식별자 정보로 갖는, 무선 소프트웨어 업데이트 방법. And sessionid information and having the same value as the session identifier information.
  7. 제 4항에 있어서,The method of claim 4, wherein
    상기 업데이트 서버로부터 적어도 하나의 업데이트 모듈의 위치 정보를 포함하는 제 4 메시지를 수신하는 단계를 더 포함하는, 무선 소프트웨어 업데이트 방법.Receiving a fourth message from the update server, the fourth message comprising location information of at least one update module.
  8. 제 7항에 있어서,The method of claim 7, wherein
    상기 위치 정보는,The location information,
    둘 이상의 URL 주소를 포함하는, 무선 소프트웨어 업데이트 방법.A wireless software update method comprising more than one URL address.
  9. 제 8항에 있어서,The method of claim 8,
    상기 둘 이상의 URL 주소 중 적어도 하나는 백업 URL 주소인, 무선 소프트웨어 업데이트 방법.And at least one of the two or more URL addresses is a backup URL address.
  10. 제 1항 내지 제 9항 중 어느 한 항에 따른 무선 소프트웨어 업데이트 방법을 실행시키기 위한 프로그램을 기록한 컴퓨터 해독 가능 기록 매체.A computer-readable recording medium having recorded thereon a program for executing the method for updating a wireless software according to any one of claims 1 to 9.
  11. 무선 소프트웨어 업데이트를 수행하는 차량용 게이트웨이에 있어서,A vehicle gateway for performing a wireless software update,
    적어도 하나의 제어기와 통신하는 유선 통신 모듈;A wired communication module in communication with the at least one controller;
    업데이트 서버와 통신하는 무선 통신 모듈; 및A wireless communication module in communication with the update server; And
    상기 유선 통신 모듈을 통해 상기 적어도 하나의 제어기로부터 소프트웨어 모듈 리스트를 포함하는 제 1 메시지를 수신하고, 상기 적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 포함하는 제 2 메시지가 상기 무선 통신 모듈을 통해 상기 업데이트 서버로 전송되도록 제어하는 프로세서를 포함하되,Receive a first message from the at least one controller via the wired communication module, the first message including a list of software modules, and a second message including a list of software modules for each of the at least one controller via the wireless communication module; Includes a processor that controls the transmission to the update server,
    상기 제 1 메시지는 하드웨어 버전 정보를 포함하고,The first message includes hardware version information,
    상기 제 2 메시지는 차량의 지역정보를 포함하는, 차량용 게이트웨이.And the second message includes regional information of the vehicle.
  12. 제 11항에 있어서,The method of claim 11,
    상기 하드웨어 버전 정보는,The hardware version information,
    상기 제 1 메시지의 장치(Device) 엘레멘트에 포함되는, 차량용 게이트웨이.The vehicle gateway included in the device element of the first message.
  13. 제 11항에 있어서,The method of claim 11,
    상기 차량의 지역정보는,Area information of the vehicle,
    상기 제 2 메시지의 차량(Vehicle) 엘레멘트에 포함되는, 차량용 게이트웨이.The vehicle gateway included in the vehicle element of the second message.
  14. 제 11항에 있어서,The method of claim 11,
    상기 프로세서는,The processor,
    상기 무선 통신 모듈을 통해 상기 업데이트 서버로부터 상기 제 2 메시지의 성공적 수신 여부를 지시하는 제 3 메시지가 수신되도록 제어하는, 차량용 게이트웨이.And control such that a third message indicating whether the second message is successfully received from the update server is received through the wireless communication module.
  15. 제 14항에 있어서,The method of claim 14,
    상기 제 3 메시지는,The third message is,
    상기 제 2 메시지의 성공적 수신 여부를 지시하는 필드를 메시지 엘레멘트에 포함하는, 차량용 게이트웨이.And a field in the message element indicating whether the second message has been successfully received.
  16. 제 14항에 있어서,The method of claim 14,
    상기 제 1 메시지, 상기 제 2 메시지 및 상기 제 3 메시지 각각은,Each of the first message, the second message, and the third message,
    세션식별자(sessionid) 정보를 포함하고, 동일한 값을 상기 세션식별자 정보로 갖는, 차량용 게이트웨이.And sessionid information and having the same value as the session identifier information.
  17. 제 14항에 있어서,The method of claim 14,
    상기 프로세서는,The processor,
    상기 무선 통신 모듈을 통해 상기 업데이트 서버로부터 적어도 하나의 업데이트 모듈의 위치 정보를 포함하는 제 4 메시지가 수신되도록 제어하는, 차량용 게이트웨이.And control a fourth message including location information of at least one update module from the update server via the wireless communication module.
  18. 제 17항에 있어서,The method of claim 17,
    상기 위치 정보는,The location information,
    둘 이상의 URL 주소를 포함하는, 차량용 게이트웨이.A vehicle gateway, comprising more than one URL address.
  19. 제 18항에 있어서,The method of claim 18,
    상기 둘 이상의 URL 주소 중 적어도 하나는 백업 URL 주소인, 차량용 게이트웨이.At least one of the two or more URL addresses is a backup URL address.
  20. 무선 소프트웨어 업데이트를 수행하는 차량에 있어서,In a vehicle performing a wireless software update,
    적어도 하나의 제어기; 및At least one controller; And
    상기 적어도 하나의 제어기로부터 소프트웨어 모듈 리스트를 포함하는 제 1 메시지를 수신하고, 상기 적어도 하나의 제어기 각각에 대한 소프트웨어 모듈 리스트를 포함하는 제 2 메시지를 업데이트 서버로 전송하는 게이트웨이를 포함하되,A gateway for receiving a first message comprising a list of software modules from the at least one controller and for transmitting a second message including a list of software modules for each of the at least one controller to an update server,
    상기 제 1 메시지는 하드웨어 버전 정보를 포함하고,The first message includes hardware version information,
    상기 제 2 메시지는 차량의 지역정보를 포함하는, 차량.And the second message includes regional information of the vehicle.
  21. 제 20항에 있어서,The method of claim 20,
    상기 하드웨어 버전 정보는,The hardware version information,
    상기 제 1 메시지의 장치(Device) 엘레멘트에 포함되는, 차량.And included in the Device element of the first message.
  22. 제 20항에 있어서,The method of claim 20,
    상기 차량의 지역정보는,Area information of the vehicle,
    상기 제 2 메시지의 차량(Vehicle) 엘레멘트에 포함되는, 차량.A vehicle element included in the vehicle element of the second message.
  23. 제 20항에 있어서,The method of claim 20,
    상기 게이트웨이는,The gateway,
    상기 무선 통신 모듈을 통해 상기 업데이트 서버로부터 상기 제 2 메시지의 성공적 수신 여부를 지시하는 제 3 메시지를 수신하는, 차량.And receiving a third message indicating whether the second message has been successfully received from the update server through the wireless communication module.
  24. 제 23항에 있어서,The method of claim 23, wherein
    상기 제 3 메시지는,The third message is,
    상기 제 2 메시지의 성공적 수신 여부를 지시하는 필드를 메시지 엘레멘트에 포함하는, 차량.And a field in the message element indicating whether the second message has been successfully received.
  25. 제 23항에 있어서,The method of claim 23, wherein
    상기 제 1 메시지, 상기 제 2 메시지 및 상기 제 3 메시지 각각은,Each of the first message, the second message, and the third message,
    세션식별자(sessionid) 정보를 포함하고, 동일한 값을 상기 세션식별자 정보로 갖는, 차량.And including sessionid information and having the same value as the session identifier information.
  26. 제 23항에 있어서,The method of claim 23, wherein
    상기 게이트웨이는,The gateway,
    상기 무선 통신 모듈을 통해 상기 업데이트 서버로부터 적어도 하나의 업데이트 모듈의 위치 정보를 포함하는 제 4 메시지를 수신하는, 차량.And receive a fourth message including location information of at least one update module from the update server via the wireless communication module.
  27. 제 26항에 있어서,The method of claim 26,
    상기 위치 정보는,The location information,
    둘 이상의 URL 주소를 포함하는, 차량.A vehicle, comprising more than one URL address.
  28. 제 27항에 있어서,The method of claim 27,
    상기 둘 이상의 URL 주소 중 적어도 하나는 백업 URL 주소인, 차량.Wherein at least one of the two or more URL addresses is a backup URL address.
PCT/KR2017/001509 2016-02-11 2017-02-10 Method and device for wirelessly updating software for vehicle WO2017138787A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP17750479.2A EP3416052B1 (en) 2016-02-11 2017-02-10 Method and device for wirelessly updating software for vehicle
CN201780011103.XA CN108701039B (en) 2016-02-11 2017-02-10 Method and device for wirelessly updating software of vehicle
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 (6)

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
KR1020170018667A KR101966626B1 (en) 2016-02-11 2017-02-10 Method and apparatus for updating software of electronic devices in a vehicle
KR10-2017-0018667 2017-02-10

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/048,692 Continuation US10768922B2 (en) 2016-02-11 2018-07-30 Method and device for wirelessly updating software for vehicle

Publications (1)

Publication Number Publication Date
WO2017138787A1 true WO2017138787A1 (en) 2017-08-17

Family

ID=59563222

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2017/001509 WO2017138787A1 (en) 2016-02-11 2017-02-10 Method and device for wirelessly updating software for vehicle

Country Status (1)

Country Link
WO (1) WO2017138787A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110908871A (en) * 2019-11-26 2020-03-24 安徽江淮汽车集团股份有限公司 Data management method, device, equipment and storage medium based on vehicle control unit

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012101788A (en) * 2011-12-01 2012-05-31 Hitachi Automotive Systems Ltd In-vehicle gateway device
US20130318541A1 (en) * 2012-05-22 2013-11-28 Avaya Inc. System and method for dynamic influencing of sequence vector by sequenced applications
KR20150043732A (en) * 2013-10-15 2015-04-23 현대자동차주식회사 System and method for software update of vehicle controller
KR20150076846A (en) * 2013-12-27 2015-07-07 기아자동차주식회사 System and method for acquiring data of electronic control unit
US9214085B2 (en) * 2009-11-06 2015-12-15 Toyota Jidosha Kabushiki Kaisha Vehicle gateway device

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9214085B2 (en) * 2009-11-06 2015-12-15 Toyota Jidosha Kabushiki Kaisha Vehicle gateway device
JP2012101788A (en) * 2011-12-01 2012-05-31 Hitachi Automotive Systems Ltd In-vehicle gateway device
US20130318541A1 (en) * 2012-05-22 2013-11-28 Avaya Inc. System and method for dynamic influencing of sequence vector by sequenced applications
KR20150043732A (en) * 2013-10-15 2015-04-23 현대자동차주식회사 System and method for software update of vehicle controller
KR20150076846A (en) * 2013-12-27 2015-07-07 기아자동차주식회사 System and method for acquiring data of electronic control unit

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110908871A (en) * 2019-11-26 2020-03-24 安徽江淮汽车集团股份有限公司 Data management method, device, equipment and storage medium based on vehicle control unit

Similar Documents

Publication Publication Date Title
US20200356356A1 (en) Method and device for wirelessly updating software for vehicle
WO2015056870A1 (en) Crum chip, image forming device for verifying consumable unit comprising the crum chip, and methods thereof
WO2013065915A1 (en) Method for interworking trust between a trusted region and an untrusted region, method, server, and terminal for controlling the downloading of trusted applications, and control system applying same
WO2012134080A2 (en) Method and apparatus for separating in order to upgrade software remotely in m2m communication
WO2018076868A1 (en) Data synchronization method, device and system, storage medium and server
WO2019054779A1 (en) Electronic device for processing message and method for operating same
WO2017047928A1 (en) Server and user terminal
WO2020220413A1 (en) Zero knowledge proving method and system for personal information, and storage medium
WO2021012481A1 (en) System performance monitoring method and apparatus, device, and storage medium
WO2020167095A1 (en) Method and apparatus for registering api provider domain function entities on capif core function entity
WO2013047997A1 (en) Method, device, and system for downloading contents on the basis of a rights verification
WO2023033588A1 (en) System for controlling data flow in virtualization terminal, and method thereof
WO2016163634A1 (en) Transmission/reception apparatus of security gateway for physical unidirectional communication performing security tunneling and data re-transmission, and data transmission method using same
WO2023090755A1 (en) System for controlling network access of virtualization instance, and method therefor
WO2020204452A1 (en) Method for transmitting data, and device therefor
WO2018076863A1 (en) Data storage method, apparatus, storage medium, server and system
WO2023120906A1 (en) Method for receiving firmware and method for transmitting firmware
WO2018076873A1 (en) Data sharing method, apparatus, medium, electronic device and system
WO2022231304A1 (en) System for controlling controller-based network access, and method therefor
WO2017138787A1 (en) Method and device for wirelessly updating software for vehicle
WO2024177382A1 (en) System for controlling network access and method therefor
WO2024177386A1 (en) System for controlling network access, and method therefor
WO2013183944A1 (en) Apparatus and method for transmitting and receiving files in general purpose device
WO2019117644A1 (en) Electronic device for controlling registration session, and operation method therefor; and server, and operation method therefor
WO2024043613A1 (en) Server device for providing curriculum vitae generation and management service, and operating method thereof

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17750479

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2017750479

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2017750479

Country of ref document: EP

Effective date: 20180911