integration structure to facilitate communication with a central authority that manages an industry

专利摘要:
INTELLIGENT NETWORK The present invention relates to a network intelligence system that may include a plurality of sensors located throughout an industry system. The sensors can obtain data related to various aspects of the industry network. The network intelligence system can include system endpoint intelligence and system infrastructure intelligence. System endpoints and system infrastructure intelligences can provide distributed intelligence allowing localized decision making to be made within the industry system based on response to system operation and occurrences. Network intelligence can include a portion of centralized intelligence to communicate with endpoint and infrastructure intelligence. The centralized intelligence part can provide answers at a localized level of the system or at a global level of the system.
公开号:BR112012023696B1
申请号:R112012023696-2
申请日:2011-03-16
公开日:2021-01-05
发明作者:John Dorn；Jeffrey D. Taft
申请人:Accenture Global Services Limited；
IPC主号:

专利说明:

PRIORITY CLAIM
[001] This application claims the priority benefit of US Patent Application Serial No. 12/830,053 filed on July 2, 2010 and US Provisional Patent Application Serial No. 61/315, 897, filed on March 19, 2010, both incorporated herein by reference. BACKGROUND OF THE INVENTION Field of the Invention
[002] The present invention refers generally to a system and method for managing an industry network and, more particularly, to a system and method for collecting data in different parts of the industry network and analyzing the data collected in the sense to manage the industry network. Related Technique
[003] Several Industries have networks associated with them. Industries can include utility companies, telecommunications, vehicle displacement (such as air travel, rail travel, car travel, bus travel, etc.), and energy exploration (such as oil wells, oil wells, natural gas, etc.)
[004] An industry like this is the utility industry that manages an electricity grid. The electric power network can include any or all of the following: electric power generation, electric power transmission and electricity distribution. Electricity can be generated using generating stations, such as a coal power plant, a nuclear power plant, etc. For efficiency purposes, the electrical energy generated is raised to a very high voltage (such as 345K Volts) and transmitted from end to end in transmission lines. Transmission lines can transmit energy over long distances, such as over state lines or across international borders, until it reaches its wholesale customer, which may be a company that has the local distribution network. The transmission lines can end at a transmission substation, which can reduce the very high voltage to an intermediate voltage (such as 138k Volts). From a transmission substation, smaller transmission lines (such as subtransmission lines) transmit the intermediate voltage to distribution substations. In distribution substations, the intermediate voltage can again be reduced to a "medium voltage" (such as from 4K Volts to 23K Volts). One or more supply circuits may emanate from the distribution substations. For example, four to dozens of power circuits can come from the distribution substation. The supply circuit is a 3-phase circuit comprising four wires (three wires for each of the 3 phases and one wire for the neutral). Feeding circuits can be run either over the ground (on electric poles) or underground. The voltage in the supply circuits can be captured periodically using distribution transformers, which reduce the "medium voltage" voltage to the consumer voltage (such as 120V). The consumer voltage can then be used by the consumer.
[005] One or more energy companies can manage the electricity network, including fault management, maintenance and improvements related to the electricity network. However, the management of the electricity grid is often inefficient and costly. For example, a power company that controls the local distribution network can manage faults that can occur in the supply circuits or in circuits, called side circuits, that branch out from the supply circuits. The management of the local distribution network often relies on calls from consumers when there is a drop in supply or depends on field workers who analyze the local distribution network.
[006] Energy companies have been trying to improve the electricity grid using digital technology, sometimes called "smart grid." For example, smarter meters (sometimes called "smart meters") is a type of advanced meter that identifies consumption in more detail than a conventional meter. The smart meter can then communicate this information via some network back to the local utility company for monitoring and billing (telemetry) purposes. While these recent advances in improving the electricity grid are beneficial, further progress is needed. It has been reported that in the United States alone, half of the production capacity is not used, half of the capacity of the long-distance transmission network is not used, and two-thirds of its local distribution is not used. Therefore, there is a clear need to improve the management of the electricity grid.
[007] Another industry like this is the vehicle displacement industry. The vehicle displacement industry in general is concerned with managing the movement of one or more types of means of transport, such as an airplane, train, automobile, bus, etc. For example, the railway industry includes railway lines, trains that run on railway lines, a central control and a network to control train / train lines. The network can include sensors to detect the various parts of the railway lines, the means by which it communicates with the central control and receives communication from it and the means by which to control the railway lines. The network for the railway industry is usually primitive. Specifically, the network limits the type of sensors used, the means by which it communicates with the central control and receives communication from it and the ability to control the railway lines. Therefore, there is a clear need to improve the management of railway lines. BRIEF SUMMARY OF THE INVENTION
[008] An intelligent network is provided to improve the management of an industry system. The smart grid can be customized and applied to one or more industries. Examples include applications for the utility and vehicle travel industry (such as air travel network, rail travel network, car travel network, bus travel network, etc.). The intelligent network can also be customized and applied to a telecommunications network and for energy exploration.
[009] An intelligent network can include one or more terminals of the system. System terminals can include one or more endpoint sensors to monitor various conditions in an industry system and generate data indicative of the conditions. System endpoints can include endpoint analytics to process system endpoint data and generate any appropriate decisions based on the data.
[0010] The smart grid can include a system infrastructure, including one or more infrastructure sensors to monitor various conditions of the industry system infrastructure and generate data indicative of the conditions. The system infrastructure can include infrastructure analytics to process the data and generate any appropriate decisions based on the data. The system infrastructure can also receive data from the system's terminals to generate appropriate decisions.
[0011] System terminals and system infrastructure can generate event data indicative of an occurrence of interest within the industry system. System terminals and system infrastructure can also generate operational and non-operational data indicative of the industry system. The smart grid can include one or more buses to provide event data and operational / non-operational data for a smart grid network core. The network core can include system analytics to analyze the data received and generate decisions that can be localized or global within the industry system. The network core can also include a data set used to store the received data in order to retrieve it for later review and analysis. The network core can also include system controls used to control various aspects of the industry system. System controls can be performed when several decisions have been made and may require manipulation of the system. The smart grid can also include a business system communicating with the network core.
[0012] Other systems, methods, characteristics and advantages will be, or will become, evident to an individual with skill in the technique after examining the figures below and the detailed description. It is intended that all, systems, methods, characteristics and additional advantages, are included in this description, are within the scope of the invention and are protected by the following claims. BRIEF DESCRIPTION OF THE DRAWINGS
[0013] Figures 1A-C are block diagrams of an example of the global architecture for an electric power network.
[0014] Figure 2 is a block diagram of the Nucleus of the Intelligent Network Data Company (INDE) represented in Figure 1.
[0015] Figures 3A-C are block diagrams of another example of the global architecture for an electrical network.
[0016] Figure 4 is a block diagram of the INDE SUBSTATION represented in figures 1 and 3.
[0017] Figures 5A-B are block diagrams of the INDE DEVICE represented in Figures 1A-C and 3A-C.
[0018] Figures 6A, 6B and 6C are a block diagram of yet another example of the global architecture of an electric power network.
[0019] Figure 7 is a block diagram of yet another example of the global architecture of an electricity network.
[0020] Figure 8 is a block diagram including a list of some examples of observability processes.
[0021] Figures 9A-B illustrate flow diagrams of Measurement Processes and Operations of the State Network.
[0022] Figure 10 illustrates a flow diagram of non-operational data processes.
[0023] Figure 11 illustrates a flow diagram of the event management processes.
[0024] Figures 12A-C illustrate flow diagrams of the Demand Response (DR) signaling processes.
[0025] Figures 13A-B illustrate flow diagrams of the fall intelligence processes.
[0026] Figures 14A-C illustrate the flow diagrams of the failure intelligence processes.
[0027] Figures 15A-B illustrate the flow diagrams of the Meta-data management processes.
[0028] Figure 16 illustrates a flow diagram of the notification agent processes.
[0029] Figure 17 illustrates a flow diagram of the Meter's data collection processes (AMI).
[0030] Figures 18A-D are an example of an entity relationship diagram, which can be used to represent the baseline connectivity database.
[0031] Figures 19A-B illustrate an example of a graphical progress flow diagram.
[0032] Figure 20 is a block diagram of an example of a smart grid.
[0033] Figures 21A-21C is a block diagram of an example of the global architecture for INDE architecture.
[0034] Figure 22 is a block diagram of the NUCLEUS INDE represented in Figure 21.
[0035] Figures 23A-23C are block diagrams of another example of the global INDE architecture.
[0036] Figures 24A-24C are block diagrams of an example of the INDE architecture executed on a railway network.
[0037] Figure 25 are block diagrams of an exemplary train in the INDE architecture of Figures 24A-24C.
[0038] Figures 26A-26C are block diagrams of an example of an example of INDE architecture executed on an electric railway network.
[0039] Figures 27A-27C are block diagrams of an example of the INDE architecture executed in a truck transport network.
[0040] Figures 28A-28C are block diagrams of an example of the INDE architecture executed in an automobile network.
[0041] Figure 29 is an example of the operational flow diagram of the INDE architecture of Figure 20.
[0042] Figure 30 is a block diagram of an example of multiple INDE architectures being used with each other. DETAILED DESCRIPTION OF THE INVENTION
[0043] In summary, the preferred modalities described below refer to a method and a system for the management of an industry network. Applicants provide examples below related to various industry networks, such as utility networks and vehicle travel networks (such as air travel network, rail travel network, automobile travel network, travel network) buses, etc.) However, other industry networks can be used, including a telecommunications network and an energy exploration network (such as an oil well network, a natural gas well network, etc.).
[0044] As discussed in greater detail below, certain aspects refer to a utility company network, such as the electricity network itself (includes hardware and software in the transmission of electricity and / or electricity distribution) or the vehicle displacement network. In addition, certain aspects relate to the functional capabilities of the central management of the utility network, such as the central management of the electricity network and the central management of the vehicle displacement network. These functional capabilities can be grouped into two categories, operation and application. Operations services enable utilities to monitor and manage utility network services infrastructure (such as applications, network, servers, sensors, etc.)
[0045] In one of the examples discussed below, application capabilities may refer to the measurement and control of the utility company network itself (such as the electric power network or vehicle displacement network). Specifically, application services enable functionality that may be important to the utility network and may include: (1) data collection processes, (2) categorization and data permanence processes; and (3) observability processes. As discussed in more detail below, the use of these processes allows an individual to "observe" the utility company network, analyze the data and derive information about the utility company network.
[0046] Referring now to Figure 20, a block diagram illustrating an exemplary 2000 Intelligent Network Data Enterprise (INDE) architecture that can be applied to industrial systems from various industries is shown. In one example, the INDE architecture can include a 2002 network core. The 2002 network core can receive various types of information and / or data based on the particular industry of use. Data and information for a given industry can originate from an end point of the 2006 system, which can represent several points with an industry system. Each 2006 system endpoint can include a series of 2014 endpoint sensors that can detect various conditions associated with an industry system. For example, 2014 endpoint sensors can be dedicated to detecting power line flow in a utility network or airline arrival / departure issues. Each of the 2006 system endpoints can include one or more processors and memory devices that allow localized analytics to be performed. At the same time, exemplary 2016 endpoint analytics can determine various events based on data received from the 2006 endpoint sensors.
[0047] The INDE 2000 architecture can also include a 2008 system infrastructure that can support the 2006 system endpoints throughout the industry system. The 2008 system infrastructure can include 2022 infrastructure sensors distributed throughout the industry system to detect conditions associated with the industry system. In one example, the 2008 system infrastructure may include analytics infrastructure 2020 allowing the system infrastructure to analyze data received from the 2022 infrastructure sensors.
[0048] The network core 2002 can receive information from the 2006 system terminals and the 2008 system infrastructure. In one example, the INDE 2000 architecture can include a number of buses, such as an operational / non-operational bus 2010 and a bus of 2012 events. The 2010 operational / non-operational bus can be used to communicate both operational and non-operational data. In one example, operational data can refer to data associated with the various operations of a particular industry system running the INDE 2000 architecture. Non-operational data can refer to industry data associated with aspects related to the particular industry system in itself. The 2012 event bus can receive data related to various events that occur in the industry system. Events can refer to any occurrence of interest in the industry system. Thus, events can include unwanted or abnormal conditions that occur in the industry system.
[0049] The INDE 2000 architecture can perform distributed intelligence in which the various components of the architecture can be used to process data and determine an appropriate output. In one example, 2006 endpoint analytics may include one or more processors, memory devices and communication modules to allow processing to be performed based on data received by the 2006 endpoint sensors. For example, endpoint analytics 2016 can receive data from the 2014 endpoint sensors related to an event and can determine that the specific event is occurring based on the data. Endpoint analytics 2016 can generate an appropriate response based on the event.
[0050] Infrastructure analytics 2020 may also include one or more processors, memory devices and communication modules to allow processing to be performed based on data received by the 2022 infrastructure sensors. The 2008 system infrastructure can communicate with the 2006 system endpoints, allowing the 2008 system infrastructure to use 2020 infrastructure analytics to evaluate and process event data, as well as operational / non-operational data from the 2014 system endpoints and 2022 infrastructure sensors.
[0051] The data can also be evaluated by the network core 2002 provided by the busses 2010 and 2012. In one example, the network core 2002 can include system analytics 2024 which includes analytics from sensors 2026 and analytics from events 2028. The analytics 2026 and 2028 may include one or more processors and memory devices that allow event data and operational / non-operational data to be analyzed. In one example, sensor analytics 2024 can evaluate sensor data from endpoint sensors 2014 and infrastructure sensors 2022. In event analytics 2028, it can be used to process and evaluate event data.
[0052] The 2002 network core can also include a 2030 data set. The 2030 data set can include several 2032 data stores used to store raw and processed data, allowing historical data to be retrieved when needed, allowing future analytics based on historical data.
[0053] The 2002 network core may also include 2034 system controls. The 2034 system controls may be responsible for actions taken within the industry system. For example, 2002 system controls may include 2036 automatic controls that automatically control various aspects of the industry system based on event data and / or operational / non-operational data. The 2002 network kernel may also include 2038 user controls allowing human control over the industrial system, which may or may not be based on event and / or operational / non-operational data bus.
[0054] A business system 2004, may include several large-scale software packages for the industry. The 2004 business system can receive and transmit data to the 2002 network core for use in such aspects, such as information technology (IT) or other aspects related to the industry. In alternative examples, buses 2010 and 2012 can be integrated into a single bus or can include additional buses. Alternative examples may also include a 2008 system infrastructure including several subsystems.
[0055] Referring now to Figure 29, an operation diagram of the exemplary INDE 2000 architecture is shown. In one example, a system endpoint (SE1) 2006 can determine the occurrence of an E1 event. Another system endpoint (SE2) 2006 can determine the occurrence of an E2 event. Each 2006 system endpoint can report events E1 and E2 through event data for the 2008 system infrastructure. The 2008 system infrastructure can analyze event data and generate a D1 decision that can be transmitted to the end points of the system. system SE1 and SE2 allowing the end points of the system to execute the response.
[0056] In another example, an E3 event can be determined by the end point of the SE1 system. The event data reporting the E3 event can be transmitted to the network core 2002, allowing the network core 2002 to perform analytics on the 2024 system and generate a D2 decision through the 2034 system controls. The D2 decision can be provided to the end point of the SE1 system.
[0057] In another example, the SE1 system endpoint can determine the occurrence of an E4 event and notify the network core 2002 of the E4 event through event data. The network core 2002 can generate a D3 decision and provide it for the end point of the SE1 system for execution while providing information about the D3 decision for the 2004 business system.
[0058] In another example, the end point of the SE1 system can determine the occurrence of an E5 event. The end point of the SE1 system can perform the end point analytics 2016 to determine and subsequently execute a D4 decision. The D4 decision can be provided for the 2008 system infrastructure and the 2002 network core for notification and storage purposes. The examples related to Figure 29 are illustrative and other events, operational data and non-operational data can be communicated through the INDE 2002 system. Description of the High Level INDE Architecture General architecture
[0059] Regarding the drawings, in which the same reference numbers refer to the same elements, figures 1A-C illustrate an example of the global architecture for INDE. This architecture can serve as a reference model that provides for the collection, transportation, storage and end-to-end management of utility company network data (such as smart grid data); it can also provide analytics and analytics management, as well as the integration of abandoned ones into utility processes and systems. Thus, it can be seen as an enterprise-wide architecture. Certain elements, such as operational management and aspects of the utility company network itself, are discussed in more detail below.
[0060] The architecture represented in Figures 1A-C can include up to four data and integration buses: (1) a high-speed sensor data bus 146 (which, in the example of an energy utility company may include operational and non-operational data); (2) a dedicated event processing bus 147 (which may include event data); (3) an operations service bus 130 (which in the example of an energy utility company can serve to provide information about the smart grid for backup applications) and (4) a company service bus for rear IT systems (shown in Figures 1A-C as the company 114 integration environment bus to serve company 115 IT). Separate data buses can be achieved in one or more ways. For example, two or more of the data buses, such as the high-speed sensor data bus 146 and the dedicated event processing bus 147, can be different segments of a single data bus. Specifically, busbars can have a segmented structure or platform. As discussed in more detail below, hardware and / or software, such as one or more switches, can be used to route data across different segments of the data bus.
[0061] As another example, two or more of the data buses can be on separate buses, such as separate physical buses in terms of the hardware needed to carry data on the separate buses. Specifically, each of the buses can include cabling separate from each other. In addition, some or all of the separate buses can be of the same type. For example, one or more of the buses may comprise a local area network (LAN), such as Ethernet® over unshielded twisted pair cabling and Wi-Fi. As discussed in more detail below, hardware and / or software, such as a driver, can be used to direct data over data to a bus among the different physical buses.
[0062] As yet another example, two or more of the buses can be on different segments in a single bus structure and one or more buses can be on separate physical buses. Specifically, the high-speed sensor data bus 146 and the dedicated event processing bus 147 can be different segments on a single data bus, while the enterprise integration environment bus 114 can be on a physically separate bus .
[0063] Although figures 1A-C illustrate four buses, a smaller or greater number of buses can be used to carry the four types of data listed. For example, a single non-segmented bus can be used to communicate sensor data and event processing data (increasing the total number of buses to three), as discussed below. And, the system can operate without the operations service bus 130 and / or the enterprise integration environment bus 114.
[0064] The IT environment can be compatible with SOA. Service Oriented Architecture (SOA) is a style of computer system architecture for creating and using business processes, packaged as services, throughout their life cycle. SOA also defines and supplies the IT infrastructure to allow different applications to exchange data and participate in business processes. However, the use of SOA and the enterprise service bus is optional.
[0065] In the example of an electric power network, the figures illustrate different elements within the overall structure, such as the following: (1) SENT INDE 120, (2) SUBSTATION INDE 180 and (3) DEVICE INDE 188. This division of the elements within the global architecture is for illustration purposes. Another division of the elements can be used. And the division of elements can be different for different industries. The INDE architecture can be used to support both a distributed and centralized approach to network intelligence and to provide mechanisms for dealing with scale in large applications.
[0066] The INDE Reference Architecture is an example of the technical architecture that can be applied. For example, it can be an example of a meta-architecture, used to provide a starting point for the development of any number of specific technical architectures, one for each industry solution (for example, different solutions for different industries) or one for each application within an industry (for example, a first solution for a first utility grid and a second solution for a second utility grid), as discussed below. Thus, a specific solution for a particular industry or a particular application within an industry (such as an application for a private utility company) may include one, some, or all of the elements in the INDE Reference Architecture. And the INDE Reference Architecture can provide a standardized starting point for solution development. Discussed below is the methodology for determining the specific technical architecture for a given industry or a specific application within an industry (such as a particular power grid).
[0067] The INDE Reference Architecture can be a broad enterprise architecture. Its goal may be to provide the framework for end-to-end management of data and analytics, such as end-to-end management of network data and analytics and integration of these into utility systems and processes. . Since advanced network technology (such as smart grid technology) affects all aspects of utility business processes, one must be aware of the effects not just at the network level (such as the network), customer's operations and room levels, but also at rear and company levels. Therefore, the INDE Reference Architecture can and does reference enterprise-level SOA, for example, in the sense of assisting the SOA environment for interface purposes. This should not be taken as a requirement that an industry, such as a utility company, must convert its existing IT environment to SOA before the advanced network, such as an intelligent network, can be built and used. An enterprise service bus is a useful mechanism for facilitating IT integration, but it is not necessary in order to run the rest of the solution. The discussion that follows focuses on different components of the INDE smart grid elements for a utility solution; however, one, some or all of the INDE components can be applied to different industries, such as telecommunications, vehicle displacement and energy exploration. Independent component groups
[0068] As discussed above, the different components in the INDE reference architecture may include, for example: (1) INDE CORE 120; (2) SUBSTATION INDE 180; and (3) INDE188 DEVICE. The following sections address these three exemplary element groups of the INDE reference architecture and provide descriptions of the components of each group. CORE INDE
[0069] Figure 2 illustrates the INDE CORE 120, which is the part of the INDE Reference Architecture that can reside in an operations control center, as shown in Figures 1A-C. CORE INDE 120 can contain a unified data architecture for storing network data and an integration scheme for analytics to operate on that data. This data architecture can use the International Electrotechnical Commission (IEC) Common Information Model (CIM) as its high-level scheme. The IEC CIM is a standard developed by the electricity industry that has been officially adopted by the IEC, with the aim of allowing the application software to exchange information about the configuration and condition of an electrical network.
[0070] In addition, this data architecture can make use of federation 134 intermediate software to connect other types of utility data (such as, for example, meter data, operational and historical data, log files and events), and metadata and connectivity files in a single data architecture that can have a single entry point for access by high-level applications, including business applications. Real-time systems can also access key data stores via the high-speed data bus, and multiple data stores can receive data in real time. Different types of data can be transported within one or more buses on the smart grid. As discussed below in the SUBSTATION INDE 180 section, substation data can be collected and stored locally at the substation. Specifically, a database, which can be associated with and near the substation, can store the substation data. Analyzes related to the substation level can also be performed on the substation computers and stored in the substation database and all or part of the data can be transported to the control center.
[0071] The types of data carried may include operational and non-operational data, events, network connectivity data and network location data. Operational data may include, but is not limited to, switching condition, power condition, capacitor condition, section condition, meter condition, FCI condition, line sensor condition, voltage, current, real power, reactive power, etc. . Non-operational data may include, but is not limited to, power quality, power reliability, asset integrity, voltage data, etc. Operational and non-operational data can be transported via an operational / non-operational data bus 146. Data collection applications in the transmission of electricity and / or distribution of electricity from the electricity grid may be responsible for sending some or of all data for the operational / non-operational data bus 146. In this way, applications that need this information may be able to obtain the data by subscribing to the information or invoking services that can make that data available.
[0072] Events may include messages and / or alarms from various devices and sensors that are part of the smart grid, as discussed below. The events can be directly generated from the devices and sensors in the smart grid, as well as those generated by the various analytical applications based on the measurement data of these sensors and devices. Examples of events may include meter drop, meter alarm, transformer drop, etc. Network components, such as network devices (intelligent energy sensors (such as a sensor with an integrated processor that can be programmed for digital processing capability) temperature sensors, etc.), power system components that include integrated processing (RTUs, etc.), smart meter networks (meter integrity, meter readings, etc.) and mobile field strength devices (drop events, work order conclusions, etc.) can generate event data , operational and non-operational data. The event data generated in the smart grid can be transmitted via an event bus 147.
[0073] The network connectivity data can define the layout of the electrical network. There may be a base plan that defines the physical layout of the network components (substations, segments, feeders, transformers, switches, reclosers, meters, sensors, electric poles, etc.) and their interconnectivity in the installation. Based on events within the network (component failures, maintenance activity, etc.), network connectivity can change on an ongoing basis. As discussed in more detail below, the structure of how the data is stored, as well as the combination of the data, allows the historical reconstruction of the network layout in several past times. Network connectivity data can be extracted from the Geographic Information System (GIS) on a periodic basis as changes to the electrical network are made and this information is updated in the GIS application.
[0074] Network location data may include information about the network component in the communication network. This information can be used to send messages and information to the specific network component. Network location data can also be entered manually into the Smart Grid database as new Smart Grid components are installed or are extracted from an Asset Management System, if this information is maintained externally.
[0075] As discussed in more detail below, data can be sent from various components on the network (such as SUBSTATION INDE 180 and / or DEVICE INDE 188). Data can be sent to the CORE INDE 120 wirelessly, wired, or a combination of both. The data can be received by communications networks of a utility company 160, which can send the data to the targeting device 190. The targeting device 190 may include software and / or hardware for managing the direction of data for a segment a bus (when the bus includes a segmented bus structure) or over a separate bus. The steering device may include one or more switches or a driver. Directing device 190 may comprise a network device whose software and hardware direct and / or direct data to one or more of the buses. For example, guiding device 190 can route operational and non-operational data to the operational / non-operating data bus 146. The director can also direct event data to event bus 147.
[0076] Targeting device 190 can determine how to target data based on one or more methods. For example, the targeting device 190 can examine one or more headers in the transmitted data to determine whether it directs the data to the segment of the operational / non-operational data bus 146 or to the segment of the event bus 147. Specifically, one or more headers in the data can indicate whether the data is operational / non-operational (so that the driving device 190 directs the data to the operational / non-operating data bus 146) or whether the data is event data (so that the driving device 190 drives event bus 147). Alternatively, the targeting device 190 can examine the data payload to determine the data type (for example, the targeting device 190 can examine the data format to determine whether the data is operational / non-operational data or event data) .
[0077] One of the warehouses, such as the operational data warehouse 137 that stores the operational data, can be run as a true distributed database. Another of the warehouses, the historian (identified as historical data 136 in Figures 1 and 2), can be run as a distributed database. The other "ends" of these two databases can be located in the SUBSTATION INDE 180 group (discussed below). In addition, events can be stored directly in any of several data stores via the complex event processing bus. Specifically, events can be stored in event logs 135, which can be a repository for all events that have posted to event bus 147. The event log can store one, some, or all of the following: event id; kind of event; event source; event priority and event generation time. Event bus 147 does not need to store events for a long term, providing persistence for all events.
[0078] Data storage can be such that the data can be as close to the source as possible or viable. In one run, this may include, for example, that the substation data is stored in SUBSTATION SINCE 180. But that data may also be needed at the level of operations control center 116 to make different types of decisions that consider the network in a much more granular level. In conjunction with a distributed intelligence approach, a distributed data approach can be adopted to facilitate data availability at all levels of the solution through the use of database connections and data services, as applicable. In this way, the solution for storing historical data (which can be accessible at the level of operations control center 116) may be similar to that for operational data storage. The data can be stored locally in the database and substation connections configured in the repository instance in the control center, providing access to the data in individual substations. Substation analytics can be performed locally at the substation using the local data store. Historical / collective analytics can be performed at the level of the operations control center 116 by accessing data in the instances of the local substation, using data connections. Alternatively, the data can be stored centrally in the CENTER INDE 120. However, given the amount of data that may have to be transmitted from the INDE 188 DEVICES, storage of the data in the INDE 188 DEVICES may be preferred. Specifically, if there are thousands or tens of thousands of substations (which can occur in an electric power grid), the amount of data that has to be transmitted to CORE INDE 120 can create a bottleneck in communications.
[0079] Finally, the CORE INDE 120 can program or control one, some or all of the SUBSTATIONS INDE 180 or DEDEVICE INDE188 in the electric power network (discussed below). For example, the NUCLEUS INDE 120 can modify the programming (such as downloading an updated program) or provide a control command to control any aspect of the INDE 180 SUBSTATION or INDE 188 DEVICE (such as sensor control or analytics). Other elements, not shown in Figure 2, may include several integration elements to support this logical architecture.
[0080] Table 1 describes the certain elements of the NUCLEUS INDE 120 as illustrated in Figure 2.





Table 1: Elements of CORE INDE
[0081] As discussed in Table 1, the real-time data bus 146 (which communicates operational and non-operational data) and the complex real-time event processing bus 147 (which communicates event processing data) on a single 346 bus. An example of this is illustrated in block diagram 300 in Figures 3A-C.
[0082] As shown in Figures 1A-C, the buses are separated for performance purposes. For CEP processing, low latency can be important for certain applications that are subject to very large bursts of messages. Most network data flows, on the other hand, are more or less constant, with the exception of digital fault log files, but these can generally be recovered in a controlled manner, while event outbursts are asynchronous and random. .
[0083] Figure 1 further shows additional elements in the operations control center 116 separate from CORE INDE 120. Specifically, Figure 1 also shows main end (s) of data collection for meter 153 a system that is responsible by communicating with meters (such as collecting data from them and providing the data collected to and from a utility company). Demand Response Management System 154 is a system that communicates with equipment in one or more customer enclosures that can be controlled by the utility company. Fall Management System 155 is a system that assists a utility company in the management of falls, by tracking the location of falls, managing what is being shipped and how they are being corrected. Energy Management System 156 is a transmission system level control system that controls devices at substations (for example) in the transmission network. Distribution Management System 157 is a distribution system level control system that controls devices at substations and power devices (for example) in the distribution network. IP 158 Network Services is a collection of services operating on one or more servers that support IP type communications (such as DHCP and FTP). Mobile Data Shipping System 159 is a system that transmits / receives messages to mobile data terminals in the field. Load Flow and Circuit Analysis, Planning, Lightning Analysis and Network Simulation Tools 152 are a set of tools used by a utility company in the design, analysis and planning of networks. IVR (integrated voice response) and Call Management 151 are systems for handling customer calls (automatic or by attendants). Phone calls received about falls can be automatically or manually entered and directed to the Fall Management System 155. Work Management System 150 is a system that monitors and manages work orders. Geographic Information System 149 is a database that contains information about where the assets are geographically located and how the assets are connected together. If the environment has a Service Oriented Architecture (SOA), Operations Support SOA 148 is a collection of services to support the SOA environment.
[0084] One or more of the systems in Operations Control Center 116 that are outside the CORE INDE 120 are legacy product systems that a utility company may have. Examples of these legacy product systems include SOA Operations Support 148, Geographic Information System 149, Work Management System 150, Call Management 151, Circuit Analysis and Load Flow, Planning, Lightning Analysis and Simulation Tools network 152, meter data collection main end (s) 153, Demand Response Management System 154, Drop Management System 155, Power Management System 156, Distribution Management System 157, Services IP 158 network, and Mobile data dispatch system 159. However, these legacy product systems may not be able to process or handle data received from an intelligent network. The INDE 120 CORE may be able to receive data from the smart grid, process the data from the smart grid and transfer the processed data to one or more legacy product systems in a way that legacy product systems can use (such as a particular special format) for the legacy product system). In this way, the NÚCLEO INDE 120 can be seen as an intermediate software.
[0085] The operations control center 116, including CORE INDE 120, can communicate with the IT of the company 115. In general, the functionality in the IT of the company 115 comprises backup operations. Specifically, company IT 115 can use company integration environment bus 114 to send data to various systems within company IT 115, including Business Data Warehouse 104, Business intelligence applications 105, Enterprise Resource Planning 106, various Financial Systems 107, Customer Information System 108, Human Resources System 109, Asset Management System 110, Enterprise SOA Support 111, Network Management System 112, and Enterprise Message Services 113. IT Company 115 can also include a portal 103 to communicate with the Internet 101 through a security program 102. SUBSTATION INDE
[0086] Figure 4 illustrates an example of the high level architecture for the SUBSTATION INDE 180 group. This group can include elements that are currently hosted in substation 170 in a substation control housing on one or more servers co-located with electronics and substation systems.
[0087] Table 2 below lists and describes some elements of the SUBSTATION INDE 180 group. The data security services 171 can be a part of the substation environment; alternatively, they can be integrated into the SUBSTATION INDE 180 group.

Table 2 Elements of the INDE SUBSTATION
[0088] As discussed above, the different elements within the smart grid may include additional functionality, including additional processing / analytical capacity and database resources. The use of this additional functionality within various elements in the smart grid enables distributed architectures with centralized management and administration of applications and network performance. For reasons of performance, functionality and scalability, an intelligent network involving thousands to tens of thousands of SUBSTATIONS INDE 180 and tens of thousands to millions of network devices can include distributed processing, data management and process communications.
[0089] SUBSTATION INDE 180 may include one or more processors and one or more memory devices (such as substation 181 non-operational data and substation operations 182 data). The non-operational data from substation 181 and data from substation operations 182 can be associated with and close to the substation, such as located inside or in the SUBSTATION INDE 180. The SUBSTATION INDE 180 may also include components of the smart grid that are responsible for observability of the smart grid at a substation level. The components of the SUBSTATION INDE 180 can provide three main functions: acquisition and storage of operational data in the distributed operational data storage; acquisition of non-operational data and storage in the historian; and processing local analytics on a real-time basis (such as a sub-second). Processing can include digital signal processing of voltage and current waveforms, detection and classification processing, including event flow processing; and processing results communications to local systems and devices, as well as operations control center systems 116. Communication between SUBSTATION INDE 180 and other devices on the network can be wired, wireless, or a combination of with and wireless. For example, data transmission from SUBSTATION INDE 180 to operations control center 116 can be wired. SUBSTATION INDE 180 can transmit data, such as operational / non-operational data or event data to operations control center 116. Directing device 190 can direct data transmitted to one of the operational / non-operational data buses 146 or the event bus 147.
[0090] Demand response optimization for distribution loss management can also be done here. This architecture is in accordance with the distributed application architecture principle previously discussed.
[0091] For example, connectivity data can be duplicated at substation 170 and operations control center 116, thus allowing a substation 170 to operate independently, even if the data communication network for the control center operations 116 is not functional. With this information (connectivity) stored locally, substation analytics can be performed locally even if the communication connection to the operations control center is inoperative.
[0092] Likewise, operational data can be duplicated at operations control center 116 and at substations 170. Data from sensors and devices associated with a specific substation can be collected and the last measurement can be stored in this storage. data in the substation. The data structures of the operational data store can be the same and, therefore, database connections can be used to provide continuous access to the data residing in the substations and through the operational data storage instance in the control center. This provides a number of advantages including decreasing data replication and allowing substation data analytics, which are more time sensitive, to take place locally and without reliance on the availability of communication beyond the substation. Data analytics at the level of operations control center 116 may be less time sensitive (since operations control center 116 can normally examine historical data to discern patterns that are more predictive, rather than reactive) and can be able to work around network problems, if any.
[0093] Finally, historical data can be stored locally in the substation and a snapshot of the data can be stored in the control center. Or, database connections can be configured on the repository instance at operations control center 116, providing operations control center access to data at individual substations. Substation analytics can be performed locally at substation 170 using the local data store. Specifically, using the additional intelligence and storage capacity at the substation allows the substation to analyze itself and correct itself without data entry from a central authority. Alternatively, historical / collective analytics can also be performed at the level of operations control center 116, by accessing data at local substation instances, using database connections. INDE DEVICE
[0094] The INDE188 DEVICE group can comprise any variety of devices within the smart grid, including various sensors within the smart grid, such as several 189 distribution grid devices (eg line sensors on power lines), meters 163 on the customer's premises, etc. The INDE 188 DEVICE group can comprise a device added to the network with special functionality (such as an intelligent Remote Terminal Unit (RTU), which includes dedicated programming) or can comprise an existing device within the network with additional functionality (such as an RTU top pole of existing open architecture that is already placed on the network which can be programmed to create a smart line sensor or smart grid device). The DEDE 188 DEVICE can also include one or more processors and one or more memory devices.
[0095] Existing network devices may not be open from the point of view of the software and may not be able to assist much in the way of modern network connections or software services. Existing network devices may have been designed to acquire and store data for occasional downloading to some other device, such as a portable computer, or to transfer files in batches over the PSTN line to a remote host on demand. These devices cannot be designed for operation in a digital network environment in real time. In these cases, data from the network device can be obtained at the level of substation 170 or at the level of operations control center 116, depending on how the existing communications network was designed. In the case of meter networks, this will normally be the case where data is obtained from the meter data collection mechanism, since meter networks are normally closed and meters may not be addressed directly. As these networks evolve, gauges and other network devices can become individually accessible, so that data can be transported directly to where it is needed, which may not necessarily be the operations control center 116, but it can be any place on the network.
[0096] Devices such as defective circuit indicators can be paired with wireless network interface cards, for connection over wireless networks of more modest speed (such as 100 kbps). These devices can report condition for the exception and perform fixed pre-programmed functions. The intelligence of many network devices can be increased using local smart RTUs. Instead of having pole top RTUs that are designed as closed architecture and fixed function devices, RTUs can be used as open architecture devices, that can be programmed by third parties and that can serve as an INDE 188 DEVICE in the Architecture of Reference INDE. In addition, meters in customer premises can be used as sensors. For example, meters can measure consumption (such as the amount of energy consumed for billing purposes) and can measure voltage (for use in volt / VAr optimization).
[0097] Figures 5A-B illustrate an example architecture for the DEDE 188 DEVICE group. Table 3 describes the certain elements of the DEDE 188 DEVICE. The smart grid device may include an embedded processor, so that the processing elements are less as SOA services and more as real-time program library routines, since the DEVICE group runs on a dedicated real-time DSP or microprocessor.

Table 3 Elements of the INDE DEVICE
[0098] Figure 1A also shows customer rooms 179 that can include one or more smart meters 163, a home monitor 165, one or more sensors 166 and one or more controls 167. In practice, sensors 166 can record data in a or more devices in the customer's premises 179. For example, a sensor 166 can record data on several main instruments within the customer's premises 179, such as the oven, hot water heater, air conditioning, etc. Data from one or more sensors 166 can be sent to smart meter 163 which can pack the data for transmission to operations control center 116 via the utility company's communications network 160. The home display 165 can provide the customer, on the customer's premises, with an output device to view, in real time, the data collected from the smart meter 163 and one or more sensors 166. In addition, an input device (such as a keypad) can be associated with home display 165 so that the customer can communicate with operations control center 116. In one embodiment, home display 165 can comprise a computer resident on the customer's premises.
[0099] The rooms of the client 165 may also include controls 167 that can control one or more devices in the premises of the client 179. Various devices, in the premises of the client 179 can be controlled, such as heater, air conditioning, etc., depending on commands from the operations control center 116.
[00100] As shown in Figure 1A, customer 169 premises can communicate in a variety of ways, such as over the Internet 168, the public switched telephone network (PSTN) 169, or over a dedicated line (such as through collector 164). Through any of the mentioned communication channels, data can be sent from one or more customer premises 179. As shown in Figure 1, one or more customer premises 179 can include an Intelligent Measurement Network 178 (which comprises a plurality of smart meters 163), sending data to a collector 164 for transmission to the operations control center 116 through the utility network management network 160. In addition, several sources of energy generation / storage distributed 162 (such as solar panels, etc.) can send data to a monitor control 161 for communication with operations control center 116 through the utility network management network 160.
[00101] As discussed above, the devices in the external electrical power network of operations control center 116 may include treatment and / or storage capacity. The devices may include the INDE 180 SUBSTATION and INDE188 DEVICE. In addition to the individual devices on the power grid including additional intelligence, the individual devices can communicate with other devices on the power grid in order to exchange information (including sensor data and / or analytical data (such as event data) ), in the sense of analyzing the condition of the electricity grid (such as determining failures) and, in the sense of changing the condition of the electricity grid (such as, correcting the failures). Specifically, individual devices may use the following: (1) intelligence (such as processing power), (2) storage (such as distributed storage discussed above), and (3) communication (such as the use of one or more more buses discussed above). In this way, the individual devices in the power grid can communicate and cooperate with each other without supervision by the operations control center 116.
[00102] For example, the INDE architecture disclosed above may include a device that detects at least one parameter on the supply circuit. The device can also include a processor that monitors the parameter detected in the supply circuit and that analyzes the detected parameter to determine the condition of the supply circuit. For example, the analysis of the detected parameter can comprise a comparison between the detected parameter with a predetermined threshold and / or can comprise a trend analysis. Such a detected parameter may include detecting the waveforms and one such analysis may comprise determining whether the detected waveforms indicate a failure in the supply circuit. The device can also communicate with one or more substations. For example, a particular substation can supply power to a particular supply circuit. The device can detect the condition of the particular supply circuit, and determine whether there is a fault in the particular supply circuit. The device can communicate with the substation. The substation can analyze the fault determined by the device and can take corrective measures, depending on the fault (such as reducing the power supplied to the supply circuit). In the example of the device sending data indicating a failure (based on waveform analysis), the substation can change the power supplied to the power circuit without input from operations control center 116. Or, the substation can combine the data indicating the failure with information from other sensors to further refine the failure analysis. The substation can also communicate with the operations control center 116, such as the drop of intelligence application (as discussed in Figures 13A-B) and / or the failure of intelligence application (as discussed in Figures 14A-C). Thus, operations control center 116 can determine the failure and can determine the extent of the fall (such as, the number of houses affected by the failure). In this way, the supply circuit condition detection device can work cooperatively with the substation, in order to correct a potential failure, with or without requiring the need for the operations control center 116 to intervene.
[00103] In another example, a line sensor, which includes additional intelligence using processing and / or memory capacity, can produce network condition data in a part of the network (such as a supply circuit). Network condition data can be shared with demand response management system 155 at operations control center 116. Demand response management system 155 can control one or more devices at customer locations on the supply circuit in response to network condition data from the line sensor. In particular, the demand response management system 155 can control the energy management system 156 and / or the distribution management system 157 to reduce the load on the supply circuit by turning off the devices at the receiving customer sites. energy from the supply circuit, in response to the line sensor that indicates a power loss in the supply circuit. In this way, the line sensor, in combination with the demand response management system 155, can automatically shift load from a faulty supply circuit and then isolate the fault.
[00104] In yet another example, one or more relays in the electrical power network may have a microprocessor associated with it (s). These relays can communicate with other devices and / or databases residing in the electric power network, in order to determine a fault and / or control the electric power network. INDS Concept and Architecture Model of Outsourced Smart Grid / Analytical Data Services
[00105] An application for smart grid architecture allows the utility company to subscribe to network and analytical data management services, while maintaining traditional control systems and related operating systems at home. In this model, the utility company can install and own network sensors and devices (as described above), and can either own and operate the network data transport communication system, or can outsource it. Network data can flow from the utility company to a remote location for Intelligent Network Data Services (INDS), where data can be managed, stored and analyzed. The utility company can then subscribe to data and analytics services under an appropriate service financial model. The utility company can avoid initial capital investment expenses and ongoing costs of managing, supporting and upgrading the smart / analytical data infrastructure in exchange for fees. The INDE reference architecture itself, described above, leads to the outsourcing arrangement described here. INDS Architecture for Intelligent Network Services
[00106] In order to execute the INDS services model, the INDE Reference Architecture can be partitioned into a group of elements that can be hosted remotely, and those that can remain in the utility company. Figures 6A-C illustrate how the architecture of the utility company services company might look once the CORE INDE 120 was made remote. A server can be included as part of the CORE INDE 120 which can act as an interface for remote systems. For utility systems, this can appear as a virtual CORE 602.
[00107] As shown in the general block diagram 600 in Figures 6A-C, the SUBSTATION INDE 180 and DEDE 188 devices are unchanged from that shown in Figures 1A-C. The multiple bus structure can also be used in the utility company.
[00108] INDE CORE 120 can be hosted remotely, as illustrated by block diagram 700 in Figure 7. At the hosting location, INDE CORE 120 can be installed as needed to support INDS-subscribing utility companies (shown as North American Lodging Center for INDS 702). Each CORE 120 can be a modular system, so adding a new subscriber is a routine operation. A separate part of the utility company can manage and support software for one, some or all of the INDE 120 CORE, as well as the applications that are downloaded from the INDS hosting location for each INDE 180 SUBSTATION and DEDE DEVICES 188 of the utility company.
[00109] In order to facilitate communications, low latency and high bandwidth communication services, such as over the 704 network (for example, an MPLS or another WAN), it can be used that can reach operations centers of the utility company company subscribers, as well as the INDS hosting sites. As shown in Figure 7, several areas can be supplied, such as California, Florida and Ohio. This modularity of operations does not only allow efficient management of several different networks. It also allows for better inter-network management. There are cases where a failure in one network can affect operations on a neighboring network. For example, a failure in the Ohio network can have a ripple effect on operations on a neighboring network, such as the average Atlantic network. Using the modular structure as illustrated in Figure 7 allows the management of individual networks and management of inter-network operations. Specifically, a global INDS system (which includes a processor and memory) can manage the interaction between the various INDE 120 cores. This can reduce the possibility of a catastrophic failure that spreads from one network to another. For example, a failure in the Ohio network can spread to a neighboring network, such as the average Atlantic network. The INDE 120 CORE dedicated to the management of the Ohio network can attempt to correct the failure in the Ohio network. And the global INDS system can try to reduce the possibility of a cascade failure occurring on neighboring networks. Specific examples of functionality in CORE INDE
[00110] As shown in Figures 1, 6 and 7, several functionalities (represented by blocks) are included in the CORE INDE 120, two of which are represented are the meter data management services (MDMS) 121 and measurement analytics and services 122. Because of the modularity of the architecture, several features, such as MDMS 121 and measurement analytics and services 122, can be incorporated. Observability processes
[00111] As discussed above, an application services functionality can include observability processes. Observability processes can allow the utility company to "observe" the network. These processes can be responsible for interpreting the raw data received from all sensors and devices on the network and transforming them into actionable information. Figure 8 includes a list of some examples of the observability processes.
[00112] Figures 9A-B illustrate a 900 flow diagram of the Network Condition Measurement & Operation Processes. As shown, the Data Digitizer can request data from the meter, as shown in block 902. The request can be sent to one or more network devices, substation computers and line sensor RTUs. In response to the request, devices can collect operation data, as shown in blocks 904, 908, 912 and can send data (such as one, some or all of the operational data, such as voltage, current, actual power and power data reactive), as shown in blocks 906, 910, 914. The data digitizer can collect operational data, as shown in block 926, and can send data to the operational data store, as shown in block 928. The data store operational data can store operational data, as shown in block 938. operational data storage can further send a snapshot of the data to the historian, as shown in block 940, and the historian can store the snapshot of the data, as shown in block 942.
[00113] The meter condition application can send a meter data request to the DCE Meter, as shown in block 924, which in turn sends a request to one or more meters to collect meter data, as shown in block 920. In response to this request, one or more meters collect meter data, as shown in block 916, and send the voltage data to the DCE Meter, as shown in block 918. The DCE Meter can collect data from voltage, as shown in block 922, and send the data to the data requester, as shown in block 928. The meter condition application can receive the meter data, as shown in block 930, and determine whether they are for a process single value or voltage profile network condition, as shown in block 932. If they go to the single value process, the meter data is sent to the requesting process, as shown in block 936. If the meter data are for storage to determine the condition of the network at a future time, the meter data is stored in the operational data store, as shown in block 938. The operational data store further sends a snapshot of the data to the historian, as shown in block 940, and the historian stores the snapshot of the data, as shown in block 942.
[00114] Figures 9A-B further illustrate actions related to response to demand (DR). Demand response refers to dynamic demand mechanisms for managing customer electricity consumption in response to supply conditions, for example, having electricity customers reduce their consumption in critical periods or in response to market prices. This may involve actually reducing the power used or starting local generation, which may or may not be connected in parallel with the grid. This can be different from energy efficiency, which means using less energy to perform the same tasks, on an ongoing basis or whenever the task is performed. In response to demand, customers, using one or more control systems, can issue charges in response to a request by a utility company or market price conditions. Services (lights, machines, air conditioning) can be reduced according to a pre-planned load prioritization scheme during critical periods. An alternative to load emission is the local generation of electricity to complement the electricity grid. Under conditions of scarce electricity supply, the response to demand can significantly reduce the peak price and, in general, the volatility of electricity prices.
[00115] The demand response can generally be used to refer to mechanisms used to encourage consumers to reduce demand, thereby reducing peak demand for electricity. Since electrical systems are generally sized to match peak demand (more margin for error and unforeseen events), decreasing peak demand can reduce overall plant and capital cost requirements. Depending on the configuration of the generation capacity, however, the demand response can also be used to increase demand (load) during periods of high production and low demand. Some systems can thus encourage energy storage for arbitrage between periods of low and high demand (or low and high prices). As the proportion of intermittent energy sources, such as wind energy, in a system grows, the response to demand may become increasingly important for effective management of the electricity grid.
[00116] The DR condition application can request the available DR capacity, as shown in block 954. The DR management system can then request the available capacity from one or more domestic DR devices, as shown in block 948. The one or more home devices can collect available DR capacity in response to the request, as shown in block 944, and send the DR capacity and response data to the DR management system, as shown in block 946. The DR management can collect DR capacity and response data, as shown in block 950, and send DR capacity and response data to the DR condition application, as shown in block 952. The DR condition application can receive the DR capacity and response data, as shown in block 956, and send the capacity and response data to the operational data store, as shown in block 958. The operational data store can store DR capacity and response data, as shown in block 938. The operational data store can still send a snapshot of the data to the historian, as shown in block 940, and the historian can store the snapshot of the data, as shown in block 942.
[00117] The substation computer can request application data from the substation application, as shown in block 974. In response, the substation application can request application of the substation device, as shown in block 964. The substation device can collect the application data as shown in block 960 and send the application data to the substation device (which can include one, some or all of the voltage, current, real power and reactive power data) as shown in the block 962. The substation application can collect the application data, as shown in block 966 and send the application data to the requester (which can be the substation computer), as shown in block 968. The substation computer can receive the application data as shown in block 970 and send the application data to the operational data store as shown in block 972.
[00118] The measurement of the network condition and operational data process can comprise the derivation of the network condition and network topology at a given point in time, as well as providing this information to other systems and data stores. Sub-processes can include: (1) measuring and capturing network condition information (this is related to the operational data pertaining to the network that was discussed earlier); (2) sending network condition information to other analytical applications (this allows for other applications, such as analytical applications, access to network condition data); (3) instant persistence of the network condition for storage of connectivity / operational data (this allows updating the information of the network condition for storage of connectivity / operational data in the appropriate format, as well as directing this information to the historian for persistence of so that a network topology at one point in time can be derived at a later point in time); (4) derive topology network at a point in time based on standard connectivity and current network condition (this provides the network topology at a given point in time, applying the snapshot of the network condition at a point in time in the historian for basic connectivity in the storage of connectivity data, as discussed in more detail below); and (5) provide information on the network topology for the applications, upon request.
[00119] Regarding the sub-processes (4), the network topology can be derived for a predetermined time, such as in real time, 30 seconds ago, 1 month ago, etc. In order to recreate the network topology, multiple databases can be used and a program to access the data in the multiple databases to recreate the network topology. A database can include a relational database that stores basic connectivity data (the "connectivity database"). The connectivity database can contain the network topology information as constructed to determine the baseline connectivity model. Asset and topology information may be updated in this database on a periodic basis, according to updates to the power grid, such as adding or modifying circuits in the power grid (for example, additional power circuits that added to the power grid). The connectivity database can be considered "static" as it does not change. The connectivity database can change if there are changes in the structure of the electricity grid. For example, if there is a change in the supply circuits, such as the addition of a supply circuit, the connectivity database may change.
[00120] An example of the 1800 structure of the connectivity database can be derived from the hierarchical model represented in Figures 18A-D. Structure 1800 is divided into four sections, with figure 18A being the upper left section, figure 18B being the upper right section, figure 18C being the lower left section and figure 18D being the lower right section. Specifically, Figures 18A-D are an example of an entity relationship diagram, which is an abstract method for representing the baseline connectivity database. The hierarchical model in Figures 18A-D can contain the metadata that describes the electricity network and can describe the various components of a network and the relationship between the components.
[00121] A second database can be used to store "dynamic" data. The second database can include a non-relational database. An example of a non-relational database can comprise a historian database, which stores time series of non-operational data, as well as historical operational data. The historian database can store a series of "flat" records, such as: (1) time stamp, (2) device ID, (3) a data value and (4) a device's condition. In addition, the stored data can be compressed. Because of this, operational / non-operational data on the electricity grid can be easily stored and can be managed even though a considerable amount of data may be available. For example, data on the order of 5 Terabytes can be in line for use at any given time to recreate the network topology. Because the data is stored in the simple flat record (such as no organizational approach), this allows for efficient data storage. As discussed in more detail below, the data can be accessed by a specific tag, such as the time stamp.
[00122] Various analytics for the network may want to receive, as data entry, the network topology at a given point in time. For example, analytics related to power quality, reliability, asset integrity, etc., can use the network topology as input. In order to determine the network topology, the baseline connectivity model, as defined by the data in the connectivity database, can be accessed. For example, if the topology of a particular power circuit is desired, the baseline connectivity model can define the various switches in the particular power circuit in the power grid. After that, the historian database can be accessed (based on the particular time), in order to determine the values of the switches in the particular supply circuit. Then, a program can combine the data from the baseline connectivity model and the historian database in order to generate a representation of the particular power circuit, at the particular moment.
[00123] A more complicated example to determine the network topology may include several supply circuits (for example, supply circuit A and supply circuit B) that have an interconnect switch and disconnect switches. Depending on the switching conditions of certain switches (such as the interconnect switch and / or disconnect switches), sections of the supply circuits may belong to a supply circuit A or supply circuit B. The program that determines the network topology can access data from both the baseline connectivity model and the historian database in order to determine connectivity at a given time (for example, which circuits belong to supply circuit A or supply circuit B).
[00124] Figure 10 illustrates a flow diagram 1000 of non-operational data processes. The application of non-operational statement can request non-operational data, as shown in block 1002. In response, the digitizer can gather non-operational data, as shown in block 1004, through which various devices in the electrical network, such as network, substation computers and line sensor RTUs can collect non-operational data, as shown in blocks 1006, 1008, 1110. As discussed above, non-operational data can include temperature, power quality, etc. The various devices on the power grid, such as network devices, substation computers and line sensor RTUs can send non-operational data to the data digitizer, as shown in blocks 1012, 1014, 1116. The digitizer can collect non-operational data, as shown in block 1018, and send non-operational data to the non-operational statement application, as shown in block 1020. The non-operational statement application can collect data non-operational data as shown in block 1022 and send the collected non-operational data to the historian, as shown in block 1024. The historian can receive non-operational data, as shown in block 1026, store the non-operational data, as shown in block 1028 and send the non-operational data to one or more analytical applications, as shown in block 1030.
[00125] Figure 11 illustrates a 1100 flow diagram of the event management processes. Data can be generated from various devices based on different events in the power grid and sent via event bus 147. For example, the meter's data collection mechanism can send power outage / restore notification information for the event bus, as shown in block 1102. Line sensor RTUs generate a fault message and can send the fault message to the event bus, as shown in block 1104. Substation analytics can generate a message fault and / or drop and can send the fault and / or drop message to the event bus, as shown in block 1106. The historian can send signal behavior to the event bus, as shown in block 1108. And, several processes can send data over event bus 147. For example, the failure intelligence process, discussed in more detail in Figures 14A-C, can send a failure analysis event through through the event bus, as shown in block 1110. The drop intelligence process, discussed in more detail in Figures 13A-B, can send a drop event across the event bus, as shown in block 1112. The drop bus events can collect the various events, as shown in block 1114. And, complex event processing services (CEP) can process events sent through the event bus, as shown in block 1120. CEP services can process queries against multiple simultaneous, high-speed, real-time event message flows. After processing by CEP services, event data can be sent via the event bus, as shown in block 1118. And the historian can receive through the event bus one or more event logs for storage, as shown in block 1116 In addition, event data can be received by one or more applications, such as the fall management system (WHO), fall intelligence, failure analysis, etc., as shown in block 1122. In this way, the event bus can send the event data to an application, thus avoiding the "silo" problem of not making the data available to other devices or other applications.
[00126] Figures 12A-C illustrate a 1200 flow diagram of the Demand Response Signaling (DR) processes. DR can be requested by the distribution operation application, as shown in block 1244. In response, the network / connectivity condition can collect DR availability data, as shown in block 1202 and can send the data, as shown in block 1204 The distribution operation application can distribute the DR availability optimization, as shown in block 1246, through the event bus (block 1254) to one or more DR Management Systems. The DR management system can send DR information and signals to one or more customer enclosures, as indicated in block 1272. The one or more customer enclosures can receive DR signals, as shown in block 1266 and send the response DR, as shown in block 1268. DR management can receive the DR response, as shown in block 1274, and send DR responses to one, some, or all, operations data bus 146, the billing and marketing database, as shown in block 1276. The billing database and marketing database can receive responses, as shown in blocks 1284, 1288. Operations data bus 146 can also receive responses as shown in block 1226 and send DR responses and available capacity for DR data collection as shown in block 1228. DR data collection can process DR responses and available capacity as shown in block 1291 and send data to ob operation data provisioning, as shown in block 1294. The operations data bus can receive DR availability and response, as shown in block 1230, and send them to the network / connectivity condition. The network / connectivity condition can receive the data, as shown in block 1208. The received data can be used to determine the network condition data, which can be sent (block 1206) via the operations data bus (block 1220 ). The distribution operation application can receive the network condition data (as an event message for DR optimization), as shown in block 1248. Using the network condition data and the DR availability and response, the operation application distribution can perform distribution optimization to generate distribution data, as shown in block 1250. Distribution data can be obtained by the operations data bus, as shown in block 1222 and can be sent to the extracting application , as shown in block 1240. The operational data bus can send data (block 1224) to the distribution operation application, which in turn can send one or more DR signals to one or more DR Management Systems (block 1252). The event bus can collect signals for each of the one or more DR Management Systems (block 1260) and send the DR signals to each of the DR management systems (block 1262). The DR management system can then process the DR signals, as discussed above.
[00127] The communication operation historian can send data to the event bus, as indicated in block 1214. The communication operation historian can also send generation portfolio data, as shown in block 1212. or, a device asset management system, such as a Ventyx®, can request virtual power plant (VPP) information, as shown in block 1232. The operations data bus can collect VPP data, as shown in block 1216 and send the data to the asset management device, as shown in block 1218. The asset management device can collect VPP data, as shown in block 1234, perform system optimization, as shown in block 1236, and send the VPP signals to the event bus, as shown in block 1238. The event bus can receive the VPP signals, as shown in block 1256, and send the VPP signals to the distribution operation application, as shown in block 1258. A The distribution operation application can then receive and process the event messages, as discussed above.
[00128] The connection extract application can extract data from new customers, as shown in block 1278, to be sent to the marketing database, as shown in block 1290. Data from new customers can be sent to network condition / connectivity, as shown in block 1280, so that network condition connectivity can receive new DR connectivity data, as shown in block 1210.
[00129] The operator can send one or more cancellation signals when applicable, as shown in block 1242. Cancellation signals can be sent to the distribution operation application. The cancellation signal can be sent to the energy management system, as shown in block 1264, the billing database, as shown in block 1282 and / or the marketing database, as shown in block 1286.
[00130] Figures 13A-B illustrate a 1300 flow diagram of the Fall Intelligence processes. Various devices and applications can send power outage notification, as shown in blocks 1302, 1306, 1310, 1314, 1318. Outage events can be collected by the event bus, as shown in block 1324, which can send out event events drop for complex event processing (CEP), as shown in block 1326. In addition, various devices and applications can send power restore condition, as shown in blocks 1304, 1308, 1312, 1316, 1320. CEP can receive messages from the fall and restore condition (block 1330), process events (block 1332) and send event data (block 1334). The drop intelligence application can receive event data (block 1335) and request condition and network connectivity data (block 1338). The operational data bus can receive the network condition and connectivity data request (block 1344) and forward it to one, or both, of the operational data store and the historian. In response, the operational data store and the historian can send condition data and network connectivity (blocks 1352, 1354) through the operational data bus (block 1346) to the drop intelligence application (block 1340). It determines whether the condition data and network connectivity indicate whether it was transient, as shown in block 1342. If so, snapshots are sent over the operational data bus (block 1348) to the snapshot database for storage (block 1350). If not, a crash case is created (block 1328) and the crash case data is stored and processed by the crash management system (block 1322).
[00131] Fall intelligence processes can: detect falls; classify and record snapshots; determine the extent of the fall; determine the root cause (s) of the fall; track fall restoration; raising crash events and updating system performance indexes.
[00132] Figures 14A-C illustrate a flow diagram 1400 of failure intelligence processes. Complex event processing can request data from one or more devices, as shown in block 1416. For example, network condition and connectivity in response to the request can send network condition and connectivity data for processing complex events, such as shown in block 1404. Likewise, the historian in response to the request can send condition of the switch in real time for the processing of complex events, as shown in block 1410. And, the processing of complex events can receive network condition, data connectivity and switch condition, as shown in block 1418. Substation analytics can request fault data, as shown in block 1428. Fault data can be sent by a variety of devices, such as line sensor RTUs and computers substations, as shown in blocks 1422, 1424. The various fault data, network condition, connectivity data and switch condition can be sent to substation analytics for event detection and characterization, as shown in block 1430. The event bus can also receive event messages (block 1434) and send event messages to the substation analytics (block 1436). Substation analytics can determine the type of event, as shown in block 1432. For protection and modification control events, the substation computers can receive a fault event message, as shown in block 1426. For all other types events, the event can be received by the event bus (block 1438) and sent to the processing of complex events (block 1440). Complex event processing can receive event data (block 1420) for further processing. Likewise, network condition and connectivity can send network condition data for processing complex events, as shown in block 1406. And, the Common Information Model (CIM) warehouse can send metadata for event processing complexes, as shown in block 1414.
[00133] Complex event processing can send a fault event message, as shown in block 1420. The event bus can receive the message (block 1442) and send the event message to the fault intelligence application (block 1444). The fault intelligence application can receive event data (block 1432) and request network condition, connectivity data and switch condition, as shown in block 1456. In response to the request, the network condition and connectivity send data from network condition and connectivity (block 1408) and the historian sends condition data from the switch (block 1412). The fault intelligence receives the data (block 1458), analyzes the data and sends the event data (block 1460). The event data can be received by the event bus (block 1446) and sent to the fault log file (block 1448). The fault log file can record the event data (block 1402). Event data can also be received by the operational data bus (block 1462) and sent to one or more applications (block 1464). For example, the drop intelligence application can receive event data (block 1466), discussed above in relation to Figures 13A-B. The work management system can also receive event data in the form of a work order, as shown in block 1468. And other requesting applications can receive event data, as shown in block 1470.
[00134] Intelligent failure processes can be responsible for interpreting network data to derive information about current and potential failures within the network. Specifically, failures can be detected using intelligent failure processes. A failure is usually a short circuit caused when the utility's equipment fails or an alternate path for the current flow is created, for example, a fallen power line. These processes can be used to detect typical faults (normally controlled by conventional protection and fault detection equipment - relays, fuses, etc.), as well as high impedance faults within the network, which are not easily detectable using currents failure.
[00135] The failure intelligence process can also classify and categorize failures. This allows faults to be classified and categorized. Currently, there is no standard for the organization and systematic classification of absences. A de facto standard can be established for them and carried out. The failure intelligence process can also characterize failures.
[00136] Fault intelligence can also determine the location of the fault. Fault location in the distribution system can be a difficult task due to its high complexity and difficulty caused by the unique characteristics of the distribution system, such as unbalanced loading, three, two and one phase sides, absence of different sensors / measures types of failures, different causes of short circuits, variable load conditions, long feeders with multiple sides and network configurations that are not documented. This process allows the use of a number of techniques to isolate the fault location with the maximum precision that the technology allows.
[00137] Failure intelligence can also increase failure events. Specifically, this process can create and publish fault events to the event bus once a fault has been detected, classified, categorized, characterized and isolated. This process can also be responsible for collecting, filtering, examining and deduplicating failures so that an individual failure event is increased rather than a flood based on the raw events that are typical during a failure. Finally, fault intelligence can record failure events in the event log database.
[00138] Figures 15A-B illustrate a 1500 flow diagram of the metadata management processes. Metadata management processes can include: point list management; and protocol communication & management connectivity and element naming and translation; management of the sensor calibration factor, and data management of the topology network in real time. The base connectivity extraction application can request base connectivity data, as shown in block 1502. Geographic Information Systems (GIS) can receive the request (block 1510) and send data to the base connectivity extract application (block 1512). The application to extract base connectivity can receive data (block 1504), extract, transform and load data (block 1506) and send base connectivity data to the data connectivity mart (block 1508). The connectivity data mart can later receive the data, as shown in block 1514.
[00139] The connectivity data mart can comprise a custom data store that contains the electrical connection information of the network components. As shown in Figures 15A-B, this information can normally be derived from the Geographic Information System (GIS) of the utility company, which contains the geographic location of the components that make up the network as constructed. The data in this data store describe the hierarchical information about all components of the network (substation, feeder, section, segment, branch, section t, circuit breaker, recloser, switch, etc. - basically all assets). This data store can have the asset and connectivity information as constructed.
[00140] The application of extract of metadata can request metadata for network assets, as shown in block 1516. The database of metadata can receive the request (block 1524) and send metadata (block 1526). The metadata extract application can receive the metadata (block 1518), extract, transform and load data (meta block 1520) and send the metadata to the CIM data warehouse (block 1522).
[00141] The CIM (Common Information Model) data warehouse can then store the data, as shown in block 1528. The CIM can prescribe standard utility formats to represent utility data. . The INDE smart grid can facilitate the availability of smart grid information in a standard utility format. And, the CIM data warehouse can facilitate the conversion of specific INDE data to one or more formats such as a prescribed utility format.
[00142] The asset extract application can request information about new assets, as shown in block 1530. The asset registry can receive the request (block 1538) and send information about new assets (block 1540). The asset extract application can receive information about new assets (block 1532), extract, transform and load data (block 1534) and send information about new assets to the CIM data warehouse (block 1536).
[00143] The DR connectivity extraction application can request DR connectivity data, as shown in block 1542. The operational data bus can send the DR connectivity data request to the marketing database, as shown in block 1548. The marketing database can receive the request (block 1554), extract, transform, load DR connectivity data (block 1556) and send DR connectivity data (block 1558). The operational data bus can send DR connectivity data to the application to extract DR connectivity (block 1550). The application to extract DR connectivity can receive DR connectivity data (block 1544) and send DR connectivity data (block 1546) via the operational data bus (block 1552) to the network condition and DM connectivity, which stores DR connectivity data (block 1560).
[00144] Figure 16 illustrates a 1600 flow diagram of the Notification Agent processes. A notification subscriber can enter a web page, as shown in block 1602. The notification subscriber can create / change / delete parameters from the scenario watch list, as shown in block 1604. The web page can store the list of scenario observation created / modified / deleted, as shown in block 1608, and the CIM data store can create a list of data labels, as shown in block 1612. A name translation service can translate the data labels into the historian (block 1614) and send the data tags (block 1616). The web page can send the list of data tags (block 1610) through the operational data bus, which receives the list of data tags (block 1622) and sends it to the notification agent (block 1624). The notification agent retrieves the list (block 1626), validates and merges the lists (block 1628) and checks the historian for notification scenarios (block 1630). If exceptions corresponding to the scenarios are found (block 1632), a notification is sent (block 1634). The event bus receives the notification (block 1618) and sends it to the notification subscriber (block 1620). The notification subscriber can receive the notification via a preferred means, such as text, email, phone call, etc., as shown in block 1606.
[00145] Figure 17 illustrates a 1700 flow diagram of the meter data collection (AMI) processes. The current collector can request data from residential meters, as shown in block 1706. One or more residential meters can collect data from residential meters in response to the request (block 1702) and send data from residential meters (block 1704). The current collector can receive data from residential meters (block 1708) and send it to the operational data bus (block 1710). The meter data collection mechanism can request data from commercial and industrial meters, as shown in block 1722. One or more commercial and industrial meters can collect data from commercial and industrial meters in response to the request (block 1728) and send the data from commercial and industrial meters (block 1730). The meter data collection mechanism can receive data from commercial and industrial meters (block 1724) and send it to the operational data bus (block 1726).
[00146] The operational data bus can receive data from residential, commercial and industrial meters (block 1712) and send the data (block 1714). The data can be received by the measurement data repository database (block 1716) or can be received by the billing processor (block 1718), which in turn can be sent to one or more systems, such as a CRM system ( Customer Relationship Management) (block 1720).
[00147] Observability processes may also include remote asset monitoring processes. Monitoring assets within an electrical network can be difficult. There may be different parts of the electricity grid, some of which are very expensive. For example, substations can include power transformers (which cost more than $ 1 million) and circuit breakers. Often, utility companies would do little, if anything, to analyze the assets and maximize the use of the assets. Instead, the utility company's focus was usually on ensuring that energy for the consumer was maintained. Specifically, the utility company was focused on scheduled inspections (which would normally take place at predetermined intervals) or "event-driven" maintenance (which would occur if a failure occurred in part of the network).
[00148] Instead of typical regular inspections or "event-driven" maintenance, remote asset monitoring processes can focus on condition-based maintenance. Specifically, if a part (or all) of the electricity grid can be accessed (such as on a periodic or continuous basis), the integrity of the electricity grid can be improved.
[00149] As discussed above, data can be generated in various parts of the electricity network and transmitted to (or accessible by) a central authority. The data can then be used by the central authority to determine the integrity of the network. In addition to analyzing the health of the network, a central authority can perform usage monitoring. Normally, the mains equipment is operated with considerable safety margins. One reason for this is that utilities are conservative in nature and seek to maintain energy for the consumer within a wide margin of error. Another reason for this is that utility companies monitoring the grid may not be aware of the extent to which a piece of equipment in the electricity grid is being used. For example, if a power company is transmitting power through a particular power circuit, the power company may not have a means by which to know whether the power transmitted is close to the limit of the power circuit (for example, the circuit may become overheated). Because of this, utilities may be underutilizing one or more parts of the electricity grid.
[00150] Utility companies also typically spend a considerable amount of money to add capacity to the power grid as the load on the power grid has grown (ie the amount of energy consumed has been increasing) . Because of the ignorance of utility companies, utility companies will update the electricity grid unnecessarily. For example, supply circuits that are not operating close to capacity can, however, be upgraded by reconducting (ie, larger wires are placed in the supply circuits) or additional supply circuits can be established. This isolated cost is considerable.
[00151] Remote asset monitoring processes can monitor various aspects of the electricity network, such as: (1) analyzing the current asset integrity of one or more parts of the network; (2) analyze future asset health of one or more parts of the network; and (3) analyze the use of one or more parts of the network. First, one or more sensors can measure and transmit to remote asset monitoring processes, in order to determine the current health of a given part of the network. For example, a sensor in a power transformer can provide an indicator of its integrity by measuring the gases dissolved in the transformer. Remote asset monitoring processes can then use analytical tools to determine whether a particular part of the network (such as the power transformer) is healthy or not. If a certain part of the network is not healthy, a certain part of the network can be fixed.
[00152] In addition, remote asset monitoring processes can analyze data generated from parts of the network, in order to predict the future asset integrity of parts of the network. There are things that cause tension in the electrical components. Stress factors may not necessarily be constant and may be intermittent. The sensors can provide an indicator of the voltage over a certain part of the electricity network. Remote asset monitoring processes can record voltage measurements, as indicated by the sensor data, and can analyze voltage measurements to predict future health on the part of the power grid. For example, remote asset monitoring processes can use trend analysis to predict when the particular part of the network can fail and can schedule maintenance before (or simultaneously with) the moment when a particular part of the network can fail . In this way, remote asset monitoring processes can predict the life of a particular part of the network and thus determine whether the life of that part of the network is too short (for example, if that part of the network is being used very quickly) .
[00153] In addition, the remote asset monitoring processes can analyze the use of a part of the electricity network in order to better manage the electricity network. For example, remote asset monitoring processes can analyze a supply circuit to determine its ability to operate. In this example of the supply circuit, remote asset monitoring processes can determine that the supply circuit is currently being operated at 70%. Remote asset monitoring processes may also recommend that the particular supply circuit be operated at a higher percentage (such as 90%), while continuing to maintain acceptable safety margins. Remote asset monitoring processes can thus allow for an effective increase in capacity simply through utilization analysis. Methodology for Determining Specific Technical Architecture
[00154] There are several methodologies for determining the specific technical architecture that can use one, some, or all elements of the INDE Reference Architecture. The methodology can include a plurality of steps. First, an initial step can be taken in generating documentation of the condition of the utility company as it is, and an assessment of readiness for the transition to a Smart Grid. Second, a requirements definition step can be performed in generating the definition of what the condition should be like and the detailed requirements to achieve this condition.
[00155] Thirdly, a solution development step can be performed in the generation of the definition of the components of the solution architecture that will enable the smart grid, including measurement, monitoring and control. For the INDE architecture, this can include the measurement devices, the communication network to pass data between the devices and the CORE INDE 120 applications, the CORE INDE 120 applications to persist and react to the data, analytical applications to interpret the data , the data architecture to model measured and interpreted data, the integration architecture to exchange data and information between INDE and utility systems, the technology infrastructure to run the various applications and databases, and the standards that can be followed to enable a portable and efficient industry standard solution.
[00156] Fourth, a value modeling can be performed in the generation of the definition of key performance indicators and success factors for the Smart Grid and the application of the ability to measure and evaluate the performance of the system against the desired performance factors . The above disclosure refers to the architecture development aspect of step 3.
[00157] Figures 19A-B illustrate an example of a graphical progress flow diagram. Specifically, Figures 19A-B illustrate a process flow of the steps that can be taken to define the requirements of the smart grid and the steps that can be taken to apply the smart grid. The smart grid development process can begin with a development of the smart grid vision, which can outline the overall objectives of the project, which can lead to the smart grid roadmap process. The process of writing scripts can lead to diagramming and modeling of value.
[00158] Diagramming can provide a systematic approach to the definition of smart grid in the context of the entire utility company. The diagramming can include a global roadmap, which can lead to a baseline and systems assessment (BASE) and a definition of requirements and selection of analytics (RDAS). The RDAS process can create the detailed definition of smart grid specific to the utility company.
[00159] The BASE process can establish the starting point for the utility company in terms of systems, networks, devices and applications to support the capabilities of the smart grid. The first part of the process is to develop an inventory of network systems, which may include: network structure (such as, generation, transmission lines, transmission substations, sub-transmission lines, distribution substations, distribution feeders, voltage classes ); network devices (such as switches, reclosers, capacitors, regulators, voltage drop compensators, feeder interconnections); automation of substations (such as IEDs, substation LANs, instrumentation, station computers / RTUs); distribution automation (such as switch and capacitor control; fault isolation and load scroll controls; LTC coordination systems; DMS; Demand Response Management System), and network sensors (such as sensor types, quantities , uses, and counting in distribution networks, transmission lines and substations); etc. Once the inventory is complete, an assessment of the utility company against a high-level smart grid readiness model can be created. A data flow model as it is and a systems diagram can also be created.
[00160] The architecture configuration process (ARC) can develop a preliminary smart grid technical architecture for the utility company, combining the BASE process information, requirements and restrictions of the RDAs process and the INDE Reference Architecture for produce a technical architecture that meets the specific needs of the utility company and that takes advantage of the appropriate legacy systems and that is in accordance with the limitations that exist in the utility company. Using the Reference Architecture INDE can avoid the need to invent a customized architecture and ensures that the accumulated experience and best practices are applied in the development of the solution. It can also ensure that the solution can make maximum use of reusable smart grid assets.
[00161] The process of configuring the sensor network architecture (SNARC) can provide a structure to make the series of decisions that define the architecture of a sensor network distributed to support the intelligent network. The structure can be structured as a series of decision trees, each oriented towards a specific aspect of the sensor network architecture. Once the decisions have been made, a sensor network architecture diagram can be created.
[00162] The sensor allocation via the T-section recursion process (SATSECTR) can provide a structure to determine how many sensors should be placed in the distribution network to obtain a given level of observability, subject to cost restrictions. This process can also determine the types and locations of the sensors.
[00163] The process of evaluating the solution element and component standard (SELECT) can provide a framework for evaluating the types of components in the solution and provides a design standard for each component class. The standard can contain a reference model for the specifications of each of the elements of the solution. These standards can then be used to request quotes from suppliers and to assist supplier / product evaluations.
[00164] The update planning process for applications and networks (UPLAN) can provide the development of a plan to update the existing systems, applications and networks of the utility company, to be ready for integration into a network solution intelligent. The risk assessment and planning management (RAMP) process can provide an assessment of the risk associated with specific elements of the smart grid solution created in the ARC process. The UPLAN process can assess the level or risk for identified risk elements and provides an action plan to reduce the risk before the utility company commits to a construction. The change analysis and management planning process (CHAMP) can analyze the process and organizational changes that may be necessary for the utility to realize the value of the smart grid investment and can provide a high-level management plan. level to carry out these changes in a synchronized manner with the deployment of the smart grid. The CHAMP process can result in a diagram being generated.
[00165] The roadmap in the value modeling process can lead to specifying value metrics, which can lead to cost and benefit estimates. The estimate can lead to the creation of one or more cases, such as tax case and business case, which in turn can lead to a case closure. The result of the diagramming and value modeling can be sent to the utility company for approval, which can result in system updates from the utility company and smart grid deployments and risk mitigation activities. After which, the network can be designed, built and tested and then operated. Alternative Description of the High Level INDE Architecture
[00166] In one example, the global INDE architecture can be applied to an industry, including both mobile and stationary sensors. The INDE architecture can be applied to receive data from the sensor and respond accordingly, through both distributed and centralized intelligence. Figures 21 to 28 illustrate examples of the INDE architecture applied in various vehicle displacement industries. Global Architecture
[00167] Returning to the drawings, in which the same reference numbers refer to the same elements, Figures 21A-C illustrate an example of the global architecture for INDE. This architecture can serve as a reference model that provides end-to-end collection, transport, storage and management of network data related to one or more industries. It can also provide analytics and analytics management, as well as the integration of the previous ones in processes and systems. Thus, it can be seen as a broad enterprise architecture. Certain elements, such as operational management and aspects of the network itself, are discussed in more detail below.
[00168] The architecture represented in Figures 21A-C can contain up to four data and integration buses: (1) a 2146 high speed sensor data bus (which can include operational and non-operational data); (2) a dedicated event processing bus 2147 (which may include event data); (3) a 2130 operations service bus (which can serve to provide information about the network's back end applications); and (4) a company service bus for the back IT systems (shown in Figures 1A-C as the company 2114 integration environment bus to serve corporate IT 2121). Separate data buses can be achieved in one or more ways. For example, two or more of the data buses, such as the 2146 high-speed sensor data bus and the 2147 event processing bus, can be different segments of a single data bus. Specifically, busbars can have a segmented structure or platform. As discussed in more detail below, hardware and / or software, such as one or more switches, can be used to route data across different segments of the data bus.
[00169] As another example, two or more of the data buses can be on separate buses, such as separate physical buses in terms of the hardware needed to carry data on the separate buses. Specifically, each of the buses can include cabling separate from each other. In addition, some or all of the separate buses can be of the same type. For example, one or more of the buses may comprise a local area network (LAN), such as Ethernet® over unshielded twisted pair cabling and Wi-Fi. As discussed in more detail below, hardware and / or software, such as a driver, can be used to direct data over data to a bus among the different physical buses.
[00170] As yet another example, two or more of the buses can be in different segments in a single bus structure and one or more buses can be on separate physical buses. Specifically, the high-speed sensor data bus 2146 and the event processing bus 2147 can be different segments on a single data bus, while the enterprise integration environment bus 2114 can be on a physically separate bus.
[00171] Although figures 21A-C illustrate four buses, a smaller or greater number of buses can be used to carry the four types of data listed. For example, a single non-segmented bus can be used to communicate sensor data and event processing data (increasing the total number of buses to three), as discussed below. And, the system can operate without the 2130 operations service bus and / or the 2114 enterprise integration environment bus.
[00172] The IT environment can be compatible with SOA. Service Oriented Architecture (SOA) is a style of computer system architecture for creating and using business processes, packaged as services, throughout their life cycle. SOA also defines and supplies the IT infrastructure to allow different applications to exchange data and participate in business processes. However, the use of SOA and the enterprise service bus is optional.
[00173] In an example of a generic industry, the figures illustrate different elements within the global structure, such as the following: (1) NÚCLEO INDE 2120; and (2) INDE 2188 DEVICE. This division of the elements within the global architecture is for illustration purposes. Another division of the elements can be used. And the division of the elements can be different for different industries. The INDE architecture can be used to support both a distributed and centralized approach to network intelligence and to provide mechanisms to deal with scale in large applications.
[00174] The INDE Reference Architecture is an example of the technical architecture that can be applied. For example, it can be an example of a meta-architecture, used to provide a starting point for the development of any number of specific technical architectures, one for each industry solution (for example, different solutions for different industries) or one for each application within an industry (for example, a first solution for a first vehicle displacement network and a second solution for a second vehicle displacement network), as discussed below. Thus, a specific solution for a particular industry or a particular application within an industry (such as an application for a private utility company) may include one, some, or all of the elements in the INDE Reference Architecture. And the INDE Reference Architecture can provide a standardized starting point for the development of the solution. Discussed below is the methodology for determining the specific technical architecture for a given industry or a specific application within an industry.
[00175] The INDE Reference Architecture can be a broad enterprise architecture. Its objective may be to provide the framework for end-to-end management of data and analytics, and their integration into systems and processes. Since advanced network technology affects all aspects of business processes, one must be aware of the effects not only at the customer's network, operations and room levels, but also at the rear and company levels. Therefore, the INDE Reference Architecture can and does reference enterprise-level SOA, for example, in the sense of assisting the SOA environment for interface purposes. This should not be taken as a requirement that an industry, such as, must convert its existing IT environment to SOA before the advanced network, such as an intelligent network, can be built and used. An enterprise service bus is a useful mechanism for facilitating IT integration, but it is not necessary in order to run the rest of the solution. The discussion that follows focuses on different components of the INDE elements for vehicle displacement; however, one, some or all of the INDE elements can be applied to different industries, such as telecommunications and energy exploration. INDE Component Groups
[00176] As discussed above, the different components in the INDE reference architecture may include, for example: (1) INDE CORE 2120, and (2) INDE 2188 DEVICE. The following sections address these examples of reference architecture element groups. INDE and provide descriptions of the components of each group. CORE INDE
[00177] Figure 22 illustrates the INDE CORE 2120, which is the part of the INDE Reference Architecture that can reside in an operations control center, as shown in Figures 21A-C. The CORE INDE 2120 can contain a unified data architecture for data storage and an integration scheme for analytics to operate on that data.
[00178] In addition, this data architecture can make use of the intermediate software federation 2134 to connect other types of data (such as sensor data, operational and historical data, log and event files), and event files. connectivity and metadata files in a single data architecture that can have a single entry point for access by high-level applications, including business applications. Real-time systems can also access key data stores via the high-speed data bus, and multiple data stores can receive data in real time. Different types of data can be transported within one or more buses in the INDE architecture.
[00179] The types of data carried may include operational and non-operational data, events, network connectivity data, and network location data. Operational and non-operational data can be carried on a 2146 operational / non-operational data bus. Data collection applications may be responsible for sending some or all of the data to the 2146 operational / non-operational data bus. , applications that need this information may be able to obtain the data by subscribing to the information or invoking services that can make that data available.
[00180] Events may include messages and / or alarms from various devices and sensors that are part of an industry network, as discussed below. The events can be generated directly from the devices and sensors, as well as on various analytical applications or generated on them based on the measurement data from these sensors and devices.
[00181] As discussed in more detail below, data can be sent from various components in (such as DEDE DEVICE INDE 2188). The data can be sent wirelessly to WIRELESS CORE 2120, or a combination of both. The data can be received by communications networks of a utility company 2160, which can send the data to the targeting device 2189. The targeting device 2189 can comprise software and / or hardware for managing the targeting of data over a segment of a bus (when the bus comprises a segmented bus structure) or on a separate bus. The steering device may include one or more switches or a driver. The targeting device 2189 can comprise a network device whose software and hardware directs and / or transmits the data to one or more of the buses. For example, the data steering device 2189 can route operational and non-operational data to the operating / non-operating data bus 2146. The targeting device 2189 can also route event data to the 2147 event bus.
[00182] The targeting device 2189 can determine how to direct the data based on one or more methods. For example, the targeting device 2189 can analyze one or more headers in the transmitted data to determine whether to direct the data to the segment for the operational / non-operational data bus 2146 or for the segment for event bus 2147. Specifically, one or more data headers can indicate whether the data is operational / non-operational data (so that the targeting device 2189 routes the data to the operational / non-operating data bus 2146) or whether the data is event data (so that the device driver 2189 directs event bus 2147). Alternatively, the targeting device 2189 can examine the data load to determine the data type (for example, the targeting device 2189 can examine the data format to determine whether the data is operational / non-operational data or event data).
[00183] One of the stores, such as the 2137 operational data store that stores the operational data, can be executed as a true database. Another of the stores, the history (identified as historical data 2136 in Figures 21 and 22), can be run as a distributed database. In addition, events can be stored directly in any of several data stores via the complex event processing bus. Specifically, events can be stored in 2135 event logs, which can be repositories of all events published to the 2147 event bus. Event logs can store one, some, or all of the following: event ID; kind of event; event source; priority of the event, and time of generation of the event. The event bus 2147 does not need to store long-term events, providing persistence for all events.
[00184] The storage of the data can be such that the data can be as close to the source as possible or viable. In an implementation, this may include, for example, substation data being stored in the DEDE 2188 DEVICE. But that data may also be needed at the operations control center level 2116 to make different types of decisions that consider the network at one level. more granular. In conjunction with a distributed intelligence approach, a distributed data approach can be adopted to facilitate data availability at all levels of the solution through the use of database connections and data services, as applicable. In this way, the solution for storing historical data (which may be accessible at the level of operations control center 2116) may be similar to that for storing operational data. Historical / collective analytics can be performed at the level of operations control center 2116, accessing data at the DEDE DEVICE level. Alternatively, the data can be stored centrally in the CENTER INDE 2120. However, given the amount of data
[00185] INDE 2188 DEVICES, data storage in INDE 2188 DEVICES may be preferred. Specifically, if there are thousands or tens of thousands of sensors, the amount of data that has to be transmitted to the INDE 2120 CORE can create a bottleneck of communications.
[00186] Finally, the INDE 2120 CORE can program or control one, some or all of the INDE 2188 DEVICES on the network. For example, the CORE INDE 2120 can modify the programming (such as downloading an updated program) or provide a control command to control any aspect of the INDE 2188 DEVICE (such as sensor control or analytics). Other elements, not shown in Figure 2, can include several integration elements to support this logical architecture. Table 2 describes certain elements of the CORE INDE 2120, as illustrated in Figure 21.




Table 2: Elements of CORE INDE
[00187] As discussed in Table 2, the 2146 real-time data bus (which communicates operational and non-operational data) and the 2147 real-time complex event processing bus (which communicates event processing data) in one single 2346 bus. An example of this is illustrated in block diagram 2300 in Figures 23A-C.
[00188] As shown in Figures 21A-C, the buses are separated for performance purposes. For CEP processing, low latency may be important for certain applications that are subject to very large message bursts. Most network data flows, on the other hand, are more or less constant, with the exception of digital fault log files, but these can generally be recovered in a controlled manner, while bursts of events are asynchronous and random. .
[00189] Figure 21 also shows additional elements in the operations control center 2116 separate from CORE INDE 2120. Specifically, Figure 21 also shows the main data collection end (s) of Sensor 2153, a system that is responsible for communicating with meters (such as collecting data from them and providing the collected data to the utility company). IP network services 2158 is a set of services operating on one or more servers that support IP type communications (such as DHCP and FTP). 2159 Mobile Data Shipping System is a system that transmits / receives messages to mobile data terminals in the field. Work Management System 2150 is a system that monitors and manages work orders. Geographic Information System 2149 is a database that contains information about where the assets are geographically located and how the assets are connected together. If the environment has a Service Oriented Architecture (SOA), SOA 2148 Operations Support is a collection of services to support the SOA environment.
[00190] One or more of the systems in the Operations Control Center 2116 that are outside of the CORE INDE 2120 are legacy product systems that a utility company may have. Examples of these legacy product systems include SOA Operations Support 2148, 2153 meter data collection main end (s), 2158 IP network services, and 2159 Mobile Data Shipping System. However, these systems legacy products may not be able to process or handle data received from an intelligent network. The INDE 120 CORE may be able to receive data from the smart grid, process the data from the smart grid and transfer the processed data to one or more legacy product systems in a way that legacy product systems can use (such as a particular special format) for the legacy product system). In this way, the NÚCLEO INDE 120 can be seen as an intermediate software.
[00191] The operations control center 2116, including CORE INDE 120, can communicate with the IT of the company 2115. In general, the functionality in the IT of the company 2115 comprises back-up operations. Specifically, company 2115 IT can use company integration environment bus 2114 to send data to various systems within company 2115 IT, including Business Data Warehouse 2104, Business intelligence applications 2105, Enterprise Resource Planning 2106, various Financial Systems 2107, Customer Information System 2108, Human Resources System 2109, Asset Management System 2110, Enterprise SOA Support 2111, Network Management System 2112, and Enterprise Message Services 2113. IT Enterprise 2115 can also include a 2103 portal to communicate with the Internet 2101 through a 2102 security program. INDE DEVICE
[00192] The DEDE 2188 DEVICE group can comprise any variety of devices used to provide data associated with a particular device. In one example, the device group 2188 can include stationary sensor units 2190 and mobile sensor units 2192. Each stationary sensor unit 2190 and mobile sensor unit 2192 can include one or more sensors, processors, memory devices, modules communication and / or power modules that allow the reception of any data from the sensors, as well as the subsequent processing and / or transmission of sensor data, raw or processed. Sensor data, raw or processed, from 2190 stationary sensor units and 2192 mobile sensor units can be processed by one or more 2194 portals. In one example, each 2194 portal can be one or more devices capable of encoding and transmitting data to a 2116 operations control center. Raw or processed sensor data from stationary sensor units 2190 and mobile sensor units 2192 can also be provided to a data collector 2196. The data collector 2196 can include one or more processors, memory devices, communication modules, and power modules. The 2196 controller can be a memory device and processor configured to collect, store and transmit data. The 2196 data collector can communicate with the 2190 stationary sensor units and the 2192 mobile sensor units to collect data and transmit the collected data to one or more 2194 portals.
[00193] In one example, the 2190 stationary sensor units can detect conditions associated with one or more of the 2192 mobile sensor units or other 2190 stationary sensor units. The 2192 mobile sensor units can detect conditions associated with the sensor units stationary 2192 or can detect other conditions associated with other 2192 mobile sensor units. During operation, event data can be generated by stationary 2190 sensor units and 2192 mobile sensor units. Event data can be indicative of abnormal conditions or unwanted effects of a vehicle displacement network. Such event data can be transmitted from stationary sensor units 2190 and mobile sensor units 2192 through portals 2194 to the central authority. In one example, event data can be received by a targeting device 2189. Event data can be provided to event bus 2147 by targeting device 2189. The received event data can be processed by the operations control center 2116 to allow that an appropriate response is generated.
[00194] Figures 24A-24C is a block diagram of the INDE architecture to operate with a rail displacement network. The INDE system of Figures 24A-24B can receive event data from stationary sensor units 2190 and mobile sensor units 2192 positioned on rail cars 2400, as shown in FIG. 25. In one example, stationary sensor units 2190 and mobile sensor units 2192 can be those disclosed in U.S. Patent Application No. 2009/0173840, which is incorporated herein by reference.
[00195] With reference to FIG. 25, in one example, a 2500 freight train may include 2400 rail cars of various types, such as box wagons, freight train personnel wagons, coal wagons, locomotives, as well as any other wagon configured to be transported by rail . The 2502 locomotive can be powered by a diesel engine, battery, steering wheel, fuel cell or any combination of these. Each 2400 rail car can include one or more 2192 mobile sensor units. The 2192 mobile sensor units can communicate with each other, allowing communication between 2192 mobile sensor units from the same 2400 rail car or different 2400 rail cars attached to it. chain of 2400 rail cars or other 2400 rail cars (not shown) separate from the chain, such as those located in a train yard. Each 2192 mobile sensor unit can have a unique ID and each given 2400 rail car can have a unique ID, held by each 2192 mobile sensor unit associated with the given 2400 rail car. IDs can be provided via RFID, for example .
[00196] In one example, the 2190A stationary sensor units can be configured to function as a "hot box" detector configured to monitor the heat associated with the wheels of a railway wagon, wheel axles, etc. The term "hot box", as known in the art, can refer to a railway wagon experiencing overheating in one or more wheel axle bearings and / or another component based on the wheels on a piece of rolling stock on the road. iron. 2190A stationary sensor units can be placed along railroad tracks 2501. Each 2190A stationary sensor unit can be equipped with one or more infrared (IR) sensors to determine the heating patterns of the bearings / axles / rail car wheels 2400 as rail cars pass through a detection zone of a particular 2190A stationary sensor unit. Abnormal heating can indicate several problems, such as load unbalance of the railway wagon, structural problems of the railway wagon, rail problems, etc. If an overheated bearing is detected, an alarm type can be triggered to alert the engineer to stop the train and correct the potentially dangerous situation which, if allowed to continue, could result in a train derailment. An example of a hot box detector is disclosed in U.S. Patent No. 4,659,043, which is incorporated herein by reference. The 2190A stationary sensor units can be configured to process the IR sensor data to generate alarm-based event data, such as event messages, to be received by the 2147 event bus for further processing.
[00197] The 2192B stationary sensor units can also serve as a fault detector. A fault detector can be a device used on railways to detect wheel axle and signal problems in passing trains. The fault detectors can be integrated into the railway tracks and can include sensors to detect one or more types of problems that could occur. Flaw detectors allow railroads to eliminate the staff wagon at the rear of the train, as well as several station agents posted along the route to detect unsafe conditions. The fault detector can be integrated or associated with a wired or wireless transmitter. As trains pass through the fault detectors, the fault detector can generate the name of the railway, mileage distance or location, track number (if applicable), number of wheel axles on the train that has passed and indication "no fault" to indicate that no train problems were detected. In addition, the ambient temperature of the location and the speed of the train can be emitted. When a problem is detected, the detector can produce an alarm indication, followed by a description of the problem and the position of the wheel axle on the train where the problem occurred.
[00198] 2190C stationary sensor units can also be configured to function as "silver boxes", as known in the art, configured to receive raw or processed data received by one or more stationary sensor units 2190A and 2190B. The 2190C stationary sensor units can receive data from a respective group of 2190A stationary sensor units based on several common factors, such as geographic location, for example. In this regard, the stationary sensory units 2190C can act as a data collector 2196, as shown in Figures 21A-21C.
[00199] During operation, a 2500 train with a 2400 railroad car chain can travel along 2502 railroad tracks. As the 2500 train travels, the 2190A stationary sensor units can detect information about each 2400 railcar, such as bearing temperature. Each 2190A stationary sensor unit can also communicate with each 2192 mobile sensor unit. Communication can allow each 2190A stationary sensor unit to perform an integrity check on each 2400 rail car and associated 2192 mobile sensor units. Any indication of abnormal or unwanted conditions associated with a given 2400 rail car can be relayed to the 2190C stationary sensor units. The conditions detected can be related to the structure of the railway wagon, the environment of the railway wagon (for example, temperature), the content of the railway wagon (for example, weight, distribution, quantity, etc.), the movement of the railway wagon , the position of the railway car, or any other parameter of interest in relation to a 2400 railway car. The conditions detected can also relate to security, such as when a railway car door is opened, which may indicate an attempted theft or vandalism. Event data 2508 can be used to alert a particular private organization that may own a particular railway car. Thus, the 2116 operations control center can supervise an entire rail network, but companies that own individual 2400 rail cars can be alerted when event data is transmitted over a given 2400 rail car (s) from owned by a private company. Alert messages can be provided through an interface, subscription service, e-mail, text message and / or any other forms of communication capable of providing such alerts.
[00200] In one example, one of the railway cars 2400, such as locomotive 2502, may have a mobile sensor unit 2192 serving as a main mobile sensor unit 2504 to receive data from each stationary mobile unit 2192 associated with the 2400 rail cars in the current rail car chain. When rail cars 2400 are connected to form a particular train, each 2192 mobile sensor unit can enroll with the main mobile sensor unit 2504. The main mobile sensor unit 2504 can receive periodic or continuous streams of raw or processed data from of the 2192 mobile sensor units. This allows the engineer to determine the integrity of each 2400 rail car during use.
[00201] In one example, each 2190 mobile sensor unit can include a global positioning system (GPS) module, allowing each individual 2192 mobile sensor unit to determine a respective geographic location. Each 2190 mobile sensor unit can receive GPS 2506 signals to determine geographic location. This information can be relayed to the 2192A stationary sensor units when a given railway car is nearby to allow the transmission of such information. Each 2192 mobile sensor unit can automatically or on request relay the geographic position to the main mobile sensor unit 2504, which can then be relayed via an onboard 2194 portal to the 2116 operations control center. In one example , portal 2194 can be the one described in American patent publication No. 2009/0173840. Each 2192A mobile sensor unit can also wirelessly transmit a GPS signal, allowing each 2400 rail car to be individually monitored. Such a provision can allow an entire train to be tracked when only a single railway car has free access to GPS satellites, such as when a train is moving through a tunnel.
[00202] Each of the stationary sensor units 2190 and the mobile sensor units 2192 can at least part of the sensor data and generate an "event". The event can comprise a non-incident event or an incident event. The non-incident event may indicate that there is no incident (such as no fault) to report. The incident event may indicate that an incident has occurred or is occurring, such as a failure that has occurred or is occurring in the section of the rail travel network.
[00203] Stationary sensor units 2190 and mobile sensor units 2192 may include one or both of: (1) intelligence to determine if there is an incident, and (2) ability to take one or more actions based on determining the existence of an incident. In particular, the memory in one or more of the stationary sensor units 2190 and the mobile sensor units 2192 may include one or more rules for determining different types of incidents based on the data generated by one or more sensors. Or, the memory in stationary sensor units 2190 and mobile sensor units 2192 may include one or more look-up tables to determine different types of incidents based on the data generated by one or more sensors. In addition, 2190 stationary sensor units and 2192 mobile sensor units may include the ability to take one or more actions based on determining the existence of an incident.
[00204] In addition to working alone, the electronic elements in the rail displacement network can work together as part of the distributed intelligence of the rail displacement network. For example, stationary sensor units 2190 and mobile sensor units 2192 can share data or can share processing power to jointly determine if an incident exists and take one or more actions based on determining whether an incident exists.
[00205] Actions include, but are not limited to: (1) sending the incident determination on the event bus 2147, (2) sending the incident determination, along with a recommended action on the event bus 2147, and (3 ), take action to modify the condition of one or more sections of the train displacement network or one or more vehicles circulating in the train displacement network. For example, the 2190 stationary sensor units can control one or more switches in a section of the rail travel network (such as redirecting traffic to a separate rail line, opening a lane for travel in different directions, etc.) Or, 2190 stationary sensor units can modify the parameters of one or more sensors in a section of the rail travel network (such as commanding the sensors to be more sensitive in their readings, commanding the sensors to generate more frequent readings, etc.). As yet another example, stationary sensor units 2190 and mobile sensor units 2192 can control one or more vehicles circulating in the train travel network. For example, a locomotive may include remote control-command capability, where the locomotive may be able to receive a wirelessly transmitted command to control one or more aspects of the locomotive. The one or more aspects that the command controls can include, but is not limited to, the speed of the locomotive, generating a whistle (or other type of noise) and generating a light (or other type of visual indication). The locomotive receiver can receive the command and the locomotive processor can control one or more aspects of the locomotive based on the command (such as modifying engine operation).
[00206] The rail displacement network may include distributed intelligence. As discussed above, the different 2190 stationary sensor units and mobile sensor units within the 2192 rail displacement network can include additional functionality, including additional processing / analytical capabilities and database features. The use of this additional functionality within several 2190 stationary sensor units and 2192 mobile sensor units in the rail displacement network allows for distributed architectures with centralized management and application administration and network performance. For reasons of functionality, performance and scalability, a rail displacement network, involving thousands of stationary 2190 sensor units and 2192 mobile sensor units can comprise distributed processing, data management and process communications.
[00207] Non-operational data and operational data can be associated with and in the vicinity of the 2190 stationary sensor units and the 2192 mobile sensor units. The 2190 stationary sensor units and the 2192 mobile sensor units can further include displacement network components. railway, which are responsible for observing the rail displacement network in various sections. Stationary sensor units 2190 and mobile sensor units 2192 can provide three main functions: acquisition of operational data and storage in distributed operational data storage; acquisition of non-operational data and storage in the historian; processing of local analytics on a real-time basis (such as a sub-second). Processing can include digital signal processing, detection and classification processing, including event flow processing; and communication of processing results to local systems and devices, as well as to 2116 operations control center systems. Communication between 2190 stationary sensor units and 2192 mobile sensor units and other devices on the rail travel network can be wired, wireless, or a combination of wired and wireless. The electronic element can transmit data, such as operational / non-operational data or event data to the 2116 operations control center. A guiding device can direct the transmitted data to one of the operational / non-operational data buses or the bus event.
[00208] One or more types of data can be duplicated in the electronic element and in the operations control center 2116, thus allowing an electronic element to operate independently, even if the data communication network for the operations control center 2116 is not functional. With this information (connectivity) stored locally, analytics can be performed locally, even if the communication link with the 2116 operations control center is inoperative.
[00209] In the same way, the operational data can be duplicated in the operations control center 2116 and in the electronic elements. Data from sensors and devices associated with a particular electronic element can be collected and the last measurement can be stored in this data storage in the electronic element. The data structures of the operational data can be the same and therefore database connections can be used to provide continuous access to the data residing in the electronic element through the example of the operational data storage example in the operations control center 2116 This provides a number of advantages, including relieving data replication and allowing data analytics, which is more time sensitive, to take place locally and without depending on the availability of communication beyond the electronic element. Data analytics at the 2116 operations control center level may be less time sensitive (since the 2116 operations control center can typically examine historical data to discern patterns that are more predictive, rather than reactive) and may be able to work around network problems, if any.
[00210] Finally, historical data can be stored locally in the electronic element and a copy of the data can be stored in the operations control center 2116. Or, database connections can be configured in the repository instance in the operations control center 2116, providing access from the operations control center to data on each of the electronic elements. Analyzes of electronic elements can be performed locally on the electronic element using local data storage. Specifically, using the additional intelligence and storage capacity in the electronic element allows the electronic element to analyze itself and correct itself, without the intervention of a central authority.
[00211] Alternatively, historical / collective analytics can also be performed at the level of operations control center 2116 through access to data in the local instances of the electronic element using database connections.
[00212] In addition, several analytics can be used to analyze data and / or events. One type of analytics can include spatial visualization. Spatial visualization ability or visual-spatial ability is the ability to manipulate 2-dimensional and 3-dimensional figures. Spatial visualization can be performed using one or more electronic elements or can be performed by the central authority. In addition, spatial visualization can be used with a variety of industry networks, including utility networks and vehicle travel networks.
[00213] In one example, during operation, event data 2508 can be produced for each mobile sensor unit 2192. Event data 2508 can be transmitted to the main mobile sensor unit 2504. The main mobile sensor unit 2504 can wirelessly transmit event data from the portal to the 2116 operations control center for processing through a 2194 portal. In alternative examples, each 2400 railcar can include a respective 2194 portal, allowing data to be transmitted directly from the 2400 rail car mobile sensor unit. This allows 2400 rail cars to communicate when not connected to a 2502 locomotive, such as those being stored in a train yard, to communicate event data 2508 to be received by the operations control center 2116. In other alternative examples, each train yard can have one or more stationary sensor units 2190 and portal 2194 to communicate with stored 2400 rail cars and to transmit any data 2508. Similarly, stationary sensor units 2190A and 2190B can transmit from from the sensor to the stationary sensor and event data through a similar 2194 portal (s) to relay such information to the 2116 operations control center.
[00214] As described above, the network of Figures 24A-4C can also allow distributed analysis in such a way that event data 2508 is processed in stationary sensor units 2190A and 2190B and in the main mobile sensor module 2504. This processing it can allow any problems to be analyzed and it can provide a solution or course of action. Such a solution of the problem can be transmitted can be used to automatically control the 2500 train in any capacity once the 2500 train is configured to allow or can alert human operators to control the 2500 train accordingly. The solution can also be transported to the 2116 operations control center allowing the 2116 operations control center to take actions remotely to confirm the solution to the problem and apply the solution accordingly.
[00215] Figure 26A-26C is a block diagram of an execution of the INDE architecture related to an electric train network, such as an urban train. An electric train network can include one or more electric trains that can be powered by overhead power lines or a third rail. In one example, a 2600 electric train can include one or more 2602 rail cars. Each rail car can be individually powered by an external source (for example, third rail or overhead lines) or internal sources (for example, batteries or fuel cells) ). Each rail car can include one or more 2192 mobile sensor units. Each 2192 mobile sensor unit can detect various conditions associated with various predetermined parameters of the 2600 train.
[00216] In the example shown in Figures 26A-26C, the electric train 2600 can be powered by a third rail 2604. The third rail 2604 can be connected to one or more stationary sensor modules 2192 that can control the energy flowing through the third track 2604. The 2190 stationary sensor modules can determine the integrity of the rail system and transmit any condition, abnormal, undesirable, or verification events in the form of event messages. Event messages can be transmitted through a 2194 portal to be received by the 2116 operations control center.
[00217] Each 2602 electric rail car can include one or more 2192 mobile sensor units. One of the 2192 mobile sensor units can serve as a main mobile sensor unit, such as the main mobile sensor unit 2504. The sensor units 2192 furniture can accumulate information related to the respective railway wagon in a similar way to that discussed in relation to Figures 25A-5B. The main mobile sensor unit for the 2600 electric train can transmit event messages generated by the other 2192 mobile sensor units to the central authority via the 2120 portal.
[00218] Figures 27A-27C is a block diagram of an execution of the INDE architecture applied to a road cargo transport network, such as that used in the truck industry. In one example, one or more 2192 mobile sensor units may be included in 2700 cargo containers, such as those towed by 2704 diesel engine trucks. Each 2192 mobile sensor unit may be similar to those 2192 mobile sensor units discussed with with respect to Figures 25A-26C. Each 2192 mobile sensor unit can detect various conditions of the 2700 cargo containers and relay them via an onboard 2194 portal to the 2116 operations control center. 2190 stationary sensor units can be deployed at the customer site, allowing the load is verified using communication between the 2190 stationary sensor units and the 2192 mobile sensor units. The 2192 mobile sensor units can be used for cargo tracking, cargo container environment, theft / vandalism detection and any other uses as described in relation to Figures 24A-25.
[00219] Figures 28A-28C is a block diagram of an execution of the global INDE architecture applied to a network of vehicles, which can be fueled with oil, electric, hybridly fueled, bio-fueled or fueled in any other appropriate way. In one example, a 2800 vehicle can include one or more mobile sensor units 2192 allowing various conditions of the 2800 vehicle to be monitored. Each vehicle can have a 2194 portal or communicate via an external 2194 portal to communicate event data directly to CORE INDE 120 or other 2192 mobile sensor units. Similar to other examples discussed, 2192 mobile sensor units can include distributed intelligence which can perform analytics involved with the vehicle or can do so by interacting with CORE INDE 2120. 2190 stationary sensor units can be used to communicate with the 2192 mobile sensor units allowing the evaluation of a 800 vehicle with a sensor unit mobile 2192 in close proximity to communicate with stationary sensor units 190. Stationary sensor units 2190 can include or share a portal 194 allowing event data to be transmitted to the INDE CORE 2120 or you can transmit it directly to the INDE CORE 120. The 2190 stationary sensor units can be run by car rental companies, sales staff or individual owners to receive event data associated with the condition and / or location of a 2800 vehicle.
[00220] Figure 30 shows an example of INDE 2000 systems that can be remotely hosted, as shown in the block diagram. At a 3000 hosting site, 2002 network cores can be installed as needed to support INDS subscribers for a given industry. In one example, as subscriber 3002 may require the use of various industries, such as rail, truck and airline. An INDE 2000 system can be modular, allowing more types of industry to be added, or in alternative examples, a new subscriber. A separate group from the utility company can manage and support software for one, some or all of the INDE 2000 systems, as well as applications that are downloaded from the INDS hosting site to be used for system terminals 2006 and 2008 system infrastructure. In order to facilitate communications, low latency and high bandwidth communications services, such as over the 3004 network (for example, an MPLS or another WAN), it can be used that can reach centers of operations of the public utility services subscribers, as well as the INDS hosting locations.
[00221] Although the present invention has been shown and described in connection with the preferred embodiments, it is evident that certain changes and modifications, in addition to those mentioned above, can be made from the basic features of the present invention. In addition, there are many different types of software and hardware that can be used in carrying out the invention, and the invention is not limited to the examples described above. The invention has been described with reference to symbolic acts and representations of operations that are performed by one or more electronic devices. As such, it must be understood that the acts and operations include the manipulation by the processing unit of the electronic device of electrical signals that represent the data in a structured way. This manipulation transforms the data or keeps it in places in the electronic device's memory system, which reconfigures or otherwise changes the operation of the electronic device in a way well understood by those skilled in the art. Data structures, where the data is kept, are physical locations of memory that have particular properties defined by the format of the data. Although the invention is described in the foregoing context, it is not intended to be limiting, since those skilled in the art will appreciate that the described acts and operations can also be performed on hardware. Accordingly, it is the applicants' intention to protect all variations and modifications within the valid scope of the present invention. The invention is intended to be defined by the following claims, including all equivalents.

权利要求:
Claims (33)
[0001]
1. Integration structure to facilitate communication with a central authority that manages an industry network, the integration structure comprising: a plurality of sensors and components of the industry network configured to generate operational data and event data within the network industry; characterized by the fact that it comprises an operational bus (2010) in communication with the plurality of sensors and components of the industry network, the operational bus (2010) configured to receive the operational data and to communicate the operational data to the central authority, the operational data comprising a real-time measurement for at least one sensor or network component of the industry, and an event bus (2147, 2012) in communication with the plurality of sensors and network components of the industry, the event bus (2147 , 2012) configured to receive event data and to communicate event data to the central authority, the event bus (2147, 2012) being separated from the operational bus (2010), the event data being distinct from and from derivatives to from real-time measurement, and comprising at least one analytical determination based on at least one real-time measurement, where operational data is communicated via the operational bus (2010) and not communicated via the event bus (2147, 2012), and where event data is communicated via the event bus (2147, 2012) and not communicated via the operational bus (2010 ).
[0002]
2. Integration structure, according to claim 1, characterized by the fact that the industry network comprises a vehicle displacement network.
[0003]
3. Integration structure, according to claim 2, characterized by the fact that the vehicle displacement network comprises a rail displacement network.
[0004]
4. Integration structure, according to claim 2, characterized by the fact that the vehicle displacement network comprises a truck transport system network.
[0005]
5. Integration structure, according to claim 1, characterized by the fact that it still comprises a router to analyze at least part of the received data and to forward the data to one of the operational bus (2010) and the event bus (2147, 2012).
[0006]
6. Integration structure, according to claim 5, characterized by the fact that the router analyzes at least one header in the data to determine whether it will forward the data to the operational bus (2010) or to the event bus (2147, 2012).
[0007]
7. Integration structure, according to claim 5, characterized by the fact that the router is located in the central authority.
[0008]
8. Integration structure, according to claim 1, characterized by the fact that the operational bus (2010) communicates non-operational data, non-operational data comprising at least one of the following: performance, health of assets and data of stress.
[0009]
9. Integration structure, according to claim 1, characterized by the fact that the plurality of sensors includes: mobile sensors (2192) connected to the mobile units of the industry network and configured to generate endpoint data, and stationary sensors ( 2190) configured to detect at least one aspect related to the industry's network infrastructure, and to generate infrastructure data indicative of at least one aspect.
[0010]
10. Integration structure, according to claim 9, characterized by the fact that the stationary sensors (2190) comprise memory and rules stored in memory, in which the stationary sensors (2190) are still configured to receive the endpoint data and run the rules to determine event data based on infrastructure and endpoint data.
[0011]
11. Integration structure, according to claim 1, characterized by the fact that the operational bus (2010) is configured to: filter a plurality of event flows to interpret the plurality of event flows according to at least one standard event, and send the interpretation of the plurality of event flows to at least the central authority.
[0012]
12. Integration structure, according to claim 1, characterized by the fact that it still comprises: a server coupled with the operational bus (2010) and the event bus (2147, 2012) and configured to receive and store operational data , the server still configured to: analyze operational data in relation to at least one rule; generate at least one event based on the analysis, and send at least one event to at least one of the network industry sensors and components to trigger self-treatment within at least one section of the industry network.
[0013]
13. Integration structure, according to claim 12, characterized by the fact that the server resides in a central control center (2116), in which at least one event triggers a modification for the operation of the central control center.
[0014]
14. Integration structure, according to claim 12, characterized by the fact that the server is still configured to generate a work order for transmission to the central authority.
[0015]
15. Integration structure to facilitate communication with a central authority that manages an industry network, the integration structure comprising: a system infrastructure (2008) comprising: a plurality of stationary sensors (2190) configured to detect at least one aspect in relation to the industry network infrastructure and generate the infrastructure data indicative of at least one aspect, and at least one infrastructure analysis module (2020) configured to receive the infrastructure data and to receive the endpoint data from one or more mobile sensors (2192) connected to the mobile units of the industry network, the infrastructure analysis module (2020) configured to generate event data based on the infrastructure and endpoint data; characterized by the fact that it comprises an operational bus (2010) in communication with the plurality of stationary sensors (2190) and the infrastructure analysis module (2020), the operational bus (2010) configured to receive the infrastructure and point data end and to communicate infrastructure and endpoint data to the central authority, infrastructure and endpoint data comprising at least one real-time measurement for at least part of the industry network, and an event bus (2147, 2012) in communication with the infrastructure analysis module (2020), the event bus (2147, 2012) configured to receive the event data and to communicate the event data to the central authority, the event bus being separated from the bus (2010), the event data being distinct and derived from real-time measurement and comprising at least one analytical determination such as the operation of the industry network based on and at least one measurement in real time; a network core (2002) configured to receive the endpoint event data exclusively through the event bus (2147, 2012) and to generate a command based on the event data, in which events within the event data comprise conditions undesirable or abnormal occurring within the industry system; where the command is sent to an endpoint that includes at least one of the mobile sensors (2192) that generated the endpoint data, for executing the command to control a mobile unit in the industry network in response to unwanted or abnormal conditions .
[0016]
16. Integration structure, according to claim 15, characterized by the fact that an event comprises an alert that is also sent to an organization that has one or more mobile units.
[0017]
17. Integration structure, according to claim 16, characterized by the fact that the alert comprises a security message indicative of an attempted theft or vandalism.
[0018]
18. Integration structure according to claim 15, characterized by the fact that the stationary sensors (2190) include memory and rules stored in memory, in which the stationary sensors (2190) are configured to execute the rules to determine an event based on infrastructure and endpoint data.
[0019]
19. Integration structure, according to claim 18, characterized by the fact that the event bus (2147, 2012) is in additional communication with stationary sensors (2190) to receive event data from stationary sensors (2190 ).
[0020]
20. Integration structure, according to claim 15, characterized by the fact that the industry system is a railway system and the mobile units comprise individual wagons (2400).
[0021]
21. Integration structure according to claim 20, characterized by the fact that the stationary sensors (2190) are further configured to control one or more switches in a section of the railway system.
[0022]
22. Integration structure according to claim 20, characterized by the fact that the stationary sensors (2190) are configured to modify one or more parameters of one or more other sensors in a section of the railway system.
[0023]
23. Integration structure according to claim 20, characterized by the fact that at least one of the stationary (2190) or mobile sensors is configured to control one or more wagons (2400) moving within the rail system.
[0024]
24. Integration structure according to claim 20, characterized by the fact that at least some of the stationary sensors (2190) include defect detectors that are configured to detect a potential unsafe condition of a wagon (2400).
[0025]
25. Integration structure, according to claim 15, characterized by the fact that the industry system is a road transport system and mobile sensors (2192) are connected to cargo containers to track cargo containers.
[0026]
26. Integration structure, according to claim 25, characterized by the fact that the stationary sensors (2190) are distributed at the customer's premises and are configured to receive the endpoint data from the mobile sensors (2192) of the containers of cargo.
[0027]
27. Method for communicating data to a central authority that manages an industry network, the method characterized by the fact that it comprises the steps of: communicating, at least partially wirelessly, operational data to the central authority on an operational bus (2010) , operational data received from a plurality of sensors and network components of the industry and comprising at least a real-time measurement of at least one sensor or network component, and communicating, at least partially wirelessly, the event data to the central authority on an event bus (2147, 2012), the event bus (2147, 2012) being separated from the operational bus (2010), the event data received from at least some of the plurality of sensors and components of industry network and being distinct and derived from real-time measurement, event data still comprising at least one analytical determination as the operation of the industry network co m based on at least one real-time measurement, in which operational data are communicated via the operational bus (2010) and not communicated via the event bus (2147, 2012), and in which event data are communicated via the event bus (2147, 2012) and not communicated through the operational bus (2010).
[0028]
28. Method, according to claim 27, characterized by the fact that it still comprises the steps of: analyzing, by a router, at least a part of the received data, and forwarding, through the router, the data to one of the operational bus ( 2010) and the event bus (2147, 2012) based on the analysis of at least a part of the data received.
[0029]
29. Method, according to claim 27, characterized by the fact that the operational bus (2010) still communicates non-operational data, non-operational data comprising at least one among performance, asset health and stress data.
[0030]
30. Method, according to claim 27, characterized by the fact that it still comprises: filtering, through the event bus (2147, 2012), a plurality of event flows to interpret the plurality of event flows according to at least an event pattern, and send, through the event bus (2147, 2012), the interpretation of the plurality of event flows to at least one of the plurality of sensors and components of the industry network.
[0031]
31. Method, according to claim 27, characterized by the fact that it still comprises the steps of: receiving and storing operational data by a server coupled with the operational bus (2010) and the event bus (2147, 2012); analyze, by the server, the operational data with respect to at least one rule; generate, by the server, at least one event based on the analysis, and send, by the server, at least one event to at least one of the sensors and components of the industry network to trigger the self-treatment within at least one section of the industry network.
[0032]
32. Method, according to claim 31, characterized by the fact that the server resides in a central control center (2116) of the industry network, further comprising: triggering, by the server, an operation modification of the control center ( 2116) central based on at least one event.
[0033]
33. Method, according to claim 31, characterized by the fact that it still comprises: generating a service order by the server for transmission to the central authority.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112012023696B1|2021-01-05|integration structure to facilitate communication with a central authority that manages an industry network and method for communicating data to said authority

---

US10833532B2|2020-11-10|Method and system for managing a power grid

---

BR112012029417B1|2020-12-15|METHOD AND SYSTEM FOR DEFINING MALICIOUS ACTIVITY IN AN INTELLIGENT ELECTRIC NETWORK SYSTEM AND COMPUTER-READABLE STORAGE MEDIA

---

BRPI0923437B1|2021-03-09|method of determining a type of failure in a multiphase power network

---

BR112012021714B1|2020-02-04|electric power grid command filter system

---

AU2012241193B2|2015-06-25|Method and system for managing a power grid

---

AU2015230786B2|2016-09-08|Method and system for managing a power grid

---

Hälvä2013|Development of Process Data Utilization in Proactive Network Management

---

Yang et al.2015|Research and development status of mobile informatization in China power industry

同族专利:

---

公开号 | 公开日

---

WO2011116074A3|2011-11-10|

---

NZ603089A|2015-02-27|

---

EP2548087B1|2019-06-19|

---

JP2016029798A|2016-03-03|

---

JP6100160B2|2017-03-22|

---

RU2546320C2|2015-04-10|

---

AU2011227319A9|2013-10-03|

---

US9876856B2|2018-01-23|

---

WO2011116074A2|2011-09-22|

---

MY163625A|2017-10-13|

---

CA2793953C|2018-09-18|

---

US20110004446A1|2011-01-06|

---

EP2548087A2|2013-01-23|

---

JP6417295B2|2018-11-07|

---

CA2793953A1|2011-09-22|

---

BR112012023696A2|2016-08-23|

---

AU2011227319B2|2015-01-22|

---

ZA201207010B|2016-07-27|

---

US20140012954A1|2014-01-09|

---

CN102870056B|2016-10-12|

---

RU2012144395A|2014-05-10|

---

JP2013523019A|2013-06-13|

---

NZ702729A|2015-12-24|

---

CN102870056A|2013-01-09|

---

AU2011227319A1|2012-11-08|

---

SG184121A1|2012-10-30|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US4659043A|1981-10-05|1987-04-21|Servo Corporation Of America|Railroad hot box detector|

---

US4781119A|1984-09-10|1988-11-01|Davis James G|Solar-rapid rail mass transit system|

---

US5735492A|1991-02-04|1998-04-07|Pace; Joseph A.|Railroad crossing traffic warning system apparatus and method therefore|

---

US5455776A|1993-09-08|1995-10-03|Abb Power T & D Company Inc.|Automatic fault location system|

---

US5513061A|1993-12-09|1996-04-30|Long Island Lighting Company|Apparatus and method for distributing electrical power|

---

JP3628416B2|1996-02-15|2005-03-09|住友電気工業株式会社|Mobile database management system|

---

JPH10119780A|1996-10-15|1998-05-12|Eikura Tsushin:Kk|Remote controllable and remote monitorial train instrumentation system|

---

US7046682B2|1997-02-12|2006-05-16|Elster Electricity, Llc.|Network-enabled, extensible metering system|

---

US5923269A|1997-06-06|1999-07-13|Abb Power T&D Company Inc.|Energy meter with multiple protocols for communication with local and wide area networks|

---

US6437692B1|1998-06-22|2002-08-20|Statsignal Systems, Inc.|System and method for monitoring and controlling remote devices|

---

US6104978A|1998-04-06|2000-08-15|General Electric Company|GPS-based centralized tracking system with reduced energy consumption|

---

AUPP855599A0|1999-02-08|1999-03-04|Nu-Lec Pty Ltd|Apparatus and method|

---

WO2001001366A2|1999-06-25|2001-01-04|Telemonitor, Inc.|Smart remote monitoring system and method|

---

IT1320415B1|2000-06-09|2003-11-26|Skf Ind Spa|METHOD AND EQUIPMENT TO DETECT AND REPORT DETAILING CONDITIONS IN A RAILWAY VEHICLE.|

---

SE519943C2|2000-12-14|2003-04-29|Abb Ab|Method for fault location in a transmission line|

---

US7062359B2|2000-12-29|2006-06-13|Abb Ab|Substation control system|

---

US20020103772A1|2001-01-31|2002-08-01|Bijoy Chattopadhyay|System and method for gathering of real-time current flow information|

---

JP2004533034A|2001-02-22|2004-10-28|コーヨームセンアメリカ，インコーポレイテッド|Apparatus, method and system for capturing, analyzing, integrating, distributing and utilizing data on current events|

---

DE60144367D1|2001-05-21|2011-05-19|Abb Research Ltd|Stability prediction for electric power grid|

---

US6985803B2|2001-05-30|2006-01-10|General Electric Company|System and method for monitoring the condition of a vehicle|

---

EP1288757A1|2001-08-07|2003-03-05|Siemens Aktiengesellschaft|Method and process control system for operating a technical installation|

---

US7568000B2|2001-08-21|2009-07-28|Rosemount Analytical|Shared-use data processing for process control systems|

---

JP3816770B2|2001-09-03|2006-08-30|ヤンマー株式会社|Cool container remote monitoring and control system|

---

DE60119555T2|2001-12-21|2007-03-08|Abb Schweiz Ag|Determination of operating limits in an energy distribution network|

---

JP2003206030A|2002-01-15|2003-07-22|Mazda Motor Corp|Physical distribution supporting system and method and program therefor|

---

US6892115B2|2002-02-25|2005-05-10|General Electric Company|Method and apparatus for optimized centralized critical control architecture for switchgear and power equipment|

---

US7031859B2|2002-03-11|2006-04-18|Piesinger Gregory H|Apparatus and method for identifying cable phase in a three-phase power distribution network|

---

US6667610B2|2002-03-11|2003-12-23|Gregory Hubert Piesinger|Apparatus and method for identifying cable phase in a three-phase power distribution network|

---

US6662124B2|2002-04-17|2003-12-09|Schweitzer Engineering Laboratories, Inc.|Protective relay with synchronized phasor measurement capability for use in electric power systems|

---

EP1408595B1|2002-10-10|2017-06-14|ABB Research Ltd.|Determining parameters of an equivalent circuit representing a transmission section of an electrical network|

---

EP1556936B1|2002-10-25|2016-12-07|S & C Electric Company|Method and apparatus for control of an electric power system in response to circuit abnormalities|

---

US7213789B1|2003-04-29|2007-05-08|Eugene Matzan|System for detection of defects in railroad car wheels|

---

WO2004099503A1|2003-05-12|2004-11-18|Franz Plasser Bahnbaumaschinen-Industriegesellschaft Mbh|Control device and method for monitoring a work train|

---

US7689323B2|2003-05-13|2010-03-30|Siemens Aktiengesellschaft|Automatic generation control of a power distribution system|

---

US7739138B2|2003-05-19|2010-06-15|Trimble Navigation Limited|Automated utility supply management system integrating data sources including geographic information systems data|

---

JP3952999B2|2003-06-24|2007-08-01|オムロン株式会社|Automatic ticket gate|

---

US7233843B2|2003-08-08|2007-06-19|Electric Power Group, Llc|Real-time performance monitoring and management system|

---

US7013203B2|2003-10-22|2006-03-14|General Electric Company|Wind turbine system control|

---

US7729818B2|2003-12-09|2010-06-01|General Electric Company|Locomotive remote control system|

---

US8108184B2|2004-01-15|2012-01-31|Bruce Fardanesh|Methods and systems for power systems analysis: a non-iterative state solver/estimator for power systems operation and control|

---

GB0402739D0|2004-02-09|2004-03-10|Saviso Group Ltd|Methods and apparatus for routing in a network|

---

US7239238B2|2004-03-30|2007-07-03|E. J. Brooks Company|Electronic security seal|

---

WO2006021398A2|2004-08-27|2006-03-02|Accenture Global Services Gmbh|Railcar transport telematics system|

---

US20060259255A1|2005-04-05|2006-11-16|Anderson James C|Method of visualizing power system quantities using a configurable software visualization tool|

---

US20060224336A1|2005-04-05|2006-10-05|Charles Petras|System and method for transmitting power system data over a wide area network|

---

US7444248B2|2005-04-29|2008-10-28|General Electric Company|System and method for synchronized phasor measurement|

---

US7708232B2|2005-05-19|2010-05-04|Progressive Rail Technologies, Inc.|Railroad car lateral instability and tracking error detector|

---

JP4755473B2|2005-09-30|2011-08-24|東日本旅客鉄道株式会社|Signal control system|

---

US7480580B2|2005-10-18|2009-01-20|Schweitzer Engineering Laboratories, Inc.|Apparatus and method for estimating synchronized phasors at predetermined times referenced to an absolute time standard in an electrical system|

---

US7720639B2|2005-10-27|2010-05-18|General Electric Company|Automatic remote monitoring and diagnostics system and communication method for communicating between a programmable logic controller and a central unit|

---

EP1780858A1|2005-10-31|2007-05-02|ABB Technology AG|Arrangement and method for protecting an electric power system|

---

JP2009521902A|2005-12-23|2009-06-04|エーエスエフ−キーストーンインコーポレイテッド|Train monitoring system|

---

US8332567B2|2006-09-19|2012-12-11|Fisher-Rosemount Systems, Inc.|Apparatus and methods to communicatively couple field devices to controllers in a process control system|

---

US7630863B2|2006-09-19|2009-12-08|Schweitzer Engineering Laboratories, Inc.|Apparatus, method, and system for wide-area protection and control using power system data having a time component associated therewith|

---

RU2363973C2|2006-12-13|2009-08-10|Николай Валентинович Татарченко|Modular engineering system|

---

US7472026B2|2006-12-22|2008-12-30|General Electric Company|Multi-ended fault location system|

---

US20080177678A1|2007-01-24|2008-07-24|Paul Di Martini|Method of communicating between a utility and its customer locations|

---

US7620517B2|2007-02-05|2009-11-17|Abb Research Ltd.|Real-time power-line sag monitoring using time-synchronized power system measurements|

---

US20090089359A1|2007-09-27|2009-04-02|Rockwell Automation Technologies, Inc.|Subscription and notification in industrial systems|

---

US8672273B2|2008-01-09|2014-03-18|International Business Machines Corporation|Rail car sensor network|

---

SG10201606766QA|2008-05-09|2016-10-28|Accenture Global Services Ltd|Method and system for managing a power grid|US7233843B2|2003-08-08|2007-06-19|Electric Power Group, Llc|Real-time performance monitoring and management system|

---

US9581723B2|2008-04-10|2017-02-28|Schlumberger Technology Corporation|Method for characterizing a geological formation traversed by a borehole|

---

US8725477B2|2008-04-10|2014-05-13|Schlumberger Technology Corporation|Method to generate numerical pseudocores using borehole images, digital rock samples, and multi-point statistics|

---

US7778738B2|2009-02-11|2010-08-17|Accenture Global Services Gmbh|Method and system for reducing feeder circuit loss using demand response|

---

US8255191B1|2009-04-30|2012-08-28|Cadence Design Systems, Inc.|Using real value models in simulation of analog and mixed-signal systems|

---

US8924033B2|2010-05-12|2014-12-30|Alstom Grid Inc.|Generalized grid security framework|

---

AU2011239306B2|2010-10-26|2013-05-30|Accenture Global Services Limited|Digital analytics system|

---

JP5195951B2|2011-02-23|2013-05-15|横河電機株式会社|Information management apparatus and information management system|

---

US20120229294A1|2011-03-11|2012-09-13|General Electric Company|System and method for communicating device specific data over an advanced metering infrastructurenetwork|

---

US20120310559A1|2011-05-31|2012-12-06|Cisco Technology, Inc.|Distributed data collection for utility grids|

---

US20120316688A1|2011-06-08|2012-12-13|Alstom Grid|Coordinating energy management systems and intelligent electrical distribution grid control systems|

---

US8965590B2|2011-06-08|2015-02-24|Alstom Grid Inc.|Intelligent electrical distribution grid control system data|

---

US9281689B2|2011-06-08|2016-03-08|General Electric Technology Gmbh|Load phase balancing at multiple tiers of a multi-tier hierarchical intelligent power distribution grid|

---

US9641026B2|2011-06-08|2017-05-02|Alstom Technology Ltd.|Enhanced communication infrastructure for hierarchical intelligent power distribution grid|

---

HU230974B1|2011-09-06|2019-07-29|General Electric Company|Monitoring system and method|

---

US8660868B2|2011-09-22|2014-02-25|Sap Ag|Energy benchmarking analytics|

---

WO2013089782A2|2011-12-16|2013-06-20|Schneider Electric USA, Inc.|Co-location electrical architecture|

---

US9979202B2|2012-01-17|2018-05-22|Ecamion Inc.|Control, protection and power management system for an energy storage system|

---

US9164663B1|2012-02-09|2015-10-20|Clement A. Berard|Monitoring and reporting system for an electric power distribution and/or collection system|

---

JP6408382B2|2012-02-13|2018-10-17|アクセンチュア グローバル サービスィズ リミテッド|Electric vehicle decentralized intelligence|

---

US9024780B2|2012-05-04|2015-05-05|Itron, Inc.|Limited data messaging with standards compliance|

---

WO2013182915A2|2012-06-04|2013-12-12|Intelligent Software Solutions, Inc.|Temporal predictive analytics|

---

GB2503056A|2012-06-15|2013-12-18|Aquamw Llp|Technical platform|

---

CN102737325A|2012-06-19|2012-10-17|南京师范大学|Cigarette anti-counterfeiting system based on electronic tags|

---

CN103679306A|2012-08-31|2014-03-26|国际商业机器公司|Method and system for saving building energy consumption|

---

CN102842962A|2012-09-24|2012-12-26|上海罗盘信息科技有限公司|Power energy information management system|

---

CN106227846A|2012-10-22|2016-12-14|国网山东省电力公司青岛供电公司|Electric network information methods of exhibiting real-time and device|

---

US9342558B2|2013-01-31|2016-05-17|Red Hat, Inc.|Systems, methods, and computer program products for selecting a machine to process a client request|

---

US10354212B2|2013-02-07|2019-07-16|Software Ag|Techniques for business process driven service oriented architecturegovernance|

---

CN103218753B|2013-04-11|2016-05-18|国家电网公司|A kind of modeling method of extra-high voltage grid information model and information interacting method|

---

US9524592B2|2013-06-03|2016-12-20|Honda Motor Co., Ltd.|Driving analytics|

---

CN103336498A|2013-06-14|2013-10-02|四川优美信息技术有限公司|Monitoring center for environment cluster|

---

CA2985104A1|2016-11-20|2018-05-20|Dresser, Inc.|Modular metering system|

---

US9058234B2|2013-06-28|2015-06-16|General Electric Company|Synchronization of control applications for a grid network|

---

WO2015016813A1|2013-07-29|2015-02-05|Hewlett-Packard Development Company, L.P.|Metadata extraction, processing, and loading|

---

CN103532739B|2013-09-25|2017-09-29|上海斐讯数据通信技术有限公司|A kind of monitoring analysis system based on network service with application|

---

US9608856B2|2013-11-03|2017-03-28|Teoco Ltd.|System, method, and computer program product for identification and handling of a flood of alarms in a telecommunications system|

---

JP6527511B2|2013-11-12|2019-06-05|エスエムエイ ソーラー テクノロジー アクティエンゲゼルシャフトＳＭＡ Ｓｏｌａｒ Ｔｅｃｈｎｏｌｏｇｙ ＡＧ|Method for communication of a system control unit with a plurality of energy generation systems via a gateway, and a correspondingly configured and programmed data server|

---

US9703309B2|2013-12-27|2017-07-11|Abb Schweiz Ag|Method and apparatus for distributed overriding automatic reclosing of fault interrupting devices|

---

EP2894597A1|2014-01-10|2015-07-15|Alcatel Lucent|A method and device for controlling a power grid|

---

US9791485B2|2014-03-10|2017-10-17|Silver Spring Networks, Inc.|Determining electric grid topology via a zero crossing technique|

---

US9652784B2|2014-04-18|2017-05-16|Level 3 Communications, Llc|Systems and methods for generating network intelligence through real-time analytics|

---

US10691154B1|2014-06-24|2020-06-23|Hrl Laboratories, Llc|Process to reduce the probability of large cascading failures in a transmission network|

---

US20150378795A1|2014-06-27|2015-12-31|Pivotal Software, Inc.|Stream computing event models|

---

WO2016011012A1|2014-07-17|2016-01-21|3M Innovative Properties Company|Systems and methods for coordinating signal injections to understand and maintain orthogonality among signal injections patterns in utility grids|

---

US9614770B2|2014-07-21|2017-04-04|Cisco Technology, Inc.|Network traffic control during limited power situations|

---

US9471060B2|2014-12-09|2016-10-18|General Electric Company|Vehicular traffic guidance and coordination system and method|

---

US9379781B1|2015-03-10|2016-06-28|Lenovo Enterprise SolutionsPte. Ltd.|Server inventory of non-electronic components|

---

US11243505B2|2015-03-16|2022-02-08|Rockwell Automation Technologies, Inc.|Cloud-based analytics for industrial automation|

---

EP3272130A4|2015-03-17|2018-10-17|Sikorsky Aircraft Corporation|Systems and methods for remotely triggered data acquisition|

---

US10176441B2|2015-03-27|2019-01-08|International Business Machines Corporation|Intelligent spatial enterprise analytics|

---

US10205733B1|2015-06-17|2019-02-12|Mission Secure, Inc.|Cyber signal isolator|

---

US10250619B1|2015-06-17|2019-04-02|Mission Secure, Inc.|Overlay cyber security networked system and method|

---

CN104932475A|2015-06-19|2015-09-23|烟台东方威思顿电气股份有限公司|IEC61850-based digital energy metering device remote control method|

---

CN104993591B|2015-07-06|2018-01-12|江苏省电力公司南京供电公司|A kind of distribution system long-distance maintenance method based on IEC61850 standards|

---

JP2017034746A|2015-07-29|2017-02-09|東京電力ホールディングス株式会社|Supervisory control system|

---

JP6604072B2|2015-07-29|2019-11-13|東京電力ホールディングス株式会社|Supervisory control system|

---

KR102046326B1|2015-09-02|2019-11-19|엘에스산전 주식회사|Apparatus for processing of data|

---

CN105119758A|2015-09-14|2015-12-02|中国联合网络通信集团有限公司|Data collection method and collection system|

---

US10140170B2|2015-10-26|2018-11-27|International Business Machines Corporation|Reporting errors to a data storage device|

---

CN108698623B|2016-03-11|2021-05-07|日本制铁株式会社|Derailment detection method and device for railway vehicle|

---

CN105703973B|2016-03-18|2018-12-25|国网天津市电力公司|A kind of power communication fiber optic network reliability consideration method based on composite measure|

---

CN105938345A|2016-06-06|2016-09-14|西安元智系统技术有限责任公司|Control method of universal controller|

---

CN105988407A|2016-06-22|2016-10-05|国网山东省电力公司蓬莱市供电公司|Interactive intelligent electric power service control platform|

---

CN106297291B|2016-08-29|2020-06-26|苏州金螳螂怡和科技有限公司|Urban expressway traffic information acquisition system|

---

US10324459B2|2016-10-11|2019-06-18|International Business Machines Corporation|System, method and computer program product for fault detection and location in power grid|

---

US10855783B2|2017-01-23|2020-12-01|Adobe Inc.|Communication notification trigger modeling preview|

---

CN108092809B|2017-12-12|2020-11-06|南京国电南自电网自动化有限公司|Intelligent substation network switch modeling method and equipment asset model mapping method|

---

US11055308B2|2018-08-31|2021-07-06|Open Text Holdings, Inc.|Systems and methods for integrated dynamic runtime ETL tool and scalable analytics server platform|

---

CN110880938A|2018-09-06|2020-03-13|云丁智能科技（北京）有限公司|Data acquisition method and device|

---

CN110844790A|2019-11-07|2020-02-28|中国海洋大学|Intelligent loading and unloading control system for railway station container|

---

US11186301B1|2021-06-14|2021-11-30|Bnsf Railway Company|System and method for wheel impact load detection compensation|

法律状态:
2019-01-08| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|

---

2019-09-03| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

---

2020-06-30| B06A| Notification to applicant to reply to the report for non-patentability or inadequacy of the application [chapter 6.1 patent gazette]|

---

2020-11-03| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|

---

2021-01-05| B16A| Patent or certificate of addition of invention granted|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 16/03/2011, OBSERVADAS AS CONDICOES LEGAIS. |

优先权:

---

申请号 | 申请日 | 专利标题

---

US31589710P| true| 2010-03-19|2010-03-19|

---

US61/315,897|2010-03-19|

---

US12/830,053|US20110004446A1|2008-12-15|2010-07-02|Intelligent network|

---

US12/830,053|2010-07-02|

---

PCT/US2011/028641|WO2011116074A2|2010-03-19|2011-03-16|Intelligent network|

---