4. Technical FOT Performance
Technical performance of the FOT technologies was demonstrated through initial Beta Testing, then during the operational test through technology exercises and staged security events. In these latter tests, the systems were tested in the field under near real-world conditions. Additionally, day-to-day performance of the test technologies' performance was captured via participant interviews and analysis of archived event transaction logs.
4.1 Technology FOT Performance
The following subsections summarize the motor carrier participants' reactions to the test technologies, as well as transaction volumes collected for the FOT by technology over the 6-month test periods for the motor carrier FOT participants. The Deployment Team archived comprehensive data records and forwarded this information on a monthly basis to the Evaluation Team for independent analysis.
4.2 Baseline Participant Interviews
On-site baseline interviews were conducted with FOT participant carriers to confirm the "day in the life" descriptions provided in the Concept of Operations document prepared by Battelle.[4] These interviews were also used to collect all available operations data to be used in comparison with the FOT automated system-generated operations data. These on-site interviews aided in quantifying existing operations, including key operating metrics, and provided the availability to collect qualitative perspectives. These perceptions were collected from the terminal managers, dispatch operations staff, and drivers. Collecting baseline data from this series of on-site visits enabled a thorough analysis, leading to informed judgment regarding the effectiveness of test component and test system technology to improve HAZMAT security and operational efficiency.
These on-site FOT participant interviews initiated the process of establishing quantitative and qualitative baseline data for each of the eight FOT participant sites interviewed. Eight of the FOT participant carriers were interviewed at either their operations terminal or corporate headquarters during the summer of 2003. The ninth FOT participant, the Scenario 1A participant motor carrier, was interviewed by phone. Follow-up occurred by regularly scheduled site visits during the FOT to obtain necessary quantitative and qualitative information required to effectively evaluate test technology and test systems' impacts on security and operational efficiency. Some of the general topic areas examined in the on-site FOT participant interviews included:
- Baseline operational description/processes, or "day-in-the-life" descriptions.
- Leading security issues and concerns.
- Current operational and security procedures with or without test technologies.
- Pre-test participant expectations of technology and test outcomes.
- An inventory of technologies and in what combinations the fleets currently employ, including decision support and record-keeping back office systems.
- Current performance measures used in fleets.
- Data used to support performance measurement and decision-making – data types, formats, frequencies, collection, and processing lags (current or historical).
- Currently used carrier return on investment (ROI) models/analyses. Where the participants conducted such analyses and were willing to share these results with the Evaluation Team, the analyses were used to provide historic baseline data and provide a framework for overlaying FOT-generated data for a side-by-side comparison of impacts.
- Historical (archived) data streams – either internal or vendor processed. These included paper logs or electronic records of dispatch; pickup and delivery events and times; and miles traveled en route.
4.3 Overall Baseline Site Visit Results
The reactions from FOT participant carriers interviewed have been overwhelmingly positive. All participants worked well with the Evaluation Team to provide comprehensive short-term historical data for comparison with system-generated test data. Interviewees expressed enthusiasm for the FOT, and many stated an extreme interest in the test outcome, especially if any government mandates result from the FOT findings. It should be noted that the first two site visits were in a slightly different format than the latter six visits that more formally followed the interview guide developed by the Evaluation Team.
4.4 Technology Exercises
The Evaluation Team also collected independent data via interim on-site visits with selected FOT participants in December 2003. This effort was conducted to verify and collect functional data/information concerning test technologies at FOT participant sites in an operational setting. These on-site visits also enabled the Evaluation Team to collect qualitative FOT participant user reactions up to the midpoint of this FOT. These interim interviews captured a broad range of user attitudes, perceptions, reactions, and policy options generated from several months of exposure and use of deployed test technologies at the respective FOT sites.
During the December technology exercises, FOT technologies were tested numerous times in varying configurations to validate their functional integrity for field operations. These technology exercises enabled the Evaluation Team to collect additional technology performance data for FOT participants to bolster the data sample used for analysis.
The technology exercises tested the "real-world" efficacy of the technologies and examined the technical and procedural success or failures. These exercises yielded policy options for improvements in technical performance, content and presentation of exception alerts, or operational procedures to maximize the use of the FOT technology-generated information.
Technologies targeted for exercising during the site visits were those that would not necessarily be used in daily trucking operations (i.e., Panic Buttons, Vehicle Disablement). Additionally, the Evaluation Team wanted to observe ESCM use, system login procedures, and to instigate, if possible, failure of the login process.
Following are the summary technology testing results for technology exercises conducted during December 2003:
- Dash Panic Button with Notification: 47 seconds average time to send and receive panic alert (9 test events).
- Wireless Panic Button with Notification: 44 seconds average time to send and receive panic alert (12 test events).
- Wireless Panic Button with Local Disabling: Tested successfully all 10 times it was tried. Disabling occurred on test vehicles immediately after the panic button initiated throttle release.
- Global Login: 33 seconds average for driver verification using Global Login (15 test events).
- Global Login: 38 seconds average for unsuccessful login for Global Login (12 test events)
- Biometric Global Login: 55 seconds average for driver verification using Biometric Global Login (12 test events).
- Biometric Global Login: 11 successful test events detecting the fingerprint tested did not match the fingerprint on the smart card.
- OBC with Remote Disabling: 2 successful test events with dispatcher initiating throttle disable at driver request with an average time of 20 seconds.
4.5 Staged Events
Staged test events were designed to assess the efficacy of the FOT test suites in terms of technical and procedural performance to address key threats and vulnerabilities. In addition to technical testing of the FOT technologies, similar to the technology exercise testing, t hese events were designed to exercise the full integration of the technology suites. The FOT also tested the technology/human interface to effectively detect and respond to staged attacks on HAZMAT shipments.
The Evaluation Team conducted staged event testing from mid-February to mid-April 2004 at five FOT participant carriers covering all four operational test scenarios. These events allowed for selected FOT technologies to be tested in the most simple and complicated system technology configurations.
There were seven distinct staged event types, with each corresponding to a specific threat type or identified vulnerability, as defined here:
- Geofence Violations: Vehicle violates Geofence in normal course of operations.
- Driver Panic Alerts: While vehicle is en route, the driver triggers a panic alert.
- Driver Identification: In the course of a truck trip, driver fails login – staged at pickup or delivery point or as part of enforcement inspection process.
- Untethered Trailer Tracking: Vehicle violation of trailer Geofence ("unauthorized" movement of trailer).
- Electronic Seal Breaches: Electronic seal tampering en route.
- Load Tracking (ESCM): Sending erroneous manifests – location of delivery, units, load type to public and private sector test participants.
- Vehicle Disabling: Disable vehicle via driver local disabling, dispatch/enforcement disabling, or OBC with loss of signal disabling via OBC in a controlled environment.
Each test event type was repeated several times per involved carrier. Staged event participants were notified of scheduled test events before the testing took place. Test event data was gathered via on-site observation and debriefing interviews immediately after staged events. Additionally, the Evaluation Team analyzed system time-stamped event data and collated it to other collected data.
The staged events helped to identify the aspects of response procedures that are not as well supported by the technologies as they could be, including identifying potential system improvements. Relevant information and data from the technology exercises was also presented to the Delphi Panelists to enable them to provide informed opinions regarding the technologies' ability to reduce vulnerabilities.
4.6 FOT Technology Use and Participant Technology Reactions
FOT participants' reactions to the various technologies deployed during the course of testing were documented at several points during the FOT. Most notable were the opinions collected during the final exit interviews at the conclusion of the FOT during April and May 2004. Exit interviews were conducted onsite at seven FOT participants; the other two were conducted via conference call.
The opinions expressed at the midpoint and conclusion of the FOT concerning various issues related to the technologies under test did not change significantly. Overall, perceptions were positive for the motor carrier FOT participants, with the most notable exception being the Biometric Login. This technology resulted in usability problems for both drivers and employees trying to access the ESCM system via the Biometric Login.
Table 4-1captures general participant response to overall technology configurations at the mid point and completion of the FOT. The scale used in capturing the participants' opinions ran from 1 equaling "Strongly Disagree" to 5 equaling "Strongly Agree."
| Participant Reaction Statements | Interim Findings: 1=Strongly Disagree; 5=Strongly Agree |
Final Findings: 1=Strongly Disagree; 5=Strongly Agree |
|---|---|---|
|
3.7 | 4 |
|
3.7 | 4 |
|
3 | 4 |
|
4 | 3 |
|
3.5 | 3.6 |
|
4 | 3.9 |
|
4 | 4. |
|
4.2 | 3.9 |
|
4.3 | 4.7 |
|
4.3 | 4.6 |
|
3.4 | 3.5 |
|
4.7 | 4 |
|
4.3 | 4.3 |
|
4 | 4.2 |
|
4 | 4 |
|
4 | 4.3 |
The following information presents the test technology transaction volumes and qualitative FOT participant opinions for each of the deployed test technologies. The Evaluation Team collected this information throughout the FOT via archived FOT transaction logs, direct observation, on-site FOT interviews, surveys, and phone interviews.
Wireless Satellite Communications/Wireless Terrestrial Communications
- Wireless Satellite Communications Vehicle Position Reports: 572,804 events
- Forward Messages/Macros from Dispatch to Vehicle: 57,074 events
- Return Messages/Macros from Vehicle to Dispatch: 256,191 events
Eight of the nine FOT test participants have been using Wireless Satellite/Terrestrial Communications for significant periods of time prior to this FOT. Participants unanimously praised Wireless Satellite/Terrestrial Communications. All eight participant carriers that have previously and continued to use Wireless Satellite Communications affirmed the positive efficiency impact it has had on their operations, and all showed robust technology utilization for Wireless Satellite Communications. Positioning frequency ranged from 17 to 70 minutes for FOT participants that depended operational conditions, such as desired customer reporting frequency, type of commodity being hauled, and length of route. Table 4-2 displays the transaction volumes for the Vehicle Position Reports and mean time between position reports received from Wireless Satellite/Terrestrial Communications by specific scenario.
| Scenario | Transaction Volumes | Mean Time Between Position Reports[5] |
|---|---|---|
| Scenario IA | 120,840 | 32 min 53 sec |
| Scenario 1B | 159,031 | 29 min 02 sec |
| Scenario 2A | 33,280 | 59 min 18 sec |
| Scenario 2B | 91,727 | 17 min 30 sec |
| Scenario 3A | 38,898 | 63 min 39 sec |
| Scenario 3B | 32,418 | 58 min 22 sec |
| Scenario 3C | 16,128 | 70 min 24 sec |
| Scenario 4A | 47,384 | 48 min 58 sec |
| Scenario 4B | 33,098 | 59 min 14 sec |
Total Transactions |
572,804 |
FOT participants agree on the positive efficiency benefits derived from using Wireless Satellite/Terrestrial Communications. These communications methods allow motor carriers to better manage drivers and vehicles. Wireless technology enables a dispatcher to rapidly locate company trucks at any time and from any location. Dispatchers utilized the Wireless Satellite tracking to respond to customer location inquiries for their loads. Carriers enjoyed the ability to run detailed reports off archived position records. Companies consistently mentioned that drivers tend to more efficient in managing their time when Wireless Satellite Communications were installed in their fleets. This helps improve carrier productivity and enhance customer service on the return on investment (ROI) side.
Some participants also heavily used macro messages going between dispatcher and driver and vice-versa during this FOT. Using macros allows operational information to be quickly relayed either to or from a terminal and a remote fleet. Table 4-3 displays the transaction volumes for the Forward Messages/Macros from dispatch to vehicle by specific scenario.
| Scenario | Transaction Volumes |
|---|---|
| Scenario 1A | 29,526 |
| Scenario 1B | 14,987 |
| Scenario 2B | 9,739 |
| Scenario 3A | 2,693 |
| Scenario 3B | 1 |
| Scenario 3C | 128 |
| Total Transactions | 57,074 |
Table 4-4 displays the transaction volumes for the Return Messages/Macros from vehicle to dispatch by specific scenario.
| Scenario | Transaction Volumes |
|---|---|
| Scenario 1A | 56,884 |
| Scenario 1B | 98,240 |
| Scenario 2A | 5,616 |
| Scenario 2B | 71,390 |
| Scenario 3A | 9,490 |
| Scenario 3B | 6,715 |
| Scenario 3C | 489 |
| Scenario 4A | 5,796 |
| Scenario 4B | 1,571 |
Total Transactions |
256,191 |
On the security side, Wireless Communications increased the perception of driver, vehicle, and cargo security through near constant visibility. Motor carriers report knowing about stolen vehicles being recovered quickly when Wireless Satellite Systems were in use for a fleet, although none of these events occurred during the conduct of the FOT. Drivers initially resisted the idea of being monitored, but have grown accustomed to the concept, and now, many report feeling more secure knowing that their locations are known.
Digital Phone Without GPS
The Digital Phone without GPS was not tested during the FOT deployment. The participant who was scheduled to use the phones for the FOT could not accommodate the phones into the company's daily operational processes after initially assessing the technology's feasibility. Prior to deploying in operational testing, management assessed the feasibility of sending load tender messages to driver phones, and then had a driver use the phone to perform selected macros. The limited test macros worked well according to the carrier, and the technology was considered viable, but would need to be improved in several areas for trucking companies to commercially use this application. Specific comments for improvement included:
- The phone's display is small, and may be difficult to see for some of our older drivers. Also, the menu button is very difficult, even with practice, to navigate the menus and selections.
- The cellular coverage in the carrier's test area was not good once the drivers left 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. This would be a useful feature for carriers who need to know where the driver is located to validate the information.
Global Login
- Global Login/Biometric Login: 78,891 events
Global Login is an enhanced driver login system that provides password verification for participating drivers. Global Login is only available on satellite mobile units. The Global Login process uses a database at the Network Management Center (NMC) that has a record for each driver. Each satellite mobile unit maintains a small driver list, which holds information for up to five drivers. When the mobile unit is first initialized, there are no drivers in the list. As new drivers log in, they are added to the driver list.
Each driver record includes the following information:
- Driver ID or user name
- Password
- Full Name
For the FOT, there were six distinct event record types captured by the QUALCOMM archived data and delivered monthly to the Evaluation Team for Global Login:
- Global Driver Log In
- Global Driver Log Off
- Bad Log In
- Driver Bumped Off
- Distance Exceeded without correct Log In.
- Time Exceeded without correct Log In.
Several test participants for driver identification and verification in the commercial motor vehicle cab used Global Login heavily during this test. Global Login proved useful for ensuring driver identity by simply entering a username and code into the mobile communications unit. Global Login proved to be a reliable form of driver identification at the four carriers who were assigned Global Login for this FOT. Several other carriers used Global Login as a backup to Biometric Login when it failed.
Global Login was generally well received by drivers who found that training was brief and simple, especially when compared to the Biometric Login. Drivers found that Global Login did not impede their daily operations.
The time required for Global Login was relatively consistent across FOT participants. The Evaluation observed at least five Global Login events at three FOT participant carriers. Global Login events were completed successfully several times at each site in about 33 seconds. Incorrect Global Login events were also conducted to show the ability of the system to reliably detect incorrect login attempts under operational conditions. Incorrect Global Logins also take approximately 38 seconds for the system to detect.
The following summarizes the timings observed at the participant motor carriers:
Successful Global Login by carrier:
- Transport Services (33.4-second average – 5 test events)
- Cox Petroleum (32.6-second average – 5 test events)
- Distribution Technologies (34 second average – 5 test events)
Unsuccessful Global Login by carrier:
- Transport Services (42-second average – 2 test events)
- Cox Petroleum (37.8-second average – 5 test events)
- Distribution Technologies (37-second average – 5 test events)
One petroleum carrier noted that the Global Login provided good security for driver identity. Another petroleum carrier thought that the Global Login might be a burden to some of its drivers who make many stops, but management admitted that the technology worked well. Both of the petroleum carriers noted that perhaps Biometrics would be a more convenient method of identifying drivers than the Global Login application deployed in this FOT.
Biometric Login
- Global Login/Biometric Login: 78,891 events
The Biometric system consisted of a Central Processing Unit (CPU) with proprietary firmware that controls an attached smart card reader and fingerprint scanner that performed Biometric verification. The Biometric system was customized to communicate with the on-board communications systems. The on-board Biometrics device is integrated using Global Login.
For the FOT, there were six distinct event record types captured by the QUALCOMM archived data and delivered monthly to the Evaluation Team for Biometric Global Login:
- Global Driver Log In
- Global Driver Log Off
- Bad Log In
- Driver Bumped Off
- Distance Exceeded without correct Log In
- Time Exceeded without correct Log In
The Biometric Login caused the most frustration of any technology deployed in this FOT due to design and functionality issues. This is disheartening, because the concept of the Biometric Login appealed to many of the participant carriers as a potential means to improve driver identification or employee identification to gain access to cargo load information.
The actual experience that test participants had with the Biometric Login device used in this FOT was that it was often unreliable in the field due to the difficulty in finger placement. It is necessary for users to introduce consistent fingerprints into the Biometric reader to allow either the vehicle to properly start or for employees to log into the ESCM system to work with manifest files. Driver complaints were high for this technology in regards to usability in the field.
According to the FOT participants, for the Biometric fingerprint Readers to be useful in a motor carrier environment, the Readers need some overall design improvement. In addition to difficulty in finger placement location for participants, other problems were noted as well. For example, if a driver's finger were too hot or too cold, the Biometric Reader would often fail to obtain a successful login event. Drivers became frustrated with the device over time and would either stop using it altogether or use the Global Login feature as a backup.
Biometric Login was relatively reliable under test exercising conducted at participant sites during the FOT. The Evaluation Team observed at least five logins per site at three FOT participant carriers using both correct Biometric Login procedures and using procedures to create a login failure (i.e., incorrect code entry, wrong fingerprint, and cold hands).
The purpose of this exercise was to observe the processes; reiterate the findings of the automated data; and to obtain driver opinions about the process and their experience in using the systems. Biometric Logins ranged from about 45 seconds to 1 minute to successfully compete or to detect an unsuccessful attempt.
Global Login and Biometric Login Data
Global Login and Biometric Login data is presented here together since data archives display the same data for both types and several carriers used both types of logins during this FOT.
The numbers below show the totals for successful and unsuccessful global and biometric logins during the course of this FOT:
- Successful Global/Biometric Login: 20,092 events.
- Unsuccessful Global/Biometric Login: 864 events.
Table 4-5 displays the login total for the Global Login/Biometric Login by the specific scenario. Table 4-6 (on page 31) displays the Global Login event types by percent recorded during the FOT.
| Scenario | Login Totals |
|---|---|
| Scenario 1A | 30,579 |
| Scenario 1B | 27,470 |
| Scenario 2A | 2,960 |
| Scenario 3A | 1,119 |
| Scenario 3B | 1,997 |
| Scenario 3C | 4,438 |
| Scenario 4A | 3,607 |
| Scenario 4B | 6,721 |
| Total Transactions | 78,891 |
Electronic Supply Chain Manifest
- The ESCM system generated 55 identifiable, unique manifest numbers. The following numbers describe various manifest transactions that occurred using the ESCM system:
- 4 manifests list only one event, such as "create", with no release or other activity.
- 20 manifests were created and released with no further activity.
- 19 manifests were created, released, picked up, and transferred, but not delivered to a shipper or trucking company.
- 12 manifests represented complete shipments from shipper to trucking company to consignee.
The event records for ESCM were captured and archived in the Biometric Solutions Group (BSG) server and forwarded to the Evaluation Team monthly. The types of events captured in these records included:
- Transaction time and date
- User name
- Shipper name
- Carrier name
- Consignee name
- Transaction Type (create, transfer, pick up, release or delivery)
The electronic supply chain manifest (ESCM) system process is initiated with a shipper biometrically logging onto the system and creating an electronic manifest, identifying the load assignment. After the appropriate data fields are completed (the system notifies the user if essential fields are incomplete or incorrectly filled out), the shipper initiates data transmission and information to a secure central server and logs out. All identified partners are notified via e-mail of the submission.
Although the FOT participants considered the ESCM to be a good concept, participants felt that all stakeholders needed to be involved in the transaction to make it successful.
| Event | Scenario 1A | Scenario 1B | Scenario 2A | Scenario 3A | Scenario 3B | Scenario 3C | Scenario 4A | Scenario 4B |
|---|---|---|---|---|---|---|---|---|
| GL Bad Login | 0.1% | 0.1% | 0.3% | 18.5% | 6.4% | 21.4% | 7.0% | 4.8% |
| GL Distance Exceeded | 9.8% | 9.8% | 5.3% | 1.2% | 5.0% | 2.7% | 11.0% | 7.3% |
| GL Driver Bumped Off | 1.4% | 2.8% | 0.0% | 0.1% | 0.0% | 0.0% | 0.0% | 0.1% |
| GL Driver Login | 29.9% | 28.4% | 35.9% | 40.0% | 36.5% | 26.8% | 31.3% | 32.0% |
| GL Driver Logoff | 28.5% | 25.6% | 33.4% | 36.8% | 34.2% | 24.3% | 30.1% | 30.5% |
| GL Time Exceeded | 30.3% | 33.3% | 25.1% | 3.3% | 17.8% | 24.8% | 20.6% | 25.1% |
Note: Scenario 2B participant did not use Global Login for this FOT.
Shippers, carriers, consignees must all participate. ESCM is not useful as a stand-alone system. All stakeholders need to be plugged into the same interface to make this sort of technology application useful and beneficial.
Access to shipment status was a major benefit noted by participant carriers who noted that it would be useful for both internal and external consumption. The ESCM was useful for viewing manifest information prior to customer pickup for the motor carriers. The manifest information provided precise commodity and quantity data for the dispatcher to see and relay that information to the driver in the field. Customer inquiries on shipment status could be quickly responded to by accessing the ESCM Website.
Participants expressed that the ESCM could reduce paperwork errors and reduce the amount of times needed to enter shipment information across the supply chain. The ESCM was viewed as a system that could also help reduce the accounts receivable cycle by a several days by allowing simultaneous invoice creation with delivery confirmation. An additional assessment was that ESCM would be useful if it was integrated with the carriers' dispatch system, rather than being a stand-alone system. ESCM was viewed as a tool that could help law enforcement or emergency response personnel know the contents of a truck to decide how to properly respond to an incident.
Overall, ESCM usage was poor during the course of the FOT. Although five carriers used the ESCM technology, none used it on a consistent basis. Some of this poor usage can be blamed on the problems encountered with the Biometric Login. Other problems were noted as well. In some instances, either shippers or consignees did not participate much or at all in the ESCM process. This would cause carrier usage to drop as well as isolating the carriers from their business partners in trying out a new technology. The repetitive nature of having to use the ESCM along with traditional paper based processes for a test shipment consumed time and effort for test participant staffs.
During the course of the FOT, the Evaluation Team observed differences in use between the ESCM processes and those with clerical methods and manual paperwork processes. Processing times for manifests were usually in the 2- to 3-minute range for non-ESCM events, versus about 1minute for ESCM events.
The ESCM system seems to be a technology that demands a high level of attention from the Operational Team to ensure consistent system usage over a prolonged period of time, such as what was required for this FOT. The ESCM needs to be used more frequently and consistently in future testing environments to generate more data on which to substantiate efficiency benefits that stakeholders suggest are potentially there.
Panic Buttons
- Panic Button Message Events: 118 test events (not actual panic alerts from drivers)
Panic Buttons were tested under controlled conditions during this FOT such as on-site technology exercises and staged events testing. Table 4-7 displays the number of Panic Button Message events recorded by the specific motor carrier, though these were not actual panic alerts generated by the drivers. There were no accidental panic alerts generated during this FOT. All panic alerts were "created" during on site testing, technology exercises or staged events testing.
| Motor Carrier | Number of Events |
|---|---|
| Scenario 1A | 9 |
| Scenario 1B | 25 |
| Scenario 2A | 17 |
| Scenario 3A | 24 |
| Scenario 3B | 6 |
| Scenario 3C | 18 |
| Scenario 4A | 6 |
| Scenario 4B | 13 |
| Total Transactions | 118 |
This technology was well accepted by the motor carriers. It was felt that Panic Buttons could accurately provide the location and time of an alert event when pressed by a driver in distress. Panic Buttons were viewed as having excellent security potential. In fact, several of the participants already had in-dash Panic Buttons installed prior to this FOT and expressed excellent satisfaction with the technology. Panic Buttons are mandatory for motor carriers participating in the Defense Transportation Tracking System and are required for Department of Transportation and Department of Energy for transporting certain load types, such as munitions.
Panic Buttons were generally well received by drivers and dispatchers, and provided a sense of security to many of the drivers. Panic Buttons were viewed as a viable technology method to alert the motor carrier or law enforcement personnel from remote regions of the nation. The only issue associated with the Panic Button was that some drivers felt the key fob (security token) design could cause an alert to be issued by a driver by accidentally bumping the trigger device.
Panic Buttons were also combined with the remote disabling available to the driver when in the immediate vicinity of the truck for some of the FOT participants. Participants viewed this as a way for a driver to respond directly to disable the vehicle in the event that an unauthorized party attempted to gain vehicle control. Drivers seemed to enthusiastic about this technology application that put the ability to disable a vehicle into their own hands.
During site visits at five FOT participant carriers, participants were asked to activate the Panic Button with notification configurations from two to three times per vehicle. Panic Buttons were not tested during normal operations due to the sensitive nature of the technology and not creating "false alarms". Recorded panic alert notifications from the technology exercise site visits took between 25 seconds to about 1 minute from the moment the Panic Button was pressed to the point when the dispatcher was alerted at the motor carrier facility.
Wireless Panic Button with Local Disabling was demonstrated of capability a minimum of two times per participant site for five participant carriers. The vehicle was disabled at distances up to 250 feet from the vehicle location. During these tests, successful throttle disablement occurred almost immediately when a Panic Button was pressed at the test locations.
Geofencing
- Geofence Events:
- 165 Off Route Detections
- 79 On Route Detections
- 38 Geofence Violations
- 38 Exited Geofence Area
Geofencing was utilized in two operational functionalities during this FOT by one of the FOT participants. Geofencing is used for alerting a trucking company when one of its vehicles leaves its designated route or enters a restricted area. Both functionalities involved frequent vehicle positioning via Wireless Satellite Communications.
The first of these functionalities, off-route detection, was tested from mid-January to mid-April by one of the FOT participant carriers on selected routes. Typically, one truck, but sometimes more, was selected daily during this 3-month test run to have a .5-mile zone placed on both sides of a delivery route designated for a vehicle. Each time a vehicle position report is generated, the vehicle position is compared against the specific route created on the QTRACS® Web interface.[6] The default positioning is set for once an hour, and is configurable at the discretion of each carrier.
Each time a positioning event takes place, this technology compares the position report against a software-created map to determine that a vehicle is not "off route" or inside or outside a designated "Geofence". This time is set at the default 1-hour positioning frequency, but the actual comparison rate depends on a particular carrier's message frequency. The participant positioning intervals observed in the FOT varied due to hourly position reports, message traffic – which provides position, and vehicle downtime en route. These included:
- Scenario 1A: 32 min 53 sec
- Scenario 1B: 29 min 02 sec
- Scenario 2A: 59 min 18 sec
- Scenario 2B: 17 min 30 sec
- Scenario 3A: 63 min 39 sec
- Scenario 3B: 58 min 22 sec
- Scenario 3C: 70 min 24 sec
- Scenario 4A: 48 min 58 sec
- Scenario 4B: 59 min 14 sec
The carrier participant in this FOT had a positioning frequency average of 48 minutes and 58 seconds due to hourly position reporting and message traffic.
Once an off-route violation was detected, the alert message was sent out within 30 seconds to 1 minute to the dispatcher's screen. Off-route detection can be set to increase the polling rate for vehicle positioning once an off-route event is detected – a feature that was not utilized during the FOT by the testing participant. There was no evidence in the archived records or through contact with the dispatcher that at any point the off route detection failed to work properly.
There were 165 off-route detection events during this FOT and 79 on-route detection events, signifying that a vehicle had returned to its designated route. There were more off-route detections because a vehicle might take a different route to the delivery location than the dispatcher-selected route. Drivers were not told what vehicles on what days were being used for off-route detection.
Minimal training was needed for the dispatcher to set a route. Each time a route was selected, the dispatcher entered the route by mapping points on an Internet-based software package. It was reported that the dispatcher would like to have the ability to archive historical routes for future usage. This would eliminate the need for the dispatcher to create a route from scratch by designating selected points on the virtual map.
The second functionality, Geofencing to alert of trucks entering a "keep out" or restricted area, was tested from late February to late April at two selected sites. The first of these sites was the participant terminal; the second site was the O'Fallon Inspection Station near O'Fallon, Illinois . A 2-mile radius was placed around each location. In the case of the latter test, the violated geofence breech occurred between two position reports generated 29 minutes apart.
Participating test trucks caused Geofence detection either when the truck violated the geofence by entering the 2-mile radius surrounding the restricted area or when the truck exited the restricted area. Each time a vehicle position report is generated, the vehicle position is compared against the specific "keep out" or "keep in" radius created on the QTRACS® Web interface. The default positioning is set for once an hour, and is configurable at the discretion of each carrier.
In the same manner as off-route detection, it took up to 1 hour for the system to detect an "off route" or Geofence violation based on the standard 1 hour positioning frequency. Once this Geofence violation was detected, the alert message was sent out within 30 seconds to 1 minute to the dispatcher's screen. There was no evidence in the archived records or through contact with the dispatcher that at any point the geofence detection failed to work properly. Geofence detection can be set up to increase the polling rate for vehicle positioning once a Geofence event is detected – a feature not utilized during the FOT by the testing participant.
Geofencing was received positively by the FOT participant who used it during the FOT. The participant viewed Geofencing as an excellent technology to locate a vehicle that was off route or in an area where management did not want that truck to be positioned. The participant thought it would useful as a tool not only to improve security, but it might keep drivers from stopping for excessive periods of time at unauthorized locations. Geofencing did not change driver behavior directly since the drivers were not aware of what vehicles were being monitored with Geofencing.
There were limitations to Geofencing in the manner that it was utilized in this test. With positioning frequency default set at 1 hour, it is possible for a vehicle to enter a "Geofence" or to travel "off route" and not be detected as long as at the location of the next positioning event the vehicle is back on course or no longer in the "Geofence" zone.
The simplest answer is to increase vehicle-positioning frequency, but more frequent positioning than 1-hour intervals would become costly for many motor carriers. Geofencing technology needs to cost effectively develop the functionality to detect violations and report them in more near real time. The technology should ideally trigger a violation alert in real time rather than needing to wait for the next positioning report to activate the alert.
Electronic Seals
- Electronic Seal Events: Security Events 3,553 and Inspection Inquiries 1,151
By definition, security events were comprised of the necessary steps to remotely operate the electronic seal including assigning, locking, unlocking, and un-assigning the seal. These events are all covered in the specific archived functionalities listed below with the exception of "Inspect Asset Security". By definition, inspection inquiries were the user requests for remote asset status updates that may be made at any point in the HAZMAT distribution chain and were recorded as an "Inspect Asset Security".
The following electronic seal events were archived during this FOT:
- Assign Seal
- Lock Seal
- Validate Security
- Un Assign Seal
- Inspect Asset Security
- Synchronize Seal
- Unlock Seal
- Clear Tamper Status
The wireless electronic tag seal (E-seal) system used for this test is a Web-based application that provides continuous online security monitoring of cargo containers and other assets. With the wireless electronic tag seal system, the user should be able to verify that a container was loaded and sealed at a secure loading point and sealing station. The E-seal can provide information regarding tamper events to ensure container accountability from point of origin to destination. For this application, the mobile Wireless Communications system was used as the communications link between its site-based and mobile subsystems.
The E-seals were also created as a concept of technology utilizing existing hardware, but not specifically for a truck environment. The participant saw potential value to the E-seal as a security device, but operational problems with the electronic seal tested including low reliability and heavy driver time and involvement needed to operate the electronic seals.
E-seals were difficult for drivers to operate at the onset of the test. It took between 5 to 6 minutes to complete the cycle of assigning and locking an E-seal at a customer's pick-up location. This problem was remedied when these steps were combined into a single step to reduce the time to between 2 and 3 minutes. Training was also difficult for the drivers, due to the complexity of the technology, and the many steps involved in its operation.
During the "staged events" testing in April 2004, initial attempts to communicate with E-seals attached to the trailer's rear door were unsuccessful, while E-seals placed on the sides of the trailer were detected. This is position in which the E-seal would normally be placed in real-world operations. Upon closer examination, the E-seal engineers discovered that the trailer selected for this test was constructed of extremely heavy gauge, double-walled stainless steel. The mechanic who selected the trailer used in the test stated that it was a newer model, and that it was the heaviest-duty trailer in the company's fleet. The E-seals had to be moved away from the heavy doors and onto the sides of the trailer; only then did the Reader in the vehicle cab read all three seals.
The electronic seal as tested in this FOT does not demonstrate a realistic operational device at this point.
OBC With Remote Door Lock
- Remote Trailer Door Lock: 16 events
This technology was successfully utilized 16 times with no recorded unsuccessful technology events by the participant carrier who had the OBC with Remote Door Lock installed on one truck for FOT testing. The participant observed that the OBC with Remote Door Locking had some merit as a security device at an acceptable cost for the carrier. The driver must send a message via the OBC unit to the dispatcher for permission to unlock the door. The dispatcher must then send an over-the-air command to remotely unlock the trailer door. The driver had 60 seconds to unlock the door after receiving confirmation from the dispatcher; otherwise, the driver would have to call again to gain permission to open the door. The amount of time the driver was allowed before the door opens is configurable according to user requirements.
The OBC with Door Lock worked excellent in both daily operations and during on-site technology testing. This sequence of events was demonstrated during on-site testing at the FOT participant carrier using this functionality on one truck. Due to the door/lock construction, it is difficult for an unauthorized individual to pry the doors open. Even if an unauthorized party opened the doors, a tamper message would be sent to the Network Management Center (NMC) that the doors security has been breached. The motor carrier or law enforcement can then be contacted about the situation.
OBC With Remote Disabling/Loss of Signal Disabling
This technology was well received during on site technology testing and during "staged events" testing at several of the FOT participants. Participants did seem to have reservations about shutting down vehicles in the normal stream of traffic, but viewed it as an option in emergency situations. Participants thought it difficult to imagine this technology being deployed in the real world due to these concerns.
Tethered/Untethered Trailer Tracking
- Trailer Tracking: Tethered Trailer 362 Events (connects and disconnects) and Untethered Position 7,133 Reports
Tethered Trailer Tracking allowed dispatch to monitor trailer connects and disconnects. Connects and disconnects were detected by the mobile unit and passed on to dispatch via the satellite link with the date, time, and location. Tethered Trailer Tracking required that each trailer be equipped with a transmitter that communicated to the mobile unit on the vehicle DC power bus. Archived FOT data included the trailer ID, the event code to either connect or disconnect, and the system time of the event.
Untethered Trailer Tracking allowed for real-time trailer identification, connect/disconnect time location, Geofencing, and unscheduled movement of the trailer independent of any power requirements or connectivity with the vehicle cab. The system utilized a multi-mode terrestrial wireless technology, which provided better geographic coverage by eliminating blackouts and dead spots, thereby improving reliability and service over single mode systems.
Both the Tethered and Untethered Trailer Tracking technologies were well received by the FOT participant using these technologies. Dispatch found useful the ability to detect trailer connects and disconnects with the Tethered Trailer Tracking, and the ability to track an unconnected trailer as another authorized carrier moved it. Both technologies were used on a consistent basis during the FOT.
4. Battelle, HAZMAT Safety and Security Field Operational Test: Task 2: Concept of Operations, prepared for FMCSA, April 18, 2003.
5. Intervals less than 3 minutes and over 12 hours have been eliminated from the data set because at the low end, the interval represents part of message traffic between driver and dispatcher related to a single "conversation"; above 12 hours represents vehicles that are parked long term and do not generate position reports.
6. QTRACS® is a registered trademark of QUALCOMM for its fleet management messaging and vehicle tracking system.