The increased number and interconnectedness of functions in modern cars is driving the need for the evolution of automotive electric/electronic (E/E) architectures. The system network, the vehicle-wide domain-oriented (E/E) architecture, that consists of up to 100 ECUs for high-end vehicles, is now commonly available. However, due to the large number of communication interfaces between ECUs in combination with ever faster innovation cycles, the further development of this system network comes to its limits.

To reduce the number of ECUs, the communication effort via networking technologies as well as harness lengths, costs and weights, the highly integrated ECUs is therefore strategically pursued. The focus is on the development of central control units, which represent a common integration platform for functions from different domains and require a redesign of the previous hardware (HW) and software (SW) design in automotive system development.

Innovative vehicle features, like Advanced Driver Assistance Systems (ADAS) and beyond, are mainly based on software. Therefore, the amount of software in vehicles will continue to increase faster than ever.

Complexity will not be reduced by avoiding communication via busses. But the working model will change to a SW development process with the possibility to use methods and tools like agile working model, Continuous Integration (CI), model-based systems engineering (MBSE) with standardized modelling languages.

During the software engineering process, different teams from multiple internal departments and external contracted partners and suppliers contribute software entities into the Continuous Integration (CI) infrastructure.

BMW Group is striving for a digital consistency in the automotive SW Development by a “Treat Architecture like Code” philosophy. A key enabler for an agile development process is the ability to change all parts of the product in an agile way. Source code repositories and scalable CI infrastructure enable an agile development of source code. But other parts, like architecture models or on-board network descriptions, which are also crucial building blocks of the overall product, are often still treated in a different way, preventing fast iteration cycles. To avoid architecture erosion by deviations between architecture and code leads us to the requirement that ideally, the architecture description is treated in the same way as the source code, homogeneously in the same CI infrastructure. [SBS2020]

For the development of safety critical systems, it is very supportive to have a completely integrated toolchain that is not reduced to the code but also allows to keep the architecture description always consistent with the code. In a first step the model contains platform independent definitions useful to run a simulation for analyzing the timing behavior.

To specify the SW beyond the functional core behavior further model elements will be added as controls for safety and security patterns. This specific way of architecture modelling illustrates firmly the necessity for the “Treat Architecture like Code” approach.

[SBS20]Stefan Schlichthaerle, Klaus Becker und Sebastian Sperber. “A Domain Specific Language Based Architecture Modeling Approach for Safety Critical Automotive Software Systems”. In: Combined Proceedings of the Workshops at Software Engineering 2020. ASE 2020: 17th Workshop on Automotive Software Engineering. CEUR-WS 2581. Innsbruck, Austria: CEUR Workshop Proceedings, März 2020, S. 6.