Florian Bock
email: florian.inifau.bock@fau.de

Reinhard German
email: reinhard.german@fau.de

Sebastian Siegl
email: sebastian.siegl@audi.de

Domain-Specific Languages for the Definition of Automotive System Requirements

Keywords: Software Engineering, Automotive, Artifact Generation, DSL

Over the last decades, the complexity of modern cars and the included hardware and software has vastly increased. To maintain a constant development and release cycle for car manufacturers, more sophisticated development methods are required. The fields of requirements engineering and test management have high optimization potential. In order to improve the transitions between the different development stages, the combination of a controlled natural language and a domainspecific language can be used, which is drafted in this paper. It enables the user to specify requirements textually with automotive vocabulary and generate artifacts such as functional models.

I. INTRODUCTION

Modern cars include a wide variety of complex software functions, ranging from essential types such as engine controlling to user-assisting types such as driver assistance functions. The amount of software code required for this functions is constantly increasing. That is why software engineering methods used over the last decades are no longer sufficient to be able to maintain the established development cycle and at the same time produce the necessary quantity of code. New methods such as agile development techniques are introduced and thus, a larger variety of tools are employed. These tools differ in their characteristics as well as in their field of application. Generally speaking, the development process can be separated into several phases mainly based on the V-model [START_REF] Bröhl | The V-Model, ser. Software -Application Delevopment -Information Systems[END_REF]:

• Specification: The system is specified in an abstract way, with focus on the use cases, actors and system boundaries.

• Design: The system is enriched with more details, the system architecture is defined and technical characteristics such as required hardware/software and interfaces to other systems are included.

• Implementation: The system design is transformed into code, either via code generation or manually.

Each of these phases is linked to an individual testing phase.

To accumulate all relevant information of a single development phase, artifacts are used, e.g. models, diagrams or documents. The degree of detail of these artifacts increases during the development process. Because the phases are based one on the other, the artifacts should be reused in subsequent phases to avoid duplication of effort caused by regenerating them.

Especially in large projects, a single engineer cannot handle all phases at once, so separate engineers treat each development phase. Due to different reasons such as the lack of communication, local separation of the engineers or complex hierarchical structures, the desired reuse of the artifacts either does not occur at all or is carried out manually in a superficial way.

A possible solution for this would be to use mandatory guidelines for all engineers. Such guidelines are quite hard to define due to the great variety of involved modeling techniques and tools. In addition, they have to be complied with manually. A key point in this discussion is the designation of the master in the development process. Different approaches are possible, from implementation-driven (requirements according to the implementation, often used in predevelopment phases) to specification-driven (implementation according to the requirements). Many of the projects in the automotive domain start implementation-driven whereas the desired trend is focused more towards specification-driven projects, where the specification is created first and is used to derive basic models and diagrams for any subsequent development phase. This can be performed manually, though an at least partly automated derivation is more efficient and less prone to errors. Such a derivation can be achieved by the combination of a Controlled Natural Language (CNL) and a Domain-Specific Language (DSL) for system specification, which are drafted in this paper. They are particularly designed for the automotive domain and include an automatic generation of various required artifacts (e.g. models) for the development process.

II. CONCEPT

A CNL is based on a natural language such as English, but is limited in terms of grammar and vocabulary. There is no general definition of a DSL in the literature, but it can be summarized as a programming language designed for a specific domain with the capability of generating predefined target artifacts. Contrary to CNLs, which typically use a textual form of presentation due to their relation with common natural languages, a DSL can either be textual, graphical or use a combination, which is called hybrid. This choice is based on the target stakeholders and the requirements of the project environment. In the automotive domain, many system specification documents are currently created and modified in IBM Rational DOORS in form of plain textual requirements without any embedded functionality. If diagrams or models have to be included due to the project settings, they are attached as manually created pictures or simple models (e.g. as Microsoft PowerPoint documents). Therefore, a hybrid approach is most appropriate for our case, because textual requirements match the existing documents and additional graphical information in form of models can be directly embedded.

The adoption of such a newly introduced methodology to specify systems mainly depends on the acceptance among the established system architects. To minimize the familiarization difficulties, the presentation and the terminology have to be leaned on already available documents and editors. That is to say the syntax and semantics of the specification should be as similar as possible to existing requirements in DOORS. For this, a detailed analysis of available requirements have to be carried out, so that common phrases, established terms and the intended underlying information can be collected and abstracted. The level of detail of the requirements differ depending on the current development phase, the personal capabilities and project experience of the specifier and the target audience. The inclusion of technical information such as interface specifications, detailed algorithms or code are not unusual. Such information are typically extracted manually afterwards and used in the system design and implementation.

The following categories of information embedded in the requirements have already been identified:

• Functional requirements, which can be used to create behavior models (e.g. state machines, activity models or timing models).

• Constraints, which specify technical or legal limitations which have to be taken into account in the system architecture.

• Descriptive requirements, which provide system details used for documentation.

• Test or scenario descriptions, which can be used to formulate test cases or formal test scenarios.

A future extension of this list is likely and depends on the investigated existing requirements and the individual project settings.

Besides the structure and representation of the DSL, the desired output artifacts have to be specified and the proper generators for each artifact have to be implemented. In the automotive domain, a vast variety of development tools and methods are used, ranging from specification instruments (e.g. DOORS) to implementation methods (e.g. C++), so an individual selection of desired target artifacts for a specific project scenario has to be defined.

The concept of our CNL/DSL-combination for the given scenario consists of a worflow divided into four steps: 1) As initial situation, the unstructured information about the system to develop are available in form of documents, slides or plain ideas. 2) These information are aggregated, structured, and a predefined lexicon and grammar (based on the English language and automotive related terminology) are used for realization in form of a semi-formal requirements collection. This can be done either by manually transforming the available data or by using parsing techniques [START_REF] Osborne | Processing Natural Language Software Requirement Specifications[END_REF].

3) The data incorporated in the collection are then transferred into a DSL, where the required information for the generation process are aggregated. A visualization of some additional details in the form of state charts or tracing information are provided. Afterwards, the generators of the DSL generates the specified target artifacts. 4) The generated artifacts can be manually enriched with additional details and then be distributed or used for the system implementation.

III. RELATED WORK

In case of CNLs, Marko et. al. [START_REF] Marko | Combining Xtext and OSLC for Integrated Model-Based Requirements Engineering[END_REF] proposed an implementation of a CNL for writing requirements in Eclipse XText [START_REF]XText -Language Engineering for Everyone![END_REF]. The general requirements structure is analyzed and the topic of a domain specific meta-model is discussed. To integrate the solution with other tools, the use of the Open Services for Lifecycle Collaboration (OSLC) standard is suggested. This paper focuses mainly on the collection of specification information, generator aspects are not discussed.

Beside the CNLs, there are already several tools available. For example KPIT medini analyze [START_REF]medini analyze[END_REF] is a functional safety tool particularly focused on considering the ISO26262 standard. It enables the user to specify requirements, design the system and perform various safety analysis. Nevertheless, neither does it use requirements in natural language form, nor are generator aspects included.

Due to the fact, that each DSL is by definition limited to a specific domain, they cannot be generally used in each project scenario. Recently, DSLs are becoming more popular in the automotive domain in the course of ongoing development process improvements. Some attempts already have been published, of which three major examples shall be summarized and reviewed at this point:

Voelter et. al. proposed a DSL focused on requirements embedded in the framework mbeddr [START_REF] Voelter | mbeddr: instantiating a language workbench in the embedded software domain[END_REF]. The specification is phrased in a pseudo code notation, which covers additional features such as tracing, state machines and tables. The goal is to generate code from the specification, which is supported by the possibility of embedding code directly in the requirements. They conclude, that such a DSL offers great advantages at the expense of reasonable effort.

Ballhause et. al. [START_REF] Ballhause | Anforderungen programmieren -eine domänenspezifische Sprache (DSL) im Praxiseinsatz[END_REF] proposed a DSL focused on requirements engineering, which uses a formal pseudo code like notation to describe use cases and requirements and transform them to predefined representations, e.g. tabular or graphical diagrams. They describe their experiences and problems with the definition and use of the DSL. They come to the conclusion, that such a DSL is a benefit for the development process, if the costs of its definition are acceptable and the DSL is limited to a specific company. A general approach is possible, but not expedient in view of effort and complexity.

Trindade et. al. [START_REF] Trindade | Automatically Generated Safety Mechanisms from Semi-Formal Software Safety Requirements[END_REF] introduced a DSL focused on safety requirements. They also use a pseudo code notation and include a generator, which transforms the DSL into code. The implementation and design is closely related to AUTOSAR and its components. They proof DSLs as proper mechanism to automate repetitive generation tasks and to include domain specific aspects in a formal but easily comprehensible document.

Although these examples offer several DSLs, they lack the extraction and creation techniques of detailed models out of the requirements and they partly use a pseudo code notation, which does not reflect the optimized textual presentation form similar to DOORS, that we intend to achieve.

IV. PROTOTYPE

Several frameworks for the stand-alone definition and implementation of CNLs are already available [START_REF] Angelov | Implementing Controlled Languages in GF[END_REF]. This is mainly relevant when intending to use parsing technologies to transform already available textual documents into the CNL. We confine the first prototype to the direct integration of the grammar and the lexicon into a drafted DSL, instead of implementing the CNL separately. This is sufficient to demonstrate the intended workflow.

For the definition of a DSL, several workbenches exist, e.g. JetBrains Meta-Programming System (MPS) [START_REF] Jetbrains | Meta Programming System -DSL Development Environment[END_REF], Eclipse XText [START_REF]XText -Language Engineering for Everyone![END_REF] or MetaCase MetaEdit++ [START_REF] Metacase | MetaEdit++ -Model your idea[END_REF]. They differ in their features and basic characteristics, but after a comparison, MPS was chosen as suitable solution for the given project. One main reason for this choice is MPS being a so-called projectional editor, the opposite of common source editors. In a source editor, the code is edited as text, if it should be compiled, an interpreter converts the text to an abstract syntax tree and transforms the tree to the target code. Within a projectional editor, this intermediate step of interpretation is left out, instead the user directly edits the abstract syntax tree in the editor. Editing with such an editor is more limited than with plain text, because only valid commands can be used, which makes it more sophisticated for the user to use it. However, it allows the combination of an arbitrary number of DSLs without worrying about any combination problems, because the grammars will automatically match. In advance, there are already many predefined DSLs available, which cover different aspects, e.g. mathematical equations, and can be integrated in the new DSL with few effort. As side remark, both the DSLs and documents which use them are saved in an ASCII-XML format, which makes them easily versionable in version control systems such as GIT [START_REF]git -local-branching-on-the-cheap[END_REF].

The structure and presentation of the drafted DSL is illustrated in Figure 2. The configuration paragraph allows the user to specify the artifacts to be generated. With help of the abbreviation definition of ABS, this acronym can be used Fig. 2: Textual DSL draft used for system specification throughout the specification document while guaranteeing, that the full form can be included in any generated artifact. The system behavior in requirement REQ1 describes the abstract algorithm of the whole system. In this case, it consists of three concatenated rules. In general, any number of rules can be combined or even divided in and distributed over several separate requirements. The strength of this approach is the similarity to natural language specifications, whereas the challenge for the DSL is to extract the underlying system behavior in order to transform it into a formal model. Constraints in any form such as in requirement LIM1 can be used to specify on the one hand intended or given technical limitations, or on the other hand legal issues such as dependencies to a specific standard, e.g. ISO26262.

Essential for the benefit of our DSL are the integratability and usability of the generated artifacts. Generally speaking, a generator of a DSL in Jetbrains MPS gathers all information stored by the specifier in the DSL document, adds relations and associations and generates Java source code, which then is finally used to create the desired artifacts. An advantage of this concept is, that the transformation is not limited to simple text-to-text transformations, but additional tools or Application Programming Interface (API)s can be accessed. For example the generation of Mathworks MATLAB Simulink [START_REF] Mathworks | Simulink -Simulation and Model-Based Design[END_REF] models can either be executed by creating the model textually as file, or by accessing the corresponding API, which is less prone to errors caused by changes in the file structure.

To show the variety of possible target artifacts, our prototype supports the following types:

• Unified Modeling Language (UML) [START_REF]Unified Modeling Language (UML) Resource Page[END_REF] sequence diagrams: Behavior specifications such as in requirement REQ1 are usually illustrated and documented in this commonly known type of diagram. After preparing the artifact creation, the generator uses a web API [START_REF]WebSequenceDiagrams[END_REF] to render the final image (cf. Figure 3).

• Mathworks MATLAB Simulink behavior models: Such models also cover the behavior extracted out of requirement REQ1 (cf. Figure 4). In addition, constraint information from other requirements such as LIM1 are included. This type of model is mainly used in the implementation of the system.

• Electrobit Assist ADTF [START_REF] Elektrobit | EB Assist ADTF -Driver assistance systems start with EB Assist ADTF[END_REF] source code: To a certain degree, test cases are derivable from requirements and some test cases can be already defined in the specification process. For example, a specific vehicle speed constraint implies several test cases, which can be automatically extracted. Such test cases are gathered and inserted in a predefined test framework in form of C code. The framework itself is also generated, so additional information from the specification document can be included. As a result, a folder structure and several source code files are created (cf. Figure 5), which are compiled and can be executed afterwards.

A manual extraction of the test cases and the repetitive creation of the source code for the test procedure are avoided with the automatic generation.

Apart from these artifacts, various additional models and files are possible. The question, which of these artifacts should be included in the DSL mainly depends on the intended target stakeholders. The more implementation-related the stakeholders are, the more technical information and models have to be generated. With help of the drafted CNL/DSL-combination, the development process for modern software systems in the automotive domain can be improved. The automatic generation of target artifacts significantly reduces the required development effort and supports the process in terms of consistency and traceability. As already mentioned in [START_REF] Ballhause | Anforderungen programmieren -eine domänenspezifische Sprache (DSL) im Praxiseinsatz[END_REF], the key factor for success of such a DSL is the tailoring to a specific company and its vocabulary. This is mainly caused by the different in-house development procedures, wordings and strategic objectives of the different companies. Obviously, this also includes the intended and included target artifacts, because they depend on the used applications. The described DSL implementation is the first step in the creation of a complete solution for the given scenario. Ongoing research topics include the collection of company-related vocabulary and grammar, the creation of a separate CNL with parsing capabilities, the definition and implementation of reasonable generators and the trial of our approach in several actual development projects. The results will be part of future publications.

Fig. 1 :

 1 Fig. 1: Concept workflow

Fig. 3 :Fig. 4 :

 34 Fig. 3: UML sequence diagram

Fig. 5 :

 5 Fig. 5: ADTF folder structure


Michael Käßmeyer

Rüdiger Berndt
email: ruediger.berndt@audi.de

Peter Bazan

Reinhard German
email: reinhard.german@fau.de

Toward an MDD-based Analysis of Stateful and Variant-rich Automotive Functions

Keywords: Fault Tree, Multi-Valued Decision Diagram, Dependability Analysis, States, Product Line Engineering, Minimal Cut Sets

The high integration of (sub-) systems performing safety critical automotive functions characterizes the current development in the automotive industry. The development and analysis is challenged by an increasing complexity resulting from product customization and variance in implementations by software-hardware solutions. In order to save costs for such scenarios, a systematic analysis of the dependencies between functions, as well as the functional and technical variance, is required. In this paper we introduce a new approach which allows to compactly represent and analyze a function with its different configurations, states, hardware modules, and software variants-also: Product Line Fault Tree (PLFT)-in a unified data structure based on Multi-valued Decision Diagrams (MDDs). The methodology allows to represent the function´s architecture within an MDD and transfer it in Fault Tree (FT)-and Minimal Cut Sets (MCSs)-MDDs. Therefore, complete fault trees are analyzed in one step-opposed to stepwise analyzing FTs of all configurations, software variants, and states. Summing up, this article introduces a systematic approach allowing to analyze fault propagation in variant-rich and stateful functions.

I. INTRODUCTION

The current challenge in the automotive industry is to enable piloted driving. Therefore a part to realize piloted driving is to combine and interact the state of the art assistant functions with each other. Moreover, additional assistant functions are developed to increase road safety or to offer new in-vehicle services.

Each assistant function and the interaction of these operate with respect to different contexts and contain a high number of sensors, actuators, and embedded software. This is why automotive functions are marked by variance and high complexity. Mostly all innovative functions are realized by software and many of them are safety related. Therefore functional safety is of considerable importance.

To manage the increasing complexity model-based development has been established in the automotive sector-mainly induced by highly-integrated Electronic Control Units (ECUs) and the growing number of variant-rich and stateful functions [START_REF] Ebert | Embedded Software: Facts, Figures, and Future[END_REF]. In this context an automotive safety standard is given by the ISO 26262 [2] postulating normative requirements to ensure functional safety within electrical and electronic vehicle systems. These include a hazard and risk analysis, a functional and technical safety concept, as well as safety analysis and safety case just to name a few. Consequently, the overall safety assessment is labor-intensive and time-consuming. As an example: available software tools that ought to support traceability or semi-automated consistency and completeness checks often do not meet specific user expectations.

Summing up, to enable piloted driving or develop a new innovative safety critical assistant function which contains all safety mechanisms is time-consuming with state-of-theart safety analysis methods such as Fault Tree Analysis (FTA). This is because on the one hand, functions are marked by numerous configurations (cf. Table I), states (cf. Table II), and software variants and on the other hand due to the lack of appropriate methods and tools to compactly represent and efficiently analyze such safety-critical functions. In this paper the characterization of configurations, states, hardware modules, and software variants is also called Combined Automotive Properties (CAP).

Therefore, in this article a new approach is established allowing to compactly represent the function´s architecture with its CAP in one data structure. Given that, a CAP-Fault Tree (FT) is established using Multi-valued Decision Diagrams (MDDs), cf.: Product Line Fault Tree (PLFT)-also referred as 150% model. Based on such compact MDD-FT representations, the proposed method allows to generate an MDD representation of the Minimal Cut Sets (MCSs) of the system including all CAP. This data structure, accordingly, enables one to extract the MCSs of specific configurations, software variants and states. Moreover, for a given MCS, the proposed method allows to identify the variants and states where the corresponding MCS will cause the system to fail. This article is structured as follows: Section II introduces related work. Section III presents a systematic approach to analyze safety-critical functions by means of MDDs. Finally, in Section IV, we summarize the article and suggest future research.

II. RELATED WORK

The related work on the overlapping areas of the safety method FTA and Product Line Engineering (PLE) are introduced.

Dehlinger proposed how to attach commonality and variability attributes to the PLFT and managed it as a core asset [START_REF] Dehlinger | Software Fault Tree Analysis for Product Lines[END_REF].

Lu's work [START_REF] Lu | Fault Contribution Trees for Product Families[END_REF] extends Dehlinger's work and is another way to obtain the same result for product lines. The so-called Fault Contribution Tree (FCT) is a variability tree for the product line where nodes are features instead of events (or conditions) [START_REF] Lam | A Case-study of Requirements Reuse Through Product Families[END_REF]. Feng's work [START_REF] Feng | Bi-directional Safety Analysis of Product Lines[END_REF] is another extension of Dehlinger's contribution constructing a software fault tree in a different manner: the method begins considering commonality and variability analysis as well as the product line architecture to obtain the so-called Extended Commonality and Variability Analysis (XCA). After that, the Software Fault Tree Analysis (SFTA) is carried out based on the XCA and the Software Failure Modes and Effects Analysis (SFMEA). Noda [START_REF] Noda | Introducing Fault Tree Analysis into Product Line Software Engineering for Exception Handling Feature Exploitation[END_REF] proposes a method assuming the fault of features from the feature diagram. A feature is selected and turned into the root node of the FT, then this structure is analyzed to identify all paths to the root node. Based on that, countermeasures are identified-like adding optional features to the diagram.

In [START_REF] Gómez | Variability Management of Safety and Reliability Models: An Intermediate Model Towards Systematic Reuse of Component Fault Trees[END_REF], the authors carry over product lines to the Component Fault Tree (CFT) approach. By doing so, the product line is steadily maintained over time and information on variability is considered w.r.t. FTAs. This method, for example, considers a component ("Ventilation System") to be reused from a previous Gas Turbine PL (SGT 500) within another Gas Turbine PL (SGT 400), the component is analyzed whether it is marked by the same software behavior, functions and structure. In the end, if the component is fully compatible with required characteristics, it is suited for the new product line [START_REF] Kaiser | A New Component Concept for Fault Trees[END_REF].

In contrast to these articles and the corresponding modeling approaches, this paper will rather focus on a systematic approach with a specific data structure to analyze fault propagation of variant-rich and stateful safety-critical automotive functions using MDDs.

III. SYSTEMATIC APPROACH TO ANALYZE SAFETY-CRITICAL FUNCTIONS

In this section a systematic approach is presented to derive safety analysis concepts. The objective is to analyze and compare MCSs and identify fault propagations of different configurations and software (SW) variants of a specific safetycritical function in one data structure. These functions are highly distributed, incorporate commercial off-the-shell components, and are developed by different supplier and Original Equipment Manufacturer (OEM) business units. In this case, neglecting of safety-critical fault propagations-which could lead to harm people-may result in costly redesigns during later development phases. Therefore, a systematic data structure approach is introduced to analyze safety-critical functions on an early development phase (architecture concepts). The advantage of an Multi-valued Decision Diagram (MDD) structure is, to store all feasible function architecture possibilities (due to CAPs) and their corresponding Fault Trees (FTs) in one framework. Moreover, a Minimal Cut Set (MCS) analysis of the different stored FTs are possible in this data structure.

In Figure 1 the transfer and encoding of properties within MDDs is shown. Specific algorithm steps are necessary to evaluate the approach and achieve the results of the shown MDDs. For reasons of simplicity, the algorithm steps are

A. Coding CAP to an MDD

Hence, safety analysis techniques on architecture concepts are increasingly applied at early design states [2]. State of the art methods are Failure Mode and Effects Analysis (FMEA) and Fault Tree Analysis (FTA). Techniques like code review, hardware (HW) review, and development audits are usually done at later design stages. To identify both single and multiple faults, it is common to use the FT technique due to the complex interaction of different systems (cf. assistant functions).

Nowadays, for each vehicle configuration, each state, and each SW variant an FT is developed. Therefore, plenty of product FTs with their corresponding MCSs are stored in different documents. A formal model has to be designed to contain all CAP in one framework and to allow the systematic transfer from a function to its safety analysis. Next, we describe the approach of encoding the set of CAP by using an MDD. This MDD, which is called Q, shows the set of all possibilities to develop an architecture for a function without any constraints. An edge connects an attribute of the upper layer with a node on the lower layer and hence encodes all combinations-Cartesian product-of the attribute and the attributes of the node. This in turn means that each path of the structure-from the top layer to the bottom layer-represents one element of Q.

The top layers represent the configuration domains. Each of those contains all corresponding attributes. Next, the architecture properties are given. First, the HW and SW variants are depicted, followed by the input and output of each possible component. Each layer of a HW domain contains all corresponding HW modules. The following layers represent the SW variant domains, the input domains and output domains. The last layers of the MDD encode the state space. Therefore, each layer represents a state domain and every of those contains all corresponding attributes. Furthermore, constraints are necessary to determine all feasible configurations, SW variants, HW modules, and states. For example, to offer piloted driving specific technologies (e.g., specific functions, sensors, cameras etc.) are needed and different safety critical states (vehicle accelerates, lane change etc.) are possible. All constraints of the configuration space, the state space, the architecture space, and the CAPspace, are constructed in a similar way (if-then paradigm). Based on the MDD-representations of Q and the constraints we successively apply the intersection operator to generate the MDD representation of Q named CAP-MDD. A pre-condition of the operation is that the orders of the layers match. During the intersection the constraints are verified with respect to selfconsistency by checking if the resulting set is empty after each intersection task.

As a result of the intersection of Q with the constraints, the number if nodes increases. In order to keep the systematic approach practicable, it is important to investigate the impact of diverse variable ordering methods-cf. ( [10]- [START_REF] Schmiedle | Selection of Efficient Reordering Heuristics for MDD Construction[END_REF])-upon the MDD-based representations of all, the CAP, the PLFT, and the MCS.

With the encoded Q the systematic transfer is initialized. In the following the task for the MDD transfers are introduced.

B. CAP-MDD to PLFT-MDD

The general starting point to construct a Binary Decision Diagram (BDD) representation of a single FT is the Top Level Event (TLE). Given that, a depth-first-search is carried out-by doing so, all gates and events are encoded by the BDD nodes. During this procedure all cyclic dependencies between gates have to be resolved. Finally, each component of the FT is represented by a variable (also: level) of the BDD.

In [START_REF] Xing | Dependability Analysis using Multiple-valued Decision Diagrams[END_REF] an MDD-based analysis of FTs whose components have three states is described-this approach is extended to any number of states in [START_REF] Xing | A New Decision-Diagram-Based Method for Efficient Analysis on Multistate Systems[END_REF]. This idea can also be carried over to systems that might be distinguished by several phases or different fault conditions [START_REF] Mo | MDD-Based Method for Efficient Analysis on Phased-Mission Systems With Multimode Failures[END_REF], [START_REF] Mo | A Multiple-Valued Decision Diagram Based Method for Efficient Reliability Analysis of Non-Repairable Phased-Mission Systems[END_REF]. Moreover, we take this approach and carry it over to the automotive challenges with different CAP. For a specific architecture such as in Figure 2, the input and output properties as well as the corresponding SW variants and HW modules are contained in the CAP-MDD. To generate a FT the inputs of a component are used as basic events and the output as top level event (cf. Figure 2).

Note, a drawn connection can also represent more input and output signals which are transmitted between two components due to SW variants or different configuration strategies. Based on Figure 2 O1. This FT generation process is done for all components with HW modules and many different SW variants in one (sub)-architecture. The complete FT of an architecture can be generated by composing the sub-FTs [START_REF] Kaiser | A New Component Concept for Fault Trees[END_REF]. The PLFT-MDD stores all FTs of each feasible architecture of a function. With a valid PLFT-MDD a MCS-MDD can be generated.

C. PLFT-MDD to MCS-MDD

This approach is an extension of the common identification of the MCSs, which can be directly constructed from a product FT. This extension approach and its application represent a determination of all MCSs of a PLFT [START_REF] Käßmeyer | Product Line Fault Tree Analysis by Means of Multi-valued Decision Diagrams[END_REF].

First, we introduce basic terms and definitions. The BDD representation of a Boolean function is based on Boole's expansion theorem (also: Shannon decomposition):

F (v 1 , ..., v n ) = v i .F vi=1 + v i .F vi=0 (1)
Here F vi=1 and F vi=0 denote the function F with argument v i set to 1 or 0, respectively. This theorem can be extended to the multi-valued case:

F : {1, 2, . . . , s} n → {0, 1} (2)
F (v 1 , . . . , v n ) = (v i = 1).F vi=1 + (v i = 2). F vi=2 + . . . + (v i = s).F vi=s (3)
The assignment of values to F 's variables can be written as minterm 1 . In the Boolean case, the literal v i denotes the assignment v i = 1 and the literal v i denotes the assignment v i = 0.

Considering multi-valued functions, the literal v i,j corresponds to the variable assignment v i = j. Obviously, minterms only contain one literal of each variable. A conjunction term is a set of literals which are exclusively connected by logical 'and' (also: conjunction)-accordingly minterms are special conjunction terms. Conjunction terms yielding F = 1 are called implicants of the function. Implicants that cannot be further reduced are called prime terms. According to [START_REF] Rauzy | Mathematical Foundations of Minimal Cutsets[END_REF] and based on a given set of literals L (also: 'literals of interest'), the set of MCSs of a function F is defined as the set of all prime terms given that all literals l / ∈ L are removed. In static FTs no temporal sequences of faults are considered. Let a static FT 1 A minterm is a product term in which each variable appears once. Boolean functions can be expressed as sum of minterms where each minterm corresponds to a row of the function's truth table whose final value-the function's outputis 1.

and the corresponding Boolean function F be given. According to [START_REF] Rauzy | Binary Decision Diagrams for Reliability Studies[END_REF] and based on the decomposition F = v.F 1 + v.F 0 , the MCS can be derived as follows:

MCS[F ] = MCS 1 ∪ MCS 0 (4) MCS 0 = MCS[F 0 ] (5) MCS 1 = {v.π|π ∈ MCS[F 1 + F 0 ] \ MCS 0 } (6)
The minimal cut set analysis for each FT in the PLFT-MDD is performed. Afterwards the superpositon of each MCSs generates the MCSs-MDD.

The MDD-based MCSs representation allows to efficiently investigate several scenarios: for example the identification of the MCSs w.r.t. CAP-or for given MCSs one might be interested in the configuration, state, or SW variant which are affected. Such queries are based on intersect operations and MDD-based structures encoding the query (for example a specific vehicle configuration).

IV. CONCLUSION AND FUTURE WORK

The automotive state-of-the-art method is to generate for each valid architecture a FT and its corresponding MCS. The novel approach in this paper is more efficient compared to the state-ofthe-art method due to the reason, that all valid architectures of a specific function are analyzed and compared in one iteration and in one data structure approach. Therefore, all different fault propagations of variant-rich and stateful safety-critical functions are determined and stored in one framework. The automatic generation is given due to the fact, that each input is used as basic event and each component has an internal fault. The underlying data structure is given as MDDs which are not only used to encode the fault propagation of all configurations, states, and SW variants of a function but also to represent the corresponding MCSs in one framework. Moreover, the systematic approach how to transfer the function development into a MDD-based safety analysis was explained.

An ongoing work is the development of a formal model which combines the architecture, the configuration, and the state space to transfer the necessary properties in an MDD structure.

In the near future, we will evaluate the presented approach with piloted driving systems. Moreover, following basic analyze options will be evaluated:

• Searching of MCSs for each valid variant and state.

• Identification of all affected variants and states of a function with a given MCS. • Comparison of the MCSs of configurations, SW variants, and states of a safety-critical function, and analysis which cardinal number is equal or not. • Identification of similar or differing safety mechanisms in configurations, SW variants, and states of a function. Based on that, we want to identify metrics to improve our approach, and to measure the impact of change requests affecting the vehicle configuration and feasible states of a function. However, we plan to integrate the MDD analysis approach into an extended model-based safety and variant management framework (cf. [START_REF] Käßmeyer | Evaluation of a systematic approach in variant management for safety-critical systems development[END_REF], [START_REF] Käßmeyer | A Model based Difference Approach and Change Impact Rules Language to manage Variability and Change Requests in Safety Critical Automotive Functions[END_REF]). Finally, in order to keep the approach practicable, we want to investigate the impact of diverse variable ordering methods-cf. [START_REF] Berndt | On the Ordering of Variables of Multi-Valued Decision Diagrams[END_REF], [START_REF] Berndt | Construction Methods for MDD-based State Space Representations of Unstructured Systems[END_REF]-upon the MDD-based representations of both, the PLFT and the MCSs.

Figure 1 .

 1 Figure 1. Systematic transfer of properties within different MDDs

Figure 2 .

 2 Figure 2. Derivation of FTs with an example of component C 3

  the parallel input signals (I1 and I2) are summarized with an OR gate which propagates to the intermediate event If ault. The component by itself is seen as a black box where an internal fault (Internal) can occur. Due to the serial connection of If ault and Internal , the intermediate event If ault and the internal fault Internal is summarized with an OR gate and propagate to the output event (top level event)


Qing Lin

Michel Ferriol

Marianne Cochez

Henri Vahabi
email: henri.vahabi@univ-lorraine.fr

Christelle Vagner

Continuous-fiber-reinforced thermoplastic composites: influence of processing on fire retardant properties

Keywords: thermoplastic composite, acrylate, flame retardancy, processing, thermal degradation

come

INTRODUCTION

A major concern in the aerospace and automotive industry is weight reduction for fuel economy and minimization of greenhouse gases emission. To meet this challenge, composites based on a polymer matrix reinforced by continuous glass or carbon fibers have been developed in recent years [START_REF] Nayak | Composite Materials in Aerospace Applications[END_REF]. Several thermoset matrices have been used: epoxies, phenolics, polyesters and polyimides. Each presents one or more drawbacks, including cost, difficulty in processing and non-recyclability. More recently, high-performance thermoplastic resins have been developed, including polyetherimide (PEI), polyphenylene sulfide (PPS), polyether ketone (PEK) and polyether ether ketone (PEEK). PEEK is highly resistant to thermal degradation, but difficult to process and very expensive [START_REF] Patel | Investigation of the thermal decomposition and flammability of PEEK and its carbon and glass-fibre composites[END_REF][START_REF] Patel | Flammability properties of PEEK and carbon nanotube composites[END_REF].

We have been involved in research whose goal was to develop thermoplastic composites based on easily available and low cost polymers, transformed using the same processes as composite thermosets. Furthermore, to be used in transportation applications, they should exhibit low flammability, heat release and smoke density. From an environmental perspective, they should also be recyclable. As fire retardant compounds are incorporated in the starting monomer, by mixing, the fire behavior can be influenced by the processing method used. The objective of this study was to evaluate the effect of processing method on fire performance properties.

EXPERIMENTAL

The composites were prepared from a liquid acrylic thermoplastic resin, Elium ® , provided by Arkema. In addition to the acrylic monomer, the resin contained a peroxide catalyst to initiate the polymerization and an accelerator agent to activate the peroxide catalyst. The reinforcement fibers were a glass taffetas tissue with a sizing agent compatible with acrylic resin (Chomarat G-Weave 600 P/A). All samples contained 9 layers of fiber glass. The theoretical fiber volume ratio was about 53%. The fire retardants were incorporated in the liquid resin prior to processing and included an aluminum phosphinate, commercially named as Exolit OP930 from Clariant and aluminum trihydroxide (ATH Martinal OL104-IO) from Albemarle Corporation. Three processes were used to obtain composites: (1) liquid resin press molding, (2) prepreg followed by thermocompression and (3) a modification of (2), discussed below. Process 1 consisted of manually impregnating the nine reinforcement layers of woven fiberglass with the filled resin (resin/flame retardant) and polymerizing at room temperature under low pressure (250 ± 50 mbar). A sheet of about 230x300 mm and 4 mm in thickness was prepared. The thickness was based on requirements specified by standard cone calorimeter tests (ISO 5660).

Process 2 was a two-step process. In the first step, a woven fiberglass sheet was manually impregnated with the filled resin. The polymerization was then performed at low pressure (200 mbar) and room temperature. In the second step, the foil was cut into nine sheets stacked and thermocompressed under 15 bars at 200 °C in order to allow the polymer to flow between the layers and to compact and make cohesive material.

Process 3 was similar to process 2, but with some modifications. The nine reinforcement layers, always manually impregnated with the filled resin, were stacked and placed into an anti-adhesive polyimide film to prevent any resin flowing during processing. Then, the polymerization was completed at 80 °C in an hydraulic press under 10 bar pressure.

Prior to investigating the fire behavior, the thermal degradation of the different samples was evaluated by thermogravimetric analysis (TGA) with a Mettler-Toledo TGA/SDTA 851 e under air atmosphere. The sample mass was 30-40 mg and the heating rate was 10°C.min -1 .

All TG curves were drawn using the unreacted mass fraction 1-α given by:

1-α= m t -m ∞ m 0 -m ∞
in which m 0 was the initial sample weight, m t was the residual sample weight at time t and m ∞ was the residual weight at infinite time. The DTG curves were expressed as dα/dt. The dispersion state of flame retardant particles was evaluated using elemental mapping (on 1×1 mm surface of sample) by X-ray fluorescence (XGT-7000 Horiba Jobin-Yvon) and scanning electron microscope/energy-dispersive X-ray spectroscopy (SEM/EDS-Quanta-Feg 200/Genesis 4i). The fire behavior was evaluated using a cone calorimeter FIRE-EU (ISO 5660). The sample size was 100x100x4 mm and the heat flux was 35 kW.m -2 . The cone calorimeter was the most appropriate device to simulate a well ventilated fire scenario [START_REF] Brabauskas | Heat release rate: The single most important variable in fire hazard[END_REF]. Several parameters were simultaneously measured, including heat release rate (HRR), time to ignition (TTI), total heat released (THR), maximum (peak) of heat release rate (pHRR), time of flame-out, mass loss, smoke density, CO and CO 2 amounts. To evaluate the fire properties, pHRR was used as it characterizes the propagation rate of the flame and the spreading of fire [START_REF] Ferriol | Fire retardancy of multiphase polymer systems, chapter 22 in: Handbook of multiphase polymer systems[END_REF]. For each process and fire retardant composition, two experiments were performed. Accuracy is estimated to be around 5% in cone calorimeter tests [START_REF] Hugget | Estimation of Rate of Heat Release by Means of Oxygen Consumption Measurements[END_REF]. The results given were the mean of, at least, two consistent experiments. Limiting Oxygen Index (LOI) tests were carried out using a FTT Company instrument, ISO4589. The dimensions of specimens were 6×10×4 mm. UL-94 vertical burn tests were performed on the samples having a dimension of 100×6.5×4 mm [START_REF]UL-94-Test for Flammability of Plastic Materials for Parts in Devices and Appliances[END_REF].

RESULTS AND DISCUSSION

As the basis of the three forming processes considered in this work is the manual impregnation of the reinforcement tissue with the filled resin, the dispersion state of the fire retardant particles in the composite was checked by X-ray fluorescence and SEM/EDS mapping (based on phosphor), Figure 1 and 2, respectively. These figures give an example of dispersion state for a composite filled with 15 phr (parts per hundred of resin), of Exolit flame retardant. The dispersion of the flame retardants particles (d 50 =2.5 µm) was satisfactory with some aggregates.

Thermal degradation

Regardless the forming process used, the DTG curves of all composites exhibited three peaks corresponding to different steps of degradation. The TG and DTG curves obtained for samples prepared with the three forming processes and containing 15, 20 and 25 phr of OP930 are shown in Figure 3. The recorded DTG peak temperatures for each process and From processes, 1 to 3, the composites appear increasingly more stable as shown by the increasing temperature of each peak (Table 1).

For a given forming process, increasing fire retardant amount should be accompanied by an increased thermal stability and therefore by a significative shift of mass loss curves towards higher temperatures. This is clearly observed for process 3 but not for processes 1 and 2. As shown in Figure 3, for process 1, the curves obtained for 20 and 25 phr are very close (shifted by less than 5 °C at half-degradation (50% mass loss (T50%)) and shifted by 30 °C from the 15 phr curve. In the case of process 2 and for 15 and 20 phr of OP930, the curves are practically merged and for 25 phr, a shift of about 5 °C was observed at half-degradation. For process 3, at half-degradation, the mass loss curves are shifted by 9 °C for 20 phr towards 15 phr and 16 °C for 25 phr towards 20 phr. To explain the relative positions of the observed TG and DTG curves when the fire retardant amount increased, one can suppose that the sample preparation for TG analysis affected the results when a small part (30-40 mg) of the composite is cut in the bulk sample. Therefore, the homogeneity and composition of resin/fiber could be different in a small sample than in the composite. It was also observed in the DTG curves for process 3 that the loading of 25 phr of OP930 influenced the first step of degradation compared to the other processes and loading percentages.

Cone calorimeter tests

Table 2 gives the values of pHRR, THR and TTI measured for each forming process and for the different OP930 compositions. Figure 4 gives the corresponding HRR curves. It appears that samples obtained by process 1 have the lowest total heat released (THR) and the highest time to ignition (TTI) whereas it is practically the same for samples prepared by processes 2 or 3. Considering the procedure used in process 1, one can assume that the low pressure applied during the polymerization step results in some evaporation of the monomer, according to the vapor pressure of parent acrylic monomers [START_REF] Lide | CRC Handbook of Thermophysical and Thermochemical Properties[END_REF], leading to a concentration of the fire retardant (non-volatile) in the polymerized material. Then, the samples obtained from process 1 should be more concentrated in OP930 than the samples produced by process 2 or 3. Consequently, they are thermally more stable and therefore, ignition would be delayed. Since they would also contain less combustible material, the released heat would be lower. These two facts were experimentally observed (Table 2). For process 2, the shape of all curves in Figure 4 is different than those obtained for the two other processes. Several peaks can be seen, meaning successive extinctions and re-ignitions after the first ignition. This behavior can be interpreted by considering a delamination of the different layers under the action of heat and the formation of cavities of combustible gases between them, abruptly released as the combustion advances through the sample.

This would permit succession of ignitions and partial extinctions. In these conditions, the HRR curves present several peaks as confirmed in the literature [START_REF] Schartel | Development of fire-retarded materials-Interpretation of cone calorimeter data[END_REF]. This drawback does not exist in process 3 as the process ensures a good interpenetration of macromolecular chains between the reinforcement layers and good cohesion of the composite. The composites obtained with this process demonstrate an improved fire performance than those produced with process 2, but slightly worse than those prepared with process 1. This result is logical as those obtained for samples produced with process 1 were overestimated due to the evaporation of the resin during processing.

The forming process 3 resolved the encountered problems including loss of material by evaporation (process 1), lack of homogeneity and lack of densification of the different layers (process 2). It allowed production of reliable samples for deeper investigation of their fire behavior.

Improvement of fire behavior

The best forming process being designed (process 3), and the composite containing 20 phr of OP930 exhibiting the best results in the cone calorimeter test, we focused on improving the fire performance of this composite by considering three options:

(1) adding aluminum trihydroxide (ATH), which has been shown to improve the fire retardant properties of PMMA, an acrylate polymer of the same family as that investigated during this work [START_REF] Bundersek | Influence of Al(OH) 3 nanoparticles on the mechanical and fire resistance properties of poly(methyl methacrylate) nanocomposites[END_REF].

(2) addition of 2 phr of dibutylmaleate (DBMA), a cross-linking agent, to improve the thermal stability as previously reported in the literature for a similar polymer and crosslinking agent (PMMA/2 phr of divinylbenzene) [START_REF] Uhl | The thermal stability of cross-linked polymers: methyl methacrylate with divinylbenzene and styrene with dimethacrylates[END_REF].

(3) after manufacturing, heating of the processed samples to 200 °C for 30 minutes to complete the polymerization reaction.

The loading amount was fixed at 20 phr after LOI and vertical UL-94 tests of different OP930/ATH compositions. These results are summarized in Table 3. The best result was obtained by combining 30 phr OP930 and 10 phr of ATH. However because of cost considerations (OP930 is more expensive than ATH), the loading amount of 20 phr OP930 and 20 phr of ATH was selected. Furthermore, this loading also allowed us to keep a ratio of 2 between aluminum and phosphorus which corresponds to the best results in terms of fire retardancy, as reported by Duquesne et al. [START_REF] Duquesne | Study of the thermal degradation of an aluminium phosphinate-aluminium trihydrate combination[END_REF].

CONCLUSION

In this study, three different forming processes were used to prepare samples of acrylate resin/taffetas/OP930. The results got with the cone calorimeter test made it possible to identify the disadvantages of each process and to select the best one: process 3. Results showed that fire behavior was improved by adding ATH and post-curing of the composites contrary to the addition of the cross-linking agent (DBMA) which did not bring significant effect. These results will be useful to define an automated process leading to an optimized fire behavior of industrial parts.

Fig 1 .

 1 Fig 1. Image obtained by X-ray Fluorescence mapping.

Fig 2 .

 2 Fig 2. SEM (a,b,c) and EDS mapping images.

Fig 3 .

 3 Fig 3. TG and DTG curves for all samples obtained with the three forming processes (left: TG curves, right: corresponding DTG curves).

Fig 4 .

 4 Fig 4. Comparison of HRR curves for the three forming processes.

Fig 5 .

 5 Fig 5. Comparison of cone calorimeter results for samples involving ATH, DBMA and post-curing.

Table 1 .

 1 Temperatures of DTG peaks for each forming process.

	Process	Peak 1 (°C)	Peak 2 (°C)	Peak 3 (°C)
	1	290	370	410
	2	300-310	380	412-423
	3	316	389	430

Table 2 .

 2 Cone calorimeter results for each forming process These results are the mean of two values, obtained from two tests on each sample.

		OP930 amount (phr)	pHRR (kW.m -2 )* THR (MJ.m -2 )* TTI (s)*
		15	190	31	56
	Process 1	20 25	155 158	18 24	76 75
		15	315	45	34
	Process 2	20 25	267 228	47 63	48 50
		15	169	37	42
	Process 3	20 25	157 159	31 39	45 42
	*

Table 3 .

 3 LOI and UL-94 results for composites obtained by process 3 and containing OP930 and ATH.

	Flame retardant (phr)
			LOI (%) UL-94
	OP930	ATH
	25	0	45	V-1
	15	10	43	V-1
	10	15	36	NC*
	0	25	25	NC
	40	0	48	V-1
	30	10	53	V-1
	20	20	45	V-1
	10	30	38	NC
	0	40	27	NC
	* NC: Not Classified

Table 4

 4 gives the different combinations studied by cone calorimetry. Table5and Figure5summarize the results. They show that the addition of ATH, alone and without post-curing,

	results in the reduction of pHRR by 13% and for THR by 26%, which confirms the positive
	influence of this fire retardant for acrylate-based polymers. In all cases with no DBMA
	addition, the results indicated that post-curing allowed further improvement of the fire
	behavior: pHRR was additionally decreased by 7 % whereas TTI increased from 50 to 59 s
	but THR remains unchanged. With the addition of DBMA, time to ignition increased from
	50 to 68 and 74 s (36 % and 48 %) without and with post-curing. This confirmed the
	increased thermal stability of the polymer when a cross-linking agent was added before
	polymerization. Regarding the accuracy on pHRR value (10%), there was no
	supplementary effect from the cross-linking agent. With post-curing, it increased from 127
	to 150 kW.m -2 (18 %) and without post-curing, it increased from 136 to 154 kW.m -2 (13

%). At the same time, the total heat released increased from 23 to 27 MJ.m -2 (17 %) without post-curing and when post-curing was performed, THR increased from 24 to 28 MJ.m -2 (17 %). This can be interpreted by considering that DBMA promotes the combustion of the acrylate-based polymers.

Table 4 .

 4 Composition of the different combinations studied involving ATH, DBMA and postcuring.

		Loading amount (phr)	Post-curing
	OP930	ATH	DBMA
	20	20	0	Yes
	20	20	0	No
	20	20	2	Yes
	20	20	2	No

Table 5 .

 5 Cone calorimeter results for samples with ATH, DBMA and post-curing. These results are the mean of two values, obtained from two tests on each sample.

	OP930/ATH/DBMA (phr)	Post-curing	pHRR* (kW.m -2 )	THR* (MJ.m -2 )	TTI (s)*
	20 / 0 / 0	No	157	31	45
	20 / 20 / 0	No	136	23	50
	20 / 20 / 2	No	154	27	68
	20 / 20 / 0	Yes	127	24	59
	20 / 20 / 2	Yes	150	28	74
	*

ACKNOWLEDGMENTS

The authors want to thank PPE (Pôle de Plasturgie de l'Est, Saint-Avold, France) for the manufacturing of composites and the Région Lorraine for financial support in the frame of the "Résines idéales" collaborative research program.


Florian Leitner-Fischer
email: florian.leitner-fischer@zf.com

Stefan Leue
email: stefan.leue@uni-konstanz.de

Sirui Liu
email: sirui.liu@uni-konstanz.de

Automated Freedom from Interference Analysis for Automotive Software

Freedom from Interference for automotive software systems developed according to the ISO 26262 standard means that a fault in a less safety critical software component will not lead to a fault in a more safety critical component. It is an important concern in the realm of functional safety for automotive systems. We present an automated method for the analysis of concurrency-related interferences based on the QuantUM approach and tool that we have previously developed. We illustrate the proposed analysis using the case study of an airbag system.

I. INTRODUCTION

The identification of interferences amongst system components is an important aspect in safety analysis. It contributes to fault containment and avoidance by ensuring that a fault in one system component does not lead to a fault in another component.

When considering software driven embedded systems, such as automotive ECUs, interference can happen at various levels. The software of one component can access and manipulate another component by writing faulty data into the memory allocated to the other component (data flow). One component can even change the control of another component by manipulating the runtime stack (control flow interference). Finally, one component can stop to send information to another component, or even worse, it can send faulty information to another component (message flow, byzantine faults). When considering concurrently executing software components, the faulty behavior of one component may cause the system to go into a deadlock. Likewise, one component executing with high priority may starve other components at lower priorities. This is particularly damaging if the higher priority component goes into a livelock that is not preempted by the operating system scheduler. Finally, various damaging scenarios can occur if the execution of a task in a component leads to exceeding real-time bounds in another component.

The investigation of these types of interference is of particular importance in the safety analysis of safety-critical automotive software. The standard ISO 26262 [START_REF] Iso | Road vehicles -functional safety[END_REF] defines various Automotive Safety Integrity Levels (ASILs) for different safety-critical functions implemented in an automobile, ranging from A to D, with ASIL D being the ASIL that corresponds to the highest criticality. ISO 26262 defines freedom from interference (FFI) as the "absence of cascading failures between components that could lead to the violation of [some] safety requirement" (c.f. part 6 of [START_REF] Iso | Road vehicles -functional safety[END_REF]).

Special interest in establishing FFI for automotive systems developed according to 26262 is motivated by the fact that the standard allows functions assessed at a higher ASIL level to be implemented by redundant functions developed according to development methods applicable to lower ASIL levels, provided there is no interference and dependence amongst these lower level implemented functions. This is referred to as "ASIL decomposition". Performing ASIL decomposition is attractive since the development process requirements that 26262 imposes on lower criticality ASILs are lower than on higher level ASILs. This has a significant impact on the overall development cost of some function: the total development cost for n redundant lower ASIL components may be less than the cost for developing one high ASIL component, while still ensuring high dependability of the resulting system.

Various techniques can be employed that will ensure FFI. Most prominent in this regard is the use of Memory Protection Units (MPUs) which ensure at run-time that a software task is only accessing memory that was allocated to it. Contrary to this approach, we are proposing a design-time analysis method that allows the designer to avoid certain types of interference before the product is manufactured and put into operation.

In light of ever increasing system complexity, manual analysis methods to ensure FFI will not succeed in the long run. Testing is not applicable, since the concurrency-related interference problems such as deadlock and livelock that we will focus on in this paper cannot be effectively tested. Also, testing is incomplete, making it a questionable method in functional safety analysis. We therefore propose an automated, algorithmic analysis method to establish the absence of interferences based on the formal methods of model-and causality checking [START_REF] Baier | Principles of model checking[END_REF], [START_REF] Leitner-Fischer | Causality checking for complex system models[END_REF]. The analysis is based on our previously developed QuantUM approach and tool. By this approach we are able to directly access architecture-level SysML / UML models given by some industry-strength modeling tool, such as IBM Rational Rhapsody, and analyze these models for interference violations without the need for user intervention. We show how to capture FFI analysis in this setting and how to perform the analysis. We illustrate our approach using a case study and discuss future developments.

Related Work: We are not aware of any comparable, formal methods based FFI analysis method that focuses on concurrency faults.

II. PRELIMINARIES

A. The QuantUM Approach

In precursory work [START_REF]Quantum: Quantitative safety analysis of UML models[END_REF], [START_REF]Probabilistic fault tree synthesis using causality computation[END_REF], [START_REF] Leitner-Fischer | Causality checking for complex system models[END_REF] we have proposed the QuantUM approach to support the automated, algorithmic functional safety analysis of critical system architectures. QuantUM analyses are based on SysML [START_REF] Omg | Omg systems modeling language[END_REF] system architecture models. Designers will provide models for the structure (block definition diagrams, internal block diagrams) as well as the normal and the fault behavior in the form of SysML StateChart diagrams. We provide an extension to SysML in the form of a stereotype that allows the designer, amongst other things, to distinguish normal and faulty behavior and to specify failure rates for individual architectural blocks. The thus extended SysML models are edited in a SysML tool, such as IBM Rational Rhapsody, and their XMI representation is then parsed and input by the prototypical QuantUM 1 tool that we have developed. QuantUM uses various model checking [START_REF] Baier | Principles of model checking[END_REF] tools in order to perform a causality analysis, that we refer to as causality checking [START_REF] Leitner-Fischer | Causality checking for complex system models[END_REF], in order to compute ordered sequences of events that lead to the violation of a safety goal. Model checking is an automated, algorithmic technique to systematically explore the state space of the system, i.e., all possible configurations of the system, in order to discover the reachability of undesired system states. We have performed various large-scale case studies using this tool suite [START_REF] Leitner-Fischer | Spincause: a tool for causality checking[END_REF].

B. FFI According to ISO 26262

Space limitations will not permit us to fully explore the intricate relationships of cascading faults, interference and independence in ISO 26262. The informative Annex D of part 6 of ISO 26262 lists in clause D.2.2 ("Timing and Execution") the following types of faults to be considered for software elements considered in each software partition: a) blocking of execution, b) deadlocks, c) livelocks, d) incorrect allocation of execution time and e) incorrect synchronization between software elements. The notion of concurrency does not occur in this context, and no examples for these faults are given, but we assume that fault types b), c) and e) are directly related to concurrency issues. Fault type e) probably refers to what is typically considered to be race conditions in concurrent systems. The technology of model and causality checking that we employ in our approach is very well suited for the analysis of these types of concurrency problems, which is why we will focus on this important aspect of FFI analysis. Notice that according to part 8 of ISO 26262, clause 9.4.1.1, model checking is an admissible method for verification. 1 https://se.uni-konstanz.de/research1/quantum/ III. FFI ANALYSIS USING QUANTUM

The FFI analysis method that we propose in this paper will focus on concurrency issues that potentially entail cascading faults. The analysis will involve the following steps:

1) System Modeling: The normal behavior of every system component will be modeled in SysML using state machine diagrams. Emphasis should be put on modeling the chain of data transfer and communication between components in a system. 2) Fault Seeding: This step involves identifying system components that are involved in the occurrence of a concurrency fault. The considered fault needs to be seeded in the model which involves modifying the previously obtained system model. 3) Fault State Identification & QuantUM Tagging: A state of the overall system needs to be identified that corresponds to a violation of the safety goal of the system. Using the QuantUM provided stereotype the system components that the analysis is supposed to consider will be tagged. At the same time, the normal and the failure behavior will be identified. 4) QuantUM FFI Analysis: The subsequent analysis of the model using the QuantUM tool is fully automatic. The result will be a fault tree displaying ordered sequences of events that are causal for the occurrence of the identified concurrency issue. 5) Result Interpretation: The final step will be an interpretation of the obtained result. This is of course to some extent specific to the property that is to be analyzed, but in principle proceeds as follows: If an event of a component with lower ASIL occurs in the ordered set of causal events prior to an event with higher ASIL, this is an indication for an interference.

IV. CASE STUDY A. Background

On the one hand, a deadlocks within a component causes interference on other components that depend on that locked component, it may remain questionable whether an interference analysis is necessary for deadlocks or livelocks. Deadlocks and livelocks are caused by software errors and consequently, according to the ISO 26262 philosophy, they could be detected and corrected at software design time. In fact, tools and techniques exist to discover possible deadlocks in a design model of a software system [START_REF] Holzmann | The SPIN Model Checker: Primer and Reference Manual[END_REF]. It is hence questionable whether these errors should be subject to FFI analysis at all. On the other hand, we assume that, in real world scenarios, the system is not free from software errors. Deadlocks and livelocks then will still exist in the system, so it still remains our interest to find out whether potential errors of this kind in subsystems can be source of a violation of FFI.

We consider the abstract architecture of an Airbag Control Unit. We are interested in analyzing what impact the failure of two redundant decision paths executing on one micro controller has on achieving the safety goal of the overall system. The system safety goal is to avoid unintended deployment, i.e., the case where no crash occurs but the airbag is deployed.If such an impact can be proven, we have shown the presence of a cascading failure, which implies interference. Since the QuantUM analysis that we perform is complete, which means that all possible system executions will be explored, we can infer from the absence of such an impact that FFI holds for the considered safety goal, concurrency fault and system model. Notice that the two decision paths could be the result of some ASIL decomposition, which would be justified in case our analysis proved FFI.

Prior to performing this case study, we carried out an analysis of the interference that could be caused by the subsystem consisting of the two decision paths going into a mutual deadlock. Although the result seems to be trivial, given that a (sub-)system is not able to perform any operations when all its components are in a deadlock, we were able to show this behavior analytically using QuantUM analysis as follows. We modeled the normal behavior pattern of the system in such a way that it was impossible for the two decision paths to end up in a deadlock, as well as a failure pattern, where the system will surely end up in a deadlock. The resulting fault tree with the deployment of the airbag as top level event did only show events of the normal operation, no events in the failure pattern were found in the fault tree, which indicates that a behavior pattern where all the deciding components will surely end up in a deadlock can not lead to a deployment of the airbag. On the other hand, by removing the normal behavior pattern, it was not possible to deploy the airbag. This analysis gave us an demonstration on how QuantUM can show us that the first safety goal is not violated by a deadlock of the two decision paths. Knowing that a deadlock will not lead to a deployment, the next question was whether we can introduce a safety mechanism that ensures the second safety goal that the airbag should deploy when a crash occurs. In this case study, we adapt the behavior pattern of the two decision paths in such a way that they can lead to a deadlock and introduce a watchdog module that detects whether the two decision paths are currently in a deadlock condition, resetting them if necessary.

B. Freedom From Interference Analysis

1) System Modeling: We begin by modeling the normal behavior of the decision paths and consider the main path in our description. The "safing" path would be modeled in a similar fashion. As shown in Figure 1, upper part, the behavior of the decision path is such that by default at the system start the decision path goes to the idle state. When a crash is detected, the considered decision path checks whether the other decision path also detected a crash. No matter whether there is a response from the other path, or what that response is, a deploy signal is sent out. Benefits at this level of abstraction is that we do not need to consider modeling the communication between the two decision paths since it does not have an influence on the emission of the deploy signal. In a real implementation the response from the other decision path could for instance be used to log an error in case not both decision paths compute the same result. 2) Fault Seeding: We continue by seeding a deadlock into the model. In a real design situation this may, for instance, be caused by a coding error. As seen in Figure 1, lower part, similar to the normal behavior the decision path enters the idle state when the system starts. In the idle state, there are two possibilities. First, after a crash is detected, the considered decision path enters the state where it communicates with the other decision path. The difference to the non-seeded model is that the decision path cannot proceed with its computation until it received a response from the other decision path containing information about whether it also detected a crash. When both decision paths enter this state, a circular wait emerges between them, which indicates a deadlock between the two decision paths. Second, the considered decision path may receive a signal requesting a "crash detected" response from the other decision path (refer to the first possibility). In this case, the decision path that received the request, enters the response state. In this state, it sends out a response message, containing information about whether it also detected a crash, to the other decision path.

Knowing that there is a seeded interference error present, we want to check whether there is a way to deploy the airbag with the introduced safety mechanism. To check this, we model the behavior of the airbag. As shown in Figure 2, the airbag can enter a ready state when one decision path sends out a deploy signal. It must receive a deploy signal from the other decision path to actually deploy.

A watchdog (Figure 3) will monitor the two decision paths. Since we know that there is a deadlock deliberately seeded in our model, we only need the watchdog to check whether our system entered the state where the two decision paths are in the seeded deadlock state and reset the two decision paths if necessary. 3) Fault State Identification & QuantUM Tagging: It has to be determined which state of the overall system we want to analyze. We choose this state according to the safety requirements of the system. In this case, it is the deploy state of the airbag module, which is shown in Figure 2. Consequently, we annotate the airbag deploy state in the airbag module as a critical state, and pass the annotated model in XMI format to the QuantUM tool.

4) QuantUM FFI Analysis: QuantUM analyzes the SysML model and returns the fault tree depicted in Figure 4. The analysis took about one minute of execution time on a computer with a Core 2 Duo CPU@2.26GHz and 4GB RAM.

5) Result Interpretation:

The QuantUM tool automatically generates fault trees that visualize ordered sequences of events that are causal for the occurrence of a top level event. We slightly abuse the fault tree formalism here in order to visualize causal events that lead to the top level event representing the deployment of the airbag, which does of course not correspond to a hazard but to an event whose occurrence illustrates the satisfaction of the safety goal that we pursue. The fault tree, which is reproduced in Figure 4, shows that there are two situations that can lead to an airbag deployment. First, the left part of the fault tree shows a sequence of exclusively normal operation events, this indicates that the airbag can deploy when functioning normally. Secondly, the right part of the fault tree shows a sequence of the two decision paths going into a mutual deadlock which is then reset by the watchdog. After the reset, a sequence of normal operations follows, leading into the airbag deploy state, which corresponds to the top level event of the fault tree. From this we conclude that the watchdog we introduced ensures deployment of the airbag even though a deadlock was present. Hence, we have shown the effectiveness of the introduced safety mechanism.

V. CONCLUSION

We have presented an automated approach to FFI analysis based on the QuantUM analysis method and tool that we have previously developed. We have applied this approach to FFI analysis of a Airbag Control Unit case study. We have shown that the technology that we have used, in particular model and causality checking, are suited to analyze FFI for concurrencyrelated faults, such as deadlock. Future research will address the question how to automate the fault seeding, so that the analysis can be performed fully automatically. A further objective will be to incorporate the analysis into standard system and safety design processes. It is our impression that more discussion in the ISO 26262 standardization body is required in order to clearly define and characterize the fault types that are to be considered with respect to FFI, in particular as far as clauses D.2.2 and D.2.4 of part 6 of the standard are concerned. We see great potential in using formal methods to characterize these properties and to provide automated, formal methods based FFI analyses for them.

Fig. 1 .

 1 Fig. 1. Behavior of the System

Fig. 2 .Fig. 3 .

 23 Fig. 2. Behavior of the Airbag

Fig. 4 .

 4 Fig. 4. Fault Tree of the deployment of the Airbag


Harold " Bud
email: bud@lawson.se

" Lawson

Saad Mubeen
email: saad.mubeen@mdh.se

Alessio Bucaioni
email: alessio.bucaioni@mdh.se

Jukka Mäki-Turja
email: jukka.maki-turja@mdh.se

John Lundbäck
email: john.lundback@arcticus-systems.com

Mattias Gålnander
email: mattias.galnander@arcticus-systems.com

Kurt-Lennart Lundbäck
email: kurt.lundback@arcticus-systems.com

Mikael Sjödin
email: mikael.sjodin@mdh.se

Provisioning of Deterministic and Non-Deterministic Services for Vehicles: The Rubus Approach

Abstract-Providing computer-based services for vehicle functions has evolved to the point where a large majority of functions are realized by software. However, the need to provide safety and security in critical functions such as braking, steering, motor control, etc. requires an approach that can guarantee the continuous reliable operation of the functions. At the same time, there are a variety of functions that are less critical from the vehicle operation perspective that can be provided where safety and security are less critical. From a vehicle manufacturers point of view, providing both types of services in an economic and reliable manner is a real challenge. To meet this challenge, we consider the Rubus Tool Suit for the software development and a well-proven (in industrial use for over twenty years) and certified (according to ISO 26262) operating system Kernel for its execution. In addition, a user-friendly approach to modeland component-based development concept called the software circuits has provided an approach to meet the demands of both safety-critical deterministic and as well as non-safety critical non-deterministic services. In this paper, a brief history of the evolution of Rubus approach as well as an overview of the driving concepts used in providing the Rubus products are described.

I. HISTORY AND EVOLUTION OF RUBUS

Arcticus Systems AB was established as a Swedish corporation in 1985. The Rubus 1 Kernel was introduced for industrial use in 1996. The concepts utilized in Rubus evolved from previous experiences with Arcticus and earlier product OTool as well as their participation in the Swedish Development Agency (NUTEK) VIA (Vehicle Internal Architecture) project during 1992-95. The partners in the project included, in addition to Arcticus, Saab Automotive, Volvo, Mecel AB, SICS, Uppsala University, Chalmers University and Lawson Konsult AB.

Earlier experiences with time-driven deterministic execution in Automatic Train Control (ATC) were used as a primary input to the VIA project. Harold "Bud" Lawson was the architect of the on-board system provided by ITT Standard Radio to the Swedish Railways (SJ). This product was developed during the 1 Rubus (the name of a red arctic berry and a registered trademark of Arcticus AB) latter part of the 1970s and has been installed in the majority of locomotives in Sweden starting in 1981. The program code was surprisingly minimal due to the utilization of the hardware like paradigm used in its development (became known as Software Circuits (SWC)). The time determinism and the small amount of program code led to significant advantages in exhaustive testing and verification of the production units. The results of this product development have been reported in [START_REF] Lawson | Twenty years of safe train control in sweden[END_REF], [START_REF]Keynote address: Provisioning of safe train control in nordic countries[END_REF], [START_REF] Lawson | Journey through the systems landscape[END_REF].

The VIA project identified the need for a mix of timedriven (became known as Red) and event-driven (became known as Blue) real-time tasks. As a central part of the VIA project, the Rubus Kernel was developed to support a mix of both forms of real-time application tasks. Red application tasks are scheduled periodically and have guaranteed execution time slots (deterministic). Blue application tasks are executed within residual time in the time slots (non-deterministic). The VIA project based on the use of the Rubus Kernel and a proposed time deterministic network communication defined a distributed real-time infrastructure for vehicles called BASEMENT. The results of the project where reported in two articles [START_REF] Hansson | Basement: A distributed real-time architecture for vehicle applications[END_REF], [START_REF] Hansson | Basement: an architecture and methodology for distributed automotive real-time systems[END_REF].

Arcticus established an agreement with Mälardalen University in 1997 and further research and development led to the development of an off-line scheduler by Christer Norström (formerly Eriksson) now CEO at SICS (Swedish Institute for Computer Science) and Kristian Sandström [START_REF] Eriksson | A real-time kernel integrated with an off-line scheduler[END_REF]. This effort formed the basis for the eventual Model Driven Development (MDD) product.

A major breakthrough for Arcticus in 1996 was the selection of the Rubus Kernel, as the real-time operating system, for the implementation of a Limited Slip Coupling Device (for four wheel drive vehicles) by Haldex in Landskrona (now owned by BorgWarner Torq Transfer Systems). After several prototype iterations the first LSCD was delivered to Volkswagen. Since then it has evolved into a significant product that is utilized in most of all four-wheel drive vehicles in the world.

In 1997, both Volvo Construction Equipment (VCE) in Eskilstuna and BAE Hägglunds in Örnsköldsvik decided to deploy the Rubus Kernel in their products. These customers' active cooperation with Arcticus led to the development and deployment of the MDD products (Rubus tool suite).

VCE has deployed the Rubus Kernel in several of its products and the Kernel has been certified, in 2015, according to the international standard ISO 26262:2011 with respect to ASIL D (Road Vehicles Functional Safety). As a part of this certification, Arcticus has developed its Quality Management System (QMS) based upon ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207 on Systems, respective Software Life Cycle Processes.

As a result of the long-term cooperation between Arcticus and Lawson Konsult AB, an article describing their contributions to Highly Reliable Real-Time Systems was presented at the 3rd Nordic Conference on Computing [START_REF] Lawson | Provisioning of highly reliable realtime systems[END_REF].

The cooperation between Arcticus and Mälardalen University has continued and is on going where both faculty members and doctoral students have made significant contributions to the Rubus tool suite. In addition to the on-line scheduler, improvements to component models [START_REF] Hänninen | The Rubus Component Model for Resource Constrained Real-Time Systems[END_REF], [START_REF] Mubeen | Communications-Oriented Development of Component-Based Vehicular Distributed Real-Time Embedded Systems[END_REF], shared stack analysis [START_REF] Bohlin | Bounding shared-stack usage in systems with offsets and precedences[END_REF], response-time analysis of singe-node (uniprocessor) systems [START_REF] Mäki-Turja | Tighter response-times for tasks with offsets[END_REF], response-time analysis of Controller Area Network and its higher-level protocols [START_REF] Mubeen | Integrating Mixed Transmission and Practical Limitations with the Worst-Case Response-Time Analysis for Controller Area Network[END_REF], end-to-end response time and delay analysis for distributed systems [START_REF] Mubeen | Support for end-to-end response-time and delay analysis in the industrial tool suite: Issues, experiences and a case study[END_REF] and worst-case execution analysis. In order to better support interoperability between Rubus and other related models and languages such as EAST-ADL [START_REF]EAST-ADL Domain Model Specification[END_REF], metal-model of the Rubus Component Model (RCM) has been formally defined [START_REF] Bucaioni | Towards a metamodel for the rubus component model[END_REF]. In addition, model-based techniques have been employed for realizing a model-based design exploration methodology for easing the transition between the EAST-ADL and the RCM [START_REF] Bucaioni | Anticipating implementation-level timing analysis for driving design-level decisions in east-adl[END_REF], [START_REF] Bucaioni | Handling uncertainty in automatically generated implementation models in the automotive domain[END_REF].

II. DRIVING CONCEPTS

Based upon the evolution of Arcticus products, the following central concepts have evolved.

A. Software Circuits

A hardware analogy where component data and control flow behave as a chain of circuits. This promotes the analysis and verification of application function timing constraints and resource utilization that is accomplished by clearly separating data and control flow mechanisms in a network of software circuits. The model of a software circuit is shown in Fig. 1. It is the basic building block and the lowest-level hierarchical element in RCM.

accomplished by clearly separating data and control flow mechanisms in a network of software circuits. The model of a software circuit is shown in Figure 1. The Construct and Destruct logic are terms from the objectoriented languages that describe activation, respectively, deactivation of the circuit.

B. Model Driven Development

MDD has had an increasingly important role in designing and implementing real-time embedded systems. Due to the complexity of real-time systems, the development must rely more and more upon automation and the interoperability amongst models such as Simulink. The Rubus Tool Suite provides an integrated tool-chain that includes system modelling, design, analysis and synthesis providing the features portrayed in Fig. 2. The three models provide various viewpoints reflecting all of the necessary information concerning the development, analysis, synthesis and execution of real-time applications.

Rubus Model

• Rubus Component Model (RCM) -Viewpoint of the developer/development team model: The developer designs the system, in a platform independent manner that focuses upon the application. Timing and resource constraints are expressed in the model.

• Rubus Analysis Model (RAM) -Viewpoint of the analysis model: The resulting RCM design is formal and lends itself to static analysis that is mapped to the actual run-time platform. The analysis includes type checking, execution order, real-time requirements such as response times and worst-case execution times. This analysis helps in reducing late, costly and time-consuming testing efforts of, e.g., temporal errors. Furthermore, mathematical models and supporting tools provide formal evidence of fulfilling requirements.

Using the Rubus analysis engines it is possible to timing analyze the system at various levels. For example, a single node is analyzed by calculating the response times of tasks and comparing them with corresponding deadlines. The analysis engines also support the analysis of endto-end delays (such as Data Reaction and Age) for distributed systems (see Fig. 3). The analysis is based on Confidential/proprietary information of Arcticus Systems AB is contained herein and may not be disclosed, displayed, used reproduced or copied without prior written consent. Failure to comply with this notice may result in liability for costs, damages or losses.

© 2015, Arcticus Systems AB. All rights reserved. Rubus® is a registered trademark of Arcticus Systems. Rubus Inspector provides for platform independent formal and semi-formal "Model in the Loop" testing environment used to test the Software Circuits of the Rubus Component Model (RCM). It provides for unit testing as well as for sub-system or complete system testing. Test inputs are provided by the user however, it is also possible to generate tests that utilize LabView/Simulink and Matlab environments.

Rubus Analyser provides for the user-friendly presentation of off-line and on-line information about the real time execution behavior of the system. It enables connection with the development host system to download information such as trace data and run-time information in real-time. Post-run-time analysis of host data for formal analysis can be compared with the original model data to verify the real-time properties initially set by the designer.

The Rubus RTOS Product

While the Rubus Component Model developed utilizing Rubus Tool Suite is platform independent, Arcticus supplies the Rubus RTOS that has been utilized in a wide variety of real-time applications.

Rubus Kernel that is integrated with the application software and further integrated into the customers products.

Rubus Simulator that provides for testing and verifying the composite of the Rubus Kernel and application software. advanced data path analysis algorithms and supports multiple networks, black box nodes (whose internal software architectures are not available), message interference and redundant data paths [START_REF] Mubeen | Support for end-to-end response-time and delay analysis in the industrial tool suite: Issues, experiences and a case study[END_REF], [START_REF] Mubeen | Integrating Mixed Transmission and Practical Limitations with the Worst-Case Response-Time Analysis for Controller Area Network[END_REF], [START_REF] Mubeen | End-to-end Timing Analysis of Black-box Models in Legacy Vehicular Distributed Embedded Systems[END_REF].

• Rubus Run-time Model (RRM) -Viewpoint of the runtime platform model: The RCM design together with the RAM analysis is utilized to synthesize the code for the actual run-time platform. This automated synthesis prevents error-prone and costly integration errors. The run-time platform may be the Rubus Kernel or some other Real Time Operating System.

C. Certified Real-time Operating System

. The Rubus Real Time Operating System (RTOS) provides support for RCM in achieving an optimized real-time software system. The Rubus RTOS has been utilized in a wide variety of real-time applications. The main features of the Rubus RTOS are as follows:

• it supports the execution of time-triggered threads also called the Red threads; • it supports the execution of interrupt-triggered threads also called the Green threads; • it supports the execution of event-triggered threads also called the Blue threads; • it supports communication between different types of threads; • it supports static allocation of resources;

• and it supports scalability and portability. The combination of a dynamic and static scheduling supported by the Rubus Kernel enables the design of optimized real-time software systems. The Rubus Kernel can be ported to various targets and development environments on customer's request and includes, amongst others, Freescale MPCprocessors, Texas DSP, Infineons xc167-processors and various C-compiler environments such as Green Hills, WindRiver, Tasking, Microsoft VS and, GCC.

It is important to note that the Rubus Kernel has been approved as a certifiable ASIL D out of context element for realtime systems according to the automotive ISO 26262 standard (Road vehicle Functional Safety). There is an ongoing project to certify the Rubus Tool Suite according to this standard.

These concepts have proven to be effective in providing scalability from small to large real-time applications im-plemented by various organizations including Haldex, Borg Warner, Volvo Construction Equipment and BAE Systems (Hägglunds).

III. RELATED MODELS AND TOOLS

There are several technologies and frameworks that support model-and component-based software development of embedded systems such as AADL [START_REF] Feiler | An Overview of the SAE Architecture Analysis & Design Language (AADL) Standard: A Basis for Model-Based Architecture-Driven Embedded Systems Engineering[END_REF], SCADE [START_REF]SCADE Suite[END_REF], MARTE [START_REF]The UML Profile for MARTE: Modeling and Analysis of Real-Time and Embedded Systems[END_REF], MAST [START_REF]MAST-Modeling and Analysis Suite for Real-Time Applications[END_REF], SysML, just to name a few. This paper targets the vehicular domain where the main focus is on EAST-ADL and EAST-ADL-like models for functional modeling and on AUTOSAR [START_REF]AUTOSAR Techincal Overview[END_REF] and Rubus for execution modeling. Fig. 4 shows some of the models, approaches and tools that are used at four different abstraction levels defined by the EAST-ADL methodology. A detailed comparison of Rubus with several other models and tools is presented in [START_REF] Mubeen | Communications-Oriented Development of Component-Based Vehicular Distributed Real-Time Embedded Systems[END_REF]. It is important to note that with the implementation of some recent research results in Rubus Tool Suite, identified by ComSIS 2013 [START_REF] Mubeen | Support for end-to-end response-time and delay analysis in the industrial tool suite: Issues, experiences and a case study[END_REF], ModComp 2014 [START_REF] Mubeen | Translating timing constraints during vehicular distributed embedded systems development[END_REF], MASE 2015 [START_REF] Bucaioni | Anticipating implementation-level timing analysis for driving design-level decisions in east-adl[END_REF], RTSCA 2015 [START_REF] Mubeen | End-to-end Timing Analysis of Black-box Models in Legacy Vehicular Distributed Embedded Systems[END_REF], CBSE 2016 [START_REF] Mubeen | Modeling of Legacy Distributed Embedded Systems at Vehicle Abstraction Level[END_REF], ITNG 2016 [START_REF] Mubeen | Refining Timing Requirements in Extended Models of Legacy Vehicular Embedded Systems Using Early End-to-end Timing Analysis[END_REF] and SEAA 2016 [START_REF] Bucaioni | Handling uncertainty in automatically generated implementation models in the automotive domain[END_REF] in Fig. 4, the tool suite now supports modeling and end-to-end timing analysis of distributed embedded systems at all the abstraction levels.

IV. SUMMARY AND FUTURE DIRECTIONS

The Rubus approach to providing both deterministic and non-deterministic service for vehicle systems has been proven by its usage as well as the certification of the Rubus Kernel according to the ISO 26262:2011 safety standard with respect to ASIL D. The evolution of Rubus from early experiences with deterministic solutions of automatic train control as well as the cooperation in the Vehicle Internal Architecture project that established the approach to mixing deterministic and non-deterministic services established the basis for the Rubus Kernel. The continued evolution both as a commercial product as well as a basis for research and development has stimulated cooperation between Arcticus Systems and Mälardalen University. This has included in provisioning of a Model-Driven Development tool suite that incorporates a variety of tools based upon research results.

In addition to the cooperation with Mälardalens University, Arcticus has participated in several European Research projects including TIMMO2USE 2 , CRYSTAL 3 , EMC 24 and ASSUME 5 .

Concerning the future, there are on going efforts to provide Rubus for Multi-core processors as well as developing a generic approach to model transformations in order to exchange information with other models and tool suites.

Figure 1 :

 1 Figure 1: Model of a Software Circuit.The Construct and Destruct logic are terms from Object Oriented languages that describe activation, respectively, deactivation of the circuit.2.2 Time Triggered, Event Triggered, and Interrupt ExecutionSoftware Circuit execution is triggered based on these three categories called Red, Blue and Green. The ability to mix both Red deterministic (time triggered) and Blue non-deterministic (event triggered) as well as treating Green interrupt execution is a unique aspect of the Rubus product suite.

Fig. 1 .

 1 Fig. 1. Model of a Software Circuit.

Fig. 2 .

 2 Fig. 2. Rubus Conceptual Models.

Figure 6 :

 6 Figure 6: End-to-End Network Analysis

Fig. 3 .

 3 Fig.3. System-level modeling and timing analysis of a distributed embedded system.

Fig. 4 .

 4 Fig. 4. Support for modeling and end-to-end timing analysis at various abstraction levels of EAST-ADL.

  Drive Software Development

	Designing		Rubus
		Design	Component
			Model (RCM)
	Configuring Properties such as:	Analysis	Rubus Analysis Model (RAM)
	Worst-case
	execution time
	Best-case execution time Resource usage	Synthesis	Rubus Run-Time Model (RRM)
	Run-Time
	Measurements