摘要: 变制冷剂流量(VRV) 空调控制系统具有多传感器、温度数据具有时滞特性，维护程序代码和功能调试非常困难，因而提出利用VRV 系统的通信网络和单片机的Bootloader 特性，开发基于CAN 总线的远程下载功能。根据VRV 控制系统的应用需求，制订了通讯协议，实现了包括单点、多点及广播等多种远程下载方式，并具有软件复位、数据加解密、异常处理等新功能。该技术已经应用于VRV 空调控制系统的开发调试，应用效果良好。
0 引 言
变制冷剂流量(Variable Refrigerant Volume, VRV)空调系统是一种网络空调系统，由制冷剂管路网络和通讯信息流网络组成，并且一台室外机通过配管和通讯总线连接多台室内机，由在监控室的监控PC 机，监控整个系统的运行状态。系统结构简图如图1 所示。
VRV 空调系统结构简图
图 1 VRV 空调系统结构简图
系统控制信息通过通信网络传输，实现对制冷剂管路网络中制冷剂流量的精确调配，可使系统具有控温舒适可靠、节能环保、节省建筑空间等优势，近十几年得到迅猛的普及。
通讯信息流网络是VRV 系统的重要组成部分。下文为叙述方便，将监控PC 机称为主机端、室外机和室内机统称为目标端。
由于每套系统都有多个参数需要传感器实时检测，并且温度数据本身具有很大的时滞性，因而维护程序代码和功能调试非常困难。本文提出一种利用VRV 的通信网络和监控PC机进行程序远程下载的方法。
另外，VRV 空调系统的通信信息流网络目前还没有统一的总线标准，国际上各大厂家都是制定自己的总线标准，兼容性不够。我们在系统设计VRV 控制系统时，经多方比较，最后鉴于CAN 总线高安全性、故障自动退出等优势，选择CAN 总线作为系统的通讯总线。
VRV 系统的室外机和室内机选一款支持CAN 模块的MICroChip公司的DSPIC33FJ 单片机作为主控制芯片。并且这款单片机本身支持Bootloader 功能，这为开发远程下载，进而实现系统维护和程序更新提供了一种可能。
本文开发出一种基于 CAN 总线，支持单点、多点及广播等多种方式的远程下载的技术，并具有软件复位、异常处理、数据加/解密等突出功能。这些功能极大方便了对VRV 空调控制系统的维护和应用，也为初期进行空系统的设计、开发、调试提供了一种极为便利的手段。
1 总体设计方案
1.1 远程下载原理
目标端复位后，在一个指定的时间内，目标端都监测与主机端相连的通讯总线是否有数据流活动。如果有，则跳转到Bootloader 自举程序，执行Bootloader 自举功能，将接收的数据，写入目标端的用户应用程序段，直到全部数据接收完成后，再跳转到用户应用程序段，执行刚接收到的新代码，实现用户应用程序的更新。如果超过时限，都没有监测到该总线上有数据流活动，则直接跳转到用户应用程序段，执行原有的程序功能。
在此一共有三段程序：
⑴目标端的自举程序和用户应用程序。这两个程序都是基于MAPLAB IDE 工具开发。
⑵主机端程序。这个程序是用Visual Studio C++开发，只有主机端程序才能主动发起与目标端自举程序间的通信。
整个通讯过程如图2 所示，其中：
(1)主机端程序读取和解析MAPLAB IDE 编译器生成的用户应用程序，并组织数据。
(2)通过CAN 总线将解析、重组后的数据传输给目标端器件。
(3)目标端自举程序(Bootloader)，将收到的数据加载到目标端器件相应的FALSH 段上。
通讯过程示意图
图 2 通讯过程示意图
www.55dianzi.com
1.2 系统功能设计
在整个设计开发中，关键之处是目标端 Bootloader 自举程序的开发。结合到VRV 空调系统的实际应用，整个系统应该至少具有以下功能：
(1)多种下载方式的提供。VRV 空调系统运行当中，可能需要根据实际情况采用不同的方式来进行远程下载。因而需要实现对单点、多点及广播等通讯方式的支持。
(2)软件复位功能。即便是目标端设备已经具备利用Bootloader 自举程序来实现远程下载的能力，但由于Bootloader 机制需要目标端先复位，才能重新再执行Bootloader 自举程序。
然而现场环境往往不能实施掉电或其他硬件方式复位目标端设备，这便需要有软件实现复位的手段。在此，将软件复位作为自定义的通讯协议中一个命令，由主机端发送给目标端，目标端的用户应用程序内接收到这一命令，经过解析、确认后进行复位。
(3)加/解密功能。鉴于多联机空调系统的商用价值，Bootloader 程序应当具备加密的功能，保护知识产权。这可以通过主机端和目标端之间采用一种密钥或加、解密算法，融合到通讯数据中实现。
(4)异常处理功能。在通讯过程中，很有可能出现如主机端出现故障，造成当前的数据不能继续成功发给目标端。目标端运行自举程序时，只有等到主机端数据全部通讯完毕，才可以跳转到用户应用程序，继续执行。此会造成目标端一直处于等待状态，效率低下或者接收错误数据并执行，以致出现严重后果。在系统设计开发时需要预留一个能够实现异常处理的命令以便主机端恢复后，将这个命令下发，目标段根据这个命令，重新接收正确的数据。
2 协议设计
要将系统的目标端和主机端之间，设计成支持单点、多点以及广播等多种远程下载方式，并且支持、软件复位和异常处理、加解密等功能，可以充分利用 CAN 总线数据帧的29 位（遵循CAN2.0B 协议）标识符来实现。定制的通讯协议中CAN 的帧格式如表1 所示，将CAN 的29 位标示符分为五段：优先级、控制域、通讯方式、节点编号、命令编号。
表 1 数据帧29 位标识符分配表
数据帧29 位标识符分配表
优先级：00->01->10->11 优先级别依次降低，默认优先级别为11，故障报警优先级最高为00，数据传输优先级为01，命令下传优先级为10，应答返回优先级为11。
控制域：ID26/ID22，用以表示当前的数据帧属于哪一种类型：故障为00、数据为01、命令10、应答11。
通讯方式：ID24/ID15，指定当前的数据帧是广播传输或者单点传输，全为0 是单点而全为1 是广播。
节点编号：ID14/ID8，共7 位，足够标识CAN 总线支持的多达112 个节点的最大负载。
命令编号：这里存放的是根据实际需要定制的一些命令，如软件复位命令、异常处理命令。主机端将定制的命令编号下发，目标端接收到命令后，解析后执行相应动作。仿照上表，配置各个目标端的接收过滤码和接收屏蔽码，便可以实现单点、多点以及广播通讯。另外，对于单点通讯方式下的远程下载，为保证主机端和目标端的通讯数据的正确和可靠传输，采用应答机制来实现，并定制了一套图3 所示的通讯链路机制。
主机端和目标端应答链路机制图
图 3 主机端和目标端应答链路机制图
远程下载的通讯只能由主机端开启。主机端先发送读取器件型号命令，读取目标端器件芯片型号，目标端收到这个命令，回复本身的型号数据作为一个应答，主机端根据这个型号，再开辟动态内存和组织要下传的数据。主机端接着下发一个读取器件PROM 命令，以获取目标端器件位于地址0x00 处的数据，将和从主机端读取并解析、组织后的HEX 文件一起下传。主机端收到这一步的应答后，开始发送写PROM 命令和PROM 数据，目标端将接收到的数据写入相应的地址段，每完成一页写操作，返回一个应答,接着接收主机端下传的下一页数据。PROM 写数据发送完后，主机端接着发送写CM 数据命令和写CM 数据，过程和写PROM 是一样的。最后，主机端下发一个跳转命令，目标端收到这个命令后，跳转到程序存储器的0x00 地址处。然后，目标端根据地址0x00 处存放的数据，跳转到用户应用程序。
而对于多点或广播，通常都是对数百甚至上千目标端进行下载。如果目标端都应答，会造成总线上数据的堵塞，浪费大量的总线时间。所以采用非应答机制，直接烧写程序存储器。
此时主机端数据的下传，采用定时器触发方式。每当定时时间到达时，触发一次数据的发送。
直至最后，发送一个跳转命令。如果目标端没有执行跳转，那么认为当前目标端没能正确接收主机端发送的数据，主机端重新对当前目标端进行一次单点方式下的远程下载。
3 目标端设计方案
目标端Bootloader 自举程序一般只是一个简单的通讯程序，负责接收和发送数据，通常只需极少的存储空间，可以位于单片机程序存储器特定的Boot Segment 区域。程序存储器还有一段称为General Segment 区域可用于存储用户应用程序。单片机的程序存储器大多都是FLASH 闪存，数据是以一个个数据页的形式存储，必须先对当前存储页擦除，然后才能写入数据。自举程序还需使用DSPIC33 单片机器件中断向量表 (IVT) 中的复位向量实现程序的跳转、以及器件上的CAN 通信模块。单片机的程序存储器的地址映射如下图4 所示。
