An outbreak of hubris
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,” it 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 dive 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 they’re trying to realize. Worse, they’re 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 isn’t 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 to create higher-level functions, complexity rises 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 than 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 be traceable through architecture, design, implementation and test, and that compliance must be demonstrated at each stage, and so on, I got some very sheepish looks. Duh.
Software is naturally complicated enough without adding human-induced overcomplexity. Somehow or other these software engineers need to 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 realize autonomous driving and related functions when one doesn’t recognize the challenges of mastering software complexity, let alone have the competence to master it?
