GB2571744A

GB2571744A - Controller and method for controlling a vehicle

Info

Publication number: GB2571744A
Application number: GB1803640.0A
Authority: GB
Inventors: James Mcgeoch David; Marsden Paul
Original assignee: Jaguar Land Rover Ltd
Current assignee: Jaguar Land Rover Ltd
Priority date: 2018-03-07
Filing date: 2018-03-07
Publication date: 2019-09-11
Anticipated expiration: 2038-03-07
Also published as: GB201803640D0; GB2571744B

Abstract

A method 400 of controlling a vehicle (100, Fig 6), comprising: determining 401 that a diagnostic of at least one oxygen sensor (204, 208, Fig. 2) of an exhaust system 202 for an engine 210 of the vehicle is required, predicting 404 when one or more conditions for implementing the diagnostic will be satisfied, and implementing 414 the diagnostic. The method is aimed at predicting when an engine maybe in an overrun condition, or sailing, coasting, or gliding mode for performing the diagnostic, and may be particularly useful in hybrid vehicles.

Description

CONTROLLER AND METHOD FOR CONTROLLING A VEHICLE

TECHNICAL FIELD

The present disclosure relates to a controller and method for controlling a vehicle. In particular, but not exclusively it relates to a controller and method for controlling implementation of a device diagnostic, wherein the device may be an oxygen sensor.

Aspects of the invention relate to a method, a controller, a vehicle and a computer program.

BACKGROUND

For the continued health of a vehicle combustion engine, diagnostic functions must be performed to check sensors/actuators are operating correctly. Example sensors that require diagnosis are the oxygen sensors in the engine's exhaust. Oxygen sensors are sometimes referred to as lambda sensors or Heated Exhaust Gas Oxygen (HEGO) sensors.

An oxygen sensor diagnostic typically operates by recognising the change from combusted air to clean air. This is performed during periods of Overrun’ (driver-off-pedal vehicle deceleration) when the combustion engine enters overrun fuel cut-off. In this state, fuelling of the engine is stopped, so that only un-burnt air is passed through the engine.

An oxygen sensor diagnostic can take upwards of 10 seconds to complete. In prior implementations, it cannot be performed when the engine is providing propulsive torque or at idle (e.g. when the vehicle is stationary). A diagnostic can easily be interrupted by driver torque demand caused by accelerator pedal depression.

Since an oxygen sensor diagnostic is only performed when in overrun, vehicles equipped with ‘sailing’ mode (aka coasting/gliding mode) functionality may not be capable of providing the required overrun conditions. This is because in sailing mode, the transmission is opened whenever the vehicle would normally be in an overrun state, so that the engine may cease rotation and no longer provide combusted air, or remain at idle.

It is an aim of the present invention to address disadvantages of the prior art.

SUMMARY OF THE INVENTION

Aspects and embodiments of the invention provide a method, a controller, a vehicle and a computer program as claimed in the appended claims.

According to an aspect of the invention there is provided a method of controlling a vehicle, comprising: determining that a diagnostic of at least one oxygen sensor of an exhaust system for an engine of the vehicle is required; predicting when one or more conditions for implementing the diagnostic will be satisfied; and implementing the diagnostic.

This provides the advantage that the diagnostic can be scheduled for when the one or more conditions for implementing the diagnostic are predicted to be met. An advantage over reactive scheduling of the diagnostic is that there is no need to inhibit sailing mode over a long period of time while waiting for the condition(s) to be satisfied. Unnecessary inhibition of sailing mode can increase pumping losses and cool exhaust gas after-treatment systems, while intermittent inhibition of sailing mode can result in inconsistent vehicle overrun response due to pumping losses.

In some examples, the one or more conditions comprise a timing condition. In some examples, the timing condition specifies a required duration and/or frequency of satisfaction of another of the one or more conditions.

This provides the advantage that the diagnostic can be scheduled for when the probability of interruption of the diagnostic is low.

In some examples, the one or more conditions comprise a torque demand condition satisfied by the engine being rotated without being fuelled. In some examples, the ‘another’ condition to be satisfied for a required duration and/or frequency is the torque demand condition.

This provides the advantage that the diagnostic can be scheduled for when the probability of intervention is low. Intervention may be from a driver or an engine ancillary requesting engine torque.

In some examples, the predicting step of the method comprises predicting a point in time at which the one or more conditions for implementing the diagnostic will be satisfied. Alternatively, the predicting step comprises predicting a location at which the one or more conditions for implementing the diagnostic will be satisfied.

In some examples, the diagnostic is only implemented when at least one of the one or more conditions is satisfied. For example, when the scheduled time is reached (or shortly before) it may be determined whether at least one of the one or more conditions is actually satisfied, and only in this case is the diagnostic carried out. In some examples, the at least one condition is the torque demand condition.

This provides the advantage that the diagnostic can be rescheduled if the timing is not appropriate as predicted.

In some examples, the prediction is dependent on one or more of: machine learning; or information indicative of a current context external to the vehicle (e.g. a route programmed into a satellite navigation system of the vehicle). In some examples, the information comprises at least one of: image data; location data; pulse reflection data; data received from another vehicle; or data from an infrastructure management system. In some examples, the machine learning is dependent on at least one of: past driver inputs; or information indicative of a past context external to the vehicle (e.g. past routes programmed into a satellite navigation system of the vehicle).

This provides the advantage that accuracy of the prediction is improved.

In some examples, the method comprises determining whether or for how long the engine is to remain connected to the vehicle driveline during the implementation, in dependence on the prediction.

This provides the advantage that the engine speed can be controlled to improve the accuracy of the diagnostic or to stay within limits required by the diagnostic.

In some examples, the method comprises causing the engine to remain connected to a driveline of the vehicle during the implementation, enabling the vehicle driveline to rotate the engine without the engine being fuelled.

This provides the advantage that the diagnostic can be performed during engine overrun.

In some examples, the method comprises causing the engine to not be connected to a driveline of the vehicle during the implementation. In some examples, the method comprises causing the engine to be rotated by a secondary torque source during the implementation. In some examples, the secondary torque source comprises an electric motor (e.g. integrated starter-generator).

If the engine is disconnected from the driveline and rotated by the secondary torque source, this provides the advantage that the diagnostic can be performed while the vehicle is stationary (at traffic lights or in traffic).

Disconnection from the driveline and/or rotation by the secondary torque source also enables fine control of engine speed during the diagnostic.

In some examples, the engine is rotated at a set speed by the secondary torque source during the implementation.

This provides the advantage of a more accurate diagnostic.

In some examples, air aspiration to the engine is fixed during the implementation (e.g. by controlling a variable valve mechanism and/or throttle valve).

This provides the advantage of a more accurate diagnostic.

In some examples, the determination that a diagnostic is required is dependent on a time elapsed and/or use of the vehicle since the last implementation of the diagnostic, and/or information indicative of a faulty oxygen sensor symptom.

This provides the advantage that the diagnostic is not implemented too frequently.

According to another aspect of the invention there is provided a method of controlling a vehicle, the method comprising: determining that a diagnostic of at least one oxygen sensor of an exhaust system for an engine of the vehicle is required; predicting when one or more conditions for implementing the diagnostic will be satisfied; scheduling future implementation of the diagnostic for when the one or more conditions are predicted to be met; and implementing the scheduled diagnostic.

According to a further aspect of the invention there is provided a method of controlling a vehicle, comprising: determining that a diagnostic of at least one device for the vehicle is required; predicting when one or more conditions for implementing the diagnostic will be satisfied; and implementing the diagnostic. In some examples, the device is a powertrain or drivetrain component. In some examples, the device is a sensor or actuator. In some examples, the device is an oxygen sensor of an exhaust system for an engine of the vehicle.

According to a further aspect of the invention there is provided a controller comprising means for causing any one or more of the methods described herein to be performed.

In some examples, the means comprises: at least one electronic processor; and at least one electronic memory device electrically coupled to the electronic processor and having instructions stored therein, the at least one electronic memory device and the instructions configured to, with the at least one electronic processor, cause any one or more of the methods described herein to be performed.

According to a further aspect of the invention there is provided a vehicle comprising the controller.

In some examples, the vehicle is a mild hybrid vehicle.

According to a further aspect of the invention there is provided a computer program that, when run on at least one electronic processor, causes any one or more of the methods described herein to be performed.

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.

BRIEF DESCRIPTION OF THE DRAWINGS

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

Fig 1 illustrates an example of a vehicle;

Fig 2 illustrates an example of potential oxygen sensor locations for a powertrain;

Fig 3 illustrates an example of a controller;

Fig 4 illustrates an example of a method;

Fig 5 illustrates an example of a predictive input;

Fig 6 illustrates a mild hybrid vehicle architecture; and

Fig 7 illustrates an example of a method.

DETAILED DESCRIPTION

Fig 1 illustrates an example of a vehicle 100 in which embodiments of the invention can be implemented. In some, but not necessarily all examples, the vehicle 100 is a passenger vehicle, also referred to as a passenger car or as an automobile. Passenger vehicles generally have kerb weights of less than 5000 kg. In other examples, embodiments of the invention can be implemented for other applications, such as industrial vehicles, air or marine vehicles.

Fig 2 illustrates potential oxygen sensor locations for a powertrain of the vehicle 100. Fig 2 illustrates an intake system 212, an engine 210 and an exhaust system 202 of a powertrain.

The engine 210 may be any automotive internal combustion engine. In some examples, the engine 210 may be a reciprocating piston engine.

Oxygen sensors 204, 208 are provided along the exhaust system 202 at different locations. Two are shown in Fig 2, however just one could be provided in other implementations.

The oxygen sensors 204, 208 are spaced longitudinally along the exhaust system 202. If a catalytic converter 206 is provided, the first oxygen sensor 204 may be a ‘pre-cat’ sensor located upstream of the catalytic converter 206. The second oxygen sensor 208 may be a ‘post-cat’ sensor located downstream of the catalytic converter 206. In other examples, the oxygen sensor or sensors can be provided at any location(s) in the exhaust system 202.

The intake system 212 comprises any suitable aspiration control means 214 for controlling air aspiration into the engine 210. An example of a suitable aspiration control means 214 is a throttle valve. Additionally or alternatively, the means 214 may comprise a variable valve mechanism capable of changing intake valve timing and/or lift.

One or more electronic controllers (controllers) may be provided to supervise and control operation of the oxygen sensors 204, 208, the engine 210, and the aspiration control means 214.

Fig 3 illustrates an example of a controller 200 comprising means for causing one or more of the methods described herein to be performed in a vehicle 100 by an appropriate system such as the system of Fig 2.

Fig 3 also illustrates an example of a computer program that, when run on at least one electronic processor 302, causes one or more of the methods described herein to be performed.

The controller 200 of Fig 3 includes at least one electronic processor 302; and at least one electronic memory device 304 electrically coupled to the electronic processor 302 and having instructions 308 (e.g. a computer program) stored therein, the at least one electronic memory device 304 and the instructions 308 configured to, with the at least one electronic processor 302, cause any one or more of the methods described herein to be performed.

For purposes of this disclosure, it is to be understood that the controller(s) 200 described herein can each comprise a control unit or computational device having one or more electronic processors 302. A vehicle 100 and/or a system thereof may comprise a single control unit or electronic controller or alternatively different functions of the controller(s) may be embodied in, or hosted in, different control units or controllers. A set of instructions 308 could be provided which, when executed, cause said controller(s) or control unit(s) to implement the control techniques described herein (including the described method(s)). The set of instructions may be embedded in one or more electronic processors, or alternatively, the set of instructions could be provided as software to be executed by one or more electronic processor(s). For example, a first controller may be implemented in software run on one or more electronic processors, and one or more other controllers may also be implemented in software run on or more electronic processors, optionally the same one or more processors as the first controller. It will be appreciated, however, that other arrangements are also useful, and therefore, the present disclosure is not intended to be limited to any particular arrangement. In any event, the set of instructions described above may be embedded in a computer-readable storage medium 310 (e.g., a non-transitory computer-readable storage medium) that may comprise any mechanism for storing information in a form readable by a machine or electronic processors/computational device, including, without limitation: a magnetic storage medium (e.g., floppy diskette); optical storage medium (e.g., CD-ROM); magneto optical storage medium; read only memory (ROM); random access memory (RAM); erasable programmable memory (e.g., EPROM ad EEPROM); flash memory; or electrical or other types of medium for storing such information/instructions.

Fig 4 illustrates an example method 400 in accordance with various aspects and embodiments of the present invention. The method 400 may be performed by the controller 200.

The method 400 begins at block 401. In block 401 the method 400 comprises determining that a diagnostic of an oxygen sensor(s) 204, 208 of an exhaust system 202 for an engine 210 of the vehicle 100 is required.

In some, but not necessarily all examples the determination may be responsive to a flag in the controller 200 that is set once a diagnostic milestone or condition has been reached. If permitted by regulatory requirements (if any) the milestone or condition may comprise, for example a time elapsed and/or use of the vehicle 100 since the last implementation of the diagnostic, and/or information indicative of a faulty oxygen sensor symptom. The use of the vehicle may comprise, for example, a number of driving cycles and/or a distance travelled. In an example, the diagnostic milestone is reached once per driving cycle.

In response to the determination, the method 400 proceeds to block 404. In block 404, the method 400 predicts when one or more conditions for implementing the diagnostic will be satisfied. The prediction is made in dependence on predictive inputs received in block 402.

The condition(s) will be discussed first. The conditions may include any condition that, if it ceases to be satisfied during implementation of the diagnostic, would be an ‘interrupter’ of the diagnostic.

Depending on implementation, an ‘interrupter’ could mean that the diagnostic is stopped, and/or the diagnostic flag is not cleared, and/or the diagnostic will be treated as not having been done, and/or the next diagnostic will be performed earlier than normal.

Examples of suitable conditions will be discussed below. In some, but not necessarily all examples the one or more conditions comprise a torque demand condition. The torque demand condition may relate to a clean air requirement for a successful implementation of the diagnostic.

In an implementation, the torque demand condition may be satisfied if the engine 210 does not produce positive torque via combustion, so that clean un-combusted air is available for the diagnostic. In an implementation, the torque demand condition may be satisfied by the engine 210 being rotated without being fuelled, and may be satisfied by the engine 210 being rotated while being fueled but without ignition of the fuel-air mixture.

The torque demand may relate to a driver torque demand (e.g. accelerator pedal/cruise control demand) and/or an engine auxiliary system torque demand (e.g. air conditioning or alternator demand).

In some, but not necessarily all examples the one or more conditions comprise an engine speed-dependent condition. In some examples, engine speed-dependent conditions may relate to engine speed parameters such as engine speed or vehicle speed while the engine 210 is connected to the vehicle wheels, acceleration, or a combination thereof.

In an implementation, an engine speed-dependent condition may be satisfied if engine speed can be kept within a window required for pumping air through the exhaust system 202 for the oxygen sensor diagnostic.

In some, but not necessarily all examples the one or more conditions comprise a timing condition. The timing condition may relate to a time required for successful implementation of the diagnostic. In some, but not necessarily all examples the timing condition may relate to a continuous uninterrupted time. In other examples the timing condition may allow a noncontinuous interrupted time such as cumulative time within a window.

The timing condition may specify a required duration and/or frequency of satisfaction of another one or more of the conditions, such as the torque demand condition and/or the engine speed-dependent condition.

Fig 5 illustrates an example of torque demand over time, which could form the basis for a prediction of future torque demand. The ‘Hi’ signal represents >0 torque demand (nonsatisfaction of the torque demand condition), and the ‘Lo’ signal represents substantially no torque demand (satisfaction of the torque demand condition).

If the timing condition requires a continuous time At of satisfaction of the torque demand condition, it can be seen in Fig 5 that the second Lo signal starting at time T presents an opportunity for implementing the diagnostic without interruption. This is because the torque demand condition will be satisfied for the whole time interval At without break.

As mentioned above, block 404 needs to make a prediction for when the condition(s) will be satisfied. Methods of making a prediction will now be discussed.

In some, but not necessarily all examples the prediction may be dependent on information indicative of a current context external to the vehicle 100.

The information may be from input data to the controller 200 which may be received directly from any suitable sensor (not shown) on the vehicle 100 arranged to sense the current context external to the vehicle 100, or indirectly via one or more intervening elements.

The information is indicative of the current context because there may be a minimal time delay between the recording of data by the sensor and the receiving of the input comprising the data, for example less than one second or less than a minute.

Examples of suitable information processed at block 404 include at least one of: image data; location (e.g. navigation) data; pulse reflection data; data received from another vehicle; or data from an infrastructure management system. Image data can be received from at least one of: a visual camera; an infrared camera, on the vehicle 100. Pulse reflection data can be received from a pulse reflection sensor such as a radar or LIDAR (Light Detection and Ranging) sensor on the vehicle 100. Information received from another vehicle or infrastructure management system can be received by a wireless receiver or transceiver on the vehicle 100.

Location data may be received from a navigation system such as any Global Navigation Satellite System (GNSS). Location data may comprise mapping data and may indicate the current location of the vehicle 100 within a virtual map. Location data may indicate a route to be followed by the vehicle 100, which may have been programmed by the driver into the navigation system. Location data may indicate traffic density and/or average speed along the route.

Information from another vehicle can comprise information concerning the speed, position and direction of the another vehicle, or any other suitable information concerning the local real-time context around the vehicle. Information from an infrastructure management system may comprise congestion information, information concerning the state of a road infrastructure object such as a traffic light, or any other suitable information concerning the local real-time context around the vehicle 100.

Some of the example information above may comprise local real-time context data indicative of a local real-time context around the vehicle 100 and external to the vehicle 100. This local real-time context data enables information on objects within a monitored field of view of a sensor to be determined by processing the data and recognizing objects in real-time. Recognition of objects in real-time can be performed using any suitable technique such as image processing. Local real-time context also relates to current traffic, a current state of traffic lights, a current diversion on a currently programmed route, and the like.

In some, but not necessarily all examples the prediction may be dependent on machine learning.

The machine learning relates to any procedure that enables a ‘routine’ of past vehicle driving to be established from past recorded use of the vehicle. Predictions can be made from the routine.

The machine learning may be dependent on at least one of: past driver inputs; or information indicative of a past context external to the vehicle 100.

Information indicative of the past context may correspond to recordings of the abovedescribed information indicative of a current context.

Past driver inputs include, for example, a history of satisfaction/non-satisfaction of the one or more of the above-mentioned conditions. Past driver inputs therefore may comprise a past driver torque demand and/or a past engine speed-dependent parameter. Fig 5 is a nonlimiting example illustrating the form that past driver input data could take, for the purposes of prediction.

Known machine learning techniques include nearest neighbour regression and/or ensemble learning, for example, although other machine learning techniques are usable.

In an example implementation, the machine learning may store past torque demand information for a particular route between two locations. The machine learning routine information can then be interrogated based on current context information such as a currently programmed route, weekday and time of day, to determine whether past data exists for the route on a similar day and time. If such past data does exist in the routine, the torque demand can be predicted for the currently programmed route ahead with a good degree of confidence. The prediction can be solely based on the past data or may be modified in dependence on further current context information.

Beneficially, the machine learning data may also be available for a plurality of other purposes other than for sensor diagnosis including, for example, predictive energy optimisation for managing traction battery state of charge.

Once the prediction has been made in block 404, the method 400 proceeds to block 406 if the condition will not be satisfied in the timeframe covered by the prediction (e.g. until end of journey/fixed time ahead). According to block 406, implementation of the diagnostic is not scheduled. The method 400 is accordingly delayed and may loop back to an earlier block such as block 401.

If the condition will be satisfied at some time T, the method 400 proceeds to block 410 instead. According to block 410, implementation of the diagnostic will be scheduled to begin at time T. No attempt will be made to implement the diagnostic before time T, even if some of the condition(s) become satisfied before time T. Before time T, the vehicle 100 is therefore able to utilize the benefits of sailing mode on overrun if the vehicle 100 is equipped with sailing mode functionality.

In an alternative embodiment, the method 400 predicts, at block 404, a location at which one or more conditions for implementing the diagnostic will be satisfied. If the one or more conditions will be satisfied at a location within a geographical region covered by the prediction (e.g. along a route ahead of the vehicle), implementation of the diagnostic will be scheduled to begin when the vehicle arrives at the location predicted at block 404.

The method 400 then proceeds to optional block 412, which checks at the scheduled time or the predicted location whether the conditions are currently satisfied as predicted. In other words, the diagnostic is only implemented at the scheduled time or the predicted location if at least one of the one or more conditions is satisfied. For example, the actual current torque demand at the scheduled time (e.g. time T) or the predicted location must satisfy the torque demand condition.

If the outcome of block 412 is negative, implementation of the diagnostic at the scheduled time or the predicted location is impossible or likely to be interrupted. In such an event, the method 400 may loop back to an earlier block of the method for making a new prediction to reschedule the implementation. Alternatively, the scheduling may switch to a ‘reactive’ mode rather than the aforementioned ‘predictive’ mode. In reactive mode, the diagnostic will be implemented as soon as possible after the scheduled time or the predicted location in response to the currently monitored aforementioned conditions for implementing the diagnostic next becoming satisfied.

The method 400 proceeds from block 410 or 412 to block 414. In block 414, the method 400 comprises implementing the diagnostic. In an example, this can comprise the controller 200 transmitting a control signal to the necessary hardware (c.f. Fig 2) for performing the diagnostic, or to one or more hardware controllers.

Air aspiration may be fixed during the implementation by control of the aspiration control means 214.

If the diagnostic is (unexpectedly) interrupted before completion, the method 400 may loop to an earlier block, switch to reactive mode, or the like.

Fig 6 illustrates an example vehicle architecture in which the above method 400 and optional additional aspects can be beneficially implemented. The illustrated architecture is one nonlimiting example of a plurality of appropriate architectures relating to the vehicle 100 comprising a secondary torque source 600 capable of controlling engine speed during implementation of the diagnostic.

The vehicle 100 of Fig 6 is an example of a mild-hybrid electric vehicle (MHEV). The vehicle 100 comprises a clutch 602 selectively openable to selectively disconnect the engine 210 from the vehicle driveline 604, so as to disconnect drive to the vehicle wheels. The vehicle 100 also comprises a secondary torque source 600 in the form of an electric motor. The electric motor is on the engine side of the clutch 602 so is operable to rotate the engine 210 while the clutch 602 is open. In one implementation, the electric motor may be an integrated starter-generator (ISG).

The illustrated secondary torque source 600 is operably coupled to the controller 200.

In some, but not necessarily all examples the vehicle 100 is operable to implement sailing mode on overrun. Implementing sailing mode comprises opening the clutch 602 during overrun to reduce pumping losses. As explained earlier, sailing mode would be an interrupter of an oxygen sensor diagnostic because the engine speed would fall therefore not satisfying the engine speed-dependent condition.

Beneficially, the vehicle 100 of Fig 6 has the architecture to enable the engine 210 to be spun by the secondary torque source 600 during the implementation of the diagnostic, to ensure that the engine speed-dependent condition is met regardless of whether the vehicle is in overrun and despite the clutch 602 being opened. As a result, there is no need to inhibit sailing mode on overrun to implement the diagnostic.

The architecture also opens up new possibilities for the timing of the diagnostic. For example, the diagnostic could be implemented while the vehicle 100 is stationary and the engine 210 would otherwise be idling.

Fig 7 illustrates an example method 700 applicable to vehicle architectures similar to, and including the MHEV architecture of Fig 6. The method 700 may comprise some of all of the steps of the method 400. Some of the blocks of the method 700 have the same reference numerals as the blocks of the method 400, to denote conceptually similar blocks. The method 700 may be performed by the controller 200.

In summary, the method 700 relates to a decision of which one of two ways the diagnostic is to be implemented.

The method 700 starts at block 401 (diagnostic required).

At the next block 706, a decision is made as to whether the engine 210 is to remain connected to the vehicle driveline 604 (clutch 602 closed) during the implementation, in dependence on the prediction. The clutch 602 can remain closed if the diagnostic can be started and completed in overrun.

In an example implementation of block 706, the method 700 comprises a prediction much like block 404, using the predictive input from block 402, which looks for a scheduling time T or predicting a location for performing 100% of the diagnostic in vehicle overrun.

If the answer is positive (e.g. long downhill section of route coming up, no torque expected), the clutch 602 can remain closed during overrun so that the vehicle driveline 604 rotates the engine 210 in overrun without the need to rotate the engine by combustion or by the secondary torque source 600. In such a situation, the method 700 may then progress to block 410 (schedule for time T1 or for the predicted location), optional block 412 (check condition(s) satisfied at T1 or at the predicted location), and then block 414 (implement diagnostic).

If the answer to block 706 is negative (e.g. route is entirely uphill, torque always expected), this means that <100% of the implementation can be completed in vehicle overrun. The implementation will then be scheduled differently.

In response to the negative answer to block 706, another prediction is made at block 712. The latter prediction looks for opportunities to implement 1-100% of the diagnostic using an open clutch 602 and rotating the engine 210 with a secondary torque source 600. This means that more future opportunities may present themselves for implementing the diagnostic (e.g. could be performed while vehicle 100 stopped at lights), at the expense of consuming energy in a traction battery for the secondary torque source 600. Further, there may be no need to inhibit sailing mode.

If the answer to block 712 is negative, the method 700 progresses to block 406 (do not implement diagnostic) and optionally loops back to block 401.

If the answer to block 712 is positive (e.g. long wait at a set of traffic lights expected, sufficient state of charge, or the like), then the diagnostic can be implemented in an alternative manner to the above-described clutch-closed overrun implementation.

In response to a positive answer to block 712, the method 700 may then progress to block 714 (schedule implementation of diagnostic for a time or location at which condition(s) will be satisfied), optional block 412 (check condition(s) are satisfied at the time or location scheduled at block 714), block 716 (clutch 602 opened), block 718 (secondary torque source 600 rotates engine 210 at required speed), and finally block 720 (diagnostic implemented in a similar manner to block 414 while engine 210 rotated at required speed).

In some, but not necessarily all examples the implementation could be a hybrid of the two scenarios discussed in relation to the method 700. The clutch 602 could be opened part way through the implementation of the diagnostic. The diagnostic may start in overrun with sailing mode inhibited (clutch 602 closed), and then to complete the diagnostic the clutch 602 may be opened and the engine 210 rotated by the secondary torque source 600.

According to block 718, the engine 210 can be rotated at a set speed (e.g. 2000rpm) by the secondary torque source 600 during the implementation. This eliminates engine speed variation so increases the accuracy of the diagnostic. In some examples the duration of the diagnostic in block 720 may be shorter than in block 414, because the fixed engine speed enabled in block 718 allows for a more accurate diagnosis with greater control of variables such as engine speed.

The blocks illustrated in Figs 4 and 7 may represent steps in a method and/or sections of code in the computer program. The illustration of a particular order to the blocks does not necessarily imply that there is a required or preferred order for the blocks and the order and arrangement of the block may be varied. Furthermore, it may be possible for some steps to be omitted.

Although embodiments of the present invention have been described in the preceding paragraphs with reference to various examples, it should be appreciated that modifications to the examples given can be made without departing from the scope of the invention as claimed. For example, the method 700 appears to prioritise non-use of the secondary torque source 600 based on the ordering of the blocks, preferring the branch to block 414 over the branch to block 720 since using the secondary torque source 600 has a greater energy cost. However, in alternative implementations the method may prioritise use of the secondary torque source 600 to aid scheduling of the diagnostic in use cases with infrequent overrun opportunities, preferring the branch to block 720 over the branch to block 414. In some implementations, the prioritization or ‘weighting’ of one of the branch over the other may be dynamic, depending for instance on the number of overrun opportunities. A vehicle that is only driven in the city and therefore never enters overrun for long enough to complete a diagnostic may favour the branch to block 720.

Features described in the preceding description may be used in combinations other than the combinations explicitly described.

Although functions have been described with reference to certain features, those functions may be performable by other features whether described or not.

Although features have been described with reference to certain embodiments, those features may also be present in other embodiments whether described or not.

Whilst endeavoring in the foregoing specification to draw attention to those features of the invention believed to be of particular importance it should be understood that the Applicant claims protection in respect of any patentable feature or combination of features hereinbefore referred to and/or shown in the drawings whether or not particular emphasis has been placed thereon.

Claims

1. A method of controlling a vehicle, comprising:

determining that a diagnostic of at least one oxygen sensor of an exhaust system for an engine of the vehicle is required;

predicting when one or more conditions for implementing the diagnostic will be satisfied; and implementing the diagnostic.

2. The method as claimed in claim 1, wherein the one or more conditions comprise a timing condition.

3. The method as claimed in claim 2, wherein the timing condition specifies a required duration and/or frequency of satisfaction of another of the one or more conditions.

4. The method as claimed in any preceding claim, wherein the one or more conditions comprise a torque demand condition satisfied by the engine being rotated without being fuelled.

5. The method as claimed in any preceding claim, wherein the predicting comprises predicting a point in time at which the one or more conditions for implementing the diagnostic will be satisfied.

6. The method as claimed in any one of claims 1 to 4, wherein the predicting comprises predicting a location at which the one or more conditions for implementing the diagnostic will be satisfied.

7. The method as claimed in any preceding claim, wherein the diagnostic is only implemented when at least one of the one or more conditions is satisfied.

8. The method as claimed in any preceding claim, wherein the prediction is dependent on one or more of: machine learning; or information indicative of a current context external to the vehicle.

9. The method as claimed in claim 8, wherein the information comprises at least one of: image data; location data; pulse reflection data; data received from another vehicle; or data from an infrastructure management system.

10. The method as claimed in claim 8 or 9, wherein the machine learning is dependent on at least one of: past driver inputs; or information indicative of a past context external to the vehicle.

11. The method as claimed in any preceding claim, comprising determining whether or for how long the engine is to remain connected to the vehicle driveline during the implementation, in dependence on the prediction.

12. The method as claimed in any preceding claim, comprising causing the engine to remain connected to the vehicle driveline during the implementation, enabling the vehicle driveline to rotate the engine without the engine being fuelled.

13. The method as claimed in any one of claims 1 to 11, comprising causing the engine to not be connected to the vehicle driveline during the implementation.

14. The method as claimed in any preceding claim, comprising causing the engine to be rotated by a secondary torque source during the implementation.

15. The method as claimed in claim 14, wherein the secondary torque source comprises an electric motor.

16. The method as claimed in claim 14 or 15, wherein the engine is rotated at a set speed by the secondary torque source during the implementation.

17. The method as claimed in any preceding claim, wherein air aspiration to the engine is fixed during the implementation.

18. The method as claimed in any preceding claim, wherein the determination that a diagnostic is required is dependent on a time elapsed and/or use of the vehicle since the last implementation of the diagnostic, and/or information indicative of a faulty oxygen sensor symptom.

19. A controller comprising means for causing the method of any one or more of claims 1 to

5 18 to be performed.

20. A vehicle comprising the controller of claim 19.

21. The vehicle as claimed in claim 20, wherein the vehicle is a mild hybrid vehicle.

22. A computer program that, when run on at least one electronic processor, causes the method as claimed in any one or more of claims 1 to 18 to be performed.