-
-
手机阅读
摘 要 介绍了高速以太网现场总线的系统管理内核与系统其他部分的通信，实现了一种可以对数据进行可靠、快速、安全传输的通信机制。
随着通信、计算机等信息技术的飞速发展，在自动化领域也引起了系统结构的变革，逐步形成了以网络集成自动化系统为基础的企业信息系统。现场总线就是这一发展的最新技术。根据国际电工委员会 IEC标准的定义：现场总线是联接智能现场设备和自动化电路系统的数字式、双向传输、多分支结构的通信网络。现场总线控制系统既是一个开放通信网络，又是一种全分布控制系统.其具有开放性、互操作性与互用性、设备的智能化与功能自治性、系统结构的高度分散性和对环境的适应性等诸多技术特点，还具有硬件投资少、安装费用低等优点。
基于以上优点，ISP和World FIP于1994成立了现场总线基金会（Fieldbus Foundation简称FF）。并于1996年颁布了低速总线H1的标准，使H1低速总线开始步入使用阶段。又于2000年3月颁布了基于高速以太网（简称HSE）的现场总线协议FS1.0，同年11月又颁布了第二版FS1.1。
在整个 FF HSE现场总线的体系中，包括了系统管理（SM）、网络管理（NM）、现场设备访问（FDA）、现场报文子层、功能块应用进程（FBAP）等几个大部分。作为一个极其重要的部分，系统管理要实现的功能为分配/清除现场设备地址、识别设备、定位、版本控制、实现应用时钟同步、调度功能块、设置/清除分配信息。而作为系统管理表现体的HSE系统管理内核（SMK）是实现这些功能的具体实现单元。系统管理内核SMK是一个现场总线设备的系统管理的实现实体，在和FDA、以太网表现体（EP）、联接设备、功能块应用进程的交互过程中，通过原语的交互完成系统管理所要求的各个功能，如图1所示。
对于系统管理所要实现的分配地址等七项功能，系统管理内核如何知道是哪种功能原语，如何得到原语中的参数，如何处理这些参数并返回响应原语等问题都是较为复杂的。尤其是还要把这些功能都整合起来形成系统管理内核，其难度就更大。因为对应每个功能的实现，都关系到整个系统的其他各个部分，所以这里就会有极多的交互操作。作为这样一个大型的系统网络结构，其各个部分的通信必然是很频繁的，同时通信量也是很大的。因此势必需要一个很好的通信机制来对这些通信过程进行管理。而这个通信机制的好坏直接影响到整个系统管理内核的实现。
高寒速以太网现场总线的协议是 2000年11月制定的，国外的研究机构也正在完成此协议的实现工作。由于国内对于现场总线的研究起步较晚，因此还没有一个成熟的机理可以借鉴，我们只有参照协议来摸索解决方法。我们所面临的最大问题就是如何有效地对如此复杂的原语进行通信传输，只要完成了这个通信过程，其他的就是本地操作，难度就不大了。要实现这个通信过程，这里的关键问题就是正确识别原语类型、保证原语结构。只有以上两点得到很好地解决，我们才可以进行可靠的系统管理内核通信。
我们先说明系统管理内核的通信过程，由图 1可以看出，SM消息是HSE SMK与HSE FDA进行交互的唯一渠道，同时SMK还和其他部分有交互，但其主要的通信集中在SM消息上，故本文把重点放在SM消息的通信上，其他的通信方式大致相同。
SM消息的通信是通过FDA的SM端口来完成的。所涉及到的操作功能为识别、版本控制、定位和地址分配，它们各自通过相应的原语交互来完成。这里所涉及到的原语有六条，分别为Find Tag Query（Unconfirmed Service）、Find Tag Reply（Unconfirmed Service）、Identify（Confirmed Service）、Clear Address（Confirmed Service）、Clear Assignment Info（Confirmed Service）、Set Assignment Info（Confirmed Service）、Device Annunciation（Unconfirmed Service）。这些原语都是结构体，里面包含了大量的参数，其处理过程也各不相同。因此我们在这些原语的消息头（Message Header）中，增加了FDA消息号（FDA Message Version）、协议号与确认消息类型（Protocol Id And Confirmed Msg Type）、服务类型（Service）等参数。其中，在Protocol Id And Confirmed Msg Type这个无符号八位的参数中，1bit位上的值为1表示Confirmed Service，为零则表示Unconfirmed Service，2～8bits位上的值表示服务的ID号。在各条原语的主体部分。分别包含了原语各自的参数，具体的参数在协议中有明确的定义，这里就不再叙述。在消息主体部分，一般都包含源地址和目标地址，这是进行通信的基础。同时在这些原语的消息尾（Message Tailer）中，如果发出的原语是确认原语，则在消息尾中包含Invoke ID，否则，则不带Invoke ID。有了这些参数，SMK有了识别各条原语的基础，同时也就可以进行相应的操作了。
一般 SM消息的处理流程如下：由下层的FDA经过FF SM UDP端口接收消息，然后根据原语自带的参数对其进行识别，如果是SM消息，则送往SMK，如果不是，则丢弃。它这里的识别是通过判断消息头中所带的Protocol Id And Confirmed Msg Type参数来实现的，当这个参数1～6位的值为2时，则表示这个消息为SM消息，送入SMK；当SM消息送入SMK后，就进入SMKPM。在SMKPM中，实现对各条原语的确认、操作、处理，然后产生新的原语，仍然通过SM端口返回。在SMKPM中的操作如图2所示。在SMKPM中，有一个关键的函数RcvMsg（），这个函数完成的任务就是识别原语的类型。其工作原理为把接收到的SM消息原语进行解码，取出原语中的消息头，消息主体和消息尾。然后根据消息头中的Service参数来判别是何种原语，其判别的根据是取出Service这个参数的2～8bits位的值。我们就得到了一个Service ID，通过这个参数我们就可以知道原语类型了。其对应关系如下表所示。然后分别送人SMKPM中的不同状态进行处理。这样就解决了原语识别这个关键问题。
在 SMKPM中，不同的原语经过了不同的处理，如果接收的原语正确，则产生新的原语，如果接收的原语错误，则产生一个错误类，这个错误类也可以认为是响应原语。在产生的响应原语中，返回请求原语所需要的参数；在产生的错误类中，指明是原语的错误类型。在原语返回的过程中，请求原语中包含的源地址在响应原语中就成了目标地址，根据这个地址，SMKPM就可以把产生的响应原语进行返回了。在这个处理过程中，我们并不对原语的结构进行改变，所以这些新产生的响应原语在结构上与请求原语是完全一样的，所不同的只是里面的参数值。如果产生的是错误原语，这个错误原语也有其固定的结构。所以对应某个原语，在传输过程中，其结构是不变的。因为只是对原语中的参数进行处理的方法，所以就能很可靠地保证原语的结构，也就解决了保证原语结构不受破坏的关键问题。引用了这种通信机制后，我们就能够非常可靠、快速的实现SMK原语的通信。
我们这里引用了一个很好的通信机制，即通过 RcvMsg（）这个特殊的涵数来实现原语的识别，然后通过对各条原语的参数处理操作来实现各个部分的交互。同时在整个通信过程中，只是对各条战线原语中的具有参数进行处理，而各条原语的结构都是固定的。正因为原语结构的稳定，所以能保证整个通信过程的可靠性。在实际的应用中，在这个过程中，我们随机对这些原语结构进行分析，得到了可靠的数据。对于每天一条原语，以经过了SMKPOM 生产的影响应原语的结构固定，没有出现数据包丢失或破坏的情况。