Minnesota MAYDAY/9-1-1 Field Operational Test (FOT) Data Routing Project Final Report

For the PDF version of this document, please click here.

Prepared for:
USDOT ITS Joint Program Office
Public Safety Program and National Highway Traffic Safety Administration
Emergency Medical Services Division

Submitted by:
Minnesota Department of Transportation

Last Revision:
February 6, 2006

Table Of Contents

1. Executive Summary
2. Introduction

3. Problem Statement, Vision, and Goals
 3.1 Problem Statement
 3.2 Project Vision
 3.3 Project Goals

4. Project Overview
 4.1 Modifications to Existing Systems
   4.1.1 OnStar operator control system modification
   4.1.2 SOAP-XML server
   4.1.3 CARS Ability to Accept OnStar Data
 4.2 New Components
 4.3 How Pre-existing and New Modules Work Together for Data Flow

5. Project Execution
 5.1 Project Boundaries
 5.2 Project Activities
   5.2.1 Regular Project Activities
   5.2.2 Milestone Activities
 
6. Technical Summary
 6.1 Systems Overview
 6.2 Tier 1: Data Routing to CARS SOAP Server
 6.3 Tier 2: Data Routing From SOAP Server to Data Routers, CARS and 3rd parties
 6.4 Combined System

7. Project Findings
 7.1 Acceptance Test Results
  7.1.1 Standalone Test Series
  7.1.2 Integrated Test Series
 7.2 Operational Test Results
  7.2.1 Summary of Events
 7.3 Demonstrated Scalability

8. Ongoing and Future Operations
 8.1 Ongoing Operations

9. Summary and Recap
 9.1 Recommendations and Next Steps

Appendix A: Acceptance Testing Detailed Results
 Inspection Tests
 Standalone Test Series
 Integrated Test Series

1. Executive Summary

The intent of the Minnesota MAYDAY/9-1-1 Field Operational Test (FOT) was to demonstrate a method for reducing the time required to notify the appropriate emergency response provider of a stranded or disabled vehicle by relaying vehicle location and other critical information about the event. This project was performed as an FOT, and was sponsored by USDOT – ITS Joint Program Office, Public Safety Program and National Highway Traffic Safety Administration, Emergency Medical Services Division. The project was operational test, the system was designed and developed for ongoing operations, and remains in full operation at this time. This report describes the data routing portion of a two phased project, where the other phase was the voice routing of emergency calls placed to a telematics service provider into the native 911 routing system. A related report is available on the voice routing portion of this overall comprehensive project.

The primary focus of the data routing portion of the project was to develop a means of routing the necessary data from the OnStar system into the Condition Acquisition and Reporting System (CARS) that is available to authorized DOT, State Patrol and other emergency response providers with Internet access. A secondary focus of the data routing project was to demonstrate the use of data routing mechanisms to relay the information as needed and requested to additional emergency response providers and support systems.

The technical activities in this project developed the data link between OnStar and the Minnesota CARS system, as well as the link to two data routing mechanisms. As a result, there is a live exchange of the OnStar data to Minnesota that continues to operate as part of the annual operations of the CARS system. In addition, two data routing mechanisms were deployed and tested to demonstrate the capability for routing the OnStar data to other regions and systems.

Throughout the timeline of this project, over 150 events involving airbag deployments of actual OnStar subscribers in Minnesota occurred. In each case, the data from OnStar vehicles was delivered to the Minnesota CARS system within one second from the time at which verification occurred. The information about these events was displayed to TMC, State Patrol, and emergency medical dispatchers through the CARS on-screen displays. Additionally, basic information about these events were relayed to Minnesota travelers using the 511 phone system and traveler information web site.

The data routing system was able to demonstrate a parallel push of OnStar event information, with delivery to law enforcement, traffic management, ambulance dispatch, and medical personnel simultaneously. As a result of this parallel push of information, for one specific event, the time required for ambulance dispatch and medical personnel to receive notice of an event was reduced by 9 minutes. Similarly, in several events, traffic management personnel received notification of the OnStar events and were able to begin response activities before receiving radio or cellular phone call notifications of the events.

The live data exchange from OnStar to the Minnesota CARS system for display to DOT, law enforcement, and medical responders around the state continues to operate with an ongoing commitment by both Mn/DOT and OnStar to continue the data exchange. The emergency responders have come to rely upon this information and it is a part of the daily response to events.

2. Introduction

In North America, there are countless new technologies being introduced into vehicles every year. These technologies create opportunities for improvements in driver safety, personal productivity, and affect all arenas of public and private activity. The widespread use of cellular telephones, wireless networking, and other telematics devices has opened up opportunities for new types of integrated systems, and resulted in unprecedented levels of information organization and sharing.

Telematics technology supports data communications between systems and devices. The goal of many in-vehicle telematics devices is to improve safety and security by providing drivers with a link to information services and assistance. The OnStar technology and service provision is one example of these services. OnStar's in-vehicle safety, security, and information services use Global Positioning System (GPS) satellite and cellular technology to link the vehicle and driver to the OnStar Center. At the OnStar Center, advisors offer real-time, personalized help 24 hours a day, 365 days a year.

When an OnStar-equipped vehicle is involved in a crash or accident, the car transmits event-related data to the OnStar call center. Prior to the current project, the automated, electronic data reporting pathway stops at the OnStar call center and must be relayed to local emergency response agencies verbally. This lack of an automatic, electronic connection between OnStar and emergency response agencies, did not allow any vehicle data to reach the PSAP electronically. The data routing portion of the MAYDAY/9-1-1 FOT has developed an automated data exchange between OnStar and the Internet based Condition Acquisition and Reporting System (CARS)[1] in Minnesota. This link, and the open availability of the CARS system to any emergency responder with Internet access, provides a mechanism to deliver this data to the appropriate responder in a timely manner. Finally, this project developed and tested two alternative methods to deliver vehicle crash data. These methods utilized a 'message broker' concept where OnStar data could be delivered to recipients based upon the location of the event. All data exchanges in this project utilized existing or draft standards to ensure future applications can easily integrate and exchange information with the systems tested during this project.

The efforts described in this report describe the data routing portion of an overall MAYDAY/9-1-1 Field Operational Test (FOT). The focus of the overall FOT was to establish routing mechanisms to deliver the voice phone call from an Onstar vehicle to the emergency response call centers using the native 911 system, as well as to establish data routing mechanisms to deliver the data concerning the event to the appropriate emergency responders. Collectively, this project was sponsored by the USDOT ITS Joint Program Office - Public Safety Program and National Highway Traffic Safety Administration - Emergency Medical Services Division, and the Minnesota Department of Transportation (Mn/DOT). This report provides a detailed account of the data routing portion of the project, including details of the project process, the activities, and the results of the data routing project.

3. Problem Statement, Vision, and Goals

This chapter provides a general overview of the project, including a description of the problem, the scope of work, and the project goals.

3.1 Problem Statement

For over 10 years, the transportation industry has recognized the problem of drivers and passengers of stranded or disabled vehicles needing a mechanism to alert emergency response providers of their location and need for assistance, either following a crash or during other types of emergencies. In addition to recognizing the need, transportation professionals have recognized the potential for advanced technologies such as Intelligent Transportation Systems (ITS) to address this need. The OnStar system is now operational in over 2 million vehicles nationwide, and utilizes GPS location devices to locate the vehicle, and cellular communications to transmit the vehicle location and other key information to the OnStar call center. When an event occurs with an OnStar-equipped vehicle triggering the airbag, or a driver pushes the emergency button, a call is initiated to an OnStar advisor at the national call center. The OnStar advisor speaks with the vehicle occupants, and is trained to determine if the event is an emergency worthy of establishing a three way call with the PSAP local to the vehicle event. If the operator determines that the PSAP should be contacted, a three way phone conversation is established. The OnStar advisor and as appropriate the vehicle occupant then relay the details of the event. Since there is not an automatic electronic link between OnStar and the local PSAP, establishing a manual connection and verbally relating crash information to the PSAP may take a considerable amount of time.

When a severe crash occurs, the first sixty minutes after a traumatic injury are critical, since the chances of survival are dramatically improved if medical attention is given within the first hour. Shaving minutes or more off emergency response times can potentially reduce death and permanent injury on the roads.

Therefore, the problem that this project was created to address is to reduce the time and manual steps involved in sharing the vehicle, location, and crash information about the event with the appropriate PSAP dispatcher, therefore reducing the time required to deliver the needed information to the appropriate response personnel.

3.2 Project Vision

The vision of this project is that Minnesota travelers in vehicles equipped with OnStar will benefit by having vehicle location and other key data routed electronically from the OnStar call center to the appropriate emergency response provider and displayed using an on-screen map. Simultaneously, the appropriate related data will be available to other stakeholders, such as trauma centers, ambulance services, and traffic operations centers.

3.3 Project Goals

The overall goals of this project were to develop a link between OnStar and the Minnesota CARS system and provide a trial and demonstration of data routing systems that can deliver the data to other emergency response agencies and systems. The routing of data from OnStar to the Minnesota CARS system and the data routers addresses three of the four objectives of the overall Mayday 9-1-1 Field Operational Test Project, with the additional goal being related to voice routing and integration with the existing 9-1-1 system. This section defines the objectives of the data routing portion of the project..

Objective #1: Implement and demonstrate a data routing mechanism that will allow OnStar and other Telematic Service Providers (TSPs) to transfer the data to one central location for all emergency calls received statewide.

A Simple Object Application Protocol (SOAP) server has been developed within this project that now functions as the central location for all telematics data. The SOAP server has demonstrated the ability to receive data from the OnStar call center and to interface with two independent data routing systems and the CARS system thereby establishing a distributed network that is capable of widespread distribution of telematics information to a variety of end users. The data routing systems interacting with the SOAP server are able to selectively route crash data based on an identifying data element. The SOAP server, by current design, has limited data routing capabilities (currently routing data based upon the state that the event occurred in); more robust routing functionality was demonstrated by the independent data routing systems. However, the SOAP server developed within this project is capable of being modified to route data based upon additional qualifiers in the future.

Objective #2: To demonstrate the capability to interface the data routing mechanism with the Minnesota CARS system to allow the display of Mayday events to dispatchers statewide in conjunction with additional conditions such as weather, road construction and traffic.

This objective is the primary focus of this document. To accomplish this objective, the CARS system has been modified to receive data from OnStar using the SOAP server and to automatically display crash information to a variety of users.

Objective #3: To demonstrate the project successes and expandability of the approach in order to encourage additional states and TSPs to expand the system.

The success of this objective has resulted in additional states requesting the direct feed of OnStar data, as well as OnStar continuing to work with the member states of the CARS consortium to advance additional ideas and concepts. One state ( Alabama) has been able to receive OnStar data building on the capability developed and tested during this project. This independently funded Alabama project distributes OnStar data via a secure web display and provides an integration of this data with a regional trauma management system.

4. Project Overview

The overall concept of the Minnesota Statewide Mayday project is to bring the crash information (data) that is received by the OnStar Call Center into the statewide traveler information and information exchange system, CARS. The concept is that data generated by the emergency OnStar system will be routed through the OnStar call center, to a secure public SOAP server which will be capable of distributing the data and automatically pushing the data to the CARS system and other data routing systems.

To develop an effective system, it was necessary to integrate existing systems and new data routing components into a new framework. These new components were developed to provide a simplified method for reporting OnStar events to CARS users and facilitate the sharing of information with third party vendors and data recipients.

4.1 Modifications to Existing Systems

The data routing portion of this project was designed and developed with the intent of ongoing operations beyond the end of the FOT. Therefore, emphasis was on modifying or expanding existing systems, rather than creating new systems that would require specific operations budgets for ongoing operations. The needed modifications to the CARS system was the development of a SOAP XML server that could accept data pushes from OnStar and potentially from other telematics providers. This section outlines the primary modifications to existing systems.

Figure 1. Diagram of the data routing processes

4.1.1 OnStar Operator Control System Modification

OnStar implemented all internal modifications to their operator control system to perform the automated push of data to the SOAP-XML server when appropriate. The modifications include the capability to automatically generate a data message that contains pertinent vehicle and crash information, and to route this data to the SOAP-XML server. In addition, the OnStar system attaches an indication code of the state that the vehicle is currently located in, which is used by the SOAP-XML server for routing to the appropriate CARS server and/or data router. All modifications to the OnStar call center within this project were performed by OnStar as a partnership contribution. No project funds were utilized by OnStar for modifications made to their system.

4.1.2 SOAP-XML Server

A second key modification to an existing system was the addition of a SOAP-XML server to the CARS system. This server is able to forward event messages received from the OnStar Call Center to the appropriate CARS State Hub. In addition to routing solely to the CARS State Hub, as part of this project, the SOAP-XML server also routed data to two additional data routing mechanisms. One data routing mechanism delivered information to recipients in Minnesota, and the other demonstrated the ability to route data to the state of Alabama (for events occurring in Alabama).

4.1.3 CARS Ability to Accept OnStar Data

Each CARS state hub has been upgraded to be able to receive OnStar events pushed from the SOAP-XML server. The XMLmessage is received by the State Hub which transforms the latitude and longitude geolocations reported by OnStar into route designators (e.g., "I-94") and mile markers/intersections. This ingestion creates an event in the CARS system that is immediately visible to any CARS user with the map interface open on the screen. One key modification to the CARS system is the ability for key Mayday users (i.e. those identified as needing extra information to assist in responding to emergency situations) to access additional information from the CARS system. This additional information includes details such as the instantaneous change in velocity upon impact (delta V), indication of whether an rollover occurred, and the principal direction of force.

In addition to disseminating information about OnStar events to emergency responders, the events entered into the CARS system also serve as events for dissemination to the traveling public over the 511 phone system and public web page (http://511mn.org). A very limited description of the event is disseminated through the 511 phone and web system, typically involving the phrase "Accident" and the location.

4.2 New Components

In order to facilitate the dissemination of information to secondary or tertiary responders, the second primary objective of this project was to demonstrate interoperability with other data routing mechanisms. The overall concept of adding these components to the project was to demonstrate and assess the viability of a data routing mechanism to deliver the data to secondary responders in Minnesota, or primary responders not served by the CARS system. Examples of the secondary responders include EMS response agencies, Traffic Management Centers (TMCs), tow truck companies, and other interested vendors who support emergency response to motor vehicle crashes. To meet these goals, two commercial data routing mechanisms were developed. Both data routers were designed to work with the exact standards used by OnStar and the CARS system (i.e. the ComCARE Recommended Vehicular Emergency Incident Data Exchange Schema (also called the Vehicle Emergency Data Set or VEDS).

4.3 How Pre-existing and New Modules Work Together for Data Flow

The modified systems (SOAP-XML server and CARS) and new systems (Data Routers) have been designed to work together in a coordinated manner to deliver data to the appropriate recipient. The SOAP-XML server provides the function of routing data to the appropriate CARS State Hub, or to another SOAP-XML server (i.e., Data Router) capable of receiving the standardized data exchange. However, the SOAP-XML server was not developed to support advanced data routing capabilities based upon rules that might be used to only alert certain recipients (i.e., only roll over crashes., or crashes on a certain roadway); this functionality could be easily developed. Instead, this 'message broker' role was the role of the data routing mechanisms. Figure 2 below illustrates the data routing approach of combining the CARS SOAP Server and the data routing mechanisms.

Figure 2. Mayday system overview including old and new components

5. Project Execution

5.1 Project Boundaries

While the Mayday 9-1-1 Field Project was conducted as a Field Operational Test of technologies and approaches, the project partners all agreed that the goal was to not test a system for a limited time and cease operations. Rather, the goal was to develop a sustainable system that would benefit drivers in Minnesota (and other states) for years to come. This Final Report is intended to summarize the project activities and boundaries. Listed below is a summary of the project details:

• The test area for the project was the entire state of Minnesota;
• The test participants included any CARS user in the state of Minnesota. Primary emphasis was placed on Minnesota State Patrol dispatchers, the Regional Traffic Management Center operators, and the Mayo Clinic dispatchers, ;
• The operational test involved OnStar customers who were involved in actual emergencies. Simulated events were used for acceptance testing; however, once the operational test began actual OnStar events were used;
• The operational test period was from October 15, 2004 to September 30, 2005.

5.2 Project Activities

The Minnesota MAYDAY/9-1-1 FOT involved a variety of traditional and non traditional partners. The Mn/DOT Project Manager was responsible for coordinating all efforts and for overall project management. This section defines the regular activities as well as the milestone deliverables or activities that collectively comprised the entire project.

5.2.1 Regular Project Activities

Minnesota Mayday Core Group

At the onset of the project, Mn/DOT reconvened the Mayday Core Group that existed for Minnesota's early Mayday project[2]. Members of the core group included Mn/DOT, Minnesota State Patrol, the Mayo Clinic, OnStar and private sector contractors. Unlike the earlier Mayday project, the Core Group did not require regular meetings for this project, as the vision, goals and objectives were established prior to the beginning of the project. However, the Core Group met early on during the project to provide guidance on key decisions that were reached during the preliminary system design.

OnStar Data Routing Design Meetings

Coordination meetings with Minnesota Voice Routing Mayday Project

At regular times, key team members from this project met with members performing the voice routing portion of the Minnesota MAYDAY/911 FOT. The intent of these meetings was to coordinate at a high level and to ensure that lessons learned transferred from one project to the other.

5.2.2 Milestone Activities

The milestones for this project include the following:

• Project kickoff meeting: A project kickoff meeting involving partners from both the data and voice components of the project as well as representatives from the USDOT ITS Joint Program Office - Public Safety Program and National Highway Traffic Safety Administration - Emergency Medical Services Division. Activities at the kickoff meeting focused on sharing the vision, goals and objectives and on discussing the detailed tasks to be performed. Due to timing limitations, the independent evaluation team was not able to attend this meeting.

• Submittal and approval of Concept of Operation / Functional Design: The first primary deliverable was the Concept of Operations / Functional Requirements Report, that was intended to present the functional design of the data routing portion of the project.

• Early system testing of software: Following months of regular conference calls among team members, OnStar sent the first message to the SOAP server and into CARS on May 19, 2004

• Acceptance testing: The data routing components from OnStar, the CARS system, and the two data routing mechanisms were tested as part of a two day acceptance test that was performed in Bloomington Minnesota. This acceptance testing focused on demonstating the routing capabilities of all systems, and testing multiple routing scenarios to ensure that the standardized SOAP-XML data exchanges functioned properly.

• Operational Test Onset: Following the acceptance testing, the operational test was considered officially underway. During this period, the OnStar center recorded the number and types of events sent to the CARS system as well as the average time for data transfers.

6. Technical Summary

6.1 System Overview

The data routing of OnStar event data can be related to three tiers of data flow, as follows:

• The initial tier of data flow is from the OnStar Call Center to the SOAP XMLserver;

• The second tier of data flow is from the SOAP XML server to the appropriate data routing mechanism or CARS State Hub. For this project, two additional data routing mechanisms were developed, one by General Dynamics (GD Router), and one by Coherent Systems (Coherent Router); and

• The third tier of data flow is from the data routing mechanisms to the appropriate end user recipient

6.2 Tier 1: Data Routing to CARS SOAP Server

The Tier 1 data routing diagram illustrates the flow of data from the OnStar call center to the SOAP server. The SOAP server then routes the event information to the appropriate state CARS system and to the additional data routers as appropriate.

Figure 3. Tier 1 Data Flow

6.3 Tier 2: Data Routing From SOAP Server to Data Routers, CARS, and 3rd parties

The Tier 2 data routing was from the SOAP server to the Data Routing Mechanisms (DRMs) or the CARS State Hub, as shown in Figure 4 in order to demonstrate the use of common ITS standards and open SOAP-XML exchanges. The premise of this project is to encourage open competition rather than single source systems, and the conclusion of this project is that any number of data routing mechanisms can exist to receive and re-circulate emergency notification data.

Figure 4. Tier 2 and Tier 3 Data Flow

Finally, The Tier 3 data routing was performed by the data routing mechanisms to route the OnStar data to third party recipients using a variety of mechanisms. End users received data through an email push and pager from the data routing mechanism. The data routers also provided the information to additional applications which in turn feed the information into another system for processing.

6.4 Combined System

The complete system, shown in Figure 5, describes how the entire system works together to get OnStar information to CARS and non-CARS users. Each step in the process is described below.

Step 1: Transfer of data from OnStar call center to CARS SOAP server

The initial step is the transfer of vehicle and event data from the OnStar call center (once an event has been verified by an operator) to the SOAP server. The format for this data exchange is the ComCARE Recommended Vehicular Emergency Incident Data Exchange Schema (also called the Vehicle Emergency Data Set or VEDS). The data is exchanged using a Web Service Definition Language (WSDL) that was defined by OnStar for use by of any telematics agencies exchanging data.

Step 2: Data routing to CARS State Hub or Data Routing Mechanism

Data received by the SOAP server is passed to the Minnesota CARS system for ingestion as a situation or to the data routing mechanisms for routing to non-CARS users. The SOAP server has the capability to route to a particular state based on the data elements received from OnStar. Agreements permitting, additional CARS states will receive the information for their particular jurisdiction based on the gross routing capabilities of the SOAP server. Currently, additional states including Iowa and Alaska are receiving the OnStar data.

When the data reaches the data routers the process is considered complete for the purposes of this project. Extensive testing was conducted to ensure that the systems were able to exchange data. This exercise was not conducted once the operational test began.

Figure 5. Breakdown of Steps

Step 3: Insert Data as a CARS Situation

In this step, the data passed to the local CARS installs will be inserted as a CARS situation into the appropriate CARS system. Like other events in CARS, the situations will contain:

• Location. Typically, the information will be received from OnStar with the latitude and longitude of the location. Typical entry in CARS is to describe the route or roadway that the event occurs on, as well as the intersection (or mile marker).

• Key phrase. The key phrase contains the best description of the event. For example "Accident".

• Start / End Time or duration. Given the unpredictability of clearing accidents, a default duration has been agreed with project partners as 1 hour.

• Additional Information. Additional information concerning the crash facts, such as delta velocity, number of passengers etc. may also be inserted. This will be in accordance with what data OnStar is able to send. Data forwarded to systems that provide data to the general public are limited to basic information about the location and general nature of the event.

Step 4: Display to CARS Users

Step 4 will have the OnStar vehicle accidents viewed as situations within CARS. Within this step, all CARS users will have access to the basic information. This will include Mn/DOT, Minnesota State Patrol, and Mayo Clinic dispatchers.

Step 5: Removal / Expiration from CARS

CARS situations generated by data received from OnStar calls is assigned a predefined duration. Upon reaching the duration, the situations are removed. The concept is that one or more users will edit the situation to add more time in the event that the situation lasts longer than the duration was defined for. Similarly, in the event that the situation is cleared prior to the predefined duration, CARS users may simply click and delete the situation.

7. Project Findings

This chapter describes the project results. Section 7.1 describes the results of the acceptance testing, conducted over the course of two days. Section 7.2 describes the operational test results, and overall project findings.

7.1 Acceptance Test Results

This section presents an overview of tests, analyses, and inspections that were conducted to verify that the data routing mechanisms meet system requirements. These tests are organized by test approach (i.e. analyses and demonstration tests).

Multiple test approaches were used to show that the existing OnStar and CARS systems could communicate as planned, and that the data routing mechanisms could communicate using the same standards and protocols used by OnStar and the SOAP XML Server.

Acceptance testing was performed at contractors facilities as well as at a joint two day acceptance test in Bloomington, Minnesota. Prior to acceptance testing, the basic contractual requirements (primarily the open non-proprietary implementation and public ownership requirements) of the data routing mechanisms was inspected to ensure that no licenses or requirements would prevent expansion. Following this inspection, two sets of tests were conducted: standalone demonstration tests, and integrated demonstration tests, defined as follows:

• The standalone tests established the compliance of each individual router to functional, data integrity, and performance requirements in an isolated environment.

• The integrated tests proved that the individual data routing mechanisms, the CARS system, the SOAP XML Server and OnStar were able to function together within the project specifications.

During both the standalone and integrated tests, several configurations were tested to verify system requirements were meet. Table 1 identifies all test configurations used; Table 2 identifies the acceptance tests that were performed. Figure 6 show a schematic of the standalone test configurations; Figure 7 identifies the integrated test configurations that were used. Detailed information about the test configurations, project requirement, acceptance testing, and expected results can be found in Appendix A.

Figure 6. Standalone Test Configurations

Figure 7. Integrated Test Configurations

7.1.1 Standalone Test Series

This series of tests demonstrated that each individual router (General Dynamics' I3B and Coherent Solution's router) meets the functional, data integrity and performance requirements defined in Appendix A. Two test data drivers and two test data receivers were required, and supplied by the manufacturers of the routers under test.

• The test data driver has the capability to send test messages at a specific interval for a specific number of iterations. The test data driver records the time that each message was sent.

• The test data receiver can receive and record each message received. The test data receiver can also record the time that each message was received.

Tests were performed using the manufacturer's equipment for the test data driver and receiver. The individual manufacturer would supply data messages required by the acceptance tests. These data messages were validated to comply with the Comcare XML schema.

The following standalone tests verify that a portion of data routing requirements were met:

• T-1 - Multiple destinations based on message source location. This test verified that the data routing mechanism can selectively route conforming messages based on the message source location data contained in the crash/emergency data message.

• T-2 - Multiple sources. This test verifies that the data routing mechanism can receive conforming messages from multiple sources .

• T-3 - Data Integrity. This test verifies that the data routing mechanism can exchange acknowledgements that messages were correctly received and that the integrity of the data in the messages is maintained.

• T-4 - Throughput performance. This test verifies that the data routing mechanism can handle at least 100 crash/emergency data messages per day.

• T-5 - Latency performance This test verifies that the data routing mechanism can transmit crash/emergency data messages to recipients within 10 seconds from the time the data message was received.

• T-6 - Message storage and retrieval. This test verifies that the data routing mechanism stores received crash/emergency data messages and allows retrieval of these stored messages. This test verifies the ability to record the time data messages are received and forwarded.

7.1.2 Integrated Test Series

This series of tests demonstrated that each individual router (i.e. the routers developed by General Dynamics and Coherent) met the interface requirements of the Functional Specifications Report.

These tests verified the interoperability between the data routing mechanism. Additionally, the tests verified the ability of each data routing mechanism to receive messages from OnStar via the SOAP XML Server, and to forward messages to CARS.

The following integrated tests verified that the remaining data routing requirements are met:

• T-7 - End-to-end call routing: State Server (or test driver) - Data routing mechanism - CARS. This test verified that the data routing mechanism can receive OnStar test crash/emergency data messages via the SOAP XML Server. The messages could then be forwarded on to CARS in accordance with the defined routing logic and location data in the test data messages using the protocols defined in the Interface Specification .

• T-8 - Inter-data routing mechanism test: State Server (or test driver) - Data routing mechanism 1 - Data routing mechanism 2 - CARS. This test verified that the data routing mechanisms could send and receive OnStar test crash/emergency data messages to and from each other using the protocols of the Interface Specification .

7.2 Operational Test Results

The connection between the OnStar call center, the SOAP XML Server, and the Minnesota CARS system was tested and activated on May 19, 2004. Since May 19, 2004 OnStar events were ingested into the Minnesota CARS system and displayed to authorized users.

Following the early October acceptance testing, the Operational Test portion of the project commenced (with full functionality) on October 15, 2004 and ran until the project completion on September 1, 2005. The operational test results represent the total number of actual live events in Minnesota, and the ability for the system to transfer the data appropriately.

7.2.1 Summary of Events

Three types of OnStar events are transferred as part of this project, summarized as follows:

• Advanced Automated Collision Notification (AACN): These represent those events where an advance collision notification system is on-board and has been activated to trigger the notification to the OnStar advisor. For these events, OnStar reports additional crash information such as delta velocity, principal direction of forces, whether a roll over occurred, in addition to the location and vehicle information.

• Automated Collision Notification (ACN): These represent those events where an airbag has been deployed in a vehicle equipped with an automated collision notification system, but not an AACN system. These event calls will include an indication that an air bag has been deployed, and will include vehicle description and location information.

• Emergency Key Press (also referred to as SOS): These represent those events where OnStar users press the emergency key button in the vehicle. Please note that for the data to be transferred to this project, the OnStar advisor had to receive the call and confirm that it was an emergency with enough certainty, that they establish a three way call with the local PSAP.

Table 3 illustrates the number of Minnesota oriented calls received by OnStar call centers and routed to the Minnesota CARS system during the operational test phase. In summary, the majority of calls were routed within 1 second and transmitted without error. Table 3 also indicates that during two weeks of April 2005, failures were reported when data transfers were attempted. During this time period, all systems were operating, however the security key required to ensure a secured connection between all routers was being renewed, and therefore caused a pause in the Operational Test, until new security keys could be obtained and synchronized.

7.3 Demonstrated Scalability

The project architecture was designed to realize scaleable and expandable benefits from other parties that expressed interest in receiving crash data. To that end two demonstrations occurred related to scaling this project outside Minnesota. It should be noted that no project funds were used to proliferate the expansion beyond the original scope, however technologies tested and developed in conjunction with this effort were utilized in other jurisdictions. The two demonstrations are as follows:

• In states operating the CARS system, the data can be pushed to the appropriate CARS State Hub and ingested and displayed the same as in Minnesota. Two key states that participated in this data routing were Iowa and Alaska, who received the OnStar event for the entire duration of the project.

• In states not operating the CARS system but having a SOAP XML server capable of receiving events pushed in compliance with the ComCare standard, the data can be pushed and received by these systems for display within their local display. In this case, data was routed to a data routing mechanism that was located in Alabama, and OnStar events were integrated with an emergency medical system.

These Alabama emergency response agencies received OnStar's ACN data during the FOT via the General Dynamics' data routing mechanism. The Alabama emergency response agencies include the Birmingham Regional EMS System (BREMSS) and emergency medical and public safety users throughout the state. BREMSS is a regional trauma control and emergency medical response coordination center that coordinates emergency medical responses for trauma cases across a six county region. The Alabama integration, shown in Figure 8, is being implemented and operated under a separate contract. The delivery of OnStar data to Alabama PSAPs is a temporary solution (therefore shown as a dashed line on Figure 11) to serve until an integration with 9-1-1 is available.

Figure 8. Integration with the Alabama Infrastructure (the initial external integration)

8. Ongoing and Future Operations

8.1 Ongoing Operations

The first piece of the CARS-Mayday integration, linking OnStar to CARS, was designed to be an ongoing project. Each time an OnStar event occurs in Minnesota, it is distributed to and displayed on CARS. At the project onset, OnStar was sending all events to CARS (i.e., air bag deployments and emergency key presses). Recently, OnStar has stopped sending events that were initiated by the driver pushing the OnStar emergency button, as part of an effort to reassess the value of emergency button notification events to emergency responders. The CARS operation has ongoing funding in Minnesota and other CARS states, therefore there will be no disturbance in service and this information delivery will continue beyond the operational test.

The data routing mechanisms developed for this project were designed to provide only a trial demonstration to third party users. This portion of the project was not designed to have continuous funding, but rather it was supposed to show vendors, the industry, and interested parties that the system could deliver crash information in a timely manner. One data routing mechanism vendor has established a relationship with emergency response agencies in Alabama and is expected to continue operations into the foreseeable future. The other data routing mechanism has not finalized any long term commitments for continued operations.

9. Summary and Recap

In summary, the intent of the data routing portion of the Minnesota MAYDAY/911 FOT is to route critical data concerning emergency events in OnStar equipped vehicles (and other telematics service providers) to the emergency response dispatchers who may be responding to such emergencies. At a high level, the following bullets present the general concepts described within this report:

• Once the event is confirmed to be an emergency, OnStar will transmit the critical data describing the event to an initial router using the XML Schema originally developed by ComCARE (and currently being considered as a NENA standard) and the SOAP Web Services / Definition Language WS/DL developed by OnStar.

• The SOAP XML Server that receives the OnStar data will provide at a minimum a limited routing capability to route the data to the CARS system as well as to other more sophisticated routing systems. As required by OnStar, the technology and approach that plays the role of this initial routing recipient must be a system with an ongoing committed budget for operations (in order to ensure the router does not discontinue after the conclusion of the project).

• The SOAP XML Server will route the OnStar data into the appropriate states' CARS system as well as to any additional routing systems with agreements in place.

• The Minnesota CARS system will display the event information to CARS operators around the state (currently State Patrol, DOT, and Mayo Clinic dispatchers with possible expansion to additional PSAPs).

• The more advanced routers have the potential to intelligently route the data to additional recipients for insert into some form of local display system (such as a local CAD system).

The overall intent of this field operational test has been to demonstrate the success of such a system and to establish an ongoing operational system that does not cease to exist at the termination of the project.

9.1 Recommendations and Next Steps

Based upon the experiences and lessons learned within this project, the project team members present the following recommendations for future Mayday related efforts:

• The result of this project is a SOAP XML Server that is operated by the CARS Pooled fund. Two additional states have already expressed interest in receiving OnStar events from the CARS router. It is recommended that a decision be made at the national level in regards to whether the SOAP XML Server will serve as a national router or whether another router, hosted by an additional party, should play this role.

• This project recommends an ongoing national effort to promote consistency and coordination among telematics service providers (OnStar and other TSPs) and states interested in receiving the information. As a result of this project, every CARS member state (MN, IA, KY, WA, NM, ID, LA, NY, FL, RI, ME, NH, VT, WY), as well as Alabama has the ability to immediately receive OnStar data (and any other TSP data that conforms to the ComCare standard and sends data to the SOAP XML server. Therefore, this project has taken great strides towards achieving a national model for Mayday event delivery, and the project participants encourage the efforts to continue in a coordinated manner.

Appendix A: Acceptance Testing Detailed Results

Inspection Tests

 I-1 

Standalone Test Series

Integrated Test Series

[1] CARS is a statewide condition reporting system developed by Minnesota as part of an FHWA Pooled Fund Program. CARS supports manual entry of events through the Internet based user interface, as well as automatically ingested events from outside systems such as traffic management centers, and traffic detection devices. In this project, Onstar data is automatically fed in to the CARS system and displayed to users on the on-screen CARS maps.

[2] The Minnesota DOT funded and performed a field operational test of a manual and automatic emergency notification "Mayday" system between the years of 1994 to 2000. This project (Mayday Plus) demonstrated the feasibility of Mayday devices relaying information to the Minnesota State Patrol and medical responders in Southeast Minnesota.

To download Acrobat Reader 7.0, please click here.