System and method for determining the lifetime of a sensor in a monitored system

Abstract

At least one server includes at least one processor coupled to at least one memory storing instructions. The 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 the 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 result and the second measurement result. The server may compare the measurement deviation with a stored 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.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] 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

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

[0004] background

[0005] 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 the 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.

[0006] 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 sensor's operability and condition to ensure reliable measurements. Sensor condition or performance can often be assessed during routine maintenance of certain systems. In some cases, a fault code or indication of sensor failure is provided to the operator after a sensor failure has occurred. However, predicting a sensor's remaining life before a failure occurs can be challenging.

[0007] Overview

[0008] In some embodiments, at least one server may include 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 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 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. The server may determine a first measurement result based on the first occurrence of the internal combustion engine event and the first measurement data. The server may determine a second measurement result based on the second occurrence of the internal combustion engine event and 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 to a stored measurement threshold. After determining that the measurement deviation meets 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.

[0009] In certain embodiments, a method may include receiving, by at least one server, a first signal from a monitored system, the first signal 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 the 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 the 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 the at least one server, a measurement deviation between the first measurement result and the second measurement result. The method may include comparing, by the at least one server, the measurement deviation to a measurement threshold. The method may include, after determining that the measurement deviation satisfies the measurement threshold, determining, by the 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.

[0010] In yet other embodiments, a network may include a first monitored system comprising 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 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 receive a first signal from the first engine control unit, the first signal 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 from a first sensor. The server may determine a first measurement result based on the first occurrence of the first internal combustion engine event and 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 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 to a stored measurement threshold. After determining that the first measurement deviation meets the measurement threshold, the server may determine a first characteristic lifespan 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

[0012] 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:

[0013] Figure 1 is a block diagram of an example vehicle system;

[0014] Figure 2 It is a process flow chart of the modeling process;

[0015] Figure 3 Example internal combustion engine events and measurement data are shown;

[0016] Figure 4 An example NO during motoring for a faulty sensor is shown. x sensor response;

[0017] Figures 5A-5C Yes No x a graph of example expected measurements from a sensor;

[0018] Figures 6A-6C Yes No x a graph of example abnormal measurements of a sensor;

[0019] Figure 7 Yes No x A graph of example prediction accuracy and remaining time for a sensor;

[0020] Figure 8 Yes No x a graph of an example remaining life of a sensor based on monitored excursions;

[0021] Figure 9 It is NO associated with different systems x Heatmap of example health status of sensors; and

[0022] Figure 10 is a flow chart of an example method for a monitored system.

[0023] 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.

[0024] Detailed description

[0025] What follows is a more detailed description of various concepts related to methods, apparatus, and systems for determining the lifespan of a sensor in a monitored system, as well as implementations of the methods, apparatus, and systems. The various concepts introduced above and discussed in greater 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.

[0026] I. Overview

[0027] 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 NOx is a byproduct in the exhaust gas and the sensor may be configured to sense NOx downstream of the engine (e.g., anywhere along the exhaust pipe). x NOx emissions x Although the examples described include sensors that measure NO x NO by-product x sensor, but the described system can be applied to other sensors.

[0028] The measurements can be used by the controller to control or manage components within or coupled to the aftertreatment system to manage emissions from the engine. For example, the components may include a reductant doser, hydrocarbon injectors, exhaust gas recirculation (EGR) systems, heaters, coolers, and other components. Using the measurements, the controller can control one or more components to minimize NO x Slippage can occur, for example, by increasing the reductant dosage, initiating hydrocarbon injection for catalyst regeneration (e.g., a selective catalytic reduction (SCR) catalyst, etc.). However, due to sensor degradation or failure over time, the controller may receive inaccurate measurements or, in some cases, may not receive any signal from the sensor at all. Inaccurate measurements or the lack of a signal indicating the exhaust output from the engine may impair the operability of certain components coupled to or in the aftertreatment system, leading to incorrect adjustment or configuration of the controller. Therefore, it is desirable to determine or predict the health of the sensor over time so that the sensor can be maintained or replaced before failure (e.g., predicting the duration until failure).

[0029] The systems and methods of the technical solutions described herein include at least one device (e.g., a computing device, server, or data processing system) comprising at least one processor coupled to at least one memory. In some cases, the device may be embedded in a system including an internal combustion engine and one or more sensors. In some cases, the device may correspond to or be referred to herein as a server. A 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 the sensors, such as measurement data (e.g., first measurement data) from the sensors during pre-specified / predetermined engine events or operating events. These engine events may include expected behavior from the sensors (e.g., expected measurement results or second measurement data), which can be used to determine anomalies relative to the expected behavior (e.g., measurement deviations between the first and second measurement results).

[0030] The server can use the fusion of data analysis methods and physics-based technologies described in this article to provide a predictive solution for health prediction of sensors and other components of the aftertreatment system. The health prediction can include the performance or predicted service life of the sensors, actuators, filters and other components in the observed engine system. By predicting the 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 the sensor measurements (e.g., first measurement results, second measurement results, 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 (e.g., calibration) can be applied to the sensor.

[0031] The server can train a model by inputting data on offsets measured during engine events. The model can aggregate input data, including variations, deviations, and fluctuations in offsets from the sensor's installation time to its failure time. The server can provide sample data to the model to improve its performance (e.g., output accuracy). Once the model is trained and executable with at least the expected performance, the server can use the model to subsequently predict the health status (e.g., remaining useful life or time until failure) of one or more sensors (e.g., sensors of a similar type to those associated with the trained model). For example, the server can receive sensor data from a sensor and input the sensor data into the model. The model can determine the remaining useful life or time until failure of the sensor based on at least one of fluctuations, deviations, or trends in the offset measurements, depending on the operating conditions / environment experienced by the sensor during its operation (e.g., age, operating temperature, exhaust gas exposure, poisoning, duty cycle, fuel quality, etc.). Thus, the server can predict the remaining operating time of the sensor without requiring high resource consumption (e.g., without requiring comparisons to various aggregate data) and without requiring extended latency for the prediction output.

[0032] 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.

[0033] II. Network System Overview

[0034] Figure 1 An example network system 100 (e.g., a network) is shown. Network system 100 includes a monitored system 102 and a monitoring system 104 (e.g., a server). Monitored system 102 communicates (e.g., electrically or wirelessly) with monitoring system 104. Monitored system 102 may include or be part of (e.g., communicate with) a vehicle. The vehicle may be an on-road vehicle or an off-road vehicle, including but not limited to long-haul trucks, mid-range trucks (e.g., pickup trucks), automobiles, ships, tanks, aircraft, locomotives, mining equipment, and any other type of vehicle. The vehicle may include a transmission, a fueling system, one or more additional vehicle subsystems, and the like. The vehicle may include additional, fewer, and / or different components / systems, such that the principles, methods, systems, apparatuses, processes, and the like 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 construed as limited to vehicles; rather, the present disclosure is also applicable to stationary equipment such as generators or generator sets.

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

[0036] The exhaust aftertreatment system 103 also includes an oxidation catalyst 111 (e.g., a diesel oxidation catalyst (DOC)). The oxidation catalyst 111 is configured (e.g., 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.

[0037] Exhaust aftertreatment system 103 also includes a particulate filter 112 (e.g., a diesel particulate filter (DPF)). Particulate filter 112 is configured to remove particulate matter (such as soot) from the exhaust provided by oxidation catalyst 111. Particulate filter 112 includes an inlet and an outlet, wherein the exhaust is received at the inlet and the exhaust is subsequently filtered of particulate matter and / or converted into carbon dioxide. In some embodiments, particulate filter 112 may be omitted.

[0038] The exhaust gas aftertreatment system 103 further includes a decomposition chamber 114 (eg, a reactor, a reactor tube, etc.). The decomposition chamber 114 is configured to convert the reducing agent into ammonia. The reducing agent 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 .

[0039] 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 CO by accelerating the conversion of ammonia and NO in the exhaust gas. x NO between x 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 being in fluid communication with the decomposition chamber 114 and receiving the exhaust gas and the reducing agent from the decomposition chamber 114, and the outlet being in fluid communication with the end of the exhaust conduit system 106.

[0040] 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, thermal decomposition, and hydrolysis to form non-NO in the exhaust duct system 106. x Emissions (e.g., gaseous ammonia, etc.).

[0041] The reductant delivery system 105 includes a dosing module 118 (e.g., a dosing device, 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 the portion of the decomposition chamber 114 on which the dosing module 118 is mounted.

[0042] The dosing module 118 is fluidly coupled to (eg, configured to be in fluid communication with) a reductant source 120 (eg, a reductant tank, a reductant reservoir, 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. ® A DEF tank is provided. A reductant pump 121 (e.g., a supply unit, etc.) is used to pressurize 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 achieve a target pressure, etc.). The reductant pump 121 may draw the reductant through a reductant filter 122. Before providing the reductant to the internal components (e.g., piston, vanes, etc.) of the reductant pump 121, the reductant filter 122 filters the reductant (e.g., strains particulate matter, etc.). For example, the reductant filter 122 may inhibit or prevent solids (e.g., solidified reductant, contaminants, etc.) from being transferred to the internal components of the reductant pump 121. In this manner, the reductant filter 122 may help prolong the operation of the reductant pump 121 in a healthy state. In some embodiments, the reductant pump 121 is coupled to the chassis of a vehicle associated with the exhaust aftertreatment system 103.

[0043] The dosing module 118 includes at least one injector 124 (e.g., a reductant injector, etc.). Each injector 124 is configured to dispense reductant into the exhaust (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 at a target location (e.g., at the inlet of the conversion catalyst 116, etc.).

[0044] 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 positioned upstream of the air pump 126. The air filter 130 filters the air before it is supplied to the internal components of the air pump 126 (e.g., pistons, blades, etc.). For example, the air filter 130 can inhibit or prevent solid matter (e.g., debris, branches, dirt, etc.) from being transferred to the internal components of the air pump 126. In this way, the air filter 130 can help prolong the operation of the air pump 126. The air pump 126 supplies air to the dispensing module 118 via a conduit. The dispensing module 118 is configured to mix the air and reductant into an air-reductant mixture and supply 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.

[0045] 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 .

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

[0047] 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 150, 152, 156, 162, 164, etc.). For example, monitoring system 104 may communicate with one or more components via wired or wireless communication (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 components of network system 100 (such as from monitored system 102).

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

[0049] In some cases, monitored system 102 is configured to communicate with monitoring system 104. For example, monitored system 102 is configured to transmit information from components of monitored system 102 (e.g., aftertreatment system 103, engine 108, etc.) to monitoring system 104 for storage or processing. This information may include sensor measurements, timestamps associated with the measurements, indications of various engine operations / events (e.g., motoring events, ignition, fuel injection levels, crankshaft speed, etc.), timestamps associated with engine operation, and other data described herein. In another example, monitored system 102 is configured to receive or obtain instructions or processed information from monitoring system 104. Instructions may include, for example, displaying processed information to an operator via a display device. The processed information may include at least the operating time, remaining useful life (e.g., operating duration), and time to failure (e.g., remaining time until failure) of a component (e.g., a 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.

[0050] 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 NOx sensor, and a CMOS sensor. x sensor, air flow sensor, etc. For the purpose of providing examples, the monitoring system 104 uses the NO x Sensor signals to perform features, functions, and operations of the technology solution (e.g., component health prognosis), although other sensors (e.g., temperature sensors, air flow sensors, ammonia sensors, dosing sensors, etc.) may also be used in similar embodiments.

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

[0052] III. Overview of Component Analysis Systems

[0053] 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 data collection circuitry 166, data pre-processing circuitry 168, model development circuitry 170, and prediction circuitry 172. The circuits (e.g., data collection circuitry 166, data pre-processing circuitry 168, model development circuitry 170, or prediction circuitry 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 the information. Also in conjunction with Figure 2 The operation of the circuit is described.

[0054] The data collection circuitry 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 data that the data collection circuitry 166 is configured to receive, obtain, collect, or acquire from components of the network system 100. The data collection circuitry 166 may receive data directly from the components or from an intermediate device, such as a storage device, a telematics unit, or other intermediate device.

[0055] The data collection circuitry 166 may acquire data continuously or periodically. For example, in various embodiments, the data collection circuitry 166 is configured to receive and store real-time data from sensors (e.g., actuators, filters, and other components used to determine the performance and service life of the corresponding components). The data collection circuitry 166 is configured to receive or collect data corresponding to the components, such as for processing and determining the performance and service life of the corresponding components. In other embodiments, the data collection circuitry 166 is configured to acquire data at predetermined intervals (e.g., daily, weekly, monthly, etc.). In such cases, the data may be stored on a local memory storage device of the monitored system 102 or uploaded to a cloud storage device by the monitored system 102, and the data may be retrieved by the monitoring system 104. Thus, the data collection circuitry 166 retrieves data from the local or remote storage device at predetermined intervals (e.g., configurable by an operator of the network system 100 or an administrator of the monitoring system 104). The data collection circuitry 166 provides the collected data to the data pre-processing circuitry 168.

[0056] In some embodiments, the collected data can be represented as data points within a graph. For example, (e.g., at least in conjunction with Figure 4A graph (described herein) can 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., flags of engine events), or information provided by a component may be associated with the y-axis, and timestamps 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, measurement frequency, or the amount of data requested by the data collection circuitry 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 circuitry 166 may determine the sensor measurements by applying the sensor offsets to the data points, 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 circuitry 166 may obtain the sensor measurements from the monitored system 102 with the corresponding offsets applied.

[0057] Data preprocessing circuitry 168 is configured to prepare or preprocess data for use by model development circuitry 170 or prediction circuitry 172. Data preprocessing circuitry 168 is configured to filter, remove, or cleanse the signal of 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 from 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 connectivity issue), or at least one gap or inconsistency in data received from one or more sensors (e.g., physical sensors or virtual sensors) 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 data indicating an expected NO xVirtual data of a measurement result (e.g., a reference measurement result). In some cases, a 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. x The measurement results can be based on at least the exhaust gas flow, temperature, fuel consumption, crankshaft rotation speed, SCR catalyst NO x Conversion efficiency (if the sensor is downstream of the catalyst), and other data that may contribute to the amount of byproducts produced by engine 108. Data pre-processing circuitry 168 compares the actual measurement from the sensor with the expected measurement. Data pre-processing circuitry 168 can determine whether the deviation between the two measurements meets a threshold (e.g., greater than or equal to the threshold, or in some cases, less than the threshold). If the deviation is greater than the threshold (e.g., exceeds the expected measurement), data pre-processing circuitry 168 can filter the data point. The threshold can be predetermined by a manager, such as + / - 20%, + / - 30%, etc.

[0058] The data pre-processing circuitry 168 also filters data based on the type of engine event. The data pre-processing circuitry 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 driving events of the engine 108 may be selected for processing. In some other cases, the data pre-processing circuitry 168 may extract data associated with other types of engine events, such as braking events, idling events, regeneration events, and other abnormal conditions (e.g., abnormal events). Because the driving event type is selected, the data pre-processing circuitry 168 is configured to filter a subset of data not associated with the driving events. In various embodiments, the data pre-processing circuitry 168 is configured to remove a portion of the data associated with the driving events, such as a specific duration or data sample from the beginning or end of each driving event.

[0059] After filtering / cleaning the data, the data pre-processing circuit 168 aggregates the remaining data associated with the engine event for signature determination. This data may include at least NO x Sensor measurement result, NO x Sensor offset, NO x Sensor invalid state, and the deviation between the actual measurement result and the expected measurement result. The data pre-processing circuit 168 is configured to provide the aggregated data to the model development circuit 170 for generating or training the model. In some cases, the data pre-processing circuit 168 is configured to provide the aggregated data to the 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.

[0060] In various embodiments, the data pre-processing circuitry 168 is configured to only crop, utilize, or extract data (e.g., sensor measurement data) that falls 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. A threshold (e.g., a target threshold) can be configured by an administrator, such as a 30%, 40%, or 50% deviation from the target operating characteristic. For example, the target operating characteristic can correspond to an expected characteristic, behavior, measurement result, pattern, or signature of the data points during a driving event. The data pre-processing circuitry 168 identifies or determines a demonstrated operating characteristic based on the operating data and the measurement results (e.g., the first measurement result or the second measurement result, pattern, or offset). The demonstrated operating characteristic can correspond to an actual characteristic, behavior, or signature of the data points during the driving event. The data pre-processing circuitry 168 can determine a target deviation (e.g., a difference in measurement) between the target operating characteristic and the demonstrated operating characteristic. The data pre-processing circuitry 168 compares the target deviation to a stored target threshold, which can be configured by the administrator of the monitoring system 104 or based on trends (e.g., historical data) of data points associated with other monitored systems.

[0061] Thus, data pre-processing circuitry 168 can use only data points with a demonstrated operational characteristic (e.g., pattern or measurement) that is within a target threshold (e.g., less than the target threshold) based on the difference between the target operational characteristic and the demonstrated operational characteristic. In other cases, if the difference between the demonstrated characteristic of a data point and the target characteristic is greater than or equal to a threshold, e.g., if the data point is outside a configured error window, then data pre-processing circuitry 168 can filter data points outside of an error range or window. In this case, the measured deviation is compared to the measurement threshold only if the target deviation is less than the target threshold (e.g., within the error window).

[0062] Model development circuitry 170 is configured to generate, develop, or train a machine learning model (e.g., sometimes 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 the model to find patterns in input data. In this case, model development circuitry 170 may receive aggregated data as input.

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

[0064] In various embodiments, the model development circuitry 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 circuitry 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: one or more failure modes or failure progression rates of the sensor. The model development circuitry 170 may compare aggregated data from sensors within multiple similar groups / categories. In this case, the model development circuitry 170 may combine the various features of sensor measurements or excursions from comparable categories to determine expected patterns associated with those sensors. The model development circuitry 170 may reiterate the model training operation. This 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.

[0065] Prediction circuitry 172 is configured to determine the remaining useful life of a sensor (e.g., a first sensor). Remaining useful life can be referred to as the duration until failure, time to failure, or the sensor's perceived useful life. For example, prediction circuitry 172 receives filtered or cleaned data from the sensor from data preprocessing circuitry 168. Prediction circuitry 172 may input this data into a trained model. The model may be trained using data from other sensors with comparable operating conditions to the first sensor. In some embodiments, the model (e.g., model development circuitry 170 and other circuitry in 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 useful life of the sensor (e.g., the operating time indicated in the specifications) under standard / normal / expected operating conditions (e.g., as indicated in the sensor's specifications), the actual operating conditions imposed on the sensor, the failure mode, or the average operating time (e.g., actual useful life) of one or more comparable / similar sensors associated with one or more engine systems (e.g., aggregate data on failed sensors). For example, the specifications of the sensor are provided by at least one of the manufacturer of the sensor, an administrator of the monitoring system 104 , a service technician, and other entities that provide sensors for the engine system.

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

[0067] In response to determining the useful life, prediction circuitry 172 is configured to send an instruction to monitored system 102 indicating the expected useful life 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 expected time (e.g., days, months, or years until failure). In some cases, prediction circuitry 172 may signal monitored system 102 to activate a service indicator, such as a recommended sensor replacement for a vehicle.

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

[0069] 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 status or health of a sensor (e.g., the lifespan of the sensor). Server 204 may also include other components, features, or functionality similar to monitoring system 104.

[0070] Before preparing or processing data herein, server 204 (e.g., data collection circuitry 166 ) identifies or obtains various parameters (e.g., prerequisites or conditions) to be followed for sensor fault prediction. For example, server 204 (or a model executable by server 204 ) may obtain the parameters or have the parameters configured by an administrator of server 204 . The operations discussed herein may follow one or more preconfigured parameters. In some cases, server 204 determines to use certain parameters based on available information from the components. The parameters may include or indicate at least a failure mode identifier (e.g., a fault classification), a physics-inferred hypothesis definition (e.g., observations of sensor behavior or sensor measurements during certain engine events), model performance criteria, the type of input data (e.g., data to be used as input to the model), and the type of output data (e.g., a presentation of results from processing the input data).

[0071] The failure mode indicator indicates the type of failure that the sensor has experienced over time. For example, NO x Sensor failures are categorized into various failure modes, such as heater degradation, platinum (P) cracks, P delamination, poisoning, contamination, circuit failure, and wiring harness failure. One or more of these failure modes (e.g., heater degradation, Pt shifting, or Pt delamination) may be progressive failure modes. Progressive failure modes are observable during the sensor's lifetime (e.g., during sensor aging or under certain operating conditions). Historical data for the corresponding sensor can be used to identify progressive failure modes.

[0072] 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. For example, because NO x The sensor tends to fail due to degradation of the heater element over time, and the server 204 (eg, the data collection circuit 166 ) monitors or receives NOx detected during certain engine operations 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.

[0073] For example, using NO x Sensor, the engine event can be an occurrence when no byproduct is produced (e.g., a first occurrence, a second occurrence, etc.) or an occurrence when the engine 108 can produce a maximum amount of byproduct. For simplicity, and to provide an example herein, the engine event can be a driving mode of the engine 108 when no fuel is being supplied to the engine 108, but other types of driving modes can be used, such as during a maximum fuel supply rate event, a braking mode, etc. For example, NO x The sensor includes several internal components (e.g., heater circuits / elements, etc.) that may degrade due to heat (e.g., heater degradation). In this case, if the 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 can provide NO x an indication of (e.g., early) thermal degradation of a sensor, the degradation of the 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), driving events associated with the occurrence of minimum operating temperatures or maximum operating temperatures may be observed. Therefore, the server 204 (e.g., the prediction circuit 172) uses the sensor measurements during these engine events as input to the model (and monitors the sensor response over time) to provide heater degradation or NO fault codes before the fault code for the sensor is triggered or activated. x Early indication of sensor failure.

[0074] In another example, NO xThe behavior of the sensor in various failure modes (e.g., platinum displacement or platinum peeling) can be explained by the NO x An abnormal rate of change (e.g., measurement result or offset) of a sensor is observed or determined. For example, an abnormal rate of change may refer to a rate that increases above a maximum threshold (e.g., an upper threshold) or decreases below a minimum threshold (e.g., a lower threshold). The server 204 (or other monitoring system) may detect an abnormal rate of change of a sensor (e.g., a measurement result or offset) by a 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) will set 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., a virtual sensor output) to determine the lifetime of the performance. In this case, the virtual sensor can be exposed to operating conditions similar to those of the physical sensor (e.g., when generating the output). The output value of the virtual sensor can be used as a reference output value for the physical sensor output (e.g., for comparison).

[0075] The type of input data for each physical inference hypothesis includes at least one of the following: NO monitored during a specified engine event; 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., to identify 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 progression rate of a failure mode (e.g., sometimes referred to as a rise in sensor offset). Machine learning models 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 available 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 logging 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 progression of damage on the sensor. In another example, a rise in sensor offset can indicate an increase in the deviation of the physical sensor output (e.g., compared to the virtual sensor output), thereby indicating progressive damage to the sensor. The data volume indicates the minimum amount of data from a single sensor used for training, such as data from 1 month, 6 months, 1 year, 3 years, 5 years, or 7 years prior to the failure. The model execution frequency indicates how often data is acquired and / or processed 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.

[0076] In various embodiments, the frequency of model execution is based on the lifetime of the sensor. For example, based on the prediction results, server 204 (e.g., prediction circuitry 172) can be configured to re-evaluate the lifetime of the sensor 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.

[0077] Model performance criteria indicate at least minimum acceptable performance of the model prior to use or execution. Server 204 can evaluate the model using sample data from various vehicles 202 or monitored systems having internal combustion engines and sensors. The sample data can include a subset of historical data for failed sensors, allowing the model to predict their performance lifespan. The sample data can also include actual performance lifespans, allowing the model to compare the predicted performance lifespan with the actual performance lifespan and adjust its process or evaluation techniques based on the deviation between the predicted performance lifespan and the actual performance lifespan. The sample data can also include other information used to train, update, improve, or validate the model. If the model meets the minimum acceptable performance (e.g., the deviation between the predicted and actual results is less than a threshold, such as a difference of less than one month for more than 90% of the sample data), server 204 can use the model to determine the performance lifespan of subsequent sensors (or components) of the monitored system (e.g., monitored system 102).

[0078] 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 Figure 9 For example, server 204 (e.g., prediction circuitry 172) can use a model to generate a heat map representation of results based on one or more (e.g., subsequent or sequential) model executions (e.g., daily, weekly, etc.) of the input data to indicate the progression of a sensor's failure, which can represent the sensor's remaining useful life over a timeline. A notification can indicate that the sensor is approaching failure (e.g., six months, three months, etc. before failure occurs). The notification can be visual, audio, or any other type of presentation. Server 204 shares the notification with at least one of an operator, a corresponding entity handling component / part replacement, or an administrator of server 204. Server 204 is configured to share the notification before further degradation progresses, triggering a fault code that causes an unplanned downtime for the operator. Model execution results can be presented to various entities in other ways.

[0079] In various embodiments, multiple models can be generated, trained, and tested against each other for performance evaluation. In certain embodiments, managers, technicians, or engineers can evaluate the performance of the models in fault pattern identification and determine true positives and false positives in the output results. In this context, server 204 (e.g., circuitry) can perform operations based on or according to parameters to determine the health status of a component.

[0080] 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 (208) 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 herein.

[0081] 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., driving 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 driving event. For example, Figure 3 Data extraction based on physical inference assumptions is described in more detail.

[0082] 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 drift). Assuming that the monitored sensor drift indicates thermal degradation or poisoning of the sensor, the server 204 can use the drift to predict or determine the sensor's time to failure or apparent useful life.

[0083] In some aspects, the server 204 utilizes additional or alternative assumptions (e.g., physical inference assumptions) in the model. For example, as an assumption, the NO2 concentration monitored over a 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 xThe invention relates to poisoning of a sensor so as to predict a failure of the sensor based on "persist not valid" in advance (eg, a predetermined time in advance from the occurrence of the failure).

[0084] Server 204 uses the collected data and performs data preparation or preprocessing based on 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 the data quality issues by filtering out null values ​​or sampling irregularities, such as using any data filtering technique to remove null values ​​and irregularities.

[0085] 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 NOx 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.

[0086] In response to the physical inference feature engineering, the server 204 maps the aggregate features on a timeline (eg, a graph, a table, a chart, etc.). x When aggregating features of a sensor's failure occurrence, the server 204 can identify or detect certain outliers within the data points over the timeline (222). In some cases, the aggregation regarding features of 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 a wait time). In some cases, the aggregation regarding features of the failure occurrence includes an aggregation based on a percentage error calculation of samples under certain operating conditions. For example, the 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. Thus, 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.

[0087] After preparing or preprocessing the data, the server 204 (e.g., the model development circuit 170) is configured to develop and train at least one model (226). To develop the model, the 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., an engine drive), 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 NOx is expected to be generated by the engine 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, allowing the sensor to activate or wake up and respond to changes in fuel supply), when driving begins, the NO x The measurement result of the sensor represents or reflects the offset value applied to the sensor.

[0088] An offset value refers to a calibration value applied to a sensor over time, such as due to gradual 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 the monitored system 102 based on expected degradation of the sensor over time, or by an administrator of the 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 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 Figures 5A-6C Shown in.

[0089] Once the training data set is generated, the server 204 (eg, the model development circuit 170 ) sends the training data set (eg, x The server 204 can train the model (230) accordingly by feeding the training dataset and providing the model with an indication that the dataset is a training sample. Because the training dataset (e.g., training sample) is validated or includes corresponding known health states associated with the measured values, the model can be trained to recognize features of subsequent samples (e.g., real-world samples). The model can 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, if 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.

[0090] Once trained with the training samples, 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. Server 204 can evaluate the model using various testing or evaluation techniques. For example, server 204 inputs the second training data and instructions for performing a health prediction process to the model. Server 204 receives 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. Server 204 compares the useful life of the first representation with the useful life of a second representation indicating the actual length of time until the sensor fails. The server 204 repeats this process for various iterations (e.g., 10, 50, 100, etc., as 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.

[0091] The server 204 aggregates the results from the evaluated model 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 the 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 can 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 can 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 the model (e.g., during the execution of the model).

[0092] 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 dataset 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., the current data point) during a driving event. Examples of further filtering the data point may include making one offset measurement represent the corresponding driving event, or performing other filtering techniques to identify erroneous data points. Accordingly, the server 204 is configured to return to prepare or preprocess the additional data or the current dataset to redevelop and retrain the model.

[0093] 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 that were generated from known samples or identified samples that had a healthy state and were processed to an unhealthy state until the sensor failed. For example, the validation sample can include data 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 the model performance and adjusting the model.

[0094] 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 life of the sensor or whether the sensor is approaching 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.).

[0095] 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 the 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.

[0096] 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 to the actual health state of the sensor (e.g., historical data for a faulty sensor), where activation of a fault code may be set as an exit criterion. For example, when a fault code is activated (or a lab test is performed), the sensor is confirmed to be faulty. For example, because the model is developed to predict a fault 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 Figure 9 An example of a heat map is shown.

[0097] In some embodiments, the exit criteria include at least a performance threshold (e.g., similar to operation 234), such as comparing the results from the processed 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 performance lifespan. The exit criteria may 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).

[0098] If the model performance meets the exit criteria, the server 204 outputs or enables the model for utilization (246). The exit criteria can be indicators of qualification or predetermined acceptance of model accuracy, precision, or other satisfactory conditions. Thus, when the model performance meets the exit criteria, the server 204 (e.g., one or more circuits) can 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) can use the trained model to predict component health. The server 204 can output a single model for various components. In various embodiments, the server 204 can output multiple models, each associated with a type of component, a type of engine 108, or other type of parameter. Thus, the server 204 can use the trained model to predict the health of the sensor.

[0099] In some embodiments, server 204 (e.g., model development circuitry 170) is configured to generate multiple models based on different sets of training data, collected features, or engine events. Server 204 can generate an ensemble model by integrating the individual models to predict any progressive 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., assumptions used in the model can be based on physical formulas and knowledge of chemical reactions in addition to or in lieu of empirical or population-based model development), the model can be engine platform and component agnostic (e.g., executable for any engine platform, component manufacturer, etc.).

[0100] refer to Figure 3 , depicts an example graph 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 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 drive event 302 (e.g., bits 0 and 1 indicating the drive event). For example, a motor sensor may provide a bit 1 (or 0) at the start of a drive and a bit 0 (or 1) at or after the active end of a drive.

[0101] To avoid or minimize the collection of data that does not represent sensor excursion during a 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, server 204 (or monitoring system 104) is configured with a wait time of a certain duration, such as 1 second, 2 seconds, etc. Server 204 filters the sensor data during the wait time, starting from the drive start time. Furthermore, the sensor is configured to discard at least one sample from a drive event 302 before the valid drive end time. For simplicity, the sensor may be configured to collect data at a 1 Hz frequency, recording one sample per second. Thus, server 204 is configured to discard the last second of data from a drive event 302. In various embodiments, server 204 is configured to discard drive events 302 that, for example, occur within a time period less than the wait time, have fewer than a predetermined number of samples, or have only one sample after the wait time.

[0102] Once at least one of the last samples at the end of the drive 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 drive event 302. The server 204 uses the collection of data points to monitor trends (e.g., characteristics) of the offset values ​​over time, such as shown in the graph 304. The graph representing the change in the offset value over time can be at least Figures 5A-6C The server 204 is configured to input the sensor offset values ​​into a machine learning model to predict health conditions.

[0103] 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 the data points (e.g., sensor offset values) over time. The trend in the data points may indicate, for example, an increase in sensor offset due to degradation of the sensor (e.g., due to 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 the time to failure 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 executed by the server 204. For example, the graph 304 shows that the NO during various driving events when the heater element of the sensor is degraded. x The increase in sensor drift over time.

[0104] For example, the server 204 may determine a deviation (e.g., a measurement deviation) between a first offset value (or first sensor measurement) at one occurrence of a driving event and a second offset value (or 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 aggregate operating conditions to which the sensor was exposed (e.g., temperature, exhaust flow, exhaust gas concentration, etc.), the server 204 is configured to obtain or determine a threshold value. The threshold value indicates an expected change in sensor offset between the two occurrences (e.g., two timestamps) based on at least one of the following: the operating time of the sensor at the time of the two occurrences, the exposure to the operating condition, the 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.

[0105] 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), server 204 may determine that the sensor is unhealthy. Thus, the executed model is configured to output a time-to-failure or a perceived useful life of the sensor based on various parameters, including the total operating time of the sensor, the degree of measurement deviation, an offset value (e.g., at least one of the first sensor measurement or the second sensor measurement), 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), server 204 is configured to indicate that the sensor is healthy. In some cases, if the threshold is not met, server 204 may be configured to provide a predetermined perceived useful life based on at least one of the operating time of the sensor, the current offset value, and other sensor data.

[0106] refer to Figure 4 , shows an example NO during engine driving for a faulty sensor x Sensor response. As shown, the diagram includes graph 400A and 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 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 the EONO represented by bit 1 and bit 0 during the same ECM operation time. x Status and drive flags (e.g. for active or inactive, enabled or disabled, and vice versa).

[0107] The driving flag indicates the start and end of the driving event. Sections 402A-402D (eg, sometimes referred to as section 402) represent the driving event. At section 402, during the driving event, NO x The sensor measurement drops to 0. In addition, NO x Output EO NO x The sensor status monitoring indicator may be zero. However, in graph 400B, the NO x Sensor for EO NO xThe status output is 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 dosing, catalyst, etc.) rely on at least the EO NO x status, so erroneous outputs may result from inaccuracies or misconfigurations, adjustments, or activations (or inactivations) of these components, leading to the escape of byproducts. 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 a sensor before a failure occurs.

[0108] Figures 5A-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 active sensor fault codes. x Sensor. Graphs 500A-500C represent various features calculated based on healthy NOx sensor data (without active sensor fault codes). Graphs 500A-500C include features associated with healthy sensors (e.g., NO x sensor, engine sensor, virtual sensor, etc. In this case, the data point represents the data point about NO x The expected rate of change of the sensor output 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 data from at least one NO x Graph 500A includes data points indicating NO for a healthy sensor. x The percentage of data points showing sensor invalid states activated or trending. Based on physics (e.g., physical 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 characteristics 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 through the 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 the target value, for example, 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 by measuring the NO x The controller receives status information and observes it.

[0109] Graph 500B includes an indication of the physical NO x The O2 measurement from the sensor is compared to the virtual NO x The percentage of deviation (i.e., error percentage) between the sensor's O2 measurements for the data points. 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 approximately 10% (e.g., 9%, 11%, 12%, etc.).

[0110] 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 indicate 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 it stopped). The data points of graphs 500A-500B may be collected during at least a portion of a drive event, such as that shown in graph 500C.

[0111] Now refer to Figures 6A-6C , depicting NO x Graphs 600A-600C of example abnormal measurements of sensors. Unhealthy NO x The sensors may be identified based on the presence of corresponding active sensor fault codes. Graphs 600A-600C represent the presence of unhealthy NO sensors based on the presence of active sensor fault codes. x Various features calculated from sensor data (e.g., showing healthy NO x Graphs 600A-600C may be similar to graphs 500A-500C for sensor data. Some elements of graphs 600A-600C (e.g., the types of data points) may be similar to graphs 500A-500C. For example, graph 600A shows that NO xGraph 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 may be provided to indicate a sensor fault (e.g., a malfunction or error in a sensor). In various embodiments, at least one of the graphs 600A-600C may be described in conjunction with at least graph 800 indicating offset data representing a remaining useful life or an apparent useful life of a sensor.

[0112] 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., as shown in conjunction with graph 600C). In this case, over time, the aggregate invalid state may exceed 50% of the total number of occurrences, with the sensor failing 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 characteristics, can be used to develop or train a model to predict the failure based on underlying physics.

[0113] Furthermore, as shown in graph 600B, during the driving event of graph 600C, the deviation between the measurements from the physical sensor and the virtual sensor increases over time (e.g., from 0 hours to 20,000 hours). For example, abnormal deviations at at least approximately 2,500 hours, 9,000 hours, and 16,500 hours of operation correspond to error percentages of approximately 12.5%, 16%, and 17.5%, respectively. Server 204 is configured to compare the deviations to a threshold. If the threshold is configured as 15%, the deviation results at at least 9,000 hours and 16,500 hours of operation can be used to determine the sensor's demonstrated useful life. For example, based on the operating time and various operating conditions or environments (e.g., historical data) of the internal combustion engine system to which the sensor was exposed during the operating time, server 204 can determine the sensor's demonstrated useful life. At 16,500 hours of operation, server 204 can determine the demonstrated useful life to be approximately half of the sensor's demonstrated useful life at 9,000 hours of operation, taking into account similar deviation percentages and operating time. In this example, using the trained model, the service life of the representation at 16,500 hours of operation 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 another service life that is lower than the service life at the deviation percentage of 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, remaining time) of a sensor is shown. Additional or alternative operations for determining the remaining lifetime of a sensor may be described herein (such as in Figure 10 (in) description.

[0114] refer to Figure 7 , depicting the 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 Graph 700 illustrates the predicted remaining operating time of a sensor and the associated prediction accuracy over time. In this case, the time on 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.

[0115] For example, server 204 collects or monitors sensor-related data. Using a model (or models), server 204 determines or predicts the remaining operating time of the sensor. Associated with each prediction of the remaining time, 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, server 204 determines the percentage accuracy based on the amount of data collected from the sensor, such that, for example, more sensor data may result in a more accurate prediction. In various embodiments, server 204 determines the percentage accuracy using the following formula: Percent Accuracy = 100 - abs[(actual ECM operating time at fault - predicted ECM operating time at fault) * 100 / actual ECM operating time at fault]. As shown, after the fault is predicted to occur in month 4, the fault code for the sensor becomes active the following month.

[0116] 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 monitored 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 Graph 800 may be executed, performed, or otherwise implemented by any other computing device described herein. Graph 800 may be generated by server 204 using, for example, a x In this case, as the data from the sensors is processed, the server 204 (eg, using a model) performs a prediction on the health state or remaining useful life of the sensors.

[0117] 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 drift (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.

[0118] For example, graph 800 illustrates an example of heater degradation (e.g., thermal degradation of the sensor's heater element). For purposes of this example, the faulty sensor associated with the sensor data may be installed on the engine outlet side (e.g., downstream of the engine). The engine system comprises a heavy-duty diesel engine for highway use and operates approximately 10 hours per day on average. As shown, the sensor's drift during driving events may increase over time as the sensor's predicted remaining useful life decreases. At approximately 11,180 hours of engine operation, a fault code is activated. Server 204 predicts a sensor failure before the fault code is triggered. In this case, server 204 predicts a sensor failure (e.g., indicating that the sensor's remaining useful life is less than 30 hours) at approximately 11,150 hours of operation.

[0119] refer to Figure 9 , depicting NO associated with different systems x A 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 900 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 any other computing device described herein to execute, perform, or otherwise implement the same.

[0120] For example, server 204 (or another server or data processing system) is configured to determine sensor health by executing a model (or models). Server 204 determines or predicts sensor health for 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 outputs generated from the model. For example, the remaining useful life represents the degradation of sensor health over time. When predicting the sensor health of different engine systems based on at least one of the model-predicted remaining useful life or a user-configured preference / configuration for advance notification (e.g., 30 days, 60 days, 90 days, etc.), server 204 (or the model) generates a heat map 900 that illustrates the corresponding sensor health status as at least one of "Healthy," "Nearly Unhealthy," or "Unhealthy." Based on the sensor health, server 204 is configured to recommend or instruct actions (e.g., maintenance or service actions) to be performed on the sensors (and other components associated with the monitored data). The actions may include at least one of sensor repair, sensor replacement, or other actions to avoid sensor failure. In various embodiments, the server 204 may provide email notifications or integrate with a portal (eg, accessible to the user via authentication credentials) to display predictions for the sensors to consume the output of the model to the user.

[0121] Now refer to Figure 10 , depicts a flow chart of an example method 1000 for a physical inference prediction method for component health prediction. The example method 1000 may be implemented 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 Method 1000 includes receiving a signal at step 1002. At step 1004, method 1000 includes determining a first measurement result and a second measurement result. At step 1006, method 1000 includes determining a measurement deviation. At step 1008, method 1000 includes comparing the measurement deviation to a threshold. At step 1010, method 1000 includes determining whether the measurement deviation meets the threshold. At step 1012, method 1000 includes determining a useful life of the representation.

[0122] Still refer to it in more detail Figure 10In step 1002, a server is configured to receive signals from a monitored system (e.g., at least one component of a monitored 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 a model. The monitored system includes at least an internal combustion engine (e.g., engine 108), a sensor (e.g., NOx), and a plurality of other components. x Sensors) and an engine control unit (e.g., monitored system 102). For example, the monitored system may be part of a vehicle. The engine control unit is configured to control or monitor engine operations, such as engine events, operating status, 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 functions to a telematics unit, such as collecting information associated with at least the engine and sensors and forwarding the information to a server for processing.

[0123] 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 hourly, daily, weekly, etc. In another example, the server may continuously receive the signal in response to new activity driven by a sensor or 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., actuation events, sometimes commonly referred to as engine events) for 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. Additionally, the server identifies measurement data from 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.

[0124] At step 1004, the server is configured to determine various measurement results (eg, NO, OFF ... x Measurement result or NO xsensor offset), or determine various measurements associated with corresponding occurrences of the engine event 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 type of engine event configured by an administrator of the server). In this context, the first occurrence can occur at a time before the second occurrence, such that the server can 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 can be plotted or mapped, such as at least Figure 3 At least as shown in graph 304 .

[0125] 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 approximately the same level as the second measurement. For example, the measurement may indicate sensor drift 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 become 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 indicate at least the progression of degradation on the sensor, the loss / gain of sensor sensitivity, and (e.g., through use of the machine learning models discussed herein) the sensor's perceived (e.g., remaining) useful life or time to failure.

[0126] 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 a first measurement at a first occurrence to a second measurement at a 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 has to various operating conditions of the vehicle system.

[0127] 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 a reference measurement result 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.

[0128] The server is configured to determine a first reference deviation between the first measurement result and a 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 may compare the first reference deviation and the second reference deviation with their respective reference thresholds (e.g., stored first and second reference thresholds). The reference thresholds may represent a maximum or minimum allowable deviation between the first or second measurement result and the reference measurement result. By comparing the deviations with the reference thresholds, the server may confirm whether the first or 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 or second reference thresholds may be similar to or equal to the measurement threshold.

[0129] In some cases, the server determines the measurement deviation between the first and second measurements 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 may be configured to determine the measurement deviation after determining that the first and second reference deviations are less than first and second reference thresholds, respectively. In this case, because the measurements over time are within the thresholds (e.g., the first and second measurements are within the reference error range), the server may be configured to use a predetermined lifetime of the representation based on at least the current level of the sensor's measurement / offset and the operating time. Determining the lifetime of the representation may be performed after comparing the deviation between the measurement result and the measurement threshold.

[0130] In other cases, the measurement result may exceed a reference threshold. Due to the reference threshold being exceeded, the server determines that the measurement result includes an abnormal response or offset value during the driving event. In this case, using a model, the server determines the lifetime of the representation based on various operating conditions of the vehicle system to which the sensor is exposed over time. These operating conditions include at least the amount of offset, 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 lifetime of the representation.

[0131] In some embodiments, the server is configured to determine a first measurement as discussed herein by applying a first offset to a first data point of the measurement data. Furthermore, the server is configured to determine a second measurement by applying a second offset to a second data point of the measurement data. For example, the sensor measurement may reflect an offset value during an engine event. The server may obtain the sensor offset as a measurement, for example, the first offset as the first measurement and the second offset as the second measurement.

[0132] 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 engine operation 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 characteristic may correspond to an expected characteristic, behavior, or feature of the data point during the driving event. The server determines a demonstrated operational characteristic based on the operational data and the measurement results (e.g., the first measurement result or the second measurement result). The demonstrated operational characteristic may correspond to an actual characteristic, behavior, or feature of the data point during the driving event. The server may determine a target deviation (e.g., a difference) between the target operating characteristic and the demonstrated operational characteristic. The server compares the target deviation to a stored target threshold.

[0133] Thus, if the server determines that the target deviation is less than or within the target threshold (e.g., the data point characteristics are within expectations), the server may then compare the measured deviation to the measurement threshold. In other cases, the server may remove at least one of the first or second measurements 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 such cases, the server is configured to remove the outlier measurement 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 or second measurements having characteristics outside the target threshold with a third, fourth, or other measurement associated with the corresponding occurrence of the engine event.

[0134] 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 in the offset value based on at least a time instance of occurrence and a level of offset between the first and second measurements. A measurement deviation satisfying the measurement threshold may mean that the offset 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 a higher-than-expected rate of change, indicating sensor degradation or deactivation. In certain aspects, satisfying the measurement threshold may mean that the measurement deviation is less than the threshold.

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

[0136] 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 gradual degradation), and the current measurement (or the most recently occurring measurement) exceeds a stored threshold, indicating degradation exceeding a certain level, the server may determine the useful life of the representation based on a predetermined useful life of the representation. For example, the predetermined useful life of the representation is based on at least the current measurement (e.g., the current deviation value) and the operating time. In other cases, if the deviation is outside the threshold (e.g., not within expected gradual degradation), the server executing the trained machine learning model is configured to determine the useful life of the representation based on at least the operating time of the vehicle system exposed to the sensor, the current deviation value, historical operating conditions, and other variables.

[0137] In response to determining the indicated useful life, the server is configured to transmit a signal (e.g., a response signal) to the monitored system (e.g., monitored system 102) to notify an operator of the indicated useful life. This notification may be provided via a display device, an audio device, or other user interface. The server is configured to send the notification signal based on a comparison of the indicated useful life with a indicated useful life threshold. For example, if the indicated useful life is less than the indicated useful life threshold, the server may send the notification signal to indicate that an operator (or other entity) should be alerted of the remaining useful life of the sensor. In some cases, the server may not provide the indicated useful life based on the indicated useful life being greater than a predetermined useful life threshold (e.g., 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.

[0138] In certain embodiments, the first signal is further associated with or includes a third occurrence of an internal combustion engine event in the monitored system. The first, second, and third measurements can be used to determine a rate of change of the sensor offset. For example, during the third occurrence, the server may determine a third measurement based on the first measurement data and the third occurrence of the engine event. After determining this, the server determines a rate of change (e.g., an aggregated rate of change, such as an average, mean, or median) between the first, second, and third measurements. The server compares the rate of change with a stored rate threshold. For example, the server may determine the rate threshold based on changes in sensor offset 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 useful life of a second representation of the sensor based on the rate of change and at least one of the first to third measurements (e.g., the most recent measurement). Therefore, in this case, the server is configured to monitor the trend (e.g., change) of the sensor offset over time to determine whether an increase or decrease in the offset is abnormal, thereby determining the useful life of the representation (e.g., the useful life of the second representation).

[0139] 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 associated with the first occurrence and a second operational measurement associated with the second occurrence. The first operational measurement and the second operational measurement can be similar to the reference measurement. For example, the operational measurement can 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 an error range of the threshold deviation. The server can determine the useful life of the first manifestation 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 useful life of the first manifestation. For example, the server can remove anomalous data points that are not within the error range of the virtual sensor measurement.

[0140] In some embodiments, the server is configured to compare the first demonstrated useful life to a stored demonstrated useful life threshold. The demonstrated useful life threshold indicates whether the demonstrated useful life indicates an unhealthy sensor or a healthy sensor. Based on whether the demonstrated useful life meets the threshold, the server compares first measurement data with second measurement data associated with a second monitored system (or any other monitored system providing measurement data of a faulty sensor). The server may determine a failure mode of the sensor (e.g., the first sensor) based at least on the demonstrated useful life, the first measurement data, and the second measurement data. For example, the server may compare trends in data points between the first measurement data and the second measurement data associated with one or more types of faults. The server may repeat this process using additional measurement data associated with other types of faults. Based on detecting similarities between the measurement data, the server is configured to determine a failure mode, including at least one of degradation of the heater of the first monitored system, a platinum stripping event of the first sensor, or poisoning of the first sensor.

[0141] 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 has been replaced with the second sensor. For example, when the first sensor is replaced with the second sensor, the monitored system may be triggered to send an indication of the sensor replacement to the server. In some cases, the server identifies the replacement of the first sensor based on the operating time of the second sensor (e.g., a different operating time or a reduced operating time). Furthermore, the server may receive another signal (e.g., a third signal) from the monitored system. The third signal is associated with or includes second measurement data from the second sensor. Thus, the server may discard, transfer, or reset historical data from the first sensor and continue to collect, analyze, and process the second measurement data from the second sensor.

[0142] In various embodiments, a 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: a third occurrence of a second internal combustion engine event for the second monitored system; a fourth occurrence of the second internal combustion engine event; and second measurement data from 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 driving event) and at least a fourth measurement result based on a fourth occurrence of the second engine event. The server then determines a second measurement deviation between the third and fourth measurement results. The server then compares the second measurement deviation to a stored measurement threshold, similar to step 1008. In this case, after determining that the second measurement deviation meets the measurement threshold, the server may determine a second representation of the useful life of the second sensor based on the second measurement deviation and at least one of the third or fourth measurement results. The server can thus repeat the operations, steps, or techniques discussed herein for other monitored systems to determine the status of additional sensors or components.

[0143] IV. Configuration of Example Embodiments

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

[0145] 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 this disclosure pertains. Those skilled in the art who review this disclosure should understand that these terms are intended to allow a description of certain features described and claimed without limiting the scope of such 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 invention as set forth in the appended claims.

[0146] 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.

[0147] As used herein, the term "fluidically coupled to" or the like refers to two components or objects having a path formed therebetween through which a fluid (e.g., air, exhaust gas, liquid reductant, gaseous reductant, aqueous reductant, gaseous ammonia, etc.) can flow with or without an intervening component or object. Examples of fluid couplings or structures 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.

[0148] 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 that come within the spirit and / or scope of the described embodiments are intended to be protected. It should be understood that some features may not be essential, and embodiments lacking various features may be considered within the scope of this application, as defined by the appended claims. When the language "a portion" is used, the item may include a portion and / or the entire item unless expressly stated to the contrary.

[0149] Furthermore, 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, or the like 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 stated, such connective language is generally not intended to imply that certain embodiments require at least one of X, at least one of Y, and at least one of Z to be present.

[0150] In addition, unless otherwise specified, 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.). Furthermore, unless otherwise specified, the value ranges (e.g., W to P, etc.) are not necessarily required to include intermediate values ​​within the value range (e.g., W to P may only include W and P, etc.).

[0151] This application also covers the following:

[0152] Item 1). At least one server, 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:

[0153] 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;

[0154] determining a first measurement result based on the first occurrence of the internal combustion engine event according to the first measurement data;

[0155] determining a second measurement result based on the first measurement data based on the second occurrence of the internal combustion engine event;

[0156] determining a measurement deviation between the first measurement result and the second measurement result;

[0157] comparing the measured deviation to a stored measurement threshold; and

[0158] After determining that the measurement deviation satisfies the measurement threshold, a first manifestation of the service 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.

[0159] Item 2). The at least one server according to item 1), wherein the instructions, when executed by the at least one processor, further cause the at least one server to:

[0160] determining a reference measurement result based on the first measurement data;

[0161] determining a first reference deviation between the first measurement result and the reference measurement result;

[0162] determining a second reference deviation between the second measurement result and the reference measurement result;

[0163] comparing the first reference deviation with a stored first reference threshold;

[0164] comparing the second reference deviation with a stored second reference threshold; and

[0165] The measurement deviation is determined 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.

[0166] Item 3). The at least one server according to Item 2), wherein the first reference threshold is equal to the measurement threshold.

[0167] Item 4). The at least one server according to item 2), wherein the instructions, when executed by the at least one processor, further cause the at least one server to:

[0168] determining the first measurement by applying a first offset to a first data point of the first measurement data; and

[0169] The second measurement is determined by applying a second offset to a second data point of the first measurement data.

[0170] Item 5). At least one server according to item 1), wherein:

[0171] The first signal is also associated with operational data of the first monitored system; and

[0172] The instructions, when executed by the at least one processor, further cause the at least one server to:

[0173] determining a target operating characteristic associated with said first measurement,

[0174] determining an operational characteristic of the performance based on the operational data and the first measurement result,

[0175] determining a target deviation between the target operating characteristic and the performed operating characteristic,

[0176] comparing the target deviation to a stored target threshold, and

[0177] After determining that the target deviation is less than the target threshold, the measured deviation is compared with the measured threshold.

[0178] Item 6). The at least one server of Item 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 being associated with an indication to replace the first sensor with a second sensor.

[0179] Item 7). At least one server according to item 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.

[0180] Item 8). At least one server according to item 1), wherein:

[0181] The first signal is further associated with a third occurrence of the internal combustion engine event of the first monitored system; and

[0182] The instructions, when executed by the at least one processor, further cause the at least one server to:

[0183] determining a third measurement result from the first measurement data based on the third occurrence of the internal combustion engine event,

[0184] determining a rate of change between the first measurement result, the second measurement result, and the third measurement result,

[0185] comparing the rate of change to a stored rate threshold, and

[0186] After determining that the rate of change satisfies the rate threshold, a second representation of the useful life 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.

[0187] Item 9). The at least one server according to item 8), wherein the instructions, when executed by the at least one processor, further cause the at least one server to:

[0188] 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;

[0189] comparing the measured deviation to the threshold deviation; and

[0190] After determining that the measured deviation satisfies the threshold deviation, a useful life of the first representation is determined.

[0191] Item 10). At least one server according to item 1), wherein:

[0192] The first measurement data indicates an amount of an exhaust byproduct associated with the first monitored system;

[0193] The measurement threshold is associated with the exhaust byproduct; and

[0194] 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.

[0195] Item 11). The at least one server of Item 1), wherein the instructions, when executed by the at least one processor, further cause the at least one server to:

[0196] comparing the useful life of the first representation to a stored useful life threshold for the representation;

[0197] 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; and

[0198] A failure mode of the first sensor is determined based on the useful life of the first manifestation, 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.

[0199] Item 12). The at least one server of Item 1), wherein the instructions, when executed by the at least one processor, further cause the at least one server to:

[0200] comparing the useful life of the first representation to a stored useful life threshold for the representation; and

[0201] A second signal is transmitted to the first monitored system, the second signal associated with a notification to replace the first sensor.

[0202] Item 13). A method comprising:

[0203] 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;

[0204] determining, by the at least one server, a first measurement result based on the first occurrence of the internal combustion engine event and the first measurement data;

[0205] determining, by the at least one server, a second measurement result based on the first measurement data and based on the second occurrence of the internal combustion engine event;

[0206] determining, by the at least one server, a measurement deviation between the first measurement result and the second measurement result;

[0207] comparing, by the at least one server, the measured deviation to a measurement threshold; and

[0208] After determining that the measurement deviation satisfies the measurement threshold, the at least one server determines a first representation of a useful life of the first sensor based on the measurement deviation and at least one of the first measurement result or the second measurement result.

[0209] Item 14). The method according to Item 13), further comprising:

[0210] determining, by the at least one server, a reference measurement result based on the first measurement data;

[0211] determining, by the at least one server, a first reference deviation between the first measurement result and the reference measurement result;

[0212] determining, by the at least one server, a second reference deviation between the second measurement result and the reference measurement result;

[0213] comparing, by the at least one server, the first reference deviation with a first reference threshold;

[0214] comparing, by the at least one server, the second reference deviation with a second reference threshold; and

[0215] 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.

[0216] Item 15). The method according to Item 14), further comprising:

[0217] determining, by the at least one server, the first measurement result by applying a first offset to a first data point of the first measurement data; and

[0218] 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.

[0219] Item 16). The method of Item 13), further comprising: receiving, by the at least one server, a second signal from the monitored system, the second signal being associated with an instruction to replace the first sensor with a second sensor.

[0220] Item 17). The method according to Item 16), further comprising: receiving, by the at least one server, a third signal from the monitored system, the third signal being associated with second measurement data of the second sensor of the monitored system.

[0221] Item 18). A network comprising:

[0222] A first monitored system, the first monitored system comprising:

[0223] The first internal combustion engine,

[0224] a first sensor, and

[0225] a first engine control unit; and

[0226] 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:

[0227] 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;

[0228] determining a first measurement result based on the first occurrence of the first internal combustion engine event according to the first measurement data;

[0229] determining a second measurement result based on the first measurement data based on the second occurrence of the first internal combustion engine event;

[0230] determining a first measurement deviation between the first measurement result and the second measurement result;

[0231] comparing the first measurement deviation to a stored measurement threshold; and

[0232] After determining that the first measurement deviation satisfies the measurement threshold, a first representative service 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.

[0233] Item 19). The network according to Item 18), further comprising a second monitored system, wherein the second monitored system comprises:

[0234] The second internal combustion engine,

[0235] a second sensor, and

[0236] a second engine control unit;

[0237] Wherein, when the instructions are executed by the at least one processor, the at least one server further causes:

[0238] 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;

[0239] determining a third measurement result from the second measurement data based on the third occurrence of the second internal combustion engine event;

[0240] determining a fourth measurement result based on the second measurement data based on the fourth occurrence of the second internal combustion engine event;

[0241] determining a second measurement deviation between the third measurement result and the fourth measurement result;

[0242] comparing the second measurement deviation to a stored measurement threshold; and

[0243] After determining that the second measurement deviation satisfies the measurement threshold, a second represented service 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.

[0244] Item 20). A network according to item 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.

Claims

1. At least one server, 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 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 based on the first occurrence of the internal combustion engine event according to the first measurement data; determining a second measurement result based on the first measurement data based on the second occurrence of the internal combustion engine event; determining a reference measurement result based on 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; 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, 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 service 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 first reference threshold is equal to the measurement threshold.

3. At least one server according to claim 1 or 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.

4. At least one server according to claim 1 or claim 2, 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 said first measurement, determining an operational characteristic of the performance based on the operational data and the first measurement result, 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 with the measured threshold.

5. At least one server according to claim 1 or claim 2, 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.

6. The at least one server according to claim 5, 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 associated with second measurement data of the second sensor of the first monitored system.

7. At least one server according to claim 1, 2 or 6, wherein: The first signal is further 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 from 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 second representation of the useful life 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.

8. The at least one server according to claim 7, 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.

9. At least one server according to claim 1, 2 or 6, 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.

10. At least one server according to claim 1, 2 or 6, 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 for the representation; comparing the first measurement data with 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 manifestation, 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.

11. At least one server according to claim 1 or claim 2, 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 for the representation; and A second signal is transmitted to the first monitored system, the second signal associated with a notification to replace the first sensor.

12. 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 based on the first occurrence of the first internal combustion engine event according to the first measurement data; 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 reference measurement result based on 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; 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, 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 representative service 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.

13. The network of claim 12, 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 from the second measurement data based on the third occurrence of the second internal combustion engine event; determining a fourth measurement result based on the second measurement data based on the fourth occurrence of the second internal combustion engine event; determining a second measurement deviation between the third measurement result and the fourth measurement result; comparing the second measurement deviation to a stored measurement threshold; and After determining that the second measurement deviation satisfies the measurement threshold, a second represented service 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.

14. The network according to claim 13, 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.

15. At least one server, 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 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, operational data 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 based on the first occurrence of the internal combustion engine event according to the first measurement data; determining a second measurement result based on 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; 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 performance characteristic and the performed performance characteristic; comparing the target deviation to a stored target threshold; After determining that the target deviation is less than the target threshold, comparing the measured deviation with a stored measurement threshold; as well as After determining that the measurement deviation satisfies the measurement threshold, a first manifestation of the service 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.

16. 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 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; receiving a second signal from the first monitored system, the second signal associated with an indication to replace the first sensor with a second sensor; determining a first measurement result based on the first occurrence of the internal combustion engine event according to the first measurement data; determining a second measurement result based on 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 service 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.

17. The at least one server according to claim 16, 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 associated with second measurement data of the second sensor of the first monitored system.

18. At least one server, 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 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, a third 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 based on the first occurrence of the internal combustion engine event according to the first measurement data; determining a second measurement result based on the first measurement data based on the second occurrence of the internal combustion engine event; 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 among the first measurement result, the second measurement result, and the third measurement result; comparing the rate of change to a stored rate threshold; 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; determining a measurement deviation between the first measurement result and the second measurement result; comparing the measured deviation to the threshold deviation; as well as After determining that the measurement deviation satisfies the threshold deviation, determining a useful 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; as well as After determining that the rate of change satisfies the rate threshold, a second representation of the useful life 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.

19. At least one server, 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: A first signal is received 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, wherein: The first measurement data indicates an amount of an exhaust byproduct associated with the first monitored system; determining a first measurement result based on the first occurrence of the internal combustion engine event according to the first measurement data; determining a second measurement result based on 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 measurement deviation to a stored measurement threshold associated with the exhaust byproduct; as well as After determining that the measurement deviation satisfies the measurement threshold, a first manifestation of the service 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.

20. At least one server, 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 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 based on the first occurrence of the internal combustion engine event according to the first measurement data; determining a second measurement result based on 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; After determining that the measurement deviation satisfies the measurement threshold, determining a first representation of the useful life of the first sensor based on the measurement deviation and at least one of the first measurement result or the second measurement result; comparing the useful life of the first representation to a stored useful life threshold for the representation; comparing the first measurement data with 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 manifestation, 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.

21. At least one server, 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 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 based on the first occurrence of the internal combustion engine event according to the first measurement data; determining a second measurement result based on 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; After determining that the measurement deviation satisfies the measurement threshold, determining a first representation of the useful life of the first sensor based on the measurement deviation and at least one of the first measurement result or the second measurement result; as well as comparing the useful life of the first representation to a stored useful life threshold for the representation; as well as A second signal is transmitted to the first monitored system, the second signal associated with a notification to replace the first sensor.

Images