Jennifer Symoun
My name is Jennifer Symoun and I will moderate today's seminar. Today's topic is Best Practices for Moving Freight Through Urban Areas. Please be advised that today's seminar is being recorded.
Today we'll have three presentations, given by Randy Butler of the Federal Highway Administration Office of Freight Management and Operations, Ron Schaefer of SAIC, and Paul Belella of Delcan.
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's education includes a Bachelor of Science in Engineering Technology from University of Memphis, Masters of Business Administration and Masters of Science Management Information Systems from Bellevue University , and a Masters of Arts in Transportation Policy, Operations, and Logistics from George Mason University. Randy 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). Mr. Schaefer was the chief architect of the Freight Information Highway Architecture based on a Service-Oriented Architecture (SOA) using Web Services and has since been the lead engineer of all FHWA technology projects that involved using the FIH architecture including the current Cross-Town Improvement Project (C-TIP). Prior to joining SAIC last year Ron worked twenty-seven years at Union Pacific Corporation. Ron has worked with various public and private stakeholders working groups such as IFTWG, IANA, NITL, and other government agencies including FHWA, FRA, TSA, DHS, Department of Justice [DOJ], Maritime Administration [MARAD], Coast Guard, Customs and Border Protection (CBP), port authorities, and various local and State governments.
Paul Belella has 24 years of professional experience in project management, business process reengineering, systems development, special studies, and technical and operational testing and evaluation. His experience spans 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. Mr. Belella currently manages Delcan's Freight, Trade, and International Borders Practice, and is providing project management, and technical support in three major program areas: 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.
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 now 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. To obtain your credits, visit the AICP Certification Maintenance web site after the seminar, login using your ID# and password, select My CM log, and select add credits. 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 Fee Structures Our first presentation will be given by Randy Butler of the Federal Highway Administration 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
Good afternoon to everyone on the call today. What we're going to do is walk through a presentation of the Cross Town Improvement Project currently in development in Kansas City, Missouri. I am going to give you a quick overview of the project and talk a little bit about its components. Ron Schaefer and Paul Belella will follow up with detail about the architecture and how the project is progressing and we will open it up at the end for questions.
To begin with, what we're going to cover today is a little background information about the project, the problem statement of how it was created, some of the users involved to create it, potential cross town improvement projects, the interchanges associated with the project, what the goal is, talk a little bit about the partner that is are involved, some of the logistics partners in Kansas City. As I said earlier, we're going to go through the components, and I will briefly give you a description of the component and how it relates to the project. I will give you a walk through of the operating scenario and how the project will work. Finally, we'll talk about next steps that concern when the project will be deployed and what we're looking for as far as completing the project next year.
Where did the concept originate? US DOT Federal Highway Office of Operations and Freight Management has been involved with a group called the IFTWG, Intermodal Freight Technology Working Group for eleven years now. This is a transportation user group that's primarily been focused on improving productivity, benefits through technology, primarily focusing on transportation network. We meet semi-annually with the Intermodal Association of North America, and the purpose of the meetings is really to get user feedback on what the new projects may be and how they would relate to improved efficiency in the transportation network. We review the projects that have been presented before. We talk about the ones that are under development, and we get additional user input. If any of you are interested in the next time this group meets, I would be glad to send you some information about it.
This slide goes back almost when I joined Federal Highway in 2003, we did a study of where the issues were associated with freight technology and what could be used to address the problems and the network and the bottlenecks. What we looked at specifically was in the transportation network we found that 40% of the time is waiting for the exchange of information between logistics partners. This is a huge target of opportunity that we have focused on in developing our technology projects, and this particularly the Cross Town Improvement Project is associated with this target area.
This slide shows a little more on the background. What is the cross town improvement project? You are familiar with the Chicago area, the St. Louis, Kansas City area. We have a place where railroads basically begin and end. The West Coast railroads end here and the East Coast railroads begin again. There is a need to do a rubber tire interchange between containers.
Sometimes in interchanging rail cars between rail carriers in large networks like Chicago, it takes two to three days, so what the railroads have chosen to do is basically deramp the container off of the rail car, give it to a drayage company and let them take it over the road to the next railroad terminal to take it onto the East Coast or onto the West Coast.
In the case of Union Pacific coming into Chicago, you have deramp taking it over the road and reramping it to an eastern railroad such as NS or CSX and taking it onto destination. This eliminates time it takes two to three days out of the cycle and provides the customer a better transportation connection with the container. The interchange this traffic must occur primarily like I said in truck derail areas and also occurs in ports and we have it specifically sometimes in airport situations.
The problem statement that we created with the group going back to Intermodal Freight Technology Working Group was the inefficiency of the cross town rubber tire interchange creates conditions that are adverse impact to congestion, efficiency of the transportation network, safety to the motoring public, environment of neighboring communities, and energy consumption.
What we have seen in our survey so far is that there are potential interchanges associated like I said earlier with rail to rail, port to rail, port to truck, and airport to truck. These are the locations that we have identified specifically this type of application could possibly be deployed.
The C-TIP goal is to develop and deploy an information sharing system that has the capability enabling the coordination of moves between parties to maximize loaded moves and to minimize unproductive moves.
We use this goal to really put together what the benefits were to each one of the entities involved in the transportation network. Looking at freight carrier specifically, the improved efficiency, higher productivity, better labor conditions. The goal of trip production could also improve the supply chain, lower prices, better supply chain performance, and reduce transportation costs. It improves competitiveness, enhanced quality of life, greater attractiveness and improved business environment. Finally, the public benefits on lower traffic volumes, reduced congestion, better safety and environment.
The components we have are five specific components. We have the Intermodal Exchange (IMEX) which I consider really the heart of the cross-town project. We have a Wireless Drayage component (WDU) that will be used to update information to the drivers. We have a Chassis Utilization Tracking module (CUT). These three areas Ron Schaefer will address with his discussion of the architecture and how these projects are progressing. We have a Real Time Traffic Monitoring module (RTTM), and a Dynamic Route Guidance (DRG) model that Paul Belella will discuss.
Briefly on the Intermodal Exchange, the basic concept is have an open architecture allowing collaborative dispatch management model among rail lines, truckers and facility operators. Basically what we're talking about is an exchange allowing railroads and facility operators to exchange information. Now, we're not talking about open exchange where everybody sees everything, only the people that are allowed to see the information and have agreements in place to share that information will be exchanging it.
Wireless Drayage Updating component is a platform that will be developed to send out messages or drivers. We will deploy best practices, so driver distraction will not be an issue here, and we're in the process of developing that. It allows the carriers and drivers get quick exchange of information with time sensitive shipment information. The Chassis Utilization Tracking is developed a process and system to commonly manage a shared intermodal chassis fleet. Currently we're working with consolidated chassis management group to exchange information about repositioning chassis in the chassis pool.
The Real Time Traffic Monitoring piece gives real time information about traffic, delays, incidents, and gives the operator of the drayage operator information on routing and scheduling between these trips as he arrives at a terminal he picks up the container he will get information about his destination, what incidents may occur and how he may reroute around it. That's more the dynamic routing.
I am going to hold most of these to Paul. He has a better description exactly how this works with the dynamic routing capability. Again, this was a public private partnership we have been working on the last four years. The key players in Kansas City we got all of the railroads involved. We have been acting as the facilitator and convener from the Federal Highway. We have actually given produced some of the funding associated with it, the U.P., BNSF, NS, and KCS have been involved and currently providing data and have trucking companies involved, some of the drayage companies, the two state governments involved, the MODOT and KDOT have been active in helping us, the metropolitan planning organization, Mid America Regional Council provided funding primarily in the air quality act, and we have had the economic development group, the Kansas City SmartPort that has been a strong support for us as we move forward. KC Scout has been working with us, the traffic management organization. This has been a very strong public private partnership working together in order to achieve the goals of trip reduction of the intermodal community.
In this operating scenario I will walk through, give you a quick overview how this would work, specifying specifically the Kansas City area and we'll walk through how the information will flow between all of the partners. To begin with, in the information flow the information about the containers available to move between rail terminals is pushed to the IMEX, the heart of the system, where the information is kept. From that we can produce a work order for the carriers so they can move the containers. This information is also available through a wireless drayage component I talked about earlier.
We make also available the real time traffic information as it occurs, the incidents, accidents, delays in the traffic network, so that is produced at the time that the driver begins his route to pick up the first container. At this time as the driver moves through his route, we will be able to employ dynamic routing to the driver in case there is an incident that he can route around and be able to improve the efficiency of getting to the destination to pick up the first container.
So now he arrived at the first railroad to pick up a container. Once he is there, he begins a trip over to the second railroad where he will drop this container off and deliver it. This is really the efficiency that we want to gain in the next step. In many cases a drayage company will not have any information to bring back another container or to move anything out of the railroad to container terminal so at this time we will have the information possibly of either a chassis or another container to move to another terminal. This is from sharing the information between all the entities involved.
The drayage operator would pick up another container and take it back to the first terminal, so now we eliminated one trip through this process. Again, back at this terminal may not have any information. He may leave that terminal in a bobtail empty mode and we could also furnish additional information either on a chassis move or an industry move where he could take the next move to industry.
From this process here if everything is correct we have eliminated two moves by improving the efficiency, sharing information, and making sure all the parties involved here have the correct delivery information for the containers.
What's our next step? With Kansas City we have been working for the last year doing the development. Ron's group and Paul's group have been focusing on developing the system. We should deploy by the first of May of this year and conduct an operational test and we also have evaluation software in place that we'll be able to see if we're actually eliminating trips and being able to measure that efficiency as we go forward in the test. We're going to continue our user conferences. We have been doing these throughout the entire project. We continue to get information and feedback from the users involved here, and especially in Kansas City the pilot participants have been very active in helping us understand what we need to do in order to make this a success.
Then we're also going to be looking at other opportunities. As I mentioned earlier, the ports, the inland ports, the airports, how we can take this same concept and adapt it to their types of operations in the local communities, and again our real purpose here is to eliminate that trip and improve the air quality and improve the efficiency of the transportation network.
I am going to hold off on the questions until the end and turn it over now to Ron to talk about the IMEX and the Wireless Drayage and Chassis Management System.
Jennifer Symoun
Thank you, Randy. Again, if you do think of any questions, please type them into the chat area, and then we'll get to those at the end of the seminar. As Randy said we're now going to move onto Ron Schaefer of SAIC. Ron, if you give me a second I will get you back to the beginning of your presentation.
Ron Schaefer
Thank you, Randy and Jennifer. What I am going to do is talk to you a little bit about the overall project, essentially where we're at, essentially where we started, and our development to date, and try to get into a little more detail about each of the different components that the C-TIP project is made up of all of those components. Basically, it is going to be one system that's going to be residing in one location, no matter which component we're talking about, whether it be the IMEX, CUT, DRG, so when we talk about C-TIP, it is all of those modules together just to make sure everyone is aware of that.
I am going to go over a little background but Randy pretty much covered that already, talk about who is participating, recent activities, our current development status, what we have planned, the schedule, and also give you a sneak proceed view of a few of the screens we have developed up to this point.
As Randy mentioned, the problem statement really has to do with congestion, efficiency of the transportation network, safety of the motoring public, environment of neighboring communities and reduce energy consumption.
Up to this point we have Union Pacific, Burlington Northern and Santa Fe, and Norfolk Southern participating in this project. KCS is not participating because they don't actually perform any cross towns within Kansas City. Their operation is set up differently. We do have to get letters of authorization from each of the carriers which we have. Due to the events of 9/11 you just can't collect data from rail carriers or truck carriers without getting authorization letters signed. We'll be getting information directly from each carrier and also through Railinc as well. Railinc is the data provider for all of the railroads, Class I's, as well as the Shortline railroads.
The dray carriers we're working with are ITS, Lake Country Logistics, and Comtrak. All of those have operations in Kansas City, and as Randy mentioned as well, we have local and regional stakeholders such as MODOT and KDOT. KC Scout is providing traffic information, which will be part of the real time traffic monitoring component and also KC Smart Port and the Mid-America regional council are stakeholders.
The activities as Randy mentioned for this project were going on for a year or so. There was a lot of prep work done first, just getting all the participants together to agree to the concept of operations and so on. From a software development perspective, we essentially started it in the September timeframe. We hope to get everything wrapped up by the end of April and then we'll be starting the pilot in the May timeframe which will run for about six months. At this point we have had to reengage the motor carriers a couple of different times essentially because we go out and we present to them our thoughts and the way the system will work, we get comments from them, go back and do a redesign and come back and confirm all of that with them. We have done that a couple of different times, both on the RTTM, the DRG and the WDU.
We had kickoff of RTTM and DRG as recently as October. We have just started receiving data from the railroads, the Union Pacific, Burlington Northern and the NS. We actually started getting data feeds from another participant that's providing information for two of the dry carriers, IXT and Lake Country Logistics through their product called Profit Tools. We're getting data fed from them to get the industry moves mapped and from the chassis pool operator in Kansas City so we can get chassis moves within the C-TIP application as well.
A part of some of the funding for this is actually coming from Federal Motor Carrier, and we evaluated a product called Escape EZ collecting emission information off of the engines. That information also will be fed from the diagnostic equipment on the truck motor and sent the iPhone which is the device that we selected for the Wireless Drayage Utilization component. We are using the Apple iPhone and teaming up with a company called Vavni that has a gateway product that will allow us to not only provide the information from our WDU application to the iPhone plus their gateway product will allow us to actually take that application and put it on any type of smartphone or PDA. As far as this project goes, we're focusing primarily on the iPhone, which will be the device in the cab mounted on the dashboard. The iPhone will be collecting and providing all the information that we are essentially pushing through on the IMEX and the other components for C-TIP.
As far as the current development status, we pretty much have completed most of the coding for IMEX in December. We have started receiving the data feeds from the railroads. We have completed our detailed design document for IMEX and should have everything completed by February which would include the design for RTTM and DRG. RTTM and DRG because of the funding and the contract was not executed until October/November timeframe, those components are lagging behind the other components that we did get the funding for, so once we get the design for RTTM and DRG all completed, that will be a part of the C-TIP design document.
CUT requirements and preliminary architecture has been complete. We pretty much finalized the data requirements that will define the information we'll be getting from the chassis pool operator and we actually have started receiving data from them. We hopefully will get that turned on in production mode shortly. On the WDU side as I mentioned we're using the VMAP mobile gateway product and will have 15 to 20 iPhones out there installed in each of the different companies tractors. As I mentioned we'll be using the Escape product. The evaluators will take the information and run their analysis on it.
Development is under way for the interface through the external devices, the iPhones. RTTM as I mentioned we had the kick off back in October. The assessment of the trucking company requirements, making sure it is in sync with the WDU. Essentially the information and the DRG, all that data is going to be populated onto the iPhone which is a function of the WDU application. Sorry, too many acronyms here. For DRG we have engaged the services of Georgia Tech to help us write the algorithm for the dynamic routing. That system design is under way, and as you can see the use case business rules have been completed. Paul is going to talk in more detail about both of these two components.
As far as what we have upcoming, we'll complete the testing for IMEX in the March timeframe. For WDU like I said we have the development already under way with Vavni and we have not ordered the iPhones yet but that will be taking place here very soon. We need to finalize exactly all the information we'll be collecting from the engine mounted devices, the Escape EZ, engine parameter information. We are to meet with the evaluators to determine what information they would like to collect off of those devices. With CUT we have pretty much really gone through the refinement, the user requirements, and which was being driven by the information we could get from the chassis pool operators.
For RTTM and DRG I am going to let Paul pretty much cover those items. The schedule as shown, from the application development perspective you see IMEX is complete in December, CUT next month, WDU the month following in March, RTTM and DRG completed in April/May timeframe. You can see the dates for the testing all pretty much in March/ May timeframe, and then the US DOT design review will be held in late February after we get all the RTTM and DRG components included in the design document. We'll be going through training in May and the deployment test will run from May through December of next year. These are just some screen shots of the application. This will be the front home page, essentially you can see we'll have a brief explanation of each of the different components, to make sure they understand what the capabilities of the application is and then we have the user ID and user name and password log in. This is a terminal administration screen that shows all the terminals, what the number of loads and unloads there at that West terminal currently, number in gates and out gates. Obviously this is all test information here that we have in the screen shot, but you can see there that we are showing all the terminals that are part of the C-TIP application that are included. This all takes place in Kansas City, so you would see when you log all the rail terminals that are participating in C-TIP would show up on this particular screen here.
The capacity administration, this is a screen that allows for each of the carriers' capacity. On the left-hand side you have the default capacity, number of trucks available and so on. This is for Greer, the actual dray company working with us in Kansas City. Normally that's what he could take on a day-to-day basis, but then on the right-hand side it shows if for some reason he had more trucks available on a particular day, he would put that into the system as displayed there. If you just can imagine that capacity constraint there would then be used as part of the overall optimization that when we run it, we can see Greer has more capacity on these particular days and may be able to change the optimization as far as who is going to be picking up what each terminal.
This is a Motor Carrier Work Order. What we're trying to do is as Randy mentioned eliminate empty moves so you don't have bobtails running across town without a load. Based on all the information we're collecting from the rail carriers and the dray carriers, their respective capacity, we run optimization and display a work order which would be available for each driver. They would be looking at this on their iPhone through the WDU application, and would tell them the type of moves that they have for the day. You can see there that will be a cross town or last couple of line entries there show the chassis moves that they would have.
In this particular example on the first line you see that there is the driver would go from KCS, Missouri, to the U.P. yard. You can see what the cut off time is, when it was accepted, the estimated out date is the time it would take to get through the gate, and transit time there. Also displayed is the time to get into the gate, the actual out gate and in-gate times there as well. From there you would then go over to the BNSF yard, drop one off at U.P., go to NS, pick one up at U.P. and so on. This is going to be the work order for the driver telling him what he needs to do from the time that he gets in the cab in the morning to the end of the day, routing out everything in order for that particular day. Once he picks up the work order from the iPhone he will select a key that would send the information back to the IMEX that states he has picked this load up or has unloaded that particular box.
These are the trip assignments, container and chassis moves that you can browse through on that screen. You can see the type of move it is, chassis or cross-town, equipment IDs, the equipment, the container ID, the proposed trucking company that would be recommended through IMEX's optimization and then the next column there shows exactly who was assigned, what the status is, the time when it is unloaded, the cut off time and so on.
With that, there are more screens but those are some of the highlights there. If you want to get more information on the project and all the project management information that we have on this, the schedule and all the documents, those are all available at www.CTIP-US.com. Again, my name is Ron Schaefer. There is my information. We'll turn it over to Paul.
Jennifer Symoun
Thank you, Ron. We're now going to move on to the final presentation given by Paul Belella of Delcan.
Paul Belella
Thank you, Jennifer. Also thank you to Randy and to Ron for all of your remarks on the other parts of the project. Looks like we have about 30 minutes left to present and about another 30 minutes I guess for question and answer. I will refrain from attempting to use every possible second. I will make sure we get through the material quickly. As Jennifer has mentioned, my name is Paul Belella, a principle with Delcan Corporation, and Delcan itself is a transportation consulting company. We're primarily responsible as both Ron and Randy has indicated for the RTTM and DRG development, but just a side note we have been involved with the project since its inception in 2004. We have been providing support to Intermodal Freight Technology Working Group on an ongoing basis since then as a company and then before that, before I joined Delcan I have been supporting that group for quite some time. Seeing this project finally come to fruition, it has been a long process. I have less hair and hair that I have is grayer than it was when we started. I am sure Randy feels the same way about it. I know he has been involved with it for since the inception as well. I am going to share with you information about the component we have a responsibility for the development of. I will give you a little overview and then I will talk specifically about the two separate components, the traffic monitoring and route guidance component. I will give you kind of what we would call a visual use case of how the systems might actually function together, talk a little bit about the data and interfaces that will be necessary to support that, and then kind of close out with a summary of some of the important factors to the success of the RTTM and DRG support and where we are from a project status standpoint.
As Randy mentioned before, the primary focus of the C-TIP project has been to reduce unproductive moves. Now, that can take several different forms. The most obvious is to eliminate empty moves. Obviously an empty move is an unproductive move except from the standpoint it is required every once in awhile to reposition equipment to support freight movement.
Unproductive moves can also be a move that doesn't happen as quickly or as efficiently as possible. From that standpoint those involved with the move incur greater costs to do so and as a result quite often the case for shorter cross town moves, may actually be conducting moves at cost the companies involve rather than offering them profit, so the idea behind the RTTM and DRG modules is to reduce the likelihood that motor carriers who are supporting intermodal freight movement not just from rail terminal to rail terminal but in an urban environment to reduce the amount of delay that they incur by giving them information about what's currently happening and give them some idea of what would happen if they chose an option other than the option other than the route they originally scheduled to take, so the objective here is to make that real time information available to motor carriers to mitigate their own delay or to reduce their own delay and mitigate congestion on larger scale, and obviously if you reduce congestion, you also have the benefits to the environment.
The major project component for the work that Delcan is doing is design and development of RTTM module and the DRG module and the implementation of both of those in the Kansas City area. I will talk later as to why this is specific to Kansas City, but has applicability regardless of location.
Also, as Ron mentioned, all of these components are tied together. The idea here is to try to make an interconnected network of capabilities that cooperate with each other, that exchange information efficiently and do so in a way that makes the capabilities and the services available to the maximum number of potential users. DRG and RTTM as you have seen are two of several components that will be designed to be fully integrated with all the other modules, and certainly we're designing it so that ultimately it will be scalable and transferable to other locations such as the ones that Randy indicated on the map he showed to you earlier.
What you should be seeing on the slide right now, it is slide number 4, a schematic diagram, and I won't spend a great deal of time on this. I think the important thing that this image shows for the purposes of this presentation is that there are a whole host of different entities, organizational entities, and systems interconnected systems, that are necessary to make C-TIP as a whole work as it is intended. You will see in the center that we indicated four specific applications. Someone argued DRG is an extension of RTTM. I think it is a separate; it has grown into really be a separate module, but it is very heavily dependent on RTTM, so I hadn't indicated it as a separate application just as of yet, but that's really beside the point. The idea here is you will see a combination of private data providers, broadcast media, intermodal source providers, state and local agencies, businesses, systems all are being considered fully when it comes to the actual design and implementation of the C-TIP project as a whole and the RTTM and DRG applications specifically in the Kansas City area.
I throw this out as an illustration of just how extensive this reach of these systems is and just how important it is to make sure that as we're designing and implementing the systems we carefully consider the potential upstream and down stream implications of the information that we're capturing and disseminating. If anybody is really blown away by this diagram and wants to learn more, there is contact information at the end and I will be happy to talk to you more about that.
From an overall project standpoint, there are very important factors that we have been considering since the beginning and continue to be important as we move forward. I put them in three general categories. The first is collecting the right data. Obviously if we're going to provide traffic information and routing recommendations, then we have to have the right data. That data we use needs to be accurate in order to cover enough of a network in an area like Kansas City. We need to consider multiple sources and I will talk about what those are a little bit later.
We need to make sure we focus in on capturing and disseminating information about roadways, what we call roadways of interest, and for this project roadways of interest include those routes, those roadways that are legitimate routes for carriers involved in this project to take. In other words, if it is a narrow surface street that can't support truck operations, then we certainly don't extend a lot of energy trying to include that in our traffic information or routing recommendations.
The second is a packaging that data into useful information. Basically you need to be able to properly interpret the data in order to make use of it. That goes specifically applies to both of these applications in depth. You also need to formulate that information in a way that conclude acted upon confidently. In other words, if you're offering an alternate route or you're suggesting there is a significant delay on a segment of roadway, it is important that the information is accurate and timely so that decisions can be made by the network users and they can trust those decisions yield positive results for them.
Finally, making the information available when it is needed, and I am sure there probably is not a lot of reason on this call to go into a great deal of detail about how important timely information is when it comes to traffic conditions because as we all know traffic conditions can change rapidly, so we are focusing very heavily on trying to streamline the process, getting information to users as quickly as possible so they can formulate a decision quickly and act upon those decisions while there is still benefit to be gained from doing so.
With that I will go into a little more specific about what each of these components are. The RTTM itself and these, there is nothing magical about the names and they may or may not be the component element names that will go into RTTM, but just for the purposes of discussion, I think it is useful to break them out. The first component is what we're calling a Telemetry Processor. What this will include is the capability to receive data from multiple sources including the iPhones that Ron talked about earlier that are going to be installed in vehicles. We're going to be getting telemetry data from those vehicles and converting it for use in determining link based travel times and link speeds, average link speeds on the network. So a portion of the RTTM capacity will be used to process and utilize telemetry.
The next is KC Scout Interface. Ron mentioned it is a traffic management center there in the Kansas City metropolitan area. We will be receiving traffic information from KC Scout and to the extents that KC Scout determines it is of use to them, we will make available to them any link based travel time data we extract from the telemetry that will be received from these iPhones.
The next is Missouri State wide data which is another source of information about what's happening on the roadway network, our plan is to do the same with that as we will KC Scout, use what available the data that we collect from telemetry to pass along to them if they so desire it. What I will call the heart of RTTM is what I am just terming loosely the Traffic Report Generator, and the function of that capability is to capture all the telemetry and traffic information data to form to do two things. One is to establish a database, historical travel times on the roadways of interest, and then the next is to gather data and analyze it on an ongoing basis to determine whether or not there is a detectable deviation in travel time from historical norms.
Finally, the last and equally as important part is the IMEX interface. The way we decided to architect the entire system is the IMEX is the cornerstone application and all information will flow to and through IMEX for this implementation, but it is important to remember that we're applying web services based practices and that if there is a desire at some metropolitan area to implement any one or more of these individual modules without the others, because they're based on web services and using open standards and the FIH information highway architecture, you shouldn't need any one component to make the others work. They will be using standard design techniques.
That's basically RTTM. DRG takes the RTTM basic functionality and takes it one step further. I recognize a few of the names on the attendee list as folks who have been around long enough to know what DRG is and that it has been tried before with what I will call modest success, maybe that's being a little charitable about it. It has been a challenging thing to do, and I have been involved one way or another from projects that go way back to the very first DRG projects in the early 90s.
The idea here is to formulate an application that provides the users in this project which are trucking companies a means to determine whether or not they're on the best route for their operation. Now, that can be defined in several different ways. It can be defined just simply in terms of travel time, the shortest travel time from a current location to a desired destination, or it can be defined in other ways, and we're exploring other ways to do that for this project and those might include looking at the lowest cost trip based on fuel use and time consumed, and also looking at it from the standpoint of the risk associated with missing a cut off, particularly in an intermodal environment where goods are being delivered for loading onto trains. There are cut offs or limits as to when those loads can be delivered in order to make a train, for instance, that's one example, and this way the application we're hoping we'll be able to provide a driver information along several dimensions including the likelihood or the probability that a given trip will conclude before the cut off time happens and give them alternate routes to look at to minimize that risk.
What could end up happening is a route that is long mileage could end up being beneficial because of the likelihood of missing a cut off is significantly reduced. If a cut off is missed, what that means is a load will have to be transported to an off site location, usually a holding yard and held there over night and then an additional vehicle has to be dispatched to pick it up and deliver it to the destination the next day when a facility opens.
You can see that a missed cut off can create a lot of additional trips. Basically what will happen is this program will monitor and update the route as a truck approaches decision points, so if a truck is traveling on a trip between a predefined origin and destination, and they're approaching what we're calling a decision point where a diversion could be made, the system will be notified by the WDU unit that it is come within a certain radius of a decision point. That will trigger a recalculation of primary and alternate routes and the presentation of the results of that recalculation will be backed through and distributed to the driver at WDU. The project will build on the RTTM and WDU as we mentioned.
It is going to leverage the latest in dynamic routing research and practical applications. Ron mentioned that we have Georgia Tech on our team. Georgia Tech has been doing a great deal of research in this area, already defined the basic logic to make this possible, and our job is to operational lies eyes that and integrate it fully with C-TIP so we can deliver a concise and complete service.
What you should see on your screen now is a multi-component diagram that I will call it a 'use case'. It is a visual version of a series of steps that might take place, and it is just intended to illustrate all the connections and all the different directions of information flow. If you start on the right-hand side of the diagram and work left, you will see that there are several sources of information what's happening on roadways, those get fed into the KC Scout TMC or Missouri State wide data. Those two entities will communicate with the RTTM application, providing link based travel times and link speeds. The RTTM application will formulate as I mentioned before travel time information based on the parameters defined by motor carrier needs, and then we'll pass that information to the IMEX application which will go out through WDU to the carriers which is up in the upper left-hand corner.
In addition to that, as I mentioned before, plan is to use the iPhone as a vehicle truck telemetry source, data source, and that information will come from the units through WDU or potentially through a third party because there may be some intermediate processing necessary, go through WDU, right to IMEX. If it has to go through a third party it will probably come right to the RTTM application, and that information will be factored in with all the information gathered from KC Scout and the Missouri statewide data and translated into travel times for the links that are of interest for the carriers.
Then as you will see at the lower center portion of the diagram, the DRG application effectively hangs off of the RTTM application because it will use the historic and current travel time data that will reside within the RTTM database to performance functions and will also use RTTM as its communication link to IMEX.
So what you will see here again is a visual representation of what the high level data flow will be for the project. I am not going to walk through this at a detailed level. You should be seeing slide 9. What this is intended to do is to show the logic for how we would get from the data that will be received from the multiple sources which is up in the upper left-hand corner to the distribution of travel time information which is on the right-hand side of the diagram. You will see that there are trip records that are received, travel times calculated, and these are all going to be done for a subset of all of the origins and destinations that are possible within the region.
This project is not funded at the level necessary, and to do an entire network, so what we have decided to do to make this a practical undertaking is we have a limited set of carriers we're working with, and in this case for the RTTM and DRG components it is probably going to have four carriers. We're going to have a limited number of origin destination pairs which means it is going to be a limited number of terminals or storage yards or businesses industry locations that will be designated origins for trips, and then we'll focus on creating travel time profiles and travel time information for the primary routes between those locations and for a select subset of potential alternate routes. In other words, if we have a fixed origin destination and a primary route, we're not going to examine every single possible roadway that a carrier might take if there is congestion or a problem on the primary route.
The primary reason for that is that there simply isn't enough data available. Very few non-interstate miles, non-highway miles are instrumented in the Kansas City area, and the number of vehicles that we will have operating in the area with the WDU devices is small as Ron mentioned it may be 15 or 20, that we can't reliably capture what's happening on the entire network with such a small sample of vehicles. Now, with that said, if over time the data set improves in its scale, and its detail, then this, the applications herein will certainly be capable of adapting to increased amounts of information so that additional roadways could be included for RTTM and DRG calculations.
Overall just again just to recap some things and indicate a few additional concerns, we talked already about how important accurate and timely data are. That information needs to be made available very quickly. We also are really at the mercy of the level of reliability of historic data. Current data isn't a great deal of use if you don't have something to compare it to so that determination can be made if traffic conditions have changed significantly. I am sure that probably everyone on the call has seen the typical web-based maps that though congestion levels based on current travel times and that is travel times might probably come from a combination of fixed roadway sensors, microwave radar, loops, and also from probe vehicles.
The idea here is we have to have reliable historical data in order to have a sound basis for comparison. The alternatives calculation that will be done within DRG needs to obviously happen very quickly in order to respond quickly to user requests for that. Also, we recognize that we have to as I mentioned before, accommodate limits associated with the operation of commercial vehicles. There are certainly going to be entering sections, roadways, and other sorts of things that are wanted suited for trucks and the idea is to make sure we provide information on the routes that are suitable. Some of the significant challenges we recognize we face to it is project, the first is validating that the output from the dynamic route guidance module actually represents a better alternative than what would have normally been a trucker's route. The driver will either take the advisor not take the advice, and because he can only choose one of those, ultimately we won't be able to determine specifically what the level of benefit was that was accrued. We can estimate some of those things based on the level of confidence we have in congestion data, but validating it, in other words, letting the driver know that he made the right choice ultimately by taking the alternate route is going to be very difficult to do.
The second is accommodating human behavior variables. Truck drivers are humans. They will make choices that do not necessarily align with any scientific practice or desired activity on our part so it is accommodating those variables, and what I am talking about here as a for instance is if there is congestion on the primary route, it is uncertain what will happen with regard to the traffic as time moves forward, whether large number of vehicles will leave that primary route and con jest the alternate route just as badly. Those are the sorts of things that have been historically very difficult for DRG applications to accommodate.
Finally, the last is getting the truckers to trust the recommendations. We're going to be dealing with drivers who operated in the Kansas City metropolitan area for quite a number of years. They know where the historic trouble spots are. A lot of them do. And if you provide them an alternate route, there is just as equal likelihood they will say I know these roads better than you do, I am going to continue on my route or I am going to take a route that is not one of the alternate routes. Those are things that are going to be difficult to overcome within the limited scope of this project, but we'll do the best that we can to focus on them.
Finally, I just want to provide a quick update on project status. Ron talked about some of these already. We already started the development of the RTTM and DRG logic for the calculation of travel time, and we have already established the guiding principles and methods for assessing the alternate routes and how we think we'll do that. The design itself we have defined almost all of the origin destination pairs that we're going to use and the default and alternate routes applicable for the project. We formulated a high level design structure and we have been defining message content and structure as well. We also have to determine the best approach for obtaining and processing the vehicle telemetry both from WDU devices that Ron talked about the iPhone and also another trucking company who has offered some telemetry data, and then what is the methodology and tools will be for us to process.
That said, that's the conclusion of my presentation. I put all three contacts on this page that if you have questions for any one of us, please feel free to contact us. We'll be more than happy to answer your questions. At this time that concludes my presentation. I guess Jennifer we can go into the Q&A portion of the session.
Jennifer Symoun
Sure. Thank you, Paul. I will leave the slide up for a while so everyone can get down the information. We're going to starlet off the question and answer session with a question posted online and then once we get through these questions if time allows I will open up the phone lines for questions. I will start at the top and put the questions out there to all three of and you let whoever appropriate jump is in. Let's see here the first one. What is the average daily container exchange volume among the three class one railroads?
Randy Butler
This is Randy Butler. The largest one is Chicago. We put together a case study available on our website at www.CTIP-US.com that I believe it was 20,000 a day as I recall is the highest number we have seen in Chicago. Kansas City is much less, and St. Louis I think is a little more than Kansas City, but it all depends on how the railroads are operating and what type of contracts they have in place, so it varies. Paul, do you want to add something to that?
Paul Belella
I think there is has been recognition with accommodation of operational challenges and obviously the economy dropped, the floor dropping out on the economy quite a bit over the last couple years that the cross-town volume in Kansas City dropped significantly, but it remains a major problem in Chicago, and we chose Kansas City and I don't remember Randy if you mention that had earlier on or not, but we chose Kansas City because the volumes were lower, so we could do a technical proof of concept here, and that we wouldn't get ourselves in a situation of getting in and messing things up in Chicago so to speak. It is such a delicate system there that we're confident these factors prove out here if the systems prove out here they could accommodate the kind of volume seen in a place like Chicago which as Randy said I believe the numbers were around 20,000 a day. You can access the website. I believe another question will refer to that same case study we did.
J. Symoun
Randy, I guess this is more for you. There are no doubt the goals of this project are solid. Should the federal government really be involved in increasing the efficiency of the trucking industry?
R. Butler
Well, this is where I will refer back to what we were talking about earlier in my presentation and the Intermodal Freight Technology Working Group. This is where the federal government or my office has been very active in being the facilitator and convener. It is hard to get a group of people together, especially industry people to share ideas. I think that's where we have come in. We have also been a facilitator of getting funding. I know there is a question coming up about funding. We were able to put together I believe five different sources of funding from the federal agencies and actually we had some funding from TSA involved in this, so there has been an ongoing effort of really managing and bringing together the ideas present in IFTWG, continually building on those user requirements, and user inputs, and then working with the local people and I think it has been very successful so far.
Ron Schaefer
I will just add to that that granted I am not speaking any official capacity as a contractor here, but as we said before, if you can improve the efficiency of the freight operations in metropolitan areas like Kansas City, Chicago, Los Angeles, New York, wherever else, you're without a doubt going to provide some benefit to a lot of other stakeholders not the least of which is the citizenry in general, reducing the number of truck trip it is takes to facilitate load movement and that's more than just a noble undertaking. It is an essential role for Federal Highway Administration to help different locals under the options they have to reduce congestion, reduce air quality or rather improve air quality and reduce emissions. Then one point we didn't talk about was that there was University of Michigan study done several years ago that indicated bobtails, trucks not pulling a trailer are five times more likely to be involved in an accident, a crash, so there is a potential public safety benefit as well by reducing the number of bobtails on the roadway. My argument would be not only does FHWA or US DOT have a role they have responsibility in this area.
R. Butler
One of the slides we usually start off the presentation with is how the growth of the freight volumes over the next 20 years will basically almost triple and the only way that we can get some additional building capacity is very expensive, so to try to build some more efficiency in the network by using technologies like this, certainly helps with that growth of the freight industry.
J. Symoun
Have you quantified the expected environmental or traffic congestion benefits.
R. Butler
Yes, that is and I don't have it in front of me. It is available on the website, www.CTIP-US.com. It is under the case studies and Paul and his team wrote the case study and it specifically talks about the VMT, number of units eliminated with referring to the Chicago situation.
J. Symoun
Are cleaner fuels and/or lower-emitting vehicle technologies factored into systems?
R. Butler
We actually have funding from the congestion mitigation air quality provided to us through the Kansas City metropolitan planning organization that we're focusing on how we can reduce emissions, and we're actually going to be measuring that in our evaluation. What we're looking at not necessarily cleaner fuels but by eliminating trips we can eliminate so much emission.
J. Symoun
How does this work to avoid making truck drivers distracted by the new information fed to them you through an iPhone.
R. Schaefer
One of the reasons that we picked the iPhone is that we can actually shut it off if the truck is moving. The application will lock. Other than that, the information would be displayed similar to a Garmin as far as information you need to see but as far as touching device or trying to interact with it while the truck is moving, the iPhone will be locked so you cannot do that.
P. Belella
We may try to experiment with voice commands, too.
J. Symoun
How does this interact with the carriers that are executing contract shipping? How much of the industry is not ''eligible'' for C-TIP because of these contracts?
R. Butler
I really don't see where there is a factor in this. Anybody that is exchanging information and each one of these modules can be deployed independently, so if you don't use say the wireless or the chassis management system or the wireless component, you could use the real time traffic management piece. You could use the dynamic routing, so each one of these is individual modules, and they will be available for everyone to use.
J. Symoun
Are there any expectations on the lag from the data source to the onboard devices? Is there a performance window that the information must meet in order it to be useful?
P. Belella
I will take this. This is Paul. I think there is recognition that particularly from traffic information and routing standpoint that it is essential that the information be provided very quickly. We don't have a performance standard we're trying to meet necessarily. I think it is safe to say that if you go beyond ten minutes between when anomalies are detected and when they're reported to a user, then you're getting close to them being useless. What we're hoping for is that we are able to provide updates that include information that is less than 10 minutes old. That's a performance target, and I am pretty confident that we can do that. Again, we're only looking at a portion of the network and not a huge volume of data. That's what I would say is a good threshold of performance. There is a national proposed rule making which talks about the timeliness of traveler information. I would encourage folks to take a look at that. We're kind of using that as a general guideline in terms of timeliness, and I probably spoke out of turn. I believe that the target there might be 15 minutes, but I am not sure that's the case. I have to go back and revisit that. We're shooting for a 10 minute maximum latency between when information is received about specific roadway conditions and when routing information is provided back as an absolute upper limit. Hopefully it will be within the one to two minute timeframe on average. I know that the load information that Ron is talking about has different implications, different time requirements, so I will leave that to him to address.
J. Symoun
What is the timeframe and funding level for this project?
R. Butler
This project was put forward by the IFTWG I believe in the fall of 2004, and we have been working on it since. We took a couple years to actually write the concept of operations, and do a simulated case study, and from that point we started presenting it to different agencies, different groups, and to put together the funding. Right now we have about 2.25 million of funding in place that we're working with, and we have had a lot of interested parties from different areas talking about doing the same type of project in their area, so hopefully as we start to produce results here early this spring and/or late spring and early summer, we'll start looking for other areas to take this project to and secure additional funding.
J. Symoun
Does the system accommodate over size overweight trucks? Does the routing optimization check for permanent or load restrictions?
R. Schaefer
As of right now it does not. It certainly could accommodate that. Those features aren't included in the original design. Very few of the loads, in fact, I would have to check for sure, it may well be that none of the loads that any of the carriers participating in the project transport are over dimensional. More likely overweight than oversized and most of the loads would be containerized. It will not do it in the initial iteration, but nothing in the design or the development will prevent that from being accommodated in future releases.
R. Butler
One of the points in the statement of work that we wrote in from the Federal Highway was that this is an open architecture that and any additional items could be developed could be used with this route guidance and RTTM.
J. Symoun
You already mentioned that the iPhone locks when the engines are running. Are there any other considerations made to prevent distracted driving?
R. Butler
Well, we have been working through it. We're looking at other areas. In fact, I am looking at another project next week that's addressing the same situation. So I believe they're talking about using voice commands, so right now I can't really answer that in detail.
R. Schaefer
I think it is important, Randy, to add to it that the funding for the WDU that wireless interfacing is coming from FMCSA, and of course they're very sensitive to distracted drivers and the safety issues associated with it, so they're an active partner in guiding the design so that it reduces the likelihood that the driver will be distracted by this device.
J. Symoun
Also with regard to the device will the guidance system be subject to the AT&T coverage area or have a wider coverage area like navigation systems have?
R. Schaefer
Well, since we're selecting the iPhone, we're limited to AT&T, but as I mentioned during my presentation, we're actually using this product from Vavni that has a gateway product. Essentially you use any type of PDA or smartphone for this pilot specifically we are using the iPhone, but going forward if we move this to other cities, we can bring other smartphones into it which would obviously open it up to other coverage areas besides AT&T.
J. Symoun
Are there any efforts to organize industrial land use in order to minimize truck movement?
R. Butler
Not part of this project. This is really a technology project.
J. Symoun
Do you foresee the need to allow access to independent truckers or will access be limited to trucking companies?
P. Belella
Great question, some of the trucking companies that are involved in the project use only owner operators. Basically units will be provided to what are effectively independent operations who simply contract their work out to the carriers who are officially enrolled in the project. Eventually you want to make this available to anybody who can use it, at least from a traffic standpoint. Again, I will defer to Ron regarding the load matching functionality.
R. Schaefer
I agree with you, Paul. We're dealing with the companies, the trucking companies themselves and as far as the participating in this project, but there is no limitation of including other independent companies as well. The trucking companies we're using, they use independent drivers to provide their various services, so there is no reason why we couldn't open it up to any other company as well. Hopefully that addresses your question.
J. Symoun
We don't have anything else typed in right now, but we do have time left so we'll open the phone lines and see if anyone wants to ask a question over the phone. In the meantime feel free too continue typing in questions. If the operator can, please give instructions on how to ask questions over the phone.
Operator
First question will come from Ed.
Ed
I am not sure who this question will go for. Let me take a crack at you guys. Do you guys foresee creating any type of open source API to enable independent developer to come up with new ways of displays using your data?
P. Belella
That probably should go to Ron.
R. Schaefer
This is Ron. The way this is being architected, we're using the software development language Java. We're using the web services and essentially the service oriented architecture as the basis of the way we have designed this. We'll have between each of the applications we'll be using web services. The APIs or web services that we're developing for the connections to KC Scout and the rail carriers, those will be open and available to use for anyone. That's really our approach on how we're connecting to outside sources through web services and the XML flavor we're using is UBL, universal business language adopted by the Oasis Standard Group.
Ed
Okay. So for somebody who wants to create a base application for some of the newer devices out there, would they have sufficient information for to create a new application independently?
R. Schaefer
I kind of mentioned that before that we're using this Vavni gateway product that will allow it. Again we're targeting the iPhone for this project but using the gateway product we can essentially target to any smartphone or PDA, and the gateway product will automatically make all the necessary adjustments so it would work with any of that, would work with the different phone. It wouldn't be a need for API the way you are suggesting because the product we're using will automatically take care of that.
J. Symoun
We have one more question typed in the mean tile while we're waiting. Do you have an estimate for the cost to an independent driver?
R. Schaefer
We haven't come up with that at this point. Focusing just on the cost of the iPhone and your normal data services beyond that, since Federal Highway is funding this project, we haven't determined what the ongoing costs would be at this point to continue to use it after the end of the pilot phase. We will provide that information at the end of in our final project report.
J. Symoun
Do we have anything else over the phone?
Operator
At this time there are no further questions.
J. Symoun
We just had another typed in. Are management practices being utilized within terminals to reduce emissions such as reducing idling or other inefficiencies?
R. Butler
I don't think that's something we can address here. I mean, there are certain policies in place with each one of the terminals, but I am not familiar with exactly what policies are being enforced at each terminal. We really don't focus our project within the terminal. It is basically getting the information and sharing it so flow can happen between the terminals.
J. Symoun
Is there anything come up on the phone?
Operator
At this time there are no questions.
J. Symoun
Okay. I think if we have no further questions, we'll go ahead and close out for today. While I am reading these last few parts, if anybody does think of anything, feel free to type it in and we'll go back to it. Thank you, Randy, Paul and Ron for great presentations, and thank you, everybody, for attending today's seminar. The recorded version of this event will be available within the next few weeks on the Talking Freight website.
As a reminder, if you are an AICP member and would like to receive 1.5 Certification Maintenance credits for attending this seminar, please make sure you were signed in today with your first and last name or type your first and last name into the chat box if you are attending with a group of people. Please download the evaluation form and email it to me after you have completed it. Please also download the CM Credit instructions if you are unsure of how to obtain your credits for today's seminar.
The next seminar will be held on February17 and will be about the Empty Miles Program. If you haven't done so already, I encourage you to visit the Talking Freight Web Site and sign up for this seminar. The address is up on the slide on your screen. I also encourage you to join the Freight Planning LISTSERV if you have not already done so. Enjoy the rest of your day!
