WO2023175752A1 - 車載プログラム更新システム、車載プログラム更新方法 - Google Patents

車載プログラム更新システム、車載プログラム更新方法 Download PDF

Info

Publication number
WO2023175752A1
WO2023175752A1 PCT/JP2022/011768 JP2022011768W WO2023175752A1 WO 2023175752 A1 WO2023175752 A1 WO 2023175752A1 JP 2022011768 W JP2022011768 W JP 2022011768W WO 2023175752 A1 WO2023175752 A1 WO 2023175752A1
Authority
WO
WIPO (PCT)
Prior art keywords
program
vehicle
old
block
blocks
Prior art date
Application number
PCT/JP2022/011768
Other languages
English (en)
French (fr)
Inventor
正貴 袁
Original Assignee
日立Astemo株式会社
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 日立Astemo株式会社 filed Critical 日立Astemo株式会社
Priority to JP2024507278A priority Critical patent/JPWO2023175752A1/ja
Priority to PCT/JP2022/011768 priority patent/WO2023175752A1/ja
Publication of WO2023175752A1 publication Critical patent/WO2023175752A1/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

Definitions

  • the present invention relates to the configuration of an in-vehicle program update system for updating programs in an in-vehicle ECU and an update method therefor, and particularly relates to a technique that is effective when applied to updates of programs with a large amount of information.
  • the typical reprogramming method involves transferring the entire new program from a PC (Personal Computer) to the on-vehicle device.
  • the on-vehicle device that receives the new program rewrites the entire received new program with the entire old program in the FLASH ROM installed in the on-vehicle device. If the update scale of the new program is small compared to the old program, if the entire new program including the unchanged program is transferred to the on-board device and reprogrammed, the transfer time of the unchanged program and the writing to FLASH ROM will be reduced. Time will be wasted.
  • Patent Document 1 proposes rewriting of block differences.
  • Patent Document 1 states, ⁇ Focusing on the fact that the FLASH memory built into the ECU's microcontroller is composed of multiple blocks, new programs and old programs are divided into blocks, and the new program and multiple blocks are divided into blocks.
  • the differential compressed data that compresses the difference between the block and the old program is transferred to the vehicle control device, the received differential compressed data is expanded on the vehicle control device side, and the new program is restored using the old program in multiple blocks of FLASH memory. "The process of writing to the relevant block in the FLASH memory is repeated for each block.” (Paragraph [0009] of Patent Document 1)
  • Patent Document 1 a new program and an old program are divided into blocks, and a difference is generated for each block and transferred from the PC to the on-vehicle device.
  • an object of the present invention is to provide an in-vehicle program update system and an in-vehicle program update method that eliminate the need to prepare an old program in advance and can suppress the trouble of version control of the old program and work errors during reprogramming work. There is a particular thing.
  • the present invention provides an in-vehicle program update system that updates an old program on a memory installed in an on-vehicle device to a new program, in which each of a plurality of blocks into which the new program is divided is A first group of identifiers, which is a set of unique identifiers, is transmitted to the onboard device, and the second group of identifiers, which is a set of identifiers unique to each block of the old program, and the second group of identifiers are transmitted from the onboard device.
  • the present invention is characterized in that it receives area information specifying a block corresponding to a difference from one identifier group, and transmits a block corresponding to the area information in the new program to the on-vehicle device.
  • the present invention also provides an in-vehicle program update method for updating an old program on a memory installed in an on-vehicle device to a new program, which includes (a) a unique identifier for each of a plurality of blocks into which the new program is divided; (b) transmitting a first group of identifiers, which is a set of identifiers, to the on-vehicle device; (b) a second group of identifiers, which is a set of identifiers unique to each block of the old program; (c) transmitting a block corresponding to the difference in the new program to the on-vehicle device; It is characterized by
  • an in-vehicle program update system and an in-vehicle program update method that do not require preparing an old program in advance and can suppress the effort of managing the version of the old program and work errors during reprogramming work. can.
  • FIG. 1 is a schematic diagram showing the overall configuration of an in-vehicle program update system.
  • FIG. 2 is a diagram showing a modification of FIG. 1;
  • 3 is a diagram showing a schematic configuration of a PC 1 in FIGS. 1 and 2.
  • FIG. 3 is a diagram showing a schematic configuration of the on-vehicle device 2 shown in FIGS. 1 and 2.
  • FIG. It is a functional block diagram of program update of PC1.
  • 5 is a diagram illustrating an example of dividing a program into blocks by a dividing unit 503.
  • FIG. FIG. 3 is a functional block diagram of a reprogramming tool 305 and a program update of the on-vehicle device 2.
  • FIG. 3 is a functional block diagram of a reprogramming tool 305 and a program update of the on-vehicle device 2 according to the second embodiment.
  • 12 is a flowchart of updating the programs of the reprogramming tool 305 and the on-vehicle device 2 according to the second embodiment.
  • 12 is a functional block diagram of a reprogramming tool 305 and a program update of the on-vehicle device 2 according to the third embodiment.
  • FIG. 3 is a functional block diagram of a reprogramming tool 305 and a program update of the on-vehicle device 2 according to the second embodiment.
  • 12 is a flowchart of updating the programs of the reprogramming tool 305 and the on-vehicle device 2 according to the second embodiment.
  • 12 is a functional block diagram of a reprogramming tool 305 and a program update of the on-vehicle device 2 according to the third embodiment.
  • FIG. 3 is a functional block diagram of a re
  • FIG. 1 is a schematic diagram showing the overall configuration of the in-vehicle program update system of this embodiment, and shows an example of the system configuration using CAN (Controller Area Network).
  • FIG. 2 is a modification of FIG. 1, and shows an example of a system configuration using OTA (Over The Air).
  • the in-vehicle program update system of this embodiment mainly includes a PC (personal computer) 1 and an on-vehicle device 2 connected to the PC 1 via a network such as CAN or OTA. It is equipped with While CAN and OTA are used as in-vehicle networks that connect ECUs and sensors in cars, when updating the program of on-board equipment (ECU) 2, as shown in Figures 1 and 2, CAN and OTA are It is also used as a network between PC and onboard equipment to transfer new programs to.
  • PC personal computer
  • OTA on-vehicle device 2
  • CAN and OTA are used as in-vehicle networks that connect ECUs and sensors in cars, when updating the program of on-board equipment (ECU) 2, as shown in Figures 1 and 2, CAN and OTA are It is also used as a network between PC and onboard equipment to transfer new programs to.
  • Examples of program updates for the onboard device 2 include updating the functions of the onboard device 2, fixing defects such as software bugs, and security updates.
  • the operation according to the present invention described below does not depend on the communication format between the PC 1 and the onboard device 2, so even if the communication format changes such as CAN or OTA, the operation according to the present invention basically remains the same. are the same.
  • FIG. 3 is a diagram showing a schematic configuration of the PC 1 in FIGS. 1 and 2.
  • the PC 1 communicates with the outside via an arithmetic unit 301 such as a CPU (Central Processing Unit), input/output devices 302 such as a keyboard, mouse, and display, and wired or wireless communication. It includes a communication device 303 and a storage device 306 such as RAM (Random Access Memory), ROM (Read Only Memory), and HDD (Hard Disk Drive). Arithmetic device 301, input/output device 302, communication device 303, and storage device 306 are interconnected by a bus.
  • arithmetic unit 301 such as a CPU (Central Processing Unit)
  • input/output devices 302 such as a keyboard, mouse, and display
  • wired or wireless communication includes a communication device 303 and a storage device 306 such as RAM (Random Access Memory), ROM (Read Only Memory), and HDD (Hard Disk Drive).
  • Arithmetic device 301, input/output device 302, communication device 303, and storage device 306 are interconnected by a bus.
  • the storage device 306 stores a new program 304 for updating an old program written in the FLASH ROM of the onboard device 2, which will be described later, and a reprogramming tool 305 for updating the program.
  • the reprogramming tool 305 is a computer program used for program update (reprogramming).
  • FIG. 4 is a diagram showing a schematic configuration of the on-vehicle device 2 shown in FIGS. 1 and 2. As shown in FIG. 4
  • the onboard device 2 includes an arithmetic unit 403 such as a CPU (Central Processing Unit), various ICs (Integrated Circuits) 401, a communication device 402 such as a CAN transceiver, a FLASH ROM 408 that is a nonvolatile memory, and a volatile It is equipped with a RAM 404 which is a static memory.
  • arithmetic unit 403 such as a CPU (Central Processing Unit), various ICs (Integrated Circuits) 401, a communication device 402 such as a CAN transceiver, a FLASH ROM 408 that is a nonvolatile memory, and a volatile It is equipped with a RAM 404 which is a static memory.
  • arithmetic unit 403 such as a CPU (Central Processing Unit), various ICs (Integrated Circuits) 401
  • a communication device 402 such as a CAN transceiver
  • FLASH ROM 408 that is a nonvolatile memory
  • a volatile It is equipped with
  • FIG. 4 shows a minimum configuration, but other configurations may be provided.
  • the FLASH ROM 408 stores a boot loader 405 that is not subject to program update, an old program 406 that is subject to program update, and various parameters 407.
  • FIG. 5 is a functional block diagram for updating the program of the PC 1. As shown in FIG.
  • the new program 304 for updating the old program 406 of the onboard device 2 is divided into a plurality of blocks. As a result, a new block group 505 is generated.
  • Each block of the new block group 505 and each compressed block of the compressed block group 501 have a one-to-one relationship.
  • compressed block 1 of the compressed block group 501 is generated by compressing block 1 of the new block group 505.
  • the purpose of compression is to shorten the communication time between the reprogramming tool 305 and the onboard device 2 by reducing the block size.
  • the identifier calculation unit 506 is used to calculate the identifiers corresponding to all the blocks in the new block group 505. As a result, a new identifier group 502 containing the same number of identifiers (six in this case) is generated.
  • Each block of the new block group 505 and each identifier (hash 1 to 6) of the new identifier group 502 have a one-to-one relationship.
  • the identifier calculation result for block 1 of the new block group 505 is hash 1 of the new identifier group 502.
  • the purpose of providing the identifier is to verify the identity of the new program 304 and the old program 406. For example, if there is a 1-bit difference in program data, it is desirable to change the identifier, so a hash value with 128 bits or more is used. Note that there are various algorithms for calculating hash values, and they are not particularly specified here.
  • the block division described above is the premise of the present invention. Since a method is adopted in which only blocks that have been changed in the on-vehicle device 2 are updated based on the new program 304 and the old program 406, appropriate block division is important. Therefore, the explanation of the concept of block division by the division unit 503 will be supplemented.
  • the number and size of divided blocks depend on the scale of the new program 304, the system configuration of the onboard device 2, and the specifications of the FLASH ROM 408, so in reality it is difficult to specify a unified dividing method, but the following Next, we will explain the basic division principle.
  • the on-vehicle device 2 has a parallel arithmetic processing device consisting of a plurality of CPUs, the blocks are divided based on task assignment to each of the plurality of CPUs.
  • the unique data for one camera is used. Since it is only necessary to update the data and there is no need to update the unique data of cameras that are not calibrated, the unique data of the two cameras is divided into blocks.
  • FIG. 6 is a diagram showing an example of program block division by the division unit 503.
  • the new program 304 is divided into block groups 601 (corresponding to the new block group 505 in FIG. 5) using the dividing unit 503.
  • the minimum erase size (sector) of the FLASH ROM 408 is 256 Mbyte
  • the block group 601 includes the common database (256 Mbyte), application function 1 (1024 Mbyte), application function 2 (768 Mbyte), and vehicle control function ( 512Mbyte), basic software (256Mbyte), camera 1 specific data (256Mbyte), and camera 2 specific data (256Mbyte). All block sizes are integral multiples of 256MByte.
  • the common database is a program that changes frequently, so it is divided independently from other blocks.
  • application function 1, application function 2, vehicle control function, and basic software correspond to task assignments of function modules and CPUs, and are therefore divided into separate sections.
  • the camera 1 specific data and the camera 2 specific data are divided independently from each other from the viewpoint of the stereo camera having the two cameras described above.
  • the new program 304 is divided into blocks of data for the right camera and blocks of data for the left camera of the stereo camera independently of each other.
  • the dividing unit 503 is not limited to the above example of block division, but can determine the optimal dividing method according to the scale of the new program 304, the system configuration of the onboard device 2, and the specifications of the FLASH ROM 408. should be adopted.
  • the division methods include manually dividing the program into blocks, using a special tool to divide the program into blocks, or dividing the source code in advance before generation using program build, and building each divided source code to create multiple program blocks. Examples include a method of generating it.
  • FIG. 7 is a functional block diagram of the program update of the reprogramming tool 305 and the onboard device 2, and shows an example of identifier comparison using the onboard device 2.
  • the reprogramming tool 305 includes an input compressed block group 501, a new identifier group 502, and an extraction unit 701.
  • the extracting unit 701 plays the role of extracting a compressed block 702 corresponding to a changed block from the compressed block group 501 based on information specifying a changed block received from the on-vehicle device 2 .
  • the onboard device 2 includes a microcomputer processing section 707 (corresponding to the arithmetic unit 403 in FIG. 4) and a FLASH ROM 408.
  • the FLASH ROM 408 includes a boot loader 405, an old program 406, and an old identifier group 407.
  • the relationship between the old program 406 and the old identifier group 407 is similar to the relationship between the new program 304 and the new identifier group 502 shown in FIG.
  • the old identifier group 407 is included in the various parameters 407 shown in FIG.
  • the boot loader 405 includes a decompression section 703, a FLASH operation section 704, and an identifier comparison section 705.
  • the decompression unit 703, FLASH operation unit 704, and identifier comparison unit 705 of the boot loader 405 are executed by the microcomputer processing unit 707. That is, the microcomputer processing unit 707 includes a decompression unit 703, a FLASH operation unit 704, and an identifier comparison unit 705 included in the boot loader 405.
  • the decompressing unit 703 plays the role of decompressing the compressed block 702 received from the reprogramming tool 305 to generate a block 706. This is an inverse algorithm of the compression unit 504 shown in FIG. 5.
  • the FLASH operation unit 704 uses the new identifier group 502 and block 706 received from the reprogramming tool 305 to erase and rewrite the corresponding parts of the old program 406 and the old identifier group 407.
  • the identifier comparison unit 705 compares the new identifier group 502 received from the reprogramming tool 305 and the old identifier group 407 read from the FLASH ROM 408.
  • the comparison method is a one-to-one identity comparison of the same block position.
  • the block corresponding to the identifier with the difference becomes the block with the change.
  • the automatic comparison by the identifier comparison unit 705 eliminates the need for manual selection or other operations based on the version of the old program 406, which eliminates the risk of operational errors by the operator.
  • FIG. 8 is a flowchart for updating the programs of the reprogramming tool 305 and the onboard device 2, and shows an example of identifier comparison using the onboard device 2.
  • step S801 the new identifier group 502 is transmitted from the reprogramming tool 305 to the onboard device 2.
  • the onboard device 2 receives the new identifier group 502.
  • step S803 the new identifier group 502 is compared with the old identifier group 407.
  • step S804 information specifying the block corresponding to the difference that is the comparison result in step S803 is transmitted from the onboard device 2 to the reprogramming tool 305.
  • step S805 the reprogramming tool 305 receives information identifying a block corresponding to the difference.
  • step S806 based on the information received in step S805, it is determined whether there is an identifier with a difference, that is, whether there is a block that requires reprogramming.
  • step S807 the reprogramming tool 305 extracts a compressed block corresponding to the identifier with a difference, that is, a compressed block necessary for reprogramming.
  • step S808 all extracted compressed block data is transmitted to the onboard device 2.
  • step S809 the onboard device 2 receives the compressed program data.
  • step S810 the compressed block data is decompressed and restored to the original block of the new program 304.
  • step S811 after erasing the old identifier group 407 and the corresponding part (sector) of the FLASH ROM 408 corresponding to the specified block, the new identifier group 502 and the restored block are used to erase the erased part of the FLASH ROM 408. Write to a location (sector).
  • the identifier comparison unit 705 is provided in the on-vehicle device 2, and the identification of blocks that have been changed through identifier comparison is performed on the on-vehicle device 2 side.
  • the identifier comparison unit 901 is included in the reprogramming tool 305, and the reprogramming tool 305 side identifies blocks that have been changed by comparing the identifiers.
  • FIG. 9 is a functional block diagram of the reprogramming tool 305 and program update of the onboard device 2, and shows an example of identifier comparison using the reprogramming tool 305.
  • the identifier comparison unit 901 of the reprogramming tool 305 of this embodiment corresponds to the identifier comparison unit 705 shown in the microcomputer processing unit 707 of the first embodiment (FIG. 7).
  • the identifier comparison unit 901 plays the role of comparing the old identifier group 407 received from the onboard device 2 with the new identifier group 502. This comparison method is the same as that explained in Example 1 (FIG. 7). Further, the functional blocks other than the identifier comparison unit 901 are the same as those in the first embodiment (FIG. 7).
  • FIG. 10 is a flowchart of updating the program of the reprogramming tool 305 and the onboard device 2, and shows an example of identifier comparison using the reprogramming tool 305.
  • step S1001 a request for the old identifier group 407 is sent from the reprogramming tool 305 to the onboard device 2.
  • step S1002 the onboard device 2 receives a request for the old identifier group 407.
  • step S1003 the old identifier group 407 is transmitted from the onboard device 2 to the reprogramming tool 305.
  • step S1004 the reprogramming tool 305 receives the old identifier group 407.
  • step S1005 the received old identifier group 407 is compared with the new identifier group 502.
  • FIG. 11 is a functional block diagram of the program update of the reprogramming tool 305 and the onboard device 2, and shows an example of an increase in the number of blocks.
  • the compressed block 7 is added to the compressed block group 1101, and the hash 7 is also added to the new identifier group 1102.
  • the identifier comparison unit 705 compares the new identifier group 1102 received from the reprogramming tool 305 and the old identifier group 1104 read from the FLASH ROM 408.
  • the comparison method is a one-to-one identity comparison of the same block position.
  • the block corresponding to the identifier with the difference becomes the block to be increased.
  • the value of the reserved area of the old identifier group 1104 is usually all 0's or all F's.
  • the hash 7 of the new identification group 1102 is calculated from the increased blocks 7 of the new program 304, and is not necessarily all 0 or all F.
  • the identifier comparison may be performed by either the reprogramming tool 305 or the on-vehicle device 2, and either the processing flowchart shown in FIG. 8 or FIG. 10 can be applied.
  • the present invention is not limited to the above-described embodiments, and includes various modifications.
  • the embodiments described above are described in detail to explain the present invention in an easy-to-understand manner, and the present invention is not necessarily limited to having all the configurations described.
  • it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment and it is also possible to add the configuration of another embodiment to the configuration of one embodiment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Stored Programmes (AREA)

Abstract

事前に旧プログラムを用意する必要がなく、旧プログラムのバージョン管理の手間やリプログラミング作業時の作業ミスを抑制可能な車載プログラム更新システムを提供する。車載器に搭載されたメモリ上の旧プログラムを新プログラムに更新する車載プログラム更新システムであって、前記新プログラムが分割された複数のブロックの各々が固有にもつ識別子の集合である第一の識別子群を車載器に送信し、前記車載器から、前記旧プログラムの各ブロックの各々が固有にもつ識別子の集合である第二の識別子群と前記第一の識別子群との差分に対応するブロックを特定する領域情報を受信し、前記新プログラムにおいて前記領域情報に相当するブロックを、前記車載器に送信することを特徴とする。

Description

車載プログラム更新システム、車載プログラム更新方法
　本発明は、車載ECUのプログラムを更新する車載プログラム更新システムの構成とその更新方法に係り、特に、情報量の多いプログラムの更新に適用して有効な技術に関する。
　電子制御技術の進化に伴い、エンジンをはじめとする様々な機能・装置において、電子制御による自動車の性能向上が図られている。特に近年では、ADAS（Advanced Driver Assistance System：先進運転支援システム）やAD（Automated Driving：自動運転）が急速に普及しつつあり、車載ECU（Electronic Control Unit：電子制御装置）に搭載されるプログラムの処理も複雑化している。そのため、プログラムが肥大化しており、プログラムの更新（以下、「リプログラミング」とも呼ぶ）に掛かる所要時間は今後益々伸びていくことが予想される。
　従来、一般的なリプログラミング手法では、新プログラム全体をPC（Personal Computer：パソコン）などから車載器に転送することで行われている。新プログラムを受信した車載器は、受信した新プログラム全体を、車載器に搭載されたFLASH ROMの旧プログラム全体と書換える。旧プログラムに対して新プログラムの更新規模が小さい場合、変更のないプログラムを含む新プログラム全体を車載器に転送してリプログラミングしてしまうと、変更のないプログラムの転送時間及びFLASH ROMへの書込み時間が無駄になる。
　このような問題に対して、例えば特許文献１では、ブロック差分の書換えが提案されている。
　特許文献１には、「ECUのマイコンに内蔵されているFLASHメモリが複数のブロックで構成されている点に着目し、新プログラムと旧プログラムをブロック単位に分割し、当該ブロックの新プログラムと複数ブロックの旧プログラムとの差分を圧縮した差分圧縮データを車両制御装置へ転送し、車両制御装置側で受信した差分圧縮データを伸長してFLASHメモリの複数ブロックの旧プログラムを用いて新プログラムを復元して、FLASHメモリの当該ブロックへ書込むことを各ブロックごとに繰返す」ことが記載されている。（特許文献１の段落［０００９］）
特開２０１９－６１６９０号公報
　上記特許文献１に開示されている技術では、新プログラムと旧プログラムをブロック単位に分割し、ブロック単位毎に差分を生成してPCから車載器に転送する。
　しかしながら、ブロック単位毎に新旧プログラムの差分を生成するために、車載器に記憶されている旧プログラムを事前に用意する必要があり、旧プログラムのバージョン管理の手間や、車載器に記憶されている旧プログラムの調査工数が発生する。
　また、例えばリコールや不具合修正のために、多数の車載器をリプログラミングする際、車載器に記憶されている旧プログラムのバージョンが同一でなければ、複数の旧プログラムを用意して同数の差分を生成する必要がある。
　作業員は、リプログラミング作業時に、車載器に記憶されている旧プログラムのバージョンに沿って、複数の差分の中から適切な差分を選択してリプログラミングする必要があるため、作業ミスが発生する可能性もある。
　そこで、本発明の目的は、事前に旧プログラムを用意する必要がなく、旧プログラムのバージョン管理の手間やリプログラミング作業時の作業ミスを抑制可能な車載プログラム更新システム及び車載プログラム更新方法を提供することにある。
　上記課題を解決するために、本発明は、車載器に搭載されたメモリ上の旧プログラムを新プログラムに更新する車載プログラム更新システムであって、前記新プログラムが分割された複数のブロックの各々が固有にもつ識別子の集合である第一の識別子群を車載器に送信し、前記車載器から、前記旧プログラムの各ブロックの各々が固有にもつ識別子の集合である第二の識別子群と前記第一の識別子群との差分に対応するブロックを特定する領域情報を受信し、前記新プログラムにおいて前記領域情報に相当するブロックを、前記車載器に送信することを特徴とする。
　また、本発明は、車載器に搭載されたメモリ上の旧プログラムを新プログラムに更新する車載プログラム更新方法であって、（ａ）新プログラムが分割された複数のブロックの各々が固有にもつ識別子の集合である第一の識別子群を車載器に送信するステップと、（ｂ）前記車載器から、旧プログラムの各ブロックの各々が固有にもつ識別子の集合である第二の識別子群と前記第一の識別子群との差分に対応するブロックを特定するための領域情報を受信するステップと、（ｃ）前記新プログラムにおいて前記差分に相当するブロックを、前記車載器に送信するステップと、を有することを特徴とする。
　本発明によれば、事前に旧プログラムを用意する必要がなく、旧プログラムのバージョン管理の手間やリプログラミング作業時の作業ミスを抑制可能な車載プログラム更新システム及び車載プログラム更新方法を実現することができる。
　これにより、高速かつ信頼性の高い車載ECUのプログラム更新が可能となる。
　上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
車載プログラム更新システムの全体構成を示す模式図である。 図１の変形例を示す図である。 図１及び図２のPC１の概略構成を示す図である。 図１及び図２の車載器２の概略構成を示す図である。 PC１のプログラム更新の機能ブロック図である。 分割部５０３によるプログラムのブロック分割例を示す図である。 リプログラミングツール３０５と車載器２のプログラム更新の機能ブロック図である。 リプログラミングツール３０５と車載器２のプログラム更新のフローチャートである。 実施例２に係るリプログラミングツール３０５と車載器２のプログラム更新の機能ブロック図である。 実施例２に係るリプログラミングツール３０５と車載器２のプログラム更新のフローチャートである。 実施例３に係るリプログラミングツール３０５と車載器２のプログラム更新の機能ブロック図である。
　以下、図面を用いて本発明の実施例を説明する。なお、各図面において同一の構成については同一の符号を付し、重複する部分についてはその詳細な説明は省略する。
　図１から図８を参照して、本発明の実施例１に係る車載プログラム更新システム及び車載プログラム更新方法について説明する。
　図１は、本実施例の車載プログラム更新システムの全体構成を示す模式図であり、CAN（Controller Area Network）を用いたシステム構成例を示している。図２は、図１の変形例であり、OTA（Over The Air）を用いたシステム構成例を示している。
　本実施例の車載プログラム更新システムは、図１及び図２に示すように、主要な構成として、PC（パソコン）１と、CANまたはOTAなどのネットワークを介してPC１に接続された車載器２とを備えている。CAN及びOTAは、自動車の中でECUやセンサを繋ぐ車載ネットワークとして利用される一方、図１及び図２のように、車載器（ECU）２のプログラムを更新する際に、PC１から車載器２へ新プログラムを転送するためのPC－車載器間ネットワークとしても利用される。
　車載器２のプログラム更新の例としては、車載器２の機能のアップデートや、ソフトバグなどの不具合の修正、セキュリティアップデートなどが挙げられる。
　なお、以下で説明する本発明による動作は、PC１と車載器２との間における通信形式には依存しないため、CAN，OTAのように通信形式が変わっても、本発明による動作は基本的に同一である。
　次に、図３を用いて、図１及び図２に示したPC１の構成を説明する。図３は、図１及び図２のPC１の概略構成を示す図である。
　図３に示すように、PC１は、CPU（Central Processing Unit）のような演算装置３０１、キーボードやマウスや表示器などの入出力装置３０２、有線通信あるいは無線通信を介して外部との通信を行う通信装置３０３、RAM（Random Access Memory）やROM（Read Only Memory）、HDD（Hard Disk Drive）などの記憶装置３０６を備えている。演算装置３０１、入出力装置３０２、通信装置３０３、記憶装置３０６は、バスにより相互に接続されている。
　記憶装置３０６には、後述する車載器２のFLASH ROMに記載されている旧プログラムを更新する新プログラム３０４、プログラム更新用のリプログラミングツール３０５が記憶されている。リプログラミングツール３０５は、プログラムの更新（リプログラミング）に使うコンピュータ・プログラム類である。
　次に、図４を用いて、図１及び図２に示した車載器２の構成を説明する。図４は、図１及び図２の車載器２の概略構成を示す図である。
　図４に示すように、車載器２は、CPU（Central Processing Unit）のような演算装置４０３、各種IC（Integrated Circuit）４０１、CANトランシーバなどの通信装置４０２、不揮発性メモリであるFLASH ROM４０８、揮発性メモリであるRAM４０４を備えている。
　なお、車載器２の構成を分かり易くするために、図４には最小限の構成を示しているが、他の構成を備えていても良い。
　FLASH ROM４０８には、プログラム更新対象外のブートローダ４０５、プログラム更新対象の旧プログラム４０６、各種パラメータ４０７が記憶されている。
　図５を用いて、プログラム更新を実行するためのPC１の機能ブロックを説明する。図５は、PC１のプログラム更新の機能ブロック図である。
　先ず、分割部５０３を用いて、車載器２の旧プログラム４０６を更新するための新プログラム３０４を複数のブロックに分割する。その結果、新ブロック群５０５が生成される。
　分割するブロック数は特に限定されないため、ここでは一例として、ブロック１～６の６個のブロックに分割する例を示す。分割部５０３による具体的なブロック分割については、図６を用いて後述する。
　次に、圧縮部５０４を用いて、新ブロック群５０５の全ブロックをそれぞれ圧縮する。その結果、同数の（ここでは６個の）圧縮ブロックを含む圧縮ブロック群５０１が生成される。
　新ブロック群５０５の各ブロックと圧縮ブロック群５０１の各圧縮ブロックは、１対１の関係にある。例えば、新ブロック群５０５のブロック１を圧縮して圧縮ブロック群５０１の圧縮ブロック１が生成される。
　圧縮の目的は、ブロックのサイズを減少することにより、リプログラミングツール３０５と車載器２の間の通信時間を短縮するためである。
　また、識別子演算部５０６を用いて、新ブロック群５０５の全ブロックに対応する識別子をそれぞれ演算する。その結果、同数の（ここでは６個の）識別子を含む新識別子群５０２が生成される。
　新ブロック群５０５の各ブロックと新識別子群５０２の各識別子（ハッシュ１～６）は、１対１の関係にある。例えば、新ブロック群５０５のブロック１の識別子演算結果は、新識別子群５０２のハッシュ１である。
　識別子を設ける目的は、新プログラム３０４と旧プログラム４０６の同一性を検証するためである。例えば、プログラムデータに１ビットの差異があった場合、識別子を変えることが望ましいため、128ビット以上を持つハッシュ値を採用する。なお、ハッシュ値の演算アルゴリズムは様々であり、ここでは特に指定しない。
　最後に、圧縮ブロック群５０１及び新識別子群５０２をリプログラミングツール３０５に入力する。これにより、PC１側でのリプログラミングの事前準備が完了する。
　上記で説明したブロック分割が本発明の前提となる。新プログラム３０４と旧プログラム４０６に基づいて、車載器２に対して変更のあるブロックのみを更新する方式を採用しているため、適切なブロック分割が重要である。そこで、分割部５０３によるブロック分割の考え方の説明を補足する。
　分割ブロックの数とサイズは、新プログラム３０４の規模や、車載器２のシステム構成、FLASH ROM４０８の仕様にも依存するため、統一した分割方法を明示することは難しいのが現実であるが、以下では、基本的な分割原則を説明する。
　先ず、ブロックのサイズは、FLASH ROM４０８の仕様に従って、最小消去サイズの整数倍を基準にする。例えば、最小消去サイズが256Mbyteになる場合、ブロックサイズを256Mbyte×n（n=1、2、…）にする。ブロックサイズが最小消去サイズ（セクタ）の境界を跨いだ場合、消去したいブロックデータを消去すると、消去したいブロック以外のブロックデータも消去してしまう可能性があるためである。
　次に、頻繁に変更のあるプログラムとあまり変更のないプログラムを分けて分割する。さらに、機能モジュール、CPUのタスク割り当て、共通データベースをそれぞれ分けて、ブロック分割を実施する。頻繁に変更のあるプログラムとあまり変更のないプログラムを互いに独立して分割することにより、なるべくリプログラミングに必要なブロックの数とサイズを減らすことができる。
　例えば、車載器２が複数のCPUからなる並列演算処理装置を有している場合、ブロックは、複数のCPUのそれぞれへのタスク割り当てに基づいて分割される。
　また、例えば車載器２を二つのカメラを持つステレオカメラを制御するECUとして使用する場合、カメラの特性などを校正する固有データにおいて、片方のカメラだけを校正する際には、片方のカメラに関する固有データを更新すればよく、校正しないカメラの固有データの更新は必要がないため、二つのカメラの固有データをそれぞれブロックごとに分割する。
　図６を用いて、新プログラム３０４のブロック分割の考え方の一例を説明する。図６は、分割部５０３によるプログラムのブロック分割例を示す図である。
　上記で説明したように、分割部５０３を用いて、新プログラム３０４をブロック群６０１（図５の新ブロック群５０５に相当）に分割する。図６に示す例ではFLASH ROM４０８の最小消去サイズ（セクタ）を256Mbyteとしているので、ブロック群６０１は、共通データベース（256Mbyte）、アプリケーション機能１（1024Mbyte）、アプリケーション機能２（768Mbyte）、車両制御機能（512Mbyte）、ベーシックソフトウェア（256Mbyte）、カメラ１固有データ（256Mbyte）、カメラ２固有データ（256Mbyte）で構成される。全てのブロックサイズが256Mbyteの整数倍になっている。
　共通データベースは、頻繁に変更のあるプログラムであるため、他のブロックとは独立して分割されている。また、アプリケーション機能１、アプリケーション機能２、車両制御機能、ベーシックソフトウェアは、機能モジュールやCPUのタスク割り当てに該当するため、それぞれ分けて分割されている。また、カメラ１固有データ、カメラ２固有データは、上述した二つのカメラを持つステレオカメラの観点で、互いに独立して分割されている。つまり、新プログラム３０４は、ステレオカメラの右カメラ用データのブロックと左カメラ用データのブロックとが互いに独立に分割される。
　なお、上記はあくまでも一例であって、分割部５０３は、上記のブロック分割例に限らず、新プログラム３０４の規模や、車載器２のシステム構成、FLASH ROM４０８の仕様に応じて、最適な分割方法を採用すればよい。
　例えば、分割方法として、手動によるプログラムのブロック分割、専用ツールによるプログラムのブロック分割、プログラムビルドによる生成前にソースコードを予めに分割して、それぞれの分割ソースコードをビルドして複数のプログラムブロックを生成する方法などが挙げられる。
　図７を用いて、リプログラミングツール３０５と車載器２のプログラム更新の機能ブロックを説明する。図７は、リプログラミングツール３０５と車載器２のプログラム更新の機能ブロック図であり、車載器２を用いた識別子比較の例を示している。
　リプログラミングツール３０５は、入力された圧縮ブロック群５０１と新識別子群５０２、及び抽出部７０１を備えている。抽出部７０１は、車載器２から受信した変更のあるブロックを特定する情報に基づいて、変更のあるブロックに対応する圧縮ブロック７０２を圧縮ブロック群５０１から抽出する役割を果たす。
　車載器２は、マイコン処理部７０７（図４の演算装置４０３に相当）、FLASH ROM４０８を備えている。
　FLASH ROM４０８は、ブートローダ４０５、旧プログラム４０６、旧識別子群４０７を備えている。
　旧プログラム４０６と旧識別子群４０７の関係性は、図５に示した新プログラム３０４と新識別子群５０２の関係性と同様である。旧識別子群４０７は図４に示した各種パラメータ４０７に含まれる。
　ブートローダ４０５は、解凍部７０３、FLASH操作部７０４、識別子比較部７０５を備えている。車載器２では、リプログラミングモードで起動後に、ブートローダ４０５の解凍部７０３、FLASH操作部７０４、識別子比較部７０５がマイコン処理部７０７により実行される。すなわち、マイコン処理部７０７は、ブートローダ４０５に含まれる解凍部７０３、FLASH操作部７０４、識別子比較部７０５を有する。
　なお、車載器２の機能を分かり易くするために、図７には最小限の機能ブロックを示しているが、他の機能ブロックを備えていても良い。
　解凍部７０３は、リプログラミングツール３０５から受信した圧縮ブロック７０２を解凍してブロック７０６を生成する役割を果たす。図５に示した圧縮部５０４の逆アルゴリズムである。
　FLASH操作部７０４は、リプログラミングツール３０５から受信した新識別子群５０２、及びブロック７０６を用いて、旧プログラム４０６と旧識別子群４０７の対応箇所の消去及び書換えを行う。
　識別子比較部７０５は、リプログラミングツール３０５から受信した新識別子群５０２とFLASH ROM４０８から読み出した旧識別子群４０７を比較する。
　比較方法は、同じブロック位置の１対１の同一性比較である。差分のある識別子に対応するブロックが、変更のあるブロックになる。
　例えば、新識別子群５０２のハッシュ１と旧識別子群４０７のハッシュ１の比較結果が不一致になった場合、新プログラム３０４のブロック１は旧プログラム４０６のブロック１に対して変更があるため、旧プログラム４０６のブロック１の更新が必要である。
　そのため、識別子比較結果での差分に対応するブロックを特定する情報をリプログラミングツール３０５の抽出部７０１にフィードバックする。
　識別子比較により変更のあるブロックを特定するため、無駄な旧プログラム４０６の送信や、新プログラム３０４と旧プログラム４０６とを直接比較する必要がなく、識別子比較のみにより更新が必要なブロックを把握できるため、時間の短縮が図れる。
　また、旧プログラム４０６のバージョンなどを事前に把握する必要がないため、バージョン管理の手間を抑制することができる。
　また、識別子比較部７０５での自動比較により、旧プログラム４０６のバージョンに沿った手動選択などの操作がないため、作業員による操作ミスのリスクも解消される。
　図８を用いて、本発明のポイントである識別子比較により特定した変更のあるブロックのみをリプログラミングする方法を説明する。図８は、リプログラミングツール３０５と車載器２のプログラム更新のフローチャートであり、車載器２を用いた識別子比較の例を示している。
　先ず、ステップＳ８０１において、リプログラミングツール３０５から車載器２へ新識別子群５０２を送信する。ステップＳ８０２において、車載器２は新識別子群５０２を受信する。
　次に、ステップＳ８０３において、新識別子群５０２を旧識別子群４０７と比較する。
　続いて、ステップＳ８０４において、ステップＳ８０３での比較結果である差分に対応するブロックを特定する情報を車載器２からリプログラミングツール３０５へ送信する。ステップＳ８０５において、リプログラミングツール３０５は差分に対応するブロックを特定する情報を受信する。
　次に、ステップＳ８０６において、ステップＳ８０５で受信した情報に基づいて、差分のある識別子の有無、すなわちリプログラミングの必要なブロックの有無を判定する。
　判定結果が無（NO）の場合、変更のあるブロックがなく、リプログラミングの必要はないため、リプログラミングツール３０５と車載器２でのリプログラミング動作を終了する。一方、判定結果が有（YES）の場合、リプログラミング動作を継続する。
　リプログラミング動作を継続する場合、ステップＳ８０７において、リプログラミングツール３０５は、差分のある識別子に対応する圧縮ブロック、すなわちリプログラミングに必要な圧縮ブロックを抽出する。
　続いて、ステップＳ８０８において、抽出した全ての圧縮ブロックデータを車載器２へ送信する。ステップＳ８０９において、車載器２は圧縮されたプログラムデータを受信する。
　受信完了後、ステップＳ８１０において、圧縮ブロックデータを解凍して本来の新プログラム３０４のブロックに復元する。
　最後に、ステップＳ８１１において、旧識別子群４０７及び特定されたブロックに対応するFLASH ROM４０８の該当箇所（セクタ）を消去した後、新識別子群５０２及び復元されたブロックを用いて、FLASH ROM４０８の消去した箇所（セクタ）に書込む。
　以上の車載プログラム更新方法により、識別子比較により特定されたブロックのみを更新することができる。
　図９及び図１０を参照して、本発明の実施例２に係る車載プログラム更新システム及び車載プログラム更新方法について説明する。
　実施例１では、識別子比較部７０５は車載器２に備えられており、識別子比較による変更のあるブロックの特定は車載器２側で行う。これに対し、本実施例では、識別子比較部９０１はリプログラミングツール３０５に備えられており、識別子比較による変更のあるブロックの特定はリプログラミングツール３０５側で行う。
　図９を用いて、リプログラミングツール３０５と車載器２のプログラム更新の機能ブロックについて、実施例１（図７）との相違点を説明する。図９は、リプログラミングツール３０５と車載器２のプログラム更新の機能ブロック図であり、リプログラミングツール３０５を用いた識別子比較の例を示している。
　本実施例（図９）のリプログラミングツール３０５の識別子比較部９０１が、実施例１（図７）のマイコン処理部７０７に示した識別子比較部７０５に相当する。
　識別子比較部９０１は、車載器２から受信した旧識別子群４０７を新識別群５０２と比較する役割を果たす。この比較方法は、実施例１（図７）での説明内容と同様である。また、識別子比較部９０１以外の機能ブロックについては、実施例１（図７）と同様である。
　図１０を用いて、本発明のポイントである識別子比較により特定した変更のあるブロックのみをリプログラミングする方法について、実施例１（図８）との相違点を説明する。図１０は、リプログラミングツール３０５と車載器２のプログラム更新のフローチャートであり、リプログラミングツール３０５を用いた識別子比較の例を示している。
　先ず、ステップＳ１００１において、リプログラミングツール３０５から車載器２へ旧識別子群４０７の要求を送信する。ステップＳ１００２において、車載器２は旧識別子群４０７の要求を受信する。
　次に、ステップＳ１００３において、旧識別子群４０７を車載器２からリプログラミングツール３０５へ送信する。ステップＳ１００４において、リプログラミングツール３０５は旧識別子群４０７を受信する。
　続いて、ステップＳ１００５において、受信した旧識別子群４０７を新識別子群５０２と比較する。
　それ以降の処理ステップＳ１００６、ステップＳ１００７、ステップＳ１００８、ステップＳ１００９、ステップＳ１０１０、ステップＳ１０１１は、図８に示したステップＳ８０６、ステップＳ８０７、ステップＳ８０８、ステップＳ８０９、ステップＳ８１０、ステップＳ８１１と同様である。
　図１１を参照して、本発明の実施例３に係る車載プログラム更新システム及び車載プログラム更新方法について説明する。
　実施例１及び実施例２では、新プログラム３０４が旧プログラム４０６に対して、ブロックデータが変更になるケースを説明した。本実施例では、新プログラム３０４が旧プログラム１１０３に対して、ブロック数が増加するケースについて説明する。
　図１１を用いて、リプログラミングツール３０５と車載器２のプログラム更新の機能ブロックについて、実施例１（図７）との相違点を説明する。図１１は、リプログラミングツール３０５と車載器２のプログラム更新の機能ブロック図であり、ブロック数増加の例を示している。
　ブロック数が増加する本実施例の前提として、車載器２のFLASH ROM４０８（旧プログラム１１０３）に空領域（余剰領域）があり、増加ブロックのデータをFLASH ROM４０８に記憶することができる必要がある。また、旧識別子群１１０４のハッシュ予備領域（余剰領域）も予め確保されている必要がある。一般には、車載器２のソフトウェアを設計する際に、ハッシュ予備領域を幾つか確保する。
　旧プログラム１１０３に対して新プログラム３０４でブロック７が増加すると仮定する。従って、圧縮ブロック群１１０１に圧縮ブロック７が増え、新識別子群１１０２にもハッシュ７が増える。
　実施例１（図７）と同様に、識別子比較部７０５は、リプログラミングツール３０５から受信した新識別子群１１０２とFLASH ROM４０８から読み出した旧識別子群１１０４を比較する。
　比較方法は、同じブロック位置の１対１の同一性比較である。差分のある識別子に対応するブロックが、増加するブロックになる。
　旧識別子群１１０４の予備領域の値は、通常オール０かオールFである。一方、新識別群１１０２のハッシュ７は新プログラム３０４の増えたブロック７から演算されており、必ずオール０かオールFにはならない。
　本実施例（図１１）では、ハッシュ７の新旧識別子比較の結果が差分ありとなるため、圧縮ブロック７を変更のあるブロックとして特定してリプログラミングする。
　なお、ブロック数が増加する本実施例は、識別子比較がリプログラミングツール３０５または車載器２のいずれで実施されてもよく、処理フローチャートは、図８または図１０のいずれも適用することができる。
　また、上記では、新プログラム３０４が旧プログラム１１０３に対して、ブロック数が増加するケースについて説明したが、逆に新プログラム３０４が旧プログラム１１０３に対して、ブロック数が減少するケースについても同様に本発明を適用することができる。
　なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
　１…PC（パソコン）、２…車載器（ECU）、３０１，４０３…演算装置、３０２…入出力装置、３０３，４０２…通信装置、３０４…新プログラム、３０５…リプログラミングツール、３０６…記憶装置、４０１…各種IC、４０４…RAM、４０５…ブートローダ、４０６，１１０３…旧プログラム、４０７…各種パラメータ（旧識別子群）、４０８…FLASH ROM、５０１，１１０１…圧縮ブロック群、５０２，１１０２…新識別子群、５０３…分割部、５０４…圧縮部、５０５…新ブロック群、５０６…識別子演算部、６０１…ブロック群、７０１…抽出部、７０２…圧縮ブロック、７０３…解凍部、７０４…FLASH操作部、７０５，９０１…識別子比較部、７０６…ブロック、７０７…マイコン処理部、１１０４…旧識別子群。

Claims (12)

  1. 　車載器に搭載されたメモリ上の旧プログラムを新プログラムに更新する車載プログラム更新システムであって、
    　前記新プログラムが分割された複数のブロックの各々が固有にもつ識別子の集合である第一の識別子群を車載器に送信し、
    　前記車載器から、前記旧プログラムの各ブロックの各々が固有にもつ識別子の集合である第二の識別子群と前記第一の識別子群との差分に対応するブロックを特定するための領域情報を受信し、
    　前記新プログラムにおいて前記差分に相当するブロックを、前記車載器に送信することを特徴とする車載プログラム更新システム。
  2. 　請求項１に記載の車載プログラム更新システムにおいて、
    　前記領域情報は、前記第一の識別子群と前記第二の識別子群との差分に関する情報、または前記第二の識別子群であることを特徴とする車載プログラム更新システム。
  3. 　請求項１に記載の車載プログラム更新システムにおいて、
    　前記ブロックは、前記新プログラムおよび前記旧プログラムの機能に応じて分割されたものであることを特徴とする車載プログラム更新システム。
  4. 　請求項１に記載の車載プログラム更新システムにおいて、
    　前記車載器は、ステレオカメラを制御する電子制御装置であって、
    　前記新プログラムは、当該ステレオカメラの右カメラ用データのブロックと左カメラ用データのブロックとが互いに独立に分割されることを特徴とする車載プログラム更新システム。
  5. 　請求項１に記載の車載プログラム更新システムにおいて、
    　前記車載器は、複数のCPUからなる並列演算処理装置を有し、
    　前記ブロックは、前記複数のCPUのそれぞれへのタスク割り当てに基づいて分割されたものであることを特徴とする車載プログラム更新システム。
  6. 　請求項１に記載の車載プログラム更新システムにおいて、
    　前記旧プログラムおよび前記第二の識別子群は、前記メモリの最小消去単位の大きさに応じた余剰領域をそれぞれ有することを特徴とする車載プログラム更新システム。
  7. 　車載器に搭載されたメモリ上の旧プログラムを新プログラムに更新する車載プログラム更新方法であって、
    　（ａ）新プログラムが分割された複数のブロックの各々が固有にもつ識別子の集合である第一の識別子群を車載器に送信するステップと、
    　（ｂ）前記車載器から、旧プログラムの各ブロックの各々が固有にもつ識別子の集合である第二の識別子群と前記第一の識別子群との差分に対応するブロックを特定するための領域情報を受信するステップと、
    　（ｃ）前記新プログラムにおいて前記差分に相当するブロックを、前記車載器に送信するステップと、
    　を有することを特徴とする車載プログラム更新方法。
  8. 　請求項７に記載の車載プログラム更新方法において、
    　前記領域情報は、前記第一の識別子群と前記第二の識別子群との差分に関する情報、または前記第二の識別子群であることを特徴とする車載プログラム更新方法。
  9. 　請求項７に記載の車載プログラム更新方法において、
    　前記ブロックは、前記新プログラムおよび前記旧プログラムの機能に応じて分割されたものであることを特徴とする車載プログラム更新方法。
  10. 　請求項７に記載の車載プログラム更新方法において、
    　前記車載器は、ステレオカメラを制御する電子制御装置であって、
    　前記新プログラムは、当該ステレオカメラの右カメラ用データのブロックと左カメラ用データのブロックとが互いに独立に分割されることを特徴とする車載プログラム更新方法。
  11. 　請求項７に記載の車載プログラム更新方法において、
    　前記車載器は、複数のCPUからなる並列演算処理装置を有し、
    　前記ブロックは、前記複数のCPUのそれぞれへのタスク割り当てに基づいて分割されたものであることを特徴とする車載プログラム更新方法。
  12. 　請求項７に記載の車載プログラム更新方法において、
    　前記旧プログラムおよび前記第二の識別子群は、前記メモリの最小消去単位の大きさに応じた余剰領域をそれぞれ有することを特徴とする車載プログラム更新方法。
PCT/JP2022/011768 2022-03-16 2022-03-16 車載プログラム更新システム、車載プログラム更新方法 WO2023175752A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2024507278A JPWO2023175752A1 (ja) 2022-03-16 2022-03-16
PCT/JP2022/011768 WO2023175752A1 (ja) 2022-03-16 2022-03-16 車載プログラム更新システム、車載プログラム更新方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/011768 WO2023175752A1 (ja) 2022-03-16 2022-03-16 車載プログラム更新システム、車載プログラム更新方法

Publications (1)

Publication Number Publication Date
WO2023175752A1 true WO2023175752A1 (ja) 2023-09-21

Family

ID=88022485

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/011768 WO2023175752A1 (ja) 2022-03-16 2022-03-16 車載プログラム更新システム、車載プログラム更新方法

Country Status (2)

Country Link
JP (1) JPWO2023175752A1 (ja)
WO (1) WO2023175752A1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006025347A (ja) * 2004-07-09 2006-01-26 Sanyo Electric Co Ltd 携帯端末
JP2010211295A (ja) * 2009-03-06 2010-09-24 Mitsubishi Electric Corp データ更新装置、データ更新装置のデータ更新方法およびデータ更新プログラム
JP2016170471A (ja) * 2015-03-11 2016-09-23 日立オートモティブシステムズ株式会社 電子制御装置
JP2019139473A (ja) * 2018-02-09 2019-08-22 株式会社デンソー 配布対象データの配布システム、及び配布対象データの取得方法
JP2020201587A (ja) * 2019-06-06 2020-12-17 京セラ株式会社 撮像装置、車両及びプログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006025347A (ja) * 2004-07-09 2006-01-26 Sanyo Electric Co Ltd 携帯端末
JP2010211295A (ja) * 2009-03-06 2010-09-24 Mitsubishi Electric Corp データ更新装置、データ更新装置のデータ更新方法およびデータ更新プログラム
JP2016170471A (ja) * 2015-03-11 2016-09-23 日立オートモティブシステムズ株式会社 電子制御装置
JP2019139473A (ja) * 2018-02-09 2019-08-22 株式会社デンソー 配布対象データの配布システム、及び配布対象データの取得方法
JP2020201587A (ja) * 2019-06-06 2020-12-17 京セラ株式会社 撮像装置、車両及びプログラム

Also Published As

Publication number Publication date
JPWO2023175752A1 (ja) 2023-09-21

Similar Documents

Publication Publication Date Title
CN112953820B (zh) 网关装置、固件更新方法以及存储介质
CN110244958B (zh) 用于更新车辆的标定数据的方法和装置
US11263001B2 (en) Car onboard control device and program updating software
CN103744712A (zh) 一种应用程序的更新方法及装置
WO2019123747A1 (ja) 自動車用電子制御装置及びその制御方法
US12050903B2 (en) OTA master, system, method, non-transitory storage medium, and vehicle
US20220391192A1 (en) Ota master, center, system, method, non-transitory storage medium, and vehicle
US20220405083A1 (en) Ota master, system, method, non-transitory storage medium, and vehicle
WO2023175752A1 (ja) 車載プログラム更新システム、車載プログラム更新方法
US11954480B2 (en) Center, OTA master, system, method, non-transitory storage medium, and vehicle
US11947824B2 (en) Electronic control unit, method, and program
US20220244946A1 (en) Ota master, update control method, non-transitory storage medium, and vehicle
JP7559600B2 (ja) Ｏｔａマスタ、センタ、システム、方法、プログラム、及び車両
US12067381B2 (en) Center, update management method, and non-transitory storage medium
JP7540401B2 (ja) センタ、ｏｔａマスタ、方法、プログラム、及び車両
WO2020241473A1 (ja) 演算処理装置、車両制御装置及び更新方法
JP2022170949A (ja) 制御装置およびデータ書き換え方法
US20230143921A1 (en) Electronic control system, storage medium storing data structure of software package, and storage medium storing computer program
WO2024062897A1 (ja) 制御システム及びソフトウェア更新方法
CN114764339A (zh) 中心、管理方法以及非暂时性存储介质
JP2022187056A (ja) ソフトウエア特定装置
JP2022133732A (ja) センター装置及び車載電子制御装置
JP2022163479A (ja) 車両用電子制御装置、書換えプログラム及びデータ構造

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2024507278

Country of ref document: JP