QAR数据（共3篇）
QAR数据 篇1
现代飞机均装有快速存取记录器QAR (Quick Access Recorder) , 其记录内容为128MB, 可连续记录时间达600h。目前国内航空公司大部分空客飞机使用的QAR设备已经改装为无线型式, 也就是无线QAR (WQAR) 。在每个航段结束后, 飞机上的WQAR装置会将记录的该航段数据发送到专门的服务器。维修部门可以通过译码软件从服务器上下载QAR数据并进行译码。
在QAR数据库中共记有232项与飞机有关的数据, 包括发动机、飞行操纵、起落架、导航等各个系统的重要参数。这些参数能为判断部件故障提供可靠的依据, 尤其是对一些在地面无法验证的项目, QAR数据能够印证故障分析, 缩短排故时间, 提高判断故障的准确性。
2014年12月, 一架A320飞机在昆明短停, 机组反映人工使用刹车过程中有不正常声音, 且机身有向左甩动的感觉;左起落架的刹车毂温度比右起落架的刹车毂温度高接近200℃。地面检查发现左起落架的两个刹车毂磨平;顶升左起落架, 两个主轮均能自由转动, 无异常响声;地面进行BSCU的BITE测试, 以及人工正常刹车操作测试, 测试结果均正常, 无故障信息。
由于航段报告P F R及测试结果均无故障信息, 无法从TSM中找到排故依据。从地面检查结果来看, 除了更换磨平的刹车毂之外, 没有其它工作可以做。但是该飞机的刹车系统的确存在着隐患, 如不彻底排除, 将会危机飞机安全。在这种情况下, 可以利用QAR数据来还原当时的刹车过程, 找出异常现象, 再结合系统原理分析其异常的原因。
在此次排故中, 我们从该航段的Q A R数据中, 提取了刹车脚蹬B R K_PED、刹车压力BRK_PRESS、刹车温度BRK_TEMP、轮速WHEEL_SPD等参数, 分别对这些参数做曲线图。通过图形比较, 我们发现左起落架主轮的刹车压力和刹车温度确实明显高于右起落架主轮。另外, 还发现一个异常现象:左侧刹车脚蹬的数值明显大于右侧。
针对这一异常现象, 我们从人工正常刹车系统的原理进行分析。机组踩下刹车脚蹬, 脚蹬变化程度通过脚蹬传感器转化为电信号, 传送给BSCU。BSCU再将其转化为控制信号, 控制每个主轮的正常刹车伺服活门的打开程度。伺服活门的开度越大, 供给刹车毂的液压压力就越大, 刹车效果越明显, 相应的刹车温度也就越高。也就是说, 当采用人工正常刹车时, 左侧刹车毂的刹车压力取决于左侧脚蹬的变化程度, 而右侧刹车毂的刹车压力取决于右侧脚蹬的变化程度。
通过上述分析, 我们可以确认, 左侧刹车毂温度高, 是由于左侧刹车压力大造成的;而左侧刹车压力大, 是由于BSCU接收到的左侧脚蹬信号大造成的。后续我们更换了脚蹬传感器, 并对左侧脚蹬机构进行了调节。当该机执行了新的航段后, 通过QAR译码对左右刹车脚蹬位置、刹车压力、刹车温度进行比较, 左右刹车脚蹬位置和刹车压力的曲线基本重合, 左侧刹车温度明显下降, 并且与右侧基本一致。
通过上述案例, 我们利用QAR译码以及系统原理分析, 将一个毫无头绪的故障, 非常迅速、准确的排除了。在日常维护工作, 我们应当学会利用QAR译码, 结合系统原理来分析飞机故障, 尤其是隐蔽性强的疑难故障。
摘要：本文通过一架A320飞机人工正常刹车系统故障的排故, 介绍了QAR数据结合系统原理的排故方法。
关键词：QAR,人工正常刹车,系统原理
参考文献
[1]李海然.排故中的QAR数据使用[J].航空维修与工程, 2010 (02) :47-48.
QAR数据 篇2
QAR数据通过机载的快速存取记录器 (QAR) 进行存储, 航后由地面机务维护人员取出交给数据分析人员[1]。QAR数据记录了飞机飞行的状态和性能参数, 是飞机状态监控和故障发现的重要参考依据。QAR数据量相当大且具有较强的时间性, 直接进行数据挖掘或相似性度量需占用大量时间和空间, 严重影响处理的效率。关于时间序列数据的挖掘, Keogh等人提出滑动聚集平均近似PAA[2]表示方法并指出其优点。由于时间序列符号化难以有效处理高维时序数据处理, Eammon博士提出了符号聚合近似SAX (Symbolic Aggregate approximation) 算法[3], 受到广泛关注。SAX符号化方法的优点使其在图像处理、生物信息、数据挖掘和机器学习等领域得到广泛应用。Jianwei Han等人提出的不产生候选项集的FP-Growth算法[4], 相对于经典Aprioi算法, 空间、时间上效率都有很大提高。关联规则广泛用于各个领域中, 如学生选课及学生成绩中的关联性分析[5]、战略绩效评估中的关联分析[6]、中药方剂配伍规律挖掘[7,8]、入侵检测[9]、遥感影像地物分类[10,11]等。子树匹配[12]源于字符串的子串匹配, 由于避免对频繁子串的大量重复查询而提高效率。对于海量数据的处理, 越来越多地用到前缀树, 例如XML数据应用[13]、下推自动机研究、网页聚类[14]、数据流检测[15]等。
本文首先对QAR数据进行预处理:通过PAA表示方法对数据进行初步压缩, 并通过SAX符号化降低数据的复杂度;然后根据FP-Growth算法建立适合符号化后的QAR数据的特殊FP-Tree;最后只保留FP-Tree的频繁前缀子树并与已有的故障模型数据进行子树匹配, 找出与当前测试数据最相近的故障数据类型。
1 QAR数据的预处理
1.1 QAR数据的初步压缩
QAR数据是从传感器获取的流数据, 其采样频率一般为每秒采样一次, 数据量相当惊人。因此本文采用滑动平均聚集近似[2]方法对数据进行初步压缩。由于所用数据源文件中的数据特点是多条数据共用同一个样本号, 因此本文通过动态计算每个样本号所囊括的数据条数作为PAA表示方法中滑动窗口的大小。
QAR数据是具有时间约束的时序数据, 其采样的样本连续升序编号, 动态计算滑动窗口的大小的过程也比较简单:对于数据序列Tij={T11, T12, T13, T21, T22, T31, …, Tn1, Tn2, Tn3}, i表示样本编号, 取值范围为1≤i≤n;j表示每个样本编号的第j条数据, 取值范围为所有正整数, 不过在本文所用数据中一般不会超过8。滑动窗口大小随着数据变化而变化, 如上数据序列Tij的窗口大小依次为{3, 2, …, 3}, 用PAA表示后序列变为:。图1为自动获取窗口大小的PAA方法的一个示例, 其中Sample列是样本号, 06Accel Vert是QAR数据的一个属性列。
1.2 QAR数据的符号化
由图1可见, 经过初步压缩处理的QAR数据属于连续的数值型数据, 在大数据量的情况下形成的序列数据依然复杂多变, 难以直接呈现出数据的内在规律, 本文通过对序列数据进行符号化处理, 原本复杂多变的数据序列就会变得直观清楚, 比较容易挖掘出频繁子序列。
Eammon博士提出的符号化聚合相似SAX表示方法首先对数据进行正规化处理, 然后采用PAA方法对标准化后的序列进行数据压缩[16,17], 最后再对压缩后的数据进行离散化, 实现将数值序列转化为符号表示。本文在1.1节中已经使用PAA方法对数据进行了初步压缩, 在这里只需实现SAX的最后一步, 将数值序列转化为符号表示即可。本文使用式 (1) 对数据进行符号离散化:
其中Scope是数据离散化的上限值, 即序列中每个元素经过离散后的值都是介于0~Scope之间的整数。max, min是给定的最大最小值, Ti是原数据序列的元素, T'i是符号化后代表Ti的符号, 则初步压缩后的数据序列经符号化后由Ti={T1, T2, …, Tn}变为新的符号序列T'i={T'1, T'2, …, T'n}。例如QAR数据序列段T13={0.95, 0.948, 0.9435, 0.947, 0.9465, 0.952, 0.9494999, 0.9485, 0.936125, 0.933375, 0.9445001, 0.9455, 0.958}, 经符号化为0~20之间的数据后T'13={10, 10, 9, 10, 10, 11, 10, 10, 8, 8, 10, 10, 11}。
2 QAR数据的频繁子序列发现
2.1 FP-Growth算法
关于频繁模式挖掘的经典算法Apriori算法产生的候选项集有可能是灾难性的, 由此, J.Han等人在文献[4]中, 介绍了不用产生候选项集的FP-growth算法。FP-growth算法基于一种称为FP-tree的树形结构, 通过将数据集的全部信息无损地压缩到FP-tree中, 然后再调用FP-growth算法递归的挖掘FP-tree, 来找出所有满足预先设定最小阈值的频繁项集。
频繁模式树FP-tree的构造算法如下:
(1) 扫描D一次, 产生频繁项目集合F及其支持数。按其支持数降序排列F, 生成频繁项目列表LF。
(2) 创建FP-tree的根节点, 标号为“null”。对于D中的每个事务Trans作如下处理。①按LF中的次序排列Trans中的频繁项目, 设排列后的结果为[p P], 其中p是第1个项目, 而P是剩余项目的列表;②调用insert_tree ([p P], T) ;③如果P非空, 递归调用insert_tree (P, N) 。过程insert_tree ([p P], T) 的执行情况如下:如果T有子女N使得N.node-name=p, 则N的计数增加1;否则创建一个新节点N, 将其名称node-name、计数node-count分别设置为p1, 由父节点指针node-parent链接到它的父节点T, 并通过节点链node-link将其链接到具有相同名称node-name的节点。
2.2 对QAR数据建立FP-Tree
1) QAR数据子序列的获取
QAR数据作为时序流数据, 每个数据文件都是一个包含着无数子序列的数据序列, 对于一个长度近乎无限而其元素的取值范围是有限集合的序列来说, 显然其有限长度的子序列很容易成为频繁子序列, 但这些子序列大部分都不是前后紧密相连子序列, 依然丢失了大量的时间信息及数据间的关联关系, 令数据挖掘的结果的价值大量流失。为保证不破坏数据内部关系, 本文只对数据截取紧密相连的定长子序列集, 采用FP-Growth算法在不产生大量候选项集的前提下, 挖掘出既能反映数据整体规律又不失数据内部关联的频繁子序列集。
子序列集通过对原始序列进行定长截取, 例如对于序列Ti={T1, T2, …, Tn}, 提取长度为m的子序列集S, 则S={S1, S2, …, Sn-m}, S的每个元素都是一个子序列Si={Ti, Ti+1, …, Ti+m-1}, i=1, 2, …, n。
2) 对子序列集建立FP-Tree
由原始数据序列截取获得的子序列中的各个元素是严格按照时间顺序排列的, 不能在处理过程中对其顺序进行改变, 因而从原始数据截取获得的子序列集S就相当于已经按照降序排列的项目列表, 可以直接开始第二步对子序列集S创建FP-Tree。如下示例对原始序列Tij创建FP-Tree:
给定原始序列T13={10, 10, 9, 10, 10, 11, 10, 10, 8, 8, 10, 10, 11}子序列定长为4, 创建FP-Tree过程如下:
(1) 对Ti进行定长截取得到子序列集S={{10, 10, 9, 10}, {10, 9, 10, 10}, {9, 10, 10, 11}, {10, 10, 11, 10}, {10, 11, 10, 10}, {11, 10, 10, 8}, {10, 10, 8, 8}, {10, 8, 8, 10}, {8, 8, 10, 10}, {8, 10, 10, 11}, {10, 10, 11}, {10, 11}, {11}}。
(2) 对子序列集S创建FP-Tree:
①创建T的根节点, 标号为“null” (如图2中的 (1) ) , T节点含有如下成员:节点数据 (ID) , 遍历过程中的动态频繁度 (sup) , 指向其子节点的指针集合和指向其父节点的指针;
②读取下一个 (现在是第一个) 子序列{10, 10, 9, 10}, 在T中从根节点开始搜索。首先搜索3, T中如果有此节点, 则将该节点的sup值增加1, 接着搜索下一个元素2;T中没有此节点, 于是不用再继续搜索, 直接建立整个{10, 10, 9, 10}序列的子树 (如图2中的 (2) ) , 子树中每个节点的sup值都置为1;
③重复过程 (2) , 直到S中的最后一个子序列处理完毕, 对S的第二个子序列处理后fp树如图2中的 (3) 所示。S全部子序列处理完毕后fp树如图2中的 (4) 所示。
(3) 截取FP-Tree的频繁前缀:遍历FP-Tree, 剪除其所有小于给定支持度的节点及其左子树, 但其右子树需要根据其支持度进一步确定。在最小频繁支持数为2的情况下, 如上图2经截取后的频繁前缀树如图3所示。
3 FP-Tree的子树匹配
树型数据结构由于其前缀共享的特点, 能够避免数据操作过程中大量的重复操作, 大幅提高数据处理效率。数据大爆炸环境下, 为高效处理数据, 无不考虑引入树型结构改进算法, 例如文献[12]中将DFST-Tree结构引入数据流挖掘算法研究, 而在人工智能与数据挖掘方向的prifix前缀树与FP-Growth等算法更是久负盛名。目前树型结构用于匹配查询方向的算法如k-d树查询[18]及子树匹配, 前者是从k-d树中查询给定序列, 给定序列并非树型结构;后者则用于查询两棵树的结构是否类似, 但是并不关心树的节点数据。本文结合两者功能, 采用一种新的子树匹配方法, 匹配过程中既考虑查询树与主题树结构是否相似, 也要考虑节点数据的值, 从而在主题树中找出与查询树匹配的序列。
子树匹配的整体思路:对于待查询树, 要对其中的每一条序列 (从根节点到每个无子树节点的所有子节点数据组成一条序列, 根节点和叶子节点包括在内。例如上图3中一共有4条序列{10, 10, 11}, {10, 11}, {11}, {8}, 只有经子节点的组成同一个序列, 若经兄弟节点则是另一条序列) , 在主题树中查找是否存在相同的序列, 若存在则该序列匹配成功, 否则不成功。最后给出匹配率 (匹配成功的序列数与查询树中所有序列数之比) 。
子树匹配算法的具体描述如下:
(1) 遍历主题树
对于主题树的每个节点Node, 都作为根节点, 与查询树test Tree进行匹配:match Node (Node, test Tree) 。
(2) Node与test Tree的匹配:
①搜索Node及其所有右兄弟节点, 找到第一个与test Tree相匹配的节点, 找到转②, 找不到转③。
②如果test Tree无左子树, 则一条序列匹配成功, 剪除该序列在test Tree中分枝;转③。
如果test Tree有左子树, 检查Node节点:若Node无左子树, 则该序列与Node不匹配, 转③;若Node有左子树, 递归调用match Node (Node.leftkid, test Tree.leftkid) 。
③如果test Tree的右兄弟节点不为空, 递归调用match Node (Node, test Tree.right Sibling) ;如果test Tree的右兄弟节点为空, 则该节点处理完毕, 函数结束。
4 实验结果与性能分析
本文采用空中颠簸数据作为实验数据, 取子序列长度为8, 数据符号化范围为0到20。取三批空中颠簸数据, 分别跟空中颠簸数据 (每批65个文件) 和非空中颠簸数据 (每批45个文件) 进行匹配实验。飞机故障通常情况下不是由单一因素引起, 而与飞机故障有关的不同属性在飞机发生故障过程中的重要程序也各不相同, 根据专家经验给出的空中颠簸故障属性重要度调查表, 垂直加速度属性是对空中颠簸故障发生的最重要影响属性, 因此首先针对该故障数据的垂直加速度属性数据实验, 结果如表1所示, 其中第一行表示数据匹配率p的取值范围。
由表1可见, 本文通过对QAR数据创建fp树并根据fp树的特点采用子树匹配的方法搜索现有故障模型, 对于相同故障模型的故障数据间匹配率92%以上都达到0.6以上, 而不同故障数据间的匹配率则全部只有0.2以下, 说明算法能够有效处理单一属性并明确区别出相同故障数据与不同故障数据。
由于垂直加速度不是空中颠簸故障发生的唯一决定因素, 数据的单一属性分量并不能完全确定数据的故障类型, 因此将另一对空中颠簸故障影响很大的属性———发动机压比 (ERP) 属性数据也考虑在内, 针对垂直加速度属性和EPR属性数据综合处理, 得出结果如表2所示, 其中第一行表示数据匹配率p的取值范围。
由表2可见, 算法对两种属性进行综合处理, 相同故障间的匹配率有所下降, 但仍旧大部分达到0.4以上;而不同故障间的匹配率仍旧全部位于0.2以下。实际上, 当处理数据由一元变为二元, 两种属性之间有着无法避免的关联与约束, 那么数据的复杂度也必然是原一元数据的两倍以上, 但是数据处理过程中尚未兼顾数据之间的关联与约束, 因此数据之间的匹配率有所下降也是必然的。若要提高多元数据处理时的匹配率, 应该就不同元之间的关联与约束着手, 进一步研究。但就本文而言, 算法处理二元数据时, 相同故障数据之间匹配有所下降, 但仍有大量匹配;而不同故障数据间的匹配率也下降, 且全部降为零;由此已经能够完全区分出空中颠簸故障数据与非空中颠簸数据。综上所述, 本文算法能够明确区别出相同故障与不同故障数据, 有效检测出故障数据。
5 结语
QAR数据 篇3
关键词：A320,燃油不平衡,译码,工程调查
空客A320飞机收集各系统数据的部件是飞行数据接口管理组件 (FDIMU) , 它通过ARINC 429数据接口, 收集各个系统的数据, 传输到飞行记录器 (FDR) 和数字式飞机综合数据记录器 (DAR) 。DAR往往被大家称为QAR (快速存取记录器) 。由于FDR数据只能自动保存25个小时, 而通常航空公司又没有定期拆装FDR, 进行FDR数据下载的要求, 故对于处理时间稍有些滞后的工程调查来说, 利用QAR数据来分析, 就更实际一些了。
1 事件回顾
2013年10月8日, 某架A320飞机执行浦东-成都航班, 飞机于20:27起飞, 空中出现左右油箱油量差1.5吨, 完成漏油程序和燃油不平衡程序, 发现不平衡量增加, 达到左3.7吨、右5.7吨, 差值2吨, 机组执行备降程序。关闭左燃油泵, 飞机带坡度盘旋, 当左右燃油平衡后于21:49备降合肥。PFR报告见图1。合肥维修人员依据TSM28-21-00-810-839-A排故, 按AMM28-21-00-710-001和AMM28-21-00-720-001, 检查油量平衡, 各燃油泵工作正常, 检查左右外油箱膜正常, 左右油箱燃油交输检查, 均正常。10月9日航后, 浦东维修人员按TSM28-21-00-810-809排故, 按AMM28-42-34PB401更换FQIC, 按AMM28-46-00-740-051G测试正常。
2 工程调查分析
根据本次事件的排故过程来看, 维修人员并未找到本次燃油不平衡故障的真正原因, 最后更换了FQIC, 主要还是把故障归结于燃油量虚假指示的偶发上。察看PFR报告来看, 主要是燃油泵低压故障, 似乎又与燃油指示完全不沾边, 但是怀疑燃油泵的本体问题的话, 机组关闭了左燃油泵, 飞机带坡度盘旋, 落地时左右燃油平衡了, 这说明燃油泵工作还是正常的。
燃油不平衡故障, 主要涉及28-21 (燃油主泵) , 28-23 (燃油交输) 和28-42 (燃油指示) 这三个系统。按故障现象来分, 主要分为机载燃油真实不平衡和燃油量虚假指示两大类。
如果是机载燃油真实不平衡的话, 可能原因主要有油箱燃油渗漏, 左右发燃耗不一致, 交输活门非指令打开, 大翼油箱与中央油箱传输活门非正常打开;如果燃油量虚假指示故障的话, 可能原因主要就和油量指示系统有关, 包括FQIC计算机, 油量传感器等。从已知的机组操作和机务排故过程来看, 初步分析故障原因是与交输活门非指令打开有关。
由于燃油不平衡故障地面无法重现, 且实时的机载燃油量数据和活门和电门位置, 对判断故障原因非常重要。故后续通过对当次航班的QAR数据译码, 来完成进一步的工程分析。
首先, 通过译码数据分析, 燃油不平衡发生在12:36, 交输活门打开后, 由于左右大翼燃油泵性能会有差异, 故造成燃油左右不平衡。同时, 通过交输活门作动器和电门的线路图来分析, 交输活门作动器仅受电门作动控制, 电门且只有OFF和ON两个位置, 电门位置只能靠人工按入, 无任何继电器和弹簧机构。活门作动器和电门位置信息, 都进入SDAC计算机, 进行采集。所以, 通过活门作动器和电门位置保持一致这一现象, 可以肯定交输活门是机组人工打开的, 可以排除交输活门非指令打开的可能性。至于机组打开交输活门的原因, 通过查阅FCOM中关于8中央油箱泵1 (2) 低压的PRO程序, 活门打开的时间和PFR报告上出现中央油箱泵低压的时间是吻合的。即机组观察到中央油箱泵故障, 进而打开了交输活门。
各个时间点上, FOB+FU与初始状态下的FOB, 基本保持一致, 故也排除了燃油渗漏的可能。
各个时间点上, 左右发FU, 基本保持一致, 也排除因发动机燃耗不同, 造成燃油不平衡的可能。
3 工程调查结论
结合FCOM上两个PRO程序:中央油箱泵低压, 燃油不平衡和燃油交输的系统图, 在正常情况下, 飞机空中交输活门关闭, 左翼油箱供给左发, 右翼油箱的油供给右发。当出现中央油箱泵低压故障, 为防止中央油箱泵仅给单侧油箱供油, 故要求机组关闭受影响的中央油箱泵, 并打开了交输活门。由于左右大翼油泵性能存在不同, 会出现了燃油不平衡的状态, 当中央油箱空时, 需要求机组及时关闭交输活门, 并按需执行燃油不平衡程序, 即进行空中倒油程序。但本次航班中, 机组未在中央油箱空情况下, 及时关闭交输活门, 其让燃油不平衡状况持续发展, 同时, 在发现燃油有不平衡情况下, 也未及时按FCOM程序, 关闭较轻一侧的大翼燃油泵, 进行倒油, 根据时间上推算, 操作延误接近了20分钟, 进而造成了左右大翼油箱相差2吨, 飞机返航备降。此次事件, 如机组严格按照FCOM操作的话, 是完全可以避免的。
4 结束语
4.1 对于某些地面无法再现的故障, 比如空速不一致, 飞机侧滑, 空中燃油出现指示错误等, 除了向机组口头了解外, 通过QAR译码, 再现故障现象, 是种简单易行的途径。
4.2 对于返航备降事件中具体责任认定, 是机组操作原因, 还是本身飞机故障, 通过查看QAR数据中的操作电门, 操作手柄, 手轮的实际位置, 与相关控制部的实际位置相比较, 并结合中央集成故障显示系统 (CFDS) 中的故障信息, 来查找具体原因, 是一种简单有效的方法。