Software update device, software update method, and software update program

Abstract

A software update device for controlling a software update by instructing a target device having first software, which outputs an output value by performing predetermined processing on input values input at fixed intervals, and second software, which is software of a different version from the first software and outputs an output value by performing predetermined processing on the input values, installed thereon to switch between the first software and the second software, comprises: an intervening time acquisition unit (101) for acquiring an intervening time (dt), which is a period excluding a processing period from the input time of the input value to the output time of the output value, in the first software; and a switch instructing unit (102) for instructing the switching of software in the intervening time when the intervening time (dt) is longer than a switching time (dk).

Description

Software update device, software update method, and software update program CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Japanese Patent Application No. 2024-130190, filed on August 6, 2024, the contents of which are incorporated herein by reference.

[0002] The present application 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 application 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.

[0003] 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.

[0004] 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.

[0005] 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 in autonomous driving mode, the autonomous driving functions are restricted and the software is updated.

[0006] WO2021 / 024589 publication

[0007] 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.

[0008] As a result of detailed investigation, the inventors have discovered the following problem. FIG. 20( a) shows how hardware and software for performing autonomous driving of a vehicle are executed. To perform autonomous driving, various sensors are attached to a vehicle. The various sensors are mainly implemented by hardware. Drivers for controlling and operating the various sensors and various applications for performing predetermined processing using output values ​​of the various drivers as input values ​​are implemented as software and executed by an electronic control system mounted on the vehicle. Examples of sensors include cameras, 3D-LiDAR, millimeter-wave sensors, acceleration sensors, GPS sensors, etc. Examples of drivers include dedicated or general-purpose drivers corresponding to each sensor. Examples of applications include an image recognition application, a three-dimensional object recognition application, a white line recognition application, a periphery recognition application, a self-position estimation application, a map generation application, and a vehicle-to-vehicle communication application.

[0009] FIG. 20( b) shows processing for performing autonomous driving of a vehicle. As an example of processing within a sensor, first, communication is confirmed for information inside and outside the vehicle, and after communication is confirmed, sensor data related to the information is output to a driver in a subsequent stage. As an example of processing within a driver, sensor data output from various sensors in a previous stage is used as input values, and predetermined processing for controlling and operating various sensors is performed within the driver, and for example, a ROS message or the like is output as an output value to an application in a subsequent stage. After outputting the output value, the system waits for input of the next input value. As an example of processing within an application, predetermined processing according to the purpose of the application is performed on input values ​​such as a ROS message output from a driver in a previous stage, and for example, the ROS message or the like is output as an output value to another application or a GUI (Graphical User Interface) in a subsequent stage. After outputting the output value, the system waits for input of the next input value. In this way, the processing of the driver and application for performing autonomous driving tends to be repeated at regular intervals.

[0010] 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.

[0011] An object of the present disclosure is to provide a software update device or the like that can update software during spare time, and more specifically, that can update software even in autonomous driving mode without stopping the processing required for autonomous driving.

[0012] A software update device according to one aspect of the present disclosure is a software update device that controls software updates for a target device on which first software is installed, the first software performing a predetermined process on input values ​​input at regular intervals and outputting an output value, and second software, a different version of software from the first software performing a predetermined process on the input values ​​and outputting an output value, by instructing the device to switch between the first software and the second software.The software update device has: a gap time acquisition unit that acquires, in the first software, a 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; and a switching instruction unit that, if the gap time (dt) is longer than the switching time (dk) required to switch from the first software to the second software, instructs the device to switch from the first software to the second software during the gap time.

[0013] According to the software update device and the like of the present disclosure, software can be updated using the gap time. More specifically, the gap time dt is compared with the switching time dk required to switch from the first software to the second software, and software switching is instructed based on the comparison result, thereby enabling software updates even during autonomous driving.

[0014] The above and other objects, features, and advantages of the present disclosure will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which Fig. 1 is a diagram illustrating the layout of a software update device, etc., Fig. 2 is a diagram illustrating the relationship between the software update device, etc., and an electronic control system (electronic control device), Fig. 3 is a diagram illustrating an example of the configuration of an electronic control system, Fig. 4 is a diagram illustrating a software update device that is a common configuration of the present embodiments, Fig. 5 is a diagram illustrating the operation of software in the first embodiment, Fig. 6 is a block diagram illustrating the configuration of the software update device in the first embodiment, Fig. 7 is a diagram illustrating software switching in the software update device in the first embodiment, Fig. 8 is a flowchart relating to the software update method in the first embodiment, Fig. 9 is a diagram illustrating the operation of software in the second embodiment, and Fig. 10 is a block diagram illustrating the configuration of the software update device in the second embodiment. FIG. 11 is a block diagram illustrating the software update method of the present embodiment 2, FIG. 12 is a diagram illustrating the operation of the software of the present embodiment 3, FIG. 13 is a diagram illustrating the operation of the software of the present embodiment 3, FIG. 14 is a block diagram illustrating the configuration of the software update device of the present embodiment 3, FIG. 15 is a flowchart illustrating the gap time calculation method of the present embodiment 3, FIG. 16 is a diagram illustrating the operation of the software of the present embodiment 4, FIG. 17 is a block diagram illustrating the configuration of the software update device of the present embodiment 4, FIG. 18 is a diagram illustrating the switching of software in the software update device of the present embodiment 4, FIG. 19 is a flowchart illustrating the software update method of the present embodiment 4, and FIG. 20 is a diagram illustrating the problems with the conventional technology.

[0015] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.

[0016] The present invention described below refers to the invention described in the claims, and is not limited to the following embodiments. Furthermore, at least double quotation marks refer to the phrases described in the claims, and are not limited to the following embodiments.

[0017] 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.

[0018] 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.

[0019] 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.

[0020] The problems described in this disclosure are not publicly known problems, but have been independently discovered by the inventors, and together with the configuration and method of this disclosure, this fact affirms the inventive step of the invention.

[0021] 1. Configuration Prerequisite for Each Embodiment (1) Layout of the Software Update Device and the Target Device on Which Software Is Installed FIG. 1 is a diagram illustrating the layout of the software update device of each embodiment. For example, as shown in FIG. 1( a), the software update device 11 of embodiment 1, the software update device 12 of embodiment 2, the software update device 13 of embodiment 3, and the software update device 14 of embodiment 4 (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. does not necessarily have to be "mounted" on a "mobile body." An example of the form of the software update device 11, etc. in FIG. 1( a) is, but is not limited to, an electronic control unit (ECU). Furthermore, an example of the form of the software update device 11, etc. in FIG. 1( b) is, but is not limited to, a personal computer (PC) or a smartphone. Here, a "mobile body" refers to a movable object, and the moving speed is arbitrary. This also naturally includes a case where the mobile body is stationary. Examples include, but are not limited to, automobiles, motorcycles, bicycles, pedestrians, ships, aircraft, and objects mounted on these vehicles. "Mounted" includes not only cases where the vehicle is directly fixed to the vehicle, but also cases where the vehicle is not fixed to the vehicle but moves with the vehicle. For example, cases where the vehicle is carried by a person riding on the vehicle, or where the vehicle is mounted on cargo placed on the vehicle, are included.

[0022] 2 is a diagram illustrating the arrangement of the software update device 11 and the like in each embodiment and the electronic control system S. The software update device 11 and the like in each embodiment are "connected" to multiple "electronic control devices" 20 (hereinafter referred to as ECUs (Electronic Control Units)) that constitute the electronic control system S. Here, the "electronic control device" may be a physically independent electronic control device, or 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.

[0023] 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).

[0024] FIG. 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 located outside the mobile body. In the case of FIG. 2(c), the software update device 11 and the like are realized, for example, by a server device. The software update device 11 and the plurality of ECUs 20 are connected via a communication network 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, 5G, or other wireless communication standard. 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 system, such as a local area network (LAN), the Internet, or a fixed telephone line, can be used instead of a wireless communication system.

[0025] (2) Configuration of Electronic Control System S Figure 3 is a diagram showing an example of the configuration of the electronic control system S. The electronic control system S is composed of multiple ECUs 20 and in-vehicle networks (NW1 to NW3) connecting these ECUs. While Figure 3 illustrates eight ECUs (ECU 20a to ECU 20h), the electronic control system S may naturally be composed of any number of ECUs. In the following description, when describing a single or multiple electronic control devices collectively, they will be referred to as ECU 20 or each ECU 20, and when describing individual electronic control devices specifically, they will be referred to as ECU 20a, ECU 20b, ECU 20c, ...

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

[0027] 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).

[0028] 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.

[0029] The external communication ECU 20b is an ECU having a communication unit that communicates with an external device provided outside the vehicle, for example, the external device 30 in each embodiment. The communication method used by the external communication ECU 20b is the wireless communication method or wired communication method described in the explanation of FIG. 2C. Note that multiple external communication ECUs 20b may be provided to implement multiple communication methods. Alternatively, instead of providing the external communication ECU 20b, the integrated ECU 20a may include the function of the external communication ECU 20b.

[0030] 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).

[0031] 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., vehicle 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.

[0032] In the first to fourth embodiments, 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 the software update device 11 and the like are 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.

[0033] In addition, in the first to fourth embodiments, the devices (corresponding to "target devices") whose software is updated by the software update device 11 or the like are the ECUs 20 constituting the electronic control system S. In the following embodiments, the ECUs 20 whose software is updated are referred to as target devices 20. The software update device 11 or the like and the target devices 20 may be included in the same ECU. For example, the software update device 11 or the like 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 or the like (including cases where the software update device 11 or the like has a function equivalent to the software update device 11 or the like) may be provided in each of all ECUs 20 in which software is installed.

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

[0035] The software update device 11 or the like is a device that manages and controls 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 switches software based on instructions from the software update device 11 or the like. The method of switching programs may vary depending on the type of software. Switching methods when the software is an application will be described in embodiments 1 to 3, and switching methods when the software is a driver will be described in embodiment 4. Here, the "target device" may be any device on which software is installed, and includes devices that are different from the software update device as well as devices that are the same as the software update device. The "target device" also includes virtual machines. "Switching" refers to a transition 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.

[0036] Software is a collection of programs and data that provide commands to a computer and cause it to execute specific tasks or functions. Examples of software include applications, operating systems, drivers, and the like used on personal computers, smartphones, and the like. While the embodiments are directed to software and drivers related to autonomous driving, the present invention may also be applied to software and drivers unrelated to autonomous driving. Software updates include updating software in use or on standby, or restoring updated software to its pre-update state. In addition, when software is containerized, software updates include updating a container in use or on standby, or restoring an updated container to its pre-update state.

[0037] The target device 20 has first software and second software installed. "Installed" refers to a state in which software is executable, such as when the software is stored on 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" input at "regular intervals" and outputs an output value. The second software is a different "version" from the first software, and performs "predetermined processing" on "input values" input at "regular intervals" and outputs an output value. Specific examples of software and the input and output values ​​of the software will be described in each embodiment. Here, "regular intervals" include cases where the intervals are always constant, as well as cases where the intervals change depending on conditions. "Versions" are indicators that identify each piece of software when the software content changes due to revisions or improvements, and include, for example, releases and revisions. "Input values" may be any data required to execute the "predetermined processing" described below. For example, they may include values ​​resulting from previous processing or data transmitted from a sensor. "Predetermined processing" may be any operation or decision performed based on input values. For example, image recognition processing, traffic light recognition processing, object recognition processing, self-position determination, path planning processing, etc. may be mentioned.

[0038] The gap time acquisition unit 101 "acquires" the 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, the 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 referred to as the reception period dt required for calculating the gap time dt. ｘIn the second and third embodiments, basic information such as the above is received in advance from the external device 30, the target device 20, or another ECU 20, and the gap time dt is obtained by calculation. Here, "obtaining" includes not only obtaining by calculation, but also receiving and obtaining information obtained in advance by calculation.

[0039] If the gap time dt is longer than the required switching time dk for switching 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, for example, in 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 about the second software and stored in a storage unit accessible by the switching instruction unit 102. Here, "more 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 (>).

[0040] Details of the software update device 11 and the like will be described below in each embodiment. Note that in embodiments 1 to 4, 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 (hereinafter referred to as the old container) with the container after the update (hereinafter referred to as the new container).

[0041] 3. Embodiment 1 (Software Update Device 11: Case where One Input Value is Used) (1) Overview and Operation of Software Used in This Embodiment In this embodiment, an example where one input value is input to the software will be described. Specifically, the description will be made of an image recognition application for autonomous driving (hereinafter abbreviated as an image recognition app).

[0042] 5A and 5B are diagrams illustrating the operation of the image recognition application. In FIG. 5A, a camera image output from a camera driver is input to the image recognition application as a first input value I １ The output value I ｏｕｔ is output to the subsequent application or GUI. In FIG. 5(a), the first input value I １ has a frequency of 10 Hz. The output value I is the result of image recognition performed in a predetermined image recognition process in the image recognition application, for example, by performing a process such as recognizing or determining a specific image. ｏｕｔ Similarly, the image recognition application uses the first input value I １ is used as a trigger to output the value I ｏｕｔ Output.

[0043] 5B is a diagram illustrating the input / output timing of the image recognition application. In FIG. 5B, the input value I １ The first reception period dt １ is 10 Hz, i.e., 100 ms. Also, the input value I １ The reception time is t １ , the output time of the output value is t ｏｕｔ When this is the case, the processing time (t ｏｕｔ -t １ ) is 40 ms. Therefore, the gap time dt is: dt = dt １ -(t ｏｕｔ -t １ ) = 100ms - 40ms = 60ms.

[0044] In this embodiment, the processing time of the image recognition process (t ｏｕｔ -t １ ) is 40 ms, and the gap time dt is 60 ms. These values ​​may be stored in the external device 30 as known values ​​measured in advance by the manufacturer of the image recognition application, and may be received and acquired by the gap time acquisition unit 101. Alternatively, the first input value I １ Reception time t １ , output value I ｏｕｔ Output time t ｏｕｔ, first reception period dt １ Based on this, the spare time acquisition unit 101 calculates the processing time (t ｏｕｔ -t １ ) and gap time dt may be calculated and obtained.

[0045] 5C, if the gap time dt is longer than the required switching time dk, it is determined that the software update is possible, whereas if the gap time dt is shorter than the required switching time dk, it is determined that the software update is not possible.

[0046] 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.

[0047] (2) Configuration of the Software Update Device 11 An example configuration of the software update device 11 of this embodiment will be described using FIG. 6. 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 the first software, and a new container, which is the 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, and the first input value I １ Furthermore, the external device 30 acquires the gap time using the gap time acquisition unit 101 and stores update parameters, which are information necessary for issuing a switching instruction using the switching instruction unit 102. The update parameters in this embodiment include the gap time dt and the required switching time dk.

[0048] The gap time acquisition unit 101 of the software update device 11 acquires the gap time dt from the external device 30. Alternatively, the gap time acquisition unit 101 may acquire the first reception period dt from the external device 30, the target device 20, or another ECU 20, etc. １ , the first input value I １ The first input time t １ , the output value I ｏｕｔ Output time t ｏｕｔ The gap time dt obtained by the gap time obtaining unit 101 is transmitted to the switching instruction unit 102.

[0049] 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 ｏｕｔ The 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.

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

[0051] Here, if image recognition processing is performed simultaneously using the old container and the new container and output values ​​are output simultaneously, there is a possibility that malfunctions may occur 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.

[0052] FIG. 7 is a diagram illustrating the details of the parallel startup and running / standby states of the old container and the new container in the target device 20. 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 the update, the first execution state 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 state 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 started, the predetermined processing using the new container is not performed on the input value, and no output value is output.

[0053] 7B 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 the 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 the 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 an output value.

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

[0055] 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 deleted from the target device 20 after a certain period of time has passed.

[0056] 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 state control unit 1001 and the second execution state control unit 1002 based on an instruction from the switching instruction unit 102.

[0057] In this case, the target device 20 may be provided with multiple memory areas to allow the new container and the old container to coexist, 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. After switching from the first software to the second software, the first software may not be deleted from the first memory area. Furthermore, 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 second software to continue execution by switching back to the first software even if a malfunction occurs, allowing the two new and old software to coexist until the new third software is installed.

[0058] 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.

[0059] (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, i.e., the presence or absence of an application update, from the container repository (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 a fixed interval, 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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 within 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.

[0065] The first execution state control unit 1001 switches the old container from the execution state to the standby state based on the switching instruction, 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 perform a predetermined process (S1008).

[0066] 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.

[0067] (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.

[0068] 4. Second Embodiment (Software Update Device 12: Case of Two Input Values) (1) Overview and Operation of Software Used in the Second Embodiment In the first embodiment, an example in which one input value is input to the software is described. In the second embodiment, a case in which two input values ​​are input is described. Specifically, a traffic light recognition application is described.

[0069] 9 is a diagram illustrating the operation of the traffic light recognition application. 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.

[0070] FIG. 9A shows the camera image output from the camera driver as a first input value I １ The self-location information output from the self-location application is used as the second input value I ２ In FIG. 9(a), the first input value I １ has a frequency of 10 Hz. The second input value I ２ has a frequency of 50 Hz. The output value I is the recognition result obtained by performing a predetermined traffic light recognition process in the traffic light recognition application. ｏｕｔ has a frequency of 10 Hz. In other words, the traffic light recognition application uses the first input value I １ is used as a trigger to output the value I ｏｕｔ Output.

[0071] FIG. 9B 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. In FIG. 9B, the first input value I １ The first reception period dt １ is 10 Hz, i.e., 100 ms. Also, the second input value I ２ The second reception period dt ２ is 50 Hz, or 20 ms.

[0072] The input value with the longest period is the first input value I １ , so the first input value I １ The period of t １ ~t １ +dt １ The number of each input value in the period (m ２ In the example shown in FIG. ２ There are five. Here, m ２ To explain in detail how to calculate m ２ is the largest natural number that satisfies the following formula: m ２ ≦(t １ +dt １ -t ２ ) / dt ２ = (15 + 100 - 0) / 20 = 5.75, so m ２ Based on this, the gap time dt is: dt = m ２ ×dt ２ -(t ｏｕｔ -t ２ ) = 5 × 20 - (55 - 0) = 45 ms. Therefore, in this embodiment, if dk is shorter than 45 ms, container replacement is performed.

[0073] Note that the first input value I １ Reception period dt １ and the second input value I ２ Reception period dt ２Under certain conditions, such as when the periods of the first input value I and the second input value I are close to each other, the relationship of gap time dt>required switching time dk may continue to not be satisfied. Therefore, if this relationship continues to not be satisfied for a certain period of time, for example, even after a certain number of loops, a restart may be instructed to the source of the input value. Specifically, １ or the second input value I ２ The first input value I is instructed to be restarted by restarting the camera driver or the self-location application in the previous stage related to at least one of the above. １ and the second input value I ２ This is because the relative input timings of the two may change, and a case may occur where the relationship of gap time dt>required switching time dk is satisfied. This allows the software update to proceed quickly.

[0074] (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. 10. 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 acquires the reception period dt ｘ and input value I １ , I ２ and obtain the gap time dt by calculation; and the input value input to the target device 20 is the first input value I １ and the second input value I ２ Hereinafter, blocks having the same functions as those of the first embodiment will be assigned the same numbers as those of the first embodiment, and the description of the first embodiment will be cited.

[0075] In this embodiment, the gap time acquisition unit 101 receives the first receiving period dt １ and the second receiving period dt ２ , a first input value I from another ECU 20 or a driver via an in-vehicle network. １ and a second input value I ２ , an output value I , which is a result of the traffic light recognition processing, from the first processing unit 1002 of the target device 20 ｏｕｔThen, a first input value I １ The time when the first input time t １ , the second input value I ２ The time when the second input time t ２ , output value I ｏｕｔ The time when the ｏｕｔ Using this basic information, the gap time dt is calculated by the method explained in FIG. １ and the second receiving period dt ２ without receiving the first input time t １ and the second input time t ２ to the first reception period dt １ and the second receiving period dt ２ You may ask for:

[0076] When the first processing unit 1002 is in the running state, the first input value I １ and a second input value I ２ A predetermined process, traffic light recognition, is performed on the output value I ｏｕｔ When the second processing unit 1002 is in the running state, it outputs the first input value I １ and a second input value I ２ A predetermined process, traffic light recognition, is performed on the output value I ｏｕｔ 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 the switching between the execution state and the standby state, refer to FIG. 7 and its description.

[0077] (3) Software Update Method Fig. 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 explanation of the first embodiment will be cited.

[0078] 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 value, or may be a variable value depending on the reception period of each input value.

[0079] After downloading the updated parameters, etc., the new container is started and placed in a standby state (S2004).

[0080] 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).

[0081] 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.

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

[0083] 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, a switching instruction is transmitted (S1006). If the gap time dt is shorter than the required switching time dk, the process 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.

[0084] (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 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.

[0085] 5. Embodiment 3 (Software Update Device 13: Case Where Three or More Input Values ​​Are Used) (1) Overview and Operation of Software Used in This Embodiment In the first embodiment, an example was described where one input value is input to the software, and in the second embodiment, an example was described where two input values ​​are input to the software. In this embodiment, a case where 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 determine how the object should move in the future. Specific examples of route calculations using the path planner app include route calculations such as which lane to use and the curvature 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.

[0086] 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.

[0087] FIG. 12 shows the object recognition result output from the object recognition application when the first input value I １ The self-location information output from the self-location application is used as the second input value I ２ The CAN information output from the CAN driver is used as the third input value I ３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-position information is information such as the position, speed, and orientation of the vehicle itself. An example of the CAN information is information such as the wheel speed and steering angle of the vehicle itself. The first input value I １ has a frequency of 10 Hz. The second input value I ２ has a frequency of 50 Hz. The third input value I ３ has a frequency of 25 Hz. The path planning process is performed in the path planner application, and the route information is output as an output value I ｏｕｔ The output value I ｏｕｔ has a frequency of 10 Hz. That is, the path planner app calculates the first input value I １ is used as a trigger to output the value I ｏｕｔ Output.

[0088] FIG. 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. In FIG. 13, the first input value I １ The first reception period dt １ is 10 Hz, i.e., 100 ms. Also, the second input value I ２ The second reception period dt ２ is 50 Hz, i.e., 20 ms. Also, the third input value I ３ The third reception period dt ３ is 25 Hz, i.e., 40 ms. For each reception time of the input value, t １ is 15ms, t ２ is 0 ms, t ３ is 5 ms.

[0089] The input value with the longest period is the first input value I １ , so the first input value I １ The period of t １ ~t １ +dt １ The number of each input value in the period (m ２ , m ３ In the example shown in FIG. ２ 5 pieces, m ３ There are two. Here, m ２To explain in detail how to calculate m ２ is the largest natural number that satisfies the following formula: m ２ ≦(t １ +dt １ -t ２ ) / dt ２ = (15 + 100 - 0) / 20 = 5.75, so m ２ There are five. Also, m ３ To explain in detail how to calculate m ３ is the largest natural number that satisfies the following formula: m ３ ≦(t １ +dt １ -t ３ ) / dt ３ = (15 + 100 - 5) / 40 = 2.75, so m ３ There are two.

[0090] The arrival times of the next input values ​​to be used are as follows: ２ In the case of t ２ +m ２ ×dt ２ =0+5×20=100ms I ３ In the case of t ３ +m ３ ×dt ３ =5+2×40=85ms I ３ <I ２ Therefore, the next input value that arrives earliest is I ３ is.

[0091] In this case, the gap time dt is: dt = m ３ ×dt ３ -(t ｏｕｔ -t ３ ) = 2 × 40 - (45 - 5) = 40 ms. Therefore, in this embodiment, when dk is shorter than 40 ms, container replacement is performed.

[0092] (2) Configuration of the Software Update Device 13 An example configuration of the software update device 13 of this embodiment will be described using Fig. 14. The software update device 13 has a configuration similar to that of the software update device 12 of the second embodiment shown in Fig. 10. The difference from the second embodiment is that the number of input values ​​is changed from 2 to 3. For the above reasons, the description of Fig. 10 will be quoted as the description of Fig. 14, with the number of input values ​​replaced.

[0093] (3) Software Update Method The operation of the software update method of this embodiment is common to the software update method of the second embodiment, and therefore the description of the flowchart shown in FIG. 11 of the second embodiment will be cited.

[0094] (4) Method of Calculating the Gap Time dt When Three or More Input Values ​​are Used When three or more input values ​​are used, the method of calculating 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 method of calculating the gap time dt.

[0095] In the spare time acquisition unit 101, an input value (I １ , I ２ ,...I ｎ ) (n is a natural number equal to or greater than 2) reception time (t １ , t ２ ...t ｎ ), reception period (dt １ , dt ２ ,... dt ｎ ), and the output time t ｏｕｔ The information required to calculate the gap time dt, such as the above, is acquired from the external device 30, the target device 20, etc. (S101).

[0096] Among the n input values, the input value I with the longest period ｎ (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.

[0097] The input value I with the longest period ｎ The period of tｎ ~t ｎ +dt ｎ The number of each input value in the period (m １ , m ２ ,...m ｎ ) is calculated (S103).

[0098] The reception time of each of the input values ​​immediately before the next execution of the predetermined process is calculated (S104). ｎ ~t ｎ +dt ｎ 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.

[0099] Input value group I immediately before the next specified processing execution １ ~I ｎ The input value I ｘ is selected (S105).

[0100] Input value I ｘ The gap time dt is calculated based on the I selected in the previous step (S106). Ｘ Period dt ｘ , number of input values ​​m ｘ , the input value I just before the next execution of the specified process ｘ Reception time t ｘ Using this, dt = m ｘ ×dt ｘ -(t ｏｕｔ -t ｘ ) is calculated using the formula:

[0101] The driver and application processes for autonomous driving tend to receive input values ​​at regular intervals, resulting in the same processes being repeated at regular intervals. The flowchart in Figure 15 utilizes this to calculate the gap time. Note that the flowchart in Figure 15 can also be applied when the input value is 1 as in the first embodiment, or when the input value is 2 as in the second embodiment.

[0102] (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.

[0103] 6. Embodiment 4 (Software Update Device 14: When the Software is a Driver) (1) Overview and Operation of 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 in which one input value is input, and the software before the update and the software after the update are not simultaneously started, i.e., only one of the software is started, is described. Specifically, a case in which the software is a camera driver is described.

[0104] 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.

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

[0106] 16B is a diagram illustrating the timing of input and output of the camera driver. The processing time of the camera driver (t ｏｕｔ -t１ ) and gap time dt.

[0107] 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.

[0108] (2) Configuration of the Software Update Device 14 An example configuration of the software update device 14 of this embodiment will be described using Fig. 17. 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.

[0109] The first control unit 4001 controls the execution and stop of the first software based on a switching instruction from the switching instruction unit 102. Specifically, the first control unit 4001 switches between 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 a switching instruction from the switching instruction unit 102. Specifically, the second control unit 4002 switches between execution and stop of the second software in the second processing unit 1004.

[0110] 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.

[0111] FIG. 18 is a diagram illustrating details of execution / stop of an old container and a new container in the target device 20. 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 executes processing by the first processing unit 1002, 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 execute the second processing unit 1004. In other words, the second processing unit 1004 is stopped without executing the new container.

[0112] 18B is a diagram illustrating the operation of the target device 20 after receiving a switching instruction, i.e., after an update. 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 an output value.

[0113] 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 embodiments 1 to 3. However, by calculating the gap time as in this embodiment, it is possible to detect timings when the gap time dt is long and switch drivers. In particular, when the input value is 2 or more as in embodiments 2 and 3, variations in the gap time dt occur, and therefore the software update method of this embodiment is effective.

[0114] (3) Software Update Method Fig. 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 explanation of the first embodiment will be cited.

[0115] 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.

[0116] 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. ... ｏｕｔ The output value I is received (S1005). ｏｕｔ The next step will not be taken and the process will wait until the next step is received.

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

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

[0119] After the old container has stopped, 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).

[0120] After the sensor is restarted, or if restarting of 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.

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

[0122] (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.

[0123] 7. Modifications In addition to the gap times shown in each embodiment, there are also the following application-specific update timings for software updates: (1) Traffic light recognition application: When there are no traffic lights nearby When it can be determined from map information, vehicle direction, and angle of view that no traffic lights will appear in the image for a certain period of time (2) Self-location estimation application: When GPS accuracy is high with Open Sky, etc., and stopping the application for a short period of time has almost no effect on location accuracy (3) Peripheral object recognition application: When there are no moving objects nearby (4) Path planner: When the vehicle speed is below a threshold

[0124] Therefore, software can be switched by using the gap time of each embodiment in combination with the specific update timings of (1) to (4). For example, a driver that takes a long time to update can be updated first at the specific update 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 timing.

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

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

[0127] 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.

[0128] 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.

[0129] 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.

[0130] Examples of the form of the software update device and the like of the present disclosure include the following: Examples of the form of components include semiconductor elements, electronic circuits, modules, and microcomputers; Examples of the form of semi-finished products include electronic control devices (ECUs (Electric Control Units)) and system boards; Examples of the form of finished products include mobile phones, smartphones, tablets, personal computers (PCs), workstations, and servers; and Other examples include devices with communication functions, such as video cameras, still cameras, and car navigation systems.

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

[0132] In addition, the present disclosure 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 disclosure recorded on a recording medium such as a memory or a hard disk, and general-purpose hardware having a dedicated or general-purpose CPU and memory that can execute the program.

[0133] A program stored in a non-transient physical recording medium (for example, an external storage device (hard disk, USB memory, CD / BD, etc.) or an internal storage device (RAM, ROM, etc.)) of dedicated or general-purpose hardware can be provided to the dedicated or general-purpose hardware via the recording medium, or via a communication line from a server without using a recording medium. This makes it possible to always provide the latest functions through program upgrades.

[0134] Although the software update device etc. of the present disclosure has been described as a software update device etc. 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.

Claims

1. A software update device (11, 12, 13, 14) that controls software updates by instructing a target device (20) that has installed thereon 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 value and outputs an output value, to switch between the first software and the second software, the software update device having: a gap time acquisition unit (101) that acquires, in the first software, a gap time (dt) that is the period from the input time of the input value to the output time of the output value excluding the processing period; and a switch instruction unit (102) that instructs switching from the first software to the second software during the gap time if the gap time (dt) is longer than a required switching time (dk) for switching from the first software to the second software.

2. The software update device (11, 14) according to claim 1, wherein the gap time acquisition unit acquires the gap time (dt) from an external device (30).

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 ｏｕｔ ) output time (t ｏｕｔ 2. The software update device (12, 13) according to claim 1, wherein the gap time (dt) is obtained by calculating using a time (t) of the software update device (12, 13).

4. The software update device (11, 12, 13, 14) described in claim 1, wherein the gap time acquisition unit instructs the 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 of time.

5. The software update device (11, 12, 13) according to claim 1, wherein the first software and the second software are applications that execute the predetermined processing.

6. The software update device according to claim 5, wherein the first software and the second software are both in an activated state, and based on the switching instruction, 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.

7. The software updating device (14) according to claim 1, wherein the first software and the second software are drivers for controlling or operating sensors.

8. The software update device according to claim 7, wherein the first software is in an activated state and the second software is in a stopped state, and the first software is stopped and the second software is started based on the switching instruction.

9. The software update device (11, 12, 13, 14) according to claim 1, wherein the first software is software before an update, and the second software is software after an update.

10. The software update device (11, 12, 13, 14) according to claim 1, wherein the first software is the software after updating, and the second software is the software before updating.

11. The software update device (11, 12, 13, 14) according to claim 1, wherein after switching to the second software, the first software is deleted from the target device.

12. The software update device (11, 12, 13, 14) of claim 1, wherein the target device has 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 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.

13. The software update device (11, 12, 13, 14) according to claim 1, wherein the software update device is mounted on a mobile object.

14. A software update method executed by a software update device (11, 12, 13, 14) that controls software update by instructing a target device (20) on 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, the software update method comprising: acquiring, in the first software, a gap time (dt) that is the period from the input time of the input value to the output time of the output value excluding the processing period (S1002, S2009); and, if the gap time (dt) is longer than a required switching time (dk) for switching from the first software to the second software, instructing switching from the first software to the second software during the gap time (S1003, S2010, S1006).

15. A software update program executable by a software update device (11, 12, 13, 14) that controls software updates by instructing a target device (20) that has installed thereon first software that performs predetermined processing on input values ​​that are 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, wherein the software update program causes the software update device to: acquire a gap time (dt) in the first software, which is the period from the input time of the input value to the output time of the output value, excluding the processing period from the input time of the input value to the output time of the output value (S1002, S2009); and if the gap time (dt) is longer than a required time (dk) for switching from the first software to the second software, instruct the software update device to switch from the first software to the second software during the gap time (S1003, S2010, S1006).

Images