“Mastering automotive software complexity is going to be a tall order if engineers don’t see the big picture and, even worse, lack common sense”
I’m increasingly concerned that automotive software engineering is suffering from a serious outbreak of hubris. Just in case you’re not familiar with the word “hubris”, the definition is: “[hubris] describes a personality quality of extreme or excessive pride or dangerous overconfidence”. In Greek mythology hubris often leads to nemesis.
For the last 18 months I’ve been consulting on software engineering process definition in the automotive world. The further I get into the current state of software engineering in this world, the more concerned I get, particularly as it relates to overconfidence. The problem is essentially that few engineers really understand the complexity of the software systems that they are trying to realize. Worse, they are being driven to deliver autonomous driving systems without having the associated complexity under control.
Even more worrying is the fact that, to the last person, the software engineers with whom I deal are intelligent, well-educated, motivated, serious people who have a detailed understanding of their particular microcosm of automotive software. But they seem to lack two things: an understanding of the “big picture” and a degree of pure common sense.
Some time ago, I read a quote from a Brainport luminary, I forget who, who said something like: “The challenge of mechanical/hardware engineering is to master the laws of Physics. Software engineering is not constrained by Physics. Here, the challenge is to master complexity”.
What we know about complexity in cyber-physical systems is that it increases with increasing semantic abstraction. In other words, at the lowest level of a system, there are usually very many relatively simple software components. However, when we start to combine these simple components together to create higher-level functions, complexity increases very quickly. The higher we go, the more lower-level functions we combine, the more complexity increases.
This “big picture” complexity principle is poorly understood by automotive software engineers, largely because historically, software has been treated as an ECU-dependent component of a vehicle. This has stood, and still stands, in the way of recognizing the need to treat the software in a vehicle as an entire system rather a collection of loosely coupled components.
In my usual diplomatic way, I like to challenge automotive people by telling them that a vehicle is a component in a software system and not the other way around. Solving the “big picture” problem is tough but doable, in my opinion. Once exposed to the advantages of engineering software as a system, the penny typically drops with many engineers.
The problem of common sense is more difficult though. I recently attended a review of the software requirements for a particular highly detailed vehicle feature. This feature involved the use of 12 identical temperature sensors. When I reviewed the requirements with the team, I found that they had 12 sets of identical requirements, one for each temperature sensor. I asked why they hadn’t written one set of requirements and then added a requirement that said the original requirements applied to all 12 sensors. I got some vague answer about the test & integration people needing individual requirements for each sensor. When I pointed out that requirements are extremely expensive, that every requirement has to traceable thorough architecture, design, implementation and test, and that compliance must be demonstrated at each stage, etc, I got some very sheepish looks. Duh.
Software is already naturally complicated enough without adding human-induced overcomplexity. Somehow or other these software engineers need learn to apply common sense, to think simply and try to make their software components and systems as simple as possible, but no simpler – to borrow a famous quote. Reduce, constrain, simplify and resist unnecessary complexity of all kinds. A really tough challenge.
Looping back to hubris: how can one possibly be confident about one’s ability to realise autonomous driving and related functions when one doesn’t recognise the challenges of mastering software complexity, let alone have a systematic competence to master it?
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.