System and method for identifying field-replaceable units using digital twins

Abstract

A computing system is configured to receive operational data provided by telematics circuitry associated with a remote engine. The operational data includes information provided by at least one sensor and / or at least one actuation command. The computing system is configured to determine, based on the operational data, a plurality of field replaceable units (FRUs) associated with the operational data. The computing system is configured to generate a computer-based simulation corresponding to at least one degradation level of the FRU from the plurality of FRUs, identify a most likely fault, and rank the computer-based simulation among the plurality of FRUs. The computing system is configured to generate an electronic notification containing data associated with the most likely fault and send the electronic notification to a computing device.

Description

[0001] Cross-references to Related Patent Applications

[0002] This application claims priority to and the benefit of U.S. Provisional Application No. 62 / 904,090, filed on September 23, 2019, entitled “System and Method for Identifying Field Replaceable Units Using Digital Twins,” which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates to a remote communication-based control and diagnostic system for a vehicle. More specifically, the present disclosure relates to a system and method for identifying field-replaceable units (FRUs) using a digital twin. The digital twin can be remotely located relative to a paired engine and vehicle. Background Art

[0004] Vehicles can use various sensors to monitor the real-time operating conditions of the vehicle's engine. The information provided by the sensors can be used by a controller (e.g., an engine control unit (ECU)) to perform diagnostics on the engine, vehicle, or various subsystems. Some ECUs have a modular structure.

[0005] Diagnosing an indicated fault in an engine, vehicle, or subsystem often requires manual pinpoint testing to isolate the fault to one or more specific components that require replacement. Pinpoint testing can involve manual methods to assess the health of individual components, resulting in significant vehicle downtime, labor costs, and warranty costs. Summary of the Invention

[0006] An exemplary embodiment relates to a computing system. The computing system includes a processor and a memory having computer-executable instructions stored therein, the computer-executable instructions being configured to cause the computing system to perform various operations when executed by the processor. The operations include receiving operational data provided by a telematics circuit associated with an engine system remotely located relative to the computing system. The operational data includes information provided by at least one sensor. The operations include determining, based on the operational data, a plurality of field replaceable units (FRUs) associated with the operational data. The operations include generating a computer-based simulation corresponding to at least one degradation level of one of the plurality of FRUs. The operations include identifying the most likely fault by sorting the computer-based simulations among the plurality of FRUs. The operations include generating an electronic notification including data associated with the most likely fault. The operations include sending the electronic notification to a computing device. Additional on-board or off-board computing resources may be used to help identify specific components that require replacement or repair. This can significantly reduce operational downtime, labor costs, and warranty costs.

[0007] In some embodiments, the operations include validating each computer-based simulation, including determining an expected error value for each computer-based simulation, and ranking each computer-based simulation according to the expected error value. In some embodiments, the expected error value is determined according to Eq.

[0008]

[0009] wherein i is the number of each consecutive computer-based simulation of the degradation level of each FRU, N is the total number of consecutive computer-based simulations of the degradation level, Diff(i) is the cumulative difference between the output value of each computer-based simulation and its corresponding actual value determined based on the operating data during a predetermined time period, Test(i) is the cumulative actual value for the predetermined time period, and w_i=1 / N.

[0010] In some embodiments, the engine system is a first engine system, the FRU is a first FRU, and the instructions, when executed by the processor, are further configured to cause the computing system to perform additional operations: the operations comprising receiving additional operational data provided by a second telematics circuit associated with a second engine system, the operations comprising identifying a second FRU associated with the second engine system based on the additional operational data, wherein the second FRU and the first FRU correspond to a particular component, and the operations comprising generating a computer-based simulation corresponding to at least one degradation level of the first FRU, wherein the computer-based simulation is based on the additional operational data of the second FRU.

[0011] In some embodiments, the notification includes a standardized code corresponding to the most likely fault. In some embodiments, the standardized code is an OBD-II code. In some embodiments, the standardized code is enhanced to include a coded error descriptor determined based on the computer-based simulation. In some embodiments, the notification includes a service recommendation.

[0012] In some embodiments, the operational data further includes at least one actuation command.

[0013] A second exemplary embodiment relates to a method. The method includes receiving operational data provided by a telematics circuit associated with an engine system remotely located relative to the computing system. The operational data includes information provided by at least one sensor. The method includes determining, based on the operational data, a plurality of field replaceable units (FRUs) associated with the operational data. The method includes generating a computer-based simulation corresponding to at least one degradation level of a FRU in the plurality of FRUs. The method includes identifying a most likely fault by sorting the computer-based simulations among the plurality of FRUs. The method includes generating an electronic notification including data associated with the most likely fault. The method includes sending the electronic notification to a computing device.

[0014] In some embodiments, the method includes validating each computer-based simulation, including determining an expected error value for each computer-based simulation, and ranking each computer-based simulation according to the expected error value. In some embodiments, the expected error value is determined according to Eq.

[0015]

[0016] where i is the number of each consecutive computer-based simulation of the degradation level for each FRU, N is the total number of consecutive computer-based simulations of the degradation level, diff(i) is the cumulative difference between the output value of each computer-based simulation and its corresponding actual value determined based on the operational data within a predetermined time period, Test(i) is the cumulative actual value within the predetermined time period, and w_i=1 / N.

[0017] In some embodiments, the engine system is a first engine system, the FRU is a first FRU, and the method further includes receiving additional operational data provided by a second telematics circuit associated with the second engine system. The method includes identifying a second FRU associated with the second engine system based on the additional operational data, wherein the second FRU and the first FRU correspond to a specific component. The method includes generating a computer-based simulation corresponding to at least one degradation level of the first FRU, wherein the computer-based simulation is based on the additional operational data of the second FRU.

[0018] In some embodiments, the notification includes a standardized code corresponding to the most likely fault. In some embodiments, the standardized code is an OBD-II code. In some embodiments, the standardized code is enhanced to include a coded error descriptor determined based on the computer-based simulation. In some embodiments, the notification includes a service recommendation.

[0019] In some embodiments, the operational data further includes at least one actuation command.

[0020] A third example embodiment relates to a computing system. The computing system includes a data management circuit, a simulation circuit, and a diagnostic circuit coupled to each other. The data management circuit is configured to receive operational data provided from a telematics circuit associated with an engine system remotely located relative to the computing system, the operational data including information provided by at least one sensor. The simulation circuit is coupled to the data management circuit and is configured to: determine, based on the operational data, a plurality of field replaceable units (FRUs) associated with the operational data; and generate a computer-based simulation corresponding to at least one degradation level of one of the plurality of FRUs. The diagnostic circuit is coupled to the simulation circuit and the data management circuit. The diagnostic circuit is configured to: identify a most likely fault by sorting the computer-based simulations among the plurality of FRUs; generate an electronic notification including data associated with the most likely fault; and send the electronic notification to a computing device.

[0021] In some embodiments, the operations include validating each computer-based simulation, including determining an expected error value for each computer-based simulation, and ranking each computer-based simulation according to the expected error value. In some embodiments, the expected error value is determined according to Eq.

[0022]

[0023] Wherein i is the number of each consecutive computer-based simulation of the degradation level of each FRU, N is the total number of consecutive computer-based simulations of the degradation level, diff(i) is the cumulative difference between the output value of each computer-based simulation and its corresponding actual value determined based on the operating data within a predetermined time period, Test(i) is the cumulative actual value within the predetermined time period, and w_i=1 / N.

[0024] In some embodiments, the engine system is a first engine system, the FRU is a first FRU, and the instructions, when executed by the processor, are further configured to cause the computing system to perform additional operations: the operations comprising receiving additional operational data provided by a second telematics circuit associated with a second engine system, the operations comprising identifying a second FRU associated with the second engine system based on the additional operational data, wherein the second FRU and the first FRU correspond to a particular component, and the operations comprising generating a computer-based simulation corresponding to at least one degradation level of the first FRU, wherein the computer-based simulation is based on the additional operational data of the second FRU.

[0025] In some embodiments, the notification includes a standardized code corresponding to the most likely fault. In some embodiments, the standardized code is an OBD-II code. In some embodiments, the standardized code is enhanced to include a coded error descriptor determined based on the computer-based simulation. In some embodiments, the notification includes a service recommendation.

[0026] In some embodiments, the operational data further includes at least one actuation command.

[0027] These and other features, as well as the organization and manner of operation thereof, will become apparent from the following detailed description taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 is a perspective view of a vehicle in communication with a remote system according to some embodiments;

[0029] Figure 2 According to some embodiments Figure 1 The vehicle's controller and Figure 1 A schematic diagram of a controller of a remote system;

[0030] Figure 3 According to some embodiments Figure 1 Schematic diagram of the digital twin of the vehicle's engine, where the digital twin is Figure 1 associated with the controller of the remote system;

[0031] Figure 4 is an identification according to some embodiments Figure 1 One or more FRUs of the vehicle's engine Figure 1 A flowchart of a method of operating a remote system;

[0032] Figure 5 is a graph illustrating output of a computer-based simulation examining received data for potential inconsistencies with predicted results of normal operation, according to some embodiments;

[0033] Figure 6 is a diagram illustrating the Figure 1 a graph of output of a computer-based simulation estimating performance of an example component (e.g., a FRU) among a plurality of components associated with an engine of a vehicle;

[0034] Figure 7 is a diagram showing the Figure 1 a graph of outputs of degradation level ranges for specific components of a plurality of components of an engine of a vehicle; and

[0035] Figure 8 is a diagram showing the Figure 1 A ranked list of predicted component failures of at least some of a plurality of components of an engine of a vehicle. DETAILED DESCRIPTION

[0036] The following is a more detailed description of various concepts related to methods, apparatus, and systems for identifying field-replaceable units (FRUs) of unhealthy engines using their digital twins. The various concepts introduced above and discussed in greater detail below can be implemented in any number 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.

[0037] As used herein, the term "field replaceable unit" ("FRU") generally refers to a diagnosable component (e.g., of a vehicle). According to various embodiments, a FRU may include electronic and / or physical components, such as electronic control units, sensors, and the like. For example, a FRU associated with an engine and / or exhaust aftertreatment system may include actuators, pipes, valves, housings, adapters, sensors (e.g., temperature sensors, pressure sensors, NOx sensors), catalysts, injectors, heaters, combinations thereof (e.g., turbochargers), and the like. A FRU may also include various control units (e.g., a combination of a processor, memory, and / or circuits disposed on a circuit board, such as an engine control unit (ECU)). Example ECUs may include an engine control module (ECM), a powertrain control module (PCM), a brake control module (BCM), a transmission control module (TCM), a battery management system (BMS), and the like.

[0038] Referring generally to the accompanying drawings, various embodiments disclosed herein relate to a computing system configured to receive operational data provided by telematics circuitry associated with a remote engine. The operational data includes information provided by at least one sensor and / or at least one actuation command. The computing system is configured to determine, based on the operational data, a plurality of FRUs associated with the operational data. The computing system is configured to generate a computer-based simulation corresponding to at least one degradation level of a FRU of the plurality of FRUs, identify a most probable fault, and rank the computer-based simulation among the plurality of FRUs. The computing system is configured to generate an electronic notification containing data associated with the most probable fault and send the electronic notification to a computing device.

[0039] Now refer to Figure 1 , shows a perspective view of a vehicle 10 in communication with a remote system 18 according to some embodiments. Vehicle 10 is configured for on-highway travel. As described herein, the concepts described herein are applicable to vehicles, such as vehicle 10. However, those skilled in the art will recognize that the present invention is applicable to a wide variety of implementations. In other embodiments, the systems and methods discussed herein can be used in off-highway vehicles, generator sets, and other machinery (e.g., wheel loaders, bulldozers, generators, etc.).

[0040] Vehicle 10 includes a vehicle controller 14 configured to at least partially control operation of vehicle 10 and communicate with a remote system 18. For example, vehicle controller 14 may control operation of an engine, aftertreatment and emission control systems, or another electronic control system of vehicle 10.

[0041] Vehicle 10 includes an engine 16 configured to power vehicle 10. Engine 16 may be a compression-ignition engine (e.g., a diesel engine), a spark-ignition engine (e.g., a gasoline engine), or another type of prime mover (e.g., an electric or hybrid powertrain).

[0042] An aftertreatment system may be configured to treat exhaust gas from an engine. An aftertreatment system may include various components, such as a reductant dosing system, a catalyst, various flow conduits, a filtration system, and the like. For example, according to some embodiments, an exhaust aftertreatment system for a diesel engine may include a diesel oxidation catalyst (DOC) for reducing or removing carbon monoxide from the exhaust flow, a diesel particulate filter (DPF) configured to reduce or remove particulate matter from the exhaust flow, and a selective catalytic reduction (SCR) component for reducing NOx levels in the exhaust flow.

[0043] The vehicle 10 also includes at least one actuator. The actuator (e.g., motor, pneumatic, servo, linear actuator, piezoelectric actuator, valve, regulator, etc.) is configured to control various aspects of various vehicle systems (e.g., fuel treatment system, air treatment system, transmission, spark timing system, braking system, diesel exhaust fluid dosing for selective catalytic reduction aftertreatment system, etc.). For example, the actuator may include a fuel valve in a fuel injection system, an air valve in an air treatment system, a diesel exhaust fluid (DEF) valve in a DEF dosing system, etc.

[0044] The vehicle 10 also includes a sensor array configured to provide signals to the vehicle controller 14 indicating various operating parameters of the vehicle 10 (e.g., engine exhaust gas temperature, engine exhaust NOx levels, vehicle speed, engine torque, suspension travel distance, etc.). The sensor array may include physical sensors configured to directly measure operating parameters (e.g., O2 sensors, NOx sensors, temperature sensors, pressure sensors, strain gauges, etc.) and / or electronically programmable sensors configured to determine operating parameters based on information collected by other physical sensors (i.e., virtual sensors). For example, a vehicle weight sensor may be configured to determine weight based on information received from a strain gauge of the vehicle 10. Additionally, the sensor array may be coupled to one or more user interfaces or controls (e.g., a steering wheel, an accelerator pedal, etc.) that provide signals indicative of user input.

[0045] Figure 1 The remote system 18 is configured to receive information from the vehicle controller 14 and perform diagnostic, prognostic, and / or, in some embodiments, control operations on the vehicle. The remote system 18 includes one or more memory devices, a processor, and circuitry comprising a digital twin 20. The digital twin 20 is configured to process sensor information and actuator input / output information from the vehicle 10 in the same or similar manner as the vehicle controller 14. In some embodiments, the digital twin 20 allows for remote reproduction of multiple parameters used by the control scheme of the vehicle controller 14. The reproduction of the control parameters allows for a more thorough diagnostic analysis of the operation of the vehicle controller 14 and / or the vehicle 10. The vehicle controller 14 transmits the sensor information (i.e., inputs to the control scheme) and actuator input / outputs to the remote system 18. The digital twin 20 is then configured to perform diagnostics and prognostics remotely.

[0046] The vehicle controller 14 communicates with the remote system 18 via a network 11, which may include one or more wired or wireless connections. The wireless connections may include the Internet, Wi-Fi, cellular, radio, Bluetooth, ZigBee, etc. In some embodiments, the network 11 includes a controller area network (CAN). The remote system 18 and the vehicle may include various devices to facilitate and enable wireless connections, such as routers, cellular modems, Bluetooth transceivers, Bluetooth beacons, RFID transceivers, NFC transmitters, etc. In some embodiments, the network 11 is at least partially a packet-switched network. The information transmitted between the vehicle controller 14 of the vehicle 10 and the remote system 18 can be segmented into data packets and can be transmitted according to a suitable communication protocol (e.g., TCP / IP). In some embodiments, the network 11 is at least partially optimized to support a high throughput of data transmitted between the vehicle controller 14 and the remote system 18.

[0047] Now refer to Figure 2 , showing a schematic diagram according to some embodiments Figure 1 The vehicle controller 14 of the vehicle 10 and Figure 1 Schematic diagram of a digital twin (e.g., controller) 20 of a remote system 18.

[0048] like Figure 2 As shown, vehicle controller 14 includes processing circuitry 140 having a processor 142 and a memory device 144, and a control system 150. Control system 150 includes input / output circuitry 152 configured to receive information from sensor array 22 and to receive control parameters and send instructions to actuators 26. Control system 150 also includes engine control circuitry 154 configured to at least partially control the vehicle. Control system 150 also includes telematics circuitry 156 configured to package sensor information and control parameters for communication with remote system 18 via communication interface 160. Sensor information may include measured or determined data regarding the operation of components or systems in vehicle 10. Control parameters may include parameters for controlling (e.g., activating, operating, etc.) components or systems in vehicle 10 based at least in part on the sensor information.

[0049] Generally, the vehicle controller 14 is configured to at least partially control the operation of one or more components and / or vehicle systems of the vehicle 10. The vehicle controller 14 may also be configured to perform one or more diagnostics and / or prognostics on one or more vehicle systems or components. The input / output circuitry 152 collects information from the sensor array 22, including any user interface or control, and the engine control circuitry 154 determines control parameters that are provided to the actuators 26 via the input / output circuitry 152 to control the components or systems of the vehicle 10.

[0050] In one configuration, the input / output circuit 152, the engine control circuit 154, and the telematics circuit 156 are implemented as a machine or computer-readable medium that can be executed by a processor (such as processor 142). As described herein and for other purposes, the machine-readable medium facilitates the execution of specific operations to achieve the reception and transmission of data. For example, the machine-readable medium can provide instructions (e.g., commands, etc.) to, for example, acquire data. In this regard, the machine-readable medium may include programmable logic that defines the frequency of data acquisition (or data transmission). In an exemplary embodiment, the frequency of data acquisition and / or transmission is between 10ms and 1000ms and includes 10ms and 10ms. The computer-readable medium may include code that can be written in any programming language including but not limited to Java and any conventional procedural programming language (such as "C" programming language or similar programming language). The computer-readable program code can be executed on one processor or multiple processors. In the latter case, the processors can be connected to each other via a suitable type of network (e.g., CAN bus, etc.).

[0051] In another configuration, the input / output circuitry 152, the engine control circuitry 154, and the telematics circuitry 156 are implemented as hardware units, such as electronic control units. Thus, the input / output circuitry 152, the engine control circuitry 154, and the telematics circuitry 156 may be implemented as one or more circuit components including, but not limited to, processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, and the like. In some embodiments, the input / output circuitry 152, the engine control circuitry 154, and the telematics circuitry 156 may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (ICs), discrete circuits, system-on-a-chip (SOC) circuits, microcontrollers, etc.), telecommunications circuits, hybrid circuits, and any other type of “circuitry.” In this regard, the input / output circuitry 152, the engine control circuitry 154, and the telematics circuitry 156 may include any type of component for implementing 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, etc.), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, etc.). The input / output circuitry 152, the engine control circuitry 154, and the telematics circuitry 156 may also include programmable hardware devices, such as field programmable gate arrays, programmable array logic, programmable logic devices, etc. The input / output circuitry 152, the engine control circuitry 154, and the telematics circuitry 156 may include one or more memory devices for storing instructions executable by the processors of the input / output circuitry 152, the engine control circuitry 154, and the telematics circuitry 156. The one or more memory devices and the processor(s) may have the same definitions as provided below with respect to the memory device 144 and the processor 142.

[0052] In the example shown, the vehicle controller 14 includes a processing circuit 140 having a processor 142 and a memory device 144. The processing circuit 140 can be constructed or configured to execute or implement the instructions, commands, and / or control processes described herein with respect to the input / output circuit 152, the engine control circuit 154, and the telematics circuit 156. Thus, the depicted configuration represents the input / output circuit 152, the engine control circuit 154, and the telematics circuit 156 as machine or computer-readable media. However, as described above, since the present disclosure contemplates other embodiments in which at least one of the input / output circuit 152, the engine control circuit 154, and the telematics circuit 156 is configured as a hardware unit, this illustration is not meant to be limiting. All such combinations and variations are intended to fall within the scope of the present disclosure.

[0053] The processor 142 can be implemented as a 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 designed to perform the functions described herein. The processor can be a microprocessor or any conventional processor or state machine. The processor 142 can also be implemented as a combination of computer devices, such as a combination of a digital signal processor (DSP) and a microprocessor, multiple microprocessors, one or more microprocessors in combination with a DSP core, or any other such configuration. In some embodiments, one or more processors can be shared by multiple circuits (for example, the input / output circuit 152, the engine control circuit 154, and the telematics circuit 156 can include or otherwise share the same processor, which, in some example embodiments, can execute instructions stored or accessed via different areas of memory). Alternatively or additionally, one or more processors can be configured to execute or otherwise perform certain operations independently of one or more co-processors. In other example embodiments, two or more processors can be connected via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. All of these variations are intended to fall within the scope of the present disclosure.

[0054] The memory device 144 (e.g., memory, memory 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 perform or facilitate the various processes, layers, and modules described herein. The memory device 144 may be communicatively connected to the processor 142 to provide computer code or instructions to the processor 142 to perform at least some of the processes described herein. Furthermore, the memory device 144 may be or include tangible, non-transitory volatile memory or non-volatile memory. Thus, the memory device 144 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. The input / output circuitry 152 is configured to receive sensor information from the sensor array 22 via the communication interface 160, which may be configured to support internal and / or external vehicle communications. The input / output circuitry 152 may modify or format the sensor information (e.g., via an analog / digital converter) so that the sensor information can be interpreted and used by other circuitry, such as the engine control circuitry 154.

[0055] The engine control circuit 154 is configured to receive sensor information from the input / output circuit 152 and determine control parameters based on the sensor information. As used herein, a "control parameter" refers to a value or information determined by embedded control logic, a model, an algorithm, or other control scheme. A "control parameter" is an intermediate value or information relative to an input and an output. In this regard, a control parameter can include a value or information representing a condition or state of a vehicle system or exhaust aftertreatment system, predicted state information, or any other value or information, or an intermediate value or information used by the engine control circuit 154 to determine what the controller 14 should do or what the output should be. In some embodiments, the engine control circuit 154 generates tens of thousands of control parameters during operation. The "control parameters" are used to generate and determine the outputs transmitted to one or more actuators 26 for controlling the vehicle systems of the vehicle 10.

[0056] In one embodiment illustrating how the input / output circuitry 152 and the engine control circuitry 154 work together, the input / output circuitry 152 provides sensor information (i.e., operating parameters) to the engine control circuitry 154, such as actual fuel flow measured by sensors in the sensor array 22. The operating parameters can be determined by the engine control circuitry 154 according to any suitable method or technique, such as using a continuously modulated control mode in which the measured operating parameters are periodically adjusted to a desired set point (e.g., PID), a lookup table, etc. The operating parameters can be used to determine control parameters to achieve the target operating parameters. For example, in an exemplary embodiment, the input / output circuitry 152 receives a target operating parameter, such as a target fuel flow rate, from the engine control circuitry 154. In response to receiving the desired set point for the target fuel flow rate (the target operating parameter), the input / output circuitry 152 outputs a pulse width modulated signal (the control parameter) to the fuel injector to achieve the target fuel flow rate.

[0057] The telematics circuitry 156 is configured to receive sensor and actuation information from the input / output circuitry 152. In some embodiments, the telematics circuitry 156 receives the sensor information and actuation information directly from the input / output circuitry 152. In some embodiments, the input information and actuation information are stored in the memory device 144, and the telematics circuitry retrieves the sensor information and actuation information from the memory device 144.

[0058] The telematics circuit 156 is configured to format the sensor information and the actuation information into data packets that are sent to the remote system 18 via the network 11. The telematics circuit 156 is configured to connect and communicate with the remote system 18 via the communication interface 160. The communication interface 160 may include a wired or wireless interface (e.g., a jack, an antenna, a transmitter, a receiver, a transceiver, a wired terminal, etc.) for communicating data with various systems, devices, or networks. For example, the communication interface 160 may include a Wi-Fi transceiver for communicating via a wireless communication network. The communication interface 160 may be configured to communicate via a local area network or a wide area network (e.g., the Internet, etc.) and may use various communication protocols (e.g., TCP / IP, local operating network (LON), controller area network (CAN), J1939, local interconnect network (LIN), Bluetooth, ZigBee, radio, cellular, near field communication, etc.).

[0059] In some embodiments, the vehicle controller 14 is a single unit. In other embodiments, the vehicle 10 includes multiple vehicle controllers 14. In some example configurations, the input / output circuitry 152, the engine control circuitry 154, and the telematics circuitry 156 may be dispersed across different physical locations within the vehicle and / or may be associated with different processes, storage media, memory modules, etc. Alternatively, and as shown, the input / output circuitry 152, the engine control circuitry 154, and the telematics circuitry 156 may be implemented in or within a single unit / housing.

[0060] Still refer to Figure 2 , showing an exemplary embodiment according to Figure 1 Schematic diagram of remote system 18 of vehicle 10. Generally, remote system 18 is configured to receive data packets from telematics circuitry 156 of vehicle controller 14, depacketize the data packets, recreate the control logic of engine control circuitry 154 in the circuitry of digital twin 20, generate computer-based simulations of failures of components of vehicle 10 based on the data received from telematics circuitry 156, and utilize the results of the computer-based simulations for diagnostic analysis of physical and / or electronic components of vehicle 10. As shown, remote system 18 includes remote processing circuitry 240 having a remote processor 242 and a remote memory device 244, a remote control system 250 having data management circuitry 252, simulation circuitry 254, and diagnostic circuitry 256.

[0061] The data management circuitry 252 is configured to receive sensor and actuator command information from the telematics circuitry 156 of the vehicle controller 14. In some embodiments, the data management circuitry 252 is configured to transmit the sensor and actuator command information to the telematics circuitry 156 of the vehicle controller 14. The transmitted information may be based on a computer-based simulation performed based on the sensor and actuator command information received from the vehicle controller 14. In some embodiments, the data management circuitry 252 is configured to transmit electronic notifications generated based on the computer-based simulation to the computing system.

[0062] The data management circuit 252 is configured to connect and communicate with the remote system vehicle controller 14 and other computing systems via a communication interface 260. The communication interface 260 may include a wired (e.g., an Ethernet card) or wireless interface (e.g., a jack, antenna, transmitter, receiver, transceiver, wired terminal, etc.) for communicating data with various systems, devices, or networks. For example, the communication interface 260 may include a Wi-Fi transceiver for communicating via a wireless communication network. The communication interface 260 may be configured to communicate via a local area network or a wide area network (e.g., the Internet, etc.) and may use various communication protocols (e.g., TCP / IP, local operating network (LON), controller area network (CAN), J1939, local interconnect network (LIN), Bluetooth, ZigBee, radio, cellular, near field communication, etc.).

[0063] Simulation circuitry 254 is configured to virtually recreate and / or modify the control logic of engine control circuitry 154 of vehicle controller 14 and generate computer-based simulations of failures of components of vehicle 10 based on data received from telematics circuitry 156. To this end, simulation circuitry 254 is configured to use sensor information, actuation information, and control parameters in the computer-based simulations. In one exemplary embodiment, each computer-based simulation in a set of computer-based simulations for each component includes multiple prediction results, where each prediction result is represented as a design of experiments (DoE)-based simulation. In one exemplary embodiment, each DoE scenario corresponds to a degradation level for a particular component. As an example, for some components, such as valves and pipes, component failures may be caused by leakage, partial path blockage, etc., and each DoE in a set of DoEs for that component may correspond to a degradation level expressed as a percentage (e.g., 10% leakage, 10% blockage, etc.). As another example, the degradation level for an entire assembly may include various failure / degradation conditions associated with different components. For example, a fault in the air flow path may be caused by any one or a combination of a leak in the corresponding duct structure, a restriction in the flow path, a fault in a sensor measuring oxygen levels, etc. In such an example, each DoE in a set of DoEs for the component may correspond to a particular component or subassembly, and further correspond to a particular degradation level or failure scenario predicted for the particular component or combination of components. Diagnostic circuitry 256 is configured to perform diagnostic analysis on the physical and / or electronic components of vehicle 10 using the results of the computer-based simulations. In some embodiments, diagnostic circuitry 256 is configured to determine an expected error value for each computer-based simulation (DoE scenario), rank the plurality of DoE scenarios based on the predicted error values, and generate an estimate for the most likely failure scenario, degradation level, etc.

[0064] In some embodiments, the diagnostic circuit 256 is configured to generate an electronic notification based on a ranked computer-based simulation. In some embodiments, the notification includes the results of the computer-based simulation corresponding to one or more possible failure / degradation scenarios. For example, the notification may include the top N (e.g., top 1, top 3, top 5, top 10) possible failure conditions identified by the computer-based simulation. In some embodiments, the notification may include component information (e.g., component description, component identifier, component assembly information), performance parameter information, operating parameter information and / or failure-related information (e.g., failure description, associated list of affected components, actual values of operating parameters, target values of operating parameters, degradation level of partial failure (e.g., % leakage), etc. The notification may be sent as an SMTP message (e.g., email), an SMS message (e.g., text message), an API message (e.g., a REST API to a service management system at a customer support center), or a web application program (e.g., web application program) to a customer support center. In some embodiments, the remote system 18 includes an electronic database that cross-references warranty information, service history, downtime, and component identifiers of components or assemblies in the vehicle 10 for a particular vehicle 10. In some embodiments, the diagnostic circuit 256 can be configured to generate a service recommendation (e.g., entire component replacement, partial FRU-level replacement, repair, etc.) based on the cross-referenced information. In some embodiments, the notification includes an OBD-II code corresponding to the estimated fault, degradation level, etc. Therefore, the telematics circuit 156 can be configured to collect and transmit information sufficient to generate an OBD-II code, which may include a description of the fault (e.g., powertrain, chassis, body, network communication, etc.), system identifiers (e.g., fuel and air metering, ignition system, auxiliary emission control, vehicle speed control and idle control system, computer output circuit, transmission (gearbox), etc.), an indicator indicating whether the OBD-II code is generic or manufacturer-specific, etc.

[0065] Conventional OBD-II codes do not include any indication of a specific fault or the component causing the fault. Thus, conventional OBD-II diagnostics only help the user locate the problem, and this is typically done in a sequential manner, rather than by running multiple DoEs in parallel in a distributed manner as disclosed herein. Thus, in some embodiments, the notification includes enhanced data items, such as enhanced OBD-II codes, which may include coded error descriptors determined based on computer-based simulations. In some embodiments, the remote system 18 may maintain a database that includes a cross-reference directory between a set of identifiers (e.g., codes, which may be numeric or alphanumeric) and error descriptions.

[0066] In some embodiments, the diagnostic circuitry 256 is configured to analyze data from multiple components across multiple vehicles 10 and generate service recommendations. Advantageously, in such embodiments, the digital twin 20 is not simply based on simulations of the diagnostic history of a specific engine 16 for a particular vehicle 10. Furthermore, in some embodiments, the computer-based simulations are not paired with a single engine 16. For example, a set of computer-based simulations generated by the digital twin 20 can utilize historical information from multiple implementations of a specific component of a specific engine 16 across different vehicles. This creates a one-to-many relationship between the digital twin 20 and the specific installation of the component on each of the multiple vehicles 10, allowing, for example, early failures in a small number of vehicles to indicate the need for a global recall. In another example, a one-to-many relationship is created between a specific engine 16 and the digital twin 20. For example, multiple digital twins 20 are created for a specific engine 16 in a vehicle 10. Each of the multiple digital twins 20 can be configured to provide different recommendations based on user-specified priorities, such as total repair cost, required total useful life, depreciation, maximum allowable downtime, and the like, either overall or for a specific continuous time period (such as the first N years of operation of the vehicle).

[0067] In one configuration, the data management circuit 252, the simulation circuit 254 and the diagnostic circuit 256 are implemented as a machine or computer readable medium that can be executed by a processor (such as a remote processor 242). As described herein and in other applications, the machine readable medium facilitates the execution of specific operations to achieve the reception and transmission of data. For example, the machine readable medium can provide instructions (e.g., commands, etc.) to, for example, 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 and any conventional process programming language (such as "C" programming language or similar programming language). The computer readable program code can be executed on one processor or multiple remote processors. In the latter case, the remote processors can be connected to each other through any type of network (e.g., CAN bus, etc.).

[0068] In another configuration, the data management circuit 252, the simulation circuit 254, and the diagnostic circuit 256 are implemented as hardware units, such as electronic control units. Thus, the data management circuit 252, the simulation circuit 254, and the diagnostic circuit 256 can be implemented as one or more circuit components including, but not limited to, processing circuits, network interfaces, peripheral devices, input devices, output devices, sensors, and the like. In some embodiments, the data management circuit 252, the simulation circuit 254, and the diagnostic circuit 256 can take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (ICs), discrete circuits, system-on-chip (SOC) circuits, microcontrollers, etc.), telecommunications circuits, hybrid circuits, and any other type of "circuitry." In this regard, the data management circuit 252, the simulation circuit 254, and the diagnostic circuit 256 can include any type of component for implementing or facilitating the operations described herein. For example, the circuits described herein can include one or more transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR, etc.), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, and the like). The data management circuitry 252, emulation circuitry 254, and diagnostic circuitry 256 may also include programmable hardware devices, such as field programmable gate arrays, programmable array logic, programmable logic devices, etc. The data management circuitry 252, emulation circuitry 254, and diagnostic circuitry 256 may include one or more memory devices for storing instructions executable by processors of the data management circuitry 252, emulation circuitry 254, and diagnostic circuitry 256. The one or more memory devices and the processor(s) may have the same definitions as provided below with respect to the remote memory device 244 and the remote processor 242.

[0069] In some hardware unit configurations, the data management circuitry 252, simulation circuitry 254, and diagnostic circuitry 256 may be geographically dispersed across different locations. Alternatively, and as shown, the data management circuitry 252, simulation circuitry 254, and diagnostic circuitry 256 may be implemented in or within a single unit / housing, which is shown as remote system 18. Although in Figure 2In the embodiments of the present invention, the remote system 18 is shown as a single, independent computing system, but one of ordinary skill in the art will understand that in some embodiments, the remote system 18 may include distributed physical or virtual systems or resources. The remote system 18 may be a cloud computing environment (such that processing for the circuitry of the remote system 18 is distributed across multiple resources) and / or may include virtualized components (such that the virtualized servers, virtualized memory, etc. used by the remote system 18 are part of the resources shared by the remote system 18 with other computing systems). Therefore, in some embodiments, the remote system 18 may include one or more virtual hosts, virtual servers, etc., such that the remote system 18 shares physical storage, hardware, and other resources with other virtual machines. In addition, in some embodiments, the virtual resources included in or accessible to the remote system 18 may include cloud computing resources, such that the remote system 18 can rely on distributed processing across multiple physical processors, distributed memory, etc. As used herein, the term "resource" generally refers to the physical or virtualized (e.g., in a cloud computing environment) computing resources required to perform computer-based operations. Examples of computing resources include computing devices or apparatuses (physical or virtualized servers, hosts, routers, switches, etc.), memory, executable files (applications, services, etc.), data files or data sets (whether stored permanently or cached), and / or combinations thereof (e.g., a set of computer-executable instructions stored in memory and executed by a processor, a computer-readable medium having data stored thereon, etc.). In one example embodiment, a computing infrastructure for practicing the teachings of the present disclosure includes multiple computing resources, each having up to 8GB of RAM, and all together including approximately 300 processors, each having a 1.9GHz processor speed. However, those skilled in the art will understand that in various other embodiments, more or less memory may be required or used to run computer-based simulations, more or fewer processors may be required or used, processor speeds may vary depending on the state of the technology, and / or all or some of the memory, processors, etc. may be implemented as virtualized resources.

[0070] In the example shown, the remote system 18 includes a remote processing circuit 240 having a remote processor 242 and a remote memory device 244. The remote processing circuit 240 can be constructed or configured to execute or implement the instructions, commands and / or control processes described herein with respect to the data management circuit 252, the simulation circuit 254, and the diagnostic circuit 256. The depicted configuration represents the data management circuit 252, the simulation circuit 254, and the diagnostic circuit 256 as machine or computer readable media. However, as described above, this description is not meant to be limiting, as the present disclosure contemplates other embodiments in which all or some of the data management circuit 252, the simulation circuit 254, and the diagnostic circuit 256 are configured as hardware units. All such combinations and variations are intended to fall within the scope of the present disclosure.

[0071] The hardware and data processing components (e.g., remote processor 242) used to implement the various processes, operations, illustrative logic, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein can be implemented or executed using a 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 designed to perform the functions described herein. The processor can be a microprocessor or any conventional processor, or a state machine. The processor can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. In some embodiments, one or more processors can be shared by multiple circuits (e.g., data management circuit 252, simulation circuit 254, and diagnostic circuit 256 can include or otherwise share the same processor, which, in some example embodiments, can execute instructions stored or accessed via different areas of memory). Alternatively or additionally, one or more processors can be configured to perform or otherwise execute certain operations independently of one or more co-processors. In other example embodiments, two or more processors may be connected via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. All such variations are intended to fall within the scope of the present disclosure.

[0072] Remote memory device 244 (e.g., memory, memory 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 herein. Remote memory device 244 may be communicatively connected to remote processor 242 to provide computer code or instructions to remote processor 242 to perform at least some of the processes described herein. In addition, remote memory device 244 may be or include tangible, non-transient volatile memory or non-volatile memory. Thus, remote memory device 244 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.

[0073] Now refer to Figure 3 , showing a schematic diagram according to an exemplary embodiment Figure 1Schematic diagram of various aspects of an example digital twin 20 of the engine 16 of a vehicle 10. The digital twin 20 is configured to include various circuits corresponding to all or some of the onboard systems of the vehicle 10 and / or the engine 16. As shown, an example digital twin 20 includes circuits for simulating various aspects of the intake and exhaust systems of the engine 16 of the vehicle 10. For example, the digital twin 20 may include an intake system circuit 302, a turbocharger circuit 304, an aftercooler 306, an exhaust gas recirculation (EGR) mixer circuit 308, an intake manifold circuit 310, a short circuit blocking circuit 312, an exhaust manifold circuit 314, an EGR loop circuit 316, a monitor circuit 320, and an exhaust system circuit 322. Each of these circuits is configured to receive, process, and run simulations of the components and operating parameters of each corresponding physical or electronic system or component. For example, the exhaust manifold circuit 314 is configured to virtually recreate and estimate the operation of the physical exhaust manifold (and its upstream and downstream systems) of the vehicle 10. The physical exhaust manifold in vehicle 10 may be configured to collect exhaust gas flows from multiple cylinders of engine 16 into a single duct. The physical exhaust manifold may include a housing, gaskets, a heat shield, and / or one or more sensors positioned at various locations near or within the manifold. These sensors may include temperature sensors, pressure sensors, oxygen sensors, and the like. Various fault conditions associated with the physical exhaust manifold may include cracks in the manifold, leaks in gaskets, sensor failures, and the like. Various fault conditions associated with upstream or downstream systems relative to the exhaust manifold may include EGR crossover pipe leaks, EGR valve failures, turbocharger failures, and the like. Exhaust manifold circuitry 314 is configured to diagnose the type or fault (physical or electronic components within the physical manifold) and use information provided by one or more sensors within the exhaust manifold to pinpoint the source of the fault. Exhaust manifold circuitry 314 may also be configured to, at least in part, diagnose the type or fault (physical or electronic components upstream or downstream of the manifold) and use this information, combined with information provided by sensors positioned upstream or downstream of the exhaust manifold, to pinpoint the source of the fault.

[0074] More generally, the circuits included in the digital twin 20 may correspond to various components and systems associated with the engine 16 and / or aftertreatment system of the vehicle 10. These circuits may be implemented as Figure 2 The remote control system 250 is a portion of the simulation circuit 254. In some embodiments, the remote control system 250 is a cloud-based computing environment, and Figure 3 Each or some of the circuits shown in the diagram may have its own dedicated physical or virtualized resources, such as memory, processors, servers, etc. In some embodiments, the digital twin 20 is configured to Figure 3 Computer-based simulations were performed on each circuit shown. Figure 3The other circuits shown are simulated to reduce the overall processing time required by the remote system 18 to generate each computer-based simulation.

[0075] Now refer to Figure 4 , showing a schematic diagram according to some embodiments Figure 1 Remote system 18 identification Figure 1 Flowchart of a method 400 for operating one or more FRUs of an engine 16 of a vehicle 10. Generally, a FRU may include physical and / or electronic components, or a combination thereof. The various physical components may include actuators, conduits, valves, housings, adapters, sensors (e.g., temperature sensors, pressure sensors, NOx sensors), injectors, heaters, combinations thereof (e.g., turbochargers), etc. The various electronic components may include various control units (e.g., a combination of processors, memories, and / or circuits disposed on a circuit board, such as an engine control unit (ECU), an example of which may include an engine control module (ECM), a powertrain control module (PCM), a brake control module (BCM), a transmission control module (TCM), a battery management system (BMS), etc. The various electronic components may further include electronic programmable sensors.

[0076] As shown according to an example embodiment, method 400 includes the following operations (e.g., computer-based operations): receiving operational data, identifying a FRU associated with the operational data, and generating a computer-based simulation of multiple DoE points for each FRU in a group of associated FRUs. For each FRU and DoE point, the simulation results are compared with actual data (e.g., historical data of the corresponding FRU received from the vehicle 10). Based on the comparison, one or more DoE points from the computer-based simulation are selected for each FRU in the group of FRUs. The DoE points are ranked, and one or more most likely faults are determined based on the ranking. In some embodiments, method 400 includes generating a notification including the one or more most likely faults and sending the notification to a user computing device.

[0077] In one example embodiment, the operations of the method 400 include: Figure 1 The remote system 18 is configured to receive data packets from the telematics circuit 156 of the vehicle controller 14. The data packets may include operational information associated with the engine 16 or other components of the vehicle 10, such as information provided by some or all of the sensors in the sensor array 22 and information provided by the remote system 18. Figure 2 The actuator 26 provides actuation commands and other data.

[0078] In some embodiments, operational data is received at predetermined time intervals, such as every 10 milliseconds, 100 milliseconds, 1 second, 30 seconds, 1 minute, 5 minutes, etc. In some embodiments, every sensor and actuator reading for a specific time period (e.g., a specific hour or day) is transmitted by the telematics circuit 156 to the data management circuit 252 of the remote system 18. In some embodiments, the readings are periodically sampled at different predetermined time intervals. In some embodiments, only a subset of the periodically sampled readings are sent to the data management circuit 252 of the remote system 18. For example, the telematics circuit 156 of the vehicle 10 can be configured to sample data from sensors and actuators at a first predetermined time interval (10 ms, 100 ms, 1 second, 30 seconds, 1 minute, 5 minutes, etc.), but send the data to the remote system 18 at a second, less frequent predetermined time interval.

[0079] In some embodiments, the data management circuitry 252 is configured to unpack (e.g., decode, parse, etc.) packets of information to extract individual values. For example, the packets may contain fixed-width numeric or alphanumeric strings where each character position identifies a corresponding data element, the packets may contain delimited data where predetermined special characters serve as delimiters (e.g., pipe-delimited, comma-delimited, etc.), the packets may contain multidimensional data items containing multiple attributes corresponding to various characteristics of the data, and the like.

[0080] The operation of the method 400 includes (at 404) identifying a FRU associated with a particular data received from a range of all available FRUs associated with the vehicle 10 via the digital twin 20. In some embodiments, the remote system 18 includes a catalog of all FRUs associated with the vehicle 10. The vehicle 10 may be configured to send only a subset of data for a particular component or subsystem of the vehicle 10 (e.g., only for a specific component or subsystem of the vehicle 10). Figure 3 20). The data management circuitry 252 of the remote system 20 may be configured to determine which FRUs are associated with the sensors and / or actuators providing the data. For example, the remote system 20 may include a database that stores an association mapping between sensor identifiers and / or actuator identifiers and the FRUs with which they are associated. Thus, in some embodiments, the telematics circuitry 156 is configured to include in a set of data received by the remote system 18 information identifying the sensor and / or actuator providing a particular data point, the location of the sensor and / or actuator, the type of sensor and / or actuator, etc.

[0081] The operation of the method 400 includes generating (at 406) a computer-based simulation for each DoE point in the set of FRUs associated with the received data. More specifically, the simulation circuit 254 is configured to virtually recreate the control logic of the engine control circuit 154 of the vehicle controller 14 and generate a computer-based simulation of the failure of the components of the vehicle 10 based on the sensor and actuator data received from the telematics circuit 156.

[0082] To this end, the simulation circuit 254 is configured to use the sensor information, actuation information, and control parameters in a computer-based simulation and generate one or more output (expected) values for performance parameters of the vehicle 10. A non-exhaustive list of performance parameters includes fresh air flow (in kg / min), torque (in lb / ft), turbine speed (in RPM), intake manifold pressure (IMP) (in kPa), flow rates (e.g., EGR flow, charge flow, in kg / min), air compressor pressure (in kPa), air compressor temperature (in degrees Kelvin), EGR cooler inlet / outlet pressure (in kPa), and throttle inlet / outlet pressure (in kPa). Figure 6 As shown, the values of the performance parameters are estimated over a period of time, so that multiple time point related values are estimated for each performance parameter.

[0083] In one example embodiment, each computer-based simulation in a set of computer-based simulations for each component includes multiple predicted results for each performance parameter, where each predicted result is associated with a design of experiments (DoE)-based simulation of the performance parameter. In one example embodiment, each DoE scenario corresponds to a degradation level for a particular component, where the degradation level is represented by a performance parameter. As an example, for some components, such as valves and pipes, component failure may be caused by leakage, partial path blockage, etc., and each DoE in a set of DoEs for the component may correspond to a degradation level expressed as a percentage (e.g., 10% leakage, 10% blockage, etc.). For example, EGR flow may vary depending on the degradation level (e.g., severity of potential blockage, severity of EGR pipe leakage, etc.). Each or certain degradation levels within the range of expected degradation levels are specific DoE scenarios, and each DoE scenario is implemented as a separate computer-based simulation for the component.

[0084] The operations of the method 400 include performing diagnostic analysis (at 408-414) on the physical and / or electronic components of the vehicle 10 using the computer-based simulation results (obtained at 406) for each FRU. More specifically, the diagnostic circuitry 256 of the digital twin 20 is configured to determine (at 410) the expected error value for each computer-based simulation (DoE scenario), such as Figure 6 Based on the expected error value, the diagnostic circuit 256 is configured to select from a set of computer-based simulations of the most likely DoE scenarios. Referring again to the EGR system diagnostic example from 406 and as shown Figure 7 As further shown in FIG2 , each computer-based simulation (DoE scenario) may correspond to a degradation level (fault magnitude) of the component. For example, based on a set of computer-based simulations generated by simulation circuitry 254, an EGR valve or EGR crossover pipe may be expected to have a leakage between 10% and 90%. The most likely degradation level is determined by diagnostic circuitry 256 based on the magnitude of the expected error value, such that the DoE with the smallest error value is determined to have the greatest prediction accuracy.

[0085] The operations of the method 400 include ranking (at 416) the most predictive computer-based simulations (determined at 410) for each FRU in a set of FRUs corresponding to the set of data received at 402, as described with reference to Figure 8 Based on this ranking, the diagnostic circuit 256 is configured to identify the top N most likely faults of a group of FRUs. For example, Figure 8 As further shown in , an example set of data received from the telematics circuitry of the vehicle 10 may be determined to correspond to the following potential fault conditions associated with the intake and exhaust systems of the engine 16 of the vehicle 10, ranked from most likely to least likely: a restriction in an EGR crossover pipe, an EGR valve malfunction (e.g., an EGR valve stem partially or fully open or closed), an EGR cooler restriction, a variable geometry turbocharger (VGT) malfunction, a leak in an EGR crossover pipe, a restriction in the charge air cooler, a leak in the charge air cooler, and a restriction in the intake path.

[0086] The operations of the method 400 include (at 418) determining the Figure 2 The computer-based simulation of the sequence described generates an electronic notification. In some embodiments, the data management circuit 252 is configured to send the notification to a computing system operated by a user of the vehicle 10, a service provider, an insurance provider, or the like.

[0087] Now refer to Figure 5 , shows a graph of the output of a computer-based simulation for checking received data for potential inconsistencies with predicted results of normal operation according to an exemplary embodiment. In some embodiments, Figure 5 Some or all of the operations shown in are performed only to verify the operation of the simulation circuitry of the digital twin 20 (e.g., in a verification or test mode) and are omitted in the actual operation of the digital twin 20 in a production system.

[0088] As shown, the computer-based simulation 500 includes predicted data for a period of time. The predicted data provides an estimate of a particular performance parameter (as shown, EGR flow), but one of ordinary skill in the art will appreciate that a similar simulation can be performed for another performance parameter or a different time period. The predicted data is compared at each point in time with actual (test) data received from sensors and actuators of the vehicle 10 (e.g., at Figure 4 In some embodiments, the remote system 18 is configured to store actual data for a specific time period (e.g., one hour, one day, one week, etc.), and data outside of these parameters may be truncated. Thus, advantageously, and unlike conventional diagnostic systems, the remote system 18 makes historical sensor and actuation data available for diagnostic and simulation validation purposes.

[0089] The results of simulation 500 can be used to validate the DoE design and computer-based simulation of a particular FRU in the digital twin 20. Additionally, if the DoE design and computer-based simulation of a particular FRU have been validated for a first digital twin 20 of a first vehicle 10, the results of simulation 500 can be used to predict FRU failures in a second digital twin 20 of a different second vehicle 10. This may include different installations of the same component. Thus, the remote system 18 can be activated to analyze data for multiple components across multiple vehicles 10 to generate or predict fault diagnoses and / or generate proactive service recommendations for a specific vehicle.

[0090] Now refer to Figure 6 and Figure 7 , shows the output of verification results based on computer simulation according to example embodiments.

[0091] Figure 6 is a diagram showing the output of a computer-based simulation for Figure 1 The performance and / or degradation level of an example component (eg, FRU) is estimated (eg, calculated, predicted) among a plurality of components related to a vehicle engine. Figure 4 As described above, a set of FRUs corresponding to the actual received sensor and actuator data is selected from the universe of all available (e.g., digitally simulated) FRUs in the vehicle 10. For each performance parameter of each FRU, multiple computer-based simulations are performed, where each simulation is a DoE scenario corresponding to a specific fault type or degradation level.

[0092] For each such computer simulation performed Figure 6The computer-based error quantification process shown. As shown in the graph 602, the cumulative actual (test) values received from the telematics circuit 156 of the vehicle controller 14 of the vehicle 10 are plotted over a specific time period. In some embodiments, these actual values can be stored in the storage medium of the remote system 18, or can be retained in volatile memory for a predetermined period of time required to collect data and generate simulations. The cumulative actual values are plotted against the cumulative estimated values generated by the computer-based simulation. To determine the expected error value, the cumulative value of the difference between the actual data point and the estimated data point at a specific point in time is obtained. The cumulative value is normalized. A weighted average of the normalized values is determined. The expected error is calculated according to formula 606:

[0093]

[0094] where i is the number of each consecutive simulation, N is the total number of simulations, Diff(i) is the cumulative difference between the simulated and actual values, Test(i) is the cumulative actual value, and

[0095] Figure 7 Shown from Figure 1 A graph showing the output of a range of degradation levels of specific components of a vehicle's engine. Again referring to Figure 4 In the EGR system diagnostic example 406, each computer-based simulation (DoE scenario) may correspond to a degradation level (fault magnitude) of the component. For example, based on a set of computer-based simulations generated by the simulation circuitry 254, an EGR valve or EGR crossover pipe may be expected to have a leakage between 10% and 90%. The most likely degradation level is determined by the diagnostic circuitry 256 based on the magnitude of the expected error value, such that the DoE with the smallest error value (here, 0.251 units) is determined to have the greatest prediction accuracy.

[0096] Now refer to Figure 8 , showing the output from Figure 1 The diagnostic circuit 256 is configured to identify the top N most likely failures of a group of FRUs based on the ranking. In one example embodiment, the ranking includes identifying the minimum error (e.g., the error in each DoE of the FRU) for each DoE. Figure 6 As described above, the corresponding FRU is selected, and then a set of results of the FRUs are sorted from smallest (most likely to fail) to largest (least likely to fail) according to the error size of each FRU.

[0097] For purposes of this disclosure, the term "coupled" refers to two components being connected or linked, directly or indirectly, to one another. This connection can be fixed or movable in nature. For example, a drive shaft of an engine being "coupled" to a transmission represents a movable connection. This connection can be achieved with two components or with two components and any additional intermediate components. For example, circuit A being "coupled" to circuit B can 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).

[0098] Although various circuits with specific functions are shown in the figures, it should be understood that the controller described herein may include any number of circuits for performing the functions described herein. Additional circuits with additional functions may also be included. Furthermore, it should be understood that the controller may further control other activities that are beyond the scope of this disclosure.

[0099] As described above and in one configuration, a "circuit" can be implemented in a machine-readable medium for execution by various types of processors. For example, the identified circuitry of executable code can include one or more physical or logical blocks of computer instructions, such as organized as an object, procedure, or function. However, the executable files of the identified circuitry need not be physically located together, but can include dispersed instructions stored in different locations that, when logically connected together, constitute the circuitry and achieve the stated purpose of the circuitry. In practice, a circuitry of computer-readable program code can be a single instruction or many instructions, and can even be distributed across several different code segments, different programs, and across several memory devices. Similarly, operational data can be identified and described herein within the circuitry and can be embodied in any suitable form and organized within any suitable type of data structure. The operational data can be collected as a single data set, or can be distributed across different locations, including different memory devices, and can exist, at least in part, solely as electronic signals on a system or network.

[0100] Although the term "processor" is briefly defined above, it should be understood that the terms "processor" and "processing circuitry" are intended to be broadly interpreted. In this regard and as described above, a "processor" can 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 configured to execute instructions provided by a memory. One or more processors can 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 can be external to the device, for example, one or more processors can be remote processors (e.g., cloud-based processors). Preferably or additionally, one or more processors can be internal and / or local to the device. In this regard, a given circuit or its components can be arranged locally or remotely (e.g., as part of a remote server, such as a cloud-based server). To this end, a "circuit" as described herein may include components distributed in one or more locations.

[0101] It should be noted that although the diagrams herein may illustrate the specific order and composition of method steps, it should be understood that the order of these steps may be different from that depicted. For example, two or more steps may be performed simultaneously or partially simultaneously. Moreover, some method steps performed as separate steps may be combined, steps performed as combined steps may be divided into separate steps, the order of certain processes may be reversed or otherwise changed, and the nature or quantity of separate processes may be changed or varied. According to alternative embodiments, the order or sequence of any element or device may be changed or replaced. Therefore, all such modifications are intended to be included within the scope of the present disclosure as defined in the appended claims. These changes will depend on the selected machine-readable medium and hardware system and the designer's choice. It should be understood that all such changes are within the scope of the present disclosure.

[0102] The foregoing description of the embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or as may be derived from the present disclosure. The embodiments were chosen and described in order to explain the principles of the disclosure and its practical application to enable those skilled in the art to utilize various embodiments and modifications as may be suitable for the particular use contemplated. Other substitutions, modifications, changes, and omissions may be made in the design, operating conditions, and arrangement of the embodiments without departing from the scope of the disclosure as expressed in the appended claims.

Claims

1. A computing system comprising a processor and a memory having computer-executable instructions stored therein, characterized in that The computer-executable instructions, when executed by the processor, are configured to cause the computing system to perform operations including: receiving operational data provided by telematics circuitry associated with an engine system remotely located relative to the computing system, the operational data comprising information from at least one of at least one sensor or at least one actuator within the engine system; identifying a plurality of field replaceable units (FRUs) of the engine system based on the operational data from at least one of at least one sensor or at least one actuator within the engine system, wherein each of the plurality of FRUs includes one or more components within the engine system; performing a computer-based simulation corresponding to a scenario for a diagnostic analysis of each of the plurality of FRUs; determining an expected error value corresponding to at least one degradation level for each of the plurality of FRUs based on a comparison of the computer-based simulation and the operational data; identifying a most likely fault corresponding to one of the plurality of FRUs within the engine system by ranking expected error values corresponding to at least one degradation level for each of the plurality of FRUs; generating an electronic notification including data associated with the most probable fault corresponding to one of the plurality of FRUs within the engine system; as well as The electronic notification is sent to a computing device to indicate a most likely fault within the engine system.

2. The computing system of claim 1, wherein: The instructions, when executed by the processor, are further configured to cause the computing system to perform operations including: Validating each computer-based simulation by determining an expected error value for each computer-based simulation; and Each computer-based simulation is ranked according to the expected error value.

3. The computing system of claim 2, wherein: The instructions, when executed by the processor, are further configured to cause the computing system to perform operations including: determining the expected error value according to an equation wherein i is the number of each consecutive computer-based simulation of the degradation level of each FRU, N is the total number of consecutive computer-based simulations of the degradation level, Diff(i) is the cumulative difference between the output value of each computer-based simulation and its corresponding actual value determined based on the operational data during a predetermined time period, Test(i) is the cumulative actual value for the predetermined time period, and 4. The computing system of claim 1, wherein: The engine system is a first engine system, the FRU is a first FRU, and wherein the instructions, when executed by the processor, are further configured to cause the computing system to perform operations comprising: receiving additional operational data provided by a second telematics circuit associated with a second engine system; identifying a second FRU associated with the second engine system based on the additional operational data, wherein the second FRU and the first FRU correspond to a particular component; and A computer-based simulation corresponding to at least one degradation level of the first FRU is generated, wherein the computer-based simulation is based on the additional operational data of the second FRU.

5. The computing system of claim 1, wherein: The notification includes a standardized code corresponding to the most likely fault.

6. The computing system of claim 5, wherein: The standardized codes are OBD-II codes.

7. The computing system of claim 5, wherein: The standardized code is enhanced to include encoding error descriptors determined based on the computer-based simulation.

8. The computing system of claim 5, wherein: The notification includes a service recommendation.

9. The computing system of claim 1, wherein: The operating data also include at least one actuation command.

10. A method, characterized in that include: receiving, by a computing system, operational data provided by telematics circuitry associated with an engine system remotely located relative to the computing system, the operational data comprising information from at least one of at least one sensor or at least one actuator within the engine system; identifying a plurality of field replaceable units (FRUs) of the engine system based on the operational data from at least one of at least one sensor or at least one actuator within the engine system, wherein each of the plurality of FRUs includes one or more components within the engine system; performing, by the computing system, a computer-based simulation of a scenario corresponding to a diagnostic analysis for each of the plurality of FRUs; determining an expected error value corresponding to at least one degradation level for each of the plurality of FRUs based on a comparison of the computer-based simulation and the operational data; identifying, by the computing system, a most likely fault corresponding to one of the plurality of FRUs within the engine system by ranking expected error values corresponding to at least one degradation level for each of the plurality of FRUs; generating, by the computing system, an electronic notification including data associated with the most probable fault corresponding to one of the plurality of FRUs within the engine system; as well as The electronic notification is sent to a computing device by the computing system to indicate a most likely fault within the engine system.

11. The method according to claim 10, wherein The method further comprises: validating each computer-based simulation by determining an expected error value for each computer-based simulation by the computing system; and Each computer-based simulation is ranked by the computing system according to the expected error value.

12. The method according to claim 10, wherein The method further includes: determining the expected error value according to an equation by a computing system wherein i is the number of each consecutive computer-based simulation of the degradation level of each FRU, N is the total number of consecutive computer-based simulations of the degradation level, Diff(i) is the cumulative difference between the output value of each computer-based simulation and its corresponding actual value determined based on the operational data during a predetermined time period, Test(i) is the cumulative actual value for the predetermined time period, and 13. The method according to claim 10, wherein The engine system is a first engine system, the FRU is a first FRU, and wherein the method further comprises: receiving, by the computing system, additional operational data provided by a second telematics circuit associated with a second engine system; identifying, by the computing system, a second FRU associated with the second engine system based on the additional operational data, wherein the second FRU and the first FRU correspond to a specific component; and A computer-based simulation corresponding to at least one degradation level of the first FRU is generated, wherein the computer-based simulation is based on the additional operational data of the second FRU.

14. The method according to claim 10, wherein The notification includes a standardized code corresponding to the most likely fault, wherein the standardized code is enhanced to include an encoded error descriptor determined based on the computer-based simulation.

15. The method according to claim 10, wherein The operating data also include at least one actuation command.

16. A computing system, characterized in that include: The data management circuit is configured to: receiving operational data provided from telematics circuitry associated with an engine system remotely located relative to the computing system, the operational data comprising information from at least one of at least one sensor or at least one actuator within the engine system; an emulation circuit coupled to the data management circuit, the emulation being configured to: identifying a plurality of field replaceable units (FRUs) of the engine system based on the operational data from at least one of at least one sensor or at least one actuator within the engine system, wherein each of the plurality of FRUs includes one or more components within the engine system; as well as performing a computer-based simulation corresponding to a scenario for a diagnostic analysis of each of the plurality of FRUs; as well as a diagnostic circuit coupled to the emulation circuit and the data management circuit, the diagnostic circuit configured to: determining an expected error value corresponding to at least one degradation level for each of the plurality of FRUs based on a comparison of the computer-based simulation and the operational data; identifying a most likely fault corresponding to one of the plurality of FRUs within the engine system by ranking expected error values corresponding to at least one degradation level for each of the plurality of FRUs; generating an electronic notification including data associated with the most probable fault corresponding to one of the plurality of FRUs within the engine system; as well as The electronic notification is sent to a computing device to indicate a most likely fault within the engine system.

17. The computing system of claim 16, wherein: The diagnostic circuit is further configured to: Validating each computer-based simulation by determining an expected error value for each computer-based simulation; and Each computer-based simulation is ranked according to the expected error value.

18. The computing system of claim 16, wherein: The diagnostic circuit is further configured to determine the expected error value according to the equation wherein i is the number of each consecutive computer-based simulation of the degradation level of each FRU, N is the total number of consecutive computer-based simulations of the degradation level, Diff(i) is the cumulative difference between the output value of each computer-based simulation and its corresponding actual value determined based on the operational data during a predetermined time period, Test(i) is the cumulative actual value for the predetermined time period, and 19. The computing system of claim 16, wherein: The engine system is a first engine system, the FRU is a first FRU, wherein the data management circuit is further configured to receive additional operating data provided by a second telematics circuit associated with a second engine system, and wherein the emulation circuit is further configured to: identifying a second FRU associated with the second engine system based on the additional operational data, wherein the second FRU and the first FRU correspond to a particular component; and A computer-based simulation corresponding to at least one degradation level of the first FRU is generated, wherein the computer-based simulation is based on the additional operational data of the second FRU.

20. The computing system of claim 16, wherein: The notification includes a standardized code enhanced to include an encoded error descriptor determined based on the computer-based simulation.

Images