Software updating method and dispersion system

Abstract

To provide a software updating method for updating software of each device of a dispersion system in which multiple devices are disposed dispersively on a network, and to provide the dispersion system.SOLUTION: In a software updating method, a device 1-1 set as a distribution master distributes software to a device 1-2 to be updated that is connected via a network (S105), the device 1-2 determines update time of software set to an own device (S106), and updates software set to an own device to software distributed from the device 1-1 at the update time (S107). The device 1-2 determines time that is determined to be the safest as the update time on the basis of an operation situation of a control object, a user's operation situation to a control object, a load situation of a network to which an own device is connected, a load situation of an own device, and the number of persons located in a control object area of an own device.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] The present invention relates to a software updating method for updating software in each device in a distributed system in which a plurality of devices are distributed over a network, and to the distributed system. [Background technology]

[0002] In recent years, with the advancement of technology, customer demands are changing at a faster rate, and there is a need to respond accordingly. For example, there is a need for a rapid response to security risks such as vulnerabilities in IP (Internet Protocol) network systems. New attack methods that use vulnerabilities as a springboard are constantly being developed. In order to ensure the quality and safety that customers demand, product software updates are required. When updating software, it is necessary to establish clear work procedures and a sufficient system to prevent human error.

[0003] Given this background, currently, to update product software, adjustment workers from the product's shipping company visit the site and perform the software update manually. To perform software updates while taking into consideration the free time of the manager of the building where the product is installed, adjustment workers perform software updates late at night, for example, using dedicated engineering tools. In addition, while the number of controllers connected to IP network systems is increasing, there is a demand to distribute software and perform updates within a range (time period, operating status) that does not affect the network load. This results in an increase in maintenance man-hours and a worsening working environment for adjustment workers.

[0004] As described above, when manually updating the software of each product, it is necessary to dispatch multiple adjustment workers to the site. Because it is not possible to determine the time period for all controllers that will not inconvenience customers, adjustment workers are currently dispatched to the site to perform the software updates late at night when the probability that the air conditioners are operating is low. However, due to human resource issues, it may become difficult to provide a manual software update service to all customers, and there is a possibility that customers will be inconvenienced in the future due to delays in cybersecurity measures such as vulnerability response.

[0005] In view of this, techniques have been proposed for updating product software via a network (see Patent Documents 1 and 2). However, for products such as controllers, downloading software and switching over to the new software requires restarting the controller.After restarting the controller, there is a temporary period of no monitoring until normal control operation begins, so the adjustment worker must identify in advance through a preliminary investigation the time periods during which schedule software will not be executed, and then make a plan to manually restart the controller.

[0006] In addition, to ensure that there are no adverse effects after a software update, runtime data such as integrated values ​​and command values ​​must be visually checked, which requires recording a lot of work time, and maintenance costs increase in proportion to the frequency of software updates. As described above, software updates require time and effort for safety reasons, but conventional technology has not been able to realize a technology for updating software safely without affecting control, etc. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] JP 2006-178892 A [Patent Document 2] Patent No. 7008832 Summary of the Invention [Problem to be solved by the invention]

[0008] The present invention has been made to solve the above-mentioned problems, and aims to provide a software update method and distributed system that can safely update software in devices distributed over a network. [Means for solving the problem]

[0009] The present invention provides a software update method in a distributed system in which a plurality of devices are distributed and arranged on a network, comprising a first step in which a first device set as a distribution master distributes software to a second device to be updated, a second step in which the second device determines an update time for the software set in the first device, and a third step in which the second device updates the software set in the first device to the software distributed from the first device at the update time, wherein the second step includes a step in which the second device determines as the update time a time that it determines to be the safest based on the operating status of the controlled object, the operation status of the controlled object by a user, the load status of the network to which the first device is connected, the load status of the first device, and the number of people in the controlled area of ​​the first device.

[0010] In addition, in one configuration example of the software update method of the present invention, the second step is characterized by including a step of deriving a time period during which the device itself does not execute schedule control of the control object, a time period during which the number of operations by the user on the control object is equal to or less than a specified minimum number of operations, a time period during which the number of the control objects that are stopped is equal to or more than a specified minimum number of operations, a time period during which the number of messages received from the network is equal to or less than a specified minimum number of messages, a time period during which the CPU utilization rate of the device itself is equal to or less than a specified minimum utilization rate, and a time period during which the number of people in the control object area is equal to or less than a specified minimum number of people, determining the time with the greatest overlap between these derived time periods as the safest time, and setting this as the update time. Furthermore, one configuration example of the software update method of the present invention is characterized in that the second step is executed periodically from the time when software reception from the first device is completed until a predetermined time before the update time arrives.

[0011] Furthermore, one configuration example of the software update method of the present invention further includes a fourth step in which, when a predetermined time before the update time is reached, the second device determines whether or not it is possible to update the software set in the device itself based on the driving status of the controlled object and the number of people in the controlled area, and the third step is characterized in that, if it is determined in the fourth step that the software update is possible, at the update time, the software set in the device itself is updated to the software distributed from the first device. Furthermore, in one configuration example of the software update method of the present invention, the fourth step is characterized in that it includes a step of determining that software update is possible even if at least one of the driving conditions of the controlled object and the number of people in the controlled area is a condition that does not allow updating, if the condition is permitted by preset tolerance conditions.

[0012] Furthermore, in one configuration example of the software updating method of the present invention, the third step is characterized in including a step in which the second device saves a copy of the current software stored in the volatile memory of the own device in a save area of ​​the non-volatile memory of the own device, and saves a copy of the calculation data and a copy of the parameter setting values ​​of the own device in the save area, updates the current software stored in the non-volatile memory to software distributed from the first device, restarts the own device, reads out the updated software from the non-volatile memory after the restart and expands it on the volatile memory, and reads out the copy of the calculation data and the copy of the parameter setting values ​​saved in the save area and expands them on the volatile memory. Furthermore, one configuration example of the software updating method of the present invention includes a fifth step in which the second device determines whether the updated software stored in the non-volatile memory is not corrupted after the restart and determines whether the software expanded on the volatile memory is consistent with the calculation data and parameter setting values ​​expanded on the volatile memory, and a sixth step in which the second device performs a process of restoring the old version of the software as the current software if the second device determines that the updated software stored in the non-volatile memory is corrupted or if the software expanded on the volatile memory is not consistent with the calculation data and parameter setting values ​​expanded on the volatile memory, wherein the sixth step includes a step of initializing an area of ​​the non-volatile memory in which the updated software is stored and restarting the device, and after the restart, reading out the software saved in the save area and expanding it on the volatile memory, and reading out a copy of the calculation data and a copy of the parameter setting values ​​saved in the save area and expanding them on the volatile memory.

[0013] Moreover, one configuration example of the software update method of the present invention includes, before the first to third steps, a seventh step in which the first device sets a range of a first multicast address that the first device can receive and generates a second multicast address for distributing software to the second device that is a predefined update target, an eighth step in which the second device sets a range of the first multicast address that the first device can receive, a ninth step in which the first device transmits a multicast packet to the second multicast address to notify the version number of the software to be updated, and a ninth step in which the second device transmits the first multicast packet to the second multicast address that the first device has set. a tenth step of receiving a multicast packet addressed to an address within a range of stored addresses, an eleventh step of the second device comparing the version number notified in the multicast packet received in the tenth step with the version number of the software set in the second device to determine whether a software update is necessary, and a twelfth step of the second device requesting the first device to distribute the software if it is determined that a software update is necessary, wherein the first step includes a step of the first device distributing the software in response to the distribution request from the second device. Furthermore, in one configuration example of the software update method of the present invention, the seventh step includes a step of setting a range of the first multicast address that the device can receive based on the model type ID of the device itself and a purpose-specific number based on the purpose of the software update of the device itself, which has been permitted in advance, and generating the second multicast address based on the model type ID of the second device to be updated and a purpose-specific number indicating the purpose of the update of the software to be updated, and the eighth step includes a step of setting a range of the first multicast address that the device can receive based on the model type ID of the device itself and a purpose-specific number based on the purpose of the software update of the device itself, which has been permitted in advance.

[0014] The present invention also relates to a distributed system in which a plurality of devices are distributed and arranged on a network, wherein each device comprises a distribution unit configured to distribute software to a second device to be updated when the device itself is a first device set as a distribution master, and a software update unit configured to determine an update time for the software set in the device itself and to update the software set in the device itself to the software distributed from the first device at the update time when the device itself is the second device, and wherein the software update unit determines the update time to be the time determined to be the safest based on the operating status of the control object of the device itself, the operation status of the control object by a user, the load status of the network to which the device is connected, the load status of the device itself, and the number of people in the control target area of ​​the device itself. Effect of the Invention

[0015] According to the present invention, the second device can safely update software of the second device by determining the update time as the time that is determined to be the safest based on the operating status of the controlled object, the user's operation status of the controlled object, the load status of the network to which the device is connected, the load status of the device, and the number of people in the area controlled by the device.

[0016] Furthermore, in the present invention, the second step is periodically executed from the time when the second device completes receiving the software from the first device until a predetermined time before the update time is reached, thereby making it possible to reflect the most recent information in the update time.

[0017] In addition, in the present invention, when a predetermined time before the update time arrives, the second device determines whether or not it is possible to update the software set in the second device based on the driving conditions of the controlled object and the number of people in the controlled area, thereby making it possible to update the software of the second device more safely.

[0018] Furthermore, in the present invention, even if at least one of the driving conditions of the controlled object and the number of people in the controlled area is a condition that does not allow an update, if the condition is permitted by pre-set tolerance conditions, it is determined that a software update is possible, thereby preventing the software update from remaining pending indefinitely.

[0019] In addition, in the present invention, after restarting, the second device determines whether the updated software stored in the non-volatile memory is not corrupted, determines whether the software expanded on the volatile memory is consistent with the calculation data and parameter setting values ​​expanded on the volatile memory, and if it determines that the updated software stored in the non-volatile memory is corrupted or if it determines that the software expanded on the volatile memory is not consistent with the calculation data and parameter setting values ​​expanded on the volatile memory, it performs a process of restoring the old version of the software as the current software, thereby making it possible to update the software of the second device more safely.

[0020] In addition, in the present invention, the first device sets a range of a first multicast address that the device itself can receive, and generates a second multicast address for distributing software to a second device to be updated, the second device sets a range of the first multicast address that the device itself can receive, the first device transmits a multicast packet notifying the version number of the software to be updated to the second multicast address, the second device receives the multicast packet addressed to an address within the range of the first multicast address set by the device itself, compares the version number notified by the multicast packet with the version number of the software set in the device itself, and when it is determined that a software update is necessary, it requests the first device to distribute the software, thereby reducing the load on the network even when a large number of devices are connected to the network. In addition, in the present invention, it is possible to minimize the impact on the operating system by having each device determine whether or not a software update is necessary.

[0021] Furthermore, in the present invention, when the device itself is a first device, a range of first multicast addresses that the device can receive is set based on the model type ID of the device itself and a purpose-specific number based on the purpose of the software update of the device itself, which has been permitted in advance, and a second multicast address is generated based on the model type ID of the second device to be updated and a purpose-specific number indicating the purpose of the update of the software to be updated, and when the device itself is a second device, a range of first multicast addresses that the device can receive is set based on the model type ID of the device itself and a purpose-specific number based on the purpose of the software update of the device itself, which has been permitted in advance, thereby enabling communication using multicast groups according to individual software update needs. [Brief description of the drawings]

[0022] [Figure 1] FIG. 1 is a diagram illustrating the basic structure of a multicast IP address. [Diagram 2]FIG. 2 is a diagram for explaining an example of setting a multicast group according to the present invention. [Diagram 3] FIG. 3 is a diagram illustrating an example of permitted software update purposes for a product. [Figure 4] FIG. 4 is a diagram illustrating another example of permitted software update purposes for a product. [Diagram 5] FIG. 5 is a sequence diagram illustrating the software updating method of the present invention. [Figure 6] FIG. 6 is a diagram for explaining an example of how the update time is determined in the present invention. [Figure 7] FIG. 7 is a flowchart illustrating the update permission determination process according to the present invention. [Figure 8] FIG. 8 is a flowchart illustrating the consistency check process in the present invention. [Figure 9] FIG. 9 is a block diagram showing the configuration of an air conditioning system according to a first embodiment of the present invention. [Figure 10] FIG. 10 is a block diagram showing the configuration of an apparatus according to the first embodiment of the present invention. [Figure 11] FIG. 11 is a block diagram showing the configuration of an air conditioning system according to a second embodiment of the present invention. [Figure 12] FIG. 12 is a block diagram showing a configuration of a cloud server according to the second embodiment of the present invention. [Figure 13] FIG. 13 is a sequence diagram illustrating a software updating method according to the second embodiment of the present invention. [Figure 14] FIG. 14 is a block diagram showing the configuration of an air conditioning system according to the third embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0023] [Principle of the invention] The present invention provides a method for a controller to safely update software in a distributed system using an IP network without affecting control. In the present invention, a device that undergoes software update judges its own load status and network load status, and reserves a date and time for software distribution to a device that distributes the software.

[0024] In addition, in the present invention, in order to reduce network traffic when there are many devices connected to an IP network and to realize communication beyond subnetworks, communication is performed using a multicast group according to the individual software update needs. In the present invention, a multicast address is generated according to the following rules, for example.

[0025] Fig. 1 is a diagram explaining the basic structure of a multicast IP address. Class D addresses (224.0.0.0 to 239.255.255.255) are used for multicast IP addresses. The first 4 bits of a multicast IP address are "1110", and the remaining 28 bits are used to identify the multicast group ID. In the present invention, these 28 bits are used to limit the group for which software is updated.

[0026] 2 is a diagram for explaining an example of setting a multicast group according to the present invention. In the present invention, a multicast group is limited by a unique model type ID 200 indicating the type of device that distributes software and the device that is the target of the software update, a physical version number 201 indicating the physical compatibility of the device's hardware, etc., a logical version number 202 indicating the logical compatibility of the device's software, etc., a purpose-specific number 203 indicating the purpose of the software update, and a reservation time 204 indicating the time when the software should be updated.

[0027] As shown in Fig. 2, 8 bits of the 28 bits are used for the model type ID 200, and 4 bits are used each for the physical version number 201, logical version number 202, purpose-specific number 203, and reservation time 204. Software with different physical versions and model type IDs is considered to be incompatible. The example in Fig. 2 is an IPv4 multicast address, but it is also possible to use an IPv6 multicast address.

[0028] The purposes of software updates for products such as controllers include, for example, (I) security (vulnerability) measures, (II) fixing minor software defects, (III) fixing critical defects of high urgency, (IV) adding features, (V) customization extensions, (VI) feature updates, etc. These purposes are expressed as purpose-specific numbers of several bits (four bits in the example in Figure 2), and the product to be updated can determine whether or not a software update is necessary depending on the product's use.

[0029] At startup, each controller connected to the network defines the multicast group in which it will participate by setting a range of receivable multicast addresses that includes its own device's model type ID, a physical version number (a database version number for checking the compatibility of data required for operation), and a purpose-specific number indicating the purpose of software updates permitted by the device.

[0030] In the present invention, the purpose-specific number makes it possible to avoid unnecessary software updates. In other words, it is possible to update software not only to the latest version, but also to update software according to the importance or functions being used.

[0031] The purpose-specific number is defined in advance for each product and can be redefined using, for example, an engineering tool. Furthermore, when new software is generated in the engineering settings, a bit of the purpose-specific number corresponding to the purpose of the software update is set. The controller whose software is to be updated generates a receivable multicast address based on the purpose-specific number indicating the purpose of the software update that the controller itself permits at startup.

[0032] For example, for a certain developed product A, the purpose of pre-authorized software updates is defined as shown in Figure 3. The "bits" in Figure 3 indicate bit 0 (the least significant bit), bit 1, the second lowest, bit 2, the third lowest, and bit 3, the fourth lowest (the most significant bit), of the four bits indicating the purpose number.

[0033] When bit 0 (the least significant bit) is enabled ("1"), it indicates that the purpose of the software update is to address vulnerabilities in network communications. When bit 1 is enabled, it indicates that the purpose of the software update is to correct bugs in existing functions. When bit 2 is enabled, it indicates that the purpose of the software update is to change the specifications of existing functions. When bit 3 (the most significant bit) is enabled, it indicates that the purpose of the software update is to add new functions.

[0034] In the example in Figure 3, "○" indicates permission and "×" indicates disallowance. In other words, for product A, software updates aimed at addressing vulnerabilities in network communication or correcting defects in existing functions are permitted, but software updates aimed at changing the specifications of existing functions or adding new functions are not permitted.

[0035] If the model type ID of product A is "0001", the physical version number is "0001", the reservation time is "0000" or "1111", and the logical version number is "0001" or "1111", then product A will set the following multicast addresses as receivable at startup, according to the definition in Figure 3: 224.1.17.1 (bit 0 of the purpose-specific number is valid), 224.1.18.1 (bit 1 of the purpose-specific number is valid), and 224.1.19.1 (bits 0 and 1 of the purpose-specific number are valid). In these multicast addresses, the reservation time and logical version number bits are set to "00000001".

[0036] Furthermore, when product A starts up, it sets the multicast addresses 224.1.17.255 (bit 0 of the purpose-specific number is valid), 224.1.18.255 (bit 1 of the purpose-specific number is valid), and 224.1.19.255 (bits 0 and 1 of the purpose-specific number are valid) as multicast addresses that it can receive. In these multicast addresses, the reservation time and logical version number bits are set to "11111111". This multicast address with all "1" bits for the reservation time and logical version number is a common multicast address used in preparation for exchanging information about the distribution of new software. Product A will be able to send and receive multicast addresses set up as described above.

[0037] On the other hand, the device (including the controller) that acts as the distribution master to prompt software updates defines the purpose of the current software version with a purpose-specific number based on the update history from the previous version of the software to be updated, and also defines a logical version based on all versions to be updated. By creating a multicast endpoint based on the purpose and logical version of the software update and multicasting the availability of new software, it becomes possible to distribute information only to products of the same model that are permitted for the same update purpose.

[0038] For example, suppose that a device (including a controller) distributing software wants to distribute the availability of new software for product A for the purpose shown in Fig. 4. In the example of Fig. 4, "○" indicates that a software update for the corresponding purpose will be performed, and "×" indicates that a software update will not be performed. The example of Fig. 4 indicates that software updates may be performed to correct defects in existing functions or add new functions, but software updates that address vulnerabilities in network communications or change the specifications of existing functions will not be performed.

[0039] If the model type ID of product A is "0001", the physical version number is "0001", the reservation time is "0000" or "1111", and the logical version number after the software update is "0010" or "1111", then according to the definition in Fig. 4, the device that prompts the software update of product A creates the multicast addresses 224.1.18.2 (bit 1 of the purpose-specific number is valid), 224.1.24.2 (bit 3 of the purpose-specific number is valid), and 224.1.26.2 (bits 1 and 3 of the purpose-specific number are valid) at startup and notifies product A of the logical version of the software. In these multicast addresses, the reservation time and logical version number bits are set to "00000010".

[0040] Furthermore, the device that prompts product A to update its software creates the multicast addresses 224.1.18.255 (bit 1 of the purpose-specific number is valid), 224.1.24.255 (bit 3 of the purpose-specific number is valid), and 224.1.26.255 (bits 1 and 3 of the purpose-specific number are valid) at startup and notifies product A of the logical version of the software. In these multicast addresses, the reservation time and logical version number bits are set to "11111111". As above, multicast addresses with all "1" bits for the reservation time and logical version number are common multicast addresses for exchanging information about the distribution of new software.

[0041] By using the multicast address 224.1.18.* (where * is an arbitrary number), it is possible to specify a product group that is the same model type and has the same target update purpose. This reduces the risk of malfunctions caused by unintended software updates, and by using a multicast address, it is possible to perform software updates all at once even if there are a large number of devices on the network that are the same model type and have the same target update purpose.

[0042] In addition, when the distribution server distributes software, if there are multiple devices that have requested distribution at the same time and the software is distributed by multicast, the distributor and receiver recognize the multicast address and use it to determine that the distribution is addressed to them. The reservation time 204 is defined for the multicast address that is required when actually distributing software to multiple devices at the same time.

[0043] Furthermore, the bit of reservation time 204 indicates that when new software is distributed by multicast distribution, the data of this software will start distribution at a time shifted by an offset from the reservation time. The bit value of reservation time 204 x α (α is, for example, 5 minutes) represents the distribution start offset (in minutes) from the program distribution time zone. For example, if it is determined that 1 AM is the time zone with the lowest network load, this will be the multicast address to be used when distributing a program at the reservation time zone (1 AM) + α x MOD (a unique device number defined in advance / β). β is the numerical value of 60 minutes / α. If 60 minutes is considered with a resolution of 5 minutes, then β = 12.

[0044] 5 is a sequence diagram explaining the software update method of the present invention. Device 1-1 and device 1-2 are connected via a network. Device 1-1, which is defined in advance as a distribution master, is a separately prepared PC device (virtual controller) or a controller product of the same model as device 1-2, which is the target of software update.

[0045] At startup, the device 1-1, which is initially set as a distribution master, sets a range of multicast addresses that the device can receive from its own model type ID and physical version number and a purpose-specific number based on the purpose of the software update of the device that is permitted in advance. The device 1-1 also generates a multicast address for distributing software from the model type ID and physical version number of the controller to be updated that are predefined, and a purpose-specific number indicating the update purpose of the software to be updated (FIG. 5, step S100).

[0046] On the other hand, device 1-2, which is not initially set as a distribution master, sets the range of multicast addresses that the device can receive at startup based on the model type ID and physical version number of the device itself and a purpose-specific number based on the purpose of the software update of the device that has been permitted in advance (Figure 5, step S101).

[0047] Device 1-1 transmits a multicast packet notifying the new version number of the software to be updated to the multicast address for distributing the software (step S102 in FIG. 5). This enables device 1-1 to notify that it is playing the role of a distribution master, and to prompt in real time a software update for a group of devices that correspond to the device specified by the model type ID and physical version number and are permitted to update the software for the purpose specified by the purpose number. The reservation time for the multicast address for distributing the software and the bits of the logical version number are set to "11111111".

[0048] If device 1-1 is a controller of the same model as device 1-2 to be updated, device 1-1 uses its own model type ID and physical version number to generate a multicast address for distributing software, and determines a purpose-specific number to be used in generating the multicast address according to the purpose for which the software set in its own device was last updated. If the last update was a manual update, the adjustment worker needs to register the purpose of the update in device 1-1.

[0049] On the other hand, if the previous update was due to software distribution from another distribution master, the purpose of the update and the purpose-specific number can be determined from the multicast packet sent from the distribution master for this update. If device 1-1 is a controller of the same model as device 1-2 to be updated, device 1-1 generates a multicast packet to notify the version number of the software set in its own device.

[0050] On the other hand, if device 1-1 is a device different from device 1-2 to be updated, device 1-1 uses a predefined model type ID, physical version number, and purpose-specific number to generate a multicast address for distributing the software. If device 1-1 is a device different from device 1-2 to be updated, device 1-1 generates a multicast packet notifying a predefined new software version number.

[0051] In this embodiment, the device 1-1 performs the notification in step S102 at the time of startup, but the notification may be performed periodically (for example, once a day).

[0052] Device 1-2 can receive multicast packets addressed to addresses within the range of multicast addresses that device 1-2 set at startup. When device 1-2 receives the multicast packet transmitted from device 1-1, device 1-2 compares the version number notified in the received multicast packet with the version number of the software set in device 1-2 and determines whether the software needs to be updated (step S103 in FIG. 5).

[0053] If the version number notified by device 1-1 is newer than the version number of the software set in device 1-2, device 1-2 determines that the software needs to be updated and transmits a unicast packet requesting software distribution to device 1-1, the source of the multicast packet (step S104 in FIG. 5). This unicast packet contains information about the reserved time for software distribution. Device 1-2 may determine the reserved time based on, for example, the past load status of its own device or the past load status of network 2 to which its own device is connected.

[0054] Upon receiving the unicast packet from the device 1-2, the device 1-1 distributes software to the device 1-2 at the reserved time designated in the unicast packet in response to the distribution request from the device 1-2 (step S105 in FIG. 5).

[0055] At this time, if only one device 1-2 has reserved distribution at the same reserved time, device 1-1 distributes the software by unicast communication to this device 1-2. On the other hand, if multiple devices 1-2 have reserved distribution at the same reserved time, device 1-1 distributes the software by multicast communication. At this time, the multicast address used is the multicast address used in the notification in step S102. Bulk distribution by multicast not only reduces the communication load in the system, but also makes it possible to efficiently distribute software to multiple devices.

[0056] If the device 1-1 is a controller of the same model as the device 1-2 to be updated, the device 1-1 may distribute to the device 1-2 the same software as that set in the device 1-1 itself. If the device 1-1 is a device different from the device 1-2 to be updated, the device 1-1 may distribute to the device 1-2 software that has been prepared in advance for distribution.

[0057] The device 1-2 receives the software distributed from the device 1-1. The device 1-2 then checks the control schedule and the like, and determines a time that will not affect the operation of the system as the update time (step S106 in FIG. 5). At the update time, the device 1-2 updates the software set in its own device to the software distributed from the device 1-1 (step S107 in FIG. 5).

[0058] Next, a specific procedure for updating the software of the device 1-2 will be described. The current software loaded from the non-volatile memory is stored in the volatile memory of the device 1-2, and the device 1-2 executes processing according to the current software stored in the volatile memory.

[0059] At the update time when the device 1-2 determines that the CPU load of the device is low and that the equipment will not be controlled, the device 1-2 updates the current software stored in the non-volatile memory to the software distributed from the device 1-1 and restarts the device. After the restart, the device 1-2 loads the updated software stored in the non-volatile memory into the volatile memory. Thereafter, the device 1-2 executes processing according to the updated software loaded into the volatile memory.

[0060] Also, immediately before rebooting, the device 1-2 saves copies of its own calculation data, such as integrated values ​​and command values, copies of parameter setting values, and copies of the current software from the volatile memory to a save area in the nonvolatile memory, and after rebooting, it loads the saved calculation data and parameter setting values ​​into the volatile memory and judges the consistency with the updated software. If the device 1-2 judges that consistency is ensured as a result of the check, it executes processing according to the updated software. Also, if the device 1-2 judges that there is a problem with consistency, it performs a reloading process in which it reads out the old software saved in the nonvolatile memory and expands it into the volatile memory, and restores the old software as the current software.

[0061] Next, a method for determining the software update time will be described. The device 1-2 loads the updated software stored in the non-volatile memory into the volatile memory, and determines the update time for rebooting the device as follows.

[0062] Device 1-2 periodically executes an update time determination process (step S106) from the time when software reception from device 1-1 is completed until N minutes before the update time (N is, for example, 1 minute, which is the smallest unit of schedule setting), thereby reflecting the most recent information in the update time.

[0063] (a) The device 1-2 derives, based on preset schedule information, a time period during which the device 1-2 is scheduled not to execute schedule control of the facility device (eg, air conditioner) that is the control target of the device itself. (b) The device 1-2 derives a time period during which the number of operations of the facility device by the user was equal to or less than a prescribed minimum number of operations during a certain period of time in the past, based on a past log history of command operations from the monitoring device by the user. (c) The device 1-2 derives a time period during which the number of equipment devices that have stopped operating during a certain period in the past was equal to or greater than a prescribed number, based on the log history of past state changes and trend data. (d) The device 1-2 derives a time period during which the number of received UDP messages per unit time was equal to or less than a specified minimum number of messages during a certain past period. (e) The device 1-2 derives the time period during which the execution rate (%) per unit time of the lowest priority idle task during a certain period in the past was equal to or greater than a specified rate (corresponding to the time period during which the CPU utilization rate was equal to or less than a specified minimum utilization rate). (f) The device 1-2 derives a time period during the past when the number of people in the device's control target area (e.g., air-conditioned area) was equal to or less than a specified minimum number of people. The number of people in the control target area can be calculated from the detection results of a human sensor installed in the control target area, the history of people entering and leaving the control target area, the planned attendance schedule for the control target area, etc.

[0064] The device 1-2 determines the safest time as the update time based on the time slots derived in (a) to (f) above. FIG. 6 is a diagram for explaining an example of determining the update time. In the example of FIG. 6, an example is shown in which a time slot is derived between 00:00 and 23:59 on February 24th. For ease of description, the example of FIG. 6 shows time slot 300 derived in (a), time slot 301 derived in (b), time slot 302 derived in (c), and time slot 303 derived in (d). The device 1-2 determines the time with the greatest number of overlaps between the time slots derived in (a) to (f) as the safest time and determines it as the update time. When multiple times can be selected as the update time, the device 1-2 determines the most recent time of the multiple times as the update time.

[0065] It is possible to weight the time period derived in (b) for each user. Specifically, the device 1-2 identifies the user from the log history of command operations from the monitoring device, and counts operations by users with a predetermined high priority in the number of times the facility equipment is operated, and does not count operations by users with a predetermined low priority in the number of times the facility equipment is operated.

[0066] The device 1-2 loads the updated software stored in the non-volatile memory into the volatile memory at the update time and restarts the device itself, thereby minimizing the impact on the facility devices to be controlled. In addition, since the device 1-2 determines the update time in advance, it can notify the user of the update time through the monitoring device, making it possible to avoid problems such as unexpected device non-response.

[0067] The device 1-2 executes an update permission determination process as shown in FIG. 7 when it reaches N minutes before the update time (the time at which determination of the update time is stopped). The device 1-2 judges whether the current time is N minutes before the update time (step S200 in FIG. 7). If the current time is not N minutes before the update time, the process returns to the update time determination process (step S201 in FIG. 7).

[0068] When the current time reaches N minutes before the update time, the device 1-2 determines whether there is any facility device that operates under schedule control between the update time and the scheduled update completion time (step S202 in FIG. 7). Since the approximate time required from restarting the device at the update time until the device resumes processing according to the updated software is known, the scheduled update completion time can be calculated from the required time and the update time.

[0069] When the device 1-2 determines that there is equipment that operates under schedule control between the update time and the scheduled update completion time, the device 1-2 determines whether or not the suspension of the device's own monitoring and control of the equipment is set in advance as an acceptable condition (step S203 in FIG. 7). If the suspension of the device's own monitoring and control of the equipment is not set as an acceptable condition, the device 1-2 determines that the situation corresponds to an update not possible, and returns to the process of determining the update time (step S201).

[0070] When the interruption of the monitoring and control of the facility equipment by the device 1-2 itself is set in advance as an acceptable condition, the device 1-2 judges whether there are n or more people (n is a prescribed number) in the area (e.g., air-conditioned area) controlled by the device 1-2 (step S204 in FIG. 7). The method of calculating the number of people in the controlled area is as described above.

[0071] When the device 1-2 determines that there are n or more people in the control target area, it determines whether the presence of n or more people is set in advance as an acceptable condition (step S205 in FIG. 7). When the presence of n or more people is not set as an acceptable condition, it determines that the situation corresponds to an update impossible situation, and returns to the update time determination process (step S201).

[0072] When the presence of n or more people is preset as an acceptable condition, the device 1-2 judges whether or not an important facility device preset as a check target is stopped (step S206 in FIG. 7). When an important facility device is in operation, the device 1-2 judges whether or not suspension of the device's own monitoring and control of the important facility device is preset as an acceptable condition (step S207 in FIG. 7). When suspension of the device's own monitoring and control of the important facility device is not set as an acceptable condition, the device 1-2 judges that the situation corresponds to an update not possible situation, and returns to the update time determination process (step S201).

[0073] When the interruption of the monitoring and control of the important facility equipment by the device 1-2 itself is set in advance as an acceptable condition, the device 1-2 notifies the monitoring device that the device will update its software (step S208 in FIG. 7). Next, the device 1-2 saves a copy of the current software stored in the volatile memory in a predetermined save area in the non-volatile memory (step S209 in FIG. 7). Furthermore, the device 1-2 saves a copy of the calculation data of the device itself, such as the integrated value and the command value, and a copy of the parameter setting value in the save area in the non-volatile memory (step S210 in FIG. 7).

[0074] Then, the device 1-2 updates the current software stored in the non-volatile memory to the software distributed from the device 1-1 (step S211 in FIG. 7). Finally, the device 1-2 reboots itself (step S212 in FIG. 7).

[0075] In this way, the device 1-2 executes the check process, and if it is determined that the software cannot be updated, it puts the software update on hold and re-determines the update time. In this case, the update time is continually redetermined, but to prevent the software update from being put on hold forever, the user is allowed to set permissible conditions for each update feasibility determination process (steps S202, S204, S206). Even if the device 1-2 determines that the software update is inappropriate (YES in steps S202 and S204, NO in step S206), if the situation is permitted by the permissible conditions, it determines that the software can be updated, and performs the processes from step S208 onwards.

[0076] Next, after rebooting, the device 1-2 executes a consistency check process as shown in Fig. 8. First, the device 1-2 determines whether the new software stored in the non-volatile memory in step S211 is corrupted (step S300 in Fig. 8). If the new software is corrupted (YES in step S301 in Fig. 8), the device 1-2 determines whether the copy of the old version of the software stored in the non-volatile memory in step S209 is corrupted (step S302 in Fig. 8).

[0077] If the device 1-2 determines that the copy of the old version of the software is not damaged, it reads out the old version of the software and expands it in the volatile memory (step S303 in FIG. 8).Then, the device 1-2 performs an initial process in which it reads out the copy of the calculation data and the copy of the parameter setting values ​​stored in the non-volatile memory in step S210 and expands them in the volatile memory (step S304 in FIG. 3).

[0078] Furthermore, if the device 1-2 determines that the copy of the old version of the software is corrupted, it reads out sub-software for program update (emergency software) prepared in advance in the non-volatile memory and loads it into the volatile memory (step S305 in FIG. 8).Then, the device 1-2 performs the same initial processing as in step S304 (step S306 in FIG. 3).

[0079] On the other hand, if the device 1-2 determines in step S301 that the new software is not corrupted, it reads out the new software stored in the non-volatile memory in step S211 and loads it onto the volatile memory (step S307 in FIG. 8).Then, the device 1-2 performs the same initial processing as in steps S304 and S306 (step S308 in FIG. 3).

[0080] Next, the device 1-2 determines whether the new software loaded onto the volatile memory is consistent with the calculation data and parameter setting values ​​loaded onto the volatile memory (step S309 in FIG. 8). If they are consistent, the consistency check process ends. Thereafter, the device 1-2 executes processing according to the updated software loaded onto the volatile memory.

[0081] If the device 1-2 determines that the new software is not consistent with the calculation data and parameter setting values, it initializes the area of ​​the non-volatile memory in which the new software is stored (FIG. 8, step S310). This initialization is performed so that the new software will be determined to be corrupted when the consistency check process is executed again after the device is restarted.

[0082] Finally, the device 1-2 reboots itself (step S311 in FIG. 8). After rebooting, the consistency check process in FIG. 8 is executed again, so that the new software is determined to be corrupted in step S301, and the old version of the software is loaded onto the volatile memory. In this way, the old version of the software can be restored as the current software.

[0083] Incidentally, the detection of inconsistency and the process of rolling back to the old software can be executed as an autonomous process by the device 1-2 itself, or can be executed in response to a rollback command from a monitoring device on the network or a user.

[0084] The devices that play the role of distributing software include not only controllers connected to actual on-site systems, but also virtual controllers connected to cloud systems for integrated management or simulation purposes. In the example of FIG. 5, the case where there is one each of the devices 1-1 and 1-2 is described, but it goes without saying that the same can be implemented even when there are a plurality of devices 1-1 and 1-2.

[0085] [First Example] Hereinafter, embodiments of the present invention will be described with reference to the drawings. Fig. 9 is a block diagram showing the configuration of an air conditioning system (distributed system) according to a first embodiment of the present invention. Fig. 9 shows only devices 1a-1, 1a-2, 1b-1, and 1b-2, which are controllers, and a monitoring device 8, and omits the description of air conditioning equipment controlled by devices 1a-1, 1a-2, 1b-1, and 1b-2.

[0086] In the example of Fig. 9, two devices 1a-1 and 1b-1 that are initially set as distribution masters are arranged, and three devices 1a-2 and one device 1b-2 that are not initially set as distribution masters are arranged. The devices 1a-1, 1a-2, 1b-1, and 1b-2 are connected to each other via a network 2. The model type ID of the devices 1a-1 and 1a-2 is 13, and the model type ID of the devices 1b-1 and 1b-2 is 20. The physical version numbers of the devices 1a-1, 1a-2, 1b-1, and 1b-2 are all set to 1, for example.

[0087] 10 is a block diagram showing the configuration of the device 1a-1. The device 1a-1 includes a CPU 10, a non-volatile memory 11, a volatile memory 12, and an interface device (I / F) 13. The other devices 1a-2, 1b-1, and 1b-2 are connected to the I / F 13 via a network 2, and air conditioners are also connected to the I / F 13 via a control network (not shown).

[0088] The CPU 10 executes processing according to firmware stored in the non-volatile memory 11, and functions as an update possibility determination unit 106, a notification unit 107, a consistency determination unit 108, a software update unit 109, and a rollback processing unit 110. The CPU 10 also executes processing according to software (software to be updated in the present invention) stored in the volatile memory 12, and functions as an address setting unit 100, a transmission unit 101, a reception unit 102, an update determination unit 103, a delivery request unit 104, a delivery unit 105, and a control unit 111 that controls air conditioners.

[0089] The firmware of the device 1a-1, the current software of the device 1a-1, the model type ID and physical version number of the device itself, the purpose (purpose number) of the software update of the device itself that is permitted in advance, and the above-mentioned allowable conditions are stored in the non-volatile memory 11. In addition, in the case of a distribution master, definition information indicating that the device itself is a distribution master is set in the non-volatile memory 11.

[0090] The volatile memory 12 stores the current software of the device 1a-1, the model type ID and physical version number of the device to be updated, the update purpose (purpose-specific number) of the software to be updated, and software prepared for distribution. If the device itself is the same model as the device to be updated, the software prepared for distribution is the same as the current software set in the device itself.

[0091] In the example of FIG. 10, the configuration of the device 1a-1 is described, but the configurations of the devices 1a-2, 1b-1, and 1b-2 are similar to that of the device 1a-1, so they will be described using the reference numerals in FIG. The functions realized by the CPU 10 and the hardware configuration may differ depending on the function of the device or the model, but such differences in configuration are not essential components of the present invention.

[0092] The software update method of this embodiment will be described with reference to Fig. 5 to Fig. 8. The address setting units 100 of the devices 1a-1 and 1b-1, which are initially set as distribution masters, perform the process of step S100 in Fig. 5 at startup. The model type ID of the device 1a-1 is 13, and the model type ID of the device 1b-1 is 20.

[0093] When the address setting units 100 of the devices 1a-2 and 1b-2 that are not initially set as distribution masters perform the process of step S101 in Fig. 5 at startup. The model type ID of the device 1a-2 is 13, and the model type ID of the device 1b-2 is 20.

[0094] The transmitting unit 101 of the device 1a-1 transmits a multicast packet notifying the new version number of the software of the device 1a-2 to the multicast address for distributing the software prepared for the device 1a-2 (step S102 in FIG. 5). Similarly, the transmitting unit 101 of the device 1b-1 transmits a multicast packet notifying the new version number of the software of the device 1b-2 to the multicast address for distributing the software prepared for the device 1b-2 (step S102). As described above, the process of step S102 may be performed periodically.

[0095] The receivers 102 of the devices 1a-2 and 1b-2 receive multicast packets addressed to addresses within the range of receivable multicast addresses set by the address setting units 100 of the devices themselves. The update determination units 103 of the devices 1a-2 and 1b-2 compare the version number notified in the multicast packets received from the devices 1a-1 and 1b-1 with the version number of the software set in the devices themselves, and determine whether or not a software update is necessary (step S103 in FIG. 5).

[0096] When the update determination unit 103 of the device 1a-2, 1b-2 determines that the version number notified from the device 1a-1, 1b-1 is newer than the version number of the software set in the device itself and that the software needs to be updated, the delivery request unit 104 of the device 1a-2, 1b-2 transmits a unicast packet requesting software delivery to the device 1a-1, 1b-1 that sent the multicast packet (FIG. 5, step S104). This unicast packet contains information about the reserved time for software delivery. The delivery request unit 104 may determine the reserved time based on, for example, the past load status of the device itself or the past load status of the network 2 to which the device itself is connected.

[0097] The receiving units 102 of the devices 1a-1 and 1b-1 receive the unicast packets transmitted from the devices 1a-2 and 1b-2, respectively. When the distributing units 105 of the devices 1a-1 and 1b-1 receive the unicast packets from the devices 1a-2 and 1b-2, respectively, they start distributing software to the devices 1a-2 and 1b-2 at the reserved time specified in the unicast packets in response to the distribution requests from the devices 1a-2 and 1b-2 (step S105 in FIG. 5).

[0098] The receiving units 102 of the devices 1a-2 and 1b-2 receive the software distributed from the devices 1a-1 and 1b-1, respectively. The software update units 109 of the devices 1a-2 and 1b-2 perform the update time determination process described in FIG. 6 from the point in time when the update determination units 103 of the devices 1a-2 and 1b-2 determine that software updating is necessary (step S106 in FIG. 5).

[0099] The update permission determination unit 106 of the devices 1a-2 and 1b-2 executes the update permission determination process described in steps S200 to S207 of FIG. 7 when N minutes have passed before the update time. If the update possibility determination unit 106 of the devices 1a-2 and 1b-2 determines that the software can be updated, the notification unit 107 of the devices 1a-2 and 1b-2 notifies the monitoring device 8 that the devices will update the software at the update time (Step S208 in FIG. 7).

[0100] The software update unit 109 of the devices 1a-2 and 1b-2 saves a copy of the current software stored in the volatile memory 12 in a specified save area of ​​the non-volatile memory 11 at the update time determined in step S106 (step S209 in FIG. 7), and saves a copy of the calculation data and a copy of the parameter setting values ​​of the device itself in the save area of ​​the non-volatile memory 11 (step S210 in FIG. 7).

[0101] Then, the software update unit 109 of the devices 1a-2 and 1b-2 updates the current software stored in the non-volatile memory 11 to the software distributed from the devices 1a-1 and 1b-1 (step S211 in FIG. 7), and restarts the devices themselves (step S212 in FIG. 7).

[0102] After the restart, the consistency determination units 108 of the devices 1a-2 and 1b-2 perform the processes of steps S300, S301, and S309 in FIG. When the compatibility determination unit 108 of the device 1a-2, 1b-2 determines that the new software is not corrupted, the software update unit 109 of the device 1a-2, 1b-2 performs the processes of steps S307, S308 in FIG.

[0103] Furthermore, when the consistency determination unit 108 of the device 1a-2, 1b-2 determines that the new software is not consistent with the calculation data and parameter setting values, the rollback processing unit 110 of the device 1a-2, 1b-2 initializes the area of ​​the non-volatile memory 11 in which the new software is stored (step S310 in FIG. 8) and restarts the device (step S311 in FIG. 8). After the restart, the rollback processing unit 110 performs a process of restoring the old version of the software as the current software (steps S302 to S304 in FIG. 8).

[0104] In this embodiment, it is possible to automatically update the software in the air conditioning system by either installing a new control controller that will act as the distribution master, or by updating the software of the existing control controller to the latest version and setting it as the distribution master (devices 1a-1, 1b-1) using an engineering tool.

[0105] [Second Example] Next, a second embodiment of the present invention will be described. Fig. 11 is a block diagram showing the configuration of an air conditioning system (distributed system) according to the second embodiment of the present invention. Fig. 11 shows only devices 1a-2, 1b-2, and 1c-2, which are controllers, a cloud server 3, and a monitoring device 8, and omits the description of air conditioning equipment controlled by devices 1a-2, 1b-2, and 1c-2.

[0106] In the example of Fig. 11, one cloud server 3 is arranged as a virtual controller that plays the role of a distribution master, and four devices 1a-2, two devices 1b-2, and one device 1c-2 are arranged. The devices 1a-2, 1b-2, and 1c-2 are connected to each other via a network 2. The devices 1a-2, 1b-2, and 1c-2 are connected to the cloud server 3 by a network 4. The model type ID of the device 1a-2 is 13, the model type ID of the device 1b-2 is 20, and the model type ID of the device 1c-2 is 15. The physical version numbers of the devices 1a-2, 1b-2, and 1c-2 are all set to 1, for example.

[0107] Fig. 12 is a block diagram showing the configuration of the cloud server 3. The cloud server 3 includes a CPU 30, a non-volatile memory 31, a volatile memory 32, and an I / F 33. The I / F 33 is connected to the devices 1a-2, 1b-2, and 1c-2 via a network 4. The CPU 30 executes processing according to software stored in the volatile memory 32, and functions as an address setting unit 100, a transmitting unit 101, a receiving unit 102, and a distributing unit 105. The configurations of the devices 1a-2, 1b-2, and 1c-2 are similar to that of the device 1a-1 shown in Fig. 10, and will be described using the reference numerals in Fig. 10.

[0108] Fig. 13 is a sequence diagram for explaining the software update method of this embodiment. Note that, in Fig. 13, for ease of description, only one device, 1a-2, out of devices 1a-2, 1b-2, and 1c-2 is illustrated.

[0109] The non-volatile memory 31 of the cloud server 3 stores the firmware of the own device, the current software of the own device, and the model type ID and physical version number of the own device. Also, the non-volatile memory 31 stores definition information indicating that the own device is a distribution master.

[0110] The volatile memory 32 of the cloud server 3 stores the current software of the device itself, the model type ID and physical version number of the devices 1a-2, 1b-2, 1c-2 to be updated, the update purpose (purpose-specific number) of the software to be updated, and the software prepared for distribution.

[0111] At startup, the address setting unit 100 of the cloud server 3 generates a multicast address for distributing software from the predefined model type ID and physical version number of the device to be updated and a purpose-specific number indicating the update purpose of the software to be updated (FIG. 13, step S400). Here, the model type IDs of multiple controllers to be updated are registered in the memory 31, so the address setting unit 100 generates a multicast address for each of the devices 1a-2, 1b-2, 1c-2 with different model type IDs. It goes without saying that the purpose-specific number may change depending on the model of the controller.

[0112] The address setting units 100 of the devices 1a-2, 1b-2, and 1c-2 perform the process of step S401, which is the same as step S101 in FIG. 5, at the time of startup. The transmitter 101 of the cloud server 3 sends a multicast packet notifying the new version numbers of the software of the devices 1a-2, 1b-2, and 1c-2 to the multicast address for distributing software to each of the devices 1a-2, 1b-2, and 1c-2 (step S402 in FIG. 13).

[0113] The receivers 102 of the devices 1a-2, 1b-2, and 1c-2 receive multicast packets addressed to addresses within the range of receivable multicast addresses set by the address setting units 100 of the respective devices. The update determination units 103 of the devices 1a-2, 1b-2, and 1c-2 compare the version number notified in the multicast packet received from the cloud server 3 with the version number of the software set in the respective devices, and determine whether or not a software update is necessary (step S403 in FIG. 13).

[0114] When the update determination unit 103 of each of the devices 1a-2, 1b-2, and 1c-2 determines that the version number of the software notified from the cloud server 3 is newer than the version number set in the device itself and that the software needs to be updated, the delivery request unit 104 of the device 1a-2, 1b-2, and 1c-2 transmits a unicast packet requesting software delivery to the cloud server 3 that is the sender of the multicast packet (step S404 in FIG. 13). The information contained in the unicast packet is the same as in the first embodiment.

[0115] The receiving unit 102 of the cloud server 3 receives the unicast packets transmitted from the devices 1a-2, 1b-2, and 1c-2. When the distributing unit 105 of the cloud server 3 receives the unicast packets from the devices 1a-2, 1b-2, and 1c-2, it starts software distribution to the devices 1a-2, 1b-2, and 1c-2 at the reserved time specified in the unicast packet in response to the distribution request from the devices 1a-2, 1b-2, and 1c-2 (step S405 in FIG. 13). It goes without saying that the software may differ depending on the model of the controller.

[0116] As in the first embodiment, the software is distributed by unicast or multicast communication. The receiving units 102 of the devices 1a-2, 1b-2, and 1c-2 receive the software distributed from the cloud server 3. Subsequent operations of the devices 1a-2, 1b-2, and 1c-2 are the same as those of the devices 1a-2 and 1b-2 in the first embodiment.

[0117] As described above, in this embodiment, a cloud server 3 that acts as a distribution master is installed on the network, and the model type IDs and latest software of the multiple devices 1a-2, 1b-2, 1c-2 to be updated are registered in the cloud server 3, making it possible to automatically update software in the entire air conditioning system.

[0118] [Third Example] Next, a third embodiment of the present invention will be described. Fig. 14 is a block diagram showing the configuration of an air conditioning system (distributed system) according to the third embodiment of the present invention. Fig. 14 shows only devices 1a-2, 1c-2, 1d-2, 1e-2, 1f-2, 1g, 1h, 1i, 1j, 1k, and 1m, which are controllers, a cloud server 3, and a monitoring device 8, and omits the description of air conditioning equipment controlled by devices 1a-2, 1c-2, 1d-2, 1e-2, 1f-2, 1g, 1h, 1i, 1j, 1k, and 1m.

[0119] In the example of Fig. 14, one cloud server 3, which is a virtual controller that plays a role as a distribution master, is arranged, three devices 1a-2, and one each of devices 1c-2, 1d-2, 1e-2, and 1f-2 are arranged. The devices 1a-2, 1c-2, 1d-2, 1e-2, and 1f-2 are connected to each other via a network 2. The devices 1a-2, 1c-2, 1d-2, 1e-2, and 1f-2 are connected to the cloud server 3 via a network 4. The model type IDs of the devices 1a-2 and 1d-2 are 13, the model type ID of the device 1c-2 is 15, and the model type IDs of the devices 1e-2 and 1f-2 are 20.

[0120] In this embodiment, devices 1g and 1h are arranged as sub-controllers under device 1d-2. The model type ID of device 1g is 101, and the model type ID of device 1h is 105. Devices 1i, 1j, and 1k are arranged as sub-controllers under device 1e-2. The model type ID of device 1i is 101, the model type ID of device 1j is 104, and the model type ID of device 1k is 105. Device 1m is arranged as a sub-controller under device 1f-2. The model type ID of device 1m is 106. The physical version numbers of devices 1a-2, 1c-2, 1d-2, 1e-2, 1f-2, 1g, 1h, 1i, 1j, 1k, and 1m are all, for example, 1. Devices 1d-2 and devices 1g and 1h are connected by a network 5. The device 1e-2 is connected to the devices 1i, 1j, and 1k via a network 6. The device 1f-2 is connected to the device 1m via a network 7.

[0121] The configuration of the cloud server 3 is as described in the second embodiment. The configuration of the devices 1a-2, 1c-2, 1d-2, 1e-2, 1f-2, 1g, 1h, 1i, 1j, 1k, and 1m is the same as the device 1a-1 shown in Fig. 10, so they will be described using the symbols in Fig. 10. Due to differences in the functions and models of the devices, the functions and hardware configurations realized by the CPUs 10 of the devices 1a-2, 1c-2, 1d-2, 1e-2, 1f-2, 1g, 1h, 1i, 1j, 1k, and 1m may differ, but such differences in the configurations are not the main components of the present invention.

[0122] The non-volatile memory 31 of the cloud server 3 stores the firmware of the own device, the current software of the own device, and the model type ID and physical version number of the own device. Also, the non-volatile memory 31 stores definition information indicating that the own device is a distribution master.

[0123] The volatile memory 32 of the cloud server 3 stores the current software of its own device, the model type ID and physical version number of the devices 1a-2, 1c-2, 1d-2, 1e-2, 1f-2, 1g, 1h, 1i, 1j, 1k, 1m to be updated, the update purpose (purpose-specific number) of the software to be updated, and the software prepared for distribution.

[0124] The non-volatile memory 11 of the devices 1a-2 and 1c-2 stores the firmware of the devices, the current software of the devices, the model type ID and physical version number of the devices, the purpose (purpose number) of the software update of the devices that is permitted in advance, and the above-mentioned allowable conditions. The volatile memory 12 of the devices 1a-2 and 1c-2 stores the current software of the devices.

[0125] On the other hand, the devices 1d-2, 1e-2, and 1f-2 can play the role of a virtual sub-controller. That is, the non-volatile memory 11 of the devices 1d-2, 1e-2, and 1f-2 stores the firmware of the device itself, the current software of the device itself as a primary controller, the current software of the device itself as a sub-controller, the model type ID and physical version number of the device itself as a primary controller, the purpose (purpose-specific number) of a software update of the device itself as a primary controller that is permitted in advance, the purpose (purpose-specific number) of a software update of the device itself as a sub-controller that is permitted in advance, and the above-mentioned allowable conditions.

[0126] Furthermore, the non-volatile memory 11 of the device 1d-2 stores the model type ID and physical version number of its own device as a sub-controller, and the model type IDs and physical version numbers of the devices 1g and 1h that are subordinate to it and are to be updated. The volatile memory 12 of the device 1d-2 stores the current software of its own device, the update purpose (purpose number) of the software to be updated, and software for the sub-controller prepared for distribution. If the device itself is the same model as the device to be updated, the software prepared for distribution is the same as the software set in the device itself as a sub-controller. The model type ID of the device 1d-2 as the primary controller is 13, and the model type IDs of the device 1d-2 as the sub-controller are 101 to 106.

[0127] Furthermore, the non-volatile memory 11 of the device 1e-2 stores the model type ID and physical version number of its own device as a sub-controller, and the model type IDs and physical version numbers of the subordinate devices 1i, 1j, and 1k to be updated. The volatile memory 12 of the device 1e-2 stores the current software of its own device, the update purpose (purpose number) of the software to be updated, and the sub-controller software prepared for distribution. The model type ID of the device 1e-2 as the primary controller is 20, and the model type IDs of the device 1e-2 as the sub-controller are 101 to 106.

[0128] The non-volatile memory 11 of the device 1f-2 stores the model type ID and physical version number of its own device as a sub-controller, and the model type ID and physical version number of the device 1m to be updated under it. The volatile memory 12 of the device 1f-2 stores the current software of its own device, the update purpose (purpose number) of the software to be updated, and the sub-controller software prepared for distribution. The model type ID of the device 1f-2 as the primary controller is 20, and the model type IDs of the device 1f-2 as the sub-controller are 101 to 106. Moreover, in the non-volatile memory 11 of each of the devices 1d-2, 1e-2, and 1f-2, definition information is set which indicates that the device itself is a distribution master for the subordinate sub-controllers.

[0129] The flow of the process of software update by the cloud server 3 is similar to that of the second embodiment, and will be described using the reference numerals in FIG. At startup, the address setting unit 100 of the cloud server 3 generates a multicast address for distributing the software from the predefined model type ID and physical version number of the controller to be updated and a purpose-specific number indicating the update purpose of the software to be updated (FIG. 13, step S400). Here, since the model type IDs of multiple controllers to be updated are registered in the memory 31, the address setting unit 100 generates a multicast address for each device with a different model type ID.

[0130] Meanwhile, the address setting unit 100 of the primary controller devices 1a-2, 1c-2, 1d-2, 1e-2, and 1f-2 sets, at startup, a range of multicast addresses that the device can receive based on the model type ID and physical version number of the device as the primary controller and a purpose-specific number based on the purpose of a software update of the device as the primary controller that has been permitted in advance (FIG. 13, step S401).

[0131] The address setting unit 100 of the devices 1d-2, 1e-2, and 1f-2, which are distribution masters of the sub-controllers, sets a range of multicast addresses that the devices can receive from the model type ID and physical version number of the devices as sub-controllers and a purpose-specific number based on the purpose of the software update of the devices as sub-controllers that is permitted in advance. The address setting unit 100 of the devices 1d-2, 1e-2, and 1f-2 generates a multicast address for distributing software from the model type ID and physical version number of the sub-controller to be updated that are predefined, and the purpose-specific number indicating the update purpose of the software to be updated (FIG. 13, step S401).

[0132] The transmitting unit 101 of the cloud server 3 transmits a multicast packet to a multicast address for distributing software to each of the primary controllers with different model type IDs and each of the sub-controllers with different model type IDs, notifying each of the controllers of the new version number of the software prepared for each of the controllers (FIG. 13, step S402).

[0133] The receivers 102 of the devices 1a-2, 1c-2, 1d-2, 1e-2, and 1f-2 receive multicast packets addressed to addresses within the range of receivable multicast addresses set by the address setting units 100 of the devices themselves. The update determination units 103 of the devices 1a-2, 1c-2, 1d-2, 1e-2, and 1f-2 compare the version number of the primary controller software notified in the multicast packet received from the cloud server 3 with the version number of the software set in the devices themselves as the primary controller, and determine whether a software update is necessary (step S403 in FIG. 13).

[0134] In addition, the update determination unit 103 of devices 1d-2, 1e-2, and 1f-2 compares the software version number of the sub-controller notified in the multicast packet received from the cloud server 3 with the software version number set in the device itself as a sub-controller, and determines whether a software update is necessary (step S403).

[0135] If the update determination unit 103 of each of the devices 1a-2, 1c-2, 1d-2, 1e-2, and 1f-2 determines that the software of the primary controller needs to be updated, the delivery request unit 104 sends a unicast packet to the cloud server 3 that sent the multicast packet, requesting delivery of the software of the primary controller (step S404 in FIG. 13).

[0136] Furthermore, when the update determination unit 103 of the devices 1d-2, 1e-2, and 1f-2 determines that the sub-controller software needs to be updated, the delivery request unit 104 transmits a unicast packet requesting delivery of the sub-controller software to the cloud server 3 (step S404). The information contained in the unicast packet is the same as in the first embodiment.

[0137] The receiving unit 102 of the cloud server 3 receives the unicast packets transmitted from the devices 1a-2, 1c-2, 1d-2, 1e-2, and 1f-2. When the distributing unit 105 of the cloud server 3 receives the unicast packets from the devices 1a-2, 1c-2, 1d-2, 1e-2, and 1f-2, it starts software distribution to the devices 1a-2, 1c-2, 1d-2, 1e-2, and 1f-2 at the reserved time specified in the unicast packet in response to the distribution request from the devices 1a-2, 1c-2, 1d-2, 1e-2, and 1f-2 (step S405 in FIG. 13). It goes without saying that the software may differ for each model of the primary controller and each model of the sub-controller.

[0138] As in the first embodiment, the software is distributed by unicast or multicast communication. The receiving units 102 of the devices 1a-2, 1c-2, 1d-2, 1e-2, and 1f-2 receive the software distributed from the cloud server 3. Subsequent operations of the devices 1a-2, 1c-2, 1d-2, 1e-2, and 1f-2 are the same as those of the devices 1a-2 and 1b-2 in the first embodiment.

[0139] The operations of the devices 1d-2, 1e-2, and 1f-2 as distribution masters of the sub-controller are similar to those of the devices 1a-1 and 1b-1 in the first embodiment. That is, devices 1d-2, 1e-2, and 1f-2 as sub-controllers operate in the same manner as devices 1a-1 and 1b-1 in the first embodiment, and devices 1g, 1h, 1i, 1j, 1k, and 1m operate in the same manner as devices 1a-2 and 1b-2 in the first embodiment.

[0140] Thus, in this embodiment, by equipping the primary controller devices 1d-2, 1e-2, and 1f-2 with the functionality of a virtual sub-controller, it becomes possible to automatically update software not only for the primary controller of the air conditioning system, but also for the sub-controllers.

[0141] In the first to third embodiments, an air conditioning system has been taken as an example of a distributed system, but it goes without saying that the distributed system to which the present invention is applicable does not have to be an air conditioning system. [Industrial Applicability]

[0142] The present invention can be applied to a distributed system in which a plurality of devices are distributed and arranged on a network. [Explanation of symbols]

[0143] 1-1, 1a-1, 1b-1, 1-2, 1a-2 to 1f-2, 1g to 1k, 1m...device, 2, 4 to 7...network, 3...cloud server, 8...monitoring device, 10, 30...CPU, 11, 31...non-volatile memory, 12, 32...volatile memory, 13, 33...interface device, 100...address setting unit, 101...transmitting unit, 102...receiving unit, 103...update judgment unit, 104...distribution request unit, 105...distribution unit, 106...update feasibility judgment unit, 107...notification unit, 108...consistency judgment unit, 109...software update unit, 110...rollback processing unit, 111...control unit.

Claims

1. 1. A software update method in a distributed system in which a plurality of devices are distributed and arranged on a network, comprising: A first step in which a first device set as a distribution master distributes software to a second device to be updated; a second step of determining, by the second device, a software update time set in the second device; and a third step of the second device updating the software set in the second device to the software distributed from the first device at the update time, A software update method characterized in that the second step includes a step in which the second device determines as the update time the time that it judges to be the safest based on the operating status of the controlled object, the user's operation status of the controlled object, the load status of the network to which the device is connected, the load status of the device, and the number of people in the area controlled by the device.

2. 2. The software update method according to claim 1, The second step of the software update method includes a step of deriving a time period during which the device itself does not execute schedule control of the control object, a time period during which the number of operations by the user on the control object is below a specified minimum number of operations, a time period during which the number of the control objects that are stopped is a specified number or more, a time period during which the number of messages received from the network is below a specified minimum number of messages, a time period during which the CPU utilization rate of the device itself is below a specified minimum utilization rate, and a time period during which the number of people in the control object area is below a specified minimum number, determining the time when these derived time periods overlap the most as the safest time, and setting this as the update time.

3. 3. The software updating method according to claim 2, a step of periodically executing the second step from a point in time when the software has been received from the first device until a predetermined time before the update time arrives.

4. 2. The software update method according to claim 1, The method further includes a fourth step of determining whether or not the second device can update software set in the second device based on the driving status of the controlled object and the number of people in the controlled area when a predetermined time before the update time arrives, The third step of the software update method is characterized in that, when it is determined in the fourth step that a software update is possible, the third step includes a step of updating the software set in the device to the software distributed from the first device at the update time.

5. 5. The software updating method according to claim 4, The fourth step of the software update method includes a step of determining that software update is possible when at least one of the driving conditions of the controlled object and the number of people in the controlled area is a condition that does not allow updating, but is permitted by preset tolerance conditions.

6. 2. The software update method according to claim 1, The third step of the software updating method includes a step in which the second device saves a copy of the current software stored in the volatile memory of the second device in a save area of ​​the non-volatile memory of the second device, and saves a copy of the calculation data and a copy of the parameter setting values ​​of the second device in the save area, updates the current software stored in the non-volatile memory to software distributed from the first device, restarts the first device, reads out the updated software from the non-volatile memory after the restart and expands it on the volatile memory, and reads out the copy of the calculation data and the copy of the parameter setting values ​​saved in the save area and expands them on the volatile memory.

7. 7. The software updating method according to claim 6, a fifth step in which the second device, after the restart, determines whether the updated software stored in the non-volatile memory is corrupted and determines whether the software loaded on the volatile memory is consistent with the calculation data and parameter setting values ​​loaded on the volatile memory; a sixth step of performing a process of restoring the old version of the software as the current software when the second device determines that the updated software stored in the non-volatile memory is corrupted or when the second device determines that the software loaded on the volatile memory is not consistent with the calculation data and parameter setting values ​​loaded on the volatile memory, The sixth step of the software update method includes a step of initializing an area of ​​the non-volatile memory in which the updated software is stored, restarting the device, and after the restart, reading out the software stored in the save area and expanding it on the volatile memory, and reading out a copy of the calculation data and a copy of the parameter setting values ​​stored in the save area and expanding them on the volatile memory.

8. 2. The software update method according to claim 1, a seventh step, prior to the first to third steps, of the first device setting a range of a first multicast address that the first device can receive, and generating a second multicast address for distributing software to the second device that is a predefined update target; an eighth step of the second device setting a range of a first multicast address that the second device can receive; a ninth step in which the first device transmits a multicast packet notifying the version number of the software to be updated to the second multicast address; a tenth step of receiving a multicast packet destined for an address within the range of the first multicast address set by the second device; an eleventh step in which the second device compares the version number notified in the multicast packet received in the tenth step with a version number of the software set in the second device, and determines whether or not software updating is necessary; and a twelfth step of, when the second device determines that a software update is necessary, requesting the first device to distribute the software, A software updating method, wherein the first step includes a step of the first device distributing software in response to a distribution request from the second device.

9. 9. The software updating method according to claim 8, The seventh step includes a step of setting a range of the first multicast address that can be received by the own device based on a model type ID of the own device and a purpose-specific number based on a purpose of a software update of the own device that is permitted in advance, and generating the second multicast address based on a model type ID of the second device to be updated and a purpose-specific number indicating an update purpose of the software to be updated; The software update method is characterized in that the eighth step includes a step of setting a range of the first multicast address that the device can receive based on the model type ID of the device and a purpose-specific number based on a purpose of the software update of the device that has been permitted in advance.

10. In a distributed system in which a plurality of devices are distributed and arranged on a network, Each device is a distribution unit configured to distribute software to a second device to be updated when the first device is set as a distribution master; a software update unit configured to determine an update time of software set in the own device when the own device is the second device, and to update the software set in the own device to the software distributed from the first device at the update time; A distributed system characterized in that the software update unit determines the update time to be the time determined to be the safest based on the operating status of the controlled object of the device, the user's operation status of the controlled object, the load status of the network to which the device is connected, the load status of the device, and the number of people in the controlled area of ​​the device.

Images