System and method for determining lifetime of performance of sensor in monitored system

Abstract

At least one server includes at least one processor coupled to at least one memory storing instructions. A server may receive a first signal from a first monitored system including an internal combustion engine and a first sensor, the first signal associated with a first occurrence of an internal combustion engine event, a second occurrence of an internal combustion engine event, and first measurement data of the first sensor. The server may determine a first measurement result based on the first measurement data. The server may determine a second measurement result based on the first measurement data. The server may determine a measurement deviation between the first measurement and the second measurement. The server may compare the measurement deviation to a stored measurement threshold. The server may determine a service life of the first performance of the first sensor based on the measurement deviation and at least one of the first measurement or the second measurement.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of and priority to U.S. non-provisional application No. 17 / 868,205, filed on July 19, 2022, entitled “SYSTEMS AND METHODS FOR DETERMINING EXHIBITED USEFUL LIFE OF SENSORS IN MONITORED SYSTEMS,” which is incorporated herein by reference in its entirety. Technical Field

[0002] The present application generally relates to systems and methods for determining the exhibited useful life of a sensor in a monitored system. background

[0003] Emissions from internal combustion engines (such as diesel engines) include nitrogen oxides (NO x ) compounds in the exhaust. For example, it may be desirable to reduce NO x To comply with environmental regulations, in order to reduce NO x Emissions, the reductant can be dosed into the exhaust gas through a dosing system in the aftertreatment system. The reductant works in conjunction with the catalyst to promote the conversion of a portion of the exhaust gas into non-NO x emissions (such as nitrogen (N2), carbon dioxide (CO2) and water (H2O)), thereby reducing NO x emission.

[0004] In some applications, these compounds in the exhaust gas may be sensed by one or more sensors located in the aftertreatment system. In such applications, it is desirable to maintain the operability and condition of the sensors to ensure reliable measurements. Typically, the condition or performance of the sensors may be evaluated during routine maintenance of certain systems. In some cases, a fault code or indication of a sensor failure is provided to an operator after the sensor has already failed. However, predicting the remaining life of a sensor before a failure occurs may be challenging. Overview

[0005] In some embodiments, at least one server may include at least one processor coupled to at least one memory storing instructions, which instructions, when executed by the at least one processor, cause the at least one server to receive a first signal from a first monitored system including an internal combustion engine and a first sensor, the first signal being associated with a first occurrence of an internal combustion engine event of the first monitored system, a second occurrence of an internal combustion engine event of the first monitored system, and first measurement data of the first sensor. The server may determine a first measurement result based on the first occurrence of the internal combustion engine event according to the first measurement data. The server may determine a second measurement result based on the second occurrence of the internal combustion engine event according to the first measurement data. The server may determine a measurement deviation between the first measurement result and the second measurement result. The server may compare the measurement deviation with a stored measurement threshold. After determining that the measurement deviation satisfies the measurement threshold, the server may determine a useful life of a first manifestation of the first sensor based on the measurement deviation and at least one of the first measurement result or the second measurement result.

[0006] In certain embodiments, a method may include receiving, by at least one server, a first signal from a monitored system, the first signal being associated with a first occurrence of an internal combustion engine event of the monitored system, a second occurrence of the internal combustion engine event of the monitored system, and first measurement data of a first sensor of the monitored system. The method may include determining, by at least one server, a first measurement result based on the first measurement data based on the first occurrence of the internal combustion engine event. The method may include determining, by at least one server, a second measurement result based on the first measurement data based on the second occurrence of the internal combustion engine event. The method may include determining, by at least one server, a measurement deviation between the first measurement result and the second measurement result. The method may include comparing, by at least one server, the measurement deviation to a measurement threshold. The method may include determining, by at least one server, a useful life of a first manifestation of the first sensor based on the measurement deviation and at least one of the first measurement result or the second measurement result after determining that the measurement deviation satisfies the measurement threshold.

[0007] In yet other embodiments, a network may include a first monitored system, the first monitored system including a first internal combustion engine, a first sensor, and a first engine control unit. The network may include at least one server external to the first monitored system, the at least one server including at least one processor coupled to at least one memory storing instructions, the instructions, when executed by the at least one processor, causing the at least one server to receive a first signal from the first engine control unit, the first signal being associated with a first occurrence of a first internal combustion engine event of the first monitored system, a second occurrence of the first internal combustion engine event, and first measurement data of the first sensor. The server may determine a first measurement result based on the first occurrence of the first internal combustion engine event and from the first measurement data. The server may determine a second measurement result based on the second occurrence of the first internal combustion engine event and from the first measurement data. The server may determine a first measurement deviation between the first measurement result and the second measurement result. The server may compare the first measurement deviation with a stored measurement threshold. After determining that the first measurement deviation satisfies the measurement threshold, the server may determine a useful life of a first manifestation of the first sensor based on the first measurement deviation and at least one of the first measurement result or the second measurement result. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The details of one or more embodiments are set forth in the accompanying drawings and the following description. Other features, aspects, and advantages of the present disclosure will become apparent from the description, drawings, and claims, in which: Figure 1 is a block diagram of an example vehicle system; Figure 2 It is a process flow chart of the modeling process; Figure 3 Example internal combustion engine events and measurement data are shown; Figure 4 An example NO signal during motoring for a faulty sensor is shown. x Sensor response; Figure 5A-Figure 5C Yes NO x a graph of example expected measurements from a sensor; Figure 6A-6C Yes NO x a graph of example abnormal measurements of a sensor; Figure 7 Yes NO x A graph of example prediction accuracy and remaining time for a sensor; Figure 8 Yes NO x a graph of an example remaining life of a sensor based on a monitored excursion; Fig. 9It is NO associated with different systems x Heatmap of example health status of sensors; and Fig.10 is a flow chart of an example method for a monitored system.

[0009] It will be appreciated that some or all of the drawings are schematic representations for illustrative purposes. The drawings are provided for the purpose of illustrating one or more embodiments, with the express understanding that they will not be used to limit the scope or meaning of the claims. Detailed Description

[0010] The following is a more detailed description of various concepts related to methods and apparatus for determining the life span of a sensor in a monitored system and implementations of the methods and apparatus. The various concepts introduced above and discussed in more detail below can be implemented in any of a variety of ways, as the concepts described are not limited to any particular implementation. Examples of specific implementations and applications are provided primarily for illustrative purposes.

[0011] I. Overview Internal combustion engines (e.g., diesel engines, etc.) produce exhaust gases. Depending on the fuel consumed by the internal combustion engine, the exhaust gases may contain different by-products (e.g., NO x , carbon monoxide (CO), unburned hydrocarbons (HC), etc.). The byproducts in the exhaust gas can be measured or sensed by one or more sensors of the aftertreatment system, such as measuring the density, volume, parts per million (ppm), etc. of the exhaust gas. For simplicity, the examples herein may provide NO x As a byproduct in the exhaust gas, the sensor may be configured to sense NO downstream of the engine (e.g., anywhere along the exhaust pipe). x Emissions of NO x Although the described examples include measuring NO x Byproduct NO x sensor, but the described system can be applied to other sensors.

[0012] The measurements may be used by the controller to control or manage components within or coupled to the aftertreatment to manage emissions from the engine. For example, the components may include a doser, hydrocarbon injectors, an exhaust gas recirculation (EGR) system, a heater, a cooler, and other components. Using the measurements, the controller may control one or more components to minimize NO xSlippage, for example, increasing the reductant dosing, initiating hydrocarbon injection for catalyst (e.g., selective catalytic reduction (SCR) catalyst, etc.) regeneration, etc. However, due to sensor degradation over time or failure, the controller may receive inaccurate measurements, or in some cases, may not receive any signal from the sensor. The inaccuracy of the measurement or the lack of a signal indicating the emission output from the engine may impair the operability of certain components coupled to the aftertreatment system or certain components of the aftertreatment system, which leads to incorrect adjustment or configuration of the controller. Therefore, it is desirable to determine or predict the health of the sensor over time to subsequently maintain or replace the sensor before failure (e.g., predict the duration until failure).

[0013] The system and method of the technical solution described herein include at least one device (e.g., a computing device, a server, or a data processing system), which includes at least one processor coupled to at least one memory. In some cases, the device can be embedded in a system including an internal combustion engine and one or more sensors. In some cases, the device may correspond to a server or be referred to as a server in this article. The server may be a remote device configured to receive signals, data, or information from one or more sensors downstream of an engine (e.g., an internal combustion engine). The server may receive and monitor signals from sensors, such as measurement data (e.g., first measurement data) of sensors during pre-specified / predetermined internal combustion engine events or operating events. These internal combustion engine events may include expected behavior (e.g., expected measurement results or second measurement data) from sensors, which may be used to determine anomalies relative to expected behavior (e.g., measurement deviations between first and second measurement results).

[0014] The server can use the fusion of data analysis and physics-based techniques described herein to provide a predictive solution for health prediction of sensors and other components of the aftertreatment system. Health predictions can include the performance or predicted service life of sensors, actuators, filters, and other components in the observed engine system. By predicting health, the server can notify the client or user to replace or maintain the sensor in advance. In addition, in order to predict the health or status of the sensor, the server can use specific measurements over time to generate, obtain, or train a machine learning model without relying on population data (e.g., information from other internal combustion engine systems). For example, instead of comparing the behavior of the sensor with other comparable sensors (e.g., sensors belonging to similar vehicles, machines, etc.), the server can aggregate sensor measurements (e.g., first measurements, second measurements, etc.) during the occurrence of a predetermined engine event to determine the change in the offset of the sensor's measurement results. Due to the reduction in sensitivity and the impact on the sensor's accurate measurement of NO x An additional variable of emission capability, an offset (eg, calibration) may be applied to the sensor.

[0015] The server can train the model by inputting data of the offset measured during the engine event. The model can aggregate input data, including changes, deviations, and fluctuations in the offset from the installation time of the sensor to the failure time. The server can provide sample data to the model to improve the performance of the model (e.g., output accuracy). Once the model is trained and can be executed based on at least the expected performance, the server can use the model to subsequently predict the health status (e.g., remaining service life or time till failure) of one or more sensors (e.g., sensors of similar types associated with the trained model). For example, the server can receive sensor data from the sensor and input the sensor data into the model. The model can determine the remaining service life or failure time of the sensor based on at least one of the fluctuations, deviations, or trends of the offset measurement results, according to the operating conditions / environment (e.g., life / aging (age), operating temperature, exhaust gas exposure, poisoning (poisoning), duty cycle (duty cycle), fuel quality, etc.) experienced by the sensor during its operation. Therefore, the server can predict the remaining operating time of the sensor without high resource consumption (e.g., without comparing with various overall data) and without extended delays for predicting output.

[0016] Through these features, the embodiments described herein can warn the user of the use of impure fuel and the aging of the catalyst beyond an expected level. Thus, the embodiments described herein can reduce the costs associated with warranty service and / or replacement that may be performed when an internal combustion engine consumes impure fuel.

[0017] II. Network System Overview Figure 1 An example network system 100 (e.g., a network) is shown. The network system 100 includes a monitored system 102 and a monitoring system 104 (e.g., a server). The monitored system 102 communicates (e.g., electrically or wirelessly) with the monitoring system 104. The monitored system 102 may include a vehicle or be part of a vehicle (e.g., communicate with the vehicle). The vehicle may be an on-road vehicle or an off-road vehicle, including but not limited to a long-haul truck, a mid-range truck (e.g., a pickup truck), a car, a ship, a tank, an airplane, a locomotive, a mining equipment, and any other type of vehicle. The vehicle may include a transmission, a fueling system, one or more additional vehicle subsystems, etc. The vehicle may include additional, fewer, and / or different components / systems, so that the principles, methods, systems, devices, processes, etc. of the present disclosure are intended to be applicable to any other vehicle configuration. It should also be understood that the principles of the present disclosure should not be interpreted as limited to vehicles; rather, the present disclosure is also applicable to stationary equipment such as generators or generator sets.

[0018] The monitored system 102 includes an exhaust aftertreatment system 103 having a reductant delivery system 105 for an exhaust conduit system 106. The monitored system 102 also includes an internal combustion engine 108 (e.g., a diesel internal combustion engine, a diesel hybrid internal combustion engine, a gasoline internal combustion engine, a petrol internal combustion engine, a liquid propane internal combustion engine, etc.) that produces exhaust received by the exhaust aftertreatment system 103. The internal combustion engine 108 receives fuel (e.g., diesel fuel, gasoline, liquid propane, etc.) from a fuel tank 110 (e.g., a reservoir, etc.). The fuel tank 110 is configured to be refillable (e.g., by a user, etc.).

[0019] The exhaust aftertreatment system 103 also includes an oxidation catalyst 111 (eg, a diesel oxidation catalyst (DOC)). The oxidation catalyst 111 is configured (eg, constructed to, capable of, etc.) to promote oxidation of hydrocarbons and / or carbon monoxide in the exhaust gas generated by the internal combustion engine 108 and flowing in the exhaust conduit system 106.

[0020] The exhaust aftertreatment system 103 also includes a particulate filter 112 (e.g., a diesel particulate filter (DPF), etc.). The particulate filter 112 is configured to remove particulate matter (such as soot) from the exhaust provided by the oxidation catalyst 111. The particulate filter 112 includes an inlet and an outlet, the exhaust is received at the inlet, and the exhaust exits at the outlet after substantially filtering the particulate matter from the exhaust and / or converting the particulate matter into carbon dioxide. In some embodiments, the particulate filter 112 may be omitted.

[0021] The exhaust aftertreatment system 103 also includes a decomposition chamber 114 (eg, a reactor, a reactor tube, etc.). The decomposition chamber 114 is configured to convert the reductant into ammonia. The reductant may be, for example, urea, diesel exhaust fluid (DEF), Adblue ® , urea aqueous solution (UWS), aqueous urea solution (AUS) (eg, AUS32, etc.) and other similar fluids. The decomposition chamber 114 includes an inlet and an outlet, the inlet being in fluid communication with the particulate filter 112 to receive the NO x The exhaust gas of the emission is used to make the exhaust gas, NO x Exhaust, ammonia, and / or reductant flow out of the decomposition chamber 114 .

[0022] The exhaust aftertreatment system 103 further includes a conversion catalyst 116 (eg, a selective catalytic reduction (SCR) catalyst, a copper zeolite SCR catalyst, etc.). The conversion catalyst 116 is configured to convert ammonia and NO in the exhaust gas into x NO x The reduction process helps reduce NO x The reduction process converts ammonia and NOx in the exhaust gas into diatomic nitrogen, water and / or carbon dioxide. The conversion catalyst 116 includes an inlet and an outlet, the inlet is fluidly connected to the decomposition chamber 114, and the exhaust gas and the reducing agent are received from the decomposition chamber 114, and the outlet is fluidly connected to the end of the exhaust gas conduit system 106.

[0023] The decomposition chamber 114 is located upstream of the conversion catalyst 116. Therefore, the reductant is injected upstream of the conversion catalyst 116 so that the conversion catalyst 116 receives a mixture of the reductant and the exhaust gas. The reductant droplets undergo evaporation, pyrolysis and hydrolysis processes to form non-NO x Emissions (e.g., gaseous ammonia, etc.).

[0024] The reductant delivery system 105 includes a dosing module 118 (e.g., a doser, etc.) configured to dosing the reductant into the decomposition chamber 114 (e.g., via an injector, etc.). The dosing module 118 is mounted to the decomposition chamber 114 so that the dosing module 118 can dosing the reductant into the exhaust gas flowing in the exhaust conduit system 106. The dosing module 118 can include an insulator (e.g., a thermal insulator, etc.) and / or an isolator (e.g., a vibration isolator, etc.) interposed between a portion of the dosing module 118 and a portion of the decomposition chamber 114 on which the dosing module 118 is mounted.

[0025] The dosing module 118 is fluidly coupled to a reductant source 120 (eg, a reductant tank, a reductant reservoir, etc.) (eg, configured to be in fluid communication with the reductant source 120, etc.). The reductant source 120 may include a plurality of reductant sources 120. The reductant source 120 may be, for example, a reductant containing Adblue. ® DEF tank. The reductant pump 121 (e.g., a supply unit, etc.) is used to pressurize the reductant from the reductant source 120 for delivery to the dosing module 118. In some embodiments, the reductant pump 121 is pressure-controlled (e.g., controlled to obtain a target pressure, etc.). The reductant pump 121 can draw the reductant through the reductant filter 122. Before providing the reductant to the internal components (e.g., pistons, blades, etc.) of the reductant pump 121, the reductant filter 122 first filters the reductant (e.g., particulate matter strain, etc.). For example, the reductant filter 122 can inhibit or prevent solids (e.g., solidified reductant, pollutants, etc.) from being transmitted to the internal components of the reductant pump 121. In this way, the reductant filter 122 can help extend the operation of the reductant pump 121 in a good state. In some embodiments, the reductant pump 121 is connected to the chassis of a vehicle associated with the exhaust gas aftertreatment system 103.

[0026] The dosing module 118 includes at least one injector 124 (e.g., a reductant injector, etc.). Each injector 124 is configured to dose the reductant into the exhaust gas (e.g., within the decomposition chamber 114, etc.). The injectors 124 can be positioned so that the reductant achieves a target uniformity index (UI) within the exhaust gas at a target location (e.g., at the inlet of the conversion catalyst 116, etc.).

[0027] In some embodiments, the reductant delivery system 105 also includes an air pump 126. In these embodiments, the air pump 126 draws air from an air source 128 (e.g., an air intake, the atmosphere, etc.) and passes the air through an air filter 130 disposed upstream of the air pump 126. The air filter 130 filters the air before the air is provided to the internal components (e.g., pistons, blades, etc.) of the air pump 126. For example, the air filter 130 can inhibit or prevent solids (e.g., debris, branches, dirt, etc.) from being transmitted to the internal components of the air pump 126. In this way, the air filter 130 can help extend the operation of the air pump 126 in good condition. The air pump 126 provides air to the dosing module 118 via a conduit. The dosing module 118 is configured to mix the air and the reductant into an air-reductant mixture and provide the air-reductant mixture to the decomposition chamber 114. In other embodiments, the reductant delivery system 105 does not include an air pump 126 or an air source 128. In such an embodiment, the dosing module 118 is not configured to mix the reductant with the air.

[0028] The dosing module 118 and the reductant pump 121 (as well as other components of the network system 100) are also electrically or communicatively coupled to the monitored system 102 (e.g., an exhaust aftertreatment system controller or an engine control unit (ECU)). The monitored system 102 is configured to control the dosing module 118 to dispense the reductant into the decomposition chamber 114. The monitored system 102 may also be configured to control the reductant pump 121.

[0029] The monitored system 102 is electrically coupled or communicatively coupled to the engine 108 and one or more components of the aftertreatment system 103. The monitored system 102 is configured to control the engine 108, such as valve timing, crankshaft rotation rate, etc. The monitored system 102 is configured to control one or more components of the aftertreatment system 103, such as a reductant doser, a hydrocarbon injector, sensor calibration (e.g., applying or providing an offset to sensor measurements based on a change in sensor sensitivity), etc. The monitored system 102 can be in electrical communication with other components of the network system 100.

[0030] In various embodiments, monitored system 102 is electrically or communicatively coupled to monitoring system 104. In some cases, monitoring system 104 may be another controller or component electrically coupled to monitored system 102. In various cases, monitoring system 104 is in remote communication with monitored system 102 and one or more other components of network system 100 (e.g., various modules, sensors, etc.). For example, monitoring system 104 may communicate with one or more components via wired or wireless communications (e.g., Bluetooth, LTE, Wi-Fi, broadcast radio, satellite, etc.). For example, monitoring system 104 may be a server, data processing system, or remote device configured to receive data from a component of network system 100 (such as from monitored system 102).

[0031] The monitoring system 104 includes a processing circuit 134. The processing circuit 134 includes a processor 136 and a memory 138. The processor 136 may include a microprocessor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc. or a combination thereof. The memory 138 may include, but is not limited to, an electronic, optical, magnetic or any other storage device or transmission device capable of providing program instructions to the processor, ASIC, FPGA, etc. The memory 138 may include a memory chip, an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a flash memory, or any other suitable memory from which the monitoring system 104 can read instructions. The instructions may include code from any suitable programming language. The memory 138 may include various modules that include instructions configured to be implemented by the processor 136.

[0032] In some cases, the monitored system 102 is configured to communicate with the monitoring system 104. For example, the monitored system 102 is configured to transmit information from components of the monitored system 102 (e.g., aftertreatment system 103, engine 108, etc.) to the monitoring system 104 for storage or processing. The information may include sensor measurements, timestamps associated with the measurements, indications of various engine operations / events (e.g., motoring events, ignition, fuel injection levels, speed of crankshaft speed, etc.), timestamps associated with engine operation, and other data described herein. In another example, the monitored system 102 is configured to receive or obtain instructions or processed information from the monitoring system 104. The instructions may include, for example, displaying the processed information to an operator via a display device. The processed information may include at least the operating time, remaining service life (e.g., operating duration), and failure time (e.g., remaining time until failure) of the component (e.g., sensor). For example, monitored system 102 may receive other data or instructions from monitoring system 104 to control components of network system 100 or provide information (such as visual feedback, audio feedback, or tactile feedback) to an operator.

[0033] Although not shown, it should be understood that the internal combustion engine 108 includes various components, such as cylinders, pistons, fuel injectors, air intakes, and other similar components. In some applications, the internal combustion engine 108 may include a turbocharger, an exhaust gas recirculation (EGR) system, a waste heat recovery (WHR) system, and / or other similar components. In addition, although not shown, various sensors are included at various locations in the network system 100, such as upstream of the internal combustion engine 108, at the internal combustion engine 108, or downstream of the internal combustion engine 108. The sensors include at least a temperature sensor, a NO x sensor, air flow sensor, etc. For the purpose of providing an example, the monitoring system 104 uses the NO x The signals of the sensors are used to perform features, functions and operations of the technical solution (e.g., component health prediction), although other sensors (e.g., temperature sensors, air flow sensors, ammonia sensors, dosing sensors, etc.) may also be used in similar embodiments.

[0034] In some embodiments, the particulate filter 112 may be positioned downstream of the decomposition chamber 114. For example, the particulate filter 112 and the conversion catalyst 116 may be combined into a single unit. In some embodiments, the dosing module 118 may alternatively be positioned downstream of the turbocharger or upstream of the turbocharger.

[0035] III. Overview of component analysis systems The memory 138 of the processing circuitry 134 may include various circuits (e.g., modules, components, etc.) to perform the features or functions discussed herein. For example, the memory 138 includes at least a data collection circuit 166, a data preprocessing circuit 168, a model development circuit 170, and a prediction circuit 172. The circuits (e.g., the data collection circuit 166, the data preprocessing circuit 168, the model development circuit 170, or the prediction circuit 172) are configured to communicate with each other to process information from components of the network system 100. In some cases, one or more circuits may communicate with an external device (such as another controller, server, or monitored system) to process information. Also in conjunction with Figure 2 The operation of the circuit is described.

[0036] The data collection circuit 166 is configured to receive signals from components of the network system 100. The signals may be associated with data from the components, such as sensor measurements, internal combustion engine events (e.g., sometimes commonly referred to as engine events or operating events), status indicators indicating the operation of the corresponding components (e.g., flags, etc.), or other data discussed herein. Receiving signals may correspond to receiving data, such as the data collection circuit 166 is configured to receive, obtain, collect, or acquire data from components of the network system 100. The data collection circuit 166 may receive data directly from the components or from an intermediate device (such as from a storage device, a telematics unit, or other intermediate device).

[0037] The data collection circuit 166 may obtain data continuously or periodically. For example, in various embodiments, the data collection circuit 166 is configured to receive and store live data from sensors (e.g., or actuators, filters, and other components used to determine the service life of the performance of the corresponding components). The data collection circuit 166 is configured to receive or collect data corresponding to the components, such as for processing and determining the service life of the performance of the corresponding components. In other embodiments, the data collection circuit 166 is configured to obtain data at predetermined intervals (e.g., once a day, once a week, once a month, etc.). In this case, the data can be stored on a local memory storage device of the monitored system 102 or on a cloud storage device uploaded by the monitored system 102, and the data can be obtained by the monitoring system 104. Therefore, the data collection circuit 166 retrieves data from a local or remote storage device at a predetermined time interval (e.g., configurable by an operator of the network system 100 or an administrator of the monitoring system 104). The data collection circuit 166 provides the collected data to the data preprocessing circuit 168.

[0038] In some embodiments, the collected data can be represented as data points in a graph. For example, (e.g., at least in combination with Figure 4The graph (described in the specification) may be represented as a two-dimensional (2D) graph including an x-axis and a y-axis. For simplicity, a 2D graph may be described herein, but other types of graphs, such as a 3D graph, may also be used. Sensor measurements, status indicators (e.g., a flag of an engine event), or information provided by a component may be associated with the y-axis, and a timestamp associated with the data may be associated with the x-axis (or vice versa). The number of data points may be based on the data transmission rate, the measurement frequency, or the amount of data requested by the data collection circuit 166 (e.g., one data point every 0.01 seconds, 0.1 seconds, 0.5 seconds, 1 second, 2 seconds, or 5 seconds). In various embodiments, the collected data includes a sensor offset associated with each data point. The data collection circuit 166 may determine the sensor measurement by applying a sensor offset to the data point, such as applying a first offset to a first data point to determine a first measurement, applying a second offset to a second data point to determine a second measurement, and so on. In various other embodiments, the data collection circuit 166 may obtain sensor measurements to which corresponding offsets are applied from the monitored system 102.

[0039] The data preprocessing circuit 168 is configured to prepare or preprocess data for use by the model development circuit 170 or the prediction circuit 172. The data preprocessing circuit 168 is configured to filter, remove or cleanse the signal from undesirable data. Undesirable data includes, for example, null values, data sampling irregularities (e.g., sampling errors), and other data points with quality issues. Data sampling irregularities may include one or more errors in data sampling. For example, one or more sensors of the engine system may be configured to log data at a corresponding frequency (e.g., 1 Hz, 10 Hz, etc.). In some cases, data pre-processing circuitry 168 identifies, observes, or determines at least one of: a change in a logging rate (e.g., a logging rate that is different than a configured logging rate), one or more missing parameters from a data log (e.g., a log of stored or recorded data from one or more sensors), incorrect values ​​for one or more parameters (e.g., out of range values, and other irregularities in the data), a delay in data reception (e.g., a network connection problem), at least one gap or inconsistency in data received from one or more sensors (e.g., a physical sensor or a virtual sensor) on a timeline. Data pre-processing circuitry 168 is configured to filter data sampling irregularities by monitoring or analyzing logged data such as stored in memory 138 or remotely stored on a remote storage device (e.g., sometimes referred to as a remote data repository, cloud storage device, or external storage drive). For example, data pre-processing circuitry 168 may receive an expected NO indicative of a sensor. xVirtual data of a measurement result (e.g., a reference measurement result). In some cases, the virtual sensor can be, for example, an embedded model on an ECU, a representation of one or more empirical physics equations, or a graph-based model. Expected NO x The measurement results can be based on at least the exhaust gas flow, temperature, fuel consumption, crankshaft spin rate, SCR catalyst NO x The data preprocessing circuit 168 may be used to determine whether the deviation between the two measurements meets a threshold value (e.g., is greater than or equal to a threshold value, or in some cases is less than a threshold value). If the deviation is greater than a threshold value (e.g., exceeds an expected measurement value), the data preprocessing circuit 168 may filter the data point. The threshold value may be predetermined by a manager, such as + / - 20%, + / - 30%, etc.

[0040] The data pre-processing circuit 168 also filters data based on the type of engine event. The data pre-processing circuit 168 is configured to selectively extract data associated with a specific type of engine event or operating condition (e.g., selected by an administrator). For simplicity, data associated with a drive event of the engine 108 may be selected for processing. In some other cases, the data pre-processing circuit 168 may extract data associated with other types of engine events (such as braking events, idle events, regeneration events, and other abnormal conditions (e.g., abnormal events)). Because the type of drive event is selected, the data pre-processing circuit 168 is configured to filter a subset of data that is not associated with the drive event. In various embodiments, the data pre-processing circuit 168 is configured to remove a portion of the data associated with the drive event, such as a specific duration or data sample from the beginning or end of each drive event.

[0041] After filtering / cleaning the data, the data pre-processing circuit 168 aggregates the remaining data associated with the engine event for feature determination. This data may include at least NO x Sensor measurement result, NO x Sensor offset, NO x Sensor invalid state, and deviation between actual measurement results and expected measurement results. Data pre-processing circuit 168 is configured to provide aggregated data to model development circuit 170 for generating or training a model. In some cases, data pre-processing circuit 168 is configured to provide aggregated data to prediction circuit 172 for determining the remaining useful life of the sensor based on feature recognition using the trained model. Figure 2Describes additional operations for preparing and preprocessing the collected data.

[0042] In various embodiments, the data pre-processing circuit 168 is configured to only clip, utilize, or extract data (e.g., sensor measurement data) within an expected (e.g., target) range of a target operating characteristic associated with various measurement results (e.g., a subset of the measurement results) of the measurement data. The threshold (e.g., target threshold) may be configured by an administrator, such as an error of 30%, 40%, or 50% from the target operating characteristic. For example, the target operating characteristic may correspond to an expected characteristic, behavior, measurement result, pattern, or feature of the data point during the driving event. The data pre-processing circuit 168 identifies or determines the operating characteristic of the performance based on the operating data and the measurement results (e.g., the first measurement result or the second measurement result, pattern, or offset). The operating characteristic of the performance may correspond to an actual characteristic, behavior, or feature of the data point during the driving event. The data pre-processing circuit 168 may determine a target deviation (e.g., a measured difference) between the target operating characteristic and the operating characteristic of the performance. The data pre-processing circuit 168 compares the target deviation to a stored target threshold, which may be configured by an administrator of the monitoring system 104 or based on trends (e.g., historical data) of data points associated with other monitored systems.

[0043] Thus, the data pre-processing circuit 168 may use only data points having a performed operating characteristic (e.g., pattern or measurement result) within a target threshold (e.g., less than the target threshold) based on the difference between the target operating characteristic and the performed operating characteristic. In other cases, if the difference between the performed characteristic of the data point and the target characteristic is greater than or equal to the threshold, such as the data point is outside a configured error window, the data pre-processing circuit 168 may filter the data points outside the error range or window. In this case, the measured deviation can be compared to the measured threshold only when the target deviation is less than the target threshold (e.g., within the error window).

[0044] Model development circuitry 170 is configured to generate, develop, or train a machine learning model (e.g., sometimes commonly referred to as a model). Model development circuitry 170 is configured to train the model using one or more machine learning techniques, such as regression, decision trees, random forests, neural networks, and other supervised or unsupervised classification techniques. For simplicity, model development circuitry 170 may generate and train a model to find patterns from input data. In this case, model development circuitry 170 may receive aggregated data as input.

[0045] The model development circuit 170 may receive aggregated data from various systems (e.g., vehicle systems, monitored systems, etc.) having corresponding internal combustion engines and sensors. Similar techniques may be used to filter or cleanse the collection of aggregated data. The model development circuit 170 may use data from a faulty sensor as input for determining a pattern, for example, from the time of installation of the sensor to the time of failure. The model development circuit 170 may group the aggregated data based on comparable operating conditions or environments between individual sensors of different systems. For example, the model development circuit 170 may group the data based on at least one of the following: the location of the sensor within the corresponding system, the type, brand or model of the engine, the duration until failure (e.g., within 2 years, 1 year, or 6 months), the geographic location associated with the system, historical operating characteristics (e.g., temperature exposure, exhaust flow, etc.), fuel type, and other categories.

[0046] In various embodiments, the model development circuit 170 may train a single model or multiple models to detect features associated with aggregated data from various groups. For example, using data from one or more groups as input to the model, the model development circuit 170 may compare patterns, features, or characteristics of sensor excursions over the life of the sensor. The pattern (or group of patterns) may be based on or depend on at least one of the following: one or more failure modes or failure progression rates of the sensor. The model development circuit 170 may compare aggregated data from sensors within multiple similar groups / categories. In this case, the model development circuit 170 may combine various characteristics of sensor measurements or excursions from comparable categories to determine expected patterns associated with these sensors. The model development circuit 170 may reiterate the training operation of the model. The training operation may be combined with at least Figure 2 Describes other operations or details for generating or training a model. Model development circuitry 170 may provide a trained model for use by prediction circuitry 172.

[0047] The prediction circuit 172 is configured to determine the remaining useful life of a sensor (e.g., a first sensor). The remaining useful life may be referred to as the duration until failure, the failure time, or the useful life of the performance of the sensor. For example, the prediction circuit 172 receives filtered or cleaned data of the sensor from the data preprocessing circuit 168. The prediction circuit 172 may input the data into a trained model. The model may be trained using data from other sensors having operating conditions comparable to the first sensor. In some embodiments, the model (e.g., the model development circuit 170 and other circuits of the monitoring system 104) may be adjusted to predict the remaining useful life of the sensor. For example, the model may be adjusted based on, but not limited to, the rated life of the sensor under standard / normal / expected operating conditions (e.g., the operating time indicated in the specifications), the actual operating conditions imposed on the sensor, the failure mode, or the average operating time (e.g., actual life) of one or more comparable / similar sensors associated with one or more engine systems (e.g., overall data of failed sensors). For example, the specifications of the sensor are provided by at least one of a manufacturer of the sensor, an administrator of the monitoring system 104 , a service technician, and other entities that provide sensors for the engine system.

[0048] After the model processes the data from the first sensor (such as comparing the characteristics of the sensor (e.g., offset measurement results) to one or more thresholds (e.g., deviation thresholds) or to characteristics of other comparable sensors), the prediction circuit 172 can at least determine the change in sensor offset over time (e.g., measurement result deviation) or the performance life of the sensor. For example, the prediction circuit 172 can determine that the sensor offset exceeds certain thresholds, indicating the corresponding performance life. In another example, the prediction circuit 172 can determine that the sensor offset follows a similar pattern as one or more comparable sensors. In this example, given the operating conditions of the first sensor, the prediction circuit 172 can determine the performance life based on the failure time of the comparable sensors. It can be combined with at least Figure 2 Describes other operations or details for determining the remaining useful life of the sensor.

[0049] In response to determining the useful life, prediction circuitry 172 is configured to send instructions to monitored system 102 to indicate the useful life of the performance of the sensor (or other sensor analyzed using the model). For example, prediction circuitry 172 may instruct monitored system 102 to present a visual representation of the time of performance (e.g., days, months, or years until failure). In some cases, prediction circuitry 172 signals monitored system 102 to enable a service indicator, such as a recommended sensor replacement for a vehicle.

[0050] Figure 2 A process flow diagram of a modeling process 200 is depicted. Figure 2 The processes, operations, or steps of the modeling process 200 may be performed, operated, or performed by components of the network system 100 (e.g., monitored system 102, monitoring system 104, sensors (not shown), etc.). For example, additional operations or alternative operations of the modeling process 200 may be performed by circuitry of the monitoring system 104.

[0051] Modeling process 200 includes features, operations, or processes performed by one or more vehicles 202 and at least one server 204. One or more vehicles 202 transmit information to server 204 (e.g., monitoring system 104, etc.). Server 204 (or other remote device) performs the operations discussed herein in conjunction with monitoring system 104. For example, server 204 may include one or more circuits similar to monitoring system 104 to determine the state or health of a sensor (e.g., the life of the representation). Server 204 may include other components, features, or functions similar to monitoring system 104.

[0052] Before preparing or processing the data herein, the server 204 (e.g., the data collection circuit 166) identifies or obtains various parameters (e.g., prerequisites or conditions) to which sensor fault prediction is subject. For example, the server 204 (or a model executable by the server 204) may obtain the parameters or configure the parameters through an administrator of the server 204. The operations discussed herein may follow one or more preconfigured parameters. In some cases, the server 204 determines to use certain parameters based on available information from the component. The parameters include or indicate at least a fault mode identification (e.g., fault classification), a physics inferred hypothesis definition (e.g., observation of sensor behavior or sensor measurements during certain engine events), a model performance criterion, a type of input data (e.g., data to be used as input to the model), and a type of output data (e.g., a presentation of results from processing the input data).

[0053] The failure mode indicator indicates the type of failure that the sensor has experienced over time. For example, NO x Sensor failures are classified into various failure modes, such as heater degradation, platinum (P) cracks, P peeling, poisoning, contamination, circuit failure, harness failure, etc. One or more of the failure modes (e.g., heater degradation, Pt shift, or Pt peeling) may be progressive failure modes. Progressive failure modes are observable during their lifetime (e.g., during sensor aging or under certain operating conditions). Progressive failure modes may be identified using historical data of the corresponding sensor.

[0054] The physical inference hypothesis definition indicates at least the type of engine event associated with the input data used to be processed (or trained) by the model. x The sensor is prone to failure due to degradation of the heater element over time. The server 204 (eg, the data collection circuit 166) monitors or receives NO detected during certain engine operation or events. x Sensor output data (e.g., NO with or without sensor offset) x Sensor measurements). An engine event refers to the occurrence of a specific engine mode or operation, such as with an expected amount of byproducts, heat, exhaust flow, etc.

[0055] For example, using NO x Sensors, the engine event may be an occurrence when no byproducts are produced (e.g., a first occurrence, a second occurrence, etc.) or an occurrence when the engine 108 may produce a maximum amount of byproducts. For simplicity, and to provide examples herein, the engine event may be a driving mode of the engine 108 when no fueling occurs within the engine 108, but other types of driving modes may be used, such as during a maximum fueling rate event, a braking mode, etc. For example, NO x The sensor includes multiple internal components (e.g., heater circuits / elements, etc.) that may degrade due to heat (e.g., heater degradation). In this case, if NO x The heater element of the sensor is degraded or damaged, NO x The sensor may output a false / inaccurate NO x ppm value. Therefore, in the absence of NO x During engine events (e.g., no fueling events or conditions), the degradation of NO x The sensor observation can provide NO x An indication of (e.g., early) thermal degradation of a sensor, the degradation of which is NO x The sensor generates NO over time during this engine event x ppm output. Similarly, for other types of sensors (such as temperature sensors), actuation events associated with minimum operating temperature occurrences or maximum operating temperature occurrences may be observed. Thus, the server 204 (e.g., the prediction circuit 172) uses the sensor measurements during these engine events as input to a model (and monitors the sensor response over time) for providing heater degradation or NO fault codes prior to triggering or activating a fault code for the sensor. x Early indication of sensor failure.

[0056] In another example, NO xThe behavior of the sensor in various failure modes (e.g., platinum displacement or platinum peeling) can be determined by NO x An abnormal rate of change (e.g., measurement result or excursion) of a sensor is observed or determined. For example, an abnormal rate of change may refer to a rate of increase exceeding a maximum threshold (e.g., an upper threshold) or decrease below a minimum threshold (e.g., a lower threshold). The server 204 (or other monitoring system) may detect an abnormal rate of change (e.g., an abnormal rate of change) of a sensor by means of NO x Sensor status (e.g., configured NO x For example, over time, the server 204 (eg, using the prediction circuit 172 of the model) may select the NO at a preselected or preconfigured engine event. x The sensor output (e.g., rate of change) is compared to a reference output (e.g., virtual sensor output) to determine the lifetime of the representation. In this case, the virtual sensor can be exposed to similar operating conditions as the physical sensor (e.g., when generating the output). The output value of the virtual sensor can be used as a reference output value of the physical sensor output (e.g., for comparison).

[0057] The type of input data for each physical inference hypothesis includes at least one of the following: NO xMeasurement results, data logging frequency (e.g., the frequency or data rate of sensor measurements during an engine event), damage progression rate, data volume, model execution frequency or historical data conditions, dew point temperature, exhaust gas flow, engine operating conditions (e.g., for identifying braking, acceleration, or other engine events), idle events, virtual sensor outputs, and other parameters related to the operating conditions of the engine system. Historical data conditions include data collected or monitored over hours, days, weeks, months, or other time periods, such as the rate of progression based on a fault mode (e.g., sometimes referred to as a rise in sensor offset). The machine learning model can use historical data conditions as one of the criteria for accurately predicting or determining sensor health. In some cases, the amount of historical data availability can be used as part of the input to the machine learning model to determine the accuracy percentage of the remaining operating time prediction. For example, the data logging frequency reflects the number of data points used as input during a driving event, such as one data point per second associated with a 1 Hz recording frequency. For example, when monitored under specified or controlled operating conditions (e.g., a driving event), a rise in sensor offset can indicate the impact of heater degradation at various points in time, thereby reflecting the progress of damage on the sensor. In another example, a rise in sensor offset may indicate an increase in the deviation of the physical sensor output (e.g., compared to the virtual sensor output), thereby indicating progressive damage on the sensor. The amount of data indicates the minimum amount of data from a single sensor used for training, such as 1 month, 6 months, 1 year, 3 years, 5 years, or 7 years of data before the failure. The model execution frequency indicates the frequency of acquiring data and / or processing data using the model, such as static hourly, daily, weekly, monthly, yearly, etc. In some cases, the frequency of executing the model can be determined based on at least one of the following: the rate of progression of the failure mode, the time to schedule or perform maintenance (e.g., replacement, repair, etc.) on the sensor after notifying the user to perform maintenance on the sensor, etc.

[0058] In various embodiments, the model execution frequency is based on the lifetime of the sensor's performance. For example, based on the prediction results, the server 204 (e.g., the prediction circuit 172) can be configured to re-evaluate the lifetime of the sensor's performance at an intermediate time between the previous execution time and the expected failure time or at a predetermined duration (e.g., 1 year, 2 years, etc.) before the expected failure time.

[0059] The model performance criteria indicate at least the minimum acceptable performance of the model before use or execution. The server 204 can evaluate the model using sample data from various vehicles 202 or monitored systems with internal combustion engines and sensors. The sample data may include a subset of fault sensor history data to enable the model to predict the service life of their performance. The sample data may also include the service life of actual performance, so that the model can compare the life of the predicted performance with the life of the actual performance, and adjust its process or evaluation technology based on the deviation between the life of the predicted performance and the life of the actual performance. The sample data may include other information for training, updating, improving or validating the model. If the model meets the minimum acceptable performance (e.g., the deviation between the predicted result and the actual result is less than a threshold, such as a difference of less than one month for more than 90% of the sample data), the server 204 can use the model to determine the service life of the performance of subsequent sensors (or components) of the monitored system (e.g., the monitored system 102).

[0060] The type of output data includes one or more representations of the model execution results, such as heat maps, notifications, etc. In some cases, the representation of the model execution results (e.g., heat maps, notifications, etc.) can be combined with Figure 7 , Figure 8 or Fig. 9 At least one of is shown. For example, the server 204 (e.g., the prediction circuit 172) can use the model to generate a heat map representation of the results based on one or more (e.g., subsequent or sequential) model executions (e.g., daily, weekly executions, etc.) of the input data to indicate the failure progression of the sensor, which can represent the remaining useful life of the sensor on a timeline. The notification can indicate that the sensor is approaching failure (e.g., 6 months, 3 months before the failure occurs, etc.). The notification can be visual, audio, or any other type of presentation. The server 204 shares the notification with at least one of an operator, a corresponding entity handling component / part replacement, or a manager of the server 204. The server 204 is configured to share the notification before further progression of degradation that triggers a fault code that causes an unplanned downtime for the operator. The model execution results can be presented to various entities in other ways.

[0061] In various embodiments, multiple models may be generated, trained, and tested against each other for performance evaluation. In certain embodiments, a manager, technician, or engineer may evaluate the performance of the model in terms of fault mode identification and determine true positives and false positives of the output results. In this context, the server 204 (e.g., circuit) may perform operations based on or according to a parameter to determine the health of a component.

[0062] Based on the above parameters, the server 204 is configured to generate, train, update, or execute one or more machine learning models discussed herein. The server 204 (e.g., data collection circuitry 166) is configured to receive or obtain data from various vehicles 202, such as directly from sensors (e.g., components of interest) or through an intermediary (e.g., monitored system 102) (206). The data includes data from components of interest (e.g., NO x The data includes engine sensor data (208). The data includes engine sensor data (210). The engine sensor data indicates any operation of the sensor, such as fuel supply operation (or no fuel supply), crankshaft rotation, and other information associated with the engine 108 to indicate the occurrence of a driving event. The data also includes other related data (212). The related data includes at least a timestamp of the operation time between the synchronized engine sensor data and the sensor data, the installation date of the sensor, the type of sensor, the type of engine, and other data used in this document.

[0063] The server 204 is configured (214) based on the physical inference assumptions. The physical inference assumptions may indicate the type of engine event (e.g., actuation event) used for model development. As shown, such as in operations (222) or (224), based on the physical inference assumptions, the server 204 may extract a subset of data associated with the actuation event. For example, the server 204 may be combined with Figure 3 Data extraction based on physical inference assumptions is described in more detail.

[0064] In various implementations, the server 204 utilizes a physical inference assumption in the model (or one of the models). The physical inference assumption may refer to or correspond to one of the assumptions used by the model to determine the failure time of the sensor. For example, the server 204 monitors the sensor offset (e.g., NO) during an engine event (e.g., a driving event) for a predetermined duration. x Sensor offset). Assuming that the monitored sensor offset indicates thermal degradation or poisoning of the sensor, the sensor 204 can use the offset to predict or determine the failure time or the demonstrated useful life of the sensor.

[0065] In some aspects, server 204 utilizes additional or alternative assumptions (e.g., physical inference assumptions) in the model. For example, as an assumption, the NO monitored over a certain period of time (e.g., days, weeks, months, etc.) is stable. x The reading or measurement and the O2 reading or measurement may indicate that the sensor (e.g., NO xSensors) are poisoned so as to predict sensor failures based on "persist not valid" in advance (eg, a predetermined time in advance from the occurrence of failure).

[0066] Server 204 uses the collected data and performs data preparation or preprocessing according to physical inference assumptions (216). For example, server 204 (e.g., data preprocessing circuitry 168) can detect data quality issues, such as null values ​​or data sampling irregularities (e.g., sampling errors) (218). Before further processing the data, server 204 can address or resolve data quality issues by filtering null values ​​or sampling irregularities, such as using any data filtering techniques to remove null values ​​and irregularities.

[0067] In addition, the server 204 performs physical inference feature engineering by aggregating the filtered data for feature determination (220). For example, the server 204 determines the NO during the driving event based on the indication from the physical inference hypothesis. x Sensor offset. Server 204 determines NO x The server 204 determines the actual NO under the associated operating conditions (eg, temperature, exhaust gas flow, fuel consumption, etc.). x Sensor output and virtual NO x Deviations (eg, errors) between sensor outputs. Sensor offsets, invalid states, biases, and other variables may be part of the features determined by the server 204 based on physical inference assumptions.

[0068] In response to the physical inference feature engineering, server 204 maps the aggregate features on a timeline (eg, a graph, a table, a chart, etc.). x When aggregating features of the sensor failure occurrence, server 204 can identify or detect certain outliers within the data points on the timeline (222). In some cases, the aggregation of features regarding the failure occurrence includes sensor offsets during a (e.g., qualified or approved) engine event, where the sensor offsets are aggregated for the duration of the engine event (e.g., the mean of the offsets calculated over the duration of the engine event without waiting time). In some cases, the aggregation of features regarding the failure occurrence includes an aggregation based on a percentage error calculation of samples under certain operating conditions. For example, server 204 detects outliers based on operating conditions such as exhaust flow, fuel supply, or NO xThe response of the sensor during at least one of a braking event, an engine idle, a catalyst regeneration event, etc. In this case, any operating conditions or events that are not driving events can be discarded from training or validation. In this way, the server 204 (e.g., the data pre-processing circuit 168) is configured to remove outliers (224) from the filtered data to be used as input. The server 204 can use any data filtering technique or outlier detection technique to detect and remove other outliers to avoid or minimize false positive or false negative results.

[0069] After preparing or preprocessing the data, server 204 (e.g., model development circuit 170) is configured to develop and train at least one model (226). To develop the model, server 204 generates a training data set (228) having expected samples and abnormal samples. For example, in response to the start of a driving event (e.g., engine driving), NO x The sensor measurement drops to its offset value (e.g., within ±10 ppm for a healthy sensor) after a predefined duration (e.g., 2 seconds, 5 seconds, 10 seconds, etc.). During engine driving, no NO generated by the engine is expected since no fuel is supplied. x Thus, after a predefined duration (e.g. derived from the specifications of the sensor, such as from the manufacturer, to allow the sensor to activate or wake up and respond to changes in fuel supply), when driving begins, NO x The measurement result of the sensor represents or reflects the offset value applied to the sensor.

[0070] An offset value refers to a calibration value applied to a sensor over time, such as due to progressive degradation of the sensor (e.g., increase or decrease in sensitivity of the sensor), damage to the sensor, poisoning of at least a portion of the sensor (e.g., a heater element or circuit), water intrusion into a portion of the sensor, etc. For example, an offset value may be applied by a technician during a service session, automatically by monitored system 102 based on expected degradation of the sensor over time, or by an administrator of server 204. Thus, when a drive begins, a positive or negative NO value after a predefined time (e.g., a calibrable time) may be applied. x The sensor readings are attributed to positive or negative offset values ​​(e.g., offset errors), respectively. Thus, the server 204 can classify the pre-processed data into at least expected samples and abnormal samples based on whether the offset value of each data point is equal to or exceeds a threshold value (such as ±10ppm or any configurable amount). NO of healthy sensors or faulty sensors x Examples of offset values ​​can be at least Figure 3 and shown in Figures 5-6.

[0071] Once the training data set is generated, the server 204 (eg, the model development circuit 170 ) sends the training data set (eg, having NO x The server 204 may train the model accordingly (230) by feeding the training data set and providing the model with an indication that the data set is a training sample. Because the training data set (e.g., training sample) is validated or includes corresponding known health states associated with the measured values, the model may be trained to recognize features of subsequent samples (e.g., real-world samples). The model may extrapolate features determined based on physical inference (e.g., NO during a driving event) in the time domain. x sensor drift) to predict the remaining useful life of a component. For example, where the model predicts or determines that a sensor will fail, the remaining useful life can be output. If the model does not identify a potential failure of the sensor, or if the remaining useful life is above a threshold (e.g., days, weeks, months, years, etc.), the model can output an indication of a healthy sensor without providing a specific time for the remaining useful life.

[0072] Once trained with the training samples, the server 204 evaluates the model performance on the second training data (232). In this case, the training samples (e.g., first training data) refer to the data set used to train the model (e.g., including features with a known healthy state before a failure occurs), and the second training data refers to the training data used to evaluate the model (e.g., including features without a healthy state). The second training data can be real-world data obtained from various faulty sensors. In some cases, the second training data can be created based on an aggregation of multiple real-world data for evaluation purposes. The server 204 can evaluate the model using various testing or evaluation techniques. For example, the server 204 inputs the second training data and instructions for performing a health prediction process to the model. The server 204 can receive an output from the model executing the second training data. The output indicates the useful life of a first representation of the sensor associated with the second training data. The server 204 compares the useful life of the first representation with the useful life of the second representation indicating the actual length of time until the sensor fails. The server 204 repeats this process for various iterations (eg, 10 times, 50 times, 100 times, etc. configured by an administrator), for example, until a predicted sensor fails and / or a sensor of the engine system is replaced, thereby resetting the sensor's historical operating data or restarting execution of the model.

[0073] The server 204 aggregates the results from the evaluated models to determine whether the model performance is satisfactory (234). For example, the server 204 (e.g., the model development circuit 170) determines the performance of the model based on a ratio or percentage of the time (in various iterations) that the useful life of the first representation is within a predetermined duration (e.g., 1 year, 6 months, 3 months, etc.) of the useful life of the second representation. In various embodiments, the server 204 determines the performance as an aggregate score based on the deviation between the useful life of the first representation and the useful life of the second representation for each iteration. Each iteration may be assigned a score (e.g., 0 to 5, 0 to 10, 0 to 100, etc.) based on the respective deviation between the useful lives of the representations. The scores associated with the respective deviations may be configured by the administrator. For example, a score of 0 / 5 corresponds to a deviation of more than 1 year, a score of 1 / 5 corresponds to a deviation of 10 months to 1 year, a score of 2 / 5 corresponds to a deviation of 8 months to 10 months, a score of 3 / 5 corresponds to a deviation of 6 months to 8 months, a score of 4 / 5 corresponds to a deviation of 4 months to 6 months, and a score of 5 / 5 corresponds to a deviation of less than 4 months. The server 204 aggregates the scores to determine the performance as a ratio or percentage. In some cases, aggregation of scores can be part of a model (e.g., the execution of a model).

[0074] The server 204 compares the performance to a performance threshold, which can be configured, for example, as 85%, 90%, 95%, etc. The performance threshold can be configured by an administrator. If the performance does not meet the threshold (e.g., is below the threshold), the server 204 performs a design of experiments (DOE) (or other analysis of the training data set and model) (248). By performing the DOE, the server 204 is configured to identify additional or alternative physical inference features and operating conditions (e.g., engine events), such as additional sensor offset values ​​during a braking event, or further filtering the current sensor offset value (e.g., current data point) during a driving event. Examples of further filtering data points may include making one offset measurement represent a corresponding driving event, or performing other filtering techniques to identify erroneous data points. Therefore, the server 204 is configured to return to prepare or pre-process additional data or the current data set to redevelop and retrain the model.

[0075] If the performance meets the threshold (e.g., is equal to or above the threshold), the server 204 performs a validation process on the model (236). For example, the server 204 (e.g., the model development circuit 170 or the prediction circuit 172) executes the model on the validation sample (238). The validation sample can be real-world data or generated based on real-world data of the faulty sensor. For example, the model executes the validation sample similar to the second training data. The validation sample can be associated with a corresponding known healthy state, where the output of the model is compared to the known state. For example, the training data can correspond to data from one or more (e.g., comparable or similar) sensors, which is generated from known samples or identified samples that have a healthy state, are processed to an unhealthy state until the sensor fails. For example, the validation sample can include samples from NO x New or additional data sets for sensors, the NO x The sensors are from one or more engine systems of the same engine type / series / model, where the engine systems experience similar duty cycles or operate at similar duty cycles during similar monitoring periods. In this case, after the model (or other similar models) predicts the health state of the sensors associated with the one or more engine systems, the samples can be tested (e.g., laboratory tested) to classify the samples as true positives or false positives, thereby evaluating model performance and adjusting the model.

[0076] In response to executing the model, server 204 sets a model output notification mechanism (240). The model output notification mechanism refers to an output type that indicates the performance of the sensor's useful life or whether the sensor is close to failure. The output notification mechanism includes at least one of a push notification, a graphical interface, an audio notification, etc. In some cases, the output notification mechanism includes a heat map generated based on various executions of the model (such as daily, weekly, semi-weekly, monthly, etc. executions).

[0077] In various embodiments, the server 204 receives an indication of a part replacement (e.g., a sensor has been replaced) (242). The number of sensor operating hours can be used as an indicator of a part replacement and to reset historical data associated with a previous or replaced sensor. In some cases, the previous sensor can be tested or evaluated (e.g., by a laboratory) for true positive result classification or false positive result classification to further train the model. If the sensor is replaced, the historical data of the previous sensor can be reset, transferred, or removed from further predictions (e.g., to avoid combining old and new sensor data). For example, the server 204 resets the model by removing the historical data associated with the previous sensor. Subsequent historical data of the installed sensor can be collected as input to the model for component health prediction.

[0078] In some embodiments, the server 204 determines whether the model performance meets or complies with acceptable exit criteria (244). For example, the model may generate one or more heat maps as part of the model output. The model may determine a rolling sum (e.g., a sum of a sequence of numbers) based on the encoded heat map (e.g., a heat map converted to values) for additional or final classification of the model output. The model may compare the rolling sum with the actual health state of the sensor (e.g., historical data of a faulty sensor), where the activation of a fault code may be set as an exit criterion. For example, when a fault code is activated (or a laboratory test is performed), the sensor is confirmed to be faulty. For example, because the model is developed to predict faults before a fault code is actuated or triggered, the fault code may be set as part of the exit criteria to classify the sample as a true positive or a false positive. If the model performance does not meet the exit criteria, the server 204 proceeds to operation 248. In other cases, the server 204 proceeds to operation 246. It may be combined with at least Fig. 9 An example of a heat map is shown.

[0079] In some embodiments, the exit criteria include at least a performance threshold (e.g., similar to operation 234), such as comparing the results from processing the validation sample to the threshold. The exit criteria also include at least a valid model output notification mechanism (e.g., based on whether the vehicle 202 supports the mechanism, such as whether it has a display device, an audio system, etc.), which is configured to notify the user of the useful life of the performance. The exit criteria include any other thresholds or parameters that can be configured by the administrator. In some cases, the exit criteria include existing diagnostic flags recorded in a data repository (e.g., memory 138).

[0080] If the model performance meets the exit criteria, the server 204 outputs or enables the model for utilization (246). The exit criteria may be indicators of model accuracy, precision, or other satisfactory conditions that are qualified or predetermined to be accepted. Thus, when the model performance meets the exit criteria, the server 204 (e.g., one or more circuits) may utilize the model to determine the health of the sensor or the life of the performance. Subsequently, the server 204 (and other servers, processors, or controllers) may use the trained model to predict component health. The server 204 may output a single model for various components. In various embodiments, the server 204 may output multiple models, each associated with a type of component, a type of engine 108, or other type of parameter. Thus, the server 204 may use the trained model to predict the health of the sensor.

[0081] In some embodiments, the server 204 (e.g., the model development circuit 170) is configured to generate multiple models based on different sets of training data, collected features, or engine events. The server 204 can generate an ensemble model by integrating the individual models to predict any progressive damage-based failure mode of the sensor. The integration of various models can enhance model performance. Because one or more models are developed based on physics (e.g., in addition to or instead of empirical or population-based model development, the assumptions used in the model can be based on physical formulas and knowledge based on chemical reactions), the model can be engine platform and component agnostic (e.g., can be executed for any engine platform, component manufacturer, etc.).

[0082] refer to Figure 3 , depicting an example graphical representation 300 of internal combustion engine events and measurement data. The operations discussed herein may be performed by the monitoring system 104, the server 204, a server, etc. Figure 1-Figure 2 Description Certain operations are discussed herein. Diagram 300 includes drive events 302A-302N (e.g., sometimes referred to as drive events 302) plotted on a graph. The x-axis of the graph represents time, and the y-axis represents an indication of the drive event 302 (e.g., bits 0 and 1 indicating the drive event). For example, the motor sensor provides a bit 1 (or 0) at the drive start time, and provides a bit 0 (or 1) at or after the effective drive end time.

[0083] In order to avoid or minimize the collection of data that does not represent sensor excursion during the drive event 302, the server (e.g., server 204 or monitoring system 104) is configured to filter a portion of the sensor data associated with the drive event. For example, the server 204 (or monitoring system 104) is configured with a waiting time of a certain duration, such as 1 second, 2 seconds, etc. The server 204 filters the sensor data during the waiting time starting from the drive start time. In addition, the sensor is configured to discard at least one sample in the drive event 302 before the effective drive end time. For simplicity, the sensor can be configured to collect data at a frequency of 1 Hz, so that each sample is recorded every second. Therefore, the server 204 is configured to discard the data from the last second of the drive event 302. In various embodiments, the server 204 is configured to discard a certain drive event 302, which, for example, occurs in a time less than the waiting time, has less than a predetermined number of samples, or has only one sample after the waiting time.

[0084] Once at least one of the last samples at the end of the driving event and the samples during the waiting time are filtered, the server 204 can collect data points (e.g., sensor offset values) of the sensor during the driving event 302. The server 204 uses the collection of data points to monitor the trend (e.g., characteristics) of the offset value over time, such as shown in the graph 304. The graph representing the change in the offset value over time can be shown at least in Figures 5-6. The server 204 is configured to input the sensor offset value into a machine learning model to predict the health condition.

[0085] In various embodiments, as shown in graph 304, the server 204 is configured to collect or extract data points associated with driving events from the sensor data. The server 204 executes a model to monitor trends in data points (e.g., sensor offset values) over time. The trend of the data points may indicate, for example, an increase in sensor offset due to degradation of the sensor (e.g., caused by exposure to heat, poisoning by exhaust byproducts, etc.). Based on the increase or fluctuation in the offset (e.g., an increase or decrease in the offset value), the model executed by the server 204 may output a prediction of a failure time or remaining useful life of the sensor. Herein, the operations performed by the server 204 may correspond to or be associated with the operations performed by the model, which is executed by the server 204. For example, the graph 304 shows that when the heater element of the sensor is degraded, the NO x Sensor drift increases over time.

[0086] For example, the server 204 may determine a deviation (e.g., a measurement deviation) between a first offset value (or a first sensor measurement) at one occurrence of a driving event and a second offset value (or a second sensor measurement) at another occurrence of the driving event. Based on a time difference between the two occurrences (such as a duration between two data points) and an aggregate operating condition (e.g., temperature, exhaust flow, exhaust gas concentration, etc.) to which the sensor is exposed, the server 204 is configured to obtain or determine a threshold. The threshold indicates an expected change in sensor offset between two occurrences (e.g., two timestamps) based on at least one of the operating time of the sensor at the two occurrences, the operating condition exposure, an offset value associated with the two occurrences (e.g., higher or lower than an expected value given the operating condition and operating time), and other variables.

[0087] The server 204 is configured to compare the deviation to a threshold. If the deviation meets the threshold (e.g., the deviation is greater than or equal to the maximum (expected) offset deviation or less than or equal to the minimum offset deviation), the server 204 can determine that the sensor is unhealthy. Therefore, based on various parameters, the executed model is configured to output a failure time or a performance life of the sensor based on various parameters, including the total operating time of the sensor, the degree of measurement deviation, the offset value (e.g., at least one of the first sensor measurement result or the second sensor measurement result), or other information associated with the sensor measurement. If the deviation does not meet the threshold (e.g., the deviation is less than the maximum offset deviation or greater than the minimum offset deviation), the server 204 is configured to indicate that the sensor is healthy. In some cases, if the threshold is not met, the server 204 can be configured to provide a predetermined performance life based on at least one of the operating time of the sensor, the current offset value, and other sensor data.

[0088] refer to Figure 4 , shows an example NO during engine driving for a faulty sensor x Sensor response. As shown, the diagram includes a graph 400A and a graph 400B. Graph 400A includes NO x Sensor readings (e.g., Exhaust Output (EO) NO x ). The NO x Sensor readings can come from virtual NO x sensor, the virtual NO x The sensor outputs an expected NO based on various operating conditions of the network system 100 (or any other system having an internal combustion engine and sensors). x Sensor readings. In some cases, NO x Sensor readings can come from physical NO x The graph 400B includes EONO represented by bit 1 and bit 0 during the same ECM operation time. x Status and drive flags (e.g. for activation or inactivation, enabled or disabled, and vice versa).

[0089] The drive flag indicates the start and end of a drive event. Sections 402A-402D (eg, sometimes referred to as section 402) represent a drive event. At section 402, during a drive event, NO x The sensor measurement drops to 0. In addition, NO x Output EO NO x The sensor status monitoring indication may be zero. However, in graph 400B, the NO x Sensor for EO NO xThe status output has a constant 0 reading, which indicates NO x The sensor is faulty. For example, for a healthy sensor, EO NO x The state may be 1 outside of the driving event 402 and may be 0 during the driving event 402. Because one or more components of the aftertreatment system 103 (eg, reductant doser, catalyst, etc.) rely on at least the EO NO x state, so erroneous outputs may result from inaccuracy or misconfiguration, adjustment, or activation (or inactivation) of these components, resulting in byproduct escape. Therefore, the systems or components discussed herein (e.g., monitoring system 104, server 204, etc.) may execute one or more models to indicate the health of the sensor before a failure occurs.

[0090] Figure 5A-Figure 5C Depicts NO x Graphs 500A-500C of example expected measurements of sensors. Unhealthy NO sensors may be identified based on the presence of corresponding activated sensor fault codes. x The graphs 500A-500C represent various features calculated based on healthy NOx sensor data (without active sensor fault codes). The graphs 500A-500C include features related to healthy sensors (e.g., NO x sensor, engine sensor, virtual sensor, etc. In this case, the data point represents the data point associated with NO x The expected rate of change of the sensor output is NO x Sensor response. The x-axis of the graphs 500A-500C corresponds to operating time (eg, operating time of one or more sensors, engines, or other associated components). For example, the server 204 (or monitoring system 104) is configured to receive and plot information from at least one NO x Graph 500A includes data points indicating NO for a healthy sensor. x A data point showing the percentage of sensor invalid states activated or enabled trends. Based on physics (e.g., physics inference assumptions), the sensor can be expected to exhibit at least one invalid state during operation. The percentage of sensor invalid states (e.g., in combination with other relevant features such as driving model percentage, engine duty cycle, physical NO x Sensors and Virtual NO xO2 error between sensors, etc.) are used to determine the health state of the sensor via application of a model (e.g., these characteristics can be used as inputs to the model). For example, for a healthy sensor, the dead state aggregated over time can be below 50%, 40%, or 30%. If the sensor's heater element degrades, the sensor may not be able to control its internal temperature near a target value, such as if the sensor's response to exhaust flow changes. In other failure modes, such as electrode poisoning, the sensor's internal control loop may not maintain stability, which can be detected via the output of a NO x The controller receives status information and observes it.

[0091] Graph 500B includes an indication of the physical NO x The O2 measurement from the sensor is compared with the O2 measurement from the virtual NO x The percentage of deviation (i.e., error percentage) between the O2 measurements of the sensors is the data point. Virtual NO x The sensors perform measurements based on various operating conditions of the network system 100, such as exhaust flow, exhaust temperature, fuel consumption, etc. For healthy sensors, as shown from 5,000 hours to 35,000 hours, the deviation may be equal to or lower than about 10% (eg, 9%, 11%, 12%, etc.).

[0092] Graph 500C includes data points indicating drive mode percentages associated with the data points of graphs 500A-500B. For example, the drive mode percentage may represent how often (e.g., how often) the engine 108 was operated in the drive mode between engine start and engine stop events (e.g., during a single trip or ignition of the engine 108 until stop). The data points of graphs 500A-500B may be collected during at least a portion of a drive event, such as shown in graph 500C.

[0093] Reference now Figure 6A-6C , depicting NO x Graphs 600A-600C of example abnormal measurements of sensors. Unhealthy NO x The sensor may be identified based on the presence of a corresponding active sensor fault code. Graphs 600A-600C represent the presence of an unhealthy NO with an active sensor fault code. x Various features calculated from sensor data (e.g., showing healthy NO x 500A-500C). Certain elements of graphs 600A-600C (e.g., the types of data points) may be at least similar to graphs 500A-500C. For example, graph 600A shows NO for an unhealthy sensor. x600A, graph 600B shows the percentage of deviation between the physical sensor measurement and the virtual sensor measurement of O2 (e.g., compared to graph 500B), and graph 600C shows the percentage of driving events (e.g., compared to graph 500C). In addition, graphs 600A-600C include the activated NO x A sensor fault indicator to indicate a sensor fault (eg, a malfunction or error of a sensor). In various implementations, at least one of the graphs 600A-600C may be described in conjunction with at least a graph 800 indicating offset data for representing a remaining useful life or an apparent useful life of a sensor.

[0094] As shown in graph 600A, NO changes with time. x The sensor invalid state percentage may output an abnormal response during a driving event (e.g., shown in conjunction with graph 600C). In this case, over time, the aggregate invalid state may exceed 50% of the total number of occurrences, where the sensor failed at approximately 22,500 hours of total operating time. Each data point may represent a merger of data during each execution of the engine 108 and sensor. For example, based on NO x A failure mode of a sensor, one or more features may be used to develop or train a model to predict the failure based on the underlying physics.

[0095] In addition, as shown in graph 600B, during the driving event of graph 600C, the deviation between the measurement results from the physical sensor and the virtual sensor increases over time (e.g., from 0 hours to 20,000 hours). For example, the abnormal deviations at least at about 2,500 hours, 9,000 hours, and 16,500 hours of operation time correspond to error percentages of about 12.5%, 16%, and 17.5%, respectively. The server 204 is configured to compare the deviation with a threshold. If the threshold is configured as 15%, the deviation results at least at 9,000 hours and 16,500 hours of operation time can be used to determine the performance service life of the sensor. For example, based on the operation time and various operating conditions or environments (e.g., historical data) of the internal combustion engine system to which the sensor is exposed during the operation time, the server 204 can determine the performance service life of the sensor. At 16,500 hours of operation, the server 204 can determine the performance service life as about half of the performance service life of the sensor at 9,000 hours of operation, taking into account similar deviation percentages and operation time. In this example, using the trained model, the usage time of the representation at 16,500 may be approximately 6,000 hours. In another example, if the deviation percentage is approximately 20% at 16,500 hours of operation, the server 204 may determine a lifetime of another representation that is lower than the lifetime when the deviation percentage is 16%, such as approximately 4,000 hours, 4,800 hours, 5,000 hours, etc., based on various operating conditions exposed to the sensor. Figure 7 An example of model accuracy associated with a predicted or determined lifetime (eg, time remaining) of a sensor is shown. Additional or alternative operations for determining the remaining lifetime of a sensor may be described herein (such as in Fig.10 Description.

[0096] refer to Figure 7 , plotting example prediction accuracy and NO x A graph 700 of the remaining time of a sensor (e.g., or other component of an engine system). Operations associated with or used to generate the graph 700 may be performed by one or more components of the network system 100 (e.g., the monitoring system 104, etc.), the server 204, the network, the data processing system, the cloud computing environment, or any combination thereof. Figure 1-Figure 3 700 illustrates the predicted remaining operating time of a sensor and the associated prediction accuracy over time. In this case, the time in the x-axis includes the corresponding month of the prediction. The left y-axis includes the percentage of prediction accuracy. The right y-axis includes the predicted remaining time (e.g., operating time) of the sensor, such as the number of remaining operating days.

[0097] For example, the server 204 collects or monitors data related to the sensor. Using a model (or more models), the server 204 determines or predicts the remaining operating time of the sensor. Associated with each prediction of the remaining time, the server 204 determines (e.g., as part of the model output) a percentage accuracy of the prediction, such as based on the similarity of the monitored data compared to other comparable engine systems with similar sensors. In some cases, the server 204 determines the percentage accuracy based on the amount of data collected from the sensor, so that, for example, more sensor data can lead to more accurate predictions. In various embodiments, the server 204 determines the percentage accuracy using the following formula: Percent Accuracy = 100-abs[(ECM operating time at actual fault-ECM operating time at predicted fault) * 100 / ECM operating time at actual fault]. As shown, after predicting a fault in the 4th month, the fault code of the sensor becomes active in the next month.

[0098] Figure 8 Yes NO x A graph 800 of an example remaining life (e.g., remaining useful life or expressed useful life) of a sensor based on a monitoring offset. Operations associated with or used to generate graph 800 may be performed by one or more components of network system 100 (e.g., monitoring system 104, etc.), server 204, a network, a data processing system, a cloud computing environment, or any combination thereof. Figure 1-Figure 3 800 may be executed, performed, or otherwise implemented by any other computing device described herein. Graph 800 may be generated by server 204, for example, using a query from a fault NO. x In this case, as the data from the sensor is processed, the server 204 (eg, using a model) performs a prediction of the health state or remaining useful life of the sensor.

[0099] Graph 800 shows an x-axis including engine operating time (e.g., in hours or other time instances). Graph 800 shows predicted remaining useful life (RUL) time (e.g., in hours) over time associated with the left y-axis. Graph 800 shows sensor offset (e.g., in ppm) over time associated with the right y-axis. The data points of graph 800 are associated with at least one of: output from a model, monitoring data from a sensor (or other component), or a signal from an ECM indicating an active or inactive fault code.

[0100] For example, graph 800 shows an example of heater degradation (e.g., thermal degradation on a heater element of a sensor). For purposes of providing an example, a fault sensor associated with sensor data may be installed on the engine outlet side (e.g., located downstream of the engine), the engine system includes a highway heavy-duty diesel engine, and is operated on average for approximately 10 hours per day. As shown, the offset of the sensor during a driving event may increase over time because the predicted remaining useful life of the sensor decreases over time. At approximately 11,180 hours of engine operating time, a fault code is activated. Server 204 predicts a fault of the sensor before the fault code is triggered. In this case, server 204 predicts a sensor fault (e.g., indicating that the remaining useful life of the sensor is less than 30 hours), for example, at approximately 11,150 hours of operating time.

[0101] refer to Fig. 9 , depicting NO associated with different systems x Heat map 900 of an example health status of sensors. Heat map 900 includes similar sensors associated with different engine systems (e.g., shown as engine 1, engine 2, and engine 3). Operations associated with or used to generate heat map 800 may be performed by one or more components of network system 100 (e.g., monitoring system 104, etc.), server 204, a network, a data processing system, a cloud computing environment, or any combination thereof. Figure 1-Figure 3 or any other computing device described herein.

[0102] For example, the server 204 (or other server or data processing system) is configured to determine the health of the sensor by executing a model (or models). The server 204 determines or predicts the sensor health of one or more engine systems (such as engine 1, engine 2, or engine 3). The sensor health may correspond to the remaining useful life of the sensor, which may be one of various forms of output generated from the model. For example, the remaining useful life indicates the deterioration of the sensor health over time. When the sensor health of different engine systems is predicted based on at least one of the remaining useful life predicted by the model or the preference / configuration on the advance notice (e.g., 30 days, 60 days, 90 days, etc. configured by the user), the server 204 (or the model) generates a heat map 900, which shows the state of the corresponding sensor health as at least one of "healthy", "close to unhealthy", or "unhealthy". Based on the sensor health, the server 204 is configured to recommend or indicate an action (e.g., maintenance or service action) to be performed on the sensor (and other components associated with the monitoring data). The action includes at least one of the repair of the sensor, the replacement of the sensor, or other actions to avoid sensor failure. In various implementations, server 204 may provide email notifications or integrate with a portal (eg, accessible to a user via authentication credentials) to display predictions for sensors to consume the output of the model to the user.

[0103] Reference now Fig.10 , depicts a flow chart of an example method 1000 of a physical inference prediction method for component health prediction. The example method 1000 may be performed by one or more components of the network system 100 (e.g., the monitoring system 104, etc.), the server 204, the network, the data processing system, the cloud computing environment, or any combination thereof. Figure 1-Figure 3 The method 1000 includes receiving a signal at step 1002. At step 1004, the method 1000 includes determining a first measurement result and a second measurement result. At step 1006, the method 1000 includes determining a measurement deviation. At step 1008, the method 1000 includes comparing the measurement deviation to a threshold. At step 1010, the method 1000 includes determining whether the measurement deviation meets the threshold. At step 1012, the method 1000 includes determining a useful life of the representation.

[0104] Still refer to it in more detail Fig.10In step 1002, a server is configured to receive a signal from a monitored system (e.g., at least one component of a monitoring sensor and an engine of the monitored system 102 or the network system 100). The server includes at least one processor coupled to at least one memory storing instructions that, when executed by the processor, cause the server (or a model executed by the server) to perform operations discussed herein. The operations performed by the server may include, correspond to, or be part of the execution of the model. The monitored system includes at least an internal combustion engine (e.g., engine 108), a sensor (e.g., NO x The monitored system may be a part of a vehicle. The engine control unit is configured to control or monitor the operation of the engine, such as engine events, operating states, etc. The engine control unit may include at least one engine sensor for identifying certain engine events (e.g., driving events). In some cases, the engine control unit may perform similar features to a telematics unit, such as collecting information associated with at least the engine and the sensors and forwarding the information to a server for processing.

[0105] The server may periodically or continuously receive a signal (e.g., a first signal) from a first monitored system. For example, the server may receive the signal at predetermined time instances (such as every hour, every day, every week, etc.). In another example, the server may continuously receive the signal in response to new activity driven by a sensor or an engine sensor. Upon receiving the signal from the monitored system, the server obtains or identifies one or more occurrences of an internal combustion engine event (e.g., a drive event, sometimes commonly referred to as an engine event) of the monitored system. For example, the server identifies a first occurrence of the internal combustion engine event and a second occurrence of the internal combustion engine event. In addition, the server identifies measurement data of the sensor based on the signal. The measurement data indicates or includes an amount of exhaust byproducts associated with the monitored system, such as NO x Measurement results, O2 measurement results, etc. In some cases, the measurement data indicates sensor invalid status, sensor offset value, and x At least one of the other outputs or responses of the sensor.

[0106] At step 1004, the server is configured to determine various measurement results (eg, NO, etc.) based on the measurement data based on the corresponding occurrence of the engine event (eg, during the driving event). x Measurement result or NO xThe server may determine various measurements associated with corresponding occurrences of engine events based on the measurement data. For example, the server determines a first measurement based on the measurement data based on a first occurrence of the engine event. The server determines a second measurement based on the measurement data based on a second occurrence of the engine event. These occurrences refer to different time instances when the engine is operating in a drive mode (or other types of engine events configured by an administrator of the server). In this context, the first occurrence may occur at a time prior to the second occurrence, such that the server may identify a change in the measurement from the first time (e.g., the first occurrence) to the second time (e.g., the second occurrence). The measurements that occur may be plotted or mapped, such as at least Figure 3 At least as shown in graph 304 .

[0107] At step 1006, the server is configured to determine a measurement deviation (e.g., a change, increase, or decrease) between the first measurement and the second measurement corresponding to the occurrence of the engine event. During the driving event, the first measurement may increase, decrease, or remain at approximately the same level as the second measurement. For example, the measurement may indicate a sensor offset because no NOx is generated from the engine during the driving event. x . Thus, the measurements from the sensor during these driving events correspond to an offset value applied or calibrated to the sensor over the life of the sensor. For example, a sensor may be more or less sensitive over the course of its operation (e.g., due to progressive degradation). Certain calibration systems may apply an offset to the sensor to account for changes in sensitivity, such as for accuracy during the production of exhaust byproducts (e.g., for adjusting reductant dosing, hydrocarbon injection, etc.). Thus, changes in the sensor offset value over its life can at least indicate the progression of degradation on the sensor, loss / gain in sensor sensitivity, and (e.g., through use of the machine learning models discussed herein) the sensor's (e.g., remaining) useful life or failure time.

[0108] At step 1008, the server is configured to compare the measurement deviation between the two measurements (e.g., or the aggregate measurement deviation between more than two measurements) to, for example, a predetermined / stored threshold or a determined threshold. The measurement threshold may be associated with the amount of the exhaust byproduct. Comparing the deviation to the threshold may indicate whether the change from the first measurement at the first occurrence to the second measurement at the second occurrence is greater than or less than an expected rate of change, a predetermined error percentage (e.g., for a certain operating time of the sensor), or other error range configured for the sensor. In some cases, the server may select the measurement threshold based on the exhaust byproduct, such as how much exposure (or operating time) the sensor is caused by various operating conditions of the vehicle system.

[0109] In various embodiments, the server is configured to determine a reference measurement result based on the measurement data. The reference measurement result can be used as a reference measurement result for at least one of the first measurement result or the second measurement result. The reference measurement result can be from a virtual sensor (e.g., NO x The reference measurement may be associated with at least one of the first occurrence or the second occurrence of the engine event.

[0110] The server is configured to determine a first reference deviation between the first measurement result and the reference measurement result and a second reference deviation between the second measurement result and the reference measurement result (or a different reference measurement result). The server can compare the first reference deviation and the second reference deviation with their corresponding reference thresholds (e.g., stored first reference thresholds and second reference thresholds). The reference threshold can represent a maximum or minimum allowable deviation between the first measurement result or the second measurement result and the reference measurement result. By comparing the deviation with the reference threshold, the server can confirm whether the first measurement result or the second measurement result is within an expected error percentage of the reference measurement result during the corresponding occurrence. In some aspects, at least one of the first reference threshold or the second reference threshold can be similar to or equal to the measurement threshold.

[0111] In some cases, the server determines the measurement deviation between the first measurement result and the second measurement result only after or immediately after determining that the reference deviation is less than a reference threshold (e.g., within an expected range). For example, the server is configured to determine the measurement deviation after determining that the first reference deviation and the second reference deviation are less than the first reference threshold and the second reference threshold, respectively. In this case, because the measurement results over time are within the threshold (e.g., the first measurement result and the second measurement result are within the reference error range), the server can be configured to use a predetermined performance life based on at least the current level of the sensor's measurement results / offset and the operating time. The determination of the performance life can be performed after comparing the deviation between the measurement results and the measurement threshold.

[0112] In other cases, the measurement may exceed a reference threshold. Due to exceeding the reference threshold, the server determines that the measurement includes an abnormal response or offset value during the driving event. In this case, using the model, the server determines the useful life of the representation based on various operating conditions of the vehicle system exposed to the sensor over time. These operating conditions include at least the amount of deviation, the total operating time of the sensor, the manufacturer's specifications associated with the sensor, and other historical data of the sensor to determine the useful life of the representation.

[0113] In some embodiments, the server is configured to determine a first measurement result discussed herein by applying a first offset to a first data point of the measurement data. In addition, the server is configured to determine a second measurement result by applying a second offset to a second data point of the measurement data. For example, the sensor measurement result reflects an offset value during an engine event. The server can obtain the sensor offset as a measurement result, such as the first offset as the first measurement result and the second offset as the second measurement result.

[0114] In some embodiments, the first signal is associated with operational data of the monitored system. The operational data indicates any engine events (e.g., driving events) that occur during operation of the engine over time. The server is configured to determine target operating characteristics associated with various measurement results (e.g., a subset of the measurement results) of the measurement data. For example, the target operating characteristics may correspond to expected characteristics, behaviors, or features of the data points during the driving event. The server determines the operating characteristics of the performance based on the operational data and the measurement results (e.g., the first measurement results or the second measurement results). The operating characteristics of the performance may correspond to actual characteristics, behaviors, or features of the data points during the driving event. The server may determine a target deviation (e.g., a difference) between the target operating characteristics and the operating characteristics of the performance. The server compares the target deviation with a stored target threshold.

[0115] Thus, if the server determines that the target deviation is less than the target threshold or within the target threshold (e.g., the data point characteristics are within expectations), the server can then compare the measurement deviation to the measurement threshold. In other cases, the server can remove at least one of the first measurement result or the second measurement result from the comparison after determining that the target deviation is greater than or equal to the target threshold (e.g., outside the range of the target threshold). In this case, the server is configured to remove the outlier measurement results to avoid or minimize inaccuracies in predicting the remaining useful life. In some cases, the server is configured to replace at least one of the first measurement result or the second measurement result having characteristics outside the target threshold with a third measurement result, a fourth measurement result, etc. associated with a corresponding occurrence of the engine event.

[0116] At step 1010, the server is configured to determine whether the measurement deviation satisfies a measurement threshold. For example, the measurement threshold may indicate at least a maximum rate of change of the offset value based at least on a time instance of occurrence and an offset level of the first measurement result and the second measurement result. A measurement deviation that satisfies the measurement threshold may refer to a deviation that is greater than or equal to the measurement threshold (e.g., if the threshold is a maximum value). In this case, satisfying the threshold may indicate that the rate of change is higher than expected, indicating degradation or deactivation of the sensor. In some aspects, satisfying the measurement threshold may refer to a measurement deviation that is less than a threshold.

[0117] At step 1012, the server is configured to determine the service life of the performance of the sensor (e.g., the service life of the first performance, the remaining operating time, the failure time, or the predicted life) based on the measurement deviation and at least one of the first measurement result or the second measurement result (e.g., whichever occurs at a later time instance) after determining that the measurement deviation meets the measurement threshold. For example, as described above, the server can execute a model trained using data of faulty sensors from various systems with internal combustion engines. The server determines the service life of the performance of the sensor based on the trend of the sensor offset over time. Because the deviation or rate of change of the first measurement result and the second measurement result meets the threshold, this can indicate the progression or degradation rate of the health / status of the sensor.

[0118] For example, if the server determines that the deviation from the first measurement to the second measurement is within a threshold (e.g., within expected progressive degradation), and the current measurement (or the most recently occurring measurement) exceeds a stored threshold, indicating degradation exceeding a certain degree, the server can determine the useful life of the performance based on a predetermined useful life of the performance. For example, the predetermined useful life of the performance is based on at least the current measurement (e.g., the current offset value) and the operating time. In other cases, if the deviation is outside the threshold (e.g., not within expected progressive degradation), the server executing the trained machine learning model is configured to determine the useful life of the performance based on at least the operating time of the vehicle system exposed to the sensor, the current offset value, historical operating conditions, and other variables.

[0119] In response to determining the useful life of the performance, the server is configured to transmit a signal (e.g., a response signal) to the monitored system (e.g., monitored system 102) to notify the operator of the useful life of the performance. The notification can be provided via a display device, an audio device, and other user interfaces. The server is configured to send the notification signal based on a comparison of the useful life of the performance with a useful life threshold of the performance. For example, if the useful life of the performance is less than the useful life threshold of the performance, the server may send the notification signal indicating that the operator (or other entity) should be warned of the remaining life of the sensor. In some cases, the server may not provide the useful life of the performance based on the useful life of the performance being greater than a predetermined life threshold (such as 3 years, 5 years, 10 years, etc.). More specifically, the server is configured to send a signal to the monitored system (e.g., monitored system 102) to notify the operator that the sensor is healthy.

[0120] In some embodiments, the first signal is also associated with or includes a third occurrence of an internal combustion engine event of the monitored system. The first measurement result, the second measurement result, and the third measurement result can be used to determine the rate of change of the sensor offset. For example, during the third occurrence, the server can determine the third measurement result based on the first measurement data based on the third occurrence of the engine event. After the determination, the server determines the rate of change (e.g., aggregated rate of change, such as average, mean, median, etc.) between the first measurement result, the second measurement result, and the third measurement result. The server compares the rate of change with the stored rate threshold. For example, the server can determine the rate threshold based on the change of the sensor offset trend analyzed from various faulty sensors. After determining that the rate of change meets (e.g., is greater than or equal to) the rate threshold, the server determines the service life of the second performance of the sensor based on the rate of change and at least one of the first measurement result to the third measurement result (e.g., the most recent measurement result). Therefore, in this case, the server is configured to monitor the trend (e.g., change) of the sensor offset over time to determine whether the increase or decrease in the offset is abnormal, thereby determining the service life of the performance (e.g., the service life of the second performance).

[0121] Further in accordance with the above example, and in some embodiments, after receiving the first signal, the server is configured to determine a threshold deviation between a first operational measurement result associated with the first occurrence and a second operational measurement result associated with the second occurrence. The first operational measurement result and the second operational measurement result may be similar to the reference measurement result. For example, the operational measurement result may include measurements from a virtual sensor based on operating conditions of the vehicle system at various occurrences of the engine event. The server compares the measurement deviation with the threshold deviation. The server is configured to determine whether the measurement deviation meets the threshold deviation, such as whether it is within the error range of the threshold deviation. The server may determine the service life of the first performance only after determining that the measurement deviation meets the threshold deviation (e.g., within the range of the threshold deviation). In other cases, the server may not determine the service life of the first performance. For example, the server may remove abnormal data points that are not within the error range of the virtual sensor measurement result.

[0122] In some embodiments, the server is configured to compare the useful life of the first representation with a stored useful life threshold of the representation. The useful life threshold of the representation indicates whether the useful life of the representation indicates an unhealthy sensor or a healthy sensor. Based on the useful life of the representation meeting the threshold, the server compares the first measurement data with the second measurement data, which is associated with the second monitored system (or any other monitored system that provides measurement data of the faulty sensor). The server can determine a failure mode of the sensor (e.g., the first sensor) based at least on the useful life of the representation, the first measurement data, and the second measurement data. For example, the server can compare the trend of data points between the first measurement data and the second measurement data associated with one or more types of failures. The server can repeat the process using other measurement data associated with other types of failures. Based on the detection of similarities between the measurement data, the server is configured to determine a failure mode, including at least one of degradation of a heater of the first monitored system, a platinum stripping event of the first sensor, or poisoning of the first sensor.

[0123] In some aspects, the server is configured to receive a second signal from the monitored system. The second signal is associated with an indication that the first sensor is replaced with the second sensor. For example, when the first sensor is replaced by the second sensor, the monitored system can be triggered to send an indication to the server that the sensor is replaced. In some cases, the server identifies the replacement of the first sensor based on an operating time of the second sensor (e.g., a different operating time or a reduced operating time). In addition, the server can receive another signal (e.g., a third signal) from the monitored system. The third signal is associated with or includes second measurement data of the second sensor. Therefore, the server can discard, transfer, or reset the historical data of the first sensor and continue to collect, analyze, and process the second measurement data from the second sensor.

[0124] In various embodiments, the server may receive a second signal from a second monitored system including an internal combustion engine and a second sensor. The second signal is associated with or includes the following items: a third occurrence of a second internal combustion engine event of the second monitored system, a fourth occurrence of the second internal combustion engine event, and second measurement data of the second sensor. For example, based on the second measurement data, the server is configured to determine at least a third measurement result based on a third occurrence of a second engine event (e.g., similar to or different from the first engine event or the driving event), and at least a fourth measurement result based on a fourth occurrence of the second engine event. Subsequently, the server determines a second measurement deviation between the third measurement result and the fourth measurement result. The server then compares the second measurement deviation with a stored measurement threshold, similar to step 1008. In this case, the server may determine the service life of the second representation of the second sensor based on the second measurement deviation and at least one of the third measurement result or the fourth measurement result after determining that the second measurement deviation satisfies the measurement threshold. Therefore, the server may repeat the operations, steps, or techniques discussed herein for other monitored systems to determine the status of other sensors or components.

[0125] IV. Configuration of Example Embodiments Although this specification contains many specific implementation details, these should not be interpreted as limitations on the scope of the content that can be claimed, but should be interpreted as descriptions of features that are unique to specific implementations. Certain features described in the context of separate implementations in this specification may also be implemented in combination in a single implementation. On the contrary, the various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations. Moreover, although features may be described as working in certain combinations and even initially claimed as such, one or more features from the claimed combination may be deleted from the combination in some cases, and the claimed combination may involve a sub-combination or a variation of the sub-combination.

[0126] As utilized herein, the terms "substantially," "approximately," "about," and similar terms are intended to have a broad meaning consistent with common and accepted usage by those of ordinary skill in the art to which the subject matter of the present disclosure belongs. Those skilled in the art who review the present disclosure should understand that these terms are intended to allow description of certain features described and claimed without limiting the scope of these features to the precise numerical ranges provided. Accordingly, these terms should be interpreted as indicating that insubstantial or inconsequential modifications or alterations of the subject matter described and claimed are considered to be within the scope of the present invention as described in the appended claims.

[0127] As used herein, the term "coupled" and similar terms mean the joining of two components directly or indirectly to one another. Such joining may be fixed (e.g., permanent) or movable (e.g., removable or releasable). Such joining may be achieved by the two components, or the two components and any additional intermediate components, being integrally formed as a single unitary body with one another, or by the two components, or the two components and any additional intermediate components, being attached to one another.

[0128] As used herein, the term "fluidically coupled to" and the like refers to two components or objects having a path formed between the two components or objects in which a fluid (e.g., air, exhaust gas, liquid reductant, gaseous reductant, aqueous reductant, gaseous ammonia, etc.) can flow with or without an intermediate component or object. Examples of fluid couplings or configurations for achieving fluid communication may include tubes, channels, or any other suitable components for achieving the flow of a fluid from one component or object to another component or object.

[0129] It is important to note that the structure and arrangement of the systems shown in the various example embodiments are illustrative and non-restrictive in nature. All changes and modifications within the spirit and / or scope of the described embodiments need to be protected. It should be understood that some features may not be necessary, and embodiments lacking various features may be considered to be within the scope of the present application, which scope is defined by the appended claims. When the language "a portion" is used, the item may include a portion and / or the entire item unless explicitly stated to the contrary.

[0130] Additionally, the word "or" is used in its inclusive sense (and not in its exclusive sense), such that when used, for example, to connect a list of elements, the word "or" means one, some, or all of the elements in the list. Unless expressly stated otherwise, connective language such as the phrase "at least one of X, Y, and Z" is understood in the context to generally convey that an item, term, etc. can be X; Y; Z; X and Y; X and Z; Y and Z; or X, Y, and Z (i.e., any combination of X, Y, and Z). Thus, unless otherwise specified, such connective language is generally not intended to imply that certain embodiments require that at least one of X, at least one of Y, and at least one of Z are all present.

[0131] In addition, unless otherwise stated, the value ranges used herein (e.g., W to P, etc.) include their maximum and minimum values ​​(e.g., W to P includes W and includes P, etc.). In addition, unless otherwise stated, the value ranges (e.g., W to P, etc.) are not necessarily required to include intermediate values ​​in the value ranges (e.g., W to P may only include W and P, etc.).

Claims

1. At least one server, the at least one server comprising at least one processor coupled to at least one memory storing instructions, the instructions, when executed by the at least one processor, causing the at least one server to: receiving a first signal from a first monitored system including an internal combustion engine and a first sensor, the first signal being associated with a first occurrence of an internal combustion engine event of the first monitored system, a second occurrence of the internal combustion engine event of the first monitored system, and first measurement data of the first sensor; determining a first measurement result according to the first measurement data based on the first occurrence of the internal combustion engine event; determining a second measurement result according to the first measurement data based on the second occurrence of the internal combustion engine event; determining a measurement deviation between the first measurement result and the second measurement result; comparing the measured deviation to a stored measurement threshold; as well as After determining that the measurement deviation satisfies the measurement threshold, a first manifestation of the useful life of the first sensor is determined based on the measurement deviation and at least one of the first measurement result or the second measurement result.

2. The at least one server according to claim 1, wherein: The instructions, when executed by the at least one processor, further cause the at least one server to: determining a reference measurement result according to the first measurement data; determining a first reference deviation between the first measurement result and the reference measurement result; determining a second reference deviation between the second measurement result and the reference measurement result; comparing the first reference deviation with a stored first reference threshold; comparing the second reference deviation with a stored second reference threshold; as well as After determining that the first reference deviation is less than the first reference threshold and the second reference deviation is less than the second reference threshold, the measurement deviation is determined.

3. The at least one server according to claim 2, wherein: The first reference threshold is equal to the measurement threshold.

4. The at least one server according to claim 2, wherein: The instructions, when executed by the at least one processor, further cause the at least one server to: determining the first measurement by applying a first offset to a first data point of the first measurement data; as well as The second measurement is determined by applying a second offset to a second data point of the first measurement data.

5. The at least one server according to claim 1, wherein: The first signal is also associated with operational data of the first monitored system; and The instructions, when executed by the at least one processor, further cause the at least one server to: determining a target operating characteristic associated with the first measurement, determining an operational characteristic of the performance based on the operational data and the first measurement, determining a target deviation between the target operating characteristic and the performed operating characteristic, comparing the target deviation to a stored target threshold, and After determining that the target deviation is less than the target threshold, the measured deviation is compared to the measured threshold.

6. The at least one server according to claim 1, wherein: The instructions, when executed by the at least one processor, further cause the at least one server to receive a second signal from the first monitored system, the second signal associated with an indication to replace the first sensor with a second sensor.

7. The at least one server according to claim 6, wherein: The instructions, when executed by the at least one processor, further cause the at least one server to receive a third signal from the first monitored system, the third signal being associated with second measurement data of the second sensor of the first monitored system.

8. The at least one server according to claim 1, wherein: The first signal is also associated with a third occurrence of the internal combustion engine event of the first monitored system; and The instructions, when executed by the at least one processor, further cause the at least one server to: determining a third measurement result based on the first measurement data based on the third occurrence of the internal combustion engine event, determining a rate of change between the first measurement result, the second measurement result, and the third measurement result, comparing the rate of change to a stored rate threshold, and After determining that the rate of change satisfies the rate threshold, a useful life of a second representation of the first sensor is determined based on the rate of change and at least one of the first measurement, the second measurement, or the third measurement.

9. The at least one server according to claim 8, wherein: The instructions, when executed by the at least one processor, further cause the at least one server to: after receiving the first signal, determining a threshold deviation between a first operational measurement associated with the first occurrence of the internal combustion engine event and a second operational measurement associated with the second occurrence of the internal combustion engine event; comparing the measured deviation to the threshold deviation; as well as After determining that the measured deviation satisfies the threshold deviation, a useful life of the first representation is determined.

10. The at least one server according to claim 1, wherein: The first measurement data indicates an amount of an exhaust byproduct associated with the first monitored system; The measurement threshold is associated with the exhaust byproduct; as well as The instructions, when executed by the at least one processor, further cause the at least one server to select the measurement threshold based on the exhaust byproduct.

11. The at least one server according to claim 1, wherein: The instructions, when executed by the at least one processor, further cause the at least one server to: comparing the useful life of the first representation to a stored useful life threshold of the representation; comparing the first measurement data to second measurement data associated with a second monitored system based on the useful life of the first representation satisfying a useful life threshold for the representation; as well as A failure mode of the first sensor is determined based on the useful life of the first representation, the first measurement data, and the second measurement data, the failure mode comprising at least one of: degradation of a heater of the first monitored system, a platinum stripping event of the first sensor, or poisoning of the first sensor.

12. The at least one server according to claim 1, wherein: The instructions, when executed by the at least one processor, further cause the at least one server to: comparing the useful life of the first representation to a stored useful life threshold of the representation; and A second signal is transmitted to the first monitored system, the second signal being associated with a notification to replace the first sensor.

13. A method comprising: receiving, by at least one server, a first signal from a monitored system, the first signal being associated with a first occurrence of an internal combustion engine event of the monitored system, a second occurrence of the internal combustion engine event of the monitored system, and first measurement data of a first sensor of the monitored system; determining, by the at least one server, a first measurement result according to the first measurement data based on the first occurrence of the internal combustion engine event; determining, by the at least one server, a second measurement result according to the first measurement data based on the second occurrence of the internal combustion engine event; determining, by the at least one server, a measurement deviation between the first measurement result and the second measurement result; comparing, by the at least one server, the measurement deviation to a measurement threshold; as well as After determining that the measurement deviation satisfies the measurement threshold, determining, by the at least one server, a service life of a first representation of the first sensor based on the measurement deviation and at least one of the first measurement result or the second measurement result.

14. The method according to claim 13, further comprising: determining, by the at least one server, a reference measurement result according to the first measurement data; determining, by the at least one server, a first reference deviation between the first measurement result and the reference measurement result; determining, by the at least one server, a second reference deviation between the second measurement result and the reference measurement result; comparing, by the at least one server, the first reference deviation with a first reference threshold; comparing, by the at least one server, the second reference deviation with a second reference threshold; as well as The measurement deviation is determined by the at least one server after determining that the first reference deviation is less than the first reference threshold and the second reference deviation is less than the second reference threshold.

15. The method according to claim 14, further comprising: determining, by the at least one server, the first measurement by applying a first offset to a first data point of the first measurement data; as well as The second measurement result is determined by the at least one server by applying a second offset to a second data point of the first measurement data.

16. The method according to claim 13, further comprising: A second signal is received by the at least one server from the monitored system, the second signal associated with an indication to replace the first sensor with a second sensor.

17. The method according to claim 16, further comprising: A third signal is received by the at least one server from the monitored system, the third signal being associated with second measurement data of the second sensor of the monitored system.

18. A network comprising: A first monitored system, the first monitored system comprising: The first internal combustion engine, a first sensor, and a first engine control unit; and At least one server external to the first monitored system, the at least one server comprising at least one processor coupled to at least one memory storing instructions that, when executed by the at least one processor, cause the at least one server to: receiving a first signal from the first engine control unit, the first signal being associated with a first occurrence of a first internal combustion engine event of the first monitored system, a second occurrence of the first internal combustion engine event, and first measurement data of the first sensor; determining a first measurement result according to the first measurement data based on the first occurrence of the first internal combustion engine event; determining a second measurement result based on the first measurement data based on the second occurrence of the first internal combustion engine event; determining a first measurement deviation between the first measurement result and the second measurement result; comparing the first measurement deviation to a stored measurement threshold; and After determining that the first measurement deviation satisfies the measurement threshold, a first manifestation of the useful life of the first sensor is determined based on the first measurement deviation and at least one of the first measurement result or the second measurement result.

19. The network of claim 18, further comprising a second monitored system, the second monitored system comprising: The second internal combustion engine, a second sensor, and a second engine control unit; Wherein, when the instructions are executed by the at least one processor, the at least one server further causes: receiving a second signal from the second engine control unit, the second signal being associated with a third occurrence of a second internal combustion engine event of the second monitored system, a fourth occurrence of the second internal combustion engine event, and second measurement data of the second sensor; determining a third measurement result based on the third occurrence of the second internal combustion engine event according to the second measurement data; determining a fourth measurement result based on the fourth occurrence of the second internal combustion engine event according to the second measurement data; determining a second measurement deviation between the third measurement result and the fourth measurement result; comparing the second measured deviation to a stored measurement threshold; and After determining that the second measurement deviation satisfies the measurement threshold, a second representation of the useful life of the second sensor is determined based on the second measurement deviation and at least one of the third measurement result or the fourth measurement result.

20. The network of claim 19, wherein: The instructions, when executed by the at least one processor, further cause the at least one server to determine an expected useful life associated with the first sensor and the second sensor using the useful life of the first representation and the useful life of the second representation.

Images