CN115033264A - 一种供暖阀门控制系统的远程更新方法 - Google Patents

Abstract

本申请提供一种供暖阀门控制系统的远程更新方法，包括：将所述控制终端的芯片上电，初始化所述终端的BIOS程序，所述终端的程序包括BIOS程序和User程序，BIOS程序负责系统正常初始化运行，提供工作时钟及底层驱动构件，驻留在FLASH固定段，User程序负责用户程序，提供驱动以及软件调用接口；在BIOS程序初始化完成后，进入User程序执行main主函数，当User程序中断服务程序检测到所述服务器通过串口通讯发送的更新标志时，则跳转至BIOS程序，等待客户端将完整更新文件传入终端，重新跳转至新的User程序继续运行。本申请可在短时间内完成终端设备的程序更新，不仅可以修复程序漏洞，还能新增设备功能，提升系统性能。

Description

一种供暖阀门控制系统的远程更新方法

技术领域

本申请涉及供暖阀门控制技术领域，尤其涉及一种供暖阀门控制系统的远程更新方法。

背景技术

阀门设备分布广、数量多、放置环境复杂，可能在热力管线总管道、小区热力管线入口主管线、楼栋支线出口以及每个用户终端热水表的后端等地区，开发人员无法对部署环境考虑周全，再加上用户需求的多样化以及程序本身的缺陷，后期需要不断的更新终端程序。传统的终端程序升级方式，开发人员需要携带相关的程序烧写工具到现场进行更新，这种方式不仅要消耗大量的人力物力，而且对工作人员有一定的专业要求，综合考虑难度太大，且存在一定的安全隐患。因此，阀门远程控制系统需要具备远程更新的能力，对节点进行灵活地配置和升级以适应环境变化。

当前国内外对物联网终端远程更新的研究集中在网络数据通信协议和代码分发机制上，着重于更新算法、可靠性、安全性方面的研究。Glas等人设计了一种基于比特流更新的可重构硬件的可信平台功能原型。Jianhe等人为了及时更新变量系统，提出了一种基于分布式对象技术的更新策略。Cuijuan等人为了克服DSP和MSP430仿真器在现场调试带来的高成本系统维护的问题，采用模块化设计方法，实现了基于以太网的系统程序远程更新方案。还有文献分析并设计了一种基于GPRS技术的远程更新系统。Kachman和Jurkovic等人都研究了用于资源受限的低功耗嵌入式设备的远程固件更新方案。Ulz等人在探讨了远程配置更改带来的安全问题。

由于阀门现场环境复杂以及用户需求，终端程序在实际使用过程中需要不断完善和更新。让工作人员前往阀门现场进行终端程序更新是不切实际的。

发明内容

有鉴于此，本申请的目的在于提出一种供暖阀门控制系统的远程更新方法，本申请能够针对性的解决现有的问题。

基于上述目的，本申请提出了一种供暖阀门控制系统的远程更新方法，所述控制系统包括客户端、服务器和控制终端，包括：

将所述控制终端的芯片上电，初始化所述终端的BIOS程序，所述终端的程序包括BIOS程序和User程序，BIOS程序负责系统正常初始化运行，提供工作时钟及底层驱动构件，驻留在FLASH固定段，User程序负责用户程序，提供驱动以及软件调用接口；

在BIOS程序初始化完成后，进入User程序执行main主函数，当User程序中断服务程序检测到所述服务器通过串口通讯发送的更新标志时，则跳转至BIOS程序，等待客户端将完整更新文件传入终端，重新跳转至新的User程序继续运行。

进一步地，所述控制终端基于存储分割的方式接收所述更新文件的数据帧，并辅以丢帧重传保护机制，完成在线程序更新。

进一步地，所述User程序为Hex文件，所述服务器在提取Hex文件时，首先使用结构体变量存储Hex文件中每行数据，包括记录长度、地址偏移量和数据段，然后根据记录的不同类型，将对应的记录使用多个结构体以链表的形式保存。

进一步地，所述服务器在与终端数据交互前，先对传输的数据进行组帧，将通信帧格式分为帧头、IMSI号、接收地址、数据长度、数据帧类型、更新数据、CRC校验码和帧尾8个字段。

进一步地，所述数据帧类型分为7种，分别是握手数据帧、开始数据帧、复制数据帧、插入数据帧、校验数据帧、命令数据帧和返回数据帧；其中，握手数据帧负责确认与终端建立通信连接；开始数据帧负责给终端开始更新操作的提示；复制数据帧负责提示终端进入BIOS程序，然后准备好要传输的Hex文件；插入数据帧负责将待更新的Hex文件一条一条的传输至终端；校验数据帧负责在远程更新结束时确认服务器是否丢帧；命令数据帧负责提示终端执行已更新的User文件；返回数据帧负责提示终端此次远程更新结束。

进一步地，所述控制终端的FLASH存储空间划分为BIOS区、User区、更新区三个部分；

所述BIOS区的内容包括BIOS启动代码和BIOS中断向量表，负责存储基础的底层驱动构件、芯片启动初始化工作、以及远程更新相关函数；User区为用户程序，负责实现用户对终端的具体需求，存储大小根据功能需求而定；更新区是缓存区域，存放终端远程更新后接收到的新User文件，在新User文件完全接收并且检验结束后，User区被覆盖成新User文件，从而完成远程更新任务。

进一步地，进一步包括：

将驱动构件固化在BIOS区，然后向User区提供驱动函数的入口地址，使得User区可以直接调用BIOS区的函数。

进一步地，所述调用的步骤如下：

BIOS区定义一个驱动函数数组，此数组负责存储BIOS区所有驱动构件的地址；

User程序根据数组和驱动构件的偏移量获取每个驱动函数的入口地址，即可实现函数调用。

进一步地，所述数据帧设有应答机制，7种数据帧都有CRC校验码，当检查到CRC校验码错误的数据帧时，则会实时返回错误状态码至服务器的远程更新软件，通知服务器端重传该帧数据；

在接收到错误信息后将丢帧信息返回给服务器的发送端请求补发，发送端在接收到返回失败的应答帧后将失败帧号存储在缓冲区，等待所有数据帧发送完毕后，发送端遍历该缓冲区，根据缓冲区存储的帧信息，对应重新发送丢失的帧。

进一步地，终端在接收到插入数据帧最后一帧数据后，对整体数据帧进行一次校验操作；

如果出现丢帧问题，则对所有帧重新校验，标记已丢失的帧号，并且通知服务器端重新传输丢失的数据帧；

在传输结束后，再次进行校验操作，直至所有数据帧成功接收，最后执行更新命令。

总的来说，本申请的优势及给用户带来的体验在于：本申请提出远程更新技术，可在短时间内完成终端设备的程序更新，不仅可以修复程序漏洞，还能新增设备功能，提升系统性能。

附图说明

在附图中，除非另外规定，否则贯穿多个附图相同的附图标记表示相同或相似的部件或元素。这些附图不一定是按照比例绘制的。应该理解，这些附图仅描绘了根据本申请公开的一些实施方式，而不应将其视为是对本申请范围的限制。

图1示出本申请的Hex文件部分截图。

图2示出根据本申请实施例的终端芯片Flash分区图。

图3示出将远程更新界面示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

1远程更新设计与实现

本申请提出的远程更新设计方案包括服务器端的远程更新软件和终端的软件设计。远程更新软件通过多种通信帧的交互，将更新文件解析后发送至终端，终端基于存储分割的方式接收数据帧，并辅以丢帧重传保护机制，完成在线程序更新。

1.1远程更新技术方案

实验室通用嵌入式计算机(General Embedded Computer，GEC)框架下终端程序分为BIOS程序和User程序两个部分，BIOS程序负责系统正常初始化运行，提供工作时钟及底层驱动构件，驻留在FLASH固定段，User程序负责用户程序，提供驱动以及软件调用接口，完成具体的用户功能需求。芯片上电后，首先执行BIOS程序部分，然后转向User程序。

据此，在包含STM32L431芯片和ME3616通信模组的控制终端上，本申请提出了一种远程更新方案，该方案的核心思想是：BIOS程序初始化完成后，会进入User程序执行main主函数，当User程序中断服务程序检测到远程更新软件通过串口通讯发送过来的更新标志时，则跳转至BIOS程序，等待客户端将完整更新文件传入终端(更新User程序完成)，重新跳转至新的User程序继续运行，此过程就完成了远程更新操作。

1.2服务器端更新文件处理

1.Hex文件解析

Makefile文件对编译规则和连接规则进行了定义，规定了不同文件的编译顺序，并生成目标可执行文件。Hex的全称是Intel HEX，Intel HEX文件以行为单位，每一行包含一个Hex记录，这些记录由对应的机器码十六进制编码数字组成。Hex文件中每行记录由6个部分组成，如表1所示。

表1Hex文件记录格式

Hex文件共有6种记录类型00～05，00表示数据记录；01表示文件结束记录；02表示扩展段地址记录；03表示开始段地址记录；04表示扩展线性地址记录；05表示链接开始地址记录。Hex记录中数据段为有效数据，该字节长度取决于记录类型，为保证Hex记录的正确性，设置有校验和，其计算公式为：校验和＝0xFF-(数据长度+偏移量+类型+数据段)+0x01。

图1是本系统中User程序编译后的Hex文件部分截图，现以第一行记录“:1000100051040000510400005104000000000000E1”为例演示Hex记录的组成。先将此记录按格式进行语义分割“:10 0010 00 51040000510400005104000000000000E1”。首先“:”表示开始标记，此条记录长度为“0x10”，即16个字节，“0010”表示地址偏移量，“00”为数据记录类型，“51040000510400005104000000000000”表示该数据段从地址0x0010处开始存放，“0xE1”表示该记录的校验和。

本申请设计的远程更新软件在提取Hex文件时，首先使用结构体变量存储hex文件中每行数据，包括记录长度、地址偏移量和数据段等，然后根据记录的不同类型，将对应的记录使用多个结构体以链表的形式保存，这样就可以高效的定位和获取到Hex记录中有效数据和对应地址偏移量，方便传输出需要的数据。

2.通信帧格式

服务器端的远程更新软件在与终端数据交互前，需要先对传输的数据进行组帧，根据本系统的需求，将通信帧格式分为帧头、IMSI号、接收地址、数据长度、数据帧类型、更新数据、CRC校验码和帧尾8个字段，格式如表2所示。

表2更新帧格式

从远程更新软件与终端通信角度，数据帧类型可以分为7种，分别是握手数据帧、开始数据帧、复制数据帧、插入数据帧、校验数据帧、命令数据帧和返回数据帧。握手数据帧负责确认与终端建立通信连接；开始数据帧负责给终端开始更新操作的提示；复制数据帧负责提示终端进入BIOS程序，然后准备好要传输的Hex文件；插入数据帧负责将待更新的Hex文件一条一条的传输至终端；校验数据帧负责在远程更新结束时确认服务器是否丢帧；命令数据帧负责提示终端执行已更新的User文件；返回数据帧负责提示终端此次远程更新结束。

1.3终端更新文件接收

1.芯片存储空间划分

本小节根据远程更新需求及烧入的Hex文件大小，对主控芯片STM32L431的FLASH存储空间进行划分，以保证程序运行更加高效和可靠。如图2所示，本系统芯片STM32的FLASH存储大小为256KB，物理起始地址为0x08000000，到0x08040000地址结束，将其主要划分为BIOS区、User区、更新区三个部分。

BIOS区设置存储大小28KB，此区内容包括BIOS启动代码和BIOS中断向量表，负责存储基础的底层驱动构件、芯片启动初始化工作、以及远程更新相关函数。User区为用户程序，负责实现用户对终端的具体需求，存储大小根据功能需求而定。更新区是缓存区域，存放终端远程更新后接收到的新User文件，在新User文件完全接收并且检验结束后，User区会被覆盖成新User文件，从而完成远程更新任务。

2.驱动构件共享

为合理有效的进行存储空间设计和减少程序的总代码量，本节提出使用驱动构件共享机制，其核心思想是将基础的驱动构件固化在BIOS区，然后向User区提供这些驱动函数的入口地址，这样User区不用重复实现基础构件，可以直接调用BIOS区的函数。其调用步骤如下，首先BIOS区需要定义一个驱动函数数组，此数组负责存储BIOS区所有驱动构件的地址；然后User程序根据数组和驱动构件的偏移量可以获取每个驱动函数的入口地址，即可实现函数调用。STM32属于ARM系列芯片，内部提供SVC软件中断机制，先将上述数组首地址存入寄存器r0中，当芯片运行至User程序时利用中断机制将寄存器r0的值取出，就能获取到BIOS中各驱动构件的入口地址。利用驱动构件共享机制可有效减少User区的代码量，也防止了User程序干预底层寄存器，增加了程序的层次性和安全性。

1.4丢帧重传保护机制

为了保证数据包传输的完整性，本申请设计了丢帧重传保护机制，当数据传输过程中出现丢包的情况，则重新传输已丢失的数据包。远程更新方案基于窄带物联网应用架构，并结合上文介绍的通信帧格式，实现了有两层防护的丢帧重传机制。丢帧重传机制是指发生数据帧丢失后，将丢失帧重新发送，从而保证数据完整性，提高更新成功率的一种数据传输处理机制。

第一层防护是通信帧中的数据帧设有应答机制，7种数据帧都有CRC校验码，当检查到CRC校验码错误的数据帧时，则会实时返回错误状态码至远程更新软件，通知服务器端重传该帧数据。在接收到错误信息后将丢帧信息返回给发送端请求补发，发送端在接收到返回失败的应答帧后会将失败帧号存储在缓冲区，等待其他所有数据帧发送完毕后，发送端会遍历该缓冲区，根据缓冲区存储的帧信息，对应重新发送丢失的帧。第二层防护是终端在接收到插入数据帧最后一帧数据后，会对整体数据帧进行一次校验操作。如果出现丢帧问题，则对所有帧重新校验，标记已丢失的帧号，并且通知服务器端重新传输丢失的数据帧。等到传输结束，再次进行校验操作，直至所有数据帧成功接收，最后执行更新命令。

2远程更新软件测试

如图3所示，服务器端的远程更新程序使用C#语言编写，界面打开后会自动进行终端程序更新，首先选定一个已和服务器通信的阀门终端(与IMSI号对应)，再导入新的Hex文件即编译后的User程序，然后Hex文件会一帧一帧的烧入芯片中，直到更新完成。

在测试远程更新程序稳定性时，通过对不同的终端(对应不同的IMSI号)进行了多次更新操作，并且采用不同字节大小的Hex文件，其测试结果如下表3。

表3远程更新成功率测试

测试结果表明本申请设计的远程更新程序成功率接近100％，更新耗时和Hex文件大小成正相关，更新失败后，终端会回到之前的User程序继续执行，等待下一次的更新。

3小结

本申请提出一种基于NB-IoT的远程更新解决方案，对终端芯片的FLASH进行合理分配，分为芯片启动初始化工作区、用户程序区、更新区，并设计丢帧重传保护机制，提高更新的成功率。与传统的烧写程序方式相比，本申请设计的远程更新方案具有实时性强、更新时间短、操作简单等特点。经测试，此方案可实现远程程序更新功能，已成功应用于供暖阀门远控系统中。

需要说明的是：

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备有固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本申请也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请的内容，并且上面对特定语言所做的描述是为了披露本申请的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本申请并帮助理解各个发明方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本申请的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本申请实施例的虚拟机的创建系统中的一些或者全部部件的一些或者全部功能。本申请还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者系统程序(例如，计算机程序和计算机程序产品)。这样的实现本申请的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本申请进行说明而不是对本申请进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干系统的单元权利要求中，这些系统中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到其各种变化或替换，这些都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种供暖阀门控制系统的远程更新方法，所述控制系统包括客户端、服务器和控制终端，其特征在于，包括：

将所述控制终端的芯片上电，初始化所述终端的BIOS程序，所述终端的程序包括BIOS程序和User程序，BIOS程序负责系统正常初始化运行，提供工作时钟及底层驱动构件，驻留在FLASH固定段，User程序负责用户程序，提供驱动以及软件调用接口；

在BIOS程序初始化完成后，进入User程序执行main主函数，当User程序中断服务程序检测到所述服务器通过串口通讯发送的更新标志时，则跳转至BIOS程序，等待客户端将完整更新文件传入终端，重新跳转至新的User程序继续运行。

2.根据权利要求1所述的方法，其特征在于，

所述控制终端基于存储分割的方式接收所述更新文件的数据帧，并辅以丢帧重传保护机制，完成在线程序更新。

3.根据权利要求1或2所述的方法，其特征在于，

所述User程序为Hex文件，所述服务器在提取Hex文件时，首先使用结构体变量存储Hex文件中每行数据，包括记录长度、地址偏移量和数据段，然后根据记录的不同类型，将对应的记录使用多个结构体以链表的形式保存。

4.根据权利要求3所述的方法，其特征在于，

所述服务器在与终端数据交互前，先对传输的数据进行组帧，将通信帧格式分为帧头、IMSI号、接收地址、数据长度、数据帧类型、更新数据、CRC校验码和帧尾8个字段。

5.根据权利要求4所述的方法，其特征在于，

所述数据帧类型分为7种，分别是握手数据帧、开始数据帧、复制数据帧、插入数据帧、校验数据帧、命令数据帧和返回数据帧；其中，握手数据帧负责确认与终端建立通信连接；开始数据帧负责给终端开始更新操作的提示；复制数据帧负责提示终端进入BIOS程序，然后准备好要传输的Hex文件；插入数据帧负责将待更新的Hex文件一条一条的传输至终端；校验数据帧负责在远程更新结束时确认服务器是否丢帧；命令数据帧负责提示终端执行已更新的User文件；返回数据帧负责提示终端此次远程更新结束。

6.根据权利要求4或5所述的方法，其特征在于，

所述控制终端的FLASH存储空间划分为BIOS区、User区、更新区三个部分；

所述BIOS区的内容包括BIOS启动代码和BIOS中断向量表，负责存储基础的底层驱动构件、芯片启动初始化工作、以及远程更新相关函数；User区为用户程序，负责实现用户对终端的具体需求，存储大小根据功能需求而定；更新区是缓存区域，存放终端远程更新后接收到的新User文件，在新User文件完全接收并且检验结束后，User区被覆盖成新User文件，从而完成远程更新任务。

7.根据权利要求6所述的方法，其特征在于，进一步包括：

将驱动构件固化在BIOS区，然后向User区提供驱动函数的入口地址，使得User区可以直接调用BIOS区的函数。

8.根据权利要求7所述的方法，其特征在于，

所述调用的步骤如下：

BIOS区定义一个驱动函数数组，此数组负责存储BIOS区所有驱动构件的地址；

User程序根据数组和驱动构件的偏移量获取每个驱动函数的入口地址，即可实现函数调用。

9.根据权利要求5所述的方法，其特征在于，

所述数据帧设有应答机制，7种数据帧都有CRC校验码，当检查到CRC校验码错误的数据帧时，则会实时返回错误状态码至服务器的远程更新软件，通知服务器端重传该帧数据；

在接收到错误信息后将丢帧信息返回给服务器的发送端请求补发，发送端在接收到返回失败的应答帧后将失败帧号存储在缓冲区，等待所有数据帧发送完毕后，发送端遍历该缓冲区，根据缓冲区存储的帧信息，对应重新发送丢失的帧。

10.根据权利要求5所述的方法，其特征在于，

终端在接收到插入数据帧最后一帧数据后，对整体数据帧进行一次校验操作；

如果出现丢帧问题，则对所有帧重新校验，标记已丢失的帧号，并且通知服务器端重新传输丢失的数据帧；

在传输结束后，再次进行校验操作，直至所有数据帧成功接收，最后执行更新命令。

Images