Automotive Real-time Operating Systems: A Model-BasedConfiguration Approach

Georg MacherInstitute for Technical

InformaticsGraz University of Technology

AVL List GmbHGraz, AUSTRIA

georg.macher@tugraz.at

Muesluem AtasInstitute for Technical

InformaticsGraz University of Technology

AVL List GmbHGraz, AUSTRIA

muesluem.atas@avl.com

Eric ArmengaudAVL List GmbHHans-List-Platz 1Graz, Austria

eric.armengaud@avl.com

Christian KreinerInstitute for Technical

InformaticsGraz University of Technology

Graz, Austriachristian.kreiner@tugraz.at

ABSTRACTAutomotive embedded systems have become very complex,are strongly integrated, and the safety-criticality and real-time constraints of these systems raise new challenges. Dis-tributed system development, short time-to-market inter-vals, and automotive safety standards (such as ISO 26262[8]) require efficient and consistent product development alongthe entire development lifecycle. The automotive OSEK/VDX standard provides an architecture for distributed real-time units in vehicles and a language aiming in specify-ing the configuration of real-time OSEK operating systems.The aim of this paper is to enhance a model-driven system-engineering framework with the capability of generating OSconfigurations from existing high level control system infor-mation. Furthermore, to enable the possibility to updatestored information from OSEK Implementation Language(OIL) files and support round-trip engineering of real-timeoperating system (RTOS) configurations. This enables theseamless description of automotive RTOS, from system levelrequirements to software implementation and therefore en-sures consistency and correctness of the configuration. Tothat aim, a bidirectional tool bridge is proposed based onOSEK OIL exchange format files.

Categories and Subject DescriptorsD.4.7 [Operating Systems]: Organization and Design; D.2.3[Software Engineering]: Coding Tools and Techniques

General TermsModel-based development, traceability, embedded operatingsystems, OSEK OIL, ISO 26262, RTOS.

EWiLi14, November 2014, Lisbon, Portugal.Copyright retained by the authors.

1. INTRODUCTIONThe number of embedded systems in the automotive do-

main has grown significantly in recent years. This trendis also strongly supported by the ongoing replacement oftraditional mechanical systems with modern embedded sys-tems. This enables the deployment of more advanced con-trol strategies, thus providing added values for the customerand more environment friendly vehicles. At the same time,the higher degree of integration and the safety-criticality ofthe control application raises new challenges. Evidence ofcorrectness of the different applications, both in the timedomain and value domain, possibly running on the samecomputing platform, has to be guaranteed. In parallel, newcomputing architectures with services integrated in hard-ware require new software architectures and safety concepts.

Safety standards such as ISO 26262 [8] for road vehicleshave been established to provide guidance during the de-velopment of safety-critical systems. These standards relyon risk identification and mitigation strategies. They targetearly hazard identification as well as solid counter measurespecification, implementation and validation along the entireproduct life cycle. One challenge in this context is to pro-vide evidence of consistency, correctness, and completenessof system specifications over different work-products alongthe entire product development process. This is a requiredbasis for the development of dependable systems. More-over, the consolidation of the system specification enablesearly bug finding and thus support reducing the costs forbug fixes and late re-design.

To handle these issues, model-based development sup-ports the description of the system under development ina more structured way, enables different views for differ-ent stakeholders, different levels of abstraction, and centralsource of information.

The contribution of this paper is to bridge the existing gapbetween model-driven system engineering tools and softwareengineering tools for automotive real-time operating systems(RTOS). More especially, the approach makes use of exist-ing high level control system information in SysML format togenerate 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 Languagefile format (OIL files) [14]. Information from the controlsystem (such as control strategies) can thus be mapped toa configuration at software level (e.g., required interfaces toother SW components, allocation to a CPU respectively toa task). The goal is to support a consistent and traceable re-finement, as required by ISO 26262 standard, from the earlyconcept phase to individual configurations of the RTOS.

The document is organized as follows: Section 2 presentsan introduction to OSEK/VDX and OSEK OIL. Then, model-based development and integrated tool chains, as well asthe base tool-chain for this approach are presented in Sec-tion 3. In Section 4 a description of the proposed approachfor the generation of RTOS configuration files according toOIL standard is provided. An application and evaluation ofthe approach is presented in Section 5. Finally, this workis concluded in Section 6 with an overview of the presentedapproach.

2. OSEK/VDX RTOS OVERVIEWThe German OSEK consortium (German abbreviation for

open systems and their interfaces for electronics in motorvehicles) was founded in 1993 by several German automotivecompanies. VDX (Vehicle Distributed eXecutive) was theFrench pendant from the French car manufacturers side,which regrouped the OSEK/VDX consortium in 1994.

OSEK/VDX is an open standard for specifications for em-bedded real-time operating systems (RTOS), designed toprovide a standard software architecture for the various elec-tronic control units (ECUs), and partially standardized inISO 17356 [7].The work of the OSEK/VDX consortium is today contin-ued by the AUTOSAR consortium [1], which is based onOSEK/VDX specifications. To describe the configuration ofan OSEK RTOS the OSEK implementation language files(OIL) is intended to be used. These files can be generatedmanually or via configuration tools. OIL files include allobject containers and information required to configure theRTOS of one specific ECU.

2.1 OSEK Implementation LanguageAs mentioned previously, the OIL files inherit a normal-

ized description language for OS configuration and relatedobjects. OIL files are commonly used in the automotivedomain to configure the real-time operating systems of indi-vidual ECUs. This is frequently done manually, due to thesimple human readable structure of OIL files and the lack oftools supporting an automated information exchange. OILfiles typically consist of implementation specific definitions,which are closely related to the hardware (ECU) in use andspecify the OIL object with all their possible attribute prop-erties.

Due to the introduction of multi-core real-time systemsand the awareness of safety-criticality of such systems, toolsupport and automation of OIL generation becomes increas-ingly relevant. An example of safety-related configurationparameters contained in the OIL file are shared task re-sources or task priorities.

2.2 OSEK Related Tools and PublicationsTo our knowledge most development frameworks do not

include a tool for automatic OIL file generation from priorinformation of previous development stages at a higher ab-straction level. Nevertheless, within this work tool infor-mation for commercial tools has been omitted due to non-exhaustiveness of such an overview and the fact that thisinformation can be found up-to-date on the respective web-site (e.g., Vector OIL Configurator or GOB - GUI based OILBuilder).

Most frameworks either require manual generation of OILfiles by the developer, or they provide a dedicated graphicaluser interface for support and guidance while generating theOIL file. Figure 1 shows a comparison of the same OIL filein typical editor view and in a guided graphical representa-tion within an Eclipse-based development framework. Manyavailable OIL file configurators provide such a representationof the OIL information. They thus provide guidance to min-imize configuration failures, but do not reduce workload orspeed up the generation of OIL files. Also the import of

prior available information is very limited.SmartOSEKs visual designer [17] makes use of a DSL (do-

main specific language) approach. The visual designing toolenables modeling of applications in a graphical way and au-tomatic generation of OIL files. The main drawback of thisapproach is the missing availability to feedback informationinto the model.

Most OIL configurators focus on generating OIL files atsoftware development level, such as in the work of Koesteret al. [10]. The main disadvantage here is that prior infor-mation of previous development phases cannot be used fortiming analysis or have to be transferred manually.

Kim et al. [9] suggest a lightweight AUTOSAR softwareplatform and additional extensions of OSEK OIL files. Thepresented approach focuses on adding extensions to OILfiles, rather than supporting automated generation of OILfiles.

The work of Yang et al. [16] presents a conversion of UMLmodels into OSEK/VDX models for simulation and opti-mization of the system design. The authors claim that byconverting UML representations into OSEK/VDX modelsproductivity can be improved, correctness of developmentartifacts can be ensured more easily, and documentation canbe provided with less effort and better quality.

Gu et al. [5] focus on the description of automated mecha-nisms for generating application codes and seamless integra-tion of models for software development, but do not providemethods of the transformation of UML and OSEK artifacts.

3. MODEL-BASED DEVELOPMENT ANDINTEGRATED TOOLCHAINS

This section provides a brief overview of model-based de-velopment (MBD) tools and related works, as well as thebasic MBD framework of the presented approach. Againa tool overview of commercial tools has been omitted dueto non-exhaustiveness and easy up-to-date online access ofsuch information on the respective website (e.g., EnterpriseArchitect, Artisan Studio, EB studio, PREEvision).

3.1 Model-Based Development Tools and Pub-lications

Fabbrini et al. [3] provide an overview of software en-gineering in the European automotive industry and presenttools, techniques and countermeasures to prevent faults. Thiswork highlights the importance of tool integration and model-based development approaches.

Broy et al. [2] mention model-based development as thebest approach to manage the large amount of informationand complexity of modern embedded systems. The authorsalso illustrate why seamless solutions have not been achievedso far, mention commonly used solutions, and problems thatarise by using an inadequate toolchain (e.g. redundancy,inconsistency and lack of automation). This work presentsbasic ideas and concepts of MBD, but not detailed solutions.

The work of Holtmann et al. [6] also highlights process andtooling gaps between different development process steps.A model-based development process is presented which con-forms with the process reference model of Automotive SPICE.With this use-case the authors highlight the lack of automa-tion for artifact traceability and missing guidelines for modelselection at varying abstraction levels. The work exposestwo important gaps: First, missing links between system

level tools and software development tools. Second, incon-sistency and redundant information, due to various very spe-cific tools and a lack of automated information transfer.

Giese et al. [4] also highlight the step from system designto software design as critical. System design models have tobe correctly transferred to the software engineering model,and later changes must be kept consistent.

The work of Quadri and Sadovykh [15] presents approachesfor novel model-driven techniques and new tools supportingdesign, validation, and simulation. The authors highlightthe possibility of high level model analysis for schedulabilityand use a subset of UML and SysML for their approach.However, configuration of real-time operating systems ac-counting for timed resource constraints is not addressed inthis work.

3.2 Basic FrameworkA brief overview of the model-based development toolchain

in use and the related preliminary work for the toolchain ofthe proposed approach is given in this section. The proto-type of our toolchain, proposed by Mader [13], is a spe-cific implementation of a tool-independent and language-independent methodology to support continuous safety anal-yses of system architecture development according to ISO26262 [8].

The basic concept behind this framework is to have a con-sistent information repository as central source of informa-tion. The toolchain allows different engineering domains towork on one model which provides traces between differentartifact types, and ensures timeliness of data. Extension forthe modeling tool (Enterprise Architect r) ensure seamlessand consistent transition of information between the reposi-tory and various adequate special-purpose tools (such as OSconfigurators). This approach also inherits an organizationalswitch from document-centric development approaches to aseamless model-based development approach. For a moredetailed overview of the concept and toolchain as a wholesee [12].

4. OVERVIEW OF THE CONTRIBUTIONThe contribution proposed in this paper is an extension of

the previously mentioned framework towards RTOS config-uration. The contribution (see also highlighting in Figure 3)comprises the following aspects:

UML modeling framework extension: Enhancement ofthe software UML profile for visualization and process-ing of OSEK OIL files. To enable configuration of theOSEK OS by prior available constraints.

OIL file generator : An extractor which automaticallygenerates OIL files from existing information at sys-tem development level. This ensures consistency ofthe specification and implementation for the RTOS.

OIL file importer : The importer supports round-tripengineering by re-importation of information updatesfrom OIL files.

This proposed extension is a constituent of the proposedtoolchain in [12] to close the gap between system-level de-velopment at abstract UML-like representations and RTOSconfiguration at software-level. This bridging extends thework presented in [11] on basic software level, guarantees

Figure 2: UML Profile Addons for OIL Objects

BASIC SOFTWARE

SYSTEM DEVELOPMENT SOFTWARE DEVELOPMENT

OS ConfiguratorOS.oil

OS.c

System Requirements

Safety Requirements

HW ArchitectureSW Architecture

System Architecture

BRIDGING APPROACH

SYSTEM MODELING TOOL

BSW.cBSW

Configurator

Figure 3: Representation of the Bridging Approachto Ensure Boundless Information Exchange

consistency of information due to the single source of infor-mation principle, and shares information more precisely andaccurately. The approach minimizes redundant manual in-formation exchange between tools and also takes IS0 26262requirements (especially traceability) and constraints intoaccount.Figure 3 shows the conceptual overview of the tool-chainand highlights the OS configuration part. As can be seenfrom the figure, a lack of tool support for information trans-fer between system development tools and basic softwaredevelopment tools exist, which has been reduced by theproposed approach. The tight linking of the independentsystem development and OS configuration tools, to a seam-less model-based development toolchain interacting via OILfiles, further allows the inclusion of additional tools, such asscheduling analysis tools, seamlessly into the toolchain.

4.1 UML Modeling Framework ExtensionThe UML profile add-on allows a graphical visualization

and processing of OSEK OIL objects. Figure 2 shows acutout of the profile. This additional information enablesthe mapping of tasks to a specific core and clear arrangementof dependencies and shared resources in terms of multi-coredevelopment. Furthermore, the profile offers an intuitivegraphical way of generating OSEK OS configurations andhighlighting functionality for safety-related software tasksand resources. This enables the possibility of a traceableautomatic OIL file configuration generation, which inheritsincreasing significance in terms of safety-critical system de-velopment according ISO 26262 and traceability. Note that

this profile has been integrated in the existing framework de-scribed in Section 3.2. Consequently, the system descriptioncan be refined down to the operating system, thus improv-ing architecture consistency over skills boundaries (such assystems and software engineering).

4.2 OIL File GeneratorThe second part of the approach is an exporter capable of

exporting the RTOS configuration available from the SysMLmodel to an OIL file. The exporter generates OIL files en-riched with the available system and safety development ar-tifact traces (such as required ASIL of task implementation).Most state-of-the-art software development frameworks areable to configure the RTOS according to the specificationswithin such an OIL file. Consequently the use of this ex-porter additionally improves communication of the (safety)context to the software experts into their native developmenttools, thus improving the consistency of the product develop-ment. Furthermore, the toolchain is capable of multi-core ormulti-system development, therefore the generation of OILfile is selectable for individual cores.

4.3 OIL File ImporterThe third part of the approach is the import functionality

add-on for the system development tool. This functionalityenables bidirectional update of representation in the systemdevelopment tool and the software development tool. Thisensures consistency between system development artifactsand changes done in the software development tool. The im-porter also implies an overview of changes between databaseand re-imported OIL file. This offers the possibility of se-lective database updates and supports impact analysis (aspart of the change management process). Finally, the im-porter enables reuse of available RTOS configurations, guar-antees consistency of information, and thereby shares infor-mation more precisely and less ambiguously. Figure 4 showsa Screenshot of the import, selective update, and differencehighlighting functionality.

5. APPLICATION OF THE APPROACHThis section demonstrates the application of the intro-

duced approach. The application of this approach inheritsa tool change for the configuration of the RTOS, from texteditor or software development framework to a graphical

Figure 4: Screenshot of the OIL File Importer

Table 1: OIL Objects of the Evaluation Use-Case

OIL Object Element-count ConfigurableAttributes perElement

CPU 4 2OS 1 15APPMODE 2 1TASKS 6 9COUNTER 1 5ALARMS 6 6

representation within the system development tool. Never-theless, this tool change does not affect the work of the basicsoftware developer in negative ways, but offers a significantbenefit for development of safety-critical software in termsof traceability and replicability of development decisions.

With the improvements presented in this paper the ex-tra facility of mapping SW task to dedicated ECU coresand their required resources enables the possibility to un-ambiguously visualize dependencies and analyze schedulingvariants at early development phases. Furthermore, safety-related software artifacts can be explicitly highlighted anddependencies linked in an graphical way.

To provide a comparison of the improvements of our ap-proach we selected a simplified multi-core use-case solelyconsisting of tasks, alarms, counters, OS, CPU, and appli-cation modes. Other OIL objects have been omitted becauseof the variable multiplicity of these objects (such as resourcesof a task). An overview of OIL objects within our use-caseis given in Table 1.

This amounts to a total of 20 OIL objects and 46 relationsbetween the elements. This small example already indicatesthat relations between the elements increase quickly and be-come confusing. To overcome this issue the model-baseddevelopment approach offers the possibility to hide specificrelations.

It might be argued that this approach does not reducethe workload or speed up the generation of OIL files sig-nificantly, due to the high number of relations that needto be established. However, the approach provides guid-ance to minimize configuration failures. Additionally, itsupports round-trip engineering features, which split work-loads among different development phases and thus simpli-fies reuse. Table 2 compares the proposed solution with

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 effectso possible or no effects

In terms of safety-critical development and reuse the pre-sented approach supports crucial additional features, such asround-trip engineering by tool-supported information trans-fer between separated tools and links to supporting safety-relevant information. Furthermore, the approach eliminatesneed of manual generation of OIL files without adequate syn-tax and semantic checking support, ensuring reproducibility,and traceability argumentation.

6. CONCLUSIONAn important challenge for the development of safety-

critical real-time automotive systems is to ensure consis-tency of the safety relevant artifacts (e.g., safety concepts,requirements and configurations) over the development cy-cle. This is especially challenging due to the large numberof skills, tools, teams and institutions involved in the de-velopment. This work presents an approach to bridge toolgaps between an existing model-driven system and safety en-gineering framework and RTOS configuration tools, basedon domain standard OSEK. The implemented tool exten-sion transfers artifacts from system development tools tosoftware development frameworks for RTOS configuration,thereby creating traceable links across tool boundaries, andrelying on standardized OSEK OIL exchange files. The mainbenefits of this enhancement are: improved consistency andtraceability from the initial design at the system level downto the single CPU configuration, as well as a reduction oferror-prone manual work. Further improvements of the ap-proach include the progress in terms of reproducibility andtraceability of safety-critical arguments, configurations forsoftware development, and support of multi-core system de-velopment.

AcknowledgmentsThe authors would like to acknowledge the financial sup-port of the COMET K2 - Competence Centers for ExcellentTechnologies Programme of the Austrian Federal Ministryfor Transport, Innovation and Technology (BMVIT), theAustrian Federal Ministry of Economy, Family and Youth(BMWFJ), the Austrian Research Promotion Agency (FFG),the Province of Styria, and the Styrian Business PromotionAgency (SFG).

Furthermore, we would like to express our thanks to oursupporting project partners, AVL List GmbH, Virtual Ve-hicle Research Center, and Graz University of Technology.

Table 2: Improvement Indicators

Improvement Indicators ProposedApproach

VisualDSL Ap-proach

SW DevelopmentLevelConfigurators

ManualApproach

OIL syntax and semantic checks + + + oReuse + + o oSpeed-up o o o oDistribution of configuration activities + o o -Automated configuration from available information + + - -Additional (safety) constraints (such as ASIL indica-tor, requirements)

+ - - o

Consistency, correctness, and completeness checks + o o -Round-trip engineering support and bi-directionalupdate features

+ o o o

Traceability of decision making process + + - -Multi-core systems + o o -

7. REFERENCES[1] AUTOSAR development cooperation. AUTOSAR

AUTomotive Open System ARchitecture, 2009.

[2] Manfred Broy, Martin Feilkas, MarkusHerrmannsdoerfer, Stefano Merenda, and DanielRatiu. Seamless Model-based Development: fromIsolated Tool to Integrated Model EngineeringEnvironments. IEEE Magazin, 2008.

[3] Fabrizio Fabbrini, Mario Fusani, Giuseppe Lami, andEdoardo Sivera. Software Engineering in the EuropeanAutomotive Industry: Achievements and Challenges.In COMPSAC, pages 10391044. IEEE ComputerSociety, 2008.

[4] Holger Giese, Stephan Hildebrandt, and StefanNeumann. Model Synchronization at Work: KeepingSysML and AUTOSAR Models Consistent. LNCS5765, pages pp. 555 579, 2010.

[5] Zonghua Gu, Shige Wang, and Kang Shin. Issues inMapping from UML Real-Time Profile to OSEK. InProc SVERTS: Workshop on Specification andValidation of UML models for Real Time andEmbedded Systems, Workshop at UML 2003, October,page 7, 2003.

[6] Joerg Holtmann, Jan Meyer, and Matthias Meyer. ASeamless Model-Based Development Process forAutomotive Systems, 2011.

[7] ISO - International Organization for Standardization.ISO 17356 Road vehicles Open interface forembedded automotive applications, 2005.

[8] ISO - International Organization for Standardization.ISO 26262 Road vehicles Functional Safety Part 1-10,2011.

[9] JaeYoung Kim, JungWook Lee, Jeongho Son,Kee-Koo Kwon, and Gwangsu Kim. LightweightAUTOSAR Software Platform for Automotive. InIEEE International Conference on ConsumerElectronics, pages 307 308, 2012.

[10] Lutz Koester, Thomas Thomsen, and Ralf Stracke.Connecting Simulink to OSEK: Automatic CodeGeneration for Real-Time Operating Systems withTargetLink. Embedded Intelligence 2001, 2001.

[11] Georg Macher, Eric Armengaud, and Christian

Kreiner. Automated Generation of AUTOSARDescription File for Safety-Critical SoftwareArchitectures. In Lecture Notes in Informatics, 2014.

[12] Georg Macher, Eric Armengaud, and ChristianKreiner. Bridging Automotive Systems, Safety andSoftware Engineering by a Seamless Tool Chain. In7th European Congress Embedded Real Time Softwareand Systems Proceedings, pages 256 263, 2014.

[13] Roland Mader. Computer-Aided Model-Based SafetyEngineering of Automotive Systems. PhD thesis, GrazUniversity of Technology, 2012.

[14] OSEK/VDX Steering Committee. OSEK/VDXSystem Generation OIL: OSEK ImplementationLanguage.http://portal.osek-vdx.org/files/pdf/specs/oil25.pdf,2004.

[15] Imran Rafiq Quadri and Andrey Sadovykh. MADES:A SysML/MARTE high level methodology forreal-time and embedded systems, 2011.

[16] Guoqing Yang, Minde Zhao, Lei Wang, and ZhaohuiWu. Model-based Design and Verification ofAutomotive Electronics Compliant with OSEK/VDX.In Proceedings of the Second International Conferenceon Embedded Software and Systems, ICESS 05, pages237245, Washington, DC, USA, 2005. IEEEComputer Society.

[17] Mingde Zhao, Zhaohui Wu, Guoqing Yang, Lei Wang0023, and Wei Chen 0005. SmartOSEK: A Real-TimeOperating System for Automotive Electronics. InZhaohui Wu, Chun Chen, Minyi Guo, and Jiajun Bu,editors, ICESS, volume 3605 of Lecture Notes inComputer Science, pages 437442. Springer, 2004.