The underestimated factor in your automated driving software strategy

Sensor Fusion > The underestimated factor in your automated driving software strategy

The automotive industry is undergoing a substantial disruption, with an increasing share of a vehicle’s value being defined by software. This is not only, but particularly, true for the automated driving (AD) domain. With such a disruption at hand and a pack of aggressive tech-based competitors at their heels, one of the core strategic goals of many OEMs and Tier1s was and is to scale their software development capabilities. So how can the transformation to an automotive SW company be successful despite the indisputable lack of software talents?

A highly relevant question. Still, I believe it distracts from another factor of a successful AD/ADAS software strategy which I consider at least equally important. Let me explain why:

Complexity-productivity-gap

A recent study of McKinsey & Company argued that while software complexity grew by a factor of 4 over the last 10 years, software-development productivity only increased by a factor of 1.0 to 1.5. If this trend continues, 25–40% of additional software development resources will be needed each year just to keep up with the current pace of automotive software. Even worse, the study found productivity for ADAS and AD software to be 25–35% lower than for traditional embedded software.

Maintenance-burden

Software is aging. It requires constant maintenance to remain functional. I am not talking about new functionality here, just about keeping existing software compatible to changing hardware, architectures, or interfaces. The more software is being developed, the more software needs to be maintained.

Effort estimates for this maintenance vary significantly from 40-80% of the development costs [Software Maintenance: Understanding and Estimating Costs]. This implies that in addition to the 25-40% additional resources needed each year due to growing complexity, even more resources will be needed to keep the existing software running.

"During our interviews, one company leader noted that software maintenance alone will rapidly use up all software R&D resources if complexity continues to grow while productivity remains unchanged, leaving little room for innovation." [McKinsey & Company: When code is king: Mastering automotive software excellence​]

Does that mean that it is a mistake to focus on internal software development capabilities? Absolutely not. I am convinced that this is the only way to stay competitive when it comes to automated driving. However, I do see a risk of underestimating a carefully designed SW sourcing strategy in addition to in-house development. Personally, I believe that regardless of size, no one can do automated driving alone. That is why I consider strategic SW sourcing as one of the most impactful factors for delivering driving automation systems in time and budget in the years to come. This topic, in my opinion, deserves and requires management priority.

I believe SW sourcing needs to go beyond traditional make-or-buy-decisions to show its full potential. In the next article, I will show why. In the meantime, I am curious about your thoughts: Are you developing your key software components in-house or are you sourcing them from outside?