Prototype deployment and results in the execution of the Freight Advanced Traveler Information System Small-Scale Testing Program in Dallas-Fort Worth.
Freight Advanced Traveler Information System (FRATIS) - Dallas-Fort Worth (DFW) Prototype: Final Report
This report summarizes the prototype deployment and results in the execution of the Freight Advanced Traveler Information System (FRATIS) Small-Scale Testing program in the Dallas-Fort Worth (DFW) region of Texas (FRATIS DFW). The purpose of the FRATIS DFW prototype was to demonstrate a small-scale implementation of the USDOT’s FRATIS bundle of applications. At the conceptual level, these included an intermodal drayage optimization application and a freight-specific travel planning and performance application. The DFW region was selected due to the size of the area (the fourth largest metropolitan area in the United States) and the prevalence of dray traffic in the region due to the presence of multiple Class I rail terminals and the many container yards, distribution centers and warehouses that network with these entities. At the highest level, the performance goals for the overall FRATIS bundle of applications included:
- Reducing the number of bobtail trips by 10 percent
- Reducing terminal queue time by 20 percent
- Reducing travel time by 15 percent
- Reducing fuel consumption by 5 percent
- Reducing criteria pollutants and greenhouse gas emissions by 5 percent each.
The challenges, solutions and lessons learned related to the stakeholder engagement activities during the FRATIS DFW prototype included:
- Early identification of potential stakeholders is necessary for alignment of expectations and schedule mitigation once the prototype process starts. It takes time to gather background information about new stakeholders, which was critical in defining their degree of participation in the prototype activities.
- First and second tier stakeholders are equally important in the design of prototype systems. Enthusiasm and participation of stakeholders engaging with a project later can impact and direct the success of a project as much as those defined at the beginning of the project.
- Prototypes should be willing to change course: the operating conditions within the stakeholder organization and user feedback should be a priority in design. Staff turnover and the fast-pace of the trucking/drayage industry mean conditions change frequently. Dispatchers that helped lay the foundation for working with the prototype were not necessarily the dispatchers working at the time of deployment. Dispatch centers may also change their technologies and either consolidate or decentralize operations at any time.
- Find the right stakeholders: incentives help, but they do not completely guarantee buy-in. The USDOT aimed to structure the FRATIS prototype so that private industry would be enticed to sign on and provide continued participation. One example of an enticement was mandating in the statement of work that any equipment purchased for the prototype could remain with the participant after the conclusion of the study.
- Given the large number of owner-operators in the current drayage community, technology involving driver use and acceptance must show benefit to drivers, not just fleet managers. Driver buy-in is important to guaranteeing the success of a proposed technology. Both participating drayage companies recommended that when technology requires driver interaction and acceptance, it must demonstrate an improvement to the drivers’ bottom line, especially when owner-operators are most of the staff for many companies.
- Small-scale prototypes may not demonstrate enough benefits to maintain necessary stakeholder involvement. Given the scope of freight transportation in the DFW area, including only two small drayage companies, a total of 50 trucks, does not register a significant impact within the region.
- Pilot and prototype tests should include flexibility within the planning process. The execution of a prototype is constantly impacted by the input of the stakeholders, their operating environment and the participation of vendors and developers. Therefore, tests must include flexibility to allow deviation from what is contractually-mandated in the statement of work.