Introduction

Avionics systems are complex since tens of subsystems and components interact to achieve required functions. Existing devices for aircraft fault monitoring are based on dedicated avionics functions but the existing solutions are insufficiently flexible for test systems and can be improved. In [1], the framework of an health management algorithms for maintenance is described and implemented on an aircraft. In [2], the diagnostic of avionics equipments is performed through dynamic fault trees. To prevent important failures on the aircraft, avionics systems are checked on rigs called Avionics Test Bench (ATB) composed of the avionics equipments and flight simulation software. The environment of the ATB needs to be compliant with the configuration of the avionics equipments. Faults of the ATB can concern the avionics equipments, their configurations, or the ATB itself i.e the movable connections and the simulation software. Since it does not exist monitoring functions of the ATB itself, a new method needs to be applied to prevent long periods of unavailability. In fact, during the development of embedded softwares, its architecture and the test environment surrounding the ATB are redesigned by adapting the test means to the specification's requirements. Since the ATB is a test system, and the main knowledge are based on its embedded systems, we need a new approach to deal with the ATB issues. As the embedded systems are already tested on the ATB, and the test results are used to focus on the ATB issues thanks to a new representation based on the model of the test system, the diagnosis of the ATB is what we call a meta-diagnosis. Many diagnosis approaches have been proposed to deal with specific avionics problems. Two different classes of representation are applied: data-based diagnosis or model-based diagnosis. The first one, as studied by Berdjag et al. [3] is used to recognize faulty behaviors of an Inertial Reference System (IRS) thanks to normal or faulty categories of input/output data. In this work, data fusion of outputs sensors is computed to eliminate faulty sources. In [2], the time dependency is introduced in data of failure messages to improve problems detection. In Model Based Diagnosis (MBD), Kuntz et al. [4] have studied an avionics system using minimal cuts notions. Belard et al. have defined a new approach based on the MBD hypotheses called Meta-Diagnosis in [5] dealing with models issues. Berdjag et al. [6] present an algebraic decomposition of the model to reduce the complexity of the required model-based diagnosers. Giap [7] has proposed a formalism of an iterative process to give a solution when models are not complete but it lacks of applications on more complex industrial systems. Nevertheless, it gives clues for an iterative diagnosis. Another diagnostic software has been developed by Pulido et al. in [8] to perform consistency-based diagnosis of dynamic system simulating diagnosis scenarios. The architecture is quite novel and is applied to the three-tank system. Structural approaches as graph theory are also popular for MBD to describe the structure of the system as with Bayesian Networks in [9]. They enable us to incorporate the system complexity as with the lattice concept to integrate the sub-models dependencies. For example, in [10], the lattice model represents fault modes to compute testable subsystems from redundancy equations. We want to get the main ideas that will serve our proposal. To our knowledge, there is no method for the diagnostic of test systems based on embedded softwares behaviour. Moreover, our proposition has been adapted from embedded systems to the ATB behaviour. Its complexity is relevant to the objectives of the avionics embedded systems certification, as for example high levels of safety requirements, or the simulation of specific test conditions. In our model, we must consider the fact that our representation must put forward the ATB behaviour in case of failures concerning embedded systems, connections, communications, simulation softwares and all settings to configure the test. Considering those features, the high number of needed ATB reconfigurations, it is proposed a structural representation associated with hierarchical verifications that reduce the faulty candidates. The motiva-tion of the proposed meta-diagnosis approach was presented in [11]. Here, we propose an extended diagnosis methodology originally defined by De Kleer, Williams [12], [13] and Davis [14] and we present a software implementation running on a real ATB. It differs from the Belard et al.'s metadiagnosis definition because the ATB is still defined as the main system under study. Here, we extend the diagnosticworld tools for a specific system and due to the lack of knowledge and data in case of issues, our proposal is based on a MBD representation with a structural and functional decomposition without fault models. First, we describe the diagnostic framework, the latticebased representation used to model the ATB system and the diagnostic algorithm. In the third section, we provide a description of the ATB and the application of the lattice concept. In the fourth section, we illustrate the approach with a case study of the ATB. In the final section, we describe the development of a software application to perform automatically the ATB diagnosis.

Diagnostic framework 2.1 System representation

The system is composed of several subsystems that interact together to achieve a global function. The decompositions into subsystems is guided by the communication between components to fulfill this goal. Partitions are used to decompose the system into functional and communications categories. So, there are two classes of partitions: the partitions that represent the structure and the connections of the system; and the partitions that represent the functions of the system. As an example, P 1 is associated with a functionality of the system P 1 = {σ 1 ; σ 2 }, σ 1 = {C 1 } and σ 2 = {C 2 , C 3 }. If a problem appears, i.e the functionality is not performed, then a fault is detected for this partition P and symptoms are seen and linked to subsystems σ. In the following paragraphs, we use the following notation: P for a partition, σ for a subsystem and c i for a component. S = {c i , i ∈ [1, n]} is the set of all the n components of a system. We note Σ the set of all subsystems, i.e the power set of components. A partition P is a set of n p subsystems σ i ∈ Σ:

P = {σ i , i ∈ [1, n p ]|∀i = j; σ i ∩ σ j =

∅, and np i=1 σ i = S}. We note P the set of all partitions.

We recall the definition 1 of inclusion relation between partitions and the definition 2 of multiplication. Definition 1. Two partitions P 1 and P 1 are said to be in inclusion relation P 1 ⊆ P 2 if and only if every subsystems of P 1 is contained in a subsystem of P 2 . The relation ⊆ means that P 1 is a sub-partition of P 2 . Definition 2. The subsystems σ k of the multiplication of two partitions

P = {σ i , i ∈ [1, n p ]} and Q = {σ j , i ∈ [1, n q ]} are defined by: ∀σ k ∈ P × Q, ∃σ i ∈ P, ∃σ j ∈ Q, σ k = σ i ∩ σ j .

This operation is used to order subsystems with respect to the proposed diagnostic algorithm. The inclusion relation ⊆ is used to organize the components with the lattice concept L (Σ, ⊆) with a partial ordering relation. It is different from the concept of partially ordered set (poset) because the arrangement of elements is not based on sets but on partitions.

Diagnostic function

A basic diagnostic function is defined to help the diagnosis: the check function. Depending on the granularity, the check function is applied on a component, a subsystem or a partition. First, the checkC function is used to determine if a component is faulty or not. However, we do not know precisely how a unique component behaves regarding a fault. So we need to define the checkS function of a subsystem. The behaviour of a faulty subsystem may also not be sufficient to explain a fault. In fact, subsystems are interconnected making the system structure and the partitioning concept allows us to focus on different levels of abstraction that we call granularities. In our study, we only focus on faults with observable and measurable symptoms. These faults can only be localized by testing a functionality on a specific architecture. That is why, functional and structural partitions are used to decompose the system into testable partitions. Definition 3. The checkC function of a component c i is defined by: checkC

: COM P S → {0, 1, −1} s.a checkC(c) = 0 if the component c is faulty, checkC(c) = 1 if the component c is unfaulty and checkC(c) = −1 if the component state is unknown. Definition 4.

The checkP function of a partition P is defined by: checkP :

P → {0, 1, −1} s.a checkP (P ) = 1 ⇔ ∀σ i ∈ P, checkS(σ i ) = 1, checkP (P ) = 0 ⇔ ∃σ i ∈ P, checkS(σ i ) = 0,

and checkP (P ) = −1 ⇔ the checked value is unknown. Some partitions cannot be checked. The set of possible checked partitions is Cons. It defined a constraint. A constraint Cons is a subset of P s.a: ∀P ∈ Cons, checkP (P ) = −1.

Once the checkP value of a partition is known, we have to define the checkS function of subsystems that are not singletons σ i = {c i }. If the partition is faulty, either it exists a component c i ∈ σ i such as checkC(c i ) = 0, or the communication between the components in σ i is faulty. This is modeled by checkCom(σ i ) = 0. If the partition is unfaulty, then all communications between the components in σ i = {c i } are unfaulty and all singletons σ i = {c i } are unfaulty. Definition 5. The checkCom function of a subsystem σ i ⊆ COM P S is defined by: checkCom

: Σ → {0, 1, −1} s.a checkCom(σ i ) = 1 ⇔ the communication between components in σ i is unfaulty; checkCom(σ i ) = 0 ⇔ the communications between components in σ i is faulty.

To help the diagnosis of the system, we decompose it into subsystems and we introduce the checkS function of a subsystem σ i ⊆ COM P S defined by:

Definition 6. checkS : Σ → {0, 1, −1} s.a checkS(σ i ) = 1 ⇔ ∀c i ∈ σ i , checkC(c i ) = 1 ∧ checkCom(σ i ) = 1 ; checkS(σ i ) = 0 ⇔ ∃c i ∈ σ i , checkC(c i ) = 0 ∨ checkCom(σ i ) = 0 and checkS(σ i ) = −1 ⇔ ∃c i ∈ σ i , checkC(c i ) = −1 ∧ checkCom(σ i ) = −1.

With the above definitions, it is now time to define the diagnosis problem. Given a system representation with the lattice concept L (Σ, ⊆) and the set of constraints Cons = {P ∈ P, checkP (P ) = −1}, the problem is defined by the consistency between L (Σ, ⊆) that contains the system representation, and Cons that describes system issues. Definition 7. The problem formulation is to find the faulty components whose current state may explain the constraints. It is defined as a function DIAG(L (Σ, ⊆)) under the constraints Cons.

There are two kinds of faults: the fault of a component C i modeled with checkC(C i ) = 0, and the communication fault of a subsystem σ i = {C i , C j , ...} modeled with checkCom(σ i ) = 0. With the P 1 partition, suppose that C 2 and C 3 are linked with an ARINC 429 link that is not working. The constraint is checkP (P 1 ) = 0 because the global function is broken. The reason is that checkCom(σ 2 ) = 0. Knowing that checkCom(σ 2 ) = 0 for the P 1 functionality is giving the information to fix the system.

Diagnostic algorithm

It is now necessary to introduce a diagnostic method whose aim is to solve the above problem. The algorithm is based on the following proposition that extends the verification from the multiplication of partitions to partitions, see Proposition 1. Then, a functional verification is propagated from partitions to subsystems, and from subsystems to components.

Proposition 1. ∀P, Q ∈ P 2 , checkP (P × Q) = 0 ⇒ checkP (P ) = 0 ∧ checkP (Q) = 0.

In order to increase the readability of the algorithm, it has been split into three: DIAG(L (Σ, ⊆)) is the main algorithm, it initializes the framework with the partitions of the system {p i , i ∈ [1, n]} and the constraints Cons = {P ∈ P, checkP (P ) = x}. F indF aultyElements checks the partitions that are defined as a constraint. If the checked value of a partition p mult is faulty (resp. unfaulty), we add it to the faulty (resp. unfaulty) partitions set P − (resp. P + ), and every subsystem σ i of the partition is possibly faulty (resp. unfaulty), we add it in Σ + , (resp. Σ − ). If another partition p mult can help to get more faulty or unfaulty components, a new constraint is proposed and added to N Cons. V erif ication is used to check the possible components that may be faulty, i.e include in F c with the checkC function, and the communication of the subsystems in Σ − with the checkCom function.

Two functions have been introduced: the checkP (p i ) value of a partition p i and the CheckCom(σ i ) of a subsystem. Their values can be automatically computed thanks to a program developed on the system to automate the diagnosis. This is performed by the GET function whose purpose is to model the computation of checkP (p i ) or CheckCom(σ i ).

Formal example

In order to illustrate the problem formulation and the diagnostic algorithm, a formal example is provided. It is composed of eight components {C i , i ∈ [1, 8]} organized into three partitions:

P 1 = { {C 1 ,C 2 , C 3 ,C 4 }, {C 5 ,C 6 , C 7 ,C 8 }}, P 2 = { {C 1 ,C 2 }, {C 3 ,C 4 ,C 5 ,C 6 ,C 7 ,C 8 }}, P 3 ={{C 1 }, {C 2 ,C 4 ,C 6 ,C 8 }, {C 3 ,C 5 ,C 7 }}.

P 3 describes the topology of the system. P 1 and P 2 describe functionalities. We set the C 2 component as faulty. The idea is to combine the topology of the system with its functionalities to find the faulty component or subsystem. A choice Algorithm 1: DIAG(L (Σ, ⊆))

Input: d = {p i , i ∈ [1, n]}, Cons = {cons i } Output: ∆(Diagnosis)

Global variables: End F c (f aulty components), U c (unf aulty components), Σ − (f aulty subsystems), Σ + (unf aulty subsystems), P − (f aulty partitions), P + (unf aulty partitions) ∆, F c , U c , P + , P − , Σ − , Σ + ← {}; End ← f alse; N Cons ← {}; while ¬End do F indF aultySubsystems(d, Cons);

V erif ication(F c , Σ − ); if ¬End then foreach p i ∈ N Cons do GET checkP (p i ) Cons ← Cons ∪ {p i } Algorithm 2: F indF aultyElements Input: d = {p i }, Cons = {cons i } Outputs: F c , P − , Σ − , Σ + foreach (p j , p k ) ∈ P 2 : p i = p j do p mult ← p j × p k if p mult ∈ Cons then if checkP (p mult ) = 0 then P − ← P − ∪ {p i } foreach σ i ∈ p i do foreach c k ∈ U c do σ i ← σ i \ {c k } if σ i = {c i } then F c ← F c ∪ σ i else if σ i / ∈ Σ + then Σ − ← Σ − ∪ {σ i } if checkP (p mult ) = 1 then P + ← P + ∪ {p i } foreach σ i ∈ p i do if σ i = {c i } then U c ← U c ∪ σ i else Σ + ← Σ + ∪ {σ i } if p mult / ∈ Cons then if ∃{c i } ∈ p mult then if ¬(c i ∈ U c ∪ F c ) then N Cons ← N Cons ∪ {p mult }

function is introduced to choose the next topology and the next functionality to be tested. It is guided by the minimum of tests to perform in order to fix the system. For a set of partitions P, we define Choose : {P} → P × P.

As the two functionalities are modeled by P 1 and P 2 , and the the topology is modeled by P 3 , we have two possibilities. We assume that P 2 is prior to P 1 , the first iteration is defined with Choose(P)=(P 1 , P 3 ). We begin with checkP (P 1 ×P 3 ) = 0, s.a P Components CheckC The method has permitted to detect quickly the faulty component using functional partition and a structural partitioning. Thanks to this result, possible faults regarding either the topology or the functionality are checked.

1 × P 3 = { { C 1 }, {C 2 ,C 4 }, {C3F c Outputs: ∆ F c , U c , End Initialization: σ + , σ − ← I; foreach c i ∈ F c do if checkC(c i ) = 0 then ∆ ← ∆ ∪ {c i } End ← true else F c ← F c \ {c i } U c ← U c ∪ {c i } foreach Σ i ∈ Σ − do GET checkCom(Σ i ) if checkCom(Σ i ) = 0 then ∆ ← ∆ ∪ {Σ i } End ← true else Σ − ← Σ − \ {Σ i } Σ + ← Σ + ∪ {Σ i }C 1 1 C 2 −1 C 3 1 C 4 −1 C 5 −1 C 6 −1 C 7 −1 C 8 −1

3 The Automatic Test Benchmark

Avionics system

The avionics system of the NH90 helicopter is designed to support multiple hardware and software platforms from The test consists in the simulation of a high roll. Normally the RA should be deactivated above the value of forty degrees. The procedure contains the following actions: engage the RA with the DKU 1; simulating a roll of 50 degrees; check that the RA functionality is deactivated on the DKU 1. Several messages are sent to achieve this functionality, see Table 3, defining a data-flow for two messages : "Mode on" and "Alert" messages: from DKU 1 to CM C1 via serial communication to activate the radioaltimeter's specific mode ("Mode on" message); from CM C1 to IRS1 via MIL-STD-1553 communication to relay the activation information; from IRS1 to RA via ARINC communication to send a request to the RA to get the roll angle; from RA to IRS1 via ARINC communication to send the response to the IRS that compute the angle; from IRS1 to CM C1 via ARINC communication, from CM C to DKU via serial communication to the alert and disable the functionality ("Alert" message).

Components CheckC C 1 1 C 2 0 C 3 1 C 4 −1 C 5 −1 C 6 −1 C 7 −1 C 8 −1

System Under Test (SUT) decomposition

The ATB is used to perform the realization of the avionics functions with the necessary equipments and a simulated environment needed to check the system specification.

The ATB is described as a structural decomposition with components subsets. These sets provide partitions of the whole system. We define subsystems σ i and the partitions p i with regards to the connections of the avionics system of Figure 1, the serial communication:

σ Serial1 = {CM C1, CM C2, DKU 1} σ Serial2 = {P M C1, P M C2} σ ¬Serial = {M F D1, IRS1, RA} p Serial = {σ Serial1 ; σ Serial2 ; σ ¬Serial } the ARINC communications: σ ARIN C = {CM C1,CM C2,P M C1,P M C2, M F D1,IRS1,RA} σ ¬ARIN C = {DKU 1} p ARIN C = {σ ARIN C ; σ ¬ARIN C } the MIL-STD-1553 communications: σ M IL = {CM C1, CM C2, P M C1, P M C2, IRS1} σ ¬M IL = {M F D1, DKU 1, RA} p M IL = {σ M IL ; σ ¬M IL }

The above partitions describe the topology of the problem. We classify the partitions into two categories: functional partitions and communication partitions. The functional partitions contain the subsystems that compute and send the informations. The communication partitions contain the subsystems that relay these informations. In our example, the navigation functionality is tested. Functional partition are: {p N AV ,p P ERF }, connection partitions are: {p M IL , p Serial , p ARIN C }. We need to define additional partitions that can be checked with the check function on the system thanks to this representation: Those partitions will serve to improve the diagnosis.

p N AV.M IL = p N AV × p M IL = {{M F D1,RA};{IRS1}; {CM C1,CM C2,P M C1,P M C2};{DKU 1}}; p N AV.Serial = p N AV × p Serial = {{CM C1, CM C2,

Outlooks about the decompositions

We describe an iterative method to update the diagnostic result by providing new topologies of the system. We need to get precise observations to find the faulty components. The subsystems are computed with the framework of the previous section.

Given the components, the messages sent between them, and the protocol of these messages, we can obtain an overview of the system decomposition: p SU T can be decomposed into d protocol = {p SU T × p M IL ; p SU T × p Serial ; p SU T × p ARIN C }. This hierarchical structure is provided with a dependency graph, see Figures 2 and 3.

The following partitions are used: σ com1 = {{DKU 1, CM C1, IRS1, RA}}; σ ¬com1 = {{M F D1, CM C2, P M C1, P M C2}}; p com1 = {σ com1 , σ ¬com1 }.

The path of the informations "RA mode on" and "RA alert" on copilot side defines another decomposition: σ com2 = {{CM C2, IRS1, RA, DKU 1}}; σ ¬com2 = {{M F D1, CM C1, P M C1, P M C2}}; p com2 = {σ com2 , σ ¬com2 }.

We describe the decomposition d com = {p com1 , p com2 } on Figures 4 and 5. We compute partitions with the navigability functionality and this structural decomposition:

User interfaces

The panels are displayed one after the others for each step of the algorithm defined in the Controller. The flow of the functional chain described by the partition must be checked. As described in the case study, it gives insights about the possible connections, wiring and, routing that can be wrong. We compute the results ∆ = { IRS1, DKU 1, CM C2, RA } and display them on Figure 11. If some components are unfaulty, we can update their status in Figure 9. The algorithm is relaunched using the "GO" button in Figure 9. The good diagnosis rate is evaluated on Figure 12. It is defined by the number of faulty components that the operator has to fix over the number of proposed faulty components.

Discussion

We have proposed a solution for the diagnosis of a complex system in aeronautics based on the MBD paradigm and the Figure 12: Good diagnosis rate lattice concept. It is an other solution for the meta-diagnosis problem as described in [5] since we consider the test system environment as the main system. Belard has extended the framework, here we use the original one with the lattice concept to represent the system description. It is also provided a diagnostic algorithm implemented on the system to evaluate our method. Since hundreds of diagnosis are possible on the ATB, since it is not possible to check all those possibilities, we have introduced a methodology for the ATB diagnosis that reduce the number of iterations to get the diagnosis. We have upgraded the applications of MBD for avionics systems evaluated in [4] and [2]. It is proposed the integration and evaluation of a diagnostic algorithm for an ATB, taking the test systems environment into account. It differs from other applications of MBD like [8] because the model decomposition is driven by the test systems specificities that are represented with the lattice concept.

Conclusion

This paper extends the MBD approach to propose a diagnostic software that is developed for the diagnosis of test systems. The current framework is based on the lattice decomposition and is used to model a test system. First, the lattice decomposition has been used to decompose the system into its functionalities and connections. The second contribution consists in the proposal of an algorithm that reduce the diagnostic ambiguity. The lattice description has been implemented with JAVA native packages. The software architecture and diagnostic iterations are provided for a formal example and an industrial case study. The diagnostic algorithm has shown to reduce the number of faulty candidates. The results is either faulty equipment or a group of equipments with the associated system functionality that is unable to meet its goal. Together, they are sufficient to point out the reparations that will fix the system. The tests on the Avionics Test Systems in AIRBUS HELICOPTERS have shown good results. The development of models may confront our solution to many others real problems. In future works, algorithms will be improved with adaptable decompositions and automatic tests. Furthermore, as the method is generic, we want to demonstrate the validity of our method for others test systems used in AIRBUS HELICOPTERS.