Cloud-based Electrical Grid Component Verification

Abstract

To perform cloud-based electrical grid component verification. 【Solution means】 A method, system and apparatus including a media encoding computer program product for cloud-based electrical grid component verification can include obtaining a computer model of the electrical grid. The computer model can include asset models of individual assets connected to the electrical grid. Each asset model can be configured to replicate the operation of a corresponding type of physical electrical grid asset. The first asset model can include a hardware emulator configured to execute firmware specific to a corresponding type of physical electrical grid asset. Modified firmware for the first asset model can be received. The computer model can be processed using a simulation engine to obtain simulation results, and the simulation engine can be configured to simulate the operation of the individual assets of the computer model including the operation of the first asset model according to the modified firmware associated with the first asset model. Simulation results can be provided.

Description

Technical Field

[0001] (Claims of Priority) This application claims the benefit of priority under 35 U.S.C. § 119(e) to U.S. Patent Application No. 63 / 359,536, filed on July 8, 2022, the entire disclosure of which is incorporated herein by reference.

Background Art

[0002] Electrical systems include a wide range of interconnected components of various types, such as inverters (solar, wind, High Voltage Direct Current (HVDC), Flexible Alternating Current Transmission System (FACTS), etc.), relays, Power Plant Controllers (PPCs), energy management systems, Remedial Action Systems (RASs), automatic generator controls, alarm systems, etc.

Summary of the Invention

[0003] This specification relates to cloud-based verification of components of an electrical system. The verification uses a hardware emulator configured to execute component firmware. The verification technique can include simulation of assets within the electrical system, and the asset simulation uses a model of the asset to simulate the behavior of power grid elements. The asset model can include firmware specific to the type of the asset, and the hardware emulator can be configured to execute the component firmware. The system can receive changes to the firmware and verify the components of the electrical system by simulating the electrical system using the changed firmware.

[0004] Certain embodiments of the subject matter described in this specification can be realized to achieve one or more of the following advantages. The techniques described below can be used to simulate the results of changing the firmware of components of an electrical grid, thereby reducing the likelihood of firmware defects that cause errors in the electrical grid. The techniques further enable simulation without requiring the distribution of hardware components, thereby reducing cost and the likelihood of malicious parties reverse engineering the hardware components. Additionally, the techniques enable a user to perform simulations of various combinations of firmware updates applied to multiple components of a system in various combinations. Such robust simulations can further reduce the likelihood of errors associated with firmware updates being introduced into the actual hardware assets installed in a power system.

[0005] One aspect is characterized by obtaining a computer model of a power grid. The computer model can include asset models of individual assets connected to the power grid. Each asset model can be configured to replicate the operation of a corresponding type of physical electrical grid asset. The first asset model among the asset models can include a hardware emulator configured to execute firmware unique to a corresponding type of physical electrical grid asset. An asset interface can be provided that is configured to allow a user to change the first asset model. The changed firmware for the first asset model can be received from the user via the asset interface. The computer model can be processed using a simulation engine to obtain simulation results, and the simulation engine can be configured to simulate the operation of the individual assets of the computer model, including the operation of the first asset model according to the changed firmware associated with the first asset model. Simulation results indicating how the first asset model functioned while using the changed firmware can be provided for display to the user. Other implementations of this aspect include corresponding systems, devices, and computer programs, which are configured to perform the operations of the method and are encoded on a computer storage device.

[0006] It can include one or more of the following features. In response to determining that the simulation result meets the verification criteria, the changed firmware can be determined to be valid. The changed firmware can include firmware replacement. The changed firmware can include firmware configuration settings. The asset interface can be configured to allow the user to change the second asset model, and can further include receiving from the user, via the asset interface, a second changed firmware for the second asset model. The computer model can be processed using a simulation engine to obtain simulation results, and the simulation engine is configured to simulate the operation of individual assets of the computer model, including (i) the operation of the first asset model according to the changed firmware associated with the first asset model and (ii) the operation of the second asset model according to the second changed firmware associated with the second asset model. The specification of the changed firmware can be determined to meet the specification of the asset described by the asset model, and the changed firmware can be applied to the asset. The specification of the asset can include the type, manufacturer, or version of the asset. In response to determining that the simulation result meets the acceptance criteria, an operation can be executed. The operation can include updating the computer model of the power grid. The operation can include providing the user with a notification indicating that the simulation was successful. Simulating the operation of individual assets of the computer model can include executing the firmware. Executing the firmware can include receiving an input and using the firmware to execute an operation on the input to generate a result that simulates the result generated when the firmware operates on physical hardware and executes on the same input. Processing the computer model can include executing a simulation engine on the computer model in a sandbox environment.

[0007] The details of one or more embodiments of the subject matter described in this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the invention will become apparent from the specification, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0008]

Figure 1

Figure 2

Figure 3

[0009] Electrical systems include a wide range of interconnected components of various types, such as inverters (solar, wind, HVDC, FACTS, etc.), relays, power plant controllers (PPCs), energy management systems, corrective action systems (RASs), automatic generator controls, alarm systems, etc. The operation of one component can affect the operation of other components. For example, a PPC adjusts and controls networked inverters within a power plant. Thus, when a change is planned for one component, it is important to test the modified version of the component within an environment that includes other connected elements to ensure that the change does not have an adverse effect anywhere within the system. Updates should only be deployed to the production environment after thorough testing has been completed to avoid potentially catastrophic failures.

[0010] The operation of many components is partially controlled by firmware, which is software that provides low-level control to specific hardware of the components. Firmware enables new hardware capabilities and can be updated to address any defects detected in a particular firmware version. However, as described above, in order to reduce the possibility that a firmware defect causes a failure somewhere within the system, the update should be tested in an environment that simulates the overall production environment before the firmware update is deployed.

[0011] One approach to such testing is called "Hardware In the Loop" (HIL) simulation. In HIL simulation, the environment is simulated by adding a mathematical representation called a "plant simulation" to all relevant components of the environment. The component being tested is connected to an HIL simulator that provides electrical emulations of sensors and actuators. These electrical emulations function as an interface between the plant simulation and the component being tested. The value of each electrically emulated sensor is controlled by the plant simulation and read by the embedded system being tested.

[0012] However, there are several drawbacks to HIL systems. First, the simulator is specific to individual electrical components, and HIL cannot be used if there is no simulator for a particular component. Second, the HIL simulator may become obsolete when mathematical representations of other components in the environment are loaded and these components are updated (e.g., component firmware is updated). Third, HIL simulators are physically large and may prevent use in real-world deployments.

[0013] This specification describes techniques for cloud-based verification of electrical grid components, also referred to as "Firmware-In-the-Loop In the Cloud" (FILIC). A verification system that executes the techniques of this specification can include a cloud-based verification engine that includes a grid model that simulates the overall structure of an electrical grid. The grid model can include asset models for each type of electrical component within the relevant environment.

[0014] By providing FILIC, the techniques described in this specification enable firmware developers to test firmware updates in the context of a grid model without the need for expensive hardware such as an HIL system. Additionally, in contrast to conventional techniques where firmware updates are tested against one version of firmware for each of the other grid components, the techniques of this specification enable simulations when multiple electrical components apply a firmware update simultaneously.

[0015] FIG. 1 is a diagram illustrating an exemplary environment for cloud-based verification of electrical grid components. The environment can include an electrical grid component verification system 110 and one or more client devices 105a, 105n (collectively referred to as 105).

[0016] The electrical grid component verification system 110 can include a power grid model acquisition engine 120, an asset interface engine 130, a model adjustment engine 135, a model processing engine 140, and a result providing engine 150. The electrical grid component verification system 110 can exist in a single location, or can be geographically dispersed and exist on one or more computer servers that can be connected by a network such as the Internet or an intranet. For example, the electrical grid component verification system 110 can operate on a cloud platform. The cloud platform can include computing resources such as servers, storage, databases, networking, etc., and can exist within a single data center or can be dispersed across multiple data centers that are connected via a network such as the Internet or an intranet that may be geographically separated.

[0017] The power grid model acquisition engine 120 can acquire a model 180a of the power grid (referred to as the "grid model" for simplicity). The power grid model acquisition engine 120 can include an application programming interface (API) that enables a user of the system 110 to provide the grid model 180a or the location of the model. In some implementations, the API can accept a Uniform Resource Indicator (URI) that specifies the location of the grid model 180a. The power grid model acquisition engine 120 can use the URI to retrieve the model 180a. In some implementations, the power grid model acquisition engine 120 accesses the grid model 180a from a database. For example, a common model of the electrical grid can be used by many users of the system 110. For example, the power grid model acquisition engine 120 can access the common electrical grid model of a particular geographic area for all users who desire to test firmware for different physical hardware assets connected to the electrical grid within that particular geographic area (e.g., California).

[0018] The grid models 180a, 180b (collectively referred to as 180) can include a plurality of asset models for individual assets connected to the power grid and a description of the interconnections between the assets. Each asset model can be configured to replicate the operation of the corresponding type of physical electrical grid asset, and each asset model can be used to simulate the operation of the asset or the type of asset. The asset model can include a hardware emulator. The hardware emulator can be configured to execute firmware specific to the corresponding type of physical electrical grid asset.

[0019] Executing the firmware can include receiving an input and executing, for the input, operations specified by the firmware to simulate the results that would be produced when the firmware operates on the physical hardware and produces results when executed for the same input. The input can be a simulated input, such as data captured when operating an actual power grid, random data generated according to parameters encountered in the actual power grid (e.g., a voltage that varies within some known parameters), data generated by a human operator, etc.

[0020] The grid model 180 of the power grid can be represented as a graph. The nodes of the graph can represent assets, and each node can include information about the asset, such as an identifier, the type of the asset, the manufacturer and version of the asset, the date of installation, information about the services to be executed on the asset, etc. The edges within the graph can represent connections between assets and can include an indication of the direction of power flow.

[0021] The asset interface engine 130 can receive the modified firmware 185. The modifications can be of many types, including firmware replacement, replacement of one or more components of the firmware, addition or deletion of firmware components, change of one or more firmware configuration settings, providing initial values of configuration settings, other firmware changes, or any combination thereof. The modified firmware can include the type of the change, the specific asset to which the change is to be applied, a description of the class of assets to which the change is to be applied (e.g., all transformers of a specific manufacturer and version), change data (e.g., firmware update, configuration settings, etc.), and other data related to the change. In some implementations, the asset interface engine 130 can include an API that enables a user of the system 110 to provide the modified firmware 185 or the location (e.g., URI) of the modified firmware 185.

[0022] In some implementations, when the asset interface engine 130 is rendered by the client device 105, it can provide user interface presentation data that causes the client device 105 to render one or more user interface panels. When the user interacts with the user interface presentation data, the user interface presentation data can cause the client device 105 to send the modified firmware 185, or the location of the modified firmware 195, to the asset interface engine.

[0023] The model adjustment engine 135 can receive the grid model 180a and the modified firmware 185 and generate a modified grid model 180b. In some implementations, the modified grid model 180b is the grid model 180a modified only by the modified firmware 185. The model adjustment engine can apply the modified firmware 185 to one or more assets within the grid model 180a to generate the modified grid model 180b, as further described below.

[0024] In some implementations, the model adjustment engine 135 can provide a "sandbox". In this, the only changes to the grid model are the modified firmware 185 submitted by a particular user. The modified firmware can be applied to one or more appropriate components of the electrical grid model. For example, the modified firmware can be applied to a single component, all components of a particular type (e.g., as defined by the component's manufacturer and model), a subset of components of a particular type, etc. The other components of the grid model remain unchanged. By providing a sandbox environment, the system can simulate specific firmware changes while keeping the other components unchanged. Further, by providing a sandbox, simulations run by one user are not affected by the modified firmware 185 used in simulations by other users. For example, the grid model or an appropriate portion thereof can be copied into the sandbox environment. The modified firmware can be applied to specific asset models of the copied grid model within the sandbox environment. A simulation can be run on the copied grid model within the sandbox environment to simulate the operation of the electrical grid with the updated firmware applied to the specific asset models.

[0025] To enable simultaneous updates of multiple electrical components, in some implementations, the model adjustment engine 135 can apply multiple instances of the firmware update 185 to multiple electrical components. The system can receive multiple firmware updates 185 and apply the updates to create a modified grid model 180b. For example, the model adjustment engine 135 can compare the specifications associated with the asset type with the specifications associated with the firmware update 185, as further described below.

[0026] In some implementations, the model adjustment engine 135 can provide the user with a list of available firmware updates, including the firmware update 185. In response to receiving an indication of a selected update, the model adjustment engine 135 can apply the selected update and the firmware update 185 to generate a modified grid model 135.

[0027] In some implementations, the model adjustment engine 135 can generate a plurality of updated grid models 185b. The model adjustment engine 135 can generate a first updated grid model 180b that is different from the grid model 180a only in the changed firmware 185. The model adjustment engine 135 can generate a second updated grid model 185b that includes the changed firmware 185 and other adjustments selected, for example, by the user. The mode adjustment engine 135 can provide the plurality of modified grid models 185b to the model processing engine 140, and the model processing engine 140 can perform a plurality of simulations, as further described below. Enabling a plurality of simulations using the plurality of changed grid models 180b allows the user to determine whether the firmware update 185 is compatible with the firmware update 185 proposed by other users, and reduces the possibility that a plurality of firmware updates will generate grid defects. The system can generate a changed grid model 180b for each candidate firmware update 185 that may be deployed during the update cycle.

[0028] The model processing engine 140 can evaluate the changed grid model 180b to generate a simulation result 190 indicating how each asset model functioned when the changed firmware 185 was used. The model processing engine 140 can obtain or create the simulated electrical inputs used by the simulation, as described above.

[0029] In some implementations, the simulation result 190 can include the instantaneous values of electrical parameters (such as current, voltage, etc.) and the magnitudes of electrical parameters at one or more points within the modified grid model 180b over one or more periods. In some implementations, the simulation result 190 can include conditional values. For example, when the voltage at a particular asset meets a configured value, the simulation result 190 can include a display such as the asset being highlighted in red. The simulation result 190 can also include an animation showing the results of the simulation over time, an audio indication that a threshold has been met, and the like.

[0030] In various implementations, the simulation result 190 can include results for various assets within the grid. In some implementations, the simulation result 190 can represent the electrical parameters for one or more assets within the modified grid model 185b to which the firmware update 185 has been applied. In some implementations, the simulation result 190 can represent the electrical parameters for all assets within the modified grid model 185b. In some implementations, the simulation result 190 can represent the electrical parameters for one or more assets within the identified region of the modified grid model 185b, or for the assets indicated by the user.

[0031] The simulation result 190 can be encoded in any suitable data format. For example, the simulation result 190 can be encoded in XML, and the XML elements can represent the electrical points and the data of the electrical points (such as instantaneous values) within the modified grid model 185b as described above. The simulation result 190 can include elements for electrical points over one or more periods.

[0032] The result providing engine 150 can provide the simulation result 190, for example, for display to the user. The simulation result 190 can be provided in a data format provided by the model processing engine 140, for example, in an XML format that can be displayed by a web browser. In some implementations, the result providing engine 150 can create user interface presentation data from the simulation result 190 and provide the user interface presentation data to the client device 105 for display.

[0033] FIG. 2 is a flowchart of an exemplary process for cloud-based electrical grid component verification. For convenience, process 200 will be described as being executed by a cloud-based electrical grid component verification system, such as the cloud-based electrical grid component verification system of FIG. 1, that is appropriately programmed to execute the process. The operations of process 200 can also be implemented as instructions stored on one or more non-transitory computer-readable media, and execution of the instructions by one or more data processing devices can cause the one or more data processing devices to execute the operations of process 200. One or more other components described herein can execute the operations of process 200.

[0034] The system can obtain a power grid model (205). The system can provide an API configured to receive a URI specifying the location of the power model. Upon receiving the URI, the system can retrieve the power grid model from the location specified by the URI using a conventional web networking protocol (e.g., Hypertext Transfer Protocol (HTTP) or HTTP Secure (HTTP-S)).

[0035] The system can provide an asset interface configured to allow a user to modify an asset model (210). As described above, in some implementations, the system can provide an asset interface that provides user interface presentation data that allows a user to modify an asset model. In some implementations, the system can provide an asset interface, such as a web interface, that accepts changes to the asset model.

[0036] The system can receive updated firmware (215). In some implementations, when rendered by a client device (e.g., by a web browser running on a laptop or desktop computer), the system can provide user interface presentation data that allows a user to specify the location of the updated firmware and indicate that a firmware update is needed. The system can then retrieve the updated firmware from that location and load it into the corresponding model to replace the existing firmware. In some implementations, when rendered by a client device, the system can provide user interface presentation data that allows a user to provide the system with the firmware associated with a particular asset model (e.g., using the Hypertext Transfer Protocol). In some implementations, when rendered by a client device, the system can provide user interface presentation data that allows a user to specify the firmware settings associated with a particular asset model. In some implementations, the system can provide an Application Programming Interface (API) that can be called by a client (user or another program) that supplies updated firmware for an asset type or a particular asset that exists within the environment.

[0037] In some implementations, the system can receive multiple instances of modified firmware. The instances of modified firmware can be associated with different asset models, and / or multiple instances of modified firmware can be associated with one asset model. For example, one instance of modified firmware can be associated with a first asset model, and a second instance of modified firmware can be associated with a second different asset model. In another example, one instance of modified firmware can include components included in the firmware for one asset model, and a second instance of modified firmware can include configuration settings of the firmware for that asset model.

[0038] When received, the system can change the firmware of at least one asset model within the grid model (220). First, the system can determine the assets within the grid model to which the firmware change (or changes) will be applied by comparing the specifications of the firmware change to the specifications of the assets within the grid model. The system can first identify any asset within the grid model using the identifier specified by the firmware change. The system can further identify any asset within the grid model that has specifications that meet the specifications in the firmware change. For example, if the firmware change specifies an asset type, the manufacturer of the asset, and the asset version, the system can identify all assets within the grid model that have the specified asset type, manufacturer of the asset, and asset version. In another example, if the firmware change specifies an asset type and the manufacturer of the asset, the system can identify all assets within the grid model that have the specified asset type and manufacturer. In some implementations, the firmware change can include more complex specifications (e.g., regular expressions) for identifying assets within the grid model. In such implementations, the system can evaluate the specifications to determine the relevant assets. The system can determine the assets associated with all firmware changes received in operation 215.

[0039] When the system identifies an asset, the system can apply the modified firmware. As described above, the modified firmware can include an indication of the type of modification (e.g., a setting change, firmware replacement, etc.). The system can determine the type of modification and perform the appropriate modification. For example, if the firmware configuration settings are set or changed, the system can set or change the settings, and if a component of the firmware is replaced, the system can remove the original component from the firmware and insert a new component, and if the entire firmware is replaced, the system can remove the original firmware and insert the new firmware, and so on.

[0040] The system can process a computer model using a simulation engine to obtain simulation results (225). The simulation engine can be configured to simulate the operation of individual assets in a computer grid model using the simulated electrical inputs. In some implementations, the system can obtain the configured simulated electrical inputs from a storage device, for example, by reading a file containing the simulated electrical inputs. In some implementations, the system can generate the simulated electrical inputs randomly or pseudo-randomly. In some implementations, the system can generate the simulated electrical inputs randomly or pseudo-randomly according to rules (e.g., a particular load must be between a minimum and a maximum value) or a configured distribution.

[0041] When an asset model and a simulated electrical input are loaded, the system performs a simulation by processing the asset model using a simulation engine to obtain simulation results. The simulation results can be generated by evaluating one or more of the asset models against the simulated input data. As described above, the asset model can include a hardware emulator that can execute firmware designed for a particular asset or asset type. In response to receiving the simulated electrical input, the hardware emulator can execute the firmware to generate results that can include changes in the internal state of the simulated asset and electrical outputs similar to the way the physical asset functions.

[0042] As described above, the system can process a computer model on one or more grid models that include updated firmware. In some implementations, the system processes the computer model using a sandbox so that simulations using one grid model are isolated from other simulations. In some implementations, the system can process the computer model using a grid model that includes all firmware updates. In some implementations, the system can process the computer model using a grid model that includes firmware updates applied in any combination. For example, if the system has three firmware updates, F1, F2, and F3, available, the system can process the computer model using only F1, F1 and F2, F1 and F3, F2 and F3, and F1, F2, and F3, or any subset of the combinations. Each instance that processes the computer results can generate simulation results.

[0043] The system can provide to the user simulation results indicating how the asset model functioned while using the firmware (230). The results can be included in user interface presentation data that causes the client device to display the simulation results when rendered by the client device. As described above, the simulation results can be provided by supplying or making available data including the simulation results including the user interface presentation data.

[0044] As further described above, the simulation results can include conditional values. Such conditional values can indicate whether a firmware update can be verified. For example, if the simulation results meet the conditions for all conditional values, the system can determine that the firmware update is valid.

[0045] In some implementations, the system can update the grid model. The system can provide simulation results, and in response to determining that the simulation meets acceptance criteria, the system can perform one or more operations. In some implementations, the operations can include updating the grid model. The acceptance criteria can, when met, be a set of predicates indicating that the updated firmware has operated properly (e.g., values are within an acceptable range). The predicates can be combined by boolean operations (AND, OR, NOT, NOR, etc.) to form compound predicates. In some implementations, in response to receiving an indication from the user that the simulation results are accepted, the system can update the grid model. In some implementations, the system can update the grid model when both acceptance criteria are met and when the user provides an acceptance indicator.

[0046] The system can update the grid model, for example, by storing the updated grid model in a database. In some implementations, the system can replace the previous grid model in the database with the updated grid model. In some implementations, the system can add the updated grid model to the database and store an indicator that the updated grid model is the current grid model.

[0047] In some implementations, in response to determining that acceptance criteria are met, the system can provide the user with a notification indicating that the simulation was successful. For example, the system can provide the notification by delivering a message using a conventional networking protocol (e.g., Transmission Control Protocol / Internet Protocol), or by providing user interface presentation data that displays a notification (e.g., a user interface message) indicating that the simulation was successful when rendered by a client device.

[0048] This specification has mainly described an electrical network, but this technique can be applied to other network types. For example, a computing network can include components such as routers, switches, cellular towers, wireless access points, etc. A failure caused by a firmware update in one network element can lead to a cascading failure across the entire network. Similarly, an Internet of Things (IoT) network can include a number of devices, such as various sensor types (notably cameras, temperature sensors, barometers, lidars, radars), actuators (for example, for locking or unlocking doors, triggering alarms, activating sensors, moving robotic devices, etc.), and an interconnected network. A defect introduced in one component (for example, a faulty sensor that transmits excessive data) can lead to a failure of the entire network.

[0049] Figure 3 is a block diagram of an exemplary computer system 300 that can be used to perform the operations described above. System 300 includes a processor 310, a memory 320, a storage device 330, and an input / output device 340. Each of the components 310, 320, 330, and 340 can be interconnected, for example, using a system bus 350. The processor 310 can process instructions for execution within the system 300. In one implementation, the processor 310 is a single-threaded processor. In another implementation, the processor 310 is a multi-threaded processor. The processor 310 can process instructions stored in the memory 320 or on the storage device 330.

[0050] The memory 320 stores information within the system 300. In one implementation, the memory 320 is a computer-readable medium. In one implementation, the memory 320 is a volatile memory unit. In another implementation, the memory 320 is a non-volatile memory unit.

[0051] The memory device 330 can provide large-capacity storage for the system 300. In one implementation, the memory device 330 is a computer-readable medium. In various different implementations, the memory device 330 can be, for example, a hard disk device, an optical disk device, a memory device shared via a network by a plurality of computing devices (e.g., a cloud memory device), or some other large-capacity memory device.

[0052] The input / output device 340 provides input / output operations for the system 300. In one implementation, the input / output device 340 can include one or more of a network interface device, such as an Ethernet card, a serial communication device, such as an RS-232 port, and / or a wireless interface device, such as an 802.11 card. In another implementation, the input / output device can include a driver device configured to receive input data and transmit output data to other input / output devices, such as a keyboard, a printer, and the display device 360. However, other implementations, such as mobile computing devices, mobile communication devices, set-top box television client devices, etc., can also be used.

[0053] Although an exemplary processing system is described in FIG. 3, the implementations of the subject matter and the functional operations described herein can be realized in other types of digital electronic circuits, including the structures disclosed herein and their structural equivalents, or in computer software, firmware, or hardware, or a combination of one or more of them.

[0054] Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, hardware, or in combinations of one or more of them, including the structures disclosed in this specification and their structural equivalents. Embodiments of the subject matter described in this specification can be implemented as one or more modules of computer program instructions encoded on a computer-readable medium for execution by, or to control the operation of, a data processing apparatus. The computer-readable medium may be a hard drive within a computer system, or an optical disk sold through a retail channel, or a product such as an embedded system. The computer-readable medium may be separately acquired and encoded with one or more modules of computer program instructions by, for example, distribution of the one or more modules of computer program instructions via a wired or wireless network. The computer-readable medium may be a machine-readable storage device, a machine-readable storage substrate, a memory device, or a combination of one or more of them.

[0055] The term "data processing apparatus" encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the relevant computer program, for example, processor firmware, a protocol stack, a database management system, an operating system, an execution environment, or a combination of one or more of them. In addition, the apparatus can use various different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

[0056] A computer program (also known as a program, software, software application, script, or code) can be written in any suitable form of programming language, including compiler-type or interpreter-type languages, declarative or procedural languages, and can be deployed in any suitable form as a stand-alone program or included as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily have to correspond to a file in a file system. The program can be stored within a portion of a file that holds other programs or data (such as one or more scripts stored in a markup language document), within a single file dedicated to the program in question, or within a plurality of coordinated files (such as files that store one or more modules, subprograms, or portions of code). A computer program can be executed on one computer or deployed to be executed on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

[0057] The processes and logical flows described herein can be executed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logical flows can also be executed by, for example, FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit) dedicated logic circuits, and the apparatus can also be implemented as, for example, FPGA or ASIC dedicated logic circuits.

[0058] As an example, a dedicated microprocessor may be mentioned as a processor suitable for executing a computer program. Generally, the processor will receive instructions and data from a read-only memory, a random access memory, or both. Essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also be operatively coupled to include, receive data from, transfer data to, or both, one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks. However, a computer need not have such devices. Further, a computer may be incorporated into another device, such as, by way of only a few examples, a cellular phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive, etc.). Examples of devices suitable for storing computer program instructions and data include all forms of non-volatile memory, such as semiconductor memory devices, e.g., EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), and flash memory devices, magnetic disks, e.g., internal hard disks or removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, dedicated logic circuitry.

[0059] To provide interaction with a user, embodiments of the subject matter described herein can be implemented on a computing device capable of providing information to the user. The information can be provided to the user in any form of sensory format, including visual, auditory, tactile, or combinations thereof. The computing device can be coupled to a display device, such as an LCD (liquid crystal display) display device, an OLED (organic light emitting diode) display device, another monitor, a head-mounted display device, etc., to display information to the user. The computing device can be coupled to an input device. Examples of input devices can include a touch screen, a keyboard, and a pointing device, such as a mouse or a trackball, through which a user can provide input to the computing device. Other types of devices can be similarly used to provide interaction with the user. For example, the feedback provided to the user can be any suitable form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and the input received from the user can be in any suitable form, including acoustic, voice, or tactile input.

[0060] A computing system can include clients and servers. The clients and servers are generally remote from each other and typically interact via a communication network. The relationship between clients and servers is created by computer programs that are executed on respective computers and have a client-server relationship with each other. Embodiments of the subject matter described herein can be implemented in, for example, a computing system that includes backend components as data servers, or includes middleware components, such as application servers, or includes frontend components, such as a client computer having a graphical user interface or a web browser through which a user can interact with an implementation of the subject matter described herein, or any combination of one or more such backend, middleware, or frontend components. The components of the system can be interconnected by any form or medium of digital data communication, such as a communication network. Examples of communication networks include local area networks (“LANs”) and wide area networks (“WANs”), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0061] While this specification contains many details, these should not be construed as limiting the scope of what is claimed or may be claimed, but rather as describing features specific to particular embodiments of the disclosed subject matter. Certain features described herein in the context of separate embodiments may also be implemented in combination within a single embodiment. Conversely, various features described in the context of a single embodiment may be implemented separately in multiple embodiments or in any suitable sub-combination. Further, features may be described above as acting in a particular combination and even initially claimed as such, but one or more features from a claimed combination may in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination. Accordingly, unless explicitly stated otherwise or as would be clear to one of ordinary skill in the art, any of the features of the above-described embodiments may be combined with any of the other features of the above-described embodiments.

[0062] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in a sequential order, or that all illustrated operations be performed, to achieve the desired results. In certain circumstances, multitasking and / or parallel processing may be advantageous. Further, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems may generally be integrated together in a single software product or packaged into multiple software products.

[0063] Thus, particular embodiments of the invention have been described. Other embodiments are within the scope of the following claims. For example, the operations recited in the claims may be performed in a different order and still achieve the desired results.

Claims

1. An electrical grid asset verification method, comprising: Obtaining a computer model of the power grid that includes a plurality of asset models for individual assets connected to the power grid, each asset model being configured to replicate the operation of a corresponding type of physical electrical grid asset, wherein a first asset model among the asset models includes a hardware emulator configured to execute firmware specific to the corresponding type of physical electrical grid asset, the obtaining of the computer model of the power grid; Providing an asset interface configured to enable a user to modify the first asset model; Receiving, from the user via the asset interface, modified firmware for the first asset model; Processing the computer model using a simulation engine to obtain simulation results, the simulation engine being configured to simulate the operation of the individual assets of the computer model, including the operation of the first asset model according to the modified firmware associated with the first asset model, the processing of the computer model; Providing simulation results indicating how the first asset model functioned while using the modified firmware for display to the user; An electrical grid asset verification method including the above steps.

2. The electrical grid asset verification method according to claim 1, further comprising determining that the modified firmware is valid in response to determining that the simulation results meet verification criteria.

3. The electrical grid asset verification method according to claim 1 or 2, wherein the modified firmware includes replacement of the firmware.

4. The electrical grid asset verification method according to any one of claims 1 to 3, wherein the modified firmware includes configuration settings of the firmware.

5. The asset interface is further configured to enable the user to modify a second asset model, and the method includes: Receiving, from the user via the asset interface, second modified firmware for the second asset model; Processing the computer model using the simulation engine to obtain simulation results, wherein the simulation engine is configured to simulate the operations of the individual assets of the computer model, including: (i) the operation of the first asset model according to the modified firmware associated with the first asset model; and (ii) the operation of the second asset model according to the second modified firmware associated with the second asset model. The electric grid asset verification method according to any one of claims 1 to 4, further comprising.

6. The method for verifying an electric grid asset according to claim 5, wherein processing the computer model includes executing the simulation engine on the computer model in a sandbox environment.

7. Determining that the specifications of the modified firmware satisfy the specifications of the assets described by the asset model. Applying the modified firmware to the assets. The electric grid asset verification method according to any one of claims 1 to 6, further comprising.

8. The method for verifying an electric grid asset according to claim 7, wherein the specifications of the assets described by the asset model include the type, manufacturer, or version of the assets.

9. The electric grid asset verification method according to any one of claims 1 to 8, further comprising performing an operation in response to determining that the simulation results meet acceptance criteria.

10. The method for verifying an electric grid asset according to claim 8, wherein the operation includes updating the computer model of the power grid.

11. The method for verifying an electric grid asset according to claim 8, wherein the operation includes providing a user with a notification indicating that the simulation was successful.

12. The method for verifying an electric grid asset according to any one of claims 1 to 11, wherein simulating the operations of the individual assets of the computer model includes executing firmware.

13. Executing firmware includes Receiving an input. To generate results that simulate the results generated by the firmware when executed on physical hardware and executed for the same input, performing an operation using the firmware on the input; The method for verifying an electric grid asset according to claim 10, including this.

14. A system comprising one or more computers and one or more storage devices storing instructions, wherein when the instructions are executed by the one or more computers, the one or more computers are caused to Obtaining a computer model of the power grid including a plurality of asset models for individual assets connected to the power grid, each asset model being configured to replicate the operation of a corresponding type of physical power grid asset, wherein a first asset model among the asset models includes a hardware emulator configured to execute firmware specific to the corresponding type of physical power grid asset, obtaining the computer model of the power grid; Providing an asset interface configured to enable a user to modify the first asset model; Receiving, from the user via the asset interface, modified firmware of the first asset model; Processing the computer model using a simulation engine to obtain simulation results, the simulation engine being configured to simulate the operation of the individual assets of the computer model including the operation of the first asset model according to the modified firmware associated with the first asset model, processing the computer model; Providing simulation results indicating how the first asset model functioned while using the modified firmware for display to the user; A system that causes an operation including this to be executed.

15. The operation is The system according to claim 14, further including determining that the modified firmware is valid in response to determining that the simulation results meet verification criteria.

16. The system according to claim 14 or 15, wherein the changed firmware includes (i) a replacement or (ii) at least one of the configurations of the firmware.

17. The asset interface is further configured to enable a user to change a second asset model, and the operation receiving, from the user through the asset interface, a second changed firmware for the second asset model; processing the computer model using the simulation engine to obtain simulation results, the simulation engine being configured to simulate the operations of the individual assets of the computer model including (i) the operation of the first asset model according to the changed firmware associated with the first asset model and (ii) the operation of the second asset model according to the second changed firmware associated with the second asset model, the system according to any one of claims 14 to 16.

18. A non-transitory computer-readable storage medium storing instructions which, when executed by one or more computers, cause the one or more computers to obtain a computer model of the power grid including a plurality of asset models for individual assets connected to the power grid, each asset model being configured to replicate the operation of a corresponding type of physical power grid asset, the first asset model of the asset models including a hardware emulator configured to execute firmware unique to the corresponding type of physical power grid asset, obtaining the computer model of the power grid; providing an asset interface configured to enable a user to change the first asset model; receiving, from the user through the asset interface, the changed firmware of the first asset model; Processing the computer model using a simulation engine to obtain simulation results, wherein the simulation engine is configured to simulate the operation of the individual assets of the computer model, including the operation of the first asset model according to the modified firmware associated with the first asset model; Providing simulation results indicating how the first asset model functioned while using the modified firmware for display to the user; A non-transitory computer-readable storage medium for causing the execution of operations including the above.

19. The operations are The non-transitory computer-readable storage medium according to claim 18, further comprising determining that the modified firmware is valid in response to determining that the simulation results meet verification criteria.

20. The asset interface is further configured to enable a user to modify a second asset model, and the operations are Receiving, from the user through the asset interface, second modified firmware for the second asset model; Processing the computer model using the simulation engine to obtain simulation results, wherein the simulation engine is configured to simulate the operation of the individual assets of the computer model, including (i) the operation of the first asset model according to the modified firmware associated with the first asset model and (ii) the operation of the second asset model according to the second modified firmware associated with the second asset model; The non-transitory computer-readable storage medium according to claim 18 or 19, further comprising the above.

Images