本发明公开了一种基于uCos‐II操作系统和lwIP协议栈的IEEE‐1588主站以及应用于电力系统的支持IEEE‐1588协议的主时钟（IEEE‐1588主站）的实现方法。该方法是在一个低成本的硬件平台上，借助uCos‐II操作系统和TCP/IP的协议栈，对以太网数据进行了分类处理，实现了在同一个以太网端口提供基于二层和三层报文交换的IEEE‐1588的主站功能。另外，通过使用不同的操作系统进程来处理E2E和P2P对时，实现了两种对时模式在同一端口上的共存。
技术领域
[0001] 本发明属于电力系统电力电子与继电保护领域，具体涉及一种应用于电力系统的支持IEEE - 1588协议的主时钟(IEEE - 1588主站)的实现方案，该方案基于uCos-II操作系统和lwIP协议栈。
背景技术
[0002] IEEE - 1588对时技术是一种基于乒乓对时原理的精确时钟同步技术，它采用短帧传输，算法简单，对计算性能和网络带宽的要求都较低，适用于支持多播消息的分布式网络通信系统。
[0003]目前，随着电力系统中的智能电网建设的逐步深入，二次设备侧的数字化、网络化的特点愈发明显，且对对时精度也提出较高的要求。IEEE - 1588因其天然具备的网络化特性以及较高的对时精度，在当前的智能电网建设中受到了广泛的关注，并应用到智能电网的建设中来。
[0004] IEEE - 1588对时技术是一种主从式的时间同步技术,各对时终端作为时间同步系统中的从节点(从站)，通过IEEE - 1588协议，与时间同步系统中支持IEEE - 1588协议的主时钟(主站)保持时间同步，进而保证各对时终端间的时间同步。
[0005] 目前，IEEE- 1588对时技术在智能电网中的应用目前还主要集中在过程层，由于过程层的数据基于二层报文交换，因而当前应用于电力系统的IEEE -1588的主时钟大多仅支持IEEE802.3的帧格式，支持IPv4帧格式的主时钟较少。
[0006] 目前,支持IPv4帧格式的主时钟,一方面由于其运行Linux、VxWorks之类的操作系统，需要使用高性能CPU及以之对应的DRAM和外部FLASH的支持。硬件成本高；另一方面，其在工作时对于IPv4和IEEE802.3帧格式的支持是互斥的，对于E2E和P2P的支持也是互斥的，不利于复杂环境下的应用。基于以上两方面因素，本中提出了一种基于低成本的硬件平台，且能同时支持多种帧格式和多种对时机制的IEEE - 1588主站的实现方法。
发明内容
[0007] 为解决现有的IEEE - 1588主站实现中存在的硬件成本高、功能支持单一等问题，本申请公开了一种基于uCos操作系统和lwIP协议栈的IEEE - 1588主站的实现方法，以及基于该主站的报文处理方法。
[0008] 本申请具体采用以下技术方案。
[0009] 一种基于uCos操作系统和lwIP协议栈的IEEE -1588主站，所述主站主要包括供电单元、逻辑处理单元、以太网接口单元、频率源单元，其特征在于:
[0010] 所述逻辑处理单元包括一 CPU，在所述CPU上移植uCos-II操作系统，并在该操作系统上使用lwIP协议栈，所述逻辑处理单元负责处理以太网数据的收发以及IEEE - 1588协议栈逻辑的实现；
[0011] 所述以太网接口单元包括一 SC接口光模块和一片IEEE - 1588专用PHY芯片，所述SC接口光模块和IEEE -1588专用PHY芯片相连，所述以太网接口单元中的PHY芯片通过MII接口连接至逻辑处理单元中的CPU以协助所述逻辑处理单元提供以太网数据的收发功能，在PHY芯片的IO脚上通过背板接入一路IRIG - B码信号作为基准源输入，所述PHY芯片捕获并记录输入的IRIG -B码，把IRIG -B码信号的高低电平的跳变方向、跳变时的时标信息封装成IEEE802.3格式的PSF (PHY Status Frame)报文，并为CPU提供分辨率为8ns的 IEEE - 1588 时标；
[0012] 所述频率源单元主要是负责给CPU和PHY提供时钟信号；
[0013] 所述供电单元负责为主站提供所需的电源。
[0014] 本申请还进一步公开了一种基于uCos操作系统和lwIP协议栈的IEEE - 1588主站的报文处理方法，方案如下:
[0015] 一种基于uCos操作系统和lwIP协议栈的IEEE -1588主站的报文处理方法，其特征在于，所述方法包括以下步骤:
[0016] (I)所述CPU接收以太网数据，在所述uCos-1I操作系统的基础上，所述CPU对以太网接收数据进行分类处理，把不同帧格式的报文分别放在操作系统的不同进程中处理，包括把封装在IEEE802.3和IPv4帧里的IEEE -1588报文放在不同的进程中处理；操作系统中负责以太网数据接收的进程，会把IEEE802.3、IPv4帧格式的报文以及PSF报文数据以消息邮箱的方式分发到不同的指定进程中，以便进行下一步的处理；
[0017] (2)在步骤(I)的基础上，所述CPU对于接收到的内含IRIG-B码的跳变沿时刻信息的PSF报文进行解析处理，所述CPU根据所述的跳变沿时刻解析出IRIG -B内信息，并计算出所解析出的信息与基准源间的误差；
[0018] (3)在步骤(I)的基础上，所述CPU对于接收的IEEE802.3帧格式的报文会再次进行分类处理，丢弃其中的非IEEE - 1588报文，并把剩余的IEEE - 1588报文分为:E2E查询报文(DelayReq 报文)、P2P 相关报文(PdelayReq、PdelayResp 和 PdelayResp Followup 报文)和BMC (Best Master Clock)相关报文(Announce报文),根据报文的类型,再次分发到不同的指定进程中去处理；
[0019] (4)在步骤(3)的基础上，对于IEEE802.3帧格式的IEEE - 1588报文中的同步报文(Sync和Followup报文)、P2P查询报文(PdelayReq报文)和Announce报文的发送,都分别有一个对应的进程来控制，进程间是相互独立的，有其自己固定的周期；
[0020] (5)在步骤(I)的基础上，对于接收的IPv4帧格式的报文会再次进行分类处理，把其中的非IEEE - 1588报文分给lwIP协议栈进程处理，其余的分给相应的IEEE - 1588处理进程;
[0021] (6)在步骤(5)的基础上，对于接收的IPv4帧格式的IEEE -1588报文会再次进行分类处理，将其分为:E2E查询报文(DelayReq报文)、P2P相关报文(PdelayReq、PdelayResp和PdelayResp Followup报文)和BMC相关报文(Announce报文),根据报文的类型,再次分发到不同的指定进程中去处理；
[0022] (7)在步骤(6)的基础上，对于IPv4帧格式的同步报文、P2P查询报文(PdelayReq报文)和Announce报文的发送，都分别有一个对应的进程来控制，进程间是相互独立的，有其自己固定的周期。
[0023] 本申请具有以下技术效果:
[0024] (I)基于一个低成本的硬件平台，实现了支持IEEE802.3、IPv4帧格式的IEEE - 1588 主站。
[0025] (2)实现了在同一个以太网端口上，同时提供基于二层和三层网络服务的IEEE - 1588主站功能。
[0026] (3 )实现了在同一个以太网端口上，同时提供对E2E和P2P延时测量机制的支持。
具体实施方式
[0029] 下面结合说明书附图对本发明的技术方案作进一步详细说明。
[0030] 本发明中，IEEE-1588主站的结构原理框图如附图中的图1所示，其结构大体上可分为供电单元、逻辑处理单元、以太网接口单元、频率源单元等。所述逻辑处理单元包括一CPU，在所述CPU上移植uCos-II的操作系统，并在该操作系统上使用lwIP的协议栈，所述逻辑处理单元设置有逻辑处理单元，通过逻辑处理单元的以太网接口接收以太网数据，所述逻辑处理单元负责处理以太网数据的收发处理以及IEEE -1588协议栈逻辑的实现；所述以太网接口单元包括一 SC接口光模块和一片IEEE -1588专用PHY芯片，所述SC接口光模块和IEEE -1588专用PHY芯片相连，所述以太网单元通过MII接口连接至逻辑处理单元中的CPU以协助所述逻辑处理单元提供以太网数据的收发功能，在PHY芯片的IO脚上通过背板接入一路IRIG - B码信号作为基准源输入，所述PHY芯片捕获并记录输入的IRIG - B码，把其沿翻转极性、时标信息封装成IEEE802.3格式的PSF报文，并为CPU提供分辨率为8ns的IEEE - 1588时标；所述频率源单元主要是负责给CPU和PHY提供时钟信号；所述供电单元负责为主站提供所需的电源。
[0031] 主站的供电单元主要包括一片国半公司LM2812 - 3.3的DC - DC芯片及相关外围器件，其负责给其它单元提供工作时所需的3.3V电源输出。
[0032] 主站的逻辑处理单元主要包括一片Freescale的Kinetis K60系列CPU,其采用高达100MHz的ARM Corte - M4内核，内部集成FLASH、SRAM以及PLL，并提供了以太网接口。为了满足CPU运行时所需的内存开销，还在CPU的外部总线上扩展了一片型号为CY62157的16*512KB的SRAM。该CPU主要负责处理以太网数据的收发处理以及IEEE -1588协议栈逻辑的实现，并为此搭建了 uCos-II的操作系统，具体版本是V2.84，最多可允许创造254个用户进程。在操作系统上使用了 lwIP协议栈，具体版本为V1.3.0。该单元对于以太网数据收发的处理，将在后续结合附图中的图2进行详细介绍。
[0033] 主站的以太网接口单元主要由一个Avago公司AFBR5803AZ (SC 口)的光模块和一片国半公司DP83640的IEEE - 1588专用PHY芯片组成。该单元主要通过MII接口协助(PU提供以太网数据的收发功能，并由DP83640芯片为CPU提供分辨率为8ns的IEEE-1588时标。另外，该单元还负责捕获输入的IRIG - B码，并把其沿翻转极性、时标等信息封装成IEEE802.3格式的PSF报文，上送给CPU做后续处理。所述PSF报文的源MAC地址会在初始化 DP83640 时被配置为 "08: 00: 17: 0B: 6B: 0F"。
[0034] 主站的频率源单元主要是负责给CPU和PHY提供时钟信号，在此为了保证输出能满足精度要求，使用了一个频率稳定度为±200ppb的恒温晶振，频点为25Mhz，经过一个时钟分发芯片CY2305的时钟分配芯片后供给CPU和PHY芯片使用。
[0035] 本发明中，对于IEEE - 1588主站功能的程序设计基于uCos-II操作系统和lwIP协议栈，其对以太网数据报文(尤其是IEEE - 1588协议相关的报文)采用分类、分层的处理方法。每一类、每一层的处理对应于操作系统中特定的一个进程，进程间通过操作系统提供的信号量、消息邮箱和信号量集来实现数据交换和进程调度。
[0036] 通过对DP83640的配置，可以让DP83640把IEEE - 1588报文的接收时标插入IEEE -1588报文中的保留字段，以便在进行报文处理时可以直接获取。对于IEEE -1588报文的发送时标的获取，需要CPU通过ΜΠΜ总线去访问DP83640的寄存器来获取。
[0037] 如附图中图2所示，本申请还公开了一种基于uCos操作系统和lwIP协议栈的IEEE - 1588主站的报文处理方法，所述方法的处理步骤具体如下:
[0038] (I)以太网数据分类处理:
[0039] 这部分的处理，与图2中序号为I的进程相对应。
[0040] 在所述过程中，CPU查询其内部以太网MAC的接收描述符，以判断是否接收完整的报文，并对报文的类型、长度及源、目的MAC地址进行识别。并根据报文的帧类型及源MAC地址进行分类，判断所述报文是IEEE802.3的报文、IPv4的报文、PSF报文或不相关报文。对于不相关报文，所述CPU会直接丢弃，不予处理。
[0041] CPU进行报文分类的依据及步骤如下:
[0042] 1.所述CPU识别报文的目的地址，判断所述报文是单播、多播还是广播报文。若所述单播报文的目的地址与所述CPU以太网MAC地址不匹配，则会被判定为不相关报文后丢弃。
[0043] 2.在步骤I的基础上，所述CPU识别报文的帧类型。若所述帧类型是0x0800，则所述CPU判定所述报文是IPv4的报文，并将所述报文封装成一个uCos-II的消息邮箱发送给图2中的序号为2的进程做后续处理。
[0044] 3.在步骤2的基础上，所述CPU继续识别报文的帧类型。若所述帧类型非0x88F7,则会被判定为不相关报文后丢弃；否则所述报文可能是PSF或IEEE802.3封装的IEEE - 1588报文，需要进一步判断。
[0045] 4.在步骤3的基础上，所述CPU判断报文的源MAC地址是否为"08:00:17:0B:6B:0F":
[0046] a)是，则所述报文是PSF报文，所述报文会被封装成一个uCos-II的消息邮箱发送给图2中的序号为3的进程做后续处理；
[0047] b)否，则所述报文是IEEE802.3封装的IEEE - 1588报文，所述报文会被封装成一个uCos-II的消息邮箱发送给图2中的序号为11的进程做后续处理
[0048] (2) PSF报文处理(IRIG - B码的解析):
[0049] 这部分的处理，与图2中序号为3的进程相对应。
[0050] 一个IRIG -B码帧有100个码元，共200个信号变化沿，对应有200个PSF报文。
[0051] 图2中序号为3的进程，在接收到消息邮箱后会解析PSF报文，提取所述PSF报文内的有关IRIG - B码信号变化时的时标信息，将所述时标信息送入一个长度为200的FIFO缓存。通过计算所述缓存中相邻单元内的时标差值，即可解算出输入的IRIG - B码的信号脉宽，进而得出相应的码元，以最终解析出IRIG - B报文所含的UTC时间(协调世界时)。
[0052] 所述UTC时间代表的是所述IRIG - B报文的秒准时时刻的基准源时间。所述的IRIG -B码秒准时沿到达主站时，主站内部的时间可通过PSF报文内的时标来获取。通过计算所述时标与UTC时间的差值，即可得出主站内部时间与基准源间的误差。采用DP83640提供的Step Adjustment的调节方式,将所述误差值转换为相应的参数后,通过所述CPU与DP83640间的MIIM总线接口操作相应的寄存器后即可完成时间的调节。
[0053] (3) IEEE802.3帧格式的ffiEE - 1588报文的分类处理:
[0054] 这部分的处理，与图2中序号为11〜14的进程相对应。
[0055] 在所述的11号进程中，CPU在接收到消息邮箱后，会解析所述邮箱内的IEEE-1588报文，根据所述报文内的messageType字段来识别IEEE -1588报文类型，并进行处理，具体处理流程如下:
[0056] 1.messageType为0x01时,所述报文为DelayReq报文,所述报文封装成消息邮箱后，发送给12号进程做后续处理；
[0057] 2.messageType为0x02时,所述报文为PdelayReq报文,所述报文封装成消息邮箱后，发送给13号进程做后续处理；
[0058] 3.messageType为0x03时,所述报文为PdelayResp报文,所述报文封装成消息邮箱后，发送给13号进程做后续处理；
[0059] 4.messageType为0x0A时，所述报文为PdelayRespFollowup报文，所述报文封装成消息邮箱后，发送给13号进程做后续处理；
[0060] 5.messageType为0x0B时,所述报文为Announce报文,所述报文封装成消息邮箱后，发送给14号进程做后续处理；
[0061] 6.messageType为其它值时,所述报文被直接丢弃。
[0062] 在所述的12号进程中，CPU在接收到消息邮箱后，会解析所述邮箱内的DelayReq报文，所述CPU会提取出插入在所述报文的保留字段内的接收时标，并将所述时标封装成DelayResp报文后,通过以太网接口发送出去。
[0063] 在所述的13号进程中，CPU在接收到消息邮箱后，会解析所述邮箱内的报文，所述报文可能有三种，所述CPU对所述报文的处理方式具体如下:
[0064] 1.PdelayReq 报文:
[0065] a)所述CPU会提取出插入在所述报文的保留字段内的接收时标，并将所述时标封装成PdelayResp报文后,通过以太网接口发送出去。
[0066] b)所述CPU通过MIIM接口，获取步骤a中发送的PdelayResp报文的发送时标,并所述时标封装成PdelayRespFollowup报文后,通过以太网接口发送出去。
[0067] 2.PdelayResp 报文:
[0068] a)所述CPU提取并记录插入在所述报文的保留字段内的PdelayResp报文的接收时标。[0069] b)所述CPU提取并记录所述报文中携带的PdelayReq报文的接收时标。
[0070] 3.PdelayRespFollowup 报文:
[0071] a)所述CPU提取并记录所述报文中携带的PdelayResp报文的发送时标。
[0072] b)所述CPU依据步骤a中获取的PdelayResp报文的发送时标，以及解释PdelayResp报文时获取的PdelayResp报文的接收时标和PdelayReq报文的接收时标，外加PdelayReq报文的发送时标(所述时标由7号进程以消息邮箱的方式提供)，计算出主站与对端的链路延时。
[0073] 在所述的14号进程中，CPU在接收到消息邮箱后，会解析所述邮箱内的Announce报文，并参照IEEE -1588标准的第9.3章节有关BMC算法的Figure26〜28中的逻辑要求，来完成IEEE - 1588状态机的状态识别和切换。
[0074] 注:在步骤(3)中，相关进程收、发的所有IEEE -1588报文均为IEEE802.3的帧格式。
[0075] (4) IEEE802.3 帧格式的 Sync、Followup、PdelayReq 和 Announce 报文的发送处理:
[0076] 这部分的处理，与图2中序号为15〜17的进程相对应。
[0077] 在所述的15号进程中，CPU依次完成如下操作:
[0078] 1.发送 PdelayReq 报文。
[0079] 2.通过ΜΠΜ接口，访问DP83640的寄存器，获取步骤I中发送的PdelayReq报文对应的发送时标。将所述时标装成成消息邮箱的方式发送给13号进程。
[0080] 3.按照设定的P2P对时周期，定时休眠，待唤醒后重新开始执行步骤I。
[0081] 在所述的16号进程中，CPU依次完成如下操作:
[0082] 1.发送 Sync 报文。
[0083] 2.通过ΜΠΜ接口，访问DP83640的寄存器，获取并保存步骤I中所述Sync报文对应的发送时标。
[0084] 3.将步骤2中所获取的时标封装成Followup报文发送。
[0085] 4.按照设定的对时同步周期，定时休眠，待唤醒后重新开始执行步骤I。
[0086] 在所述的17号进程中，CPU依次完成如下操作:
[0087] 1.根据主站当前的状态，填充Announce报文的相应字段后发送
[0088] 2.按照设定的报文发送周期，定时休眠，待唤醒后重新开始执行步骤I。
[0089] 注:在步骤(4)中，相关进程收、发的所有IEEE -1588报文均为IEEE802.3的帧格式。
[0090] (5) IPv4报文的分类处理:
[0091] 这部分的处理，与图2中序号为2的进程相对应。
[0092] 在所述进程2中，CPU需要识别出封装在UDP报文中的IPv4帧格式的IEEE -1588报文，并以消息邮箱的方式转给4号进程，将其余报文转给18号进程。
[0093] 所述CPU在识别待判断报文是否为IPv4帧格式的IEEE - 1588报文，是依据以下几个判定条件:
[0094] 1.所述报文为UDP报文。
[0095] 2.所述报文的目的端口为319或320。
[0096] 3.所述报文的目的 IP 为 224.0.0.107 或 224.0.1.129。
[0097] 当所述报文同时满足以上3个条件时，即可判定为IPv4帧格式的IEEE - 1588报文。
[0098] (6) IPv4帧格式的ffiEE - 1588报文的分类处理:
[0099] 这部分的处理,与图2中序号为5〜7的进程相对应。
[0100] 封装在IEEE802.3帧中的IEEE - 1588报文的格式定义与封装在IPv4帧中的IEEE - 1588报文的格式定义是完全一样的，因此这部分的处理的流程和判定条件，与上述的步骤(3)是一致的。唯一的不同点在于步骤(3)中处理的是封装在IEEE802.3帧中的IEEE - 1588报文数据，而本步骤中处理的是封装在IPv4帧中的IEEE - 1588的报文数据。
[0101] (7) IPv4 巾贞格式的 Sync、Followup、PdelayReq 和 Announce 报文的发送处理:
[0102] 这部分的处理，与图2中序号为8〜10的进程相对应。
[0103] 封装在IEEE802.3帧中的IEEE - 1588报文的格式定义与封装在IPv4帧中的IEEE - 1588报文的格式定义是完全一样的，因此这部分的处理的流程和判定条件，与上述的步骤(4)是一致的，唯一的不同点在于步骤(4)中发送的报文的数据是封装成IEEE802.3帧后发送的，而本步骤中发送的报文是封装成IPv4帧后发送的。