Research on interoperability within development processes of Embedded Systems on an example E-Book

Ferdinand Schäfer

• Herausgeber: GRIN Verlag
• Sprache: Englisch

Veröffentlichungsjahr: 2015

Beschreibung

Master's Thesis from the year 2014 in the subject Engineering - Mechanical Engineering, grade: 1.0, University of Applied Sciences Karlsruhe (Fakultät für Maschinenbau und Mechatronik), language: English, abstract: This master thesis investigates the standard AUTOSAR („AUTomotive Open System ARchitecture“) within the ARTEMIS Joint Undertaking project CRYSTAL (“CRitical sYSTem engineering AcceLeration”), which is concerned with the development of interoperability-technology for System Engineering Environments. This work identifies a conflict between the application of the development-scheme “AUTOSAR-Methodology” and the superior industrial trend of Model-based Software Engineering. Founded on specialized literature, the mentioned problem can be titled as “Frontloading”. This methodological issue is such a fundamental aspect for the utilization of AUTOSAR that the present elaboration concentrates on it and refrains from interoperability-technology as focused by the paramount project. In the light of the motivation indicated in the acronym of CRYSTAL, clarifying this methodological aspect constitutes a fundamental contribution to efficiency in the engineering of Embedded Systems. This master thesis elucidates in detail the phenomenon “Frontloading” and its symptoms in software-development with AUTOSAR. The elaboration is based on a rich automotive function-example, which is developed in accordance with the established paradigm of Model-based Software Engineering. Although AUTOSAR adheres to the latter, its application demands own specific procedures to produce automotive functions. This work finally delivers a concept for the efficient handling of AUTOSAR within Model-based Software Engineering with respect to Frontloading, associating requirements to corresponding development-artefacts.

Leseprobe

Impressum:

Copyright (c) 2015 GRIN Verlag / Open Publishing GmbH, alle Inhalte urheberrechtlich geschützt. Kopieren und verbreiten nur mit Genehmigung des Verlags.

Bei GRIN macht sich Ihr Wissen bezahlt! Wir veröffentlichen kostenlos Ihre Haus-, Bachelor- und Masterarbeiten.

Jetzt beiwww.grin.com

Abstract

This master thesis investigates the standard AUTOSAR („AUTomotive Open System ARchitecture“) within the ARTEMIS Joint Undertaking project CRYSTAL (“CRitical sYSTem engineering AcceLeration”), which is concerned with the development of interoperability-technology for System Engineering Environments. This work identifies a conflict between the application of the development-scheme “AUTOSAR-Methodology” and the superior industrial trend of Model-based Software Engineering. Founded on specialized literature, the mentioned problem can be titled as “Frontloading”. This methodological issue is such a fundamental aspect for the utilization of AUTOSAR that the present elaboration concentrates on it and refrains from interoperability-technology as focused by the paramount project. In the light of the motivation indicated in the acronym of CRYSTAL, clarifying this methodological aspect constitutes a fundamental contribution to efficiency in the engineering of Embedded Systems. This master thesis elucidates in detail the phenomenon “Frontloading” and its symptoms in software-development with AUTOSAR. The elaboration is based on a rich automotive function-example, which is developed in accordance with the established paradigm of Model-based Software Engineering. Although AUTOSAR adheres to the latter, its application demands own specific procedures to produce automotive functions. This work finally delivers a concept for the efficient handling of AUTOSAR within Model-based Software Engineering with respect to Frontloading, associating requirements to corresponding development-artefacts.

Keywords

Acknowledgement

I have written this master thesis during my internship with ITK Engineering AG in the third semester of my mechatronic-studies at the University of Applied Sciences of Karlsruhe. The thesis investigates the standard AUTOSAR in scope of the European research-project CRYSTAL directed by ARTEMIS Joint Undertaking. I have completed this work in the period from April to September 2014 at ITK Engineering AG´s headquarter in Rülzheim.

I primarily want to thank Aleksander Lodwich, M. Sc., for the supervision of this thesis and his advices along the complete elaboration. This thank is equally addressed to Dipl.-Ing. (FH) Stefan Holzinger for the coordination of this activity within the CRYSTAL-project. I further would like to express thanks to ITK Engineering AG for the excellent atmosphere and the material available for this thesis. This thank further concerns the employees who intensely supported me with directive advices: Dipl.-Ing.(FH) Markus Wawersich, Dipl.-Ing. Abdul Rahman Fadloun, Dipl.-Inform.Kai Richter and Michael Massa, M. Sc.

I further would like to pronounce special thanks to the coordinator of this work at the University of Applied Sciences of Karlsruhe, Prof. Dr. Ottmar Beucher.

Finally, I express special gratitude to my family, especially to my companion and my parents, for their constant support during my overall studies.

Table of contents

Abstract

Keywords

Acknowledgement

1 Introduction

2 Presentation of CRYSTAL

2.1 Origin of the project

2.2 Mission of CRYSTAL

2.3 Overview of project-contents

2.4 Contributions of earlier projects to CRYSTAL

2.5 The CRYSTAL-consortium

2.6 Project-structure

2.7 Location of this master thesis within CRYSTAL

2.8 Relevance of interoperability to automotive system engineering

3 Understanding interoperability

3.1 Definitions for interoperability

3.2 Example in business-process

3.3 Interoperability in process-management

3.4 Analogy for interoperability

4 Introducing AUTOSAR

4.1 Presentation of AUTOSAR

4.2 Motivation for AUTOSAR

4.3 Insight into development of automotive functions

4.4 AUTOSAR-Methodology

4.5 Specifying application-software with the Virtual Functional Bus

4.6 The activity “Develop Application Software”

5 Frontloading as a cause for inefficiency in engineering with AUTOSAR

5.1 Model-based Software Engineering in the V-Model

5.2 AUTOSAR within Model-based Software Engineering

5.3 The price for easing software-integration: Frontloading

5.4 Round-Trip-Engineering with Software Components

5.5 Frontloading: An interoperability-problem?

5.6 Summarizing Frontloading

6 Clarifying Frontloading with AUTOSAR in Model-based Software Engineering

6.1 Setup for observation

6.2 Presentation of the exemplary embedded function for this master thesis

6.2.1 UML use case diagram

6.2.2 User-requirements

6.3 Description of Frontloading within AUTOSAR

6.3.1 Signification of the Basis-Software

6.3.2 Meaning of architecture in an AUTOSAR-development

6.3.3 Architecture and non-functional requirements in AUTOSAR

6.3.4 Summarizing Frontloading

6.4 Fundament of Model-based Software Engineering

6.4.1 Model-based Software Engineering with the executable specification

6.4.2 Comparison of architecture in the executable specification and the Virtual Functional Bus

6.4.3 Decomposition as fundament for Model-based Software Engineering

7 Development of AUTOSAR Software Components for the spoiler-functionality

7.1 Systematic procedure with the spoiler-functionality

7.2 Approaching Virtual Functional Bus architecture with the executable specification

7.2.1 The Virtual Functional Bus as component-architecture

7.2.2 Handling different kinds of Software Components at the Virtual Functional Bus

7.2.3 Decomposition of the spoiler-functionality with operational requirements

7.2.4 Pushing the decomposition of the spoiler-functionality from the logical perspective

7.2.5 Summary of the actual state of decomposition

7.2.6 Comparison of the present development-status with the specification of the VFB

7.3 Mapping of Software Components to Electronic Control Units

7.3.1 Status of the Internal Behavior in the Software Component Description

7.3.2 Mapping of Software Components to Electronic Control Units

7.4 Developing Internal Behavior of Software Component Descriptions

7.4.1 Transition from architecture to design

7.4.2 First steps for the modelling of Software Component Descriptions

7.4.3 Aspects to be specified in the Internal Behavior

7.4.4 Specifying the Internal Behavior of the Software Components on the Ecu-Spoiler

7.4.5 Relations to Operating Systems and communication-stacks

7.4.6 Model-based implementation of Software-Components

7.4.7 Summary of the specification of the Internal Behavior

7.5 Involving System Services for the Application-SWC-Main-Functionality

8 Concept for efficient development of application-software with AUTOSAR

8.1 Context of the elaborated concept

8.2 The challenge of Frontloading

8.3 Summarizing the development of the spoiler-functionality

8.4 Possible reasons for iterations in the development

8.5 Concept for efficient development of AUTOSAR application-software

List of abbreviations

Table of figures

Tables

Bibliography

Appendix

A. Classification of requirements

B. Non-functional operational requirements for the spoiler-functionality

C. Model-based documentation of the spoiler-functionality with a state-chart

D. System-requirements for the spoiler-functionality for detailing of Table 1 and development of a state-chart

E. 2nd decomposition of the spoiler-functionality from a logical perspective

F. Overview for Software Component Description for modelling of the spoiler-functionality in this thesis

G. Summary of relevant AUTOSAR-contents

H. Non-functional development requirements for the spoiler-functionality

I. Mapping of Software Components to Electronic Control Units

J. Response-times for the spoiler-functionality

K. Communication-matrix

L. Clarification of signals in addition to the communication-matrix

M. Specification of the Internal Behavior of Software Components on the Ecu-Spoiler

N. Rates of execution for the Runnables on Ecu-Spoiler

O. Information for the usage of MATLAB in this thesis

P. Exemplary requirements for the usage of System Services in the spoiler-functionality

1 Introduction

The present document investigates the automotive software-standard AUTOSAR in scope of the European research-project CRYSTAL, directed by ARTEMIS. More exactly, this work is completed within Work Package 6.5 of CRYSTAL, in which ITK Engineering AG participates. An exemplary automotive function has been set up for this elaboration. This represents the base for the present thesis, whose primary aim is to enhance efficiency in development processes with AUTOSAR.

AUTOSAR is continuously gaining importance for the handling of complexity in the development ofautomotive Embedded Systems and even beyond. Efficiency in the application of the standard thus represents a crucial need for every actor in this industrial sector. In this way, the present master thesis directly contributes to the know-how of ITK Engineering AG, whose implication into AUTOSAR-related projects is steadily increasing.

Economic reflections lead to the need for sustained interoperability in business-processes. This necessity is accentuated by the fact, that these processes imply ever more specialized know-how and are distributed among different parties. CRYSTAL is concerned with the development of interoperability-technology for System Engineering Environments to satisfy this demand within the European market of Embedded Systems.

Although the present consideration of AUTOSAR in the context of the CRYSTAL-project also proves the demand for interoperability in the engineering-process, another fundamental aspect is clarified: the development of application-software with AUTOSAR relies on the standard-format ARXML and thus an interoperability-technology is already used. The industrial application of AUTOSAR for the development of application-software shows an abusive use of this technology. Instead of directing attention to an interoperability-solution for this use case according to CRYSTAL, the present work choses to consider the development of application-software with AUTOSAR based on the ARXML, with to goal to identify reasons for inefficiency.

In fact, the engineering of AUTOSAR-software in practice is linked to the so-called Frontloading, which can basically be understood as an architecture-paradigm requiring densified knowledge in early development-phases and which mainly results from the premise of AUTOSAR to improve the integration of software. Frontloading in particular can be illustrated from an economic side withFigure 1, which symbolically compares the development-time for a project with and without AUTOSAR. The development time is divided in single phases for the illustration.

Figure 1: Clarification of Frontloading and iterations due to Round-Trip Engineering in development processes with AUTOSAR (clarification in subchapter 5.5)

The upper part of the figure therefore first of all shows a development without AUTOSAR. The important aspect to underline there is that in addition to the main development-phase, a supplementary phase has to be taken into account. This phase is known to cause high efforts to overcome the integration-problems in a development, where no contract has been fixed for the interfaces of the software. Such a phase for the integration can significantly lengthen the development-time.

A basic property of the development with AUTOSAR is shown in the middle-line of the figure with a phase preceding the main development. The architectural work to define a contract for the design of the different Software Components can be summarized as Frontloading. Industrial use cases show that iterations are often applied to handle the densified knowledge embodied by Frontloading, as represented in the lowest line of the figure, which details the middle-line: In practice the phase of Frontloading goes along with a phase of Round-Trip-Engineering. Both represent efforts to apply in a right manner the AUTOSAR-paradigm and the duration of these phases have to be kept as short as possible, to efficiently apply AUTOSAR. A methodological procedure is required therefore. This leads to the subtitle of this master thesis: “A concept for tackling Frontloading in Model-based Engineering with AUTOSAR”.

To be able to elaborate the addressed concept, this thesis relies on the development of an exemplary function according to the AUTOSAR-paradigm. In a first time the clarification of Frontloading is targeted. AUTOSAR is further subordinated to the technological trend of Model-based Software Engineering. The guideline chosen for the elaboration of the example is to apply AUTOSAR with respect to the fundaments of Model-based Software Engineering. This represents an important decision for the present work.

Figure 2shall briefly illustrate this decision, made in an advanced stage of the work. Without deepening the numerous details contained in the figure, it shows that an anticipatory development of the logical system-architecture is completed in the V-Model, which represents the main reference for automotive engineering. This means, that this work aims to respect the fundament of the Model-based Software Engineering, to practice an early and durable decomposition of the system, taking into account the heavy architectural-paradigm which has to be faced at software-level with AUTOSAR. Based on this decision, the elaboration choses a precise Requirements Engineering to elucidate the development based on user requirements towards application-software with AUTOSAR. The association of requirements-types to corresponding development-artefacts is the base for the concept to set up.

Figure 2: Left branch of the V-Model depicting the model-based approach to AUTOSAR practiced in this thesis (clarification in subchapter 7.1)

With these contents in mind, the introduction made in this chapter finally aims to give an overview of the different chapters of the thesis:

Chapter2of this document locates this master thesis in its context, in particular within CRYSTAL, in the framework of which this thesis has been initiated at ITK Engineering AG. It presents the origin and motivation of the CRYSTAL-project, which is concerned with the development of interoperability-technology for System Engineering Environments. Furthermore, determining project-parts like Work Package 6.5 and the Use Case 3.1, to which this thesis is related, are introduced. This chapter finally underlines the relevance of CRYSTAL´s core topic “interoperability” in the automotive context, the development of safety-critical functionalities demanding ever better tool-chain-integration.

As this master thesis originates from the prevalence of interoperability targeted by CRYSTAL, chapter3pursues the definition of terminologies related to this key-word. It further emphasizes the economical relevance of the topic within information-processes and ends with a meaningful analogy, underlining how tool-chain-integration is targeted in the sense of CRYSTAL.

The standard AUTOSAR being the actual base of research for this master thesis, chapter4approaches the introduction to this industrial field. It pursues a presentation of the standard, which embodies a promising solution for handling the growing complexity in the development of automotive software. AUTOSAR´s Methodology is presented with focus on the development of application-software.

Beyond the actual standard-contents,chapter5classifiesAUTOSAR within the established industrial trend of Model-based Software Engineering. This leads to the identification of the mentioned methodological conflict in the application of the standard AUTOSAR, commonly referred to as Frontloading. This issue and its refurbishment are so fundamental for the application of AUTOSAR that the present elaboration refrains from the concentration of CRYSTAL on the topic “interoperability” with the prevalent aim to pursue efficiency in the engineering-process.

Chapter6first of all introduces the set up chosen for the work in this thesis and introduces the exemplary automotive function to be elaborated. Before deepening the development of the latter in this thesis, the addressed Frontloading and its symptoms in software-development with AUTOSAR are elucidated. The early decomposition of the system at the logical level is finally identified as a key-aspect of Model-based Software Engineering.

Chapter7approaches the actual function-realization with AUTOSAR especially respecting the paradigm of Model-based Software Engineering. The guideline chosen for the elaboration of the example is to apply AUTOSAR with respect to the fundaments of Model-based Software Engineering. This important decision, as depicted inFigure 2, represents the base for the elaboration of the exemplary function, which consequently applies a precise Requirements Engineering.

This work finally sets out to deliver a concept for the efficient handling of AUTOSAR within Model-based Software Engineering, in particular tackling Frontloading and associated iterations in the engineering-process. The concept is built on the insights gained by the development of an exemplary function, mainly associating different types of requirements to corresponding development artefacts. Chapter8presents the concept.

2Presentation of CRYSTAL[1]

This chapter serves the purpose of better locate this master thesis in the surrounding context. It presents the CRYSTAL-project, in which this thesis has been initiated by ITK Engineering AG. The origin and the mission of the project are explained and determining project-parts as Work Package 6.5 and the Use Case 3.1 are introduced. The chapter thus helps understanding the superior motivation of this thesis work.

CRYSTAL stands for “CRitical sYSTem engineering AcceLeration” and is a project of ARTEMIS Joint Undertaking (ARTEMIS JU), which started in May 2013. ARTEMIS Joint Undertaking is a European partnership focusing on Embedded Systems with more than 200 members. Every stakeholder in the ARTEMIS JU follows the ARTEMIS Strategic Research Agenda (SRA), which is a commonly agreed research agenda defined by the members. The CRYSTAL-project has a duration of three years and its main goal is to improve interoperability of tools during systems development.

2.1 Origin of the project

The project is based on results from previous ARTEMIS projects like CESAR (1), iFEST (2) and MBAT (3) and in this way offers a concrete chance to accomplish the transition from pure research to industrial application. It also reuses results of European and national projects like p/nSAFECER, SAFE (4), TIMMO-2-USE, OPENCOSS (5). With this foundation, CRYSTAL wants to enhance the Reference Technology Platform (RTP) and the Interoperability Specification (IOS), which have been initiated by previous projects, towards European standards and mature their industrialization.

2.2 Mission of CRYSTAL

According to the mission of the ARTEMIS JU to strengthen the European market for Embedded Systems, the CRYSTAL-project wants to enhance the reusability[2] across the domains Aerospace, Automotive, Health and Rail. The main aim therefore is to mature the RTP and IOS, so that faster development-cycles and early validation can take place. With CRYSTAL, ARTEMIS JU plans to establish collaboration schemes on a large scale and to cover the entire software product life-cycle for ready-for-use industrial tool-chains. CRYSTAL aims to develop usable results for the industry and therefore strives for a Technology Readiness Level (TRL) up to seven[3] in a scale from one[4] to nine[5]. An appropriate handover of the results from CRYSTAL towards the industry will therefore have to take place.

For the development of Embedded Systems, companies crucially rely on the usage of different software-tools. Multiple software vendors provide different tools with special abilities. These tools have mostly evolved separately and are not primarily designed to collaborate. Data-exchange is needed between these tools to ensure an effective workflow. Otherwise engineers are forced to adapt and transfer information between tools and this causes numerous disadvantages[6]. Through the establishment of the RTP and IOS, CRYSTAL wants to foster interoperability. (Cf.(6))

2.3 Overview of project-contents

CRYSTAL defines four main pillars for its strategy to achieve its goals:

“

1. Apply engineering methods to industrially relevant use cases and increase the maturity of existing concepts developed in previous projects

2. Provide technical innovations (“Bricks”) with high maturity to fill gaps identified in the use cases.

3. Contribute to the Cooperative RTP and push the Interoperability Specification towards standardization.

4. Support SME[7] integration into the embedded systems engineering ecosystem.

“ (7)

As it is mentioned in the first pillar, CRYSTAL wants to increase the maturity of existing concepts from predecessor-projects, mainly RTP and IOS. Also domain-specific insights are to be investigated to be able to establish cross-domain synergies (cf. (8)).

With the final aim to develop the abovementioned bricks (cf. next paragraph), CRYSTAL takes a user-driven approach, like shown inFigure 3. According to this approach, every consideration inside CRYSTAL starts at the so called User Cloud, in which User Stories from different domains[8] can be found. User Stories are fully abstract entities corresponding to certain processes, which are deployed in different companies. A refinement of the User Stories leads to the so called Use Cases (UC), which describe a concrete scenario of a project inside a company. These special Use Cases define requirements needed to improve the RTP and IOS and thus allow the development of bricks[9].

Figure 3: User driven approach of CRYSTAL, (7)

To better understand the background of today´s industry of Embedded Systems, it is helpful to acknowledge the interwoven structure for concepts in the different domains Aerospace, Automotive, Healthcare and Rail and underline the resulting complexity, cf.Figure 4. Indeed a closer look on this structure helps to reflect the intention of CRYSTAL with regard to the user-driven-approach, which has been mentioned right above. It is crucial to be aware of the fact that the different domains (y-axis) covered by CRYSTAL, all use or aspire to certain technologies (z-axis). These technologies in turn cannot by achieved by single elements. To create modern technologies it is necessary to rely on a set of different entities, which can rather be special methodologies or software-tools. This is where the development of so called Bricks (x-axis) is required. This finally explains the user-driven approach that has been introduced previously. For Uses Cases[10] inside a company, which again are related to certain technologies, executing members need elements to reach goals. These elements can be for example different tools that have to work together to perform a result. That is the point, where CRYSTAL tries to deliver concrete results in terms of bricks. The superior aim is to reach good interoperability.

Figure 4: Interwoven structure in the Embedded System industry focused by CRYSTAL, (6)

2.4 Contributions of earlier projects to CRYSTAL

Subchapter2.1mentioned that CRYSTAL is based on main achievements from previous ARTEMIS projects. The Reference Technology Platform and the Interoperability Specification are main achievements originating from them. Having now elucidated this basis, the project-interdependencies can be addressed

The left part ofFigure 5first of all shows a timeline as overview for the mentioned ARTEMIS JU projects: CESAR, iFEST, MBAT and CRYSTAL. The right part of the figure in turn depicts the relation between CRYSTAL and different European research-projects with their achievements. This clearly demonstrates the continuous efforts to develop a common interoperability standard. CESAR aimed at improving methods, tools and processes to decrease development-efforts and introducing the RTP (Cf. (9)). The main goal of iFEST was to specify and develop an integration framework for establishing and maintaining tool-chains for the engineering and life-cycle support of SW (Software) and HW (Hardware) of Embedded Systems. MBAT in turn focuses the development of a RTP for validation and verification within the transportation domain.

Figure 5: Timeline of ARTEMIS JU projects (left) and relationship between CRYSTAL and other European research-projects (right), (6)

With this foundation, CRYSTAL offers a concrete chance to accomplish the transition from the research-field towards industrial application by maturing the RTP and IOS, so that faster development-cycles and early validation can take place. RTP and IOS necessarily have to be mentioned in this chapter for the presentation of the frame-project, but due to the orientation of this thesis, these topics are not discussed in further detail.

As a project, which made first efforts towards interoperability and which is already completed by June 2012, CESAR delivers suitable contents to elucidate more details on interoperability. The paper (10) for example delivers a good overall introduction in to RTP and IOS.

The principal endeavors of CRYSTAL actually rely on OSLC (Open Services for Lifecycle Collaboration), (11), and thus are mainly based on WWW (World Wide Web). CRYSTAL is aiming to overcome challenges of interoperability at different levels of communication, from architecture of systems up to processes. Existing standards shall be integrated in this context.

2.5 The CRYSTAL-consortium

Realizing such an ambitious project and delivering results with a high Technology Readiness Level, requires a large number of proponents and contributors. There are 68 partners from 10 different countries[11] as shown inFigure 6. The German company AVL LIST GMBH has the role of the project manager (cf. (12)) and famous firms like EADS, Daimler and IBM contribute to CRYSTAL. The project is formed by participants from different backgrounds: OEMs (Original Equipment Manufacturer), suppliers, tool vendors and academic institutions are involved. The overall budget can be numbered at approximately 82 million €. Major parts will be financed by six Dutch companies and thirteen German companies.

Figure 6: Structure of CRYSTAL-consortium and partners from ten European countries, (7)

2.6 Project-structure

This chapter aims to explain the internal structure by means ofFigure 7. In a first approach, there is a division into six Subprojects (SP). The Subproject SP1 is at the highest level and is accountable for the project management. For each of the four domains that have been presented in subchapter2.3, there is an own Subproject in the form of SP2 to SP5. These Subprojects are mainly responsible for elaborating domain-specific Use Cases that can be investigated within SP6. The latter is in direct interaction with the sub-projects two to five. It defines and develops solutions in terms of IOS- and RTP-contributions and bricks.

[12]Since the sub-projects two to five are domain-specific, a higher partition is needed by means of the Work Packages (WP). These WPs either focus on special Use Cases within a company[13] or treat an issue of higher relevance.[14] Each Work Package within the Subprojects two to five has a direct correspondence to a Use Case. This is not the case for Work Packages within the SP6. Work Packages in turn can be divided into Tasks (e.g. 6.5.3) and Undertasks with precise goals to accomplish. The so-called Deliverables are results[15] that have to be elaborated until a certain point of time within Tasks. The already mentioned Bricks[16], cf. subchapter2.3, are superior objectives. They have to be achieved by tasks and represent building blocks that can either be a software-component for a tool or a product, a whole tool or product itself, a special methodology for an engineering-process, a standard or any other means striving for the superior goal of interoperability.

Figure 7: Internal project-structure of CRYSTAL, (6)

2.7 Location of this master thesis within CRYSTAL