WO2018123242A1 - ソフトウェア更新装置、ソフトウェア更新システム - Google Patents

ソフトウェア更新装置、ソフトウェア更新システム Download PDF

Info

Publication number
WO2018123242A1
WO2018123242A1 PCT/JP2017/038792 JP2017038792W WO2018123242A1 WO 2018123242 A1 WO2018123242 A1 WO 2018123242A1 JP 2017038792 W JP2017038792 W JP 2017038792W WO 2018123242 A1 WO2018123242 A1 WO 2018123242A1
Authority
WO
WIPO (PCT)
Prior art keywords
update
software
unit
trigger
server
Prior art date
Application number
PCT/JP2017/038792
Other languages
English (en)
French (fr)
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 US16/473,929 priority Critical patent/US11645062B2/en
Priority to EP17886794.1A priority patent/EP3564822A4/en
Priority to CN201780080696.5A priority patent/CN110114761B/zh
Publication of WO2018123242A1 publication Critical patent/WO2018123242A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G06F13/12—Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor
    • G06F13/124—Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor where hardware is a sequential transfer control unit, e.g. microprocessor, peripheral processor or state-machine
    • G06F13/128—Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor where hardware is a sequential transfer control unit, e.g. microprocessor, peripheral processor or state-machine for dedicated transfers to a network
    • 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/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
    • 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
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/02—Registering or indicating driving, working, idle, or waiting time only
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 

Definitions

  • the present invention relates to a software update device and a software update system.
  • the software update device is a software update device connected to one or more other software update devices and a server via a network, and a receiving unit that receives update data from the server; An update unit that updates software using the update data, a communication unit that communicates with the other software update device, and an update opportunity that describes conditions for updating the software including reception of an update trigger.
  • An update opportunity receiving unit that receives from the server, a notification information receiving unit that receives notification information including a condition for transmitting the update trigger to the other software update device, and the other software update based on the notification information
  • An update trigger notification unit for transmitting the update trigger to a device, and the update from the other software update device It comprises an update trigger receiving unit for receiving the trigger, and an update start determination unit that executes the software update to the update the update unit and determines that the trigger all the conditions described in are met.
  • a software update device is a software update device connected to one or more other software update devices and a server via a network, and a receiving unit that receives update data from the server; An update unit that updates software using the update data, a communication unit that communicates with the other software update device, and an update opportunity that describes conditions for updating the software including reception of an update trigger.
  • An update trigger receiving unit that receives from the server, an update trigger receiving unit that receives the update trigger from the other software update device, and the update unit upon determining that all the conditions described in the update trigger are satisfied
  • An update start determination unit for executing the software update.
  • a software update device is a software update device connected to one or more other software update devices and a server via a network, and a receiving unit that receives update data from the server; An update unit that updates the software using the update data, a communication unit that communicates with the other software update device, and an update trigger that receives an update trigger that describes the conditions for updating the software from the server A receiving unit; a notification information receiving unit that receives a notification information including a condition for transmitting an update trigger to the other software updating device; and the update trigger is transmitted to the other software updating device based on the notification information.
  • the update trigger notification unit to be executed and before determining that all the conditions described in the update trigger are satisfied.
  • a software update system is a software update system including a plurality of software update devices and a server, and the server includes a distribution unit that distributes update data for updating software, The plurality of software update devices communicate with a reception unit that receives the update data from the server, an update unit that updates the software using the update data, and the server and other software update devices.
  • a communication unit an update trigger receiving unit that receives an update trigger describing a condition for updating the software including reception of an update trigger from the server, and a condition for transmitting the update trigger to the other software update device
  • a notification information receiving unit for receiving notification information from the server, and the notification information based on the notification information
  • An update trigger notification unit that transmits the update trigger to the software update device, an update trigger reception unit that receives the update trigger from the other software update device, and all conditions described in the update trigger are satisfied
  • An update start determination unit that causes the update unit to update the software when it is determined that the update has been performed.
  • the software can be updated while satisfying the software dependency.
  • the figure which shows the structure of the software update system in 1st Embodiment, and a functional block The figure which shows the hardware constitutions of a 1st update apparatus.
  • Diagram showing server hardware configuration The figure which shows the structure of 1st client tree DB.
  • the figure which shows the structure of 2nd client tree DB Diagram showing the configuration of the server tree DB
  • the figure which shows the structure of the update opportunity contained in 1st client tree DB The figure which shows the structure of the update opportunity contained in 2nd client tree DB
  • the figure which shows the structure of the notification information contained in 1st client tree DB The figure which shows the structure of the notification information contained in 2nd client tree DB
  • First half of sequence diagram for software update Second half of sequence diagram for software update
  • Flow chart showing operation when notification information is received from server Flow chart showing the operation when an update opportunity is received from the server
  • the figure which shows the hardware constitutions of 1st ECU The figure which shows the outline of 1st client tree DB in 2nd Embodiment.
  • FIG. 1 is a diagram illustrating a configuration and functional blocks of the software update system S according to the first embodiment.
  • the software update system S includes a vehicle 1 and a server 2 connected to each other by a wide area network, for example, the Internet 5.
  • the vehicle 1 includes a first update device 10, a second update device 11, and a LAN network 18.
  • the first update device 10 communicates with the second update device 11 via the LAN network 18.
  • the first update device 10 and the second update device 11 communicate with the server 2.
  • the first update device 10 and the second update device 11 have the same hardware configuration and the same function. However, the data stored in the first update device 10 and the second update device 1 and the software to be updated are different. Below, the structure of the 1st update device 10 is mainly demonstrated, and the difference with the 1st update device 10 is demonstrated about the 2nd update device 11. FIG.
  • the first update device 10 updates the software “ABC” installed in the first update device 10
  • the second update device 11 uses the software “PQR” installed in the second update device 11.
  • Update The software “ABC” and the software “PQR” may be one program operating on the OS or a plurality of programs. Further, it may be a part of the OS such as a kernel or the entire OS.
  • the first update device 10 includes an update management unit 30, an update unit 31, an HMI 34, and a communication unit 33.
  • the update unit 31 updates software (not shown) in the first update device 10 using update data received from the server 2.
  • the HMI 34 is a human machine interface, that is, an interface unit with a user, and accepts presentation of information using sound and video to the user and input from the user. However, the HMI 34 may not function as a physical interface with the user, but may function as an interface control unit that controls a device that includes an interface with the user.
  • the communication unit 33 communicates with the server 2, the second update device 11, and an ECU (not shown) provided in the vehicle 1.
  • the update management unit 30 includes a first control unit 71, a first client tree DB 72, an update data acquisition unit 73, an update start determination unit 40, an update trigger reception unit 41, a notification information reception unit 42, and an update completion.
  • a detection unit 43, an update trigger reception unit 44, an update trigger notification unit 45, an ignition reception unit 46, and a line state detection unit 47 are provided.
  • the first control unit 71 outputs an operation command to each component of the update management unit 30.
  • the first client tree DB 72 is a tree-like database in which information related to the first update device 10 is stored. The configuration of the first client tree DB 72 will be described later with reference to the drawings.
  • the update data acquisition unit 73 acquires update data, which is data necessary for updating the software of the first update device 10 from the server 2, and stores the update data in a storage described later.
  • the update start determination unit 40 operates the update unit 31 when it is determined that the update unit 31 is in a state of starting to update software based on an update trigger described later received by the update trigger reception unit 41.
  • the update trigger describes a condition for updating the software, and the update start determination unit 40 determines whether or not this condition is satisfied from the reception of an update trigger (to be described later), the state of the vehicle, and the like.
  • the update opportunity receiving unit 41 stores the update opportunity from the server 2, which will be described later.
  • the notification information receiving unit 42 receives notification information described later from the server 2 and stores it in a storage described later.
  • the update completion detection unit 43 detects that the software update by the update unit 31 has been completed, and transmits it to the update trigger notification unit 45.
  • the update trigger receiving unit 44 receives an update trigger transmitted by the first update device 10 and the second update device 11. That is, in the present embodiment, the first update device 10 may transmit an update trigger to itself.
  • the update trigger receiving unit 44 stores the received update trigger in a storage described later.
  • the update trigger notification unit 45 transmits an update trigger based on the description information described later.
  • the ignition receiving unit 46 acquires the operating state of the engine of the vehicle 1 or the setting state of the ignition switch, and notifies the update start determining unit 40 and the update trigger notifying unit 45.
  • the ignition receiver 46 may notify the state every predetermined time, and notifies when the state has changed, for example, when the ignition is turned on or off, or when the engine is stopped. May be.
  • the line state detection unit 47 acquires the connection state of the first update device 10 to the Internet 5 and notifies the update start determination unit 40 and the update trigger notification unit 45.
  • the line state detection unit 47 may notify the state every predetermined time, or may notify when the state has changed. However, the line state detection unit 47 may determine and notify whether or not an access to a specific URI is possible instead of whether or not the connection to the Internet 5 is possible. For example, it may be determined whether or not access to a URI storing resources necessary for providing a predetermined online service is possible.
  • the second update device 11 includes an update management unit 80, an update unit 81, a communication unit 83, and an HMI 84 as its functions.
  • the update management unit 80, the update unit 81, the communication unit 83, and the HMI 84 correspond to the update management unit 30, the update unit 31, the communication unit 33, and the HMI 34 of the first update device 10, respectively.
  • the update management unit 80 includes a second control unit 91 and a second client tree DB 92.
  • the second control unit 91 and the second client tree DB 92 correspond to the first control unit 71 and the first client tree DB 72 of the first update device 10, respectively.
  • the server 2 includes a server control unit 61, a server tree DB 62, and a data providing unit 63 as its functions.
  • the server control unit 61 exchanges a prescribed message with the first control unit 71 and the second control unit 91, and realizes software update processing by the first control unit 71 and the second control unit 91. Specific processing and procedures will be described later.
  • the server control unit 61 is a DM (Device Management) server defined in OMA (Open Mobile Alliance), while the first control unit 71 and the second control unit 91 are DM clients defined in OMA.
  • OMA DM is a type of technology used for software update of mobile phones, and is a mechanism for exchanging information necessary for software update between a server and a client via access to a tree-like database.
  • the data providing unit 63 sends various information necessary for software update based on the operation command from the server control unit 61, the request from the first update device 10, and the request from the second update device 11, to the first update device 10, And provided to the second update device 11.
  • the various types of information necessary for software update are update triggers, notification information, and update data, which will be described later. These pieces of information are transmitted using a communication protocol such as HTTP or FTP.
  • FIG. 2 is a diagram illustrating a hardware configuration of the first update device 10.
  • the first update device 10 includes a storage unit 151, a CPU 152, a storage 159, a WAN I / F 154, a CAN I / F 155, a LAN I / F 157, a bus 156, and an HMI 158.
  • the CPU 152 controls information handled by the first update device 10 and operates according to the description of the software stored in the storage unit 151.
  • the storage unit 151 is a memory that temporarily stores information handled by the CPU 152 and exchanges data via the bus 156.
  • the storage 159 is a non-volatile storage device in which software or the like is stored, and may be a hard disk or SSD equipped with a file system, or a storage element such as a flash ROM not equipped with a file system.
  • the storage unit 151, the CPU 152, and the storage 159 correspond to the update management unit 30 and the update unit 31 in FIG.
  • the WAN I / F 154 is an interface that wirelessly transmits and receives information to the server 2 via the Internet 5, and uses various wireless communication standards such as LTE, 3G, 4G, IEEE802.16, IEEE802.11, and infrared rays. Can do.
  • the CAN I / F 155 is an interface of a CAN (Controller Area Network) that is a dedicated network used in the vehicle 1, and information related to the vehicle 1 from an ECU (not shown) mounted on the vehicle 1, such as an ignition state. get.
  • the LAN I / F 157 is an interface connected to the LAN network 18.
  • the WAN I / F 154, the CAN I / F 155, and the LAN I / F 157 correspond to the communication unit 33 in FIG.
  • the HMI 158 includes a device that presents information to the user, such as a liquid crystal display, and a device that receives input from the user, such as a touch panel.
  • the HMI 158 presents information to the user based on the operation command of the CPU 152 and transmits the input from the user to the CPU 152.
  • the HMI 158 corresponds to the HMI 34 in FIG.
  • the above is the hardware configuration of the first update device 10. Since the second update device 11 has the same hardware configuration as the first update device 10 as described above, the description thereof is omitted.
  • FIG. 3 is a diagram illustrating a hardware configuration of the server 2.
  • the server 2 includes a storage unit 180, a CPU 181, a storage 183, a WAN I / F 184, and a bus 182.
  • the CPU 181 of the server 2 controls entry / exit of information handled by the server 2 and operates according to the description of software stored in the storage unit 180.
  • the storage unit 180 is a memory that temporarily stores information handled by the CPU 181 and exchanges data via the bus 182.
  • the storage 183 is a non-volatile storage device that stores software of the first update device 10 and the second update device 11 and retains information retained in the storage unit 180 even after power is turned off.
  • the storage 183 may be a hard disk equipped with a file system, an SSD, a holographic drive, or the like.
  • the storage unit 180, the CPU 181 and the storage 183 correspond to the server control unit 61 and the server tree DB 62 in FIG.
  • the WAN I / F 184 is an interface for wirelessly transmitting and receiving information via the bus 182, and for example, LTE, 3G, 4G, IEEE802.16, IEEE802.11, infrared rays, or the like can be used.
  • the WAN I / F 184 corresponds to the data providing unit 63 in FIG.
  • FIG. 4 is a diagram illustrating a configuration of the first client tree DB 72 provided in the first update device 10.
  • the first client tree DB 72 is a database having a tree structure and includes a plurality of nodes.
  • a node can contain information, but not only the information contained in the node but also the presence / absence of the node and the name of the node may be used for the control described later.
  • the top of the tree structure in the first client tree DB 72 is root 101, and root 101 has three nodes, that is, DevInfo 102, DevDetail 104, and 1st SCM 105.
  • DevInfo 102 device feature information such as 1stVIN 103, which is an identifier of the vehicle 1, is arranged under the control.
  • DevDetail 104 the attached information of the vehicle is stored under the control, but in FIG. 4, the nodes under the DevDetail 104 are omitted.
  • the 1st SCM 105 has a node used for software update.
  • the 1st SCM 105 has a download 106 that is a node related to download and an inventory 110 that is a node for updating software.
  • Download 106 has an ABCv2s 107 indicating a package to be downloaded.
  • This node name means, for example, a package name “ABCv2s”, which is a stable version (Stable) of version 2 of software “ABC”. If there is other software to be downloaded by the first update device 10, it is placed in parallel with ABCv2s 107 under the download 106.
  • the ABCv2s 107 has a Pkg URL 108 that stores the download destination URL of the package, a Status 109 that stores the status relating to the download, and an Operation 110 that has an operation command as a subordinate node.
  • the download 111 is placed under the operation 110 based on the command from the server 2
  • the update data acquisition unit 73 is operated to download the package “ABCv2s” from the URL indicated by the PkgURL 108.
  • the nodes below ABCv2s107 are added from the server 2 via the Internet 5.
  • the Inventory 110 arranged in parallel with the Download 106 under the 1st SCM 105 has Delivered 121 and Deployed 130 nodes under it.
  • Information under which the software is updated by using the downloaded package is stored under Delivered 121.
  • the Delivered 121 has a node of ABCv2s122 having the name of the downloaded package under the subordinate.
  • the ABCv2s 122 has a status 123 in which a status related to update is stored and an operation 124 having an operation command as a subordinate node.
  • the Operation 124 is arranged based on a command from the server 2 and has an Install 125 that is one of the conditions for executing the update and an Ext 126 for storing an additional condition for executing the update.
  • An update opportunity 191 existing under the Ext 126 stores an additional condition for executing the update. That is, when a node named Install125 exists and all the conditions stored in the update opportunity 191 are satisfied, installation of the downloaded package “ABCv2s”, that is, update of the software “ABC” is started. The configuration of the update opportunity 191 will be described later.
  • Deployed 130 has a node having the name of software, that is, ABC 131 under the subordinate.
  • the ABC 131 includes an AvailableVersion 132 in which the latest available version number is stored, a Version 133 in which the current version number is stored, and an Ext 137 in which the notification information 195 is subordinated.
  • the notification information 195 will be described later.
  • FIG. 5 is a diagram illustrating a configuration of the second client tree DB 92 provided in the second update device 11.
  • the second client tree DB 92 is a database having a tree structure and includes a plurality of nodes.
  • the configuration of the second client tree DB 92 is substantially the same as that of the first client tree DB 72. That is, in principle, each node of the second client tree DB 92 is obtained by changing the sign 100 of each node constituting the first client tree DB 72 from “1” to “2”.
  • the PQRv3s 207 is placed under the download 206.
  • This node name means a package name “PQRv3s” which is a stable version of software version 3 “PQR”.
  • PQRv3s 222 having the same name as the package name to be downloaded is placed under Delivered 221 in which information for updating software using the downloaded package is stored.
  • a PQR 231 that is a node having the name of the software is placed under the deployed 230 in which the current information of the software is stored.
  • FIG. 6 is a diagram illustrating a configuration of the server tree DB 62 provided in the server 2.
  • the server tree DB 62 is a database having a tree structure and includes a plurality of nodes.
  • the server tree DB 62 stores information on a plurality of update devices mounted on a plurality of vehicles. Information about the update device can be obtained by duplicating a part of a database provided in each update device via communication. That is, the server tree DB 62 includes some nodes of the first client tree DB 72 and some nodes of the second client tree DB 92.
  • the vertex of the tree structure in the server tree DB 62 is root 1001, and it has 1st VIN 1010, 2nd VIN 1020,. Information for each vehicle is stored under these nodes.
  • the 1st VIN 1010 includes DevInfo 1002, DevDetail 1004, 1st SCM 1105, and 2nd SCM 1205, which are nodes that store information on the vehicle 1 under the control.
  • the nodes below DevInfo 1002 correspond to the nodes below DevInfo 102 in the first client tree DB 72 and the nodes below DevInfo 202 in the second client tree DB 92.
  • the DevDetail 1004 corresponds to the DevDetail 104 in the first client tree DB 72 and the DevDetail 204 in the second client tree DB 92.
  • Each node below 1st SCM 1105 corresponds to each node below 1st SCM 105 in the first client tree DB 72. That is, the code “11xx” in the server tree DB 62 corresponds to the code “1xx” in the first client tree DB 72.
  • Each node below 2nd SCM 1205 corresponds to each node below 2nd SCM 205 in the second client tree DB 92. That is, the code “12xx” in the server tree DB 62 corresponds to the code “2xx” in the second client tree DB 92.
  • the update opportunity 191 included in the first client tree DB 72 and the update opportunity 291 included in the second client tree DB 92 will be described with reference to FIGS. 7 and 8. As described above, an additional condition for executing the update is stored in the update opportunity. Since the configurations of the update opportunity 191 and the update opportunity 291 are similar, the update opportunity 191 will be mainly described, and the update opportunity 291 will explain the differences from the update opportunity 191.
  • the update opportunity 191 has three nodes, that is, a vehicle state 1911, a first update device 1914A, and a second update device 1914B.
  • General update conditions are stored below the vehicle state 1911
  • update conditions related to the first update device 10 are stored below the first update device 1914A
  • the second update device 11 is stored below the second update device 1914B.
  • the update condition for is stored.
  • the parent node may be omitted.
  • the first update device 1914A may not be provided.
  • the vehicle state 1911 has IGN information 1912 and user permission 1913 under its control.
  • the IGN information 1912 takes a value of “ON” or “OFF”, and indicates that one of the update conditions is that the ignition is operated “ON” or “OFF”.
  • the user permission 1913 indicates that one of the update conditions is to receive an update permission from the user.
  • the first update device 1914A includes three nodes connected in series under the control, ABC 1915A, Download 1916A, and Version 1917A. These nodes indicate that one of the update conditions is that the version indicated by the version 1917A of the software named “ABC” in the first update device 10 is “downloaded”.
  • the second update device 1914B has three nodes connected in series under the control, PQR 1915B, Install 1916B, and Version 1917B. These nodes indicate that one of the update conditions is that the version indicated by the version 1917B of the software named “PQR” in the second update device 11 is “installed”.
  • the additional condition for executing the update is that the ignition of the vehicle 1 is in a predetermined state, and permission is obtained from the user.
  • the predetermined version of the software “ABC” has been downloaded by the first update device 10, and the predetermined version of the software “PQR” is installed in the second update device 11.
  • the update opportunity 191 adds an additional condition for installing the ABCv2s 122, in other words, an addition for updating the software “ABC” to the version “2”. Conditions.
  • the update opportunity 291 has three nodes under its control, that is, a vehicle state 2911, a first update device 2914A, and a second update device 2914B.
  • the vehicle state 2911 has a line state 2912 under its control.
  • the line state 2912 indicates that the condition is that the connection with the Internet 5 is disconnected.
  • the configurations of the first update device 2914A and the second update device 2914B are the same as those of the first update device 1914A described in FIG.
  • the additional condition for executing the update from the information stored below the update trigger 291 is that the connection with the Internet 5 is disconnected and the predetermined version of the software “ABC” Has been downloaded by the first update device 10 and a predetermined version of the software “PQR” has been downloaded by the second update device 11.
  • the update opportunity 291 is an additional condition for installing the PQRv3s 222, in other words, an addition for updating the software “PQR” to the version “3”.
  • the notification information 195 included in the first client tree DB 72 and the notification information 295 included in the second client tree DB 92 will be described with reference to FIGS.
  • the notification information 195 includes information on conditions under which the update trigger notification unit 45 transmits an update trigger, a transmission destination, and transmission contents.
  • the notification information 195 has two nodes, a download completion 1951A and an installation completion 1951B.
  • the information about the update trigger notified after the completion of download of the package is stored below the download completion 1951A.
  • the download completion 1951A has a first update device 1952A and a second update device 1952B under its control. However, in the present embodiment, the first update device 1952A and the second update device 1952B have no meaning in the node names themselves.
  • the first update device 1952A has three nodes, a destination 1953A, a package 1954A, and a Version 1955A.
  • Information indicating the transmission destination of the update trigger for example, the IP address or loopback address (127.0.0.1) of the first update device 10 is stored in the destination 1953A.
  • the package 1954A indicates that the name of the package is included in the update trigger.
  • Version 1955A indicates that updated version information is included in the update trigger.
  • the configuration of the second update device 1952B is the same as that of the first update device 1952A.
  • Install Complete 1951B stores information related to the update trigger notified under the condition that installation is completed. However, in the example shown in FIG. 9, there is no update trigger that requires installation completion as a condition, so there are no subordinate nodes.
  • the notification information 295 includes information on a condition, a transmission destination, and transmission contents for transmitting an update trigger by the update trigger notification unit of the second update device 11.
  • the notification information 295 is different from the notification information 195 in the presence or absence of a node and the value stored in the node, but the configuration is the same as the notification information 195, and the description of the configuration is omitted. To summarize what is shown in FIG. 10, the following two points are shown.
  • the first point is that when the download of the package “PQRv3s” is completed, an update trigger including the name and version information of the downloaded package is transmitted to the destinations 2953A and 2953B.
  • the second point is that when the installation of the package “PQRv3s” is completed, an update trigger including the name and version information of the installed package is transmitted to the destination 2953C.
  • the version of the software “ABC” provided in the first update device 10 is “1”, and the version of the software “PQR” provided in the second update device 11 is “2”.
  • the first client tree DB 72 has no nodes under the Download 106 and no nodes under the Delivered 121.
  • the second client tree DB 92 has no nodes under the Download 206 and no nodes under the Delivered 221.
  • the first control unit 71 of the first update device 10 transmits VIN information for identifying the vehicle to the server control unit 61 (S301).
  • the server 2 identifies that the vehicle to be communicated is the vehicle 1, and obtains information on the latest version of the software included in the vehicle 1 from a database (not shown).
  • the latest version information is, for example, that the latest version of the software “ABC” is “2” and the latest version of the software “PQR” is “3”.
  • the server control unit 61 transmits the acquired latest version information and a version information acquisition request to the first control unit 71 (S302).
  • the first control unit 71 stores the received latest version information in the first client tree DB 72 (S350). More specifically, the value “2” is stored in the node of AvailableVersion 132 under the ABC 131 under the Deployed 130 in the first client tree DB 72.
  • the information on the latest version received from the server 2 includes information on the software “PQR”. However, since the information about the software “PQR” is not stored in the first client tree DB 72, the information on the software “PQR” is stored. Information is discarded. Subsequently, the first control unit 71 acquires information on all nodes below the deployed 130 from the first client tree DB 72 (S351), and transmits the information to the server control unit 61 (S303).
  • the server control unit 61 stores the received information of nodes below Deployed 130 as information below Deployed 1130 of the 1st SCM 1105 in the server tree DB 62. Then, it is determined whether or not the software needs to be updated based on the stored information of the nodes below Deployed 1130. That is, the server control unit 61 compares the AvailableVersion 1132 and the Version 1133, and determines that the update is necessary when the AvailableVersion 1132 is newer (S352).
  • the server control unit 61 acquires notification information 195 and software update information from the storage 183 provided in the server 2 (S361). More specifically, the software update information is a node below Download 106 in FIG. 4 and a node excluding Download 111. Then, the server control unit 61 transmits software update information and notification information 195 to the first control unit 71 (S304). The first control unit 71 stores the received information in the first client tree DB 72. Specifically, the notification information 195 is added under Ext 137 (S362), and the software update information is added as Download 106 under 1st SCM 105 (S353). Then, a response indicating that the update information has been set is returned to the server control unit 61 (S305).
  • S362 Ext 137
  • S353 1st SCM 105
  • the server control unit 61 transmits a download execution instruction to the first control unit 71 in order to cause the first update device 10 to download a package called ABCv2s107 (S308).
  • This instruction causes the download 111 to be created under the operation 110 of the first client tree DB 72.
  • the first control unit 71 instructs the update data acquisition unit 73 to execute the download (S356).
  • the update data acquisition unit 73 acquires update data from the URL described in the PkgURL 108.
  • the update data acquisition unit 73 requests the data providing unit 63 for a package called ABCv2s (S309), and acquires the package (S310).
  • the update data acquisition unit 73 notifies the first control unit 71 that the download has been completed (S357).
  • the first control unit 71 executes an update trigger notification transmission process to be described later (S368).
  • the first control unit 71 transmits that the download has been completed to the server control unit 61 (S311).
  • the server control unit 61 transmits to the first control unit 71 a software update permission request message for confirming to the user whether the software update may be executed (S306).
  • the first control unit 71 causes the HMI 34 to display a message for requesting software update permission (S354).
  • the HMI 34 displays the requested message, receives a response from the user, and returns it to the first control unit 71 (S355).
  • the first control unit 71 transmits information indicating permission or non-permission to the server control unit 61 (S307).
  • the server control unit 61 acquires the update opportunity 1191 from the storage 183 (S360), and transmits it to the first control unit 71 together with a message instructing execution of software update (S314).
  • the update opportunity 1191 may be read from the server tree DB 62.
  • the first control unit 71 stores the received update trigger as the update trigger 191 in the first client tree DB 72 (S363), and creates a node Install125 under the operation 124 based on a message instructing execution of software update. Then, the first control unit 71 interprets the update trigger 191 and waits for an update trigger (S365), and determines whether all the update triggers are prepared every predetermined time (S366). Here, since all the update triggers are not prepared, the wait for the update trigger (S365) is continued. Specifically, the update trigger 191 shown in FIG. 7 waits for an update trigger indicating the installation completion of the version “3” of the software “PQR” in the second update device 11.
  • the processing from the VIN transmission (S301A) by the second update device 11 to the storage of the update opportunity 291 in the second client tree DB 92 (S363A) is the same as the processing of S301 to S363 by the first update device 10.
  • the line state 2912 is offline as shown in FIG. 8, the download of the software “ABC” is completed in the first update device 10, and the download of the software “PQR” is completed in the second update device 11. Therefore, all the conditions are satisfied when S363A is executed. Therefore, the second control unit 91 transmits an update start command to the update unit 81 (S317), and causes the update unit 81 to execute software update processing (S390).
  • the update unit 81 notifies the second control unit 91 when the update process is completed (S318).
  • the second control unit 91 receives a notification that the update process has been completed, the second control unit 91 transmits an update trigger based on the notification information 295 (S368, S369).
  • the notification information 295 indicates that the name and version number of the package that has been updated are notified to the destination 472 as shown in FIG. Therefore, since the destination 472 indicates the first update device 10, the second controller 91 has completed the installation including “PQRv3s” that is the name of the package that has been updated and “3” that is the version number. Is sent to the first update device 10.
  • the first control unit 71 that has received the update trigger determines that all the update triggers are available (S366), and causes the update unit 31 to start updating (S317).
  • the update unit 31 executes the software update process 390, and when the update process is completed, the update unit 31 outputs a notification indicating the completion to the first control unit 71 (S318).
  • FIG. 13 is a diagram showing an example of a message for inquiring whether the user can update the HMI 34 in S354 of FIG.
  • the display shown in FIG. 13 is displayed on the HMI 34 included in the first update device 10.
  • the first update device 10 also has a car navigation function, and a message for inquiring whether or not update is possible is displayed on the interface screen used for car navigation.
  • FIG. 14 is a diagram illustrating an example of a message for inquiring whether a user can update a device displayed on a device other than the first update device 10 when the HMI 34 operates as an HMI control unit. In the example shown in FIG. 14, it is displayed on the mobile terminal owned by the user.
  • FIG. 15 is a flowchart showing processing when the first update device 10 receives the notification information 195 from the server 2.
  • the CPU 152 searches for a node in the first client tree DB 72 that stores the received notification information 195.
  • the CPU 152 stores the received notification information 195 in the node specified in step S2103, and ends the process shown in FIG.
  • FIG. 16 is a flowchart showing processing when the first update device 10 receives an update opportunity 191 from the server 2.
  • the CPU 152 searches for a node in the first client tree DB 72 that stores the received update opportunity 191.
  • CPU 152 stores received update opportunity 191 in the node identified in step S2107, and ends the process shown in FIG.
  • FIG. 17 is a flowchart showing processing when the first update device 10 receives an update execution instruction from the server 2.
  • the Install 125 node is created and one of the conditions for executing the update is satisfied as described above, but the description of creating the Install 125 node is omitted here.
  • step S2110 the CPU 152 acquires the update opportunity 191 from the first client tree DB 72.
  • step S2111 CPU 152 waits for an update trigger and waits for vehicle conditions to be satisfied.
  • step S2120 CPU 152 stores the received update trigger in storage 159 or storage unit 151.
  • step S2112 CPU 152 determines whether all update triggers described in update opportunity 191 have been prepared, in other words, all additional conditions for executing update have been satisfied.
  • the CPU 152 proceeds to step S2113 when determining that all the update triggers have been prepared, and returns to step S2111 when determining that any one of the conditions is not satisfied.
  • step S2113 the CPU 152 executes software update processing.
  • step S2114 CPU 152 determines whether or not the update is completed, and stays in step S2114 until it is determined that the update is completed. If it is determined that the update is completed, the process proceeds to step S2115.
  • step S2115 the CPU 152 reads the notification information 195 from the first client tree DB 72.
  • step S2117 information to be notified when the update is completed is extracted from the notification information 195, and a notification that the update is completed, that is, an update trigger is transmitted.
  • the notification information 195 is the example shown in FIG. 9, there is no node under the installation completion 1951B, so the processing shown in FIG. 17 is terminated without executing this step.
  • step S2118 it is determined whether or not the update trigger has been transmitted to all the target destinations.
  • the processing shown in FIG. If it is determined that there is, the process returns to step S2117.
  • FIG. 18 is a flowchart showing processing when the first update device 10 receives a download execution instruction from the server 2.
  • the CPU 152 causes the update data acquisition unit 73 to acquire update data.
  • the download is executed between the update data acquiring unit 73 and the data providing unit 63, and any protocol may be used as long as the protocol can transfer data such as HTTP or FTP.
  • the acquisition destination of the update data is stored as PkgURL 108 in the first client tree DB 72, for example.
  • CPU 152 determines whether or not downloading of update data is completed. This determination can be made, for example, based on whether or not a download completion notification is received from the update data acquisition unit 73. If the download is complete, the process proceeds to step S2203, and if it is determined that the download is not complete, the process stays at step S2202.
  • step S2203 the CPU 152 reads the notification information 195 from the first client tree DB 72.
  • step S2204 information to be notified when the download is completed is extracted from the notification information 195, and a notification that the download is completed, that is, an update trigger is transmitted.
  • the notification information 195 is an example shown in FIG. 9, an update trigger is transmitted to two devices, and the update trigger includes the name and version of the package that has been downloaded.
  • step S2205 it is determined whether or not the update trigger has been transmitted to all the target destinations. If it is determined that the update trigger has been transmitted to all the targets, the processing shown in FIG. If it is determined that there is, the process returns to step S2204.
  • the update opportunity 191 and the notification information 195 can be acquired from the first client tree DB 72, so there is no problem in software update. . Also in this case, since the update is not executed unless the condition defined by the update trigger 191 is satisfied, even if the connection with the server 2 is disconnected, by setting the update trigger 191 appropriately, the dependency relationship between the software is set. Software can be updated while maintaining.
  • the first update device 10 that is a software update device is connected to one or more software update devices, that is, the second update device 11 and the server 2 via the Internet 5.
  • the first update device 10 includes an update data acquisition unit 73 that receives update data from the server 2, an update unit 31 that updates software using the update data, and a communication unit 33 that communicates with other software update devices.
  • an update trigger receiver 41 that receives from the server 2 an update trigger 191 that describes the conditions for updating the software including the reception of the update trigger, and notification information 195 that includes a condition for notifying other software update devices.
  • an update trigger notification unit 45 that transmits an update trigger to another software update device based on the notification information 195
  • an update trigger reception unit 44 that receives an update trigger from another software update device. If it is determined that all the conditions described in the update opportunity 191 are satisfied, the update unit 31 updates the software. And a update start determination unit 40 to execute.
  • the update start determination unit 40 updates the software when all the conditions described in the update trigger 191 received from the server 2 are satisfied, so that the software can be updated while satisfying the software dependency. For example, when there is a dependency relationship between the software “ABC” installed in the first update device 10 and the software “PQR” installed in the second update device 11, the software can be obtained by using an appropriately set update opportunity 191. The software can be updated while satisfying the dependency. That is, as shown in FIG. 7, the software “ABC” of the first update device 10 can be updated on condition that a predetermined version of the software “PQR” is installed in the second update device 11.
  • the first update device 10 since the first update device 10 includes the update trigger notification unit 45, an update trigger can be transmitted to another software update device based on the notification information 195. That is, the software can be updated based on the reception of the update trigger by another software update device. Further, the first update device 10 can update the software using the received information even after the connection with the server 2 is disconnected, after receiving the update opportunity 191, the notification information 195, and the update data from the server 2. It can be performed.
  • the notification information 195 includes sending an update trigger when the software is updated.
  • the update trigger notification unit 45 transmits an update trigger when the update unit 31 completes the software update. Therefore, the first update device 10 can notify other software update devices of the software update in the first update device 10. That is, the software can be updated by another software update device while satisfying the software dependency.
  • the notification information 195 includes that an update trigger is transmitted when the update data acquisition unit 73 receives the update data.
  • the update trigger notification unit 45 transmits an update trigger when the update data acquisition unit 73 receives the update data. Therefore, the first update device 10 performs the update on the condition that the other device has received the update data, in other words, at least a part of the advance preparation for the other device to execute the update is completed. Can start.
  • the first update device 10 is mounted on the vehicle 1.
  • the update opportunity 191 includes turning on or off the ignition of the vehicle 1.
  • the update start determination unit 40 can detect whether the ignition is on or off. By setting the ignition off as the update start condition, the software related to the traveling of the vehicle 1 can be safely updated. In general, when the user turns off the ignition, the user does not use the vehicle 1 for a while. Therefore, even if an update requiring a long process is performed, the user is not hindered. By setting the ignition on as a condition for starting the update, the update can be executed when the user can easily select the timing.
  • the first update device 10 is mounted on the vehicle 1 connected to the Internet 5.
  • the update opportunity 191 includes disconnection from the Internet 5.
  • the update start determination unit 40 can detect disconnection. By setting the disconnection with the Internet 5 as a condition for starting the update, it is possible to reduce a decrease in availability due to the software update.
  • the details are as follows. That is, software that requires connection to the Internet 5 for operation cannot operate while the connection to the Internet 5 is disconnected. When software update is started, the software cannot be used until the update is completed. Therefore, by reducing the time when the software cannot be used due to the update, the time when the software cannot be used due to the update is overlapped with the time when the software cannot be used due to the disconnection with the Internet 5, thereby reducing the decrease in availability due to the software update.
  • the first update device 10 includes a storage unit 151 and a storage 159.
  • the update trigger receiving unit 44 stores the received update trigger in the storage unit 151 or the storage 159.
  • the update start determination unit 40 determines update start including the update trigger stored in the storage unit 151 or the storage 159. Therefore, the update can be started even when the update conditions are satisfied at different timings.
  • the update opportunity 191 may not include nodes in the vehicle state 1911 or lower, and different nodes may be arranged under the vehicle state 1911. For example, nodes representing conditions relating to time and conditions relating to the state of the engine of the vehicle 1 may be arranged.
  • Modification 2 Although the conditions for the first update device 10 and the second update device 11 are stored in the update opportunity 191, only the conditions for either one may be stored. Also, conditions relating to two or more software may be stored for one update device, and conditions other than “Download” and “Install”, for example, “Remove” indicating that the software has been deleted may be set for each software. .
  • a node other than the download completion 1951A and the installation completion 1951B may exist under the notification information 195.
  • nodes such as “IGN ON” indicating that the ignition has been turned on and “Update permission” indicating that the user has given permission for updating may exist under the notification information 195. That is, the update trigger notification unit 45 may transmit the update trigger when the ignition is turned on or when an update permission is obtained from the user. This configuration is effective when another update management apparatus cannot directly obtain ignition information or user permission information.
  • the first client tree DB 72, the second client tree DB 92, and the server tree DB 62 are expressed as a tree-like database, that is, a hierarchical database.
  • the format of these databases is not limited to this. Other formats such as a network database and a relational database may be used.
  • the first update device 10 transmits and receives the update trigger. However, the first update device 10 may only transmit the update trigger and may not receive it, or may only receive the update trigger and not transmit. For example, when the first update device 10 only transmits the update trigger and does not receive it, the first update device 10 may not include the update trigger receiving unit 44. When the first update device 10 only receives the update trigger and does not transmit it, the notification information receiving unit 42 and the update trigger notifying unit 45 may not be provided.
  • the software update device is connected to one or more software update devices and servers via a network.
  • the software update device includes a reception unit that receives update data from the server, an update unit that updates software using the update data, a communication unit that communicates with other software update devices, and reception of an update trigger.
  • An update trigger receiver that receives an update trigger that describes the conditions for updating software from the server, an update trigger receiver that receives an update trigger from another software update device, and all the conditions described in the update trigger
  • the update unit includes an update start determination unit that causes the update unit to execute software update.
  • the software update device is connected to one or more software update devices and servers via a network.
  • the software update device includes a receiving unit that receives update data from the server, an update unit that updates software using the update data, a communication unit that communicates with other software update devices, and a condition for updating software.
  • An update opportunity receiver that receives the described update opportunity from the server, a notification information receiver that receives notification information including a condition for notifying other software update devices from the server, and another software update device based on the notification information
  • an update trigger notifying unit that transmits an update trigger that is one of the conditions for updating software is received, and if it is determined that all the conditions described in the update trigger are satisfied, the update unit is updated with software.
  • An update start determination unit that determines an update trigger that is one of the conditions for updating software is received, and if it is determined that all the conditions described in the update trigger are satisfied, the update unit is updated with software.
  • the notification information 195 stored in the first update device 10 does not describe the first update device 10 as a destination, and the update trigger from the first update device 10 to the first update device 10 may not be transmitted. In this case, information indicating that the download has been completed is transmitted to the update start determination unit 40 without going through the update trigger notification unit 45 or the update trigger reception unit 44.
  • FIG. 19 is a diagram illustrating a configuration of the software update system S according to the second embodiment.
  • the vehicle 1 includes a first update device 10, a second update device 11, a LAN network 18, a first ECU 511, a second ECU 512, a third ECU 513, a first CAN network 501, and a second CAN network 502.
  • the first update device 10 and the second update device 11 are connected by a LAN network 18.
  • the first update device 10, the first ECU 511, and the second ECU 512 are connected by a first CAN network 501.
  • the second update device 11 and the third ECU 513 are connected by a second CAN network 502.
  • the first ECU 511 includes software “DEF”
  • the second ECU 512 includes software “GHI”
  • the third ECU 513 includes software “STU”.
  • the first update device 10 updates the software of the first ECU 511 and the second ECU 512.
  • the second update device 11 updates the software of the third ECU 513.
  • FIG. 20 is a diagram illustrating a hardware configuration of the first ECU 511.
  • the first ECU 511 includes a storage unit 170, a CPU 171, a storage 173, a CAN I / F 174, and a bus 172.
  • the CPU 171 of the first ECU 511 controls entry / exit of information handled by the first ECU 511 and operates according to the description of software stored in the storage 173.
  • the storage unit 170 temporarily stores information handled by the CPU 171 and exchanges data with the CPU 171 via the bus 172.
  • the storage 173 is a non-volatile storage device that stores software of the first ECU 511.
  • the first ECU 511 operates with software stored in the storage 173, and the operation of the first ECU 511 can be changed by updating the software.
  • the CAN I / F 174 is an interface for CAN that is a dedicated network used in the vehicle 1, and communicates with the first update device 10 via the first CAN network 501. Software can be received via this interface, and the software stored in the storage 173 can be rewritten.
  • FIG. 21 is a diagram illustrating an outline of the first client tree DB 72 according to the second embodiment.
  • a node of “DEFv2s” and a node of “GHIv4s” that store information of two packages to be downloaded are placed.
  • information on two pieces of software is also stored under the nodes of Delivered 121 and Deployed 130. That is, an update opportunity corresponding to each software is arranged under the Delivered 121, and notification information corresponding to each software is arranged under the Deployed 130. Since the configuration of the second client tree DB 92 is obtained by changing the names of software and packages from the configuration in the first embodiment, the description thereof is omitted.
  • the first updating device 10 is connected to the first ECU 511 and the second ECU 512, and the updating unit 31 updates the software of the first ECU 511 and the second ECU 512. Therefore, even when the first ECU 511 and the second ECU 512 cannot execute control related to the software update, the first ECU 511 and the second ECU 512 do not satisfy the software dependency on the first ECU 511 and the second ECU 512 instead of the first ECU 511 and the second ECU 512. Can be updated.
  • the first update device 10 may update not only the software of the first ECU 511 and the second ECU 512 but also the software of the first update device 10.
  • the second update device 11 may update not only the software of the third ECU 513 but also the software of the second update device 11.
  • the program of the first update device 10 is stored in the storage 159, the first update device 10 has an input / output interface (not shown), and the input / output interface and the first update device 10 can be used when necessary.
  • the program may be read from another device via the medium.
  • the medium refers to, for example, a storage medium that can be attached to and detached from the input / output interface, or a communication medium, that is, a wired, wireless, or optical network, or a carrier wave or digital signal that propagates through the network.
  • some or all of the functions realized by the program may be realized by a hardware circuit or FPGA.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

ソフトウェア更新装置は、１以上の他のソフトウェア更新装置及びサーバとネットワークを介して接続され、サーバから更新用データを受信する受信部と、更新用データを用いてソフトウェアの更新を行う更新部と、他のソフトウェア更新装置と通信する通信部と、更新トリガの受信を含むソフトウェアを更新する条件が記載された更新契機をサーバから受信する更新契機受信部と、他のソフトウェア更新装置に更新トリガを送信する条件を含む通知情報をサーバから受信する通知情報受信部と、通知情報に基づき他のソフトウェア更新装置に更新トリガを送信する更新トリガ通知部と、他のソフトウェア更新装置から更新トリガを受信する更新トリガ受信部と、更新契機に記述されているすべての条件が満たされたと判断すると更新部にソフトウェアの更新を実行させる更新開始判断部とを備える。

Description

ソフトウェア更新装置、ソフトウェア更新システム
　本発明は、ソフトウェア更新装置、およびソフトウェア更新システムに関する。
　近年は自動車の制御に電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）が多用されている。ＥＣＵの動作を司るソフトウェアは、従来は整備士により更新されていたが、このソフトウェアを遠隔で更新するサービスへのニーズが高まっている。例えば、特許文献１には、組み込まれた前記所定のソフトウェアが更新された場合、更新された前記所定のソフトウェアのバージョンを前記通信部から前記他のネットワークデバイスに送信し、更に、前記他のネットワークデバイスからの要求に応じて、更新された前記所定のソフトウェアを前記他のネットワークデバイスに提供し、他方で、前記通信部が前記他のネットワークデバイスに組み込まれた前記所定のソフトウェアのバージョンを受信し、前記判定部が組み込むべき前記所定のソフトウェアの変更を判定した場合、前記他のネットワークデバイスから前記所定のソフトウェアを取得し、組み込まれている前記所定のソフトウェアに替えて、取得した前記所定のソフトウェアを組み込む制御部と、を備えるネットワークデバイスが開示されている。
日本国特開２０１１－９５９５０号公報
　特許文献１に記載されている発明では、ソフトウェアの依存関係を満たしたままソフトウェアを更新することができない。
　本発明の第１の態様によるソフトウェア更新装置は、１以上の他のソフトウェア更新装置及びサーバとネットワークを介して接続されるソフトウェア更新装置であって、前記サーバから更新用データを受信する受信部と、前記更新用データを用いてソフトウェアの更新を行う更新部と、前記他のソフトウェア更新装置と通信する通信部と、更新トリガの受信を含む前記ソフトウェアを更新する条件が記載された更新契機を前記サーバから受信する更新契機受信部と、前記他のソフトウェア更新装置に前記更新トリガを送信する条件を含む通知情報を前記サーバから受信する通知情報受信部と、前記通知情報に基づき前記他のソフトウェア更新装置に前記更新トリガを送信する更新トリガ通知部と、前記他のソフトウェア更新装置から前記更新トリガを受信する更新トリガ受信部と、前記更新契機に記述されているすべての条件が満たされたと判断すると前記更新部に前記ソフトウェアの更新を実行させる更新開始判断部とを備える。
　本発明の第２の態様によるソフトウェア更新装置は、１以上の他のソフトウェア更新装置及びサーバとネットワークを介して接続されるソフトウェア更新装置であって、前記サーバから更新用データを受信する受信部と、前記更新用データを用いてソフトウェアの更新を行う更新部と、前記他のソフトウェア更新装置と通信する通信部と、更新トリガの受信を含む前記ソフトウェアを更新する条件が記載された更新契機を前記サーバから受信する更新契機受信部と、前記他のソフトウェア更新装置から前記更新トリガを受信する更新トリガ受信部と、前記更新契機に記述されているすべての条件が満たされたと判断すると前記更新部に前記ソフトウェアの更新を実行させる更新開始判断部とを備える。
　本発明の第３の態様によるソフトウェア更新装置は、１以上の他のソフトウェア更新装置及びサーバとネットワークを介して接続されるソフトウェア更新装置であって、前記サーバから更新用データを受信する受信部と、前記更新用データを用いてソフトウェアの更新を行う更新部と、前記他のソフトウェア更新装置と通信する通信部と、前記ソフトウェアを更新する条件が記載された更新契機を前記サーバから受信する更新契機受信部と、前記他のソフトウェア更新装置に更新トリガを送信する条件を含む通知情報を前記サーバから受信する通知情報受信部と、前記通知情報に基づき前記他のソフトウェア更新装置に前記更新トリガを送信する更新トリガ通知部と、前記更新契機に記述されているすべての条件が満たされたと判断すると前記更新部に前記ソフトウェアの更新を実行させる更新開始判断部とを備える。
　本発明の第４の態様によるソフトウェア更新システムは、複数のソフトウェア更新装置およびサーバを含むソフトウェア更新システムであって、前記サーバは、ソフトウェアを更新するための更新用データを配信する配信部を備え、前記複数のソフトウェア更新装置は、前記サーバから前記更新用データを受信する受信部と、前記更新用データを用いて前記ソフトウェアの更新を行う更新部と、前記サーバおよび他のソフトウェア更新装置と通信する通信部と、更新トリガの受信を含む前記ソフトウェアを更新する条件が記載された更新契機を前記サーバから受信する更新契機受信部と、前記他のソフトウェア更新装置に前記更新トリガを送信する条件を含む通知情報を前記サーバから受信する通知情報受信部と、前記通知情報に基づき前記他のソフトウェア更新装置に前記更新トリガを送信する更新トリガ通知部と、前記他のソフトウェア更新装置から前記更新トリガを受信する更新トリガ受信部と、前記更新契機に記述されているすべての条件が満たされたと判断すると前記更新部に前記ソフトウェアの更新を実行させる更新開始判断部とを備える。
　本発明によれば、ソフトウェアの依存関係を満たしたままソフトウェアを更新することができる。
第１の実施の形態におけるソフトウェア更新システムの構成、および機能ブロックを示す図 第１更新装置のハードウェア構成を示す図 サーバのハードウェア構成を示す図 第１クライアントツリーＤＢの構成を示す図 第２クライアントツリーＤＢの構成を示す図 サーバツリーＤＢの構成を示す図 第１クライアントツリーＤＢに含まれる更新契機の構成を示す図 第２クライアントツリーＤＢに含まれる更新契機の構成を示す図 第１クライアントツリーＤＢに含まれる通知情報の構成を示す図 第２クライアントツリーＤＢに含まれる通知情報の構成を示す図 ソフトウェア更新に係るシーケンス図の前半 ソフトウェア更新に係るシーケンス図の後半 ＨＭＩがユーザへ更新の可否を問い合わせる表示の一例を示す図 ＨＭＩがＨＭＩ制御部として動作する場合に、ユーザへ更新の可否を問い合わせる表示の一例を示す図 サーバから通知情報を受信した際の動作を表すフローチャート サーバから更新契機を受信した際の動作を表すフローチャート サーバから更新実行指示を受信した際の動作を表すフローチャート サーバからダウンロード実行指示を受信した際の動作を表すフローチャート 第２の実施の形態におけるソフトウェア更新システムの構成を示す図 第１ＥＣＵのハードウェア構成を示す図 第２の実施の形態における第１クライアントツリーＤＢの概略を示す図
―第１の実施の形態―
　以下、図１～図１８を参照して、ソフトウェア更新システムＳの第１の実施の形態を説明する。
　図１は、第１の実施の形態におけるソフトウェア更新システムＳの構成、および機能ブロックを示す図である。ソフトウェア更新システムＳは、広域ネットワーク、たとえばインターネット５により相互に接続される車両１とサーバ２とを含む。
　車両１は、第１更新装置１０と、第２更新装置１１と、ＬＡＮネットワーク１８とを備える。第１更新装置１０は、ＬＡＮネットワーク１８を介して第２更新装置１１と通信する。また、第１更新装置１０および第２更新装置１１は、サーバ２と通信する。第１更新装置１０および第２更新装置１１は同一のハードウェア構成を有し、同一の機能を有する。ただし第１更新装置１０および第２更新装置１に格納されるデータおよび更新対象のソフトウェアが異なる。以下では主に第１更新装置１０の構成について説明し、第２更新装置１１については第１更新装置１０との相違点を説明する。
　本実施の形態では、第１更新装置１０は第１更新装置１０にインストールされているソフトウェア「ＡＢＣ」を更新し、第２更新装置１１は第２更新装置１１にインストールされているソフトウェア「ＰＱＲ」を更新する。ソフトウェア「ＡＢＣ」やソフトウェア「ＰＱＲ」は、ＯＳ上で動作する１つのプログラムでもよいし、複数のプログラム群であってもよい。また、カーネルなどＯＳの一部でもよいし、ＯＳ全体でもよい。
（第１更新装置の機能構成）
　第１更新装置１０は、更新管理部３０と更新部３１とＨＭＩ３４と通信部３３とを備える。更新部３１は、サーバ２から受信する更新用データを用いて第１更新装置１０内の不図示のソフトウェアを更新する。ＨＭＩ３４はヒューマンマシンインタフェース、すなわちユーザとのインタフェース部であり、ユーザへの音や映像を用いた情報の提示、およびユーザからの入力を受け付ける。ただしＨＭＩ３４は、ユーザとの物理的なインタフェースを備えず、ユーザとのインタフェースを備える装置を制御するインタフェース制御部として機能してもよい。通信部３３は、サーバ２、第２更新装置１１、および車両１に備えられる不図示のＥＣＵと通信する。
　更新管理部３０は、第１制御部７１と、第１クライアントツリーＤＢ７２と、更新データ取得部７３と、更新開始判断部４０と、更新契機受信部４１と、通知情報受信部４２と、更新完了検知部４３と、更新トリガ受信部４４と、更新トリガ通知部４５と、イグニッション受信部４６と、回線状態検知部４７と、を備える。
　第１制御部７１は、更新管理部３０の各構成要素に動作指令を出力する。第１クライアントツリーＤＢ７２は、第１更新装置１０に関する情報が格納されたツリー状のデータベースである。第１クライアントツリーＤＢ７２の構成は後に図を用いて説明する。更新データ取得部７３は、サーバ２から第１更新装置１０のソフトウェアの更新に必要なデータである更新用データを取得して、後述するストレージに格納する。
　更新開始判断部４０は、更新契機受信部４１が受信する後述する更新契機に基づき、更新部３１がソフトウェアの更新を開始する状況にあると判定すると更新部３１を動作させる。更新契機にはソフトウェアを更新する条件が記載されており、更新開始判断部４０はこの条件を満たしているか否かを、後述する更新トリガの受信、および車両の状態などから判断する。
　更新契機受信部４１は、サーバ２から更新契機を受信する後述するストレージに格納する。通知情報受信部４２は、サーバ２から後述する通知情報を受信して後述するストレージに格納する。更新完了検知部４３は、更新部３１によるソフトウェアの更新が完了したことを検知し、更新トリガ通知部４５に伝達する。更新トリガ受信部４４は、第１更新装置１０および第２更新装置１１が送信する更新トリガを受信する。すなわち本実施の形態では、第１更新装置１０が自分自身に更新トリガを送信することもある。更新トリガ受信部４４は、受信した更新トリガを後述するストレージに格納する。更新トリガ通知部４５は、後述する通知情報の記載に基づき更新トリガを送信する。
　イグニッション受信部４６は、車両１のエンジンの稼働状態、またはイグニッションスイッチの設定状態を取得し、更新開始判断部４０および更新トリガ通知部４５に通知する。イグニッション受信部４６は、所定時間ごとにその状態を通知してもよいし、状態に変化があった場合、たとえばイグニッションがオンやオフに操作された場合や、エンジンが停止した場合などに通知してもよい。
　回線状態検知部４７は、第１更新装置１０のインターネット５への接続状態を取得し、更新開始判断部４０および更新トリガ通知部４５に通知する。回線状態検知部４７は、所定時間ごとにその状態を通知してもよいし、状態に変化があった場合に通知してもよい。ただし回線状態検知部４７は、インターネット５への接続可否に代えて、特定のＵＲＩへのアクセス可否を判断して通知してもよい。たとえば所定のオンラインサービスの提供に必要なリソースが格納されたＵＲＩへのアクセス可否を判断してもよい。
（第２更新装置の機能構成）
　第２更新装置１１は、その機能として、更新管理部８０と、更新部８１と、通信部８３と、ＨＭＩ８４とを備える。更新管理部８０、更新部８１、通信部８３、およびＨＭＩ８４は、第１更新装置１０の更新管理部３０、更新部３１、通信部３３、およびＨＭＩ３４にそれぞれ対応する。更新管理部８０は、第２制御部９１、および第２クライアントツリーＤＢ９２を含む。第２制御部９１、および第２クライアントツリーＤＢ９２は、第１更新装置１０の第１制御部７１、および第１クライアントツリーＤＢ７２にそれぞれ対応する。図１では更新管理部８０の構成として第２制御部９１および第２クライアントツリーＤＢ９２のみを記載しているが、更新管理部８０は更新管理部３０が備える全ての機能を備える。各機能の説明は、第１更新装置１０と同様なので省略する。
（サーバの機能構成）
　サーバ２は、その機能として、サーバ制御部６１と、サーバツリーＤＢ６２と、データ提供部６３とを備える。
　サーバ制御部６１は、第１制御部７１や第２制御部９１と規定のメッセージをやり取りし、第１制御部７１や第２制御部９１によるソフトウェア更新の処理を実現する。具体的な処理および手順は後述する。
　サーバ制御部６１は、ＯＭＡ（Open Mobile Alliance）において定義されるＤＭ（Device Management）サーバであり、一方、第１制御部７１および第２制御部９１はＯＭＡにおいて定義されるＤＭクライアントである。ＯＭＡ　ＤＭとは、携帯電話のソフトウェア更新で使用される技術の一種であり、ツリー状のデータベースへのアクセスを介してサーバとクライアント間でソフトウェア更新に必要な情報をやりとりする仕組みである。データ提供部６３は、サーバ制御部６１からの動作指令、第１更新装置１０からの要求、および第２更新装置１１からの要求に基づきソフトウェア更新に必要な各種の情報を第１更新装置１０、および第２更新装置１１に提供する。ソフトウェア更新に必要な各種の情報とは、後述する更新契機、通知情報、および更新データである。これらの情報は、ＨＴＴＰやＦＴＰなどの通信プロトコルを用いて送信される。
（第１更新装置のハードウェア構成）
　図２は、第１更新装置１０のハードウェア構成を示す図である。第１更新装置１０は、記憶部１５１と、ＣＰＵ１５２と、ストレージ１５９と、ＷＡＮ　Ｉ／Ｆ１５４と、ＣＡＮ　Ｉ／Ｆ１５５と、ＬＡＮ　Ｉ／Ｆ１５７と、バス１５６と、ＨＭＩ１５８とを備える。
　ＣＰＵ１５２は、第１更新装置１０が扱う情報を制御し、記憶部１５１に保存されているソフトウェアの記述に従い動作する。記憶部１５１は、ＣＰＵ１５２が扱う情報を一時的に保存し、バス１５６を介してデータをやり取りするメモリーである。ストレージ１５９は、ソフトウェアなどが保存される不揮発性の記憶装置であり、ファイルシステムを搭載するハードディスクやＳＳＤなどであってもよいしファイルシステムを搭載しないフラッシュＲＯＭなどの記憶素子であってもよい。記憶部１５１、ＣＰＵ１５２およびストレージ１５９は、図１の更新管理部３０および更新部３１に対応する。
　ＷＡＮ　Ｉ／Ｆ１５４はインターネット５を介してサーバ２への情報を無線で送受信するインタフェースであり、様々な無線通信規格、たとえばＬＴＥ，３Ｇ，４Ｇ，ＩＥＥＥ８０２．１６，ＩＥＥＥ８０２．１１，赤外線などを用いることができる。ＣＡＮ　Ｉ／Ｆ１５５は、車両１で使用される専用のネットワークであるＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）のインタフェースであり、車両１に搭載される不図示のＥＣＵから車両１に関する情報、たとえばイグニッションの状態などを取得する。ＬＡＮ　Ｉ／Ｆ１５７は、ＬＡＮネットワーク１８と接続するインタフェースである。ＷＡＮ　Ｉ／Ｆ１５４、ＣＡＮ　Ｉ／Ｆ１５５およびＬＡＮ　Ｉ／Ｆ１５７は、図１の通信部３３に対応する。ＨＭＩ１５８は、液晶ディスプレイなどユーザへ情報を提示する装置、およびタッチパネルなどユーザからの入力を受け付ける装置から構成される。ＨＭＩ１５８はＣＰＵ１５２の動作指令に基づきユーザへ情報を提示し、ユーザからの入力をＣＰＵ１５２に伝達する。ＨＭＩ１５８は、図１のＨＭＩ３４に対応する。
　以上が第１更新装置１０のハードウェア構成である。前述のとおり第２更新装置１１は第１更新装置１０と同一のハードウェア構成なので、説明を省略する。
（サーバのハードウェア構成）
　図３は、サーバ２のハードウェア構成を示す図である。サーバ２は、記憶部１８０と、ＣＰＵ１８１と、ストレージ１８３と、ＷＡＮ　Ｉ／Ｆ１８４と、バス１８２とから構成される。
　サーバ２のＣＰＵ１８１は、サーバ２で扱う情報の出入りを制御し、記憶部１８０に保存されているソフトウェアの記述に従い動作する。記憶部１８０は、ＣＰＵ１８１が扱う情報を一時的に保存し、バス１８２を介してデータをやり取りするメモリーである。ストレージ１８３は、第１更新装置１０および第２更新装置１１のソフトウェアを保存し、記憶部１８０に保持されている情報を電源切断後も保持する不揮発性の記憶装置である。ストレージ１８３は、ファイルシステムを搭載するハードディスクやＳＳＤやホログラフドライブなどであってもよい。記憶部１８０、ＣＰＵ１８１およびストレージ１８３は、図１のサーバ制御部６１およびサーバツリーＤＢ６２に対応する。ＷＡＮ　Ｉ／Ｆ１８４はバス１８２を介して情報を無線で送受信するインタフェースであり、たとえばＬＴＥ，３Ｇ，４Ｇ，ＩＥＥＥ８０２．１６，ＩＥＥＥ８０２．１１，赤外線などを用いることができる。ＷＡＮ　Ｉ／Ｆ１８４は、図１のデータ提供部６３に対応する。
（第１クライアントツリーＤＢ）
　図４は、第１更新装置１０に備えられる第１クライアントツリーＤＢ７２の構成を示す図である。第１クライアントツリーＤＢ７２はツリー構造を有するデータベースであり、複数のノードから構成される。ノードは情報を包含できるが、ノードが包含する情報だけでなくノードの存在の有無やノードの名称が後述する制御に使われる場合もある。
　第１クライアントツリーＤＢ７２におけるツリー構造の頂点はｒｏｏｔ１０１であり、ｒｏｏｔ１０１は配下に３つのノード、すなわちＤｅｖＩｎｆｏ１０２，ＤｅｖＤｅｔａｉｌ１０４，および１ｓｔＳＣＭ１０５を有する。ＤｅｖＩｎｆｏ１０２は、車両１の識別子である１ｓｔＶＩＮ１０３のようなデバイスの特徴情報が配下に配置される。ＤｅｖＤｅｔａｉｌ１０４は車両の付属情報が配下に格納されるが図４ではＤｅｖＤｅｔａｉｌ１０４の配下のノードは省略している。１ｓｔＳＣＭ１０５は、ソフトウェア更新で使用するノードを配下に持つ。以下では１ｓｔＳＣＭ１０５の配下のノードを詳しく説明する。１ｓｔＳＣＭ１０５は、配下にダウンロードに関するノードであるＤｏｗｎｌｏａｄ１０６、およびソフトウェアを更新するためのノードであるＩｎｖｅｎｔｏｒｙ１１０を有する。
　Ｄｏｗｎｌｏａｄ１０６はダウンロード対象であるパッケージを示すＡＢＣｖ２ｓ１０７を配下に有する。このノード名はたとえば、「ＡＢＣ」というソフトウェアのバージョン２の安定版（Ｓｔａｂｌｅ）である「ＡＢＣｖ２ｓ」というパッケージ名を意味する。なお第１更新装置１０がダウンロード対象とするソフトウェアが他にもある場合は、Ｄｏｗｎｌｏａｄ１０６の配下にＡＢＣｖ２ｓ１０７と並列に置かれる。
　ＡＢＣｖ２ｓ１０７は、パッケージのダウンロード先ＵＲＬが格納されるＰｋｇＵＲＬ１０８、ダウンロードに関する状態が格納されるＳｔａｔｕｓ１０９、動作指令を配下のノードとして有するＯｐｅｒａｔｉｏｎ１１０を配下に有する。サーバ２の指令に基づきＯｐｅｒａｔｉｏｎ１１０の配下にＤｏｗｎｌｏａｄ１１１が配置されると、更新データ取得部７３を動作してＰｋｇＵＲＬ１０８により示されるＵＲＬから「ＡＢＣｖ２ｓ」というパッケージをダウンロードする。なおＡＢＣｖ２ｓ１０７以下のノードはサーバ２からインターネット５を介して追加されたものである。
　１ｓｔＳＣＭ１０５の配下にＤｏｗｎｌｏａｄ１０６と並列に配置されるＩｎｖｅｎｔｏｒｙ１１０は、Ｄｅｌｉｖｅｒｅｄ１２１およびＤｅｐｌｏｙｅｄ１３０のノードを配下に有する。
　Ｄｅｌｉｖｅｒｅｄ１２１以下には、ダウンロードしたパッケージを用いてソフトウェアの更新を行うための情報が格納される。Ｄｅｌｉｖｅｒｅｄ１２１は配下に、ダウンロードしたパッケージの名称を有するＡＢＣｖ２ｓ１２２のノードを有する。ＡＢＣｖ２ｓ１２２は、更新に関する状態が格納されるＳｔａｔｕｓ１２３と、動作指令を配下のノードとして有するＯｐｅｒａｔｉｏｎ１２４とを配下に有する。Ｏｐｅｒａｔｉｏｎ１２４は、サーバ２の指令に基づき配置され、存在することが更新を実行する条件の１つであるＩｎｓｔａｌｌ１２５と、更新を実行する付加的な条件を格納するＥｘｔ１２６を配下に有する。Ｅｘｔ１２６の配下に存在する更新契機１９１には更新を実行する付加的な条件が格納される。すなわちＩｎｓｔａｌｌ１２５というノードが存在し、更新契機１９１に格納されるすべての条件が満たされると、ダウンロード済みのパッケージである「ＡＢＣｖ２ｓ」のインストール、すなわちソフトウェア「ＡＢＣ」の更新が開始される。更新契機１９１の構成については後述する。
　Ｄｅｐｌｏｙｅｄ１３０以下には、ソフトウェアの現在の情報が格納される。Ｄｅｐｌｏｙｅｄ１３０は配下に、ソフトウェアの名称を有するノード、すなわちＡＢＣ１３１を有する。ＡＢＣ１３１は配下に、入手可能な最新のバージョン番号が格納されるＡｖａｉｌａｂｌｅＶｅｒｓｉｏｎ１３２と、現在のバージョン番号が格納されるＶｅｒｓｉｏｎ１３３と、通知情報１９５を配下に有するＥｘｔ１３７とを有する。通知情報１９５については後述する。
（第２クライアントツリーＤＢ）
　図５は、第２更新装置１１に備えられる第２クライアントツリーＤＢ９２の構成を示す図である。第２クライアントツリーＤＢ９２はツリー構造を有するデータベースであり、複数のノードから構成される。第２クライアントツリーＤＢ９２の構成は、第１クライアントツリーＤＢ７２と概ね同じである。すなわち原則として、第１クライアントツリーＤＢ７２を構成する各ノードの符号の１００の位を「１」から「２」に変更したものが第２クライアントツリーＤＢ９２の各ノードである。
　ただし、第１更新装置１０と第２更新装置１１に備えられるソフトウェアは異なりバージョン番号も異なるとすると、たとえばＤｏｗｎｌｏａｄ２０６の配下にはＰＱＲｖ３ｓ２０７が置かれる。このノード名は「ＰＱＲ」というソフトウェアのバージョン３の安定版である「ＰＱＲｖ３ｓ」というパッケージ名を意味する。また、ダウンロードしたパッケージを用いてソフトウェアの更新を行うための情報が格納されるＤｅｌｉｖｅｒｅｄ２２１の配下には、ダウンロードするパッケージ名と同一の名称のＰＱＲｖ３ｓ２２２が置かれる。さらにソフトウェアの現在の情報が格納されるＤｅｐｌｏｙｅｄ２３０の配下には、ソフトウェアの名称を有するノードであるＰＱＲ２３１が置かれる。
（サーバツリーＤＢ）
　図６は、サーバ２に備えられるサーバツリーＤＢ６２の構成を示す図である。サーバツリーＤＢ６２はツリー構造を有するデータベースであり、複数のノードから構成される。サーバツリーＤＢ６２には、複数の車両に搭載された複数の更新装置に関する情報が格納される。更新装置に関する情報は、それぞれの更新装置に備えられるデータベースの一部を通信を介して複製することにより得られる。すなわちサーバツリーＤＢ６２には、第１クライアントツリーＤＢ７２の一部のノードと、第２クライアントツリーＤＢ９２の一部のノードが含まれる。
　サーバツリーＤＢ６２におけるツリー構造の頂点はｒｏｏｔ１００１であり、配下に各車両を示すノードである１ｓｔＶＩＮ１０１０、２ｎｄＶＩＮ１０２０、・・を有する。これらのノードの配下には車両ごとの情報が格納される。１ｓｔＶＩＮ１０１０は配下に車両１の情報を格納するノードである、ＤｅｖＩｎｆｏ１００２、ＤｅｖＤｅｔａｉｌ１００４、１ｓｔＳＣＭ１１０５、および２ｎｄＳＣＭ１２０５を有する。
　ＤｅｖＩｎｆｏ１００２以下のノードは、第１クライアントツリーＤＢ７２におけるＤｅｖＩｎｆｏ１０２以下のノード、および第２クライアントツリーＤＢ９２におけるＤｅｖＩｎｆｏ２０２以下のノードに対応する。ＤｅｖＤｅｔａｉｌ１００４は、第１クライアントツリーＤＢ７２におけるＤｅｖＤｅｔａｉｌ１０４、および第２クライアントツリーＤＢ９２におけるＤｅｖＤｅｔａｉｌ２０４に相当する。１ｓｔＳＣＭ１１０５以下の各ノードは、第１クライアントツリーＤＢ７２における１ｓｔＳＣＭ１０５以下の各ノードに相当する。すなわちサーバツリーＤＢ６２における符号「１１ｘｘ」は第１クライアントツリーＤＢ７２における符号「１ｘｘ」に相当する。２ｎｄＳＣＭ１２０５以下の各ノードは、第２クライアントツリーＤＢ９２における２ｎｄＳＣＭ２０５以下の各ノードに相当する。すなわちサーバツリーＤＢ６２における符号「１２ｘｘ」は第２クライアントツリーＤＢ９２における符号「２ｘｘ」に相当する。
（更新契機）
　第１クライアントツリーＤＢ７２に含まれる更新契機１９１、および第２クライアントツリーＤＢ９２に含まれる更新契機２９１を図７および図８を用いて説明する。前述のとおり更新契機には更新を実行する付加的な条件が格納される。更新契機１９１と更新契機２９１の構成は似ているので主に更新契機１９１を説明し、更新契機２９１は更新契機１９１との相違点を説明する。
　図７に示すように、更新契機１９１は、配下に３つのノード、すなわち車両状態１９１１、第１更新装置１９１４Ａ、および第２更新装置１９１４Ｂを有する。車両状態１９１１以下には全般的な更新の条件が格納され、第１更新装置１９１４Ａ以下には第１更新装置１０に関する更新の条件が格納され、第２更新装置１９１４Ｂ以下には第２更新装置１１に関する更新の条件が格納される。ただし子ノードが存在しない場合は親ノードは省略してもよく、たとえば第１更新装置１０に関する更新の条件がない場合は第１更新装置１９１４Ａがなくてもよい。
　車両状態１９１１は、ＩＧＮ情報１９１２とユーザ許諾１９１３とを配下に有する。ＩＧＮ情報１９１２は「オン」または「オフ」の値をとり、イグニッションが「オン」または「オフ」に操作されることが更新の条件の１つであることを示す。ユーザ許諾１９１３は、ユーザから更新の許諾を受けることが更新の条件の１つであることを示す。
　第１更新装置１９１４Ａは配下に直列に接続される３つのノードである、ＡＢＣ１９１５Ａ、Ｄｏｗｎｌｏａｄ１９１６Ａ，およびＶｅｒｓｉｏｎ１９１７Ａを有する。これらのノードは、第１更新装置１０において「ＡＢＣ」という名称のソフトウェアのＶｅｒｓｉｏｎ１９１７Ａにより示されるバージョンが「ダウンロード」されることが更新の条件の１つであることを示す。
　第２更新装置１９１４Ｂは配下に直列に接続される３つのノードである、ＰＱＲ１９１５Ｂ、Ｉｎｓｔａｌｌ１９１６Ｂ，およびＶｅｒｓｉｏｎ１９１７Ｂを有する。これらのノードは、第２更新装置１１において「ＰＱＲ」という名称のソフトウェアのＶｅｒｓｉｏｎ１９１７Ｂにより示されるバージョンが「インストール」されることが更新の条件の１つであることを示す。
　図７に示されていることをまとめると、更新契機１９１以下に格納される情報から、更新を実行する付加的な条件は、車両１のイグニッションが所定の状態であり、ユーザから許諾が得られ、ソフトウェア「ＡＢＣ」の所定のバージョンが第１更新装置１０でダウンロード済みであり、ソフトウェア「ＰＱＲ」の所定のバージョンが第２更新装置１１にインストールされていることである。図４に示したように更新契機１９１はＡＢＣｖ２ｓ１２２の配下に存在するので、更新契機１９１は、ＡＢＣｖ２ｓ１２２をインストールする付加的な条件、換言するとソフトウェア「ＡＢＣ」をバージョン「２」に更新するための付加的な条件である。
　図８に示すように、更新契機２９１は、配下に３つのノード、すなわち車両状態２９１１、第１更新装置２９１４Ａ、および第２更新装置２９１４Ｂを有する。車両状態２９１１は、回線状態２９１２を配下に有する。回線状態２９１２は、インターネット５との接続が切断されたことが条件であることを示す。第１更新装置２９１４Ａ、および第２更新装置２９１４Ｂの構成は、図７において説明した第１更新装置１９１４Ａと同様なので省略する。
　図８に示されていることをまとめると、更新契機２９１以下に格納される情報から、更新を実行する付加的な条件は、インターネット５との接続が切断され、ソフトウェア「ＡＢＣ」の所定のバージョンが第１更新装置１０でダウンロード済みであり、ソフトウェア「ＰＱＲ」の所定のバージョンが第２更新装置１１でダウンロード済みであることである。図５に示したように更新契機２９１はＰＱＲｖ３ｓ２２２の配下に存在するので、更新契機２９１は、ＰＱＲｖ３ｓ２２２をインストールする付加的な条件、換言するとソフトウェア「ＰＱＲ」をバージョン「３」に更新するための付加的な条件である。
（通知情報）
　第１クライアントツリーＤＢ７２に含まれる通知情報１９５、および第２クライアントツリーＤＢ９２に含まれる通知情報２９５を図９および図１０を用いて説明する。通知情報１９５には更新トリガ通知部４５が更新トリガを送信する条件、送信先、および送信内容の情報が含まれる。
　図９に示すように、通知情報１９５は、Ｄｏｗｎｌｏａｄ完了１９５１ＡとＩｎｓｔａｌｌ完了１９５１Ｂの２つのノードを有する。Ｄｏｗｎｌｏａｄ完了１９５１Ａ以下は、パッケージのダウンロード完了が条件となって通知される更新トリガに関する情報が格納される。Ｄｏｗｎｌｏａｄ完了１９５１Ａは、配下に第１更新装置１９５２Ａと第２更新装置１９５２Ｂを有する。ただし本実施の形態では、第１更新装置１９５２Ａおよび第２更新装置１９５２Ｂはノードの名称自体に意味はない。
　第１更新装置１９５２Ａは配下に、宛先１９５３Ａ、パッケージ１９５４Ａ、Ｖｅｒｓｉｏｎ１９５５Ａの３つのノードを有する。宛先１９５３Ａには更新トリガの送信先を示す情報、たとえば第１更新装置１０のＩＰアドレスやループバックアドレス（１２７．０．０．１）が格納される。パッケージ１９５４Ａは、更新トリガにパッケージの名称を含めることを示す。Ｖｅｒｓｉｏｎ１９５５Ａは、更新トリガに更新後のバージョン情報を含めることを示す。第２更新装置１９５２Ｂの構成は第１更新装置１９５２Ａと同様である。
　Ｉｎｓｔａｌｌ完了１９５１Ｂは配下に、インストール完了が条件となって通知される更新トリガに関する情報が格納される。ただし図９に示す例ではインストール完了が条件となる更新トリガが存在しないので配下にノードを有しない。
　図９に示されていることをまとめると、パッケージ「ＡＢＣｖ２ｓ」のダウンロードが完了すると、宛先１９５３Ａおよび宛先１９５３Ｂに対してパッケージの名称とバージョンの情報を含む更新トリガを送信する。
　図１０に示すように、通知情報２９５には第２更新装置１１の更新トリガ通知部が更新トリガを送信する条件、送信先、および送信内容の情報が含まれる。通知情報２９５は、通知情報１９５と比較すると、ノードの有無、およびノードに格納される値は異なるが、構成は通知情報１９５と同様なので構成の説明を省略する。
　図１０に示されていることをまとめると、次の２点が示されている。１点目はパッケージ「ＰＱＲｖ３ｓ」のダウンロードが完了すると、宛先２９５３Ａおよび宛先２９５３Ｂに対してダウンロードしたパッケージの名称とバージョンの情報を含む更新トリガを送信することである。２点目はパッケージ「ＰＱＲｖ３ｓ」のインストールが完了すると、宛先２９５３Ｃに対してインストールしたパッケージの名称とバージョンの情報を含む更新トリガを送信することである。
（処理シーケンス）
　サーバ２、第１更新装置１０、および第２更新装置１１におけるソフトウェア更新に係るメッセージのやり取りを図１１～図１２のシーケンス図を用いて説明する。いずれのシーケンス図も図示上方から下方に向かって時間が経過しており、図１１の下部から図１２の上部に時間が連続している。なお図１１ではサーバ２と第１更新装置１０におけるメッセージのやり取りを詳細に説明し、図１２ではサーバ２と第２更新装置１１におけるメッセージのやり取りは簡略して記載する。
　以下の説明するシーケンスが開始される時点では、第１更新装置１０に備えられるソフトウェア「ＡＢＣ」のバージョンは「１」であり、第２更新装置１１に備えられるソフトウェア「ＰＱＲ」のバージョンは「２」である。シーケンスが開始される時点では、第１クライアントツリーＤＢ７２は、Ｄｏｗｎｌｏａｄ１０６の配下にノードを有さず、Ｄｅｌｉｖｅｒｅｄ１２１の配下にもノードを有しない。シーケンスが開始される時点では、第２クライアントツリーＤＢ９２は、Ｄｏｗｎｌｏａｄ２０６の配下にノードを有さず、Ｄｅｌｉｖｅｒｅｄ２２１の配下にもノードを有しない。
　始めに第１更新装置１０の第１制御部７１が、サーバ制御部６１に車両を識別するＶＩＮ情報を送信する（Ｓ３０１）。これによりサーバ２は通信対象の車両が車両１であることを識別し、不図示のデータベースから車両１に備えられるソフトウェアの最新バージョンの情報を取得する。最新バージョンの情報とはたとえば、ソフトウェア「ＡＢＣ」の最新バージョンが「２」であり、ソフトウェア「ＰＱＲ」の最新バージョンが「３」であることである。次にサーバ制御部６１は、取得した最新バージョンの情報およびバージョン情報取得要求を第１制御部７１に送信する（Ｓ３０２）。
　第１制御部７１は、受信した最新バージョンの情報を第１クライアントツリーＤＢ７２に格納する（Ｓ３５０）。詳述すると、第１クライアントツリーＤＢ７２におけるＤｅｐｌｏｙｅｄ１３０の配下のＡＢＣ１３１の配下のＡｖａｉｌａｂｌｅＶｅｒｓｉｏｎ１３２のノードに「２」という値が格納される。なお、サーバ２から受信した最新バージョンの情報にはソフトウェア「ＰＱＲ」の情報も含まれるが、第１クライアントツリーＤＢ７２にはソフトウェア「ＰＱＲ」についての情報が格納されていないので、ソフトウェア「ＰＱＲ」の情報は破棄される。続いて第１制御部７１は、第１クライアントツリーＤＢ７２からＤｅｐｌｏｙｅｄ１３０以下の全てのノードの情報を取得し（Ｓ３５１）、サーバ制御部６１に送信する（Ｓ３０３）。
　サーバ制御部６１は、受信したＤｅｐｌｏｙｅｄ１３０以下のノードの情報を、サーバツリーＤＢ６２に１ｓｔＳＣＭ１１０５のＤｅｐｌｏｙｅｄ１１３０以下の情報として保存する。そして保存したＤｅｐｌｏｙｅｄ１１３０以下のノードの情報に基づきソフトウェアの更新の要否を判断する。すなわちサーバ制御部６１は、ＡｖａｉｌａｂｌｅＶｅｒｓｉｏｎ１１３２とＶｅｒｓｉｏｎ１１３３を比較し、ＡｖａｉｌａｂｌｅＶｅｒｓｉｏｎ１１３２の方が新しい場合に更新が必要であると判断する（Ｓ３５２）。
　次にサーバ制御部６１は、サーバ２に備えられるストレージ１８３から通知情報１９５およびソフトウェア更新情報を取得する（Ｓ３６１）。ソフトウェア更新情報とは、具体的には、図４のＤｏｗｎｌｏａｄ１０６以下のノードであってＤｏｗｎｌｏａｄ１１１を除くノードである。そしてサーバ制御部６１は、ソフトウェア更新情報と通知情報１９５を第１制御部７１に送信する（Ｓ３０４）。
　第１制御部７１は、受信した情報を第１クライアントツリーＤＢ７２に格納する。具体的には、通知情報１９５をＥｘｔ１３７の配下に追加し（Ｓ３６２）、ソフトウェア更新情報を１ｓｔＳＣＭ１０５の配下にＤｏｗｎｌｏａｄ１０６として追加する（Ｓ３５３）。そして、サーバ制御部６１に更新情報を設定した旨の応答を返す（Ｓ３０５）。
　サーバ制御部６１は、第１更新装置１０にＡＢＣｖ２ｓ１０７というパッケージをダウンロードさせるために、第１制御部７１にダウンロード実行指示を送信する（Ｓ３０８）。この指示は第１クライアントツリーＤＢ７２のＯｐｅｒａｔｉｏｎ１１０の配下にＤｏｗｎｌｏａｄ１１１を作成させるものである。第１制御部７１は、第１クライアントツリーＤＢ７２のＯｐｅｒａｔｉｏｎ１１０の配下にＤｏｗｎｌｏａｄ１１１が作成されると、更新データ取得部７３にダウンロードの実行を指示する（Ｓ３５６）。更新データ取得部７３は、ＰｋｇＵＲＬ１０８に記載されたＵＲＬから更新データを取得する。ここで、ＰｋｇＵＲＬ１０８に記載されたＵＲＬがサーバ２の内部であるとすると、更新データ取得部７３はデータ提供部６３にＡＢＣｖ２ｓというパッケージを要求し（Ｓ３０９）、パッケージを取得する（Ｓ３１０）。更新データ取得部７３は、パッケージの取得が完了すると第１制御部７１にダウンロードが終了したことを通知する（Ｓ３５７）。ここで第１制御部７１は、後述する更新トリガ通知送信処理を実行する（Ｓ３６８）。第１制御部７１は、ダウンロードが終了したことをサーバ制御部６１に送信する（Ｓ３１１）。
　次にサーバ制御部６１は、ソフトウェア更新を実行してもよいかをユーザに確認するためのソフトウェア更新許可要求メッセージを第１制御部７１に送信する（Ｓ３０６）。第１制御部７１は、ＨＭＩ３４にソフトウェアの更新許可を求めるメッセージを表示させる（Ｓ３５４）。ＨＭＩ３４は要求されたメッセージを表示し、ユーザからの応答を受け取って第１制御部７１に返す（Ｓ３５５）。第１制御部７１は、許可か不許可かの情報をサーバ制御部６１に送信する（Ｓ３０７）。ただしここではユーザが許可したとして、以下は図１２を参照して説明を続ける。
　次にサーバ制御部６１は、ストレージ１８３から更新契機１１９１を取得し（Ｓ３６０）、ソフトウェア更新の実行を指示するメッセージとともに第１制御部７１に送信する（Ｓ３１４）。ただし更新契機１１９１はサーバツリーＤＢ６２から読みだされてもよい。
　第１制御部７１は、受信した更新契機を更新契機１９１として第１クライアントツリーＤＢ７２に保存し（Ｓ３６３）、ソフトウェア更新の実行を指示するメッセージに基づきＯｐｅｒａｔｉｏｎ１２４の配下にノードＩｎｓｔａｌｌ１２５を作成する。そして第１制御部７１は、更新契機１９１を解釈して更新トリガを待ち（Ｓ３６５）、所定時間ごとに全ての更新トリガが揃っているかを判断する（Ｓ３６６）。ここでは、すべての更新トリガが揃っていないので更新トリガ待ち（Ｓ３６５）を継続する。具体的には、図７に示した更新契機１９１において第２更新装置１１におけるソフトウェア「ＰＱＲ」のバージョン「３」のインストール完了を示す更新トリガを待つ。
　第２更新装置１１による、ＶＩＮ送信（Ｓ３０１Ａ）から、更新契機２９１の第２クライアントツリーＤＢ９２への保存（Ｓ３６３Ａ）までの処理は第１更新装置１０によるＳ３０１～Ｓ３６３の処理と同様である。更新契機２９１は図８に示したように回線状態２９１２がオフラインであり、第１更新装置１０においてソフトウェア「ＡＢＣ」のダウンロードが完了し、第２更新装置１１においてソフトウェア「ＰＱＲ」のダウンロードが完了することなので、Ｓ３６３Ａが実行された時点で全ての条件が満たされている。そのため第２制御部９１は、更新部８１に更新開始の指令を送信し（Ｓ３１７）、更新部８１にソフトウェア更新処理（Ｓ３９０）を実行させる。更新部８１は更新処理が終了すると第２制御部９１に通知する（Ｓ３１８）。第２制御部９１は、更新処理が終了した旨の通知を受信すると、通知情報２９５に基づき更新トリガを送信する（Ｓ３６８、Ｓ３６９）。通知情報２９５は、図１０に示すように宛先４７２に対して更新が完了したパッケージの名称とバージョン番号とを通知することを示している。そのため第２制御部９１は、宛先４７２が第１更新装置１０を示していることから、更新が完了したパッケージの名称である「ＰＱＲｖ３ｓ」およびバージョン番号である「３」を含みインストールが完了したことを示す更新トリガを第１更新装置１０に送信する。
　更新トリガを受信した第１制御部７１は、全ての更新トリガが揃っていると判断して（Ｓ３６６）更新部３１に更新開始させる（Ｓ３１７）。更新部３１はソフトウェア更新処理３９０を実行し、更新処理が終了すると終了した旨の通知を第１制御部７１に出力する（Ｓ３１８）。
　以上説明した動作により、複数のソフトウェア更新装置が存在するシステムにおいて、ソフトウェア同士の依存関係を保持したままソフトウェアを更新することができる。
（画面表示）
　図１３は、図１１のＳ３５４においてＨＭＩ３４がユーザへ更新の可否を問い合わせるメッセージの一例を示す図である。図１３に示す表示は、第１更新装置１０が備えるＨＭＩ３４に表示されている。図１３に示す例では第１更新装置１０はカーナビゲーション機能を兼ね備えており、カーナビゲーションに用いられるインタフェース画面に重畳して、更新の可否を問い合わせるメッセージが表示される。
　図１４は、ＨＭＩ３４がＨＭＩ制御部として動作する場合に、第１更新装置１０以外の装置に表示されるユーザへ更新の可否を問い合わせるメッセージの一例を示す図である。図１４に示す例では、ユーザの所持する携帯端末に表示される。
（フローチャート）
　第１更新装置１０がサーバ２から通知情報１９５、更新契機１９１、更新実行指示、およびダウンロード実行指示を受信した際の動作を図１５～図１８を参照して説明する。以下に説明するフローチャートの各ステップの実行主体は、第１更新装置１０のＣＰＵ１５２である。なお第２更新装置１１も第１更新装置１０と同様な処理を行う。
　図１５は、第１更新装置１０がサーバ２から通知情報１９５を受信した際の処理を表すフローチャートである。ステップＳ２１０３では、ＣＰＵ１５２は受信した通知情報１９５を格納する第１クライアントツリーＤＢ７２のノードを検索する。続くステップＳ２１０４では、ＣＰＵ１５２は受信した通知情報１９５をステップＳ２１０３において特定したノードに保存し、図１５に示す処理を終了する。
　図１６は、第１更新装置１０がサーバ２から更新契機１９１を受信した際の処理を表すフローチャートである。ステップＳ２１０７では、ＣＰＵ１５２は受信した更新契機１９１を格納する第１クライアントツリーＤＢ７２のノードを検索する。続くステップＳ２１０８では、ＣＰＵ１５２は受信した更新契機１９１をステップＳ２１０７において特定したノードに保存し、図１６に示す処理を終了する。
　図１７は、第１更新装置１０がサーバ２から更新実行指示を受信した際の処理を表すフローチャートである。サーバ２から更新実行指示を受信することにより、前述のとおりＩｎｓｔａｌｌ１２５ノードが作成され更新を実行する条件の一つが満たされるが、ここではＩｎｓｔａｌｌ１２５ノードの作成についての説明は省略する。
　ステップＳ２１１０では、ＣＰＵ１５２は第１クライアントツリーＤＢ７２から更新契機１９１を取得する。ＣＰＵ１５２は、続くステップＳ２１１１では更新トリガを待ち受けるとともに車両条件が満たされることを待機し、続くステップＳ２１２０では受信した更新トリガをストレージ１５９または記憶部１５１に保存する。続くステップＳ２１１２では、ＣＰＵ１５２は更新契機１９１に記載されたすべての更新トリガが揃ったか、換言すると更新を実行する付加的な条件がすべて満たされたか否かを判断する。ＣＰＵ１５２は、全ての更新トリガが揃ったと判断する場合はステップＳ２１１３に進み、１つでも満たされない条件があると判断する場合はステップＳ２１１１に戻る。
　ステップＳ２１１３では、ＣＰＵ１５２はソフトウェア更新処理を実行する。続くステップＳ２１１４では、ＣＰＵ１５２は更新が完了したか否かを判断し、更新が完了したと判断するまでステップＳ２１１４に留まり、更新が完了したと判断するとステップＳ２１１５に進む。
　ステップＳ２１１５では、ＣＰＵ１５２は第１クライアントツリーＤＢ７２から通知情報１９５を読み込む。続くステップＳ２１１７では、通知情報１９５から更新が完了した際に通知すべき情報を抽出し、更新が完了した旨の通知、すなわち更新トリガを送信する。ただし通知情報１９５が図９に示す例の場合はＩｎｓｔａｌｌ完了１９５１Ｂの配下にノードが存在しないため、本ステップを実行せずに図１７に示す処理を終了する。続くステップＳ２１１８では、対象となるすべての宛先に更新トリガを送信したか否かを判断し、全ての対象に送信したと判断する場合は図１７に示す処理を終了し、送信していない対象があると判断する場合はステップＳ２１１７に戻る。
　図１８は、第１更新装置１０がサーバ２からダウンロード実行指示を受信した際の処理を表すフローチャートである。
　ステップＳ２２０１では、ＣＰＵ１５２は更新データ取得部７３を用いて更新データを取得させる。ダウンロードは更新データ取得部７３およびデータ提供部６３との間で実行され、プロトコルはＨＴＴＰあるいはＦＴＰなどのデータを転送することができるものであればどのようなプロトコルを用いてもよい。更新データの取得先は、第１クライアントツリーＤＢ７２にたとえばＰｋｇＵＲＬ１０８として格納されている。続くステップＳ２２０２では、ＣＰＵ１５２は更新データのダウンロードが完了したか否かを判断する。この判断はたとえば、更新データ取得部７３からダウンロード完了の通知を受けたか否かにより判断できる。ダウンロードが完了したとする場合はステップＳ２２０３に進み、ダウンロードが完了していないと判断する場合はステップＳ２２０２に留まる。
　ステップＳ２２０３では、ＣＰＵ１５２は第１クライアントツリーＤＢ７２から通知情報１９５を読み込む。続くステップＳ２２０４では、通知情報１９５からダウンロードが完了した際に通知すべき情報を抽出し、ダウンロードが完了した旨の通知、すなわち更新トリガを送信する。通知情報１９５が図９に示す例の場合は、２つの装置に更新トリガを送信し、その更新トリガにはダウンロードが完了したパッケージの名称とバージョンが含まれる。続くステップＳ２２０５では、対象となるすべての宛先に更新トリガを送信したか否かを判断し、全ての対象に送信したと判断する場合は図１８に示す処理を終了し、送信していない対象があると判断する場合はステップＳ２２０４に戻る。
　なお、第１更新装置１０のインターネット５との接続の切断がステップＳ２１１０以降で発生したとしても、更新契機１９１および通知情報１９５は第１クライアントツリーＤＢ７２から取得できるので、ソフトウェアの更新に支障はない。この場合も更新契機１９１により定められた条件が満たされなければ更新が実行されないので、サーバ２との接続が切断されていても更新契機１９１を適切に設定することにより、ソフトウェア同士の依存関係を維持したままソフトウェアを更新することができる。
　上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）ソフトウェア更新装置である第１更新装置１０は、１以上のソフトウェア更新装置、すなわち第２更新装置１１及びサーバ２とインターネット５を介して接続される。第１更新装置１０は、サーバ２から更新用データを受信する更新データ取得部７３と、更新用データを用いてソフトウェアの更新を行う更新部３１と、他のソフトウェア更新装置と通信する通信部３３と、更新トリガの受信を含むソフトウェアを更新する条件が記載された更新契機１９１をサーバ２から受信する更新契機受信部４１と、他のソフトウェア更新装置に通知を行う条件を含む通知情報１９５をサーバ２から受信する通知情報受信部４２と、通知情報１９５に基づき他のソフトウェア更新装置に更新トリガを送信する更新トリガ通知部４５と、他のソフトウェア更新装置から更新トリガを受信する更新トリガ受信部４４と、更新契機１９１に記述されているすべての条件が満たされたと判断すると更新部３１にソフトウェアの更新を実行させる更新開始判断部４０とを備える。
　更新開始判断部４０は、サーバ２から受信した更新契機１９１に記載された条件がすべて満たされるとソフトウェアの更新を実行させるので、ソフトウェアの依存関係を満たしたままソフトウェアを更新することができる。たとえば、第１更新装置１０にインストールされるソフトウェア「ＡＢＣ」と第２更新装置１１にインストールされるソフトウェア「ＰＱＲ」に依存関係がある場合に、適切に設定された更新契機１９１を用いることでソフトウェアの依存関係を満たしたままソフトウェアを更新することができる。すなわち図７に示したように、第２更新装置１１に所定のバージョンのソフトウェア「ＰＱＲ」がインストールされたことを条件として、第１更新装置１０のソフトウェア「ＡＢＣ」を更新させることができる。
　また第１更新装置１０は更新トリガ通知部４５を備えるので、通知情報１９５に基づき他のソフトウェア更新装置に更新トリガを送信することができる。すなわち他のソフトウェア更新装置に更新トリガの受信に基づきソフトウェアを更新させることができる。さらに第１更新装置１０は、サーバ２から更新契機１９１、通知情報１９５、および更新データを受信した後であれば、サーバ２との接続が切断されても受信済みの情報を用いてソフトウェアの更新を行うことができる。
（２）通知情報１９５には、ソフトウェアが更新されると更新トリガが送信されることが含まれる。更新トリガ通知部４５は、更新部３１がソフトウェアの更新を完了すると更新トリガを送信する。
　そのため第１更新装置１０は、他のソフトウェア更新装置に第１更新装置１０におけるソフトウェアの更新を通知することができる。すなわちソフトウェアの依存関係を満たしたまま、他のソフトウェア更新装置にソフトウェアを更新させることができる。
（３）通知情報１９５には、更新データ取得部７３が更新用データを受信すると更新トリガが送信されることが含まれる。更新トリガ通知部４５は、更新データ取得部７３が更新用データを受信すると更新トリガを送信する。
　そのため第１更新装置１０は、他の装置が更新データを受信済みであること、換言すると他の装置が更新を実行するための事前準備の少なくとも一部が完了していることを条件として更新を開始することができる。
（４）第１更新装置１０は車両１に搭載される。更新契機１９１には車両１のイグニッションのオンまたはオフが含まれる。更新開始判断部４０は、イグニッションのオンまたはオフを検知可能である。
　イグニッションのオフを更新開始の条件とすることで、車両１の走行に係るソフトウェアを安全に更新することができる。また一般にユーザがイグニッションをオフに操作するとその後しばらくはユーザは車両１を使用しないので、長時間の処理を要する更新を実行してもユーザの妨げとならない。イグニッションのオンを更新開始の条件とすることで、ユーザがタイミングを選択可能なわかりやすい時に更新を実行できる。
（５）第１更新装置１０はインターネット５に接続される車両１に搭載される。更新契機１９１にはインターネット５との接続の切断が含まれる。更新開始判断部４０は接続の切断を検知可能である。
　インターネット５との接続の切断を更新開始の条件とすることで、ソフトウェアの更新による可用性の低下を低減することができる。詳述すると以下のとおりである。すなわち、動作にインターネット５との接続が必要なソフトウェアは、インターネット５との接続が切断されている間は動作できない。またソフトウェアの更新を開始すると更新が終了するまではソフトウェアを使用できない。そこで、インターネット５との接続が切断されたことによりソフトウェアを使用できない時間に更新によりソフトウェアを使用できない時間を重複させることで、ソフトウェアの更新による可用性の低下を低減する。
（６）第１更新装置１０は記憶部１５１およびストレージ１５９を備える。更新トリガ受信部４４は受信した更新トリガを記憶部１５１またはストレージ１５９に記憶させる。更新開始判断部４０は、記憶部１５１またはストレージ１５９に記憶されている更新トリガを含めて更新開始の判断を行う。
　そのため、更新条件のそれぞれが異なるタイミングで成立した場合でも、更新を開始することができる。
（変形例１）
　更新契機１９１には車両状態１９１１以下のノードが含まれなくてもよいし、車両状態１９１１の配下に異なるノードが配置されてもよい。たとえば時刻に関する条件や車両１のエンジンの状態に関する条件を表すノードが配置されてもよい。
（変形例２）
　更新契機１９１には、第１更新装置１０および第２更新装置１１についての条件が格納されたが、いずれか一方についての条件のみが格納されてもよい。また１つの更新装置について２以上のソフトウェアに関する条件が格納されてもよいし、各ソフトウェアについて「Ｄｏｗｎｌｏａｄ」や「Ｉｎｓｔａｌｌ」以外の条件、たとえば削除されたことを示す「Ｒｅｍｏｖｅ」が設定されてもよい。
（変形例３）
　通知情報１９５の配下には、Ｄｏｗｎｌｏａｄ完了１９５１ＡやＩｎｓｔａｌｌ完了１９５１Ｂ以外のノードが存在してもよい。たとえば、イグニッションがオンになったことを示す「ＩＧＮオン」や、ユーザから更新の許諾が得られたことを示す「更新許諾」などのノードが通知情報１９５の配下に存在してもよい。すなわち更新トリガ通知部４５が、イグニッションがオンにされた際やユーザから更新の許諾を得られた際に更新トリガを送信してもよい。この構成は、他の更新管理装置がイグニッションの情報やユーザの許諾の情報を直接得ることができない場合に有効である。
（変形例４）
　第１の実施の形態では、第１クライアントツリーＤＢ７２、第２クライアントツリーＤＢ９２、およびサーバツリーＤＢ６２をツリー状のデータベース、すなわち階層型データベースとして表現したが、これらデータベースの形式はこれに限定されない。ネットワーク型データベースやリレーショナル型データベースなど他の形式であってもよい。
（変形例５）
　第１更新装置１０は、更新トリガの送信および受信を行ったが、更新トリガの送信のみを行い受信を行わなくてもよいし、更新トリガの受信のみを行い送信を行わなくてもよい。たとえば第１更新装置１０が更新トリガの送信のみを行い受信を行わない場合は、第１更新装置１０は更新トリガ受信部４４を備えなくてよい。また第１更新装置１０が更新トリガの受信のみを行い送信を行わない場合は、通知情報受信部４２および更新トリガ通知部４５を備えなくてよい。
　本変形例によれば、以下のソフトウェア更新装置も本発明に含まれる。
（１）ソフトウェア更新装置は、１以上のソフトウェア更新装置及びサーバとネットワークを介して接続される。ソフトウェア更新装置は、サーバから更新用データを受信する受信部と、更新用データを用いてソフトウェアの更新を行う更新部と、他のソフトウェア更新装置と通信する通信部と、更新トリガの受信を含むソフトウェアを更新する条件が記載された更新契機をサーバから受信する更新契機受信部と、他のソフトウェア更新装置から更新トリガを受信する更新トリガ受信部と、更新契機に記述されているすべての条件が満たされたと判断すると更新部にソフトウェアの更新を実行させる更新開始判断部とを備える。
（２）ソフトウェア更新装置は、１以上のソフトウェア更新装置及びサーバとネットワークを介して接続される。ソフトウェア更新装置は、サーバから更新用データを受信する受信部と、更新用データを用いてソフトウェアの更新を行う更新部と、他のソフトウェア更新装置と通信する通信部と、ソフトウェアを更新する条件が記載された更新契機をサーバから受信する更新契機受信部と、他のソフトウェア更新装置に通知を行う条件を含む通知情報をサーバから受信する通知情報受信部と、通知情報に基づき他のソフトウェア更新装置に、受信することがソフトウェアを更新する条件の１つとなる更新トリガを送信する更新トリガ通知部と、更新契機に記述されているすべての条件が満たされたと判断すると更新部にソフトウェアの更新を実行させる更新開始判断部とを備える。
（変形例６）
　第１更新装置１０に格納される通知情報１９５には、宛先として第１更新装置１０が記載されず、第１更新装置１０から第１更新装置１０への更新トリガが送信されなくてもよい。この場合は、更新トリガ通知部４５や更新トリガ受信部４４を介さずに、ダウンロードが完了した旨の情報が更新開始判断部４０に伝達される。
―第２の実施の形態―
　図１９～図２１を参照して、ソフトウェア更新システムＳの第２の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、第１更新装置および第２更新装置が他の装置のソフトウェアを更新する点で、第１の実施の形態と異なる。
（システム構成）
　図１９は、第２の実施の形態におけるソフトウェア更新システムＳの構成を示す図である。車両１は、第１更新装置１０と、第２更新装置１１と、ＬＡＮネットワーク１８と、第１ＥＣＵ５１１と、第２ＥＣＵ５１２と、第３ＥＣＵ５１３と、第１ＣＡＮネットワーク５０１と、第２ＣＡＮネットワーク５０２とを備える。第１更新装置１０、および第２更新装置１１は、ＬＡＮネットワーク１８により接続される。第１更新装置１０、第１ＥＣＵ５１１、および第２ＥＣＵ５１２は、第１ＣＡＮネットワーク５０１により接続される。第２更新装置１１、および第３ＥＣＵ５１３は、第２ＣＡＮネットワーク５０２により接続される。
　第１ＥＣＵ５１１にはソフトウェア「ＤＥＦ」が備えられ、第２ＥＣＵ５１２にはソフトウェア「ＧＨＩ」が備えられ、第３ＥＣＵ５１３にはソフトウェア「ＳＴＵ」が備えられる。第１更新装置１０は、第１ＥＣＵ５１１および第２ＥＣＵ５１２のソフトウェアを更新する。第２更新装置１１は、第３ＥＣＵ５１３のソフトウェアを更新する。
（ＥＣＵのハードウェア構成）
　第１ＥＣＵ５１１、第２ＥＣＵ５１２、および第３ＥＣＵ５１３のハードウェア構成は同様なので、ここでは代表して第１ＥＣＵ５１１のハードウェア構成を説明する。
　図２０は、第１ＥＣＵ５１１のハードウェア構成を示す図である。第１ＥＣＵ５１１は、記憶部１７０と、ＣＰＵ１７１と、ストレージ１７３と、ＣＡＮ　Ｉ／Ｆ１７４と、バス１７２とを備える。
　第１ＥＣＵ５１１のＣＰＵ１７１は、第１ＥＣＵ５１１で扱われる情報の出入りを制御し、ストレージ１７３に保存されているソフトウェアの記述に従い動作する。記憶部１７０は、ＣＰＵ１７１が扱う情報を一時的に保存し、バス１７２を介してＣＰＵ１７１とデータをやり取りする。ストレージ１７３には、第１ＥＣＵ５１１のソフトウェアが格納される不揮発性の記憶装置である。第１ＥＣＵ５１１は、ストレージ１７３に保存されているソフトウェアで動作し、このソフトウェアを更新することにより第１ＥＣＵ５１１の動作を変更することが可能である。ＣＡＮ　Ｉ／Ｆ１７４は、車両１で使用される専用のネットワークであるＣＡＮ用インタフェースであり、第１ＣＡＮネットワーク５０１を介して第１更新装置１０と通信する。このインタフェースを介してソフトウェアを受信し、ストレージ１７３に格納されているソフトウェアを書き換えることが可能である。
（第１クライアントツリーＤＢ）
　第２の実施の形態における第１クライアントツリーＤＢ７２は、第１の実施の形態における第１クライアントツリーＤＢ７２の構成において、「ＡＢＣ」を「ＤＥＦ」および「ＧＨＩ」で置き換えたものである。
　図２１は、第２の実施の形態における第１クライアントツリーＤＢ７２の概略を示す図である。Ｄｏｗｎｌｏａｄ１０６の配下には、ダウンロードする２つのパッケージの情報が格納される、「ＤＥＦｖ２ｓ」のノードと、「ＧＨＩｖ４ｓ」のノードが置かれる。これと同様にＤｅｌｉｖｅｒｅｄ１２１、およびＤｅｐｌｏｙｅｄ１３０のノードの配下にも２つのソフトウェアの情報が格納される。すなわちＤｅｌｉｖｅｒｅｄ１２１の配下には各ソフトウェアに対応する更新契機が配され、Ｄｅｐｌｏｙｅｄ１３０の配下には各ソフトウェアに対応する通知情報が配される。
　第２クライアントツリーＤＢ９２の構成は、第１の実施の形態における構成からソフトウェアおよびパッケージの名称を変更したものなので説明を省略する。
　上述した第２の実施の形態によれば、次の作用効果が得られる。
（１）第１更新装置１０は第１ＥＣＵ５１１および第２ＥＣＵ５１２に接続され、更新部３１は、第１ＥＣＵ５１１および第２ＥＣＵ５１２のソフトウェアを更新する。そのため、第１ＥＣＵ５１１および第２ＥＣＵ５１２がソフトウェアの更新に係る制御を実行できない場合でも第１更新装置１０が第１ＥＣＵ５１１および第２ＥＣＵ５１２に代わって、ソフトウェアの依存関係を満たしたまま、第１ＥＣＵ５１１および第２ＥＣＵ５１２にソフトウェアを更新させることができる。
（第２の実施の形態の変形例）
　第１更新装置１０は、第１ＥＣＵ５１１および第２ＥＣＵ５１２のソフトウェアだけでなく、第１更新装置１０のソフトウェアも更新してよい。また第２更新装置１１は、第３ＥＣＵ５１３のソフトウェアだけでなく、第２更新装置１１のソフトウェアも更新してよい。
　第１更新装置１０のプログラムはストレージ１５９に格納されるとしたが、第１更新装置１０が不図示の入出力インタフェースを備え、必要なときに入出力インタフェースと第１更新装置１０が利用可能な媒体を介して、他の装置からプログラムが読み込まれてもよい。ここで媒体とは、例えば入出力インタフェースに着脱可能な記憶媒体、または通信媒体、すなわち有線、無線、光などのネットワーク、または当該ネットワークを伝搬する搬送波やディジタル信号、を指す。また、プログラムにより実現される機能の一部または全部がハードウェア回路やＦＰＧＡにより実現されてもよい。
　上述した各実施の形態および変形例は、それぞれ組み合わせてもよい。
　上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。
　次の優先権基礎出願の開示内容は引用文としてここに組み込まれる。
　日本国特許出願２０１６年第２５２７８７号（２０１６年１２月２７日出願）
　　　　１　…　車両
　　　　２　…　サーバ
　　　　Ｓ　…　ソフトウェア更新システム
　　　１０　…　第１更新装置
　　　１１　…　第２更新装置
　　　３１　…　更新部
　　　３３　…　通信部
　　　４０　…　更新開始判断部
　　　４１　…　更新契機受信部
　　　４２　…　通知情報受信部
　　　４４　…　更新トリガ受信部
　　　４５　…　更新トリガ通知部
　　１９１　…　更新契機
　　１９５　…　通知情報
　　４５１　…　通知情報

Claims (10)

  1. 　１以上の他のソフトウェア更新装置及びサーバとネットワークを介して接続されるソフトウェア更新装置であって、
    　前記サーバから更新用データを受信する受信部と、
    　前記更新用データを用いてソフトウェアの更新を行う更新部と、
    　前記他のソフトウェア更新装置と通信する通信部と、
    　更新トリガの受信を含む前記ソフトウェアを更新する条件が記載された更新契機を前記サーバから受信する更新契機受信部と、
    　前記他のソフトウェア更新装置に前記更新トリガを送信する条件を含む通知情報を前記サーバから受信する通知情報受信部と、
    　前記通知情報に基づき前記他のソフトウェア更新装置に前記更新トリガを送信する更新トリガ通知部と、
    　前記他のソフトウェア更新装置から前記更新トリガを受信する更新トリガ受信部と、
    　前記更新契機に記述されているすべての条件が満たされたと判断すると前記更新部に前記ソフトウェアの更新を実行させる更新開始判断部とを備えるソフトウェア更新装置。
  2. 　１以上の他のソフトウェア更新装置及びサーバとネットワークを介して接続されるソフトウェア更新装置であって、
    　前記サーバから更新用データを受信する受信部と、
    　前記更新用データを用いてソフトウェアの更新を行う更新部と、
    　前記他のソフトウェア更新装置と通信する通信部と、
    　更新トリガの受信を含む前記ソフトウェアを更新する条件が記載された更新契機を前記サーバから受信する更新契機受信部と、
    　前記他のソフトウェア更新装置から前記更新トリガを受信する更新トリガ受信部と、
    　前記更新契機に記述されているすべての条件が満たされたと判断すると前記更新部に前記ソフトウェアの更新を実行させる更新開始判断部とを備えるソフトウェア更新装置。
  3. 　１以上の他のソフトウェア更新装置及びサーバとネットワークを介して接続されるソフトウェア更新装置であって、
    　前記サーバから更新用データを受信する受信部と、
    　前記更新用データを用いてソフトウェアの更新を行う更新部と、
    　前記他のソフトウェア更新装置と通信する通信部と、
    　前記ソフトウェアを更新する条件が記載された更新契機を前記サーバから受信する更新契機受信部と、
    　前記他のソフトウェア更新装置に更新トリガを送信する条件を含む通知情報を前記サーバから受信する通知情報受信部と、
    　前記通知情報に基づき前記他のソフトウェア更新装置に前記更新トリガを送信する更新トリガ通知部と、
    　前記更新契機に記述されているすべての条件が満たされたと判断すると前記更新部に前記ソフトウェアの更新を実行させる更新開始判断部とを備えるソフトウェア更新装置。
  4. 　請求項１または請求項３に記載のソフトウェア更新装置であって、
    　前記通知情報には、前記ソフトウェアが更新されると前記更新トリガが送信されることが含まれ、
    　前記更新トリガ通知部は、前記更新部が前記ソフトウェアの更新を完了すると前記更新トリガを送信するソフトウェア更新装置。
  5. 　請求項１または請求項３に記載のソフトウェア更新装置であって、
    　前記通知情報には、前記受信部が前記更新用データを受信すると前記更新トリガが送信されることが含まれ、
    　前記更新トリガ通知部は、前記受信部が前記更新用データを受信すると前記更新トリガを送信するソフトウェア更新装置。
  6. 　請求項１から請求項３までのいずれか一項に記載のソフトウェア更新装置であって、
    　前記ソフトウェア更新装置は車両に搭載され、
    　前記更新契機には前記車両のイグニッションのオンまたはオフが含まれ、
    　前記更新開始判断部は、前記イグニッションのオンまたはオフを検知可能なソフトウェア更新装置。
  7. 　請求項１から請求項３までのいずれか一項に記載のソフトウェア更新装置であって、
    　前記ソフトウェア更新装置はインターネットに接続される車両に搭載され、
    　前記更新契機には前記インターネットとの接続の切断が含まれ、
    　前記更新開始判断部は前記接続の切断を検知可能なソフトウェア更新装置。
  8. 　請求項１または請求項２に記載のソフトウェア更新装置であって、
    　記憶部をさらに備え、
    　前記更新トリガ受信部は受信した前記更新トリガを前記記憶部に記憶させ、
    　前記更新開始判断部は、前記記憶部に記憶されている前記更新トリガを含めて更新開始の判断を行うソフトウェア更新装置。
  9. 　請求項１から請求項３までのいずれか一項に記載のソフトウェア更新装置において、
    　前記ソフトウェア更新装置は制御装置に接続され、
    　前記更新部は、前記ソフトウェア更新装置のソフトウェア、および前記制御装置のソフトウェアの少なくとも一方を更新するソフトウェア更新装置。
  10. 　複数のソフトウェア更新装置およびサーバを含むソフトウェア更新システムであって、
    　前記サーバは、ソフトウェアを更新するための更新用データを配信する配信部を備え、
    　前記複数のソフトウェア更新装置の各々は、
    　前記サーバから前記更新用データを受信する受信部と、
    　前記更新用データを用いて前記ソフトウェアの更新を行う更新部と、
    　前記サーバおよび他のソフトウェア更新装置と通信する通信部と、
    　更新トリガの受信を含む前記ソフトウェアを更新する条件が記載された更新契機を前記サーバから受信する更新契機受信部と、
    　前記他のソフトウェア更新装置に前記更新トリガを送信する条件を含む通知情報を前記サーバから受信する通知情報受信部と、
    　前記通知情報に基づき前記他のソフトウェア更新装置に前記更新トリガを送信する更新トリガ通知部と、
    　前記他のソフトウェア更新装置から前記更新トリガを受信する更新トリガ受信部と、
    　前記更新契機に記述されているすべての条件が満たされたと判断すると前記更新部に前記ソフトウェアの更新を実行させる更新開始判断部とを備えるソフトウェア更新システム。
PCT/JP2017/038792 2016-12-27 2017-10-26 ソフトウェア更新装置、ソフトウェア更新システム WO2018123242A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US16/473,929 US11645062B2 (en) 2016-12-27 2017-10-26 Software update device and software update system
EP17886794.1A EP3564822A4 (en) 2016-12-27 2017-10-26 SOFTWARE UPDATE DEVICE AND SOFTWARE UPDATE SYSTEM
CN201780080696.5A CN110114761B (zh) 2016-12-27 2017-10-26 软件更新装置和软件更新系统

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016-252787 2016-12-27
JP2016252787A JP6667430B2 (ja) 2016-12-27 2016-12-27 ソフトウェア更新装置、ソフトウェア更新システム

Publications (1)

Publication Number Publication Date
WO2018123242A1 true WO2018123242A1 (ja) 2018-07-05

Family

ID=62708219

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/038792 WO2018123242A1 (ja) 2016-12-27 2017-10-26 ソフトウェア更新装置、ソフトウェア更新システム

Country Status (5)

Country Link
US (1) US11645062B2 (ja)
EP (1) EP3564822A4 (ja)
JP (1) JP6667430B2 (ja)
CN (1) CN110114761B (ja)
WO (1) WO2018123242A1 (ja)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7003975B2 (ja) 2018-08-10 2022-01-21 株式会社デンソー 車両情報通信システム，センター装置及びセンター装置のメッセージ送信方法
JP7287476B2 (ja) * 2019-08-28 2023-06-06 株式会社デンソー 車両用マスタ装置、車両用電子制御システム、コンフィグ情報の書換え指示方法及びコンフィグ情報の書換え指示プログラム
JP7392407B2 (ja) 2019-11-14 2023-12-06 株式会社デンソー センター装置、車両用電子制御システム、プログラム更新の進捗制御方法及びプログラム更新の進捗制御プログラム
CN113162959B (zh) * 2020-01-23 2023-06-30 华为技术有限公司 车载设备的升级方法和装置
JP7396216B2 (ja) * 2020-06-26 2023-12-12 トヨタ自動車株式会社 サーバ、更新管理方法、更新管理プログラム及びソフトウェア更新装置
KR20220001924A (ko) * 2020-06-30 2022-01-06 현대자동차주식회사 차량의 ecu 업데이트 제어 장치 및 그 방법
JP7380468B2 (ja) * 2020-07-20 2023-11-15 トヨタ自動車株式会社 ソフトウェア更新装置、更新制御方法、更新制御プログラム、サーバ、ｏｔａマスタ及びセンタ
US11513792B2 (en) * 2020-09-30 2022-11-29 Izuma Tech, Inc. Tracking history of firmware program updates
CN114461240B (zh) * 2021-06-30 2023-04-14 荣耀终端有限公司 软件升级方法、软件升级系统及电子设备
JP2023022405A (ja) * 2021-08-03 2023-02-15 トヨタ自動車株式会社 情報処理装置、情報処理方法、およびシステム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006011647A (ja) * 2004-06-23 2006-01-12 Fujitsu Ten Ltd ソフトウェア管理装置
JP2011095950A (ja) 2009-10-29 2011-05-12 Seiko Epson Corp ネットワークデバイス、ネットワークデバイスシステムおよびネットワークデバイスのソフトウェア更新方法
JP2014041456A (ja) * 2012-08-22 2014-03-06 Toyota Motor Corp 車載機器、携帯端末、情報管理装置、情報通信システム
US20160147525A1 (en) * 2014-11-20 2016-05-26 Hyundai Motor Company System and method for firmware update of vehicle

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2333864B (en) * 1998-01-28 2003-05-07 Ibm Distribution of software updates via a computer network
US7539686B2 (en) 2004-03-12 2009-05-26 Microsoft Corporation Tag-based schema for distributing update metadata in an update distribution system
US20060106806A1 (en) * 2004-11-12 2006-05-18 Smith Micro Software, Inc. Software update for a plurality of mobile devices
US8214470B2 (en) * 2007-11-02 2012-07-03 Telefonaktiebolaget L M Ericsson (Publ) Upgrading software in radio base station nodes
EP2229625B1 (en) * 2007-12-13 2011-08-31 Telefonaktiebolaget LM Ericsson (publ) Updating firmware of an electronic device
US8892699B2 (en) * 2008-12-31 2014-11-18 Schneider Electric USA, Inc. Automatic firmware updates for intelligent electronic devices
US20120216183A1 (en) * 2011-02-23 2012-08-23 Amit Mahajan Firmware updation in electronic devices
US9092300B2 (en) * 2013-04-18 2015-07-28 Ottr Products, Llc Peripheral device and method for updating firmware thereof
US9952851B2 (en) * 2015-03-10 2018-04-24 International Business Machines Corporation Intelligent mobile application update
US9934020B2 (en) 2015-03-10 2018-04-03 International Business Machines Corporation Intelligent mobile application update
US10042635B2 (en) 2015-06-16 2018-08-07 Lear Corporation Method for wireless remote updating vehicle software
US9703490B2 (en) * 2015-07-27 2017-07-11 Datrium, Inc. Coordinated upgrade of a cluster storage system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006011647A (ja) * 2004-06-23 2006-01-12 Fujitsu Ten Ltd ソフトウェア管理装置
JP2011095950A (ja) 2009-10-29 2011-05-12 Seiko Epson Corp ネットワークデバイス、ネットワークデバイスシステムおよびネットワークデバイスのソフトウェア更新方法
JP2014041456A (ja) * 2012-08-22 2014-03-06 Toyota Motor Corp 車載機器、携帯端末、情報管理装置、情報通信システム
US20160147525A1 (en) * 2014-11-20 2016-05-26 Hyundai Motor Company System and method for firmware update of vehicle

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3564822A4

Also Published As

Publication number Publication date
JP6667430B2 (ja) 2020-03-18
US11645062B2 (en) 2023-05-09
US20190354363A1 (en) 2019-11-21
EP3564822A1 (en) 2019-11-06
EP3564822A4 (en) 2020-08-19
CN110114761B (zh) 2023-04-28
CN110114761A (zh) 2019-08-09
JP2018106461A (ja) 2018-07-05

Similar Documents

Publication Publication Date Title
WO2018123242A1 (ja) ソフトウェア更新装置、ソフトウェア更新システム
CN106897086B (zh) 用于升级机器人操作系统的方法、装置及系统
EP3764220B1 (en) Automatic application updates
JP2011148398A (ja) 車両用プログラム更新システム
JP5444865B2 (ja) 通信装置
US8001095B2 (en) Method of updating a version of an application program
US9058182B2 (en) Management device for causing devices to update programs and computer readable media
CN102724308A (zh) 软件更新方法及软件更新系统
CN102420873B (zh) 复合网络全新云应用平台
CN102855152A (zh) 升级应用程序中资源文件的方法及系统
US20190303557A1 (en) Controller, control method, and non-transitory storage medium storing program
CN112748942A (zh) 车辆用控制装置、程序更新方法以及程序更新系统
CN112134908B (zh) 应用适配方法及服务器、介质、车载多媒体系统
JP5847457B2 (ja) 画像形成装置及びその処理方法
US9268553B2 (en) Management device for causing specific device to update programs and computer readable media
KR20120074321A (ko) 관리장치, 및 그 방법
CN103631621A (zh) 一种信息提示方法及装置
US20210201599A1 (en) Vehicle and software update method
JP7435100B2 (ja) プログラム更新システム及び車両管理サーバー
US9049180B2 (en) Method for providing a signal output on the basis of a main file and at least one secondary file, and motor vehicle
WO2023119909A1 (ja) 車両通信システム及び車載側システム
JPH10269045A (ja) ネットワーク分散型画像処理システム
CN108089868B (zh) 对智能设备上的项目进行升级的方法以及相关设备
JP6101333B2 (ja) 画像形成装置及びその制御方法、管理装置及びその制御方法、及びプログラム
CN114296763A (zh) 物联网设备的固件升级方法、装置、服务器及存储介质

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: 17886794

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017886794

Country of ref document: EP

Effective date: 20190729