active fleet monitoring & reporting...

UNIVERSITY OF STELLENBOSCH

Active Fleet Monitoring & Reporting System

Project E 448

Candidate: Justin Maximilian Schietekat

Study Leader: Thinus Booysen

Date: November 2012

Report submitted in partial fulfilment of the requirements of the module Project (E) 448 for the degree Baccalaureus in Engineering in the Department of Electrical and Electronic Engineering at the University of Stellenbosch.

ii

ACKNOWLEDGMENTS

I would sincerely like to thank Thinus Booysen for all his technical advice and affirmative support.

I would also like to thank MTN and Trinity Telecomms, who enabled and supported this work with their technical and financial assistance.

I would also like to thank both my parents for always being there to listen whenever I would share experiences that excite me.

Lastly I would like to thank Amelia Lötter for her youthful enthusiasm and continuous and unconditional support.

iii

DECLARATION OF AUTHENTICITY

I, the undersigned, hereby declare that the work contained in this report is my own original work unless indicated otherwise.

Justin Maximilian Schietekat

Signature ______________________ Data _____________________

iv

EXECUTIVE SUMMARY Many lives are lost annually on our South African roads due to accidents caused by reckless driving, fatigue, and illegal overloading. Countless innocent victims are subjected to vehicle theft and insurance companies constantly have to battle fraudulent insurance claims due to insufficient evidence. One of the main objectives for the Active Fleet Monitoring & Reporting System is to improve driver safety and drastically reduce road accidents and the unnecessary loss of lives.

Through thorough research it was concluded that none of the current competitors in the vehicle tracking and reporting system industry uses accelerometers to monitor or detect reckless driving. Like other similar devices this project uses global positioning to determine position and velocity but this project also incorporates the use of an accelerometer to report different degrees of reckless behaviour. The use of an accelerometer in such an application adds dimensions of resolution to the data being processed which helps to determine certain driver behaviour.

Multiple valuable conclusions, measurements and derivations where made to advance this innovative exciting aspect of Active Fleet Monitoring & Reporting.

v

UITVOERENDE OPSOMMING Elke dag word daar baie lewens verloor op ons Suid-Afrikaanse paaie as gevolg van ongelukke wat veroorsaak word deur roekelose bestuur, moegheid, en onwettige oorlading. Talle onskuldige slagoffers is onderhewig aan voertuig diefstal. Versekeringsmaatskappye moet gedurig twyfelagtige versekeringseise ondersoek en uitbetaal as gevolg van onvoldoende bewyse. Een van die belangrikste doelwitte vir die aktiewe vloot monitor en verslagleweringsstelsel is om bestuurder veiligheid aan te moedig en om ‘n drastiese verminder in padongelukke en die onnodige verlies van lewens te bewerkstellig.

Deur deeglike navorsing is daar tot die gevolgtrekking gekom dat nie een van die huidige mededingers in die voertuig monitor en rapporteringstelsel-bedryf gebruik maak van versnellingsmeters om roekelose bestuur te monitor of te rapporteur nie. Hierdie projek en toestel, soos soortgelyke toestelle, maak gebruik van globale posisiëringestelsels om posisie en snelheid te bepaal, maar hierdie projek maak ook gebruik van 'n versnellingsmeter om verskillende vlakke van roekelose gedrag te rapporteur. Die gebruik van 'n versnellingsmeter in so 'n kapasiteit voeg dimensies van resolusie by die data wat verwerk word en wat dus help om sekere bestuurder gedrag te rapporteer.

Veelvuldige en waardevolle gevolgtrekkings, metings en afleidings was opgelewer om hierdie innoverende opwindende aspek van die aktiewe vloot monitor en verslagdoening te bevorder.

vi

TABLE OF CONTENTS Executive Summary ...................................................................................................................................... iv

Uitvoerende Opsomming .............................................................................................................................. v

Table of Contents ........................................................................................................................................... vi

List of Tables .................................................................................................................................................. viii

List of Appendix Tables ............................................................................................................................. viii

List of Figures ................................................................................................................................................ viii

List of Equations ............................................................................................................................................... x

List of Flow Diagrams ..................................................................................................................................... x

List of Functional Diagrams ......................................................................................................................... x

List of Abbreviations .................................................................................................................................... xi

1 Introduction ........................................................................................................................................ 1-1

1.1 Overview & Background ......................................................................................................... 1-1

1.2 Objectives & Outcomes ........................................................................................................... 1-1

1.3 Methodology ................................................................................................................................ 1-2

1.4 Digital Demonstration ............................................................................................................. 1-3

1.5 Documentation Layout ............................................................................................................ 1-3

2 Literature Study ................................................................................................................................. 2-4

3 System Specifications ...................................................................................................................... 3-5

3.1 Hardware Specifications ......................................................................................................... 3-5

3.2 Software Specifications ........................................................................................................... 3-5

3.3 Measureable Requirements .................................................................................................. 3-5

4 System Overview ............................................................................................................................... 4-6

4.1 Functional Overview ................................................................................................................ 4-6

4.2 Single System Flow Diagram ................................................................................................. 4-7

4.3 Multiple Asset System Flow Diagram ................................................................................ 4-8

5 Detailed Design .................................................................................................................................. 5-9

5.1 Microcontroller .......................................................................................................................... 5-9

5.2 Accelerometer .......................................................................................................................... 5-12

5.3 GPS ................................................................................................................................................ 5-24

5.4 Secondary Storage .................................................................................................................. 5-27

5.5 Modem ......................................................................................................................................... 5-29

5.6 Web-Interface ........................................................................................................................... 5-32

6 Measurements .................................................................................................................................. 6-36

vii

6.1 Accelerometer: Braking ........................................................................................................ 6-36

6.2 Accelerometer: Turning ........................................................................................................ 6-38

7 Conclusions & Recommendations ............................................................................................ 7-41

7.1 Conclusion .................................................................................................................................. 7-41

7.2 Recommendation .................................................................................................................... 7-41

8 Literature References .................................................................................................................... 8-42

Appendix A Project Management ................................................................................................... A-1

A.1 Gantt Chart ................................................................................................................................... A-1

Appendix B Project Specification .................................................................................................... B-1

B.1 Hardware Specifications ......................................................................................................... B-1

B.2 Software Specifications ........................................................................................................... B-1

B.3 Measureable Requirements .................................................................................................. B-1

Appendix C Specific Outcomes and Assessment Criteria ...................................................... C-2

Appendix D Interface Interpretation ............................................................................................. D-4

D.1 NMEA Sentences ........................................................................................................................ D-4

viii

LIST OF TABLES Table 5-1: Microcontroller Properties ................................................................................................ 5-9

Table 5-2: Preferred Microcontroller Properties ........................................................................... 5-9

Table 5-3: Arduino Mega 2560 Pin Assignments ......................................................................... 5-10

Table 5-4: Interpretation of System Variables .............................................................................. 5-11

Table 5-5: Behavioural Events ............................................................................................................. 5-12

Table 5-6: Accelerometer Sensitivity and Resolution Relationship ...................................... 5-15

Table 5-7: Stopping Parameters under Dry Conditions............................................................. 5-16

Table 5-8: Stopping Parameters under Wet Conditions ............................................................ 5-17

Table 5-9: Minibuses Accident Parameters [13] .......................................................................... 5-17

Table 5-10: Static Acceleration Tilt Answers ................................................................................. 5-22

Table 5-11: GPS Protocol Parameters ............................................................................................... 5-25

Table 5-12: GPS Software Parameters .............................................................................................. 5-26

Table 5-13: Coordinate Format Examples ...................................................................................... 5-27

Table 5-14: RS-232 & TTL Bus Voltage Levels .............................................................................. 5-30

Table 5-15: Frequent AT Messages .................................................................................................... 5-31

Table 5-16: Modem Event Notification ............................................................................................ 5-32

Table 5-17: Modem Data Transfer ..................................................................................................... 5-32

Table 6-1: Differentiator Thresholds ................................................................................................ 6-38

Table 6-2: Differentiator Maximums ................................................................................................. 6-40

LIST OF APPENDIX TABLES Appendix Table C-1: ECSA Exit Level Outcomes Assessed in this Module ........................... C-2

Appendix Table D-1: NMEA GPGGA Global Positioning System Fix Data ............................. D-4

Appendix Table D-2: NMEA GPGLL Geographic Position, Latitude & Longitude ............... D-4

Appendix Table D-3: NMEA GPGSA GPS DOP & Active Satellites ............................................. D-5

Appendix Table D-4: NMEA GPRMC Recommended minimum Specific Transit Data ..... D-5

Appendix Table D-5: NMEA GPVTG Track Made Good & Ground Speed .............................. D-5

LIST OF FIGURES Figure 1-1: Waterfall Model of Software Development [1] ........................................................ 1-2

Figure 5-1: Picture of Arduino Mega 2560 Prototyping Board ............................................... 5-10

Figure 5-2: Picture of MMA7361L Accelerometer Breakout Board ...................................... 5-13

Figure 5-3: Demonstration of Static Acceleration ........................................................................ 5-14

Figure 5-4: Demonstration of Dynamic Acceleration ................................................................. 5-14

ix

Figure 5-5: Angle between Z & X Axis (Roll) .................................................................................. 5-19

Figure 5-6: Angle between Z & Y Axis (Pitch) ................................................................................ 5-19

Figure 5-7: Accelerometer Signal, Static Implementation ........................................................ 5-19

Figure 5-8: Accelerometer Signal before and after LPF, Static Implementation .............. 5-21

Figure 5-9: Accelerometer Signal before and after LPF, Measurement Purpose ............. 5-21

Figure 5-10: Normal Acceleration (X-Axis) .................................................................................... 5-22

Figure 5-11: Tangent Acceleration (Y-Axis) ................................................................................... 5-22

Figure 5-12: Accelerometer Signal before and after LPF, Dynamic Implementation .... 5-23

Figure 5-13: Accelerometer Signal after Differentiator, Dynamic Implementation ....... 5-24

Figure 5-14: ITead Studio GPS Shield & Antenna ......................................................................... 5-25

Figure 5-15: Sierra Wireless AirLink GL6100 ............................................................................... 5-29

Figure 5-16: Digilent PmodRS232 Converter Module Board .................................................. 5-30

Figure 5-17: DB9 Male Connection .................................................................................................... 5-30

Figure 5-18: DB9 Female Connection ............................................................................................... 5-30

Figure 5-19: Transforms ........................................................................................................................ 5-33

Figure 5-20: Variable Transformed into a Metric ........................................................................ 5-33

Figure 5-21: Gadgets ................................................................................................................................ 5-34

Figure 5-22: Metric(s) Linked to Gadget ......................................................................................... 5-34

Figure 5-23: Gadgets placed on Dashboard .................................................................................... 5-34

Figure 5-24: Dashboard - Active Asset Monitor............................................................................ 5-36

Figure 6-1: Braking Test Location ...................................................................................................... 6-37

Figure 6-2: Legend.................................................................................................................................... 6-37

Figure 6-3: Normal Breaking Test 1 .................................................................................................. 6-37

Figure 6-4: Reckless Braking Test 1 .................................................................................................. 6-37





Figure 6-9: Turning Test Location ..................................................................................................... 6-39

Figure 6-10: Legend ................................................................................................................................. 6-39

Figure 6-11: Normal Turning Test 1 ................................................................................................. 6-40

Figure 6-12: Reckless Turning Test 1 ............................................................................................... 6-40



x



LIST OF EQUATIONS Equation 5-1: Nyquist Sampling Theorem [10] ............................................................................ 5-15

Equation 5-2: Rectilinear Motion Constants .................................................................................. 5-16

Equation 5-3: Rectilinear Motion Deduction to Calculate Acceleration [12] .................... 5-16

Equation 5-4: Rectilinear Motion Deduction to Calculate Time [12] ................................... 5-16

Equation 5-5: Calculating Degree of Tilt [14] ................................................................................ 5-19

Equation 5-6: Low Pass Filter Design for Unity Gain .................................................................. 5-20

Equation 5-7: Inverse Z-Transform ................................................................................................... 5-20

Equation 5-8: Low Pass Filter Difference Equation .................................................................... 5-20

Equation 5-9: Finite-Difference Approximation of Derivatives [15] .................................... 5-23

Equation 5-10: Complete Filter Difference Equation ................................................................. 5-23

Equation 5-11: Converting from Degree-Minute Format to Degree-Decimal Format ... 5-27

LIST OF FLOW DIAGRAMS Flow Diagram 1-1: Selecting a Component ....................................................................................... 1-2

Flow Diagram 1-2: Selecting a Microcontroller .............................................................................. 1-2

Flow Diagram 4-1: Single System ......................................................................................................... 4-7

Flow Diagram 4-2: Multiple Asset System ........................................................................................ 4-8

LIST OF FUNCTIONAL DIAGRAMS Functional Diagram 5-1: Microcontroller & Accelerometer .................................................... 5-15

Functional Diagram 5-2: Accelerometer Low Pass Filter ......................................................... 5-20

Functional Diagram 5-3: LPF & Differentiator Block Diagram ............................................... 5-23

Functional Diagram 5-4: Microcontroller & GPS Module .......................................................... 5-26

Functional Diagram 5-5: Microcontroller & Secondary Storage ............................................ 5-28

Functional Diagram 5-6: Microcontroller & Modem ................................................................... 5-30

Functional Diagram 5-7: SMART Sight Builder ............................................................................. 5-33

xi

LIST OF ABBREVIATIONS A/D: Analog to Digital, 5-9 ABS: Anti-lock Braking System, 6-36, 6-39 ADK: Accessory Development Kit, 5-10 ANSI C: American National Standards Institute for the C programming language, 5-29 CAN: Controller Area Network, 5-9 D/A: Digital to Analog, 5-9 DCE: Data Communications Equipment, 5-14, 5-25, 5-29 DMA: Direct Memory Access, 5-9 DOF: Degrees-of-Freedom, 5-13 DTE: Data Terminal Equipment, 5-14, 5-25, 5-29 EEPROM: Electrically Erasable Programmable Read-Only Memory, 5-10 GIU: Graphical User Interface, 5-33 GPS: Global Positioning System, 3-5, B-1 HDOP: Horizontal Dilution of Precision, D-4, D-5 I/O: Input/Output, 5-9 I2C: Inter-Integrated Circuit, 5-9 IC: Integrated Circuit, 5-24 ICT: Information and Communications Technology, 1-1 IEBus: Inter Equipment Bus, 5-9 IEEE: Institute of Electrical and Electronics Engineers, 1-4 LED: Light Emitting Diode, 4-6, 5-11 LIN: Local Interconnect Network, 5-9 LPF: Low Pass Filter, 5-20 LTI: Linear Time-Invariant, 1-1, 5-20 MEMS: Microelectromechanical Systems, 5-13 MISO: Master In – Slave Out, 5-28 MOSI: Master Out – Slave In, 5-28 NMEA: National Marine Electronics Association, 5-25 PDOP: Position Dilution of Precision, D-5 PLL: Phase-Locked Loop, 5-9 PSAP: Public Service Answering Point, 2-4 PWM: Pulse Width Modulation, 5-9 RISC: Reduced Instruction Set Computer, 5-10 RTC: Real-Time Clock, 5-9 SCK: Serial Clock, 5-28 SCN: Chip Select, 5-28 SIM: Subscriber Identity Module, 5-29 SPI: Serial Peripheral Interface, 5-9 SRAM: Static Random-Access Memory, 5-10 SV: Satellite Vehicle, D-5 TTFF: Time to first fix, 5-25 TTL: Transistor–transistor logic, 5-25 UART: Universal Asynchronous Receiver/Transmitter, 5-9 UCT: Coordinated Universal Time, D-4, D-5 USB: Universal Serial Bus, 5-9 VDOP: Vertical Dilution of Precision, D-5

(Chapter-Page) 1-1

1 INTRODUCTION

1.1 OVERVIEW & BACKGROUND

Fleet monitoring is a technique used to obtain various measurable data from any type of vehicle. The system depends on and takes advantage of the fact that there are wireless data communication networks available practically in all the areas where vehicles operate. Such a system only reports small packets of vital information which does not require a high bandwidth communication channel. The concept of monitoring a remote subject is known as telemetry.

Telematics typically describes any integrated use of telecommunications and informatics, also known as Information and Communications Technology (ICT). Telemetry is the transmission of measurements from the location of origin to the location of computing and consumption, without affecting the control on the remote subject.

Vehicle telematics has various practical applications and are used in numerous fields in the business and private sector. In the private sector it is used to monitor the location, speed, status and behaviour among other features of personal vehicles. These uses move to the commercial sector when third-party companies are involved to supply the device and a recovery service, if a vehicle was stolen.

The business sector’s uses include those of the private sector but may include features specifically for fleet management such as; driver identification; driver ratings; on-going logging; reminder listings; fuel profiling; warning systems for when vehicles leave usual operating areas; vehicle immobilisation; vehicle status such as temperature, fuel levels, oil pressure etc.

Considering all the features in tracking devices on the market today and how useful they can be when implemented correctly even if they only supply peace of mind. There are still so many possibilities in numerous sectors.

1.2 OBJECTIVES & OUTCOMES

The primary objectives for this project were to design and produce an all-inclusive product prototype that can actively monitor a vehicle’s location, velocity and driver behaviour whilst transmitting relevant data to a centralized web server. Data such as acceleration, speed and tilt angle of the vehicle was measured and used to characterize driver behaviour.

It was concluded that companies with similar products and features such as live tracking and driver behaviour monitoring does not use accelerometers to characterize the driver’s behaviour. Accelerometers are very sensitive to vibrations and data captured from them should be analysed carefully. Through the use of various carefully designed LTI (Linear Time-Invariant) filters this project has succeeded in detecting various levels of reckless driving behaviour from monitoring and interpreting multi directional acceleration.

University of Stellenbosch Active Fleet Monitoring & Reporting System

(Chapter-Page) 1-2

Various simulations were executed and numerical thresholds where obtained to distinguish between acceptable and reckless driving. To be noted: these thresholds are functions of the mass of the specific vehicle used in the simulations.

1.3 METHODOLOGY

DESIGN FLOW

Figure 1-1: Waterfall Model of Software Development [1]

The waterfall development model in Figure 1-1 consists of five major phases [1]. Requirements analysis determines the basic characteristics of the system. This was completed in chapter 3 where the requirements were decomposed into software and hardware requirements. Architecture design decomposes the functionality into major components. This was done in chapter 5 where the system was characterized by subsystems. Coding implements the pieces and integrates them whereas testing uncovers bugs and maintenance entails deployment in the field, bug fixes and upgrades. Coding, testing and maintenance were iteratively implemented in order to eliminate software and hardware bugs.

SELECTING HARDWARE

This section describes the thought process and logical reasoning followed to determine the best components and interfaces to be used. Deciding which microcontroller to use with which components is an iterative process which may best be described with the aid of flow diagrams.

Flow Diagram 1-1: Selecting a Component

Flow Diagram 1-2: Selecting a Microcontroller


(Chapter-Page) 1-3

Flow Diagram 1-1 and Flow Diagram 1-2 are decision based criteria to determine the ideal combination of components and microcontroller. This is the basis on which this design project was built.

Flow Diagram 1-1 is the decision based flow diagram for selecting a component, whereas Flow Diagram 1-2 is used for selecting a microcontroller. When starting the selection process either one can be used first. Note that Step 5 in each selection process desires the completion of the other diagram, thus this process is considered to be iterative.

In both Flow Diagram 1-1 and Flow Diagram 1-2 Step 1 is where a new component or microcontroller is selected to be researched. When browsing for different components or microcontrollers, Step 2 is an ideal and quick way to filter through all the candidates and exclude a few for further review. Step 3 is where the components and microcontroller needs to be matched up. If there is a mismatch of interfaces, the component and microcontroller should be carefully reviewed and decided whether it is best to search for a different component or microcontroller. If all the interfaces are compatible with each other the first time they are reviewed, no iteration of the process was done and the choosing of components and microcontrollers are complete.

It is strongly advised to iterate more than once through these cycles. Doing this might avoid the acquiring of a microcontroller or component with excess and unnecessary features.

When starting the selection process it is wise to do a limited amount of research before blindly iterating through the decisions, thus one can start the process with an educated guess and shorten the iteration cycles.

1.4 DIGITAL DEMONSTRATION

Search for “Active Fleet Monitoring & Reporting System” on www.youtube.com and verify the up loader as Justin Schietekat to view this project’s video.

1.5 DOCUMENTATION LAYOUT

This technical document consists of three sections. Section 1 contains the declaration of authenticity, acknowledgements, executive summary, table of contents and lists of all the indexed items such as figures, equations, tables, flow diagrams and functional diagrams. Section 1 is numbered in roman numerals.

Section 2 contains the body of the report and occasionally refers to the appendices. The chapter and page number are used to index this section. The body consists of the following chapters:

Chapter 2 staring on page 2-4 is the literature study which gives an overview of current projects around the world and communicates the necessity of this project.

Chapter 3 starting on page 3-5 is a detailed description of the requirements of this project.

Chapter 4 starting on page 4-6 is a systems overview discussing the capabilities of the project in the form of a flow diagram.

Chapter 5 starting on page 5-9 is the detailed design of the whole system. It describes subsystem objectives; views specific research and motivates design choices.

http://www.youtube.com/


(Chapter-Page) 2-4

Chapter 6 starting on page 6-36 is the measurements and analysis of specific subsystems thus confirming desired outcomes.

Chapter 7 starting on page 7-41 is where the conclusions and recommendations are discussed.

Chapter 8 starting on page 8-42 is the literature reference, in IEEE (Institute of Electrical and Electronics Engineers) 2006 referencing format, for all the research conveyed throughout this project.

Section 3 contains all the compulsory and supplementary appendices. The compulsory appendices include project management, project specification and specific outcomes and assessment criteria.

2 LITERATURE STUDY This literature study aims to convey information concerning the necessity for vehicle telematics in the transport infrastructures of South Africa and the status of current vehicle telematics around the world. Information was gathered from government legislation surveys; respected telematics and vehicle safety initiatives such as Engineering News, Telematics Update and Arrive Alive.

eCall in Europe is one example of a government project that is helping to further vehicle telematics. The European Union’s goal is to have every vehicle equipped with the eCall system by 2015 [2].

The eCall system is embedded within a vehicle and linked to the vehicle’s air bag control module to automatically detect a crash. It has a manual button to request help for a passenger with health problems or to report an accident of another vehicle. It has a GPS receiver, for locating the vehicle and its immediate path just before the accident. The United Kingdom has a service called the Public Service Answering Point (PSAP), these already exist and are operated by BT999 and Cable & Wireless which uses different switches, databases and call handling software [3]. The eCall unit automatically contacts the PSAP. They then pass information to the many emergency service control rooms dispatching emergency services. The device has a data channel to send out a message about the vehicle and its location to PSAP. It also consists of a voice channel for operators to talk to those in the vehicle, to gain more detail and reassure the occupants [4].

Contran 245 a is legislation in Brazil, requiring all new vehicles produced in, or imported to, Brazil be equipped with GPRS-enabled tracking modules to reduce vehicle theft. This project is currently on track and in the implementation phase [5]. This legislation could make Brazil one of the largest telematics markets in the world, both for basic vehicle tracking and extended services, ranging from basic tracking required by the legislation to services like fleet management and behaviour modelling for insurance purposes.

In the United States, although not a current law, many insurance companies are beginning to implement usage-based insurance to lower insurance prices for customers, as well as promote safe driving. In Italy the benefits of usage-based insurances are already leading to a new law which is at the moment under parliament approval [2].

In South Africa it is already an industry standard that high-end motor vehicles should have GPS tracking devices installed in order for it to be insured. Many insurance companies support and use a usage-based system to determine risk factors. It is centred


(Chapter-Page) 3-5

on measurable information like the odometer reading of the vehicle; number of minutes the vehicle is being used; speed and time-of-day information in addition to distance or time travelled. Other data could include your location and driving behaviour such as speeding, excessive braking [6].

In Kwazulu-Natal approximately 3000 taxis will be equipped in the next two years with state-of-the-art electronic fare collection systems called TAP-I-FARE. The uMgungundlovu Regional Taxi Council in Kwazulu-Natal, with its 40 Taxi Associations, collectively owns 3 700 taxis and transports more than 500 000 people daily [7]. Their system is currently cash based which results in checks and balances regarding vehicle condition, driver behaviour and passenger safety very difficult to manage, monitor and enforce.

Safety is a key selling point for the automotive industry, which are fitting systems that either actively reduce the chances of a crash or passively mitigate its effects. The challenge is to transform raw data into useful information for customers and especially to create new services from this enhanced information.

3 SYSTEM SPECIFICATIONS The primary objectives for this project are to design and produce an all-inclusive product prototype that actively monitors multiple vehicles and reports to a centralized web-server.

Accomplishing this task requires the development of a number of hardware and software subsystems.

3.1 HARDWARE SPECIFICATIONS

a) Integration of a GPS that enables the capturing of current position, velocity, time and date.

b) Integration of an accelerometer that enables measuring of the severity of multi-axial acceleration.

c) Integration of a cellular modem to report vital parameters in a periodic fashion. d) Integration of secondary memory in order to log on-going events and behaviour. e) Development of an electronic control circuit to interface with, and control the above

sensors, and to interface with the cellular network. f) Implementation of a power conditioning circuit to obtain power from the vehicle’s

power source.

3.2 SOFTWARE SPECIFICATIONS

a) Development of a web-based interface that allows the end-user to monitor individual vehicles or fleets as a whole.

b) Programming of an electronic control circuit to interface with, and control the hardware in 3.1

3.3 MEASUREABLE REQUIREMENTS

a) A technique must be developed, tested and confirmed in which reckless driving can be measured and detected.

b) Data must be reported to a web-server in such a manner, which data and how often, that it is useful to the end-user.


(Chapter-Page) 4-6

c) Data must be stored on the device’s secondary storage containing all the necessary information to retrace and simulate an event.

4 SYSTEM OVERVIEW 4.1 FUNCTIONAL OVERVIEW

Flow Diagram 1-1 is a representation of the whole system. The flow diagram is broken down into multiple logical subsections in order to better understand the flow and direction of information.

Input: The input division illustrates that all the raw data is acquired from an accelerometer and a GPS.

Processing: The processing division illustrates that only selected data is filtered and then the microcontroller determines which data to output where.

Output: The output division illustrates the three types of outputs this device facilitates. Mass data is logged on secondary storage; critical states are indicated on LED’s (Light Emitting Diode) on the device itself; and data is sent via a modem to the web-server for further interpretation and processing.

Channel: The channel division illustrates that to transfer data from the modem to the web-server facilitates the available GSM networks as channel(s) for communication.

User Interface: The user interface division illustrates that the web-server processes and finalizes the data to be viewed and interpreted by the end-user.

Flow Diagram 4-2 shows the whole system divided up into hardware and software sections. The reason for this flow diagram is to demonstrate that the hardware can be placed in multiple vehicles. These vehicles with devices installed, are from here on addressed as assets. The software side can then monitor multiple assets


(Chapter-Page) 4-7

4.2 SINGLE SYSTEM FLOW DIAGRAM

Flow Diagram 4-1: Single System


(Chapter-Page) 4-8

4.3 MULTIPLE ASSET SYSTEM FLOW DIAGRAM

Flow Diagram 4-2: Multiple Asset System


(Chapter-Page) 5-9

5 DETAILED DESIGN Chapter 5 systematically describes the design procedures followed for this project. Section 5.1 describes and discusses the reasons for which the microcontroller was chosen whereas section 0 to 5.6 describes the objective, research and design process followed for each component used in conjunction with the microcontroller.

5.1 MICROCONTROLLER

5.1.1 RESEARCH

CHOOSING A MICROCONTROLLER

In the search for a microcontroller various aspects and features has to be considered. These features are tabulated in Table 5-1. To start the process described in Flow Diagram 1-1 and Flow Diagram 1-2 one is obligated to choose either components or a microcontroller first.

Table 5-1: Microcontroller Properties

Microcontroller Properties

Bit Size Program Memory Size RAM Size

Flash Size Program Memory Type Pin Count

Frequency On-Chip Oscillator PLL (Phase-Locked Loop)

RTC (Real-Time Clock) Power-On Reset Floating Point Unit

DMA (Direct Memory Access) I/O (Input/Output) Ports Timer

PWM (Pulse Width Modulation)

A/D (Analog to Digital) Converter

D/A (Digital to Analog) Converter

CAN (Controller Area Network)

Ethernet SPI (Serial Peripheral Interface)

I2C (Inter-Integrated Circuit) LIN (Local Interconnect Network)

IEBus (Inter Equipment Bus)

USB (Universal Serial Bus) UART (Universal Asynchronous Receiver/Transmitter)

For this project a microcontroller was chosen first. After some light research concerning the type of components and their protocols that has to be used to accomplish the requirements was completed, an educated guess was made to choose a microcontroller to start the iterative process in Flow Diagram 1-2. Knowing that this project must consist of a GPS module, accelerometer, secondary storage and a modem the following starting points were used.

Table 5-2: Preferred Microcontroller Properties

Component Protocol(s)

GPS UART

Accelerometer I2C or Analog

Secondary Storage I2C or SPI


(Chapter-Page) 5-10

Component Protocol(s)

Modem UART

Narrowing down the search to microcontrollers specifically including the protocols in Table 5-2 a viable solution was found. An open-source solution named Arduino, has a variety of powerful prototyping boards. Uno, Leonardo, Mega 2560, Mega ADK, Due and Ethernet are all examples of boards available. The Mega 2560 and Mega ADK (Accessory Development Kit) were the only two boards available that supports more than two UART protocols. The Mega ADK’s only additional feature was that it supports the ADK for Android Developers thus the Mega 2560 was chosen.

Iterating through the process described in Flow Diagram 1-2 might have given a cheaper solution for a microcontroller but since this project is only a prototype, the time saved by purchasing a standalone pre-assembled microcontroller seems more viable.

ARDUINO MEGA 2560

The Arduino Mega 2560 (Figure 5-1) is a prototyping board containing an ATMEL ATmega2560 microcontroller. It is an 8-Bit Microcontroller facilitating RISC (Reduced Instruction Set Computer) architecture that supplies 135 powerful instructions which are most single cycle executions and has general purpose working registers [8].

Figure 5-1: Picture of Arduino Mega 2560 Prototyping Board

The ATmega2560 microcontroller offers high endurance non-volatile memory segments such as of in-system self-programmable flash, of EEPROM (Electrically Erasable Programmable Read-Only Memory) and internal SRAM (Static Random-Access Memory) and an average data retention of years [8]. It comes pre-burned with a boot-loader that allows you to upload new code to it without the use of an external hardware programmer. Table 5-3 summarizes the peripheral features and which pins they can be assigned to.

Table 5-3: Arduino Mega 2560 Pin Assignments

Feature Pins Feature Pins

UART 0 0(RX),1(TX) External Interrupt 3 20



UART 3 15(RX),14(TX) PWM (8-Bit) 0-13

External Interrupt 0 2 SPI 50(MISO),51(MOSI),5


(Chapter-Page) 5-11

Feature Pins Feature Pins 2(SCK),53(SS)

External Interrupt 1 3 LED 13

External Interrupt 2 21 I2C 20(SDA),21(SCL)

Analog I/O (10-Bit) A0-A15 Digital I/O 0-53

Analog Reference AREF Supply 3.3V, 5V

Reset /RESET Ground GND

5.1.2 DESIGN

The microcontroller can be run directly from a USB 2.0 port, . Its power will be obtained from an in-car USB port.

VARIABLE INTERPRETATIONS

Table 5-4 shows the critical system variables. The interpretation column indicates where the variable is used whereas the description column describes in what calculation or process the variable is used. From here on forward the variable names in the name column will be used to identify the variables as they are used. Further interpretations and derivations of these variables are available throughout the rest of chapter 5. They will be addressed as e.g. is used for the velocity variable associated with the GPS.

Table 5-4: Interpretation of System Variables

Path Name Interpretation Description

Web-Interface Indicate whether the vehicle is active or stationary.

Web-Interface Indicates the severity of the last reckless event.

Web-Interface Used to build coordinates and indicate position on Google-maps gadget.

Web-Interface Used to build coordinates and indicate position on Google-maps gadget.

Web-Interface/ Microcontroller

Used to determine the state of the state machine.

Web-Interface Indicates the amount of satellites currently being tracked.

Web-Interface/ Microcontroller

Indicates current and history velocity, also a determining factor for reckless driving.

Microcontroller Indicates current date which is used when logging activities.

Microcontroller Indicates current time which is used when logging activities.

Microcontroller Tangent acceleration factor to determine reckless behaviour.

Microcontroller Normal acceleration factor to determine reckless behaviour.


(Chapter-Page) 5-12

Path Name Interpretation Description

Microcontroller Vertical acceleration factor to determine reckless behaviour.

Microcontroller Pitch angel to determine tilt angle.

Microcontroller Roll angel to determine tilt angle.

EVENTS

Whenever certain thresholds are surpassed the microcontroller will inform the web-server of the events showed in Table 5-5. These events will be logged and a history can be viewed indicating the exact time and severity of the offense. The first level of reckless behaviour will be triggered when the velocity of the vehicle exceeds . This is no cause for alarm unless a specific vehicle is not permitted to travel on national roads.

The second level of reckless behaviour will be triggered when the velocity of the vehicle exceeds , or a reading exceeding the predetermined thresholds ( ) on the perpendicular axes of the accelerometer. These thresholds were derived experimentally; these measurements and derivations can be viewed in chapter 6 under subsections 6.1 and 6.2 starting on page 6-36.

The third level of reckless behaviour will be triggered when the vehicle exceeds , or when the acceleration thresholds ( ) exceeds their predetermined values by . This event will also send an email to the asset’s owner or coordinator informing them of this occurrence.

The last event is sent when fatal parameters are measured. Parameters are considered fatal if the accelerometer measures a vehicle tilt angel of more than on any perpendicular axis or an acceleration measurement of the maximum range of the accelerometer. The accelerometer design section 5.2.3 on page 5-14 concludes that only of the maximum range of the accelerometer is used to determine reckless driving. This section also concludes that severe accidents results in accelerations above the maximum range of the accelerometer. Thus a reading within the top 10 percentile of the accelerometer range will indicate a collision of some sort.

Table 5-5: Behavioural Events

Name Event ID Trigger(s)

RecklessBehaviour1 101

RecklessBehaviour2 102 or or

RecklessBehaviour3 103 or or

Accident 104 or or or

5.2 ACCELEROMETER

5.2.1 OBJECTIVES

The objectives are to research, configure and implement a three-axis accelerometer. An investigation was conducted to determine the optimal sampling rate and resolution. Each axis must be monitored individually enabling the measurement of tilt, tangent,


(Chapter-Page) 5-13

normal and vertical acceleration respectively. From here on forward the acceleration vector will be broken into three-dimensional components and will be visualized with the help of a vehicle. The tangent acceleration is the forward or backward acceleration. The normal acceleration is the acceleration experienced while turning and the vertical acceleration will be the up or down acceleration perpendicular to the earth’s gravitational field.

5.2.2 RESEARCH

Accelerometers has a wide range of features including sensing of acceleration, tilt, rotation, shock, vibration and multiple DOF (Degrees-of-Freedom). The application of an accelerometer in this project is primarily to sense acceleration and secondarily tilt.

Figure 5-2: Picture of MMA7361L Accelerometer Breakout Board

The MMA7361L from Freescale Semiconductors, as seen in Figure 5-2, is a low power, low profile capacitive MEMS (Micro-electromechanical Systems) accelerometer featuring signal conditioning, a 1-pole low pass filter, temperature compensation, self-test, and g-Select which allows for the selection between 2 sensitivities [9]. Other features and parameters include:

3mm x 5mm x 1.0mm LGA-14 package Low current consumption: Sleep mode: Low voltage operation: High sensitivity ( ) Selectable sensitivity , ) Fast turn on time ( Enable Response Time) Self-test for free-fall detect diagnosis -Detect for free-fall protection Signal conditioning with low pass filter Robust design, high shocks survivability

The MMA7361 accelerometer is known as a MEMS device. MEMS are made up of components between in size, and these devices generally range in size from . They usually consist of a central unit that processes data and several components that interact with outside parameters.

Static and dynamic acceleration measurements are two different applications of the accelerometer. Static acceleration is the measurement of the earth’s gravity as the device is rotated into various positions as demonstrated in Figure 5-3. This implementation is used to measure the tilt angle of the object it is attached to.


(Chapter-Page) 5-14

Figure 5-3: Demonstration of Static Acceleration

Dynamic acceleration is the measurement of the physical acceleration vector of an object only considering the difference in acceleration as demonstrated in Figure 5-4. The accelerometer is still subject to the gravitational force of the environment, but this information is disregarder in the process of obtaining multi-axial acceleration.

Figure 5-4: Demonstration of Dynamic Acceleration

5.2.3 DESIGN

The microcontroller is seen as the DTE (Data Terminal Equipment) and the accelerometer peripheral as the DCE (Data Communications Equipment). The DCE obtains power directly from the DTE and measures the three axes separately with A/D converters. Functional Diagram 5-1 illustrates the physical configurations between the DTE and DCE


(Chapter-Page) 5-15

Functional Diagram 5-1: Microcontroller & Accelerometer

SAMPLING RESOLUTION

The MMA7361L accelerometer is supplied with a reference voltage of and in return it gives a variable voltage that ranges from as an output on the three axes respectively. The ATmega2560 microcontroller has sixteen 10-Bit A/D converters. When measured, the accelerometer readings result in a resolution of , thus will map to . The accelerometer has selectable sensitivities of or . The relationship between the sensitivity settings and bit/voltage resolution is tabulated in Table 5-6.

Table 5-6: Accelerometer Sensitivity and Resolution Relationship

Sensitivity Bit Resolution Voltage Resolution

SAMPLING RATE

A/D sampling rate and any external power supply switching frequency should be selected such that they do not interfere with the internal accelerometer sampling frequency of . This will prevent aliasing errors [9].

According to Equation 5-1 the sampling frequency must be twice the value of the largest frequency in the frequency spectrum of the signal being sampled in order to avoid aliasing. The minimum sampling frequency is also known as the Nyquist rate. If the Nyquist theorem is satisfied, perfect signal reconstruction is possible [10].

Equation 5-1: Nyquist Sampling Theorem [10]

To avoid aliasing, signals are normally band limited by low-pass filtering before sampling.


(Chapter-Page) 5-16

INVESTIGATION TO DETERMINE OPTIMAL SAMPLING RATE AND RESOLUTION

In order to define the ideal sampling rate it is required to investigate the physics involved in the operation of a vehicle in order to determine the highest significant frequency to this project.

A logical deduction is that the average vehicle experiences the highest non-fatal acceleration when braking. The total stopping distance of a vehicle depends on four factors; perception time; reaction time; vehicle reaction time and the vehicle braking capability. For this investigation we are interested in the speed of a light vehicle before braking and the time it took to come to a complete stop. Human reaction time is irrelevant in this investigation. Table 5-7 and Table 5-8’s speed and braking distance (braking distance = total braking distance - perception distance - reaction braking distance) column information was gathered from an online source [11]. Row two consists of units whereas row three is variable symbols and calculations involving them.

The calculations for the braking time, acceleration, g-forces and minimum frequency were deduced with the assumption that the acceleration is constant for each experiment. By the separation of variables the following equations was deduced.

, , ,

Equation 5-2: Rectilinear Motion Constants

∫

∫

Equation 5-3: Rectilinear Motion Deduction to Calculate Acceleration [12]

∫

∫

Equation 5-4: Rectilinear Motion Deduction to Calculate Time [12]

Table 5-7: Stopping Parameters under Dry Conditions

Speed Speed Braking Distance

Acceleration Acceleration Braking Time

Frequency

30 8.333 5.3 -6.551 -0.668 1.272 0.786


(Chapter-Page) 5-17



Frequency

50 13.889 14.8 -6.517 -0.665 2.131 0.469

60 16.667 21.4 -6.490 -0.662 2.568 0.389

80 22.222 38.0 -6.498 -0.663 3.420 0.292

100 27.778 59.4 -6.495 -0.662 4.277 0.234

120 33.333 85.5 -6.498 -0.663 5.130 0.195

Table 5-8: Stopping Parameters under Wet Conditions



Frequency

30 8.333 9.4 -3.694 -0.377 2.256 0.443

50 13.889 26.1 -3.695 -0.377 3.758 0.266

60 16.667 37.5 -3.704 -0.378 4.500 0.222

80 22.222 66.7 -3.702 -0.377 6.003 0.167

100 27.778 104.3 -3.699 -0.377 7.510 0.133

120 33.333 150.2 -3.699 -0.377 9.012 0.111

From Table 5-7 and Table 5-8’s acceleration column it was observed that the absolute maximum acceleration was | | , it is thus safe to assume that reckless braking can be detected within a range. From the Braking Time column it was observed that the minimum time to experience acceleration was which relates to a maximum frequency we wish to observe to be . The Nyquist rate for events that depicts reckless behaviour is thus .

When considering fatal impact, much higher accelerations are expected for much shorter times. The data in Table 5-9 was acquired from the United Kingdom’s Vehicle Safety Research Centre [13]. It was acquired from experiments that were concluded, with minibuses loaded to different capacities and then crashed according to the scenarios below.

Scenario: (1) 50% Frontal impact into front of minibus. (2) 50% Frontal impact with barrier. (3) 40% Frontal impact with barrier. (4) 100% Frontal impact with barrier. (5) 100% Frontal impact into back of minibus. (6) 100% rear impact from minibus.

Table 5-9: Minibuses Accident Parameters [13]

Test Vehicle Mass Impact Speed

Impact Scenario

Maximum Acceleration

Duration of Acceleration

Frequency

1 3500.0 64.0 1 6.8 170 5.88


(Chapter-Page) 5-18

Test Vehicle Mass Impact Speed

Impact Scenario

Maximum Acceleration

Duration of Acceleration

Frequency

2 3493.0 50.0 2 11.6 200 5.00

3 1989.0 56.2 2 22.1 140 7.14

4 1633.2 51.1 3 17.9 140 7.14

5 3300.0 57.7 4 17.8 190 5.26

6 2209.0 56.0 4 24.3 120 8.33

7 2194.5 48.6 4 27.1 105 9.52

8 2001.0 48.9 4 28.0 95 10.53

9 1959.0 57.2 4 28.7 105 9.52

10 2609.0 (Bullet)

3300.0 (Target)

88.5 5 18.7 150 6.67

11 2609.0 (Bullet)

3300.0 (Target)

88.5 6 14.8 180 5.56

The average duration of a fatal acceleration is ∑

, which

relates to . The Nyquist rate for events that depicts fatal accidents is thus . If a sampling rate of is selected, the Nyquist theorem is satisfied ( ) thus eliminating the possibility if aliasing when reconstructing the signal and leaving room to detect accelerations that endured a shorter time of up to no less that . The accelerometer will be set to detect resulting in a high enough resolution to detect reckless behaviour and detecting impacts when the reading surpasses the average non-fatal acceleration measured in Table 5-7 and Table 5-8. The

detecting of reckless braking will thus facilitate

of

the total accelerometer range.

CALCULATING TILT FROM RAW DATA

When considering raw data sampled at with a resolution of one can calculate the tilt angle of a vehicle also known as the roll ( ) or pitch ( ). These are the angles between the vehicle’s perceptive X-axis or Y-axis and the stationary Z-axis respectively as illustrated in Figure 5-5 and Figure 5-6. The accelerometer does not measure direction like a compass, thus we are not interested in the yaw, the output on the Z-axis. Information regarding the direction in which the vehicle is travelling will be obtained from the GPS.


(Chapter-Page) 5-19

Figure 5-5: Angle between Z & X Axis (Roll)

Figure 5-6: Angle between Z & Y Axis (Pitch)

Tilt is a static measurement where gravity is the acceleration being measured. Therefore, to achieve the highest degree resolution of a tilt measurement, a low-g, high-sensitivity accelerometer is required. The typical output of capacitive, micro-machined accelerometers is nonlinear and is best described by a sine function [14]. Equation 5-5 is a derivation to calculate the roll ( ) and pitch ( ) respectively. is the accelerometer

output in volts; is the 0g offset voltage;

is the

resolution; is the earth’s gravity and is the angle of tilt.

(

)

(

)

Equation 5-5: Calculating Degree of Tilt [14]

Figure 5-7: Accelerometer Signal, Static Implementation


(Chapter-Page) 5-20

Figure 5-7 is an output of the unfiltered accelerometer data when simulated to obtain static measurements (Definition of static measurement on page 5-14). The output [ ] for both the X and Y-axis is unfiltered and contains uncorrelated Gaussian noise. The noise can be reduced by averaging the outputs over time. A LPF (Low Pass Filter), in Functional Diagram 5-2, will aid in the averaging of the data, but will have other effects like phase shifts and bandwidth reduction. These effects can be calculated and are trade-offs in order to reduce noise.

Functional Diagram 5-2: Accelerometer Low Pass Filter

An LTI (Linear Time-Invariant) LPF with unity gain was designed as shown in Equation 5-6. Equation 5-8 transforms the transfer function into a difference equation with the help of Equation 5-7.

Unity gain is required so,| |

|

| and thus,

Equation 5-6: Low Pass Filter Design for Unity Gain

[ ]

∫

denoted as

[ ] { }

Equation 5-7: Inverse Z-Transform

{ } { }

[ ] [ ] [ ]

Equation 5-8: Low Pass Filter Difference Equation

A MATLAB simulation was written to repetitively filter the raw data with the LPF in Equation 5-8 with varying values. An output with reduced noise and small bandwidth loss was observed with . The resulting signal output [ ] is shown in Figure 5-8

along with the raw input [ ]. A phase shift is clearly noted, and it can be calculated. A phase shift which results in a delay of s does not influence the performance of the system.


(Chapter-Page) 5-21

Figure 5-8: Accelerometer Signal before and after LPF, Static Implementation

The microcontroller persistently monitors these parameters every ( ) with the help of a timer interrupting on stack overflows, if either the tilt angles, or exceeds an angle of for an extended period of time, an event will be logged to the web-server. The events are described in Table 5-5 on page 5-12. Figure 5-9 has coordinates plotted on it, the corresponding angles are calculated and tabulated in Table 5-10.

Figure 5-9: Accelerometer Signal before and after LPF, Measurement Purpose


(Chapter-Page) 5-22

Table 5-10: Static Acceleration Tilt Answers

2.95 438.3034 1413.882 -59.16 8.2 518.733 1673.332 4.87

3.7 449.3255 1449.437 -46.83 8.95 544.5232 1756.526 22.79

4.45 497.7854 1605.759 -9.26 9.7 566.9404 1828.84 40.57

5.2 536.0657 1729.244 16.75 10.45 572.8072 1847.765 45.98

5.95 546.7852 1763.823 24.45 11.2 548.5337 1769.464 25.75

6.7 546.5296 1762.999 24.26 11.95 500.8638 1615.69 -7.17

CALCULATING ACCELERATION FORM RAW DATA

In order to measure dynamic acceleration the difference in acceleration must be obtained. It must also be considered that a vehicle can experience tangent (Figure 5-10) or normal (Figure 5-11) acceleration while on a slope i.e. the tilt measurement must not influence the dynamic acceleration measurement. The Z-axis’ acceleration is also monitored for extreme values but reckless driving behaviour will primarily be detected from acceleration vector.

Figure 5-10: Normal Acceleration (X-Axis)

Figure 5-11: Tangent Acceleration (Y-Axis)

In order to retrieve the acceleration vector with a zero offset, the raw data must be differentiated. Functional Diagram 5-3 shows the LPF with a differentiator. It is the complete prototype filter that needs to be implanted. A finite-difference approximation was derived to approximate a differentiator in Equation 5-9. The approximation becomes more accurate as increases.


(Chapter-Page) 5-23

Functional Diagram 5-3: LPF & Differentiator Block Diagram

[ ] [ ] [ ]

{

} { [ ]}

Equation 5-9: Finite-Difference Approximation of Derivatives [15]

The difference equation of the differentiator and the LPF combined is calculated in Equation 5-10.

{

} {

}

[ ] [ ] [ ] [ ]

Equation 5-10: Complete Filter Difference Equation

Figure 5-12 is the output of the raw ( [ ]) and the simulated output of the filtered signal ( [ ]) when simulated to obtain dynamic measurements (Definition of dynamic

measurement on page 5-14).

Figure 5-12: Accelerometer Signal before and after LPF, Dynamic Implementation


(Chapter-Page) 5-24

Figure 5-13 is the absolute output | [ ]| of the complete filter as showed in the

Functional Diagram 5-3 on page 5-22. Taking the absolute value of a signal destroys valuable characteristics of it. Only peaks in the signals are measured and talking the absolute value saves microcontroller process power, since unsigned variables can be used and only one comparison is made with extreme values. An offset of was added to Y and was added to Z for illustration only. The differentiation of the signal results in a measurement independent of the original constant which

means the measurements are accurate even when the vehicle is on an incline/decline. (i.e., the static gravitational effect was removed by the differentiator).

Figure 5-13: Accelerometer Signal after Differentiator, Dynamic Implementation

From monitoring the extreme values of the tangent and normal components of the accelerations, one can determine different degrees of reckless driving. The coefficients will differ as a function of the vehicles mass. The process of determining coefficients are described, applied and demonstrated in chapter 0.

5.3 GPS

5.3.1 OBJECTIVES

The objectives are to research, configure and implement an autonomous GPS subsystem. It must be set up initially and continuously used to capture and extract various parts of live information. The information required from the GPS is velocity, direction, position, time and date. This information would then be captured and processed by a microcontroller for further use within the system.

5.3.2 RESEARCH

The GPS device used is an off-the-shelf product, it is ITead Studio’s Arduino GPS shield v1.1 as viewed in Figure 5-14. It is a breakout board designed to be attachable to various Arduino microcontrollers. The shield uses a Globelsat EB-365 GPS IC (Integrated Circuit) which is a small standalone GPS receiver.


(Chapter-Page) 5-25

Figure 5-14: ITead Studio GPS Shield & Antenna

A GlobalSat EB-365 GPS module was used. It is a compact, high performance, and low power consumption GPS engine board. It uses SiRF Star III chipset which can track up to 20 satellites at a time and perform fast TTFF (Time to first fix) in weak signal environments. SiRF Star III architecture is designed to be useful in wireless and handheld location-based services applications, for 2G, 2.5G, 3G asynchronous networks. EB-365 is suitable for applications like automotive navigation; personal positioning; fleet management; mobile phone navigation and marine navigation. The receiver features an integrated GPS crystal, providing fast acquisition and excellent tracking performance [16]. Other features and parameters include:

SiRF star III high performance GPS chipset Very high sensitivity (Tracking Sensitivity: -159dBm) Extremely fast TTFF at low signal level Serial port I2C interface 4Mb flash Built-in LNA Compact size (16 * 12.2 * 2.4mm) suitable for space-sensitive application One size component, easy to mount on another PCB board Support NMEA 0183 V2.3 (Output: GGA, GSA, GSV, RMC, VTG, GLL, ZDA) Support SiRF binary protocol

The EB-365 offers three different serial interfaces. The serial communication uses a universal protocol which was developed by NMEA (National Marine Electronics Association) to interface between various pieces of marine electronic equipment [17]. These standards dictate that data should be transmitted serially according to the parameters represented in Table 5-11. The data is packaged and transmitted in a collection of independent sentences on a periodic basis. The raw sentences sent and used from the GPS is analysed and explained in Appendix D under D.1.

Table 5-11: GPS Protocol Parameters

Baud Rate Data Bits Parity Stop Bits Handshaking

9600 bits/s 8 bits None 1 bit None

5.3.3 DESIGN

The microcontroller is seen as the DTE (Data Terminal Equipment) and the GPS peripheral as the DCE (Data Communications Equipment). The DCE obtains power directly from the DTE and communicates via TTL (Transistor–transistor logic) standard UART. Functional Diagram 5-4 illustrates the physical configurations.


(Chapter-Page) 5-26

Functional Diagram 5-4: Microcontroller & GPS Module

The GPS module serially streams NMEA standard sentences via a UART to the microcontroller. It sends updated $GPGGA, $GPGLL, $GPGSA, $GPRMC and $GPVTG sentences every second. Every five seconds the sentences include $GPGSV data which gives information about the reliability of the satellites being tracked. All the sentences and their meanings are available in Appendix D under D.1. Table 5-12 shows what information is extracted from which sentences and what data types they are converted to by the microcontroller.

Table 5-12: GPS Software Parameters

Description Parameter Data Type NMEA Sentence

Latitude double $GPGGA

Latitude hemisphere integer $GPGGA

Longitude double $GPGGA

Longitude hemisphere integer $GPGGA

Satellites integer $GPGGA

Fix Quality integer $GPGSA

Direction double $GPRMC

Velocity double $GPVTG

Time integer $GPGGA

Date integer $GPRMC

The $GPGGA sentence contains latitude and longitude information which together forms a coordinate on the geographic coordinate system. The coordinate obtained from the $GPGGA sentence is in a Degree-Minute format whereas the format required for the Web-Interface is Degree-Decimal format. If the coordinate is expressed in decimal form, northern latitudes are positive, southern latitudes are negative, eastern longitudes are


(Chapter-Page) 5-27

positive and western longitudes are negative. See example data in Table 5-13 and conversion method in Equation 5-11.

Format: $GPGGA,hhmmss.ss,ddmm.mmm,a,dddmm.mmm,b,q,xx,p.p,a.b,M,c.d,M,x.x,nnnn*XX

Example: $GPGGA,210037.000,3355.4308,S,01851.8181,E,1,04,3.2,27.1,M,32.8,M,,0000*7C

Table 5-13: Coordinate Format Examples

Format Name Placeholder Example

Degree-Minute

Degree-Decimal

{

(

)

{

(

)

Equation 5-11: Converting from Degree-Minute Format to Degree-Decimal Format

The Degree-Decimal format has several advantages over the Degree-Minute format. The Degree-Decimal latitude and longitude can be stored in separate variables and mathematical operations can directly be applied whereas with the Degree-Minute format, an interpretation of the longitude and latitude must first be implemented before operations can be applied to degrees and minutes respectively.

The satellites and fix quality are valuable information to monitor the status of the GPS. This information allows the microcontroller to assume another state, thus not reporting false data and rather waiting for GPS signal or attempt to correct the error. The altitude information is exclusively used to gather a better perspective of the parameters of the vehicle being monitored. The velocity information extracted from the GPS in conjunction with the acceleration vector is vital parameters in determining reckless behaviour. The time and date information are exclusively used for accurate logging onto secondary storage.

The GPS periodically streams all the information in Table 5-12. Thus the information is only captured when it is needed. It takes less than a second to intercept the data stream and listen for a specific sentence to acquire and update a parameter.

5.4 SECONDARY STORAGE

5.4.1 OBJECTIVES

The objectives are to research, configure and implement a reliable secondary storage feature. It will be used to continuously store various parts of live information. The format and frequency must be of such a nature that all the necessary information required to identify driver behaviour must be stored. This includes velocity, direction, position, time, date, tilt angles and multi-axial acceleration. This feature will assist in troubleshooting while updating and developing the device, but primarily functions as a


(Chapter-Page) 5-28

recording device. The retrieval of this device after an incident or accident might assist in the investigation to confirm system or human failures.

5.4.2 RESEARCH

The ATMEL ATmega2560’s on-chip EEPROM was considered and rejected because it will store approximately half an hour’s worth of data. It is sensible to store at least one week’s data.

The MicroSD card system is a mass-storage system based on modernizations in semiconductor technology. MicroSD cards are highly integrated flash memories with serial and random access capabilities. These MicroSD cards have two serial interface modes; SD Card or SPI mode, optimized for fast and reliable data transmission. These interfaces allow several cards to be stacked by connecting their peripheral contacts. It has been developed to provide an inexpensive, mechanically robust storage medium in card form for mass-storage consumer applications. The MicroSD card will deliver enough capacity for all kinds of logging data [18].

The Serial Peripheral Interface Bus or SPI bus is a synchronous serial data link standard that operates in full duplex mode. Devices communicate in master/slave mode where the master device initiates the data frame. Multiple slave devices are allowed with individual chip select lines [19].

5.4.3 DESIGN

PHYSICAL CONNECTION

The microcontroller is seen as the DTE and the MicroSD card as the DCE. The DCE obtains power directly from the DTE and communicates via SPI. Functional Diagram 5-5 illustrates the physical configuration between DTE and DCE.

Functional Diagram 5-5: Microcontroller & Secondary Storage

The ITead GPS module contains a MicroSD card slot (Figure 5-14). This module is pre-configured with SPI in mind, the supply pins are correctly connected and the communication signals are open for manipulation. The data signals, MISO (Master In – Slave Out) and MOSI (Master Out – Slave In) are connected to digital pin 50 and 51 respectively. The control signals, SCK (Serial Clock) and SCN (Chip Select) are connected to digital pin 52 and 53 on the microcontroller.


(Chapter-Page) 5-29

DATA RECORDING

The data is saved directly to a text file onto the Micro SD card. Each hour of each day is stored in a separate text file. The text file is named with the date and hour it contains. This separation eases the data mining process when interpretation is needed.

All the activity of the modem, as indicated in Table 5-16 and Table 5-17 on page 5-32, are logged with a time stamp as the leading line. The raw data of the accelerometer are also logged but without a time stamp. The raw accelerometer data is only logged when the normal or tangent acceleration exceeds 70% ( or ) of their individual thresholds or the angel of tilt surpasses ( or ). 70% and where selected as a midway mark for reckless behaviour, this ensures that any scenario close or heading to the trigger of an event will be logged in full detail. When any of these boundaries are crossed, accelerometer data is continuously stored for the proceeding 30 seconds.

5.5 MODEM

5.5.1 OBJECTIVES

The objectives are to research, configure and implement a modem subsystem. It must be set up initially and continuously used to transmit and receive data through the available GSM networks. The modem acts as the two-way link between the microcontroller and the web-server

5.5.2 RESEARCH

The Sierra Wireless AirLink GL6100 is a wireless modem that allows users to connect to a wireless network. It uses an external SIM (Subscriber Identity Module) and offers quad band 850/900/1800/1900 MHz GPRS Class 10 capabilities. The modem communicates with a microcontroller using a RS232 interface

Figure 5-15: Sierra Wireless AirLink GL6100

The modem is customizable with the Sierra Wireless Software Suite which enables one to set up custom AT commands, custom application libraries and native execution of embedded ANSI C (American National Standards Institute for the C programming language) applications. The modem uses the RS-232 serial interface with customizable baud rates, handshaking, data bits and stop bits options [20].

5.5.3 DESIGN

The microcontroller is seen as the DTE and the modem peripheral as the DCE. The DCE obtains power externally and communicates via RS-232. The Max3232 IC converts RS-232 to TTL standard voltage levels for two-way UART communication. Functional Diagram 5-4 illustrates the physical configurations. The modem functions normally on a wide voltage range, thus it will be connected directly to the vehicle’s power source.


(Chapter-Page) 5-30

Functional Diagram 5-6: Microcontroller & Modem

HARDWARE INTERFACE

The Digilent PmodRS232 converter module board (Figure 5-16) with a Max3232 module creates a two-way I/O exchange by converting RS-232 voltage to TTL and vice versa.

Table 5-14: RS-232 & TTL Bus Voltage Levels

RS-232 TTL

Logic 0 [ ] [ ]

Logic 1 [ ] [ ]

Figure 5-16: Digilent PmodRS232 Converter Module

Board

Figure 5-17: DB9 Male Connection

Figure 5-18: DB9 Female Connection

DTE devices usually use the male (Figure 5-17) DB9 connection whereas DTCs use the female (Figure 5-18) connection. The PmodRS232 converter module is wired as a DTE device. RS-232 signals are named from the perspective of the DCE [21]. The TX (Transmit) signal carries data from the DCE to the DTE, therefore the TX signal on pin 3 in Figure 5-17 is connected to the output of a receiver and then connected to the receive input of a UART on microcontroller. Similarly, the RX (Receive) signal on pin 2 carries data from the DTE to the DCE and is connected to the input of a transmitter on the PmodRS232 converter and then connected to the output of the UART on the system


(Chapter-Page) 5-31

board. Handshaking were not required thus, the converter is connected in 3-wire mode where RTS is connected back to CTS on the RS-232 side of the module.

SOFTWARE COMMUNICATION

The GL6100 modem uses AT commands to communicate with the microcontroller. The AT command set includes commands for various manipulations, such as various controls to set up the modem, including a set of register commands which allows the user to directly set the various memory locations [20].

After configuring the modem and the microcontroller as shown in Functional Diagram 5-6, communication was established. The modem responds to solicited and unsolicited messages with the difference being that unsolicited messages have a plus prior to the message. Table 5-15 is a list of frequent messages and a description of their meanings.

Table 5-15: Frequent AT Messages

No Type Command Description

1 Solicited OK Is received for any successful command and should be interpreted as a confirmation.

2 Unsolicited +AWTDA: BOOT Shows the modem is attempting to connect to a network.

3 Unsolicited +AWTDA: UP Shows the modem as successfully established a network connection.

4 Unsolicited +AWTDA: DN Shows the modem as just lost network connection.

5 Unsolicited + AWTDA: TIMEOUT Indicates that an expected response took too long and was aborted.

6 Unsolicited +CME ERROR: # Indicates an error has occurred, the error can be looked up from the datasheet or AT command manual.

7 Solicited AT+AWTDA? Requests the current status of the modem either 2, 3 or 4 will be returned as a message.

8 Solicited AT+IFC=0,0 Disables the flow control function of the modem

9 Solicited AT+CFUN=1 Manually resets the modem.

10 Solicited AT+AWTDA=e Triggers a numbered event.

11 Solicited AT+AWTDA=d Send data to the web-server.

12 Solicited AT+AWTDA=c Send a command status and acknowledgement to the web server

13 Solicited AT+AWTDA=dh Create a data handler to receive command from web-server.

A state machine was implemented by observing the unsolicited messages regarding the state of the modem (Message 2,3,4,5 or 6 as indicated in Table 5-15) are received and captured by the serial 2 interrupt of the microcontroller. These messages are interpreted and the microcontroller will decide to continue sending data; wait for confirmation of data sent; manually reset the modem or wait for the modem to re-establish a network connection when if it was temporarily offline.


(Chapter-Page) 5-32

DATA & EVENTS

The web-server is pre-configured through AirVantage Developer Suite with variables, events and commands. These variable names, data types asset information, event number etc., are then used in the AT commands sent from the modem. The web-server identifies exact properties and updates, triggers or executes the corresponding parameter(s) on the server. Table 5-16 illustrates the AT command(s) used for events and which ID’s are used to identify them. Table 5-17 illustrates the AT command(s) used to transfer data from the asset to the web-server.

Table 5-16: Modem Event Notification

Name Event ID

AT Command: AT+AWTDA=e,"<Asset ID>",<Event ID>




Accident 104

Table 5-17: Modem Data Transfer

Path Name Data Type Data

AT Command: AT+AWTDA=d,<n>,["<Asset ID>,<Path>",<Name>,<Data Type>,<Data>]1,[]2,…,[]n

INT32 1

INT32 0

INT32 -33923544

INT32 18864216

INT32 3

INT32 7

INT32 60

INT32 245

5.6 WEB-INTERFACE

5.6.1 OBJECTIVES

The objectives are to research, configure and implement a web-interface. It must be set up to show all the relevant and up-to-date information that will be sent from the microcontroller via the modem. The interface is solely used to monitor the asset’s parameters.

5.6.2 RESEARCH & PROCEDURE

The modem was setup to communicate with SMART Sight. It is a platform developed by Trinity Telecomms. This platform allows the user to link various variables to metrics; these metrics are connected to gadgets which are then placed on a dashboard which is


(Chapter-Page) 5-33

the end-user will interface. Functional Diagram 5-7 is a procedural diagram for the order in which a dashboard is assembled.

Functional Diagram 5-7: SMART Sight Builder

DATA

SMART sight allows the user to use variables associated with the network; the communication device and the asset(s) the modem is monitoring. Within the data column of Functional Diagram 5-7 these sources are demonstrated by three images.

METRICS

SMART sight offers a wide variety of transforms. Figure 5-19 shows the graphical representation of the transforms available. In the top left is a ‘free equation’ transform that allows basic mathematic operations to be applied to one or more variables as indicated in Figure 5-20. Second is the ‘location’ transform which takes latitude and longitude values and pairs them as a coordinate. On the top right is an ‘enumerator’ which assists in changing data types, for instance when a 7 should relate to “Yellow” (INT to String).

All variables that must be incorporated into a GIU (Graphical User Interface) must be represented as a metric. This procedure allows an additional calculation or filter to be applied before the variable is finalised, naturally the variable can be linked to a metric directly.

Figure 5-19: Transforms

Figure 5-20: Variable Transformed into a Metric

GADGETS

The gadget section allows the user to represent a matric or multiple metrics in a graphical manner. Figure 5-21 represents the graphical representations of all the gadgets. SMART Sight allows the user to modify almost every aspect of the gadget, from colours to values and names. Figure 5-22 shows a metric being connected to a gauge


(Chapter-Page) 5-34

gadget. The gadget has been set to look like a typical speedometer. The numerical values, major and minor ticks, blue limit range, orientation and units have been selected manually. All the gadgets of a particular system should have a similar theme. This allows specific inconsistencies to stress important viewing areas.

Figure 5-21: Gadgets

Figure 5-22: Metric(s) Linked to Gadget

DASHBOARD

The layout of the dashboard is the last step before it is ready for the end-user. The user imports all the gadgets that need to be displayed. The gadgets should strategically be placed in order to have a natural flow of information. Figure 5-23 is a typical example of such a layout. The two gadgets representing speed and its history are placed together.

Figure 5-23: Gadgets placed on Dashboard

5.6.3 DESIGN

All the data sent from the microcontroller was connected to corresponding metrics. The variables sent form the modem can be viewed in subsection 5.5.3 in Table 5-17 on page 5-29.

FUNCTIONALITY

Figure 5-24 is an example of the dashboard that the end-user will be using. To follow is a numbered list of descriptions and functionality of each section of the dashboard. The numbers corresponds to the numbers on Figure 5-24.

1. State Description: The state description and the state light are directly linked to one another. There are four specific states in which the device can be. The first state is active. The light will be green which means the asset is moving and reporting in a normal fashion. The second state is stationary. The light will be blue which means the asset is not moving and the device is reporting in a normal fashion. The next state is the service state. The light will be orange which means there is an identified error


(Chapter-Page) 5-35

on the device and the device is still reporting to the web-server. Lastly is the error state, the light will be red which means the communication link has been lost.

2. Fix Description: The fix description section indicates the type of GPS fix the device has. This information should be used to deduce how accurate the position information is. The fix type will be ‘none’ if no satellites are currently being tracked. If the device is tracking one or two satellites the fix type will be ‘two dimensional’ whereas it will report ‘three dimensional’ if three or more satellites are being tracked.

3. Amount of Satellites: The satellite section indicates the amount of satellites currently being tracked, on a visual progress bar. Orange markers are placed on the progress bar at values three and twelve, this indicates the range of satellites required for normal operation. At the bottom of the progress bar is a numerical value of the amount of satellites and a time stamp as to when last the information was updated.

4. Speedometer: The speedometer indicates the speed of the asset. The range indicated in blue are the speeds the system will recognize as reckless behaviour. Below the speedometer is a numerical value of the speed and its time stamp.

5. Speed History Graph: The speed history graph represents the reported speed from the previous one-thousand speed reports. Below the graph is a scroll bar which allows the end-user to view certain days or hours in the whole window. When the mouse cursor is moved over a data point the time stamp of that point is viewed as a tool tip text. The graph has a range band which corresponds with the range limits of speedometer.

6. Cardinal Direction: The cardinal direction text description and the compass are directly linked to one another. The text will change to the corresponding cardinal direction i.e. N, NNE, NE, ENE, E etc. whereas the compass’ needle will point in that direction.

7. Behavioural History Graph: The behavioural history graph shows the previous one-hundred reckless behaviour reports. Below the graph is a scroll bar which allows the end-user to view certain days or hours in the whole window. When the mouse cursor is moved over a data point, the time stamp of that point is viewed as a tool tip text. The graph has a range band between 3 and 4 which indicates their severity. Refer to Table 5-16 on page 5-32 to view the events and their corresponding meanings.

8. Position: The latitude and longitude data is combined into one metric which is then viewed through a Google Maps gadget. This gadget plots the coordinates as a red marker. The map will show a trail of up to two-hundred and fifty markers which will indicate the route history. Google Maps/Earth additional terms of service can be view on their website at http://www.google.com/intl/en-US_US/help/terms_maps.html.

http://www.google.com/intl/en-US_US/help/terms_maps.html

http://www.google.com/intl/en-US_US/help/terms_maps.html


(Chapter-Page) 6-36

Figure 5-24: Dashboard - Active Asset Monitor

6 MEASUREMENTS

6.1 ACCELEROMETER: BRAKING

6.1.1 STRATEGY & HYPOTHESIS

STRATEGY

The strategy was to record accelerometer data while conducting a series of controlled tests. A quiet straight asphalt motorway was acquired, as illustrated in Figure 6-1. The device was set to record the accelerometer data continuously. Every recording includes the departure and stopping before and after each test. The vehicle was driven to obtain a speed of before completely stopping. The tests were conveyed in two sections. Three tests were done by stopping in a regular and comfortable fashion after which an additional three tests were done by stopping in a reckless and uncomfortable manner. The vehicle used was a Toyota Corolla 1986 model, manual front wheel drive with no ABS (Anti-lock Braking System). The objective is to obtain a threshold value that distinguishes between acceptable and reckless braking behaviour.


(Chapter-Page) 6-37

Figure 6-1: Braking Test Location

HYPOTHESIS

It was expected to be able to identify acceleration and deceleration patterns from the readings of the Y-axis. Furthermore it was expected to be able to differentiate between severities of acceleration and deceleration by observing the difference in the peak heights and offset values; and the duration the acceleration or deceleration occurred. In these tests the X-axis should not have any significant meanings.

6.1.2 RESULTS

Figure 6-3 to Figure 6-8 are the results of the six braking tests. In order to ease comparisons the vertical scale on all the figures were selected to range from to . Figure 6-2 is the legend for all the tests conveyed.

All the graphs starting at zero is the LTI filter settling. Analysing the results, it is clear in all the graphs where a gear was shifted. This is illustrated on Figure 6-3. These graphs confirm that braking occurred while the vehicle was in third-gear. Figure 6-7 illustrates thet normal braking results in a gradual and longer stoppong time whereas Figure 6-8 illustrates that reckless braking results in a shorter and higher deceleration.

Figure 6-2: Legend

Figure 6-3: Normal Breaking Test 1

Figure 6-4: Reckless Braking Test 1


(Chapter-Page) 6-38

Table 6-1: Differentiator Thresholds

Y-Axis Test 1 Test 2 Test 3 Average

Normal Braking 24.3 27.3 25.2 25.60

Reckless Braking 42.3 41.7 37.3 40.43

The results in Table 6-1 were obtained after the differentiator was applied to each scenario. These are the thresholds determined for each normal and reckless braking test.

6.1.3 CONCLUSION

A threshold of was implemented in the microcontroller so that it will trigger on the events described in Table 5-5 on page 5-12. With the threshold set, the device reported reckless braking as expected thus rendering this experiment successful.

6.2 ACCELEROMETER: TURNING

6.2.1 STRATEGY & HYPOTHESIS

The strategy was to record accelerometer data while conducting a series of controlled tests. A large circle was acquired and the tests where conveyed during a quiet and safe time of day, as illustrated in Figure 6-9. Every recording includes the departure and stopping before and after each test. The device was set to record the accelerometer data






(Chapter-Page) 6-39

continuously. The tests were conveyed in two sections. All the tests were done by entering and leaving the circle at the same node. Three tests were recorded in a regular and comfortable fashion after which an additional three tests were done in a reckless and uncomfortable manner. The vehicle used was a Toyota Corolla 1986 model, manual front wheel drive with no ABS. The objective is to obtain a threshold value that distinguishes between acceptable and reckless turning behaviour.

Figure 6-9: Turning Test Location

HYPOTHESIS

It was expected to be able to identify the normal component of the acceleration vector and also to identify patterns from the readings of the X-axis. Furthermore it was expected to be able to differentiate between severities of the normal acceleration by observing the difference in the peak heights and offset values; and the duration the acceleration or deceleration occurred. In these tests the Y-axis should not have any significant meanings.

6.2.2 RESULTS

Figure 6-11 to Figure 6-16 are the results of the six turning tests. In order to ease comparisons the vertical scale on all the figures were selected to range from to . Figure 6-10 is the legend for all the tests conveyed.

Figure 6-11illustrates the characteristics of entering, completing and exiting a circle. Figure 6-11and Figure 6-12 illustrate a clear destingshion between normal and reckless turning. In Figure 6-13 and Figure 6-14 the duration spent in the circle clearly differs from normal to reckless, a higher normal component of acceleration is expected when the velocity throughout the experiment is higher thus the circle is completed quicker. Figure 6-15 and Figure 6-16 illustrates how a left or right turn can be identified as the acceleration deviates from the X-axis offset.

Figure 6-10: Legend


(Chapter-Page) 6-40

Figure 6-11: Normal Turning Test 1

Figure 6-12: Reckless Turning Test 1





Table 6-2: Differentiator Maximums

X-Axis Test 1 Test 2 Test 3 Average

Normal Turning 27.7 31.2 33.0 33.63

Reckless Turning 40.9 58.6 61.3 53.68

6.2.3 CONCLUSION

A threshold of was implemented in the microcontroller so that it will trigger on the events described in Table 5-5 on page 5-12. With the threshold set, the device reported reckless turns as expected, thus rendering this experiment successful.


(Chapter-Page) 7-41

7 CONCLUSIONS & RECOMMENDATIONS

7.1 CONCLUSION

The primary objectives for this project were to design and produce an all-inclusive product prototype that can actively monitor a vehicle’s location, velocity and driver behaviour whilst transmitting relevant data to a centralized web-server. All of these aspects were thoroughly researched and successfully achieved. Data such as acceleration, speed and tilt angle of the vehicle was measured and used to characterize driver behaviour.

It was concluded that companies with similar products and features such as live tracking and driver behaviour monitoring does not use accelerometers to characterize the driver’s behaviour. They would use velocity to identify reckless behaviour and monitor position to identify usual operating zones. Accelerometers are very sensitive to vibrations and data captured from them was analysed with caution. Through the use of various carefully designed LTI (Linear Time-Invariant) filters this project has succeeded in detecting various levels of reckless driving behaviour from monitoring and interpreting multi directional acceleration.

The difference between acceptable and reckless driving behaviour is based on the occupants’ experience. Different people might have different experiences and will rate certain events differently. It was a challenge to quantify feelings and to create a model to respond to them.

The measurements and simulations conducted gave tremendous insight to what aspects of driver behaviour can be monitored and characterized with an accelerometer. The numerical thresholds obtained to distinguish between acceptable and reckless driving where implemented and proved to produce accurate readings.

The force experienced by the accelerometer is the same force experienced by occupants of the vehicle. The force experienced in a vehicle is a function of its mass and the acceleration of it. Transferring the Active Fleet Monitoring & Reporting System to another class of vehicle such as a minibus or a cargo truck with a different mass will require the recalibration of the acceleration thresholds in order to detect certain behaviour. Nevertheless this system enables easy modification of these thresholds.

7.2 RECOMMENDATION

The end-user might want to modify acceleration thresholds remotely, thus a facility enabling the end-user to adjust thresholds from the web-interface will ease numerous procedures. Tracking facilities such as stop logging, fuel logging, geofencing, driver identification and database queries can be implemented to provide more end-user functionality.

For the Active Fleet Monitoring & Reporting System to be mass implemented further research must be done. Observing and characterizing the relationship between the acceleration thresholds and the mass of the vehicle is a topic of high importance.


(Chapter-Page) 8-42

8 LITERATURE REFERENCES

[1] W. Wolf, Computers as Components: Principles of Embedded Computing System Design, Morgan Kaufmann, 2008.

[2] B. Principi, “Legislation largest driver for telematics,” Telecommuncations Online & Horizon House Publications, 2012.

[3] J. Medland, UK Emergency Calls, British Telecommunications 999, 2011.

[4] D. McClure and A. Graham, “eCall – The Case for Deployment,” The Department for Transport, 2006.

[5] J. Stojaspal, Telematics opportunties in Brazil and LATAM, part II, London: Telematics Update, 2012.

[6] Arrive Alive, “Vehicle and Insurance Telematics,” 202. [Online]. Available: www.arrivealive.co.za. [Accessed 1 October 2012].

[7] B. Zondi, “3000 KZN TAXIS TO BE FITTED WITH SMART CARD TECH, ON-BOARD CAMERAS,” Engineering News, Creamer Media, p. 6, 13-19 July 2012.

[8] Atmel Corporation, “Datasheet: ATmega640/1280/1281/2560/2561,” Atmel Corporation, San Jose, USA, 2012.

[9] Freescale Semiconductor, “Datasheet: ±1.5g, ±6g Three Axis Low-g Micromachined Accelerometer,” Freescale Semiconductor, Tempe, Arizona, 2008.

[10] D. G. Manolakis and J. G. Proakis, “Digital Signal Processing,” in Principles, Algorithms, and Applications Fourth Edition, Upper Saddle River, New Jersey, Pearson Education, Inc., 2007, pp. 354-410.

[11] Road Safety Authority, “Road Safety Authority,” Transport Research Laboratory, UK, 2007. [Online]. Available: http://www.rulesoftheroad.ie/rules-for-driving/speed-limits/speed-limits_stopping-distances-cars.html. [Accessed 15 September 2012].

[12] J. L. Meriam and L. G. Kraige, “Engineering Mechanics Dynamics,” in Engineering Mechanics Dynamics Sixth Edition, Virginia, John Wiley & Son, Inc., 2008, pp. 21-26.

[13] D. Kecman, J. Lenard and P. Thomas, “Safety of Seats in Minibuses - Proposal for a Dynamic Test,” Cranfield Impact Centre Ltd & Vehicle Safety Research Centre, United Kingdon.

[14] M. Clifford and L. Gomez, “Measuring Tilt with Low-g Accelerometers,” Freescale Semiconductor, Tempa, Arizona, 2005.


(Chapter-Page) 8-43

[15] M. Gopal, Digital Control and State Variable Methods - Conventional and Intelligent Control Systems, Delhi: McGraw-Hill, 2010.

[16] Globalsat Technology Corporation, “Datasheet: GLOBALSAT GPS Engine Board,” Globalsat Technology Corporation, Hsien, Taiwan, 2010.

[17] G. Baddeley, “NMEA Data,” 24 May 2011. [Online]. Available: http://www.gpsinformation.org/dale/nmea.htm. [Accessed 21 August 2012].

[18] Kingmax, “Micro SD Card Specification,” Kingmax, 2005.

[19] Atmel, “AVR910: In-System Programming,” Atmel, San Jose, CA, 2008.

[20] Sierra Wireless, “Datasheet: GL61x0 Product Technical Specification and User Guide, AirLink GL Series,” Sierra Wireless, 2010.

[21] Digilent, “Datasheet: Digilent PmodRS232 Converter Module Board,” Digilent, 2007.

[22] D. DePriest, “NMEA Data,” [Online]. Available: http://www.gpsinformation.org/dale/nmea.htm. [Accessed 21 August 2012].


(Appendix-Page) A-1

Appendix A PROJECT MANAGEMENT The following project plan was created in Microsoft Project 2010. It visually demonstrates all the tasks, task groupings and milestones from the commencement to the completion of the project (2012/07/23 – 2012/11/05).

A.1 GANTT CHART


(Appendix-Page) A-2


(Appendix-Page) B-1

Appendix B PROJECT SPECIFICATION The primary objectives for this project are to design and produce an all-inclusive product prototype that actively monitors multiple vehicles and reports to a centralized web-server.

Accomplishing this task requires the development of a number of hardware and software subsystems.

B.1 HARDWARE SPECIFICATIONS

a) Integration of a GPS that enables the capturing of current position, velocity, time and date.

b) Integration of an accelerometer that enables measuring of the severity of multi-axial acceleration.

c) Integration of a cellular modem to report vital parameters in a periodic fashion. d) Integration of secondary memory in order to log on-going events and behaviour. e) Development of an electronic control circuit to interface with, and control the above

sensors, and to interface with the cellular network. f) Implementation of a power conditioning circuit to obtain power from the vehicle’s

power source.

B.2 SOFTWARE SPECIFICATIONS

a) Development of a web-based interface that allows the end-user to monitor individual vehicles or fleets as a whole.

b) Programming of an electronic control circuit to interface with, and control the hardware in 3.1

B.3 MEASUREABLE REQUIREMENTS

a) A technique must be developed, tested and confirmed in which reckless driving can be measured and detected.

b) Data must be reported to a web-server in such a manner, which data and how often, that it is useful to the end-user.

c) Data must be stored on the device’s secondary storage containing all the necessary information to retrace and simulate an event.


(Appendix-Page) C-2

Appendix C SPECIFIC OUTCOMES AND ASSESSMENT CRITERIA Appendix Table C-1: ECSA Exit Level Outcomes Assessed in this Module

Outcome Assessment Items Chapter.Section

1. Problem Solving (identify, assess, formulate and solve convergent and divergent engineering problems).

Identify problem and solution criteria; Identify engineering info required for solution; Formulate solution approaches; Model/ analyse solutions; Evaluate solutions; Formulate / present the solution.

1.1, 1.2, 1.3 and 5

2. Application of Scientific and Engineering Knowledge

Use Engineering knowledge and methods o Formal analysis and modelling; o Communicate concepts, ideas and theories; o Reasoning and conceptualizing using components; o Dealing with uncertainty.

Use Physical laws as foundation o Formal analysis and modelling; o Reasoning and conceptualizing using physical principles.

Use techniques, principles and laws of engineering science o Identify and solve open-ended engineering problems; o Work across engineering disciplinary boundaries (shared fundamental

knowledge).

5.2, 5.3 and 6

3. Engineering Design (procedural and nonprocedural design and synthesis of components, works, products and processes)

Identify/formulate problem to satisfy user needs, applicable standards, code of practice and legislation;

Plans and manages the design process; Acquires and evaluates requisite knowledge; Performs design tasks, quantitative modelling and optimization; Evaluate alternatives (judgment, implement ability and techno economic

analysis); Assesses impact and benefits; Communicates design logic and information.

1.3, 2, 3, 5, 6 and Appendix A

4. Investigations, experiments and data analysis (design and conduct

Plan and conduct investigations/ data analysis; Conducts critical literature search;

2, 5.2, 6 and 7


(Appendix-Page) C-3

investigations and experiments) Performs analysis; Select and use equipment/ software; Analysis/ interprets information from data; Draws conclusion (evidence); Communicates purpose, process and outcomes in report.

5. Engineering Methods, Skills and Tools, including Information Technology (methods, skills and tools, including those based on information technology)

Uses method, skill and tools by: o Selecting/ assessing the applicability/ limitations of the methods,

skills and tools; o Properly applying the method, skill or tool; o Critically testing and assessing the results produced.

Creates computer applications.

5.1, 5.2, 5.3, 5.4, 5.5 and 6

6. Professional and Technical Communication (effective oral and written communication)

Written communication: o Uses appropriate structure, style and language for purpose/ audience; o Uses effective graphical support; o Applies engineering methods of providing information; o Meets the requirements of the intended audience.

Oral communication: o Uses appropriate structure, style and language; o Uses appropriate visual materials; o Delivers fluently; o Meets the requirements of the intended audience.

1.4, 1.5 and 4

9. Independent learning ability (independent learning through well-developed learning skills)

Reflects on own learning and determines requirements and strategies; Sources and evaluates information; Assesses comprehends and applies knowledge acquired outside formal

instruction; Critically challenges assumptions and embraces new thinking.

2 and 5


(Appendix-Page) D-4

Appendix D INTERFACE INTERPRETATION

D.1 NMEA SENTENCES

The Appendix Table D-1 to Appendix Table D-5 where produced from information gathered from online sources [17] [22].

Format: $GPGGA,hhmmss.ss,ddmm.mmm,a,dddmm.mmm,b,q,xx,p.p,a.b,M,c.d,M,x.x,nnnn*XX

Example: $GPGGA,210037.000,3355.4308,S,01851.8181,E,1,04,3.2,27.1,M,32.8,M,,0000*7C

Appendix Table D-1: NMEA GPGGA Global Positioning System Fix Data

Description Format Example

UCT (Coordinated Universal Time) hhmmss.ss 21007.000

Latitude ddmm.mmmm 3355.4308

Latitude hemisphere a S

Longitude dddmm.mmmm 01851.8181

Longitude hemisphere b E

Quality indicator q 1

Number of satellites in use xx 04

HDOP (Horizontal Dilution of Precision) p.p 3.2

Altitude a.b 27.1

Units M M

Antenna altitude above mean-sea-level c.d 32.8

Units M M

Age of Differential GPS data x.x

Differential reference station ID nnnn 0000

Checksum XX 7C

Format: $GPGLL,ddmm.mmmm,a,dddmm.mmmm,b,hhmmss.ss,c*XX

Example: $GPGLL,3355.4308,S,01851.8181,E,210037.000,A*2C

Appendix Table D-2: NMEA GPGLL Geographic Position, Latitude & Longitude







Validation (A=Valid, V=Invalid) A A

Checksum XX 2C

Format: $GPGSA,a,x,s1,s2,s3,s4,s5,s6,s7,s8,s9,s10,s11,s12,a.a,b.b,c.c*XX


(Appendix-Page) D-5

Example: $GPGSA,A,3,16,31,03,19,,,,,,,,,5.4,3.2,4.3*3B

Appendix Table D-3: NMEA GPGSA GPS DOP & Active Satellites


Manual or Auto 2D or 3D fix (A=Auto, M=Manual)

A A

Fix type (1=No, 2=2D, 3=3D) x 3

PRN's of SV's (Satellite Vehicle) used in position fix (null for unused fields)

s1-s12 16,31,03,19

PDOP (Position Dilution of Precision ) a.a 5.4

HDOP (Horizontal Dilution of Precision) b.b 3.2

VDOP (Vertical Dilution of Precision) c.c 4.3

Checksum XX 3B

Format: $GPRMC,hhmmss.ss,A,ddmm.mmmm,a,dddmm.mmmm,b,x.x,x.x,ddmmyy,x.x,a*XX

Example: $GPRMC,210037.000,A,3355.4308,S,01851.8181,E,173.8,231.8,100812,004.2,W*0F

Appendix Table D-4: NMEA GPRMC Recommended minimum Specific Transit Data



Validation (A=Valid, V=Invalid) A A





Speed (Knots) x.x 137.8

True course x.x 231.8

Date ddmmyy 100812

Variation x.x 004.2

Variation directions (E,W) a W

Checksum XX 0F

Format: $GPVTG,x.x,T,x.x,M,x.x,N,x.x,K

Example: $GPVTG,360.0,T,348.7,M,5.50,N,12.1,K*7E

Appendix Table D-5: NMEA GPVTG Track Made Good & Ground Speed


Track made good x.x 360.0

T=Relative to true north T T


(Appendix-Page) D-6

Magnetic track made good x.x 348.7

M=Relative to magnetic north M M

Speed x.x 5.5

N = Knots N N

Speed x.x 12.1

K = km/h K K

Checksum XX 7E

active fleet monitoring & reporting...

Documents