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

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.3 Description of Frontloading within AUTOSAR
6.4 Fundament of 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.3 Mapping of Software Components to Electronic Control Units
7.4 Developing Internal Behavior of Software Component Descriptions
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

Abstract

Keywords

AUTOSAR, Model-based Software Engineering, V-Model, Interoperability, Frontloading, Round-Trip Engineering, Decomposition, Integration, Model-in-the-Loop, Virtual Functional Bus

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.

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 of automotive 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 with Figure 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.

illustration not visible in this excerpt

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 2 shall 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.

illustration not visible in this excerpt

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:

Chapter 2 of 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, chapter 3 pursues 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, chapter 4 approaches 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, chapter 5 classifies AUTOSAR 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.

Chapter 6 first 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.

Chapter 7 approaches 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 in Figure 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. Chapter 8 presents the concept.

2 Presentation of CRYSTAL

This chapter serves the purpose of better locate this master thesis in the surrounding context.^[1] 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 in Figure 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].

illustration not visible in this excerpt

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.

illustration not visible in this excerpt

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

2.4 Contributions of earlier projects to CRYSTAL

Subchapter 2.1 mentioned 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 of Figure 5 first 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 veriﬁcation within the transportation domain.

illustration not visible in this excerpt

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 in Figure 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.

illustration not visible in this excerpt

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 of Figure 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 subchapter 2.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. subchapter 2.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.

illustration not visible in this excerpt

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

2.7 Location of this master thesis within CRYSTAL

ITK Engineering AG actively participates in the CRYSTAL as a project-member. The company is among other things involved in Work Package 6.5 named “Specification, Development and Assessment for AUTOSAR Tools & Components”^[17]. For this master thesis an agreement has been reached with the development process at Volvo Trucks in UC 3.1^[18]: An exemplary automotive functionality has been defined for the research in this thesis with the consent of ITK and Volvo.

With regard to the structure of CRYSTAL, as presented in the previous subchapter, this thesis can contribute to tasks within WP 6.5, namely Task 6.5.2 “AUTOSAR/EAST-ADL Interface”, Task 6.5.6 “SWC builder” and Task 6.5.7 “ARTOP”. WP 6.5 and the 3.1 emphasize the link of this thesis to the topic “AUTOSAR”.

2.8 Relevance of interoperability to automotive system engineering

Although the realization of interoperability-technology will not be explained in this work, the superior motivation for this endeavor shall be underlined in this subchapter, especially with regard to the surrounding automotive context. Looking at the boundary conditions of this work, the general framework in which it is acting is the development of Embedded Systems. At this level, circumstances to be emphasized are^[19]:

- A decreasing time-to-market is needed.
- The market demands for sustained cost-reduction.
- The development relies on ever more distributed teams with an increasing number of partners.
- The engineering has to handle more and more multidisciplinary aspects and the complexity grows.
- The number of tools needed is growing with a tool-landscape getting more and more heterogeneous.

One step further, this thesis is located within the automotive industry. Additional influencing factors thus have to be taken into consideration (Cf. (9)). The expansion of E/E (Electric/electronic)-systems within cars evolves even more dynamically than the global market of Embedded Systems.

Embedded Systems realize more and more safety-critical functionalities within cars. This evolution represents a major change compared to mostly comfort-related features in previous car-generations. Already little malfunctions can lead to accidents seriously harming people and environment. This explains the necessity of the application of safety-standards like the ISO 26262. In particular, these standards require new methodologies and techniques within development processes.

This again underpins the need for tool-chain-integration ^[20]. An improved communication between tools used for the different activities in the engineering-process like specification, modelling or testing is required. Manual information-transfer between tools represents high costs and leads to inconsistencies. Deficient tool-integration becomes amplified in the interaction between an OEM and a supplier. In this way, it becomes clearer what the challenge of interoperability is within the automotive industry. (Cf. (9), chapt. 2)

3 Understanding interoperability

This chapter targets to develop a deeper understanding of the key-word “interoperability”. A clarification of this term must be given at an early stage of the thesis. The term is frequently used to express the fact that entities apparently work together in a technical context. A closer consideration in turn shows that the usage is often fuzzy and indistinctive from other technical terms.

Even if it is not necessary for the treatment of AUTOSAR in this thesis, the explanations within this chapter represent an useful foundation for a work approaching the topic “interoperability”, which strongly emerges in industry. Subchapter 3.1 shall first of all clarify the terminology of interoperability. A basic example is then used for introduction in the following subchapter. Subchapter 3.3 underlines the motivation for interoperability in process-management, and subchapter 3.4 finally introduces an analogy, which also indicates the approach to interoperability in CRYSTAL.

3.1 Definitions for interoperability

Although the word “interoperability” is not common in the academic context, it is a highly relevant topic in technical environments. A survey within the present work reveals the occurrence of the issue in science, especially in informatics. Due to its restrained public dissemination, the term is often confused with other notions. This subchapter aims to establish a clarification of the word “interoperability” to counter the fuzzy usage of this term.

In a first time, two principal definitions^[21] shall be noted:

Definition by IEEE

The IEEE (Institute of Electrical and Electronics Engineers) defines interoperability as: “the ability of two or more systems or components to exchange information and to use the information that has been exchanged”, (13)

At the same, it emphasizes a strong relationship to the term “compatibility” that is defined as:

“the ability of two or more systems or components to perform their required functions while sharing the same hardware or software environment”, (13)

Apart from the importance of these definitions for software engineering, the property of multiple units sharing information or resources and fulfilling their function with the help of the shared elements are underlined.

Definition in ISO 15926

The ISO^[22] 15926 is a standard for automation systems and their data integration. It defines interoperability as: “the ability of different types of computers, networks, operating systems, and applications to work together effectively, without prior communication, in order to exchange information in a useful and meaningful manner”, (14).

This explanation already describes the topic in much a more technical manner and explicitly focuses on technical systems.

The definition by the IEEE represents a meaningful description of “interoperability” and is sufficient for discussions approached in following subchapters. As it has been stated at the outset of this subchapter, interoperability is a topic treated within different scientific disciplines. As the following classification will show, useful insights can be found, although the public dissemination is not broad:

Categorization of interoperability

Valuable features of interoperability are for example discussed in the context of health information systems: The report (15) explains a clear subdivision of the term “interoperability”, which is applicable for the field of ICT (Information and Communication Technology). Accordingly interoperability can be considered on the following levels^[23]:

- Interoperability at the technical level^[24]: This is the most concrete level and concerns the connection of a hardware-device, the signals transmitted and the protocol used.
- Interoperability on the structural level: The latter means a simple data-exchange based on the previous connection.
- Interoperability at the syntactical level: On this level a meaningful data-exchange with agreed vocabulary can take place. This means that there are elementary units composed of subunits commonly used and understood by the cooperating or communicating components.
- Interoperability at the semantic level: There has to be communication with common information models and agreed signification of the information exchanged.
- Interoperability at the level of organization and service^[25]: This type of interoperability is based on a common business model and services and thus goes one step further. It refers to a common treatment of information and goes beyond the static signification of information towards the dynamic processing of the latter.

This distinction will be addressed later on in the work with regard to the standard AUTOSAR. Meanwhile, to tackle the fuzzy usage of the term “interoperability”, a distinction from other terms is helpful:

Terminology-delimitation

A first basic distinction has to be made between the terms integration, interoperability and interoperation. These three words, which are apparently similar, are often intermingled in the daily use. It is possible to note a difference between these three words, already indicated by the previous definition from IEEE, designating interoperability as an ability of systems.

- As opposed to this, integration is not an ability of a system but much more a precondition to be fulfilled to reach interoperability. With regard to the system, integration thus is a static property and has to be completed before the runtime of the system. For example, in a tool-chain, the integration of the different tools is needed to establish a relation between the data of each tool and the common processing (Cf. (16)). A comparison of both terms can be found within (17). In the common usage, integration can further address the enclosed action of a function within a system without obvious inference.
- Interoperation in turn is neither an ability nor a static property of a system, but has to be seen as a runtime-phenomenon. This means that interoperation has to be considered during the action of a system. Two tools in use within a company and exchanging a data-format are indeed interoperating.

A further meaningful delimitation can be reached considering the engineering field of modelling and simulation within (18). The latter emphasizes a clear distinction between the notions interoperability, reusability and composability^[26]. According to it, interoperability is the ability of different systems to work together and to exchange data or services at runtime. Attention shall be directed towards the fact, that in contrast to this:

- Reusability is the ability of a system to be reused when the application scenario changes. It is a measurement of applicability in different environments and scenarios. Reusability, as a static property of a component to be reused, can support the interoperation of components. In general reusability also improves different forms of interoperability but also can restrain interoperability, if huge efforts have to be put into adaptor-techniques of the components.
- Composability is the capability to assemble units in different combinations towards a valid system for a specific use. Thus, composability has to be considered prior to runtime and focuses on what components can be integrated into or added to a system without restricting its function^[27].

With respect to these comparisons, IEC (International Electrotechnical Commission) presents a classification within the document TC 65/290/DC, (19)to categorize the degree of compatibility of devices in a network for automatization. Interoperability can thus be understood as a degree of compatibility ^[28]. IEC defines a graduation starting with “incompatible” and ending up with “interchangeable” stretching over the attributes “coexistent”, “interconnectable”, “interworkable”, and “interoperable” to measure how far devices can work together depending on the availability of special features. This classification from IEC allows quantifying to a certain manner, how well components of a system work together.

These delimitations finally facilitate a clearer handling of the key-word “interoperability” in this thesis: They for example give a meaning to “reusability” as addressed with the presentation of CRYSTAL in subchapter 2.2. The clarifications in this subchapter represent a base of knowledge that can be addressed in the following chapters of this work. This work intentionally forewent an own definition, the terminology-landscape being already extensive enough.

3.2 Example in business-process

It is useful to continue with an example to emphasize in a simple manner, what interoperability can be about and how the mentioned topic is relevant to the daily work of a company. This example intentionally is given without a technical introduction, to emphasize its common signification.

Inside the processes of a company the communication of employees working together on a common issue is a key-factor for the success, provided that it occurs efficiently. The happening of regular meetings or web-conferences between project-members, who can be located at different places of the company or even across companies, is a crucial part of good project-communication. Furthermore, the finding of common dates for the meetings between all participants is necessary. To then approach the issue of interoperability within the scenario of finding a date, two different procedures could be considered:

- On one hand, one could imagine the organizer and meeting-members finding a date without having access to the calendars of the members. This means, that the organizer would have to make different proposals e.g. via mail or phone to each member, getting the answer of each and making new proposals until most members agree for the proposed date. This approach obviously bears the risk to cost a lot of time through the high communication exchange between the organizer and every single member solely. Consequently the efficiency of the procedure “finding an appointment” is very low, because the investment of time for the organizer and the members is potentially high.
- On the other hand, one could imagine the organizer and meeting-members finding a date through a global access of the organizer to the calendars of each meeting-member. In this way, the fast finding of a meeting-date is much more probable. Exception may be due to a late change in the calendar of a member at the time the organizer makes a proposal.

Without detailing the technical realization of information-exchange in this case, this example shows how crucial the issue “interoperability” is for the daily business within companies: The example relates to the intuitive meaning as the seamless cooperation between entities (cf. (20)).

The definition of interoperability given from the IEEE, cf. subchapter 3.1, as “The ability of two or more systems or components to exchange information and to use the information that has been exchanged” thus is very meaningful here.

Two different scenarios for the procedure “finding an appointment” have been considered in this example, where interoperability can be understood as the good access of information of one colleague to information of other colleagues; the calendars are the entities and the exchange of dates between the latter represents the seamless cooperation. Such reflections can be applied similarly for implied tools and their communication.

This example shows in a basic way how the efficiency of a company in terms of low invest of time and money for a procedure can be improved through the good and easy interaction between entities. Interoperability thus has a superior economic motivation. In this case interoperability is shown by means of the communication and information-exchange between employees within a company.

3.3 Interoperability in process-management

Before introducing interoperability from an economic angle within process-management in this subchapter, a short presentation of the basic theory of economic processes can be meaningful. This first theory-part is oriented on (21).

A business-process can be seen as a set of numerous steps together forming a transformation: The latter transforms inputs into outputs; the outputs can be goods or services: This allows the distinction between goods-processes and information-processes. Talking about processes, it is elementary to distinguish between the process as type or generic description^[29], and the process as order or concrete realization of a process of a certain type^[30]. Corresponding to this distinction, one can differentiate two levels of process-organization: the process-planning and the order-planning. The type of a process is basically specified through the description of the input-factors, output-factors, functions and the corresponding synchronization-rules. The assessment of processes is done with criteria like quality, flexibility, costs and time. As the description of an aggregated cost-function is often pretty difficult, time represents a central factor for the evaluation of processes^[31]. (Cf. (21))

To describe processes and be able to solve problems related to them via process-management, the modelling of processes is a key-issue. In this context the modelling of different views on systems is crucial. Thus, one can e.g. differentiate the point of view of scheduling, structure, transformations or transitions. To establish a relation between inputs and outputs, it is for example possible to use a transformation-diagram with nodes corresponding to the transformation, compare Figure 8. (Cf. (21))

illustration not visible in this excerpt

Figure 8: Example of process-description via transformation-diagram, (21)

Beside the general introduction into processes given above, this subchapter fosters a very general explication of the term “interoperability”. The aim of this subchapter is not to define interoperability but to underline its importance. A pretty abstract approach to this notion can be found inside the book “Prozessmanagement. Strategien, Methoden, Umsetzung”, (22). The latter addresses the topic from an economic point of view in the framework of process-management.

As an economic entity, a company targets the superior goal of reaching high efficiency and effectiveness. Thereby, process-management is the key to reach structured activities with as less as possible avoidable efforts. It allows improving procedures in which human beings, resources and information are involved. The rigorous application of process-management can positively affect quality-management and cross-company cooperation. (Cf. (22), P.3)

Process-management can basically be distinguished into three different abstraction-levels^[32]: The strategy, as the way to reach superior economic goals, the procedure, describing the concrete action of a company, and the method^[33], for the application of processes within a company e.g. by means of tools. Interoperability is the key-word of process-management at the method-level and in this way represents the base for a solid process-management. (Cf. (22))

From this perspective, interoperability can generally be understood as a key-factor for the economic success of a company, as it has already been indicated within the previous subchapter. Ensuring efficiency in an international context, where different business-models and organizational structures can be involved, requires interoperability as a key-competence. Major international projects, as e.g. the development of the Airbus A380, accentuate the primordial role of interoperability and its signification for the success within a distributed project.

Furthermore, specialization is an important aspect for companies as they have to act in numerous different technical fields. At the same time, the cooperation of different faculties is crucial and it is necessary to unify them within the supply-chain. Business-processes can be very diverse and ensuring interoperability represents a significant technical challenge, being everything but natural. In fact, advanced solutions are required at the methodological level, aiming for interoperability on the organization-level, cf. subchapter 3.1. This underlines the importance of the approaches fostered by CRYSTAL for interoperability-technology.

3.4 Analogy for interoperability

This subchapter presents an analogy for the key-word “interoperability”. Even if it has no scientific background, this subchapter helps in giving a more tangible understanding, also indicating decisive insights driving the development of interoperability-technology in CRYSTAL. Therefore, interoperability shall be referred to as the seamless cooperation between entities, like it has been presented in subchapter 3.2. At the same time its influence on the economy of a company should be emphasized. The analogy presented here is established between a process within a company and a spur-gear-train and based on a transformation-diagram, like it has been presented in the previous subchapter. The analogy focuses on information-processes ^[34]. This means, that input is any kind of data and the output is information^[35]. The analogy is shown in Figure 9.

illustration not visible in this excerpt

Figure 9: Analogy for interoperability between spur-gear-train and information-process

At this level, the following association can be made between the information-process and a mechanical gear-train: The input-data corresponds to the input-torque, whereas the output-information corresponds to the output-torque. Inside the gear-train, the gears correspond to the processors^[36]. The fulfilment of the needed transmission-ratio at the output corresponds to the output of the correct information in the process. The operation of the gearing with as less as possible losses shall now be compared with a process within a company, which has to be performed as economically as possible.

In this simplified consideration, the information-process has to be seen as a sequence of steps. The number of steps can be different and depends on the elementary operations needed to build the process^[37]. In the analogy with the gear-train, this can be seen as the number of wheels needed for a defined transmission-ratio with the restriction that the transmission between two wheels is limited^[38].

In a basic approach, the correct engagement of two spur-gears requires adapted toothing^[39] and division. For example, the engagement between the wheels 1 and 2 or between the wheels 4 and 5 work properly this way, because the division is the same. In contrast to this the engagement of the gears 2 and 4 would not be possible and that is why the two gears of different types of division are needed on the axis 3. Related to the information-process one could say, that the interoperability between the processors 1 and 2 and between the processors 4 and 5 is good. Opposed to this, good interoperability between 2 and 4 can only be ensured via an additional adaptor in terms of the axis 3 with two gears of both types of division.

Here a differentiation between elementary and additional gear-wheels is needed for the analogy. The elementary wheels should be understood as these absolutely necessary for the transformation. These processors fulfil a step in the process, which is indispensable. Furthermore, there are additional gears like these based on the axis 3, which are needed to improve interoperability. From an economic point of view, these wheels can be seen as disadvantageous. In a gear-train every single gear rotating is linked to inertia and to friction leading to losses in terms of power.

The analogy depicted in this subchapter has the following intention. On one hand, it aims to simplify the theoretical contents regarding processes from the previous subchapter and gives them a practical meaning through a correspondence with a common technical example.

On the other hand, it can be understood as a very basic indication for the major motivation of interoperability, as it is fostered by CRYSTAL. This shall by no means be the main intention here, because another starting-point should have been taken therefore. Nevertheless, the following insight is worth to be noted: The attempt to solve bad interoperability between the processors of an information-process, especially development-tools, through the usage of proprietary adaptors (cf. (10)), for the solution of a particular use case ,as represented by the axis 3 in the above analogy, does not resolve interoperability-problems on a high scale. It only helps solving a particular interoperability-problem.

Such adaptors in particular are not scalable with a growing number of interacting tools and cannot guaranty efficiency for processes. This chapter thus finally indicates that interoperability, as it is fostered by CRYSTAL with IOS, cf. subchapter 2, pursues a fundamentally different interoperability-approach comparable to a data-BUS^[40]: All parties of a process agree on a common interoperability specification, with concepts for the tools and their communication (cf. (10)). Referring back to subchapter 3.1, it becomes clear in how far such efforts for interoperability-technology in CRYSTAL rely on tool-integration: This static precondition has to be guaranteed to enhance good interoperation.

4 Introducing AUTOSAR

As it has been elucidated in subchapter 2.7, this master thesis contributes to Work Package 6.5 “Specification, Development and Assessment for AUTOSAR Tools & Components” of CRYSTAL. In order to clarify the base of research for this elaboration, some background is beneficial.

AUTOSAR is the emergent software-standard within the development of automotive functionalities. The increasing popularity of AUTOSAR causes the industry to experience its application, with its advantages, but also with related difficulties. Countering negative side-effects in the application of AUTOSAR is an urgent task. The consideration of AUTOSAR represents an important contribution for the research on interoperability within the development of Embedded Systems, as fostered by CRYSTAL, cf. subchapter 2.2. The title of this thesis emphasizes exactly this issue, as pursued by Work Package 6.5 of CRYSTAL.

4.1 Presentation of AUTOSAR

AUTOSAR, (23), stands for „ AUTomotive Open System ARchitecture “ and represents an international partnership of OEMs, automotive suppliers and software-vendors. The partnership has been founded in 2003 and the consortium is divided into 4 levels of partnership, led by the so-called core partners. The main content of AUTOSAR is the standardization of the automotive software, which shall foster the independency of software from underlying hardware (Cf. (24), chapt. 4.2). The standard has actually reached its release 4.1 on the market, after having established itself, mainly with the release 3.2, (25). A first approach to the standard can be accomplished through the media-site of the consortium, (26). The extensive specification-material, however, should be consulted with greater care and it is recommended to look for secondary literature for a better introduction into the standard. The main topics treated by AUTOSAR can be categorized into:

- Methodology
- Architecture ^[41]
- Interfaces

4.2 Motivation for AUTOSAR

The sources emphasizing the explosive expansion of E/E-systems in the automotive industry are endless. The still-growing role of these systems is not only a topic in the literature but is a palpable phenomenon for every car-passenger. The function an OEM is able to offer its customer has become one of the most market-decisive factors. At this point it is primordial to point out the central role of software in this context. Nearly all these market-decisive functions finally rely on software. The term function is basically understood as an “intended relation between causes and effects” (Cf. (27)) and fundamentally influences the costumer-experience in the car.

For a long time the expansion of E/E-systems in the car-industry has manifested itself through a continuously growing number of ECUs (Electronic Control Unit). This evolution actually encounters physical limits (Cf. (28)), which go along with a noteworthy change in the function-development within the automotive industry. Instead of purchasing entire ECUs from suppliers for the fulfilment of a specific function, OEMs more and more practice a distinct development: High efforts are performed to decouple software and hardware, so that both no longer have to be considered as capsulated. OEMs attempt to slacken the binding between ECUs and application-software, even if the one-to-one relationship has obvious organizational advantages. There is a tendency to develop a growing number of functionalities on generic hardware platforms (Cf. (29), chapt. 2.4.1) with a stagnating number of ECUs, minimizing as far as possible interdependencies. Thereby, OEMs tend to enhance the development of own brand-specific functions. The ECU-network in contrast does not develop in the same rhythm and can be seen as more static. Software-parts not relevant to the core function at application level but necessary for the operation of the system and requiring special know-how often have to be accomplished by suppliers.

The motivation of a standard with the scale of AUTOSAR is tangible in this context. The OEMs are the driving force and thus play the decisive role in this context. AUTOSAR aims to improve the development of software and its integration (Cf. (29), chapt. 2.4.1) in the automotive system. The development should be less ECU-oriented and more software-function-oriented: At the same time OEMs^[42] actually want to maintain and expand their influence on the development of the function, as the aspect to be experienced by the customer.

4.3 Insight into development of automotive functions

The previous subchapter touches on the development of function.^[43] In particular, it underlines the turnabout from an ECU-oriented development towards a software-oriented development. This change can be compared with the orientation on applications in the case of modern smartphones. The following example shall clarify the scenarios in actual developments and point out further aspects going along with the new trend.

Functionalities in cars are nearly never built from the scratch. This means there are only rare cases, where the whole electronic-platform of a car is developed completely from the very beginning on. An example for such a development is the Toyota Prius, a pioneer of the hybrid propulsion. The most cases of function-development in cars have different approaches. Figure 10 therefore shows a possible scenario for new car-functions in a “car-type B” from an exemplary “OEM 1”.

The figure depicts the timeline for the development, SOP (Start Of Production) and update^[44] of two car-types from a same OEM and shall emphasize, that beside functions newly developed for type B, like the functions B2 or B8, there can also be functions handed over from type A to type B, like the function A3. This could for example happen, if type A is an upper class car already available on the market and type B is a more recent car from a lower class: Adopting a proven function in type B from type A is then a common setting. The inverse can also happen, if an innovative function is developed for type B and the OEM aims to integrate the function into the updated type A, like with function B7. The seamless transfer of software containing the function is thus desirable.

As it is not always possible to simply adopt a function into an already established system, like it could occur for the transfer of function B7, it can be necessary to perform adaptations on the technical system-architecture. An example with respect to a new function for the chassis could be: The considered chassis-function should operate within a network that is already overloaded; in this case the installation of an additional FlexRay-network for the chassis could be required.

This subchapter, beyond the software-oriented development addressed previously, underlines that beside the new development of software-functions, the portability of functions is a dominating topic, e.g. in the case of an OEM aiming to deliver the same function for 2 car-types. Ensuring reusability and portability of development-artefacts in fact is a further strong motivation fostered by AUTOSAR, beyond the efforts to improve integration of software as explained in the previous subchapter.

illustration not visible in this excerpt

Figure 10: Exemplary scenario of new car-functions in a car-type B from OEM 1

4.4 AUTOSAR-Methodology

AUTOSAR publishes the Methodology for the standard-conform software-production. The specifications for the Methodology aim to describe the development with AUTOSAR from a process perspective and represent a neutral and public source of information in contrast to different software-tools on the market claiming the standard-conform realization of special parts of the workflow. The main document concerning the Methodology is “AUTOSAR_TR_Methodology.pdf”, (30) . As it is stated within the section “ Objective ” in this document, “ AUTOSAR requires a common technical approach for some steps of system development” and the Methodology “covers all major steps of the development of a system with AUTOSAR: from the deﬁnition of the Virtual Function Bus to the generation of an ECU executable”.

The Methodology of AUTOSAR as defined in the release 4.0 is shown in Figure 11. The workflow depicted there starts with the activity “Develop a VFB System Description” and ends with “Integrate Software for ECU”^[45]. The VFB (Virtual Functional Bus) is a structured overview of the functions required for the system in focus. In a first time this overview does not take into account the underlying network and ECUs, which are considered in a further step. The Methodology ends with the integration of the different software-parts produced in the development process, allowing the generation of an executable file per ECU.

The Methodology does not claim completeness for the development of automotive systems, but in fact represents the main guideline for every company adapting its software-development to the standard. Furthermore, it is important to know that AUTOSAR does not want to prescribe an order for the different activities but focuses more on the logical link between work-product (data), represented by the pink covers in the upper figure, and the corresponding activity (work-step), represented by the yellow and orange boxes. There is no timeline prescribed and iterations are planned to happen. The responsibilities for activities are not further assigned to special departments of any kind in companies, but simply associated with a role. (Cf. (30), chapt. 1)

This thesis is not concerned with all aspects of the AUTOSAR-Methodology and thus is would not be appropriate to start a detailed description of it. The standard tries to cover the development of automotive systems and in this way approaches an immense task. Instead this chapter forges ahead to the core topic that matters for the development of automotive systems; the primordial aspect for the OEM is the function, which has to be delivered to the customer. As it has it been indicated in subchapter 4.2, the software-part of this function is the most decisive aspect in its development. The next subchapter therefore emphasizes how AUTOSAR addresses the realization of software-functions, in the way OEMs want to deliver them on the market.

illustration not visible in this excerpt

Figure 11: AUTOSAR-Methodology in release 4.0, (30)

4.5 Specifying application-software with the Virtual Functional Bus

As it has been explained with Figure 11, the Methodology of AUTOSAR starts with the activity “Develop a VFB System Description”. This means that the process according to AUTOSAR starts with a structured overview of the functions required for the system that shall be developed. One can directly note that the key-word function is evocated here. Therefore, it is useful to describe properly, how AUTOSAR defines this view of function. Corresponding information can be found in the specification of the VFB, (31).

Figure 12 shows an example of a functional structure as it can be considered on the VFB -level by means of an exemplary seat-heating-functionality. The details of this example are not at all relevant to the actual reflections. It is much more interesting to reflect the singularities of the structuration used here. The main units of this structure are the so-called SWCs (Software Components) , which are represented by black frames with grey background. As single units are created with the SWCs, communication-paths have to be defined together with this structuration: So called-connectors are used for this purpose and represent instances of generic Interfaces. The points of interaction at each end of a connector are named Ports.

Being confronted to such architectural decisions, it is useful to understand according to which criteria they have to be completed. The main specification for the VFB, (31), e.g. states that components are units that can be instantiated. This reveals that these development-steps can be understood in terms of object-orientation, with an approach comparable to classes and objects. At the same time there is less precise information to be found like the following statement: “A single component can implement both very simple but also very complex functionality. A component may have a small number of ports providing or requiring simple pieces of information, but can also have a large number of ports providing or requiring complex combinations of data and operations”, (31). The latter probably wants to address the granularity of the architecture. A more systematic approach can be found in a classification presenting different types of SWCs and e.g. differentiating a “Service software component” from an “Application software component”, ( (31), P. 29-32).

illustration not visible in this excerpt

Figure 12: Example of a function-structure at VFB-level, (31)

Since the structuration of components includes the definition and assignment of Interfaces, the knowledge about these and their restrictions is crucial. According to the specification of AUTOSAR, there is more than the commonly-known differentiation between the Client/Server-Interface and the Sender/Receiver-Interface; special types of Interfaces like the Trigger Interface can also be taken into account.

These central VFB-paradigms shall not be detailed here, as they will be discussed in the main part of this thesis. Instead the attention shall be directed to further aspects. It can e.g. be necessary to take into account components for the abstraction from the underlying hardware on VFB-level^[46]. This can be the case for Sensor-actuator software components^[47] or Complex device driver software components. The delimitation of the core function at application-level and duties of the software related to the ECU thus can require special attention. AUTOSAR also defines components with a special role like for AUTOSAR Services or Mode Management.

When the design of the VFB is finally completed, the activity “Configure System” is accomplished to mainly map SWCs on ECUs. In the Methodology according to the release 4.0, this activity is to be found inside the activity “Develop System”, (Cf. (30), P.46 et seq.).

The description in this subchapter can be followed along the documents “AUTOSAR_TR_Methodology.pdf”, (30) , and the “AUTOSAR_EXP_VFB.pdf”, (31). The activity “Develop a VFB System Description” has been presented in this way. At this point of the Methodology, it becomes much more difficult to comprehend the further steps of AUTOSAR to describe software-functions. Figure 11 shows that the activity “Develop Application Software” is coupled to “Develop a VFB System Description”. Since this is exactly the place where the functional part of software has to implemented, and where the engineering-process becomes less clear, it is worthwhile to examine it.

4.6 The activity “Develop Application Software ”

Subchapter “2.3 Develop Software Components” in (30) e.g. states “This is the generic Activity valid for several kinds of atomic software components. The ﬁrst step is to create design, including the runnables, events, interrunnable variables, etc. Once this is complete, the contract header ﬁles can be created and the software component can be implemented”. Subchapter “3.4 Software Component” in turn reveals the following: “This chapter contains the deﬁnition of work products and tasks used for the development of a single software component against a given VFB description. …”. These two citations allow the following deduction: To be able to further describe a function in AUTOSAR the development has to be accomplished “against a given VFB description” and “the ﬁrst step is to create a design, including the Runnables, Events, Interrunnable Variables”. The additional information to be found in (30) is hardly processable by humans: It mainly describes detailed relations between specific work-products and activities and is rather destined to tool-implementations according to the Methodology.

As such specific activities are mostly to be accomplished with tool-support and do not explain in a meaningful manner how a function is described in AUTOSAR, further information can be found in “AUTOSAR_TPS_SoftwareComponentTemplate.pdf”, (32).

The first chapter of this document states:

“In this context, the term software-component refers to a formally described piece of software existing that needs the AUTOSAR RTE [2] for execution.

Please note that the general ideas behind the semantics of application software-components have been described in the speciﬁcation of the Virtual Functional Bus [3]. The latter, however, represents conceptual work that strongly inﬂuences but does not totally govern the formal deﬁnition of software-components.”^[48]

This thus confirms that more precision can be found in the specification of Software Components, (32), on how to describe a function within AUTOSAR. Figure 13 especially depicts that in AUTOSAR, Software Components have to be described at three distinct levels:

- The Virtual Functional Bus level: Here the fundamental communication properties are expressed by means of Interfaces and Ports mostly.
- The Runtime-Environment level: This level allows describing the so-called Internal Behavior of SWCs according to RTE (Runtime-Environment)-concepts with e.g. Runnables and Events.
- The Implementation level: It is the lowest level of description in the AUTOSAR meta-model. At this stage, code has to be mapped to the previously presented Internal Behavior: this frame-structure is filled with a concrete functional implementation for a specific function.

As AUTOSAR explicitly doesn’t focus on standardizing means of implementations for functions^[49], the next level to focus on, is the Runtime-Environment level. The VFB-level, as the first level for the description of a function within AUTOSAR, has been addressed in subchapter 4.5. The RTE-level aims to specify the Internal Behavior of the Software Components. Chapt. 7 of the document (32) describes the different AUTOSAR-artifacts relevant to the modelling at this level like Runnables, Events and possibilities to access and exchange data. As it is explicitly stated in the name of this modeling-level, all aspects treated here are relevant to the runtime. The best information thus can be accessed through a combined lecture of the already mentioned documents (31) and (32) but also with the specification of the RTE, (33).

illustration not visible in this excerpt

Figure 13: Description levels for AUTOSAR Software Components, (32)

Beyond the reflections on VFB-level, the focus on contents concerning the Internal Behavior will require main efforts in this work. The elucidation of these specifications, which is primarily destined to tool-implementers, and their classification in the global context of function-development with AUTOSAR, are crucial for efficient engineering-processes. Such clarifications represent a first methodological support for the elaboration of the concept in this thesis.

5 Frontloading as a cause for inefficiency in engineering with AUTOSAR

From a historical point of view, the standard AUTOSAR is subordinated to Model-based Software Engineering. This makes the presentation of this paradigm and the V Model necessary. Furthermore, the location of AUTOSAR within this established technological trend allows deducing a main consequence from the application of the standard: Frontloading embodies the measures proposed by AUTOSAR for easing the integration of software. The fact that this phenomenon is not related to interoperability in a first place, influences the orientation of this thesis, to elaborate a methodological concept.

5.1 Model -based Software Engineering in the V-Model

AUTOSAR, which has been initiated in 2003, is a more recent technology than the well-established and broadly-applied Model-based Engineering. The evocation of this key-word necessitates a brief explanation, in particular with regard to fact that the thesis builds on this term.

Model-based Engineering is applied in different engineering activities of the automotive sector but plays an especially important role for the software, where it is then called Model-based Software Engineering (MBSE). The name usually designates the usage of graphical models within development processes to formulate and develop special aspects of the software-products on a certain abstraction level (cf. (34)): The focus can be directed towards the aspects targeted, minimizing technical side-issues. In practice it commonly implies tool-capabilities to automatically generate development-artefacts like C-Code and can further support test-possibilities. Without being able to detail this topic, it should be mentioned, that beyond this clarification, Model-based Engineering represents an established technological trend in the automotive industry that is in particular embodied by the technology-chain composed out of MIL (Model-in-the-Loop), SIL (Software-in-the-Loop) and HIL (Hardware-in-the-Loop).

In particular, Model-based Engineering is rigorously applied within the automotive industry with the V-Model, (35): Its first version has already been presented in 1992. The V-Model is considered as the main reference for Model-based Engineering and is based on a broad consent. Its application will not be justified here: It´s dissemination and expressiveness plead for it. An extensive academic treatment of this topic can be found in the source (36). De facto, the application of the standard AUTOSAR has to be subordinated to it.

Figure 14 shall serve as a brief reference to the mentioned V-Model. The latter presents special characteristics like the separation between the development-branch and the test-branch, horizontal interactions between these branches, a system-development divided into different technical fields, especially with the ECU-software, and finally the implementation in the base of the V-Model.

The thesis in particular introduces the term system with this figure, which has a high relevance for the progress of the work. A clear introduction of the notion is thus helpful. Therefore the work refers to the definition of Automotive SPICE, (37), where the system can be understood as the union of mechanics, software and hardware (cf. (38)). It specially has to be contrasted from the pure software-part, which is in the focus of this thesis.

illustration not visible in this excerpt

Figure 14: Presentation of the V-Model, (Cf. (27))

As already indicated in the previous subchapter, the aim again is to clarify, how the development process can evolve from a function-idea in terms of requirements to a corresponding software-representation. Therefore, it is helpful in a first time to follow the deepening of the left V-branch through main steps (Cf. (36)), without omitting the importance of corresponding test-steps in the right branch:

- The specification of the logical system-architecture:

At this level, the aim is to model in a technically-independent manner the function according to primary requirements. The latter shall be grouped into non-redundant sets and emergent features have to be identified. This is the base for modelling functionality with tools like MATLAB/Simulink.

Therefore, a meaningful structure of corresponding models, e.g. of a block-diagram in Simulink is required: Usually the models are divided into a behavioral model for the main logic on an ECU and an environment model, containing models of actuators, sensors, the controlled system, the environment and the driver. The behavioral model targets the identification of logical units and important signals.

A key-technology of Model-based Engineering to be mentioned at this level is the MIL. The latter allows verifying and validating requirements and corresponding models in an early stage of development.

- The specification of the technical system-architecture:

This specification takes into account low-level requirements with detailed aspects of the system, on which the function has to be realized. It implies the underlying ECUs, the associated networks, the mapping of functions to ECUs and the mapping of signals between ECUs to network-messages.

- The specification of the software-architecture:

In classical development processes, this work is usually done in technical languages like UML (Unified Modeling Language) or SysML (Systems Modeling Language) and aims to establish a structuration into software components, to describe their connections and to model states of operation for the software.

- The specification of software components:

This step comprises the specification of the algorithms in software components, the definition of their real-time behavior and the separation between algorithms and parameters. After this step, the concrete implementation of the software can be completed.

- The implementation:

This allows proceeding with the next important key-technology of Model-based Engineering: The SIL enables the test of core-algorithms as software, previously represented in the behavioral model in MIL.

An important aspect of Model-based Engineering at the transition from a model to the corresponding software is the automatic code-generation. This technology allows a fast and traceable code-implementation for a corresponding model.

5.2 AUTOSAR within Model-based Software Engineering

With these explanations concerning the V-Model in the industrial context, the broadly established procedure for software-development has been elucidated. Subchapter 4.5 in turn has given explanations regarding the function-development with AUTOSAR. Based on this, a first approach can be completed to classify software-development with AUTOSAR within Model-based Software Engineering. Figure 15 allows a first simple mapping of the function-modeling with AUTOSAR, as it has been presented in subchapter 4.5, and Model-based Engineering with the V-Model, as described in subchapter 5.1. Such a classification constitutes a first milestone for this work, so that the research can be deepened. For clarification, it shall already been said at this stage, that this classification will require a more detailed consideration later on.

The steps number 4 and 5 in the V-Model have therefore been depicted with AUTOSAR artifacts. Number “4” shows a structuration like defined at the VFB-level with SWCs and Interfaces, while number “5” gives a further description of the Internal Behavior of a SWC at the RTE-level with artifacts like Runnables and Events. A first consideration could thus give the impression that the realization of software with AUTOSAR could occur in different detailing-degrees, like indicated within Figure 13, from the VFB-level, over the Internal Behavior, to the implementation in number “5”.

Figure 15 does not claim neither completeness nor detailed illustration. It aims much more to depict a typical classification of an automotive software-development, where the standard AUTOSAR is being applied within an established Model-based Engineering procedure.

As two major different technological trends have been presented until here:

- AUTOSAR, as a standardization for automotive software launched in 2003, in chapter 4
- Model-based Engineering, as the established guideline in the automotive system-development, in subchapter 5.1

Key aspects concerning both should be recalled here. The AUTOSAR-Methodology, as shown in Figure 11, tries to represent a common technical approach for major steps of the development of a system along activities with work-products. No timeline is prescribed in this context and iterations are planned to happen. The V-model, as a procedure-model, focuses more on the order of the different steps but in this case as well, iterations have to be taken into account especially due to feedbacks from the test-cases.

Iterations may happen in every development, but the key-question is how Model-based Engineering with AUTOSAR, as presented in a first approach within Figure 15, can be completed efficiently from a process-angle on. The Methodology of AUTOSAR represents the central reference in this context, as it is the only neutral guideline of the development with AUTOSAR.

illustration not visible in this excerpt

Figure 15: The V-Model and first classification of the development of software-functions with AUTOSAR

5.3 The price for easing software-integration: Frontloading

Integration is one of the major issues in the development of embedded real-time systems. This is explained in a concise manner in the second chapter of the book (29), entitled “Model-Based Integration”. According to this source, the integration-problem is basically caused by the human need to divide problems in order to find solutions. The report explains the terminology of integration, presents types of integration-problems, solution-strategies and the state of the art, and furthermore refers to advanced solution-proposals like AUTOSAR^[50]. In summary, AUTOSAR approaches integration with the concept of interfaces, which combines the major integration-techniques “Explicit Horizontal Decomposition & Composition” and “Vertical Abstraction & Enrichment”. At the ECU-level, this concept of AUTOSAR mainly addresses problems of syntactic, technological and data-ﬂow nature. (Cf. (29), chapt. 2)

Subchapter 4.2 has already underlined that easing the integration of software is a core goal of AUTOSAR, with respect to the fact, that the development is no more ECU-oriented but more software-function-oriented. An important insight can thus be made with regard to Figure 15: The integration of the software being located in the right branch of the V-Model at number “8”, the attempt to improve the integration of the software, makes the introduction of particular paradigms necessary in the left branch of the V-Model. This is where AUTOSAR acts in terms of software-architecture.

For Model-based Engineering, the component-interface software engineering means that logical models, like they are handled on the level of the “Specification of the logical system-architecture”, cf. number “2” in Figure 15, have to be transposed into particular software-architecture models. This cannot be reduced to the pure coding with a special software language like C. The conformity to the standard AUTOSAR requires fundamental architectural approaches, which go far beyond the simple translation of functional aspects from a model towards software. Anyhow, the superior goal is to fulfil the requirements on the function to be realized. The logical model used in Model-based Engineering in this context allows for early validations of functional requirements. The usage of AUTOSAR as software-standard in turn mainly promises the circumvention of integration-problems. But AUTOSAR in a first time represents the explicit decomposition of the system.

The phenomenon addressed in this subchapter can be titled as Frontloading (cf. (24), P. 182). AUTOSAR is especially encountered as component-interface software engineering at the level of application-software, which implicates the need for an explicit software-architecture (cf. (29), P. 40). Frontloading can thereby be understood as the occurrence of very challenging decisions in early development-phases. The component-interface software engineering mainly aims to anticipate difficulties normally appearing in the integration-phase. The term “Frontloading” thus results from the transfer of development-efforts from late to early development-phases. It is not only linked to the knowledge relevant to build an AUTOSAR-application-architecture, but in practice is especially encompassed by a huge tool-support claiming to represent a guidance to appropriately configure the AUTOSAR-system. This represents an additional financial aspect of the evocated Frontloading for companies.

Examples of “real-life”-practice in the industry help emphasizing the challenge represented by Frontloading: It is common practice in industrial processes^[51] to bypass the AUTOSAR-application-architecture by applying colloquially called “soft-variants” of AUTOSAR-applications. This can mean either simply using one SWC with one Runnable to represent a function or eliminating the RTE as defined by AUTOSAR. Such practices are not intended by the standard and obviously bear the risk not to profit from decisive advantages enabled by AUTOSAR. Furthermore, interventions as the suppression of a key element, like the RTE within AUTOSAR, are linked to huge consequences in terms of architecture and process, which are difficult to embank.

As mentioned in subchapter 4.4, AUTOSAR and its Methodology take into account the occurrence of iterations, which are nearly not avoidable within complex engineering-processes, where numerous different aspects have to be considered. AUTOSAR and the tools established on the market of the AUTOSAR-Methodology therefore generally support the import and export of the AUTOSAR-specific file-format ARXML (AUTOSAR Extensible Markup Language). These exchanges represent the means to realize the AUTOSAR-Methodology, as the logical link between data, “work-product”, and the corresponding work-step, named “activity”, cf. subchapter 4.4.

Figure 15 showed a first pragmatic approach to the topic AUTOSAR within model-based development in this thesis. The discussion in this subchapter especially summarizes AUTOSAR within MBSE as a highly-challenging architectural task encountered when reaching the software-level within a development. Approaching AUTOSAR as a methodology, like presented in subchapter 4.4, without further considering the system at a logical level in the V-model, an important remark can be made. Figure 11 clearly illustrates that in AUTOSAR the activity “Develop Application Software” is subsequent to the “Overall VFB System”. This means that in the AUTOSAR-Methodology, except for an eventual previous logical model, not addressed explicitly by the standard, the development of application-software is accomplished inside a contract, referred to as SWC Description, cf. Figure 13.

5.4 Round-Trip-Engineering with Software Components

The preceding subchapter addresses the fact that according to the AUTOSAR-Methodology the development of application-software is accomplished inside a contract, referred to as SWC Description. This is a design-by-contract (Cf. (39)^[52], chapt. 17.3). The structuration leading to SWC Descriptions is done at the level of VFB^[53]. The actual development of a Software Component occurs inside the SWC Description, and insights within the development can lead to changes affecting the SWC Description itself, in turn affecting the VFB and leading to numerous iterations for the development of application-software.

The import and export of the AUTOSAR-specific file-format ARXML has further been introduced as the main means of tools to realize the AUTOSAR-Methodology, linking work-products and corresponding activities. SWC Descriptions are ARXML-files mainly developed at VFB-level. The Methodology of AUTOSAR intends the import of the SWC Description into model-based modeling-tools like MATLAB/Simulink. The latter shall allow for the model-based implementation of components. This primarily means that the production of code for a corresponding function is intended. The practice proves that design-by-contract necessitates several rounds for the coordination of SWC Descriptions with the overall VFB, and during the model-based implementation of components, SWC Descriptions need to be exported back towards the VFB. In this way, MBSE for components is iterated again, as sustained by the AUTOSAR-Methodology. This procedure is called Round-Trip Engineering (Cf. (40)).

The report (40) is the most prominent description of the practice of Round-Trip Engineering, as supported in AUTOSAR. In substance, Round-Trip Engineering as described there shall be the base to allow for iterations in the development process. The report in particular details the interaction between architecture-tools and BMTs (Behavior Modeling Tool) for MBSE. The import and export of the ARXML SWC Description between tools plays the key-role in this scenario.

With regard to CRYSTAL, UC 3.1 (Cf. (41)) presents such a roundtrip-situation at the step “AUTOSAR Application Development”. The above-mentioned phenomenon occurring here shows a reinforced need for coordination between the system-architecture and the implementation of single Software Components. Thus, the Use Case presents a typical scenario of Round-Trip Engineering. UC 3.1 resorts to ArcCore Arctic Studio as AUTOSAR-tool (42), especially for the setup of SWC Descriptions, and to MATLAB/Simulink with Embedded Coder (43) for model-based implementations of AUTOSAR-SWCs. In particular, UC 3.1 intends the realization of an interoperability-solution between MATLAB/Simulink with Embedded Coder^[54] and the ArcCore Arctic Studio.

Round-Trip Engineering is not a new phenomenon occurring with AUTOSAR. It can much more be considered as procedure used in software engineering to coordinate the target-actual comparison between a model and the corresponding product. The paper (44) for example elucidates such a procedure with UML. A concise statement describing the topic Round-Trip Engineering from the perspective of software engineering could be the following: “With Round-Trip Engineering, a programmer generates code from a design diagram, changes that code in a separate development environment and recreates the adapted design diagram back from the source code”, (45). The important analogy to underline with Round-Trip Engineering in AUTOSAR is that iterations can obviously be linked to a development with different representations, where aspects of the product are modelled at different levels depending on the fact, where a certain aspect is the best changeable.

[...]

^[1] The information for this chapter is mainly taken from: (7), (75), (4), (6) and (12)

^[2] Cf. subchapter 3.1 of this thesis for a clarification of this term.

^[3] (76) briefly explains TRL.

^[4] TRL 1 is the lowest level, where only basic principles of a technology are identified.

^[5] TRL 9 is the highest level, where a technology is fully developed and approved for real operation.

^[6] This mostly means increased development costs and risks of inconsistencies.

^[7] Small and Medium-sized Enterprises

^[8] The project focuses on the four domains Aerospace, Automotive, Healthcare and Rail.

^[9] A brick 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. Furthermore a brick can either have a methodical or technological character.

^[10] This word should be understood with its root-meaning. For the user of a product, a use case is known as a special scenario one performs with the product e.g. reading mails with Microsoft Outlook.

^[11] (78)

^[12] Internal project-information

^[13] E.g. a development process at Volvo Trucks for electronic architecture including vehicle functions in UC 3.1

^[14] E.g. “Specification, Development and Assessment for AUTOSAR Tools & Components” in WP 6.5

^[15] In general deliverables are textual documents.

^[16] The numeration for bricks is not linked to Subprojects like WP or tasks, but has an own numeration.

^[17] (85), internal document of CRYSTAL

^[18] (41), internal document of CRYSTAL

^[19] Cf. (77) P.93 et seq.: chapt. 4.6.3

^[20] Cf. subchapter 3.1 of this thesis for a clarification of this term

^[21] More definitions can be found in ISO 12382, ISO 14285, ISO 15745 and ISO 16100.

^[22] International Organization for Standardization

^[23] The norm ISO/TR 20514 can also be mentioned in this context: It further evocates the term “functional interoperability” in contrast to the semantic interoperability.

^[24] Depending on the context, technical interoperability can be considered on a more abstract level, for example in relation to simulations accomplished on computers, Cf. (18).

^[25] This can also be called “substantive interoperability”, Cf. (18).

^[26] Most of the explanations are related to the field of modelling and simulation, nevertheless the core-content can be transposed to a general interpretation, as the terms considered are broadly used, e.g. in informatics.

^[27] One can note the relation to integration, composability as a measurement for integration.

^[28] The link between interoperability and compatibility is underlined here.

^[29] For example travel-expense-reports within a company

^[30] The travel-expense-report of the travel X from the employee Y.

^[31] The different notions of time can mostly be valued in money.

^[32] Cf. (22), P.13-14

^[33] Cf. (22), P.24 et seq.

^[34] Goods-processes are not in scope, compare subchapter 3.3

^[35] The comparison is simplified to a single input and output.

^[36] Cf. (21), P.3: Among the inputs of a process, employees and operating-material are called processors due to their special role.

^[37] This can be compared to a mathematical problem, where a defined set of calculations within an algorithm has to be accomplished to reach the result.

^[38] This shall explain why the transmission ratio is not achieved directly via two wheels.

^[39] In this comparison, only spur-gears are focused. Other types of gears like helical gears are not considered.

^[40] Binary Unit System

^[41] The layered software-architecture, cf. (55), cannot be focused here. A concise representation will be addressed later in Figure 27.

^[42] A basic principle stated by AUTOSAR is “Cooperate on standards, compete on implementation”.

^[43] Exemplary scenario discussed with a technical expert at ITK Engineering.

^[44] For the design of the car, updates are often referred to as “facelift” and often go along with system-updates.

^[45] The verbs „start“ and „end“ must not purely be seen from a time-angle on, as mentioned previously.

^[46] Cf. (31), P.60-63

^[47] The spelling of these terms is oriented on the specifications.

^[48] This citation contains highly-relevant information that will be addressed again in subchapter 7.3 of the thesis.

^[49] According to the basic principle “Cooperate on standards, compete on implementation”.

^[50] As the integration-strategy of AUTOSAR itself is not in the focus of this thesis, this topic cannot be focused.

^[51] Sources must not be named due to confidentiality.

^[52] This book is a main reference for general software engineering and will be often used as a neutral reference, although it is not specialized for the automotive context.

^[53] This structuration in particular does not have to coincide with a previous logical architecture, used for a first validation in MBSE.

^[54] A technical detail to mention regarding the exchange of AUTOSAR SWC Descriptions is that MATLAB recently developed an alternative solution to the “arxml.importer”. The ATPP (AUTOSAR Target Production Package) is a new solution to approach tasks linked to MBSE with AUTOSAR in MATLAB.

Ende der Leseprobe aus 147 Seiten - nach oben

Details

Titel: Research on interoperability within development processes of Embedded Systems on an example
Untertitel: A concept for tackling Frontloading in Model-based Engineering with AUTOSAR
Hochschule: Hochschule Karlsruhe - Technik und Wirtschaft (Fakultät für Maschinenbau und Mechatronik)
Note: 1.0
Autor: Ferdinand Schäfer (Autor:in)
Erscheinungsjahr: 2014
Seiten: 147
Katalognummer: V292686
ISBN (eBook): 9783656897965
ISBN (Buch): 9783656897972
Sprache: Englisch
Schlagworte: research embedded systems frontloading model-based engineering autosar

Arbeit zitieren: Ferdinand Schäfer (Autor:in), 2014, Research on interoperability within development processes of Embedded Systems on an example, München, GRIN Verlag, https://www.grin.com/document/292686

Research on interoperability within development processes of Embedded Systems on an example

A concept for tackling Frontloading in Model-based Engineering with AUTOSAR

Leseprobe

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

Details