P Amey

B Dion

Combining Model-Driven Design With Diverse Formal Verification

Keywords: Model-driven-design, formal-methods, static-analysis, verification, safety-critical

Two historically diverse research streams are now delivering strong industrial performance in the engineering of high-integrity, software-intensive systems. The earlier of these is the use of sourcelanguage-based static analysis and formal verification. The more recent is the use of modeldriven design coupled with automatic code generation. Although both have been effective, neither is without problems. Fortunately, these approaches are not mutually exclusive and combining them offers a route to ultra-high integrity at low cost. The paper exemplifies the approach by describing the combining of SPARK and SCADE and illustrating the benefits and opportunities that this brings.

Introduction

The challenge of producing high-integrity software doesn't get any easier. Furthermore, the challenge exists in a commercial environment which constantly demands we meet it faster and more cheaply. The old adage that you can only have any two of faster, better, cheaper is constantly under attack with all three being demanded simultaneously.

There is clear and compelling evidence that we can only hope to meet this challenge by processes that favour error prevention over error detection and forward prediction of correctness rather than retrospective demonstration of correctness. Such approaches come with various labels including "correctness by construction" and even "lean software engineering".

A key ingredient of such constructive approaches is the use of mathematically-sound, formal methods. Only by driving out ambiguity early in the development lifecycle can we hope to achieve a fully constructive approach.

Formal methods are sometimes criticised for their apparent difficulty and an encouraging trend is the embedding of formal techniques in graphical tools which can combine visual attractiveness and ease of use with an underlying mathematical rigour. (As an aside, this is very similar to tools used in other engineering domains such as finite element analysis and computational fluid mechanics which also hide heavyweight mathematics behind a convenient user interface).

These promising approaches to introducing precision and rigour to the early lifecycle phases must not be allowed to reduce our commitment to precision elsewhere, for example in code-based static analysis and verification activities. The aim is to spread rigour throughout the lifecycle not just move it from one place to another.

The combination of mathematically-supported, model-based design and code-based, formal verification is therefore a very interesting one. We illustrate the potential benefits from such a combination using SCADE as an exemplar of rigorous model-based design and the SPARK language and tools as an example of rigorous codebased verification.

The Challenge

The challenge of producing ultra-high integrity software, for use in life-critical or similarly demanding domains, is not to be taken lightly. Firstly the level of integrity required can be extraordinarily high. It is not unusual for failure rates as low as 10 -9 per hour to be demanded. Given that 10 9 hours is 114,000 years, the requirement is that we believe our system will only have a 50% chance of suffering a softwareinduced failure in 57,000 years of operation. For numerate engineers with a conscience that is probably a claim we wouldn't want to make at all; for sure it is not a claim we should make lightly. Unfortunately, the challenge is even harder than suggested by these rather stark figures. It is harder because we not only have to achieve the required integrity but also produce a credible case that we have done so before the system enters service. Achieving and demonstrating integrity before there is any service experience is a unique challenge for the producers of safety and security critical software. There are many other software systems that have become extremely reliable, for example telephone exchange switches and even the Linux kernel; however, none of these could have been predicted to be so reliable before deployment (and most were not !). The twin challenges of producing high integrity software and knowing that you have produced it place great strains on the techniques and tools used in its construction. Crucially, it is clear that we cannot rely on dynamic testing alone for the construction of such systems. Dynamic testing has both theoretical and practical limitations. Theoretically, there is overwhelming mathematical proof that claims for software reliability in the ultrahigh integrity domain (<10 -6 per hour) cannot be sustained by statistical testing alone [START_REF] Littlewood | Validation of Ultra-high Dependability for Software-Based Systems[END_REF][START_REF] Butler | The Infeasibility of Quantifying the Reliability of Life-Critical Real-Time Software[END_REF][START_REF] Littlewood | Limits to evaluation of software dependability[END_REF]. Practically, dynamic testing has the drawback of pushing verification towards the back end of the development lifecycle where the correction of any errors uncovered will be at its most expensive and pose the greatest risk of schedule delays. The challenge of producing high-integrity software and an acceptable cost can therefore only be met by constructive techniques using unambiguous notations which are amenable to logical reasoning. The next two sections describe examples of two different approaches which exemplify the application of constructive techniques using unambiguous notations.

The first, SPARK, is centred on programming languages and their verification. The second, SCADE, is concerned with model-based designs and their verification. The remainder of the paper describes the beneficial synergy that arises when these complementary approaches are combined. In principle the approach taken is applicable to other model-driven design methods and implementation languages; however, an essential prerequisite is that both component technologies are sufficiently rigorous and formallybased as to make the links between them exact. It is for this reason that the approach is illustrated with SCADE and SPARK which jointly meet this requirement.

Overview of SPARK

SPARK [START_REF] Barnes | High Integrity Software -the SPARK Approach to Safety and Security[END_REF] is an annotated subset of Ada with some specific properties that are designed to make static analysis both deep and fast. The annotations take the form of special comments which are ignored by an Ada compiler but have semantic meaning for SPARK's support tool, the SPARK Examiner. Annotations range in complexity from the description of data flows via global variables through to full preand post-condition predicates suitable for the formal verification of operations.

A key, indeed we believe unique, property of SPARK is its complete lack of ambiguity. The language rules of SPARK, enhanced by its annotations, ensure that a source text can only be interpreted in one way by a legal Ada compiler. Compiler implementation freedoms such as sub-expression evaluation order, cannot affect the way object code generated from a SPARK source behaves. For example, a complete detection of parameter and global variable aliasing ensures that SPARK parameters have pass-by-copy semantics even if the compiler actually passes them by reference. The removal of ambiguous language constructs allows source-based static analysis of great precision and efficiency. Instead of using static analysis techniques to look for errors we can use them to prove the absence of certain classes of errors. This rather small linguistic difference masks a hugely-significant practical difference: only by eliminating ambiguity can we reach the goal of constructive, rather than retrospective, software verification. We can exploit this language property using the associated SPARK Examiner tool which divides the verification task into two parts: Firstly we seek to show that the program is well-formed. That is, the program could be a correct implementation of some useful specification because it is free from egregious errors such as data flow errors (e.g. use of uninitialized variables) and run-time errors (e.g. array bounds violations). Only when this is done do we seek to show that the program actually is a correct implementation of its specification. This conceptual separation is quite deliberate: the first condition provides the logically consistent framework which makes the second feasible. The idea that we should ensure a program could be correct before trying to establish whether it is correct was a major motivator for the development of information flow analysis. See for example the seminal ACM paper [START_REF] Bergeretti | Information-flow and dataflow analysis of while-programs[END_REF] which noted that: "most programs presented to verifiers are actually wrong; considerable time can be wasted looking for proofs of incorrect programs before discovering that debugging is still needed".

The first verification step, showing wellformedness, is largely achieved by data and information flow analysis.

Flow analysis is important for two reasons:

1. Elimination of undefined variable values by data flow analysis is an essential step in providing a sound environment for program proof. Clearly such proofs are complicated if we have to allow for unknown and potentially invalid data items.

Information flow analysis, which establishes the influence of variability of one data item on another, provides the main foundation on which we can build segregation arguments.

Once we have achieved the goal of having an unambiguous source text which is free from gross errors such as reading of uninitialized variables we have established a baseline that will prove very useful when we come to consider how to combine SPARK with model-driven design methods. For these purposes two key conditions are:

1. The ability to demonstrate properties of the code using proof techniques.

• Strong typing • Explicit initialization of data flows

• Explicit management of time (delays, clocks, etc) 2. The ability to do such analyses with access only to the annotated specifications of units on which the item being analyzed depends.

• Simple expression of concurrency (data dependencies)

The associated SCADE Suite toolset is an environment for the development of safety-critical software. It supports the model-driven driven paradigm as illustrated in Figure 2. The modeldriven approach has the following features:

An illustration of the power of the first of these properties is the ability to prove that a SPARK program is free from run-time exceptions. The Examiner toolset includes provisions for the automatic generation of proof obligations that correspond to each predefined run-time exception check defined by the Ada language. Discharging these proof obligations is sufficient to guarantee that the associated exception can never be raised. The process is described in [START_REF] Chapman | Industrial Strength Exception Freedom[END_REF]. Again, usefully for the purpose described in this paper, these forms of analysis can be taken right to the boundaries of the system and down to the bit level. For example, SPARK analysis is fully capable of dealing with concept of invalid values such as might be returned by a malfunctioning external interface or port.

• The model is the component's software specification. • Documentation can be generated from the model. • The model can be exercised by simulation.

• Model coverage analysis can be performed to assess these test-based verification activities. • Formal proof techniques can be applied to prove safety properties. • Code can automatically be generated from the model, using the code generator.

We will see in a later section how the these properties are extremely useful in our aim of combining source-based static analysis with modelbased design.

Overview of SCADE

In this section we will see how the SCADE methodology and toolset allows the description of rigorous and complete software specification models based on a formal notation [START_REF] Halbwachs | Synchronous Programming of Reactive Systems[END_REF][START_REF] Berry | The Foundations of Esterel[END_REF][START_REF] Dion | Correct-by-Construction Methods for the Development of Safety-critical Applications[END_REF]. This notation includes both block diagrams and safe state machines as shown on Figure 1 below: In this paper, we will not further comment on the model coverage and the formal verification activities.

The interested reader may refer to [START_REF] Bouali | Using Formal Verification in Real-Time Embedded Software Development[END_REF]11].

Finally, the SCADE KCG Code Generator automatically generates the complete source code implementing the software specifications for both data flows and safe state machines. It does not just generate a skeleton; the complete dynamic behavior is implemented.

The SCADE Suite KCG 4.2 C code generator has been qualified with respect to DO-178B at level A [START_REF]DO-178B "Software Considerations in Airborne Systems and Equipment Certification[END_REF], to be used for the development of the Airbus A380 flight software. This means that the verified and functionally validated model of the software is safely translated to C code. Thanks to the formal input model and the certified code generator, the behavior of the generated code is fully safe and deterministic.

Remaining problems

Thus far we have described two different approaches to the development of high-integrity software. Both have strong formal foundations but they are otherwise rather different in scope and concept.

Since both approaches can point to successful industrial use the questions arise: "what benefit could we anticipate from attempting to combine them?" Should we, instead, simply regard them as alternative approaches rather than seek to make them complementary approaches?

The value of combining the two different techniques depends on whether each, in isolation, has any weaknesses and, if so, whether combining them provides a way of addressing those weaknesses. Note that "weakness" here doesn't mean "defect", it simply recognizes that no individual technique can be expected to address all aspects of software development.

We therefore now examine what parts of the software development problem space are not fully addressed by each of our two constituent technologies.

SPARK

SPARK is, at its heart, a high level programming language.

It contains strong features for the effective expression of software designs but does not directly address the issue of how those designs, especially at the more abstract, architectural level, are created. SPARK users increasingly want to use graphical design methods before moving to the lower abstraction level of SPARK code. Clearly graphical design methods can be used with SPARK; however, unless the graphical method has strong semantics, we are forced to defer verification activities until we have produced SPARK code that purports to implement our model. SPARK provides very strong support for such verification and can produce useful results much earlier than can be obtained by dynamic testing; however, detection of architectural design errors would still be later than might be achieved if the verification could be performed directly on the graphical design model. Also arising from its programming language roots is the issue of how SPARK code is actually produced. Generally it is hand crafted. While our experience is that the coding phase represents a rather small part of the overall development lifecycle, and SPARK provides very considerable protection against errors being introduced during the coding phase, it is nevertheless true that developers are increasingly seeking to see automatic generation of at least part of their source code.

Since SPARK is an unambiguous and precise language effective automatic code generation requires that the design representation from which generation will take place is also precise. Certainly the generation of non-SPARK source code by some means and its hand conversion to SPARK for analysis purposes would be a rather pointless exercise giving few of the benefits of either code generation or SPARK.

SCADE

By contrast with SPARK, SCADE is firmly founded in the design and modelling phases of the development lifecycle.

Model-driven design, coupled with automatic code generation, neatly solves the early design phase problems but it may introduce a new difficulty: the large semantic gap between the model and the generated code.

Although the more rigorous graphical design tools, exemplified by SCADE, allow useful analysis of the integrity of the design models, the problem of the trustworthiness of the generated code remains. This has been solved in practice for some specific situations like the SCADE C code generator that has been qualified for DO-178B and certified for IEC 61508. In some other cases, this solution does not exist. We may also face some standards like Def Stan 00-56 where the concept of qualification or certification of a development tool has not been defined and other means will be required to demonstrate the correctness of the automatically-generated code.

Another issue with model driven design is ensuring that high-level safety properties of the system are adequately captured in the model specifications. It is common in model-driven approaches to regard the model as the specification (even, sometimes, the requirements) for a component. The model may very accurately capture low level details of each modelled component; however, certain system level properties may depend on the interaction of several individually modelled components. We can imagine a system, for example an aircraft landing gear controller, where switch and actuator subsystems can be modelled in great detail but where important system-level safety properties such as "the undercarriage must not be capable of being retracted when the aircraft is on the ground" can only be established by considering how the individuallymodelled subsystems work together.

Finally, model-based designs rely on a computation model that excludes things such as invalid values and machine representation of values. Validation of the models, and code generation from them must assume that variables are well-formed and correctly in their respective types. The models therefore exist inside a boundary of hand written interfaces or "device drivers". The integrity of these drivers and other pieces of "glue" code, as well as their correct interaction with automatically-generated code, has to be established by some other means.

We can summarise these areas for improvement thus (the technology which would benefit from solving each problem is shown in parentheses):

• Rigorous analysis can beneficially start earlier than the coding phase (SPARK). • Having to hand-craft all code may be less efficient than auto-generating some of it (SPARK). • Trustworthiness of automatically-generated code has to be demonstrated to a level dictated by various standards in use (SCADE). • High-level safety (and other) properties may depend on interaction between modelled components (SCADE). • Auto-generated code must work with device drivers and other hand-written, "glue" code (SCADE).

Why combine?

As can be seen from the discussion above, we are in the happy position of having two technologies, both with strong formal foundations, whose strengths and weaknesses dovetail almost perfectly. By combining them we can retain their individual benefits and produce a combined development approach which more completely addresses the overall software development challenge. Furthermore, the formal foundations of both methods makes it possible to combine them in a strong and precise manner.

If we imagine the existence of a formally-based, model-driven design tool which can produce models from which code in an unambiguous and independently verifiable language can be generated, we can reap the following benefits.

The design tool assists with the vital and challenging task of getting the architecture and conceptual integrity of the system right.

Furthermore, the rigorous nature of the model allows us to carry out various forms of analysis and validation; this provides early error detection which is essential for efficient work and allows a forwardflowing, constructive design technique to be used (SPARK gap addressed by SCADE).

Having eliminated as may errors as possible we can automatically generate code from the validated model (SPARK gap addressed by SCADE). The generation of source code in an unambiguous notation reduces the possibility of the semantics of the model and the semantics of the generated code differing and therefore increases the value of any model-based verification that has been carried out.

Since code generation is a form of translation, it is clearly easier to translate one precise notation into another, than it is if one (or both) of the representations is potentially ambiguous.

Finally, the generated source code, because it is in a precise language designed for analysis, allows a completely independent and diverse verification to be carried out on both the auto generated code and any supporting hand-written components. Furthermore, this analysis can reach closer to the boundaries of the system because SPARK is able to produce useful results from analysing low-level, device-driver code (SCADE gap addressed by SPARK).

The semantic gap between the verified source code and the resulting object code is much smaller than that between the original model and the object code. (Of course the problem of compiler integrity remains but that is a separate problem common to all use of high-level languages).

Finally, high-level properties of the entire set of assembled sub-system components may be proved using SPARK's proof-based verification techniques (SCADE gap addressed by SPARK). When doing this last form of verification we have another choice. Recall that SPARK can be analysed without requiring access to the full implementation (bodies) of each program unit; only the annotated specification is needed. Provided the SCADE code generator translates specification information in the model into suitable SPARK annotations, we have the option of ensuring that the required properties of the entire set of assembled sub-system components are met without re-analysing the auto-generated body code. In effect, this gives two levels of verification : for the most critical systems and the most demanding standards we can do a full, independent and diverse verification of all the code, both handwritten and auto-generated. For less demanding situations, where we are content to take on trust that the auto-generated code will be a faithful implementation of its design model, we can show that the components fit together properly without having to look at the auto-generated bodies at all. These forms of diverse verification are a direct match to the requirements of standards such as Def Stan 00-56 [START_REF]Safety Management Requirements for Defence Systems[END_REF].

Integration in practice

Approach

The approach we have taken relies on the existence of SCADE Ada Code Generator that generates the proper SPARK Ada subset and then on using the SPARK tools for performing formal verification activities on the generated source code. Initial experiments of this coupling have been made and have been very promising. SPARK offers a level of verification that matches or in some case exceeds the one of SCADE, thus providing a diverse verification path. Further work will be performed in introducing at the SCADE model level more specific annotations that will denote safety SPARK properties that could then be used as an input by the SPARK verification tools. There is also considerable value in enriching the type model at the SCADE level to include such things as valid numeric ranges of scalar objects. SPARK's ability to reason about freedom from runtime errors is greatly enhanced if values are bounded in this way rather than just being, rather lazily, considered to be, say, "integers".

Practical benefits

We foresee benefits in both improved code quality and in reduced development time and cost. Although it is a frequently stated mantra that you can only have two out of these three, it is our increasingly frequent experience that the best way of reducing cost and time is to improve quality, provided that the quality improvement is achieved by bug prevention rather than a painful, retrospective period of bug detection and removal [START_REF] Amey | Correctness by Construction: Better Can Also Be Cheaper[END_REF]. The logic is inescapable: there is no cheaper bug to remove than the one you never introduced! The use of notations with strong formal foundations is a prime way of avoiding the introduction of errors. The encapsulation of those notation in a graphical design environment makes them much more approachable and usable.

We envisage the time benefit being delivered as a result of effects that are best shown diagrammatically. In the following diagrams, which mimic the familiar "V lifecycle model", elapsed time flows from right to left and increasing level of design detail flows from top to bottom. Descending lines are production activities and ascending lines are verification and validation activities.

First, we take the V model itself as a starting point. verification could be achieved by always generating SPARK code, as a background activity, regardless of the intended end purpose and implementation language chosen. Analysis of properties such as freedom from run-time errors could then be fed back and displayed at the model level. Such an approach could provide protection from events such as division by zero even if the eventual implementation was produced using the SCADE qualified C code generator. Note that this possibility can only be considered because of the rigorous, formal nature of both SCADE and SPARK; clearly the analysis would be of little or no value if we can't be sure that the semantics of the model, the automatically-generated, background SPARK version of it, and the automatically-generated, deliverable C code are identical.

Conclusions

Often we have to make a choice between different engineering approaches. Sometimes having to make this choice is rather undesirable because both options have advantages that we would like to benefit from. In the case of combining the proven benefits of both code-based formal verification and rigorous model-driven development, we find ourselves in the happy position that we don't have to make this hard choice; we can have the benefits of both approaches.

Our experience with the combining of SCADE and SPARK is that we do indeed retain the benefits of each.

Crucially, however, it appears that the combination only works because both SCADE and SPARK have formal roots. Clearly combining and translating between two exact notations is both easier and more effective than if one or other component is imprecise in some way.

Finally, we note that the use of diversity and redundancy are key engineering techniques with a long industrial pedigree; combining model-driven design with formally-verifiable programming languages brings them to the information age.

Acknowledgement

The authors acknowledge the contribution of their colleagues to this work.

Figure 2 :

 2 Figure 2: Model-based design and verification with SCADE A user of the above toolset can the apply the following three "golden rules": • Share unique and accurate specifications. • Do things once (i.e. do not rewrite descriptions from one activity of the life cycle in another). • Do things right (i.e. prevent errors or at least detect them in the earlier stages of a project). Now, when it comes to the verification activities, support is provided by a combination of three different tools: Figure 1: SCADE Block-diagrams and Safe State Machines • The SCADE Suite Simulator supports interactive or batch simulation of a SCADE model, for both data flows and safe state machines. The above SCADE notation has been formally defined and it has the following characteristics that are key in the targeted application domain, i.e. the development of safety-critical systems: • The SCADE Suite Model Test Coverage (MTC) tool is used to measure the coverage of the

Figure 3 :

 3 Figure 3: Traditional V Model When we add trustworthy code generation to a formal system model, we effectively reduce coding time (in principle, to zero) and remove some low level verification activities. We can conceive this as transforming the V model into a Y model, as shown in Figure 4 below.Note that the overall width of the Y is smaller than was the V showing a saving in time. The automation of some activities also offers a reduction in cost.

Figure 4 :

 4 Figure 4: "Y" Model Showing Automatic Code Generation In practice, we do not achieve 100% code generation because of the need to write low level interfaces, device drivers and other glue code. The final diagram shows this in a hybrid V and Y lifecycle. The Y is augmented with a smaller activity showing the hand production of interface and other glue code.In this case we have achieved complete verification of all the code to a very detailed level but we have still reduced the elapsed time compared to a tradition approach. Furthermore, we have two forms of verification taking place: an early, modelbased analysis; and a later, independent, codebased analysis.

Figure 4 :

 4 Figure 4: Combined Model Showing Diverse Verification Activities 7.3 Possible future work One tentative but very interesting possibility arises from the availability of an independently analyzable representation of the graphical design model. It might be the case that additional model-based


T Erkkinen
email: tom.erkkinen@mathworks.com

Model Style Guidelines for Embedded Code Generation

Keywords: Model-Based Design, Production Code Generation, Simulink

Embedded systems are increasingly being developed using models. These models may have started with the system engineer or algorithm developer as an executable specification or algorithm description. However, these models also now serve as the entry point for software engineering, thanks to automatic embedded code generation. As a result, software engineers want to take advantage of these same models, adding constraints on system behavior; describing characteristics that are needed for implementation, such as fixed-point details; or linking components in the design to relevant parts of requirements and specification documents. This paper describes model style guidelines for automatically generating fixed-point and floatingpoint code for embedded systems. The guidelines are based on best practices and techniques derived from actual industry examples in aerospace and automotive companies worldwide.

Introduction

The model structure and code generation configuration options significantly impact the efficiency, clarity, and traceability of the automatically generated code. While model style and verification may not be a top issue for early algorithm development or rapid prototyping, it is extremely important for embedded system development, especially flight software applications. Furthermore, the composition of the model also eases the process integration with the "test-in-the-loop" (e.g., SiL, PiL, HiL) phases that are needed, while improving component reusability and Intellectual Property management.

Increasingly, companies that use modelbased design approaches --particularly in aerospace and automotive --are collaborating to define model style guidelines, which they can individually tailor and apply as a key aspect of their software development processes.

This provides system engineers and algorithm developers greater freedom to innovate early in the process, while resulting in models that can be augmented, refined, and constrained with implementation details for efficient embedded code generation later in the development process.

Discussion

A system model has components for modeling both the algorithm and the environment where the algorithm executes. The algorithm may be a control law or a signal processing algorithm. The environment may include actuators, sensors, and the plant. Or, the environment may represent a communication transport layer with varying latencies and noise.

The algorithm model will eventually be deployed as embedded software on a microcontroller, a digital signal processor, or a multi-core device. The plant model may eventually be deployed on a test system for HiL testing and system validation.

A typical model is comprised of block diagrams, state machines, and embedded language scripts. Examples of system models are shown in Figures 1 and2. The examples use MathWorks products. Note that the system models are comprised of individual components. The components may be subsystems pulled from libraries, which have dependencies based on the system model they are placed in. Or the components may be separate models that are atomic and isolated from the properties of the system model they are placed in. The simulation results can be shown in many ways such as scopes, gauges, and virtual animation. See Figure 3 for an example of an aircraft system simulation interfaced to a flight simulator. The results can also be produced as massive amounts of data that are reused as test suites during detailed design and implementation. The simulation model can also be used as an executable specification. The fidelity of the model dictates whether or not the model specification is high-level or low-level.

There are other aspects in addition to model fidelity to be considered during the model development process. Some aspects span multiple groups or even different companies, such as OEMs and suppliers. For example, Toyota Motor Corporation and DENSO Corporation discussed important aspects that guide their modelling and production code generation environments [1].

Toyota needs automatic code generation tools that are system development-oriented:

• Ease of simulation

• Easy operation

• Seamless linkage with other system development tools and data DENSO needs code generation tools that are software development-oriented:

• Conformance to coding rules

• Well defined software structure

• Seamless linkage with other software development tools and data

One of the keys to a successful model style is to develop models that allow for fast, easy, and seamless transitions between system engineering and software design.

Detailed Design

Technology improvements starting in the late 1990s have allowed high-level models to be refined and elaborated to great levels of detail. Software design details such as fixed-point data type, scope and storage class, function and file partitioning, and explicit identifier control are now possible.

Back and forth transition between model fidelities improves system and software communication and also fosters a development approach that encourages iterations for optimizing code, addressing derived requirements, and improving design integrity.

Data type design is a good example of this back and forth flow. Early during high-level specification, numerical accuracy involving data types is not a major consideration. The models typically use double precision data for assessing algorithm performance.

Once the performance is deemed satisfactory, however, detailed data type design should occur. Single precision or fixed-point types are then derived for each signal and parameter in the model based on embedded target resources or other factors.

Once the data types are assigned, it is important to compare the detailed types with the original high-level specification.

Data type override is one way to accomplish this comparison. With data type override, a developer is able to make the simulation and code generation tool ignore the detailed data types and act upon the model as if all data elements were specified as a specific floating point type (e.g., double precision real). This greatly facilitates comparison and verification of the detailed design with its higher-level representation.

One could also use a data dictionary driven approach. For example, a floating point data dictionary could be loaded and used for rapid prototyping simulation, while a fixedpoint data dictionary could be loaded for embedded, mass-production target environments. To do this, the model needs to be developed in a style that supports inheriting data types from an external or workspace data dictionary. The external data dictionary could be provided, for example, using a corporate database tool, Excel, or XML file.

An example of a data dictionary and a data dictionary element for a lookup table is shown in Figure 4.

Code Generation

For companies trying to maximize code efficiency, it is important to have a good understanding of the appropriate blocks, appropriate block parameters settings, and the appropriate code generation settings.

As with any language, teams should agree on the language aspects to use or not use for a particular project. The aspects may be based on the target environment, the software integrity level, or other criteria.

Model tool documentation such as the block data types table shown in Figure 7 guides developers on which constructs to use.

Figure 7: Block Data Type Table for Production Code Generation

In addition to the blocks, the block settings heavily influence the format of the generated code. One of the key settings in a fixed-point environment is the check for numerical overflow involving fixed-point calculations.

The block parameter form for a simple gain block in Figure 8 shows this setting. The Visteon metrics shown in Figure 5 noted that this saturation setting determined whether or not the automatically generated code was smaller, larger, or equal to hand code. If the setting was used "where necessary" the automatic code was approximately equal to hand code.

The code generation configuration settings also have a great influence on the generated code. One of the major groups of settings that is important involves the hardware implementation pane. This pane is where one establishes the target specific settings not defined by ANSI/ISO-C, such as integer word sizes.

By selecting the appropriate target hardware developers may realize significant code efficiency improvement. See Figure 9. It is important to note that Honeywell's automatically generated software was developed in accordance with criteria per DO-178B Level A software integrity [START_REF] Rtca Inc | Software considerations in airborne systems and equipment certification[END_REF].

Verification and Validation

Using Model-Based Design, verification and validation activities occur throughout development. A number of new technologies have recently been introduced that assist with this such as model advisor, model coverage tools, and in-the-loop testing.

One of the key benefits to establishing model guidelines is that they can be automated. The model advisor analyzes the model and checks for areas that may impede its use in production software environments. Some of the checks focus on the simulation aspects, others on code generation.

For example, one of the checks makes sure that model interface ports are well defined and do not inherit important characteristics such as data type and sample rate. Another check informs users if they are missing important code optimization settings. Figure 10 shows checks based on the model, the code generation settings, and customized user-provided settings.

Even if one does not use the model analysis tool itself, developers should inspect the many guidelines that it offers. Note that the model advisor also has an API for an organization to add their model checks. In addition to supporting requirementsbased testing and bi-directional traceability, the model should support test coverage analysis. One way to determine test coverage is to use a model coverage tool.

Figure 11 shows such a tool and highlights areas where the model was not exercised. Once the model has satisfied its test and coverage requirements, code can be automatically generated, as described earlier. As code implementation and integration moves forward, there are several opportunities to verify the implementation using SiL or HiL.

DaimlerChyrsler Trucks noted the importance of using SiL testing [START_REF] Wünsche | Model based development of Cruise Control for Mercedes Benz Trucks[END_REF] There are many other sources of guideline information including C code guidelines [START_REF]Guidelines for the Use of the C Language in Vehicle Based Software[END_REF], automotive model guidelines [START_REF]Controller Style Guidelines for Production Intent Using MATLAB®, Simulink® and Stateflow®[END_REF], large scale model guidelines [START_REF] Aberg | Strategy for Successful Enterprise-Wide Modeling and Simulation Using COTS[END_REF], and fixed point tips [START_REF] Nadarajah | Fixed-Point Modeling and Code Generation Tips[END_REF].

Developing a complete modelling and code generation environment takes some time and effort but the rewards are worth it.

Consider what Lockheed-Martin presented regarding their use of automatic flight code generation for the Joint Strike Fighter program flight controls [START_REF] Nixon | Flight Control Law Development for the F-35 Joint Strike Fighter[END_REF].

It is proven in CDA Phase:

• Successful flight tests of all variants with one OFP

• Reduced Software Defects (Early checkout in Engineering Simulations)

• Overall reduction in Manhours/SLOC of ~40%

Conclusion

This paper presented a few important guidelines and industry trends for using modelling and automatic code generation for production software.

Figure 1 :

 1 Figure 1: Vehicle and ECU System Model

Figure 2 :

 2 Figure 2: Radar Application System Model 2.1 Simulation In order for the model to be clearly understood, it needs to simulate. Successful simulation requires that the model compile and execute based on the values established for the model's diagnostic settings, such as array out-of-bounds error checking.

Figure 3 :

 3 Figure 3: Aircraft System Model Animation

Figure 4 :

 4 Figure 4: Data Dictionary Showing Lookup Table using Structure Data TypesVisteon Corporation has described their data dictionary driven approach for ECU software using automatic production code generation in an SAE paper[2]. This paper also includes code metrics comparing handwritten production code with automatically generated code as shown below.

Figure 5 :

 5 Figure 5: Visteon Production Code Metrics General Motors Powertrain also described their use of data dictionary driven development and code metrics at a recent conference [3]. They also presented hand vs. automatic code metrics as shown below in Figure 6.

Figure 6 :

 6 Figure 6: General Motor Powertrain production code metrics 2.2 Code Generation

Figure 8 :

 8 Figure 8: Saturation on integer overflow block setting enabled

Figure 9 :

 9 Figure 9: Production hardware settings used to deploy the automatically generated code Taking the time to establish these and other model and code generation guidelines can lead to impressive results beyond code efficiency. Honeywell Aerospace Corporation presented that they generated over 1.6 million lines of certified flight code within the past year using a COTS toolbased environment [4]. Honeywell also noted that their software process produced greater than six-sigma code quality.

Figure 10 :

 10 Figure 10: Interactive model coverage reportingAnother important verification step is to design and execute model tests. For safetyrelated systems, it is important that the test cases be based on the requirements. Bidirectional links between the model and the systems requirements in documents, data bases or requirements management tools is important and available. Requirementsbased comments can also appear in the generated code.

Figure 11 :

 11 Figure 11: Interactive model coverage reporting

  It was not possible to provide numerous detailed examples in the space provided but several references were provided containing numerous guidelines, examples, and tips. This paper also discussed approaches for verification and validation of the models and generated code. Industry examples were referenced.

	7. References T. Katayam, A. Ohata, Toyota; Y. Uematsu DENSO; "Production Code Generation for Engine Control System", International Automotive Conference, Stuttgart, 2004 http://www.mathworks.com/company/ events/programs_de/iac2004/present ations/08_pp_toyota.pdf Grantley Hodge, et al, Visteon Corp, "Multi-Target Modeling for Embedded Software Development for Automotive Applications", SAE Congress Technical Paper No. 2004-01-0269, Detroit, 2004 http://www.mathworks.com/products/rt wembedded/technicalliterature.html L. Michaels, General Motors Powertrain, Software-in-the-Loop Processor-in-the-Loop Hardware-in-the-Loop ECU Electronic Control Unit [1] [2] [3] SiL PiL HiL OEM Original Equipment Manufacturer FAA Federal Aviation Agency API Application Program Interface OFP Operational Flight Program "Automatic 8. Glossary SLOC Source Lines of Code

Code Generation Process", MathWorks International Automotive Conference, Dearborn MI, 2005 http://www.mathworks.com/industries/ auto/iac/presentations/michaels.pdf [4] B. Potter, Honeywell; "Achieving Six Sigma Software Quality Using Automatic Code Generation", Mathworks International Aerospace and Defense Conference, Manhattan


Keywords: Parking Systems, Sensors, Integrated Development Approaches, Model Driven Engineering 1. Overview of parking systems

A Methodology for Model Based Development of Application Software Modules Exemplified by Radar Based Parking Systems

Andy Yap 1 , Helmut Keller 2 1: MB-technology GmbH, HPC 050/G170, 71059 Sindelfingen, Germany 2: DaimlerChrysler AG, HPC 059/X914, 71059 Sindelfingen, Germany

Abstract: This paper addresses a methodology for the development of driver assistance systems. As an example the development of parking systems is described in detail. Throughout the paper the complete system including sensors, ECU and software is considered in order to provide better understanding of the overall development activities in each state of development.

A model based development approach is chosen for the early evaluation of the whole system. Graphical models are used throughout the process which is also advantageous for the extraction and the systematic validation of sub modules. The models are both used for the preparation of decisions in functional or software architecture and for testing and integration strategies.

For software modules containing core function applications the tool-supported development is presented, starting from basic ideas of new functionalities up to and including automatically generated production code for electronic control units.

Parking systems cover the range from pure optical assistance functions to fully automated parking. In addition various sensor principles are used or discussed, e.g. ultrasonic distance sensors as well as radar or optical image processing systems.

Other challenges include the activation and control of driving dynamics or the design of an acceptable human-machine interaction. The basic example of a parking system provides pure information for the driver, in this paper such a system is named PINFO. PINFO systems contain sensors and information processing to drive optical or acoustical output devices.

In contrast to this a fully automated autonomous parking system is considered that includes drive by wire technologies as acting devices in order to represent the possibly high complexity of challenges in development, in the text below it will be referenced as PAUTO. In this paper only this two versions of possible systems will be discussed. All other solutions are subject to similar conditions.

Functionality

Going through the process of entering a parking lot there are some sub-processes involved. The simplest approach contains just two steps. First the activities of identifying an adequate parking lot and in the second step the manoeuvre of placing the vehicle at the desired position. While performing the second step one main issue is to prevent accidents.

Based on these three topics (search, movement and accident prevention) we can classify the possible range of parking systems. The simple assistance function PINFO offers no support in step 1 or 2 but assists in topic 3 with additional information. Looking at a PAUTO type of system it will be actively influencing the vehicle behaviour in all three aspects.

Sensor principles

Most of the PINFO systems that are currently available, rely on ultrasonic devices as sensor principle in order to measure the distance from vehicle to possible obstacles. Using camera based systems for this type of assistance there is no need for sophisticated image processing as the user can be informed by displaying the raw image. Looking at PAUTO requirements, several results from image interpretation out of camera or radar sensors are necessary to fulfil the active parts in the system functionality. For radar systems plenty of calculation is necessary in order to have useful input for the control algorithms. The area that has to be monitored requires more than one sensor and leads to the demand for sensor data fusion as shown in [START_REF] Schmid | A new dimension of active and passive safety with PRE-SAFE and Brake Assist BAS PLUS in the new Mercedes-Benz S-Class[END_REF] for another assistance system.

System decomposition

All technical systems can be decomposed using different methodologies. For example looking at the component level, a system is divided into the parts that are relevant for assembly. Using functional decomposition will lead to parts of the system that are logically connected but may be implemented in different ways. Another approach is looking at the individual parts. The components could be mechanical, electrical, standard software, traditionally developed software modules or software modules that are designed by model based methods. This leads to a combined system and software architecture. Instead of looking at just hardware and software that require different levels of interaction during the development, we focus on the software in this paper which can be made in the three different ways named above. More details regarding the software modularisation will be given in chapter 4 below.

Model based approach

A model based development approach is chosen for the early evaluation of the whole system. For several years now a large variety of very powerful domain specific computer aided design, simulation, analysis and test tools offer support for the development of embedded components (e.g. digital and analogue microelectronics, software, mechanical sensors and actuators or optical components). Also there are some system level design and analysis tools available. However, these are individual tools. Consequently, due to the complexity of embedded system design, today it is an accepted fact that a single integrated design environment does not yet exist. The development environment should be capable of handling all requirements for designing and verifying the complete embedded system and even more all possible system components, packaging and interconnections. In addition, there are no or only few design standards and no common databases in use. For that reason, gaps for important design steps, especially in early system design phases occur.

Combining the situation described above with the demand to focus on safety for vehicle systems there is a need to consider safety and quality standards. Regarding process assessment, the simple transfer of aviation related standards like DO-178B for automotive specific topics is not the best way [START_REF] Kreuzinger | Softwareentwicklung im Automobilbau Anforderungen, Standards und Vorbilder[END_REF].

The automotive industry heads for own standards and special automotive variants of standards like ISO 15504 are jointly defined. Concerning the development process and the results, the upcoming focus on safety, as addressed in IEC 61508, can be satisfied by systematic procedures [START_REF] Savic | Dynamic Safety Assessment of an Advanced Driver Assistance System According to the IEC 61508[END_REF] and can also be supported by complete methodologies [START_REF] Dion | Efficient Development of Embedded Automotive Software with IEC 61508 Objectives using SCADE Drive[END_REF]. When the complete system is addressed concepts like information models [START_REF] Conrad | Eine integrierte Methodik für die modell-basierte Entwicklung von Steuergeräte Software[END_REF] can be used to create an integrated methodology for the system as a whole.

Therefore we [START_REF] Sax | A seamless model based design flow for embedded systems in automotive applications[END_REF] concentrate on the model based software development for embedded systems and on establishing an integrated design flow from first model based specifications to production code for microcontrollers. Such an environment for the SW development for embedded system design includes methodologies and tools, which support the system engineers. The application of tools results in short conceptual design cycles by supporting reusable software modules and allows implementation independent design as long as possible in the process.

The analysis of requirements is followed by the transformation of the specification from graphical notation to an executable computer format. After that, the reproduction of timing conditions by rapid prototyping leads to an executable specification.

Then, for the software the processes of raw and fine design, implementation and code-generation are employed. The traditionally coded parts are implemented within an established development environment and standard software modules are purchased. All the artefacts flow into the integration of all components to a complete system Integrated testing methods and an overall configuration management have to run in parallel to this process. Thus, the design of embedded systems mandates an open and flexible integration platform that provides design flow management, general data management and a common graphical user interface to support the various design environments.

Compared to the status just a few years ago, as described above, massive improvements to the possibilities of model based software development have been made. Questions like modular testing or version control on a subsystem basis within models have been solved or at least there are first versions of tools available that provide features to fulfil the needs in these topics.

Two elements for software development are addressed within the model based approach, one is the model description of functional modules that can be seen as the first artefact in development of embedded application modules. The other area covered by models is the environment for the functional module that allows simulation, validation and testing. Talking about the specific development environment for a project, there is the possibility to use the same modelling language for the description of the environment, at each level of integration including full software integration. Parts of these simulation development models can be used again as an adequate validation environment. The models remain unchanged for model validation and will be simplified, regarding calculations for the use in simulators to perform "hardware-in-the-loop" (HIL) testing.

The functional modules are treated in a similar way in order to obtain a full graphical representation of the application software module that is integrated into the embedded software.

As already known from traditional software development methodologies, the model based development of application modules is following a step by step development process. The models are representing different levels of development regarding the content of information but still are formulated in the same modelling environment. This may be made better understandable using a simple example regarding radar sensing systems. In the level of functional ideas, the representations of the system inputs are: the shortest distances of objects in the parking lot and a time to collision type of information during the parking activities among many others.

In the abstract level of system concept description, the values of such input variables can be obtained directly from the mathematical model of the environment. The next phase of development is about the refinement of the system described above. The models are refined taking all the real world restrictions into account. Going back to the example aspect the data processing within the radar sensor modules have to be modelled. In this phase functionalities like data processing modules will be included into the model.

This phase is completed as soon as the specification is complete. This also means that all the constraints regarding hardware or surrounding modules are available. The next development efforts are replacing the implementation phase from traditional software development. In this phase all the timing and memory constraints have to be fulfilled. Due to modelling guidelines and other methods all the demands regarding the code can be considered in the model.

Production code technology has become a key component in the evolution of software development because it is practical: details to designs can be added directly on a model and then the final code can be generated automatically [START_REF] Langenwalter | Model-Based Design with Production Code Generation for Steer-by-Wire System Development[END_REF]. Production code generation has done well in early adoption. However, further growth requires a supporting software engineering framework that integrates processes, methods, and tools. Engineers use model based design in nearly every industry that requires embedded control systems development.

As already mentioned above the model based design must address the needs of safety-critical systems, which often require additional process rigor. Through simulation and prototyping, this approach supports safety-related system development by providing extensive verification and validation prior to a final build. The benefit is clear: system integration and testing result in fewer bugs and less rework.

The first step is behavioural modelling. In model based design we use models to specify requirements and design. A typical system includes: inputs (for example obstacle data), a controller or signal processing model (for example the parking lot), a plant or environment model (for example the vehicle) and outputs (for example the driver information).

A system model is created to represent the desired behaviour using control system block diagrams for feedback control, state machines for discrete events and conditional logic, and signal processing blocks for filters. We execute the model and then analyze it to ensure that the requirements are satisfied, using methods such as time-or event-based simulation and frequency domain analysis. For example, a PINFO system must respond to a detected obstacle quick enough in order to enable the driver to stop the vehicle before collision. Simulation, a core validation activity, ensures that a system can be developed to satisfy the requirements.

Because plant models can be inaccurate and the production processor may not provide sufficient processing power to get a working result, modelling alone does not provide the total solution. Rapid prototyping overcomes these shortcomings, because it replaces the plant model with the physical plant. A real time platform runs the controller software and interacts with the plant. The goal is to determine whether the system controls the physical car as well as it controlled the modelled car. If so, plant model inaccuracies are considered insignificant and the control strategy is validated.

Requirements

Hence there are extensive requirements to be met by the development approach and its implementation as an integrated development environment. Taking functional safety aspects into account when considering system integrity leads to extra effort. Software safety requirements as specified e.g. in IEC 61508 will interfere with the development process. Therefore the process is based on a result oriented approach similar to the V-Model XT.

As an approach for the model based treatment of functional requirements a solution is to use models of system behaviour [START_REF] Grochtmann | Systemverhaltensmodelle zur Spezifikation bei der modellbasierten Entwicklung von eingebetteter Software im Automobil[END_REF] in order to have a model representation of traditionally textual requirements. This model can help to analyse requirements, if they are complete and consistent. For a single assistance function in the parking system area the number of textual requirements can easily reach 50 or more and such models help to maintain the system overview.

At system level there is the need to address also other than functional requirements [START_REF] Mutz | Seamless Model Based Development Process of Automotive Systems[END_REF]. In addition the system has to fulfil also non functional requirements, diagnosis requirements and requirements regarding interfaces and parameters. Another means to provide assistance with structuring is the introduction of abstraction levels. The top level of product specific requirements represents the user or product level. These requirements describe how the system is used in the vehicle. The next level of requirements refers to the system. In this abstraction level requirements specify the technical implementation. The implementation details are further refined at subsystem or component level.

Software modularisation

The elements of software for electronic control units can be categorized in different classification approaches. In chapter 1.3 we looked at the system level modules. As stated, we consider in this paper standard software elements, high level language modules and automatically generated application modules from the model based software engineering environment.

Distributed architecture design

Modern embedded systems contain several distributed ECUs, which communicate in real time with each other over a fault-tolerant communication system. If some system functionality is placed onto an ECU there is the need to add network components such as hosts, tasks, signals, and so forth to the individual subsystems, such framework enables the embedded functions to be connected and mapped onto an ECU architecture. Distributed network design solutions like DaVinci from Vector Informatik GmbH then integrate the code generated from models with legacy code from other subsystems and different suppliers and map the resulting code onto the ECU or system architectures for verification. Up to now, this effort has not been needed for the parking function example.

Software architecture

The decisions regarding system and software architecture are not discussed in this paper. Some ideas for approaches regarding software architecture are discussed in [START_REF] Thurner | The EAST-EEA project -a middleware based software architecture for networked electronic control units in vehicles[END_REF]. As already mentioned in this paper we look at three different sorts of software modules to be integrated into the ECU.

Standard software modules: These modules were coded according to specifications that are accepted as standards. The modules are somehow box products that are licensed for the ECU and released for certain CPU families. Using these modules is already a requirement in some areas of the industry and allows the re-use of many base level functions that have to be implemented into several ECUs. Those modules have passed approved, defined and independent testing, provide defined behaviour and fulfil the integration requirements. Those modules include for example: low-level drivers, the OSEK operating system, and CAN drivers.

C-Code modules: As already mentioned, up to now there are some restrictions to the model based design method that require certain elements of ECU software to be implemented with traditional methods. Functionalities like some hardware drivers are an example for code that has no real advantage in development when they are designed using model based engineering. One example is the glue code function to call the low-level functions, pass the inputs to the auto-coded modules and update the outputs via the low-level functions with the values returned by the auto-coded modules.

Auto-coded modules: In this paper the focus is on these modules. In the approach described in this paper most of the modules are containing the implementation of the functional requirements and represent the application software level within the ECU. The elements are representing the part of the software that is also addressed as applications in the AUTOSAR approach. The following chapters refer to these modules.

Toolchain

The integrated development environment is based on elements of commercial toolchains that are supplemented with new elements. The newest toolchain is presented offering a state-of-the-art development approach starting from basic ideas of new functionalities up to and including automatically generated production code for electronic control units. The whole toolchain started producing ECU Code with release 11 of the Matlab product family from The MathWorks Inc. and version 1.3 of Target-Link from dSPACE GmbH. The base tools today are release 14 of Matlab, Simulink and Stateflow and version 2 of TargetLink. In addition to this MTest from dSPACE GmbH is used and the tools are completed with various parts of the PROVEtech:SD family of project specific additions from MBtechnology GmbH. The toolchain can also be modified for code generation with the Embedded RealTimeWorkshop from The MathWorks Inc. as code generator.

Code generation

The toolchain used for the parking systems was improved during the past years and consistently adjusted for the releases of the base tools. Mostly, there were needs of creating interfaces to existing development tools and for measurement systems at ECU integration level. In order to have everything available to produce auto-code, you need more than a development environment. Knowledge must be provided for example in form of rules, guidelines etc. in order to gain experience as examples from other areas [START_REF] Pruett | Targetlink goes off-road[END_REF] show.

Auto-code integration process

To support auto-code generation, a change in the way a development environment is used has to be done. In the first step the specification model has to incorporate only blocks that support the code generation. Depending on the elements the model contains, functional equivalents may have to be found for Simulink blocks that are not supported.

Within our toolchain such an effort can be avoided by using appropriate modelling guidelines. In some of the projects already the specification is only containing code generable blocks.

Using MTest every module can be tested in its individual simulation test harness. These tests are executed under simulation while for example the minimum and maximum values of every node in the model are recorded. Within the tool there are options to automatically compare the model outputs with a reference output file and generate a pre-defined report for the test. Using the data collected, the fixed-point model can be auto-scaled with for example TargetLink. The MTest test suite is run again, however, this time in fixed-point mode. With the information gathered the fixed-point model output can be compared against the floating-point model output.

The next step is to use "processor-in-the-loop" (PIL) simulation in order to run the integration test suite on an evaluation board. Here log stack usage and execution time for each test case is evaluated. The model is then exported as C code, and integrated with the low-level drivers, the OSEK operating system, and CAN drivers. This integration involves writing the glue code mentioned above.

The size and complexity of applications made with model based design can include the complete functionality of a system. In [START_REF] Pruett | Targetlink goes off-road[END_REF] all application code is built into an implementation model. In this , one application model for example the application model consists of about 4700 blocks that take a file size of about 13 MB on the host PC and result in ECU application code of 90 kB for a HCS12 CPU.

Embedded software metrics

When working in a traditional embedded software development environment there are a variety of tools to measure effort and productivity. These include LOC (lines of code), the change in LOC from one design iteration to the next, computational complexity and many more. Such metrics are usually collected manually or semi-automatically. A comparison of those issues regarding model based design is discussed in [START_REF] Hosagrahara | Measuring Productivity and Quality in Model-Based Design[END_REF] where the following issues named in this chapter are further elaborated. Total time spent simulating: An objective measure of the total time spent simulating models can be captured to ensure thorough model execution. This includes the time used to simulate alternative designs or validation and verification scenarios, or for advanced tuning and optimization of controls.

Several tools are used to support the metrics task.

For example the tools from The MathWorks Inc.: Simulink Accelerator, a Simulink companion product for accelerating and optimizing model performance, collects performance data while simulating the model. And Simulink Verification and Validation, another Simulink companion product, provides a measure of cyclomatic complexity and a measure of the structural complexity of the model.

Supplementary remarks

Comparing production code generation to traditional coding we can find similar requirements. For the integration we can assume the same demands as with a traditional C compiler. Various optimization settings and user configuration options exist. The key is to keep the code efficient, accurate and integrated with other modules. In safety-related software, it is also important for the code to be traceable to the diagram so that it can be reviewed and verified.

The validation and verification activities include various options. As long as we stay in the model based design environment all the tests are done with models so that the device under test is a model and this leads to the term "model-in-the-loop" (MIL).

Once the controller is built, we can perform a series of open-and closed-loop tests with the real-time plant model in the loop. Some tests involve only the software or processor and are known as "softwarein-the-loop" (SIL) or "processor-in-the-loop" (PIL) testing, respectively. When using the ECU hardware as device under test the procedure is referred to as "hardware-in-the-loop" (HIL). In either case, we test the physical controller with the plant model. In order to have a suitable effort in the testing activities these activities are planned and documented within a test specification.

Most software standards require traceability of requirements, perhaps originating in other requirements tools, throughout development. Also, Software Configuration Management (SCM) is needed to store, version and retrieve the various development artefacts. Documentation via report generators ensures that management, customers, and suppliers will see the model. Model based design supports all of these components.

  The following software design activities include fixedpoint data specification, real time tasking, data typing, built-in test, and diagnostics.

	With model based design, the same model, used for
	the algorithm specification and the validation, is
	refined and constrained by the software engineers
	as part of the production code generation process.
	Automated scaling and data type override help
	convert floating-point models to fixed point and
	provide mechanisms to assess a fixed-point design
	by simulating it in floating point.
	Testing the model on a desktop is preferable to
	deploying it on hardware for build and integration.
	Source-code-based testing has existed for many
	years, and recent methods enable model testing and
	structural coverage analysis. Using simulation and
	coverage, developers can fully stress the controller
	to verify its design integrity.
	Numerical overflow and dead code are examples of
	poor design integrity. Stress testing of the model
	using minimum and maximum numerical values
	helps to ensure that overflow conditions will not
	occur. Simulation facilitates this method of stress
	testing, but dead code is not easy to find because
	detection requires structural coverage analysis.
	Dead code differs from deactivated code as it is
	deactivated for a reason and this is known and
	documented by the developer. Actual dead code
	indicates that details were omitted during
	requirements specification, design, or test case
	development.
	Model coverage assesses the cumulative results of a
	test suite to determine which blocks were not
	executed or which states were not reached. Certain
	types of coverage are well established in source
	code languages (such as C and C++). More
	information regarding metrics within model based
	development is given in chapter 5.1 below.

Conclusion

The development methodology described is based on more than ten years of experience in applying model based development at DaimlerChrysler AG [START_REF] Rau | Model-Based Development of Embedded Automotive Control Systems[END_REF] and has been adapted in the past few years for other domains at MB-technology GmbH. Several software projects based on this methodology have been completed successfully. Consequently this approach is used as a reference method for new projects.

Acknowledgement

The authors acknowledge the contribution of their colleagues to this work.

Glossary


G Bel

P Bieber

F Boniol

Dalla Barba

G Durrieu

B Sidoruk

Integration of quality of service in avionics architecture

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Integration of quality of service in avionics architecture Abstract

G. Bel 1 , P. Bieber 1 , F. Boniol 1,2 , D. Dalla Barba 3 , G. Durrieu 1 , B. Sidoruk 1 1: ONERA-CERT, 2 av. E. Belin, BP 4025, 31055 Toulouse France 2: ENSEEIHT, 2 rue C. Camichel, 31071 Toulouse France 3: Airbus France, 316 route de Bayonne, 31053 Toulouse France 1 From federated avionics architecture to IMA

Traditionally, avionics systems have followed a federated approach -separate software functions allocated to dedicated (often physically disjoint) computing "black-boxes". As the transmitted data are involved in process control, the communication architecture between avionics functions is based on three key principles: (1) one source, one line, several receivers, (2) the transmitter does not need to know who receives data, and (3) no time synchronisation between transmitter and receiver. The traditional aeronautical answer to these requirements was the ARINC 429 Digital Information Transfer System: each line has only one source and is connected to every equipment that need the data transmitted by the source, and each data is individually identified (by a label) and sent. The main advantage to such architectures is determinism. However, they often lead to inefficient resource utilisation. In recent years there has been a considerable amount of effort undertaken by ARINC to define standards for Integrated Modular Avionics (IMA). IMA proposes the integration of avionics systems to common resources (computers as well as communication lines and switches) (see figure 1).

The AFDX solution for communication resource sharing

The main benefits of IMA architecture are to reduce the weight of the aircraft as less pieces of equipment and wiring are needed, and to reduce maintenance cost as well as less types of spare equipment could be used to replace failed components. However IMA architecture, and more specifically re-source sharing, introduces new difficulties in designing and integrating avionics systems. Communication resource sharing can introduce non-determinism (loss of messages, unbounded latency). The Airbus response to this problem is the new AFDX (Avionics Full Duplex Switched Ethernet) communication architecture. This architecture is based on IEEE 802.3 Ethernet and TCP/IP general principles. However it uses specific concept and features to provide secure data transfer with real time constraints, to provide the guarantee of services and determinism required for civil aerospace requirements. It is built with switches (SW), i.e., network devices in charge of data forwarding, and End System (ES), i.e., network devices in charge of data transmission/reception. Bandwidth control is achieved with advanced queue management and multiple bandwidth use strategies. For that purposes, AFDX introduces the notions of BAGs (Bandwidth Allocation Gap) and of maximum frame size to allocate bandwidth as in ATM CBR (Constant Bit Rate), and UBR (User Bit Rate). This guarantee applies to the key notions of AFDX, the virtual links.

However, as far as we can not state on the actual source traffic, the worst case performance of the AFDX network is systematically majored. This leads to network configurations that under-use the true Ethernet capability.

Towards resource reservation protocols and integration of Quality of Service for avionics architecture

Ethernet uses a Carrier Sense Multiple Access with Collision Detection (CSMA/CD) arbitration mechanism, according to which a network controller having a message to be transmitted must wait for the bus to become idle. This protocol does not provide, In the particular case of the Internet, two other approaches have been proposed: a resource reservation approach (for example IntServ and RSVP and most of QoS general architectures), and priority based services (for examples DiffServ).

IntServ and Resource reservation protocols such as RSVP [Zha97] provide support for end-to-end resource reservation for specific sessions and define a concept based on per flow reservations (sig-nalling) and admission control to be present end-toend. In RSVP the sessions are identified with the IP address and the ports of connects. Reservation is supported for specific sessions or clusters of sessions (in multicast communication). The reservation protocol includes PATH and RESV messages that make the reservation of resources (especially bandwidth reservation) in all nodes (routers, switches and computers) included in the flow path. Several routers and switches support these protocols based on configurable traffic control schemas. The basic problems associated to RSVP are the scalability (RSVP requires complex queuing algorithms and packet scheduling) and the wasted bandwidth necessary to handle the management of the whole network.

A second approach has been proposed to specifically address the problem of handling QoS requirements and differentiated service guarantees. Diff-Serv is an example of such an architecture supporting real-time as well as the current non-real-time service of IP and takes another approach assuming no explicit reservation mechanism in the interior network elements. It defines an approach for the classification of network traffic and services and interfaces for their support. DiffServ is a layer 3 traffic-handling mechanism including new services such as SLA (service level agreement), which specify the amount of customer traffic that can be accommodated at each service level.

It is well admitted that this last technique, Diff-Serv, combined with controlled traffic generation, provides correct result in the Internet Context for voice or multimedia traffic. The aim of this article is to evaluate these techniques (DiffServ and controlled traffic generation) in the context of avionics systems, and more particularly for embedded switched Ethernet networks.

In order to validate the Diffserv concept a laboratory mock-up based upon 2 COTS Gigabit Ethernet switches and several PC stations instrumented with traffic generation and capture capability means addressing and supporting QoS concepts and mechanisms, was built. A first set of experiments had been conducted in order to characterize the limits of performance achieved with the traffic generated throughput and the captured traffic. After that, throughput evaluations have been made for prioritized traffic according to the DiffServ concept, and handling of several bandwidth reservations for prioritized traffic has been characterized.

The results obtained show good conformance with traffic classification, traffic prioritization and bandwidth reservation.