A Domain-Specific Language Based Architecture Modeling Approach for Safety Critical Automotive Software Systems Stefan Schlichthaerle Klaus Becker Sebastian Sperber BMW Group BMW Group BMW Group 80788 Munich, Germany 80788 Munich, Germany 80788 Munich, Germany Stefan.Schlichthaerle@bmw.de Klaus.Becker@bmw.de Sebastian.Sperber@bmw.de Abstract—Modeling software architecture for software inten- Platform for automated driving. The Software-Platform is sive systems like future automated driving vehicles becomes based on Adaptive AUTOSAR [5]. 1 We also show how increasingly complex, compared to Advanced Driver Assistance Continuous Integration (CI) influences our methodology on Systems currently available on the market. The complexity and novelty of the customer functions and the hardware and software describing software architecture. platforms demands for an agile development methodology. In this paper, we introduce why and how we at BMW apply a Treat II. R EQUIREMENTS AND G OALS FOR S OFTWARE Architecture like Code approach for the software development for A RCHITECTURE D ESIGN automated driving. We introduce the requirements which lead us A. Software System and Development Process Overview to this approach, the tools and artifact flows around the tools, and how we embed this into our agile development. We show The mixed safety-critical software platform for automated examples from a real vehicle function. driving, for which the architecture modeling approach pre- Index Terms—Software architecture, Agile software develop- sented in this paper is used, consists of different CPUs that ment, Service-oriented systems engineering use Adaptive AUTOSAR as middleware. The communication I. I NTRODUCTION between the CPUs is enabled by the SOME/IP protocol [6], an automotive standard for Ethernet communication, speci- In the automotive domain, innovations are to a huge extend fied and used as part of AUTOSAR. During the software driven by software, particularly in the last 15 years [1] [2]. engineering process, different teams from multiple internal Innovative vehicle features, like Advanced Driver Assistance departments and external contracted partners and suppliers Systems (ADAS) and future highly, or fully automated driving contribute software entities into the Continuous Integration features (SAE levels 3-5), are mainly based on software. (CI) infrastructure. The agile development process is based Therefore the amount of software in vehicles has been and on the LeSS framework, which enables agile methodologies will continue to increase dramatically. for big project setups [7]. Additionally, especially in the context of automated driving, the requirements for the engineering problems cannot be B. Agile Working Model completely predefined in the beginning and then afterwards A fundamental aspect of agile methodologies is the ability developed, like in classical development processes. This is to react fast towards changed requirements [8]. In classical because many engineering problems are Volatile, Uncertain, development processes like the waterfall approach, all product Complex and Ambiguous (often abbreviated with VUCA), development phases follow a well-defined sequence, which raising the demand for agile development models [3]. The starts with requirements engineering and ends with the product VUCA factors influence all stages of engineering, like re- release. Changes in this sequence are hard to deploy and quirements engineering, software architecture design, software are often perceived like a failed project result. In contrast to implementation, testing at different integration levels, and also the waterfall approach, an agile software development process the engineering and integration processes. always involves the full cycle to introduce a change, starting Because of the complexity of the development of automated from updated requirements, changed architecture, source code driving, agile software development is required in a large- and tests. The product development always iterates through scale with many software development teams. Therefore BMW this cycle, resulting in small product increments which even- adopted a large-scale scrum (LeSS) approach for the teams tually sum up to the final product. involved in development of automated driving [4]. In an large scale agile software development project with In this paper, we present our requirements and our approach multiple distributed development teams, an essential success for a methodology for software architecture design in a large- scale agile software development process of a Software- 1 https://www.autosar.org/standards/adaptive-platform Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). factor is to have a stable basis in a master repository, in which the architecture description shall be kept as close to the code as always a certain level of functional quality is ensured. For possible, to avoid architecture erosion by deviations between instance, it shall compile and automated tests on different architecture and code. This leads us to the requirement that levels shall be ok. This high quality stable master (sometimes ideally, the architecture description is treated in the same also called green master, because all tests are always green) way like the source code, homogeneously in the same CI can only be established by avoiding that people directly infrastructure. A textual architecture description is best suited commit their changes into the master without any quality for this, as automated merges can be done for the architecture check. Hence, we setup a staged development process with description in exactly the same way as for source code. semi-automated quality gates. Developers create small, short This is why we decided to choose a textual Domain Specific living, development branches, do their changes in the branches, Language (DSL) like Franca+ to describe those parts of the and then create a pull request (PR) to request a takeover of architecture from which code is going to be generated (see their changes into the master. Once the PR has been triggered, section V). The architecture model is stored in text files two stages of automated quality gates are triggered. within the same repository as the corresponding source code, 1) check accompanied by a tool chain running in the CI infrastructure in 2) gate the cloud. Thereby we ensure that always, with each delivery, To pass the check, at least one manual review has to be done the architecture models match the code and to the build system by another developer, which either declines with comments configuration files. Hence, we integrate the development of requesting improvements or fixes, or approves the changes. architectures with Franca+ and the development of software Only when the review and all automated tests done during code into the same CI process. the check are ok, the gate is triggered and performs additional III. R ELATED W ORK deeper tests based on a virtual merge with the master (and with all changes of the master that have been added after the Agile methodologies and development workflows are widely development branch has been created). If the automated tests used within software engineering among different industries. A of the gate are also ok, the change will be merged into the key aspect of software development is the related architectural master, see Fig. 1. design. In this section, we briefly describe related work in agile software architecture development. In [9], the author talks about the alignment of architecture work with agile teams. Based on his experience as software architect, there are often difficulties when software architects and agile development teams work together, because their Pull Request: Check: Gate: priorities and scope may vary. For example architects tend to Developer requests Quality Feedback Assess quality of change, quality check about change integrated with recent work on a comprehensive design upfront, which shall cover all (incl. manual reviews) master aspects, whereas agile teams following the agile manifest work create branch to develop push push continuously on their product and regularly deal with changed new feature or fix problem changes improvement requirements, which may impact their overall product. branch To address these differences, the author derives a set of quality quality Automatic not ok ok Merge architecture practices, which helps software architects and Git Repo agile teams to collaborate and benefit from each other. Among master others, he emphasizes that sharing information over simple other branch tools is key to bring both parties together. Additionally, he Fig. 1. CI Integration process with quality gates and automatic merging describes that incremental deliveries and Deliver something that runs are key to match with the development workflow But what does this staged continuous integration process of the agile team. The author does not introduce concrete mean for the development of the software architecture? technical solutions to enable these practices in a project setup, though. In our project, these architecture practices have been C. Treat Architecture like Code clearly identified as well and we address them with our DSL- A key enabler for an agile development process is the based approach for architecture modeling. ability to change all parts of the product in an agile way. The work in [10] introduces research questions and study Source code repositories and scalable CI infrastructure enable results about the requirements to apply Service Oriented an agile development of source code. But other parts, like Architectures (SOA) in safety-critical automotive software. For architecture models or on-board network descriptions, which the modeling of service architectures, they propose to use tech- are also crucial building blocks of the overall product, are often niques such as UML or SoaML. SoaML enables formal model- still treated in a different way, preventing fast iteration cycles. ing of service interfaces on syntactic and semantic level. They Reasons for this are legacy tools, or a development process propose to develop service interfaces with service description which emphasizes on big releases on fixed dates, instead of languages. Typically those service description languages are fast and small incremental updates. To address this challenge, also text-based, like WSDL. The presented study result was that the vast majority of interviewed persons agreed that a Besides the layered view described, a different view of the model based approach for SOA development is needed, and model starts from the individual component and introduces that services should be designed independently from a target a vertical column spanning from model layer on top to the hardware platform. The Franca+ approach which we apply deployment layer at the bottom. This view expresses the supports this. The textual modeling approach with Franca+ is technological-independent model of a component, its inter- motivated by the Treat Architecture like Code idea to enable faces and data types together with a technology-dependent the homogeneous handling of architecture and code in the deployment on a concrete CPU. At the same time, the vertical same CI process, to avoid deviations between architecture column reduces dependencies to the shared usage of interfaces and code. As service middleware, we use SOME/IP in our and data types, which is a crucial prerequisite for the design project. Due to the usage of platform-independent models of a performant tool chain, as we will see in section (V-A). and the platform-specific deployment models (see section IV), To express all entities and to store them in text files within different service middleware could be used, like for instance a repository, the Franca IDL, which is part of the Franca also Data Distribution Service (DDS) [11], which can be framework [12], is used. In the following section, the Franca applied as alternative to SOME/IP in the AUTOSAR Adaptive IDL and the extensions introduced in our project are described. Platform. 2 IV. M ODELING A PPROACH B. Franca In section II-C, we described the philosophy of Treat Franca is a framework for defining and transforming soft- Architecture like Code and the expected benefits and improve- ware interfaces. The core of it is the Franca IDL (Interface ments for product development in our domain. To transfer Definition Language), which is a textual language for speci- this overall approach into an automotive software project, we fication of APIs [12]. Franca is a domain-specific language developed a modeling approach which is based on latest tools based on the Eclipse Xtext framework [13]. Due to its Xtext and processes for agile software development and fulfills all nature, Franca already provides an editing tool with built-in requirements necessary for the development of safety critical basic validations and a software development kit (SDK) to systems. The current status of our tool chain’s qualification work with Franca files in other tools, at almost no cost. Within regarding these requirements is discussed in V-D. our project, we use the Franca IDL for defining entities on the In this section, we will first describe the key entities of our model layer and an extension of it called Franca+, which we model and their representation. Afterwards, we introduce the use to define software components and their deployment on language which is used to describe the entities. the deployment layer. 1) Franca IDL: Franca IDL is an interface definition A. Model Fundamentals language which allows defining interfaces, and corresponding Our model consists of two horizontal layers. data types. It is part of the Franca framework, which is • The model layer contains platform-independent definition published in [12] and described in detail in [14]. As we of interfaces, data types and components. use most of Franca IDL without any changes, except its • The deployment layer maps the platform-independent concept of service instances as service deployments, we won’t model to concrete technologies and instances on CPUs describe the language features in detail here and refer to the available in the system. This layer also contains dedicated sources available. Instead we emphasize on the extensions properties and settings, which are required during code we introduced towards the definition of software components, generation or at runtime of the system. ECUs and their deployment in the next section. A component defined on the model layer may include 2) Franca+: Franca+ was developed at BMW to enable provided and required communication ports, which are typed a language-based modeling approach for AUTOSAR environ- by the used Interface. An Interface itself can contain an ments, where software architecture is described in terms of arbitrary number of methods, events or fields, which are typed software components and communication via ports. As an by the data types. extension of Franca IDL, Franca+ reuses Franca’s definitions For every entity on the model layer, a deployment is added of interfaces and datatypes. A software component’s port is on the deployment layer, which adds properties towards the an instantiation of such an interface. The above mentioned technical realization on the concrete platform. For example model is split into two layers and is also applied to Franca+, an technological independent interface defined on the model which consists of two domain specific languages, the Franca layer can be extended with properties required for SOME/IP Component Description Language (FCDL) and the Franca deployment on the deployment layer, so that the interface can Component Deployment Language (CDEPL). The Component be used for SOME/IP communication in the vehicle network. Description Language allows defining software components With this layered approach, the same software component with ports that provide or require services. The service’s and interface description on model layer can be mapped to content is described in terms of Franca interfaces. Furthermore different platforms by using different deployment models. in Franca+, model elements called devices can be used to model CPUs and their network interfaces. In case that the 2 https://www.autosar.org/standards/adaptive-platform communication relations between software components shall be stated in the model view already, connectors can be used Agile Iteration to connect the corresponding component ports. Bordnet Signal Catalogue Within the Component Deployment Language it is defined Diagnostic Autosar which of these new model elements act as deployment targets Request Catalogue Models and gen Source Code Manifests Code and how these deployments have to be specified. The actual (*.arxml) Code ... Franca deployment properties that can be applied for each type are defined in so called deployment specification files, a mech- + Interface Description (FIDL) + Interface Deployment (FDEPL) UML Data anism reused from Franca. Using this approach deployment + Component Description (FCDL) + Component Deployment (CDEPL) properties can be edited later on by simply adding them to the specifications without the need of changing the actual tool. To Fig. 2. Franca Toolchain consisting of two parts: Converting existing data enable our tool chain we introduced deployment specifications sources into the Franca+ model on the left side and translation towards AUTOSAR Models and source code on the right side. to describe SOME/IP and IPC communication, as well as runtime parameters of Adaptive AUTOSAR applications and diagnostic communication. In Franca+, service instances are introduces a change request as a pull request, the tool chain is defined as the deployment of service components, with all started and tries to compile the change together with the rest corresponding deployment information, e.g. for their commu- of the model. nication ports. The first part of the tool chain is a python-based compiler, which reads the Franca+ model affected by the pull request In this section, we first introduced the fundamentals of our and translates it into an Adaptive AUTOSAR compatible XML modeling approach, which supports modeling of platform- representation. In subsequent steps, the Adaptive AUTOSAR independent and platform-dependent entities on different lay- model is further translated into C++ source code and binaries, ers. Additionally, we described the domain-specific language which are then executed on the hardware. Whenever an error that is used as modeling language and the extensions for occurs during execution of these steps, no matter if it is related component description developed at BMW. to validation, quality assurance or regression in test cases, the In the next section, we describe the tool chain used to pull request is rejected, resulting in a negative feedback to the translate the model towards the platform and to connect the developer. To integrate the change, the developer has to first software architecture model to other tools applied in our resolve the problems discovered. software and systems engineering. In section IV-A, the importance of dependencies between V. T OOL C HAIN parts of the model has been discussed already. To design a performant tool chain that scales to huge projects, it is very To embed the described architecture model into the software important that a run triggered by a pull request only translates development process and fulfill the requirements regarding these parts of the model that are directly affected by the working mode as stated in section II, a comprehensive tool change. It shall not be required to consider the whole model chain is required. to check a partial change. The tool chain consists of two major parts influencing the In a first development iteration of our tool chain, a pull actual target code generation and one additional part, which request affecting a single component always caused a rebuilt is used for documentation purposes. of the whole CPU to which the corresponding instance was 1) First, the model stored in the repository has to be allocated to. With growing number of developers contributing translated into executable code, which is eventually to the model, build times increased significantly, resulting in running on the target hardware in the vehicle. Besides long waiting times and overall decrease of productivity. Only translation into different languages, this part of the chain considering changed model entities in the check of a pull also contains validation steps, to ensure that errors in the request eliminated these problems. model are discovered as early as possible. 2) Second, there is a part of the tool chain which pro- B. Incorporating legacy systems duces Franca+ model artifacts mainly from existing data Some data required to generate a complete system de- sources like on-board network or diagnosis description. scription is located into other data sources. For example, Figure 2 shows an overview of the parts of the tool chain, at BMW, the ethernet-based vehicle network description is contributing to and starting from the Franca+ model respec- managed in a separate database system, which is involved tively. In addition there is another part that generates Unified in a variety of processes and projects. The tool does not Modeling Language (UML) elements for graphical modeling allow agile workflows, therefore we decided to import its tools. In the following sections, the parts of the tool chain are data into our model on a regular basis. Whenever a release described in more detail. takes place for the ethernet-based vehicle network, we convert the artifacts into a Franca+ model description and add them A. Code Generation towards the platform to our repository. With this approach, we decouple the code The component model is described with Franca+ and stored generation as described in V-A from the legacy system, so in text files within a git repository. Whenever a developer that its contents can be changed with our workflow. We did not implement a round trip within our tools, though. In this software which is part of the Software-Platform for Automated example, changes introduced in the Franca+ model have to Driving and explain how it is developed with the tools and be aligned with the other system by following their change processes described. processes on a regular basis. The same approach applies for diagnosis description for A. Regulatory software identification numbers Unified Diagnostic Services (UDS, ISO 14229). The origin To comply with statutory specifications and type approval of the data is a database system with a separate change regulations, the software platform shall provide regulatory process. We extended our tool chain to read an export of software identification numbers (short: RxSWINs) [17] [18]. the diagnosis database on a regular basis and to convert it These numbers are used to identify the software version used into the Franca+ model. This was necessary because at many during approval of the product and to establish a process to interfaces diagnostic data and requests have to be handled. handle software updates and their impact on existing type- approved systems or functions. To comply with these require- C. Tracing to other tools ments, a software shall be developed as part of the Software- Since graphical representations may help to understand the Platform for Automated Driving, which handles RxSWINs and software architecture better and allow advanced documenta- the relevant communication needs. tion, we introduced another tool for the generation of Uni- For the sake of simplicity in this illustration, our exemplary fied Modeling Language (UML) elements from our Franca+ model below focuses on a single requirement derived out of the model. type approval regulations: The software shall offer an interface We generate UML elements (data-types, components and to query the RxSWIN of the whole platform. interfaces) from the Franca+ models and import them into an UML tool, in which other aspects of the software and B. Architecture Model of RxSwinApp system architecture are described. By this, we enable seamless To fulfill the requirements derived for the software identi- tracing and referencing from other system aspects with are not fication number feature of the platform, a service component defined in Franca+, towards the entities defined in Franca+. called RxSwinApp is modeled, which offers a single interface At the same time, this enables tracing from our Requirements containing a method. If the method is called, the RxSWIN of Engineering tool to the entities defined in Franca+. the platform is returned. As the exchange format with these graphical UML tools we Thus, the Franca+ model for this software contains a ser- use Eclipse UML2, which is part of the Eclipse Model De- vice component definition, including a provided port which of- velopment Tools (MDT) [15] framework. The Franca+ meta- fers interface RxSwinData. The interface contains one method model can be mapped straight-forward to UML2, because most definition with one out parameter. If the method is called by elements are defined in both representations. the client, the out parameter contains the RxSWIN. Listing 1 D. Tool qualification shows the model in Franca+ language. As we use the introduced architecture modeling approach 1 i n t e r f a c e RxSwinData for the development of mixed safety critical systems, an 2 { additional factor to consider is the tool qualification according 3 method getRxSwin to functional safety standards, particularly the ISO 26262 4 { [16] for the automotive domain. The necessary actions, like 5 out { determination of the tool confidence level (TCL) and software 6 UInt32 rxswin tool qualification, are currently ongoing. 7 } 8 } In this section, we described the tool chain used to embed the 9 } Franca+ model into the Continuous Integration (CI) infras- 10 tructure, to enable agile workflows and change processes. We 11 s e r v i c e component RxSwinApp { described the translation from the model all the way to the 12 p r o v i d e s RxSwinData a s R x S w i n D a t a P P o r t binary running on the hardware. Additionally, we introduced 13 } tools used to incorporate legacy systems and generate UML Listing 1. Definition of interface and service component in Franca+ model elements. In the next section, we will introduce a concrete example, To deploy RxSwinApp on a CPU and the interface RxSwin- which illustrates our architecture development approach in Data towards a communication protocol, e.g. SOME/IP, ad- daily practice. ditional parts of the model define the deployment of the entities defined in listing 1. For example the deployment on a VI. D EVELOPMENT EXAMPLE CPU may include additional parameters which are required In the previous sections, we described modeling with to configure the Adaptive AUTOSAR middleware for this Franca+ and how agile teams and workflows can benefit from application, e.g. regarding startup parameters or dependencies this approach. In this section, we take a dedicated piece of towards other applications. C. Tool chain and software development for RxSwinApp R EFERENCES The Franca+ model of RxSwinApp is stored in the overall [1] M. Broy, “Challenges in automotive software engineering,” in Pro- ceedings of the 28th international conference on Software engineering. project git repository. We use Bazel [19] as build system and ACM, 2006, pp. 33–42. to define a set of rules to compile the model into ARXML [2] S. Fürst, “Challenges in the design of automotive software,” in Pro- and C++ as described in section V. The corresponding C++ ceedings of the Conference on Design, Automation and Test in Europe. European Design and Automation Association, 2010, pp. 256–258. source code, which implements method getRxSwin, is stored [3] W. Vieweg, Management in Komplexität und Unsicherheit - Für agile in the same git repository, as well as all unit and component Manager. Berlin Heidelberg New York: Springer-Verlag, 2014. tests to ensure quality of the software. [4] K. Ribel and C. Larman, “LeSS Huge at BMW Group,” https://www.scrumalliance.org/ScrumRedesignDEVSite/media/pdfs/ Due to co-location of architecture model and source code Konstantin-Ribel-181008 - LeSS Adoption at BMW Group.pdf, and embedding everything into the Bazel build system and October 2018. continuous integration, the agile workflows as described in [5] S. Fürst, “Autosar the next generation–the Adaptive Platform,” in 3rd Workshop on Critical Automotive applications - Robustness and Safety section II-B can now be pursued whenever requirements (CARS@EDCC), 2015. are changing. Imagine for example a new requirement that [6] L. Völker, “Some/ip-die middleware für ethernetbasierte kommunika- requests returning the RxSWIN as character string, to be tion,” Hanser automotive networks, 2013. [7] M. Bregenzer, “LeSS adoption at a bavarian car manufacturer,” https: compatible with legacy testing environment. A feature team //less.works/case-studies/bmw-group.html, 2018, [Online; accessed 04- breaking down the new requirement may come up with the October-2019]. solution that introducing a second method returning a byte [8] K. Beck, M. Beedle, A. Van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries et al., array instead of UInt32 is the most feasible solution for this “Manifesto for agile software development,” 2001. use case. Due to model and code located in the same git [9] E. Woods, “Aligning architecture work with agile teams,” IEEE Soft- repository and following the same change process, they can ware, vol. 32, no. 5, pp. 24–26, Sep. 2015. [10] S. Kugele, P. Obergfell, M. Broy, O. Creighton, M. Traub, and adapt the Franca+ model, extend C++ implementation and W. Hopfensitz, “On service-orientation for automotive software,” in add corresponding tests, all in a single pull request to be Software Architecture (ICSA), 2017 IEEE International Conference on. validated by the continuous integration system. IEEE, 2017, pp. 193–202. [11] Object Management Group (OMG), “Data-distribution-service,” http:// www.omg.org/spec/DDS. In this section, we have seen how Franca+ based architec- [12] Genivi, “Franca framework,” https://github.com/franca/franca, 2019, ture modeling is pursued on a real-life example within our [Online; accessed 04-October-2019]. [13] E. Foundation, “Eclipse Xtext,” https://www.eclipse.org/Xtext/, 2019, project. Describing the software architecture with Franca+ [Online; accessed 03-November-2019]. enables feature teams to change the model in the same way [14] itemis AG, “Franca User Guide,” https://info.itemis.com/en/ as the corresponding source code, which is a key prerequisite franca-user-guide, 2018, [Online; accessed 04-October-2019]. [15] E. Foundation, “Eclipse Model Development Tools,” https://www. to apply agile processes, workflows and tools. eclipse.org/modeling/mdt/?project=uml2/, 2019, [Online; accessed 15- November-2019]. VII. C ONCLUSION AND F UTURE W ORK [16] International Organization for Standardization (ISO), “ISO 26262-8 – Road vehicles – Functional safety, Part 8: Supporting processes,” In this paper, we presented the requirements and a solution Technical Committee 22 (ISO/TC 22), Tech. Rep., 2011. [17] “Regulation No 13-H of the Economic Commission for Europe of for a software architecture description approach in an agile de- the United Nations (UN/ECE) - Uniform provisions concerning the velopment project. The solution included a Treat Architecture approval of passenger cars with regard to braking,” https://eur-lex. like Code philosophy and our architecture tool chain, based on europa.eu/legal-content/EN/TXT/?uri=CELEX:42015X1222(01), 2015, [Online; accessed 04-October-2019]. an extended version of the publicly available Franca modeling [18] “Regulation No 79 of the Economic Commission for Europe of the framework. United Nations (UN/ECE) - Uniform provisions concerning the ap- Our Treat Architecture like Code approach facilitates feature proval of vehicles with regard to steering equipment,” https://eur-lex. europa.eu/legal-content/EN/TXT/?uri=CELEX:42008X0527(01), 2008, teams to perform their end-to-end responsibility, from writing [Online; accessed 04-October-2019]. requirements, architecture descriptions, code, tests and even- [19] Google, “Bazel - a fast, scalable, multi-language and extensible build tually bring the changes into the master of the repository, such system,” https://bazel.build/, 2019, [Online; accessed 04-October-2019]. that the changes can be delivered. The approach enables a lean and efficient way to model modular independent parts of the architecture, by independent feature teams. As success story, we can see already in the repository that our Franca+ based modeling approach has been directly adopted in the development. More than 200 developers from 4 companies contributed to the Franca+ models in quite a short time after releasing this approach. This is already a big improvement compared to traditional centralized UML based architecture modeling tools, where only some experts can edit the models (due to impediments in knowledge, rights or tool- licenses), and a simple change request sometimes takes weeks to introduce.