A System for Automatic Notification and Severity Estimation of Automotive Accidents

New communication technologies integrated into modern vehicles offer an opportunity for better assistance to people injured in traffic accidents. Recent studies show how communication capabilities should be supported by artificial intelligence systems capable of automating many of the decisions to be taken by emergency services, thereby adapting the rescue resources to the severity of the accident and reducing assistance time. To improve the overall rescue process, a fast and accurate estimation of the severity of the accident represent a key point to help emergency services better estimate the required resources.

This paper proposes a novel intelligent system which is able to automatically detect road accidents, notify them through vehicular networks, and estimate their severity based on the concept of data mining and knowledge inference. Our system considers the most relevant variables that can characterize the severity of the accidents (variables such as the vehicle speed, the type of vehicles involved, the impact speed, and the status of the airbag).

Results show that a complete Knowledge Discovery in Databases (KDD) process, with an adequate selection of relevant features, allows generating estimation models that can predict the severity of new accidents. We develop a prototype of our system based on off-the-shelf devices and validate it at the Applus+ IDIADA Automotive Research Corporation facilities, showing that our system can notably reduce the time needed to alert and deploy emergency services after an accident takes place.

1.2 INTRODUCTION

1.3 LITRATURE SURVEY

CHAPTER 2

2.0 SYSTEM ANALYSIS

2.1 EXISTING SYSTEM:

Most ITS applications, such as road safety, fleet management, and navigation, will rely on data exchanged between the vehicle and the roadside infrastructure (V2I), or even directly between vehicles (V2V). The integration of sensoring capabilities on-board of vehicles, along with peer-to-peer mobile communication among vehicles, forecast significant improvements for failure. Existing V2V architecture, the transportation network is broken into zones in which a single vehicle is known as the super vehicle. Only super vehicles are able to communicate with the central infrastructure or with other Super Vehicles, and all other vehicles can only communicate with the super vehicle responsible for the zone in which they are previously traversing in describe the super vehicle detection (SVD) algorithm for how a vehicle can find or become a super vehicle of a zone and how super vehicles can aggregate the speed and location data from all of the vehicles within their zone to still ensure an accurate representation of the network.

2.1.1 DISADVANTAGES:

  • Zero accident objectives on the long term, a fast and efficient rescue operation during the hour following a traffic accident significantly increase the probability of survival of the injured, and reduce the injury severity.
  • Communication systems between vehicles, the infrastructure should be supported by intelligent systems capable of estimating the severity of accidents, and automatically deploying the actions required, thereby reducing the time needed to assist injured passengers.
  • Many of the manual decisions taken nowadays by emergency services are based on incomplete or inaccurate data, which may be replaced by automatic systems that adapt to the specific characteristics of each accident.


2.2 PROPOSED SYSTEM:

The proposed system consists of several components with different functions. Firstly, vehicles should incorporate an On-Board unit (OBU) responsible for: (i) detecting when there has been a potentially dangerous impact for the occupants, (ii) collecting available information coming from sensors in the vehicle, and (iii) communicating the situation to a Control Unit (CU) that will accordingly address the handling of the warning notification. Next, the notification of the detected accidents is made through a combination of both V2V and V2I communications. Finally, the destination of all the collected information is the Control Unit; it will handle the warning notification, estimating the severity of the accident, and communicating the incident to the appropriate emergency services.

Our proposed architecture provides: (i) direct communication between the vehicles involved in the accident, (ii) automatic sending of a data file containing important information about the accident to the Control Unit, and (iii) a preliminary and automatic assessment of the damage of the vehicle and its occupants, based on the information coming from the involved vehicles, and a database of accident reports. According to the reported information and the preliminary accident estimation, the system will alert the required rescue resources to optimize the accident assistance.

2.2.1 ADVANTAGES:

  • In-vehicle sensors: They are required to detect accidents and provide information about its causes. Accessing the data from in-vehicle sensors is possible nowadays using the On-Board Diagnostics (OBD) standard interface, which serves as the entry point to the vehicles.
  • Data Acquisition Unit (DAU): This device is responsible for periodically collecting data from the sensors available in the vehicle (airbag triggers, speed, fuel levels, etc.), converting them to a common format, and providing the collected data set to the OBU Processing Unit.
  • OBU Processing Unit: It is in charge of processing the data coming from sensors, determining whether an accident occurred, and notifying dangerous situations to nearby vehicles, or directly to the Control Unit.
  • The information from the DAU is gathered, interpreted and used to determine the vehicle’s current status. This unit must also have access to a positioning device (such as a GPS receiver), and to different wireless interfaces, thereby enabling communication between the vehicle and the remote control center.

2.3 HARDWARE & SOFTWARE REQUIREMENTS:

2.3.1 HARDWARE REQUIREMENT:

v    Processor                                 –    Pentium –IV

  • Speed                                      –    1.1 GHz
    • RAM                                       –    256 MB (min)
    • Hard Disk                               –   20 GB
    • Floppy Drive                           –    1.44 MB
    • Key Board                              –    Standard Windows Keyboard
    • Mouse                                     –    Two or Three Button Mouse
    • Monitor                                   –    SVGA

 

2.3.2 SOFTWARE REQUIREMENTS:

  • Operating System                   :           Windows XP or Win7
  • Front End                                :           Microsoft Visual Studio .NET 2008
  • Script                                       :           C# Script
  • Back End                                :           MS-SQL Server 2005
  • Document                               :           MS-Office 2007

CHAPTER 3

3.0 SYSTEM DESIGN:

Data Flow Diagram / Use Case Diagram / Flow Diagram:

  • The DFD is also called as bubble chart. It is a simple graphical formalism that can be used to represent a system in terms of the input data to the system, various processing carried out on these data, and the output data is generated by the system
  • The data flow diagram (DFD) is one of the most important modeling tools. It is used to model the system components. These components are the system process, the data used by the process, an external entity that interacts with the system and the information flows in the system.
  • DFD shows how the information moves through the system and how it is modified by a series of transformations. It is a graphical technique that depicts information flow and the transformations that are applied as data moves from input to output.
  • DFD is also known as bubble chart. A DFD may be used to represent a system at any level of abstraction. DFD may be partitioned into levels that represent increasing information flow and functional detail.

NOTATION:

SOURCE OR DESTINATION OF DATA:

External sources or destinations, which may be people or organizations or other entities

DATA SOURCE:

Here the data referenced by a process is stored and retrieved.

PROCESS:

People, procedures or devices that produce data’s in the physical component is not identified.

DATA FLOW:

Data moves in a specific direction from an origin to a destination. The data flow is a “packet” of data.

MODELING RULES:

There are several common modeling rules when creating DFDs:

  1. All processes must have at least one data flow in and one data flow out.
  2. All processes should modify the incoming data, producing new forms of outgoing data.
  3. Each data store must be involved with at least one data flow.
  4. Each external entity must be involved with at least one data flow.
  5. A data flow must be attached to at least one process.


3.1 ARCHITECTURE DIAGRAM

3.2 DATAFLOW DIAGRAM

UML DIAGRAMS:

3.2 USE CASE DIAGRAM:

3.3 CLASS DIAGRAM:

3.4 SEQUENCE DIAGRAM:

3.5 ACTIVITY DIAGRAM:

CHAPTER 4

4.0 IMPLEMENTATION:

The KDD approach can be defined as the nontrivial process of identifying valid, novel, potentially useful, and understandable patterns from KDD process begins with the understanding of the application specific domain and the necessary prior knowledge. After the acquisition of initial data, a series of phases are performed:

1) Selection: This phase determines the information sources that may be useful, and then it transforms the data into a common format.

2) Preprocessing: In this stage, the selected data must be cleaned (noise reduction or modeling) and preprocessed (missing data handling).

3) Transformation: This phase is in charge of performing a reduction and projection of the data to find relevant features that represent the data depending on the purpose of the task.

4) Data mining: This phase basically selects mining algorithms and selection methods which will be used to find patterns in data.

5) Interpretation/Evaluation: Finally, the extracted patterns must be interpreted. This step may also include displaying the patterns and models, or displaying the data taking into account such models.

4.1 ALGORITHM

We propose to develop a complete KDD process, starting by selecting a useful data source containing instances of previous accidents. The data collected will be structured and preprocessed to ease the work to be done in the transformation and data mining phases. The final step will consist on interpreting the results, and assessing their utility for the specific task of estimating the severity of road accidents. The phases from the KDD process will be performed using the open-source Weka collection, which is a set of machine learning algorithms.

Weka is open source software issued under the GNU General Public License which contains tools for data pre-processing, classification, regression, clustering, association rules, and visualization. We will deal with road accidents in two dimensions: (i) damage on the vehicle (indicating the possibility of traffic problems or the need of cranes in the area of the accident), and (ii) passenger injuries. These two dimensions seem to be related, since heavily damaged vehicles are usually associated with low survival possibilities of the occupants.

We   will use the estimations obtained with our system about the damage on the vehicle to help in the prediction of the occupants’ injuries. Finally, our system will benefit from additional knowledge to improve its accuracy, grouping accidents according to their degree of similarity. We can use the criteria used in numerous studies about accidents in which crashes are divided and analyzed separately depending on the main direction of the impact registered due to the collision. The following sections contain the results of the different phases of our KDD proposal.

4.2 MODULES:

USER MODULES:

VEHICULAR NETWORKS (ITS):

OBU AND CU STRUCTURE:

DATA ACQUISITION:

KDD MACHINE LEARNING:

4.3 MODULE DESCRIPTION:

USER MODULES:

VEHICULAR NETWORKS (ITS):

OBU AND CU STRUCTURE:

DATA ACQUISITION:

KDD MACHINE LEARNING:

CHAPTER 8

8.1 CONCLUSION:

The new communication technologies integrated into the automotive sector offer an opportunity for better assistance to people injured in traffic accidents, reducing the response time of emergency services, and increasing the information they have about the incident just before starting the rescue process. To this end, we designed and implemented a prototype for automatic accident notification and assistance based on V2V and V2I communications.

However, the effectiveness of this technology can be improved with the support of intelligent systems which can automate the decision making process associated with an accident. A preliminary assessment of the severity of an accident is needed to adapt resources accordingly. This estimation can be done by using historical data from previous accidents using a Knowledge Discovery in Databases process.

We showed that the vehicle speed is a crucial factor in front crashes, but the type of vehicle involved and the speed of the striking vehicle are more important than speed itself in side and rear-end collisions. The status of the airbag is also very useful in the estimation, since situations where it was not necessary to deploy the airbag rarely produce serious injuries to the passengers.

We developed a prototype that shows how inter-vehicle communications can make accessible the information about the different vehicles involved in an accident. Moreover, the positive results achieved on the real tests indicates that the accident detection and severity estimation algorithms are robust enough to allow a mass deployment of the proposed system.