注：

更多关于EDDL的内容，详见：

【整理】EDDL简介

下面的内容，主要翻译自：

HART的spec中的：SPEC500.pdf

即：Hart协议中的Device Description Language Specification

即Hart的EDDL的spec。

注：

HART的EDDL的规范，一共两个，分别是：

• HCF_SPEC-500 == SPEC500.pdf == Device Description Language Specification

• HCF_SPEC-501 == SPEC501.pdf == Device Description Language Method Standard Library Specification

前言

Device Description Language (DDL)，之前一直没啥变化；

5年后，才发布了第一次更新的改动：DD Language Enhancements

当然，此更新，确保了向后兼容性；

更新主要包括：

• 添加了BLOB和TEMPLATE这两个概念；

• （为HART 7）针对VARIABLE添加了新的TYPE：TIME_VALUE

• 支持离线设备配置(Offline device configurations)

• 支持共享文件，比如访问一个，包含了工程数据的，外部的数据库

• （为HART 6）内在的支持了块数据传输（Block Data Transfer）

• 增加了很多用于描述host和device的特殊的符号（symbol）

• 增加了很多详细的阐述说明，以及很多细节方面的小的提升；

Block Transfer的概念，是HART 5中引入的，然后HART6实现了完整的描述；

此版本的DDL支持Block Transfer：

• 添加了新的概念：BLOB

• 相关的库函数，以支持Block Transfer，详见：HCF_SPEC-501

HCF已经在SDC-625中，部分的为此做出了原型设计，以验证此概念的可行性；

新添了，支持和标准化离线配置（Offline Configuration）：

• 此部分的内容是和FF（Fieldbus Foundation），PNO（Profibus Nutzerorganisation）一起联合开发的

• 对应的是添加了新的概念：TEMPLATE

• 菜单（MENU）中添加了对应的上传和下载（Upload/Download）的动作；

• 以及标准化了的相关请求，用于离线配置和配置数据库（Configuration Database）；

在DD中，很久之前就已经，一直存在的，一些常用的标准的符号，现在已被加到此EDDL中了：

• 比如device_root_menu，factory_protection_array

• 以及为离线配置而新增的：download_to_device_root_menu

增强了设备模拟方面的功能：

• 生产HART设备的公司，通过DDL指定了设备的功能需求；

• 此预先配置好的DD，帮助和促进，在还未真正生产出真正的设备之前的，设备的应用程序层的设计；

• 在模拟方面的增强的功能，给在还未完成设备的固件开发之前的设备的验证，提供了方便；      

  • HCF device simulator，Xmtr-DD，在某种情况下，就已经实现了此类的功能。

HART的EDDL规范：HART DDL Specifications，即HCF_SPEC-500和HCF_SPEC-501，在设计之初，就是互相协作的。

在此版DDL规范之前，HART DLL的版本命名的规范就已经制定好了。

此规则是基于HCF By-Laws和HART Protocol Specifications，而这两个东西也都是基于此DDL协议的。

无论何时，兼容于HART协议规范的优先级，都要高于兼容于DLL规范。

所有的HART设备，DD文件，DD主机应用（程序），都必须先要是符合HART协议的。

HART所唯一支持的，用于实现最通用的配置HART的技术，就只有DDL。

HCF，HCF的DDL工作组，以及和FF，PNO之间的合作，都一如既往地坚定的支持DDL的持续发展。

DDL如有任何更新，都会持续的加入到HCF中的。

DDL的简介

DDL，一种用于现场设备建模的一种语言；

所谓建模，就是建立模型，此处就是为现场设备建立模型；

只有建立了模型后，才能更好的，全面的，精确的描述设备的各种信息。

DDL允许，即使实现对于设备不是很了解，也可以通过Host主机应用（程序）去利用，配置，校准，诊断设备；

DDL允许，通用的，完整的，对于设备的，所有的属性和功能的访问，且兼容于所有的HART设备。

现场设备中的很多数据，被HART协议标准化了。

支持标准化的去访问，过程值，基本的校准，设备和过程的状态，设备的识别信息等等。

这些数据是通过，通用的（Universal）命令，惯例（Common Practice）命令，厂商特定（Device Family Commands）的命令。同时对于设备相关的数据和属性，也是可以获得的。

对于设备来说，很多和设备相关的，特殊的一些功能，都是通过自定义命令去实现的。

而由于设备又是变得越来越复杂，导致此相关的命令和数据，都是越来越复杂和更加广泛。

所以HAR协议就为此，提供统一的，一致性的接口，去获知设备的能力。

这使得了本地的用户界面面板，减少了兼容HART设备的复杂度，以及提供了额外一种选择。

更多的需求是，希望找到一个统一的接口，去实现，查看，配置设备属性和行为；

关于设备描述语言这个概念，是来自一个1900年的一个关于现场设备的讨论中；

此概念第一次真正实现了，是在HART的DDL中；

后来才是用于FF和Profibus；

DDL是一种基于文本的描述语言，用于描述设备，建立对应的模型的，且是主机平台，操作系统，技术，无关的；

DDL，将，设备的实时的数据库，与设备间的通讯，设备所用到的SOP标准操作，建立对应的模型。

估计多数软件开发者都会发现，此DDL语言，和其他编程语言很不同；

因为DDL中，主要是通过描述，陈述，一个东西是啥，而却没有描述主机Host端如何去实现此东西；

DDL是去告诉主机Host端，此设备具有什么功能，而关于如何去利用这些功能去实现自己的目的，则是Host端自己要关心的。

DDL也可以描述一些非常复杂的设备的行为；

比如，设备在某种模式下，是存在某些数据，且可以被修改的，但是却在另一种模式下，根本不存在此数据；

而修改了一个数据，还可能影响到其他的数据；

DDL提供机制以支持开发者去描述比这更加复杂的功能；

通过此DDL，设备的开发者，可以用来组织设备的数据，属性，过程等，用于用户访问；

此点，对于Host应用端意味着，是需要动态地，显示出对应的图形界面，去显示和表示设备的各种数据；

且不同的设备的图形界面可能会差异很大；

根据DDL的描述不同，则对应的数据，属性，过程等可能会很简单，也可能会很复杂；

HCF的DD库中，有来自世界各地的DD文件；

新版本的，或者升级后的，DD，可以被加载到已有的主机应用中，以支持那些可能实际上还并未存在的设备，使得支持以后的可能出现的该设备，以此实现了更好的扩展性；

也使得，新的设备的发布，不依赖于主机端的应用程序；

当有了现存设备的DD文件后，就可以加载到主机端应用中，然后主机应用就可以操作该设备；

设备的开发者，无需再（繁琐地）去验证主机端的应用，而只需要验证和保证自己的DD的有效性即可。

以此实现了，新的设备和主机端，新版本的已有设备和主机端，都可以实现，独立的发布，而不会影响到对方。

DDL并没有替代设备的技术文档（HCF_LIT-18）。

此文档提供了，在应用层数据，属性，DD中的过程之上的，关于性能方面的细节和其他技术信息；

DDL支持通用的主机应用程序；

DDL为主机端操作设备提供了一个集中的地方，存放了所有的相关的信息；

而这些应用程序可以访问到设备的所有的数据，属性，因此简化了HART兼容的设备的维护，支持和操作；

DDL在小的手持的主机端和大的集成维护系统，都工作的很好；

DDL也支持嵌入式的应用和运行于商业操作系统中的应用；

DDL的强大功能和可移植性，为主机端和设备端的提供商，节省了大量的成本；

HART的EDDL的概述

2.现场设备中，包含各种数据：

• （设备本身的）配置（configuration）数据；

• （来自传感器的）测量值；

• （从测量值中）计算出来的值；

• （和时间有关的）历史性数据；

而用户呢，对其中很多数据，都很关心，需要用到这些数据。

而EDDL，就是一个设备描述语言，其定义一个框架，以实现更加方便的描述这些数据，提供给上层应用程序或用户。

EDDL，针对数据，主要提供了几种方面的支持：

• 有哪些数据变量：variable

• 这些数据变量之间的关系：relation

• 去获得这些数据时的方式：manner

• 数据如何呈现给用户：presentation

另外还定义了，关于有哪些方式去实现用户更改配置数据，以及当配置变化后，如何更新主机（host）数据库等内容；

所以，为了提供如此众多的信息，且以一个比较层次分明的结构体现出来，因此EDDL中会定义很多的概念（constructs）。

这些概念，可以根据其逻辑关系，分成几大类：

• 数据data；

• 人机交互HMI；

• 通讯模型communications modeling

• （通过METHOD实现）标准操作过程SOP（standard operating procedure）：      

  • 维护maintaining

  • 校准calibrating

  • 试运行commissioning

  • 配置configuring

由此相关的，对应于EDDL中的各种概念就是：

• 数据data      

  • 和数据本身有关的：          

    • 物理上的（设备的数据空间，设备内部所用的存储设备，所存储的变量）              

      • VARIABLE

      • ARRAY

      • LIST

    • （逻辑）概念上的（用于组织数据，允许设备内的多个不同的操作间的间接引用）              

      • Reference-arrays

      • COLLECTION

    • 用于代表设备本身的，指定DD数据存放于Host端的：              

      • FILE

  • 和数据之间的关系方面的：          

    • UNIT

    • REFRESH

• 通讯模型communications modeling      

  • 用COMMAND来表示，定义了：          

    • 命令号

    • 会话Transaction              

      • 会引用对应的数据项（比如VARIABLE）

    • 返回代码（的格式）

  • COMMAND主要是被（DD）Host端来使用的          

    • 去访问设备的数据，确保Host本地的缓存数据是最新的

    • DD并不能告诉Host端，什么时候，发哪个命令；DD的设备模型中，包含了对应的信息：在何时，发送何命令；

• 人机交互HMI：      

  • 方便DD开发者：          

    • 根据相应的逻辑去组织数据；

    • 当前的设备的数据，应该以何种方式去显示给用户看；

  • HMI中最重要的就是MENU了：          

    • 每个MENU都包含了对应的每个项之间的逻辑关系；

    • MENU中会引用到MENU，METHOD，EDIT_DISPLAY等项；

    • 其中的EDIT_DISPLAY，提供的是类似于弹出窗口显示更多详细信息的功能；

  • 除了显示数字和文本等内容外，还有GRAPH，CHART等显示的内容；          

    • 如果GRAPH是在一个菜单列表中时，对应的会显示WAVEFORM；

    • CHART是用于，对于单个数据项，随着时间的变化，而显示出来的图表；

  • 很明显，HMI只是描述了显示的逻辑结构，不涉及技术细节，所以算是可移植的，只要DD的Host端能显示即可。

• 标准操作流程SOP：      

  • DD除了支持描述设备的数据和通讯之外，还支持SOP；

  • SOP是通过ANSI C语言的一个子集，来定义的。

  • 一般都是通过对应的METHOD来实现的。          

    • 举例：校准数模转换器的过程，重新定义设备的范围

【总结】

经过如此的解释，才算是对于EDDL的出现和基本用途，有了个大概的了解了。

以及HART中的EDDL的大概用途。

转载请注明：在路上 » 【整理】HART EDDL概述