发明内容
为解决现有技术中的不足,本申请提供一种基于多CPU工业系统控制器的工控逻辑冗余实现方法,涉及多个独立运行的CPU,每个CPU中包含独立运行的用户逻辑运行时系统(user run time system,userRTS)、独立运行的仲裁逻辑运行时系统(redundency runtime system,reduRTS),通过抢占式的仲裁方法进行逻辑仲裁,以此提高系统的可靠性和安全等级。
为了实现上述目标,本发明采用如下技术方案:
一种基于多CPU工业系统控制器的工控逻辑冗余实现方法,所述工控系统控制器包括N个CPU,N≥2,每个CPU均包含独立运行的userRTS和reduRTS;
其特征在于:
实际运行中,N个userRTS独立运行用户逻辑,N个reduRTS依据userRTS执行结束的时间抢夺仲裁执行权,具有仲裁执行权的reduRTS获取进行仲裁所需的userRTS逻辑输出数据并运行仲裁逻辑,将仲裁结果输出到执行单元,实现工控逻辑冗余。
本发明进一步包括以下优选方案:
优选地,所述用户逻辑为:由用户根据工业现场的控制流程组态的工业控制逻辑;
所述仲裁逻辑由控制器厂商开发或由用户自主组态。
优选地,所述控制器还包括由N个CPU共享的消息总线、逻辑输出数据总线、仲裁输出总线以及用户逻辑输出数据存储区;
所述消息总线,用于用户组态的控制逻辑下装、仲裁逻辑下装以及N个CPU之间消息的传递、同一CPU内reduRTS和userRTS之间消息的传递;
所述消息包括逻辑启动、逻辑执行结束、逻辑仲裁结束消息;
所述逻辑输出总线,用于将N个CPU中userRTS计算的逻辑输出数据传递到逻辑输出数据存储区,以及将N个userRTS保存在逻辑输出数据存储区中的数据传递给具有仲裁执行权的reduRTS中;
所述仲裁输出总线,用于输出最终的经过仲裁的逻辑输出结果,即将具有仲裁执行权的reduRTS计算的结果传递到实际的执行IO插件中,驱动实际的执行机构动作;
所述逻辑输出数据存储区,用于保存N个userRTS计算的逻辑输出数据,同时向拥有仲裁权的CPU中的reduRTS提供进行仲裁所需的userRTS逻辑输出数据。
优选地,所述userRTS的状态转换过程如下:
在系统上电后N个CPU各自运行,当接收到启动逻辑运行消息后,N个userRTS进入用户逻辑运行状态,各自运行其用户逻辑;
当userRTS运行完一用户逻辑执行周期以后进入发送逻辑执行结束消息的状态,在该状态下完成逻辑执行结束消息的发送,之后进入等待启动逻辑运行消息的状态;
当userRTS再次接收到启动逻辑运行消息后开始进入下一轮的用户逻辑运行状态。
优选地,所述reduRTS的状态转换过程如下:
在系统上电后N个独立的reduRTS开始运行,由初始态完成初始化工作之后直接进入等待逻辑执行结束的状态;
当收到N个独立的逻辑执行结束消息或者等待超时以后进入仲裁权判断状态;
在仲裁权判断状态下,reduRTS根据各自的运行信息综合判断是否获得仲裁执行权,未能获得仲裁执行权的reduRTS进入等待启动逻辑运行消息状态;
在等待启动逻辑运行消息状态下,如果收到启动逻辑运行消息则立即进入等待逻辑执行结束状态,如果等待超时,则启动本CPU内的userRTS,之后进入等待逻辑执行结束状态;
获得仲裁执行权的reduRTS,则开始执行仲裁逻辑,在仲裁逻辑执行结束后将仲裁结果通过仲裁输出总线发送出去,之后进入等待逻辑周期结束状态;
在等待逻辑周期结束状态下,判断是否到达启动下一次用户逻辑执行周期,当用户逻辑执行周期到达后进入发送启动逻辑运行消息的状态,完成启动逻辑运行消息的发送之后进入等待逻辑执行结束的状态。
优选地,所述reduRTS判断是否等待超时的方法如下:
计算当前系统时间与收到启动逻辑运行消息时间的时间差,当时间差大于Tuser+Talign时判断为等待超时;
Tuser为用户逻辑执行时间;
Talign为执行对齐时间,该时间为等待N个CPU中的userRTS执行结束的时间。
优选地,所述reduRTS通过如下方法判断是否获得仲裁执行权:
判断当前仲裁的初始态是正常进入仲裁状态还是超时进入仲裁状态;
若为正常进入仲裁状态,仲裁逻辑解析收到的来自N个CPU发送的逻辑执行结束消息中的时间信息,比较这些消息中所包含的时间,找出其中最早的时间,如果发现这个最早的时间属于本CPU的,那么本CPU中的reduRTS获得仲裁执行权,其他CPU则放弃仲裁执行权;
若为超时进入仲裁状态,仲裁逻辑锁定已经收到的逻辑执行结束消息,丢弃在此之后收到的逻辑执行结束消息,丢弃的消息不参与仲裁权的判别;仲裁逻辑解析锁定的逻辑执行结束消息中的时间信息,找出最早完成用户逻辑执行的CPU,该CPU中的reduRTS获取仲裁执行权,其他CPU中的reduRTS则放弃仲裁执行权。
优选地,所述reduRTS在判断是否获得仲裁执行权时,若存在解析出的逻辑执行结束消息中的时间信息相同,且均属于最早的时间的情况,则比较对应CPU的编号,编号最小的CPU中的reduRTS获得仲裁执行权,其他CPU中的reduRTS放弃仲裁执行权。
优选地,所述reduRTS执行仲裁逻辑过程如下:
从逻辑输出数据存储区读取N个CPU中userRTS的逻辑输出数据到reduRTS的逻辑输入区;
执行模拟量的仲裁逻辑和数字量的仲裁逻辑;
将仲裁结果通过仲裁输出总线发送到实际的执行IO插件中,驱动实际的执行机构动作。
优选地,模拟量的仲裁逻辑为:选高、选低或选平均值;
数字量的仲裁逻辑为:数字量一致的情况下直接输出;不一致的情况下选多、保持不变或者输出预设的安全值。
本申请所达到的有益效果:
本发明采用工控系统控制器中N个CPU均独立运行reduRTS,实际运行中由N个reduRTS抢夺仲裁控制权的方式,避免了单一仲裁点带来的风险。
具体实施方式
下面结合附图对本申请作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案,而不能以此来限制本申请的保护范围。
如图1所示,本发明的一种基于多CPU工业系统控制器的工控逻辑冗余实现方法,所述工控系统控制器包括N个CPU,N≥2,每个CPU均包含独立运行的userRTS和reduRTS;
CPU中运行的userRTS和reduRTS具备独立的运行地址空间;
实际运行中,N个userRTS独立运行用户逻辑,N个reduRTS依据userRTS执行结束的时间抢夺仲裁执行权,具有仲裁执行权的reduRTS获取进行仲裁所需的userRTS逻辑输出数据并运行仲裁逻辑,将仲裁结果输出到执行单元,实现工控逻辑冗余。
具体实施时,所述用户逻辑为:由用户根据工业现场的控制流程组态的工业控制逻辑;
所述仲裁逻辑由控制器厂商开发或根据用户对可靠性以及实际应用场合的要求进行自主组态。
所述控制器还包括由N个CPU共享的消息总线、逻辑输出数据总线、仲裁输出总线以及用户逻辑输出数据存储区;
所述消息总线,用于用户组态的控制逻辑下装、仲裁逻辑下装以及N个CPU之间消息的传递、同一CPU内reduRTS和userRTS之间消息的传递;
所述消息总线通过逻辑组态软件向N个CPU传递逻辑启动、停止、在线监视消息;
所述消息包括逻辑启动、逻辑执行结束、逻辑仲裁结束消息;
所述逻辑输出总线,用于将N个CPU中userRTS计算的逻辑输出数据传递到逻辑输出数据存储区,以及将N个userRTS保存在逻辑输出数据存储区中的数据传递给具有仲裁执行权的reduRTS中;
所述仲裁输出总线,用于输出最终的经过仲裁的逻辑输出结果,即将具有仲裁执行权的reduRTS计算的结果传递到实际的执行IO插件中,驱动实际的执行机构动作;
所述逻辑输出数据存储区,用于保存N个userRTS计算的逻辑输出数据,同时向拥有仲裁权的CPU中的reduRTS提供进行仲裁所需的userRTS逻辑输出数据。
如图2所示实施例中,工控系统控制器包含了3个独立的CPU,通过系统中的以太网交换芯片作为消息总线,三个独立的CPU通过各自的以太网接口连接到交换芯片上,同时该控制器通过以太网芯片对外扩展了两个以太网接口(以太网接口1、以太网接口2),这两个接口用于连接外部的逻辑组态软件实现用户逻辑和仲裁逻辑的下装;
在本实施例中使用DDR内存作为逻辑输出数据存储区,使用DDR接口总线实现逻辑输出数据总线,三个独立的CPU使用各自的的UART接口构成了仲裁输出总线,获得仲裁输出权的CPU可以通过自己的UART将仲裁数据发送到RS485接口上,RS485接口在外部连接用于控制执行机构的各种IO插件;
如图3所示,reduRTS和userRTS作为系统中的两个独立进程运行,各自有独立的进程空间相互不干扰,为了保持3个CPU中所有reduRTS和userRTS的运行独立性和处理流程的一致性,即使在同一个CPU内部运行的reduRTS和userRTS之间也使用相同的消息总线来进行交互,在任何一个reduRTS来看所有的userRTS都来自消息总线,同样对于任意一个userRTS来说所有的消息也均来自消息总线,所有的处理流程都保持一致。
userRTS具备以下功能:
(1)从消息总线上接收到启动逻辑运行消息后开始执行用户组态的用户逻辑。
(2)在执行完用户逻辑后将逻辑计算输出数据通过逻辑输出数据总线写入逻辑输出数据存储区中属于自己的数据区。
(3)在执行完用户逻辑后向消息总线发送逻辑执行结束消息;
逻辑执行结束消息中包括当时的时间信息,该时间信息用于reduRTS之间仲裁执行权判定。
(4)在完成(1)(2)(3)后进入停止状态,等待接收下一次启动逻辑运行消息。
仲裁逻辑运行时系统具备以下功能:
(1)从消息总线上接收来自各个CPU中userRTS发送的逻辑执行结束消息。
(2)从消息总线上接收到启动逻辑运行消息,并以此消息作为超时判断的时间起点。
(3)具有超时判断功能,即根据启动逻辑运行消息的时间(以下简称Tstart)和用户逻辑执行周期来判断是否等待超时。
(4)具有依据各个userRTS执行结束的时间判别仲裁执行权的功能。
(5)具有执行仲裁逻辑的功能。
如图4所示,所述userRTS的状态转换过程如下:
在系统上电后N个CPU各自运行,当接收到启动逻辑运行消息后,N个userRTS进入用户逻辑运行状态,各自运行其用户逻辑;
当userRTS运行完一用户逻辑执行周期以后进入发送逻辑执行结束消息的状态,在该状态下完成逻辑执行结束消息的发送,之后进入等待启动逻辑运行消息的状态;
当userRTS再次接收到启动逻辑运行消息后开始进入下一轮的用户逻辑运行状态,此后不断重复上述过程。
如图5所示,所述reduRTS的状态转换过程如下:
在系统上电后N个独立的reduRTS开始运行,由初始态完成初始化工作之后直接进入等待逻辑执行结束的状态;
当收到N个独立的逻辑执行结束消息或者等待超时以后进入仲裁权判断状态;
在仲裁权判断状态下,reduRTS根据各自的运行信息综合判断是否获得仲裁执行权,未能获得仲裁执行权的reduRTS进入等待启动逻辑运行消息状态;
在等待启动逻辑运行消息状态下,如果收到启动逻辑运行消息则立即进入等待逻辑执行结束状态,如果等待超时,则启动本CPU内的userRTS(通过发送启动逻辑运行消息),之后进入等待逻辑执行结束状态;
获得仲裁执行权的reduRTS,则开始执行仲裁逻辑,在仲裁逻辑执行结束后将仲裁结果通过仲裁输出总线发送出去,之后进入等待逻辑周期结束状态;
在等待逻辑周期结束状态下,判断是否到达启动下一次用户逻辑执行周期,当用户逻辑执行周期到达后进入发送启动逻辑运行消息的状态,完成启动逻辑运行消息的发送之后进入等待逻辑执行结束的状态,后续不断重复这个流程。
系统运行时,用户被控对象的控制周期Tctrl由四部分组成:
Tctrl=Tuser+Talign+Tarbi+Twait;
其中:
Tuser为用户逻辑执行时间,即用户逻辑执行周期;
Talign为执行对齐时间,该时间为等待N个CPU中的userRTS执行结束的时间,
Tarbi为仲裁逻辑执行时间;
Twait为延时等待时间,Twait可能存在为0的情况。
所述reduRTS判断是否等待超时的方法如下:
计算当前系统时间与收到启动逻辑运行消息时间的时间差,当时间差大于Tuser+Talign时判断为等待超时,此时强制执行仲裁逻辑;
Tuser为用户逻辑执行时间;
Talign为执行对齐时间,该时间为等待N个CPU中的userRTS执行结束的时间。
本发明等待超时均采用此方法判断。
所述reduRTS通过如下方法判断是否获得仲裁执行权:
判断当前仲裁的初始态是正常进入仲裁状态还是超时进入仲裁状态;
当正常进入仲裁状态时说明此时所有N个CPU中的userRTS已经执行完毕,并且已经接收到了相应的逻辑执行结束消息,此时所有N个CPU的逻辑输出数据区的数据均认为是有效的可以参加仲裁。
若为正常进入仲裁状态,仲裁逻辑解析收到的来自N个CPU发送的逻辑执行结束消息中的时间信息,比较这些消息中所包含的时间,找出其中最早的时间,如果发现这个最早的时间属于本CPU的,那么本CPU中的reduRTS获得仲裁执行权,其他CPU则放弃仲裁执行权;
若为超时进入仲裁状态,仲裁逻辑锁定已经收到的逻辑执行结束消息,丢弃在此之后收到的逻辑执行结束消息,丢弃的消息不参与仲裁权的判别;仲裁逻辑解析锁定的逻辑执行结束消息中的时间信息,找出最早完成用户逻辑执行的CPU,该CPU中的reduRTS获取仲裁执行权,其他CPU中的reduRTS则放弃仲裁执行权。
即获取所有有效的逻辑执行结束消息,从这些消息中解析出时间信息,对比解析出的时间信息,从中找出最早的时间,然后查看该消息所对应的发送节点是否是本节点,如果是本节点则认为自己获取了仲裁执行权(最先执行完用户逻辑的具有执行权),否则认为未获得仲裁执行权。
所述reduRTS在判断是否获得仲裁执行权时,若存在解析出的逻辑执行结束消息中的时间信息相同,且均属于最早的时间的情况,则比较对应CPU的编号,编号最小的CPU中的reduRTS获得仲裁执行权,其他CPU中的reduRTS放弃仲裁执行权。
所述reduRTS执行仲裁逻辑过程如下:
从逻辑输出数据存储区读取N个CPU中userRTS的逻辑输出数据到reduRTS的逻辑输入区;
执行模拟量的仲裁逻辑和数字量的仲裁逻辑;
将仲裁结果通过仲裁输出总线发送到实际的执行IO插件中,驱动实际的执行机构动作。
模拟量的仲裁逻辑为:选高、选低或选平均值;
数字量的仲裁逻辑为:数字量一致的情况下直接输出;不一致的情况下选多、保持不变或者输出预设的安全值。
本发明申请人结合说明书附图对本发明的实施示例做了详细的说明与描述,但是本领域技术人员应该理解,以上实施示例仅为本发明的优选实施方案,详尽的说明只是为了帮助读者更好地理解本发明精神,而并非对本发明保护范围的限制,相反,任何基于本发明的发明精神所作的任何改进或修饰都应当落在本发明的保护范围之内。