RTE Generation and BSW Configuration

Tool-Extension for Embedded Automotive Systems

Georg Macher∗k ,Rene Obendraufk , Eric Armengaudk , Eugen Brenner∗ and Christian Kreiner∗
∗ Institute for Technical Informatics, Graz University of Technology, AUSTRIA
Email: {georg.macher, brenner, christian.kreiner}@tugraz.at

k AVL
List GmbH, Graz, AUSTRIA
Email: {georg.macher, rene.obendrauf, eric.armengaud}@avl.com

Abstract—Automotive embedded systems have become very for supporting the description of the system under develop-
complex, are strongly integrated and the safety-criticality and ment in a more structured manner. Model-based development
real-time constraints of these systems are raising new challenges. approaches enable different views for different stakeholders,
Distributed system development, short time-to-market intervals, different levels of abstraction, and provide a central storage of
and automotive safety standards (such as ISO 26262 [8]) re- information. This improves the consistency, correctness, and
quire efficient and consistent product development along the
entire development lifecycle. The challenge, however, is to ensure
completeness of the system specification. Nevertheless, such
consistency of the concept constraints and configurations along seamless integrations of model-based development are still the
the entire product life cycle. So far, existing solutions are still exception rather than the rule and frequently MBD approaches
frequently insufficient when transforming system models with a fall short due to the lack of integration of conceptual and
higher level of abstraction to more concrete engineering models tooling levels [3].
(such as software engineering models).
The aim of this paper is to present a tool approach which
The aim of this work is to present a model-driven system- enables a seamless description of safety-critical software, from
engineering framework addon, which enables the configurations requirements at the system level down to software component
of basic software components and the generation of a runtime implementation in a bidirectional way. With the presented
environment layer (RTE; interface between application and
basic software) for embedded automotive system, consistent with
tool available hardware- software interfacing (HSI) information
preexisting constraints and system descriptions. With this aim in can be used to generate basic software (BSW) component
mind a tool bridge to seamlessly transfer artifacts from system configurations, as well as, automatic generation of the run-
development level to software development level is described. This time environment layer (RTE; interface between application
enables the seamless description of automotive software and soft- software (ASW) and basic software).
ware module configurations, from system level requirements to
software implementation and therefore ensures both consistency The tool consists of a basic software configuration
and correctness for the configuration. generator and a software interface generator producing .c
and .h files for linking ASW and BSW. To ensure more
Keywords—automotive, embedded systems, Model-based devel-
versatility of the tool the required HSI information can either
opment, basic software configuration, traceability, model-based
software engineering. be imported from a HSI spreadsheet template or the system
model representation. The goal is, on one hand, to support
a consistent and traceable refinement from the early concept
I. I NTRODUCTION phase to software implementation, and on the other hand,
to combine the versatility and intuitiveness of spreadsheet
Embedded systems are already integrated into our everyday tools (such as Excel) and the properties of MDB tools
lives and play a central role in all domains including automo- (e.g., different views, levels of abstraction, central source of
tive, aerospace, healthcare, manufacturing industry, energy, or information, and information reuse) bidirectionally to support
consumer electronics. Current premium cars implement more semi-automatic generation of BSW configuration and the
than 90 electronic control units (ECU) per car with close to 1 SW-SW interface layer (in AUTOSAR notation known as
Gigabyte software code [4], these are responsible for 25% of runtime environment - RTE).
vehicle costs and bring an added value between 40% to 75%
[18]. This trend of making use of modern embedded systems,
which implement increasingly complex software functions The document is organized as follows:
instead of traditional mechanical systems is unbroken in the Section II presents an overview of related works as well as the
automotive domain. Similarly, the need is growing for more fundamental model-based development tool chain on which
sophisticated software tools, which support these system and the approach is based. In Section III a description of the
software development processes in a holistic manner. As a con- proposed tool and a detailed depiction of the contribution parts
sequence, the handling of upcoming issues with modern real- is provided. An application and evaluation of the approach is
time systems, also in relation to ISO 26262 [8], model-based presented in Section IV. Finally, this work is concluded in
development (MBD) would appear to be the best approach Section V with an overview of the presented approach.
 HSI
SPREADSHEET INFORMATION IMPORTER

SYSTEM MODELING TOOLS

ASW/BSW INTERFACE GENERATOR

&
System Requirements BSW CONFIGURATOR
BSW – Low
Level Driver
Safety Requirements

System Architecture

SW Architecture HW Architecture
Interface. AVLIL_ AVLIL_ AVLIL_
HW AND SW MODELING FRAMEWORK Adc.h
c Adc.c Port.c PWM.c

Interface AVLIL_ AVLIL_ AVLIL_

Can.h
.h Adc.h Dio.h PWM.h

AVLIL_ AVLIL_ AVLIL_

Adc_cfg. Dio_cfg. PWMcfg Dio.h
c h .h

Fig. 2. Portrayal of the Approach for Generation of BSW Configuration and SW Interfaceing Files for the SW Development Phase

additional familiarization with usually very complex and time-

InputA.c consuming AUTOSAR tools compared to the full AUTOSAR
manual approach (ICC3). The ICC1 approach does not take advantage
rework
of the AUTOSAR benefits from the full AUTOSAR tool-chain
supporting tools for RTE configuration and communication
FunctionA.c
interfaces, but standardized component interfaces for exchange
of data between the ASW and BSW and therefore features the
separation of application specific and hardware specific soft-
OutputA.c
ware parts (like native non-AUTOSAR development). ICC1
Software Development Tool manual mainly focuses on SW engineering and more specifically on
rework
the integration of ASW into a given SW architecture. However,
Fig. 1. ICC1 AUTOSAR Approach Methodology with Required Manual the aspects related to control systems engineering (including
Intervention HW/SW co-design) are not integrated and aspects such as
HW/SW interface definition must be performed manually, as
indicated in Figure 1. The tool approach introduced in this
II. R ELATED W ORK work enhances this aspect by providing a framework for the
Development of automotive embedded software as well as visualization of both ASW and BSW interface configuration
the configuration of the underlying basic software and em- and automated generation of these interfacing .c and .h files
bedded systems are engineering domains and research topics (see Figure 2). Furthermore, the available hardware- software
aimed at moving the development process to an automated interfacing (HSI) information can be used to generate basic
work-flow for improving the consistency and tackling the com- software (BSW) components configurations and the HSI infor-
plexity of the software development process across expertise mation import functionality can also handle HSI spreadsheet
and domain boundaries. Recent publications are mainly based templates to ensure more versatility of the tool.
on AUTOSAR [1] methodology. An approach for an AUTOSAR migration of existing
automotive software is described in the work of Kum et.
Due to the ever increasing software complexity of the
al [10]. The authors highlight the benefits of separating the
last few years more and more efforts are becoming necessary
application software and the basic software and present an
to manage the development process of automotive embedded
approach to configuration of basic software modules instead of
software. To handle this complexity the AUTOSAR consor-
time consuming and error-prone manual coding of embedded
tium was founded and the AUTOSAR methodology provides
software. The automatic generation of automotive embedded
standardized and clearly defined interfaces between different
software and the resultant configuration of the embedded
software components. The AUTOSAR approach features three
systems thus improves quality as well as re-usability.
different classes of implementation (ICC - implementation
conformance class). The main benefit of the AUTOSAR ICC1 In [11], the authors describe a framework for a seamless
approach clearly relies on the time-saving in terms of no configuration process for the development of automotive em-
bedded software. The framework is also based on AUTOSAR supports (1) the generation of source code and (2) configura-
which defines the architecture, methodology, and application tion of the basic software from information available at system
interfaces. The configuration process is established via system level and from system models. The approach we present
configuration and ECU configuration. All the configurations by contrast, supports not only the automatic generation of
and descriptions used are stored in separate XML (Extensible the RTE source code, but also the automated generation of
Markup Language) files, containing described and classified basic software configuration of embedded systems from system
parameters and the associated information. The authors addi- models.
tionally specify a meta-model for the AUTOSAR exchange
formats that describe the ECU configuration parameter defini- III. BASIC S OFTWARE I NTERFACE AND C ONFIGURATION
tion and the ECU configuration description. G ENERATION A PPROACH
Jo et al. [9] describe an approach for the design of a ve- The underlying concept of the approach is to have a consis-
hicular code generator for distributed automotive systems. The tent information repository as a central source of information,
increasing complexity during development of an automotive to store all information of all engineering disciplines involved
embedded software and systems and the manual generation in embedded automotive system development in a structured
of software have the effect of leading to more and more manner [13]. The concept focuses on allowing different engi-
software defects and problems. The authors thus integrated neers to do their job in their own specific way, but providing
a RTE module into their earlier development phase tool to traces and dependency analysis of features concerning the
design and evolve an automated embedded code generator with overall system, e.g. safety, security, or dependability. The
a predefined generation process. The presented approach saves approach stirs out of common AUTOSAR based approaches
time through automated generation of software code, compared and additionally supports a non-AUTOSAR or AUTOSAR
to manual code generation, it reduces error-prone and time- ICC1 approach, which are frequently hampered due to a
consuming tasks and is also based on an AUTOSAR aligned lack of supporting tools. The decision of not fostering a full
approach. The output of the code generator tool is limited AUTOSAR approach is based on the one hand on focusing not
to the RTE source code and the application programming only AUTOSAR based automotive software development and
interface (API) of the input information. As in our approach, on the other hand, experiences we have made with our previous
the configuration of software modules, is not focused. approach [12] confirm the problem mentioned by Rodriguez
et al. [16]. Not all development tools fully support the entire
Piao et al. [15] illustrate a design and implementation AUTOSAR standard, because of its complexity, which leads to
approach of a RTE generator for automotive embedded soft- several mutual incompatibilities and interoperability problems.
ware. The RTE layer is located in the middle-ware layer of
the AUTOSAR software architecture and combines the top Figure 2 shows an overview of the approach and highlights
layer mentioned as application software with the underlying the main contributions. For a more detailed overview of the
hardware and basic software. Automated code generation aims orchestration for the overall development tool-chain see [13].
at moving the development steps closer together and thus im- The tool approach introduced in this work provides a
proving the consistency of the software development process. framework for the visualization of ASW and BSW interface
The output of the automated RTE generator are communication configuration and automated generation of these interfacing
API functions for AUTOSAR SW components of the ASW. .c and .h files (see Figure 2). Furthermore, the available
Focusing on software complexity, Jo et al. [7] presents hardware- software interfacing (HSI) information can be used
a design for a RTE template structure to manage and de- to generate basic software (BSW) component configurations
velop software modules in automotive industry. The authors and the HSI information import functionality can also handle
focus on the design of a RTE structure also based on the HSI spreadsheet templates to ensure more versatility of the
AUTOSAR methodology. Within this design they describe the tool. More specifically, the contribution proposed in this work
Virtual Functional BUS (VFB) which establishes independence consists of the following parts:
between the Application Software (ASW) and the underlying
• AUTOSAR aligned UML modeling framework:
basic software (BSW) and hardware.
Enhancement of an UML profile for the definition of
In [14], an approach for realizing location-transparent inter- AUTOSAR specific artifacts, more precisely, for the
action between software components is shown. The proposed definition of the components interfaces (based on the
work illustrates the relationship between the RTE and the VFB virtual function bus abstraction layer), see Figure 2 –
and shows which artifacts of the VFB are necessary for the HW and SW Modeling Framework.
generation of the RTE.
• BSW and HW module modeling framework:
A work depicting the influence of the AUTOSAR method- Enhancement of an UML profile to describe BSW
ology on software development tool-chains is presented by components and HW components. To ensure consis-
Voget [19]. The tool framework presented, named ARTOP tency of the specification and implementation for the
(AUTOSAR Tool Platform), is an infrastructure platform that entire control system, see Figure 2 – HW and SW
provides features for the development of tools used for the Modeling Framework.
configuration of AUTOSAR systems. The implemented fea-
• RTE generator:
tures are base functionalities required for different AUTOSAR
Enables the generation of interface files (.c and .h) be-
tool implementations. The work does not, however, focus on
tween application-specific and hardware-specific soft-
a specific tool integration.
ware functions, see Figure 2 – ASW/BSW Interface
To summarize, none of the approaches described above Generator .
Fig. 3. Screenshot of the SW Architecture Representation within the System Development Tool and Representation of the Interface Information

• Basic software configuration generator: following sections describe those parts of the approach that
Generates BSW configurations according to the spec- make key contributions in more details.
ifications within the HSI definition, see Figure 2 –
BSW Configurator. A. AUTOSAR aligned UML modeling framework
• Spreadsheet information importer: The first part of the approach is a specific UML model-
Enables the import of HSI definition information done ing framework enabling software architecture design in AU-
in spreadsheet format, see Figure 2 – Spreadsheet TOSAR like representation within a state-of-the-art system
Information Importer. development tool (in this case Enterprise Architect). A specific
UML profile to limit the UML possibilities to the needs of
This proposed approach closes the gap between system-
software architecture development of safety-critical systems
level development of abstract UML-like representations and
and enable software architecture design in AUTOSAR like
software-level development, also mentioned by Giese et al. [5],
representation within the system development tool (Enterprise
Holtmann et al. [6], and Sandmann and Seibt [17] by support-
Architect). In addition to the AUTOSAR VFB abstraction layer
ing consistent information transfer between system engineering
[2], the profile enables an explicit definition of components,
tools and software engineering tools. Furthermore the approach
component interfaces, and connections between interfaces.
minimizes redundant manual information exchange between
This provides the possibility to define software architecture
tools and contributes to simplifying seamless safety argumen-
and ensures proper definition of the communication between
tation according to ISO 26262 for the developed system. The
the architecture artifacts, including interface specifications
benefits of this development approach are highly noticeable in
(e.g. upper limits, initial values, formulas). Hence the SW
terms of re-engineering cycles, tool changes, and reworking
architecture representation within EA can be linked to system
of development artifacts with alternating dependencies, as
development artifacts and traces to requirements can be easily
mentioned by Broy et al. [3].
established. This brings further benefits in terms of constraints
The contribution proposed in this work is part of the frame- checking, traceability of development decisions (e.g. for safety
work presented in [13] aiming towards software development case generation), reuse and ensures the versatility to also
in the automotive context. The implementation of the approach enable AUTOSAR aligned development as proposed in [12].
is based on versatile C# class libraries (dll) and API command Figure 3 shows an example of software architecture artifacts
implementations to ensure tool and tool version in-dependence and interface information represented in Enterprise Architect.
of the general-purpose UML modeling tool (such as Enterprise As can be seen in the depiction, all artifacts required to model
Architect or Artisan Studio) and other involved tools (such as the SW architecture are represented and inherit the required
spreadsheet tool and software development framework). The information as tagged values.
 APPLICATION SW
LAYER
APPLICATION APPLICATION APPLICATION
A.C B.C C.C

SW / SW INTERFACE LAYER
INTERFACE.C

AVLIL_BSW AVLIL_BSW AVLIL_BSW

A.C B.C C.C

BASIC SOFTWARE
Fig. 4. Screenshot of the BSW and HW Pin Representation within the System

LAYER
Development Tool
BSWDRIVER BSWDRIVER BSWDRIVER
A.C A.C A.C

B. BSW and HW Module Modeling Framework

The AUTOSAR architectural approach ensures hardware- Fig. 5. Overview of Architecture Level Files Generated by the Interface
Generator
independent development of application software modules
until a very late development phase and therefore enables
application software developers and basic software developers of basic SW drivers. This ensures independence from imple-
to work in parallel. The hardware profile of the approach mentation of the BSW drivers and also features an AUTOSAR
allows a graphical representation of hardware resources (such ICC1 approach if needed.
as ADC, CAN), calculation engines (core), and connected
peripherals which interact with the software. Special basic D. Basic Software Configuration Generator
software (BSW) and hardware module representations are
assigned to establish links to the underlying basic software The basic software configuration generator is also part
and hardware layers. This enables an intuitive graphical means of the dll- based tool, which generates BSW driver specific
of establishing software and hardware dependencies and a ∗ cf g.c files. These files configure the vendor specific low-
hardware-software interface (HSI), as required by ISO 26262. level driver (basic software driver) of the HW device according
Software signals of BSW modules can be linked to HW port to the HSI specifications. The mapping of HSI specifications to
pins via dedicated mappings. On the one hand this enables low-level driver configuration is hardware and low-level driver
the modeling and mapping of HW specifics and SW signals, implementation specific and needs to be done once per HW
see Figure 4 and on the other hand this mapping establishes device and supported low-level driver package.
traceable links to port pin configurations. A third point is that
this HW dependencies can be used to interlink scheduling and E. HSI Spreadsheet Information Importer
task allocation analysis tools for analysis and optimization of The HSI definition requires mutual domain knowledge of
resource utilization. hardware and software and is to be a work product of a
collective workshop of hardware, software, and system experts
C. Runtime Environment Generator and will act as the linkage between different levels of devel-
opment. Consistency and evidence of correct implementation
The third part of presented approach is the SW/SW in-
of HSI can be challenging in case of concurrent HW and SW
terface generator. This dll- based tool generates .c and .h
development and cross-dependencies of asynchronous update
files defining SW/SW interfaces between application software
intervals. Therefore, this approach enables a practicable and
signals and basic software signals based on modeled HSI
intuitive way of engineering HSI definitions in a spreadsheet
artifacts. In addition, this generation eliminates the need for
tool (Excel) and transforms them to a reusable and version-
manual SW/SW interface generation without adequate syntax
able representation in the MDB tool (Enterprise Architect).
and semantic support and ensures the reproducibility and
The spreadsheet template defines the structure of the data
traceability of these configurations.
representation in a project-specific customizable way. On the
Figure 5 shows the conceptual overview of generated one hand this enables a practicable and intuitive means of
files. The .c and .h files on application software level are engineering HSI definitions with spreadsheet tools, while their
generated via a model-based software engineering tool, such machine- and human-readable notation ensures a cost- and
as Matlab/Simulink. The files on the basic software level time-saving alternative to the usually complex special-purpose
are usually provided by the hardware vendor. While the files tools, while on the other hand it enables the generation of
referred to in the SW/SW interface layer are generated by our SW/SW interface files and BSW configurations without the
approach. need for a model-based development toolchain in place. Figure
6 depicts the project-independent template structure for HSI
The generated files are designed in a two-step approach. definition data preparation.
The first step of the interfacing approach (interf ace.c and
interf ace.h) establishes the interface between ASW and
IV. A PPLICATION OF THE P ROPOSED A PPROACH
BSW based on AUTOSAR RTE calls. The second step
(AV LIL BSW a.c and AV LIL BSW a.h) maps these AU- This section demonstrates the benefits of the introduced
TOSAR RTE based calls to the HW specific implementation approach for development of automotive embedded systems.
 This results in the file architecture depicted in Figure 7.
With the use of the approach 8 additional interfacing files with
481 lines of code (LoC) source and 288 LoC configuration
have been generated.
In terms of getting started with AUTOSAR aligned devel-
opment or supporting non-AUTOSAR SW development our
approach features a smooth first step approach of the ICC1 AU-
TOSAR and generates an interface layer (similar to AUTOSAR
RTE) without relying on full AUTOSAR tooling support. In
terms of safety-critical development the approach presented
supports traceability links between BSW configurations to HSI
information and eliminates the need of manual interface source
code rework, which further surmounts the main drawbacks of
the ICC1 AUTOSAR approach.

V. C ONCLUSION
An important challenge for the development of embedded
Fig. 6. Example of a project-independent spreadsheet template structure for automotive systems is to ensure consistency of the design
HSI definition decisions, SW implementations, and driver configurations,
especially in the context of safety-related development. This
TABLE I. OVERVIEW OF THE E VALUATION U SE -C ASE SW work presents an approach which seamlessly describes safety-
A RCHITECTURE
critical software, from requirements at the system level down
to software component implementation in a traceable manner.
Object type Element- Configurable The available hardware- software interfacing (HSI) information
count Attributes can thus be used to generate basic software (BSW) component
per Element configurations, as well as automatic software interface layer
ASW Modules 10 3
generation (interface between application software and basic
BSW Modules 7 3 software). With this aim in mind a framework consisting
ASW Module Inputs 54 10 of a basic software configuration generator and a software
ASW Module Outputs 32 10 interface generator producing .c and .h files for linking ASW
ASW/ASW Interfaces 48 - and BSW has been presented, which can also be used in
ASW/BSW Interfaces 19 - combination with a spreadsheet based HSI definition. The
HW/SW Interfaces 19 13 main benefits of this enhancement are: improved consistency
and traceability from the initial design at the system level
down to the single CPU driver configuration, together with a
We used an automotive battery management system (BMS) reduction of cumbersome and error-prone manual work along
as the use-case for the evaluation of the approach. This use- the system development path. Further improvements of the
case is an illustrative material, reduced for internal training approach include the progress in terms of reproducibility and
purposes and is not intended to be either exhaustive in scope traceability of configurations for software development (such
or to represent leading-edge technology. as driver configurations and SW-SW interfaces).

The definition of the software architecture is usually done The application of the presented approach has been demon-
by a software system architect within the software development strated utilizing an automotive BMS use-case, which is in-
tool (Matlab/Simulink). With our approach this work package tended to be used for training purposes for students and
is included in the system development tool (as shown in engineers and does not represent either an exhaustive or a
Figure 3). This does not hamper the work of the software commercial sensitive project. While the authors do not claim
architect but enables the possibility to also link existing HSI completeness of the analysis (due to confidentiality issues), the
mapping information to the SW architecture (as shown in benefits of the approach are already evident.
Figure 4).
ACKNOWLEDGMENTS
The use-case consists of 10 ASW modules and 7 BSW
modules with 19 interface definitions between ASW and BSW This work is partially supported by the EM C 2 and the
and makes use of the 3 fundamental low-level HW functions M EM CON S projects.
(digital input/output, analog input/outputs, and PWM outputs).
A more complete overview of use-case is given in Table I. The research leading to these results has received funding
from the ARTEMIS Joint Undertaking under grant agree-
The definition of the 19 HW/SW interfaces with 10 pa- ment nr 621429 (project EM C 2 ) and financial support of
rameters for each SW signal and 13 parameters for each HW the ”COMET K2 - Competence Centers for Excellent Tech-
pin sums up to 437 parameter configurations within the HSI nologies Programme” of the Austrian Federal Ministry for
spreadsheet template or in the MDB tool, which can be used Transport, Innovation and Technology (BMVIT), the Austrian
to generate ASW/BSW interfaces and BSW configurations. Federal Ministry of Economy, Family and Youth (BMWFJ),
 APPLICATION
SW LAYER
IO_ACCPED.C MOTORCONTROL.C IO_THRVAL.C

GETACCPEDFILTERED1() SETMCOUTPUT() GETTHRVALFILTERED1()

GETACCPEDFILTERED2() SETMCE NABLE() GETTHRVALFILTERED2()
CLEARMCENABLE()
...
SWI_1MS()
SWI_10MS()
SWI_100MS()
INTERFACE.C XCUIF.C
INTERFACE LAYER
ADC_INIT() PORT_INIT() PWM_INIT()
AVLIL_GETVALADC() RTE_IREAD_EGASSYS RTE_IREAD_EGASSYS
RTE_IREAD_EGASSYSTEM_1M TEM_1MS_PORT_APE TEM_1MS_PWM_AP
S_ADC_THRPOSN1_IN() DL1_IN() EDL2_IN()
... ... ...
AVLIL_ADC.C AVLIL_PORT.C AVLIL_PWM.C

ADC_INITMODULE() PORT_SETPINMODEINPUT() GTM_TOM_TIMER_INITCONFIG()

ADC_INITMODULECONFIG() PORT_SETPINMODEOUTPUT() GTM_TOM_TIMER_INIT()
ADC_INITGROUP() PORT_SETPINSTATE() GTM_PINMAP_SETTOMTOUT()
ADC_INITGROUPCONFIG() PORT_SETPINMODE() GTM_TOM_TGC_ENABLECHANNELS()
ADC_INITCHANNEL() PORT_SETPINPADDRIVER() GTM_TOM_CH_SETSIGNALLEVEL()
ADC_INITCHANNELCONFIG() ... ...
BASIC SW LAYER

...

ADC.C PORT.C PWM.C

Fig. 7. Excerpt of Generated Files for the BMS Use-Case

the Austrian Research Promotion Agency (FFG), the Province [10] D. Kum, G.-M. Park, S. Lee, and W. Jung. AUTOSAR Migration from
of Styria, and the Styrian Business Promotion Agency (SFG). Existing Automotive Software. In International Conference on Control,
Automation and Systems, COEX, Seoul, Korea, 2008. DGIST.
Furthermore, we would like to express our thanks to our [11] J.-C. Lee and T.-M. Han. ECU Configuration Framework based on
supporting project partners, AVL List GmbH, Virtual Vehicle AUTOSAR ECU Configuration Metamodel. 2009.
Research Center, and Graz University of Technology. [12] G. Macher, E. Armengaud, and C. Kreiner. Automated Generation of
AUTOSAR Description File for Safety-Critical Software Architectures.
R EFERENCES In 12. Workshop Automotive Software Engineering (ASE), Lecture Notes
in Informatics, pages 2145–2156, 2014.
[1] AUTOSAR development cooperation. AUTOSAR AUTomotive Open
System ARchitecture, 2009. [13] G. Macher, E. Armengaud, and C. Kreiner. Bridging Automotive
Systems, Safety and Software Engineering by a Seamless Tool Chain.
[2] AUTOSAR Development Cooperation. Virtual Functional Bus. online, In 7th European Congress Embedded Real Time Software and Systems
2013. Proceedings, pages 256 –263, 2014.
[3] M. Broy, M. Feilkas, M. Herrmannsdoerfer, S. Merenda, and D. Ratiu. [14] N. Naumann. Autosar runtime environment and virtual function bus.
Seamless Model-based Development: from Isolated Tool to Integrated Department for System Analysis and Modeling.
Model Engineering Environments. IEEE Magazin, 2008.
[15] S. Piao, H. Jo, S. Jin, and W. Jung. Design and Implementation
[4] C. Ebert and C. Jones. Embedded Software: Facts, Figures, and Future.
of RTE Generator for Automotive Embedded Software. In Seventh
IEEE Computer Society, 0018-9162/09:42–52, 2009.
ACIS International Conference on Software Engineering Research,
[5] H. Giese, S. Hildebrandt, and S. Neumann. Model Synchronization Management and Applications. DGIST, 2009.
at Work: Keeping SysML and AUTOSAR Models Consistent. LNCS
5765, pages pp. 555 –579, 2010. [16] E. Rodriguez-Priego, F. Garcia-Izquierdo, and A. Rubio. Modeling
Issues: A Survival Guide for a Non-expert Modeler. Models2010,
[6] J. Holtmann, J. Meyer, and M. Meyer. A Seamless Model-Based 2:361–375, 2010.
Development Process for Automotive Systems, 2011.
[17] G. Sandmann and M. Seibt. AUTOSAR-Compliant Development
[7] J. Hyun Chul, P. Shiquan, C. Sung Rae, and J. Woo Young. RTE Workflows: From Architecture to Implementation - Tool Interoperability
Template Structure for AUTOSAR based Embedded Software Platform. for Round-Trip Engineering and Verification & Validation. SAE World
In Basic Research Program of the Ministry of Education, Science and Congress & Exhibition 2012, (SAE 2012-01-0962), 2012.
Technology, pages 233–237, 2008.
[18] G. Scuro. Automotive industry: Innovation driven by elec-
[8] ISO - International Organization for Standardization. ISO 26262 Road
tronics. http://embedded-computing.com/articles/automotive-industry-
vehicles Functional Safety Part 1-10, 2011.
innovation-driven-electronics/, 2012.
[9] H. C. Jo, S. Piao, and W. Y. Jung. Design of a Vehicular code
generator for Distributed Automotive Systems. In Seventh International [19] S. Voget. AUTOSAR and the Automotive Tool Chain. In DATE10,
Conference on Information Technology. DGIST, 2010. 2010.