AV Errata
Work in Progress - Latest Apr 9, 2020


AV (Atonmomus Vehicles) Errata - Defects Are Lurking
I like the idea of being delivered to my destination by AV. Spoiler Alert: There are no AV for sale. Some of the vendors AV hype storms are quieting down as reality set in. See Autonomus Vehicles

My primary concern about AV is developing, testing, and updating, hardware and software. Defects in computer systems is the way of things. They are lurking in AV hardware, component, and software stacks that are built with various vendor products. The stacks are evolving. Vendors do a herculean task of creating, testing, and updating their products. Some more than others. Fixing defects with updates is a fact of computer technology.

Updating may be the AV Achilles heal. Use Microsoft as an example. It has been developing, selling, and updating software since 1975. It became market-dominate in selling PC compatible operating system and office software suit markets. Microsoft updates still stumble sometimes. Some PC users and business IT staff dread Update Tuesday because of the collateral damage updates may inflict, but users and staff do not usually die.

Autonomous Vehicles Technology Stacks

The AV stacks deployed by different AV companies, use different combinations of hardware, components, and software. They may be more complex to develop, test, update and deploy, then what Microsoft experiences. I doubt many AV company comes close to matching Microsoft resources.

Hardware Stack

Let’s start by looking at the AV hardware stack. The core of this stack are computers with processors of various types and brands with billions of transistors. They are interconnected and woven to perform complex logic.

Experience through the years has shown defects exist in processors. Intel states "Intel, processors, chipsets, and desktop boards may contain design defects or errors known as errata, which may cause the product to deviate from published specifications." Some "errata" appear during vendor testing, some appear in customer product testing, and sometimes they are lurking until a complex logic state triggers them.

Microcode instructions are stored permanently in processors. They control the operation of the device. A processor instruction to add two numbers is an abstraction of microcode instructions that controls the processor circuity to add the numbers.

Some processor vendors have included means of applying update patches to the primary microcode instructions. They are applied every time the processor is booted up. Some processors have more than one set of microcode instructions. Only the primary microcode instructions are usually able to be updated.

The hardware components interconnecting collections of processors and devices may use programmable logic devices that are not readily updatable when defects are triggered.

Software Stack

Programmers write software to instructs processors how to solve tasks with specific rules, such as add two numbers and then multiply the sum by a third number. Instructions are bit patterns the processor microcode decodes to control the processor circuity to execute instructions.

Writing processor instruction by hand is difficult, error prone, and slow. Fortunately there are much better ways of writing programs.

Programming languages are abstractions of processor instructions. A compiler is a computer program that compiles instructions written in a programming language suitable for the task, into instructions for the processor to execute. When the unexpected happens, programmers have a plethora of hardware and software tools to help track down the "errata."

Probably the most complex part of the AV software stack are the various operating systems that are interconnected. Each manages the hardware, software, and common services of the computer they are running on. The AV software stacks, of operating systems, programming languages, compilers and programs are not perfect, are evolving, and need updating.

AV software is a combination top-down and bottom-up programming


Most contemporary programming is top-down. It emphasizes planning and program task-specific instructions. AV operating systems and programs use top-down programming to build structures for executing Artificial Intelligence (AI) programs .


Bottom-up programming is how artificial neural networks "learn" a task. It is a type of AI programming that is vaguely inspired by neural networks of the brain. Programming neural networks is unlike top-down programming that most programmers are familiar with. It requires data analysis, machine learning, and statistics skills.

Tasks are learned by processing numerous examples without being programmed with task-specific instructions. When learning begins the error rate is very high. While processing many more examples, learning is improved by neural networks adjusting numerous parameters to lower error rates. The solution is being programmed bottom-up by the neural network. When the error rate is acceptable, it has "learned" the task.

Some neural networks unexpectedly improve learning or does something that was unexpected. Explaining “why”, is difficult and may not be possible. Unlike top-down programming, bottom-up programming has few tools to help track down the “errata.”

Test Suites

I managed a team of programmers developing test suites for a computer manufacture to test products. Engineering and manufacturing loved and hated the test suites. It was loved when it found defects and hated because the complex logic triggering the “errata” could not be captured and used for update development testing.

The core design principle of the test suites was to behave like ocean tides. When the tide is out, the processor load, and data rates for input and output of orifices, such as disk, network, and other traffic were light. The processor load and data rates raised with the incoming tide. Every so often a tsunami hits and saturates the processor and data rates. Unlike earthly tides, the test suit tides happened randomly. The mixture of test cases and load generators were also random.

The test suite triggered processor, component, test case, programming library, compiler, operating system, and other errors, including errors in most vendor controllers.

The idea of testing complex AV systems like this may be helpful in delivering higher quality and safer products.



John at johntelford dot com
Portland, Oregon

© 2019, Built with asciidoctordev.com and a cast of creative APIs and apps

Back to - Tech Talk John