![MBUF Logo](../images/MBUF_logo2.jpg)
Proceedings
Download this chapter of the proceedings [PDF, 131K]
Download the entire proceedings document [PDF, 657K]
Technology Panel
Tuesday, April 14, 2009
KEVIN BALKE, Moderator (Bio)
Director, Translink® Research Center,
Texas Transportation Institute
DR. JOHN KUHL, Panelist (Bio)
Professor of Electrical and Computer Engineering,
Professor of Public Policy, University of Iowa
SCOTT ANDREWS, Panelist (Bio)
Cogenia Partners
RAY STARR, Panelist (Bio)
Assistant State Traffic Engineer for Intelligent Transportation Systems (ITS),
Minnesota Department of Transportation
GLENN DEITIKER, Panelist (Bio)
Telvent Caseta Inc.
Kevin Balke
This session deals with technology and implementation of different technologies in the pilot studies. We’ve had a lot of discussion so far on policy issues, the inter-relationship with technology, and implementing those policy issues. We have four speakers here today that are going to talk about different aspects of the technology side of things.
Each of the speakers will come up and talk for about five minutes and present a little bit about their systems and about the design of their systems. It is hard to talk about technology without having some sort of picture in terms of architecture and things like that. I would like the panelists to focus on these three aspects as they go through their discussion: how they accumulate the mileage itself, how their systems communicate the mileage fees back to some processing center and how this processing center distributes the fee information back to the users.
[ Top ]
John Kuhl
Just over a decade ago I got a phone call from my good friend David Forkenbrock, and he said, "I would like you to come over and work with me on this mileage-based charging idea that I am thinking about." I said, "David, I am an electrical engineer. I do not know anything about policy issues and transportation." He said, "That’s OK, I just need somebody to help me a little bit with technology, and I will take care of the policy things." It didn’t quite work out that way in the end. But I have to say this past decade has been a very interesting and humbling experience for me, as an electrical engineer, pouring into this new world of policy. And it’s taught me a number of lessons, and I want to share a couple of these with you because I think they may have been discussed today.
First of all, technology is not a substitute for good policy. If you don’t understand the policy issues, if you can’t justify things on the policy-based system, then technology certainly isn’t going to save you. If our reason for pursuing mileage-based charging is just because we can, then we’re certainly destined to fail. We need to always keep that in mind as we go forward.
Technology has a very limited ability to change public perception. Many of the issues that we are dealing with here we can use to develop variable solutions for protecting people’s privacy. And we can be very proud of ourselves as technologists for having thought of these things and implementing them, but in the end if we can’t explain them, the people won’t trust them, and then we’ve done nothing. Solving the privacy issues is of no value if we don’t solve the perception of the privacy issue.
[ Top ]
Technology is confusing; people have a limited ability to really absorb major changes in technology. To me, it’s clear that the policy makers need to be driving this bus, and those of us who do technology will be your obedient servants and will try our best to address the issues and problems that you bring up. I don’t think it is our role on the technology side to try to be too much on the forefront as to how this should evolve.
At this point of the day there is probably very little new that we could really say. I just want to catch the issues in this way and this is sort the basis for other discussion and questions. I see that there are five technology decision points that need to be addressed in developing a mileage-based system. First is how do we charge, how do we decide how many miles someone has driven, how do we report these charges, how do we move these charges from the vehicle to some collection point, how does the person pay the charge, how do we enforce the payment of the charge and how do we apportion the charges back to the appropriate jurisdictions?
Perhaps, more importantly, if you look on the other side of the slides, we can see the cross-cutting issues because these are issues that are sort of orthogonal to these five decision points. The first of all these issues is ubiquity. In other words, if we are going to do this at the national basis it needs to work everywhere, for everyone, and all the time.
There is a cost/overhead issue. How do you collect user fees from 250 million vehicles and do that in a cost-effective way that is not overhead? How do you maintain people’s privacy? How do you make the system secure and robust, resilient to various types of threats? How do you deal with evasion issues? How do you make this system compatible with others, like road pricing initiatives, that people are interested in pursuing? Etc...
[ Top ]
If you look at charge accrual, the blessing in the curse of mileage-based charging is the global positioning system (GPS). On the one hand, it is sort of the basic enabling on the other hand, it’s the one that holds us back in terms of getting public acceptance because of the fears of invasion of privacy. The fundamental technology question that has to be answered is do we get enough value from using the GPS-based system and providing specific location services to really make it worth the public liabilities? The answer for that question is clearly yes. So much of what people accept today is their vision. Their dream of the benefits and payoffs of this are based upon things you can only do with that type of information.
We move on to the reporting of the charges. What are the choices? The particular one that we are using in our study involves wide area wireless (e.g., cellular data links) because there is existing infrastructure almost everywhere in the country these days that you can tap into. We have also seen examples in the Oregon study of using wireless local area network (LAN) technologies, the use of a smart card. We have also seen allusions to using VII infrastructure, although I would point out that if you are going to use VII, you are not going to implement that on 4 million miles of public roadways in the country, so that is going to be a limited solution, or partial solution, not an entire solution to the problem.
We also need to keep in mind that technology is a moving target. We are talking about designing a system here that may be deployed in 2020, and almost everything about communication infrastructure is going to change radically in the period between now and then. It is a big challenge to think about a system that we can define in today’s terms while trying to address the future.
[ Top ]
There are charge payment issues. One of the options we have heard about is from the technology point of view where we are dealing with invoicing people. (We are working with a prototype system.) But there are some issues about the costs associated with that. We’ve heard presentations about the possibility of using designated payment stations and perhaps things like smart cards. How much information should we collect? What is the trade off between protecting people’s privacy and allowing them to understand the nature of their charges? What about casually transient populations? Etc.
There are charge enforcement issues. How and when is non-payment detected? There are a number of things we could do technologically to identify situations or apparent situations where payment is not being made. We can look up at the history or track people’s patterns and say, "It looks like this person is not paying their fees." What is the leverage to induce payment?
With charge apportionment we have to ask, "How are collected charges apportioned to the appropriate jurisdictions?" I haven’t laid out any particular opinions in terms of what I think the answers to this are, but this is how we frame the problem. For any of these areas there is a whole range of possible technical solutions. I hope we can get to some discussion on any of these issues, but I am not going to stand up and necessarily say that I think my answers to any of these questions are the best ones.
[ Top ]
Scott Andrews
I am going to talk about some technology that we have developed over the past few years as part of the VII proof of concept project in Detroit. This is now known as Intellidrive. It is a possible means for implementing mileage-based user fees (MBUFs). There have been quite a number of misconceptions and worries about how effective these kinds of technologies can be. What we did in the proof of concept involved implementing an on-the-fly tolling. Most of you understand that you can easily apply this to on-the-fly mileage-based user fee collection.
The VII proof of concept was an activity to validate safety, mobility, productivity and convenience. To build a system that could provide all of these with the same hardware and thereby really benefit users. I think we have seen this with intelligent transportation system (ITS) services on the side of mileage-based user fees, and that is what this is about. How do you get more benefits out of the same hardware and the same basic infrastructure and thereby reduce the impact of any of the costs associated with putting that system in place?
The approach that we did was we built a proof of concept set up in Detroit over a large area in the northwest portion. We did a whole series of tests with subsystems and services. And then we built a bunch of applications. We collected a lot of data, which I’ve been reducing over the past six months. This is a quick cartoon of the VII system. What we have is equipment on board the vehicle. We had the great advantage of having vehicle connectivity to all of the vehicle systems that we could want as well as dedicated short-range communications (DSRC) and a lot of computing power. Clearly, you need to reduce that down to a simpler system and make it affordable. Fifty-five different roadside units were distributed around various intersections. An infrastructure computer network system allowed us, in the case of the tolling system, to collect information from the car, send it back to the charging or payment service, and back on the network. Basically, it was an Internet-connected payment service. That could be a credit card based system or use a special account. You can imagine multiple ways to implement that. We also had roadside infrastructure, which is actually a processor located at the toll zone, and you wouldn’t necessarily need to use something like that in the case of a mileage-based system unless you have to do very rapid transactions.
[ Top ]
In this picture what we have is a series of freeways, which are the orange lines, and the red dots are the locations of the roadside equipment we used for freeway exchanges. The blue ones are a series of arterial roads in the same general area. This is actually in place up in the Detroit area, and we are hoping to make it available for people to do experiments.
Here is the quick explanation of how the tolling system works in this case. We used the same system for a parking application. You would enter and exit a parking area and you get charged. You get a token when you enter, and when you leave you pay a fee for how long you parked there. The red zone here indicated an area (you can make that red zone as big or small as you want) that when you enter, you start to get information about how much you need to pay for, so the car doesn’t know anything about the system until it gets into this red box. Then once it gets in the red box it finds out about the green box, which if you go through this little patch on the road, you are going to get charged. And this is how much you are going to get charged. That gets communicated to the driver through a user interface, a little screen in the car. They have the option to approve that payment, and then when you actually pass through the green box, the charge transaction happens. We did this completely end to end: a digital encryption process, encrypted from the car back to the payment system. People talk a lot about privacy, but there is no reason that you couldn’t make an indirect kind of thing where you would have a third party that would get the information and figure out how much you are going to be charged and then charge you in some other ways so that no one actually knew who is paying a fee or where they were.
This is one of the interchanges — a very large interchange. There are little payment zones; these are the little green boxes. We have 10 different payment zones covering all kinds of places on this interchange. Some of them were actually independent lanes of the freeway; some of them were connected zones. People talk about GPS not being too accurate; these red lines are actually reports from the car that were collected as to what their position was. You can see that is actually exactly where the car comes from. We had 10 different zones. We did this at low speed, just entering and exiting the freeway, and also traveling at 70 to 75 miles per hour through these payment zones. We were able to discriminate individual lanes and pay different amounts for different lanes.
[ Top ]
So there are some interesting cases here that I think are important, which point out some of the technical challenges that you have. These were particular cases that we set up and, in fact, the big shaded area is the plaza zone. Once you get inside that zone you are getting informed about all these little payment zones and then you decide, the car itself decides, whether it’s in that zone or not. Once it gets close to it, it starts the transaction.
The top one here is the case where you have the frontage road right next to the freeway on-ramp, and we’ve all seen that kind of situation. We have a couple of different roads, and one of them is getting on the freeway where you want them to pay. In fact, one of these passes right next to the plaza zone, but you don’t actually go into the payment zone because you are going to some other place on the road. We’ve actually acquired all of the information to make the payment, but since it didn’t go through the box it doesn’t actually execute the transaction. It is fairly good at discriminating who was where and whether they should pay. Another case is down here where the plaza was made intentionally a little too small, and the guy went out of the zone and went back into the zone and then went back though another toll plaza or another payment zone. The idea is to make sure he didn’t get charged twice for having gone through two payment boxes within 10 or 15 seconds of one another.
Lastly, we had more of these adjacent roads. Here, we wanted to make sure that you didn’t get bothered if you were, for example, doing pro data transaction or maybe some ITS navigation transactions. You don’t want to have all your bandwidth sucked up by doing a bunch of tolling stuff that is irrelevant to you, because you are not really in the plaza zone. So we had some cars moving on the road nearby, and we wanted to make sure that they didn’t pay any attention to the tolling system at all.
[ Top ]
The system worked, in general, very well with very few mischarges. We are doing another test, similar to California, at the Dumbarton Bridge. You have the actual toll plaza where people pay in cash, and we defined payment zones. You can see in the bottom here (red zone) and this is where we end up with two people that didn’t pay. After a lot of analysis we found out that what was happening was that the gantry going across the freeway for enforcing a fast track was actually blocking the radio frequency (RF) signals. The only places where we ended up with a problem of missing a charge or charging somebody incorrectly were generally related to where we put the antennas and how we set that up. It wasn’t related to the ability of the car to know where it was.
We were able to discriminate lane base payment zones. I think that is really important when talking about congestion-based pricing or, in particular, distinctions between the use of one kind of lane or another. It also means that you can avoid charging people driving on the frontage roads. We were able to execute all these transactions, even going all the way back through the network to perform a payment transaction. We were able to do this with cars running at full speed. They were at the plaza zone for only 10 seconds, at the most. There are actually more cases of what are called false positive and false negatives where you get this incorrect charge or missing charges that you shouldn’t have gotten. We are very happy with the outcome, and I think it represents a good set of technologies to implement this kind of system.
[ Top ]
Ray Starr
Excellent timing. We are just starting an MBUF project in Minnesota and finalizing the concept of operation and various requirements, so the things we hear today are useful for us. I have two different things I would like to talk about. One is integration with other applications. We think that is a good idea. Tolling system, mileage insurance, mayday, Onstar, navigation devices (tomtom, digital map, one-way receiving map), mileage fee, VII — how are these read? GPS, roadside communication, wide area communications, or digital map? How do we get these in all cars? We need to integrate these things. But the question is, "Do we really want to have a car with four GPS receivers to do similar things?" It makes a lot of sense to integrate these things.
Considering previous discussions of what the value of these things are, trying to convince the Intellidrive program that mileage-based user fees should be a big VII application is going to be hard.
If you don’t have some of this equipment in the car, it can be very expensive. It’s very expensive to implement if we have nothing, but many cars already have these systems, and implementing an MBUF would be easier and very cost effective. From the point of view of VII, we need to figure out how we do this project and how to bring in revenue. In Minnesota we are trying to demonstrate mileage-based user fees as a VII application along with a couple other ones. We are looking at in-vehicle signing, safety application and travel information. What we are hoping to do is to build on consumer navigation devices.
[ Top ]
Hopefully, we can get someone in that area that is willing to work with us to get the mileage off of the navigation device, report that with cellular communications, and then payment would either be billed monthly or billed with the vehicle registration. That will also depend on the enforcement mechanism. If you haven’t paid your registration fee, then you cannot get your sticker. Police tend to see stickers that are out of date. That would be an enforcement mechanism.
The other cost-effective way to do mileage-based fees, besides using VII, could be the no-technology way. We are proposing to manually read odometers and then paying a flat rate with vehicle registration. There is ongoing discussion about self-reporting, but you could have government certified people that would read the odometer, so you wouldn’t need self-reporting. In Minnesota we used to have an emissions testing program before you could renew your registration. You had to take the car into the emissions check. This could be less expensive than what that program was. They terminated that program, as they found out it wasn’t doing anything for the environment.
That would be our approach, and there are some advantages to that. One is that you can implement that in a couple of years for all cars in Minnesota because it doesn’t require anything in the vehicle. It would only be a recording of the identification number, the mileage reading, and a digital photo of the odometer. It is inexpensive. Another advantage is that it would be independent of the gas tax. One way to sell this is to say, "We need more revenue, and a mileage-based fee is a fair way to do this, to add a mileage-based fee that is not going to be obsolete in a few years." You could, at the year you start charging per mile, say, "We are going to reduce the gas tax by x cents." This could be one way to have both. This also addresses the privacy objections. The odometer won’t tell where you were driving and when. We take this as a good kind of default base case. There are some disadvantages. You will not be able to tell what miles were in the state versus out of the state. But in a way, we already have that with the gas tax. Neighboring states don’t have the same gas tax rates, and we don’t seem to be bothered by people crossing borders to buy gas.
[ Top ]
If you decide to actually replace the gas tax, then mileage rate will have to be a lot higher than if you were just supplementing the gas tax. Only paying a once-a-year registration fee could be a hardship if you had a high cost.
To address all of these things we are could have an opt-in program where, if you want to get into the program, we would put the device in your vehicle, obtain and record miles, and exclude miles driven outside Minnesota. So now there is a reason for you to want to get this. Are there enough benefits to you, in terms of privacy loss versus saving some money, to charge reduced rates if you are driving outside the Minnesota congested zones? You are getting a discount if you are not driving in the congested metropolitan area or driving outside congested times. There is a lot of incentive to get in the program. That is the approach we are looking at.
The device that would be used is the same that would provide VII application. It would include in-vehicle signing for curve warnings, intersection avoidance collisions, work zones, and school zones. Navigations device manufacturers are already capable of getting travel time information.
In summary, the two things we are looking at are integrating VII and the mileage-based user fee and then also using this technique to take care of some of the privacy issues. If you don’t want anyone to know where you are driving, then stay with the odometer readings.
[ Top ]
Glenn Deitiker
I am the Toll Guy in Texas. I want to talk a little bit about maybe the third way. I am not suggesting this is an alternative to mileage-based fees. To the contrary, I don’t think it can function as an alternative to MBUF or tolling. But I think it is an interesting concept for discussion as a mechanism for charging for small and specific projects.
Will $100 barrel of oil come back? Or electric vehicles? It seems like this is happening around us. Will they become the majority of the traffic on roads? Who knows if the battery problem will be addressed? Will transportation budget surpluses come back? Most likely not.
Technology is not the looming factor. These are mostly political and public perception issues. Technology can solve all of the problems we are facing or any of these issues. It can collect the information for mileage-based fees, can process the transactions, can do it inexpensively and can do it so effectively. The question is, "Can we do it in a way that is acceptable to the politicians and acceptable to the public?"
This is the direction in which toll systems are headed. Toll technology is becoming a commodity. The systems five years ago cost an order of magnitude more than the systems cost today. Cameras are becoming less expensive. The next generation of camera technology is going to cost a fraction of what the state of the art system that was deployed only a couple of years ago cost. License plate recognition technology, mostly software, is becoming incredibly accurate. There are all kinds of new approaches that are being applied to license plate recognition. This is one of those exponential problems. That last 5 percent and that last 1 percent become very expensive. But in this case, the approach we are going to use is good enough. The last bid is transaction processing. This has been kind of the bane of toll systems for ages. Transaction processing, even electronic systems, have consumed a large part of toll fees. When those transaction fees start approaching pennies or even less than a penny, then we have a lot more alternatives in the way we approach tolling.
[ Top ]
Here is what we are suggesting: it is the idea that you can toll a very small section of road at a very, very low toll amount, using nothing but cameras and license plate recognition. So, for example, here in Austin, 5th Street would be a great choice. You can go out and put a bunch of cameras on 5th Street and collect tolls, and let’s say those tolls are 2 cents or 5 cents, or some tiny amount that would be used just for resurfacing that street. Collect those tolls over the course of some number of years until the project is paid. There is no toll agency, there is no toll overhead, nothing but a camera on a pole that collects license plate images and may collect radio frequency identification (RFID) information. It processes this electronically, and we aggregate the transaction into a larger transaction. That makes financial sense to process. We potentially have additional violation processing tools. For example, registration data can be used. It is a capability that local, regional mobility and other transportation agencies can use to solve the problem. If you have a small project that needs to be funded over the course of a handful of years, you can deploy a very low-cost toll system and charge people a very tiny amount, something equivalent to a mileage-based fee. Obviously, this is not the solution for the entire state. You are not going to put cameras all over the state. But for small projects (bridges, individual roads, and other individual projects) it is a very low-cost alternative.
It is not going to happen today. Transaction fees are still a problem in the toll industry. I think we are going to see a lot of change in that area in the next year or two. The camera technology has to come a little bit further. I think the license plate recognition technology is probably almost there. In a handful of years, probably in a year or two, it is going to be cost effective to do mileage-based technology with roadside equipment at a very low cost. Once again, I don’t think this in an alternative to the mileage-based charging. It is not an alternative to tolling because I don’t think this makes sense for large toll projects. We are collecting a dollar or two per transaction. When you can pay for a project with pennies per transaction, I think this represents a solution. I think those of us in the tolling industry that are watching what is happening, watching the commoditization and the reduction in transaction fees, see these kinds of approaches coming.
[ Top ]
Questions & Discussion
1. Moderator Kevin Balke asks: We’ve seen a lot of different approaches and a lot of different policies, anywhere from the national level down to kind of getting very route-specific, user-specific type of information and charging fees related to that. We see an implementation window of about 2020 as the desired implementation window. We hear that technology is ready. What are the minimum requirements and functionalities technology must have in order to do this by these timeframes and at all the levels?
Scott Andrews answers:
Tell us the policies and we’ll figure out the technology. I think we need some ability to determine the position of the vehicle. If you are dealing with large areas, charging for entering a city center, you could probably do that without necessarily having a lot of positioning equipment in the vehicle. If you are trying to charge per mile, you should have the ability to collect the mileage on the car and also to validate that somehow because you know what people will try to do to get out of it. People will undo things in their cars and, because it’s their car, they feel they have the right to unplug things or change things. So you have to deal not only with enforcement but also prevention. Of the 200 million cars on the road, some large percentage of those cars will have something wrong with the system. You need to be capable of finding them and getting revenues up. The rest of the technology really deals with how extravagant you want your system to be. What are the policies, and then you can make the system as simple or complicated as you need to.
Ray Starr agrees and replies:
I think the other piece is cost. You can build them, but it has to be affordable in the near future.
John Kuhl replies:
The technology is already there. The jury is still out on the enterprise cost structures. If there is an Achilles heel from the technology point of view, it will be in the cost of that infrastructure, not the cost of collecting the data on the vehicle.
Glenn Deitiker replies:
Bureaucracy is costly. If someone created demand for 200 million devices you can put in a car to track vehicles, it would be cheap. If you require a national infrastructure, with heavy overhead with a lot of oversight, that will be significant.
[ Top ]
2. When will Minnesota be implementing?
Ray Starr answers:
We are in the phase of finding the concept and requirements. We are hoping to have requests for proposals (RFPs) going out this summer.
3. Question to Ed Regan, Wilbur Smith & Associates: Would you tell Minnesota to stop? What do you tell Minnesota, who is ready to move on?
Ed Regan answers:
I’ll say move on and don’t wait for national go-ahead.
4. With the cost being a key element here and how to get the cost down, this is certainly one of the biggest challenges that the Dutch are facing right now and they are procuring the first national vehicle miles traveled (VMT) fee approach. I’ve been sorry we don’t have someone from there talking about where they are on their process. One of the ways of reducing those costs is to spread the cost to various consumer applications. How do we rapidly diversify the base of applications that are attractive to customers so as to adopt this technology voluntarily, while our governance structures are stumbling over each other to come up with a consensus approach?
[ Top ]
Scott Andrews answers:
We have to understand this historically. The first critical cost issue is communications. If you have to pay a carrier for communication, at some point it becomes a sizable percentage of the overall system operating costs. That was part of the motivation to go with the dedicated short-range communications (DSRC) solution. We built a completely generalized communication and processing system in the car and then a very generalized, almost Internet-like, network. The whole idea of that was we didn’t want to build a single purpose communication and computing system with only one application. We ended up testing five or six different applications. If you have the ability, in the car, to run a whole bunch of different applications, the cost associated with this is spread over a variety of different benefits, and each individual can choose what to have in the car.
John Kuhl replies:
If there is a profit to be made, then the private sector will find out how to make it. Would it be more cost effective to use DSRC infrastructure that is already present or use cellular structure? The cellular structure is already there. You don’t have a capital cost. Cell providers will say, "We want a blanket contract to provide the service for 250 million vehicles, and we are going to be competitive." The opportunity to make money is there and is going to be a big competition.
I want to take the discussion just a slightly different direction. Everybody has a phone. Everybody has had a problem with it. It probably failed at one point in time. In looking at deploying systems in terms of redundancy, in terms of storage of information and uploading information, how do we account for and how do we build systems so if we do have a failure, we have this recovery mechanism?
[ Top ]
Ray Starr replies:
In Minnesota, we read the odometer. It is to your advantage to keep it working and keep it there.
You have to account for all the weird things that people are going to do (unscrew devices, unplug, etc.) and design your systems to identify when that happens. You have to account for all the ways in which the systems are going to fail.
This is an issue we had to address in the national evaluation study. If something goes wrong with any aspect of the system, whether it is the communication, the GPS, the odometer readings, we get indications very quickly, in a few hours. It is an important problem, but it is one that you can address.
There has to be a secondary system, a secondary development, because people are smart. They are going to break it on purpose. That could mean manually reading the odometer.
I agree with the comments that technology supports policy. I think that policy makers need to be very well informed about a complete range of options that technology provides. I am worried that we may rush to some conclusions without fully understanding the potential. I also agree that there are no technology breakthroughs. However, I do think the selection of the technology choice is not trivial, and I think we owe it to ourselves to be very thoughtful about the range of capabilities and the trade offs between various technology choices. Depending on how we choose the technology, we can enable some other capabilities. We have the real ability to optimize the system and safety. As with this community, there is another community in a room, like this, somewhere else sitting around talking about establishing open interfaces into the vehicle and about doing the testing necessary to support the safety applications that will mandate the technology on the vehicle because of these safety applications. It would be a shame if we don’t fully explore all those synergistic options that we have at our disposal. We are working with Jim (Whitty) to do a relatively quick study on the range of technologies available and the capabilities that they can provide so that we can inform decision makers and make an informed decision. My last comment is that I think it is good to ask what the minimum set of requirements is, but we shouldn’t stop at the minimum set of requirements. We need to balance vision and pragmatism, technical feasibility with political feasibility; we may be able to sell something more together than apart.
[ Top ]
What do you do with older vehicles? If you are planning on retrofitting, how are you going to deal with these issues? If you are not planning on retrofitting, how do you plan on collecting these fees?
First of all, you have to wait until the point where the pay off of the distribution of vehicles that are problematic to deal with becomes small. At that point we will have to make special considerations for those vehicles. Vehicles that are too old for retrofitting technology simply need to be provided with an option. Either they are exempted from the system since they are such a small portion or provide some alternative means to pay the fee.
If I was a policy maker, from the technology viewpoint, is it reasonable to assume I can make a policy decision today and begin planning the deployment of the VMT pricing system that is implemented 10 years from now, or do I need to wait for a technology to be proved? I think if you wait for the technology to be proven, you’ll find there is a better technology. So I can make a comfortable policy decision today to do this, with the idea that if I decide to do it, the technology suppliers will find a way to make the system work.
I don’t see any real barrier other than older cars. I don’t see any specific technology barriers or any pricing barriers. There is plenty of ability to implement it today. It is just a question of deciding how.
I wonder if the best approach is for the government to design a channel and dictate it into the marketplace. A better policy decision is turn to the private sector and say, "Here is the problem I have to solve. Who can do this most efficiently, least expensively?" and allow the private sector to come up with some pilots. Allow the private sector to come up with ideas.
[ Top ]