Brainport should export its world-class software & engineering capabilities
ÌI have been proclaiming for 10+ years that the Brainport region is a world leader in software engineering. This belief is based on my experience making sales visits and leading workshops for a large number of software development 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 in-depth, insightful and challenging questions we received from Brainport companies about Dezyne were of a different order than those from teams outside our region. Of course, this is a superficial measure of a given team's maturity. Nevertheless, if repeated often enough, you begin to get a feel for the development of software engineering in other industries and region'
It seemed to me that the worst offenders were often car companies and their suppliers. The software development teams in these organizations seemed stuck in a kind of through-the-looking-glass world called Autosar, where common words and concepts seemed to have a different meaning. When we talked about event-driven, service-oriented systems, we often got blank stares. I could never quite grasp the nature of the problem or the communication gap. And so we never got a foothold in the automotive world.
For the past 18 months I have been consulting on software engineering to one of the larger automotive OEMs, and during that time I have finally understood the nature of the problem. In a nutshell, innovation in automotive software engineering is severely limited by two things.
First, established automotive OEMs have evolved into highly efficient outsourcing and systems integration organizations. Everything about a vehicle is considered a component, including software. The entire automotive systems engineering process treats software as a component of a vehicle. This prevents anyone from thinking about the software as a whole system. It gets in the way of developing a vehicle-wide architecture that deals with error handling, supervisory control, and so on.
The second is Autosar Classic, the common vehicle control environment based on a Matlab-like, data-driven, clock-tap paradigm. Consequently, that component-based, event-driven, service-oriented architecture is not a supported way to develop software systems. In my opinion, the adoption and use of component-based, service-oriented architecture is key to the ability to realize complex cyber physical systems. The problems my client sees in its end products may be largely related to a lack of understanding and control of the behavior of a very large collection of loosely coupled software "runnables" - I would not call these objects a "component" right away.
As I look back over 38 years of working in this region on machine control and factory automation software, I realize that we are fortunate to have been influenced by some very erudite people. People who developed the subject of software systems engineering to handle the phenomenal complexity of the cyber-physical systems we produce today. Consequently, I am now completely confident that the knowledge and skills at our disposal are world-class, if not world-leading. In a world where the demand for increasingly complex cyber physical systems is increasing, we really need to figure out how to better leverage our competencies.