|
仪表板公共链接：http://programmerhou.xyz/webroot/decision/link/fCrA
尝试部署在了自己的服务器，服务器比较鸡肋，物理内存只有2G，为防止宕机，服务器将于每个整点reboot，整点访问可能出现无法访问的情况，稍等一两分钟就好了~
组件联动可能比较慢...链接随时可能无法使用...
由于使用的FineBI未注册，该仪表板公共链接仅供本大赛测试及临时展示使用~
视频介绍链接：https://www.bilibili.com/video/BV17a411v7EE?share_source=copy_web
因为视频有点大，无法直接上传，就贴外部链接了~
一、自我介绍
1、选手介绍
社区用户名：小伙头发还挺多，现在是南京邮电大学通信与信息工程学院的一名硕士研究生。
2、参赛初衷
-
- 航空大数据处理是我研究生阶段的一个研究课题，之前一直是用MATLAB做可视化，现在想尝试使用FineBI做航空大数据处理，事实证明，至少在我用到的可视化需求上，FineBI不输MATLAB，甚至要更加便捷；
- 帆软总部在我的家乡无锡，毕业以后希望有机会能够成为帆软大家庭的一员，想先体验一下帆软的产品~
二、作品介绍
1、背景说明
ADS-B是广播式自动相关监视系统，是一种开放的航路监视设备，相比传统雷达，ADS-B设备价格低、安装维护简单、数据更加详细，适合大面积部署。工作流程如下：
ADS-B的数据来自于飞机的各种机载设备，如：
-
-
-
-
- GPS接收机，GPS是ADS-B系统主要的数据来源；
- 静压管或大气计算机，可以向ADS-B提供气压高度信息；
- FMS，可以向ADS-B提供航班号信息。
这些信息被机载的ADS-B发射机发出，由于ADS-B信号链路的开放性，地面只要具备ADS-B接收机，谁都能收到一定范围内的所有ADS-B报文，专业人员可以利用这些报文，实现对飞机姿态的实时监视。ADS-B报文的数据非常清晰，这是传统雷达无法做到的，下面是一个ADS-B报文的样例：
国内从2020年12月31日起，全面实施ADS-B管制，飞机必须要装有ADS-B发射机，地面广泛部署ADS-B接收机。
国外起步较早，已有类似OpenSky这类非盈利开源网站，通过接入大量ADS-B接收机，收集ADS-B报文在地图上实时显示航班轨迹。
2、需求痛点
ADS-B系统的优势毋庸置疑，但ADS-B接收机的广泛部署，为接收机的维护增加了难度，本作品希望通过FineBI为ADS-B接收机布站和维护提供便捷。当前主要面临的需求痛点如下：
- 国内没有ADS-B设备数据开源数据库，ADS-B设备数据开源数据库可以供研究人员用于分析和改进空中交通管制技术和流程，为了能够更好地提高空域使用的安全性、可靠性和效率；
- ADS-B的时间戳是毫秒，甚至是纳秒级别，单位时间数据量大，处理困难；
- 现有的监测系统大多都是对ADS-B报文进行分析，OpenSky就是使用ADS-B报文数据内容绘制的可视化飞行轨迹，但无法监控及维护大量ADS-B设备，日积月累系统中会出现大量“僵尸设备”，占用资源。
3、数据来源
作品中数据来自于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报文数据集”中的服务器时间戳，每台接收机都有自己的时间戳，接收机时间戳表示该接收机捕获该条数据的时间点，服务器时间戳是汇总多台接收机捕获情况的时间点，每台接收机之间、接收机与服务器之间，它们的时间戳或多或少会有延迟。
以上三个数据集的关联视图如下：
4、分析思路
预期目标：
（1）利用FineBI处理航空大数据，实现 接收机布站情况 和 航路情况 可视化；
（2）辅助ADS-B接收机布站和维护等工作做出决策；
（3）构建一个类似OpenSky的开源数据库，作为一个demo，填补国内在航空大数据开源方面的空缺。
实现思路：
（1）根据“ADS-B接收机数据集”和“ADS-B报文数据集”，对 接收机整体布站情况 和 每个航班的航路 实现可视化；
（2）分析航路被ADS-B接收机的捕获情况，来确定哪些位置需要增设ADS-B接收机；分析哪些接收机在航路监测中不活跃，哪些接收机接收信号强度有故障，哪些接收机时钟有故障，来对“ADS-B接收机数据集”中的接收机做维护。
（3）只要将上述数据库开源即实现了“构建一个类似OpenSky的开源数据库”的预期。
5、数据处理
（1）时间戳单位转换：数据集中，接收机时间戳单位是纳秒，服务器时间戳单位是秒，为了统一单位，将接收机时间戳统一除以10^9，统一单位为秒；
（2）计算接收机与飞机的距离：这个距离主要用于判断接收机接收的信号强度接收器是否损坏，理想状态下，飞机离接收机越远，信号强度越小。现在已知飞机的经纬高，和接收机的经纬高，需要将大地坐标系转换为笛卡尔坐标系才能计算出三维空间距离，以飞机为例，根据如下转换公式计算：
转换完成后，计算距离：
（3）接收机与服务器时间戳的延时：即便接收机与服务器之间的时间戳独立，但是时间前进的速度不变，则理想状态下，接收机与服务器时间戳的差是一个稳定的数值，如果该数值存在波动，则可以认为接收机的时钟损坏。
（4）所有捕获到该航班的接收机数量：如果一个航班被较少的接收机捕获，则需要在该航路上增设ADS-B接收机。
（5）为“ADS-B接收机数据集”增设一列虚拟航班号-1：用于观察哪些接收机被录入了系统，但已经失去活性成为了“僵尸设备”，需要进行相关维护或者剔除，防止资源浪费，后面可视化报告中会有详细展示。
6、可视化报告
可视化报告一共分为三大块：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的接收机的时钟延迟不稳定。
分析：时间前进速率不变，接收机时间戳与服务器时间戳的差值应为一个相对的稳定的值。
结论：这两个接收机需要维护时钟。
组件功能总结：上述组件对接收机个体的性能进行了分析，分别为维护每台接收机的信号强度接收器和时钟做出了指导。
7、仪表板总结
（1）实现了 接收机布站情况 和 各航班的航路 可视化；
（2）为接收机维护提供依据：判定哪些设备是不活跃的“僵尸设备”，判定哪些设备活跃但其相关功能组件存在损坏；
（3）为接收机增设提供依据：判定哪些区域（航路）缺少接收机部署；
（4）只要将上述数据库开源即实现了“构建一个类似OpenSky的开源数据库”的预期，且在功能上要比仅支持航路可视化的OpenSky要强大。
最终结果呈现的页面布局如下：
三、参赛总结
1、FineBI工具
之前一直用MATLAB做航空大数据的处理，此次第一次尝试使用FineBI处理数据，感觉非常良好，有FineBI的基础，个人认为帆软完全有能力去开发一款toC的，与MATLAB（数据可视化部分）类似的国产数据分析软件。下面总结作品中用到的FineBI亮点功能：
（1）轻松清洗大数据
（2）给定经纬度，就能在地图上精准定位
（3）闪烁动画显示方向性，使图表更加直观
（4）联动功能，使单独观察数据更加方便、快捷
2、参赛总结
最近正好有些空闲时间，正好看到帆软公众号推了这个比赛，正好帆软这个公司是我比较关注的一家公司，正好一直想找机会体验一下帆软的产品，正好之前做了航空大数据相关的课题，正是这些机缘巧合让我参加了这个竞赛。
由于实验室只有我一个人是做这个课题方向的，于是就一个人报名参赛了，大概花了半个月的时间，从学习FineBI帮助文档，到清洗数据，再后到仪表板的制作，我很享受这个过程，FineBI给我的体验也非常好，字段拖拉的这种操作模式，让操作非常方便。
在竞赛中也遇到了一些问题，要感谢苏茜、大赛指导黄老师和朱老师的耐心讲解指导。总之，这是一次很不错的竞赛体验！
 ADS-B接收机布站情况及报文分析-最终仪表板.pdf (2.81 M)
| 
