2020年07月29日 | 采用32位ARM处理器实现现场数据采集器的设计方案

方便、舒适、高效、安全，以及环保节能等作为人们对自身生活和工作场所的基本要求由来已久。自上世纪90年代以来，随着数字通信技术和信息技术的飞速发展，基于网络的智能化建筑和住宅是该领域的一个主要发展方向。

现介绍其中一种利用ARM技术、嵌入式实时内核和TCP协议设计的现场数据采集器。

1、现场数据采集器的基本功能

“一线通”系统的基本架构如图1所示，3台管理计算机互为冗余。

系统是面向设备管理的，基本功能可归结为三点，即“监”、“控’’和“报警”。“监”是指管理机查询设备的状态；

控，是管理者通过监控界面操纵现场设备；“报警”是当设备运行状态超越报警限时，及时向管理机报告。管理机监控界面采用组态王6.5通用组态软件进行设计。

“一线通”系统将监测与报警合并。在现场，设备的DEC控制器和智能仪表通过485总线连接到数据采集器，在整理设备状态数据的基础上，根据状态的变化，由采集器向管理机发送设备最新变化状态。彻底避免了无谓的查询，减轻了网络的通信负荷。这就是数据采集器的由来。

现场数据采集器的基本功能要求分为两个方面。首先，要定期采集各DDC控制器（以下称子站）和智能仪表中的状态数据，并将状态变化信息发送到管理机。其次，也要传递管理机对设备的控制命令。

2 、现场数据采集器的设计实现

设计采用了EasyARM2200开发板，CPU是Philips公司的32位嵌入式处理器LPC2210（ARM7TDMI-S核）。开发板基本结构如图2所示［1］。CPU采用11.059 2 MHz晶振，通过片内锁相环和外设分频器，分别获得44 MHz系统时钟和11 MHz外设时钟频率。串行通信波特率为19 200 bps。

采集器用C语言编制实现。设计大致分四步进行。

（1） 协议设计

在“一线通”系统中，设备以采集器号、子站号和设备号惟一确定。管理机用采集器号区别局域网上的采集器。采集器用子站号标识总线上的DDC控制器。同一子站下可能有不止一个设备，相互以设备号区分。

所有的状态和控制数据都以设备为单位进行组织。通过工程项目的配置文件，系统中确定的设备与具体设备类型联系起来。采集器中设备状态数据块格式定义为

设备状态数据和控制数据格式由设备类型数据协议规定。

采集器与子站的串行通信数据帧基本格式为

所有协议数据传输字节加ETX生成校验和。由16个ASCII字符O～9、A～B作为传输字节对协议数据和校验和进行编码，传输字节的最高位用作奇偶校验位。

通信采用主从方式，由采集器向子站写控制数据。写命令帧协议数据为

其中Write为写命令字节。设备控制数据块可任意组合到写命令帧中。

读设备数据时，采集器先发读子站命令，并等待应答。相应子站在收到读命令后，还以应答帧。读命令帧协议数据为

其中Read为读命令字节。子站应答帧协议数据为

采集器与管理机的通信应用层用户数据报基本格式为

设备状态数据块或控制数据块可任意组合到用户数据域中。标志字符指明用户数据的类型。例如，是采集器向管理机发送的设备状态数据块组合，还是管理机向采集器发送的设备控制数据块组合。

（2）数据结构

采集器中，为设备控制数据块设置从网口到串口的队列。设备状态数据块须定期地从各子站中读取并刷新存储，变化的状态须向管理机发送。为此，设置子站项和设备记录块两种基本结构，构成三种链表，如图3所示。

子站项的基本域是子站号。各子站项通过指针NextDDC相互连接，构成一个循环链表，管理对子站的采集过程。指针CurrDDC指向当前正被访问的子站项。采集器根据CurrDDC沿循环链表的依次移动，确定下一个访问的子站站号。

在子站项数据域中设置了一个故障计数器。当某子站对采集器读命令连续多次无正常应答时，采集器判定其故障，将暂停对其读取，并启动计数器。计时结束后再尝试重新访问该子站。如果成功，便恢复正常；否则，停止读取而重新计时。这样将大大减少对故障子站的超时等待时间，实现了故障屏蔽和自动恢复的连接重试功能。

设备记录块的基本域是设备号。在其记录数据域中存放着一个完整的最新设备状态数据块，由记录长度域指明长度。

每个子站下连接着数目不等的若干个设备，每个设备对应一个设备记录块。同一子站下的设备记录块通过指针域RBPtr连成一个单链表。采集器能根据子站下设备的增加自动添加设备记录块。

状态发生变化的设备记录块由指针域RBInList连接成发送链表。以太网发送程序将给设备状态数据块加上采集器号，组合到用户数据报中。这样的方式能保证发送设备最新的状态数据。

（3）任务设计

μC/OS-II（v2.52）被移植到LPC2210上，是独立于采集器程序外的一段代码。作为可剥夺型内核，它能保证实时性的需要，使时间要求苛刻的事件得到快捷的处理［1］。

采集器程序由一组任务构成，如表1所列。

Task_UartProcess（）是采集器的核心任务。它依次循环地完成：

◆发送写命令帧（如果有控制数据块）。从设备控制数据块队列中取出新的控制数据块，组合到写命令帧中。利用串行发送中断服务发送写命令帧。

◆发送读命令帧。从子站项循环链表中获得访问子站号，生成读命令帧。同样，利用串行发送中断服务发送读命令帧。

◆等待子站应答帧。当收到UartRcvMbox中消息或超时退出时，进入应答帧数据处理程序。数据处理程序完成对设备状态数据块的刷新存储和变化处理。

◆发采集信号量通知发送服务器和发送客户端。

（4）程序设计

LPC2210上电后需运行一段汇编代码，完成中断向量表的定义和重映射，外部存储控制器的初始化，并分配系统堆栈空间，然后进入main（）函数。

在main（）中：

◆调用（）SInit（）函数对内核多任务调度所用系统变量和数据结构完成初始化，并建立空闲任务。

◆调用（）SStart（）函数进入内核。

内核中集成了TCP/IP协议栈，数据报交换通过连接来进行。主要Socket API函数如表2所列。

在ADS开发环境下，函数都是可重入的。

采集器发送客户端或发送服务器均能独立地完成对变化的设备状态数据块的发送，和对控制数据块的接收。采集器发送客户端程序状态如图4左端所示。调用connect（）函数发起与管理机的连接。连接只需与三台管理机之一建立即可。

连接建立后，可用send（）发送设备状态数据块组合帧。采集器在访问每个子站后，都要检查设备状态变化情况，并及时向管理机汇报。

当故障发生时，send（）函数将不能成功返回。若干次发送失败后，客户端程序将调用close（）断开连接，然后重新发起建立连接。

实际上，close（）并不一定能正常断开连接，这将影响连接的重新建立。故约定，当设备状态无变化时，采集器也将间隔一定时间发送一个空数据报。进入故障处理后，管理机因收不到定期的空数据报，亦将关闭连接而重新侦听。

采集器发送服务器程序状态如图4右端所示。事先指定侦听的连接数，通过accept（）函数查看管理机与采集器的连接情况。

当有管理机连接后，即可通过send（）发送设备状态数据块帧，所有过程同客户端中一样。不同的只是，当进入故障处理后，将退回到accept（）重新侦听远程连接。

采集器由5个源文件和6个头文件组成，编译后约8 KB代码。包括启动代码、实时内核和TCP/IP协议栈后，总共40 KB，并占用125 KB数据空间。

管理计算机可对采集器的数据结构和工作方式等进行必要的配置。

采集器正常工作时测得的串口通信时序示意图如图5所示。其中，读命令帧历时约3.8 ms，子站应答帧约13.2 ms.子站应答延迟取决于子站的处理时间。

由图5可见，子站的访问时间约35 ms。期间除完成子站访问外，还包括以太网发送等各项任务。如果要求总线访问周期小于1 s，则可连接25个子站。

结 语

本文介绍的现场数据采集器采用32位ARM处理器加实时内核μC/OS-II的嵌入式实现方案。它将现场各类设备与管理计算机连接起来，使智能小区“一线通”监控系统的结构和对网络资源的利用更趋合理。

通常，对电梯运行状态的监控实时性要求较高，延迟一般应小于O.5 s。其他诸如安防报警等，也应小于2 s。现场数据采集器能很好地满足实时性要求。当十台电梯均以4 m/s以上的高速模拟运行时，监控界面上所有的参数都能及时得到反映，并几乎感觉不到延迟。事实上，每个状态的数据都能被传递达2次以上。