In a world where there’s growing demand for increasingly complex cyber-physical systems, there’s a huge opportunity for Brainport region companies to leverage their unique competencies, argues Robert Howe.
I’ve spent the last 10+ years declaiming on and off that the 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 they ask. The deep, insightful and challenging questions we used to get about Dezyne from Brainport companies were in a different league from 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 a different meaning. 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 to one of the larger automotive OEMs and during this time, I’ve 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 into 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 from 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 isn’t 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 to a failure to understand and control the behavior of a very large collection of loosely coupled software ‘runnables’ – I wouldn’t honor 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 we produce today. Consequently, I’m now utterly certain that the knowledge and skills that we have are world class, if not world leading. In a world where there’s growing demand for increasingly complex cyber-physical systems, we really should figure out how to better 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 say to them, vehicles are components of a software mobility system, as anyone who drives a Tesla will tell you.