Automotive Real-time Operating Systems: A Model-Based ...

1 Automotive Real-time Operating Systems: A model -BasedConfiguration ApproachGeorg MacherInstitute for TechnicalInformaticsGraz University of TechnologyAVL List GmbHGraz, AtasInstitute for TechnicalInformaticsGraz University of TechnologyAVL List GmbHGraz, ArmengaudAVL List GmbHHans-List-Platz 1 Graz, KreinerInstitute for TechnicalInformaticsGraz University of TechnologyGraz, 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 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.

2 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 and Subject [ Operating Systems]: Organization and Design; [Software Engineering]: Coding Tools and TechniquesGeneral TermsModel- based development, traceability, embedded operatingsystems, OSEK OIL, ISO 26262, 14, November 2014, Lisbon, retained by the 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.

3 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 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.

4 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 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 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 operatingFigure 1: Comparison OIL File Normal View vs.

5 Graphical Representation with Eclipsesystems 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 ( , 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 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.

6 Finally, this workis concluded in Section 6 with an overview of the OSEK/VDX RTOS OVERVIEWThe German OSEK consortium (German abbreviation foropen 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 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.

7 These files can be generatedmanually or via configuration tools. OIL files include allobject containers and information required to configure theRTOS of one specific 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 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.

8 An example of safety-related configurationparameters contained in the OIL file are shared task re-sources or task OSEK Related Tools and PublicationsTo our knowledge most development frameworks do notinclude 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 ( , Vector OIL Configurator or GOB - GUI based OILB uilder).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.

9 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 ofprior available information is very s 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 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 et al. [9] suggest a lightweight AUTOSAR softwareplatform and additional extensions of OSEK OIL files.

10 Thepresented approach focuses on adding extensions to OILfiles, rather than supporting automated generation of 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 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 Model-Based DEVELOPMENT ANDINTEGRATED TOOLCHAINSThis 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 .