US20070169075A1 - Synchronizing and controlling software downloads, such as for utility meter-reading data collection and processing - Google Patents

Synchronizing and controlling software downloads, such as for utility meter-reading data collection and processing Download PDF

Info

Publication number
US20070169075A1
US20070169075A1 US10/570,779 US57077903A US2007169075A1 US 20070169075 A1 US20070169075 A1 US 20070169075A1 US 57077903 A US57077903 A US 57077903A US 2007169075 A1 US2007169075 A1 US 2007169075A1
Authority
US
United States
Prior art keywords
software
data collection
ccu
download
utility
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/570,779
Inventor
David Lill
Eric Benson
James Jespersen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Itron Inc
Original Assignee
Itron Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Itron Inc filed Critical Itron Inc
Assigned to ITRON, INC. reassignment ITRON, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LILL, DAVID, BENSON, ERIC, JESPERSEN, JAMES
Publication of US20070169075A1 publication Critical patent/US20070169075A1/en
Assigned to WELLS FARGO BANK, NATIONAL ASSOCIATION reassignment WELLS FARGO BANK, NATIONAL ASSOCIATION SECURITY AGREEMENT Assignors: ITRON, INC.
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • G06F11/1433Saving, restoring, recovering or retrying at system level during software upgrading
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163Interprocessor communication
    • G06F15/173Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/61Installation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates

Definitions

  • ______ (attorney docket no. 1725.156US01), filed Sep. 5, 2003, entitled “Synchronous Data Recovery System,” U.S. patent application Ser. No. ______ (attorney docket no. 1725.161US01), filed Sep. 5, 2003, entitled “Data Communication Protocol in an Automatic Meter Reading System,” U.S. patent application Ser. No. ______ (attorney docket no. 1725.167US01), filed Sep. 5, 2003, entitled “Response Optimization for Mobile and Fixed Network Operations,” and U.S. patent application Ser. No. ______ (attorney docket no. 10145-8012.US00), filed on Sep. 5, 2003, entitled “Field Data Collection and Processing System, such as for Electric, Gas, and Water Utility Data,” which are herein incorporated by reference.
  • Utility users and utility providers typically monitor utility use by collecting data from one or more utility meters at users' premises.
  • meters equipped with transmitters such as radio-based transmitter modules, transmit meter-reading data locally to a data collection device (“CCU”). So that the collected data may be processed in a meaningful way, the CCU may periodically upload data to one or more host or “head-end” processors via a communication link, such as a wide-area network (WAN) or the Internet.
  • WAN wide-area network
  • software applications at both the CCU and the head-end are implemented to manage the CCU's data collection, to the control the transmission of data between the CCU and the head-end, and to facilitate downloading of schedules and other applications to the CCU. Accordingly, software updates at the head-end and/or the CCU may be implemented to ensure that the meter-reading system stays updated or to expand the meter-reading system.
  • CCUs are configured to download software from the head-end via a network link. Using this technique, system administrators avoid having to physically access each field collection device to perform a software update.
  • a CCU that is downloading software from the head-end may have to interrupt some or all of its data collection and transmission functionality. Because CCUs typically collect and transmit data on an ongoing or frequent periodic basis, interrupting a CCU's data collection and transmission functionality can be problematic, especially when large software updates can take several hours to download.
  • FIG. 1 is a block diagram showing an example of a system on which the software download technique of one embodiment.
  • FIG. 2 is a block diagram showing an example of a software download facility operating in the data collection system of FIG. 1 .
  • FIG. 3 is a state diagram showing some examples of high-level CCU states, as controlled by the state machine of FIG. 2 in one embodiment.
  • FIG. 4 is an example of a stored procedure or routine that, when executed at the state machine of FIG. 2 , places a subject CCU in a download pending state.
  • FIG. 5 is a flow chart showing an example of a system-level software download process in the software-download facility of FIG. 2 .
  • FIG. 6 is a flow chart showing an example of a software download routine in the CCU of FIG. 2 .
  • FIG. 7 is flow chart illustrating an example of a software download routine in the head-end of FIG. 2 .
  • FIG. 8 is an example of a system-level software take effect process in the software-download facility of FIG. 2 .
  • FIG. 9 is an example of a system-level software cancel process in the software-download facility of FIG. 2 .
  • FIG. 10 is an example of a system-level software rollback process in the software-download facility of FIG. 2 .
  • FIG. 11 is an example of a CCU discovery process in the software-download facility of FIG. 2 .
  • FIG. 12 is an example of a routine in the software download facility of FIG. 2 for adding a CCU to a group of CCUs.
  • a software download system described in detail below provides a facility for upgrading/reloading distributed embedded data collection devices, such as cell control units (“CCUs”), in the field without having an operator physically visit the CCUs.
  • the software download system may be implemented over a communication network such as the Internet, a wide-area network (WAN), a local area network (LAN), a cellular network, etc., using well-known protocols and technologies such as HTTP, HTTPS, Wget, Active Server Pages (ASP), etc.
  • the software download system may provide for upgrade and installation of both operating system and application-type components with minimal staging or preparation.
  • the software download system may also facilitate recovery from a “dead box” scenario where a CCU is not working (e.g., due to a corrupted Flash file system) without a service call to the CCU.
  • the software download system may facilitate efficient use of a system's existing available bandwidth.
  • a CCU in the software download system may be configured to store more than one version of software.
  • the CCU may store a current version, a previous version, and a next version.
  • the CCU may be in one of a variety of states (e.g., “download pending,” “download accepted,” “downloaded,” “takeeffect pending,” “takeeffect accepted,” etc.).
  • the state of the CCU may have an effect on how the CCU behaves given a command from the head-end.
  • the software download system may also provide grouping and audit capabilities. These capabilities may be used, for example, to monitor versions running at the CCU and the state of any scheduled downloads.
  • the software download system may incorporate techniques to minimize interruption to data transmission functionality of the CCU during the software download process. For example, the software download system may facilitate intelligent sharing of a transport link to minimize interference with a scheduled push of consumption data (e.g., collected meter reading data) to the head-end.
  • consumption data e.g., collected meter reading data
  • FIG. 1 and the following discussion provide a brief, general description of a suitable computing environment in which the invention can be implemented.
  • aspects of the invention are described in the general context of computer-executable instructions, such as routines executed by a general-purpose computer, e.g., a server computer, wireless device or personal computer.
  • a general-purpose computer e.g., a server computer, wireless device or personal computer.
  • PDAs personal digital assistants
  • wearable computers all manner of cellular or mobile phones, multi-processor systems, microprocessor-based or programmable consumer electronics, set-top boxes, network PCs, mini-computers, mainframe computers and the like.
  • ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇
  • aspects of the invention may be stored or distributed on computer-readable media, including magnetically or optically readable computer discs, as microcode on semiconductor memory, nanotechnology memory, or other portable data storage medium.
  • computer implemented instructions, data structures, screen displays, and other data under aspects of the invention may be distributed over the Internet or over other networks (including wireless networks), on a propagated signal on a propagation medium (e.g., an electromagnetic wave(s), a sound wave, etc.) over a period of time, or may be provided on any analog or digital network (packet switched, circuit switched or other scheme).
  • a propagation medium e.g., an electromagnetic wave(s), a sound wave, etc.
  • packet switched, circuit switched or other scheme any analog or digital network
  • a suitable system 100 on which the software download techniques may be implemented includes a meter-reading data collection system having multiple meters 102 coupled to utility-consuming devices (not shown), such as electric, gas, or water consuming devices.
  • each meter 102 includes an encoder receiver/transmitter module (ERT) 104 , which serves as a data collection endpoint.
  • the ERTs 104 encode consumption, tamper information, and other data from the meters 102 and communicate such information to a CCU 108 .
  • the communication of this data may be accomplished via radio-to-radio data collection systems such as handheld, mobile automatic meter reading or fixed network.
  • the ERTs 104 can be retrofitted to existing meters or installed on new meters during the manufacturing process.
  • the ERTs 104 may be installed under the glass of new or existing electric meters 104 and are powered by electricity running to the meter. Gas and water ERTs 104 can be attached to the meter 102 and powered by long-life batteries.
  • a group of ERTs 106 communicates with one of the CCU devices 108 , which in turn feeds collected data to a head-end system 110 via periodic uploads. This may occur on an ongoing basis (e.g., every half-hour) or as otherwise needed.
  • the CCUs 108 may be implemented as neighborhood concentrators that read the ERT meter modules 104 , process data into a variety of applications, store data temporarily, and transport data to the head-end 110 as needed.
  • the CCUs 108 can be installed on power poles or street light arms (not shown).
  • a software download facility 200 operating in the data collection system 100 of FIG. 1 is configured to allow multiple versions of a software package to persist on a CCU 108 at any given time—allowing for more robust capabilities of the CCU 108 during download and providing a safety net should a need arise to revert to a previous software version.
  • a previous version, a current version and a next version of software can concurrently exist on the CCU 108 .
  • multiple outstanding versions may be used, while in other embodiments, multiple versions may not be allowed.
  • the new version can be configured to contain the full set of components needed for the upgrade.
  • the CCU 108 checks its current stored outstanding version and only downloads components that it needs. The CCU 108 may also delete any stored software components that are not a part of the newer version.
  • the software download facility 200 includes components that reside on one or more platforms (not shown) at both the CCU 108 and the head-end 110 .
  • the platform at the CCU 108 does not need to be the same as the platform at the head-end 110 .
  • the CCU 108 may have a Linux based platform and the head-end 110 may have a Windows 2000 Server platform. Additionally, subcomponents within the system may each operate on independent platforms.
  • the software download facility 200 in the illustrated embodiment provides for updating CCU software stored in a file system 202 at the CCU 108 and for recovering from a catastrophic software failure without requiring a service call to the CCU or a return of the CCU to a repair depot. In some embodiments, it is possible to store a copy of the current package set in a protected partition (not shown) of the CCU file system 202 to facilitate rapid recovery from accidental or malicious corruption of a current software version.
  • transport mechanisms of the software download facility may support transfer checkpoint/restarts.
  • Application layer protocols such as HTTP, HTTPS, WAP, SMTP, FTP, etc., may be utilized in the transfer of data.
  • data transferred across the communication link 204 may be compressed using known compression techniques such as Gzip library functions.
  • a request message from the CCU may include outstanding ACK/NAK responses from the CCU 108
  • a response message from the head-end 110 may include optional CCU commands (“take effect,” “cancel,” etc.).
  • the CCU 108 may respond synchronously to the response message by returning another request message with a command response packet appended to it.
  • the appended command response packet may contain a configuration response ACK and an optional command response ACK/NAK, depending on whether the command message that the CCU received was from the head-end. This and similar message exchanges can occur during a single session and conversation or in multiple sessions.
  • the CCU 108 initiates all request/response message exchanges, meaning the head-end 110 does not send any unsolicited messages to the CCU.
  • the CCU 108 may include a two-stage loader ( 206 and 208 ) so that it can load software in such a way to help prevent catastrophic loss of software.
  • the first stage loader 206 exists in ROM and is capable of downloading the second stage loader 208 onto the file system 202 .
  • the second stage loader 208 may then download operating system features and application software components (not shown) onto the file system 202 .
  • the second stage loader 208 of the illustrated embodiment is responsible for ensuring that all the needed software components exist and are not corrupt.
  • the second stage loader 208 may function to inform the head-end 110 of the current software component versions and of the current state of a software upgrade in progress.
  • the second stage loader 208 may also handle downloading new software component versions and installation and rollback of software component versions.
  • Downloading of software data packages may be handled asynchronously at the CCU 108 , in part, by a GNU (“GNU's not Unix”) utility known as Wget 210 . While Wget is utilized in the illustrated embodiment, other utilities or systems could be used to provide similar functionality, such as FTP, HTTPGet, remote file copy, web server, etc.
  • the CCU software download process 212 can invoke the Wget utility 210 as needed.
  • the Wget utility 210 interacts with downloaded applications stored in the file system 202 of the CCU, so that the CCU 108 can receive and store requested files.
  • the Wget utility 210 may include a transport mechanism for the Wget utility 210 that runs over HTTP (or HTTPS) and, in some embodiments, supports file checkpoint/restart through a “range” feature to aid in recovery in case of a disconnected communication link 204 .
  • the Wget utility 210 works by requesting a transfer of data pointed to by a URL.
  • the CCU 108 may be able to build such URLs dynamically based on configuration information and data contained within a message sent by the head-end 110 to the CCU in response to a software download request message. Accordingly, the CCU 108 may be configured so that it knows its own software download server name and an appropriate top level head-end virtual directory, such as an Internet Information Services (IIS) directory.
  • IIS Internet Information Services
  • the CCU software download process 212 may be responsible for providing an interface with the Wget utility 210 , which is used for the actual download of software packages as described above.
  • the CCU download process 212 may also be responsible for maintaining download status information until the information has been forwarded to the head-end 110 .
  • the CCU download process 212 is also used to verify the correctness of the current version and to re-download missing or corrupt components, save current software versions, verify a new software version prior to installation, and install the new version at a scheduled “take effect” time.
  • the CCU download process 212 may also be responsible for sending shutdown requests to other processes such as a data collection application (not shown) so that those processes can persist data and state information and perform an orderly shutdown. In some embodiments, the CCU software download process 212 may wait for the other processes to end prior to shutting down the CCU 108 completely. The CCU software download process 212 can monitor the shutdown process and generate a hard kill of a process that does not respond to the requested shutdown.
  • the CCU software download process 212 facilitates a “rollback” to a previous version of software stored in the CCU file system 202 .
  • the installation of a new version is handled as an autonomous operation so that if a subsequent update or rollback is not successfully completed, the CCU 108 reverts to a state it was in prior to attempting the update/rollback.
  • the CCU software download process 212 may avoid message exchanges with the head-end 110 until completion of the operation to insure that any software download configuration information received at the head-end 110 does not contain partial configuration information.
  • the head-end processor 110 which includes a database 214 for storing persistent information, supports several components of the software download facility 200 .
  • the head-end 110 may provide device grouping, version control and tracking functionality for the management of software download processes via a head-end software download command processor, which is implemented as a state machine 216 in some embodiments.
  • a state machine 216 in some embodiments.
  • standard hierarchy-based, procedural, or object-oriented coding practices may implement the software download processor instead of the state machine.
  • the state machine 216 can exist in the database 214 and may be implemented using stored procedures and triggers stored in the database 214 at the head-end 110 or may be implemented using components stored on the file system 218 at the head-end 110
  • the head-end 110 is not responsible for packaging, building, releasing, and verifying of CCU software packages
  • the head-end 110 may facilitate these tasks.
  • CCU software application, operating system, etc.
  • RPM Remote Package Manager
  • each set of packages corresponds to a version of the software and constitutes the bill of materials (BOM) for that version.
  • BOM bill of materials
  • the file system 218 at the head-end 110 stores applications (not shown) that may facilitate the transfer of software packages.
  • An Internet Information Service (IIS) component 220 may interact with the file system 218 to download files (e.g., RPM files) from virtual directories via the communication link 204 .
  • An Active Server Page (ASP) component 222 in the IIS component 220 may be responsible for processing binary data and storing it in an appropriate “To Process” database tables for further processing.
  • ASP Active Server Page
  • when the ASP component 222 receives a binary message from the CCU 108 it can use Gzip to verify that the message has arrived intact. It then unzips the message, parses it, and stores the parsed message in appropriate data tables.
  • the ASP component 222 may then invoke a stored procedure (not shown) that will invoke the state machine 216 .
  • the state machine 216 in turn returns a response to the ASP component 222 .
  • the ASP component can then Gzip the response and forward it back to the CCU 108 .
  • the ASP component 222 may hold an HTTPS session (or other type session) open until the CCU 108 acknowledges receipt of the sent response packet.
  • IIS and Wget can provide the appropriate interaction for the transport of packages, implementation at the head-end may not be needed to handle downloading of software packages.
  • the state of a CCU (e.g., CCU 108 of FIGS. 1 and 2 ), as determined by a CCU decision processor or state machine (e.g., state machine 216 of FIG. 2 ), may be used in controlling the software download process, and other related processes.
  • the state machine 216 may control a download state of any CCU that is in communication with the state machine.
  • each state handles self-transitions that may occur if the state machine 216 receives configuration requests or duplicate command response events while waiting for the events that cause a state transition. In such cases, the state machine 216 may rebuild the correct response message, return it to the ASP component 222 , and remain in the current state.
  • the state machine 216 may also be responsible for updating the head-end database 214 with the status of scheduled software downloads from information received from the CCUs 108 .
  • the state machine 216 may use information stored in the database to control downloads of new CCU software components to selected CCUs or groups of CCUs.
  • FIG. 3 is a state diagram 300 showing some examples of high-level CCU superstates (“states”), as controlled by the state machine in one embodiment. These superstates may be associated with various lower level states (as shown in Table 1) that may inherit from, or otherwise relate back to, the superstates.
  • the illustrated states include a discovery state 301 , an update state 302 , a stable state 303 , a rollback state 304 , a cancel state 305 and a rejected state 306 .
  • Each state can be triggered by some event.
  • the rejected state 306 can be triggered by a failed software update or software rollback.
  • the discovery state 301 is invoked for a CCU when the CCU is first incorporated or reincorporated into the system.
  • the state machine invokes the discovery state 301 for the CCU when the head-end receives a command from a CCU that has a global uniform identifier (GUID) equal to zero or not equal to some default (meaning that the CCU is not known to the system).
  • GUID global uniform identifier
  • the CCU may be assigned a default software version (initialization). Once this occurs, the state machine may change the CCU's state to the update state 302 so that a software update can be initiated via processing that occurs at both the head-end and the CCU.
  • the state of the CCU may proceed to the stable state 303 , the cancel state 305 or the rejected state 306 .
  • the CCU's state may change from the update state 302 to the stable state 303 if the invoked software update is successfully completed. If, however, the invoked software update fails, then the state may change from the update state 302 to the rejected state 306 .
  • the state may change from the update state 302 to the cancel state 305 .
  • the CCU's state may go back to the update state 302 or may proceed to the rollback state 304 .
  • the state changes from the stable state 303 to the rollback state 304 if a rollback request is implemented.
  • the state can change back to the stable state 303 if the rollback is successfully completed. If the rollback fails, the state can change to the rejected state 306 . If an administrator cancels a rollback, the state may change back to the cancel 305 state.
  • the state can change to the update state 302 , the rollback state 304 or the stable state 303 , depending on the nature of the rejection. For example, in the case of a failed software update, the update state 302 may be resumed so that the software update can be reattempted.
  • CCU states Some more detailed examples of CCU states, including those discussed with respect to FIG. 3 , are shown in Table 1 below.
  • Table 1 includes a reference to “Process to Execute.” Such processes may stored procedures that reside in the database 214 as described with respect to FIG. 2 , or could be other programs.
  • the software download facility 200 may provide functionality and corresponding interfaces that allow administrative users to manage the software running on the system's CCUs 108 .
  • this functionality and any corresponding user interfaces may be implemented in part, via stored procedures at the state machine.
  • administrative users may be able to perform operations to set a CCU 108 into a download pending state so that the state machine 216 will send a download command to the CCU the next time the CCU communicates with the head-end.
  • FIG. 4 is an example of a state machine stored procedure or routine 400 that, when executed, places a subject CCU in the download pending state.
  • the routine begins at block 401 where the routine logs a state change request made by the administrative user. Because moving into the download pending state may not be possible if a CCU is currently in a state other than stable or rejected (e.g., the stable 303 or rejected 306 states of FIG. 3 ), in decision block 402 the routine checks the current state of the subject CCU. If the subject CCU is not in a stable or rejected state, the routine logs an error at block 405 and then ends. Otherwise, if at decision block 402 the subject CCU is in a stable or rejected state, the routine continues at decision block 403 where the routine checks to see if the administrator's request is valid (e.g., if there is an existing software upgrade available for that particular CCU).
  • the routine checks to see if the administrator's request is valid (e.g., if there is an existing software upgrade available for that particular CCU).
  • routine logs an error at block 405 and then ends. If, however, at decision block 403 the administrator's request is valid, the routine proceeds to block 404 , where the state of the subject CCU is updated to the download pending state. The routine then ends.
  • the CCU can send a configuration request to the head-end to initiate a software download.
  • the CCU may initiate a configuration request communication, for example, when the CCU reboots or determines that its current software is corrupted or during any scheduled communications window in which a software download bit is set for the window.
  • a software download process 500 permits a CCU to download software from a head-end system.
  • a software download process running at the CCU such as the software download process component 212 of FIG. 2 , is responsible for initiating communications with the head-end.
  • new software components are installed at the head-end.
  • an administrator schedules a CCU to download a software update.
  • the scheduled CCU sends out a configuration request to the head-end. This may include posting a message to a configuration request ASP page.
  • the configuration request message may also include appended software command responses (ACKs/NAKs).
  • the head-end replies to the configuration request message by sending a software configuration data back to the CCU, including software download commands and/or a new software BOM that contains all the information needed by the CCU to verify the validity of the current installed version.
  • the CCU downloads the software components to its file system.
  • the CCU sends an operation status message to the head-end. This may occur at some point during the download and may include posting a configuration response message to a configuration response ASP page. While not shown, the head-end may reply to the configuration response message via an HTTP reply.
  • the head-end receives a command response message from the CCU.
  • the command response message may indicate whether the download was successful.
  • decision block 508 if the download was successful the routine continues at decision block 509 . However, if at block 508 the download was not successful, the process continues at decision block 511 where the head-end checks if a timeout count for the download was exceeded. If at decision block 511 the timeout count was exceeded, the process continues at block 512 where the head-end system marks the scheduled download as “failed” and then ends. Otherwise, if at decision block 511 the timeout count is not exceeded, the process loops back to block 503 and repeats the process for the same CCU.
  • the routine continues at decision block 509 where the head-end checks if all scheduled CCUs in the group have completed the download. While the downloading of the CCUs in the group may be occurring in parallel, because responses from CCUs may be sent at different times, the routine repeats itself each time a new configuration response is received at the head-end. Accordingly, if at decision block 509 all scheduled CCUs have not been downloaded, the routine loops back to block 503 . Otherwise, if at decision block 509 all scheduled CCUs have been downloaded, the process continues at block 510 where the head-end marks the scheduled download as “complete” for all scheduled CCUs in the group. The process then ends.
  • FIG. 6 is a flow chart showing an example of a routine 600 that occurs at the CCU during the software download process of FIG. 5 (see i.e., block 505 of FIG. 5 ).
  • the CCU sends a configuration message to the head-end.
  • the routine receives a software configuration response message from the head-end, which includes any additional download commands (take-effect time, cancel, etc.).
  • the CCU's software download process may be responsible for processing the software configuration response along with any additional software download commands received from the head-end.
  • decision block 603 the routine checks to see if the download is possible. If the download is not possible, the routine sends a “failed” command response message to the head-end (block 613 ) before ending. Otherwise, if at decision block 603 the download is possible, the routine continues at block 604 where the routine sends a “success” command response message to the head-end.
  • the routine determines if new RPM packages need to be downloaded. In decision block 606 if new software versions are needed, the routine continues at block 607 . Otherwise, the routine ends. At block 607 the routine invokes the Wget utility to download and store the appropriate software versions. At block 608 the routine monitors Wget for download statuses (complete, failed, etc.).
  • decision block 609 if the download is unsuccessful, the routine continues at block 614 where the routine sends a “failed” command response to the head-end before ending. Otherwise, at decision block 609 if the download is successful, the routine continues at block 610 where the new version of the software is validated. In decision block 611 if the validation is not successful, the routine continues at block 614 where the routine sends a “failed” command response to the head-end before ending. Otherwise, if at decision block 611 the validation is successful, the routine continues at block 612 where the routine sends a “success” command response message to the head-end before ending.
  • a software download routine 700 is called by an ASP component, such as the ASP component 222 of FIG. 2 , after the configuration request message has been received, parsed and stored in a “ToProcess” table at the head-end database.
  • the routine invokes the head-end state machine for state determinations.
  • the routine retrieves a configuration request message from the ToProcess table.
  • the routine gets the current state via the state machine. The state machine achieves this by querying one or more head-end database tables for software configuration data. The state machine then forwards this information along with any required software download command messages back to the ASP component.
  • decision block 703 if a state does not exist, the state is set to zero by default (block 704 ) before continuing at block 707 . Otherwise, if a state does exist at block 703 the routine proceeds to decision block 705 where the routine checks to see if the state is stable. If the state is not stable, the routine proceeds to block 707 . Otherwise, if at decision block 705 the state is stable, the routine continues at block 706 where the routine checks to see if the globally unique identifier (GUID) of the configuration request is equal to zero.
  • GUID globally unique identifier
  • the routine If the GUID of the configuration request is equal to zero, the state is also set to zero at block 704 . Otherwise, if at decision block 706 the GUID is not equal to zero, the routine continues at block 707 . At block 707 the routine gets the next state context stored procedure to be called. At block 708 if the state context stored procedure does not exist, the routine logs an error (block 711 ) and builds a corresponding message (block 712 ) before ending. Otherwise, if at decision block 708 , the state stored procedure exists, the routine continues at block 709 , where the routine invokes the state context stored procedure. At decision block 710 if additional configuration request commands are waiting in the ToProcess table, the routine loops back to block 701 . Otherwise, the routine builds the appropriate log message (block 712 ) and then ends.
  • a take effect process 800 involves creating a schedule with a take effect time for one or more CCUs.
  • the take effect process 800 begins at block 801 where an administrative user invokes a stored procedure that provides the interface needed to set a take effect time for the desired CCUs next software version.
  • the CCU may be set to the take effect pending state so that a take effect command will be sent to the CCU the next time the CCU communicates with the head-end.
  • the take effect time may be saved and the head-end may send the take effect command to the CCU upon notification that the software download operation has successfully completed.
  • the process checks to see if the software version is downloaded to each of the scheduled CCUs. If the scheduled version is not currently downloaded on each of the scheduled CCUs, the process proceeds to block 816 where the schedule request is marked “failed” before ending. If at block 802 the scheduled version is downloaded to each of the scheduled CCUs, the process continues at block 803 where the head-end receives a configuration request from the next scheduled CCU (assuming the take effect time is still in the future). In response to receiving the configuration request, the head-end sends a command to the CCU to proceed with the take effect (block 804 ). At block 805 the CCU validates the new version of the software.
  • the CCU remains on the current version of the software (block 814 ) and the process proceeds to block 809 . If, however, at decision block 806 the CCU properly validates the new version, the process continues at block 807 where the CCU installs the new version of the software at the scheduled take effect time. At decision block 808 a check is made to determine if the installation was successful. If, at block 808 the installation was not successful, the CCU remains on the current version of the software (block 814 ) and the process continues at block 809 . Otherwise, if at block 808 the installation was successful, the process continues at block 809 where the CCU sends an operation status message to the head-end system.
  • the head-end receives a command response message from the CCU. If, at decision block 811 the command response message indicates that the installation was not successful, the process proceeds to block 815 , where if a timeout count is exceeded the process proceeds to mark schedule as failed before ending. Otherwise, if at decision block 815 the timeout count is not exceeded, the process loops back to block 803 . If at decision block 811 the installation is okay, the process continues at decision block 812 where the head-end checks to see if all scheduled CCUs are running on the new version. If not, the process loops back to block 803 , after receiving a configuration request from the another scheduled CCU. If at decision block 812 all scheduled CCUs are running the new version, the process continues at block 813 where the schedule is marked as complete. The process then ends.
  • a validation to check on the group's status may be performed first. If the validation fails and an override flag is set, the administrator may then invoke the take effect operation for each CCU in the group after logging an error.
  • the group take effect functionality may allow for “incremental” addition of CCUs to the group, as well as allowing for updates to the take effect time of state-checked CCUs that have not yet taken effect. Incremental application of take effect time is possible since the take effect operation checks to see what the state of a CCU is prior to establishing a new take effect time. If the CCU state is not “Download Pending,” “Download In Transit,” “Download Accepted,” or “Downloaded,” the function will fail, indicating to the user that the state was invalid for the operation.
  • a system-level process 900 is shown for canceling a software download request that has been downloaded to the CCU but not yet installed.
  • an administrative user that wishes to cancel an upcoming software change invokes a stored procedure that schedules the CCU to enter into a “cancel pending” state so that a cancel command will be sent to the CCU the next time the CCU communicates with the head-end. If the CCU is in the “Download Pending” or “Rollback Pending” state, it will be set back to the “Stable” state and no command will be sent to the CCU. If the CCU is in the “download accepted,” downloaded,” “takeeffect pending,” or takeeffect accepted” states, the cancel command may be sent to the CCU. If, during the course of the cancel operation, the head-end determines that the CCU has already completed the installation of the new software version, an error message may be logged and the CCU's state may be updated to show the “current” CCU software version.
  • decision block 902 if the version has not been downloaded to any CCUs yet, then the process continues at block 911 where the cancel schedule is marked as cancelled. Otherwise, if at decision block 902 the version has been downloaded to the CCUs, then the process continues at block 903 where the head-end receives a configuration request from a scheduled CCU. At block 904 the head-end process responds by sending a cancel command to the CCU. At block 905 the CCU cancels any outstanding take effect time values. At block 906 the CCU removes the cancelled software version. At block 907 the CCU sends an operation status message to the head-end. At block 908 the head-end receives a command response from the CCU.
  • the process continues at decision block 912 where if a timeout count was not exceeded, the process loops back to block 903 . Otherwise, if the timeout count was exceeded, the cancel schedule is marked as failed (block 913 ) and the process ends. If at decision block 909 the cancel was okay, the process continues at decision block 910 where if all scheduled CCUs have not been cancelled, the process loops back to block 903 for the next CCU on the cancel schedule. Otherwise, if at decision block 910 all scheduled CCUs have been cancelled, the process continues at block 911 where the schedule is marked as successfully cancelled. The process then ends.
  • Similar functionality may be applied to a group of CCUs. For example, when a cancel command is applied to a group, there will probably be CCUs in various stages of download. Consequently, downstream processing of the cancel request will vary from CCU to CCU.
  • the cancel function for groups may validate and report on the consistency of the group prior to issuing the Cancel request. If validation fails and an override flag is set, a cancel operation may be performed on each CCU in the group after logging an error.
  • a stored procedure may loop through the set of CCUs as defined by a group ID and invoke a request cancel stored procedure for each CCU in the group.
  • the CCU's state can be updated into a “Rollback Pending” state so that a rollback command will be sent to the CCU the next time the CCU communicates with the head-end.
  • an administrator schedules one or more CCUs for rollback to a previous software version at a specific time and date. Because the rollback command may only be valid in certain CCU states, such as the “stable” and “rejected” states, the stored procedure providing the interface for scheduling rollbacks may be configured to validate and report on the state of subject CCUs prior to issuing the rollback request.
  • the rollback schedule is marked as completed. If, however, at decision block 1002 there is a previous version stored at the CCU to rollback to, at rollback time the process continues at block 1003 where the head-end receives a configuration request from the scheduled CCU. At block 1004 the head-end sends a rollback command to the CCU. At block 1005 , the CCU validates the rollback version. At decision block 1006 if the version is successfully validated, the process continues at block 1007 . Otherwise, the process continues at block 1015 where the CCU remains on the current version and sends an operation status request to the head-end (block 1010 ).
  • the process continues at block 1008 . Otherwise, the process proceeds to block 1015 where the CCU remains on the current version, and then skips to block 1010 to send an operation status message to the head-end. At block 1008 the CCU rolls back to the previous version of the software. At decision block 1009 , if the rollback occurs successfully, the process continues at block 1010 . Otherwise, the process advances to block 1015 where the CCU remains running on the current version then skips to block 1010 to send an operation status message to the head-end.
  • the CCU sends an operation status message to the head-end.
  • the software-download process receives a command response message from the CCU.
  • decision block 1012 if the rollback is successful, the process continues at decision block 1013 . Otherwise, if at decision block 1012 the rollback is not successful, the process proceeds to decision block 1016 where the process checks to see if the timeout count is exceeded. If at block 1016 the timeout count is exceeded, the process continues at block 1017 where the schedule is marked as having a failed rollback before the process ends. If the timeout count is not exceeded, the process loops back to block 1003 where the process receives a configuration request from the CCU.
  • FIG. 11 is a flow chart showing an example of a process 1100 for discovering a CCU that is not recognized by the network in one embodiment.
  • the head-end receives a configuration request from a CCU that is not known on the network.
  • appropriate records are created in the software download database tables.
  • a new software BOM is sent to the CCU with a next version set to the default software version. This next version is given the take effect time of 0, so that the default version is scheduled to take effect upon download.
  • the CCU downloads the software components from the head-end.
  • the CCU sends an operation status message to the head-end indicating that the download has taken place.
  • the software download process receives a command response message from the CCU.
  • the process continues at block 1108 . Otherwise, the process continues at block 1110 where if the timeout count is not exceeded, the process loops back to block 1103 . If at decision block 1110 the timeout count was exceeded, the process continues at block 1111 where the CCUs current state is updated to download failed, after which the process ends.
  • the process loops back to block 1103 , where the new software BOM is resent to the CCU.
  • decision block 1108 if the installation of the software was okay, the process continues at block 1109 . If, however, at decision block 1108 the install was not successful, the process continues at decision block 1110 for a check of the timeout count. If the timeout count was not exceeded, the process loops back to block 1103 where a new software BOM is sent. At block 1109 the CCU's current, previous and next information is updated to reflect the software version that is currently in effect. The process then ends.
  • a group of CCUs is an association of one or more CCUs that can be acted upon in a consistent manner. For example the operator could set up a group of CCUs to be used to test new software versions and later assign the new software version to this group as a whole instead of having to manage them separately.
  • a software version may be targeted for an individual CCU, a group of CCUs or all CCUs within a system.
  • Software Version 123 could be fully implemented on CCUs in group A, fully downloaded but not implemented on CCUs in group B, partially downloaded to CCUs in group C, partially implemented on CCUs in group D and never scheduled to be implemented on CCUs in group E.
  • Reporting functions may be used to evaluate the current state of a group and of a software version so that the appropriate updates can be made. While the system may not generally assign CCU states on the basis of software version, the status of a software version at any CCU can be determined through database queries. In some embodiments, the database queries can roll-up the individual CCU states and present the information in a manner that will allow the user to determine the software version state of the system. Using these and similar reporting functions, information about CCUs and groups of CCUs can be determined such as whether members of the group have the same next version and what CCUs are out of synch with a group's definition. In addition, reporting functionality may be able to help determine the state of a specified software version (e.g., which CCUs are running it, which CCUs have successfully downloaded the version, etc.).
  • a specified software version e.g., which CCUs are running it, which CCUs have successfully downloaded the version, etc.
  • a reporting function may provide as follows: “Four CCUs from the group have successfully downloaded the requested version; two are still in the process of downloading the requested version; and one has failed.”
  • a reporting function may provide as follows: “Version XYZ has been assigned to CCU group 1 (CCUs a, b, and c) but not yet scheduled to be downloaded;” or “Version XYZ has been assigned to CCU group 2 (CCUs d, e, and f), downloaded to d, in the process of being downloaded to e, and failed downloaded to f;” or “Version XYZ has had a take effect time scheduled for CCU Group 3 (CCUs g, h, and i) for Oct.
  • Such queries can run periodically, before scheduled events (e.g., prior to a take-effect event), or at the request of a user.
  • the outcome of the reporting functions may be reports that may be of use in a variety of applications.
  • the reporting functions could also generate alarms/reports that would alert the administrator of problems with, for example, an update/install procedure, so such outstanding problems can be corrected.
  • a user interface tied to the reporting functions may provide, for example, a graphical or textual composite view of the state or status of groups of CCUs. For example, a graphical pie chart may display a percentage of CCUs in a download pending state and a percentage of CCUs in a download failed state.
  • states of CCUs within a group may be presented in a bar chart with various colors used to represent different subgroups within the group, or even individual CCUs in the group.
  • the color green may represent all CCUs in a desired state, such as the stable state
  • the color yellow may represent all CCUs in a transitional state, such as the download pending state
  • the color red may represent all CCUs in a problematic state, such as the download failed state.
  • special graphical, textual, or even audio indicators e.g., highlighted text, flashing displays, alarm sounds, etc.
  • FIG. 12 is a flow chart showing an example of a routine 1200 for adding a CCU to a group of CCUs.
  • the routine begins at decision block 1201 where if the CCU identified for addition to the group is a valid CCU, the routine continues at decision block 1202 . If the new CCU is not valid, an error is logged (block 1208 ). At decision block 1202 the routine checks to see if the new CCU's current version is compatible with the group's default version. If not, the system logs a warning at block 1203 .
  • the routine continues at decision block 1204 to determine whether the new CCU is currently a member of another group. If the new CCU is not a member of another group, the routine continues at block 1205 where the routine inserts a new collector group association record for the new CCU into a database table. If, however, at decision block 1204 the collector already belongs to a group, the routine continues at block 1206 where the routine updates the CCUs current collector group association to include the desired group or groups. After either block 1205 or block 1206 , the routine continues at block 1207 , where a log is created indicating that the addition of the CCU is complete. The routine then ends.
  • a similar routine may be implemented for removing a CCU from a group.
  • the CCU is not subsequently assigned to a new group after being removed it may become part of a default group.
  • relevant data can have preceding headers, or other overhead data proceeding (or following) the relevant data.
  • relevant data can avoid the use of any overhead data, such as headers, and simply be recognized by a certain byte or series of bytes within a serial data stream. Any number of data structures and types can be employed herein.

Abstract

A system and method for coordinating software downloads and executions, such as in a utility meter collection environment, employs a central server or head-end processor (110) that is coupled to communicate with a network of collection units, such as cell control units (108). A process, such as a state machine, tracks the status of software on the CCUs or groups of CCUs to coordinate software downloads and loading of the software on the CCUs, including adding new or past software versions.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This application is related to the following commonly assigned U.S. patent applications: U.S. patent application Ser. No. ______ (attorney docket no. 1725.173US01), filed on Sep. 5, 2003, entitled “System and Method for Detection of Specific On-Air Data Rate,” U.S. patent application Ser. No. ______ (attorney docket no. 1725.162US01), filed Sep. 5, 2003, entitled “System and Method for Mobile Demand Reset,” U.S. patent application Ser. No. ______ (attorney docket no. 1725.160US01), filed Sep. 5, 2003, entitled “System and Method for Optimizing Contiguous Channel Operation with Cellular Reuse,” U.S. patent application Ser. No. ______ (attorney docket no. 1725.156US01), filed Sep. 5, 2003, entitled “Synchronous Data Recovery System,” U.S. patent application Ser. No. ______ (attorney docket no. 1725.161US01), filed Sep. 5, 2003, entitled “Data Communication Protocol in an Automatic Meter Reading System,” U.S. patent application Ser. No. ______ (attorney docket no. 1725.167US01), filed Sep. 5, 2003, entitled “Response Optimization for Mobile and Fixed Network Operations,” and U.S. patent application Ser. No. ______ (attorney docket no. 10145-8012.US00), filed on Sep. 5, 2003, entitled “Field Data Collection and Processing System, such as for Electric, Gas, and Water Utility Data,” which are herein incorporated by reference.
  • BACKGROUND
  • Utility users and utility providers typically monitor utility use by collecting data from one or more utility meters at users' premises. In some meter-reading systems, meters equipped with transmitters, such as radio-based transmitter modules, transmit meter-reading data locally to a data collection device (“CCU”). So that the collected data may be processed in a meaningful way, the CCU may periodically upload data to one or more host or “head-end” processors via a communication link, such as a wide-area network (WAN) or the Internet. In this way, information from thousands or even millions of meters and field collection devices can be gathered and processed in one or more centralized locations.
  • Typically, software applications at both the CCU and the head-end are implemented to manage the CCU's data collection, to the control the transmission of data between the CCU and the head-end, and to facilitate downloading of schedules and other applications to the CCU. Accordingly, software updates at the head-end and/or the CCU may be implemented to ensure that the meter-reading system stays updated or to expand the meter-reading system.
  • While updating software at the head-end may be a relatively straightforward process, updating software at the CCUs may be more difficult, given that a single system may contain hundreds or even thousands of field collection devices possibly spread over a wide geographic area. Accordingly, in some systems, CCUs are configured to download software from the head-end via a network link. Using this technique, system administrators avoid having to physically access each field collection device to perform a software update. However, a CCU that is downloading software from the head-end may have to interrupt some or all of its data collection and transmission functionality. Because CCUs typically collect and transmit data on an ongoing or frequent periodic basis, interrupting a CCU's data collection and transmission functionality can be problematic, especially when large software updates can take several hours to download.
  • In addition, with current download techniques, it is difficult to ensure that all CCUs in the system will complete the download process and be ready for upgraded operation at the same time. This can cause difficulties where synchronization of multiple field collection devices is desirable.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram showing an example of a system on which the software download technique of one embodiment.
  • FIG. 2 is a block diagram showing an example of a software download facility operating in the data collection system of FIG. 1.
  • FIG. 3 is a state diagram showing some examples of high-level CCU states, as controlled by the state machine of FIG. 2 in one embodiment.
  • FIG. 4 is an example of a stored procedure or routine that, when executed at the state machine of FIG. 2, places a subject CCU in a download pending state.
  • FIG. 5 is a flow chart showing an example of a system-level software download process in the software-download facility of FIG. 2.
  • FIG. 6 is a flow chart showing an example of a software download routine in the CCU of FIG. 2.
  • FIG. 7 is flow chart illustrating an example of a software download routine in the head-end of FIG. 2.
  • FIG. 8 is an example of a system-level software take effect process in the software-download facility of FIG. 2.
  • FIG. 9 is an example of a system-level software cancel process in the software-download facility of FIG. 2.
  • FIG. 10 is an example of a system-level software rollback process in the software-download facility of FIG. 2.
  • FIG. 11 is an example of a CCU discovery process in the software-download facility of FIG. 2.
  • FIG. 12 is an example of a routine in the software download facility of FIG. 2 for adding a CCU to a group of CCUs.
  • In the drawings, the same reference numbers identify identical or substantially similar elements or acts. To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the Figure number in which that element is first introduced (e.g., element 1104 is first introduced and discussed with respect to FIG. 11).
  • DETAILED DESCRIPTION
  • The invention will now be described with respect to various embodiments. The following description provides specific details for a thorough understanding of, and enabling description for, these embodiments of the invention. However, one skilled in the art will understand that the invention may be practiced without these details. In other instances, well-known structures and functions have not been shown or described in detail to avoid unnecessarily obscuring the description of the embodiments of the invention.
  • The headings provided herein are for convenience only and do not necessarily affect the scope or meaning of the claimed invention.
  • It is intended that the terminology used in the description presented below be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific embodiments of the invention. Certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section.
  • I. Overview
  • A software download system described in detail below provides a facility for upgrading/reloading distributed embedded data collection devices, such as cell control units (“CCUs”), in the field without having an operator physically visit the CCUs. The software download system may be implemented over a communication network such as the Internet, a wide-area network (WAN), a local area network (LAN), a cellular network, etc., using well-known protocols and technologies such as HTTP, HTTPS, Wget, Active Server Pages (ASP), etc. The software download system may provide for upgrade and installation of both operating system and application-type components with minimal staging or preparation. The software download system may also facilitate recovery from a “dead box” scenario where a CCU is not working (e.g., due to a corrupted Flash file system) without a service call to the CCU. In addition, the software download system may facilitate efficient use of a system's existing available bandwidth.
  • A CCU in the software download system may be configured to store more than one version of software. For example, the CCU may store a current version, a previous version, and a next version. During a software download process, the CCU may be in one of a variety of states (e.g., “download pending,” “download accepted,” “downloaded,” “takeeffect pending,” “takeeffect accepted,” etc.). The state of the CCU may have an effect on how the CCU behaves given a command from the head-end. For example, if a cancel update operation is in progress and the head-end determines that the CCU has already installed the canceled version, it will move the CCU to a “stable” state with the “next” software version being changed to “current” and the old “current” version being changed to “previous.”
  • To facilitate logical grouping of CCU devices, the software download system may also provide grouping and audit capabilities. These capabilities may be used, for example, to monitor versions running at the CCU and the state of any scheduled downloads.
  • The software download system may incorporate techniques to minimize interruption to data transmission functionality of the CCU during the software download process. For example, the software download system may facilitate intelligent sharing of a transport link to minimize interference with a scheduled push of consumption data (e.g., collected meter reading data) to the head-end.
  • II. System Architecture
  • FIG. 1 and the following discussion provide a brief, general description of a suitable computing environment in which the invention can be implemented. Although not required, aspects of the invention are described in the general context of computer-executable instructions, such as routines executed by a general-purpose computer, e.g., a server computer, wireless device or personal computer. Those skilled in the relevant art will appreciate that the invention can be practiced with other communications, data processing or computer system configurations, including: Internet appliances, hand-held devices (including personal digital assistants (PDAs)), wearable computers, all manner of cellular or mobile phones, multi-processor systems, microprocessor-based or programmable consumer electronics, set-top boxes, network PCs, mini-computers, mainframe computers and the like. Indeed, the terms “computer,” “host” and “host computer” are generally used interchangeably, and refer to any of the above devices and systems, as well as any data processor. Aspects of the invention can be embodied in a special purpose computer or data processor that is specifically programmed, configured or constructed to perform one or more of the computer-executable instructions explained in detail herein. Aspects of the invention can also be practiced in distributed computing environments where tasks or modules are performed by remote processing devices, which are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
  • Aspects of the invention may be stored or distributed on computer-readable media, including magnetically or optically readable computer discs, as microcode on semiconductor memory, nanotechnology memory, or other portable data storage medium. Indeed, computer implemented instructions, data structures, screen displays, and other data under aspects of the invention may be distributed over the Internet or over other networks (including wireless networks), on a propagated signal on a propagation medium (e.g., an electromagnetic wave(s), a sound wave, etc.) over a period of time, or may be provided on any analog or digital network (packet switched, circuit switched or other scheme). Those skilled in the relevant art will recognize that portions of the invention reside on a server computer, while corresponding portions reside on a client computer such as a mobile device.
  • Referring to FIG. 1, a suitable system 100 on which the software download techniques may be implemented includes a meter-reading data collection system having multiple meters 102 coupled to utility-consuming devices (not shown), such as electric, gas, or water consuming devices. In the illustrated embodiment, each meter 102 includes an encoder receiver/transmitter module (ERT) 104, which serves as a data collection endpoint. The ERTs 104 encode consumption, tamper information, and other data from the meters 102 and communicate such information to a CCU 108. The communication of this data may be accomplished via radio-to-radio data collection systems such as handheld, mobile automatic meter reading or fixed network. The ERTs 104 can be retrofitted to existing meters or installed on new meters during the manufacturing process. In a system for electrical metering, the ERTs 104 may be installed under the glass of new or existing electric meters 104 and are powered by electricity running to the meter. Gas and water ERTs 104 can be attached to the meter 102 and powered by long-life batteries.
  • As shown in FIG. 1, a group of ERTs 106 communicates with one of the CCU devices 108, which in turn feeds collected data to a head-end system 110 via periodic uploads. This may occur on an ongoing basis (e.g., every half-hour) or as otherwise needed. The CCUs 108 may be implemented as neighborhood concentrators that read the ERT meter modules 104, process data into a variety of applications, store data temporarily, and transport data to the head-end 110 as needed. In some embodiments, the CCUs 108 can be installed on power poles or street light arms (not shown).
  • Further details about the system of FIG. 1, and similar systems can be found in the following commonly assigned patent applications: U.S. patent application Ser. No. 09/911,840, entitled “Spread Spectrum Meter Reading System Utilizing Low-speed/High-power Frequency Hopping,” filed Jul. 23, 2001, U.S. patent application Ser. No. 09/960,800, entitled “Radio Communication Network for Collecting Data From Utility Meters,” filed Sep. 21, 2001, and U.S. patent application Ser. No. 10/024,977, entitled “Wide Area Communications Network for Remote Data Generating Stations,” filed Dec. 19, 2001, which are herein incorporated by reference.
  • Referring to FIG. 2, a software download facility 200 operating in the data collection system 100 of FIG. 1 is configured to allow multiple versions of a software package to persist on a CCU 108 at any given time—allowing for more robust capabilities of the CCU 108 during download and providing a safety net should a need arise to revert to a previous software version. In the illustrated embodiment, a previous version, a current version and a next version of software can concurrently exist on the CCU 108. However, in alternate embodiments, multiple outstanding versions may be used, while in other embodiments, multiple versions may not be allowed. In systems where multiple software versions are not allowed, if a change needs to be made before an outstanding version of software is installed, the new version can be configured to contain the full set of components needed for the upgrade. In some cases, the CCU 108 checks its current stored outstanding version and only downloads components that it needs. The CCU 108 may also delete any stored software components that are not a part of the newer version.
  • The software download facility 200 includes components that reside on one or more platforms (not shown) at both the CCU 108 and the head-end 110. The platform at the CCU 108 does not need to be the same as the platform at the head-end 110. For example, the CCU 108 may have a Linux based platform and the head-end 110 may have a Windows 2000 Server platform. Additionally, subcomponents within the system may each operate on independent platforms. The software download facility 200 in the illustrated embodiment provides for updating CCU software stored in a file system 202 at the CCU 108 and for recovering from a catastrophic software failure without requiring a service call to the CCU or a return of the CCU to a repair depot. In some embodiments, it is possible to store a copy of the current package set in a protected partition (not shown) of the CCU file system 202 to facilitate rapid recovery from accidental or malicious corruption of a current software version.
  • To minimize bandwidth, transport mechanisms of the software download facility, such as those associated with a communication link 204, may support transfer checkpoint/restarts. Application layer protocols such as HTTP, HTTPS, WAP, SMTP, FTP, etc., may be utilized in the transfer of data. In addition, data transferred across the communication link 204 may be compressed using known compression techniques such as Gzip library functions.
  • Software download-related messages passed between the CCU 108 and the head-end 110 via the communication link 204 may be in request/response format. Such messages are described in more detail in U.S. patent application Ser. No. ______ (Attorney Docket No. 10145-8012.US00), which has been incorporated by reference. In some embodiments, a request message from the CCU may include outstanding ACK/NAK responses from the CCU 108, while a response message from the head-end 110 may include optional CCU commands (“take effect,” “cancel,” etc.). The CCU 108 may respond synchronously to the response message by returning another request message with a command response packet appended to it. The appended command response packet may contain a configuration response ACK and an optional command response ACK/NAK, depending on whether the command message that the CCU received was from the head-end. This and similar message exchanges can occur during a single session and conversation or in multiple sessions. In some embodiments, the CCU 108 initiates all request/response message exchanges, meaning the head-end 110 does not send any unsolicited messages to the CCU.
  • Several components of the CCU 108 are associated with the software download facility 200. The CCU 108 may include a two-stage loader (206 and 208) so that it can load software in such a way to help prevent catastrophic loss of software. In the illustrated embodiment, the first stage loader 206 exists in ROM and is capable of downloading the second stage loader 208 onto the file system 202. The second stage loader 208 may then download operating system features and application software components (not shown) onto the file system 202. During normal operations, the second stage loader 208 of the illustrated embodiment is responsible for ensuring that all the needed software components exist and are not corrupt. In addition, the second stage loader 208 may function to inform the head-end 110 of the current software component versions and of the current state of a software upgrade in progress. The second stage loader 208 may also handle downloading new software component versions and installation and rollback of software component versions.
  • Downloading of software data packages may be handled asynchronously at the CCU 108, in part, by a GNU (“GNU's not Unix”) utility known as Wget 210. While Wget is utilized in the illustrated embodiment, other utilities or systems could be used to provide similar functionality, such as FTP, HTTPGet, remote file copy, web server, etc. The CCU software download process 212 can invoke the Wget utility 210 as needed. The Wget utility 210 interacts with downloaded applications stored in the file system 202 of the CCU, so that the CCU 108 can receive and store requested files. The Wget utility 210 may include a transport mechanism for the Wget utility 210 that runs over HTTP (or HTTPS) and, in some embodiments, supports file checkpoint/restart through a “range” feature to aid in recovery in case of a disconnected communication link 204. The Wget utility 210 works by requesting a transfer of data pointed to by a URL. The CCU 108 may be able to build such URLs dynamically based on configuration information and data contained within a message sent by the head-end 110 to the CCU in response to a software download request message. Accordingly, the CCU 108 may be configured so that it knows its own software download server name and an appropriate top level head-end virtual directory, such as an Internet Information Services (IIS) directory.
  • In addition to processing the messages passed between the head-end 110 and the CCU 108, the CCU software download process 212 may be responsible for providing an interface with the Wget utility 210, which is used for the actual download of software packages as described above. The CCU download process 212 may also be responsible for maintaining download status information until the information has been forwarded to the head-end 110. The CCU download process 212 is also used to verify the correctness of the current version and to re-download missing or corrupt components, save current software versions, verify a new software version prior to installation, and install the new version at a scheduled “take effect” time.
  • The CCU download process 212 may also be responsible for sending shutdown requests to other processes such as a data collection application (not shown) so that those processes can persist data and state information and perform an orderly shutdown. In some embodiments, the CCU software download process 212 may wait for the other processes to end prior to shutting down the CCU 108 completely. The CCU software download process 212 can monitor the shutdown process and generate a hard kill of a process that does not respond to the requested shutdown.
  • In the illustrated embodiment, the CCU software download process 212 facilitates a “rollback” to a previous version of software stored in the CCU file system 202. The installation of a new version is handled as an autonomous operation so that if a subsequent update or rollback is not successfully completed, the CCU 108 reverts to a state it was in prior to attempting the update/rollback. During the update/rollback, the CCU software download process 212 may avoid message exchanges with the head-end 110 until completion of the operation to insure that any software download configuration information received at the head-end 110 does not contain partial configuration information.
  • The head-end processor 110, which includes a database 214 for storing persistent information, supports several components of the software download facility 200. For example, the head-end 110 may provide device grouping, version control and tracking functionality for the management of software download processes via a head-end software download command processor, which is implemented as a state machine 216 in some embodiments. In other embodiments, standard hierarchy-based, procedural, or object-oriented coding practices may implement the software download processor instead of the state machine. The state machine 216 can exist in the database 214 and may be implemented using stored procedures and triggers stored in the database 214 at the head-end 110 or may be implemented using components stored on the file system 218 at the head-end 110
  • While in the illustrated embodiment, the head-end 110 is not responsible for packaging, building, releasing, and verifying of CCU software packages, in alternative systems (not shown) the head-end 110 may facilitate these tasks. For example, various types of CCU software (application, operating system, etc.) can be packaged into sets or packages using a package manager such as a Linux based Remote Package Manager (RPM), or a proprietary package manager. In some embodiments, each set of packages corresponds to a version of the software and constitutes the bill of materials (BOM) for that version. Accordingly, the BOM contains all the information needed by the CCU 108 to verify the validity of a currently installed version.
  • The file system 218 at the head-end 110 stores applications (not shown) that may facilitate the transfer of software packages. An Internet Information Service (IIS) component 220 may interact with the file system 218 to download files (e.g., RPM files) from virtual directories via the communication link 204. An Active Server Page (ASP) component 222 in the IIS component 220 may be responsible for processing binary data and storing it in an appropriate “To Process” database tables for further processing. In some embodiments implementing ASP technology, when the ASP component 222 receives a binary message from the CCU 108, it can use Gzip to verify that the message has arrived intact. It then unzips the message, parses it, and stores the parsed message in appropriate data tables. The ASP component 222 may then invoke a stored procedure (not shown) that will invoke the state machine 216. The state machine 216 in turn returns a response to the ASP component 222. The ASP component can then Gzip the response and forward it back to the CCU 108. In some cases, the ASP component 222 may hold an HTTPS session (or other type session) open until the CCU 108 acknowledges receipt of the sent response packet.
  • Because IIS and Wget can provide the appropriate interaction for the transport of packages, implementation at the head-end may not be needed to handle downloading of software packages.
  • III. State Machine
  • In some embodiments of the software download system, the state of a CCU (e.g., CCU 108 of FIGS. 1 and 2), as determined by a CCU decision processor or state machine (e.g., state machine 216 of FIG. 2), may be used in controlling the software download process, and other related processes. For example, the state machine 216 may control a download state of any CCU that is in communication with the state machine. In some embodiments, each state handles self-transitions that may occur if the state machine 216 receives configuration requests or duplicate command response events while waiting for the events that cause a state transition. In such cases, the state machine 216 may rebuild the correct response message, return it to the ASP component 222, and remain in the current state.
  • The state machine 216 may also be responsible for updating the head-end database 214 with the status of scheduled software downloads from information received from the CCUs 108. The state machine 216 may use information stored in the database to control downloads of new CCU software components to selected CCUs or groups of CCUs.
  • FIG. 3 is a state diagram 300 showing some examples of high-level CCU superstates (“states”), as controlled by the state machine in one embodiment. These superstates may be associated with various lower level states (as shown in Table 1) that may inherit from, or otherwise relate back to, the superstates. The illustrated states include a discovery state 301, an update state 302, a stable state 303, a rollback state 304, a cancel state 305 and a rejected state 306. Each state can be triggered by some event. For example, in some embodiments, the rejected state 306 can be triggered by a failed software update or software rollback.
  • The discovery state 301 is invoked for a CCU when the CCU is first incorporated or reincorporated into the system. In some embodiments, the state machine invokes the discovery state 301 for the CCU when the head-end receives a command from a CCU that has a global uniform identifier (GUID) equal to zero or not equal to some default (meaning that the CCU is not known to the system). During the discovery state 301, the CCU may be assigned a default software version (initialization). Once this occurs, the state machine may change the CCU's state to the update state 302 so that a software update can be initiated via processing that occurs at both the head-end and the CCU. From the update state 302, the state of the CCU may proceed to the stable state 303, the cancel state 305 or the rejected state 306. For example, the CCU's state may change from the update state 302 to the stable state 303 if the invoked software update is successfully completed. If, however, the invoked software update fails, then the state may change from the update state 302 to the rejected state 306. In another possibility, if an administrator cancels an invoked software update request, the state may change from the update state 302 to the cancel state 305.
  • From the stable state 303, the CCU's state may go back to the update state 302 or may proceed to the rollback state 304. The state changes from the stable state 303 to the rollback state 304 if a rollback request is implemented. From the rollback state 304, the state can change back to the stable state 303 if the rollback is successfully completed. If the rollback fails, the state can change to the rejected state 306. If an administrator cancels a rollback, the state may change back to the cancel 305 state.
  • From the rejected state 306, the state can change to the update state 302, the rollback state 304 or the stable state 303, depending on the nature of the rejection. For example, in the case of a failed software update, the update state 302 may be resumed so that the software update can be reattempted.
  • Some more detailed examples of CCU states, including those discussed with respect to FIG. 3, are shown in Table 1 below. Table 1 includes a reference to “Process to Execute.” Such processes may stored procedures that reside in the database 214 as described with respect to FIG. 2, or could be other programs.
    TABLE 1
    Sample States
    Current
    State Control Input Process To Execute Next State
    Initialize Configuration NoOp Download In
    Request Received Transit
    Initialize Initialization Failed InitializeFailed Rejected
    for Collector
    Stable Configuration NoOp Stable
    Request Received
    Stable Update Request NoOp Download
    Pending
    Stable Rollback Request NoOp RB Pending
    Download Configuration NoOp Download In
    Pending Request Received Transit
    Download Configuration InvalidTakeEffectTime Rejected
    Pending Request Received
    and Invalid Take
    Effect Time
    Download Configuration InvalidNextVersion Rejected
    Pending Request Received
    and No Next Version
    Download Cancel Request NoOp Stable
    Pending
    Download In Null Control Input NoOp Download In
    Transit Transit
    Download In Command Rejected DownloadInTransitCmdRejected Rejected
    Transit
    Download In Command Accepted DownloadAcceptedNoNextVersion Rejected
    Transit and No Next Version
    Download In Command Accepted InvalidTakeEffectTime Rejected
    Transit and Invalid Take
    Effect Time
    Download In Command Accepted NoOp Download
    Transit Accepted
    Download Null Control Input NoOp Download
    Accepted Accepted
    Download Command Complete DownloadCompleteNoNextVersion Rejected
    Accepted and No Next Version
    Download Command Complete SetDownloaded Take Effect
    Accepted and Valid TE Time In Transit
    Download Command Complete DownloadCompleteInvalidTakeEffectTime Rejected
    Accepted and Invalid TE Time
    Download Command SetDownloaded Downloaded
    Accepted Completed
    Download Command Failed DownloadAcceptedCmdFailed Rejected
    Accepted
    Download Cancel Request NoOp Cancel
    Accepted Pending
    Downloaded Configuration NoOp Downloaded
    Request Received
    Downloaded Take-Effect Request spSoftwareDownloadEvtNoOp Take Effect
    Pending
    Downloaded Take-Effect Time spSoftwareDownloadEvtInvalidNextVersion Rejected
    Request and no
    Next Version in
    Database
    Downloaded Cancel Request NoOp Cancel
    Pending
    Take Effect Configuration NoOp Take Effect
    Pending Request Received In Transit
    Take Effect Configuration InvalidNextVersion Rejected
    Pending Request Received
    and No Next Version
    Take Effect Cancel Request NoOp Cancel
    Pending Pending
    Take Effect Null Control Input NoOp Take Effect
    In Transit In Transit
    Take Effect Command Accepted TakeEffectAcceptedNoNextVersion Rejected
    In Transit and No Next Version
    Take Effect Command Accepted NoOp Take Effect
    In Transit Accepted
    Take Effect Command Rejected TakeEffectInTransitCmdRejected Rejected
    In Transit
    Take Effect Configuration ChangeSWVersion Stable
    In Transit Request Received
    and UPD
    Configuration =
    Expected
    Take Effect Null Control Input NoOp Take Effect
    Accepted Accepted
    Take Effect Command TakeEffectCompletedNoNextVersion Rejected
    Accepted Completed and No
    Next Version
    Take Effect Command ChangeSWVersion Stable
    Accepted Completed
    Take Effect Command Failed spSoftwareDownloadEvtTakeEffectAcceptedCmdFailed Rejected
    Accepted
    Take Effect Configuration ChangeSWVersion Stable
    Accepted Request Received
    and UPD
    Configuration =
    Expected
    Take Effect Cancel Request NoOp Cancel
    Accepted Pending
    Rejected Configuration NoOp Rejected
    Request Received
    Rejected Update Request NoOp Download
    Pending
    Rejected Rollback Request NoOp Rollback
    Pending
    Rollback Cancel Request NoOp Stable
    Pending
    Rollback Configuration NoOp Rollback In
    Pending Request Received Transit
    Rollback Configuration CfgRqstNoPreviousVersion Rejected
    Pending Request Received
    and No Previous
    Version
    Rollback In Null Control Input NoOp Rollback In
    Transit Transit
    Rollback In Command Accepted NoOp Rollback
    Transit Accepted
    Rollback In Command Rejected RBInTransitCmdRejected Rejected
    Transit
    Rollback In Command Accepted RBAcceptedNoPreviousVersion Rejected
    Transit and No Previous
    Version
    Rollback In Configuration RollbackSWVersion Stable
    Transit Request Received
    and RB
    Configuration =
    Expected
    Rollback Null Control Input NoOp Rollback
    Accepted Accepted
    Rollback Command RollbackSWVersion Stable
    Accepted Completed
    Rollback Command Failed RollBackAcceptedCmdFailed Rejected
    Accepted
    Rollback Command RollBackCompleteNoPreviousVersion Rejected
    Accepted Completed and No
    Previous Version
    Rollback Configuration RollbackSWVersion Stable
    Accepted Request Received
    and RB
    Configuration =
    Expected
    Cancel Null Control Input NoOp Cancel
    Pending Pending
    Cancel Configuration NoOp Cancel In
    Pending Request Received Transit
    Cancel Configuration CancelTakeEffectOccurred Stable
    Pending Request Received
    and UPD
    Configuration =
    Expected
    Cancel Configuration CancelPendingInvalidTakeEffectTime Rejected
    Pending Request Received
    and Invalid
    TakeEffect Time
    Cancel Take-Effect CancelTakeEffectOccurred Stable
    Pending Completed
    Cancel Take-Effect Failed CancelPendingTakeEffectFailed Rejected
    Pending
    Cancel Configuration NoOp Cancel In
    Pending Request Received Transit
    and Valid TE Time
    Cancel In Null Control Input NoOp Cancel In
    Transit Transit
    Cancel In Command Accepted NoOp Cancel
    Transit Accepted
    Cancel In Command Rejected CancelInTransitCmdRejected Rejected
    Transit
    CN In Configuration CancelTakeEffectOccurred Stable
    Transit Request Received
    and UPD
    Configuration =
    Expected
    Cancel In Take-Effect CancelTakeEffectOccurred Stable
    Transit Completed
    Cancel In Take-Effect Failed CancelInTransitTakeEffectFailed Rejected
    Transit
    Cancel Null Control Input NoOp Cancel
    Accepted Accepted
    Cancel Command Accepted CancelAcceptedCmdComplete Stable
    Accepted
    Cancel Command Failed CancelAcceptedCmdFailed Rejected
    Accepted
    Cancel Configuration CancelTakeEffectOccurred Stable
    Accepted Request Received
    and UPD
    Configuration =
    Expected
    Cancel Take-Effect CancelTakeEffectOccurred Stable
    Accepted Completed
    Cancel Take-Effect Failed CancelAcceptedTakeEffectFailed Rejected
    Accepted

    IV. Software Control Functionality and Interface
  • The software download facility 200 may provide functionality and corresponding interfaces that allow administrative users to manage the software running on the system's CCUs 108. In some embodiments, this functionality and any corresponding user interfaces may be implemented in part, via stored procedures at the state machine. For example, administrative users may be able to perform operations to set a CCU 108 into a download pending state so that the state machine 216 will send a download command to the CCU the next time the CCU communicates with the head-end. FIG. 4 is an example of a state machine stored procedure or routine 400 that, when executed, places a subject CCU in the download pending state.
  • The routine begins at block 401 where the routine logs a state change request made by the administrative user. Because moving into the download pending state may not be possible if a CCU is currently in a state other than stable or rejected (e.g., the stable 303 or rejected 306 states of FIG. 3), in decision block 402 the routine checks the current state of the subject CCU. If the subject CCU is not in a stable or rejected state, the routine logs an error at block 405 and then ends. Otherwise, if at decision block 402 the subject CCU is in a stable or rejected state, the routine continues at decision block 403 where the routine checks to see if the administrator's request is valid (e.g., if there is an existing software upgrade available for that particular CCU). If, at decision block 403 the administrator's request is not valid, the routine logs an error at block 405 and then ends. If, however, at decision block 403 the administrator's request is valid, the routine proceeds to block 404, where the state of the subject CCU is updated to the download pending state. The routine then ends.
  • Once the subject CCU is in a download pending state, the CCU can send a configuration request to the head-end to initiate a software download. The CCU may initiate a configuration request communication, for example, when the CCU reboots or determines that its current software is corrupted or during any scheduled communications window in which a software download bit is set for the window. Some of the processes associated with software downloads are illustrated in more detail in FIGS. 5 through 11.
  • Referring to FIG. 5, a software download process 500 permits a CCU to download software from a head-end system. A software download process running at the CCU, such as the software download process component 212 of FIG. 2, is responsible for initiating communications with the head-end.
  • At block 501 new software components are installed at the head-end. At block 502 an administrator schedules a CCU to download a software update. At block 503 the scheduled CCU sends out a configuration request to the head-end. This may include posting a message to a configuration request ASP page. The configuration request message may also include appended software command responses (ACKs/NAKs). At block 504 the head-end replies to the configuration request message by sending a software configuration data back to the CCU, including software download commands and/or a new software BOM that contains all the information needed by the CCU to verify the validity of the current installed version. At block 505 the CCU downloads the software components to its file system. At block 506 the CCU sends an operation status message to the head-end. This may occur at some point during the download and may include posting a configuration response message to a configuration response ASP page. While not shown, the head-end may reply to the configuration response message via an HTTP reply.
  • At block 507 the head-end receives a command response message from the CCU. The command response message may indicate whether the download was successful. At decision block 508 if the download was successful the routine continues at decision block 509. However, if at block 508 the download was not successful, the process continues at decision block 511 where the head-end checks if a timeout count for the download was exceeded. If at decision block 511 the timeout count was exceeded, the process continues at block 512 where the head-end system marks the scheduled download as “failed” and then ends. Otherwise, if at decision block 511 the timeout count is not exceeded, the process loops back to block 503 and repeats the process for the same CCU.
  • Where a group of CCUs in involved, the routine continues at decision block 509 where the head-end checks if all scheduled CCUs in the group have completed the download. While the downloading of the CCUs in the group may be occurring in parallel, because responses from CCUs may be sent at different times, the routine repeats itself each time a new configuration response is received at the head-end. Accordingly, if at decision block 509 all scheduled CCUs have not been downloaded, the routine loops back to block 503. Otherwise, if at decision block 509 all scheduled CCUs have been downloaded, the process continues at block 510 where the head-end marks the scheduled download as “complete” for all scheduled CCUs in the group. The process then ends.
  • FIG. 6 is a flow chart showing an example of a routine 600 that occurs at the CCU during the software download process of FIG. 5 (see i.e., block 505 of FIG. 5). At block 601 the CCU sends a configuration message to the head-end. At block 602 the routine receives a software configuration response message from the head-end, which includes any additional download commands (take-effect time, cancel, etc.). The CCU's software download process may be responsible for processing the software configuration response along with any additional software download commands received from the head-end. In decision block 603 the routine checks to see if the download is possible. If the download is not possible, the routine sends a “failed” command response message to the head-end (block 613) before ending. Otherwise, if at decision block 603 the download is possible, the routine continues at block 604 where the routine sends a “success” command response message to the head-end.
  • At block 605 the routine determines if new RPM packages need to be downloaded. In decision block 606 if new software versions are needed, the routine continues at block 607. Otherwise, the routine ends. At block 607 the routine invokes the Wget utility to download and store the appropriate software versions. At block 608 the routine monitors Wget for download statuses (complete, failed, etc.).
  • In decision block 609 if the download is unsuccessful, the routine continues at block 614 where the routine sends a “failed” command response to the head-end before ending. Otherwise, at decision block 609 if the download is successful, the routine continues at block 610 where the new version of the software is validated. In decision block 611 if the validation is not successful, the routine continues at block 614 where the routine sends a “failed” command response to the head-end before ending. Otherwise, if at decision block 611 the validation is successful, the routine continues at block 612 where the routine sends a “success” command response message to the head-end before ending.
  • Referring to FIG. 7, a software download routine 700 is called by an ASP component, such as the ASP component 222 of FIG. 2, after the configuration request message has been received, parsed and stored in a “ToProcess” table at the head-end database. The routine invokes the head-end state machine for state determinations.
  • At block 701 the routine retrieves a configuration request message from the ToProcess table. At block 702 the routine gets the current state via the state machine. The state machine achieves this by querying one or more head-end database tables for software configuration data. The state machine then forwards this information along with any required software download command messages back to the ASP component. In decision block 703 if a state does not exist, the state is set to zero by default (block 704) before continuing at block 707. Otherwise, if a state does exist at block 703 the routine proceeds to decision block 705 where the routine checks to see if the state is stable. If the state is not stable, the routine proceeds to block 707. Otherwise, if at decision block 705 the state is stable, the routine continues at block 706 where the routine checks to see if the globally unique identifier (GUID) of the configuration request is equal to zero.
  • If the GUID of the configuration request is equal to zero, the state is also set to zero at block 704. Otherwise, if at decision block 706 the GUID is not equal to zero, the routine continues at block 707. At block 707 the routine gets the next state context stored procedure to be called. At block 708 if the state context stored procedure does not exist, the routine logs an error (block 711) and builds a corresponding message (block 712) before ending. Otherwise, if at decision block 708, the state stored procedure exists, the routine continues at block 709, where the routine invokes the state context stored procedure. At decision block 710 if additional configuration request commands are waiting in the ToProcess table, the routine loops back to block 701. Otherwise, the routine builds the appropriate log message (block 712) and then ends.
  • Once downloaded onto a CCU, software is typically stored on the CCU as a “next” software version. To allow for flexibility as to when the software version will in take effect, the downloaded software will usually not take effect on the CCU until a scheduled take effect time is established for the CCU. Once a CCU is scheduled with a take effect time, it is then responsible for knowing its own take effect time and installing or loading downloaded software versions accordingly.
  • Referring to FIG. 8, a take effect process 800 involves creating a schedule with a take effect time for one or more CCUs. The take effect process 800 begins at block 801 where an administrative user invokes a stored procedure that provides the interface needed to set a take effect time for the desired CCUs next software version. During the invocation of the stored procedure, if the CCU is in the downloaded state, the CCU may be set to the take effect pending state so that a take effect command will be sent to the CCU the next time the CCU communicates with the head-end. If the CCU is in a download pending, download in transit, or download accepted state, the take effect time may be saved and the head-end may send the take effect command to the CCU upon notification that the software download operation has successfully completed.
  • At decision block 802 the process checks to see if the software version is downloaded to each of the scheduled CCUs. If the scheduled version is not currently downloaded on each of the scheduled CCUs, the process proceeds to block 816 where the schedule request is marked “failed” before ending. If at block 802 the scheduled version is downloaded to each of the scheduled CCUs, the process continues at block 803 where the head-end receives a configuration request from the next scheduled CCU (assuming the take effect time is still in the future). In response to receiving the configuration request, the head-end sends a command to the CCU to proceed with the take effect (block 804). At block 805 the CCU validates the new version of the software. At decision block 806 if the validation fails, then the CCU remains on the current version of the software (block 814) and the process proceeds to block 809. If, however, at decision block 806 the CCU properly validates the new version, the process continues at block 807 where the CCU installs the new version of the software at the scheduled take effect time. At decision block 808 a check is made to determine if the installation was successful. If, at block 808 the installation was not successful, the CCU remains on the current version of the software (block 814) and the process continues at block 809. Otherwise, if at block 808 the installation was successful, the process continues at block 809 where the CCU sends an operation status message to the head-end system.
  • At block 810 the head-end receives a command response message from the CCU. If, at decision block 811 the command response message indicates that the installation was not successful, the process proceeds to block 815, where if a timeout count is exceeded the process proceeds to mark schedule as failed before ending. Otherwise, if at decision block 815 the timeout count is not exceeded, the process loops back to block 803. If at decision block 811 the installation is okay, the process continues at decision block 812 where the head-end checks to see if all scheduled CCUs are running on the new version. If not, the process loops back to block 803, after receiving a configuration request from the another scheduled CCU. If at decision block 812 all scheduled CCUs are running the new version, the process continues at block 813 where the schedule is marked as complete. The process then ends.
  • When take effect functionality is applied to a group of CCUs, a validation to check on the group's status (to ensure consistency within the group) may be performed first. If the validation fails and an override flag is set, the administrator may then invoke the take effect operation for each CCU in the group after logging an error. In some embodiments, the group take effect functionality may allow for “incremental” addition of CCUs to the group, as well as allowing for updates to the take effect time of state-checked CCUs that have not yet taken effect. Incremental application of take effect time is possible since the take effect operation checks to see what the state of a CCU is prior to establishing a new take effect time. If the CCU state is not “Download Pending,” “Download In Transit,” “Download Accepted,” or “Downloaded,” the function will fail, indicating to the user that the state was invalid for the operation.
  • Referring to FIG. 9, a system-level process 900 is shown for canceling a software download request that has been downloaded to the CCU but not yet installed. At block 901, an administrative user that wishes to cancel an upcoming software change invokes a stored procedure that schedules the CCU to enter into a “cancel pending” state so that a cancel command will be sent to the CCU the next time the CCU communicates with the head-end. If the CCU is in the “Download Pending” or “Rollback Pending” state, it will be set back to the “Stable” state and no command will be sent to the CCU. If the CCU is in the “download accepted,” downloaded,” “takeeffect pending,” or takeeffect accepted” states, the cancel command may be sent to the CCU. If, during the course of the cancel operation, the head-end determines that the CCU has already completed the installation of the new software version, an error message may be logged and the CCU's state may be updated to show the “current” CCU software version.
  • In decision block 902 if the version has not been downloaded to any CCUs yet, then the process continues at block 911 where the cancel schedule is marked as cancelled. Otherwise, if at decision block 902 the version has been downloaded to the CCUs, then the process continues at block 903 where the head-end receives a configuration request from a scheduled CCU. At block 904 the head-end process responds by sending a cancel command to the CCU. At block 905 the CCU cancels any outstanding take effect time values. At block 906 the CCU removes the cancelled software version. At block 907 the CCU sends an operation status message to the head-end. At block 908 the head-end receives a command response from the CCU. At decision block 909 if the cancel was not okay, the process continues at decision block 912 where if a timeout count was not exceeded, the process loops back to block 903. Otherwise, if the timeout count was exceeded, the cancel schedule is marked as failed (block 913) and the process ends. If at decision block 909 the cancel was okay, the process continues at decision block 910 where if all scheduled CCUs have not been cancelled, the process loops back to block 903 for the next CCU on the cancel schedule. Otherwise, if at decision block 910 all scheduled CCUs have been cancelled, the process continues at block 911 where the schedule is marked as successfully cancelled. The process then ends.
  • Similar functionality may be applied to a group of CCUs. For example, when a cancel command is applied to a group, there will probably be CCUs in various stages of download. Consequently, downstream processing of the cancel request will vary from CCU to CCU. Thus, the cancel function for groups may validate and report on the consistency of the group prior to issuing the Cancel request. If validation fails and an override flag is set, a cancel operation may be performed on each CCU in the group after logging an error. A stored procedure may loop through the set of CCUs as defined by a group ID and invoke a request cancel stored procedure for each CCU in the group.
  • To have a CCU rollback to a previous software version that has been stored on the CCU, but not in current use, the CCU's state can be updated into a “Rollback Pending” state so that a rollback command will be sent to the CCU the next time the CCU communicates with the head-end.
  • Referring to FIG. 10, a process 1000 for conducting software rollbacks in one embodiment whereby a CCU may reinstall a previously installed version of software saved on that CCU. Allowing CCUs to return to a previous version can be useful in circumstances where current versions are not running properly, or in a variety of other circumstances. At block 1001 an administrator schedules one or more CCUs for rollback to a previous software version at a specific time and date. Because the rollback command may only be valid in certain CCU states, such as the “stable” and “rejected” states, the stored procedure providing the interface for scheduling rollbacks may be configured to validate and report on the state of subject CCUs prior to issuing the rollback request.
  • At decision block 1002 if there is no previous version to roll back to, the rollback schedule is marked as completed. If, however, at decision block 1002 there is a previous version stored at the CCU to rollback to, at rollback time the process continues at block 1003 where the head-end receives a configuration request from the scheduled CCU. At block 1004 the head-end sends a rollback command to the CCU. At block 1005, the CCU validates the rollback version. At decision block 1006 if the version is successfully validated, the process continues at block 1007. Otherwise, the process continues at block 1015 where the CCU remains on the current version and sends an operation status request to the head-end (block 1010).
  • At decision block 1007 if the scheduled rollback version exists on the CCU, the process continues at block 1008. Otherwise, the process proceeds to block 1015 where the CCU remains on the current version, and then skips to block 1010 to send an operation status message to the head-end. At block 1008 the CCU rolls back to the previous version of the software. At decision block 1009, if the rollback occurs successfully, the process continues at block 1010. Otherwise, the process advances to block 1015 where the CCU remains running on the current version then skips to block 1010 to send an operation status message to the head-end.
  • At block 1010 the CCU sends an operation status message to the head-end. At block 1011 the software-download process receives a command response message from the CCU. At decision block 1012 if the rollback is successful, the process continues at decision block 1013. Otherwise, if at decision block 1012 the rollback is not successful, the process proceeds to decision block 1016 where the process checks to see if the timeout count is exceeded. If at block 1016 the timeout count is exceeded, the process continues at block 1017 where the schedule is marked as having a failed rollback before the process ends. If the timeout count is not exceeded, the process loops back to block 1003 where the process receives a configuration request from the CCU.
  • At decision block 1013 if all scheduled CCUs have been rolled back then the process continues at block 1014. Otherwise, the process loops back to block 1003 where the process receives a configuration request from another scheduled CCU. At block 1014 the process marks the scheduled CCU as rolled back.
  • When a rollback command is applied to a group of CCUs there may be CCUs in various stages of download. Consequently, downstream processing of the rollback command will vary from CCU to CCU.
  • The system may also provide a process for “discovering” a CCU that has been newly added to the network, or a CCU that is returning the network after being disabled for some period of time. FIG. 11 is a flow chart showing an example of a process 1100 for discovering a CCU that is not recognized by the network in one embodiment. At block 1101 the head-end receives a configuration request from a CCU that is not known on the network. At block 1102 appropriate records are created in the software download database tables. At block 1103 a new software BOM is sent to the CCU with a next version set to the default software version. This next version is given the take effect time of 0, so that the default version is scheduled to take effect upon download. At block 1104 the CCU downloads the software components from the head-end. At block 1105 the CCU sends an operation status message to the head-end indicating that the download has taken place. At block 1106 the software download process receives a command response message from the CCU.
  • At decision block 1107 if the download was successful, the process continues at block 1108. Otherwise, the process continues at block 1110 where if the timeout count is not exceeded, the process loops back to block 1103. If at decision block 1110 the timeout count was exceeded, the process continues at block 1111 where the CCUs current state is updated to download failed, after which the process ends.
  • If at decision block 1110 the timeout count was not exceeded, the process loops back to block 1103, where the new software BOM is resent to the CCU. At decision block 1108 if the installation of the software was okay, the process continues at block 1109. If, however, at decision block 1108 the install was not successful, the process continues at decision block 1110 for a check of the timeout count. If the timeout count was not exceeded, the process loops back to block 1103 where a new software BOM is sent. At block 1109 the CCU's current, previous and next information is updated to reflect the software version that is currently in effect. The process then ends.
  • V. Grouping CCUs
  • As described, most of the software download facility's functionality can be applied either to single CCUs or groups of CCUs. A group of CCUs is an association of one or more CCUs that can be acted upon in a consistent manner. For example the operator could set up a group of CCUs to be used to test new software versions and later assign the new software version to this group as a whole instead of having to manage them separately.
  • Through the use of CCU groups, a software version may be targeted for an individual CCU, a group of CCUs or all CCUs within a system. For example, Software Version 123 could be fully implemented on CCUs in group A, fully downloaded but not implemented on CCUs in group B, partially downloaded to CCUs in group C, partially implemented on CCUs in group D and never scheduled to be implemented on CCUs in group E.
  • Reporting functions may be used to evaluate the current state of a group and of a software version so that the appropriate updates can be made. While the system may not generally assign CCU states on the basis of software version, the status of a software version at any CCU can be determined through database queries. In some embodiments, the database queries can roll-up the individual CCU states and present the information in a manner that will allow the user to determine the software version state of the system. Using these and similar reporting functions, information about CCUs and groups of CCUs can be determined such as whether members of the group have the same next version and what CCUs are out of synch with a group's definition. In addition, reporting functionality may be able to help determine the state of a specified software version (e.g., which CCUs are running it, which CCUs have successfully downloaded the version, etc.).
  • For example, in response to a user query: “What is the current status of CCU group 123?,” a reporting function may provide as follows: “Four CCUs from the group have successfully downloaded the requested version; two are still in the process of downloading the requested version; and one has failed.” Likewise, in response to a user query: “What is the current status of SW version XYZ?,” a reporting function may provide as follows: “Version XYZ has been assigned to CCU group 1 (CCUs a, b, and c) but not yet scheduled to be downloaded;” or “Version XYZ has been assigned to CCU group 2 (CCUs d, e, and f), downloaded to d, in the process of being downloaded to e, and failed downloaded to f;” or “Version XYZ has had a take effect time scheduled for CCU Group 3 (CCUs g, h, and i) for Oct. 11, 2003, the take effect time sent to g, in the process of being sent to h, and failed when sent to i;” or “Version XYZ has had a take effect time scheduled for Group 4 (collectors j, k, and l) for Sep. 11, 2003, the SW was installed successfully in j and k, but failed in l;” or “Version XYZ is currently running in collector m because m failed the update to version +1 and rolled back.”
  • Once generated, such queries can run periodically, before scheduled events (e.g., prior to a take-effect event), or at the request of a user. The outcome of the reporting functions may be reports that may be of use in a variety of applications. The reporting functions could also generate alarms/reports that would alert the administrator of problems with, for example, an update/install procedure, so such outstanding problems can be corrected. Additionally, a user interface tied to the reporting functions may provide, for example, a graphical or textual composite view of the state or status of groups of CCUs. For example, a graphical pie chart may display a percentage of CCUs in a download pending state and a percentage of CCUs in a download failed state. In another example, states of CCUs within a group may be presented in a bar chart with various colors used to represent different subgroups within the group, or even individual CCUs in the group. For example, the color green may represent all CCUs in a desired state, such as the stable state, the color yellow may represent all CCUs in a transitional state, such as the download pending state, and the color red may represent all CCUs in a problematic state, such as the download failed state. Likewise, special graphical, textual, or even audio indicators (e.g., highlighted text, flashing displays, alarm sounds, etc.) may be used to flag problems, such as CCUs from the group in a failed state. Many other representations of the reporting functions are possible without departing from the scope of the invention.
  • Because grouping CCUs may be useful, the system may provide procedures for controlling the grouping of CCUs. For example, administrative users may be able to add/remove CCUs from a group. FIG. 12 is a flow chart showing an example of a routine 1200 for adding a CCU to a group of CCUs. The routine begins at decision block 1201 where if the CCU identified for addition to the group is a valid CCU, the routine continues at decision block 1202. If the new CCU is not valid, an error is logged (block 1208). At decision block 1202 the routine checks to see if the new CCU's current version is compatible with the group's default version. If not, the system logs a warning at block 1203. At this point, the operation may still be allowed and reporting functions may determine what CCUs are out of synch with the group definition. If at block 1202 the CCU's current version is compatible with the group's, the routine continues at decision block 1204 to determine whether the new CCU is currently a member of another group. If the new CCU is not a member of another group, the routine continues at block 1205 where the routine inserts a new collector group association record for the new CCU into a database table. If, however, at decision block 1204 the collector already belongs to a group, the routine continues at block 1206 where the routine updates the CCUs current collector group association to include the desired group or groups. After either block 1205 or block 1206, the routine continues at block 1207, where a log is created indicating that the addition of the CCU is complete. The routine then ends.
  • A similar routine (not shown) may be implemented for removing a CCU from a group. In some embodiments, if the CCU is not subsequently assigned to a new group after being removed it may become part of a default group.
  • The above detailed descriptions of embodiments of the invention are not intended to be exhaustive or to limit the invention to the precise form disclosed above. While specific embodiments of, and examples for, the invention are described above for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. For example, while steps are presented in a given order, alternative embodiments may perform routines having steps in a different order. The teachings of the invention provided herein can be applied to other systems, not necessarily the automatic meter-reading system described herein. The elements and acts of the various embodiments described above can be combined to provide further embodiments and some steps may be deleted, moved, added, subdivided, combined, and/or modified. Each of these steps may be implemented in a variety of different ways. Also, while these steps are shown as being performed in series, these steps may instead be performed in parallel, or may be performed at different times.
  • While the term “field” and “record” are used herein, any type of data structure can be employed. For example, relevant data can have preceding headers, or other overhead data proceeding (or following) the relevant data. Alternatively, relevant data can avoid the use of any overhead data, such as headers, and simply be recognized by a certain byte or series of bytes within a serial data stream. Any number of data structures and types can be employed herein.
  • Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in the sense of “including, but not limited to.” Words in the above detailed description using the singular or plural number may also include the plural or singular number respectively. Additionally, the words “herein,” “above,” “below,” and words of similar import, when used in this application, shall refer to this application as a whole and not to any particular portions of this application. When the claims use the word “or” in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.
  • The teachings of the invention provided herein can be applied to other systems, not necessarily the system described herein. These and other changes can be made to the invention in light of the detailed description. The elements and acts of the various embodiments described above can be combined to provide further embodiments.
  • All of the above patents and applications and other references, including any that may be listed in accompanying filing papers, are incorporated herein by reference. Aspects of the invention can be modified, if necessary, to employ the systems, functions, and concepts of the various references described above to provide yet further embodiments of the invention.
  • These and other changes can be made to the invention in light of the above detailed description. While the above description details certain embodiments of the invention and describes the best mode contemplated, no matter how detailed the above appears in text, the invention can be practiced in many ways. Details of the protocol, data model, and processing scheme may vary considerably in its implementation details, while still being encompassed by the invention disclosed herein. As noted above, particular terminology used when describing certain features, or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to any specific characteristics, features, or aspects of the invention with which that terminology is associated. In general, the terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification, unless the above Detailed Description section explicitly defines such terms. Accordingly, the actual scope of the invention encompasses not only the disclosed embodiments, but also all equivalent ways of practicing or implementing the invention under the claims.
  • While certain aspects of the invention are presented below in certain claim forms, the inventors contemplate the various aspects of the invention in any number of claim forms. For example, while only one aspect of the invention is recited as embodied in a computer-readable medium, other aspects may likewise be embodied in a computer-readable medium. Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the invention.

Claims (21)

1. A system for providing software updates for download to multiple utility data collection devices each having a state, wherein the utility data collection devices receive utility meter data associated with multiple utility meters, wherein the utility meter data represents consumption of a utility such as electricity, water or gas, the system comprising:
a user interface for allowing a user to schedule software downloads and software take effect times for the utility data collection devices;
a network interface for receiving software download configuration requests from the utility data collection devices and for communicating software download commands with the utility data collection devices;
a state machine component for recognizing the state of each of the utility data collection devices, wherein downloading of an update to a software program onto each of the utility data collection devices is dependent on the state of the utility data collection device as recognized by the state machine component; and
a database for storing information about the states of the utility data collection devices, wherein the states include:
a stable state representing that one of the utility data collection devices is running a known version of the software program,
a rollback state representing that one of the utility data collection devices is running an old version of the software program, and
an update state representing that one of the utility data collection devices is running a new version of the software program.
2. The system of claim 1
wherein the database stores information about at least a first group and at least a second group of the utility data collection devices;
wherein the utility data collection devices in the first and second groups are associated with the update and stable states, respectively;
wherein the state machine is configured to manage the first and second groups of utility data collection devices based on the update and stable states, respectively; and
wherein the state machine and database are configured to:
obtain a command, via the user interface, to add a new utility data collection device to the first group, wherein the new utility data collection device is running the current version of the software program; and
request the utility data collection devices in the first group to download and execute the new version of the software program, wherein only the new utility data collection device downloads and executes the new version of the software program in response thereto.
3. The system of claim 1
wherein the database stores information about at least first a first group and at least a second group of the utility data collection devices,
wherein the utility data collection devices in the first and second groups have different first and second states, respectively,
and wherein the state machine is configured to manage the first and second groups of utility data collection devices based on the first and second states, respectively.
4. A computer-readable medium whose contents cause at least one data aggregation and processing system, coupled to communicate with a network of intermediate data collectors, to perform a method to control the updating of software associated with the network of intermediate data collectors, the method comprising:
at the data aggregation and processing system, associating one of multiple states with each of the intermediate data collectors, wherein the intermediate data collectors are coupled to communicate with multiple data collection devices associated with utility metering devices, wherein the states relate to a software program running on the intermediate data collectors, and wherein the states include a stable state representing that one of the cell control units is running a known version of the software program; and
at the data aggregation and processing system, managing the states of each of the cell control units.
5. The computer-readable medium of claim 4 wherein the computer-readable medium is a memory of the telecommunications mobile device.
6. The computer-readable medium of claim 4 wherein the computer-readable medium is a logical node in a computer network receiving the contents.
7. The computer-readable medium of claim 4 wherein the computer-readable medium is a computer-readable disk.
8. The computer-readable medium of claim 4 wherein the computer-readable medium is a data transmission medium carrying a generated data signal containing the contents.
9. The computer-readable medium of claim 4 wherein the computer-readable medium is a memory of a computer system.
10. In a network of distributed embedded devices, an apparatus for downloading software from a central server having a software configuration management unit for controlling the condition and configuration of the distributed embedded devices, the apparatus comprising;
means for sending a configuration request to the central server, wherein the central server is associated with aggregating and collecting information for automatic meter reading in a utility meter reading system;
means for receiving a software download command from the central server, wherein the software download command is based on the sent configuration request and on a current condition of the apparatus as determined at the software configuration management unit; and
means for downloading the software from the central server to the distributed embedded devices.
11. A method for providing software for download to at least one of multiple utility data collection devices, then method comprising:
receiving a request from the utility data collection device;
determining a current condition of the utility data collection device; and
based on the received request and the determined current condition of the utility data collection devise, sending a software download command to the data collection device.
12. The method of claim 11, further comprising:
providing a rollback command to at least some of the multiple data collection devices in a group, wherein the rollback command instructs the data collection devices in the group to execute a locally stored prior version of software.
13. The system of claim 1 wherein running a different version of a software program onto each of the multiple utility data collection devices is dependent on the state of each of the utility data collection devices as recognized by the state machine component.
14. The computer-readable medium of claim 4 wherein the states further include a rollback state representing that one of the intermediate data collectors is running a old version of the software program.
15. The computer-readable medium of claim 4 wherein the states further include an update state representing that one of the intermediate data collectors is running a new version of the software program.
16. The apparatus of claim 10 wherein the apparatus concurrently controls the condition of more than one of the distributed embedded devices.
17. The apparatus of claim 10 wherein each of the distributed embedded devices collect utility meter information in a utility meter reading system.
18. The method of claim 11 wherein the software download command includes a list of software components.
19. The method of claim 11, further comprising:
prior to sending the software download command to the utility data collection device, updating the condition of the utility data collection device to a condition for downloading software.
20. The method of claim 11, further comprising sending information for download to the data collection device, wherein the sending of information for download does not does not interrupt normal operation of the data collection device.
21. A method for providing software for download to multiple data concentrator devices that collect meter data in a utility system, the method comprising;
receiving a request from a data concentrator device in a utility data collection network;
determining a current condition of the data concentrator device, wherein the current condition is related to software currently running on the data concentrator device;
based on the received request and the determined current condition of the data concentrator device, sending a software download command to the data concentrator device; and
facilitating the download of software at the data concentrator device, wherein the download of software at the data concentrator device does not hinder the scheduled operation of the data concentrator device, including the collection and transmittal of data at the data concentrator device.
US10/570,779 2003-09-05 2003-09-05 Synchronizing and controlling software downloads, such as for utility meter-reading data collection and processing Abandoned US20070169075A1 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2003/027738 WO2005033964A1 (en) 2003-09-05 2003-09-05 Synchronizing and controlling software downloads, such as for utility meter-reading data collection and processing

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2003/027738 A-371-Of-International WO2005033964A1 (en) 2003-09-05 2003-09-05 Synchronizing and controlling software downloads, such as for utility meter-reading data collection and processing

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/543,600 Continuation US9128880B2 (en) 2003-09-05 2014-11-17 Synchronizing and controlling software downloads, such as for utility meter-reading data collection and processing

Publications (1)

Publication Number Publication Date
US20070169075A1 true US20070169075A1 (en) 2007-07-19

Family

ID=34421176

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/570,779 Abandoned US20070169075A1 (en) 2003-09-05 2003-09-05 Synchronizing and controlling software downloads, such as for utility meter-reading data collection and processing
US14/543,600 Expired - Lifetime US9128880B2 (en) 2003-09-05 2014-11-17 Synchronizing and controlling software downloads, such as for utility meter-reading data collection and processing

Family Applications After (1)

Application Number Title Priority Date Filing Date
US14/543,600 Expired - Lifetime US9128880B2 (en) 2003-09-05 2014-11-17 Synchronizing and controlling software downloads, such as for utility meter-reading data collection and processing

Country Status (4)

Country Link
US (2) US20070169075A1 (en)
AU (1) AU2003270322A1 (en)
CA (1) CA2537910C (en)
WO (1) WO2005033964A1 (en)

Cited By (79)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050132348A1 (en) * 2003-12-15 2005-06-16 Meulemans Michael E. System and method for managing and communicating software updates
US20050132351A1 (en) * 2003-12-12 2005-06-16 Randall Roderick K. Updating electronic device software employing rollback
US20060171377A1 (en) * 2005-02-03 2006-08-03 Xerox Corporation Automated remote device meter reading
US20060264206A1 (en) * 2003-05-28 2006-11-23 Nec Corporation Mobile communication system, server, portable terminal and data transfer method used for it
US20080109537A1 (en) * 2006-11-03 2008-05-08 Smartsynch, Inc. Systems and Methods For Auto-Configuration of a Generic Data Device on a Wireless Network
US20080195562A1 (en) * 2007-02-09 2008-08-14 Poweronedata Corporation Automated meter reading system
US20080250405A1 (en) * 2007-04-03 2008-10-09 Microsoft Corporation Parallel installation
US20080301665A1 (en) * 2007-05-30 2008-12-04 Steven Charlton Architecture for field upgrade of a health monitoring system
WO2009067258A1 (en) * 2007-11-25 2009-05-28 Trilliant Networks, Inc. Upgrade process system and method
US20100079793A1 (en) * 2008-09-29 2010-04-01 Canon Kabushiki Kaisha System, server, image forming apparatus, system control method, and storage medium
US20110214021A1 (en) * 2010-02-26 2011-09-01 Seth Kelby Vidal Systems and methods for initiating software repairs in conjunction with software package updates
US20110214112A1 (en) * 2010-02-26 2011-09-01 Seth Kelby Vidal Systems and mehtods for generating predictive diagnostics via package update manager
US20110214116A1 (en) * 2010-02-26 2011-09-01 Seth Kelby Vidal Systems and methods for managing software package updates using communication pipes
US20110214118A1 (en) * 2010-02-26 2011-09-01 James Antill Systems and methods for generating and storing translation information as package metadata
US20110214018A1 (en) * 2010-02-26 2011-09-01 Seth Kelby Vidal Systems and methods for diagnostic notification via package update manager
US20110271267A1 (en) * 2010-04-29 2011-11-03 International Business Machines Corporation Updating elements in data storage facility using predefined state machine over extended time period
US20120011494A1 (en) * 2010-07-07 2012-01-12 Canon Kabushiki Kaisha Information processing apparatus, method for controlling the same, and storage medium
US8138934B2 (en) 2007-11-25 2012-03-20 Trilliant Networks, Inc. System and method for false alert filtering of event messages within a network
US8144596B2 (en) 2007-11-25 2012-03-27 Trilliant Networks, Inc. Communication and message route optimization and messaging in a mesh network
US8171364B2 (en) 2007-11-25 2012-05-01 Trilliant Networks, Inc. System and method for power outage and restoration notification in an advanced metering infrastructure network
US8289182B2 (en) 2008-11-21 2012-10-16 Trilliant Networks, Inc. Methods and systems for virtual energy management display
US8319658B2 (en) 2009-03-11 2012-11-27 Trilliant Networks, Inc. Process, device and system for mapping transformers to meters and locating non-technical line losses
US8332055B2 (en) 2007-11-25 2012-12-11 Trilliant Networks, Inc. Energy use control system and method
US8334787B2 (en) 2007-10-25 2012-12-18 Trilliant Networks, Inc. Gas meter having ultra-sensitive magnetic material retrofitted onto meter dial and method for performing meter retrofit
US8381036B2 (en) 2010-05-26 2013-02-19 Red Hat, Inc. Systems and methods for restoring machine state history related to detected faults in package update process
US8429256B2 (en) 2010-05-28 2013-04-23 Red Hat, Inc. Systems and methods for generating cached representations of host package inventories in remote package repositories
US20130117740A1 (en) * 2011-11-07 2013-05-09 Lsis Co., Ltd. Apparatus, system and method for upgrading firmware of energy metering device
US8458312B2 (en) 2006-03-16 2013-06-04 Us Beverage Net Inc. Distributed intelligent systems and methods therefor
US20130151672A1 (en) * 2011-12-13 2013-06-13 Samsung Electronics Co., Ltd. Cloud computing method, computing apparatus and server using the same
US8468515B2 (en) 2000-11-17 2013-06-18 Hewlett-Packard Development Company, L.P. Initialization and update of software and/or firmware in electronic devices
US8479189B2 (en) 2000-11-17 2013-07-02 Hewlett-Packard Development Company, L.P. Pattern detection preprocessor in an electronic device update generation system
US8502640B2 (en) 2007-11-25 2013-08-06 Trilliant Networks, Inc. System and method for transmitting and receiving information on a neighborhood area network
US8510596B1 (en) * 2006-02-09 2013-08-13 Virsec Systems, Inc. System and methods for run time detection and correction of memory corruption
US8526940B1 (en) 2004-08-17 2013-09-03 Palm, Inc. Centralized rules repository for smart phone customer care
US8555273B1 (en) * 2003-09-17 2013-10-08 Palm. Inc. Network for updating electronic devices
US8578361B2 (en) 2004-04-21 2013-11-05 Palm, Inc. Updating an electronic device with update agent code
US8699377B2 (en) 2008-09-04 2014-04-15 Trilliant Networks, Inc. System and method for implementing mesh network communications using a mesh network protocol
US8713558B2 (en) 2010-09-01 2014-04-29 Red Hat, Inc. Generating package profiles in software package repositories using selective subsets of packages
US8752044B2 (en) 2006-07-27 2014-06-10 Qualcomm Incorporated User experience and dependency management in a mobile device
US8762931B2 (en) 2010-05-26 2014-06-24 Red Hat, Inc. Generating an encoded package profile
US20140222510A1 (en) * 2012-06-12 2014-08-07 Sensity Systems, Inc. Lighting Infrastructure and Revenue Model
US8806471B2 (en) 2010-09-28 2014-08-12 Red Hat, Inc. Upgrade and downgrade in package update operations
US8806477B2 (en) 2009-10-30 2014-08-12 Red Hat, Inc. Space efficient software package management
US8832428B2 (en) 2010-11-15 2014-09-09 Trilliant Holdings Inc. System and method for securely communicating across multiple networks using a single radio
US8856323B2 (en) 2011-02-10 2014-10-07 Trilliant Holdings, Inc. Device and method for facilitating secure communications over a cellular network
US8856953B2 (en) 2010-09-01 2014-10-07 Red Hat, Inc. Access policy for package update processes
US8893110B2 (en) 2006-06-08 2014-11-18 Qualcomm Incorporated Device management in a network
US20140358482A1 (en) * 2013-05-31 2014-12-04 Itron, Inc. Distributed applications across platforms
US20140359595A1 (en) * 2013-05-31 2014-12-04 Itron, Inc. Surfacing cross platform applications
US8925818B2 (en) 2007-08-16 2015-01-06 Hand Held Products, Inc. Data collection system having EIR terminal interface node
US8970394B2 (en) 2011-01-25 2015-03-03 Trilliant Holdings Inc. Aggregated real-time power outages/restoration reporting (RTPOR) in a secure mesh network
US9001787B1 (en) 2011-09-20 2015-04-07 Trilliant Networks Inc. System and method for implementing handover of a hybrid communications module
US9003400B2 (en) 2010-11-29 2015-04-07 Red Hat, Inc. Tracking computing systems utilizing software repositories
US9003389B2 (en) 2010-05-25 2015-04-07 Red Hat, Inc. Generating an encoded package profile based on executing host processes
US9013173B2 (en) 2010-09-13 2015-04-21 Trilliant Networks, Inc. Process for detecting energy theft
US9041349B2 (en) 2011-03-08 2015-05-26 Trilliant Networks, Inc. System and method for managing load distribution across a power grid
US9084120B2 (en) 2010-08-27 2015-07-14 Trilliant Networks Inc. System and method for interference free operation of co-located transceivers
US20160004607A1 (en) * 2013-03-18 2016-01-07 Fujitsu Limited Information processing apparatus and information processing method
US9239715B1 (en) * 2013-09-25 2016-01-19 Amazon Technologies, Inc. Cancel and rollback update stack requests
US9282383B2 (en) 2011-01-14 2016-03-08 Trilliant Incorporated Process, device and system for volt/VAR optimization
US9367302B2 (en) 2010-05-27 2016-06-14 Red Hat, Inc. Generating client qualification to execute package update manager
US9417865B2 (en) 2010-05-28 2016-08-16 Red Hat, Inc. Determining when to update a package manager software
US9762399B2 (en) 2010-07-15 2017-09-12 The Research Foundation For The State University Of New York System and method for validating program execution at run-time using control flow signatures
US9772834B2 (en) 2010-04-27 2017-09-26 Red Hat, Inc. Exportable encoded identifications of networked machines
US9792429B2 (en) 2010-10-06 2017-10-17 Red Hat, Inc. Detection of malicious software packages
US9959113B2 (en) 2011-03-01 2018-05-01 Red Hat, Inc. Managing versions of software packages
US10079841B2 (en) 2013-09-12 2018-09-18 Virsec Systems, Inc. Automated runtime detection of malware
US10089476B1 (en) 2014-06-03 2018-10-02 Amazon Technologies, Inc. Compartments
US10114726B2 (en) 2014-06-24 2018-10-30 Virsec Systems, Inc. Automated root cause analysis of single or N-tiered application
US10354074B2 (en) 2014-06-24 2019-07-16 Virsec Systems, Inc. System and methods for automated detection of input and output validation and resource management vulnerability
US10402273B2 (en) * 2016-12-14 2019-09-03 Microsoft Technology Licensing, Llc IoT device update failure recovery
US10416991B2 (en) 2016-12-14 2019-09-17 Microsoft Technology Licensing, Llc Secure IoT device update
US10481943B2 (en) * 2016-12-30 2019-11-19 Winmore, Inc. System and method for state machine management
US10516667B1 (en) 2014-06-03 2019-12-24 Amazon Technologies, Inc. Hidden compartments
US10715526B2 (en) 2016-12-14 2020-07-14 Microsoft Technology Licensing, Llc Multiple cores with hierarchy of trust
US20210405984A1 (en) * 2020-06-30 2021-12-30 Paypal, Inc. Computer Model Management System
US11328344B2 (en) 2013-05-31 2022-05-10 Itron, Inc. Utility application delivery platform
US11409870B2 (en) 2016-06-16 2022-08-09 Virsec Systems, Inc. Systems and methods for remediating memory corruption in a computer application
US11582101B2 (en) * 2013-03-29 2023-02-14 Hewlett Packard Enterprise Development Lp Update of programmable for computing nodes

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7583203B2 (en) 2005-11-28 2009-09-01 Elster Electricity, Llc Programming electronic meter settings using a bandwidth limited communications channel
US7752145B2 (en) 2006-02-14 2010-07-06 Panasonic Corporation Consumer-sited power management system and method
EP2075693A1 (en) * 2008-07-22 2009-07-01 Siemens Aktiengesellschaft Automation device and method for actualising files on an automation device
US9818073B2 (en) 2009-07-17 2017-11-14 Honeywell International Inc. Demand response management system
US9124535B2 (en) 2009-07-17 2015-09-01 Honeywell International Inc. System for using attributes to deploy demand response resources
US9137050B2 (en) 2009-07-17 2015-09-15 Honeywell International Inc. Demand response system incorporating a graphical processing unit
US8782190B2 (en) 2009-07-17 2014-07-15 Honeywell International, Inc. Demand response management system
US9153001B2 (en) 2011-01-28 2015-10-06 Honeywell International Inc. Approach for managing distribution of automated demand response events in a multi-site enterprise
US8621123B2 (en) 2011-10-06 2013-12-31 Honeywell International Inc. Device management using virtual interfaces
US8539123B2 (en) 2011-10-06 2013-09-17 Honeywell International, Inc. Device management using a dedicated management interface
US20140081704A1 (en) 2012-09-15 2014-03-20 Honeywell International Inc. Decision support system based on energy markets
US9389850B2 (en) 2012-11-29 2016-07-12 Honeywell International Inc. System and approach to manage versioning of field devices in a multi-site enterprise
US9989937B2 (en) 2013-07-11 2018-06-05 Honeywell International Inc. Predicting responses of resources to demand response signals and having comfortable demand responses
US10346931B2 (en) 2013-07-11 2019-07-09 Honeywell International Inc. Arrangement for communicating demand response resource incentives
US9691076B2 (en) 2013-07-11 2017-06-27 Honeywell International Inc. Demand response system having a participation predictor
US9830141B2 (en) 2013-12-23 2017-11-28 Google Llc Providing a software update to computing devices on the same network
US9665078B2 (en) 2014-03-25 2017-05-30 Honeywell International Inc. System for propagating messages for purposes of demand response
US11204749B2 (en) * 2016-09-20 2021-12-21 Apple Inc. State machines for installation management
US10007582B2 (en) 2016-09-27 2018-06-26 International Business Machines Corporation Rebuild rollback support in distributed SDS systems
US10693720B2 (en) 2017-04-10 2020-06-23 Cisco Technology, Inc. Distribution of updates in an IoT network
US10541556B2 (en) 2017-04-27 2020-01-21 Honeywell International Inc. System and approach to integrate and manage diverse demand response specifications for multi-site enterprises
JP7371585B2 (en) * 2020-07-28 2023-10-31 トヨタ自動車株式会社 Software update device, update control method, update control program and server

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6308061B1 (en) * 1996-08-07 2001-10-23 Telxon Corporation Wireless software upgrades with version control
US20020158774A1 (en) * 1990-02-15 2002-10-31 Itron, Inc. Radio communication network for collecting data from utility meters
US20030126159A1 (en) * 2001-12-28 2003-07-03 Nwafor John I. Method and system for rollback of software system upgrade
US20050228798A1 (en) * 2004-03-12 2005-10-13 Microsoft Corporation Tag-based schema for distributing update metadata in an update distribution system
US6976062B1 (en) * 1999-09-22 2005-12-13 Intermec Ip Corp. Automated software upgrade utility
US20060103549A1 (en) * 2002-04-15 2006-05-18 Hunt Power, L.P. User-installable power consumption monitoring system

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6631247B1 (en) * 1999-09-29 2003-10-07 Ricoh Co., Ltd. Method and system for remote diagnostic, control and information collection based on various communication modes for sending messages to a resource manager
US5963650A (en) * 1997-05-01 1999-10-05 Simionescu; Dan Method and apparatus for a customizable low power RF telemetry system with high performance reduced data rate
US6618709B1 (en) * 1998-04-03 2003-09-09 Enerwise Global Technologies, Inc. Computer assisted and/or implemented process and architecture for web-based monitoring of energy related usage, and client accessibility therefor
US6437692B1 (en) * 1998-06-22 2002-08-20 Statsignal Systems, Inc. System and method for monitoring and controlling remote devices
US6438749B1 (en) * 1999-03-03 2002-08-20 Microsoft Corporation Method and system for restoring a computer to its original state after an unsuccessful patch installation attempt
EP1118003A4 (en) 1999-06-30 2003-08-13 Gen Electric Methods and apparatus for defining meter data calculations in an electronic electricity meter
US6710721B1 (en) * 1999-10-16 2004-03-23 Datamatic Inc. Radio frequency automated meter reading device
US6993760B2 (en) * 2001-12-05 2006-01-31 Microsoft Corporation Installing software on a mobile computing device using the rollback and security features of a configuration manager
US8776018B2 (en) * 2008-01-11 2014-07-08 International Business Machines Corporation System and method for restartable provisioning of software components

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020158774A1 (en) * 1990-02-15 2002-10-31 Itron, Inc. Radio communication network for collecting data from utility meters
US6308061B1 (en) * 1996-08-07 2001-10-23 Telxon Corporation Wireless software upgrades with version control
US6976062B1 (en) * 1999-09-22 2005-12-13 Intermec Ip Corp. Automated software upgrade utility
US20030126159A1 (en) * 2001-12-28 2003-07-03 Nwafor John I. Method and system for rollback of software system upgrade
US20060103549A1 (en) * 2002-04-15 2006-05-18 Hunt Power, L.P. User-installable power consumption monitoring system
US20050228798A1 (en) * 2004-03-12 2005-10-13 Microsoft Corporation Tag-based schema for distributing update metadata in an update distribution system

Cited By (133)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8468515B2 (en) 2000-11-17 2013-06-18 Hewlett-Packard Development Company, L.P. Initialization and update of software and/or firmware in electronic devices
US8479189B2 (en) 2000-11-17 2013-07-02 Hewlett-Packard Development Company, L.P. Pattern detection preprocessor in an electronic device update generation system
US20060264206A1 (en) * 2003-05-28 2006-11-23 Nec Corporation Mobile communication system, server, portable terminal and data transfer method used for it
US7653680B2 (en) * 2003-05-28 2010-01-26 Nec Corporation Mobile software distribution system, server, terminal and method
US8555273B1 (en) * 2003-09-17 2013-10-08 Palm. Inc. Network for updating electronic devices
US20050132351A1 (en) * 2003-12-12 2005-06-16 Randall Roderick K. Updating electronic device software employing rollback
US20050132348A1 (en) * 2003-12-15 2005-06-16 Meulemans Michael E. System and method for managing and communicating software updates
US7574706B2 (en) * 2003-12-15 2009-08-11 Microsoft Corporation System and method for managing and communicating software updates
US8578361B2 (en) 2004-04-21 2013-11-05 Palm, Inc. Updating an electronic device with update agent code
US8526940B1 (en) 2004-08-17 2013-09-03 Palm, Inc. Centralized rules repository for smart phone customer care
US20060171377A1 (en) * 2005-02-03 2006-08-03 Xerox Corporation Automated remote device meter reading
US8510596B1 (en) * 2006-02-09 2013-08-13 Virsec Systems, Inc. System and methods for run time detection and correction of memory corruption
US8966312B1 (en) 2006-02-09 2015-02-24 Virsec Systems, Inc. System and methods for run time detection and correction of memory corruption
US11599634B1 (en) 2006-02-09 2023-03-07 Virsec Systems, Inc. System and methods for run time detection and correction of memory corruption
US10331888B1 (en) 2006-02-09 2019-06-25 Virsec Systems, Inc. System and methods for run time detection and correction of memory corruption
US8458312B2 (en) 2006-03-16 2013-06-04 Us Beverage Net Inc. Distributed intelligent systems and methods therefor
US8893110B2 (en) 2006-06-08 2014-11-18 Qualcomm Incorporated Device management in a network
US9081638B2 (en) 2006-07-27 2015-07-14 Qualcomm Incorporated User experience and dependency management in a mobile device
US8752044B2 (en) 2006-07-27 2014-06-10 Qualcomm Incorporated User experience and dependency management in a mobile device
US8010640B2 (en) * 2006-11-03 2011-08-30 Smartsynch, Inc. Systems and methods for auto-configuration of a generic data device coupled to a utility meter on a wireless network
US20080109537A1 (en) * 2006-11-03 2008-05-08 Smartsynch, Inc. Systems and Methods For Auto-Configuration of a Generic Data Device on a Wireless Network
US8739148B2 (en) * 2007-02-09 2014-05-27 Elster Electricity, Llc Automated meter reading system
US20080195562A1 (en) * 2007-02-09 2008-08-14 Poweronedata Corporation Automated meter reading system
US8484637B2 (en) * 2007-04-03 2013-07-09 Microsoft Corporation Parallel installation
US20080250405A1 (en) * 2007-04-03 2008-10-09 Microsoft Corporation Parallel installation
US8978026B2 (en) * 2007-05-30 2015-03-10 Bayer Healthcare Llc Architecture for field upgrade of a health monitoring system
US10176888B2 (en) 2007-05-30 2019-01-08 Ascensia Diabetes Care Holdings Ag Architecture for field upgrade of a health monitoring system
US20080301665A1 (en) * 2007-05-30 2008-12-04 Steven Charlton Architecture for field upgrade of a health monitoring system
US9471098B2 (en) 2007-05-30 2016-10-18 Ascensia Diabetes Care Holdings Ag Architecture for field upgrade of a health monitoring system
US9258188B2 (en) 2007-08-16 2016-02-09 Hand Held Products, Inc. Data collection system having EIR terminal interface node
US9509801B2 (en) 2007-08-16 2016-11-29 Hand Held Products, Inc. Data collection system having EIR terminal interface node
US9929906B2 (en) 2007-08-16 2018-03-27 Hand Held Products, Inc. Data collection system having EIR terminal interface node
US8925818B2 (en) 2007-08-16 2015-01-06 Hand Held Products, Inc. Data collection system having EIR terminal interface node
US8334787B2 (en) 2007-10-25 2012-12-18 Trilliant Networks, Inc. Gas meter having ultra-sensitive magnetic material retrofitted onto meter dial and method for performing meter retrofit
EP2215545A1 (en) * 2007-11-25 2010-08-11 Trilliant Networks, Inc. Upgrade process system and method
US8370697B2 (en) 2007-11-25 2013-02-05 Trilliant Networks, Inc. System and method for power outage and restoration notification in an advanced metering infrastructure network
US8171364B2 (en) 2007-11-25 2012-05-01 Trilliant Networks, Inc. System and method for power outage and restoration notification in an advanced metering infrastructure network
US8144596B2 (en) 2007-11-25 2012-03-27 Trilliant Networks, Inc. Communication and message route optimization and messaging in a mesh network
US8138934B2 (en) 2007-11-25 2012-03-20 Trilliant Networks, Inc. System and method for false alert filtering of event messages within a network
US8502640B2 (en) 2007-11-25 2013-08-06 Trilliant Networks, Inc. System and method for transmitting and receiving information on a neighborhood area network
WO2009067258A1 (en) * 2007-11-25 2009-05-28 Trilliant Networks, Inc. Upgrade process system and method
US8725274B2 (en) 2007-11-25 2014-05-13 Trilliant Networks, Inc. Energy use control system and method
EP2215545A4 (en) * 2007-11-25 2011-04-20 Trilliant Networks Inc Upgrade process system and method
US8332055B2 (en) 2007-11-25 2012-12-11 Trilliant Networks, Inc. Energy use control system and method
US8699377B2 (en) 2008-09-04 2014-04-15 Trilliant Networks, Inc. System and method for implementing mesh network communications using a mesh network protocol
US9621457B2 (en) 2008-09-04 2017-04-11 Trilliant Networks, Inc. System and method for implementing mesh network communications using a mesh network protocol
JP2010086069A (en) * 2008-09-29 2010-04-15 Canon Inc System, server, image forming apparatus, system control method, program and recording medium
US8804168B2 (en) * 2008-09-29 2014-08-12 Canon Kabushiki Kaisha System, server, image forming apparatus, system control method, and storage medium
US20100079793A1 (en) * 2008-09-29 2010-04-01 Canon Kabushiki Kaisha System, server, image forming apparatus, system control method, and storage medium
US8289182B2 (en) 2008-11-21 2012-10-16 Trilliant Networks, Inc. Methods and systems for virtual energy management display
US8319658B2 (en) 2009-03-11 2012-11-27 Trilliant Networks, Inc. Process, device and system for mapping transformers to meters and locating non-technical line losses
US9189822B2 (en) 2009-03-11 2015-11-17 Trilliant Networks, Inc. Process, device and system for mapping transformers to meters and locating non-technical line losses
US8806477B2 (en) 2009-10-30 2014-08-12 Red Hat, Inc. Space efficient software package management
US20110214112A1 (en) * 2010-02-26 2011-09-01 Seth Kelby Vidal Systems and mehtods for generating predictive diagnostics via package update manager
US20110214116A1 (en) * 2010-02-26 2011-09-01 Seth Kelby Vidal Systems and methods for managing software package updates using communication pipes
US20110214021A1 (en) * 2010-02-26 2011-09-01 Seth Kelby Vidal Systems and methods for initiating software repairs in conjunction with software package updates
US10534624B2 (en) 2010-02-26 2020-01-14 Red Hat, Inc. Generating and storing translation information as package metadata
US10824521B2 (en) 2010-02-26 2020-11-03 Red Hat, Inc. Generating predictive diagnostics via package update manager
US9092295B2 (en) 2010-02-26 2015-07-28 Red Hat, Inc. Managing software package updates using communication pipes
US8209564B2 (en) * 2010-02-26 2012-06-26 Red Hat, Inc. Systems and methods for initiating software repairs in conjunction with software package updates
US9116802B2 (en) 2010-02-26 2015-08-25 Red Hat, Inc. Diagnostic notification via package update manager
US20110214118A1 (en) * 2010-02-26 2011-09-01 James Antill Systems and methods for generating and storing translation information as package metadata
US20110214018A1 (en) * 2010-02-26 2011-09-01 Seth Kelby Vidal Systems and methods for diagnostic notification via package update manager
US9152484B2 (en) 2010-02-26 2015-10-06 Red Hat, Inc. Generating predictive diagnostics via package update manager
US9772834B2 (en) 2010-04-27 2017-09-26 Red Hat, Inc. Exportable encoded identifications of networked machines
US20110271267A1 (en) * 2010-04-29 2011-11-03 International Business Machines Corporation Updating elements in data storage facility using predefined state machine over extended time period
US8959505B2 (en) * 2010-04-29 2015-02-17 International Business Machines Corporation Updating elements in data storage facility using predefined state machine over extended time period
US9600265B2 (en) 2010-04-29 2017-03-21 International Business Machines Corporation Updating elements in data storage facility using predefined state machine over extended time period
US8881134B2 (en) * 2010-04-29 2014-11-04 International Business Machines Corporation Updating elements in data storage facility using predefined state machine over extended time period
US20120222026A1 (en) * 2010-04-29 2012-08-30 International Business Machines Corporation Updating elements in data storage facility using predefined state machine over extended time period
US9003389B2 (en) 2010-05-25 2015-04-07 Red Hat, Inc. Generating an encoded package profile based on executing host processes
US8381036B2 (en) 2010-05-26 2013-02-19 Red Hat, Inc. Systems and methods for restoring machine state history related to detected faults in package update process
US8762931B2 (en) 2010-05-26 2014-06-24 Red Hat, Inc. Generating an encoded package profile
US9367302B2 (en) 2010-05-27 2016-06-14 Red Hat, Inc. Generating client qualification to execute package update manager
US8429256B2 (en) 2010-05-28 2013-04-23 Red Hat, Inc. Systems and methods for generating cached representations of host package inventories in remote package repositories
US9417865B2 (en) 2010-05-28 2016-08-16 Red Hat, Inc. Determining when to update a package manager software
US8799887B2 (en) * 2010-07-07 2014-08-05 Canon Kabushiki Kaisha Information processing apparatus, method for controlling the same, and storage medium
US20120011494A1 (en) * 2010-07-07 2012-01-12 Canon Kabushiki Kaisha Information processing apparatus, method for controlling the same, and storage medium
US9762399B2 (en) 2010-07-15 2017-09-12 The Research Foundation For The State University Of New York System and method for validating program execution at run-time using control flow signatures
US9084120B2 (en) 2010-08-27 2015-07-14 Trilliant Networks Inc. System and method for interference free operation of co-located transceivers
US8713558B2 (en) 2010-09-01 2014-04-29 Red Hat, Inc. Generating package profiles in software package repositories using selective subsets of packages
US8856953B2 (en) 2010-09-01 2014-10-07 Red Hat, Inc. Access policy for package update processes
US9013173B2 (en) 2010-09-13 2015-04-21 Trilliant Networks, Inc. Process for detecting energy theft
US8806471B2 (en) 2010-09-28 2014-08-12 Red Hat, Inc. Upgrade and downgrade in package update operations
US9792429B2 (en) 2010-10-06 2017-10-17 Red Hat, Inc. Detection of malicious software packages
US10055576B2 (en) 2010-10-06 2018-08-21 Red Hat, Inc. Detection of malicious software packages
US8832428B2 (en) 2010-11-15 2014-09-09 Trilliant Holdings Inc. System and method for securely communicating across multiple networks using a single radio
US9003400B2 (en) 2010-11-29 2015-04-07 Red Hat, Inc. Tracking computing systems utilizing software repositories
US9282383B2 (en) 2011-01-14 2016-03-08 Trilliant Incorporated Process, device and system for volt/VAR optimization
US8970394B2 (en) 2011-01-25 2015-03-03 Trilliant Holdings Inc. Aggregated real-time power outages/restoration reporting (RTPOR) in a secure mesh network
US8856323B2 (en) 2011-02-10 2014-10-07 Trilliant Holdings, Inc. Device and method for facilitating secure communications over a cellular network
US9959113B2 (en) 2011-03-01 2018-05-01 Red Hat, Inc. Managing versions of software packages
US9041349B2 (en) 2011-03-08 2015-05-26 Trilliant Networks, Inc. System and method for managing load distribution across a power grid
US9001787B1 (en) 2011-09-20 2015-04-07 Trilliant Networks Inc. System and method for implementing handover of a hybrid communications module
US20130117740A1 (en) * 2011-11-07 2013-05-09 Lsis Co., Ltd. Apparatus, system and method for upgrading firmware of energy metering device
US9235405B2 (en) * 2011-11-07 2016-01-12 Lsis Co., Ltd. Apparatus, system and method for upgrading firmware of energy metering device
US20130151672A1 (en) * 2011-12-13 2013-06-13 Samsung Electronics Co., Ltd. Cloud computing method, computing apparatus and server using the same
US9253228B2 (en) * 2011-12-13 2016-02-02 Samsung Electronics Co., Ltd. Cloud computing method, computing apparatus and server using the same
US9965813B2 (en) 2012-06-12 2018-05-08 Sensity Systems Inc. Lighting infrastructure and revenue model
US20170103474A1 (en) * 2012-06-12 2017-04-13 Sensity Systems Inc. Lighting infrastructure and revenue model
US10290065B2 (en) 2012-06-12 2019-05-14 Verizon Patent And Licensing Inc. Lighting infrastructure and revenue model
US20140222510A1 (en) * 2012-06-12 2014-08-07 Sensity Systems, Inc. Lighting Infrastructure and Revenue Model
US20160004607A1 (en) * 2013-03-18 2016-01-07 Fujitsu Limited Information processing apparatus and information processing method
US11582101B2 (en) * 2013-03-29 2023-02-14 Hewlett Packard Enterprise Development Lp Update of programmable for computing nodes
JP2016527596A (en) * 2013-05-31 2016-09-08 アイトロン インコーポレイテッド Distributed application through the platform
US20140358482A1 (en) * 2013-05-31 2014-12-04 Itron, Inc. Distributed applications across platforms
US20140359595A1 (en) * 2013-05-31 2014-12-04 Itron, Inc. Surfacing cross platform applications
US11328344B2 (en) 2013-05-31 2022-05-10 Itron, Inc. Utility application delivery platform
US9342288B2 (en) * 2013-05-31 2016-05-17 Itron, Inc. Surfacing cross platform applications
US10198254B2 (en) 2013-05-31 2019-02-05 Itron, Inc. Surfacing cross platform applications
US10205769B2 (en) * 2013-05-31 2019-02-12 Itron, Inc. Distributed applications across platforms
US10079841B2 (en) 2013-09-12 2018-09-18 Virsec Systems, Inc. Automated runtime detection of malware
US11146572B2 (en) 2013-09-12 2021-10-12 Virsec Systems, Inc. Automated runtime detection of malware
US9239715B1 (en) * 2013-09-25 2016-01-19 Amazon Technologies, Inc. Cancel and rollback update stack requests
US11526342B2 (en) 2013-09-25 2022-12-13 Amazon Technologies, Inc. Cancel and rollback update stack requests
US10127028B2 (en) 2013-09-25 2018-11-13 Amazon Technologies, Inc. Cancel and rollback update stack requests
US11687661B2 (en) 2014-06-03 2023-06-27 Amazon Technologies, Inc. Compartments
US10516667B1 (en) 2014-06-03 2019-12-24 Amazon Technologies, Inc. Hidden compartments
US10089476B1 (en) 2014-06-03 2018-10-02 Amazon Technologies, Inc. Compartments
US10977377B2 (en) 2014-06-03 2021-04-13 Amazon Technologies, Inc. Parent and child account compartments
US11113407B2 (en) 2014-06-24 2021-09-07 Virsec Systems, Inc. System and methods for automated detection of input and output validation and resource management vulnerability
US10354074B2 (en) 2014-06-24 2019-07-16 Virsec Systems, Inc. System and methods for automated detection of input and output validation and resource management vulnerability
US10114726B2 (en) 2014-06-24 2018-10-30 Virsec Systems, Inc. Automated root cause analysis of single or N-tiered application
US11409870B2 (en) 2016-06-16 2022-08-09 Virsec Systems, Inc. Systems and methods for remediating memory corruption in a computer application
US11106537B2 (en) * 2016-12-14 2021-08-31 Microsoft Technology Licensing, Llc IoT device update failure recovery
US10936303B2 (en) * 2016-12-14 2021-03-02 Microsoft Technology Licensing, Llc Secure IoT device update
US10402273B2 (en) * 2016-12-14 2019-09-03 Microsoft Technology Licensing, Llc IoT device update failure recovery
US10715526B2 (en) 2016-12-14 2020-07-14 Microsoft Technology Licensing, Llc Multiple cores with hierarchy of trust
US20200012492A1 (en) * 2016-12-14 2020-01-09 Microsoft Technology Licensing, Llc Secure iot device update
US10416991B2 (en) 2016-12-14 2019-09-17 Microsoft Technology Licensing, Llc Secure IoT device update
US10481943B2 (en) * 2016-12-30 2019-11-19 Winmore, Inc. System and method for state machine management
US20210405984A1 (en) * 2020-06-30 2021-12-30 Paypal, Inc. Computer Model Management System
US11816461B2 (en) * 2020-06-30 2023-11-14 Paypal, Inc. Computer model management system

Also Published As

Publication number Publication date
AU2003270322A1 (en) 2005-04-21
WO2005033964A1 (en) 2005-04-14
CA2537910C (en) 2012-11-06
CA2537910A1 (en) 2005-04-14
US9128880B2 (en) 2015-09-08
US20150067670A1 (en) 2015-03-05

Similar Documents

Publication Publication Date Title
US9128880B2 (en) Synchronizing and controlling software downloads, such as for utility meter-reading data collection and processing
US10284925B2 (en) Meter device
US8447868B2 (en) Method for extending business systems to a mobile workforce
US20070043849A1 (en) Field data collection and processing system, such as for electric, gas, and water utility data
US8606891B2 (en) Client processor device for building application files from file fragments for different versions of an application
US20120198434A1 (en) Virtual bundling of remote device firmware upgrade
AU2011244901B2 (en) Client processor device
AU2016202559B2 (en) A meter device

Legal Events

Date Code Title Description
AS Assignment

Owner name: ITRON, INC., WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LILL, DAVID;BENSON, ERIC;JESPERSEN, JAMES;REEL/FRAME:018835/0610;SIGNING DATES FROM 20060331 TO 20060403

AS Assignment

Owner name: WELLS FARGO BANK, NATIONAL ASSOCIATION, WASHINGTON

Free format text: SECURITY AGREEMENT;ASSIGNOR:ITRON, INC.;REEL/FRAME:026761/0069

Effective date: 20110805

STCB Information on status: application discontinuation

Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION