System and method for identifying field replaceable units using digital twin

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 the at least one sensor and / or the at least one actuation command. The computing system is configured to determine a plurality of field replaceable units (FRUs) associated with the operational data based on the operational data. The computing system is configured to generate a computer-based simulation corresponding to at least one degradation level of an 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 the computing device.

Description

[0001] This application is a divisional application of the invention application filed on September 22, 2020, with application number 202080066959.9 and titled "System and Method for Identifying Field Replaceable Units Using Digital Twins".

[0002] Cross-referencing of related patent applications

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

[0004] This disclosure relates to a remote communication-based control and diagnostic system for vehicles. More specifically, this disclosure relates to systems and methods for identifying field-replaceable units using digital twins. The digital twins can be remotely configured relative to paired engines and vehicles. Background Technology

[0005] Vehicles can use various sensors to monitor the real-time operating status of their engines. The information provided by these sensors can then be used by controllers (e.g., engine control units (ECUs)) to perform diagnostics on the engine, vehicle, or various subsystems. Some ECUs have a modular design.

[0006] When diagnosing indicated faults in an engine, vehicle, or subsystem, manual precision localization tests are typically required to isolate the fault to one or more specific components that need to be replaced. Precision localization tests may involve using manual methods to assess the health of individual components, resulting in significant vehicle downtime, labor costs, and warranty expenses. Summary of the Invention

[0007] 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, when executed by the processor, to cause the computing system to perform various operations. The operations include receiving operational data provided by telematics circuitry associated with an engine system remotely positioned 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 probable fault by ranking the computer-based simulations among the plurality of FRUs. The operations include generating an electronic notification including data associated with the most probable fault. The operations include sending the electronic notification to a computing device. Additional onboard or offboard computing resources can be used to help identify specific components requiring replacement or repair. This can significantly reduce operational downtime, labor costs, and warranty costs.

[0008] In some embodiments, the operation includes verifying 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 based on an equation.

[0009]

[0010] Where i is the number of each consecutive computer-based simulation for each degradation level of each FRU, N is the total number of consecutive computer-based simulations for 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 for the predetermined time period, and w_i = 1 / N.

[0011] 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 include receiving additional operation data provided by a second telematics circuit associated with the second engine system. The operations include identifying a second FRU associated with the second engine system based on the additional operation data, wherein the second FRU and the first FRU correspond to a specific component. The operations include 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 operation data of the second FRU.

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

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

[0014] A second exemplary embodiment relates to a method. The method includes receiving operational data provided by telematics circuitry associated with an engine system remotely positioned relative to the computing system. The operational data includes information provided by at least one sensor. The method includes determining 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 one of the plurality of FRUs. The method includes identifying the most probable fault by ranking the computer-based simulations of the plurality of FRUs. The method includes generating an electronic notification including data associated with the most probable fault. The method includes sending the electronic notification to a computing device.

[0015] 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 based on an equation.

[0016]

[0017] Where i is the number of each consecutive computer-based simulation for each degradation level of each FRU, N is the total number of consecutive computer-based simulations for 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.

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

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

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

[0021] A third example embodiment relates to a computing system. The computing system includes mutually coupled data management circuitry, simulation circuitry, and diagnostic circuitry. The data management circuitry is configured to receive operational data from a telematics circuitry associated with an engine system remotely positioned relative to the computing system, the operational data including information provided by at least one sensor. The simulation circuitry is coupled to the data management circuitry and configured to: determine 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 circuitry is coupled to the simulation circuitry and the data management circuitry. The diagnostic circuitry is configured to: identify the most probable fault by ranking the computer-based simulations of the plurality of FRUs; generate an electronic notification including data associated with the most probable fault; and send the electronic notification to a computing device.

[0022] In some embodiments, the operation includes verifying 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 based on an equation.

[0023]

[0024] Where i is the number of each consecutive computer-based simulation for each degradation level of each FRU, N is the total number of consecutive computer-based simulations for 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.

[0025] 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 include receiving additional operation data provided by a second telematics circuit associated with the second engine system. The operations include identifying a second FRU associated with the second engine system based on the additional operation data, wherein the second FRU and the first FRU correspond to a specific component. The operations include 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 operation data of the second FRU.

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

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

[0028] These and other features, as well as the organization and manner of their operation, will become apparent from the following detailed description taken in conjunction with the accompanying drawings. Attached Figure Description

[0029] Figure 1 This is a perspective view of a vehicle communicating with a remote system according to some embodiments;

[0030] Figure 2 According to some embodiments Figure 1 vehicle controller and Figure 1 A schematic diagram of the controller of the remote system;

[0031] Figure 3 According to some embodiments Figure 1 A schematic diagram of the digital twin of a vehicle's engine, where the digital twin is... Figure 1 Associated with the controller of the remote system;

[0032] Figure 4 Identification based on some embodiments Figure 1 One or more FRUs of the vehicle's engine Figure 1 A flowchart of the operation method of the remote system;

[0033] Figure 5 It is a graph showing the output of a computer-based simulation of the potential inconsistencies between the data received during the inspection according to some embodiments and the predicted results of normal operation;

[0034] Figure 6 This illustrates the relationship between and according to some embodiments. Figure 1 A graph of the output of a computer-based simulation that estimates the performance of an example component (e.g., FRU) among multiple components associated with the engine of a vehicle;

[0035] Figure 7 This is an illustration from some embodiments. Figure 1 A graph showing the output degradation level range of specific components of multiple parts of the vehicle's engine; and

[0036] Figure 8 This is an illustration from some embodiments. Figure 1 A sorted list of predicted component failures for at least some of the multiple components of a vehicle's engine. Detailed Implementation

[0037] The following is a more detailed description of various concepts related to methods, apparatuses, and systems for identifying field-replaceable units of unhealthy engines using their digital twins. The various concepts introduced above and discussed in more detail below can be implemented in any number of ways, as the described concepts are not limited to any particular implementation. Examples of specific implementations and applications are provided primarily for illustrative purposes.

[0038] As used herein, the term "Field Replaceable Unit" ("FRU") generally refers to a diagnostic component (e.g., in a vehicle). According to various embodiments, an FRU may include electronic and / or physical components such as electronic control units, sensors, etc. For example, an 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), etc. An FRU may also include various control units (e.g., processors, memories, and / or combinations of circuitry 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), etc.

[0039] Referring generally to the accompanying drawings, the 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 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 one of the plurality of FRUs, identify the most probable faults, and rank the computer-based simulations among the plurality of FRUs. The computing system is configured to generate an electronic notification containing data associated with the most probable faults and send the electronic notification to a computing device.

[0040] Now for reference Figure 1 This diagram illustrates a perspective view of a vehicle 10 communicating with a remote system 18 according to some embodiments. The vehicle 10 is configured for travel on a highway. As described herein, the concepts described apply to vehicles, such as vehicle 10. However, those skilled in the art will recognize that the 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.).

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

[0042] 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 system).

[0043] An aftertreatment system can be configured to treat exhaust gas from an engine. An aftertreatment system may include various components, such as a reductant metering system, a catalyst, various flow ducts, a filtration system, etc. 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 stream, a diesel particulate filter (DPF) configured to reduce or remove particulate matter from the exhaust stream, and a selective catalytic reduction (SCR) assembly for reducing NOx levels in the exhaust stream.

[0044] Vehicle 10 also includes at least one actuator. The actuator (e.g., a 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 (DEF) metering feeder for selective catalytic reduction aftertreatment systems, 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 metering feeder, etc.

[0045] Vehicle 10 also includes a sensor array configured to provide signals to vehicle controller 14 indicative of various operating parameters of vehicle 10, such as engine exhaust temperature, engine 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 (i.e., virtual sensors) configured to determine operating parameters based on information collected by other physical sensors. For example, a vehicle weight sensor may be configured to determine weight based on information received from a strain gauge in vehicle 10. Additionally, the sensor array may be coupled to one or more user interfaces or controllers (e.g., steering wheel, accelerator pedal, etc.) that provide signals indicative of user input.

[0046] Figure 1 The remote system 18 is configured to receive information from the vehicle controller 14 and perform diagnostic, predictive, and / or control operations on the vehicle in some embodiments. The remote system 18 includes one or more memory devices, a processor, and circuitry including 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 the remote reproduction of multiple parameters used by the control scheme of the vehicle controller 14. 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 sensor information (i.e., inputs to the control scheme) and actuator inputs / outputs to the remote system 18. The digital twin 20 is then configured to remotely perform diagnostics and predictions.

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

[0048] Now for reference Figure 2 This illustrates some embodiments. Figure 1 The vehicle controller 14 of vehicle 10 and Figure 1 A schematic diagram of a digital twin (e.g., controller) 20 of a remote system 18.

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

[0050] Typically, 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 predictions on one or more vehicle systems or components. Input / output circuitry 152 collects information from sensor array 22, including any user interface or control, and engine control circuitry 154 determines control parameters provided via input / output circuitry 152 to actuator 26 for controlling components or systems of the vehicle 10.

[0051] In one configuration, input / output circuitry 152, engine control circuitry 154, and telematics circuitry 156 are implemented as machine- or computer-readable media executable by a processor (such as processor 142). As described herein and in other uses, machine-readable media facilitate the execution of specific operations to achieve the reception and transmission of data. For example, machine-readable media can provide instructions (e.g., commands, etc.) to, for example, acquire data. In this regard, machine-readable media may include programmable logic defining the frequency of data acquisition (or data transmission). In one exemplary embodiment, the frequency of data acquisition and / or transmission is between 10 ms and 1000 ms, and includes 10 ms and 10 ms. Computer-readable media 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 the "C" programming language or similar programming languages). The computer-readable program code can be executed on one or more processors. In the latter case, the processors can be interconnected via a suitable type of network (e.g., CAN bus, etc.).

[0052] In another configuration, the input / output circuit 152, engine control circuit 154, and telematics processing circuit 156 are implemented as hardware units, such as electronic control units. Therefore, the input / output circuit 152, engine control circuit 154, and telematics processing circuit 156 can be implemented as one or more circuit components, including but not limited to processing circuits, network interfaces, peripherals, input devices, output devices, sensors, etc. In some embodiments, the input / output circuit 152, engine control circuit 154, and telematics processing circuit 156 can 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.), telecommunication circuits, hybrid circuits, and any other type of "circuit". In this respect, the input / output circuit 152, engine control circuit 154, and telematics processing circuit 156 can include any type of components for implementing or facilitating the implementation of 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. Input / output circuitry 152, engine control circuitry 154, and telematics processing circuitry 156 may also include programmable hardware devices, such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc. Input / output circuitry 152, engine control circuitry 154, and telematics processing circuitry 156 may include one or more memory devices for storing instructions executable by the processors of input / output circuitry 152, engine control circuitry 154, and telematics processing circuitry 156. The one or more memory devices and processors(s) may have the same definitions as provided below regarding memory device 144 and processor 142.

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

[0054] Processor 142 may 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 designed to perform the functions described herein. The processor may be a microprocessor or any conventional processor or state machine. Processor 142 may 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 incorporating a DSP core, or any other such configuration. In some embodiments, one or more processors may be shared by multiple circuits (e.g., input / output circuitry 152, engine control circuitry 154, and telematics circuitry 156 may include or otherwise share the same processor, which in some example embodiments may execute instructions stored or accessed via different regions of memory). Optionally or additionally, one or more processors may be configured to perform or otherwise perform certain operations independently of one or more coprocessors. In other example embodiments, two or more processors may be bus-connected to enable independent, parallel, pipelined, or multithreaded instruction execution. All these variations are intended to fall within the scope of this disclosure.

[0055] Memory device 144 (e.g., memory, memory cell, 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. Memory device 144 may be communicatively connected to processor 142 to provide processor 142 with computer code or instructions to perform at least some of the processes described herein. Furthermore, memory device 144 may be or include tangible, non-transient volatile memory or non-volatile memory. Therefore, memory device 144 may include database components, object code components, scripting components, or any other type of information structure for supporting the various activities and information structures described herein.

[0056] Input / output circuitry 152 is configured to receive sensor information from sensor array 22 via communication interface 160, and may be configured to support internal and / or external vehicle communication. Input / output circuitry 152 may (e.g., via analog-to-digital converter) modify or format sensor information such that it can be interpreted and used by other circuitry such as engine control circuitry 154.

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

[0058] 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 the actual fuel flow rate 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 where the measured operating parameters are periodically adjusted to a desired setpoint (e.g., PID), 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 setpoint (target operating parameter) for the target fuel flow rate, the input / output circuitry 152 outputs a pulse-width modulated signal (control parameter) to the fuel injector to achieve the target fuel flow rate.

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

[0060] Telematics processing circuitry 156 is configured to format sensor information and actuation information into data packets, which are transmitted to remote system 18 via network 11. Telematics processing circuitry 156 is configured to connect to and communicate with remote system 18 via communication interface 160. Communication interface 160 may include wired or wireless interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wired terminals, etc.) for data communication with various systems, devices, or networks. For example, communication interface 160 may include a Wi-Fi transceiver for communication via a wireless communication network. Communication interface 160 may be configured to communicate via a local area network or wide area network (e.g., the Internet, etc.) and may use various communication protocols (e.g., TCP / IP, Local Operation Network (LON), Controller Area Network (CAN), J1939, Local Interconnect Network (LIN), Bluetooth, ZigBee, radio, cellular, near field communication, etc.).

[0061] 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 distributed 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 a single unit / housing or within a single unit / housing.

[0062] Still referencing Figure 2 This illustrates an exemplary embodiment. Figure 1 A schematic diagram of a remote system 18 for vehicle 10 is shown. Typically, the remote system 18 is configured to receive data packets from the telematics processing circuitry 156 of the vehicle controller 14, unpack the data packets, recreate the control logic of the engine control circuitry 154 in the circuitry of the digital twin 20, generate a computer-based simulation of faults in the components of vehicle 10 based on the data received from the telematics processing circuitry 156, and utilize the results of the computer-based simulation for diagnostic analysis of the physical and / or electronic components of vehicle 10. As shown, the remote system 18 includes a remote processing circuitry 240 with a remote processor 242 and a remote memory device 244, a remote control system 250 with a data management circuitry 252, a simulation circuitry 254, and a diagnostic circuitry 256.

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

[0064] Data management circuitry 252 is configured to connect and communicate with remote system vehicle controller 14 and other computing systems via communication interface 260. Communication interface 260 may include wired (e.g., Ethernet card) or wireless interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wired terminals, etc.) for data communication with various systems, devices, or networks. For example, communication interface 260 may include a Wi-Fi transceiver for communication via a wireless communication network. Communication interface 260 may be configured to communicate via a local area network (LAN) or wide area network (WAN) (e.g., the Internet, etc.) and may use various communication protocols (e.g., TCP / IP, Local Operation Network (LON), Controller Area Network (CAN), J1939, Local Interconnect Network (LIN), Bluetooth, ZigBee, radio, cellular, near field communication, etc.).

[0065] Simulation circuit 254 is configured to virtually recreate and / or modify the control logic of engine control circuit 154 of vehicle controller 14, and generate computer-based simulations of faults in components of vehicle 10 based on data received from telematics circuit 156. To this end, simulation circuit 254 is configured to use sensor information, actuation information, and control parameters in the computer-based simulation. In one example embodiment, each computer-based simulation in a set of simulations for each component includes multiple predictions, where each prediction is represented as a simulation based on a design of experiment (DoE). In one example embodiment, each DoE scenario corresponds to a degradation level for a specific component. As an example, for some components, such as valves and pipes, component failures may be caused by leaks, partial path blockages, 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% leak, 10% blockage, etc.). As another example, the degradation level of the entire component may include various failure / degradation scenarios associated with different components. For example, a failure in the airflow path could be caused by any one or a combination of factors, such as a leak in the corresponding piping structure, a limitation in the flow path, or a malfunction in the sensor measuring the oxygen level. In such an example, each DoE in a set of DoEs for the component could correspond to a specific component or sub-component, and further correspond to a specific level of degradation or failure scenario predicted for that specific component or combination of components.

[0066] The diagnostic circuit 256 is configured to perform diagnostic analysis on the physical and / or electronic components of the vehicle 10 using the results of computer-based simulations. In some embodiments, the diagnostic circuit 256 is configured to determine the expected error value for each computer-based simulation (DoE scenario), rank multiple DoE scenarios based on the predicted error values, and generate estimates for the most probable failure scenario, degradation level, etc.

[0067] In some embodiments, the diagnostic circuit 256 is configured to generate electronic notifications based on a sorted computer-based simulation. In some embodiments, the notification includes the results of a 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, a list of associated components, actual values ​​of operating parameters, target values ​​of operating parameters, degradation level of partial failures (e.g., % leakage), etc. The notification may be sent as an SMTP message (e.g., email), an SMS message (e.g., text message), or an API message (e.g., a REST API message sent to a service management system at a customer support center). Transmissions such as API messages are allowed. In some embodiments, the remote system 18 includes an electronic database that cross-references warranty information, service history, downtime, and component identifiers of parts or components in the vehicle 10 for a specific vehicle 10. In some embodiments, the diagnostic circuit 256 may be configured to generate service recommendations (e.g., whole 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 may be configured to collect and transmit information sufficient to generate an OBD-II code, which may include fault descriptions (e.g., powertrain, chassis, body, network communications, etc.), system identifiers (e.g., fuel and air metering, ignition system, auxiliary emission control, vehicle speed control and idle speed control systems, computer output circuitry, transmission (gearbox), etc.), indicators indicating whether the OBD-II code is generic or manufacturer-specific, etc.

[0068] Traditional OBD-II codes do not include indications of any specific fault or the component causing the fault. Therefore, conventional OBD-II diagnostics only help users locate the problem, and this is typically done sequentially, rather than by running multiple DoEs in parallel in a distributed manner as disclosed herein. Therefore, 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 comprising a cross-reference directory of identifiers (e.g., codes, which may be numeric or alphanumeric) and error descriptions.

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

[0070] In one configuration, data management circuitry 252, emulation circuitry 254, and diagnostic circuitry 256 are implemented as a machine- or computer-readable medium executable by a processor (such as remote processor 242). As described herein and in other uses, 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 respect, the machine-readable medium may include programmable logic defining 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 procedural programming language (such as the "C" programming language or similar programming languages). 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 via any type of network (e.g., CAN bus, etc.).

[0071] In another configuration, the data management circuit 252, emulation circuit 254, and diagnostic circuit 256 are implemented as hardware units, such as electronic control units. Therefore, the data management circuit 252, emulation circuit 254, and diagnostic circuit 256 can be implemented as one or more circuit components, including but not limited to processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, etc. In some embodiments, the data management circuit 252, emulation circuit 254, and diagnostic circuit 256 can 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 "circuit". In this respect, the data management circuit 252, emulation circuit 254, and diagnostic circuit 256 can include any type of components for implementing or facilitating the implementation of 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, etc. 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. Data management circuitry 252, emulation circuitry 254, and diagnostic circuitry 256 may include one or more memory devices for storing instructions executable by the processor of data management circuitry 252, emulation circuitry 254, and diagnostic circuitry 256. The one or more memory devices and processor(s) may have the same definitions as provided below with respect to remote memory device 244 and remote processor 242.

[0072] In some hardware unit configurations, the data management circuitry 252, simulation circuitry 254, and diagnostic circuitry 256 can be geographically distributed across different locations. Alternatively, and as shown in the figure, the data management circuitry 252, simulation circuitry 254, and diagnostic circuitry 256 can be implemented in a single unit / enclosure or within a single unit / enclosure, shown as remote system 18. Although in Figure 2In the embodiments shown, the remote system 18 is depicted as a single, independent computing system; however, those skilled 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 of circuitry for the remote system 18 is distributed across multiple resources) and / or may include virtualization components (such that virtualized servers, virtualized storage, etc., used by the remote system 18 are part of 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. Furthermore, in some embodiments, the virtual resources included in or accessible in 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 storage, etc. As used herein, the term "resource" generally refers to 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 datasets (whether persistent storage or cache), and / or combinations thereof (e.g., a set of computer-executable instructions stored in memory and executed by a processor, a computer-readable medium on which data is stored, etc.). In one example embodiment, the computing infrastructure for practicing the teachings of this disclosure includes multiple computing resources, each having up to 8GB of RAM, and together comprising approximately 300 processors, each with a processor speed of 1.9 GHz. 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.

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

[0074] 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 may be implemented or performed by 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 designed to perform the functions described herein. The processor may be a microprocessor or 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, multiple microprocessors, one or more microprocessors incorporating a DSP core, or any other such configuration. In some embodiments, one or more processors may be shared by multiple circuits (e.g., data management circuitry 252, emulation circuitry 254, and diagnostic circuitry 256 may include or otherwise share the same processor, which in some example embodiments may execute stored instructions or instructions accessed via different regions of memory). Optionally or additionally, one or more processors may be configured to perform or otherwise perform certain operations independently of one or more coprocessors. In other example embodiments, two or more processors may be connected via a bus to enable independent, parallel, pipelined, or multithreaded instruction execution. All of these variations are intended to fall within the scope of this disclosure.

[0075] Remote memory device 244 (e.g., memory, memory cell, 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. 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. Furthermore, remote memory device 244 may be or include tangible, non-transient volatile memory or non-volatile memory. Therefore, remote memory device 244 may include database components, object code components, scripting components, or any other type of information structure for supporting the various activities and information structures described herein.

[0076] Now for reference Figure 3 This illustrates an exemplary embodiment. Figure 1A schematic diagram of various aspects of an example digital twin 20 of the vehicle's engine 16. 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 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 operate 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 of the vehicle 10 (and its upstream and downstream systems). The physical exhaust manifold in vehicle 10 can be configured to collect exhaust streams from multiple cylinders of engine 16 into a single conduit. The physical exhaust manifold may include a housing, gaskets, a heat shield, and / or one or more sensors located at various locations near or within the manifold. These sensors may include temperature sensors, pressure sensors, oxygen sensors, etc. Various fault conditions associated with the physical exhaust manifold may include cracks in the manifold, leaks in the gaskets, sensor malfunctions, etc. Various fault conditions associated with upstream or downstream systems relative to the exhaust manifold may include EGR crosspipe leaks, EGR valve malfunctions, turbocharger malfunctions, etc. 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 partially diagnose the type or fault (physical or electronic components upstream or downstream of the manifold) and use the aforementioned information in conjunction with information provided by sensors located upstream or downstream of the exhaust manifold to pinpoint the source of the fault.

[0077] More generally, the circuitry 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 This is part of the simulation circuit 254 of the remote control system 250. In some embodiments, the remote control system 250 is a cloud-based computing environment, and Figure 3 Each or some of the circuits shown may have their own dedicated physical or virtualized resources, such as memory, processors, servers, etc. In some embodiments, the digital twin 20 is configured to simultaneously... Figure 3 Each circuit shown is simulated using a computer and... Figure 3The other circuits shown are simulated to reduce the total processing time required for the remote system 18 to generate each computer-based simulation.

[0078] Now for reference Figure 4 This illustrates some embodiments. Figure 1 Remote system 18 identification Figure 1 A flowchart of an operation method 400 for one or more FRUs of engine 16 of vehicle 10. Typically, an FRU may include physical and / or electronic components, or combinations thereof. Various physical components may include actuators, pipes, valves, housings, adapters, sensors (e.g., temperature sensors, pressure sensors, NOx sensors), injectors, heaters, and combinations thereof (e.g., turbochargers), etc. Various electronic components may include various control units (e.g., processors, memories, and / or combinations of circuitry mounted on a circuit board, such as an engine control unit (ECU), one example of which an ECU 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. Various electronic components may further include electronically programmable sensors.

[0079] As illustrated in one example embodiment, method 400 includes the following operations (e.g., computer-based operations): receiving operational data, identifying FRUs associated with the operational data, and generating a computer-based simulation of multiple DoE points for each FRU in a set 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 vehicle 10). Based on the comparison, one or more DoE points from the computer-based simulation are selected for each FRU in the set of FRUs. These DoE points are sorted, and one or more most probable faults are determined based on the sorting. In some embodiments, method 400 includes generating a notification including one or more most probable faults and sending the notification to a user computing device.

[0080] In one example embodiment, the operation of method 400 includes accessing remote system 18 from... Figure 1 The vehicle 10 receives operational data (at 402). The remote system 18 is configured to receive data packets from the telematics processing circuitry 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 by [other sensors]. Figure 2 The actuator 26 provides actuation commands and other data.

[0081] 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, each sensor and actuator reading for a specific time period (e.g., a specific hour or day) is transmitted by telematics circuitry 156 to data management circuitry 252 of remote system 18. In some embodiments, readings are sampled periodically at different predetermined time intervals. In some embodiments, only a subset of periodically sampled readings is sent to data management circuitry 252 of remote system 18. For example, telematics circuitry 156 of vehicle 10 may 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 remote system 18 at a less frequent second predetermined time interval. In some embodiments, data management circuitry 252 is configured to unpack (e.g., decode, parse, etc.) packets to extract individual values. For example, these packages may contain fixed-width numeric or alphanumeric strings, where each character position identifier corresponds to a specific data element; these packages may contain delimited data, where predetermined special characters are used as delimiters (e.g., pipe-delimited, comma-delimited, etc.); these packages may contain multidimensional data items, which contain multiple attributes corresponding to various characteristics of the data.

[0082] The operation of method 400 includes (at 404) identifying the FRU associated with specific data received via digital twin 20 from a range of all available FRUs associated with vehicle 10. In some embodiments, remote system 18 includes a catalog of all FRUs associated with vehicle 10. Vehicle 10 may be configured to send only a subset of data from specific components or subsystems of vehicle 10 (e.g., only for use with respect to specific components or subsystems of vehicle 10). Figure 3 (The digital twin 20 in the diagram shows the intake and exhaust systems). The data management circuitry 252 of the remote system 20 can be configured to determine which FRUs are associated with the sensors and / or actuators providing data. For example, the remote system 20 may include a database that stores an association mapping between sensor identifiers and / or actuator identifiers and their associated FRUs. Thus, in some embodiments, the telematics circuitry 156 is configured to include, within a set of data received by the remote system 18, information about the sensors and / or actuators that provide specific data points, the location of the sensors and / or actuators, the type of the sensors and / or actuators, etc.

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

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

[0085] In one example embodiment, each computer-based simulation in a set of computer-based simulations for each component includes multiple predictions for each performance parameter, wherein each prediction is associated with a design-of-experiment (DoE)-based simulation of said 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 the performance parameter. As an example, for some components, such as valves and pipes, component failures may be caused by leaks, partial path blockages, 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.). For example, EGR flow rate can vary depending on the degradation level (e.g., the severity of potential blockage, the severity of EGR pipe leakage, etc.). Each or some degradation levels within the expected degradation level range are specific DoE scenarios, and each DoE scenario is implemented as a separate computer-based simulation of the component.

[0086] The operation of method 400 includes (at positions 408-414) performing diagnostic analysis on the physical and / or electronic components of vehicle 10 using (obtained at position 406) computer-based simulation results for each FRU. More specifically, the diagnostic circuitry 256 of digital twin 20 is configured to determine (at position 410) the expected error value for each computer-based simulation (DoE scenario), such as Figure 6 As further illustrated below. Based on the expected error value, the diagnostic circuit 256 is configured to select from a set of computer-based simulations of the most probable DoE scenarios. Refer again to the EGR system diagnostic example from 406 and as shown below. Figure 7 As further illustrated, each computer-based simulation (DoE scenario) can correspond to a component's degradation level (failure magnitude). For example, based on a set of computer-based simulations generated by simulation circuit 254, a leakage rate of 10% to 90% can be expected for an EGR valve or EGR crosspipe. The most probable degradation level is determined by diagnostic circuit 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 predictive accuracy.

[0087] The operation of method 400 includes (at 416) sorting the most predictive computer-based simulations (determined at 410) for each FRU in a set of FRUs corresponding to a set of data received at 402, as referenced. Figure 8 Further described. Based on this ranking, diagnostic circuitry 256 is configured to identify the top N most likely faults in a set of FRUs. For example, as Figure 8 As further shown, a set of sample data received from the telematics circuitry of vehicle 10 can be identified as corresponding to the following potential fault conditions associated with the intake and exhaust systems of engine 16 of vehicle 10, ordered from most likely to least likely: limitation in EGR crosspipe, EGR valve failure (e.g., EGR valve stem partially or fully open or closed), EGR cooler limitation, variable geometry turbocharger (VGT) failure, leakage in EGR crosspipe, limitation in boost air cooler, leakage in boost air cooler, and limitation in intake path.

[0088] The operation of method 400 includes (at 418) based on, for example, reference Figure 2 The sorting is based on computer-generated simulations to generate electronic notifications. In some embodiments, the data management circuitry 252 is configured to send notifications to a computing system operated by the user, service provider, insurance provider, etc. of the vehicle 10.

[0089] Now for reference Figure 5 The diagram illustrates a graph of the output of a computer-based simulation, according to an exemplary embodiment, for checking potential inconsistencies between received data and predictions made during normal operation. In some embodiments, Figure 5 Some or all of the operations shown are performed only to verify the operation of the simulation circuit of the digital twin 20 (e.g., in verification or test mode), and are omitted in the actual operation of the digital twin 20 in the production system.

[0090] As shown in the figure, the computer-based simulation 500 includes predicted data over a period of time. This predicted data provides an estimate for a specific performance parameter (EGR flow, as shown in the figure), but those skilled in the art will understand that similar simulations can be performed for another performance parameter or a different time period. At each time point, the predicted data is compared with actual (test) data received from the sensors and actuators of vehicle 10 (e.g., at...). Figure 4 (at position 402). 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 these parameters can be truncated. Therefore, advantageously and unlike conventional diagnostic systems, the remote system 18 makes historical sensor and actuation data available for diagnostic and simulation verification purposes.

[0091] The results of simulation 500 can be used to verify the DoE design of a specific FRU in digital twin 20 and computer-based simulations. Additionally, if the DoE design of a specific FRU has been verified for a first digital twin 20 of a first vehicle 10, the results of simulation 500 can be used to predict FRU faults for a second digital twin 20 of a different second vehicle 10. This may include different installations of the same component. Therefore, remote system 18 can be initiated to analyze data from multiple components across multiple vehicles 10 to generate or predict fault diagnoses and / or generate proactive service recommendations for a specific vehicle.

[0092] Now for reference Figure 6 and Figure 7 The output of the verification results based on a computer simulation according to an example embodiment is shown.

[0093] Figure 6 This is a graph showing the output of a computer-based simulation used to compare with... Figure 1 Estimate (e.g., calculate, predict) the performance and / or degradation level of example components (e.g., FRU) among multiple components related to the vehicle engine. See reference... Figure 4 The method involves selecting a set of FRUs from all available (e.g., digitally simulated) FRUs in vehicle 10 that correspond to the actual received sensor and actuator data. For each performance parameter of each FRU, multiple computer-based simulations are performed, where each simulation corresponds to a DoE scenario for a specific fault type or degradation level.

[0094] For each of these computer simulations executed Figure 6The computer-based error quantization process is illustrated in graph 602, which plots the cumulative actual (test) values ​​received from the telematics circuitry 156 of the vehicle controller 14 of vehicle 10 over a specific time period. In some embodiments, these actual values ​​may be stored in the storage medium of the remote system 18, or they may be retained in volatile memory for a predetermined period of time required for data collection and simulation generation. The cumulative actual values ​​are plotted relative to the cumulative estimates generated by the computer-based simulation.

[0095] To determine the expected error, the cumulative value of the difference between the actual data points and the estimated data points at a specific time point is obtained. The cumulative value is normalized. A weighted average of this normalized value is determined. The expected error is calculated using Equation 606:

[0096]

[0097] 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 value and the actual value, and Test(i) is the cumulative actual value.

[0098] Figure 7 Showing from Figure 1 A graph showing the range of degradation levels of specific components of a vehicle's engine. (Refer to [source] again.) Figure 4 The 406 example of EGR system diagnostics shows that each computer-based simulation (DoE scenario) can correspond to a component's degradation level (failure magnitude). For example, based on a set of computer-based simulations generated by simulation circuit 254, a leakage rate of 10% to 90% can be expected for the EGR valve or EGR crosspipe. The most probable degradation level is determined by diagnostic circuit 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 predictive accuracy. Now refer to Figure 8 This illustrates, according to some embodiments, from Figure 1 A ranked list of predicted component failures for at least some of the multiple components of the vehicle's engine. Based on this ranking, diagnostic circuitry 256 is configured to identify the top N most likely failures of a set of FRUs. In one example embodiment, the ranking includes identifying the minimum error (as referenced) for each DoE of the FRU. Figure 6 The process involves selecting the appropriate FRU, and then sorting the results of the FRUs from smallest (most likely to fail) to largest (least likely to fail) based on the error magnitude of each FRU.

[0099] For the purposes of this disclosure, the term "coupled" refers to two components being directly or indirectly connected or linked to each other. Such a connection can be fixed or movable in nature. For example, the "coupled" driveshaft of an engine to a transmission represents a movable connection. This connection can be achieved using two components or two components plus 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 intermediate medium) or indirectly with circuit B (e.g., through one or more intermediate media). While various circuits with specific functions are shown in the accompanying drawings, it should be understood that the controller described herein can 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 can further control other activities beyond the scope of this disclosure.

[0100] As described above and in one configuration, the "circuit" can be implemented in a machine-readable medium for execution by various types of processors. For example, the circuit of identified executable code can include one or more computer instructions, organized as physical or logical blocks of objects, processes, or functions. However, the executable files of the identified circuit do not need to be physically located together, but can include scattered instructions stored in different locations that, when logically connected together, constitute the circuit and achieve the circuit's stated purpose. In practice, the circuit 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 within the circuit herein, and can be embodied in any suitable form and organized within any appropriate type of data structure. Operational data can be collected as a single dataset or distributed across different locations including different storage devices, and can exist at least partially as electronic signals on a system or network.

[0101] Although the term "processor" has been briefly defined above, it should be understood that the terms "processor" and "processing circuitry" are intended to be interpreted broadly. In this regard, and as stated 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 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 respect, a given circuitry or its components can be arranged locally or remotely (e.g., as part of a remote server, such as a cloud-based server). For this purpose, "circuitry" as described herein can include components distributed across one or more locations.

[0102] It should be noted that while the diagrams herein may illustrate the specific order and composition of the method steps, it should be understood that the order of these steps may differ from that depicted. For example, two or more steps may be performed simultaneously or partially simultaneously. Furthermore, some method steps may be combined as separate steps, steps performed as combined steps may be divided into separate steps, the order of certain processes may be reversed or otherwise varied, and the nature or number of separate processes may be altered or changed. According to alternative embodiments, the order or sequence of any element or device may be varied or substituted. Therefore, all such modifications are intended to be included within the scope of this disclosure as defined by the appended claims. These changes will depend on the machine-readable medium and hardware system chosen, as well as the designer's selection. It should be understood that all such changes are within the scope of this disclosure.

[0103] The above description of embodiments has been made for purposes of illustration and description. It is not intended to be exhaustive or to limit the present disclosure to the precise forms disclosed, and modifications and variations may be made in accordance with the above teachings, or may be obtained from the present disclosure. The embodiments were chosen and described to explain the principles of the present disclosure and its practical application, enabling those skilled in the art to utilize various implementations and modifications suitable for the particular intended use. Other substitutions, modifications, alterations, and omissions may be made in the design, operating conditions, and arrangement of the embodiments without departing from the scope of the present disclosure as set forth in the appended claims.

Claims

1. A system, characterized in that, include: One or more processors, coupled to memory and communicating with an engine system including multiple field-replaceable units (FRUs), are configured to: Generate a computer-based simulation corresponding to each of the multiple FRUs of the engine system; The degradation level of each of the plurality of FRUs is determined based on the computer-based simulation and operational data of each of the plurality of FRUs; Based on the degradation level of the FRU, identify the FRU corresponding to the fault in the engine system from the plurality of FRUs; as well as An electronic notification is provided, indicating that a fault in the engine system corresponds to the FRU.

2. The system according to claim 1, characterized in that, The one or more processors are further configured to: Receive operational data from the engine system, including information from at least one of the sensors or actuators within the engine system; as well as The operational data is used to identify multiple FRUs in the engine system, each of which corresponds to one or more components within the engine system.

3. The system according to claim 1, characterized in that, The one or more processors are further configured to: Based on the computer-based simulation and operational data, multiple degradation levels for multiple fault scenarios are determined for each of the plurality of FRUs; as well as Based on the degradation level among multiple degradation levels of associated fault scenarios in the corresponding multiple fault scenarios, the FRU corresponding to the fault in the engine system is identified from the multiple FRUs.

4. The system according to claim 1, characterized in that, The one or more processors are further configured to: The computer-based simulation is performed to generate output data for each of the plurality of FRUs in the engine system; as well as The degradation level of each of the plurality of FRUs is determined by comparing the output data from the computer-based simulation with the expected output of the operational data.

5. The system according to claim 1, characterized in that, The one or more processors are further configured to: Identify the operational data of the first FRU among the plurality of FRUs; and Using the operational data of the first FRU, a computer-based simulation is generated for the second FRU among the plurality of FRUs.

6. The system according to claim 1, characterized in that, The one or more processors are further configured to: The multiple FRUs are sorted based on the degradation level of each FRU; Based on the order of the plurality of FRUs, a subset of FRUs is identified as potential faults in the engine system; as well as The electronic notification is provided, indicating that the subset of FRUs represents a potential fault in the engine system.

7. The system according to claim 1, characterized in that, The one or more processors are also configured to generate the electronic notification to include at least one of a plurality of codes for corresponding potential faults in the engine system.

8. The system according to claim 1, characterized in that, The one or more processors are also configured to generate the electronic notification to indicate at least one of a plurality of service recommendations, including whole component replacement, partial component replacement, or repair of a component associated with the FRU.

9. A method, characterized in that, include: A computer-based simulation corresponding to each of the plurality of FRUs of the engine system is generated by a computing system that communicates with an engine system comprising a plurality of field replaceable units (FRUs). The degradation level of each of the plurality of FRUs is determined by the computing system based on the computer-based simulation and operational data of each of the plurality of FRUs; The computing system identifies the FRUs corresponding to the faults in the engine system from among the plurality of FRUs based on the degradation level of the FRUs; as well as The computing system provides electronic notifications indicating that a fault in the engine system corresponds to the FRU.

10. The method according to claim 9, characterized in that, Also includes: The computing system receives operational data from the engine system, including information from at least one of the sensors or actuators within the engine system. as well as The computing system uses the operational data to identify multiple FRUs in the engine system, each of which corresponds to one or more components within the engine system.

11. The method according to claim 9, characterized in that, Also includes: Based on the computer-based simulation and the operational data, multiple degradation levels for multiple fault scenarios are determined for each of the multiple FRUs; as well as The computing system identifies the FRU corresponding to the fault in the engine system from the plurality of FRUs based on the degradation level among the multiple degradation levels of the associated fault scenarios in the corresponding multiple fault scenarios.

12. The method according to claim 9, characterized in that, Also includes: The computer-based simulation is performed by the computing system to generate output data for each of the plurality of FRUs in the engine system. Determining the degradation level further includes determining the degradation level of each of the plurality of FRUs by comparing the output data from the computer-based simulation with the expected output of the operational data.

13. The method according to claim 9, characterized in that, It also includes sorting the plurality of FRUs based on the degradation level of each FRU in the plurality of FRUs using the computing system. The identification of the FRU further includes: identifying a subset of FRUs as potential faults in the engine system based on the order of the plurality of FRUs, and Providing electronic notifications also includes providing electronic notifications indicating that the subset of FRUs represents a potential fault in the engine system.

14. The method according to claim 9, characterized in that, It also includes generating the electronic notification via the computing system to include at least one of a plurality of codes for corresponding potential faults in the engine system.

15. The method according to claim 9, characterized in that, It also includes generating the electronic notification via the computing system to indicate at least one of a plurality of service recommendations, including whole component replacement, partial component replacement, or repair of a component associated with the FRU.

16. A computing system, characterized in that, include: At least one processing circuit, including at least one processor coupled to a memory, said at least one processing circuit is configured to: Generate a computer-based simulation corresponding to each of the multiple field replaceable units (FRUs) in the engine system; The degradation level of each of the plurality of FRUs is determined based on the computer-based simulation and operational data of each of the plurality of FRUs; Based on the degradation level of the FRU, identify the FRU corresponding to the fault in the engine system from the plurality of FRUs; as well as An electronic notification is provided, indicating that a fault in the engine system corresponds to the FRU.

17. The computing system according to claim 16, characterized in that, The at least one processing circuit is further configured to: Receive operational data from the engine system, including information from at least one of the sensors or actuators within the engine system; as well as The operational data is used to identify multiple FRUs in the engine system, each of which corresponds to one or more components within the engine system.

18. The computing system according to claim 16, characterized in that, The at least one processing circuit is further configured to: Based on the computer-based simulation and the operational data, multiple degradation levels for multiple fault scenarios are determined for each of the multiple FRUs; as well as Based on the degradation level among multiple degradation levels of associated fault scenarios in the corresponding multiple fault scenarios, the FRU corresponding to the fault in the engine system is identified from the multiple FRUs.

19. The computing system according to claim 16, characterized in that, The at least one processing circuit is further configured to: The computer-based simulation is performed to generate output data for each of the multiple FRUs in the engine system; as well as The degradation level of each of the plurality of FRUs is determined by comparing the output data from the computer-based simulation with the expected output of the operational data.

20. The computing system according to claim 16, characterized in that, The at least one processing circuit is further configured to: The multiple FRUs are sorted based on the degradation level of each FRU; Based on the order of the plurality of FRUs, a subset of FRUs is identified as potential faults in the engine system; as well as An electronic notification is provided, indicating that the subset of FRUs represents a potential fault in the engine system.

Images