WO2013156791A1 - Machine analytic system and components thereof - Google Patents

Machine analytic system and components thereof Download PDF

Info

Publication number
WO2013156791A1
WO2013156791A1 PCT/GB2013/051001 GB2013051001W WO2013156791A1 WO 2013156791 A1 WO2013156791 A1 WO 2013156791A1 GB 2013051001 W GB2013051001 W GB 2013051001W WO 2013156791 A1 WO2013156791 A1 WO 2013156791A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
data
fault
raw data
signature
Prior art date
Application number
PCT/GB2013/051001
Other languages
French (fr)
Inventor
Ken Scott
Original Assignee
Project Vanguard Limited
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 Project Vanguard Limited filed Critical Project Vanguard Limited
Publication of WO2013156791A1 publication Critical patent/WO2013156791A1/en

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C3/00Registering or indicating the condition or the working of machines or other apparatus, other than vehicles
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/008Registering or indicating the working of vehicles communicating information to a remotely located station
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/08Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0808Diagnosing performance data
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/08Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0816Indicating performance data, e.g. occurrence of a malfunction
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/08Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841Registering performance data

Definitions

  • This invention concerns a system for analysing the operation of a machine.
  • the invention has particular, but not exclusive, relevance to the diagnosis or prognosis of a fault in a vehicle.
  • an analytic system in accordance with the invention is to the management of a fleet of vehicles by a fleet operator.
  • the fleet operator may be a courier company operating a fleet of vans.
  • the fleet operator may be a taxi company operating a fleet of taxis. It is known to supply information from the fleet of vehicles to the fleet operator to improve the utilisation of the fleet of vehicles, and over recent years the nature of the information provided to the fleet operator has increased.
  • a GPS device was fitted to each vehicle in the fleet to allow the movement of the vehicles to be monitored. Subsequently, the location information provided by the GPS devices was integrated into a scheduling service to improve scheduling of the use of the fleet of vehicles. More recently, an interface to the vehicle diagnostic network was added to enable information about vehicle and driver behaviour to be gathered while the vehicle is in use, providing data relating to fuel consumption and carbon emissions of the vehicle.
  • fault codes produced by the on-board diagnostic network (OBD) in a vehicle can identify components of the vehicle which are not functioning properly, the cause of the fault is not provided and as such the necessary action to correct the fault can be difficult to ascertain.
  • fault codes are only produced after a fault has occurred, by which time the expense in rectifying the fault may be significant. The present invention addresses these problems.
  • a machine analytic system which processes data from one or more machines to identify events satisfying predetermined event conditions indicative of faulty operation, and for each identified event generates an event signature using data associated with the event.
  • the event signatures are then analysed to generate data identifying a prediction of the cause of a fault.
  • the generated fault prediction data may be output to a machine operator to take appropriate action.
  • the data from one or more machines includes parametric data and at least one of the event conditions may relate to a plurality of parameter readings.
  • an event condition may relate to the variation of the readings for a particular parameter over time
  • another event condition may relate to readings for different parameters at the same time
  • yet another event condition may relate to parameter readings corresponding both to the variation of one particular parameter over time and the parameter values for a plurality of parameters at the same time.
  • each possible event signature is mapped to corresponding fault prediction data in a fault prediction database.
  • fault correction data indicating successful remedial action taken for an event is received by the machine analytic system and the fault correction data for the event signature corresponding to the event is updated to take account of the received fault correction data.
  • Figure 1 schematically shows the main components of a machine analytic system according to the invention
  • Figure 2 schematically shows the main components of an analytic server forming part of the machine analytic system illustrated in Figure 1;
  • Figure 3 schematically shows client data stored in a client database illustrated in Figure 2;
  • Figure 4 schematically illustrates the processing of raw data from a machine by the analytic server of Figure 2;
  • Figure 5 illustrates the variation of a parameter value over time
  • Figure 6 illustrates a plurality of parameter values at the same time instant
  • FIG. 7 schematically shows the processing of fault correction data by the analytic server of Figure 2.
  • an analytic service operator operates an analytic server 1 which performs vehicle analysis services for a plurality of vehicle operators.
  • Each of the vehicle operators has a vehicle operator server 3 (only one of which is shown in Figure 1 for ease of illustration) and operates a fleet of vehicles 5 (only a single vehicle 5 being shown in Figure 1 for ease of illustration).
  • a back-up server 7 is also provided for backing up data stored in the analytic server 1 in case of damage to the analytic server 1.
  • the vehicle 5 includes a driver communication device 9 which is wirelessly connected, either directly or via a wireless communication network (for example a public land mobile network (PLMN)), with the vehicle operator server 3 to allow the vehicle operator to communicate with the driver of the vehicle 5.
  • PLMN public land mobile network
  • the vehicles 5 are serviced in vehicle maintenance workshops, with each vehicle maintenance workshop having a vehicle maintenance workshop server 11 (only one of which is shown in Figure 1 for ease of illustration).
  • the analytic server 1, the back-up server 7, the vehicle operator servers 3 and the vehicle maintenance workshop servers 11 are all connected to each other via the Internet 13.
  • Dedicated connections may be provided in addition to, or instead of, the Internet connections between (i) the analytic server 1 and the back-up server 7, (ii) the analytic server 1 and one or more of the vehicle operator servers 3, and (iii) each vehicle operator server 3 and one or more vehicle maintenance workshop servers 11.
  • raw data from the vehicle 5 is communicated to the analytic server 1, which analyses the data to identify fault events and then sends fault prediction data for the identified fault events to the vehicle operator server 3 associated with the vehicle 5, which in turn forwards the fault prediction data to the vehicle maintenance workshop server 11 at the vehicle maintenance workshop where the vehicle 5 is to be serviced.
  • the vehicle maintenance workshop uses the fault prediction data to assist servicing, and then sends, via the vehicle operator server 3, fault correction data for each fault event back to the analytic server 1.
  • the fault correction data is then used by the analytic server 1 to improve the accuracy of the fault prediction data produced for subsequent fault events. In other words, the analytic server 1 learns through experience the most likely causes of fault events.
  • vehicle 5 includes a plurality of electronic control units interconnected by a bus 15, typically a CAN bus.
  • the electronic control units typically include an engine control unit 17, a transmission control unit 19 and a traction control system 21.
  • Those skilled in the art will appreciate that many other electronic control units may conventionally be attached to the bus 15, for example an airbag deployment system and/or a cruise control system.
  • An OBD port 25 is also connected, via an OBD interface unit 27, to the bus 15.
  • the electronic control units monitor the operation of the vehicle 5, including processing parametric data and, if certain conditions (for example a parameter varying outside of its normal operating range) are satisfied, generating either permanent fault codes or temporary fault codes.
  • a permanent fault code will typically result in the driver interface 23 presenting a fault warning to the driver, for example by activating a malfunction indicator light.
  • a temporary fault code is stored by an electronic control unit for internal reference. For example, an electronic control unit may monitor the frequency of temporary fault codes and issue a permanent fault code if that frequency exceeds a predetermined amount.
  • a telematics device 29 is connected to the OBD port 23.
  • the telematics device 29 probes the electronic control units connected to the bus 15 for data, logs the collated data and forwards the collated data to the analytic server 1.
  • the telematics device 29 collates the generated permanent fault codes and temporary fault codes, and also collects parametric data in real time as the vehicle 5 is driven.
  • This parametric data may include, for example, oil temperature, RPM, Air Intake Temperature, Mass Air Flow, Engine Load, Throttle Position.
  • the telematics device 29 also includes a Global Positioning System (GPS) device (not shown) which provides both location (longitude and latitude) data and time data.
  • GPS Global Positioning System
  • the telematics device 29 can transmit raw telemetric data to the analytic server 1 in various ways. While the vehicle 5 is in operation, the telematics device 29 transmits the telemetric data wirelessly, using antenna 33, to the analytic server 1. Although the vehicle 5 may transmit the telemetric data wirelessly directly to the analytic server 1, typically the vehicle 5 transmits to the analytic server 1 via a PLMN, not shown in Figure 1.
  • the telematics device 29 may also be physically connected to a personal computer 31, for example by a USB cable, to allow the telemetric data to be transmitted via the Internet 13 to the analytic server 1. Further, telemetric data may be transferred from the telematics device 29 to a portable memory device, such as a USB drive or a hard disk, and the portable memory device can be physically transported to the analytic server 1 where the telemetric data is downloaded.
  • a portable memory device such as a USB drive or a hard disk
  • the analytic server 1 includes the following input/output devices for receiving and transmitting data:
  • a radio transceiver 41 for processing radio signals detected by an antenna 43 and transmitting radio signals using the antenna 43;
  • an Internet Transceiver 45 for receiving and sending IP signals 47; a network transceiver 49 for receiving and sending signals 51 over a network such as a Local Area Network (LAN); and
  • LAN Local Area Network
  • a hard disk reader/writer 53 for reading data from or writing data onto a memory device 55.
  • the radio transceiver 41, the Internet transceiver 45, the network transceiver 51 and the hard disk reader/writer 53 are all connected to a bus 57. Also connected to the bus 57 are a processor 59, a clock 61 and memory 63. It will be appreciated that, in a conventional manner, the memory 63 may involve several memory devices having different memory characteristics. With respect to hardware, the analytic server 1 may be implemented by a conventional network server.
  • the memory 63 has program storage memory 65, data storage memory 67 and working memory 69. Although represented as separate memory regions in Figure 2 for ease of illustration, typically these memory regions will not be formed by contiguous blocks of memory addresses.
  • the program storage memory 65 stores a Master_Control_Routine 71, which controls the operation of the analytic server 1.
  • the Master_Control_Routine 71 in response to the receipt of telemetric data from a vehicle 5, the Master_Control_Routine 71 initiates a Process_Raw_Data sub-routine 73. Further, in response to receiving fault correction data from a vehicle maintenance workshop server 11, the Master_Control_Routine 71 initiates a Process_FC_Data sub-routine 75.
  • the data storage memory 67 stores a client database 77, raw telemetric data 79, a datastream database 81, a failure mode database 83 and a fault effect signature database 85.
  • the client database 77 stores data for each of the vehicle operators. As schematically shown in Figure 3, the data 91 stored for a vehicle operator includes:
  • device rules 93 providing device details for each vehicle 5 owned by the vehicle operator, including an identification number and the format of transmitted telemetric data; event rules 95 specifying data indicative of conditions that the vehicle operator wishes to monitor, an occurrence of such conditions being hereafter referred to as an event;
  • report rules 97 specifying specific telemetric data which the vehicle operator wishes reported
  • warning rules 99 specifying events which the vehicle operator wishes to be warned about; and prediction rules 101 specifying events for which the vehicle operator wishes to be provided with information predicting the likely cause of the event.
  • the client database may be stored in the form of a relational database to facilitate the accuracy of data entry and data updating.
  • the datastream database 81 stores the received telemetric data after it has been decoded into a standardised format.
  • the fault effect signature database 85 stores a fault effect signature for each event in association with a unique event identifier, the fault effect signature being data associated with the event.
  • the failure mode database 83 stores data indicating, for each possible fault effect signature, the likely possible causes of the corresponding event.
  • receipt of the telemetric data triggers the execution of the Process_Raw_Data sub-routine 73 which first stores, at S I, the received telemetric data in the raw data memory region 79 and the back-up server 7. By storing all received telemetric data in the back-up server 7, the telemetric data may be recovered in case of damage to the diagnostic server 1.
  • the diagnostic server 1 is not reliant on the received data conforming to a particular format, but rather stores the format of the received data for each device in the device rules 93. This facilitates the use of the analytic server 1 with telematics devices 29 produced by different manufacturers.
  • the format in which the telematics data is transmitted may be dependent on the medium by which it is communicated to the analytic server 1 (e.g. by radio waves, the Internet or a memory card).
  • the analytic server 1 decodes, at S3, the telemetric data into a common format using the device rules 93. This decoded data is then stored, at S5, in the datastream database 81.
  • each portion (referred to hereafter as a message) of decoded data includes:
  • GPS data including latitude/longitude co-ordinates and timestamp
  • the analytic server 1 generates, at S7, a report to the vehicle operator based on the message data stored in the datastream database 81.
  • the message data will typically include telemetric data such as fuel consumption, odometer, vehicle battery charge, RPM, vehicle speed, coolant temperature and driver behaviour.
  • the vehicle operator does not necessarily wish all of this information included in the report, and accordingly the report data is generated using the report rules 97 specified by the vehicle operator.
  • the analytic server 1 identifies, at S9, events occurring within received telemetric data using the event rules 95.
  • Each event rule specifies one or more conditions in a message, or a sequence of messages, which if satisfied indicate an event that is indicative or predictive of a fault in the vehicle 5 and requiring of investigation has occurred.
  • Such event rules may specify conditions to be satisfied relating to fault codes, both permanent and temporary, and parametric data.
  • an event rule indicating a fault could specify one or more of the following:
  • An event rule predicting the occurrence of a fault typically specifies a plurality of conditions, which may relate to a plurality of conditions being satisfied in one message or one or more conditions being satisfied for each of a series of messages.
  • the plurality of conditions may relate to the variation of an individual parameter over a sequence of messages.
  • Figure 5 illustrates such an example, in which the value of a parameter is shown for a sequence of messages time-stamped at Ti - T 9 . While the parameter values are approximately the same in the first four messages, over the next five messages an upward trend is apparent suggesting that a fault will eventually occur.
  • the normal operating range of the parameter is from Pi to P 2 , with a fault code (either permanent or temporary) being generated if the parameter value moves outside this normal operating range. It is notable that a fault may be predicted before the parameter value moves outside of the normal operating range, i.e. before any fault code would have been generated.
  • Figure 6 illustrates another example, in which the conditions relate to the values specified for a plurality of parameters in a single message.
  • values for a parameter A normal operating range Ai to A 2
  • a parameter B normal operating range Bi to B 2
  • a parameter C normal operating range Ci to C 2
  • a parameter D normal operating range Di to D 2
  • an event may occur if, as shown in Figure 6, the values for parameters A and B are in the bottom quartile of their normal operating range and the values for parameters C and D are in the top quartile of their normal operating range.
  • the plurality of conditions may include a plurality of conditions for each of a sequence of messages, with the respective conditions for each message not necessarily being the same.
  • the analytic server 1 Following identification of an event, the analytic server 1 generates, at S l l, a fault effect signature for the event and stores the fault effect signature in the fault effect signature database 85 in association with a unique event identifier.
  • the fault effect signature provides data representative of the event, and more particularly provides data showing the effect that a particular fault has on the fault code(s) and parametric data.
  • the fault effect signature could contain all the telemetric data associated with an event.
  • the fault effect signature will include a compressed form of the telemetric data associated with an event. It will be appreciated that many data processing techniques are available to compress the telemetric data so that each fault effect signature remains representative of a respective particular fault.
  • the fault effect signature includes a portion which is representative of the vehicle 5 and a portion which is representative of the raw data from the vehicle 5. In this way, the same fault in identical vehicles will result in the same fault effect signature.
  • the analytic server 1 Following generation of the fault effect signature, the analytic server 1 generates, at S13, warning data to advise the vehicle operator of the fault.
  • the vehicle operator may not wish to be advised of every fault, and accordingly the analytic server 1 consults the warning rules 99 specified by the vehicle operator to determine the events for which warnings are to be issued.
  • the warning data includes the unique event identifier of each event for which a warning is issued.
  • the analytic server 1 also predicts, at S 15, the cause of the fault using the failure mode database 83.
  • the failure mode database 83 logs reported causes of failure associated with every possible fault effect signature, and then subsequently uses this logged data to predict the likely cause of a fault for a newly generated fault effect signature.
  • the failure mode database 83 may have logged that previously, the fault associated with the fault effect signature had been caused by reason 'A' seven times, reason 'B' two times and reason 'C one time, and accordingly will predict that there is a 70% chance that the fault was caused by reason ⁇ ', a 20% chance that the fault was caused by reason 'B' and a 10% chance that the fault was caused by reason 'C .
  • the analytic server 1 Following the determination of likely causes of a fault, the analytic server 1 generates, at S 17, prediction data to advise the vehicle operator of the predicted cause of a fault.
  • the vehicle operator may not wish to receive all the prediction data, but rather may prefer only to be advised of the most likely cause or any causes which are above a certain level of likelihood. Accordingly, the analytic server 1 consults the prediction rules 101 specified by the vehicle operator to determine the exact prediction data to be sent to the vehicle operator. For each event for which prediction data is generated, the prediction data includes the unique event identifier for that event in association with data identifying the predicted cause of that event.
  • the analytic server 1 sends the report data, the warning data and the prediction data to the vehicle operator server 3. Following receipt of the warning data, the vehicle operator may decide to submit a vehicle 5 for which a warning is issued to a vehicle maintenance workshop for servicing.
  • the vehicle operator server 3 sends a message conveying the warning data and the corresponding prediction data for the vehicle 5 to the vehicle maintenance workshop server 11 for the vehicle maintenance workshop handling the servicing.
  • the prediction data facilitates servicing and repair of the vehicle by suggesting the most likely cause or causes of a fault. In this way, the vehicle may be serviced and repaired in less time and at less expense.
  • the vehicle maintenance workshop server 11 sends, either directly or via the vehicle operator server 3, fault correction data indicating the actual cause of the fault to the analytic server 1.
  • the fault correction data includes for each corrected event, the unique event identifier and data indicating the cause of failure for that event.
  • the analytic server 1 updates, at S21, the entry in the failure mode database 83 for the corresponding fault effect signature with the actual cause of the fault.
  • the analytic server 1 identifies the correct entry in the failure mode database by referencing the fault effect signature corresponding to the unique event identifier conveyed in the fault correction data. In this way, the analytic server 1 learns through experience the likely causes associated with every possible fault effect signature.
  • the arrangement of the present embodiment has several advantages.
  • One advantage is the ability to provide early warning of faults, and predictions of the causes of the faults, in real time while the vehicle is in operation.
  • the early warnings may be issued before any permanent fault code occurs, allowing the predicted cause of the fault to be addressed before serious damage is done. In this way, the maintenance of the fleet of vehicles can be made more efficient. It will also be appreciated that, over time, the fault prediction data will become more and more accurate as a result of experiential learning by the analytic server 1.
  • the analytic server 1 is used to analyse the operation of a vehicle 5. It will be appreciated that the analytic server 1 could alternatively be used to analyse the operation of different types of machine.
  • the term machine covers any form of mechanical, electrical and/or chemical apparatus or system having means for monitoring the operation of the machine and generating raw data indicative of that operation, and means for transmitting the raw data to an analytic server 1.
  • machines suitable for the present invention include electric vehicles, hybrid vehicles, alternative fuel vehicles, seacraft, aircraft, agricultural and construction vehicles, military vehicles, industrial and robotic machinery, and power generators.
  • the invention requires that fault prediction data is determined for each fault effect signature.
  • this is achieved by a failure mode database which maps each fault effect signature to corresponding fault prediction data, and the failure mode database is updated as fault correction data is received.
  • the analytic server 1 may use a neural network to generate the fault prediction data through experiential learning.
  • the embodiment described with reference to the drawings involves performing process instructions defined by a computer program using some form of processing apparatus.
  • the invention therefore also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice.
  • the program may be in the form of source code, object code, a code intermediate to source code and object code such as in partially compiled form, or in any other form suitable for using in the implementation of the processes according to the invention.
  • the carrier may be any entity or device capable of carrying the program.
  • the carrier may comprise a storage medium, such as a ROM, for example a CD- ROM or a semiconductor ROM, or a magnetic recording medium, for example a floppy disc or a hard disc, or an optical recording medium.
  • the carrier may be a transmissible carrier such as an electronic or optical signal which may be conveyed via electrical or optical cable or by radio or other means.
  • the carrier may be an integrated circuit in which the program is embedded, the integrated circuit being adapted for performing, or for use in the performance of, the relevant processes.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Traffic Control Systems (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

There is discussed a machine analytic system which processes data from one or more machines to identify events satisfying predetermined event conditions indicative of faulty operation, and for each identified event generates an event signature using data associated with the event. The event signatures are then analysed to generate data identifying a prediction of the cause of a fault. The generated fault prediction data may be output to a machine operator to take appropriate action. In an embodiment, each possible event signature is mapped to corresponding fault prediction data in a fault prediction database. Preferably, fault correction data indicating successful remedial action taken for an event is received by the machine analytic system and the fault correction data for the event signature corresponding to the event is updated to take account of the received fault correction data.

Description

Machine Analytic System and Components Thereof
This invention concerns a system for analysing the operation of a machine. The invention has particular, but not exclusive, relevance to the diagnosis or prognosis of a fault in a vehicle.
One application for an analytic system in accordance with the invention is to the management of a fleet of vehicles by a fleet operator. For example, the fleet operator may be a courier company operating a fleet of vans. Alternatively, the fleet operator may be a taxi company operating a fleet of taxis. It is known to supply information from the fleet of vehicles to the fleet operator to improve the utilisation of the fleet of vehicles, and over recent years the nature of the information provided to the fleet operator has increased.
Initially, a GPS device was fitted to each vehicle in the fleet to allow the movement of the vehicles to be monitored. Subsequently, the location information provided by the GPS devices was integrated into a scheduling service to improve scheduling of the use of the fleet of vehicles. More recently, an interface to the vehicle diagnostic network was added to enable information about vehicle and driver behaviour to be gathered while the vehicle is in use, providing data relating to fuel consumption and carbon emissions of the vehicle.
Although fault codes produced by the on-board diagnostic network (OBD) in a vehicle can identify components of the vehicle which are not functioning properly, the cause of the fault is not provided and as such the necessary action to correct the fault can be difficult to ascertain. In addition, fault codes are only produced after a fault has occurred, by which time the expense in rectifying the fault may be significant. The present invention addresses these problems.
According to the present invention, there is provided a machine analytic system which processes data from one or more machines to identify events satisfying predetermined event conditions indicative of faulty operation, and for each identified event generates an event signature using data associated with the event. The event signatures are then analysed to generate data identifying a prediction of the cause of a fault. The generated fault prediction data may be output to a machine operator to take appropriate action.
In an embodiment, the data from one or more machines includes parametric data and at least one of the event conditions may relate to a plurality of parameter readings. For example, an event condition may relate to the variation of the readings for a particular parameter over time, another event condition may relate to readings for different parameters at the same time, while yet another event condition may relate to parameter readings corresponding both to the variation of one particular parameter over time and the parameter values for a plurality of parameters at the same time. By using a plurality of parameter readings, a fault may be predicted in advance of any one parameter varying outside of a normal operating range and thereby triggering the generation of a fault code.
In an embodiment, each possible event signature is mapped to corresponding fault prediction data in a fault prediction database. Preferably, fault correction data indicating successful remedial action taken for an event is received by the machine analytic system and the fault correction data for the event signature corresponding to the event is updated to take account of the received fault correction data.
An exemplary embodiment of the invention will now be described with reference to the attached figures, in which:
Figure 1 schematically shows the main components of a machine analytic system according to the invention;
Figure 2 schematically shows the main components of an analytic server forming part of the machine analytic system illustrated in Figure 1;
Figure 3 schematically shows client data stored in a client database illustrated in Figure 2;
Figure 4 schematically illustrates the processing of raw data from a machine by the analytic server of Figure 2;
Figure 5 illustrates the variation of a parameter value over time;
Figure 6 illustrates a plurality of parameter values at the same time instant; and
Figure 7 schematically shows the processing of fault correction data by the analytic server of Figure 2.
System Overview
In the exemplary embodiment of the invention, an analytic service operator operates an analytic server 1 which performs vehicle analysis services for a plurality of vehicle operators. Each of the vehicle operators has a vehicle operator server 3 (only one of which is shown in Figure 1 for ease of illustration) and operates a fleet of vehicles 5 (only a single vehicle 5 being shown in Figure 1 for ease of illustration). A back-up server 7 is also provided for backing up data stored in the analytic server 1 in case of damage to the analytic server 1. The vehicle 5 includes a driver communication device 9 which is wirelessly connected, either directly or via a wireless communication network (for example a public land mobile network (PLMN)), with the vehicle operator server 3 to allow the vehicle operator to communicate with the driver of the vehicle 5.
The vehicles 5 are serviced in vehicle maintenance workshops, with each vehicle maintenance workshop having a vehicle maintenance workshop server 11 (only one of which is shown in Figure 1 for ease of illustration). The analytic server 1, the back-up server 7, the vehicle operator servers 3 and the vehicle maintenance workshop servers 11 are all connected to each other via the Internet 13. Dedicated connections (shown by dotted lines in Figure 1) may be provided in addition to, or instead of, the Internet connections between (i) the analytic server 1 and the back-up server 7, (ii) the analytic server 1 and one or more of the vehicle operator servers 3, and (iii) each vehicle operator server 3 and one or more vehicle maintenance workshop servers 11.
As will be described in more detail hereafter, in accordance with the invention, raw data from the vehicle 5 is communicated to the analytic server 1, which analyses the data to identify fault events and then sends fault prediction data for the identified fault events to the vehicle operator server 3 associated with the vehicle 5, which in turn forwards the fault prediction data to the vehicle maintenance workshop server 11 at the vehicle maintenance workshop where the vehicle 5 is to be serviced. The vehicle maintenance workshop uses the fault prediction data to assist servicing, and then sends, via the vehicle operator server 3, fault correction data for each fault event back to the analytic server 1. The fault correction data is then used by the analytic server 1 to improve the accuracy of the fault prediction data produced for subsequent fault events. In other words, the analytic server 1 learns through experience the most likely causes of fault events.
As shown in Figure 1, vehicle 5 includes a plurality of electronic control units interconnected by a bus 15, typically a CAN bus. As shown, the electronic control units typically include an engine control unit 17, a transmission control unit 19 and a traction control system 21. A driver interface 23, for example a dashboard display having an array of malfunction indicator lights, is also connected to the bus 15. Those skilled in the art will appreciate that many other electronic control units may conventionally be attached to the bus 15, for example an airbag deployment system and/or a cruise control system. An OBD port 25 is also connected, via an OBD interface unit 27, to the bus 15.
In a conventional manner, the electronic control units monitor the operation of the vehicle 5, including processing parametric data and, if certain conditions (for example a parameter varying outside of its normal operating range) are satisfied, generating either permanent fault codes or temporary fault codes. A permanent fault code will typically result in the driver interface 23 presenting a fault warning to the driver, for example by activating a malfunction indicator light. A temporary fault code is stored by an electronic control unit for internal reference. For example, an electronic control unit may monitor the frequency of temporary fault codes and issue a permanent fault code if that frequency exceeds a predetermined amount.
In this embodiment, a telematics device 29 is connected to the OBD port 23. The telematics device 29 probes the electronic control units connected to the bus 15 for data, logs the collated data and forwards the collated data to the analytic server 1. In particular, the telematics device 29 collates the generated permanent fault codes and temporary fault codes, and also collects parametric data in real time as the vehicle 5 is driven. This parametric data may include, for example, oil temperature, RPM, Air Intake Temperature, Mass Air Flow, Engine Load, Throttle Position. The telematics device 29 also includes a Global Positioning System (GPS) device (not shown) which provides both location (longitude and latitude) data and time data.
In this embodiment, the telematics device 29 can transmit raw telemetric data to the analytic server 1 in various ways. While the vehicle 5 is in operation, the telematics device 29 transmits the telemetric data wirelessly, using antenna 33, to the analytic server 1. Although the vehicle 5 may transmit the telemetric data wirelessly directly to the analytic server 1, typically the vehicle 5 transmits to the analytic server 1 via a PLMN, not shown in Figure 1. The telematics device 29 may also be physically connected to a personal computer 31, for example by a USB cable, to allow the telemetric data to be transmitted via the Internet 13 to the analytic server 1. Further, telemetric data may be transferred from the telematics device 29 to a portable memory device, such as a USB drive or a hard disk, and the portable memory device can be physically transported to the analytic server 1 where the telemetric data is downloaded.
As shown in Figure 2, the analytic server 1 includes the following input/output devices for receiving and transmitting data:
a radio transceiver 41 for processing radio signals detected by an antenna 43 and transmitting radio signals using the antenna 43;
an Internet Transceiver 45 for receiving and sending IP signals 47; a network transceiver 49 for receiving and sending signals 51 over a network such as a Local Area Network (LAN); and
a hard disk reader/writer 53 for reading data from or writing data onto a memory device 55.
The radio transceiver 41, the Internet transceiver 45, the network transceiver 51 and the hard disk reader/writer 53 are all connected to a bus 57. Also connected to the bus 57 are a processor 59, a clock 61 and memory 63. It will be appreciated that, in a conventional manner, the memory 63 may involve several memory devices having different memory characteristics. With respect to hardware, the analytic server 1 may be implemented by a conventional network server.
As schematically shown in Figure 2, the memory 63 has program storage memory 65, data storage memory 67 and working memory 69. Although represented as separate memory regions in Figure 2 for ease of illustration, typically these memory regions will not be formed by contiguous blocks of memory addresses.
The program storage memory 65 stores a Master_Control_Routine 71, which controls the operation of the analytic server 1. As will be described in more detail hereafter, in response to the receipt of telemetric data from a vehicle 5, the Master_Control_Routine 71 initiates a Process_Raw_Data sub-routine 73. Further, in response to receiving fault correction data from a vehicle maintenance workshop server 11, the Master_Control_Routine 71 initiates a Process_FC_Data sub-routine 75.
The data storage memory 67 stores a client database 77, raw telemetric data 79, a datastream database 81, a failure mode database 83 and a fault effect signature database 85. The client database 77 stores data for each of the vehicle operators. As schematically shown in Figure 3, the data 91 stored for a vehicle operator includes:
device rules 93 providing device details for each vehicle 5 owned by the vehicle operator, including an identification number and the format of transmitted telemetric data; event rules 95 specifying data indicative of conditions that the vehicle operator wishes to monitor, an occurrence of such conditions being hereafter referred to as an event;
report rules 97 specifying specific telemetric data which the vehicle operator wishes reported;
warning rules 99 specifying events which the vehicle operator wishes to be warned about; and prediction rules 101 specifying events for which the vehicle operator wishes to be provided with information predicting the likely cause of the event.
It will be appreciated that the client database may be stored in the form of a relational database to facilitate the accuracy of data entry and data updating.
The datastream database 81 stores the received telemetric data after it has been decoded into a standardised format. The fault effect signature database 85 stores a fault effect signature for each event in association with a unique event identifier, the fault effect signature being data associated with the event. The failure mode database 83 stores data indicating, for each possible fault effect signature, the likely possible causes of the corresponding event.
The processing of received telemetric data will now be discussed with reference to Figure 4. As mentioned above, receipt of the telemetric data triggers the execution of the Process_Raw_Data sub-routine 73 which first stores, at S I, the received telemetric data in the raw data memory region 79 and the back-up server 7. By storing all received telemetric data in the back-up server 7, the telemetric data may be recovered in case of damage to the diagnostic server 1.
In this embodiment, the diagnostic server 1 is not reliant on the received data conforming to a particular format, but rather stores the format of the received data for each device in the device rules 93. This facilitates the use of the analytic server 1 with telematics devices 29 produced by different manufacturers. In addition, the format in which the telematics data is transmitted may be dependent on the medium by which it is communicated to the analytic server 1 (e.g. by radio waves, the Internet or a memory card). The analytic server 1 decodes, at S3, the telemetric data into a common format using the device rules 93. This decoded data is then stored, at S5, in the datastream database 81. Typically, each portion (referred to hereafter as a message) of decoded data includes:
• Vehicle Identification
• GPS data (including latitude/longitude co-ordinates and timestamp)
• Acceleration/Deceleration Data
• Message Receipt Timestamp
• Message Sequence Number
• Permanent Fault Codes
• Temporary Fault Codes
• Parametric Data The analytic server 1 generates, at S7, a report to the vehicle operator based on the message data stored in the datastream database 81. The message data will typically include telemetric data such as fuel consumption, odometer, vehicle battery charge, RPM, vehicle speed, coolant temperature and driver behaviour. The vehicle operator does not necessarily wish all of this information included in the report, and accordingly the report data is generated using the report rules 97 specified by the vehicle operator.
In accordance with the present invention, the analytic server 1 identifies, at S9, events occurring within received telemetric data using the event rules 95. Each event rule specifies one or more conditions in a message, or a sequence of messages, which if satisfied indicate an event that is indicative or predictive of a fault in the vehicle 5 and requiring of investigation has occurred. Such event rules may specify conditions to be satisfied relating to fault codes, both permanent and temporary, and parametric data. For example, an event rule indicating a fault could specify one or more of the following:
• A permanent fault code is detected
• A temporary fault code is detected
• A parametric data value is out of tolerance
An event rule predicting the occurrence of a fault typically specifies a plurality of conditions, which may relate to a plurality of conditions being satisfied in one message or one or more conditions being satisfied for each of a series of messages. For example, the plurality of conditions may relate to the variation of an individual parameter over a sequence of messages. Figure 5 illustrates such an example, in which the value of a parameter is shown for a sequence of messages time-stamped at Ti - T9. While the parameter values are approximately the same in the first four messages, over the next five messages an upward trend is apparent suggesting that a fault will eventually occur. In Figure 5, the normal operating range of the parameter is from Pi to P2, with a fault code (either permanent or temporary) being generated if the parameter value moves outside this normal operating range. It is notable that a fault may be predicted before the parameter value moves outside of the normal operating range, i.e. before any fault code would have been generated.
Figure 6 illustrates another example, in which the conditions relate to the values specified for a plurality of parameters in a single message. In particular, values for a parameter A (normal operating range Ai to A2), a parameter B (normal operating range Bi to B2), a parameter C (normal operating range Ci to C2) and a parameter D (normal operating range Di to D2) are indicated. While none of the parameter values are outside of their normal operating range, an event may occur if, as shown in Figure 6, the values for parameters A and B are in the bottom quartile of their normal operating range and the values for parameters C and D are in the top quartile of their normal operating range.
It will be appreciated that the plurality of conditions may include a plurality of conditions for each of a sequence of messages, with the respective conditions for each message not necessarily being the same.
Following identification of an event, the analytic server 1 generates, at S l l, a fault effect signature for the event and stores the fault effect signature in the fault effect signature database 85 in association with a unique event identifier. The fault effect signature provides data representative of the event, and more particularly provides data showing the effect that a particular fault has on the fault code(s) and parametric data. In one form, the fault effect signature could contain all the telemetric data associated with an event. However, in a preferred form, the fault effect signature will include a compressed form of the telemetric data associated with an event. It will be appreciated that many data processing techniques are available to compress the telemetric data so that each fault effect signature remains representative of a respective particular fault.
In this embodiment, the fault effect signature includes a portion which is representative of the vehicle 5 and a portion which is representative of the raw data from the vehicle 5. In this way, the same fault in identical vehicles will result in the same fault effect signature.
Following generation of the fault effect signature, the analytic server 1 generates, at S13, warning data to advise the vehicle operator of the fault. The vehicle operator may not wish to be advised of every fault, and accordingly the analytic server 1 consults the warning rules 99 specified by the vehicle operator to determine the events for which warnings are to be issued. In this embodiment, the warning data includes the unique event identifier of each event for which a warning is issued.
The analytic server 1 also predicts, at S 15, the cause of the fault using the failure mode database 83. As will be discussed hereafter, in this embodiment the failure mode database 83 logs reported causes of failure associated with every possible fault effect signature, and then subsequently uses this logged data to predict the likely cause of a fault for a newly generated fault effect signature. For example, for a particular fault effect signature the failure mode database 83 may have logged that previously, the fault associated with the fault effect signature had been caused by reason 'A' seven times, reason 'B' two times and reason 'C one time, and accordingly will predict that there is a 70% chance that the fault was caused by reason Ά', a 20% chance that the fault was caused by reason 'B' and a 10% chance that the fault was caused by reason 'C .
Following the determination of likely causes of a fault, the analytic server 1 generates, at S 17, prediction data to advise the vehicle operator of the predicted cause of a fault. The vehicle operator may not wish to receive all the prediction data, but rather may prefer only to be advised of the most likely cause or any causes which are above a certain level of likelihood. Accordingly, the analytic server 1 consults the prediction rules 101 specified by the vehicle operator to determine the exact prediction data to be sent to the vehicle operator. For each event for which prediction data is generated, the prediction data includes the unique event identifier for that event in association with data identifying the predicted cause of that event.
The analytic server 1 sends the report data, the warning data and the prediction data to the vehicle operator server 3. Following receipt of the warning data, the vehicle operator may decide to submit a vehicle 5 for which a warning is issued to a vehicle maintenance workshop for servicing. The vehicle operator server 3 sends a message conveying the warning data and the corresponding prediction data for the vehicle 5 to the vehicle maintenance workshop server 11 for the vehicle maintenance workshop handling the servicing. The prediction data facilitates servicing and repair of the vehicle by suggesting the most likely cause or causes of a fault. In this way, the vehicle may be serviced and repaired in less time and at less expense.
When the vehicle maintenance workshop has determined the actual cause of the fault, the vehicle maintenance workshop server 11 sends, either directly or via the vehicle operator server 3, fault correction data indicating the actual cause of the fault to the analytic server 1. In particular, the fault correction data includes for each corrected event, the unique event identifier and data indicating the cause of failure for that event.
As shown in Figure 7, following receipt of the fault correction data, the analytic server 1 updates, at S21, the entry in the failure mode database 83 for the corresponding fault effect signature with the actual cause of the fault. The analytic server 1 identifies the correct entry in the failure mode database by referencing the fault effect signature corresponding to the unique event identifier conveyed in the fault correction data. In this way, the analytic server 1 learns through experience the likely causes associated with every possible fault effect signature. As discussed above, the arrangement of the present embodiment has several advantages. One advantage is the ability to provide early warning of faults, and predictions of the causes of the faults, in real time while the vehicle is in operation. The early warnings may be issued before any permanent fault code occurs, allowing the predicted cause of the fault to be addressed before serious damage is done. In this way, the maintenance of the fleet of vehicles can be made more efficient. It will also be appreciated that, over time, the fault prediction data will become more and more accurate as a result of experiential learning by the analytic server 1.
MODIFICATIONS AND FURTHER EMBODIMENT
In the illustrated embodiment, the analytic server 1 is used to analyse the operation of a vehicle 5. It will be appreciated that the analytic server 1 could alternatively be used to analyse the operation of different types of machine. For the avoidance of doubt, the term machine covers any form of mechanical, electrical and/or chemical apparatus or system having means for monitoring the operation of the machine and generating raw data indicative of that operation, and means for transmitting the raw data to an analytic server 1. Other examples of machines suitable for the present invention include electric vehicles, hybrid vehicles, alternative fuel vehicles, seacraft, aircraft, agricultural and construction vehicles, military vehicles, industrial and robotic machinery, and power generators.
The invention requires that fault prediction data is determined for each fault effect signature. In the illustrated embodiment, this is achieved by a failure mode database which maps each fault effect signature to corresponding fault prediction data, and the failure mode database is updated as fault correction data is received. Alternatively, the analytic server 1 may use a neural network to generate the fault prediction data through experiential learning.
The embodiment described with reference to the drawings involves performing process instructions defined by a computer program using some form of processing apparatus. The invention therefore also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice. The program may be in the form of source code, object code, a code intermediate to source code and object code such as in partially compiled form, or in any other form suitable for using in the implementation of the processes according to the invention.
The carrier may be any entity or device capable of carrying the program. For example, the carrier may comprise a storage medium, such as a ROM, for example a CD- ROM or a semiconductor ROM, or a magnetic recording medium, for example a floppy disc or a hard disc, or an optical recording medium. Further, the carrier may be a transmissible carrier such as an electronic or optical signal which may be conveyed via electrical or optical cable or by radio or other means.
5 The carrier may be an integrated circuit in which the program is embedded, the integrated circuit being adapted for performing, or for use in the performance of, the relevant processes.
Although the invention may be implemented by software, it will be appreciated that alternatively the invention could be implemented by hardware devices or a combination of i o hardware devices and software.

Claims

1. An analytic apparatus comprising:
means for receiving raw data from a machine;
means for processing the received raw data to identify events in the raw data, each event corresponding to the received raw data satisfying one or more event conditions indicative of faulty operation of the machine;
means for generating an event signature for each event using raw data associated with the event, the event signature for an event being characteristic of the corresponding faulty operation; and
means for determining fault prediction data corresponding to each event signature, the fault prediction data identifying one or more predicted causes of said corresponding faulty operation for the event.
2. An analytic apparatus according to claim 1, wherein the determining means comprises a database storing fault prediction data for each possible event signature.
3. An analytic apparatus according to claim 2, further comprising:
means for receiving fault correction data for a generated event signature, the fault correction data indicating an actual cause of the faulty operation associated with the generated event signature; and
means for updating the fault correction data for the generated fault signature to take account of the received fault correction data.
4. An analytic apparatus according to any preceding claim, wherein the raw data comprises parameter data, and said one or more event conditions specify at least one condition relating to parameter data received from the machine.
5. An analytic apparatus according to claim 4, wherein at least one event has a plurality of event conditions.
6. An analytic apparatus according to claim 5, wherein the analytic apparatus is operable to receive a sequence of messages, each of the sequence of messages conveying raw data for a respective timing, and said plurality of event conditions includes conditions associated with the values of two or more parameters in a single message.
7. An analytic apparatus according to claim 5, wherein the analytic apparatus is operable to receive a sequence of messages, each of the sequence of messages conveying raw data for a respective timing, and said plurality of event conditions includes conditions associated with the values of a single parameter in two or more messages.
8. An analytic apparatus according to any of claims 4 to 7, wherein at least one event corresponds to values of the parameter data which do not trigger a fault code.
9. An analytic system comprising a machine and an analytic apparatus according to any preceding claim, wherein the machine comprises:
means for monitoring the machine during operation and generating said raw data; and means for transmitting said raw data to the analytic apparatus.
10. An analytic system according to claim 9, wherein the raw data comprises one or more of fault codes and parameter data.
11. An analytic system according to claim 9 or 10, wherein the machine comprises a vehicle.
12. A method of operation of an analytic apparatus, the method comprising:
receiving raw data from a machine;
processing the received raw data to identify events in the raw data, each event corresponding to the received raw data satisfying one or more event conditions indicative of faulty operation of the machine;
generating an event signature for each event using raw data associated with the event, the event signature for an event being characteristic of the corresponding faulty operation; and determining fault prediction data corresponding to each event signature, the fault prediction data identifying one or more predicted causes of said corresponding faulty operation for the event.
13. A method according to claim 12, wherein said determining comprises retrieving fault prediction data for the event signature from a database storing fault prediction data for each possible event signature.
14. A method according to claim 12 or 13, further comprising:
receiving fault correction data for a generated event signature, the fault correction data indicating an actual cause of the faulty operation associated with the generated event signature; and
updating the fault correction data for the generated fault signature to take account of the received fault correction data.
15. A method according to any of claims 12 to 14, wherein the raw data is generated during operation of the machine.
16. A method according to any of claims 12 to 15, wherein the raw data comprises parameter data, and said one or more event conditions specify at least one condition relating to parameter data received from the machine.
17. A method according to claim 16, wherein at least one event has a plurality of event conditions.
18. A method according to claim 17, comprising receiving a sequence of messages, each of the sequence of messages conveying raw data for a respective timing,
wherein said plurality of event conditions includes conditions associated with the values of two or more parameters in a single message.
19. A method according to claim 17, comprising receiving a sequence of messages, each of the sequence of messages conveying raw data for a respective timing,
wherein said plurality of event conditions includes conditions associated with the values of a single parameter in two or more messages.
20. A method according to any of claims 16 to 19, wherein at least one event corresponds to values of the parameter data which do not trigger a fault code.
21. A computer program for programming a programmable device to perform a method as claimed in any of claims 12 to 20.
PCT/GB2013/051001 2012-04-19 2013-04-19 Machine analytic system and components thereof WO2013156791A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1206844.1A GB2501291A (en) 2012-04-19 2012-04-19 Diagnostic system with predicted problem cause feedback
GB1206844.1 2012-04-19

Publications (1)

Publication Number Publication Date
WO2013156791A1 true WO2013156791A1 (en) 2013-10-24

Family

ID=46209281

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2013/051001 WO2013156791A1 (en) 2012-04-19 2013-04-19 Machine analytic system and components thereof

Country Status (2)

Country Link
GB (1) GB2501291A (en)
WO (1) WO2013156791A1 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106682795A (en) * 2015-11-05 2017-05-17 大陆汽车投资(上海)有限公司 Data analysis based automobile part information processing method
CN108806222A (en) * 2018-03-09 2018-11-13 上海蜀瑞电子科技有限公司 Intelligent door lock method for connecting network and intelligent door lock
JP2019206247A (en) * 2018-05-29 2019-12-05 株式会社デンソーテン Failure prediction device and failure prediction method
US11093315B2 (en) 2019-03-22 2021-08-17 Toyota Motor Engineering & Manufacturing North America, Inc. Systems and methods for detecting a fault or a model mismatch
FR3131168A1 (en) * 2021-12-20 2023-06-23 Renault Communication system configured to communicate with vehicles in a combination of vehicles
US11704590B2 (en) 2017-03-24 2023-07-18 Toyota Motor Engineering & Manufacturing North America, Inc. Methods and systems for predicting failure of a power control unit of a vehicle

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10547502B2 (en) 2017-08-10 2020-01-28 Ford Global Technologies, Llc Vehicle communications
CN113706739B (en) * 2021-07-09 2023-01-03 中联重科土方机械有限公司 Remote fault diagnosis processing method, platform and system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1991010205A1 (en) * 1989-12-21 1991-07-11 Siemens Aktiengesellschaft Method and device for storing intermittent functional faults of a physical system and of context variables of these faults
GB2388666A (en) * 2002-05-16 2003-11-19 Ford Global Tech Llc Diagnostic and prognostic methods for complex systems
US20100023203A1 (en) * 2008-07-23 2010-01-28 Oren Shibi Diagnosis system and method for assisting a user
US20120053778A1 (en) * 2010-08-27 2012-03-01 Zonar Systems, Inc. Method and apparatus for remote vehicle diagnosis

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002244724A (en) * 2001-02-20 2002-08-30 Honda Motor Co Ltd Remote monitoring device for machine and management method therefor
JP4826609B2 (en) * 2008-08-29 2011-11-30 トヨタ自動車株式会社 Vehicle abnormality analysis system and vehicle abnormality analysis method

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1991010205A1 (en) * 1989-12-21 1991-07-11 Siemens Aktiengesellschaft Method and device for storing intermittent functional faults of a physical system and of context variables of these faults
GB2388666A (en) * 2002-05-16 2003-11-19 Ford Global Tech Llc Diagnostic and prognostic methods for complex systems
US20100023203A1 (en) * 2008-07-23 2010-01-28 Oren Shibi Diagnosis system and method for assisting a user
US20120053778A1 (en) * 2010-08-27 2012-03-01 Zonar Systems, Inc. Method and apparatus for remote vehicle diagnosis

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106682795A (en) * 2015-11-05 2017-05-17 大陆汽车投资(上海)有限公司 Data analysis based automobile part information processing method
US11704590B2 (en) 2017-03-24 2023-07-18 Toyota Motor Engineering & Manufacturing North America, Inc. Methods and systems for predicting failure of a power control unit of a vehicle
CN108806222A (en) * 2018-03-09 2018-11-13 上海蜀瑞电子科技有限公司 Intelligent door lock method for connecting network and intelligent door lock
JP2019206247A (en) * 2018-05-29 2019-12-05 株式会社デンソーテン Failure prediction device and failure prediction method
US11093315B2 (en) 2019-03-22 2021-08-17 Toyota Motor Engineering & Manufacturing North America, Inc. Systems and methods for detecting a fault or a model mismatch
FR3131168A1 (en) * 2021-12-20 2023-06-23 Renault Communication system configured to communicate with vehicles in a combination of vehicles
WO2023117296A1 (en) * 2021-12-20 2023-06-29 Renault S.A.S. Communication system configured to communicate with vehicles of a set of vehicles

Also Published As

Publication number Publication date
GB2501291A (en) 2013-10-23
GB201206844D0 (en) 2012-05-30

Similar Documents

Publication Publication Date Title
WO2013156791A1 (en) Machine analytic system and components thereof
US11978291B2 (en) Method and apparatus for remote vehicle diagnosis
US11282306B2 (en) Telematically monitoring and predicting a vehicle battery state
US20170103101A1 (en) System for database data quality processing
CN106843190B (en) Distributed vehicle health management system
US6609051B2 (en) Method and system for condition monitoring of vehicles
EP2112492B1 (en) Test requirement list for diagnostic tests
CA2689744C (en) System and method for monitoring operation of vehicles
US7668643B2 (en) Method and system for automatically inspecting and registering automotive exhaust emission data
CN102375452B (en) Event-driven data mining method for improving fault code settings and isolating faults
US20030137194A1 (en) Data collection and manipulation apparatus and method
JP2020507748A (en) Cloud-based vehicle failure diagnosis method, apparatus and system
US9928669B2 (en) System and method for providing optimal state indication of a vehicle
CN103493019A (en) Collaborative multi-agent vehicle fault diagnostic system & associated methodology
CA2689110A1 (en) Compiling source information from a motor vehicle data system and configuring a telematic module
CN105469147B (en) Method for diagnosing faults and/or diagnosing repair and/or maintenance needs
JPWO2005057519A1 (en) Vehicle information collection management method, vehicle information collection management system, information management base station apparatus and vehicle used in the system
EP2609565A1 (en) Method and apparatus for remote vehicle diagnosis
JP2019206247A (en) Failure prediction device and failure prediction method
US7729825B2 (en) System and method of intelligent agent management using an agent interface for use in vehicle diagnostics
KR102255599B1 (en) System and method for providing vehicle diagnosis service
WO2024040287A1 (en) Vehicle asset benchmarking system
WO2022229970A1 (en) System and method for real time data extraction of vehicle operational impact on traction battery
Zanini et al. Mobile assets monitoring for fleet maintenance

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: 13724336

Country of ref document: EP

Kind code of ref document: A1

DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13724336

Country of ref document: EP

Kind code of ref document: A1