Submitted by brad on Mon, 2015-02-02 20:31.
I commonly see statements from connected car advocates that vehicle to vehicle (V2V) and vehicle to infrastructure communications are an important, even essential technology for robocar development. Readers of this blog will know I disagree strongly, and while I think I2V will be important (done primarily over the existing mobile data network) I suspect that V2V is only barely useful, with minimal value cases that have a hard time justifying its cost.
Of late, though, my forecast for V2V grows even more dismal, because I wonder if robocars will implement V2V with human-driven cars at all, even if it becomes common for ordinary cars to have the technology because of a legal mandate.
The problem is security. A robocar is a very dangerous machine. Compromised, it can cause a lot of damage, even death. As such, security will have a very strong focus in development. You don’t want anybody breaking into the computer systems or your car or anybody else’s. You really don’t want it.
One clear fact that people in security know — a very large fraction of computer security breaches caused by software faults have come from programs that receive input data from external sources, in particular when you will accept data from anybody. Internet tools are the biggest culprits, and there is a long history of buffer overflows, injection attacks and other trouble that has fallen on tools which will accept a message from just anyone. Servers (which openly accept messages from outside) are at the greatest risk, but even client tools like web browsers run into trouble because they go to vast numbers of different web sites, and it’s not hard to trick people to sending them to a random web site.
We work very hard to remove these vulnerabilities, because when you’re writing a web tool, you have no choice. You must accept input from random strangers. Holes still get found, and we pay the price.
The simplest strategy to improve your chances is to go deaf. Don’t receive inputs from outside at all. You can’t do that in most products, but if you can close off a channel without impeding functionality it’s a good approach. Generally you will do the following to be more secure:
- Be a client, which means you make communications requests, you do not receive them.
- You only connect to places you trust. You avoid allowing yourself to be directed to connect to other things
- You use digital signature and encryption to assure that you really are talking to your trusted server.
This doesn’t protect you perfectly. Your home server can be compromised — it often will be running in an environment not as locked down as this. In fact, if it becomes your relay for messages from outside, as it must, it has a vector for attack. Still, the extra layer adds some security. read more »
Submitted by brad on Mon, 2014-02-17 10:06.
It was revealed earlier this month that NHTSA wishes to mandate vehicle to vehicle radios in all cars. I have written extensively on the issues around this and regular readers will know I am a skeptic of this plan. This is not to say that I don’t think that V2V would not be useful for robocars and regular cars. Rather, I believe that its benefits are marginal when it comes to the real problems, and for the amount of money that must be spent, there are better ways to spend it. In addition, I think that similar technology can and will evolve organically, without a government mandate, or with a very minimal one. Indeed, I think that technology produced without a mandate or pre-set standards will actually be superior, cheaper and be deployed far more quickly than the proposed approach.
The new radio protocol, known as DSRC, is a point-to-point wifi style radio protocol for cars and roadside equipment. There are many applications. Some are “V2V” which means cars report what they are doing to other cars. This includes reporting one’s position tracklog and speed, as well as events like hitting the brakes or flashing a turn signal. Cars can use this to track where other cars are, and warn of potential collisions, even with cars you can’t see directly. Infrastructure can use it to measure traffic.
The second class of applications are “V2I” which means a car talks to the road. This can be used to know traffic light states and timings, get warnings of construction zones and hazards, implement tolling and congestion charging, and measure traffic.
This will be accomplished by installing a V2V module in every new car which includes the radio, a connection to car information and GPS data. This needs to be tamper-proof, sealed equipment and must have digital certificates to prove to other cars it is authentic and generated only by authorized equipment.
Robocars will of course use it. Any extra data is good, and the cost of integrating this into a robocar is comparatively small. The questions revolve around its use in ordinary cars. Robocars, however, can never rely on it. They must be be fully safe enough based on just their sensors, since you can’t expect every car, child or deer to have a transponder, ever.
One issue of concern is the timeline for this technology, which will look something like this:
- If they’re lucky, NHTSA will get this mandate in 2015, and stop the FCC from reclaiming the currently allocated spectrum.
- Car designers will start designing the tech into new models, however they will not ship until the 2019 or 2020 model years.
- By 2022, the 2015 designed technology will be seriously obsolete, and new standards will be written, which will ship in 2027.
- New cars will come equipped with the technology. About 12 million new cars are sold per year.
- By 2030, about half of all cars have the technology, and so it works in 25% of accidents. 3/4 of those will have the obsolete 2015 technology or need a field-upgrade. The rest will have soon to be obsolete 2022 technology. Most cars also have forward collision warning by this point, so V2V is only providing extra information in a tiny fraction of the 25% of accidents.
- By 2040 almost all cars have the technology, though most will have older versions. Still, 5-10% of cars do not have the technology unless a mandate demands retrofit. Some cars have the equipment but it is broken.
Because of the quadratic network effect, in 2030 when half of cars have the technology, only 25% of car interactions will be make use of it, since both cars must have it. (The number is, to be fair, somewhat higher as new cars drive more than old cars.) read more »
Submitted by brad on Thu, 2013-03-21 22:37.
Earlier in part one I examined why it’s hard to make a networked technology based on random encounters. In part two I explored how V2V might be better achieved by doing things phone-to-phone.
For this third part of the series on connected cars and V2V I want to look at the potential for broadcast data and other wide area networking.
Today, the main thing that “connected car” means in reality is cell phone connectivity. That began with “telematics” — systems such as OnStar but has grown to using data networks to provide apps in cars. The ITS community hoped that DSRC would provide data service to cars, and this would be one reason for people to deploy it, but the cellular networks took that over very quickly. Unlike DSRC which is, as the name says, short range, the longer range of cellular data means you are connected most of the time, and all of the time in some places, and people will accept nothing less.
I believe there is a potential niche for broadcast data to mobile devices and cars. This would be a high-power shared channel. One obvious way to implement it would be to use a spare TV channel, and use the new ATSC-M/H mobile standard. ATSC provides about 19 megabits. Because TV channels can be broadcast with very high power transmitters, they reach almost everywhere in a large region around the transmitter. For broadcast data, that’s good.
Today we use the broadcast spectrum for radio and TV. Turns out that this makes sense for very popular items, but it’s a waste for homes, and largely a waste for music — people are quite satisfied instead with getting music and podcasts that are pre-downloaded when their device is connected to wifi or cellular. The amount of data we need live is pretty small — generally news, traffic and sports. (Call in talk shows need to be live but their audiences are not super large.)
A nice broadcast channel could transmit a lot of interest to cars.
- Timing and phase information on all traffic signals in the broadcast zone.
- Traffic data, highly detailed
- Alerts about problems, stalled vehicles and other anomalies.
- News and other special alerts — you could fit quite a few voice-quality station streams into one 19 megabit channel.
- Differential GPS correction data, and even supplemental GPS signals.
The latency of the broadcast would be very low of course, but what about the latency of uploaded signals? This turns out to not be a problem for traffic lights because they don’t change suddenly on a few milliseconds notice, even if an emergency vehicle is sending them a command to change. If you know the signal is going to change 2 seconds in advance, you can transmit the time of the change over a long latency channel. If need be, a surprise change can even be delayed until the ACK is seen on the broadcast channel, to within certain limits. Most emergency changes have many seconds before the light needs to change.
Stalled car warnings also don’t need low latency. If a car finds itself getting stalled on the road, it can send a report of this over the cellular modem that’s already inside so many cars (or over the driver’s phone.) This may take a few seconds to get into the broadcast stream, but then it will be instantly received. A stalled car is a problem that lasts minutes, you don’t need to learn about it in the first few milliseconds.
Indeed, this approach can even be more effective. Because of the higher power of the radios involved, information can travel between vehicles in places where line of sight communications would not work, or would actually only work later than the server-relayed signal. This is even possible in the “classic” DSRC example of a car running a red light. While a line of sight communication of this is the fastest way to send it, the main time we want this is on blind corners, where LoS may have problems. This is a perfect time for those longer range, higher power communications on the longer waves.
Most phones don’t have ATSC-M/H and neither do cars. But receiver chips for this are cheap and getting cheaper, and it’s a consumer technology that would not be hard to deploy. However, this sort of broadcast standard could also be done in the cellular bands, at some cost in bandwidth for them.
19 megabits is actually a lot, and since traffic incidents and light changes are few, a fair bit of bandwidth would be left over. It could be sold to companies who want a cheaper way to update phones and cars with more proprietary data, including map changes, their own private traffic and so on. Anybody with a lot of customers might fight this more efficient. Very popular videos and audio streams for mobile devices could also use the extra bandwidth. If only a few people want something, point to point is the answer, but once something is wanted by many, broadcast can be the way to go.
What else might make sense to broadcast to cars and mobile phones in a city? While I’m not keen to take away some of the nice whitespaces, there are many places with lots of spare channels if designed correctly.
Submitted by brad on Mon, 2013-03-18 16:28.
Last week, I began in part 1 by examining the difficulty of creating a new network system in cars when you can only network with people you randomly encounter on the road. I contend that nobody has had success in making a new networked technology when faced with this hurdle.
This has been compounded by the fact that the radio spectrum at 5.9ghz which was intended for use in short range communications (DSRC) from cars is going to be instead released as unlicenced spectrum, like the WiFi bands. I think this is a very good thing for the world, since unlicenced spectrum has generated an unprecedented radio revolution and been hugely beneficial for everybody.
But surprisingly it might be something good for car communications too. The people in the ITS community certainly don’t think so. They’re shocked, and see this as a massive setback. They’ve invested huge amounts of efforts and careers into the DSRC and V2V concepts, and see it all as being taken away or seriously impeded. But here’s why it might be the best thing to ever happen to V2V.
The innovation in mobile devices and wireless protocols of the last 1-2 decades is a shining example to all technology. Compare today’s mobile handsets with 10 years ago, when the Treo was just starting to make people think about smartphones. (Go back a couple more years and there weren’t any smartphones at all.) Every year there are huge strides in hardware and software, and as a result, people are happily throwing away perfectly working phones every 2 years (or less) to get the latest, even without subsidies. Compare that to the electronics in cars. There is little in your car that wasn’t planned many years ago, and usually nothing changes over the 15-20 year life of the car. Car vendors are just now toying with the idea of field upgrades and over-the-air upgrades.
Car vendors love to sell you fancy electronics for your central column. They can get thousands of dollars for the packages — packages that often don’t do as much as a $300 phone and get obsolete quickly. But customers have had enough, and are now forcing the vendors to give up on owning that online experience in the car and ceding it to the phone. They’re even getting ready to cede their “telematics” (things like OnStar) to customer phones.
I propose this: Move all the connected car (V2V, V2I etc.) goals into the personal mobile device. Forget about the mandate in cars.
The car mandate would have started getting deployed late in this decade. And it would have been another decade before deployment got seriously useful, and another decade until deployment was over 90%. In that period, new developments would have made all the decisions of the 2010s wrong and obsolete. In that same period, personal mobile devices would have gone through a dozen complete generations of new technology. Can there be any debate about which approach would win? read more »
Submitted by brad on Wed, 2013-03-06 15:45.
A few weeks ago, in my article on myths I wrote why the development of “vehicle to vehicle” (V2V) communications was mostly orthogonal to that of robocars. That’s very far from the view of many authors, and most of those in the ITS community. I remain puzzled by the V2V plan and how it might actually come to fruition. Because there is some actual value in V2V, and we would like to see that value realized in the future, I am afraid that the current strategy will not work out and thus misdirect a lot of resources.
This is particularly apropos because recently, the FCC issued an NPRM saying it wants to open up the DSRC band at 5.9ghz that was meant for V2V for unlicenced wifi-style use. This has been anticipated for some time, but the ITS community is concerned about losing the band it received in the late 90s but has yet to use in anything but experiments. The demand for new unlicenced spectrum is quite appropriately very large — the opening up of 2.4gz decades ago generated the greatest period of innovation in the history of radio — and the V2V community has a daunting task resisting it.
In this series I will examine where V2V approaches went wrong and what they might do to still attain their goals.
I want to begin by examining what it takes to make a successful cooperative technology. History has many stories of cooperative technologies (either peer-to-peer or using central relays) that grew, some of which managed to do so in spite of appearing to need a critical mass of users before they were useful.
Consider the rise and fall of fax (or for that matter, the telephone itself.) For a lot of us, we did not get a fax machine until it was clear that lots of people had fax machines, and we were routinely having people ask us to send or receive faxes. But somebody had to buy the first fax machine, in fact others had to buy the first million fax machines before this could start happening.
This was not a problem because while one fax machine is useless, two are quite useful to a company with a branch office. Fax started with pairs of small networks of machines, and one day two companies noticed they both had fax and started communicating inter-company instead of intra-company.
So we see rule one: The technology has to have strong value to the first purchaser. Use by a small number of people (though not necessarily just one) needs to be able to financially justify itself. This can be a high-cost, high-value “early adopter” value but it must be real.
This was true for fax, e-mail, phone and many other systems, but a second principle has applied in many of the historical cases. Most, but not all systems were able to build themselves on top of an underlying layer that already existed for other reasons. Fax came on top of the telephone. E-mail on top of the phone and later the internet. Skype was on top of the internet and PCs. The underlying system allowed it to be possible for two people to adopt a technology which was useful to just those two, and the two people could be anywhere. Any two offices could get a fax or an e-mail system and communicate, only the ordinary phone was needed.
The ordinary phone had it much harder. To join the phone network in the early days you had to go out and string physical wires. But anybody could still do it, and once they did it, they got the full value they were paying for. They didn’t pay for phone wires in the hope that others would some day also pay for wires and they could talk to them — they found enough value calling the people already on that network.
Social networks are also interesting. There is a strong critical mass factor there. But with social networks, they are useful to a small group of friends who join. It is not necessary that other people’s social groups join, not at first. And they have the advantage of viral spreading — the existing infrastructure of e-mail allows one person to invite all their friends to join in.
Enter Car V2V
Car V2V doesn’t satisfy these rules. There is no value for the first person to install a V2V radio, and very tiny value for the first thousands of people. An experiment is going on in Ann Arbor with 3,000 vehicles, all belonging to people who work in the same area, and another experiment in Europe will equip several hundred vehicles. read more »
Submitted by brad on Sun, 2013-01-13 23:32.
There’s been a lot of press on robocars in the last few months, and a lot of new writers expressing views. Reading this, I have encountered a recurring set of issues and concerns, so I’ve prepared an article outlining these top myths and explaining why they are not true.
Perhaps of strongest interest will be one of the most frequent statements — that Vehicle to Vehicle (V2V) communication is important, or even essential, to the deployment of robocars. The current V2V (and Vehicle to Infrastructure) efforts, using the DSRC radio spec are quite extensive, and face many challenges, but to the surprise of many, this is largely orthogonal to the issues around robocars.
So please read The top 10 (or so) myths or robocars.
- They won’t be safe
- The big issue is who will be liable in a crash
- The cars will need special dedicated roads and lanes
- This only works when all cars are robocars and human driving is banned
- We need radio links between cars to make this work
- We wont see self-driving cars for many decades
- It is a long time before this will be legal
- How will the police give a robocar a ticket?
- People will never trust software to drive their car
- They can’t make an OS that doesn’t crash, how can they make a safe car?
- We need the car to be able to decide between hitting a schoolbus and going over a cliff
- The cars will always go at the speed limit
You may note that this is not my first myths FAQ, as I also have Common objections to Robocars written when this site was built. Only one myth is clearly in both lists, a sign of how public opinion has been changing.