Today's topic -- my name is Jennifer Symoun, and I will be moderating today's seminar.
Today's topic is best practices for moving freight through urban areas. Please be advised 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 operation, Ron Shafer of SAIC, and Paul Belella.
Randy joined the federal highway administration in November of 2003 as a transportation specialist on the operation and technology team. Prior to joining FHWA he completed a 35 year career in the private sector
and managing freight operations, engineering, Customer Service, business process reengineering, information systems and project management.
Randy's education includes a bachelor of science in engineering tech technology, masters of business spheration, and management information and master of arts, transportation policy, ( indiscernible ).
Ron Schaefer is a senior transportation analyst in logistics and engineering business unit at science application international Corporation.
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 federal highway administration technology projects that involved using the FIH architecture including the current cross town improvement project.
Prior to joining SAIC he worked 27 years at union Pacific. He has worked or other government government entities.
Paul has 24 years of professional experience in project management, business process reengineering, systems development, special cities, and technical and operational testing and evaluation. Areas of intermodal
and truck board freight transportation to include specific expertise with vehicle and administrative technology systems.
, frat efficiency and operation analysis, freight security technology, freight planning, decision support systems, and web-based communications and transaction immediate A he currently managing 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 and analysis and assessment
and reengineering of operations to leverage advancements in information technology.
I would now like to go over a few logistical details prior to starting the seminar. Today's seminar will last 90 minutes with 60 allocated for speakers and final 30 minutes for audience question and answer.
If during the presentation you think of a question, you can type it into the chat area. Please make sure you send your questions to everyone and indicate which presenter your question is for.
Presenters will be unable to answer questions during the presence but I will start off the Q&A session with the questions typed in the chat box.
Once we get through all the questions typed the operator will give you instructions how to ask questions over the phone.
If you think of questions after the seminar, you can send it to the presenters directly or I encourage you to use the freight planning web sever. If you haven't joined the listserv the web address is provided on the slide on your screen.
Finally, I would like to remind you the session is being recorded.
A file containing audio and visual portion of the seminar will be posted to the talking freight website in the next week. We encourage to you direct others in your office that may not have been able to attend to access the recording.
The PowerPoint presentation are available for download from the file download box in the lower right corner of your screen. The presentations will also be available online and I will notify all attendees of availability of power points,
recording and the transcript.
One final note talking freight seminars are eligible for 1.5 certification continuing education credits. In order to obtain credit you must have logged in with your first and last name or if you're attending with a group of people
and haven't logged in under your name type your name in the chat box. To obtain your credits follow the instruction that is are available in the file share download box. Please download the evaluation form from the file share box
and submit the form to me once you filled it out. We'll now go ahead and get started. Today's topic for those of who you joined us is best practices for moving freight through urban areas.
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 any questions during the presentation,
please type them into the chat box and we'll get to them at the end of the seminar. With that I will turn it over to Randy.
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 Shafer 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 have Annmarie Hagan mages at the end that gives 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 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.
A little pack ground. 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.
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 where railroads basically begin and end the West Coast railroads end,
the East Coast railroads again. There is a need to do a rubber tar 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 D ramp 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 more 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 the sweer modal freight technology 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, 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 which I consider really the heart of the cross-town project. We have a wireless drayage component that will be used to update information to the drivers.
We have a chassis utilization tracking module. These three areas Ron Shafer will address with his discussion of the architecture and how these projects are progressing. We have a realtime traffic monitoring module,
and a dynamic route guidance 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 chassises in the chassis pool.
The realtime traffic monitoring piece gives realtime 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 it may be -- he may reroute around it.
That's more the dynamic routing.
I am going to let Paul -- 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 date A we have trucking companies involved, some of the drayage companies,
the two state governments involved, the MODOT and K dot have been active in helping us, the metropolitan planning organization, midAmerica regional council provided funding primarily in the air quality act,
and we have had the economic development group, the Kansas City Smart port 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 realtime 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 Bob tail 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 steps? 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 did deploy by the first of may of this year
and conduct an operational test and we also have an 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 do 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 driage and chassis management system.
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 Shafer of SAIC. Ron,
if you give me a second I will get you back to the beginning of your presentation.
Thank you, Rand and I 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 of the C-TIP project is made up of all of those components and essentially 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 I mechanics, 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,
and Randy also talked about the goals and there again we have the components and all of those -- each of those all make up the C-TIP application. Up to this point we have union Pacific, northern,
and the southern participating in this project. KCS is not participating because they don't actually perform any cross towns within Kansas City. Their operations is set up differently.
We do have to get letters of authorization from each of the carriers which we have that and you just can't collect data from rail carriers or truck carriers as well without getting authorization, letters signed,
which we had that completed. We'll be getting information directly from each carrier and also through rail link as well. Rail Link is the data provider for essentially all of the railroads, class ones, as well as the short lines.
The dry carriers we're working with are ITS, lake country logistics, contract, all of those have operations in Kansas City, and as Randy mentioned as well, we have local and regional stakeholders and MODOT, KDOT,
KC Scout is providing traffic information which will be part of the realtime traffic monitoring component and also Smart Port and the midAmerica regional council.
The activities as Randy mentioned this project has been going on for a year or so. I guess a lot of prep work was done first, just getting all the participants together to agree to the concept operations and so on.
From a software development perspective we essentially have started it was in September timeframe.
We hope to get everything wrapped up by the end of April and then we'll be starting the pilot in May timeframe which will run for about six months. At this point we have had to because of the projects been taking awhile,
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, so we have done that a couple of different times, both on the RTTM, the DRG and the WDU.
We had kick off for RTTM and DRG as recently as October. We have picked up the -- just recently started receiving data from the railroads, the union Pacific Burlington northern and the DNS.
We actually started getting data feeds from another participant that's providing information for two of the dry carriers, IXT and lake country through the product called profit tools,
and we're getting data feed from them to get the industry mood rapped I mentioned and 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 collecting emission information off of the engines,
and that information also will be Fed from the diagnostic equipment on the truck motor will be Fed into 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 or all of C-TIP from that application to the iPhone
and the ( indiscernible ) 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, and that will be the device that will be in the cab mounted on the dashboard
and it will be collecting -- providing all the information that we are essentially pushing through on the IMAX and the components for C-TIP.
My 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, actually had the draft done
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 lent to us 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 we're targeting next month to get all of that done.
CUT requirements and preliminary architecture has been complete.
We pretty much finalized the data requirements that will essentially the information we'll be getting from the chassis pool operator and we actually have started receiving data from them, test data
and 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 do analysis on it.
Then we have the development under way for the interface devices to or the interface through the external devices and that's the iPhones that we have actually started that as well. RTTM as I mentioned we had the kick off back in October.
The 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.
We have to document the risk associated with this and the use case rules and DRG use case rules and DRG actually are engaged in services of Georgia Tech along with helping us write the algorithm for the DRG,
and that system design is under way, and as you can see the use cases 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 Vavmi
and we have not ordered the iPhones yet but that will be taking place here very soon, and then we need finalize exactly all the information we'll be collecting from the engine mounted devices, the escapees, engine parameter information.
So we were to meet with the evaluators to determine what information they need to -- they would like to collect off of those devices, and CUT pretty much really gone through the refinement, the user requirements,
and that really was being driven by the information we could get from the chassis pool operators.
RTTM and DRG I am going to let Paul pretty much cover those items. The schedule, application development perspective, as you see there 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 there the dates for the testing all pretty much in March, May timeframe, and then the US DOT, the design review will be held in late February after we get all the RTTM and DRG components included in that.
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 just 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 here that shows the essentially all the terminals, what the number of loads and unloads there at that West terminal there at currently, number in gates and out gates,
and obviously this is all test information here that we have in the screen shot, but you can see there that we essentially are showing all the terminals that are part of the C-TIP application that are included,
so this would again as Randy mentioned this is all taking place in Kansas City,
so you would see when you log in you would essentially see all the rail terminals that are participating in the C-TIP would show up on this particular screen here.
The capacity administration, this is a screen that allows each of the capacity for each on the left-hand side there you have the default capacity, number of trucks available for this is for Greer,
actually the dry company is working with us in Kansas City and left inside is the default capacity. Normally that's what he could take on a day-to-day basis,
but then on the right-hand side if for some reason he had more trucks available on a particular day, he would put that into the system as displayed there.
And then if you just can imagine that capacity constraint there would then be used as part of the overall optimization that when we rent it, we can see Greer has more capacity on these particular days
and that 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 we are the intent of the application is to eliminate empty moves so you don't have Bob tails running across town without a load on it,
so based on all the information we're collecting from the rail carriers and the Dray carriers, the perspective their 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 essentially would be telling them the type of moves that they have. 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 there 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 and also what the time to get into the gate,
and then you can show 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 DNS, pick one up at U.P. and so on. This is going to be the work order for the driver,
essentially tell 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 that orders for that particular day. Once he picked up the order,
he will on the iPhone itself he will select a key and it would tell him it would send the information back to the IMEX and say he has picked this up or has unloaded that particular box.
These are the trip assignments, container and chassis moves, and let you browse through that there. You can see there the type of move it is, chassis or cross-town, ideas, the equipment, the container ID,
the proposed trucking company that would be essentially what IMEX is through the optimization of what we're recommending and then show the next column there is shows exactly who was assigned, what the status is,
the ( indiscernible ) when it is unloaded, the cut off time and so on.
With that, there is 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 C-TIP-US.com. Again, my name is Ron Shafer. There is my information. We'll turn it over to Paul.
Thank you, Ron. We're now going to move on to the final presentation given by Paul Belella of Dell can. Paul, are you seeing the slide now?
Yes. It was the last slide Ron present before his contact information that didn't have any content on it that I saw.
Okay. Not sure what happened there. As long as you're table to see the slides we should be good to go and get started when you're ready.
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 Q&A.
I will refrain from attempting to use every possible second. I will Milwaukee sure we get through the material quickly. As Jenn measure mentioned my name is Paul leal la, 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 Ann unproductive move except from the standpoint it is required every once in awhile to reposition equipment to support freight movement.
Unproductive move 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 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 realtime 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 attending 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 there are -- 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,
intermedial 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 is 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 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 you -- 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 Reno this call -- 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 data we can
and make 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 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 part, and as equally as important as anything else 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 a basic 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 inner 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 have I 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. George George 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 we're calling -- 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 illustrated 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 CMT 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 then interface -- 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 information -- 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 gathered from KC Scout and the Missouri State wide 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 her 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 sprawl 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 enter 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, just a quick update on project status. Ron talked about some of these already. We already started the development of the RTTM and VRG 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.
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 Q&A 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 is appropriate jump in. Let's see here the first one. What is the average daily container exchange volume among the three class one railroads?
This is Randy Butler. The largest one is Chicago. We put together a case study available on our website at www.C-TIP-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?
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.
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?
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.
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 reduce -- 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 Nobel 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 Bob tails,
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 Bob tails on the roadway.
My argument would be not only does FHWA or US DOT have a role, they have responsibility in this area.
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.
Have you quantified the expected environmental or traffic congestion benefits.
Yes, that is and I don't have it in front of me. It is available on the website, www.C-TIP-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.
On cleaner fuels or lower emitting vehicle technologies factored into systems?
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 a trippy naturing so much emissions.
How does this work to avoid making truck drivers drivers distracted by the new information Fed to them you through an iPhone.
One of the reason that is 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 .
We may try too experiment with voice commands, too.
How would this interact with carries in contract shipping how much of the industry is not eligible because of the contracts?
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 realtime traffic management piece. You could use the dynamic routing, so each one of these are individual modules, and they're available -- will be available for everyone to use.
Any expectations on the lag from the data source to the on board devices? Is there a performance window that the information must meet in order to be useful?
I will take this. This is Paul.
I think there is a recognition that particularly from a 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 are -- 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 partly because 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 that 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 believe that the -- 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.
What is the timeframe and funding level for this project.
This project was put forward by the IFTWG I believe in the fall of 2004 and we have been working.
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.
Does the system accommodate over size overweight trucks? Does the rooting optimization check for permanent or load restrictions?
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.
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.
You already mentioned that the iPhone locks when the engines are running. Are there any other considerations made to prevent distracted driving?
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 ( indiscernible ), so right now I can't really answer that in detail.
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.
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?
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 Vavmi 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.
Are there any efforts to organize industrial land use in order to minimize truck movement movement?
Not part of this project. This is really a technology project.
Do you foresee the need to allow access to independent truckers or will access be limited to trucking companies?
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.
Agreed 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 other -- any other company as well. Hopefully that addresses your question.
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 give instructions on how to ask questions over the phone.
Thank you. [ Operator Instructions ] First question will come from Ed.
Hi. Hi, Randy, hi, Paul. 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?
That probably should go to Ron.
This is Ron. The entire -- the way this is being architected, we're using software development language is 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.
Okay. So for somebody who wants to create ( indiscernible ) base application for some of the newer devices out there, would they have sufficient information for to create a new application independently or --
I kind of mentioned that before that we're using this Vavmi gateway product that will allow -- 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 AVI the way you are suggesting because the product we're using will automatically take care of that.
Okay. Thank you.
[ Operator Instructions ]
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?
We haven't come up with that at this point. Focusing just on the cost of the iPhone and your norm a 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.
Do we have anything else over the phone?
At this time there are no further questions.
We just had another typed in.
Are management practices being utilized within terminals to reduce emissions such as reducing idling or other inefficiencies?
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.
Is there anything come up on the phone?
At this time there are no questions.
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 recording and the PowerPoints will be posted online within the next two weeks, and I will send out an email once they become available.
As a reminder, if you are at AICP member and want to receive one and-a-half certification maintenance credits for today's seminar, make sure you were signed in with your first and last name or if are you in a group
and not logged in under your name you can type it into the chat box. I did type in there that this seminar is not yet available on the AICP website, so if you were to try to go log in your credits for this one,
you wouldn't be able to find it. It should be up in the next week or so. I will send an email once it is available for logging your credit. You can download instructions for receiving your credits from the file share box
and please also download the evaluation form and email to me after you completed it. If you're not applying for AICP credits, you're also welcome to fill out the evaluation form. We always welcome your feedback.
The next seminar will be held on February 17th and about the empty miles program. If you haven't done so already, I encourage to you visit the talking freight website and in-up for the seminar,
and the address is up on the slide on your screen. I also encourage to you join the freight planning listserv if you haven't already to be done so. With that thank you to the presenters and thank you, everybody, for attending
and enjoy the rest of your day.
Thank you for participating in today's conference call. You may disconnect at this time.