现场总线系统的用户一直被多系统的合作运行问题困扰着。随着设备变得愈加复杂，操作人员、工程人员、技术人员不得不花费很大的精力以获得设备的信息。解决这一窘境的简单方法就是在现场总线系统中引进由设备制造商编写的专业应用程序。
这里所说的专业应用程序是指在控制系统的工程设计和维护环境中使用的用户界面。不再需要从系统的硬件树中查找点击设备，或是查阅设备的参数列表，取而代之的是由最熟悉仪表的制造商设计的、功能强大的应用程序。如果您希望了解某个阀门是否正确的安装，您可以通过图表查阅在过去一个月内这个阀门设定点的变化范围。如果您希望检测一个压力变送器的状态，这个应用程序可以帮助你获取整个流程的数据、进行所有的数据处理、存储需要的数据、显示控制的结果和质量。
将这些应用程序集成在系统之中是非常重要的。这可以使诊断过程在控制室中完成，而不再需要在网络中插入任何手持设备，也不再需要暂停设备或是将设备连接到其它的独立应用程序。
由于到控制系统和组态软件的硬件连接使用了不同的接口卡件，使这些应用程序的集成并不顺利。现场总线领域为了解决这一问题引入了两种全新且互补的技术FDT和eEDDL。
什么是EDDL语言？
电子设备描述语言是现场总线技术诞生之初产生的一项
技术，它的作用如它的名字所示用于描述设备。与现场设备交互的系统需要在通信开始之前预先了解会话的规则。设备中具有哪些功能模块？可以使用哪些参数？这些参数的数据类型是什么？这些参数的默认值和允许变化范围是什么？系统需要利用这些信息在使用这些设备之前了解它们。
什么样的问题困扰着DD?
现场总线技术需要处理来自于各种设备描述语言的通信规范，所以设计的出发点是从设备的角度考虑问题。我们可以设计出具有多参数的设备，但是系统或者说是系统用户无法通过这些参数理解这些设备，无法与之进行交互，无法对这些设备进行合并和分类。使用文件，系统可以提供参数列表。但需要用户自己去理解这些参数的用途。
DD文件无法与设备通信。DD文件与设备的实际通信之间需要多层软件的支持。
DD文件存在很多版本。各种现场总线技术通过不同的方式使用EDDL语言。直至今日，全新的改进版DD依旧延续这样的状况(我们会在后面进行讨论)。DD文件是利用某种语言编写的，但是这些文件之后会被编码为二进制形式。这种编码方法因不同的现场总线技术而异(例如，FF的DD文件不同于HART的DD文件，而且如何解码这些文件的规范是不公开的。系统供应商需要从每个总线组织那里购买相应的软件解码DD文件。这些软件包是彼此独立的，迫使系统供应商开发并维护多个产品以支持多种现场总线文件类型。
DD文件限制了设备的交互范围。例如当使用FF的DD文件时，每次都只能访问一个功能块，即使某一操作涉及多个模块。
什么是eEDDL?
eEDDL是多家现场总线组织为解决上述的第一个问题--简单的参数列表无法与现场总线设备进行足够的交互--所作的初步尝试。尽管这些改进可以融入入到最初的EDDL语言之中，但实际上他们发挥着截然不同的功能，需要单独进行讨论。
eEDDL是一种初级的编程语言，用于支持Windows与设备的交互。除了参数列表，使用eEDDL编写的程序可以生成独立于交互界面的表格、二维图形，并绘制数据图表，进行基本的数据处理，存储文件，显示图片。
eEDDL是一种类的语言，类似于最初的EDDL，它也需要由各个总线组织编写的不同规范进行编码和解码。文件中的编码可以在运行时间内由软件进行解码，这些软件由现场总线组织提供不同的总线使用(不同的软件)。
使用EDDL的系统供应商负责编写相当大量的代码来解码这些文件。例如， eEDDL文件可以告诉系统在屏幕的指定位置生成一个图表。由供应商选择编写系统软件所使用的操作系统和编程语言平台，系统软件必须能够利用相应的编程语言绘制所需的图表。系统软件同时也负责编写与物理网络的接口驱动，并且负责配置和所需软件的运行环境。
改进EDDL语言的工作还在继续，改进不仅针对最初的设备描述特性，同时也针对新增的改进。
eEDDL的不足
如上文所述， eEDDL非常简单。设备供应商所面临的是日趋复杂的设备和相应的软件支持。供应商需要决定使用何种语言编写，这也决定了产品适用于何种系统。因为当今的大多数工程工具都是基于Windows操作系统的，所以可供选择的编程语言非常之多，例如C,C++,C#,Visual Basic,Visio,MatLab,EDDL等等。无论何种工程设计决策，工具箱的选择必须依据产品的需要。如果程序简单而且可以利用完成，那么这将是一个不错的选择，而且有不少的好处，例如具有一定程度的平台独立性。如果需要更多的功能，例如数据库的交互能力、高级或者多维的绘图能力、Excel表格输出功能、高级数学计算功能等等，那么必须选择一种支持这些功能的语言。其他的功能同样会影响最终选择何种编程语言，例如同时与多功能模块和多设备交互的功能，或者提供嵌入式的服务系统。
什么是FDT?
无论选择何种编程语言编写针对现场总线设备的应用软件，所编写的软件必须能够与控制系统和组态工具进行交互。实现这一交互功能的常用方法可以分为两软件组成。第一部分是网络接口的驱动，负责系统与实际现场总线设备之间的物理通信。第二部分是平台接口的驱动，负责组织系统中的设备和获取存储在平台上的数据。
假设每个控制系统供应商都希望支持所有的现场总线设备，那么他们必须为每个系统开发相应的上述两种组件。倘若由系统供应商来设计这个交互接口，必将会产生多种专用的交互接口。这无疑会是多家现场总线组织为解决上述的第一个问题简单的参数列表无法与现场总线设备进行足够的交互所作的初步尝试。尽管这些改进可以融入入到最初的语言之中，但实际上他们发挥着截然不同的功能，需要单独进行讨论。是一种初级的编程语言，用于支持与设备的交互。除了参数列表，使用编写的程序可以生成独立于交互界面的表格、二维图形，并绘制数据图表，进行基本的数据处理，存储文件，显示图片。是一种类的语言，类似于最初的，它也需要由各个总线组织编写的不同规范进行编码和解码。文件中的编码可以在运行时间内由软件进行解码，这些软件由现场总线组织提供不同的总线使用不同的软件。迫使设备供应商为所有不同的系统开发不同的软件。如果某个设备供应商恰好是一个实力雄厚的系统
供应商，那么该供应商很可能不会共享相关的接口描述。最终的结果是设备供应商不愿意开发针对相应控制系统的应用软件或者开发出的软件功能不如独立软件，导致某些系统的用户也无法从应用软件中获益。
FDT技术正是帮助自动化领域的用户避免上述困境。FDT定义设备应用程序、控制系统平台以及现场设备之间的接口。FDT使设备供应商能够为系统开发通用的应用程序。任何支持这个接口的系统均可以集成这个应用程序。因此，这个应用程序在每个系统中都具有相同的操作方式、相同的外观、相同的用户体验。
FDT不影响系统、设备或者DD文件。如上所述，每个系统都必须有FDT接口。以一种开放的标准化的方式定义这些接口。在系统配置的过程中，依旧需要文件对设备进行描述，而在这个过程中设备本身没有变化。
符合FDT规范的设备应用程序(也称为“DTM”)可以用很多种语言编写。通过编写支持的eEDDL的DTM可以实现eEDDL的集成，其工作方式类似于集成其他语言编写的DTM。
FDT的不足
FDT是基于Microsoft Windows的技术。因此，它不可避免的局限于升级和操作系统的变化。由于依赖于操作系统中的软件工具，FDT平台和设备也不可避免的需要进行升级。
FDT仅仅定义了系统组件之间的接口。因此，FDT组件无法取代DD文件，所以现场总线系统依旧不能脱离文件。
讨论
eEDDL是DD技术的延伸，所有的现场总线系统均支持这项技术。作为一种编程语言，在任何支持这项技术的系统中，eEDDL都可以用于开发可移植的应用程序。
FDT是一种接口规范，它允许系统和工程设计工具供应商共享设备接口。具有FDT接口的设备应用程序可以很容易的被集成到任意支持FDT的系统中。这些应用程序可以用多种语言进行编写，包括eEDDL
。市场上也有一些可以解码eEDDL的FDT应用程序，因此eEDDL文件可以随时加入到系统之中。
FDT对于Microsoft Windows操作系统的依赖一直是饱受争议的问题。毫无疑问特有的Windows特有的“moving target ”特性对于客户那些多20年的陈旧设备是一个不小的挑战。然而，工业界会根据自己的利益进行权衡。Windows提供带来的好处似乎超过了他的劣势。当今供应商销售的大约100%的系统工程设计工具是基于Windows的。即使供应商声称对FDT的Windows依赖是非常严重的问题，基于Windows的设备应用软件依旧是他们最热卖的产品。
FDT得到了大多数主要系统和设备供应商，以及一些著名最终用户的支持，他们都已成为FDT组织的成员并参与FDT产品的开发。许多的FDT供应商同样也支持增强的eEDDL。支持两种技术的系统现在已经面世。
的确，现在有很多关于FDT与EDD竞争的讨论。但是，这些讨论已经清楚地说明这两种技术之间不存在任何的重合，基于FDT的系统支持并将继续支持DD文件。设备供应商也不需要舍弃DD，而转投FDT/DTM。支持FDT也不需要对设备作任何的改进。两种技术都将为现场总线系统带来更大的价值。
FDT/DTM FDT
（转载）
