=Paper=
{{Paper
|id=Vol-2581/ase2020paper2
|storemode=property
|title=A Domain-Specific Language Based Architecture Modeling Approach for Safety Critical Automotive Software Systems
|pdfUrl=https://ceur-ws.org/Vol-2581/ase2020paper2.pdf
|volume=Vol-2581
|authors=Stefan Schlichthaerle,Klaus Becker,Sebastian Sperber
|dblpUrl=https://dblp.org/rec/conf/se/SchlichtharleBS20
}}
==A Domain-Specific Language Based Architecture Modeling Approach for Safety Critical Automotive Software Systems==
https://ceur-ws.org/Vol-2581/ase2020paper2.pdf
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.