Patrick Briand

Martin Brochet

Thierry Cambois

Emmanuel Coutenceau

Olivier Guetta

Daniel Mainberte

Frederic Mondot

Patrick Munier

Loic Noury

Philippe Spozio

A Patrick Briand

B Martin Brochet

D Emmanuel Coutenceau

E Olivier Guetta

F Daniel Mainberte

G Frederic Mondot

H Patrick Munier

I Loic Noury

J Philippe Spozio

K Frederic Retailleau

Software Quality Objectives for Source Code

Keywords: Quality, run-time error, absence, formal method, MISRA, formal proof, software

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

This document has been produced by a working group which includes the automotive manufacturers Renault SA and PSA Peugeot Citroën, the automotive suppliers Delphi Diesel Systems and Valeo, and software supplier The MathWorks1 . The document defines a general and standard approach to measure the software quality of a product using criteria linked to code quality and dynamic execution errors.

N.B:

This current work does not cover functional test activities.

Origin of Software Quality Objectives

After the PolySpace company acquisition by The MathWorks in 2007, a new dynamic occurred. The MathWorks team worked as facilitator to organize a meeting with PSA Peugeot Citroën and Renault SA. The objective of this meeting was to get their feedback about PolySpace product usage. During this discussion PSA Peugeot Citroën and Renault presented their 4 PolySpace usages:

-Risk prevention of non-quality embedded software -Acceptance criteria for product delivery or process embedded software -Audit/Assess the quality of embedded software -Investigate the possible causes of malfunctions And these uses had several objectives:

-A "deterministic" implementation to know exactly the software quality integrated in vehicles. -Keep a good technical/economic performance by maximizing the automation (e.g. reduce the number of warnings need to be analyzed manually) -Compliance strategy (to obtain results) rather than means (tools to use)

From their experiences automotive manufacturer gathered a set of common difficulties:

-The analysis reports were not homogeneous, they were homemade, did not always indicate whether the preconditions of the analysis were validated and did not guarantee their integrity or completeness. (e.g. MISRA compliance). Incremental verification between 2 software deliveries and comparative treatment of the associated report were difficult -The reports documented numerous measures and/or warnings without providing the method of analysis involved (see Process Area MA CMMi) which increased the presence of inaccuracies and false alarms -The method of verification report was not formalized and validation of justification was difficult, it was primarily for validation (expert opinion). The report study did not provide the possibility to easily conclude on the software quality and made judgments "OK or Not OK" on the product embedded software.

In regard of this feedback the working group decided to: Gather criteria, (complexity metrics, measure of unreachable code, etc) to be able to objectively measure "Software Quality" Formalize relationships and communication between automotive manufacturers and their suppliers through a list of requirements. Ask software suppliers to provide guidelines on how to use their tools (ex: PolySpace) to produce information required.

After two and a half years the working group got agreement between automotive manufacturers and suppliers on a standard requirement list and described it in the Software Quality Objective document version 2.0. This requirement list consists of six Software Quality Objectives (SQO) which are associated to four quality levels, Quality Levels 1 (QL-1 lowest quality) to Quality Levels 4 (QL-4 highest quality).

The following document will present the content of the Software Quality Objective. If you need more information about the software supplier implementation, please contact them.

Software Quality Objectives (SQO) Overview

The first working step was to define generic acceptance criteria.

Generic acceptance criteria

The criteria selected to build Software Quality Objectives are focused on static and dynamic software quality and also takes into consideration the organisational information, which helps the car manufacturer to better understand who performs the work, and how and where the work is done.

Static and dynamic criteria are spread over six others themes:

-Detailed design description, -Code metrics, -Coding rules, -Unreachable branches, -Run-time errors -Dataflow Analysis.

Definition of 6 incremental Quality Objectives

Differences between Software Quality Objectives 1 and Software Quality Objectives 6 are the number of requirements to fulfil. The following table presents this distribution over the 6 Software Quality Objectives.

For the SQO-1 (Software Quality Objectives) the supplier has to provide information regarding Quality Plan, Detailed design description, Code metrics and Coding rules.

For higher SQO, some additional criteria come in.

For the SQO-3 the supplier has to provide information to the car manufacturer about systematic Run Time Error, Non terminating information and unreachable branches in addition to information already present in SQO-1.

For the SQO-6, the highest SQO, the supplier has to provide information about a bigger set of coding rules, non terminating construction, Dataflow Analysis and an advance level of review coverage for potential run-time errors.

The incremental process for quality levels is mapped to vehicle development processes which guarantee integration of items of increasing maturity.

Software Quality Objective vs. Quality Level

Software Quality Objectives (SQO) are associated with four quality levels, Quality Level 1 (QL-1 lowest quality) to Quality Level (QL-4 highest quality). It is up to the supplier and car manufacturer to negotiate and map SQO to their deliveries and completely integrate it to their schedule.

The supplier shall provide a quality plan which shall consist of a table showing for each module:

• The corresponding Quality Level (QL-1 to QL-4) • The quality objectives for that level • The number of times the module will be delivered during the project.

N.B.: the automotive manufacturer shall validate the software quality plan and the decisions taken within it.

The following example table shows the possible progress for each quality level to achieve the final Software Quality Objectives. The number of quality levels is fixed. The SQO associated to the first, last and penultimate deliveries are also fixed. The number of deliveries (table lines) is project dependant.

Delivery

Quality Level QL-1 QL-2 QL-3 QL-4 First SQO-1 SQO-2 SQO-3 SQO-4 X Intermediates … … … … X Intermediates SQO-2 SQO-3 SQO-4 SQO-5 X Intermediates … … … … Penultimate SQO-3 SQO-4 SQO-5 SQO-6 Last SQO-3 SQO-4 SQO-5 SQO-6

N.B.:

The penultimate and the last delivery have the same SQO. This is to increase the probability to obtain at the last delivery, the SQO decided at the beginning and associated to a quality level.

How to associate each level to your application?

As expressed before, at the beginning of the project the supplier and the car manufacturer have to associate a quality level to each software module. The document does not provide recommendation or criteria to do it.

To accomplish this work several criteria should be used and combined. The final objective is to achieve an agreement between both sides.

The SQO document does not exclude any kind of source code. All software modules have to be associated with Quality Level, whatever the type of code it may be: automatically generated, handwritten, legacy, or COTS. After that both sides should respect these commitments.

Systematic run-time errors

This criterion shall prove the absence of systematic error in the supplier software. The supplier shall demonstrate that for all files within a module a review of systematic runtime errors has been performed and that errors which have not been corrected are justified, for the following categories:

• Out-of-bounds array access • Incorrect dynamic_cast on pointer (for C++) • Incorrect dynamic_cast on reference (for C++) • Invalid pointer to member (for C++)

• Call of pure virtual function (for C++)

• Incorrect type for this-pointer (for C++)

Non terminating function calls and loops

This criterion shall help suppliers to present the amount of verified non terminating function calls and loops in their software.

If the code intentionally contains:

• Non terminating loops like 'while(1)' or 'for(;;)' • Non terminating calls like 'exit', 'stop', 'My_Non_Returning_Function' these should be justified.

Unreachable branches

The supplier shall demonstrate that files do not contain any unjustified dead code branches, as well as all defensive code and dead code intentionally contained in the application shall be justified.

Three subsets of potential run-time errors

This criterion shall help suppliers to present the amount of verified operation presents in their software.

The supplier shall demonstrate that for all files within a module, a review of potential runtime errors with review coverage level 1 (lowest), 2 or 3 has been performed and that potential errors which have not been corrected are justified The 3 subset lists of run time error are the same as presented in the 8.5 Systematic run-time errors paragraph. Hereunder there is an example of percentage defined for review coverage level 1:

• Out-of-bounds array access: 80%

• Division by zero: 80%

• Read access to local non-initialized data: 80%

• overflow/underflow: 60%

• ...

N.B.:

For runtime errors the review coverage is defined by a percentage, indicated after the runtime error category (example: "Division by zero: 80 %") which represents the number of operations concluded as proven safe or justified. These conclusions could be drawn:

-Automatically (with a tool); -Partially automatically and completed manually; -Totally manually.

Example: let's take an application containing 60 divisions. Let's assume that the review coverage objective is "Division by zero: 80%".

Then the 80% review coverage can be reached by proving that at least 80% of the divisions are "safe operations" or "potential runtime errors" that can be justified. Let's consider that a tool is used, which proves automatically that 45 divisions out of the 60 are "safe operations". The review objective can be reached by demonstrating that at least 3 "potential errors" can be justified, because (45 + 3) / 60 = 80%.

Dataflow Analysis

This criterion shall help automotive manufacturer to see the dependencies in the supplier application files architecture (global variables read/write location) and show if all shared variables are protected.

The supplier shall provide for each module, the data flow analysis results.

This shall contain at least:

Conclusion

Currently "Software Quality Objectives" version 2.0 is available.

PSA Peugeot Citroën and Renault SA integrated Version 1.0 in their Quality Requirements in 2009 and already got some feedback from suppliers in October 2009.

Renault integrated it as rank 2 in their requirement but they are negotiating with Nissan to integrate it in their rank 1 requirements.

Valeo & Delphi Diesel System promoted this document internally and they are currently working on a solution to implement this standard in their process.

The MathWorks presented it to several companies from the automotive industry, Railway industry, defence industry, in France and abroad (Germany, Japan and USA)

Presentations have been given to several other software companies, including Coverity, KlocWork and Programming Research (QAC author).

Work is ongoing to evaluate the interaction between the SQO standard and ISO-26262 and establish how the SQO complements the ISO-26262 requirement and how it covers it.

The SQO standard version 2.0 is available; please contact the work group to get it and provide feedback 11. Glossary COTS: Commercial, off-the-shelf is a term for software or hardware, generally technology or computer products, that are ready-made and available for sale, lease, or license to the general public. They are often used as alternatives to in-house developments or one-off government-funded developments. The use of COTS is being mandated across many government and business programs, as they may offer significant savings in procurement and maintenance. However, since COTS software specifications are written by external sources, government agencies are sometimes wary of these products because they fear that future changes to the product will not be under their control.

Automotive manufacturer: is a company that uses a component made by a second company in its own product, or sells the product of the second company under its own brand. It constitutes a federally-licensed entity required to warrant and/or guarantee their products, unlike "aftermarket" which is not legally bound to a government-dictated level of liability.

Supplier: automotive components manufacturer.

SQO: Software Quality Objectives QL: Quality Level

MISRA:

The Motor Industry Software Reliability Association (http://www.misra.org.uk/)

ISO 26262: Is an emerging ISO standard for safety systems in road vehicles engine (http://www.iso.org/) HIS: Hersteller Inititiative Software. Initiative from German automotive manufacturers (Audi, BMW Group, DaimlerChrysler, Porsche and Volkswagen) whose goal is the production of agreed standards within the area of standard software modules for networks, development of process maturity, software test, software tools and programming of ECU's. HIS specifies a fundamental set of Software Metrics to be used in the evaluation of software. See http://portal.automotivehis.de/images/pdf/SoftwareTest/his-scmetriken. 1.3.1_e.pdf

With Patrick Artola participation (DevQuality).

Software Quality developed in criteria

Each Software Quality Objective consists of a set of 12 criteria listed in the table below

First subset of potential runtime errors

X X X

Second subset of potential runtime errors

X X

Third subset of potential runtime errors

X

Dataflow Analysis X

Criteria distributed over Software Quality Objectives

Quality Plan

This criterion describes the general information which shall be provided by a supplier. It covers information about the methods, tools and teams involved in the Software Quality Requirement fulfilment, as well as information about the project itself. This information shall help to better understand who performs the work, and how and where the work is done.

Detailed design description

The information provided in this criterion will help evaluate the architecture of the application and its maturity. This will form the basis for following criteria of the document. Three levels of information have to be provided:

Two MISRA-C:2004 rules subsets

These two criteria shall help the automotive manufacturer to evaluate the code quality and maintainability. The criterion shall help the automotive supplier to be more efficient regarding the reduction of the number of Run Time Errors. Two MISRA-C:2004 rules subsets were defined; the first one covers 20 rules and the second one 29 rules.

The objective is to correct or justify all violations, i.e. zero remaining violations found by the tool or remaining violations unjustified.


E Andrianarison

J-D Piques

SysML for embedded automotive Systems: a practical approach

Keywords: Model Driven Engineering, System Modeling, SysML, System Engineering 1. Overview

While SysML (System Modeling Language) is a leading topic for System Engineering (SE) in all domains, there is no pragmatic implementation of SE for automotive embedded systems and products. In this paper, a proposal is developed to meet the needs of Valeo product lines.

As an introduction to the proposed SysML method, Part 2 is intended to emphasize major challenges related to system engineering in automotive and expectations from a model based approach. Methodological background and SysML positioning regarding research are developed in Part 3. Part 4 illustrates a SysML implementation of the modeldriven SE process, experimented at Valeo's on pilot projects. Part 5 describes how SysML must be supported by an integrated set of tools. Remaining open issues are finally addressed in Part 6, to go further on the subject.

Motivations

Automotive challenges

While intrinsic systems complexity is often highlighted, the increasing complexity of organizations responsible for system development shall also be emphasized. The quest for the holly grail of R&D competitiveness and the globalization of the automotive industry have revealed a need for efficient use of worldwide competence centers and thus collaboration of teams located throughout the world. Thus, many (not saying all) automotive developments use multidisciplinary and distributed concurrent engineering. To mitigate risks, automotive actors are deploying processes (CMMI, HIS-SPICE...) requiring more and more formalization and effort in document writing. Furthermore increasing complexity and safety expectations (upcoming ISO26262) are also in favor of that. Such trend has huge impacts on automotive actors who historically worked out a fine-grained trade off between cost, quality, performance and development cycles. Automotive lean processes have now to cope with higher formalization needs and still whilst ensuring flexibility and R&D efficiency. What is ultimately at stake is to improve formalization, avoiding administrative documentation drawbacks and degradation of expected gains. At the same time, this context is also a unique opportunity while automotive industry is facing a major market breakthrough with a move towards electrical and hybrid vehicles. New products are expected and innovation is taking over usual carry over. From this point of view, system approach and higher formalization are key levers to secure investments and work out innovative systems and products.

Drawbacks of document centric approach

Implementation of requirement driven processes with document centric data management has been achieved in domains requiring high traceability of safety related designs. Taking benefit of their feedback, the following drawbacks have been identified:

• to achieve a minimum formal level with text, consistent effort is spent in writing valid requirements that are testable, clear, consistent .. • engineering models such as state machines or architectures are difficult and expensive to transform into textual requirements • consistency and configuration of these artifacts are hard to manage efficiently. This often leads to disconnect engineering artifacts and project documents All these issues are impacting R&D efficiency and ability to achieve quick iterations, whereas adopting a model centric approach allows: • to re-focus engineers on added value tasks by increasing actual time spent on design • to ensure a seamless and costless traceability / consistency between different design elements (functional/organic architectures …) • to provide graphical means which ease information sharing among different discipline teams 2.3. Benefits of model based approach On top of that, major system engineering improvements are also expected. Sufficient effort shall be dedicated to problem statement and new means to work out and formalize stakeholders' needs are required. As different architectures and products are competing, support for design exploration and decision making is required. The short coming ISO26262 regulation reinforcing functional safety activities is in favor of a tight coupling between system and safety processes.

Interfacing functional and dysfunctional descriptions is a prerequisite to achieve "Safety in the loop" (SaIL). More generally, model based approach will provide a seamless and efficient way to rework designs in iterative innovation developments.

Methodological background

System engineering mindset

A common issue is to define what a system is, and when to use system engineering. Actually, the critical point is how you consider the "object" under design, not what the "object" actually is. Adopting a system approach, involves considering various aspects in a parallel and consistent way. These different focuses are commonly called points of view (viewpoints). These points of views may apply to system as well as components, parts … Methods and thoughts mentioned here are not only targeting pure systems in Valeo but are also applicable to components/products, to ensure managed transition to the different implementation disciplines.

Point of views

Among research projects focusing on complex system modeling, SAGACE ([1], [START_REF] Penalva | La modélisation par les systèmes en situations complexes[END_REF]) demonstrates that 9 "orthogonal" viewpoints allow a complete and optimized formalization of all system concerns. From this theoretical basis, selection of viewpoints has been achieved taking into account current risks related to each concern on Valeo systems and products. For migration path reasons and to cope with system engineers' learning curve, a first step focus is dedicated to the 6 (among 9) following viewpoints:

• External actors needs (static) • Interactions scenarios/mission profiles • Provided services to external actors • Internal operations • Physical resources and related breakdown • Internal operations mapping onto resources Most viewpoints related to system fairness regarding adaptation to context, actors, resources or services changes have been discarded.

EAST-ADL2 as automotive ontology

In order to make sure that models are meaningful, concepts used (functions, ECU, actuators…) and links shall be formally defined to provide an automotive ontology. During the last past 10 years, successive European automotive projects have contributed to work out EAST-ADL2 (Automotive Description Language, [START_REF]EAST-ADL2 Language and Profile[END_REF]) which defines an architecture framework and provides a metamodel of automotive specific artifacts. Here also, a subset has been defined regarding Valeo specific needs as an automotive supplier:

SysML opportunity

Nevertheless, there is currently no modeling industrial tool available on the market using this automotive Domain Specific Language (DSL). Being method agnostic and providing a very general boxology with "low" semantics, SysML therefore may be used to describe selected SAGACE system viewpoints and EAST-ADL2 artifacts. This allows for instance to use the same SysML block definition diagram (BDD) to describe either a functional or a physical breakdown. Thus SysML appears to be a unique opportunity to implement "EAST ADL2 friendly models" and take benefit from the defined architecture framework. SysML method added value consists in:

• Selecting a diagram subset (among 9 available) which allows viewpoints and artifacts implementation in a convenient way for system engineers (learning curve optimization) • Providing defined semantics to ensure diagrams meaning • Providing an obvious diagram sequence which ensures modeling efficiency regarding company processes • Taking into account interfaced processes and tools constraints such as Reqtify from Geensoft for requirement traceability or Simulink from The Mathworks for continuous modeling The current method is therefore targeting the optimum trade off for Valeo deployment and is built from existing state of the art. It does not claim for any theoretical novelty while having merged relevant best practices from existing approaches listed in the bibliography ( [START_REF] Caron | Exigences et ingénierie système : Mise en oeuvre avec SysML[END_REF], [START_REF] Friedenthal | A Practical Guide to SysML -The Systems Modeling Language[END_REF], [START_REF] Weilkiens | Systems Engineering with SysML/UML -Modeling, Analysis, Design[END_REF], [START_REF] Hoffmann | Rational Harmony for Systems Engineering -Deskbook release 3.0[END_REF], [START_REF] Roques | SysML par l'exemple[END_REF]), such as EIRIS method. This implementation is also taking maximum benefits from available features of the selected SysML tool for Valeo pilot projects, namely Artisan Studio from Atego. Furthermore, for the first step, no particular emphasis was put on execution and simulation of the SysML model.

Valeo SysML example

Diagrams selected to illustrate the approach are extracted from a tutorial example used as training on pilot projects. For confidentiality and readability reasons it has been preferred to using diagrams directly extracted from pilot projects.

The method described below is under validation on pilot projects and is obviously subject to changes and improvements, to take into account field return.

Model-driven System Engineering process

The overall System Engineering process begins with the project context, considering the system to be developed as a black box, studying the environment, and then successively going deeper into the details. More precisely the System Engineering process is divided into four major phases:

• Stakeholder needs definition

• Requirements analysis

• Logical architecture design

• Physical architecture design

In the following, the process and the sequence of activities will be described in a pure sequential way. However, in practice different steps could be performed simultaneously with iterative and mutual refinements. Moreover, even though not detailed in this paper, each phase systematically ends with a traceability analysis to check the completeness of activities performed and artifacts developed. Finally, the kind of diagrams used at each step will be given by acronyms in brackets at title level: Block Definition Diagrams (BDD), Internal Block Diagrams (IBD), Use Case diagrams (UC), Sequence Diagrams (SD), STate Machine diagrams (STM), ACTivity Diagrams (ACT), REQuirements diagrams (REQ).

Stakeholder needs definition

Probably the most important step in a system development process is collecting initial needs to secure the goals that the system under development is to pursue. The key steps of this phase are:

• Identify all the stakeholder needs • Define the boundaries of the system and external actors involved • Identify the user level operating modes • Identify and describe the operational use cases • Link the stakeholder requirements to the operational use cases At this stage, all analyses are performed from the system external user point of view, the system being considered as a black box. The output of this phase is the Stakeholder Needs Document (SND) that makes a synthesis of all activities performed.

Stakeholder needs identification (REQ)

All individuals and organizations that may have an interest in the system are the potential source of requirements and therefore should be identified prior to all other activities. The key point is that stakeholder needs should describe the services expected by the system user, and not how the system will fulfill these needs. The sources of stakeholder needs will be managed outside of the SysML model, within requirements documents or specific databases. It is particularly important to capture mission-level performance requirements and measures of effectiveness that will be used later to select the best candidate solutions. The next step is to import stakeholder needs (with all their relevant fields) into mirroring SysML requirement objects (with same identifiers). A gateway mechanism such as Reqtify is required to perform a mono-directional synchronization (from external data to SysML) in case of change of source data. Because the standard SysML requirement format is quite limited, the extension mechanism of stereotypes is used to add new specific attributes to keep track of extra information contents. The first application of stereotyping attributes is to differentiate requirements imported from external requirement repositories from those created directly inside the SysML model. Moreover, other stereotyped tags should be declared to store specific information or resulting from the elicitation activities.

System context modeling (BDD)

The system context model represents the direct environment of the system and gives initial information about the system boundaries and the communication flowing between the system and external systems and users that the system interacts with. The first step is to identify the different stages of the system lifecycle, from manufacturing to recycling. The next step consists in representing all currently known interaction partners, using SysML actor objects. An actor is not necessarily a concrete individual or system, but a role played by an outside element in interaction.

Then, interactions between actors and the system are represented as SysML association relationships.

The purpose is to identify basic information helpful to determine the services requested from the system embedded in its environment (the use cases), and not to give technical details of these services.

Even though, the context diagrams may seem obvious, in practice, searching for actors can lead to very fruitful discussions between the different stakeholders.

User modes identification (STM)

A mode characterizes a situation in the system life for which a specific expected behavior can be defined. It represents a state invariant of the system from the external user point of view, e.g. regarding the service given to the user and not how this service is performed by the system. The goal is to derive a unique state machine aggregating all the modes and main transitions identified in the interactions with external users. Therefore, establishing the user mode state machine is an iterative process tightly coupled and interleaved with operational use case identification described in the next chapter.

Operational use cases identification (UC, SD)

Use cases represent the services expected from the system, which means that they will be key elements to the requirement analysis stage. Indeed, use cases will help to refine stakeholder expectations and therefore identify system requirements in greater details. Uses cases will be identified starting from the context model, asking what the actors want of the system, especially with regard to their roles and to incoming information flows. More precisely, a use case always refers to at least one actor; it is started by an external trigger; and it ends with a user result. Moreover, as many use case diagrams as stages of the system lifecycle will be described. In fact, a use case can be seen as a group of scenarios performed by the same main actor, with the same starting point and leading to the same ending point. These scenarios describe sequences of actions, beginning with the same pre-condition (trigger) and ending with the same post-condition (result); the pre-condition and the post-condition corresponding to modes in the user mode state machine mentioned in the previous chapter The purpose is to describe the sequence of steps involved in the different alternative scenarios, either leading to the expected result or to failure. This is done using SysML sequence diagrams. It is particularly important to notice that, at this stage, scenarios will only be described at user interaction level. The sequence diagram established here is primarily aimed at identifying the system interfaces. It will be further refined at requirement analysis stage to identify functions performed by the system.

Traceability to stakeholder needs (REQ)

We remember that stakeholder (or initial) requirements refer to statements that define the expectations of the systems in terms of mission objectives, environment, constraints and measures of effectiveness/suitability, from the system user point of view. In order to make sure that all stakeholder needs are covered by the operational use cases, respective traceability links have to be established between SysML use case objects and requirements.

Requirement analysis

The objective of the requirement analysis phase is to analyze the inputs previously collected, to move from a problem statement to an abstract solution.

The key steps of this phase are:

• Describe the interfaces of the system with external actors precisely • Identify the system level operating states • Develop and refine the system use cases • Develop and refine the system requirements into external function and interface descriptions • Link system functions and interfaces to the system requirements At this stage all analyses are performed from system designer point of view, the system still being considered as a black box. The output of this phase is the System Requirement Document (SyRD), which summarizes all activities performed.

System interfaces description (IBD)

The objective of the system interface description phase is to give more details on the interaction flows between the actors and the system (always seen as a black box). The system physical external interfaces are described using internal block diagrams. mechanical, electrical, data processing buses…) to ease information sharing with involved disciplines.

System states identification (STM)

The objective of this step is to derive a unique state machine, resulting from the aggregation of all the states and main transitions identified in the system scenarios it participates in. This state machine will be the central element of the system model to which complementary artifacts will be later attached to, with the final target in mind being its validation by simulation.

The system state machine is not necessarily a refinement of the user mode state machine, as possibly new sub-states or suppressed states and even a completely different structure may be defined. Practically, establishing the system state machine is an iterative process tightly coupled and interleaved with system scenarios refinement described in the next chapter.

System scenario refinement (SD)

The objective of this stage is to refine user level scenarios in order to identify services to be provided by the system. Therefore, this activity is similar to a classical external functional analysis.

The sequence diagrams previously established to describe actors/system interactions are complemented by functions to be performed by the system (always seen as a black box). As shown on the figure below, these functions are denoted as loop interactions on the system lifeline and modeled as SysML operations attached to the system block. The refinement of user scenarios into system scenarios will possibly lead to new interaction events and even to a new structure of use cases.

System requirement capture

The process under validation in the pilot projects is to avoid a redundant writing of system requirements as textual requirements in an external requirement management repository, and to choose the SysML model artifacts as the reference for system and component requirements specification. Indeed, interface requirements are modeled by ports and related type definitions, while functional requirements are represented by operations, both being owned by the system block.

Logical architecture design

The objective of the logical architecture design phase is to describe how the system will be internally structured to realize the expected features, but without any consideration of their upcoming physical implementation.

The key steps of this phase are:

• Identify the set of internal functions to be provided by the system • Describe how these internal functions are activated depending on the system state • Group these functions into coherent logical blocks • Develop and refine the logical interfaces between the logical blocks • Link internal functions and interfaces to the logical blocks • Take into consideration any existing and relevant architecture At this stage all analyses are performed from system internal point of view, the system being considered as a white box. The modeling elements developed in this phase are included in the System Design Document (SyDD), which makes a synthesis of all logical and physical design solutions and their mapping.

Internal functions identification (ACT)

The objective of this step is to provide details on the internal behavior of system block operations. Therefore, the kind of task performed is similar to a classical internal functional analysis. The activity diagrams use data flow and control flow representations in a hierarchical decomposition to work out internal activities that should be performed. The lowest level activities (namely leaves activities) of this hierarchy represent internal functions. The key point is that the upper level activity diagrams describing the internal behavior are triggered by the system state machine, which will be an interesting and mandatory property for later execution of the system model.

Logical blocks definition

The objective of this step is to factorize and group system internal functions (leaves activities) into subsets to support the analysis of alternatives during physical architectural analysis. These subsets, called logical blocks, are abstractions of the components that will be implemented by the system; they perform the system functionality without imposing implementation constraints. The selection of each logical block is based on qualitative or quantitative criteria such as modularity or reuse of existing components. The logical blocks are declared as SysML blocks with allocation relationships to the leaves activities performed. Moreover, operations are declared at block level to perform the activities which have been allocated to.

Logical architecture definition (BDD)

The logical architecture describes the compositional relationships between the upper level system block and constitutive logical blocks. It serves as an intermediate level of abstraction between the system requirements and the physical architecture. This intermediate level can reduce the impact of both requirements and technology changes on the physical design. This description is performed using a block definition diagram.

Logical internal interfaces description (IBD)

The objective of the internal logical interface description step is to give more details on the interaction flows between the internal logical blocks. The system logical internal interfaces are described using internal block diagrams. To specify the kind of admissible data flow, a type indication shall be associated with each port, using SysML item types or flow specifications.

Physical architecture design

The focus of the physical architecture design phase is on the development of a physical architecture (e. Evaluate the measures of effectiveness • Select the best physical architecture solution based on measure of effectiveness criteria The modeling elements developed in this phase are included in the System Design Document (SyDD), which makes a synthesis of all logical and physical design solutions. The output of this phase is a also a set of Component Needs Documents (CND), which correspond to specifications for the components or disciplines modules to be implemented.

Physical blocks definition

The focus of the physical architecture design phase is on the allocation of logical operations to the components of a physical architectural structure. This structure may result from a previous trade study or a given (legacy) architecture. The partitioning criteria used for allocation should reduce the impact of requirements and technology changes and more effectively address key issues such as performance, reliability, efficient re-use of COTS, maintainability, security and cost. At the lowest level of the architectural decomposition, the functional allocation shall address the realization, e.g. which operation shall be implemented by which physical component developed by a single specific discipline (e.g. hardware, software, mechanics…). The physical blocks are declared in the same way as logical blocks, using SysML blocks and linked with allocation relationships to the logical blocks they implement. Moreover, operations are implemented at block level to perform the activities which have allocated to.

Physical architecture definition (BDD)

The physical architecture describes the compositional relationships between the upper level (physical) system block and its constitutive physical blocks. This description is performed using a block definition diagram in the same way as for the logical architecture.

Physical internal interfaces description (IBD)

The objective of the internal physical interface description step is to provide more details on the interaction flows between the internal physical blocks, using internal block diagrams. The analyses performed by the system modeling tool can result in proposing updates to the requirements baseline, but the textual requirements are formally updated and controlled in the requirement management tool.

Traceability reports are generated and used to analyze how the system design meets the system requirements and to perform impact analysis in case of changes. In fact, two kinds of analyses are performed:

• Internal traceability analysis, between the SysML model artifacts, directly generated using the SysML tool, • External traceability analysis, between the text requirements repository and the SysML model boundary, performed, using a standard requirement traceability tool such as Reqtify.

Configuration management

Configuration management tools ensure that models and other development artifacts are maintained in a controlled fashion and that baselines are well identified.

The SysML tool is used with internal configuration management and change control features activated to provide a small granularity on configuration items manipulated. However, for major milestones, the packages contents of the SysML database are baselined and put under the standard configuration management tool. Therefore, packages are used to partition the model and constitute the unit of external configuration control.

System simulation

The SysML system model information can be used as a basis for building an executable system model to analyze the dynamics of the system. To support this, the static system modeling environment must be complemented by an execution environment. This execution environment could be either directly supported by the SysML tool or performed by an external simulation tool. The approach selected for pilot projects is to transfer only components architecture description information to discipline specific tools in charge of refining an implementation dynamic model. For instance, internal blocks diagrams describing the software architecture of a control law are translated into Simulink dataflow models, with a direct mapping of blocks, flows and ports. The internal behavior of the component will be thereafter detailed and simulated in the Simulink modeling and execution environment.

Document generation

Document generation tools are used to prepare and manage formal documentation of the system design, in a format that is easily comprehensible by a broad range of stakeholders. These documents are an effective way to organize, validate and communicate system design information. Thanks to the feature of the SysML tool, automatic document generation can be run on demand to collect and format data from the SysML model, without any special effort. The only thing to do is to pre-define the expected document format (e.g. SyDD, CND…) by defining a specific template, which can be re-used on different projects, to generate documents related to project specific milestones.

Data exchange mechanisms

The interface between the system modeling tool and the discipline-related ones (e.g. hardware, software, mechanics…) is a critical issue. Indeed, the system modeling tool provides the component specifications for the different disciplines and it is crucial to avoid loss of information and reworking of data exchanged. Among the possible alternatives, approaches independent from the tools are preferred to those using tool-dependent interaction exchange protocol (for instance APIs). From this point of view, a filebased exchange mechanism based on neutral format or standard interchange format is a good answer.

Preferred relevant interchange standards are:

• RIF/ReqIF (Requirement Interchange Format) to exchange requirements between requirement management or traceability tools • XMI (XML Metadata Interchange format) to exchange system models artifacts between SysML tools (with possible extension to other modeling and simulation tools) • ISO AP-233 (Application Protocol 233) to transmit system engineering descriptions to domains or disciplines Since the current level of maturity of these standards seems insufficient, confidence is put on short term improvements.

Lessons learned and perspectives

Boosting required cultural changes

As SysML method is implementing SE processes, it enables reinforcement of currently weak practices. For instance, deep understanding of the problem, before focusing on solution, is not currently natural and may be improved. The commonly used method to achieve external functional analysis APTE (APplication des Techniques d' Entreprise), may be improved as well. Moving to a use case driven approach taking into account interaction needs is a key improvement that SysML method naturally introduces but which may hurt current habits. New ability to perform quick iterations between levels and viewpoints may worry project managers, used to progress indicators related to sequential process.

Therefore, training engineers is a key point, but achieving a mindset breakthrough definitely requires functional and project managers to be committed.

SysML adoption by engineers

While a DSL tool strictly focuses on users' needs, SysML tools provide confusing features and GUI which are unneeded. Whereas a wide range of users from system, hardware, software, mechanics disciplines are targeted, ergonomics and user friendliness is an issue for non software disciplines. SysML tool customization is therefore a key factor of success. SysML profiles or simply GUI simplification are definitely mandatory. Different categories of users have been identified: • Experts, defining SE methodology and SysML implementation. They are in charge of method and tool customization and evolution • System leaders, having detailed understanding of implemented process. They are in charge of tailoring system modeling on a given project • Contributors, having skills to model diagrams related to specific system engineering tasks • Readers with reduced SysML knowledge, validating and verifying system description in the model For efficiency reasons, each user category should model using a relevant specialized GUI depending on its skill level and task to be performed. At the moment, standard SysML tools are used by experts and pilot users, in order to tune SysML method and underlying data model. Based on field return, tool customizations will be specified and implemented in order to ensure wide adoption and user efficiency.

SysML modeling as central enabling brick

ISO26262 compliance

Upcoming ISO26262 regulation will require a higher level of formalization and traceability. At the interface between system and safety development teams, sharing of a common reference architecture is a key enabler. This helps avoiding system / safety concepts inconsistencies during design iterations. Furthermore, what is expected is to share a common sound basis for both functional and dysfunctional studies and related simulations. While safety related effort will increase, automated safety analysis would help reduce costs impact. This topic is covered by an internal project extension named "SaIL" (Safety In the Loop).

Coupling to behavior simulation tools

A key topic is the strategy for system model verification and validation and particularly model simulation. For the time being, SysML does not seem to be able to propose major breakthrough improvements regarding simulation; this topic will require deeper study. The current adopted strategy is a close collaboration with tools such as Simulink or Statemate to be able to execute the system model (or part of it) in the simulation environment. Still, there are open questions regarding the artifacts to be transferred and whether this is the most efficient approach.

Coupling to AUTOSAR authoring tools

As commonly admitted and formalized in EAST ADL2, wherever system and software architectures are different, a tight coupling shall be ensured in between. The M2M (Model to Model) related transformation need to be addressed. For such topics, improvements of standard interchange format (XMI, AP-233 …) are expected solutions.

Conclusion

SysML offers a promising solution to implement automotive ontology and extend current modeling scope. A practical approach and first results are given in the area of embedded automotive Systems and products. However, further iterations and improvements will be necessary to work out a final efficient and seamless process. This paper does not claim any theoretical novelty. Neither does it claim to be on the leading edge of SysML modeling compared to other domains. However, it should enable sharing and collaboration with other industry experts, in charge of SysML implementation trade offs and facing similar issues regarding ergonomics and interfacing with simulation and safety analysis tools. It should help leverage synergies of cross-domain expertise and needs.

Figure 1 :

 1 Figure 1: Operational context diagram

Figure 2 :

 2 Figure 2: User modes state diagram

Figure 3 :

 3 Figure 3: Use case diagram (user level)

reqFigure 4 :

 4 Figure 4: Requirement traceability diagram

ibdFigure 5 :

 5 Figure 5: External interfaces description To specify the kind of admissible data flow, a type indication shall be associated with each port, using SysML item types or flow specifications. Several internal block diagrams are defined to describe the different contexts of use. Moreover, it is

Figure 6 :

 6 Figure 6: Scenario description (system level)

bddFigure 7 :

 7 Figure 7: System requirements as block properties

Figure 8 :

 8 Figure 8: Lowest level activity diagram describing system internal functions

  Figure 9: Logical architecture

  g. a set of components or component parts) capable of performing the internal functions required by the logical architecture. The key steps of this phase are: • Define relevant measures of effectiveness to identify candidate physical architectures to be investigated • Investigate the most promising candidate solutions, and for each one: o Define a physical architecture capable of performing the required functions o Allocate the logical functions to physical components o Develop and refine the components physical interfaces and interactions o Develop and refine the components requirements o

Figure 10 :

 10 Figure 10: Physical internal interfaces description

To avoid information overload on the same diagram, several internal block diagrams will be described, each diagram corresponding to a specific kind of interface (ex: mechanical, electrical, data processing buses,…).

Component interactions definition (SD)

The focus of black-box sequence diagrams described at system level was on the identification of the required sequences of system functions (operations). Because some physical components may require significant refinement to address discipline-specific concerns and fully specify the related requirements, it may be necessary to establish white-box sequence diagrams focused on the collaboration between the different components. The derivation of white-box sequence diagrams is performed by refining the system level related sequence diagrams and splitting the black-box system lifeline into as many lifelines as constitutive physical components. Moreover, a physical component may include a state machine as part of its specification, if it has significant state-based behavior.

Best physical architecture choice

Since there may be several competing hardware and/or software physical architectures that meet a given set of functional and performance requirements (e.g. the same logical architecture), several physical architecture alternatives may be investigated. The optimum physical design concept is selected based upon a set of measures of effectiveness (MoEs), that are weighted according to relative importance. The estimations of MoEs result from specific engineering analyses performed with appropriate tools such as modeling and simulation environments and with different analysis objectives (performance, robustness, safety, cost…). The results from engineering analyses are therefore not elaborated using the SysML tool but incorporated back into the system model as value properties attached to the upper level system block describing the corresponding physical alternative.

Component Requirements Specification

The physical architecture model results in the specification of the components to be implemented by each specific discipline (e.g. hardware, software, mechanics…). The component specifications are typically captured as blocks with the appropriate black-box specification features attached as operations, ports or properties. The black-box component specification also includes functional requirements derived from scenarios analysis, and performance properties whose values (measures of effectiveness) have been determined through engineering analysis and trade studies. The Component Needs Document (CND) describing the component requirements from the system designer point of view, is therefore automatically generated from the SysML model, through an extraction of all artifacts attached to the physical block under consideration.

Towards a systems development integrated environment

This chapter describes how the SysML system model must be supported by the development environment to provide an integrated framework for system development. A system development environment refers to the tools and repositories used for system engineering.

REQTIFY REQTIFY

Traceability results

Figure 12: Tools for an integrated systems development environment

Requirement management and traceability

The requirement traceability management activity is invoked throughout the whole system engineering process, to establish traceability between the stakeholder requirements, the system model artifacts, and the system and components specifications. The stakeholder requirements are typically captured in text specifications external to the SysML modeling environment. The SysML modeling tool provides a mechanism to import text requirements by creating mirroring requirements directly into the SysML model and to maintain synchronization between the source requirements


Miguel Ángel

Mozas Pajares

Carlos Murciano Díaz

Ismael Lafoz Pastor

Carlos Fernández De La Hoz

ICD Management (ICDM) tool for embedded systems on aircrafts

Keywords: ICD managenent, tool integration, requirement management

In the scope of on-board systems development and integration for aircrafts, ICDs (Interface Control Document/Description) are fundamental sources of information at same level that the functional requirements. ICD description must include feasible (bus capacity not exceeded, processing load under specific limits) and accurate (data precision, data retransmission rate, data consistency) inter-connectivity mechanisms, to support the application requirements needs, as well as the information must be easy to update and to maintain. On the other hand, DOORS (IBM) is a tool specialized on requirements management. It faces with aspects as traceability, version control, security (access control), changes control, data persistency and accessibility. DOORS is widely used and it is recognized as a reference tool in the scope of aeronautic developments. Nevertheless, ICD information usually is not managed with DOORS. The reason can be found in the specificities of the nature of ICD information, which suggests other approaches more suitable than DOORS. The alternative approaches are very diverse but most of them focus on handling information typified according to specific meta-models for ICD: databases, customized spreadsheets, and tabular descriptions. But whatever is the solution, it must address also, by its own means, the features of ICD derived of its "requirement nature". This paper presents a solution based on the integration of DOORS with a user front-end developed with Model Driven Architecture (MDA) and Open Source technologies. It is intended to provide means to manage ICD data in a robust way (guaranteeing the correctness -syntactic, completeness, non ambiguity-of data, changes, versions, dependencies, …) and additionally, to provide mechanisms to focus the effort on the data transformation rather than on the manual elaboration of derived artefacts.

1.2 Nature of ICD data ICD information is strongly typified. Practically any ICD description fits with one among a limited group of description pattern. For complex systems, the number of information elements which are associated with ICD is very high (hundred of thousands of items). Inside an organization involved in aircraft or systems development, it is quite usual to face with the need of reusing ICD information from one development to another, either exactly the same information or a variant of it.

As it has been said, ICD is a requirements source for Subsystems and Equipments. In the other side, ICD describes design decisions intended to satisfy upper level requirements. Therefore, ICD is deeply embedded in the requirements chain. Sometimes, ICD data have a high degree of volatility along the life cycle of the system development. ICD volatility acts like a multiplicative factor over the normal error tendency.

ICD data operation

The artefacts derived from the ICD information are strongly typified as well. The elements carrying out the transmission are typically in charge of the transmission and reception themselves, of the packaging and un-packaging of the information, and of the transformation of raw data to engineering units, as handled by the computer (transference syntax <-> local syntax). The construction of the test environment and the definition of test cases use exhaustively and systematically the ICD information.

Challenges and opportunities

Taken into account the characteristics mentioned previously, it is possible to identify important opportunities to optimise the efficiency in the management and the usage of ICD information. The early detection of errors in the phase of ICD definition avoids the propagation of those throughout the development process where, on the other hand, it is more difficult the detection and diagnosis of the problems. The origin of the problems can be of different nature: errors in the definition, inconsistency, incompletness, errors in the version control, errors in the control of changes or errors in the interpretation of the information, derived from the ambiguity in the expression of ICD definitions. Some of these causes can be controlled by means of classic procedures for change control, version control and traceability (requirement management). Nevertheless, the ability to avoid other problems depends on the capability to analyse the correctness of the ICD definition. Thus, the definition of a formal language (ICD metamodel), specialised for ICD description, appears like a fundamental tool to allow the definition precise and no ambiguous, of ICD. It is useful to facilitate the early verification of ICD, but also to analyse the implementation feasibility (load analysis), and to generate, systematically and automatically, the artefacts produced from the ICD. Taking into account the massive volume of information being involved, such automatic generation can suppose very significant savings in the development efforts. Moreover, the effective management of the ICD reusability allows saving important efforts on definition, development and verification.

Development environment/process extension

The purpose of the proposed approach is to achieve a powerful environment to manage ICD, by means of the integration of well-known, available and established tools, technologies and processes. The idea is to take advantage of the knowledge in ongoing practices and tools, and to extend it in a smooth and undisruptive way. In any case, we would like to emphasize the idea that having the appropriate language (formal), and the appropriated means, the artisanal way of developing ICD dependent products, can be substituted by a formalized practice that allows to improve drastically the efficiency, by providing powerful helps for correct ICD definition, and for the automatic creation of derived products (transformations). In fact, we are pointing the opportunity of introducing MDA on these scenarios.

ICDMS extension

Obviously, the current solution does not support all the possible ICD definition casuistry. Taken it into account, the development has been undertaken by applying an MDA approach, in order to be able to extend the ICDMS capabilities by working, basically, in the ICD meta-model extension.

Technology

The proposed solution is based on the integration of the following technologies and tools:  traceability … Why DOORS? We will not try to justify the use of DOORS as opposed to other alternatives in basis of its intrinsic features, but in fact, it is probably the most used tool for requirements management, in the scope of aeronautic systems development. The interconnection between DOORS and ICD-UI has been defined to keep them as uncoupled as possible, in order to allow the substitution of DOORS by another alternative product.

Eclipse

Eclipse is a multi-language software development environment comprising an IDE and an extensible plug-in system.

Eclipse Modelling Framework (EMF)

The EMF project is a modelling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, along with a set of adapter classes that enable viewing and commandbased editing of the model, and a basic editor EMF framework includes a meta-model (Ecore) for describing models and runtime support for the models including change notification, persistence support with default XMI serialization and a very efficient reflective API for manipulating EMF objects generically. The EMF code generation facility is capable of generating everything needed to build a complete editor for an EMF model. It includes a GUI from which generation options can be specified, and generators can be invoked. The generation facility supports regeneration of code while preserving user modifications.

Object Constraint Language (OCL)

OCL is a formal and declarative language that allows defining constraints any meta-model that cannot otherwise be expressed by diagrammatic notation. It is used to complement Ecore meta-model definition. It also allows defining model analysis algorithms, and elaborating object query (filter) expressions. These features are used for implementing the ICDMS "analysis" and "search" capabilities in a declarative -no programmatic-way, closely connected to ICD meta-model definition. In fact, when used for defining model constraints and model analysis algorithms, OCL expressions are part of the meta-model itself. ICDMS adds some useful features to standard OCL:  Applying to any object: is("type"): it returns true if the object type is "type". It is an alias for oclIsTypeOf  Applying to ICDObject: from(): it returns the set of entities that depend on it, parent(): it returns the parent of it (the object where it is defined in)

 Applying to string: match("expression"): it evaluates matching with regular expressions, toInteger(), toReal(), toLower(), toUpper(),.

 Applying to Real: abs(), exponential("power"), round(), floor().

 Applying to Integer: abs(), div(), mod() 2.5 Template engines A template engine is software or a software component that is designed to combine one or more templates with a data model to produce one or more result documents. A template processor is used in Template Oriented Programming. A result document is any kind of formatted output, including documents, web pages, or source code …

 Set bounds to error introduction

There are some circumstances that make a scenario more suitable to be managed with templates:

 A simple pattern for the solution can be found  The ratio between the effort to develop and run the template and the effort to develop the product is low or very low  The problem is typified  It is sure or foreseeable that the same mistake will appear many times

XMI/XSLT/XSL-FO

The XML Metadata Interchange (XMI) is an standard for exchanging metadata information via Extensible Mark-up Language (XML). It can be used for any metadata whose meta-model can be expressed in Meta-Object Facility (MOF).

The most common use of XMI is as an interchange format for UML models, although it can also be used for serialization of models of other languages. In fact, this is the format used by EMF editors to support data persistency for Ecore models. XSLT (XSL Transformations) is a declarative, XML-based language used for the transformation of XML documents into other XML documents.

For parsing XSL, we use MSXML with some jscript extensions to make easier the XSL template design.

XSLT is chosen for XML to XML transformations. XSL-FO is a facet of XSL, specialized in formatting XML data. It is chosen as a basis for ICD documentation generation.

Smarty

Smarty is a template engine for PHP. It is chosen for XML to no-XML transformations (source code …).

A special XML parser (written in XSL and PHP) has been developed to provide PHP input data to Smarty from XMI.

Altova® StyleVision®

It is an application for graphically designing and editing proprietary style-sheet (SPS) that can be used for generating XSLT style-sheets based on the SPS design (Both XSLT 1.0 and XSLT 2.0 are supported.). The XSLT style-sheets can be used outside StyleVision to transform XML documents into outputs such as HTML, PDF and RTF.

ICDMS Architecture

ICDMS comprises two complementary aspects: ICD data management and ICD data transformations. They are connected through the XMI representation of ICD data.

ICD data management

One of the key aspects of this -open source basedsolution is the integration with DOORS. Anyway, the mechanisms to connect and to synchronize the front-end with DOORS have been designed to guarantee the robustness of session protocol.

ICD User interface (ICD-UI)

The front-end application (ICD-UI) has been developed with EMF, based on the Ecore metamodel and OCL analysis, following principles MDA.

The manual implementation of ICD-UI features has been undertaken by means of generic programming techniques (EMF reflective API) and user preserving sections in order to be as independent as possible from the details of the meta-model and the consequent EMF automatic code generation.

The programming language is Java. Available Eclipse plug-ins have been considered, and used when appropriate.

ICD Meta-model

For the elaboration of ICD meta-model, previous knowledge of traditional ICD tools (ALBATROS, EPT-ICD, eICD …) have been taken into account.

The structural aspects of the meta-model for ICD (entities, attributes, relationships, cardinalities …) are written in Ecore, and they are mostly based on the entity-relationship paradigm. Additionally, the specializations are described by means of inheritance relationships, following an objectoriented approach.

The top-level container entity is the Module that represents the unit of information under configuration control. A module can depend on another for its definition, but the dependency cannot be circular.

There is a section for generic ICD information and others for the description of specific aspects of different types of communications. Inside the generic section, there are element intended to describe data layout (message, signals ...), data scaling and communication architecture (systems, subsystems and networks).

The specifics sections refine the definitions made on the generic one, using an extension mechanism based on inheritance relationships.

Entity-Relationship paradigm

Entity-Relationship model is used to define ICD meta-model in order to enable normalised and flexible ICD descriptions that avoid the redundancy and facilitate the reuse.

Entity

This class is the base for any entity defined in the meta-model. An entity is the representation of a concept, defined by its attributes, which represents the inherent characteristics of the element, those that it has derived from its own nature. An entity has independent existence and is uniquely identifiable.

Relationship

A relationship is the representation of a unidirectional tie between two entities. The relationship defines attributes that only exist as features of the relationship, so such attributes are not inherent to the related entities.

A relation can be solved by reference or by containment (that is called in-site declaration).

In the first case, the referenced element is defined in some other part of the model. The reference "with" (not containment) of the specialized relationship is used.

In the second case, the referenced element is defined inside the relationship. This is useful, and facilitates the management of the model, when the referenced element is only relevant for the entity that references him. The reference "owns" (containment) of the specialized relationship is used.

Data Layout

A Structured class represents a data layout definition composed by a set of lower level information elements arranged over a bit stream. For each component, the start bit and the cardinality (in the case of a fixed length array of elements) is specified.

The Message is the highest level of data layout definition.

The Signal is the lowest level of data layout definition. This element carries the information. Figure 12: ICD meta-model. System

Specific packages

There are packages that include the specificities of concrete types of ICD. Following is the list of ICD supported so far:

 ARINC 429,  MIL-STD 1553,  AFDX,  ARINC 653,  Ethernet
 Analogue and Discrete signals.

ICD-UI features

ICD-UI provides user with access to all ICDMS features. It means that user does not need work directly with DOORS user interface. User friendliness tries to be one of the main strengths of ICDMS. Because of that, we have put extreme care to develop an user graphical interface intuitive, easy to use, and familiar for most of the addressed users, avoiding heavy procedures based on series of forms. Instead, we have chosen an interface based on trees and tabular windows, that provides mechanisms for fast edition (short-cut, copy-paste, drag-drop) and ICD data overview.

Browser pane

 This element (the top-right one) contains two tabs: the proper ICD Browser window,  and a Progress View window. The first element in the ICD Browser window is the tree of entities inside the selected ICD module. Each tree node can be expanded or collapsed. The selected module is the selected one in the Views pane (the left one). Furthermore, all modules on which the selected one depends, either directly or indirectly, are showed by means of additional trees. The Progress View window shows the execution status of tasks that are running in background.

Properties pane

This element contains the proper Properties window (on the bottom right), and sometimes, other optional windows (Console). The Properties pane gives access to the value of the attributes of the selected element for edition. The "Selected element" is the last one that has been selected either in ICD Browser or in Views pane.

Views pane

This element contains several tabs. Two of them (General and Message) have a common behaviour on configuration capabilities. Since both are based on a tabular window, where rows represent a set of elements, and columns represent the element properties, both take advantage of the same filtering and ordering features. There is a status line, on the top of Views pane, intended to show some information related with the active Module like write permission, synchronization with Database status or Control Configuration data (Baseline identification).

Search view

This is a complex view, composed of two parts:  a query console and  a search result window. The search result window is a tree-table window that shows the findings of the last query. It allows inspecting both the backwards and forward dependencies of found items.

Information view

This element is intended to log the results of checking and analysis of ICD. It is a reactive window that allows to select in the Browser the entity affected by each information entry just clicking on it.

Problem view

This element is intended to show any kind of error reports. It is opened automatically when a problem occurs while loading a model.

ICDMS Features

Module management

Modularity is a fundamental aspect of ICD description that affects the performance of the deployment (size of DOORS formal modules affects the operation response time) and mainly on the reusability. It has been carefully taken into account in the meta-model design. A Module is an information assembly that is a configuration control unit (see ICD meta-model description). Each Module under configuration control ("controlled") is stored in a corresponding DOORS Formal Module. Besides, either "controlled" or not, all Module are stored in a XMI file (EMF feature). It is possible to build a secure XMI file (controlled files) for controlled Modules. These files include a checksum that allows detecting undesirable changes in the content. These files are useful to sharing ICD information without the need of using DOORS. Obviously, controlled files are not suitable for ICD edition.

Module dependencies

ICD Meta-model defines how ICD can be described by means of a set of related modules. Each Module can depend (always explicitly) on other controlled modules, but circular dependencies are forbidden. Each referenced module is loaded automatically as a resource (additional tree into the Browser Window). A frozen version of a module (baseline) cannot depend on a no frozen one. There cannot be dependencies between elements into Modules that are not directly dependent. A Module dependency cannot be destroyed while there is some relationship between their elements.

Load a Module

It is possible to load controlled or uncontrolled Modules (Open / Open checked module). A controlled Module can be loaded either from Database of from a controlled file. When loading a Module from Database, It can be selected a Baseline version or the "current" one (the last working version, not frozen).

ICD edition

Write permission

When working with an uncontrolled Module, the permissions are the same as for the underlying XMI file. The user can manage it with file system. In that case, ICDMS is not responsible about concurrent edition. When working with a controlled file, it is forbidden to modify it. Anyway, the user could do it changing the XMI file properties, but the file would lose its "unmodified" condition so, it will not be any more a correct controlled file.

When working with a controlled Module from Database, The menu option (lock/unlock) can be used to switch the write permissions. Only one user each time is granted with writing rights. This mechanism, coordinated with DOORS, prevents form collisions while editing a module. 6.2.2 Create Element All the elements belong to a containment hierarchy that starts with a Module element. A new element can only be created below an existing one. The creation of a new element is done by calling the "New Child" or "New Sibling" options of the contextual menu whereas the parent or sibling entity is currently selected. With respect to the selected element, only the adequate types of element, according to ICD Metamodel, can be created. It must be taken into account that other constraints not defined in Ecore meta-model, but in OCL constraints definition, can apply, but these are not controlled during the creation phase.

Modify Properties

The attributes of the selected element can be read and modified in the Properties Pane. Some of the constraints for the attribute values are declared in the Ecore Meta-model definition and are managed by the Properties Pane. The "with" attribute of relationships is quite special. It represents the relation with another existing entity. When "with" attribute is selected for change, the Property Pane provides a list with all the entities suitable to be selected, extracted from the own Module and from the Modules on which it depends directly. Alternatively, the related entity can be dragged and dropped over the relationship.

Delete Element

When deleting a reference to an entity, the referenced entity is not deleted. When deleting an entity, the references to the entity are also deleted. The user is not warned when deleting a referenced entity, nevertheless, that condition is shown by means of a colour code for the nodes in the Browser view tree.

Copy or Clone

Strictly speaking, no copies of element can be done, because the element identifier value must be unique. So copies become on a clone action. A new element with different identifier but with similar characteristics is created. There are two procedures to clone an element:  Copy the element and paste it in the desired/allowed location  Drag and drop (while pressing Control key) to the desired/allowed location Note that when dragging and dropping an entity to a relationship, the entity is not cloned, but a reference is created inside the target relationship.

Configuration control

Configuration control is delegated to DOORS. It is possible to request all the actions related with this feature from ICD-UI.

Create Module in Data Base

The uncontrolled Module loaded will be introduced into the Database. A new DOORS formal module will be created in the specified path, with the same name as the Module and with equivalent contents.

Create Baseline

This action allows creating a DOORS baseline for a module. It is possible to define a suffix for the baseline tag and to introduce a comment.

Create Controlled File

This action allows creating a controlled file from the loaded Module.

Change tracking

We have decided not to use DOORS-CPS for change management directly, because its working way does not match with the problematic of ICD change. Nevertheless, change tracking is based on module and object history DOORS features, complemented with some extensions to manage change request identifiers. It is assumed that the management of change control (proposals, discussion, planning ...) is done outside ICDMS. Once a change has been planned and so, it must be implemented, the affected controlled Module must be loaded and unlocked. For each identified change, a change session will be opened. The menu option Change Request (init-end) can be used to switch change request session status (opened-closed). The user is invited to introduce the change request identifier (free format). All changes made in the module from this moment until the session is closed, are stored in the History of DOORS, associated to the change request identifier. The change session can be aborted at anytime. In that case, all the ongoing modifications will be cancelled. Each time a change session is closed, the changes are stored in the Database and a comment, associated to the change request session, can be introduced.

ICD Verification

All the constraints that apply to ICD data are defined formally either in the ICD meta-model, or in the associated constraints (OCL) file. There are three different verification points, where different checks are performed :  loading the model,  running "Validate" command The first verification of ICD model is done when it is loaded.

A check about correctness of the loaded file (XMI) is performed against the XML schema that has been derived form the ICD meta-model. If there is any problem, the model is loaded incompletely, and the problems messages are shown in the Problems View. This kind of problems should not happen frequently because they are due to a bad file construction. Nevertheless, it can be common while tuning procedures to import external data into ICDMS. Some ICD model constraints derived from ICD metamodel are not reflected in the associated XML schema so, they cannot be detected when loading the model, and cannot be automatically avoided while editing the model. These validations must be requested explicitly, and the result is shown in the Information View.

ICD Analysis

It is possible to do some automatic analysis over ICD data. This analysis is intended to provide useful information for the system/ICD designer. The information provided is of the following nature:  Transmission load of physical resources  Process load of equipments/subsystems  Growth capability (message addressing, payload, processing, transmission, connectivity ...) …

The analysis must be requested explicitly, and the result is shown in the Information View.

Impact analysis

Additionally to the automatic load analysis, it is possible to undertake the impact analysis with the help of ICDMS.

There are two main ways to do that at different level of detail:

 By inspection of inter-Module dependencies  By using the capabilities of Search Window For the finest dependency analysis, first select in the Search Window, the entities under inspection. Then select "reverse" mode to get the set of entities dependent on those.

Queries

It is possible to make sophisticated queries over ICD model data. The result of such queries is showed in "Search View" window. The syntax to build the queries is OCL. It is recommended to get a good knowledge on it. Moreover, it is encouraged to get a good knowledge about the ICD meta-model to build the queries.  Flight test instrumentation configuration Nevertheless, probably the list is not complete and other suitable transformations can be found (e.g. bus analyzer configuration).

ICD documentation

The documentation of ICD data for publishing is produced as the result of an special ICD data transformation, where the input is the ICD model (XMI), an the template is written in XSL-FO. Because of the difficulties of writing XSL-FO transformations for complex document formats, we have considered the convenience of using a complementary tool to support that task. After a light assessment of ALTOVA StyleVision and TOPCASE GenDoc, we have chosen the first one because of his greater maturity.

Return of experience

The Pilot cases successfully using this ICDMS are:

Conclusion

In this paper, we have presented the current state of the ICDMS. It should be stressed that many design decisions have been made based on previous usage of ICD tools in the area of data structure. The innovating issues are based on incorporating new approaches (MDA) and mature tools like DOORS, Eclipse, EMF, Ecore, XML, XSLT, MOF, OCL, … Those have provided features like: tool construction from a meta model, GUI interface in tabular format including edition, check and search features based on OCL, ICDs handling in the same way as requirements (traceability and impact analysis), reuse of ICDs to deal with the product line topic, data model loosely coupled to the output data transformations, templater based approach for transformations. These features provide a highly scalable and configurable tool to specific domains even different than the aeronautical. A future extension of the capabilities of this platform could be the integration with UML design capabilities (already available on Eclipse/TOPCASED) to complement the ICD static description with protocol information, described in terms of state-machine, and using ICD data (messages) as protocol data units.

Acknowledgement

Special thanks to the EADS Research & Technology network (GIN4 -RTG14) by its contribution inside the OBSYS demonstrator, the technology room where the ICDMS grew up. Also mention this work was supported by active participation of the AIRBUS Military organisation by providing a lot of comments to improve the tool. In addition, we wish to acknowledge our colleagues in the EADS' Military Aircraft Systems who encourage us to extend the ICDMS capabilities.

  (ICDMS) is an infrastructure aimed to manage the edition, the publication and the operation of ICD data in an error free, controlled and efficient manner. The main features are:  ICD edition  ICD data verification  ICD data analysis  ICD data transformation  ICD documentation  Master repository  Access control  Configuration and change control  Traceability  Reuse management 1.1 ICD into the Aircraft Development Life-cycle ICD is a key piece of system definition and system development. Its relevance comes from the role it plays in the different phases of the development process: ICD data is a requirement for the Equipment (Software and Hardware) under development. Additionally, it can be used as an input for definition of Integration test, for definition of Equipment/Software test, and for testing (Test Bench configuration, including bus analyzers and Flight Test instrumentation).

Figure 1 :

 1 Figure 1: Impact of ICD in the development life-cycle Because of its position in the development chain, errors or misunderstandings on ICD impact widely along the development process. The early detection

2. 1

 1 DOORS DOORS 8.2 is used as Master repository with Requirements Management capabilities  Access control,  user management,  change/version Management,

Figure 2 :

 2 Figure 2: Template engine

Figure 3 :

 3 Figure 3: ICDMS Architecture. Data Management

Figure 4 :

 4 Figure 4: Data transference. ICD-UI <=> DOORS

Figure 5 :

 5 Figure 5: ICD-UI Building 3.2 ICD data transformationsThe nature of ICD (massive and strongly typified information) and of its usage (many and heterogeneous users -system/software development, test benches configuration, onground/flight tests-; and reduced number of transformation patterns) makes it very suitable to be managed by means of automatic transformations, that allow to put the effort on the design of generic and reusable patterns. The template engines used so far are MSXSL for XML to XML transformations (XSLT), and Smarty for others.

Figure 6 :

 6 Figure 6: ICDMS Architecture. Transformations

Figure 7 :

 7 Figure 7: ICD meta-model. Data layout definition

Figure 8 :

 8 Figure 8: ICD meta-model. Alternative data

Figure 10 :

 10 Figure 10: ICD meta-model. Complex scaling

Figure 11 :

 11 Figure 11: ICD meta-model. Network

6. 9

 9 ICD data transformations So far, we have exercised transformation for a series of derived products:  Source code for Input/Output (C++ and Ada)  Test bench (SEAS) configuration files (XML)  Source code for Test case stimulus/acquisition implementation (Ada)  ICD documentation (HTML)



  the Aircraft Management Information System of the A330-MRTT for the Ethernet data bus interconnection in the code generation and the test benches configuration, and  the Boom Control and Computing System and the Multi-Function and Control Display of the ARBS in ARINC-429, CANbus, MIL-STD-1553, Analog and Discrete signals, for the code generation, the test benches configuration, and flight tests.