张 潇,舒 海,王童生
(中广核(北京)仿真技术有限公司,广东 深圳 518028)
随着数字化仪控与仿真技术的不断发展,具有高仿真度的虚拟DCS 逐渐成为核电厂全范围模拟机主要开发方式。虚拟DCS 是将真实DCS 在非DCS 的计算机系统中以某种形式再现[1],保留了实际DCS 的软硬件系统结构、组态方法、算法模块、系统管理等内容,能够最大限度满足操作员对各类机组故障培训的需求[2],因此受到了业主和操作员广泛认可。虚拟DCS 与仿真支撑平台的通讯接口开发是全范围模拟机项目研制的关键技术之一,也是全范围模拟机项目建设的关键路径。
进入到三代核电时代,华龙1 号逐渐成为国内核电建设的主流。相比较于二代核电机组,其DCS 系统有着更为复杂的设计,特别是在系统多样性设计原则下,IO 数据量有了成倍的增长,这对虚拟DCS 的通讯性能提出了很大挑战。因此,DCS 通讯接口的稳定性与可靠性成为模拟机开发的重点任务,也是模拟机系统可用率的关键指标之一。
基于虚拟DCS 的核电厂全范围模拟机参照了实际电厂机组DCS 系统采用的三层网络架构,即Level 0,Level 1,Level 2。Level 0 层为现场控制层,主要以执行机构和传感器为主的现场设备;Level 1 层为过程控制层,包括反应堆保护系统、T/G 控制系统和采集系统等;Level 2 层为操作监视层,包括用于主控室控制的KIC、BUP 等人机交互相关的操作。虚拟DCS 软件由实际DCS 改造而成,并且根据用途的不同,分为非安全级与安全级。在保留原软件的系统结构、组态方法、算法模块、系统管理等内容功能的同时,还增加了模拟机软件的专有功能,包括:仿真命令、数据处理、IC 存储、故障模拟等。这些功能的实现与仿真模型的通讯接口有着紧密的联系。虚拟DCS 与实际DCS 的逻辑结构如图1。
图1 逻辑结构Fig.1 Logic structure
仿真模型与虚拟DCS 系统间的通讯接口可以采用不同的技术解决方案,目前较为主流的通讯方案中以OPC 与TCP/IP 通信协议为主要实现方式。OPC 是一个工业通信标准,它定义过程控制数据如何在软硬件应用中传输,为工业自动化软件面向对象的开发提供了统一的标准[3],采用OPC 技术作为虚拟仿真方案已经广泛应用于仿真模拟机的开发应用中。TCP/IP 协议作为Internet 的基本的协议,主要由网络层的IP 协议和传输层的TCP 协议构成[4]。TCP 是面向连接的通信协议,通过3 次握手建立连接。通讯结束时,需要主动与连接端断开。协议自带的传输再确认、重传、阻塞控制机制,可以很好地解决系统间数据同步的可靠性。该协议也是目前CPR1000/ACPR1000 核电厂全范围模拟机采用的虚拟DCS 通讯集成方案。
图2所示,仿真模型与安全级、非安全级虚拟DCS 的Level 1 系统之间采用了基于C/S 架构的通讯方式。其中,虚拟DCS 软件作为通讯服务端,负责监听和响应仿真模型的通讯请求,仿真模型则作为通讯客户端负责通讯连接与仿真指令的发起。DCS 接口程序基于仿真支撑平台Genus 开发,采用C/C++语言实现,开发过程中需要利用DCS 厂家提供的通讯DLL 和通讯协议,它们是DCS 接口实现的基础。DLL 基于Socket 的TCP/IP 协议封装实现,负责通讯底层的收发与流量算法;通讯协议则规定了模拟机仿真指令与数据封包、解包的格式与方法等。
图2 通讯架构Fig.2 Communication architecture
DCS 通讯接口开发需要解决通讯过程中的3 大类数据的传输问题:①仿真指令和仿真指令反馈数据,该类型数据是模拟机系统特有的仿真指令,包括:加载、冻结、复位IC、运行等数十种;②仿真模型与虚拟DCS Level 1非安全级、安全级的I/O 数据,这些数据是DCS 通讯的主要内容,包括AI、DI、DO、AO 以及故障模拟数据等;③非安全级与安全级DCS Level 1&Level 2 系统间的I/O 数据,既包括了Level1 层的数据,也包括了Level 2层的数据。如调屏网关指令等,该类型数据,仿真模型并不关注,但需要对其进行存储转发。
全范围模拟机系统的数据交换由仿真指令驱动,仿真指令由仿真模型发起,不同的指令会引起不同的系统状态变化,DCS 系统状态转换必须与仿真模型保持一致,这是系统间通讯的前提。全范围模拟机系统状态大致可分为4种。
准备模式:系统内各软件初始化完成后的状态。这种状态下,系统内逻辑都处于不运算状态,仅有通讯端口保持监听,等待指令的唤醒。
冻结模式:此时系统内各软件已完成通讯建立或者IC存储/复位相关操作,系统软件处于挂起状态,等待新的指令。
运行模式:系统内各软件完成运行指令后的状态。此时模拟机系统内部的仿真模型与虚拟DCS 开始周期性地进行数据包交换,所有软件的功能、逻辑与算法都开始实时运算。
回放模式:该模式与之前的运行模式基本一致,只是将模拟机切换至之前的某个时间点运行,所有的教员操作与学员操作都会反映到模拟机系统中。该模式下系统依然保持运算,并实时进行数据交换。
仿真模型与虚拟DCS 通讯的数据包格式采用了包头+包体的形式,包头部分包含了模拟机的专有字段信息,如:仿真时间、仿真指令、IC 编号等。包体部分则与实际机组的通讯结构保持一致。数据的打包需要严格按照通信协议规定的数据结构进行,否则会造成数据的解析失败,因此仿真模型与DCS 系统间共享了相同的I/O 数据。
图3所示,虚拟DCS 的I/O 数据由实际DCS 的组态数据生成,文件中包含了与I/O 变量相关的信息,这是通讯双方数据一致的基础。为了确保仿真模型与虚拟DCS 系统间通讯数据的匹配,DCS 系统会提供自己的I/O 数据供仿真模型解析转换,形成仿真平台可识别的数据库格式,仿真平台再通过共享内存机制,建立起仿真模型变量与DCS 变量间的对点映射。
图3 通讯点转换Fig.3 Communication point conversion
仿真模型与虚拟DCS 间的通讯由仿真模型发起,DCS系统应答响应,所有仿真指令的发送与应答总是一个接一个地传输。
一个通讯周期由两个仿真周期组成,如图4。其为一个完整的DCS 通信周期的指令运行时序。当仿真模型与虚拟DCS 系统完成好通讯连接、复位IC、运行状态同步后,系统开始执行第一个仿真周期。首先仿真模型侧的通讯程序执行接收功能,由于DCS 系统还没有数据发送,因而接收函数在此时将无数据接收。接收函数阻塞超过设定时间后执行发送函数,该过程需要将指令连同模型的输入数据一同打包,再由DLL 发送给DCS。DCS 接收到数据后,会立即向仿真模型返回应答指令与数据。进入第二个仿真周期,仿真模型继续运算,DCS 通讯接口程序则处于等待状态,直到第二个仿真周期结束,即第一个DCS 通讯周期结束。进入第二个通讯周期,重新执行收发流程,此时仿真模型的DCS 接口程序才能接收到上一个通讯周期DCS 系统发来的应答指令和数据,仿真模型在确认接收成功后会立即发送新的指令与数据到DCS,随后进入等待状态,直到第二个通讯周期结束,如此周而复始。在这种机制下,仿真模型的DCS 通讯发送与接收并不在同一个通讯周期内完成,即仿真模型每次接收的数据都是DCS 系统上一个周期发送的。
图4 指令运行时序Fig.4 Command execution sequential
上述的指令时序属于周期包指令,通常情况下DCS 会立即返回,但如果仿真指令与IC 操作相关,如存储IC,则反馈数据可能需要等待较长的时间才能收到,具体的时间取决于虚拟DCS 执行所消耗的时间。因此,为了保证系统的正常运转,DCS 接收指令后会单独开启一个IC 存储相关的线程任务在后台执行,而不影响主线任务,直到完成任务后再反馈给仿真模型。
实时性是仿真系统重要的性能指标之一,全范围模拟机系统的实时性由仿真模型决定。在诸多的影响模拟机实时性的因素中,通讯实时性是其中的关键。DCS 通讯接口编程采用Socket 同步调用模式开发,这种通讯方式需要合理地设置好接收函数的超时时间,避免发生通讯阻塞延迟造成的平台运行超时与死锁问题,但同时也要确保仿真模型能够完整地接收到数据。为了解决这个问题,针对不同的仿真指令设置不同的接收超时时间非常必要。通常不同仿真指令的超时设置从几毫秒到几十秒不等,时长取决于指令在后台执行的时间,例如通讯连接、IC 相关的仿真指令会设置较长的超时等待时间,从而确保系统双方的状态同步。
DCS 通讯接口需要能精准地反馈通讯过程中的异常信息,从而及时向模拟机教员和运维人员反馈运行过程中发生的问题。因此,仿真模型与DCS 会针对每一个通讯周期进行数据包的检测和判断,如果内容与预期不符,需要及时返回错误代码,并主动记录在通讯日志中,必要时会终止通讯,确保仿真数据的准确性。
异常信息分为3 类:①指令执行异常,该类型错误主要表现为DCS 系统对数据包解析的异常,包括:指令执行超时、指令执行失败、I/O 数据不一致等;②以Socket TCP 封装的通讯动态库定义的报错信息,这些报错信息通常定义在DLL 中,如内存溢出,缓存区异常,对端强制断开等情况时,错误代码会及时反馈给仿真模型;③特定的DCS 应用服务异常,该类型信息会针对具体的异常服务故障进行提示,如:计算服务器故障、历史服务器故障等。
衡量通信系统的性能主要归纳为两个指标,即通讯有效性和通讯质量:①通讯有效性反映为通讯执行的速率,最直接的观测指标是DCS 接口程序在一个仿真周期所持续的时间,其计算方法是利用两次通讯周期运算所用的时钟频率计数之差求得;②网络通讯质量反映为数据收发过程中产生的丢包率,通讯丢包率的算法公式如下:丢包率=(应发包数-实际收包数)/应发包数×100%。
本次测试,采用了ACPR1000 全范围模拟机的数据与环境,其中仿真模型服务器选用联想SR650,CPU 主频3.4 GHz,操作系统为Window server 2016,千兆网络设备。虚拟DCS 软件包括:非安全级系统HOLLIAS_MACS、安全级系统FirmSys 以及基于SpeedHold 开发的多样化系统(KDS)、严重事故系统(KDA)、P-GU 系统[5]。测试数据见表1,仿真模型需要向5 个虚拟DCS 系统依次发起通讯请求,并且在规定的通讯周期时间内完成5 次的数据发送与5 次的数据接收。
表1 测试数据Table 1 Test data
为了防止其他运算模块对测试数据的影响,测试过程中仅保留与通讯和传值相关的模块。图5 展示了仿真模型与虚拟DCS 通讯过程的周期执行时间,其曲线维持在47ms ~48ms,趋势平稳,实时性满足全范围模拟机系统的运行周期要求。图6 展示了仿真模型与虚拟DCS 通讯过程产生的丢包率,趋势基本为0,且曲线平滑,反映出系统间的数据交换质量良好,无丢包现象。
图5 通讯实时性Fig.5 Real time communication
图6 丢包率Fig. 6 Packet loss rate
全范围模拟机系统为了确保仿真的精度,会严格地按照设定的仿真周期调度系统内的运算,即实时模式。如果启用非实时模式,系统有可能会出现“有多快,算多快”的快时模式,引起系统的全局加速,仿真模型的DCS 通讯数据发送也会加快。由于受限于DCS 逻辑运算的负荷[6],会造成虚拟DCS 系统无法及时响应计算,导致明显的数据丢包和延时问题,甚至通讯异常,因而需要谨慎使用快时模式。
TCP 协议是一个面向连接的高可靠性通讯协议,作为全范围模拟机虚拟DCS 集成的通讯方案具有很好的优势,协议自带的传输再确认、重传、阻塞控制机制可以有效地实现仿真模型与虚拟DCS 系统间的数据交换。实践证明,基于TCP 协议开发的DCS 通讯接口方案能够满足核电厂全范围模拟机大数据、多系统通讯的功能与性能指标,并且其设计理念上与实际DCS 系统非常类似,两者之间具有天然的可融合性,未来具备向DCS 半实物闭环验证领域升级与拓展的能力。