Patent Application
20090240391
This application claims the benefit of British Patent Application No. 0802368.1, filed Feb. 8, 2008, which is incorporated herein by reference.
This invention relates generally to vehicles, and relates more particularly to controlling the operation of at least one component of a vehicle.
US 2001/0056318 describes an integrated vehicle control system for integratedly controlling a plurality or components such as an engine or an automatic transmission mounted on a vehicle. As component control sections, an engine ECU and an AT ECU arc provided. In the engine ECU and the AT ECU non-volatile memories (ROM) are provided. Stored in the memories in advance are the tuning freedom degree information, representing a category of tuning patterns settable on the side of the respective ECU, and the characteristic information representing the operation of the engine and the automatic transmission, controlled respectively by the tuning pattern set according to the tuning selection information from the manager ECU. The most suitable tuning pattern of the engine tuning patterns realisable by the engine ECU is selected on the basis of the engine tuning freedom degree information retrieved from the engine ECU. By connecting all sorts of information systems such as a navigation system or the like to the manager ECU, the drive system and the brake system of a vehicle may well be integratedly controlled in such a manner that the manager ECU retrieves the information such as gradient and altitude of a road where a vehicle is travelling at present from these information systems.
A problem of the known method is that it is based on default assumptions regarding future usage of the vehicle. The tuning pattern selected by the manager ECU offers limited scope for optimising the performance of the vehicle components to suit the actual operational needs.
An embodiment of the invention relates to a method of configuring an electronic control system for controlling the operation of at least one component of a vehicle, the electronic control system including: a microcontroller; programmable non-volatile memory, wherein the microcontroller is configured to process input signals from at least one vehicle sensor to provide output signals for controlling the at least one vehicle component in accordance with programme data read at least partly from the programmable non-volatile memory; and an interface enabling a programming unit to programme at least part of the programme data into the programmable non-volatile memory, the method comprising:
Another embodiment of the invention also relates to a system for configuring an electronic control system for controlling the operation of at least one component of a vehicle, the electronic control system including: a microcontroller; programmable non-volatile memory, wherein the microcontroller is configured to process input signals from at least one vehicle sensor to provide output signals for controlling the at least one vehicle component in accordance with programme data read at least partly from the programmable non-volatile memory, the system comprising:
A further embodiment of the invention also relates to a computer programme.
It is an object to provide a method, system and computer programme that allow the operating behaviour of vehicle components to be adapted to suit the actual usage and operation of the vehicle.
This object is achieved by the method according to embodiments of the invention, which is characterised by causing a programming unit on board the vehicle to programme the appropriate set into the programmable non-volatile memory. By obtaining sensor data pertaining to the vehicle during its operation, characteristics of the actual usage and operation or the vehicle can be deduced by analysing the sensor data. By determining an appropriate set of programme data based on the analysis, the performance of the vehicle component or components can be adapted to suit the determined characteristics. By causing a programming unit to programme the appropriate set into the programmable non-volatile memory, it is possible to use a bespoke set of data, allowing for better optimisation of the performance characteristics of the vehicle component to suit the actual conditions. Because it is the programme data read by the microcontroller from the programmable non-volatile memory (“Keep-Alive Memory”) that is adapted, a more radical adaptation can be effected than would be possible by modifying a limited set of variables that the microcontroller may maintain in registers (“scratch pad memory”) when controlling the at least one vehicle component. In effect, the control strategy can be modified. By causing a programming unit on board the vehicle to carry out the programming, adaptation to actual usage and operation of the vehicle are achievable. A further advantage is that such adaptation can be achieved without reducing the length of the service intervals of the vehicle.
In an embodiment, the data based on sensor signals and pertaining to the vehicle during its operation includes data indicative of a position of the vehicle, at least implicitly associated with timing information.
The implicit association may be through the point in time at which the data indicative of a position of the vehicle is requested or received. An effect is to obtain data that is relevant to the adaptation of an electronic control system for controlling the operation of at least one component of a vehicle. The location of the vehicle determines the environment which it is in and the demands placed on it. Environmental conditions, such as temperature, humidity, visibility, etc., have a relatively large effect on the operation of vehicle components. The demands placed on the vehicle are quite closely related to its location, for example where legal requirements, road surface conditions and typical gradients are concerned.
In an embodiment of the method, the data based on sensor signals and pertaining to the vehicle during its operation include data based on signals from at least one vehicle sensor.
An effect is to adapt control of the vehicle component(s) to relevant parameters indicative of how the vehicle is being used and of how well vehicle sub-systems are performing.
An embodiment of the method includes obtaining at least one operator profile that indicates the operating style of at least one operator.
An effect is to provide a control strategy that is appropriate to medium and/or short-term future operation of the vehicle, since the operator style is a good predictor of the demands likely to be placed on the vehicle. Thus, the adaptation moves from being purely reactive to being anticipatory.
In a variant, the operator profile(s) is or are derived at least partly on the basis of data based on signals from at least one vehicle sensor.
An effect is to provide a more objective characterisation of an operator, e.g. a driver of a car or rider of a motorbike.
In a further variant, determining an appropriate set of programme data based on the analysis includes obtaining information for identifying an operator of the vehicle and selecting an operator profile of the operator from one of a plurality of operator profiles associated with the vehicle.
This variant takes into account that a vehicle may have several regular operators. It allows for a separation of operator profiles, and contributes to improving the adaptation of the electronic control system.
In an embodiment, the set of programme data includes at least one control map, including data representative of an operating envelope and/or adaptation parameters, for an electronic control system comprising a map-based controller.
An effect is to bring about an adaptation of control strategy that is relatively easy to implement. Moreover, it is amenable to automation.
In an embodiment, the electronic control system comprises at least one Electronic Control Unit for controlling at least a component of an engine.
An effect is to adapt the vehicle's performance most effectively to the conditions under which it is operated, since the engine performance has the greatest effect on the overall vehicle performance. Moreover, in particular in the case of internal combustion engines, the engine performance requires most adaptation to changing conditions. being relatively sensitive to changing conditions and determinative of many key performance indicators, such as fuel efficiency, speed, etc.
In a variant, determining an appropriate set of programme data includes establishing a set of programme data having an effect of improving the efficiency of the engine under conditions to be expected and determined in accordance with the analysis.
An effect is to improve the fuel efficiency of the vehicle. Conventionally, engine performance is determined by factory-installed maps, which are designed on a “one-size-fits-all” basis, and are thus not optimised for any particular pattern of vehicle usage, or operating style. They tend to be biased towards reducing component wear (and hence warranty repair costs), rather than anything else. When a manufacturer releases a vehicle onto the market, it has to be able to cope with many different demands in many different environments. For example, a car has to be able to cope with poor fuel quality, poor servicing, etc., and at the same time provide reliability and economy. This means that manufacturers have to make a compromise, viz. “de-tune” the car. In many countries, such as the United Kingdom, the above-mentioned issues are of no concern. Therefore, there is scope for optimising fuel economy, which is of concern due to environmental regulations.
An embodiment of the method includes causing a programming unit on board the vehicle to programme a set of data into the programmable non-volatile memory for adjustment of use of components of the engine to modify the maximum output of an internal combustion engine.
An effect is to be able to avoid flat spots and increase fuel economy by operating at close to optimum. In effect, it allows for the electronic control system to be adapted such that the accelerator pedal becomes a means of indicating required power, as opposed to a throttle control. This embodiment is based on the recognition of the fact that internal combustion engines achieve optimum specific fuel consumption at a certain percentage of their maximum output, not just at particular ranges of Revolutions Per Minute. An implementation would, for instance, include modifying a control strategy for selectively switching cylinders on and off, based on expected engine loads.
In an embodiment, the programming unit is comprised in a unit connected to a port of an on-board diagnostic system of the vehicle.
An effect is to obviate the need for physically modifying electronic control units, and to make the method potentially suitable for after-market implementation. On-board diagnostic systems are generally standardised in terms of communication protocols and also external ports.
In an embodiment, the data based on sensor signals is obtained via a diagnostic unit plugged into a port for interrogating an on-board diagnostic system, wherein the diagnostic unit communicates with the electronic control system using at least partly a proprietary protocol of the electronic control system.
An effect is to help eliminate the dependency on the often limited maximum data rate of conventional on-board diagnostic systems. The standards for such systems are generally laid out to accommodate devices according to the lowest common denominator.
According to another aspect, the system for configuring an electronic control system for controlling the operation of at least one component of a vehicle according to embodiments of the invention is characterised in that the programming unit is provided on board the vehicle and in that the system is configured to cause the programming unit to programme the appropriate set into the programmable non-volatile memory of the electronic control system.
The system is configured to execute a method according to embodiments of the invention.
According to another aspect of embodiments of the invention, there is provided a computer programme including a set of instructions capable, when incorporated in a machine-readable medium. of causing a system having information processing capabilities to perform a method according to embodiments of the invention.
The computer programme can be used locally within the vehicle or used to implement a distributed system including a server in a network with which the vehicle is arranged to interface.
Embodiments of the invention will be explained in further detail with reference to the accompanying drawings, in which:
Methods for configuring (including re-configuring) electronic control systems for vehicles are discussed herein using the example of a motor car 1. They are equally applicable to other types of vehicle, particularly motor vehicles, such as motor bikes, lorries, ships, aircraft, agricultural machinery, etc.
The car 1 includes an Engine Control Unit (ECU) 2 for controlling an internal combustion engine 3 and an electronic control unit 4 for an Electronic Stability Control (ESC) system (not shown in detail). Engine Control Units are also referred to as Power-Train Control Modules (PCM). The ECU 2 is essential to controlling electronic fuel injection. This description will focus on the ECU 2, but is equally applicable to the electronic control unit 4 of the ESC system. The ECU 2 includes a microcontroller 5 and programmable non-volatile memory, here in the shape of an EEPROM 6 (Electronically Erasable Programmable Read-Only Memory). In another embodiment, the EEPROM 6 is integrated in the microcontroller 5. In another embodiment, SRAM (Static Random Access Memory) or DRAM (Dynamic Random Access Memory) memory units backed up by a battery of the car 1 are used instead of the EEPROM 6. In yet another embodiment, flash RAM is used. The ECU 2 further includes an output stage 7 for providing output signals to engine components such as:
The output stage 7 can include a circuit known as a quad driver to produce voltage levels—these range between five and twelve Volts—necessary to operate automotive actuators
The ECU 2 also includes an interface 8 to a serial vehicle bus, e.g. a CAN (Controller Area Network) bus (not shown). The ECU 2 receives input signals from at least one vehicle sensor through the interface 8 and/or through an input stage (not shown), to which sensor leads are directly connected. Examples of sensors providing input signals include:
The MAP sensor is preferred over the VAF/MAF sensor, because it is better at responding to the addition of a forced induction system or severe changes in atmospheric pressure. In the case of a MAF sensor, the ECU 2 uses feedback from a speed sensor and a look-up table based on the assumption that there is a certain amount of airflow at a certain speed. The look-up table can be stored in the EEPROM 6, for instance.
The ECU 2 controls at least part of the functionality of the engine 3 by processing the input signals in accordance with programme data read at least partly from the EEPROM 6. The actual instructions are read from (non-reprogrammable) Read-Only Memory (ROM) (not shown), in some embodiments. Depending on the features of the car 1, the ECU 2 will have a varying list of functions to perform. In a typical car 1 with a limited set of features, the ECU 2 controls fuel delivery, timing advance and anti-smog equipment. With an increase in engine speed (RPMs), it will increase the timing setting. When the accelerator pedal is pressed down significantly, it increases fuel and air delivery in order to provide more speed, and sometimes advances the timing still further to add power. If a knock sensor detects detonation, the ECU 2 will retard the timing to preserve the engine 3. The simplest versions of the ECU 2 (e.g. those used with engines without fuel injection) do nothing more than control timing advance and smog equipment for best possible emissions, and perhaps also fuel delivery.
The use of electronic fuel injection is of benefit to the environment. The ECU 2 monitors the output from an oxygen sensor (not shown), and adjusts air flow and fuel delivery accordingly. It also controls a smog system, and will add fresh air to the exhaust, which helps to burn unburnt fuel there. Where the car 1 is fitted with a smog pump, which forcibly blows air into the exhaust system, this pump is also controlled by the ECU 2.
In a particular embodiment, the ECU 2 implements a speed limiter to keep the vehicle speed below a certain maximum. In a further embodiment, the ECU 2 implements a rev limiter, to avoid over-revving the engine 3 or reduces the engine speed when the timing advance cannot eliminate detonation. In a variant, the car 1 is provided with a combination of these latter functions, with different limits on the engine speed for different gear combinations.
Where the car 1 is fitted with variable valve timing, the ECU 2 controls intake and exhaust timing, sometimes also during valve lift and duration.
The ECU 2 implements a mapping controller, adapting its control of the engine 3 within an operating envelope using adaptation parameters. The data representative of the operating envelope and adaptation parameters are stored in the EEPROM 6, in addition to data representative of executable programme code. This data may be encrypted. The controller map data include an ignition timing map, for instance. As will be explained in detail below, the system of
An external interface to the vehicle bus is provided by a port 9, into which a Remote Telematics Unit (RTU) 10 is plugged, or to which it is otherwise connected. The port 9 preferably conforms to one or more standards for on-board diagnostic systems, e.g. OBD-II or EOBD. The port 9 is a component fitted as standard to most modern cars, usually within the passenger compartment, e.g. under the dashboard. It is conventionally used for connecting diagnostic tools when the car 1 is being serviced. In the illustrated embodiment, communication is in accordance with international standard ISO 15765. In other embodiments, a different type of vehicle bus is used, and the communications between the RTU 10 and the bus arc in accordance with another standard, e.g. SAE J1850, ISO 9141-2 or ISO 14230.
ODB-II has been the industry standard format for on-board diagnostics across most vehicle marques since 1996. In 1998, the Society of Automotive Engineers set a standard connector plug and a set of diagnostic protocols. However, OBD-II being a worldwide standard has its limitations in terms of speed and functionality. For performance tuning purposes, it is very limited, since the rate of information retrieval is too low. Since all new cars must support OBD-II or the European variant EOBD, the standard is the lowest common denominator. It is a standard that must be achievable by any vehicle, including middle-class cars, vans and top-of-the range cars. The standard requires that an OBD-II reader must not request data from the ECU 2 at more than a couple of single data values per second, even if the ECU 2 is capable of a much higher speed. For this reason, the RTU 10, in one embodiment, uses a custom protocol over the standard protocol for its programming and diagnostic functionality (the functionality described below in detail). This protocol is generally a protocol used by garage tools designed for identifying faults and performing key tasks such as re-tuning, electronic maintenance and re-mapping of the ECU 2. It is characterised by higher data rates than those provided by the standard protocol of the vehicle bus. In another embodiment, the RTU 10 is capable of using any one of a number of protocols.
The RTU 10 comprises a functional unit for (re-) programming the ECU 2 via the port 9 and vehicle bus. Thus, the standard mapping data stored in the EEPROM 6 can be replaced by a mapping to suit the style of the driver and the environmental conditions in which the car 1 is being operated.
In the illustrated embodiment, re-mapping can be carried out remotely through a network connection to the car 1. The RTU 10 has an interface to a cellular transceiver 11 providing a connection to a mobile phone network 12. In other embodiments, other types of interfaces to wireless networks are provided, e.g. WiMax or Bluetooth. In yet other embodiments. such a transceiver is integrated into the RTU 10.
As an alternative to re-mapping over the air, the RTU 10 can be implemented as a stand-alone device, but provided with a memory device for storing a set of data for providing any of a plurality of control maps for re-programming the ECU 2. For more versatility, the RTU 10 optionally includes a read unit (not shown) for reading a portable data carrier storing such data. e.g. an optical disk or solid-state memory device such as an SD-card, Memory Stick, USB memory key, etc.
In the illustrated embodiment, a multi-functional in-vehicle unit 13 is provided, which includes a user interface. e.g. a graphical user interface implemented by means of a touch screen. In an embodiment, the RTU 10 directs reports to the in-vehicle unit 13 via a wired or wireless connection. In another embodiment, the RTU 10 and in-vehicle unit 13 are integrated into one device. The multi-functional in-vehicle unit 13 provides a user interface that allows the user to initiate a method of re-mapping the ECU 2 in one embodiment and/or to confirm that a suggested re-mapping should take place.
In the embodiment illustrated in
Referring to
In addition, the RTU 10 interfaces with a GPS receiver 20 in order to obtain data indicative of the location of the car 1. Where a log is maintained, the location data is time-stamped. Where it is transmitted to the remote computer 14 continually, the timing information is implicit, in that the position is always a generally current one.
Steps in a method of configuring the ECU 2 are shown in
In the illustrated method, the remote computer 14 receives the log data 21 assembled by the RTU 10. Next (step 22), it obtains those data that allow it subsequently (step 23) to determine at least one driver profile that indicates the driving style of the driver, based on the location of the car 1 and the parameters associated with the car whilst it is being driven. A suitable method for obtaining a driver profile is set out in EP-A1-1 811 481. The driving style indicators are based on the parameters monitored by the RTU 10 and mentioned above. For example, the engine RPM can be monitored to determine how aggressively the vehicle is being driven. The vehicle speed can be compared to the local speed limit using the location data. It can also be used to determine the type of road travelled on most often (city traffic, long-distance motorway driving, etc.). It may be desirable to re-map the ECU 2 to operate the engine 3 in a regime most appropriate to a particular type of road, particularly in respect of fuel economy.
It is observed that the vehicle log may cover a period of time in which two or more drivers were using the car 1. In an embodiment, the analysis is able to discern between different driver profiles, and/or to obtain an identification of the driver in association with the driving style indicators. For example, different drivers may have different ignition keys and the RTU 10 may record the data in association with an identifier corresponding to one of the keys. Alternatively, the driver may be prompted to enter an identification using the in-vehicle unit 13, or to enter a personalised code to disarm an immobiliser. In an alternative embodiment, the analysis is configured to detect transitions between time intervals corresponding to different styles of usage of the car 1. These different styles are each associated with an anonymous user (e.g. driver #1, driver #2, etc.).
Concurrently, the GPS data is retrieved (step 24) from the data received by the remote computer 14. It is used (step 25) to obtain location-dependent parameters for determining an appropriate set of programme data for the ECU 2. In an embodiment, the current location is used to search geographically tagged information in a geographic database for relevant parameters. In particular, these may include the local temperature, humidity, regulations (speed, emissions, etc.), visibility, average gradients, etc.
Next (step 26), the remote computer 14 analyses the data generated in the preceding steps 23,25, and determines an appropriate set of programme data for re-programming the ECU 2. In particular, the remote computer 14 selects the appropriate values for the operating envelope and support parameter value(s) that define the control map for the engine 3. Other programme data can be determined and include, for example, the number of cylinders to be used. This would be the case where the engine 3 is suitable for selective switching of cylinders, the number being based on expected engine load.
Finally (step 27), the RTU 10 is caused to programme the set of programme data into the EEPROM 6 of the ECU 2.
Referring to
In the embodiment of
Effects attainable using the systems and methods described above include one or more of the following: increased fuel economy, increased performance, increased drivability, decreased turbo lag and wear, less un-burnt fuel (soot in Diesel engines), lower emissions, and a lower fuel bill. The results will vary from vehicle to vehicle, the most prominent effects being achieved in vehicles with a forced induction engine 3.
In one scenario, the driving performance of a vehicle may be controlled dynamically over time by changing the mapping in the ECU. For example, if a driver, or a particular user, is considered less safe a driver than other users, then the vehicle may be controlled, remotely via the ECU for example, to have a reduced driving performance capability. It may be limited to reduce the chances of the driver having an accident. A difficult to drive sports car may, for example, be remapped to drive like a much less powerful vehicle (a typical budget entry-level compact car, for example). The reduced performance mapping could be adjusted/reprogrammed as the driver's experience, increased, or than measured driving performance improved.
It will be appreciated that in many embodiments we can log the driving profile of a particular person (e.g. how fast they accelerate, how hard they brake, when they change gears, etc.), to gain knowledge of that person's driving profile and we can then use that personal knowledge to re-map the ECU for an optimum map based on the driver behaviour. That optimum would be optimum fuel use, optimum safety (or a safety-led constraint on vehicle performance), or on other criteria. We also use, in many embodiments, geo-location related/coded information. By knowing where the vehicle is we can know that it is on a motorway (for example) and map the ECU whilst it is on the motorway to tailor the performance of the engine/other components to suit that environment for driving. Also, we can map the ECU to suit atmospheric or climate conditions. Air is colder/more dense in near-Arctic circle regions/in the winter than in the desert/in the summer, and this can affect optimum ECU settings for fuel/air mixes (for example). At present vehicle engines are set to “average” conditions. But by using temperature sensors, or geo-location (for example) and weather maps, we can finesse the setting of the ECU of a vehicle to suit the local climatic environment. As a vehicle drives from one temperature region to another/as the conditions change, we can change the mapping in the ECU.
We may have an urban driving mapping and a motorway driving mapping stored in the ECU or in a device linked to the ECU (or any other plurality of mappings) in the system and an external person may send a remote signal to select an appropriate setting (or the driver could set the mapping—e.g. using a GSM signal/phone signal).
Thus in some embodiments the ECU mapping can be adjusted whilst a driver is actually driving, possibly in real time/close to real time. The ECU mapping could be adaptive/dynamic—adapting or changing to the area/circumstances of the road, and/or adaptive to driver behaviour.
The geo-turning (e.g. with GPS) of the ECU could force low emission driving on a driver when they entered certain geographic areas (e.g. low-emission city centres).
The ability to have dynamic ECU control enables the same vehicle to be controlled remotely to drive in different ways, depending upon the mapping programmed into the ECU. This can change with time, or driver, or condition/measured data from the vehicle, or road/weather conditions, or for other reasons.
The invention is not limited to the embodiments described above, which may be varied within the scope of the accompanying claims. For example, the re-mapping may take place automatically at pre-set or user-adjustable intervals, or it may take place when particular performance indicators transcend a pre-set threshold. In an alternative embodiment, the location of the car 1 is determined with respect to the mobile telephone network 12 by determining the cell of the network it is in, so that the GPS receiver 20 is not required. In a further embodiment, the methods illustrated herein are used also or alternatively to re-programme the Electronic Control Unit 4 for the ESC system fitted to the car 1. For example, the control strategy for a hill descent system can be modified to take account of the fact that the vehicle is being driven off-road or in an area with steep gradients.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0802368.1 | Feb 2008 | GB | national |
