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