UCF Senior Design 1
H.A.R.A.M.B.E.
Heterogenous Automotive Response Apparatus Messenger for Big Emergencies
A.C.E.
Automotive, Correspondence, Enabler
Department of Electrical Engineering and Computer Science
University of Central Florida
Dr. Lei Wei
Initial Project Document and Group Identification
Divide and Conquer
Group 33
Tommy Goris / Computer Engineering /Jacob Wurm / Computer Engineering /
Jihang Li / Electrical Engineering /
Ismael Rivera / Electrical Engineering /
1.Project Proposal
The objective of this project is to develop a device that will contact emergency services on the driver’s behalf in the event that they get into a vehicular accident. The device will be able to take in information from the vehicle’s OBD-II port. If time allows we may add a series of sensors including an accelerometer and a g-sensor to get better readings and data for our microcontroller. Based on the data gathered from these sensors and the on-board diagnostics of the carthe system will be able to determine whether the driver has been in an accident. If the driver was indeed in an accident the device will query the driver’s current location and other data about the event, such as how fast the vehicle was moving, the acceleration of the vehicle and ultimately the severity of the crash. Afterwards it will send a message to emergency services containing the driver’s personal information and location. This message will be sent through a GSM module included in the system. Emergency services will be notified of the accident and be provided the location where the accident occurred. As a result, the driver will be able to get the help that they need without having to call emergency services.
Another key feature for safety will be added to the system design. In the event that the driver is not within the range of a cell tower, the device will act as a beacon. When another vehicle drives by it will be able to pass the message along to that vehicle in the hopes that once they are within the range of a cell tower the message will be transmitted. The passing of this message will be done through a Zigbee module or a Wi-Fi module.
2. Narrative Description
When driving a car, one of the most dangerous parts of the journey is driving in sparsely populated or rural areas. In these areas there are not a significant number of people so in the event of an accident the driver and their passengers would not be able to get help promptly. This lack of help could lead to the demise of the driver and their passengers. Another disadvantage of driving in a rural area is the response time of emergency services. Several studies show that people with lesser injuries are more likely to die in rural areas than urban areas. This may be because the response time is significantly slower in rural areas. Regardless, we believe it is important that the authorities are alerted as soon after the accident as possible.
One solution that has helped alleviate this problem is the introduction of mobile phones into the global market. With a vast majority of the population now owning mobile devices it is definitely easier for people to call emergency services when needed. This solution could be great for car accidents because even if the driver and their passengers are injured, a bystander could call emergency services on their behalf. However, this solution breaks down in a sparsely populated area where there is a much smaller likelihood of bystanders being present. If a severe car crash occurs in this environment, the drivers and passengers of both vehicles will most likely not be able to receive help from emergency services. To ensure the safety of these people, we propose A.C.E, Automobile Correspondence Enabler, to allow quick action before, during, and after a car crash. The intended effect of A.C.E is to continuously monitor the vehicle for any sort of collision, and if a collision is detected, A.C.E will immediately contact emergency services with an automated call and/or text message. When driving a car, one of the many features our product will have is to provide a hands-free, automated service that will save lives. If you wish for the product to contact emergency services as well as friends and family during an emergency. It will be possible to add custom numbers into the directory of contacts.Also, in the event that the driver and their passengers are injured they will not be able to operate a mobile device, rendering the device useless. If they are unable to contact emergency services, they may perish.
Another solution that has been developed is having an automated system built into the vehicle. Examples of this service that are currently on the market include OnStar, Lexus Link, and BMW Assist. These services will alert emergency services in the event of an accident as well as connect you to an agent who will assess the situation. These services are very effective in helping those drivers, however their service is only available to a subset of the population who drive a vehicle of that specific make. A driver who operates an older vehicle that doesn’t contain the technology necessary for these services will be unable to utilize it. This leaves out a vast majority of drivers. Luckily since technology is improving, this technology is being seen in a growing percentage of vehicles.
Our project aims to alleviate the shortcomings from the former solutions by proposing a universal adapter which will connect to any vehicle manufactured after 1996. We will be able to meet this requirement by connecting to the vehicle’s on-board diagnostics port (OBD-II). Through this port we will be able to gather information from the vehicle such as the velocity, and the state of the airbags. In addition, we will have an accelerometer and a g-sensor to detect sudden changes in acceleration and the direction of the vehicle. By collecting this information, the system will be able to determine whether or not the driver has been in an accident. In addition to determining the possibility of an accident, the system will also aggregate and collect this information, similar to a black box in an airplane. When emergency services arrive they will be able to analyze variables from the situation that caused the accident, such as how fast the driver was moving, how suddenly they stopped, etc.
Another feature of this system is its ability to communicate with other similar systems. This system will be used in the event that the driver is not within the range of a cellular tower, and thus will be unable to contact emergency services. In this situation the system will act as a beacon for vehicles passing by. The system will be able to transmit a packet of information containing the location of the damaged vehicle and certain information about the internals of the vehicle. Once the passerby vehicle is within the range of a cellular tower it will be able to pass along the message for the driver.
3. Motivation
The risk of losing our lives is completely real when we make the conscious decision of getting inside an automobile and driving to our destination. One second you may be singing along to a song on the radio, and in an instant be lying in a pool of your own blood due to a reckless driver hitting you at speeds greatly above the speed limit. In this situation, you don’t have many options of survival, you are disoriented and slowly falling unconscious, as you leave your life at the hands of those nearby. But this crash occurs in the middle of the night, and the driver that has crushed your life decides to run away from the scene, leaving you to your fate. Luckily, a passerby spots the accident and decides to immediately call emergency services as he spots you unconscious in the automobile with no one else on sight. The ambulance arrives and takes you to the nearest hospital where doctors try their best to save your life. Unfortunately, that day marked the end. If only you had made it to the hospital earlier. Could a couple minutes have made a difference between life or death? If so, then the doctors would have been able to save your life. This is just one, of many realistic situations where an immediate response to an emergency service would have been able to save a life. A car crash is a real fear any individual is susceptible to, the fear of seeing the faces of your family, friends, and even yourself, gone forever. We want people to feel safe and secure when they are in an automobile. We want to be the difference those couple minutes make. The fear will always be there, but it is possible to undermine it by making sure, that in the event of an emergency, those in a severe accident will be taken care of.
4. Goals and Objectives
The goal of this project is to ensure that in the event of an automobile accident, the driver and passengers of both vehicles will be able to get immediate help from emergency services. An automated call/or message is sent instantaneously so that emergency service can arrive in the fastest amount of time possible. Along these lines, keeping the product low cost and of high quality is an essential goal. Since the idea is to connect the device to the OBD-II port of a vehicle, it is also important to make it easy to install and operate. A universal OBD-II port connection is an extreme goal/objective to achieve due to our time constraints but outside of this project and in the market it would be necessary as different models of cars follow different OBD-II protocols. The type of OBD-II protocol a vehicle uses may range from the year it was made to the make of the vehicle. Nevertheless, as a long term goal we would like to ensure that all cars can be equipped with this kind of technology.
5. Constraints and Standards
Constraints
- Vehicle Age
The OBD-II standard began being implemented only in vehicles manufactured after 1996. So in the case of our project we are constrained to vehicles that were manufactured after 1996.
- Cost
It is important to minimize the cost of the product while still providing high quality and service. There are many competitors with similar features and tools as our product, but they are expensive to create and buy.
- Time
Time is a major constraint for this project. We started this project Fall 2016 and are required to finish it by Spring 2017.
- Protocols
There many different types of OBD-II port protocols that follow different rules. It is not yet known how many of these protocols we will be able to use.
- Size
In order for the driver to continue operating their vehicle safely, the device must not protrude too far into the driver’s pedal area.
Standards:
-Wi-Fi - IEEE 802.11
-GPS
-UART
-OBD-II PIDs
-Zigbee
The standards below designed to allow microcontrollers and devices to communicate with each other on every vehicle approved by the SAE J1979 standard built after 1996.
●CAN-bus (vehicles after 2008, CAN only)
●ISO
●KWP
●GSM
6. Estimated Budget
This is our estimated budget for the project. Some of these prices may be subject to changes in the near future. Our team will be taking care of the funds by splitting up the costs. As of now, it is expected that the bulk of the team’s expenses be placed on getting several custom PCBs to ensure that a replacement will be available quickly if an error occurs or if we need to test/use the PCB.
Device / Quantity / Price / Total priceCustom PCB / 5 / $20.00 / $100.00
GSM / 1 / $12.85 / $12.85
GPS / 1 / $17.27 / $17.27
MCU / 1 / $12.00 / $12.00
Battery/ Supercapacitor / 1 / $6.00 / $6.00
Accelerometer / 3 / $1.32 / $3.96
OBD-II Female / 1 / $4.17 / $4.17
ZigBee Module / 1 / $9.30 / $9.30
ELM-chip (communicating with OBD) / 2 / $12.00 / $24.00
Total Cost / $189.55
7. Time table
Week 1 (Aug 29 - Sept 9)
●Completion of the Initial Project and Group Identification Document document
●Initial project research.
Week 2 - 4( Sept 10 - Sept 23 )
●Research for the project to familiar with basic parameters (airbag,velocity and tire) of the 3 different types of vehicles.
●Initial OBD-II port testing with these parameters
Week 5 - 7 (Sept 24 - Oct 8)
●Research on GPS module and GSM module and start to test both with microcontroller, to receive an address
●Prototype GPS module and GSM module
Week 8 - 10 (Oct 9-Oct 23)
●Research on zigbee module
●Prototype zigbee module
Week 9 (Oct 24-Oct 31)
●Research on wireless communication with another vehicle
●Prototype wireless communication
Week 10-11( Nov 1 - Nov 15)
●Prototype OBD-II with microcontroller
●Prototype battery
Week 12 - 13 (Nov 16 - Nov 30)
●Final draft review
Week 14 - 15 (Dec 1 - Dec 12)
●Submit final document
Senior Design 2:
Week 1
●Design PCB on Eagle
Week 2
●Order PCB
Week 3- 5
●PCB Testing
●GPS and GSM module Testing
Week 6 - 9
●Overall Testing
●Pre-demo
Week 10-15
●Final document and presentation for Demo
●Demo day
8. Block Diagram
Functional:
Division of Responsibility:
Green: Computer Engineering (Jacob Wurm)
Red: Computer Engineering (Tommy Goris)
Blue: Electrical Engineering (Jihang Li)
Brown: Electrical Engineering (Ismael Rivera)
Grey: Project goal
Software Block Diagram:
Protocols:
-ISO9141-2(5 baud init, 10.4Kbaud)
-ISO14230-4 KWP (5 baud init, 10.4 Kbaud)
-ISO14230-4 KWP (fast init, 10.4 Kbaud)
-ISO15765-4 CAN (11bit ID, 500 Kbaud)
-ISO15765-4 CAN (29bit ID, 500 Kbaud)
-ISO15765-4 CAN (11bit ID, 250 Kbaud)
-ISO15765-4 CAN (29bit ID, 250 Kbaud)
9. House of Quality
The tradeoffs for our project are labeled in the House of Quality chart. The plus sign and the arrows pointing up determine an advantage our system may have over similar products in the market. The minus sign and the downward facing arrows show a disadvantage our product will have compared to the market. For starters, it is important to understand what kind of chip is used to communicate with the OBD-II. The chip we use to communicate with the OBD-II will draw some power from the power input pin. This pin is connected to the car battery so it is paramount to draw a small amount of power. Determining the amount of power different chips use and how fast they transmit data will be crucial in figuring out what kind of chip to use in the end. The power input ultimately correlates directly to the system's lifespan when not considering outside factors.
Similar to the data rate and its tradeoffs, the efficiency of the product varies depending on the amount of power that is used. The lifespan will suffer if we fail to understand the risks and tradeoffs between the efficiency and the lifespan of the product. If the system is not efficient there are many problems that may occur. One of the main problems that might happen is that the system may overheat and ultimately not only damage the system but the car itself.
The most important aspect of the product based on tradeoffs is the power input we decide to use. Not only will the power input affect cost, install ease, lifespan, etc, but also the failure to install a proper power input will make the efficiency of the product to suffer greatly.
Out of all the marketing requirements we primarily want the product to be cheap. The main reason we want our product to be cost efficient is due to the fact that our team is much smaller than the companies in the competing market. As a result, we will have to make a good product with less time and less resources. That does not mean that our product will not be viable and as useful to any person interested in this market. As a result, this will take our full effort to have be competitive.
Install ease is something we will strive to make this product good at. Since this system is powered by the OBD-II port in cars we want this to be compatible with a variety of cars and easy to install. Our first objective is to meet one of the many standards implemented right now which is ISO9141-2 which was used by many car manufacturers from 1996 to 2004. We chose this protocol in particular because it will allow us to test our system on our automobiles. If time allows we will try to meet other standards as well.
Last, but not least, the range, in terms of tradeoffs, will vary greatly based on the power usage, installation, and the features that it has. A powerful tool with great range will suffer from its power usage, but a weak tool suffers greatly because it will lack in performance, efficiency and ultimately will not be able to work at all.
Engineering / RequirementsRange / Efficiency / Data Rate / Power Input
(+) / (-) / (-) / (+)
Install Ease / (-) / ↑↑ / ↓ / ↓ / ↑↑
Marketing / Cost / (+) / ↓ / ↓ / ↓↓ / ↑
Requirements / Features / (-) / ↑↑ / ↓↓ / ↓↓ / ↑
Life Span / (+) / ↑ / ↑ / ↑ / ↓
Engineering Targets / >20km / >75% / >2KBps / < 2W @ 3,3V