The Self Driving Product — Part 2: Orientation & Ecosystem
A view from the trenches
Preamble
This series is split into 4 parts:
- Part 1 — Background
- Part 2 — Orientation & Ecosystem
- Part 3 — Autonomous Products
- Part 4 — The Lived Experience
All views expressed are entirely my own.
TL;DR — A reflection of 6 years in Autonomous Vehicles, the AV ecosystem, moving from engineering to product, and what makes doing product in AVs different.
An Ecosystem View
Let’s try an analogy. When asked to identify our favourite coffee shop we need to be clear about which city we are in to condition our answer. The AV ecosystem and associated value chain can be represented by three broad layers, ordered left-to-right by decreasing distance from the end customer:
There are a plethora of companies and startups addressing different subsets of the ecosystem. Some focus on specific components (e.g., Velodyne, Here), others on connecting services (e.g., Holo), and yet others are developing fully integrated vertical solutions (e.g., ZOOX, Caterpillar).
Note this breakdown holds for both on-road and off-road domains. While on-road applications get most press, the off-road ones are important proof and revenue points along the way.
For the purposes of this post the focus is on the first column: Providing specific AV technology, instantiated and configured for a defined set of ODDs & OEDRs.
Product != Product
To stick with the coffee analogy, we now know which city we are in. Now let’s be clear what we mean by coffee shop and agree on some definitions.
Product Definition
You could fill many pages about what constitutes a product, the difference between internal and external products, etc. In my view a product is a well defined artefact or service that…
- Satisfies a specific customer need…
- through an explicit business case…
- and competes in the market…
- with a long term roadmap…
- without an explicit end date.
The cost of implementation and distribution of a product should scale sublinearly with the number of customers. Else you are just hopping around from project to project.
AV Definition
Similarly, at a high level an autonomous vehicle consists of the following components:
- Base vehicle platform
- Sensor hardware
- Compute hardware
- On board autonomy software and associated safety systems
- Off board tools and services (e.g., mapping, data pipelines, remote assist suite, route commissioning, etc.)
The last point is important and generally gets less attention. However, ensuring a well integrated off board toolchain for development and support services is crucial to operating reliably at scale.
Given the components that make up an AV, for this post I draw the boundary around those that make up the Autonomous Driving System (ADS). These are all the components and procedures (on board and off board) that, when combined with hardware (sensors, compute, platform), deliver full L4 autonomous driving.
Axes of Autonomy
Building a reliable ADS is a complex business. Many capabilities and workflows need to be developed, integrated, validated, and maintained. Just like many different aspects need to come together to run a great coffee shop (atmosphere, pricing, ingredients, …). These capabilities and workflows can themselves be situated on a multi-dimensional space characterised by 5 axes:
- Autonomous Capability: The level of autonomy the ADS is able to achieve and what ODD & OEDR elements are supported (e.g., highway vs container terminal)
- System specification, safety, and standards: The specifications and standards the ADS (and its development) needs to adhere to for series production and commercial operation. E.g., SOTIF, ASPICE, ISO 23725, …
- Production Runtime Platform: The runtime environment (compute, sensors, OS, interfaces) that the ADS needs to support at production. E.g, QNX, ASIL-D hardware, …
- 3rd Party operation, support, and scale: The surrounding tooling, processes, and documentation needed to enable 3rd party integration, operation, and support at scale.
- Visibility & Packaging: The way in which the ADS is presented and demonstrated. These are the product features and integrations that are needed to support sales, marketing, and pilot activities.
As a product person in the ADS space one should care about all axes and thread a roadmap through time to ensure they all line up. Though the last one is always a harder sell to Engineers.
Adaptations
Finally, there is the question of the type of coffee shop we have in mind. I.e, defining what adaptations and integrations are needed (and at what ecosystem levels) to the ADS in order to achieve & support ODD specific use cases and production platforms.
Are we building a system that will move people, cucumbers, or iron ore? Additionally, how long will it take to implement, verify and validate those adaptations to a core autonomy system and who is going to do that? This is a big question in it’s own right and much depends on the degree you can push the autonomy (safety) problem onto operational constraints.
This is a topic worthy of its own post. But for the remainder of this series, when referring to an ADS, you can assume something like an autonomous urban shuttle transport solution.
— Dirk