The Implementation of the Multi-channel ADC Module The basic principle of operation of the multichannel ADC Module is;

 Firstly: required 5 unused GPIO ports to be configured as analogue inputs. These ports will be reading the sensors that attached to these ports referenced to 3.3 Volts. Most sensors on motor vehicles are normally 5v sensors which means the device will need to do some level shifting.

25

 The ADC module on the microcontroller has to be configured for multichannel processing. See appendix A.

 Seeing that device will be using DMA to transfer the data from the ADC peripheral to the ADC Buffer. This will also be set up.. In this design the peripheral_base_address of the ADC is the Data register of the ADC the device is using. The memory address will be the array that is created to store the respective converted ADC values ConvertedAdcValue[].This array will be volatile as the values can change any given time and outside the code.

 So each index of the array will store one sensor value, the value of the sensor that the GPIO is reading. Each index of the ConvertedAdcValue will be copied to a static array and each index of that array will be stored as global variables for use in the code.

 E.g. int Vspd=ConvertedAdcValue[0];The static buffer created will be used in the serialization routine for transmission to the remote control centre. The variables created from this array will be used by the GSM state machine to control the various modes of transmission.

 The ADC Module will also responsible for determining the engine running hours that is necessary for asset management. The Ignition of the vehicle and Engine speed are the two parameters used to start the Running_Hours function which is a counter: if(IGN>0&&Rpm>0) { Running_Hours(); } 2.9 OBD Module 2.9.1 Overview

The fundamental purpose of this design is to acquire data from a specific asset and present it in a desired format to remote collection service for storage as well as analytics. The asset in question is a modern motor vehicle.

Motor vehicles are no longer just a mechanical apparatus they have numerous electronic control units networked together.

Since 1996, most vehicles have been required by law to monitor their own emissions performance and to report on it through an On-Board Diagnostics port. This has lent us the

26

opportunity to able to retrieve this data and possibly analyse it but also to make decisions based on this data in terms of asset lifecycle management as well as asset optimisation. Before 2008, several different protocols were used as base protocol for transferring OBD data. All vehicles after 2008 have to be CAN compliant. Today’s vehicles have many built- in computer systems that control parts of the car such as fuel injections, airbags or brakes. All of these systems are controlled by one of several Electronic Control Units (ECU), which communicate with each other over the internal high speed Controller Area Network (CAN) of the car.

In this chapter, we focus on the implementation of the OBD module on its own and it the next Chapter the CAN module on its own. The reason being their functional implementation in this thesis is different for the purpose of asset tracking and also they are fundamentally different technologies. As many of the vehicles that we are interested in monitoring will be vehicles prior to 2008 the OBD module is and essential module for the asset tracking device. 5.2 The OBD II Standard

The On-Board Diagnostics (OBD) can discover and diagnose problems with the data reported by the ECUs. If a problem occurs, the OBD system generates a trouble code that which makes it possible for a service engineer to identify and fix the problem. Trouble codes and other diagnostic information can be accessed by plugging an OBD scan tool into the OBD interface in the car. The main advantage with having an OBD system is that it makes it easier to diagnose faults that occur in the vehicle. An advantage from a sustainability point of view is that vehicle emissions can be reduced by discovering and fixing problems, that makes the vehicles emission levels rise, that otherwise might not have shown any noticeable symptoms to the user or service personnel. This design however will not be using the full functionality of the OBD system just the monitoring capability as the main purpose is to retrieve data that can impact asset lifecycle management. There is clearly numerous application for using the fault codes and engine management diagnostics capability of the OBD module but will not implemented in this design as this design is focussed on the tracking of specific asset data.

There are numerous end-user products for extracting OBD trouble codes from cars but these products are stand-alone with little to no user-based content around the faults and or

monitoring. For the asset-tracking device, this will be monitoring pre-2008 vehicles and in some case specialised vehicles pre 1996.

On Board Diagnostics OBD is the computer system built into cars that monitors the

performance of the engine components as well as other control units. It consists of several ECUs that uses various sensors to collect data and evaluate the performance of the car. The OBD module in this design will monitor various predefined data or PID’s of the vehicle and

27

relay it to the control centre. There is how ever very few or no aftermarket implementation of remote monitoring real time obd data to a control centre

There is no available implementation of an OBD software library that can freely be used on an embedded system to communicate with the OBD system in a car and extract information. The objective of this module is to develop a system that can monitor data present by the OBD system and make the information accessible to the asset manager.

OBD2 permits five different communication protocols, as listed in table 3-1, which can be used to communicate with the OBD2 interface. Most vehicle manufacturers only implement one of these protocols so it is often possible to identify the used communication protocol by looking at which pins are present on the connector.

Standard Description

SAE J1850 Pulse-Width Modulation (PWM) SAE J1850 Variable Pulse Width (VPW) ISO 9141-2 Similar to RS232

ISO 14230 Keyword Protocol 2000 (KWP2000) ISO 15765 CAN (250kbps or 500kbps)