FDT2的功能(二)

2014年07月28日

　　4.4 公共组件

　　互操作性

　　所有组件的互操作性是在工厂中使用FDT最重要的先决条件。这就是为什么在FDT2的开发期间给予了特别的关注。接口简单化和规范详细化 – 比较以前的版本 – 在这方面有很大进步。比如，对框架应用和DTM的状态机进行了优化，线程使用规则(执行线程相互平行)和他们的同步进行了精确定义。

　　然而，互操作性主要取决于各产品执行规范的一致性。为了确保这个FDT2规范最重要的部分，诸如接口行为，FDT组织已经声明这些部分作为“公共组件”开发，并集中管理。然后对这些组件进行授权，由许可公司用于执行FDT项目。

　　在开发期间，新框架应用和DTM可以不改变地使用公共组件，因此，不会对规范执行造成偏差。这导致从本质上改进了互操作性，降低了互操作性测试的工作量。同时，DTM和框架应用的开发变得更简单、更快，更具成本效益。

　　图16 设备DTM中的公共组件

　　4.5 垂直通信

　　垂直通信(嵌套式通信)是一种由FDT从一个框架应用跨越各种通信系统的边界，在多层面和分层拓扑中，建立有针对性的设备连接，从框架应用跨越不同通信系统边界。

　　该方法也称为垂直通信，因为在这个过程中要经过多层叠加才能完成。原理在于所有的DTM要不间断地连接，保证了路径的畅通，每个DTM仅需要支持他自己的通信协议，不需要了解整个拓扑结构。

　　● 一个设备DTM在第一次建立通信时需要至少一个通信DTM作为一个通信通道。有了相应的网关DTM，就可以打开跨协议层的通信路径，比如从以太网现场总线到HART(图17)。有为所有公共通信协议提供的网关DTM;可以为额外协议以及相关组件创建DTM。这种分层通信路径的结构可以简化框架应用的通过能力，当一个路径打开时，扫描连接设备上的协议可以找到正确的DTM。图17表示了垂直通信;所有DTM需要访问的组件要在框架应用的设备目录中注册。为了访问系统，对应于项目工程的访问路径，需要配置和检索彼此耦合的DTM。图17显示了基于“在一个设备上加载数据”机制的规程：在调用“开始对设备写数据”时，设备数据通过负责的DTM设备(1)准备，“打包”成这个设备支持的HART协议，然后转移到更高层的DTM(2)。

　　● DTM 2 重新打包数据/HART包成他支持的现场总线协议，然后把他传递到更高层的DTM 3。

　　● DTM 3进一步扩展打包成他支持的以太网协议，然后把这个过程创建的“整个包”转发到DTM 4。

　　● DTM 4用一种报文结构把整个包传输到控制器(5)，由此到达了实际物理网络的最高层。

　　● 设备6、7和8从各自高层设备接过数据包，在每层进行拆包，然后转发到下级设备。

　　● 链条最终的设备加载了数据(结束，数据写入设备)。

　　这里显示的以太网、现场总线和HART的网络拓扑结构，这里只是作为一个例子。这种方法，也称为“通过系统拓扑路由”，能够不受限制地应用到其他系统，特别是非常复杂的系统。

　　图17 通过多层的垂直通信

　　4.6 PLC 工具接口

　　把过程信号集成到PLC编程系统

　　FDT技术首先用于在控制器、控制系统或在工厂资产管理系统中现场总线设备的集成和配置。PLC编程系统通过FDT框架应用访问设备或他们的DTM，这就是为什么FDT已经支持 – 在工厂自动化中总线类型众多的– 大量不同的现场总线和以太网协议。然而，一个用户不断提出的要求是在设备集成期间把过程信号考虑进来，所以可以用PLC编程系统以统一的方式处理所有现场总线系统。

　　由设备DTM提供的过程信号具有现场总线的特定格式。然而，在过去，没有对这些存在的信号用标准化、中立于现场总线的形式描述，这是能够统一处理的基础。这要求PLC编程系统熟悉这些总线的特定格式;按照总线类型要进行大量工作。

　　这里，FDT2规范解放了PLC编程系统，也使用户不用处理总线特别细节的任务。下面简述这个机制：

　　● 到现在为止，使用依赖现场总线的变体，编程系统直接在设备DTM(图18左边)检索过程信号信息。

　　● 在新情况下，不依赖现场总线变体，集成发生在两层形式中(图18右边)：第一通信DTM从设备DTM检索特定总线过程信号，因为他知道他们的格式。通信DTM以现场总线中性的形式结合此信息，并且把他提供给编程系统检索。

　　这种不依赖现场总线过程信号的集成能够通过另外的FDT接口和数据类型定义为通信DTM形成一种过程映射的中性描述。这一创新使得来自不同现场总线的过程数据以一致和统一的方式显示，并且数据类型按照IEC61131的数据类型分配。其结果是一个集成不同现场总线系统和不同制造商设备的完整系统。现场总线独立和在PLC编程系统中标准化使用I/O信号是向前进了一大步，对用户以及这种系统提供商都是这样。

　　图18 用于现场总线独立过程信号集成的PLC工具接口

　　4.7 FDT2作为一个对象模型

　　在面向对象编程中，“对象”被理解为一个单元，可以通过他的接口对他访问，虽被封装但能用某些属性识别。这里“接口”描述了一个对象的功能和规程，以及调用他们的动作。对象的属性和对象相互连接相互通信的机制被称为对象模型。

　　FDT2是基于这样的对象模型;FDT2的功能是通过对象及其接口来表现的，就像以下各节要阐述的。四个基本对象是框架应用、DTM业务逻辑(BL)、DTM用户界面(UI)和通信通道;图19表示了这些对象和他们之间的关系。对象模型使用了微软的.NET技术。

　　图19 FDT2的对象模型

　　框架应用

　　“框架应用”对象包含了DTM和为他们提供的运行时环境。同时，框架应用为业务逻辑或用户界面到他们的环境、以及他们之间互动提供了接口。业务逻辑和用户界面的直接互动在FDT2中是有意禁止的。框架应用本身可再分成(图20)：

　　图20 FDT2的框架应用对象模型

　　“业务逻辑”用于运行如设备通信、浏览FDT拓扑、保存数据或与DTM用户界面对象互动等功能，“用户界面”建立了用户对DTM功能的访问。

　　业务逻辑

　　业务逻辑负责处理数据和封装的设备特定和协议特定功能，这把框架应用放在与任何设备或协议交互的位置上，不用知道他们的具体细节。在这个过程中，业务逻辑和框架应用通过定义的接口进行交互。

　　图21表示在过程中使用“信息对象”：

　　图21 DTM中业务逻辑中的信息对象

　　对象DTM，DTM设备类型和设备标识符信息封装了有关设备的信息，如类型、制造商、硬件和软件版本等。对象设备数据信息封装了设备的特定数据(参数)。对象过程数据信息封装了有关面向过程设备集成的信息，如数据类型、信号方向等。对象网络管理信息封装了关于网络的信息，如总线地址、标签号或总线特定设置等。该信息是特定的协议。对象功能信息封装了关于DTM功能的信息，如标识、状态(有效或者无效)，等。对象报告信息封装了关于当前设备的数据信息，目的为了建立文件或归档。对象文件参考信息封装了关于外部文件的参考信息，如在框架应用中显示参考文件等。

　　DTM用户界面

　　DTM用户界面的对象是用图形控制元件建立的，该元件可以直接集成到框架应用的用户界面部分，或作为一个代理服务器，用DTM访问外部程序。用户界面的内容和设计是设备特定的，然而，他们的外观要遵从DTM风格指南。

　　通信通道

　　“通信通道”对象依赖于技术，打开了通信系统的路径。他是到一个标准化现场总线系统、一个专有通信总线或一个点对点连接的接入点。通信通道可以是框架应用的一部分，也可以是DTM中BL的一部分。

　　一个通信通道具有多个接口，可以建立或断开设备连接、发送报文或在工厂层扫描可用设备。

　　4.8 DTM分类

　　在自动化系统中，使用的设备类型不同，对应的DTM也不同，他们可以分为三大类– 设备DTM、通信DTM和网关DTM – 他们已在前面描述了。另外，还定义了下面的类：

　　● 复合设备DTM，用于设备的模块化设计(特殊网关DTM);

　　● 模块DTM，用于硬件模块的应用软件(特殊设备DTM);

　　复合设备DTM和模块DTM合在一起，描述了一种模块化设计的设备。

　　4.9 FDT系统拓扑

　　FDT系统的拓扑来源于DTM的多层结构，其中一个“父DTM”可以连接一个或多个“子DTM”。框架应用负责拓扑管理，即层次结构的设计，也定义了在工厂中到特定设备的通信路径(路由)。所有DTM连接的整体拓扑称为FDT拓扑，在IEC 62453-2中详细描述。