ASSET INSPECTION ASSISTANT

Abstract

This system (2) for identifying probable faults of an asset (1) within a fleet of assets (8) comprises sensors (10) configured to detect asset sensor data (6b); one or more user input devices (13, 16) associated with said plurality of assets (8); and one or more user output terminals (15) associated with said plurality of assets (8); and a server device (7). The server device (7) is configured to collect historical data; to use an algorithm to identify correlations in said historical data; to obtain current asset sensor data (6b); to calculate one or more probable faults that may be present on the asset (1) based on the correlations identified in the historical data, and based on the current asset sensor data (6b); and to send said probable faults to a user output terminal associated with the given asset (1).Figure for abstract: Fig 1.

Description

Title of the invention: ASSET INSPECTION ASSISTANT Technical field

[0001] The present invention relates to systems and methods for assisting in the inspection of assets and / or identifying probable defects of an asset within a fleet of assets. More particularly, the present invention relates to systems and methods for assisting in the inspection of a vehicle and / or identifying probable defects of a vehicle within a fleet of vehicles. Context

[0002] In most countries, users of assets such as generator sets, trailers, machinery or utility vehicles are required by law and / or company policies to complete a checklist periodically or, before using an asset, to check the asset for defects. This process is extremely important for the safety of users, employees and, where the asset is a vehicle, passengers and other road users.

[0003] Currently, users perform checks based primarily on their previous experience and visible defects. This approach, however, introduces a high degree of human error. In particular, drivers of commercial vehicles are often under significant time pressure due to busy schedules. As a result, it is not uncommon for users / drivers to perform less thorough checks or skip certain checklist items in order to reduce inspection time and help them comply with the schedule. Clearly, such an approach compromises safety, and therefore there is a need to improve the means for performing asset checks. Summary of the invention

[0004] According to a first aspect of the present invention, there is provided a system for identifying probable defects of an asset within a fleet of assets, the system comprising:

[0005] one or more sensors configured to detect sensor data from assets of the asset fleet;

[0006] one or more user input devices associated with said plurality of assets configured to receive asset fleet inspection report data;

[0007] one or more user output terminals associated with said plurality of assets; and

[0008] a server device, wherein the server device is configured to:

[0009] collect historical data including: i. historical asset sensor data generated by the one or more sensors on the asset fleet; and ii. historical inspection report data from the one or more user input devices associated with the asset fleet;

[0010] using an algorithm to identify correlations in the historical data;

[0011] obtaining current asset sensor data from the one or more sensors on a given asset within the asset fleet and / or obtaining current inspection report data from a user input device associated with a given asset within the asset fleet;

[0012] calculating one or more probable defects that may be present on the given asset based on the correlations identified in the historical data, and based on the current asset sensor data and / or the current inspection report data; and

[0013] sending said one or more probable faults to a user output terminal associated with the given asset;

[0014] wherein said user output terminal is configured to display an indication of said one or more probable faults.

[0015] Asset sensor data, both historical and current, generated by one or more sensors may optionally be obtained by the server device directly from the one or more sensors. However, in preferred embodiments, the asset sensor data may be obtained by the server device from a telematics device installed on the asset or on each asset within the fleet of assets. Thus, preferably, the server device is configured to communicate with a telematics device installed on an asset within the fleet of assets to obtain current asset sensor data generated by one or more sensors on the asset. The system may thus further comprise a telematics device installed on the (or each) asset within the fleet of assets.In such embodiments, the telematics device may obtain the asset sensor data directly from the one or more sensors, or the telematics device may obtain the asset sensor device from an asset computer, installed on the asset or on each asset, which obtains the asset sensor data from the one or more sensors. Alternatively, in some embodiments, the server device may obtain the asset sensor data from an asset computer, installed on the asset or on each asset, which obtains the asset sensor data from the one or more sensors - i.e., without the need for a separate telematics device.

[0016] A telematics device as disclosed herein will be understood to include at least the electronic components necessary to activate a telematics function. The telematics device comprises a wireless transceiver arranged to communicate with the server device. As the present invention relates to a system for identifying probable faults of an asset within a fleet of assets, for example for fleet management, the assets may move independently of each other and the server device is necessarily remote from the assets. In various embodiments, the telematics device may comprise a location sensor, such as a GPS receiver (or any other global navigation satellite system (GNSS) receiver, or an equivalent location device), and a processor arranged to obtain location data based on measurements of the location sensor. Other electronic components, such as an acceleration sensor or an inertial measurement unit, may optionally be included in the telematics device.

[0017] In embodiments in which a telematics device is installed on the asset or on each asset within the fleet of assets, it will be understood that the telematics device may operate independently of the vehicle engine control unit (ECU) to obtain the asset sensor data from the one or more sensors. In some embodiments, the telematics device is a mobile device installed on the asset. In some other embodiments, the telematics device is a fixed device installed on the asset, for example, plugged into an on-board diagnostic (OBD) port (for example, when the asset is a vehicle). The fixed device may include mechanical and / or electrical mounting means (for example, to connect to power from an on-board battery).The fact that the telematics device is a fixed device means that it is not intended to be regularly removed and carried by a user in the form of a mobile device, however the fixed device may still be installable and removable rather than being a permanent part of the asset. In other words, the telematics device may be manufactured by a third party and installed on an asset subsequent to its manufacture, for example as part of a fleet management system. The telematics device is therefore distinct from on-board data computing systems installed by the manufacturer of the asset (e.g. a vehicle). In various examples, the telematics device may be one of the LINK tracking devices available from Webfleet Solutions BV.

[0018] It will be understood that using this system, potential probable defects are identified using patterns recognized in historical data of a fleet of assets, the historical data including both asset sensor data acquired from sensors on the assets in the fleet, and inspection report data detailing defects that have been reported by users in the past. Probable defects are potential defects that warrant an inspection to confirm whether Yes or no, an actual defect is present. Using this system, defects that might otherwise be missed by a human inspector, such as a user completing an asset checklist, can be identified, thereby improving safety. In addition, because the system indicates likely defects to the user, the user can focus their inspection time on checklist items that are indicated as likely to be defective, allowing them to use their limited time more efficiently, saving time without compromising safety.

[0019] Preferably, the algorithm is trained to identify correlations in the historical data. In various embodiments, the algorithm is trained to recognize correlations in the historical data from patterns detected in the historical asset sensor data and / or the historical inspection report data. In some embodiments, the algorithm is trained to look for correlations between data points in the historical asset sensor data and data points in the historical inspection report data. The algorithm can therefore detect when certain asset sensor data (such as a tire sensor reading of a vehicle) tends to occur at the same time as certain inspection report data (such as a vehicle steering malfunction).

[0020] In some embodiments, additionally or alternatively, the algorithm is trained to search for correlations in the historical inspection report data itself. For example, when searching for correlations, the algorithm may be trained to simultaneously recognize checklist items that are frequently reported as defective by a user.

[0021] In embodiments, the algorithm may be trained to look for only one of the two types of correlations discussed above. For example, the algorithm may be trained only to look for correlations between historical asset sensor data and historical inspection report data, or the algorithm may be trained only to look for correlations in the historical inspection report data.

[0022] In one set of embodiments, the displayed indication of a probable defect on the user output terminal may be in the form of an alert icon on a checklist item, or may be in the form of a written notification. In one set of embodiments, the displayed indication of a probable defect on the user output terminal may be in the form of a priority checklist item (e.g., for inspection report data). The user output terminal may decide for itself how to display the indication of a probable defect. However, as described in more detail below, it may be preferable that the user exit terminal is provided with an appropriate display model by the server device.

[0023] In some embodiments, each user input device comprises a user output terminal. In some embodiments, the user input device associated with the given asset comprises said user output terminal associated with the given asset. The user input device may be a personalized device, alternatively, the user input device may be a smartphone with an application installed thereon.

[0024] In some embodiments, the user may be presented with a predefined checklist (e.g., a template) for inspection report data that may be created based on legislation and / or corporate policy. The checklist may be ordered in any suitable manner, for example, the checklist may simply be ordered alphabetically. The predefined checklist may further be based on current asset sensor data, and correlations recognized from historical asset sensor data and historical inspection report data. Such a predefined checklist may be presented to a user at the user exit terminal before the user has started to perform an asset inspection, since no current inspection report data has been collected at that point.Each checklist item can be considered a suggested action, the suggested action being to perform an inspection of the asset component corresponding to the checklist item. The checklist for the inspection report data can be a prioritized checklist, with checklist items for the most likely and / or most severe defects presented first. The predefined checklist can be updated with new checklist items when the user enters current inspection report data, e.g., if the algorithm determines a new likely defect based on the current inspection report data, a checklist item corresponding to the likely defect can be added to the checklist.This updating of the displayed checklist for the inspection report data may occur locally at the user input device. However, it may be preferable for the user input device to require relatively little processing capacity and instead rely on the server device to update the displayed checklist for the inspection report data.

[0025] In various embodiments, the server device is configured to: select a display model from a memory of the server device based on the one or more probable faults and send the display model to the user output terminal, the display model prioritizing the display of one or more checklist items in the inspection report data based on said one or more probable defects. This means that the probable defects are not directly indicated but rather used to inform the selection of an appropriate display model for the inspection report data. Since the display model prioritizes certain checklist items in the inspection report data, a user is prompted to prioritize the entry of the most relevant inspection report data by focusing on those checklist items. Even if the user loses focus or fails to complete an inspection report, it is still likely that entering data for the prioritized checklist items will detect the probable defects.The system is therefore intelligent enough to compensate for poor user input of current inspection report data. Additionally or alternatively, in embodiments, the model prioritizes one or more checklist items based on the severity of said one or more likely defects.

[0026] According to a second aspect of the present invention, there is provided a system for assisting in the inspection of assets within an asset park, the system comprising:

[0027] one or more sensors configured to detect sensor data from assets of the asset fleet;

[0028] one or more user input / output devices associated with said plurality of assets configured to receive asset fleet inspection report data;

[0029] and

[0030] a server device, wherein the server device is configured to:

[0031] collect historical data including: i. historical asset sensor data generated by the one or more sensors on the asset fleet; and ii. historical inspection report data from the one or more user input devices associated with the asset fleet;

[0032] using an algorithm to identify correlations in the historical data;

[0033] obtaining current asset sensor data from the one or more sensors on a given asset within the asset fleet and / or obtaining current inspection report data from a user input device associated with a given asset within the asset fleet;

[0034] calculating one or more probable defects that may be present on the given asset based on the correlations identified in the historical data, and based on the current asset sensor data and / or the current inspection report data; and

[0035] selecting a display template from a memory of the server device based on the one or more probable defects and sending the display template to the user input / output device associated with the given asset, the display template prioritizing the display of one or more checklist items in the inspection report data based on the one or more probable defects.

[0036] As described above, this means that the display template received at the user input / output device can be selected to intelligently prioritize one or more checklist items for the inspection report data based on the calculated probable defects. Preferably, the user input / output device is configured to use the selected display template when the current inspection report data is entered.

[0037] The display template may be updated by the server device sending a replacement display template based on the current inspection report data and / or the current asset sensor data received. In some examples, the display template is dynamically updated by the server device when new current inspection report data is received. In some examples, additionally or alternatively, the display template is dynamically updated by the server device when new current asset sensor data is received.

[0038] The display templates stored in the memory of the server device may be updated by the algorithm, for example, periodically or continuously, based on correlations identified in the historical data and / or based on current inspection report data. For example, this means that a standard template may be updated over time to reflect inspection report data collected in the field for a given asset fleet.

[0039] In some embodiments, the server device is configured to calculate a suggested action based on the one or more probable faults, and send the suggested action to the user output terminal associated with the asset based on the one or more probable faults. The user output terminal is configured to display the suggested action. A suggested action may be an instruction to check the condition of an asset component or to take additional sensor readings. Suggested actions may also be instructions to take more immediate action such as scheduling service or maintenance, or an instruction not to use the asset.

[0040] In one set of embodiments, the server device is configured to calculate a prioritized list of suggested actions to be provided to the user output terminal based on the one or more probable faults. Such a list The user may be presented with one suggested action at a time, with the highest priority actions being presented first. Alternatively, the prioritized suggested actions may be presented together in an ordered list. The order of priority may be decided, for example, by the severity of the likely defect. For example, if a defect would render the asset unusable, or for example, if a defect with a vehicle would render the vehicle unroadworthy, then that defect would be presented first, while a minor defect that might require future maintenance but does not cause an immediate problem would be presented later.

[0041] In other embodiments, the suggested actions may be presented as a prioritized list, for example based on a selected model.

[0042] The prioritized suggested action list may be updated when the user enters current inspection report data, for example if the algorithm determines a new probable defect based on the current inspection report data and / or current asset sensor data.

[0043] In one set of embodiments, the suggested action is for the user to inspect one or more components on the asset and update the current inspection report data at the user input device.

[0044] In embodiments where an indication of a probable fault has been provided at the user output terminal, the system may request (e.g. via the user output terminal) that the user inspect the indicated probable fault, and that confirmation that said probable fault has been inspected is given to the user input device.

[0045] In a preferred set of embodiments, the user input device comprises the user output terminal.

[0046] In embodiments, one or more of the sensors is a smart sensor, and the server device is configured to instruct a smart sensor associated with an asset component related to a likely fault to provide (e.g., automatically) sensor data to the server device to verify the current status of the asset component.

[0047] The fleet of assets may be a fleet of vehicles of the same type and / or owned by the same fleet operator, such as a fleet of heavy trucks operated by a transportation company. Alternatively, the plurality of assets may consist of assets from a plurality of different fleets, e.g., operated by different companies. For example, users of the present invention may aggregate historical data of their assets into a single historical data set. In a set of embodiments where the assets are vehicles, the plurality of vehicles are all of the same vehicle type. The vehicle type may be defined, for example, in terms of categories such as motorcycles, cars, vans, minibuses, buses, ultra-light trucks, very light trucks, light trucks, medium trucks, heavy-duty trucks, and off-road trucks. Limiting the plurality of vehicles to a single vehicle type may increase the efficiency of the training process and lead to more accurate defect predictions. In some embodiments, the historical data may be collected from a plurality of vehicles of the same type but from different vehicle manufacturers. The algorithm may recognize correlations in the historical data that are independent of the vehicle manufacturer.

[0048] The asset sensor data may include data in any suitable form that is collected by sensors onboard the asset. These sensors may be an integral part of the asset or contained within a separate telematics device carried by the asset. However, in one set of embodiments, the asset sensor data includes diagnostic trouble codes (DTCs) as specified by one or more asset manufacturers to identify asset faults.

[0049] The inspection report data may include data in any suitable form that is collected from users of the asset. In a preferred set of embodiments, the inspection report data includes responses entered by the user while completing an asset inspection checklist as described above.

[0050] In one set of embodiments, the server device is configured to group the asset sensor data according to an asset component to which the asset sensor data relates. In embodiments where the asset sensor data includes DTCs, the grouping may include grouping DTCs according to the asset component to which the DTC relates.

[0051] Further, in embodiments, the server device is configured to group the inspection report data according to an asset component to which the inspection report data relates. In embodiments where the inspection report data comprises a checklist response, the grouping may comprise grouping checklist items according to the asset component to which the checklist item relates.

[0052] In embodiments, both the inspection report data and the asset sensor data are grouped according to the asset component to which the data relates, alternatively, only one of the inspection report data or the asset sensor data may be grouped as discussed above. Furthermore, the grouping step may apply only to historical data, but in a preferred set of embodiments, both the historical data (asset sensor, inspection report, or both) and the asset sensor data current (asset sensor, inspection report or both) are grouped as discussed above.

[0053] In embodiments, the requested confirmation includes the user providing further input, at the user input device, verifying the current status of an asset component related to the likely defect. These further inputs may include taking a photograph of the asset component and uploading it to the user input device. This photograph may then be automatically reviewed, or sent, by the server, to a fleet operator who can review the photograph. Alternatively, the user may be prompted to take a manual reading of a sensor or gauge related to the asset component, such as a tire pressure reading or a tread depth gauge reading, and enter the reading at the user input device.In embodiments, a reading from a sensor or gauge relating to the asset component may be taken automatically using smart sensors transferring data directly to the user input device. Such embodiments may eliminate the need for the user to perform a manual reading to verify the current status of an asset component related to a likely fault, which may save time. It is further contemplated that the user may be prompted to scan an identification code, such as a QR code or an RFID code, that is present on or near the asset component to confirm that the user has visited the location of the asset component to perform a check.In embodiments, for example in embodiments where the user input device is a smartphone, it may be possible for the user to perform such a scan directly with the user input device.

[0054] In a preferred set of embodiments, the server device is configured to add current asset sensor data and current inspection report data to the historical data; and to train the algorithm to recognize correlations in the added historical data such that the algorithm continues to learn to recognize correlations in the historical data. The current inspection report data that is added to the historical data includes inspection report data that was entered both before and after indications and / or suggested actions regarding probable defects were given.For example, when the asset is a vehicle and the asset user is a driver of the vehicle, a faulty steering inspection report can be entered, prompting the algorithm to indicate that there is likely a fault with the tires and suggest that the tires be checked. When checking the tires, the driver will enter whether they were faulty or not, and . so for the algorithm to continue learning efficiently, both steering report data (before indication) and tire report data (after indication) must be added to the historical inspection report data.

[0055] In embodiments in which a display model is selected based on the one or more identified probable defects, the models stored in the memory of the server device may be updated by the algorithm based on correlations recognized in the added historical data. The display model may therefore evolve to prioritize checklist items that are found to have the greatest correlation to the probable defects based on the added historical data.

[0056] According to another aspect of the present invention, there is provided a server for use in a system for identifying probable faults with an asset within a fleet of assets, the server being configured to:

[0057] collecting historical data, the historical data comprising:

[0058] historical asset sensor data from one or more sensors on the plurality of assets; and

[0059] historical inspection report data from one or more user input devices associated with the plurality of assets;

[0060] training an algorithm to recognize correlations in historical data;

[0061] obtaining current asset sensor data from an asset within the asset fleet and current inspection report data from a user input device associated with an asset within the asset fleet;

[0062] calculating, using the algorithm, one or more probable defects that may be present on the asset based on correlations in the historical data, and based on current asset sensor data and / or current inspection report data.

[0063] As mentioned above, it is preferable that the server is configured to obtain current asset sensor data from a telematics device installed on the asset or on each asset within the fleet of assets. In such embodiments, the server is configured to be in wireless communication with a telematics device installed on the asset or on each asset within the fleet of assets.

[0064] It will of course be appreciated that the term "server" as used herein means a computer or machine (e.g., a server device) connected to a network such that the server sends and / or receives data from other devices (e.g., computers or other machines) on that network. Additionally or alternatively, the server may provide resources and / or services to other devices on the network. The network may be the Internet or another suitable network. The server may be incorporated into any suitable type of server or server device, e.g., example a file server, an application server, a communications server, a computer server, a web server, a proxy server, etc. The server may be a single computing device or may be a distributed system, i.e., the functionality of the server may be distributed across a plurality of computing devices. For example, the server may be a cloud-based server, i.e., its functions may be distributed across many computers "on demand." In such arrangements, server resources may be acquired from one or more data centers, which may be located at different physical locations.

[0065] It will thus be understood that the processes described above which are executed by the server, can be executed by a single computing device, i.e. a single server, or by several separate computing devices, i.e. several servers. For example, all the processes can be executed by a single server which has access to all the necessary relevant information.

[0066] The one or more sensors may include one or more sensors that are an integral part of the asset, and / or one or more sensors contained within a telematics device carried by the asset. In various embodiments, the detection apparatus may include one of the LINK tracking devices available from Webfleet Solutions BV

[0067] According to another aspect of the invention, there is provided a computer-implemented method of identifying probable faults with an asset within a fleet of assets, the method comprising:

[0068] the collection, by a server device, of historical data, the historical data comprising: i. historical asset sensor data from one or more sensors on the asset fleet; and ii. historical inspection report data from one or more user input devices associated with the asset pool;

[0069] obtaining current asset sensor data using one or more sensors on a given asset within the asset fleet and / or collecting current inspection report data using a user input device associated with a given asset within the asset fleet;

[0070] calculating, using an algorithm on the server device, one or more probable defects that may be present on the given asset based on correlations in the historical data, and based on current asset sensor data and / or current inspection report data; and

[0071] providing an indication of said one or more probable faults at a user output terminal associated with the given asset.

[0072] It will be understood that this aspect may include (preferably) one or more of (e.g., all) the preferred and optional features described herein, e.g., relating to other aspects and embodiments of the invention, as appropriate. For example, the method may further comprise training, by the server device, the algorithm to recognize correlations in the historical data. For example, the method may further comprise displaying an indication of the one or more probable faults at the user output terminal associated with the given asset.

[0073] It will be understood that in each of the embodiments discussed above, reference to current asset sensor data and current inspection report data is intended to mean data that relates to the asset on which defects are currently identified, and that may be collected in real time. It will be further understood that the data that is collected in real time does not necessarily need to be sent in real time, e.g., sent from the user input device to the server, or from the one or more sensors on the asset to the server. For example, the current inspection report data may be sent as soon as it is entered at the user input device, or it may be sent only after a checklist has been completed.It will be understood that the data associated with the asset being evaluated will always be classified as current data, even if there is a delay between the data being collected and being sent to the server.

[0074] In any of the aspects and embodiments disclosed herein, the assets may be movable assets, such as vehicles or assets intended to be coupled to vehicles (e.g., trucks, cars, trailers, caravans, etc.), or non-movable assets such as machinery. In various embodiments, the assets are all registered in a remote server as part of the same fleet. As mentioned above, an asset belonging to a fleet may be distinguished from any other asset (e.g., a vehicle or a machine) by installing a telematics device therein. An asset intended to be coupled to a vehicle may not have its own telematics device but be in communication with the vehicle's telematics device.

[0075] In each of the embodiments discussed above, the assets may be vehicles and the users of said assets may be drivers of the vehicles.

[0076] The invention relates to the identification of probable faults of a vehicle within a fleet of vehicles comprising internal combustion engine vehicles, hybrid vehicles and / or electric vehicles. Brief description of the drawings

[0077] One or more non-limiting examples will now be described, by way of example only, and with reference to the appended figures in which:

[0078] [Fig-1] is a schematic overview of a system for determining probable defects with a vehicle according to an embodiment of the present invention;

[0079] [Fig.2] is a flowchart illustrating a method of determining probable faults with a vehicle according to an embodiment of the present invention;

[0080] [Fig.3] is an overview of a method of training a machine learning algorithm to determine probable faults with a vehicle according to an embodiment of the present invention;

[0081] [Fig.4] is an overview of a method of obtaining updated inspection report data;

[0082] [Fig.5] shows a checklist displayed on a driver input device;

[0083] [Fig.6] shows an input screen presented on a driver input device;

[0084] [Fig.7] shows a fault type menu presented on a driver input device;

[0085] [Fig.7a] shows a close-up of an icon from the menu of [Fig.7];

[0086] [Fig.8] shows an input screen as illustrated in [Fig.6] which has been completed with a driver;

[0087] [Fig.9] shows a checklist as illustrated in [Fig.5], but with an example indication of a probable fault displayed; and

[0088] [Fig. 10] shows a message that can be provided to the driver at the driver output terminal.

[0089] Detailed Description of Preferred Embodiments

[0090] In the illustrated embodiment, the asset is a vehicle 1 among a plurality of vehicles 1. The user of the asset is a driver of the vehicle 1.

[0091] [Fig.l] is a schematic overview showing a system 2 for identifying probable faults with a vehicle 1, and providing an indication of these faults to a driver. The vehicle 1 carries a telematics device 3 which may comprise sensors for generating data relating to the vehicle 1. For example, the telematics device 3 may comprise a location sensor, for example a GPS sensor, configured to generate position data relating to the driving of the vehicle 1. The vehicle 1 also comprises a plurality of sensors 5 which are configured to generate data relating to the condition of vehicle components. The plurality of sensors 5 may comprise, for example, tire pressure sensors, engine temperature sensors, oil pressure sensors, etc.The telematics device 3 and the plurality of sensors 5 are configured to generate current asset sensor data which, in the illustrated embodiment, is . current vehicle sensor data 6b and are capable of transmitting current vehicle sensor data 6b to a server 7, either directly or via a separate communication device (not shown).

[0092] In the current application, vehicle sensor data is defined as sensor data that contains details about a vehicle, which may include location, speed, idling time, harsh acceleration or braking, fuel consumption, and vehicle fault information such as diagnostic trouble codes (DTCs). The vehicle sensor data is generated by one or more sensors that may be connected to a vehicle data and signal bus such as a controller area network (CAN) bus.

[0093] As illustrated, the server 7 is located remotely and externally to the vehicle 1. The telematics device 3 may be any device capable of collecting vehicle sensor data. For example, it may be a mobile device, for example a cell phone or a tablet, carried by a driver of the vehicle 1. Alternatively, the telematics device 3 may be a device connected to or integral with the vehicle 1. For example, the telematics device 3 may be connected to an on-board diagnostic (OBD) port of the vehicle 1. The telematics device 3 may be temporarily, or permanently, installed on the vehicle 1. In some examples, the telematics device 3 may comprise one of the LINK tracking devices available from Webfleet Solutions BV. The plurality of sensors 5 may be integral with the vehicle 1.

[0094] The server 7 comprises a processor 9 and a memory 11 which store a computer product comprising computer-executable instructions for performing at least part of a method of calculating probable faults with the vehicle 1. The processor 9 may comprise one or more processing devices, for example several processing devices arranged in series or in parallel. The method of identifying probable faults with the vehicle 1 is shown in [Fig.3] and described in more detail below. The server 7 may comprise a computer-readable medium on which an algorithm is stored.

[0095] The system 2 further comprises a user input device associated with the asset, which in turn comprises a user output terminal. In the illustrated embodiment, the user input device is a driver input device 13 associated with the vehicle 1, which in turn comprises a driver output terminal 15. The driver output terminal 15 is used to provide calculated probable fault indications to a driver, as well as recommended actions. The driver input device 13 is configured to accept inputs from the driver such as current inspection report data 14b relating to the vehicle 1 and is capable of transmitting current inspection report data 14b, as well as other input data, to the server 7, either directly or via a separate communication device (not shown). The driver input device 13 may be remote from the server 7, and may be a driver's smartphone. Although the driver input device 13 is shown here as a separate device from the telematics device 3, a combined device may be provided.

[0096] The system further comprises a plurality of assets which, in the illustrated embodiment, is a fleet of vehicles 8, having a plurality of telematics devices 12 which may themselves each comprise sensors for generating data relating to the fleet of vehicles 8. For example, the plurality of telematics devices 12 may each comprise a location sensor, for example a GPS sensor, configured to generate position data relating to the driving of each vehicle 1 in the fleet of vehicles 8. Each vehicle 1 in the fleet of vehicles 8 also comprises a plurality of sensors 10, which are configured to generate fleet-wide data relating to the condition of one or more vehicle components. The pluralities of sensors 10 may comprise, for example, tire pressure sensors, engine temperature sensors, oil pressure sensors, etc.The telematics devices 12 and the pluralities of sensors 10 are configured to generate historical asset sensor data (which, in the illustrated embodiment, is historical vehicle sensor data) 6a. In this example, the telematics devices 12 are capable of wirelessly transmitting the historical vehicle sensor data 6a to the server 7. The system further includes a plurality of user input devices associated with the plurality of assets, which in the illustrated embodiment are a plurality of driver input devices 16 associated with the fleet of vehicles 8, configured to accept driver inputs such as historical inspection report data 14a on the fleet of vehicles 8.The plurality of driver input devices 16 are capable of transmitting historical inspection report data 14a, as well as other input data, to the server 7, either directly or via a separate communication device (not shown).

[0097] The system 2 also includes a fleet operator output terminal 17 which is used to provide fault indications to a fleet operator, enabling him to make decisions regarding the technical inspection of the vehicle 1 or to schedule maintenance. The server 7 is configured to receive current inspection report data 14b, as well as other input data, from the driver input device 13, and to send the received data to the fleet operator output terminal 17. The data sent to the fleet operator output terminal 17 may include current inspection report data 14b, additional driver notes, photographs and / or sensor readings.

[0098] It will be understood that the vehicle 1 may be included in the fleet of vehicles 8, and / or that the driver input device 13 associated with the vehicle 1 may be included in the plurality of driver input devices 16.

[0099] The plurality of sensors 10 on the vehicle fleet 8 transmit historical vehicle sensor data 6a to the same remote server 7, and the plurality of driver input devices 16 associated with the vehicle fleet 8 transmit historical inspection report data 14a to the same remote server 7. Such a system 2 is therefore used to calculate probable faults with a vehicle 1 based on historical vehicle sensor data 6a and historical inspection report data 14a from multiple vehicles in a fleet. In the illustrated embodiment,

[0100] [Fig.2] is a flowchart illustrating a method 20 for identifying probable faults with the vehicle 1. The method 20 may for example be executed by the system 2 described above, for example it may be partially executed by the server 7, for example by the processor 9 of the server 7. In step 22, historical data is collected from the vehicle fleet 8, which may be a plurality of vehicles 1 in a fleet. The historical data includes historical vehicle sensor data 6a obtained from the vehicle fleet 8, for example via the telematics devices 12 and / or directly from the pluralities of sensors 10, and historical inspection report data 14a obtained from the plurality of driver input devices 16.

[0101] In step 24, the algorithm is trained on the historical data using known machine learning techniques such as those described in Collaborative Deep Learning for Recommender Systems by Wang et al (https: / / arxiv.org / pdf / 1409.2944.pdf) to recognize correlations in the historical data. [Fig. 3] illustrates a training method 33 whereby the algorithm is trained using historical data that includes historical vehicle sensor data 6a obtained from the telematics devices 12 and / or the pluralities of sensors 10 on the fleet of vehicles 8, and historical inspection report data 14a obtained from the plurality of driver input devices 16 associated with the fleet of vehicles 8. The data set must be of a significant size and collected over a significant period of time to be considered historical data.For example, a suitable set of historical data might be collected from a fleet of 20 vehicles over a 6-month period. Alternatively, a suitable set of historical data might be collected from a fleet of 10 vehicles over a 12-month period.

[0102] The historical data may contain data associated with vehicles of a common type, possibly a common manufacturer, or a common model. A non-exhaustive list of vehicle types may include: motorcycles, cars, vans, minibuses, buses, ultra-light trucks, very light trucks, light trucks, medium trucks, heavy trucks, and off-road trucks. In some examples, it may be advantageous to limit the historical data to which the algorithm is exposed to a single vehicle type, manufacturer, and / or model to ensure that the calculated probable faults are as relevant and as accurate as possible. The disadvantage of such a limitation is the reduction in the size of the historical data set because more limits are imposed on the properties of the plurality of vehicles 1.For users who have a fleet of vehicles large enough to provide a usable historical data set, the historical data may include only data from their fleet of vehicles. Alternatively, where a user does not have a large fleet of vehicles, the historical data set may include data associated with vehicles from a plurality of different fleets.

[0103] In the illustrated embodiment, the algorithm is trained to search for two types of correlations. In step 37, the algorithm is trained to search for correlations between historical vehicle sensor data 6a and historical inspection report data 14a. The historical vehicle sensor data 6a may be in the form of diagnostic trouble codes (DTCs), commonly referred to as "trouble codes." These trouble codes may be generated by the sensors 10 or reported directly by the OEM integrations. The historical inspection report data 14a may be in the form of checklist responses submitted by drivers. Thus, when searching for correlations, in step 37, the algorithm may be trained to recognize which DTCs are frequently present when specific checklist items are reported as defective by a driver.As part of training to recognize which DTCs are frequently present with specific checklist items, the algorithm is provided with a mapping matrix to group the DTCs according to the specific vehicle components to which the DTC relates. This mapping matrix may be predefined and static, or the mapping matrix may be adaptable (e.g., based on fuzzy logic, certain probability-based rules, learning algorithms, etc.). Table 1 below shows an example of grouping DTCs according to the vehicle components to which they relate according to a mapping matrix. It will be understood that a “vehicle component” may be any physical component involved in the operation of the . vehicle, whether separate (e.g. tires) or distributed (e.g. coolant and engine oil).

[0104] [Tables 1] Trouble Codes Reported by LINK Device (Can be Read from OBD or CAN) Corresponding Vehicle Component / Checklist Item • Exhaust Related Trouble Codes • P2463: Particulate Filter Restriction - Soot Accumulation Bank 1 • P246C: Particulate Filter Restriction - Forced Limited Power Bank 1 509 • P2BAC NOx Overshoot - EGR Disable 890 • P0420: Catalytic System Efficiency Below Threshold (Bank 1) • P0430: Catalytic System Efficiency Below Threshold (Bank 2) • Exhaust • P0700: Transmission Control System Malfunction • P0702: Electric Transmission Control System • Engine / Clutch • P00B7 Engine Coolant Flow • Engine Coolant Low / Engine Performance • P0195 Engine Oil Temperature Sensor Malfunction • PO 196 Engine Oil Temperature Sensor Range / Performance • PO 197 Engine Oil Temperature Sensor Low • P0198 Engine Oil Temperature Sensor High • Engine Oil • P0460 Fuel Level Sensor Circuit Malfunction • P0461 Fuel Level Sensor Circuit Range / Performance • P0462 Fuel Level Sensor Circuit Low Input • P0463 Fuel Level Sensor Circuit High Input • P0464 Fuel Level Sensor Circuit Intermittent • Fuel Level • BS, 1094,Different tires (circumference) mounted on one axle • Unexpected accelerometer reading from axles • Tires • Faulty electrical connection • P0562 OBD-II: System Voltage Low Diagnostic Trouble Code (DTC) • P0561 - System Voltage - Unstable • P0560 - System Voltage Malfunction • Battery / Electrical Circuit , • P0563 - System Voltage - high • Unexpected cooldowns • Defective charging cable

[0105] Further, a similar approach of a mapping matrix may be applied to the historical inspection report data 14a. In embodiments where the historical inspection report data 14a is in the form of checklist responses, the checklist items are generally grouped according to the specific vehicle components to which they pertain. These groupings may streamline the training process.

[0106] Once the groupings are applied to the historical vehicle sensor data 6a and / or the historical inspection report data 14a, the algorithm is allowed to train itself to look for correlations between the two sets of data 6a, 14a. In this first type of correlation (step 37), the algorithm is trained to recognize which checklist items are frequently reported with certain DTCs. An example of this first type of correlation, given below, is a correlation being recognized between the DTC "BS, 7300, Rear axle axle modulator is faulty" and the checklist item "Tires". Another example of this first type of correlation is a correlation being recognized between a trouble code relating to a voltage drop at a particular electrical circuit connection or the absence of an electrical signal, and a given vehicle component on the checklist. Example checklist items

[0107] - External vehicle components • Tires • Exhaust • Windshield • Headlights - Daily vehicle checks • Brakes • Fuel level • Engine / clutch • Direction - Weekly vehicle checks • Engine oil • Engine coolant • Brake fluid • Power steering fluid • Battery / electrical circuit

[0108] Additionally, or alternatively, in step 39, the algorithm is trained to search for correlations in the historical inspection report data 14a itself. Thus, when searching for this second type of correlations, in step 39, the algorithm may be trained to simultaneously recognize checklist items that are frequently reported as defective by a driver. An example of this second type of correlation, given below, is a recognized correlation between the checklist items "Tires" and "Steering".

[0109] Referring again to [Fig. 2], in step 26, current vehicle sensor data 6b is obtained from the vehicle 1. In the present application, the current vehicle sensor data 6b is defined as discussed above. This current vehicle sensor data 6a may comprise a list of diagnostic trouble codes (DTCs). The current vehicle sensor data 6a may be obtained from one or both of the telematics device 3 and the plurality of sensors 5. In step 28, the algorithm calculates whether there are any probable faults that may be present on the vehicle 1 based on the current vehicle sensor data 6b. The algorithm is capable of making this calculation based on the correlation training performed on the historical data in step 37 of the training method of [Fig. 3].

[0110] Alternatively or additionally, in step 30, current inspection report data 14b is obtained from the driver input device 13 associated with the vehicle 1. This current inspection report data 14b may include checklist responses submitted by a driver at the driver input device 13. In step 32, the algorithm determines whether there are any probable defects that may be present on the vehicle 1 based on the current inspection report data 14b. The algorithm is capable of performing this calculation based on the correlation training performed on the historical inspection report data in step 37 and / or step 39 of the training method 35 of [Fig. 3].

[0111] If the algorithm does not identify any probable faults, then no action regarding the fault indication is given. If probable faults are identified in one or both of steps 28 and 32, then an indication is provided and / or a suggested action is provided in step 33, for example an indication at the conductor output terminal 15.

[0112] In some examples, the method 20 may include obtaining current vehicle sensor data 6b from a vehicle 1 in step 26, and calculating whether there are any probable faults that may be present based on the current vehicle sensor data 6b in step 28, but does not include obtaining current inspection report data 14b from a driver input device 13 associated with the vehicle 1 in step 30, or calculating whether there are any probable defects that may be present based on the current inspection report data 14b in step 32. This may occur in situations before the driver has started to perform an inspection of the vehicle, and thus has not yet entered current inspection report data 14b at the driver input device 13.

[0113] In other examples, the method 20 may include obtaining current inspection report data 14b from a driver input device 13 associated with the vehicle 1 in step 30, and calculating whether there are any probable defects that may be present based on the current inspection report data 14b in step 32, but does not include obtaining current vehicle sensor data 6b from a vehicle 1 in step 26, or calculating whether there are any probable defects that may be present based on the current vehicle sensor data 6b in step 28.

[0114] In some examples, the method 20 may include obtaining current vehicle sensor data 6b from a vehicle 1 in step 26, and calculating whether there are any probable defects that may be present based on the current vehicle sensor data 6b in step 28, and also includes obtaining current inspection report data 14b from a driver input device 13 associated with the vehicle 1 in step 30, and calculating whether there are any probable defects that may be present based on the current inspection report data 14b in step 32.

[0115] In various examples, the probable defects are checklist items (e.g., as defined by local legal requirements), and the suggested action is to perform a check of the vehicle component related to the checklist item.

[0116] The method 20 will now be explained in more detail by means of two examples.

[0117] A first example follows steps 22—>24—>26—>28—>33. In step 22, historical data is collected as discussed above. In step 24, the algorithm is trained to recognize correlations in the historical data, including correlations between historical vehicle sensor data 6a and historical inspection report data 14a. In an example of this first type of correlation, the historical vehicle sensor data 6a is in the form of DTCs, and the historical inspection report data 14a is in the form of checklist entries. In this training step, the algorithm recognizes a correlation between the DTC “BS, 7300, The modulator axle modulator is faulty” and an inspection report of a fault with the tires. This correlation is likely to be present because the axle modulator modulates the wheel braking pressure on the axle, and therefore if the axle modulator is faulty, the wheels may be braked unevenly, causing uneven tire wear. In step 26, the current vehicle sensor data 6b is obtained from vehicle 1, and the DTC “BS, 7300, The rear axle axle modulator is faulty” is present in the current vehicle sensor data 6b. Therefore, in step 28, the algorithm identifies that there is a likely fault with the tires based on the DTC that is present in the current vehicle sensor data 6b.At step 33, an indication is provided to the driver at driver output terminal 15 that there is a probable fault with the tires, and a suggested action is provided which, in this example, is to perform a tire inspection.

[0118] A second example follows steps 22—>24—>30—>32—>33. In step 22, historical data is collected as discussed above. In step 24, the algorithm is trained to recognize correlations in the historical data, including correlations in the historical inspection report data 14a. In an example of this second type of correlation, the historical inspection report data 14a is in the form of checklist entries. In this training step 24, the algorithm recognizes a correlation between a checklist entry of a defect with the steering, and a checklist entry of a defect with the tires. This correlation may be present because underinflated front tires can make the steering feel heavy, or uneven inflation between the front tires can cause the steering to pull to the left / right.In step 30, current inspection report data 14b is obtained from the vehicle 1, and a checklist entry reporting a fault with the steering is present in the current inspection report data 14b. Accordingly, in step 32, the algorithm identifies that there is a probable fault with the tires based on the checklist entry that is present in the current inspection report data 14b. In step 33, an indication is provided to the driver at the driver output terminal 15 that there is a probable fault with the tires, and a suggested action is provided which, in this example, is to perform a tire inspection.

[0119] [Fig.4] shows method steps associated with indicating probable faults to a driver, and continuously training the algorithm. In step 41, indications of the probable faults and resulting suggested actions are provided to the driver at the driver output terminal 15. In step 43, the driver output terminal 15 is configured to request that the driver update current 14b inspection report data based on suggested actions. If the driver output terminal 15 has indicated to the driver that there is likely a defect with a vehicle component, and has suggested the action of performing a check on the vehicle component, the driver output terminal 15 will request that the driver confirm that they have performed a check on the component, and update the current inspection report data 14b to confirm whether or not a defect was identified by the driver. This confirmation may be provided by means of a checkbox and / or the driver may be required to provide a signature to confirm that they have performed the inspection. Further, in embodiments, the driver may be requested to upload a photograph of the vehicle component being checked to the driver input device.In embodiments, an identification code (such as a QR code) may be present on or near the vehicle component that the driver will need to scan with the driver input device 13 to confirm that they have checked the vehicle component. Further, it is contemplated that the driver may be asked to take a manual reading of a sensor or gauge associated with the checklist item to verify whether or not a fault is present. In such embodiments, it may be necessary for the driver to take a reading from a sensor or gauge and manually enter the reading into the driver input device 13.Additionally or alternatively, where there are connected smart sensors installed on the vehicle 1, for example smart tire pressure monitoring system (TPMS) sensors, it may be possible for the server device to automatically request further readings from the smart sensors. For example, where a smart sensor is associated with a vehicle component related to a probable fault, the server device may request further readings from that sensor to verify whether or not a fault exists for that vehicle component. Alternatively, it may be necessary for the driver to take a reading directly from the smart sensor using the driver input device 13, for example by initiating a wireless connection between the driver input device 13 and the smart sensor.

[0120] In step 45, the updated current inspection report data 14b, which will indicate whether or not the indicated probable defect corresponded to an actual defect that was identified by the driver, is sent to the server 7 which adds the data to the historical data. The current vehicle sensor data 6b is also added to the historical data by the server 7. As such, the algorithm may continue to learn from the updated current inspection report data 14b that is input by the driver in response to suggested actions, suggested by the algorithm. In embodiments, the updated current inspection report data 14b and / or the vehicle sensor data. Current 6b data are grouped using a mapping matrix, as discussed above, before being added to the historical data.

[0121] [Fig. 5] illustrates a checklist presented to a driver at the driver output terminal 15. In the illustrated embodiment, a smartphone 50 provides both the driver input device 13 and the driver output terminal 15, and the checklist is provided to the driver by means of an application that is installed on the smartphone 50.

[0122] [Fig. 6] illustrates an input screen presented to the driver on the smartphone 50. This input screen allows the driver to update the current inspection report data 14b, either as part of a regular statutory inspection or in response to a suggested action to perform an inspection of a vehicle component and update the current inspection report data 14b. Three options are presented to the driver, a "Not Applicable" icon 61 which can be used when the inspection is not applicable, for example if the checklist item is for a trailer and the current vehicle is not carrying a trailer, a "Defect" icon 63 which the driver will use to indicate that a defect is present with the checklist item, and an "OK" icon 65 which the driver will use to indicate that they have completed an inspection of the checklist item and have not identified a defect.Other inputs are also available to the driver.

[0123] If the driver indicates that a fault is present by selecting the fault icon 63, then in a preferred set of embodiments, the driver must enter the fault type using the "Fault Type" bar 67. Selecting the "Fault Type" bar 67 takes the driver to a "Fault Type" menu 70 shown in [Fig. 7] which contains a plurality of predefined possible faults 71, as well as an "Other" option 73 which can be used when the fault present is not contained in the predefined possible faults. The driver must select which of the predefined faults 71 is present using the check boxes 72, and confirm their selection with the confirmation icon 75. It can be seen in [Fig. 7] that some of the predefined faults have a non-roadworthy icon 74.Predefined faults marked with this icon 74 are of unroadworthy severity and will result in the vehicle being considered unroadworthy. [Fig.7a] shows the unroadworthy icon 74 in close-up view.

[0124] By limiting the driver input (the inspection report data) to a list of predefined defects 71, the process of identifying probable defects is streamlined. If the inspection report data were limited to indicating that there was a defect with a checklist item, i.e., a defect with the tire, but did not contain information about the nature of the defect, then the probable defects calculated by the algorithm would be less accurate. Furthermore, if the driver were able to provide details about the defect without constraints, and these details were added to the inspection report data, then the method 20 would have to contain some sort of interpretation step before the algorithm could look for correlations relating to the inspection report data.

[0125] Referring again to [Fig. 6], options are provided to the driver to add a note relating to the defect in a note entry area 68, and to add an image of the vehicle component linked to the checklist item using an image entry option 69. For the reasons discussed above, in the current embodiment, these additional details will not be included in the current inspection report data 14b which is sent to the server 7 to be added to the historical data, but may be sent to a fleet operator, via the server 7, or via any other suitable means, and displayed on a fleet operator terminal 17 so that the fleet operator can carry out a further check, schedule maintenance or book servicing of the vehicle if necessary.

[0126] [Fig. 8] shows an input screen as illustrated in [Fig. 6] that has been completed by a driver. In the illustrated example, the checklist item is engine oil, the driver has indicated that there is a defect by selecting the defect icon 63, indicated that the defect type is a minor leak by selecting the minor leak option from the predefined defects 71, added a note 81 to check for leaks in the note entry area 68, and added an image 83 of the defect using the image entry option 69.

[0127] [Fig. 9] shows a checklist as shown in [Fig. 5], but with an example of indicating a probable defect given by means of a warning icon 91. The warning icon 91 informs the driver that there is a probable defect calculated with the visibility checklist item, and the driver will be prompted to inspect this item carefully, or to prioritize this checklist item over other checklist items. The checklist seen in [Fig. 9] may be displayed according to a display template selected at the server 7, based on the calculated probable defect(s), and sent to the smartphone 50. This is the display template that prioritizes the display of the “Visibility” checklist item on the first page of the inspection report and adds the warning icon 91.A different display template may be selected and sent to the smartphone 50, or the display template may be updated, based on the calculated probable fault(s) and their associated checklist items.

[0128] Indications and suggested actions may be provided to the driver via the driver output terminal 15 in various forms, such as messages that may appear as notifications. [Fig. 10] shows an example of a message 100 that may be provided to the driver at the driver output terminal 15. The message 100 contains an indication portion 101 that provides the indication to the driver, and a suggested action portion 102 that provides the suggested action to the driver. In the case of the message 100, this message may be presented to the driver at the driver output terminal 15 in step 33 of the second example discussed above in connection with [Fig. 2]. The method has calculated based on the current inspection report data 14b containing a report of a fault with the steering that there is a probable fault with the tire pressure, and therefore the suggested action is to check the pressure. It can therefore be seen from [Fig.10] that the indication part 101 of the message 100 indicates “this could be related to the tires”, and the suggested action part 102 of the message 100 indicates “Please check the pressure”.

[0129] In the illustrated embodiments, the indication is given to the driver in the form of an icon or as part of a notification message, but those skilled in the art will understand that the indication could be provided in any suitable manner. In embodiments, a priority checklist may be presented to the driver at the driver output terminal 15, the priority checklist ordering the checklist items according to whether a probable fault has been identified with the checklist item, and further according to the severity of the probable fault. In such an embodiment, checklist items with calculated probable faults that would result in the vehicle 1 being deemed unroadworthy may be presented to the driver first. Suggested actions may likewise be provided in any suitable manner.

[0130] In the illustrated embodiment, the historical data is continually updated with updated current inspection report data 14b obtained from the driver input device 13. It is contemplated that, in embodiments, the historical data may also be updated with data related to the fleet manager's actions, so that the algorithm can learn how the fleet manager responds to defects, and can adapt its suggested actions accordingly. For example, if the fleet manager always schedules maintenance in response to a particular defect, the algorithm may present scheduling maintenance as the suggested action when that defect is identified and confirmed by the driver.

[0131] Further, in the illustrated embodiment, the historical data includes historical vehicle sensor data 6a and inspection report datahistorical data 14a, but in embodiments, it is contemplated that other data may be present in the historical data that may be taken into account by the algorithm. For example, the algorithm may take into account data from a vehicle manufacturer that may contain common faults with a particular model of vehicle. The algorithm may therefore provide an indication of said common fault to the driver, and / or instruct the driver to pay particular attention to or check the commonly faulty checklist item more frequently. Additionally or alternatively, the data may include geographic data.For example, if vehicle 1 is operating in an area where roads are known to be of poor quality, then the algorithm may provide an indication to the driver that defects are more likely with the tires and suspension, and / or instruct the driver to pay special attention to or check more frequently the checklist items corresponding to the tires and suspension.

[0132] In any of the embodiments described above, the historical vehicle sensor data 6a and the historical inspection report data 14a may comprise data collected for at least 6 months from a plurality of vehicles consisting of 20 vehicles. The time interval over which the historical data is collected may depend on the number of vehicles in the plurality of vehicles, and the typical usage of the plurality of vehicles and how their usage varies over time.

[0133] While the invention has been described in detail in connection with only a limited number of embodiments, focusing on the case where the assets in question are vehicles, it should be readily understood that the invention is not limited to these disclosed embodiments, and the assets could be any asset on which it is necessary to perform usage controls. The invention may be modified to incorporate any number of variations, alterations, substitutions, or equivalent arrangements not heretofore described, but which are commensurate with the scope of the invention. In addition, although various embodiments of the invention have been described, it should be understood that aspects of the invention may include only some of the described embodiments.Accordingly, the invention should not be construed as limited by the foregoing description, but is limited only by the scope of the appended claims.

Claims

Claims

1. A system (2) for identifying probable faults with an asset (1) within a fleet of assets (8), the system comprising: - one or more sensors (5, 10) configured to detect sensor data of assets (6b, 6a) of the asset fleet (8); - one or more user input devices (13, 16) associated with said plurality of assets (8) configured to receive inspection report data (14b, 14a) from the fleet of assets (8); - one or more user output terminals (15) associated with said plurality of assets (8); and a server device (7), wherein the server device is configured to: • collect historical data including: i. historical asset sensor data (6a) generated by the one or more sensors (10) on the asset fleet (8); and ii. historical inspection report data (14a) from the one or more user input devices (16) associated with the asset pool; • use an algorithm to identify correlations in historical data; • obtaining current asset sensor data (6b) from the one or more sensors (5) on a given asset (1) in the asset fleet (8) and / or obtaining current inspection report data (14b) from a user input device (13) associated with a given asset (1) within the asset fleet (8); • calculate one or more probable defects that may be present on the given asset (1) based on the correlations identified in the historical data, and based on the current asset sensor data (6b) and / or the current inspection report data (14b); and • sending said one or more probable faults to a user output terminal (15) associated with the given asset (1), wherein said user output terminal (15) is configured to display an indication of said one or more probable faults.

2. System (2) according to claim 1, wherein the user input device (13) associated with the given asset (1) comprises said user output terminal (15) associated with the given asset (1).

3. The system (2) of claim 1 or claim 2, wherein the server device (7) is configured to: select a display template from a memory (11) of the server device (7) based on said one or more probable defects and send the display template to the user output terminal (15), wherein the display template prioritizes the display of one or more checklist items in the inspection report data based on said one or more probable defects.

4. The system (2) of claim 3, wherein the server device (7) is configured to dynamically update the display model as new current inspection report data (14b) and / or current asset sensor data (6b) is received.

5. System (2) according to any preceding claim, wherein the server device (7) is configured to calculate a suggested action based on said one or more probable faults, and send the suggested action to the user output terminal (15), and wherein the user output terminal (15) is configured to display the suggested action.

6. The system (2) of claim 5, wherein the server device (7) is further configured to calculate a prioritized list of suggested actions to be provided to the user output terminal (15) based on said one or more probable faults.

7. A system (2) according to claim 5 or claim 6, wherein the suggested action is for the user to inspect one or more components on the asset (1) and update the current inspection report data (14b) at the user input device (13).

8. A system (2) according to any preceding claim, wherein one or more of the sensors (10, 5) is a smart sensor, and the server device (7) is configured to instruct a smart sensor associated with an asset component related to a probable fault to provide sensor data to the server device (7) in order to check the current status of the asset component.

9. A system (2) according to any preceding claim, wherein the plurality of assets is a plurality of vehicles which are all of the same vehicle type.

10. A system (2) according to any preceding claim, wherein the asset sensor data comprises diagnostic trouble codes as specified by one or more asset manufacturers to identify asset faults.

11. A system (2) according to any preceding claim, wherein the server device (7) is configured to: - group the asset sensor data according to an asset component to which the asset sensor data relates; and / or - group the inspection report data according to an asset component to which the inspection report data relates.

12. A system (2) according to any preceding claim, wherein the server device (7) is configured to use the algorithm to identify correlations between historical asset sensor data (6a) and historical inspection report data (14a).

13. A system (2) according to any preceding claim, wherein the server device (7) is configured to use the algorithm to identify correlations in the historical inspection report data (14a).

14. A computer-implemented method for identifying probable faults with an asset (1) within a fleet of assets (8), the method comprising: - collecting, by a server device (7), historical data, the historical data comprising: i. historical asset sensor data (6a) from one or more sensors (10) on the fleet of assets (8); and ii. historical inspection report data (14a) from one or more user input devices (16) associated with the fleet of assets (8); - obtaining current asset sensor data (6b) using one or more sensors (5) on a given asset (1) within the asset fleet (8) and / or collecting current inspection report data (14b) using a user input device (13) associated with a given asset (1) within the asset fleet (8); - calculating, using an algorithm on the server device (7), one or more probable defects that may be present on the given asset (1) based on correlations in the historical data, and based on the current asset sensor data (6b) and / or the current inspection report data (14b); and providing an indication of said one or more probable faults at a user output terminal (15) associated with the given asset (1).

Images