基于NB-IoT的轨道交通监测系统远程固件升级技术研究.pdf

中国科技期刊数据库 工业 A 收稿日期：2023 年 12 月 22 日 作者简介：顾红宇（1995），男，汉族，江苏常州人，工程硕士，中科技术物理苏州研究院，助理工程师，电子学系统设计方向。-33-基于NB-IoT的轨道交通监测系统远程固件升级技术研究 顾红宇1 范余茂1 夏建琪1 吴 迪2 顾明剑1 1.中科技术物理苏州研究院，江苏 苏州 215127 2.上海申通地铁集团有限公司技术中心，上海 201103 摘要：摘要：目的 为完成上海轨道交通运营线路试点应用中声屏障联网监测设备的远程固件升级。方法 分析了中国移动OneNET物联网云平台与监测设备的交互方式及实现策略，确定了基于NB-IoT模组+EFM32PG22微控制器+OneNET云平台的远程交互体系架构，提出了通过 NB-IoT 网络实现设备的远程固件升级方案。同时，针对无线信号质量不佳而导致数据传输失败的问题，提出了一种分布式通信模式设计。结果 实现了批量远程设备的固件升级，提高了设备运行过程中修复 Bug 的效率。关键词：关键词：远程固件升级；铁路声屏障；OneNET 云平台；NB-IoT 中图分类号：中图分类号：TP277 0 引言 随着电子、通信和计算机技术的迅速发展，物联网设备在工业、军事和民用领域得到了广泛应用1。但是某些物联网设备存在着三个问题：（1）设备安装地点较为偏远，不能轻易到达现场；（2）设备间相距比较远；（3）设备数量较多；这样使设备的系统升级极不方便。传统的固件升级是维护人员到现场进行手动烧录，存在操作困难和实时性差等问题。此外，当设备数量庞大、分布范围广时，耗费成本十分巨大。对此，本文提出了一种基于NB-IoT无线网络的批量远程升级方案。NB-IoT 即窄带物联网，可在现行的 2G、3G 及4G 网络上部署，具有覆盖范围广、网络增益高、设备功耗低以及建设与运行维护成本低等特点2。1 远程升级系统的硬件组成 远程升级设备基于 EFM32PG22 微控制器设计，EFM32PG22 是 Silicon Labs 推出的一款 32 位微控制器（MCU），它具有低成本、低功耗、高性能的特点。在存储方面，EFM32PG22 的最大存储容量为 512kb 的Flash，并搭配了 32kB 的 RAM。采用 M5311 作为 NB-IoT数传模块，该模块支持 MQTT 协议，具有低功耗、低延时和低成本等特点。M5311 模块通过 AT 指令完成与OneNET 云平台之间的通信，发送 AT 命令后平台会反馈结果。整个设备的硬件组成包括电源管理系统，NB-IoT无线通信模组和其他功能模块。EFM32PG22 通过串口和M5311 模块进行连接。M5311 通信模块可以实现串口到网络的双向数据透明传输，可以通过此模块实现发送数据到 OneNET 服务器3。模块也可以接收来自服务器的数据，并将数据通过串口发送至 EFM32PG22。图 1所示为系统硬件组成。图 1 系统硬件组成 2 远程升级系统终端软件设计 程序开发环境为 QT Creator4.8.2+Simplicity Studio。程序由上位机控制界面程序和嵌入式主程序两部分组成。基于Qt图形用户界面应用程序开发框架，设计了物联网远程升级工具，具有友好的用户交互界面。软件界面如图 2 所示。图 2 上位机软件界面 中国科技期刊数据库 工业 A-34-当上位机要从OneNET云端服务器上读取数据的时候，使用的都是 GET 方法；通过调用 httpGet(const QString&url)函数将请求参数和对应的值附加在 URL后面，本次URL示例为“http:/ HTTP 响应，将服务器上对应 ID 的设备最新的一包数据推送至上位机4。同样的，上位机要将数据发送至 OneNET 云端服务器时，使用 POST 方法；通过调用 httpPost(const QString&url，const QByteArray&data)函数将数据 发 送 至 目 标URL；本 次URL示 例 为http:/ 需要写入以下请求参数：设备 IMEI 号、obj_id、obj_inst_id、传输模式 mode 和超时时间，前三者可以在云平台注册时查看；传输模式代表了云平台和设备端之间的通信方式，包括写入、读取和执行三种，当 mode=1 时，云平台接收到数据后，会立即将得到的数据写入设备端；超时时间会对云平台下发数据到设备端的时间进行判断，若超过这个时间则代表下发失败，返回一个错误信息。同时，按照云端平台要求，传 输 数 据 需 具 备 一 定 的 结 构，例 如data:res_id:5750,val:+send_data+，这样才能保证数据准确完整的发送至设备端。图 3 EFM32PG22 内部 Flash 分配情况 使用Simplicity Studio 开发软件完成EFM32PG22内部程序编写、调试、编译，并转换为.bin 格式文件用于远程升级。物联网设备如想拥有软件的远程升级功能，那么就首先需要一个引导加载程序 Bootloader。Bootloader 是嵌入式系统在上电后执行的第一段代码。在完成 CPU 和相关硬件的初始化之后，Bootloader会将操作系统映像或固化的嵌入式应用程序装载到内存中，之后再跳转到原程序所在的地址空间，最终完成整个嵌入式系统的启动加载5。应用程序及Bootloader 程序均存放在 Flash 中，存储空间分配如图 3 所示。进行升级时，上位机将待升级文件按规则分多包发送到 EFM32PG22 设备，当物联网设备连接至 NB-IoT网络时，云平台自动将升级数据包推送到物联网设备上，需要注意的是，只有当设备上报数据后的 60s 内，云平台才能有效的推送下行数据给设备。基于应用软件+云平台的远程升级可以分为以下几个步骤：（1）按照协议准备升级所需的 GBL 文件包。（2）打开上位机软件，不断的 GET 云平台的数据，当接收到某设备升级标记数据时，自动发送升级指令，云平台自动将升级数据包推送到物联网设备上。（3）设备收到升级数据包后，临时存储在 MCU 内部 Flash 中，设备进行应用程序版本校验，同现有应用程序版本比对后判断是否需要做出升级更新。（4）待所有升级包发送完且验证正确后，软件复位重启系统。设备重启后向云平台上报升级结果，完成远程升级。通过以上步骤，终端设备可以接收到全部来自于平台的升级包并写入到 Flash 中，完成升级流程。远程升级流程如图 4 所示。图 4 基于云平台的远程升级流程 本文在嵌入式 APP 程序中接收升级数据。在进行升级时，需要遵循一定的通信协议，才能正确的进行升级。云平台下发的数据分为 9 部分，如表 1 所示。中国科技期刊数据库 工业 A-35-表 1 固件升级通信协议 序号 协议字段 举例 说明 1 包头 0 x9BB9 数据包包头 2 终端 ID 868913052522340 升级包发送设备编号 3 控制字 0 xC1 此数据包类型为升级报文 4 固件版本 0 x00 用于固件更新成功判断 5 数据包编码 0 x00 包计数 6 数据包长度 0 x0200 每小包字节数 7 尾包标志位 0 x00/0 x01 0 x01：表示尾包 8 原始数据 0 xeb17a60308.hex 固件 9 CKS 校验 0 x43 0 x8C 和校验+异或校验 为了降低远程传输数据的误码率，通常将更新后的固件拆分为多个小数据包进行传输。每个数据包的长度可以根据实际使用情况进行设置，并在通信协议中进行规定。根据NB-IoT通信规则以及实际测试结果，一般建议每次上报的数据长度不超过 1024 字节。每个数据包都有一个编码，用于标识它是第几个数据包。当出现传输错误、CKS 校验不正确或接收超时等问题时，终端设备会反馈错误接收的数据包的编码。云平台根据反馈的编码，重新发送相应数据包直到正确接收。当终端设备成功接收完当前数据包后，会向云平台返回一个应答信号，表明当前数据包已经正确接收。此过程将一直重复，直到整个固件升级过程完成。云平台下发数据至设备端后，设备触发串口中断，完成升级指令的接收，同时反馈一个成功标志，并且进入等待状态；待接收到第一组数据包后，临时存储在 MCU 内部 Flash 中，并且反馈数据接收状态，若是接收成功，则将数据包序号字段加一然后上报给云端平台，待所有升级包接收完成且验证正确后，设备向云端发送一个升级成功标志，软件复位重启系统，完成升级。若所有升级数据都接收完毕，但升级包本身存在问题导致校验失败，则系统复位，恢复成旧程序，等待下一次系统唤醒后再次启动升级程序。3 批量分布式设备通信模式设计 NB-IoT 基站的容量取决于多个因素，包括频谱配置、调制方案、信道数量等。根据目前的技术参数和仿真测试数据，单个 NB-IoT 基站只能同时允许 15 台NB 设备并行通信，因此在设计大批量分布式物联网设备通信时，需要考虑信道竞争问题。针对此问题，本文设计了一种随机延时唤醒方案，在设备准备休眠时，将休眠时间设置成一个真随机数，随机数的间隔设置按设备数量而定，保证在一座基站下不超过 15 台设备同时工作。通信模式设计的时候需要考虑到接收到错误返回值或者接收超时等情况，同时针对这些情况采取相对策略，例如抛弃数据，请求重发或者直接进入休眠状态等。然而在偏远地区，由于信号质量差，或者设备遭到屏蔽导致 M5311 模组无法连接至网络时，需设计一个异常处理方式，即多次连接不上，终端设备进入睡眠状态，以避免电池长期处于放电过程。本文采取退避算法来进行状态的判断，入网 9 次不成功则进入休眠状态，直到下一次唤醒周期才再次尝试注网6。同时，由于设备数量较多，每台设备传输数据量较大，对于偏于地区信号时好时差的情况，难免会出现设备能注网成功，但是数据上传失败或接收回包超时等问题。本文设计了一种重传机制，即当设备注网成功，在发送数据后接收来自云平台的回包判断错误或者超时，则最多重复发送此数据 99 次，直至接收到正确的回包值。经过多次验证，此传输方式能在信号时好时差的情况下将数据包完整的上传。4 实验结果与分析 远程升级系统硬件部分如下图 5 所示。软件设计的验证也是基于此终端设备完成。图 5 远程升级系统硬件 使用 Simplicity Studio 完成 Bootloader 和主程序后，使用 SWD 分别烧写到 Flash 的初始区和代码区。系统启动后从初始区跳转到代码区开始工作，等待M5311 注网、上报数据后，开始远程升级测试。为验证升级速度，将新编译的.hex 文件扩充到 142KB，以每包 512 字节发送，共 204 包升级数据包，全程需 960s。中国科技期刊数据库 工业 A-36-为验证重传机制，将 55 套设备放在实验室密闭空间中，先后测试两套程序，前 10 次为每包数据重传 3次，后 10 次为每包数据重传 99 次，每当传输超过重传次数，则设备进入休眠状态，视为升级失败，测试结果如图 6 所示。图 6 两种重传机制实验对比结果 从前后 20 次升级实验结果可以看出，当每一小包重传次数为 3 次时，有大量设备不能一次性升级成功，而当重传次数设置为 99 次时，一次性升级成功的概率基本为 1。其中，第 10 次和第 11 次实验上报的数据包数如下图 7 和图 8 所示，可以看出在信号不稳定的情况下，NB 设备上报数据成功率并不高，需要增加重传次数，以保证一次性升级成功。图 7 第 10 次升级上报包数 图 8 第 11 次升级上报包数 为在实际工况条件下验证、调试本升级系统，本文选择在上海 16 号线野生动物园站上行区间，入轨安装设备，并开展测试研究。设备安装场景如图 9 所示。图 9 设备安装场景 共计 55 套设备上电之后，每日定时唤醒 NB 设备上报数据，从 2023 年 10 月 15 日起，给随机唤醒的设备进行程序升级，测试结果如图 10 所示。到 2023 年10 月 16 日止，55 台设备全部升级完成。图 10 联网监测设备远程升级测试结果 本系统设计可靠性主要体现在以下几个方面：1）模组经过多次重新注网以及数据重传，可以保证在偏远地区无线信号不稳定的情况下数据传输成功率达到 100%。2）当无线模组多次连接不上，终端设备进入睡眠状态，以避免电池长期处于放电过程。3）设备因休眠导致升级暂停，唤醒后可通过上传已保存的数据包序号，断点继续执行，不必重新发送所有数据。4）缺包查询机制严谨，保证设备完整的接收到所有升级包。5）设备将收到的升级数据以相同方式校验，与上位机发来的 CKS 对比，确保升级数据正确。5 结语 本文详述了远程升级设备的硬件架构，同时，本文对应用软件程序和嵌入式软件程序的设计流程进行了详细介绍。实现了基于 NB-IoT+EFM32PG22+OneNET云平台的物联网设备的远程在线升级。在上海轨道交通运营线路试点应用中，完成了 55 套声屏障联网监测设备远程升级测试。经过系统验证和分析，本文所设中国科技期刊数据库 工业 A-37-计的批量分布式设备通信模式设计方法可以解决恶劣环境、偏远地区等特殊情况下程序升级及维护的可靠性问题。尤其是当设备数量众多且分布范围广泛时，该方法可以显著提高工作效率，降低维护成本，具有很高的应用价值。参考文献 1吕春艳,靳占军,钟贻兵等.4G 无线通信技术的单片机远程升级研究J.单片机与嵌入式系统应用,2019,19(11):60-64.2李少白.无线蜂窝物联网发展J.通信电源技术,2020,(14):139-141.3郑俊翔,陈朱峰,朱伟.4G 网络和 STM32 的远程系统升级J.电子世界,2021(08):87-89.4黄河.嵌入式设备远程固件升级J.西部广播电视,2020,41(21):228-230.5Russell King.Booting ARM LinuxZ.Linux Documentation.May 2002 6汪宏伟.基于 NB-IoT 和振动检测技术的无线智能终端D.安徽:安徽大学,2022.基金项目：既有线土建设施大修更新及技术改造策略研究项目（JS-KY21R006-2）。