WO2009125178A2

WO2009125178A2 - Apparatus and method for obtaining a value related to carbon emissions resulting from operation of a vehicle

Info

Publication number: WO2009125178A2
Application number: PCT/GB2009/000910
Authority: WO
Inventors: Karl W. Fielder; Adrian Siegrist; Adrian Dickinson
Original assignee: The Neutral Group Limited
Priority date: 2008-04-07
Filing date: 2009-04-07
Publication date: 2009-10-15
Also published as: GB2471629B; WO2009125178A3; GB2471629A; GB201018870D0

Abstract

A method of indicating the fuel efficiency of a vehicle during a journey that is attributable to the driving behaviour of the driver of the vehicle, rather than due to conditions over which the driver has no control is provided. The driver behaviour, evaluation threshold values may be calibrated by performing regression to calculate the fuel efficiency of the vehicle dependent on the driver behaviour and iteratively adjusting the behaviour threshold values by comparing the resulting fuel efficiency with the observed fuel efficiency.

Description

APPARATUS AND METHOD FOR OBTAINING A VALUE RELATED TO CARBON EMISSIONS RESULTING FROM OPERATION OF A VEHICLE

This invention relates to measurement of carbon emissions from a vehicle and. in particular relates to obtaining a value related to carbon emissions resulting from operation of a vehicle.

It is becoming increasingly important to be able to accurately monitor sources of CO₂ emissions from road transportation vehicles in light of the dual concerns of climate change and increasing fuel costs. As result of these concerns, it is desirable to minimise or reduce CO₂ emissions from vehicles. It is known that the manner in which a road vehicle is driven can strongly influence the fuel efficiency of the vehicle and, therefore, the quantity of CO₂ emissions produced by the vehicle. For example, a driver who has a smooth driving style and avoids sudden braking or acceleration will (given an identical vehicle and route) typically use less fuel over a particular journey than a driver with an aggressive or erratic driving style .

Fuel consumption meters are known in the art that comprise a measurement device installed in a vehicle and a visual indicator located on or around the dashboard so as to be visible to a driver when driving the vehicle. The measurement device measures real time engine parameters such as engine speed and mass air flow into the engine and. utilises these parameters to calculate the instantaneous fuel consumption of the vehicle in miles per gallon (MPG) . The visual indicator displays the calculated MPG allowing a driver to monitor their fuel consumption as they drive and learn how their driving behaviour affects fuel consumption (and thus carbon emissions) of the vehicle .

Further known devices that attempt to measure CO₂ emissions resulting from driver behaviour utilize telemetric data to detect negative driver behaviours such as harsh braking, fast starts or other similar aggressive events. The telemetric data may include, for example, accelerometer readings such that when the g-forces on the accelerometer exceed a threshold the device registers an aggressive driving event which is recorded and stored.

The problem addressed by the present invention is how to provide an improved apparatus and method for obtaining a measure of carbon emissions resulting from operation of a vehicle.

It should be noted that in the above introduction and the following text the term ^λ carbon' is used interchangeably with CO₂ and as will be appreciated 'carbon' is intended to have substantially the same meaning as CO₂ throughout .

In one aspect of the invention, this improvement is achieved by processing parameters related to the operation of the vehicle to obtain a value which is indicative of the amount of carbon emissions arising from driver behaviour, rather than a value, as in the prior art, dependent upon total carbon emissions, where said total is dependent upon a combination of the driving environment (such as volume of traffic) , the properties of the vehicle being driven and the behaviour of the driver. Accordingly, this aspect of the invention provides a value which, enables the driver to understand more accurately the way his driving is affecting carbon emission and to adjust his driving in order to minimise it.

According to one aspect, the present invention provides a method of indicating the fuel efficiency of a vehicle during a journey that is attributable to the driving behaviour of the driver of the vehicle, which comprises:

1) receiving data that has been input defining the vehicle type and the loading (if any) of the vehicle ;

2) receiving measured data defining the motion of the vehicle being driven by the driver comprising a series of acceleration values obtained from an accelerometer in the vehicle, and data defining the position of the vehicle obtained from a global position satellite detector, and generating therefrom a measured data file in which the acceleration values and the position values are stored as a function of time;

3) generating for each driver, vehicle type and vehicle loading, a file of useful data in which the measured data has been transformed to generate data that expresses the motion of the vehicle during the journey in terms of parameters that are appropriate for a vehicle journey,-

4) comparing the useful data from the useful data file with data in a behaviour thresholds file that specifies threshold values for the said parameters or parameters derived therefrom that define a plurality of types of driving behaviour, in order to generate a behaviour data file that indicates incidents of each of the predetermined types of driving behaviour;

5) comparing the data in the behaviour data file with data in a data rates table that specifies a fuel efficiency weighting coefficient to be assigned to any incident of driving behaviour of the predetermined type ; and

6) summing the weighting coefficients for all the incidents of driving behaviour of the predetermined types to generate a fuel efficiency value for the journey that is attributable to the driver behaviour .

According to another aspect, the invention provides a system for indicating the fuel efficiency of a vehicle during a journey that is attributable to the driving behaviour of the driver of the vehicle, which comprises :

1) an input device for recording data that has been input defining the vehicle type and the loading

(if any) of the vehicle ,-

2) a measurement device for recording measured data defining the motion of the vehicle being driven by the driver, comprising a series of acceleration values obtained from an accelerometer in the vehicle, and data defining the position of the vehicle obtained from a global position satellite sensor, and for generating therefrom a measured data file in which the acceleration values and the position values are stored as a function of time; and a carbon efficiency analyser which comprises:

3 ) a useful data set generator for generating for each driver, vehicle type and vehicle loading, a file of useful data in which the measured data has been transformed to generate data that expresses the motion of the vehicle during the journey in terms of parameters that are appropriate for a vehicle journey;

4) a behaviour assignment unit data file generator for comparing the useful data from the useful data file generator with data in a behaviour thresholds file that specifies threshold values for said parameters or parameters derived therefrom that define types of driving behaviour, in order to generate a behaviour data file that indicates incidents of driving behaviour of each of the predetermined types ;

5) a carbon score calculator for comparing the data in the behaviour data file with data in a data rates file that indicates a fuel efficiency weighting coefficient to be assigned to any incident of driving behaviour of the predetermined type; and

6) a device for summing the weighting coefficients for all the incidents of driving behaviour of the predetermined types to generate a fuel efficiency value for the journey that is attributable to the driver behaviour.

In another aspect, the invention provides a portable unit for monitoring driver behaviour which may be personal to a driver and is constructed so that it may be installed in different vehicles that a given driver may drive at different times. This is particularly useful for commercial drivers who may drive different vehicles in a fleet at different times.

In yet another aspect, the invention provides a calibration method and system for calibrating the portable unit for use with a particular combination of driving environment and vehicle properties, the calibration of the portable unit permitting calculation by the portable unit of an improved value which is a more accurate indication of the amount of carbon emissions arising from driver behaviour for the particular combination of driving environment and vehicle properties. This is particularly useful for commercial driving operations where particular vehicles in a fleet may be assigned to particular delivery routes.

Thus, the invention provides a method of calibrating driver behaviour threshold parameters that define different types of driving, and which are employed to determine a carbon score, which is a value of the fuel efficiency of a vehicle during a journey that is attributable to the driving behaviour of the driver, which comprises:

1) defining the overall fuel efficiency of the vehicle (in terms of distance travelled per quantity of fuel) as being given by the weighted sum of the carbon score and of a plurality of terms that are independent of the driving behaviour;

2) performing a regression to calculate initial coefficients to be multiplied with each of the terms in the weighted sum that are independent of the driving behaviour and with the carbon score that minimise the error between the defined overall fuel efficiency value and the observed overall fuel efficiency value that has been obtained from a number of journeys ; 3) storing data defining the error;

4) adjusting the behaviour threshold parameters by a predetermined amount and re-calculating the carbon score using the adjusted threshold parameters; 5) repeating the regression to determine new coefficients to be multiplied with the recalculated carbon score;

6) selecting a set of coefficients to be multiplied with the terras that minimises the error between the calculated overall fuel efficiency value and the observed overall fuel efficiency value ;

7) performing a regression to calculate new values for the coefficients to be multiplied with each of the terms of the weighted sum that are independent of the driving behaviour and with the carbon score that minimise the error between the defined overall fuel efficiency value and the observed overall fuel efficiency value; and 8) comparing the error value obtained in step

7) with that specified in step 3) and repeating steps 4) to 7) if the difference in error values has reduced by at least a predefined threshold value.

In addition, the invention provides a carrier that carries a computer program comprising computer implementable instructions for answering a computer to perform the driver monitoring and calibration methods of the invention.

Embodiments according to the present invention will now be described by way of example with reference to the following drawings in which:

Figure 1 is an illustration of a first embodiment of the present invention comprising a road vehicle having a controllable carbon emissions measurement device located inside the vehicle ;

Figure 2 is a block diagram showing the functional components of the measurement device of Figure 1;

Figures 3 and 3b are block diagrams showing the functional components of the 'Measurement Unit' of Figure 2 ;

Figure 4a is a block diagram showing the storage blocks comprising the 'Memory' of Figure 2 ;

Figure 4b is a table illustrating the structure of the 'Behaviour Thresholds Look Up Table' of Figure 4a;

Figure 4c is a table illustrating the structure of the "Behaviour Rates Look Up Table' of Figure 4a;

Figure 5 is a block diagram showing the functional components of the 'Carbon efficiency analyser' of Figure 2 ;

Figure 6a is a block diagram showing the functional components of the 'Useful Data Set Generator' of Figure 5 ;

Figure 6b is an illustration of a data structure that comprises the 'Useful Data' generated by the 'Useful Data Set Generator' of Figure 6a;

Figure 7 is a flow diagram showing the data processing steps performed by the 'Accelerometer Data Generator' of Figure 6a;

Figure 8 is a flow diagram showing the data processing steps performed by the 'Loading Event Detector' of Figure 6a;

Figure 9 is a flow diagram showing the data processing steps performed by the 'Validation Unit' of Figure 6a;

Figure 10a is a block diagram showing the functional components of the "Behaviour Assignment Unit¹ of Figure 5 ;

Figure 10b is an illustration of a data structure comprising 'Behaviour Data' generated by the 'Behaviour Assignment Unit' of Figure 10a;

Figure 11 is a block diagram showing the functional components of the 'Carbon Score Calculator¹ of Figure 5.

Figure 12 is an illustration showing a driver report generated by the 'Report Generator' of Figure 5;

Figure 13 is an illustration showing a system for calibrating the 'Measurement Device' of Figure 1;

Figure 14 is a flow diagram showing the data processing steps performed by the calibration server of Figure 13 ;

Figure 15 is an illustration of a second embodiment of the present invention comprising a 'Measurement Device' located in a delivery vehicle and a distributed system for processing measurement data obtained from the "Measurement Device' ;

Figure 16 is a block diagram showing the functional components of the 'Measurement Device' of Figure 15; and

Figure 17 is a block diagram showing the functional components of the ^λ Carbon Analysis Server' of Figure 15.

OVERVIEW OF FIRST EMBODIMENT

Figure 1 illustrates a first embodiment of the present invention wherein a controllable carbon measurement device 1 is located within a road vehicle 2 being driven by a driver 3. Although a car is shown in Figure 1 it will be appreciated that the measurement device 1 can be used in any road vehicle, such as a delivery truck or a delivery van for the purpose of measuring controllable carbon emissions.

The measurement device 1 is operable to measure data relating to the location and acceleration of the vehicle 2 during a particular journey.

As will be described in more detail below the measurement device 1 is further operable to utilise the measured acceleration and position data to determine a value that is a measure of the controllable carbon emissions produced by the vehicle for a particular journey. Controllable carbon emissions are emissions that are a consequence of the driving style of the driver rather than external factors, such as, the type of vehicle, the loading of the vehicle or the route being driven. A negative score in this context is indicative of increased carbon emissions due to inefficient driving behaviours and a positive score is indicative of reduced carbon emissions due to efficient driving behaviours.

As will be explained in further detail below, in this embodiment the exact position and orientation of the controllable carbon measurement device 1 within the vehicle 2 is not critical to the operation of the device 1 and the driver 3 is free to place the measurement unit 1 wherever it is convenient to do so within the car 2. Further, in this embodiment the device is powered via the cigarette lighter socket of the car (not shown) and accordingly will only operate when it is appropriately connected to the socket .

CONTROLLABLE CARBON MEASUREMENT DEVICE

Turning now to figure 2, a block diagram shows the functional components of the controllable carbon measurement device 1 of figure 1. In particular, the measurement device 1 comprises a measurement unit 4, a carbon efficiency analyser 5 and a memory 6. The measurement unit 4 is operable to measure position and acceleration data at regular predetermined time intervals and the memory 6 is operative to store the measured data. The measured data is retrieved from the memory 6 upon completion of a journey by the carbon efficiency analyser 5 which then utilises the measured data in addition to route and vehicle specific behaviour parameters, also stored in the memory 6, to calculate a carbon score that is a measure of the controllable carbon emissions produced by the vehicle during that journey.

The output of the measurement unit 4 is connected to a central processing unit (CPU) 7 via an input/output interface 8. The memory 6 and the carbon efficiency analyser 5 are connected via respective bi-directional data buses to the CPU 7. The CPU 7 is operable to retrieve and store data in the memory 6 from the measurement unit 4 (which communicates with the CPU 7 via the I/O interface 8) and the carbon efficiency analyser 5. Further, the device 1 also comprises a user interface comprising an input device 9 and a display 10. The output of the input device 9 is connected to the I/O interface 8 while an output of I/O interface 8 is connected to the input of the display 10. Both the input device 9 and the display 10 are operable to communicate with the CPU 7 via the I/O interface 8. The input device 9 may be for example a numeric keypad or a group of arrow keys and a selection button that would facilitate, for example, selection by the user of options via a drop down menu displayed via the display 10.

The input device 9 allows a driver to input information relating to external factors that effect fuel consumption (and thus carbon emissions) such as, for example, the vehicle type that the device is placed in and the route that the driver is about to take. The entered information can then be stored in the memory 6 by the CPU 7 for subsequent use by the carbon efficiency analyser 5 in calculating a measure of the controlled carbon emissions. The display 10 is operable to display results generated by the carbon efficiency analyser 5 and a suitable user interface facilitating entry of the relevant information relating to external factors via the input device 9.

The controllable carbon measurement device 1 of this embodiment is, therefore, a completely self contained device that can be used when driving in any vehicle to record and calculate a measure of the controllabe carbon emissions made during a particular journey undertaken by a driver of that vehicle. Calibration of the carbon score that is a measure of controllable carbon emissions is facilitated by the entry by the user of route, loading and vehicle information via the input device 9. Ideally, each driver will have their own personal device 1 so that they can measure and record an individual objective measure of their controllable carbon emissions for all journeys they undertake regardless of vehicle, loading or route .

MEASUREMENT UNIT

The structure of the measurement unit 4 of Figure 2 shall now be described with reference to the block diagram shown in Figure 3. As shown the measurement unit 4 comprises a three dimensional (3D) accelerometer 301 and a Global Positioning Satellite

(GPS) receiver 302. A clock 303 is connected to both the 3D accelerometer 301 and the GPS receiver 302. The GPS 302 and accelerometer 301 are configured to regularly measure acceleration and position respectively at a predetermined time interval. To do this they require a clock signal to provide the necessary timing information. The clock 303 , therefore, provides the required clock signal to both the GPS 302 and the accelerometer 301. In addition to ensuring that measurements are taken at regular intervals having a common clock signal also ensures that the measurements of the accelerometer 301 and the GPS 302 are substantially synchronised. The clock 303 is configured to provide timing pulses every 0.1s, although as will be appreciated smaller or larger values of t may be selected with the size of t being a trade off between the number of data points that need to be stored and the time resolution of the measurements .

As will also be appreciated by those skilled in the art the 3D accelerometer 301 could be implemented using any of a variety of conventional accelerometer types, for example capacitive or piezo-resistive MEMS (micro electro-mechanical systems) , optical or piezoelectric acceleroraeters . As is conventional acceleration is measured by the accelerometer 301 for each of the X, Y and Z directions in units of g (where g is a unit of acceleration equal to the Earth's gravity at sea level 9.81m/s²) . The maximum resolution the accelerometer for each axis in this embodiment is in the order of O.Olg. The resolution will depend upon other things on the type and specification of accelerometer used. As will further be appreciated by a person skilled in the art, the resolution of the accelerometer is a design trade off between accuracy of the measurements and the cost and complexity of the accelerometer used.

The GPS receiver 302 works in a conventional manner that will be familiar to a person skilled in the art. In particular, it receives position and time data from a plurality of satellites (typically 4) and solves for position. In this embodiment the position is given as at the output of the GPS in terms to latitude and longitude in metres.

The outputs of the accelerometer 301, the GPS receiver 302 and the clock 303 are all connected to the input of a data frame assembler 304. The data frame assembler 304 receives the measured data from the accelerometer 301 and the GPS 302 along with the measurement time as provided by the clock 303 and collates this information into a single data point of measured data 305.

The contents of the measured data point 305 are shown in Figure 3b. As shown the measured data point 305 comprises a header file 306 containing the time of the measurement and a body 307 containing latitude and longitude measurements provided by the GPS 302 and X,

Y and Z acceleration measurements provided by the accelerometer 301.

Measured data 305 from the measurement unit 4 is transmitted to the CPU 7 via the I/O interface 8 and stored in measurement file by the CPU 7 in the memory 6. Measurement data continues to be logged and stored in the memory until such time as the user instructs the device to stop measuring data via the input device 9 or the device is disconnected from its power source.

MEMORY UNIT

Turning now to Figure 4, a block diagram is shown which illustrates the different data stores that comprise the memory 6. The memory 6 comprises a measured data store 401 wherein measured data from the measurement unit 4 is stored. Measured data is regularly received by the memory 6 from the measurement unit 4 via the I/O interface 8 and the CPU 7 and added to the contents of a measured data file contained within the measured data store 401. Each measured data file ideally contains data from a single journey and will comprise a header file containing data identifying the date of the measurements, driver identity, the vehicle type, the loading of the vehicle and the route being driven. The vehicle, loading and route data being obtained by the processor 7 from the vehicle and route data stores 402 and 403 which will be explained below. The measured data file stored in the measurement data store 401 is subsequently retrieved from the memory 6 for processing by the carbon efficiency analyser via the CPU 7 when it is performing its analysis .

The memory 6 further comprises a vehicle data store 402 and a route data store 403. These contain data describing the type of vehicle that the device 1 is presently installed in and its loading, and data describing the route on which the vehicle is to be driven respectively. As mentioned above, this data is manually entered via the input device 9 by the driver and is ideally updated by the driver whenever they put the device in new vehicle or change driving route. In addition, the vehicle and data stores 402 and 403 also contain a pre- stored list of possible vehicles and routes respectively. Thus, when a driver wants to update the present vehicle or route data the driver indicates that they wish to do perform an update by selecting an update option from a main menu displayed on the display 10. A respective list of possible vehicles or routes is then displayed to the driver on the display 10 in the form of a drop down menu from which the driver makes a selection utilising the input device 9.

In addition, the memory 6 also comprises two look up tables, a behaviour thresholds look up table 404 and a behaviour rates look up table 405. As will be described in further detail below, the processing performed by the carbon efficiency analyser 5 includes utilising the measured GPS 302 and accelerometer 301 data to categorise each data point as being indicative of a certain type of driving behaviour. Such driving behaviours include, for example, harsh braking events or periods of constant steady acceleration. In performing its analysis the analyser 5 determines if certain measurements, such as the acceleration of the vehicle, exceeds or lies below predetermined threshold values. The classification of a particular type of behaviour will vary depending on factors such as the performance and weight of the actual vehicle being driven, its loading and the demands of the actual route being driven.

In order to take into account these factors different threshold values are utilised for different combinations of vehicles, routes and loadings. In this embodiment, different sets of threshold values corresponding to different vehicle, route and loading combinations are stored within the behaviour thresholds look up table 404. The appropriate threshold values can then be retrieved by using the presently stored vehicle, route and loading values to look up the correct set of values from the table 404.

Figure 4b shows the structure of the behaviour thresholds look up table 404 in this embodiment. The table is indexed by the vehicle 407-01, loading 407-02 and route fields 407-03 and for each set of vehicle, loading and route data there is a corresponding set of behaviour threshold data grouped under the behaviour descriptions 408-01 to 408-08. In this embodiment there are eight behaviour types with threshold parameters dependent on the vehicle, loading and route data, steady speed 408-01, steady braking 408-02, steady acceleration 408-03, coasting 408-04, harsh braking 408-05, harsh acceleration 408-06, high power 408-07 and idling 408-08.

Steady speed 408-01 has a first parameter 408 -Ola that is a threshold for the minimum difference between the maximum and minimum speed in a predetermined time period and a second parameter 408 -01b that is a threshold for the minimum average speed in a predetermined time period.

Steady braking 408-02 has two parameters 408 -02a and 408- 02b that give the maximum and minimum average deceleration thresholds in a predetermined time period respectively .

Steady acceleration 408-03 has a two parameters 408- 03a and 408- 03b that give the maximum and minimum average acceleration thresholds in a predetermined time period respectively.

Coasting 408-04 has a first and second parameter 408- 04a and 408-04b that give the maximum and minimum deceleration thresholds for a predetermined time period. A third parameter 408 -04c gives a minimum speed threshold for the predetermined period of time.

Harsh braking 408-05 has a single parameter 408-05a that gives a minimum deceleration threshold value below which a data point will be assigned as a harsh braking behaviour.

Harsh acceleration 408-06 has a single parameter 408- 06a that gives a minimum acceleration threshold value above which a data point will be assigned as a harsh acceleration event. High power 408-07 has a single parameter 408 -07a that gives a minimum threshold value for the product of acceleration and speed above which a data point will be assigned as a high power event.

Finally, idling 408-08 has a first parameter that gives a maximum speed threshold value and a second parameter that gives a maximum average speed threshold.

Each of the different types of behaviour can be categorized as either efficient or inefficient. Further, certain 'inefficient' behaviours have been determined to be more carbon inefficient than others while certain 'efficient' behaviours have been determined to be more carbon efficient than others . For example, harsh acceleration events are deemed to be more costly in terms of carbon emissions than idling, and coasting is deemed to save on carbon emissions more than steady acceleration of the vehicle. In order to take this into account, each behaviour is assigned an individual weighting coefficient which is either positive (for carbon friendly behaviours) or negative (for carbon unfriendly behaviours) . These weighting coefficients are called behaviour rates and like the behaviour thresholds can also be dependent on the vehicle, route and loading of the vehicle . Accordingly, the behaviour rates look up table 405 provides a table containing different sets of behaviour rates corresponding to different combinations of vehicle, route and loading.

Other driving behaviours may be included in the table if desired. For example an over-rewing behaviour type may be included in which the engine speed is inappropriately high, either when the vehicle is in neutral or by use of an inappropriate gear.

Figure 4c shows the structure of the behaviour rates look up table 405. Like the behaviour threshold table 404 the behaviour rates table 405 is indexed by vehicle, loading and route data and contains data fields 408-01 to 408-08 for each of the driving behaviours. In addition, there is one further driving behaviour called defensive urban driving 408-09 which is not featured in the behaviour thresholds table 404. Each field 408-01 to 408-09 contains a coefficient value that is used to weight the score assigned to that behaviour with respect to the other behaviours when calculating the score that is a measure of the controllable carbon emitted by the vehicle. In this embodiment the behaviour fields 408-09 and 408-01 to 408-04 are determined to be efficient behaviours and accordingly have positive behaviour rate values . In contrast, the behaviour fields 408-05 to 408-08 are determined to be inefficient behaviours and accordingly have negative behaviour rate values .

The memory 4 further comprises a carbon scores and driver report store 406 which stores the report related data generated by the carbon efficiency analyser. Such results comprise data including the carbon score calculated as a measure of the controllable carbon emissions and a breakdown of the relative number of driving behaviours carried out by the driver for a particular journey. The report store 406 may also contain, for example, archived results which can be recalled be a user for comparison purposes with, more recent scores or reports .

CARBON EFFICIENCY ANALYSER

Turning now to Figure 5, a block diagram is shown illustrating the functional components of the carbon efficiency analyser of figure 2.

The carbon efficiency analyser comprises a useful data set generator 501, a behaviour assignment unit 504, a carbon score calculator 507 and a report generator

508. The input of the useful data set generator 501 is connected to the output of the CPU 7. The useful data set generator is operable to receive a measured data file 502 from the measured data store 401 of the memory 6 via the CPU 7 and to process the received measured data file 502 utilising the measured data values contained within the measured data file 502 to generate a useful data file 503 comprising of data that can be used to identify various driver behaviours .

The output of the useful data set generator 501 is connected to a first input port 504a of the behaviour assignment unit 504. Further, the output of the CPU 7 is connected to a second input port 504b of the behaviour assignment unit 504. The behaviour assignment unit 504 is operable to receive a useful data file 503 from the useful data set generator 501 and a behaviour thresholds data file 505 from the behaviour thresholds look up table 404 of the memory 6 via the CPU 7.

The behaviour assignment unit is operable to utilise the behaviour thresholds from the behaviour thresholds data file 505 to assign a driving behaviour to each. data point in the useful data file 503. The determined behaviours are compiled into a single behaviour data file 506 which is transmitted from the output of the behaviour assignment unit 504 to both the input of the carbon score calculator 507 and a behaviour input port 508b of the report generator 508.

The carbon score calculator 507 is operable to calculate a value that is a measure of the controllable carbon emissions produced during the journey recorded in the measured data file 502. The carbon score calculator utilises the behaviour data file 506 which contains the number of instances of each particular type of driving behaviour and a behaviour rates file 509 that contains a series of weighted coefficients each corresponding to a particular behaviour type. The carbon score calculator 507 multiplies the number of instances of a particular behaviour type with its corresponding behaviour rate to generate a score. This is repeated for each behaviour type and the resulting scores are summed to produce a carbon score 510 that is an overall measure of the controllable carbon emissions for a particular journey.

The output of the carbon score calculator 507 is connected to a carbon score input port 508a of the report generator 508. The report generator 508 is operable to generate a report 511 that contains a breakdown of the number of instances of each driving behaviour that occurred during the journey and the relative contribution of each type of behaviour to the total carbon score . The report may also contain other information such as the driver ID, the vehicle type, the date (or dates) of the journey, the driving time, average speed and distance travelled. The output of the report generator 508 is connected to the CPU 7 and the report generator 508. The report generator is further operable to transmit the generated driver report 511 to the driver report store 406 of the memory 6.

USEFUL DATA SET GENERATOR

Figure 6a shows a block diagram of the functional components of the useful data set generator 501 of figure 5. As shown, the useful data set generator 501 comprises eight processing units (journey concatenation unit 601, engine inactivity identifier 602, data point reduction unit 603, speed profile generator 604, accelerometer data generator 605, loading event detector 606, speed profile smoother 607 and urbanicity calculator 608) connected in series that process measured data to generate useful data that can be used to assign driving behaviours to each data point of a measured data set and a validation unit 609 connected to the output of the urbanicity calculator 608 that is operable to analyse the generated data to determine if it is within predetermined error limits.

The output of the validation unit 609 is connected to the input of the behaviour assignment unit 504. A useful data file 612 provided at the output of the validation unit comprising a set of useful data generated by the processing carried out by the processing units 601 to 608. Figure 6b shows the content and structure of the useful data file 612. As shown, the header 612a of the generated useful data file comprises the following data fields:

(1) ^x DRIVER ID' ;

(2) ¹DATE' ; (3) 'VEHICLE TYPE' ;

(4) 'ROUTE' ;

(5) 'LOADING' ;

(6) 'WEATHER';

(7) 'DRIVING TIME' ; (8) 'JOURNEY TIME' ; and (9) 'VALID' .

The data for (1) - (6) are obtained from the measured data file, while the data for (7) and (8) is generated by the validation unit 609 by taking the start and end times of the measured data and by totalling the time periods when the engine is determined to be on. The

'VALID' field (9) is assigned a value by the validation unit 609 when it performs its validation algorithm.

The body 612b of each data point in the generated useful data file contains data fields for:

(1) 'TIME' (s) ;

(2) 'DISTANCE FROM BASE' (m) ;

(3) ^Λ SPEED' (mph) ;

(4) 'ENGINE ON' (YES/NO) ;

(5) 'F/B ACCELERATION' (mph s^"1) ; (6) 'L/R ACCELERATION' (mph s^{^1}) ;

(7) ^λU/D ACCELERATION' (mph s^"1) ;

(8) 'URBANICITY' (YES/NO) ; and

(9) 'LOADING EVENT' (EVENT TYPE) .

Time (1) is an average time generated by the data point reduction unit 603 for each consolidated data point. Distance from Base (2) is calculated as part of the processing undertaken by the speed profile generator 604. The Speed (3) is the value of speed calculated by the speed profile smoother 607. The value of the Engine On (4) flag is determined by the engine inactivity detector 602. The F/B, L/R, U/D acceleration values, (5), (6) and (7) are calculated by the accelerometer data generator 605. The value of the Urbanicity (8) flag is determined by the urbanicity calculator 608. Finally, the Loading Event

(9) data is determined by the loading event detection unit 606.

The processing carried out by each of the processing units 601 to 608 will now be described in more detail.

The journey concatenation unit 601 is operable to concatenate two or more sets of data (for example measured data A 610a and measured data B 610b in Figure 6a) measured as separate parts of a single days journey to make a continuous single set of measured data 502. This may be necessary where for example the measurement has been suspended or the device has been turned off in between legs comprising a single days worth of journeys and as a result separate measured data files exist for individual legs of a common journey. The concatenation unit, therefore, generates a joined measured data file 611 that comprises of a single continuous set of measured data. As will be appreciated, where there only exists a single set of measured data, the journey concatenation unit 601 does not perform any processing operation on the data and passes it directly to the engine inactivity detector 602. The engine inactivity detector 602 is operable to calculate at each data point contained within the joined data file 612 the standard deviation σ of the sum of X, Y and Z accelerometer readings over a range of +60 data points starting at the data point of interest. If the standard deviation is below a predetermined threshold value then the engine is determined to be off and if it is above the threshold value then it is determined to be on. An additional field is added to the joined measured data file 610 called 'Engine On' to contain a flag for each data point indicating whether the engine is on or off at that particular point. After determining whether the engine is on or off for a particular data point the engine inactivity detector 602 then assigns a value of 1 or 0 to the 'Engine On' field of the relevant data point indicating whether the engine is on or off respectively. As will be explained below the data in this field is used by a validation unit 609 to perform one of a series of validation steps to determine if the measured data is within a set of error bounds . The modified data file including the engine on data is then output to the data point reduction unit 603.

As mentioned above the time resolution of the GPS 302 is typically less than the accelerometer 301. For example, in this embodiment the GPS typically gives a new reading of position every 2 seconds while the accelerometer gives fresh readings every 0.1 seconds. In order to correct for this disparity the data point reduction unit 603 is operable to reduce the measured data points by consolidating consecutive data points with identical GPS positions into a single data point. More specifically, the data point reduction unit 603 analyses the GPS positions and identifies where there are groups of consecutive data points having the same GPS position. For each identified group of data points an average time T(n) is calculated where n is the index of the data point within the reduced data set. Further, for each group an average value of each of the X, Y, and Z acceleration values is generated. Thus for each consolidated data point has an associated average time T(n), average values of acceleration X(n), Y(n) and Z (n) and latitude and longitude values lat(n) and long (n) denoting a common GPS position.

The reduced set of data points are stored consecutively in a reduced data file which comprises the same header information as the original joined measured data file. The data point reduction unit provides the reduced data file at its output and consequently subsequent processing is now carried out on the data points in the reduced data file 613.

The output of the data point reduction unit 603 is connected to the input of the speed profile generator 604. The speed profile generator 604 is operable to calculate an estimated speed for each data point n in the reduced data file using the GPS position data lat(n), long(n) and the average time T(n) . The latitude and longitude measurements are converted by the speed profile generator 604 from degrees into North (N) and West (W) coordinate values in metres. The North and West coordinate values are generated with respect to an origin given by the starting point of the journey which, for example, could be the location of a truck depot of a delivery business. The converted position data is then used by the speed profile generator 604 to calculate an estimate of the speed at each data point n by calculating the distance between the GPS position at the data point n-1 and the position at data point n+1 (i.e. the data point immediately preceding and following the point of interest) and dividing by the time elapsed between the two data points T (n+1) -T (n-1) in seconds. The resulting speed v(n) is then scaled appropriately to transform the units from metres per second into miles per hour (mph) . This process is repeated for each data point until a complete speed profile is generated for the entire reduced data set. The reduced data set 613 including the generated speed profile and the calculated distance data is provided at the output of the speed profile generator 604 which is connected to the input of the accelerometer data generator 605.

The accelerometer data generator 605 is operable to utilise the generated speed profile and the converted

GPS data to transform the X(n), Y(n), Z (n) accelerometer data at each data point into a set of acceleration data in the actual forward/backward

(F/B) , left/right (L/R) and up/down (U/D) axes of the vehicle that the device 1 is located in. In this way the actual orientation of the accelerometer within the vehicle is compensated for and accurate positioning of the measurement device 1 within the vehicle is not necessary. The transformation of the accelerometer data to the axes of the actual vehicle facilitates the use of the device 1 in a wide variety of vehicles without the need for the precise installation and positioning required by known devices. This allows an individual to have a personal device which can be used in any road vehicle in which the individual undertakes a journey. For example, a delivery driver may drive a variety of different trucks on different routes and in these circumstances it is desirable to record a measure of controllable carbon emissions associated with that individual for all these journeys regardless of the vehicle driven. This is made easy using the device 1 of the present embodiment, however, with a conventional device this would be difficult or impossible because of the complex installation procedure required every time the device is moved to a new vehicle .

The accelerometer data generator replaces the X(n), y(n) and Z (n) acceleration values in the reduced data file with acceleration F/B (mph s^"1) , acceleration L/R (mph s^"1) and acceleration U/D (mph s^"1) respectively. The modified reduced data file 613 is provided at the output of the accelerometer data generator 605 which is connected to the input of the loading event detection unit 606.

The loading event detection unit 606 is operable to execute a drop analysis algorithm utilising the GPS data contained within the reduced data file 613 to ascertain the number of drops made during the journey

(differentiating from interruptions to the GPS signal, short stops and driver breaks where the engine is off) .

As will be described in more detail below, such data can be utilised by a calibration system to calculate an average load of the vehicle utilising the drop profile, the initial loading and route data obtained from a transport management server which can be used for the purpose of generating suitable behaviour rates W

30 and thresholds for a particular route. For example, where the route is a delivery route of a logistics vehicle and goods may be dropped off as part of the route. The output of the loading event detector 606 is connected to the input of the speed profile smoother 607.

The speed profile smoother 607 is operable to analyse the reduced data set and smooth out the calculated speed values v(n) when the acceleration or deceleration are very low. In particular, the speed profile smoother first calculates a moving average speed, mas(T(n)), for each data point. The moving average speed being the average speed over +5 seconds relative to the point of interest. Then a best fit speed is calculated using the following expression:

where ,

T is the time at the relevant data point;

v (T) is the speed at time T(n) generated by the speed profile generator;

mas (T) is the moving average speed at time T; and

f(T)= const.(σ_F/B(T)/σ_n(T)) (2)

where,

σ_F/E<_τ) - standard deviation of F/B acceleration, as derived from the accelerometer readings, over a period of ±6 seconds relative to the data point of interest; and

σ_a(τ) = standard deviation of F/B acceleration, as derived from the GPS readings, over a period of +6 seconds relative to the data point of interest.

The calculated values of v_bestflt (n) are appended to the reduced data file 613 and are used in place of v(n) in subsequent processing with the exception of the identification of idling behaviour as will be explained more fully below. The output of the speed profile smoother 607 is connected to the input of the urbanicity calculator 608.

The urbanicity calculator 608 is operable to determine for each data point in the reduced data set 613 whether the vehicle is driving in areas that deemed to be 'urban' . Urban areas typically have high congestion rates and as a result the driver may be forced to make the vehicle stop and start more in urban areas than when driving in a non-urban environment. As a first processing step the urbanicity calculator adds a data field labelled 'urbanicity' to the measured data file. The data contained in the urbanicity field will be a flag containing the value 1 or 0 that indicates whether the area is urban or non-urban respectively. To determine whether the vehicle is in an urban area the urbanicity calculator 607 performs a two step test for each data point in the reduced data file 613.

In a first step it calculates the average speed from the speed data (as generated by the speed profile generator) for data points covering the period of at least 20 seconds before the data point of interest and data points covering the period of at least 20 seconds after the data point of interest. The urbanicity calculator 608 then determines if the calculated average speed is less than 20mph. If the first test is not satisfied then the urbanicity calculator 608 records a zero in an urbanicity data field in the measured data file to indicate that the vehicle was not in an urban area at this point and then moves on to analyse the next data point.

If the average speed is less than 20mph then the first step of the test is satisfied and the urbanicity calculator proceeds with carrying out the second step of the test. The second step comprises analysing the speed data generated by the speed profile smoother 607 for data points covering the period of at least 40 seconds before the data point of interest and at least 40 seconds after the data point of interest to determine the maximum speed in that period. The urbanicity calculator 608 then determines whether the determined maximum speed is less than 30mph. If it is determined that the maximum speed is above 30mph then as above a zero is added to the corresponding urbanicity field in the measured data file and the next data point is analysed. If it is determined that the maximum speed is less than 30mph then a 1 is added to the corresponding urbanicity field in the measured data file. It will be appreciated that although specific values are given for the average, maximum speed and the associated time periods above other values could be used with said values being chosen based on what values give the best definition of urbanicity when compared with the actual driving environment of a journey. The definition of urbanicity as given above will also categorise areas of slow traffic on motorways or rural areas as urban. This is satisfactory for our purposes because events such as these will have very similar characteristics as urban driving and therefore driving defensively in such areas is also a positive behaviour with relation to controllable carbon emissions .

The validation unit 609 is operable to run a series of validation steps to check that there are not errors in the measured data that indicate that the data is not useful for generating any meaningful measure of controllable carbon emissions. The validation unit 609 adds a value to the header file of the reduced data file 613 that indicates whether the file contains a valid set of data. The validated reduced data file is then provided to the behaviour assignment unit 504 via the output of the validation unit 609.

The processing steps carried out by the accelerometer data generator 605, the loading event detector 606 and the validation unit 609 will now be described in more detail with reference to figures 7 to 9.

ACCELEROMETER DATA GENERATOR

Figure 7 is a flow diagram showing the processing steps performed by the accelerometer data generator when calculating the F/B, L/R, U/D accelerometer data.

In a first step 701 an estimate of the F/B acceleration is made for each data point in the reduced data file. This is done by dividing the estimated difference between speeds v(n+l) and v(n-l) at time T(n+1) and T(n-l) respectively by the elapsed time. The estimated acceleration a (n) , therefore, being defined as follows:

In a second step 702 the angle of turn is calculated by determining the angle between a first line connecting the GPS positions at T(n) and T(n+2) and a second line connecting the GPS positions at T(n) and T{n-2) .

In a third step 703 an estimate of the centripetal acceleration of the vehicle at time T(n) is calculated where centripetal acceleration is defined as:

2.sϊn(angle oftwn(ή) 12).v(n) c(n) = ( 4 ) T(n+ V) - T(n~ I)

In a fourth step 704 a vector estimating the direction of the F/B axis of the vehicle relative to the orientation of the accelerometer is calculated by normalising the weight average cumulative vector defined as :

where N is the total number of data points, X(FB), Y(FB) and Z(FB) are the respective x,y,z components of the FB direction vector, a (n) is the estimated acceleration and X(n), Y(n) and Z (n) are the average acceleration values measured by the accelerometer for a particular data point of index n.

The resulting vector FB is normalised in a conventional manner by dividing each of the vector components X(FB) , Y(FB) and Z(FB) by the magnitude of the vector FB.

In a fifth step 705 a vector estimating the direction of the L/R axis of the vehicle relative to the orientation of the accelerometer is calculated by normalising the weight average cumulative vector defined as :

LR = (6)

where N is the total number of data points, X(LR), Y(LR) and Z(LR) are the x,y,z components of the LR direction vector, c (n) is the centripetal acceleration and X(n) , Y(n) and Z(n) are the average acceleration values measured by the accelerometer for a particular data point of index n. The resulting vector LR is normalised in the same manner as the FB vector.

In a sixth step 706 a second normalised L/R vector LR2={X(LR2) , Y(LR2), Z(LR2)} is generated that is perpendicular and in the same plane as the F/B vector. It is LR2 that is actually used for determining the L/R accelerometer data. The orientation of the first L/R vector LR, generated in the fifth step, relative to the second L/R vector is used by the validation unit 609 to check that the accelerometer has not been moved during the journey thereby invalidating the data. In a seventh step 707 a vector UD defining the U/D axis is generated by the accelerometer data generator 605 using conventional linear algebraic techniques known to those skilled in the art that is perpendicular to both the FB and LR normalised vectors .

In a final step 708 a set of F/B(n), L/R(n), ϋ/D(n) acceleration values are generated from the average X(n), Y(n), Z (n) accelerometer data by calculating the dot products of the FB vector with the X(n) accelerometer value, the LR vector with the Y(n) accelerometer value and the UD vector with the Z (n) accelerometer value respectively. The F/B(n), L/R(n) and U/D(n) acceleration values replace the corresponding X(n), Y(n) and Z (n) values in the reduced data file and the modified reduced data file is provided to the loading event detector 606.

LOADING EVENT DETECTOR

Figure 8 is a flow diagram showing the processing steps carried out by the loading event detector 606 in determining if a drop has taken place.

In a first process step 801, the loading event detector 606 analyses the GPS data to determine periods of time where the GPS 302 loses its lock and there is a break in the GPS data. A break in GPS lock is indicated by the GPS receiver 302 by outputting a string of zeros as the latitude and longitude measurements. The loading event detector determines the position before GPS signal was lost and after it has been reacquired and calculates the distance between these two points. If this distance is greater than a predetermined threshold then processing continues with processing step 803. If the distance is less than the threshold then processing continues at processing step 802.

In a second processing step 802, the loading event detector determines from the engine inactivity data generated by the engine inactivity identifier 602 whether the engine has been switched off for a period greater than a predetermined engine inactivity threshold. The predetermined period is determined by investigating the typical length of time that is required to be registered by the engine inactivity identifier before it can be sure that the engine has actually been switched off. If there is a period of engine inactivity lasting longer than the threshold then processing continues at step 803. If the period of inactivity is less than the threshold then it is determined in step 805 whether there are data points that have not yet been analysed. If there are still remaining data points to be analysed then processing starts again at step 801 if all data has been looked at then processing ends at step 8OG.

In a third step, the length of time that either the GPS lock was lost for (if the determination in the first step 801 was true) or the engine was registered as inactive (if the determination made in the second step 802 was true) is calculated. It is then determined if this period of time is greater than a drop time threshold, where said drop time threshold is a predetermined time period which is sufficient for a drop to have taken place. If the period of time is above the threshold then processing continues at step 804. If the period of time is below the threshold then it is determined in step 805 whether there are data points that have not yet been analysed. If there are still remaining data points to be analysed then processing starts again at step 801 and if all data has been looked a.t then processing ends at step 806.

In a final step 804, the loading event detector 606 determines the distance between the last detected drop and the presently identified potential drop event. If the distance is above a drop distance threshold then it is determined that the two events are sufficiently far apart for this to be a new drop event. The first data point in the period where there is a break in GPS data (if check 801 is true) or the first data point in the period where the engine is turned off (if check 802 is true) is flagged as being a loading event. If the distance is below the drop distance threshold then it is determined in step 805 whether there are data points that have not yet been analysed. If there are still remaining data points to be analysed then processing starts again at step 801 if all data has been looked at then processing ends at step 806. As will be explained in detail below although drop event data is not used in calculating the carbon score by the carbon score calculator, it is used by a calibration system in calibrating the behaviour thresholds for a particular vehicle and route .

VALIDATION UNIT

Figure 9 is a flow diagram showing the processing steps carried out by the validation unit 609 in determining whether a data set is valid. The validation algorithm makes four different checks to ascertain the validity of the data.

In the first step 901 the actual total journey distance is checked against a corresponding route distance value associated with the route that the driver has selected via the input device 9 before setting off on the journey. The actual distance travelled is determined by calculating the sum of the distance data as determined when calculating the speed profile for all data points. This is then compared with the route distance and if the actual distance lies outside a range of +10% of the route distance then the 'VALID' flag of the header file is assigned a value of 1 to indicate that the data set is potentially invalid.

In a second validation step 902 the actual journey time is checked against a corresponding route time associated with the pre-selected route. The actual journey time is compared with the route time and if the actual time lies outside a range of ±10% of the route time then the 'VALID' flag of the header file is assigned a value of 1 to indicate that the measured data set is potentially invalid.

The reason that the data is marked as invalid by the validation unit 609 in the above two cases is that the calibrated behaviour thresholds and rates are dependent on the route being driven. If the driver has in fact driven a different route or undertaken an irregular journey then the calibrated thresholds and rates will no longer be valid for that journey which would lead to an erroneous measure of controlled carbon emissions being calculated by the carbon score calculator 507.

In a third validation step 903 the total sum of the F/B (n) acceleration is summed for all data points . For a valid set of data the speed at the start and end of the journey will be zero and therefore the total acceleration should also be zero. Thus, the third step checks that the sum is greater than a threshold value set close to zero (a threshold greater than zero is required to account for any potential measurement errors) then the data is flagged as invalid. In this embodiment the threshold value is 10E-3 but as will be appreciated other threshold values close to zero could be used.

In a final step 904, the validation unit 609 checks the orthogonality of the first L/R axis relative to the F/B axis. The validation unit 609 calculates the angle between the first and second L/R axes LRl and LR2. The validation unit 609 calculates the angle by evaluating the following conventional expression:

If it is determined that the angle is greater than 2 degrees then the data is marked as invalid because this indicates that the measured L/R axis is not orthogonal to the F/B axis which further indicates that the device has been rotated during the journey and thus the measured data set is invalid.

If the validation unit determines that the data has passed all of the validation checks 901 to 904 then the valid field is assigned a value of 0 to indicate that the data file 613 comprises a valid data set.

BEHAVIOUR ASSIGNMENT UNIT

The functional blocks that comprise the behaviour assignment unit 504 are illustrated in Figure 10a.

The behaviour assignment unit comprises a validation checker 1001, a behaviour cascade 1002, a behaviour data assembler 1003 and an end of data checker 1004.

The behaviour assignment unit 504 is operable to receive the useful data file 612 from the output of the validation unit 609 and to read the data contained within the ^λVALID' field of the header file. If the value is 0 then the validation checker 1001 knows that the useful data file 612 contains a valid data set and the validation checker 1001 accordingly passes the useful data file 612 to the assignment cascade for further processing. If the value is 1 then the validation checker 1001 knows that the useful data file 612 contains invalid data and accordingly the validation checker 1001 terminates the processing of the data by carbon efficiency analyser 5.

The behaviour cascade 1002 is operable to perform a sequence of checks to identify whether a data point can be classified as being representative of a particular driving behaviour. Nine behaviour units 1002-01 to 1002-09 are connected in a cascaded arrangement whereby the useful data is provided in sequence from the first unit 1002-01 to the ninth unit 1002-09. Further, a behaviour thresholds file 1005 is provided from the memory 6 via the processor 7 to each of the processing blocks 1002-01 to 1002-09. Where the behaviour thresholds file 1005 contains the relevant threshold parameters for each of the behaviour units 1002-01 to 1002-09. The behaviour units 1002-01 to 1002-09 are operable to utilise the relevant behaviour thresholds to determine whether a data point corresponds to Harsh Braking, High Power, Harsh Acceleration, Idling, Steady Speed, Steady Acceleration, Coasting, Steady Braking or Defensive Urban Driving respectively.

Upon positively identifying its associated behaviour, each behaviour unit is operable to bypass the remaining units in the behaviour cascade 1002 and send the result to the behaviour data assembler 1003, which is operable to flag the relevant data point as having that behaviour. If a behaviour unit does not identify its associated behaviour then the data is passed to the next behaviour unit in the sequence .

The behaviour data assembler 1003, after flagging the relevant data point, then passes the data to end of data checker 1004 which is operable to determine if all the data points have been processed. If there are still data points that have not yet been assigned a behaviour then the flagged data from the data assembler is fed back into the first processing unit 1002-01 of the cascade and processing proceeds for the next data point in the data set. This continues until all the data points have been processed by the behaviour assignment unit 504 at which point the end of data checker passes the resulting behaviour data to the carbon score calculator 507.

The structure of the resulting behaviour data file 1006 is shown in figure 10b. As shown it comprises a header file 1006a that comprises substantially the same data as the useful data file 612 while the body 1006b contains a field containing the time and ten flag fields (Harsh Braking, High Power, Harsh Acceleration, Idling, Steady Speed, Steady Acceleration, Coasting, Steady Braking, Defensive Urban Driving and Other) containing a binary value indicating whether that behaviour has been assigned to that data point by the relevant behaviour unit 1002-01 to 1002-09.

The processing performed by each of the behaviour units 1002-01 to 1002-09 will now be described in more detail.

The idling behaviour unit 1002-01 is operable to generate an idling parameter for each data point in the useful dataset 612. The idling parameter being assigned a value of 1 when the device has not acquired a GPS position for the data point of interest, the speed at the data point of interest is less than the maximum speed threshold 409 -08a and the unsmoothed average speed v(n) (the unsmoothed average speed being the value of v(n) calculate by the speed profile generator 604) at the data point of interest is less than the average speed threshold 408 -08b wherein said thresholds are obtained from the behaviour thresholds file 1005. The latter statement is used to like cases where the GPS position was lost due to for example, the vehicle being in a tunnel which could otherwise appear to be indicating that the vehicle is stationary. The assignment of an idling parameter is performed on the on the first iteration of processing by the behaviour cascade. Thereafter idling can be determined for each data point using the generated idling data.

At each data point it is then determined from the idling data whether the engine has been idling for a period larger than two minutes or has been idling for less than two minutes up until the data point of interest but the idling data for the subsequent data points indicate that idling behaviour will continue for a period of at least two minutes. If either of the above conditions is true then the idling behaviour unit 1002-01 indicates to the behaviour data assembler 1003 that an idling event has taken place for that data point and processing proceeds at the behaviour data assembler 1003. If both conditions are false then processing continues at the high-power behaviour unit 1002-02.

The high power behaviour unit 1002-02 determines whether, for the data point of interest, the product of acceleration F/B(n) and speed v(n) is above the threshold value 408- 07a provided by the behaviour thresholds file 1005. If true then the high power behaviour unit 1002-02 indicates this to the behaviour data assembler and exits the cascade 1002, if it is false then processing proceeds at the harsh acceleration behaviour unit 1002-03.

The harsh acceleration behaviour unit 1002-03 determines whether the F/B(n) acceleration at the data point of interest is above the minimum acceleration threshold value 408 -06a. If true then the harsh acceleration behaviour unit 1002-03 indicates this to the behaviour data assembler and exits the cascade, if it is false then processing continues at the harsh braking behaviour unit 1002-04. The harsh braking behaviour unit 1002-03 determines whether the F/B (n) acceleration at the data point of interest is below the minimum deceleration threshold value 408-06a. If true then the harsh braking behaviour unit 1002-03 indicates this to the behaviour data assembler 1003 and exits the cascade, if false then processing continues at the steady acceleration behaviour unit 1002-04.

The steady acceleration behaviour unit 1002-04 determines for a given data point whether the average F/B (n) acceleration lies between maximum and minimum threshold values 408-03a and 408-03 for a set of data points around the data point of interest covering a period of +3 seconds. Further, it is also operable to determine if there has been no harsh braking or harsh acceleration event in the same period. Finally, it also determines that the speed at the end of the period is higher than the speed at the beginning of the period. The second and third statements above are necessary to avoid false steady acceleration events that are artefacts resulting from the averaging of the acceleration data. For example, if a first data point indicates high deceleration value and the next two points indicate high acceleration values then the arithmetic average will indicate steady acceleration. The third statement is used to rule out artefacts that are due to a road incline, for example, driving at a constant speed uphill will show the vehicle to be accelerating because the accelerometer 301 feels gravity pulling backwards . If the above statements are determined to be true then the steady acceleration unit 1002-05 indicates this to the behaviour data assembler and exits the cascade, if it is false then processing continues at the coasting behaviour unit 1002-06.

The coasting behaviour unit 1002-06 is operable to determine for a given data point whether the F/B (n) acceleration is between the maximum and minimum thresholds 408-04a and 408-04b and the speed v(n) at the given data point is greater than the minimum speed threshold 408-04. In addition, it checks that the speed v(n+l) is lower than v(n-l) , this statement is necessary for the same reasons given for steady acceleration unit 1002-06 above. If the above statements are all determined to be true then the coasting unit 1002-06 indicates this to the behaviour data assembler and exits the cascade, if it is false then processing continues at the steady braking behaviour unit 1002-07.

The steady braking behaviour unit 1002-07 operates in an analogous fashion to the steady acceleration behaviour unit 1002-08 but utilising the max and min average deceleration values 408-02a and 408-02b, checking for no harsh braking events (rather than harsh acceleration events) and checking the speed is lower at the end of the period (rather than higher) .

Further description will therefore be omitted in the interests of brevity. If the analogous statements are determined to be true then steady braking unit 1002-07 indicates this to the behaviour data assembler 1003 and exits the cascade, if false then processing continues at the steady speed behaviour unit 1002-08.

The steady speed behaviour unit 1002-08 is operable to determine if the difference between the maximum and minimum speed in the period of ±10 seconds relative to a data point of interest is lower than a minimum threshold value 408-Ola and to determine if the average speed in the same period is higher than a minimum average speed threshold 408-Olb. If both statements are true then steady speed unit 1002-08 indicates this to the behaviour data assembler 1003 and exits the cascade, if it is false then processing continues at the defensive urban driving behaviour unit 1002-09.

The defensive urban driving behaviour unit 1002-09 is operable for a given data point to determine from the value contained in the urbanicity field corresponding to that data point whether the vehicle is being driven in an urban area or not. If it is determined to be an urban area then the defensive urban driving behaviour unit 1002-09 further determines whether there has been any harsh braking or harsh acceleration behaviours flagged in the data points corresponding to the period +20 seconds relative to the data point of interest. If defensive urban driving behaviour is determined then defensive urban driving unit 1002-09 indicates this to the behaviour data assembler 1003 and exits the cascade, if it not determined then the unit 1002- 09 indicates to the behaviour data assembler 1003 that the behaviour should be flagged as other and also exits the cascade. Processing then continues until all data points have been assessed by the behaviour cascade 1002.

CARBON SCORE CALCULATOR

Turning now to figure 11, a block diagram is shown of the functional components of the carbon score calculator 507 of figure 5. The carbon score calculator 507 comprises a behaviour summation unit 1101, a behaviour score calculator 1102 and a carbon score summation unit 1103. The behaviour summation unit 1101 is operable to calculate the sum of the number of incidents of each type of behaviour as flagged in the behaviour data file 1006. The behaviour summation unit 1101 comprises nine summing units 1101-01 to 1101-09 corresponding to the nine different types of behaviour that can be assigned by the behaviour assignment unit 504. The output of each summing unit 1101-01 to 1101-09 is connected to a corresponding multiplier 1102-01 to 1102-09 in the behaviour score calculator 1102. Each multiplier is operable to multiply the total received from the corresponding summing unit with a corresponding behaviour rate 408-Old to 408-09d. The processor 7 is connected to the input of the behaviour score calculator 1102 and is operable to provide from the behaviour rates look up table 405 stored in memory 6 a behaviour rates file 1104 comprising the corresponding behaviour rates 408-0Id to 408 -09d from the behaviour rate look up table 405.

The outputs of each multiplier 1102-01 to 1102-09 are connected to the input of the carbon score summation unit 1103. The carbon score summation unit 1103 is operable to calculate the sum of the values provided by the multipliers 1102-01 to 1102-09 and the calculated sum is output as the carbon score to the report generator 508.

REPORT GENERATOR

The report generator 508 is operable to take the behaviour data and the calculated carbon score to generate a report including, vehicle, journey and driver details and a breakdown of the contribution of each type of driving behaviour to the carbon score.

Figure 12 shows an example report generated by the report generator 508. As shown, the report comprises the total carbon score 1201 as calculated by the carbon score calculator 507 and the details of the vehicle, route, driving time, distance and driver ID from the header file 1006a of the relevant data set. Further, the report generator 508 generates a carbon score breakdown 1203 showing the score associated with each behaviour type for the journey in question. Finally, the report generator 508 is also operable to generate a pie chart illustrating the proportion of the carbon score associated with each behaviour type and further comprising percentage values to be overlaid on the chart giving the percentage of time spent undergoing each given behaviour type. This allows a user reading the report to easily see the relative inefficiency of some behaviours relative to others. For example, in the report of Figure 12 only 10% of the time was spent coasting but this accounted for a larger score than the 24% of the journey time spent maintaining a steady speed.

BEHAVIOUR THRESHOLDS CALIBRATOR

Turning now to Figure 13 a block diagram is shown of a system for calibrating the behaviour thresholds utilised by the behaviour assignment unit 504 of the carbon efficiency analyser 5. As shown the calibration system comprises a measurement device 1 connected to a calibration server 1301 and a transport management system server 1302 operable to communicate with the calibration server 1301 via network 1303. The calibration server is operable to receive report data from the device 1 comprising behaviour data, carbon scores. The transport management server 1302 is a server containing a database typically maintained by a transport operations company which in this embodiment contains data on the vehicle, route, loading, fuel, weather, distance travelled and corresponding miles per gallon (mpg) data collated for logistics vehicles after performing journeys on predetermined routes .

The calibration unit is operable to calibrate the behaviour thresholds for a particular vehicle type and route utilising the above listed data in order to minimise the influence on the carbon score of the external factors average loading, weather and urbanicity. To perform the calibration it is typically required to have data from a suitably large number of sample journeys undertaken with the same vehicle on the same route over a reasonable amount of time (as for example, weather may only vary significantly over several days) . Taking the example of a logistics operation, two weeks worth of data is has been determined to be a reasonable time period over which to obtain data samples .

Figure 14 is a flow chart showing processing steps performed by the calibration unit in calibrating the behaviour thresholds. An estimated function of mpg can be expressed by: estimated MPG = cl. Average Loading

+ c2.Urbanicity + c3. Weather

+ c4. Carbon Score (8)

where :

"Average Loading' is calculated utilising the loading event data calculated by the loading event detector of the useful data set generator and the start and end loading data provided by the TMS server. Assuming a linear relationship between drops then at each drop event the vehicle unloads a load = (start loading - end loading) /number of drops. Knowing the time of each drop and the amount unloaded at each drop it is therefore straightforward to calculate the average load;

'Urbanicity' in this context is a value related to the percentage of a journey that was classified as an urban area by the urbanicity calculator 608;

'Weather' is a numerical value that is high for bad driving weather (such as windy conditions) and low for good driving weather (dry and clear for example) . The numerical value could comprise, for example, the average wind speed or the amount of rainfall; and

'Carbon Score' is the carbon score for a particular journey undertaken with a particular vehicle and route combination .

In processing step 1401 a regression is performed to calculate the coefficient cl(0) while the rest of the coefficients c2 to c4 are held at zero. Where coefficient cl(O) is the coefficient c that minimises the sum of squares of errors value with respect to the estimated MPG function = c x average loading.

In processing step 1402 a regression is performed to calculate the coefficient c2(0) where c2(0) is the coefficient c that minimises the sum of squares of errors value with respect to the estimated MPG function = c(0) x average loading + c x Urbanicity.

In processing step 1403 a regression is performed to calculate the coefficient c3(0) where c3(0) is the coefficient c that minimises the sum of squares of errors value with respect to the estimated MPG function = cl(0) x average loading + c2(0) x Urbanicity + c x Weather.

In processing step 1404 a regression is performed to calculate the coefficient c4(0) where c4(0) is the coefficient c that minimises the sum of squares of errors value with respect to the estimated MPG function = cl(0) x average loading + c2(0) x Urbanicity + c3(0) x Weather +c4(0) x Carbon Score.

In step 1405 the sum of squares of errors value value for the zeroth iteration is stored by the calibration server 1301.

In step 1406 the threshold parameters are adjusted by ± a variance constant=10% to generate two new sets of threshold parameters one with the threshold parameters increased by +10% and the other with the threshold parameters decreased by -10%. As will be appreciated other values could be chosen for the variance constant and as will be appreciated choice of this value will largely depend on what value gives the best result from experience.

In step 1407 a new carbon score is calculated for each threshold scenario by the calibration server utilising functional modules equivalent to the behaviour assignment and carbon score calculation units 504 and 505 that are used by the measurement device 1 to calculate carbon scores .

In step 1408 the regression step 1404 is repeated for each carbon score to calculate a new value for c4(0) and corresponding estimated MPG functions for each new carbon score.

In step 1409 the best set of threshold values is selected by choosing the set with the corresponding MPG function with the lowest sum of squares of errors value value. The set of coefficients cl to c4 corresponding to the best threshold scenario are then assigned as the values for cl(i), c2(i), c3 (i) and c4(i) to be used in the subsequent regression steps. These coefficients are then used as a base for generating an improved set of coefficients using further regressions steps 1410 to 1413.

In step 1410, coefficient cl(i+l) is calculated where cl(i+l) is the coefficient c that minimises the sum of squares of errors value of the estimated MPG = c x Average Loading + c2(i) x Urbanicity + c3 (i) x Weather + c4 (i) x Carbon Score.

In step 1411, coefficient c2(i+l) is calculated where c2 (i+1) is the coefficient c that minimises the sum of squares of errors value of the estimated MPG = cl(i+l) W

54 x Average Loading + c x Urbanicity + c3 (i) x Weather + c4 (i) x Carbon Score.

In step 1412, coefficient c3(i+l) is calculated where c3 (i+1) is the coefficient c that minimises the sum of squares of errors value of the estimated MPG = cl(i+l) x Average Loading + c2 (i+1) x Urbanicity + c x Weather + c4(i) x Carbon Score.

In step 1413, coefficient c4(i+l) is calculated where c3 (i+1) is the coefficient c that minimises the sum of squares of errors value of the estimated MPG = cl(i+l) x Average Loading + c2(i+l) x Urbanicity + c3 (i+1) x Weather + c x Carbon Score.

In step 1414 the sum of squares of errors value of the MPG function using the coefficients cl(0), c2(0) , c3 (0) and c4(0) is compared with the sum of squares of errors value of the MPG function using the coefficients cl(i+l), c2(i+l), c3 (i+1) and c4(i+l) and if there is an improvement of greater than a minimum improvement threshold which in this embodiment is equal to 5% in the sum of squares then the process proceeds to step 1415 otherwise a new iteration is begun and the process is repeated from step 1406. As will be appreciated other values are possible for the minimum improvement threshold and choice of this value will largely depend on empirical testing to determine a value that gives a suitable improvement in the sum of squares of error values.

At step 1415 the calibration server determines whether the sum of squares of errors of the final MPG function is greater than a threshold, if yes then in step 1416 an error is reported and it may be necessary to review the MPG data for erroneous measurements . If no then in step 1417 the behaviour thresholds and regression coefficients are stored by the calibration server. The calibrated thresholds can then be uploaded to the measurement device and stored in the behaviour threshold look-up table 404 indexed by the associated vehicle, route and loading data.

It is stated above that the threshold parameters are adjusted by a variance constant in step 1406. The threshold parameters may be varied as a whole in step

1406 if desired. Alternatively, it may be preferable to adjust a single threshold parameter only in step

1406, and once the process has reached the end of the flow diagram in step 1417, or between steps 1414 and

1415, to repeat steps 1406 to 1414 in which a different threshold parameter is adjusted by the variance constant. Once all the threshold parameters have been adjusted the process may end at steps 1416 or 1417.

As will be appreciated by a person skilled in the art the regression processes described above can be calculated utilising any of a number of statistical methods known in the art .

SUMMARY AND ADVANTAGES

In this embodiment of the present invention accelerometer (and GPS) measurements are logged at regular intervals regardless of whether an 'event' is detected or not . In this way a complete set of data covering the entire journey undertaken by the driver is recorded. This data is then subsequently analyzed to identify driver behaviours that may include harsh braking/acceleration but also more complex behaviours such as 'defensive urban driving¹ and efficient behaviour such as 'steady acceleration/braking' . Identifying these behaviours would be impossible utilizing the event triggered methods known from the prior art .

Further, by identifying 'urbanicity' , that is areas with, for example, dense traffic or large numbers of traffic signals where normal driving behaviour is difficult, defensive driving can be identified and rewarded accordingly.

In addition, the behaviour thresholds and rates are calibratable for vehicle type, route, urbanicity, average loading and weather. Thus, when calculating the carbon score an objective measure of the carbon emissions resulting from the driver's behaviour can be obtained.

A further advantage is that the orientation of the device in this embodiment is not important because of the inclusion of a accelerometer data generator 603 that is operable to transform the accelerometer data from x, y, z accelerometer readings into front/back F/B(n), left/right L/R(n), up/down U/D(n) acceleration data relative to the orientation of the vehicle. This not only removes the need for accurate installation of the device within a vehicle but also allows the device to be easily transferred from one vehicle to another facilitating scoring an individual's controllable carbon emissions over a range of vehicles and j ourneys . SECOND EMBODIMENT

Figure 15 shows a second embodiment of the present invention. This embodiment comprises a measurement device 1501 is placed within a truck 1502, a 3^rd party- data server 1503, a carbon analysis server 1504 and a transport management system (TMS) server 1505.

The measurement device 1501 is operable to communicate securely with the 3^rd party server 1503 wirelessly via the internet 1504 and in particular to encrypt and send measured accelerometer and GPS data 1505. The 3^rd party server is operable to decrypt and store the received measured data and further to transmit said measured data 1505 to a carbon analysis server 1506 via a first wireless network 1507. The carbon analysis server 1506 is operable to generate a carbon score for a journey corresponding to the received measured data 1505 and to store the results. Further, a transport management (TMS) server 1508 is operable to transmit route, vehicle, weather, loading and MPG data 1509 for a particular journey to the carbon analysis server via a second wireless network 1510.

Figure 16 shows the functional components of the measurement device 1501 of this embodiment. As shown, the measurement device 1501 comprises a measurement unit 1601 an I/O interface 1602, a processor 1603 and a memory 1604. These components operate in a substantially identical manner to the corresponding components of the measurement device 1 of the first embodiment, however, in this embodiment the memory is only used to store measurement data. In addition, the measurement device 1501 further comprises a wireless transceiver 1605 connected to the I/O interface 1602. The transceiver is operable to transmit measurement data stored in the memory 1604 wirelessly over the internet 1504. Further, the processor 1603 is further operable to encrypt data retrieved from the memory 1604 in preparation of wireless transmission of the data by the transceiver 1605. Encryption of measured data is critical where the data being measured comes from delivery vehicles that may contain valuable goods .

Figure 17 shows the functional components of the carbon analysis server 1506. The carbon analysis server comprises a carbon efficiency analyser 1701 and a calibration unit 1702, a memory 1703 and a wireless transceiver 1704 all connected to a processor 1705. The carbon efficiency analyser 1701 contains the substantially the same functional components as the carbon efficiency analyser 5 of the first embodiment. Similarly, the calibration unit 1702 operates in substantially the same way as the calibration server 1301 of the first embodiment except it receives the data it needs to calibrate the threshold parameters from the 3^rd party server 1503 and TMS server 1508. Measurement data is received via the from the 3^rd party server via the transceiver 1704 and then stored in the memory 1703 where it can then be subsequently retrieve by either the carbon efficiency analyser 1701 or the calibration unit 1702.

The second embodiment has the advantage that it only requires a very simple device to be used as the measurement device 1. This means it can be easily and cheaply manufactured or an existing device can be readily adapted to obtain the necessary GPS and accelerometer readings. Further, by managing all the recorded measurement data, for example for a fleet of delivery vehicles, at a single server it is simple to collate large sets of measurement data which can be utilized by the calibration unit 1702 to accurately calibrate behaviour thresholds for delivery route and vehicle combinations specific to a particular logistics operation.

ALTERNATIVE EMBODIMENTS

In the second embodiment described above the data measured by the measurement device is securely transmitted via the internet to a third party server before being sent to a carbon analysis server for further processing. In a further embodiment the measurement device 1501 is operable to securely transmit the measured data directly to the carbon analysis server 1506 without the need for the third party server 1503. Further, in the second embodiment described above, route, vehicle, start and end loading and other journey related data is retrieved by the carbon analysis server 1506 from a transport management server 1508. In a yet further embodiment the carbon analysis server 1506 further comprises the transport management system and there is therefore no need for a separate transport management system server 1508.

In the above described embodiments the carbon score calculator 507 calculates a carbon score by calculating for each behaviour type the product of the number of instances of a behaviour type with a behaviour rate associated with that particular behaviour type and then summing the products . In a further embodiment, instead the product of the total time that the vehicle is determined to have a particular behaviour with the behaviour rate associated with that particular behaviour type is calculated. In this embodiment, the data point reduction unit is further operable to calculate the time elapsed for each consolidated data point. The elapsed time being equal to the number of data points averaged to generate the consolidated data point multiplied by the measurement time interval as determined by the clock 303 of the measurement unit 4. The total time that the vehicle underwent a particular behaviour is calculated by the carbon score calculator 303 by summing the elapsed time values associated with each data point flagged as having that particular behaviour. The elapsed time values will typically be close to the maximum time resolution of the GPS receiver 302.

In the above embodiments the validation unit 609 performs four checks 901 to 904 in order to validate the generated data set . In a further embodiment the validation unit 609 performs a further validation step that utilises the engine activity data generated by the engine inactivity identifier 602 to determine if there are periods of irregular engine activity which may indicate that there has been an error in the data or that there have been excessive periods of idling during the journey. Firstly, the engine activity data is analysed by the validation unit 609 to determine the number of times that the engine was turned off. The validation unit 609 determines if the number of short stationary periods (time less than a predetermined time threshold) where the engine is off is above a predetermined threshold value and if so then flags the data as invalid. To determine if there have been excessive periods of idling, the validation unit 609 further determines if the number of long stationary periods (time greater than a predetermined time threshold) where the engine is on is above a threshold and if so also flags the data as invalid.

In a yet further embodiment the validation unit 609 performs a further validation step to check that the position data of the data set has no significant gaps in it. The validation unit 609 determines the distance travelled between adjacent data points of the reduced data set and checks that the determined distance is less than a maximum distance threshold. Further, the validation unit 609 also determines the time elapsed between adjacent data points and checks that the elapsed time is not greater than a minimum update time which will typically be two seconds. The validation unit 609 then looks at data points where the GPS is acquiring a lock (which is indicated by zeros in the latitude and longitude fields) . If the GPS receiver 302 is acquiring lock then the next position recorded by the GPS receiver 302 must be reachable in the time taken to get the lock otherwise the data must be in error. ThUs₇ the validation unit calculates a speed given by the distance from the last recorded position to the position measured once lock has been reacquired divided by the time taken to reacquire the lock. If this speed is greater than a reference speed (for example 40mph) then the data is deemed to be invalid.

In a yet further embodiment the validation unit 609 is operable to carry out further validation steps as necessary to determine that the measured data does not contain errors and relates to a valid journey. In the above embodiments the calibration unit and server 1301 and 1506 are shown to perform a regression to find the parameters cl, c2, c3 and c4 of the function for estimated MPG given by equation (8) . Equation (8) is a linear combination of the different factors: average loading, urbanicity, weather and carbon score. In further embodiments, in order to have a better function of estimated MPG, the equation (8) may be a multiplicative combination of the different factors or, further, be a mixture of linearly and multiplicatively combined factors or any other combination rather than a linear combination as described in the embodiments above.

In the above embodiments the transport management server provides data relating to the weather for the purposes of calibration of the behaviour thresholds. In a further embodiment, the weather data is obtained from a third party source such as a meteorological office or other similar source either via the internet or a private computer network.

In the first embodiment described above, the user is required to select route, vehicle and loading data before undertaking a journey in order that the device

1 utilises the correct behaviour threshold values and rates . In a further embodiment the user is not required to provide route information in order for the device to operate. In this embodiment the user selects vehicle and loading and corresponding thresholds and rates are retrieved from the look up tables 404 and 405. Further, as no route information is provided the validation unit 609 does not perform the validation steps 901 and 902 as without knowing the route being driven it is impossible to know whether the journey time or distance is reasonable.

Although in the above embodiments the threshold values and rates have been described as being either selectable and/or calibratable depending on factors such as the vehicle, weather, urbanicity and loading that are external to the driving style of a driver further embodiments of the invention is envisaged where said parameters are fixed at manufacture of the device. Although this means the calculated carbon score will not be as accurate such a device has the advantage that it is simpler and does not require any specific calibration or selection of parameters by a user.

In a yet further embodiment the measurement devices 1 and 1501 of the first and second embodiments above may further comprise an engine management unit that is adapted to use the conventional J1939 interface. This may then be used to obtain further telemetric data relating to engine parameters such a temperature, MPG or other engine related data. The engine related data can be stored as part of the measurement data and then potentially utilised as further parameters by the carbon efficiency analyser or the calibration server.

In the above embodiments the high power behaviour is identified by determining if the product of acceleration and speed is greater that a minimum acceleration threshold 408 -06a. The product of acceleration and speed does not give the actual power in the correct physical units but instead is merely an indicator of the power being used by the vehicle . In a further embodiment, a further max power behaviour defined as occurring when the actual power demand from the vehicle is greater than 90% of the vehicles maximum power. The actual power demand of a vehicle is calculated by the useful data set generator 501 and stored in the useful data file 503 for utilisation by the behaviour assignment unit 504. The actual power is calculated by the useful data generator 501 from the following expression .-

P(v,a)= P₀+ v.m.(a+ g.sina)+ v.m.g.(μ_o + μ_vv)+ ~C_w.p.A.v^z [kW] (9)

where ,

P₀ is the basic power consumption when the vehicle is idling;

v is speed v (n) [m/s] ;

m is the total mass of the vehicle which is equal to the mass of the vehicle m₀ plus any load carried by the vehicle;

a+g.sinα is the total F/B(n) acceleration as measured by the accelerometer [m/s²] ;

/X₀ and /X₁ are both friction coefficients,-

c_w is an air drag coefficient;

p is air density [kg/m³] ; and

A is the cross sectional area of the vehicle.

In this embodiment the memory 6 further comprises a vehicle parameter look up table (not shown) comprising a table indexed by vehicle and containing the parameters P₀, m_0< c_w/ A and maximum power P_max for each vehicle. In order to calculate the actual power at each data point the useful data set generator 501 retrieves the relevant parameter values for the presently selected vehicle are from the memory 6 via the processor 7. In order for the behaviour assignment unit 504 to determine whether a max power event has occurred it first retrieves the corresponding max power from the vehicle parameter look up table and determines if P (v, a) /P_max>0.9P_raax. In this way an accurate determination of high power events can be achieved.

In a yet further embodiment the useful data set generator 501 is further operable to generate altitude data derived from the accelerometer , speed and distance data that denotes the change in height at a data point of interest from the previous data point in the set. The change in height is calculated by the useful data set generator from the following expression:

h=d.ήna (10)

where,

a = wccsmy{a_τ ~ a_s ) / gj ( 11) where ,

a_t is equal to the F/B acceleration measured by the accelerometer; a_s is equal to the F/B acceleration generated by the acceleroraeter data generator 605 from the speed profile; and

g is acceleration due to the Earth's gravity at sea level equal to 9.81 m/s^z.

The change in height is calculated over ten second periods in order to smooth out artefacts caused by erroneous acceleration peaks or troughs. The height is then added as a further parameter to the useful data set where it is available for utilisation by the behaviour assignment unit 504 or the calibration device 1301 or 1702.

Although in the above embodiments specific examples of different behaviour types are given, in further embodiments the invention is operable to identify alternative or additional behaviour types with associated threshold parameters calibratable in the manner described for the above embodiments .

Further, although the above embodiments of the invention have been described in terms of road vehicles in yet further embodiments the invention also extends to measurement of controllable carbon emissions from other vehicles such as boats and aeroplanes . In such embodiments the behaviour types would be particular to the operation of the vehicle in question and may require further telemetric data in order to identify vehicle specific behaviours (for example, altitude in the case of an aeroplane) .

Although the embodiments of the invention described with reference to the drawings comprise computer apparatus and processes performed in computer apparatus, the invention also extends to computer programs, particularly computer programs all or in a carrier, adapted for putting the invention into practice. The program may be in the form of source code or object code or in any other form suitable for use in the implementation of the processes according to the invention. The carrier can be any entity or device capable of carrying the program.

For example, the carrier may comprise a storage medium, such as a ROM, for example he CD ROM or a semiconductor ROM, or a magnetic recording medium, for example a floppy disc or hard disc. Further, the carrier may be a transmissible carrier such as electrical optical signal which may be conveyed here electrical or optical cable or by radio or other means .

When a program is embodied in a signal which may be conveyed directly by cable or other device or means the carrier may be constituted by such cable or other device or means .

Alternatively, the carrier may be an integrated circuit which the program is embedded, the integrated circuit being adapted for performing, or for use in the performance of the relevant processes.

Claims

Claims :

1. A method of indicating the fuel efficiency of a vehicle during a journey that is attributable to the driving behaviour of the driver of the vehicle, which comprises :

1) receiving data that has been input defining the vehicle type and the loading (if any) of the vehicle;

2) receiving measured data defining the motion of the vehicle being driven by the driver comprising a series of acceleration values obtained from an accelerometer (301) in the vehicle, and data defining the position of the vehicle obtained from a global position satellite detector (302) , and generating therefrom a measured data file (305,502) in which the acceleration values and the position values are stored as a function of time;

3) generating for each driver, vehicle type and vehicle loading, a file of useful data (503) in which the measured data has been transformed to generate data that expresses the motion of the vehicle during the journey in terms of parameters that are appropriate for a vehicle journey;

4) comparing the useful data from the useful data file with data in a behaviour thresholds file that specifies threshold values for the said parameters or parameters derived therefrom that define a plurality of types of driving behaviour, in order to generate a behaviour data file (506) that indicates incidents of each of the predetermined types of driving behaviour ;

5) comparing the data in the behaviour data file with data in a data rates table that specifies a fuel efficiency weighting coefficient to be assigned to any incident of driving behaviour of the predetermined type ; and 6) summing the weighting coefficients for all the incidents of driving behaviour of the predetermined types to generate a fuel efficiency value for the journey that is attributable to the driver behaviour.

1. A method as claimed in claim 1, which includes the step of generating a report (511) indicating the fuel efficiency value of the vehicle on the journey attributable to the driver.

3. A method as claimed in claim 1 or claim 2 , wherein the step of generating the file of useful data includes the step of converting the acceleration detected by the accelerometer into acceleration values using co-ordinates based on the vehicle as a frame of reference.

4. A method as claimed in claim 3, wherein the step of converting the acceleration detected by the accelerometer into acceleration values using coordinates based on the vehicle as a reference comprises the steps of: a) generating an estimate of the front/back acceleration at each time data point (T (n) ) (701) ; b) calculating an angle of turn at time T(n) (702) ; c) calculating an estimate of the centripetal acceleration at time T (n) (703) ; d) estimating the front/back orientation of the accelerometer by normalising the weight average

X{n) cumulative vector T7∑ a(n).' Y(n) (704)

Z{n) where a{n) is the estimated acceleration, X(n) , Y(n) and Z (n) are the average acceleration values measured by the accelerometer for a data point of index n, and

N is the total number of data points, e) estimating the left/right orientation of the accelerometer by normalising the weight average

cumulative vector — (705)

where c{n) is the centripetal acceleration, and X(n) , Y(n) and Z (n) and N are as defined above . f) redefining the left/right orientation by choosing an axis perpendicular to the front/back axis but in the same plane as the front/back axis and the first estimate of the left/right axis (706) ,- g) estimating the up/down axis as perpendicular to both the front/back axis and the left/right axis

(707) _; and h) generating acceleration values in the front/back, left/right and up/down directions (708) .

5. A method as claimed in any one of claims 1 to 4 , wherein the predetermined types of driving behaviour include all possible types of driving behaviour, so that the behaviour data file covers the entire j ourney .

6. A method as claimed in any one of claims 1 to 5 , wherein the types of driving behaviour are classed as idling, driving at high power, harsh acceleration, harsh braking, steady acceleration, coasting, steady braking and driving at a steady speed. W

71

7. A method as claimed in any one of claims 1 to 6, wherein the types of driving behaviour include a defensive urban driving category in which an average speed over a first predetermined time period is below a predetermined threshold, and a peak speed over a second predetermined time period is below a second predetermined threshold.

8. A method as claimed in any one of claims 1 to 7, wherein the step of generating the file of useful data includes determining whether or not the engine of the vehicle is inactive by recording the sum of the acceleration values in orthogonal directions over a predetermined period of time, recording the standard deviation of the sum of the acceleration values and determining whether or not the standard deviation is below a threshold value .

9. A method as claimed in claim 8, which includes determining whether or not the driver has stopped to drop off or pick up a load, by a) determining whether there is a break in the position data from the GPS detector that is greater than a predetermined time threshold; or b) determining whether or not the engine of the vehicle has been inactive for a predetermined time threshold.

10 A method as claimed in any one of claims 1 to 9, wherein step 1) includes receiving data that has been input defining the route to be taken during the j ourney .

11. A method as claimed in any one of claims 1 to 10, wherein step 1) includes receiving data that has been input defining the weather.

12. A system for indicating the fuel efficiency of a vehicle during a journey that is attributable to the driving behaviour of the driver of the vehicle, which comprises :

1) an input device for recording data that has been input defining the vehicle type and the loading (if any) of the vehicle;

2) a measurement device for recording measured data defining the motion of the vehicle being driven by the driver, comprising a series of acceleration values obtained from an accelerometer (301) in the vehicle, and data defining the position of the vehicle obtained from a global position satellite sensor (302) , and for generating therefrom a measured data file (305,502) in which the acceleration values and the position values are stored as a function of time_/ and a carbon efficiency analyser (5,1506) which comprises :

3) a useful data set generator (501) for generating for each driver, vehicle type and vehicle loading, a file of useful data (503) in which the measured data has been transformed to generate data that expresses the motion of the vehicle during the journey in terms of parameters that are appropriate for a vehicle j ourney ; 4) a behaviour assignment unit (302,504) for comparing the useful data from the useful data file generator with data in a behaviour thresholds file

(404,505) that specifies threshold values for said parameters or parameters derived therefrom that define types of driving behaviour, in order to generate a behaviour data file (506) that indicates incidents of driving behaviour of each of the predetermined types,-

5) a carbon score calculator (507) for comparing the data in the behaviour data file with data in a data rates file (405,509) that indicates a fuel efficiency weighting coefficient to be assigned to any incident of driving behaviour of the predetermined type; and

6) a device (1103) for summing the weighting coefficients for all the incidents of driving behaviour of the predetermined types to generate a fuel efficiency value for the journey that is attributable to the driver behaviour.

13. A system as claimed in claim 12, which includes a report generator (508) for generating a report (511) indicating the fuel efficiency value of the vehicle on the journey attributable to the driver.

14. A system as claimed in claim 12 or claim 13, wherein the processor for generating the file of useful data (503) includes a convertor for converting the acceleration detected by the accelerometer (301) into acceleration values using co-ordinates based on the vehicle as a frame of reference.

15. A system as claimed in claim 14, wherein the processor for converting the acceleration detected by the accelerometer into acceleration values using coordinates based on the vehicle as a reference comprises a device for: a) generating an estimate of the front/back acceleration at each time data point (T(n)) (701) ; b) calculating an angle of turn at time T (n) (702) ; c) calculating an estimate of the centripetal acceleration at time T(n) (703) ; d) estimating the front/back orientation of the accelerometer by normalising the weight average

cumulative vector (704;

where a(n) is the estimated acceleration, X (n) , Y(n) and Z (n) are the average acceleration values measured by the accelerometer for a data point of index n_f and

cumulative vector (705)

where c (n) is the centripetal acceleration, and

X(n), Y(n) and Z (n) and N are as defined above . f) redefining the left/right orientation by choosing an axis perpendicular to the front/back axis but in the same plane as the front/back axis and the first estimate of the left/right axis (706) ; g) estimating the up/down axis as perpendicular to both the front/back axis and the left/right axis (707) ; and h) generating acceleration values in the front/back, left/right and up/down directions (708) .

16. A system as claimed in any one of claims 12 to 15, wherein the predetermined types of driving behaviour include all possible types of driving behaviour, so that the behaviour data file covers the entire journey.

17. A system as claimed in any one of claims 12 to

16, wherein the types of driving behaviour are classed as idling, driving at high power, harsh acceleration, harsh braking, steady acceleration, coasting, steady braking and driving at a steady speed.

18. A system as claimed in any one of claims 12 to

17 , wherein the types of driving behaviour include a defensive urban driving category in which an average speed over a predetermined time period is below a predetermined limit, and a peak speed over a second predetermined time period is below a second predetermined limit .

19. A system as claimed in any one of claims 12 to

18, wherein the processor for generating the file of useful data includes means for determining whether or not the engine of the vehicle is inactive by recording the sum of the acceleration values in orthogonal directions over a predetermined period of time, recording the standard deviation of the sum of the acceleration values and determining whether or not the standard deviation is below a threshold value.

20. A system as claimed in claim 19, which is capable of determining whether or not the driver has stopped to drop off or pick up a load, by a) determining whether there is a break in the position data from the GPS detector that is greater than a predetermined time threshold; or b) determining whether or not the engine of the vehicle has been inactive for a predetermined time threshold. 21 A system as claimed in any one of claims 12 to

20, wherein the input device is operable to receive data that has been input defining the route to be taken during the journey.

22. A system as claimed in any one of claims 12 to

21, wherein the input device is operable to receive data that has been input defining the weather.

23. A system as claimed in any one of claims 12 to

22, wherein the detector is associated with a measurement device (1501) that is separate from the useful data file processor, and is arranged to transmit the measured data to the useful data file processor wirelessly.

24. A method of calibrating driver behaviour threshold parameters that define different types of driving, and which are employed to determine a carbon score, which is a value of the fuel efficiency of a vehicle during a journey that is attributable to the driving behaviour of the driver, which comprises:

2) performing a regression to calculate initial coefficients to be multiplied with each of the terms in the weighted sum that are independent of the driving behaviour and with the carbon score that minimise the error between the defined overall fuel efficiency value and the observed overall fuel efficiency value that has been obtained from a number of journeys (1401-1404) ; 3) storing data defining the error (1405) ;

4) adjusting the behaviour threshold parameters by a predetermined amount and re- calculating the carbon score using the adjusted threshold parameters (1406,1407) ;

5) repeating the regression to determine new coefficients to be multiplied with the recalculated carbon score (1408) ;

6) selecting a set of coefficients to be multiplied with the terms that minimises the error between the calculated overall fuel efficiency value and the observed overall fuel efficiency value (1409) ;

7) performing a regression to calculate new values for the coefficients to be multiplied with each of the terms of the weighted sum that are independent of the driving behaviour and with the carbon score that minimise the error between the defined overall fuel efficiency value and the observed overall fuel efficiency value (1410-1413) ; and 8) comparing the error value obtained in step 7) with that specified in step 3) and repeating steps 4) to 7) if the difference in error values has reduced by at least a predefined threshold value (1414) .

25. A method as claimed in claim 24, which includes the step of determining whether or not the error between the defined overall fuel efficiency value and the observed overall fuel efficiency value is greater than a predefined error threshold (1415) and, if not, saving the behaviour threshold parameters.

26. A method as claimed in claim 25, which includes the step of storing the saved behaviour threshold parameters in a table of a system that is operable to record data relating to the motion of the vehicle and to generate a value of the carbon score by comparing data relating to the motion of the vehicle with the driver behaviour threshold parameters .

5 27. A method as claimed in any one of claims 24 to 26, wherein the terms that are independent of the driving behaviour comprise terms that relate to the average loading of the vehicle, the weather, and the urbanicity which is the proportion of the journey that LO is classified as being in a city as determined from the peak speed of the vehicle and the average speed of the vehicle.

28. A method as claimed in any one of claims 24 to L5 27, wherein the different types of driving behaviour are classed as idling, driving at high power, harsh acceleration, harsh braking, steady acceleration, coasting, steady braking and driving at a steady speed. 20

29. A method as claimed in claim 28, wherein the types of driving behaviour include a defensive urban driving category in which an average speed over a first predetermined time period is below a

25 predetermined threshold, and a peak speed over a second predetermined time period is below a second predetermined threshold.

30. A system for calibrating driver behaviour 30 threshold parameters that define different types of driving, and which are employed to determine a carbon score, which is a value of the fuel efficiency of a vehicle during a journey that is attributable to the driving behaviour of the driver, in which the overall 35 fuel efficiency of the vehicle (expressed in terms of distance travelled per quantity of fuel) is given by the weighted sum of the carbon score and of a plurality of terms that are independent of the driving behaviour; which comprises: 1) means for performing a regression to calculate initial coefficients to be multiplied with each of the terms in the weighted sum that are independent of the driving behaviour and with the carbon score that minimise the error between the defined overall fuel efficiency value and the observed overall fuel efficiency value that has been obtained from a number of journeys (1401-1404) ;

2) a store for data defining the error (1405) ;

3) means for adjusting the behaviour threshold parameters by a predetermined amount and for recalculating the carbon score using the adjusted threshold parameters (1406,1407) ;

4) means for repeating the regression to determine new coefficients to be multiplied with the recalculated carbon score (1408) ;

5) means for selecting a set of coefficients to be multiplied with the terms that minimises the error between the calculated overall fuel efficiency value and the observed overall fuel efficiency value (1409) ; 6) means for performing a regression to calculate new values for the coefficients to be multiplied with each of the terms of the weighted sum that are independent of the driving behaviour and with the carbon score that minimise the error between the defined overall fuel efficiency value and the observed overall fuel efficiency value (1410-1413) ; and 7) means for comparing the error value so obtained with the data defining the error held in the store, and for repeating steps 3) to 6) if the difference in error values has reduced by at least a predefined threshold value (1414) .

31. A system as claimed in claim 30, which includes means for determining whether or not the error between the defined overall fuel efficiency value and the observed overall fuel efficiency value is greater than a predefined error threshold (1415) and, if not, saving the behaviour threshold parameters .

32. A system as claimed in claim 31, which includes a store for storing the saved behaviour threshold parameters in a table of a system that is operable to record data relating to the motion of the vehicle and means for generating a value of the carbon score by comparing data relating to the motion of the vehicle with the driver behaviour threshold parameters .

33. A system as claimed in any one of claims 30 to 32, wherein the terms that are independent of the driving behaviour comprise terms that relate to the average loading of the vehicle, the weather, and the urbanicity which is the proportion of the journey that is classified as being in a city as determined from the peak speed of the vehicle and the average speed of the vehicle.

34. A system as claimed in any one of claims 30 to 33, wherein the different types of driving behaviour are classed as idling, driving at high power, harsh acceleration, harsh braking, steady acceleration, coasting, steady braking and driving at a steady speed.

35. A system as claimed in claim 34, wherein the types of driving behaviour include a defensive urban driving category in which an average speed over a first predetermined time period is below a predetermined threshold, and a peak speed over a second predetermined time period is below a second predetermined threshold.

36. A carrier which carries a computer program comprising processor-implementable instructions for causing a computer to perform a method as claimed in any one of claims 1 to 11 or to act as a system as claimed in any one of claims 12 to 23.

37 A carrier which carries a computer program comprising processor-implementable instructions for causing a computer to perform a method as claimed in any one of claims 24 to 29 or to act as a system as claimed in any one of claims 30 to 35.