Matteo Bordin
email: bordin@adacore.com

Cyrille Comar
email: comar@adacore.com

Tristan Gingold
email: gingold@adacore.com

J Ér Ôme Guitton

Olivier Hainque
email: hainque@adacore.com

Thomas Quinot
email: quinot@adacore.com

Object and Source Coverage for Critical Applications with the COUVERTURE Open Analysis Framework

Keywords: Source coverage, object coverage, DO-178B, DO-178C, target emulation, open source

This paper presents COUVERTURE, an open coverage analysis framework for safety-critical software development. COUVERTURE offers nonintrusive source and object coverage analysis on unmodified user code, using instrumentation of a virtual execution platform based on QEMU, a flexible and efficient open-source CPU emulator.

COUVERTURE focuses primarily on the DO-178 civilian avionics certification process: it supports the source coverage analysis activities required for each criticality level. It also provides instruction and branch coverage analysis of object code. We discuss the relationship between execution traces, object coverage metrics, and source coverage. In particular, we provide a characterization of source constructs for which object branch coverage implies modified condition/decision coverage, and we discuss the trace collection process required for those cases where there is no such equivalence.

Introduction

The development of a high-integrity application involves interaction between the design and testing phases. System requirements are decomposed into high-level requirements, which lead to the definition of a software architecture and lower level requirements. The latter are implemented, generally using a highlevel programming language such as Ada, C, or C++. A set of corresponding verification activities often mirrors each decomposition step. For example, the testing part of the verification associated with system requirements is often referred to as acceptance testing, the one associated with software architecture and highlevel requirements is referred to as integration testing, while unit testing is often used to verify low level requirements. The workflow implied by such a decomposition is the standard waterfall model but even when more agile workflows are used, with shorter iterations and earlier emphasis on integration issues, the same correspondance exist between a level of requirements and verification activities.

At any level of decomposition, the test cases to verify the implementation of a given requirement are to be built from the requirement itself: the idea is to have the specifications, rather than the implementation, drive the testing strategy. One essential point in this process is the evaluation of the quality of the testing: Were enough test cases developed to verify that the software properly implements all of its requirements? Is there any functionality in software that does not stem from requirements?. Structural coverage analysis offers a means to conduct such an evaluation.

Various coverage metrics are in industrial use [START_REF] Ntafos | A comparison of some structural testing strategies[END_REF]. They differ by how comprehensive a test suite should be to achieve coverage. Two common examples are statement and decision coverage; the former measures how source code statements are exercised, the latter measures how complex or flow-controlling Boolean expressions (decisions) are evaluated.

Achieving a certain coverage criterion means that the requirement-driven testing strategy includes a set of tests whose execution exercises all the coverable structures that the metric targets.

For example, achieving statement coverage means executing at least once all statements present in the source code of interest, and achieving decision coverage means that the test suite executes all decisions with both outcomes (True and False). In section 2.1, we discuss MC/DC (Modified Condition/Decision Coverage), an even more stringent criterion.

We will use the following small Ada program as an example throughout this paper: The example on listing 1 contains two statements (lines 3 to 4) and a single decision (the Boolean expression at line 3). Statement coverage for procedure P can be achieved with just one test causing the decision to be evaluated True. Decision coverage is achieved with two tests, one evaluating the decision to True, the other to False. Coverage evaluation is explicitly required by several industrial standards: for example, DO-178B (civil avionics) [START_REF] Rtca | Software considerations in airborne systems and equipment certification[END_REF], EN 50128 (railroad systems) [START_REF]Railway applications -Communication, signalling and processing systems -Software for railway control and protection systems[END_REF], ECSS-E-ST-40C (space systems) [START_REF]European Cooperation for Space Standardization (ECSS). Space engineering -software[END_REF], or IEC 60880 (nuclear) [START_REF] Iec | Nuclear power plants -Instrumentation and control systems important to safety -Software aspects for computer-based systems performing category A functions[END_REF]. The remainder of this paper focuses specifically on DO-178 (we use DO-178 to refer to both DO-178B, the current version of the standard, and DO-178C, its upcoming replacement). In section 2, we give an overview of the coverage analysis activities defined in DO-178, and introduce MC/DC analysis. We discuss the relationship between object and source coverage, as well as current assessment methodologies. Section 3 presents our innovative approach: achieving object and structural coverage analysis by means of control flow traces produced by an emulated execution platform.

In section 4, we provide an in-depth discussion of the applicability of our approach to MC/DC assessment. We introduce several theoretical results on the conditions in which MC/DC can be derived from synthetic branch coverage information, and those in which full execution history must be collected. We present some practical results obtained with COU-VERTURE in section 5, and we discuss future directions in section 6.

Structural coverage and DO-178

DO-178 [START_REF] Rtca | Software considerations in airborne systems and equipment certification[END_REF] is the international standard providing guidance for the development of software to be deployed on airborne systems flying over civil ground. DO-178 describes a set of development and verification objectives which shall be met by a development team in order to gain certification credit for the developed software. Structural coverage analysis is an activity associated with the software verification process objectives (see [START_REF] Rtca | Software considerations in airborne systems and equipment certification[END_REF], table 7). Three different metrics are considered within DO-178: Statement Coverage (SC), Decision Coverage (DC) and Modified Condition/Decision Coverage (MC/DC). All these metrics express coverage in terms of source code elements: SC measures which source code statements are exercised, DC measures how boolean expressions (decisions) are evaluated, and MC/DC refines further with rules on atomic elements in boolean expressions (conditions). We give a brief description of MC/DC in section 2.1; additional information can be found in [START_REF] Chilenski | An Investigation of Three Forms of the Modified Condition/Decision Coverage (MCDC) Criterion[END_REF]. The metric required for structural coverage depends on the criticality of the application: the more safetycritical the application, the more stringent the metric (i.e. more extensive testing is required to achieve the coverage objective):

• Level A requires MC/DC. Applications whose criticality level is A are those whose failure would cause a catastrophic impact.

• Level B requires Decision Coverage. Applications whose criticality level is B are those whose failure would cause a severe impact such as a large reduction in safety.

• Level C requires Statement Coverage. Applications whose criticality level is C are those whose failure would cause major impact such as a significant reduction in safety margins.

Level D (minor impact) and E (no impact) do not require any measure of coverage.

Modified Condition/Decision Coverage

2.1.1 MC/DC definition MC/DC distinguishes decisions and conditions. A condition is an atomic Boolean expression. A decision is composed of one or more conditions connected by boolean operators. (C1 and then C2) or else C3, for example, is one decision with three conditions C1, C2, and C3. To achieve MC/DC, every point of entry and exit in the program must be invoked at least once, every decision must take all possible outcomes at least once, and each condition in a decision must be shown to independently affect the outcome of that decision [START_REF] Rtca | Software considerations in airborne systems and equipment certification[END_REF]. To explain what "independently affect" actually means, we introduce here the notion of decision evaluation vector.

An evaluation vector for a decision is a vector of Boolean values where each element corresponds to the value of one condition in the decision. For example, (T,F,T) is an evaluation vector for (C1 and then C2) or else C3 where C1 evaluates to True, C2 to False and C3 to True. A condition C has an independent influence on a decision D if two evaluation vectors exist which evaluate D to True and False and are identical but for the value of C. Note that a given vector may participate in more than one pair, each pair showing independent influence of a different condition.

For example, to achieve MC/DC for the code in listing 1, we can use the following evaluation vectors for the single decision: (T, T, F), (T, F, T), (T, F, F), (F, T, F). Independent influence of A is demonstrated by (T, T, F) and (F, T, F): the two vectors are identical but for the value of A and the decision is evaluated first to True, then to False. Independent influence of B is demonstrated by (T, T, F) and (T, F, F); independent influence of C is demonstrated by (T, F, T) and (T, F, F). MC/DC requires at least n + 1 tests to cover a decision composed by n independent conditions. 2.1.2 Unique Cause + Short-Circuit MC/DC MC/DC has been the source of confusion in the avionics certification community, stemming primarily from the meaning of a condition's "independently affecting the outcome" of a decision. The definition of MC/DC at the beginning of the previous section, based on the Glossary of DO-178B, has come to be known as Unique Cause MC/DC. This definition has several limitations:

• Unique Cause MC/DC can never be achieved for decisions with coupled conditions (because coupling means that the condition values change together);

• The set of possible independence pairs for a given condition is unnecessarily restrictive (because even inputs that cannot possibly affect the output are forced to be unchanged).

To address these issues, several variants of MC/DC have been proposed, which relax the definition of an independence pair, allowing some inputs (other than the condition whose independent influence is being demonstrated) to differ in the two test vectors. Unique Cause+Masking MC/DC and Masking MC/DC [START_REF] Chilenski | An Investigation of Three Forms of the Modified Condition/Decision Coverage (MCDC) Criterion[END_REF] are two examples of such relaxed variants which Certification Authorities have accepted as reasonable alternatives [START_REF]Rationale for accepting Masking MCDC in certification projects[END_REF].

In COUVERTURE, we use an intermediate form, which introduces a limited use of condition hiding: Unique Cause + Short-Circuit MC/DC. In this variant, we consider the right-hand side operand of a short-circuit operator (and then or or else) to be hidden when the value of the left-hand side alone determines the outcome of the operator, and we ignore differences in hidden condition values for determination of independence pairs. This is consistent with the code generation strategy for such operators: the right-hand side is evaluated only if the value of the left-hand side makes it necessary. In other words, a condition is hidden under Unique Cause + Short-Circuit MC/DC when the evaluation of the enclosing decision does not even evaluate that condition.

In this case, no value change of that condition can possibly be the cause of a change in decision outcome. As for standard Unique Cause MC/DC, we retain the constraint that all evaluated conditions (other than the one being tested for independent influence) have fixed values. This definition of hiding is more conservative than the notion of masking proposed in [START_REF]Rationale for accepting Masking MCDC in certification projects[END_REF].

Source Coverage versus Object Coverage

Applicants for DO-178 certification have sometimes proposed the use of object code coverage instead of source code coverage as a metric to satisfy the objectives of DO-178. The proposed approach involves measuring either instruction coverage or branch coverage. Object instruction coverage (OIC) requires assessing whether all object instructions are executed at least once; object branch coverage (OBC) in addition requires that all conditional branches be exercised for both directions (branch and fall through). The use of object code coverage has also been proposed as a way to cope with untraceable object code. Section 6.4.4.2 of DO-178 indeed states: The structural coverage analysis may be performed on the Source Code, unless the software level is A and the compiler generates object code that is not directly traceable to Source Code statements. Then, additional verification should be performed on the object code to establish the correctness of such generated code sequences.

Untraceable object code is compiler generated machine code that impacts the execution control flow in a way not directly visible from source code. An example is the Ada mod operator, which requires an implicit conditional branch to distinguish between positive and negative moduli. Achieving a certain source coverage level is not indicative of coverage of untraceable code: even a comprehensive testing campaign (from a source coverage point of view) may not assure all object code is executed. The untraceable object code is nevertheless present in the application and may lead to unintended behaviour not verified during the testing process.

Measuring object code coverage may be a way to ensure even untraceable code is executed during the requirement-driven testing campaign. However, CAST paper 12 [START_REF]Guidelines for Approving Source Code to Object Code Traceability[END_REF] suggests the use of a traceability study to satisfy the additional verification activities on untraceable object code for level A software: a traceability study provides evidence that, in a given context (coding standard, compiler, compilation switches), the compiler either generates traceable code or the untraceable code is correct -i.e. it correctly implements the requirements expressed by the specifications of the chosen programming language. The issue raised by section 6.4.4.2 of DO-178, and in general the equivalence of source and object coverage, is considered in both FAQ 42 of DO-248B [START_REF]of do-178b "software considerations in airborne systems and equipment certification[END_REF] (Can structural coverage be demonstrated by analyzing the object code instead of the source code?) and CAST paper 17 (Structural Coverage of Object Code) issued by the Federal Aviation Administration [START_REF]Certification Authorities Software Team. Structural Coverage of Object Code[END_REF].

Both documents assert that object code coverage can substitute for source code coverage as long as analysis can be provided which demonstrates that the coverage analysis conducted at the object code will be equivalent to the same coverage analysis at the source code level. In section 4. Coverage of instrumented code has the advantage of providing a straightforward mapping between the source code and the logged coverage information: it satisfies the requirements of DO-178. On the other hand, developers may be asked to demonstrate that the instrumentation did not modify the application behaviour and that the coverage of the instrumented application is representative of the coverage of the final application.

Another common approach to structural coverage targets object code, using hardware probes that log which instructions have been executed and allow step-bystep execution. This approach, implemented in tools such as VeroCel VeroCode or GreenHills GCover, has the advantage of being non intrusive: coverage is measured on the final, cross compiled application, and no additional verification is required. In addition, this approach is independent of the choice of a specific programming language, making it an excellent candidate for multi-language applications. However, this technique has several limitations. First of all, as we discuss in section 4.3, MC/DC and OBC are not equivalent in the general case. Furthermore, coverage may be measured only when the target hardware is available.

These limitations make it impractical to evaluate object code coverage continuously during the development process, potentially leading to late discovery of defects in the testing strategy, and costly remediation actions.

The COUVERTURE approach to coverage

COUVERTURE is a research project founded by French institutions within the System@tic framework. The project consortium comprises AdaCore, OpenWide, Telecom ParisTech and LIP6 (Pierre et Marie Curie University, Paris). COUVERTURE innovates on all aspects of current technology for structural coverage by:

• Providing a virtualized execution platform for crosscompiled application on the host machine. The virtual machine is able to produce a detailed control flow execution trace (i.e. a report of which basic blocks have been executed, and how control transferred from one to another).

• Measuring object code coverage through careful examination of execution traces.

• Measuring source code coverage as defined by DO-178 by relating elements of the execution trace (instructions, branches) to source-level structures (statements, decisions, conditions).

The COUVERTURE technology is thus able to measure both source and object coverage for the cross compiled application, thus offering maximal flexibility. The use of a virtualized environment removes any dependency on target hardware and offers an efficient coverage analysis workflow. No source code instrumentation is required, which ensures that the coverage analysis activity does not interfere with application behaviour.

Virtualized execution environment

The core of the COUVERTURE technology is a virtualized execution environment playing a dual role: it permits the execution of cross compiled applications on the host workstation without requiring the final hardware to be available, and it gathers execution traces used by COUVERTURE to measure object and source code coverage. The basic idea behind COUVERTURE is to virtualize the approach commonly used to measure object code coverage: while traditional object coverage tools require a physical connection to the target hardware to measure coverage, COUVERTURE uses a virtualized environment producing a rich execution trace containing the address of executed object instructions and the outcomes of conditional branches. COUVERTURE is then able to determine actual object code coverage by processing several execution traces corresponding to the executions of different tests.

The technology at the heart of COUVERTURE is QEMU [1]. QEMU is a processor emulator employing dynamic binary translation. QEMU takes as input a crosscompiled application and translates basic blocks into executable code for the host processor. This method is in general very efficient, and in the case of current generation PowerPC or ERC32/LEON2 targets, the simulator even proved to be faster than actual target boards in our environments. QEMU also provides an accurate model of the target Floating Point Unit (FPU), as well as an emulation of various I/O devices, allowing a significant amount of testing without any physical environment interaction.

An open source project, QEMU can be modified and extended by users. Our main contribution to QEMU is the support for the generation of execution traces. Two output modes are supported:

• synthetic, bounded-size traces indicating which range of code addresses have been executed, and, for conditional branches, whether they have been taken in one direction or the other, or both.

• full historical traces (for selected code addresses), indicating branch direction information for each separate evaluation of relevant conditional instructions.

These traces are the basis for COUVERTURE's coverage analyses, to date supported on LEON2/ERC32 (SPARC) bareboard platforms as well as on PowerPC, bareboard or with Wind River VxWorks 653.

Source coverage obligations

The traces produced by QEMU are enough to measure object code coverage. They are however not sufficient in themselves to produce source code coverage evidence as required by DO-178.

In order to produce these reports from object execution traces, COUVERTURE needs additional information about source code structure. This information comes in two parts. The first one is the standard DWARF debugging information emitted by the compiler. Debugging information links every executable instruction to a location in source code (identified by file, line and column).

In order to further relate this information to coverable constructs (statements, decisions, and conditions), COUVERTURE augments the debugging information with Source Coverage Obligations (SCOs), which identify source constructs (including their source location) for which coverage artifacts need to be exhibited in order to satisfy some coverage objective. SCOs are extracted from source code by the compiler. They contain an abbreviated representation of the logical control flow of the program, including the full logical structure of decisions. These obligations are then discharged by associating them with execution traces, using debug information and source locations as the connection. COUVERTURE can thus infer all DO-178 source code coverage metrics from the execution traces produced by QEMU: Statement, Decision, and Modified Condition/Decision coverage.

MC/DC assessment from execution traces

In this section, we discuss how execution traces collected from an instrumented virtual execution environment, as described above, can be used to determine whether a given source coverage criterion (and specifically MC/DC) is achieved by a certain set of executions.

MC/DC assessment work flow

The general principle in this process is to infer the values of each condition for a given evaluation of a decision from the direction taken by execution at each conditional branch instruction in the object code. This assumes that the code generation process generates appropriate conditional branch instructions (as opposed e.g. to Boolean computations) for each condition, i.e. that the object control flow graph reflects the source structure of decisions. In GNAT, this is achieved using the -fpreserve-control-flow compiler switch, in addition to mandating the exclusive use of short-circuit boolean operators (the non-short-circuit Boolean operators and, or, and xor, as well as all relational operators on Boolean operands, are forbidden). SCOs and DWARF debugging information are used as an aid to trace each edge of the control flow graph back to edges of the decision's Binary Decision Diagram (BDD), i.e. to the value of each condition: from a conditional branch instruction, debugging information yields a location in source code (file, line, and column), and SCOs then indicate what condition is tested at that location. This mapping is created during a preliminary static analysis phase, prior to code execution. Determining whether MC/DC is reached for a given decision and a given set of tests requires the ability to reconstruct the complete set of evaluated test vectors, i.e. the combination of values of the relevant conditions encountered for each evaluation of a decision. In general, this requires full historical traces of the corresponding conditional branch instructions, and the amount of collected data can potentially grow to an unwieldy size.

However in some cases it is sufficient to keep synthetic information about each conditional branch instruction (indicating whether it has been taken in one direction, in the other, or both), as opposed to keeping state information about all evaluations of the instruction. In other words, there are cases where MC/DC can be derived from object branch coverage information and in such cases, there is no need to keep and process historical traces since the regular stateless execution traces are sufficient. Relying as much as possible on stateless traces makes it also easier to produce accurate coverage metrics in a multithreaded context. It is therefore important to be able to characterize very precisely and accurately the situations where MC/DC can be deduced from OBC.

Non equivalence between OBC and MC/DC

First let us have a look at how MC/DC and object coverage relate to each other on some simple cases. Cases of non-equivalence for decisions with up to 5 conditions have been studied in [START_REF]Object Oriented Technology Verification Phase 3 Report -Structural Coverage at the Source Code and Object Code Levels[END_REF]: non-equivalence cases have been shown to occur in decisions with three or more conditions, and an illustration is provided with (A and then B) or else C, where A, B and C are three independent conditions. A representation of this decision's BDD is depicted on figure 1(a):

A B C T T F T F T F T F (a) C 0 C 1 C 1 C 2 C 2 T T F T F T F T F T F T F (b)
Figure 1: Example decision BDDs

From this representation, we can see that a set of three evaluations can achieve branch coverage of the whole BDD, corresponding to the three vertical paths in figure 1(a). These evaluations are:

A B C (A and then B) or else C T T x T T F T T F x F F
where "x" means not evaluated and thus can be indifferently True or False. Now, indeed, even though all the BDD edges are covered, MC/DC is not met. In particular, the independent effect of conditions B and C on the decision is not shown. Since n + 1 tests are needed to cover a decision with n condition with respect to MC/DC, 3 evaluations cannot cover a threecondition decision.

It turns out that this particular case can be generalized in a quite spectacular counterexample: there exists classes of decisions with an arbitrary high number of conditions that can be branch covered by just three evaluations; the previous example was one element of this class with 3 conditions.

Consider the following set {D n } n∈N of decisions:

• let D 0 be a simple condition decision; by convention, we will call C 0 its condition;

• let us define D n , for any n > 0, as follows: D n = (D n-1 and then C n ) or else C n C n and C n being independent from each other and from any condition in D n-1 .

In other words: , where it is visible that all the edges can be covered by three evaluation paths which only demonstrate the independent effect of C 0 :

• D 0 = C 0 • D 1 = (C
C 0 C 1 C 1 C 2 C 2 D 2 T T x T x T T F T F T T F x F x F F
We can thus build a decision D n with an arbitrary number of conditions, that can be BDD branch covered by just three evaluation paths. As MC/DC can only be achieved with a minimal number of n + 1 evaluations, this is a striking case where BDD branch coverage (and consequently OBC) is far from being equivalent to MC/DC.

Equivalence cases between OBC and MC/DC

Having introduced two example situations where OBC and MC/DC are not equivalent, we now generalize this discussion using formal reasoning on properties of the canonical reduced ordered binary decision diagram associated with each decision, considering the variables ordered as they appear in source code. The construction of this canonical diagram is given in [START_REF] Bryant | Graph-Based Algorithms for Boolean Function Manipulation[END_REF]. In the remainder of this paper, we will refer to this canonical diagram informally as the BDD.

We rely on the straightforward correspondence between nodes of the object control flow graph and nodes of the BDD: it is assumed -and this property is guaranteed by GNAT when using the -fpreserve-control-flow compiler switch -that the evaluation of a condition corresponds to a conditional branch instruction (that is, an alteration of the execution control graph depending on the condition), and that a mapping can be established between edges of the control flow graph and edges of the BDD.

Under this representation, evaluating the decision using the Ada semantics of short-circuit operators (evaluating the right-hand side only if necessary to determine the outcome) is exactly equivalent to following a path through the BDD.

The following property then holds:

Theorem 1 Given a decision D, branch coverage of the BDD implies MC/DC if, and only if, there is no diamond in the BDD (i.e. no node of the BDD is reachable through more that one path from the root).

A complete formal proof is given in the COUVERTURE documentation [2].

As a consequence of this theorem, when the BDD has no diamond, it is possible to establish MC/DC without resorting to full historical traces. When there is exactly one conditional branch instruction for each condition, this is also exactly equivalent to OBC, assuming a code generation process where the object control flow is isomorphic to the BDD (which is the case in the context of COUVERTURE).

When some conditions involve multiple conditional branch instructions, OBC still implies MC/DC, but becomes in effect an even stronger property: MC/DC could potentially be established by a test set that does not achieve OBC. However, as long as the conditions of theorem 1 hold, it is still the case that MC/DC can be determined from stateless execution traces (i.e. from the OBC information for each conditional branch instruction) even if full OBC is not achieved (because some edge of the control flow graph that remains within a condition might not be taken, even when all those edges that do correspond to BDD edges are).

Alternative characterization

In this section we provide an alternative (equivalent) property that characterizes cases where BDD branch coverage implies MC/DC:

Theorem 2 Given a decision D, BDD branch coverage implies MC/DC if, and only if, when considering the negation normal form D' of D, for every sub-decision E of D', all binary operators in the left-hand-side operand of E, if any, are of the same kind as E's operator.

The negation normal form is obtained by rewriting the expression using De Morgan's laws so that negations apply only to atomic conditions (and not to more complex subexpressions).

More informally, this corresponds to expressions where there is no or else in the left-hand-side of a and then and conversely. The proof of this theorem first shows that this alternative characterization is equivalent to having no diamond in the associated BDD. Theorem 2 then follows by application of Theorem 1.

Results

In this section, we give examples of the output of the COUVERTURE analysis tool for simple test cases, and we discuss interesting MC/DC analysis results obtained on real-life industrial code.

Object and Source coverage ouput examples

We will consider the results obtained exercizing the Ada procedure in listing 1, which evaluates (A and then B) or else C where A, B and C are incoming arguments. We are using a version of the GNAT compiler which ensures that each condition eventually materializes as a conditional branch instruction.

Let us look at object branch coverage results first. Amongst several possible output formats, we will observe an "annotated source" report, where each source line is annotated with a synthetic sign to summarize the coverage information for all the instructions associated with that line.

Out of two calls with (T, T, F) and (T, F, T) for A, B and C respectively, we obtain partial branch coverage for the code associated with the evaluation line. This translates into a '!' sign next to the line number, and we can request the expansion of all the associated machine instructions to confirm:

4 !: if (A and then B) or else C then ... fffc019c v: beq cr7, <_ada_p+00000044> ... fffc01ac +: bne cr7, <_ada_p+00000054> ... fffc01bc v: beq cr7, <_ada_p+00000060> ... The 'v' sign next to address for the first conditional branch instruction indicates that the branch was only taken one way. This is as expected since the branch is decided on the value of A, and A was True in both evaluations. The '+' on the second branch indicates that it was taken both ways, as expected since B was evaluated twice, once True and once False. The 'v' sign on the third branch indicates partial coverage of the branch for C, as for A. Even though the C argument was passed both True and False in the program, partial coverage of this branch was actually expected because C is not evaluated on the first call.

As suggested earlier in this paper, full object branch coverage for this expression is achieved by adding no more than a third call with (F, F, F), which indeed translates as '+' annotations everywhere.

If we now consider source coverage criteria, the 3-calls testset we have so far achieves decision coverage as well: there is one decision in the code and the tests have exercized it both True and False. We still don't have MC/DC, however, and the reason is reported if we re-analyze for this criterion: "B" : failed to show independent influence "C" : failed to show independent influence, MC/DC not achieved

Evaluation on actual industrial code

Our approach to DC and MC/DC assessment through execution traces rely on good properties of the code generator used, preserving source decision structure and reflecting it, to some extent, in the object code control flow graph. Improvements have been made to the GNAT compiler enabling this mapping to be performed completely on an actual industrial application, with no optimization of the generated code. Adjusting the code generator to preserve sufficient decision structure in the generated code at higher optimization levels is still work in progress.

We have evaluated COUVERTURE against two industrial applications. Reporting from the analysis phase of COUVERTURE provided interesting insight on the frequency of those constructs that are specifically difficult to check for MC/DC coverage (decisions involving diamond paths in their BDD). Some of these results are summarized below. Additionally, all of these complex decisions are in preconditions, postconditions or assertions: none is in actual functional code.

Measure

The second application similarly has relatively few decisions with multiple paths (0.4 % of all decisions). It has a few pathological very large decisions (up to 78 conditions), but 35 844 decisions (or 96 %) have one, two or three conditions. This means that in practice, even though COUVER-TURE is prepared to handle the worst case scenario where full historical traces is required to establish MC/DC coverage, in practice the overhead will be marginal compared to plain OBC assessment (which can be performed using synthetic traces of bounded size), because in industrial code those worst cases are very infrequent.

Future directions

The current results of COUVERTURE have been obtained with all compiler optimizations disabled (gcc -O0). Higher optimization levels hinder coverage assessment because of code reorganizations that break the relationship between object code and source coverable constructs. Work is in progress to improve COU-VERTURE so that most of -O1 can be retained while preserving the ability to compute source coverage from execution traces.

As discussed in section 3.2, this computation relies on SCOs: artefacts produced by the compiler that describe source constructs that are the targets of coverage assessment. SCO generation is currently implemented only for Ada language programs. We have plans to extend GCC to also generate SCOs for C source code. Ongoing research work of academic partners in the COUVERTURE project also aims at applying it to Ocaml programs [START_REF] Chailloux | Non Intrusive Structural Coverage for Objective Caml[END_REF].

Conclusion

We have presented the COUVERTURE approach to object and structural coverage analysis for certified safety-critical applications, in particular in the context of DO-178. Our methodology is non-intrusive, assessing coverage on unmodified user code, and collecting execution traces from an instrumented emulated and very efficient execution platform. We have used object coverage techniques in order to generate precise source coverage metrics. In particular, we have formally characterized the cases where synthetic object branch coverage information is sufficient to establish MC/DC coverage and the cases where it is not.

This approach has been implemented in a set of open source tools that have been successfully evaluated against both extensive unit tests aiming at tool qualification and real-life industrial application code. These tools and methods will constitute an important building block within the OpenDO initiative.

We also hope that the availability of such efficient and accurate coverage techniques on the embedded code itself will be useful to the growing number of critical software developers adopting agile techniques such as "continuous integration". As a matter of fact, providing daily coverage metrics on the system being continuously integrated provides an inestimable too for evaluating project advancement.

1

  procedure P ( A , B , C : Boolean ) i s 2 begin 3 i f (A and then B) or else C then 4 Do Something ; 5 end i f ; 6 end P ; Listing 1: Example source code

3 •

 3 0 and then C 1 ) or else C 1 • D 2 = (((C 0 and then C 1 ) or else C 1 ) and then C 2 ) or else C 2 • D 3 = (((((C 0 and then C 1 ) or else C 1 ) and then C 2 ) or else C 2 ) and then C 3 ) or else C ...

Figure 1

 1 Figure 1(b) shows the BDD for D 2 , where it is visible that all the edges can be covered by three evaluation paths which only demonstrate the independent effect of C 0 :

  Of these 869 decisions, only 7 (or 0.8 %) have a node in their BDD that is reachable through multiple paths.

					App. 1	App. 2
	Ada units				351	8 356
	Ada SLOCs				67 344	1 166 183
	Decisions				869	37 324
	Max. conds per decision		7	78
	Decisions with diamond	7 (0.8 %) 141 (0.4 %)
	For the first application, the breakdown of decisions
	according to condition count is as follows:
	# conditions	1	2	3	4 5 6 7
	decisions	597 194 49 13 5 10 1


Dr Stefan Voget

P Favrais

How the concepts of the Automotive standard "AUTOSAR" are realized in new seamless tool-chains

Keywords: AUTOSAR, AUTOSAR methodology, meta-model, seamless tool-chain, ARTOP, EAST/ADL, timing modeling

How the concepts of the Automotive standard "AUTOSAR" are realized in new seamless tool-chains

Stefan Voget, P Favrais

Introduction

Since six years the AUTOSAR standard [1] is under development within the automotive industry. No subdomain of the vehicle is excluded. Today, series developments based on this standard run in interior, power-train as well as in chassis. Although their requirements are quite different, AUTOSAR allows reuse of infrastructure software between the subdomains.

In none of the projects the development starts at zero. Existing solutions have to be adapted to the AUTOSAR approach. The reality shows, that there is not the one and only path to migrate existing solutions to AUTOSAR. But, several "best practices" can already be derived by the experiences done in all automotive domains as the standard is in series development since more than three years. AUTOSAR does not only define new infrastructure software, but also the processes and tool-chains are influenced by the standard.

In this article we will motivate the importance of AUTOSAR for the tool chains in series development projects. This is due to the AUTOSAR methodology [2][3] which shifts more and more complexity from an implementation oriented process to a configuration based process. This results in a shift of main tasks in a development process more to the left part of the Vcycle. As a consequence, the configuration based process enables the introduction and use of more automatism in the software development. The new character of the AUTOSAR methodology enables and requires new tools that provide the automatisms. Therefore, AUTOSAR currently has a deep influence on the tool developments for the automotive industry. More and more tool vendors arise in the market with tools that support the AUTOSAR methodology.

Mainly two alternative approaches for the development of these tools can be observed. Some vendors enhance their existing tools with export and import capabilities to and from the AUTOSAR format but do not adapt the workflow regarding the configuration process. This is mainly reasoned in the fact that most of the series projects are still non-AUTOSAR projects. The comment given above regarding migration to AUTOSAR is also valid for the tool industry. Other vendors use the standard as an opportunity to design new tool capabilities. This enables new vendors to establish them self in the automotive industry.

A lot of new tool innovations that realize the concepts around the AUTOSAR system methodology are on the way. One platform for these innovations is ARTOP (AUTOSAR TOol Platform) [4] [5][7] [START_REF] Rudorfer | Artop -an ecosystem approach for collaborative AUTOSAR tool development[END_REF]. The so called ARTOP user group provides common base functionality used for design and configuration of AUTOSAR compliant systems and electronic control units (ECU). It is an Eclipsebased AUTOSAR tool infrastructure platform (See www.artop.org) [6].

Based on this platform we will show how the AUTOSAR concepts like system development, system configuration, timing analysis and code generation can be brought together into a seamless tool-chain. Some outlook about extensions into functional modelling -that is not defined by the AUTOSAR methodology itself -is presented, too.

AUTOSAR

The main concept of the AUTOSAR approach is to separate application and infrastructure software. On application level the AUTOSAR software components (SW-C) are introduced. A SW-C may cover a small, reusable but also a complex automotive functionality.

Software components are connected with each other through well defined ports and interfaces. In terms of implementation, the AUTOSAR software component is independent from the infrastructure, i.e. it is independent from the type of the microcontroller and the type of electronic control units (ECU) the SW-C is running on.

The separation between function and infrastructure is important for the reusability of software components in different ECU's and is achieved at design time through the Virtual Functional Bus (VFB). The Virtual Functional Bus takes care of the communication between different components and between software components and the hardware. The VFB realizes the goal of being able to relocate software components and allows a virtual integration of AUTOSAR software components in an early development phase. AUTOSAR provides a methodology and proposes the use of tools for this purpose.

AUTOSAR Methodology

The AUTOSAR Methodology is a booklet to support the exchange of model data in early development steps of a series project. It defines activities and work products. But, it is neither a process description nor a business model and therefore does not predefine a strict order in which the activities should be accomplished.

In the first step, system information is collected that will be used for a configuration of the system. These inputs are formal descriptions of software components, ECU hardware resources and system topology.

The first important step, the system configuration, takes these descriptions and performs a mapping of the software components to one or more ECU's. With the help of the VFB principle the application software had been modelled independent from the concrete hardware until this step. The system configuration step marks the changeover from a hardware independent SW development to a hardware related SW configuration. To complete this step, a second mapping is performed. It is the mapping of signals to bus frames which results in the communication matrix.

If the system configuration step is finalized, one knows the software components that are allocated to a single ECU. Now, the further steps of the methodology operate on a single ECU. To be able to concentrate on a single ECU, the subset of information that is relevant for the further implementation of that ECU is extracted from the system configuration description.

Additionally, necessary information for the implementation is added in the ECU configuration activity. The output of this step is the ECU Configuration Description containing all information concerning one electronic control unit. Using this description executable software for this ECU can be generated.

This step includes the generation of code, compiling code and connecting everything into an executable. The description of an AUTOSAR system is performed using appropriate templates. Those templates define the AUTOSAR meta-model and allow a formal description of an AUTOSAR system. Based on these descriptions the AUTOSAR Methodology generates an ECU executable. But, the AUTOSAR meta-model is very complex. It is a new terminology with complex relationships between the defined objects. So far, only limited knowledge about how to realize the methodology in series projects can be found in the industry. The models will be exchanged and reused between suppliers and OEMs during the life cycle of a software development. However, the AUTOSAR methodology does not define who is doing what and when in a software development. Procedures and the sharing of the different roles and tasks have to be identified and contracted between the OEM and their suppliers.

The standard itself does not give support in the modelling process and just partial support in the data consistency. Concurrent configuration / modelling and parallel development are not considered by AUTOSAR but are a must for the usability of a toolchain. Furthermore, until now several AUTOSAR versions are in use, that are incompatible with each other. The templates defined by AUTOSAR improve the interoperability of tools but do not completely solve the problem of usage of too many different tools. As each step of the methodology leads to a result, which is saved in an exchange format, the change of a tool can lead to loss of information and to errors. Additionally to the AUTOSAR data, very often the tools need to store presentation data for the tool itself. As this is not foreseen in AUTOSAR, exporters, importers and translators are still needed.

AUTOSAR Use Case: exchange of models

In this section we want to consider an example for how an OEM and a supplier may collaborate during the development of a network of ECUs. It is assumed that the supplier develops several ECUs that run within the network of ECUs in a vehicle. The OEM is the integrator for the whole system. The steps are presented in the form of a use case description.

Pre-condition:

A subsystem, consisting of several ECUs equipped with AUTOSAR software, is developed by the supplier.

Post-condition:

A subsystem of ECUs is adapted according to the customer's specific wishes and is sold to the customer.

Description:

1) The supplier delivers the input information for the system configuration step.

The supplier delivers the ECU resource description for the hardware used in the subsystem to the OEM.

The OEM adds this description to the ones used in the whole vehicle such that he gets a complete set of ECU resource descriptions for all hardware used in the dedicated vehicle.

The supplier delivers the application software (ASW) component descriptions for the ASW components of the subsystem to the OEM. The OEM adds these descriptions to his software architecture for the whole vehicle.

The supplier delivers the system constraints for the ASW components used in the subsystem to the OEM. The OEM integrates these system constraints into the system architecture.

2) OEM runs the system configuration.

The OEM integrates all three templates -the ECU resource description, the system template and the ASW component template. Now, the OEM runs through the system configuration step. This step is an iterative one. A first mapping of ASW components to the ECU hardware may lead to the need to adapt the system architecture as well as the software architecture. This leads to changes on the side of the OEM as well as on the supplier's side. So, a strong relationship between OEM and the involved suppliers is necessary.

The OEM extracts the configuration descriptions for the dedicated subsystem of ECUs that will be implemented by the considered supplier. The OEM delivers this configuration data to the supplier.

3) Supplier implements subsystem.

The supplier adapts its subsystem, generates the RTE and configures the BSW for each ECU. After the integration and testing on the ECU as well as on the subsystem level, the supplier delivers the integrated subsystem to the OEM.

4) OEM integrates system. The OEM integrates the subsystem into the whole electronic/electric system. This includes the necessary integration and testing steps.

The use case shows an intensive interaction between OEM and suppliers. This is particularly necessary when considering early integration on the vehicle function bus level. Such a new concept breaks traditional OEM -supplier relationships. As mentioned for the development processes as well as for the introduction of new OEM -supplier collaboration processes needs time and are difficult to establish. But the success of the whole standard depends on the success of the processes demanded by the standard.

Effects on tool landscape

The importance of exchange of models leads directly to the conclusion that the interoperability of tools is a key factor for enabling the AUTOSAR methodology in reality. But, some tools use proprietary internal data formats and support AUTOSAR via Import / Export features.

Although the data can be imported or exported to AUTOSAR, the merge of the exported data is complex as the proprietary formats usually do not follow the workflow of the AUTOSAR methodology.

Additionally to the AUTOSAR data, very often such tools need to store presentation data for the tool itself which leads to a mix of AUTOSAR data with non-AUTOSAR data in files.

Last but not least, a fact that should not be neglected is that the tools use different base technology. The users spend a lot of time in learning the tool rather than in using the tool. Moreover, tools based on different technology cannot be easily integrated in a seamless workflow.

ARTOP

A common framework, which enables the development of a continuous, lossless tool chain, is helpful to overcome the challenges presented in the previous chapter. 2. The Extension Points mechanism contributes functionality to a specific plug-in, which defined the extension point. This enables the users of tools to extend the functionality in an easy manner. Adaptations to the needs of the user can be operated by him. This is an often whished feature in the Automotive industry.

ARTOP (AUTOSAR

3. The Wizards utilities enable to guide the user through a defined sequence of steps to fulfil a specific task Eclipse provides support to easily create wizards.

Recently, an automotive working group had been founded in Eclipse. This group wants to define an Eclipse target platform for the automotive industry. This target platform should be used to develop tools for the whole development process lifecycle. AUTOSAR influences parts of this development process. Therefore, ARTOP is of highly interest for the working group. Due to restrictions given by the AUTOSAR contracts, the AUTOSAR dependent parts of ARTOP cannot be handled by the Eclipse automotive workgroup itself. But the AUTOSAR independent parts are taken over by the Eclipse working group. ARTOP is the first concrete use case for the workgroup.

ARTOP enables seamless tool chain

This chapter will present some challenges in the existing tool landscape and how ARTOP supports solutions.

AUTOSAR has boundaries

Having a look to the AUTOSAR methodology one recognizes that it does not cover the complete development process lifecycle. The influence of the methodology begins somewhere in the middle of the system architecture modelling step and ends directly before the compilation step. Topics like requirements management, hardware development or built management are not related with AUTOSAR.

One cannot expect that ARTOP provides a platform to enable a seamless tool chain starting with a requirements step up to an executable built step. But, as AUTOSAR influences directly a central part of the development process lifecycle, ARTOP is a good base for harmonization of the tool landscapes. It provides useful features to extend the platform itself -on editor level as well as on meta-model level. The extension point mechanism from Eclipse is heavily used.

Meta-model structure in-homogeneous

The structure of the AUTOSAR meta-model differs very much between the "work on system" part and the "work on ECU" part (Figure 1). This reflects the differences in the use cases to be covered on both sides.

The tool market follows these borders. Normally a tool works either on system level or on ECU level but not on both. The interoperability between both sides are usually done file based. ARTOP enables tool chains that do not require from the user to start several tools, to export from the one tool and to import to another tool. Everything is shifted from the file level to the meta-model level that enables a better data management consistency.

Concurrent modelling

In addition, in a seamless tool chain it is also important to consider the support of concurrent modelling, configuration and implementation. So, it is a key aspect that ARTOP enables the split of models such that several developers can work on different parts of the model independently from each other. In addition, the support of concurrent modelling also needs the support for successive iteration loops. The integration of the work products delivered by the different developers need to be facilitated by advanced comparison and merge features. This is necessary to detect

• integration conflicts • unresolved references • incompatible versions
• missing parts of the models Such workflow oriented support is not content of ARTOP itself. It has rather to be implemented by the commercial tools that are implemented on top of ARTOP.

Limitations of data format harmonization

The normative aspect of AUTOSAR presents an answer to the usage of different data format for describing the same things. Nevertheless, also with AUTOSAR this has still some limitations.

• Mainly all today's projects are not 100% AUTOSAR, e.g. some projects implement only basic software with AUTOSAR but model the application software without AUTOSAR. • As there are several releases of AUTOSAR, there is not the one and only data format.

Transformations between the releases are still needed.

As ARTOP supports all published AUTOSAR metamodel releases, transformation algorithms can be implemented on top of the platform easily.

Case Study -CESSAR-CT

On the one side the arguments for an approach like ARTOP are obvious. It works and one gets something for free.

On the other side one may ask the question about why tool vendors should use ARTOP, as they may give sensitive parts of a tool development into an open user group.

The development of an AUTOSAR configuration tooling within Continental Engineering Services (CES) can be taken as a case study for the successful usage of ARTOP. Together with the AUTOSAR standard basic software -also implemented and put on the market -these software products enable the engineering activities of CES.

For the engineering business it is of main importance to have a flexible, extensible and customizable tool. Normally, these are not the attributes one finds in the tools available on the market. These are usually oriented on a fixed end user use case and not usable for an engineering expert that develops and adapts something for the customer. The main user roles supported by the tool are the "basic software developer" and the "ECU integrator".

Therefore, the focus is on the ECU part. But, with AUTOSAR also these use cases need information from the system part of the meta-model. E.g., Figure 4 As Continental were not a tool vendor before it had been a challenge to act as a founding member of the user group ARTOP. After nearly two years with ARTOP it is accepted, that the approach enabled CES to develop a tool that can be sold on the market.

Experiences

Experiences done within Continental Automotive have shown the importance of the seamless integration of the AUTOSAR tools together with the build tool chain. Indeed, with AUTOSAR architecture, it becomes natural that a project is an integration of many AUTOSAR modules (IO, COM, RTE...) developed by different companies. So, the first challenge to the project team, before making the ECU software running, is to make the development tool chain running on a robust manner and with good performances so that it can be deployed to the complete project team. If an AUTOSAR module or a set of modules (e.g. PORT, ADC, DIO...) is delivered by an external company, the delivery contains the XML configuration files, the related code generators andsometime -specific tool editors. This means that the tool chain becomes very heterogeneous and more and more complexity is shifted to this area.

The following problems have to be considered: Regarding the editors, the complete workbench becomes very heavy and not user-friendly because too many different tools must be started to edit the different modules. As a consequence, the workingperformance is becoming really bad. Moreover, as there are different tools, it also implies very often different workspaces or projects for the XML configuration files.

Regarding this problem ARTOP framework will bring advantage if it is largely deployed in the future. Thus, instead of delivering a complete standalone tool, we could imagine that the companies who deliver its modules also deliver the ARTOP plug-in for the edition.

Concerning the code generator, they could have been implemented on different platforms, but need to be executed from a unique build environment at the project level. For instance, it is important that:

• The code generator can be executed in command line mode so that they can be launched from the build. • There is a way to check the dependencies between the generated .h/.c files and the input XML configuration files. Indeed this is important to not regenerate and then recompile more that necessary the .h/.c files. Else, it is a considerable loose of time for the project end-users to wait for regeneration and compilation. On the other side, it is important to launch the code generators affected by the modification of parameters in any of the input XML configuration files.

The AUTOSAR configuration model is very large and complex. On the side of the configuration tool one of the challenges was to develop editors which hide the model complexity and assist the user in its configuration work. Indeed, for the very first project, we started to make the configuration using generic editors. For starting, such generic editors were a good solution because it provides very quickly the capability to edit any parts of the whole AUTOSAR model with the same editor. However, the drawback of this editor is that it does not hide the AUTOSAR model complexity.

Indeed, these editors show the configuration model in a raw way (keeping the Containers / Parameters structure), which do not necessarily correspond to the user functional view. Moreover in the AUTOSAR model a quite big quantity of parameters have dependencies between each other, or are sometimes duplicated in different AUTOSAR model parts.

Also that does not include that each project and customer have its own requirements. For example, very often -in a project for an identical AUTOSAR model -the configuration is done by several users having different roles (e.g.: Basic SW developer, Basic SW integrator, Application SW engineer, and customer). Also the editor should assist the user in avoiding overwriting configuration parameters which he is not responsible for or making inconsistencies by detecting and modifying parameter with dependencies.

Of course, to improve as much as possible these generic editors, on the top of them we implemented many additional accessories (e.g.: validators, additional consistency checker and advanced tool tips, plugets...), but still in the project, the time spent in doing the configuration was too long.

Therefore we have introduced on the top of CESSAR-CT a Form Composer framework which enables the users to implement easily specific editors. The Form Composer is a powerful and lightweight declarative UI framework based on XML as markup language. Using the XWT (XML markup language), the users are able to build their own editors and to bind any UI controls to the AUTOSAR model by specifying its fully qualified name. When more complex operations need to be performed, of course Java can be used.

Indeed, as AUTOSAR is very large, complex and still moving, the tool development effort can not only be covered by a tool team. So, with this framework, we give the chance to any users (e.g.: AUTOSAR function specialist, project user members...) to develop their customized editors. Moreover, as these Form Editors are placed on the top of the tool framework, they are very easy to deploy at the project level and do not need any update of the tool framework itself.

Outlook

The next phase in the development of AUTOSAR tool-chains will be driven by the new concepts of AUTOSAR release 4.0 that has been published end of 2009. The methodology and the meta-model had been enhanced in this release. "Functional safety"

Figure 1

 1 Figure 1 AUTOSAR methodology

Figure 2 :

 2 Figure 2: Exchange of models between OEM and supplier

Figure 4

 4 Figure 4 CESSAR-CT showing a SW-C editor

  presents a SW-C editor. It is a typical example for a situation, in which users normally have to open several tools in parallel. As CESSAR-CT is based on ARTOP the user gets a seamless AUTOSAR tooling. It had been shown that the extensibility mechanisms provided by ARTOP are of main importance for CESSAR-CT. CESSAR-CT provides a Pluget mechanism such that the engineering expert or also the end user can extend the tool. Code generators of different technologies can be integrated and a form editor enables the easy extensibility and customization of the UI.

Figure 5 Figure 5

 55 Figure 5 One editor based on several layers


Andreas Graf

Markus Völter

Integrating the AUTOSAR tool chain with Eclipse based model transformations

Keywords: AUTOSAR, Eclipse, Open Source, model transformation, Artop, Model Driven Engineering, AUTOSAR tool chain, software development process, AUTOSAR migration, automotive software, standardization, Engineering tools integration and interoperability, Open source, open systems

Introduction

AUTOSAR is establishing itself as a prominent standard in automotive systems and is expected to significantly improve software architecture and the software development processes. However, the introduction of AUTOSAR also poses some challenges. AUTOSAR only defines part of the development process, it does not specify how to interface tools in preceding process steps (such as functional design or requirements engineering) and to subsequent steps (such as testing or the actual implementation of the software).

In addition, AUTOSAR currently does not cover all aspects of automotive software. AUTOSAR software needs to communicate with non-AUTOSAR software, for example in the infotainment domain or even with off-board software. In addition to these conceptual challenges, the availability of tools can be a challenge, too. Similar to the early phase of UML, AUTOSAR tools are rather new and immature, and experience with those tools is not widespread. Tool features might be lacking and the integration of AUTOSAR tools into a company's overall tool chain will definitely not be provided out of the box by an off-the-shelf tool. It needs customization. The different steps in the AUTOSAR methodology might be addressed by different AUTOSAR tools from different vendors. Those tools need to interact with each other, increasing increases the need for an open approach that allows for customization and extension.

Scope of the paper

In this paper, we discuss a number of examples of the challenges above. The paper shows how these challenges can be alleviated by Eclipse based tools. Eclipse has established itself as an industrial strength development tool in industries that develop complex systems, such as aerospace and automotive. OEMs, first-tiers and suppliers already successfully use it for software development and as a rich and mature tooling platform. It can be seen as a platform for domain specific extensions that can be used out-of-the box (e.g. the C programming IDE "CDT") as well as a platform for additional tools. The open nature of the Eclipse platform allows for the integration of applications and project specific extensions.

With

Tools

In this paper, we look at Eclipse-based tools for model-driven software development. Eclipse is an open source project started by IBM a couple of years ago. Initially Eclipse was a Java development environment. However, from the start, Eclipse has been architected to be extendable in significant ways. Over time, a number of additional projects have been initiated as part of the Eclipse platform; among them the Eclipse Modeling project.

The Eclipse Modeling project is a collection of frameworks and tools for model driven development. In sum, they provide a wide range of solutions for various aspects of model driven development, from language definition to editor construction to code generation as well as model verification and validation.

This section introduces some of the tools from Eclipse Modeling. Specifically, we suggest those tools as a basis for integrating an AUTOSAR tool chain. EMF EMF, the Eclipse Modeling Framework, forms the basis for all Eclipse Modeling tools. At its core, it provides the Ecore meta meta model, a formalism for defining the abstract syntax of modeling languages. EMF comes with a set of related frameworks and tools for validation, query, persistence, and model transactions.

Xpand

Xpand is a framework for code generation (in fact, you can generate any kind of textual artifact such as configuration files or documentation as well). It processes models based on languages defined with EMF. The Xpand language itself is quite sophisticated in the sense that it contains a powerful expression language for querying and traversing models. It also supports polymorphism and aspects for code generation templates, making sure that nontrivial code generators remain maintainable.

Xtend

Xtend is used for transforming models into other models, for modifying existing models before they are fed into a code generator, as well as for implementing simple helper functions that are used as part of code generation templates.

Check

Check is used for validating models. Constraints are expressed in the constraints Check language (which embeds the same OCL-like expression language used in Xpand and Xtend). The constraints are then evaluated either in real time in the editors when creating models or as part of model transformation and code generation workflows.

Xtext

Xtext is a framework for defining textual domain specific languages. Based on a grammar definition, the Xtext tooling generates a parser, an EMF metamodel, as well as an editor for the language defined by the grammar. The editor provides all the features known from current IDE's: code completion, syntax highlighting, folding, customizable outline views, goto definition and find references, etc. Using Xtext, the effort of defining languages and providing editor support on a level that makes using that language productive and comfortable becomes significantly simpler.

GMF

GMF supports the construction of graphical editors (box and line style) for existing EMF meta-models. Using this framework, you can define graphical notations for your own languages.

Integration of the tools

Using the above mentioned tools together results in a complete toolset for model driven development. You define your meta-models using EMF, then you add a graphical or textual notation using GMF or Xtext, you use check for validating models, and finally, you can use Xtend and Xpand to transform the models created with your graphical or textual editors into other models or text.

An additional project, the modeling workflow engine, is used to orchestrate the processing of models. It provides facilities for loading models from files and supplying them to validation, transformation, and code generation components.

Artop

One of the fundamental motivations of AUTOSAR is to increase the reuse of software within the car. Transferring this motivation to the AUTOSAR authoring tools is a logical step. This motivation drives the Artop initiative. The AUTOSAR Tool Platform (Artop) is an implementation of common base functionality for AUTOSAR development tools. Artop uses many of the above mentioned frameworks to provide specific base functionalities for creating AUTOSAR tools. This includes a complete implementation of the AUTOSAR meta-model in the form of an Ecore model, an extensible validation engine for checking AUTOSAR specific and even project-specific constraints, a sophisticated workspace management that takes into account AUTOSAR's way of storing models and lots more. Artop is developed by the Artop User Group, a group of AUTOSAR members and partners and uses Eclipse not only as its technical platform but also uses a similar community approach to develop the software. Artop is open to any AUTOSAR member or partner.

Sphinx

The Sphinx project proposal [Sph2010] is a proposal for a new Eclipse Model Development Tools (MDT) subproject. While developing Artop a lot of functionalities were developed, that had their origins in the use of AUTOSAR, but were not specific to AUTOSAR at all. Similar functionalities were also required in other industries than the automotive domain, like avionics. The goal of the Sphinx proposal is to remove these features from the Artop platform and rather develop them in a larger community within the Sphinx project.

Bridging the gaps

Based on these tools, there are two basic types of tool integration: A tight integration on the Eclipse platform and a looser coupling through data exchange formats. The tight integration allows tools that conform to the Eclipse architecture to be integrated within one application. The user does not have to switch between different applications, because he sees an integrated development environment.

However, existing tools used by projects might not be based on Eclipse. By making use of the Eclipse modeling tools, a loose integration is still possible through data import and export.

Challenges and Solutions

In this section we show how to use the aforementioned tools to address a number of challenges in the integration of an AUTOSAR tool chain. To describe the relevant AUTOSAR models, we will introduce a textual description of AUTOSAR models called ARText. ARText is based on Xtext and an early implementation is available through the Artop distribution. This language is used to illustrate AUTOSAR models used in the examples, since it is much more concise than a graphical notation. Here is an example of a definition of a sensor component with an interface in ARText format: Adding AUTOSAR Import / Export to existing tools Challenge: All tools within the AUTOSAR tool chain have to be able to read / write data in the AUTOSAR XML format. The AUTOSAR XML-format is a complex data exchange format. Adding reading / writing functionality to an existing application requires significant effort. If every tool re-implements the XML functionality, the end user basically pays several times for the development of a nondifferentiating feature. The cost and time can be significantly reused by making use of Artop and the Eclipse modeling tools. Solution: Artop provides capabilities to read and write the AUTOSAR XML formats to and from the Eclipse EMF. Using model transformations, AUTOSAR models can be converted to the native format of existing tools.

Figure 2 -Integrating non-AUTOSAR tools by model transformation

For the example, a transformation of the AUTOSAR model into a CSV (Comma-Separated-Value)-file is given. CSV is a common file format that can be read by various spread sheet and database tools. Each line of the output should contain a software component name and information about the ports of that software component. A Xpand template could be similar to the template shown in Fragment 1.

Code Fragment 1 -M2T of AUTOSAR into .csv Code Fragment 2 -CSV Result

The first line of the output file contains the component of the short example given in the introduction with the specification of the provided part. The second line shows an additional software component to illustrate the structure of the output file. Any output file in a textual format can be generated by Xpand.

Integration of Behavioral Models

Challenge: AUTOSAR explicitly provides no means for the specification of the behavior (program logic) of software. In model bases software development, a number of modeling approaches are well established (such as state machines or dataflow modeling). However, AUTOSAR does not specify a mapping to behavioral modeling paradigms. The linking and synchronization between with artifacts in other modeling tools is not defined.

Solution: Use model transformations to synchronize the AUTOSAR model with a behavioral model. This helps to avoid redundant modeling of elements in more than one tool and manual synchronization. The exemplary solution links AUTOSAR models with UML state machines.

The meta-model elements of AUTOSAR and the state machine have to be mapped. A state machine needs to react to data being received. For this solution, we map AUTOSAR data elements to state machine triggers. Based on this mapping, a modelto-model-transformation generates the skeleton of a state machine and infers the required events / triggers from the AUTOSAR specification.

Code Fragment 3 -M2M of AUTOSAR into UML state machines

The code fragment generates a state machine for every software component and to keep the models synchronized, adds a trigger for each data element of required interfaces (i.e. incoming data). Developers who are more inclined to textual formats will benefit from a less steep learning curve when developing AUTOSAR models with ARText.

Project Specific Code generation

Challenge: Existing tools might not be prepared for AUTOSAR-conforming code generation. Manual post processing of the code is necessary. Solution: Create AUTOSAR conforming code by using customized generation templates based on Xpand.

For the exemplary integration of open-source state machine modeling / simulation, the Yakindu tool generation has been made AUTOSAR conforming.

The state machine for terminal control can be transformed into AUTOSAR compliant code that uses the RTE as an interface to get notified of incoming transition triggers and reacts by sending data through the RTE.

Migrating Legacy Models to AUTOSAR

Challenge: Migrate existing component models to AUTOSAR. Before the introduction of AUTOSAR, projects often modeled the software architecture with other notations (e.g. UML). These models have to be migrated to AUTOSAR. Solution: Load the models into Eclipse and transform them to AUTOSAR. Most UML2 should have a XMIconforming export. These models are loaded into a UML2-EMF model and subsequently transformed to Artop models directly by Xtend or to textual representations like ARText.

Suppose that every class in a UML model should be transformed into an AUTOSAR software component. The following Xtend transformation will perform this transformation.

  Eclipse's latest Galileo release, several mature tools for model-driven software development (MDSD) have become available. These provide a flexible and low-cost set of tools for bridging the gaps in existing AUTOSAR tool chains. The paper is structured as follows: We first introduce the AUTOSAR tool platform Artop and a number of open source Eclipse Modeling tools and explain their role in model driven development. We then show example challenges in the integration of an AUTOSAR tool chain and sketch solutions for these challenges based on the Eclipse based tools introduced.

  interface senderReceiver cardata { data int32 speed } component atomic Sensor { ports { sender X provides cardata } } Model-to-Model-Transformations and Model-to-Text-Transformations are shown as examples in the solutions to the challenges. The code fragments of the transformation are for illustration only. Real transformations might include additional code.

Figure 1 -

 1 Figure 1 -XML Readers and Writers are a redundant functionality in the tool chain.

Figure 3 -

 3 Figure 3 -AUTOSAR Data Element as triggers in state machines

Figure 4 -

 4 Figure 4 -State Machine as input to the generation.

Code Fragment 4 -M2M of UML to AUTOSAR

The second create function will create an AUTOSAR package in the destination model and call the transformation for every class in the UML model. The semantics of the class to component transformation is specified in the third create statement. Here it is a simply copying of the name.

Generating RTE for non-AUTOSAR Basic SW

Challenge: Implement an AUTOSAR RTE on platforms that have no AUTOSAR Basic Software available. One of the suggested migration strategies to AUTOSAR ECUs is the use of legacy BSW with AUTOSAR conforming application layer as a first step [AR2010]. However, COTS RTE generators cannot be used, since they usually do not support project specific legacy basic software. Solution: Use Xpand to generate a RTE that conforms the API for the application software and interfaces to the platform specific basic software. Supposing, that a communication call in the legacy software would have the signature "void Legacy_SendCall(…)", a RTE that makes use of this generation can be generated by a code fragment like:

Code Fragment 5 -M2M of UML to AUTOSAR

Conclusion

In the paper we showed some of today's recurrent challenges in tools and described the need for more integrated tool chains. Challenges in the integration of an AUTOSAR tool chain can be solved by the use of inexpensive Eclipse based tooling. An open platform is the precondition for an integrated tool chain. The solutions shown in this paper have been applied in various projects.