System and method for distributing a software update to a plurality of nodes in a network

Abstract

The present disclosure provides systems and methods for automating the distribution of a software update (such as a firmware update) to a plurality of devices (nodes) in a network. A software update distribution plan is generated based on one or more constraints (e.g. input by a system user). The software update is sent to each node of the plurality of nodes according to the software update distribution plan via a plurality of requests.

Description

[0001] SYSTEM AND METHOD FOR DISTRIBUTING A SOFTWARE UPDATE TO A PLURALITY OF NODES IN A NETWORK

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to systems and methods for distributing a software update to a plurality of nodes in a network.

[0004] BACKGROUND

[0005] Distributing a firmware update to a large deployment of devices, such as smart meters, while maintaining a required service level agreement (SLA) is currently a task that is performed manually. For example, an SLA may require a minimum amount of metering operations to continue at the deployment while the update is taking place, such that the impact of the update on the metering operations is minimized.

[0006] SUMMARY

[0007] The present disclosure provides systems and methods for automating the distribution of a software update (such as a firmware update) to a plurality of devices (nodes) in a network. As described herein, a software update distribution plan is generated based on one or more constraints (e.g. input by a system user). The software update distribution plan includes requests that may be scheduled according to the constraints so that the software update is delivered to the devices incrementally and dynamically to maintain a service level agreement (SLA).

[0008] Described herein is a system for distributing a software update to a plurality of nodes in a network. The plurality of nodes may be distributed among one or more metering locations. The system comprises an input device configured to receive one or more constraints. The one or more constraints may correspond to a targeted software update for the plurality of nodes. The system further comprises a processing device configured to generate a software update distribution plan for the plurality of nodes based on theone or more constraints. The software distribution plan may comprise a plurality of requests. The system also comprises a communications device. The system may be configured to send, via the communications device, the software update to each node of the plurality of nodes according to the software update distribution plan via the plurality of requests.

[0009] Also described herein is a method for distributing a software update to a plurality of nodes in a network. The plurality of nodes may be distributed among one or more metering locations. The method comprises receiving one or more constraints. The one or more constraints may correspond to a targeted software update for the plurality of nodes. The method further comprises generating a software update distribution plan for the plurality of nodes based on the one or more constraints. The software distribution plan may comprise a plurality of requests. The method also comprises sending the software update to each node of the plurality of nodes according to the software update distribution plan via the plurality of requests.

[0010] A network according to the present disclosure is a network of devices, which may comprise devices that provide metering of consumption of a resource (i.e. a utility such as electricity, gas, or water). For example, a node in the network may be a smart meter. In at least some examples, the network may comprise devices that do not provide a metering function (e.g. such as edge devices). Some nodes may act as root nodes in some examples. The network may be a mesh network. The system described herein may be, or may comprise, a head-end system. The smart meters may transmit metering data to / from the head-end system, e.g. via the root nodes. The root nodes may also be capable of receiving the software update.

[0011] The systems and methods described herein may advantageously result in improved efficiency and reduced operational costs for managing a large volume of software (e.g. firmware) updates across a large deployment of smart meters.

[0012] The one or more constraints may comprise a maximum proportion of nodes at each metering location of the one or more metering locations to be impacted (i.e. to exhibit a performance change) due to the software update. For example, the one or more constraints may comprise a target impact (e.g. impact to the SLA), the target impact being a maximum reduction in metering data transfers by the nodes at each of the one or more metering locations. The metering data transfers may include meter reading datapushes from smart meters, receipt of metering data by any root nodes, transfers of metering data from root nodes (e.g. to the head-end system), and / or any other kinds of data transfers between nodes in the network.

[0013] The maximum reduction in metering data transfers may correspond to the SLA for the deployment at the metering locations. By receiving the target impact as a constraint input, the systems and methods according to the present disclosure can dynamically manage the distribution of the software update so that the SLA is maintained during the update. For example, the target impact may be 5%. The requests of the software update distribution plan are then scheduled such that the target impact is maintained, e.g. by scheduling the software update incrementally across dynamically generated groups of nodes.

[0014] A metering location may be, for example, a building (such as an office or residential building), or may be a group of buildings.

[0015] In some examples, generating the software update distribution plan comprises determining a plurality of node groups for each metering location. Each node group may include a group of devices including smart meters and / or root nodes. Each node group may comprise a number of nodes corresponding to the target impact. For example, a node group may correspond to 10,000 nodes (e.g. smart meters) for a metering location having 200,000 smart meters where the target impact is set at 5%.

[0016] In some examples, the number of nodes in a node group may not correspond exactly to the target impact percentage or proportion. That is, the target impact may define an impact on overall performance of the nodes at the metering location collectively, and it may be possible or necessary to send the software update to more or fewer nodes than the proportion corresponding to the target impact while maintaining the same target impact (i.e. SLA). For example, the number of nodes in each node group may be determined based on the target impact, but the actual number of nodes in each node group may additionally be determined based on other factors such as the network bandwidth, the size of the software update, the amount of time allocated to perform the update, the required update duration, etc. At least some of the factors used to determine the number of nodes in each node group may be provided as constraints. For example, determining the number of nodes in each node group may comprise balancing the target impact with the required update duration.The plurality of requests may comprise a first distribution request. Sending the software update according to the software update distribution plan may comprise sending a first software update request to one node group at each metering location at a time. That is, the first distribution request may be sent to no more than one node group at each metering location at a time, so that the target impact is not exceeded.

[0017] In some examples, the first distribution request may be sent to node groups at multiple metering locations (e.g. in multiple buildings) in parallel. The SLA can therefore be maintained for each metering location while the update takes place across multiple metering locations.

[0018] In some examples, following the completion of an initial distribution of the software update to a deployment of devices (nodes), e.g. via the first distribution request, it may be desirable to resend the software update to at least a subset of the nodes, or node groups. For example, resending the software update may ensure that any devices (nodes) that are added to the deployment during the first distribution request are able to receive the update.

[0019] For example, the software update distribution plan may comprise one or more redistribution requests, and the software update may be resent (e.g. via the communications device of the system) to at least a subset of the node groups at a metering location, via the one or more redistribution requests, after the first distribution request has been sent to all node groups at the metering location.

[0020] It will be understood that the redistribution request(s) at a given metering location should only be carried out after the completion of the initial software distribution (via the first distribution request), so that the SLA is preserved.

[0021] As with the first distribution request, the one or more redistribution requests may be sent to one node group at the metering location at a time (i.e. to one node group at a given metering location at any given time).

[0022] In some examples, the software update distribution plan is configured to terminate after a predetermined number of redistribution requests.In some examples, generating the software update distribution plan comprises determining a transmission mode for each request. A transmission mode may be one of a multicast transmission mode or a unicast transmission mode. For example, the transmission mode may be selected automatically and / or dynamically according to network bandwidth, SLA impact, etc.

[0023] In some examples, the transmission mode may be input as one of the constraints.

[0024] In some examples, generating the software distribution plan comprises determining a first transmission mode for the first distribution request, and a second transmission mode for at least one of the redistribution requests. The second transmission mode may be different from the first transmission mode. For example, the first distribution request may comprise distributing the software update in a multicast transmission mode, and at least one of the redistribution requests may comprise redistributing the software update in a unicast transmission mode.

[0025] In some examples, generating the software distribution plan comprises determining a transmission mode for a first redistribution request after the first distribution request according to a success rate of the first distribution request, i.e. according to a success rate of software update downloads by the nodes. For example, the first distribution request may comprise distributing the software update in a multicast transmission mode. If a total number of nodes to download the software update successfully via the first distribution request is above a threshold, subsequent redistribution requests may comprise a unicast transmission mode (e.g. to attempt to distribute the software update directly to those nodes that were unsuccessful in the first distribution request). If the total number of nodes to download the software update successfully via the first distribution request is below the threshold, at least the first redistribution request (i.e. the redistribution request immediately after the first distribution request) may comprise distributing the software update in a multicast transmission mode again. Therefore, the conditions for the redistribution request(s) can be optimized according to available network bandwidth, the SLA impact, or other conditions of the network / nodes.

[0026] In some examples, the one or more constraints comprise an activation time and / or date. For example, a user may be able to input a time and / or date at which the software update(s) can be sent according to the software update distribution plan. The activationtime and / or date could, for example, be early in the morning or late in the evening (i.e. outside of office hours) to minimize disruption.

[0027] In some examples, the one or more constraints comprise one or more excluded activation time periods (e.g. excluded activation dates). For example, the software update distribution plan could be constrained so that updates do not take place at weekends, so that updates do not take place when a user responsible for the network is unavailable to monitor the network for errors or problems.

[0028] In some examples, the one or more constraints comprise an excluded group of nodes. For example, certain groups of nodes may be excluded based on geographical area.

[0029] BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The invention will now be described, by way of example only, with reference to the following drawings:

[0031] Figure 1 depicts an example of a network according to the present disclosure;

[0032] Figure 2 schematically illustrates an example of a system, such as a head-end system, according to the present disclosure;

[0033] Figure 3 depicts a flow diagram illustrating some examples of software distribution according to the present disclosure;

[0034] Figure 4 depicts a flow diagram illustrating some further examples of software distribution according to the present disclosure;

[0035] Figure 5 is a process flow diagram illustrating some examples of decisions that may be taken according to some examples of a software distribution plan according to the present disclosure;

[0036] Figure 6 schematically illustrates a processing sequence for some examples of systems and methods according to the present disclosure in which a software update is distributed across a deployment having multiple metering locations;

[0037] Figure 7 illustrates examples of distribution plan variations employing different transmission modes according to the present disclosure;

[0038] Figure 8 schematically illustrates an example in which multiple requests are created dynamically;

[0039] Figure 9 schematically illustrates an example of a user interface that may be provided in some examples according to the present disclosure; andFigure 10 schematically illustrates a method for distributing a software update to a plurality of nodes in a network according to the present disclosure.

[0040] DETAILED DESCRIPTION

[0041] Distributing a firmware update to a large deployment of devices, such as smart meters while maintaining a required service level agreement (SLA) is usually performed as a manual task. This manual task is extremely labor intensive, requiring tracking the smart meters requiring the firmware update; creating groups of smart meters to manage the impact to the target SLA, and incorporating smart meters added to the deployment over the span of the distribution process.

[0042] The invention according to the present disclosure may automate at least some of the steps required to identify the smart meter(s) in need of the firmware update, incrementally and dynamically creating groups of the smart meters targeted for the update to maintain the SLA target, and scheduling requests to utilize firmware distribution methods.

[0043] In at least some examples, the present disclosure may also provide automatic selection of firmware distribution methods (e.g. multicast or unicast) dynamically. This may greatly reduce the operational costs and improve efficiency when managing a large volume of firmware updates.

[0044] In some examples, the systems and methods according to the present disclosure may provide flexibility to vary the target SLA to accelerate the firmware update to balance the SLA against the overall duration for effecting the firmware updates.

[0045] It will be understood that references to “firmware” (including firmware versions, firmware updates, firmware distribution plans, etc.) illustrate examples according to the present disclosure that may be applicable more generally to other kinds of software (other than firmware) as well.

[0046] Figure 1 depicts an example of a network 100 according to the present disclosure. The example depicted in Figure 1 is a mesh network. The example network 100 may be a time-synchronized channel hopping (TSCH) network, as defined by I EEE 802.15.4e. Thenetwork 100 may be a network of RF Mesh IP / Wi-SUN (Wireless Smart Utility Network) nodes. The network 100 is an example of a mesh network upon which the present invention may be implemented. In examples, the network 100 may comprise a full mesh topology, e.g. where any node can communicate with any node within range, or a partial mesh topology with more limited or selected connectivity between nodes.

[0047] The example network comprises a head-end system 110. The head-end system 110 may be known in the art as an “AMI Head-End System”, e.g. Advanced Metering Infrastructure Head-End System. The Head-End system 110 may function as a central processing system that transmits and / or receives data, streams of data, data packets and / or messages from nodes 105a - 105h of the network 100, as described in more detail below. The head-end system 110 may generate and / or process the data. In examples, the head-end system 110 may be communicably coupled to a further system, such as a cloud based system (not shown), for generating and / or processing the data.

[0048] The head-end system 110 may, for example, be configured to acquire meter module data and to monitor parameters that may be acquired from meter modules. The headend system 110 may, for example, be configured to manage connectivity and scheduling of collection of data from metering modules. The head-end system may also be configured to control / enables secure access to meter modules for configuration and software updates.

[0049] The example network 100 of Figure 1 may comprise a root node 115. The root node 115 of the network 100 may be configured for communicating with the nodes 105a - 105h to perform operations such as retrieving data from the nodes 105a - 105h and / or transmitting data to the head-end system 110. In some examples, the root node 115 may also operate as a node similar to other nodes 105a - 105h. In examples, the root node 115 may comprise a gateway device. The root node 115 may be configured to transmit and receive data to / from the head-end system 110 via backhaul 120, such as the Internet, an intranet, or any other data communication network. It will be understood that the root node 115 is optional, and may not be present or required in all implementations. For example, in the case of unicast transmission, the head-end system 110 may transmit data packets to nodes (acting as end devices) directly.

[0050] Although only a single root node 115 is depicted for illustrative purposes, it will be understood that the mesh network 100 may comprise more than one root node 115.Similarly, the depicted network 100 comprises multiple nodes 105a-105h. Each node 105a-105h may be an end-node. For purposes of example, only nodes 105a-105h are depicted, but it will be understood that substantially more than eight nodes may be implemented.

[0051] In examples, each node 105a - 105h may comprise a device for metering and / or controlling a resource.

[0052] In examples, each node 105a - 105h may comprise a metering system comprising a communication module communicatively coupled to at least one meter module and configured to communicate with the head-end system.

[0053] In some examples, each meter module in a metering system may be configured to effectively operate as an end node, e.g. one or more of example nodes 105a - 105h may be a meter module in a metering system.

[0054] In such examples, each meter module may comprise circuitry and / or components for metering a consumption of a resource, e.g. electricity, and / or controlling access to the resource, such as by a service disconnect switch or the like. In an example, the network 100 may be associated with a utility network. In such an example, the nodes 105a -105h may comprise circuitry and / or components for metering the resource, for determining various operating characteristics of the utility network, and / or for transmitting collected data through the mesh network 100 to the head-end system 110 via the root node 115.

[0055] The nodes 105a - 105h forming the network 100 may be effectively provided in layers, as annotated in Figure 1 . In this example, the root node 115 forms layer 0. Nodes 105a, 105b that are communicably coupled directly to the root node 115 form a first layer, “Layer 1”, of the network 100. Similarly, nodes 105c - 105e that are communicably coupled to the metering system network 100 through a “Layer 1” node form a second layer, “Layer 2”, of the metering system network 100. Similarly, nodes 105f - 105h that are communicably coupled to the mesh network 100 through a “Layer 2” node form a third layer, “Layer 3”, of the network 100. In an example, for data to propagate from the root node 115 to a Layer 3 of the network 100 would require three “hops” of the data.In the example mesh network 100 of Figure 1 , each node 105a-105h may be configured to implement a protocol stack to enable communication therebetween, e.g. a protocol stack implementing at least a transport layer and a network layer, as defined by the Open Systems Interconnection model (OSI model) or the Transmission Control Protocol / lnternet Protocol (TCP / IP) model.

[0056] As described herein, a system for distributing a software update to a plurality of nodes according to the present disclosure may comprise a computer system. Figure 2 schematically illustrates an example of such a system 200 according to the present disclosure. As shown in Figure 2, the system 200 comprises a processing device 202 (e.g. a central processing unit (CPU), or a processor) configured to carry out computer-readable instructions corresponding to methods and processes described herein, including for the generation of a software update distribution plan as described herein. The system 200 may comprise a non-transitory computer readable medium 204, and the instructions may be stored on the non-transitory computer readable medium. A non-transitory computer readable medium 204 can include any electronic, optical, magnetic, or other storage devices capable of providing a processor with computer readable instructions or other program code. Non-limiting examples of a computer readable medium include a magnetic disk, a memory chip, a ROM, a RAM, an ASIC, optical storage, magnetic tape or other magnetic storage, or any other medium from which a processing device can read instructions. The instructions may include processorspecific instructions generated by a compiler or an interpreter from code written in any suitable computer-programming language, including, for example, C, C++, C#, Visual Basic, Java, Python, Perl, JavaScript, and ActionScript.

[0057] The system 200 also comprises an input device 206, where e.g. a user may provide one or more constraints for the software update distribution plan, or other inputs to the system 200 via the input device 206. For example, the input device 206 may comprise one or more of a mouse, keyboard, keypad, tablet, touchscreen, etc. The system 200 may comprise a display device (e.g. a screen), not shown, on which a user interface may be displayed (e.g. a graphical user interface) to enable the user to input the constraints or other inputs using the input device 206.

[0058] The system 200 further comprises a communications device 208 such as an antenna and / or a radio to enable the system 200 to connect to the network 100. The communications device 208 can include any device or group of devices suitable forestablishing a wired or wireless data connection to one or more data networks, e.g. a transceiver device, such as a radio frequency (RF) transceiver, capable of transmitting and receiving RF communication from other nodes in the network (e.g. mesh network). The communications device 208 may comprise a network interface device. Non-limiting examples of a network interface device include an Ethernet network adapter, a modem, and / or the like. The processor 202 is able to communicate with processors of other devices (i.e. nodes) via the network using the communications device 208. Communications with the processors of other nodes may comprise, or take the form of, transmissions and / or requests as described herein. For example, the system 200 may also receive transmissions via the communications device 208. For example, the system 200 may send the software update to nodes in the network via the communications device 208. The requests described herein may comprise scheduled data packets to be transmitted.

[0059] As described herein, in at least some examples, the system 200 may be a head-end system as described herein.

[0060] Figure 3 depicts a flow diagram illustrating various examples of automation of software (e.g. firmware) distribution according to the present disclosure. Parts of the flow diagram are numbered for ease of reference, and the various processes illustrated in Figure 3 are described hereinbelow.

[0061] At 1 (Figure 3), a system (e.g. head-end system) user is presented with a user interface in which criteria can be input (e.g. selected) for generating a firmware distribution plan. As described herein, criteria may comprise a target impact, a software (e.g. firmware) version to which the nodes are to be updated, a type of firmware or node, a hardware model (e.g. for the node(s) to be updated), a geographical parameter (e.g. area, branch, office, city, district, building), activation time(s), excluded time period(s) or date(s), a transmission mode, etc. The criteria may be input using e.g. a user interface and / or via an input device 206 as illustrated in Figure 2.

[0062] At 2 (Figure 3), the input criteria are used to generate a firmware distribution plan dynamically.At 3a (Figure 3), device (node) groups are generated based at least partly e.g. on the metering location(s) (e.g. geographical area), the input activation date, any excluded dates / time periods, a target impact, and / or any of the other criteria.

[0063] At 3b (Figure 3), in at least some examples, a firmware distribution plan may require approval by the user, or another operator, before it can be scheduled for execution. In some examples, the user can modify the firmware distribution plan manually (e.g. through the user interface and / or input device 206) before execution. In some examples, modifications to the plan may not be allowed once execution has initiated. In some examples, some criteria may be changeable while others may not be changeable by the user.

[0064] As shown at 4, 5, and 5a (Figure 3), a firmware distribution plan may utilize a unicast and / or multicast distribution method. The distribution method may be set by a constraint input by the user, and / or the distribution method may be selected automatically and constrained by transmission capacity (e.g. of a collector (CR)), network communication bandwidth, and / or impact on the SLA. A distribution plan may generate multiple firmware distribution requests for execution. The SLA impact may be dependent on the area or office locations impacted and the time when the activations occur.

[0065] As shown at 6 (Figure 3), the devices (which may be nodes) that can be the target of distribution methods described herein can include smart meters, repeaters, collectors, and collector radios.

[0066] As shown at 7 (Figure 3), execution of the firmware distribution requests may produce results that will be accumulated at the request level. This may occur as the messages are processed from the network in response to the firmware updates.

[0067] As shown at 8 (Figure 3), the results at the request level may be rolled up to the distribution plan level.

[0068] As shown at 9 (Figure 3), some examples according to the present disclosure may comprise generating a report of the software update distribution plan, and / or of the results of the software update distribution, and outputting a report. For example, the distribution plan and the request level results may be combined to generate one or more output files, or reports.Figure 4 depicts a further flow diagram illustrating various examples of automation of software (e.g. firmware) distribution according to the present disclosure, including the inputs and outputs that may be provided according to the present invention. Parts of the flow diagram are numbered for ease of reference, and the various processes illustrated in Figure 4 are described hereinbelow.

[0069] At 1 (Figure 4), the process starts.

[0070] At 2 (Figure 4), the initial distribution plan (also called a firmware download plan) is created. Criteria (i.e. constraints) may be input by a user, and a software update distribution plan is generated. In some examples, different plans for unicast and multicast distribution, respectively, may be generated.

[0071] At 3 (Figure 4), in some examples, the generated plan may require approval (e.g. by a user). In some examples, the generated plan may be scheduled to begin at a particular time.

[0072] At 4 (Figure 4), the plan is executed (e.g. using a processor and a communications device as described herein).

[0073] As shown at 5 (Figure 4), in some examples, a redistribution plan may be created, e.g. to redistribute the software update to any devices that did not successfully download the software update during the original distribution. In some examples, a rollback plan may be created, e.g. to revert the software version on at least some devices to the earlier version (i.e. the version before the update distribution), for example in the event of an error or a failure caused by the update.

[0074] As shown at 6 (Figure 4), in some examples, the successful completion of the software update download may be confirmed, or verified In some cases, this step may involve sending commands to the network, e.g. a “Confirm registration” command to confirm the software version. This can occur where the firmware version update messages could be dropped.

[0075] As shown at 7 (Figure 4), in some examples a report of the distribution plan, and / or the results, may be generated and / or outputted.In some examples, generating the software update distribution plan may comprise determining a plurality of node groups, also referred to herein as “SLA units”. The node groups correspond to the quantity of nodes (e.g. smart meters) that can be potentially affected by the software (e.g. firmware) update process while maintaining the target SLA, which may be a fraction or percentage. For example:

[0076] SLA Unit quantity = (Total Number of SM assigned to the Office) * (Target SLA Percentage)

[0077] According to the present disclosure, for a newly created plan, the plan may be broken down into requests based on computed SLA units (node groups) per office. A command to execute the plan may be scheduled for a future point in time based on the information in the plan. In some examples according to the present disclosure, it may be determined whether the conditions are met for redistribution, and redistribution requests may be created for the selected locations such that SLA continues to be met. In some examples, for plans pending cancellation, a plan may be transitioned to a cancelled state and requests for cancellation may be sent at the request level to other services.

[0078] An example of a flow diagram corresponding to some of the decisions described above is depicted in Figure 5.

[0079] Figure 6 schematically illustrates a processing sequence for some examples of systems and methods according to the present disclosure in which a software update is distributed across a deployment having multiple metering locations (e.g. offices). As described herein, updates may be distributed to nodes at each location (office) in parallel, where one node group (SLA unit) is selected from each location for parallel execution of the plan. In the example illustrated in Figure 6, the node group (SLA unit) is defined as 5%, which corresponds to 10,000 smart meters per office. Redistribution requests are only performed after the completion of the initial software update distribution to all node groups within an office. Therefore, any nodes that are added to the deployment during the timespan of the initial distribution pass will receive the update via the redistribution passes. In the example illustrated in Figure 6, multiple offices are worked independently as separate initial or redistribution requests.In some examples, redistribution could be performed per node group, before moving on to the next metering location (office).

[0080] Once generated (e.g. after constraint selection), a distribution plan may encapsulate one or more distribution methods that can be made configurable. Figure 7 schematically illustrates examples of plan variations according to different distribution methods (transmission modes) available (i.e. multicast or unicast). It will be understood that the boxes labelled “multicast” and “unicast” in Figure 7 may correspond, in some examples, to multiple requests that could each be batched and executed concurrently.

[0081] As shown at 1 (Figure 7), multiple control operations may be supported to control the distribution plan. The control operations can include: “Approve the plan for execution”; “Execute the plan immediately”; and / or “Terminate the execution of the plan”.

[0082] As shown at 2 (Figure 7), multiple distribution requests could occur for a given plan.

[0083] As shown at 3 (Figure 7), the number of unicast firmware download attempts for a given distribution plan can be made a configurable parameter.

[0084] As shown at 4 (Figure 7), multiple multicast distributions may occur in case of a poor update success rate, and / or in case the threshold conditions for multicast are met.

[0085] As shown at 5 (Figure 7), some plans may be generated that use only the unicast distribution method.

[0086] As shown at 6 (Figure 7), some plans may be generated that use only the multicast distribution method. There may be some cases where unicast transmissions would not be required.

[0087] As shown at 7 (Figure 7), the requests of the plan may execute in sequence along a time scale. In some examples, a subsequent request (which may or may not be transmitted according to a different distribution method to the preceding request, as described herein) may be directed to devices that were not updated in the previous request.

[0088] As described herein, software distribution plan creation may result in multiple requests being created dynamically. A request may be an existing system abstraction created forsupporting multicast and unicast downloads. The requests may encapsulate a firmware download execution unit which would contain a dynamically generated group of nodes (e.g. collectors (CR) or smart meters (SM)) as shown schematically in Figure 8.

[0089] Figure 9 schematically illustrates an example of a user interface that may be provided in some examples according to the present disclosure for the provision of constraints as described herein. In some examples, the user interface illustrated in Figure 9 may be displayed on a display device of the system 200 illustrated in Figure 2 and described herein. As shown in Figure 9, various constraints may be input by the user (e.g. using an input device 206 as illustrated in Figure 2 and described herein). For example, devices of particular models may be selected, along with a target software (e.g. firmware) version, the location, the SLA impact per location, the desired activation time for the plan, any excluded dates or times (including, as shown in Figure 9, the option to exclude or include weekends), any node groups (which may be smart meters associated with particular collectors) to exclude, and a scheduled execution date or time. It will be understood that the constraints described and illustrated herein are merely examples. More or fewer constraints may be provided in some examples.

[0090] In some examples, the user interface may be accessed via a network, e.g. via the world wide web, such that the user interacts with the system 200 described herein using another computer or device (e.g. mobile device) that is remote from the system.

[0091] Figure 10 illustrates an example of a method 1000 for distributing a software update to a plurality of nodes in a network according to the present disclosure. As described herein, the plurality of nodes may be distributed among one or more metering locations.

[0092] At S1002, the method 1000 comprises receiving one or more constraints. For example, the one or more constraints may be received from a user via e.g. an input device 206 as illustrated in Figure 2. In some examples, as described herein, the one or more constraints may be provided using a user interface, such as the example user interface illustrated in Figure 9, which may be displayed on a display device of a system such as the system 200 illustrated in Figure 2, and / or on a remote device as described herein. As described herein, the one or more constraints may correspond to a targeted software update for the plurality of nodes.At S1004, the method 1000 comprises generating a software update distribution plan for the plurality of nodes based on the one or more constraints. For example, the software update distribution plan may be generated by the processing device 202 illustrated in Figure 2. As described herein, the software update distribution plan may comprise a plurality of requests.

[0093] At S1006, the method 1000 comprises sending the software update to each node of the plurality of nodes. For example, the software update may be sent using a communications device 208 as illustrated in Figure 2 and described herein. As described herein, the software update may be sent as a plurality of requests.

[0094] It will be understood that, in general, the methods, sequences, and processes described herein and illustrated in Figures 3, 4, 5, 6, 7, 8, and 10 may correspond to algorithms that are stored as computer-readable instructions (e.g. software) in a memory of a system such as a head-end system, and said computer-readable instructions may be executed by a processor such as the processing device 202 of the system 200 illustrated in Figure 2 (e.g. a processor of a head-end system).

[0095] Although the disclosure has been described in terms of preferred embodiments as set forth above, it should be understood that these embodiments are illustrative only and that the claims are not limited to those embodiments. Those skilled in the art will be able to make modifications and alternatives in view of the disclosure, which are contemplated as falling within the scope of the appended claims. Each feature disclosed or illustrated in the present specification may be incorporated in any embodiments, whether alone or in any appropriate combination with any other feature disclosed or illustrated herein.

Claims

CLAIMS:1 . A system for distributing a software update to a plurality of nodes in a network, the plurality of nodes being distributed among one or more metering locations, the system comprising:an input device configured to receive one or more constraints, the one or more constraints corresponding to a targeted software update for the plurality of nodes;a processing device configured to generate a software update distribution plan for the plurality of nodes based on the one or more constraints, the software update distribution plan comprising a plurality of requests; anda communications device, wherein the system is configured to send, via the communications device, the software update to each node of the plurality of nodes according to the software update distribution plan via the plurality of requests.

2. A system according to claim 1 , wherein the one or more constraints comprise a target impact, the target impact being a maximum reduction in metering data transfers by the nodes at each of the one or more metering locations.

3. A system according to claim 1 or 2,wherein generating the software update distribution plan comprises determining a plurality of node groups for each metering location; and wherein sending the software update according to the software update distribution plan comprises sending a first distribution request to one node group at each metering location at a time.

4. A system according to claim 3, wherein the system is configured to send the first distribution request to node groups in multiple metering locations in parallel.

5. A system according to claim 3 or 4, wherein the software update distribution plan comprises one or more redistribution requests, and wherein the system is configured to resend the software update via the communications device to at least a subset of the node groups at a metering location, via the one or more redistribution requests, after sending the first distribution request to all node groups at the metering location.

6. A system according to claim 5, wherein the software update distribution plan is configured to terminate after a predetermined number of redistribution requests.

7. A system according to claim 6, wherein the one or more constraints comprise the predetermined number of redistribution requests.

8. A system according to any one of the preceding claims, wherein generating the software update distribution plan comprises determining a transmission mode for each request.

9. A system according to any one of claims 1 to 7, wherein the one or more constraints comprise a transmission mode.

10. A system according to claim 5, wherein generating the software distribution plan comprises determining a first transmission mode for the first distribution request, and a second transmission mode for at least one of the redistribution requests, the second transmission mode being different from the first transmission mode.

11. A system according to claim 10, wherein generating the software distribution plan comprises determining a transmission mode for a first redistribution request after the first distribution request according to a success rate of the first distribution request.

12. A system according to any one of the preceding claims, wherein the one or more constraints comprise an activation time.

13. A system according to any one of the preceding claims, wherein the one or more constraints comprise one or more excluded time periods.

14. A system according to any one of the preceding claims, wherein the one or more constraints comprise an excluded group of nodes.

15. A system according to any one of the preceding claims, wherein the software update is a firmware update.

16. A method for distributing a software update to a plurality of nodes in a network, the plurality of nodes being distributed among one or more metering locations, the method comprising:receiving one or more constraints, the one or more constraints corresponding to a targeted software update for the plurality of nodes;generating a software update distribution plan for the plurality of nodes based on the one or more constraints, the software update distribution plan comprising a plurality of requests; andsending the software update to each node of the plurality of nodes according to the software update distribution plan via the plurality of requests.

17. A method according to claim 16, wherein the one or more constraints comprise a target impact, the target impact being a maximum reduction in metering data transfers by the nodes at each of the one or more metering locations.

18. A method according to claim 16 or 17,wherein generating the software update distribution plan comprises determining a plurality of node groups for each metering location; and wherein sending the software update according to the software update distribution plan comprises sending a first distribution request to one node group at each metering location at a time.

19. A method according to claim 18, comprising sending the first distribution request to node groups in multiple metering locations in parallel.

20. A method according to claim 18 or 19, wherein the software update distribution plan comprises one or more redistribution requests, and wherein the method comprises resending the software update to at least a subset of the node groups at a metering location, via the one or more redistribution requests, after sending the first distribution request to all node groups at the metering location.

21. A method according to claim 20, comprising terminating the software update distribution plan after a predetermined number of redistribution requests.

22. A method according to claim 21 , wherein the one or more constraints comprise the predetermined number of redistribution requests.

23. A method according to any one of claims 16 to 22, wherein generating the software update distribution plan comprises determining a transmission mode for each request.

24. A method according to any one of claims 16 to 22, wherein the one or more constraints comprise a transmission mode.

25. A method according to claim 20, wherein generating the software distribution plan comprises determining a first transmission mode for the first distribution request, and a second transmission mode for at least one of the redistribution requests, the second transmission mode being different from the first transmission mode.

26. A method according to claim 25, wherein generating the software distribution plan comprises determining a transmission mode for a first redistribution request after the first distribution request according to a success rate of the first distribution request.

27. A method according to any one of claims 16 to 26, wherein the one or more constraints comprise an activation time.

28. A method according to any one of claims 16 to 27, wherein the one or more constraints comprise one or more excluded time periods.

29. A method according to any one of claims 16 to 28, wherein the one or more constraints comprise an excluded group of nodes.

30. A method according to any one of claims 16 to 29, wherein the software update is a firmware update.

Images