PROFIBUS-DP现场总线控制系统性能研究及诊断软件开发

　　随着越来越多工业控制系统采用了Profibus现场总线技术，对这些控制系统进行具体的、直观的和实时的在线分析与诊断成为了最基本的要求，要想完成这样的任务，就需要有相应的工程分析诊断工具。国内外目前所研究的这些总线性能分析诊断工程工具存在着功能不够全面、界面不够完善、价格昂贵、不适合中国国情等问题。开发一款能够对总线系统进行分析和诊断，方便的、性能价格比高的分析诊断工程工具必将成为急需的产品。

　　由于在PRIFBUS传输报文可以反映出总线性能的很多参数，包括各种故障状态。比如：从参数化报文可以看出主站和从站的关系，从站的操作方式，包括通道参数、功能设定、装置参数和ID号等。从组态报文可以看出从站I/0类型及性质，以及模块的I/O性质及数据类型等。从诊断报文可以看出从站各种参数设置错误，各种组态错误，以及装置模块错误类型。所以，本文作者就是在对Profibus-DP报文进行详尽分析的基础上，采用VC++ 6.0开发了一款基于串口通讯的Profibus性能分析诊断软件。

　　1 Profibus工作机理

　　1.1 Profibus-DP编码技术

　　PROFIBUS-DP交换数据使用异步传输技术和NRZ编码。NRZ编码的二进制信号“0”或“1”的信号电平在信号持续期间维持不变。图1所示为NRZ码信号图。　　

　　图1 非归零码信号

　　每个数据链路层协议数据单元应由一定数量的字符组成，每个字符都是一个用于异步传输的起——停字符。

　　每个字符由11个比特组成，包括1个总是为二进制“0”的起始比特(ST)，8个可以是二进制数“0”亦可以是二进制数“1”的信息比特，1个可以是二进制“1”也可以是二进制数“0”的偶校验比特(P)，1个总是为二进制数“1”的停止比特，如图2所示。　

　　图2 单个字符格式

　　接收器的比特同步总是从起始比特的下降沿开始，也就是说，在从二进制“1”转换到二进制数“0”时开始。在比特时间的中间应扫描起始比特和所有后继的比特。在比特时间的中间，起始比特应是二进制数“0”，否则认为同步失败并停止同步过程。以二进制“1”的停止比特来结束字符的同步，如果此时出现二进制数“0”来代替此停止比特，则应认为并报告一个同步差错或字符差错，并应等待下一个起始比特的前导沿。

　　1.2 报文格式

　　如图3所示，PRFIBUS-DP有以下5种报文格式。其中，SYN为同步周期，它是一个最小的时间间隔，在此时间间隔内，每个站在它可以接收发送/请求报文帧或令牌起始部分之前，应从传输介质接收空闲状态(idle state)(idle=二进制“1”)。同步周期最小为33个线空闲比特;SD为起始定界符，DA是目的地址，SA是源地址，FC是控制帧;FCS是帧校验和，ED为结束定界符，值为16h，L是信息字段长度，其中SD1= 10h，用于请求FDL状态，寻找一个新的活动的站点，报文长度固定，没有数据单元;SD2= 68h，用于SRD服务，报文的数据长度可变;SD3 = A2h，数据单元长度固定(L总为8字节);SD4 = DCh，表示该报文为令牌报文;SC =E5h, 短确认报文。　

　　图3 PROFIBUS—DP链路层报文格式

　　2 报文诊断软件的实现

　　2.1 实验平台

　　图4为作者组建的PROFIBUS-DP网络实验系统结构图。在网络系统中，1类主站为SIEMENS公司的CPU315-2DP PLC，PC工控机作为2 类主站，通过现场总线接口卡CP5611与DP 总线相连， WAGO公司的750-333、BECKHOFF公司的BK3120、SIEMENS公司的ET200-L及和利时公司的LM3107 PLC等PLC设备作为从站连接到DP网络中。　　

　　图4 PROFIBUS-DP网络实验系统结构图

　　2.2 软件开发环境

　　软件开发工具为VC++6.0，通过计算机标准串口通信，将PROFIBUS—DP报文采集到上位机进行处理。PROFIBUS-DP系统作为实验平台，采用RS485/RS232通信电缆将其RS485的一端接入PROFIBUS-DP网络连接器的背插接口，RS232一端直接接入到PC机的串口。

　　2.3 软件系统基本程序框图

　　软件系统的程序基本架构流程图如图5所示。　

　　图5基本程序框架流程图

　　整个系统软件包括如下几个模块：

　　1)程序主控模块：负责实现程序逻辑与主界面，调用串口通信模块和接收显示模块。

　　2)串口通信模块：负责实现串口通信任务，PROFIBUS-DP报文数据采集及串口参数设置。

　　3)数据处理模块：根据PROFIBUS-DP协议报文格式，将采集上来的数据按报文格式进行处理，并存入临时缓冲区。

　　4)接收显示模块：负责实现接收数据的处理与显示。

　　5)数据库模块及数据查询模块，用来实现对采集到报文的历史数据的分析和查询。

　　2.4 关键技术

　　该软件主要是实现对PROFIBUS报文进行提取，实现在线采集PROFIBUS-DP报文数据，从数据链路层角度对各种报文进行分析，完成各种类型报文的显示，完成对报文种类、服务类型、地址、数据长度及数据单元等信息的提取显示，并对诊断报文、参数化报文及组态报文等的数据单元进行详细的分析，得出总线性能的各种参数及故障原因，将分析过的数据存储进数据库，存入临时缓冲区，根据需要将分析过的报文信息存入数据库，实现历史查询。

　　如何实现报文帧的提取是本软件设计的一个关键问题。由于PROFIBUS报文格式有很多种，而且包括数据长度不固定的可变报文。虽然各种报文都具有固定的报头、报尾，但是存在的问题是报头报尾并不是特定的字符，有可能和报文中数据单元内容一样，所以这里利用报头报尾进行报文的提取是不可行的。作者在这里利用各种报文帧前的同步字符进行报文提取，也就是说，在每个完整报文帧传输之前，其前面都有一个不小于33bit的同步时间，在报文帧中间是没有任何间隔的，利用这一同步时间，在VC++中利用超时函数，对报文帧进行了完整地提取。

　　另外，由于通信数据量很大，速度较快，这里采用了WINDOWS多线程技术。一个线程为监视线程，监视串口通讯，一个为数据处理主线程，另外一个为定时刷新数据库线程。当监视线程监视到串口中有数据到达时，就触发一个消息通知数据处理主线程，数据处理主线程就去串口缓冲区中取出数据，并进行数据处理。定时器线程定时刷新数据库显示，以实现实时显示功能。

　　作者在程序编写的过程中，出现数据库不能实时刷新的情况，后来发现问题出在WINDOWS的WM_TIMER定时器上，由于该定时器消息优先级较低，可能造成WM_TIMER消息的丢失，所以不能实现数据库的实时刷新。解决的方法是采用WINDOWS的多媒体定时器。在使用多媒体定时器的过程中，定时间隔的选取又是一个关键的问题，定时间隔选取太小，将会耗费大量的CPU内存，造成系统“死机”, 定时间隔选取太大，又不能完成“实时”显示功能。这里又涉及到PROFIBUS总线信息循环时间的问题，总线信息循环时间与总线传输的波特率、从站的数量、I/O数据的数量、从站需要的延迟时间以及主站的空闲时间等有关。作者通过了大量的计算和多次实验调试，寻找到一个合适的定时器间隔。

　　2.5 显示界面

　　该PROFIBUS-DP报文分析软件的程序界面包括主界面、串口配置界面、报文过滤界面、报文查询界面、数据库存储界面以及历史查询界面等。

　　PROFIBUS-DP分析诊断软件的运行主界面如图6，窗口左上部分“当前profibus报文”组框内存放最近采集到的PROFIBUS-DP报文信息，并可通过工具栏上的记录移动按钮滚动察看记录;右上方“信息面板”是用来显示所有查看报文的详细信息。窗口下半部分以网格形式显示PROFIBUS-DP历史信息。

　　若需要打开串口，开始接收PROFIBUS报文信息，则可选择“命令”菜单下的“开始接收”项;若需停止接收PROFIBUS报文信息，则可选择“命令”菜单下的“停止接收”项;若需要配置串口参数，则可选择“命令”菜单下的“串口配置”项，此时将弹出“串口配置对话框”，若需清除当前所有记录，可选择“记录”菜单下的“清除所有记录项”命令，如果需要分类查看各种报文，可以选择“查看”命令菜单下的“报文查询”，此时将弹出“报文查询对话框”，可根据需要进行报文分类查看。　　

　　图6 软件运行主界面