Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
UTILITY NETWORK MONITORING WITH A DEVICE AND AN UNMANNED AIRCRAFT
Document Type and Number:
WIPO Patent Application WO/2019/075435
Kind Code:
A1
Abstract:
A device (12) for monitoring a component of a utility network (302) configured to access characteristic data (316) associated with the component and a geographical region where the component is located such that a portion of the characteristic data is accumulated by an unmanned aircraft (100), generate an operation model for the component, access sensor data for the component such that a portion of the sensor data is accumulated by the unmanned aircraft, compare the portion of the characteristic data accumulated by the unmanned aircraft with the portion of the sensor data accumulated by the unmanned aircraft, identify changes in a condition of the component, and update the operation model for the component.

Inventors:
NEUENSCHWANDER, Victoria (115 Tabor Road, Mail Stop: 4D3Morris Plains, NJ, 07950, US)
Application Number:
US2018/055753
Publication Date:
April 18, 2019
Filing Date:
October 13, 2018
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
HONEYWELL INTERNATIONAL, INC. (115 Tabor Road, Mail Stop: 4D3Morris Plains, NJ, 07950, US)
International Classes:
G05B23/02; G05D1/10; G06Q50/06; H02G1/02
Domestic Patent References:
WO2016122966A12016-08-04
Foreign References:
US20150131079A12015-05-14
Other References:
ZHOU GUANG ET AL: "Robust real-time UAV based power line detection and tracking", 2016 IEEE INTERNATIONAL CONFERENCE ON IMAGE PROCESSING (ICIP), IEEE, 25 September 2016 (2016-09-25), pages 744 - 748, XP033016579, DOI: 10.1109/ICIP.2016.7532456
None
Attorney, Agent or Firm:
SHUDY, John, G., Jr. (Seager Tufte Wickhem LLP, 100 South Fifth StreetSuite 60, Minneapolis MN, 55402, US)
Download PDF:
Claims:
What is claimed is:

1. A device for monitoring a component of a utility network, the device configured to:

access characteristic data associated with the component and a geographical region where the component is located, wherein a portion of the characteristic data is accumulated by an unmanned aircraft;

generate an operation model for the component based on the characteristic data;

access sensor data for the component, wherein a portion of the sensor data is accumulated by the unmanned aircraft;

compare the portion of the characteristic data accumulated by the unmanned aircraft with the portion of the sensor data accumulated by the unmanned aircraft;

identify changes in a condition of the component based on the comparison of the portion of the characteristic data with the portion of the sensor data; and

update the operation model for the component based the identified changes in the condition of the component.

2. The device of claim 1, wherein the operation model indicates a likelihood of failure of the component.

3. The device of claim 1, wherein:

the comparison of the portion of the characteristic data accumulated by the unmanned aircraft with the portion of the sensor data accumulated by the unmanned aircraft provides a time lapse measurement of the changes in the condition of the component; or

the device is further configured to control the unmanned aircraft.

4. The device of claim 1, wherein

the unmanned aircraft is operatively coupled to a camera that is configured to obtain visual images of the component; or the unmanned aircraft is operatively coupled to an infrared (IR) sensor that is configured to obtain heat measurements emitted from the component.

5. The device of claim 1, further configured to:

identify an anomaly associated with the component;

compare the portion of the sensor data accumulated by the unmanned aircraft with characteristic data associated with another component;

identify a cause of the anomaly based on the comparison; and

update the operation model for the component based the identified cause of the anomaly.

6. The device of claim 1, wherein the changes in the condition of the component comprise deterioration of the component and vegetation intruding the component.

7. A system for monitoring a component of a utility network, the system comprising:

an unmanned aircraft configured to accumulate sensor data for the component; and

a device operatively coupled to the unmanned aircraft and configured to: access characteristic data associated with the component and a geographical region where the component is located, wherein the characteristic data includes a portion of characteristic data accumulated by the unmanned aircraft;

generate an operation model for the component based on the characteristic data;

access the sensor data for the component from the unmanned aircraft;

compare the portion of the characteristic data accumulated by the unmanned aircraft with the sensor data;

identify changes in a condition of the component based on the comparison of the portion of the characteristic data with the sensor data; and update the operation model for the component based the identified changes in the condition of the component.

8. The system of claim 7, wherein: the operation model indicates a likelihood of failure of the component; or the comparison of the portion of the characteristic data accumulated by the unmanned aircraft with the sensor data provides a time lapse measurement of the changes in the condition of the component.

9. The system of claim 7, wherein:

the device is further configured to control the unmanned aircraft; or the unmanned aircraft is operatively coupled to a camera that is configured to obtain visual images of the component.

10. The system of claim 7, wherein the unmanned aircraft is operatively coupled to an infrared (IR) sensor that is configured to obtain heat measurements emitted from the component.

1 1. The system of claim 7, the device further configured to:

identify an anomaly associated with the component;

compare the sensor data with characteristic data associated with another

component;

identify a cause of the anomaly based on the comparison; and

update the operation model for the component based the identified cause of the anomaly.

12. A method for monitoring a component of a utility network, the method comprising:

accessing characteristic data associated with the component and a

geographical region where the component is located, wherein a portion of the characteristic data is accumulated by an unmanned aircraft; generating an operation model for the component based on the characteristic data;

accessing sensor data for the component, wherein a portion of the sensor data is accumulated by the unmanned aircraft;

comparing the portion of the characteristic data accumulated by the unmanned aircraft with the portion of the sensor data accumulated by the unmanned aircraft; identifying changes in a condition of the component based on the comparison of the portion of the characteristic data with the portion of the sensor data; and

updating the operation model for the component based the identified changes in the condition of the component.

13. The method of claim 12, wherein:

the operation model indicates a likelihood of failure of the component; or the comparison of the portion of the characteristic data accumulated by the unmanned aircraft with the portion of the sensor data accumulated by the unmanned aircraft provides a time lapse measurement of the changes in the condition of the component.

14. The method of claim 12, further comprising:

identifying an anomaly associated with the component;

comparing the portion of the sensor data accumulated by the unmanned aircraft with characteristic data associated with another component; identifying a cause of the anomaly based on the comparison; and

updating the operation model for the component based the identified cause of the anomaly.

15. The method of claim 12, wherein the changes in the condition of the component comprise deterioration of the component and vegetation intruding component.

Description:
UTILITY NETWORK MONITORING WITH A DEVICE AND AN UNMANNED

AIRCRAFT

This Application claims the benefit of U. S. Provisional Patent Application Serial No. 62/572,370, filed October 13, 2017. U. S. Provisional Patent Application Serial No.

62/572,370, filed October 13, 2017, is hereby incorporated by reference.

TECHNICAL FIELD

The disclosure relates generally to utility networks, and more particularly to using an unmanned aircraft to assist in outage prediction for utility networks.

BACKGROUND

A power outage or power failure may be a short-term or a long-term loss of the electric power to a particular area. There are many causes of power outages in a

utility/electricity network. These causes may include faults at utility premises/power stations, damage to electric transmission lines, substations or other parts of the distribution system, a short circuit, or the overloading of electricity mains. Power outages are particularly critical at sites where the environment and public safety are at risk, such as hospitals, sewage treatment plants, mines, shelters and the like. Other critical systems, such as telecommunications, may also be affected by a power outage. Under certain conditions, a utility network component failing or decreasing in operation can cause disturbances in the network that can lead to a cascading failure of a larger section of the network. This may range from a building, to a block, to an entire city, to an entire electrical grid. Modern utility networks are designed to be resistant to this sort of cascading failure, but it may be unavoidable. What would be desirable is an approach to monitor components of a utility network using an unmanned aircraft that would provide real-time alerts and predictions of where and when a component may be damaged and outages may occur. A technician crew may then be prepared in terms of equipment needs and staging to prevent or lessen the duration of an outage.

SUMMARY

In an example of the disclosure, a device for monitoring a component of a utility network may be configured to access characteristic data associated with the component and a geographical region where the component is located, wherein a portion of the characteristic data is accumulated by an unmanned aircraft, generate an operation model for the component based on the characteristic data, access sensor data for the component, wherein a portion of the sensor data is accumulated by the unmanned aircraft, compare the portion of the characteristic data accumulated by the unmanned aircraft with the portion of the sensor data accumulated by the unmanned aircraft, identify changes in a condition of the component based on the comparison of the portion of the characteristic data with the portion of the sensor data, and update the operation model for the component based the identified changes in the condition of the component.

Alternatively or additionally to the foregoing, the operation model may indicate a likelihood of failure of the component.

Alternatively or additionally to any of the embodiments above, the comparison of the portion of the characteristic data accumulated by the unmanned aircraft with the portion of the sensor data accumulated by the unmanned aircraft may provide a time lapse measurement of the changes in the condition of the component.

Alternatively or additionally to any of the embodiments above, the device may be further configured to control the unmanned aircraft.

Alternatively or additionally to any of the embodiments above, the unmanned aircraft may be operatively coupled to a camera that may be configured to obtain visual images of the component.

Alternatively or additionally to any of the embodiments above, the unmanned aircraft may be operatively coupled to an infrared (IR) sensor that may be configured to obtain heat measurements emitted from the component.

Alternatively or additionally to any of the embodiments above, the device may further configured to identify an anomaly associated with the component, compare the portion of the sensor data accumulated by the unmanned aircraft with characteristic data associated with another component, identify a cause of the anomaly based on the comparison, and update the operation model for the component based on the identified cause of the anomaly.

Alternatively or additionally to any of the embodiments above, the changes in the condition of the component may comprise deterioration of the component and vegetation intruding the component.

In another example of the disclosure, a system for monitoring a component of a utility network may comprise an unmanned aircraft configured to accumulate sensor data for the component and a device operatively coupled to the unmanned aircraft. The device may be configured to access characteristic data associated with the component and a geographical region where the component is located, wherein the characteristic data include a portion of characteristic data accumulated by the unmanned aircraft, generate an operation model for the component based on the characteristic data, access the sensor data for the component from the unmanned aircraft, compare the portion of the characteristic data accumulated by the unmanned aircraft with the sensor data, identify changes in a condition of the component based on the comparison of the portion of the characteristic data with the sensor data, and update the operation model for the component based on the identified changes in the condition of the component.

Alternatively or additionally to any of the embodiments above, the operation model may indicate a likelihood of failure of the component.

Alternatively or additionally to any of the embodiments above, the comparison of the portion of the characteristic data accumulated by the unmanned aircraft with the sensor data may provide a time lapse measurement of the changes in the condition of the component.

Alternatively or additionally to any of the embodiments above, the device may be further configured to control the unmanned aircraft.

Alternatively or additionally to any of the embodiments above, the unmanned aircraft may be operatively coupled to a camera that may be configured to obtain visual images of the component.

Alternatively or additionally to any of the embodiments above, the unmanned aircraft may be operatively coupled to an infrared (IR) sensor that may be configured to obtain heat measurements emitted from the component.

Alternatively or additionally to any of the embodiments above, the device may be further configured to identify an anomaly associated with the component, compare the sensor data with characteristic data associated with another component, identify a cause of the anomaly based on the comparison, and update the operation model for the component based on the identified cause of the anomaly.

In another example of the disclosure, a method for monitoring a component of a utility network may comprise accessing characteristic data associated with the component and a geographical region where the component is located, wherein a portion of the characteristic data is accumulated by an unmanned aircraft, generating an operation model for the component based on the characteristic data, accessing sensor data for the component, wherein a portion of the sensor data is accumulated by the unmanned aircraft, comparing the portion of the characteristic data accumulated by the unmanned aircraft with the portion of the sensor data accumulated by the unmanned aircraft, identifying changes in a condition of the component based on the comparison of the portion of the characteristic data with the portion of the sensor data, and updating the operation model for the component based on the identified changes in the condition of the component.

Alternatively or additionally to any of the embodiments above, the operation model may indicate a likelihood of failure of the component.

Alternatively or additionally to any of the embodiments above, the comparison of the portion of the characteristic data accumulated by the unmanned aircraft with the portion of the sensor data accumulated by the unmanned aircraft may provide a time lapse measurement of the changes in the condition of the component.

Alternatively or additionally to any of the embodiments above, the method may further comprise identifying an anomaly associated with the component, comparing the portion of the sensor data accumulated by the unmanned aircraft with characteristic data associated with another component, identifying a cause of the anomaly based on the comparison, and updating the operation model for the component based the identified cause of the anomaly.

Alternatively or additionally to any of the embodiments above, the changes in the condition of the component may comprise deterioration of the component and vegetation intruding the component.

The above summary of some illustrative embodiments is not intended to describe each disclosed embodiment or every implementation of the present disclosure. The Figures and Description which follow more particularly exemplify these and other illustrative embodiments.

BRIEF DESCRIPTION OF THE FIGURES

The disclosure may be more completely understood in consideration of the following description in connection with the accompanying drawings, in which:

Figure 1A is a schematic of a cloud computing node;

Figure IB is a block diagram of an example of an unmanned aircraft;

Figure 2 is an illustrative cloud computing environment;

Figure 3 is an illustrative system for monitoring a component of a utility network; Figure 4A is an example of a OMS Dashboard components screen;

Figure 4B is an example of a OMS Dashboard investigations screen; and

Figure 5 is an illustrative method.

While the disclosure is amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described. It should be understood, however, that the intention is not to limit the disclosure to the particular embodiments described. On the contrary, the intention is to cover all

modifications, equivalents, and alternatives falling within the spirit and scope of the disclosure.

DESCRIPTION

For the following defined terms, these definitions shall be applied, unless a different definition is given in the claims or elsewhere in this specification.

All numeric values are herein assumed to be modified by the term "about," whether or not explicitly indicated. The term "about" generally refers to a range of numbers that one of skill in the art would consider equivalent to the recited value (i.e., having the same function or result). In many instances, the terms "about" may include numbers that are rounded to the nearest significant figure.

The recitation of numerical ranges by endpoints includes all numbers within that range (e.g. 1 to 5 includes 1 , 1.5, 2, 2.75, 3, 3.80, 4, and 5).

As used in this specification and the appended claims, the singular forms "a", "an", and "the" include plural referents unless the content clearly dictates otherwise. As used in this specification and the appended claims, the term "or" is generally employed in its sense including "and/or" unless the content dictates otherwise.

It is noted that references in the specification to "an embodiment", "some

embodiments", "other embodiments", etc., indicate that the embodiment described may include one or more particular features, structures, and/or characteristics. However, such recitations do not necessarily mean that all embodiments include the particular features, structures, and/or characteristics. Additionally, when particular features, structures, and/or characteristics are described in connection with one embodiment, it should be understood that such features, structures, and/or characteristics may also be used connection with other embodiments whether or not explicitly described unless stated to the contrary.

The following description should be read with reference to the drawings in which similar structures in different drawings are numbered the same. The drawings, which are not necessarily to scale, depict illustrative embodiments and are not intended to limit the scope of the disclosure. Although examples of construction, dimensions, and materials may be illustrated for the various elements, those skilled in the art may recognize that many of the examples provided have suitable alternatives that may be utilized.

The current disclosure relates to devices, controllers, systems, computer programs, and methods adapted for monitoring components of a utility network. In some cases, "character" data (e.g., geological map data, property tax data, weather data, sensor data, image data, etc.) associated with the components and/or the geographical region where the components are located may be accessed such that portions of the characteristic data are accumulated by an unmanned aircraft. In some instances, the character data may be used to generate operation models for the components. In some cases, the operation models may be component fault or failure predictors that may be capable of forecasting deterioration or constraints of the components over time and predict their operating and structural conditions/limitations that, when satisfied by physical strains/force, may cause the components to fail. Additionally, sensor data may be accessed such that portions of the sensor data may be accumulated by the unmanned aircraft. The portions of the characteristic data accumulated by the unmanned aircraft may be compared with the portions of the sensor data accumulated by the unmanned aircraft and used to identify any changes in the conditions of the components. In some examples, the operation models for the components may then be updated based on the changes in the conditions of the components.

It is understood in advance that although this disclosure includes a description on cloud computing, implementation of the teachings recited herein are not limited to a cloud computing environment. Rather, embodiments of the present system are capable of being implemented in conjunction with any other type of device or computing environment now known or later developed. Cloud computing may be a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service. Moreover, a cloud computing environment may be service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing may be an infrastructure comprising a network of interconnected nodes.

Figure 1A depicts a schematic of an example of a cloud computing node 10. The cloud computing node 10 is only one example of a suitable cloud computing node and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the system described herein. Regardless, the cloud computing node 10 may be capable of being implemented and/or performing any of the functionality set forth herein.

In the cloud computing node 10, there may be a device 12 for monitoring a component of a utility network. In some cases, the device 12 may be a computer system/server that may be operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the device 12 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, and the like.

The device 12 may be described in the general context of computer system executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on, that perform particular tasks or implement particular abstract data types. The device 12 may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

As shown in Figure 1A, the device 12 in cloud computing node 10 is shown in the form of a general -purpose computing device. The components of the device 12 may include, but are not limited to, one or more processors or processing units 16, a system memory 28, and a bus 18 that couples various system components including system memory 28 to the processor 16.

The bus 18 may represent one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures may include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

In some instances, the processing unit 16 may include a pre-programmed chip, such as a very-large-scale integration (VLSI) chip and/or an application specific integrated circuit (ASIC). In such embodiments, the chip may be pre-programmed with control logic in order to control the operation of the device 12. In some cases, the pre-programmed chip may implement a state machine that performs the desired functions. By using a pre-programmed chip, the processing unit 16 may use less power than other programmable circuits (e.g., general purpose programmable microprocessors) while still being able to maintain basic functionality. In other instances, the processing unit 16 may include a programmable microprocessor. Such a programmable microprocessor may allow a user to modify the control logic of the device 12 even after it is installed in the field (e.g., firmware update), which may allow for greater flexibility of the device 12 in the field over using a preprogrammed ASIC.

The device 12 may include a variety of computer system readable media. Such media may be any available media that are accessible by the device 12, and may include both volatile and non-volatile media, removable and non-removable media.

The device memory 28 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and/or cache memory 32. The device 12 may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, storage system 34 can be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a "hard drive"). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM, EPROM, flash memory (e.g., NAND flash memory), an external SPI flash memory or other optical media can be provided. In such instances, each can be connected to the bus 18 by one or more data media interfaces. As will be further depicted and described below, memory 28 may include at least one program product having a set (e.g., at least one) of program modules (e.g., software) that are configured to carry out the functions of embodiments of the system.

Program/utility 40, having a set (e.g., at least one) of program modules 42, may be stored in memory 28 by way of example, and not limitation, as well as an operating system, one or more application programs (e.g., an Outage Management System Application (OMS) 44, a Computer Information System (CIS) Application 46, a Geographic Information System Application (GIS) 48, a Supervisory Control and Data Acquisition Application (SCAD A) 60, a WOMS Application 62, a Home Electronic System Application (HES) 64, and an Meter Data Management Application (MDM) 66, etc.), other program modules, and program data. Each of the operating systems, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules 42 generally carry out the functions and/or methodologies of embodiments of the system as described herein. In some cases, the program modules 42 and/or the application programs (e.g., the OMS 44, the CIS 46, the GIS 48, the SCADA 60, the WOMS 62, the HES 64, and the MDM 66) may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages.

The device 12 may also communicate with one or more external devices 24 such as a keyboard, a pointing device, a display, etc.; one or more devices that enable a user to interact with the device 12; and/or any devices (e.g., network card, modem, etc.) that enable the device 12 to communicate with one or more other remote device(s) 14 such as, for example, an unmanned aircraft, a field device, a smart phone, tablet computer, laptop computer, personal computer, PDA, and/or the like. Such communication with the external device 24 can occur via Input/Output (I/O) interfaces 22. Still yet, the device 12 can communicate with the external devices 24 and/or the remote devices 14 over one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter 20. As depicted, the I/O interfaces 22 and the network adapter 20 may communicate with the other components of the device 12 via bus 18. In some cases, the remote devices 14 may provide a primary and/or a secondary user interface for the user to interact with the device 12. In some cases, the device 12 may utilize a wireless protocol to communicate with the remote devices 14 over the network.

As stated above, in some cases, the remote device(s) 14 may be an unmanned aircraft (shown in Figure IB). In some examples, the processing unit 16 may control the unmanned aircraft by using input commands to the unmanned aircraft. A command may be an instruction, order, or directive to the unmanned aircraft and may include a high-level goal (e.g., flying to a particular location/component, capturing video of a particular component) or one or more low-level instructions (e.g., increasing a speed of a rotor, rotating a rotor, initiating capture with a camera on the unmanned aircraft). The commands may be encoded in analog signals or digital signals transmitted to the unmanned aircraft. The device 12 may include software, such as the OMS 44 for example, and/or hardware for controlling the movement of the unmanned aircraft as well as the function of additional devices mounted on the unmanned aircraft. For example, the OMS 44 may provide instructions to the processing unit 16 to control the height and geographic position of the unmanned aircraft as well as lights, a camera, and speakers mounted thereon. In some cases, the OMS 44 may display an unmanned aircraft control interface on the external device(s) 24 or the remote device(s) 14. In some cases, the unmanned aircraft control interface may be integrated with an OMS Dashboard.

In some instances, the OMS 44 and the MDM 66 may execute entirely on the device 12, as a stand-alone software package, and/or partly on the device 12 and partly on the remote devices 14. For example, the OMS 44 may provide instructions to the processing unit 16 to access characteristic data. In some examples, the characteristic data may also be stored locally on the device 12, partially on the device 12 and partially on an external computing architecture/environment, or fully on an external computing architecture/environment (e.g., a remote server). In some cases, the characteristic data may be associated with a component of a utility network and a geographical region where the component is located. For instance, the characteristic data may refer to information produced as result of environmental conditions, such as, real-time and historical weather conditions, landscape conditions, vegetation conditions, etc. Additionally, the characteristic data may also refer to information produced as a result of actions on the component that may deteriorate its condition. For example, the component may be a distribution line. As such, the characteristic data may refer to the motion or movement of the distribution line. In another example, the characteristic data may refer to the electricity that runs through the distribution line. In yet further examples, the characteristic data may be a combination of environmental conditions and actions on the component. That is, the environmental conditions may affect and/or alter how the component experiences the actions. For instance, elevated wind gusts may occur near the distribution line. However, the distribution line may be at the bottom of a hill so the distribution line may not experience the elevated wind gusts and therefore, may not experience elevated motion or movement. In some cases, the characteristic data may track these environmental conditions and actions and be recorded, and the characteristic data may then be accessed using a range of devices connected to a network (e.g., the Internet), such as the device 12, a PC, tablet, or smartphone, for example.

In some cases, the characteristic data may permit the OMS 44/device 12 to identify which characteristic data is pertinent for the component and group the data accordingly. For example, the OMS 44 may take distinct characteristic data for the component, grouped according to their separate datasets (e.g., characteristic data originating from meter devices, segmentation based characteristic data, characteristic data originating from eCommerce platforms, characteristic data originating from web applications, characteristic data originating from weather platforms, etc.), and generate a set of models from the grouped data. The OMS 44 may then provide instructions to the processing unit 16 to combine the set of models to create and generate an operation model for the component, in some cases, because the set of models was configured from environmental conditions and actions that the component has been subjected to or will likely be subjected to, the combination of the set of models in the operation model may be a forecaster of the likelihood that the component is fail/stop or decrease in operation. For instance, the component of the utility may be a transmission line. Based on the characteristic data, when the transmission line experiences a sway .00005 m/s 2 , the operation of the transmission line is likely to stop or decrease in operation. As such, the transmission line may have an acceptable line sway range of 0 to .00005 m/s 2 . Moreover, the characteristic data may also indicate that when the transmission line is subject to wind gusts of 35 mph, the transmission line may sway at its maximum acceptable line sway (i.e., a structural condition) of .00005 m/s 2 . Accordingly, the OMS 44 may provide instructions to the processing unit 16 to generate an operation model for the transmission line that indicates that when the transmission line is subject to wind gusts of 35 mph (i.e., an operating condition) and/or the transmission line sways at least .00005 m/s 2 , there is a likelihood that the transmission line may stop or decrease in operation (i.e., the transmission line may fail) and power outages may be likely to occur as a result. As such, when both or either corresponding operating and structural condition is satisfied, the OMS 44 may provide instructions to the processing unit 16 to send a notification to a

technician/employee of the utility network that the transmission line may be the cause of the power outages and proper action may then be taken to either prevent the transmission line from causing the power outage or repair the power outage (e.g., repair the transmission line).

In some examples, the MDM 66 may also provide instructions to the processing unit 16 to access sensor data for the component of the utility network. In some examples, the sensor data may also be stored locally on the device 12, partially on the device 12 and partially on an external computing architecture/environment, or fully on an external computing architecture/environment (e.g., a remote server). In some cases, the sensor data may indicate the current physical strain on the component. In some examples, the physical strain may cause the component to deteriorate, damage, break, and/or change its current condition such that the component may be weakened and cannot operate at its former (pre- deteriorated) capacity. In other examples, the physical strain may not affect the component and/or the component may continue to operate. For instance, continuing with the example of the transmission line, in some cases the transmission line may be operatively coupled to a sensor, such as for example, an accelerometer that may be used to sense/detect the motion/force on the transmission line due to the current weather conditions (e.g., wind, storms, etc.). As stated above, the transmission line has an operation model that indicates that when the transmission line is subject to wind gusts of 35 mph and/or the transmission line sways at least .00005 m/s 2 , there is a likelihood that the transmission line may stop or decrease in operation (i.e., the transmission line may fail). In this example, a wind gust of 45 mph is detected and the accelerometer senses that the transmission line sways .00006 m/s 2 . When the processing unit 16 receives this data from the accelerometer (i.e., the processor 16 identifies that the corresponding operating and structural conditions of the operation model for the transmission line are met by the physical strain of the wind), the OMS 44 may provide instructions to the processing unit 16 to send a notification to the technician. However, in this case, the technician may observe that the transmission line did not stop/fail or decrease in operation and no power outages occurred. The technician may then send a report to the device 12 that upon experiencing 45 mph wind gusts and a .00006 m/s 2 line sway, the operation of the transmission line did not decrease or stop and no power outages occurred. In some instances, the OMS 44 may provide instructions to the processing unit 16 to use the report to update the operation model for the transmission line. In other words, the report may provide data that helps purge, standardize, tag, categorize, and summarize the characteristic data properly so that the characteristic data may be used to generate operation models that more accurately predict whether there is a likelihood that a component is going to stop or decrease in operation. Accordingly, in some cases, the device 12 may produce reliable, repeatable descriptive results and predictions and uncover "hidden insights" through historical relationships and trends in the characteristic data. As such, in some examples, the device 12 may be configured to "learn" (e.g., progressively improve the failure prediction of the operation models) from the reports and/or feedback, without being explicitly

programmed. For instance, the device 12 may automatically update the operation model to indicate that the new acceptable line sway range of the transmission line is 0 to .00006 m/s 2 . Accordingly, when the transmission line is subject to wind gusts of 45 mph and/or the transmission line sways at least .00006 m/s 2 , there is a likelihood that the transmission line may stop or decrease in operation (i.e., the transmission line may fail).

It should be understood that although not shown, other hardware and/or software components could be used in conjunction with the device 12. Examples include, but are not limited to microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

Figure IB is a block diagram of an example of an unmanned aircraft 100. The unmanned aircraft 100 may include a receiver 102, a controller 104, an image sensor 106 (e.g., a camera, an IR sensor, a thermal imaging sensor, etc.), and a transmitter 108. The unmanned aircraft may also include standard components of a flying vehicle. For example, the unmanned aircraft 100 may include rotors and motors for providing torque to rotate the rotors, and shafts to convey the torque from the motors to the rotors. Using the rotors, the unmanned aircraft 100 may accelerate air to propel itself through the air both vertically and horizontally. The unmanned aircraft 100 may also include an electrical power source (e.g., a battery, solar panels) or a chemical power source (e.g., a fuel cell, a fuel tank and electrical generator engine) to power the motors, rotors, and other components. The unmanned aircraft 100 may also include structures to prevent damage to the unmanned aircraft 100 upon landing (e.g., skids, wheels) or to prevent the rotors from colliding with another object.

The receiver 102 may be used to allow communication (e.g., wireless communication) with the device 12 or any other computer system/server or cloud computing environment. In some instances, the receiver 102 may receive commands from the device 12 or the remote device(s) 14. The receiver 102 may be an antenna and accompanying electronic circuitry (e.g., an analog-to-digital converter, an amplifier, a noise-attenuating filter) to detect signals transmitted through electromagnetic signals (e.g., radio, WiFi, LTE).

The controller 104 may provide digital or analog control of the unmanned aircraft 100. The controller 104 may receive commands through the receiver 102 and direct the unmanned aircraft 100 to adjust its position or orientation subject to the commands or capture image/sensor data subject to the commands. In some cases, the controller 104 may be a computing device, and may optionally include a memory for storing media captured by the image sensor 106 or received through the receiver 102. The controller 104 may monitor the status of the unmanned aircraft 100, the image sensor 106, or itself and transmit status reports through the transmitter 108. The controller 104 may include one or more sensors to measure the unmanned aircraft's 100 position, speed, and/or orientation, such as one or more global positioning system receivers, inertial measurement units, gyroscopes, magnetometers, pitot probes, or accelerometers.

In some cases, the controller 104 may be a computing system that executes applications (e.g., the OMS 44, the MDM 66). The controller 104 may download (or otherwise obtain), install, and execute applications. For example, the controller 104 may install an application to broadcast a video stream from the image sensor 106 to other computing devices executing the application. The video stream may also be broadcast through interactive messages. The controller 104 may execute multiple applications to interface with multiple types of applications on other computing devices. Applications on the controller 104 may be downloaded, installed, removed, or updated in response to remote commands (e.g., from the device 12 or other computing device associated with the device 12).

The image sensor 106 may capture media from the environment around a utility network. In some cases, the image sensor 106 may be a still and/or video-capable camera that includes an optical lens assembly to focus light and produce an electronic signal in response to light incident on the optical lens to produce visual images of the components. In some cases, the image sensor 106 may be an IR sensor, night vision equipment such as a thermal imaging device, radar, sonar, and others. The image sensor 106 may optionally include a microphone to capture audio or a memory to store captured media. The image sensor 106 may operate in response to commands from the device 12, which may initiate or stop capture of media or may control focusing of an optical lens or image sensor assembly. The image sensor 106 may include one or more mechanical actuators that modify the orientation or position of the image sensor 106 relative to the rest of the unmanned aircraft 100.

The transmitter 108 may be configured to send communications from the unmanned aircraft to the device 12, the remote device(s) 14, or any other computer system/server or cloud computing environment. In some cases, the transmitter sends media/image data captured by the image sensor 106 to the device 12, the remote device(s) 14, or any other computer system/server or cloud computing environment. The transmitter 108 mayhave an antenna and accompanying electronic circuitry (e.g., a digital-to-analog converter, an amplifier, a noise-attenuating filter, a power supply) to transmit data using electromagnetic signals. The transmitter 108 and receiver 102 may optionally be combined as a single component. It should be understood that although not shown, other hardware and/or software components could be used in conjunction with the unmanned aircraft 100.

Figure 2 depicts an illustrative cloud computing environment 50. As shown, cloud computing environment 50 comprises one or more cloud computing nodes 10 with which cloud consumers (e.g., utility companies, technicians, investigators, general public, etc.) may use local computing devices, such as, for example, a personal digital assistant (PDA) or a cellular telephone 52, desktop computer 54, laptop computer 56, and/or a field device 58 may communicate. Nodes 10 may communicate with one another. They may be grouped (not shown) physically or virtually, in one or more networks, such as, for example, Private, Community, Public, or Hybrid clouds, or a combination thereof. This may allow cloud computing environment 50 to offer infrastructure, platforms and/or software (e.g., the NTL Application 44, from Figure 1) as services for which a cloud consumer does not need to maintain resources on a local computing device. It is understood that the types of computing devices 52, 54,56, 58 shown in Fig. 2 are intended to be illustrative only and that computing nodes 10 and cloud computing environment 50 can communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., using a web browser).

Figure 3 depicts an illustrative system 300 for monitoring a component of a utility network 302. As shown in Figure 3, the utility network 302 may include a utility premise 304 (e.g., a power plant/source) that includes the device 12 and distributes energy (e.g., electricity) across power lines 318 of the utility network 302 to a first utility /structure (or energy consuming entity) that has a metering device 306 which monitors and records the amount of a particular energy being consumed by the utility/structure. A second

utility /structure (or energy consuming entity) has a similar metering device 308 associated therewith, and a third utility/structure (or energy consuming entity) likewise has a similar metering device 310 associated therewith. Each of the metering devices 306, 308, 310 maybe operatively coupled to the utility premise 304 so that readings/energy data being taken by the metering devices are transmitted to the device 12 for processing and storage. In some cases, the power lines 318 may include a transformer monitor(s) 312 that monitors and records the amount of a particular energy being distributed to the utilities/structures. The transformer monitor(s) 312 may also be operatively coupled to the utility premise 304 so that

readings/energy data being taken by the transformer monitor(s) 312 may be transmitted to the device 12 for processing and storage. While only three metering devices 306, 308, 310, the power line 318, and one transformer monitor 312 are shown in Figure 3, it should be understood that there can be any number of components included in the utility network 302. Moreover, there may be many different kinds of components present in the utility network including, for example, meters, transformers, distribution lines or poles, transmission towers or lines, substations, transformer stations, etc. Additionally, the utility network 302 may include sensors 350 and 352 operatively coupled to the components and/or operatively coupled to/attached to the unmanned aircraft 100. Accordingly, the sensors (e.g., sensors 350 and 352) may be configured to accumulate sensor data for the components. There may be any number of sensors present in the utility network and many different kinds including, for example, accelerometers, infrared (IR) sensors, temperature sensors, multimeters, pressure sensors, optical/visual sensors, etc., that may be used to accumulate data by sensing/detecting characteristics of the component and/or the area around the component. As such, the sensors may sense the current physical strain on the component, such as for example, the heat emitted by a component when power/electricity is flowing through it, the motion/force on a component due to the current weather conditions (e.g., wind, storms, etc.), the vegetation surrounding the component, the current outdoor temperature that the component is subject to, structural damage of the component, etc.

In some cases, the device 12 may also access characteristic data 316. In some examples, the characteristic data 316 may be stored in a cloud computing environment 314 (e.g., a remote server(s)). In some cases, the characteristic data 316 may be associated with components of the utility network 302 and a geographical region where the component and/or the utility network 302 is located. For instance, as shown in Figure 3, the characteristic data 316 may include Property Tax Data 320 for residence and/or businesses in a particular neighborhood serviced by the utility network 302, Geological Map Data 322 for the particular neighborhood, Real-Time Weather Data 324 for the particular neighborhood, Historical Weather Data 326 for the particular neighborhood, Transformer Monitor Data 328 for transformers belonging to the utility network 302, Line Sensor Data 330 for

power/distribution lines belonging to the utility network 302, and image Data 332 of components belonging to the utility network 302. It is understood that the types of the characteristic data 316 shown in Figure 3 are intended to be illustrative only and that the characteristic data 316 may include more or less data types and can include any type of data relevant to a component of the utility network 302 or neighborhood/geographical region where the component and/or the utility network 302 may be located.

In some cases, the unmanned aircraft 100 may contribute to the accumulation of characteristic data and sensor data and assist the utility premise 304/device 12 in determining whether there is a likelihood a component of the utility network 304 may fail/stop or decrease in operation. In some instances, the unmanned aircraft 100 may be programmed to fly over components and obtain video images, photographic images, IR sensor detections, thermal detections, radar detections, sonar detections, etc., of each component and download the images and detections. In some instances, the unmanned aircraft 100 may repeat flight paths to position cameras/detectors at relatively the same angle as previous flights. The downloaded images may then be sent to the cloud computing environment 314 and/or the device 12 and included with the characteristic data 316 and sensor data. The images and detections may then be analyzed to identify deteriorations, damages, breaks, and/or changes in the condition of the components. In some cases, the device 12 may compare the images and detections with images or detections of proper components. In some examples, since the unmanned aircraft 100 may have repeated flight paths, the device 12 may compare the images and detections with past images or detections of the components in order to identify new or changes in the deteriorations and allow for time lapse measurement of the deteriorations, damages, breaks, and/or changes in the condition of the components. In some cases, based on the comparisons, the device 12 may use OMS analytics, such as for example, regression analytics or statistical methods to evaluate the damages and generate/update operation models that may predict the time when a component may stop/fail or decrease in operation.

In some cases, components such as distribution polls and lines, for example, may have trees and other vegetation too close or growing on the distribution polls and lines and may need to be trimmed. The unmanned aircraft 100 can take photos, videos, and detections of the vegetation intruding the distribution polls and lines and the images/detections may be sent to the cloud computing environment 314 and/or the device 12 for analysis and pinpoint areas that need trimming. The cloud computing environment 314 or the device 12 may analyze the images to identify automatically the areas where the vegetation is intruding the distribution polls and lines. The analysis may highlight the exact location using latitude and longitude and GPS coordinates to identify the area where trimming needs to be done. In this way, trimming crews or technicians/utility premise 304 employees may not waste time trying to locate the distribution polls and lines that have intruding vegetation.

In some cases, the unmanned aircraft 100 may be used to identify components that are damaged or worn out. The unmanned aircraft 100 may fly over a component and take photographs or video of the component. The data for each individual component may be downloaded and sent to the cloud computing environment 314 and/or the device 12 to be analyzed. In some instances, the device 12 may use OMS analytics to generate an operations model for the components to identify when a component is likely to be worn out/non- operable and may need replacement or repair. In some examples, the device 12 may automatically generate a notification to a technician to address the repair that is needed.

In some instances and as previously stated, the unmanned aircraft 100 may be fitted with temperature/heat seeking sensors (e.g, IR sensors) configured to obtain heat

measurements emitted from the components or a camera that has heat emitting imaging capability. In some examples, the heat emitting capability may allow a sensor or camera to focus its field of vision on breaks, cracks, damages, etc. of a component. The breaks, cracks, damages, etc. may then be compared with past data or data from proper components to determine excessive readings so that defective or old components may be identified. Likewise cool air sensors may also be used to identify defective components.

The data collected from these unmanned aircraft 100 collections may be provided to the device 12 to assist in generating operating models for the components.

In some cases, data from the unmanned aircraft 100 can be used to identify anomalies with components that are not operating according to their operating model. The device 12 may control the unmanned aircraft 100 to fly over components and obtain images/detections of the components. The data may then be observed and compared with similarly situated components to identify the cause(s) of the anomalies. In some instances, this may allow the device 12 to produce reliable, repeatable operation models and predictions. As such, in some examples, the device 12 may be configured to progressively improve the likelihood of failure/likelihood of outage predictions of the operation models from the image/detection data provided by the unmanned aircraft 100.

In some instances, a Model Layer 348 may track, validate, cleanse, process, and record the characteristic data 316 to generate models. For example, as shown, the Model Layer 348 may include an Energy Forecasting by Segmentation Module 334, an Energy Forecasting by Site Module 336, a Building Occupancy Prediction Module 338, a Time to Event Prediction Module 340, and an Oscillation Detection Module 342. It is understood that the modules of the Model Layer 348 are intended to be illustrative only and that the Model Layer 348 may include more or less modules and can include any type of relevant module. In some examples, the Energy Forecasting by Segmentation Module 334 may segment or group components that exhibit similar energy characteristics or behaviors, based on a detailed history of energy monitoring, plus information about component locations, demographics, and historical and real-time weather conditions experienced by the components. The Energy Forecasting by Segmentation Module 334 may use pattern recognition or any suitable method to then generate models for the components. In another example, the Energy Forecasting by Site Module 336 may identify the sites where the components are located and segment or group the sites that exhibit similar energy characteristics or behaviors, based on a detailed history of energy monitoring, plus information about site locations, demographics, and historical and real-time weather conditions experienced by the sites. The Energy Forecasting by Site Module 336 may use pattern recognition or any suitable method to then generate models for the components. In another example, the Building Occupancy Prediction Module 338 may use property information, location information, image information, sensor information, etc. to establish room relationships over time to generate occupancy models for the components. In another example, the Time to Event Prediction Module 340 may use state-of-the-art algorithms which use time until a given event as the target variable and generated models for the components. In another example, the Oscillation Detection Module 342 may use property information, location information, image information, sensor information, etc. to generate oscillation/movement/sway models for the components. In another example, the Vegetation Prediction Module 344 may use property information, location information, image information, sensor information, etc., to monitor encroaching vegetation near components, predict growth of vegetation, combine regional agricultural growth models, and identify weather patterns to generate vegetation growth models for the components.

In some cases, the device 12 may use OMS analytics to combine the set of models to create and generate operation models for the components of the utility network 302. For example, by combining the set of graphs using OMS analytics the device 12 may identify that a distribution pole has structural damage, is located in an area with heavy vegetation, and has connectors for distribution lines that frequently experience high current intensity. As such, the device 12 may generate an operation model that indicates, under the current conditions, the distribution pole is likely to stop/fail or decrease in its operational capacity within a given amount time (e.g., 1 month, 2 months, 3 months, 6 months, 1 year, 5 years, etc.). As such, the device 12 may notify and or generate the operation model for a technician/employee of the utility network on a display or the remote device(s) 14 (e.g., a field device, a smart phone, tablet computer, laptop computer, personal computer, PDA, and/or the like) that the distribution pole may fail and cause power outages. The technician may then take proper action to prevent the distribution pole from causing the power outage or repair the distribution pole to stop the power outage.

In some cases, the utility network 302 may also operate according to an MDM system. As such, sensor data sent to the device 12 may comprise the current physical strain on the components of the utility network 302. In some examples, the physical strain may cause a component to deteriorate, damage, break, and/or change its current condition such that the component may be weakened and cannot operate to its former (pre-deteriorated) capacity. In other examples, the physical strain may not affect the component and/or the component may continue to operate. Moreover, in some instances, the operation models for the components may have sets of operating and structural conditions that when met by the physical strain, may indicate a likelihood that the component may stop/fail or decrease in its operational capacity. As such, when device 12 identifies that the physical strain on a component meets or exceeds a corresponding operating or structural condition of the component, the device 12 may identify whether operation of the component is affected by the physical strain. Whether the operation of the component is affected by the physical strain, the device 12 may then update the operation model for the component. For instance, continuing with the example of the distribution pole, in some cases the distribution pole may be operatively coupled to sensors, such as for example, IR sensors, optical sensors, and accelerometers. In some examples, the IR sensors may be used to detect the temperatures of the connectors of the distribution pole due to the high-intensity current, the optical sensors and the IR sensors may be used to detect structural damage of the distribution pole, and the accelerometers may be used to detect the motion/force on the distribution lines connected to the connectors and attached to the distribution pole. Due to the structural damage and the deterioration of the connectors from the high-intensity current, the operation model indicates that a structural condition or the acceptable line sway range of the distribution lines is 0 to .00005 m/s 2 . In some cases, an accelerometer may then detect that a distribution line is being swayed .00006 m/s 2 . When the device 12 receives this data from the accelerometer (i.e., the device 12 identifies that the corresponding condition of the operation model for the distribution poll are met), the device may send a notification to the remote device(s) 14. However, in this case, a technician that observes the notification on the remote device(s) 14 may observe that the distribution poll did not fail and no power outages occurred. The technician may then send a report to the device 12 that upon experiencing a .00006 m/s 2 line sway, the distribution poll did not fail and no power outages occurred. In some instances, the device 12 may use the report to update the operation model for the distribution poll such that the line sway structural condition for the distribution poll is now set at 0 to .00006 m/s 2 .

In another example, the accelerometer may detect that the distribution line is being swayed .00004 m/s 2 and the technician observes that a power outage has occurred due to the failure of the distribution poll. The technician may then send a report to the device 12 that upon experiencing a .00004 m/s 2 line sway, the distribution poll failed and a power outage has occurred. In some instances, the device 12 may use the report to update the operation model for the distribution poll such that the line sway structural condition for the distribution poll is now set at 0 to .00004 m/s 2 . These are just a couple examples of how the device 12 can generate an operation model for a component and are not intended to limit the scope of the disclosure. As such, the device 12 can use any method to generate operation models that indicate when components are likely to stop/fail or decrease in their operational capacity.

In some cases, when the device 12 receives a report (e.g., a report from the technician), the device 12 may be capable of leaming from the report without being explicitly programmed. Instead the device 12 may use the report to build logic based on the data obtained from the report. In conjunction with the characteristic data and cloud computing, described herein, the capability of the device 12 to learn from patterns in the data may improve the device's ability to analyze those big chunks of data from multiple sources. For instance, in some cases, the device 12 may be capable of discovering interesting structures in the characteristic data. In some examples, the device 12 may be capable of discovering rules that describe large portions of the characteristic data. In some instances, the device 12 may improve its ability to discover inherent groupings in the characteristic data. In any scenario, this ability to learn from the report may allow the device 12 to produce reliable, repeatable operation models and predictions and uncover "hidden insights" through historical relationships and trends in the characteristic data. As such, in some examples, the device 12 may be configured to progressively improve the likelihood of failure/likelihood of outage predictions of the operation models from the reports and/or feedback.

In some instances, the device 12 may generate operation models in the form of an OMS Dashboard that gi ves a detailed account and predictions of the likelihood that a component may stop/fail or decrease in operational capacity. Figure 4A depicts an illustrative OMS Dashboard 400 generated by the device 12 on a display, an external device (e.g., external device(s) 24, from Figure 1), or the remote device(s) 14 (e.g, a smart phone, tablet computer, laptop computer, personal computer, PDA, and/or the like). In some cases, the remote device 14 may be a field device used by a technician and/or an employee of the utility premise 304. According to various embodiments, the OMS Dashboard 400 may be an integrated, simple to use dashboard. In some cases, the OMS Dashboard 400 may enable the device 12 to send notifications, alerts, provide confidence scores, geographical maps, charts, notes, investigation summaries, etc. regarding the likelihood that a component may stop/fail or decrease in operational capacity and/or the likelihood of an outage in a utility network. In some instances, the OMS Dashboard 400 may be configured with user accounts that need user passwords to navigate through templates/screens of the OMS Dashboard 400. In some examples, the OMS Dashboard 400 may configure the screens displayed based on the user/user account. For instance, the utility network 302 may span multiple areas or neighborhoods and technicians may be assigned to particular neighborhoods. As such, the OMS Dashboard 400 may limit what is displayed on the screens for a technician, having a user account, to only the neighborhoods that the technician is assigned. This is just an example of how the device 12/OMS Dashboard 400 can selectively configure the screens and is not intended to limit the scope of the disclosure. As such, the device 12/ OMS Dashboard 400 can selectively configure the screens in any manner and as needed.

As shown in Figure 4A, icons may be located on a sidebar 402 of the OMS

Dashboard 400. The icons may include a home icon 404, a reports icon 406, an

investigations icon 408, a components icon 410, a locations icon 412, an administration icon 414, and a logout icon 416, for example. Each icon may be selected to display their corresponding template/screen of the OMS Dashboard. In this example, as shown in Figure 4A, the components icon 410 has been selected to display a components screen 418 showing a likelihood that the distribution poll may stop/fail or decrease in operational capacity. In some cases, the components screen 418 may provide confidence scores of whether there is a likelihood that the distribution poll may stop/fail or decrease in operational capacity. For example, as shown, the confidence score may be shown using a chart(s) 420, 422, and 424 that include a score or percentage of the likelihood that the distribution poll may fail at a given line sway and experiencing a given wind gust speed. For instance, as shown by chart 420, when a distribution line of the distribution poll has a line sway of .00004 m/s 2 and there is a 25 mph wind gust, the distribution poll has a likelihood of failure of 50% and a likelihood of non-failure of 50%. As shown by chart 422, when a distribution line of the distribution poll has a line sway of .00005 m/s 2 and there is a 35 mph wind gust, the distribution poll has a likelihood of failure of 66% and a likelihood of non-failure of 34%. As shown by chart 424, when a distribution line of the distribution poll has a line sway of .00006 m/s 2 and there is a 45 mph wind gust, the distribution poll has a likelihood of failure of 90% and a likelihood of non-failure of 10%. It should be understood that such features of the components screen 418 are intended to be illustrative only and the components screen 418 may be configured in any manner and include any number of depictions of the confidence scores such as icons, bar graphs, scatter plots, thumbnails, etc. Moreover, the components screen 418 may also include any number of features, such as icons, sidebars, scroll bars, etc.

Turning to Figure 4B, in this example, the device 12 may generate an investigations screen 426 from the OMS Dashboard 400 when the investigations icon 408 (shown in Figure 4A) is selected. In some cases, the investigations screen 426 may allow a user/technician to input and record/send a report of whether the distribution poll failed and/or caused an outage. Moreover, the user may also input a detailed description of the evidence found at or near the distribution poll, actions taken, and general notes about the distribution poll and/or the area around the distribution poll. It should be understood that such features of the investigations screen 426 are intended to be illustrative only and the investigations screen 426 may be configured in any manner that allows a user to provide a report of whether a component failed and/or caused an outage. Moreover, the investigations screen 426 may also include any number of features, such as icons, sidebars, scroll bars, graphs, thumbnails, etc.

It is understood that this is just an example of the OMS Dashboard 400. There may be many different configurations of the OMS Dashboard 400 and there may be many other ways that the device 12 may send notifications or alerts regarding the likelihood that a component may stop/fail or decrease in operational capacity and/or the likelihood of an outage in a utility network. As such, the illustrative embodiments are not intended to limit the scope of the disclosure.

Figure 5 depicts an illustrative method 500 for monitoring a component of a utility network. The method 500 begins at step 502, where characteristic data associated with the component and a geographical region where the component is located is accessed such that a portion of the characteristic data is accumulated by an unmanned aircraft. In some examples, the components may include, meters, transformers, distribution lines or poles, transmission towers or lines, substations, transformer stations, etc. In some examples, the characteristic data may include Property Tax Data for residence and/or businesses in a particular neighborhood serviced by the utility network, Geological Map Data for the particular neighborhood, Real-Time Weather Data for the particular neighborhood, Historical Weather Data for the particular neighborhood, Transformer Monitor Data for transformers belonging to the utility network, Line Sensor Data for power/distribution lines belonging to the utility network, and image Data of component belonging to the utility network. At step 504, an operation model is generated from the characteristic data for the component. In some examples, OMS analytics may be used to combine a set of models generated from the characteristic data to create and generate the operation model for the component. At step 506, sensor data for the component is accessed such that a portion of the sensor data is accumulated by the unmanned aircraft. In some examples, the sensor data may be accessed from any number of sensors present in the utility network and many different kinds including, for example, accelerometers, IR sensors, temperature sensors, multimeters, pressure sensors, optical/visual sensors, etc., that may be used to sense/detect/accumulate characteristics of the component and/or the area around the component. In some examples, the portion of the sensor data accumulated by the unmanned aircraft may be obtained by any number or configuration of sensors operatively and/or physically coupled to the unmanned aircraft. At step 508, the portion of the characteristic data accumulated by the unmanned aircraft is compared with the portion of the sensor data accumulated by the unmanned aircraft. At step 510, it is determined whether there are any changes in the condition of the component. In some examples, the unmanned aircraft may repeat flight paths to position cameras/sensors at relatively the same angle as previous flights. In some examples, since the unmanned aircraft may have repeated flight paths, current images and detections of the component may be compared with past images or detections of the component in order to identify new or changes in deteriorations of the component and allow for time lapse measurement of the deteriorations, damages, breaks, and/or changes in the condition of the component. If it is determined that there are no changes in the condition of the component, method 500 ends. If it is determined that there are changes in the condition of the component, at step 512, the operation model for the component is updated and method 500 ends. In some examples, based on the comparisons, OMS analytics, such as for example, regression analytics or statistical methods may be used to evaluate the deteriorations and update operation models that may predict the time when the component may stop/fail or decrease in operation. In some examples, logic may also be built and learned from the data obtained from the comparison of whether there is change in the condition of the component. This ability to learn from the outcome may allow the production of reliable, repeatable operation models and predictions and uncover "hidden insights" through historical relationships and trends in the characteristic data. In some examples, the failure predictions of the operation models may be progressively improved from the comparisons and/or feedback.

Method examples described herein can be machine or computer-implemented at least in part. Some examples can include a computer-readable medium or machine-readable medium encoded with instructions operable to configure an electronic device to perform methods as described in the above examples. An implementation of such methods can include code, such as microcode, assembly language code, a higher-level language code, or the like. Such code can include computer readable instructions for performing various methods. The code may form portions of computer program products. Further, in an example, the code can be tangibly stored on one or more volatile, non-transitory, or nonvolatile tangible computer-readable media, such as during execution or at other times.

Examples of these tangible computer-readable media can include, but are not limited to, hard disks, removable magnetic or optical disks, magnetic cassettes, memory cards or sticks, random access memories (RAMs), read only memories (ROMs), and the like.

The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) may be used in combination with each other. Also, in the above Description, various features may be grouped together to streamline the disclosure. This should not be interpreted as intending that an unclaimed disclosed feature is essential to any claim. Rather, inventive subject matter may lie in less than all features of a particular disclosed embodiment. Thus, the following claims are hereby incorporated into the Description as examples or embodiments, with each claim standing on its own as a separate embodiment, and it is contemplated that such embodiments can be combined with each other in various combinations or permutations. The scope of a system should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.