Data is the New Snake Oil in the Future of Automated Driving

Being a long-term Intel Corp. stock holder, I am becoming very concerned about the pattern of behavior practiced by Intel Corp. top executives over the last three years. It is becoming clearer by the minute that top management is clueless about how to utilize the company human capital and where to take the company into the future. The large number of PR appearances by the current CEO, trying to make a splash in the news may be an indication that selling PR is the current core focus of the company.

Apparently, executive management's assessment of their internal human capital is so low that they have resorted to spending very large amounts of capital for purchasing other companies. From my recent conversations with friends and colleagues who work at Intel, I understand that Intel Corp. has significant problems in plans execution due to perceived management incompetence and lack of trust, both inside internal organizations as well as among external organizations. The latest sales figures in the Data Center, crown jewel business unit, did not do well for Intel stock either.

Yesterday, an article published in ZDnet (Intel announces new investment $250M in autonomous driving) caught my eye. On the face of it I was enthused about the message, until I began reading the content. It turns out that the source for this article was a blog post by no other than BK, who published an article entitled: Data is the New Oil in the Future of Automated Driving.

In this article, BK makes an argument that autonomous cars are going to produce a very large amount of data on a daily basis and Intel Corp. is in the best position in the industry to fulfill the requirements for handling this data deluge. The graphic accompanying BK's article is shown below.

It is not very clear to me what BK is trying to say in this blog article, other than implying that autonomous cars would contribute to a massive growth of the Data Center business. Regardless, let us examine this wishful thinking idea.

If we take it at face value and begin looking at BK's message, starting with the largest number in the above picture, 4TB of data a day per car is an impressive rate requirement for today's technological reality. The open questions are: what does this number represent? How is this number derived? Does the number represent actionable information?

The need for communication infrastructure to move 4TB/day of data from all new cars deployed on the market seems like a good opportunity--too good to pass up for companies like AT&T, Verizon, T-Mobile, etc. Why is it that we don't hear much from these communication infrastructure titans on this subject? In the absence of communication infrastructure that could handle such a massive amount of data, having excessive Data Center capacity does not mean much.

There is even the fundamental question of whether it would be wise to connect autonomous cars to Data Centers (cloud) if potentially this would open new security vulnerabilities.  Are we not facilitating new avenue for a national adversary or a terrorist organization to inflict major damage on targeted transportation hot-spots by hacking into autonomous cars? Did we forget that some bad dudes have already used standard transportation vehicles (airplanes) to inflict physical damage upon U.S. lives and physical property in the early 21st Century? What does it take to hijack a million autonomous cars through the Internet and recruit them to do you evil bidding from a safe distance away?

Assuming that the flow is limited to one-way (from car to Data Center) it is not clear why we need to transfer raw data to the data center at all. Most of the data collected from various sensors is aggregated anyhow, in the process of "making sense" of it during real-time processing. Most of the raw data becomes irrelevant in a matter of a few seconds, as the car continues moving. Unless, of course, your interest is to spy on the passengers (see: https://en.wikipedia.org/wiki/Person_of_Interest_(TV_series)).

Expecting privacy in your car? A legal warrant to track your whereabouts would no longer be necessary due to SCOTUS deciding that once your car is connected to the "cloud" you cannot expect to be protected by the 4th amendment. However, the government would be the least of your problems; you are more than likely to have beef with your jealous wife or your daughter's stoker. All that stokers will have to do is pay their $7.99/month fee to the "life means money to us" corporation to watch the action in the rear seat of your car. Unscrupulous auto makers (Volkswagen?) may even cut a deal for implanting "special purpose software extensions" that serve the interest of any other party but yourself, inside your car. The number of YouTube "streaming reality" channels will exceed 3 billion by then...

Regarding the data rates quoted in BK's blog article, even if I only look at the GPS sensor data rate that he is using, I already see a major flaw. Every GPS sensor that is suitable for mobile use and is available on the market today, can update its absolute position information only once per second. This behavior is derived from the inherent design limitations of the Civilian L1 carrier system. Some GPS sensors claim to provide faster update rate through post-processing and mathematical extrapolation of the GPS data. They claim to provide perhaps as high as 20 updates per second at a lower reliability rate. Time of Flight (TOF) methods can produce better dynamic accuracy; however they cannot be utilized within the current transportation systems due to lack of ground station infrastructure.

Since GPS location information for automotive use only requires 2D data (Latitude/Longitude), this information can be simply represented as a pair of floating-point numbers. A floating point number is contained in four bytes of information. The pair of Lat/Lon information will therefore occupy only eight bytes. Assuming that some communication overhead is required for conveying Geo position from a GPS sensor we can increase the message size to 16 bytes per location report. Even at an exorbitant rate of 20 update per second we would need a communication rate of about 320 bytes per second. Even if we increase this rate to 500 bytes per second, this value is only 1/100th of what BK is claiming in his blog article.

I do not wish to continue and dissect each one of the numbers in the presentation slide or the blog article to validate if what is claimed there are true facts. I believe that it is the responsibility of Intel Corp. to answer all of the above questions and either correct them or stand by their CEO's statements.

If we take a different angle to the issue, perhaps BK meant to say that Intel Corp. is about to develop a Mega Chip that will incorporate all the elements necessary to implement an autonomous car on a single SOC.

When I studied and researched distributed systems in the late 1970's and early 1980's, most of the ideas in this field manifested themselves in a large heap of papers and a few academic projects. The cost of hardware dominated the field and both machines and communication mechanisms were too slow to implement an effective and practical systems solution. In the 21st Century, this picture has dramatically changed as hardware became cheap and abundant and communication technology kept pace with the need to connect all parts of a system together. Though the major emphasis in the field was on large systems with homogeneous components, the low cost of computing hardware brought on the era of application-specific processing and with it the growth of heterogeneous distributed systems.

The best example for such a heterogeneous system is the Smart Phone. Even though typically a smart phone has a component known as the Application Processor, in actuality, a complete smart phone system contains a multitude of compute engines (micro-controllers) that perform subsystem-specific functions, independently and concurrently with the application processor. A good example for such distributed functions are the radio-based subsystems (modems). Each radio-based interface, whether GPS, Bluetooth, WiFi, or cellular phone utilizes at least one embedded micro-controller. Same goes for the camera interfaces and the display controller.

(click to enlarge)

By nature, cars were a fertile ground for heterogeneous distributed systems, as electronic systems began replacing a variety of mechanical and hydraulic devices with electrical ones. Nowadays, all newer cars incorporate a multitude of computer controlled functions and these functions are completely distributed according to their designated functions while communicating among themselves via a common communication mechanism (typically CAN Bus). The above image demonstrates the typical functional distribution of autonomous car architecture.

While the idea of concentrating all car functions into a single general purpose "mega component" (SOC) seems good for economical reasons, in practice, it does not match the requirements for a variety of reasons:

1. As cars go through years of service, internal subsystems tend to wear out or break down. Most servicing in today's cars is done by component or module replacement, rather than by machining or direct repair. If even a minor malfunction requires replacement of a mega-component, the economic advantages of the modular repair become moot.
2. Safety and reliability considerations preclude the incorporation of a "single point of failure" anywhere within the system domain. From this perspective alone, there are great advantages to maintaining functional distribution and domain separation. Relying on mega-components to cover all functions is contrary to any safety-centered design philosophy.
3. Most of today's sensors provide post-processing functions that reduce the data rate coming out of the sensor due to optimization algorithms implemented in the embedded controllers on-board the sensor. Being late into the game, Intel Corp. cannot offer significant cost savings by incorporating such functions in a future SOC.
4. The significance of the flagship X86 ISA in the automotive market is close to nil.

It is likely that Intel Corp. will have to compete with companies that ventured into the autonomous car market earlier. Companies like Nvidia and potentially Google and Apple. None of these companies were interested in a Mega SOC solution. They all put the emphasis on the higher-level application-specific architecture required for pattern recognition, classification, machine learning and decision making aspects of autonomous car architecture. Intel Corp. does not have any specific advantage in these areas of data processing and as mentioned earlier, the proprietary X86 ISA is quite meaningless for handling this processing domain.

Spending $250,000,000 on entry into the automotive market may be the right move for Intel Corp., even if this move is so late in the game. However, if this strategic move is so loosely based on thin grounds as BK explained in his blog article, I remain extremely worried about my stock holdings value sinking again.

--Dr. Flywheel

If you like this article please share with your friends and relatives by clicking on the icon below, representing your favorite social network.