引言
      基金会现场总线的既定目标永远是设备之间的互用性，它靠使用开放的、非专有的现场总线协议、标准的用户层功能块和设备描述技术。设备描述文件（DD）是允许设备在相同的H1现场总线共存和通讯的关键。为了保证互用性，要求设备供应商经过基金会检测和注册设备，使注册文件对用户是可用的。主系统也同样被基金会用主机互用性支持测试（HIST）进行检测，来保证未来的互用性。
      但是，为什么所有的设备供应商都要测试设备呢？今天，几乎所有的DCS供应商都拥有不同功能的现场总线互用性检测实验室，为的是用他们各自的主控制系统来检测基金会现场总线设备。那么，什么是主机供应商可以做，但是基金会和设备供应商不可以做的呢？最后，用户的最终收益将是什么呢？
      这篇文章主要研究了这些问题，并且关注了技术供应商，无论是主系统或是设备的，可以做些什么来使基金会现场总线为每个人工作。

历史回顾
      刚开始基金会现场总线的创始者，详细阐述了他们的意图，就是，为设备——传感器和执行机构等——可以存在于一个强大的总线之中，并且可以与其它设备和主机通讯，不管这些设备是来自于哪个厂家，这一想法通过标准的电气和通讯协议得以实现，基金会指出，设备上出现的参数都是标准的，当然也会存在一些包括制造商特定参数的选择。各个制造商可以通过这些可选参数区分彼此。例如，一个温度传感器，将会在阀门定位器得到不同的参数。
      在更多的案例中，所指定的主系统可能是一个DCS系统，但是它也可以是一个笔记本电脑，抑或是一个手持配置工具，或是一个简单的PC程序。设备描述文件和功能文件使得主系统可以识别设备，并且知道它们的参数和功能。描述设备的这些文件通常被整体指定为设备文件。这些设备文件定义了功能块和设备功能，因此，就使一个主系统可以知道所需的关于FF设备的所有信息，而不需要亲眼看到这些设备。所以，这些设备文件是离线配置的关键。
      测试所需 在一个理想的世界里，如果拥有一个完美详尽的说明还要有对这个说明的充分理解，主机和设备供应商可以各自开发自己的产品，而且这些产品可以互相配合良好。但是在现场总线设备的现实世界中，由于现实人所开发的软件的复杂性，所以大家公认，测试是必须的——而且是大量的测试。所以基金会开始要求设备进行基金会测试和注册（在测试之后），最初并没有对主系统测试做要求。多数设备供应商曾经在提交给FF注册之前进行自己的提前认证（现在仍在进行）。现在，基金会仍然提供一些进行FF通讯协议检测。国家仪器现场总线配置被用来进行设备测试。许多设备供应商把这个软件包作为他们在协议层之外进行测试和解决问题的“黄金定律”。

      同时，DCS领域也遇到了他们自己的问题。已经通过FF测试的设备和设备文件有时可能在一个系统上工作良好，却在另一个系统上出现问题。每个主系统供应商都可以自由使用他们自己的一套现场总线功能和特点，一些不同的堆栈（协议实施）是可用而且已经被用了。另外，不同的供应商（无论是系统或是设备的）可能在现场总线规范的解释上稍有不同。
      所以有两件事就在早期发生了。首先，用户的项目要求不同的DCS系统与他们的各种现存设备配合使用。用户开始要求设备被测试或是“认证”来保证他们的现场总线项目可以顺利工作。第二，当遇到问题时，主系统和设备供应商开始合作（和基金会）来解决这些问题。现在，大多数大型的系统供应商在适当的位置有测试程序。这些测试程序就代表了“幕后之人”，它们在确保现场总线工程顺利实施，问题成功解决方面非常有用。

测试的“三角关系”
      当今，使得基金会现场总线之所以成功的一个关键因素就是测试的三角关系，包括基金会，设备供应商和主系统供应商（见图1）虽然信任用户的测试实验室和试验工厂，或是独立的顾问，学习中心，但是最主要的责任是来自这三个部门。让我们看一下他们各自的职责。
    图1 测试的三角关系
      除了提供技术，现场总线组织，现场总线基金会负责测试设备，使之满足FF标准的要求。FF注册设备是已经通过测试的。这些测试非常重要，但是也有限制。实际上，FF并不“证明”设备，他们并不保证一个设备以特定的方式运行。他们的宗旨是保证协议和标准被执行。FF通过执行非常严格的测试来保证电气设备的协议被执行。FF互用性测试软件包依靠这些标准测试设备。他们测试通讯功能，检验一个设备包含一个通过FF一致性测试的注册堆栈。
      当FF确实运行一个设备互用性测试来检验不同设备功能块之间的通讯时，这并不保证正确的功能块控制行为。FF并不强制测试或是使设备执行相关的测试。FF的DD测试保证语法正确并满足一定的标准。CFF测试保证功能文件定义现有设备的功能。当然，主要的目的还是保证FF协议和说明将被执行。也就是说每台设备都要得到FF检测标志。但是现场总线基金会并不保证设备与系统配合正确。考虑到所有的可能组合，这将会是一个不可能的任务。
      设备供应商最在意他们的设备按照需求工作。他们最关注设备功能（制造商置于传感器模块的特殊部分），也是区分他们产品的地方。大多数设备供应商的堆栈或是外部功能的一些功能块依靠第三方，例如Softing、SMAR或是国家仪器有限公司。设备供应商在基金会处购买工具进行提前测试，以保证通过进一步的FF互用性测试，但是这些工具并不测试类似算法等行为。许多设备供应商只有有限的测试能力，有时只使用NI配置软件作为用户测试工具，他们很少有主系统，例如，NI配置软件对报警行为并不做出反映。幸运的是，供应商已经开始购买主系统，并且在保证设备所有行为表现越来越主动。这是一个学习的过程，但是他们的主要目的仍然是保证他们的设备正常工作并合乎标准。
     系统供应商的职责不仅仅是把各种现场总线设备相互连接和集成在一起，而且要保证整个系统的控制行为，包括设备的功能块。最终，用户期望整个系统工作正确。为此，还有很多其它的事要做。系统供应商在设备测试中扮演重要角色。现在，正式的现场总线互用性程序已经被以下公司开发使用： Honeywell (PlantScape和 Experion PKS), Emerson (DeltaV 和 Ovation), Yokogawa (Centum), ABB (Industrial IT), Rockwell 自动化和 SMAR (System 302)。（如有遗漏，请多见谅）。尽管每个企业的测试程序应用或是原则有所不同，但是最终目的都是相同的，保证可用的设备正确可靠的与控制系统工作。
系统供应商的测试之所以意义重大，具有以下几点原因：
● 如报警和时间报告等行为可以更好的被主系统观察到
● 一个设备的功能涉及系统的不同功能
● 新的功能总是在规则中详细说明
● 规则的新变形被试验（如规则没有排除但是以前没有人试验过的）
● 一些可能使用的特性没有被支持，但是也没有明确反对 [page]

      供应商要进行测试，还因为（a）用户希望系统稳定（b）DD/CFF文件有时也会发现问题（c）设备性能有时也会出现问题（即使通过FF认证）（d）主供应商希望调试或是改进他们的系统。最后一个原因很重要，因为所有的这些测试也是在帮助控制系统更加稳健。除了系统供应商的现场总线互用性测试，其它无法做到。

HIST系统测试的任务
       在把上述观点发展深入之前，讨论Foundation’s Host System Interoperability Test,即HIST，旨在认证FF主机。这个过程的更多解释参见基金会网站，在此不再赘述。概括的讲，HIST是一个用来检测系统可以执行基本的现场总线功能的测试。尽管它作为一种确认哪种功能是主系统已经实施的工具，但是它不保证这些功能对于所有的注册设备或是应用程序可以工作正确。这无需责怪HIST程序，但是却是事实。它并没有要成为一个全面的功能测试程序。虽然HIST是一个很有价值的工具，但是它不能取代供应商提供的主系统互用性测试，而且这种情况在近期也不会改变。但是，也同样指出，HIST已经在很广泛的产品范围内应用，从完全成熟的控制系统到实验室或是工作台控制工具。但是控制系统所要求的功能远比工作台校准工具要多，所以，HIST必须可以在这个领域的两个极端实施。

一般测试原则
      本小节将会阐述Honeywell现行的互用性原则，在很多情况下，这些原则也同样被其它厂商所采用，但是这些规则却在供应商之间促在差异，但是从没有人把他们做对比。
      通常系统供应商会免费为用户或是设备供应商提供他们所采用的原则，作为回报，系统供应商要为他们提供设备来进行测试。至今，这已经成为广泛接收的实践。这里，必须给予FF标准以足够的信任，就像在大多数系统中所实施的一样，把一个新的设备集成到一个系统相对容易。这有助于进行相关的合理测试。
在告知用户和系统供应商那些设备已经被检测等这些测试方面不同的系统供应商之间有所区别。在Honeywell，我们把已经在公共网站上成功检测过的设备文件邮寄出去。http://www.acs.honeywell.com。这是我们的惯例。既然我们的系统可以直接使用设备文件，它也是支持用户工程的重要机制，其它大多数公司好像是利用网络工具达到这个目的。需要指出，我们特别邮寄出的这些与我们系统配合工作的设备文件，可能需要或是不需要被修改或修正，或许有很多版本的可用文件。我们也包括将此设备集成到我们系统的任何信息。后者是系统供应商邮寄设备文件的最主要原因。即使设备文件工作正常，也许会有其它一些系统差别将会被指出。
      当测试揭示了一些问题时，接下来该怎么办呢？一般来讲，供应商力求通力合作，把问题解决，这永远是首先要做的。耐心在这里很重要，因为修理和改变需要时间，而这些过程往往需要再测试，但是有时用户需要规定这个节奏。如果有些问题或是性能没有被解决，尤其是涉及控制，我们经常会通过设备文件为设备供应商提供可以相互接收的信息。注意，我们并没有公布测试报告的细节；我们认为设备文件可以引起足够的注意。
      我们的互用性测试计划和原则并没有公开，但是对于提出要求的用户和设备供应商都有效。

测试步骤
      测试的主要目的是按照用户要求支持所选用的基金会现场总线，是注册的设备与主系统可以相互操作。这个目的在工业得到一致响应，因为其它系统供应商支持他们的用户。文件的互用性和测试过程中发现的功能型问题，与供应商之间合作解决问题也是一些很重要的目的。
以下是测试设备时的一些基本要点，这些已经应用到我们的设备，但是对于其它供应商也非常普遍：
● 从供应商或是用户处得到典型的设备和设备文件。
● 根据设备文件建立一个设备的系统模型（通常叫做实验室模型）这是测试设备文件的第一步（这一步在厂家之间各不相同）。
● 如果遇到问题并且我们可以解决它，我们解决并告知供应商。极少数情况下，我们如果不能解决，我们要与供应商一起解决。这时会发现必须对我们的系统需要做一些改变或是修正。
● 下一步是加载设备，（在我们的系统中）也要加载电源和所有的传感器模块。要保证：（a）应用默认设置协议的设备稳定（b）所有的参数工作正常。当我们寻找任何潜在的互用性问题时，这在一个从现在多个厂家的设备所组成的设备混合体的系统中完成。
● 一旦测试基本的设备操作，在控制策略中的各种可用功能块将会被使用和测试。这一步可以涉及AI或是DI模块到输入输出和功能块的大量组合。（在下一节中将会有详细介绍）。
● 测试功能块要通过“硬件控制”和“软件控制”设置实现。这是两个非常重要的测试环节。另外要使用不同的或是很大的循环周期。
● 其它一些行为和特征的测试包括确认：
○厂家指定的可以读写的读写参数。
○只读参数可以被读取，并且包含厂商规定的期望值。
○设备地址分配和标志名可以被更改。
○可选的，如果文件可用，则可以执行设备校准。
○对于设备，可以执行LAS，连接到主系统LAS失败恢复和正确恢复工作。
○系统行为，例如报警、总线电源恢复失败，与活动的总线连接/断开、设备如期保存或是恢复工作。
○电源模块的所列选项工作正确，尤其是事件报告。
● 注意，有些设备有额外的厂家专有的传感器模块需要测试。例如，大多数Rosemount 传感器拥有TRANSDUCER_LCD模块控制显示行为。

控制行为测试
      使用功能块对于基金会现场总线来说十分特殊，所以要格外注意功能模块控制行为。从某种意义上说，这个测试对于控制系统供应商具有一定的意义。 基金会现场总线设备是控制系统这幅巨图中的一部分。大多数系统供应商以控制的基本原则为基础，很好的理解那些必须正确工作的行为。

      下面是测试现场总线设备功能块行为的一些典型测试案例。图2显示了一个PID互用性控制测试应用的典型案例。记住，输入输出模块连接到传感器模块，所以这些将会一同测试。控制功能块（PID等）没有这样的联系。
● 测试简单的输入设备（AI和DI）连接到主机或是其它设备功能块。验证由报警或是AI和DI模块的状态值所引起的VALUE和STATUS改变。验证报警行为，包括禁止和优先权。确认发布信息每个周期将会更新。确认与传感器模块的正确工作范围。有些情况下，当有很多通道时，要确认所有的通道正确工作。
● 测试PID控制行为，使用IN、CAS_IN、 RCAS_IN、 ROUT_IN、和FF_VAL作为输入，检查各种控制和PV选项工作正常。确认震荡形式的正确性。测试任何读回或是反馈功能工作正常。对于多通道设备（如DO模块），确认通道分配任务正确且不冲突。
● 检测设备上的功能块可用。对于不同的控制有不同的设备特定指令。
● 测试设备功能块——输入、输出和控制——和主功能块。
● 因为有两种不同的功能块连接，发布/订阅和异步连接，两种都应该测试。例如，RCAS_IN或是RCAS_OUT是远程的客户服务连接，为DDC控制而设计，CAS_IN是发布/订阅连接。在应该被应用的地方，初始化应该被确认。这些测试也同样在重载连接时进行。
     图2 典型的现场总线兼容性控制应用程序
● 确认默认的功能块和设备的操作状态。注意，在很多钟情况下许多默认的状态是不可以测试的，因为这会具有破坏性，很难模拟，因为系统供应商并不了解它们。[page]

解决问题
      关于解决问题已经讨论过一些。当测试出现一些问题时，一些技术或是工具可以解决问题，或是提供一些数据细节。包括：
● 使用NI配置或是其它操作台校正工具例如Rosemount375来研究问题是出在设备上还是系统上。例如，NI配置软件可以确认一些即使标出可读/可写，但是其实并不可写的一些参数。
● 使用监视软件来捕获一些总线上的时间用来确认设备的行为是否正确。这需要对基本的FF协议特性有着高度的理解，而不是一般的普通用户所能掌握的。
● 使用DD浏览器来检测所提供的DD文件的细节。例如，我们可以看到关于参数预定性能的一些细节。当然，这也需要对FF规则有着深入的理解。
● 使用其它的设备（已经成功的检测过的），对一些性能进行比较和对比，例如报警和控制功能。
      随之而来的一些问题就是某个问题是来自设备还是系统。有时必须要参照一些FF技术规则，以用来确认是不是在某种程度上有些规则上的违背，但是，经常会遇到一些“灰色区域”，就必须与基金会一起解决。当这些问题出现时，就要就需要一方或是多方可以起草一个AR文件，来取得技术规则上的一致。AR进一步澄清规则的不明确部分，并可以进一步改进FF技术。有一种错误的理解就是，既然一个注册设备已经经过测试了，互用性问题必须是主机所默认的。
      这里必需明确一点，就是设备之间会有区别。当FF设备供应商被要求在他们的设备和功能块上使用特定的标准参数时，他们也被允许添加自己的特殊参数，而且并没有要求标准的模块的内部功能性能完全一致。例如，两个不同厂商的设备上的PID模块可能看上去一样，但是执行起来并不完全一样。他们内部的一些公式等还是属于厂家所有。这是被允许的，也为区别提供了可能。实际上，区别有时看起来并不大，用户当然也在他们的一致性上得到很好的服务。

Honeywell 测试的特点
      Honeywell坚持使用两套独立的系统来进行对现场总线设备的测试，每套系统的侧重点不同。我们主要的设备细节测试工厂是位于印度Bangalore的现场总线互用性测试实验室，实验室隶属HTSL。图3中所示，为我们的主管工程师和系统在实验室。图4、图5也是实验室。以前所讨论的方法都是在这个实验室使用的。一个现场总线设备的平均测试时间大约要花费一周左右，但是这些在设备上根据功能块的数目和设备的复杂性而有所差别。正如所想象的那样，这也和所遇到的问题有关。
图3 在印度Bangalore的Honeywell现场总线测试工程师。
      我们在华盛顿宾夕法尼亚街区还拥有一个Experion PKS测试的大型系统，基于我们的发展工厂。这个大型系统主要关注于拥有H1负载，大量的报警和显示负载的大型系统。图6和图7显示的是大型系统的一部分。我们把从不同厂家的设备集成在一起。
      另外，一些小型的系统也为开发、解决问题和验证目的所保留。包括Honeywell的TAC所运行的一些系统。但是测试的主要责任还是属于Bangalore工厂。
图4 于印度Bangalore的Honeywell现场总线户用性测试实验室 [page]
图5 于印度Bangalore的Honeywell现场总线户用性测试实验室
所有这些意味着什么？
      本文的标题“幕后之人”。这个短语意思是指系统供应商所提供的互用性测试一直是FF可靠性的很重要的因素，而这些，对于终端用户来说，并不是完全可见的。但是，如果没有这些，我们将不会对于技术很重要的系统确认。系统供应商在确保和维持基金会现场总线设备和系统的强健性和可靠性方面起到了很重要的作用。
      在2000年，基金会所颁布的修正的功能性文件将会成为期望安装测试的一线曙光。现在也有一种同样的说法，最近的趋势是支持基金会的全部未修正文件，而将来却可能会有一项很大的改进。CFF1.7是HIST组织的观点所作出的规定的修改的直接结果。但是这种改变很花费时间，而且触及到技术的根本。比较有利的观点是这可能会在将来在我们身边出现。
      意识到测试过程中，三方都很重要，使用复杂的底层技术来完成这个简单的任务。现场总线基金会、设备供应商和主系统供应商的测试都很重要。这种不同测试的组合，再加上成千上万的已经运行中的设备，证实了这项技术的可靠性和生命力。



图6、7在Ft. Washington, PA的大型系统测试实验室

 

结论
如果您要开始一个项目，建议您最好提前和系统供应商联系，以保证您所要使用的设备正在或已经进行综合测试。同样确认使用的哪个修正文件也很重要。测试了错误的修正将不会有任何好处，因为厂家可能或是已经对设备进行了大量的修改，作为修正文件改变的一部分。