Patent Description:
Air data probes are safety-critical sensors installed on all modern aircraft to measure parameters like total pressure, static pressure, and in some cases, pressures for angle of attack and side slip. These probes are external to the aircraft and are exposed to harsh weather conditions and subzero temperatures. Such conditions may cause ice formation on part of the probe resulting in incorrect measurement of air data parameters. Accordingly, resistive heating elements are installed in the air data probes to prevent ice formation. To heat the probe, an operational voltage is provided through the heating element. Prolonged usage and frequent switching (i.e., between the OFF state and ON state) can lead to an abrupt failure of the heating element. When the heating element breaks down, the probe must be replaced prior to subsequent takeoff of the aircraft to ensure continued monitoring air data parameters. Thus, health monitoring of air data probes is critical.

Existing aircraft-based health monitoring systems can monitor various probe parameters but lack the sophistication to analyze the data using complex health monitoring algorithms. Data must be transmitted to a ground station for this purpose. Similarly, modification of the monitoring parameters in current systems requires the removal and reinstallation of the updated data acquisition module. A need exists for a dynamic health monitoring system for real-time prediction of remaining useful life and predicted failure of an air data probe with a high level of accuracy.

XP055604680 relates to the development of an Aircraft Health Monitoring Program for Predictive Maintenance, and <CIT> relates to a health monitoring system, and more specifically to a pitot heater health monitoring system.

A system as defined in claim <NUM> is provided.

A method for operating a cloud infrastructure in a system for monitoring a vehicle-borne probe as defined in claim <NUM> is provided and includes receiving, by a first edge device in communication with the probe, sensed data related to a characteristic of a heating element of the probe, analyzing, by a first application of the first edge device, the sensed data to generate a first data output, receiving, by a coordinator, the first data output, and incorporating the first data output into a data package, receiving, by a cloud infrastructure, a data package, analyzing, by the cloud infrastructure, the data package to estimate a remaining useful life and a failure of the probe.

While the above-identified figures set forth one or more embodiments of the present disclosure, other embodiments are also contemplated, as noted in the discussion. The figures may not be drawn to scale, and applications and embodiments of the present invention may include features and components not specifically shown in the drawings.

This disclosure presents a prognostics health monitoring (PHM) system and method for estimating a remaining useful life (RUL) and predicting imminent failure of a vehicle-bome probe, such as an aircraft air data probe. The system includes one or more sensors in communication with each monitored probe. An edge device associated with a probe receives the sensed data and performs various levels of data analytics. Data outputs from each edge device are sent to a smart coordinator of the system for additional monitoring and analysis. The coordinator packages the data and sends it to a cloud infrastructure and ground station for detailed analysis.

<FIG> is a schematic block diagram of an exemplary embodiment of multi-stage PHM system <NUM> for monitoring one or more air data probes <NUM>. System <NUM> includes a sensor <NUM> in communication with each probe <NUM> for monitoring characteristics of a heating element <NUM> of each probe <NUM>. In some embodiments, more than one sensor <NUM> can be in communication with a respective probe <NUM>. Each sensor <NUM> is further in communication with a dynamic edge device <NUM> for performing initial processing and monitoring of sensed data. Each edge device <NUM> is in communication with smart coordinator <NUM> which monitors pre-processed data from each edge device <NUM>, as well as aircraft parameters from one or more avionics systems <NUM>. On-aircraft gateway <NUM> connects coordinator <NUM> with cloud <NUM> and ground station <NUM>. The individual components of system <NUM> are discussed in greater detail below.

Each probe <NUM> can be a pitot probe, total air temperature (TAT) probe, or angle-of-attack (AOA) probe, to name a few non-limiting examples, configured to measure aircraft operational parameters such as pressure and/or temperature. In an alternative embodiment, probes <NUM> can be mounted to other types of (non-aerial) vehicles and can be suitable for measuring operational parameters of such vehicles. Each probe <NUM> includes a resistive heating element <NUM>, such as a heater wire, powered by a source of alternating (AC) or direct (DC) current. The flow of current through heating element <NUM> provides heating to the associated probe <NUM> to prevent ice accretion. The one or more sensors <NUM> in communication with a respective probe <NUM> can measure characteristics of an associated heating element <NUM>, such as current, capacitance, and/or voltage.

Each sensor <NUM> outputs sensed heating element <NUM> data to an associated edge device <NUM>. <FIG> is a schematic block diagram of an exemplary edge device <NUM> as a modular end node. Shown in <FIG> as part of edge device <NUM> are analog-to-digital converter (ADC) <NUM>, device identification (ID) <NUM>, device location identification (ID) <NUM>, signal conditioner <NUM>, power supply <NUM>, processing unit <NUM>, memory <NUM>, trusted platform module (TPM) <NUM>, digital-to-analog converter (DAC) <NUM>, and input/output communication interfaces <NUM>.

In operation of system <NUM>, data from sensor <NUM> is received by edge device <NUM> via a wired (e.g., Ethernet, AFDX, ARINC <NUM>, RS232/<NUM>/<NUM>, CAN, etc.) or wireless (e.g., Bluetooth, Wi-Fi, cellular, etc.) first/input communication interface <NUM>. The latter type of connection permits a sensor <NUM> and associated edge device <NUM> to be in physically separate locations on the aircraft. ADC <NUM> converts the received sensor <NUM> output signals to digital signals. Subsequent signal conditioning (e.g., filtering, linearization, amplification, etc.) is performed by signal conditioner <NUM>. Power supply <NUM> can be any suitable source of power, such as a battery, energy harvesting devices, or other sources on the aircraft. Upon power-up of edge device <NUM>, processing unit <NUM> reads device ID <NUM> and device location ID <NUM> to determine/confirm the type and physical location of edge device <NUM>. Processing unit <NUM> then reads the device configuration stored in memory <NUM> and configures edge device <NUM> based on device ID <NUM> and location ID <NUM>. Memory <NUM> can further store data and applications for access by processing unit <NUM>. Processing unit <NUM> can be, for example, a microprocessor or microcontroller configured to perform various data processing and analysis tasks, discussed in greater detail below, and output processed data to coordinator <NUM> via second/output communication interface <NUM>. Output communication interface <NUM> may be of the wired or wireless type discussed above with respect to input communication interface <NUM>. Output communication interface <NUM> is configured to exchange data with coordinator <NUM>. TPM <NUM> is at least one of various cybersecurity measures (e.g., certificate management, advanced encryption, etc.) implemented by edge device <NUM> for securely communicating with interfacing devices and systems.

<FIG> is a schematic block diagram of select software of edge device <NUM>. Edge device <NUM> software can include hardware abstraction layer <NUM>, data conditioner <NUM>, PHM data manager <NUM>, communication handler <NUM>, and hosted PHM application module <NUM>. Hardware abstraction layer <NUM> includes various board support packages and device drivers for abstracting hardware interfaces (e.g., device ID, discrete input/output, analog input/output, communication interfaces, etc.) of edge device <NUM>. Hardware abstraction layer can abstract higher level software modules from any changes in such hardware. Data conditioner <NUM> acquires signals from the hardware at the configured rate, filters the data, and stores the data in memory <NUM> (shown in <FIG>) which is accessible by data manager <NUM>. Data manager <NUM> manages edge device <NUM> data according to its configuration. Data manager <NUM> implements a publish/subscribe methodology to enable one or more applications of hosted PHM application module <NUM> to publish processed data while others of the applications can subscribe for data for processing. Any published data are automatically broadcast to any applications which have subscribed for that data. Data manager <NUM> further allows for space and time partitioning of the various hosted PHM applications which enables multiple Development Assurance Level (DAL) software/applications to coexist in edge device <NUM>. Communication handler <NUM> implements wrapper software to the various wired and/or wireless communication interfaces implemented in edge device <NUM>. Communication handler <NUM> provides standard software interfaces (e.g., SDK or APIs) to interfacing hosted PHM applications to enable communication with the external systems. Communication handler <NUM> uses cybersecurity measures (e.g., TPM, EAP-TLS, certificate management, advanced encryption, etc.) implemented in the operating system (OS) to ensure security of edge device <NUM> and its communications with interfacing devices/systems, including coordinator <NUM>, and other avionics systems.

Hosted PHM application module <NUM> can include core application module <NUM> with core applications <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> (collectively referred to as "core applications <NUM>"), and dynamic application module <NUM> with dynamic applications <NUM>-<NUM> and <NUM>-<NUM> (collectively referred to as "dynamic applications <NUM>"). Various embodiments of edge device <NUM> can include any number of <NUM> to n core applications <NUM> and/or <NUM> to m dynamic applications <NUM>. In some embodiments, core applications <NUM> and/or dynamic applications <NUM> can be incorporated into a field load bundle that enables updating of the hosted applications. The field load bundle can additionally and/or alternatively include any of the following sections for updating: device configuration information (e.g., edge device ID and location ID, serial number, part number, etc.), cybersecurity (e.g., certificates, encryption keys, etc.), device-specific software containing configuration information (e.g., input sample size, sampling rate, output rate, parameters, communication protocol, etc.), and software/firmware (e.g., executable object code, parameter data item, etc.).

Core applications <NUM> enable implementation of the PHM functions of edge device <NUM>. More specifically, core application <NUM>-<NUM> can be an advanced local PHM data repository for implementing reusable data analytics algorithms (e.g., Fast Fourier Transform (FFT), arc fault detection, etc.) local to edge device <NUM>. The various hosted PHM applications can use the algorithms implemented in the data analytics repository instead of duplicating their implementation. Core application <NUM>-<NUM> can be a stage-<NUM> pre-PHM data processing application for continuously monitoring sensed heater <NUM> data, and for performing coarse-PHM data analytics on the sensed data using one or more coarse-PHM data analytics algorithms. Any resulting coarse data analytics outputs can be sent to coordinator <NUM>, as well as further monitored by one of the dynamic applications <NUM>, as is discussed in greater detail below. Core application <NUM>-<NUM> can be a field loader application for updating any of the bundled applications or sections discussed above.

Dynamic applications <NUM> are optional PHM applications that can be temporary or short-term in nature. More specifically, dynamic applications <NUM> can be automatically loaded onto edge device <NUM> by coordinator <NUM> and/or enabled/activated by the occurrence of one or more trigger events. As such, dynamic applications <NUM> can be automatically deactivated after a specific interval or when other conditions occur. Dynamic application <NUM>-<NUM> can include one or more application-specific monitoring algorithms (e.g., for brake temperature monitoring, acoustics monitoring, smart BIT, battery monitoring, vibration monitoring, cabin temperature monitoring, heater current arc fault detection, etc.). Dynamic application <NUM>-<NUM> can be a stage-<NUM> targeted PHM assessment application for monitoring the coarse data outputs from the stage-<NUM> pre-PHM application, performing finer data analysis on the monitored data, and dynamically updating the data monitoring scheme of the hosting edge device <NUM>. The finer data analysis can include monitoring of additional parameters from the associated sensor <NUM>, monitoring of parameters at a higher rate, and/or monitoring of higher parameters at higher precision and/or processing.

<FIG> is a plot, over time, of the operation of the stage-<NUM> pre-PHM data processing application and a pre-loaded stage-<NUM> targeted PHM assessment application. <FIG> is a plot, over time, of the operation of the stage-<NUM> pre-PHM data processing application and an alternative, dynamically loaded, time-bound stage-<NUM> targeted PHM assessment application. <FIG> is a plot, over time, of the operation of the stage-<NUM> pre-PHM data processing application and a second alternative dynamically loaded, trigger-based stage-<NUM> targeted PHM assessment application.

As shown in <FIG> from the top to the bottom of the y-axis, are plots of PHM system <NUM>, the stage-<NUM> pre-PHM data processing application, start and end triggers, and the stage-<NUM> targeted PHM assessment application. Beginning at time t<NUM>, system <NUM> is running and active. At time t<NUM>, the stage-<NUM> pre-PHM data processing application is activated. In the embodiment of <FIG>, the stage-<NUM> targeted PHM assessment application is pre-loaded onto edge device <NUM> and continuously monitors the data outputs generated by the stage-<NUM> application for trigger events. As such, the stage-<NUM> targeted PHM assessment application begins operating at time t<NUM>. A "start" trigger event occurs at time t<NUM>. For any of the embodiments of <FIG>, a "start" trigger event can be, for example, a probe fault, or exceedance of a predetermined parameter threshold or count. Also at time t<NUM>, the stage-<NUM> targeted PHM assessment application begins finer data analytics, as identified by interval 68A. An "end" trigger event occurs at time t<NUM>, and the stage-<NUM> targeted PHM assessment application ceases finer data analytics and continues monitoring stage-<NUM> data. An "end" trigger event can be, for example, the ending of or return to normal values of a "start" trigger event, or a different trigger event based on another monitored parameter. Interval 68A is defined by the "start" and "end" trigger events of times t<NUM> and t<NUM>, respectively, and represents activation of the stage-<NUM> targeted PHM assessment application to perform finer data analysis and generate a finer data analytics output to be sent to coordinator <NUM>.

The embodiment of <FIG> is similar to the embodiment of <FIG>, except that the stage-<NUM> targeted PHM assessment application is dynamically loaded and activated by coordinator <NUM>. The stage-<NUM> targeted PHM assessment application is time-bound such that it is configured to run for a predetermined interval (interval 68B) once activated. Activation can occur by a "start" trigger event, and deactivation with time elapsing. As with the embodiment of <FIG>, PHM system <NUM> and the stage-<NUM> pre-PHM data processing application become active at times t<NUM> and t<NUM>, respectively. At time t<NUM>, the timer begins running as the result of a "start" trigger or other event, and the stage-<NUM> targeted PHM assessment application is activated to perform finer data analysis. Time elapses at time t<NUM> and the stage-<NUM> targeted PHM assessment application is deactivated. The finer data analytics output generated by the stage-<NUM> targeted PHM assessment application can be sent to coordinator <NUM>. In an alternative embodiment, activation/deactivation of the stage-<NUM> targeted PHM assessment application may not occur simultaneously with the starting/ending of the timer, rather, interval 68B can be slightly offset from the timer due to a cycle delay in processing the event triggering the timer.

<FIG> shows an alternative dynamically loaded stage-<NUM> targeted PHM assessment application configured for trigger-based activation. As with the embodiments of <FIG> and <FIG>, PHM system <NUM> and the stage-<NUM> pre-PHM data processing application become active at times t<NUM> and t<NUM>, respectively. At time t<NUM>, a "start" trigger event occurs, causing activation of the stage-<NUM> targeted PHM assessment application to perform finer data analytics at time t<NUM>. An "end" trigger event occurs at time t<NUM> leading to deactivation of the stage-<NUM> targeted PHM assessment application at time t<NUM>. Interval 68C defines the period of activity of the stage-<NUM> targeted PHM assessment application. As with the embodiments of <FIG> and <FIG>, the finer data analytics output generated by the stage-<NUM> targeted PHM assessment application can be sent to coordinator <NUM>.

<FIG> is a schematic block diagram of an exemplary smart coordinator <NUM>. As shown in <FIG>, coordinator <NUM> includes communication interfaces <NUM> interfacing with one or more edge devices <NUM>, on-aircraft gateway <NUM>, and one or more avionics systems <NUM>. Through its interface with avionics systems <NUM>, coordinator <NUM> can monitor aircraft parameters such as air speed, weight-on-wheel, latitude, longitude, altitude, etc. Further included are power supply <NUM>, processing unit <NUM> (e.g., a microprocessor or microcontroller), memory <NUM>, and TPM <NUM>. Communication interfaces <NUM> can be wired (e.g., Ethernet, AFDX, ARINC <NUM>, RS232/<NUM>/<NUM>, CAN, etc.) or wireless (e.g., Bluetooth, Wi-Fi, cellular, etc.) interfaces for exchanging data with connected devices and systems. Power supply <NUM> can be a battery, or energy harvesting devices or other sources on the aircraft. According to the invention, upon power-up, processing unit <NUM> retrieves edge device <NUM> and/or coordinator <NUM> updates (e.g., software, configuration information, field load bundles, etc.) from ground station <NUM> or cloud <NUM> via on-aircraft gateway <NUM>. Each edge device <NUM> interfaced with coordinator <NUM> attempts to connect with coordinator <NUM> until coordinator <NUM> rejects or accepts the request by authenticating the requesting edge devices <NUM>. Connected edge devices <NUM> are dynamically configured by coordinator <NUM>, which transmits the latest software, configuration, trigger events, etc. to edge devices <NUM>. Processing unit <NUM> accesses various data and applications from memory <NUM>.

As discussed above with respect to <FIG> and <FIG>, coordinator <NUM> can monitor the stage-<NUM> pre-PHM coarse data outputs from an associated edge device <NUM>, and dynamically load a stage-<NUM> targeted assessment application to the edge device <NUM> if any trigger events occur. The application can be loaded using, for example, a field load bundle. Upon successful loading, coordinator <NUM> can activate and deactivate the stage-<NUM> targeted assessment application as necessary based on activation parameters (e.g., trigger events, predetermined time intervals, etc.). In some embodiments, coordinator <NUM> can be configured to locally (i.e., within coordinator <NUM>) implement the stage-<NUM> targeted assessment application using processing unit <NUM>.

Coordinator <NUM> can further synthesize monitored aircraft data from avionics system(s) <NUM> with the coarse data (stage-<NUM>) and finer data (stage-<NUM>) analytics outputs from multiple edge devices <NUM> for determining trigger events and making monitoring decisions. Accordingly, coordinator <NUM> can implement stage-<NUM> PHM data analytics on the synthesized data. <FIG> is a plot, over time, of the operation of the stage-<NUM> data analytics application on the data monitored by coordinator <NUM>. Shown in <FIG>, from the top to the bottom of the y-axis, are plots of the operation of PHM system <NUM>, the stage-<NUM> pre-PHM data processing applications and stage-<NUM> targeted PHM assessment applications of a first and second edge devices <NUM>, monitored data from edge devices <NUM>, monitored aircraft data, start and end triggers, and the stage-<NUM> PHM data analytics application. Although only two edge devices <NUM> are represented on the plot of <FIG>, coordinator <NUM> can monitor and analyze data from more than two edge devices <NUM> in alternative embodiments.

At time t<NUM>, system <NUM> and the stage-<NUM> and stage-<NUM> applications from each edge device <NUM> are activated, and coordinator <NUM> begins monitoring edge device and aircraft data. At time t<NUM>, the stage-<NUM> applications from each edge device <NUM> are activated for an interval defined generically as interval <NUM>. The "start" trigger event for activation of the stage-<NUM> applications is not plotted in <FIG>. At time t<NUM>, a "start" trigger event, based on the monitored edge device and aircraft data, occurs and coordinator <NUM> begins stage-<NUM> PHM data analytics at time t<NUM>. At time t<NUM>, an "end" trigger event occurs, and coordinator <NUM> ceases stage-<NUM> PHM data analytics at time t<NUM>. Interval <NUM> is defined by the "start" and "end" trigger events and represents activation of stage-<NUM> PHM data analytics and generation of a stage-<NUM> data analytics output by coordinator <NUM>. In an alterative embodiment, stage-<NUM> PHM data analytics can be time-bound (i.e., enabled for predetermined intervals) in a manner substantially similar to the stage-<NUM> targeted PHM assessment application of <FIG>.

Data received and/or analyzed by coordinator <NUM> (e.g., aircraft data, stage-<NUM>, stage-<NUM> and/or stage-<NUM> data analytics outputs) can be timestamped and packaged before sending to cloud <NUM> and/or ground station <NUM>. Cybersecurity measures, such as encryption and digital signatures, can be implemented by TPM <NUM> to ensure confidentiality, integrity, and authentication of the data package(s). In an alternative embodiment, system <NUM> can include more than one coordinator <NUM>, and data packages can be shared among the multiple coordinators <NUM>. Data packages are shared with cloud <NUM> and/or ground station <NUM> via on-aircraft gateway <NUM>. Referring back to <FIG>, on-aircraft gateway <NUM> is distinct from coordinator <NUM>, however, coordinator <NUM> and on-aircraft gateway <NUM> can be grouped together in an alternative embodiment to facilitate implementation of the two components.

Cloud <NUM> can implement a cloud-hosted PHM data analytics application for analyzing, using machine learning techniques, received PHM data to predict imminent failure and estimate RUL of air data probes <NUM>. <FIG> is a flowchart illustrating method <NUM> showing the prediction, estimation, and updating functions of cloud <NUM>. At step <NUM>, the data package is received by cloud <NUM> from coordinator <NUM>. At step <NUM>, cloud <NUM> performs a PHM assessment on the data. At step <NUM>, the assessment can be used to predict imminent failure and estimate RUL of probe <NUM>. This can be accomplished, for example, by using machine learning techniques to analyze received data, as well as monitored aircraft data, data history, and trend data. Supplemental flight data such as weather, flight path, service history, etc. can also be included and analyzed. At step <NUM>, cloud <NUM> can automatically and intelligently tune/refine algorithms of the stage-<NUM>, stage-<NUM> and/or stage-<NUM> applications to improve the relevance and quality of collected data for more accurate RUL estimation and failure prediction. At step <NUM>, the cloud-hosted PHM data analytics application can update trigger events and data collection and monitoring strategies, as necessary. Updates can be included in field load bundles and pushed/transmitted, by cloud <NUM>, to coordinator <NUM> and edge devices <NUM>.

Cloud <NUM> can further implement data storage for storing monitored data. Ground station <NUM> can access data stored in cloud <NUM> to perform additional analysis using, for example, advanced PHM algorithms, to further improve upon technologies and methods for estimating RUL and predicting imminent failures of probes <NUM>. In some embodiments, ground station <NUM> can be configured to carry out the failure prediction and RUL estimation of method <NUM> in addition to, or as an alternative to cloud <NUM>. This can be the case, for example, where it is desirable to provide redundancy, or where the functions of cloud <NUM> and ground station <NUM> overlap. RUL and failure predictions can be reported to a database monitored by and accessible to aircraft maintenance personnel. Such reporting can be accomplished via an alert or notification generated by an application of cloud <NUM>, and/or by ground station <NUM>. PHM system <NUM> allows for a tailored maintenance approach that allows for the timely replacement of faulty probes to minimize operational disruption and avoids the unnecessary replacement of healthy probes based on flight hours or other standard metrics.

Discussion of Possible Embodiments not belonging to the claimed invention.

The following are non-exclusive descriptions of possible embodiments not belonging to the claimed invention.

A system for monitoring a vehicle-borne probe includes a first edge device in communication with the probe and configured to sense data related to a characteristic of a heating element of the probe, a coordinator in communication with the first edge device and configured to receive a first data output from the first edge device and to incorporate the first data output into a data package, a cloud infrastructure in communication with the coordinator via a data gateway and configured to analyze the data package to estimate a remaining useful life and predict a failure of the probe, and a ground station in communication with the cloud infrastructure and configured to refine remaining useful life estimation and failure prediction techniques of the system.

The system of the preceding paragraph can optionally include, additionally and/or alternatively, any one or more of the following features, configurations and/or additional components:
In the above system, the vehicle can be an aircraft and the probe can be one of a pitot probe, a total air temperature probe, and an angle-of-attack probe.

In any of the above systems, the coordinator can further be configured to either receive a second data output from the first edge device, or to generate the second data output.

In any of the above systems, the coordinator can further be configured to incorporate the second data output into the data package.

Any of the above systems can further include: a second edge device in communication with a separate probe of the aircraft. The coordinator can further be configured to receive a third data output from the second edge device and incorporate the third data output into the data package.

In any of the above systems, the cloud infrastructure can further be configured to analyze at least one of trend data and supplemental flight data to estimate the remaining useful life and predict the failure of the probe.

In any of the above systems, the supplemental flight data can include at least one of weather, flight path, and service history of the aircraft.

In any of the above systems, the cloud infrastructure can further be configured to implement a data analytics application to analyze the data package.

In any of the above systems, the data analytics application can include machine learning.

In any of the above systems, at least one of the cloud infrastructure and the ground station can be configured to generate a notification of the remaining useful life estimation and the failure of the probe.

A method for operating a cloud infrastructure in a system for monitoring a vehicle-borne probe includes receiving, by a first edge device in communication with the probe, sensed data related to a characteristic of a heating element of the probe, analyzing, by a first application of the first edge device, the sensed data to generate a first data output, receiving, by a coordinator in communication with the first edge device, the first data output, and incorporating the first data output into a data package, receiving, by a cloud infrastructure in communication with a coordinator, a data package, analyzing, by the cloud infrastructure, the data package to estimate a remaining useful life and a failure of the probe, and transmitting, by the cloud infrastructure, updates to the coordinator.

The method of the preceding paragraph can optionally include, additionally and/or alternatively, any one or more of the following features, configurations and/or additional components:
The above method can further include analyzing, by a second application of the first edge device, the first data output to generate a second data output, receiving, by the coordinator, the second data output, and incorporating, by the coordinator, the second data output in the data package.

In any of the above methods, the first application can be a core application, and the second application can be a dynamic application.

Any of the above methods can further include: monitoring, by the core application, the sensed data, and analyzing, by the core application, the sensed data to generate the first data output.

Any of the above methods can further include: monitoring, by the dynamic application, the first data output, analyzing, by the dynamic application, the first data output if a trigger event occurs, and generating, by the dynamic application, the second data output.

In any of the above methods, the step of analyzing the data package can include implementing, by the cloud infrastructure, a data analytics application.

Any of the above methods can further include: refining, by the coordinator, at least one of the core application and the dynamic application.

In any of the above methods, the updates transmitted to the coordinator can include an updated trigger event.

Any of the above methods can further include: transmitting, by the cloud infrastructure, data to a ground station.

Any of the above methods can further include: generating, by at least one of the cloud infrastructure and ground station, a notification of an estimation of the remaining useful life of the probe and a prediction of the failure of the probe.

Claim 1:
A system comprising:
a probe (<NUM>) for mounting to a vehicle having a heating element (<NUM>); and
a system for monitoring the probe (<NUM>), the system comprising:
a first edge device (<NUM>) in communication with the probe and configured to sense data related to a characteristic of the heating element (<NUM>) of the probe;
a coordinator (<NUM>) in communication with the first edge device and configured to receive a first data output from the first edge device and to incorporate the first data output into a data package;
a cloud infrastructure in communication with the coordinator via a data gateway and configured to analyze the data package to estimate a remaining useful life and predict a failure of the probe; and
a ground station (<NUM>) in communication with the cloud infrastructure and configured to refine remaining useful life estimation and failure prediction techniques of the system;
wherein the coordinator is further configured to:
authenticate, upon power up of the coordinator, the first edge device (<NUM>); and
subsequently, retrieve updates from the cloud infrastructure (<NUM>) and transmit the updates to the first edge device (<NUM>).