This paper addresses Model Based Diagnosis for the test of avionics systems that combines aeronautic computers with simulation software. Just like the aircraft, those systems are complex since additional tools, equipments and simulation software are needed to be consistent with the test requirements. We propose a structural diagnostic framework based on the lattice concept to reduce the time of unscheduled maintenance when the tests cannot be performed. Here, we also describe a diagnosis algorithm that is based on the formal lattice description and designed for test systems. The benefits is to capture the system structure and communication specificities to diagnose the configuration, the equipments, the connections, and the simulation software.
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 [
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. [
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 [
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. 2 2.1
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, P1 is associated with a functionality of the system P1 = {σ1; σ2}, σ1 = {C1} and σ2 = {C2, C3}. 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 ci for a component. S = {ci, 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 np subsystems σi ∈ Σ: P = {σi, i ∈ [1, np]|∀i 6= j; σi ∩ σj = np ∅, and S σi = S}. We note P the set of all partitions.
i=1 We recall the definition 1 of inclusion relation between partitions and the definition 2 of multiplication. σi ∩ σj .
Definition 1. Two partitions P1 and P1 are said to be in inclusion relation P1 ⊆ P2 if and only if every subsystems of P1 is contained in a subsystem of P2. The relation ⊆ means that P1 is a sub-partition of P2.
Definition 2. The subsystems σk of the multiplication of two partitions P = {σi, i ∈ [1, np]} and Q = {σj , i ∈ [1, nq]} are defined by: ∀σk ∈ P × Q, ∃σi ∈ P, ∃σj ∈ Q, σk =
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. 2.2
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 thecheckS 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 ci 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 ) 6= −1.
Once the checkP value of a partition is known, we have to define thecheckS function of subsystems that are not singletons σi 6= {ci}. If the partition is faulty, either it exists a component ci ∈ σi such as checkC(ci) = 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 6= {ci} are unfaulty and all singletons σi = {ci} 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 ⇔ ∀ci ∈ σi, checkC(ci) = 1 ∧ checkCom(σi) = 1 ; checkS(σi) = 0 ⇔ ∃ci ∈ σi, checkC(ci) = 0 ∨ checkCom(σi) = 0 and checkS(σi) = −1 ⇔ ∃ci ∈ σi, checkC(ci) = −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 ) 6= −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 Ci modeled with checkC(Ci) = 0, and the communication fault of a subsystem σi = {Ci, Cj , ...} modeled with checkCom(σi) = 0. With the P1 partition, suppose that C2 and C3 are linked with an ARINC 429 link that is not working. The constraint is checkP (P1) = 0 because the global function is broken. The reason is that checkCom(σ2) = 0. Knowing that checkCom(σ2) = 0 for the P1 functionality is giving the information to fix the system.
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 ∈ P2, 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 {pi, i ∈ [1, n]} and the constraints Cons = {P ∈ P, checkP (P ) 6= x}.
F indF aultyElements checks the partitions that are defined as a constraint. If the checked value of a partition pmult 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 pmult 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 Fc with the checkC function, and the communication of the subsystems in Σ− with the checkCom function.
Two functions have been introduced: the checkP (pi) value of a partition pi 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 (pi) or CheckCom(σi).
In order to illustrate the problem formulation and the
diagnostic algorithm, a formal example is provided. It is
composed of eight components {Ci, i ∈ [
P3 describes the topology of the system. P1 and P2 describe functionalities. We set the C2 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
Input: d = {pi, i ∈ [1, n]}, Cons = {consi} Output: Δ(Diagnosis)
Fc(f aulty components), Uc(unf aulty components), Σ−(f aulty subsystems), Σ+(unf aulty subsystems), P −(f aulty partitions), P +(unf aulty partitions) Δ, Fc, Uc, P +, P −, Σ−, Σ+ ← {}; End ← f alse; N Cons ← {}; while ¬End do
F indF aultySubsystems(d, Cons); V erif ication(Fc, Σ−); if ¬End then foreach pi ∈ N Cons do
GET checkP (pi)
Cons ← Cons ∪ {pi} Algorithm 2: F indF aultyElements Input: d = {pi}, Cons = {consi} Outputs: Fc, P −, Σ−, Σ+ foreach (pj , pk) ∈ P 2 : pi 6= pj do pmult ← pj × pk if pmult ∈ Cons then if checkP (pmult) = 0 then
P − ← P − ∪ {pi} foreach σi ∈ pi do foreach ck ∈ Uc do
σi ← σi \ {ck} if σi = {ci} then
Fc ← Fc ∪ σi else if σi ∈/ Σ+ then
Σ− ← Σ− ∪ {σi} if checkP (pmult) = 1 then
P + ← P + ∪ {pi} foreach σi ∈ pi do if σi = {ci} then
Uc ← Uc ∪ σi else
Σ+ ← Σ+ ∪ {σi} if pmult ∈/ Cons then if ∃{ci} ∈ pmult then if ¬(ci ∈ Uc ∪ Fc) then
N Cons ← N Cons ∪ {pmult} 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 defineChoose : {P} → P × P. As the two functionalities are modeled by P1 and P2, and the the topology is modeled by P3, we have two possibilities. We assume that P2 is prior to P1, the first iteration is defined with Choose(P)=(P1, P3). We begin with checkP (P1×P3) = 0, s.a P1 × P3 = { { C1 }, {C2,C4}, {C3}, {C6,C8}, {C5,C7}}. The possible faulty component are C1 and C3. We check the C1 and C3 components and Algorithm 3: V erif ication
foreach ci ∈ Fc do if checkC(ci) = 0 then Δ ← Δ ∪ {ci}
End ← true else
Fc ← Fc \ {ci}
Uc ← Uc ∪ {ci} else foreach Σi ∈ Σ− do
GET checkCom(Σi) if checkCom(Σi) = 0 then Δ ← Δ ∪ {Σi} End ← true Σ− ← Σ− \ {Σi} Σ+ ← Σ+ ∪ {Σi} find them as unfaulty, see Tables 1. The possible faulty subsystems are {C2, C4}, {C6, C8} and {C5, C7} and they are unfaulty. The diagnosis is not sufficient, we must relax the constraint P2 × P3.
The second iteration is defined withChoose(P)=(P2, P3), s.a P2 × P3 = {{C1}, {C2}, {C4,C6,C8}, {C3,C5,C7}}. We get checkP (P2 × P3) = 0, the possible faulty components are C1 and C2 but C1 has already been checked in the previous iteration. So, the possible faulty subsystems are {C3,C5,C7} and {C4,C6,C8}. We check the C2 component and find it as faulty. For this example, the computed faulty or unfaulty components is, see Table 2, C2 in P2 × P3. If no components has been found faulty, the upper topological level is treated i.e subsystems: {C2,C4}, {C6,C8}, {C5,C7}, {C4,C6,C8} and {C3,C5,C7}}. Here, they are unfaulty.
Components
C1 C2 C3 C4 C5 C6 C7 C8
CheckC
1
−1
1
−1
−1
−1
−1
−1
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.
more than twelve national customers in over twenty
different basic helicopter configurations. The NH90 Avionics
System consists of two major subsystems: the CORE
System and the MISSION System. A computer is the bus
controller and manages each subsystem communications: the
Core Management Computer (CMC) for the CORE
System and the Mission Tactical Computer (MTC) for the
MISSION System. Each computer is connected to one or both
subsystems via a multiplex data bus (MIL-STD-1553), point
to point connections (ARINC429) and serial RS-485 lines.
Additional redundant computers are used as backup. One
of the two CMC is the Bus Controller (BC) of the CORE
multiplex data bus. The avionics system of the ATB is
composed of fourteen computers and the above
connections: two CMC: c1 = CM C1 and c2 = CM C2; two
Plant Management Computer (PMC): c3 = P M C1 and
c4 = P M C2; five Multifunction Display (MFD): c5 =
M F D1, c6 = M F D2, c7 = M F D3, c8 = M F D4,
c9 = M F D5; two Display and Keyboard Unit (DKU):
c10 = DKU 1, c11 = DKU 2; two IRS: c12 = IRS1,
c13 = IRS2; one Radio Altimeter (RA): c14 = RA.
Formally, COM P SAT B = {ci, i ∈ [
The avionics system under test COM P SSUT is a subsystem of COM P SAT B. It is described Figure 1. COM P SSUT = {c1, c2, c3, c4, c5, c10, c12, c14}. For the rest of the article, COM P SSUT will be the primary system under study. The PMC is used to monitor the status of all the avionics computers. It displays the alert informations on the MFD. We define the performances partition pP ERF = {σP ERF ,σ¬P ERF } with: σP ERF = {P M C1,P M C2,RA,IRS1,M F D1} σ¬P ERF = {CM C1,CM C2,DKU 1} and the navigation partition pNAV = {σNAV ,σ¬NAV } with: σNAV = { RA,IRS1,M F D1} σ¬NAV = {CM C1,CM C2,DKU 1,P M C1,P M C2}. 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); fromCM 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 display the alert and disable the functionality ("Alert" message). 3.2
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 pi 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} pSerial = {σSerial1; σSerial2; σ¬Serial} the ARINC communications: σARINC = {CM C1,CM C2,P M C1,P M C2,
M F D1,IRS1,RA} σ¬ARINC = {DKU 1} pARINC = {σARINC ; σ¬ARINC } the MIL-STD-1553 communications: σMIL = {CM C1, CM C2, P M C1, P M C2, IRS1} σ¬MIL = {M F D1, DKU 1, RA} pMIL = {σMIL; σ¬MIL} 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: {pNAV ,pP ERF }, connection partitions are: {pMIL, pSerial, pARINC }. We need to define additional partitions that can be checked with the check function on the system thanks to this representation: pNAV.MIL = pNAV × pMIL = {{M F D1,RA};{IRS1}; {CM C1,CM C2,P M C1,P M C2};{DKU 1}}; pNAV.Serial = pNAV × pSerial = {{CM C1, CM C2, DKU 1}; {P M C1, P M C2}; {M F D1, IRS1, RA}}; pNAV.ARINC = pNAV × pARINC = {{M F D1, IRS1, RA}; {CM C1, CM C2, P M C1, P M C2}; {DKU 1}}.
The performance function can give insights about the fault. We compute the partitions with this functionality: pP ERF.MIL = pP ERF ×pMIL = { {M F D1,RA}; {DKU 1}; {CM C1,CM C2}; {P M C1,P M C2,IRS1} } pP ERF.Serial=pP ERF ×pSerial = { {CM C1,CM C2, DKU 1}; {P M C1,P M C2}; {M F D1,IRS1,RA} } pP ERF.ARINC = pP ERF ×pARINC = { { P M C1, P M C2, M F D1, IRS1, RA};{CM C1, CM C2}; {DKU 1} }.
Those partitions will serve to improve the diagnosis. 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: pSUT can be decomposed into dprotocol = {pSUT × pMIL; pSUT × pSerial; pSUT × pARINC }. 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}}; pcom1 = {σ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}}; pcom2 = {σcom2 , σ¬com2 }.
We describe the decomposition dcom = {pcom1, pcom2} on Figures 4 and 5. We compute partitions with the navigability functionality and this structural decomposition: pNAV.com1 = pNAV × pcom1 = {{RA, IRS1}; {M F D1}; {CM C1, DKU 1}; {CM C2, P M C1, P M C2}}; pNAV.com2 = pNAV × pcom2 = {{RA, IRS1}; {DKU 1, CM C2}; {M F D1}; {CM C1, P M C1, P M C2}}; × pcom1 = {{RA, IRS1};
DKU 1}; {M F D1, P M C1, pP ERF.com1 = pP ERF {CM C2}; {CM C1, P M C2}}; pP ERF.com2 = pP ERF × pcom2 = {{RA, IRS1}; {DKU 1, CM C2}; {CM C1}; {M F D1, P M C1, P M C2}}.
4.1
An iterative approach is very helpful in this case of distributed systems since diagnosis can use new subsystems and partitions. The results of the diagnosis are re-injected in the upper system to refine the results. The first symptom is the misbehavior of the navigation functionality. We describe the iterations of the algorithms with two topologies. We have launched the metadiagnostic algorithm with the topology: dNAV.protocol = {pNAV.MIL,pNAV.ARINC ,pNAV.SERIAL} and dNAV.com = {pNAV.com1, pNAV.com2}. The constraint is CON S = {checkP (pi), ∀pi ∈ dNAV.protocol ∪ dNAV.com}. The iterations of the algorithms are described in Tables 4, and 5.
pi pNAV.ARINC pNAV.SERIAL pNAV.MIL checkP (pi) 0 1 0
Uc ∅ ∅ ∅
Fc {DKU 1} {DKU 1} {IRS1, DKU 1}
The third step gives a state of the components in Fc set that can be faulty: DKU 1 and IRS1 in Table 5. If the components are faulty, this may explain the system behavior and the algorithm ends. At the same time, the communications of subsystems in Σ− can be faulty. They are checked in Table 6.
The IRS1 is not faulty, the algorithm is relaunched with Uc = {DKU 1, IRS1} and the other decomposition dcom = {pNAV.com1, pNAV.com2}. The algorithm iterations are described in Tables 7 and 8.
Once checkP (pNAV.com2) = 1, we deduce that M F D1 is not faulty, see Table 7. At this step, the unfaulty components are {DKU 1, IRS1, M F D1}, and the diagnosis is {RA}.
Here the RA is faulty with pNAV.com1, and the algorithm ends. The solution is RA for pNAV.com1. The data flow of the messages are checked as the impacted connections, wiring and, routing. The system specificities of the communication modeled with com1 five clues of the possible checkP (pi) 0 1
Uc {DKU 1, IRS1} {DKU 1,
IRS1, M F D1}
Fc {RA, M F D1} {RA} faults. Thanks to the impacted functionality, we know that only messages concerning the IRS roll are concerned. At this stage, the simulation of the message or the bad connection of the IRS are the two main solutions.
We describe a new problem: the navigation functionality and the performance function do not behave normally. The new constraint is CON S = {checkP (pi), ∀ pi ∈ dNAV.protocol ∪ dNAV.com ∪ dP ERF.protocol ∪ dP ERF.com}. The algorithm is loaded from CheckM ultiplicationP artition with the decomposition dcom. The algorithm iterations are described in Table 9. Once checkP (pP ERF.com2) = 1, we deduce that CM C1 is not faulty.We continue with dprotocol knowing the CM C1 is not faulty in Table 10. We deduce that we have to check DKU 1 and CM C2.
pi pP ERF.com1 pP ERF.com2 checkP (pi) 0 1
Uc ∅ {CM C1}
Fc {CM C2} {CM C2}
At this state, we check the components on the system. Since the reparation of CM C2 has fixed the problem, we conclude that CM C2 has been faulty. We also check the DKU 1 configuration, and find nothing. The diagnosis is Δ = {CM C2}.
The evolution of the number of faulty and unfaulty components is reviewed on figure 6. As expected, the number of unfaulty components is increasing with new tests, i.e tests of partitions. It reveals that the algorithm is converging to a solution because the number of components is limited. 5 5.1
The algorithms are implemented in a spy software of ARINC and MIL-STD-1553 buses, see Figure 7. They are developed using C++ for effective diagnosis, and to be implemented in the AIRBUS software. The user interfaces are developed with Java 1.7 and the Swing Graphical User Interface (GUI) widget toolkit. The architecture of the diagnostic framework has been adapted to the ATB specificities as described with the Model-View-Controller (MVC) paradigm on Figure 8. Three main objects are defined for the Model: the Component, the Set, and the Partition objects. Four main objects are defined in the View to define specific panels: the diagnosisPanel, the constraintsPanel, the initialStatePanel and the resultsPanel objects. The model is implemented with the ArrayList class. It is used to define the list of components, the subsystems and the list of partitions. eXtensible Markup Language (XML) files have been used to describe the system structure. The Controller dispatches the user requests and selects the panels for presentation. The diagnosis algorithm is implemented in it. A GUI is provided for handling user inputs such as partitions check values and components observations values. The panels are displayed one after the others for each step of the algorithm defined in the Controller. The We have proposed a solution for the diagnosis of a complex system in aeronautics based on the MBD paradigm and the initialStateP anel panel, Figure 9 defines the status of equipments before launching the diagnosis and a button the run the algorithm. The check values computed by the algorithm defined in the Controller are provided to the operator in Figure 11. The constraintsPanel panel lets to edit and update constraints, see Figure 10. The result of the diagnostic algorithm is provided on Figures 11. It gives the faulty components (observation equal to zero) and the impacted functionality. If a component is suspected, the data 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.
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 [
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.
Arnaud Lefebvre, Zineb Simeu-Abazi, Jean-Pierre Derain, and Mathieu Glade. Diagnostic of the avionic