Enabling isolation development mode in utility endpoints

Abstract

Techniques for software development on utility devices are disclosed. In an example, a utility device transitions to an isolated development mode in response to verifying a manufacturer signature. While in the isolated development mode, the utility device is restricted from joining a network and receiving an application from a development computing system. The utility device verifies a network signature and transitions to a network test mode. While in the network test mode, the utility device joins the network, registers with a headend system via the network, and executes the application. After a threshold amount of time elapses, the utility device transitions to the isolated development mode.

Description

Technical Field

[0001] This invention relates generally to resource distribution systems, and more specifically to the software development of applications running on utility equipment within resource distribution systems. Background Technology

[0002] Modern resource distribution systems use interconnected networks of utility devices (such as utility meters) to collect consumption and other data, and propagate the data to a central system for billing and other purposes. Each utility device is typically connected to a communications network (e.g., a wireless mesh network). In some cases, utility devices may run custom application software. Summary of the Invention

[0003] Certain aspects and features include techniques for software development for applications running on utility devices such as utility meters. In one aspect, a utility device includes one or more processors. The utility device is configured to operate in one or more of the following modes: endpoint mode, isolated development mode, and network test mode. When in endpoint mode, the utility device is configured to communicate with other devices on the network. When in endpoint mode, the utility device is also configured to access manufacturer signatures and network signatures. When in endpoint mode, the utility device is also configured to verify a manufacturer signature against a reference manufacturer signature. When in endpoint mode, the utility device is also configured to switch to isolated development mode in response to verifying the manufacturer signature. When in isolated development mode, the utility device is restricted from joining the network and is configured to receive applications from a development computing system via a development port. When in isolated development mode, the utility device is also configured to execute applications on one or more processors. When in isolated development mode, the utility device is also configured to verify a network signature against a reference network signature. When in isolated development mode, the utility is also configured to switch to network test mode in response to verifying a network signature. When in network test mode, the utility is also configured to join a network. When in network test mode, the utility is also configured to register with the headend system via the network. When in network test mode, the utility is also configured to execute an application on one or more processors. The utility communicates with one or more other utility devices based on the application. When in network test mode, the utility is also configured to switch back to isolated development mode after a threshold time period.

[0004] On the other hand, one method involves sending a request for a development certificate. The request includes a unique identifier for the utility device. The method also involves receiving a manufacturer's signature and a network signature. The method further involves verifying the manufacturer's signature against a reference manufacturer's signature. The method also involves switching to an isolated development mode in response to verifying the manufacturer's signature. While in isolated development mode, the method also involves restricting the utility device from joining the network. While in isolated development mode, the method also involves receiving an application from the development computing system. While in isolated development mode, the method also involves executing the application. While in isolated development mode, the method also involves verifying the network signature against a reference network signature. While in isolated development mode, the method also involves switching to a network test mode in response to verifying the network signature. While in network test mode, the method further includes joining the network and communicating with one or more utility devices connected to the network. While in network test mode, the method further includes registering with a headend system via the network. While in network test mode, the method also involves executing an application. The application can communicate with one or more utility devices. While in network test mode, the method also involves switching back to isolated development mode after a threshold time interval.

[0005] In another aspect, a system includes a development computing system and a utility device. The development computing system is configured to send a request for a development certificate to a verification server. This request includes a unique identifier for the utility device. The development computing system is configured to receive a development certificate from the verification server. The development certificate includes a network signature and a manufacturer signature. The development computing system is also configured to send the development certificate and an application to the utility device. The utility device includes one or more processors and memory configured to store a reference manufacturer signature and a reference network signature. The utility device is also configured to communicate with the development computing system and operate in one or more of the following modes: endpoint mode, isolated development mode, or network test mode. When in endpoint mode, the utility device is configured to communicate with other devices on the network. When in endpoint mode, the utility device is configured to receive a development certificate from the development computing system. When in endpoint mode, the utility device is configured to verify the manufacturer signature against the reference manufacturer signature. In response to verifying the manufacturer signature, the utility device is configured to switch to isolated development mode. When in isolated development mode, the utility device is restricted from joining the network and is configured to run applications on one or more processors. When in isolated development mode, the utility device is configured to verify network signatures against a reference network signature. When in isolated development mode, the utility device is configured to switch to network test mode in response to verifying the network signature.

[0006] These illustrative examples are provided not to limit or restrict this disclosure, but to provide examples to aid in understanding it. Further examples and descriptions are provided in the detailed description. Attached Figure Description

[0007] These and other features, aspects, and advantages of this disclosure can be better understood when the following detailed description is read with reference to the accompanying drawings, in which:

[0008] Figure 1 This illustrates a development environment for utility equipment within a utility network, based on one aspect.

[0009] Figure 2 An exemplary state diagram of a utility facility is shown, based on one aspect.

[0010] Figure 3 This is a flowchart illustrating an exemplary process for developing a utility facility according to one aspect.

[0011] Figure 4 A verification environment for a development environment for public utility equipment is shown, based on one aspect.

[0012] Figure 5 An exemplary computing system that can be used in a collector or metering device is shown, according to one aspect. Detailed Implementation

[0013] The disclosed solutions relate to the development, debugging, testing, and deployment of application software on utility equipment (e.g., utility meters) within a resource distribution network. Examples of resource distribution networks are utility networks, such as electricity, gas, or water distribution networks. Examples of functions that can be performed by the application software include testing line faults, determining line losses, checking for safety issues, smart metering applications, and smart grid applications.

[0014] A resource distribution network includes utility equipment that measures parameters such as resource consumption or resource status. Equipment on a resource distribution network is typically connected by one or more communication networks, which provide a mechanism for aggregating and transmitting data to a central system for purposes such as billing or analysis.

[0015] Application software can be developed for and deployed on utility equipment, but security concerns exist due to the nature of utility communication networks. For example, because application software running on utility equipment can access the utility network, poorly written or malicious applications could cause reliability issues with the utility network. This risk may be intolerable due to the security requirements of utility systems and utility infrastructure. The disclosed solution mitigates these risks by facilitating application software development and testing in a secure and restricted manner before widespread deployment.

[0016] Furthermore, promoting the development of safety application software on utility equipment can facilitate previously impractical advanced applications. For example, applications operating on utility equipment downstream of transformers can perform high-frequency measurements to determine if excessive line losses are occurring. However, due to bandwidth and power limitations of utility networks, propagating these measurements sufficiently quickly to the headend system can be challenging. Therefore, enabling applications to operate within a local area of ​​the network can improve analytical capabilities.

[0017] In a more specific example, the disclosed solution facilitates the development of secure software deployed on utility equipment within a utility system. The disclosed solution enables development and testing capabilities in constrained environments by verifying one or more certificates or signatures from the utility equipment manufacturer and / or the utility network operator.

[0018] Now turn to the attached image. Figure 1 This illustrates a development environment for utility equipment within a utility network, based on one aspect. Figure 1 A development environment 100 and a public utility network 150 are depicted. The development environment 100 includes a verification server 110, a network 120, and a development computing system 130. Figure 1 In the depicted example, verification server 110 verifies utility equipment on utility network 150, thereby enabling the development and / or testing functions of the utility equipment. Therefore, the capabilities of utility equipment on utility network 150 can be limited by a license granted by verification server 110. A license can be granted by receiving a development certificate, which may include one or more signatures. For example, a manufacturer signature indicates a license granted by the manufacturer of the utility equipment, and a network signature indicates a license granted by the operator of the utility network.

[0019] To facilitate development and testing, a given utility device can be licensed to operate in different modes, each with a different set of capabilities and limitations. Examples of modes include: endpoint mode, isolated development mode, and network testing mode. Switching between modes or access to modes can be predicted based on successful validation of the utility device by the device manufacturer and / or the utility company operating the utility network. About Figure 2 Further explanation of these patterns, and in Figure 3 The document describes an example of the process of switching between modes.

[0020] The development computing system 130 is configured to download, debug, test, and cause the execution of application software on one or more utility devices. For example, using development tool 132, the developer can build (compile, assemble, link, etc.) the software application into an object file, download the object file to the utility device via a development port, and step-by-step debug the application. An example of development tool 132 is an integrated development environment (IDE).

[0021] Utility network 150 includes one or more of headend system 152, backhaul network 154, collector 156, and network 170. Headend system 152 communicates with collector 156 via backhaul network 154. Backhaul network 154 can be a wired network (e.g., Ethernet or fiber optic cable), a wireless network (e.g., cellular), or a combination of both. Although utility equipment may be located at the end-user's residence, the topology of the communication network including the utility equipment is fundamentally different from the topology of the resource distribution network itself because the communication network is constructed based on connectivity between devices rather than resource flow.

[0022] Network 170 can be a Area Network (PAN). A PAN can be a wireless network or a wireless mesh network using wireless protocols such as WiFi, Bluetooth, Wireless Smart Utility Network (Wi-SUN), ZigBee, and the Institute of Electrical and Electronics Engineers (IEEE) 802.15 protocol or proprietary protocols. Collector 156 communicates with network 170. If network 170 is a PAN, then collector 156 can be the PAN coordinator for network 170. Collector 156 communicates with utility devices 160a-e. Each utility device can wirelessly communicate with one or more other devices across one or more PANs. Although network 170 includes five utility devices for illustrative purposes, any number of utility devices is possible. For example, network 170 can include hundreds of utility devices. One or more different communication paths can exist between utility devices 160a-e and collector 156.

[0023] Utility equipment 160a-e is typically a utility meter located at the end-user's residence (e.g., at a point of service), but may also include other measuring or control equipment connected to power lines, transformers, capacitor banks, etc. Utility equipment may include one or more computing systems. Therefore, utility equipment can implement functions such as advanced metering infrastructure (AMI) capabilities, which may include capturing, processing, and transmitting metering and resource information.

[0024] Each utility device 160a-e can execute firmware and software applications. Firmware may include basic operating functions such as an operating system, software drivers for various peripherals on the utility device, etc. Each utility device may include one or more applications pre-installed from the manufacturer or from the utility network operator.

[0025] Application software can be tested and debugged when the target hardware is operating in an isolated development mode with limited network and other connectivity. Furthermore, in network testing mode, a wider range of tests can be performed compared to isolated development mode, while still maintaining slightly limited capabilities on public utilities networks and / or within limited timeframes compared to the default mode.

[0026] Figure 2 An exemplary state diagram 200 is shown based on one aspect of a public utility facility. Figure 2 Endpoint mode 202, isolated development mode 204, and network testing mode 206 are described. While three modes are listed, more than three modes are possible. For illustrative purposes, utility equipment 160a is discussed. Figure 2 .

[0027] On one hand, utility device 160a enters endpoint mode 202 upon power-up. In endpoint mode, utility device 160a operates with the default set of functions required to function within the utility network. For example, utility device 160a can join the network, communicate across networks, register with headend systems, etc. Utility device 160a can collect and transmit metering data, perform analytics, and execute any approved or manufacturer-installed application software. In some cases, in endpoint mode 202, any diagnostic or development (e.g., Joint Test Action Group (JTAG)) ports of utility device 160a can be disabled to prevent software development or tampering.

[0028] To transition from endpoint mode 202 to isolated development mode 204, a manufacturer signature is obtained and verified. The manufacturer signature ensures that the utility device has a license from the manufacturer for debugging and testing application software. Development computing system 130 can facilitate the transition by performing actions such as requesting a unique key from the utility device and sending the unique key to verification server 110. (About...) Figure 3 and Figure 4 Further explanation of the verification process.

[0029] Once in isolated development mode 204, utility devices are functionally limited. Examples of limitations include restricted or no network access (e.g., network 170) and restricted or no access to headend system 152. One or more ports on the utility device (such as JTAG ports or diagnostic ports) can be enabled to facilitate development tools' access to the utility device. In some cases, communication between utility devices can still occur through non-disabled communication ports (such as via serial ports and switches).

[0030] In isolated development mode 204, because the network and other functions are restricted, the application being tested or debugged generally does not cause harm to the network. Therefore, application software debugging and testing can be carried out without the risk of damaging the network or other equipment or interfering with network functions (e.g., the collection and transmission of metering or status data).

[0031] When in isolated development mode 204, utility device 160a can be controlled by development computing system 130 and development tools 132. Development tools 132 can download one or more applications to utility device 160a. Development tools 132 can also control utility device 160a using commands such as debug, step-by-step debugging (through code), and tracing.

[0032] To transition from isolated development mode 204 to network testing mode 206, a network signature is obtained from the server. The network signature indicates that the utility device has a license from the utility network operator to perform application software testing. Requests for certificates or signatures can be made by utility device 160a and / or development tool 132. In some cases, the utility network operator sends a unique identifier for utility device 160a to the manufacturer. Based on the unique identifier and, in some cases, additional parameters such as device type or configuration, the manufacturer sends a manufacturer signature and a network signature to utility device 160a. About Figure 3 and Figure 4 Further explanation of the verification process.

[0033] In network testing mode 206, utility device 160a can join the network, for example, to perform restricted testing of software applications; however, compared to endpoint mode, utility device 160a remains restricted. When in network testing mode 206, some restrictions present in isolated development mode 204 can be removed. For example, utility device 160a can join the network and register with the headend system.

[0034] In some cases, access to network test mode 206 can be time-limited. For example, after a certain period of time, the utility device can automatically switch back to isolated development mode 204. Examples of time periods include 1 day or 7 days. The time period can be pre-configured and / or adjusted. From endpoint mode 202, the utility device can switch back to endpoint mode after a threshold amount of time has elapsed or after the development computing system 130 sends a control signal to the utility device. In some cases, the utility device can switch back to endpoint mode 202, for example, after firmware replacement and / or parameter changes of the utility device.

[0035] The restrictions implemented in isolated development mode and network testing mode can be achieved in various ways. For example, in one implementation, to transition from endpoint mode 202 to isolated development mode 204 and / or from isolated development mode 204 to network testing mode 206, utility device 160a is rebooted to a restricted state controlled by the firmware of utility device 160a. In other cases, a reset is combined with the application of a set of parameters of the utility device to implement the restrictions.

[0036] Network access restrictions can be implemented by the utility device (e.g., in firmware) to disable or limit network adapters, or by the network itself. For example, the serial or network identifier of the utility device can be masked in software, preventing the utility device from joining the network. In another example, the network itself can deny access to the utility device by sending a command with the utility device's identifier from a headend system and causing the network to add the identifier to a restricted access list.

[0037] Figure 3 This is a flowchart illustrating an exemplary process for operating utility equipment according to one aspect of a development. It should be understood that the operations described in process 300 may be performed in a different order and / or one or more operations of process 300 may not need to be performed.

[0038] For illustrative purposes, process 300 is described as being performed by development environment 100 (e.g., development computing system 130) and utility network 150 (e.g., utility equipment 160a). Process 300 involves three modes: endpoint mode, isolated development mode, and network testing mode.

[0039] At box 302 of process 300, when in endpoint mode, the utility device communicates with other devices on one or more networks. For example, when in endpoint mode, utility device 160a is configured to communicate with other utility devices 160b-e, network 170, collector 156, and headend system 152 via backhaul network 154. In endpoint mode, for security reasons, the development port and / or other ports on utility device 160a can be disabled.

[0040] At box 304 of process 300, utility device access includes a development certificate with both manufacturer signature and network signature. Utility device 160a receives the development certificate via development computing system 130 (e.g., via a development port connected to utility device 160a) or via utility network 150 (e.g., via network 170, through collector 156 to backhaul network 154, and via backhaul network 154 to headend system 152).

[0041] A development certificate can be requested for utility equipment 160a or development tool 132. The request for a development certificate may include a unique identifier for the utility equipment, such as a serial number or network device identifier. In some cases, manufacturer signature and network signature can be requested separately. (See also: Regarding...) Figure 4 As discussed further, issuing a development certificate may include matching the unique identifier in a database of approved devices.

[0042] At box 306 of process 300, the utility device verifies the manufacturer signature against a reference manufacturer signature. The reference manufacturer signature may be predetermined and stored in the non-volatile memory of utility device 160a prior to deployment, or it may be obtained by utility device 160a (e.g., downloaded). In one aspect, the verification of the utility device may involve a public-private key verification of the manufacturer signature, as per [reference to...]. Figure 4 Further discussion is needed. On the other hand, verification of utility equipment can involve comparing hashes of signatures.

[0043] As described, the network signature can be verified at box 316. In some cases, manufacturers can verify both the manufacturer's signature and the network signature at box 306 without requiring verification by the utility equipment. For example, manufacturers can approve and verify utility network operators.

[0044] At box 308 of process 300, in response to verifying the manufacturer's signature, the utility device 160a switches to isolated development mode. If the utility device 160a cannot verify the manufacturer's signature, the utility device 160a may remain in endpoint mode and / or issue error messages to the development computing system 130 and / or the utility network via the development port.

[0045] At block 310 of process 300, access to the network for a utility device is restricted. When in isolated development mode, the utility device is restricted from performing certain actions. For example, when utility device 160a is in isolated development mode, access to network 170 can be restricted. Thus, utility device 160a cannot communicate with collector 156, backhaul network 154, and headend system 152.

[0046] At box 312 of process 300, the utility device receives the application from the development computing system via a development port. In isolated development mode, the development port and / or other ports on the utility device 160a can be activated to facilitate application software download, debugging, tracing, etc. In the example, development tool 132 builds the application and downloads the application to the utility device 160a.

[0047] At box 314 of process 300, the utility device executes the application on one or more processors. Continuing the example, utility device 160a executes the application. Utility device 160a can step through and debug the application and send trace or debug information back to development tool 132.

[0048] At box 316 of process 300, the utility device verifies the network signature against a reference network signature. The reference network signature may be predetermined and stored in the utility device's memory before deployment, or it may be obtained by the utility device (e.g., downloaded). A request to switch from isolated development mode to network test mode may be initiated by an external request, such as via development tool 132. When a request is received, utility device 160a verifies the network signature against the reference network signature. The reference network signature may be stored in non-volatile memory before deployment. In one aspect, the verification by utility device 160a may involve a public-key / private-key verification of the network signature, as per [reference to...]. Figure 4 Further discussion is needed.

[0049] At box 318, in response to the network signature verification process 300, the utility device 160a switches to network test mode. If the utility device 160a successfully verifies the network signature, it switches to network test mode. If the utility device 160a fails to verify the network signature, it may remain in isolated development mode and / or send error messages to development computing system 130 and / or the utility network via the development port. In some cases, the utility device 160a may start a timer such that, at box 326, when the timer has elapsed for a predetermined amount of time, it can automatically switch back to isolated development mode.

[0050] At box 320 of process 300, when in network test mode, a utility device joins one or more networks. Continuing the example, utility device 160a joins network 170 and can communicate with utilities 160b-e, collector 156, backhaul network 154, and headend system 152. Because network access is disabled in isolated development mode, it is restored by utility device 160a and / or the network when switching to network test mode. For example, a reboot, reset, or unmasking of the utility device's serial number is performed.

[0051] In box 322 of process 300, utility equipment 160a registers with the headend system via the network. Utility equipment 160a registers with the headend system 152, thereby enabling testing of applications on the utility network.

[0052] At box 324 of process 300, the utility device executes an application on one or more processors. Continuing the example, utility device 160a executes the application, and in doing so, can communicate with one or more of the utility devices 160b-e.

[0053] At box 326 of process 300, after a threshold time has elapsed, the utility device switches to isolated development mode. Continuing the example, utility device 160a determines that the timer has reached the threshold time and switches back to isolated development mode.

[0054] The transition between modes can be triggered by other events. For example, the transition can be caused by external commands or input. When in network test mode, a utility device can be configured to switch to isolated development mode upon receiving input from an external development system.

[0055] Figure 4 A verification environment for a development environment for public utility equipment is shown, based on one aspect. Figure 4 A verification environment 400 is depicted, which includes one or more of the following: a manufacturer verification server 420, a network verification server 430, a network 450, utility equipment 460, and a development computing system 470. Figure 4 In the example depicted, manufacturer verification server 420 and network verification server 430 each determine the license granted to utility device 460 by comparing its unique identifier with one or more databases. The resulting license may be reflected in one or more development certificates that enable isolated development mode or network testing mode.

[0056] Compared to the description of verification server 110 Figure 1 , Figure 4A more specific example is depicted where the manufacturer of the equipment and the utility network operator on which the equipment operates verify the utility equipment. For example, both the manufacturer and the utility network operator can match the unique identifier of utility equipment 460 in their respective databases.

[0057] In some cases, the manufacturer also verifies the utility network operator. For example, if the utility network operator is trusted by the manufacturer, the verification of utility device 460 may only need to be performed by the manufacturer's verification server 420. In some cases, the utility device may not need to verify the utility. For example, in many cases, the utility itself may be the application.

[0058] The development computing system 470 can facilitate the verification of utility equipment 460. For example, utility equipment 460 can receive messages or signatures via the development computing system 470 (e.g., via a development port and / or network). In other cases, utility equipment 460 can communicate directly with manufacturer verification server 420 and / or network verification server 430 via a utility network (e.g., via collectors and headend systems). Similarly, requests including unique identifiers can be sent via the development computing system 470 or via a utility network. Therefore, the development computing system 470 may or may not always be used to verify utility equipment.

[0059] In a more specific example, the manufacturer of utility device 460 verifies utility device 460. Manufacturer verification server 420 includes verification application 422, device verification database 424, and manufacturer private key 426. Manufacturer verification server 420 is typically controlled by the manufacturer of the utility device. Manufacturer verification server 420 receives a request from utility device 460 and / or development computing system 470. The request includes one or more unique identifiers, such as the serial number or device network identifier of utility device 460. Manufacturer verification server 420 matches the unique identifier in device verification database 424. If verification is successful, for example, if the unique identifier is on the list of approved devices within device verification database 424, manufacturer verification server 420 sends a manufacturer signature back to utility device 460.

[0060] In some cases, public-key-private-key encryption is used. For example, manufacturer verification server 420 creates a message and encrypts it, including the manufacturer's signature, with its private key. Manufacturer verification server 420 sends the message to utility device 460. Utility device 460 then verifies the message by decrypting it with the manufacturer's public key 462 and comparing it to a reference manufacturer signature. If the signatures match, utility device 460 can switch to isolated development mode.

[0061] Additionally or alternatively, the utility company operating utility device 460 verifies utility device 460. Network verification server 430 includes verification application 432, utility verification database 434, and utility private key 436. Network verification server 430 is controlled by the utility network operator. Network verification server 430 receives requests from utility device 460 and / or development computing system 470. The request includes one or more unique identifiers of utility device 460. Network verification server 430 matches the unique identifiers in utility verification database 434. If verification is successful, for example, if the unique identifier is on the list of approved devices within utility verification database 434, network verification server 430 sends a utility signature back to utility device 460.

[0062] In some cases, public-key-private-key encryption is used. For example, network verification server 430 creates a message and encrypts it, including a utility signature, with its private key. Network verification server 430 sends the message to utility device 460. Utility device 460 then verifies the message by decrypting it with the utility public key 464 and comparing it to a reference utility signature. If the signatures match, utility device 460 can switch to network test mode.

[0063] In some cases, hashing is used. For example, utility equipment 460 can verify a manufacturer's signature or a message containing a signature by comparing it to a reference hash. If the hash of the received manufacturer's signature matches the reference hash, the manufacturer's signature is verified. Similarly, utility equipment 460 can verify a network signature or a message containing a signature by comparing it to a reference hash. If the hash of the received network signature matches the reference hash, the network signature is verified.

[0064] Figure 5 An exemplary computing system that can be used in a utility facility according to one aspect is illustrated. Any suitable computing system can be used to perform the operations described herein. The illustrated example of computing system 500 includes a processor 502 communicatively coupled to a memory device 504. The processor 502 executes computer-executable program code 530 stored in the memory device 504, accesses data 520 stored in the memory device 504, or both. The program code 530 may include program code for applications developed using the development computing system 130 and / or development tools 132. The data 520 may include application-related data.

[0065] Examples of processor 502 include microprocessors, application-specific integrated circuits (“ASICs”), field-programmable gate arrays (“FPGAs”), or any other suitable processing device. Processor 502 may include any number of processing devices or cores, including a single processing device. The functionality of the computing system may be implemented using hardware, software, firmware, or a combination thereof.

[0066] The computing system 500 may include a sensor 550 configured to measure parameters related to resources in a resource distribution network. For example, in a power distribution system, the sensor 550 may measure power consumption, voltage, current, etc. In a gas distribution system, the sensor 550 may measure flow rate. In some aspects, the computing system 500 may include multiple sensors. For example, the computing system 500 may include both a power sensor and a temperature sensor.

[0067] The computing system 500 may include a resource regulation device 511. The resource regulation device 511 is configured to control resources, such as electricity, water, gas, etc. The resource regulation device 511 can disconnect, reconnect, slow down, accelerate, or otherwise adjust the resources. In some embodiments, the resource regulation device 511 may be located remotely from the computing system 500.

[0068] Memory device 504 includes any suitable non-transitory computer-readable medium for storing data, program code, or both. Computer-readable media can include any electronic, optical, magnetic, or other storage device capable of providing computer-readable instructions or other program code to a processor. Non-limiting examples of computer-readable media include flash memory, ROM, RAM, application-specific integrated circuits (ASICs), or any other medium from which instructions can be read by a processing device. Instructions can include processor-specific instructions generated by a compiler or interpreter from code written in any suitable computer programming language, including, for example, C, C++, C#, Visual Basic, Java, or scripting languages.

[0069] The computing system 500 may also include multiple external or internal devices, such as input or output devices. For example, the computing system 500 is shown as having one or more input / output (“I / O”) interfaces 508. The I / O interface 508 can receive input from an input device or provide output to an output device. One or more buses 506 are also included in the computing system 500. The buses 506 communicatively couple one or more components of a corresponding one in the computing system 500.

[0070] The computing system 500 may also include a diagnostic port 505. The diagnostic port 505 may be used, for example, by an equipment vendor or utility company, to determine whether the computing system is operating correctly, or to diagnose and remedy problems, or to perform firmware upgrades on the computing system 500.

[0071] The computing system 500 may also include a development port 509. The development port 509 facilitates the downloading, execution, and debugging of application software on the computing system 500. For example, an external development computing system can connect to the computing system 500 via the development port 509 and download applications to the computing system 500. The external development computing system can then execute, start, or stop the applications. Examples of development ports 509 include JTAG ports, serial ports, parallel ports, and network ports. The development port 509 can be disabled by firmware or software.

[0072] The computing system 500 executes program code 530, which configures the processor 502 to perform one or more operations described herein. For example, program code 530 causes the processor to perform... Figure 3 The operations described in the document.

[0073] The computing system 500 also includes a network interface device 510. The network interface device 510 includes any device or group of devices suitable for establishing wired or wireless data connections to one or more data networks. The network interface device 510 may be a wireless device and has an antenna 514. The computing system 500 can use the network interface device 510 to communicate with one or more other computing devices implementing the computing system or other functions via a data network. The network interface device 510 may be controlled by firmware, which can restrict access to one or more networks.

[0074] The computing system 500 may also include a display device 512. The display device 512 may be an LCD, LED, touch screen, or other device operable to display information about the computing system 500. For example, the information may include the operating status of the computing system, network status, etc.

[0075] While the subject matter has been described in detail with respect to specific aspects, it should be understood that those skilled in the art will readily make changes, variations, and equivalents to these aspects upon understanding the foregoing. Therefore, it should be understood that this disclosure is presented for illustrative purposes rather than for limitation, and does not exclude the inclusion of such modifications, variations, and / or additions to the subject matter, which will be apparent to those skilled in the art.

Claims

1. A public utility facility, comprising: One or more processors are configured to operate in one or more of endpoint mode, isolated development mode, and network test mode, wherein: When in the endpoint mode, the utility equipment is configured as follows: Communicating with other devices on the network; Access manufacturer signatures and network signatures; Verify the manufacturer's signature against the reference manufacturer's signature; and In response to verifying the manufacturer's signature, switch to the isolated development mode; When in the isolated development mode, the utility equipment is restricted from joining the network and is configured as follows: Receive applications from the development computing system via the development port; The application is executed on one or more processors; Verify the network signature against a reference network signature; and In response to verifying the network signature, switch to the network test mode; and When in the network test mode, the public utility equipment is configured as follows: Join the network; Register with the headend system via the network; The application is executed on one or more processors, wherein the utility device communicates with one or more other utility devices based on the application; and After the threshold time has elapsed, switch to the isolated development mode.

2. The utility equipment of claim 1, wherein the manufacturer's signature is included in the message, and wherein verifying the manufacturer's signature against the reference manufacturer's signature includes decrypting the message with the manufacturer's public key and comparing the message with the reference manufacturer's signature.

3. The public utility equipment according to claim 1, wherein, The utility equipment includes a diagnostic port and a Joint Test Action Group (JTAG) port, wherein one or more of the diagnostic port and the JTAG port are disabled when the isolated development mode is in play.

4. The utility equipment according to claim 1, when in the isolated development mode, is restricted from communicating with the headend system.

5. The utility equipment according to claim 1, wherein the manufacturer signature and the network signature are generated based on a unique identifier of the utility equipment matched in a database, wherein the unique identifier is a network device identifier of the utility equipment or a serial number of the utility equipment.

6. The public utility equipment according to claim 1, wherein, Switching to the isolated development mode or the network test mode includes restarting or resetting the utility equipment.

7. The utility equipment of claim 1, wherein the network signature is included in the message, and wherein verifying the network signature against the reference network signature includes decrypting the message with the public key of the utility network operator and comparing the message with the reference network signature.

8. The public utility equipment according to claim 1, wherein, When in the network testing mode, upon receiving input from an external development system, the utility equipment is configured to switch to the isolated development mode.

9. The utility equipment of claim 1, wherein verifying the manufacturer's signature against the reference manufacturer's signature includes creating a hash of the manufacturer's signature and comparing the hash with the reference hash.

10. The utility device of claim 1, wherein when in the endpoint mode, the utility device is configured to send a unique identifier of the utility device to the development computing system, and wherein one or more of the manufacturer signature and the network signature are received from the development computing system.

11. A method comprising: Send a request for a development certificate, wherein the request includes a unique identifier for the utility equipment; Receive manufacturer signatures and network signatures; Verify the manufacturer's signature by comparing it with the reference manufacturer's signature; as well as In response to verifying the manufacturer's signature, switch to isolated development mode; When in the isolated development mode: Restrict the access of the aforementioned public utilities and equipment to the network; Receive applications from the development computing system; Execute the application; Verify the network signature by comparing it with a reference network signature; as well as In response to verifying the network signature, switch to network test mode; and Specifically, when in the network test mode: Join the network and communicate with one or more utility devices connected to the network; Register with the headend system via the network; The application is executed, wherein the application is capable of communicating with the one or more utility devices; and After the threshold time has elapsed, switch to the isolated development mode.

12. The method according to claim 11, wherein: The manufacturer's signature is included in the first message; Verifying the manufacturer's signature against the reference manufacturer's signature includes decrypting the first message using the manufacturer's public key and comparing the first message with the manufacturer's signature; The network signature is included in the second message; and Specifically, verifying the network signature by comparing it with the reference network signature includes decrypting the second message using the public key of the public utility network operator and comparing the second message with the network signature.

13. The method according to claim 11, wherein, Switching to the isolated development mode or the network testing mode includes restarting the utility equipment.

14. The method according to claim 11, wherein, Verifying the network signature against the reference network signature includes creating a hash of the network signature and comparing the hash with the reference hash.

15. A system comprising: Develop a computing system that is configured as follows: Send a request for a development certificate to the verification server, wherein the request includes a unique identifier for the utility equipment; Receive the development certificate from the verification server, wherein the development certificate includes a network signature and a manufacturer signature; as well as Send the development certificate and application to the utility equipment; The public utilities and equipment include: One or more processors; The memory, configured to store reference manufacturer signatures and reference network signatures, wherein the utility device is configured to communicate with the development computing system and operate in one or more of the following: endpoint mode, isolated development mode, or network test mode, wherein: When in the endpoint mode, the utility equipment is configured as follows: Communicating with other devices on the network; Receive the development certificate from the development computing system; Verify the manufacturer signature by comparing it with the reference manufacturer signature; and In response to verifying the manufacturer's signature, switch to the isolated development mode; and When in the isolated development mode, the utility equipment is restricted from joining the network and is configured as follows: The application is executed on one or more processors; Verify the network signature against the reference network signature; and In response to verifying the network signature, switch to the network test mode.

16. The system of claim 15, wherein the manufacturer signature is included in the message, and wherein verifying the manufacturer signature against the reference manufacturer signature includes decrypting the message with the manufacturer's public key and comparing the message with the reference manufacturer signature.

17. The system of claim 15, wherein the network signature is contained within the message, and wherein verifying the network signature against the reference network signature includes decrypting the message with a public key of a public utility network operator and comparing the message with the reference network signature.

18. The system of claim 15, wherein the development computing system is further configured to obtain the unique identifier of the utility equipment from the utility equipment and via a development port.

19. The system of claim 15, wherein when the utility equipment is in the isolated development mode, the development computing system is configured to debug the application.

20. The system of claim 15, wherein when the verification server receives the request, the verification server matches the unique identifier in the database of the approved device and generates the development certificate.

Images