引言
基金会现场总线的既定目标永远是设备之间的互用性，它靠使用开放的、非专有的现场总线协议、标准的用户层功能块和设备描述技术。设备描述文件（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)。（如有遗漏，请多见谅）。尽管每个企业的测试程序应用或是原则有所不同，但是最终目的都是相同的，保证可用的设备正确可靠的与控制系统工作。
系统供应商的测试之所以意义重大，具有以下几点原因：
● 如报警和时间报告等行为可以更好的被主系统观察到
● 一个设备的功能涉及系统的不同功能
● 新的功能总是在规则中详细说明
● 规则的新变形被试验（如规则没有排除但是以前没有人试验过的）
● 一些可能使用的特性没有被支持，但是也没有明确反对

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

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