如何编写一个HART设备的DD文件

了解您的设备

HART设备描述（DD）基本上是符合HART的现场设备的模型。要开发DD，您必须要做到：

成为编写DD的现场设备的操作、行为和功能方面的专家。

使用DDL对现场设备的所有功能进行建模，包括其支持的命令、包含的数据项以及用于配置和维护现场设备的标准操作程序（SOP）。

描述与现场设备交互的仪器管理系统将使用的用户界面。最终用户将要求您的用户界面提供对现场设备中所有功能的访问。

测试你的DD，以确认它正确地为你的现场设备建模，并且用户界面符合你的期望。

由于DD是现场设备的模型，因此DD与编写它的现场设备一样简单或复杂。如果现场设备简单，开发DD将简单、直接，并且可以快速完成。如果设备符合HART标准并符合HART概念，则DD将更加简单。另一方面，复杂的设备可能需要很长时间才能建模，并且可能需要在DD中使用许多“技巧”（例如，有效性、条件或方法）。

虽然了解或学习DDL很重要，但了解现场设备更为重要。在大多数情况下，编写DD的最佳人选是开发该设备的人。设备开发人员学习DDL的成本通常远低于记录设备并将设备教授给DDL专家的成本。

获取正确的HART DD开发工具

为了有效地开发你的DD，你需要DD-IDE。该工具是利用经验丰富的FieldComm集团工程师积累的DD开发知识设计的。这些专业知识是通过多年编写DD、教授DD开发人员以及为全球DD开发人员提供技术支持而获得的。DD-IDE工具旨在让您开发一个功能强大但可移植的独立于主机的DD。

DD-IDE提供了为现场设备开发和测试DD所需的所有工具。DD-IDE工具：

集成在单个环境中，以自动化重复任务；

提供向导以简化标准构造的生成；

支持DD的测试和调试；和允许对DD进行回归测试和验证。

DD最好是逐步开发的。这允许在可管理的小块中对设备功能进行建模和确认。例如，大多数DD开发人员首先包含了对通用命令和一组简单菜单的支持。然后，一次添加和测试一个通用实践命令，然后是设备特定命令。

这将导致重复多次的“编辑-生成-测试-验证”循环。DD-IDE为该循环中的每个步骤提供工具，包括：

编辑-DD-IDE的核心是一个强大的DDL知识丰富的编辑器，具有向导和项目管理功能。

提供了构建-令牌化器和DD管理工具。

测试-提供SDC-625参考DD主机是为了方便DD的测试。

验证-提供的工具有助于验证DD。其中包括Xmtr DD，它允许您模拟设备并产生异常行为来测试DD。

了解HART协议

您的设备必须符合HART，因为并非所有主机应用程序都使用DD。启用DDL的主机应用程序是大型、重量级的应用程序。例如，控制系统和I/O系统通常具有实时要求或有限的容量，这阻碍了它们对DD的利用。这些类型的主机应用程序使用HART通用和通用规程命令，并取决于设备是否完全兼容。

为了简化和加快DD开发，HART DD-IDE提供了为HART协议建模的标准DD库。理解HART应用层是理解这些标准DD的关键。DD-IDE提供了示例DD，以演示标准DD的使用。

了解HART简化了HART兼容设备的开发。这一点很重要，因为解决DD中的设备合规性问题会直接导致更复杂的DD和更长的DD开发周期——开发成本更高，维护成本更高。

对HART协议、符合HART的设备、标准DD和HART DD-IDE的使用有深入的了解，可以最大限度地提高DD开发的生产力。

FieldComm集团提供HART协议培训研讨会。HART基础是一门为期一天的强化课程，涵盖HART通信协议的各个方面。参加本课程的学生将具备开发新的HART兼容产品、支持现有产品和设计使用HART的系统的知识。学生还将了解测试设备的正确方法，并将其注册到FieldComm小组。

学习EDDL和FDI

虽然了解您的设备是编写好DD的关键，但也需要了解EDDL。设备描述语言是一类独特的计算机语言。它是一种基于文本的语言，用于对现场设备的行为进行建模。这种独特性可能会使理解EDDL变得困难，因为它对大多数开发人员的经验来说是陌生的。

EDDL是HART标准，也是FieldComm集团认可的唯一用于HART设备配置的技术。自1990年以来，EDDL一直是HART技术的关键要素，已被证明是一个可靠、稳健和稳定的平台，供供应商一致定义和记录HART产品的功能。2004年3月，EDDL被批准为国际标准——IEC 61804-2。

FieldComm集团提供EDDL研讨会，帮助开发人员学习EDDL。EDDL规范既非常具体又易于阅读。《外国直接投资技术规范》定义了外国直接投资一揽子计划中包含的EDD和增强功能的附加属性。设备集成-编写EDD和FDI软件包研讨会是学习EDDL的最快方式，提供课堂讲座和许多小时的动手、讲师辅助的开发时间。

开发您的EDD

1.创建唯一命名的源文件。

所有注册到FieldComm组的DDL源文件都存储在一个目录中并标记化。这意味着所有源文件都需要具有唯一的文件名，这样，当DD添加到库中时，所有制造商和设备类型的文件都不会被重写。此外，所有DD源文件，包括图像文件（*.jpg、*.gif、*.png），必须位于同一目录中，而不使用子目录。

FieldComm组注册可接受6种扩展类型：*.ddl、*.dd、*.h、*.jpg、*.gif和*.png

注意：DD注册不接受其他文件扩展名

文件名的最佳做法是使用与设备修订版连接的扩展设备类型作为提交包中所有源文件的前缀。例如，扩展设备类型为0x1111、设备版本为0x23的设备的源文件名为111123_main.ddl、111123_icon.jpg、111123_menus.dd。使用此文件名约定可以轻松识别文件，并确保文件名对您的产品是唯一的。

2.识别

在主源文件中，识别制造商和设备，以及EDD版本。

主DDL文件（*.DDL）–每个DD必须有一个DDL源文件，其中定义了DDL对象。

文件名必须使用扩展名*.ddl，并且每个DD注册只能有一个*.ddl文件。如果需要多个源文件，则可以在注册提交中添加额外的DDL Include Files（见下文）。

该*.ddl文件中必须声明制造商构造，并且应具有制造商和设备类型的字符串值（在devices.cfg中定义）。请勿在此声明中指定实际数值。

对的：

制造商FCG，设备类型_示例1，设备_愿景1，DD_愿景1

不正确：

制造商249，设备类型249，设备愿景1，DD_REVISION 1

DDL Include Files（*.dd）–可以创建包含DDL对象的任何其他文件（如果需要）。文件名必须使用扩展名*.dd。

定义（*.h）–此文件只能包含宏和/或#defines。此文件中不得定义任何DDL对象。开发人员必须包含标准DD库宏.h和方法.h文件。

Images（*.jpg、*.gif和*.png）–IMAGE的PATH属性必须包含一个唯一的文件名，没有特定的路径，以便所有图像文件与其他源文件位于同一目录中。

对的：

路径“26ef01error.gif”

不正确：

路径“pics\\26ef01error.gif”

请不要提交整个项目的工作目录。

3.导入标准HART DD

所有设备必须遵守HART通信协议规范的有效修订版。HART标准DD设计用于完全建模和表示这些规范：

HART 5 DD必须导入通用版本5、DD版本2（Univ5_2.ddl）和通用规范版本7、DD版本4（Cmn7_.ddl）

HART 6 DD必须导入通用版本6、DD版本2（Univ6.ddl）和通用规范版本8、DD版本2中（Common8.ddl）

HART 7 DD必须导入通用开发版本7、DD版本2（Univ7.ddl）、通用实践版本9、DD版本2中（Common9.ddl）

所有DD必须导入最新的通用表格规范（HCF_SPEC-183）标准

目前-开发版本20，DD版本4

一般情况下：

所有DD必须导入标准_PV

UNIVERSAL必须导入所有内容

不要删除通用命令

不要删除导入的变量（包括标准_PV）

有关标准项目的重新定义，请参阅HART EDD附加测试

4.HART标准DD命令

除非HART协议规范明确允许在设备内修改命令，否则不得更改标准DD中引用的所有HART命令和数据（即REDEFINE）。

如果HART协议允许截断设备中的命令，则必须修改命令以匹配DD。DD必须使用标准DD命令的精确子集，而不添加任何用户定义的变量或进行额外修改。

例如，典型的修改可以包括但不限于：

命令3可以重新定义（仅当支持的动态变量少于4个时）

可以重新定义命令8（仅当支持的动态变量少于4个时）

只有在HART协议的修订允许的情况下，命令9才能重新定义为少于8个槽的设备变量。

只有在不支持所有数据字节的情况下，才可以重新定义命令48。

所有过程测量（即设备变量）必须使用COLLECTION进行建模，并将其名称和设备变量代码添加到COLLECTIONARRAY“设备变量”中

HART协议中定义的所有不可截断（和不可修改）命令必须按照标准DD的规定使用，不得重新定义。

5.HART标准DD数据（即变量，包括通过集合/ARRAYs的参考）

如果通用表DD中未列出制造商/扩展设备类型代码，则VARIABLEs manufacturer_id、private_label_distributor和设备类型的枚举值和描述可能会重新定义

只有当变量有写入命令时，HANDLING才能重新定义为READ&WRITE

DISPLAY_FORMAT和EDIT_FORMAT可能被重新定义

DEFAULT_VALUE可能被重新定义

REFRESH_ACTIONS可能被重新定义

不得重新定义标准DD中指定的所有其他属性。

6.HART标准DD标签/说明

必须按照标准DD中定义的方式使用标签和帮助字符串。选择这些字符串是为了适当地反映HART规范，并受UTF-8标准DD的管辖，该标准允许多种语言翻译。

以下命令48数据字节可能会重新定义其LABEL和描述：

设备_规格_状态0、设备_规格_status_1、设备_规范_status_2、设备_规定_status_3、设备_指定_status_4、设备_说明_status_5、设备_具体_status_14、设备_明确_status_15、设备_规定_status_16、设备_特定_status_17、设备_确定_status_18、设备_特殊_status_19、设备_专门_status_20、设备_指明_status_21、设备_详细_status_22，设备规范状态23，设备规范状态24

不得重新定义标准DD中规定的所有其他HART数据串（标签/说明）。

注：如果在标准DD中发现不正确、不完整或缺失的标签/说明，请在提交DD注册之前与技术服务部门联系。

7.用户界面

以下强制性根菜单必须在DD中定义：root_menu、device_root_menu，process_variables_root_menu、diagnostic_root_manu、offline_root_mnu*和maintenance_root_mnu*

注：HART工作组破例要求EDD中的offline_root_menu和maintenance_root_mnu。菜单仅适用于FDI设备包。开发人员必须在提交的“readme.txt”中包含一个参考：“根据WG PD20013，请求免除对offline_root_menu和maintenance_root_mnu根菜单的要求。”

IMAGE的PATH属性必须包含一个没有特定路径的唯一文件名，以便所有图像文件与其他源文件位于同一目录中。

8.构建和测试

提交的源在由Tokenizer构建时不得产生任何错误，否则将导致测试活动失败，从而导致测试服务费的发票开具。

如果需要对标准DD进行更改，制造商必须在提交EDD之前记录更改并请求批准。需要经批准的变更请求（CR#），这应作为EDD提交包的一部分在Readme文件中注明。（请参阅：如何提交更改请求。）

与当前HART协议规范的所有偏差都必须有一份在提交日期前批准的支持性文件（CR#、AR#或PD#）。这包括：

重新定义标准变量或命令

ADD枚举或位枚举

符号表中现有项的数据类型的REDEFINE

由HART协议规范定义但尚未在标准DD库中发布的命令（即浓缩状态命令）。

主机模拟器软件产生的错误必须在提交EDD供FieldComm Group测试之前解决，否则将导致测试活动失败，从而导致测试服务费的发票开具。示例包括但不限于：

T链接错误、链接错误

成员列表找不到成员错误

命令数据项无法解决错误

回复中的索引与请求中的索引不匹配错误

引用数组deviceVariables的getByIndex（）无法获取索引值错误的ItemByIndex

命令有效性规则失败错误

应使用FDI参考运行时环境（RRTE）来探索连接到实时设备时产生的FDI设备包内容和EDD。