Method for maintaining a vehicle

Abstract

Aspects of the present invention relate to a computer-implemented method (400) for maintaining a vehicle (100), the method comprising the steps of obtaining (410) data indicative of a plurality of maintenance plans (331-338), each maintenance plan defining a predetermined event and at least one associated maintenance action, receiving (420) first vehicle data (340) from a vehicle (100), determining (430), in dependence on the first vehicle data (340), an occurrence of an event associated with at least one of the plurality of maintenance plans (331-338) and selecting the at least one associated maintenance plan (334) in dependence thereon, outputting (440) maintenance data (350) to cause the at least one associated maintenance action defined by the selected maintenance plan (334) to be performed upon the vehicle (100), receiving second vehicle data (360) from the vehicle (100), determining (450), in dependence upon the second vehicle data (360), that the at least one maintenance action has been performed upon the vehicle (100), and monitoring (460), for a re-occurrence of the event associated with the selected maintenance plan (334).

Description

[0001] Method for Maintaining a Vehicle

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to maintaining a vehicle Aspects of the invention relate to computer implemented methods, to a vehicle, and to computer readable instructions for performing a method.

[0004] BACKGROUND

[0005] It is known that complex machines, such as vehicles, require maintenance. It can be inconvenient for a user when a vehicle requires maintenance in that the vehicle may be unavailable for a period of time when it is required to visit a maintenance location for the maintenance to be carried out. Furthermore, it is often desired to ensure that the maintenance performed on the vehicle has addressed an issue with the vehicle or has reduced a likelihood of an issue arising.

[0006] It is an aim of the present invention to address one or more of the disadvantages associated with the prior art.

[0007] SUMMARY OF THE INVENTION

[0008] Aspects and embodiments of the invention provide a computer-implemented method, and vehicle as claimed in the appended claims.

[0009] According to an aspect of the present invention there is provided a computer-implemented method for maintaining a vehicle, the method comprising the steps of receiving vehicle data from a vehicle, determining, in dependence on the first vehicle data, an occurrence of an event associated with at least one of a plurality of maintenance plans, each maintenance plan defining a predetermined event and at least one associated maintenance action, and selecting the at least one associated maintenance plan in dependence thereon, outputting maintenance data to cause the at least one associated maintenance action defined by the selected maintenance plan to be performed upon the vehicle, determining, in dependence upon the vehicle data, that the at least one maintenance action has been performed upon the vehicle, and monitoring, for a re-occurrence of the event associated with the selected maintenance plan. Advantageously, the maintenance action is performed according to the maintenance data which assists in ensuring that the appropriate maintenance action is performed. Advantageously, it is determined using the vehicle data that the maintenance action has been performed. Advantageously re-occurrence of the event associated with the selected maintenance plan is monitored.

[0010] According to an aspect of the present invention there is provided a computer-implemented method for maintaining a vehicle, the method comprising the steps of obtaining data indicative of a plurality of maintenance plans, each maintenance plan defining a predetermined event and at least one associated maintenance action, receiving first vehicle data from a vehicle, determining, in dependence on the first vehicle data, an occurrence of an event associated with at least one of the plurality of maintenance plans and selecting the at least one associated maintenance plan in dependence thereon, outputting maintenance data to cause the at least one associated maintenance action defined by the selected maintenance plan to be performed upon the vehicle, receiving second vehicle data from the vehicle, determining, in dependence upon the second vehicle data, that the at least one maintenance action has been performed upon the vehicle, and monitoring, for a re-occurrence of the event associated with the selected maintenance plan. Advantageously, the maintenance action is performed according to the maintenance data which assists in ensuring that the appropriate maintenance action is performed. Advantageously, it is determined using the second vehicle data that the maintenance action has been performed, which assists in checking that the maintenance action has been successfully performed. Advantageously reoccurrence of the event associated with the selected maintenance plan is monitored to determine if the maintenance action has ameliorated the event. Optionally at least one maintenance plan defines at least one condition associated with the event. Advantageously, occurrence of the event in the presence of the condition may be determined. The at least one maintenance plan may define a plurality of conditions associated with the event. Advantageously, occurrence of the event in the presence of the plurality of conditions may be determined. The at least one condition optionally comprises one or more communication signals occurring at the vehicle. Advantageously the one or more communication signals may be used to determine the occurrence of the event. Where there are a plurality of communications signals, these may occur within a period of time defined in the maintenance plan. Advantageously the occurrence of temporally-related communication signals may be indicative of the event. The period of time may be a duration of time within which the signals are considered to be related Optionally the maintenance data comprises data indicative of an output to be provided to a user of the vehicle.

[0011] The output may be user notification provided via user interface of vehicle The notification is optionally indicative of a user performed maintenance action. Advantageously the user may be informed or notified to undertake the maintenance action, which may reduce a period of time for which the vehicle is unavailable.

[0012] The first vehicle data may be generated prior to the maintenance action being performed The second vehicle data may be generated after the maintenance action has been performed. Advantageously the second vehicle data may be used to determine an effectiveness of the maintenance action on the vehicle. The second vehicle data may be received over a period of time. Advantageously the reoccurrence of the event may be monitored over the period of time. The period of time may be a plurality of days The determining that the maintenance action has been performed upon the vehicle and the monitoring for the re-occurrence of the event may be performed sequentially or at least partly simultaneously. Advantageously flexibility for different types of event is provided.

[0013] Optionally at least one of the plurality of maintenance plans defines at least one condition associated with the respective event. The monitoring for the re-occurrence of the event may comprise determining whether the event re-occurs in the presence of the condition. Advantageously diagnosis of the event is improved by being able to determine whether the one or more conditions are present without the event re-occurring.

[0014] The method may comprise determining whether the at least one condition occurs during a predetermined number of communication sessions. A session may be a predetermined number of data sessions The method may comprise determining whether the at least one condition occurs over a period of time. The method may comprise determining whether the at least one condition occurs over number of uses of the vehicle. The uses of the vehicle may be a number of vehicle starts or power mode changes. Advantageously the re-occurrence of the event may be monitored for over a significant extent of use of the vehicle.

[0015] Optionally each maintenance plan defines a use extent of the vehicle. The monitoring for the re-occurrence of the event may comprise monitoring for the re-occurrence of the event over the use extent. Advantageously the use extent improves the monitoring for the reoccurrence.

[0016] The use extent optionally comprises one or more of a use duration, a use distance or number of uses of the vehicle or a feature of the vehicle. The monitoring for the re-occurrence of the event may comprise monitoring for the re-occurrence of the event over the use duration, use distance or number of uses of the vehicle or a feature of the vehicle. The use duration may be a period of time. Advantageously the use extent may be defined in various ways appropriate to the event. The outputting of the maintenance data optionally comprises communicating the maintenance data to the vehicle to cause the maintenance action to be performed at the vehicle. Advantageously a need for the vehicle to be taken to a maintenance location is reduced. Advantageously the maintenance action may be performed at the vehicle in dependence on the maintenance data. The maintenance data may be received by a processor at the vehicle to cause the processor to perform the maintenance action. Advantageously a need for manual intervention is reduced.

[0017] The maintenance data is optionally indicative of an instruction to perform software installation at the vehicle The determining that the maintenance action has been performed may comprise determining that the software installation has been completed. Advantageously the software for execution at the vehicle may be installed. The software installation may be a software update. The method may comprise receiving an indication that the software installation has been completed. Advantageously the software executing at the vehicle may be updated.

[0018] The maintenance data may be indicative of an instruction to perform a calibration process at the vehicle. The determining that the maintenance action has been performed may comprise determining that the calibration process has been successfully completed.

[0019] Advantageously the calibration process may reduce a likelihood of the even occurring.

[0020] The outputting the maintenance data optionally comprises communicating the maintenance data to another computer system to cause the maintenance action to be performed upon the vehicle. Advantageously the another computer system is provided with an indication of the maintenance action for the vehicle. The method may comprise receiving an indication of the maintenance action having been performed upon the vehicle. Advantageously it is confirmed that the maintenance action has been performed.

[0021] The method may comprise receiving an indication that the event associated with the selected maintenance plan has not re-occurred. Advantageously it can be determined that the maintenance action has reduced a likelihood of the event re-occurring.

[0022] The method may comprise receiving an indication that the event associated with the selected maintenance plan has not re-occurred within a use extent of the vehicle. The use extent may comprise a use duration, use distance or number of uses of the vehicle or a feature of the vehicle. Advantageously the vehicle may experience a variety of use conditions whilst the monitoring is performed.

[0023] The method may comprise storing an indication of the maintenance action having been performed upon the vehicle. The method may comprise storing an indication that the event associated with the selected maintenance plan has not re-occurred. Advantageously the stored data allows selection of a maintenance plan to be responsive to prior maintenance actions.

[0024] The method optionally comprises outputting an indication in dependence on determining that the maintenance action has not been performed upon the vehicle, or determining that the event associated with the selected maintenance plan has re-occurred.

[0025] Advantageously notification is provided. The indication may be provided to a user. The user may be a user of a maintenance computer system. The output is optionally an alert. Advantageously appropriate action may be taken.

[0026] Optionally at least one of the plurality of maintenance plans comprises vehicle qualifying data indicative of a set of one or more vehicles with which the maintenance plan is associated. The method may comprise determining whether the vehicle is within the set of one or more vehicles. Advantageously maintenance plans may be responsive to one or more attributes of each vehicle The vehicle qualifying data may comprise a unique vehicle identifier. The unique vehicle identifier may be vehicle identification number, VI N . Advantageously a maintenance plan may be provided for a specific vehicle.

[0027] The vehicle qualifying data may comprise data indicative of one or more of a vehicle model, a vehicle age or age range, and one or more vehicle features. Advantageously a maintenance plan may be provided for groups of vehicles.

[0028] The vehicle qualifying data optionally comprises an indication of at least one maintenance plan having been previously performed with respect to the vehicle. Advantageously a maintenance plan may be defined as subsequent to a prior maintenance plan.

[0029] The vehicle qualifying data optionally comprises an indication of an unsuccessful validation operation associated with the at least one maintenance plan. Advantageously a maintenance plan may be provided to address a prior maintenance plan unsuccessfully addressing an event at the vehicle. The predetermined maintenance plan may relate to the same event as the selected maintenance plan.

[0030] The method may be performed by a rules engine executing on the computer. The rules engine is optionally arranged to store state information indicative of the vehicle and the maintenance plan. Advantageously the rules engine supports stateful operation.

[0031] Optionally the rules engine is arranged to store information indicative of a number of iterations of the maintenance action having been performed upon the vehicle. Advantageously the number of iterations of the maintenance action can be controlled, such as limited to avoid wasting resources. The method may comprise determining whether the number of iterations of the maintenance action having been performed upon the vehicle is equal to or greater than a threshold. If the number is equal to or greater than the threshold then the maintenance action may not be performed further on the vehicle.

[0032] The rules engine may be arranged to store information indicative of a number of iterations of the monitoring for a re-occurrence of the event associated with the selected maintenance plan. Advantageously the monitoring may be controlled.

[0033] According to an aspect of the present invention there is provided a vehicle comprising a communication module and one or more processors, wherein the one or more processors are arranged to communicate, via the communication module, first vehicle data to a computer system, the first vehicle data indicative of an event occurring at the vehicle, receive, via the communication module, maintenance data from the computer system, perform a maintenance operation in dependence on the maintenance data, communicate, via the communication module, second vehicle data to the computer system, the second vehicle data being indicative of performance of the maintenance operation and re-occurrence of the event at the vehicle.

[0034] According to an aspect of the present invention there is provided computer readable instructions which, when executed by one or more processors, cause the one or more processors to perform the method according to an aspect of the invention.

[0035] According to an aspect of the present invention there is provided a system, comprising a computer system and a vehicle, wherein the computer system is arranged to receive first vehicle data from a vehicle, determine, in dependence on the first vehicle data, an occurrence of an event associated with at least one of a plurality of maintenance plans each maintenance plan defining a predetermined event and at least one associated maintenance action, select at least one associated maintenance plan in dependence thereon, output maintenance data to cause the at least one associated maintenance action defined by the selected maintenance plan to be performed upon the vehicle, receive second vehicle data from the vehicle, determine, in dependence upon the second vehicle data, that the at least one maintenance action has been performed upon the vehicle, and monitor, for a re-occurrence of the event associated with the selected maintenance plan.

[0036] Within the scope of this application it is expressly intended that the various aspects, embodiments, examples and alternatives set out in the preceding paragraphs, in the claims and / or in the following description and drawings, and in particular the individual features thereof, may be taken independently or in any combination. That is, all embodiments and / or features of any embodiment can be combined in any way and / or combination, unless such features are incompatible. The applicant reserves the right to change any originally filed claim or file any new claim accordingly, including the right to amend any originally filed claim to depend from and / or incorporate any feature of any other claim although not originally claimed in that manner.

[0037] BRIEF DESCRIPTION OF THE DRAWINGS

[0038] One or more embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0039] Figure 1 shows a vehicle according to an embodiment of the invention;

[0040] Figure 2 shows a computer system according to an embodiment of the invention;

[0041] Figure 3 shows a system according to an embodiment of the invention;

[0042] Figure 4 shows a method according to an embodiment of the invention;

[0043] Figure 5 shows a method according to an embodiment of the invention;

[0044] Figure 6 illustrates a maintenance plan store storing a plurality of maintenance plans according to an embodiment of the invention;

[0045] Figure 7 shows a method according to an embodiment of the invention; and Figure 8 shows a method according to an embodiment of the invention.

[0046] DETAILED DESCRIPTION

[0047] A vehicle in accordance with an embodiment of the present invention is described herein with reference to the accompanying Figure

[0048] 1 As shown in Figure 1 , the vehicle 100 is a land-going i.e. wheeled vehicle, although it will be appreciated that embodiments of the present invention may be used with any type of vehicle such as aircraft and watercraft. Embodiments of the present invention may also be useful with any type of machine. The vehicle 100 shown in Figure 1 is a passenger vehicle 100 having a plurality of wheels, although embodiments of the invention may be used with goods vehicles e.g. heavy goods vehicles or other types of vehicles such as aircraft and watercraft.

[0049] Figure 2 illustrates a computer system 200 which hosts i.e operatively executes a rules engine 240 according to an embodiment of the invention. The computer system 200 is illustrated in Figure 3 in a system 300 according to an embodiment of the invention which is used to perform or initiate a maintenance operation on the vehicle 100.

[0050] The computer system 200 as illustrated in Figure 2 comprises processing means 210 and memory means 220. The processing means 210 may be one or more electronic processing device 210 or processors 210 which operably executes computer-readable instructions. The memory means 220 may be one or more memory device 220 or memory 220 The memory 220 is electrically coupled to the processing means or processor 210 The memory 220 is configured to store instructions, and the processor 210 is configured to access the memory 220 and execute the instructions stored thereon. The memory 220 may also store data for operation on by a process executing on the processor 210. It will be understood that the computer system 200 may be implemented by more than one processor 210 and memory 220. In particular, the computer system 200 may be implemented as cloud computer system using a plurality of processors and memories e.g. where a method performed by the computer system is performed by the plurality of processor acting together, as will be understood.

[0051] The computer system 200 comprises a communication means 230. The communication means 230 may comprise an electrical input / output 230 of the computer system 200. The communication means 230 may comprise a wired or wireless communication interface 230 of the computer system 200. In one embodiment, the communication means 230 may be a network interface 230 of the computer system 230. The network interface 230 may communicably connect the computer system 200 to a wired network via which the computer system communicates communicate with a wireless telecommunications network to communicate data 235 with the vehicle 100 as illustrated in Figure 3. In other embodiments, the network interface 230 may communicate directly with a wireless network such as WiFi or a telecommunications network e.g. implemented by a telecommunications standard such as LTE, 4G, 5G, 6G etc. The network interface 230 may also allow the computer system 200 to communicate data with one or more other computer systems 310, 320 or data storage devices or storage systems such as hosting a data store e g. a database, to retrieve and / or store data therein. In particular, as illustrated in Figure 2, the computer system 200 is communicably coupled with at least one data store. In the illustrated embodiment the computer system 200 is arranged to communicate data with a maintenance plan store 250 and a maintenance state store 260 with it being understood that this is merely illustrative and that any number and structure of data stores is envisaged. The computer system 200 may store and retrieve data from the one or more data stores 250, 260 as will be explained Furthermore, as illustrated in Figure 3, the computer system 200 is communicable in some embodiments with at least on other computer system 310, 320. As will be explained, a first computer system 310 may be a user computer 310 and a second computer system 320 may be a diagnosis computer system 320

[0052] With reference to Figure 3, the computer system 200, hereinafter maintenance computer 200, is configured to receive 235 data from the vehicle 100, as will be explained. The maintenance computer 200 may also communicate 235 data to the vehicle 100. The maintenance computer 200 is arranged to perform or cause a maintenance operation of the vehicle 100 in dependence on the received 235 data. The diagnosis computer system 320 may be a computer system which is present at a maintenance location for the vehicle 100, such as a vehicle garage which may be associated with the manufacturer of the vehicle 100, or for example as a portable computer which may be carried by a technician performing diagnosis on the vehicle 100 When the vehicle 100 is at the maintenance location it may be communicably coupled with the diagnosis computer system 320 such as via a local or short range communication network e g. Bluetooth, WiFi or the like, or alternatively the vehicle 100 may be coupled to the diagnosis computer system 320 via a wired data connection, such as via a diagnostic port of the vehicle 100 The diagnosis computer system 320 may communicate data from the vehicle 100 to the maintenance computer system 200 and vice versa, as will be explained.

[0053] The maintenance computer 200 may receive data from the vehicle 100 periodically or substantially in real-time. In the described embodiment, the maintenance computer 200 is arranged to receive data from the vehicle periodically corresponding to a session. A session may be understood as a period of use of the vehicle 100 and the data communicated to the maintenance computer 200 corresponds to data generated during the session i.e for a period of use. Data for that session may be referred to as a data session i.e. a block of data for that session. For example, the vehicle 100 may communicate data in response to a predetermined event occurring such as a change in power state of the vehicle 100, which may be an engine of the vehicle 100 being stopped or a power mode of the vehicle 100 changing to stopped in the case of a hybrid or electric vehicle. In other embodiments data may be communicated from the vehicle 100 to the maintenance computer 200 periodically i.e at predetermined time intervals such as 5, 10 or 30 minute intervals as examples which do not restrict the present invention. The data communicated from the vehicle 100 to the maintenance computer 200 may be referred to as vehicle data 340 as illustrated in Figure 3. The vehicle data 340 may be communicated from the vehicle 100 to the maintenance computer 200 via a wireless communication module of the vehicle 100 such as supporting telecommunication using e.g. LTE, 4G, 5G, 6G or similar telecommunication protocols. In other instances, the vehicle data 340 may be communicated from the vehicle 100 to the maintenance computer 200 via the diagnosis computer 320.

[0054] The vehicle data 340 comprises identification data identifying the vehicle 100. The identification data may provide unique identifying information for the vehicle, such as a Vehicle Identification Number (VIN) or registration number associated with the vehicle 100. In some embodiments, the vehicle data 340 may comprise an identification of one or both a manufacturer and a model of the vehicle 100. For example, the vehicle data 340 may identify the vehicle as being produced by a certain manufacturer and being a specific production model. It will be appreciated that in some embodiments the manufacturer may be omitted since the maintenance computer 200 may only support one manufacturer’s vehicles. In some embodiments the vehicle data 340 may comprise an indication of one or more features of the vehicle 100, such forming part of a manufactured specification of the vehicle 100 i e. optional extras on the vehicle 100. In other embodiments, the maintenance computer 200 may use the unique identifying information to obtain data relating to the features from a data store providing the manufactured specification of the vehicle 100.

[0055] The vehicle data 340 may provide an indication of a status of one or more systems, modules or components of the vehicle 100. The vehicle data may comprise an indication of any fault or diagnostic signals, such as codes, generated at the vehicle 100. The vehicle data 340 may comprise one or more Diagnostic T rouble Codes (DT Cs) generated by systems, modules or components. A DTC provides an indication of a fault or error at the vehicle 100 where the DTC identifies an origin and type of fault. The vehicle data 340 may comprise one or more Diagnostic IDs (DIDs) providing diagnostic information for the vehicle 100. The vehicle data 340 may provide an indication of data communicated on a communication bus or network of the vehicle i.e. an indication of network signals on the vehicle 100 i.e. vehicle signals. The data communicated about the vehicle may comprise an indication of routine signals occurring on the communication bus or network i.e. not specifically relating to an identified fault. Data relating to such signals may assist with preemptively identifying faults or errors, or for diagnosing a cause of identified faults or errors. When communicated periodically, the vehicle data 340 may relate to i.e. encompass signals generated during a period of time since last communication of vehicle data 340 to the maintenance computer 200 The received vehicle data 340 is provided to the rules engine 240 at the maintenance computer 200.

[0056] As shown in Figure 3, the maintenance computer 200 is communicable with at least one other computer, computer system 310. The first computer system 310 in the illustrated system of Figure 3 is a user computer which is arranged to provide a user interface allowing a maintenance plan for the vehicle 100 to be defined. It will be appreciated that in other embodiments the user interface may be provided by the maintenance computer 200 In either embodiment, data indicative of a maintenance plan 330 is provided to the maintenance computer. A maintenance plan defines an event, such as a set of one or more signals, which may occur at the vehicle 100 and at least one associated maintenance action to be performed responsive to the event, as will be explained.

[0057] The user interface allows the user to define the maintenance plan. Advantageously, the user interface is arranged so that the user is not required to, for example, understand a programming language to define the maintenance plan. The user interface provides an interface through which the maintenance plan can be defined using, for example, in some embodiments one or more of menus, menu items, check boxes and drop -down menus. In this way the user is able to create a maintenance plan via the user interface in a convenient manner.

[0058] A user operates the user interface, such as provided at the user computer 310, to define one or more vehicle qualifying criteria with which the maintenance plan is associated. The vehicle qualifying criteria define a set of one or more vehicles with which the maintenance plan is associated. The vehicle qualifying criteria may comprise a unique vehicle identifier, such as the VIN number of the vehicle 100. In other examples, the vehicle qualifying criteria comprises an indication of one or more of a vehicle model, a vehicle age or age range, and one or more vehicle features to which the maintenance plan relates. The vehicle qualifying criteria may comprise an indication that the associated maintenance plan relates to vehicles for which an identified (previous) maintenance plan has failed one or both of verification and validation. The vehicle qualifying criteria may define that the associated maintenance plan relates to any vehicles for which validation has failed a specified number of times e.g. once, twice or more validation failure. In this way, the associated maintenance plan is defined as being a subsequent maintenance plan for the previous maintenance plan when both relate to the same event. Data indicative of the vehicle qualifying criteria, vehicle qualifying data, forms a part of the maintenance plan 330. In this way it is advantageously possible for a maintenance plan to be defined which only relates to some i.e. a subset of vehicles, such as from a vehicle manufacturer

[0059] The user interface 310 further allows the user to define the event to which the maintenance plan 330 relates. An event is an occurrence at the vehicle 100 with which the maintenance plan 330 is associated. The event has a unique signature which can be detected as having occurred at the vehicle 100. The occurrence of the event may be the identification of a fault at the vehicle 100, such as indicated by a module (for example) generating a fault code e.g. a specific DTC. In this example, the maintenance plan 330 defines a maintenance action to be performed to address the fault code. However it will be appreciated that it is not necessary that a fault is identified at the vehicle 100 as the maintenance plan 330 may relate to a set of circumstances or conditions which may be indicative of a potential fault developing with the vehicle 100. The event may be defined to comprise at least one condition or, in some examples, a plurality of conditions. The one or more conditions may be identified with respect to the DID provided as part of the vehicle data 340.

[0060] A condition may comprise, for example, a measurement at the vehicle 100 e.g. a temperature reading such as engine or motor temperature, air pressure, vehicle distance from another vehicle, suspension movement or other conditional measurement as will be envisaged by the skilled person. A condition may comprise one or more communication signals occurring at the vehicle. For example, a communication signal may be defined as being indicative of a request at the vehicle, such as a request for headlights to be turned on, a torque request, window opening request or other signals as may be exchanged between components on the communication or network of the vehicle 100. Where there are a plurality of communications signals defined as part of the maintenance plan 330, these may occur defined to occur within a period of time defined in the maintenance plan 330 i.e. to test for simultaneous events at the vehicle 100. The maintenance plan comprises event data defining the event to which the maintenance plan 330 relates. The event data defines the signature of the event such that the signature may be identified in the vehicle data provided by the vehicle 100. The event signature may comprise one or more of a fault code, such as a DTC, and one or more other signals or conditions such as one or more vehicle signals and / or one or more DID values.

[0061] In this way, the event at the vehicle 100 to which the maintenance plan relates is defined by the user at the user computer 310 in some embodiments. It will also be appreciated that the maintenance plan 330 may be generated by an automated process, such as using a machine learning model on training data providing an indication of one or more maintenance actions required by one or more vehicles and vehicle signals etc at those vehicles. The maintenance plan 330 is defined to comprise at least one maintenance action to be performed upon the vehicle. Each maintenance action is an action to be performed to address the event described above which relates to a fault or pre-emptively identified potential fault with the vehicle 100. The maintenance action may comprise requesting additional data from the vehicle 100, or providing a request to provide information to a user of the vehicle 100. The maintenance action may be a performed in an automated process at the vehicle 100 For example, the maintenance action may be to update software or firmware at the vehicle 100, to perform a calibration process or to change a configuration e.g. to disable a sensor or to switch to a backup sensor or system at the vehicle 100 Thus the maintenance action may not require any human intervention at the vehicle 100. In some examples, the maintenance action comprises an associated maximum process count which defines a maximum number of times the maintenance action should be performed. The maximum process count is provided to reduce a risk of, or prevent, a maintenance action being repeatedly performed on the vehicle 100 when it is seemingly unsuccessful at preventing the even occurring. In other examples, the maintenance action may be user-performable at the vehicle 100. A user-performable maintenance action may be to refill or replace a consumable at the vehicle 100, such as washer fluid or to replace a user-replaceable part such as a filter In such examples the maintenance action may be to cause an output to be provided to the user, such as displayed upon a display at the vehicle 100 or on a user device associate with the vehicle 100 or audibly output, to guide the user to perform the maintenance action In other examples, the maintenance action may be to replace hardware at the vehicle 100, such as to replace a module, system or component of the vehicle 100 For example, the maintenance plan 330 may define that the event is to be addressed by replacing a sensor at the vehicle 100. Data indicative of the at least one maintenance action i.e. maintenance data 350 is output by the maintenance computer 200 to cause the at least one associated maintenance action defined by the maintenance plan to be performed upon the vehicle 100. The maintenance data 350 may be communicated to the vehicle 100, e g. via a telecommunication network, to the diagnosis computer system 320 or to another computer system for performing, or causing to be performed, the maintenance action.

[0062] The maintenance plan 330 is defined to comprise a verification for the maintenance action having been performed upon the vehicle 100. The verification may comprise a test for the maintenance action having been performed, such as to compare an ID of a software or hardware component updated or replaced as part of the maintenance action. For example, the verification may comprise comparing identifying information of the software or hardware component, which may comprise a serial number, part number, IP address of the software or hardware component, e.g. a serial number of a body control module (BCM), prior to the maintenance action with the serial number of the BCM after performing the maintenance action. The verification is advantageously defined to ensure or check that the maintenance action has been successfully performed. In this way, it can be verified that a correct maintenance action has been performed (such as updating or replacement of the correct part) and that the maintenance action has been correctly performed. It can be appreciated that in order to verify the maintenance action further vehicle data 340 may be required from the vehicle 100 i.e. data subsequent to the maintenance action. The maintenance plan 330 comprises verification data defining the verification for the maintenance action. The verification for the maintenance action may comprise an indication of a duration over which the verification of the maintenance action should be performed. Where the vehicle data 340 is provided periodically, such as at an end of each session or at periodic intervals, the vehicle data 340 may define a number of sessions over which the verification should be attempted, whilst in other embodiments the verification may indicate a temporal duration e.g. number of days over which the verification should be attempted. If the verification is not completed indicating that the maintenance action has been successful within the defined duration then the verification may be completed indicating that the maintenance action cannot be verified as having been performed successfully.

[0063] The maintenance plan 330 is defined to comprise a validation for the event. The validation comprises one or more tests which allow reoccurrence of the event associated with the maintenance plan 330 to be validated. The maintenance plan 330 comprises validation data defining the validation for the maintenance action. That is, the validation may be validation that the maintenance action has successfully addressed the event associated with the maintenance plan 330. For example, successful validation may be a determination that the fault with the vehicle 100 has not re-occurred. The validation may be performed over a use extent, where the extent may be a use duration i.e. a period of time, a use distance e.g. travel distance of the vehicle 100, or a usage of the vehicle 100 defined in other ways such as a number of starts or power mode transitions of the vehicle 100, or the extent may be may be defined with respect to a particular feature of the vehicle 100 such as operation of an air conditioning system or otherfeature of the vehicle 100. The validation comprises monitoring for a re-occurrence of the event associated with the maintenance plan. For example, the validation may comprise monitoring for re-occurrence of a fault, such as identified by generation of a fault code or DTC, at the vehicle 100. The monitoring may be performed over the period use extent, such as the duration or distance of use defined as part of the validation. The use duration may be defined as a number of hours or days e.g. 14 or 30 days, a use distance as e.g. 1000km or numbers of uses of the vehicle 100 or feature. The validation may be defined as comprising at least one condition associated with the respective event. The condition may be the same one or more conditions described above associated with the event. For example, determining whether a measurement e.g. of temperature meets one or more thresholds, or whether one or more vehicle signals occur at the vehicle 100. In other examples, the validation may utilise a different event signature, for example which encompasses other potential indications of the issue corresponding to the original event. The validation may indicate that if the one or more conditions are not met at the vehicle 100, then the maintenance action cannot be verified. In other words, if successful addressing of the event leading to the maintenance action cannot be achieved, then the validation is not successful. Where such one or more conditions are specified, the monitoring for the re-occurrence of the event comprises determining whether the event re-occurs in the presence of the condition. In some examples, once the one or more conditions are met or satisfied, such as a temperature being above a value defined as part of the condition e.g. 80°C, the validation may comprise beginning the monitoring for the event over the use extent e.g. use duration and / or use distance of the vehicle 100.

[0064] The maintenance plan 330 may be stored in a data structure for convenient exchange between computers, such as computers which, for example, use different operating systems. The data structure or file may be a human-readable file which allows a user to review the maintenance plan. A file storing the maintenance plan 330 may be language-independent. In one embodiment the maintenance plan 330 may be stored in a JSON data format, although it will be appreciated that this is merely an example. The maintenance plan 330, when created at the user computer 310, is communicated via one or more data communication networks to the maintenance computer 200 such that the maintenance computer 200 and rules engine 240 obtaining data indicative of each maintenance plan 330, where each maintenance plan 330 defines a predetermined event and at least one associated maintenance action

[0065] As noted above, the maintenance computer 200 is arranged to communicate data with a maintenance plan store 250. The maintenance computer 200 stores each obtained maintenance plan 330 in the maintenance plan data store 260 Thus, as illustrated in Figure 6 a plurality of maintenance plans 331, 332, 333, 334, 335, 336, 337, 338, hereinafter maintenance plans 331-338, are stored over time in the maintenance plan data store 250 for accessing by the rules engine 240. The rules engine 240 is arranged to determine whether the vehicle 100 experiences an event corresponding to one or more of the maintenance plans 331-338 with reference to the vehicle data 340 received from the vehicle 100.

[0066] The maintenance state store 260, with which the maintenance computer 200 is arranged to communicate data, is used to store state data corresponding to each vehicle 100 enabling the rules engine 240 to operate in a stateful manner. The state data indicates whether maintenance plans have been implemented or executed with respect to the vehicle 100 and a result of those one or more maintenance plans. In this way, the rules engine 240 is able to implement maintenance plans on each vehicle in a progressive or structured manner. I n one embodiment, the maintenance state store 260 is arranged to store identifying information of any vehicles to which a maintenance plan 330 has been implemented, and identifying information of those one or more maintenance plans 330. The vehicle identifying information may be the VIN of each vehicle 100. The identification of the one or maintenance plans 330 may be a name or other identifying information associated with each maintenance plan 330. In some embodiments, the maintenance state store 260 stores information identifying a number of times each maintenance plan 330 has been executed or implemented with respect to the vehicle 100. The information identifying the number of times may be referred to as a process count, which has a value which is incremented each time the respective maintenance plan 330 is executed. A maintenance plan 330 may define a maximum number of times the plan is to be executed with respect to a particular vehicle 100. The maximum number may be referred to as a process count threshold, which may adopt integer values. The process count threshold may be used to prevent the maintenance plan 330 being executed repeatedly or excessively. In some embodiments, the maintenance state store 260 stores an indication of a number of times or period of time for which verification and / or validation has been attempted with respect to the vehicle 100 and whether one or both of verification and validation has been completed successfully or has failed for the vehicle 100 as will be explained. In some embodiments, the maintenance state store 260 is arranged to store at least part of the vehicle data 340 associated with the vehicle 100. The vehicle data 340 may be a portion associated with the event For example, the maintenance state store 260 may store an indication of one or more vehicle signals e.g one or more DID values associated. Advantageously storing the vehicle data 340 allows later comparison with the same vehicle data at a later point in time e g. during validation.

[0067] Figure 4 illustrates a method 400 according to an embodiment of the invention. The method 400 is a method of maintaining a vehicle 100, such as the vehicle 100 illustrated in Figure 1 In particular, the method 400 is a computer-implemented method of maintaining the vehicle 100. The method 400 may be performed by the computer system 200 i.e. the maintenance computer system 200 as illustrated in Figure 2. The memory 220 may comprise computer-readable instructions which, when executed by the processor 210, perform the method 400 according to an embodiment of the invention. The method 400 may be performed particularly by the rules engine 240 operating on the maintenance computer system 200 The method 400 is arranged to determine, using the vehicle data 340 received from the vehicle 100, an occurrence of one or more predetermined events at the vehicle and in dependence thereon causes one or more associated maintenance actions to be performed on the vehicle 100. The method 400 determines, or verifies, that the one or more maintenance actions have been performed on the vehicle 100 and monitors for re-occurrence of a predetermined event.

[0068] The method comprises a block 410 of obtaining data indicative of a plurality of maintenance plans 330. As described above, each maintenance plan defines a predetermined event and at least one associated maintenance action for that event Each maintenance plan 330 may be defined at the user computer 310 and data indicative of the maintenance plan 330 received at the maintenance computer 200, or may be defined at the maintenance computer 200. Data indicative of each maintenance plan 330 is obtained by the rules engine 240 and stored at the maintenance plan store 250. Thus the maintenance plan store 250 is caused to store the plurality of maintenance plans 331-338 (see Figure 6). At least some of the maintenance plans 331-338 may relate to the same event, such as the same fault at the vehicle 100, whilst other maintenance plans may relate to one or more different events, such as different faults the vehicle 100. Furthermore, since the maintenance plans 331 -338 may comprise vehicle qualifying data identifying one or more vehicles to which each maintenance plan relates, such as a group or individual vehicles, the maintenance plans 331-338 may relate to specific groups of one or more vehicles e.g. models, age ranges or individual vehicles The rules engine 240 is arranged to analyse received vehicle data 340 to identify whether an event associated with at least one of the plurality of maintenance plans 331-338 has occurred at one or more vehicles 100. When an event defined by at least one of the plurality of maintenance plans 331-338 in the maintenance plan store 250 is identified, the rules engine 240 is arranged to select the at least one associated maintenance plan 330. As illustrated in Figure 6, the maintenance plan 334 is indicated as being a selected one of the plurality of maintenance plans 331 - 338.

[0069] The method 400 comprises a block of receiving 420 first vehicle data 340 from a vehicle e.g. the vehicle 100 shown in Figures 1 and 2. It will be appreciated that in practice vehicle data 340 from a plurality of vehicles is received and each processed according to the method 400 For ease of illustration operation of the method 400 with respect to the one vehicle 100 is described The first vehicle data 340 is the vehicle data 340 used to determine an occurrence of an event, for example to diagnose a fault occurring at the vehicle 100, or to pre-emptively identify circumstances occurring at the vehicle 100 which may lead to a fault occurring or are otherwise undesirable. The vehicle data 340 may be wirelessly received from the vehicle 100 or via another device or computer system such as the diagnosis computer system 320.

[0070] The method 400 comprises a block 430 of determining an occurrence of an event associated with at least one of the plurality of maintenance plans 340 and selecting the at least one associated maintenance plan. The block 430 is explained in more detail with reference to Figure 5. If no event is detected in the vehicle data 340, a current iteration of the method 400 follows 432 to block 480, as discussed below. If, however, an event corresponding to at least one maintenance plan 330 is detected with respect to the vehicle data 340, the method follows 431 to block 440.

[0071] Figure 5 illustrates method blocks 510, 520, 530 which may be performed in block 430 in some embodiments of the invention.

[0072] In some embodiments, block 430 as illustrated in Figure 5 comprises a block 510 of determining whether the vehicle 100 from which the vehicle data is received is a qualifying vehicle with respect to each of the maintenance plans 330 Block 510 is arranged to determine whether each maintenance plan is relevant to the vehicle 100, and to select those relevant maintenance plans.

[0073] As discussed above, some of the plurality of maintenance plans comprise vehicle qualifying data which indicates a set of one or more vehicles with which the maintenance plan 330 is associated. For example, the qualifying data may indicate a model of qualifying vehicle or a specific qualifying vehicle identified e.g. by the vehicle’s VI N. Block 510 comprises comparing the identification data in the vehicle data 340 against the qualifying data to determine if the vehicle meets the qualifying criteria. For example, comparing whether the VIN provided in the identification data is the same as a VIN in the qualifying data In some embodiments of block 510 it may be determined with respect to the maintenance state data whether the vehicle 100 has e.g. failed validation with respect to a previous maintenance plan identified in the vehicle qualifying data. For example, the vehicle qualifying data may indicate that the associated maintenance plan is relevant to vehicles having had the previous maintenance plan executed in relation to the vehicle, but having failed validation. In this way, the associated maintenance plan is defined as being the subsequent maintenance plan in the case of validation failure.

[0074] Consider, as an example, an event relating to a forward radar sensor of the vehicle 100. The event may, for example, relate to a condition where the radar is generating a number of object tracking errors exceeding a predetermined threshold For this condition, first and second maintenance plans are defined and stored in the maintenance plan store 260. For example, MP1 e.g maintenance plan 331 may define an associated maintenance action of installing a latest version of a software module associated with the radar sensor, whilst MP2 e g. maintenance plan 332 defines an associated maintenance action of performing a calibration process on the radar sensor. As part of the qualifying data for MP2 332 a qualifying condition for the vehicle 100 is defined that it has failed validation associated with MP1 331. Effectively this makes MP2 332 a subsequent maintenance plan for MP1 331 to be used where the maintenance action associated with MP1 331 has not been validated as successful for the associated event i.e. generating the object tracking errors

[0075] If the vehicle 100 is a qualifying vehicle with respect to a maintenance plan 330, the method follows path 514 moves to block 520. If the vehicle 100 is not a qualifying vehicle with respect to the maintenance plan 330, the current iteration of block 510 may progress via path 515 and end at block 540. It will be appreciated that the blocks shown in Figure 5 are repeated for each of the plurality of maintenance plans in the maintenance plan store 250 to thereby assess whether any maintenance plans are relevant to the vehicle 100 and to select those maintenance plans.

[0076] In some embodiments as illustrated in Figure 5, block 510 comprises a sub-block 511 of determining whether a model of vehicle identified in the identification data from the vehicle data 340 corresponds to a model of vehicle identified in the qualifying data from the maintenance plan 330. The model of vehicle may comprise one or more of a model, which may be identified with manufacturer’s model code, e.g. X760, an engine variant, which may be identified with an engine variant code, e.g. A321 -D4 (as an example, other formats etc are envisaged), one or more model year’s e.g. 2014 and 2015 and / or other attributes of the vehicle 100 such as the presence of hardware or software on the vehicle, the presence of features e.g. optional features on the vehicle. It will be appreciated that other specifications of the vehicle 100 may be considered to determine whether the vehicle is relevant Thus, sub-block 511 may identify a set of vehicles to which each maintenance plan 330 applies. If the vehicle 100 is the model to which the maintenance plan relates, the method may progress via path 512 to block 513 If not, the method follows path 515 and ends.

[0077] In some embodiments, block 510 may comprise a sub-block 513 of determining whether the vehicle 100 has one or more features to which the maintenance plan is relevant. Each vehicle feature may be identified by a feature code e.g. the qualifying data may define that the maintenance plan is relevant to vehicle’s having features 34488 or 34551 . Identification of the features of the vehicle may be provided as part of the vehicle data 340, or the rules engine 240 may look up the features of the vehicle 100 from which the vehicle data 340 originated e.g. by consulting a manufacturer’s database to retrieve the features of that vehicle, which are then compared against the one or more features identified by the qualifying data of the maintenance plan. If the vehicle has features matching those one or more features of the maintenance plan, the method follows path 514 to block 520. Thus block 510 determining whether the vehicle 100 from which the vehicle data is received is within the set of one or more vehicles identified by each maintenance plan. Only maintenance plans which are relevant to the vehicle 100 are selected in block 510

[0078] As an example, of the plurality of maintenance plans 331-338 stored in the maintenance plan store 250, only some of those maintenance plans 331-338 are expected to be relevant to a particular vehicle 100, with the others relating to e.g other models of vehicle etc. By executing block 510 with respect to each of the plurality of maintenance plans 331-338 and the vehicle data 340 from the vehicle 100, one or more relevant maintenance plans 334 are selected (thus being one or more selected maintenance plans 334) and the method progresses to block 520. If a maintenance plan does not comprise qualifying data, then it may be deemed to be relevant to all vehicles, such as all vehicles of a manufacturer, and those maintenance plans be selected.

[0079] Block 520 comprises determining whether an event associated with at least one of the plurality of maintenance plans 331-338 is identified at the vehicle 100. That is, in some embodiments, whether any of the events associated with the one or more maintenance plans identified by block 510 has occurred at the vehicle 100. The determination may be accomplished by having an instance of the method operating for each of the plurality of maintenance plans 331-338. In this way, each method instance is responsible for determining whether the respective maintenance plan should be executed in dependence on the received vehicle data 340. In this way, when the vehicle data 340 is indicative an event associated with one of the plurality of maintenance plans 331-338, the associated maintenance plan 334 is selected by virtue of its method instance Each of the plurality of method instances may be performed independently and may be in different states at any point in time. If an event is identified as having occurred at the vehicle 100, the corresponding one or more maintenance plans are selected in block 520 In block 520 if it determined that there has not been an event at the vehicle 100 corresponding to any of the maintenance plans 331-338, the method follows path 525 to block 540 where the method ends. If it is determined in block 520 that an event corresponding to one or more of the maintenance plans 331-338 has occurred at the vehicle 100, those one or more maintenance plans are selected and the method follows path 523 to block 530.

[0080] In some embodiments, block 520 comprises a sub-block 521 of comparing the event signature associated with each of the plurality of maintenance plans 331-338 against the vehicle data 340. If the event signature matches the vehicle data 340, or the vehicle data 340 is determined to fall within the event signature (such as within one or more values specified as the event signature), the method moves to block 530. For example, where the event data of a maintenance plan defines a condition of a DI D, such as a temperature or pressure, being greater than or equal to a particular value e.g. DID F361 >=0.25, it is determined whether the vehicle data 521 comprises a DID meeting the condition. Similarly, the event data may define the event comprising a fault code such as a DTC value of NULL or not equal to one or more values e.g. P006A-85 OR P2279-64. The event data may define the event signature utilising Boolean logic to comprise one or more conditions e.g. DIDs and / or DTCs The event signature may be defined to comprise any signals or data which may be obtained from the vehicle 100 communication bus or network which may be indicative of an issue with the vehicle 100. If the vehicle data 340 meets the requirements of the event data, e.g. matches the event signature, the corresponding maintenance plan is selected and the method moves to block 530. Thus, as a result of block 520, one or more maintenance plans 334 relevant to the vehicle 100 and the current condition of the vehicle 100 are selected. As noted, above, in some embodiments each instance of the method is operative in relation to a respective one of the maintenance plans to select or activate that maintenance plan according to the associated event signature.

[0081] In block 530 it is determined whether the selected maintenance plan 334 has been performed previously with respect to the vehicle 100. As discussed above, the maintenance plan 334 may define the maximum process count for that maintenance plan. The maintenance state store 260 stores the process count for each vehicle and maintenance plan indicating the number of times that the maintenance plan has been executed or implemented with respect to that vehicle 100. Block 530 comprises checking the process count against the maximum process count for each maintenance plan. In sub-block 531 , the process count for the vehicle and selected maintenance plan from the maintenance state store 260 is compared against the maximum process count associated with the maintenance plan 330. If the current process count for that vehicle 100 is less than the maximum process count for the maintenance plan, the method progresses to 533 and returns to Figure 4, continuing to block 440. If, however, the process count is equal to or greater than the maximum process count for the maintenance plan, the method moves to block 532 wherein an output is provided indicative of the maximum process count being reached or exceeded In this way, the maintenance plan is prevented from being executed too many times with respect to the particular vehicle 100. Advantageously this avoids wasting resources repeatedly executing the same maintenance plan on the vehicle 100. The method may end after block 532.

[0082] Block 440 comprises outputting 440 maintenance data 350 to cause the at least one associated maintenance action defined by the selected maintenance plan 334 to be performed. In block 440 the rules engine 240 causes the maintenance data 350 to be output, such that the maintenance action associated with the selected maintenance plan 334 is performed with respect to the vehicle 100. The rules engine 240 may output the maintenance data 350, or may instruct another computer system, such as the diagnostic computer system 320, to output the maintenance data 350. In this case, the outputting the maintenance data 350 comprises communicating the maintenance data 350 to the another computer system to cause the maintenance action to be performed upon the vehicle 100. In some embodiments, the outputting of the maintenance data 350 comprises communicating the maintenance data 350 to the vehicle 100 to cause the maintenance action to be performed at the vehicle 100, as illustrated in Figure 3. The maintenance data 350 may be wirelessly communicated from the rules engine 240 the vehicle 100. The communication of the maintenance data 350 may be formed in a push or pull manner. That is, the maintenance data 350 may be pushed to the vehicle 100 such as by the rules engine 240 sending the maintenance data 350 to the vehicle 100, or alternatively the maintenance data 350 may be held at the maintenance computer system 200 waiting for the another computer system, such as the diagnostic computer system 320, or the vehicle 100 to retrieve or pull the maintenance data 350 from the maintenance computer system 200. When received at the vehicle 100, the maintenance data 350 is provided to a processor at the vehicle 100 to cause the processor to perform the maintenance action indicated by the maintenance data 350. In other embodiments, the maintenance data 350 is communicated to the diagnostic computer system 320. When received at the diagnostic computer system 320, an indication of the maintenance action may be output e.g. on a display device associated with the diagnostic computer system 320 such that a user of the diagnostic computer system 320 is able to perform the maintenance action on the vehicle 100 according to the maintenance plan. In such embodiments, blocks 450 and 460 are operative to ensure that the maintenance action has been correctly performed and to validate an effectiveness of the maintenance action as will be discussed.

[0083] In one example, the maintenance data 350 is indicative of an instruction to perform software installation at the vehicle 100 The software installation may be a software update, which includes updating i.e. storing a newer version of software the vehicle 100 or the software installation may be installation of a new or additional software component at the vehicle 100. As will be appreciated, software installation may be a convenient method of resolving problems in software-based systems, wherein the new version of the software may correct issues discovered with existing software versions. The software to be installed may be provided with the maintenance data 350 or, in response to receiving the maintenance data 350, the vehicle 100 may download the software to be installed. Once the software to be installed is obtained at the vehicle 100 it can be installed be appreciated by the skilled person.

[0084] In another example, the maintenance data 350 is indicative of an instruction to perform a calibration process at the vehicle 100. The calibration process may calibrate a system or module of the vehicle 100. In this sense, it will be understood that the calibration process comprises a first step of checking or comparing one or more measurement values of a device e.g. electromagnetic e.g. radar, ultrasonic etc., sensor, liquid level sensor, electrical sensor e.g voltage / current, against a calibration standard of known accuracy. The calibration process may also include a step performing an adjustment to correct an error to an acceptable level.

[0085] In some embodiments, the maintenance data 350 comprises data indicative of an output to be provided to a user of the vehicle 100. For example, the data may comprise a user notification which is provided to the user at the vehicle via a user interface associated with the vehicle 100. The user interface may be at the vehicle 100 i e. a user interface built into the vehicle 100, or may be a user interface of a device e.g mobile device associated with the vehicle 100, such as executing a software application linked to the vehicle 100. The outputting may be performed one or both of visually on a display device or audibly via a speaker. The user notification is indicative of a user performed maintenance action. For example, to refill a liquid associated with the vehicle 100 e g. screen wash fluid, AdBlue etc., or to replace a user-serviceable component such as a filter or the like Other user-performable actions will be envisaged.

[0086] Following block 440 the method 400 comprises two operational blocks 450, 460 which may be performed in any order either sequentially or at least partly in parallel i.e. simultaneously. The method 400 comprises a block 450 of determining that the at least one maintenance action has been performed upon the vehicle 100. Block 450 may be referred to as a verification block 450 which is performed to verify that the at least one maintenance action has been performed to the vehicle 100. In particular, block 450 may be performed to verify that the maintenance action has been successfully performed. That is, that the maintenance action associated with the selected maintenance plan 334 has been performed accordingly. In the verification block 450 the rules engine 240 attempts to confirm that the maintenance action was completed with respect to the vehicle 100.

[0087] The method 400 comprises a block 460 of monitoring for a re-occurrence of the event associated with the selected maintenance plan 334. Block 460 may be referred to as a validation block 460 which is performed to validate that the maintenance action has addressed the issue which caused the maintenance plan to be executed or implemented with respect to the vehicle 100. In the validation block 460 the rules engine 240 attempts to confirm that the maintenance plan 334 has successfully addressed or mitigated the event associated with the maintenance plan.

[0088] In some embodiments, in order for either one or both of blocks 450, 460 to be performed necessary for further data to be received from the vehicle 100. The data may be received following the maintenance action having been performed. The data may be received immediately following the maintenance action or received over a period of time, such as over hours or a plurality of days forming a validation period. It may be necessary for data to be received over a relatively long period of time in order to validate the success of the maintenance plan 334 at addressing the issue having caused the execution of the maintenance plan 334 with respect the vehicle 100 i.e. the event having the event signature associated with the selected maintenance plan 334. The validation period may be defined by the maintenance plan 334. The further data may be referred to as second vehicle data 360 as illustrated in Figure 3. However, it will be appreciated that particulate when the validation block 460 is performed over a period of time, e.g. a plurality of hours or days, it may be considered to operate on still further data referred to as third or fourth vehicle data etc., although not specifically illustrated in Figure 3. When data is received from the vehicle 100 it may be processed by one or both of blocks 450, 460 by an instance of the method 400 with respect to one maintenance plan i.e. a maintenance plan whose maintenance action has been performed on the vehicle 100, whilst also being processed by one or more further instances of the method 400 associated with one or more other maintenance plans.

[0089] An embodiment of the verification block 450 according to an embodiment of the invention is illustrated in Figure 7. In some embodiments, the maintenance plan 334 defines a retry threshold or threshold duration for the verification block 450. In other words, the maintenance plan 334 defines the maximum number of times or maximum duration over which the verification block 450 is to be performed. The maximum duration may be defined in units of time, such as hours or days, over which the verification block 450 attempts to verify the maintenance action. When the method 400 is performed on blocks of data i e. data sessions, the retry threshold may be defined in terms of a number of data sessions for which the verification is to be attempted. In other embodiments, the threshold duration may define a period of time over which the verification is attempted on data received during that period of time from the vehicle 100.

[0090] In some embodiments, the determining or verifying that the maintenance action has been performed comprises determining that the software installation has been successfully completed. The verification may comprise receiving an indication in the second vehicle data 360 from the vehicle 100 that the software installation has been successfully completed. In another example, the determining that the maintenance action has been performed comprises determining that the calibration process has been successfully completed. Still further, the determining that the maintenance action has been performed comprises receiving an indication in the second vehicle data 360 from the vehicle 100 that a user of the vehicle has opened a notification sent to the vehicle 100 e.g. the vehicle 100 has displayed a notification to the user that a message has arrived and the vehicle has received an indication from the user such as a user input to open the notification.

[0091] In some examples, the verification block 450 may comprise a sub-block 710 of determining that a module (software or hardware) or component of the vehicle 100 identified in the maintenance action having been replaced or updated based upon a change in a value such as an address or version number associated with the module or component. For example, block 450 may comprise detecting a change in a DID associated with the module or component e.g. DID F188 (as an example) having a new value When the new value is detected, block 450 is able to determine that the maintenance action has been successfully completed and the method progresses via path 711 to block 730. In some embodiments the maintenance plan defines a verification signature which in block 710 the rules engine 240 attempts to identify in the vehicle data 360 in order to verify that the maintenance action has been performed on the vehicle 100. When the verification signature is identified in the vehicle data 360 it is determined that the maintenance action has been performed and the method progresses via path 711 to block 730.

[0092] In block 730 the method may output indication of the verification being successful and / or may store in the maintenance state store 260 an indication of the verification of the maintenance action for the vehicle 100.

[0093] If, however, block 710 is not able to verify that the maintenance action has been performed, the method progresses via path 712 to block 720. The method may progress via path 712 upon a block or session data being received from the vehicle 100 or upon expiry of a unit of time e.g. each hour or other unit of time In sub-block 720 it is determined or checked whether the maximum number of retries or maximum duration has been reached and, if not, the method returns to block 710 via path 721. If, however, maximum number of retries or maximum duration has been reached in block 720 and the method progresses via path 722 block 740 In block 740 the method may output indication of the verification being unsuccessful and / or may store in the maintenance state store 260 an indication of the unsuccessful verification of the maintenance action for the vehicle 100 That is, in block 740 it is determined that it is not possible to confirm that the maintenance action has been performed upon the vehicle 100.

[0094] An embodiment of the validation block 460 according to an embodiment of the invention is illustrated in Figure 8 As discussed above, in block 460 the method attempts to validate that the maintenance action as having resolved the event which caused the execution of the maintenance plan 334, such as validating that the fault potential fault with the vehicle 100 has been addressed. As discussed above, the validation block 460 may be performed at least partly simultaneously with block 460. Validating that the maintenance action has successfully addressed the event may require a period of time over which data from the vehicle is obtained and analysed to determine that the originating event is not re-occurred. As such, the validation block 460 comprises monitoring for a re-occurrence of the event associated with the selected maintenance plan 334.

[0095] In some embodiments, at least some maintenance plans define a use extent of the vehicle 100, which may be a use duration, a use distance or number of uses of the vehicle 100 or one or more features of the vehicle 100. The monitoring for the re-occurrence of the event is performed at least periodically over the use duration or use distance of the vehicle 100.

[0096] Figure 8 illustrates an embodiment of the validation block 460. The method comprises a sub-block 810 which comprises determining one or more conditions. As discussed, above, the event which caused the execution of the maintenance plan may comprise one or more conditions. Block 810 comprises determining whether the one or more conditions re-occur. As discussed above, the one or more conditions may be identified with respect to the DID provided as part of the vehicle data 360, such as a measurement at the vehicle 100 e.g. a temperature reading, measure of suspension movement or other conditional measurement. The condition may comprise one or more communication signals occurring at the vehicle 100. For example, block 810 comprises determining whether DID F631 <=0.1. Block 810 may be performed over a period of time, a number of blocks or sessions of data or over number of uses of the vehicle, where the use of the vehicle 100 may be vehicle starts or power mode changes, for example If it is not determined that the condition at the vehicle 100 has arisen or the vehicle has experienced the condition, the method follows path 812 to block 820. If it is determined that the condition has occurred, the method follows path 811 to block 830.

[0097] The method may progress via path 812 upon a block or session data being received from the vehicle 100 or upon expiry of a unit of time e.g. each hour or other unit of time In sub-block 820 it is determined or checked whether a maximum number of retries or maximum duration as defined in the maintenance plan 334 has been reached and, if not, the method returns to block 810 via path 821 If, however, maximum number of retries or maximum duration has been reached in block 820 and the method progresses via path 822 block 840. In block 840 the method may output an indication of the validation being unsuccessful and / or may store in the maintenance state store 260 an indication of the unsuccessful validation of the maintenance action for the vehicle 100. That is, in block

[0098] 840 it is determined that it is not possible to confirm or validate that the maintenance action has been successful with respect to the vehicle 100.

[0099] In block 830 it is determined whether the event has re-occurred. Block 830 is a delay block where the vehicle data 360 is monitored for re-occurrence of the event signature during the validation period If re-occurrence of the event is not detected, the method returns to block 810 and the method continues looping or waiting for the validation period. In block 830 if it is determined that the validation period has expired without reoccurrence of the event, the method follows path 832 to block 850.

[0100] In block 850 the method may output indication of the validation being successful and / or may store in the maintenance state store 260 an indication of the validation of the maintenance action for the vehicle 100. It is understood that validation means that the event has not been determined to re-occur within the validation period, such that the maintenance action is deemed successful.

[0101] Returning to Figure 4, in some embodiments of the method 400 in a block 470 of the method 400 the process count value for the selected maintenance plan 334 with respect to the vehicle 100 is updated. In particular, the process count value for the selected maintenance plan 334 is incremented in block 470 to indicate the execution of the maintenance plan 334 upon the vehicle 100. The process count value may be stored in the maintenance plan state store 260 where it is updated.

[0102] The method 400 comprises a block 480 of determining whether to repeat the method 400 i.e. to perform a further iteration. In most instances, the method 400 is expected to continually repeat by following path 481 to return to block 410, such that the method 400 continually monitors for events corresponding to maintenance plans at vehicles and implements maintenance actions as described above. However block 480 allows for a termination condition to be evaluated which, if met, causes the method to follow 482 and end.

[0103] It will be appreciated that various changes and modifications can be made to the present invention without departing from the scope of the present application.

Claims

CLAIMS1 A computer-implemented method for maintaining a vehicle, the method comprising the steps of: obtaining data indicative of a plurality of maintenance plans, each maintenance plan defining a predetermined event and at least one associated maintenance action; receiving first vehicle data from a vehicle; determining, in dependence on the first vehicle data, an occurrence of an event associated with at least one of the plurality of maintenance plans and selecting the at least one associated maintenance plan in dependence thereon; outputting maintenance data to cause the at least one associated maintenance action defined by the selected maintenance plan to be performed upon the vehicle; receiving second vehicle data from the vehicle; determining, in dependence upon the second vehicle data, that the at least one maintenance action has been performed upon the vehicle; and monitoring, for a re-occurrence of the event associated with the selected maintenance plan.2 The computer-implemented method of claim 1 , wherein at least one of the plurality of maintenance plans defines at least one condition associated with the respective event, and wherein the monitoring for the re-occurrence of the event comprises determining whether the event re-occurs in the presence of the condition.3 The computer implemented method of claim 1 or 2, wherein each maintenance plan defines a use extent of the vehicle and the monitoring for the re-occurrence of the event comprises monitoring for the re-occurrence of the event over the use extent.4 The computer-implemented method of any preceding claim, wherein the outputting of the maintenance data comprises communicating the maintenance data to the vehicle to cause the maintenance action to be performed at the vehicle.5 The computer-implemented method of claim 4, wherein: the maintenance data is indicative of an instruction to perform software installation at the vehicle; and the determining that the maintenance action has been performed comprises determining that the software installation has been completed6 The computer-implemented method of claim 4, wherein: the maintenance data is indicative of an instruction to perform a calibration process at the vehicle; and the determining that the maintenance action has been performed comprises determining that the calibration process has been successfully completed.7 The computer-implemented method of any of claims 1 to 3, wherein the outputting the maintenance data comprises communicating the maintenance data to another computer system to cause the maintenance action to be performed upon the vehicle.8 The computer-implemented method of any preceding claim, comprising one or both of: receiving an indication of the maintenance action having been performed upon the vehicle; and receiving an indication that the event associated with the selected maintenance plan has not re-occurred.9 The computer-implemented method of any preceding claim, comprising outputting an indication in dependence on: determining that the maintenance action has not been performed upon the vehicle; or determining that the event associated with the selected maintenance plan has re-occurred.

10. The computer-implemented method of any preceding claim, wherein at least one of the plurality of maintenance plans comprise vehicle qualifying data indicative of a set of one or more vehicles with which the maintenance plan is associated, and the method comprises determining whether the vehicle is within the set of one or more vehicles.

11. The computer-implemented method of claim 10, wherein the vehicle qualifying data comprises an indication of at least one maintenance plan having been previously performed with respect to the vehicle.

12. The computer-implemented method of claim 1 1 , wherein the vehicle qualifying data comprises an indication of an unsuccessful validation operation associated with the at least one maintenance plan.

13. The computer-implemented method of claim 11 or 12, wherein the predetermined maintenance plan relates the same event as the selected maintenance plan.

14. The computer-implemented method of any preceding claim, wherein the method is performed by a rules engine executing on the computer, wherein said rules engine is arranged to store state information indicative of the vehicle and the maintenance plan.

15. A vehicle comprising a communication module and one or more processors, wherein the one or more processors are arranged to: communicate, via the communication module, first vehicle data to a computer system, the first vehicle data indicative of an event occurring at the vehicle; receive, via the communication module, maintenance data from the computer system, perform a maintenance operation in dependence on the maintenance data; communicate, via the communication module, second vehicle data to the computer system, the second vehicle data being indicative of performance of the maintenance operation and re-occurrence of the event at the vehicle.

Images