[go: up one dir, main page]

WO2024119094A1 - Systèmes et procédés de journalisation de données à l'aide d'ingénierie de systèmes basée sur un modèle pour une analyse de défaillance - Google Patents

Systèmes et procédés de journalisation de données à l'aide d'ingénierie de systèmes basée sur un modèle pour une analyse de défaillance Download PDF

Info

Publication number
WO2024119094A1
WO2024119094A1 PCT/US2023/082108 US2023082108W WO2024119094A1 WO 2024119094 A1 WO2024119094 A1 WO 2024119094A1 US 2023082108 W US2023082108 W US 2023082108W WO 2024119094 A1 WO2024119094 A1 WO 2024119094A1
Authority
WO
WIPO (PCT)
Prior art keywords
fault
vehicle
parameters
computing system
model
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2023/082108
Other languages
English (en)
Inventor
Ninad Ghike
Chandrasekar SUNDARAM
Chaitanya Rao
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cummins Inc
Original Assignee
Cummins Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cummins Inc filed Critical Cummins Inc
Publication of WO2024119094A1 publication Critical patent/WO2024119094A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F02—COMBUSTION ENGINES; HOT-GAS OR COMBUSTION-PRODUCT ENGINE PLANTS
    • F02D—CONTROLLING COMBUSTION ENGINES
    • F02D41/00—Electrical control of supply of combustible mixture or its constituents
    • F02D41/22—Safety or indicating devices for abnormal conditions
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/04—Monitoring the functioning of the control system
    • B60W50/045—Monitoring control system parameters
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0787—Storage of error reports, e.g. persistent data storage, storage using memory protection
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W2050/0001—Details of the control system
    • B60W2050/0019—Control system elements or transfer functions
    • B60W2050/0028—Mathematical models, e.g. for simulation
    • B60W2050/0037—Mathematical models of vehicle sub-units
    • B60W2050/0039—Mathematical models of vehicle sub-units of the propulsion unit
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/0205—Diagnosing or detecting failures; Failure detection models
    • B60W2050/022—Actuator failures
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/04—Monitoring the functioning of the control system
    • B60W50/045—Monitoring control system parameters
    • B60W2050/046—Monitoring control system parameters involving external transmission of data to or from the vehicle, e.g. via telemetry, satellite, Global Positioning System [GPS]
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2510/00—Input parameters relating to a particular sub-units
    • B60W2510/06—Combustion engines, Gas turbines
    • B60W2510/0657—Engine torque
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2510/00—Input parameters relating to a particular sub-units
    • B60W2510/06—Combustion engines, Gas turbines
    • B60W2510/0666—Engine power
    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F02—COMBUSTION ENGINES; HOT-GAS OR COMBUSTION-PRODUCT ENGINE PLANTS
    • F02D—CONTROLLING COMBUSTION ENGINES
    • F02D41/00—Electrical control of supply of combustible mixture or its constituents
    • F02D41/02—Circuit arrangements for generating control signals
    • F02D41/14—Introducing closed-loop corrections
    • F02D41/1401—Introducing closed-loop corrections characterised by the control or regulation method
    • F02D2041/1433—Introducing closed-loop corrections characterised by the control or regulation method using a model or simulation of the system
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/81—Threshold

Definitions

  • the present disclosure relates to managing data storage. More particularly, the present disclosure relates to logging data using model-based systems engineering (MBSE) for fault analysis.
  • MBSE model-based systems engineering
  • the vehicles can transmit data (e.g., a superset of data) to a cloud over the air using a telematics device. This allows the logging of the data for the vehicles for remote processing without interrupting vehicle operations.
  • Supersets of data e.g., all monitored/recorded data
  • these supersets of data continue to accumulate in the database at an increasing rate, resulting in non-optimized costs associated with data logging, storage, and maintenance. Better systems and methods for logging/ storing data are desired.
  • the computing system includes a processing circuit having one or more memory devices coupled to one or more processors.
  • the one or more memory devices are configured to store instructions that, when executed by the one or more processors, cause the processing circuit to: receive an indication of a fault from a vehicle; select, using a model corresponding to the fault, a set of parameters related to the fault; transmit, to the vehicle, the selected set of parameters for monitoring; receive, from the vehicle, data regarding the set of parameters monitored for a predefined period; and store the data in the one or more memory devices for diagnosing the fault.
  • Another embodiment relates to a method.
  • the method includes: receiving, by a processing circuit comprising one or more memory devices coupled to one or more processors, an indication of a fault triggered at a first time instance from a vehicle; selecting, by the processing circuit using a model corresponding to the fault, a set of parameters related to the fault; transmitting, by the processing circuit to the vehicle, the set of parameters for monitoring; receiving, by the processing circuit from the vehicle, data regarding the set of parameters; and storing, by the processing circuit, the data in the one or more memory devices for diagnosing the fault.
  • Still another embodiment relates to a system.
  • the system includes one or more processors and one or more memory devices coupled to the one or more processors.
  • the one or more memory devices store instructions that, when executed by the one or more processors, cause the one or more processors to: receive, from a vehicle monitoring a plurality of parameters, an indication of a fault; select, using a model corresponding to the fault, a set of parameters related to the fault; send, to the vehicle, a command to monitor the set of parameters; receive, from the vehicle, data regarding the set of parameters; and diagnose the fault according to the data regarding the set of parameters.
  • FIG. 1 is a schematic diagram of an example remote monitoring, diagnostics, prognostics, and control computing system, according to an example implementation.
  • FIG. 2 is a schematic view of an example computing system of FIG. 1, according to an example implementation.
  • FIG. 3 is a flow diagram showing a process flow for a reactive data logging method, according to an example implementation.
  • FIG. 4 is a flow diagram showing a process flow for a predictive data logging method, according to an example implementation.
  • FIG. 5 is a flow diagram of a method for logging data using model-based systems engineering (MBSE) for fault analysis using the computing system of FIGS. 1-2, according to an example implementation.
  • MBSE model-based systems engineering
  • data can be stored in a database, such as a remote database or a cloud, for remote fault analysis and diagnosis.
  • the data is communicated by a vehicle to the remote database for storage.
  • the data can be retrieved by one or more devices (e.g., remote from the vehicle) for processing, such as for fault analysis or diagnosis.
  • the systems and methods of the technical solution discussed herein include a computing system in communication with a vehicle and a database.
  • the database is included with the remote computing system. An indication of one or more faults triggered in the vehicle is communicated to the computing system.
  • the computing system communicates the indication of the one or more faults to a database and retrieves/obtains a corresponding model. Using the model, the system selects or identifies a set of parameters related to the fault.
  • the one or more parameters are a subset of a superset of data collected/monitored by the vehicle and, particularly, by a control system of the vehicle.
  • the system communicates the set of parameters to the vehicle thereby instructing the vehicle and, particularly the control system, to track/monitor only those indicated parameter(s).
  • the vehicle may selectively then periodically provide the indicated parameter(s) to the computing system.
  • the computing system Upon receiving the data, the computing system is configured to store the data in the memory.
  • the systems and methods can receive and store a portion of the superset of data (e.g., the set of identified parameter(s)) for analyzing the respective fault. Therefore, the systems and methods of the technical solution can minimize the cost of data logging, storage, and maintenance by reducing or avoiding communications of supersets of data, which include parameters unnecessary to perform analysis for certain types of faults. Further, by reducing communications of unneeded parameters, the systems and methods can minimize network bandwidth consumption, reduce network traffic, and optimize resource availability in the memory.
  • a system 100 that includes a computing system 104 coupled to a vehicle 108 is shown, according to an example embodiment. While only one vehicle 108 is depicted, it should be appreciated that the computing system 104 may be coupled to a plurality of vehicles that may have a variety of configurations (e.g., marine vehicles, stationary vehicles such as gensets, etc.). The vehicles may be part of a fleet, or be a plurality of independently operated vehicles. In some embodiments, the vehicle 108 may be a part of a fleet of vehicles. The vehicles of the fleet may have a similar or different configuration and structure relative to the vehicle 108. Each vehicle of the fleet may be coupled to the computing system 104.
  • a computing system 104 may have a variety of configurations (e.g., marine vehicles, stationary vehicles such as gensets, etc.).
  • the vehicles may be part of a fleet, or be a plurality of independently operated vehicles.
  • the vehicle 108 may be a part of a fleet of vehicles.
  • the vehicles of the fleet may
  • an operator, manager, etc. of the fleet may couple to the computing system 104 (e.g., via one or more computing devices, such as a tablet computer, mobile smartphone, desktop computer, etc.).
  • the vehicle 108 includes an engine 12, an aftertreatment system 38, a telematics unit 34, a controller 28, a powertrain 26 (also referred to as a powertrain system), and an operator I/O 30 (also referred to as an operator I/O device).
  • the vehicle 108 can be any type of on-road or off-road vehicle including, but not limited to, line-haul trucks, midrange trucks (e.g., pick-up trucks, etc.), sedans, coupes, tanks, airplanes, boats, and any other type of vehicle.
  • the vehicle in some embodiments, may also be stationary equipment (e.g., a generator or genset, etc.).
  • the vehicle 108 may include more, less, and/or different components than those described herein in some other embodiments.
  • the engine 12 may be any type of internal combustion engine.
  • the engine 12 may be a gasoline, natural gas, diesel engine, and/or any other suitable engine.
  • the engine 12 may be a part of a hybrid engine system (e.g., a combination of an internal combustion engine and an electric motor(s)).
  • the engine 12 is a diesel-powered compression-ignition engine.
  • the engine 12 includes a first cylinder 14, a second cylinder 16, a third cylinder 18, a fourth cylinder 20, a fifth cylinder 22, and a sixth cylinder 24 (collectively referred to herein as “cylinders 14-24”). It should be understood that, while six cylinders are represented in FIG. 1, the number of cylinders may vary depending upon system configurations and requirements.
  • the cylinders 14-24 can be any type of cylinders suitable for the engine in which they are disposed (e.g., sized and shaped appropriately to receive pistons).
  • the aftertreatment system 38 is in exhaust-gas receiving communication with the engine 12.
  • the aftertreatment system 38 includes a diesel oxidation catalyst (DOC) 40, a diesel particulate filter (DPF) 42, a reductant delivery system 44, a selective catalytic reduction (SCR) system 46, an ammonia slip catalyst (ASC) 48, and a heater 36.
  • the DOC 40 is structured to receive the exhaust gas from the engine 12 and to oxidize hydrocarbons and carbon monoxide in the exhaust gas.
  • the DPF 42 is arranged or positioned downstream of the DOC 40 and structured to remove particulates, such as soot, from exhaust gas flowing in the exhaust gas stream.
  • the DPF 42 includes an inlet, where the exhaust gas is received, and an outlet, where the exhaust gas exits after having particulate matter substantially filtered from the exhaust gas. In some implementations, the DPF 42 may be omitted.
  • the aftertreatment system 38 may further include a reductant delivery system 44 which may include a decomposition chamber (e.g., decomposition reactor, reactor pipe, decomposition tube, reactor tube, etc.) to convert a reductant into ammonia.
  • the reductant may be, for example, urea, diesel exhaust fluid (DEF), Adblue®, a urea water solution (UWS), an aqueous urea solution (e.g., AUS32, etc.), and other similar fluids.
  • a diesel exhaust fluid (DEF) is added to the exhaust gas stream to aid in the catalytic reduction.
  • the reductant may be injected upstream of the SCR catalyst member by a DEF doser 44 such that the SCR catalyst member receives a mixture of the reductant and exhaust gas.
  • the reductant droplets then undergo the processes of evaporation, thermolysis, and hydrolysis to form gaseous ammonia within the decomposition chamber, the SCR catalyst member, and/or the exhaust gas conduit system, which leaves the aftertreatment system 38.
  • the aftertreatment system 38 may further include an oxidation catalyst (e.g., the DOC 40) fluidly coupled to the exhaust gas conduit system to oxidize hydrocarbons and carbon monoxide in the exhaust gas.
  • the DOC 40 may be required to be at a certain operating temperature.
  • this certain operating temperature is between 200-500 °C. In other embodiments, the certain operating temperature is the temperature at which the conversion efficiency of the DOC 40 exceeds a predefined threshold (e.g., the conversion of HC to less harmful compounds, which is known as the HC conversion efficiency).
  • a predefined threshold e.g., the conversion of HC to less harmful compounds, which is known as the HC conversion efficiency
  • the SCR 46 is configured to assist in the reduction of NOx emissions by accelerating a NOx reduction process between the ammonia and the NOx of the exhaust gas into diatomic nitrogen, water, and/or carbon dioxide. If the SCR catalyst member is not at or above a certain temperature, the acceleration of the NOx reduction process is limited and the SCR 46 will not be operating at a necessary level of efficiency to meet regulations. In some embodiments, this certain temperature is 250-300°C.
  • the SCR catalyst member may be made from a combination of an inactive material and an active catalyst, such that the inactive material, (e.g., ceramic metal) directs the exhaust gas towards the active catalyst, which is any sort of material suitable for catalytic reduction (e.g., base metals oxides like vanadium, molybdenum, tungsten, etc. or noble metals like platinum).
  • the ASC 48 may be any of various flow-through catalysts, such as an ammonia oxidation (AMOX) catalyst, structured to react with ammonia to produce mainly nitrogen.
  • ASC 48 is structured to remove ammonia that has slipped through or exited the SCR 46 without reacting with NOx in the exhaust.
  • the aftertreatment system 38 can be operable with or without the ASC 48.
  • the ASC 48 is shown as a separate unit from the SCR 46 in FIG. 1, in some implementations, the ASC 48 may be integrated with the SCR 46, e.g., the ASC 48 and the SCR 46 can be located within the same housing. According to the present disclosure, the SCR 46 and ASC 48 are positioned serially, with the SCR 46 preceding the ASC 48.
  • the aftertreatment system 38 treats the exhaust gas before the exhaust gas is released into the atmosphere, much of the particulate matter or chemicals that are treated or removed from the exhaust gas build up in the aftertreatment system over time. For example, the soot filtered out from the exhaust gas by the DPF 42 builds up on the DPF 42 over time.
  • a heater 36 is located in the exhaust flow path before the aftertreatment system 38 and is structured to controllably heat the exhaust gas upstream of the aftertreatment system 38.
  • the heater 36 may be any sort of heat source that can be structured to increase the temperature of passing exhaust gas (or component temperature directly), which, in turn, increases the temperature of components in the aftertreatment system 38, such as the DOC 40 or the SCR catalyst member, thereby improving vehicle 108 performance while reducing fuel and DEF usage.
  • the heater may be an electric heater, an induction heater, a microwave, or a fuel-burning (e.g., HC fuel) heater.
  • the heater 36 is an electric heater that draws power from a battery of the vehicle 108. In other embodiments, more than one heater 36 is included and/or the heater(s) are disposed within the aftertreatment system.
  • a telematics unit 34 is included with the vehicle 108.
  • the telematics unit 34 may include, but is not limited to, one or more memory devices for storing tracked data, one or more electronic processing units for processing the tracked data, and a communications interface for facilitating the exchange of data between the telematics 34 and one or more remote devices (e.g., the computing system 104 or database 106).
  • the communications interface may be configured as any type of communications interface or protocol including, but not limited to, WiFi, WiMax, Internet, Radio, Bluetooth, Zigbee, satellite, radio, Cellular, GSM, GPRS, LTE, and/or the like.
  • the telematics unit 34 may also include a communications interface for communicating with the controller 28 of the vehicle 108.
  • the communication interface for communicating with the controller 28 may include any type and number of wired and wireless protocols (e.g., any standard under IEEE 802, etc.).
  • a wired connection may include a serial cable, a fiber optic cable, an SAE J1939 bus, a CAT5 cable, or any other form of wired connection.
  • a wireless connection may include the Internet, Wi-Fi, Bluetooth, Zigbee, cellular, radio, etc.
  • a controller area network (CAN) bus including any number of wired and wireless connections provides the exchange of signals, information, and/or data between the controller 28 and the telematics unit 34.
  • the communication between the telematics unit 34 and the controller 28 is via the unified diagnostic services (UDS) protocol. All such variations are intended to fall within the spirit and scope of the present disclosure.
  • UDS unified diagnostic services
  • the powertrain 26 of the vehicle 108 can include the engine 12 coupled to a transmission of the vehicle 108 (among potentially other components).
  • the transmission may be operatively coupled to a drive shaft which is operatively coupled to a differential, where the differential transfers power output from the engine 12 to the final drive (e.g., the wheels of the vehicle 108, tracks for some off-road applications) to help propel the vehicle 108.
  • the powertrain 26 can be controlled by the controller 28 to drive the vehicle 108, such as responsive to instructions, commands, or actions by the operator. In some cases, the powertrain 26 can receive instructions from an operator I/O 30 coupled with the controller 28.
  • the powertrain system 26 may include an electric motor (not shown) and/or electric motor-generator (not shown) structured to generate and provide electrical energy to one or more vehicle accessories (hence, generator) as well as to at least partly propel the vehicle.
  • the motor generator may be operably coupled to the engine 12 and the transmission such that, in these implementations, the vehicle 108 is structured as a hybrid vehicle (e g., a combination of an internal combustion engine and an electric motor or motor/generator).
  • the engine 12 may be omitted and the vehicle is a full electric vehicle.
  • the vehicle 108 is structured as a plug-in hybrid vehicle, a fuel cell electric vehicle, and various other types of vehicles that utilize fluid.
  • the motor generator may receive power from an energy source, such as a battery that provides an input energy to output usable work or energy to in some instances propel the vehicle 108 alone or in combination with the engine 12.
  • energy may be diverted to charge the battery or any electrical powered accessories within the vehicle.
  • the battery may be charged through regenerative braking, a fuel cell, or a combination of both.
  • the operator I/O 30 may be communicably coupled to the controller 28, such that information may be exchanged between the controller 28 and the operator I/O 30, where the information may relate to one or more components of the vehicle 108 or other components of the system 100 or determinations (described below) of the controller 28.
  • the operator I/O 30 can enable an operator of the vehicle 108 to communicate with the controller 28 and one or more components of the vehicle 108 of FIG. 1.
  • the operator I/O 30 may include, but is not limited to, an interactive display, a touchscreen device, one or more buttons and switches, voice command receivers, etc.
  • the operator I/O 30 can display a GUI to the operator (e.g., the user or the client) of the vehicle 108.
  • the operator I/O 30 may provide one or more indications or notifications to an operator, such as a malfunction indicator lamp (MIL), etc.
  • the vehicle 108 may include a port that enables the controller 28 to connect or couple to a scan tool so that fault conditions and other information regarding the vehicle may be obtained.
  • the controller 28 is coupled to the engine 12, the aftertreatment system 38, the telematics unit 34, the powertrain 26, and the operator I/O 30, among other potential components, and is structured or configured to at least partly control these systems/devices. Communication between and among the components may be via any number of wired or wireless connections.
  • a wired connection may include a serial cable, a fiber optic cable, a CAT5 cable, or any other form of wired connection.
  • a wireless connection may include the Internet, Wi-Fi, cellular, radio, etc.
  • a CAN bus provides the exchange of signals, information, and/or data.
  • the CAN bus includes any number of wired and wireless connections.
  • the controller 28 may be configured to receive signals, information, data, etc. (e.g., engine operating parameter signals and/or aftertreatment system operating parameter signals) from sensors such as exhaust flow rate sensors, speed sensors, pressure sensors, temperature sensors, and/or any other sensors associated with the engine 12 or the aftertreatment system 38.
  • controller 28 may be configured to receive data monitored by one or more components of the vehicle 108 (e.g., the powertrain 26, etc.) and transmit the signals, information, data, etc., to one or more devices (e.g., computing system 104) within the network 102 using the telematics unit 34.
  • vehicle 108 e.g., the powertrain 26, etc.
  • devices e.g., computing system 104
  • the controller 28 is configured to receive data from various components of the vehicle 108 including monitored data or parameters, for instance, from the powertrain 26, sensors (e.g., pressure sensors, gas sensors, NOx sensors, flow sensors, torque sensors, or other sensors coupled to the engine 12 or the aftertreatment system 38), etc.
  • the controller 28 is configured to use the monitored data to determine whether at least one fault has occurred in the vehicle 108.
  • the fault may include a fault code, such as a fault code regarding operation of the engine, the aftertreatment system or a component thereof, an oil system fault, and so on.
  • the controller 28 is configured to identify the different types of faults based on monitoring the data related to the respective types of fault.
  • the controller 28 Upon identifying at least one fault, the controller 28 triggers an indication of the fault.
  • the controller 28 may transmit the indication of the fault to a remote device (e.g., computing system 104) via the telematics unit 34.
  • the controller 28 transmits the indication of the fault in response to the fault being triggered.
  • the data includes one or more parameters, such as requested torque, energy output/consumption, torque output, operating data or parameters (e.g., torque/speed, transmission setting, temperature information at various locations, determined information (e.g., NOx conversion efficiency, ammonia slip, etc.), emissions information (e.g., greenhouse gases, etc.), state of charge and/or other information regarding a battery(ies) of the vehicle, presence of an engine derate condition, presence and/or absence of fault codes, time since last service event, hours of operation/mileage of operation of the vehicle 108, among other information about the vehicle 108.
  • the data may be acquired at particular times, an average over a period of operation (e.g., time, distance, etc.), and so on.
  • the fault includes a fault condition that includes a fault code.
  • the fault code may be a specific code (e.g., FC 1234) stored in the ECM (e.g., controller 28) and/or accessed via a scan tool and/or other service tools.
  • the fault code can indicate an error with respect to a system or component of the vehicle 108.
  • the fault includes a fault condition that may not correspond with a fault code (at least not presently).
  • NOx conversion efficiency may be below a predetermined threshold for a certain duration. This duration may be relatively short, such that the fault code associated with the aftertreatment system 38 may not be triggered.
  • this operating condition may correspond with a fault condition.
  • Other types of data that may correspond with a fault condition include, but are not limited, an ammonia slip amount above a predefined threshold, a pressure differential across the DPF being above a predefined threshold, a fluid temperature above a predefined threshold, and so on.
  • the controller 28 is configured to predict an occurrence of a fault based on the data regarding operation of one or more other components of the vehicle 108.
  • the faults to be predicted include, but are not limited, performance and/or emission related faults for powertrain and vehicles. This includes the controller 28 collecting the data sensor information, application health information, and software parameters which are examined while activating the fault. This data collected is passed through prediction models which include physics based models, machine learning models (regression models, neural networks, etc.) to understand the sensor data trend and then make prediction(s) whether the fault will be triggered or not. For example, for a battery temperature high fault, the controller 28 may monitor data including battery temperature sensor information, battery state of charge, vehicle speed, battery coolant temperature sensor, and ambient temperature sensor.
  • This data is run through a regression model to predict, for the current and upcoming vehicle operating conditions (which may be received via the telematics unit), whether the battery temperature will cross the threshold temperature to trigger the fault in the vehicle.
  • This disclosure is applicable to all or mostly all fault codes which are present in a MBSE database (which are populated based on a historical MBSE analysis using tools and languages like SysML, UML, etc.). Further, engineering parameters may be logged along with their respective component details specific to each fault code. Accordingly, the list of parameters may be derived from the MBSE database specific to each of the fault code originating at controller 28.
  • the controller 28 may determine that a fault (e.g., a fault code or fault condition) may be triggered or occur at a predefined time instance (e.g., 30 seconds, 1 minute, 5 minutes, etc.) in the future. In response to the determination, the controller 28 transmits the indication of the predicted fault to the computing system 104 using the telematics unit 34, for example.
  • a fault e.g., a fault code or fault condition
  • a predefined time instance e.g. 30 seconds, 1 minute, 5 minutes, etc.
  • the controller 28 may be structured as one or more electronic control units (ECU). As described herein, in some cases, the controller 28 can transmit instructions to the computing system 104 to be stored or processed. The function and structure of the computing system 104 is described in greater detail in at least FIGS. 2-5.
  • the controller 28 may be configured for V2X communications with or without the usage of a telematics unit 34.
  • the controller 28 may be directly or indirectly coupled to the telematics unit 34 configured for V2X communication.
  • the controller 28 may include a network interface for external communication.
  • the controller 28 may be structured to exchange information from the computing system 104 over a wide area network communicating directly with the vehicle 108.
  • the controller 28 may communicate with the computing system 104 via the telematics unit 34.
  • the computing system 104 is in communication with the vehicle 108 and at least one database 106 via a network 102.
  • the network 102 may be any type of communication protocol that facilitates the exchange of information between and among the vehicle 108 and the computing system 104.
  • the network 102 may be an interconnection of devices remote or local to one another, which uses at least one type of communication protocol facilitating the exchange of information between various devices or components (e.g., vehicle 108, computing system 104, database 106, etc.) connected to the network 102.
  • the network 102 may be a wireless network, such as Wi-Fi, WiMax, Geographical Information System (GIS), Internet, Radio, Bluetooth, Zigbee, satellite, radio, Cellular, Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Long Term Evolution (LTE), light signaling, etc.
  • the network 102 may be configured as a wired network or a combination of wired and wireless protocol.
  • the controller 28 and/or telematics unit 34 of the vehicle 108 may electrically, communicably, and/or operatively couple via fiber optic cable to the network 102 to selectively transmit to and receive data wirelessly to and from the computing system 104.
  • the computing system 104 can be operated by, owned by, managed by, controlled by, and/or associated with a provider entity (not shown).
  • the provider entity may be an equipment manufacturer (e.g., engine manufacturer, aftertreatment system manufacturer, controller manufacturer, etc.).
  • the provider entity may be a manager of equipment, such as a fleet operator or manager.
  • the provider entity may also be an analytics provider.
  • the analytics may include diagnostics, prognostics, and/or remote monitoring regarding the monitored equipment (e.g., vehicles 108).
  • the computing system 104 creates and curates a database or a data repository of vehicle information that contains information related to the vehicle operation (e.g., engine performance parameters, etc.) for the plurality of vehicles of the fleet.
  • the database may include information specific to a plurality of routes for the vehicles of the fleet, conditions of the components and/or vehicle associated with certain component parameters, fleet information, other vehicle information, etc.
  • the computing system 104 is configured to access the database 106 storing various models to perform advanced analytics to determine and identify patterns, among other analyses. These advanced analytics may be based on the utilization of Artificial Intelligence (Al), physics-based models, machine learning, etc.
  • the determined and identified patterns may relate to repeated instances of similar parameter values (e.g., pressure values, temperature values, location data associated with other parameters, etc.) for a vehicle(s) along similar routes, under similar operating conditions, or of similar types. These patterns may be associated with a particular vehicle in the fleet, may be associated with a particular type of vehicle (e.g., a vehicle with internal combustion engine that utilizes diesel fuel), and/or these patterns may be associated with a particular route.
  • similar parameter values e.g., pressure values, temperature values, location data associated with other parameters, etc.
  • the computing system 104 is configured to receive data associated with the fleet (or single vehicle 108) directly from the respective vehicle(s) or from a remote database, a source, or a data repository. In one embodiment, information regarding each vehicle in the fleet is maintained by another remote computing system (not shown). The computing system 104 may periodically receive fleet information from this remote computing system. In another embodiment, the computing system 104 periodically receives information from one or more of the vehicles of the fleet directly via the network 102. The data associated with the fleet may be a part of population data. The computing system 104 is configured to store the data received from the network 102 in the memory (e.g., local storage). The stored data may be accessed for analysis of the vehicle 108, such as fault analysis or diagnosis.
  • the stored data may be removed from the computing system 104 after a predefined time period (e.g., after an expiration period) or moved to the remote computing system or remote database.
  • the stored data can be maintained in the local memory until the computing system 104 receives a command to remove the stored data from an administrator of the computing system 104.
  • the database 106 can be remote from the computing system 104 of the vehicle 108. In some implementations, the database 106 is a part of the computing system 104.
  • the database 106 may be referred to as a model database configured to store, manage, or configure various models or metrics.
  • the models or metrics may be generated for and specific to one or more fault conditions signified by one or more vehicle fault codes. In another embodiment, the models or metrics may be specific to various operating conditions independent of whether a fault code is triggered/generated.
  • the models can include or correspond to an algorithm, function, processes, events, look-up table for associating fault condition with parameter(s) of the vehicle 108, etc.
  • the database 106 stores at least one model for a respective type of fault, such as a first model for first fault code or type, a second model for second fault code or type, etc. Different models can be utilized for predicting these faults, such as regression models, neural networks, classification models, decision trees, etc.
  • the database 106 is accessible by the computing system 104 to retrieve or use one or more models. In some cases, the database 106 is accessible to the vehicle 108, such as for the controller 28 to retrieve or use the one or more models.
  • the database 106 is configured to receive an indication of the fault from the computing system 104 or directly from the vehicle 108.
  • the database 106 selects a model based on the indication of the fault, such as the type of fault.
  • the database 106 determines a set or a list of one or more parameters related to the fault (e.g., input parameters for analyzing or diagnosing the fault).
  • the computing system 104 may identify a list of parameters that are typically responsible for the fault condition.
  • the computing system 104 can perform similar operations or functionalities as the database 106 as described in conjunction with at least FIGS. 2-5. In this way and as described herein, the computing system 104 transmits a command with the identified set of parameters to track/monitor by the vehicle such that a superset of data is not tracked.
  • the computing system 104 includes one or more circuits and at least one communications interface 216.
  • the computing system 104 may be communicably coupled to the vehicle 108, the database 106, or other remote devices/components (e.g., vehicle fleet or client devices) via the network 102.
  • the computing system 104 may be a part of the vehicle 108 and is configured to receive data or information directly from the one or more components of the vehicle 108.
  • the database 106 may be a part of the computing system 104 and/or the vehicle 108.
  • the computing system 104 is shown to include a processing circuit 202 having at least one processor 206 coupled to at least one memory 204, a fault circuit 208, a model circuit 210, a storage circuit 212, an user interface circuit 214, and a communications interface 216.
  • the components of the computing system 104 are combined into a single unit.
  • one or more of the components may be geographically dispersed.
  • various components of the computing system 104 discussed below, may be dispersed in separate devices or components that are physically separate and remote from each other.
  • the communications interface 216 may include any combination of wired and/or wireless interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wire terminals) for conducting data communications with various systems and/or devices.
  • the communications interface 216 may be structured to communicate via local area networks and/or wide area networks (e.g., the Internet) and may use a variety of communications protocols (e.g., IP, LON, Bluetooth, ZigBee, radio, cellular, near field communication).
  • the computing system 104 can use the communications interface 216 to communicate with other vehicles in the fleet of one or more vehicles.
  • the computing system 104 may be used to collect information from the vehicle system by transmitting a command for one or more parameters to the controller 28 indicating the one or more parameters for transmission to the computing system 104.
  • the fault circuit 208, model circuit 210, storage circuit 212, or user interface circuit 214 can be embodied as a machine or computer-readable media storing instructions that are executable by a processor, such as processor 206.
  • the computer or machine-readable media may include programmable logic including code, which may be written in any programming language including, but not limited to, Java or the like and any conventional procedural programming languages, such as the "C" programming language or similar programming languages.
  • the computer readable program code may be executed on one processor or multiple processors. In the latter scenario, the remote processors may be connected to each other through any type of network (e.g., CAN bus, etc.).
  • the fault circuit 208, model circuit 210, storage circuit 212, or user interface circuit 214 are embodied as hardware units, such as electronic units.
  • the fault circuit 208, model circuit 210, storage circuit 212, and/or user interface circuit 214 may be embodied as one or more circuitry components including, but not limited to, processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, etc.
  • one or more circuits of the computing system 104 may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOCs) circuits, microcontrollers, etc.), telecommunication circuits, hybrid circuits, and any other type of “circuit.”
  • the one or more circuits may include any type of component for accomplishing or facilitating achievement of the operations described herein.
  • a circuit as 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, and so on).
  • the one or more circuits may also include programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
  • the one or more circuits may include one or more memory devices for storing instructions that are executable by the processor(s) of the one or more circuits.
  • the one or more memory devices and processor(s) may have the same definition as provided below with respect to the memory device 204 and processor 206.
  • the one or more circuits may be geographically dispersed throughout separate locations in the computing system 104.
  • the one or more circuits may be embodied in or within a single unit/housing, which is shown as the computing system 104.
  • the computing system 104 includes a processing circuit 202 having at least one processor 206 and at least one memory device 204.
  • the processing circuit 202 may be configured to execute or implant the instructions, commands, and/or control processes described herein with respect to at least the fault circuit 208, model circuit 210, storage circuit 212, and/or user interface circuit 214.
  • the depicted configuration represents the one or more circuits as instructions stored in a machine or computer-readable media. However, as mentioned above, this illustration is not meant to be limiting as the present disclosure contemplates other implementations where the one or more circuits can be configured as a hardware unit. All such combinations and variations are intended to fall within the scope of the present disclosure.
  • the processor 206 may be implemented as one or more processors, one or more application-specific integrated circuits (ASIC), one or more field programmable gate arrays (FPGAs), a digital signal processor (DSP), a group of processing components, or other suitable electronic processing components.
  • the one or more processors may be shared by multiple circuits (e g., the fault circuit 208, model circuit 210, storage circuit 212, or user interface circuit 214 may comprise or otherwise share the same processor which, in some example implementations, may execute instructions stored, or otherwise accessed, via different areas of memory).
  • the one or more processors may be configured to perform or otherwise execute certain operations independent of one or more co-processors.
  • the memory device 204 may store data and/or computer code for facilitating the various processes described herein.
  • the memory device 204 may be communicably coupled to the processor 206 to provide computer code or instructions to the processor 206 for executing at least some of the processes described herein.
  • the memory device 204 may be or include tangible, non-transient volatile memory or non-volatile memory. Accordingly, the memory device 204 may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described herein.
  • the memory device 204 may be referred to as a database, data repository, or storage device of the computing system 104.
  • the memory device 204 is configured to store information received from the vehicle 108, among other vehicles in the fleet.
  • the memory device 204 is configured to store one or more operating conditions including, for instance, fault conditions associated with respective vehicles.
  • the fault condition may include or correspond to a fault code.
  • the fault condition may include or correspond to parameter(s) that does not satisfy a desired acceptable threshold to trigger a certain fault code, operates outside of desired operating ranges, etc.
  • the fault condition may include or correspond to progressive indicator(s) of a potential failure, such as a NOx conversion decreasing progressively, ammonia slip increasing progressively, exhaust flow rate decreasing progressively, etc., for the same operating conditions over a predefined period of time. Additionally or alternatively, if the NOx conversion rate is progressively decreasing below a certain threshold, a fault code may be triggered, indicating an issue within the aftertreatment system 38.
  • the memory device 204 is configured to store one or more parameters or information related to the fault received from respective vehicles.
  • the memory device 204 is configured to store executable instructions for storing fault codes (e.g., predetermined/preconfigured by the administrator, service entity, or manufacturer) and/or triggering fault codes based on monitored parameter(s) and/or condition(s) satisfying a fault condition (e.g., according to a look-up table).
  • the memory device 204 is configured to be accessed by the one or more other circuits of the computing system 104.
  • the memory device 204 includes, corresponds to, or is a part of the database 106.
  • the one or more circuits of the computing system 104 can communicate with each other.
  • the one or more circuits can perform features or operations discussed herein to store information related to the fault (e.g., triggered or about to be triggered) by the vehicle 108.
  • the one or more circuits are configured to operate independently or concurrently to each other.
  • the computing system 104 may include additional or alternative one or more circuits configured to perform the features or operations to manage (e.g., reduce) incoming data from one or more vehicles for fault analysis or diagnosis.
  • the fault circuit 208 is configured or structured to receive an indication of at least one fault or fault condition from the vehicle 108.
  • the indication of the fault includes at least one of a type of fault, a time the fault was triggered, among other information indicating that the fault is triggered by the vehicle 108.
  • the indication of the fault includes a prediction of a time instance when the fault may trigger.
  • the prediction is performed based on certain predefined operating parameters that are obtained periodically or aperiodically, such as NOx conversion amounts over a predefined amount of time, etc.
  • the prediction may be performed based on data correlated to a look-up table, models, etc.
  • the fault circuit 208 receives the prediction of the fault from the vehicle 108 indicating the time instance when the fault triggers.
  • the fault circuit 208 is configured to determine whether the fault triggered around the predicted time instance.
  • the fault circuit 208 is configured to inform the other circuits (e.g., model circuit 210, storage circuit 212, and/or interface circuit 214) whether the fault triggered at the predicted time instance, for example.
  • the fault circuit 208 is configured to inform the other circuits when the fault is predicted to occur, such that a command can be sent to initiate monitoring the parameters related to the fault.
  • the fault circuit 208 may not inform the other circuits if a fault is not predicted to occur within a predetermined time duration.
  • the model circuit 210 is configured or structured to manage models associated with different types of faults for the vehicle 108.
  • Managing the model can include at least one of creating a new model, maintaining models within the memory 204 of the computing system 104, updating existing model(s), and/or retrieving model(s) from the database 106.
  • the model circuit 210 can perform features or functionalities similar to or including those of the database 106.
  • Each model may be associated with a type of fault. Based on the type of fault, the respective model indicates or provides a list or set of one or more parameters associated with the type of fault. The parameters correspond to different types of information (e.g., temperature, pressure, power consumption, etc.) from the vehicle 108 to be used for analyzing or diagnosing the specific type of fault.
  • the model circuit 210 (or the database 106) is configured to receive inputs from the administrator to generate a new model and/or update an existing model.
  • the model may refer to or be described as a set of algorithm(s), function(s), look-up table(s), executable script(s) or code(s), computing process(es), etc., configured to receive and process data to produce/generate an output data.
  • the inputs include an indication of a fault and its associated parameter(s) for analyzing or diagnosing the fault.
  • the model circuit 210 Based on the inputs, the model circuit 210 generates the model which can be selected using the indication of the fault as a lookup key or search index.
  • the model circuit 210 updates the model with the additional or alternative parameter(s).
  • the model circuit 210 (or the database 106) is configured to select at least one at least one model based on the indication of the fault (e.g., the type of fault). In response to the selection, the model circuit 210 obtains, identifies, or determine a set of one or more parameters associated with the fault using the model.
  • the model circuit 210 is configured to provide the list of parameter(s) to the vehicle 108 (e.g., controller 28) for data transmission.
  • the model(s) may be stored in the database 106 remote from the computing system 104. In this case, the model circuit 210 is in communication with the database 106 to request or retrieve at least one model using the indication of the fault as a lookup key, search index, or identifier.
  • the storage circuit 212 is configured or structured to manage the memory device 204 or data storage on the computing system 104.
  • the storage circuit 212 is configured to store data received from the vehicle 108.
  • the storage circuit 212 is configured to remove data from the memory device 204 in response to a command received from the administrator.
  • the storage circuit 212 is configured to distribute or allocate resources for storing data of vehicles within the fleet. In some cases, the storage circuit 212 is configured to remove data of vehicles that are irrelevant to the fault (e.g., type of fault). In some other cases, the storage circuit 212 is configured to remove data subsequent to an expiration of a timer (e.g., 5 days, 10 days, 30 days, etc.). For instance, the storage circuit 212 is configured to store the indication of at least one fault communicated by the vehicle 108 to the computing system 104. The storage circuit 212 is configured to store one or more parameters communicated from the vehicle 108.
  • the storage circuit 212 is configured to receive a request to access data of one or more vehicles for fault analysis.
  • the storage circuit 212 may receive the request from at least one other circuit of the computing system 104.
  • the storage circuit 212 may receive a request from the processing circuit 202 to process the parameter(s) or information of the vehicle 108 related to the fault.
  • the storage circuit 212 may receive the request from a remote computing device/system configured to process information of the vehicle 108.
  • the user interface circuit 214 is configured or structured to generate, modify, or provide a graphical user interface (GUI) to at least one of the operator VO 30, the computing system 104, or other client devices of the operator, the service technician, or the administrator of the computing system 104.
  • GUI graphical user interface
  • the user interface circuit 214 can generate a fault analysis report for the operator based on the one or more parameters related to the fault.
  • the user interface circuit 214 is configured to receive a generated report from the remote computing device in response to processing the fault-related data.
  • the computing system 104 is in communication with other remote devices, such as service center devices to relay vehicle information or fault analysis report to facilitate services using the communications interface 216 via the network 102.
  • the computing system 104 (or one or more circuits of the computing system 104) may provide information to at least the vehicle 108 or one or more client devices using the communications interface 216.
  • the computing system 104 is configured to receive raw data or processed data from various components, devices, or systems within the network 102, and store the data in the local memory (e.g., memory device 204) for access by at least one other device within the network 102.
  • the computing system 104 minimizes network traffic (e.g., optimizes data transmission cost) and resource consumption in the local memory (e.g., optimizes storage cost) because of the reduction of parameters received from the vehicle 108, and improves the efficiency of data processing (e.g., optimizes computing cost by reducing data irrelevant to specific fault analysis based on the model).
  • network traffic e.g., optimizes data transmission cost
  • resource consumption in the local memory e.g., optimizes storage cost
  • FIG. 3 a flow diagram of a method 300 for a reactive data logging process is shown, according to an example embodiment.
  • the method 300 may be performed by the components of FIGS. 1-2, such that reference may be made to them to aid explanation of the method 300.
  • the method 300 includes operations 302- 328, among other processes (or other operations) to manage the data storage of vehicles for fault analysis, diagnosis, and mitigation.
  • certain processes can be omitted, performed before, after, or concurrently with one another, and/or other modifications.
  • the vehicle 108 determines or identifies that a fault is occurring or has occurred at a time instance. In some cases, the controller 28 determines an occurrence of a fault in response to a triggering of a fault indicator, such as a fault code. Tf the fault is a fault condition, such as operating parameters not falling within acceptable operating ranges, the controller 28 determines a potential occurrence of a fault based on certain parameter(s) operating outside a desired range or do not satisfy a respective predefined threshold.
  • the vehicle 108 may include various fault sensors, each associated with a respective type of fault. In some cases, the controller 28 determines an occurrence of a fault based on information from one or more components of the vehicle 108.
  • the vehicle 108 (e.g., controller 28 directly or indirectly via the telematics unit 34) communicates or transmits the indication of the fault to the computing system 104 in response to identifying the occurrence of the fault.
  • the vehicle 108 communicates the indication of the fault (e.g., fault condition) over-the-air using the telematics channel (e.g., telematics unit 34).
  • the indication of the fault can include or indicate the fault condition including at least one of the fault code (e.g., associated with a particular error of a system or component), data related to or leading to potentially triggering a fault during operation, and/or other information related to the operation of the vehicle 108 that may be indicative of undesired operation of the vehicle and, particularly, one or more components or systems thereof.
  • the fault code e.g., associated with a particular error of a system or component
  • data related to or leading to potentially triggering a fault during operation e.g., data related to or leading to potentially triggering a fault during operation
  • other information related to the operation of the vehicle 108 e.g., associated with a particular error of a system or component
  • the computing system 104 (e.g., storage circuit 212) is configured to store the indication of the fault in the memory device 204.
  • the computing system 104 (e.g., storage circuit 212) is in communication with a remote database managed by the administrator of the computing system 104 (e.g., database 106 or other storage devices).
  • the computing system 104 may store the indication of the fault, among other information from the vehicle 108 to the remote database.
  • the remote database may be an extension (e.g., storage expansion device) of the computing system 104.
  • the computing system 104 (e.g., model circuit 210) is configured to find or search for at least one model corresponding to or associated with the received at least one fault associated with the vehicle 108.
  • the computing system 104 communicates with the database 106 to obtain the model or a list of parameters to initiate electronic data logging by the vehicle 108.
  • the computing system 104 is configured to trigger a model -based system engineering (MBSE) framework to obtain a model or a list of one or more parameters.
  • MBSE model -based system engineering
  • the computing system 104 may perform or include features or functionalities of the database 106.
  • the database 106 receives the request for a model from the computing system 104.
  • the database 106 is configured to manage various models corresponding to respective faults (e.g., fault codes).
  • the database 106 is configured to create and store models for each fault.
  • the database 106 uses the MBSE to integrate failure modes and effects analysis (FMEA) information and fault tree analysis (FTA) information for model generation and/or training.
  • FMEA failure modes and effects analysis
  • FTA fault tree analysis
  • the meta-structure informs how the FMEA information is connected to the rest of the system and systematically linked to the other faults or parameters that need or may need to be monitored.
  • the systems and methods described herein can query and manage the FMEA and FTA analyses with the MBSE models.
  • the remote computing system or at least one other remote computing device may be configured to initiate a model generation process.
  • the database 106 can receive sample data input by an operator or an administrator.
  • the sample data includes available or monitored parameters from vehicles and the fault conditions associated with the vehicles, respectively.
  • the sample data includes data regarding the parameters monitored for a predefined time duration before and after the occurrence of the fault, such as parameters 5 minutes, 10 minutes, 20 minutes, etc., before and/or after the time instance when the fault is triggered.
  • the database 106 feeds the sample data to one or more models (e.g., FMEA and/or FTA models 330).
  • the database 106 feeds each model with a portion of the sample data having the corresponding fault type/code.
  • each model is configured to receive the sample data and extract a subset of the sample data based on the corresponding fault type.
  • Each model is configured to perform FMEA and/or FTA on the sample data. By performing the FMEA and/or FTA, each model determines the parameter(s) that is/are affected or have a correlation with the fault condition or triggered fault code.
  • the model can list one or more parameters for analysis given the indication of the fault.
  • the database 106 can create, store, and/or update the models for respective faults.
  • the database 106 is configured to remove outdated models in response to a timer expiration (e.g., 1 week, 1 month, 6 months, 1 year, etc.).
  • the execution of the FMEA and/or FTA techniques can be performed on one or more remote computing devices different from the database 106 that are configured to identify the parameters of one or more components of vehicles correlated to certain types of faults.
  • the database 106 is configured to store the models generated by the remote computing device(s).
  • the database 106 can be a part of the computing system 104.
  • the computing system 104 e.g., model circuit 210) is configured to create or update the models and store (e.g., by the storage circuit 212) the created models similar to the features of the database 106, for example.
  • the controller 28 or the computing system 104 is configured to use the model(s) to perform traceability studies on the systems, subsystems, and requirements. Further, the models can be used to list the failure/fault modes/types/codes and estimate the effects of the fault modes.
  • certain other parameters related to the listed parameters may be identified and included in the list of input parameters (e.g., set up for logging). These parameters may be indirectly related to the fault condition.
  • indirectly related parameters can include fuel injection timing, fuel injection amount, reductant injection rate, reductant injection amount, pressure information, etc.
  • the list can include the parameters in direct relation to the fault condition and the parameters related therewith, thereby increasing the types of parameters included in the list.
  • these additional parameters may be consider during relatively high network connectivity, such as relative high network bandwidth, low network traffic, among other network conditions.
  • only directly related parameters are considered for logging.
  • the database 106 shares the input parameter(s).
  • the input parameter or parameters may be a list or a set of parameter(s) associated with the fault corresponding to the retrieved model.
  • the computing system 104 e.g., model circuit 210) receives the list of parameter(s) from the database 106.
  • the computing system 104 e.g., model circuit 210) sets up or configures the list of parameter(s) for logging (e.g., for the vehicle 108 to log) in response to receiving the parameter(s) from the database 106.
  • the computing system 104 shares or communicates the list of parameter(s) with the vehicle 108 (e.g., controller 28).
  • the vehicle 108 e.g., controller 28
  • the controller 28 starts continuously logging electronic data associated with only predefined parameter(s) and/or related parameters thereof according to a predefined list of parameter(s) and/or related data points (e.g., fuel injection amount, fuel injection rate, NOx, or mass air flow, etc.).
  • the controller 28 is configured to monitor and track or log the data at a predefined rate, such as 1 Hz, 10 Hz, etc.
  • the controller 28 is configured to log the identified parameter data for a predefined duration after the occurrence of the fault or after the command is provided to the vehicle, such as 1 minute, 5 minutes, 10 minutes, etc.
  • the controller 28 is configured to continuously log data and maintain a predefined amount/size of the data. As the controller 28 continues to log new data, the controller 28 can replace the oldest data with the incoming data and, in some embodiments, discard the oldest data to provide available memory space for the incoming data. In this case, the controller 28 is configured to log one or more parameters before and after the occurrence of the fault.
  • logging data may refer to the tracking and storing of parameters (e.g., parameter values) of one or more components and/or systems of the vehicle 108.
  • the logged parameters may be defined by the list of parameters.
  • the vehicle 108 (e.g., controller 28) is configured to send the data to the computing system 104 via an over-the-air channel (e.g., telematics channel via telematics unit 34).
  • the data includes the one or more parameters in the list of parameter(s) set by the computing system 104 (e.g., model circuit 210).
  • the controller 28 can send the data at predefined time intervals, such as at 1 minute, 5 minutes, or 10 minutes interval.
  • the controller 28 may send the data in real-time responsive to receiving the data (e.g., one or more parameters) from the component s) of the vehicle 108.
  • the vehicle 108 is configured to transmit data intermittently in response to satisfying a threshold for a data size, reaching a threshold number of parameters, or filling a transmission queue.
  • the computing system 104 receives the data from the vehicle 108 and stores the data (e.g., sequentially, such as time-series data) inside the local database or memory device 204.
  • the memory device 204 includes allocated resources or space for storing data or parameters related to the vehicle 108.
  • the memory device 204 includes allocated spaces for storing data from other vehicles.
  • the computing system 104 continuously, periodically, or intermittently stores the data based on the data transmission scheme of the vehicle 108 (e.g., in response to receiving the data from the vehicle 108).
  • the vehicle 108 stops logging the data or parameters after the predefined period, and namely a time duration (e g., buffer) after the time instance when the fault occurred (e.g., labeled as “T”).
  • the fault can have timestamps for determining when the fault occurred associated therewith.
  • the controller 28 stops logging the parameters in response to receiving a command (e g., from the operator I/O 30), when a predefined amount of datasets or data size are received, among other metrics for indicating to stop logging the parameters.
  • the controller 28 can continue logging data for the vehicle 108 without sending additional data to the computing system 104 after the buffer or the predefined time duration ends.
  • the controller 28 can provide the indication of the predefined time duration or buffer to the computing system 104, such that the computing system 104 can determine the end of the log or data sharing/communication.
  • the computing system 104 determines that vehicle 108 stops logging or transmission of data.
  • the computing system 104 may receive an indication from the vehicle 108 that data logging has ended. In some cases, the computing system 104 determines that the vehicle 108 stops logging data based on the predefined buffer.
  • the computing system 104 processes the data (e.g., stored in the memory device 204) for remote analysis or diagnosis of the fault. [0079] In some arrangements, the computing system 104 processes the data responsive to receiving (e.g., additional) data from the vehicle 108. In certain arrangements, the computing system 104 processes the data at a predefined time interval. This time interval can be similar to or different from the predefined interval of sending data by the vehicle 108. In certain other arrangements, the computing system 104 processes the data after the vehicle stops logging the data or parameter(s).
  • FIG. 4 a flow diagram of a method 400 for a predictive data logging is shown, according to an example embodiment.
  • the method 400 may be performed by the components of FIGS. 1-2, such that reference may be made to them to aid explanation of the method 400.
  • the method 400 includes operations/processes 402-428, among other processes (or other operations) to manage the data storage of vehicles for fault analysis and diagnosis.
  • Certain operations of processes 402-428 can be performed in similar manners as processes 302-328 as described in conjunction with FIG. 3.
  • certain processes can be performed before or after one another.
  • the vehicle 108 e.g., controller 28
  • the computing system 104 predicts that a fault is occurring (e.g., about to occur) at a subsequent time instance, such as in 5 minutes, 10 minutes, 20 minutes, etc., based on a prognostic technique.
  • the controller 28 can use the prognostic technique to analyze the operation data of one or more components of the vehicle 108 to determine whether a fault is about to occur. Based on the prognostics, the controller 28 determines a time instance when the fault is going to occur and the particular fault (e.g., fault code or failure mode) that will be triggered.
  • a command can be provided to the controller 28 to start logging parameters related to the predicted fault.
  • a command may be provided to log only the parameter used for predicting the occurrence of the fault condition (e.g., only logging NOx conversion efficiency to monitor the system), for example.
  • other parameters such as temperatures, flow rates, regeneration events, etc., may be logged.
  • the vehicle 108 e.g., controller 28 using the telematics unit 34
  • communicates to an indication of the fault e.g., fault code
  • processes 404-420 can be performed in similar manners as processes 304-320 as described in conjunction with FIG. 3, for example.
  • the computing system 104 receives and stores the indication of the fault from the vehicle 108 in the memory device 204.
  • the computing system 104 (e.g., model circuit 210) transmits a request to the database 106 for at least one model corresponding to the fault.
  • the computing system 104 includes or is part of the database 106 configured to create and/or store the models (e.g., operation 412).
  • the database 106 receives the request from the computing system 104.
  • the database 106 (or the computing system 104) is configured to create and store a model for each fault (e.g., operation 412).
  • the model may be referred to as FMEA and/or FTA model 430 for a respective type of fault.
  • the database 106 (or the computing system 104) can select at least one model based on the indication of the fault (e.g., fault code).
  • the model indicates one or more input parameters associated with the fault.
  • the database 106 shares the input parameter(s) (e.g., a list or a set of parameter(s)) to the computing system 104.
  • the computing system 104 e.g., model circuit 210) receives the list of parameters from the database 106.
  • the computing system 104 sets up the param eter(s) for logging.
  • the computing system 104 transmits or shares the list of parameters with the vehicle 108 for (e.g., continuous or periodic) data/parameter logging.
  • the vehicle 108 e.g., controller 28
  • the vehicle 108 determines whether the fault occurred within a predefined time duration (e.g., 1 minute, 2 minutes, 3 minutes, etc.) of the predicted time of a fault occurrence.
  • the time duration may be configured by the administrator or may be based on the estimated prediction accuracy. For example, for a prediction accuracy of 90%, the controller 28 determines that a fault may occur within 5 minutes of the initially predicted time instance of the fault. In another example, for a prediction accuracy of 99%, the controller 28 determines that a fault may occur within 1 minute of the initially predicted time instance of the fault.
  • the controller 28 transmits/sends data to the computing system 104 using over-the-air channel (e.g., telematics unit 34).
  • the controller 28 can send the data continuously, periodically, or intermittently.
  • the controller 28 is configured to log data before and/or after the time instance of the occurrence of the fault.
  • the controller 28 determines that the fault has not occurred within the predefined time duration of the predicted time instance. In this case, the controller 28 determines that the prediction is a fault positive. The controller 28 may perform a second prognostics technique to determine if the fault is going to occur in another time instance. In some cases, the controller 28 may stop the logging operation and discard the data/parameters.
  • the controller 28 may have sent data to the computing system 104 while anticipating the occurrence of the fault. In this case, if the fault did not occur within the predefined time duration, the controller 28 may indicate to the computing system 104 that the predicted fault did not occur. Accordingly, the computing system 104 can discard the data received from the vehicle 108 associated with the fault that did not occur. As discussed herein, processes 424-428 can be performed similarly to processes 324-328 of FIG. 3.
  • the computing system 104 (e.g., storage circuit 212) stores the data inside the local database or the memory device 204 in response to receiving the data from the vehicle 108.
  • the computing system 104 may store the data after the occurrence or triggering of the fault.
  • the vehicle 108 e.g., controller 28
  • the computing system 104 (e.g., processing circuit 202) processes the data for remote fault analysis or diagnosis.
  • the computing system 104 is configured to process the data in response to at least one of receipt of the data from the vehicle 108, storing the data in the memory device 204, the vehicle 108 stops logging the parameters, or the expiration of the buffer (e.g., after the predefined time duration).
  • FIG. 5 a flow diagram of a method 500 logging data using MBSE for fault analysis is shown, according to an example embodiment.
  • the method 500 may be performed by the components of FIGS. 1-2, such that reference may be made to them to aid explanation of the method 500.
  • certain processes can be performed before or after one another.
  • the computing system 104 communicates with the vehicle 108 (e.g., controller 28) to receive an indication of a fault from the vehicle 108.
  • the controller 28 is configured to monitor data or parameters associated with the components of the vehicle 108.
  • the indication of the fault can include at least one of a fault condition, which can include data indicative of components or systems not operating as intended and/or a fault code indicative of, a fault code (e.g., predefined code) indicative of an error or failure condition of a system or component of the vehicle 108, time stamp associated with the data or triggered fault code, a time duration the controller 28 is configured to log data after the occurrence of the fault, etc.
  • a fault condition can include data indicative of components or systems not operating as intended and/or a fault code indicative of, a fault code (e.g., predefined code) indicative of an error or failure condition of a system or component of the vehicle 108, time stamp associated with the data or triggered fault code, a time duration the controller 28 is configured to log data after the occurrence
  • the computing system 104 receives the indication of the fault including a predicted time instance when the fault will occur or an occurrence of a triggered fault code.
  • the controller 28 is configured to use a suitable predictive technique (e.g., provided continuously monitored parameters as inputs using the predictive technique) to determine the predicted time instance of the fault.
  • the computing system 104 (e.g., model circuit 210) or the database 106 selects a set of parameters related to the fault using a model corresponding to the fault.
  • the set of parameters includes at least one parameter being or configured to be monitored by the vehicle 108.
  • the computing system 104 or the database 106 is configured to select the model based on the indication of the fault received from the vehicle 108.
  • the computing system 104 selects the model from a list of models configured for respective faults.
  • Each model is trained with a collection of data (e.g., sample data) from various vehicles that triggered or experienced the respective faults. Based on the data, each model is configured to identify a list or a set of parameter(s) (e.g., input parameters) affected by the fault.
  • the computing system 104 identifies and selects the list of one or more parameters using the model based on the indication of the fault.
  • the computing system 104 e.g., model circuit 210) or the database 106 identifies at least one suitable model based on the indication of the fault (e.g., fault code or the type of fault).
  • the computing system 104 inputs the indication of the fault into the model, such as the type of fault that occurred or is about to occur in the vehicle 108.
  • the model can provide the list of parameters in response to receiving the indication of the fault (e.g., type of fault).
  • the model can select the set of parameters related to the fault from a list of faults. Accordingly, the model can provide the set of parameters to the computing system 104. Each fault in the list of faults is associated with a respective set of parameters, for example.
  • the computing system 104 (e.g., model circuit 210) transmits the list/set of parameters to the vehicle 108 for monitoring or logging. In some cases, the computing system 104 transmits the set of parameters in response to receiving the list of parameters from the database 106 executing the model. In some other cases, the model circuit 210 is configured to execute the model. In this case, the computing system 104 is configured to transmit the set of parameters in response to determining the list of parameters identified using the model. Hence, the model may be executed by the computing system 104 or by a remote device (e.g., database 106) remote from the computing system 104 depending on the configuration.
  • a remote device e.g., database 106
  • the vehicle 108 in response to receiving the list of parameter(s) from the computing system 104, the vehicle 108 (e.g., controller 28) starts logging data related to the one or more parameters in the list of parameter(s).
  • the controller 28 can log the data for a predefined time duration (e.g., 5 minutes, 10 minutes, etc.) after the time instance of the fault occurrence.
  • the controller 28 may log the data before and/or after the occurrence of the fault, such as 5 minutes, 10 minutes, etc., before and/or after the fault.
  • the computing system 104 e.g., fault circuit 208 or the vehicle
  • the computing system 104 determines whether the fault is triggered.
  • the computing system 104 can reactively or predictively receive an indication of the fault from the vehicle 108 according the configuration of the controller 28.
  • the computing system 104 receives the indication of the fault in response to at least one component of the vehicle 108 triggering the fault.
  • the method 500 may skip operation 508 and proceeds to operation 512.
  • the predictive approach if the fault was not triggered at or around the predicted time instance (e.g., within a predefined time limit, such as 10 minutes, 1 hour, 24 hours, etc.), the method 500 proceeds to operation 510. Otherwise, the method 500 proceeds to operation 512.
  • the vehicle 108 is configured to determine whether the fault has been triggered, such as in the predictive approach, without the assistance of the computing system 104.
  • the computing system 104 determines that the fault did not occur within the predicted time period or around the time instance indicated by the vehicle 108 (e g., controller 28). In response to determining that the fault did not occur around such time instance (e.g., vehicle 108 does not provide another indication that the fault has been triggered or occurred), the computing system 104 may command the vehicle 108 (e.g., controller 28) to stop logging data and/or discard the data that recorded in anticipation of the occurrence of the fault if logging has started.
  • the vehicle 108 e.g., controller 28
  • the controller 28 determines whether the fault has occurred around the predicted time instance. In this case, in response to the detection of the absence of the fault around such time instance, the controller 28 discards the data without transmitting the data to the computing system 104. In this case, the controller 28 may perform another prediction to identify the time instance of the fault occurrence(s) or fall back to the reactive approach.
  • the computing system 104 receives data regarding the set of parameters monitored by the vehicle 108 for the predefined timeframe or time duration.
  • the computing system 104 e.g., storage circuit 212 stores the data in the memory device 204 or the local database of the computing system 104 for diagnosing the fault.
  • the computing system 104 can process the data stored in the memory at a subsequent time period of the fault.
  • the computing system 104 e.g., user interface circuit 214) can transmit a summary or a report of the fault analyzed by the computing system 104 or a remote processing device to the vehicle 108 (e.g., operator I/O 30).
  • circuits may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components.
  • VLSI very-large-scale integration
  • a circuit may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
  • circuits may also be implemented in machine-readable medium for execution by various types of processors, such as processor 206 of FIG. 2.
  • An identified circuit of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified circuit need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the circuit and achieve the stated purpose for the circuit.
  • a circuit of computer readable program code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices.
  • operational data may be identified and illustrated herein within circuits, and may be embodied in any suitable form and organized within any suitable type of data structure.
  • the operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.
  • the computer readable medium (also referred to herein as machine-readable media or machine-readable content) may be a tangible computer readable storage medium storing the computer readable program code.
  • the computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.
  • examples of the computer readable storage medium may include but are not limited to a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), an optical storage device, a magnetic storage device, a holographic storage medium, a micromechanical storage device, or any suitable combination of the foregoing.
  • a computer readable storage medium may be any tangible medium that can contain, and/or store computer readable program code for use by and/or in connection with an instruction execution system, apparatus, or device.
  • the computer readable medium may also be a computer readable signal medium.
  • a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electrical, electro-magnetic, magnetic, optical, or any suitable combination thereof.
  • a computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport computer readable program code for use by or in connection with an instruction execution system, apparatus, or device.
  • computer readable program code embodied on a computer readable signal medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, Radio Frequency (RF), or the like, or any suitable combination of the foregoing.
  • the computer readable medium may comprise a combination of one or more computer readable storage mediums and one or more computer readable signal mediums.
  • computer readable program code may be both propagated as an electromagnetic signal through a fiber optic cable for execution by a processor and stored on RAM storage device for execution by the processor.
  • Computer readable program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages.
  • the computer readable program code may execute entirely on a local computer (such as via the computing system 104 of FIGS. 1 and 2), partly on the local computer, as a stand-alone computer-readable package, partly on the local computer and partly on a remote computer or entirely on the remote computer or server.
  • the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
  • LAN local area network
  • WAN wide area network
  • Internet Service Provider an Internet Service Provider
  • the program code may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the schematic flowchart diagrams and/or schematic block diagrams block or blocks.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Automation & Control Theory (AREA)
  • Mechanical Engineering (AREA)
  • Software Systems (AREA)
  • Medical Informatics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Evolutionary Computation (AREA)
  • Data Mining & Analysis (AREA)
  • Human Computer Interaction (AREA)
  • Transportation (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Artificial Intelligence (AREA)
  • Chemical & Material Sciences (AREA)
  • Combustion & Propulsion (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

L'invention concerne un système, un procédé et un appareil de journalisation de données à l'aide d'une ingénierie de systèmes basée sur un modèle. Un système comprend un circuit de traitement présentant un ou plusieurs dispositifs de mémoire couplés à un ou plusieurs processeurs. Lesdits un ou plusieurs dispositifs de mémoire sont conçus pour stocker des instructions qui, lorsqu'elles sont exécutées par lesdits un ou plusieurs processeurs, amènent le circuit de traitement à : recevoir une indication d'une défaillance d'un véhicule ; sélectionner, à l'aide d'un modèle correspondant à la défaillance, un ensemble de paramètres associés à la défaillance ; transmettre, au véhicule, l'ensemble sélectionné de paramètres pour la surveillance ; recevoir, en provenance du véhicule, des données concernant l'ensemble de paramètres surveillés pendant une période prédéfinie ; et à stocker les données dans lesdits un ou plusieurs dispositifs de mémoire pour diagnostiquer la défaillance.
PCT/US2023/082108 2022-12-02 2023-12-01 Systèmes et procédés de journalisation de données à l'aide d'ingénierie de systèmes basée sur un modèle pour une analyse de défaillance Ceased WO2024119094A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202263429737P 2022-12-02 2022-12-02
US63/429,737 2022-12-02

Publications (1)

Publication Number Publication Date
WO2024119094A1 true WO2024119094A1 (fr) 2024-06-06

Family

ID=91325040

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/082108 Ceased WO2024119094A1 (fr) 2022-12-02 2023-12-01 Systèmes et procédés de journalisation de données à l'aide d'ingénierie de systèmes basée sur un modèle pour une analyse de défaillance

Country Status (1)

Country Link
WO (1) WO2024119094A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118332936A (zh) * 2024-06-12 2024-07-12 中国航空工业集团公司金城南京机电液压工程研究中心 一种基于智能故障树的故障自动定位方法和装置
CN119135507A (zh) * 2024-08-15 2024-12-13 东南大学 一种基于fta和fmea的通信系统故障分析方法
CN119575012A (zh) * 2024-11-18 2025-03-07 广东电网有限责任公司 电缆故障检测方法、装置、电子设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200122656A1 (en) * 2018-10-18 2020-04-23 Northrop Grumman Systems Corporation Parametric data modeling for model based reasoners
US20210092018A1 (en) * 2019-09-20 2021-03-25 Sonatus, Inc. System, method, and apparatus to support mixed network communications on a vehicle

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200122656A1 (en) * 2018-10-18 2020-04-23 Northrop Grumman Systems Corporation Parametric data modeling for model based reasoners
US20210092018A1 (en) * 2019-09-20 2021-03-25 Sonatus, Inc. System, method, and apparatus to support mixed network communications on a vehicle

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118332936A (zh) * 2024-06-12 2024-07-12 中国航空工业集团公司金城南京机电液压工程研究中心 一种基于智能故障树的故障自动定位方法和装置
CN119135507A (zh) * 2024-08-15 2024-12-13 东南大学 一种基于fta和fmea的通信系统故障分析方法
CN119135507B (zh) * 2024-08-15 2025-11-18 东南大学 一种基于fta和fmea的通信系统故障分析方法
CN119575012A (zh) * 2024-11-18 2025-03-07 广东电网有限责任公司 电缆故障检测方法、装置、电子设备及存储介质

Similar Documents

Publication Publication Date Title
WO2024119094A1 (fr) Systèmes et procédés de journalisation de données à l'aide d'ingénierie de systèmes basée sur un modèle pour une analyse de défaillance
CN105736101B (zh) 用于排气后处理系统的NOx传感器诊断的装置、方法和系统
EP2946084B1 (fr) Procédé, système et appareil pour diagnostiquer un composant de post-traitement d'échappement
US11719151B2 (en) Systems and methods for diagnosis of NOx storage catalyst
CN109424406B (zh) 集成式尾气无线监控装置
US12473853B2 (en) Systems and methods for diagnosing component failure
US20240337209A1 (en) SYSTEMS AND METHODS FOR DIAGNOSING NOx SENSOR BASED ON AMMONIA SLIP
CN111929079A (zh) 车辆的年检预审方法及车辆
CN114517727A (zh) 数据采集装置、分析装置、分析方法及计算机程序产品
US12448912B2 (en) Systems and methods for multi-factor diagnosis of exhaust aftertreatment system components
CN118591684A (zh) 用于基于后处理系统的退化来预测和控制尾管NOx转化和氨逃逸的系统和方法
CN114555921B (zh) 用于scr相关控制和诊断的系统和方法
US20250035018A1 (en) Real-time system and method for determining remaining useful oil life in vehicles
CN116324660A (zh) 使用预测分析管理排气后处理系统的系统和方法
WO2025147549A1 (fr) Systèmes et procédés de détection de durée de vie utile restante (rul) et commandes basées sur ceux-ci
EP4658890A1 (fr) Systèmes et procédés de régulation de température d'un élément de catalyseur à l'aide d'un apprentissage automatique
EP4215726B1 (fr) Dispositif et procédé en connexion avec un procédé de préchauffage d'un système de post-traitement
US20230186688A1 (en) Systems and methods for generating and providing fluid analysis reports
US12291220B2 (en) Systems and methods for collection and analysis of vehicular data
KR101651930B1 (ko) 배기가스 후처리 시스템의 원격 모니터링 장치
WO2025072877A1 (fr) Systèmes et procédés pour optimiser le dimensionnement d'un catalyseur et composition de revêtement catalytique
CN117869045A (zh) 一种基于车联网的dpf再生数据监控分析方法及系统
KR20240096004A (ko) 차량 데이터 전송 방법, 장치, 시스템 및 컴퓨터 프로그램

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23899004

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 23899004

Country of ref document: EP

Kind code of ref document: A1