J P Blanquart

C Delord
email: cdelord@sopragroup.com

J Doumerc
email: jdoumerc@sopragroup.com

G Hannoyer
email: gilles.hannoyer@continental-corporation.com

J C Laperche

M Morel

M Müller

C Seguin

Model Driven Engineering and Dependability Analyses: The Topcased 1 Approach

Keywords:

Model Driven Engineering approaches are widely promoted to overcome difficulties to design, validate and maintain large complex systems. They present interesting dependability characteristics especially in terms of prevention of design faults and validation of design correctness. However industrial needs, practices and applicable standards impose constraints on the dependability activities to perform and justify. Therefore it is necessary to analyze how a complete dependability and safety process can be integrated with model-driven approaches within a seamless global process: which dependability activities are naturally covered or facilitated by model-driven approaches, and which additional activities are needed with which support. This paper presents the results of a study aiming at the establishment of requirements to model-driven engineering methods and tools, to support dependability analyses.

Introduction

This document presents a synthesis of the work conducted within the Topcased 1 project, with focus on selected application case studies. The objectives were to manage the discussion and assessment of main issues to get efficient support to dependability analyses within a model-based engineering framework. They address the main following points:

• Identification and classification of the relevant dependability concepts, attributes and links, Identification of dependability analysis methods and tools; • Organisation of the dependability and safety process, activities, inputs and outputs and mapping to life cycle and model-based engineering entities, especially identifying the interactions between dependability and design;

• Illustration of the proposed approach on two complementary examples: o Association of failure modes and failure rates to design model entities, to support through model transformation the elaboration of dependability models for quantitative evaluation, o Representation of partitions (with respect to faults and failures) on design models, to support fault dependency or independency analyses (e.g., criticality level allocation, common cause analysis, etc.); • Discussion of current limitations (concepts, methods, tools) and proposals.

Dependability engineering

Background

Dependability, defined as the ability to deliver service that can justifiably be trusted [START_REF] Avizienis | Basic concepts and taxonomy of dependable and secure computing[END_REF] encompasses properties such as reliability (continuity of correct service), availability (readiness for correct service) etc. Dependability engineering, including validation, consists in ensuring the required dependability properties taking into account possible threats (faults, errors and failures). Faults, errors and failures are not "atomic" concepts. Detailed dependability analyses lead to distinguish permanent, intermittent and transient faults, or dormant and active faults (corresponding to a state where a given fault causes or does not cause errors), leading to the notion of fault dormancy. In the same way, errors may be detected or not detected, leading to the notion of error latency.

Failures may be characterised by their occurrence process (e.g., failure rate), and by the distinction between several failure modes. Failure modes may be themselves further characterised by their severity, leading to the notion of severity level, associated to the allocation of levels to entities according to the maximum severity of their potential failures: development assurance level, safety integrity level, software criticality.

Dependability Analyses: Needs and Objectives

Dependability engineering encompasses the set of activities intended to:

• Provide the system with the required dependability properties; • Ensure that the system actually fulfils its required properties. These two categories are in practice tightly coupled in an iterative process where solutions are progressively analysed and evaluated thanks to dependability analysis methods. In industrial practice and applicable standards, we can distinguish the following four categories of dependability analyses:

• Criticality analysis:

The objectives are to identify and allocate "criticality categories" to design entities (functions, hardware or software elements) reflecting the level of trust we must have on these entities (and therefore the level required for their design and validation).

• Dependency analysis (common cause analysis):

The objectives are to evaluate to which extent some design entities are independent with respect to failures i.e., to which extent we can assume that two considered failures are stochastically independent events. Conversely the approach may focus on the identification of common causes: either a potential source of failure propagating to two design entities expected to fail independently (redundancies) or a potential (undesired) path through which the failure of an entity may propagate and cause the failure of another expected independent entity.

• Quantitative dependability analysis:

The objectives are to provide an estimation of a quantitative dependability property (reliability, availability, error latency, coverage factor, etc.). This can be achieved through experimental (fault injection, field data collection) or analytical (modelling) techniques, based on a set of assumptions on the stochastic characteristics of the fault occurrence and propagation processes (see next point below).

• Fault propagation analysis:

The objectives are to characterize the process of propagation of faults and failures, in particular to assess whether the various fault tolerance and error detection mechanisms are sufficient or where additional ones are needed. Fault propagation analyses may be top-down (e.g., fault-tree analysis) or bottom-up (e.g., failure modes, effects and criticality analysis) (or even both such as HAZOP -Hazard and Operability analysis). It is worth noting that this fourth category is not exactly of the same nature of the previous three ones, in the sense that in addition to its own objectives as identified above, fault propagation analysis can also, and generally is, used as a support to perform criticality, dependency or quantitative analysis. In addition, a particular category of dependability analysis approaches is constituted by the analysis of the behaviour of fault tolerance mechanisms. It is similar by nature to analysis methods in support to the general engineering process. However their application to mechanisms (or elements, subsystems, procedures etc.) dedicated to dependability, leads to highlight here their important contribution as a dependability assessment means. Their objectives are to analyse and characterize the functional properties of the fault tolerance mechanisms. This may be used to validate that they fulfil their requirements, or as a support to other dependability analysis methods (e.g., to evaluate quantitative parameters such as error latency).

Dependability methods and tools

As mentioned previously, the fault propagation analysis is the kernel of any dependability analysis. It can be done by using experimental techniques on actual devices (e.g. fault injection in a hardware components) or by building some analytical models and then analyzing the models. In this section, we focus on the second approach. For sake of clarity, we try to separate concerns, presenting on the one hand the features of usual analytical models and on the other hand, the kind of computations that enable to exploit these models. The analytical dependability models depict how faults are propagated or confined inside the system. They catch causality chains between dependability concepts (how faults cause errors and then failures). Fault tree, FMEA and all system models that describe how a system reacts when a fault occurs can be considered as analytical dependability models. In the following, some features of these models are highlighted in order to understand their commonalities and differences. Models may have different scopes. They can be centred on a specific failure and forget all faults and errors that are not related to the studied failure. This approach is usually taken when designing fault-tree or reliability blocks models. Conversely, they can be "system centred" and gather in one model all causality chains of interest for this system. This approach is for example taken when injecting failures in a software model. Models may encode fault propagation in different ways. A model may consist in an explicit set of fault propagation paths. For instance, traditional fault trees usually encode dependencies between observable failures or between failures and primary faults by and/or gates. More details about the metamodels of fault-tree can be found for instance in [START_REF]Dependability requirements on TOPCASED[END_REF]. Conversely, a fault propagation may be modelled in a more compositional and implicit way. In such cases, the model consists in interconnected basic blocks of the system. Each basic block model depicts explicitly how the basic component may be faulty and propagate (or not) faulty inputs. The global propagation paths are left implicit and result from the composition rules of the basic components. Finally, the models can be specifically built for dependability analyses or may be reused and extended to cope with failure propagation. For instance, one may intend to reuse an AADL model that depicts the software architecture of a system. Then the model can be extended in order to describe the effects of a failure of each piece of the software architecture. Finally, we have to compile this extended model into a format that better support the safety analysis. For instance, the extended AADL model can be compiled in an AltaRica model [START_REF]Dependability requirements on TOPCASED[END_REF]. The kinds of computation that enable to use such models for dependability analysis rely on at least four general mechanisms: • Analysis of failure propagation paths: o bottom-up analysis: effect of one fault on the system o top-down analysis: search of faults leading to a feared event; • Quantification of the probability of occurrence of some events; • Verification of the validity of some hypotheses or requirements about a system or component design. Whatever the way for building models, the tools that implement these mechanisms operate on mainly two kinds of low level formats that encode causality chains:

• Boolean formulae when static view of causality is sufficient; • Automata when reasoning about system dynamic is necessary. Then the search of causes or effects of some events will turn out to compute either causes/consequences of formulae or exploring the system state space. For instance, Aralia is a tool used to deal with fault trees i.e. Boolean formulae. It performs both qualitative analysis (search of minimal cut sets) and quantitative one. OCAS, SIMFIA and COMBAVA are tools dedicated to mode automata models written in the AltaRica languages. They enable interactive model simulation, search of sequences of bounded length leading to a feared event, extraction of fault trees for static systems. In ISAAC project (see for more details [4: www.cert.fr/isaac/]), tools were also developed to inject failure modes inside Nu-SMV, Scade and Statechart models and then extract either fault tree or sequence of fault leading to a feared events. Similarly, the quantification of the probability of occurrence of a feared event will be computed thanks to a Boolean formula annotated by probability (e.g., by means of Aralia) or by stochastic simulation of an automata (e.g. COMBAVA) or by probabilistic model-checking (e.g. Prism model checker). Finally, the verification of the truth of some hypothesis can be performed by simulation or by proof (we mean here by "proof", a rigorous exhaustive verification. It can be achieved in several ways such as by so-called model-checking technique).

Relation with engineering models

To perform the fault propagation analysis described in §2.3, the dependability engineer may use different types of system modelling and associated attributes, which level of details depends also on the current step in the dependability process. The input of this analysis is the Functional Hazard Analysis which is made at an upper level, generally by the customer, and which defines the system Failure Conditions with associated qualitative and quantitative requirements. In practical, the first task for building the "safety" system model is to identify the functional paths i.e., the chains of functional dependencies, related to each Failure Condition or Feared Event, by mapping these paths on the system functions and components. The second step is the identification of interfaces between functions and equipment inside a same functional path, to express functional dependencies in the model:

Modelling entities

Attributes of entities

Attributes of attributes

• Identification of inputs / outputs links between functional block or equipment,

• Identification of intrinsic architectural "safety barriers" (redundancies or monitoring). Note that this activity may be performed at various decomposition levels (systems, equipment, software or hardware elements). At this stage, the fault propagation model may be used for criticality analysis, by adding "criticality" attributes to the modelling entities (e.g. at function and component levels), which are defined from the initial feared event severity allocated to each functional path and thanks to the mapping functional path / functions / components and the identification of "safety barriers" involved in the functional path.

Modelling entities

Attributes of entities

Attributes of attributes

Modelling entities

Attributes of entities

Function criticality of function Component criticality level

Then, the "dependability" system model is expanded with a description of the component behaviour face to failures to constitute the analytical dependability model described in §2.3, which will be used for all the dysfunctional analysis mentioned in §2.2. In particular, specific quantitative attributes may be added to this fault propagation model, in order to perform the quantitative dependability analysis (basically FMEA for single failures, FTA for scenarios of multiple failures, etc) through the use of specific tools: For the dependency analysis, a specific "common mode" attribute may be added to each component (e.g. potential common mode are related to: common design or technologies, common resources, common operational or maintenance tasks on several components, etc.), in order to validate the independence hypotheses between safety barriers.

Modelling entities

Attributes of entities

Attributes of attributes

Modelling entities

Attributes of entities

Attributes of attributes

Case studies

3.1. Quantitative analysis Using a simple digital output example, a draft workflow at the functional level is established. It illustrates the application of the failure rate attribute in the early architecture phase. The important features to be provided by engineering models are marked bold. Based on the system analysis, certain failure rates with specific failure modes are assigned to the digital output functionality DGO, labelled with '1' in the figure 1 below. E.g. this could be 5•10 -6 /h for the 'detected loss' and 10 -6 /h for the 'undetected erroneous transmission'. Models shall support the annotation of the quantitative values and enable the user to define generic failure modes to be referenced in the further modelling activities. Each failure mode contains an attribute to quantify it's by percent participation to the objects over all failure rate ('% of failure rate'). In the next step, the safety objective of the function is linked with the related and relevant sub-functions ('2' in figure 1

above). Again additional dependability modelling facilities are required, to express relations between objects or functions in terms of RAMS dependencies.

A two fold approach is used to elaborate a feasible architecture. On one side the primary objectives are refined to the resulting sub-function requirements. On the other side, failure mode specific failure rates are put on the sub-functions ('2'), based on experience, a data base or research. So models shall provide means to verify the quantitative breakdown of the dependability objectives by a bottom up assessment of the current architecture and sub-function property assumptions. In the next step failure mode specific barriers and monitoring functions ('3' in figure 2 below) are added and assessed as in the previous step. The applied measures are linked with the failure mode attribute they are designed to cope with. So models shall provide means to quantify the impact of monitoring functions on the failure mode detection and the failure rate coverage. Also relations between entities in the design models and dedicated dependability assessment models such as FTA or failure propagation models shall be supported.

To conclude the results of the example work flow, engineering model based environments should provide a dependability tool bar in some diagrams and views, to ease the access to certain important dependability attributes and links. The process for the failure rate, failure mode and '% of failure rate' described above shall be extended and generalized to be applicable for all dependability attributes. Merging and linking design and dependability aspects makes dependability visible for the developers and helps to avoid inappropriate design choices by enabling an 'on the fly' assessment of the dependability attributes.

Partitioning

Partitioning is an important issue in system dependability. It is worth noting that partitioning may be seen from two complementary perspectives:

• On the one hand partitioning is used to limit the impact of faults and the propagation of failures between different functions and components. In dependable systems some entities are protected by barriers. • On the other hand, partitioning enables dependability analyses. Only by restricting and knowing the relevant faults, that affect a function or component quantitative assessments such as failure rate estimations are possible. When looking at functions in general we try to reduce dependencies and want to get an overview how these entities contribute to some common failure conditions. The dependability engineer analyses, if a small number or events can cause multiple sub function failures which lead in their summation to a critical system state. Barriers as means of partitioning are applied then to reduce the spread out of failures The partitioning of redundant functions is somehow a special case of the above. Redundancy is applied to cope with certain failures and to avoid their propagation into subsequent functions. In this case the technical implementation is given and the partitioning analysis is performed as a dependability justification. The dependability engineer is looking for common cause failures that bypass the redundancy and verifies the barriers. Partitioning may be represented as a logical separation between functions and pieces of software, as illustrated in figure 4. An appropriate support to dependability analyses or partitioned systems should provide means to assign an "area of influence" to a fault / failure or the responsible failure mode of a function or component, so as to obtain a flexible method to describe the impact of failures. We can express and quantify independence in terms of several aspects • There are geometrical areas, which use distances to avoid failures with physical impact to propagate. The faults that we want to address may be e.g., over temperature, shock waves or leakage of critical liquids. • There are also logical physical areas, such as an independent power supply or short circuit failure isolation by galvanic decoupling. • Finally there are software considerations, e.g. the independence in terms of memory and scheduling. Many open questions remain to be answered in further research activities. Up to now it is not clear, for example, how these areas should be represented in models, especially how the relation and interaction with the standard design models may look like.

Hardware O/S + Drivers + Services

Configuration

Towards Model-based dependability engineering

Embedded systems become more and more complex while their criticality increases due to their wider functional coverage. Consequently complex systems have to be designed to be fault tolerant, reliable and robust. More often, such critical systems shall also be proven dependable. The acceptance process depends on the application domain (aeronautic, space, automotive, nuclear power station, etc.). The certification processes are periodically updated in order to better fit the evolutions of technologies (IMA, smart sensors and actuators ...) or development process (model based design, use of COTS, open-source software ...). In the aeronautic field, major documents (e.g., ARP4754, DO178B, ARP4761) are currently under revision. In a similar way, for automotive field, ISO WD 26262 is in progress. Today we find a layered process, starting with some preliminary and abstract design studies and ending with the validation of the product, e.g. an embedded device. All stages of this well known V-cycle typically make use of different methods and tools to perform the required tasks. In the last years more and more modelling techniques were introduced to offer a common platform for all the lifecycle activities. Models provide the ability to successively refine a draft design and to enter the coding and verification phases seamlessly.

A common concern is to adapt the certification processes in order to reduce their cost whilst covering new practices. The following points highlight some difficulties. Sometimes, the certification objectives are overspecified. This induces unnecessary cost and may lead to discard the use of innovative product in embedded systems. For instance, in DO178B, levels of test coverage are recommended according to the software criticality level. This mean of compliance is costly and prohibit the use of some COTS whereas it would be better to clarify the expected product properties.

Another problem is the definition of a homogenous approach concerning dependability and safety.

There are engineering models and safety or dependability related models. Each of them is evolving over several design phases from very abstract content to complex systems. There is no guidance, what dependability features should be modelled and how to integrate them efficiently in the engineering models, and advise when to add some qualitative and quantitative dependability arguments and how to combine and assess them is missing. We do not know exactly how to make use of these arguments among different design or abstraction levels. It turned out to be necessary to improve the binding between different dependability assessment and analysis methods in the development process. Finally, it becomes harder and longer to assess complex integrated systems with traditional compliance means. Thus it is also interesting to enhance existing assessment techniques or define alternative ones in order to cope more efficiently both with emerging certification objectives, current development process and increasing system complexity.

The following axes for further work can be identified: for research on systematic ways of selecting the "inputs" (including the fault dimension), as well as on how to concretely apply them to a target system. The relevant methods and tools should build on both the fault injection technology and the software testing one.

• Contribution of methods and their combinations to SW dependability assessment: In most domains, the incorporation of software in critical systems is largely based on a generic approach where an abstraction of dependability requirements is elaborated as an ordered set of criticality levels, and software assurance means are used accordingly, corresponding to an ordered set of development and validation requirements. The problem we propose to investigate concerns the definition of the contents of the assurance levels, put in front of each criticality level i.e., the definition and justification of the sets of software dependability objectives and constraints, with associated means (methods, techniques and their possible combinations). This involves an assessment of software dependability means combining the complementary skills and experience of both academic and industrial partners, exploiting both: o analytical assessment of various software dependability approaches (combining objective assessment when possible and engineer judgement), o lessons-learnt in particular from dependability properties actually observed whenever available and their possible relationships to identified software assurance means.

• Particular focus should be put, first on modelbased approaches (assurance approaches for "model-based-engineered-software", as well as "model-based-assurance approaches"), second on advanced approaches that could be proposed for COTS software.

• Secondary (though important) objectives might be to investigate the very nature of the claim supported by a criticality-based approach, and whether it can be rigorously expressed. Such a rigorous (or at least, clear enough) expression is expected to provide fruitful bases for e.g.,: o additional support to the sound definition of assurance means for each criticality level, o support to the definition of a sound approach to allocate criticality levels along the definition of a system, o support to the sound incorporation of the dependability claims related to software (based on the criticality-based approach) into the global set of system level dependability claims.

Summary

The work reported in this paper aims at analysing how to integrate dependability analyses within a seamless process adapted to model-based engineering approaches.

In a first step we analysed the entities addressed by current dependability analysis techniques, and established requirements towards model-based engineering process and tools so as to appropriately support these analyses. However dependability analyses may also benefit more directly from model-based approaches. We have therefore identified a set of proposals on which partners are now engaged towards efficient integrated model-based dependability engineering.

Figure 1 :

 1 Figure 1: DGO Functional description

Figure 2 :Figure 3 :

 23 Figure 2: DGO Functional monitoring

Figure 5 :

 5 Figure 4: Software Partitioning


Franco Gasperoni
email: gasperoni@adacore.com

Free Software and Leveraged Service Organizations

Keywords: Free software, FLOSS, leveraged service organization, embedded real-time software market

In this work we concentrate on where forprofit pure FLOSS business organizations in the embedded real-time software space draw their revenue. The business model of these ventures rests on an original concept: the LSO (Leveraged Service Organization) which, thanks to its subscription-based model, is capable of generating a stable cash flow that can be invested in innovation and reward employees and investors alike. The leverage aspect, in an LSO, comes from concentration of know-how and expertise around the Free Software package(s) marketed. Thanks to this expertise an LSO can offer a service of extremely high-value to its customers.

Free Software is not Free-of-Charge

"There is no such thing as a free lunch" goes the adage. This is equally true in the free software world (or FLOSS for Freely Licensed Open Source Software). The creator of the free software movement, Richard Stallman himself, pinpoints that the term "free" in free software is a reference to the notion of freedom rather than a lack of cost [1].

And yet, when we pronounce the words free software, open-source software, or FLOSS, the first thing that comes to mind to many is "free lunch". Why this confusion? First, and foremost, FLOSS is characterized by the following freedoms [1]:

• The freedom to run FLOSS for any purpose;

• The freedom to study FLOSS by looking at its sources;

• The freedom to redistribute copies of FLOSS to anyone;

• The freedom to change FLOSS and distribute the modified software.

To protect these freedoms FLOSS uses intellectual property laws, and more specifically copyright as described in [START_REF] Gasperoni | FLOSS, COTS, and Safety: A Business Perspective[END_REF].

As one can see from the above there is no mention of price, it is only a matter of freedom: FLOSS can be sold or provided free-of-charge. In either case the recipient of FLOSS has the freedom to run, study, redistribute, and modify the software.

It is important not to confuse freedom to use and program (which characterizes FLOSS) with free-ofcharge downloads made over the internet which characterizes freeware and does not necessarily come with the programming freedoms of FLOSS.

Having said that, the source code and often the binary of most FLOSS is available for download freeof-charge over the internet. These free-of-charge downloads should not mislead the reader.

Whether it is Apache [3], GNU Linux [4], Eclipse [5],
or GCC -the GNU Compiler Collection [6], someone is picking up the bill for others to enjoy software freeof-charge. In the case of GCC, for instance, this generous "someone" may be a chip manufacturer such as Intel, AMD, or MIPS; computer hardware vendors such as IBM, or HP; Linux vendors such as Red Hat and Suse/Novell; or tools vendors such as CodeSourcery and AdaCore.

This state of affairs may resemble the situation with internet search engines, where individual usage is paid for by advertising. As the remainder of this article explains this is a misleading analogy.

Free Software Communities are really Co-Ops

The days of lone programmers writing FLOSS are behind us. Most contributions to FLOSS are funded by for-profit corporations.

Behind any significant FLOSS project you find several companies. Today most of the individuals that make up a FLOSS community are on the payroll of companies who have a vested interest in the FLOSS. As such a FLOSS community resembles much more to a software cooperative (co-op) than a not-for-profit organization such as UNICEF.

A co-op is an association formed and operated for the benefit of those participating in it. Its business purpose lies more in cost reduction than in revenue generation. The roots of the co-op concept lie in the work of Peter Kropotkin in 1902 [START_REF] Kropotkin | Mutual Aid: A Factor of Evolution[END_REF]. In his book Kropotkin describes how in Siberia animals, instead of competing for resources, have to work together to stay alive. Throughout his book, Kropotkin stresses that cooperation is the main factor in evolution.

It is precisely this drive for cooperation to solve a mutual problem, too hard or too costly to solve in corporate isolation that is the business case for coops.

The idea of industrial cooperation is not new. Airbus or the Eurofighter consortia are good example of cooperative efforts across aerospace companies and nations. What is novel, and what the FLOSS movement has shown, is that this idea can be applied to the development and evolution of software.

Embedded Real-Time Software and FLOSS

In this section we concentrate on the embedded real-time software (ERTS) market.

This market has very specific needs and a limited number of companies developing ERTS ("ERTS manufacturers") for use in larger systems such as planes, trains, or automobiles.

ERTS is inextricably linked to the characteristics of the underlying systems. These systems tend to have a life-span (and hence maintenance requirements) of decades, they have to operate in harsh temperature, mechanical, and electro-magnetic conditions, and may have to pay attention to safety issues such as those listed in DO-178B [START_REF] Eurocae | -178B: Software Considerations in Airborne Systems and Equipment Certification[END_REF].

Furthermore, the difference in life-span between transportation systems and the electronic hardware employed poses additional challenges (such as spare parts availability) onto the development of ERTS for these systems.

All these factors make the ERTS market very different from the traditional IT or office automation ones.

Given the characteristics of ERTS, how can ERTS manufacturers take advantage of FLOSS tools, libraries, operating systems, and other FLOSS components?

Free Software Co-Ops Share Technology

To answer the previous question let us turn once more to FLOSS co-ops.

From the GNU compiler collection, to the GNU debugger, to the GNU binary utilities, to Eclipse, to the GNU Linux operating system the FLOSS co-ops which relate to ERTS are many.

Secondly, at the root of FLOSS co-ops is the idea of pooling together R&D resources to work on and share a common technology base which is then tailored and adapted by each member of the co-op to its needs and those of its customers.

The key point when it comes to FLOSS co-ops is that these communities share technology, not products.

In some cases FLOSS co-ops also collaborate to create a joint general-purpose product from the technology such as Eclipse, FireFox, Thunderbird, or OpenOffice are some examples.

This phenomenon is predominant in markets, such as Java software development or office automation that have a large user base.

In a specialized market such as ERTS this is not a wide-spread phenomenon. For instance, several general-purpose GNU Linux binary distributions can be downloaded over the internet. Those geared towards the ERTS market, however, are not available in ready-to-use form free-of-charge.

The key message here is: in specialized markets such ERTS, the FLOSS co-op participants share technology not products.

Using FLOSS in the Construction of ERTS

There are various scenarios under which an ERTS manufacturer can employ FLOSS when constructing ERTS.

The FLOSS can be used as is

Given the specifics of the ERTS market this scenario is restricted to a limited number of FLOSS items such as the Eclipse core infrastructure and some of the Eclipse plug-ins.

Note, however, that the need to integrate the FLOSS component into a wider context or environment for the development of ERTS remains. If this integration is not straight-forward as-is use of FLOSS is not possible (e.g. several ERTS tool vendors se a tailored version of Eclipse for the ERTS market since out-of-the box use of Eclipse to develop ERTS is not immediate).

For those FLOSS components that can be used (and integrated) as-is without the need for special support or maintenance, the ERTS manufacturer needs to ascertain with its legal department that it has a proper FLOSS license for the software item it intends to use/integrate.

Limited support or minor changes are required

If limited support is needed during installation, use, and integration, or if minor changes are required for the FLOSS component the ERTS manufacturer may be able to tap into the FLOSS community (i.e. co-op) for help.

From a risk-management standpoint this approach is acceptable if the FLOSS component is not a critical item of the ERTS or its development life-cycle and the ERTS manufacturer can eventually do without this help or changes in a worst case scenario.

In-house expertise

The ERTS manufacturer can develop internal expertise to use, maintain, adapt, integrate, and evolve the FLOSS it intends to use.

In this case it is fundamental that the ERTS manufacturer become a member of the co-ops for the FLOSS it will use. Participation to the community effort around each FLOSS component is essential to warrant that the future needs of the ERTS manufacturer are taken into account.

Forking a private copy of the FLOSS that evolves differently from the mainstream one is often an extremely costly undertaking: What many do together via a co-op, one may not do alone. Furthermore, merging future FLOSS evolutions into one's private copy that has been enriched with possibly incompatible changes is expensive.

When analyzing this possibility it is important to evaluate the ability of the ERTS manufacturer to nurture, train, and retain expertise over time around the FLOSS component. This analysis rests on identifying the in-hose core competencies and knowhow.

Purchasing the FLOSS and associated services

The ERTS manufacturer can purchase FLOSS together with support and maintenance services from a vendor who participates to the community effort around the FLOSS.

When taking this route the ERTS manufacturer should avoid artificial purchasing boundaries: if FLOSS 1 and FLOSS 2 are tightly coupled purchasing them from different vendors leaves the manufacturer responsible for their integration.

FLOSS Sold as COTS

The possibility for an ERTS manufacturer to purchase the FLOSS and related support services may appear similar to the traditional relationship with a COTS (Commercial Off-The-Shelf) vendor [START_REF] Gasperoni | FLOSS, COTS, and Safety: A Business Perspective[END_REF].

It is important in this context to distinguish between COTS software that comes with a restrictive license and FLOSS sold as COTS. FLOSS sold as COTS changes the customer-vendor relationship radically since there is:

• No lock-in for software redistribution;

• No lock-in for software changes and evolution;

• No lock-in for support.

Given this absence of lock-ins it is interesting to analyze the role and business model of FLOSS vendors in the ERTS market.

Business Models and the ERTS Market

The business models underlying most of the traditional computer industry rest, at least initially, on the notion of supplier scarcity. Put simply, there are three basic types of scarcities: technology, expertise, and infrastructure.

An example of technology scarcity is the Microsoft operating systems technology: you can purchase a product based on this technology only from Microsoft. Microsoft has managed to established a stronghold in the PC industry thanks to the lock on its technology which is the de-facto standard, not because of the scarcity of expertise (or infrastructure) in building operating systems or office automation software.

The vendor lock-in that comes with restrictively licensed COTS is designed to create technology scarcity which under certain circumstances gives rise to monopolies or oligopolies. This phenomenon is well described in [START_REF] Moore | The Gorilla Game[END_REF].

Contrary to business models, such as Microsoft's, the FLOSS movement has created economies of technology abundance thereby shifting the focus of business based on FLOSS to expertise and infrastructure know-how (put it another way scarcity of expertise and QA infrastructure).

The Leveraged Service Organization (LSO)

This section describes a FLOSS business model that is particularly suited to the ERTS marketplace. Other FLOSS business models exist and are described in [START_REF] Comar | Open Source in Dependable Systems: Current and Future Business Models[END_REF][START_REF] April | Livre blanc sur les modèles économiques du logiciel libre[END_REF].

The business model described in this section is that of AdaCore [12, 13], a 100% free software company with many customers in the ERTS market. AdaCore is the leader in Ada software development solutions.

AdaCore sells several types of FLOSS development solutions. The important points about these solutions are detailed below.

What does AdaCore sell?

All solutions sold by AdaCore comprise two equally important items:

• A coherent and integrated suite of tools and libraries with a proper FLOSS license;

• Frontline support provided directly by AdaCore's developers which are part of the FLOSS co-ops that are the basis for AdaCore's tool suite.

AdaCore sales model

All of AdaCore's solutions are sold as a yearly subscription which has the advantage over a pay up-front model to generate a predictable and recurrent revenue stream.

The price of a subscription is based on the number of developers in the teams using the tools provided by AdaCore.

How does AdaCore check that customers do not exceed the number of users they purchased? It doesn't. AdaCore trusts its customers. Trust builds trust.

Benefits over a do-it-yourself approach

Everything that AdaCore sells is FLOSS. What are the benefits for an AdaCore customer to purchase and renew a subscription package with AdaCore? Here are some examples:

• The customer does not have to select, develop, adapt, or customize the tools, libraries, and other components required to make a coherent whole (product development and integration);

• The customer does not have to test and ensure compatibility with other popular tools, operating systems, or libraries it uses (compatibility);

• The customer does not have to participate to the FLOSS co-ops to guarantee integration, toolset coherency, and participate to FLOSS R&D efforts over time (product evolution);

• The customer does not have to set-up an infrastructure to ensure that changes and enhancements in the source code do not introduce regressions in future releases (continuous integration);

• The customer does not have to build and package releases (productization);

• The customer does not have to test and verify the final products (quality assurance);

• For new releases the customer does not have to worry about compatibilities with previous versions (backward compatibility);

• The customer does not have to set-up and maintain a build, continuous integration, and productization infrastructure for current and future target hardware (build and QA infrastructure);

• The customer does not have to setup a continuous integration infrastructure so that it can receive a new qualified release when it needs a new feature or a blocking problem is solved (continuous integration infrastructure for qualified pre-releases);

• The customer does not have to recruit, nurture, and manage in-house expertise to ensure longterm support and availability for the tool set.

What all of the above boils down to is the fact that when purchasing a subscription with AdaCore the customer purchases an insurance about what it receives and the guarantee to receive assistance throughout the critical moments of its project.

Leveraged service organization

We use the term LSO (Leveraged Service Organization) to designate organizations similar to AdaCore. The L in LSO comes from the leverages exercised by the concentration of technical expertise along with the ability to set up an industrial quality and release cycle infrastructure for the FLOSS packages marketed.

Thanks to its expertise and infrastructure leverages, an LSO can offer FLOSS products and services of extremely high-value to its customers.

On Aligning with Customer Interests

For customers, an important benefit of the subscription-based model for FLOSS products, over a pay-up-front model is the customer-supplier alignment of interests.

The ERTS customer is interested in receiving a highquality product with a responsive and high quality service.

A vendor of FLOSS products such as AdaCore has a vested interest in seeing its ERTS customers be satisfied throughout the duration of a project since this increases the likelihood that the customer renews its subscription year after year.

In summary the business model of an LSO is aligned with the customer's engineering objectives, and this is a sound basis for a healthy business.

Conclusion

In this article we have discussed the possibility an ERTS manufacturer has when it wants to use a related set of FLOSS technologies.

The ERTS manufacturer has two basic choices:

• Rely on the FLOSS co-ops;

• Build in-house expertise and support the FLOSS technologies itself;

• Rely on a FLOSS vendor.

In the end, the decision of whether to rely on the community (co-ops), build internal expertise, or purchase the FLOSS and the required services from a vendor rests on a cost vs. risk analysis.

In the paper we describe an LSO which provides an interesting business model for a FLOSS vendor in the ERTS market.

An LSO sells FLOSS solutions on a subscription basis. An LSO leverages on its concentration of technical expertise, its communication channel to FLOSS co-ops, and the ability to set up an industrial quality and release cycle infrastructure.

Thanks to its expertise and infrastructure leverages, an LSO can offer FLOSS products and services of extremely high-value to its customers.

Thanks to the nature of FLOSS, an LSO aligns the interests of the principal stakeholders: customers, employees, and long-term investors. Contrary to short-sighted win/lose intuition this alignment maximizes long-term value creation for these three constituencies, creating an enduring and selfsustaining virtuous circle.


Keywords: Requirements management, model based design, Traceability Automation, Impact Analysis, DO178B, DO254, ISO 26262, RIF, Quality Process, workflow

This paper demonstrates two different solutions that have already been adopted by major companies of Automotive, Aerospace and Railway industries to automate such relationship with considerable costefficiencies, development time savings and quality improvements. It also introduces an innovative peerto-peer solution upon this newly introduced RIF standard, based on an intelligent client and a light MySQL server allowing all the parties to share requirements from their original Requirement Management tool.

Solutions To Automate Collaborative Requirements Management

A. Larronde-Larretche Eric 1 , B. Burgaud Lionel 2 , C. Fourgeau Eliane 1 1: Geensys, 242 Blvd Jean Jaurès 92100 Boulogne-Billancourt -FR 2: Geensys, Toulouse -FR Abstract: Years after years, the number of partners involved in a product development increases significantly. As a result and because of tight project schedule and high quality constraints, solution to improve the relationship between stakeholders of the same company, JVs, tier 1 and 2 is becoming mandatory to avoid project deliveries delays and bad quality (misunderstanding, lost requirements...).

Requirement-oriented document definition, with both standardized textual and/or graphical representations like SysML, is one of the best practices that appear for improving the communication and the exchange of specifications. Unfortunately even if requirement definition clarifies what the system shall do and speed up the commitment on system specification, the relationship, especially during specification negotiation and product delivery phases, is still time consuming due to heterogeneous processes and communication channels.

In recent years, some standards have begun to emerge which support the systems engineering process. HIS, a joint standard initiative of the German automotive industry created RIF (Requirement Interchange Format) for component specification exchange between OEM and potential tier suppliers.

Introduction

Requirement management became years after years a recommended activity for addressing new market challenges. Projects complexity is increasing, managing diversity on products and reusability of components is now the only way to stay competitive. Compliance with standards (FAA, FDA, ISO, Sarbanes-Oxley…) and providing evidence of quality is mandatory to address new markets. At the end, all these new objectives are reinforcing company's motivation to put in place such a new methodology, giving quantifiable benefits on product quality and product development time saving. The fact that product development is now distributed across organizations from different companies changes requirement management problematic. Specification and traceability evidences have now to be exchanged between different organizations. As a consequence, Requirement Management has to evolve to facilitate collaborative aspects especially for requirement exchange and traceability data consolidation. This paper presents several approaches based on Reqtify technology that have been chosen by companies from Aerospace, Automotive and Railway industries to succeed implementing collaborative requirement management with their partners.

Reqtify Technical Overview

Reqtify is a requirement management and traceability technology, originally born and matured in the European Aerospace industry, now also developing fast in other safety critical domains like Automotive, Railway, Energy, Semiconductors and pharmaceutical industries. The solution has been used on projects under most demanding quality and domains standards constraints:

• Aerospace: DO178B/C, DO254…

• Automotive: ISO26262, Spice, AUTOSAR…

• Railway: EN5012x, IEC6150x…

• Defense: MoDAF, DoDAF.

• Medical Devices: CFR 21part11, GAMP.

• Allow to meet CMMI Objectives.

Reqtify is an innovative technology that allows keeping engineering teams focused on their daily work, synchronized and focused on requirements, implementation and verification.

Typical use cases are System requirements defined using Word TM, Requirement Management tools, and refined using model-based approach with Simulink TM or Statemate TM , or a SysML[1] approach. SysML provides an emerging approach leveraging modelled requirements vs. textual requirements. Some advanced SysML tools or verification tools offer requirements traceability features, provided the requirements are created in their environment.

Figure 1: Requirement Traceability everywhere

(1) Requirements are captured from any source. They are made available everywhere for simple traceability

(2) Traceability is easily performed directly in the authoring, testing and coding environments.

(3) Work results and Traceability can be uploaded into repositories.

The Reqtify engine also takes as inputs process information describing expected traceability relations, and Company Standards describing requirements syntax. Results can be filtered to allow more accurate and oriented analysis and rules check consistency with best practices or company own process rules. Generic and/or specific analysis results are made available for users through the intuitive GUI, for reports generation, and also for 3 rd party tools.

Reqtify centric approach

Consolidation of partner's data is always time consuming and can be really painful if it has not been managed and fully organized in advance. This use case will demonstrate on a software component development project how to share traceability data between internal and external organization that are all using Reqtify technology. In most of 90% of the case the OEM lead the relationship and consolidate partner's project files in order to manage requirements globally and to show traceability evidences on the entire development lifecycle. The main benefits of this approach are the lightweight of the exchanged data (attached to an email) and the automatic linkage of partner's artifacts to the original requirements. This mode is fully automatic and allows OEM to measure impact analysis & global requirement coverage on both sides (OEM & Partners). The figure 3 just below depicts the traceability project hierarchy as it has been specified by the OEM. In this case the SRS (Software Requirement Specification) is the "software contract document" between all stakeholders. This is not a pre-requisite. It should be one for each partner but it is mandatory to establish and manage this "contract document" in a point-to-point relationship, to improve understanding and to automate the consolidation within Reqtify. On the OEM side, the SRS is covering a set of requirements coming from corporate know-how (Technical & Quality requirements) and Marketing requirements (User Requirement Document). The Software Requirement Specification document will be shared with partners A & B with Reqtify type of analysis that will give the ability to all stakeholders to automatically integrate and capture Requirements within Reqtify. At this stage each of the partners is fully independent and can manage his own Reqtify project throughout the activities he is in charge of. Traceability data as design hierarchies are extracted from each *.mdl file. As soon as traceability data are added by Designers, requirements coverage information is updated in a real time basis in Reqtify. In the same way, a code developer will add formalized comments at the top of each function or directly in the header of each file to manage requirement traceability in his piece of code.

OEM\Customer

As a consequence, each designer and coder can analyze how well requirements he/she is in charge of get covered and can easily measure the remaining required effort. Project manager and\or quality manager will take care of the full traceability picture as they have information in real time from Software Requirements to design and code. Reqtify gives a global view of the overall project status enabling risk analyses and providing help to prove compliancy with project requirements and constraints. For each delivery, partners will provide, in addition to product data, a Reqtify file (*.rqtfimage) that is containing all the extracted information from real project data. This file will be used by the OEM in order to merge partner sub-project with the original Reqtify project. As a result the contractor can measure requirement traceability and impact analysis from highest level requirements to partner's artifacts. He can generate automatically traceability matrices on the entire design activities. As Partner A, Partner B will have to fully cover software requirements with his V&V artifacts. A Software Validation Plan will first depict all the V&V activities that are going to cover all the software requirements. Then the validation plan will be covered by the test cases and the final test results within Quality Center TM . Verification engineers can link verification plans and results to both system and technical requirement assessments and can measure the impact of failed test results on higher level requirements. Partner B will generate an *.rqtfimage file in order to provide the entire traceability graph to the OEM. The OEM is now able to see all the verification branch traceability linked to the Technical, Quality and Business related requirements. No need to acquire all the tools that have been used by partners. Even real data are not requested by Reqtify to recreate the entire Traceability graph! As a result, the OEM is now able to generate automatically global traceability matrices on both validation and conception activities (Figure 5). Thanks to Reqtify, measuring risk and impact on project activities at each milestone is now as simple as one click away, even on partners activities.

Doors centric approach

If we consider the global project lifecycle, trying to get all the information managed in the DOORS database may lead to a huge and non reasonable effort. Project artifacts are generated by a significant number of tools and practices. This situation exists between internal teams but also, at a larger scale, for relationship between a customer specifying the "system" or the "equipment (LRU, ECU)" and subcontractors.

The Reqtify technology is widely used and offers support of several practices that we describe here.

The best solution to apply depends on several criteria:

• The first criteria will be the capability (or not) for the subcontractor to access the Doors requirements database.

• The reference applied to the customersubcontractor relationship. Frequently the reference to consider is a set of documents.

The Figure 3.1 describes several ways to create requirements-based exchanges between the customer and the subcontractor. Case B is a case very widely used. In a lot of contexts, the reference for the exchanges are documents (Word, PDF,…). Typically, requirements are discussed and defined using Doors; Specifications documents which are then sent to subcontractors are Word documents generated from Doors. So we see a lot of cases where subcontractors say "our requirements come from Doors", the reality being that requirements are contained in Word documents coming from Doors.

In the same way, what is expected by the customer is a set of traceability matrices, contained in Word documents generated by the subcontractor, typically an appendix to the Design Document,…).

In this case there is no real logic to have a direct interface between tools: The customer uses Doors, then generates Specification documents. Reqtify captures requirements in those documents, and also captures project artifacts with the traceability information, then generates traceability matrices that are sent to the customer.

Hundreds of projects are in this case, since the very first versions of Reqtify in 2001. Characteristics of this case are as follows:

• More consistent and synchronized with the contracts that are usually document-based. • Tool Independent (all the documents could even be written manually…) • Tool capabilities are not fully used, a gap still exists between the customer and the subcontractor environments and exchanges are timed by document releases.

In the case A, there is a direct, bidirectional exchange between tools: Doors requirements are captured directly from the database, Project artifacts and traceability information captured by Reqtify can be directly uploaded in the Doors database, allowing Doors users to navigate in the whole project lifecycle. • From Doors, the customer imports the information into Doors, and the corresponding modules and linked modules are created.

Highlights for this case are:

• Subcontractor needs only Reqtify

• Specifier/customer needs to modify the Doors configuration to include this add-in.

Specification exchanges between OEMs & Suppliers

Another key aspect of a collaborative requirement management approach is the requirement exchange between OEMs, Suppliers and the different partners involved in the product development process. A wide range of benefits for system engineering and purchasing departments is created by the edition of a central specification that becomes the reference for both sides.

The main difficulty of this approach, as soon as requirement has been specified correctly (i.e. unambiguous, complete, testable, and traceable, with good granularity...), is to manage the arbitration on requirements and to create the good specification configuration according to component variants. VDA

[2] provides the prerequisite for raising quality on a standardized component requirement specifications document in the automotive industry.

To address this objective, a primary need is the ability to import and export automatically specifications between different IT/Requirement Engineering tools. Reqtify implements exchange automation between different requirement management and Office tools: it has already been chosen to manage the relationship between major automotive actors. The two others benefits are the capability to keep the history on specification negotiation and to create specific requirement configurations on system variants. HIS [3] has defined a requirement interchange format RIF [3] to break down the boundaries between RE tools available on the market. Reqtify has integrated this format as a new entry point called RIF Gateway. The picture just below shows a requirement exchange process with change and specification configuration management that has been implemented with this solution:

Figure 9: Typical specification exchange between OEM and partners.

Conclusion

In today's projects which involve distributed teams, a large number of tools, tasks sharing, etc., it is necessary to consider flexible and open solutions in order to successfully manage diversity. This paper has provided several use cases where requirement management can be shared and kept synchronized between project stakeholders from different organizations.

For the companies that prefer collaboration between tools rather than the difficult objective of deploying the same solution everywhere for everyone, it is now proven that there is a technology that can leverage the respective added values of several tools and environments, for system, software and hardware engineering domains.

Worldwide economy evolution is impacting all process & practices needed to reach quality level objectives requested by market demands. The key success factors for system companies are directly related to their capacity to efficiently reduce time spent between the different stakeholders in the product development chain. Reqtify is a proven technology, which has been widely delivering its value in achieving such goals; in all of its current market sectors -automotive, aerospace, train transportation etc.., Reqtify has confirmed that avoiding revolution with pragmatic evolutions is the safe and cost-effective way to go.

Figure 2 :

 2 Figure 2: Analysis of Project information

Figure 3 :

 3 Figure 3: Traceability project on OEM/Customer side

  Figure 4: Traceability project on Partners side Partner A has to fully cover requirements captured from SRS document with Simulink TM designs.

Figure 5 :

 5 Figure 5: Impact analysis & Traceability matrix on OEM side

Figure 5 :

 5 Figure 5: Several collaboration solutions.

Figure 6 :

 6 Figure 6: Document-based exchanges

Figure 7 :

 7 Figure 7: Direct bidirectional collaboration

Figure 8 :

 8 Figure 8: Integration as a Doors Add-In

About the Authors Eric Larronde-Larretche

Eric holds a Master 2 Pro in Quality and Safety of embedded systems. After some years as an R&D Engineer in Valiosys company -where he worked on software formal verification of safety critical applications, Eric Joined TNI-Software as a Worldwide Field Application Engineer. Eric is currently Reqtify Products Line Manager for Geensys (ex TNI-Software), in charge of the requirement-based solutions and tools integration for major companies in Aerospace, Automotive, Railway and Semiconductors worldwide. Eric.larronde@geensys.com

Lionel Burgaud

Lionel is Aerospace Business Unit Manager for Geensys (formerly TNI-Software).