Elon: "Feature complete for full self driving this year"

[J1mbo]

In a fantasy world with 100% saturation of V2V, you don't need lane markers, speed limits, red lights, stop signs, etc. Those exist to keep cars from hitting each other.

And cycles... scooters... pedestrians... guide dogs... etc.

Physical V2x is a dead end. A logical conclusion of AV saturation will be standardised traffic control. This is more likely to be a real-time map overlay than having to have dedicated hardware installed in every vehicle and piece of roadside furniture.

 

[CrayZ1]

Did the police look at the video from the Cruise vehicle?

Cruise has taken billions of dollars in funding. If their vehicles get into fewer accidents than a human driver I can't see how liability could be a problem even if they are wrongly held liable for accidents where they are not at fault.

Deep pockets. If they were at fault it would be millions.

If someone runs into you in traffic and it's not your fault, does your bank account determine liability? Yes it does in the US.

 

[CrayZ1]

And cycles... scooters... pedestrians... guide dogs... etc.

Physical V2x is a dead end. A logical conclusion of AV saturation will be standardised traffic control. This is more likely to be a real-time map overlay than having to have dedicated hardware installed in every vehicle and piece of roadside furniture.

V2V is not a replacement for AV. It is an augmentation. You will detect more cycles, scooters, people, animals, potholes, etc with V2V than without it.

 

[Daniel in SD]

Deep pockets. If they were at fault it would be millions.

If someone runs into you in traffic and it's not your fault, does your bank account determine liability? Yes it does in the US.

Only because there’s no point getting a large settlement from someone who has no money, they’ll just declare bankruptcy. Like I said before there are probably over a million vehicles in California owned and operated by corporations with deep pockets.

 

[linux-works]

Devils advocate here.

You can judge that by visually looking at the situation as well. Also that is mission critical information that has to have 0 latency, and if the server is down, you're screwed. If you have direct car-to-car communication it means that it has to be super secure, and make sure 110% that you can't spoof the signal of your own car sending incorrect information. Causing cars to behave erratic and disrupt the whole thing.
In car-to-car communication you are actually sitting on the "server" in your own car, which can be tampered with.
I view the downside of that way bigger than the potential upside.

there are secure ways to accomplish this, starting with secure-boot (which most companies are, at least, planning on).

as for the server latency, I've heard that the message frequency is something like 2000 msgs/sec that the front end processor has to parse and probably dispose of, for a lot of them. but this will be a dedicated core in a multicore ASIL environment and as long as your architecture has accounted for this, it should not be a problem. adding it in aftewards would be a problem.

before I changed to the automotive field, I was a data/networking person and I have to admit, the networking aspect of v2x has me excited. networking was kind of boring and vehicle networks (ethernet, can, wireless) are a new twist (for me, at least).

level 4 will also require tight timing inside the car, so the next big update (really big update) would include things like PTP for very precise time keeping, on your car LAN. for scheduling ethernet packets (TSN is the new term for this) you do need microsecond level timing.

there is a new level of complexity that l4 cars will need. adding in v2x is just a small thing compared to the really big changes that are planned.

 

[ChrML]

Devils advocate here.

You can judge that by visually looking at the situation as well. Also that is mission critical information that has to have 0 latency, and if the server is down, you're screwed. If you have direct car-to-car communication it means that it has to be super secure, and make sure 110% that you can't spoof the signal of your own car sending incorrect information. Causing cars to behave erratic and disrupt the whole thing.
In car-to-car communication you are actually sitting on the "server" in your own car, which can be tampered with.
I view the downside of that way bigger than the potential upside.

For traffic jams etc you can use the server, that is sort of in place at Tesla where it can choose a detour if there's too much traffic. Yes I know it's very "low level" / "basic" version of realtime traffic queue arrangement.

This is really not a problem, or nearly as difficult as you try to make it.

People have been sending sensitive data across insecure lines, wireless and Wifi for decades. This is a solved problem, why make it one?

Just use standard signed certificates with asymmetric encryption, with a 3 level certificate chain. Let a few trusted regulatory organizations have the root signing certificate. Car manufacturers have the 2nd level certificates, and each car has the 3rd level certificate. Car only has private key for the 3rd level, signed for a distinct car identifier, something like "manufacturer/SN" (but anonymized for GDPR).

Now any car can transmit any message directly to any car, and the receiving car can verify it's the real car that signed the message. Beauty with this is that you don't need to ask the cloud to verify, and it's a quick compute to check, so latency is a non-issue.

For security you now need to consider only this:

1. A cloud-managed list of revoked certificates from blacklisted/tampered cars, same as for websites. Does not need to be realtime.

2. Receivers to be conservative what type of info to trust or not. You can use V2V infovfor help and hints to increase safety and efficiency, but you cannot use it to override local driving policy if your own sensors conclude it's a bad course.

3. A way to detect cars that often miscommunicate or are tampered with, maybe a kind of manufacturer specific voting system. So they can be blacklisted. These cars cannot cause accidents, but they can cause slowdowns.

 

[ChrML]

1. A cloud-managed list of revoked certificates from blacklisted/tampered cars, same as for websites. Does not need to be realtime.

Or eventually you can time-limit them to a short duration, and you won't need the public blacklist. But then the 3rd level certificates will rotate, car manufacturer issues new certificates to every car every day. Probably easier, better and more secure than permanent certificates stored in each car.

Manufacturer still needs a private blacklist to avoid issuing new certificates to blacklisted cars.

 

[emmz0r]

there are secure ways to accomplish this, starting with secure-boot (which most companies are, at least, planning on).

TPM chip is hiding the keys, granted, but exchange and authentication can be accessed by connecting to them physically (by probing / soldering) to authenticate with the server. Since these devices have to run without requiring a password prompt. Secure boot works because you have to enter a password to decrypt using keys hidden away in the chip separated from the drive. If you have the chip (it has nvram so it will keep it's keys even if you rip it off the board) there's nothing stopping you really. Or did I miss something?

Then, I assume there's a spec / RFC for the standard, giving you a TPM chip you can use to authenticate given that you reverse engineer the entire authentication process. With local access to hardware, everything is possible, which people WILL have since they are in the car

https://www.forbes.com/sites/daveywinder/2020/01/09/can-you-hack-a-tesla-model-3-500000-says-that-you-cant

Those hacking competitions excludes you from probing into the actual hardware, I think.

So my thought is that yeah it's useful for non-critical communication. That is, the communication should not directly control your car.

The consequences might not be big anyway, since there probably is going to be consensus algorithms catching erratic data.

as for the server latency, I've heard that the message frequency is something like 2000 msgs/sec that the front end processor has to parse and probably dispose of, for a lot of them. but this will be a dedicated core in a multicore ASIL environment and as long as your architecture has accounted for this, it should not be a problem. adding it in aftewards would be a problem.

Yeah I was thinking of a cloud service with millions of cars connected to it with adequate response to all the other cars to avoid direct communication between the cars.

before I changed to the automotive field, I was a data/networking person and I have to admit, the networking aspect of v2x has me excited. networking was kind of boring and vehicle networks (ethernet, can, wireless) are a new twist (for me, at least).

level 4 will also require tight timing inside the car, so the next big update (really big update) would include things like PTP for very precise time keeping, on your car LAN. for scheduling ethernet packets (TSN is the new term for this) you do need microsecond level timing.

E.g. EtherCAT can be very responsive. I have worked on that

 

[ChrML]

TPM chip is hiding the keys, granted, but exchange and authentication can be accessed by connecting to them physically (by probing / soldering) to authenticate with the server. Since these devices have to run without requiring a password prompt. Secure boot works because you have to enter a password to decrypt using keys hidden away in the chip separated from the drive. If you have the chip (it has nvram so it will keep it's keys even if you rip it off the board) there's nothing stopping you really. Or did I miss something?

Then, I assume there's a spec / RFC for the standard, giving you a TPM chip you can use to authenticate given that you reverse engineer the entire authentication process. With local access to hardware, everything is possible, which people WILL have since they are in the car

https://www.forbes.com/sites/daveywinder/2020/01/09/can-you-hack-a-tesla-model-3-500000-says-that-you-cant

Those hacking competitions excludes you from probing into the actual hardware, I think.

So my thought is that yeah it's useful for non-critical communication. That is, the communication should not directly control your car.

The consequences might not be big anyway, since there probably is going to be consensus algorithms catching erratic data.



Yeah I was thinking of a cloud service with millions of cars connected to it with adequate response to all the other cars to avoid direct communication between the cars.



E.g. EtherCAT can be very responsive. I have worked on that

I would definitely go for car-2-car, not car-2-cloud-2-car. There is no reason to go through the cloud, only adds latency. V2V can communicate in less than 1ms, through cloud minimum 50ms, typically 100-200ms. Plus who's going to run and pay for the cloud? There are many car manufacturers.

The beauty of security solutions is even if you have all the sourcecode, see all the communication traffic and know how authentication works, you still cannot hack it.

You can definitely extract the car's private key from the chipset. If you got the key, which you do cause you own the car, you can transmit any message as you. And if you somewhat protected the key, you can still trick your sensors. Which is why you need a blacklist that could be managed by the manufacturer, and is why your car never overrides local security from remote input.

 

[emmz0r]

I would definitely go for car-2-car, not car-2-cloud-2-car. There is no reason to go through the cloud, only adds latency. V2V can communicate in less than 1ms, through cloud minimum 50ms, typically 100-200ms. Plus who's going to run and pay for the cloud? There are many car manufacturers.

To have useful information you should have consensus from > 1 car to verify it's correct data. And before processing the situation, analyzing the objects etc it has to be done on each car before a result can be sent.

The beauty of security solutions is even if you have all the sourcecode, see all the communication traffic and know how authentication works, you still cannot hack it.

You can definitely extract the car's private key from the chipset. If you got the key, which you do cause you own the car, you can transmit any message as you. And if you somewhat protected the key, you can still trick your sensors. Which is why you need a blacklist that could be managed by the manufacturer, and is why your car never overrides local security from remote input.

So you CAN hack it You can by sending bogus data using the TPM chip which is authenticated. And that's why you would need consensus from multiple cars, much like a blockchain, and that will of course increase the latency.

 

[TerrapinThief]

If the car company is liable during FSD operation, I can't imagine one authorizing speeding while on FSD use. I suspect real FSD cars are going to drive following every rule, but you won't care since you will be asleep or reading a book or whatever.

There were a number of articles several years back about Google determining it was safer to have their cars violate the speed limit if it meant they were staying within the flow of traffic (within reason). Seems there were also problems related to crossing a double yellow line.

 

[ChrML]

To have useful information you should have consensus from > 1 car to verify it's correct data. And before processing the situation, analyzing the objects etc it has to be done on each car before a result can be sent.

So you CAN hack it You can by sending bogus data using the TPM chip which is authenticated. And that's why you would need consensus from multiple cars, much like a blockchain, and that will of course increase the latency.

Yeah, consensus from multiple cars could be a way to heighten the probability that the info is correct.

I think V2V can be compared to asking for directions. Most people you ask give you the correct directions, but there's always someone that point you in the complete wrong direction. If you got consensus, it's more likely to be correct. But if someone tell you to drive off a cliff, or even if that's the consensus, you're not going to do that.

 

[EVNow]

And cycles... scooters... pedestrians... guide dogs... etc.

Physical V2x is a dead end. A logical conclusion of AV saturation will be standardised traffic control. This is more likely to be a real-time map overlay than having to have dedicated hardware installed in every vehicle and piece of roadside furniture.

Yep.

In this country we can't even keep 100 year old bridges maintained so that they are not in danger of collapse. I can name a 100 different things that should be prioritized over some sci fi utopia.

 

[J1mbo]

V2V is not a replacement for AV. It is an augmentation. You will detect more cycles, scooters, people, animals, potholes, etc with V2V than without it.

I didn't say it was a replacement?

I was talking about V2x-specific hardware devices which talk directly to each other as being a dead end, likely to be replaced by (standardised) centralised control and monitoring as AVs become mainstream. I imagine this would be paid for and operated by the same authorities that manage traffic today.

 

[CrayZ1]

I didn't say it was a replacement?

I was talking about V2x-specific hardware devices which talk directly to each other as being a dead end, likely to be replaced by (standardised) centralised control and monitoring as AVs become mainstream. I imagine this would be paid for and operated by the same authorities that manage traffic today.

We can't even decide what charging format electric cars will be. What are the hopes of a government dealing with V2X?

 

[linux-works]

v2x is a suite of standards.

its gonna happen. its just a matter of how and when.

 

[daniel]

That was just the highlights. If you thought it was impressive, check out the full unedited demo. Yes, it is very impressive.

These demos are why I think we are closer than 10 years from L4. Mobileye is promising it in 5 years.

Thanks.

First, it is genuine. I also sent you the unedited video so you can see for yourself. Also, Mobileye is owned by Intel. I don't think they have anything to do with Microsoft.

That's encouraging. I must have misremembered or mis-read something.

 

[M3BlueGeorgia]

From recent (1/3/2020) job posts, they seem to be investing in more crowdsourced fleet mapping for NoA and Smart Summon:
Autopilot & Navigation Maps Engineer | Tesla

That's really good news because, in theory, Tesla have masses of data flowing in, but the maps continue to have a non-trivial level of obsolete and inaccurate information, starting with the speed limit database.

 

[linux-works]

you can't go by tesla job postings. some have been up for months and even a year.

its like fishing. they throw out a line even if they have no immediate need.

that said, I do wish tesla would start hiring a bit more than they have. there is SO much work to be done and I know they are horribly under-staffed.

 

[diplomat33]

From recent (1/3/2020) job posts, they seem to be investing in more crowdsourced fleet mapping for NoA and Smart Summon:
Autopilot & Navigation Maps Engineer | Tesla

I hope Tesla does put a lot of emphasis on maps because it is definitely a weak point in AP and NOA.