【整理】HART EDDL概述

注:

更多关于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的大概用途。



发表评论

电子邮件地址不会被公开。 必填项已用*标注

无觅相关文章插件,快速提升流量