Sébastien Valette
email: sebastien.valette@creatis.insa-lyon.fr

Yun-Sang Kim
email: yun-sang.kim@creatis.insa-lyon.fr

Ho-Youl Jung

Isabelle Magnin

Rémy Prost
email: remy.prost@creatis.insa-lyon.fr

A multiresolution wavelet scheme for irregularly subdivided 3D triangular mesh

We propose a new subdivision scheme derived from the Lounsbery's regular 1:4 face split, allowing multiresolution analysis of irregularly subdivided triangular meshes by the wavelet transforms. Some experimental results on real medical meshes prove the efficiency of this approach in multiresolution schemes. In addition we show the effectiveness of the proposed algorithm for lossless compression.

Introduction

Multiresolution analysis of 3D objects is receiving a lot of attention nowadays, due to the practical interest of 3D modelling in a wider and wider range of applications. Multiresolution analysis of these objects gives some useful features : several levels of details can be built for these objects, accelerating the rendering when there is no need for sharp details, and allowing progressive transmission. Another feature is that multiresolution analysis can be an efficient way for data compression. A survey of the existing methods used to simplify meshes which is the first step for processing multiresolution analysis, like vertex decimation [START_REF] Soucy | Multiresolution surface modeling based on hierarchical triangulation[END_REF], edge contraction [START_REF] Hoppe | Progressive meshes[END_REF] and wavelet surfaces [START_REF] Lounsbery | Multiresolution Analysis for Surfaces of Arbitrary Topological Type[END_REF], was reported in [START_REF] Heckbert | Survey of polygonal surface simplification algorithms[END_REF]. We put our attention on the third method, because wavelets are wellsuited for multiresolution analysis. In section 2, we will shortly explain multiresolution analysis of meshes [START_REF] Hoppe | Progressive meshes[END_REF], and show its drawbacks in practical implementation, which we improved, as described in section 3. In section 4, we show why our proposal is suitable for compression. The next part (section 5) gives the results obtained with this new scheme.

Lounsbery's wavelets based multiresolution scheme

In wavelets decomposition, a mesh (for example a tetrahedron, see figure 1.a) is quaternary subdivided (figure 1.b) and deformed (figure 1.c), to make it fit the surface to approximate. Subdividing the mesh consists in splitting each triangular face into four faces. These steps can be processed depending on the required resolution levels. Multiresolution analysis is computed with two analysis filters A j and B j for each resolution level j. Reconstruction is done with two synthesis filters P j and Q j . These filters are represented with matrix notation and, to ensure exact reconstruction, must satisfy the following constraint:

[ ]

A B P Q j j j j       = -1 (1)
Let us call C i the N(j)x3 matrix giving the coordinates of each vertex of the mesh at the resolution level j. Then we have the relations:

C j =A j+1 .C i+1 (2) D j =B j+1 .C j+1
(3) C j+1 = P j .C j +Q j .D j (4) D j represents the wavelet coefficients of the mesh, necessary to reconstruct C j+1 from C j . From a theoretical point of view, each column of the P j matrix (respectively the Q j matrix) represents a scaling function (respectively a wavelet function). These functions are defined on a 3D space fixed by the mesh topology.

We apply the lifting scheme [START_REF] Wim | The Lifting Scheme : A Custom-Design Construction of Biorthogonal Wavelets[END_REF] which consists here in constructing wavelet functions (starting from the hat function, figure 2.a) orthogonal to the scaling functions (which are hat functions too, but with a twice wider support). Without the lifting scheme, Lounsbery's multiresolution analysis would simply consist in subsampling the mesh, but with the lifting, the mesh at resolution level j is ensured to be the best approximation in the mean square sense for the mesh at level j+1. The main material for the lifting is the inner product between two functions defined by Lounsbery as:

∑ ∫ ∆ ∈ ∈         >= < ) ( ). ( ). ( ) ( , M s j ds s g s f area K g f τ τ τ (5)
∆(M) is the set of triangles τ of the mesh and K j is a constant for a given resolution level j. (K j =4 -j ). Note that in this inner product it is assumed that the triangular faces of the mesh have the same area. The consequence of this assumption is that a mesh at resolution level j will effectively be the best approximation of the mesh at level j+1 only if this constraint is fulfilled. We can see in figure Wavelet surfaces give a powerful tool for multiresolution analysis. However, in the simplification process, the major drawback is that faces are always merged four to one to have a simpler mesh. If the mesh does not respect this connectivity constraint, one has to process a resampling of the mesh, which results in a mesh having more faces than the original, as explained in details in [START_REF] Eck | Multiresolution Analysis of Arbitrary Meshes[END_REF]. The aim of this work is to solve this problem by improving the subdivision process, as described in the next section.

A proposal for irregular subdivision

In the proposed scheme, the subdivision process is changed : each face of the mesh to subdivide is no more systematically split into four faces, but can also be split into three or two faces or remain unchanged. As an example, four different cases of subdivision are shown in figure 3. This approach allows to simplify meshes even if some faces cannot be merged four to one. The simplification is done with an algorithm that merges the faces of a mesh, considering rules established by the subdivision process. Figure 4 shows an example, where 15 faces are reduced to 6, resulting from merging 4 :1 faces for G2, 3 :1 faces for G3 and G6, 2 :1 faces for G1 and G4 and keeping one face unchanged for G5. One important consequence of the simplification rules is that a vertex can be removed during the simplification process only if its valence is equal to 4, 5 or 6. Clearly the efficiency of our algorithm depends on the number of removable vertices in the mesh. Fortunately, meshes usually have such vertices, and during the simplification, the valence of the vertices tends to decrease. As an example, the vertex V1 shown in figure 4 has a valence of 7, which makes it impossible to remove, but after one simplification step, its valence is reduced to 5, and the algorithm will be able to remove it in a further step.

Briefly, the simplification algorithm starts by merging 4 faces to 1, building a set of merged faces, and tries to expand this set by merging faces around it. Figure 5 shows the beginning of the expansion of the merged faces set (in gray), merging sequentially 4:1 faces, 3:1 faces and 2:1 faces.

Figure 5: expansion of the simplified mesh set

V1 V1 b) a) c) d)
The algorithm stops when no more faces have to be simplified. In order to prevent the algorithm from being unable to simplify some faces with respect to the subdivision rules, a modification of the mesh is allowed. It consists in an edge permutation between two neighbour faces, as shown in figure 6. Of course this modification has to be stored, to recover the original mesh after subdivision and guarantee the reversibility of the simplification process. We notice that this modification will introduce a quality loss during multiresolution analysis, but the difference between the original mesh and the altered mesh is small and experimental results show that this local error is negligible compared to the approximation error. Finally, the algorithm is very efficient for simplifying a large set of meshes.

The last thing to do is to compute the approximation of the high resolution mesh with the simplified one that is to calculate the analysis filters A j and B j . This can be done with Lounsbery's scheme. A difference has to be noticed, due to the change of the subdivision process. The inner product (5) has to be reformulated and becomes:

∑ ∫ ∆ ∈ ∈         >= < ) ( ). ( ). ( ) ( ) ( , M s j ds s g s f area K g f τ τ τ τ (6)
K j (τ) is no longer a constant and changes with each face of the mesh. For example, a face in a low resolution mesh that will split in 3 faces will have K j (τ)=3 and the three resulting faces will have K j+1 (τ)=1, taking into account the differences between the triangle areas : the first face cited above will approximately be three times larger than the three last.

Compression

The proposed method has powerful features for compressing meshes, for two reasons:

• The wavelet decomposition, used to compute the vertices coordinates, transforms coordinates into wavelet coefficients which histogram is concentrated around the value, making them well suited for entropy coding.

• Starting from the lowest resolution level, there is no need to store or transmit the faces descriptions to reconstruct higher levels, only the subdivisions have to be, which lets the amount of information needed to reconstruct the connectivity of the mesh close to 3 bits per face. In the experimental results section, the lowest resolution mesh is coded using the algorithm described in [START_REF] Taubin | Geometric compression Through Topological Surgery[END_REF].

Results

Table 1 shows the results on a heart mesh simplification using the proposed method. The high resolution mesh is a regular tesselation similar to that proposed in [START_REF] Lotjonen | A triangulation method of an arbitrary point set for biomagnetic problem[END_REF]. Its vertices coordinates are coded with a 7 bits/vertex precision. The number of bytes noted in table 1 is the amount of information needed to reconstruct the mesh to the concerned resolution level starting from the nearest lower resolution level.

Table 2 gives some more results on different 3D meshes: brain, body and lung. We notice that at the middle resolution levels, used in practical implementation, the approximation quality remains rather good in terms of local shape and size.

Conclusion

We proposed a new scheme allowing to process multiresolution analysis on arbitrary meshes. In sharp contrast with [START_REF] Lounsbery | Multiresolution Analysis for Surfaces of Arbitrary Topological Type[END_REF] where a resampling of the original mesh is necessary, our scheme processes directly on the original mesh. The proposed method has many potential applications such as mesh compression, progressive transmission and fast rendering of 3D images.

Figure 1

 1 Figure 1: the subdivision scheme

  2.b) the effects of the lifting scheme on the hat function showed in figure 2.a).

Figure 2 :

 2 Figure 2: wavelets in 3D

Figure 3 :

 3 Figure 3: some possible cases of subdivision

Figure 4

 4 Figure 4: an example of surface simplification

Figure 6 :

 6 Figure 6: an edge permutation between two faces

Table 1 :

 1

	multiresolution representation of a 3D left
		ventricle of a heart mesh
	Level 6	Level 5	Level 4
	1008 faces	446 faces	208 faces
	413 bytes	226 bytes	123 bytes
	Level 3	Level 2	Level 1
	94 faces 65 bytes	46 faces 36 bytes	22 faces 22 bytes
	Level 0
		Summary:
		Original file: 4730 bytes
		Compressed files: 925 bytes
		Ratio : 5.1 : 1
	8 faces
	40 bytes

Table 2 :

 2

		complementary results
	Original mesh	Level 4	Original file:
			19493 bytes
			Compressed
			file:
			3246 bytes
	3584 faces 8 levels	524 faces	Ratio: 6.1 : 1
	Original mesh	Level 5	Original file :
			25894 bytes
			Compressed
			file:
			4062 bytes
	4454 faces 10 levels	306 faces	Ratio : 6.4 : 1
	Original mesh	Level 5	Original file:
			9705 bytes
			Compressed
			file :
			1801 bytes
	1916 faces 10 levels	168 faces	Ratio : 5.4 : 1

Acknowledgments:

The authors are grateful to Prof. E. Rittman and R. Robb for providing the 3D x-ray angiographic data, and J. Lotjonen for building the meshes. This work is in the scope of the scientific topics of the GdR-PRC ISIS research group of the French National Center for Scientific research.


Damien Chabrol

Vincent David

Patrice Oudin

Gilles Zeppa

Mathieu Jan

Freedom from interference among time-triggered and angle-triggered tasks: a powertrain case study

Over the last years, the amount of software integrated in products like cars, planes, or trains has considerably grown in order to get more intelligent, more open and more communicating embedded systems. Due to this trend, the ability to manage the software complexity while respecting the safety constraints is now key for competitiveness in industrial domains such as automotive, aeronautic or railway.

To achieve this challenge, the real-time kernel plays a major role. Unfortunately the current technologies proposed by the market are handicapped by programming models with poor or nonexistent temporal semantics. This weakness is a really blocking point to keep under control the cost and the time-tomarket of safety-related and always more complex embedded systems.

To address these issues, KRONO-SAFE has extended its real-time kernel, called KRON-OS, in order to support an innovative programming model enabling to mix periodic and aperiodic real-time references while guaranteeing the freedom from interference among treatments and the determinism of system behavior on single-core and multi-core processors.

Introduction

Embedded systems are becoming widely present in all our daily products. This means more and more embedded software; Software is bringing many product innovations in order to achieve scalability, flexibility, connectivity, maintenance and management: the final value of a product is now largely based on its embedded software. Control of software technologies for embedded systems becomes a key asset for competitiveness. In addition, the boundaries between the "critical" systems and "comfort" vanish. By comfort system, we can consider: intelligent home, consumer electronics, e-health, digital city the smart-grid, and more. By "critical" systems, we mean aeronautics, railway, automotive and part of energy. In the world of critical applications, this trend has two impacts:

-Time to market pressure becomes higher, but certification requirements are not relaxed. Product development cycle and maintenance processes must be reviewed in order to achieve fast and safe results. -Several industrials can participate to the realization of a product (with different critical levels). The most critical parts of the applications must not be impacted by any malfunction of a non-critical function.

The industry requires compliance to safety certifications on single-core but not also on multi-cores platforms. In addition, it is now necessary to get the possibility to make the product evolve during its lifetime (offering additional functionalities typically).

The key element to control both the time-to-market and coexistence of critical and non-critical functions on a device is the real-time kernel (called also Real-Time Operating System and noted RTOS) which allows the share of hardware resources in a safe and effective manner. The technology evolution that needs the industry to perform a new revolution requires solving the current difficulties of RTOS. Indeed, "timing behavior in RTOSs is coarse and becomes increasingly uncontrollable as the complexity of the system increases" as said Professor Edward A. Lee [1].

Specifically for hard real-time systems, the tasks are often modeled as periodic activities which lead to the realization of multi-tasking systems based on fixed policy priorities [2] [3]. Nevertheless, this approach is absolutely not flexible. Typically the implementation of functions that are not periodic is complex and inefficient. The task will be activated even if no functional processing has to be done leading to unnecessary load of the system. If the system function behavior can change within a certain range, then its model becomes even more complex and the overall system efficiency is drastically reduced. In other words, although such systems are deployed industrially, their execution and programming models are too simple to be used in safety context because the confidence in the system is mainly based on analysis without guarantee.

Other approaches provide more flexible task model for describing the real-time tasks as a temporal activities of sequences [4] [5], a task being then represented as a graph of processing's with time constraints [6], which can even be data-dependent. When high flexibility and performance are required, a dynamic scheduling approach is necessary to optimally use execution resources. Besides, formal schedulability analysis can be performed to demonstrate the timeliness property of a system [4]. The drawback is that the number of preemption points for each task can become quite complex to evaluate. Besides, some application domains require systems to be built without temporal interference among their real-time tasks. This requirement for a "freedom from temporal interference" among real-time tasks therefore favors the use of static scheduling instead of dynamic scheduling approach [7] [8].

Current RTOS provide a set of services through an interface (called API) without proposing execution model to ensure a safe and efficient resource sharing mechanisms. It is then up to the developers through the offered programming model to design correctly the software architecture. Managing how the system should behave becomes a very hard task for the developer. It is very difficult to avoid errors and in particular at temporal level due to the numerous conversions between logical and real temporal units.

So, industrials need a new kind of solution in order to address performance, safety and flexibility together with time-to-market constraints. Performance refers to CPU and memory resources usage which should be consumed efficiently in order to avoid oversizing of hardware resource. Safety refers to compliance with safety standards thanks to determinism, noninterference, fault tolerance mechanisms completed by some proofs (sizing, execution) to build the confidence in the system. Flexibility refers to ability for the users to create, update, modify, extend, and reuse components with the help of tools that automatize complex and risked development phases.

This paper deals with the new paradigm included to KRON-OS which generalizes the Time-Triggered (TT) approach to external events, and which was briefly presented in [9]. The triggering of tasks can be linked to the occurrence of events from the controlled system, in addition to the classical physical time scale of the TT paradigm. Moreover, we present how this paradigm can be deployed in a safety context where deterministic behaviors, where output values will be unique for a same set of input values, and noninterference among functions shall be ensured. To target this requirement, KRON-OS helps to build more reliable real-time systems based on a flexible task model with a scheduling that relies on a static approach in order to master the freedom from interferences among tasks.

This paper is organized as follows: Section 2 describes the related work in the design of task and computational models that target hard real-time system. Section 3 then presents the KRON-OS solution, while section 4 describes its provided TIME-triggered paradigm. Section 5 shows its use on the DELPHI DIESEL SYSTEM powertrain use case. Finally, section 6 concludes and gives some perspectives.

Related works

In the event-trigger computational model, no constraints are applied on top of the periodic task model: tasks may perform I/O at any time when they are scheduled. This is what is classically found in TT approaches, such as in [10]. [START_REF] David | Safety properties ensured by the OASIS model for safety critical real-time systems[END_REF] introduces a flavor of the TT paradigm, which also let tasks perform I/O at any time when they are scheduled. The recurrent realtime tasks are statically represented as flexible cyclic graphs [START_REF] Lemerre | An introduction to time-constrained automata[END_REF], allowing any temporal triggering to be specified. The temporal constraints of a task can therefore be chosen depending on the result of an application-level condition. A dynamic scheduling of the chosen execution paths is performed. However, in both cases within multitasking systems this leads to I/O latency and jitter. The periodic control demand of the I/O operations [START_REF] Arzen | An introduction to control and scheduling co-design[END_REF] is therefore violated, resulting in a degradation of the control performance [START_REF] Wittenmark | Timing problems in real-time control systems[END_REF]. Besides, tasks may release useless jobs, from the control point of view, wasting resources. [START_REF] Henzinger | From control models to real-time code using Giotto[END_REF] is also a TT programming language and introduces the concept of Logical Execution Time (LET). It provides a programming abstraction for hard realtime applications which exhibit (only) time-periodic and multi-modal behavior. The reading of inputs is performed in logically zero time before the activation date of tasks, but in practice through hardware interrupts. This is called the one-sample computation model or the synchronized I/O computational model, as output is generated at the deadlines. A constant I/O latency of one sampling period is achieved. However, this reduces the schedulability of the system due to I/O interrupt handlers' execution.

GIOTTO [5]

In [START_REF] Lozoya | The one-shot task model for robust real-time embedded control systems[END_REF], the so-called one-shot task model is introduced. Sampling is done when the tasks start to be executed. However, outputs operations are performed only at the deadlines of tasks. Compared to the one-sample computation model, the number of interrupts handlers is reduced by half. In the worst-case, I/O latency is one sample but is generally lower, allowing faster reactions to perturbations. Finally, latency jitters are eliminated as the actuation is always done at job deadlines. In [START_REF] Cervin | The control server: a computational model for real-time control tasks[END_REF], another proposal for reducing the jitters consists in limiting the time interval where control jobs can execute. The control tasks is divided into a calculate output task and an update state task, whose deadlines are assigned through an off-line evaluation. In [START_REF] Albertos | Rt control scheduling to reduce control performance degrading[END_REF] and [START_REF] Balbastre | A task model to reduce control delays[END_REF], tasks are also divided into several subtasks: sampling, control and actuation. While limiting the jitters, the system schedulability is reduced because subtasks are forced to execute within shorter time intervals. In [START_REF] Buttazzo | Elastic scheduling for flexible workload management[END_REF], a task model is proposed which allow periodicity of task to be modified in order to optimize their values according to the current utilization of the system. In [START_REF] Velasco | The self triggered task model for real-time control systems[END_REF], a task model is also presented in order to jointly optimize the used computing resources and the control performance. The proposed tasks model allows each control task to trigger itself: the timing constraints are dynamically adjusted depending whether the controlled system is stable or subject to perturbations. To the best of our knowledge, xGIOTTO [START_REF] Sanvido | xGiotto language report[END_REF] [23] is our closest work. It is an extension of GIOTTO which can also deals with asynchronous events, in addition to the TT paradigm. Through a mechanism called event scoping, activities can start either due to physical timing constraints or on the occurrence of an external event. However, the synchronized I/O computational model, and its limited schedulability capability, still applies. Besides, the end of an activity must still be specified in physical time preventing the capability to define an (application specific) time scale for deadlines different than physical time. In addition, a delay exists between the occurrence of an event and the first activation instant of a related task since tasks being executed must first terminates.

KRON-OS : TIME-triggered paradigm

To address these needs for the design of nextgeneration real-time systems, KRONO-SAFE brings an innovative real-time kernel called KRON-OS. KRON-OS is a methodology for the design and the implementation of embedded real-time multitasking systems. In order to have a safe execution, KRON-OS helps the application designer to have a "correct by construction" real-time system. In order to achieve this, the execution support is totally abstracted from the developer's point of view and relies on a rigorous execution control concept including resources sharing (CPU, memory, I/O, multi-core support), monitoring, protection mechanisms (spatial and temporal partitioning) and error recovery mechanisms. Moreover, the system is designed to have deterministic behaviors (i.e. predictable and reproducible behaviors in both temporal and logical domains) in order to guarantee the consistency between offline analysis and tests, on one hand, and actual execution, on the other. Such determinism level is then reached by mastering sources of asynchronism (i.e. pre-emption due to scheduling policy, variations of the execution times, and communication delays) from the design level to execution. The tasks are then activated using a timetriggered approach where its time-scale, observations, and interactions are defined at the design step, allowing precise control of the system execution.

Historically, KRON-OS provided a time-triggered paradigm where time was only set by a timer. The following chapter show how this model is now extended to external trigger and how mix of such triggered paradigm is built.

a. Programming model

The dependability relies on the explicit and nonambiguous software description in order to bring a whole knowledge of all the application behavior. For this, the software functions must be specified without dissociating temporal and logical behaviors and must give all the run time hypotheses. To reach this objective, KRON-OS provides a language based on a declarative approach that allows to abstract critical aspects from the implementation: developers write their application needs (not how to implement it). By this way, application can be developed through a set of real-time components with rigorously specified and controlled resources. It has to be noticed that each task can adopt different time-scales and different temporal behaviors without considering real time execution at design level. KRON-OS is based on the TIME-Triggered execution paradigm. The system observes the environment and initiates its activities at predetermined points of the globally synchronized time. For each task, its timescale, observations, and interactions are defined at the design step, allowing precise control of the system. The decomposition in tasks corresponds exactly to the processing that should be executed in parallel (i.e. activities that are not directly dependent). No constraint on the decomposition of an application in tasks and the trigger source are imposed by KRON-OS. A TT task -also called an agent -is an autonomous entity defined by a deterministic labeled transition system, where labels represent elementary activities (denoted EA) representing sequential computation. Each EA has an associated deadline D, i.


CONNEXION Project Manager, ALL4TEC François Chastrette

Technical Director, ALL4TEC Frédérique Vallée

Luc Coyette

Combining Model-Based Design (MBD) and Model-Based Testing (MBT) for early validation of embedded real-time systems 

Keywords: Model-based engineering, MBE, Model-based testing, MBT, SCADE, MaTeLo, early validation, V&V, tool integration, CONNEXION, nuclear, Instrumentation and Control, I&C

This paper describes an approach combining Model-Based Engineering (MBE) and Model-Based Testing, and its application to requirements validation for an embedded Instrumentation & Control (I&C) system. Many aspects of the embedded system can thus be validated early in the lifecycle, long before an actual implementation is developed, and, most importantly, requirements can be validated before the system is implemented. A flexible integration environment makes it possible to reuse the test cases throughout the lifecycle. This approach is being implemented in the CONNEXION R&D project, using Esterel Technologies' SCADE Suite and All4tec's MaTeLo, with Corys' ALICES as an integration environment.

Introduction

One of the issues in system and software engineering is to ensure the correctness of system or software requirements. This is particularly the case for very complex systems, such as nuclear Instrumentation and Controls (I&C) systems [5].

In April 2012, a number of French companies involved in the field of nuclear I&C started a new R&D project named CONNEXION. This project aims at implementing, among others, early validation of such embedded systems, and specifically of their requirements.

Esterel Technologies' tool, SCADE Suite, is already used for the design of I&C software. All4tec's MaTeLo makes it possible to generate test cases for I&C systems, based only on their specifications. In the scope of the CONNEXION project, the challenge is to integrate these tools and combine their features in an optimum way.

This paper describes how this was achieved for the first test case that was selected by CONNEXION.

CONNEXION Project Overview

CONNEXION [4], a French R&D project, aims at defining and implementing new methods and tools for the design and validation of nuclear Instrumentation and Control architectures. The project is scheduled to last four years. The new methods and tools must comply a set of references from IEC establishing acceptable practice ( [START_REF]Nuclear power plants -Instrumentation and control important to safety -General requirements for systems[END_REF] to [START_REF]Nuclear power plants -Instrumentation and control important to safety -Hardware design requirements for computerbased systems[END_REF]) to comply with regulations from various national nuclear safety authorities (e.g. [9]) and must allow the designers to efficiently build a convincing safety case.

CONNEXION partners include power plant operator EDF, I&C suppliers Rolls-Royce, AREVA and Atos Worlgrid, simulation specialists such as CORYS, and technology suppliers, such as All4tec and Esterel Technologies.

CONNEXION has selected a full model-based approach, in which the I&C system is modeled (Figure 1, top), as well as its physical environment (Figure 1, bottom) and the manmachine interface that is normally found in the plant's control room (Figure 1 For each of these Elementary Systems, the I&C development is tightly integrated with the development of other aspects of the system (Figure 3).

Figure 3: Development of an Elementary System

The "I&C Functional Diagrams" box contains an iteration of the lifecycle for each I&C function associated with the Elementary System. This lifecycle is described in the next section.

Lifecycle of an I&C function

Based on the extensive experience of project participants [1] [2] [3], CONNEXION has selected a lifecycle which involves successive iterations of the specify-design-validate (V) cycle.

In each of these iterations, a validation step is performed (Figure 4). Model-Based Engineering is used throughout this lifecycle. For Grade A functions [START_REF]Nuclear power plants -Instrumentation and control important to safety -Classification of instrumentation and control functions[END_REF], early implementations of the system are developed with SCADE Suite [6]. The code generated by SCADE Suite is then used to build an executable version of the model (Box labeled "2", Figure 4). The early SCADE Suite model itself is then discarded when the system is implemented in its final technology, appropriately qualified industrial automata (PLC's) in most cases. The only purpose of the early model is to provide an executable version of the system, and to allow early validation of its requirements.

The Model-Based testing tool that was selected for CONNEXION is MaTeLo [7] (Box labeled "3", Figure 4).

Test cases

In the scope of CONNEXION, each method or tool (or integration of tools) must be implemented at least once against a significant test case (demonstrator). For early validation of requirements, two very different test cases were selected.

Diesel Load Sequencer (DLS)

The DLS is the control system for the Emergency Diesel Generator (part of the Backup Power Supply system), which provides power to the plant in case external power sources are lost.

If Main Power Supply is lost, the DLS starts the Diesel generators, then reconnects the major components of the plant. In doing so, it provides an orderly load sequence to prevent heavy transients on the emergency diesel generator solicitation.

The DLS features a relatively large number (24) of Boolean inputs, with some degree of input redundancy (AND / OR) as defined by Quality of Service requirements allocated to this function. It also features a significant number ( 12) of Boolean outputs.

The DLS was selected as a test case because of another of its features, namely its complex timing constraint: the orderly reload sequence requires 7 or 9 scheduled actions to be performed at precisely timed intervals.

Continuous Control system with cosimulation of the physical process

The second test case is reactive, also derived from a real-life system, and embeds a control loop that maintains a physical parameter (in this case, the water temperature at a certain point in the circuit) within specified bounds. Proper operation of the control loop can only be tested if the physical environment of the real I&C system (i.e. part of a nuclear power plant) is appropriately simulated: an appropriate integration environment for co-simulation was thus developed and implemented. Test cases can then create appropriate variations of the simulated environment and explore how the control loop maintains the required properties. In addition, tests also simulate discrete events such as user inputs and equipment failures.

Full implementation of this second test case is scheduled for a later stage in the CONNEXION project. When time comes, implementation will take place using the tools described in this paper (SCADE Suite, MaTeLo) in the selected integration environment (ALICES).

Application of MBD and MBT to early validation of requirements

Purpose

In order to perform early validation of functional requirements (Figure 4, box "1"), requirements must be mostly validated in the first iteration of the V cycle (1 -2 -3, dashed line on Figure 4). The objects that are being validated are the requirements themselves, not their implementation.

This goal is achieved by a combination of Model Based Design (MBD) and Model Based Testing (MBT). Each of these modeling activities has its own model. These two models and their construction are described in the next sections of this paper.

Independence between development activities (design, implementation) and V&V (verification and validation) activities is a key issue when verifying safety-critical applications and systems. For example, IEC 60880 [START_REF]Nuclear power plants -Instrumentation and control systems important to safety -Software aspects for computer-based systems performing category A functions[END_REF] requires such independence for software validation of Category A functions such as the DLS. To address functional validation (validation of requirements) according to IEC 61513 [START_REF]Nuclear power plants -Instrumentation and control important to safety -General requirements for systems[END_REF], due attention was paid to maintain independence for the implementation of the DLS test case: MBD was performed by Esterel Technologies, while MBT was performed by All4tec.

Requirements

For the DLS test case, requirements were expressed in text form with some additional SysML diagrams (Figure 5). A graphical SCADE Suite model was built to describe the system from its textual requirements. This model is executable, which allows clarification of the early set of requirements and early testing (before any code is written).

The SCADE model contains a detailed description of dynamic behavior and algorithms. It features full traceability to functional requirements.

Using SCADE Suite, all verifications can be statically performed at model level.

Dynamic verifications, such as executing tests scenarios generated by MaTeLo, can be executed under SCADE's Qualified Testing Environment (QTE). In the MBT lifecycle, a test model is built, then used to generate one or more test scripts. These test scripts are later executed in an appropriate environment.

A test model is built by a human from a set of requirements.

A full description of the DLS test model that was built for CONNEXION is beyond the scope of this paper. Only some of its most significant features are shown in this section.

Time

The discrete nature of time is handled by MaTeLo as follows (Figure 7). Time is increased when the test script allows the SCADE model to execute one step (SSM::cycle primitive). Time is suspended when the test script sets test inputs (SSM::set primitive) and checks that outputs have their expected values (SSM::get primitive). The test model also contains advanced features, two of which are described below.

Ignored inputs

The DLS requirements contain statements such as "when the system is in state S, input I causes…; all other inputs are ignored". Testing such "ignored" requirements implies a proper coverage of the "other inputs" clause.

A first approach is to set each of the ignored inputs, one by one, and to verify that they indeed have no effect. Figure 9 illustrates this approach.

Figure 9: Dealing with ignored inputs (deterministic approach)

A second approach is to randomly set a number of the "ignored" inputs, and verify that they have no effect. This is achieved by a test model such as the fragment shown on Figure 10. For the DLS test case, both the deterministic and the stochastic approach were applied to different parts of the test model. This was done in order to illustrate the feasibility of each approach with respect to model size, knowing that both approaches will lead to combinatorial explosion if they are applied to a large test model.

Deterministic testing of a complex timing sequence

The DLS requirements specify a complex reload sequence that is composed of 7 macro-steps and can be interrupted at any time. If the interruption occurs, two specific steps must be performed; the interrupted sequence is then resumed.

Stochastic testing is not appropriate as the corresponding requirements are safety-related and therefore must be tested extensively. The test model must therefore "unroll" the sequence. This is achieved by the model fragment shown on Figure 11, which can in fact easily be created, as it is highly regular.

Static integration

Static integration mostly involves requirements traceability. Each of the involved tools has its own traceability feature:

 SCADE establishes traceability between requirements, on the one hand, and model features and tests, on the other hand;

 MaTeLo establishes traceability between requirements and individual test steps.

In the generated test scripts, requirements identifiers were inserted, in order to allow SCADE to determine which requirements were covered by a particular test case. This was done at the level of an individual test step. For this demonstrator, requirements were included in test scripts as comments, as shown in the following script fragment

# Requirements: SEQD_CTL_08

Other means of implementing requirements traceability are possible, and could be implemented in the future.

Dynamic integration

As shown above, integrating SCADE with MaTeLo requires that test scripts call appropriate QTE primitives at the appropriate instants. Integration is easy, as only three primitives are needed:

SSM::set Model/Input SSM::get Model/Output SSM::cycle or SSM::cycle $n

Integration environment

Test stimuli can be sent directly to the I&C system (e.g., operator actions) or to the physical environment model that simulates the physical world that the I&C system controls (e.g., temperature, pressure and flows in various pipes). Equipment failures must also be simulated (normally through test inputs to the physical model) in order to test how the I&C system recovers from such failures.

In addition, execution of the models (I&C model on the one hand and physical environment model on the other hand) must be synchronized with the test scenario.

Corys' ALICES environment provides the framework in which test cases are executed throughout the system lifecycle. It provides the required features, namely model synchronization and distributed computing if needed. The use of a common integration environment also makes it possible to seamlessly replace models implemented in a particular technology by other models implemented in different technologies, thus preserving investments such as the definition of test cases when technologies evolve.

In the specific case of the DLS system, usage of ALICES was not required for early validation of requirements. It will however be required for the second test case.

ALICES will also be used when the same test cases are reused, later in the I&C lifecycle: CONNEXION intends the test cases to be reusable throughout the lifecycle, as shown by the red arrows (Figure 12). The current specification of QTE and ALICES makes it possible to reuse the same SCADE model, and the same generated test scripts at all of the above steps (Figure 12). This has not yet been exercised in practice, but we are confident that this will be achieved soon.

Application and results

The method described in this paper was applied to the Diesel Load Sequencer.

The execution chain was tightly integrated, as described above. This is illustrated in Figure 13. Requirements coverage was 100% for both the design model and the test model, except for a small number of requirements that were expressed as "to be completed later".

The test model was deliberately build in order to generate test cases that independently exercised the various conditions that appeared in the requirements, such as "when signals S1 and S2 are true for more than S seconds, then…". Indeed, the generated test cases made it possible to achieve 100% MC/DC coverage of the SCADE Suite model.

Conclusion

Early validation of requirements is a known "best practice". The seamless integration of the described tools, and the availability of executable models early in the lifecycle, have made it possible to detect errors in requirements early in the lifecycle of an I&C function.

The power of this combination of Model-Based Design (MBD) and Model-Based Testing (MBT) has been shown on a practical example, the DLS. The CONNEXION project has planned to evaluate this approach on systems of other technical natures, such as a continuous control system. The objective of CONNEXION is that, after the project ends, this particular combination of MBD and MBT will become mature enough to support standard practice for I&C design. Règle Fondamentale de Sûreté (RFS) II.4.1.a "Logiciels des systèmes électriques classés de sûreté" (2000)

Figure 1 :

 1 Figure 1: The three models

Figure 2 :

 2 Figure 2: Overall Plant Lifecycle

Figure 4 :

 4 Figure 4: Lifecycle of an I&C Function

Figure

  Figure 5: DLS Requirements 5.3 I&C Specification (Model-Based Design)

Figure

  Figure 6: SCADE Model 5.4 I&C Test Model (Model-Based Testing)

Figure 7 :

 7 Figure 7: Discrete TimeTimed events, which are found in the complex reload sequence (e.g. "item N shall be reloaded 5 seconds after item N-1"), are tested in a similar way (Figure8), using the appropriate parameter of the SSM::cycle primitive.

Figure 10 :

 10 Figure 10: Dealing with ignored inputs (stochastic approach)

Figure 11

 11 Figure 11: Reload Sequence

Figure 12 :

 12 Figure 12: Future reuse of the test cases

Figure 13 :

 13 Figure 13: Integrated Tool Chain Functional validation was achieved. Errors in the (fake) requirements used for this project were indeed found. More unexpectedly, errors in both models (the design model and the test model) were found as well.

  Chériaux François, Galara Dominique, « Expérimentation de techniques d'ingénierie système pour la formalisation de données de fonctionnement et de contrôlecommande », Génie Logiciel N°100 (2012) Lars et collectif, « Expressing and verifying technical specification logic using a plant generic model », EHPG (HALDEN) 2013 [3] Daumas Frédéric, Joubert Christian, « Méthode d'analyse critique du logiciel des systèmes programmés de sûreté par modélisation exécutable et instrumentée de ses documents de spécification et de validation », 12ème Colloque National de Sûreté de Fonctionnement « Lambda-Mu », Montpellier, France (2000) [4] Devic Catherine, Morilhat Patrick, et collectif partenaires du Cluster CONNEXION « COntrôle Commande Nucléaire Numérique pour l'EXport et la rénovatION -Coupler génie logiciel et ingénierie système : source d'innovations », Génie Logiciel N°104 (2013) [5] Cheriaux François, Salaün Patrick, Daumas Frédéric, "Functional test of control systems ensuring a high coverage rate", ANS NPIC-HMIT, Knoxville, USA (2009) [6] F.X. Dormoy "SCADE 6 A Model Based Solution For Safety Critical Software Development", Embedded Real Time Software and Systems (ERTSS'2008) [7] All4tec website: http://www.all4tec.net/.[8] H. L. Guen and T. Thelin. Practical experiences about statistical usage testing. In STEP


Gilles Millet

Serge Bruillot

Didier Dejardin

Nicolas Imbert

Fabrice Auzanneau

Luca Incarbone

Marc Olivas

Loïc Vincent

EUROCOPTER Alain Cremezi

Sylvain Poignant

Aircraft

à 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.

Context

The cumulated lengths of electrical cables continuously increases in aircrafts and trucks: now up to 10 kilometers in a modern truck, 40 km in a helicopter or in a fighter aircraft and 500 km in a modern civil transport aircraft such as A380. Electrical wiring is a critical part in the nominal operation of a system. The importance of the wired network has thus grown to the same level as the systems it is connected to [START_REF] Auzanneau | Wire Troubleshooting and Diagnosis: Review and Perspectives[END_REF]. Regarding the increasing complexity of the electric system (increase in the number of electric loads, in the supply voltages), the regulation authorities (FAA, Federal Aviation Administration and EASA, European Aviation Safety Agency ) now require to consider aircrafts' electrical wiring as a system on its own, named EWIS (Electrical Wiring Interconnection System).

On-board electronic equipment and systems are now equipped with integrated functions allowing a fast and targeted diagnosis called BITE (Built-In TEst), however this is not the case today for the electrical harnesses. The sensitivity to defects evolves because of the design complexity and integration of new technologies: various problems can emerge at system level due to electric cables. The diagnosis of the electrical wiring is then essential to detect and locate these defects, and to improve safety and reduce maintenance costs. This paper presents recent results in wire diagnosis for transportation.

One can question about the necessity of such a Research and Technology work undertaken to improve cabling defect diagnosis, since the reliability of the cables installed in modern vehicles is specified to be compliant with its life time. This statement does not take into account neither the possible human errors during manufacturing, installation of the electrical harness and maintenance operations, nor the stringent operational environment in terms of shocks, vibration and humidity aggressing the wiring infrastructure, composed of cables, connectors and interconnection units.

Several kinds of cable defects must be considered (Figure 1). Depending on them, different techniques must be deployed. Through Ground Maintenance, only established true defects can be located, after being preliminarily detected by classical continuity tests, for example.

Transient defects are an important issue because they only appear during usage. Most of the time they can't be reproduced afterwards; which often leads to electronic pieces of equipment removal with "No Fault Found" after test. The only solution to detect and to locate them is an embedded harness maintenance system. Such a system must be designed for scanning in real time the relevant cables, without affecting their operational mode of operation, in order to detect a defect and then to focus on the suspicious cable to locate it precisely. One must keep in mind that on-board cable monitoring must discriminate true defects from normal discontinuities due to powered off equipment or electrical power distribution reconfiguration such as load sheds.

Cable degradation diagnosis is the most challenging topic because it can reduce the "Aircraft On Ground" (AOG) time or improve the Truck Uptime (availability for the driver), thanks to a maintenance operation before a true defect occurrence. Methods to provide a prognostic are out of the scope of this paper.

Wire diagnosis reflectometry-based methods

Apart from transports, reliable wired networks are of utmost importance in several domains, such as energy production, large infrastructures, buildings, telecommunication, etc. There are often quite long lengths of wires of various types (Figure 2) and several systems and sometimes even people directly depend on their good health. From a quality of service point of view, it is very important to be able to check the proper state of these cables or to repair any defect as quick as possible. The stakes are huge: the overall cost of an AOG was estimated by airlines up to USD 150000 per hour.

Figure 2 : Cumulated cable lengths in various application domains

In all these application domains the importance of maintenance is clear, but locating a small defect or even an open circuit in several kilometers of wires can be very difficult, considering that these cables may not be easy to reach. There are very few diagnosis and maintenance methods for wires, the most widely used being visual inspection. But it can't be exhaustive, especially in the case of very long or hidden wires. The need for more adapted diagnosis methods has grown and several new electrical methods have been studied and developed recently.

As of today, the most promising diagnosis methods for wired networks are based on the reflectometry principles: sending a probe signal down the wire [START_REF] Auzanneau | Wire Troubleshooting and Diagnosis: Review and Perspectives[END_REF]. This signal propagates and sends back a part of its energy when it reaches an impedance discontinuity. The analysis of the reflected signal -which is generally quite different from the input signal -provides information on detection, localization and characterization of the defects which generated the impedance discontinuities. Some methods are well adapted for the monitoring of ageing cables [START_REF] Fantoni | Wire System Aging Assessment and Condition Monitoring Using Line Resonance Analysis (LIRA)[END_REF] (e.g. LIRA, Line Resonance Analysis, which requires heavy equipment), some others are more dedicated to the detection of hard defects (open and short circuits) for maintenance purposes [START_REF] Furse | A Critical Comparison of Reflectometry Methods for Location of Wiring Faults[END_REF] (TDR and STDR, Sequence Time Domain Reflectometry) or embarked diagnosis (MCTDR, Multi Carrier Time Domain Reflectometry) [START_REF] Lelong | On Line Wire Diagnosis using Multicarrier Time Domain Reflectometry for Fault Location[END_REF] and sometimes of soft defects [START_REF] Wang | Health Monitoring of Power Cable via Joint Time-Frequency Domain Reflectometry[END_REF]. Recent developments have proven their efficiency for the cancelation of location ambiguities in complex topology networks [START_REF] Ben Hassen | On-Line Diagnosis using Orthogonal Multi-Tone Time Domain Reflectometry in a Lossy Cable[END_REF]. These results have also been extended to the diagnosis of connectors [START_REF] Olivas | Feasibility of the detection of vibration induced faults in connectors by Reflectometry[END_REF], which are often considered as the weak points of an interconnection system.

Standard reflectometry systems are made of 3 basic blocks: signal generation and injection, measurement acquisition, data processing and fault localization. These electronic blocks can be studied separately, depending on the complexity of the chosen method, and each can be prototyped and realized with quite simple electronic design. Modern reflectometry-based methods use complex diagnosis signals with specific mathematical properties. The reflectogram is obtained by the correlation of the measured signal and the injected signal. Embedded diagnosis implies additional constraints such as: cost, low power, small size and harmlessness. The latter means that the diagnosis signal must not interfere with potential useful signals on the wire, and that the emitted EM radiation fulfills some EMC requirements. In the case of automotive and avionics, this last constraint is of extreme importance.

To this end, MCTDR method permits a precise control of the spectrum of the injected signals, and supports a distributed diagnosis architecture [START_REF] Lelong | Distributed Reflectometry Method for Wire Fault Location using Selective Average[END_REF] that enables unambiguous and full diagnosis coverage for complex branched topologies. The diagnosis signal of MCTDR is designed as the sum of a finite number of sinusoids at a given set of frequencies, chosen outside of the useful signals and EMC (Electro Magnetic compatibility) spectra. Specific conducted and emitted electromagnetic interference measurements have proven that MCTDR does not radiate any harmful signal outside of the chosen frequency bands, thus guaranteeing zero interference with the useful signals of the network under test.

Current achievements in various TDR-based systems have proven the possibility of diagnosing hard defects with localization accuracy close to few centimeters both for embedded or external purposes. A single acquisition phase is about 500ns -1µs long. The signal to noise ratio can be improved by averaging several results, thus increasing the acquisition duration. To be able to diagnose soft defects, such as damaged insulator or shielding defect, new methods are currently under study [START_REF] Franchet | Modeling the effect of a defect on crosstalk signals under the weak coupling assumption[END_REF].

The « Harness BITE » project

Rationale

The main industrial actors of aeronautics in France have worked in a cooperative research project called "Harness BITE", led by Airbus, whose main objective is to develop a real time monitoring system of aircraft power distribution electrical wiring, aiming at detecting and locating wires defects, even intermittent (in flight), thus decreasing the maintenance costs.

Electronic design

An innovative reflectometry-based method, called Multi Carrier Time Domain Reflectometry (MCTDR) has been developed. Several electronic boards were designed and realized (Figure 3) for the needs of the project, based on the use of FPGA (Field-Programmable Gate Array) components (Altera Cyclone III). The FPGA is in charge of signal generation and injection via a Digital to Analog Converter (DAC, @100 MSPS) and signal acquisition via an Analog to Digital Converter and signal processing. A specific IP has been designed and implemented for the analysis of measured signals and extraction of the useful information, i.e. defect detection, location and characterization.

Figure 3: Reflectometry electronic boards

The location accuracy in TDR-based methods depends directly on the frequency band of the injected signal, and the propagation speed of the cable, as shown on formula (1).

√

Where c 0 is the light velocity in vacuum,  is the relative permittivity of the insulator, f is the frequency band of the DAC. In our case, this leads to 1 m accuracy, which is not acceptable. An innovative oversampling process has been implemented [START_REF] Guilhemsang | Method for detecting and locating defects by reflectometry in a wired electric network and corresponding device[END_REF], based on the hypothesis that the state of the cable does not change over a complete measurement phase. A sequence of N data acquisition desynchronized in time by a portion of the DAC period is acquired and used to reconstruct a full reflectogram with N-fold enhanced location accuracy.

Description of the test benches

In order to incrementally validate the MCTDR based diagnosis methods, three test benches have been used, with an increasing level of relevance compared to a real aircraft electrical installation:

1. OFF-LINE bench (Figure 4): it is a purely topologic bench, not powered, wired with real electrical cables but without any load. The types and lengths of the cables (up to 30 meters) were characteristic of cables used in various aircrafts. The purpose of this first bench is to characterize the cables with different cable defects. Some parts of the harnesses can be replaced by defective ones. 2. ON-LINE bench (Figure 5): this bench, illustrative of the electrical installation and distribution aspects, is equipped with powered loads. The purpose of this second bench is to validate the performances with powered cables and the coupling with a protection device (AGFCB: Arc Ground Fault Circuit Breaker) and to test the ability to detect intermittent defects. Raceways used to ensure shield continuity in case of composite fuselage were also fixed to the M2000 fuselage (Figure 10).

Figure 10 : Raceway general installation view

The purpose of this bench is to validate performances with real electrical installation and powered loads, thus being as close as possible of a real aircraft environment but still on ground.

Benches definition is based on the aircraft / rotorcraft manufacturers' specifications in terms of cable lengths, electrical distribution topologies, types of cables and connectors, wire gauges and installation rules.

Loads are chosen in order to cover a wide diversity of characteristics and different types of cabling and electrical power (28V DC or 115V AC / 400 Hz): resistive loads such as lamps, inductive loads such as pumps, pieces of avionics equipment. For each load, return current path is achieved by the mockup structure; which is fully representative of a non composite aircraft installation.

Several configurations have been tested in order to evaluate the robustness of the MCTDR-based defect diagnosis algorithms:

 Longest path between the power supply unit and the highest power consuming unit,  Path with the worst topology case (electrical bus with the maximum number of derivations),  Path with the maximum number of cable segments and cut-off connectors,  Path with the maximum number of heterogeneous cable segments,  Path with the load closest to the power supply unit.

The different types of studied defects are open-circuits, short-circuits between two wires or with the ground and intermittent defects (Figure 11 to Figure 13):

Measurement results

Around 3000 different measurements were performed on the 3 test benches, according to a predefined test procedure. The objective was to be able to evaluate the diagnosis performances for almost all possible cables and defects configurations, representative of the 3 aircrafts types (helicopter, corporate jet aircrafts and airliners).

A few example are shown below. The cable topology shown on Figure 4 was duplicated on the ON-LINE test bench, with a load at connector C1 and energy supply of 28V DC. The reflectogram was measured for 3 different load configurations: normal load, open circuit (load was removed) and short-circuit (cables were connected). Figure 14 compares the 3 reflectograms: the curves change at distance close to 30 meters, which is the length of the line under test. The presence of voltage does not prevent from detecting the defect, and the signatures of open and short-circuits can be easily recognized. The peaks situated between distance 0 and the defect come from the impedance mismatch at the connection of the electronic board and the cable, and also from additional components and metallic structures between the board and the load. All these impedance changes create noisy signals that bounce several times before coming back at the reflectometer. However, as we are dealing with embedded diagnosis, the important feature for defect detection is the difference between the current measurement and a reference one, which is dynamically updated to take into account small and slow variations of the wire's state. A fast change, such as the appearance of a defect at the load can easily be isolated by simple comparison. Figure 15 shows a burst of the first 4 measurements done at the detection of an intermittent open circuit defect leading to a series arc fault on the M2000 test bench (Figure 11). The red curve is the last result just before the signal went above the detection threshold, and then come the green, blue and purple curves. Each measurement lasts for 160µs due to the averaging and oversampling processes. The difference between each curve is due to the fact that this defect lasts longer than the measurement phase: the detection device can monitor the appearance, the "steady state" and the disappearance of the defect, just as a camera would do.

Way forward

Through this in-depth test campaign, the consortium has shown the adequacy of embedded reflectometry systems to avionics issues, and the technology developed in the project was labeled at Technology Readiness Level 4 (TRL4), i.e. the MCTDR technology was validated in laboratory environment, although very close to operational conditions (i.e. TRL close to level 5).

Based on the encouraging results of this first step, a second step is envisioned in order to increase readiness up to TRL6. Its goal is to validate a system approach, with reflectometry sensors embedded as an ASIC in electronic equipment, such as electrical power distribution center or Circuit Breaker, and globally or locally in order to detect and locate defects, even intermittent, during the flight.  Tests improvement thanks to the coupling of the toolkit with the vehicle's ground database for a better wiring defect localization and quicker maintenance.

A longer term challenge for embedded electrical harness maintenance would be defect prognostic, taking into account wiring ageing.

Conclusion

To increase the reliability of wired networks or to ease their maintenance, MCTDR was identified as the most promising method for embedded EWIS diagnosis. Based on the injection into the network of a multicarrier signal which respects EMC and harmlessness constraints, this method provides information for the detection, localization and characterization of electrical defects (or mechanical defects having electrical consequences) in the wired network.

The application to avionics has been studied in this project, gathering a consortium of large industries such as Airbus, Dassault Aviation, Eurocopter, Labinal, Latelec, Crouzet and, Zodiac with upstream research from CEA LIST. Next step is to cover both avionics and automotive (through Volvo group's involvement in the project).

Location accuracy was evaluated close to 20 cm for twisted wires but was degraded for one wire above metallic ground, for up to 30 meters long cables. Branched networks are difficult to diagnose above 3 branches, but this only concerns less than 5% of wires in aircrafts. The ability to detect intermittent defects of less than 1 ms duration was proven.

The use of Off the Shelf components and an FPGA for embedded data processing paves the way for future ASIC design and system integration.

Figure 1 :

 1 Figure 1 : Classification of wire defects found in aircrafts (NASA)

Figure 4 :

 4 Figure 4 : OFF-LINE bench. Red portions can be replaced by defective ones.

Figure 5 :

 5 Figure 5 : ON-LINE bench, equipped with real loads (lights, etc), powered by a real aircraft generator 3. M2000 bench: this bench consists of the installation of a harness manufactured with an industrial process and of topologies representative both of the cabling rules and the electrical distribution architectures of the 3 end users involved in the project (Airbus, Eurocopter and Dassault Aviation).Cabling performed on a Mirage 2000 fuselage (Figure6to Figure9) includes the use of several kind of fastening (plastic or not) and paths (ceiling path, path with irregular interval between fixings).

Figure 6 :Figure 8 : Ceiling path Figure 9 :

 689 Figure 6 : HB collars Figure 7 : Plastic collars

Figure 11 :Figure 13 :

 1113 Figure 11 : Series Arcing Fault injection Figure 12 : Parallel Arcing Fault injection

Figure 14 :

 14 Figure 14: 3 different defects on a wire, ON-LINE testbench Intermittent defects have been generated by specifically designed devices, and tested according to the appropriate standards (AS6019 for 28VDC & AS5692 for 115VAC).

Figure 15 :

 15 Figure 15: Intermittent defect detection

  This project allows to:  Anticipate new FAA & EASA Airworthiness recommendations for EWIS,  Anticipate new risks induced by High-Voltage (arc-fault detection and location),  Create new on-board diagnosis systems for electrical harnesses,  Reduce maintenance cost with defect location capability.

  Possible enlarging of the use of this wiring defects diagnosis technology to communication links (i.e. digital buses) will be also a new challenge of this second phase.The results obtained during this second step will offer to trucks, aircraft or rotorcraft development programs new opportunities to take benefit of defect localization techniques. The main milestones are: Retrofit ofan existing aircraft by only replacing in the harness the current AGFCBs by smart AGFCB versions embedding the cable defect localization function (wire by wire management),  Test new vehicles' electrical architecture with an embedded Harness BITE system, including: o Wiring defects detection and localization sensors integrated in vehicle's Electrical Power Distribution Units or communication buses switches, o Sensors management and measures exploitation functions, including false alarms filtering (in case of normal avionics units power off for example),

Acknowledgement

The results presented in this paper were obtained during the research project Harness BITE, a part of the @MOST project dedicated to aircraft maintenance led by AIRBUS and partially funded by the French Directorate General for Civil Aviation (DGAC).


Florent Feve
email: florent.feve@valeo.com

Automatic Safety mechanisms implementation in Software Model-Based Development ERTSS 2014 : (thema : Model-based system engineering, Safety)

Keywords: Model Based Development, Safety, Error detection, Fault injection, MIL, SIL

ABSTRACT

Model Based Development (MBD) is now a common approach for the automotive industry. Using modeling tools to simulate the behavior of a system before developing the corresponding product(s) through automatic code generation has proven its efficiency. The Road vehicles -Functional safety -ISO 26262 standard (Part6 ) [START_REF]Road vehicles -Functional safety -Part 6: Product development: software level[END_REF] identifies MBD as a recommended approach especially for software architecture design with semi-formal notation and software verification with back-to-back testing through Model in the Loop (MIL) , Software in the Loop (SIL) and Processor in the Loop (PIL). Regarding error detection the standard recommends a certain number of monitoring methods such as "Range checks of input and output data", "Plausibility check", "Control flow monitoring", but does not give any concrete recommendation for software implementation of those methods and therefore how to test through fault injection. In the MBD approach, since code is generated automatically, safety mechanisms must be introduced at model level.

This paper explains the automated process that has been developed to implement safety mechanisms for error detection at model level. Concrete example is described showing the advantage of MBD for safety mechanisms implementation as well as for testing. The safety mechanisms tests are done through fault injection at both model and code level. It illustrates how, from a graphical model implementing functional requirements, dedicated safety mechanisms are automatically generated in the model on selected elements. In addition, test cases are automatically generated with complete validation environment to allow full test of the safety requirements. For functional requirement verification, the MIL, SIL, PIL and HIL regular process is applied in block box. For safety mechanism verification, the same process is applied but as white box (fault injection). Results reports for model simulation and code as well as coverage reports for model and code are automatically generated.

Benefits of this innovating process are to:

-Minimize the risks for the implementation of monitoring methods since safety mechanisms are automatically introduced in the model through a plug-in.

-Improve consistency through code generation but also through automatic documentation generation from the model.

-Support full testing and verification process (test cases creation, execution and reports generation).

-Push standardization across projects for safety mechanisms implementation.

INTRODUCTION

MODEL-BASED SOFWARE DEVELOPMENT PROCESS

Overview

This chapter will give a brief description of MBD process. The aim is to describe only the part of the process which is involved in the automatic safety mechanism.

Model Based Development Process including automatic code generation is used as standard in VALEO for 10 years. For reactive system, which will be the use case for MBD safety mechanism described in this paper, Statemate tool is used. The scope of the model is the functional requirements which will be implemented as part of the application layer of the embedded software. From Requirements analysis, a functional model is first designed in order to validate the functional requirements. In parallel Requirement based testing is initiated. Validation team analysis requirements and build test cases that will be used in MIL (Model In the Loop), SIL (Software In the Loop) and HIL (Hardware In the Loop). Those test cases are generated as test scripts that will be automatically applied as inputs to the model for MIL testing. MIL reports cover both results comparison (expected results vs simulation results) and model coverage.

Later on for HIL testing with the final ECU the exact same test cases will be performed.

Figure 1 -MIL validation process

The process is fully automated with a set of plugins allowing translating test scripts into Statemate Statecharts that will be added to the simulation environment as test drivers for simulation.

Once the model has formally been validated, the implementation phase starts with dedicated design rules checked automatically by an in-house plug-in.

Code is generated to be executed first on a host PC. SIL testing is then performed by complete reuse of the MIL environment. Same as for MIL testing, SIL reports cover both results comparison (expected results vs code execution results) and code coverage. Code coverage is performed using a third party tool which is part of the full automation. No new scripting or configuration is needed. This part of the process is especially useful in case of Safety relevant Sw development as we will see later on.

Full traceability from requirements to code is covered though dedicated attributes for all elements of the model which are generated as comments in the source code by code generator configuration.

MBD PROCESS AND SAFETY REQUIREMENTS 4.1 Road vehicles -Functional safety -

The ISO 26262 is a set of documents defining the standard for Functional safety for Road vehicles. It defines an automotive specific risk-based approach for determining risk classes: ASIL (Automotive Safety Integrity Level). Four classes (A, B, C, D) are used to specify the necessary safety requirements for achieving an acceptable residual risk. "D" represents the highest risk. QM stands for "Quality Management" and means that there is no ISO 26262 requirement to apply.

Figure 2 -ASIL determination

The ASIL determination is based on the Hazard Analysis and Risk Assessment and leads to the Safety goal concept. "++": The method is highly recommended for this ASIL "+": The method is recommended for this ASIL.

"o": The method has no recommendation for or against its usage for this ASIL.

In the document we can find that Model Based Development is either recommended or highly recommended for safety related product development depending on the ASIL level. For example, specification methods are defined in the table "Specification of safety requirements" [START_REF]Road vehicles -Functional safety -Part 8: Supporting processes[END_REF]. Three general methods for requirements specification are listed:

-Informal notations (1a) -Semi-formal notations (1b) -Formal notations (1c)

Tools used for MBD are semi-formal notations. This method is recommended ("+") for ASIL A and B and highly recommended ("++") for ASIL C and D.

Another example is for verification methods which are listed in the table « Specification Verification of safety requirements in part 8 » [START_REF]Road vehicles -Functional safety -Part 8: Supporting processes[END_REF]. Four methods are listed:

-Verification by walk-through (1a)

-Verification by inspection (1b)

-Semi-formal verification (1c)

-Formal verification (1d)

For method 1c, there is the following note : "can be supported by executable models" which is indeed inline with the MBD process. Actually MBD is also an added value for method 1b in the way that large part of the inspection can be automated.

Method 1b is recommended ("+") for ASIL A and highly recommended ("++") for ASIL B, C and D. Method 1c is recommended ("+") for ASIL A and B and highly recommended ("++") for ASIL C and D.

In addition Part 6 of ISO 26262 [START_REF]Road vehicles -Functional safety -Part 6: Product development: software level[END_REF] mentions the following:

-Table 6 (PART 6)-Methods for the verification of the software architectural design, method 1C : Simulation of dynamic parts of the design which "requires the usage of executable models for the dynamic parts of the software architecture".

- The main adaptation needed comes from the safety mechanisms to be implemented at software level. In the MBD approach, since code is generated automatically from the model, safety mechanisms must be introduced at model level.

Safety mechanisms for error detection

This steps of the process comes after the Safety analyze, that is to say, the Software functions/modules to be protected by safety mechanisms has been already identified. Critical Path Analysis can be applied to identify all modules for which safety mechanisms should be implemented.

[2] Examples of those methods can be found in some publications but it seems that different interpretations can be found. This paper describes one safety mechanism implemented for error detection which we have classified as "Control flow monitoring" even though some would see it has "Plausibility check". The implementation is done automatically in the model through a plug-in. It should be performed when functionality is implemented using state machines.

The workflow is the following:

-functional model is designed without safety mechanisms.

-functional test scripts are created based on Requirements analyze (classical MIL and SIL process)

-once safety analyze has identified which part of the design should be protected (this can be done through Critical Path Analisis), automatic implementation is generated through a plug-in.

-Test scripts are also generated automatically by the plug-in in order to be able to produce Model and code coverage reports for all safety related code. This is done by automatic modification of existing test scripts introducing Faults to trigger the "safety code " (white box testing).

Control flow monitoring :

Rational

The aim of the safety mechanism is to detect, in a state machine, during SW execution, any transition between one state to the other which is not in line with the design. From formally designed Statecharts from functional requirements, a table is build which lists all basic states and indicates all allowed former state. The table is a 2 dimensional array. The size is determined with the number of basic states of the state machine, including subcharts. Bit-array is used to represent the valid transitions to reach a state. Each bit represents a state. Value "1" indicates a valid transition. In the basic example below, 5 transitions are allowed : TR_DEF_S1, TR_S2_S1, TR_S1_S2, TR_S1_S3 and TR_S3_S2.

This leads to the following table :

Figure 3 -Transition Statechart table: example 1

The algorithm for this table is pretty simple, but becomes more complicated when considering all possibility of Statechart modeling with sub charts, parallelism, and History connector. History connector is a notation indicating that when leaving a chart or an encapsulated state, the last validate state will be entered when the chart is active again (instead of the default state). Parallel charts leads to consider more than 1 default state (as many as there are parallel state machines in a Statechart), History connector leads to consider all transitions leading to the chart as possible transition to each elementary state.

The initial version of the plug-in supported only simple Statecharts. It now supports all possibility of modeling, See example Figure 4.

Figure 4 -Transition Statechart table: example 2

Each time a state is entered, the above table is analyzed to detect any invalid former state by comparing the former state value to the "allowed former state" defined in the table for each state.

Current state is then stored to be used for next state entered. If an invalid former state is detected an error function is called.

The plug-in analyzes the Statecharts in which safety mechanism needs to be introduced. to be secured, creates the necessary table and adds in each state an "entering static reaction" to perform the check each time the state is entered. Following items are automatically created in the model :

-enumeration listing all basic states (includes subcharts) and Parallel states. Number of enumeration values equal number of states.

-Statechart table listing valid transitions for each state -subroutine for error detection (to be customized for each project)

-"entering static reaction" (actions performed when entering a state) for each state to detect non allowed transition.

This instrumentation of the model is possible due to a set of API provided with Statemate which allows any user to develop plugins able to parse the model and retrieve any elements by using a set of query functions but also to create any kind of model element. This approach of using the so called dataport APIs was already used in the Standard MIL process to translate test scripts into Satecharts (see Figure 1 plug-in GenStatechartVal).

Therefore each elementary state will be instrumented with following pseudo code:

S2

Figure

-Pseudo code instrumentation if elementary states

"entering" is a keyword for specifying actions to be performed only when the state is entered. The former state (hold in the array CTRL_TOPCHART_OLD_SATE in the example) and the current one are checked against the Statechart table. If a mismatch is detected an error handler is triggered ( CTFL_STM_ERROR) passing as parameter the current state value and the former one.

For Default state (initial state when a Statechart becomes active) specific pseudo code is generated in order to distinguish the entering in the state due to the first activation of the Statechart with further entry in the state.

Deep

Verification and Testing:

Regarding Validation and Verification strategy, the ISO 26262 has a dedicated chapter "Software unit testing" in which we can find that [START_REF]Road vehicles -Functional safety -Part 8: Supporting processes[END_REF] Software unit testing can be executed in different environments with MIL, SIL, PIL and HIL. It is also mentioned that in the case of model-based development, software unit testing may be moved to the model level using analogous structural coverage metrics for models.

The following tables can be found: We have seen how a safety mechanism is implemented automatically in a model. To be compliant with the standard the instrumented code needs to be covered in MC/DC mode.

By definition the code introduced for safety mechanism cannot be reached by regular test cases generated from the model interfaces. Those tests will need to be generated as white box through fault injection by modifying internal state variables in order to generate an error. The aim of those test scripts is to cover the structural tests of the implemented safety mechanism.

Selection of charts

Instrumentation of charts

Creation of Safety SW mechanism

Figure 7 -Simulation output files format

In regular functional MIL testing, this output file allows comparing the results of the simulation with the expected results defined in the script. Model coverage and, after performing SIL, code coverage reports are produced in order to check coverage. Therefore the verification that all states and all transitions are reached by functional test cases is available. The 100% coverage for states and transitions is a mandatory condition in order to generate test scripts for Safety mechanisms as we will see further on. For conditions, only Decision coverage ( DC ) is needed, no need of MC/DC coverage. Indeed what is needed is to have at least one test scenario that will lead to cover a transition, no matter if we cover all the possibility to trigger the transition. For example if the label of a transition is [Condition_A] OR [Condition_B], a scenario in which Condition_A is true is enough.

The test cases that will be generated for the Safety mechanism structural coverage are not generated from scratch but from existing tests scripts developed based on functional requirements. Necessary step is to run the functional tests with adding in the list of "output" signals to be stored the state variables that were introduced by the plug-in. This will lead to have output files containing references of state variables (see Figure 7 CTRL_AUTH_DRINK_OLD_STATE state variables).

The test scripts are, as well has the output recorded files during simulation, inputs for the plug-in. Both files are parsed to detect which input change in the script leads to a new state. Due to the presence of State variables in the "outputs" file it is possible to detect in the output recorded file each reference to the entering in a state with its timing reference. This timing reference will be used to identify in the input test script where to modify. The scripts are then duplicated and modified so that state variables could be corrupted in order to generate safety error.

4. 1 . 1

 11 ASIL determination ASIL determination is based on the combination of 3 factors: Severity of potential harm ( S ), Probability of exposure ( E ) and Controllability / chances to avoid harm ( C ). -Severity of potential harm has 4 classes: S0 (No injuries) to S3 (Life-threatening injuries or fatal injuries). -Probability of exposure has 5 classes: E0 (incredible) to E4 (High probability). Only E1 (Very low probability) to E4 have affect on ASIL determination. -Controllability/chances to avoid harm has 4 classes: C0 (Controllable in general) to C3 (Difficult to control or uncontrollable). Only C1 (Simply controllable) to C3 have affect on ASIL determination.

  -in workflowThe plug-in displays the whole tree structure of the model allowing choosing which part of the model should be instrumented with Safety mechanisms.

Figure 6 -

 6 Figure 6 -Model instrumentation workflow

  The solution chosen for the automation of the fault injection through test scripts was to reuse the functional test cases and introduce fault to cover fault error detection functions. As mentioned in chapter 3, our regular process for black box testing uses test scripts which describes some test sequences with the expected results. In general the signals used are the interfaces of the module. During MIL testing, inputs and outputs are stored by the simulation tool. The format of this file contains Timing reference, name of variables and new value. List of variables to be recorded is defined by the test cases. Statemate will record during simulation every signals in the list each time a signal changes. In example of recorded output file Figure7, we can find regular output signals (EWO_xxx).

Figure 8

 8 Figure 8 describes this structural coverage test script generation workflow

Figure 8 -

 8 Figure 8 -workflow for Structural coverage script generation

Table 10

 10

	(PART 6)-Methods for software unit
	testing, method 1e : Back-to-back comparison test
	between model and code, if applicable which
	"requires a model that can simulate the functionality of
	the software units. Here, the model and code are
	stimulated in the same way and results compared with
	each other".
	Both methods are either recommended or highly
	recommended for safety related product development
	depending on the ASIL level.
	Globally, Model based development process is a
	recommended approach for Safety related product
	development in terms of Requirement formalization,
	architecture, testing and validation. VALEO MBD
	process is already in line with most of the
	recommendation of the ISO 26262 Standard.

Table 4

 4

	(PART 6)-Mechanisms for error
	detection at the software architectural level,
	indicates methods to be applied but does not specify
	any concrete implementation mechanism. Six
	methods/measures are listed :
	-Range checks of input and output data (1a)
	-Plausibility check (1b)
	-Detection of data errors (1c)

The ISO 26262 Part 6 lists methods without giving definitions. "Plausibility check" and "Control flow monitoring" for example are not clearly defined.

Table 12 (

 12 Part 6)-

Structural coverage metrics at the software unit level, mentions

  Branch coverage and MC/DC coverage as recommended or highly recommended methods.

Table 10 (

 10 Part 6)-

Methods for software unit testing, method

1c : Fault injection test

CONCLUSION

This example of automated Safety mechanism generation is only one part of safety techniques to be designed and implemented at Software level but it has the great advantage to be fully automated not only for implementation but also for test cases. This innovating automated process is a first step on how to fill the gap between MBD regular approach and the Safety related requirements defined in the ISO 26262. It minimizes the risks for the implementation of monitoring methods since the safety mechanisms are automatically introduced in the model through a plug-in. In case of functional change request, model is modified and safety mechanism is regenerated with no effort. The process also supports full automated testing and verification workflow (test cases creation, execution and reports generation). Finally it pushes standardization across projects for safety mechanisms implementation. Projects only need to determine the actual error handler implementation for error detection.

GLOSSARY