Software specific device

Abstract

To specify software to be written in a computer after replacement when replacing a computer installed in a vehicle with another computer in which software written in the computer cannot be used.SOLUTION: A management tool 160 acquires an identification number of a vehicle 150 and an article-number of an ECU 152 from the ECU 152 that is incorporated in the vehicle after replacement and sends an inquiry including such information to a software management system 100. The software management system 100 obtains an article-number of software written into the ECU 152 of the vehicle 150 before replacement from an individual vehicle DB 110, and obtains an article-number of software to be written into the ECU 152 after replacement corresponding to a combination of an article-number of the ECU 152 after replacement and the obtained article-number of the software before replacement from condition information 122.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to an apparatus for identifying software to be written into a replaced computer when the computer installed in a vehicle is replaced. [Background technology]

[0002] Automobiles and other vehicles are controlled by computers called ECUs (Electronic Control Units).Vehicles are equipped with various types of ECUs for various types of control, such as engine control, motor control, brake control, car audio, and navigation.

[0003] An ECU has a built-in non-volatile storage device such as a flash memory. Various programs that describe the processes to be executed by the ECU and software such as data used when executing these programs are written in the non-volatile storage device. The ECU realizes the desired control or information processing function by executing the programs stored in the non-volatile storage device using a built-in processor.

[0004] At the vehicle factory, ECUs are installed in vehicles during production, and the necessary software is written into the installed ECUs. Then, during the inspection stage before the vehicle leaves the factory, it is checked whether the appropriate software is written into each of the various ECUs installed in the vehicle.

[0005] After a vehicle is shipped from the factory, the ECU installed in the vehicle may be replaced for some reason, for example, at a vehicle dealership. A worker at the dealership downloads the same software that was written in the previous ECU from a server operated by the vehicle manufacturer, and writes it into the new ECU installed in the vehicle.

[0006] A technology for rewriting a program installed in an ECU of a vehicle is disclosed in Patent Document 1. In this technology, specification data required for updating the ECU program is generated by a center device, and the specification data is transmitted to the vehicle, where the data is used to perform the update.

[0007] In addition, the device described in Patent Document 2 includes an acquisition means for acquiring an ECU program of an on-board ECU via communication when a vehicle diagnostic device (dummy ECU) that performs fault diagnosis of an on-board ECU is replaced with the on-board ECU, and a control means for controlling on-board equipment that was controlled by the on-board ECU using the ECU program. [Prior art documents] [Patent documents]

[0008] [Patent Document 1] JP 2020-27669 A [Patent Document 2] JP 2006-349430 A Summary of the Invention [Problem to be solved by the invention]

[0009] If the replaced ECU has the same part number as the original ECU (i.e., the hardware configuration is the same), there is no problem in writing the same software that was written in the original ECU to the replaced ECU.

[0010] On the other hand, ECU designs are constantly being improved, and it is common for multiple types of ECUs with the same purpose but different hardware configurations to be in circulation at the same time. There are cases where it becomes necessary or beneficial to replace an ECU installed in a vehicle with an ECU with the same purpose but different part number.

[0011] However, even if ECUs are interchangeable, it is not always possible to use the same software. Of course, some ECUs with different part numbers from the ECU before replacement can use the same software, but some cannot. For example, software that is available on one ECU may not be available on the other ECU due to differences in processor, memory capacity, non-volatile storage capacity, OS (operating system), etc.

[0012] Therefore, in the conventional method of downloading the same software as that written in the old ECU and writing it to the new ECU, it was only possible to replace the old ECU with one that could use the software written in the old ECU.If there were such a restriction on the ECUs that could be replaced, it was not possible to replace the old ECU until an ECU that could use the same software was available, or it was not possible to replace the old ECU with a higher performance ECU for the same purpose, which could reduce convenience. [Means for solving the problem]

[0013] The software identification device according to the present invention includes a first means for obtaining first information for identifying a first computer installed in a vehicle and second information for identifying software written in a second computer that was installed in the vehicle before the first computer, and a second means for identifying second software corresponding to the software to be written in the first computer based on the first information and the second information. The first means receives an inquiry including vehicle identification information of the vehicle and the first information from an inquiry source, and obtains, as the second information, the identification information corresponding to the vehicle identification information included in the inquiry from a database that stores the vehicle identification information and identification information that identifies software written in a computer installed in the vehicle corresponding to the vehicle identification number. . Effect of the Invention

[0014] According to the present invention, when a second computer installed in a vehicle is replaced with a first computer in which the software written in the second computer cannot be used, it is possible to identify the software to be written in the replaced first computer. [Brief description of the drawings]

[0015] [Figure 1] FIG. 1 illustrates a system for downloading and writing software to an ECU. [Diagram 2] FIG. 2 is a diagram showing data registered in a vehicle DB (database). [Diagram 3] FIG. 13 is a diagram showing an example of condition information stored in a software management DB. [Figure 4] 11 is a diagram illustrating a processing procedure executed by a determination unit; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] Hereinafter, modes for carrying out the present invention (hereinafter referred to as embodiments) will be described with reference to the drawings.

[0017] FIG. 1 illustrates an example of a system configuration according to this embodiment.

[0018] 1, the software management system 100 is a system that manages software (hereinafter abbreviated as "software") that is written to an ECU 152 mounted on a vehicle 150 at a factory that manufactures the vehicle 150 or at a dealer that sells or maintains the vehicle 150. Software written to the ECU 152 at the vehicle factory or dealer in this way is also called after-write software. Base software, which is basic software such as an OS, is written in the ECU 152 in advance by, for example, the manufacturer of the ECU 152, and after-write software, which is an application that runs on this base software, is created by the vehicle manufacturer and written to the ECU 152 at the factory or dealer.

[0019] ECU 152 has a built-in microcomputer, and the microcomputer includes, as hardware, a processor, a RAM (random access memory), a ROM (read only memory), a non-volatile storage device (e.g., flash memory), etc. The base software is stored in the ROM, for example. Postscript software is written to the non-volatile storage device in ECU 152. In the following, the postscript software written to the non-volatile storage device of ECU 152 will be simply called "software" to avoid complication.

[0020] The term "software" as used herein typically refers to one program or a set of multiple programs, but is not limited to this. Data such as configuration data used to execute a program, and a set of a program and the data used to execute that program are also examples of software.

[0021] The software management system 100 is constructed as a system consisting of, for example, a single server or a plurality of computers that cooperate with each other, such as a cloud service. The computer here has a circuit configuration in which, for example, a processor, a memory (main storage device) such as a random access memory (RAM), a controller that controls an auxiliary storage device that is a non-volatile storage device such as a flash memory, an SSD (solid state drive), or an HDD (hard disk drive), an interface with various input / output devices, a network interface that controls connection to a network such as a local area network, and the like are connected via a data transmission path such as a bus. A program in which the contents of the processing of the above embodiment are described is installed in the computer via a network or the like and stored in the auxiliary storage device. The program stored in the auxiliary storage device is executed by the processor using the memory, thereby forming the software management system 100 of this embodiment.

[0022] The software management system 100 is capable of communicating with a management tool 160 operated by an operator via a communication line such as the Internet or a dedicated line.

[0023] The software management system 100 includes, as functional elements, a reception unit 102, a determination unit 104, a provision unit 106, an individual vehicle DB (database) 110, and a software management DB 120.

[0024] The reception unit 102 receives an inquiry about software to be written from a management tool 160 that writes software to the ECU 152. The determination unit 104 determines the software to be written in response to the inquiry. The provision unit 106 provides the determined software to the management tool 160.

[0025] The individual vehicle DB 110 is a database that stores and manages data on individual vehicles. As shown in Fig. 2, the individual vehicle DB 110 registers, for each individual vehicle, the software product numbers of one or more pieces of software written in the ECU 152 of the vehicle in association with the VIN of the vehicle. The VIN (Vehicle Identification Number) is an identification number for each individual vehicle and is a type of vehicle identification information. The software product number is a number assigned to each piece of software of the same type for management purposes.

[0026] The software product number registered in the individual vehicle DB 110 in association with the vehicle's VIN is the product number of software written in the ECU 152 currently installed in the vehicle 150. In a situation assumed in this embodiment, this currently installed ECU 152 is replaced with another ECU 152 at a dealer or the like. From the perspective of the replaced ECU 152, the software product number registered in the individual vehicle DB 110 indicates the product number of the software that was written in the ECU 152 before the replacement.

[0027] That is, the data in the column of the product number of the software written in the ECU in FIG. 2 is one implementation example of the identification information that identifies the software written in the computer installed in the vehicle.

[0028] In addition to the above-mentioned software product number, various other information related to the vehicle is registered in the individual vehicle DB 110, but since this information is not particularly relevant to the processing of the embodiment, a description thereof will be omitted.

[0029] Generally, a vehicle 150 is equipped with a plurality of ECUs 152 according to their applications. In addition, one or more pieces of software are written in each of the plurality of ECUs 152. The individual vehicle DB 110 may be in a format in which the product number of the software written in each ECU 152 installed in the individual vehicle 150 is registered for that ECU 152. However, this is not essential. The example shown in FIG. 2 is in a format in which the product numbers of the software written in any of the ECUs 152 of the vehicle 150 are listed in association with the VIN of the vehicle 150, without distinguishing between the ECUs 152. In a general environment in which software with the same software product number is not written in different ECUs 152 in the same vehicle 150 (i.e., the same software does not operate in multiple ECUs 152), the format shown in FIG. 2 functions without any inconsistencies.

[0030] The software management DB 120 is a database that manages information on software to be written to the ECU 152. The software management DB 120 stores, in association with a software product number, entity data (e.g., programs, setting data, etc.) of the software identified by the software product number. The software management DB 120 also stores condition information 122. The condition information 122 is information that represents conditions for determining software corresponding to an inquiry from the management tool 160. The system of this embodiment is provided with this condition information 122, thereby making it possible to determine the software to be written to the replaced ECU 152.

[0031] Fig. 3 shows an example of the condition information 122. The condition information 122 shown in Fig. 3 is in the form of a table that determines one output according to a combination of two inputs. One row of the record in the table shown in Fig. 3 indicates one condition.

[0032] The two entries in the record are (a) the part number of the replaced ECU in the first column of the table, and (b) the part number of the software written in the ECU before replacement in the second column. (a) is read from the replaced ECU 152 installed in the vehicle 150. (b) is searched for in the individual vehicle DB 110 using the VIN read from the replaced ECU 152 as a key.

[0033] The output data shown in the third column of the table is the product number of the software to be written into the replaced ECU 152, which corresponds to the combination of two inputs in the same row of the table.

[0034] In addition, when the replaced ECU 152 is called the first computer, the replaced ECU 152 can be said to be the second computer that was installed in the vehicle 150 before the first computer. In this case, the above-mentioned (a) part number of the replaced ECU is an example of the first information that identifies the first computer. Also, (b) part number of the software written in the replaced ECU is an example of the second information that identifies the software written in the second computer that was installed in the vehicle before the first computer. Also, the part number of the software to be written in the replaced ECU 152 in the third column of the table is information that identifies the second software to be written in the first computer. Here, the second software is software for the first computer that corresponds to the software written in the second computer that was installed in the vehicle before the first computer.

[0035] When software for an existing ECU cannot be used for a newly developed ECU, software for the newly developed ECU that corresponds to the software for the existing ECU is developed. For example, a developer of the software (e.g., the software development department of a vehicle manufacturer) adds a record including the part number of the newly developed ECU, the part number of the software for the existing ECU, and the part number of the software for the newly developed ECU to the condition information 122.

[0036] Here, the product number of the ECU 152 is a number assigned for management purposes to each of the same type of ECU 152. In addition, software for an existing ECU may be "unusable" for a newly developed ECU if the software cannot be executed on the newly developed ECU due to differences in the processor, memory capacity, OS, etc., if the capacity of the non-volatile storage device of the newly developed ECU is insufficient to write the software, etc.

[0037] In one example, if it is acceptable to write the same software as that written in the pre-replacement ECU 152 to the post-replacement ECU 152, it is not necessary to incorporate records for the combination of the pre-replacement ECU 152 and the software into the condition information 122. The processing procedure in Fig. 4, which will be described later, corresponds to this example.

[0038] As another example, even in such a case, a record may be incorporated into the condition information 122. In this example record, the software part number written in the ECU before replacement in the second row is the same as the software part number to be written in the ECU after replacement in the third row.

[0039] 3 is merely an example. Condition information 122 may be in any format as long as it can identify the part number of the software to be written to replaced ECU 152 from a combination of the part number of replaced ECU 152 and the part number of the software written to ECU 152 before replacement.

[0040] Returning to the explanation of Fig. 1, the management tool 160 is a terminal used by a worker at a dealer or the like to inspect and maintain the ECU 152 installed in the vehicle 150. The management tool 160 has a built-in computer equipped with a data communication function, and performs data communication with the ECU 152 installed in the vehicle via a communication cable or wireless communication. Through this data communication, the ECU 152 is inspected and software is written to the ECU 152.

[0041] When the worker finishes replacing the ECU 152 installed in the vehicle 150 with another ECU 152, the worker connects the management tool 160 to the newly installed replaced ECU 152. The worker then operates the management tool 160 to execute a process of writing software to the ECU 152. Below, an overview of the process that is performed in response to an instruction to start the execution of this writing process will be described in the order of steps (1) to (5) shown in FIG. 1.

[0042] (1) Upon receiving an instruction to start execution of this writing process, the management tool 160 queries the ECU 152 for the VIN of the vehicle 150 and the model number of the ECU 152, and acquires this information from the ECU 152. The VIN of the vehicle 150 is written in the ECU 152 in advance, or the ECU 152 acquires it from another device in the vehicle 150 (e.g., another ECU 152).

[0043] (2) The management tool 160 inquires of the software management system 100 via the network about the software to be written into the ECU 152. This inquiry includes information on the VIN acquired from the ECU 152 and the part number of the replaced ECU 152.

[0044] (3) The reception unit 102 of the software management system 100 receives this inquiry. The determination unit 104 determines the software to be written into the ECU 152 from the VIN and the part number of the replaced ECU 152 included in the inquiry. This determination process will be described later with reference to the flowchart of FIG.

[0045] (4) The providing unit 106 acquires the entity data of the software determined by the determining unit 104 from the software management DB 120, and returns the entity data to the management tool 160 via the network.

[0046] (5) The management tool 160 writes the returned software entity data into the non-volatile storage device of the ECU 152 .

[0047] Next, an example of the procedure of the process executed by the software management system 100 in response to an inquiry from the management tool 160 will be described with reference to Fig. 4. The example in Fig. 4 shows a procedure corresponding to the case where the same software as that written in the ECU 152 before replacement may be written in the replaced ECU 152, but the record for the combination of the ECU 152 before replacement and the software is not incorporated in the condition information 122.

[0048] In this procedure, the reception unit 102 receives an inquiry from the management tool 160 (S10). The determination unit 104 receives information on the VIN and the part number of the replaced ECU 152 included in the inquiry. The determination unit 104 then searches the individual vehicle DB 110 (see FIG. 2) for a software part number corresponding to that VIN (S12). At this point, the software part number stored in the individual vehicle DB 110 in association with that VIN is that of the software that was written in the ECU 152 before replacement. In this step, the part numbers of all software written in the multiple ECUs 152 mounted on the vehicle 150 corresponding to that VIN are searched for. The software written in the multiple ECUs 152 includes the software written in the pre-replacement ECU 152 that was the replacement target of the replaced ECU 152 whose part number was obtained in S10.

[0049] Next, the determination unit 104 searches the condition information 122 (see FIG. 3) for a record having the part number of the replaced ECU 152 included in the inquiry and the software part number searched in step S12 (i.e., the software part number before replacement) in the first and second columns, respectively (S14). The third column of the record searched in this step is the part number of the software to be written to the replaced ECU 152, which corresponds to the combination of the values ​​in the first and second columns.

[0050] Here, the replaced ECU 152 has one part number, but in step S12, multiple software part numbers may be searched for. Multiple software part numbers are searched for when there is multiple software written in the pre-replaced ECU 152 that corresponds to the replaced ECU 152. If there are N pre-replacement software part numbers (N is an integer equal to or greater than 1), then there are N combinations of the part number of the replaced ECU 152 and the pre-replacement software part numbers. In step S14, for each of these N combinations, a search is made for a record in which the combination in the first and second columns of the table matches that combination. That is, in this step, for each piece of software written in the pre-replaced ECU 152, the part number of the software that corresponds to that software and should be written in the replaced ECU 152 is found.

[0051] The subsequent steps S16 to S20 are executed for each combination. That is, the determination unit 104 determines whether or not the third column corresponding to the combination, that is, the product number of the software to be written into the replaced ECU 152, has been found (S16).

[0052] In this example, if the software indicated by the software part number before replacement in that combination may be written to the replaced ECU 152, there is no record including that combination in the condition information 122. In this case, the determination result in step S16 is No (i.e., unable to be found). In this case, the determination unit 104 obtains entity data of the software indicated by the software part number included in that combination (i.e., the software part number before replacement) from the software management DB 120, and the provision unit 106 responds to this to the management tool 160 via the network (S18).

[0053] On the other hand, if the judgment result in step S16 is Yes, the judgment unit 104 obtains from the software management DB 120 the actual data of the software indicated by the software product number searched for in S14 (i.e., the replaced software product number), and the provision unit 106 responds to this data to the management tool 160 via the network (S20).

[0054] The software entity data provided in step S18 or S20 is written by the management tool 160 into the replaced ECU 152.

[0055] Furthermore, when the software management system 100 writes, in step S20, different software corresponding to the software written in the ECU 152 before replacement, to the replaced ECU 152, it updates the individual vehicle DB 110 (see FIG. 2). That is, the software management system 100 rewrites the software part number before replacement in the "Software part number written in ECU" column corresponding to the VIN of the vehicle 150 in FIG. 2 to the software part number of the software provided in S20. For software for which step S18 rather than step S20 was executed, it is not necessary to update the individual vehicle DB 110. Note that this update may be performed after the necessary software is written to the replaced ECU 152, the writing result is read and inspected by the management tool 160, and it is confirmed that the software has been written correctly.

[0056] 4 is a procedure for the case where the same software as that written in the ECU 152 before replacement may be written in the replaced ECU 152, but records corresponding to the combination of the ECU 152 before replacement and the software are not incorporated into the condition information 122. In contrast, in an example where records corresponding to the combination of the ECU 152 before replacement and the software are incorporated into the condition information 122 even in such a case, the processing of the software management system 100 becomes simpler. That is, in this example, the determination unit 104 can search for the software part number to be written in the replaced ECU 152 in step S14, and then obtain the software with the searched software part number from the software management DB 120 and provide it to the management tool 160 via the providing unit 106.

[0057] In the example described above, the software management system 100 has entity data for each piece of software, identifies the software corresponding to an inquiry from the management tool 160, and returns the entity data for that software to the management tool 160. However, this configuration is merely one example. As another example, the software management system 100 may not have entity data for each piece of software, but may identify the software corresponding to an inquiry from the management tool 160, and return the product number of that software to the management tool 160. In this example, the management tool 160 sends the inquiry including the software product number returned from the software management system 100 to another server that holds the entity data for the software, and obtains the entity data from that server. [Explanation of symbols]

[0058] 100 software management system, 102 reception unit, 104 judgment unit, 106 provision unit, 110 individual vehicle DB, 120 software management DB, 122 condition information, 150 vehicle, 152 ECU, 160 management tool.

Claims

[Claim 1] a first means for obtaining first information for identifying a first computer installed in a vehicle and second information for identifying software written in a second computer installed in the vehicle before the first computer; a second means for specifying a second software corresponding to the software to be written to the first computer based on the first information and the second information; Including, The first means comprises: receiving an inquiry including vehicle identification information of the vehicle and the first information from an inquiry source; obtaining, as the second information, from a database storing the vehicle identification information and identification information for identifying software written in a computer installed in a vehicle corresponding to the vehicle identification number, the identification information corresponding to the vehicle identification information included in the inquiry; A software specifying device comprising:

Images