The present invention generally relates to systems and methods for managing power transmission and distribution systems, and more particularly to systems and methods for analyzing power grid data.
The power grid infrastructure includes power lines, transformers and other devices for power generation, power transmission, and power delivery. A power source generates power, which is transmitted along high voltage (HV) power lines for long distances. Typical voltages found on HV transmission lines range from 69 kilovolts (kV) to in excess of 800 kV. The power signals are stepped down to medium voltage (MV) power signals at regional substation transformers. MV power lines carry power signals through neighborhoods and populated areas. Typical voltages found on MV power lines power range from about 1000 V to about 100 (69) kV. The voltages are stepped down further to low voltage (LV) at distribution transformers. LV power lines typically carry power having voltages ranging from about 100 V to about 600 V to customer premises.
In a typical a power grid, operating data is acquired from regional substations, and includes data such voltage and current supplied by the substations. For example, a supervisory control and data acquisition (SCADA) system, or other industrial distributed control system, may be implemented with access points at each regional substation.
The power line voltage and current collected by the SCADA system constitutes operational data. To better manage and control the power transmission and distribution systems it is desirable to obtain non-operational data, such as environmental data (e.g., lightening strikes, temperature, etc.), harmonics fault records, and equipment health data. Little, if any of such non-operational data has been available or processed to provide an actionable or valuable data.
A power line communication system may be implemented to provide communications over the power lines. Accordingly, data now may be acquired from various points within the power grid such as at distribution transformers and at power meters. It is desirable that both operational and non-operational data be acquired and processed. Further, there now is a need for a system and method of analyzing power grid data, and in particular, non-operational power grid data to more effectively manage a power grid (sometime referred to herein as power distribution network). These and other needs may be addressed by one or more embodiments of the present invention.
The present invention provides a system and method for analyzing power grid data. In one embodiment, the system includes a data collection module comprising a plurality of database adaptors configured to retrieve non-operational utility data, a data storage module in communication with said data collection module and comprising a database for storing the non-operational utility data, and an analysis and reporting module in communication with said data storage module and configured to process the non-operational data and to provide a plurality of reports and a plurality of alarms. The analysis and reporting module may comprise an object library comprising a plurality of objects and wherein each object is configured to perform a specific analysis of utility data, an analysis rules module linking one or more objects of the object library and defining an analysis to be performed, an analysis engine configured to execute the analysis rules module, and a report generator configured to produce a report based on an output of the analysis rule module.
The invention will be better understood by reference to the following detailed description taken in conjunction with the accompanying drawings.
The invention is further described in the detailed description that follows, by reference to the noted drawings by way of non-limiting illustrative embodiments of the invention, in which like reference numerals represent similar parts throughout the drawings. As should be understood, however, the invention is not limited to the precise arrangements and instrumentalities shown. In the drawings:
In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular networks, devices, communication systems, computers, terminals, components, techniques, data and network protocols, power line communication systems (PLCSs), power grids, software products and systems, enterprise applications, operating systems, development interfaces, hardware, etc. in order to provide a thorough understanding of the present invention.
However, it will be apparent to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. Detailed descriptions of well-known networks, devices, communication systems, computers, terminals, components, techniques, data and network protocols, software products and systems, operating systems, development interfaces, and hardware are omitted so as not to obscure the description of the present invention.
The present invention comprises a system and method of collecting and processing non-operational data. According to an example embodiment of the present invention, a non-operational data acquisition (NODA) system may be implemented to complement an operational data acquisition system, such as a conventional supervisory control and data acquisition (SCADA) system. Operational data for a utility's power transmission and distribution network generally includes the real time circuit voltages, currents, watts, and VARs collected by the SCADA system or the like at each substation, along with the status of circuit breakers at the various substations. Typically such data is collected every 3-5 seconds by the SCADA system. While operational data typically indicates what is happening, non-operational data is collected for use typically in a non real-time environment and used to provide information as to why something happened and also can be predictive of what may happen. Generally, non-operational data is a measurement or detection of something other than operational data (e.g., other than measurements of parameters of the power used to operate a utility grid on a real-time basis). Non operational data is generally not collected through the SCADA system (although it could be) and is not collected in real time. Examples of non operational data include power line fault records (e.g. waveforms of the fault), equipment health information (e.g., transformer temperature, status of cooling fans, dissolved gas, etc.), power quality data, voltage disturbance data (e.g., voltage transients), harmonics, environmental data (e.g., lightning location and time, temperature, humidity, wind), and other system measurements that typically are not required on a constant basis in real time. Such non-operational data often is obtained by (and stored in) digital fault recorders, protective relay devices, dissolved gas monitors, temperature sensors and other sensing devices. While some non-operational data may result from a measurement of the same parameter as some operational data such as voltage and current, generally the non-operational data will be derived from a much higher sampling rate of that parameter (e.g., to identify harmonics) and/or may comprise a waveform of the parameter (e.g., as opposed to simply a rms value of the voltage or current). Processing the non-operational data can result in outages being restored faster, equipment being operated more efficiently, and decisions being made more accurately with respect to the reparation, upgrade, and/or replacement of power grid infrastructure.
Various non-operational data may be acquired and stored and then processed by one or more software objects. An open human machine interface may be implemented allowing various personnel in various settings to access these software objects according to various permissions and security prerequisites. In particular, various alarm conditions may be detected, and reports generated. The non-operational data may be acquired by various devices at various locations within a power distribution system, and communicated via any suitable manner.
Accordingly, the NODA system may obtain data of complex measurements using various sensing devices located throughout a portion of the power transmission and distribution network 100 controlled or operated by a given power utility company. Example measurements may include, although are not limited to, fault records, apparatus health data, power quality data, harmonics, and environmental data (e.g., lightning, temperature, humidity, wind). Various applications (e.g., analysis and reporting packages) may be executed to store and analyze the collected data. Various reports, graphs, charts, alarms, and task lists also may be generated.
In some embodiments, the network elements of a power line communication system may be used to collect and communicate the non-operational data. A detailed description of examples of power line communication systems 101, including access devices 96 such as bridges, backhaul points, repeaters, along with related devices such power line servers, sensing devices 95, and other components and their functionality are provided in U.S. Pat. No. 7,224,272, issued May 29, 2007, entitled “Power Line Repeater System and Method,” which is hereby incorporated by reference in its entirety. Additional descriptions of such systems, devices, sensors, components and their functionality also is provided in U.S. patent application Ser. No. 11/423,206 filed Jun. 9, 2006, entitled “Power Line Communication Device and Method,” which is hereby incorporated by reference in its entirety.
In one embodiment operational data such as the real time circuit voltages, amperages, watts, and VARs are collected by the SCADA system 102 or the like at each substation, along with the status of circuit breakers at the various substations and the power factor directly derived from the collected data. Typically such data is collected every 3-5 seconds by the SCADA system. The operational data typically is accessed using a given substation's remote terminal unit (RTU). Such RTUs often have direct analog inputs (4-20 mA or 0-10 volts) from circuit potential transformers and current transformers and direct digital inputs from breaker auxiliary contacts. More modern substations may include substation computer gateways that access the voltages, currents, and status digitally from computer relays. The SCADA system 102 typically gets the real time operational data from the RTUs or gateways via a standard protocol, e.g. DNP3. The format of the data may be, for example, a value and a node number.
The NODA system 110 may receive non-operational data 112 of a power transmission and distribution network 100 (such as from a PLCS 101) and store the non-operational data 112 in a non-operational data database 114. The NODA system 110 also may access the operational data database 106 to store and/or retrieve data as needed. To integrate with the SCADA system 102, the NODA system 110 may be deployed as a centralized system either making use of the SCADA HMI 108 or another HMI 116. By working complementary to the SCADA system 102, the NODA system 110 may provide a variety of desirable functions not performed by the SCADA system 102. For example, unlike the SCADA system 102 that just passes the collected data through (without significant processing), the NODA system 110 may continually process collected information, automatically diagnose a broad collection of transmission and distribution issues, and generate alarms based on user configurable conditions. The NODA system 110 also may provide action-oriented, “value event” reports. A value event may be a time and/or money saving activity or an improvement in reliability that can be performed by the utility that is based on insights revealed from the acquisition and analysis of the non-operational data (e.g., in conjunction with the operational data). The value event reports may be delivered to the appropriate utility engineers via e-mail 118 or the HMI 116. Accordingly, some information may be reported on demand through the SCADA HMI 108 and the NODA HMI 116. For example, a failing transformer may be identified and the analyses automatically integrated with the utility's asset/work management system. Thus, the value event analysis may be automatically “served” to another IT system.
By deploying all or a portion of the NODA system 110 at a substation, several benefits may be realized. One benefit relates to data filtering. Non operational data must be managed, which in some cases includes filtering the data. For example, a fault may result in a number of intelligent electronic devices (IED's) in the substation capturing essentially the same fault data. A local analysis system can determine which data is redundant and only transmit and store the fault data once. The intelligent filtering of data becomes more valuable as the number of IEDs in a substation increases. Another benefit is that analysis and reports may be generated more quickly when the analysis system is local to a substation whose data is being analyzed. Still another benefit relates to data security. All data in the substation, both operational and non operational can be collected and pushed up to a central data server avoiding the need for users to download data using proprietary software using various communication paths. In addition, the NODA system 110 may more readily control substation automation equipment when located at the substation 94.
In some embodiments, the NODA system 110 may be a database-driven system in which key modules, such as data collection and data analysis, are managed or controlled by information in a database. The system database, for example, may include tables with lists of data collection, analysis, and reporting jobs. NODA system components may query the database to obtain the next job to execute, remove the job from the list, then attempt to accomplish the job with a separate process. If the process fails to accomplish the job, the job may be put back on the list. This allows the NODA system modules 132-138 to be installed on multiple computers, resulting in the modules “competing for jobs.” In this way the NODA system 110 may automatically perform load leveling. As monitoring devices are added, new servers can be added to maintain the speed and performance of the system. Such an architecture may allow the NODA system 110 to be self-healing, such that if one server is lost, the other servers in the system handle the load. For systems that communicate via phone lines, a Digiboard system may be employed in which one data collection server can drive up to sixteen modems via serial ports. The result is a load-leveling, self-healing system that scales automatically as the monitoring or analysis needs of the utility change.
Substation measurement devices 92 may comprise intelligent electronic devices (IEDs), substation power monitors, power quality monitors, apparatus condition monitors and sensors, and digital fault recorders may be located at the substation and be the source of collected data. Other sensing device may comprise utility meters at customer premises and sensing devices accessed by network elements of a PLCS 101, which also may be the source of collected data. Data services 98 may comprise weather information, lightening strike data, and other data from various data service organizations, which may be another source of collected data. In cases where a substation data concentrator is present, the data collection module 132 may collect and upload data stored in the concentrator to a central data warehouse, and connect directly to substation devices that hold the more complex data that is not collected by the concentrator.
In an example embodiment, the data collection module 132 is an encapsulated Windows application that may be used from a central computer to poll each device in the NODA system 110. Alternately, it can be installed on a PC at the substation to collect all data in the substation via a serial connection or the substation internal network and then transfer the data to the central office data warehouse.
While substation measurement devices usually allow operational data to be collected using standard industry protocols such as Modbus or DNP3, non-operational data stored in these devices may be communicated via these or other protocols. For example various drivers may be included in the data collection module 132 to collect non-operational data from a broad array of monitoring devices. A given device driver typically may serve four functions. The first function is to connect to a corresponding device using that device's communication and command protocol. The second is to collect raw data. A third function is to validate data and perform basic error checking. A fourth function may be to translate the data into a comma-separated, variable format (CSV) (or other suitable tabular file format) for temporary storage. The temporary file format or “transfer file format” can be published so that third parties can collect non operational data, store that data in the file transfer format and the system would be able to automatically take that data and import it into the non operational data base thereby making the system more open.
The communications and data collection component 140 (see
At a first substation 94a, the data collection module 132 may collect data from measurement devices 92 or sensing devices 95 via TCP, serial, wireless, frame relay, modem or other communication links. The data may be stored in a temporary database 206. Data analysis and reporting may be performed from a central host 210. For example, data from the substation 94a may be accessed by a locally installed analysis and reporting module 136 and pushed to the central host 210. A data import component 198 may pass the data to the analysis and reporting module 136 and/or store the data in a data warehouse 212.
In some embodiments a data concentrator may be used. For example at a substation 94b a data concentrator or RTU 214 may collect data from substation measurement devices 92 and sensing devices 95. Such data may be accessed by the data collection module 132 from the data concentrator or RTU 214 (or directly) and pushed to the data warehouse 212 at the central host 210 by a data compression and encryption module. To maximize the value of the data and especially for correlating data from different data sources, time and data synchronization of system equipment is desirable. GPS or IRIGB (Inter-range Instrumentation Group, standard B) are the examples of synchronization systems that may be used.
The web services data collection component 142 (see
The data exchange component 144 (see
In some embodiments the data exchange component 144 includes a data acquisition “service” that continuously or upon certain conditions acquires data from a utility company's information technology (IT) system. This is usually performed through the IT system's data transfer interface. For example, an Application Program Interface (API) may be included (in the data exchange component 144 of the remote IT system) to enable data communications with third-party IT systems. The API not only provides a stable and supported method for obtaining data but also provides functions that support a limited amount of data analysis, which can save time and expense in integration. Such analysis may include “bucketing” power data in intervals for energy and demand analysis as well as enumerating voltage sags from waveform events. Generally, a database API provides back the data that is in the database. However, many application that want to use the data may have specific requirements such as using energy usage data to prepare bills and correlate with market purchases. These applications generally want energy data “bucketed” such as, for example, in five minute averages rather than just raw energy data that would be arbitrarily collected and time stamped. The benefit here is that the system can “prepare” the data the way application needs to use it, thereby avoiding work at their end and making the system more valuable. In a given embodiment the API may provide more than one hundred functions. An API also may be included which may be used for data access by the analysis and reporting module 136, as well as by third-party applications. Many functions may be COM objects usable by C++ as well as by scripting languages such as ASP and Visual Basic. Other objects may be only available to C++ applications. The data exchange component 144 may allow data to be exported in a variety of formats, such as COMTRADE, PQDIF, a simple comma separated variable format and various other formats.
As depicted in
The distributed database implementation allows the user to set up multiple databases. For example, all databases may be on a local-area network (LAN) or wide-area network (WAN). Therefore, a user may set up a database in each substation, which would be transparent to the HMI. The user may also use multiple database engines. For example, one district's data may be stored in an Microsoft® SQL Server database, while another district's data may be stored using Microsoft® Office Access.
Data may be exported in various formats, such as comma-separated variable format via the data exchange module 144 of the data collection module (DCM). In some embodiments waveform data may be exported in the IEEE defined COMTRADE and PQDIF formats. The system's Application Program Interface (API) (e.g., of the data exchange module 144) may be used to automate export tasks. This gives users and third-parties easy access to the database for robust application development that would be unaffected when the database schema changes.
The database maintenance component 150 provides tool for maintaining the databases 148. Users can back-up the full database as well as archive and trim portions of the database with corresponding restore functions.
As illustrated in
Following are examples of some analysis and reporting modules, although other modules also may be included.
A fault analysis and reporting module 172 automates the fault reporting function and may include ancillary analyses such as lightning fault correlation. The utility will want to know when a fault is due to a lightning strike and if so, they may dispatch a crew to find the damage. The utility can also use the information to determine the effectiveness of its lightening arrestors. Another analysis may include breaker re-strike detection. When a breaker operates, the contacts open extinguishing the arc and associated current flow. However, if the oil in the breaker is contaminated or the contacts are severely pitted a re-arc can occur quickly for a cycle or two. This is a precursor to a complete breaker failure. This system can provide this information to the utility so it can take appropriate action. Another analysis may include the impact of a lightening strike to power quality impact (i.e., compatibly of the delivered power to the needs of the customers load.) Typically voltage fluctuations resulting from a lightening strike may cause sub-cycle high frequency voltage transients that can cause miss firing or under or over rms voltage. The fault analysis and reporting module 172 provides functionality beyond a conventional oscillographic report produced by digital fault recorder software packages by supplying additional analytical computations and diagnoses. An example fault report is shown in
A power quality analysis and reporting module 173 provides intelligent analysis of power quality disturbances along with the impact on the customer and the origin of the disturbance. For example, the power quality analysis and reporting module 173 generates reports of the power quality during a particular disturbance or over a given time period. The most destructive power quality events may be highlighted with pertinent information such as: potential destructive impact on sensitive electronic loads; the direction of the source of the disturbance as upstream or downstream from the monitoring location; the specific source of the disturbance (if known); the equipment it may have (or did) affected; and an industry-accepted solution to the problem. In addition, summary analyses of harmonics, zero-crossing errors, and notches may be presented. For example, some customer loads are synchronized to the zero crossing of the voltage waveform of the delivered power. If the voltage waveform is distorted the waveform can have multiple zero crossings or be time shifted affecting the operation of the phase controlled load. As another example, a phase controlled rectifier may have its power control device (thyristors, power transistors, etc) “turn on” or conduct at the 60 degree point on the voltage wave. If a large notch occurs the thyristor may not turn on or not supply enough energy to power the load. In an example embodiment, the report is generated as a PDF or RTF file, and e-mailed automatically and/or made available via the Web HMI 158 or console HMI 160.
An energy cost analysis and billing module 174 includes a rate interface for the analysis and billing of power distributed to member utilities or to power customers. In one embodiment, a web interface is provided to allow power customers to view up-to-the-minute (real time) energy usage and costs. In addition, the energy cost analysis and billing report package 174 may generate a bill for a specific customer.
A waveform analysis, graphing, and reporting module 176 is a comprehensive set of tools for diagnosing more complex transmission and distribution network problems and performance, and for reducing costs. In some embodiments the report content, the format, and the delivery can be configured to allow utilities to customize the analysis and reporting modules to meet the specific needs of the distribution network. This module allows the user to process large amounts of waveforms (e.g., hundreds or thousands) looking for events of interest. The module includes automated waveform functions build into the other modules such as the power quality module. The collection of functions process the waveforms into its harmonics, impedance, phasors, sag frequency, CBEMA/ITIC, and harmonic frequency distribution by a click of the mouse. This functionality is largely independent of the structure of the waveform data.
The waveform analysis, graphing, and reporting module 176 may provide two methods for manual data charting and manipulation, both of which may be available via the Web HMI 158 and console HMI 160. One method may be used to create static charts and graphs, while another method may provide a more advanced, interactive method for manual data analysis. The charting and graphing package may be used on data independent of the measuring device, so as to provide charting and graphing for all available power measuring devices available today as well as those that may be introduced in the future. The module 176 also may provide for plotting and charting data that is unrelated to power monitors such as analog data (temperature, wind, and even security (access) information, etc.) and binary information (breaker open/closed).
In an example embodiment a user may select from various static charts and graphs. For basic charts the user selects the chart type, monitoring asset, and time range. For comparison charts the user selects the monitoring asset and the time interval of the comparison.
In another embodiment an interactive graphical interface may be included from which to view the archived data in both waveform and tabular form. Multiple waveform events representing a continuous waveform may be appended and displayed as a single, multi-cycle waveform event. For example, a large collection of summary graphs including sag frequency, harmonic distribution, ITIC, CBEMA, and time plots may be included. Users can enlarge these summary charts with a click of the mouse, displaying a detailed event of interest such as a waveform, phasor, harmonic distribution, or other parameter. Extensive calculations may be computed from waveform and analog data in real time as the user surveys data parameters such as W, VA, VARS, THD, V or unbalance, Vrms, Arms, PF, and a single harmonic. Channels from multiple dissimilar devices can be viewed and charted simultaneously in the same window. This flexibility is invaluable when comparing a similar power event recorded by different measurement devices on the circuit.
Data analysis may be performed at various stages of the information path.
Referring again to
The smart object library 162 is a group of software objects (e.g., COM, .NET assemblies, DLLs, etc.) that encapsulate analysis methods and are available to other components of the analysis engine 152. Each object is designed to perform a specific function or analytical procedure. An example of a simple smart object is the computing of power factor from recorded kW and kVAR values, while a more complex smart object is a neural network based capacitor signature analysis of a voltage waveform. Given waveform (oscillography) data collected from devices (nodes on the grid) these, more complex, reusable smart objects, using a combination of SME developed rules-based expert systems and SME developed fuzzy logic systems can analyze the waveform data to detect the following occurrences:
A group of simpler, reusable smart objects, also working on the waveform data can perform complex calculations, branching logic, Boolean tests, and are not based on expert or fuzzy logic systems (unlike those above).
The analysis rules 164 define the analysis to be performed, the smart objects to be used, and the information to be generated (i.e., the output). The rules defines the objects to use and it is the analysis engine that processes the rules. So the objects get the data and include the embedded algorithms. The engine processes the objects in the order of the analysis rules code and allows the results of one object to pass to another. The engine is then able to use the report and notification systems based upon the results of the overall analyses.
The analysis engine 166 executes the analysis rules 164 (program code), which links the smart objects 162 and outputs a file with the results of the analysis. The rules contain information identifying which smart objects to use (instantiate), which methods (functions) to use in the smart objects, and how to react (branching logic) to the results returned by the methods.
The report generator 168 uses a report engine to produce a finished report based on the results of the analysis. The report engine may comprise an expert system of report templates, an extensive array of database-stored text, and the logic and procedures for creating the report using the results of the analysis and the file and measurement data input to the analysis engine 166. These analysis modules can be used together such as by the power quality reporting module 173 or individually as in the energy delivery analysis module 174.
The alarm module 154 of the analysis and reporting module 136 continuously reviews and analyzes data, when it is notified by the threshold detector, as the data is collected and at other points in time. An alarm may be triggered when the data exceeds user-selected thresholds or satisfies a threshold rule made up of one or more predetermined conditions. The thresholds may be provided by users via the HMI module 138. For example, simple high and low limits may be set on any measurement parameter such as volts, amps, and power. More complex combinations of conditions also may be established. An alarm may be triggered through data exchange, such as when the SCADA system 102 supplies data that indicates a breaker operation.
Once an alarm is triggered, an entry is made in an alarm log, which can be viewed from the Internet and the system administration console (e.g., web HMI 158; Console HMI 160). After an alarm log entry is made, a number of other events may be triggered. For example, a notification (e.g., an e-mail or an alphanumeric page) including the nature of the alarm may be sent to one or more selectable parties. A user-selectable report may be generated and optionally attached to the e-mail. A message may be announced at the Web HMI 158 and/or console HMI 160. An analysis rule program code may be executed.
A technician may execute a specific module to view information, such as a report. In addition, analysis rules may include access to a specific module to generate reports, charts or action lists. For example, for a given measurement device or a collection of devices, a technician may schedule a job, which is a particular report or action. The job can be scheduled or invoked when an alarm or particular condition occurs. Jobs can be simple, such as weekly routing of power quality reports, or can perform advanced calculations such as in response to predetermined or interrelated alarm conditions. System events such as monitor download failures also result in generation of an alarm and report.
The HMI module 138 may include a browser based human machine interface (HMI) 158, and an administrative console HMI 160. The browser based HMI 158 may access a web server that provides full functional access to remote users via the Internet and/or a company's intranet. In an example embodiment the browser based HMI 158 (accessible via the Internet) gives users a graphical view of the state of the system, indications on whether any alarms have occurred, full access to reports, and an unprecedented level of data analysis and manipulation through data presentation, computation, and graphing tools. The Web server may use the internet information services tools or other web support tools and generally complies with utility IT department security concerns. Users may access the system with a username and password provided by the system administrator. For example, when logging in through Windows Internet Explorer, the user may see monitors and assets complying with permissions granted by the system administrator. In addition, each user may be assigned a profile by the administrator that will define the type and combination of charts and reports the user may access or be presented automatically. In some embodiments the browser based HMI 158 provides substantially the same interactive experience as with the administrative console HMI 160, in which a user may view a tree and a site layout to select reports or other system actions.
The console (administrative) HMI 160 provides an interactive environment for a user to access all administrative functions including setup and maintenance. The console HMI 160 may be an application installed on only one PC (per substation) on a system's local area network. From the console the following functions can be performed: set up and maintain system databases; add or change graphical HMI layouts; add, delete, or edit monitors or equipment and their properties including download intervals; add, delete, or edit alarms and automated reports; add, delete, or edit rate schedules; add, delete, or edit local or Web users and assign names, passwords, and viewing levels; acknowledge or delete alarms; and view reports and data via report packages.
At step 302, data collected via various measurement devices 92 and sensing devices 96 and/or from third party services is received, (see for example the data collection configurations shown in
At step 306, collected data may be processed to detect an alarm condition. For example, during the collection process, various processing may be performed on the data to detect one or more specific alarm conditions. In an example embodiment, a local copy of an analysis and reporting module 136 at a substation 94a, 94b may perform such alarm detection. When an alarm condition is detected at step 306, an alarm may be generated at step 310. In various embodiments one or more of the following may be performed to output the alarm: the alarm may be logged for inclusion in a report or message; a message may be sent to appropriate personnel; a report automatically may be generated.
At step 312 stored data may be periodically processed to detect an alarm condition from among a second set of alarm conditions. For example, processing may be performed for one or more specific alarm conditions which may be different, the same or overlap the alarm conditions for which data is processed during data collection. In an example embodiment the analysis and reporting module 136 residing on a computer (e.g., data collection and analysis server 109; client computer 117, 119; administrative console 115 (see
At step 316, a user may generate an analysis request, such as by running an analysis module from among the modules 172-176. Various analysis steps may then be performed at step 318 according to the analysis requested. At step 320 an output report may be generated responsive to the analysis request. For example, a report from among those as shown in
During the analysis performed at step 318 in response to a specific request, various data may be processed performed to detect any of various alarm conditions. The alarm conditions being tested may be defined according to the specific analysis request. Thus, data may be processed to detect different alarm conditions for different analysis requests. When an alarm condition is detected during the analysis at step 318, an alarm may be generated at step 322. In various embodiments one or more of the following may be performed to output the alarm: the alarm may be logged for inclusion in a report or message; a message may be sent to appropriate personnel; a report automatically may be generated.
It should be noted that the alarm conditions described herein may be triggered automatically as a result of processing data at any of the stages (such as those described in
It is to be understood that the foregoing illustrative embodiments have been provided merely for the purpose of explanation and are in no way to be construed as limiting of the invention. Words used herein are words of description and illustration, rather than words of limitation. In addition, the advantages and objectives described herein may not be realized by each and every embodiment practicing the present invention. Further, although the invention has been described herein with reference to particular structure, materials and/or embodiments, the invention is not intended to be limited to the particulars disclosed herein. Rather, the invention extends to all functionally equivalent structures, methods and uses, such as are within the scope of the appended claims. Those skilled in the art, having the benefit of the teachings of this specification, may affect numerous modifications thereto and changes may be made without departing from the scope and spirit of the invention.
This application claims the benefit of U.S. Provisional Application No. 61/022,320, filed Jan. 19, 2008, entitled “System and Method for Analyzing Power Line Data,” which is incorporated herein by reference in its entirety for all purposes.
Number | Date | Country | |
---|---|---|---|
61022320 | Jan 2008 | US |