报文监测(精选7篇)
报文监测 篇1
随着智能电网概念的提出和网络计算机通信技术的迅速发展, 变电站内智能电子设备间的互操作性的需求进一步加强, 国际电工委员会提出一个全球性的变电站自动化通信标准——IEC61850。IEC61850标准是基于通用网络平台的变电站自动化系统的国际标准, 它改变了目前变电站自动化系统封闭式的结构, 使之成为一个开放性和标准性的系统。
IEC61850采用抽象通信服务接口 (ACSI) 和特定通信服务映射 (SCSM) 的方法, 将底层核心服务映射到MMS。制造报文规范MMS。MMS是OSI应用层的一个标准, 用于在网络连接的设备以及计算机应用之间交换实时数据和监控信息。
在IEC61850数字化变电站中, 网络的健康状态是变电站系统正常运行的基础。在实际运行中, 为了保证变电站的正常运行, 各个厂商生产的IED在变电站中有良好的互操作性, 需要监听、记录完整通信报原始报文, 进行在线报文分析和通信协议故障分析, 从而方便查找变电站自动化系统各关键通信环节的故障。网络通信过程监测主要包括:制造报文规范MMS/抽象服务接口 (ACSI) 过程;通用变电站事件 (GOOSE) 过程。本文主要对MMS和ACSI过程进行研究。
1 ACSI到MMS映射过程分析
IEC61850使用面向对象的UML统一建模技术, 将变电站中各种设备定义为相关信息模型和服务模型。ACSI中的抽象有两个方面:第一, ACSI定义的信息和服务模型只是一种概念性模型。第二, ACSI不定义具体的ACSI报文, 而是将ACSI服务映射到MMS上。将MMS作为应用层协议架构在底层通信之上, 从而实现IEC61850设备的互操作性。IEC61850到MMS的通信映射如图1所示。
ACSI到MMS的映射只用到MMS的一部分对象和服务, 其映射分为数据类型映射、对象模型映射和服务模型映射。对象和服务模型映射如表1所示。
在IEC61850标准和MMS中各自定义了一套用于对象类的基本数据类型。这些数据类型都是抽象的, 映射的关键是定义特定语言的诗句类型。比如将位串 (Bit-string) 、八进制位串 (Octet-str ing) 及MMS串 (MMS string) 类型定义为C语言的结构类型, 可视串 (Visible-string) 定义为字符串类型。基本数据类型映射较为简单直接, 也是所有映射的基础。 (如表1)
对象模型映射是指服务器、逻辑设备、逻辑节点数据、关联和文件等模型分别于MMS的虚拟制造设备 (VMD) 、域、有名变量、应用关联和文件等对象模型之间的映射。通过对ACSI信息模型和MMS对象模型的对比分析, 总结出两种映射方法, 分别是直接映射和间接映射。直接映射主要是ACSI中较高层次的类模型可以相对应地映射到MMS中得VMD对象等。间接映射需要将ACSI类的实例的属性结构映射为MMS对象的一或多个字段的值, 这种映射可以看作是ACSI类的MMS封装。
IEC61850定义的服务均为抽象服务, 只对服务请求的接收方需要做出的动作进行了描述。只有当这些抽象服务映射到一种具体的服务, 对携带服务采取的报文格式和编码规则以及其网络传输方式加以定义, 才可以用于实际的信息交换过程。MMS定义了一套标准的服务, 任何MMS用户使用相同的服务进行交互, 从而实现互操作表1 ACSI到MMS服务和对象映射性。IEC61850采用MMS一小部分服务进行映射。其映射过程主要是服务原语及参数的映射。
通过归纳, ACSI向MMS映射分为三种情况:第一种情况:一个ACSI服务映射到一个MMS服务;这种映射非常简单, ACSI服务直接映射到MMS的服务, 如应用关联服务中的associate、abort和release分别直接映射到MMS服务的initiate、abort和conclude。
第二种情况:一个ACSI服务映射到多个MMS服务。这种映射又分为两种子情况。第一种, ACSI定义的一个服务由于参数不同而实现不同功能, 映射到MMS的服务时, 采用不同的MMS服务实现, 例如ACSI的G e t S e r v e r D i r e c t o r y服务, 有一参数为Object Class, 当取值为“LOGICAL DEVICE”时, 映射到MMS的Get Name List服务, 用于返回服务器中所有逻辑设备对象的引用;当取值为“FILE”时, 映射到MMS的File Dir ectory服务, 用于返回服务器中所有文件对象的引用。第二种, ACSI的一个服务映射为MMS的一组服务, 共同实现ACSI服务定义的功能。这样的一组服务可能是同一个MMS服务的多次执行, 也可能是不同的MMS服务协同工作完成一个ACSI服务的功能。例如ACSI的Get Server Directory服务映射为MMS的Get Name List服务, 由于MMS协议数据单元大小的限制, 可能需要分多次返回服务请求的结果, 每次返回对象引用的一个子集, 包含一个需要再次请求的标志, 最后一次返回结果中无此指示信息。于是客户方再次发出同一服务请求, 直到全部请求结果被返回。ACSI的Get File服务的MMS映射是一个映射到一组不同服务的例子。Get File服务映射到MMS的File Open, File Read和File Close服务, 这三个服务分别实现Get File服务的不同阶段的功能。这种情况的例子还有Set File等。
第三种情况:多个ACSI映射到一个MMS服务。多个ACSI类的服务采用同一个MMS服务实现。在这种情况下需要采用某种机制以区别MMS到底要执行哪类服务。通过在MMS服务原语中给定的一个或多个参数, 可以明确服务的操作对象、范围及要进行的操作等。例如, Server、LD、LN的目录服务就是都映射到MMS的VMD支持服务Get Name List服务。只是在Get Name List的请求服务中参数不同, 执行的服务服务也就不同, 也就得到相应得结果。
2 MMS报文分析
IEC61850规定, 除采样值、通用变电站事件及时间同步报文之外, 其它报文的传输层和网络层协议均采用TCP/IP (或OSI模型, 但TCP/IP更具实践价值) 。图2为MMS在TCP/IP+Ethernet通信模型。
在进行报文解析时, 必须按照上面所定义的层次进行层层解析, 根据各个层次的协议把每层的报文头和数据分离出来, 下面主要对MMS层报文进行一个解析。
根据MMS的协议规范, MMS PDU采用ASN.1语法描述, 它的报文格式是分层的, 从最外层开始, 层层往里嵌套, 最后嵌套至基本数据类型为止。最外层共有14类MMS PDU, 它们处于“根”的位置, 如表2所示。然表4 ACSI向MMS映射错误后在这14类PDU中选择其中的某项服务继续嵌套, 从而得到完整的MMS PDU格式。下面举例说明一下MMS PDU的详细过程。根据MMS Ethereal截取的Get Name List Request报文进行解析。解析结果如表3所示:左列为Get Name List Request的MMS PDU结构。右列根据ASN.1中得BE R编码规则, 形成的编码结果。 (如表2)
说明: (1) 此编码过程所用的各层ASN.1语法均来自MMS协议, 即文献[2]。
(2) 根据ASN.1的BER编码, 采用TLV结构进行编码, 编码结果按照T、L、V顺序排列。
(3) 编码出来的数据流采用十六进制来表示, 假设invoke ID=4434, Domain Spec if ic="KIRKLAND"。
3 通信报文监测方法
3.1 正常过程分析
该分析是根据一致性测试流程, 记录分析测试过程中得原始数据报文, 从而检验各设备标准的一致性, 包括各服务过程以及相应的报文是否符合标准。主要包括MMS一致性测试和ACSI一致性测试。
MMS一致性测试内容:MMS层的测试分析, 包括初始化过程分析、读/写过程分析、报告过程分析、日志服务过程分析、获取有名列表分析、获取有名变量列表属性分析以及各过程相关的报文解析和分析。
ACSI一致性测试内容:应用分析, 包括控制操作、定值操作、事件上送、文件服务等服务过程与MMS服务过程之间的映射分析, 以及各过程相关的报文解析的映射分析。
3.2 通信错误分析
根据记录的报文, 分析所有过程错误和报文错误。主要有以下几个方面的错误:MMS报文错误和过程错误、ACSI过程错误。
MMS报文错误包括以下几点。
报文结构错误, 报文编码错误, 报文校验错误, 规约符合性错误, 单报文不完整, 报文时序错误, 命令控制过程不完整。
ACSI过程错误包括以下几点。
主要包括ACSI想MMS映射错误。通过ACSI选取典型模型, 包括服务器类映射错误、逻辑设备类映射错误、逻辑节点类映射错误、数据类映射错误和数据集类映射错误。表4是服务器类ACSI向MMS映射错误代码列表。
3.3 异常过程分析
根据通信过程中出现的异常现象, 有针对性地分析相应时段相关设备的原始通信报文, 分析产生异常的原因。异常分析一般包括:通信延迟, 报文丢失, 请求应答失败或错误等。MMS属于中低速报文, 其传输时间是应大于100MS, 在一定时间内, 没有收到MMS报文, 可以认为丢包, 应请求重发。数据包丢包来自以下两个方面:一是网卡本身的数据接收能力;二是上层系统对数据的处理造成延迟而导致存放捕获报文图5 libcap基本流程图的数据缓冲丢包。请求应答失败, 主要来自ACSI映射失败, 以及MMS通信失败等。
3.4 监测流程 (如图3)
对采集到的原始数据报文, 经过正常过程分析, 错误分析和异常过程之后, 如果有一个出现异常, 都要提示用户此次报文通信出现问题。
4 基于嵌入式装置的分布式IEC61850MMS报文监测系统实现
分布式监测系统在20世纪80、90年代占主导地位。其核心思想是集中管理、分散控制, 即管理与控制相分离, 上位机主站用于集中监视管理功能, 若干台嵌入式采集装置下放分散到现场实现分布式测量与控制, 上位机与嵌入式采集装置之间用控制网络互连以实现相互之间的信息传递。因此, 这种分布式的测控系统体系结构有力地克服了集中式数字测控系统对控制器处理能力和可靠性要求高的缺陷。
4.1 分布式系统实现架构
由高性能嵌入式采集装置与上位机主站组成对变电站二次设备 (含各种装置) 的分布式设备监测平台, 嵌入式采集装置采用专业的嵌入式Linux操作系统, 并配备多网口和大容量数据存储器, 在libcap基础上就可以捕获IEC61850 MMS报文, 通过TCP/IP上传至上位机主站, 上位机主站实现对上传报文进行集中评价分析, 实现集中监控管理。其系统实现架构如图4所示。
4.2 技术难点分析
(1) 嵌入式Linux平台下的Libpcap应用实现。
Libpcap是UNIX/Linux平台下的网络数据包捕获函数包, 是实现各类网络监控应用的基础。Libpcap的重点是底层包捕获机制和过滤器设置方式。网络数据包常规的传输路径依次为网卡、设备驱动层、数据链路层、IP层、传输层、最后到达应用程序。
包捕获机制是在数据链路层增加一个旁路处理, 对发送和接收到的数据包做过滤/缓冲等相关处理, 最后直接传递到应用程序。包过滤机制是对所捕获到的数据包根据要求进行筛选, 把满足过滤条件的数据包传递给上层应用。其基本使用流图如图6所示。
(2) 高性能多线程流式解析服务器实现
为了将分布在不同采集位置 (同一变电站不同站控层网络位置或不同变电站站控层) 的嵌入式IEC 61850 MMS报文采集装置所采集信息进行集中汇总分析, 我们在Linux平台下实现了基于多线程并发和无阻塞网络通信技术的MMS报文流式解析服务器。其核心技术如下。
(1) 多线程并发服务器技术。
多线程并发服务器工作原理是服务器在接受客户方请求后, 立即调度一个线程去处理服务器与客户之间的数据通信, 主程序则返回继续监听端口, 等待下一客户的连接请求。多线成并发运行在同一进程下, 使用共有的自愿, 满足系统的多任务要求。在实现多线程并发服务器时, 要充分考虑到并发性/安全性等问题, 才能提高服务器和系统的效率, 发挥多任务并发的高效性。我们将每路IEC 61850 MMS报文的拼接和转换成XML格式结果的处理流程设计成线程服务程序, 通过对每路装置的不同线程处理, 达到同时解析多路IEC 61850MMS报文的目的。初步的系统实现和测试表明, 在模拟100路报文同时到达的情况下采用8G内存, 2.1GHz主频双核CP U的Linux P C服务器, 服务器的并发服务处理仅占CPU利用率的6.5%, 能够满足多路并发处理的应用要求。
(2) 非阻塞网络通信技术。
要实现高效的网络处理通信流程, 必须对通信流程进行优化, 实现异步无阻塞的通信模式。所谓非阻塞方式 (non-block) 就是进程或线程执行此函数时不必非要等待事件的发生, 一旦执行肯定返回, 以返回值的不同来反映函数的执行情况, 而进程或线程继续执行, 从而提高代码效率在Linux平台下, 使用Select函数, 就可以设计和完成非阻塞方式的网络通信程序。在我们的实现中, 所有通信线程都采用Select函数进行异步处理, 因此实现系统的高效率。
(3) MMS报文流式解析技术。
对拼接完整的一个MMS报文, 我们将其所有数据都保存在内存中的缓冲区中, 通过指针传递, 形成流式操作, 直接交给XML解析生成模块进行处理。这样, 就避免了写入磁盘或其他外存的文件读写操作, 提高了系统处理速度和效率。而对解析完毕的XML形式MMS报文, 我们则由用户选择直接缓存显示后删除或缓存后批量写入磁盘文件, 从而减少应用程序的I/O操作, 提高应用实现效率和响应速度。
4.3 应用实例
将嵌入式MMS报文采集装置接入新投运的南瑞金华110k V IEC61850唐先变站控层网络, 目前已投运超过8个月, 装置工作稳定正常, 后台系统也不断根据接收到的站控层MMS报文流实时解析出监控报文信息, 如图6所示。
5 结语
随着变电站智能化、网络化程度不断提升, 为了保证其运行的稳定性, 必须对变电站中的各个设备进行有效地监控, 这些投入到变电站中的智能设备已经经过了一致性测试, 符合IEC61850标准, 因此监控的主要目的是为了保证其互操作性是良好的。本文中主要介绍了基于嵌入式装置的分布式MMS报文监测系统, 通过采集原始数据报文, 采用报文正常过程分析、错误分析和异常过程分析等分析手段, 可以实时监控数字化变电站内部IED设备的运行状况, 同时能够及时发现运行中的问题, 有效地保证了IEC61850数字化变电站的正常运行。
摘要:随着数字化变电站不断增多, 原有的集中式IEC61850站控层MMS报文检测系统不能满足分布式应用的要求。文中分析MMS报文结构, 设计在嵌入式Linux装置中进行分布式MMS报文采集, 通过网络通信流程, 与后台服务器组成分布式监测系统。结合系统的实现, 进行了实现难点分析和总结, 并为下一步的改进完善指出了方法。
关键词:分布式系统,IEC 61850,报文监测,嵌入式系统
参考文献
[1]王林, 王倩, 刘从洪, 等.IEC61850MMS编解码库的设计与实现继电器[J], 2008, 36 (5) .
[2]ISO 9506-2-2003.Industrial automa-tion systems-Manufacturing MessageSpecification-Part 2:Protocol specification.2003
[3]IEC.IEC61850-7-2 Communicationnetworks and systems in subst ations.Geneva, Swit zer land:IEC, 2003.E.F.Mulder and M.V.Kothare“, Title ofpaper, ”in Proc.Amer.Control Conf., vol.5, Chicago, IL, June 2000, pp.3239-3 24 3.
[4]张长明.制造报文规范及其在电力监控系统数据通信中的应用[D].华北电力大学, 2004.
卫星短报文通信系统研究 篇2
卫星短报文通信系统作为地面通信系统的补充, 有广泛的需求和应用。3种典型的卫星短报文通信系统包括ORBCOMM、Argos和Aprize。
文献[1 - 4]分析了系统ORBCOMM的主要特性, 介绍了存储转发机制, 对短数据系统技术体制做了综述性介绍, 详细描述了系统组成, 系统工作原理、工作模式和工作流程。文献[5]介绍了Argos系统, 分析了系统组成和系统中通信终端平台的定位方法。文献[6]对卫星通信信道进行了分析和研究, 在该信道模型基础上, 对低轨卫星CDMA短数据移动通信系统的关键性能进行了分析。文献[7]对Globalstar系统进行了简要介绍, 描述了其系统构成。文献[8]对Iridium系统的构成、工作原理和技术进行了介绍。文献[9 - 12]分析了卫星通信的一些新技术和趋势, 介绍了不同的动态接收技术。这些已有系统用户链路频带规划效率低, 拥塞控制机制不完善, 应对大动态接收也有一定的局限性。本文针对这些问题, 提出了在这几个方面都有改善的一种卫星短报文通信系统关键技术。
1 卫星短报文通信系统技术体制
本文所涉及的系统体制主要针对用户上行信道规划、用户接入、拥塞控制和多普勒分集接收展开。
1. 1 用户上行信道规划
在已有的卫星短报文通信系统中, 用户上行的信道规划在频率上采用传统的方式, 即用户信道间设有保护间隔, 以防止多普勒频移造成的频谱漂移, 规划方式如图1所示, 这种方式下存在信道间保护间隔。
本文对用户上行的信道规划如图2所示, 在用户频带内信道间不设置保护间隔, 所有频带皆用于用户数据上行, 只在用户频带两边设置保护带。这种信道规划方式下, 利用多普勒频移进行并行分集接收, 把原本多普勒频移带来的问题转化为优势, 这种信道规划方式下的接收在后面描述。由于没有信道间保护频带, 所有用户频带都用于数据传输, 提高了频带资源的利用效率。
1. 2 接入方式
短数据业务的特点是多数情况下为突发、不连续, 传输数据量小的短包, 少数情况下有突发的数据量大的业务。为适应这种业务特征, 适宜采用2种方式接入:随机接入和预约接入。用户上行信道分为普通和专用通道2类逻辑信道, 系统根据当前运行状况动态划分2类信道。用户上行通道一般情况下作为普通信道使用, 终端通过竞争占用信道资源, 采用S-Aloha方式接入系统。由于环境等要素变化, 终端需要短时间内上传大量数据时, 为了提高数据传输的可靠性和及时性, 可以通过预约方式申请专用信道, 系统将空闲上行信道作为专用信道分配给终端, 完成数据传送后终端释放该信道, 该信道再次成为普通信道, 通过这种信道分配方式保证系统传输效率和资源利用率。
1. 3 拥塞控制
短报文通信系统主要采用S-Aloha方式实现数据传输, 在系统运行过程中可能会出现某一区域内的终端在某一段时间内集中向卫星发送数据的情况, 在这种情况下可能会引起大量数据冲突, 从而出现大量接收数据异常的情况, 为避免出现某一区域内终端在某一时间段内集中发送数据的情况, 需要采取相应的拥塞控制机制保证该区域内的终端在该时间段内分散进行数据发送, 根据拥塞控制的发起方不同, 系统中可以采取主动和被动2种拥塞控制方式。
1. 3. 1 主动拥塞控制流程
主动拥塞控制是指当终端发送数据后, 长时间没有收到网络侧发送的确认信息, 终端自动延迟下次数据发送时刻, 从而实现冲突的避让, 由于是由终端主动进行发送时刻的延迟操作, 无法实现与网络侧及其他终端的同步, 因此, 可能会出现大面积终端延迟后再次出现拥塞的现象, 直到大部分终端的发送时刻不完全一致时, 才会达到较好的拥塞控制效果, 因此, 采用主动拥塞控制的缺点是取得较好的拥塞控制效果的时间比较长, 优点是实现起来比较简单, 仅需在终端设计相应的冲突避让算法进行控制就能实现。本系统中主动拥塞控制计划采用树分协议控制算法实现。
具体过程如下:设网络中有1 ~ N编号的N个终端, 它们都能独立地监听信道和检测冲突。如果某个时刻在信道上发生了冲突, 则未参与冲突的终端将不再向信道中发送请求, 直到冲突解决。发生了冲突的终端中, 编号为1 ~ N/2的终端被推入堆栈中, 编号为N/2 ~ N的终端在下一时隙发送。而在下一时隙中可能出现3种情况:1如果仍然有冲突, 则编号在N/2 ~ 3N/4范围内的终端被推入堆栈中, 编号为3N/4 ~ N的终端在下一时隙发送。换言之, 在每轮循环中, 如果有冲突存在, 就把发生冲突的终端的一半推入堆栈, 而另一半参与下一时隙的竞争。2如果没有冲突且有数据正常发送, 则在数据发送完毕后, 将堆栈顶部的终端弹出, 在下一时隙发送数据。3如果没有冲突而且信道空闲, 则将堆栈顶部的终端弹出, 在下一时隙发送。该过程被重复执行, 直到堆栈被清空, 所有参与了冲突的终端数据都发送完毕, 这一轮的冲突才算完全解决。基本二叉树形冲突分解算法原理如图3所示。
上述描述的仅仅是树分协议的基本思想。在具体的实现过程中, 为了消除终端编号顺序、解决各个终端发送公平性的问题, 可以在发生冲突之后由每个终端各自生成一个0 ~ 1之间的随机浮点数。如果某终端上该随机数的值小于0. 5, 则该终端被推入堆栈, 否则将参与下一时隙的竞争。
1. 3. 2 被动拥塞控制流程
被动拥塞控制是指当网络侧检测到系统出现拥塞时, 由网络侧根据当前卫星的覆盖区域和该区域内地面终端的具体数量实施拥塞控制, 该控制过程比较复杂。
当发生拥塞时, 网络侧根据检测到的拥塞区域计算出卫星在该区域的过顶时间T, 并根据链路规划情况, 计算出单位时间内能够承担的最大并行发送数据的终端量N。结合该区域内覆盖的终端总量M可计算出过顶时间内在该区域能提供的数据接收最大次数为C = M/N* T, 网络侧对区域内的终端按照C次全部覆盖生成每次进行数据传输的终端规划信令, 终端根据接收到的规划信令确定自己的发送时刻, 从而避免了大量终端集中在某一时刻同时发送数据的情况。被 动拥塞控 制流程如 图4所示。
1. 4 多普勒分集接收
卫星短报文通信系统中, 用户上行链路在大多普勒频偏的情况下接收端接收到的频率将远远偏离发送端的发送频率。为了解决这种情况下的接收问题, 本文提出多通道接收方法。多通道接收是将整个工作频率划分为小的接收子带, 接收信号由A/D进入基带后首先进行通道化处理, 将信号搬移到各个子带的中心频率上, 用通道滤波器过滤出本子带的信号, 然后对其进行解调。接收端对整个频带进行了子带划分, 所以发送终端发送的信号必然落在接收端的某个子带中, 从而将其捕获, 解调过程如图5所示。使用这种多通道信道化接收的方法可以很好地解决大多普勒接收问题。
2 仿真分析
首先对系统的接入性能进行仿真。采用Matlab工具, 用户上行通道数为1 000路, 按照S-aloha方式接入, 接入概率为p, 对不同并发终端接入系统时系统的归一化吞吐率进行仿真。当系统中并发接入终端数量增大时, 大的p导致吞吐率急剧恶化, 这个概率可等效为等待下一次发送的时延。通过主动或这被动拥塞控制策略, 在不同的并发接入终端量下动态调整p使得实际接入的终端数在1 000个时, 系统吞吐率能够保持在S-aloha的归一化吞吐率的性能限0. 36处。
为了仿真多普勒分集接收的性能, 使用Matlab仿真了4路终端并发仿真, 4路信号间隔1 350 Hz, 分别处于中 心频点0 Hz, 1 350 Hz, 2 700 Hz和4 050 Hz处, 并发信号的频谱如图6所示。
经过信道化处理后, 分离出每个信道上的信号, 选取1 ~ 6的信道的信号进行展示, 对应信道信号的频谱如图7所示, 其中1、3和6信道处的信号为终端发送的信号, 能够完成正确解调。仿真结果表明, 通道化接收很好地利用了多普勒分集, 当信号偏移到其他信道时, 信号仍然能够正确接收。
3 结束语
研究了卫星短报文通信系统所涉及的技术, 包括用户上行信道规划、用户接入、拥塞控制和多普勒分集接收。用户上行信道规划改进了传统的用户信道间保留隔离带的问题, 提高了频谱利用率。在接收时采用通道化接收完成了多普勒分集接收, 仿真结果表明了设计的可行性。针对拥塞问题, 本文提出了主动和被动2种拥塞控制方法所研究的系统技术改进了已有技术的不足, 为后续卫星短报文通信系统的研究工作打下了一定的基础。
参考文献
[1]余金培, 华戌明, 李国通, 等.低轨卫星数据通信系统ORBCOMM在我国的应用[J].电信科学, 2000 (12) :42-44.
[2]MIYAMOTO Y, UCHIDA K, ORII R, et al.Three‐dimensional Underwater Shape Measurement of Tuna Longline Using Ultrasonic Positioning System and ORBCOMM Buoy[J].Fisheries Science, 2006, 72 (1) :63-68.
[3]ORBCOMM G.ORBCOMM L P.System Overview[J].A80TD0008 Rev B, Virginia, 1998 (26) :25-28.
[4]詹亚平, 华戌明.ORBCOMM商用低轨道小卫星短数据通信系统[J].电子技术, 2001, 28 (2) :24-27.
[5]梁洁雯.卫星通信中的数据采集系统[J].电信科学, 2002, 18 (9) :61-63.
[6]陈寅健.低轨卫星CDMA短数据移动通信系统设计与分析[D].上海:中国科学院上海冶金研究所博士学位论文2002:5-30.
[7]DIETRICH F, METZEN P, MONTE P.The Globalstar Cellular Satellite System[J].Antennas and Propagation, IEEE Transactions on, 1998, 46 (6) :935-942.
[8]LEMME P W, GLENISTER S M, MILLER A W.Iridium (r) Aeronautical Satellite Communications[J].Aerospace and Electronic Systems Magazine, IEEE, 1999, 14 (11) :11-16.
[9]王文革, 万千.国际移动卫星通信系统中频率补偿技术[J].无线电通信技术, 2011, 37 (1) :10-12, 33.
[10]张俊祥.卫星通信发展展望[J].无线电通信技术, 2012, 38 (4) :1-4.
[11]刘英, 路志勇, 武伟.卫星通信天线自动极化调整技术[J].无线电工程, 2012, 42 (7) :46-48.
智能变电站网络报文分析 篇3
关键词:网络报文分析,过程层,技术参数
随着智能变电站的迅速发展, 变电站站控层、间隔层以及过程层的通信网络报文已经成为变电站智能设备间信息交互和共享的主要方式。直接影响整个智能变电站的通信是智能设备和通信网络的健康状况, 可能导致电力系统重大事故的原因可能是网络报文的发送端、接收端及通信网络异常或故障, 因此需要对网络报文进行有效的监视、记录和诊断, 提前发现通信网络的薄弱环节和故障设备, 预防电力系统事故的发生。
1 智能变电站网络报文分析技术特点及构成
技术特点:无损高速记录;海量数据存储;结构灵活安全;调试过程可视化;
网络可靠性在线监视;信息综合分析;标准化数据交换接口。
网络报文分析系统构成:现阶段实现智能变电站网络报文分析功能的方式是智能变电站网络报文分析系统, 智能变电站网络报文分析系统的结构采用“1 台网络报文分析单元+N台网络报文记录单元”的构成模式。
2 智能变电站网络报文分析标准规范
(1) DL/T 553-2013 电力系统动态记录装置通用技术条件;
(2) Q/GDW 383-2009 智能变电站技术导则;
(3) Q/GDW 715-2012 智能变电站网络报文记录及分析装置技术条件;
(4) Q/GDW 733-2012 智能变电站网络报文记录及分析装置检测规范;
(5) 国家电网公司2011 年新建变电站设计补充规定。
3 智能变电站网络报文分析的作用
3.1 网络报文实时记录、监视及分析
实时分析报文, 给出预警信息并启动报文记录, 启动报文记录的条件包括:报文格式错误:SV、GOOSE、MMS等报文格式错误;报文不连续:丢帧、重复、超时等;报文不同步;数据属性变化:品质因数变化、同步标志变化等;SV采样异常:频率不稳定、双A/D不一致等;对时服务事件:时钟加入、退出、切换等。
3.2 电力系统数据实时监视及分析
实时监视电力系统数据, 如有效值、相角、频率、有功、无功、功率因数、差流、阻抗等量值及开关量状态。
实时分析以下异常:电压突变、电压越限、零序 (或负序) 电压越限、谐波电压越限、电流突变、电流越限、频率越限、开关量变位等, 并给出告警信息。
3.3 网络流量、网络报文统计、异常报警
实时监视及分析网络状态, 实时监视网络中节点的增加和删除、报文流量、帧速、通信状态等, 给出预警信息并启动报文记录。启动报文记录的条件包括:流量异常、网络风暴、节点突增、通信超时、通信中断等。
3.4 网络报文回放、过滤
当电力系统发生故障时, 通过对记录的网络原始报文进行分析, 还原电力系统一次设备故障波形以及二次设备动作行为, 便于事故后分析和快速查找故障原因。
3.5 原始报文查看
当电力系统故障发生时, 不仅能对记录的网络原始报文进行分析, 还能还原电力系统一次设备故障波形以及二次设备动作行为, 便于事故发生后进行分析和快速查找故障原因。
4 智能变电站网络报文分析技术参数
4.1 监听端口及处理能力
监听记录端口采用相互独立的数据接口控制器;过程层监听记录端口:6 个100Mbps监听接口, 端口形式:多模光纤ST, 波长1310nm;站控层监听记录端口: 2 个100Mbps监听接口, 端口形式: 电口, RJ45; 单个端口的报文最大接入能力:100Mbps;端口100Mbps流量接入能力下同时接入个数:4 个;装置长期稳定工作时的最大报文接入能力:400Mbps。
4.2 通讯端口及接入处理能力
采集装置接入端口: ≥ 4 个1Gbps接入接口, 接口形式:电口, RJ45;站控层通讯端口:≥ 2 个1Gbps/100Mbps自适应通讯接口, 接口形式:电口, RJ45;装置长期稳定工作时的最大报文分析能力:500Mbps。
4.3 数据记录
SV报文连续记录:≥ 3 天 (24 路SV, 每个SV 22 通道, 采样频率为4000Hz, 总流量约30MB/ 秒) ;
GOOSE连续记录: ≥ 15 天, 支持单独记录, 记录空间大小可根据实际情况配置;
MMS报文连续存储记录:≥ 3 天;
报文异常事件记录:≥20000条, 可配置;
记录数据的分辨率:≤1us;
数据存储格式:连续记录数据存储格式为.zip解压缩后为pcap, 异常报文及GOOSE报文单独记录格式为pcap;
连续记录报文实时压缩, 压缩比≥ 5, 存储格式为.zip;
数据记录分连续记录区和异常记录区, 循环滚动记录。
5 智能变电站网络报文分析运行及维护
网络报文记录及分析现场运行时需注意指示灯的变化, 以及出现的告警信息。指示灯一般用来指示装置的运行情况, 指示灯有变化时, 及时查看设备哪里出了问题, 不能处理及时告知厂家。
保证装置正常运行的情况下, 如有告警信息, 要分清告警的种类, 主要有以下几种:报文存在漏包、错包、重包等现象, 及时找出相关设备, 报文异常又分以下三种情况:GOOSE报文异常, 分报文序列异常和报文内容异常;采样值报文异常, 分报文序列异常和报文内容异常;MMS报文异常;网络通讯中断, 及时找出中断的通讯端口。网络流量异常, 及时检查相关交换机是否正常。
如果发生事故, 调出相关保护跳闸报文, 分析保护跳闸信号的动作过程, 并结合采样值, 综合分析整个的故障过程。
6 结束语
网络报文分析系统主要应用于基于IEC61850 通信网络的智能变电站。通过海量记录过程层SV报文及Goose报文, 有效实现网络报文的选择过滤、在线记录、网络流量统计。当网络流量异常时给出告警信号, 报文异常时分析导致报文异常的原因, 实现事故在线分析, 图像化显示报文丢失、报文异常情况, 最终实现通信网络的实时监测, 预防电流系统事故的发生, 还可以提起发现电流系统通信网络薄弱环节和故障设备, 预防电流系统事故的发生, 直接避免由于通信网络故障或一次设备、二次设备故障导致的电流系统事故造成的经济损失。
参考文献
[1]冯艳丽, 王响, 孙静.智能变电站网络报文分析关键技术分析[J].电子技术与软件工程, 2015, 10.
某型水下航行体长报文通信机制 篇4
“北斗一代”[1]是我国自主研发的一种新型、全天候、区域性的卫星导航定位系统。其是由空间卫星、地面中心控制系统和用户终端组成, 可在服务区域内任何时间、任何地点, 为目标用户提供位置信息。具有快速定位、短消息通信和精密授时3大功能。目前广泛运用于水下航行体领域。
当前“北斗一代”卫星导航系统的报文长度有一定的限制, 即可为水下航行体与北斗用户型指挥机、用户机与地面中心站之间提供每次最多120个汉字或1 680 bit的短报文通讯服务[2]。通信数据数量如果超过最大报文长度, 必须分包进行发送, 且存在丢包现象, 本文在此基础上提出一种基于“北斗一代”卫星导航系统应用于水下航行器通信的长报文可靠通信机制。该机制可有效提高通信效率。
1 水下航行体与“北斗一代”工作原理
北斗用户型指挥机主要通过“北斗一代”卫星导航系统与水下航行体传递控制指令信息、系统状态信息、航行体位置信息, 如图1所示。
定位部分:“北斗一代”为有源定位方式[3], 即水下航行体用户终端通过至少2颗导航卫星向地面控制中心发出申请定位信号, 地面控制中心主控站发出测距指令, 根据无线电信号传输的时间得到水下航行体与卫星的距离, 同时主控站数据库存有地球表面各点至地球球心的距离, 通过信号可判断出用户所在球面, 根据三球交汇定位原理, 控制中心便计算出水下航行体的位置信息, 正确引导打捞水下航行体[4,5,6]。
通信部分:“北斗一代”为短报文通信方式, 即可为水下航行体与北斗用户型指挥机、用户机与地面中心站之间提供每次最多120个汉字或1 680 bit的短报文通讯服务。流程为: (1) 短报文发送方首相将包含接收端ID号和通信内容的通信申请信号加密后通过卫星转发入站。 (2) 地面接入站接收到通信申请信号后, 经脱密和在加密后加入持续广播出站广播电文中, 经卫星广播给用户。 (3) 接收方用户机接收出站信号, 解调解密出站电文, 完成一次通信[7,8]。
2 水下航行体长报文通信协议
2.1 整体思路
目前水下航行体合段状态下各系统主要通过“北斗一代”卫星导航系统与地面保障设备之间传递各系统实时信息, 由于目前“北斗一代”主要为短报文通信方式, 当水下航行体需发送长报文时不可一次发送[4], 且存在严重的丢包问题。本文针对该问题提出一种基于北斗卫星导航系统的水下航行体长报文通信协议。
整体思路是:发送端对长报文进行压缩分解, 编号并加包头, 首包和末包分别加起始和结束标志位。处理完毕后发送端按标号顺序发送。发送端对长报文进行解压缩整合, 去包头。并对全包进行校验, 校验完毕后发送回复正确信息。若发现丢包行为, 接收方发送要求发送方启动重传机制。
2.2 长报文发送机制
一个完整的水下航行体长报文发送过程包括长报文压缩分包、加包头和校验信息、接收响应信息分析及后续响应。发送端的工作流程如图2所示。发送方需要发送长报文消息给接收方, 首先采取的策略是将长报文进行压缩, 其次将压缩包按一定规则进行分包。分别给各个分包 (编号为1~N) 添加包头并加入开始、结束标志位, 数据包格式如表1所示。
数据包格式由数据包包头、数据包分包编号、总分包数量、起始包标记、结束包标记以及航行体数据域组成。其中起始标志位TRUE为起始数据包, 结束标记位TURE为结束数据包, 否则为FALSE。
本文提出的长报文发送机制为:发送方首先将长报文进行压缩、分包、补充数据包格式。然后顺序发送完N个数据包后则进入等待接收端回复消息状态:如果收到“接收完毕”消息, 则结束本次发送;如果收到“补发数据包X”消息, 则需要发送端启动数据重传机制, 根据标号补发相应数据包。若发送端规定时间内未收到回复信息, 则发送“查询接收信息”, 若重发3次仍未收到, 则结束本次发送。
2.3 长报文接收机制
接收端的完整工作流程如图3所示, 接收端收到N或<N个数据包并对这些数据包进行拆包头。记录已收到的数据包编号、查询结束标志位。将统计信息做判断, 验证数据包完整性, 如果数据包完整, 则发送“接收完毕”消息给发送端;如果数据包个数不完整, 则发送“补发数据包X”消息。
2.4 重传机制
接收端若收到的数据包个数小于数据包总个数, 则向发送端发送“补发数据包X”消息, 此时发送方则启动消息重传机制。发送端根据“补发数据包X”消息可知本次发送存在丢包现象, 则根据读取丢包的包编号, 重新补发相应数据包, 并等待接收端回复。如果发送端接收到“补发成功”消息则结束本次补发;若未接收到该消息, 则重发相应数据包, 重发3次仍未收到则结束本次补发。重传机制如图4所示。
3 协议可靠性验证
为验证基于“北斗”卫星导航系统的长报文通信协议的可靠性, 通过“北斗”卫星导航系统向水下航行体天线接收状态下多次发送同一长报文。一种采用传统短报文通信协议, 将长报文分包顺序发送, 丢包现象严重。其次采用本文提供的长报文协议, 重传机制可有效缓解丢包现象。试验证明, 发送相同长报文, 采用了长报文通信控制协议可有效提高水下航行体通信效率。
4 结束语
基于“北斗”卫星导航系统在水下航行体领域的应用是一项庞大的系统工程, 随着水下航行体对通信长度和时间精度的要求越来越高[5], 长报文通信协议在保证其高可靠性的基础上满足时间和通信长度方面的需求, 为实现水下航行体领域的“北斗一代”卫星导航系统, 由目前“点对点”、“点对多”的通信方式发展为分布式通信方式提供技术支撑。
摘要:当前应用于水下航行体领域的“北斗一代”卫星导航系统的通信协议主要为短报文来实现“点对点”、“点对多”的通信方式, 文中在分析现状的基础上介绍了一种基于“北斗一代”卫星导航系统的长报文可靠通信机制。经验证, 该机制可有效提高水下航行体与地面保障设备的通信效率。
关键词:水下航行体,“北斗一代”卫星导航系统,通信协议,长报文
参考文献
[1]姚一飞, 王浩, 赵东.发北斗卫星导航定位系统综述[J].科技向导, 2011, 2 (8) :10-11.
[2]黎明, 时海富.基于北斗卫星的大型海洋浮标通信机制研究[J].海洋技术, 2012, 31 (1) :1-5.
[3]高明亮, 谢强.无线通信可靠性研究[J].自动化与仪器仪表, 2010 (2) :17, 21.
[4]北京神州天鸿科技有限公司.神州天鸿终端通信协议 (V2.5Release) [M].北京:北京神州天鸿科技有限公司, 2002.
[5]马立新, 陈永兵.北斗组合导航系统定位精度研究[J].海洋测绘, 2009, 29 (1) :76-78.
[6]左玲.北斗无源定位系统及其卡尔曼滤波分析[J].电子科技, 2010, 23 (12) :49-51, 54.
[7]刘永明, 张云, 袁国良.GPS/北斗-2组合定位性能的研究[J].电子设计工程, 2013, 21 (14) :121-123, 126.
智能变电站通用报文解析器设计 篇5
目前, 智能变电站正处于井喷式的发展阶段, 大量智能变电站在全国各地投运, 对电网运维人员来讲, 智能站的快速发展对其技术水平有了新的要求, 这给日常运维工作带来了一定的困难。究其原因, 是智能站与常规站中信息传输的方式发生了本质变化, 使得运维人员在测量判断时感觉无从下手。于是, 众多围绕报文的研究逐渐深入展开, 报文解析已经是智能变电站运维的必要手段。
本文首先分析了智能站与常规站的区别, 阐述了智能变电站运维存在的问题, 进而提出并设计了通用报文解析器, 并介绍了通用报文解析器在某变电站的应用情况, 为智能变电站的日常运维提供了一种有效的测量手段。
智能变电站中的数字信息
典型智能变电站为“三层两网”结构, 如图1所示。与常规站相比, 部分电缆被光缆所替代, 站内合并单元、智能终端至智能化保测装置无论是点对点的连接方式还是组网的方式, 均传输的是基于IEC61850的GOOSE、SV报文, 站控层传输的是基于IEC61850的MMS报文, 而站间远动装置至调度主站通常采用的是IEC60870-5-104规约报文。
常规变电站中, 一次设备与保护、测控装置用电缆联系, 可以用万用表直接测量电量来判断传输信息。智能变电站中在检查遥信、遥测量的传输时, 不能像常规站中用万用表进行测量, 需要对设备间传输的各种规约报文进行抓取、解析, 从而了解设备间的通讯内容, 掌握设备的运行状态。
通用报文解析器的设计
硬件设计
为适应变电站二次设备运行环境, 将通用报文解析器按照6U标准机箱尺寸设计, 规格为482.6*265*230mm。将仪器硬件系统分为主板模块、电源模块、接口模块、告警指示模块和人机交互模块几个部分, 同时考虑功能性及经济性, 对各模块进行选择, 如图2所示。仪器采用工业级主板, INTEL C1037U双核1.8G CPU, 32G SSD硬盘, 10点触摸显示屏, 14寸, 分辨率1600*900, 确保仪器稳定、快速运行。考虑变电站内随时可取到电源, 采用模块化开关电源, 220V交流市电输入。考虑到仪器通用性, 接口选择USB口、光口及以太网口, 以适应不同报文抓取需要。仪器告警指示采用灯光告警指示, 经济直观。人机交互单元采用彩色触摸屏, 节省键盘、鼠标等空间, 增强显示效果。
其中USB口、以太网口均为标准接口, 光口种类较多, 包括ST口、FC口、SC口等等, 考虑到变电站现场二次智能化设备中采用ST口较多, 此处光纤接口选用ST口。
软件设计
通用报文解析器的软件设计思想是通过读取智能二次设备的工程模型CID文件, 获得相应间隔设备工程定义信息, 抓取基于IEC61850的GOOSE/SV报文, MMS报文, 以及IEC60870-5-104报文, 结合CID文件, 直观显示相应报文释义, 方便运维人员阅读。
IEC61850标准是电力系统自动化领域唯一的全球通用标准。它通过对设备的一系列规范化, 使其形成一个规范的输出, 实现系统的无缝连接。
软件系统层次结构如图3所示, 此处利用Lib IEC61850开源库进行软件开发, 采用开源开发软件的主要优势是:降低风险, 拥有源代码可以使用户能够控制软件质量, 开放源码给用户极大自由, 用户能够按照自己的业务需求定制软件。lib IEC61850提供了服务器和客户端库, 以win CE为软件系统平台, 实现Sockets、Threads、Time、Ethernet硬件/平台抽象层 (HAL) ;在HAL上提供MMS服务栈和IEC61850数据模型;然后实现IEC61850服务层 (报告、控制、存取……) ;在IEC61850服务层上提供统一的IEC61850客户端API;利用客户端API编写MMS报文分析模块和GOOSE、SV报文分析模块;最后结合WIN32 API实现分析报告的可视化输出。
104规约是厂站与配网主站进行通讯的规约, 以以太网为载体, 服务模式是平衡传输。104规约是101规约的网络化访问, 目前变电站厂站与主站间的通讯常采用104规约, 至于104规约的解析, 目前技术已十分成熟, 此处不做赘述。
通用报文解析器的应用
智能变电站通用报文解析器在110k V某变电站进行了现场测试, 完全具备智能变电站站内、站间二次报文的通用解析功能, 且操作简单, 使用方便。
以国电南自PSR662U测控装置为例, 我们通过光口抓取GOOSE/SV报文, 通过网口抓取MMS报文, 再以国电南自PSX610G远动装置为例, 通过以太网口抓取104报文, 图4是各报文的解析结果。
在110k V某新建变电站投运前调试过程中, 发现一110k V线路间隔遥测值显示不正确, 经检查, 合并单元、测控装置虚端子均连接正确, 利用通用报文解析器从合并单元至测控装置再至站控层逐一排查, 最终定位故障点为测控装置, 其模型文件有误, 重新下载新版模型文件后, 故障排除, 有效提高故障排查效率。
结束语
报文监测 篇6
在信息安全应用领域中,网络安全应用软件从底层的网卡硬件和操作系统的协议栈收取报文,网卡和协议栈软件负责对网络数据包进行收发和处理。对网络数据的传输工作消耗了大量的CPU计算资源。随着万兆带宽时代的到来,一味通过提高服务器CPU的工作频率、扩充服务器内存等方法来提升服务器对网络数据包的处理速度,将会面临功耗、成本、机房散热等一系列瓶颈。更重要的是,服务器CPU对网络数据的处理能力并非随CPU速度的增长而线性增长。如果CPU的很多开销是进行响应中断、数据拷贝、校验、对网络数据包的地址进行过滤等比较简单但费时的I/O类操作,其能够为应用层处理软件提供的计算能力将受到很大影响,从而影响应用层处理软件的速度与性能。
通过取消UC(Un-cacheable)模式、采用零拷贝、数据预取等方式,可在一定程度上提高网络数据处理能力,但其对上层CPU负载卸载有限。现有部分NIC可提供校验和计算并减少CPU约10%的负载,但是对于64字节小包来说,使用NIC卸载校验和运算对于降低CPU使用率并无多大帮助,这是因为校验和运算是基于字节的运算,因此卸载校验和对于大数据报文比较有效而对64字节小包效果很小。利用硬件处理的高速性以及可并行处理的特性,可将比较简单但费时的I/O类操作由智能网卡来完成,从而有效降低CPU工作负载并提高网络数据报文的捕获能力,特别是对密集小报文的处理能力。现有的高速FPGA具有丰富的逻辑运算资源,非常适合处理高速的网络数据报文,从而配合服务器应用层处理软件提供更高的网络数据报文捕获与处理能力。
本文介绍的一种智能网卡实现将报文分析和分类过滤工作完全下移至智能网卡中,由智能网卡上的高速FPGA实现硬件的报文分类,把上层不需要的流量直接过滤调,把上层需要的流量打上协议标签提交给服务器的应用层数据处理软件处理,由应用层数据处理软件对智能网卡获取的网络数据进行应用层数据的解析。
智能网卡通过PCI-E接口与服务器进行通信与管理,并通过加载配置文件和调用API接口的方式,实现IP、端口以及协议规则的动态更新。由此大大提高服务器网络报文的处理能力,减轻上层CPU的负载。
文章共分为四个部分:第一部分分析了智能网卡的总体架构;第二部分介绍了关键技术;第三部分介绍了智能网卡的测试结果及分析;第四部分对全文做出总结。
2 智能网卡体系结构
与普通网卡相比,智能网卡增加了报文的协议分析和根据用户配置规则对报文分类的功能,这部分处理逻辑在FPGA中用硬件实现,在板载RAM中存储过滤规则和缓冲报文,并基于零拷贝驱动把过滤后的报文传给上层应用程序。上层系统管理员可基于配置管理程序分析、建立、修改规则配置文件,通过驱动提供的接口实现FPGA中过滤规则的实时更新和网卡状态监控。智能网卡的逻辑结构如图1所示。
在FPGA芯片上,分为GIGABIT MAC模块、规则设置模块、规则查找模块、DDR3 SDRAM控制器、QDR SRAM控制器、PCI-E接口等六大部分。千兆以太网控制模块主要功能是数据流的反压、MAC侧数据MIB信息的监控、报文的CRC校验、包长度设置、将接收到的链路层数据的前导码和CRC去掉,给后续模块,将发送的报文加上前导码和CRC发送出去,检测报文是否为IP报文,根据软件的设置开启VLAN工作模式并把五元组信息提取出来给后续模块。
规则查找与设置模块其主要功能为根据应用软件的配置,更新硬件中的规则表。并根据接收到报文的五元组信息在规则表中查找,如果找到,则根据规则指定的动作丢弃报文或上传报文至CPU。PCI-E接口模块主要实现上传报文到CPU、下载规则到FPGA、配置FPGA内部寄存器、监控FPGA内部工作状态、根据EEPROM中的内容做PCI-E的基本配置。DDR3 SDRAM控制器和QDR SRAM控制器分别实现DDR3、QDR总线仲裁机制及配置控制。
3 关键技术实现
3.1 报文处理
FPGA内部的报文处理过程有两个大的执行模块,报文的接收模块和五元组过滤模块,模块间的接口是一个报文索引FIFO队列。先入先出报文索引缓冲队列是FPGA内不同功能模块间的主要接口,一个模块处理完报文后,把报文索引放入另一个模块的输入队列,由另一个模块从队列中取出报文索引,作进一步处理。
报文索引缓冲队列中保存报文在DDR3中的缓冲区索引,同时也是报头信息(包括五元组、Payload偏移等)在BRAM中的存储区索引。系统初始化时,所有的缓冲区空闲可用,全部缓冲区的索引都放在全局可用队列中。当接收到报文时,接收模块从全局可用缓冲区队列获得一个空闲缓冲区索引,把报文存入缓冲区后,把缓冲区索引送入报文过滤的输入队列。
报文过滤模块处理完缓冲区内的报文后把报文缓冲区索引再放入全局可用缓冲队列。报文上传和丢弃也分别有一个队列,作为命中动作执行模块的输入队列。报文接收模块分为两个子模块:报文缓冲模块和链路层过滤模块。负责把MAC来的报文在片内缓冲,如果不是IP报文,则丢弃,如果是IP报文则缓冲到DDR3。当报文在片内缓冲时,报头信息提取模块负责把报头中的五元组信息提取出来,存入BRAM中。
报文过滤模块包括几种。
(1)并发流匹配模块
负责根据存在BRAM中的报文的五元组,到DDR3中的并发流hash表中寻找该报文对应的流,如果找到,则根据该流的命中动作,把报文索引放入丢弃或上传队列。如果找不到,则把该报文交给规则匹配模块进行五元组规则的匹配。
(2)规则匹配模块
当一个报文是一个流中的第一个报文时,在并发流hash表中没有该流的表项,因此并发流匹配模块不能决定对该报文的动作,这时需要规则匹配模块负责查找五元组规则表,(也是一个hash表),把报文五元组和查找到的规则表项比较,不管是否命中规则,规则过滤模块都会通知规则控制模块把该报文的五元组和对应动作写入并发流表,(可认为没有命中五元组规则的报文命中了默认的上传规则)。并把报文索引放入丢弃或上传队列。
(3)规则和并发流控制模块
当一个新的流被规则匹配模块发现后,把该流的五元组写入并发流表。另外,每条规则有一个生存期,保存在一个规则生存期数组中,(如果规则的生存期无限长,就用0表示),规则控制模块负责每隔一秒轮询一遍规则的生存期数组,把生存期减少,对生存期从1降到0的规则,把有效标志位置为无效。同样,对并发流中的每一个流,该模块也处理其超时。
(4)命中动作执行模块
当一个报文在并发流表中匹配上相应的五元组后,根据该流应该采取的动作,报文的索引会进入丢弃或上传队列,同样,一个报文在规则表中命中了某条规则后,也会进入丢弃或上传队列。动作执行模块的作用就是从丢弃和上传队列中获取要处理的报文索引,执行相应的动作。上述功能模块和报文流经各模块的情况如图2所示。
3.2 五元组规则匹配算法
智能网卡支持多达5万条五元组规则过滤,每一个规则通过hash运算进入hash表,每一个报文通过hash运算查找hash表中的规则,从而规则数增加不会引起规则读取时QDR SRAM压力的增加,可扩展性较好。这里需要解决的是五元组掩码的问题,方法如下:A)把规则加上每个元素(IP、协议、端口)的掩码标志,构成固定的规则;B)把规则存入一个Hash表中;C)对收到的每个报文的五元组信息,也加上每个元素的掩码规则,构成(32-1)个五元组待匹配项;D)每个待匹配项通过Hash表查找规则,进行匹配。上述过程如图3所示。
下面结合上图举例说明规则匹配过程。假设规格式为(掩码)(五元组)(其它),掩码表示五元组的哪一元素有效,五元组为源地址ip、目的地址IP、协议、源地址端口、目的地址端口,其它信息包括规则编号和命中动作等,这里省略。配置文件中有两条规则,第一条规则规定从10.0.0.1发出的报文,第二条规则规定发送到10.0.0.1的报文,两条规则经过hash运算写入hash表的m和n位置。假设一个从10.0.0.1到10.0.0.2的ICMP(协议号为0)报文,报文的五元组(实际是三元组)首先要经过一个“带掩码五元组”产生器,这里要把五元组配上不同的掩码产生出多个(三元组7个,五元组31个)与规则相同格式的结构。在这里产生的是:(10000)(10.0.0.1,0,0,0,0)等。每一个带掩码五元组经过hash运算得到对应的规则在hash表中的位置,取出规则进行比较。比如本例中掩码在第一位的五元组经过hash运算也会得到m,因为它实际上与第一条规则相同。但是掩码在第二位的五元组经过hash运算不能在hash表中得到匹配的规则。上面的掩码五元组产生器和比较器有多个并行以保证报文处理速率。
4 性能评价
为测试智能网卡的性能,我们采用Ixia网络测试仪表和曙光网络流量审计软件,对智能网卡进行了系统资源占用率、吞吐率、帧丢失率测试。测试主机采用曙光I610服务器(CPU:Intel Xeon 5500、4G内存、OS:Linux2.6.18)。智能网卡和网络测试仪采用光纤直接相连。
在加载100000条五元组过滤规则情况下上层系统CPU资源占用率和内存占用率均为0.00%。因智能网卡对网络数据包的处理不需要上层CPU参与,存储资源也采用板上存储资源,故上层CPU占有率和内存占用率均为0.00%。普通libpcab千兆网卡因其存在大量的用户态和内核态数据拷贝导致上层CPU负载非常高。基于零拷贝驱动的千兆网卡虽没有用户态和内核态数据拷贝导致的上层CPU开销,但在海量数据包到达时,大量的中断和频繁的进程切换同样导致较大的上层CPU负载。
在内存消耗方面,零拷贝网卡需在用户空间开辟固定大小的数据缓冲区,其内存占用率固定。智能网卡和基于libpcab千兆网卡及基于零拷贝千兆网卡100000条五元组规则过滤系统资源占用率测试结果对比如图4所示。
吞吐量测试时在发送端指定发送速度,在接收端上计算收到的帧的速度。吞吐量是接收器收到的好帧数量/时间,测试通过改变帧长度,重复以上测试得到不同速率下的测试结果。测试中,采用了100000条五元组过滤规则,线速发包来计算不同包长度下的吞吐量,测试结果如图5所示,可以看出,智能网卡因采用板级FPGA逻辑,可充分利用硬件的并行性,与基于libpcab千兆网卡及基于零拷贝千兆网卡吞吐量相比,在64字节小包下可获得近30倍的加速比。
5 结束语
基于FPGA的智能网卡可以在硬件中实现报文的分类和过滤,有效卸载应用软件进行底层网络报文处理的开销,在高速网络上的网络安全应用软件,如果基于智能网卡开发报文捕获和数据采集功能,会大大提升系统的整体性能。
参考文献
[1]田志宏,方滨兴,云晓春等.RTLinux下基于半轮询驱动的用户级报文传输机制[J].软件学报,2004,15(6):834-841.
[2]杨武,方滨兴等.基于Linux系统的报文捕获技术研究[J].计算机工程与应用,2003,26:28-30.
报文监测 篇7
在解决网络拥塞问题上,传统的基于TCP/IP协议的拥塞控制算法已无法有效、及时的解决当前的网络拥塞问题,而基于主动队列的拥塞控制算法是当前研究解决网络拥塞问题的主要方向之一。通过设置队列可以吸收、暂存网络中暂时无法处理的数据包,从而起到网络拥塞调控的作用。较大的队列能够暂存较多的突发数据包、减少丢包率、提高网络的吞吐量,但是同样会增大数据包的排队延时。相反,如果队列的容量太小,则无法解决拥塞问题。有效的队列管理算法在缓解网络拥塞问题上具有重要的作用。RED(Random early Discard)随机早丢弃算法作为当前最流行的主动拥塞控制算法在解决网络拥塞问题上已经发挥了重要的作用,然而该算法自身的局限使得其并不能及时有效地解决网络中出现的拥塞问题,算法具有相对滞后性,且算法对参数的设置非常敏感。现有的一些主动队列拥塞控制算法大多是RED算法的衍生,实现的基础仍然是队列长度或平均队列长度。因此,这些算法在提高网络整体性能上具有局限性。
时延是反映网络性能的一个重要指标。数据报文由源发送端到达目的接收端的过程中,数据报文所经历的延时一般包括传输时延、传播时延、处理时延和排队时延。对于长度相同的数据报文通过同一条源端到目的端的路径来说,传输时延、传播时延和处理时延是固定的,这三部分又称为固定时延。由于网络流具有突发性,每个数据报文的排队时延随着网络的状况的变化而变化,因此,排队时延又称为变化时延。
本文将重点考虑往返延时(Round-Trip Time,RTT)中的ACK传输时延对网络性能的影响。往返时延是由源、目端节点间的单向时延、目的节点间的处理时延和目、源端节点间的单向时延(ACK传输时延)组成的。往返时延对于设置重传超时时间、源发送端的发送窗口的大小具有重要的实际意义。本文在原有拥塞控制算法的基础上,将ACK报文传输延迟引入到拥塞控制系统中,仿真实验表明:ACK传输延时的大小在很大程度上影响着网络的吞吐量、数据包传输延迟等。
1 RED算法
RED算法是由Van Jacobson和Sally Floyed在1993年首次提出来的,算法设计目的是减小包丢失率和排队延迟,避免全局源同步和获得较高的链路利用率。其基本工作原理是在每个路由上监视自己的队列长度,当它检测到拥塞即将发生时,就按照一定概率选择一个即将进入缓冲队列的数据包将其丢弃,工作原理如图1所示,S为发送端,D为接收端,R1、R为路由节点。
RED是采用加权的动态平均值来计算平均队列的长度(AvgLen)。计算如下:Lenavg=(1-Weight)×Lenavg+Weigh×SampleLen
其中:0
在RED队列中存在两个用于触发某种特定活动的阀值:Thresholdmin和Thresholdmax。
当Lenavg
当Thresholdmin<=Lenavg
当Lenavg>=Thresholdmax时,将到达的数据包或分组全部丢弃。
RED算法能够在一定程度上减小了数据包的队列排队延时和丢包率,但该算法不是明确的将链路拥塞通知信息发送给发送端,而是通过设置标志位或丢弃一个数据包隐式的通知发送端链路已发生拥塞,源发送端根据目的接收端发送的反馈信息来调整发送窗口大小,调整数据发送速率,从而实现拥塞控制。因此,在与源发送端协作上不具有协调性。这种不协调性主要体现在:当节点发生拥塞时,发送端并没有及时的接收到拥塞信息,致使丢包。
2 ACK数据报文传输状态引入
由于发送端与接收端之间的链路具有非对称性,因此,往返延时(RTT)的值随着链路的状态的变化而变化。RTT值的变化取决于以下两个因素:(1)数据报文从发送端到接收端的传送过程中的存储转发排队延时的变化。排队延时的大小取决于数据报文所在链路的拥塞程度。(2)数据报文确认信息报文(ACK)从接收端到发送端传输过程中的存储转发排队延时变化以及丢包等因素所造成的延时变化。
传统的队列拥塞控制的研究仅仅考虑发送端到接收端之间的单向瓶颈链路的拥塞状态,而并没有考虑接收端到发送端之间链路的拥塞状态,即:没有考虑ACK数据报文的延时或丢失对系统性能的影响。
本文将在以下四种情况下,分别研究RTT值对拥塞控制算法在提高网络性能方面的影响,重点研究ACK数据报文传输状态对网络性能的影响。
情况一、发送端到接收端的单向链路上不会出现瓶颈链路,返回链路上没有竞争数据流,而且反向链路上不会发生数据报文拥塞状态。
情况二、发送端到接收端的单向链路上不会出现瓶颈链路,返回链路上有竞争数据流,而且反向链路上不会发生数据报文拥塞状态或ACK数据报文丢失。
情况三、发送端到接收端的单向链路上会出现瓶颈链路,但是反向链路上没有竞争数据流或者不会出现ACK数据报文丢失。
情况四、发送端与接收端之间的往返链路上都会出现瓶颈链路,而且都会出现链路拥塞状态或数据报文丢失。
3 仿真实验及结果
仿真实验采用NS-2.34软件平台,链路环境设置如图2所示。图中的S表示源端,D代表目的端。发送的数据流包括基于TCP协议的数据流和基于UDP协议的数据流;两端与路由节点之间的链路带宽设置为2Mbs,传输延时为10ms;两个路由节点之间的链路的带宽和传输延时随着实验目的的不同将会发生变化。
在节点R1处采集基于TCP协议的数据报文的传输信息,所采集的信息根据返回链路上是否具有背景流,将分为两类:一类是在返回链路(R→R1)上没有背景流,以S开头表示此类,如:“Sdelay”等;另一类是返回链路上具有背景流,以D开头表示此类,如:“Ddelay”等。
3.1 基于情况一与情况二的仿真与数据分析
分别分析在这两种情况下的数据报文的传输延时和吞吐量的关系,分析图如图3、图4所示。通过图3可以看出:在通信两端之间的返回链路上不会出现链路拥塞状况时,无论返回链路上是否具有竞争流,数据报文的传输延时的变化主要取决于源端到目的端之间的链路上的拥塞程度,而与返回链路上是否具有竞争流关系很小。同理,此时系统的数据报文的吞吐量大小的变化也主要取决于源端到目的端之间的链路上的拥塞程度,而与返回链路上是否具有竞争流关系很小。
3.2 基于情况三和情况四的仿真与数据分析
在每种情况下,分别采集数据并分析相应的数据报文传输延时以及吞吐量的大小情况,分析结果如图5、图6所示。通过图可以看出,当返回链路上出现拥塞状况或ACK数据包丢失时,数据报文的传输延时将会随之增大,与此同时,系统的吞吐量也明显的降低。由此可以看出ACK数据报文的传输延时会明显的影响应用数据包的传输延时和系统吞吐量的大小。
4 总结
【报文监测】推荐阅读:
报文通信06-13
异构数据报文11-07
can通讯报文09-09
退汇报文引出的案例07-03
状态监测(在线监测)08-29
生物监测与环境监测10-30
3工区施工监测监测点保护管理办法07-11
播种监测07-14
感染监测07-15
监测手段07-17