- 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.
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.
I gave a presentation at the IoT conference in Lund.
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.
Comic from XKCD.