An explanation on how automotive software systems are composed?

I got a question if there is a readily available source that could explain how automotive software systems are composed and how they contrast to more “normal” software systems.
Unfortunately I don’t know of any textbook or white paper that described the key principles of automotive software design end execution. The few books I know of are more process oriented. I enclose some references below, but I still don’t think these will provide enough inside knowledge. Some of them seem old, but I would say there is a huge difference between a current Mercedes S-class and a cheap vehicle (the latter is about 2 generations behind…)
AUTOSAR is of course a fairly common standard for a runtime environment for automotive software components:
Understanding the design of a software system based on source code might be difficult in the automotive domain. Typically 40% (commercial vehicles) to 80% of the software is developed by Tier1 suppliers and are delivered as black box binaries. Therefore there is usually no stakeholder that has complete access to all software in a vehicle, including the OEM.
  • K. Melin, ‘Volvo S80: Electrical system of the future’, Volvo Technology Report, vol. 1, pp. 3–7, 1998. 
  • A. Pretschner, M. Broy, I. H. Krüger, and T. Stauner, ‘Software Engineering for Automotive Systems: A Roadmap’, in Future of Software Engineering, 2007, pp. 55–71.
  • J. Mössinger, ‘Software in Automotive Systems’, Software, IEEE, vol. 27, no. 2, pp. 92–94, 2010.
  • Tsakiris, ‘Managing Software Interfaces of On-Board Automotive Controllers’, IEEE Software, vol. 28, no. 1, pp. 73–76, 2011.
  • J. Schäuffele and T. Zurawka, Automotive Software Engineering: Grundlagen, Prozesse, Methoden und Werkzeuge effizient einsetzen, 5th ed. Springer, 2012. (Mostly process oriented, and I don’t know if German works for you. Previous editions are available in English though)
  • A. Thums and J. Quante, ‘Reengineering embedded automotive software’, in Proceedings of the IEEE International Conference on Software Maintenance, 2012, pp. 493 –502.
  • J. Quante, M. Tarabain, and J. Siegmund, ‘Towards recovering and exploiting domain knowledge from C code: A case study on automotive software’, in IEEE Conference on Software Maintenance, Reengineering and Reverse Engineering, 2014, pp. 383–386.

Are common abstractions a sign of engineering maturity?

It has often been said that software engineering is not as mature as other engineering disciplines. I can agree with that, often it seems that the way we design large software systems is more akin to how great cathedrals in europe were constructed, with a blend of some basic understanding of mechanics, craftsmanship and artistry. We don’t have the equivalence of finite element methods for doing structural calculations etc.

But I realised ne thing that also sets software engineering apart from e.g. mechanical or civil engineering. We don’t have a universally accepted set of abstractions that we work with. A mechanical engineer has e.g. a blueprint (often drawn in a CAD program) which everybody can read regardless of where they are educated or which company they belong to (even if they are not familiar with a specific CAD program).

We don’t have a corresponding set of abstractions in software, if you go from one company to another they will use a different set of abstractions, form the low level (.g. choice of programming language), via design descriptions (which could be UML), to how to describe properties or requirements. And our tolls follow that, it is almost the other way around, the abstractions we use are dictate by the tools we choose, instead of the tools adhering to a common “view”, and what they differ in are things like UI, features etc.

I don’t think that software engineering will be considered a mature engineering domain unless we actually have a set of universally accepted abstractions which all software engineers are familiar with.

IoT standards

I attended the Embedded Conference Syd last week, which had both exhibitors and presentation tracks covering Internet-of-things. One thing that struck me is the lack of dominating standards in the area. It seems most proposed solutions and available devices are ether based on proprietary solutions, or relies on one of many various standards controlling how to integrate devices and services.

I assume that over time some standards will emerge and dominate also for IoT, in the same way as http/html for internet hypertext (does anybody remember Gopher and WAIS?). But we are not there yet…

Fortunately, the charging one has been solved now that we've all standardized on mini-USB. Or is it micro-USB? Shit.

Comic from XKCD.