Jennifer Symoun
Good afternoon or good morning to those of you to the West. Welcome to the Talking Freight Seminar Series. My name is Jennifer Symoun and I will moderate today's seminar. Today's topic is the Cross Town Improvement Project, or CTIP. Please be advised that today's seminar is being recorded.
Before I go any further, I do want to let those of you who are calling into the teleconference for the audio know that you need to mute your computer speakers or else you will be hearing your audio over the computer as well. I'm also going to bring up a poll to get an idea of how many of you are using the voice over IP option versus how many are using the teleconference option.
Today we'll have five presenters, Randy Butler of the FHWA Office of Freight Management and Operations, Ron Schaefer of SAIC, Paul Belella of Delcan, Roger Schiller of Cambridge Systematics, and Ed McQuillan of RMI.
Randy Butler joined Federal Highway Administration in November of 2003 as a Transportation Specialist on the Operation and Technology Team. Prior to joining FHWA, Randy completed a thirty-five year career in the private sector in managing freight transportation operations, engineering, customer service, business process reengineering, information systems and project management. Randy currently is completing a Doctor of Business Administration in Global Supply Chain Management at Walden University. He also holds a Project Management Professional Certification from the Project Management Institute.
Ron Schaefer is a Senior Transportation Analyst in the Logistics and Engineering Business Unit at Science Applications International Corporation (SAIC). He is the Program Manager for the FHWA Cross-Town Improvement Project (C-TIP), the Electronic Freight Management case study project, the Dynamic Mobility Application Open Source Portal Project, and the Smart Roadside Initiative. Prior to joining SAIC Ron worked twenty-seven years at Union Pacific Corporation in a variety of information technology management positions including software development, R&D, emerging technologies, and business development.
Paul Belella has 24 years of experience spanning the areas of intermodal and truck-borne freight transportation, to include specific expertise with vehicle and administrative technology systems, freight efficiency and operations analysis, freight security technology, freight planning, decision support systems, and web-based communications and transaction media. He currently manages Delcan's Freight, Trade, and International Borders Practice, and is providing project management, and technical support to the development and application of advanced vehicle and back-office technology to enhance commercial freight security and efficiency, freight transportation planning and analysis, and the assessment and reengineering of operations to leverage advancements in information technology.
Roger Schiller is an Associate at Cambridge Systematics, and is serving as the Lead Analyst in Cambridge Systematics evaluation of the C-TIP deployment in Kansas City, Missouri. Recent projects he has been involved with include the Chattanooga Volkswagen Plant Freight Impact Analysis and the West Coast Corridor Coalition (WCCC) Trade and Transportation Study. Mr. Schiller also is assisting in the collection of truck GPS data in Southern California for improvements to SCAG's Heavy Duty Truck Model.
Ed McQuillan is a Senior Transportation Manager at RMI, and is responsible for managing RMI's development of the C-TIP evaluation performance monitoring system. He has over 30 years of experience in the freight and rail transportation industry, and has a broad understanding of transportation network structures and strategies. His career in freight operations has included work for Hanjin Shipping and the Chicago and Northwestern Railway Company. He is a member of the Intermodal Association of North America (IANA) and also is a member of the Intermodal Association of Chicago and the Intermodal Freight Technology Working Group.
I'd now like to go over a few logistical details prior to starting the seminar. Today's seminar will last 90 minutes, with 60 minutes allocated for the speakers, and the final 30 minutes for audience Question and Answer. If during the presentations you think of a question, you can type it into the chat area. Please make sure you send your question to "Everyone" and indicate which presenter your question is for. Presenters will be unable to answer your questions during their presentations, but I will start off the question and answer session with the questions typed into the chat box. Once we get through all of the questions that have been typed in, the Operator will give you instructions on how to ask a question over the phone. If you think of a question after the seminar, you can send it to the presenters directly, or I encourage you to use the Freight Planning LISTSERV. If you have not already joined the LISTSERV, the web address at which you can register is provided on the slide on your screen.
Finally, I would like to remind you that this session is being recorded. A file containing the audio and the visual portion of this seminar will be posted to the Talking Freight Web site within the next week. We encourage you to direct others in your office that may have not been able to attend this seminar to access the recorded seminar.
The PowerPoint presentations used during the seminar are available for download from the file download box in the lower right corner of your screen. The presentations will also be available online within the next week. I will notify all attendees of the availability of the PowerPoints, the recording, and a transcript of this seminar.
One final note: Talking Freight seminars are eligible for 1.5 certification maintenance credits for AICP members. In order to obtain credit for today's seminar, you must have logged in with your first and last name or if you are attending with a group of people you must type your first and last name into the chat box. I have included more detailed instructions in the file share box on how to obtain your credits after the seminar. Please also download the evaluation form from the file share box and submit this form to me after you have filled it out.
We're now going to go ahead and get started. Today's topic, for those of you who just joined us, is Freight Analysis Framework 3. Our first presenter will be Randy Butler of the FHWA Office of Freight Management and Operations.
As a reminder, if you have questions during the presentation please type them into the chat box and they will be answered in the last 30 minutes of the seminar.
Randy Butler
Great. Thank you, thank you everyone for joining this afternoon for an update on the Cross-Town Improvement Project. We reviewed this project about a year ago in Talking Freight. We're now at the point that we're starting implementation and at the same time starting evaluation. What I will do briefly is go over an overview of the project and turn it over to Ron, Paul, Roger and Ed to talk about the components and the evaluation of the project.
This project has been in development for almost five years. It originated out of a group that used to meet semi-annually. I will briefly talk about what the contents of this presentation are, and then we will go into the specifics. First is the background of what a cross-town consists of and what we've developed out of that as a problem statement that focuses on trip reduction. We will talk about potential locations of where this may be deployed and different modes. We will look at our goal and how we've been able to put together a public-private partnership working together to achieve these goals. There are five components, I will briefly introduce them and let Ron and Paul talk more about the details of the components. I will briefly give you an operating scenario of how this will be planned to work. And then at the end of the presentation I will talk about where we are from a status perspective and next steps. Also, the evaluation piece, we will go quickly into that and talk about how we're measuring the results of the project.
For those of you that are not familiar with what the Cross-Town Improvement Project is, it originated with a group called the Intermodal Freight Technology Working Group. This is a transportation stakeholder group focused on improving productivity and public benefits through technology. This slide says we meet semi-annually. We've been meeting for the last five years. This next year we'll move into more of a regional concept. We will focus on having meetings across the country at different locations to understand and listen to what some of the regional problems are and how they can be used in different areas of the country. From this group that meets and introduces new projects and reviews ongoing projects, one of the first accomplishments out of this group is to do a business process model following a container as it originates in the U.S. and moves through the transportation network. This process map took up about four or five rooms as there were many activities taking place in it. We were able to identify in the processes associated with the transportation movement of a container, basically coming off of a water container to a drayage company on to rail then back to a drayage company then to a distribution center and then out of the distribution center. Of this total transportation time time, 40% was waiting for information exchanges between supply chain partners. From this time we were able to focus our efforts on information sharing and exchange between the partners and developing new technologies that would support that.
The cross-town is a part of this process. When railroads take shipments from the West Coast, there are three interchange points that focus on cross-towns. The main one is Chicago, but there's one in Kansas City and one in St. Louis. Memphis is another area where there's a tremendous amount of cross-towns. In order to get through between say the Union Pacific and the NS or the Burlington Northern and CSX there has to be a container taken off of a railcar and moved over the highway and reloaded on another railcar. What we found in our study is that when these movements were actually taking place, there was no back haul associated with the movement. There was a bob tail movement for each movement that was taking place. In the Chicago area we're looking sometimes at the neighborhood of peak economic conditions of close to 20,000 of these movements a day. You can see what the problem was, if we could start coordinating information between the terminals of what containers need to move back to another terminal, we could eliminate a trip. Thus, saving productive time and also reducing emissions.
We developed a problem statement that focuses on public and private benefits like congestion, efficiency of the transportation network, safety, environment of communities and energy consumption. These areas focused our next steps in developing what we considered areas where we may be able to deploy this technology. As I mentioned, we were focused on, but as we looked at other types of contain movement we saw the same type of operation inefficiencies and being to apply this same concept to reduce that empty trip. So our C-TIP goal was to develop and deploy an information sharing and transfer capability that enables the coordination of movements to maximize loaded movements and minimize unproductive movements.
The public private partnership was focused on a goal of trip reduction. From that, we looked at specific areas where we could apply these types of benefits. Examples include: from the freight carrier, from the supply chain, opening up competitiveness, and public benefits. If we were able to accomplish this goal, we would see results in these four different areas.
The public private partnership, even though this idea was really conceived to be beneficial to Chicago as being the main focus, we wanted to start with a project that was smaller in magnitude and would produce the same results. We worked with a group in Kansas City. We worked with the railroads in Kansas City, Union Pacific, Burlington Northern, NS, and KCS. We've had some specific trucking companies we've been working. We've had the Missouri DOT and Kansas DOT heavily involved as well as a MPO, Mid-America Regional Council. We've also had the economic development group that's been very active in helping us pull in project together. And the traffic management organization, KC Scout, is where we get traffic information from. We've had all of these groups working together as a public private partnership to achieve the goal.
I mentioned the C-TIP components briefly. Like I said, I will let Ron and Paul take the detail and give you a good idea about the concepts. I look at the Intermodal Exchange, the IMEX, as the heart of the system. This is where everything flows to and from. It is the main focus of where we're sharing information. We're developing some of the work that we've done in the past with our web services, service oriented architecture to be able to support this exchange. The Wireless Drayage Updating was actually contributed to us on part by the Federal Motor Carrier. The Chassis Utilization Tracking project originally was conceived as being a project that would manage inventories within the chassis environment. Since our development, this has moved to a chassis pool organization. That organization is cooperating with us to share information to eliminate unneeded trips. Finally, the Real Time Traffic Monitoring component is where some of our private data was brought in to focus on the improvements. The Dynamic Route Guidance focuses on how we can improve in-route transit by giving drivers information to be able to make their delivery times.
I will quickly give you an operating scenario of how this may work to get everyone familiar with this and then we will go into more detail. As I mentioned, the information has to be exchanged so we bring the information in from rail terminals here that sent information in which focuses specifically on movements between the terminals. From that point, the information is sent out to the drayage company that has to complete the movements. We can send this information directly to the dispatcher or use the Wireless Drayage component to send the information directly to the driver. Now I want to emphasize the design that we have put forward does include a driver distraction capability where we lockdown information that can be sent to the driver if the truck is moving, they cannot use the device. We will go into that in a few minutes. The next step is the Real Time Traffic monitoring piece. Now we get information about what is taking place, any incidents on the route that may cause a problem with the traffic time. From that the driver begins the journey to the first terminal; they have their instructions and work order to pick up a container at this first terminal. Paul will emphasize this routing piece in his presentation. If there's any problems in the route the driver would be rerouted, he would get that information through an audio file in transit. Once he's arrived at the terminal, he picks up that first container and moves it to a second terminal. This is where we identify the information sharing. Previously that driver would have basely returned either back to the location he originated or to another location as a bob tail. We've been able to coordinate the information between these terminals to indicate there's a cross-town at terminal 2 that needs to be taken to terminal 1. He can receive that information over his wireless device and return back to terminal 1 with the container to drop off. At this point if there's no other information we've taken another step to start including information about the local deliveries to distribution centers, warehouses, or directly to customers to take the container and unload it. We could merge that information in and give it to the drayage company so they can make a move from that rail terminal out to a specific industry or distribution center, warehouse, whatever. This is really the concept: sharing that information, making it available, making the transportation connections between these different entities so there is no missed trip or no bob tail moving without a container.
From this, I will turn it over to Ron to really talk about the first few components, the IMEX and the Wireless Drayage Update and Chassis Utilization Tracking. Afterwards, we will turn it over to Paul to talk about the Dynamic Route Guidance.
Jennifer Symoun
Thank you. Ron, you can go ahead when you are ready.
Ron Schaefer
Thank you. Welcome everyone. What I will do today is drill down into more technical aspects of the different components. As mentioned, the goal is really to eliminate bob tail moves and the component which we do that is through the Intermodal Exchange, IMEX. This is the core to the system; all of the data from the components passes through the IMEX module. The second component is Chassis Utilization Tracking. The original plan was to maintain a chassis inventory. Since the start of this project, the chassis pool is now being handled by the Midwest Chassis Pool in the Kansas City area. Now we're getting files from the chassis pool operator; they're giving us what moves and what repositioning needs to take place within the area.
The next component is the Wireless Drayage. On the next slide I will show you the architecture of the entire system. Just think of the iPhone, all the information being distributed to the driver and returning back to IMEX is all done through the WDU component. The Real Time Traffic Monitoring collects the information from the roadside sensors. Paul will go into detail on that, as well as the Dynamic Route Guidance.
The next slide is pretty much the architecture of C-TIP, not to scare everybody. As I mentioned, the core is IMEX. All of the arrows in the system, everything is pointing to and from the IMEX database. The architecture is based on a previous project called Electronic Freight Management. It is a service oriented architecture. This application is built on that architecture. It's working very well. The next application is the CUT, that's where we collect the chassis pool information. You can see the different messages that are being transmitted between the different applications. We are getting a file from the chassis pool operator that is telling us what chassis need to be repositioned. It could be any of the rail terminals in Kansas City; it could also be at the container yard. It's a variety of locations. We're getting that information through the chassis pool operator. The railroads are providing us the information of all of the containers that are offloaded from the train throughout the day that are going to need be moved cross-town to another railroad. We're dealing with the Union Pacific, BNSF and Norfolk Southern.
That information is being fed into and out of the IMEX. The cross-town trucking companies there, that information from each trucking company can be put into the system showing their capacity. Maybe on Saturday they only have two trucks available, but five trucks the rest of the week. This information can be put that into the system to determine their availability for any truck moves for any given day. We're getting information that includes the industry moves. Randy talked about the cross-town, a potential chassis move and industry moves. He was showing what the truck driver was doing between each of the different terminals or nodes. That's all being controlled through the program being run in IMEX. The way we're able to reduce bob tails, reduce the empty moves is through optimization. The data feeds that are talked about run through an optimization program which allows each of the truck drivers to receive a work order. It will describe their day for them, the moves they need to make from point A to B, B to C and so on. We're optimizing that information for the truck driver.
Paul will talk about this, but the RTTM component is Real Time Traffic Information as well as the Dynamic Routing Guidance. That information is pushed out to the driver via the iPhone. We are using a phone gateway that allows you to write applications to any type of smart phone. We targeted the iPhone because it allows us to lock the phone when the truck is moving, so the driver can't use it, although we can continue to display information to them. The gateway product will allow us to move from the iPhone to the Droid or any other smart phone. You can see the information, the work orders, traffic information and the route sent from IMEX back to the phone. This is the architecture. It's a lot of information being passed. IMEX is the core of the entire system, again. Of course, the iPhone is displaying the information to the driver.
Moving on, I will quickly go through and show you screen shots of what the system looks like. From the railroad perspective they can view any daily in bound and out bound cross-town moves. They can view the optimized plan for movements of containers between the rail terminals. Then they will assign the container to a particular drayage carrier. This is probably a little bit hard to see. In the lower part of that screen shot, hopefully you can see the green arrow, based on this information that we received the optimization that we did shows five movements that were coordinated that would have saved five bob tails from being put on the road. There was a saving of five movements there that we were able to coordinate through IMEX.
The next screen shows the trip assignment. This is where the rail carrier assigns a box to a dray carrier. The railroad will assign that move to a truck carrier. Then, the motor carrier can look at the containers assigned by the railroads to them. They can look at it on the server or on their iPhone. They will look at their optimized plan for the day. They can accept or reject moves. They can assign it to a driver. They can also look at traffic conditions. This is what the motor carrier could see in the office as far as moves assigned to them and whether or not they've accepted the moves.
The railroads would manage their profiles. They would put in what capacity they have on any given day and also they can put in any temporary capacity. If they have five trucks, but one day they have twice as many trucks, they can put that all in there. It becomes part of the optimization program. They can manage user profiles and terminal information. It's very flexible. I apologize that you can't see this too well. It shows the various moves that have taken place between the terminals. And then on the next screen what we've done is shown the total move summary. Total moves that have taken place, the number that were empty, this number at the top shows the number of bob tails that were eliminated because of using the C-TIP application.
Now I will show you what the iPhone application looks like. We would set up for each of the drivers the device ID. It will say this driver has this device in his truck. The next screen will show the status profile. These are the different statuses that the driver that could be set up. It would include in gate, loading, out gate and whether or not he's unloading. On the right side here shows that we can update the status to display other messages. The route profiles you can see there on the left-hand side. On the right-hand side it's showing how we can key in addition routes. This is where the driver would request all of the work orders that have been generated from IMEX. He then would have the option to view them and send in a trip status back to IMEX. The right is showing the work orders that were downloaded successfully to the iPhone. If you would want to look at any particular orders for the day you can see on the left-hand side here this EIS work order, the right-hand side shows all of the information he needs to pick up that container.
Send status, this is showing a load. He's picked up the load. He has entered that into the iPhone, the information is sent back to IMEX for processing. For traffic information, this is where you can receive real time traffic information. This just shows that we're collecting GPS information. We're pulling it every 30 seconds right now on the iPhone. If we want to select a particular route to figure out the exact travel time they would select the route. On the right-hand side it shows that route two there the travel time is 31 minutes at that given time. You can see on the left-hand side the primary and alternative routes. If the alternative was selected then it would show up on the right-hand side. There also are audio files that are provided that would announce what the route is.
I guess that's my last slide, Jen. Anyway, that's the application, the architecture, and the demonstration of what the system looks like. Now I will turn it over to Paul.
Jennifer Symoun
Paul, we will turn it over to you. If you have questions please type them into the chat area.
Paul Belella
Thanks. We've been doing this road show for quite a while. It's still pretty interesting stuff. Every time I see it I think of different things to bring up. I will share with you more detail about the Real Time Traffic Monitoring and Dynamic Route Guidance components. I will give you a quick overview of the concept itself. I will break into each of the two components, show you the functional layout, and then I will let you see how it's intended to work and how it appears to be working. Then I will share with you some closing thoughts about things that are very important to make applications like this successful. The real primary point behind RTTM and DRG combined as a group of services is to make tailored information about traffic on the roads and travel times available to motor carriers to address goals like reducing delay and mitigate congestion. Major components were the RTTM module and the DRG module. Our primary role was designing and implementing these two modules in Kansas City. These are two of several components. As we've been working down at the detail level on this we tend to lose sight. We are often asked questions such as can't you buy something off of the shelf to do what you are doing? You can for some things. The real power in what we're doing here is in the way that we are developing and deploying these solutions on a service oriented architecture with open standards and having each of those components so fully integrated with each other, yet able to stand alone in many ways we're offering up an entirely new way of offering services to the freight community that allows them to layer in capability it's and functionality as they see fit for their operation. As you can see from what Ron presented, the ability to go from accepting a load to finding out what the traffic is on that route without going through and entering in origins and destinations and knowing that the information fed back to you have been is vetted and that the travel time information is not only information about current travel times but what they're predicted to be into the future by the time a truck is likely to get to a downstream point. These are useful capabilities. We're excited about it. We've been at this for a while, as Randy said. We go way back on this, since 2004. At time it's good to refocus back on what we are trying to accomplish.
At a very, very high level Ron mentioned that we're using an iPhone. For the RTTM and DRG systems to function, the iPhone is a focal point. It provides information to the systems that is critical for delivering the functionality. It also provides a mechanism for relaying information back to a driver. One of the things that were talked about early on was the need to keep the cost of access, the ability to become a subscriber of the system, to keep it as low as possible. The idea of using a smart phone with straightforward and simple applications on that phone would help to make this solution more accessible to the kinds of motor carriers that operate in the intermodal environment. The cross-town environment is similar in many was to a port environment. You have a lot of operators, very small numbers of trucks in their fleets, low technology budgets and limitation on the technology capabilities in the companies. Smartphones were a great option. You just have to define a way to communicate with this phone, extract information from it and deliver information to it about what is happening on the roadways so you can make an effective use of the technology and control the price so it's accessible to the maximum number of folks as possible. The RTTM component of this, they are separated and for good reason. I will just talk about the RTTM first. It has several components.
It provides the database for the traffic-related information that is collected and distributed, it does several other things. First, it's a telemetry processer. We get information from the iPhones, we get location, we get heading and speed passed along to us from the phone every 30 seconds. We can locate the trucks on the routes of interest during the project. And it helps us, at some point in the future when the number of phones starts to multiply, it can provide a significant bump in the volume and quality of information about the actual traffic on the roadway. The number of phones in this test is small. We're not relying on them to supplement our travel time information, but that's a distinct possibility for the future. It would add another layer of value should the deployment expand to a level necessary to make that happen. It also includes traffic interfaces. We receive information from KC Scout. This consists of point speed data. We take that data for the roadways that we're covering for the project and calculate link speeds and travel times. Link speeds are the average speed on a roadway and the travel time is summing the time it would take to traverse the links for a vehicle.
A traffic report generator is where we formulate trip reports. You saw from Ron's presentation that a driver can choose an origin and destination pair. We take a pair and look at a primary route that the carrier has identified, we look at several other alternative routes that are viable for trucks to use and we use that to calculate current travel time calculations within RTTM. We'll talk about what DRG does in a minute. Finally, the IMEX WDU interface, we receive a request a request from the wireless device through IMEX and process the request and send information back out through IMEX to the trucks.
DRG, the idea is to extend that functionality and provide navigation information to trucks that look at predictive travel time information. Instead of just saying we looked at this route and right now adding up the travel times it will take 20 minutes, RTTM uses probabilistic calculations to determine what that route travel time is likely to do over the course of that trip. Normally its 20 minutes then DRG looks ahead and says when the truck reaches this link what travel time on that link likely to be? This is based on both historical and current information. One of the real challenges here is it takes time to build up that historical information. Using that approach we should be able to determine a best route that offers the carrier a safe passage meaning the roads are appropriate for trucks to travel on that will get them as quickly as possible. Going back to what we said earlier, the fact this is fully integrated within C-TIP helps expand its value.
Real quickly, this is a functional layout to put in pictures what I mentioned. In the center you have the RTTM and DRG applications. You have the WDU application which offers an interface to the trucks out there. We can send information to them and get information from them. We're getting traffic data from the third party directly into the application here. In this case this is NAVTEQ and then traffic management center, in this case KC Scout. These all are relative and the idea is we're using standard ITS terminology, we're using transportation standards, we're using service oriented architecture, web services, and all the sorts of things that Ron talked about. We're applying the same principles across the board to connect these sources of information. The idea being if in some point in the future the third party is changed and they're more equipped to give data, you can use them too with the same interface and all of the design points are fixed.
How does it operate? At a very basic level what you are seeing on the screen is a Google Map overview of the Kansas City area. I'm hoping the animation will work here. Here comes the truck. At point A, the driver can enter the destination and request traveler information. At that point RTTM and DRG in combination execute their trip calculations for the primary route and the alternative routes. The blue route is the primary route. The red route is alternative number 1 and the yellow route is alternative route number 2. It offers advice back to the phone about which route will be the shortest trip in terms of travel time. The system is set up now for this purpose. A difference between this system and off the shelf system is that you can customize this. Let's say that you are a carrier and fuel is back up at $5 a gallon. You are concerned about the fuel cost more than the time of the trip. You could do those calculations using this and set it up so you have the best fuel economy trip as your goal. Or the most important thing is meeting a train cutoff time because this is a late pickup. The system could be con figured to tell you the odds of each route getting you to the cutoff time before it arrives so that you don't have to take that load and store it somewhere until you deliver it the next day. They get this information at the origin.
Next, the truck starts on the trip. As it comes within three miles of a decision point, a decision point is simply an opportunity point for a reroute. There are several of them for each route. The idea here is it's a logical and likely beneficial alternative route for that truck to take. As we are receiving the information from the phone, the RTTM is calculating position in relation to the next decision point. Within three miles of the decision point, we call it a reroute point, the device requests travel information. At that point, a trip calculation is executed and returns one of two responses. The default response is to remain on the present route. That mean the primary route remains the best route between origin and destination. The alternative is an audio file which is played that says that there's a faster route to the destination. It will give them an abbreviated list of roadways to take. It may say at this decision point on the map, using the example where this vehicle is traveling north on I-29 to divert on to I-35 and proceed to I-435 North and them basically resume the route. The driver would get audio directions. He would be given guidance for the remainder of the route at any remaining decision point. In this case, there are not any additional downstream decision points. It's important to note that the audio direction was used because FMCSA is very sensitive to distraction issues. It was determined that an audio file is less distracting than a map display on a relatively small phone screen.
As the truck continues its trip, the device continues to report every 30 seconds, a location, a heading and a speed for that device. For our purposes it doesn't matter which truck it's in. The device will be going from point A to B and as long as we keep track of it we can continue to evaluate the route as it goes. Each 30 second report is a request for updated information. We won't play that audio file unless it's coming up on a decision point. As mentioned earlier, the visual display is locked out and the driver cannot interact with it as the vehicle is moving.
That's the simplified overview of the operation of the RTTM and DRG. Ron had a spaghetti chart, so I felt I had to give you one too. The only thing I was to point out here is that this project is really about interconnectivity, using open standards to give access to get information to as many people as possible using one architecture and one set of technical standards. What you see here is just simply all the stakeholders in the Kansas City area and how they're connected to each other and to the system all using these sorts of open architecture and these sorts of standards.
So here are just a couple of slides to wrap up. There are some real important factors to keep in mind that will drive the success of this project. You have to have the right data. If you don't have the right data and enough of it or it is not accurate, then all of the things we're trying to do really will fall flat. The quality of what goes in absolutely drives the quality of what comes out. Packaging the data into useful information, the idea is to make sure that we're providing information that could be quickly interpreted and confidently acted upon. Making information available when and where needed and to make sure it's timely so people can make decisions quickly when they get the information. Some things that are important for DRG, we mentioned accurate data already and timely data. These are really critical to DRG. To be able to do predictive travel time models, these are absolutely essential along with reliable historical data.
I anticipate that over the course of the test and evaluation period, the quality of the DRG output will improve as that database builds. The accommodation for roadway limits, restrictive routes, and geometric constraints, I mentioned all of those. It is really critical; we've adopted this posture from the start. We have to make sure that safety is not compromised in any way, shape or form as a result of implementing these systems. The significant challenge we have moving ahead is validating the output from DRG. It's one of the big challenges that we have. How do you validate the accuracy on a route that you didn't take? That is something we are evaluating. DRG says that an alternative route is five minutes faster or ten minutes faster and a driver opts to stay on the primary route; how do you know that the driver was right or that it wasn't? Providing usable output to the drivers, again, we have the audio files. We're not necessarily convinced that long-term that is the best way to do it. We will learn over time some things about that.
Accommodating human behaviors, I mentioned drivers don't always take the routes offered to them. That's one of the things we have figured out here. We have one origin destination where drivers consistently select a route which is not displayed as the shortest route. This is one of those items that over time as this project migrates, we can sort through how to deal with. Finally, another item is getting the truckers to test the DRG recommendations. If you are working with a driver that has been working for 10 or 15 years, getting him to trust a device that tells him his route which he has been using over all of these years is not as good as another which he does not know as well. That is a pretty tall barrier to climb, but we are hoping we can accomplish that. With that, I will close. I appreciate the opportunity to share what we're doing here and I will be happy to answer questions at the end. Thanks.
Jennifer Symoun
Thank you, Paul. We will have the contact information for everybody at the end. Right now I want to turn it back over to Randy Butler.
Randy Butler
Okay, thank you Jen. This is a new methodology that we are experiencing with this project to bring it so we can get real-time evaluation information as the project progresses. Traditionally programs are done towards the end of the project where there's a large of data that has to be sifted through to come up with results. The evaluation for this project we're using software called Vantage which sits on top of the IMEX exchange and it has a specific group of metrics that have been developed for the project. So as the project is tested and information is exchanged and actual work is done it's recorded and those results are basically displayed in a dashboard to us. So I will ask Roger to introduce it, Ed will follow up with examples of how we're using this. Roger?
Roger Schiller
Thanks, Randy. Yeah, so I will just talk about what are the evaluation goals and get into the methodology for how we're measuring these things. The overall goal is we're trying to measure both the public and private sector benefits associated with C-TIP. From the public perspective, we're interested in measuring how many truck trips can be eliminated by the system. For example, if you are getting trucks off of the road there are going to be operational improvements for the rest of the transportation network. We would like to get a sense of what those are. We also want to find out the amount of emissions reduction associated with improving the operational characteristics of these drayage moves. From a private sector point of view, rationalizing these cross-town moves, avoiding congestion, and reducing travel time all carry improved efficiencies.
Here's my own spaghetti chart. This is the overall approach for the evaluation portion. We're pretty much done with the planning phase, which is task two. We have an idea of what we're trying to measure and RMI is putting the finishing touches on the performance modeling system. Then we will move into the baseline data phase where we will get the data feeds from SAIC to RMI and that will feed into the Vantage system and provide us an archive of data. From there we will move into the deployment to see what the difference between having C-TIP and not having it was.
These are the performance metrics that we're trying to measure. One thing that we're interested in is number of trips in load versus bob tails; this goes back to maximizing the productive moves. We are also looking at travel time between terminals and how much time are the trucks spending awaiting information processing within the terminal. Delay times in traffic due to congestion or accidents. Also, we are looking at emissions for those four items previously mentioned. We want also to calculate the level of compliance with work orders being issued. We want to get an idea of what level of compliance is occurring with the truckers. Are they accepting what IMEX is proposing? If not, why not?
Our overall methodology: we're identifying the cross-towns using data feeds. We will make some assumptions to identify the bob tail trips. Basically, we're getting gate move information from the railroads. If a truck in-gates at a certain time and doesn't out gate within a specified amount of time we can reasonably deduce that was a bob tail. Time savings is just a simple calculation of what is the typical route travel time and subtract the C-TIP route to find time savings. We have some EPA factors specific to the Kansas City area. They're based on distance and speed and we also have an idle factor. We can identify any idling emissions in traffic or within terminals. We have the factors for all of the criteria pollutants plus greenhouse gases. With that I will pass it along to Ed to talk about more about the Vantage system.
Ed McQuillan
Okay. Great, thank you, Roger. I will jump right in. Randy and Roger talked about Vantage, but one thing I would say is Vantage a business intelligence tool. It's different than other business intelligence tools because it doesn't just run a query against your data. It also pushes data out to the user. The user, without intervention or with an open dashboard view, that dashboard will be continually updated with new information without the user refreshing it. Where that is important is that as things occur and are reported into the database system the information is really any change in your database is a trigger and sends that information out to an open query or to an unopened query. You can have immediate update of that information through an alert or refresh of your view without asking for it. That's sort of one of the unique things about Vantage. It pushes data out to the user. Why was Vantage chosen? It has both the ability to provide the evaluation side and it can also assist in the operation and the plan execution here because of its immediate alerting capability. In addition, one probably valuable feature of RMI is that we also do the terminal management software for the UP, BNSF, and in a few weeks KCS. We have access to a lot of the data for these gate moves.
I mentioned the key features. It's an easy to use tool so that the people that are using Vantage to perform the evaluation don't have to go through a real lengthy process to learn how to use it. In addition to that Vantage can transmit information out to non-users as well, the alerts can go out to the non-users like trucking companies involved with C-TIP or the railroads or other external parties that may have some need to know about the availability of cross-towns.
Roger already went through a pretty clear list of what we're trying to measure. One reasons for using the Vantage tool is that the cross-towns and the bob tails are not necessarily readily available for identifiable within the railroad system. When a container leaves a gate and a trucker pulls out it's not clearly identified in most cases that he's leaving A to go to B; the driver knows this, but it's not part of the gate record. Vantage is matching the gate records from terminal A to B, which now are being received into the IMEX database. Vantage will also be used to look at the route compliance and the travel time compliance and comparisons that are part of the dynamic routing guidance and the real time traffic monitoring. As well as we can build calculations in that will allow us to make use of the number of trips and the travel time to deduce the emission factors and the benefits from the system.
This is an example of what the Vantage dashboard and tool look like. The panel on the left is what a user would use to navigate. That's where the queries are written. The drive metrics portion is where the user would take the results of a query and do calculations with it. Those calculations could be percentages; they could be multiplications that are using factors for different emissions issues. On any one of these gauges that you see there the user can actually click on the gauge and drill down to get the detailed information behind that. We show on in the upper right-hand side we show 11 cross-town matches. If I wanted to see what those 11 were, when they occurred, the detail behind them I can click on the gauge for the detail. The other thing too is that as the information changes in the database, the total number of moves changes and the gauge will keep updating. That might not be so valuable if you are talking about the total number of moves where it doesn't make much difference if it is 1233 or 1234, but some of the information on a gauge could be very critical and we can build in thresholds that will also attach alerts to those.
This particular dashboard shows some of those types of situations. In this particular case we're measuring the route compliance for six different lanes. Showing the total number of moves in each lane and also showing the percentage of times of the driver complied with the particular route information that he was receiving, whether it was to use the primary route or to use an alternative route. The gauges, if this were an open dashboard that the user had on their desktop, you see some of the gauges are in red because they've fallen past a threshold that was a critical area, and some are in yellow because there's a set of parameters that identified this as a warning status. As the gauge falls into that it will not only turn to yellow or red, it will also be flashing. It highlights the visibility for the user. They will be able to see immediately that some situation has taken place. For example, where this is critical can be seen on the lane 3 where the total trips are 63 and we have a low percentage of compliance. On a daily basis maybe a user wants to see what is happening on a particular route. If there's a lack of compliance on that particular route we want to find out immediately what the reason for that is. Are the drivers not familiar with the route? Is there something not valid about what we've assigned as the primary or alternative routes? Or is there something else occurring that we're not seeing within the other data? It's going to highlight it to us and give us that immediate visibility. Now that type of alert could also be sent to an email address or to a cell phone if you want to alert someone who is not actually looking at dashboard. They could have that capability to still be advised of this particular alert.
This is kind of a busy dashboard. What we're showing here is the emissions reductions in these same six lanes based on the number of trips and using the number of trips and the travel time times the particular factors that we've put into the formulas, it's resulting in each one of the results for a particular matter, or criteria pollutants. We can continuously keep track of the emissions reductions by means of these dashboards. The information can all be shown in Excel spreadsheets; it doesn't have to be a graphical view like this. There's a whole variety of different types of tables. These are summary graphs, but you can have a bar chart, you could have a pie chart, you could have the actual data showing it as an Excel spreadsheet. You do it here, or you can save the information into an archive so we can do analysis against that as well. That is pretty much it.
Jennifer Symoun
Okay. Thank you. I will turn it back to Randy Butler to close out the presentation. Randy, I will bring your presentation back up.
Randy Butler
Okay. First, I want to thank the presenters today. They've done an outstanding job of displaying the work we've been doing in the last five years. It has all come together. We're in the process of turning it on in the next couple of weeks. I did want to mention also that part of this process, pulling this project together was securing the funding to be able to do it. We were able to use seven sources of funding that originated with the Mid-America Regional Council with the Missouri DOT and the Kansas DOT on the RTTM side, the Federal Motor Carriers participated in the wireless drayage update. We've had development done with TSA, and that was moved to the Turner-Fairbank's exploratory research program. Our office has also contributed funds. We had to pull these different groups of funding together to make it happen. We are very excited about the upcoming events that will be happening over the next couple of weeks. What we're going to be doing is we've started doing load matching optimization. Some of the numbers that Ed was just showing you are from the optimization. We started working on the installation and training on the wireless devices back in October. We want to run the test through April of next year, 2011. During that test we'll be using the Vantage software to monitor the performance. It will give us an idea of if we're achieving the results and the tweaks we need to make. Hopefully we should be issuing a final report from our evaluator Cambridge Systematics by midsummer of next year.
Where do we go from here? We've been working to get this test going. One of the biggest next steps that we have is to understand what the requirements are to improve upon the work we've already done. We've gone back and are using the Intermodal Freight Technology Working Group to do that. And also we're going back to the Kansas City pilot participants to get their feedback. We're going to be look at where we can deploy this. Our greatest opportunity is in the Intellidrive area. We will be working to incorporate some of the ideas in Dynamic Route Guidance and drayage optimization, and freight traveler information into the overall program.
This is the contact information for all of us that are working on the project. If you have any questions specifically for any one of the presenters, please give us a call or email. I want to thank you. We'll open the floor for questions.
Jennifer Symoun
Okay. Thank you. We will start off the Question and Answer session now. We have some questions typed in. I think most of the questions are geared to all of the presenters, so I will let anyone jump in. The first question: I heard Randy Butler say that the iPhone was chosen because it locks while the truck is in transit. Does that lock happen automatically somehow, or does the driver do it? If the driver encounters a real-time traffic delay but can't pull over, can he use the phone? I presume he can use the phone if he breaks down, because at that point he'd be pulled over.
Randy Butler
The lock happens as the truck starts to move. If the truck is not moving the phone will be available for use. We haven't done anything in respect if he's idling in traffic. But in that case he could use the phone if he is stopped.
Ron Schaefer
The locking was programmed within the C-TIP application. When the truck starts to move we know that, that's what locks the application. Once he stops they can exit out of the application and can use the phone for whatever he needs.
J. Symoun
What percent of dray trucks are currently 'technology ready' and functional now in Chicago and Kansas, for example? What are the upgrade timelines in years?
R. Butler
Again, I want to emphasize this is a research project. There's nothing going on in Chicago at this time. What we're developing is going to be transferable and useable in Chicago and other locations. Right now our number of iPhones is really low. It's probably way below 10%. I don't know exact numbers. As we get additional funding or find additional resources to add more we will. We first want to prove the concept. That is the basis of the resource. Can we do this? Can we reroute trucks? Can we optimize these loads? Will it work? If we say yes it can work, and we have the full cooperation then we can go to the next step and add more iPhones to it and add more functionality hopefully.
J. Symoun
Going back to the first question, but I think you answered this. There's no way it can detect stationary idling, is there?
R. Schaefer
We can tell when it's moving.
J. Symoun
Okay. I understand RTTM is used for industry in Europe. How much of that previous work is being used as a starting place here.
Paul Belella
This is Paul. Let me back up for a second to the question about stationary idling. No by itself, the phone can't, but the important design consideration when we selected the iPhone is that it's a communications and computing device, it has multiple mechanisms for exchanging information. One thing that we've talked about and may come to pass in this project is you can attach devices to the engine's data bus that have Bluetooth that can connect to with iPhone. Theoretically, when the truck is sitting still the phone can monitor whether or not the data bus is indicating if the engine is running. Based on calculations you can build in about the power plant of the vehicle, you can calculate if fuel is consumed and the emissions being generated as the vehicle sits there. You have to create those interfaces and do the mathematical logic to make that possible.
J. Symoun
Okay. Going back to the question about RTTM?
P. Belella
I'm not sure how much of what we're doing at RTTM is done in Europe. In general terms, the accumulation of traffic information and the calculation of traffic times over a predefined route is not really anything cutting edge in and of itself. You could buy devices off of the shelf, Garmin or any other number of devices, that if you input the destination it will tell you how long it will take to get there and show the quickest route or other predetermined characteristics. This test was less about that than it was about integrating the multiple sources of information and tailoring it to the freight community and how it operates in the U.S. There's a lot of inherent background knowledge that comes from the experience that our staff has in those things. There's not nothing specific that I can point to from Europe.
J. Symoun
Okay. The next question is: will the cargo be identified so that another layer of goods movement is tracked?
R. Butler
Well, this is something that is very sensitive to the railroad industry. We've had to sign nondisclosures that we would not be tracking any goods movement at this time. It's very competitive information. It is scrubbed out of the data. The answer is no. No goods movement tracking with this project.
J. Symoun
Okay. Do reroutes account for existing and/or future roadway conditions such as weather, construction, low bridges?
P. Belella
The answer is yes right now to a certain extent. Construction, weather and those things to the extent they show up as variations in traffic speed on segments of roadway and are accounted for now. For the purposes of calculating the travel times, the nature of whatever the delay is less important than the impact that the delay has on the overall travel time. We're not specifically tracking weather or construction; we are taking real time information from the network that is reflective of the impact of those situations on the roadway travel time. In terms of things like low bridges or other route specific information, for this test we've constructed the routes to avoid these things just as a manual practice in the development. The idea would be that absolutely in a deployed situation you would want to build into the database the ability to prevent reroutes to locations that have low bridges or have limits, other things that are restrictive that makes it difficult. All those things you would want to build into a system so that you open up the possibilities for reroutes to a whole host of other potential roadway segments. One other thing you would want to limit or eliminate is trips through or bordering residential areas. We don't want to reroute trucks through someone's neighborhood because that would make this program very unpopular in a hurry. Hope that answers the question.
J. Symoun
Okay. Are there any safety-related performance measures?
R. Butler
No, not at this time. We have heard from our Freight Technology Working Group there's safety-related metrics that should be considered. We're in the process of looking at those. But at this time we haven't included any safety-related metrics to be supported by the project.
J. Symoun
Okay. I think Randy answered the question about how the program is financed. How do you deal with third party concern for confidential information regarding the shipments?
R. Butler
I dealt with that, with respect to the confidential statements that we had to sign. First of all, we ask the carriers not to send us any information. That's pretty much scrubbed before we get it. So we are trying to only look at the movement information that is required and keep that as part of our operating environment.
J. Symoun
Okay. What are the timeframes for the dashboards? Are they real-time, weekly, monthly, or annually?
R. Butler
They are any time you want to see them, they're basically updated. Ed, you want to answer that?
Ed McQuillan
The data on the dashboard is updated in real time. As data comes into the IMEX database, it gets posted to the dashboard. We're accumulating the information though to be able to summarize it on a weekly, monthly, or longer term basis.
J. Symoun
Okay. Does the emissions reduction software match with MOVES2010A?
R. Butler
You mean where the emissions factors came from?
J. Symoun
Not sure. If the person that asked that wants to clarify. We can move on to the next question while they clarify.
R. Butler
I think I know what they're talking about. I need to get clarification from people in our office. I think we're pretty much on track with that. I can follow-up with a better answer.
J. Symoun
Okay. They said yes, emissions factors.
R. Butler
The factors that we're using now came from MOVES. I don't know what specific version. We would have to follow-up on that and get a firmer answer.
J. Symoun
Okay, this is the last question we will have time to go over today. Do you encourage the trips to occur during off peak hours?
R. Butler
We haven't gotten to that point where we've set those parameters. When you look at Kansas City the volume is low, so it is really not an issue in Kansas City. As you move this project into Chicago, there may be a factor of some type of showing the benefits of moving the loads later in the evening, or during non-peak times. But it would be a future enhancement of the system.
J. Symoun
Okay. One last question came in: is avoiding residential areas a criterion that the routing software uses? Or are residential areas avoided only by making unobstructed ways easy to find?
P. Belella
Avoiding the areas right now for this test is done by not offering any roadway as an alternative route that goes through those sorts of areas. As we prove out the concept and examine DRG's times then we will start to look at for complex ways of setting up route priorities and opening it up so it's not just fixed routes. They will be routes which can be determined by the system on the fly. Right now we're just using fixed routes.
J. Symoun
Okay. We're about out of time. I think we will close out. I want to thank all of the presenters and thank you for attending today's seminar. The recording will be available online within the next few weeks. I will send out an email when it's available. If you are an AICP member applying for certification maintenance credits, this is not yet available on the website, but I will send out an email once that up. I also want to encourage everybody to download the evaluation form, fill it out and send it back to me. For those of you applying for credits, you can download the applying for credits instructions.
