Automatic Management System for vehicles
All printed material, including text, illustrations, and charts, must be kept within a print area of 6-1/2 inches (16.51 cm) wide by 8-7/8 inches (22.51 cm) high. Do not write or print anything outside the print area. All text must be in a two-column format. Columns are to be 3-1/16 inches (7.85 cm) wide, with a 3/8 inch (0.81 cm) space between them. Text must be fully justified.A format sheet with the margins and placement guides is available as both Word and PDF files as <format.doc> and<format.pdf>. It contains lines and boxes showing the marg ins and print areas. If you hold it and your printed page up to the light, you can easily check your margins to see if your print area fits within the space allowed
A. DescriptionIn 1988, the US Environmental Protection Agency (EPA) established for vehicle manufacturers to necessarily include a program of self – diagnosis in automotive computers. This first generation of on-board diagnostic systems was known as OBDI. [2]
OBDI is a set of programmed instructions in computers or automotive brains. The main objective of these programs is to detect any damage that might occur in actuators, switches and the wiring of any system that is related to gas emissions fro m the vehicle. Therefore if the computer detects a failure or malfunction in any of these systems, an indicator on the dashboard is lit. The indicator therefore will only be lit when a problem is detected in the vehicle emissions.OBDII offers a second version of OBDI, the diagnosis programs are improved and show a new automotive monitoring function, unlike OBDI that was only able to identify damaged components. The monitoring function not only deals with issues related to gas emission systems but several others responsible for the proper operation and safety of the vehicle. OBDII also allows all this information to be available and accessible to owners and mechanics using the proper equipment. However, OBDII’s main characteristic is standardization but each manufacturer implemented it based on their own considerations. The connector, communication protocols, fault codes and terminology varied depending on the car brand, so diagnostic systems had no interoperability between cars from different manufacturers. Digital Vehicle – License, Insurance And RC Book Tracing For Police Therefore OBDII three main objectives are:• Standardize communication procedures and protocols between the diagnostic equipment and automotive computers• Promote the use of a standard link connector on all vehicles.• Standardize the code numbers, code definitions and used language for the description and identification of car flaws.• Currently most modern light vehicles incorporate the OBDII standard; however, for heavy vehicles it s implementation is not yet mandator y.
B. ODBII ConnectorThe Data Link Connector or DLC is the physical interface between the vehicle’s computer and the diagnosis system or equipment. In OBDI systems shape, size and connector location varied between manufacturers while using OBDII the 16-pin connector is standardize and even though its location varies between vehicles, in general it is possible to find it in the left hand part of the instrumental board.
C. OBDII Faul CodesAlso known as Diagnose Trouble Code or DTC, these codes identify failures or malfunctioning in systems of specific components of the vehicle. Each vehicle in its instrumental board has a malfunction indicator known as “Engine Light”. When the computer detects a problem in automotive operation of one or more systems: Assigns a fault code that identifies the source of the problem, store this code in the internal memory of the computer and turns on the malfunction indicator to inform the owner to carry out a check on the vehicle.
D. Bluetooth Device BAFX OBDIIBAFX OBDII bluetooth adapter is a device that allows synchronization and communication between the computer of any vehicle manufactured after 1996 and an Android device or a a computer with Windows operating system.
The developed systems can display the engine’s RPM, vehicle speed, coolant temperature, and percentage of engine load and the accelerator position of a vehicle in the screen of an Android phone.The mobile application implemented makes a diagnosis of the mechanical condition of the vehicle using the OBDII protocol. It is obtained as a result, fault codes that are stored on a web server. Using a computer with Internet Access it is possible to access to the fault codes extracted from the vehicle and know its meaning.The implementation of data reading algorithm shows that frames extracted from the vehicle take various formats that are different from the ones expected theoretically. The main cause for this phenomenon is the greater processing capacity possessed by the mobile terminal, for this reason the creation of several regular expressions that cover all possible formats, is essential.Reading the engine RPM required special attention because the frame structure representing this parameter. Unlike the three bytes composing the frames for speed, engine load, coolant temperature and accelerator position, the frame belonging to the revolutions per minute is made up of four bytes. This is mainly because the parameter is quantified in the order of thousands unlike other parameters quantified in the order of hundreds.At first it was found that the reading of local mo nito ring parameters was incorrect because the mobile application sent new requests when the car had not yet responded to the previous request. Therefore, it was necessary to give the application a20-millisecond pause so the car has enough time to answer therequests.At the time of diagnosis, the fault codes found are presented in a certain order. When sending data to the server, the Web application shows them in a different order, however, this does not affect in any way the diagnosis result.The developed Web application allows a system user to access through Internet to all fault codes detected in a vehicle with their meanings.Thanks to the Web application, the user is able to track the speed, RPM, coolant temperature, engine load and accelerator position by using historical graphs of the behavior of these parameters.In order to verify the correct operation of the mobile application to diagnose a vehicle, a Java application that acts as a car simulator was developed, which allowed checking the optimal fault code reading done by the system.The algorithm for interpreting the data sent from the vehicle to the mobile terminal was designed using regular expressions. Code Shoppy Regular expressions allow the application to be able to correctly discriminate frames sent from the car, avoiding the presentation of wrong information.
