Software-Defined Vehicles Tesla Is Getting Rid of the Steering Wheel—Who Will Now Revamp the Development Process?

Related Vendor

SIMTOS (Seoul International Machine Tool Show)

Tesla has begun limited commercial operations in Austin with “Cybercabs”—vehicles that do not have a steering wheel or pedals. On the very same day, the U.S. National Highway Traffic Safety Administration (NHTSA) launched an investigation. The agency has since issued a Special Order requesting information on the technical and legal basis upon which Tesla has self-certified its compliance with the Federal Motor Vehicle Safety Standards.

The Cybercab thus highlights how the requirements for vehicle development are changing. This issue is also becoming a reality for the German market: Waymo is preparing a fully autonomous ride-hailing service in Munich and aims to launch it commercially toward the end of 2027. At the same time, the Holon urban is emerging as a Level 4 autonomous vehicle based on end-to-end digital product development. This brings German and European automakers closer to addressing the question of how vehicles can be efficiently further developed after they are manufactured.

Development After the Start of Production

In the traditional development model, a manufacturer works toward a defined product milestone. After the functions have been defined, implemented, and tested, production of a defined vehicle configuration begins at the Start of Production. In the case of a software-defined vehicle (SDV), development continues after the Start of Production. Features can be modified, expanded, or enabled after delivery via over-the-air updates. Each update thus becomes a development item. The manufacturer must be able to trace why a change was made, which configurations it affects, how it was tested, and who approved it.

When it comes to autonomous driving functions, this traceability is critical to safety. For example, a change to object detection may affect only certain combinations of sensors, computing platforms, and software versions. In addition, there may be implications for functional safety or homologation. Therefore, the vehicle series and model year are not sufficient for identification. Two vehicles that appear identical on the outside may have different software versions and system configurations. The development documentation must therefore extend all the way down to the specific vehicle.

UNECE Regulations R155 and R156 provide a regulatory framework for this. A simple question illustrates how robust the underlying process is: Can an automaker quickly identify which software version is active in a specific vehicle, what approval it is based on, and what tests were conducted for it? If this information first has to be pieced together from various systems, spreadsheets, and manual lists, the process is not suitable for a fleet whose software versions are constantly changing.

Software Becomes the Central Variant Level

Platform strategies can reduce the number of physical vehicle variants, but this does not eliminate complexity. Instead, it shifts to software versions, feature releases, country-specific variants, and dependencies between systems. However, an autonomous driving function depends on the entire vehicle architecture. Changes to sensor systems or related vehicle functions can therefore affect overall functionality.

A completed test is therefore not automatically valid for every combination of hardware, software, and market requirements. Automakers must precisely map test coverage and approval to a defined configuration status. Before making a change, impact analyses must identify which requirements, interfaces, and vehicle variants need to be retested. Rollback is also part of this process. If an update fails or has unexpected effects in the field, it must be determined which vehicles are affected and to which safe configuration they can be rolled back.

Separate Systems as Process Boundaries

In many development organizations, the information needed to make a change is scattered across different systems. Individual teams can work efficiently using local files and specialized tools. However, the transition points become critical. If information is transferred manually, different version states and gaps in the change history arise. This makes root cause analysis difficult even within a single company. With autonomous vehicles, the problem is exacerbated because multiple departments, suppliers, and software partners are involved in the same function.

Any deviation from the field must be traceable back to the affected function. Conversely, it must be clear which specific vehicles are authorized to receive a change from engineering. It is crucial that the relationships between the pieces of information remain unambiguous, versioned, and machine-readable.

ALM, PLM, and MBSE Working Together

Application Lifecycle Management (ALM), Product Lifecycle Management (PLM), and Model-Based Systems Engineering (MBSE) cover different aspects of this task. ALM links requirements to software development, testing, and approvals. PLM maps changes to the current product and vehicle configurations. MBSE describes functions, system architectures, interfaces, and dependencies.

However, it is only by linking them that the relationships between requirements, systems, and vehicle configurations become traceable and visible. For example, if a requirement for an autonomous function is changed, it must be possible to determine which software components and tests are affected. At the same time, it must be clear for which hardware configurations, markets, and vehicles the change is relevant. The Intelligent Product Lifecycle (IPL) provides a common development framework for this purpose. It links the relevant information—from the requirement through architecture, software status, and testing to the vehicle configuration in the field. This helps OEMs evaluate changes more quickly and document the necessary evidence in a more targeted manner. At the same time, it reduces the risk that a technically correct change will be rolled out to a configuration that has not been approved for it.

Responsibility for the Entire Process

An integrated toolchain requires clear lines of responsibility. The engineering departments involved work with different methods, objectives, and responsibilities. For an SDV, it must therefore be clearly defined who is responsible for a function throughout the entire process. This end-to-end responsibility begins with the requirement and does not end with the release for production; it also encompasses operations. It is important to document which configurations are affected, what supporting documentation is available, who approves updates, and how to handle assumptions that prove to be incorrect in the field.

Automakers should first describe the end-to-end process for a given function, from the initial requirements specification through to its implementation in the vehicle. Only then can they make an informed decision about how ALM, PLM, MBSE, and other systems should support this process.

The Cybercab as a Litmus Test

The Cybercab is not a model for German and European manufacturers to copy. However, its use highlights what a vehicle that continues to evolve after delivery demands of the development organization. For a specific vehicle, an OEM must be able to demonstrate—within a short period of time—the current software version, the underlying requirements, the test results, and the approval status.

If this information has to be manually compiled from multiple systems, there is no end-to-end development process for the software-defined vehicle. Tesla removed the steering wheel from the Cybercab. For the rest of the automotive industry, the greater challenge lies in creating development processes that allow vehicles to be safely refined after delivery, while ensuring that speed, safety, and regulatory compliance go hand in hand.