Software updating device, software updating method, and software updating program

Abstract

Provided are a software update device, a software update method, and a software update program for updating software without limiting an automatic driving function during automatic driving.SOLUTION: The software update devices 11 to 14 control software update by instructing the target device 20, in which first software that performs predetermined processing on an input value input at a constant cycle and outputs an output value and second software that is software of a version different from the first software and performs predetermined processing on an input value and outputs an output value are installed, to switch between the first software and the second software. The first software includes a gap time acquisition unit 101 that acquires a gap time dt that is a period excluding a processing period from an input time of an input value to an output time of an output value, and a switching instruction unit 102 that instructs switching of software in the gap time when the gap time is longer than a required switching time dk.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to a software update device, a software update method, and a software update program (hereinafter collectively referred to as a software update device, etc.) for controlling software updates by mainly instructing switching between first software and second software. Specifically, the present invention relates to a software update device, etc., installed in an in-vehicle electronic control system, in which the first software and the second software are applications related to autonomous driving. [Background technology]

[0002] Automobiles are equipped with various electronic control units connected via an in-vehicle network. With the recent development of autonomous driving technology, the functions required of automobiles are becoming more complex, and the number of electronic control units installed in automobiles is increasing.

[0003] In order to perform autonomous driving, various autonomous driving-related software is executed in the electronic control unit, but in order to continue autonomous driving properly, it is desirable to be able to update the software in real time.

[0004] To solve this problem, for example, Patent Document 1 describes a method in which, if an update status for autonomous driving-related software is detected while the vehicle is in autonomous driving mode, the autonomous driving functions are restricted and the software is updated. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] WO2021 / 024589 publication Summary of the Invention [Problem to be solved by the invention]

[0006] However, the invention described in Patent Document 1 does not allow software to be updated while in autonomous driving mode without restricting the autonomous driving function.

[0007] As a result of investigation, the present inventors have found the following problems. FIG. 20(a) shows how hardware and software for performing automatic driving of a vehicle are executed. Vehicles are equipped with various sensors for autonomous driving. These sensors are mainly implemented as hardware. Drivers for controlling and operating the sensors and various applications that perform predetermined processing using the output values ​​of the drivers as input values ​​are implemented as software and run on the electronic control system installed in the vehicle. Examples of sensors include a camera, a 3D-LiDAR, a millimeter wave sensor, an acceleration sensor, and a GPS sensor. An example of the driver is a dedicated or general-purpose driver corresponding to each sensor. Examples of applications include an image recognition application, a three-dimensional object recognition application, a white line recognition application, a surrounding recognition application, a self-position estimation application, a map generation application, and a vehicle-to-vehicle communication application.

[0008] FIG. 20(b) shows the process for performing automatic driving of the vehicle. As an example of processing within the sensor, first, communication is confirmed for information inside and outside the vehicle, and after communication is confirmed, sensor data related to that information is output to the driver at a subsequent stage. As an example of processing within a driver, the sensor data output from various sensors in the previous stage is used as an input value, and the driver performs the required processing to control and operate the various sensors, and outputs, for example, a ROS message as an output value to the application in the subsequent stage. After outputting the output value, the driver waits for the next input value to be input. As an example of processing within an application, input values ​​such as ROS messages output from a driver in the previous stage are processed according to the purpose of the application, and the ROS messages are output as output values ​​to another application in the subsequent stage or a GUI (Graphical User Interface), etc. After outputting the output value, the application waits for the next input value to be input. In this way, the processes performed by the driver and applications for autonomous driving tend to be the same processes repeated at regular intervals.

[0009] However, during autonomous driving, the gap time, which is the time between when a driver or application performs a predetermined process and outputs an output value and when it waits for the next input value, is often relatively short. The inventors of the present application have noticed that if a method can be found to update software using this gap time, it will be possible to update software without restricting autonomous driving functions.

[0010] An object of the present invention is to update software using spare time. More specifically, the object is to provide a software update device or the like that can update software without stopping the processing for performing automatic driving, even during automatic driving mode. [Means for solving the problem]

[0011] In order to solve the above problems, the software update device of the present invention comprises: A software update device that controls software update by instructing a target device (20) in which first software that performs predetermined processing on input values ​​input at a constant cycle and outputs an output value, and second software that is software of a different version from the first software and performs predetermined processing on the input values ​​and outputs an output value, to switch between the first software and the second software, a gap time acquisition unit (101) in the first software that acquires a gap time (dt) that is a period excluding a processing period from an input time of the input value to an output time of the output value; a switching instruction unit (102) that instructs switching from the first software to the second software during the gap time (dt) if the gap time (dt) is longer than a switching required time (dk) for switching from the first software to the second software; It has. [Effects of the Invention]

[0012] According to the software update device of the present invention, software can be updated during spare time. More specifically, the software can be updated by comparing the gap time dt with the required switching time dk for switching from the first software to the second software, and issuing a command to switch the software based on the comparison result. This makes it possible to update the software even during autonomous driving. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 illustrates the layout of a software update device, etc. [Figure 2] A diagram explaining the relationship between a software update device and an electronic control system (electronic control device). [Figure 3] A diagram illustrating an example of the configuration of an electronic control system. [Figure 4] FIG. 1 is a diagram illustrating a software update device that is a common configuration of the present embodiment. [Figure 5] FIG. 1 is a diagram illustrating the operation of the software according to the first embodiment. [Figure 6] 1 is a block diagram illustrating the configuration of a software update device according to a first embodiment of the present invention. [Figure 7] FIG. 1 is a diagram illustrating software switching in the software update device of the first embodiment. [Figure 8] Flowchart showing the software update method according to the first embodiment [Figure 9] FIG. 10 is a diagram illustrating the operation of the software according to the second embodiment. [Figure 10] 10 is a block diagram illustrating the configuration of a software update device according to a second embodiment of the present invention. [Figure 11] Flowchart showing the software update method according to the second embodiment [Figure 12] FIG. 10 is a diagram illustrating the operation of the software according to the third embodiment. [Figure 13] FIG. 10 is a diagram illustrating the operation of the software according to the third embodiment. [Figure 14] 10 is a block diagram illustrating the configuration of a software update device according to a third embodiment of the present invention. [Figure 15] Flowchart showing a gap time calculation method according to the third embodiment [Figure 16] FIG. 10 is a diagram for explaining the operation of the software according to the fourth embodiment. [Figure 17] 10 is a block diagram illustrating the configuration of a software update device according to a fourth embodiment of the present invention. [Figure 18] FIG. 10 is a diagram illustrating software switching in the software update device of the fourth embodiment. [Figure 19] Flowchart showing the software update method according to the fourth embodiment [Figure 20] Diagram explaining the conventional problems DETAILED DESCRIPTION OF THE INVENTION

[0014] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0015] The present invention refers to the inventions described in the claims or in the Summary of the Invention section, and is not limited to the following embodiments. Furthermore, at least the words in quotation marks refer to the words described in the claims or in the Summary of the Invention section, and are not limited to the following embodiments.

[0016] The configurations and methods recited in the dependent claims are optional configurations and methods in the inventions recited in the independent claims. The configurations and methods of the embodiments corresponding to the configurations and methods recited in the dependent claims, as well as the configurations and methods recited only in the embodiments without being recited in the claims, are optional configurations and methods in the present invention. The configurations and methods recited in the embodiments when the recitation of the claims is broader than the recitation of the embodiments are also optional configurations and methods in the present invention, in the sense that they are examples of the configurations and methods of the present invention. In either case, by being recited in the independent claims, they become essential configurations and methods of the present invention.

[0017] The effects described in the embodiments are effects obtained when the configurations of the embodiments are provided as examples of the present invention, and are not necessarily effects that the present invention has.

[0018] When there are multiple embodiments, the configurations disclosed in each embodiment are not limited to each embodiment, but can be combined across the embodiments. For example, a configuration disclosed in one embodiment may be combined with another embodiment. Also, configurations disclosed in multiple embodiments may be collected and combined.

[0019] The problem described in the section on the problem to be solved by the invention is not a publicly known problem, but was discovered independently by the inventor, and this fact, together with the configuration and method of the present invention, affirms the inventive step of the invention.

[0020] 1. Configuration underlying each embodiment (1) The location of the software update device and the target device on which the software is installed FIG. 1 is a diagram illustrating the layout of software update devices according to the respective embodiments. For example, as shown in FIG. 1(a), a software update device 11 according to the first embodiment, a software update device 12 according to the second embodiment, a software update device 13 according to the third embodiment, and a software update device 14 according to the fourth embodiment (hereinafter abbreviated as the software update device 11, etc.) are "mounted" on a vehicle, which is a "mobile body." Alternatively, as shown in FIG. 1(b), the software update device 11, etc. may not necessarily be "mounted" on a "mobile body." An example of the form of the software update device 11, etc. in FIG. 1(a) is an electronic control unit (ECU), but is not limited thereto. Furthermore, an example of the form of the software update device 11, etc. in FIG. 1(b) is a personal computer (PC) or a smartphone, but is not limited thereto. where: "Mobile object" refers to an object that can move at any speed. It also includes cases where the object is stationary. Examples include, but are not limited to, automobiles, motorcycles, bicycles, pedestrians, ships, aircraft, and objects mounted on these. "Mounted" includes not only cases where the device is directly fixed to the mobile body, but also cases where the device is not fixed to the mobile body but moves with the mobile body. For example, cases where the device is carried by a person riding on the mobile body, or cases where the device is mounted on cargo placed on the mobile body, are included.

[0021] 2 is a diagram illustrating the arrangement of the software update device 11, etc., of each embodiment and the electronic control system S. The software update device 11, etc., of each embodiment is "connected" to a plurality of "electronic control devices" 20 (hereinafter referred to as ECUs (Electronic Control Units)) that constitute the electronic control system S. where: The "electronic control device" may be a physically independent electronic control device, or may be a virtualized electronic control device realized using virtualization technology. "Connection" refers to a state in which data can be exchanged, and includes not only cases in which different hardware is connected via a wired or wireless communication network, but also cases in which virtual machines realized on the same hardware are virtually connected.

[0022] 2(a) shows a case where the software update device 11 and the like are provided inside the electronic control system S, and FIG. 2(b) shows a case where the software update device 11 and the like are provided outside the electronic control system S and inside the vehicle. In other words, the software update device 11 and the like are "mounted" on a "mobile body" together with the ECU 20. In the cases of FIGS. 2(a) and 2(b), the software update device 11 and the like and the multiple ECUs 20 are connected via an in-vehicle communication network such as a CAN (Controller Area Network) or a LIN (Local Interconnect Network). Alternatively, they may be connected using any communication method, whether wired or wireless, such as Ethernet (registered trademark), Wi-Fi (registered trademark), or Bluetooth (registered trademark).

[0023] 2(c) shows a case where the software update device 11 and the like are provided outside the electronic control system S and outside the vehicle. That is, the ECU 20 is "mounted" on a "mobile body", and the software update device 11 and the like are arranged outside the mobile body. In the case of FIG. 2(c), the software update device 11 and the like are realized by, for example, a server device. The software update device 11 and the multiple ECUs 20 are connected via a communication network, such as a wireless communication method such as IEEE802.11 (Wi-Fi (registered trademark)), IEEE802.16 (WiMAX (registered trademark)), W-CDMA (Wideband Code Division Multiple Access), HSPA (High Speed ​​Packet Access), LTE (Long Term Evolution), LTE-A (Long Term Evolution Advanced), 4G, or 5G. Alternatively, DSRC (Dedicated Short Range Communication) can be used. When the vehicle is parked in a parking lot or in a repair shop, a wired communication method can be used instead of a wireless communication method. For example, a local area network (LAN), the Internet, or a fixed telephone line can be used.

[0024] (2) Configuration of electronic control system S Fig. 3 is a diagram showing an example of the configuration of an electronic control system S. The electronic control system S is made up of multiple ECUs 20 and an in-vehicle network (NW1 to NW3) that connects these ECUs. Fig. 3 shows eight ECUs (ECU20a to ECU20h) as an example, but the electronic control system S may naturally be made up of any number of ECUs. In the following explanation, when describing one or multiple electronic control devices collectively, they will be referred to as ECU20 or each ECU 20, and when describing individual electronic control devices specifically, they will be referred to as ECU20a, ECU20b, ECU20c, ...

[0025] In the case of FIG. 3, the ECUs 20 are connected to each other via the in-vehicle network described above in the description of FIGS. 2(a) and 2(b), or via other wired or wireless communication methods.

[0026] The electronic control system S shown in FIG. 3 includes an integrated ECU 20a, an external communication ECU 20b, zone ECUs (20c, 20d), and individual ECUs (20e to 20h).

[0027] The integrated ECU 20a is an ECU that has a function of controlling the entire electronic control system S and also has a gateway function of mediating communication between the ECUs 20. The integrated ECU 20a is also called a gateway ECU (G-ECU) or a mobility computer (MC). The integrated ECU 20a may also be a relay device or a gateway device.

[0028] The external communication ECU 20b is an ECU having a communication unit that communicates with an external device provided outside the vehicle, for example, in each embodiment, the external device 30. The communication method used by the external communication ECU 20b is the wireless communication method or the wired communication method described in the explanation of FIG. 2(c). In order to realize a plurality of communication methods, a plurality of external communication ECUs 20b may be provided. Also, instead of providing the external communication ECU 20b, the integrated ECU 20a may include the function of the external communication ECU 20b.

[0029] The zone ECUs (20c, 20d) are ECUs equipped with a gateway function and appropriately arranged according to the locations and functions of the individual ECUs described below. For example, the zone ECU 20c is an ECU with a gateway function that mediates communication between the individual ECUs 20e and 20f arranged at the front of the vehicle and other ECUs 20, and the zone ECU 20d is an ECU with a gateway function that mediates communication between the individual ECUs 20g and 20h arranged at the rear of the vehicle and other ECUs 20. The zone ECUs (20c, 20d) are sometimes referred to as domain computers (DCs). The individual ECUs 20e and 20f are connected to the zone ECU 20c via a network 2 (NW2), and the individual ECUs 20g and 20h are connected to the zone ECU 20d via a network 3 (NW3).

[0030] The individual ECUs (20e to 20h) can be configured with ECUs having any desired functions. Examples include drivetrain electronic control units that control the engine, steering, brakes, etc., body electronic control units that control meters, power windows, etc., information system electronic control units such as navigation systems, and safety control system electronic control units that perform control to prevent collisions with obstacles or pedestrians. Furthermore, the ECUs may be classified as master and slave rather than parallel.

[0031] In the first to fourth embodiments, a case will be described in which the software update device 11 and the like are provided in the integrated ECU 20a. However, the software update device 11 and the like may be provided in the external communication ECU 20b, the zone ECUs (20c to 20d), or the individual ECUs (20e to 20h). When provided in one of the individual ECUs (20e to 20h), it is desirable to use a dedicated ECU for realizing the software update device 11 and the like.

[0032] In addition, in the first to fourth embodiments, the device (corresponding to the "target device") whose software is updated by the software update device 11 or the like is each ECU 20 constituting the electronic control system S. In each of the following embodiments, the ECU 20 whose software is updated will be referred to as the target device 20. The software update device 11, etc. and the target device 20 may be included in the same ECU. For example, the software update device 11, etc. implemented in the integrated ECU 20a may not only manage and control software updates of ECUs 20 other than the integrated ECU 20a, but may also manage and control software updates of the integrated ECU 20a. Alternatively, the software update device 11, etc. (including cases where the software update device 11, etc. has a function equivalent to that of the software update device 11, etc.) may be provided in each of all ECUs 20 in which software is installed.

[0033] 2. Common Configuration of Each Embodiment (Software Update Device) First, the schematic configuration of the software update device 11 and the like of each embodiment will be described with reference to FIG. 4 is a diagram showing an example of the configuration of the software update device 11, etc., which are common to all the embodiments. The software update device 11, etc., includes a spare time acquisition unit 101 and a switching instruction unit 102.

[0034] The software update device 11 and the like are devices that manage and control software updates by instructing the target device 20 (corresponding to the "target device") to "switch" between first software and second software installed therein. The target device 20 itself performs the software switching based on an instruction from the software update device 11 and the like. The method of switching programs may vary depending on the type of software. The switching method when the software is an application will be described in embodiments 1 to 3, and the switching method when the software is a driver will be described in embodiment 4. where: The "target device" may be any device on which software is installed, and may be the same device as the software update device, as well as a device different from the software update device. The "target device" also includes a virtual machine. "Switching" simply means transitioning from a state in which the first software is running to a state in which the second software is running, and the switching method and process are arbitrary.

[0035] Software is a collection of programs and data that give commands to a computer and cause it to execute specific tasks or functions. Examples of software include applications, operating systems, drivers, etc. used on personal computers, smartphones, etc. Although each embodiment targets software and drivers related to autonomous driving, the software may also be applied to software and drivers unrelated to autonomous driving. Furthermore, software updates include updating software that is in use or on standby, or restoring updated software to its pre-update state. Furthermore, if the software is containerized, it also includes updating a container that is in use or on standby, or restoring an updated container to its pre-update state.

[0036] The first software and the second software are installed in the target device 20. "Installed" refers to a state in which the software is executable, such as a state in which the software is stored in a secondary storage device such as a hard disk, and can be deployed to a main storage device and executed by a predetermined command. The first software performs "predetermined processing" on "input values" that are input at "regular intervals" and outputs an output value. The second software is a different "version" of software from the first software, and performs "predetermined processing" on "input values" that are input at "regular intervals" and outputs an output value. Specific examples of the software and specific examples of the input and output values ​​of the software will be described in each embodiment. where: The term "constant cycle" includes not only a case where the cycle is always constant, but also a case where the cycle changes depending on conditions. A "version" is an index used to identify each piece of software when the content of the software changes due to revision or improvement, and includes, for example, release and revision. The "input value" may be any data required to execute the "predetermined process" described below. For example, it may include the result of a previous process or data transmitted from a sensor. The "predetermined processing" may be any operation or decision that is performed based on input values, such as image recognition processing, traffic light recognition processing, object recognition processing, self-position determination, path planning processing, etc.

[0037] The gap time acquisition unit 101 "acquires" gap time dt, which is the period excluding the processing period from the input time of the input value to the output time of the output value in the first software. In other words, gap time dt is the time from the output time of the output value, which is the result of performing a predetermined process on the input value, to the input time of the next input value in the first software. In the first and fourth embodiments, the case where the pre-calculated gap time dt is received and acquired from the external device 30 or the target device 20 is considered. x In the second and third embodiments, the case where basic information such as the above is received in advance from the external device 30, the target device 20, or another ECU 20, etc., and the gap time dt is obtained by calculation will be described. Here, "obtain" includes not only obtaining by calculation, but also receiving and obtaining something that has been calculated in advance.

[0038] If the gap time dt is longer than the switching time dk required to "switch" from the first software to the second software, the switching instruction unit 102 instructs the target device 20 to switch from the first software to the second software during the gap time. The required switching time dk is a known value measured in advance and stored in, for example, the external device 30. The switching instruction unit 102 may acquire the required switching time dk in advance from the external device 30. For example, when downloading the second software to the target device 20, the required switching time dk may be acquired as additional information of the second software and stored in a storage unit accessible by the switching instruction unit 102. where: The term "than" may mean either a case where the gap time and the required switching time are the same (≧) or a case where they are not (>).

[0039] The software update device 11 and other components will be described in detail below in each embodiment. In the first to fourth embodiments, an example will be described in which one application runs in one container and one driver also runs in one container. That is, an example will be described in which software is updated by replacing the container before the update (referred to as the old container) with the container after the update (referred to as the new container).

[0040] 3. Embodiment 1 (Software Update Device 11: When One Input Value Is Used) (1) Overview and operation of the software used in this embodiment In this embodiment, an example in which one input value is input to software will be described. Specifically, an image recognition application for autonomous driving (hereinafter abbreviated as image recognition app) will be described.

[0041] FIG. 5 is a diagram illustrating the operation of the image recognition application. In FIG. 5(a), the camera image output from the camera driver is used as the first input value I1 of the image recognition application, and the output value I out is output to a downstream application or GUI. In FIG. 5(a), the first input value I1 has a frequency of 10 Hz. The output value I out Similarly, the image recognition application generates an output value I out Output.

[0042] FIG. 5(b) is a diagram illustrating the input / output timing of the image recognition application. In FIG. 5(b), the first reception period dt1, which is the reception period of the input value I1, is 10 Hz, i.e., 100 ms. The reception time of the input value I1 is t1, and the output time of the output value is t out When this is the case, the processing time (t out -t1) is 40 ms. Therefore, the gap time dt is dt=dt1-(tout -t1) =100ms-40ms =60ms This becomes:

[0043] In this embodiment, the processing time for image recognition processing (t out -t1) is 40 ms, and gap time dt is 60 ms. These values ​​may be stored in external device 30 as known values ​​measured in advance by the manufacturer of the image recognition application, and may be received and acquired by gap time acquisition unit 101. Alternatively, the time t1 of receiving the first input value I1 and the time t2 of the output value I2 actually measured in the target device 20 may be calculated. out Output time t out Based on the first reception period dt1, the gap time acquisition unit 101 calculates the processing time (t out -t1) and the gap time dt may be calculated and obtained.

[0044] 5(c), if the gap time dt is longer than the required switching time dk, it is determined that the software update is possible. If the gap time dt is shorter than the required switching time dk, it is determined that the software update is not possible.

[0045] In this embodiment, the gap time dt is on the order of several to several tens of milliseconds, and in such a short time, it is not possible to execute a typical container update method in which the old container is stopped and then a new container is started and executed. Therefore, in this embodiment, the new container is started in parallel with the old container, so that predetermined processing can be executed promptly in the new container based on a switching instruction. Below, an example configuration of the software update device 11 of this embodiment and each step of the update method will be described.

[0046] (2) Configuration of the software update device 11 An example of the configuration of the software updating device 11 of this embodiment will be described with reference to FIG. As shown in FIG. 4, the software update device 11 includes a spare time acquisition unit 101 and a switching instruction unit 102. Furthermore, an old container, which is a first software, and a new container, which is a second software, are installed in the target device 20. In this embodiment, the target device 20 includes a first execution state control unit 1001 that controls the execution state and standby state of the first software, a first processing unit 1002 that executes the first software, a second execution state control unit 1003 that controls the execution state and standby state of the second software, and a second processing unit 1004 that executes the second software. Furthermore, there is only one input value, which is a first input value I1. Furthermore, the external device 30 acquires the gap time by the gap time acquisition unit 101 and stores update parameters, which are information necessary for issuing a switching instruction by the switching instruction unit 102. The update parameters in this embodiment include the gap time dt and the required switching time dk.

[0047] The gap time acquisition unit 101 of the software update device 11 acquires the gap time dt from the external device 30. Instead, the gap time acquisition unit 101 receives a first reception period dt1, a first input time t1 of a first input value I1, an output value I2 as a result of image recognition processing, and the like from the external device 30, the target device 20, or another ECU 20. out Output time t out The gap time dt obtained by the gap time obtaining unit 101 is transmitted to the switching instruction unit 102.

[0048] The switching instruction unit 102 receives the required switching time dk from the external device 30 and receives the gap time dt from the gap time acquisition unit 101. The switching instruction unit 102 compares the gap time dt with the required switching time dk, and if the gap time dt is longer than the required switching time dk, transmits a switching instruction to the target device 20 to instruct switching from the old container to the new container during the gap time. More specifically, the output value I output from the first processing unit 1002 of the target device 20 outThe reception of the command by the switching instruction unit 102 is used as a trigger to transmit a switching instruction to the first execution state control unit 1001 and the second execution state control unit 1003, respectively.

[0049] The first execution state control unit 1001 of the target device 20 switches the first processing unit 1002 to an execution state or a standby state based on the switching instruction transmitted from the switching instruction unit 102. Similarly, the second execution state control unit 1003 switches the second processing unit 1004 to an execution state or a standby state based on the switching instruction. When the first processing unit 1002 is in the running state, the first processing unit 1002 performs predetermined processing by the first software on the input value and outputs the output value. In this embodiment, as described above, the first processing unit 1002 performs image recognition processing on the camera image using the old container and outputs the image recognition result. Similarly, when the second processing unit 1004 is in the running state, the second processing unit 1004 performs predetermined processing by the second software on the input value and outputs the output value. In this embodiment, as described above, the image recognition processing is performed on the camera image using the new container and the image recognition result is output.

[0050] Here, if image recognition processing is performed simultaneously using the old container and the new container and output values ​​are output simultaneously, this may cause problems in the operation of the downstream application or GUI. Therefore, control is performed so that either the first processing unit 1002 or the second processing unit 1004 is in an execution state and the other is in a standby state. In the standby state, no software processing is performed, so no output values ​​are output. This point will be described in detail using FIG. 7.

[0051] FIG. 7 is a diagram for explaining details of the parallel activation and running / standby states of the old container and the new container in the target device 20. In FIG. 7(a) is a diagram illustrating the operation of the target device 20 before receiving a switching instruction, i.e., before an update. Before an update, the first execution status control unit 1001 puts the first processing unit 1002 into an execution state, and the first processing unit 1002 performs predetermined processing using the old container on the input value and outputs an output value. The second execution status control unit 1003 puts the second processing unit 1004 into a standby state, and the second processing unit 1004 does not perform predetermined processing using the new container. In other words, although the new container is running, the new container does not perform predetermined processing on the input value, and no output value is output.

[0052] 7(b) is a diagram illustrating the operation of the target device 20 after receiving a switching instruction, i.e., after the update is completed. Upon receiving a switching instruction from the switching instruction unit 102, the first execution state control unit 1001 switches the first processing unit 1002 from an execution state to a standby state, and stops the predetermined processing by the first processing unit 1002. Upon receiving a switching instruction, the second execution state control unit 1003 switches the second processing unit 1004 from the standby state to an execution state, and the second processing unit 1004 performs predetermined processing using the new container on the input value and outputs the output value.

[0053] In this way, the software can be switched by simply switching the execution state / standby state of the first processing unit 1002 or the second processing unit 1004, which significantly reduces the time required for software update. Therefore, software update is possible even in a short gap time of several ms to several tens of ms.

[0054] After receiving the switching instruction, the first processing unit 1002 is in a standby state, but the old container may then be completely stopped and the old container may be deleted from the target device 20 after a certain period of time has passed.

[0055] Alternatively, the old container may be stopped but not deleted, and if a problem occurs with the new container, the old container may be switched to. In this case, too, the switching may be performed by transmitting a switching instruction to the first execution status control unit 1001 and the second execution status control unit 1002 based on an instruction from the switching instruction unit 102.

[0056] In this case, multiple memory areas are provided in the target device 20 to store new and old containers, and the old container may be deleted when the latest container is downloaded. That is, the target device 20 may have a first memory area in which the first software is stored and a second memory area in which the second software is stored, and after switching from the first software to the second software, the first software may not be deleted from the first memory area, and when installing third software that is a different version from both the first software and the second software, the third software may be overwritten in the first memory area. This allows the device to switch back to the first software and continue execution even if a malfunction occurs in the second software, and allows the two software, new and old, to coexist until the new third software is installed.

[0057] Furthermore, when switching from an old container to a new container, information about the internal state of the application may be carried over. For example, by mounting a common area such as memory in the target device 20 and storing information about the internal state of the application, such as numerical values ​​used in internal calculations for a predetermined process and calculation results for the past few frames, in the common area, the information used in the old container can be used even after switching to the new container.

[0058] (3) Software update method FIG. 8 is a flowchart showing the software update method of this embodiment. The software update device 11 checks the presence or absence of a new container from the container repository, i.e., the presence or absence of an application update (S1001). Here, the container repository is an infrastructure environment that manages new and old containers and update parameters, and is included in the external device 30. The external device 30 including the container repository may itself move as a mobile object. The check for the presence or absence of an update may be performed at regular intervals, for example, once every 10 seconds, or may be performed at a predetermined date and time, or information regarding the update may be received from the external device 30, such as a server.

[0059] Next, if there is an update, i.e., if there is a new container, the new container and update parameters are downloaded from the container repository (S1002). The update parameters are stored in the spare time acquisition unit 101 and the switching instruction unit 102 of the software update device 11, and the new container is stored in the storage of the target device 20, such as an HDD or SSD.

[0060] The switching instruction unit 102 compares the gap time dt with the required switching time dk to determine whether the gap time dt is longer than the required switching time dk (S1003). If the gap time dt is shorter than the switching time dk, the update process is terminated.

[0061] If the gap time dt is longer than the required switching time dk, the new container is started and put into a standby state (S1004). Specifically, the second execution state control unit 1003 instructs the second processing unit 1004 to start the new container, and puts the second processing unit 1004 into a standby state. Alternatively, the new container may be started and put into a standby state regardless of the result of S1003.

[0062] The switching instruction unit 102 receives the output value from the first processing unit 1002 of the target device 20 (S1005). The process waits until the output value is received without proceeding to the next step.

[0063] When receiving the output value from the first processing unit 1002, the switching instruction unit 102 transmits a switching instruction to the target device 20 to instruct switching from the old container to the new container in the gap time dt (S1006). Specifically, the switching instruction unit 102 transmits the switching instruction to each of the first execution state control unit 1001 and the second execution state control unit 1003 of the target device 20.

[0064] Based on the switching instruction, the first execution state control unit 1001 switches the old container from the execution state to the standby state, and causes the first processing unit 1002 to wait without performing a predetermined process (S1007). The second execution state control unit 1003 switches the new container from the standby state to the execution state based on the switching instruction, and causes the second processing unit 1004 to execute a predetermined process (S1008).

[0065] After a certain period of time has elapsed, the first execution status control unit 1001 stops the old container (S1009). After another certain period of time has elapsed, the old container is deleted from the storage of the target device 20. The step of stopping the old container does not need to be executed within the gap time dt.

[0066] (4) Summary As described above, according to the software update device of this embodiment, software switching is instructed when the gap time is longer than the required switching time, so software can be switched during the gap time. In particular, the target device can quickly switch software by switching between the running state and the standby state while both the first software and the second software are running based on the switching instruction.

[0067] 4. Second Embodiment (Software Update Device 12: When Two Input Values ​​Are Used) (1) Overview and operation of the software used in this embodiment In the first embodiment, an example in which one input value is input to the software has been described, but in the present embodiment, a case in which two input values ​​are input will be described. Specifically, a traffic light recognition application will be described.

[0068] 9 is a diagram illustrating the operation of the traffic light recognition application. Hereinafter, the configurations and operations common to those shown in FIGS. 5 to 8 of the first embodiment are assigned the same numbers as those in the first embodiment, and the description of the first embodiment is cited.

[0069] In FIG. 9(a), a camera image output from a camera driver is used as a first input value I1 of a traffic light recognition application, and self-location information output from a self-location application is used as a second input value I2. In FIG. 9(a), the first input value I1 has a frequency of 10 Hz. The second input value I2 has a frequency of 50 Hz. The output value I2 is the recognition result of a predetermined traffic light recognition process performed in the traffic light recognition application. out has a frequency of 10 Hz. In other words, the traffic light recognition application uses the first input value I1 as a trigger to generate the output value I out Output.

[0070] 9(b) is a diagram illustrating the input / output timing of the traffic light recognition application. A method for calculating the gap time dt in this embodiment will be described below. 9(b), the first reception period dt1 of the first input value I1 is 10 Hz, or 100 ms, and the second reception period dt2 of the second input value I2 is 50 Hz, or 20 ms.

[0071] Since the input value with the longest period is the first input value I1, the number (m2) of each input value in the period from t1 to t1+dt1, which is the period of the first input value I1, is calculated. In the example shown in Figure 9, m2 is 5. Here, to explain in detail how to calculate m2, m2 is the largest natural number that satisfies the following formula. m2≦(t1+dt1-t2) / dt2 =(15+100-0) / 20 =5.75 Therefore, m2 is 5. Based on this, the gap time dt is dt=m2×dt2-(t out -t2) =5×20―(55-0) =45ms Therefore, in this embodiment, when dk is shorter than 45 ms, container replacement is performed.

[0072] Note that under certain conditions, such as when the reception period dt1 of the first input value I1 and the reception period dt2 of the second input value I2 are close to each other, the relationship "gap time dt > required switching time dk" may continue to be unsatisfied. Therefore, if this relationship continues to be unsatisfied for a predetermined period of time, for example, after a predetermined number of loops, a restart instruction may be issued to the source of the input values. Specifically, an instruction is issued to restart the upstream camera driver or self-location application associated with at least one of the first input value I1 or the second input value I2. This is because restarting the source driver, etc., may change the relative input timing of the first input value I1 and the second input value I2, potentially resulting in the relationship "gap time dt > required switching time dk" being satisfied. This allows for a prompt software update.

[0073] (2) Configuration of the software update device 11 An example of the configuration of the software update device 12 of this embodiment will be described with reference to FIG. The software update device 12 has a configuration similar to that of the software update device 11 of the first embodiment shown in Fig. 6. The difference from the configuration of the first embodiment is that the spare time acquisition unit 101 receives the reception period dt x and input values ​​I1 and I2 are received, and gap time dt is obtained by calculation, and the input values ​​input to target device 20 are two, a first input value I1 and a second input value I2. Hereinafter, blocks that share functions with blocks in embodiment 1 are assigned the same numbers as the blocks in embodiment 1, and the description of embodiment 1 will be quoted.

[0074] In this embodiment, the gap time acquisition unit 101 receives a first reception period dt1 and a second reception period dt2 from the external device 30, a first input value I1 and a second input value I2 from another ECU 20 or a driver via the in-vehicle network, and an output value I2 as a result of traffic light recognition processing from the first processing unit 1002 of the target device 20. out The time when the first input value I1 is received is defined as the first input time t1, the time when the second input value I2 is received is defined as the second input time t2, and the output value I out The time when the message was received is output at time t out Using this basic information, the gap time dt is calculated using the method explained in FIG. It is also possible to determine the first receiving period dt1 and the second receiving period dt2 from the first input time t1 and the second input time t2 without receiving the first receiving period dt1 and the second receiving period dt2 from the external device 30.

[0075] When the first processing unit 1002 is in the execution state, it performs a predetermined process of traffic light recognition on the first input value I1 and the second input value I2, and outputs an output value I out When the second processing unit 1002 is in the execution state, it performs a predetermined process of traffic light recognition on the first input value I1 and the second input value I2, and outputs an output value I out As in the first embodiment, in the first processing unit 1002 and the second processing unit 1004, the first execution state control unit 1001 and the second execution state control unit 1003 switch between the execution state and the standby state based on a switching instruction from the switching instruction unit 102, so that one of them enters the execution state and the other enters the standby state. For switching between the running state and the waiting state, refer to FIG. 7 and its description.

[0076] (3) Software update method 11 is a flowchart showing the software update method of this embodiment. Hereinafter, operations that are substantially the same as those in the flowchart shown in FIG. 8 of the first embodiment are assigned the same numbers as those in the first embodiment, and the description of the first embodiment will be cited.

[0077] In this embodiment, a new container and update parameters are downloaded from the container repository (S1002). The update parameters include try_max, which specifies the maximum number of update attempts. As mentioned above, depending on the input value period, it may not be possible to satisfy gap time dt > required switching time dk, resulting in an infinite loop. To prevent this, an upper limit for the loop must be set. try_max is information indicating the upper limit for this loop. try_max may be an arbitrary fixed numerical value, or may be a variable numerical value depending on the reception period of each input value.

[0078] After downloading the updated parameters, etc., the new container is started and put into a standby state (S2004).

[0079] The update attempt counter i is initialized to i=0 (S2005). The update attempt counter i is incremented to i=i+1 (S2006). If i<=try_max, proceed to the next step; if not, end the process (S2007).

[0080] The process waits until the output value of the old container application is received (S2008). If the output value is received, the process proceeds to the next step.

[0081] After receiving the output value, the gap time acquisition unit 101 calculates the gap time dt (S2009). The specific calculation method is as explained with reference to FIG.

[0082] The switching instruction unit 102 compares the gap time dt with the required switching time dk and determines whether the gap time dt is longer than the required switching time dk (S2010). If the gap time dt is longer than the required switching time dk, it transmits a switching instruction (S1006). If the gap time dt is shorter than the required switching time dk, it returns to step S2006, increments the update attempt counter i, and repeats steps S2007 to S2010 until the gap time dt exceeds the value of try_max.

[0083] (4) Summary As described above, according to the software update device of this embodiment, even when there are two input values, the gap time is calculated by obtaining the reception time of the input values, the reception period of the input values, and the output time of the output values, so that software switching instructions can be issued at an appropriate time based on the operating status of the target device 20.

[0084] 5. Third Embodiment (Software Update Device 13: When Three or More Input Values ​​Are Included) (1) Overview and operation of the software used in this embodiment In the first embodiment, an example in which one input value is input to the software was described, and in the second embodiment, an example in which two input values ​​are input to the software was described. In this embodiment, however, a case in which three or more input values ​​are input will be described. Specifically, a path planner app will be described. A path planner app is an app that calculates a route for a moving object such as a vehicle to move in the future. Specific route calculation examples of the path planner app include route calculations such as which lane to use and what curvature is required to safely turn right or left, and using an object recognition app to determine whether or not there is an obstacle on a predetermined route and then calculating a route that avoids the obstacle.

[0085] 12 and 13 are diagrams for explaining the operation of the path planner app. Hereinafter, configurations and operations common to those shown in FIGS. 5 to 8 of the first embodiment are given the same numbers as those in the first embodiment, and the explanation for the first embodiment will be cited. Similarly, configurations and operations common to those shown in FIGS. 9 to 11 of the second embodiment are given the same numbers as those in the second embodiment, and the explanation for the second embodiment will be cited.

[0086] In FIG. 12, the object recognition result output from the object recognition application is used as the first input value I1 of the path planner application, the self-location information output from the self-location application is used as the second input value I2, and the CAN information output from the CAN driver is used as the third input value I3. An example of the object recognition result is information such as the position, speed, and orientation of an object around the vehicle. An example of the self-location information is information such as the position, speed, and orientation of the host vehicle. An example of the CAN information is information such as the wheel speed and steering angle of the host vehicle. The first input value I1 has a frequency of 10 Hz. The second input value I2 has a frequency of 50 Hz. The third input value I3 has a frequency of 25 Hz. A path planning process is performed within the path planner application, and route information is input as the output value I out The output value is I out has a frequency of 10 Hz. This means that the Path Planner app will trigger the first input value I1 to generate the output value I out Output.

[0087] 13 is a diagram illustrating the input / output timing of the path planner application. A method for calculating the gap time dt in this embodiment will be described below. 13, the first reception period dt1 of the first input value I1 is 10 Hz, i.e., 100 ms. The second reception period dt2 of the second input value I2 is 50 Hz, i.e., 20 ms. The third reception period dt3 of the third input value I3 is 25 Hz, i.e., 40 ms. Furthermore, the reception times of the input values ​​are t1, t2, and t3, respectively, which are 15 ms, 0 ms, and 5 ms, respectively.

[0088] Since the input value with the longest period is the first input value I1, the number of input values ​​(m2, m3) in the period from t1 to t1+dt1, which is the period of the first input value I1, is calculated. In the example shown in Figure 13, m2 is 5 and m3 is 2. Here, the method for calculating m2 will be explained in detail. m2 is the largest natural number that satisfies the following formula. m2≦(t1+dt1-t2) / dt2 =(15+100-0) / 20 =5.75 Therefore, m2 is 5. Also, the calculation method of m3 will be described in detail. m3 is the largest natural number that satisfies the following formula. m3 ≦ (t1 + dt1 - t3) / dt3 =(15 + 100 - 5) / 40 =2.75 Therefore, m3 is 2.

[0089] Also, the arrival times of the input values to be used next time are as follows. For I2: t2 + m2 × dt2 = 0 + 5 × 20 = 100 ms For I3: t3 + m3 × dt3 = 5 + 2 × 40 = 85 ms Since I3 < I2, the next input value that arrives earliest is I3.

[0090] In this case, the gap time dt is dt = m3 × dt3 - (t out - t3) = 2 × 40 - (45 - 5) = 40 ms Thus, when dk is shorter than 40 ms, container replacement is performed in this embodiment.

[0091] (2) Configuration of Software Update Device 13 Using FIG. 14, a configuration example of the software update device 13 of this embodiment will be described. The software update device 13 has the same configuration as the software update device 12 of Embodiment 2 shown in FIG. 10. The difference from Embodiment 2 is that the number of input values has changed from 2 to 3. From the above, the description of FIG. 14 is cited by reading the number of input values in the description of FIG. 10.

[0092] (3) Software Update Method Since the operation of the software update method of this embodiment is common to the software update method of Embodiment 2, the description of the flowchart shown in FIG. 11 of Embodiment 2 is cited.

[0093] (4) How to calculate the gap time dt when there are three or more input values Even when three or more input values ​​are present, the calculation method for the gap time dt is the same as that in the second and third embodiments, and will be described with reference to Fig. 15. Fig. 15 is a flowchart showing a generalized calculation method for the gap time dt.

[0094] In the spare time acquisition unit 101, input values ​​(I1, I2, ... I n ) (n is a natural number greater than or equal to 2) n ), reception period (dt1, dt2, ... dt n ), and the output time t out The information required to calculate the gap time dt is acquired from the external device 30, the target device 20, etc. (S101).

[0095] Among n input values, the input value I with the longest period n (S102) When an application performs a calculation using multiple types of input values, the calculation cannot be performed unless all types of input values ​​are available, so the application performs the calculation and outputs the result at the timing when the input value with the longest period is input.

[0096] The input value I with the longest period n The period of t n ~t n +dt n The number of each input value in the period (m1,m2,...m n ) is calculated (S103).

[0097] The reception time of each input value group immediately before the execution of the next predetermined process is calculated (S104). The input value immediately before the execution of the next predetermined process is t n ~t n +dt n That is, based on the number of input values ​​calculated in the previous step, the input value corresponding to the maximum number corresponds to the last input value.

[0098] Input value group I1 to I immediately before the next specified processing execution n The input value I that is received the earliest among x (S105).

[0099] Input value I x The gap time dt is calculated based on the I selected in the previous step (S106). X Period dt x , number of input values ​​m x , the input value I just before the next specified processing is executed x Reception time t x Using this, dt=m x ×dt x -(t out -t x ) is calculated using the formula:

[0100] The driver and application processes for autonomous driving tend to repeat the same process at regular intervals as input values ​​are input at regular intervals. The flowchart in Figure 15 utilizes this to calculate gap time. The flowchart in FIG. 15 can be applied to the case where the input value is 1 as in the first embodiment, and to the case where the input value is 2 as in the second embodiment.

[0101] (5) Summary As described above, according to the software update device of this embodiment, even when there are three or more input values, the gap time is calculated by obtaining the reception time of the input values, the reception cycle of the input values, and the output time of the output values, so that software switching instructions can be issued at an appropriate time based on the operating status of the target device 20.

[0102] 6. Embodiment 4 (Software Update Device 14: When Software is a Driver) (1) Overview and operation of the software used in this embodiment In the first embodiment, an example was described in which one input value is input to the software, and the software before the update and the software after the update are simultaneously started to switch the software. In this embodiment, a case will be described in which one input value is input, and the software before the update and the software after the update are not simultaneously started, that is, only one of the software is started. Specifically, a case will be described in which the software is a camera driver.

[0103] 16 is a diagram illustrating the operation of the camera device. Hereinafter, configurations and operations common to those shown in FIGS. 5 to 8 of the first embodiment are assigned the same numbers as those in the first embodiment, and the description of the first embodiment will be cited.

[0104] In FIG. 16(a), the sensor data output from the camera is used as the first input value I1 of the camera driver, and the output value I of the camera image of the camera driver out is output to the subsequent application. In FIG. 16(a), the first input value I1 has a frequency of 10 Hz. The output value I, which is a camera image that has undergone predetermined processing in the camera driver, for example, processing to convert sensor data into an image, is out Similarly, the first input value I1 is used as a trigger to generate the output value I out Output.

[0105] FIG. 16(b) is a diagram illustrating the timing of input and output of the camera driver. The processing time (t out -t1) and gap time dt.

[0106] As in the first embodiment, if the gap time dt is longer than the required switching time dk, it is determined that the software update is possible, and if the gap time dt is shorter than the required switching time dk, it is determined that the software update is not possible.

[0107] (2) Configuration of the software update device 14 An example of the configuration of the software update device 14 of this embodiment will be described with reference to FIG. The software update device 14 has a configuration similar to that of the software update device 11 of the first embodiment shown in Fig. 6. The difference from the configuration of the first embodiment is that the target device 20 has a first control unit 4001 and a second control unit 4002 instead of the first execution state control unit 1002 and the second execution state control unit 1003.

[0108] The first control unit 4001 controls the execution and stop of the first software based on the switching instruction from the switching instruction unit 102. Specifically, the first control unit 4001 switches between the execution and stop of the first software in the first processing unit 1002. The second control unit 4002 controls the execution and stop of the second software based on the switching instruction from the switching instruction unit 102. Specifically, the second control unit 4002 switches between the execution and stop of the second software in the second processing unit 1004.

[0109] In this embodiment, the first control unit 4001 and the second control unit 4002 control the execution / stop of the first processing unit 1002 and the second processing unit 1004 so that the first software and the second software are not executed simultaneously.

[0110] FIG. 18 is a diagram for explaining details of the execution / stop of the old container and the new container in the target device 20. In FIG. 18(a) is a diagram illustrating the operation of the target device 20 before receiving a switching instruction, i.e., before an update. Before an update, the first control unit 4001 causes the first processing unit 1002 to execute processing, and the first processing unit 1002 performs predetermined processing using the old container on an input value and outputs an output value. At this time, the second control unit 4002 does not cause the second processing unit 1004 to execute processing. In other words, the second processing unit 1004 is stopped without executing the new container.

[0111] 18(b) is a diagram illustrating the operation of the target device 20 after receiving a switching instruction, i.e., after updating. When the first control unit 4001 receives a switching instruction from the switching instruction unit 102, it stops the processing of the first processing unit 1002. When the second control unit 4002 receives a switching instruction, it starts the second processing unit 1004 and causes the second processing unit 1004 to execute processing, performs predetermined processing using the new container on the input value, and outputs the output value.

[0112] Generally, it is not expected that the same driver will be started at the same time, and when replacing a driver, it is necessary to first stop the driver before the update and then start the updated driver. Therefore, switching takes longer than switching between the running state and the standby state as in the first to third embodiments. However, by calculating the gap time as in the present embodiment, it is possible to detect a timing when the gap time dt is long and switch the driver. In particular, when the input value is 2 or more as in the second and third embodiments, the gap time dt varies, and therefore the software update method of the present embodiment is effective.

[0113] (3) Software update method 19 is a flowchart showing the software update method of this embodiment. Hereinafter, operations that are substantially the same as those in the flowchart shown in FIG. 8 of the first embodiment are assigned the same numbers as those in the first embodiment, and the description of the first embodiment will be cited.

[0114] In this embodiment, if there is an update, i.e., if there is a new container, the new container, update parameters, and a restart flag are downloaded from the container repository (S1002). The restart flag is information indicating whether or not a container update instruction requires restarting the sensor.

[0115] The switching instruction unit 102 determines whether the gap time dt is longer than the required switching time dk (S1003). If the gap time dt is longer than the required switching time dk, the switching instruction unit 102 determines whether the gap time dt is longer than the required switching time dk. ...out The process waits until the output value I is received (S1005). out The next step will not be taken and the process will wait until the next step is received.

[0116] When the output value from the first processing unit 1002 is received, the switching instruction unit 102 includes a restart flag in the switching instruction and transmits it to the target device 20 (S1006).

[0117] Based on the switching instruction, the first control unit 4001 stops the processing of the first processing unit 1002. That is, it stops the old container (S4001).

[0118] After the old container stops, the first control unit 4001 or the second control unit 4002 restarts the sensor if it is necessary to restart the sensor based on the restart flag (S4003).

[0119] After the sensor is restarted, or if restarting the sensor is not necessary, the second control unit 4002 executes the processing of the second processing unit 1004 based on the switching instruction. That is, the new container is started (S4004). As described above, during the gap time dt, a series of processes from stopping the old container (S4001) to starting the new container (S4004) are executed.

[0120] (4) Other This embodiment can also be applied to cases where the input value is two or more, as in the second and third embodiments.

[0121] (5) Summary As described above, according to the software update device of this embodiment, even if the software is a driver, software switching is instructed if the gap time is longer than the required switching time, so that software can be switched during the gap time.

[0122] 7. Variations Regarding the timing at which software can be updated, in addition to the gap time shown in each embodiment, there are also the following application-specific timings at which software can be updated. (1) Traffic light recognition app If there are no traffic lights nearby When it is determined that no traffic lights are visible in the image for a certain period of time based on map information, vehicle direction, and angle of view. (2) Self-location estimation app When GPS accuracy is high in open skies, etc., and stopping the app for a short period of time has almost no effect on location accuracy (3) Surrounding object recognition app When there are no moving objects nearby (4) Path Planner When the vehicle speed is below the threshold

[0123] Therefore, software can be switched by using the gap time of each embodiment in combination with the specific update possible timings of (1) to (4). For example, a driver that takes a long time to update can be updated first at the specific update possible timing, and then an application that uses the output value from the driver as an input value can be updated at the gap time or the specific update possible timing.

[0124] 8. Summary The features of the software update device and the like in each embodiment of the present invention have been described above.

[0125] The terms used in each embodiment are merely examples and may be replaced with synonymous terms or terms having the same functions.

[0126] The block diagrams used to explain the embodiments classify and organize the device configuration by function. The blocks representing each function can be realized by any combination of hardware or software. Furthermore, because they represent functions, the block diagrams can also be understood as disclosures of method inventions and program inventions that realize the methods.

[0127] The order of the functional blocks that can be understood as the processes, flows, and methods described in each embodiment may be changed as long as there are no constraints, such as one step utilizing the results of another step that precedes it.

[0128] The terms first, second, through Nth (N is an integer) used in each embodiment and in the claims are used to distinguish between two or more configurations or methods of the same type, and do not limit the order or superiority or inferiority.

[0129] Furthermore, examples of the form of the software update device etc. of the present invention include the following. Examples of the component include semiconductor elements, electronic circuits, modules, and microcomputers. Examples of semi-finished products include an electronic control unit (ECU) and a system board. Finished product forms include mobile phones, smartphones, tablets, personal computers (PCs), workstations, and servers. Other examples include devices with communication functions, such as video cameras, still cameras, and car navigation systems.

[0130] Furthermore, necessary functions such as an antenna and a communication interface may be added to each device.

[0131] In addition, the present invention can be realized not only by dedicated hardware having the configuration and functions described in each embodiment, but also by a combination of a program for realizing the present invention recorded on a recording medium such as a memory or hard disk, and general-purpose hardware having a dedicated or general-purpose CPU and memory that can execute the program.

[0132] Programs stored on non-transitory physical recording media (for example, external storage devices (hard disks, USB memory, CDs / BDs, etc.) or internal storage devices (RAM, ROM, etc.)) of dedicated or general-purpose hardware can be provided to the dedicated or general-purpose hardware via a recording medium, or via a communication line from a server without using a recording medium. This allows the latest functions to be provided at all times through program upgrades. [Industrial Applicability]

[0133] Although the software update device of the present invention has been described as a software update device that is primarily installed in automobiles, it is not limited to in-vehicle use and can be applied to any device or system that requires software updates. [Explanation of symbols]

[0134] 11, 12, 13, 14 software update device, 20 electronic control device (target device), 30 external device, 101 spare time acquisition unit, 102 switching instruction unit, 1001 first execution state control unit, 1002 first processing unit, 1003 second execution state control unit, 1004 second processing unit, 4001 first control unit, 4002 second control unit

Claims

1. A software update device that controls software update by instructing a target device (20) in which first software that performs predetermined processing on input values ​​input at regular intervals and outputs an output value, and second software that is a different version of the first software and performs predetermined processing on the input values ​​and outputs an output value, to switch between the first software and the second software, a gap time acquisition unit (101) in the first software that acquires a gap time (dt) that is a period excluding a processing period from an input time of the input value to an output time of the output value; a switching instruction unit (102) that instructs switching from the first software to the second software during the gap time (dt) if the gap time (dt) is longer than a switching time (dk) required for switching from the first software to the second software; having Software update device (11, 12, 13, 14).

2. The gap time acquisition unit acquires the gap time (dt) from an external device (30).

2. A software update device (11, 14) according to claim 1.

3. The spare time acquisition unit acquires first to nth input values ​​(I １ ~I ｎ ) (where n is a natural number greater than or equal to 1) １ ~t ｎ ), the reception period of the first to nth input values ​​(dt １ ~dt ｎ ), and the output value (I out ) output time (t out ) to obtain the gap time (dt) by calculation.

2. A software updating device (12, 13) according to claim 1.

4. The gap time acquisition unit instructs a source of the input value to restart if the gap time (dt) is not longer than the required switching time (dk) within a predetermined period.

2. A software updating device (11, 12, 13, 14) according to claim 1.

5. the first software and the second software are applications that execute the predetermined processing; 2. A software updating device (11, 12, 13) according to claim 1.

6. the first software and the second software are both running, Based on the instruction to switch, the first software switches from an execution state to a standby state, and the second software switches from the standby state to an execution state.

6. The software update device according to claim 5.

7. the first software and the second software are drivers for controlling or operating sensors; 2. The software update device (14) of claim 1.

8. the first software is in an active state and the second software is in a stopped state; The first software is stopped and the second software is started based on the instruction to switch.

8. The software update device according to claim 7.

9. The first software is software before the update, and the second software is software after the update.

2. A software updating device (11, 12, 13, 14) according to claim 1.

10. The first software is software after updating, and the second software is software before updating.

2. A software updating device (11, 12, 13, 14) according to claim 1.

11. After switching to the second software, removing the first software from the target device.

2. A software updating device (11, 12, 13, 14) according to claim 1.

12. the target device includes a first memory area in which the first software is stored and a second memory area in which the second software is stored; after switching to the second software, the first software is not deleted from the first memory area, and when installing third software that is a different version from both the first software and the second software, the third software is overwritten in the first memory area; 2. A software updating device (11, 12, 13, 14) according to claim 1.

13. The software update device is mounted on a mobile object.

2. A software updating device (11, 12, 13, 14) according to claim 1.

14. A software update method executed by a software update device (11, 12, 13, 14) for controlling software update by instructing a target device (20) to switch between first software and second software, the first software performing predetermined processing on input values ​​input at a constant cycle and outputting an output value, and second software being software of a different version from the first software and performing predetermined processing on the input values ​​and outputting an output value, the method comprising: In the first software, a gap time (dt) is acquired, which is a period from the input time of the input value to the output time of the output value excluding the processing period (S1002, S2009); If the gap time (dt) is longer than the switching time (dk) required for switching from the first software to the second software, an instruction to switch from the first software to the second software is issued during the gap time (S1003, S2010, S1006). How to update your software.

15. A software update program executable by a software update device (11, 12, 13, 14) for controlling software update by instructing a target device (20) to switch between first software and second software, the first software performing predetermined processing on input values ​​input at a constant cycle and outputting an output value, and second software being software of a different version from the first software and performing predetermined processing on the input values ​​and outputting an output value, The software update program is transmitted to the software update device. In the first software, a gap time (dt) is acquired, which is a period from the input time of the input value to the output time of the output value excluding the processing period (S1002, S2009); If the gap time (dt) is longer than the switching time (dk) required for switching from the first software to the second software, an instruction to switch from the first software to the second software is issued during the gap time (S1003, S2010, S1006). Execute the process, Software updates.

Images