WO2019038855A1 - 車載電子機器、サーバ装置、およびソフトウェア更新方法 - Google Patents

車載電子機器、サーバ装置、およびソフトウェア更新方法 Download PDF

Info

Publication number
WO2019038855A1
WO2019038855A1 PCT/JP2017/030111 JP2017030111W WO2019038855A1 WO 2019038855 A1 WO2019038855 A1 WO 2019038855A1 JP 2017030111 W JP2017030111 W JP 2017030111W WO 2019038855 A1 WO2019038855 A1 WO 2019038855A1
Authority
WO
WIPO (PCT)
Prior art keywords
update
software
vehicle electronic
vehicle
electronic device
Prior art date
Application number
PCT/JP2017/030111
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 PCT/JP2017/030111 priority Critical patent/WO2019038855A1/ja
Publication of WO2019038855A1 publication Critical patent/WO2019038855A1/ja

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • 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

Definitions

  • the present invention relates to an on-vehicle electronic device, a server device, and a software update method for updating software of an on-vehicle electronic device in cooperation with the server device.
  • the electronic control unit according to Patent Document 1 has two storage areas, and normally stores the same program in each storage area by mirroring. At the time of program update, the electronic control unit compresses one of the storage areas to secure an information storage area, and temporarily stores update data of the program in the information storage area.
  • the present invention has been made to solve the problems as described above, and it is an object of the present invention to secure resources required for software update of on-vehicle electronic devices.
  • the on-vehicle electronic device is one on-vehicle electronic device among a plurality of on-vehicle electronic devices connected to the in-vehicle network, and receives a software update request from a server apparatus outside the vehicle via a wireless communication network.
  • the memory map information indicating the free space of the plurality of storage units of the plurality of in-vehicle electronic devices connected to the in-vehicle network is transmitted to the server device via the wireless communication network, and from the server device via the wireless communication network
  • the update data for updating the capacity smaller than the free space of the plurality of storage units included in the plurality of in-vehicle electronic devices among the update software for the in-vehicle electronic devices targeted for software update among the plurality of in-vehicle electronic devices is received .
  • Software update target using free space of multiple storage units of multiple in-vehicle electronic devices Become vehicle electronic device is intended comprise updating the master processing unit to perform the software update.
  • the software update is performed using the free space of the plurality of storage units of the plurality of in-vehicle electronic devices connected to the in-vehicle network. Therefore, the resources required for the software update of the in-vehicle electronic devices Can be secured.
  • FIG. 1 is a block diagram showing a configuration example of a software update system according to a first embodiment.
  • FIG. 2 is a block diagram showing an exemplary configuration of a server apparatus according to Embodiment 1;
  • FIG. 2 is a block diagram showing a configuration example of a master device which is an in-vehicle electronic device according to Embodiment 1.
  • FIG. 2 is a block diagram showing a configuration example of a slave device which is an in-vehicle electronic device according to Embodiment 1.
  • FIG. 2 is a block diagram showing an example of a hardware configuration common to the server device and the on-vehicle electronic device according to Embodiment 1.
  • FIG. 2 is a diagram showing an outline of a program stored in a ROM in the first embodiment.
  • FIG. 7 is a diagram showing the relationship between an old software image, a new software image, and update data in the first embodiment.
  • 5 is a flowchart showing an outline of a software update method of the software update system according to the first embodiment.
  • 5 is a flowchart showing an operation example of the server apparatus according to the first embodiment.
  • 7 is a flowchart showing an operation example of the master device according to the first embodiment. It is a flowchart which shows the detail of the operation
  • FIG. 5 is a diagram showing an example of a system memory map in the first embodiment. It is a flowchart which shows the detail of the operation
  • FIG. 7 is a block diagram showing a modification of the software update system according to the first embodiment.
  • FIG. 1 is a block diagram showing an example of the configuration of a software update system 1 according to the first embodiment.
  • the software update system 1 includes a server device 10, and a master device 20 and slave devices 30A to 30F, which are on-vehicle electronic devices.
  • a master device 20 and slave devices 30A to 30F are mounted on one vehicle.
  • the master device 20 can communicate with the server device 10 outside the vehicle via the wireless communication network 2.
  • the wireless communication network 2 is, for example, WWAN (Wireless Wide Area Network), LTE (Long Term Evolution), or 3G.
  • the master device 20 and the slave devices 30A to 30F are connected via the in-vehicle network 3.
  • the in-vehicle network 3 is, for example, a controller area network (CAN), a media oriented system transport (MOST), or Ethernet (registered trademark).
  • the master device 20 can communicate with the server device 10, and the on-vehicle electronic device to be updated with software is any of the slave devices 30A to 30F.
  • the software image in the first embodiment refers to an image of part or all of the software written to each slave device. If it is necessary to distinguish between some and all of the software, please note that.
  • FIG. 2A is a block diagram showing a configuration example of the server apparatus 10 according to the first embodiment.
  • the server device 10 includes an image database 11, an update data generation unit 12, an update server processing unit 13, a wireless communication unit 14, and a PC (Personal Computer) 15.
  • the image database 11 stores all of the old software images of each of the slave devices 30A to 30F and all of the new software images.
  • the old software image is software before update, and the new software image is update software.
  • the update data generation unit 12 reads out from the image database 11 the new and old software images of the slave device to be subjected to software update among the slave devices 30A to 30F, extracts the difference between the new and old software images, and generates difference data.
  • the difference data is update data for updating software of any of the slave devices 30A to 30F.
  • the update server processing unit 13 communicates with the master device 20 via the wireless communication unit 14 to execute software update processing of the slave device targeted for software update.
  • the wireless communication unit 14 communicates with the master device 20 via the wireless communication network 2.
  • the PC 15 stores the entire new software image in the image database 11.
  • the PC 15 also manages the server device 10.
  • FIG. 2B is a block diagram showing a configuration example of the master device 20 which is the on-vehicle electronic device according to the first embodiment.
  • the master device 20 is, for example, a head unit or a gateway.
  • the master device 20 controls software update processing of the slave devices 30A to 30F.
  • the master device 20 includes an update master processing unit 21, a new image generation unit 22, an empty memory 23, a wireless communication unit 24, and an in-vehicle communication unit 25.
  • the update master processing unit 21 responds to the server device 10 via the wireless communication unit 24 in response to the request from the server device 10 received by the wireless communication unit 24 and also receives slave devices 30A to 30F via the in-vehicle communication unit 25. And instructs the slave devices 30A to 30F to perform software update processing.
  • the update master processing unit 21 generates a system memory map indicating the capacity of free memory of the slave devices 30A to 30F.
  • the information indicating the system memory map corresponds to "memory map information".
  • the new image generation unit 22 generates a new software image using the old software image of the slave device targeted for software update and the update data transmitted by the server device 10.
  • the empty memory 23 is a non-volatile memory for storing system memory map information and the like at the time of software update. This non-volatile memory is referred to as an empty memory 23 because it is not currently used, and is an empty memory 102 c of the ROM 102 described later.
  • the wireless communication unit 24 communicates with the server device 10 via the wireless communication network 2.
  • the in-vehicle communication unit 25 communicates with the slave devices 30A to 30F via the in-vehicle network 3.
  • FIG. 2C is a block diagram showing a configuration example of the slave device 30 which is the on-vehicle electronic device according to the first embodiment.
  • the slave device 30 is, for example, an ECU (Electronic Control Unit) that controls an engine, or an ECU that controls an air conditioner.
  • the slave device 30 updates its own software under the control of the master device 20.
  • the slave device 30 includes an update slave processing unit 31, a software update unit 32, an empty memory 33, and an in-vehicle communication unit 34.
  • the update slave processing unit 31 responds to the master device 20 via the in-vehicle communication unit 34 in response to the request from the master device 20 received by the in-vehicle communication unit 34.
  • the software update unit 32 performs software update processing by erasing the old software image of itself and writing a new software image, when the software update unit 32 itself is a slave device that is a software update target.
  • the empty memory 33 is a non-volatile memory for temporarily storing backup data and the like at the time of software update.
  • the in-vehicle communication unit 34 communicates with the master device 20 via the in-vehicle network 3.
  • Each of the slave devices 30A to 30F shown in FIG. 1 includes the update slave processing unit 31, the software update unit 32, the empty memory 33, and the in-vehicle communication unit 34, similarly to the slave device 30 shown in FIG. 2C.
  • the slave devices 30A to 30F are hereinafter referred to as slave devices 30 when it is not necessary to distinguish them.
  • FIG. 3 is a block diagram showing an example of the hardware configuration common to the server device 10 according to the first embodiment and the master device 20 and the slave device 30 which are in-vehicle electronic devices.
  • the server device 10 includes a CPU 101, a ROM 102, and a RAM 103 connected to a bus 100.
  • Each function of the update data generation unit 12 and the update server processing unit 13 in the server device 10 is realized by software.
  • the software is written as a program and stored in the ROM 102.
  • the CPU 101 implements the functions of the respective units by reading out the program stored in the ROM 102 to the RAM 103 and executing the program.
  • the server device 10 includes the ROM 102 for storing a program which, when executed by the CPU 101, causes the steps shown in the flowchart to be described later to be executed. Also, it can be said that this program causes a computer or the like to execute the procedure or method of the update data generation unit 12 and the update server processing unit 13.
  • the image database 11 in the server device 10 is, for example, an HDD (Hard Disk Drive).
  • Master device 20 includes CPU 101, ROM 102, and RAM 103 connected to bus 100. Each function of the update master processing unit 21 and the new image generation unit 22 in the master device 20 is realized by software.
  • the software is written as a program and stored in the ROM 102.
  • the CPU 101 implements the functions of the respective units by reading out the program stored in the ROM 102 to the RAM 103 and executing the program. That is, the master device 20 includes the ROM 102 for storing a program which, when executed by the CPU 101, causes the steps shown in the flowchart to be described later to be executed. Also, it can be said that this program causes a computer or the like to execute the procedure or method of the update master processing unit 21 and the new image generation unit 22.
  • the slave device 30 includes a CPU 101, a ROM 102, and a RAM 103 connected to the bus 100.
  • Each function of the update slave processing unit 31 and the software update unit 32 in the slave device 30 is realized by software.
  • the software is written as a program and stored in the ROM 102.
  • the CPU 101 implements the functions of the respective units by reading out the program stored in the ROM 102 to the RAM 103 and executing the program. That is, the slave device 30 includes the ROM 102 for storing a program which, when executed by the CPU 101, causes the steps shown in the flowchart to be described later to be executed. Further, it can be said that this program causes a computer or the like to execute the procedure or method of the update slave processing unit 31 and the software update unit 32.
  • FIG. 4 is a diagram showing an outline of a program stored in the ROM 102 in the first embodiment.
  • the ROM 102 of the master device 20 and the slave device 30 includes a boot program 102a, an application program 102b, and an empty memory 102c.
  • the boot program 102 a is read out immediately after the power is turned on and developed in the RAM 103.
  • the application program 102 b is read out and expanded on the RAM 103 after the boot program 102 a finishes the inspection of the CPU 101.
  • the boot program 102 a and the application program 102 b are mainly targeted for software update.
  • the empty memory 102 c is the empty memory 23 or the empty memory 33 and is a storage unit.
  • FIG. 5 is a diagram showing the relationship between the old software image, the new software image, and the update data in the first embodiment.
  • the update data generation unit 12 of the server device 10 uses the system memory map information received from the master device 20 to generate update data capable of update processing with a capacity matched to the total empty memory capacity of the slave devices 30A to 30F. .
  • the capacity of the update target software image to be updated is 100 Kbytes
  • the total free memory capacity of the slave devices 30A to 30F indicated by the system memory map information is 30 Kbytes.
  • the update data generation unit 12 generates update data for the partial update target software image having a capacity smaller than 30 KBytes.
  • the update data generation unit 12 divides the 100 KByte update target software image into 20 KBytes and sets five partial update target software when the capacity per one partial update target software image is set to 20 KBytes with a margin.
  • the image is divided into five pieces of differential data by comparing each of the divided five partially updated target software images to generate five pieces of differential data, which are converted into five pieces of updated data. If the capacity of the software image to be updated is smaller than 30 Kbytes, no division is necessary, and the update data generation unit 12 uses one difference data as it is as one update data.
  • the update data generation unit 12 may set the capacity per new and old software image to be generated as update data, according to the ROM configuration of the CPU 101 of the slave devices 30A to 30F. For example, since the CPU 101 updates data stored in the ROM 102 in units of block memory, the update data generation unit 12 sets update data to N times (N is a natural number) the capacity of new and old software images to be compared. Preferably it is generated. That is, it is preferable that the new software image to be rewritten using the update data be N times as large as the block memory.
  • FIG. 6 is a flowchart showing an outline of a software update method of the software update system 1 according to the first embodiment.
  • the slave device 30 targeted for software update is the slave device 30A.
  • the server device 10 transmits an update request to the master device 20, which is an on-vehicle electronic device, via the wireless communication network 2.
  • the master device 20 receives the update request from the server device 10 via the wireless communication network 2, and the free capacity of the plurality of empty memories 33 possessed by the plurality of slave devices 30A to 30F connected to the in-vehicle network 3 System memory map information representing the above is transmitted to the server device 10 via the wireless communication network 2.
  • the server device 10 receives system memory map information from the master device 20 via the wireless communication network 2, and uses the system memory map information to select a slave as a software update target of the slave devices 30A to 30F.
  • update software for the device 30A update data is generated for new and old software images smaller than the free capacity of the plurality of empty memories 33 possessed by the plurality of slave devices 30A to 30F, and the master device is generated via the wireless communication network 2.
  • Send updated data to 20 Send updated data to 20.
  • the master device 20 receives update data from the server device 10 via the wireless communication network 2, and uses the free space of the plurality of empty memories 33 possessed by the plurality of slave devices 30A to 30F to perform software update
  • the slave device 30A is updated to perform the software update.
  • the software update can be performed using the resources of the other slave devices 30B to 30F connected to the slave device 30A. it can.
  • FIG. 7 is a flowchart showing an operation example of the server device 10 according to the first embodiment.
  • the server device 10 periodically repeats the operation shown in the flowchart of FIG.
  • the update server processing unit 13 determines whether or not an event has occurred and the type of the event. If an event has not occurred (step ST100 “NO”), the update server processing unit 13 repeats step ST100. If an event has occurred (step ST100 “YES”), the update server processing unit 13 determines the type of event as follows. .
  • step ST110 the update server processing unit 13 transmits an update request to the master device 20 via the wireless communication unit 14.
  • step ST100 When the master device 20 transmits the system memory map information to the server device 10, the update server processing unit 13 receives the system memory map information via the wireless communication unit 14, and it is determined that “system memory map notification” is present in step ST100. It determines and progresses to step ST120. The operations in step ST120 and step ST130 will be described later.
  • step ST100 When the master device 20 transmits a partial completion response of the software update process to the server device 10, the update server processing unit 13 receives the partial completion response via the wireless communication unit 14, and there is a "partial completion response" in step ST100. It determines with it and progresses to step ST140. The operation in step ST140 will be described later.
  • step ST100 When the master device 20 transmits an all completion response of the software update process to the server device 10, the update server processing unit 13 receives the all completion response via the wireless communication unit 14, and there is an “all completion response” in step ST100. It determines with it and progresses to step ST150. The operation in step ST150 will be described later.
  • FIG. 8 is a flowchart showing an operation example of the master device 20 according to the first embodiment.
  • the master device 20 periodically repeats the operation shown in the flowchart of FIG.
  • the update master processing unit 21 determines whether or not an event has occurred and the type of the event. When an event has not occurred (step ST200 “NO”), the update master processing unit 21 repeats step ST200, and when an event occurs (step ST200 “YES”), determines the type of the event.
  • the server device 10 transmits the update request to the master device 20
  • the update master processing unit 21 receives the update request via the wireless communication unit 24, determines that the “update request” is present, and proceeds to step ST210.
  • the update master processing unit 21 investigates the empty memory 33 of the slave devices 30A to 30F. Details of the operation in step ST210 are shown in FIG.
  • step ST270 the update master processing unit 21 receives the ROM abnormality notification via the in-vehicle communication unit 25, and determines that the "ROM abnormality notification" is present. Proceed to step ST270. The operation in step ST270 will be described later.
  • FIG. 9 is a flow chart showing details of the operation in step ST210 of FIG.
  • the update master processing unit 21 broadcasts an empty memory information request to the slave devices 30A to 30F connected to the in-vehicle network 3 via the in-vehicle communication unit 25.
  • FIG. 10 is a flowchart showing an operation example of the slave device 30 according to the first embodiment.
  • the slave device 30 periodically repeats the operation shown in the flowchart of FIG.
  • the update slave processing unit 31 determines whether or not an event has occurred and the type of the event. If an event has not occurred (step ST310 “NO”), the update slave processing unit 31 repeats step ST300. If an event has occurred (step ST310 “YES”), the update slave processing unit 31 determines the type of the event.
  • step ST320 the update slave processing unit 31 checks the capacity of the free memory 33 of itself, the address position of the free memory 33, and the like, and transmits free memory information to the master device 20 via the in-vehicle communication unit 34.
  • step ST212 of FIG. 9 the update master processing unit 21 waits for the slave devices 30A to 30F to respond to the empty memory information request.
  • the update master processing unit 21 receives empty memory information as a response to the empty memory information request from any of the slave devices 30A to 30F via the in-vehicle communication unit 25 (step ST212 “YES”), the process proceeds to step ST213 The process proceeds, and if not received (step ST212 “NO”), step ST212 is repeated.
  • step ST213 the update master processing unit 21 stores the empty memory information received from any of the slave devices 30A to 30F.
  • step ST214 if the update master processing unit 21 has received empty memory information from all of the slave devices 30A to 30F (step ST214 "YES"), the process proceeds to step ST215, and if not received (step ST214). “NO”), returns to step ST212. If there is no response from the slave devices 30A to 30F even if a predetermined time (for example, 10 seconds) elapses after the empty memory information request is issued in step ST211, the update master processing unit 21 performs time-out processing in step STST214. It may be determined that all responses have been made (step ST214 "YES”), and the process may proceed to step ST215.
  • a predetermined time for example, 10 seconds
  • step ST215 the update master processing unit 21 generates a system memory map using the empty memory information received from all of the slave devices 30A to 30F, and stores the system memory map in the ROM 102 of the master device 20. Thereafter, the update master processing unit 21 proceeds to step ST220 in FIG.
  • FIG. 11 is a diagram showing an example of a system memory map in the first embodiment.
  • the update master processing unit 21 registers, for example, “5 KByte” in the “empty memory capacity” column of the slave device ID “A” using the empty memory information received from the slave device 30A.
  • the total free memory capacity of all the slave devices 30A to 30F is "30 KBytes".
  • step ST220 of FIG. 8 the update master processing unit 21 exchanges information with the server device 10. The details of the operation in step ST220 are shown in FIG.
  • FIG. 12 is a flowchart showing the details of the operation in step ST220 of FIG.
  • the update master processing unit 21 transmits system memory map information to the server device 10 via the wireless communication unit 24.
  • step ST120 of FIG. 7 the update data generation unit 12 uses the system memory map information received from the master device 20 to target one new and old software image of a capacity smaller than the total free memory capacity of the slave devices 30A to 30F. Generate the above update data.
  • the update data generation unit 12 generates five update data as shown in FIG. In this example, one update data is about several hundred bytes to several K bytes.
  • step ST130 the update server processing unit 13 transmits one of the five update data generated by the update data generation unit 12 in step ST120 to the master device 20 via the wireless communication unit 14.
  • the update server processing unit 13 determines the difference data capacity (for example, several KBytes), which is the total capacity of all update data, the number of update processes (for example, 5 times), and the start position
  • the update target address which is an address indicating the address, and the name of the update target device (for example, the slave device 30A) are transmitted together with the update data.
  • step ST222 of FIG. 12 the update master processing unit 21 waits for the response of the server device 10 to system memory map information transmission. If the update master processing unit 21 receives update data etc. from the server device 10 via the wireless communication unit 24 (step ST222 “YES”), the process proceeds to step ST223, and if not received (step ST222 “NO”) , Step ST222 is repeated. In step ST 223, the update master processing unit 21 stores update data and the like received from the server device 10 in the RAM 103 of the master device 20. After that, the update master processing unit 21 proceeds to step ST230 of FIG.
  • step ST230 of FIG. 8 the update master processing unit 21 carries out a software update process on the slave device 30 that is the object of software update. Details of the operation in step ST230 are shown in FIG.
  • FIG. 13 is a flowchart showing details of the operation in step ST230 of FIG.
  • the slave device 30 targeted for software update is the slave device 30A.
  • the update master processing unit 21 transmits the old image transmission request to the slave device 30A targeted for software update via the in-vehicle communication unit 25.
  • the old image transmission request is a request for acquiring the software image of the update target address of the slave device 30A.
  • the update slave processing unit 31 of the slave device 30A receives the old image transmission request via the in-vehicle communication unit 34. Then, the update slave processing unit 31 of the slave device 30A determines that the “old image transmission request” is present in step ST310 of FIG. 10, and proceeds to step ST330. In step ST330, the update slave processing unit 31 of the slave device 30A transmits the software image of the update target address designated by the old image transmission request in the software image before update, that is, the old software image to the master via the in-vehicle communication unit 34. Transmit to device 20.
  • step ST232 of FIG. 13 the update master processing unit 21 waits for the slave device 30A to respond to the old image transmission request.
  • the update master processing unit 21 receives the old software image of the update target address from the slave device 30A via the in-vehicle communication unit 25 (step ST232 “YES”), the received old software image is stored in the RAM 103 of the master device 20. It memorizes, advances to step ST233.
  • the update master processing unit 21 repeats step ST232.
  • step ST233 the update master processing unit 21 performs backup processing of the old software image received in step ST232. Details of the operation in step ST233 are shown in FIG.
  • FIG. 14 is a flowchart showing details of the operation in step ST233 of FIG.
  • the update master processing unit 21 refers to the system memory map, and calculates how to divide the old software image and to be stored in which slave devices 30A to 30F. If all of the old software image can be stored in the single empty memory 33, no division is necessary. For example, the update master processing unit 21 divides the old software image into four 5 KBytes, and calculates that the 5 K Byte old software image is stored as a backup in each of the slave devices 30B to 30E. Then, as shown in FIG.
  • the update master processing unit 21 registers “presence” in the “backup availability” column of slave device IDs “B”, “C”, “D” and “E” in the system memory map. At the same time, "5 KByte” is registered in the "backup memory location” column.
  • the “backup memory position” is an address position of the empty memory 33 at which the slave devices 30 B to 30 E respond to the empty memory information request from the master device 20.
  • step ST233-2 the update master processing unit 21 transmits the divided old software image and backup request to the slave device 30B via the in-vehicle communication unit 25 as calculated in step ST233-1.
  • step ST233-3 the update master processing unit 21 finishes transmitting the old software image and the backup request divided to all of the slave devices 30B to 30E to be backed up (step ST233-3 "YES")
  • step ST233-3 "YES” The process proceeds to step ST234 in FIG. 13, and when the transmission is not completed (step ST233-3 "NO"), the process returns to step ST233-1.
  • the update slave processing unit 31 of the slave devices 30B to 30E divides the old software image and backup divided via the in-vehicle communication unit 34. Receive a request. Then, the update slave processing unit 31 of the slave devices 30B to 30E determines that the “backup request” is present in step ST310 of FIG. 10, and proceeds to step ST350. In step ST350, the update slave processing unit 31 of the slave devices 30B to 30E stores the old software image received from the master device 20 as backup data at an address position in the empty memory 33 of the slave devices 30B to 30E. This address position is the address position of the empty memory 33 when the slave devices 30 B to 30 E respond to the empty memory information request from the master device 20.
  • the update master processing unit 21 may store not only the old software image but also the update data in the empty memory 33 of the slave device 30. Backing up the update data eliminates the need for the master device 20 to request the update data from the server apparatus 10 in the recovery process of FIGS. 15 and 16 described later.
  • step ST234 of FIG. 13 the new image generation unit 22 uses the update data received from the server apparatus 10 in step ST220 and the old software image received from the slave device 30A targeted for software update in step ST231. Generate a new software image.
  • the new image generation unit 22 stores the generated new software image in the RAM 103 of the master device 20.
  • the update master processing unit 21 transmits the new software image generated by the new image generation unit 22 and the software rewrite request to the slave device 30A targeted for software update via the in-vehicle communication unit 25.
  • the update slave processing unit 31 of the slave device 30A receives the new software image and the software rewrite request via the in-vehicle communication unit 34. Then, the update slave processing unit 31 of the slave device 30A determines that the “software rewrite request” is present in step ST310 of FIG. 10, and proceeds to step ST370. In step ST370, the software update unit 32 of the slave device 30A erases the old software image at the update target address of the ROM 102 of the slave device 30A, and writes the received new software image.
  • step ST380 the update slave processing unit 31 of the slave device 30A proceeds to step ST390 when the software rewrite processing of the software update unit 32 is successful (step ST380 “YES”), and fails (step ST380 “NO”). Proceed to step ST400.
  • step ST390 the update slave processing unit 31 of the slave device 30A transmits a success response to the master device 20 via the in-vehicle communication unit 34.
  • step ST400 the update slave processing unit 31 of the slave device 30A transmits a failure response to the master device 20 via the in-vehicle communication unit 34.
  • step ST236 of FIG. 13 the update master processing unit 21 waits for the response of the slave device 30A to the software rewrite request.
  • the update master processing unit 21 receives the success response from the slave device 30A via the in-vehicle communication unit 25 (step ST237 “YES”), the process proceeds to step ST237.
  • the update master processing unit 21 receives a failure response from the slave device 30A (step ST237 “NO”), the update master processing unit 21 returns to step ST235, and resends a new software image and a software rewrite request to the slave device 30A. Since the new software image remains in the RAM 103 of the master device 20, the update master processing unit 21 can make another software rewrite request.
  • step ST 237 the update master processing unit 21 broadcasts a backup data deletion request to the slave devices 30 A to 30 F connected to the in-vehicle network 3 via the in-vehicle communication unit 25. After that, the update master processing unit 21 proceeds to step ST240 in FIG.
  • the update slave processing unit 31 of the slave devices 30A to 30F receives the backup data deletion request via the in-vehicle communication unit.
  • the update slave processing unit 31 of the slave devices 30B to 30E having backup data determines that the “backup data deletion request” is present in step ST310 of FIG. 10, and proceeds to step ST360.
  • the update slave processing unit 31 of the slave devices 30B to 30E erases the backup data stored in the empty memory 33 of the slave devices 30B to 30E.
  • step ST240 of FIG. 8 since the update master processing unit 21 has completed the software update process using the update data of one of the plurality of divided update data, the update master processing unit 21 sends the server device 10 via the wireless communication unit 24. , Send a partial completion response.
  • step ST250 update master processing unit 21 proceeds to step ST260 when the software update processing using all of the plurality of divided update data is completed (step ST250 “YES”), and when not completed (step ST250) “NO”), returns to step ST220.
  • step ST260 the update master processing unit 21 transmits an all-completion response to the server device 10 via the wireless communication unit 24.
  • the update server processing unit 13 receives the partial completion response via the wireless communication unit 14, and there is a "partial completion response" in step ST100. It determines with it and progresses to step ST140.
  • the update server processing unit 13 stores which update data of the plurality of divided update data has been used to complete the software update process. Thus, the update server processing unit 13 can determine to which extent of the software image the update has been completed and which portion is currently being updated when there is an abnormality. Thereafter, the update server processing unit 13 proceeds to step ST130 and transmits the remaining update data to the master device 20.
  • the update server processing unit 13 receives the all completion response via the wireless communication unit 14, and there is an “all completion response” in step ST100. It determines with it and progresses to step ST150. In step ST150, the update server processing unit 13 stores that the software update process using all of the plurality of divided update data is completed.
  • step ST270 of FIG. 8 the recovery process in step ST270 of FIG. 8 will be described. If the power of the master device 20 or the slave device 30A or the like is turned off during the software rewriting process in step ST370 of FIG. 10, in particular, until the rewriting of the new software image is completed after erasing the old software image The slave device 30A is lost in the software image. Also, since the master device 20 only stores the new software image in the RAM 103 of the master device 20, when the power of the master device 20 is turned off, the new software image of the RAM 103 disappears.
  • the master device 20 or the slave device 30A or the like starts activation.
  • the slave device 30A targeted for software update performs the operation shown in the flowchart of FIG.
  • FIG. 15 is a flowchart showing an operation example of the slave device 30A according to the first embodiment at the time of abnormality.
  • the update slave processing unit 31 in the slave device 30A targeted for software update determines whether the software image of the application program 102b in the ROM 102 is lost.
  • the update slave processing unit 31 of the slave device 30A determines that there is a defect because the software image is lost (step ST411 "YES"), Go to ST412.
  • step ST411 “NO” the update slave processing unit 31 of the slave device 30A ends the operation shown in the flowchart of FIG.
  • the update slave processing unit 31 of the slave device 30A transmits the ROM abnormality notification to the master device 20 via the in-vehicle communication unit 34.
  • step ST270 the update master processing unit 21 performs a recovery process of the software image of the slave device 30A that is the object of software update. The details of the operation in step ST270 are shown in FIG.
  • FIG. 16 is a flowchart showing details of the operation in step ST 270 of FIG.
  • the update master processing unit 21 refers to the system memory map and confirms where the old software image and update data are stored.
  • step ST272 the update master processing unit 21 transmits a backup data transmission request to the slave devices 30B to 30E storing the old software image and the update data via the in-vehicle communication unit 25.
  • the update master processing unit 21 requests the server device 10 to resend the update data via the wireless communication unit 24. Just do it.
  • the update slave processing unit 31 of the slave devices 30B to 30E receives the backup data transmission request via the in-vehicle communication unit 34. Then, the update slave processing unit 31 of the slave devices 30B to 30E determines that the “backup data transmission request” is present in step ST310 of FIG. 10, and proceeds to step ST340. In step ST340, the update slave processing unit 31 of the slave devices 30B to 30E transmits the backup data stored in the empty memory 33 of the slave devices 30B to 30E, that is, the divided old software image through the in-vehicle communication unit 34. Transmit to the master device 20.
  • step ST273 the update master processing unit 21 waits for responses from the slave devices 30B to 30E to the backup data transmission request. If the update master processing unit 21 receives backup data from any of the slave devices 30B to 30E via the in-vehicle communication unit 25 (step ST273 “YES”), the process proceeds to step ST274, and if not received (step ST273) “NO”), repeat step ST273.
  • step ST 274 the update master processing unit 21 stores the received backup data in the RAM 103 of the master device 20.
  • step ST275 when the update master processing unit 21 receives the backup data from all of the slave devices 30B to 30E that have transmitted the backup data transmission request (step ST275 "YES"), the process proceeds to step ST276. If the reception has not been completed ("NO" at step ST275), the process returns to step ST273.
  • step ST276 the new image generation unit 22 generates a new software image using the old software image integrated with the backup data and the update data. Thereafter, the update master processing unit 21 proceeds to step ST235 in FIG.
  • the master device 20 includes the update master processing unit 21.
  • the update master processing unit 21 receives an update request from the server device 10 via the wireless communication network 2
  • the update master processing unit 21 is a system that indicates the free capacity of the plurality of free memories 33 possessed by the slave devices 30A to 30F connected to the in-vehicle network 3.
  • Memory map information is transmitted to the server device 10 via the wireless communication network 2.
  • the update master processing unit 21 receives the slave devices 30A to 30F from the server device 10 via the wireless communication network 2 among the new software images for the slave device 30A to be subjected to software update among the slave devices 30A to 30F.
  • the slave device 30A is made to perform software update.
  • software update is performed using the free capacity of the plurality of empty memories 33 possessed by the slave devices 30A to 30F connected to the in-vehicle network 3, the resources required for the software update of the on-vehicle electronic device Can be secured.
  • the master device 20 controls software update of the slave devices 30A to 30F, each of the slave devices 30A to 30F does not have to have a function of controlling software update.
  • the update master processing unit 21 adds the old software image of the slave device 30A to be subjected to software update to the free capacity of the plurality of empty memories 33 possessed by the slave devices 30A to 30F as backup data.
  • the update master processing unit 21 adds the old software image of the slave device 30A to be subjected to software update to the free capacity of the plurality of empty memories 33 possessed by the slave devices 30A to 30F as backup data.
  • master device 20 when the update data is difference data between the old software image and the new software image of slave device 30A to be subjected to software update, master device 20 receives the update data received from server device 10 and the update data.
  • a new image generation unit 22 is provided which generates a new software image using backup data stored in the free space of the plurality of empty memories 33 possessed by the slave devices 30A to 30F. Since the update data to be transmitted from the server device 10 to the master device 20 is not the new software image but only the difference data, the amount of communication can be reduced. Further, since at least the master device 20 only needs to include the new image generation unit 22, there is no need for each of the slave devices 30A to 30F to have a function of generating a new software image.
  • the master device 20 in the first embodiment is not a software update target, it may be a software update target.
  • the master device 20 includes the software update unit 32 that performs software update using the update data when it is an on-vehicle electronic device that is a software update target.
  • the master device 20 can not only cause the slave devices 30A to 30F to perform the software update, but also can perform its own software update. Further, when software update of its own is performed, resources necessary for software update can be secured by using the slave devices 30A to 30F.
  • the server device 10 includes the update server processing unit 13 and the update data generation unit 12.
  • the update server processing unit 13 transmits an update request to the master device 20 via the wireless communication network 2, and the master device 20 makes available plural empty memories 33 of the slave devices 30A to 30F connected to the in-vehicle network 3.
  • Receive system memory map information indicating capacity.
  • the update data generation unit 12 uses the system memory map information to set, among the new software images for update to the slave device 30A targeted for software update among the slave devices 30A to 30F, a plurality of the slave devices 30A to 30F have.
  • the slave device 30A In the slave device 30A to be subjected to software update by receiving update data for new and old software images having a smaller capacity than the free space of the empty memory 33 and transmitting the update data to the master device 20 via the wireless communication network 2. Make software update. As described above, since software update is performed using the free capacity of the plurality of empty memories 33 possessed by the slave devices 30A to 30F connected to the in-vehicle network 3, the resources required for the software update of the on-vehicle electronic device Can be secured.
  • the update data generation unit 12 generates update data from the difference data between the old software image and the new software image of the slave device 30A to be subjected to software update. Since the update data to be transmitted from the server device 10 to the master device 20 is not the new software image but only the difference data, the amount of communication can be reduced.
  • the update data generation unit 12 generates difference data according to the free capacity of the plurality of empty memories 33 possessed by the slave devices 30A to 30F and the processing capability of the slave device 30A to be subjected to software update. To generate updated data. This enables efficient use of resources at the time of software update.
  • master device 20 in the first embodiment When generating a system memory map, master device 20 in the first embodiment does not treat empty memory 23 owned by itself as a vacant capacity, but registers the vacant memory 23 owned by itself in the system memory map as vacant capacity. May be used as a resource for software update.
  • FIG. 17 is a block diagram showing a modification of the software updating system 1 according to the first embodiment.
  • the server device 10 and the wireless communication network 2 are not shown.
  • a head unit 200, gateways 201 to 204, and ECUs 205 to 222 are mounted on the vehicle.
  • the head unit 200, the gateways 201 to 204, and the ECUs 205 to 222 are on-vehicle electronic devices.
  • the head unit 200 and the gateways 201 to 204 have the functions of the master device 20.
  • the ECUs 205 to 222 have the functions of the slave device 30.
  • any one of the head unit 200 or the gateways 201 to 204 functions as the master device 20, and controls software update processing of the ECUs 205 to 222.
  • the head unit 200 and the gateways 201 to 204 may have the function of the slave device 30 in addition to the function of the master device 20.
  • any one of the head unit 200 or the gateways 201 to 204 functions as the master device 20, and controls the software update processing of the other head units 200 or the gateways 201 to 204 or the ECUs 205 to 222.
  • the on-vehicle electronic device can perform software update even if resources necessary for software update can not be prepared by a single device, it is used for electronic devices of automobiles operating with limited resources. Suitable for
  • SYMBOLS 1 software update system 2 wireless communication network, 3 in-vehicle network, 10 server device, 11 image database, 12 update data generation unit, 13 update server processing unit, 14 wireless communication unit, 15 PC, 20 master device (vehicle electronic device) , 21 update master processing unit, 22 new image generation unit, 23 empty memory (storage unit), 24 wireless communication unit, 25 in-vehicle communication unit, 30, 30A to 30F slave devices (vehicle electronic devices), 31 update slave processing unit, 32 software update unit, 33 empty memory (storage unit), 34 in-car communication unit, 100 bus, 101 CPU, 102 ROM, 102a boot program, 102b application program, 102c empty memory (storage unit), 103 RAM, 200 head Units, 201-204 gateway, 205 ⁇ 222 ECU.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Mechanical Engineering (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

マスタ機器（２０）は、サーバ装置（１０）からソフトウェア更新要求を受信した場合、車内ネットワーク（３）に接続されたスレーブ機器（３０Ａ～３０Ｆ）が有する複数の空メモリ（３３）の空き容量を示すメモリマップ情報をサーバ装置（１０）へ送信する。マスタ機器（２０）は、サーバ装置（１０）から、ソフトウェア更新対象のスレーブ機器（３０Ａ）に対する更新用ソフトウェアのうち、スレーブ機器（３０Ａ～３０Ｆ）が有する複数の空メモリ（３３）の空き容量より小さい容量を更新対象とした更新データを受信した場合、これらの空メモリ（３３）を使用してスレーブ機器（３０Ａ）にソフトウェア更新を行わせる。

Description

車載電子機器、サーバ装置、およびソフトウェア更新方法
　この発明は、サーバ装置と連携して車載電子機器のソフトウェアを更新するための車載電子機器、サーバ装置、およびソフトウェア更新方法に関するものである。
　自動車の電子化にともないソフトウェア依存度が高まり、また自動車の公衆ネットワーク接続により、車載電子機器はＣＥ（Ｃｏｎｓｕｍｅｒ　Ｅｌｅｃｔｒｏｎｉｃｓ）機器と同様にセキュリティの脅威にさらされるようになった。車載電子機器のセキュリティ対応およびその他の利便性のため、ＯＴＡ（Ｏｎ　Ｔｈｅ　Ａｉｒ）によるソフトウェア更新が広まっている。ただし、車載電子機器のＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）は、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）およびＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）等の限られたリソースで動作しているため、ソフトウェア更新に必要となるリソースを低減する必要がある。
　特許文献１に係る電子制御装置は、２つの記憶領域を有し、通常時はそれぞれの記憶領域に同一プログラムをミラーリングして記憶している。プログラム更新時、電子制御装置は、一方の記憶領域を圧縮して情報格納領域を確保し、この情報格納領域にプログラムの更新用データを一時的に格納する。
特開２０１４－１９１５７４号公報
　特許文献１に係る電子制御装置は以上のように構成されているので、情報格納領域のサイズより更新用データのサイズが大きい場合、ソフトウェア更新に必要となるリソースを確保できないという課題があった。
　この発明は、上記のような課題を解決するためになされたもので、車載電子機器のソフトウェア更新に必要となるリソースを確保することを目的とする。
　この発明に係る車載電子機器は、車内ネットワークに接続された複数の車載電子機器のうちの１つの車載電子機器であって、無線通信ネットワークを介して車外のサーバ装置からソフトウェア更新要求を受信した場合、車内ネットワークに接続された複数の車載電子機器が有する複数の記憶部の空き容量を示すメモリマップ情報を、無線通信ネットワークを介してサーバ装置へ送信し、無線通信ネットワークを介してサーバ装置から、複数の車載電子機器のうちのソフトウェア更新対象となる車載電子機器に対する更新用ソフトウェアのうち、複数の車載電子機器が有する複数の記憶部の空き容量より小さい容量を更新対象とした更新データを受信し、複数の車載電子機器が有する複数の記憶部の空き容量を使用してソフトウェア更新対象となる車載電子機器にソフトウェア更新を行わせる更新マスタ処理部を備えるものである。
　この発明によれば、車内ネットワークに接続された複数の車載電子機器が有する複数の記憶部の空き容量を使用してソフトウェア更新を行うようにしたので、車載電子機器のソフトウェア更新に必要となるリソースを確保することができる。
実施の形態１に係るソフトウェア更新システムの構成例を示すブロック図である。 実施の形態１に係るサーバ装置の構成例を示すブロック図である。 実施の形態１に係る車載電子機器であるマスタ機器の構成例を示すブロック図である。 実施の形態１に係る車載電子機器であるスレーブ機器の構成例を示すブロック図である。 実施の形態１に係るサーバ装置および車載電子機器に共通するハードウェア構成例を示すブロック図である。 実施の形態１においてＲＯＭに記憶されているプログラムの概要を示す図である。 実施の形態１における旧ソフトウェアイメージ、新ソフトウェアイメージ、および更新データの関係を示す図である。 実施の形態１に係るソフトウェア更新システムのソフトウェア更新方法の概要を示すフローチャートである。 実施の形態１に係るサーバ装置の動作例を示すフローチャートである。 実施の形態１に係るマスタ機器の動作例を示すフローチャートである。 図８のステップＳＴ２１０における動作の詳細を示すフローチャートである。 実施の形態１に係るスレーブ機器の動作例を示すフローチャートである。 実施の形態１におけるシステムメモリマップの一例を示す図である。 図８のステップＳＴ２２０における動作の詳細を示すフローチャートである。 図８のステップＳＴ２３０における動作の詳細を示すフローチャートである。 図１３のステップＳＴ２３３における動作の詳細を示すフローチャートである。 実施の形態１に係るスレーブ機器の異常時の動作例を示すフローチャートである。 図８のステップＳＴ２７０における動作の詳細を示すフローチャートである。 実施の形態１に係るソフトウェア更新システムの変形例を示すブロック図である。
　以下、この発明をより詳細に説明するために、この発明を実施するための形態について、添付の図面に従って説明する。
実施の形態１．
　図１は、実施の形態１に係るソフトウェア更新システム１の構成例を示すブロック図である。ソフトウェア更新システム１は、サーバ装置１０と、車載電子機器であるマスタ機器２０およびスレーブ機器３０Ａ～３０Ｆとを含む。１台の車両には、マスタ機器２０およびスレーブ機器３０Ａ～３０Ｆが搭載されている。マスタ機器２０は、無線通信ネットワーク２を介して、車外のサーバ装置１０と通信可能である。無線通信ネットワーク２は、例えば、ＷＷＡＮ（Ｗｉｒｅｌｅｓｓ　Ｗｉｄｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、ＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）、または３Ｇである。また、マスタ機器２０およびスレーブ機器３０Ａ～３０Ｆは、車内ネットワーク３を介して接続されている。車内ネットワーク３は、例えばＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、ＭＯＳＴ（Ｍｅｄｉａ　Ｏｒｉｅｎｔｅｄ　Ｓｙｓｔｅｍ　Ｔｒａｎｓｐｏｒｔ）、またはＥｔｈｅｒｎｅｔ（登録商標）である。
　実施の形態１では、サーバ装置１０と通信可能な車載電子機器はマスタ機器２０のみであるものとし、ソフトウェア更新対象となる車載電子機器はスレーブ機器３０Ａ～３０Ｆのいずれかであるものとする。また、実施の形態１におけるソフトウェアイメージとは、各スレーブ機器に書き込まれたソフトウェアの一部または全部のイメージを言う。ソフトウェアの一部と全部とに区別が必要な場合はその旨記載する。
　図２Ａは、実施の形態１に係るサーバ装置１０の構成例を示すブロック図である。サーバ装置１０は、イメージデータベース１１、更新データ生成部１２、更新サーバ処理部１３、無線通信部１４、およびＰＣ（Ｐｅｒｓｏｎａｌ　Ｃｏｍｐｕｔｅｒ）１５を備える。イメージデータベース１１は、スレーブ機器３０Ａ～３０Ｆのそれぞれの旧ソフトウェアイメージの全部および新ソフトウェアイメージの全部を記憶する。旧ソフトウェアイメージは更新前のソフトウェアであり、新ソフトウェアイメージは更新用ソフトウェアである。更新データ生成部１２は、スレーブ機器３０Ａ～３０Ｆのうちのソフトウェア更新対象のスレーブ機器の新旧ソフトウェアイメージをイメージデータベース１１から読み出して、新旧ソフトウェアイメージの差分を抽出し差分データを生成する。差分データは、スレーブ機器３０Ａ～３０Ｆのうちのいずれかのソフトウェアを更新するための更新データである。更新サーバ処理部１３は、無線通信部１４を介してマスタ機器２０と通信して、ソフトウェア更新対象のスレーブ機器のソフトウェア更新処理を実施させる。無線通信部１４は、無線通信ネットワーク２を介してマスタ機器２０と通信する。ＰＣ１５は、イメージデータベース１１に新ソフトウェアイメージの全部を記憶させる。また、ＰＣ１５は、サーバ装置１０を管理する。
　図２Ｂは、実施の形態１に係る車載電子機器であるマスタ機器２０の構成例を示すブロック図である。マスタ機器２０は、例えばヘッドユニットまたはゲートウェイである。このマスタ機器２０は、スレーブ機器３０Ａ～３０Ｆのソフトウェア更新処理を制御する。
　マスタ機器２０は、更新マスタ処理部２１、新イメージ生成部２２、空メモリ２３、無線通信部２４、および車内通信部２５を備える。更新マスタ処理部２１は、無線通信部２４が受信したサーバ装置１０からの要求に応じて、無線通信部２４を介してサーバ装置１０に応答するとともに車内通信部２５を介してスレーブ機器３０Ａ～３０Ｆへ指示することにより、スレーブ機器３０Ａ～３０Ｆのソフトウェア更新処理を行う。また、更新マスタ処理部２１は、スレーブ機器３０Ａ～３０Ｆが有する空きメモリの容量を示すシステムメモリマップを生成する。システムメモリマップを示す情報は「メモリマップ情報」に相当する。新イメージ生成部２２は、ソフトウェア更新対象のスレーブ機器の旧ソフトウェアイメージとサーバ装置１０が送信した更新データとを用いて新ソフトウェアイメージを生成する。空メモリ２３は、ソフトウェア更新時にシステムメモリマップ情報等を記憶するための不揮発性メモリである。この不揮発性メモリは、現在は使用されていないため空メモリ２３と称され、後述するＲＯＭ１０２の空メモリ１０２ｃである。無線通信部２４は、無線通信ネットワーク２を介してサーバ装置１０と通信する。車内通信部２５は、車内ネットワーク３を介してスレーブ機器３０Ａ～３０Ｆと通信する。
　図２Ｃは、実施の形態１に係る車載電子機器であるスレーブ機器３０の構成例を示すブロック図である。スレーブ機器３０は、例えばエンジンを制御するＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）、またはエアコンを制御するＥＣＵ等である。このスレーブ機器３０は、マスタ機器２０の制御下で自身のソフトウェアを更新する。
　スレーブ機器３０は、更新スレーブ処理部３１、ソフトウェア更新部３２、空メモリ３３、および車内通信部３４を備える。更新スレーブ処理部３１は、車内通信部３４が受信したマスタ機器２０からの要求に応じて、車内通信部３４を介してマスタ機器２０に応答する。ソフトウェア更新部３２は、自身がソフトウェア更新対象のスレーブ機器である場合に、自身の旧ソフトウェアイメージを消去して新ソフトウェアイメージを書き込むことによってソフトウェア更新処理を行う。空メモリ３３は、ソフトウェア更新時にバックアップデータ等を一時的に記憶するための不揮発性メモリである。この不揮発性メモリは、現在は使用されていないため空メモリ３３と称され、後述するＲＯＭ１０２の空メモリ１０２ｃである。車内通信部３４は、車内ネットワーク３を介してマスタ機器２０と通信する。
　なお、図１に示されるスレーブ機器３０Ａ～３０Ｆのそれぞれは、図２Ｃに示されるスレーブ機器３０と同様に更新スレーブ処理部３１、ソフトウェア更新部３２、空メモリ３３、および車内通信部３４を備える。以下では、スレーブ機器３０Ａ～３０Ｆを区別する必要がない場合、スレーブ機器３０と称する。
　図３は、実施の形態１に係るサーバ装置１０ならびに車載電子機器であるマスタ機器２０およびスレーブ機器３０に共通するハードウェア構成例を示すブロック図である。
　サーバ装置１０は、バス１００に接続されたＣＰＵ１０１、ＲＯＭ１０２、およびＲＡＭ１０３を備える。サーバ装置１０における更新データ生成部１２および更新サーバ処理部１３の各機能は、ソフトウェアにより実現される。ソフトウェアはプログラムとして記述され、ＲＯＭ１０２に記憶される。ＣＰＵ１０１は、ＲＯＭ１０２に記憶されたプログラムをＲＡＭ１０３に読み出して実行することにより、各部の機能を実現する。即ち、サーバ装置１０は、ＣＰＵ１０１により実行されるときに、後述するフローチャートで示されるステップが結果的に実行されることになるプログラムを格納するためのＲＯＭ１０２を備える。また、このプログラムは、更新データ生成部１２および更新サーバ処理部１３の手順または方法をコンピュータ等に実行させるものであるとも言える。
　なお、サーバ装置１０におけるイメージデータベース１１は、例えばＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）である。
　マスタ機器２０は、バス１００に接続されたＣＰＵ１０１、ＲＯＭ１０２、およびＲＡＭ１０３を備える。マスタ機器２０における更新マスタ処理部２１および新イメージ生成部２２の各機能は、ソフトウェアにより実現される。ソフトウェアはプログラムとして記述され、ＲＯＭ１０２に記憶される。ＣＰＵ１０１は、ＲＯＭ１０２に記憶されたプログラムをＲＡＭ１０３に読み出して実行することにより、各部の機能を実現する。即ち、マスタ機器２０は、ＣＰＵ１０１により実行されるときに、後述するフローチャートで示されるステップが結果的に実行されることになるプログラムを格納するためのＲＯＭ１０２を備える。また、このプログラムは、更新マスタ処理部２１および新イメージ生成部２２の手順または方法をコンピュータ等に実行させるものであるとも言える。
　スレーブ機器３０は、バス１００に接続されたＣＰＵ１０１、ＲＯＭ１０２、およびＲＡＭ１０３を備える。スレーブ機器３０における更新スレーブ処理部３１およびソフトウェア更新部３２の各機能は、ソフトウェアにより実現される。ソフトウェアはプログラムとして記述され、ＲＯＭ１０２に記憶される。ＣＰＵ１０１は、ＲＯＭ１０２に記憶されたプログラムをＲＡＭ１０３に読み出して実行することにより、各部の機能を実現する。即ち、スレーブ機器３０は、ＣＰＵ１０１により実行されるときに、後述するフローチャートで示されるステップが結果的に実行されることになるプログラムを格納するためのＲＯＭ１０２を備える。また、このプログラムは、更新スレーブ処理部３１およびソフトウェア更新部３２の手順または方法をコンピュータ等に実行させるものであるとも言える。
　図４は、実施の形態１においてＲＯＭ１０２に記憶されているプログラムの概要を示す図である。マスタ機器２０およびスレーブ機器３０のＲＯＭ１０２は、ブートプログラム１０２ａ、アプリケーションプログラム１０２ｂ、および空メモリ１０２ｃを含む。ブートプログラム１０２ａは、電源投入直後に読み出されてＲＡＭ１０３に展開される。アプリケーションプログラム１０２ｂは、ブートプログラム１０２ａがＣＰＵ１０１の検査を終了した後、読み出されてＲＡＭ１０３に展開される。主に、ブートプログラム１０２ａおよびアプリケーションプログラム１０２ｂがソフトウェア更新対象となる。空メモリ１０２ｃは、空メモリ２３または空メモリ３３であり、記憶部である。
　図５は、実施の形態１における旧ソフトウェアイメージ、新ソフトウェアイメージ、および更新データの関係を示す図である。サーバ装置１０の更新データ生成部１２は、マスタ機器２０から受信したシステムメモリマップ情報を用いて、スレーブ機器３０Ａ～３０Ｆの合計空メモリ容量に合わせた容量で更新処理が可能な更新データを生成する。例えば、イメージデータベース１１に記憶されている新旧ソフトウェアイメージのうち更新対象となる更新対象ソフトウェアイメージの容量が１００ＫＢｙｔｅであり、システムメモリマップ情報が示すスレーブ機器３０Ａ～３０Ｆの合計空メモリ容量が３０ＫＢｙｔｅである場合、更新データ生成部１２は、３０ＫＢｙｔｅより小さい容量の一部更新対象ソフトウェアイメージを対象とした更新データを生成する。更新データ生成部１２は、一部更新対象ソフトウェアイメージ１つあたりの容量に余裕を持たせて２０ＫＢｙｔｅに設定した場合、１００ＫＢｙｔｅの更新対象ソフトウェアイメージを２０ＫＢｙｔｅ毎に分割して５つの一部更新対象ソフトウェアイメージにし、分割した５つの一部更新対象ソフトウェアイメージのそれぞれを比較処理して差分データを５つ生成し、５つの更新データとすることになる。もし、更新対象ソフトウェアイメージの容量が３０ＫＢｙｔｅより小さければ分割は不要であり、更新データ生成部１２は１つの差分データをそのまま１つの更新データとする。
　更新データ生成部１２は、スレーブ機器３０Ａ～３０Ｆが有するＣＰＵ１０１のＲＯＭ構成に応じて、更新データの生成対象となる新旧ソフトウェアイメージ１つあたりの容量を設定してもよい。例えば、ＣＰＵ１０１は、ブロックメモリ単位でＲＯＭ１０２に記憶されているデータを更新するため、更新データ生成部１２は、比較する新旧ソフトウェアイメージの容量をブロックメモリのＮ倍（Ｎは自然数）として更新データを生成するのが好ましい。即ち、更新データを用いて書き換えを行う新ソフトウェアイメージがブロックメモリのＮ倍になることが好ましい。
　図６は、実施の形態１に係るソフトウェア更新システム１のソフトウェア更新方法の概要を示すフローチャートである。ここでは、ソフトウェア更新対象のスレーブ機器３０がスレーブ機器３０Ａであるものと仮定する。
　ステップＳＴ１において、サーバ装置１０は、無線通信ネットワーク２を介して車載電子機器であるマスタ機器２０へ更新要求を送信する。
　ステップＳＴ２において、マスタ機器２０は、無線通信ネットワーク２を介してサーバ装置１０から更新要求を受信し、車内ネットワーク３に接続された複数のスレーブ機器３０Ａ～３０Ｆが有する複数の空メモリ３３の空き容量を示すシステムメモリマップ情報を、無線通信ネットワーク２を介してサーバ装置１０へ送信する。
　ステップＳＴ３において、サーバ装置１０は、無線通信ネットワーク２を介してマスタ機器２０からシステムメモリマップ情報を受信し、システムメモリマップ情報を用いて、スレーブ機器３０Ａ～３０Ｆのうちのソフトウェア更新対象となるスレーブ機器３０Ａに対する更新用ソフトウェアのうち、複数のスレーブ機器３０Ａ～３０Ｆが有する複数の空メモリ３３の空き容量より小さい新旧ソフトウェアイメージを対象とした更新データを生成し、無線通信ネットワーク２を介してマスタ機器２０へ更新データを送信する。
　ステップＳＴ４において、マスタ機器２０は、無線通信ネットワーク２を介してサーバ装置１０から更新データを受信し、複数のスレーブ機器３０Ａ～３０Ｆが有する複数の空メモリ３３の空き容量を使用してソフトウェア更新対象となるスレーブ機器３０Ａにソフトウェア更新を行わせる。
　これにより、ソフトウェア更新に必要なリソースをマスタ機器２０またはスレーブ機器３０Ａが準備できなくとも、スレーブ機器３０Ａに接続されている他のスレーブ機器３０Ｂ～３０Ｆのリソースを使用してソフトウェア更新を行うことができる。
　次に、ソフトウェア更新システム１におけるソフトウェア更新方法を詳細に説明する。
　図７は、実施の形態１に係るサーバ装置１０の動作例を示すフローチャートである。サーバ装置１０は、図７のフローチャートに示される動作を定期的に繰り返す。
　ステップＳＴ１００において、更新サーバ処理部１３は、イベントの発生有無およびイベントの種類を判定する。更新サーバ処理部１３は、イベントが発生していない場合（ステップＳＴ１００“ＮＯ”）、ステップＳＴ１００を繰り返し、イベントが発生した場合（ステップＳＴ１００“ＹＥＳ”）、以下のようにイベントの種類を判別する。
　オペレータがＰＣ１５を操作して更新サーバ処理部１３に対してソフトウェア更新対象のスレーブ機器３０を指定するとともにイメージデータベース１１に新ソフトウェアイメージの全部を記憶させた場合、更新サーバ処理部１３は、「更新イベント」有りと判定し、ステップＳＴ１１０へ進む。
　ステップＳＴ１１０において、更新サーバ処理部１３は、無線通信部１４を介してマスタ機器２０へ、更新要求を送信する。
　マスタ機器２０がサーバ装置１０へシステムメモリマップ情報を送信した場合、更新サーバ処理部１３は、無線通信部１４を介してシステムメモリマップ情報を受信し、ステップＳＴ１００において「システムメモリマップ通知」有りと判定し、ステップＳＴ１２０へ進む。ステップＳＴ１２０およびステップＳＴ１３０における動作は後述する。
　マスタ機器２０がサーバ装置１０へソフトウェア更新処理の部分完了応答を送信した場合、更新サーバ処理部１３は、無線通信部１４を介して部分完了応答を受信し、ステップＳＴ１００において「部分完了応答」有りと判定し、ステップＳＴ１４０へ進む。ステップＳＴ１４０における動作は後述する。
　マスタ機器２０がサーバ装置１０へソフトウェア更新処理の全完了応答を送信した場合、更新サーバ処理部１３は、無線通信部１４を介して全完了応答を受信し、ステップＳＴ１００において「全完了応答」有りと判定し、ステップＳＴ１５０へ進む。ステップＳＴ１５０における動作は後述する。
　図８は、実施の形態１に係るマスタ機器２０の動作例を示すフローチャートである。マスタ機器２０は、図８のフローチャートに示される動作を定期的に繰り返す。
　ステップＳＴ２００において、更新マスタ処理部２１は、イベントの発生有無およびイベントの種類を判定する。更新マスタ処理部２１は、イベントが発生していない場合（ステップＳＴ２００“ＮＯ”）、ステップＳＴ２００を繰り返し、イベントが発生した場合（ステップＳＴ２００“ＹＥＳ”）、イベントの種類を判別する。
　サーバ装置１０がマスタ機器２０へ更新要求を送信した場合、更新マスタ処理部２１は、無線通信部２４を介して更新要求を受信し、「更新要求」有りと判定し、ステップＳＴ２１０へ進む。
　ステップＳＴ２１０において、更新マスタ処理部２１は、スレーブ機器３０Ａ～３０Ｆの空メモリ３３を調査する。ステップＳＴ２１０における動作の詳細は図９に示す。
　ソフトウェア更新対象のスレーブ機器３０がマスタ機器２０へＲＯＭ異常通知を送信した場合、更新マスタ処理部２１は、車内通信部２５を介してＲＯＭ異常通知を受信し、「ＲＯＭ異常通知」有りと判定し、ステップＳＴ２７０へ進む。ステップＳＴ２７０における動作は後述する
　図９は、図８のステップＳＴ２１０における動作の詳細を示すフローチャートである。
　ステップＳＴ２１１において、更新マスタ処理部２１は、車内通信部２５を介して、車内ネットワーク３に接続されたスレーブ機器３０Ａ～３０Ｆに対して空メモリ情報要求をブロードキャストする。
　図１０は、実施の形態１に係るスレーブ機器３０の動作例を示すフローチャートである。スレーブ機器３０は、図１０のフローチャートに示される動作を定期的に繰り返す。
　ステップＳＴ３１０において、更新スレーブ処理部３１は、イベントの発生有無およびイベントの種類を判定する。更新スレーブ処理部３１は、イベントが発生していない場合（ステップＳＴ３１０“ＮＯ”）、ステップＳＴ３００を繰り返し、イベントが発生した場合（ステップＳＴ３１０“ＹＥＳ”）、イベントの種類を判別する。
　マスタ機器２０がスレーブ機器３０へ空メモリ情報要求を送信した場合、更新スレーブ処理部３１は、車内通信部３４を介して空メモリ情報要求を受信し、「空メモリ情報要求」有りと判定し、ステップＳＴ３２０へ進む。
　ステップＳＴ３２０において、更新スレーブ処理部３１は、自身の空メモリ３３の容量および空メモリ３３のアドレス位置等を調査し、車内通信部３４を介してマスタ機器２０へ空メモリ情報を送信する。
　図９のステップＳＴ２１２において、更新マスタ処理部２１は、空メモリ情報要求に対するスレーブ機器３０Ａ～３０Ｆの応答を待つ。更新マスタ処理部２１は、車内通信部２５を介して、スレーブ機器３０Ａ～３０Ｆのいずれかから空メモリ情報要求に対する応答である空メモリ情報を受信した場合（ステップＳＴ２１２“ＹＥＳ”）、ステップＳＴ２１３へ進み、受信していない場合（ステップＳＴ２１２“ＮＯ”）、ステップＳＴ２１２を繰り返す。
　ステップＳＴ２１３において、更新マスタ処理部２１は、スレーブ機器３０Ａ～３０Ｆのいずれかから受信した空メモリ情報を記憶する。
　ステップＳＴ２１４において、更新マスタ処理部２１は、スレーブ機器３０Ａ～３０Ｆのすべてから空メモリ情報を受信し終えた場合（ステップＳＴ２１４“ＹＥＳ”）、ステップＳＴ２１５へ進み、受信し終えていない場合（ステップＳＴ２１４“ＮＯ”）、ステップＳＴ２１２へ戻る。なお、更新マスタ処理部２１は、ステップＳＴ２１１で空メモリ情報要求をしてから一定時間（例えば、１０秒）を経過してもスレーブ機器３０Ａ～３０Ｆから応答がない場合、タイムアウト処理としてステップＳＴＳＴ２１４で全応答ありと判断し（ステップＳＴ２１４“ＹＥＳ”）、ステップＳＴ２１５へ進んでもよい。
　ステップＳＴ２１５において、更新マスタ処理部２１は、スレーブ機器３０Ａ～３０Ｆのすべてから受信した空メモリ情報を用いてシステムメモリマップを生成し、マスタ機器２０のＲＯＭ１０２に記憶する。
　その後、更新マスタ処理部２１は、図８のステップＳＴ２２０へ進む。
　図１１は、実施の形態１におけるシステムメモリマップの一例を示す図である。更新マスタ処理部２１は、例えば、スレーブ機器３０Ａから受信した空メモリ情報を用いて、スレーブ機器ＩＤ「Ａ」の「空メモリ容量」の欄に「５ＫＢｙｔｅ」と登録する。図１１の例では、スレーブ機器３０Ａ～３０Ｆ全体の空メモリ容量の合計は「３０ＫＢｙｔｅ」である。
　図８のステップＳＴ２２０において、更新マスタ処理部２１は、サーバ装置１０との間で情報を交換する。ステップＳＴ２２０における動作の詳細は図１２に示す。
　図１２は、図８のステップＳＴ２２０における動作の詳細を示すフローチャートである。
　ステップＳＴ２２１において、更新マスタ処理部２１は、無線通信部２４を介してサーバ装置１０へシステムメモリマップ情報を送信する。
　図７のステップＳＴ１２０において、更新データ生成部１２は、マスタ機器２０から受信したシステムメモリマップ情報を用いて、スレーブ機器３０Ａ～３０Ｆの合計空メモリ容量より小さい容量の新旧ソフトウェアイメージを対象として１つ以上の更新データを生成する。ここでは、更新データ生成部１２が、図５に示されるような５つの更新データを生成したものとする。この例では、１つの更新データは、数百Ｂｙｔｅから数ＫＢｙｔｅ程度である。
　ステップＳＴ１３０において、更新サーバ処理部１３は、更新データ生成部１２がステップＳＴ１２０にて生成した５つの更新データのうちの１つを、無線通信部１４を介してマスタ機器２０へ送信する。その際、更新サーバ処理部１３は、全更新データ合計容量である差分データ容量（例えば、数ＫＢｙｔｅ）、更新処理回数（例えば、５回）、更新データの生成対象である新旧ソフトウェアイメージの開始位置を示すアドレスである更新対象アドレス、および更新対象機器名（例えば、スレーブ機器３０Ａ）等を、更新データと合わせて送信する。
　図１２のステップＳＴ２２２において、更新マスタ処理部２１は、システムメモリマップ情報送信に対するサーバ装置１０の応答を待つ。更新マスタ処理部２１は、無線通信部２４を介してサーバ装置１０から更新データ等を受信した場合（ステップＳＴ２２２“ＹＥＳ”）、ステップＳＴ２２３へ進み、受信していない場合（ステップＳＴ２２２“ＮＯ”）、ステップＳＴ２２２を繰り返す。
　ステップＳＴ２２３において、更新マスタ処理部２１は、サーバ装置１０から受信した更新データ等を、マスタ機器２０のＲＡＭ１０３に記憶する。
　その後、更新マスタ処理部２１は、図８のステップＳＴ２３０へ進む。
　図８のステップＳＴ２３０において、更新マスタ処理部２１は、ソフトウェア更新対象のスレーブ機器３０に対するソフトウェア更新処理を実施する。ステップＳＴ２３０における動作の詳細は図１３に示す。
　図１３は、図８のステップＳＴ２３０における動作の詳細を示すフローチャートである。ここでは、ソフトウェア更新対象のスレーブ機器３０を、スレーブ機器３０Ａと仮定する。
　ステップＳＴ２３１において、更新マスタ処理部２１は、車内通信部２５を介してソフトウェア更新対象のスレーブ機器３０Ａへ、旧イメージ送信要求を送信する。旧イメージ送信要求は、スレーブ機器３０Ａの更新対象アドレスのソフトウェアイメージを取得するための要求である。
　マスタ機器２０がスレーブ機器３０Ａへ旧イメージ送信要求を送信した場合、スレーブ機器３０Ａの更新スレーブ処理部３１は、車内通信部３４を介して旧イメージ送信要求を受信する。そして、スレーブ機器３０Ａの更新スレーブ処理部３１は、図１０のステップＳＴ３１０にて「旧イメージ送信要求」有りと判定し、ステップＳＴ３３０へ進む。
　ステップＳＴ３３０において、スレーブ機器３０Ａの更新スレーブ処理部３１は、更新前のソフトウェアイメージにおける旧イメージ送信要求で指定された更新対象アドレスのソフトウェアイメージ、つまり旧ソフトウェアイメージを、車内通信部３４を介してマスタ機器２０へ送信する。
　図１３のステップＳＴ２３２において、更新マスタ処理部２１は、旧イメージ送信要求に対するスレーブ機器３０Ａの応答を待つ。更新マスタ処理部２１は、車内通信部２５を介して、スレーブ機器３０Ａから更新対象アドレスの旧ソフトウェアイメージを受信した場合（ステップＳＴ２３２“ＹＥＳ”）、受信した旧ソフトウェアイメージをマスタ機器２０のＲＡＭ１０３に記憶し、ステップＳＴ２３３へ進む。一方、更新マスタ処理部２１は、旧ソフトウェアイメージを受信していない場合（ステップＳＴ２３２“ＮＯ”）、ステップＳＴ２３２を繰り返す。
　ステップＳＴ２３３において、更新マスタ処理部２１は、ステップＳＴ２３２にて受信した旧ソフトウェアイメージのバックアップ処理を行う。ステップＳＴ２３３における動作の詳細は図１４に示す。
　図１４は、図１３のステップＳＴ２３３における動作の詳細を示すフローチャートである。
　ステップＳＴ２３３－１において、更新マスタ処理部２１は、システムメモリマップを参照し、旧ソフトウェアイメージをどのように分割しどのスレーブ機器３０Ａ～３０Ｆに記憶させるかを算出する。もし、旧ソフトウェアイメージの全部が単独の空メモリ３３に記憶できるのであれば分割は不要である。更新マスタ処理部２１は、例えば、旧ソフトウェアイメージを５ＫＢｙｔｅずつ４つに分割して、スレーブ機器３０Ｂ～３０Ｅにそれぞれ５ＫＢｙｔｅの旧ソフトウェアイメージをバックアップとして記憶させる旨を算出する。そして、更新マスタ処理部２１は、図１１のように、システムメモリマップのスレーブ機器ＩＤ「Ｂ」、「Ｃ」、「Ｄ」および「Ｅ」の「バックアップ有無」の欄に「有」と登録するとともに、「バックアップメモリ位置」の欄に「５ＫＢｙｔｅ」と登録する。「バックアップメモリ位置」は、スレーブ機器３０Ｂ～３０Ｅがマスタ機器２０からの空メモリ情報要求に対して応答した空メモリ３３のアドレス位置である。
　ステップＳＴ２３３－２において、更新マスタ処理部２１は、ステップＳＴ２３３－１で算出した通り、車内通信部２５を介してスレーブ機器３０Ｂへ、分割した旧ソフトウェアイメージとバックアップ要求を送信する。
　ステップＳＴ２３３－３において、更新マスタ処理部２１は、バックアップ対象であるスレーブ機器３０Ｂ～３０Ｅのすべてに対して分割した旧ソフトウェアイメージとバックアップ要求を送信し終えた場合（ステップＳＴ２３３－３“ＹＥＳ”）、図１３のステップＳＴ２３４へ進み、送信し終えていない場合（ステップＳＴ２３３－３“ＮＯ”）、ステップＳＴ２３３－１へ戻る。
　マスタ機器２０がスレーブ機器３０Ｂ～３０Ｅへ分割した旧ソフトウェアイメージとバックアップ要求を送信した場合、スレーブ機器３０Ｂ～３０Ｅの更新スレーブ処理部３１は、車内通信部３４を介して分割した旧ソフトウェアイメージとバックアップ要求を受信する。そして、スレーブ機器３０Ｂ～３０Ｅの更新スレーブ処理部３１は、図１０のステップＳＴ３１０にて「バックアップ要求」有りと判定し、ステップＳＴ３５０へ進む。
　ステップＳＴ３５０において、スレーブ機器３０Ｂ～３０Ｅの更新スレーブ処理部３１は、マスタ機器２０から受信した旧ソフトウェアイメージを、スレーブ機器３０Ｂ～３０Ｅの空メモリ３３におけるアドレス位置にバックアップデータとして記憶する。このアドレス位置は、スレーブ機器３０Ｂ～３０Ｅがマスタ機器２０からの空メモリ情報要求に対して応答した空メモリ３３のアドレス位置である。
　なお、図１３のステップＳＴ２３３のバックアップ処理において、更新マスタ処理部２１は、旧ソフトウェアイメージだけでなく更新データも、スレーブ機器３０の空メモリ３３に記憶させてもよい。更新データをバックアップすることで、後述する図１５および図１６の復旧処理においてマスタ機器２０からサーバ装置１０へ更新データを要求する必要がなくなる。
　図１３のステップＳＴ２３４において、新イメージ生成部２２は、ステップＳＴ２２０にてサーバ装置１０から受信した更新データと、ステップＳＴ２３１にてソフトウェア更新対象のスレーブ機器３０Ａから受信した旧ソフトウェアイメージとを用いて、新ソフトウェアイメージを生成する。新イメージ生成部２２は、生成した新ソフトウェアイメージをマスタ機器２０のＲＡＭ１０３に記憶する。
　ステップＳＴ２３５において、更新マスタ処理部２１は、車内通信部２５を介してソフトウェア更新対象のスレーブ機器３０Ａへ、新イメージ生成部２２が生成した新ソフトウェアイメージとソフトウェア書換え要求を送信する。
　マスタ機器２０がスレーブ機器３０Ａへ新ソフトウェアイメージとソフトウェア書換え要求を送信した場合、スレーブ機器３０Ａの更新スレーブ処理部３１は、車内通信部３４を介して新ソフトウェアイメージとソフトウェア書換え要求を受信する。そして、スレーブ機器３０Ａの更新スレーブ処理部３１は、図１０のステップＳＴ３１０にて「ソフトウェア書換え要求」有りと判定し、ステップＳＴ３７０へ進む。
　ステップＳＴ３７０において、スレーブ機器３０Ａのソフトウェア更新部３２は、スレーブ機器３０ＡのＲＯＭ１０２の更新対象アドレスにおける旧ソフトウェアイメージを消去し、受信した新ソフトウェアイメージを書き込む。
　ステップＳＴ３８０において、スレーブ機器３０Ａの更新スレーブ処理部３１は、ソフトウェア更新部３２のソフトウェア書換え処理が成功した場合（ステップＳＴ３８０“ＹＥＳ”）、ステップＳＴ３９０へ進み、失敗した場合（ステップＳＴ３８０“ＮＯ”）、ステップＳＴ４００へ進む。
　ステップＳＴ３９０において、スレーブ機器３０Ａの更新スレーブ処理部３１は、車内通信部３４を介してマスタ機器２０へ、成功応答を送信する。
　ステップＳＴ４００において、スレーブ機器３０Ａの更新スレーブ処理部３１は、車内通信部３４を介してマスタ機器２０へ、失敗応答を送信する。
　図１３のステップＳＴ２３６において、更新マスタ処理部２１は、ソフトウェア書換え要求に対するスレーブ機器３０Ａの応答を待つ。更新マスタ処理部２１は、車内通信部２５を介してスレーブ機器３０Ａから成功応答を受信した場合（ステップＳＴ２３７“ＹＥＳ”）、ステップＳＴ２３７へ進む。一方、更新マスタ処理部２１は、スレーブ機器３０Ａから失敗応答を受信した場合（ステップＳＴ２３７“ＮＯ”）、ステップＳＴ２３５へ戻り、スレーブ機器３０Ａに対して新ソフトウェアイメージとソフトウェア書換え要求を再送する。新ソフトウェアイメージはマスタ機器２０のＲＡＭ１０３に残っているため、更新マスタ処理部２１は再度のソフトウェア書換え要求が可能である。
　ステップＳＴ２３７において、更新マスタ処理部２１は、車内通信部２５を介して、車内ネットワーク３に接続されたスレーブ機器３０Ａ～３０Ｆに対してバックアップデータ消去要求をブロードキャストする。
　その後、更新マスタ処理部２１は、図８のステップＳＴ２４０へ進む。
　マスタ機器２０がスレーブ機器３０Ａ～３０Ｆへバックアップデータ消去要求をブロードキャストした場合、スレーブ機器３０Ａ～３０Ｆの更新スレーブ処理部３１は、車内通信部３４を介してバックアップデータ消去要求を受信する。バックアップデータをもつスレーブ機器３０Ｂ～３０Ｅの更新スレーブ処理部３１は、図１０のステップＳＴ３１０にて「バックアップデータ消去要求」有りと判定し、ステップＳＴ３６０へ進む。
　ステップＳＴ３６０において、スレーブ機器３０Ｂ～３０Ｅの更新スレーブ処理部３１は、スレーブ機器３０Ｂ～３０Ｅの空メモリ３３に記憶されているバックアップデータを消去する。
　図８のステップＳＴ２４０において、更新マスタ処理部２１は、分割された複数の更新データのうちの１つの更新データを用いたソフトウェア更新処理が終了したので、無線通信部２４を介してサーバ装置１０へ、部分完了応答を送信する。
　ステップＳＴ２５０において、更新マスタ処理部２１は、分割された複数の更新データすべてを用いたソフトウェア更新処理が完了した場合（ステップＳＴ２５０“ＹＥＳ”）、ステップＳＴ２６０へ進み、完了していない場合（ステップＳＴ２５０“ＮＯ”）、ステップＳＴ２２０へ戻る。
　ステップＳＴ２６０において、更新マスタ処理部２１は、無線通信部２４を介してサーバ装置１０へ、全完了応答を送信する。
　マスタ機器２０がサーバ装置１０へソフトウェア更新処理の部分完了応答を送信した場合、更新サーバ処理部１３は、無線通信部１４を介して部分完了応答を受信し、ステップＳＴ１００において「部分完了応答」有りと判定し、ステップＳＴ１４０へ進む。
　ステップＳＴ１４０において、更新サーバ処理部１３は、分割された複数の更新データのうちのどの更新データを用いたソフトウェア更新処理が完了したかを記憶する。これにより、更新サーバ処理部１３は、異常時にソフトウェアイメージのどこまで更新が完了し、現在どの部分を更新中か判断できる。
　その後、更新サーバ処理部１３は、ステップＳＴ１３０へ進み、残りの更新データをマスタ機器２０へ送信する。
　マスタ機器２０がサーバ装置１０へソフトウェア更新処理の全完了応答を送信した場合、更新サーバ処理部１３は、無線通信部１４を介して全完了応答を受信し、ステップＳＴ１００において「全完了応答」有りと判定し、ステップＳＴ１５０へ進む。
　ステップＳＴ１５０において、更新サーバ処理部１３は、分割された複数の更新データすべてを用いたソフトウェア更新処理が完了したことを記憶する。
　次に、図８のステップＳＴ２７０における復旧処理を説明する。
　図１０のステップＳＴ３７０におけるソフトウェア書換え処理中、特に、旧ソフトウェアイメージを消去してから新ソフトウェアイメージの書換えが完了するまでに、マスタ機器２０またはスレーブ機器３０Ａ等の電源が落ちた場合、ソフトウェア更新対象のスレーブ機器３０Ａは、ソフトウェアイメージが欠損した状態となる。また、マスタ機器２０は、新ソフトウェアイメージをマスタ機器２０のＲＡＭ１０３に記憶しているだけなので、マスタ機器２０の電源が落ちるとＲＡＭ１０３の新ソフトウェアイメージが消える。
　上述のようにステップＳＴ３７０におけるソフトウェア書換え処理中に電源が落ちた後、マスタ機器２０またはスレーブ機器３０Ａ等は起動を開始する。このとき、ソフトウェア更新対象のスレーブ機器３０Ａは、図１５のフローチャートに示される動作を行う。
　図１５は、実施の形態１に係るスレーブ機器３０Ａの異常時の動作例を示すフローチャートである。
　ステップＳＴ４１１において、ソフトウェア更新対象のスレーブ機器３０Ａにおける更新スレーブ処理部３１は、ＲＯＭ１０２におけるアプリケーションプログラム１０２ｂのソフトウェアイメージが欠損しているか否かを判定する。上述のようにステップＳＴ３７０におけるソフトウェア書換え処理中に電源が落ちた場合ソフトウェアイメージが欠損しているため、スレーブ機器３０Ａの更新スレーブ処理部３１は欠損ありと判定し（ステップＳＴ４１１“ＹＥＳ”）、ステップＳＴ４１２へ進む。一方、スレーブ機器３０Ａの更新スレーブ処理部３１は、ソフトウェアイメージが欠損していない場合（ステップＳＴ４１１“ＮＯ”）、図１５のフローチャートに示される動作を終了する。
　ステップＳＴ４１２において、スレーブ機器３０Ａの更新スレーブ処理部３１は、車内通信部３４を介してマスタ機器２０へ、ＲＯＭ異常通知を送信する。
　スレーブ機器３０Ａがマスタ機器２０へＲＯＭ異常通知を送信した場合、マスタ機器２０の更新マスタ処理部２１は、車内通信部２５を介してＲＯＭ異常通知を受信する。更新マスタ処理部２１は、図８のステップＳＴ２００にて「ＲＯＭ異常通知」有りと判定し、ステップＳＴ２７０へ進む。
　ステップＳＴ２７０において、更新マスタ処理部２１は、ソフトウェア更新対象のスレーブ機器３０Ａのソフトウェアイメージの復旧処理を行う。ステップＳＴ２７０における動作の詳細は図１６に示す。
　図１６は、図８のステップＳＴ２７０における動作の詳細を示すフローチャートである。
　ステップＳＴ２７１において、更新マスタ処理部２１は、システムメモリマップを参照し、どこに旧ソフトウェアイメージおよび更新データが記憶されているかを確認する。
　ステップＳＴ２７２において、更新マスタ処理部２１は、車内通信部２５を介して旧ソフトウェアイメージおよび更新データを記憶しているスレーブ機器３０Ｂ～３０Ｅへ、バックアップデータ送信要求を送信する。
　なお、マスタ機器２０またはスレーブ機器３０Ａ～３０Ｆのいずれもが更新データを記憶していない場合、更新マスタ処理部２１は、無線通信部２４を介してサーバ装置１０へ、更新データの再送を要求すればよい。
　マスタ機器２０がスレーブ機器３０Ｂ～３０Ｅへバックアップデータ送信要求を送信した場合、スレーブ機器３０Ｂ～３０Ｅの更新スレーブ処理部３１は、車内通信部３４を介してバックアップデータ送信要求を受信する。そして、スレーブ機器３０Ｂ～３０Ｅの更新スレーブ処理部３１は、図１０のステップＳＴ３１０にて「バックアップデータ送信要求」有りと判定し、ステップＳＴ３４０へ進む。
　ステップＳＴ３４０において、スレーブ機器３０Ｂ～３０Ｅの更新スレーブ処理部３１は、スレーブ機器３０Ｂ～３０Ｅの空メモリ３３に記憶されているバックアップデータ、つまり分割された旧ソフトウェアイメージを、車内通信部３４を介してマスタ機器２０へ送信する。
　ステップＳＴ２７３において、更新マスタ処理部２１は、バックアップデータ送信要求に対するスレーブ機器３０Ｂ～３０Ｅからの応答を待つ。更新マスタ処理部２１は、車内通信部２５を介してスレーブ機器３０Ｂ～３０Ｅのいずれかからバックアップデータを受信した場合（ステップＳＴ２７３“ＹＥＳ”）、ステップＳＴ２７４へ進み、受信していない場合（ステップＳＴ２７３“ＮＯ”）、ステップＳＴ２７３を繰り返す。
　ステップＳＴ２７４において、更新マスタ処理部２１は、受信したバックアップデータをマスタ機器２０のＲＡＭ１０３に記憶する。
　ステップＳＴ２７５において、更新マスタ処理部２１は、バックアップデータ送信要求を送信したスレーブ機器３０Ｂ～３０Ｅのすべてからバックアップデータを受信した場合（ステップＳＴ２７５“ＹＥＳ”）、ステップＳＴ２７６へ進み、すべてのバックアップデータの受信が完了していない場合（ステップＳＴ２７５“ＮＯ”）、ステップＳＴ２７３へ戻る。
　ステップＳＴ２７６において、新イメージ生成部２２は、バックアップデータを統合した旧ソフトウェアイメージと更新データとを用いて、新ソフトウェアイメージを生成する。
　その後、更新マスタ処理部２１は、図１３のステップＳＴ２３５へ進む。
　以上のように、実施の形態１に係るマスタ機器２０は、更新マスタ処理部２１を備える。更新マスタ処理部２１は、無線通信ネットワーク２を介してサーバ装置１０から更新要求を受信した場合、車内ネットワーク３に接続されたスレーブ機器３０Ａ～３０Ｆが有する複数の空メモリ３３の空き容量を示すシステムメモリマップ情報を、無線通信ネットワーク２を介してサーバ装置１０へ送信する。また、更新マスタ処理部２１は、無線通信ネットワーク２を介してサーバ装置１０から、スレーブ機器３０Ａ～３０Ｆのうちのソフトウェア更新対象となるスレーブ機器３０Ａに対する新ソフトウェアイメージのうち、スレーブ機器３０Ａ～３０Ｆが有する複数の空メモリ３３の空き容量より小さい容量の新旧ソフトウェアイメージを対象とした更新データを受信し、スレーブ機器３０Ａ～３０Ｆが有する複数の空メモリ３３の空き容量を使用してソフトウェア更新対象となるスレーブ機器３０Ａにソフトウェア更新を行わせる。このように、車内ネットワーク３に接続されたスレーブ機器３０Ａ～３０Ｆが有する複数の空メモリ３３の空き容量を使用してソフトウェア更新を行うようにしたので、車載電子機器のソフトウェア更新に必要となるリソースを確保することができる。また、マスタ機器２０がスレーブ機器３０Ａ～３０Ｆのソフトウェア更新を制御するため、スレーブ機器３０Ａ～３０Ｆのそれぞれがソフトウェア更新を制御する機能を備える必要はない。
　また、実施の形態１によれば、更新マスタ処理部２１は、ソフトウェア更新対象となるスレーブ機器３０Ａの旧ソフトウェアイメージを、バックアップデータとしてスレーブ機器３０Ａ～３０Ｆが有する複数の空メモリ３３の空き容量に記憶させる。これにより、ソフトウェア更新対象の車載電子機器がもつ旧ソフトウェアイメージのバックアップに必要となるリソースを確保することができる。また、差分データを使用したソフトウェア更新である場合、ソフトウェア更新が失敗し再トライする際に必要となる旧ソフトウェアイメージを残すことができる。
　また、実施の形態１において、更新データが、ソフトウェア更新対象となるスレーブ機器３０Ａの旧ソフトウェアイメージと新ソフトウェアイメージとの差分データである場合、マスタ機器２０は、サーバ装置１０から受信した更新データおよびスレーブ機器３０Ａ～３０Ｆが有する複数の空メモリ３３の空き容量に記憶されているバックアップデータを用いて、新ソフトウェアイメージを生成する新イメージ生成部２２を備える。サーバ装置１０からマスタ機器２０へ送信する更新データを、新ソフトウェアイメージではなく差分データのみにしたので、通信量を削減することができる。また、少なくともマスタ機器２０が新イメージ生成部２２を備えていればよいため、スレーブ機器３０Ａ～３０Ｆのそれぞれが新ソフトウェアイメージを生成する機能を備える必要はない。
　なお、実施の形態１におけるマスタ機器２０は、ソフトウェア更新対象外であったが、ソフトウェア更新対象であってもよい。
　その場合、マスタ機器２０は、自身がソフトウェア更新対象の車載電子機器である場合に更新データを使用してソフトウェア更新を行うソフトウェア更新部３２を備える。これにより、マスタ機器２０は、スレーブ機器３０Ａ～３０Ｆにソフトウェア更新を行わせるだけでなく、自身のソフトウェア更新を行うこともできる。また、自身のソフトウェア更新を行う場合に、スレーブ機器３０Ａ～３０Ｆを利用することによってソフトウェア更新に必要となるリソースを確保することができる。
　実施の形態１に係るサーバ装置１０は、更新サーバ処理部１３および更新データ生成部１２を備える。更新サーバ処理部１３は、無線通信ネットワーク２を介してマスタ機器２０へ更新要求を送信し、マスタ機器２０から、車内ネットワーク３に接続されたスレーブ機器３０Ａ～３０Ｆが有する複数の空メモリ３３の空き容量を示すシステムメモリマップ情報を受信する。更新データ生成部１２は、システムメモリマップ情報を用いて、スレーブ機器３０Ａ～３０Ｆのうちのソフトウェア更新対象となるスレーブ機器３０Ａに対する更新用の新ソフトウェアイメージのうち、スレーブ機器３０Ａ～３０Ｆが有する複数の空メモリ３３の空き容量より小さい容量の新旧ソフトウェアイメージを対象とした更新データを受信し、無線通信ネットワーク２を介してマスタ機器２０へ更新データを送信することによってソフトウェア更新対象となるスレーブ機器３０Ａのソフトウェア更新を行わせる。このように、車内ネットワーク３に接続されたスレーブ機器３０Ａ～３０Ｆが有する複数の空メモリ３３の空き容量を使用してソフトウェア更新を行うようにしたので、車載電子機器のソフトウェア更新に必要となるリソースを確保することができる。
　また、実施の形態１によれば、更新データ生成部１２は、ソフトウェア更新対象となるスレーブ機器３０Ａの旧ソフトウェアイメージと新ソフトウェアイメージとの差分データから更新データを生成する。サーバ装置１０からマスタ機器２０へ送信する更新データを、新ソフトウェアイメージではなく差分データのみにしたので、通信量を削減することができる。
　また、実施の形態１によれば、更新データ生成部１２は、スレーブ機器３０Ａ～３０Ｆが有する複数の空メモリ３３の空き容量およびソフトウェア更新対象となるスレーブ機器３０Ａの処理能力に応じて、差分データを分割して更新データを生成する。これにより、ソフトウェア更新時にリソースを効率的に使用することができる。
　なお、実施の形態１におけるマスタ機器２０は、システムメモリマップを生成する際、自身が有する空メモリ２３を空き容量として扱わなかったが、自身が有する空メモリ２３を空き容量としてシステムメモリマップに登録し、ソフトウェア更新用のリソースとして使用してもよい。
　また、実施の形態１では、サーバ装置１０と通信可能な車載電子機器がマスタ機器２０の１つだけであったが、複数あってもよい。
　図１７は、実施の形態１に係るソフトウェア更新システム１の変形例を示すブロック図である。なお、図１７においてサーバ装置１０および無線通信ネットワーク２の図示を省略する。車両には、ヘッドユニット２００、ゲートウェイ２０１～２０４、およびＥＣＵ２０５～２２２が搭載されている。ヘッドユニット２００、ゲートウェイ２０１～２０４、およびＥＣＵ２０５～２２２は、車載電子機器である。
　図１７において、ヘッドユニット２００およびゲートウェイ２０１～２０４は、マスタ機器２０の機能を備える。ＥＣＵ２０５～２２２は、スレーブ機器３０の機能を備える。この場合、ヘッドユニット２００またはゲートウェイ２０１～２０４のうちのいずれか１つがマスタ機器２０として機能し、ＥＣＵ２０５～２２２のソフトウェア更新処理を制御する。
　または、図１７において、ヘッドユニット２００およびゲートウェイ２０１～２０４は、マスタ機器２０の機能に加えて、スレーブ機器３０の機能を備えてもよい。この場合、ヘッドユニット２００またはゲートウェイ２０１～２０４のうちのいずれか１つがマスタ機器２０として機能し、それ以外のヘッドユニット２００もしくはゲートウェイ２０１～２０４、またはＥＣＵ２０５～２２２のソフトウェア更新処理を制御する。
　なお、本発明はその発明の範囲内において、実施の形態の任意の構成要素の変形、または実施の形態の任意の構成要素の省略が可能である。
　この発明に係る車載電子機器は、ソフトウェア更新に必要なリソースを単一機器で準備できなくともソフトウェア更新を行うことができるので、限られたリソースで動作している自動車の電子機器などに用いるのに適している。
　１　ソフトウェア更新システム、２　無線通信ネットワーク、３　車内ネットワーク、１０　サーバ装置、１１　イメージデータベース、１２　更新データ生成部、１３　更新サーバ処理部、１４　無線通信部、１５　ＰＣ、２０　マスタ機器（車載電子機器）、２１　更新マスタ処理部、２２　新イメージ生成部、２３　空メモリ（記憶部）、２４　無線通信部、２５　車内通信部、３０，３０Ａ～３０Ｆ　スレーブ機器（車載電子機器）、３１　更新スレーブ処理部、３２　ソフトウェア更新部、３３　空メモリ（記憶部）、３４　車内通信部、１００　バス、１０１　ＣＰＵ、１０２　ＲＯＭ、１０２ａ　ブートプログラム、１０２ｂ　アプリケーションプログラム、１０２ｃ　空メモリ（記憶部）、１０３　ＲＡＭ、２００　ヘッドユニット、２０１～２０４　ゲートウェイ、２０５～２２２　ＥＣＵ。

Claims (9)

  1. 　車内ネットワークに接続された複数の車載電子機器のうちの１つの車載電子機器であって、
    　無線通信ネットワークを介して車外のサーバ装置からソフトウェア更新要求を受信した場合、前記車内ネットワークに接続された前記複数の車載電子機器が有する複数の記憶部の空き容量を示すメモリマップ情報を、前記無線通信ネットワークを介して前記サーバ装置へ送信し、
    　前記無線通信ネットワークを介して前記サーバ装置から、前記複数の車載電子機器のうちのソフトウェア更新対象となる車載電子機器に対する更新用ソフトウェアのうち、前記複数の車載電子機器が有する複数の記憶部の空き容量より小さい容量を更新対象とした更新データを受信し、前記複数の車載電子機器が有する複数の記憶部の空き容量を使用して前記ソフトウェア更新対象となる車載電子機器にソフトウェア更新を行わせる更新マスタ処理部を備えることを特徴とする車載電子機器。
  2. 　前記更新マスタ処理部は、前記ソフトウェア更新対象となる車載電子機器の更新前のソフトウェアを、バックアップデータとして前記複数の車載電子機器が有する複数の記憶部の空き容量に記憶させることを特徴とする請求項１記載の車載電子機器。
  3. 　前記更新データが、前記ソフトウェア更新対象となる車載電子機器の更新前のソフトウェアと前記更新用ソフトウェアとの差分データである場合、
    　前記サーバ装置から受信した前記更新データおよび前記バックアップデータを用いて、前記更新用ソフトウェアを生成する新イメージ生成部を備えることを特徴とする請求項２記載の車載電子機器。
  4. 　自身がソフトウェア更新対象の車載電子機器である場合に前記更新データを使用してソフトウェア更新を行うソフトウェア更新部を備えることを特徴とする請求項１記載の車載電子機器。
  5. 　車内ネットワークに接続された複数の車載電子機器のソフトウェアを更新させる、車外のサーバ装置であって、
    　無線通信ネットワークを介して前記複数の車載電子機器のうちの１つの車載電子機器へソフトウェア更新要求を送信し、前記１つの車載電子機器から、前記車内ネットワークに接続された前記複数の車載電子機器が有する複数の記憶部の空き容量を示すメモリマップ情報を受信する更新サーバ処理部と、
    　前記メモリマップ情報を用いて、前記複数の車載電子機器のうちのソフトウェア更新対象となる車載電子機器に対する更新用ソフトウェアのうち、前記複数の車載電子機器が有する複数の記憶部の空き容量より小さい容量を更新対象とした更新データを生成し、前記無線通信ネットワークを介して前記１つの車載電子機器へ前記更新データを送信することによって前記ソフトウェア更新対象となる車載電子機器のソフトウェア更新を行わせる更新データ生成部とを備えることを特徴とするサーバ装置。
  6. 　前記更新データ生成部は、前記ソフトウェア更新対象となる車載電子機器の更新前のソフトウェアと前記更新用ソフトウェアとの差分データから前記更新データを生成することを特徴とする請求項５記載のサーバ装置。
  7. 　前記更新データ生成部は、前記複数の車載電子機器が有する複数の記憶部の空き容量および前記ソフトウェア更新対象となる車載電子機器の処理能力に応じて、前記差分データを分割して前記更新データを生成することを特徴とする請求項６記載のサーバ装置。
  8. 　請求項１記載の車載電子機器と、
    　請求項５記載のサーバ装置とを備えるソフトウェア更新システム。
  9. 　車内ネットワークに接続された複数の車載電子機器と、前記複数の車載電子機器のうちの少なくとも１つの車載電子機器と無線通信ネットワークを介して通信可能な車外のサーバ装置とを備えるソフトウェア更新システムのソフトウェア更新方法であって、
    　前記サーバ装置が、前記無線通信ネットワークを介して前記複数の車載電子機器のうちの１つの車載電子機器へソフトウェア更新要求を送信するステップと、
    　前記１つの車載電子機器が、前記無線通信ネットワークを介して前記サーバ装置からソフトウェア更新要求を受信し、前記車内ネットワークに接続された前記複数の車載電子機器が有する複数の記憶部の空き容量を示すメモリマップ情報を、前記無線通信ネットワークを介して前記サーバ装置へ送信するステップと、
    　前記サーバ装置が、前記無線通信ネットワークを介して前記１つの車載電子機器からメモリマップ情報を受信し、前記メモリマップ情報を用いて、前記複数の車載電子機器のうちのソフトウェア更新対象となる車載電子機器に対する更新用ソフトウェアのうち、前記複数の車載電子機器が有する複数の記憶部の空き容量より小さい容量を更新対象とした更新データを生成し、前記無線通信ネットワークを介して前記１つの車載電子機器へ前記更新データを送信するステップと、
    　前記１つの車載電子機器が、前記無線通信ネットワークを介して前記サーバ装置から更新データを受信し、前記複数の車載電子機器が有する複数の記憶部の空き容量を使用して前記ソフトウェア更新対象となる車載電子機器にソフトウェア更新を行わせるステップと備えることを特徴とするソフトウェア更新方法。
PCT/JP2017/030111 2017-08-23 2017-08-23 車載電子機器、サーバ装置、およびソフトウェア更新方法 WO2019038855A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/030111 WO2019038855A1 (ja) 2017-08-23 2017-08-23 車載電子機器、サーバ装置、およびソフトウェア更新方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/030111 WO2019038855A1 (ja) 2017-08-23 2017-08-23 車載電子機器、サーバ装置、およびソフトウェア更新方法

Publications (1)

Publication Number Publication Date
WO2019038855A1 true WO2019038855A1 (ja) 2019-02-28

Family

ID=65439813

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/030111 WO2019038855A1 (ja) 2017-08-23 2017-08-23 車載電子機器、サーバ装置、およびソフトウェア更新方法

Country Status (1)

Country Link
WO (1) WO2019038855A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2021199575A1 (ja) * 2020-03-30 2021-10-07
WO2023195324A1 (ja) * 2022-04-04 2023-10-12 株式会社オートネットワーク技術研究所 車載システム、更新制御装置、及びプログラム更新制御方法
WO2024106264A1 (ja) * 2022-11-17 2024-05-23 横河電機株式会社 更新補助デバイス、更新補助方法、および、更新補助プログラム、ならびに、フィールド機器

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008291666A (ja) * 2007-05-22 2008-12-04 Suzuki Motor Corp 車両用制御装置
JP2010218070A (ja) * 2009-03-16 2010-09-30 Toyota Motor Corp 管理装置
JP2012091755A (ja) * 2010-10-29 2012-05-17 Honda Motor Co Ltd 車両用プログラム書換えシステム
JP2013246718A (ja) * 2012-05-28 2013-12-09 Auto Network Gijutsu Kenkyusho:Kk 制御システム及びプログラム更新方法
JP2016071527A (ja) * 2014-09-29 2016-05-09 株式会社オートネットワーク技術研究所 通信システム、車載装置、通信装置、及びコンピュータプログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008291666A (ja) * 2007-05-22 2008-12-04 Suzuki Motor Corp 車両用制御装置
JP2010218070A (ja) * 2009-03-16 2010-09-30 Toyota Motor Corp 管理装置
JP2012091755A (ja) * 2010-10-29 2012-05-17 Honda Motor Co Ltd 車両用プログラム書換えシステム
JP2013246718A (ja) * 2012-05-28 2013-12-09 Auto Network Gijutsu Kenkyusho:Kk 制御システム及びプログラム更新方法
JP2016071527A (ja) * 2014-09-29 2016-05-09 株式会社オートネットワーク技術研究所 通信システム、車載装置、通信装置、及びコンピュータプログラム

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2021199575A1 (ja) * 2020-03-30 2021-10-07
WO2021199575A1 (ja) * 2020-03-30 2021-10-07 日立Astemo株式会社 プログラム更新システム、車両制御装置及びプログラム更新方法
JP7390476B2 (ja) 2020-03-30 2023-12-01 日立Astemo株式会社 プログラム更新システム、車両制御装置及びプログラム更新方法
WO2023195324A1 (ja) * 2022-04-04 2023-10-12 株式会社オートネットワーク技術研究所 車載システム、更新制御装置、及びプログラム更新制御方法
WO2024106264A1 (ja) * 2022-11-17 2024-05-23 横河電機株式会社 更新補助デバイス、更新補助方法、および、更新補助プログラム、ならびに、フィールド機器

Similar Documents

Publication Publication Date Title
JP6889296B2 (ja) ゲートウェイ装置、システム及びファームウェア更新方法
CN106257416B (zh) 用于无线远程更新车辆软件的方法
CN106257420B (zh) 用于使用差分更新包更新ecu的方法
WO2018070156A1 (ja) ソフトウェア更新装置、ソフトウェア更新方法、ソフトウェア更新システム
US11914987B2 (en) Master update agent and distributed update agent architecture for vehicles
US20160371075A1 (en) Method for software updating of vehicle components
US9372682B2 (en) Parallel programming and updating of lighting bus subscribers
JP6581859B2 (ja) 情報処理装置、ソフトウェア配信システム、およびソフトウェア配信方法
WO2019038855A1 (ja) 車載電子機器、サーバ装置、およびソフトウェア更新方法
JP2022093680A (ja) ゲートウェイ装置、車載ネットワークシステム及びファームウェア更新方法
US11126422B2 (en) Program update system, control system, mobile body, program update method, recording medium
US11853742B2 (en) Server, software update system, distribution method, and non-transitory storage medium
WO2020162430A1 (ja) 電子制御装置及び不揮発性メモリの使用方法
US20220244946A1 (en) Ota master, update control method, non-transitory storage medium, and vehicle
JP7484791B2 (ja) Ｏｔａマスタ、更新制御方法、及び更新制御プログラム
CN115514742A (zh) Ota管理器、中心、系统、方法、非暂时性存储介质
US11995429B2 (en) Software update device, update control method, non-transitory storage medium, and server
CN111586112B (zh) 一种数据传输方法、装置以及计算机可读存储介质
JP2022187646A (ja) Ｏｔａマスタ、システム、方法、プログラム、及び車両
JP6631676B2 (ja) 車載更新装置、更新システム及び更新処理プログラム
JP2020154540A (ja) メモリシステム及び制御システム
US20080228840A1 (en) Data updating method and data processing system
US10540169B2 (en) Electronic device configured to update program stored therein using difference data and program updating method using difference data
CN116483409A (zh) 一种远程固件更新的方法、系统、电子设备及存储介质
CN115514743A (zh) 中心、ota管理器、方法、非暂时性存储介质及车辆

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17922751

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP