蓝牙电话-无人值守的巡检方案探索

蓝牙电话-无人值守的巡检方案探索

• 一、前言

上一篇章我们分析到了探讨蓝牙电话方案无人值守和远程巡检这个方向的必要性（这个事情确实也比较重要，凡是跟法律法规有关的事，一般都比较重要），并分析了蓝牙电话方案在无人值守方面会面临哪些问题。

本篇章中，我们针对技术细节以及无人值守可能的实现方式，进行简单的探讨。目的是为了从通用一般的方法上，看看如果有类似的方案，它们做这个事情能走的通路大概都有哪些，以及如何要阻止这些方案和应用要这样去使用。

在物联网应用中，比如远程抄表，后台平台系统对终端设备的感知和操控主要体现在下述几个方面：

1. 感知终端的在线状态，拉取电量、温湿度、运行负载等节点自身的状态信息；
2. 感知终端节点的工作状态或链路状态的信息，如该水/电表是工作在哪一户人家，当前使用的数值是多少，是否欠费等状态。
3. 根据日常的业务流程进行双方的业务数据同步，比如用户已欠费超过授信额度后远程自动下发指令断水/电。
4. 触发某些特殊状态的时候，可以由远程管理人员在后台对该设备进行远程锁死/解锁（控制）操作。
5. 如果终端出现故障，终端会先尝试复位和恢复故障，如故障无法恢复，则上报管理后台，由后台维护人员进行远程维护模式的修复和故障恢复。
6. 实在恢复不了的故障，才会由用户拆卸后送到维修点维修或由维修人员上门维修。

这样的话，其实蓝牙电话的无人值守策略，跟远程抄表的物联网应用并没有太多本质上的区别。简单归纳就是它们在正常运行时会同步保持两种功能：正常业务功能和异常状态监管。

正常的业务功能在不同的应用中，会存在不同的业务和数据。本篇章中着重拆解和分析异常状态监管部分的架构体系和具体可行的实现技术方案。

• 二、异常状态监测和管理

终端设备在正常工作时，会以一定周期的频率将自身状态和业务链路状态的数据，上报反馈给管理后台。

当终端设备遇到链路状态异常情况时会实时将异常事件反馈到管理后台，并尝试进行自检和自我恢复，若恢复成功则将就绪状态同步反馈给管理后台。

终端设备自身状态异常时，也将实时同步状态属性到管理后台，但设备不能自我重启，若需要复位或重启恢复的场景，需由管理后台远程切换到维护模式再进行此类操作。

若终端设备的自我恢复操作，无法将自身状态或链路状态恢复到默认的就绪状态，则需要将告警信息在管理后台中高亮提示，用于供后台的远程维护人员进行介入和干预。

管理后台人员进行远程维护时，可能采用设备工作模式的常规维护，也可能使终端设备进入采用单独的维护模式进行远程维护操作。维护模式在远程巡检完毕后会恢复为正常工作模式并重新加载和初始化操作，使终端设备达到就绪状态。

实在连远程维护都维护不了的情况，需要对终端设备做高亮标注，用于对后续实体设备的维修提供支持。

• 三、蓝牙方案远程干预的技术手段分析

蓝牙方案在日常运行中的状态上报和自身复位等内容属于基本操作，本篇不再详细展开论述，本章节主要对常用的远程介入和干预的方式进行探讨。

由于蓝牙方案采用的是Android手机+外置USB蓝牙的方式进行SIM卡数据的对接。依照前文的内容可知：

【

无人值守最大的工作量在于更换SIM卡。其次在于对智能手机工作状态和自身状态的检测和预警。最后才是提供应急预案，为故障或异常的设备提供远程切换SIM卡或重启设备等故障恢复提供远程操作入口。

经过以上的方式仍然无法恢复或生效的工作，则交由线下物理巡检的技术人员进行现场维护，如：SIM卡被封卡需要更换SIM实体卡、手机USB松动需要拔插恢复、电源与供电故障需要现场解决等常规问题。

在蓝牙电话方案中，关于检测和预警，最关键的预警和恢复预案应该包括两部分：识别SIM卡被封卡、以及识别手机无法连接（本地局域网的）SIP服务器

】

那么，对于蓝牙电话的远程巡检和远程操作而言，只需要基于Android标准的远程操作入口，进行远程人工干预下的链路状态恢复和SIM卡手动切换等常规操作。在远程操作时，可能需要借助于Android手机的界面进行参考和定位。

按照这个需求，以及Android手机提供的标准操作和恢复入口，我们可以对【远程干预】这个目标，大致分解为桌面内容展示和触控按键指令/脚本的远程注入。

这么一搞，其实这个无人值守或者说远程巡检的手段，基本跟当前市面上的“群控”这个方案比较类似了。对于这一块的内容，方案或实现原理中，开源世界里对这一个方向主要有两个很经典的方案，分别如下：

• 四、ADB连接+Scrcpy远程操作

这个例子就不详细阐述了，如此知名的开源软件都不了解的话，自己去搜去学习哈。反正搞群控、搞同屏共享、搞云手机等领域的，对Scrcpy以及其衍生出的一系列注入QtScrcpy之类的工具不熟的话，也没啥话可说的了。

Scrcpy这个软件基于adb的tcp连接，自动就拥有了获取远程手机界面、声音，以及注入按键、触控事件指令的能力。但由于adb连接大部分是基于局域网的（因为tcp如果跨因特网可能会遇到弱网卡顿等致命问题），需要在远程搭建一个adb桥梁，用于在需要远程访问手机设备的时候，每次只开一两个端口指向对应手机，减少公网暴露的风险。

具体的方案和搭建方式可以从各搜索引擎中获取，这里不再展开叙述。但这个方法确实是最为简洁、效率也是最高的。

• 五、Minicap截图+远程触控按键注入或内置自动化脚本

ADB如果被公开出来，可能会使手机设备遭受各种不可预知的风险。而且蓝牙电话的方案由于采用外置USB蓝牙的方式，占用了手机的Type-C接口，无法直接插入adb调试线到本地主机（而且无人值守环境也不一定存在本地主机）。

使用局域网IP:端口连接的adb有可能存在网络波动或因手机设备重启导致adb不可用的风险。

这个情况下，可以采用Scrcpy的子集Minicap的方式进行截图（这个也是一个很知名的开源库，感兴趣的可以自己搜索），截图后通过网络已一个比较稀疏的频率将缩略图上传到管理后台。

在操作时，使用远程命令注入或者预设自动化脚本的方式，将远程操作指令同步到手机终端设备，并使其实时生效的方式。

这样，通过上述的方式，即可实现无人值守的场景的状态画面同步，以及远程实时操作。远程巡检和无人值守场景可以使用上述方法，进行链路可用性的进一步确认、以及进行远程切换sim卡等操作。

• 六、蓝牙方案无人值守方向的思维发散

无人值守需要识别SIM卡被运营商封锁的场景，不过这个基本上属于常规操作，凡是所有的涉及实体SIM卡的应用，都会遇到这个现象。通过话务人员实际接通时人工识别即可。

我们基于上述的场景，以及无人值守或远程巡检这个概念，反过来思索：如果是走这个（无人值守的）模式，我们真的需要一个实体手机？手机的屏幕、触摸屏、电源电池这些辅助配置？像下述的这种主板机，是否也能堆叠出更高的密度和更低的成本？？

^v^，你看，要这样搞就离缝纫机的距离就越来越近了。^v^

• 七、总结

综上，经过初步分析，我们可以简单判断和列举，如果要阻断【无人值守】这条通路，最好的做法是从链路的方向入手。即通过业务和通话语音的特性，将数据和链路从技术层面进行阻断，从应用层面的角度进行业务的隔离。

---

上一章：蓝牙电话-如何做到无人值守(方案探讨)

下一篇：编写中。