石油开采厂中的一台大型涡轮压缩机由一套 15 年前的数字控制系统 (DCS) 控制，该系统提供所有监控功能，以及重要事件和数据到打印机的日志记录。该系统多年来一直运行良好，但现在管理层希望将该机器集成到全球工厂 SCADA 系统中，以便收集和处理来自各种机器的数据，从而为整个工厂提供集成管理。

现有 DCS 的基于 PLC 的架构几乎无法扩展，并且从硬件或软件的角度来看，都不允许添加项目所需的必要数据传输功能。为了实现此目的，对 DCS 系统进行重新设计以增加所需功能被认为是一种影响过大的解决方案。

因此提出的解决方案是在现有 DCS 上添加一种“协议转换器网关”，即一个盒子，它可以捕获打印机数据流，分析文本行以提取数据值，并使它们可用于 SCADA（见侧边栏）系统。后者将定期发出数据查询，以从网关接收数据值。对于连接的这一部分，选择了标准协议 Modbus RTU，因为它简单且已在整个工厂中广泛使用。

术语定义

从硬件的角度来看，需要的是一个带有两个串行端口的盒子：一个用于从 DCS 接收打印机数据流，另一个用于从 SCADA 系统接收数据查询。该盒子必须运行一些程序，该程序可以解码打印机数据流并响应 SCADA 查询。

这种应用的主要挑战在于特定的环境：工厂位于地理位置偏远的地区，并且该站点具有工业环境中通常存在的所有问题——灰尘、电气噪声、宽环境温度范围等等。工业 PC 在市场上很容易买到，但必须考虑到一些通常在其他 PC 中找不到的特性

由于上述某些限制以及嵌入式应用的典型工作条件，该软件还必须满足许多要求

为什么不是实时操作系统？ 正如对所提出问题的描述应该清楚表明的那样，我们没有受到严格的实时要求的挑战。两个 I/O 通道的有限速度限制了数据吞吐量，并且服务于两条串行线路时的不可预测延迟不应引起任何问题。这使得可以使用舒适的标准操作系统，并排除了任何特殊用途的实时操作系统作为具有成本效益的解决方案。

为什么不是 DOS？ 手头的问题本质上是异步的。系统必须能够同时吞下 DCS 打印机输出产生的数据流，并响应来自 SCADA 系统的查询，这两个过程在任何方面都不是同步的。因此，DOS 显然不是一个可行的解决方案。尽管它具有非常轻巧且占用空间小的优点，但它需要相当多的底层编程才能解决这个问题。

为什么不是 Windows 95/98/NT？ 由于有大量适用于任何需求的第三方软件包和工具，并且背后有主要供应商的支持，Microsoft Windows（尤其是 Windows NT）在工业应用中越来越受到重视。但是，目标计算机的硬件特性使得为有限的文件空间和可用的 CPU 功率量身定制任何 Windows 品牌版本变得具有挑战性，甚至是不可能的。Windows CE 不够稳定或可靠，不值得考虑。此外，Windows 特有的（弱）多任务处理能力可能会使并发应用程序的编程变得稍微困难一些。

为什么选择 Linux？ 管理者在不得不做出并非“工业上合理”的选择时通常会感到担忧。只要有主要供应商的支持并且拥有庞大的安装基础，他们就能毫无问题地证明选择昂贵产品的合理性。Linux（还）不是这种情况，因此为了促进这种选择，技术论据必须特别有力。在这种情况下，我相信 Linux 提供的优势优于许多反对意见。

选择 Linux 有许多优点

它显然也有一些缺点

在这个项目中，我们需要两个非标准设备，即闪存 EPROM 磁盘和 RS-485 串行接口。这没有造成任何问题：闪存 EPROM 磁盘被用作标准的 DOS 格式化设备，串行接口取代了 COM 端口，并由标准串行驱动程序管理。

协议转换器网关软件的结构非常简单。它由两个独立的进程组成：数据吞噬器和 Modbus 服务器。数据吞噬器从串行端口接收打印行，分析字符串，提取相关数据，并将值写入共享内存缓冲区。Modbus 服务器根据 Modbus 协议规范接收来自 SCADA 系统的查询，并将请求的值发送回，从共享内存缓冲区读取它们。

为了调试目的，添加了两个交互式程序：一个内存转储程序，用于打印从共享内存缓冲区读取的值，以及一个将值写入共享内存的程序。显然，这两个程序都可以与网关进程并发运行。

所有代码均以 C 语言编写，共享内存管理是通过使用标准 System V 进程间通信 API 实现的，该 API 允许创建和管理共享内存段，并提供信号量以同步对它们的访问。

由于问题的结构非常简单，因此通过在进行内存访问时锁定对整个共享缓冲区的访问，可以轻松实现同步。这种简单化的方法在这种情况下非常适用，因为所有对内存的访问都是分块执行的，并且相对于内存访问而言，I/O 操作的速度较低，确保任何进程等待内存锁释放的时间都相对较短。

作为持续验证网关正常运行的工具，共享内存缓冲区的一个位置已预留给计数器，该计数器在数据吞噬器进程完成读取周期时递增。SCADA 系统定期读取该变量，因此如果该变量在给定时间段后未递增，则可能会发出警报。

按照 Linux BootDisk-HOWTO 中找到的说明，从标准的 Red Hat 6.1 安装开始构建了一个小型 Linux 系统。这实际上是一个反复试验的过程，因为必须准确找出目的所需的文件。

即使我们的闪存 EPROM 磁盘提供了舒适的 8MB 磁盘空间，所有软件都必须通过软盘传输到目标计算机，因此希望生成的系统尽可能小。

定制系统包括内核、许多标准 Linux 命令（我们在添加命令时相当慷慨：最好在将来进行维护时手头拥有所有必要的工具）以及所有相关的库。它还包括管理 DOS 格式卷所需的加载模块。这可能有助于挂载和访问 DOS 格式的软盘或闪存 EPROM 磁盘。

毋庸置疑，为网关开发的四个程序，以及两个运行进程在启动时使用的一些 ASCII 配置文件，也包含在内。

由于 Linux 引导程序的要求，上述组件存储在两个文件中：压缩的内核映像 (450KB) 和压缩的根映像 (2500KB)。仅仅比两个软盘可以容纳的量多一点：我们实际上需要三个软盘才能完成分发。在 BootDisk-HOWTO 中，可以找到许多与缩小根映像大小相关的提示，但我们对达到的尺寸感到满意，并且不想在这方面做更多工作。

为该项目选择的闪存 EPROM 磁盘 (M-Systems DiskOnChip) 配备了 Linux 驱动程序，可以用作 Linux 引导盘。这可以通过将 DiskOnChip 驱动程序包含到内核中来完成，但也需要对 DiskOnChip 配置实用程序和特殊版本的 LILO 进行一些调整，使其可引导。

经过几次测试，我们更喜欢不同的解决方案：DiskOnChip 配置为普通的 DOS 可引导磁盘。这样做的好处是避免了重建 Linux 内核和重新配置 DiskOnChip（它是设备的出厂配置），而且相对于该设备的未来版本，它被认为是一个更稳定的解决方案。Linux 映像文件存储在 DOS 文件系统上，Linux 通过 LOADLIN 实用程序引导。这为软件增加了大约 160KB 的 DOS 文件。

因此，系统的加电顺序是

协议转换器进程在启动时启动，因为它们被插入到 inittab 表中。这也提供了在两个进程中的任何一个崩溃时自动重启的功能。

引导后，如果键盘和显示器已连接，则会显示通常的 Linux 登录提示，并且可以进行 root 登录。这使我们能够执行维护操作，特别是启动 Linux 命令或使用上述两个交互式监控程序中的任何一个。如果需要（例如，为了在不经过制作新根映像的整个过程的情况下修改配置文件），可以将闪存 EPROM 磁盘挂载为 DOS 卷。

我们已经展示了如何使用 Linux 解决工业环境中典型的数据采集问题。实际上，我们能够构建一个可以使用 32MB RAM 和 8MB 磁盘空间做一些有用的事情的系统，但该系统最值得注意的特性是其稳健性。

磁盘访问在启动时仅限于只读；运行时文件系统由 RAM 磁盘支持。这意味着在断电后重启永远不需要文件系统检查，否则可能会阻止引导过程继续进行。此外，由于所有系统文件都保留在只读设备上，因此它们极不可能被任何人意外篡改。最后，在程序崩溃的情况下，Linux 提供了重启进程的功能。

对压缩内核和根映像的本机支持也非常有价值，因为它使我们能够保持整个系统非常小。