Cloud-based verification of electrical grid components

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] (Claim of Priority) This application claims the priority of U.S. Patent Application No. 63 / 359,536, filed on July 8, 2022, under 35 U.S.C. § 119(e), and the entire disclosure thereof is incorporated herein by reference.

Background Art

[0002] Electrical systems include a wide range of interconnected components 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 (RAS), 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 asset, and the hardware emulator can be configured to execute the component firmware. The system can receive changes to the firmware and verify components of the electrical system by simulating the electrical system using the changed firmware.

[0004] Certain embodiments of the subject matter described herein can be implemented to achieve one or more of the following advantages. The techniques described below can be used to simulate the results of modifying the firmware of components of an electric grid, thereby reducing the likelihood of firmware defects causing errors in the electric grid. The techniques further enable simulation without requiring the distribution of hardware components, thereby reducing costs and the possibility of malicious actors reverse engineering the hardware components. In addition, the techniques enable users 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 related to firmware updates being introduced into actual hardware assets installed in a power system.

[0005] One embodiment is characterized by obtaining a computer model of a power grid. The computer model may include asset models of individual assets connected to the power grid. Each asset model may be configured to replicate the operation of a corresponding type of physical electrical grid asset. A first asset model among the asset models may include a hardware emulator configured to run firmware specific to the corresponding type of physical electrical grid asset. An asset interface may be provided, configured to allow a user to modify the first asset model. The modified firmware for the first asset model may be received from the user via the asset interface. The computer model may be processed using a simulation engine to obtain simulation results, and the simulation engine may be configured to simulate the operation of 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 showing how the first asset model behaved while using the modified firmware may be provided for display to the user. Other implementations of this embodiment include corresponding systems, devices, and computer programs, which are configured to perform the operation of the method and are encoded on a computer storage device.

[0006] It may include one or more of the following features: The modified firmware may be determined to be valid in response to the simulation results determining that the verification criteria are met. The modified firmware may include firmware replacement. The modified firmware may include firmware configuration settings. The asset interface may be configured to allow a user to modify a second asset model, and may further include receiving a second modified firmware for the second asset model from the user via the asset interface. The computer model may be processed using a simulation engine to obtain simulation results, and the simulation engine is configured to simulate the operation of individual assets in 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 specifications of the modified firmware may be determined to satisfy the asset specifications described by the asset model, and the modified firmware may be applied to the asset. The asset specifications may include the asset type, manufacturer, or version. An action may be performed in response to the simulation results determining that the acceptance criteria are met. The action may include updating the computer model of the power grid. Actions may include providing the user with a notification indicating that the simulation was successful. Simulating the behavior of individual assets in a computer model may include running firmware. Running firmware may include accepting input and using the firmware to perform actions on the input, producing results that simulate the results that the firmware would produce when running on physical hardware and on the same input. Processing a computer model may include running a simulation engine on the computer model in a sandbox environment.

[0007] Details of one or more embodiments of the subject matter described herein are shown in the accompanying drawings and the following description. Other features, aspects, and advantages of the present invention will become apparent from the specification, drawings, and claims. [Brief explanation of the drawing]

[0008] [Figure 1] This figure shows an exemplary environment for cloud-based electrical grid component verification. [Figure 2] This is a flowchart illustrating an exemplary process for cloud-based electrical grid component verification. [Figure 3] This is a block diagram of an exemplary computer system. [Modes for carrying out the invention]

[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 control, and alarm systems. The operation of one component can affect the operation of others. For example, a PPC coordinates and controls networked inverters within a power plant. Therefore, when a change is planned for a component, it is crucial to test the modified version of the component in an environment that includes other connected elements to ensure that the change does not adversely affect anywhere in the system. To avoid potentially catastrophic failures, updates should only be deployed to the production environment after thorough testing has been completed.

[0010] The operation of many components is partially controlled by firmware, which is software that provides a low level of control over the specific hardware of the component. Firmware can be updated to enable new hardware capabilities and address any defects detected in a particular firmware version. However, as mentioned above, to reduce the likelihood that a firmware defect could cause failure somewhere in the system, firmware updates should be tested in an environment that simulates the overall production environment before being 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 components under test are connected to an HIL simulator that provides electrical emulations of sensors and actuators. These electrical emulations act as an interface between the plant simulation and the components under test. The values ​​of each electrically emulated sensor are controlled by the plant simulation and read by the embedded system being tested.

[0012] However, HIL systems have several drawbacks. Firstly, simulators are specific to individual electrical components, and if a simulator does not exist for a particular component, HIL cannot be used. Secondly, HIL simulators are loaded with mathematical representations of other components in the environment, and if these components are updated (e.g., component firmware is updated), the HIL simulator can become outdated. Thirdly, HIL simulators are physically large, which can hinder their use in real-world deployments.

[0013] This specification describes a technique for cloud-based verification of electrical grid components, also known as "Firmware-In-the-Loop In the Cloud" (FILIC). A verification system that performs the technique described herein may include a cloud-based verification engine that includes a grid model simulating the overall structure of the electrical grid. The grid model may include asset models for each type of electrical component in the relevant environment.

[0014] By providing FILIC, the technique described herein enables firmware developers to test firmware updates in the context of a grid model without requiring the presence of expensive hardware such as HIL systems. In addition, in contrast to conventional techniques in which a firmware update is tested against one version of the firmware for each of the other grid components, the technique herein enables simulation of when multiple electrical components apply a firmware update simultaneously.

[0015] Figure 1 shows an exemplary environment for cloud-based electrical grid component verification. The environment may include an electrical grid component verification system 110 and one or more client devices 105a, 105n (collectively referred to as 105).

[0016] The electric grid component verification system 110 may 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 results provision engine 150. The electric grid component verification system 110 may reside in a single location or on one or more computer servers that are geographically distributed and connected by a network such as the Internet or an intranet. For example, the electric grid component verification system 110 may run on a cloud platform. The cloud platform may include computing resources such as servers, storage, databases, and networking, and may reside in a single data center or be distributed across multiple data centers connected by a network such as the Internet or an intranet, which may be geographically separated.

[0017] The power grid model acquisition engine 120 can acquire a power grid model 180a (for brevity, "grid model"). The power grid model acquisition engine 120 may include an Application Programming Interface (API) that allows users of system 110 to provide the grid model 180a or the location of the model. In some implementations, the API may 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 electric grid can be used by many users of system 110. For example, the power grid model acquisition engine 120 can access a common electric grid model for a particular geographical area (e.g., California) for all users who wish to test firmware on different physical hardware assets connected to the electric grid within that geographical area.

[0018] Grid models 180a and 180b (collectively referred to as 180) may include multiple asset models for individual assets connected to the power grid, and descriptions of the interconnections between assets. Each asset model may be configured to replicate the operation of a corresponding type of physical electric grid asset, and each asset model may be used to simulate the operation of an asset or type of asset. Asset models may include hardware emulators, which may be configured to run firmware specific to the corresponding type of physical electric grid asset.

[0019] Executing firmware can include accepting inputs and performing actions specified by the firmware on those inputs to produce results that simulate the results the firmware would produce if it were running on physical hardware and performing actions on the same inputs. Inputs can be simulated inputs, such as data captured when operating a real power grid, random data generated according to parameters encountered in a real power grid (e.g., voltages fluctuating within a few known parameters), or data generated by human operators.

[0020] The grid model 180 of a power grid can be represented as a graph. Nodes in the graph can represent assets, and each node can contain information about the asset, such as its identifier, asset type, asset manufacturer and version, installation date, and information about the services performed on the asset. Edges in the graph can represent connections between assets and may include an indication of the direction of power flow.

[0021] The asset interface engine 130 can receive modified firmware 185. Modifications can be of numerous types, including firmware replacement, replacement of one or more components of firmware, addition or deletion of firmware components, modification of one or more firmware configuration settings, provision of initial values ​​for configuration settings, other firmware modifications, or any combination thereof. Modified firmware may include the type of modification, the specific asset to which the modification should apply, a description of the class of assets to which the modification should apply (e.g., all transformers of a particular manufacturer and version), modification data (e.g., firmware updates, configuration settings, etc.), and other data related to the modification. In some implementations, the asset interface engine 130 may include an API that allows a user of system 110 to provide the modified firmware 185 or the location (e.g., URI) of the modified firmware 185.

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

[0023] The model adjustment engine 135 can accept 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 generate the modified grid model 180b by applying the modified firmware 185 to one or more assets in the grid model 180a, as will be further described below.

[0024] In some implementations, the model tuning 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., defined by component 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 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 to 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 tuning engine 135 can apply multiple instances of firmware updates 185 to multiple electrical components. The system can accept multiple firmware updates 185 and apply the updates to create a modified grid model 180b. For example, the model tuning 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 firmware update 185. In response to receiving an instruction for a selected update, the model adjustment engine 135 can apply the selected update and 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, for example, selected 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 using the changed firmware 185. 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 may include instantaneous values ​​and magnitudes of electrical parameters (e.g., current, voltage, etc.) at one or more points within the modified grid model 180b over one or more time periods. In some implementations, the simulation result 190 may include conditional values. For example, if the voltage at a particular asset meets a configured value, the simulation result 190 may include a display such as highlighting the asset in red. The simulation result 190 may also include animations showing the simulation results over time, audio prompts indicating that thresholds have been met, etc.

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

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

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

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

[0034] The system can obtain a power grid model (205). The system can provide an API configured to accept 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 may provide an asset interface configured to allow users to modify the asset model (210). As described above, in some implementations, the system may provide an asset interface that provides user interface presentation data that allows users to modify the asset model. In some implementations, the system may provide an asset interface, such as a web interface, that accepts changes to the asset model.

[0036] The system can receive modified firmware (215). In some implementations, the system can provide user interface presentation data, when rendered by a client device (e.g., by a web browser running on a laptop or desktop computer), 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, load it into the corresponding model, and replace the existing firmware. In some implementations, the system can provide user interface presentation data, when rendered by a client device, that allows a user to provide the system with firmware associated with a particular asset model (e.g., using a hypertext transfer protocol). In some implementations, the system can provide user interface presentation data, when rendered by a client device, that allows a user to specify firmware settings associated with a particular asset model. In some implementations, the system can provide an application programming interface (API) that can be invoked by a client (a user or another program) supplying updated firmware for an asset type or a specific asset present in the environment.

[0037] In some implementations, a system can receive multiple instances of modified firmware. Instances of modified firmware can be associated with different asset models, and / or multiple instances of modified firmware can be associated with a single 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 other examples, one instance of modified firmware may contain components included in the firmware for one asset model, and a second instance of modified firmware may contain the firmware configuration settings for that asset model.

[0038] Upon receipt, the system can modify the firmware of at least one asset model in the grid model (220). The system can first determine which asset in the grid model to which the firmware change (or changes) applies by comparing the specification of the firmware change with the specification of the asset in the grid model. The system can first identify any asset in the grid model using the identifier specified by the firmware change. The system can further identify any asset in the grid model that has a specification that satisfies the specification in the firmware change. For example, if the firmware change specifies an asset type, asset manufacturer, and asset version, the system can identify all assets in the grid model that have the specified asset type, asset manufacturer, and asset version. In another example, if the firmware change specifies an asset type and asset manufacturer, the system can identify all assets in the grid model that have the specified asset type and manufacturer. In some implementations, the firmware change may include a more complex specification (e.g., a regular expression) that identifies an asset in the grid model. In such implementations, the system can evaluate the specification to determine the relevant asset. The system can determine the assets associated with all firmware changes received in operation 215.

[0039] Once the system identifies an asset, it can apply the modified firmware. As mentioned above, the modified firmware may include instructions for the type of modification (e.g., configuration change, firmware replacement, etc.). The system can determine the type of modification and perform the appropriate modification. For example, if firmware configuration settings are set or changed, the system can set or change the settings; if firmware components are replaced, the system can remove the original components from the firmware and insert the new components; 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 behavior of individual assets in a computer grid model using simulated electrical inputs. In some implementations, the system can obtain 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 simulated electrical inputs randomly or pseudo-randomly. In some implementations, the system can generate simulated electrical inputs randomly or pseudo-randomly according to a rule (e.g., a particular load must be between a minimum and a maximum value) or a configured distribution.

[0041] Once the asset model and simulated electrical inputs are loaded, the system runs the simulation by processing the asset model using the simulation engine to obtain simulation results. Simulation results can be generated by evaluating one or more asset models against the simulated input data. As described above, the asset model may include a hardware emulator capable of running firmware designed for a particular asset or asset type. In response to the receipt of simulated electrical inputs, the hardware emulator can run the firmware and generate results, which may include changes in the internal state of the simulated asset and electrical outputs similar in manner to the function of the physical asset.

[0042] As described above, the system can process the computer model on one or more grid models containing 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 containing all firmware updates. In some implementations, the system can process the computer model using a grid model containing firmware updates applied in any combination. For example, if the system has three available firmware updates, F1, F2, and F3, the system can process the computer model using only F1, F1 and F2, F1 and F3, F2 and F3, and any subset of F1, F2, and F3, or any combination thereof. Each instance processing the computer results can generate simulation results.

[0043] The system may provide the user with simulation results showing how the asset model performed while using the firmware (230). The results may be included in user interface presentation data that displays the simulation results to the client device when rendered by the client device. As described above, the simulation results may be provided by supplying or making available data that includes the simulation results, which also includes the user interface presentation data.

[0044] Furthermore, as mentioned above, the simulation results may include conditional values. Such conditional values ​​can indicate whether a firmware update can be verified. For example, if the simulation results satisfy 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 actions. In some implementations, actions may include updating the grid model. Acceptance criteria can be a set of predicates (e.g., values ​​fall within acceptable limits) that, when met, indicate that the updated firmware is functioning correctly. Predicates can be combined using Boolean operations (AND, OR, NOT, NOR, etc.) to form compound predicates. In some implementations, the system can update the grid model in response to receiving an instruction from the user that the simulation results are accepted. 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 the 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, upon determining that acceptance criteria have been met, the system may provide a notification to the user indicating that the simulation was successful. For example, the system may provide this notification by delivering a message using conventional networking protocols (e.g., Transmission Control Protocol / Internet Protocol), or by providing user interface presentation data that, when rendered by a client device, displays a notification (e.g., a user interface message) indicating that the simulation was successful.

[0048] While this specification has primarily described electrical networks, the techniques can be applied to other network types. For example, computing networks can include components such as routers, switches, cellular towers, and wireless access points. 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 numerous devices, including various sensor types (among others, cameras, temperature sensors, barometers, lidars, and radar), actuators (e.g., for locking or unlocking doors, triggering alarms, activating sensors, moving robotic devices, etc.), and interconnected networks. A defect introduced in one component (e.g., a faulty sensor transmitting excessive data) can lead to a failure across 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. The system 300 includes a processor 310, memory 320, storage device 330, and 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 to be executed 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 memory 320 or on storage device 330.

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

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

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

[0053] An exemplary processing system is shown in Figure 3, but the subject matter and functional operations described herein can be implemented 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 these.

[0054] The subject matter and functional embodiments described herein can be implemented in digital electronic circuits, computer software, firmware, or hardware, or in a combination thereof, including the structures disclosed herein and their structural equivalents. Embodiments of the subject matter described herein can be implemented as one or more modules of computer program instructions encoded on a computer-readable medium for execution by a data processing device or for controlling the operation of a data processing device. The computer-readable medium may be a hard drive in a computer system, an optical disc sold through retail channels, or a product such as an embedded system. The computer-readable medium may be separately acquired and encoded in one or more modules of computer program instructions, such as by distribution of one or more modules of computer program instructions over a wired or wireless network. The computer-readable medium may be a machine-readable storage device, a machine-readable storage board, a memory device, or a combination thereof.

[0055] The term "data processing device" encompasses all devices, machines, and equipment for processing data, including, for example, programmable processors, computers, or multiple processors or computers. In addition to hardware, a device may include code that creates an execution environment for the computer program in question, such as processor firmware, protocol stacks, database management systems, operating systems, execution environments, or code comprising one or more of these. Furthermore, a device may utilize various different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

[0056] Computer programs (also known as programs, software, software applications, scripts, or code) can be written in any preferred form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed as standalone programs or in any preferred form, including modules, components, subroutines, or other units suitable for use in a computing environment. Computer programs do not necessarily have to correspond to files in a file system. A program may be stored in part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in a set of coordinated files (e.g., a file storing one or more modules, subprograms, or parts of code). Computer programs can be deployed to run on one computer, or on multiple computers located in one site or distributed across multiple sites and interconnected by a communication network.

[0057] The processes and logic flows described herein can be executed by one or more programmable processors that run one or more computer programs to perform a function by acting on input data and producing outputs. The processes and logic flows can also be executed by dedicated logic circuits, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits), and the devices can also be implemented as dedicated logic circuits, such as FPGAs or ASICs.

[0058] A suitable processor for executing computer programs is, for example, a dedicated microprocessor. Generally, a processor will receive instructions and data from read-only memory, 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 include one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, or will be operablely coupled to them to receive data from them, transfer data to them, or both. However, a computer is not required to have such devices. Furthermore, a computer can be incorporated into another device, for example, a mobile 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 (such as a universal serial bus (USB) flash drive). Suitable devices for storing computer program instructions and data include, for example, semiconductor memory devices such as EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), and flash memory devices, magnetic disks such as internal hard disks or removable disks, magneto-optical disks, and all forms of non-volatile memory, including CD-ROMs and DVD-ROMs. Processors and memory may be complemented by or incorporated into dedicated logic circuits.

[0059] To provide user interaction, embodiments of the subject matter described herein can be implemented on a computing device capable of providing information to the user. Information can be provided to the user in any form of sensory format, including visual, auditory, tactile, or a combination thereof. The computing device may 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., for displaying information to the user. The computing device may also be coupled to an input device. Input devices may include touchscreens, keyboards, and pointing devices, such as a mouse or trackball, from which the user can provide input to the computing device. Other types of devices may similarly be used to provide user interaction; for example, feedback provided to the user may be any preferred form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and input from the user may be received in any preferred form, including acoustic, speech, or tactile input.

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

[0061] This specification includes many details of implementations, which should be interpreted not as limiting the scope of claims or claims, 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 realized in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may be realized individually in multiple embodiments or in any preferred partial combination. Furthermore, features may be described above as acting in a particular combination, and may even be initially claimed as such, but one or more features from a claimed combination may, in some cases, be removed from the combination, and the claimed combination may be directed towards a partial combination or a variation of a partial combination. Thus, unless expressly otherwise provided or clearly indicated by the knowledge of those skilled in the art, any feature of the above embodiments may be combined with any other feature of the above embodiments.

[0062] Similarly, although the operations are depicted in a specific order in the diagrams, this should not be understood as requiring that such operations be performed in a specific or sequential order shown, or that all exemplified operations be performed, in order to achieve the desired result. In certain circumstances, multitasking and / or parallel processing may be advantageous. Furthermore, 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 can generally be integrated together in a single software product or packaged in multiple software products.

[0063] Having thus described specific embodiments of the present invention, other embodiments fall within the scope of the following claims. For example, the operations described in the claims can be performed in a different order, and the desired results can still be achieved.

Claims

1. A method for verifying electric grid assets, The system obtains a computer model of the power grid, which includes multiple 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, and the first asset model among the asset models includes a hardware emulator configured to run firmware specific to the corresponding type of physical electrical grid asset. The system provides an asset interface configured to allow a user to modify the first asset model, The system receives, via the asset interface, the modified firmware of the first asset model from the user, The system processes 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 in accordance with the modified firmware associated with the first asset model. The system provides, for display to the user, simulation results showing how the first asset model functioned while using the modified firmware, A method for verifying electric grid assets, including the verification of such assets.

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

3. The modified firmware is the method for verifying electric grid assets according to claim 1, comprising the replacement of the firmware.

4. The modified firmware includes configuration settings for the firmware, as described in claim 1, for the electric grid asset verification method.

5. The asset interface is further configured to allow the user to modify a second asset model. The method described above is The system receives, through the asset interface, a second modified firmware for the second asset model from the user, The system processes 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 method for verifying electric grid assets according to claim 1, further comprising:

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

7. The system determines that the modified firmware specification satisfies the specification of the asset described by the asset model, The system applies the modified firmware to the asset, The method for verifying electric grid assets according to claim 1, further comprising:

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

9. The electric grid asset verification method according to claim 1, further comprising performing an action in response to the system determining that the simulation results meet the acceptance criteria.

10. The electric grid asset verification method according to claim 9, wherein performing the action in response to determining that the simulation results meet the acceptance criteria includes updating the computer model of the power grid.

11. The electric grid asset verification method according to claim 9, wherein performing the action in response to determining that the simulation results meet the acceptance criteria includes providing a notification to the user that the simulation was successful.

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

13. Running the firmware is Accepting input and To run on physical hardware and generate results that simulate the results that the firmware generates when it is run on the same input, the firmware is used to perform an operation on the input, The method for verifying electric grid assets according to claim 12, including the method described in claim 12.

14. A system comprising one or more computers and one or more storage devices for storing instructions, wherein when an instruction is executed by one or more computers, the one or more computers shall Obtaining a computer model of the power grid, which includes multiple 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, and a first asset model among the asset models including a hardware emulator configured to run firmware specific to the corresponding type of physical electrical grid asset; To provide an asset interface configured to allow a user to modify the first asset model, The system receives the modified firmware of the first asset model from the user via the asset interface, Processing the computer model using a simulation engine to obtain simulation results, wherein the simulation engine is configured to simulate the behavior of the individual assets of the computer model, including the behavior of the first asset model in accordance with the modified firmware associated with the first asset model. To display to the user, provide simulation results showing how the first asset model functioned while using the modified firmware, A system that performs actions including those mentioned above.

15. When the instruction is executed by one or more computers, the one or more computers shall The system according to claim 14, further comprising determining that the modified firmware is valid in response to the determination that the simulation results satisfy the verification criteria.

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

17. The asset interface is further configured to allow the user to modify a second asset model. When the instruction is executed by one or more computers, the instruction will be directed to one or more computers. The system receives a second modified firmware for the second asset model from the user through the asset interface. The system according to any one of claims 14 to 16, further comprising processing the computer model using the simulation engine to obtain simulation results, wherein the simulation engine is configured to process the computer model, which includes (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.

18. A non-temporary computer-readable storage medium for storing instructions, wherein when an instruction is executed by one or more computers, the instructions are stored in the one or more computers. Obtaining a computer model of the power grid, which includes multiple 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, and a first asset model among the asset models including a hardware emulator configured to run firmware specific to the corresponding type of physical electrical grid asset; To provide an asset interface configured to allow a user to modify the first asset model, The system receives the modified firmware of the first asset model from the user via the asset interface, Processing the computer model using a simulation engine to obtain simulation results, wherein the simulation engine is configured to simulate the behavior of the individual assets of the computer model, including the behavior of the first asset model in accordance with the modified firmware associated with the first asset model. To display to the user, provide simulation results showing how the first asset model functioned while using the modified firmware, A non-temporary computer-readable storage medium that enables the execution of operations including [specific actions].

19. When the instruction is executed by one or more computers, the one or more computers shall The non-temporary computer-readable storage medium according to claim 18, further comprising determining that the modified firmware is valid in response to the determination that the simulation results satisfy the verification criteria.

20. The asset interface is further configured to allow the user to modify a second asset model. When the instruction is executed by one or more computers, the instruction will be directed to one or more computers. The system receives a second modified firmware for the second asset model from the user through the asset interface. A non-temporary computer-readable storage medium according to claim 18 or 19, further comprising processing the computer model using the simulation engine to obtain simulation results, wherein the simulation engine is configured to process the computer model, which includes (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.

Images