FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
PROVISIONAL SPECIFICATION
(See Section 10; rule 13)
TITLE OF INVENTION
Methodology For Automatic Vehicle Variant Learning From In-Vehicle Networks


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
Dibyendu Palai and Jayachandran Duraisamy
Both are Indian Nationals
of TATA MOTORS LIMITED,
an Indian company having its registered office
at Bombay House, 24 Hoini Mody Street, Hutatma Chowk,
Mumbai 400 001 Maharashtra, India
PREAMBLE TO THE DESCRIPTION
The following specification describes invention.


FIELD OF INVENTION
The present invention relates to automatic vehicle variant learning by different electronic control units (ECUs) which are connected with each other through in-vehicle communication bus system. Typically most of the current automotive vehicles are equipped with such in-vehicle network bus system.
BACKGROUND OF INVENTION
With the advent of complex distributed functionalities in the vehicles, number of electronic control units (ECUs) has drastically increased over last couple of decades. These large numbers of ECUs share hundreds of signals with each other over in-vehicle network system. As the numbers of functionalities vary in different variants of the vehicle, the amount of information exchange also varies across different vehicle variant and at the same time different ECUs need to know the vehicle variant related information for proper functioning. This calls for the need of robust vehicle variant handling methodologies for different ECUs in the vehicle.
Existing methodologies typically suggest having different variant of ECUs or different software with different part numbers to be flashed in different variants of ECUs at the vehicle end of line process. This method results in a large number of software variants for ECUs and the variant management becomes complex in end of line and in field service.
Sometimes it is also in practice that different variant codes are defined to identify different vehicle variants. Then these different variant codes are flashed in the ECUs at the vehicle end of line. According to the variant code which is flashed in the ECU, it understands about the vehicle variant where it is integrated and the ECU picks up the proper calibration table to function as per the vehicle variant.

The problems associated with the existing method of variant coding are that if any ECU with incorrect vehicle variant code is fitted at vehicle end of line, then this ECU will not function correctly. Also in the field while replacing any ECU in the vehicle, proper care needs to be taken. If an ECU with incorrect variant code is fitted in the vehicle then the ECU will not function properly. Such types of errors are frequent in the field unt) also in the vehicle end of line.
fhe proposed methodology talks about an alternate approach for automatic self learning of the vehicle variant related information by any ECU fitted in the vehicle. The proposed methodology overcomes the limitations of existing methods.
OBJECTS OF INVENTION
The main object of invention is automatic self learning of vehicle variants by any electronic control unit (ECU) in any ignition cycle. The proposed invention will help to reduce number of variants of ECUs and help in ECU variant handling. Also it will reduce few activities at vehicle end of line process and thereby it will reduce possibility of errors at end of line and also during service at the field.
BRIEF DESCRIPTION OF INVENTION
Recent automotive vehicles are equipped with large number of electronic control units. Typically any vehicle has different vehicle variants, for example high, mid and low end vehicle variants. So, different ECUs in such vehicles need to know the vehicle variant related information for proper functioning. The vehicle variant related information includes information on different engine types, gearbox types, body configurations, etc. ECUs need to handle such type of vehicle configuration related differences.

This could be provided either of the following ways:-
a. Manufacturing of different ECU variants to cater the different vehicle
variants* requirements.
b. End of line (EOL) parameterization to configure the vehicle variant
related information at the end of the vehicle builds.
But all the above mentioned methodologies will result in increase of development cost, piece cost, inventory cost and additional operation at the end of the line. Hence an alternate methodology is proposed and implemented which significantly reduces the ECU variants and completely eliminates the vehicle variant parameterization in any ECU. Thus development cost, inventory cost and additional operational cost is reduced significantly.
The invention proposes a new methodology for automatic self learning of vehicle variant related information by any ECU. Different ECUs need to be connected with each other over in-vehiele network. Typically Controller Area Network (CAN) protocol is used to connect different ECUs over network. ECU will receive vehicle variant related information from CAN network. When the vehicle variant related information is recognized for the first time by reading the variant information from CAN network, that information shall be stored in the EEPROM (electrically erasable and programmable read only memory) of the ECU. From the next ignition cycle ECU will start up with the already learnt vehicle variant related information and function properly. This is called as automatic vehicle variant learning by any ECU. By this approach, the requirement of multiple variants of ECU and additional EOL operational at the end of the line is eliminated.
BRIEF DESCRIPTION OF DRAWINGS
Figure 1 shows the self learning method when the ECU is unlearnt and all other ECUs are connected in the vehicle network and the network is powered up

Figure 2 shows the self learning method after the ECU is learnt with the vehicle variant information and all other ECUs are connected in the vehicle network and the network is powered up.
Figure 3 shows a typical topology of the CAN network where instrument cluster (1C) is connected as a network node.
Figure 4 shows the flow chart for automatic vehicle variant learning for ABS/ESP feature by Instrument Cluster.
Figure 5 shows the flow chart for automatic vehicle variant learning for TOD feature by Instrument Cluster.
Figure 6 shows the flow chart for automatic vehicle variant learning for CC feature by Instrument Cluster.
DETAILED DESCRIPTION OF INVENTION
The focus of proposed methodology is to minimize the need of ECU variants and elimination of end of line (EOF) parameterization to configure the vehicle variant related information inside the ECU at the end of the vehicle build.
To understand the complexity of variant handling which different ECUs need to manage in the vehicle, let us consider a vehicle for example where following broad level features are available in the vehicle: Engine Management System (EMS), Antilock Brake System (ABS), Electronic Stability Program (ESP), Torque On Demand Control (TOD) and Cruise control.
Following table shows the possible combination of a vehicle variant based on the marketing requirement.


Sr. no Possible
vehicle
variants Supported Feature
1
2 Variant #1 EMS

Variant #2 EMS with Cruise control
3 Variant #3 EMS with ABS
4
5 Variant #4 EMS, ABS with
Cruise control

Variant #5 EMS with ESP
6 Variant #6 EMS,ESP with cruise control
7 Variant #7 EMS,ABS with TOD
8
9 Variant #8 EMS,ABS,TOD with Cruise control

Variant #9 EMS,ESP with TOD
10 Variant #10 EMS,ABS,TOD without Cruise control
Tabic 1: Vehicle variant matrix
Let us consider the variant complexity management of Instrument cluster (IC) ECU for such a vehicle. IC needs to know vehicle variant information for display of warning and functional information to driver. Typically most instrument clusters are equipped with initial bulb check functionality and functional telltales just after ignition on. This initial bulb check functionality is required to check whether all necessary telltales in the instrument cluster are working correctly so


thai telltales can provide can provide correct information to drivers. To achieve these functionalities instrument cluster needs to know the vehicle variant related information. To achieve such functionally for any vehicle with ten possible variants, following are the existing approaches.
Approach 1:
Vehicle manufacturer needs to manage design, development and manufacture of len different variants of IC to cater the above requirement. In this case, IC supplier has to manufacture all the ten variants of IC and supply to vehicle manufacturer as per their demand in the production line. And vehicle manufacturer needs to maintain minimum inventory of all ten different IC at their end to fulfill the need of vehicle build and also additional check of ensuring the correct variant of instrument cluster is getting fitted in correct variant of the vehicle. This approach will eventually increase the design cost, piece cost and Inventory cost and additional checking process, at the vehicle end of line,, This will also increase the complexity and possible errors in the field service stations.
Approach 2:
IC can be designed with maximum feature with end of line (EOL) parameterization compatibility at vehicle manufacturer's end. In this approach, different variant codes will be assigned for different vehicle variants. The instrument cluster needs to be programmed with the correct variant code in vehicle end of line. As per the programmed variant code, instrument cluster will pick up the corresponding calibration table and executes its functionality- In this case, vehicle manufacturer will have additional operation at end of the vehicle build to configure the IC feature as per the vehicle variant. This approach will eventually increase the cost for additional operation and equipment and tac time of vehicle build. In service stations in the field this approach calls for need of EOL
3 1 MAR 2009

parameterization equipment if the IC is replaced due to any failure. Also if the instrument cluster is not programmed with the correct vehicle variant code during replacement in the field, the cluster will not function as desired. Hence the management of variant code handling both at vehicle end of line and in the field is a challenge as per this existing method.
As the existing methods suffer from some or the other drawback, an automatic self learning of vehicle variant content method is proposed for ECUs. This methodology meets all the requirement of vehicle variant and eliminates requirement of ten variant of IC or EOL parameterization at end of the vehicle build as per above example.
As per the invention the detailed step by step method of automatic vehicle variant learning is as follows:-
• The different electronic control units (ECUs) which are present in the vehicle need to be connected over vehicle network to share vehicle information. Typically ECUs communicate with each other using controller area network (CAN) protocol.
• The total number of vehicle variants and the detailed configuration of each vehicle variant shall be worked out. Typical vehicle variants could be information on different engine type (i.e. whether diesel engine or gasoline engine is fitted in the vehicle variant), engine volume, whether any special feature like cruise control or engine start stop is present in the vehicle variant, different transmission types (i.e. whether fully automatic transmission or manual transmission is fitted in the vehicle variant), different body configurations, etc,
• Different CAN signals shall be defined to encompass all the vehicle variant related information so that all vehicle variant related


information shall be available in the network. Different CAN signals shall be defined in such a way that by reading those CAN signals it is possible to determine a vehicle variant unambiguously. This means that no two vehicle variant shall not be determined based on same CAN data.
• To determine the vehicle variant, the necessary variant data shall
be available in the network periodically. If the valid variant data is
received over CAN for at least N consecutive cycle times, then
this received data from CAN shall be used to determine the
vehicle variant. The default value of N shall be 3. However
depending on application of the concerned ECU, this value may be
configured.
• Just after start up ECU checks the variant code written in
EEPROM. If the variant code read from EEPROM is equal to OxFF,
then it means no valid variant is learnt yet by the ECU and ECU will
try to learn the variant in the current ignition cycle.
• As soon as a valid variant is recognized in current ignition cycle,
the determined variant code is stored in EEPROM, if the
variant code read from EEPROM at the start up equals OxFF. This is
explained in figure 1. As per figure 1, just after ignition on, OxFF is
read from EEPROM as vehicle variant code. Three consecutive valid
vehicle variant CAN messages are received within 10 sec from
ignition on. ECU is able to determine unique vehicle variant code
and the vehicle variant code is learnt and stored in EEPROM. ECU
continues to remain in limphome mode in the current ignition cycle.
• A failure shall be detected and corresponding diagnostic
trouble code shall be logged by the ECU and ECU shall remain in
limphome mode if one of the following occurs:

o If the ECU fails to learn vehicle variant related information
within the configured learning time period Tlearing from the I ignition on detection. This may happen if the ECU does not receive necessary CAN signals after start up. The default value of Tlearing shall be 10 sec. However depending on system specific requirements, the value of Tlearning shall be configured.
o If the ECU does not receive same variant data for at least N consecutive cycles within Tlearning duration after ignition on.
o If the CAN signals received by the ECU does not lead to a valid vehicle variant configuration according to the variant table already programmed in the ECU.
o If the content of the received CAN signal is not valid.
• After successful determination of a valid vehicle variant
related information and it is stored in the EEPROM in form of a
variant code. From the next ignition cycle on words, the learnt
vehicle variant code is directly read from the EEPROM in startup
phase. ECU shall compare the learnt vehicle variant code read from
EEPROM with the variant code determined by received CAN
signals in the current ignition cycle.
• After learning in the next ignition cycle, if the vehicle variant code
read from EEPROM of the ECU and the vehicle variant code
determined from received CAN signals are identical, only then ECU
becomes fully functional. Else ECU shall detect a failure due to
plausibility error and corresponding diagnostic trouble code shall be
logged by the ECU. In this case, the ECU shall remain in limphome
mode and no further learning shall be performed for the rest of the
ignition cycle. This is explained in figure 2. After learning is over, in
the next ignition cycle the already learnt variant code is read and


compared against the determined vehicle variant code and match is found. ECU continues to work in full functional mode. • On a battery reconnect, all previous learning will be erased and the learning of vehicle variant information will start afresh.
When ECU manufacturer will send any ECU to vehicle manufacturer, the variant code which is stored in the EEPROM of that ECU shall be equal to OxFF (i.e. vehicle variant not learnt). At the next power on, the system will detect a variant error and the ECU goes into limphome mode because there is no valid variant read from EEPROM. Once all the E'CUs are connected over CAN network and the system is powered on and if the ECU receives valid variant information on CAN (as per the proposed method), then from the next ignition cycle, the ECU will be fully functional. But if valid information is not received over CAN, ECU remains in degraded mode.
There could be some small number of cases where a valid variant code is memorized, which is not corresponding to any valid vehicle configuration. For example, during bench testing any ECU may end up learning variant equivalent to test setup or if an ECU has been connected to power supply earlier and has accidentally learned a wrong variant. In this case, it is necessary to reinitialize the variant to its unlearnt state OxFF, This can be achieved with a diagnostics tester. During production of a vehicle, the memorizing of a wrong variant code can be ruled out. It shall be ensured that all necessary partner ECUs are available and correctly configured before the ECU starts self learning.
hollowing failure handling mechanism shall be incorporated in the ECU for the
proposed automatic self learning method. Failure shall be detected and
corresponding diagnostic trouble code shall be logged if any of the following
occur;-
• The variant code could not be read from EEPROM.


• An invalid value has been read from EEPROM.
• The variant code read from EEPROM does not comply with the variant code determined from received CAN signals.
• The variant code determined by CAN messages is valid but not released,
• The variant code could not be evaluated within T|eaming seconds after startup.
After detection of any of the above failure, ECU is degraded and no further learning shall be performed for the rest of the ignition cycle.
Let us consider the following example to explain the invention in detail. As shown in figure 3, let us consider a typical electrical architecture of a vehicle CAN network where Engine Management System (EMS), Antilock Brake System (ABS), Electronic Stability Program (ESP), Torque On Demand Control (TOD) and Instrument Cluster (1C) are connected with each other over CAN network. All ihe above ECU's share information with each other by transmitting and receiving CAN frames over CAN network at every ignition cycle. As the functions in the vehicle has enormously increased, the need has arisen to display more warning and functional information to driver. Also the huge information which is to be displayed to driver in instrument cluster varies across different vehicle variants. Typically in all vehicle variants instrument cluster is present as standard equipment. So, instrument cluster needs to manage all different configurations across all vehicle variants.
It is explained in this example how the proposed automatic vehicle variant learning strategy can be implemented in instrument cluster (IC) which is connected to the vehicle CAN network as shown in figure 3. IC can employ the proposed learning method to learn any vehicle variant out of the vehicle variant matrix. If the vehicle variant is learnt in any ignition cycle after ignition on, then

IC will function as per the learning from the next ignition cycle. This learning is not limited to only the first ignition cycle of the vehicle. Anytime IC detects the respective CAN signal, information related to the vehicle variant will be updated and learnt. The vehicle variant information which is learnt in any ignition cycle will be retained across all future ignition cycles. On a battery reconnect, all previous learning will be erased and the learning of vehicle variant information will start afresh. This 'fresh learning on battery reconnect1 feature allows the use of same instrument cluster (IC) from highest end vehicle variant to lowest end vehide variant without any service person's intervention in the field.
In this example let us consider the learning method for anti-lock braking system and electronic stability (ABS/ESP) feature. IC needs to know whether the vehicle variant is a non-ABS variant or ABS variant or ESP variant. If the vehicle variant is a non-ABS variant then IC will not execute initial bulb check for ABS and ESP telltales. If the vehicle is ABS variant, then IC needs to execute initial bulb check for ABS and brake telltales (FBD), This is because ABS feature is associated with both ABS and EBD telltales. If the vehicle is ESP variant, then IC needs to execute initial bulb check for all three ESP, ABS and brake telltales. The learning strategy of ABS/ESP feature is as follows.
This ESP status signal is transmitted by ESP and received by IC over vehicle CAN network. ESP feature is learnt to be present on the vehicle network when any of
The ESP status signal is defined for CAN communication as follows:



the following data is received over CAN:
a. ESP status signal has data "ESP fully available".
b. ESP status signal has data "ESP switched off due to a system passive
request".
e. ESP .stains signal has data 'ESP switched off due to a detected failure at
ESP system".
The ABS status signal is defined for CAN communication as follows:

B1 BO
* <"■

function
ABS Hilly available

Not Used
Not Used
ABS suiithed oil due to a detected failure at ABS system
This ABS status signal is transmitted by ABS and received by IC over vehicle CAN network. ABS feature is learnt to be present on the vehicle network when any of the following data is received over CAN:
a. ABS status signal has data "ABS fully available".
b. ABS status signal has data "ABS switched off due to a detected failure
at ABS system".
After ignition on, IC wJJJ cheek whether ESP variant is already learnt in previous ignition cycle. If ESP variant is already learnt in previous ignition cycle, then ESP being the superset, IC will understand that all three features i.e. EBD, ABS and ESP exist in the vehicle and execute bulb check for all three telltales in the current ignition cycle. If ESP variant is not learnt in the previous ignition cycle, then IC will check whether ABS variant is already learnt. If ABS variant is already learnt, then JC will understand the vehicle does not have ESP, it has ABS and EBD features and accordingly IC will execute bulb check for ABS and EBD only, it will not execute initial bulb check for ESP in the current ignition cycle. If neither


HSP nor ABS is learnt in previous ignition cycle, then IC will not execute bulb check for ESP, ABS, EBD telltales in the current ignition cycle. IC will then look for vehicle configuration related status signals from ESP or ABS and try to learn ihc vehicle variant in the current ignition cycle. If such signal is received by IC in the current ignition cycle, then ]C will execute bulb check in the next ignition cycle as per the learning of current ignition cycle. This method is explained in detail in form of flow chart in figure 4.
The learning of TOD feature is as follows.
The TOD status signal is defined for CAN communication as follows:

lid

Function

TOD has not delected any failure in tie vehicle system
Not Usee*.
Not Used.
T OD has detected a failure In the vehicle system
This TOD status signal is transmitted by TOD and received by IC over vehicle CAN network. TOD feature is learnt to be present on the vehicle network when any ol the following data is received over CAN:
a. TOD status signal has data "TOD has not detected any failure in the
vehicle system".
b. TOD status signal has data "TOD has detected failure in the vehicle
system".
After ignition on, IC will check whether TOD variant is already learnt in previous ignition cycle. If TOD variant is already learnt in previous ignition cycle, then IC will understand that TOD feature exists in the vehicle and execute bulb check for all TOD lamp in the current ignition cycle. If TOD variant is not learnt in the previous ignition cycle, IC will then look for vehicle configuration related status


signal from TOD and try to learn the vehicle variant in the current ignition cycle. If such signal is received by 1G in the current ignition cycle, then IC will execute bulb check in the next ignition cycle as per the learning of current ignition cycle. This method is explained in detail in form of flow chart in figure 5.
The learning of cruise control feature is as follows.
The cruise control status signal is defined for CAN communication as follows:

This cruise control status signal is transmitted by engine management system (EMS) and received by IC over vehicle CAN network. Cruise control feature is learnt to be present on the vehicle network when any of the following data is received over CAN:
a. Cruise control status signal has data "The cruise control is not active".
b. Cruise control status signal has data "The cruise control is active".
After ignition on, IC will check whether cruise control (CC) variant is already learnt in previous ignition cycle. If CC variant is already learnt in previous ignition cycle, then IC will understand that CC feature exists, in the vehicle and execute bulb check for all CC lamp in the current ignition cycle. If CC variant is not learnt in the previous ignition cycle, IC will then look for vehicle configuration related status signal from EMS and try to learn the vehicle variant in the current ignition cycle. If such signal is received by IC in the current ignition cycle, then IC will execute bulb check in the next ignition cycle as per the learning of current ignition cycle. This method is explained in detail in form of flow chart in figure 6-

By this approach, the requiremen t of multiple variants of IC and additional EOL operational at the end of the line and service station is eliminated. So, the advantages of the instant invention over the prior art are:
• Automatic evaluation of the vehicle configuration is derived from in-vehicle network data.
• The proposed method does not need a special intervention of an external operator to program the variant number either at the vehicle end of line or in the Held at service station.
• The proposed method is the quickest way for the plant to program the variant.
• From the second ignition cycle onwards, the system is fully functional.
• Diagnostics intervention is only needed to recover the initial unlearnt slate. The particular case could be when programmed variant in the ECU is not equal to the learned variant.
• The proposed method improves the usability, reusability, reliability, portability, efficiency, maintainability and functionality of the ECUs connected in the different vehicle variants.
Dated this 3lst day of March 2009
TATA Motors Limited By their agent & Attorney

(Karuna Goleria) of De PENNING & De PENNING