JP7809967B2 - Software Update System - Google Patents

Description

The present invention relates to a software update system.

Patent Document 1 describes a software update system that includes multiple update target computers connected via a network and a distribution source computer that distributes software update data to the multiple update target computers.

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

The software storage unit stores data for 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 complete, sends an installation instruction to at least one update target computer among the multiple update target computers whose software has not been updated.

Japanese Patent Application Laid-Open No. 2020-119094

However, conventional software update systems, including those described 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 optimally performing software updates.

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 functions between the controller and the target equipment it controls, raising concerns that operation may continue with a communication abnormality.

The present invention was made in consideration of these points, and one of its objectives is to provide a software update system that can perform software updates efficiently.

One aspect of the present invention is a software update system comprising: an update processing unit that performs a software update process on a target device; a first acquisition unit that acquires a first parameter indicating 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 indicating the communication status with the target device after the update processing unit has performed the software update process on the target device; and a determination unit that determines the success or failure of the software update process on the target device based on the first and second parameters.

The present invention provides a software update system that can efficiently perform software updates.

1 is a block diagram showing a schematic configuration of a software update system according to a first embodiment; FIG. 2 is a functional block diagram showing the internal configuration of a controller according to the first embodiment. FIG. 2 is a functional block diagram showing the internal configuration of a software distribution server according to the first embodiment. FIG. 10 is a diagram illustrating a determination of success or failure of a software update process based on first and second parameters. 10A and 10B are diagrams illustrating success/failure determination based on communication states before and after software update processing. FIG. 10 is a diagram illustrating an example of whether or not to execute rollback processing depending on the importance of a target device. FIG. 10 is a conceptual diagram showing a first example of control of software update processing/rollback processing based on grouping. FIG. 10 is a conceptual diagram showing a second example of control of software update processing/rollback processing based on grouping. FIG. 10 is a conceptual diagram showing a third example of control of software update processing/rollback processing based on grouping. 4 is a timing chart showing an example of an operation of the software update system of the first embodiment. FIG. 10 is a functional block diagram showing the internal configuration of a controller according to a second embodiment. 10 is a timing chart showing an example of an operation of the software update system of the second embodiment. 10 is a flowchart showing an example of an operation of a controller in the second embodiment. 10 is a flowchart showing an example of the operation of the software distribution server in the second embodiment.

The 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 store. If a problem occurs during a software update by the controller at each base, normal system operation may be disrupted, and in large-scale systems in particular, software updates by the controllers at all bases must be carried out 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.

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

As shown in Figure 1, the update system 1 has a software distribution server 10 as a host system and multiple stores (bases) A-I connected to the software distribution server 10 via a network.

Store A is equipped with controller 20A that ties together (overall controls) devices X, Y, and Z, store B is equipped with controller 20B that ties together (overall controls) devices X, Y, and Z, and store C is equipped with controller 20C that ties together (overall controls) devices X, Y, and Z. Devices X, Y, and Z in stores A-C are defined as group 1 of a group of target devices that are grouped based on specific 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).

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

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

In this way, controllers 20A-20I bundle (overall control) target device groups (Group 1 consisting of devices X-Z, Group 2 consisting of devices X and Y, and Group 3 consisting of devices X and Z) at multiple stores A-I. The software distribution server 10 bundles (overall control) controllers 20A-20I at multiple stores A-I.

The multiple stores A-I may be, for example, franchise stores belonging to a large chain such as a supermarket or convenience store. In this case, the devices X-Y included in the multiple stores A-I may be various pieces of store-related equipment, such as an accounting system for managing sales, an employee labor management system, an in-store surveillance camera system, an information sharing system with other stores, and temperature control equipment for in-store air conditioning, refrigerators, freezers, and warming cabinets. The number and types of stores managed by the software distribution server 10 are flexible, allowing for various design changes. The locations managed by the software distribution server 10 are also flexible, and could be factories and various other facilities.

In this specification, the term "software update system 1" is used to refer to the software distribution server 10 and/or the controllers 20A-20I. In other words, the various functions of the software update system 1 of this embodiment can be allocated to the software distribution server 10 and the controllers 20A-20I in a variety of ways.

Figure 2 is a functional block diagram showing the internal configuration of controllers 20A-20I in the first embodiment. Controllers 20A-20I each have the same (common) functional configuration to control the target devices (groups of target devices) in the stores under their jurisdiction. In the following description, the functional components of controllers 20A-20I will be assigned the same reference numerals.

As shown in FIG. 2, 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, and a rollback processing unit 25.

The operation data collection unit 21 collects operation data for target devices (groups of target devices) in the stores under its jurisdiction. For example, if the operation data collection unit 21 is responsible for stores A-C, it collects operation data for devices X-Z; if it is responsible for stores D-F, it collects operation data for devices X and Y; and if it is responsible for stores G-I, it collects operation data for devices X and Z. The operation data collection unit 21 collects operation data at predetermined time intervals (for example, every minute).

The update processing unit 22 performs software updates on target devices (groups of target devices) in the stores under its jurisdiction. For example, when the update processing unit 22 is responsible for stores A-C, it performs software updates on devices X-Z; when the update processing unit 22 is responsible for stores D-F, it performs software updates on devices X and Y; and when the update processing unit 22 is responsible for stores G-I, it performs software updates on devices X and Z. When performing a software update, the software distribution server 10 outputs a software update instruction to the controllers 20A-20I of each store A-I, 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 a software update, whether the process succeeds or fails may vary depending on the status of the other device and other communication environments, etc.

The first acquisition unit 23 acquires a first parameter indicating the communication state between the controller and the target device (group of target devices) before the update processing unit 22 performs a software update process on the target device (group of target devices). For example, if the first acquisition unit 23 is responsible for stores A-C, it acquires the first parameter before the software update process is performed on devices X-Z; if the first acquisition unit 23 is responsible for stores D-F, it acquires the first parameter before the software update process is performed on devices X and Y; and if the first acquisition unit 23 is responsible for stores G-I, 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.

The second acquisition unit 24 acquires second parameters indicating the communication state between the controller and the target device (group of target devices) after the update processing unit 22 has performed a software update process on the target device (group of target devices). For example, if the second acquisition unit 24 is responsible for stores A-C, it acquires second parameters after the software update process on devices X-Z; if the second acquisition unit 24 is responsible for stores D-F, it acquires second parameters after the software update process on devices X and Y; and if the second acquisition unit 24 is responsible for stores G-I, it acquires second parameters after the software update process on devices X and Z. The second parameters acquired by the second acquisition unit 24 are sent to the software distribution server 10 via the network.

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

The rollback processing unit 25 executes rollback processing to return the target device (group of target devices) from the state after the software update processing has been performed to the state before the software update processing was performed on the target device (group of target devices). In other words, under predetermined conditions, and under the control of the rollback control unit 12 of the software distribution server 10 (described below), 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.

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

The determination unit 11 determines the success or failure of the software update process for the target devices (group of target devices) in stores A-I under the jurisdiction of the controllers 20A-20I based on the first parameters acquired by the first acquisition unit 23 and the second parameters acquired by the second acquisition unit 24.

More specifically, if the first and second parameters are the same, the determination unit 11 determines that the software update process for the target device (group of target devices) was successful, and if the first and second parameters are different, the determination unit 11 determines that the software update process for the target device (group of target devices) was unsuccessful.

Alternatively, the determination unit 11 determines that the software update process for the target device (group of target devices) was 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) was unsuccessful if one of the first and second parameters is outside the predetermined range based on the other. For example, consider a case in which 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 is "0.96," the software update process is determined to be 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 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.

The first and second parameters may include values for normal communication (data can be acquired normally), values for no communication (NULL) (no data exists), and values for bad data (abnormal values) (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, the software update process may be determined to have been successful. If the first and second parameters are different before and after the software update process, the software update process may be determined to have failed.

Figures 4A, 4B, and 4C are diagrams showing how the success or failure of a software update process is determined based on the first and second parameters. Figures 4A and 4B show an example of a successful software update process, while Figure 4C shows an example of a failed software update process.

In the example of Figures 4A-4C, the operational data of devices X-Z was acquired in one-minute increments from 10:00 to 10:13, and the software update process was performed from 10:05 to 10:07. Therefore, the operational data of devices X-Z at 10:04 is the "first parameter," and the operational data of devices X-Z at 10:08 is the "second parameter."

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 devices X-Z was successful.

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 devices X-Z was successful.

In the example of Figure 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 the specified 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 (raising the possibility of communication failure after the update), 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 (raising the possibility of data corruption after the update), and therefore the software update process for device Z is determined to have failed.

In this way, the determination unit 11 compares the operational data acquisition status before and after the software update process, and may determine that the software update process was successful if there is no change in the operational data acquisition status before and after the software update process, as shown in Figures 4A and 4B, or may determine that the software update process failed if there is a change in the operational data acquisition status before and after the software update process, as shown in Figure 4C.

Figure 5 shows the 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). However, 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 (substantially the same range), the software update process is determined to have failed.

If the first parameter is a value indicating normal communication before the software update process, and the second parameter is a value indicating 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), the software update process is determined to have failed.

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 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 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 impact 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 incorrect 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 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.

When the determination unit 11 determines that the software update process for the target device (group of target devices) 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, which restores the state of the target device (group of target devices) from the state after the software update process was performed to the state before the software update process was performed. The rollback processing unit 25 of the controllers 20A-20I appropriately executes rollback processing for the target device (group of target devices) under its jurisdiction based on the instruction signal from the rollback control unit 12.

Here, the target device (group of target devices) is assigned multiple levels of importance that serve as the criteria for determining whether or not to execute rollback processing if the software update processing fails. Then, under the control of the rollback control unit 12, the rollback processing unit 25 executes rollback processing if the importance of the target device (group of target devices) is equal to or greater than a predetermined level of importance from the multiple levels of importance that have been determined in advance, and does not execute rollback processing if the importance of the target device (group of target devices) is less than the predetermined level of importance from the multiple levels of importance that have been determined in advance.

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 rather than an immediate rollback process (after which, of course, subsequent responses and adjustments are made). This allows software update processes and rollback processes to be optimized according to the importance of the target devices.

Figures 6A and 6B show an example of whether or not rollback processing is performed depending on the importance of the target device (group of target devices).

In the example of Figure 6A, three levels of importance are assigned to target devices (group of target devices): "high," "medium," and "low." The importance of device X is set to "high," the importance of device Y to "medium," and the importance of device Z to "low." The predetermined importance level that serves as the criterion for whether or not to perform rollback processing is set to "medium." If the software update processing for devices X-Z fails, rollback processing is performed on devices X and Y, but not on device Z.

In the example of Figure 6B, five levels of importance are assigned to the target devices (group of target devices) 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 level that serves as the criterion for whether or not to perform rollback processing is set to "4." If the software update processing for devices X-Z fails, rollback processing is performed on device Z, but rollback processing is not performed on devices X and Y.

In this way, in the software update system 1 of the first embodiment, in the controllers 20A-20I of the multiple stores (locations) A-I, the first acquisition unit 23 acquires a first parameter and the second acquisition unit 24 acquires a second parameter for the target devices (groups of target devices) X-Z, 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 the success or failure of the software update process for the target devices (groups of target devices) X-Z of the multiple stores (locations) A-I 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 (locations) A-I as to whether or not to execute the rollback process.

As mentioned above, the target devices (target device groups) X-Z of multiple stores (bases) A-I are grouped based on specific device configuration information held by the software distribution server 10. More specifically, the target device group consisting of devices X-Z (corresponding to stores A-C) is defined as Group 1, the target device group consisting of devices X and Y (corresponding to stores D-F) is defined as Group 2, and the target device group consisting of devices X and Z (corresponding to stores G-I) is defined as Group 3.

In the software update system 1 of the first embodiment, for each group, after confirming that the software update process for the target devices at one store (base) has been successful, the software update process is performed for the target devices at another store (base).

Figure 7 is a conceptual diagram showing a first example of controlling software update/rollback processing based on grouping. The example in Figure 7 depicts stores A-C, which have a target device group consisting of devices X-Z that belong to group 1. First, store A is selected as a representative store from stores A-C that belong to group 1. Next, before performing software update processing for all stores A-C that belong to group 1, the software update processing is performed for representative store A. Then, after confirming that the software update processing for representative store A was successful, the software update processing is performed for other stores B and C.

Since devices in the same group share the same device configuration information, there is a high probability that software updates performed on devices in the same group will have the same success or failure. Therefore, rather than simultaneously (all at once) updating software on devices in multiple stores in the same group, you can confirm that the software update was successful on devices in one store in the same group before updating devices in another store in the same group. This prevents the same software update failure (such as secondary damage causing operational outages) from occurring on devices in multiple stores in the same group.

In the first embodiment of the software update system 1, if the software update process for a group of target devices at one store (base) fails for each 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 another store (base).

Figure 8 is a conceptual diagram showing a second example of controlling software update/rollback processing based on grouping. The example in Figure 8 depicts stores A-C, which have a target device group consisting of devices X-Z that belong to group 1. First, store A is selected as a representative store from stores A-C that belong to group 1. Next, before performing software update processing on all stores A-C that belong to group 1, a 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 of other stores B and C is canceled, or if the update processing has already been performed, a rollback processing is performed on the target device groups of other stores B and C.

Since the same group has the same device configuration information, there is a high probability that software updates performed on target devices belonging to the same group will have the same success or failure. Therefore, rather than performing software updates simultaneously (all at once) on target devices in multiple stores belonging to the same group, if a software update fails on target devices in one store in the same group, the software update for target devices in another store in the same group can be canceled, or if an update has already been performed, a rollback can be performed on target devices in another store in the same group. This can prevent the same software update failure (such as secondary damage causing operational suspension) from occurring on target devices in multiple stores belonging to the same group.

In the first embodiment of the software update system 1, 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 some of the device configuration information is shared is canceled, or a rollback process is performed for the other store (base) group with which at least some of the device configuration information is shared.

Figure 9 is a conceptual diagram showing a third example of controlling software update/rollback processing based on grouping. The example in Figure 9 depicts store A, which has a target device group consisting of devices X-Z belonging to group 1; store D, which has a target device group consisting of devices X and Y belonging to group 2; and store G, which has 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, which consists 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, consisting of devices X and Y.

Figure 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, the controller 20A belonging to store A, and devices X-Z will be explained as an example.

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.

In step ST4, the software distribution server 10 inputs an instruction to update the software for device XY to the controller 20A. In step ST5, the controller 20A requests the software distribution server 10 to update the software for device XY, and the program is downloaded.

In step ST6, controller 20A performs a software update process on device X. In step ST7, controller 20A performs a software update process on device Y. In step ST8, controller 20A performs a software update process on device Z. The update processes in steps ST6-ST8 do not necessarily have to be performed in this order, and may be performed simultaneously.

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

In step ST12, the operating data (first and second parameters) for devices X-Z before and after the update process are input from controller 20A to software distribution server 10.

In step ST13, the software distribution server 10 determines whether the software update process for device X-Z was successful based on the operating data (first and second parameters) before and after the update process for device X-Z input from controller 20A, and notifies controller 20A of the success/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 software distribution server 10 to controller 20A.

In the example of Figure 10, it is assumed that the software update process was successful for devices X and Y, but failed for device Z. Therefore, rollback processing is not performed for devices X and Y, and in step ST14, rollback processing is performed only for device Z.

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.

Figure 11 is a functional block diagram showing the internal configuration of controllers 20A-20I in the second embodiment. Parts that are common to the first embodiment (Figure 2) are given the same reference numerals, and redundant explanations will be omitted.

As shown in FIG. 11, 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, a determination unit 26, and a rollback control processing unit 27.

The determination unit 26 determines the success or failure of the software update process for the target devices (group of target devices) in stores A-I under the jurisdiction of the controllers 20A-20I, based on the first parameters acquired by the first acquisition unit 23 and the second parameters 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 in the first embodiment.

When the determination unit 26 determines that the software update process for the target device (group of target devices) has failed, the rollback control processing unit 27 executes rollback processing to return the target device (group of target devices) from the state after the software update process was performed to the state before the software update process was performed. While the rollback processing unit 25 in the first embodiment performed 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 perform rollback processing.

Figure 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, the controller 20A belonging to store A, and devices X-Z will be explained as an example. The processing of steps ST1-ST11 is the same as the timing chart of Figure 10 of the first embodiment, so duplicate explanations will be omitted.

In step ST15, controller 20A (determination unit 26) determines whether the software update process for device X-Z was successful based on the operating data (first and second parameters) before and after the update process for device X-Z, and notifies the software distribution server 10 of the success/failure determination. In step ST16, if there is any device for which the software update process failed, controller 20A (rollback control processing unit 27) executes rollback processing for that device.

In the example of Figure 12, it is assumed that the software update process was successful for devices X and Z, but failed for device Y. Therefore, rollback processing is not performed for devices X and Z, and in step ST16, rollback processing is performed only for device Y.

Figure 13 is a flowchart showing an example of the operation of the controller in the second embodiment. Figure 13 shows the operation after the software update process has been executed for the target device (group of target devices).

In step ST21, operational data (first and second parameters) before and after the software update process are acquired. In step ST22, the operational data (first and second parameters) before and after the software update process are compared.

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

In step ST24, it is determined whether the importance of the device in which the abnormality due to the software update process occurred is high (whether it is at or above a certain 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 occurred is high (step ST24: YES), proceed to step ST25. In step ST25, rollback processing is performed on the device in which the abnormality due to the software update process 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 occurred is not high (step ST24: NO), proceed to step ST26.

In step ST26, it is determined whether the evaluation of all devices has been completed. If the evaluation of all devices has not been completed (step ST26: NO), the process returns to step ST21 and repeats steps ST21 to ST26 until the evaluation of all devices has been completed. If the evaluation of all devices has been completed (step ST26: YES), the process proceeds to step ST27, where the results of the software update/rollback process are notified to the higher-level system (software distribution server), and the process ends.

Figure 14 is a flowchart showing an example of the operation of the software distribution server in the second embodiment.

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

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 other stores in the same group are instructed to also perform the software update process, and 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.

In step ST35, the software update process is stopped for other stores among the multiple stores belonging to the same group. In step ST36, the equipment configuration of stores belonging to other groups is checked.

In step ST37, it is determined whether there is an abnormal device in a store belonging to another group (whether 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), proceed to step ST38.

In step ST38, it is determined whether software updates have been performed for the stores in the other group where the malfunctioning device is located. If software updates have been performed for the stores in the other group where the malfunctioning device is located (step ST38: YES), proceed to step ST39, issue an instruction to execute rollback processing for all stores in the other group, and then terminate processing. If software updates have not been performed for the stores in the other group where the malfunctioning device is located (step ST38: NO), proceed to step ST40, stop software updates for the stores in the other group, and then terminate processing.

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 indicating the communication status with the target device before the update processing unit performs the software update processing on the target device; a second acquisition unit that acquires a second parameter indicating the communication status with the target device after the update processing unit has performed the software update processing on the target device; and a determination unit that determines the success or failure of the software update processing on the target device based on the first and second parameters.

In this way, first and second parameters indicating the communication status 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, allowing the software update for the target device to be carried out optimally.

The determination unit determines that the software update process for the target device was 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 was unsuccessful 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.

This improves the accuracy of determining whether the software update process for the target device using the first and second parameters was successful.

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

In this way, by performing a rollback process if the software update process for the target device fails, it is possible to eliminate the negative effects of continuing to use the software after the update process has failed.

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

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 level of importance fails, a rollback process is immediately performed, while if a software update process for a target device with a relatively low level of importance fails, the software after the update process has failed is continued to be used rather than an immediate rollback process. This allows software update processes and rollback processes to be performed that are optimized according to the importance of the target device.

The software update system of this embodiment includes controllers that manage target device groups at multiple bases and a host system that manages the controllers at the multiple bases. In the controllers at the multiple bases, 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. In the host system, the determination unit determines the success or failure of the software update process for the target device group at the multiple bases based on the first and second parameters, and a rollback control unit instructs the controllers at the multiple bases whether or not to execute the rollback process.

This means that, for example, when updating controller software via a cloud service, controllers at multiple locations can perform appropriate software update and rollback processes for target devices under the control of a higher-level system.

The target devices at the multiple locations are grouped based on the specified device configuration information held by the host system, and for each group, after confirming that the software update process for the target devices at one location has been successful, the software update process is performed for the target devices at another location.

Since the same group has the same device configuration information, there is a high probability that when software updates are performed on target devices belonging to the same group, the success or failure will be the same. Therefore, rather than performing software updates simultaneously (all at once) on target devices at multiple locations belonging to the same group, you can confirm that the software update process for target devices at one location in the same group was successful before performing the software update process for target devices at another location in the same group, thereby preventing the same software update process from failing (such as causing operational suspension due to secondary damage) on target devices at multiple locations belonging to the same group.

The target devices at the multiple locations are grouped based on the specified device configuration information held by the host system, and for each group, if a software update process for the target devices at one location fails, the software update process for the target devices at another location is canceled, or a rollback process is performed for the target devices at the other location.

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

The target device groups at the multiple locations are grouped based on specified 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 with which at least part of the device configuration information is shared is canceled, or a rollback process is performed for the target device group at another location with which at least part of the device configuration information is shared.

Even if the groups are located at different bases, if the groups share at least some of their device configuration information, there is a high probability that the success or failure of software updates performed on the target devices belonging to these groups will be the same. Therefore, if a software update fails for a target device group at one of the base groups, the software update for the target device group at the other base group with at least some of the device configuration information can be canceled, or a rollback process can be performed for the target device group at the other base group with at least some of the device configuration information. This can prevent the same software update failure (such as operational suspension due to secondary damage) from occurring for target devices at multiple bases that belong to groups with at least some of the device configuration information in common.

The present invention is not limited to the above-described embodiments and modifications, and may be modified, substituted, or altered in various ways without departing from the spirit of the technical concept. Furthermore, if technological advances or derived technologies allow the technical concept to be realized in a different way, the invention may be implemented using that method. Therefore, the claims cover all embodiments that may fall within the scope of the technical concept.

The software update system of the present invention can be applied, for example, to a cloud system having a cloud-connected controller that monitors and controls multiple different pieces of equipment located at each base, such as a factory or store.

1 Software update system 10 Software distribution server (host system)
11 Determination unit 12 Rollback control units 20A-20I Controller 21 Operational data collection unit 22 Update processing unit 23 First acquisition unit 24 Second acquisition unit 25 Rollback processing unit 26 Determination unit 27 Rollback control processing unit

Claims (8)

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: 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. 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. 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;
not executing the rollback process when the importance of the target device is less than a predetermined importance level among a plurality of predetermined importance levels;
4. The software update system according to claim 3. 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. 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. 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. 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.