4.1 Overview

The discussion in Sections 3.2 and 3.3 outlines the approach used to put together the three building blocks of the FOT: the defined research objectives, the identified threats and vulnerabilities, and the applicable technologies. This section provides additional detail on that process and shows how the proposed scenarios were further defined and implemented.

4.2 Threat and Vulnerability Analysis

The identification of the threats and vulnerabilities of motor carrier hazmat transportation was presented in Section 2.4. This section describes the approach used to analyze that information, including the development of estimates for the potential damages that would result from terrorist use of hazmat in an attack.

4.2.1 Consequence Analysis

A typical security-based vulnerability analysis involves development of exposure values based on specific weapons and tactics. The analysis conducted for the FOT assumed worst-case outcomes for materials, defined reference components with specific vulnerabilities that can be exploited, and constructed attack profiles that can be used as the basis for defining test scenarios.

Further adaptation was necessary to address targets, which are ordinarily the focus of the analysis (such as critical facilities, sporting events, or monuments). To address the general use of hazmat as a weapon, it was necessary to conceptualize an ideal target for each material for each defined attack profile, much as a terrorist would. These idealized targets are not described in this report, as the information would provide a detailed blueprint for target identification, evaluation, and exploitation.

For the intentional release-based attack profiles, two sets of worst-case, material-specific consequence estimates were developed, one for bulk/truckload and one for LTL, primarily based on the different material quantities associated with each of these two operational types. These estimates are shown in Tables E-3 and E-4 in Appendix E. It is assumed that the release of the material being transported will result in worst-case consequences, which are not dependent on which specific tactic is used. The only exception to this is for interception, in which the terrorist cannot precisely place the hazmat prior to release, detonation, or ignition; therefore, consequences for these attacks would typically be lower than for theft or legal exploitation. Consequences estimates include deaths, injuries, and property damage and were developed from accident scenarios and expert judgment. They are designed to be order-of-magnitude estimates and to be relative rather than absolute.

For the unintentional releases, the results of the FMCSA risk study [3] were applied to an abbreviated list of the threat-based material classifications to allow comparisons. These consequences were expressed on an expected annual basis rather than on a single-incident, worst-case basis to reflect the nature of the risk assessment used to determine them. The consequences for unintentional releases also include other costs such as delay and evacuation costs. Table E-5 in Appendix E lists these costs for unintentional releases.

The consequence values for both intentional and unintentional releases include a cost-equivalent for fatalities and injuries of $3,000,000 and $215,000, respectively. These values were selected based on previous U.S. DOT hazmat impact studies. Rankings are sensitive to the total economic impact value of which these are a component in the calculations. These costs represent those that are recognized by the U.S. DOT for the purpose of analytical studies such as this one. A series of tables is presented in the full Task 1 report [2] with estimated consequences resulting from each combination of attack profiles (e.g., theft involving bulk/truckload operations) and each of the 18 threat-based material categories.

4.2.2 Results

The final step in the assessment process is to use the consequence estimates to develop a ranking of threat and material categories. In order to rank the various threat-based attack profiles against each other, two different sets of weights were applied to the consequence estimates. These weights were designed to reflect the attractiveness to a terrorist of (a) a specific attack profile relative to others and (b) a specific material for a specific attack profile. The two sets of weights are shown in Tables E-6 and E-7 in Appendix E. These weights take into account two sets of criteria: (1) the FBI criteria, which are focused on the attractiveness of a target and include the potential for mass casualties, significant economic damage, extensive psychological trauma, and high symbolic value, and (2) TSSI-developed criteria, which are focused on the attractiveness of the set of operations that a terrorist would need to employ to mount a successful attack. The ranking, shown in Table E-8 in Appendix E, provides an understanding of how the different attack profiles relate to each other and makes it possible to prioritize efforts to address the specific vulnerabilities that would allow terrorists to effectively carry them out.

In addition to ranking the attack profiles themselves, it is possible to rank the threat-based material categories across all attack profiles based on their estimated consequences and weightings. The overall threat-based material category ranking, shown in Table E-9 in Appendix E, could be used to apply specific countermeasures to the top-ranked categories.

These rankings (and the specific vulnerabilities that were identified for each reference component) were provided as input to Task 2, the Concept of Operations. They were an important consideration in defining operational scenarios and associated countermeasures that were selected for testing during the field operational test.

To use past history as a barometer or forecaster of future events, it is necessary to have a sufficiently large number of historical events upon which to base such a prediction. Without a sufficiently large historical record of terrorist events exploiting hazmat, it is difficult to predict with certainty the likelihood of any specific type of incident. It is instructive, however, to compare the expected annual consequences of unintentional releases to the relatively large theoretical consequences of just one terrorist incident.

The FOT, and the companion cost-benefit analysis, address security, safety, and efficiency within the same context. It is likely that some protective measures applied to security vulnerabilities will provide benefits in safety and efficiency and these additional benefits will facilitate the adoption of these protective measures by industry.

The threat and vulnerability assessment framed the safety and security risks being addressed by the FOT and was the basis for developing the Concept of Operations (Task 2). In addition, the assessment categorized the threats and serves as a benchmark for the prioritization of potential countermeasures.

4.3 Scenario Development

As discussed in Section 3.2, the threat and accident-related profiles were compared with the four proposed scenarios to ensure that each of the profiles corresponded to at least one scenario. This was found to be the case and no adjustments to the scenarios were necessary. Including four scenarios in the FOT allowed the application of technology to a wider range of practical situations. The technology applied to each scenario to address the identified vulnerabilities could be tailored to the unique operational characteristics of each.

4.4 Deployment - Technologies and Operational Considerations

The Battelle Team included private sector technology providers that could offer products and/or services that would test one or more of the specified research objectives. Table 10 highlights the array of COTS technology brought to this test by these private sector partners.

4.4.1 FOT Design Criteria

The discussion below presents a high-level summary of the design criteria and requirements addressed in the development of the FOT. A more detailed, in-depth discussion of the overall FOT design can be found in the two Task 4 System Requirements and Design (SRD) documents [4,5].

The design criteria and rationale for how the Battelle Team approached addressing the requirements spelled out in the statement of work was to insure first that all applicable research objectives were addressed. The focus then turned to applying this technology to as broad a spectrum of hazardous materials as possible within the constraints of the program resources.

In selecting the technologies to test, it was important that the technologies be as close to COTS as possible. While it was not an absolute requirement that all technologies be commercially available at the time of the FOT, it was important that the technologies be more than just a concept or early beta-test candidate.

4.4.2 Technology Components

The discussion below presents a high-level description of the functionality of each technology component included in the FOT. A more detailed description of the technologies can be found in the two Task 2 Concept of Operations reports [6, 7] and the SRD.

Communication

Qualcomm provided the major technologies used as the backbone communication systems. These included satellite and terrestrial communications with global positioning system (GPS) and tracking capabilities, and digital mobile phone technologies without GPS. These are clearly "off-the-shelf" systems that are used by thousands of fleets throughout the world. In North America, more than 250,000 trucks use Qualcomm systems. Other major communication (integrated) systems would likely add another 100,000 vehicles to this grouping. When cell phones and two-way radios are included, nearly 100 percent of all 5-axle tractor trailer vehicles utilize wireless communications.

Wireless Satellite or Terrestrial Communications (w/GPS) and Tracking

Trucks received wireless tracking and communications systems with an integrated Global Positioning System (GPS) working in conjunction with the dispatch systems that provided for load/cargo positions and status. The system (Figure 8) also included a Driver Interface Unit for two-way text communications. Positions were automatically displayed for the carrier's dispatcher at a regular frequency determined by the carrier.

Figure 8. Wireless Satellite

These positions were viewed through an application that enabled the carrier's dispatcher to view the location of the vehicle on a map. Position information including the latitude, longitude, and time were also provided. The application enabled the carrier's dispatcher to track the vehicle in near real-time and also view a history of the vehicle's location at a particular time during the route.

FMCSA's 1996 ITS/CVO Cost-Benefit Study showed that wireless vehicle tracking was one of the fastest growing technologies in the trucking industry. It was also listed as having one of the highest return on investment for carriers that invested in asset tracking and communications systems.

Digital Phone (without GPS)

This technology provided integrated work order assignment and status messaging between a carrier's dispatcher and a driver using a low-cost digital cellular handset (Figure 9) with specialized operating software. Store-and-forward guaranteed messaging ensured message delivery upon returning to digital cellular coverage areas.

Along with messaging, ancillary services such as mapping and directions were also available.

Figure 9. Digital Phone

According to one American Trucking Associations' study, cell phones are now the most frequently used communication system in trucking. One issue that must be considered is the safety impact of using cell phones. At least one HMFOT test carrier forbids the use of cell phones in trucks because of safety (accidents) concerns. Many other carriers are investigating the safety issues associated with using a cell phone while driving, and a number of municipalities have banned the use of cell phones while vehicles are in motion.

Panic Buttons

Panic buttons existed in some communication systems prior to 9/11, but in general their integration and use has been limited. However, many new communications systems now include them as standard features, there is little collective knowledge on how often they are used.

Panic buttons provided real-time emergency alert message notification by the driver to the dispatcher. An emergency alert message was generated via the use of a panic button, which came in two configurations:

• A panic button mounted inside the vehicle to send an emergency alert (Figure 10).
• A wireless panic button (WPB) that can be carried by the driver to remotely send an emergency alert and/or use the remote panic button to disable the vehicle (Figure 11).

Figure 10. Dash Mounted Panic Button

Figure 11. Wireless Panic Button

The functionality implemented with the panic buttons (either dash mounted or wireless) was configurable. Functions that could be enabled by pressing the panic button included:

• Disabling/shutting-down the vehicle
• Sending an emergency alert notification to the communications control center to be forwarded on to the carrier's dispatcher
• Bleed the air from the trailer's air-brake system
• Flash the vehicles lights, honk the horn, etc.

Driver Authentication

Driver ID systems, particularly on-board systems are extremely new to the trucking industry with very few operational systems in place. Nevertheless, driver authentication was included in the FOT to ensure that only authorized drivers were operating hazmat vehicles and picking up hazardous materials shipments. This FOT tested two separate technologies designed to authenticate drivers.

Driver Authentication with Global Login

Similar to a username and password on a computer system, Global Login is an authentication feature of the Wireless Communications System. Through the use of a driver login process, the login information (user id and password) that the driver enters into the truck-based interface was verified both locally (on the truck) and over the air using the wireless communication system. If this verification fails, various configurable alerts and resulting actions were triggered up to and including vehicle disabling with the aide of an on-board computer (if installed).

Driver Authentication with Biometric Verification

This technology required having a biometric verification unit (Figure 12) on the vehicle. This was a customized system designed to satisfy the environmental and usage characteristics required for installation in a trucking rig. The biometric system consisted of a Central Processing Unit (CPU) with proprietary firmware which controls an attached smart card reader and fingerprint scanner, and which performs biometric verification. The biometric system was customized to communicate with the on-board tracking and communications system.

Figure 12. Biometric Identification

Electronic Supply Chain Manifest (ESCM)

Supply chain management software is a major component of the business industry, although it continues to grow and evolve in sophistication. However, supply chain systems have only recently integrated with onboard systems, and even fewer supply chain systems link with the public sector. When personnel ID and smart cards are included, the research team was not aware of any off-the-shelf systems for managing these different requirements. The US DOT-sponsored ESCM system does provide technologies that allowed positive identification of the person responsible for the cargo and tracking capabilities for cargo movement within a hazardous materials shipment. Combining biometric verification, smart-cards, Internet applications and the on-board wireless communications, the system insured proper chain-of-control for the hazardous materials throughout the lifecycle of a shipment. It also provided visibility into the location and status of the shipment to the shipper, carrier and consignee, thus enhancing both security and customer service.

Electronic Supply Chain Manifest (ESCM) system security was achieved using:

• Biometric fingerprint readers to restrict unauthorized system access and validate driver identification. Biometric log-ins were required at all access points to create, modify, send, receive, or view data and information within the enclosed test system; and
• Smart cards that integrate data encryption and biometrics to enhance security of the ESCM system. Encrypted smart cards containing shipper, cargo, and driver data were used throughout the ESCM supply chain to transfer and validate essential supply chain information.

Remote Vehicle Shut Down

The ability to remotely control or shut down a vehicle has existed for many years but has seen very little use in the United States, partially due to cost and few historical precedents for justifying the investment. The FOT included an intelligent onboard computer (OBC) integrated with the wireless communications and vehicle operating systems to allow a variety of security related functions, based on configurable input. The OBC was used to control the disabling of the vehicle in a variety of means. These methods included blocking fuel, or sending proprietary system instructions via the wireless communications system directly to the vehicle's data bus. The primary mode of disabling for this FOT was retarding the vehicle into a limp mode where the vehicle still has electrical power but little throttle response past idle. The actual mode of disabling depended on the make, model, and year of the vehicle during installation. The OBC was also configured to shut the vehicle down if there was a loss of satellite signal strength (i.e., severed feed cables). The driver also was able to call the monitoring center and inform them that the vehicle needs to be disabled (in case of theft, for example). At that time the dispatcher could send an over-the-air command to disable the vehicle.

Cargo Door Locking

A cargo door lock (Figure 13) that required the driver to request authorization from the carrier's dispatcher to lock or unlock the trailer door was also demonstrated. This lock was a rugged unit that was bolted to the inside door of the trailer. Using over-the-air communications, a message requesting the doors to be unlocked/locked was sent to the dispatcher. The dispatcher then sent a message to the vehicle OBC device, which sent a command to the door, allowing the driver to unlock/lock the cargo door. For more than 20 years, sophisticated cargo door locking systems have been on the market, however standard, low-cost seals, bolts and locks continue to dominate the market.

Figure 13. Cargo Locking

Electronic Cargo Seals

"E-seals" are a ubiquitous category of sophisticated seals that identify tampering, and/or create random access codes. The type of seal used in the FOT is very sophisticated in its design, but cost and technology integration issues have nearly precluded its use in the for-hire trucking industry.

This technology included a cargo E-seal (Figure 14) that automatically generated an alert if the seal was broken without proper authorization. The seal used short-range wireless communications to interface with a mobile E-Seal reader (located in the vehicle). The mobile reader was connected to the on-board wireless communications device and the cargo alerts were forwarded automatically to the dispatcher. These alerts included the date, time, and location where the seal was breached.

Figure 14. Smart Seal Tag

The driver was alerted of the security breach by one of three ways:

1. Dispatcher sent a message to alert the driver
2. The hand-held device had a driver display
3. The system was integrated with the OBC and was hooked to a buzzer to alert the driver

Geofencing

There are a variety of ways to create geofencing around vehicles and facilities, and there has been some specialized use of this concept in the past; mostly for high-security facilities. While there is now great interest by the public sector in utilizing geofencing for HM vehicles, the technology - particularly the system algorithms - are still developing. Consequently there are few robust systems available today.

Within the FOT, this technology deployed specialized software that allowed the operator to define a risk area or a route to monitor. An "electronic fence" was set around any given route or point on a displayable map (Figure 15).

Figure 15. Geofencing

The dispatcher could define a risk area (e.g., the White House) and if the vehicle entered the risk area or deviated from its route, an alert was sent to the carrier's dispatch center. A safe-haven could also be setup as a geofenced area and notifications could be configured if a vehicle left the area.

The geofencing capability interacted with frequent positioning and the on-board wireless communications system. If the geofence application had received a security breach, the system would automatically increase the positioning reports to a configurable time interval.

Trailer Tracking

Trailer tracking systems have existed for approximately 10 years but only recently - with the advent of integrated asset management software - has the industry begun investing in trailer tracking on a fleet-level scale. The FOT trailer tracking subsystem (Figure 16) provided trailer position information to the dispatcher on a regular basis.

Figure 16. Trailer Tracking Subsystem

The collection of untethered trailer positioning information was accomplished through the installation of devices on the trailers. Through the use of various sensors, these devices monitored the trailer to which they were attached. In response to physical or temporal events, these devices reported details of the event, including position, time, status, and identity data.

Using the tethered device (Figure 17), connect and disconnect events were captured and transmitted as alerts to the dispatcher. This notified the dispatcher that a trailer had been connected or disconnected from the tractor.

Figure 17. Tethered Device

Public Sector Reporting Center (Psrc)

The Battelle Team created the Psrc in order to provide advanced capabilities to law enforcement for data acquisition, fusion, and distribution of messaging for enhancing hazardous materials safety and security. During the FOT, the center was staffed live, 24/7, and was able to incorporate wireless voice/data communications, satellite-tracking technology, automatic routing of alerts to authorities, and online access to highly specialized data. The results were real-time alerts based on monitoring of hazmat shipment information, increased load security, and enhanced law enforcement actions and incident response in the selected test areas.

The Psrc made available the web-based application and allowed end users to create and manage rules that specified which conditions triggered the alert and sent the notification messages. The PSRC also managed user contact information including email, voice text messaging on cell phones (vtext), fax, and pager numbers.

The dominant technology for the Psrc included intelligent agent software as well as database and messaging software which produced and delivered alerts based on detecting certain user-specified events.

The system accepted information input in the form of data feeds from a number of different sources, namely FOT partners. The information from each partner source was temporarily stored and preprocessed. The data was then aggregated and stored in the newly created data silo (a single relational database). The data silo correlated and stored all the information received from the various data feeds. Once in the data silo, a software program acting like an intelligent agent, analyzed the individual pieces of information according to customized rules. These rules analyzed the contents of the data silo, finding data patterns or specific criteria defined by users. As those patterns were found and criteria were met, the system sent one or more messages according to a user specified distribution list.

The Psrc provided the following functionality to motor carriers and public sector agencies:

• Participating motor carriers and agencies created custom alert notification rules based on off-route, unauthorized driver and panic event data. Event data was generated by on-board telematic devices and delivered to the appropriate carrier and public sector agency in the form of a customized alert.
• Numerous individuals within each motor carrier and agency created custom alert notification rules such that each individual or department would receive each particular alert by their choice of email, fax, page, text message, and voice.
• Using hand-held devices and cell phones, the participating carriers and agencies were able to update the Psrc with contact information; view carrier, load, driver and location information; and receive email, text message, and voice alerts.
• Carriers were able to create customized alerts and designate alert levels consistent with specific company operations and protocols. The ability for an unlimited number of individuals within the company to receive customized alerts based upon a particular business activity, load, or customer enabled the carrier to leverage existing carrier safety and response resources efficiently.
• Public sector enforcement and response agencies were able to create customized alerts and designate alert levels consistent with agency enforcement and response protocols and procedures. The ability for an unlimited number of individuals and departments within the agency to receive customized alerts based upon a particular event, material or location enabled the agency to maximize personnel and identify and respond to priority events more effectively.

4.4.3 Technology Selection Rationale

The deployment team recognized early on in the FOT planning stages that the unique operational characteristics of many of the hazardous materials carriers around the country would not lend themselves to full-scale deployment of all the technologies included in the test. While it may be prudent (and the market may bear the cost) to deploy more technologies on certain types of shipments (e.g., explosives), other carriers operate on thin profit margins and the marginal cost of deploying some of these technologies in their vehicles would be prohibitive. To represent these concerns of the market, the FOT separated the various technology components into six technology tiers, ranging from a low-end cost of approximately $250 per vehicle to a high-end of approximately $3,500 per vehicle. Table 11 provides a brief summary of each technology tier.

These estimates for the each end of the price continuum represented only the hardware installed on the trucks in commercial quantities. They did not reflect the price of servers and dispatch systems amortized over the number of vehicles since this can vary widely depending on customer setup.

4.4.4 Scenario Development

The FMCSA required addressing specific research objectives with technologies deployed onto 100 commercial trucks. In addition, from an operational perspective, it was important that the technology applications tested be representative of the various hazmat industry segments and the unique operational considerations of each. Based on the risk profiles and route components identified during the risk and threat assessment, four operational scenarios were developed for the FOT. Table 12 presents a summary of the scenarios and technology components deployed per scenario. Each scenario consisted of 25 vehicles.

To further leverage the available technologies and involve a wider range of participants, these scenarios were subdivided into different components. Table 13 identifies the participants in each scenario and the number of vehicles that were involved.

4.4.5 Design and Installations

The implementation plan addressed the following topics:

• Overview of the FOT
• Training requirements for both deployment team and participant personnel
• Implementation details for each scenarios, including a management plan, roles and responsibilities, an installation plan, and a training plan
• Support processes for both the deployment team and for the participants, including a hotline and engineering support
• Procedures for technology upgrades and addressing equipment failures during deployment
• Internal management and accounting issues.

Processes and Dates

Training of FOT management personnel for scenario 1 and 2 were held in San Diego on August 5^th, 2003. A second group for Scenario 3 and 4 was trained on August 21^st and 22^nd, 2003. These were staged further apart so the training data were still fresh prior to launching the particular scenarios. The training included the implementation plan as well as carrier, shipper, and driver training guides.

Figure 18 shows the installation dates of each carrier's hardware along with the removal dates.

D

Figure 18. FOT Technology Installation, Operation, and Removal Schedule

Support and Training

Each carrier was assigned a Qualcomm regional Customer Service Representative (CSR) to manage, support, and train the participants. The CSR was on site for installs, training, and ongoing visits throughout the six-month test. A Saflink CSR was also on-site for Scenarios 3 and 4 installations of the ESCM system and related technologies.

The training provided by the CSRs included instructing the participants on the roles for carriers, drivers, state agencies, and the deployment team. It also included the collection of test data from the participants to support both the deployment (by uncovering any implementation issues) and the independent evaluation (cost/benefit analysis). Table 14 shows the record of training dates and launch dates of each scenario:

Each CSR was also responsible for setting up all on site evaluations with the evaluators as well as ongoing training when and if needed per carrier.

4.4.6 Conduct the FOT Beta Test

The Battelle Team conducted a beta test of the FOT on July 14-18, 2003 at Qualcomm headquarters in San Diego, CA. The beta test utilized the Qualcomm technology truck and included members of the Deployment Team and the Independent Evaluation Team, led by Science Applications International Corporation (SAIC). A full description of the beta test is presented in Appendix D.

The FOT system design documents [4,5] were modified as a result of the beta test and full-scale deployment of the FOT occurred between August 2003 and May 2004. Throughout the field test, there was close integration with the independent evaluators. A complete description of the four scenarios that comprised the FOT is presented in Appendix A. This includes the participants, the specific technologies that were installed on each truck, and a general description of how the technologies were used in the day-to-day operational setting of the participants.

4.4.7 FOT Data Collection

Throughout the field operational test, a variety of data was collected from the deployed technologies. Well over one million data points were collected. The type and format of data was refined several times based on initial data analysis conducted during the 2003 beta test. A data distribution plan forwarded all data to the Battelle research team, FMCSA, and to SAIC, the project's Independent Evaluation Team. Prior to distribution, a joint ATRI/SAIC data group continually analyzed data and questions and/or issues, and worked with the data system integrators and vendors to clarify or revise data presentations, or investigate system usage. For example, if a specific technology was not producing adequate data, the Deployment Team would investigate and determine whether follow-up training was necessary or if there was an issue with the technology itself. This ensured that data points would support the analysis component of the project. Data was collected on a monthly basis.

Not all technologies produced "operational" data streams. Several technologies were tested both in staged testings in-person and during company visits. Due to lack of integration, data was mined from three separate databases: Qualcomm, Savi, and BSG. The following technologies provided data streams:

• Electronic Supply Chain Manifest - System tracked document creations, electronic cargo data transfers, data confirmation and verification, verified and authenticated system users, and documented changes in cargo "chain of possession."
• Wireless Satellite and Terrestrial Communications (w/GPS) - Produced forward and return messages as well as vehicle positions.
• Wireless Terrestrial Communications Handheld w/ pickup and Delivery Software - Produced and managed information macros and vehicle positions.
• Driver Authentication with Global Login - System created information on driver login/logoff, bad login, distance exceeded, time exceeded, and driver bumped off events.
• Tethered Trailer Tracking - Trailer events (connect or disconnect), as well as position reports were collected.
• Untethered Trailer Tracking - Trailer position reports were collected.
• Electronic Cargo Seals - Sealed, unsealed, and tampered seals were all reported and in turn generated a position report.
• Routing and Geofenced Mapping Software - Out-of-route and exception based violations were reported with position reports.
• Dash and Wireless Panic Buttons - Panic messages were triggered and stored by depressing the panic buttons and collected.
• Cargo Door Lock - Position reports and lock and unlock messages were collected.

4.5 Addressing Functional Requirements

The remainder of this section provides a description of the FOT approach for addressing each of the functional requirements (FR). It identifies the technology products, the participants, and the scenarios that were applied to address each FR as well as the operational approach taken to test each technology either in a daily operational environment or a staged event test.

Table 15 identifies the shippers, carriers, consignees, and hazmat product for each scenario and sub-scenario of the FOT.

4.5.1 FR 1.1 Hazmat Driver Identification and Verification by the Shipper

This FR required the application of technologies that could allow shippers to positively identify a driver prior to allowing that driver to take control of a hazardous materials shipment.

Two technologies, global login and biometric verification, were deployed to provide shippers the ability to verify the identity of a driver prior to allowing him/her to take control of a hazardous materials shipment.

Global Login - Used by itself, the global login required the shipper to watch the driver log in to the Qualcomm system in the cab of the vehicle using the mobile communications terminal. If the driver successfully logged in (proper username and password) a text message was received on the Mobile Communications Terminal indicating a successful login. If the driver entered an incorrect username and/or password, an error message was sent and the driver was required to re-enter the username and password.

The process⁸ used to test this feature involved the following steps:

1. Driver initiates sequence by logging into Qualcomm system.
2. Driver is authenticated via use of proper username and password or is required to try again if login attempt failed.
3. When the system is initiated the driver receives an audible warning and message prompting him/her to login.
4. If the driver starts the engine but does not successfully log into the system after five minutes of idling, a global login security breach is sent to the carrier.
5. If the driver departs without successfully logging into the system after driving one mile, a global login security breach is sent to the carrier.
6. If the driver fails to successfully log into the system three consecutive times, a security breach is sent to the carrier.

The global login technology was used to address FR 1.1 in scenarios 1a, 1b, and 2a. Testing the global login feature was accomplished during the daily operations of the shippers, carriers, and consignees. The test team collected data remotely on usage of this technology and verified the application and use during site test visits at Cox, Dupre, and DisTech in December of 2003. The second onsite tests were performed in February, 2004 for Dupre and March, 2004 with Cox and DisTech. All verifications of this functionality were performed at a carrier location with the independent evaluators serving the role of the shipper.

During the on-site tests the evaluators observed both successful and unsuccessful usage of the global login system. A successful use of global login was defined by when the user entered his/her username and password correctly and was granted access to the system. An unsuccessful login could be caused by entering either an incorrect username, a password, or entering an invalid username and password. When a login was unsuccessful (for whatever reason) the system prompted the user to re-enter his/her username and password. Three consecutive failed login attempts (number was configurable) were deemed to be an unauthorized attempt to access the system and an alert was generated. All events (successful and unsuccessful login) were captured successfully and electronic data was delivered to the independent evaluators as part of the monthly data deliveries.

Biometric Verification - The biometric verification system required the driver to pre-register in the system. This involved recording his/her fingerprint electronically into the biometric database as well as providing him/her with a wallet-sized smart card that contained an electronic copy of their fingerprint.

Driver verification at the shipper's location using biometrics was accomplished two different ways. Some shippers had desktop computer systems with biometric fingerprint readers (bioboxes - see Section 4.5.2 for details) attached. Others simply watched the driver perform the biometric verification in the cab of their vehicle. The process for verification was the same for both approaches:

1. Driver inserts smart card into the slot on the biobox and then places his/her finger on the scanner for verification.
2. An initial verification is made locally, matching the fingerprint stored on the smart card to that scanned on the biobox. If those two fingerprints match, the LED light begins flashing green. If they do not match, the LED light turns red.
3. Once the local verification is made, a message containing the driver's global login user name and password is sent to the Qualcomm Network Management Center (NMC) for verification. The NMC would then send a notification to the carrier, and when verified, a message would be sent back and the driver's identification would be displayed next to the vehicle name. The biobox LED would then turn to a solid green.
4. If the driver starts the engine and did not log in via biometric verification, after two minutes an audible beep is generated and after five minutes or one mile driven, a global login security breach is sent to the carrier.

The biometric verification technology was used to address FR 1.1 in scenarios 3a, 3b, 3c, 4a, and 4b. Testing the biometric verification feature was accomplished during the daily operations of the shippers, carriers, and consignees. The test team collected data remotely on usage of this technology and verified the application and use during site test visits to Transport Services in December, 2003 and January, 2004. Site visits with Roeder were conducted in December, 2003 and January, 2004, with Quality in December, 2003, with R&R in January, February, and April of 2004, and with Dyno in January, 2004. All verifications of this functionality were performed at a carrier location with independent evaluators serving the role of the shipper.

During the on-site test, the evaluators observed both successful and unsuccessful usage of the biometric verification. On several of the occasions the driver's fingerprint was not always read on the first attempt and sometimes took several tries. All events were captured successfully and electronic data was delivered to the independent evaluators as part of the monthly data deliveries.

4.5.2 FR 1.2 Hazmat Cargo Verification by the Driver, Dispatcher, and Receiver

This FR required the application of technologies that would allow drivers, dispatchers, and consignees to verify the hazmat cargo. The primary technology application used to address this functional requirement was the Electronic Supply Chain Manifest (ESCM) system integrated with the biometric verification discussed above.

ESCM - The ESCM system provides a secure means for a shipper to generate a manifest, notify their selected carrier of the need for shipment, confirm that only authorized drivers gain access to a particular load, and only authorized shipments are delivered to the eventual consignee. The process for verification of the cargo is:

1. Shipper logs into the ESCM system with fingerprint and smart card to create electronic manifest.
2. System generates an e-mail to inform the carrier and consignee of the manifest ID (number within the ESCM system).
3. Carrier notifies the driver of load.
4. When driver arrives at shippers facilities, he/she logs into the ESCM with fingerprint and smart card to accept responsibility for the specific load/manifest.
5. System generates an e-mail notification to the carrier and consignee that the driver has "accepted" the load.
6. When driver reaches consignee's location, he/she logs into the ESCM system using smart card and fingerprint and transfers responsibility for the load/manifest to the consignee.
7. System generates an e-mail notification to the carrier, consignee, and shipper confirming receipt by consignee.

The ESCM technology was used to address FR 1.2 in scenarios 3a, 3b, 3c, 4a, and 4b, the shipper and a brief description of the Hazmat Product shipped. Testing the ESCM feature was accomplished during the daily operations of the shippers, carriers, and consignees. The test team collected data remotely on usage of this technology and verified the application and use during state agency testing with BP, Roeder, Evans Chemical, Dyno, R&R, and Orica in February, 2004.

During the on-site tests the ESCM technology worked very well with some instances where driver's were required to re-insert their finger for successful biometric verification. The state agencies were able to pull up the electronic manifest from the roadside using a hand-held personal digital assistant (PDA) equipped with a wireless internet access card. In one test, the team also accompanied the driver inside of the consignee location to view the successful receipt process.

4.5.3 FR 1.3 Hazmat Driver Identification and Verification by the Vehicle

This FR required the application of technologies that required drivers to positively identify themselves in the vehicle prior to allowing that driver to take control of a hazardous materials commercial vehicle.

Two technologies, global login and biometric verification, were deployed to provide this vehicle-based identification and verification of a driver prior to allowing him/her to take control of a hazardous materials commercial vehicle.

Global Login - The global login process was identical to that described for addressing FR 1.1 above.

The global login technology was used to address FR 1.3 in scenarios 1a, 1b, and 2a. Testing the global login feature was accomplished during the daily operations of the shippers, carriers, and consignees. The test team collected data remotely on usage of this technology and verified the application and use during site test visits (see discussion for FR 1.1).

Biometric Verification - Driver verification by the vehicle using biometric verification was identical to that described for addressing FR 1.1 above.

The biometric verification of the driver by the vehicle was tested in scenarios 3a, 3b, 3c, 4a, and 4b. Testing the biometric verification feature was accomplished during the daily operations of the shippers, carriers, and consignees. As discussed later in the findings, there were several operational issues related with the driver identification and verification that centered primarily around the use of the biometric verification technology. These problems included drivers feeling that the "box" took up too much space where it was installed, some problems with the "bio box" reading fingerprints of certain drivers, and difficulty orienting the fingers properly so the bio box would "read" the fingerprint. The majority of these problems would be fixed if the system as a whole were designed to be operated in a rugged environment such as the trucking industry.

The test team collected data remotely on usage of this technology and verified the application and use during site test visits (see discussion for FR 1.1).

4.5.4 FR 1.4 Hazmat Driver Identification and Verification by the Dispatcher

This FR required the application of technologies that required dispatchers to have the capability to positively identify drivers in the vehicle prior to allowing that driver to take control of a hazardous materials commercial vehicle.

Two technologies, global login and biometric verification, were deployed to provide this vehicle-based identification and verification of a driver prior to allowing him/her to take control of a hazardous materials commercial vehicle.

Global Login - The global login process was identical to that described for addressing FR 1.1 above.

The global login technology was used to address FR 1.4 in scenarios 1a, 1b, and 2a. Testing the global login feature was accomplished during the daily operations of the shippers, carriers, and consignees. The test team collected data remotely on usage of this technology and verified the application and use during site test visits (see discussion for FR 1.1).

All functionality was successfully performed at a carrier location with independent evaluators serving the role of the dispatcher observing a driver.

Biometric Verification - Driver verification by the vehicle using biometric verification was identical to that described for addressing FR 1.1 above.

The biometric verification of the driver by the vehicle was tested in scenarios 3a, 3b, 3c, 4a, and 4b. Testing the biometric verification feature was accomplished during the daily operations of the shippers, carriers, and consignees. The test team collected data remotely on usage of this technology and verified the application and use during site test visits (see discussion for FR 1.1).

All functionality was successfully performed at a carrier location with independent evaluators serving the role of the dispatcher viewing a driver.

4.5.5 FR 1.5 Hazmat Cargo Tampering Alert to the Driver and the Dispatcher

This FR required the application of technologies that provided the drivers and dispatchers notification if their hazmat cargo was tampered with.

Two separate cargo security technologies (electronic seals and cargo trailer locking) were integrated with an on-board computer (OBC) technology that interfaced with the Qualcomm on-board communications unit to provide the driver and dispatcher an indication if the security barrier had been penetrated or tampered with during transit.

OBC with Cargo Door Lock - This technology utilized a ruggedized door lock bolted to the inside door of the trailer. Locking and unlocking of this door lock was controlled remotely by the dispatcher. If the door was opened or tampered with prior to proper authorization, an alert was sent to the OBC and forwarded through the Qualcomm NMC to the carrier.

The OBC and cargo door lock technology was used to address FR 1.5 in scenario 4a. Testing the OBC/cargo lock feature was accomplished during the daily operations of the shippers, carriers, and consignees. The test team collected data remotely on usage of this technology and verified the application and use during site test visits at the Illinois weigh station scale just across the border from St. Louis, MO in February, 2004. R&R Trucking provided their driver and vehicle for the test.

Electronic Seals - The electronic seal technology used involved the use of active electronic cargo seals that communicated using dedicated short-range communication (Dsrc) to a hand-held reader. The reader included a cradle assembly that was integrated with the on-board communications unit. The handheld unit used by the drivers recognized the serial numbers of the tags "within range" of the unit. These tags were typically on the trailer door locks.

Once locked, the mobile unit monitors the status of the electronic seals, and if any seal is tampered with, the system automatically sends an alert over the air to the dispatcher. In addition, if at any time the seals can no longer be recognized by the mobile reader (i.e., the cab is disconnected from the trailer and physically separated), the system automatically sends an alert over the air to the dispatcher. If the driver is required to open the cargo doors while en-route (i.e., at an inspection station or roadside by a roadside safety enforcement officer), using the handheld unit the driver electronically "authorizes" the opening of the seals and the system records this opening in a history log. Once completed, the driver repeats the locking procedure and this information is also recorded in the history log.

The process for verifying proper operation of the cargo tampering capabilities of the electronic seals involved:

1. While in surveillance mode, if handheld detects tampering of one or more seals, an alert is sent over the air to the carrier and an audible alarm sounds in the cab of the truck.
2. If seal becomes undetected an alert is sent over the air to the carrier and an audible alarm sounds in the cab of the truck.

The electronic seal technology was tested in scenario 4a. Testing the electronic seal feature was accomplished during the daily operations of the shippers, carriers, and consignees. The test team collected data remotely on usage of this technology and verified the application and use during site test visits at R&R in April 2004.

During the on-site tests for the hardened door lock the evaluation team did not test tampering of the door lock since that would have required damaging to door of the trailer.

The evaluation team did observe periodic difficulties being able to read the tags on the doors of a 48 foot trailer with stainless steel doors while testing the Savi seals. The tags were easily read if located on the doors while the doors were open facing the tractor. As discussed in Section 4.6, the e-seal manufacturer indicated that a newer generation e-seal resolves this issue.

4.5.6 FR 1.6 Remote Cargo Locking and Unlocking by the Dispatcher

This FR required the application of technologies that provided the dispatchers the capability to remotely control access to the hazmat cargo.

OBC with Cargo Door Lock - This technology utilized a ruggedized door lock bolted to the inside door of the trailer. Locking and unlocking of this door lock was controlled remotely by the dispatcher. When the driver wanted to lock/unlock the trailer, he/she would send a message via the on-board communication unit to the dispatcher. The dispatcher would be able to confirm that the driver was at the appropriate location and send a message back to the OBC authorizing the locking/unlocking and the OBC would send the appropriate command to lock/unlock the cargo door. The process for verifying proper operation of the OBC and cargo door lock included:

1. Driver sends an over-the-air message requesting trailer door lock.
2. Message is forwarded from Qualcomm NMC to carrier's dispatcher.
3. Dispatcher responds with authorization to lock/unlock cargo door.
4. Driver presses trailer door switch in cab and walks to back of trailer and opens door.

Note: Initial configurations gave the driver 20 seconds from the time he/she pressed the trailer door switch in the cab to get to the back of the trailer and open the door. If more than 20 seconds elapsed, the door automatically defaulted back to the locked position. During the initial beta test (see Appendix D for more details), this was found to be too short a period of time and the time was increased to 60 seconds for the operational test.

The OBC and cargo door lock technology was used to address FR 1.6 in scenario 4a. Testing the OBC/cargo lock feature was accomplished during the daily operations of the shippers, carriers, and consignees. The test team collected data remotely on usage of this technology and verified the application and use during site test visits at the Illinois weigh station scale just across the border from St. Louis, MO in February, 2004.

During the on-site tests for the ruggedized door lock the evaluation team demonstrated that the door could not be opened unless the command was sent to the driver. The driver also successfully demonstrated that the door could be opened after receiving authorization and pushing the dash mounted switch which unlocked the back door.

4.5.7 FR 2.1 Hazmat Driver Identification and Verification by Dispatcher

This FR required the application of technologies that provided the dispatcher the capability to remotely identify a driver prior to allowing that driver to take control of a hazardous materials shipment.

Two technologies, global login and biometric verification, were deployed to provide dispatchers the ability to verify the identity of a driver prior to allowing him/her to take control of a hazardous materials shipment.

Global Login - The global login process for this FR is identical to that described earlier for FR 1.1 with the exception that the dispatcher monitors the login/logout activity remotely.

The global login technology was used to address FR 2.1 in scenarios 1a, 1b, and 2a. Testing this feature was accomplished in parallel with the testing described earlier for FR 1.1.

Biometric Verification - The biometric verification system process for this FR is identical to that described earlier for FR 1.1 with the exception that the dispatcher monitored the login/logout attempts remotely.

The biometric verification technology was used to address FR 2.1 in scenarios 3a, 3b, 3c, 4a, and 4b. Testing this feature was accomplished in parallel with the testing described earlier for FR 1.1.

4.5.8 FR 2.2 Hazmat Driver Identification and Verification by Roadside Safety Enforcement Officers

This FR required the application of technologies that provided the roadside safety enforcement officers the capability to verify the identity of a driver at the roadside. The technologies deployed to provide this capability again were the global login and biometric verification technologies described previously.

For the driver identification requirement, while en-route, the vehicle was stopped at inspection facilities and/or at the roadside by a mobile officer. In both cases, these stops were prearranged with the carrier, driver, and the roadside safety enforcement organizations and the testing was conducted in a "staged" environment. The driver identification occurred by one of three methods:

1. The officer watched the driver authenticate himself/herself using the global login feature on the vehicle.
2. The officer watched the driver authenticate himself/herself using the smart card and biobox reader installed in the truck.
3. The officer would bring the driver into an inspection facility or into a patrol car and use the smart card and biometric verification system installed there for verification of the driver's identity.

The global login technology was used to address FR 2.2 in scenarios 1a and 1b. Testing this feature was accomplished in parallel with the testing described earlier for FR 1.1.

The biometric verification technology was used to address FR 2.2 in scenarios 3a, 3b, 3c, 4a, and 4b. Testing this feature was accomplished during staged testing events at Evans Chemical, Roeder Cartage, and NYSP in Waterloo New York in February, 2004. The second on-site test verified the application and use during site test visits with R&R Trucking and Illinois State Police outside of St. Louis, MO in February, 2004. The carrier, driver and roadside safety enforcement officers were all notified in advance of this staged test.

4.5.9 FR 2.3 Hazmat Cargo Location Tracking by the Dispatcher

This FR required the application of vehicle and tracking technologies that provided the dispatcher the capability to monitor the location of a hazmat load. The technologies deployed to provide this capability were the basic Qualcomm QTRACS system and the tethered trailer tracking technology.

QTRACS - Qualcomm's QTRACS system monitors the location of the commercial vehicle. The on-board systems monitor their location using either GPS or QASPER (Qualcomm proprietary satellite-based location determination system similar to GPS). Position information is collected locally on-board the vehicle and transmitted via wireless communication to the NMC hourly⁹. Position locations (current and position history) were automatically displayed to the carrier's dispatcher through an application that allowed the dispatcher to view the location (latitude, longitude, and time) of the vehicle on a map.

This tracking capability was demonstrated using both satellite communications as well as terrestrial communications.

This technology was the foundation of the overall system integration and was used to provide cargo tracking to the dispatcher in all scenarios. Testing this technology was accomplished during the daily operations of the shippers, carriers, and consignees. The test team collected data remotely on usage of this technology and verified the application and use during all site visits.

Tethered Trailer Tracking - The TrailerTRACS technology monitored the connect/disconnect events and transmitted a message to the dispatcher when these events occurred. When a driver picked up a hazmat load and a connect message was sent, the dispatcher could then track that load along is route. As long as a disconnect message was not received before the load reached the consignee, the dispatcher was assured that the cargo was "connected" to the tractor sending the location information.

The process for verifying proper operation of the tethered trailer tracking technology included:

1. When the driver hooked the tractor to the trailer, the tethered trailer unit transmitted an ID over the power bus to the mobile unit in the cab of the truck.
2. At this time, the trailer ID is displayed on the display unit in the truck.
3. The mobile unit would then send an over-the-air message to the carrier notifying them of the connect event.
4. This connect message is displayed to the dispatcher.
5. When the driver unhooks the trailer at the consignee's yard, the mobile unit detects the lack of the trailer track ID and sends an over-the-air disconnect message to the carrier.

Combined with the trailer tracking capability described above, this provided the dispatcher the capability to track the load and be assured that no unauthorized disconnects occurred while en-route to the consignee.

The tethered trailer tracking technology was tested in scenario 4b. Testing this technology was accomplished during the daily operations of the shippers, carriers, and consignees as well as during staged event testing. The test team collected data remotely on usage of this technology. The global search on-site testing was not performed with California CHP. One reason for this was the irregular demand requirements associated with this shipment. The load was specialized explosives that were only manufactured when Orica placed an order. Unfortunately, no orders were placed by Orica during the operational period. Other factors impacting the seasonality of these shipments related to the route of the shipment. The route included traversing the Donner Pass in western California, which is frequently closed due to sever weather conditions during the winter months.

4.5.10 FR 2.4 Hazmat Cargo Route Adherence by the Dispatcher and Roadside Safety Enforcement Officers, as Required, Based on the Quantity and Type of Hazmat being Transported

This FR required the application of vehicle and tracking technologies that provided the dispatcher the capability to track a hazmat vehicle's actual route compared to a planned route (on a map) and provide alerts to roadside safety enforcement officers when a geofence route is violated.

Geofencing - The geofencing technology was specialized software that interfaced with the Qualcomm vehicle location reporting information and allowed the operator (dispatcher or roadside safety enforcement officer) to define a risk area or a route to monitor. An "electronic fence" was set around any given route or point on a displayable map. The geofence could be either an inclusion zone (vehicle must stay within a specific defined area) or an exclusion zone (vehicle must not enter a specific defined area). The geofence areas were defined by the dispatcher prior to assignment of the hazmat load.

Psrc - The alerting process for roadside safety officers involved both dispatchers notifying appropriate officials when a geofence alert was received as well as the Public Sector Reporting Center (PSRC) automated alerting function. Prior to initiating a hazmat route, the carrier submitted trip plan information to the PSRC. When roadside safety enforcement officers had a vehicle pulled over (either roadside or at permanent weigh stations) they could use the hand held wireless devices provided by the PSRC to query the system and verify specific route adherence. In addition, when a geofence violation alert was generated by the dispatcher (automatic within the software application running at the carrier's facility), that alert would be forwarded to the PSRC. Based on the location of the vehicle and the safety enforcement organizations involved, the PSRC would then forward an alert to appropriate enforcement personnel via telephone calls, faxes, emails, and/or text messages (depending on how the individual enforcement personnel had defined their preference for receiving such alerts).

The process for verifying proper operation of the geofencing technology included:

1. Carrier initiated a route-based geofence trip on a designated route.
2. Once the trip is initiated, the host system "requests" position location information every 15 minutes (configurable parameter).
3. Dispatcher monitors the vehicle for positions and is able to view on a route map.
4. When driver deviates from the designated route over half a mile (configurable parameter), the host system begins requesting positions every five minutes.
5. If an exclusion zone is penetrated, the host system begins requesting position every 3 minutes.

Both the carrier's dispatchers, as well as selected dispatch officers, were provided with the appropriate software applications to allow them to view and monitor selected hazmat routes.

The process for verifying proper operation of the Psrc geofencing technology involved:

1. Roadside safety enforcement officer pulls driver over (either roadside or at permanent weigh station).
2. Using wireless handheld device, officer inputs vehicle specific parameters and can query the Psrc database for vehicle's adherence to required route.

The process to test the proper operation of the Psrc geofence alerting function included:

1. Alert is generated by dispatcher and forwarded to Psrc.
2. Psrc system correlates the vehicle, cargo, driver, and location with appropriate roadside safety enforcement officers.
3. Alert is generated and forwarded to appropriate roadside safety enforcement officers via telephone calls, faxes, emails, and/or text messages (depending on how the individual enforcement personnel had defined their preference for receiving such alerts).

The geofencing technology and alerting capabilities were tested in scenario 4a. Testing the geofencing technology was accomplished during the daily operations of the shippers, carriers, and consignees. Since no alerts were generated during normal operations, staged events were used to generate and test the alerting capabilities to the dispatcher, roadside safety enforcement officers, and the Psrc. The test team collected data remotely on usage of this technology and verified the application and use during site test visits at the Illinois weigh station scale just across the border from St. Louis, MO in February, 2004. R&R provided the truck and driver for this event.

During the on-site tests the team successfully observed alerts for out-of-route as well as entering an exclusionary zone/geofence. Alerts came across handheld computers, phones, and pagers successfully.

4.5.11 FR 2.5 Untethered Trailer Notification and Tracking by Dispatcher

This FR required the application of vehicle and tracking technologies that provided the dispatcher the capability to monitor when hazmat trailers were unhooked from the cab and the ability to track the trailers while untethered. The technologies deployed to provide this capability were Qualcomm's QTRACS system and the tethered and untethered trailer tracking technology.

QTRACS - The QTRACS tracking system technology used to address this FR is identical to that described for FR 1.9.

Tethered Trailer Tracking - The TrailerTRACS technology was used to address this FR is identical to that described for FR 1.9.

Untethered Trailer Tracking - Qualcomm provided a derivative of their GlobalTRACS asset tracking system to provide the functionality of untethered trailer tracking. The proof of concept technology provided for the FOT provided real-time trailer identification, connect/disconnect time and location, geo-fencing, unscheduled movement identification capabilities. It utilized a multi-mode terrestrial wireless technology that provided better geographic coverage by limiting blackout and dead spot areas.

The Untethered Trailer Tracking unit used a rectangular geofence area. The area was defined by the latitude and longitude of its center, its east-west width, and its north-south height. When the trailer was connected to the tractor and receiving external power, it continually checked its GPS position. If the trailer was moved into or out of a geofenced area, an alert was generated and sent to the carrier. The unit switched over to its own battery power when disconnected from the tractor and recorded the current GPS position of the trailer. When the carrier received notification of the trailer disconnect from the Tethered Trailer Tracking Unit, he/she sent a message to the Untethered Unit to set the width and height of the geofence. The unit then powered down to save battery power. The unit would reawake when the tractor is reconnected or periodically in the absence of external power. At this time its position was checked. If it had left the geofence area an alert was sent to the carrier.

The untethered trailer tracking technologies were deployed in scenario 4b. Testing this technology was done by remote collection of records from daily activities by the independent evaluation team.

The on-site testing of this technology was not performed with the California Highway Patrol (CHP) due to the seasonal shipments into Lincoln California. No shipments were planned during the active testing period. One reason for this was the irregular demand requirements associated with this shipment. The load was specialized explosives that were only manufactured when Orica placed an order. Unfortunately, no orders were placed by Orica during the operational period. Other factors impacting the seasonality of these shipments related to the route of the shipment. The route included traversing the Donner Pass in western California, which is frequently closed due to severe weather conditions during the winter months.

4.5.12 FR 2.6 Hazmat Cargo Tampering Alert to the Driver and the Dispatcher

This FR required the application of technologies that provided the drivers and dispatchers notification if their hazmat cargo was tampered with.

The technologies implemented to address this FR were identical to those described above for FR 1.5.

4.5.13 FR 2.7 Remote Cargo Locking and Unlocking by the Dispatcher

This FR required the application of technologies that provided the dispatchers the capability to remotely control access to the hazmat cargo.

The technologies implemented to address this FR were identical to those described above for FR 1.6.

4.5.14 FR 2.8 Real-time Emergency Alert Message Notification by the Driver to the Dispatcher

This FR required the application of technologies that provided the drivers with a method of notifying dispatchers of emergency situations.

The technologies implemented to address this functional requirement were wireless (key fob¹⁰) and dash-mounted panic buttons.

Wireless Panic Button - The wireless panic button (WPB) was a device that could be carried by the driver to remotely send an emergency alert (via satellite or terrestrial communications) and/or to disable the vehicle. There is a separate button for each function on the Wireless Panic Button Transmitter. The button that is used to send a panic message is recessed to prevent accidental activation.

The process used to test the wireless panic button included:

1. Driver presses red panic button on wireless transmitter.
2. Transmitter sends "panic message" signal to mobile unit.
3. Mobile unit forwards panic message to NMC.
4. NMC forwards panic message to carrier and Psrc and calls carrier and law enforcement with vehicle identification number.

The wireless panic button technologies were deployed in scenarios 1a, 1b, 2a, 3a, 3b, 3c, 4a, and 4b. Testing this technology was accomplished during staged event testing with the independent evaluation team. The test team collected data on usage of this technology and verified the application and use during site test visits on all occasions with Dupre (in conjunction with the Texas Department of Public Safety), Cox (in conjunction with the California Highway Patrol), Distech, Transport Services, Quality, Roeder (in conjunction with the New York State Police), and with R&R (in conjunction with the Illinois State Police).

During the on-site tests simulated panic messages were successfully delivered to the dispatcher, driver manager, public sector reporting center (Psrc), and state agency's dispatch, pager, and hand held computers. Most alerts were delivered within 20 seconds to 2 minutes. The distance from the driver to the cab of the vehicle was approximately 5 feet on the first test and 150 - 200 feet on second test.

In-Dash Panic Button - A panic button was mounted inside the vehicle on the dash to send an emergency alert (via satellite or terrestrial communications). For safety purposes, the vehicle can not be disabled with the wired panic button.

The process used to test the in-dash panic button included:

1. Driver presses wired panic button on dash.
2. "Panic message" signal to mobile unit.
3. Mobile unit forwards panic message to NMC.
4. NMC forwards panic message to carrier and Psrc and calls carrier and law enforcement with vehicle identification number.

The in-dash panic button technologies were deployed in scenarios 1a, 1b, 2a, 3a, 3b, 3c, 4a, and 4b. Testing this technology was accomplished during staged event testing with the independent evaluation team. The test team collected data on usage of this technology and verified the application and use during site test visits listed above under wireless panic testing.

During the on-site tests panics were successfully delivered to the dispatcher, driver manager, public sector reporting center (Psrc), and state dispatch, pager, and hand held computers. Most alerts were delivered within 20 seconds to 2 minutes.

4.5.15 FR 2.10 Real-time Emergency Alert Message Notification by the Vehicle to the Dispatcher if Vehicle Senses an Unauthorized Driver

This FR required the application of technologies that sensed when an unauthorized driver was attempting to operate the hazmat vehicle and notified the dispatcher (without the need for driver intervention).

The technologies deployed and the testing protocol to address this FR were the global login and biometric verification technologies described earlier in the description for FR 1.1. After three failed login attempts on either the global login or the biometric verification systems, an alert message is sent to the dispatcher via the NMC of an attempted unauthorized access.

The global login and biometric verification technologies were deployed in scenarios 1a, 1b, 2a, 3a, 3b, 3c, 4a, and 4b. Testing this technology was accomplished during staged event testing with the independent evaluation team. The test team collected data on usage of this technology and verified the application and use during site test visits listed under FR 1.1

During the on-site tests the evaluation team observed successful and unsuccessful login attempts which generated the appropriate alerts. Alerts were verified from visual, electronic records, and state agency receipts of notifications.

4.5.16 FR 2.11 Real-time Emergency Alert Message Notification by the Dispatcher to Local and State Law Enforcement Officials and Emergency Responders

This FR required the application of technologies that provided for real-time notification of local and state law enforcement officials when dispatchers became aware of emergency situations.

The primary technology deployed to address this FR was the Psrc. Whenever an alert message was generated by one of the other technologies (global login, biometric verification, in-dash panic buttons, wireless panic buttons, geofencing alerts), at the same time the message was sent to the dispatcher it was also sent to the PSRC. Using intelligent software, the PSRC would analyze the alert and based on the vehicle, location, and cargo would notify the appropriate law enforcement personnel and carrier dispatch. The notification was done using a variety of communication means including telephone calls, email, fax, and text message. Each law enforcement agency and carrier participant could establish their own custom protocol for who to contact and how when an alert was generated that applied to them. Once these rules were established, the actual implementation of the notification process was automatic through the PSRC process.

The Psrc notification process was deployed and tested in scenarios 1a, 1b, 3c, and 4a. Testing this technology was accomplished during normal daily operations and staged event testing with the independent evaluation team. The test team collected data on usage of this technology and verified the application and use during site test visits with Dupre and the Texas Department of Public Safety in February, 2004, with Cox and the California Highway Patrol in March, 2004, with Roede and the New York State Police in February, 2004, and with R&R and the Illinois State Police in February, 2004.

During the on-site tests the evaluation team observed proper escalation of the alerts. They did observe one problem while testing with CHP and Cox where a redundancy of escalations would have made it successful. This was a good test and gave real world feedback of designing a production alerting system with built-in redundancy.

4.5.17 FR 2.12 Remote Hazmat Vehicle Disabling by the Driver

This FR required the application of technologies that gave the hazmat drivers the capability to remotely (from outside the cab of the truck) disable their vehicle.

The technology deployed to address this FR was the wireless panic button.

Wireless Remote Vehicle Disabling - The driver-initiated vehicle disabling was implemented with a wireless transmitter, carried by the driver, and a wireless receiver, mounted in the vehicle. In an emergency situation, the driver could disable the vehicle by depressing the Aux button on the wireless transmitter. Once the situation was resolved, the driver re-enabled the vehicle by depressing the Test/Reset button. The device complies with part 15 of FCC rules and the range of the transmitter was approximately 150 feet (line of sight).

The wireless remote vehicle disabling technology was deployed in scenarios 1a, 1b, 2a, 3a, 3b, 3c, and 4a. Testing this technology was accomplished during staged event testing with the independent evaluation team. The test team collected data on usage of this technology and verified the application and use during site test visits listed in FR 1.1.

During the on-site tests the evaluation team observed the driver remotely disabling (sending into limp mode) the vehicle from 5 - 400 feet in some cases. The disabling technology was only activated and installed during on site testing with participants and state agencies.

4.5.18 FR 2.13 Remote Hazmat Vehicle Disabling by the Dispatcher

This FR required the application of technologies that gave dispatchers the capability to remotely disable their vehicle.

Remote Vehicle Disabling - An On Board Computer provided the ability to sense and control door locks over the satellite, activate either a siren or headlights and horn of the truck when a security breach was detected and an over-the-air signal could also be sent to notify both dispatch and a remote monitoring location at the host of a problem detected. The unit provided loss of signal detection and response, based upon a programmable configuration of sensed inputs such as speed, time and temperature. The unit is small and easily concealed.

The On-Board Computer (OBC) vehicle disabling system was hosted on a Windows server at the NMC using the QT/Brazil software application. The application provides the ability to configure the OBC, enable/disable the vehicle, and receive cargo lock alerts. When the vehicle disable message is sent, the throttle was reduced to only idle speed so the vehicle can retain power, steering and brakes.

The remote vehicle disabling technology was tested on scenario 1b, 2a, and 4a. Testing this technology was accomplished during staged event testing with the independent evaluation team. The test team collected data on usage of this technology and verified the application and use during site test visits with Cox and the California Highway Patrol in March, 2004 with Distech in December, 2003 and March, 2004, and with R&R and the Illinois State Police in February, 2004.

During the on-site tests the evaluation team observed over-the-air disabling with commands from dispatch as well as loss of signal disabling (simulated by disconnecting the cables). Disable commands effectively reduced the vehicle operation to the limp mode within 20 seconds to 1 minute 20 seconds from the time the command was sent. The required re-enable full operation of the vehicle averaged 30 seconds from the time the command was issued. The loss of signal re-enable commands took approximately 1-2 minutes to take effect after the cables were re-connected.

4.5.19 FR 2.14 Hazmat Driver Identification and Verification by the Vehicle if the Vehicle is Motionless for 10 Minutes

This FR required the application of technologies onboard the vehicle that sensed when it was motionless and required the driver to re-establish authorization any time the vehicle was motionless for more than 10 minutes with engine idling.

The QTRACS vehicle tracking system was configurable to monitor vehicle movement and log off the driver any time the vehicle remained motionless for more than 10 minutes. The process to test driver login was described earlier in FR 1.1.

This FR was tested in scenarios 1a and 1b as part of the global login procedures.

4.5.20 FR 3.1 Remote Cargo Locking and Unlocking by the Dispatcher

Addressing this FR at the receiver's facility was accomplished in an identical fashion to that described earlier for addressing FR 2.7 for en-route applications.

4.5.21 FR 3.2 Hazmat Driver Identification and Verification by the Receiver

Addressing this FR at the receiver's facility was accomplished in an identical fashion to that described earlier for addressing FR 1.1 for shipper applications.

4.5.22 FR 3.3 Hazmat Cargo Verification by the Receiver

Addressing this FR at the receiver's facility was accomplished in an identical fashion to that described earlier for addressing FR 1.2 for shipper applications.

4.5.23 FR 3.4 Receiver Confirmation of Received Cargo to the Driver and Dispatcher

Addressing this FR at the receiver's facility was accomplished in an identical fashion to that described earlier for addressing FR 1.2 for shipper applications.

4.6 Issues Identified and Lessons Learned from the Field Operational Test

Throughout the course of a highly involved, technically sophisticated field test, there are always many unexpected yet highly valuable lessons that can be documented. The Battelle Team was able to witness and document these findings throughout the system installations, data collection, and interaction with system users. If adjustments were feasible and did not compromise the research objectives, they were made with the advance notification of, and approval by, the project sponsor. However, some of the lessons learned came from qualitative interviews with carrier and driver participants and were not easily remedied.

The majority of the documented lessons learned were discovered during the actual FOT through participant usage, interviews, and site visits. The issues identified and lessons learned were generated from the deployment of technologies to address the vulnerabilities from the Task 1 Threat and Vulnerability Assessment report. Only those vulnerabilities that were determined could be addressed by technology solutions were addressed in this FOT. Vulnerabilities that dealt with the physical environment (i.e., need for perimeter fencing), operational issues (such as better sign-in procedures), or environmental issues (i.e., hazmat delivery in close proximity to high-value target) were not addressed in this FOT. The following discoveries are distinguished by each of the technology groupings.

4.6.1 Technology and Operational Issues

Technological interoperability worked well because of the limited project size and scope; however, the many computing platforms used by the numerous data owners in the industry will present a technical challenge for future work of this nature.

Biometrics & Smart Cards

• The biometric fingerprint readers utilized existing hardware not originally intended for a truck cab environment and did not easily conform to ergonomic designs for in-cab telematic systems. As expected, the readers were difficult to properly position in some trucks, and a number of drivers felt the devices interfered with their "space". During the actual installation of the device, it was very hard to position screws due to the small amount of space between the mount and the box. In addition, box cables need to be at least 6 feet long for ease of after-market installation. This issue could be easily rectified by installing the system into the dashboard console, or utilizing a smaller, less obtrusive reader.
• On a positive note, many drivers conveyed their interest and preference for biometrics as a replacement for driver's licenses and other credentials that highlighted personal information such as addresses and social security numbers.
• There were several substantive issues regarding fingerprint usage. Drivers had some difficulty finding the proper location on the readers. This resulted in lost time and increased driver frustration. Location markers or guides on the reader as to where the finger should be placed would be very helpful. In addition, unique driver characteristics must be taken into account. For example, one driver had poor circulation in his right arm and left hand fingerprints had to be used.
• Driver training was critical to the success of biometric reader acceptance, and when drivers were re-trained on the readers, their participation was higher.
• Cold, moist mornings often resulted in added condensation, making the log-in process more difficult. This is a relatively common issue for biometric readers in general with no simple solution. Certain biometric systems work better than others in cold weather; anecdotally, circuit chips perform better than optical readers in this respect.
• Smart cards sometimes fell out of the reader on rough roads. This problem could be easily rectified with design revisions such as improved smart card guides.
• A related issue is that smart cards tend to warp in wallets and pockets, making insertion and placement somewhat more challenging. A strong consideration for future cards is to utilize the contactless cards that are now seeing increased market usage.
• The biometric unit takes 40-45 seconds to turn on after the key has been turned. Drivers felt this was too long.
• Improved usage rates were recorded on dedicated driver runs. If a driver moved to a different vehicle for 2-3 weeks, they did not remember how to use the device. This would not be an issue if the entire corporate fleet were equipped with biometric devices.
• Companies liked the idea of not having to copy their paperwork and DL and just using an automated system; of having a secure personnel ID system; and of having a system for wirelessly transferring and revising cargo data while the vehicle is en route.

Electronic Data Transfer & ESCM

• The Electronic Supply Chain Manifest (ESCM) generated issues similar to those identified in the original U.S. DOT-sponsored FOT in 2001 [8]. These issues typically focus around data transfer issues associated with slow dial-up connections and/or ISP issues. High-speed digital infrastructure such as T1 lines, DSL, and broadband cable generally eliminate ESCM connectivity issues.
• Another problem experienced in both the hazmat and original ESCM FOTs was hardware and software crashes resulting from unauthorized use of the computer for games and web-surfing. The regrettable solution is to eliminate access to the computer's hard drive and CD by removing them.
• Ultimately it is important to integrate an ESCM-like system with other business management systems in order to eliminate the redundancy that comes from multiple and extraneous steps associated with stand-alone systems.
• Improved user name/password match between the ESCM and QTRACS/Global Login could be accomplished through enhanced system integration.
• The company administrators at ESCM sites were occasionally unable to login to the ESCM system. This was attributed to infrequent use, and fingerprint verification issues likely related to fingers misplaced on the readers.
• Frustration arose when participants were occasionally required to process both electronic and paper-based bills of lading. If an ESCM were expanded to a larger-scale application, it is likely that redundant processing would decrease concurrent with a reduction in paper-based transactions.
• While the ESCM software attempted to duplicate paper-based transactions, users proposed improvements to the ESCM user interface.

Mobile Communication Terminals (MCT)

There were fewer issues and concerns with the MCTs (and the related driver interface) since these devices have evolved through many market-generated iterations. While technical issues with the MCTs were nearly non-existent, there were some ergonomic and qualitative comments. (For instance, one qualitative interview with a driver raised the issue of MCT placement in the truck cabs). In one truck fleet, a special bracket held the MCT in place facing rearward (towards the trailer). The driver stated that it was hard to read incoming messages during daylight hours and that it required him to stop and remove the MCT from the bracket.

• Newer generation MTCs only have one external port where older MTCs have 2 ports. These ports were needed by the suite of systems including e-seals, OBCs, and the biometric smart card readers; obviously not all are used at once due to the port limitations. A future port expander will alleviate this issue if multiple technologies are needed on the same vehicle.

Global Login

• Some drivers were irritated by the beeping triggered when someone does not log in. This occurred when drivers refused to log in due to union issues; forgot how to use the system since it had been some time since they had driven vehicles with the technology; had forgotten their smart card; or had other issues.
• One participating carrier had some issues with drivers being bumped off the system after being logged in.
• This feature was heavily used and some drivers preferred it to the biometric verification. Based on driver comments, the research team speculates that this finding results from some combination of (a) greater familiarity with the existing Global Login, (b) privacy concerns associated with biometric readers, and (c) more frequent technical problems with biometrics.

Cargo Door Locking Systems

• Data collection was difficult to manage because the data had to be captured from the carrier's database.
• The door lock was used successfully in day-to-day operations and on-site testing.
• One carrier used a pin in the lock to keep it in the unlocked position so it could be used on trucks without an OBC.
• Time between wireless command to unlock cargo door and its automatic relocking was reconfigured from 20 seconds to 1 minute to provide drivers enough time to move from the truck cab to the trailer door. This amount of time worked well.

E-Seal System

The e-seal devices were used in this FOT as a concept technology. While they have some utilization in other sectors of the freight industry, they are not currently used in the for-hire trucking industry. The primary benefit of e-seals is their ability to provide immediate notification of a security breach or unauthorized access to the hazmat cargo. They are not necessarily a technology designed to prevent specific terrorist incidents.

• For operation and security purposes, some type of indicator is needed to determine when a tag is inoperable.
• E-seals showed some benefits over other approaches. Padlocks were susceptible to key loss and bolts were too difficult to legitimately cut.
• Placement of the antenna allowed it to be too easily damaged and detection of tags was not reliable.
• Drivers removed the handheld from the truck for security purposes which caused battery failure.
• Newer, heavy-duty trailers and trailer doors interfered with the tag's data transmission. The tag vendor indicated that newer versions of the tag would address this issue.
• Even with e-seal training, it was apparent that the system was extremely complex, likely resulting in low driver usage.
• Actual time spent by the driver affixing and managing tags prior to departing is significant. Additional driver comments included "handhelds have an extremely small screen that is not easy to read" and "buttons on the handheld unit are too small".
• E-seal System Reboot Recovery is time consuming and not user-friendly, i.e., resets the handheld configuration at 45 minutes per driver.
• Handhelds are not able to store and forward information.
• There were several occurrences in which the individual managing the e-seal site was unable to communicate with the e-seal application server.
• The notification process was random. Sometimes an e-mail was provided and other times not.

Geofencing

• Geofencing as a concept had extremely high interest by both industry and government, however the technical design needs revisions including improved position resolution and more complex protocols (bases for exceptions, identification and interdiction). From a carrier perspective, this would provide better asset management.
• Initially, some valid user names and passwords were not accepted. The research team rectified this issue.
• One carrier wanted to import electronic routes from the system into it for ease of operation. The user felt it was too time-consuming creating routes manually on the map.
• Another carrier used the display mapping capabilities of geofencing effectively as a tracking technology to reroute trucks around an area in which someone shot at one of their trucks.

Portable Phone with P&D Software

The portable phone was used at only one carrier. User comments included:

• The phone's display is small and may be difficult for older drivers to see; the menu button is very complex, and button navigation is challenging, resulting in correcting and reselecting due to the navigation button design.
• The cellular coverage in the primary area of test, South Louisiana, was not strong off the Interstate highway.
• Battery life on the phones was short, which required the phone to be plugged into the cigarette charge adapter most of the time.
• The phones are not equipped with a GPS capability. The carrier stated that it is extremely important for them to know where their drivers are at all times; GPS functionality would address this.
• The limited test macros worked well. The test carrier currently uses a more advanced communications system in their over-the-road trucks. If they were to deploy the portable phone instead, they would need the capability to use the same macros and user-defined parameters that are available with their current system.
• Overall, the carrier felt it is a viable commercial solution for medium to large carriers if several key improvements are made, such as larger viewing screen and integration with other management and communication systems.

Panic Buttons

• Although only tested in staged tests and interim visits, many drivers were extremely excited to have both the in-dash and key fob¹¹ panic button.
• There were 2-3 units at one participating carrier that did not function. This was corrected in a later visit.
• Panic buttons were viewed as "insurance policies"; carriers did not expect to use them, but felt their presence created peace-of-mind for drivers.

Untethered Trailer Tracking

• Several electrical power issues arose and were centered on Pin 7 of the 7-way connector. Many trucks were found to have blown fuses. It was determined that some batteries were drained even when connected. Working with the carrier maintenance team, the issue was ultimately solved.
• One battery was discovered that would not hold a charge. It was located and replaced. However, the new battery also discharged very quickly suggesting other electrical problems with this trailer.
• Several of the 7-way connectors on the trailers were found to be old and corroding. These had to be repaired.
• Trailer tracking in general is getting more attention by industry and government for both security and operational purposes. Given the relatively high number of "misplaced" trailers and shipper requirements to better manage cargo, trailer tracking systems have increased substantially. Security benefits are presently unknown but are being tested by the U.S. DOT in other ongoing field tests.

Tethered Trailer Tracking

• Installing the tethered trailer tracking fuse on more tractors would have provided more reliable data on this technology. Hook and drop information, sent from dispatch over the satellite system, was only visible on 10 trucks when hitching to the trailer.

Terrestrial Communications

• Terrestrial communication systems are less expensive than satellite systems, possibly making them a preferred system for smaller carriers.
• One carrier conducted an internal operational analysis of its (terrestrial) tracking system, which indicated it provided a positive ROI based on a cost-benefit survey of facility managers and data analysis. Because of the differential cost structure between satellite and terrestrial systems, it is unclear how the ROI could be extrapolated to satellite systems.

Public Sector Reporting Center

There are a number of issues and lessons learned that were identified concerning the integration of public sector agencies into the FOT:

• The Psrc approach, when shown to non-public sector users, was of tremendous interest to them. They saw the value to being provided with proactive messaging to enable them to enhance their safety and security programs.
• Public sector agencies need to have a solution that is exception-based, is simple to use and is reliable at all times. False alarms drain valuable resources and confidence in the system.
• Law enforcement is reluctant to rely on an operational system that is primarily built and managed by the motor carrier industry. The operational mandates of law enforcement and emergency response are different and as a result, the technological systems in use are different. Future work should focus on integrating the Psrc approach with these systems (e.g., computer aided dispatch systems) to provide a value-added service.
• The Psrc infrastructure for the FOT supplemented existing systems and technologies in use by the public agencies involved. Future consideration should be given to the integration of these capabilities with existing public sector devices as well as with future devices.
• The data silo work and exception-based rule alerting was predicated only on the availability of raw data. The approach on the acquisition of source data to feed the data silo was to work with BSG, Qualcomm, and the participating shippers, carriers, and law enforcement agencies to define the data sources and establish agreements under which these data was moved, shared, and used. Many more stakeholders hold data that could enhance the operation and effectiveness of the Psrc. Future consideration should be given to defining what the optimal, or preferred architecture should be in order to meet ever evolving needs of law enforcement for enhancing hazmat safety and security.
• The field operational test was a vehicle-centric approach, which served well as a baseline. Very little attention was provided during the test to physical or fixed asset infrastructure security. This is important to law enforcement as their mission is not only to protect the moving asset and driver, but also those operating around it and the infrastructure it moves on, through, and around.
• In addition to meeting the research objectives of the FOT, the Psrc was able to demonstrate enhanced, near real-time user functionality including: (a) viewing recent alert notification messages; (b) viewing vehicle and trailer identification data; (c) viewing bill of lading information; (d) viewing carrier, shipper, and consignee contact information; (e) viewing vehicle location data; and (f) sending manual alerts based on driver ID, route adherence, and emergency alert.
• The public sector FOT was not performed in a manner conducive to typical law enforcement operations. The public sector testing was primarily done at carrier terminal locations, which is not an accurate representation of the operational requirements of law enforcement. Further exploration is needed on how to integrate these capabilities/ functions into current operational and technology "protocols" for law enforcement agencies.
• Since Psrc testing was done to minimize the impacts on revenue trips by the participating motor carriers, it was difficult to schedule tests. This led to minimal testing with law enforcement. More frequent and robust testing with law enforcement and emergency response personnel in an operational setting would be beneficial.
• It is difficult to create a joint public-private field operational test that appropriately balances the potential negative operational impacts on either group.
• The public sector testing did not include the incorporation of any law enforcement-sensitive data such as terrorist watch lists, criminal databases, state systems, and other data sources relevant to criminal and security activity. This is something that should be explored for future work of this nature.
• The various types, reliability, security, and cost-effectiveness of communications technologies as they relate to law enforcement was not investigated. In addition, there is a need to investigate the issue of message priority amongst such communications technologies. Alerts relevant to safety and security breaches must take priority over other types of communications.
• Liability concerns need to be identified and defined in terms of when officers become aware of threats/events whether action or inaction presents any potential concerns. This is especially true concerning information coming from non-law enforcement sources.
• The management needs of the data silo, including at what point data should be purged or archived and what events must be logged was not specifically addressed in this operational test. This is an important step in moving ahead with additional work of this nature.
• Law enforcement saw the value of incorporating additional data into the alerts. As such, future work needs to explore the impacts of sending additional data through the modular connector in the data silo for processing and generating alerts. Such information could include more specific vehicle information (e.g., color, markings, description), driver and carrier identification, additional response resources, chemical information, shipper information, population demographics, weather event data, building/structural floor plans, populated places, location of schools, hospitals, major event venues, and even water supplies.
• In order to provide an appropriate environment for operational testing, exception-based agent analysis and message delivery, and queries from law enforcement and first responders, it is critical to have a robust, standardized, central location for all data storage and/or assimilation. Equally as important is having the appropriate interfaces to the data systems that hold the "authoritative" source data.