openpilot is an open-source driving system developed by As the slogan ‘make driving chill’ reflects, the system aims at achieving partial automation (level 2), letting the software control both steering and acceleration, while the human is still responsible for environment monitoring and fallback performance. With the corresponding plug-and-play hardware, consisting of wiring to communicate with the bus of the car and a dashboard unit used for road monitoring, the performance of any of the 63 supported cars should be significantly enhanced and improved compared to factory functionality, for under $1000. is founded by George Hotz (aka geohot), known for sim-unlocking the first generation iPhone, developing various iOS jailbreaks and hacking the PlayStation 3 to side-load pirated games. In a recent presentation, Hotz states the ambition of openpilot to become the Android of car automation, comparing the Tesla performance to Apple. collects the driving data on a voluntary basis to constantly adjust the model and improve performance. So far, over 22 million kilometres of driving data has been collected since openpilot was made publicly available in 2015. As of January 2020, openpilot has 1500 monthly users. This number is expected to grow since the company recently made its first appearance on the 2020 edition of the Consumer Electronics Show (CES).

The system uses a pre-trained non-deterministic deep neural network to locally make driving decisions, written in Python 3. The Panda subsystem used to communicate with the car hardware is written in C and comes with certain timing guarantees. The system complies with ISO26262 road vehicles safety functionality and furthermore never overrules the factory default safety features.

Product Vision: Make Driving Chill

Problem Definition

Bob’s Traveling Problem

The advertising slogan of openpilot is ‘make driving chill’, indicating that apparently driving is currently not so chill. Imagine Bob who’s living in the US, he visits his family on a regular basis and therefore travels between his residence in Austin TX and his family in Houston TX. Public transport is rarely available along this 266 km route, and while taking a flight is the fastest way of traveling, Bob prefers saving both his wallet and the environment by utilizing his car.

From Vision To Architecture: How to use openpilot and live

Autonomous driving is a very simple task in theory, but still remains unsolved at large. How does openpilot tackle the problems that arise on the road?

When an autonomous car is in the garage

Addressing quality from a software point of view deserves some caution in openpilot’s case. Image yourself as an openpilot software engineer and picture a variety of cars driving around seamlessly and without active human efforts because the code you wrote is good. It sure is an awesome feeling. Now imagine a less cheerfull scene with a car collision, beware that this is not your average lightweight javascript view library, peoples lives depend on it. As the company rightly pointed out, quality is represented by the stability of the cars that are driven by their software (and partially hardware). Therefore assessing quality deserves an unusual integral approach in this non-deterministic context that the code runs in. Think about all the slightly different traffic lights at every corner of the street, think about quaint driving lanes with potholes, think about ludacris other drivers, no situation is the same. An autonomous car is not an ordinary car and a comma two is not an oridnary android device.

How even a single product can vary

In previous posts, we focused on the business, technical and quality side of openpilot. Today it’s time to zoom in on some different aspect that might not be the first thing that pops into your mind when thinking about the architecture of a software product: Variability! Now you might think, variability is everywhere or variability is unavoidable. In the world of software, both are true! This post will be dedicated to defining, identifying and coping with variability from an architectural point of view. We will do this by identifying the aspects of the software that are susceptible for variability and how individual components relate to each other. Subsequently we will look at the meta-side of variability and which effects it has on those concerned. Finally, we will have a look at openpilot’s strategy for managing variability.