FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
PROVISIONAL SPECIFICATION
(See Section 10; rule 13)
TITLE OF INVENTION
Method For Improving Reliability Of Odometer And Vehicle Speed Functionality


APPLICANTS
TATA MOTORS LIMITED, an Indian company
having its registered office at Bombay House,
24 Homi Mody Street, Hutatma Chowk,
Mumbai 400 001 Maharashtra, India
INVENTORS
Dihyendu Palai and Jayachandran Duraisamy
Both are Indian Nationals
of TATA MOTORS LIMITED,
an Indian company having its registered office
at Bombay House, 24 Homi Mody Street, Hutatma Chowk,
Mumbai 400 001 Maharashtra, India
PREAMBLE TO THE DESCRIPTION
The following specification describes the invention.


FIELD OF INVENTION
The present invention relates to vehicle speed and odometer functionality in automotive vehicles. The invention proposes an alternate method of distributing these functions to improve reliability.
BACKGROUND OF INVENTION
Vehicle speed and odometer functions arc the most critical functions of the vehicle from vehicle warranty and regulation point of view. As per regulatory requirements, these two vehicle functionalities shall be present in all vehicle variants and shall be displayed to user of the vehicle. So, it is very crucial for the car manufacturers to achieve reliable vehicle speed and odometer functionality in all the vehicles.
Existing methodologies for vehicle speed and odometer functions are typically stand alone functions where these functions are totally realized in only one electronic control unit (ECU), namely instrument cluster ECU. The problem associated with this stand alone method is that it calls for extra speed sensor to support this functionality. Sometimes it is also in practice to distribute these functions between two ECUs, namely engine management ECU and instrument cluster (IC), As per this method, engine management ECU (or any other ECU) provides the vehicle speed and distance traveled input to IC. IC receives them and computes the total distance traveled value and displays them for user. The value of the total distance traveled by tht: vehicle (or the odometer value) is typically stored in the EEROM of instrument cluster. As per regulatory requirement, IC shall not loose this value from its memory. Also this odometer value is critical from warranty point of view. The problem associated with this method is that whenever IC is replaced in the field at service stations, IC shall be reprogrammed with the correct total distance traveled (or odometer) value. There is always possibility of error in writing the odometer value after replacing the IC.


OBJECTS OF INVENTION
The main object of invention is to improve reliability of vehicle speed and odometer function in the vehicle by distributing these functions over different electronic control units (ECU).
The advantages of the proposed 'invention are that, the vehicle speed and odometer functions can be implemented across all vehicle variants with minimum integration cost. There will be no need to separately program the instrument cluster with the odometer (or total distance traveled) value, even if the instrument cluster is replaced in a used vehicle at service station. This improves the reliability of vehicle speed and odometer functionality of the vehicle in the field.
BRIEF DESCRIPTION OF INVENTION
The proposed methodology aims to improve the reliability and robustness of vehicle speed and odometer functions by distributing them over different electronic control units (ECUs). Two major vehicle variants are considered, vehicle variant with and without brakes controller. The functional distributions for both the vehicle variants are proposed to achieve cost reduction, complexity reduction for the vehicle. Also, proposed invention includes method for automatic learning of main odometer and trip odometer values by instrument cluster. This will avoid manual programming of odometer values in the field during replacing instrument cluster in the vehicles.
BRIEF DESCRIPTION OF DRAWINGS
Figure 1 shows the system flow diagram of vehicle speed and odometer functionalities for vehicle variants with ABS/ESP ECU.
Figure 2 shows the system flow diagram of vehicle speed and odometer functionalities for vehicle variants without ABS/ESP ECU.
Figure 3 shows event driven CAN communication to exchange Odometer data in the beginning and end of ignition cycle.


DETAILED DESCRIPTION OF INVENTION
The focus of proposed methodology is to improve reliability of vehicle speed and odometer functions by distributing them over several electronic control units (ECU).
Let us consider vehicle variants with and without brakes controller (i.e. anti-lock braking system or ABS ECU, electronic stability program or ESP ECU). Typically ABS/ESP ECU needs four wheel speeds as input, so the vehicle variant with ABS/ESP ECU will have four wheel speed sensors. At the low end of the vehicle variants where ABS ECU is not present, four wheel speed sensors need not be integrated in the vehicle. It is sufficient to integrate only one vehicle speed sensor in the low end vehicle variant, So, basically there are two major types of vehicle variants:
• Vehicle variant with brakes ECU (i.e. ABS/ESP), Four wheel speed sensors are present in these vehicle variants
• Vehicle variant with out any brakes ECU. Wheel speed sensors are not present in these vehicle variants. Only one vehicle speed sensor is present.
The invention suggests the following method of realization of vehicle speed and odometer functionalities considering the above two major types of vehicle variants.
Following is the suggested method for vehicles equipped with brakes controller:-
• In vehicle variant with brakes ECU, ABS/ESP is the owner of the
vehicle speed and odometer function. As explained in figure 1, ABS/ESP ECU
receives the four wheel speed signals and wheel speeds are calculated by using the
impulses from the wheel speed sensors with correlated time information. The four
calculated wheel speeds shall be used to calculate vehicle speed and status
information indicating whether vehicle speed is valid or implausible. In healthy
condition the vehicle speed computed by ABS/ESP ECU shall be the average of 2
wheel speeds. Depending on the driving axle, a detected wheel speed sensor fault
different wheel speed signals shall be used to compute vehicle speed output. This

shall be done as per table -I for a rear axle driven vehicle. The wheels which are marked valid in the table -1 are used to calculate the vehicle speed output signal. For example the default choice rear axle driven vehicle is that vehicle speed output signal is the average of rear left and rear right wheel speeds. If rear left wheel speed sensor failure is detected then vehicle speed output shall be computed as average of front left and rear right wheels speeds. The other conditions in the table need to be inLerpreted in the same manner. The Abbreviations used in the table are as follows
WSS wheel speed sensor
PL = front left
FR front right
RL = rear left

Tabic 1: Vehicle speed computation from wheel speed sensors
RR rear right


• The vehicle speed computed in rpm needs to be multiplied with the actual wheel si/e of the vehicle to calculate actual vehicle speed in m/s. To simplify the vehicle end of line process, the actual wheel size is only flashed in engine management system (RMS) ECU only and not flashed in ABS/ESP. ABS/ESP computes the vehicle speed in m/s by using a fixed wheel size. As the vehicle speed computed by ABS/ESP docs noi account for actual wheel size of the vehicle it is called as un-calibrated vehicle speed output.
• Using this un-calibrated vehicle speed signal ABS/ESP ECU computes the distance rolling count data, after reaching the maximum value it resets to zero.
• EMS receives both un-calibrated vehicle speed and distance rolling count signals from ABS/ESP. As EMS uses the correct scaling factor to convert un-calibrated vehicle speed to calibrated vehicle speed which corresponds to actual wheel size of the vehicle, instrument cluster receives correct vehicle speed signal from EMS over CAN network and use it for display.
• EMS (IC) shall receive distance rolling count data from EMS over CAN. EMS shall compare current received rolling count data with the last received roiling count data.
• If Ihe current received value is greater than or equal to last received value then the delta distance traveled (or delta odometer) is calculated as follows:
• Delta odometer - current rolling count data - last rolling count data
• If the current received value is less than the last received value then the rolling count data has wrapped around at the maximum limit of the signal range. So, the delta distance traveled (or delta odometer) is calculated as follows:
• Delta odometer - current rolling count data + (Max value of the rolling counter - last rolling count data).
• EMS shall rescale the delta odometer change computed from received distance rolling count data from ABS/ESP to take care of the correct wheel size.
• EMS shall calculate the new distance rolling count signal by incrementing the last EMS odometer signal by the rescaled delta odometer change as follows.

• New EMS distance rolling count value = (old EMS odometer value + reseated delta odometer change) Mod by maximum value of distance rolling counter
• The distance rolling count value determined by EMS takes care of actual wheel size of the vehicle. EMS transmits the distance rolling count value computed by EMS over CAN and 1C receives the same.
Following is the suggested method for vehicles not equipped with brakes controller:-
• As explained in figure 2, in vehicle variants without brakes ECU (i.e. without ABS/ESP ECU), EMS is the owner of owner of vehicle speed and odometer function.
• To achieve low cost solution for low end vehicles, no wheel speed sensors are connected in these vehicles. Instead only one vehicle speed sensor is connected to EMS. EMS receives the pulse signal from vehicle speed sensor and computes vehicle speed and rolling distance counter. As EMS always has the actual wheel size data, it computes vehicle speed and distance rolling count data as per actual wheel size. Instrument cluster receives these calibrated signals from EMS over CAN network.
• This ensures that for both basic type of vehicle variants, instrument cluster receives information from EMS only over CAN network.
• Usage of only one vehicle speed sensor ensures low cost integration for vehicles without brakes ECU.
As shown in figure I and figure 2, in both the vehicle variants (with and without brakes ECU), IC receives both calibrated vehicle speed and calibrated distance rolling count data from EMS over CAN network. IC directly displays the vehicle speed signal. IC needs to process further the distance rolling count data for odometer display. IC shall follow the following method to improve the reliability of odometer function.
31 MAR 2009

• As explained in figure 1 and figure 2, Instrument cluster (IC) shall receive distance rolling count data from EMS over CAN. IC shall compare current received Tolling count data with the last received rolling count data.
• If the current received value is greater than or equal to last received value then the delta distance traveled (or delta odometer) is calculated as follows:
• Delta odometer = current rolling count data - last rolling count data
• If the current received value is less than the last received value then the rolling count data has wrapped around at the maximum limit of the signal range. So, the delta distance traveled (or delta odometer) is calculated as follows;
• Delta odometer = current rolling count data + (Max value of the rolling counter- last rolling count data).
• IC shall add up all the delta odometer values and compute accordingly main odometer and trip odometer values for display.
• At the end of each ignition cycle, as explained in figure 3, after detecting ignition off, instrument cluster shall transmit the value of main and trip odometer computed for that ignition cycle. Two different ECUs in the CAN network (typically, HMS and body control module, BCM) receive these signals and stores them in their FHPROM. IC also stores the main and trip odometer values in its own FHPROM at the end of ignition cycle.
• To communicate the resulting value of main odometer and trip odometer, IC typically needs to transmit three CAN frames spaced in time with T rns, containing the values of these signals in CAN network. If EMS and BCM receive three consecutive CAN frames T ms after each other and if all the three CAN frames have same value of odometer data, then only EMS, BCM stores the odometer values in their FFPROM. Typical value of T shall he 10ms. After odometer values arc stored in the FFPROM, both F.MS and BCM sends acknowledgement back to IC that odometer values are stored. If IC does not receive the acknowledgement both from EMS and BCM within a configurable time window (typically 100ms) from ignition off. then IC detects an odometer storage failure and corresponding diagnostic trouble code is stored in IC. 'This is explained in figure 3,

• In the next ignition cycle, after detecting ignition on condition, both EMS and BCM reads the main odometer and trip odometer values which were stored in their EEPROM in the last ignition cycle and transmits them back to IC over CAN. EMS, BCM transmits CAN frame containing the odometer values for three times with T ms cycle time. Typical value of T shall be 10ms. IC receives these CAN frames. If it receives three consecutive CAN frames with same odometer values with T ms cycle time, then it uses them for computation in the current ignition cycle. If IC does not receive three consecutive CAN frames with same odometer values from either EMS or BCM within a configurable time window (typically 500ms from ignition on), then IC detects an odometer retrieval failure against EMS or BCM and corresponding diagnostic trouble codes are stored in IC. and IC uses the odometer value written in its own EEPROM for computation in the current ignition cycle. This is explained in figure 3.
• After ignition on, IC aiso reads main odometer and trip odometer values from its own EEPROM. It also receives the CAN frames from EMS and BCM containing the odometer values over CAN. IC compares the odometer values received from EMS, received from BCM, read from its own EEPROM. IC uses the maximum value of the all for processing in the current ignition cycle for display and computation as the vehicle travels. If odometer retrieval failure is detected for either of EMS or BCM, then IC will compare between the only one odometer value received from network (either from EMS or from BCM) and read from its own EEPROM and use the maximum of them for computation in current ignition cycle. If odometer retrieval failure is detected for both EMS and BCM, then IC will use the odometer value read from its own EEPROM and use the same for computation in current ignition cycle.
As engine management system (EMS) gets the total vehicle distance travelled data at the end of every ignition cycle, EMS shall use the same to improve field diagnostics. Whenever EMS detects any functional failure and logs associated diagnostic trouble code in its EEPROM, EMS shall log the main odometer data also as environment

variable data. Whenever EMS ECU will be scanned with any diagnostic scan tool, along the DTC's the odometer data also will be accessed for further analysis.
So, the advantages of the instant invention over the prior art are:
• The proposed method optimizes the EOT activity and takt time as only engine management ECU (i.e. EMS) needs to be flashed with actual wheel size parameter. Other ECUs like ABS/ESP, instrument cluster (IC) need not be flashed with actual wheel size parameter.
• Only one vehicle speed sensor is required for vehicle variants without brakes ECU, it does not need four wheel speed sensors. This results in cost reduction,
• In both the vehicle variants instrument cluster (IC) receives vehicle speed and distance rolling count data from EMS. So, IC is standardized in both vehicle variants,
• In the beginning of every ignition cycle, instrument cluster (IC) learns the value of main odometer and trip odometer from other ECUs in the network and compares the same with the odometer value stored in it. IC uses the maximum of the values for compulation in the current cycle. Whenever any IC is replaced in the field at dealer's end, IC will automatically learn the distance already travelled by the vehicle and use the same. There is no need to manually program the odometer value at service station while replacing IC. This automatic learning of odometer data by IC also eliminates errors due to manual interventions in the field.
• As HMS has the main odometer value at the end of every ignition cycle, EMS also stores the odometer value as an environment variable along with any functional diagnostic trouble code (DTC) detected in that ignition cycle. So, whenever any functional DTC is logged by EMS, it also logs the main odometer value at that ignition cycle. This helps field diagnostics because whenever any functional DTC is read using any scan tool, along with the trouble code the vehicle distance travelled data can also be retrieved for further analysis.


MAIN FEATURE

1. As two other electronic control units (ECUs) in the network also stores the odometer values in their respective EEPROM and communicates the same to instrument cluster (IC) over CAN network, IC automatically learns the main odometer and trip odometer values from the network just after ignition on,
2. As per claim 1, whenever IC is replaced in the field at service station there is no need of manual programming of odometer data in the IC through diagnostic tool. IC needs to be replaced and new IC needs to be connected in the vehicle. Just after ignition on. IC will learn the odometer value and operate with full functionality. As manual intervention is eliminated at service station for reprogramming the odometer values, there will be no errors and mistakes in the field.
3. Proposed method suggests logging odometer values for all critical functional failures by engine ECU. When the vehicle will be diagnosed in the filed, the odometer values also will be available along with different functional diagnostic trouble codes. This will provide important information at service on distance traveled by the vehicle when the concerned diagnostic trouble code was logged,
4. Proposed method optimizes vehicle end of line activities as it recommends configuring actual wheel size only in engine management controller. It is not needed to be configured in other electronic control units (ECUs) in the vehicle.
5. Proposed method results in cost reduction as it recommends using only one vehicle speed sensor for low end vehicles without brakes controller without reducing the robustness of vehicle speed and odometer functionalities.
Dated this 31st day of March 2009
TATA Motors Limited By their Agent & Attorney

(Karuna Goleria)
of De PENNING & De PENNING
31 MAR 2009