=Paper=
{{Paper
|id=Vol-1291/ewili14_19
|storemode=property
|title=Automotive Real-time Operating Systems: A Model-Based Configuration Approach
|pdfUrl=https://ceur-ws.org/Vol-1291/ewili14_19.pdf
|volume=Vol-1291
}}
==Automotive Real-time Operating Systems: A Model-Based Configuration Approach==
https://ceur-ws.org/Vol-1291/ewili14_19.pdf
Automotive Real-time Operating Systems: A Model-Based
Configuration Approach
Georg Macher Muesluem Atas Eric Armengaud
Institute for Technical Institute for Technical AVL List GmbH
Informatics Informatics Hans-List-Platz 1
Graz University of Technology Graz University of Technology Graz, Austria
AVL List GmbH AVL List GmbH eric.armengaud@avl.com
Graz, AUSTRIA Graz, AUSTRIA
georg.macher@tugraz.at muesluem.atas@avl.com
Christian Kreiner
Institute for Technical
Informatics
Graz University of Technology
Graz, Austria
christian.kreiner@tugraz.at
ABSTRACT 1. INTRODUCTION
Automotive embedded systems have become very complex, The number of embedded systems in the automotive do-
are strongly integrated, and the safety-criticality and real- main has grown significantly in recent years. This trend
time constraints of these systems raise new challenges. Dis- is also strongly supported by the ongoing replacement of
tributed system development, short time-to-market inter- traditional mechanical systems with modern embedded sys-
vals, and automotive safety standards (such as ISO 26262 tems. This enables the deployment of more advanced con-
[8]) require efficient and consistent product development along trol strategies, thus providing added values for the customer
the entire development lifecycle. The automotive OSEK/ and more environment friendly vehicles. At the same time,
VDX standard provides an architecture for distributed real- the higher degree of integration and the safety-criticality of
time units in vehicles and a language aiming in specify- the control application raises new challenges. Evidence of
ing the configuration of real-time OSEK operating systems. correctness of the different applications, both in the time
The aim of this paper is to enhance a model-driven system- domain and value domain, possibly running on the same
engineering framework with the capability of generating OS computing platform, has to be guaranteed. In parallel, new
configurations from existing high level control system infor- computing architectures with services integrated in hard-
mation. Furthermore, to enable the possibility to update ware require new software architectures and safety concepts.
stored information from OSEK Implementation Language Safety standards such as ISO 26262 [8] for road vehicles
(OIL) files and support round-trip engineering of real-time have been established to provide guidance during the de-
operating system (RTOS) configurations. This enables the velopment of safety-critical systems. These standards rely
seamless description of automotive RTOS, from system level on risk identification and mitigation strategies. They target
requirements to software implementation and therefore en- early hazard identification as well as solid counter measure
sures consistency and correctness of the configuration. To specification, implementation and validation along the entire
that aim, a bidirectional tool bridge is proposed based on product life cycle. One challenge in this context is to pro-
OSEK OIL exchange format files. vide evidence of consistency, correctness, and completeness
of system specifications over different work-products along
the entire product development process. This is a required
Categories and Subject Descriptors basis for the development of dependable systems. More-
D.4.7 [Operating Systems]: Organization and Design; D.2.3 over, the consolidation of the system specification enables
[Software Engineering]: Coding Tools and Techniques early bug finding and thus support reducing the costs for
bug fixes and late re-design.
To handle these issues, model-based development sup-
General Terms ports the description of the system under development in
a more structured way, enables different views for differ-
Model-based development, traceability, embedded operating
ent stakeholders, different levels of abstraction, and central
systems, OSEK OIL, ISO 26262, RTOS.
source of information.
The contribution of this paper is to bridge the existing gap
between model-driven system engineering tools and software
engineering tools for automotive real-time operating systems
(RTOS). More especially, the approach makes use of exist-
EWiLi’14, November 2014, Lisbon, Portugal.
ing high level control system information in SysML format to
Copyright retained by the authors. generate the configuration of automotive real-time operating
Figure 1: Comparison OIL File Normal View vs. Graphical Representation with Eclipse
systems in a standardized OSEK Implementation Language 2.1 OSEK Implementation Language
file format (OIL files) [14]. Information from the control As mentioned previously, the OIL files inherit a normal-
system (such as control strategies) can thus be mapped to ized description language for OS configuration and related
a configuration at software level (e.g., required interfaces to objects. OIL files are commonly used in the automotive
other SW components, allocation to a CPU respectively to domain to configure the real-time operating systems of indi-
a task). The goal is to support a consistent and traceable re- vidual ECUs. This is frequently done manually, due to the
finement, as required by ISO 26262 standard, from the early simple human readable structure of OIL files and the lack of
concept phase to individual configurations of the RTOS. tools supporting an automated information exchange. OIL
The document is organized as follows: Section 2 presents files typically consist of implementation specific definitions,
an introduction to OSEK/VDX and OSEK OIL. Then, model- which are closely related to the hardware (ECU) in use and
based development and integrated tool chains, as well as specify the OIL object with all their possible attribute prop-
the base tool-chain for this approach are presented in Sec- erties.
tion 3. In Section 4 a description of the proposed approach Due to the introduction of multi-core real-time systems
for the generation of RTOS configuration files according to and the awareness of safety-criticality of such systems, tool
OIL standard is provided. An application and evaluation of support and automation of OIL generation becomes increas-
the approach is presented in Section 5. Finally, this work ingly relevant. An example of safety-related configuration
is concluded in Section 6 with an overview of the presented parameters contained in the OIL file are shared task re-
approach. sources or task priorities.
2. OSEK/VDX RTOS OVERVIEW 2.2 OSEK Related Tools and Publications
The German OSEK consortium (German abbreviation for To our knowledge most development frameworks do not
open systems and their interfaces for electronics in motor include a tool for automatic OIL file generation from prior
vehicles) was founded in 1993 by several German automotive information of previous development stages at a higher ab-
companies. VDX (Vehicle Distributed eXecutive) was the straction level. Nevertheless, within this work tool infor-
French pendant from the French car manufacturers’ side, mation for commercial tools has been omitted due to non-
which regrouped the OSEK/VDX consortium in 1994. exhaustiveness of such an overview and the fact that this
OSEK/VDX is an open standard for specifications for em- information can be found up-to-date on the respective web-
bedded real-time operating systems (RTOS), designed to site (e.g., Vector OIL Configurator or GOB - GUI based OIL
provide a standard software architecture for the various elec- Builder).
tronic control units (ECUs), and partially standardized in Most frameworks either require manual generation of OIL
ISO 17356 [7]. files by the developer, or they provide a dedicated graphical
The work of the OSEK/VDX consortium is today contin- user interface for support and guidance while generating the
ued by the AUTOSAR consortium [1], which is based on OIL file. Figure 1 shows a comparison of the same OIL file
OSEK/VDX specifications. To describe the configuration of in typical editor view and in a guided graphical representa-
an OSEK RTOS the OSEK implementation language files tion within an Eclipse-based development framework. Many
(OIL) is intended to be used. These files can be generated available OIL file configurators provide such a representation
manually or via configuration tools. OIL files include all of the OIL information. They thus provide guidance to min-
object containers and information required to configure the imize configuration failures, but do not reduce workload or
RTOS of one specific ECU. speed up the generation of OIL files. Also the import of
prior available information is very limited. level tools and software development tools. Second, incon-
SmartOSEK’s visual designer [17] makes use of a DSL (do- sistency and redundant information, due to various very spe-
main specific language) approach. The visual designing tool cific tools and a lack of automated information transfer.
enables modeling of applications in a graphical way and au- Giese et al. [4] also highlight the step from system design
tomatic generation of OIL files. The main drawback of this to software design as critical. System design models have to
approach is the missing availability to feedback information be correctly transferred to the software engineering model,
into the model. and later changes must be kept consistent.
Most OIL configurators focus on generating OIL files at The work of Quadri and Sadovykh [15] presents approaches
software development level, such as in the work of Koester for novel model-driven techniques and new tools supporting
et al. [10]. The main disadvantage here is that prior infor- design, validation, and simulation. The authors highlight
mation of previous development phases cannot be used for the possibility of high level model analysis for schedulability
timing analysis or have to be transferred manually. and use a subset of UML and SysML for their approach.
Kim et al. [9] suggest a lightweight AUTOSAR software However, configuration of real-time operating systems ac-
platform and additional extensions of OSEK OIL files. The counting for timed resource constraints is not addressed in
presented approach focuses on adding extensions to OIL this work.
files, rather than supporting automated generation of OIL
files. 3.2 Basic Framework
The work of Yang et al. [16] presents a conversion of UML A brief overview of the model-based development toolchain
models into OSEK/VDX models for simulation and opti- in use and the related preliminary work for the toolchain of
mization of the system design. The authors claim that by the proposed approach is given in this section. The proto-
converting UML representations into OSEK/VDX models type of our toolchain, proposed by Mader [13], is a spe-
productivity can be improved, correctness of development cific implementation of a tool-independent and language-
artifacts can be ensured more easily, and documentation can independent methodology to support continuous safety anal-
be provided with less effort and better quality. yses of system architecture development according to ISO
Gu et al. [5] focus on the description of automated mecha- 26262 [8].
nisms for generating application codes and seamless integra- The basic concept behind this framework is to have a con-
tion of models for software development, but do not provide sistent information repository as central source of informa-
methods of the transformation of UML and OSEK artifacts. tion. The toolchain allows different engineering domains to
work on one model which provides traces between different
artifact types, and ensures timeliness of data. Extension for
3. MODEL-BASED DEVELOPMENT AND the modeling tool (Enterprise Architect r) ensure seamless
INTEGRATED TOOLCHAINS and consistent transition of information between the reposi-
This section provides a brief overview of model-based de- tory and various adequate special-purpose tools (such as OS
velopment (MBD) tools and related works, as well as the configurators). This approach also inherits an organizational
basic MBD framework of the presented approach. Again switch from document-centric development approaches to a
a tool overview of commercial tools has been omitted due seamless model-based development approach. For a more
to non-exhaustiveness and easy up-to-date online access of detailed overview of the concept and toolchain as a whole
such information on the respective website (e.g., Enterprise see [12].
Architect, Artisan Studio, EB studio, PREEvision).
4. OVERVIEW OF THE CONTRIBUTION
3.1 Model-Based Development Tools and Pub- The contribution proposed in this paper is an extension of
lications the previously mentioned framework towards RTOS config-
Fabbrini et al. [3] provide an overview of software en- uration. The contribution (see also highlighting in Figure 3)
gineering in the European automotive industry and present comprises the following aspects:
tools, techniques and countermeasures to prevent faults. This
work highlights the importance of tool integration and model- • UML modeling framework extension: Enhancement of
based development approaches. the software UML profile for visualization and process-
Broy et al. [2] mention model-based development as the ing of OSEK OIL files. To enable configuration of the
best approach to manage the large amount of information OSEK OS by prior available constraints.
and complexity of modern embedded systems. The authors
• OIL file generator : An extractor which automatically
also illustrate why seamless solutions have not been achieved
generates OIL files from existing information at sys-
so far, mention commonly used solutions, and problems that
tem development level. This ensures consistency of
arise by using an inadequate toolchain (e.g. redundancy,
the specification and implementation for the RTOS.
inconsistency and lack of automation). This work presents
basic ideas and concepts of MBD, but not detailed solutions. • OIL file importer : The importer supports round-trip
The work of Holtmann et al. [6] also highlights process and engineering by re-importation of information updates
tooling gaps between different development process steps. from OIL files.
A model-based development process is presented which con-
forms with the process reference model of Automotive SPICE. This proposed extension is a constituent of the proposed
With this use-case the authors highlight the lack of automa- toolchain in [12] to close the gap between system-level de-
tion for artifact traceability and missing guidelines for model velopment at abstract UML-like representations and RTOS
selection at varying abstraction levels. The work exposes configuration at software-level. This bridging extends the
two important gaps: First, missing links between system work presented in [11] on basic software level, guarantees
Figure 2: UML Profile Addons for OIL Objects
SYSTEM MODELING TOOL
this profile has been integrated in the existing framework de-
scribed in Section 3.2. Consequently, the system description
can be refined down to the operating system, thus improv-
System Requirements
BSW
BSW.c
ing architecture consistency over skills boundaries (such as
Configurator
Safety Requirements systems and software engineering).
System Architecture
SW Architecture HW Architecture
4.2 OIL File Generator
OS OS.c
OS.oil
BRIDGING APPROACH
Configurator
BASIC SOFTWARE
The second part of the approach is an exporter capable of
SYSTEM DEVELOPMENT SOFTWARE DEVELOPMENT
exporting the RTOS configuration available from the SysML
model to an OIL file. The exporter generates OIL files en-
riched with the available system and safety development ar-
Figure 3: Representation of the Bridging Approach tifact traces (such as required ASIL of task implementation).
to Ensure Boundless Information Exchange Most state-of-the-art software development frameworks are
able to configure the RTOS according to the specifications
within such an OIL file. Consequently the use of this ex-
consistency of information due to the single source of infor- porter additionally improves communication of the (safety)
mation principle, and shares information more precisely and context to the software experts into their native development
accurately. The approach minimizes redundant manual in- tools, thus improving the consistency of the product develop-
formation exchange between tools and also takes IS0 26262 ment. Furthermore, the toolchain is capable of multi-core or
requirements (especially traceability) and constraints into multi-system development, therefore the generation of OIL
account. file is selectable for individual cores.
Figure 3 shows the conceptual overview of the tool-chain
and highlights the OS configuration part. As can be seen 4.3 OIL File Importer
from the figure, a lack of tool support for information trans- The third part of the approach is the import functionality
fer between system development tools and basic software add-on for the system development tool. This functionality
development tools exist, which has been reduced by the enables bidirectional update of representation in the system
proposed approach. The tight linking of the independent development tool and the software development tool. This
system development and OS configuration tools, to a seam- ensures consistency between system development artifacts
less model-based development toolchain interacting via OIL and changes done in the software development tool. The im-
files, further allows the inclusion of additional tools, such as porter also implies an overview of changes between database
scheduling analysis tools, seamlessly into the toolchain. and re-imported OIL file. This offers the possibility of se-
lective database updates and supports impact analysis (as
4.1 UML Modeling Framework Extension part of the change management process). Finally, the im-
The UML profile add-on allows a graphical visualization porter enables reuse of available RTOS configurations, guar-
and processing of OSEK OIL objects. Figure 2 shows a antees consistency of information, and thereby shares infor-
cutout of the profile. This additional information enables mation more precisely and less ambiguously. Figure 4 shows
the mapping of tasks to a specific core and clear arrangement a Screenshot of the import, selective update, and difference
of dependencies and shared resources in terms of multi-core highlighting functionality.
development. Furthermore, the profile offers an intuitive
graphical way of generating OSEK OS configurations and
highlighting functionality for safety-related software tasks 5. APPLICATION OF THE APPROACH
and resources. This enables the possibility of a traceable This section demonstrates the application of the intro-
automatic OIL file configuration generation, which inherits duced approach. The application of this approach inherits
increasing significance in terms of safety-critical system de- a tool change for the configuration of the RTOS, from text
velopment according ISO 26262 and traceability. Note that editor or software development framework to a graphical
other approaches presented in Section 2.2 and discusses dif-
ferent improvement indicators. The labels for categoriza-
tions are:
+ supported or positive effects
- not supported or negative effects
o possible or no effects
In terms of safety-critical development and reuse the pre-
sented approach supports crucial additional features, such as
round-trip engineering by tool-supported information trans-
fer between separated tools and links to supporting safety-
relevant information. Furthermore, the approach eliminates
need of manual generation of OIL files without adequate syn-
Figure 4: Screenshot of the OIL File Importer tax and semantic checking support, ensuring reproducibility,
and traceability argumentation.
Table 1: OIL Objects of the Evaluation Use-Case
6. CONCLUSION
OIL Object Element-count Configurable An important challenge for the development of safety-
Attributes per critical real-time automotive systems is to ensure consis-
Element tency of the safety relevant artifacts (e.g., safety concepts,
CPU 4 2 requirements and configurations) over the development cy-
OS 1 15 cle. This is especially challenging due to the large number
APPMODE 2 1 of skills, tools, teams and institutions involved in the de-
TASKS 6 9 velopment. This work presents an approach to bridge tool
COUNTER 1 5
ALARMS 6 6
gaps between an existing model-driven system and safety en-
gineering framework and RTOS configuration tools, based
on domain standard OSEK. The implemented tool exten-
sion transfers artifacts from system development tools to
representation within the system development tool. Never- software development frameworks for RTOS configuration,
theless, this tool change does not affect the work of the basic thereby creating traceable links across tool boundaries, and
software developer in negative ways, but offers a significant relying on standardized OSEK OIL exchange files. The main
benefit for development of safety-critical software in terms benefits of this enhancement are: improved consistency and
of traceability and replicability of development decisions. traceability from the initial design at the system level down
With the improvements presented in this paper the ex- to the single CPU configuration, as well as a reduction of
tra facility of mapping SW task to dedicated ECU cores error-prone manual work. Further improvements of the ap-
and their required resources enables the possibility to un- proach include the progress in terms of reproducibility and
ambiguously visualize dependencies and analyze scheduling traceability of safety-critical arguments, configurations for
variants at early development phases. Furthermore, safety- software development, and support of multi-core system de-
related software artifacts can be explicitly highlighted and velopment.
dependencies linked in an graphical way.
To provide a comparison of the improvements of our ap- Acknowledgments
proach we selected a simplified multi-core use-case solely
consisting of tasks, alarms, counters, OS, CPU, and appli- The authors would like to acknowledge the financial sup-
cation modes. Other OIL objects have been omitted because port of the ”COMET K2 - Competence Centers for Excellent
of the variable multiplicity of these objects (such as resources Technologies Programme” of the Austrian Federal Ministry
of a task). An overview of OIL objects within our use-case for Transport, Innovation and Technology (BMVIT), the
is given in Table 1. Austrian Federal Ministry of Economy, Family and Youth
This amounts to a total of 20 OIL objects and 46 relations (BMWFJ), the Austrian Research Promotion Agency (FFG),
between the elements. This small example already indicates the Province of Styria, and the Styrian Business Promotion
that relations between the elements increase quickly and be- Agency (SFG).
come confusing. To overcome this issue the model-based Furthermore, we would like to express our thanks to our
development approach offers the possibility to hide specific supporting project partners, AVL List GmbH, Virtual Ve-
relations. hicle Research Center, and Graz University of Technology.
It might be argued that this approach does not reduce
the workload or speed up the generation of OIL files sig-
nificantly, due to the high number of relations that need
to be established. However, the approach provides guid-
ance to minimize configuration failures. Additionally, it
supports round-trip engineering features, which split work-
loads among different development phases and thus simpli-
fies reuse. Table 2 compares the proposed solution with
Table 2: Improvement Indicators
Improvement Indicators Proposed Visual SW Development Manual
Approach DSL Ap- Level Approach
proach Configurators
OIL syntax and semantic checks + + + o
Reuse + + o o
Speed-up o o o o
Distribution of configuration activities + o o -
Automated configuration from available information + + - -
Additional (safety) constraints (such as ASIL indica- + - - o
tor, requirements)
Consistency, correctness, and completeness checks + o o -
Round-trip engineering support and bi-directional + o o o
update features
Traceability of decision making process + + - -
Multi-core systems + o o -
7. REFERENCES [10] Lutz Koester, Thomas Thomsen, and Ralf Stracke.
[1] AUTOSAR development cooperation. AUTOSAR Connecting Simulink to OSEK: Automatic Code
AUTomotive Open System ARchitecture, 2009. Generation for Real-Time Operating Systems with
[2] Manfred Broy, Martin Feilkas, Markus TargetLink. Embedded Intelligence 2001, 2001.
Herrmannsdoerfer, Stefano Merenda, and Daniel [11] Georg Macher, Eric Armengaud, and Christian
Ratiu. Seamless Model-based Development: from Kreiner. Automated Generation of AUTOSAR
Isolated Tool to Integrated Model Engineering Description File for Safety-Critical Software
Environments. IEEE Magazin, 2008. Architectures. In Lecture Notes in Informatics, 2014.
[3] Fabrizio Fabbrini, Mario Fusani, Giuseppe Lami, and [12] Georg Macher, Eric Armengaud, and Christian
Edoardo Sivera. Software Engineering in the European Kreiner. Bridging Automotive Systems, Safety and
Automotive Industry: Achievements and Challenges. Software Engineering by a Seamless Tool Chain. In
In COMPSAC, pages 1039–1044. IEEE Computer 7th European Congress Embedded Real Time Software
Society, 2008. and Systems Proceedings, pages 256 –263, 2014.
[4] Holger Giese, Stephan Hildebrandt, and Stefan [13] Roland Mader. Computer-Aided Model-Based Safety
Neumann. Model Synchronization at Work: Keeping Engineering of Automotive Systems. PhD thesis, Graz
SysML and AUTOSAR Models Consistent. LNCS University of Technology, 2012.
5765, pages pp. 555 –579, 2010. [14] OSEK/VDX Steering Committee. OSEK/VDX
[5] Zonghua Gu, Shige Wang, and Kang Shin. Issues in System Generation OIL: OSEK Implementation
Mapping from UML Real-Time Profile to OSEK. In Language.
Proc SVERTS: Workshop on Specification and http://portal.osek-vdx.org/files/pdf/specs/oil25.pdf,
Validation of UML models for Real Time and 2004.
Embedded Systems, Workshop at UML 2003, October, [15] Imran Rafiq Quadri and Andrey Sadovykh. MADES:
page 7, 2003. A SysML/MARTE high level methodology for
[6] Joerg Holtmann, Jan Meyer, and Matthias Meyer. A real-time and embedded systems, 2011.
Seamless Model-Based Development Process for [16] Guoqing Yang, Minde Zhao, Lei Wang, and Zhaohui
Automotive Systems, 2011. Wu. Model-based Design and Verification of
[7] ISO - International Organization for Standardization. Automotive Electronics Compliant with OSEK/VDX.
ISO 17356 Road vehicles – Open interface for In Proceedings of the Second International Conference
embedded automotive applications, 2005. on Embedded Software and Systems, ICESS ’05, pages
[8] ISO - International Organization for Standardization. 237–245, Washington, DC, USA, 2005. IEEE
ISO 26262 Road vehicles Functional Safety Part 1-10, Computer Society.
2011. [17] Mingde Zhao, Zhaohui Wu, Guoqing Yang, Lei Wang
[9] JaeYoung Kim, JungWook Lee, Jeongho Son, 0023, and Wei Chen 0005. SmartOSEK: A Real-Time
Kee-Koo Kwon, and Gwangsu Kim. Lightweight Operating System for Automotive Electronics. In
AUTOSAR Software Platform for Automotive. In Zhaohui Wu, Chun Chen, Minyi Guo, and Jiajun Bu,
IEEE International Conference on Consumer editors, ICESS, volume 3605 of Lecture Notes in
Electronics, pages 307 – 308, 2012. Computer Science, pages 437–442. Springer, 2004.