“Software is not a component of a vehicle. Rather, a vehicle is a component of a software system”
I’ve spent the last 10+ years declaiming on and off that the Netherlands Brainport region is a world leader in software engineering. This belief was based on my experience of technical sales visits to and running workshops for quite a large range of software-developing companies in Germany, India, Scandinavia and elsewhere. One can tell a lot about the maturity of a software development team by the questions that they ask. The deep, insightful and challenging questions that we faced from Brainport companies were more substantive than those that we got from teams outside of our region. Of course, this is a superficial measure of the maturity of a given team. Nevertheless, when repeated frequently enough, one starts to get a feel for the state of software engineering in other industries and regions.
It seemed to me that the worst offenders were often automotive companies and their tier-one suppliers. The software development teams in these organizations seemed to be stuck in some sort of through-the-looking-glass world called AutoSAR, where common words and concepts seemed to have different meanings. Whenever we talked about event-driven, service-oriented systems, we were often met with blank stares. I could never quite figure out the nature of the problem or how to bridge the communication gap. And so we never managed to gain a foothold in the automotive world.
For the last 18 months, I’ve been consulting on software engineering for one of the larger automotive OEMs, and during this time, I have finally understood the nature of the problem. In short, innovation in automotive software engineering is severely constrained by two things.
Firstly, established 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 anyone thinking about the software as a whole system. It stands in the way of developing a vehicle-wide architecture that deals with error handling, supervisory control, and so on.
Secondly, AutoSAR Classic, the prevalent operating environment for vehicles, is based on a Matlab-esque, data-driven, clock-tick paradigm. Consequently, component-based, event-driven, service-oriented architecture is not an understood and supported way of engineering software systems. In my view, the adoption and use of component-based, service-oriented architecture is utterly key to the ability to realize complex cyber-physical systems. The problems that my customer is seeing in their finished products can be significantly related back to a failure to understand and control the behaviour of a very large collection of loosely coupled software ‘runnables’ – I wouldn’t honour these objects with the moniker ‘component’.
When I look back on the 38+ years that I’ve spent working in machine control and factory automation software engineering in this region, I realize that we’ve been fortunate to have been influenced by some very erudite people. People who have advanced the subject of software systems engineering to deal with the phenomenal complexity of the cyber-physical systems that we produce today. Consequently, I am now utterly certain that the knowledge and skills that we have are world-class, if not world-leading. In a world where there is a growing demand for increasingly complex cyber-physical systems, we really should figure out how better to leverage our competencies.
As a footnote, I get a lot of enjoyment from watching the reaction of automotive software engineering managers and teams when I tell them that software is not a component of a vehicle. Rather, I tell them, vehicles are components of a software mobility system, as anyone who drives a Tesla will tell you.
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.