第二章:数据获取与清洗——从飞机系统到可用日志

说实话,很多飞行员拿到日志的第一反应是——这玩意儿能看懂?满屏的十六进制、时间戳、参数代码,跟天书似的。我刚开始带学员的时候,有人直接把原始日志打印出来,拿荧光笔在那划重点。嗯,精神可嘉,但效率太低了。

这一章,我们就来解决这个问题。怎么从飞机系统里把日志拽出来,怎么把脏数据洗干净,怎么让数据变成你能用的样子。说白了,就是教你怎么跟飞机“对话”。

核心观点: 数据清洗不是可有可无的步骤,而是决定后续分析是否靠谱的基石。脏数据进去,垃圾结论出来,这个道理在航空领域尤其致命。

2.1 数据获取:从飞机系统到你的电脑

不同飞机、不同航司,日志的获取方式差别挺大。我归纳了三种最常见的途径:

获取方式 适用场景 数据格式 我的建议
机载数据总线直读 模拟机、测试机、部分通航飞机 ARINC 429 / 717 二进制流 需要专用硬件和驱动,适合深度研究
航后数据卸载(QAR/DAR) 主流民航客机 .dat / .qar / 专有格式 最常用,但需要解码软件
电子飞行包(EFB)日志导出 已部署EFB的航司 .csv / .json / .kml 最方便,但数据字段有限

我个人习惯优先用EFB导出的CSV文件做教学。为什么?因为门槛低。你不需要懂总线协议,不需要买解码器,一个Excel或者Python就能打开。等把清洗和分析的逻辑练熟了,再回头啃那些二进制流也不迟。

小技巧: 如果你拿到的是QAR原始文件,别急着用记事本打开。先查一下航司用的是哪家解码软件——Teledyne、SAGEM还是L3Harris。不同厂家的解码器,输出字段名都不一样,这个坑我踩过。

2.2 数据清洗:缺失值与异常值处理

数据拿到手,第一件事不是分析,是“打扫卫生”。我见过太多人上来就画图,结果图里全是毛刺,根本没法看。为什么会这样?因为原始日志里充满了缺失值和异常值。

2.2.1 缺失值处理

缺失值在飞行日志里太常见了。传感器偶尔掉线、数据总线丢包、记录仪写入失败——原因一大堆。处理方式有三种:

  1. 直接删除(行删除):适用于缺失比例小于5%且随机分布的情况。简单粗暴,但会损失样本量。
  2. 填充(均值/中位数/前向填充):适用于连续参数,比如高度、空速。我个人偏好前向填充——用上一秒的有效值补下一秒的缺失值,因为飞行参数变化是连续的,这个假设比较合理。
  3. 插值(线性/样条):适用于关键参数,比如发动机转速、迎角。插值比填充更平滑,但计算量也更大。
注意: 千万不要在缺失比例超过30%的字段上做填充。我曾经处理过一批数据,某个传感器的缺失率高达40%,我硬着头皮做了插值,结果分析出来的着陆距离偏差了15米——这在跑道长度紧张的时候是要命的。

2.2.2 异常值处理

异常值比缺失值更隐蔽。它看起来有数值,但那个数值根本不合理。比如空速突然跳到800节,或者垂直加速度变成-5G——这明显是传感器故障或者记录错误。

我常用的检测方法:

  • 物理阈值法:根据飞机手册设定上下限。比如波音737的Vmo(最大操作速度)是340节,超过这个值直接标红。
  • 统计法(3σ原则):计算均值和标准差,超出3倍标准差的值视为异常。适合正态分布的数据。
  • 滑动窗口法:看相邻时间点的变化率。如果一秒内高度变化超过500英尺,大概率是异常。

下面是一个简单的Python清洗示例,我经常在课上用:

import pandas as pd
import numpy as np

# 读取原始日志
df = pd.read_csv('flight_log_raw.csv')

# 缺失值处理:前向填充
df['ALTITUDE'] = df['ALTITUDE'].ffill()

# 异常值处理:物理阈值
df = df[(df['IAS'] >= 0) & (df['IAS'] <= 350)]

# 异常值处理:滑动窗口(变化率限制)
df['ALT_DELTA'] = df['ALTITUDE'].diff().abs()
df = df[df['ALT_DELTA'] <= 500]

# 保存清洗后的数据
df.to_csv('flight_log_clean.csv', index=False)
避坑指南: 我曾经在清洗一批737-800的日志时,发现某个航段的高度数据全部偏低200英尺。一开始以为是传感器故障,后来查了机场气压设置才发现——那天机组忘了调QNH。所以,清洗之前先看看元数据,有时候“异常”其实是操作习惯导致的。

2.3 数据标准化:让不同飞机说同一种语言

数据洗干净了,但还有一个问题——不同飞机、不同航司,用的单位不一样。有的用英尺,有的用米;有的用节,有的用公里/小时;有的用摄氏度,有的用华氏度。不统一,就没法对比分析。

标准化要做三件事:

  • 单位统一:我建议全部转为国际标准单位。高度用米,速度用米/秒,温度用摄氏度。虽然航空气象常用英尺和节,但做数据分析时,国际单位制更通用。
  • 时间对齐:把时间戳统一为UTC,精度到秒。有些日志用本地时间,有些用GPS时间,不统一的话,多源数据合并时会乱套。
  • 字段命名规范:把不同来源的字段名映射成统一名称。比如“ALT”、“ALTITUDE”、“HGT”都改成“ALTITUDE_M”。

下面是我常用的字段映射表:

原始字段名(波音) 原始字段名(空客) 标准化字段名 单位
ALT ALTITUDE ALTITUDE_M 米
IAS SPD SPEED_MPS 米/秒
VRTG VRTG VERT_ACCEL_G G
OAT TAT TEMP_C 摄氏度
记住: 标准化的目的是让数据可比较、可复用。你今天清洗了一架A320的日志,明天拿到一架B737的日志,如果标准化做得好,分析流程可以直接复用,不用从头再来。

2.4 本章知识体系总览

下面这张图,把数据获取、清洗、标准化的核心流程串起来了。你可以把它当成一个检查清单——每次拿到新日志,按这个流程走一遍,基本不会漏东西。

数据获取与清洗流程框架图 数据获取与清洗流程框架 数据获取 机载总线直读 QAR/DAR卸载 EFB日志导出 数据清洗 缺失值处理(删除/填充/插值) 异常值处理(阈值/统计/滑动窗口) 数据标准化 单位统一(国际标准) 时间对齐(UTC) 字段命名规范

嗯,这张图把整个流程串起来了。从数据获取开始,到清洗,再到标准化,每一步都有明确的处理对象和方法。你下次拿到日志,可以对着这张图走一遍,保证不会漏掉关键步骤。

最后提醒一句: 清洗和标准化不是一次性工作。随着你积累的日志越来越多,你会发现新的问题——比如某个传感器在特定温度下容易漂移,或者某个航司的日志格式又更新了。保持迭代的心态,把清洗脚本当成一个持续维护的工具,而不是写完就扔的作业。