Trends

Before the adoption of over-the-air (OTA) updates, automotive software development programs had one business-critical goal: to make the start of production (SOP). Features were designed upfront and deadlines were set years ahead in alignment with hardware development. As long as the software was ready when the vehicle was meant to go into series production, the goal was achieved.

With the huge increase in the complexity of in-vehicle software, the development process has become a more significant element and cost factor in overall vehicle development. OTA updates have become a standard feature, setting customer expectations that new features and fixes will be available after purchasing a vehicle.

In the SDV era, software engineering has a major impact on the quality and success of a vehicle. Increasingly, OEMs’ focus is shifting away from just making SOP to investing in engineering effectiveness and continuously improving development processes. This new mindset, which makes in-vehicle software development more iterative and incremental, is now crucial for OEMs’ success.

One of the inherent challenges of in-vehicle software development is the vast number of variants the software must support. Accommodating different electrical/electronic (EE) architectures, hardware generations, model lines and optional packages means the software must run on numerous distinct targets.

The established practices to deal with this challenge come from a time when software was significantly less complex. Software components were developed as individual projects, usually tied to specific hardware, leading to a highly fragmented software stack. While this approach is typically quicker for developing a feature or fixing an issue for a single line, it’s significantly more effort to do the same for all models and variants.

Today’s in-vehicle software is too large and complex for this traditional way of working. Time and costs for developing new features and supporting new hardware are rising; to remain competitive, OEMS must find a new approach.

Various approaches exist to handle this challenge more effectively, including extracting common components, creating a ‘car OS’, or having a single superset software package handle all setups. Some of these are described in more detail in this publication.

Many of the obstacles to OEMs implementing SDVs are organizational rather than technical. For decades, structures, processes and mindsets have been aligned to a project-based model-focused way of working. To succeed in the SDV era, organizations must adapt to handle:

• Iterative and incremental development: Most development teams are still siloed based on activities in the V-Model, leading to numerous handovers and long cycle times. To iterate and innovate faster, a more cross-functional model is needed.

• The Inverse Conway Maneuver: With in-vehicle architecture and communication flows changing, a reasonable approach is to reflect them in the organizational setup to minimise the effects of Conway’s Law.

• Products over projects: Internal tools and services as well as software components used across models should be treated as evolving products rather than temporary projects. Product teams should be able to handle not only development, but also operations and support.

Every organization has to accept that all structures come with downsides that must be deliberately mitigated. Fostering direct communication and collaboration across organizational structures appears to be essential for this.