本文主要是介绍航空大数据——使用FineBI对ADS-B接收机布站情况及报文分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
这个专题的前面三篇文章主要是由ADS-B报文系统预测飞机坐标，偏向于数据应用。本文主要是对ADS-B接收机的数据做分析，为接收机的维护和增设提供依据，偏向于数据分析。
本文相当于是对前文数据集的再利用，再分析。使用FineBI作为分析工具，机缘巧合碰到了这个软件，个人感觉在数据可视化上，用起来要比MATLAB方便一点。
本文只是提供分析思路，所有可视化分析均可由MATLAB实现。
| 目录 引言 一、数据来源 二、分析思路 三、数据处理 三、可视化报告 四、仪表板总结 FineBI V 5.1.18 试用版下载： Windows版：点击下载 macOS版：点击下载 Linux版：点击下载 FineBI 资源包下载： 航空大数据——使用FineBI对ADS-B接收机布站情况及报文分析-数据集文档类资源-CSDN文库 （该资源包为FineBI资源包，导入FineBI中，能够获取数据及仪表板） 引言ADS-B系统的优势毋庸置疑，但ADS-B接收机的广泛部署，为接收机的维护增加了难度，本文希望为ADS-B接收机布站和维护提供依据。当前主要面临的挑战如下： （1）ADS-B的时间戳是毫秒，甚至是纳秒级别，单位时间数据量大，处理困难； （2）现有的监测系统大多都是对ADS-B报文进行分析，OpenSky就是使用ADS-B报文数据内容绘制的可视化飞行轨迹，但无法监控及维护大量ADS-B设备，日积月累系统中会出现大量“僵尸设备”，占用资源。 一、数据来源数据来自于OpenSky数据库，由于该数据库没有收录国内设备，所以大部分数据来自欧洲部署的ADS-B接收机设备。共涉及以下三个数据集： （1）ADS-B接收机数据集：
每行数据表示每台ADS-B接收机的地理坐标及型号，每台接收机都有一个全局唯一的id。 （2）ADS-B报文数据集：
每行数据表示一条ADS-B报文，报文中包含飞机航班号和飞机当前坐标，除此之外，还有该报文被总服务器（此处是指OpenSky服务器）汇总的时间戳，和该报文一共被多少台ADS-B接收机捕获。每条数据都有一个全局唯一的ADS-B数据id。 （3）报文被接收机的捕获情况：
该数据集记录了ADS-B报文被ADS-B接收机的捕获情况，如第一行表示，接收机136在2,506,033,793,125这个时间点（单位：纳秒），捕获到了ADS-B数据id为4,549,514的报文，捕获时的信号强度为35dB。同一个ADS-B数据id可能会被多台ADS-B接收机捕获，因此在数据集中会多条相同id的行。 此处需要特别注意，接收机时间戳不是“ADS-B报文数据集”中的服务器时间戳，每台接收机都有自己的时间戳，接收机时间戳表示该接收机捕获该条数据的时间点，服务器时间戳是汇总多台接收机捕获情况的时间点，每台接收机之间、接收机与服务器之间，它们的时间戳或多或少会有延迟。 以上三个数据集的关联视图如下：
二、分析思路
预期目标： （1）利用FineBI处理航空大数据，实现 接收机布站情况 和 航路情况 可视化； （2）辅助ADS-B接收机布站和维护等工作做出决策。 实现思路： （1）根据“ADS-B接收机数据集”和“ADS-B报文数据集”，对 接收机整体布站情况 和 每个航班的航路 实现可视化； （2）分析航路被ADS-B接收机的捕获情况，来确定哪些位置需要增设ADS-B接收机；分析哪些接收机在航路监测中不活跃，哪些接收机接收信号强度有故障，哪些接收机时钟有故障，来对“ADS-B接收机数据集”中的接收机做维护。 三、数据处理（1）时间戳单位转换：数据集中，接收机时间戳单位是纳秒，服务器时间戳单位是秒，为了统一单位，将接收机时间戳统一除以10^9，统一单位为秒； （2）计算接收机与飞机的距离：这个距离主要用于判断接收机接收的信号强度接收器是否损坏，理想状态下，飞机离接收机越远，信号强度越小。现在已知飞机的经纬高，和接收机的经纬高，需要将大地坐标系转换为笛卡尔坐标系才能计算出三维空间距离，以飞机为例，根据如下转换公式计算：
转换完成后，计算距离：
（3）接收机与服务器时间戳的延时：即便接收机与服务器之间的时间戳独立，但是时间前进的速度不变，则理想状态下，接收机与服务器时间戳的差是一个稳定的数值，如果该数值存在波动，则可以认为接收机的时钟损坏。
（4）所有捕获到该航班的接收机数量：如果一个航班被较少的接收机捕获，则需要在该航路上增设ADS-B接收机。
（5）为“ADS-B接收机数据集”增设一列虚拟航班号-1：用于观察哪些接收机被录入了系统，但已经失去活性成为了“僵尸设备”，需要进行相关维护或者剔除，防止资源浪费，后面可视化报告中会有详细展示。
三、可视化报告可视化报告一共分为三大块：ADS-B接收机布站情况总览、ADS-B报文数据可视化分析、ADS-B接收机性能分析。分别从ADS-B接收机整体布站情况，和ADS-B接收机个体性能两大方面进行分析。 （1）ADS-B接收机布站情况总览：
上图组件为接收机布站情况总览，以接收机id为细粒度，根据每台接收机的经纬度，在地图上标出位置，不同型号的接收机以不同的颜色表示，不同型号的接收机有着不同的性能。有些型号的接收机体积大、布站困难，但精准度高；有些型号的接收机体积小、便携，但精准度不高。Dump1090型号是性价比最高的接收机，所以其布站最为广泛。
上图为数量统计组件，分别统计了接收机数据集总记录数，和每种型号分别的记录数。
上述组件可以联动，单独观察某型号接收机布局。 组件功能总结：上述三个组件是对当前系统收录的ADS-B接收机布站情况的总览。 （2）ADS-B报文数据可视化分析：
由于数据较多，选择部分航班观测。上面两个组件均以服务器时间戳为细粒度，展示了每个航班的航路以及飞机的高度变化。
以航班3展示联动效果，闪烁动画更加直观地展示了飞机的飞行方向，从上图能够获得的信息是：航班3在服务器时间1000秒时从圣但尼起飞，往日内瓦方向飞行，在服务器时间2462秒时达到水平飞行的姿态。
上图组件以接收机id为细粒度，不同航班以不同颜色表示，展示了每个航班使用到的接收机，航班号-1表示未被使用到的接收机，这也是为什么在“ADS-B接收机数据集”增设一列虚拟航班号-1的原因。 问题一：“僵尸设备”的判定
发现问题：继续以航班3为例，单独观察航班3接收机的使用情况，航路上有一些灰色的接收机，这些是录入在系统中，但未被使用到的接收机。 分析：这些接收机在该航班的航路上，理应能够捕获到该航班的ADS-B报文，但事实上这些接收机并未工作。 结论：这些接收机就是需要维护的接收机，不能让他们在系统中占用资源，却不工作。
上图组件是对每个航班被接收机捕获的情况汇总，按照经验值，单一时间的报文被3台以上的接收机捕获才合理，通过上图的组件，能够明显看出，哪些航班的航路需要增设ADS-B接收机。 问题二：哪里需要增设ADS-B接收机
发现问题：整个数据集的服务器时间戳变化范围为0-3600秒，而航班1的数据在2100秒就消失了。
分析：结合航班1被接收机捕获的情况汇总，和捕获航班1报文的接收机分布，发现航班1涉及的接收机数量少，航路上存在大量空白，且存在不活跃的接收机。 结论：1、维护不活跃的接收机；2、航路上增设接收机。 组件功能总结：上述组件主要对接收到的ADS-B报文结合ADS-B接收机布站情况进行分析，定位“僵尸设备”，为哪些接收机需要维护做出指导，并且为接收机的增设提供思路。 （3）ADS-B接收机性能分析：
选择一个航班（此处以航班3为例），在指定时间区间观测具体接收机。
上图组件，以服务器时间戳为细粒度，不同接收机赋予不同的颜色，展现接收机接收信号强度与接收距离的关系。
组件联动观察id为587的接收机情况，飞机在服务器2000秒的时候飞离接收机，接收机信号强度骤降，直到最后信号消失，飞机飞离接收机监测范围，此接收机接收信号强度与接收距离关系良好，此接收机的信号强度接收器无需维护。 问题三：哪些接收机的信号强度接收器需要维护
发现问题：id为574的接收机接收信号强度始终维持在0dB附近，而飞机逐渐远离接收机。 分析：不符合接收距离越近，接收信号强度越强，接收距离越远，接收信号强度越弱的理论。 结论：该接收机需要维护信号强度接收器。 问题四：哪些接收机的时钟需要维护
上图组件，以服务器时间戳为细粒度，不同接收机赋予不同的颜色，展现每台接收机相对于服务器时间戳存在的时钟延迟。 发现问题：id为296和312的接收机的时钟延迟不稳定。 分析：时间前进速率不变，接收机时间戳与服务器时间戳的差值应为一个相对的稳定的值。 结论：这两个接收机需要维护时钟。 组件功能总结：上述组件对接收机个体的性能进行了分析，分别为维护每台接收机的信号强度接收器和时钟做出了指导。 四、仪表板总结（1）实现了 接收机布站情况 和 各航班的航路 可视化； （2）为接收机维护提供依据：判定哪些设备是不活跃的“僵尸设备”，判定哪些设备活跃但其相关功能组件存在损坏； （3）为接收机增设提供依据：判定哪些区域（航路）缺少接收机部署。 最终结果呈现的页面布局如下：
|
这篇关于航空大数据——使用FineBI对ADS-B接收机布站情况及报文分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
