The first week I had my Kia Hybrid, I was sitting at a red light and pushed the button to turn on the radio. It was the on/off button for the engine. When the light turned green, the car went nowhere and a pickup truck driver behind me laid on the horn to let me know I was clogging up the intersection and his morning. However, I just had to press the ignition button and I was on my way again, and so was the truck behind me.
So, what happens when grid lock occurs from self-driving robotaxis getting stuck—like it did in San Francisco in August? Or, as it did in Austin two weeks ago on a busy Saturday night? A push of a button couldn’t clear these. At a minimum these roadblocks are an annoyance to those in or around the jam, and at the upper end, it can be downright dangerous, as when first responders are blocked from traveling from point A to point B.
In San Francisco, grid lock was reportedly due to festivalgoers chewing up all of the network bandwidth. When the robotaxis couldn’t reach the central server, which held much of the intelligence they needed to navigate the city, it resulted in a 10-car backup of robotaxis in the city’s North Shore neighborhood, and nearer to the festival, dozens of robotaxis were at a dead stop as they waited for the network to be restored.
The second traffic jam mentioned was in my hometown, Austin, TX. A robotaxi became stuck in an intersection. Unable to navigate itself out, a queue of self-driving robotaxis soon began to form behind it and there was a mess. This was reportedly due to an unexpected detour or possible heavy foot traffic, which led to more cars than expected on a route they wouldn’t normally take. A Cruise spokesperson stated programmers were unable to reroute the robotaxis fast enough.
Rand Corporation estimates that self-driving vehicles need to drive 11 billion physical test miles to match a human-level error rate. Even though automotive engineers are replacing physical test miles with test miles from simulations running in parallel, fully autonomous vehicles are not here yet. Today’s self-driving cars are what is known as a Level 3, (conditional driving automation) or Level 4 (high driving automation) and they are subject to geofencing, to limit the areas where they can travel.
Do we yank the robotaxis off the road until those 11 billion miles of test driving are done? No, I think the cat is well and truly out of the bag. Perhaps it is time to re-think the approach for a successful rollout. How do we quickly and cost-effectively improve the solution? In both cases, there is a need for an improved method of communication to keep the vehicles on the move.
In San Francisco, the lack of network bandwidth caused the cars to freeze as they couldn’t get the data they needed to continue. The first thought is to increase the bandwidth – but that is really pushing the can down the road. What is really needed is the ability for the cars to work without accessing the central server ‘all the time’. If there is no bandwidth through one communication protocal, then perhaps another can be used, with the cars themselves becoming hot-spots and creating ad-hoc networks between vehicles to share their information in the locale. As the vehicles move, so the connections change with other vehicles coming in and out of range – until full communication with the central server is restored.
In Austin, the challenge is a bit different. Geofencing keeps the cars inside a designated area, but there are times when a detour will take the robotaxis outside of their ‘comfort zone.’ There probably needs to be additional legislation from the city to enable these self-driving cars to travel in exceptional circumstances outside the approved area – and the vehicles themselves need to be able to do this, with rapid changes to their navigation policies and the appropriate data to enable safe travel. Once again, there is a need to be able to achieve this without necessarily having access to a central server, but to be able to use data from around themselves along with policy to enable safe onward journeys.
11 billion miles of test driving sounds like a lot. It really isn’t and we’ll get there. But even then, as it is now, data needs to be shared between the various (and often competing) participants, particularly when in real-world scenarios. Autonomous taxis securely sharing situational data with other commercial vehicles, first responders and private citizens will all need to be a part of the mix.
This is the problem we solve at Kinnami. Our software, AmiShare, is a secure resilient data mesh for the digital edge, specifically complex distributed environments. AmiShare is designed to handle operations in sporadic and low-bandwidth environments. And many digital edge applications need to be prepared for unstable networks or disrupted communication channels as standard, others applications for unforeseen circumstances. With AmiShare, Data is protected, secure and made available wherever and whenever it is needed.
There are times when stable networks fail to support apps that depend on them. Throwing on more bandwidth (and expense) does not have to be the answer. AmiShare is a software-only data management solution designed to support disconnected and autonomous environments and it enables ad-hoc networking with peer-to-peer data sharing (mesh).
The San Francisco traffic jam scenario could be avoided by the robotaxis themselves becoming hot-spots and by creating ultra-localized ad-hoc networks between the vehicles. In this way, when the central server cannot be reached, they can share information providing real-time situational awareness among the vehicles in the area. Connections are made opportunistically between vehicles while moving and as they move in and out of spheres of communications.
In the Austin case, the robotaxi safe zone could be temporarily expanded to accommodate special circumstances, like a detour funneling the traffic in a direction that defies the system logic of the robotaxi. AmiShare can be used to temporarily network and securely share operational information between disparate groups to improve autonomous operation. For those systems out of range of the central server, policy updates can be rapidly and efficiently pushed across the ad-hoc temporary network of systems, keeping the disruption to a minimum.
The issues in both San Francisco and Austin have raised new edge cases for autonomous vehicles, which now need to be addressed through changes in critical data sharing and management.
Data fuels innovation and the digital edge offers immense opportunities for new innovations in many industries, including self-driving automobiles, autonomous operations, remote monitoring and IoT. To support the next generation of autonomous digital edge applications, data processing and selected data continues to be moved from the data center to edge environments.
This brings new challenges and unreliable network connectivity is probably the most significant. Other challenges around local data storage, security and integrity, and efficient data transport need to be addressed to ensure data is resilient and available where and when it is needed. Technologies originally built for the data center addressing these requirements often don’t meet the needs of the new digital edge.
Kinnami has built the first of its kind secure peer-to-peer data mesh capable of extemporaneous connections, which addresses complex requirements and problems found in many digital edge applications. For more information, please download our Kinnami AmiShare white paper or email info@kinnami.com