“The automotive world has an awful lot to learn about innovating in software engineering and little time to do it.“
For many years, I have repeatedly claimed that many Dutch companies have world-class skills in software engineering, particularly in the realisation of what has become known as Cyber-Physical Systems (CPS). For the last half year, I have been consulting in software engineering with a large automotive OEM, an eye-opening experience, to say the least. The automotive world has an awful lot to learn about innovating in software engineering and little time to do it.
The roots of this problem lie in the very DNA of the OEMs. For many years, they have created value through vehicle system engineering. At heart, they functioned as system integrators, composing together components outsourced to and produced by suppliers. For example, the OEM to which I refer currently develops just 10% of the software that goes into its vehicles. Tier 1 suppliers provide the rest. The result is that the system engineering processes of this OEM are deterministic and optimised to decompose the design of a vehicle into components, to outsource the development of those components and finally to integrate them into a system. Following Conway’s Law, the shape of their organisation and its mentality reflect these processes.
We’re all aware that the world of mobility is changing rapidly, and this has not passed by the Automotive OEMs. They are also fully conscious of the potential for new competition from software-centric companies such as Apple and Alphabet. The OEM with which I’m involved has set a range of highly ambitious targets, including a goal to internally develop 60% of the software in its vehicles in the near future. They have published a beautiful strategy which, cynic though I am, I find rather inspiring.
Back to the problem. Yesterday’s vehicles were merely complicated. The automotive Cyber-Physical Systems of tomorrow will be complex. This difference has fundamental consequences. For example, complex (software) systems are difficult, if not impossible, to realise with hierarchical, deterministic system engineering processes.
Further, at the OEM where I’m consulting, software system engineering is not integrated into vehicle system engineering. Software is still seen merely as a collection of components that contribute to the operation of a vehicle rather than the overall intelligence that enables it to operate as a cyber-physical system.
Perhaps worse is that engineering mentality must catch up with the times – I still see architectural decomposition process descriptions that end up at an ECU. In other words, while automotive OEMs have woken up to the importance of software, they have yet to understand the consequences for their systems engineering.
And this is where Dutch companies have an opportunity. We have been building complex Cyber-Physical Systems since before the term was invented. We have more than 30 years of experience in realising system engineering processes that embrace software, and we’re at least ten years ahead of the automotive OEMs.
Europe has lost the battle for dominance in many software markets, including business software, social media, and gaming. The only major markets left are industrial and automotive systems. If we’re not to become a backwater in software, dependent on US or Asian suppliers, perhaps we should be more proactive in seeking ways to share and build upon our inherent software engineering capital.
Read more
An outbreak of hubris
Software is the medium of digitalisation. If you don’t understand software, you have no hope of coming up with a decent digitalisation strategy.
Software is not a component of a vehicle
Automotive OEMs have evolved to become highly efficient outsourcing and system integration organizations. Everything related to a vehicle is thought of as a component, including software. The whole automotive system engineering process treats software as a component of a vehicle. This prevents them thinking about the software as a whole system.
Abstraction versus Vagueness in Software Engineering
Some software engineering teams have a problem understanding the difference between abstraction and vagueness. Since one is essential to the architecture and design of complex systems and the other leads to technical debt and poor software quality, software teams must grok the difference.