Digital twin of fuel system

Abstract

Systems and apparatus include one or more processing circuitry having one or more storage devices, the one or more storage devices coupled with one or more processors. The one or more storage devices are configured to store instructions that, when executed by the one or more processors, cause the one or more processors to: receive information from at least one sensor; controlling operation of a vehicle subsystem based on the information; generating a digital twin output based on the information; generating a priority list of faults based on the digital twin output; and providing the priority list to an instrument panel.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit and priority of Indian Provisional Patent Application No. 202241053236 (titled “Digital Twin of Fuel System”, filed on September 17, 2022), which application is incorporated herein by reference in its entirety and for all purposes. Technical Field

[0002] The present disclosure relates to fault detection of vehicle systems. More specifically, the present disclosure relates to systems and methods for determining faults and root causes of vehicle systems or subsystems using digital twins. Background Art

[0003] Many vehicles include a fuel system. The fuel system includes various components, such as pumps, injectors, and sensors. The fuel system is generally a complex vehicle system. Given its complexity, diagnosing the fuel system can be resource intensive and time consuming when problems arise. Therefore, there is a need for improved systems and methods for diagnosing vehicle systems, such as fuel systems. Summary of the invention

[0004] One embodiment relates to an apparatus including one or more processing circuits, the processing circuits including one or more storage devices coupled to one or more processors. The one or more storage devices are configured to store instructions that, when executed by the one or more processors, cause the one or more processors to: receive information from at least one sensor; control operation of a vehicle subsystem based on the information; generate a digital twin output based on the information; generate a priority list of faults based on the digital twin output; and provide the priority list to a dashboard.

[0005] In some embodiments, the one or more processing circuits are located within the vehicle, particularly within an engine control module. In some embodiments, the digital twin output includes a fuel injection duration-injection amount (fueling on-time-to-quantity) indicator for a fuel injector. The one or more storage devices may be further configured to store instructions, which, when executed by the one or more processors, cause the one or more processors to: compare the digital twin output with the actual output; and generate a priority list of the faults based on the correlation between the digital twin output and the actual output. In some embodiments, the one or more storage devices may be further configured to store instructions, which, when executed by the one or more processors, cause the one or more processors to determine multiple faults based on prompts that the correlation exceeds a threshold. In some embodiments, the one or more storage devices may be further configured to store instructions, which, when executed by the one or more processors, cause the one or more processors to interface with a second digital twin on a remote control system.

[0006] Another embodiment relates to a system. The system may include a vehicle system and a controller coupled to the vehicle system. The controller may have one or more processors coupled to at least one memory. The controller may be configured to: receive information from at least one sensor; control the operation of the vehicle system based on the information; generate a digital twin output based on the information; generate a priority list of faults based on the digital twin output; and provide the priority list to a user interface on a computing device. In some embodiments, the controller may be configured to compare the digital twin output with the output of the vehicle subsystem to determine the correlation. In some embodiments, the controller may be configured to generate a priority list of faults based on the correlation of the digital twin output with the output. In some embodiments, the controller may be configured to determine multiple faults based on a prompt that the correlation exceeds a threshold. In some embodiments, the controller may be configured to communicate with a second digital twin on a remote control system to send telematics data.

[0007] In some embodiments, the controller may determine the digital twin output from the information using an artificial intelligence model of the digital twin. In some embodiments, the digital twin output may include a fuel injection duration-injection amount indicator for a fuel injector. In some embodiments, the controller may be located within a vehicle. In some embodiments, the vehicle system includes at least one of an aftertreatment system, a transmission, or an engine.

[0008] Another embodiment relates to a method for generating a priority list of faults using a digital twin. The method includes: receiving information from at least one sensor by one or more processors; controlling the operation of a vehicle system based on the information by the one or more processors; generating a digital twin output by the one or more processors based on the information; generating a priority list of faults based on the digital twin output by the one or more processors; and providing the priority list to an interface on a computing device by the one or more processors. In some embodiments, the method includes: comparing the digital twin output with an output of the vehicle system by the one or more processors to determine a correlation; and generating the priority list of faults based on the correlation of the digital twin output with the output by the one or more processors. In some embodiments, the method includes determining, by the one or more processors, a plurality of faults based on a prompt that the correlation exceeds a threshold. In some embodiments, the method includes communicating, by the one or more processors, with a second digital twin on a remote control system. In some embodiments, the method includes determining, by the one or more processors, the digital twin output from the information using an artificial intelligence model of the digital twin. In some embodiments, the one or more processors may be at least a portion of a controller located within the vehicle.

[0009] The foregoing summary is illustrative only and is not intended to be limiting in any way.Other aspects, inventive features, and advantages of the devices or processes described herein will become apparent from the following detailed description taken in conjunction with the accompanying drawings, wherein like reference numerals refer to like elements.

[0010] A large amount of specific details are provided, so that the embodiments of the present application theme are thoroughly understood. The described features of the present application theme can be combined in any suitable manner in one or more embodiments and / or implementations. In this regard, one or more features of an aspect of the present invention can be combined with one or more features of different aspects of the present invention. In addition, additional features may be present in some embodiments and / or implementations, and these additional features may not be present in all embodiments or implementations. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is a schematic diagram of a vehicle according to some embodiments.

[0012] Figure 2 According to some embodiments Figure 1 Schematic diagram of a controller of a vehicle.

[0013] Figure 3 According to some embodiments Figure 2 Schematic diagram of the control architecture of the controller.

[0014] Figure 4 According to some embodiments, Figure 3 Graph of the default and adapted curves generated by the control architecture.

[0015] Figure 5 According to some embodiments, Figure 3 Graph of the default and adapted curves generated by the control architecture.

[0016] Figure 6 According to some embodiments, Figure 3 Graph of the default and adapted curves generated by the control architecture.

[0017] Figure 7 According to some embodiments, Figure 3 Graph of the default and adapted curves generated by the control architecture.

[0018] Figure 8 According to some embodiments, the use Figure 2 Flowchart of a method for generating a prioritized list of root causes for a digital twin of a controller.

[0019] Fig. 9 According to some embodiments Figure 8 An exemplary schematic representation of the method. DETAILED DESCRIPTION

[0020] Below is a more detailed description of various concepts and implementations related to methods, devices, and systems for determining failures and root causes of vehicle systems using digital twins. Before turning to the drawings that detail certain example embodiments, it should be understood that the present application is not limited to the details or methods described in the specification or drawings. It should also be understood that the terminology used herein is for descriptive purposes only and should not be considered as limiting.

[0021] Referring generally to the accompanying drawings, various embodiments disclosed herein relate to systems, devices, and methods for digital twins of vehicle systems or subsystems (e.g., fuel injectors) that are used to identify faults and generate a prioritized list of root causes associated with the identified faults. The digital twin receives the same inputs as a vehicle controller (e.g., an engine control unit) and includes a control architecture that can introduce errors into the digital twin model. The digital twin can then generate expected results for the introduced errors. The expected results are then compared to the real-world outputs of the system, which can be used to assign priorities to the introduced errors. For example, the better the expected results match the real-world outputs, the higher the priority assigned. In some embodiments, the real-world output includes multiple expected results, and the digital twin can rank or prioritize each expected result. The systems, methods, and devices described herein can provide improved diagnostic and predictive capabilities compared to traditional systems.

[0022] like Figure 1 As shown, vehicle 10 includes system 14 in the form of an engine and subsystem 18 in the form of a fuel injector. In some embodiments, system 14 includes an aftertreatment system, a transmission, or another vehicle system. In some embodiments, subsystem 18 includes different components (e.g., a diesel exhaust fluid metering pump, an oxygen sensor, a transmission shift actuator, etc.). System 14 and subsystem 18 may include any component or system of vehicle 10 that is monitored for failure, aging, or that may require maintenance or replacement. Although portions of the following description are directed to a fuel injector for an engine, other systems and subsystems may utilize the concepts, devices, systems, and methods described herein.

[0023] The vehicle 10 also includes a controller 22 in the form of an engine control unit. In some embodiments, the controller 22 is a transmission control unit, a dedicated (i.e., separate) controller, or another controller of the vehicle 10. The controller 22 controls the operation of the system 14 and / or the subsystems 18. For example, the controller 22 controls the fuel pump and the fuel injectors during operation of the vehicle 10.

[0024] The controller 22 includes a digital twin 26 that includes policies that mimic the operation of the system 14 and subsystems 18. The digital twin 26 is located on the controller 22 and receives the same inputs (e.g., sensors, actuator feedback, external information, etc.) as the controller 22. The digital twin 26 provides a digital copy of the operating state and output information of the system 14 and subsystems 18.

[0025] In some embodiments, the remote digital twin 28 is maintained in parallel with the digital twin 26. In some embodiments, the remote digital twin 28 is located on a cloud or network server, a dedicated remote server, a computer or other processor remote from the vehicle 10, or any combination of locations. The remote digital twin 28 can operate similarly to the digital twin 26 to provide a remote representation of the system 14 and / or subsystem 18. Although the following description references the actions of the digital twin 26, these same actions can also exist in the remote digital twin 28.

[0026] because Figure 1 The components in FIG. 1 are shown as an embodiment of the vehicle 10. The controller 22 may be constructed as one or more electronic control units (ECU) (e.g., engine control module (ECM)). The controller 22 may be independent of a transmission control unit, an exhaust aftertreatment control unit, a powertrain control module, an engine control module, or the like, or may be included in at least one of the units. The functions and structures of the controller 22 are shown in FIG. Figure 2 A more detailed description is given in .

[0027] Now refer to Figure 2 , according to an example embodiment, shows Figure 1 Schematic diagram of the controller 22 of the vehicle 10. Figure 2 As shown, the controller 22 includes a processing circuit 26 having a processor 30 and a storage device 34, a control system 38 having a digital twin 26, an input circuit 42, a priority circuit 50, and an output circuit 54. The controller 22 also includes a communication interface 58. Generally, the controller 22 is configured to operate the system 14 and subsystems 18, and operate the digital twin 26 to identify faults and prioritize potential root causes for resolving the identified faults.

[0028] In one configuration, the control system 38 is embodied as a machine or computer readable medium that can be executed by a processor (such as processor 30). As described herein and in addition to other uses, the machine readable medium facilitates the execution of certain operations, making the reception and transmission of data possible. For example, the machine readable medium can provide instructions (e.g., commands, etc.) to the processor to obtain data. In this regard, the machine readable medium may include programmable logic that defines the frequency of data acquisition (or data transmission). The computer readable medium may include code that can be written in any programming language, including but not limited to Java or similar languages ​​and any traditional programming language, such as the "C" programming language or similar programming languages. The computer readable program code can be executed on one processor or on multiple remote processors. In the latter case, the remote processors can be interconnected via any type of network (e.g., CAN bus, etc.).

[0029] In another configuration, the control system 38 is embodied as a hardware unit, such as an electronic control unit. Thus, the control system 38 may be embodied as one or more circuit components, including, but not limited to, processing circuits, network interfaces, peripherals, input devices, output devices, sensors, and the like. In some embodiments, the control system 38 may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (ICs), discrete circuits, system-on-chip (SOC) circuits, microcontrollers, and the like), telecommunications circuits, hybrid circuits, and any other type of "circuitry". In this regard, the control system 38 may include any type of components for accomplishing or facilitating the operations described herein. For example, the circuits described herein may include one or more transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR, and the like), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, and the like. The control system 38 may also include programmable hardware devices, such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. The control system 38 may include one or more storage devices for storing instructions executable by a processor of the control system 38. The one or more storage devices and processors may have the same definitions as provided below with respect to storage device 34 and processor 30. In some hardware unit configurations, control system 38 may be geographically dispersed at different locations in the vehicle. Alternatively, as shown, control system 38 may be embodied within or within a single unit / housing, which is shown as controller 22.

[0030] In the illustrated example, the controller 22 includes a processing circuit 26 having a processor 30 and a storage device 34. The processing circuit 26 may be constructed or configured to execute or implement the instructions, commands, and / or control processes described herein with respect to a control system 38. The described configuration represents the control system 38 as a machine or computer readable medium. However, as described above, such illustration is not meant to be limiting, as the present disclosure contemplates other embodiments in which the control system 38 or at least one circuit of the control system 38 is configured as a hardware unit. All such combinations and variations are intended to fall within the scope of the present disclosure.

[0031] The hardware and data processing components (e.g., processor 30) used to implement the various processes, operations, illustrative logic, logic blocks, modules, and circuits associated with the embodiments disclosed herein may be implemented or executed by a general purpose single-chip or multi-chip processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, which are designed to perform the functions described herein. A general purpose processor may be a microprocessor, any conventional processor, or a state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. In some embodiments, one or more processors may be shared by multiple circuits (e.g., the control system 38 may include or otherwise share the same processor, which may execute instructions stored or otherwise accessed through different memory areas in some example embodiments). Alternatively, one or more processors may be configured to perform certain operations independently of one or more coprocessors. In other example embodiments, two or more processors may be coupled by a bus to enable independent, parallel, pipelined, or multithreaded instruction execution. All of these variations are within the scope of the present disclosure.

[0032] The storage device 34 (e.g., memory, storage unit, storage device) may include one or more devices (e.g., RAM, ROM, flash memory, hard disk storage) for storing data and / or computer code to complete or facilitate the various processes, layers, and modules described in the present disclosure. The storage device 34 may be communicatively connected to the processor 30 to provide computer code or instructions to the processor 30 for performing at least part of the processes described herein. In addition, the storage device 34 may be or include tangible, non-transient volatile memory or non-volatile memory. Thus, the storage device 34 may include a database component, an object code component, a script component, or any other type of information structure for supporting the various activities and information structures described herein.

[0033] The input circuitry 42 is configured to receive and process information received from sensors and actuators of the system 14 and subsystems 18. For example, the input circuitry 42 may receive pressure information from a fuel rail pressure sensor, temperature information from a fuel rail temperature sensor, flow rate information from an injector flow rate sensor, injector injection duration information from a transistor-transistor logic (TTL) system, pump status information from a fuel pump, fuel quality information from a fuel quality sensor, and other desired inputs. The input circuitry 42 is configured to process the received information for use within the control system 38. In some embodiments, the inputs received by the input circuitry 42 are different and are associated with different systems 14 and / or subsystems 18. For example, if the digital twin 26 is replicating an oxygen sensor, the input circuitry 42 may receive information indicative of the operation of the oxygen sensor (e.g., upstream NOx, downstream NOx, engine outlet temperature, system outlet temperature, flow rate information, etc.).

[0034] The digital twin 26 is configured to receive information processed by the input circuit 42. The controller 22 is configured to control the operation of the system 14 and / or subsystem 18 using the information processed by the input circuit 42, in parallel with the operation of the digital twin 26. In some embodiments, the digital twin 26 is located on the controller 22 within the vehicle 10. The digital twin 26 is configured to implement a strategy to replicate the state and output of the system 14 and / or subsystem. The output of the digital twin 26 provides expected results based on the processed information and the digital twin prompts determined by the strategy. For example, when the subsystem 18 is a fuel injector, the output of the digital twin 26 is a fuel injection duration-injection amount curve at a given rail pressure. The prompts determined by the strategy may include potential error sources that the digital twin 26 wants to test (e.g., a descending list of possible faults or failures).

[0035] In some embodiments, the strategy includes an artificial intelligence engine that learns over time to accurately replicate the system 14 and / or subsystem 18. The artificial intelligence engine can be any architecture, such as an artificial neural network (ANN), a support vector machine (SVM), a clustering algorithm (e.g., k-means clustering), a naive Bayes classifier, a regression model (e.g., linear or logistic regression), and factor analysis, etc., or any combination thereof. The artificial intelligence engine can be trained using training data according to a learning technique (e.g., supervised or unsupervised). The training data can include inputs (e.g., prompts or sensor data from the system 14 or subsystem 18) and expected outputs associated with the inputs. Once the training is complete, the artificial intelligence engine on the digital twin 26 can be used to process new inputs (e.g., prompts or sensor data) to generate new expected outputs. In some embodiments, the strategy is model-based (e.g., a set of equations) and can be updated periodically (e.g., on a set schedule, at each service event of the vehicle 10, at a predetermined mileage interval, etc.). During the operation of the digital twin 26, the strategy will inject prompts and output relevant expected results. In this way, the digital twin 26 generates a list of expected results and related prompts (ie, incorrect inputs).

[0036] The priority circuit 50 is configured to receive expected results and related prompts from the digital twin 26, as well as processing information from the input circuit 42. The priority circuit 50 compares the expected results with the real-world or default results of the system 14 and / or subsystem 18. For example, the priority circuit 50 compares the fuel injection duration-injection amount curve of the fuel injector provided by the digital twin 26 with the default or real-world fuel injection duration-injection amount curve. The strength of the correlation between the digital twin output and the real-world output is used to define the priority of the digital twin output. For example, a highly correlated digital twin output (i.e., a good match) will be given a higher priority than a low-correlation digital twin output (i.e., a poor match). The priority circuit 50 generates a descending fault list of digital twin outputs sorted from highest to lowest priority.

[0037] The output circuit 54 is constructed to receive the fault list from the priority circuit 50 and associate a set of top digital twin outputs with the root cause of each top digital twin output. In some embodiments, the top digital twin output is defined as an output with a priority higher than a threshold. For example, the top digital twin output may include any digital twin output whose relevance exceeds a threshold (e.g., the top ten percent with the highest relevance). In some embodiments, the top digital twin output includes the three digital twin outputs with the highest relevance. In some embodiments, more than three or less than three digital twin outputs may be included. The output circuit 54 can use any root cause determination system to identify potential methods that may repair the problem or error identified by the digital twin 26. The output circuit 54 provides the top digital twin output and the associated root cause to the instrument panel 62, the data output 66, and the telematics system 70.

[0038] In some embodiments, the dashboard 62 is an interactive graphical user interface (GUI) that can be accessed via a mobile device, tablet, computer, or workstation computer. The dashboard 62 provides the user with top-level digital twin outputs and associated root causes. In some embodiments, the dashboard 62 is located in a service center to help mechanics or technicians repair the system 14 and / or subsystem 18. For example, the dashboard 62 may indicate a list of the top three faults and their associated root causes, enabling technicians to identify and repair problems more quickly and cost-effectively.

[0039] In some embodiments, the data output 66 may be used to assemble digital twin information, processed inputs, top-level digital twin outputs, and associated root causes into a data package for use outside the vehicle 10. For example, the data output 66 may provide information to a remote digital twin 28 or another remote control system. In some embodiments, the data output 66 may be used to update a digital twin policy that is remote from the vehicle 10, allowing the policy to be updated regularly. For example, the policy in the remote digital twin 28 may be updated based on data packages received from multiple vehicles 10 in a fleet. The policy updated in the remote digital twin 28 can then be updated in the local digital twin 26. For example, the data output 66 may be provided during a service event (or on another schedule) and then the policy is updated on the local digital twin 26 of the vehicle 10.

[0040] In some embodiments, telematics 70 allows information from the controller 22 to be distributed between the vehicle and a remote controller (e.g., remote digital twin 28) in a vehicle-to-X communication (V2X) system. This can enable a more integrated fleet, gaining advantage through a wider range of experiences available to the digital twin 26. Telematics 70 can communicate between vehicles 10 or with a remote controller (e.g., remote digital twin 28).

[0041] like Figure 3 As shown, the system architecture 74 can be implemented on the digital twin 26. At step 78, the fuel rail pressure is received from the input circuit 42. At step 82, the injector injection duration is received from the input circuit 42. At step 86, the pressure function block receives the pressure and the injector injection duration and determines the amount of fuel delivered to the injector (INJ_Q) 90, the fuel flow rate delivered to the injector (INJ_FLOW) 94, the amount of fuel drained from the injector through leakage (DRAIN_Q) 98, and the fuel flow rate drained from the injector valve (DRAIN_FLOW) 102.

[0042] At step 106, INJ_Q 90 and DRAIN_Q 98 are added to provide a total fuel quantity which is provided to step 110 which includes a pressure change determination function block (CALC DELTA P). Step 110 also receives pressure information 78 and fuel temperature information 114 from input circuit 42. Step 110 determines a pressure change (DELTA_P) 118 due to operation of the injector during the injection duration 82. DELTA_P 118 is indicative of injector valve operation.

[0043] At step 122, a scaling offset including a prompt is introduced. The digital twin 26 injects the prompt (e.g., error) into the system architecture 74. For example, the digital twin 26 may inject an error associated with an increased exhaust flow path restriction, a decreased exhaust flow path restriction, or a deviation (positive and negative) of a rail pressure sensor. Other errors / prompts are contemplated, and different systems 14 or subsystems 18 may include different errors / prompts associated with these systems. The prompts may include typical offset errors associated with the target error. The prompt list may be developed by the artificial intelligence engine of the digital twin 26, received from telematics 70, the remote digital twin 28, and / or reviewed from different sources (e.g., a predetermined list based on maintenance history or warranty claims). Step 122 determines a processed pressure change (PROCESSED_DELTA_P) based on the prompt. PROCESSED_DELTA_P represents the expected pressure change that the fuel injector will produce if the introduced prompt / error is present.

[0044] At step 126, PROCESSED_DELTA_P is received by the injection quantity calculation function block, along with the pressure information 78 and the temperature information 114. Step 126 determines the total injected fuel quantity (CALC_QUANTITY) that is expected to be delivered based on the prompt. In other words, CALC_QUANTITY is the amount of fuel that would be delivered if there was a prompt / fault in the injector.

[0045] At step 130, the amount of fuel to be discharged (INJ_DRAIN) is determined based on DRAIN_Q 98 and pressure information 78. CALC_QUANTITY and DRAIN_Q 98 of step 126 are provided to step 134 where a difference is calculated and the expected amount of fuel delivered is determined at step 138. The expected amount of fuel delivered represents the volume of fuel that the injector is expected to actually deliver when the prompt is present.

[0046] At step 142, the digital twin 26 determines the current injection duration of the injector (e.g., the same as the injector injection duration of step 82) to provide the desired delivered fuel quantity. At step 146, the current injection duration and pressure information 78 are used to determine an adapted fuel injection duration-injection quantity curve based on the prompt.

[0047] like Figure 4 As shown, the output generated by the digital twin 26 includes an injection duration-injection amount graph 150, where the x-axis is the injection duration in milliseconds and the y-axis is the delivered fuel amount in milligrams (e.g., the expected delivered fuel amount determined in step 138). Graph 150 is provided for a specific pressure (e.g., pressure information 78) and shows the volume of fuel delivered by the injector within a given injection duration. A default or real-world curve 154 (e.g., an ideal injector curve 154, if there is no anomaly) represents the injection duration-injection amount curve experienced by the injector in the real world. Adaptation curve 158 represents the injection duration-injection amount curve generated by the digital twin 26 based on the prompt (e.g., the adapted fuel injection duration-injection amount curve generated in step 146). For example, the prompt represented in graph 150 is a drain path obstruction. The adaptation curve 158 has a relatively low correlation with the default curve 154, and the drain path obstruction prompt is given a low priority.

[0048] like Figure 5 As shown, the digital twin 26 generates an injection duration-injection amount graph 162, investigating a very low exhaust path blockage prompt, including a default curve 166 and an adaptation curve 170. The adaptation curve 170 has a very high correlation with the default curve 166, and the priority circuit 50 assigns a high priority to the very low exhaust path blockage prompt. This indicates to the output circuit 54 that the very low exhaust path blockage prompt should be recommended as an error, rather than Figure 4 The output circuit 54 will determine the root cause of the very low exhaust path obstruction indication and provide the root cause and potential fixes to the dashboard 62.

[0049] like Figure 6As shown, the digital twin 26 generates an injection duration-injection quantity graph 174 to investigate scaling error cues in the rail pressure sensor, including a default curve 178 and an adapted curve 182. The correlation of the curves shows that as the fuel injection duration increases, the difference between the adapted curve 182 and the default curve 178 increases because the injector is experiencing scaling error.

[0050] like Figure 7 As shown, the digital twin 26 generates an injection duration-injection quantity graph 186 to investigate very low scaling error hints in the rail pressure sensor, including a default curve 190 and an adapted curve 194. The correlation of the curves shows that the adapted curve 194 and the default curve 190 remain close to each other with a high correlation because the introduced error is very low, which reflects an ideal healthy scenario for the sensor information and injector operation.

[0051] like Figure 8 As shown, the controller 22 is configured to implement a method 200 for determining a fault using a digital twin 26. At step 204, the digital twin 26 receives information from the input circuit 42. At step 208, the controller 22 controls the operation of the system 14 and the subsystem 18 (e.g., the injector) based on the information received at step 204. At step 212, the digital twin 26 processes the information received at step 204 and generates an output based on the prompt.

[0052] At step 216, the prompts with a relevance exceeding a threshold are determined to be included in a top result list (e.g., a top five list, a top ten list, a top three list, etc.) and are determined to be potential faults. At step 220, the root causes are associated with the identified faults using a root cause engine, historical data, etc. At step 224, the root causes and related faults are prioritized by the priority circuit 50 based on their relevance, and the output circuit 54 provides the priority list to the dashboard 62 at step 228.

[0053] The DELTA_Q determined by the digital twin 26 at step 134 includes an average / weighted value, and intermittent problems do not affect the average value of DELTA_Q, so the output of the digital twin 26 captures only the gradual drift of injector fuel supply. In a service event, the output of the digital twin 26 includes multiple representations of all error sources, which are compared to the current adapted fuel injection duration to indicate the most likely cause of the fault at the system level.

[0054] The digital twin 26 allows for reduced service time and reliable detection of root causes associated with robust repairs. The digital twin can be implemented on the vehicle 10 for continuous prognostic / health checks or remotely / offline via telematics 70 and data acquisition processes, allowing for offline data processing by the remote digital twin 28 to provide input to the service team. The digital twin 26 allows for analysis of combined failure modes such as the effect of a partially blocked exhaust flow valve and a noise sensor on fuel injection duration.

[0055] The digital twin 26 can also be used to simplify the engine tuning process. For example, the digital twin 26 can help avoid the conventional laborious methods to troubleshoot closed loop fuel control (CLFC) problems because the measurement events are not stored to reproduce the problem. The digital twin 26 can avoid re-verifying each step of the CLFC tuning.

[0056] In addition, the digital twin 26 can learn how the system 14 (e.g., engine) affects the subsystem 18 to find deeper fault possibilities. For example, the injector discussed above may be affected by the operation of non-fuel system components. The digital twin 26 is able to learn new connections and causal relationships and improve diagnostic capabilities by learning new relationships within the system 14.

[0057] Fig. 9 An example workflow of the method 200 is shown. Parameters of an injector (e.g., subsystem 18) are mapped to the digital twin 26. The illustrated method 200 generates five prompts (e.g., pressure sensor problem, high pressure pump problem, injector problem, fuel quality, and wiring harness problem) and outputs an injection duration-injection amount curve for each prompt. These curves are then compared to normal fuel injection duration-injection amount curves and real-world or field fuel injection duration-injection amount curves, and a priority list is generated for use by the service team.

[0058] As used herein, the terms "approximately," "about," "substantially," and similar terms are intended to have a broad meaning consistent with commonly accepted usage by persons of ordinary skill in the art to which this disclosure relates. It should be understood by those of skill in the art who review this disclosure that these terms are intended to allow for the description of certain features without limiting those features to the precise numerical ranges provided. Accordingly, these terms should be interpreted as indicating that insubstantial or insignificant modifications or alterations of the subject matter described and claimed are considered to be within the scope of the disclosure as described in the appended claims.

[0059] It should be noted that the term "exemplary" and variations thereof are used herein to describe various embodiments and are intended to indicate that these embodiments are possible examples, representations, or illustrations (these terms are not intended to imply that these embodiments are necessarily extraordinary or exceptional examples).

[0060] The term "coupled" and its variations, as used herein, refers to two members being connected together, directly or indirectly. Such connection may be static (e.g., permanent or fixed) or removable (e.g., removable or releasable). Such connection may be achieved by coupling the two members directly, by coupling the two members using one or more separate intermediate members, or by coupling the two members using an intermediate member that forms a single entity with one of the two members. If "coupled" or its variations are modified by additional terms (e.g., directly coupled), the general definition of "coupled" provided above is modified by the ordinary language meaning of the additional terms (e.g., "directly coupled" means the connection of the two members without any separate intermediate members), resulting in a narrower definition than the general definition of "coupled" provided above. Such coupling may be mechanical, electrical, or fluid. For example, circuit A being "communicatively coupled" to circuit B may mean that circuit A communicates directly with circuit B (i.e., without an intermediary) or indirectly with circuit B (e.g., through one or more intermediaries).

[0061] References to element positions herein (e.g., "top," "bottom," "above," "below") are only used to describe the orientation of the various elements in the drawings. It should be noted that the orientation of the various elements may differ according to other example embodiments, and these variations are intended to be covered by the present disclosure.

[0062] Although Figure 2 Various circuits are shown with specific functions, but it should be understood that the controller 22 may include any number of circuits for performing the functions described herein. For example, the activities and functions of the control system 38 may be combined in multiple circuits or as a single circuit. Additional circuits with additional functions may also be included. In addition, the controller 22 may further control other activities beyond the scope of the present disclosure.

[0063] As described above, in one configuration, the “circuitry” may be implemented in a machine-readable medium to be executed by various types of processors, e.g. Figure 2processor 30. An identified executable code circuit may, for example, include one or more physical or logical blocks of computer instructions, which may, for example, be organized as objects, procedures or functions. However, the executable code of the identified circuit need not be physically located together, but may include different instructions stored in different locations, which, when logically connected together, constitute the circuit and achieve the intended purpose of the circuit. In practice, a circuit of computer readable program code may be a single instruction, or multiple instructions, and may even be distributed across several different code segments, different programs and different storage devices. Similarly, operating data may be identified and described within the circuit and may be embodied in any suitable form and organized in any suitable type of data structure. The operating data may be collected as a single data set, or may be distributed across different locations, including different storage devices, and may exist at least in part only as electronic signals on a system or network.

[0064] Although the term "processor" is briefly defined above, the terms "processor" and "processing circuit" are interpreted broadly. In this regard, as described above, a "processor" may be implemented as one or more general-purpose processors, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), or other suitable electronic data processing components that are constructed to execute instructions provided by a memory. One or more processors may take the form of a single-core processor, a multi-core processor (e.g., a dual-core processor, a triple-core processor, a quad-core processor, etc.), a microprocessor, etc. In some embodiments, one or more processors may be located outside the device, for example, one or more processors may be remote processors (e.g., cloud-based processors). Alternatively, one or more processors may be internal and / or close to the device. In this regard, a given circuit or component thereof may be located locally (e.g., as part of a local server, a local computing system, etc.) or remotely (e.g., as part of a remote server such as a cloud-based server). To this end, the "circuit" described herein may include components distributed in one or more locations.

[0065] Embodiments within the scope of the present disclosure include program products, which include machine-readable media for carrying or storing machine-executable instructions or data structures. Such machine-readable media can be any available media that can be accessed by a general-purpose or special-purpose computer or other machine with a processor. As an example, such machine-readable media can include RAM, ROM, EPROM, EEPROM or other optical disk storage, disk storage or other magnetic storage devices, or any other media that can be used to carry or store required program code in the form of machine-executable instructions or data structures, and can be accessed by a general-purpose or special-purpose computer or other machine with a processor. Combinations of the above are also included in the scope of machine-readable media. Machine-executable instructions include, for example, instructions and data that cause a computer (such as a special-purpose computer or a special-purpose processing machine) to perform a certain function or a group of functions.

[0066] Although the illustrations and descriptions may illustrate a particular order of method steps, the order of these steps may be different from that described and shown, unless otherwise noted above. In addition, two or more steps may be performed simultaneously or partially simultaneously, unless otherwise noted above. Such variations may depend on, for example, the software and hardware systems selected and the designer's choices. All such variations are within the scope of the disclosure. Similarly, software implementations of the methods can accomplish the various connection steps, processing steps, comparison steps, and decision steps through standard programming techniques, rule-based logic, and other logic.

[0067] It should be noted that the structure and arrangement of the digital twin 26 in the various example embodiments are merely illustrative. In addition, any element disclosed in one embodiment may be combined or used with any other embodiment disclosed herein. Although only an example of an element in one embodiment being incorporated or used in another embodiment is described above, it should be understood that other elements of the various embodiments may be combined or used with any other embodiment disclosed herein.

Claims

1. A device, characterized in that: include: One or more processing circuits, the processing circuits comprising one or more storage devices, the one or more storage devices coupled to the one or more processors, the one or more storage devices configured to store instructions that, when executed by the one or more processors, cause the one or more processors to: receiving information from at least one sensor; controlling operation of vehicle subsystems based on the information; generating a digital twin output based on the information; generating a prioritized list of faults based on the digital twin outputs; as well as The priority list is provided to a dashboard.

2. The device according to claim 1, characterized in that The one or more processing circuits are located within the vehicle.

3. The device according to claim 2, characterized in that The one or more processing circuits are located within an engine control module.

4. The device according to claim 1, characterized in that The digital twin output includes a fuel injection duration-injection quantity indicator for a fuel injector.

5. The device according to claim 4, characterized in that The one or more storage devices are further configured to store instructions that, when executed by the one or more processors, cause the one or more processors to: comparing the digital twin output with the actual output; and A priority list of the faults is generated based on the correlation between the digital twin output and the actual output.

6. The device according to claim 1, characterized in that The one or more storage devices are further configured to store instructions that, when executed by the one or more processors, cause the one or more processors to determine a plurality of faults based on at least one indication that the correlation exceeds a threshold.

7. The device according to claim 1, characterized in that The one or more storage devices are further configured to store instructions that, when executed by the one or more processors, cause the one or more processors to communicate with a second digital twin on the remote control system.

8. A system, characterized in that: include: Vehicle systems; as well as A controller coupled to the vehicle system, the controller having one or more processors coupled to at least one memory, the controller being configured to: receiving information from at least one sensor; controlling operation of said vehicle systems based on said information; generating a digital twin output based on the information; generating a prioritized list of faults based on the digital twin outputs; as well as The priority list is provided to a user interface on a computing device.

9. The system according to claim 8, characterized in that The controller is further configured to: comparing the digital twin output to an output of the vehicle system to determine a correlation; and A priority list of the faults is generated based on the correlation between the digital twin output and the actual output.

10. The system according to claim 8, characterized in that The controller is further configured to determine a plurality of faults based on indications that the correlation exceeds a threshold.

11. The system according to claim 8, characterized in that The controller is further configured to communicate with a second digital twin on the remote control system to send telematics data.

12. The system according to claim 8, characterized in that The controller is further configured to determine the digital twin output from the information using an artificial intelligence model of the digital twin.

13. The system according to claim 8, characterized in that The digital twin output includes a fuel injection duration-injection quantity indicator for a fuel injector.

14. The system according to claim 8, characterized in that The controller is located in a vehicle, and the vehicle system includes at least one of an aftertreatment system, a transmission, or an engine.

15. A method for generating a priority list of faults using a digital twin, characterized in that: include: receiving, by one or more processors, information from at least one sensor; controlling, by the one or more processors, operation of a vehicle system based on the information; generating, by the one or more processors, a digital twin output based on the information; generating, by the one or more processors, a prioritized list of faults based on the digital twin output; as well as The priority list is provided, by the one or more processors, to an interface on a computing device.

16. The method according to claim 15, characterized in that Further including: comparing, by the one or more processors, the digital twin output with an output of the vehicle system to determine a correlation; as well as The one or more processors generate a priority list of the faults based on correlations of the digital twin outputs with the outputs.

17. The method according to claim 15, characterized in that Further included determining, by the one or more processors, a plurality of faults based on indications that the correlation exceeds a threshold.

18. The method according to claim 15, characterized in that Further comprising communicating, by the one or more processors, with a second digital twin on the remote control system.

19. The method according to claim 15, characterized in that Further comprising determining, by the one or more processors, the digital twin output from the information using an artificial intelligence model of the digital twin.

20. The method according to claim 15, characterized in that The one or more processors are at least part of a controller located within the vehicle.

Images