嵌入式通信网关中的 Linux
1996 年，太平洋瓦电公司 (PG&E) 启动了一个项目，旨在开发一种商业级高级传感器，用于监测电力线路。该系统的概念很简单：使用大量悬挂在电力线路上的小型廉价单元，每个单元由几个传感器元件、一个嵌入式 CPU、一个扩频无线电和一个电池组成。传感器单元将监测特定的线路状况；如果这些状况发生，传感器将进行测量，然后将信息无线电传输到“主”无线电单元。该主单元将反过来通过网关将信息转发到公司广域网 (WAN) 上的服务器。
服务器软件将分析到达的数据，如果存在警告条件，将向电力系统运营商发出警报。广域网上的其他软件将能够监控和执行无线传感器网络的远程配置。该软件将使用专有的无线网络协议来完成控制和监控——实际上，是将该协议通过网关系统隧道传输到 TCP/IP 中并返回。
该项目的时间表非常紧迫：在 1996 年秋季冬季风暴开始之前，将一个可工作的演示系统投入现场。幸运的是，底层传感器技术已经由 PG&E 研发实验室开发出来。PG&E 与一家外部供应商合作，基于这项传感器技术开发、测试并将无线传感器网络推向市场。整个系统将由三个主要部分组成：传感器网络、使用传感器收集的数据的客户端软件以及提供可靠链接的网关。Linux 被选为网关的操作系统。
该项目的目标是开发和测试传感器技术及其相关的无线网络。研发部门率先进行了实际的传感器设计，并对原型传感器进行了现场测试。为了将这项技术从原型转化为产品，我们必须进行面向制造的设计——这不是一家公用事业公司所擅长的。此外，开发和测试无线扩频无线电网络超出了我们的能力范围。因此，我们与一家商业供应商合作，以帮助开发和生产该系统。
供应商负责将我们的传感器设计与他们的无线电集成，并实施无线电网络。我们将提供全面的技术协助，并处理初始试验的所有数据收集和分析。还需要进行相当大的软件开发工作。客户端显示软件基于其他相关的软件开发工作，因此项目的这一部分有一个良好的开端。我是研发部门项目开发团队的成员，负责网关软件的实际开发。
无线传感器网络使用扩频无线电。这些免许可无线电相对不受干扰，但发射器和接收器之间需要清晰的视线。传感器设计为悬挂在电力线上。为了为这些传感器提供视线，并从单个主无线电提供良好的地理覆盖，无线电站点必须高于电力线的高度。因此，主无线电必须位于山顶或安装在塔架上才能有效。这两种解决方案都给主无线电的供电和广域网连接带来了问题。更具挑战性的是，根据地理位置，给定的站点可能需要多个主无线电。为了“越过”小山或绕过建筑物“看”，我们可能不得不添加第二个主无线电。即使在这些情况下，我们也只想使用一个网关系统；因此，每个网关必须能够服务于多个主无线电。
图 2. 作者（前景）和 Julian Riccomini 正在安装网关系统。
该项目的现场试验地点之所以被选中，是因为它具有有趣的配电线路、我们电力服务区域的典型地形以及相对容易到达的主无线电站点。该站点位于我们办公室所在地几个小时车程之外，在一个又大又陡峭的山顶上。即使在干燥的条件下，上山的路也很危险；在潮湿的冬季，到达山顶的设备所在地将非常困难。考虑到物理上到达网关系统的困难，系统必须可靠且容错。该站点已经有一个备用发电机，用于保护位于山顶的其他无线电设备，这大大简化了我们对网关系统和主无线电的电力需求。一个小型 UPS 增加了直通能力，以保护系统在电压骤降期间以及等待备用发电机在断电时启动期间。
主无线电是由无线供应商定制开发的，但其到网关的链路仅限于单个串行通信端口。无线电中不包含嵌入式以太网或其他网络接口。网关系统承担了所有的网络责任。更复杂的是，无线电天线要求迫使主无线电位于室外，高高的桅杆上。计算机系统将位于附近建筑物内。主无线电和计算机系统之间的串行通信电缆必须延伸约 50 英尺。这排除了标准的 RS-232 通信，因为在这样的电缆长度下，我们永远无法达到 56 波特的设计目标。此外，如果没有添加更多的串行端口，正常的 RS-232 通信将不允许我们每个网关拥有多个主无线电。为了解决这个问题，我们选择使用 RS-485 双线差分通信，这为我们提供了距离、高波特率、出色的抗噪能力以及在需要时将链路扩展到多个分支（支持多个无线电）的能力。
网关将需要额外的功能才能进行现场试验。为了正确评估从传感器收集的数据，数据必须记录在某个地方。系统规范要求数据实时传输到中央服务器，该服务器将记录数据、执行数据分析，并在必要时向电力系统运营商发送警报。从网关到广域网的任何链路故障或广域网中断都将中断整个过程并导致数据丢失的风险。事实上，收集到最有趣数据的时间——暴风雨期间——恰恰是链路最容易发生故障的时间。显然，网关必须具有冗余链路和本地记录传感器数据的能力，以防所有链路都发生故障。山顶可以直接看到当地的 PG&E 办公室和一些备用的电话线对。对于主链路，我们使用了商用扩频点对点无线电桥。（类似的无线电已经在公司中广泛用作广域网链路。）
我们的备用链路是 ISDN。我们选择使用商用网桥来提供无线电链路和 ISDN 链路之间的自动切换。虽然我们可以在软件中添加该功能，但我们选择购买“现成的”，相信额外的成本是值得的，可以减少开发时间。为了提供额外的冗余，我们添加了一条标准拨号线路。如果发生广域网中断，切断网络侧的链路，这将为检索数据提供备用路径。作为完整的备份，网关还将记录来自主无线电的所有网络流量。这些日志将保存在系统的硬盘驱动器上，因为我们预计在记录大量兆字节数据之前修复任何链路故障。当然，我们可能仍然需要亲自前往网关并执行手动下载，但我们不会丢失数据。
如上所述，主无线电通过 RS-485 链路与网关通信。该链路使用一种简单的协议（类似于 HDLC，高级数据链路控制）来打包专有无线电网络协议，并在需要时允许多个主无线电。网关将从 RS-485 链路获取数据流，将其封装到 TCP/IP 套接字连接中，并将其流到广域网上。在另一个方向流动的数据将返回到 RS-485 链路到主无线电。在广域网上，一个简单的数据库服务器将位于协议隧道的另一个端点。电力系统运营商使用的软件将仅与服务器交互。这种模块化是划分参与开发过程的不同团队工作量的关键。
在设计系统时，我们始终关注可扩展性。每个基于广域网的服务器都需要能够支持多个无线网络网关。项目的成功完成将意味着推出数百个无线网络，从而导致庞大的数据库需求。此外，服务器软件需要在并非专门为该项目购买的硬件上运行。所有 PG&E 部门都部署了大型 Sun 服务器，以支持其他工程功能。从财务和空间的角度来看，仅仅为了无线传感器网络而购买和安装新服务器的想法被否决了。我们的新服务器软件必须能够跨主要的 UNIX 平台移植——至少是 SunOS 和 Solaris。回想一下，服务器是承载专有无线电网络数据的协议隧道的端点。我们为服务器编写的代码也必须可以移植到网关；编写两个版本不仅愚蠢，而且在我们短暂的开发时间内也是不可能的。
总而言之，桥接系统及其相关组件有很多要求，包括以下内容
一侧使用 RS-485，另一侧使用以太网。
支持通过串行通信通道和 TCP/IP 隧道传输无线电网络协议。
支持主链路、备用链路和拨号链路。
如果这些链路发生故障，支持本地自动数据记录。
支持在链路恢复且不中断正常操作的情况下，在不中断网关操作的情况下通过网络提取日志的功能。
尽可能可靠地在偏远、偶尔难以到达的位置运行。
服务器软件必须可以在各种 UNIX 版本之间移植，并尽可能重用网关代码。更令人兴奋的是，整个系统必须在大约六个月内构建、测试和安装到现场。
对于系统的大部分，我们选择使用现成的技术，以最大限度地缩短开发时间并最大限度地提高可靠性。然而，据我们所知，这种类型的项目以前从未做过，并且大部分特殊功能都必须由我们编写。如果没有一个具有合理功能集和工具的稳定操作系统，我们将永远无法按时完成任务。
由于之前在使用 Linux 的项目中获得了积极的经验，Linux 立即被认为是该项目的一个选项。然而，之前的项目仅在正常的办公室环境中以批处理环境进行数据转换。虽然之前的软件是一个主要项目，但它与关键任务“嵌入式”系统截然不同。网关将是远程和无人值守的，如果出现问题，无法进行人工干预。我们确信 Linux 可以处理负载，但谨慎起见，需要评估替代方案。网关对于整个项目至关重要：没有它，我们将无法获得关于传感器无线网络性能的性能指标。我们需要充分的理由来证明我们为该项目选择 Linux 是合理的。
与往常一样，有人强烈主张使用 Microsoft 操作系统。我们立即拒绝了这种方法。我们使用 Windows NT 的经验表明，它仍然存在一些稳定性问题（尽管比其他 Windows 平台稳定得多）。虽然它可能是一个有用的桌面和/或服务器操作系统，但我们认为 NT 不适合远程系统，特别是那些没有显示器或键盘的系统。我们也不满意 NT 的远程管理功能。然而，也许最重要的是，系统必须在一种环境中运行，在这种环境中，如果看门狗定时器重置系统，它必须自动启动并运行其软件。我们对 NT 在这种情况下启动、纠正磁盘问题然后正常运行的能力几乎没有信心。由于这些原因，NT（和所有其他 Microsoft Windows 操作系统）被拒绝。
还考虑了各种基于 DOS 的解决方案。我们有用于 DOS 的串行端口处理库，我们过去曾成功地使用这些库来解决串行通信问题。微控制器操作系统 ( muC/OS )，一种可用于许多不同微处理器的免费实时操作系统，也经过了评估。muC/OS 同样具有良好的串行端口处理功能。两者都被认为对于嵌入式应用来说是稳定可靠的。然而，核心系统要求之一是允许在不干扰网关操作的情况下提取日志和数据文件。由于某些系统调用的不确定性，DOS 需要一些棘手的编程才能实现该选项，并且我们认为 muC/OS 在高流量负载下会遇到问题。可移植性是另一个问题——协议隧道代码必须易于移植到 UNIX。即使我们能够为 DOS 或 muC/OS 找到经济实惠、可靠的 TCP/IP 堆栈，我们对保持源代码可移植性的能力也深感怀疑。我们从列表中删除了这两个操作系统选项。
我们在类 UNIX 操作系统中有很多选择：QNX、Linux、FreeBSD、Solaris x86 或 SCO。我们对后两者的接触使我们对其性能产生了严重的担忧。我们看到的运行这些操作系统的系统都不是特别快速或响应迅速，即使在相当轻的负载下也是如此。我们还期望将网关计算机硬件平台移植到单板计算机 (SBC)，并且我们想知道这些操作系统是否可以在这种硬件上成功运行。我们当然怀疑这些系统是否可以使用 RS-485 和看门狗定时器驱动程序。我们认为选择 FreeBSD 而不是 Linux 没有什么价值，因为我们所有的经验都在 Linux 方面。
因此，我们的选择减少到 QNX 和 Linux。QNX 是一种稳定、多任务、可扩展、可靠的实时操作系统，可以轻松地在 SBC 上运行。它具有串行端口/RS-485 和看门狗定时器支持以及完整的网络支持，包括 TCP/IP。QNX 还享有良好的技术支持声誉。简而言之，QNX 和项目的需求之间找到了良好的初始契合点。然而，也存在一些陷阱。QNX 不支持 gcc（我们听说正在进行移植）。唯一可用的编译器是 QNX 提供的编译器，它基于 Watcom C 集成开发环境。虽然它可能是一个不错的编译器，但这意味着学习一种新工具，这转化为在已经很短的开发周期中浪费的时间。我们已经在使用并熟悉 gcc 和其他优秀的 GNU 工具。考虑到项目“上市时间”很短，从学习新环境浪费的任何时间都被认为是有害的。
同样的理念也扩展到了 QNX 的整体。作为一种复杂的实时、微内核操作系统，需要一定的学习曲线才能很好地使用它。我们问自己，我们是否真的需要一个实时操作系统以及随之而来的额外复杂性。我们还想知道可移植性问题。由于没有 QNX 的经验，我们非常担心最终不得不编写两次代码：一次用于 QNX，一次用于我们的服务器平台。至少，我们担心我们必须花费额外的时间添加条件编译器指令，以使代码在两种环境中都能工作。相比之下，使用 Linux 几乎可以保证相同的代码。QNX 的许可成本也很高，特别是当在每个网络节点上添加完整的 TCP/IP 功能时。相比之下，单张 50 美元的 Red Hat Linux CD-ROM 代表了显着的成本节省。
最终，低成本、熟悉度和 GNU 工具的可用性使天平倾向于 Linux。它以有形的成本效益满足了项目的所有关键要求，这很难忽视。总而言之，Linux 提供了
一个稳定、健壮、多用户的操作系统
对 TCP/IP 网络和串行通信的可靠支持
能够在各种单板计算机和主机上运行
熟悉的、常用的开发工具和熟悉的系统库——不会浪费时间学习其他工具和系统
代码可以完全重用于其他 UNIX 平台，以实现系统的服务器
作为一个额外的优势，如果我们将来投入生产并开始构建数百或数千个网关，Linux 将为我们节省大量资金，因为使用它是没有许可费的。
网关系统已经运行了一年多，没有明显的停机时间，也没有传感器数据丢失。在某个时候，该系统有 179 天的正常运行时间——唯一需要重启的原因是由于网络桥接设备的问题进行故障排除。Linux 已被证明非常稳定和有效，并且不需要人工干预。
我们现场安装的系统与我们最初设想的略有不同。我们选择的单板计算机遇到了一些问题，但这些问题与板载 RS-485 硬件有关，而不是 Linux。当我们与通信问题作斗争并仔细研究串行驱动程序源代码以试图找到修复程序时，情况看起来不妙。Linux 比其他操作系统选择的另一个主要优点是源代码的完全可用性。我们没有想到需要它，但它确实被证明很有价值。Linux 串行驱动程序代码的大部分开发人员 Theodore Ts'o 亲自通过电子邮件回答了问题——在一种情况下是在几个小时内。虽然我们当然不期望每次都能得到这种回应，但我们从未从任何商业供应商那里获得过这种水平的支持。
图 4. Mary Ilyin 和 Julian Riccomini 正在研究主无线电。
在解决单板计算机上的硬件问题的同时，我们将开发工作转移到我们闲置的一块旧的 386-40MHz 主板上。我们换入了硬盘驱动器，添加了网卡、看门狗定时器卡和 RS-485 端口卡，并立即获得了一台可工作的网关计算机。单板计算机是 486-100，但我们发现 Linux 在最少的硬件上也非常高效，因此不需要更快的 CPU。我们从未解决单板计算机上的奇怪硬件问题。386 系统运行良好，以至于我们一直使用它，并实际将其用于现场试验。它工作完美。Linux 支持的令人难以置信的硬件范围成为另一个坚实的优势，帮助我们实现了可工作的系统。
服务器代码也运行可靠。我们测试并演示了在运行 SunOS 和 Solaris 的 Sun 服务器上的软件；然而，现场系统的主力是运行 Linux 的 Pentium PC。两个系统的代码库是相同的——唯一的区别是项目 Makefile 中的几行代码。Linux 坚持开放标准使我们的可移植性目标变得微不足道。
无线传感器网络取得了一定的成功，尽管确实出现了一些技术问题。然而，在项目进行到一半时，加州法律的变化为该州的电力公用事业行业引入了更多的竞争力。传感器项目是由 PG&E 的研发部门启动的。州法律的一项直接变化是研发资金的管理方式将有所不同。结果，公司废除了其研发部门，并将该项目转移到另一个部门完成。该项目的初始阶段即将结束，但下一步将采取什么措施仍然未知。
自从该项目开始以来，Linux 已经成熟，值得花时间研究一下最近 Linux 的发展如何使下一阶段的网关设计受益。我想强调的是，以下评论是假设性的——如果我要尝试升级和现代化网关系统，这就是我将采取的方法。
下一阶段将需要部署多个无线电网络和网关来服务大型地理区域，并且可以进行更改以简化和改进操作。非测试情况下的网关不需要记录大量的无线电网络流量，因此硬盘驱动器（系统中唯一的移动部件）可以移除。
Paul Moody 撰写了一篇关于嵌入式 Linux 的优秀新 Mini-HOWTO (http://users.bigpond.com/paulmoody/)。他的文档使添加闪存盘就像遵循食谱一样简单。
对于我们的现场试验，我们专门选择使用外部、分立的网络桥接设备来连接到公司广域网。我们认为它实现起来会很快，并且比我们自己编写的东西更可靠。它并非完全即插即用（配置网桥被证明很麻烦），但设置起来相对较快。然而，桥接设备是网关在近十八个月的服务中遇到的唯一问题来源，因此我不再确信专有网络设备的优越性。相比之下，定制的网关软件运行完美无瑕。
1998 年 6 月的《Linux Journal》杂志上有一篇关于 Sangoma WANPIPE S508 路由器卡 (http://www.sangoma.com/) 的优秀文章。此外，Usenet 用户的报告包括对 Spellcaster ISDN 卡 (http://www.spellcast.com/) 的高度评价。在未来的系统中使用这些卡将把所有网关功能集成到一个盒子中（除了点对点链路的无线电，如果需要这样的链路）。由此产生的系统尺寸将约为现在系统的一半，价格约为现在系统的三分之二，功耗为现在系统的一半，而且很可能比现在的系统更可靠。
这个项目是 Linux 在商业市场和关键任务商业通信应用中成功应用的众多例子之一。事实上，Linux 可能在其他操作系统无法竞争的应用领域占有一席之地。
Linux 非常适合通信功能。它快速、稳定、可靠，具有内置的 TCP/IP 网络，并且使用常用的、知名的开发工具。这些工具的商业版本现在可以从 Cygnus Solutions (http://www.cygnus.com/) 获得。使用可加载模块可以很容易地将系统精简到最小内核，并且整个操作系统都是开源的，因此可以进行无限的定制。
Linux 可以在许多不同的处理器上运行，从而打开了广泛的目标平台——但为其开发的应用可以很容易地移植到其他 UNIX 平台，根据需要。Linux 移植到小型廉价处理器的数量正在增长——Linux 甚至可以在 Palm 掌上电脑上运行。多家公司提供 Linux 的商业技术支持。随着操作系统的普及，以及越来越多的大学在其计算机科学实验室中使用 Linux，Linux 开发人员越来越容易找到。此外，对于商业企业来说，也许最重要的是，使用 Linux 没有许可费。这为商业产品节省了大量成本。凭借其技术和财务优势，Linux 可能是许多嵌入式通信系统的最佳选择。
未来几年将出现大量新的商业通信服务。PCS 系统、无线网络的新应用、近地轨道卫星网络、新的公用事业 SCADA 系统、家庭和小型办公室网络——所有这些系统都需要以各种方式互连，并且将构建嵌入式通信系统来服务这些功能。这些系统的范围将从安装在电线杆上的电缆调制解调器/视频点播控制器到锁定在电话公司中心局的小型黑盒子，再到坐在您的 PC 后面的小型黑盒子。如果许多下一代系统运行 Linux，我不会感到惊讶。
