Software update method and distributed system

Abstract

To reduce a network load even if a large number of devices are connected to an IP network.SOLUTION: A CPU in a device 1a-1 includes: an address setting unit which sets a range of a first multicast address, and generates, when the device is a first device set as a distribution master, a second multicast address for distributing software to a second device to be updated; a transmission unit which transmits a multicast packet indicating a version number of software to be updated; a receiving unit which receives the multicast packet; an update determination unit which determines whether the update of the software is necessary; a distribution request unit which requests the first device to distribute software at a designated reservation time; a distribution unit which distributes the software at the reservation time; and a software update unit which updates the software. The CPU determines the reservation time on the basis of a load state of the device or a load state of a network to which the device is connected.SELECTED DRAWING: Figure 9

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 software updates are performed manually for each product, multiple adjustment workers must be dispatched to the site. Since it is not possible to determine the time period when software updates will not inconvenience customers for all controllers that are the subject of software updates, adjustment workers are sent 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 manual software update services to all customers, and in the future, there is a possibility that customers will be inconvenienced by delays in cybersecurity measures such as vulnerability response. The number of air conditioning control controllers on the network is expected to increase due to the recent promotion of digital transformation (DX), making it difficult for adjustment workers to monitor the network load and plan the timing of software updates.

[0005] In view of this, techniques have been proposed for updating product software via a network (see Patent Documents 1 and 2). However, since controllers that perform various controls are connected to a network, updating the software of all of those controllers at the same time increases the load on the network, which runs the risk of affecting system monitoring. Therefore, it is necessary to reduce the load on the network, but conventional technology has not been able to achieve this. [Prior art documents] [Patent documents]

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

[0007] The present invention has been made to solve the above-mentioned problems, and aims to provide a software update method and a distributed system that can reduce the load on the network even when there are a large number of devices connected to the network. [Means for solving the problem]

[0008] The present invention relates to a software update method in a distributed system in which a plurality of devices are distributed and arranged on a network, the method comprising the steps of: a first step in which a first device set as a distribution master sets a range of a first multicast address that the first device can receive, and generates a second multicast address for distributing software to a predefined second device that is a target for update; a second step in which the second device sets a range of the first multicast address that the first device can receive; a third step in which the first device transmits a multicast packet for notifying the version number of the software to be updated to the second multicast address; a fourth step in which the second device receives a multicast packet whose destination is an address within the range of the first multicast address set by the second device; a fifth step of comparing the version number notified in the multicast packet received at step 10 with the version number of the software set in the first device to determine whether a software update is necessary; a sixth step of the second device requesting the first device to start distributing the software at a specified scheduled time if it determines that a software update is necessary; a seventh step of the first device starting software distribution at the scheduled time in response to the distribution request from the second device; and an eighth step of the second device updating the software set in its own device to the software distributed from the first device, wherein the sixth step includes a step in which the second device determines the scheduled time based on the load status of its own device and the load status of the network to which its own device is connected.

[0009] In addition, in one configuration example of the software update method of the present invention, the sixth step is characterized by including a step of counting the CPU usage rate of the device itself and the number of messages received from the network during a certain period in the past, and determining the time when the sum of these count values ​​is the smallest as the scheduled time. Furthermore, in one configuration example of the software update method of the present invention, the sixth step includes a step of notifying the first device of the reserved time together with the allowable time before and after, and the seventh step includes a step of starting software distribution within a time range of T±β, where T is the reserved time and β is the allowable time before and after.

[0010] Furthermore, in one configuration example of the software updating method of the present invention, the seventh step is characterized in that, when there is only one second device that has reserved distribution at the same scheduled time, the software is distributed by unicast communication to the second device, and, when there are multiple second devices that have reserved distribution at the same scheduled time, the software is distributed by multicast communication. Furthermore, in one configuration example of the software updating method of the present invention, the sixth step includes a step of notifying the first device of the desired date and time for updating the software together with the reserved time, the seventh step includes a step of adjusting the transmission interval of unicast packets so that the delivery completion date and time does not exceed the desired date and time when distributing the software by unicast communication, and a step of distributing the software by unicast communication to the second device for which it has been determined that the delivery completion date and time will exceed the desired date and time when distributing the software by multicast communication, and the eighth step includes a step of the second device updating the software set in its own device to the software distributed from the first device at the desired date and time.

[0011] Furthermore, in one configuration example of the software update method of the present invention, the first 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 second 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. Furthermore, in one configuration example of the software update method of the present invention, the first device is a primary controller for control or a cloud server, and the model type ID of the first device and the model type ID of a subordinate primary controller to be updated that is connected to the first device via a network are set in the memory of the first device, and the second device has the model type ID of the first device as the primary controller for control, the model type ID of the second device as a sub-controller for control, and the model type ID of a subordinate sub-controller to be updated that is connected to the first device via a network set in the memory of the second device, and operates as the primary controller to be updated and also operates as the first device that is a distribution master for the sub-controller to be updated.

[0012] 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 includes an address setting unit configured to set a range of a first multicast address that the device can receive when the device is a first device set as a distribution master, and to generate a second multicast address for distributing software to a predefined second device that is a target for updating, and to set a range of the first multicast address that the device can receive when the device is a second device that is not set as a distribution master; a transmitting unit configured to transmit a multicast packet that notifies the version number of the software to be updated to the second multicast address when the device is the first device; a receiving unit configured to receive a multicast packet that is destined for an address within the range of the first multicast address set by the device; and a receiving unit configured to receive a multicast packet that notifies the version number of the software to be updated to the second multicast address when the device is the second device. The device comprises an update determination unit configured to compare a version number notified in a received multicast packet with the version number of the software set in the device itself to determine whether a software update is necessary; a distribution request unit configured to request the first device to start distributing software at a specified reserved time when the update determination unit of the device itself determines that a software update is necessary, when the device itself is the second device; a distribution unit configured to start distributing software at the reserved time in response to a distribution request from the second device, when the device itself is the first device; and a software update unit configured to update the software set in the device to the software distributed from the first device, when the device itself is the second device, wherein the distribution request unit determines the reserved time based on the load status of the device itself and the load status of the network to which the device is connected. Effect of the Invention

[0013] According to the present invention, the first device set as a distribution master sets the range of the first multicast address that the device can receive and generates a second multicast address for distributing software to the second device to be updated, the second device sets the range of the first multicast address that the device 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, compares the version number notified by the multicast packet with the version number of the software set in the device, and if it is determined that the software needs to be updated, it requests the first device to start distributing the software at a designated reservation time. Also, in the present invention, the second device determines the reservation time based on the load status of the device itself and the load status of the network to which the device itself is connected. As a result, in the present invention, the network load can be reduced even when a large number of devices are connected to the network. Also, in the present invention, it is possible to minimize the impact on the operating system by each device determining whether or not it needs to update its software.

[0014] Furthermore, in the present invention, when there are multiple second devices that have reserved distribution at the same scheduled time, the software is distributed via multicast communication, thereby reducing the load on the network and enabling efficient software distribution to the multiple second devices.

[0015] In addition, in the present invention, when distributing software via unicast communication, the transmission interval of unicast packets is adjusted so that the distribution completion date and time does not exceed the desired date and time, and when distributing software via multicast communication, the software is distributed via unicast communication to a second device for which it has been determined that the distribution completion date and time will exceed the desired date and time, thereby making it possible to complete software distribution by the desired date and time notified by the second device.

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

[0017] Furthermore, in the present invention, by setting in the memory of the second device the model type ID of the device itself as a primary controller for control, the model type ID of the device itself as a sub-controller for control, and the model type ID of a subordinate sub-controller to be updated that is connected to the second device via a network, it becomes possible to operate the second device as the primary controller to be updated and also as the first device which is a distribution master for the sub-controller to be updated. [Brief description of the drawings]

[0018] [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 sequence diagram for explaining the operation when software is distributed by unicast communication in the present invention. [Figure 7] FIG. 7 is a sequence diagram for explaining the operation when software is distributed by multicast communication in the present invention. [Figure 8] FIG. 8 is a block diagram showing the configuration of an air conditioning system according to a first embodiment of the present invention. [Figure 9] FIG. 9 is a block diagram showing the configuration of an apparatus according to a first embodiment of the present invention. [Figure 10] FIG. 10 is a block diagram showing the configuration of an air conditioning system according to a second embodiment of the present invention. [Figure 11] FIG. 11 is a block diagram showing a configuration of a cloud server according to the second embodiment of the present invention. [Figure 12] FIG. 12 is a sequence diagram illustrating a software updating method according to the second embodiment of the present invention. [Figure 13] FIG. 13 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

[0019] [Principle of the invention] The present invention provides a function in a distributed system using an IP network where the controller itself automatically updates software in bulk according to the load status of the network, the load status of the device itself, and the urgency of the software update.The present invention proposes a method in which, when the software set in the air conditioning controller is the latest and of high importance, the device plays a role in distributing the software without the intervention of an operator or a dedicated software update tool, and the device distributes software in bulk or individually to the same controllers connected to the network according to the reservation time, without installing a special software distribution device.

[0020] In the present invention, a device that undergoes software update judges its own load status (CPU usage rate) and network load status, and reserves the date and time of software distribution to a device that distributes the software. At this time, the reservation is made by unicast communication.

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

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

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

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

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

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

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

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

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

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

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

[0032] 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".

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

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

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

[0036] 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".

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

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

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

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

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

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

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

[0044] 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".

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

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

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

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

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

[0050] 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 sender of the multicast packet (step S104 in FIG. 5). This unicast packet contains information about the reserved time for software distribution. As will be described later, 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.

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

[0052] At this time, if only one device 1-2 has reserved distribution at the same reservation 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 reservation 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.

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

[0054] 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 restarts itself to update the software during a time period that will not affect the operation of the system (step S106 in FIG. 5). In this way, the software of the device 1-2 is updated to the software distributed from the device 1-1.

[0055] Next, a method for determining a reservation time for software distribution will be described. For a certain period (e.g., one week), the device 1-2 counts its own CPU (Central Processing Unit) usage rate, the number of received messages in UDP (User Datagram Protocol) communication addressed to the device itself, and the number of received messages in broadcast communication for each hour from 0:00 to 24:00, and derives the time when the total of these count values ​​is the smallest as the time when the load on the device itself and the network 2 is the lowest.

[0056] The device 1-2 notifies the distribution master of the derived time as the reservation time T for distribution (step S104). When the above count value is calculated in 30-minute units, the reservation time T is also in 30-minute units. However, it is not certain whether the distribution master will be in a state where distribution is possible at the reservation time T. Therefore, the device 1-2 notifies the distribution master of the reservation time T, the allowable time β (minutes) before and after the reservation time T, and the desired date and time for updating the software by a unicast packet.

[0057] For example, if the allowable time before and after the reservation time T is 0 minutes and the reservation time T is 9:30 p.m., it is assumed that software distribution will start from the distribution master at 9:30 p.m. On the other hand, if the allowable time before and after the reservation time T is 60 minutes and the reservation time T is 9:30 p.m., this indicates that the distribution time may be shifted depending on the load status of the distribution master within the time range from 8:30 p.m. to 10:30 p.m.

[0058] Furthermore, the desired date and time for updating the software is notified as a desired date and time explicitly set by the user of the system, for example. However, the air conditioning controller may calculate a date and time at which the software can be safely updated. The method of determining the desired date and time is not a required constituent element of the present invention, and the desired date and time may be determined by any method.

[0059] Furthermore, the desired date and time for software update does not have to be notified to the distribution master. If the desired date and time is not explicitly specified, the distribution master starts software distribution within a time range of the reservation time T±β depending on the load status of the device itself and the load status of the network 2. If the desired date and time for software update is explicitly notified from the device to be updated, the distribution master automatically adjusts the software distribution method and packet transmission interval taking into account the reservation time T and the desired date and time.

[0060] In order to shift the reservation time for each device to be updated, the reservation time T may be determined as follows: T=t+MOD(n / m)×offset (1)

[0061] t is the time (e.g., 1:00 AM) when the load on the device and the network is the lowest, derived from the count value during the one-week period mentioned above, n is a unique device number predefined by an engineering tool for each device, offset is the offset time (e.g., 5 minutes), m is the number of groups divided by 1 hour (60 minutes) taking into account the offset time (e.g., if the offset time is 5 minutes, m is 12 (60 / 5)), and MOD(n / m) represents the remainder when the device number is divided by the number of groups m.

[0062] As described above, when only one device 1-2 has reserved distribution at the same reservation time T, device 1-1 distributes software to device 1-2 by unicast communication. Figure 6 is a sequence diagram explaining the operation when distributing software by unicast communication.

[0063] Device 1-1 calculates the number N of unicast packets required for distribution from the size of the software to be distributed, divides the data of the software to be distributed into block data of the number N of unicast packets, and sequentially stores each divided block data in a unicast packet for distribution. A packet ID is added to each unicast packet. In the example of Fig. 6, device 1-1 distributes a unicast packet with packet ID = i (i is an integer from 1 to N) (step S200-i in Fig. 6), and device 1-2 returns a response indicating that it has received the packet normally (step S201-i).

[0064] If device 1-1 does not receive a response for packet ID=i from device 1-2 until a certain waiting time has elapsed since the delivery of the unicast packet for packet ID=i, device 1-1 may deliver the unicast packet for packet ID=i again.

[0065] When device 1-1 receives a response with packet ID=N from device 1-2 and determines that distribution of unicast packets number N has been completed, device 1-1 cancels the distribution reservation for device 1-2 (step S202 in FIG. 6).

[0066] After there are no more arriving unicast packets, device 1-2 can recover the software before it was divided by extracting and combining block data from each received unicast packet. Device 1-2 then reboots itself to update the software at the desired date and time for updating the software (step S203 in FIG. 6). If the desired date and time for updating the software is not set, the reboot should be performed during a time period that will not affect the operation of the system.

[0067] When device 1-1 is notified by device 1-2 of the desired date and time for updating software, device 1-1 automatically adjusts the transmission interval based on the number of unicast packets N (number of transmission and reception sequences) calculated from the size of the software to be distributed so that the distribution completion date and time does not exceed the notified desired date and time. In other words, if the time from reservation time T to the desired date and time is short, the packet transmission interval is adjusted to be shorter so that the distribution completion date and time does not exceed the desired date and time.

[0068] As described above, device 1-1 distributes software by multicast communication when there are multiple devices 1-2 that have reserved distribution at the same reservation time T. Figure 7 is a sequence diagram explaining the operation when distributing software by multicast communication.

[0069] As in the case of unicast communication, device 1-1 calculates the number N of multicast packets required for distribution from the size of the software to be distributed, divides the data of the software to be distributed into block data equal to the number of multicast packets, and sequentially stores each divided block data in a multicast packet for distribution. A packet ID is added to each multicast packet. In the example of FIG. 7, device 1-1 sequentially distributes multicast packets with packet ID=i (i is an integer from 1 to N) (FIG. 7 step S300-i). Taking into account the load on the network, device 1-1 distributes multicast packets at intervals of the minimum time unit of the reservation time T.

[0070] If device 1-2 determines that it has not received the multicast packet with packet ID=i after there are no more multicast packets arriving (step S301 in FIG. 7), it requests device 1-1, the source of the packet, to resend the multicast packet with packet ID=i that it has not received (step S302 in FIG. 7).

[0071] The device 1-1 retransmits the multicast packet with the packet ID=i requested by the device 1-2 (step S303 in FIG. 7). After receiving all the multicast packets, the device 1-2 notifies the device 1-1 of the completion of reception (step S304 in FIG. 7).

[0072] When device 1-1 receives a reception completion notice from device 1-2, it determines that distribution of the number N of multicast packets is complete, and cancels the distribution reservation for device 1-2 (step S305 in FIG. 7).

[0073] After there are no more multicast packets arriving, device 1-2 can extract and combine the block data from each received multicast packet to restore the software to its original state before it was divided. If the multicast packets are resent, the order of the packets will change, but the software can be restored by rearranging the data in the correct order, for example, based on the packet ID.

[0074] Then, the device 1-2 is rebooted to update the software at the desired date and time for updating the software (step S306 in FIG. 7). If the desired date and time for updating the software is not set, the device 1-2 may be rebooted during a time period that will not affect the operation of the system.

[0075] If device 1-1 determines that a device 1-2 that has notified the desired date and time for software update is present among multiple devices 1-2 that have reserved distribution at the same reservation time T and that the distribution completion date and time would exceed the desired date and time if the software is distributed by multicast communication, device 1-1 distributes software by unicast communication to the device 1-2 for which it has determined that the distribution completion date and time will exceed the desired date and time.

[0076] Since the reservation time T, the number of packets (the number of transmission / reception sequences), and the packet transmission interval are known values, it is possible to calculate the distribution completion date and time. As described above, in the case of unicast communication, the packet transmission interval can be adjusted to be shorter so that the delivery completion date and time does not exceed the desired date and time.

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

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

[0079] In the example of Fig. 8, 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.

[0080] 9 is a block diagram showing the configuration of the device 1a-1. The device 1a-1 includes a CPU 10, a memory 11, and an interface device (I / F) 12. The I / F 12 is connected to other devices 1a-2, 1b-1, and 1b-2 via a network 2, and is also connected to air conditioners via a control network (not shown). The CPU 10 executes processing according to software stored in the memory 11, and functions as an address setting unit 100, a transmitting unit 101, a receiving unit 102, an update determining unit 103, a distribution request unit 104, a distribution unit 105, a software updating unit 106, and a control unit 107 that controls the air conditioners.

[0081] The memory 11 stores the software of the device 1a-1, the model type ID and physical version number of the device itself, the purpose of the software update of the device itself that is permitted in advance (purpose-specific number), the model type ID and physical version number of the device to be updated, the update purpose of the software to be updated (purpose-specific number), 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 software set in the device itself. In addition, in the case of a distribution master, definition information indicating that the device itself is a distribution master is set in the memory 11.

[0082] In the example of FIG. 9, the configuration of the device 1a-1 is described, but since the configurations of the devices 1a-2, 1b-1, and 1b-2 are similar to that of the device 1a-1, 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.

[0083] The software update method of this embodiment will be described with reference to Fig. 5 to Fig. 7. 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.

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

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

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

[0087] If 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 software version number set in the device itself and that a software update is necessary, the distribution request unit 104 of the device 1a-2, 1b-2 sends a unicast packet to the device 1a-1, 1b-1 that sent the multicast packet, requesting distribution of the software (Figure 5 step S104).

[0088] This unicast packet contains information on the reservation time T for software distribution and the allowable time before and after β. The distribution request units 104 of the devices 1a-2 and 1b-2 each determine the reservation time T by the above-mentioned method. The allowable time before and after β is a predefined known value. Furthermore, if the desired date and time for updating the software is predetermined, the distribution request units 104 of the devices 1a-2 and 1b-2 each store information on the desired date and time in the unicast packet.

[0089] 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 within the time range of the reservation time T±β specified in the unicast packets in response to the distribution requests from the devices 1a-2 and 1b-2 (step S105 in FIG. 5).

[0090] When only one device 1a-2 has reserved distribution at the same reservation time T, distribution unit 105 of device 1a-1 distributes the software by unicast communication addressed to device 1a-2. Similarly, when only one device 1b-2 has reserved distribution at the same reservation time T, distribution unit 105 of device 1b-1 distributes the software by unicast communication addressed to device 1b-2. Furthermore, when distribution units 105 of devices 1a-1 and 1b-1 are notified of the desired date and time for updating the software by devices 1a-2 and 1b-2, respectively, they adjust the packet transmission interval so that the distribution completion date and time does not exceed the desired date and time.

[0091] When the distribution request units 104 of the devices 1a-2 and 1b-2 normally receive the unicast packets with packet ID=i from the devices 1a-1 and 1b-1, they return responses with packet ID=i to the devices 1a-1 and 1b-1 (step S201-i in FIG. 6).

[0092] If the distribution units 105 of the devices 1a-1 and 1b-1 do not receive a response of packet ID=i from the devices 1a-2 and 1b-2 until a certain waiting time has elapsed since the distribution of the unicast packet of packet ID=i, they distribute the unicast packet of packet ID=i again. When the distribution units 105 of the devices 1a-1 and 1b-1 receive responses of packet ID=N from the devices 1a-2 and 1b-2, respectively, they cancel the distribution reservation for the devices 1a-2 and 1b-2 (step S202 in FIG. 6).

[0093] Furthermore, when there are multiple devices 1a-2 that have reserved distribution at the same reservation time T, the distribution unit 105 of the device 1a-1 distributes the software by multicast communication addressed to a multicast address that can be received by these devices 1a-2 (FIG. 7, step S300-i). At this time, the multicast address used is the multicast address used in the notification in step S102.

[0094] If the distribution request unit 104 of the device 1a-2 determines that the multicast packet with packet ID=i has not been received, it requests the device 1a-1, the source of the packet, to resend the multicast packet with packet ID=i (FIG. 7, step S302). The distribution unit 105 of the device 1a-1 retransmits the multicast packet with the packet ID=i requested by the device 1a-1 (FIG. 7, step S303).

[0095] After receiving all the multicast packets, the distribution request unit 104 of the device 1a-2 notifies the device 1a-1 of the completion of reception (Step S304 in FIG. 7). When the distribution unit 105 of the device 1a-1 receives a reception completion notification from the device 1a-2, it cancels the distribution reservation for the device 1a-2 (Step S305 in FIG. 7).

[0096] When a device 1a-2 that has notified a desired date and time for updating software is present among a plurality of devices 1a-2 that have reserved distribution at the same reservation time T, and when it is determined that the distribution completion date and time will exceed the desired date and time if the software is distributed by multicast communication, a distribution unit 105 of the device 1a-1 distributes software by unicast communication to the device 1a-2 for which it has determined that the distribution completion date and time will exceed the desired date and time.

[0097] 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 105 of the devices 1a-2 and 1b-2 restart the devices 1a-2 and 1b-2 to update the software at the desired date and time for updating the software (step S106 in FIG. 5). If the desired date and time for updating the software is not set, the devices 1a-2 and 1b-2 may be restarted during a time period that will not affect the operation of the system.

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

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

[0100] In the example of Fig. 10, 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.

[0101] 11 is a block diagram showing the configuration of cloud server 3. Cloud server 3 includes a CPU 30, a memory 31, and an I / F 32. Devices 1a-2, 1b-2, and 1c-2 are connected to I / F 32 via network 4. CPU 30 executes processing according to software stored in memory 31, 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. 9, and therefore will be described using the same reference numerals as in FIG.

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

[0103] The memory 31 of the cloud server 3 stores the software of the device itself, the model type ID and physical version number of the device itself, the model type IDs and physical version numbers of the devices 1a-2, 1b-2, and 1c-2 to be updated, the update purpose (purpose number) of the software to be updated, and software prepared for distribution. The memory 31 also stores definition information indicating that the device itself is a distribution master.

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

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

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

[0107] 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. 12). The information contained in the unicast packet is the same as in the first embodiment.

[0108] 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 within the time range of the reservation time T±β specified in the unicast packet in response to the distribution request from the devices 1a-2, 1b-2, and 1c-2 (FIG. 12, step S405). It goes without saying that the software may differ depending on the model of the controller.

[0109] As in the first embodiment, the software is distributed by unicast or multicast communication. The receiving unit 102 of the devices 1a-2, 1b-2, and 1c-2 receives the software distributed from the cloud server 3. The software update unit 105 of the devices 1a-2, 1b-2, and 1c-2 restarts the devices to update the software at the desired date and time for updating the software (step S406 in FIG. 12). If the desired date and time for updating the software is not set, the devices may be restarted during a time period that will not affect the operation of the system.

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

[0111] [Third Example] Next, a third embodiment of the present invention will be described. Fig. 13 is a block diagram showing the configuration of an air conditioning system (distributed system) according to the third embodiment of the present invention. Fig. 13 shows only devices 1a-2, 1c-2, 1d-2, 1e-2, 1f-2, 1g, 1h, 1i, 1j, 1k, and 1m, which are controllers, and a cloud server 3, 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.

[0112] In the example of Fig. 13, 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.

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

[0114] 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. 9, so they will be described using the symbols in Fig. 9. 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.

[0115] The memory 31 of the cloud server 3 stores the software of its own device, the model type ID and physical version number of its own device, the model type IDs and physical version numbers of the update target devices 1a-2, 1c-2, 1d-2, 1e-2, 1f-2, 1g, 1h, 1i, 1j, 1k, and 1m, the update purpose (purpose number) of the software to be updated, and software prepared for distribution. Also, the memory 31 stores definition information indicating that its own device is a distribution master.

[0116] The memory 11 of the devices 1a-2 and 1c-2 stores the software of the device itself, the model type ID and physical version number of the device itself, and the purpose (purpose-specific number) of a software update of the device itself that is permitted in advance.

[0117] On the other hand, the devices 1d-2, 1e-2, and 1f-2 can act as virtual sub-controllers. That is, the memory 11 of the device 1d-2 stores software of the device itself as a primary controller, software of the device itself as a sub-controller, a model type ID and a physical version number of the device itself as a primary controller, a purpose (purpose-specific number) of a software update of the device itself as a primary controller that is permitted in advance, and a purpose (purpose-specific number) of a software update of the device itself as a sub-controller that is permitted in advance.

[0118] Furthermore, the memory 11 of the device 1d-2 stores the model type ID and physical version number of its own device as a sub-controller, the model type IDs and physical version numbers of the subordinate devices 1g and 1h to be updated, the update purpose (purpose-specific 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.

[0119] Similarly, memory 11 of device 1e-2 stores software for its own device as a primary controller, software for its own device as a sub-controller, the model type ID and physical version number of its own device as a primary controller, the purpose (purpose-specific number) of a software update for its own device as a primary controller that has been permitted in advance, and the purpose (purpose-specific number) of a software update for its own device as a sub-controller that has been permitted in advance.

[0120] Furthermore, the memory 11 of the device 1e-2 stores the model type ID and physical version number of its own device as a sub-controller, the model type IDs and physical version numbers of the subordinate devices 1i, 1j, and 1k to be updated, 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.

[0121] Similarly, the memory 11 of device 1f-2 stores the software of its own device as a primary controller, the software of its own device as a sub-controller, the model type ID and physical version number of its own device as a primary controller, the purpose (purpose-specific number) of a software update that has been permitted in advance for its own device as a primary controller, and the purpose (purpose-specific number) of a software update that has been permitted in advance for its own device as a sub-controller.

[0122] Furthermore, the memory 11 of the device 1f-2 stores the model type ID and physical version number of its own device as a sub-controller, the model type ID and physical version number of the subordinate device 1m to be updated, 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 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 sub-controllers under it.

[0123] 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 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. 12, 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.

[0124] 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. 12, step S401).

[0125] 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. 12, step S401).

[0126] 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. 12, step S402).

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

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

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

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

[0131] 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 within the time range of the reservation time T±β 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 (FIG. 12, step S405). It goes without saying that the software may differ for each model of the primary controller and each model of the sub-controller.

[0132] 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. The software update units 105 of the devices 1a-2, 1c-2, 1d-2, 1e-2, and 1f-2 restart the devices to update the software at the desired date and time for updating the software (step S406 in FIG. 12). If the desired date and time for updating the software is not set, the devices may be restarted during a time period that will not affect the operation of the system.

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

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

[0135] 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]

[0136] 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]

[0137] 1-1, 1a-1, 1b-1, 1-2, 1a-2 to 1f-2, 1g to 1k, 1m...devices, 2, 4 to 7...network, 3...cloud server, 10, 30...CPU, 11, 31...memory, 12, 32...interface device, 100...address setting unit, 101...transmitting unit, 102...receiving unit, 103...update determination unit, 104...distribution request unit, 105...distribution unit, 106...software update unit, 107...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 sets a range of a first multicast address that the first device can receive and generates a second multicast address for distributing software to a predefined second device that is a target for updating; a second step of the second device setting a range of a first multicast address that the second device can receive; a third step of transmitting a multicast packet to the second multicast address from the first device, the multicast packet notifying the version number of the software to be updated; a fourth step of receiving a multicast packet destined for an address within the range of the first multicast address set by the second device; a fifth step of the second device comparing the version number notified in the multicast packet received in the fourth step with a version number of the software set in the second device to determine whether or not software updating is necessary; a sixth step of requesting the first device to start distributing the software at a designated reserved time when the second device determines that a software update is necessary; a seventh step of the first device starting distribution of the software at the reserved time in response to a distribution request from the second device; and an eighth step of the second device updating software set in the second device to the software distributed from the first device; The software update method is characterized in that the sixth step includes a step in which the second device determines the reservation time based on a load condition of the second device and a load condition of a network to which the second device is connected.

2. 2. The software update method according to claim 1, The sixth step is characterized in that it includes a step of counting the CPU usage rate of the device itself and the number of messages received from the network during a certain period in the past, and determining the time when the sum of these count values ​​is the smallest as the scheduled time.

3. 2. The software update method according to claim 1, the sixth step includes a step of notifying the first device of an allowable time before and after the reservation time together with the reservation time, The software update method is characterized in that the seventh step includes a step of starting distribution of the software within a time range of T±β, where T is the reservation time and β is the allowable time before and after the reservation time.

4. 2. The software update method according to claim 1, The seventh step of the software update method includes a step of distributing the software by unicast communication addressed to the second device when there is only one second device that has reserved distribution at the same scheduled time, and distributing the software by multicast communication when there are multiple second devices that have reserved distribution at the same scheduled time.

5. 5. The software updating method according to claim 4, the sixth step includes a step of notifying the first device of a desired date and time for updating the software together with the reservation time; the seventh step includes a step of adjusting a transmission interval of a unicast packet so that a distribution completion date and time does not exceed the desired date and time when distributing the software by the unicast communication, and a step of distributing the software by the unicast communication to the second device determined to have a distribution completion date and time that will exceed the desired date and time when distributing the software by the multicast communication; The software update method is characterized in that the eighth step includes a step in which the second device updates the software set in the second device to software distributed from the first device at the desired date and time.

6. 2. The software update method according to claim 1, The first 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; A software update method characterized in that the second 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.

7. 7. The software updating method according to claim 6, the first device is a primary controller or a cloud server for control, and a model type ID of the first device and a model type ID of a subordinate primary controller to be updated that is connected to the first device via a network are set in a memory of the first device; The second device is characterized in that the model type ID of the device itself as a primary controller for control, the model type ID of the device itself as a sub-controller for control, and the model type ID of a subordinate sub-controller to be updated that is connected to the second device via a network are set in the memory of the second device, and the second device operates as the primary controller for the update target and also operates as a first device that is a distribution master for the sub-controller to be updated.

8. In a distributed system in which a plurality of devices are distributed and arranged on a network, Each device is an address setting unit configured to set a range of a first multicast address that the device itself can receive when the device itself is a first device set as a distribution master, generate a second multicast address for distributing software to a predefined second device that is a target for updating, and set the range of the first multicast address that the device itself can receive when the device itself is a second device that is not set as a distribution master; a transmitting unit configured to transmit a multicast packet notifying a version number of the software to be updated to the second multicast address when the own device is the first device; a receiving unit configured to receive a multicast packet destined for an address within the range of the first multicast address set by the own device; an update determination unit configured to compare a version number notified in the multicast packet received by the receiving unit with a version number of software set in the own device when the own device is the second device, and to determine whether software updating is necessary; a distribution request unit configured to request the first device to start distributing software at a designated reservation time when the update determination unit of the first device determines that software update is necessary, when the device itself is the second device; a distribution unit configured to start distributing software at the reserved time in response to a distribution request from the second device when the device itself is the first device; a software update unit configured to update software set in the device to software distributed from the first device when the device itself is the second device; A distributed system, wherein the distribution request unit determines the reservation time based on a load state of the own device and a load state of a network to which the own device is connected.

Images