本文介绍了使用 Linux 和实时 Linux 应用程序接口 (RTAI) 设计和开发用于集中操作建筑物中不同空调设备的控制系统。分布在建筑物各处的每个空调都配有自己的红外 (IR) 遥控器。目标是用基于计算机的中央控制系统取代它们，以操作空调，包括打开或关闭空调以及设置所需的温度和风扇速度。

该项目的想法源于当地一所大学需要一种集中且灵活的方式来操作其空调，且成本在其预算范围内。市场上存在用于相同用途的商业软件和硬件，但通常价格过于昂贵且依赖于制造商。

该项目的硬件解决方案包括一台中央控制计算机（运行 Linux），连接到 RS-485 微控制器网络。微控制器能够使用红外信号向相关空调发送命令，以操作附近的设备。

系统的软件设计包括两个实时任务（主控制任务和 RS-485 网络控制任务）以及两个非实时任务（Web 服务器和数据库）。Web 服务器负责用户界面，使其可以从大学计算机网络中的任何浏览器访问。PostgreSQL 数据库用作主要数据存储库。

该实现方案是一种低成本解决方案，并具有根据需要进行扩展的灵活性。此外，它不依赖于制造商，并且可以与任何支持红外遥控器的空调配合使用。每个空调都使用自己的温度控制系统独立工作。为了监督设备的运行，网络中的每个微控制器都配备了一个温度传感器，以监控实际教室温度并将其报告给中央计算机。

整个用户界面都基于 Web 页面。第一个页面显示每个空调的实际状态摘要。此信息包括标识字符串、空调在建筑物中的房间位置、实际室温以及设备是否具有预编程的操作序列，并根据该序列实际运行。对于每个空调，此页面都有一个指向特定设备操作界面的链接。在转到此页面之前，系统会要求输入用户名和密码。在此级别，可以与系统交互，直接控制空调，或者创建或更改自动运行的实际程序（图 1）。

图 1. 从操作界面，授权用户可以打开空调、设置新温度或关闭空调。

系统最有趣的部分是程序化操作。例如，每天系统可以在课程开始前自动打开空调，并为每个房间预定义温度设置。然后，系统可以在晚上建筑物或特定教室的活动结束时关闭空调。

硬件架构由中央控制计算机和控制空调设备的微控制器组成。所有微控制器都连接到 RS-485 双线网络。此应用中使用的微控制器是 ATMEL 公司的 AT89C2051，它是 Intel 8051 的衍生产品。它封装在 20 引脚 DIP 封装中，配备 128 字节的数据 RAM、2KB 的 ROM 代码、一个异步串行端口和 14 个独立的数字 I/O 端口。图 2 显示了微控制器板及其部件。

图 2. 微控制器板，移除了微控制器。

微控制器中的软件使用一个数字输出端口生成红外信号。串行端口将微控制器连接到 RS-485 网络。每个微控制器板都配备了一个温度传感器，即 Dallas Semiconductor 公司的 DS1620。微控制器使用数字三线同步串行接口与温度传感器通信。微控制器没有对同步串行端口的硬件支持；因此，它是在软件中使用普通 I/O 端口实现的。

RS-485 网络在此应用中被使用，因为它易于部署、实施成本低廉，并且可以轻松连接大量节点。仅一对 3 类电话级电缆连接节点。由于硬件驱动程序的限制，允许的最大节点数为 32，但可以使用网络中继器轻松扩展此数量。控制计算机与第一个中继器之间或中继器之间的最大电缆长度为 1200 米。

主从协议控制对物理电缆的访问。运行 Linux 的计算机是主设备，它以预定义的速率轮询每个节点。在每次轮询时，主设备可以向节点发送命令；被轮询的节点通过向主设备发送数据或发送一个空数据包来回答，以表明节点处于活动状态。如果主设备发生故障，则使用此访问控制协议的一个缺点是整个网络也会瘫痪。

考虑到微控制器的有限资源，使用第 9 位协议来确定通过网络发送的数据包是否用于此控制器。通过网络传输的每个字节都有一个附加位。数据包目标地址是唯一一个将其附加位设置为高的地址。默认情况下，微控制器的 UART（通用异步接收器和发送器）被编程为仅当接收字节的第 9 位为高时才生成中断。然后，中断服务例程将接收到的字节与节点地址进行比较。如果匹配，则例程将 UART 编程为接收所有字节，而不管第 9 位状态如何，直到数据包结束。如果目标地址与此节点地址不匹配，则中断服务例程返回。

中央控制计算机 UART（即 PC 硬件）不直接支持第 9 位协议。为了克服此限制，驱动程序通过使用奇偶校验位来模拟它。在传输字节之前，驱动程序配置奇偶校验以在地址字节的第 9 位中生成 1，并在其他字节的第 9 位中生成 0。

图 3 显示了系统中任务的图表以及它们之间的通信链接。

图 3. 系统中任务之间的通信

主控制任务、网络访问控制任务和 RS-485 网络物理层软件驱动程序是在实时执行程序中运行的任务。为 RTAI 开发了 RS-485 驱动程序。此驱动程序类似于任何其他串行驱动程序，只是在此应用程序中使用了第 9 位协议，如上所述。

另一个实时任务是网络访问控制任务，它负责定期向每个网络节点发送数据包。此数据包可以是生成红外信号的命令、查看节点是否处于活动状态的轮询，或命令微控制器传输实际室温的命令。节点用对前两种类型数据包的确认以及对最后一种数据包的实际室温进行响应。关于每个节点实际状态的信息可供主控制任务使用，如果节点发生故障，主控制任务会通知用户界面。

主控制任务使用从数据库检索到的信息，按照编程操作建筑物中的空调设备。此任务还可以接收来自用户界面的指令，这些指令使用两个 RT-FIFO 覆盖编程配置。RT-FIFO 是一种用于实时任务和普通 Linux 任务之间通信的进程间通信例程。为了与 PostgreSQL 数据库通信，开发了一个 Linux 守护程序。此守护程序使用另外两个 RT-FIFO 与主控制任务通信。此守护程序的另一个重要功能是将系统日期和时间发送到主控制任务；RTAI 中不存在读取系统日期和时间的支持。

开发的系统向空调发送命令，无需本地遥控器。我们不干扰空调温度控制系统，也不接触任何内部电路。每个空调都有其内置的温度控制系统，每个微控制器中的温度传感器都监控设备是否正常工作。图 4 显示了已安装的微控制器板。

图 4. 已安装的完整微控制器板。

Linux 任务负责通过 Web 服务器呈现用户界面，并运行 PostgreSQL 数据库引擎，这是主要数据存储库。如上所述，另一个 Linux 端任务是一个守护程序，供 RTAI 主控制任务访问系统日期/时间和数据库。

用户界面很简单。第一个页面显示有关每个空调实际状态的信息。每种类型的用户都可以访问此页面。为了更改程序或向特定空调发送命令，系统会要求输入用户名和密码。PHP 用于动态生成 Web 页面，以呈现从数据库检索的信息。

在 PostgreSQL 数据库中，系统存储有关空调的一般信息，例如 BTU、位置、品牌和微控制器网络节点地址；程序化操作；以及操作每个空调所需的红外命令。

系统的一个重要部分是读取空调遥控器信号的模块，并将与相应设备关联的信息存储在数据库中，以便使用联网的微控制器重现它。此模块仅在添加具有不同品牌和/或不同遥控器命令的空调类型时使用。

此模块包含两个任务：第一个是读取红外信号的实时任务。“在线资源”中的 LIRC 项目以及 Ripoll 和 Acosta 论文提供了有关红外遥控器的详细信息以及使用普通 Linux 和 RTLinux（Linux 的另一个实时执行程序）的示例实现。此模块的另一个任务是在 Linux 上运行的用户界面。这两个任务使用 RT-FIFO 进行通信。

由于微控制器中可用的 RAM 容量很小以及红外信号持续时间长，因此该软件的一个重要功能是帮助用户获取与每个按钮或按钮组合关联的不同红外遥控器信号中的重复模式。这些模式被编码在微控制器的固件中，并用于重建控制设备的命令。例如，如果有十个不同的模式，则发送到网络中适当微控制器的信息类似于：重复模式一十次，然后重复模式二三次，依此类推，直到重建完整的命令。这种技术的优点是使用较少的资源进行信号重建。缺点是每当引入新的空调时，都需要更改微控制器的软件以引入新添加设备的模式。

目前，使用此处描述的系统控制着九台空调；所有空调都位于同一栋建筑物中。另外 15 台空调即将添加。每个微控制器节点的硬件成本为 60 美元，中央控制计算机的成本约为 500 美元。其他成本是 RS-485 网络的部署，当然还有系统的开发和实施。

实施的系统满足了实际用户的规范。由于该项目的成功，大学采购的每台新空调都必须与该系统兼容。要符合系统要求的唯一条件是每台新空调都必须配备红外遥控器。

感谢 RTAI，系统主控制任务独立于在 Linux 中运行的用户界面任务。即使在 Linux 出现故障的不太可能发生的情况下，系统也将继续按程序化操作运行。

将来，该系统可以轻松扩展以控制建筑物照明、警报、限制区域的访问控制和其他系统等。

本文资源： /article/7742。