AFDX(avionics full duplex switched ethernet)作为目前大型飞机的主干通信网络，其安全性尤为重要。近年来，故障检测和诊断技术在机载通信设备中已有应用，但AFDX网络设备监控诊断方法大多在机上无法快速搭建网络验证环境，更难以实现飞行状态下实时监控，并且需要专门的检测工具，而且诊断工具价格昂贵。本文研究如何在机上已有环境下对AFDX网络设备运行状态进行实时监控，同时结合故障检测和诊断技术，提供更加可靠的故障报警依据，以此降低AFDX网络设备管理的人力成本、时间成本和维护成本。本文贡献如下：

1) 给出故障和故障类型的定义，为每类故障类型设计合理的故障特征参数标识故障类型，并给出检测结果和故障特征参数的关联关系；

2) 针对检测中的数据采集环节设计一级筛选二级缓存的数据存储管理方法。改进了传统的基于被动式采集故障诊断方法，并进行分析验证；

3) 研制了一套针对AFDX网络设备异常状态监控的工具，覆盖每类故障的验证范围，并进行相应的实验验证。

1 相关工作

目前常见的故障诊断方法主要有以下5种：

1) 基于解析模型的方法，其思想是利用检测到的信息与解析模型得到的先验信息做残差分析再获取故障诊断的结果^[1]。目前仍有许多故障诊断研究使用解析模型中的状态估计法^[2]、参数估计法^[3]以及等价空间法^[4]等;

2) 基于数据驱动诊断方法，其通过采样数据进行建模^[5]。基于数据驱动的诊断方法常用的有3种。第一种是基于信号处理的方法^[6]，该类方法通过监测可测信号的输入和输出，分析振幅、相位、方差等特征值的变化，进而诊断出系统中的故障^[7]。第二种是基于统计分析的方法^[8]。第三种是基于机器学习的方法^[9];

3) 基于知识的检测方法，根据先验知识，建立所有故障事件的推理模型进行故障诊断^[10]，领域知识包括专家系统、故障树等。

4) 基于数据挖掘的方法能够在大量的网络流量数据中找到潜在的相关参数之间的关系^[11]，从而检测异常;

5) 基于网络演算的方法常用于网络性能诊断^[12]，其原理基于非线性代数确定性排队理论以及最小加代数和最大加代数的计算，能够实时评估设备的性能状况^[13]。但由于网络演算能够对节点的性能进行实时分析，该方法也可以运用于网络故障诊断中^[14]。

目前，国内外的一些科研团队和科技公司开发了相应故障诊断系统和方案平台，部分产品已进入市场，具有非常大的应用价值。例如，由惠普公司的OpenView系统所提供的故障诊断服务^[15]，通过轮询实现网络设备的运行状态控制，并以此做出故障告警^[16]；Cabletron公司的Spectrum网络系统，提出了基于案例推理的故障诊断方法^[17]，检查不同的网络对象和事件，归纳出同一本质或故障^[18]。SMARTS公司提供的产品InCharge是基于编码本的诊断方法^[19]。美国IBM公司开发的TivoliNetView是通过对设备进行性能轮询和状态轮询进行诊断，但容易导致故障响应的延迟，且不能找出相关故障的内在联系^[20]。北京游龙网网络科技有限公司研发的SiteView NNM是基于SNMP^[21]的网络设备管理软件，它可以管理所有主流厂商的各种设备，能够实时获取网络设备的信息^[22]。

近年来，虽说故障检测和诊断技术在机载通信设备中已有应用，但目前为止，AFDX网络设备监控诊断方法大多在机上无法快速搭建网络验证环境，更难以实现飞行状态下实时监控，并且需要专门的检测工具，而且诊断工具价格昂贵。王竹清等^[23]设计了一种采用并联方法进行数据采集监控的方法，通过监控设备、数据汇聚设备和数据分析设备完成网络监控，故障的诊断全部集中到数据分析设备中，提取网络设备中所有通信数据进行分析，该方式存在较大延时且占用大量带宽。景文君等^[24]借鉴航电系统向机载维护系统实时上报健康状态并对启动自检命令做出响应的机制，通过FIDO软件对机载软件进行监控并实时获取维护数据。中国电子科技集团公司通过机内测试和自动测试装备联合进行故障诊断^[25]，当设备发生故障时，需要根据机内测试的报告，将异常部件取出，采用自动测试装备继续检测^[26]，这种离线方法的诊断效率低、成本高、时间长，且机内测试自检覆盖面不够，机载设备的大部分故障不能检测，存在虚警的问题^[27]。

本文研究面向AFDX网络层面的故障监控和诊断，应用智能化的故障诊断方法和监控机制，解决当前机载网络监控难以保障实时性、额外的检测设备昂贵等复杂问题，设计并实现了AFDX网络设备监控诊断工具，用于对机载网络的运行状态、健康状态进行实时的监控、管理和维护。

2 AFDX网络设备故障监控诊断技术 2.1 故障和故障类型的定义

本文将AFDX网络设备常见故障进行分类，给出5类故障类型的定义，并在此基础上，总结分析了共计23种故障及其故障特性。

定义1  关键器件故障   该类故障指在网络设备中处于管理控制或通信地位的元器件发生损坏，关键器件共11种，主要包括RTC、FLASH、CPU、SDRAM、DPRAM、硬件端口状态、PCI总线，针对交换机额外选取管脚编程、默认应用程序及配置表、交换机芯片、引导代码。

定义2  物理层故障   该类故障是指网络设备本身的接口故障和连接交换机的物理链路故障。当接收端接收数据帧时出现以下3种情况时指示物理层故障：①字节非对齐；②CRC错误；③接收到相同的数据帧。

定义3  VL链路层故障   该类故障是指VL链路层中提供的虚拟链路技术、流量整形模块、完整性检查模块、冗余管理模块和发送接收控制模块功能失效，导致VL虚拟链路层无法或错误提供服务，无法保障AFDX网络数据传输的确定性和可靠性。

定义4  UDP/IP层故障   该类故障是指UDP/IP网络协议的配置或操作错误、IP分片功能失效等。

本文定义的物理层故障、VL虚拟链路层故障、UDP/IP层故障类型的具体故障特性如表 1所示。

定义5  设备性能故障   该类故障是指网络设备高负载状态导致存储和处理数据的能力不足、速率下降，进而导致网络拥塞、数据丢包问题。本文探究网络设备性能故障的指标包括CPU利用率、内存占用率、带宽的利用率以及缓冲区满标识。

2.2 故障检测方法

本节通过被动式采集方式对关键元器件、通信过程以及设备性能进行状态检测，获取当前设备的运行状态数据，设计合理的数据存储管理方案保存获取的数据，并根据数据解析定义指示故障类型的特征参数。

2.2.1 网络设备运行状态检测

本文选取PBIT对关键器件的状态进行测试。PBIT是BIT的一种，在设备的工作过程中周期性地进行检测。执行测试项时，根据测试结果将对应的位清零或置1。表 2是BIT检测项及检测方法的描述，其中0表示检测结果正常，1表示出现故障。

2.2.2 通信过程的状态检测

在AFDX网络中，与底层关键器件的故障不同，物理层、VL虚拟链路层、UDP/IP层构成网络协议、流量整形、缓冲管理、分组调度等通信网络运行规则，捕获并存储网络设备运行过程中实际发送和接收的原始通信数据，通过有效的协议分析可以反映数据在各层传输的通信过程。对其进行有效性的统计可观测网络的错误，完成网络故障的类型确认。针对2.1节所述的故障类型，结合状态检测的方法，本文将关键器件故障的故障特征参数用0和1表示，0表示当前检测结果为正常，1表示当前检测结果为故障。

2.2.3 网络性能状态检测

网络中某一时刻的CPU利用率、内存占用率、带宽利用率并不能直接反映网络中某一段时间的网络性能，因此，为体现设备当前的负载状况需要对一段时间内的性能数据进行采样处理。网络状态检测程序对设备该段时间内的网络性能参数进行抽样统计之后, 才可以得到网络在本段时间内的性能。

2.3 故障诊断方法

本文设计了基于多链路分组技术的网络演算算法, 用于验证机载网络的实时性和确定性。但网络演算的方法并不能明确表明故障的具体问题，因此本文将其运用于异常分析中，提出了一种综合诊断的方法。

2.3.1 设备通信异常诊断方法相关定义及描述

本文基于网络演算理论建立了针对设备通信异常的诊断方法。首先，将AFDX网络抽象为有向图G=(V, E)进行建模。其中，V={v}为网络中的设备集，包括AFDX网络中的端系统和交换机。E={e_ij|v_i, v_j∈V}为设备v_i指向设备v_j的弧，其中v_i称为弧尾，v_j为弧头。则弧v_i→v_j表示v_i到v_j存在数据流。将[0, t]时间内的总数据量表示为R_ij(t)，则弧尾v_i在时间[0, t]内的输入过程记为R_{i, in}(t)，计算过程表达为

(1)

式中：N_{i, in}为发送数据到弧尾v_i的设备集，即N_{i, in}={v_i|e_ij∈E}。

(1) 式中，输入过程的数据量由设备集N_{i, in}发送数据到v_i的所有数据量求和得到。同理，当v_i作为弧头时，在时间[0, t]内的输出过程记为

(2)

式中：N_{i, out}为接收来自弧头v_i数据的设备集，即N_{i, out}={v_j|e_ji∈E}。

(2) 式中，与输入过程相反，输出过程的数据量由v_i发送数据到设备集N_{i, out}的所有数据量求和得到。

服务曲线是对网络设备的服务能力进行描述，从而对流的输入、输出行为进行限制和描述^[28]。

定义1  服务曲线S(t)

若设备的输入过程为R_in(t)，设备的输出过程为R_out(t)，则当存在函数S(t)满足R_out(t)≥(R_in⊗S)(t)时，称S(t)为设备的服务曲线。其中，当设备v_i正常工作时, 为数据流提供的服务曲线函数为^[24]

(3)

式中：S_i(t)为设备v_i的服务曲线函数；r为设备服务的最低速率；τ为设备开始服务的最大时延。

(3) 式中，服务曲线S_i(t)表示设备服务能力的下界。

不同设备(端系统或交换机)的性能等参数不同，可能导致网络设备的服务曲线形态有所变化，但不影响对其异常情况的分析。

2.3.2 设备通信异常类型及诊断算法

通过上述定义及描述，设备正常服务时输入、输出过程满足为R_out(t)≥R_in(t)⊗S(t)，发送的数据总量不超过接收的数据总量，即R_out(t)≤R_in(t)。设备正常服务时对于数据积压也有限制，当数据积压过大时，设备性能下降不在正常服务状态范畴。因此需满足在设备正常服务的任一时间段内输入的累计数据量不大于最低服务速率下服务的数据量总和，表示为在时间(s, s+t]内有

(4)

且输入过程R_in(t)是严格单调递增的，即

(5)

基于公式(5)，设备服务正常时的输入输出过程如图 1所示。

图 1中，输入过程与输出过程基本吻合。此时，设备通信异常诊断问题转化为判断检测设备v_i的输入过程R_in(t)和输出过程R_out(t)，即当在时刻t不满足公式(4)时，则设备v_i在[0, t]内存在异常。

在设备通信的异常诊断中，将非正常工作状态分为以下3种异常情况：无服务、服务减慢、错误服务，诊断以上3种异常的算法时间复杂度均为O(1)。

1) 无服务通信异常类型分析

无服务指设备不再对数据流提供服务，不再向网络系统中发送数据。此时对任意形式的输入过程和任意积压，在无服务(s, s+t]期间，均有

(6)

同时，在无服务期间不保存接收的数据。若时刻s+t恢复服务则对s+t后接收的数据服务。设备无服务时的输入输出过程如图 2所示。

在时间段的中段，输出过程数据量停止增加且保持到该时间段结束，表明设备发生无服务异常，此时的判定条件为：若在时刻s出现R_out(s) < (R_in⊗S)(s)且R_out(s+t)-R_out(s)=0判定设备在时刻s无服务，若在时间(s+τ, s+t]不满足R_out(t)≥R_in(t)⊗S(t)则判定设备在时间(s, s+t]内无服务。

2) 服务减慢通信异常类型分析

服务减慢指设备为数据量服务的速率远小于数据输入速率。此时对任意形式的输入过程和积压，在服务减慢(s, s+t]期间，存在r₀>0满足

(7)

发生设备服务减慢时的输入输出过程如图 3所示。

图 3中，在时间段的中段，输出过程数据量增加缓慢，与输入过程的数据量相比，随着时间变化差距变大，表明设备发生服务减慢异常。因此，对于设备服务减慢判定条件为：若在时刻s出现R_out(s) < (R_in⊗S)(s)且R_out(s+τ)-R_out(s)>0时判定设备在时刻s服务减慢，若在时间不满足R_out(t)≥R_in(t)⊗S(t)则判定设备在时间(s, s+t]内服务减慢。

3) 错误服务通信异常类型分析

错误服务指设备大量发送与输入过程无关的数据。此时对任意形式的输入过程和积压，在错误服务(s, s+t]期间，存在

(8)

发生设备错误服务时的输入输出过程如图 4所示。

从图 4可以观察到，在一定时间段内，输出过程在该时间段某一时刻，输出数据量超过输入数据量，且随时间增长。表明设备发生服务错误异常，判定条件为：若在时刻s出现R_out(t)>R_in(t)时判定设备在时刻s错误服务，若在时间不满足R_out(t)≤R_in(t)则判定设备在时间(s, s+t]内错误服务。

设备输入输出过程都是通过数据包的形式，因此，为了建立连续的输入输出过程模型，本文设置了一个采样周期，该采样周期远大于连续发送2条消息的时间间隔，且采样周期保持不变。因此，离散的输入输出过程可以被视为连续的，不影响检测结果。

基于上述3种通信异常类型分析，本文使用type值表示设备状态，其中，0为正常，1为无服务，2为服务减慢，3为错误服务。设备通信异常类型诊断算法如Algorithm 1所示。

Algorithm 1. Node communication abnormal diagnosis

Input：R_in——the input process after sampling

R_out——the output process after sampling

δt——sampling period

t_delay——after the sample delay

Output：type

1. l_lowbound←0;

2. t←0;

3. type←0;

4. l_lowbound←min(l_lowbound+rδt, R_in[t-t_delay]);

5. if (l_lowbound>R_out[t] and R_out[t]==R_out[t-1]) then

6.   type←1;

7. else if (l_lowbound>R_out[t] and R_out[t]>R_out[t-1]) then

8.   type←2;

9. else if (R_out[t]>R_in[t]) then

10.   type←3;

11. end if

Algorithm 1中，输入过程R_in和输出过程R_out均为采样后的结果，δt为采样周期，delay为采样后的延迟。首先，初始化下界、时间、状态为0。由于当前type类型码为0，通过公式(9)更新下界。

(9)

式中：l_lowbound为累积数据下界/bit；r为设备服务的最低速率。

若更新后的下界大于当前时刻t的输出过程且当前时刻t的输出过程与前一时刻t-1的输出过程相等，则判定状态为1，即设备服务停止。若更新后的下界大于当前时刻t的输出过程且当前时刻t的输出过程大于前一时刻t-1的输出过程，则判定状态为2，即设备服务缓慢。当输出过程大于输入过程时，更新type类型码为3，即认为此时发生设备错误服务。若均不满足上述情况，认为当前设备通信状态正常。

2.3.3 异常恢复的诊断算法

由于部分干扰而产生的偶发异常对于设备来说不必进行维护和处理，通过检测出设备从异常恢复正常状态的时间，对比发生异常的时间可获悉偶发的异常现象。

在判定设备通信产生异常后，进入后续的异常恢复检测过程，首先在时刻s对输入过程和输出过程进行初始化：

(10)

在设备异常服务恢复的诊断中，分为以下3种异常情况：设备无服务恢复、设备服务减慢恢复、设备错误服务，诊断以上3种异常的算法时间复杂度均为O(1)。

1) 设备无服务恢复算法

设备从无服务到恢复正常的判定条件为：s时刻处于服务停止状态，若∃t>0, R_out(s+t)-R_out(s)>0时，表明设备已开始发送数据，判定设备在时刻s+t恢复正常，若在时间(s+τ, s+t]满足∀a∈(s+τ, s+t], R_out(s+t)-R_out(s)>0，表明设备恢复服务，则判定设备在时间(s, s+t]内恢复正常。Algorithm 1判定后，此时，type类型码为1，根据Algorithm 2进行恢复正常状态诊断。

Algorithm 2. Node service stopped

Input：R_in——the input process after sampling

R_out——the output process after sampling

Output：type

1.l_lowbound←0;

2. t←0;

3. type←1;

4. if (R_out[t]>R_out[t-1]) then

5.   R_in←R_in-R_in[t];

6.   R_out←R_out-R_out[t];

7.   l_lowbound←0;

8. end if

Algorithm 2中，输入过程R_in和输出过程R_out均为采样后的结果，在1~3行，对下界、时间、状态分别初始化。当时刻t的输出过程大于前一时刻t-1的输出过程时，分别更新输入过程、输出过程和下界。如5~7行所示。

2) 设备服务减慢恢复算法

设备从服务减缓到恢复正常的判定条件为：s时刻处于服务缓慢状态，若∃t>0, R_out(s+t)-R_out(s)>rt时，表明设备发送速率增加，则判定设备在时刻s+t已恢复正常，输出过程满足∃a∈(s, s+τ], b-a, R_out(b)-R_out(a)>r(b-a)。此时执行恢复算法如Algorithm 3所示。

Algorithm 3. Slow node service

Input：R_in——the input process after sampling

R_out——the output process after sampling

δt——sampling period

t_delay——after the sample delay

T₀——after sampling normal continuous upper bound

Output：type

1. l_lowbound←0;

2. t←0;

3. t_con←0;

4. type←2;

5. l_lowbound←min(l_lowbound+rδt, R_in[t-t_delay]);

6. if (R_out[t]-R_out[t-1]>r×t_delay) then

7.   type←1;

8. end if

9. if (l_lowbound < R_out[t]) then

10.   if (t_con≥T₀) then

11.    type←0;

12.    t_con←0;

13.   else

14.    t_con←t_con+1;

15.   end if

16. else

17.   t_con←0

18. end if

Algorithm 3中，δt为采样周期，delay为采样后的延迟。初始化正常持续时间为0，状态为2，如第3~4行所示。接下来通过公式(11)更新下界。

(11)

式中：l_lowbound为累积数据下界/bit；r为设备服务的最低速率；δt为采样后周期；t_delay为采样后的时延。

如第6行所示，若当前输出过程与前一时刻输出过程的差大于设备服务的最低速率与采样后时延的乘积，则更新type类型码为1。若下界小于当前输出过程且正常持续时间大于正常持续时间上界，更新type类型码和正常持续时间为0。若下界小于当前输出过程而正常持续时间小于等于正常持续时间上界，将正常持续时间加1。否则，正常持续时间继续保持为0。

3) 设备错误服务恢复算法

设备从错误服务状态到恢复到正常服务状态应满足：在时刻s初始化，若∃t>0使得初始化后的输入输出过程在(s, s+t]内满足R_out(t)≤R_in(t)时，表明设备发送的数据小于接收的数据，从时刻s后由错误服务状态恢复为正常服务状态。具体过程如Algorithm 4所示。

Algorithm 4. Node error output

Input：R_in——the input process after sampling

R_out——the output process after sampling

δt——sampling period

t_delay——after the sample delay

T₀——after sampling normal continuous upper bound

Output：type

1. l_lowbound←0;

2. t←0;

3. t_con←0;

4. type←3;

5. if (t_con==0) then

6.   R_in[t]= R′_in[t];

7.   R′_out[t]=R_out-R_out[t];

8.   l_lowbound←0;

9.   t_con←0;

10. end if

11. if (t_con>0) then

12.   l_lowbound←min(l_lowbound+rδt, R′in[t-t_delay]);

13.   if (R′_in[t] < R′_out[t]) then

14.    if (t_con≥T₀) then

15.      R_in=R′_in;

16.      R_out=R′_out;

17.      type←0;

18.      t_con←0;

19.    end if

20.   end if

21. end if

Algorithm 4中，前3行与算法3一致，初始化下界、时间、正常持续时间为0，状态为3。若正常持续状态为0，则更新输入输出过程。并将下界、正常持续时间重新赋值为0。若正常持续时间大于0，通过公式(11)更新下界。在t时刻，若初始化后的输入过程小于输出过程，且正常持续时间不小于采样后正常持续时间上界，则使用初始化后的输入输出过程更新输入输出过程。同时，置type类型码和正常持续时间为0。

2.3.4 基于通信数据的异常诊断流程

网络故障诊断不仅仅是检测网络连通与否、当前设备是否通信异常，而需要用更为具体的标准去衡量和判别当前网络的故障问题。在网络设备的运行状态检测中已完成数据帧的捕获和存储，而设备通信异常诊断提供通信异常的时间点，因此故障类型分析就是提取该时间点前后存储的历史数据帧，对数据帧进行校验，通过统计相应特征参数反映当前网络的具体故障问题。本文提出的基于通信数据的异常诊断流程如图 5所示。

3 实验验证 3.1 网络设备故障诊断实验流程

故障诊断实验分为发生异常诊断阶段和异常恢复的诊断阶段。故障诊断流程如图 6所示。首先根据设备的输入输出过程建立设备通信异常诊断，分析设备是否发生异常以及何时发生异常，当发生异常时通过查询历史的通信数据诊断出具体的故障类型。当发生异常后才进入异常恢复诊断流程，重置输入输出过程，根据异常类型进行相应的异常恢复检测，当诊断为异常恢复后可停止故障类型分析过程，降低资源消耗。

3.2 网络设备故障诊断测试用例设计 3.2.1 状态检测测试用例设计

状态检测测试用例主要测试对注入的关键器件故障、通信过程故障、设备性能故障能否准确进行检测，具体测试用例集如下：

状态检测测试用例集的标识为NMDF_Test_01，模块名称为状态检测。

测试项分别为：①检测器件功能；②获取设备性能参数；③数据帧捕获；④更新故障参数。

测试输入为系统控制句柄(包括初始化结果和系统状态等信息)。

针对该类用例集合的测试步骤为：①输入系统控制句柄；②调用状态检测主接口，依次启动器件检测线程、数据帧捕获检测线程和获取设备性能参数的线程；③更改系统状态为激活状态；④注入硬件端口故障、FLASH故障、VL错误的数据帧、MAC源地址错误的数据帧；⑤根据检测结果，更新故障参数。

期望的测试结果为: ①系统状态为未激活时，状态检测线程挂起，不执行检测操作；②未注入故障之前，所有故障参数均为0；③注入故障之后硬件端口故障参数、FLASH故障参数计数均为1，缓冲区中tail的值+2。

3.2.2 故障诊断测试用例设计

故障诊断测试用例主要测试能否诊断发生异常以及异常恢复，并能在发生异常时进行故障类型的分析。具体测试用例集如下：

故障诊断测试用例集的标识为NMFD_Test_02，模块名称为故障诊断。

测试项分别为：①加载诊断策略；②异常类型诊断；③异常恢复诊断；④数据帧解析和特征参数统计；⑤诊断结果生成。

测试输入为系统控制句柄、故障参数。

针对该类用例集的测试步骤为：①输入系统控制句柄和故障参数；②将系统状态改为策略加载状态；③调用故障诊断主接口，开启异常诊断线程；④将系统状态改为激活状态；⑤依次注入设备无服务异常、减缓服务异常、错误服务异常，并同时注入VL错误和MAC源地址错误的数据帧。

期望的测试结果为：①系统状态为策略加载状态时，故障诊断线程挂起，不执行诊断操作；②系统状态为激活状态时，开始异常诊断，检测到异常发生的时间，并生成诊断结果；③故障类型分析正确执行；④诊断结果与累计的故障特征参数与实际注入的故障相符；⑤成功检测到异常恢复的时间，并停止故障类型分析。

3.3 实验结果

为保证AFDX网络设备监控诊断工具可以在机载软件系统上正常运行，本文从实时性、并发性等方面对工具进行非功能性测试，以确保工具自身满足机载软件的要求。

1) 实时性测试

实时性是机载软件质量的重要评价指标，本文通过“程序插桩”来计算各功能的运行时间。本文插桩主要记录程序运行时刻，具体测试方案及结果如表 3所示。

2) 并发性测试

AFDX网络设备监控诊断工具包含多进程和多线程，本文通过模拟运行时情况来测试工具的并发性，具体测试方案及结果如表 4所示。

4 结论

本文是根据机载故障诊断的局限性以及AFDX网络故障诊断的复杂性等问题，结合实际的项目需求，研究了AFDX网络设备监控诊断技术方案，并设计实现了AFDX网络设备监控诊断工具，可以很大程度上拓宽机载维护的范围，能在网络层面上进行监控，降低虚警概率，提高了诊断效率，能够实现对AFDX网络的实时监控和诊断。