Software Update System

Abstract

To provide a software update system capable of suitably updating software.SOLUTION: An update processing unit (22) performs software update processing on an object apparatus (X-Z). A first acquisition unit (23) acquires a first parameter showing a communication state with the object apparatus (X-Z) in a state before the update processing unit (22) performs the software update processing on the object apparatus (X-Z). A second acquisition unit (24) acquires a second parameter showing a communication state with the object apparatus (X-Z) in a state after the update processing unit (22) performs the software update processing on the object apparatus (X-Z). Determination units (11, 26) determine the success / failure of the software update processing on the object apparatus (X-Z) on the basis of the first and second parameters.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to a software update system. [Background technology]

[0002] Patent Document 1 describes a software update system that includes a plurality of update target computers connected via a network, and a distribution source computer that distributes software update data to the plurality of update target computers.

[0003] The computer to be updated has a software storage unit, an update data storage unit, a backup data storage unit, and a remote installer.

[0004] The software storage unit stores data of software executed on the update target computer. The update data storage unit stores update data distributed from the distribution source computer. The backup data storage unit stores software data stored in the software storage unit for backup purposes. Upon receiving an installation instruction from the distribution source computer or another update target computer, the remote installer backs up the software data stored in the software storage unit to the backup data storage unit, then performs an update process for the software data stored in the software storage unit using the update data stored in the update data storage unit, and after the update process is completed, sends an installation instruction to at least one update target computer among the multiple update target computers whose software has not been updated. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Publication No. 2020-119094 Summary of the Invention [Problem to be solved by the invention]

[0006] However, conventional software update systems, including those disclosed in Patent Document 1, determine whether the software update was successful (whether the software was updated normally) by looking at the startup status and startup time of the computer to be updated (device to be updated), so there is room for improvement in terms of performing software updates efficiently.

[0007] For example, when updating controller software via a cloud service, it is expected that controllers at multiple locations will be updated simultaneously. In this case, if the success or failure of the controller software update is determined solely based on the startup status and startup time of the controller system, it will be impossible to detect abnormalities in the communication function between the controller and the target equipment it controls, and there is a concern that operation will continue with an abnormal communication state.

[0008] The present invention has been made in view of the above points, and one of its objects is to provide a software update system that can perform software updates in a suitable manner. [Means for solving the problem]

[0009] A software update system according to one embodiment of the present invention is characterized by having an update processing unit that performs a software update process on a target device, a first acquisition unit that acquires a first parameter that indicates the communication status with the target device before the update processing unit performs the software update process on the target device, a second acquisition unit that acquires a second parameter that indicates the communication status with the target device after the update processing unit has performed the software update process on the target device, and a judgment unit that judges whether the software update process on the target device was successful based on the first and second parameters. [Effects of the Invention]

[0010] According to the present invention, it is possible to provide a software update system that can perform software updates in an appropriate manner. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a block diagram showing a schematic configuration of a software update system according to a first embodiment. [Figure 2] FIG. 2 is a functional block diagram showing the internal configuration of a controller according to the first embodiment. [Figure 3] FIG. 2 is a functional block diagram showing the internal configuration of a software distribution server according to the first embodiment. [Figure 4] FIG. 10 is a diagram illustrating a determination of the success or failure of a software update process based on first and second parameters. [Figure 5] 10A and 10B are diagrams illustrating success / failure determination based on communication states before and after software update processing. [Figure 6] FIG. 10 is a diagram illustrating an example of whether or not to execute rollback processing depending on the importance of a target device. [Figure 7] FIG. 10 is a conceptual diagram showing a first example of control of software update processing / rollback processing based on grouping. [Figure 8] FIG. 10 is a conceptual diagram showing a second example of control of software update processing / rollback processing based on grouping. [Figure 9] FIG. 10 is a conceptual diagram showing a third example of control of software update processing / rollback processing based on grouping. [Figure 10] 4 is a timing chart showing an example of the operation of the software update system of the first embodiment. [Figure 11] FIG. 10 is a functional block diagram showing the internal configuration of a controller according to a second embodiment. [Figure 12] 10 is a timing chart showing an example of the operation of the software update system of the second embodiment. [Figure 13] 10 is a flowchart showing an example of the operation of a controller in the second embodiment. [Figure 14] 10 is a flowchart showing an example of the operation of the software distribution server in the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0012] A software update system according to this embodiment will be described in detail below with reference to the drawings. The software update system according to this embodiment can be applied to a cloud system having cloud-connected controllers that monitor and control multiple different pieces of equipment located at each base, such as a factory or a store. If a problem occurs during a software update by the controller at each base, normal system operation may be disrupted. Therefore, in large-scale systems in particular, software updates by the controllers at all bases must be performed with even greater care. Therefore, the software update system according to this embodiment is capable of realizing a configuration and operation that solves problems that occur when updating software in controllers that control various devices (target devices, target device groups) at multiple bases.

[0013] First Embodiment FIG. 1 is a block diagram showing a schematic configuration of a software update system 1 according to the first embodiment.

[0014] As shown in FIG. 1, the update system 1 has a software distribution server 10 as a host system, and a plurality of stores (bases) AI connected to the software distribution server 10 via a network.

[0015] Store A is provided with a controller 20A that ties up (overall controls) devices X, Y, and Z, store B is provided with a controller 20B that ties up (overall controls) devices X, Y, and Z, and store C is provided with a controller 20C that ties up (overall controls) devices X, Y, and Z. Devices X, Y, and Z in store AC are defined as group 1 of a group of target devices that are grouped based on predetermined device configuration information held by the software distribution server 10 (the group of target devices consisting of devices X, Y, and Z is defined as group 1).

[0016] Store D is provided with a controller 20D that ties together (overall controls) devices X and Y, store E is provided with a controller 20E that ties together (overall controls) devices X and Y, and store F is provided with a controller 20F that ties together (overall controls) devices X and Y. Devices X and Y in store DF are defined as group 2 of a group of target devices that are grouped based on predetermined device configuration information held by the software distribution server 10 (a group of target devices consisting of devices X and Y is defined as group 2).

[0017] Store G is provided with a controller 20G that ties together (overall controls) devices X and Z, store H is provided with a controller 20H that ties together (overall controls) devices X and Z, and store I is provided with a controller 20I that ties together (overall controls) devices X and Z. Devices X and Z in store GI are defined as group 3 of a group of target devices that are grouped based on predetermined device configuration information held by the software distribution server 10 (a group of target devices consisting of devices X and Z is defined as group 3).

[0018] In this way, the controllers 20A-20I bundle (overall control) target device groups (Group 1 consisting of device XZ, Group 2 consisting of device X and Y, and Group 3 consisting of device X and Z) in multiple store AIs. The software distribution server 10 bundles (overall control) the controllers 20A-20I of multiple store AIs.

[0019] The multiple store AIs may be, for example, franchise stores belonging to a large chain such as a supermarket or convenience store. In this case, the devices XY included in the multiple store AIs may be various pieces of equipment related to the store, such as an accounting system for managing sales, an employee labor management system, a surveillance camera system within the store, an information sharing system with other stores, and temperature control equipment for air conditioning, refrigerators, freezers, and warming cabinets within the store. Note that there is a degree of freedom in the number and types of stores that the software distribution server 10 manages, and various design changes are possible. There is also a degree of freedom in the locations that the software distribution server 10 manages, and they may be factories or various other facilities.

[0020] In this specification, the term "software update system 1" is used to refer to a concept including at least one of the software distribution server 10 and the controllers 20A-20I. In other words, the various functions of the software update system 1 of this embodiment can be distributed to the software distribution server 10 and the controllers 20A-20I in various variations.

[0021] 2 is a functional block diagram showing the internal configuration of the controllers 20A-20I of the first embodiment. The controllers 20A-20I each have the same (common) functional configuration to control the target devices (group of target devices) in the store under their jurisdiction. In the following description, the functional components of the controllers 20A-20I are assigned the same reference numerals.

[0022] As shown in FIG. 2, the controllers 20A-20I include an operational data collection unit 21, an update processing unit 22, a first acquisition unit 23, a second acquisition unit 24, and a rollback processing unit 25.

[0023] The operation data collection unit 21 collects operation data of target devices (groups of target devices) in stores under its jurisdiction. For example, when the operation data collection unit 21 is responsible for store AC, it collects operation data of device XZ; when the operation data collection unit 21 is responsible for store DF, it collects operation data of devices X and Y; and when the operation data collection unit 21 is responsible for store GI, it collects operation data of devices X and Z. The operation data collection by the operation data collection unit 21 is performed at predetermined time intervals (for example, every minute).

[0024] The update processing unit 22 performs software update processing on target devices (target device group) in the stores under its jurisdiction. For example, when the update processing unit 22 is responsible for store AC, it performs software update processing on device XZ; when the update processing unit 22 is responsible for store DF, it performs software update processing on devices X and Y; and when the update processing unit 22 is responsible for store GI, it performs software update processing on devices X and Z. When performing software update processing, the software distribution server 10 outputs a software update instruction to the controllers 20A-20I of each store AI, and the controllers 20A-20I that receive the update instruction download and use the software update program from the software distribution server 10. Note that even when the update processing unit 22 performs software update processing, whether the processing succeeds or fails may vary depending on the status of the other device, other communication environments, etc.

[0025] The first acquisition unit 23 acquires a first parameter indicating the communication state between the controller and the target device (a group of target devices) in a state before the update processing unit 22 performs a software update process on the target device (a group of target devices). For example, when the first acquisition unit 23 is responsible for store AC, it acquires the first parameter before the software update process is performed on device XZ; when the first acquisition unit 23 is responsible for store DF, it acquires the first parameter before the software update process is performed on devices X and Y; and when the first acquisition unit 23 is responsible for store GI, it acquires the first parameter before the software update process is performed on devices X and Z. The first parameter acquired by the first acquisition unit 23 is sent to the software distribution server 10 via the network.

[0026] The second acquisition unit 24 acquires second parameters indicating the communication state between the controller and the target devices (group of target devices) in a state after the update processing unit 22 has performed a software update process on the target devices (group of target devices). For example, the second acquisition unit 24 acquires the second parameters after the software update process on device XZ when it is responsible for store AC, acquires the second parameters after the software update process on devices X and Y when it is responsible for store DF, and acquires the second parameters after the software update process on devices X and Z when it is responsible for store GI. The second parameters acquired by the second acquisition unit 24 are sent to the software distribution server 10 via the network.

[0027] The first parameter acquired by the first acquisition unit 23 and the second parameter acquired by the second acquisition unit 24 can be, for example, a communication quality index (metric) including the bandwidth required for data to reach the destination from the source of communication, the rate at which data is discarded (loss rate), delay, and delay time variation (jitter). As such, the specific aspects of the first and second parameters have a degree of freedom, allowing for various design changes. However, it is preferable that the first and second parameters are parameters of the same dimension and type so that they can be compared.

[0028] The rollback processing unit 25 executes rollback processing to return the target device (group of target devices) from a state after the software update processing has been performed on the target device (group of target devices) to a state before the software update processing on the target device (group of target devices). That is, under predetermined conditions, under the control of the rollback control unit 12 of the software distribution server 10 (described later), the rollback processing unit 25 invalidates the software update processing performed on the target device (group of target devices) by the update processing unit 22, and returns the state to the state before the update processing.

[0029] 3 is a functional block diagram showing the internal configuration of the software distribution server 10 of the first embodiment. As shown in FIG. 3, the software distribution server 10 has a determination unit 11 and a rollback control unit 12.

[0030] The judgment unit 11 judges whether the software update process for the target devices (group of target devices) of the store AI under the jurisdiction of the controllers 20A-20I has been successful or not, based on the first parameter acquired by the first acquisition unit 23 and the second parameter acquired by the second acquisition unit 24.

[0031] More specifically, if the first and second parameters are the same, the judgment unit 11 judges that the software update process for the target device (group of target devices) has been successful, and if the first and second parameters are different, the judgment unit 11 judges that the software update process for the target device (group of target devices) has failed.

[0032] Alternatively, the determination unit 11 determines that the software update process for the target device (group of target devices) has been successful if one of the first and second parameters is within a predetermined range based on the other, and determines that the software update process for the target device (group of target devices) has failed if one of the first and second parameters is out of a predetermined range based on the other. For example, assume that the determination is made based on whether one of the first and second parameters is greater than or equal to 90% and less than or equal to 110% of the other. If one of the first and second parameters is "1.00" and the other of the first and second parameters is "0.96," the software update process is determined to have been successful because one of the first and second parameters is greater than or equal to 90% and less than or equal to 110% of the other. On the other hand, if one of the first and second parameters is "1.00" and the other of the first and second parameters is "0.82", the software update process is determined to have failed because one of the first and second parameters is not greater than 90% and less than 110% of the other.

[0033] The first and second parameters may include values ​​when communication is normal (data can be acquired normally), values ​​when communication is not possible (data does not exist) (NULL), and values ​​when data is bad (for example, a negative value is displayed instead of a positive value such as a percentage). Regardless of whether communication is normal, communication is not possible, or data is bad, if the first and second parameters are the same before and after the software update process, it may be determined that the software update process was successful, and if the first and second parameters are different before and after the software update process, it may be determined that the software update process failed.

[0034] 4A, 4B, and 4C are diagrams illustrating the success or failure of the software update process based on the first and second parameters. 4A and 4B show an example of a successful software update process, and 4C shows an example of a failed software update process.

[0035] In the example of Figures 4A-4C, the operation data of device XZ is acquired in one-minute increments from 10:00 to 10:13, and the software update process is performed from 10:05 to 10:07. Therefore, the operation data of device XZ at 10:04 is the "first parameter," and the operation data of device XZ at 10:08 is the "second parameter."

[0036] In the example of Figure 4A, the first and second parameters of device X are both the same at "0.15", the first and second parameters of device Y are both the same at "1.12", and the first and second parameters of device Z are both the same at "2.01". Therefore, it is determined that the software update process for device XZ was successful.

[0037] In the example of Figure 4B, the first and second parameters of device X are both "0.15" and the same, the first and second parameters of device Y are both "NULL" and the same, and the first and second parameters of device Z are both "2.01". Therefore, it is determined that the software update process for device XZ was successful.

[0038] In the example of FIG. 4C, for device X, the first parameter is "0.15" while the second parameter is "0.25," meaning that one of the first and second parameters is outside a predetermined range based on the other, and therefore the software update process for device X is determined to have failed. Also, for device Y, the first parameter is "1.12" while the second parameter is "NULL," meaning that the first and second parameters are significantly different (suspecting a communication failure after the update process), and therefore the software update process for device Y is determined to have failed. Also, for device Z, the first parameter is "2.01" while the second parameter is "-4.23," meaning that the first and second parameters are significantly different (suspecting a data error after the update process), and therefore the software update process for device Z is determined to have failed.

[0039] In this way, the judgment unit 11 may compare the acquisition status of the operational data before and after the software update process, and judge that the software update process was successful if there is no change in the acquisition status of the operational data before and after the software update process as shown in Figures 4A and 4B, or judge that the software update process was unsuccessful if there is a change in the acquisition status of the operational data before and after the software update process as shown in Figure 4C.

[0040] 5 is a diagram showing a success / failure determination based on the communication state before and after the software update process. As described above, if the first parameter is a value indicating normal communication before the software update process and the second parameter is a value indicating normal communication after the software update process, the software update process is determined to be successful if the first and second parameters are the same or if one of the first and second parameters is within a predetermined range based on the other (substantially the same range), and the software update process is determined to have failed if the first and second parameters are different or if one of the first and second parameters is outside the predetermined range based on the other (outside the substantially same range).

[0041] If the first parameter is a value that indicates normal communication before the software update process, and the second parameter is a value that indicates communication is not possible (e.g., NULL) or the data is incorrect (e.g., a negative value is displayed instead of a positive value such as a percentage) after the software update process, it is determined that the software update process has failed.

[0042] If the first parameter is a value indicating that communication is not possible before the software update process and the second parameter is a value indicating that communication is normal after the software update process, it is determined that the software update process has resulted in an improvement, and the software update process is determined to be successful.If the first parameter is a value indicating that communication is not possible before the software update process and the second parameter is a value indicating that communication is not possible after the software update process, it is determined that there is no effect from the software update process and the software update process is determined to be successful.If the first parameter is a value indicating that communication is not possible before the software update process and the second parameter is a value indicating that data is incorrect after the software update process, it is determined that the software update process has failed.

[0043] If the first parameter has a value of bad data before the software update process and the second parameter has a value of normal communication after the software update process, it is determined that the software update process has resulted in an improvement, and the software update process is determined to be successful.If the first parameter has a value of bad data before the software update process and the second parameter has a value of bad data after the software update process, it is determined that the software update process has failed.If the first parameter has a value of bad data before the software update process and the second parameter has a value of bad data after the software update process, it is determined that there is no effect from the software update process, and the software update process is determined to be successful.

[0044] When the determination unit 11 determines that the software update process for the target device (target device group) has failed, the rollback control unit 12 sends an instruction signal to the rollback processing unit 25 of the controllers 20A-20I to execute rollback processing to return the target device (target device group) from the state after the software update process was performed to the state before the software update process was performed on the target device (target device group). The rollback processing unit 25 of the controllers 20A-20I executes rollback processing on the target device (target device group) under its jurisdiction as appropriate, based on the instruction signal from the rollback control unit 12.

[0045] Here, the target device (target device group) is assigned multiple levels of importance that serve as criteria for determining whether or not to execute rollback processing when software update processing fails. Under the control of the rollback control unit 12, the rollback processing unit 25 executes rollback processing when the importance of the target device (target device group) is equal to or greater than a predetermined level of importance among the predetermined levels of importance, and does not execute rollback processing when the importance of the target device (target device group) is less than the predetermined level of importance among the predetermined levels of importance.

[0046] The level of harm caused by continuing to use software after an update process has failed varies depending on the predetermined importance of the target device (group of target devices) (the higher the importance, the higher the level of harm, and the lower the importance, the lower the level of harm). Therefore, if a software update process for a target device (group of target devices) with a relatively high level of importance fails, a rollback process is immediately performed, while if a software update process for a target device (group of target devices) with a relatively low level of importance fails, the software after the update process has failed is continued to be used (after which, of course, subsequent measures and treatment are taken). This makes it possible to perform software update processes and rollback processes that are optimized according to the importance of the target devices.

[0047] 6A and 6B are diagrams showing an example of whether or not rollback processing is to be executed depending on the importance of a target device (target device group).

[0048] In the example of Fig. 6A, three levels of importance, "high," "medium," and "low," are assigned to target devices (group of target devices), with the importance of device X set to "high," the importance of device Y set to "medium," and the importance of device Z set to "low." The predetermined importance that serves as the criterion for whether or not to execute rollback processing is set to "medium." If the software update processing for device XZ fails, rollback processing is executed for devices X and Y, but rollback processing is not executed for device Z.

[0049] In the example of Fig. 6B, five levels of importance are assigned to target devices (target device group) in order from highest to lowest: "5," "4," "3," "2," and "1." The importance of device X is set to "3," the importance of device Y is set to "2," and the importance of device Z is set to "5." The predetermined importance that serves as a criterion for whether or not to execute rollback processing is set to "4." If the software update processing for device XZ fails, rollback processing is executed for device Z, but rollback processing is not executed for devices X and Y.

[0050] As described above, in the software update system 1 of the first embodiment, in the controllers 20A-20I of the multiple stores (bases) AI, the first acquisition unit 23 acquires the first parameter and the second acquisition unit 24 acquires the second parameter for the target device (group of target devices) XZ, and transmits the first and second parameters to the software distribution server (host system) 10. Then, in the software distribution server 10, the determination unit 11 determines whether the software update process for the target device (group of target devices) XZ of the multiple stores (bases) AI has been successful based on the first and second parameters, and the rollback control unit 12 instructs the rollback processing unit 25 of the controllers 20A-20I of the multiple stores (bases) AI as to whether or not to execute the rollback process.

[0051] As described above, the target devices (target device groups) XZ of multiple stores (bases) AI are divided into groups based on predetermined device configuration information held by the software distribution server 10. More specifically, the target device group consisting of device XZ (corresponding to store AC) is defined as group 1, the target device group consisting of devices X and Y (corresponding to store DF) is defined as group 2, and the target device group consisting of devices X and Z (corresponding to store GI) is defined as group 3.

[0052] In the software update system 1 of the first embodiment, for each same group, after confirming that the software update process for a group of target devices at a certain store (base) is successful, the software update process is performed for a group of target devices at another store (base).

[0053] Figure 7 is a conceptual diagram showing a first example of control of software update processing / rollback processing based on grouping. The example in Figure 7 depicts store AC having a group of target devices consisting of device XZ belonging to group 1. First, store A is selected as a representative store from among stores AC belonging to group 1. Next, before performing software update processing on all stores AC belonging to group 1, software update processing is performed on representative store A. Then, after confirming that the software update processing on representative store A was successful, software update processing is performed on other stores B and C.

[0054] Since the same group has the same device configuration information, when software update processing is performed on target devices belonging to the same group, there is a high probability that the success or failure will be the same. Therefore, rather than performing software update processing simultaneously (all at once) on target devices in multiple stores belonging to the same group, by confirming that the software update processing on target devices in one store of the same group was successful and then performing software update processing on target devices in another store of the same group, it is possible to prevent the same software update processing failure (such as operation suspension due to secondary damage) from occurring on target devices in multiple stores belonging to the same group.

[0055] In the software update system 1 of the first embodiment, if the software update process for a group of target devices at a certain store (base) fails for each of the same group, the software update process for the group of target devices at another store (base) is canceled, or a rollback process is performed for the group of target devices at the other store (base).

[0056] Figure 8 is a conceptual diagram showing a second example of control of software update / rollback processing based on grouping. The example in Figure 8 depicts store AC having a group of target devices consisting of device XZ belonging to group 1. First, store A is selected as a representative store from among stores AC belonging to group 1. Next, before performing software update processing on all stores AC belonging to group 1, software update processing is performed on representative store A. If the software update processing on representative store A fails, the software update processing on the target device groups at other stores B and C is canceled, or if the update processing has already been performed, rollback processing is performed on the target device groups at other stores B and C.

[0057] Since the same group has the same device configuration information, when software update processing is performed on target devices belonging to the same group, there is a high probability that the success or failure will be the same. Therefore, rather than performing software update processing simultaneously (all at once) on target devices in multiple stores belonging to the same group, if software update processing on target devices in one store of the same group fails, the software update processing on target devices in another store of the same group is canceled, or if an update processing has already been performed, a rollback process is performed on target devices in another store of the same group, thereby preventing the same software update processing failure (such as operation suspension due to secondary damage) from occurring on target devices in multiple stores belonging to the same group.

[0058] In the software update system 1 of the first embodiment, if the software update process for a group of target devices in one of the store (base) groups fails, the software update process for the group of target devices in another store (base) group with which at least part of the device configuration information is common is canceled, or a rollback process is performed for the other store (base) group with which at least part of the device configuration information is common.

[0059] FIG. 9 is a conceptual diagram illustrating a third example of control of software update / rollback processing based on grouping. The example in FIG. 9 depicts store A having a target device group consisting of devices X and Z belonging to group 1, store D having a target device group consisting of devices X and Y belonging to group 2, and store G having a target device group consisting of devices X and Z belonging to group 3. Here, devices X and Y are used as examples of devices for determining whether at least a portion of the device configuration information is common. First, software update processing is performed for store A consisting of devices X, Y, and Z. If the software update processing for store A fails, the software update processing for devices X and Y in store D, which share at least part of the device configuration information, is canceled, or if the update processing has already been performed, rollback processing is performed for devices X and Y in store D. On the other hand, software update processing may be performed for devices X and Z in store G, which do not share at least part of the device configuration information, X and Y.

[0060] 10 is a timing chart showing an example of the operation of the software update system 1 of the first embodiment. Here, the operation of the software distribution server 10, and the controller 20A and device XZ belonging to store A will be explained as an example.

[0061] In step ST1, pre-update operating data (first parameters) is input from device X to controller 20A. In step ST2, pre-update operating data (first parameters) is input from device Y to controller 20A. In step ST3, pre-update operating data (first parameters) is input from device Z to controller 20A. The input processes of steps ST1-ST3 do not necessarily have to be performed in this order, and may be performed simultaneously.

[0062] In step ST4, an instruction to update the software of device XY is input from the software distribution server 10 to the controller 20A. In step ST5, the controller 20A requests the software distribution server 10 to update the software of device XY, and the software is downloaded.

[0063] In step ST6, the controller 20A performs software update processing on the device X. In step ST7, the controller 20A performs software update processing on the device Y. In step ST8, the controller 20A performs software update processing on the device Z. The update processing of steps ST6 to ST8 does not necessarily have to be performed in this order, and may be performed simultaneously.

[0064] In step ST9, the operating data (second parameters) after the update process is input from device X to the controller 20A. In step ST10, the operating data (second parameters) after the update process is input from device Y to the controller 20A. In step ST11, the operating data (second parameters) after the update process is input from device Z to the controller 20A. The input processes of steps ST9-ST11 do not necessarily have to be performed in this order, and may be performed simultaneously.

[0065] In step ST12, the controller 20A inputs the operating data (first and second parameters) of the device XZ before and after the update process to the software distribution server 10.

[0066] In step ST13, the software distribution server 10 determines whether the software update process for the device XZ was successful or not based on the operating data (first and second parameters) before and after the update process for the device XZ input from the controller 20A, and notifies the controller 20A of the success or failure determination. Also, in step ST13, if the software update process for any device has failed, an instruction to perform rollback processing as necessary is input from the software distribution server 10 to the controller 20A.

[0067] 10, it is assumed that the software update process for devices X and Y was successful, but the software update process for device Z failed. Therefore, rollback process is not performed for devices X and Y, and rollback process is performed only for device Z in step ST14.

[0068] Second Embodiment In the first embodiment described above, the function of the controllers 20A-20I was limited to acquiring the first and second parameters, and the success / failure of the software update process and the control of the rollback process were performed by the software distribution server 10. In contrast, in the second embodiment, the functions of the software update process success / failure and the control of the rollback process, which were performed by the software distribution server 10 in the first embodiment, are installed in the controllers 20A-20I.

[0069] 11 is a functional block diagram showing the internal configuration of controllers 20A-20I of the second embodiment. The same reference numerals are used to designate parts that are common to the first embodiment (FIG. 2), and redundant explanations will be omitted.

[0070] As shown in FIG. 11, the controllers 20A-20I have an operational data collection unit 21, an update processing unit 22, a first acquisition unit 23, a second acquisition unit 24, as well as a judgment unit 26 and a rollback control processing unit 27.

[0071] The determination unit 26 determines whether the software update process for the target devices (group of target devices) of the store AI managed by the controllers 20A-20I has been successful, based on the first parameter acquired by the first acquisition unit 23 and the second parameter acquired by the second acquisition unit 24. The determination method used by the determination unit 26 is the same as (common to) the determination method used by the determination unit 11 of the first embodiment.

[0072] When the determination unit 26 determines that the software update process for the target device (target device group) has failed, the rollback control processing unit 27 executes rollback processing to return the target device (target device group) from the state after the software update process was executed to the state before the software update process was executed for the target device (target device group). While the rollback processing unit 25 in the first embodiment executes rollback processing in accordance with an instruction signal from the software distribution server 10, the rollback control processing unit 27 in the second embodiment also determines whether or not to execute rollback processing.

[0073] 12 is a timing chart showing an example of the operation of the software update system 1 of the second embodiment. Here, the operation of the software distribution server 10, and the controller 20A and device XZ belonging to store A will be explained as an example. The processing of steps ST1-ST11 is the same as that of the timing chart of FIG. 10 of the first embodiment, so duplicated explanations will be omitted.

[0074] In step ST15, the controller 20A (determination unit 26) determines whether the software update process for the device XZ has succeeded or failed based on the operating data (first and second parameters) before and after the update process for the device XZ, and notifies the software distribution server 10 of the success or failure determination. In step ST16, if there is any device for which the software update process has failed, the controller 20A (rollback control processing unit 27) executes rollback processing for that device.

[0075] 12, it is assumed that the software update process has been successful for devices X and Z, but has failed for device Y. Therefore, rollback processing is not performed for devices X and Z, and rollback processing is performed only for device Y in step ST16.

[0076] Fig. 13 is a flowchart showing an example of the operation of the controller in the second embodiment. Fig. 13 shows the operation after the software update process is executed on the target device (target device group).

[0077] In step ST21, the operating data (first and second parameters) before and after the software update process is acquired. In step ST22, the operating data (first and second parameters) before and after the software update process are compared.

[0078] In step ST23, it is determined based on the comparison in step ST22 whether or not an abnormality has occurred due to the software update process (whether the update process was successful). If an abnormality has occurred due to the software update process (if the update process has failed) (step ST23: YES), the process proceeds to step ST24. If an abnormality has not occurred due to the software update process (if the update process has succeeded) (step ST23: NO), the process proceeds to step ST26.

[0079] In step ST24, it is determined whether the importance of the device in which the abnormality due to the software update process has occurred is high (whether the importance is equal to or higher than a predetermined level of importance among multiple predetermined levels of importance). If the importance of the device in which the abnormality due to the software update process has occurred is high (step ST24: YES), the process proceeds to step ST25. In step ST25, rollback processing is executed for the device in which the abnormality due to the software update process has occurred and is of high importance. On the other hand, if the importance of the device in which the abnormality due to the software update process has occurred is not high (step ST24: NO), the process proceeds to step ST26.

[0080] In step ST26, it is determined whether or not the determination of all devices has been completed. If the determination of all devices has not been completed (step ST26: NO), the process returns to step ST21, and steps ST21 to ST26 are repeated until the determination of all devices has been completed. If the determination of all devices has been completed (step ST26: YES), the process proceeds to step ST27, and the results of the software update process / rollback process are notified to the upper system (software distribution server), and the process ends.

[0081] FIG. 14 is a flowchart showing an example of the operation of the software distribution server in the second embodiment.

[0082] In step ST31, a representative store among the stores belonging to the same group is instructed to perform software update processing. In step ST32, the result of the software update process success / failure determination is received from the representative store.

[0083] In step ST33, it is confirmed whether or not an abnormality has occurred due to the software update process for the representative store (whether the update process was successful). If no abnormality has occurred due to the software update process for the representative store (if the update process was successful) (step ST33: NO), the process proceeds to step ST34, where the other stores among the multiple stores belonging to the same group are instructed to also perform the software update process, and then the process ends. On the other hand, if an abnormality has occurred due to the software update process (if the update process failed) (step ST33: YES), the process proceeds to step ST35.

[0084] In step ST35, the software update process is stopped for the other stores among the stores belonging to the same group, and in step ST36, the equipment configurations of the stores belonging to the other groups are checked.

[0085] In step ST37, it is determined whether or not there is an abnormal device in a store belonging to another group (whether or not there is the same device as the one for which the update process failed in the representative store). If there is no abnormal device in a store belonging to another group (step ST37: NO), the process ends. If there is an abnormal device in a store belonging to another group (step ST37: YES), the process proceeds to step ST38.

[0086] In step ST38, it is determined whether software update processing has been performed for the store in the other group where the abnormal device is located. If software update processing has been performed for the store in the other group where the abnormal device is located (step ST38: YES), the process proceeds to step ST39, where an instruction to execute rollback processing is issued for all stores in the other group, and the process ends. If software update processing has not been performed for the store in the other group where the abnormal device is located (step ST38: NO), the process proceeds to step ST40, where software update processing is stopped for the store in the other group, and the process ends.

[0087] The software update system of this embodiment includes an update processing unit that performs software update processing on a target device, a first acquisition unit that acquires a first parameter that indicates the communication status with the target device in a state before the update processing unit performs software update processing on the target device, a second acquisition unit that acquires a second parameter that indicates the communication status with the target device in a state after the update processing unit has performed software update processing on the target device, and a judgment unit that judges whether the software update processing on the target device was successful based on the first and second parameters.

[0088] In this way, first and second parameters indicating the communication state before and after the software update process for the target device are obtained, and the success or failure of the software update process for the target device is determined based on (compared to) the first and second parameters, so that the software update for the target device can be carried out in an optimal manner.

[0089] The determination unit determines that the software update process for the target device has been successful if the first and second parameters are the same or if one of the first and second parameters is within a predetermined range based on the other, and determines that the software update process for the target device has failed if the first and second parameters are different or if one of the first and second parameters is outside a predetermined range based on the other.

[0090] This makes it possible to improve the accuracy of determining whether the software update process for the target device has been successful using the first and second parameters.

[0091] The software update system of this embodiment further has a rollback processing unit that, when the determination unit determines that the software update process for the target device has failed, returns the target device to a state before the software update process was performed on the target device from the state after the software update process was performed on the target device.

[0092] In this way, by performing a rollback process when the software update process for the target device fails, it is possible to eliminate the adverse effects that may occur when the software is continued to be used after the update process has failed.

[0093] The rollback processing unit executes the rollback processing when the importance of the target device is equal to or greater than a predetermined importance level among a plurality of predetermined importance levels, and does not execute the rollback processing when the importance of the target device is less than the predetermined importance level among a plurality of predetermined importance levels.

[0094] The level of harm caused by continuing to use software after an update process has failed varies depending on the predetermined importance of the target device (the higher the importance, the higher the level of harm, and the lower the importance, the lower the level of harm). Therefore, if a software update process for a target device with a relatively high importance fails, a rollback process is immediately performed, while if a software update process for a target device with a relatively low importance fails, the software after the update process has failed is continued to be used rather than an immediate rollback process. This makes it possible to perform software update processes and rollback processes optimized according to the importance of the target device.

[0095] The software update system of this embodiment includes a controller that bundles target device groups at multiple locations, and a host system that bundles the controllers at the multiple locations, and in the controllers at the multiple locations, the first acquisition unit acquires the first parameter for the target device group, the second acquisition unit acquires the second parameter, and the first and second parameters are sent to the host system, and in the host system, the determination unit determines whether the software update process for the target device groups at the multiple locations was successful based on the first and second parameters, and a rollback control unit instructs the controllers at the multiple locations whether or not to execute the rollback process.

[0096] This allows, for example, when updating controller software using a cloud service, controllers at multiple locations to execute appropriate software update and rollback processes for target devices under the control of a higher-level system.

[0097] The target equipment groups at the multiple locations are divided into groups based on predetermined equipment configuration information held by the upper system, and for each group, after confirming that the software update process for the target equipment group at one location has been successful, the software update process is performed for the target equipment group at another location.

[0098] Since the same group has the same device configuration information, when software update processing is performed on target devices belonging to the same group, there is a high probability that the success or failure will be the same. Therefore, rather than performing software update processing simultaneously (all at once) on target devices at multiple locations belonging to the same group, by confirming that the software update processing on target devices at one location in the same group was successful, and then performing software update processing on target devices at another location in the same group, it is possible to prevent the same software update processing failure (such as operation suspension due to secondary damage) from occurring on target devices at multiple locations belonging to the same group.

[0099] The target equipment groups at the multiple locations are divided into groups based on predetermined equipment configuration information held by the upper system, and for each group, if a software update process for the target equipment group at one location fails, the software update process for the target equipment group at another location is canceled, or a rollback process is performed for the target equipment group at another location.

[0100] Since the same group has the same device configuration information, when software update processing is performed on target devices belonging to the same group, there is a high probability that the success or failure will be the same. Therefore, rather than performing software update processing simultaneously (all at once) on target devices at multiple locations belonging to the same group, if software update processing on target devices at one location in the same group fails, the software update processing on target devices at another location in the same group can be canceled, or a rollback process can be performed on target devices at another location in the same group, thereby preventing the same software update processing failure from occurring (such as operation suspension due to secondary damage) on target devices at multiple locations belonging to the same group.

[0101] The target device groups at the multiple locations are grouped based on predetermined device configuration information held by the upper system, and if the software update process for the target device group at one of the locations fails, the software update process for the target device group at another location group with which at least part of the device configuration information is common is canceled, or a rollback process is performed for the target device group at another location group with which at least part of the device configuration information is common.

[0102] Even if the groups are located at different bases, if the groups share at least some of the device configuration information, there is a high probability that the success or failure of software update processing on target devices belonging to these groups will be the same. Therefore, if the software update processing on target devices in one of the groups at a base fails, the software update processing on target devices in the other group at a base that shares at least some of the device configuration information can be canceled, or a rollback process can be performed on the other group at a base that shares at least some of the device configuration information, thereby preventing the same software update processing failure (such as operation suspension due to secondary damage) from occurring on target devices in multiple bases that belong to groups that share at least some of the device configuration information.

[0103] The present invention is not limited to the above-described embodiments and modifications, and may be variously changed, substituted, or modified within the scope of the spirit of the technical idea. Furthermore, if the technical idea can be realized in a different way due to technological advances or other derived technologies, it may be implemented using that method. Therefore, the claims cover all embodiments that may fall within the scope of the technical idea. [Industrial Applicability]

[0104] The software update system of the present invention can be applied to a cloud system having a cloud-connected controller that monitors and controls a plurality of different pieces of equipment located at each base such as a factory or store. [Explanation of symbols]

[0105] 1 Software Update System 10 Software distribution server (host system) 11 Judgment section 12 Rollback control section 20A-20I Controller 21 Operational Data Collection Unit 22 Update processing section 23 First Acquisition Section 24 Second Acquisition Section 25 Rollback processing section 26 Judgment section 27 Rollback control processing section

Claims

1. an update processing unit that performs software update processing on the target device; a first acquisition unit that acquires a first parameter indicating a communication state between the target device and the update processing unit before the update processing unit performs a software update process on the target device; a second acquisition unit that acquires a second parameter indicating a communication state with the target device in a state after the update processing unit has performed a software update process on the target device; a determination unit that determines whether the software update process for the target device has been successful based on the first and second parameters; A software update system comprising:

2. The determination unit If the first and second parameters are the same, or if one of the first and second parameters is within a predetermined range based on the other, it is determined that the software update process for the target device has been successful; If the first and second parameters are different, or if one of the first and second parameters is outside a predetermined range based on the other, it is determined that the software update process for the target device has failed.

2. The software update system according to claim 1.

3. a rollback processing unit that, when the determination unit determines that the software update process for the target device has failed, executes a rollback process to return the target device from a state after the software update process has been performed to a state before the software update process for the target device.

3. The software update system according to claim 1 or 2.

4. The rollback processing unit executes the rollback process when the importance of the target device is equal to or greater than a predetermined importance level among a plurality of levels of importance that have been determined in advance; When the importance of the target device is less than a predetermined importance level among a plurality of predetermined importance levels, the rollback process is not executed.

4. The software update system according to claim 3.

5. A controller that bundles target devices at multiple locations, a host system that bundles together the controllers of the plurality of bases; and In the controllers of the plurality of bases, the first acquisition unit acquires the first parameter, the second acquisition unit acquires the second parameter for the target device group, and the first and second parameters are transmitted to the host system; In the host system, the determination unit determines whether the software update process for the target devices at the plurality of bases has been successful based on the first and second parameters, and a rollback control unit instructs the controllers at the plurality of bases as to whether or not to execute the rollback process.

5. The software update system according to claim 3 or 4.

6. the target devices at the plurality of bases are grouped based on predetermined device configuration information held by the upper system, For each group, after confirming that the software update process for the target devices at one location has been successful, perform the software update process for the target devices at another location.

6. The software update system according to claim 5.

7. the target devices at the plurality of bases are grouped based on predetermined device configuration information held by the upper system, For each group, if a software update process for a group of target devices at a certain location fails, the software update process for a group of target devices at another location is canceled, or a rollback process is performed for the group of target devices at another location.

6. The software update system according to claim 5.

8. the target devices at the plurality of bases are grouped based on predetermined device configuration information held by the upper system, If a software update process for a target device group fails in one of the groups at a base, the software update process for the target device group in another group at a base with which at least a part of the device configuration information is common is canceled, or a rollback process is performed for the group at another group at a base with which at least a part of the device configuration information is common.

6. The software update system according to claim 5.

Images