现代核电站的高负荷分布式控制系统

没有电力,就不会有我们如此钟爱的高负载互联网服务。 奇怪的是,用于核电厂等发电设施的控制系统也很分散,也承受着高负荷,并且还需要许多技术。 此外,核能在世界上的份额将不断增长,这些设施的管理及其安全性是一个非常重要的主题。

因此,让我们了解其中的内容,如何安排,主要的结构难题在哪里以及在核电站中可以应用流行的ML和VR技术的地方。



核电厂是:

  • 由于必须备份物理系统以及Internet服务,因此平均需要3-4个功率单元,每个NPP的平均容量为1000 MW。
  • 约有150个特殊子系统,可确保该设施的功能。 例如,这是内部反应堆控制系统,涡轮机控制系统,化学水处理控制系统等。 这些子系统中的每一个都集成到自动化过程控制系统(ACS TP)的上级块(SVBU)的巨大系统中。
  • 200-300,000个标签,即实时变化的信号源。 您需要了解什么是变化,什么不是变化,如果我们没有错过任何事情,如果我们错过了什么,那么该怎么做。 这些参数由两名操作员监控,即首席反应堆控制工程师(VIUR)和首席涡轮控制工程师(VIUT)。
  • 大多数子系统集中的两座建筑物:反应堆和涡轮机舱。 如果发生非标准或标准事件,两个人必须实时做出决定。 如此高的责任仅施加于两个人,因为如果他们更多,那么他们将需要在彼此之间达成共识。


关于发言人:瓦迪姆·波多尔尼(Vadim Podolny,电动静脉代表莫斯科工厂Fizpribor)。 这不仅是一家工厂,而且主要是一个工程局,在其中开发硬件和软件。 该名称是对自1942年以来一直存在的企业历史的致敬。 这不是很时髦,但很可靠-这就是他们想告诉他们的。

核电厂的IIoT


Fizpribor企业生产连接整个子系统所需的全部设备,这些子系统包括传感器,下游自动化控制器,用于构建下游自动化控制器的平台等。

在现代设计中,该控制器只是一台工业服务器,具有扩展的输入/输出端口,用于将设备与特殊子系统连接。 这些是大型机柜-与服务器机柜相同,只是它们具有提供计算,收集,处理和管理的特殊控制器。



我们开发安装在这些控制器,网关设备上的软件。 此外,与其他地方一样,我们有数据中心,一个本地云,在其中进行计算,处理,决策,预测以及控制对象运行所需的一切。

应当指出,在我们的世纪中,设备正在减少,变得越来越智能。 许多设备已经具有微处理器-提供预处理的小型计算机(现在称为时髦)-执行边界计算以免使整个系统过载。 因此,可以说,核电厂的现代自动化过程控制系统已经像工业物联网一样。

控制此的平台是许多人听说过的IoT平台。 现在有很多,我们与实时紧密地联系在一起。

最重要的是,构建了端到端验证和确认机制以提供兼容性和可靠性检查。 它还包括压力测试,回归测试,单元测试-所有您所知道的。 只有通过我们设计和开发的硬件以及与此硬件一起使用的软件才能做到这一点。 网络安全问题(通过设计确保安全等)正在得到解决。



该图显示了控制控制器的处理器模块。 这是一个由6个单元组成的平台,带有用于放置母板的机箱,我们在其上表面安装了所需的设备(包括处理器)。 现在,我们开始了替代进口的浪潮,我们正在努力支持国内加工商 。 有人说,结果,工业系统的安全性将提高。 的确如此,稍后我将解释原因。

安全系统


核电厂的任何过程控制系统都保留为安全系统。 核动力装置是专为飞机落在其上而设计的。 安全系统应为反应堆提供紧急冷却,以使由于β衰变而产生的余热不会像福岛核电站那样熔化。 没有安全系统,备用柴油发电机被一波冲走,发生了什么事。 在我们的核电厂中这是不可能的,因为我们的安全系统位于那儿。

安全系统的基础是硬逻辑。

实际上,我们正在调试一种或几种可以组合为功能组算法的控制算法,并且无需借助微处理器就可以将整个故事直接发布到板上,也就是说,我们得到了严格的逻辑。 如果有时需要更换一台设备,其设置或参数将发生变化,并且有必要对其操作算法进行更改-是的,您将必须卸下焊接该算法的电路板并放入新的电路板上。 但这很昂贵,但很安全



以下是破坏保护的三重系统的示例,在该系统中,用于解决实施例中的安全系统的一个问题的算法是三分之二。 四分之三-就像RAID。



技术多样性


首先,使用不同的处理器很重要。 如果我们制作一个跨平台的系统并从运行在不同处理器上的模块中选择一个通用系统,那么如果恶意软件在生命周期的某个阶段(设计,开发,预防性维护)进入系统,则不会立即破坏了所有破坏性技术。



还有一个定量的变化 。 当我们在预算,空间,理解和操作方面尽可能多地种植各种农作物时,从卫星的视野中可以很好地反映该模型,也就是说,我们实现了冗余,并尽可能地复制了系统。



以下是用于基于三重破坏保护系统选择解决方案的示例算法。 基于三个答案中的两个,该算法被认为是正确的。 我们认为,如果其中一个机柜出现故障,我们首先会了解它,其次,其他两个机柜会正常工作。 核电站中这种柜子的整个领域。



我们谈论了硬件,让我们继续进行对每个人都更有趣的事情-软件。

软件。 顶部和脊椎


这就是这些机柜的监视系统。



顶层系统(在底层自动化之后)为操作员和其他感兴趣的服务提供可靠的信息收集,处理和传递信息。 首先,它应该解决主要任务-能够在峰值负载时解决所有问题,因此,在正常操作中,系统的负载可以达到5-10%。 剩余容量实际上是空闲的,并且经过设计,以便在紧急情况下我们可以平衡,分配和处理所有过载。

最典型的例子是涡轮机。 它提供了最多的信息,并且如果它开始不稳定运行,则DDoS实际上会发生,因为整个信息系统都被来自该涡轮机的诊断信息所阻塞。 如果QoS不能很好地工作,则可能会出现严重的问题:运营商根本不会看到一些重要信息。

实际上,一切并不那么可怕。 操作员可以在物理电抗仪上工作2小时,但会丢失一些设备。 为了防止这种情况的发生,我们正在开发新的软件平台。 以前的版本现在可服务于15个在俄罗斯和国外制造的动力装置。



软件平台是一种跨平台的微服务架构 ,由以下几层组成:

  • 数据层是实时数据库。 这很简单-类似于键值,但值只能是两倍。 没有更多的对象存储在此处以完全消除缓冲区溢出,堆栈或其他问题的可能性。
  • 一个单独的数据库,用于存储元数据。 我们使用PostgreSQL和其他技术,原则上可以配置任何技术,因为没有硬实时性。
  • 存档层。 这是一个在线档案(大约一天),用于处理当前信息和报告。
  • 长期存档。
  • 紧急存档 -如果发生事故且长期存档已损坏,将使用黑匣子。 关键指示器,警报,确认警报的事实都记录在其中( 确认表示操作员看到了警报并开始采取措施 )。
  • 脚本语言所在的逻辑层 。 计算核心基于它,在计算核心之后,就像一个模块一样,还有一个报告生成器。 没什么不寻常的:您可以打印图形,提出请求,查看参数如何更改。
  • 客户端层 -允许您基于代码开发客户端服务的节点,其中包含API。

客户端节点有几个选项:

  • 优化录音 。 它开发设备驱动程序,但不是经典驱动程序。 该程序从下游自动化控制器收集信息,进行初步处理,解析所有信息以及下游自动化设备使用的所有协议-OPC,HART,UART,Profibus。
  • 针对阅读进行了优化 -用于构建用户界面,处理程序以及所有后续操作。

基于这些节点,我们正在构建 。 它由使用常规操作系统进行管理的经典可靠服务器组成。 我们主要使用Linux,有时使用QNX。



云被切成虚拟机,容器在某个地方启动。 作为容器虚拟化的一部分,将启动各种类型的节点,这些节点在必要时执行不同的任务。 例如,您可以每天运行一次报告生成器,当一天中所有必要的报告材料准备就绪,虚拟机已卸载,并且系统已准备好执行其他任务时。

我们称我们的系统为Vershok ,是Spine系统的核心-显而易见。


我们认为,网关控制器上具有足够强大的计算资源,为什么不将其功能不仅用于预处理? 我们可以将云和所有边界节点变成雾状,并通过任务(例如识别错误)来加载这些容量。



有时会发生传感器必须校准的情况。 随着时间的推移,读数是浮动的,我们知道它们将按照什么时间表更改它们的读数,而不是更改这些传感器,而是更新数据并进行校正-这称为传感器校准。

我们有一个完整的Fog平台。 是的,它在雾中仅执行有限的任务,但是我们将逐渐增加它们的数量并卸载整个云。



另外,我们有一个计算核心。 我们包含一种脚本语言,可以与Lua,Python(例如PyPy库),JavaScript和TypeScript一起使用,以解决用户界面问题。 我们可以在云内部和边界节点上同样出色地执行这些任务。 每个微服务都可以在任何数量的内存和任何电量的处理器上启动。 他将仅处理当前容量下可能的信息量。 但是,该系统在几乎所有节点上均相同。 它也适合放置在简单的IoT设备上。

现在,该平台从多个子系统获取信息:物理保护级别,访问控制系统,来自摄像机的信息,消防安全数据,过程控制系统,IT基础架构,信息安全事件。

基于此数据,构建了行为分析-行为分析。 例如,如果摄像机未记录他去了操作室,则操作员将无法登录。 或另一种情况:我们发现某些通信通道无法正常工作,而我们修复了此时机架温度已改变,门已打开的问题。 有人进来,打开门,拉出或敲打电缆。 这当然不应该,但是监视仍然是必要的。 有必要描述尽可能多的案例,以便当突然发生某些事情时,我们可以肯定地知道。



上面是所有可运行的设备及其参数的示例:

  • 左侧是常规的Supermicro服务器。 之所以选择Supermicro,是因为它具有铁的所有可能性,因此可以使用家用设备。
  • 右边是控制器,它是我们工厂生产的。 我们完全信任他,并了解那里发生的事情。 在幻灯片上,它已满载计算模块。

我们的控制器与被动冷却一起工作 ,并且从我们的角度来看,它更加可靠,因此我们尝试将最大数量的任务转移给采用被动冷却的系统。 任何风扇都会在某个时刻失效,核电站的寿命为60年,并有可能延长至80年。很明显,在这段时间内将进行定期的预防性维修,将更换设备。 但是,如果您现在使用的是90年代或80年代开始的物体,那么甚至不可能找到一台计算机来运行可以在该计算机上运行的软件。 因此,必须重写和更改所有内容,包括算法。

我们的服务在多主模式下运行,没有单点故障,所有这些都是跨平台的。 节点是自确定的,可以执行热交换,因此可以添加和更改设备,并且不依赖于一个或多个元素的故障。



系统退化之类的事情。 在某种程度上,操作员应该不会注意到系统有问题:处理器模块烧坏了,或者服务器上的电源消失了并且关闭了; 由于系统无法应对,通信通道过载。 这些和类似问题可以通过备份所有组件和网络来解决。 现在我们有了双星和网状拓扑。 如果任何节点发生故障,则系统的拓扑结构允许您继续正常操作。



这些是Supermicro参数(上方)和我们的控制器(下方)的比较,这些参数是我们从基于实时数据库的更新中获得的。 图4和8是副本的数量,也就是说,数据库实时维护所有节点的当前状态-这些是多播和实时的。 在测试配置中,大约有一千万个标签,即信号变化的来源。

Supermicro显示平均为7 M / s或5 M / s,副本数增加。 随着节点数量的增加,我们正在努力不失去系统的功能。 不幸的是,当有必要处理设置和其他参数时,我们会随着节点数量的增加而损失速度,但是节点越多,损失就越少。

我们的控制器上 (在Atom上),参数要小一个数量级。

要创建趋势,将为用户显示一组标签。 下面是操作员的触摸式界面,他可以在其中选择选项。 每个客户端节点都有一个数据库副本。 客户端应用程序开发人员使用本地内存,不考虑通过网络同步数据,而是通过API进行获取,设置。



为过程控制系统开发客户端界面并不比开发站点复杂。 以前,我们使用C ++ Qt在客户端上进行实时争夺。 现在我们拒绝了它,并在Angular上完成了所有操作。 现代处理器使您可以保持此类应用程序的可靠性。 尽管内存是浮动的,但网络已经足够可靠。

确保应用程序一年运行而不重启的任务不再重要。 所有这些都打包在Electron中,并且实际上提供了平台独立性,即可以在平板电脑和面板上运行界面的能力。

焦虑症


警报是系统中出现的唯一动态对象 。 系统启动后,将固定整个对象树;无法从此处删除任何内容。 也就是说,CRUD模型不起作用,您只能标记“标记为已删除”。 如果您需要删除标签,则只需对其进行标记并向所有人隐藏即可,但是不会删除它,因为删除操作很复杂,并且可能会破坏系统状态及其完整性。

警报是当来自特定设备的信号参数超出设置时出现的对象。 设置是值的警告上下限:紧急,严重,超严重等。 当参数落入特定比例值时,将出现相应的警报。

发生警报时出现的第一个问题是向谁显示该消息。 向两个操作员显示警报? 但是我们的系统是通用的,可能会有更多的运营商。 在核电厂,由于设备不同,因此涡轮机和反应堆专家的数据库“略有不同”。 当然,很显然,如果信号水平超出了反应堆隔室的限制,那么领先的反应堆控制工程师将在涡轮机中-在涡轮机中看到这一点。

但是,假设有很多操作员。 . - , . real-time , , . . , “” .

, . - “” – . , , , , “” . , . : , . , .



, , .



  • – ,
  • – ,
  • — ,
  • c – .

– .

. , .





.



, , , , .



– , . SCADA/HMI , , , – , , . , : «, ! Illustrator, Sketch – , SVG». SVG . , .

, . API, . , , , . , , . , , , , – . , , , , .



, . , . Data Lake. , multitenancy (, ). .

, . , , , .

, : . , 10 100 , – .



, . , .



— . , , . – , : -1200 10 .

, , , , , - , , .… .

. . 5 : , , , . .

:

  • - ( CPU);
  • Computational Fluid Dynamics (CFD) ( GPU).

, . - , , ( ). .

60 , ( , ). KPI , .



.



– , – .

. – . , , , – . VR- , .



, , , . ( ) — , - . , , . — ( ), – ( ), .

, , — . . . .

ITER . , – . , , . , !

InoThings Conf 4 . IIoT , . . , .

Source: https://habr.com/ru/post/zh-CN439510/


All Articles