FORM 2
THE PATENTS ACT, 1970
(39 of 1970) & The Patens Rules 2003
COMPLETE SPECIFICATION
(SECTION 10 and Rule 13)
TITLE
"Electronic Control Unit Having Curve Data In Polar Coordinate System"
APPLICANT
We, Robert Bosch India limited, having Our Principal Place of Business At 123, Industrial Layout, Housur Road, Koramangala, Bangalore - 560 095, State of Karnataka, an Indian Company.
We, Robert Bosch GmBh, a company incorporated under the laws of Germany having its pricipal place of business at Stuttgart, Feuerbach, Germany.
The following specification describes and ascertains the nature of this invention and the manner in which it is to be performed:-

Background of Invention:
With the introduction of Electronic Control Units becoming more and more critical in almost every field, the reduction of memory used to store the data is gaining vital Importance. In typical ECU applications Curve-Data is one of the major contributors occupying considerable amount of memory. A Curve stored in the ECU can be described as data stored in two rows with a definite number of axis points. In majority of the cases currently, every axis point (x-axis point and y-axis point combined) is stored in four bytes. The work taken up here explores the possibility of using Polar Co-ordinates to store the Curve-Data and there by reduce the memory used for data storage. Hence this emphasizes on an approach of using Polar co-ordinate system instead of Cartesian co-ordinate system to store the curve data and there by reducing the memory consumed.
OBJECT OF INVENTION:
In conventional ECUs of a given flash area, with the introduction of newer functionalities the code part occupies more memory, cramping the memory space for storing the data. While a verity of advancements happening continuously in this field, there is a heavy crunch on memory space for data storage area which means there is an urgent and great need for improvement in the pattern of storing the data in ECU. The main objective of the work taken up is to optimize the storage of data in the ECU and save valuable memory space.
Prior Art:
Some of the current trends in optimization of curve data, focus on removing redundant axis points after analyzing the curve data. In this approach, when there are some flat portions in the curve spanning across more than two axis points then only first and the last axis point of the flat portion is retained and the other axis points with in the flat region are removed. This reduction of the number of axis points in the curve data directly results in saving of memory consumed by those redundant axis points as explained below.
Table 1. Sample curve data with redundant values
With reference to the above mentioned data in table 2, it is very clear that the second and fifth are redundant axis points that can be removed. By removing the redundant data in second and
2

fifth axis points, 8 bytes consumed by them can be saved. Even after their removal, the shape of the curve can be completely reconstructed without any loss. Hence once the calibration of the curve is done and the values are fixed, detailed analysis is performed on the calibrated data to spot the redundant axis points. Once such an analysis is performed and is inferred that the redundancy is consistent for a considerable number of cases, then a decision is made to reduce the number of axis points in order to save the memory consumed.

Table2 Sample curve data after removal of the redundant values
The limitations of the current approach are as follows
• The application of this approach to save memory is restricted to the curves that exhibit redundant values consistently for a considerable number of samples .
• By reducing the number of axis points the freedom offered to the calibration engineer in defining the curve's shape is reduced.
• This approach calls for extensive analysis of the curve data across a lot of sample datasets to confirm the consistency of the behavior. This causes longer lead-times and consumes a lot of effort.
• The knowledge gained after the analysis is applied on the design stage of the further ECUs subject to the conformance of the consistent behavior as exhibited by the sample datasets. Hence there is an element of uncertainty of applying the gained knowledge on the next series of ECUs.
DESCRIPTION OF INVENTION:
With the above mentioned limitations, the application of the current approach confines to a very limited set of curve data resulting in relatively very less gains in memory saving. So this justifies the need for a better approach of reducing the memory to store the curve data that retains the flexibility without reducing the number of axis points and also applicable across curves irrespective of the presence of redundant values. This drives the movement into the polar co-ordinate system. The proposed concept aims at reducing the number of bytes per axis point in order to achieve a considerable saving in the memory by using polar coordinate system.

Main Advantages of the invention are:
• Applicable to all the cases, as this approach is not based on the redundancy of the values in the curve data .
• Savings of up to 12.5%-25% in the curve data can be achieved.
• No loss of axis points and hence flexibility offered for calibration is retained.
• No extra effort needs to be spent in analyzing large samples of datasets. Hence the effort and time involved in analysis is cut down.
• There are no elements of uncertainty and results are guaranteed.
The Concept of working on Polar Co-ordinate System is described herein
By converting the Cartesian co-ordinates (X, Y) into the polar coordinates (r, 0) , the edge gained is that the value of 9 has a very definite range from 0 to 2^ .This definite range offers a golden opportunity to cramp the entire value of 0 less than two bytes. This unique virtue of the polar co-ordinate system exhibits a potential of memory saving up to 25%.
Firstly looking closer at the resolution, it becomes very evident that computing the 0 value without much of a loss is of prime importance. Hence the tan"1 series is used as in eq(5) to determine the value of 0.
0= tanel(Y/X) = (Y/X) - (Y/X)3/3 + (Y/X)5/5 - eq(5)
By attempting to encapsulate the value of 0 in one and half bytes, a saving of half a byte is gained in each axis point. The value of the 0 would be stored in consecutive sequence of bytes such that the first byte and the first half of the second byte would hold the value of 01, 02 would be held by second half of the second byte and third byte and so on. While retrieving the value of 0 the corresponding pair of bytes have to be read and then one of the bytes should be masked with OF or FO accordingly in order to get the value of the nibble. This method of using the nibble offers the opportunity to improve the resolution and also sweep the complete range from 0 to 2^ .


Figure 2. Layout for storing 9 value in 12 bits
As shown in figure2 the layout offers only 12 bits, out of which 2 bits are used to represent the four possible combinations of 0+9, 90+0, 180+9, 270+9, leaving effectively only 10 bits to represent the value of 9. The resolution of 0 value can be written as in eq(6).
Resolution of 9 value in radian = 2p /(210-l) = 0.0061388074291300097751710654936457 eq(6).
As the value of 9 is a floating point value, it can not be stored directly in less than 2 bytes, so only the integer value would be stored which could be written as
n= 9/ 0.0061388074291300097751710654936457
A typical case study is described below
Through this case study, it is elucidated that the curve data when stored in the polar terms can save space. The following curve is taken for the case study having 9 axis points.
X = [ -25.14 -0.14 9.86 14.96 19.96 24.96 39.86 49.86
59.86];
Y= [ 800.0 800.0 800.0 800.0 800.0 900.0 900.0 900.0
900.0];
The storage of Y value in Hex format in the ECU has been explained in the below as Y each value consuming two bytes (03 takes the first byte and 20 the second).Similarly each X values is also stored in two bytes.
0320 0320 0320 0320 0320 0384 0384 0384 038
As the number of bytes allocated for X and Y is done very much earlier to the determination of the values, there is no knowledge of the overall range of the values that would be taken by X and Y for all the curves in a given project. Hence currently, in majority of the cases 2 bytes are allocated at the design stage for both the X and Y value.

This above set of Cartesian Values are converted into Polar Values and the results are
THETA =
1.60221098853652 1.57097132679311 1.55847195081696 1.55209850607201 1.54585150200788 1.54307010043356 1.52653636150903 1.51545289980707 1.50438303187341
RHO =
800.394914776450 800.000012250000 800.060759942643 800.139863773828 800.248962261120 900.346045473628 900.882245135290 901.380063902015 901.988480857710
After identifying the quadrant in which the theta value would lie , the only part of the value that needs to be stored in 1 Obits is the residual part (ie, 0-0, 0-90, 0-180, 0-270 based on the quadrant) which is just the multiple of the resolution value 0.0015345982142857142857142857142857.
Final theta - 20 1023 1016 1011 1007 1006 995 988 980

As the 0 value strictly varies between 0 and 360 and is known at the design stage itself ,it is very convenient to encapsulate this in 1 ½ bytes as in the 12 bit layout.
The last column in the above table makes it very evident that the hex equivalent of the theta value requires only 1 Vi bytes to store and hence saves ½ byte per axis.
Result of the Case Study:
With the Cartesian Co-ordinate system the memory occupied to store the curve having 9 axis points is
Total bytes occupied = (number of points) * (bytes per X-axis point + bytes per Y-axis point)

9 * ( 2 + 2 ) bytes
= 36 bytes.
With the Polar Co-ordinate system the memory occupied to store the curve having 9 axis points is
Total bytes occupied = (number of points) * (no. of bytes for 0 + no. of bytes for rho)
=9 * ( 1.5 + 2) bytes
=31.5 bytes.
Number of bytes saved = bytes consumed in Cartesian system - bytes consumed in polar
system
= 36-31.5 bytes
= 4.5 bytes
% of savings = (Number of bytes saved by moving to polar) / (Total bytes occupied in Cartesian)
= (4.5/36)* 100%
= 12.5 %
Linear Interpolation in Polar Space is also envisaged in the invention:
Another major area of focus is to transform the internal computations done in the Cartesian co-ordinate system on to the Polar co-ordinate system such as linear interpolation. Hence algorithms have been developed for linear interpolation in the polar domain directly without transferring the values on to the Cartesian domain in order to avoid the runtime overhead. For a given pair of Cartesian co-ordinate points (XI,Yl) and (X2, Y2) ,the interpolated value at Xint in cartesian system can be written as
Yint = ((Y2-Yl)/(X2-Xl))Xint + Yl eq(l).
The above equation eq(l) can be written in the polar form by first converting cartesian coordinates (XI,Yl), (X2,Y2) on to the polar co-ordinates (rl, 01), (r2, 02) respectively and then re-writing as
Y int = ((r2*sin02- rl*sinGl) /(r2*cosG2- rl*cos01))*Xint + rl*sin91 ....eq.(2).
For computing the value of Yjnt in the above equation Sin and Cos values of 61 and 92 have to be calculated by the series

sinө = 0 - 03/3! + 05/5! - 07/7! eq.(3).
cosө = 0-02/2! + 04/4!-06/6! !.... eq.(4).
The series is run long enough in order to achieve the desired resolution and the decision of how long the series needs to be run is taken on case by case basis based on the criticality. Only when there is a requirement for linear interpolation to be done, the calculations are performed otherwise there is no runtime overhead.
The invention promises as proposed a solution to one of crucial problems in the area of optimizing the memory occupied by calibrated curve data stored in the Electronic Control Units. Polar coordinate system was chosen as it offered a great potential due to the confined range of 0 which could be compressed.
In the art of storing and analysis of data curves it has been least effort attempted to concentrate on patterns of storing the curve data, but instead various concepts and designs have been developed for improvement in creating new programs based on new demands made for additional control features desired. As such there has been very little improvement or attempt in prior methods in storing the data curve information and so there remains a need for fundamental improvement in the method of storing the curve data information. The present invention overcomes the problems faced in the prior art