一种适用于核电站应急指挥系统的软件架构

北京广利核系统工程有限公司 由玉伟，傅春霞，胡俊，赵慧丽

1 概述

核事故是指大型核设施（例如核燃料生产厂、研究堆、核电厂、核动力舰船及后处理厂等）发生的意外事件，可能造成厂内人员受到放射损伤和放射性污染。严重时，放射性物质泄漏到厂外，污染周围环境，对公众健康造成危害。

核事故应急是针对可能发生的核事故，进行控制、缓解、减轻核事故后果而采取的紧急行动。

核电站核事故应急涉及国家、地方政府、核电站等各个层面的核应急单位，为了将各级单位完善地整合起来，实现不同应急状态下有效地应急联动与应急处理，国家从法律、法规、导则、国标等方面进行了详细的规定。

核电站是核事故处理的主体，当事故发生时，往往面临时间紧，任务重的情况，为了更加有效地对事故进行处理，电站需要建设自己的应急系统。设计良好的核电站应急系统，能够紧密贴合应急计划，有效接收、存储、分析、处理和发布来自不同区域的核电站的各种信息，并在事故突发期间快速形成准确的应急指挥指令，为应急管理和指挥决策提供强有力的技术支持，提高应急管理和指挥决策的科学性和时效性。如何设计一个良好的架构模型，是系统设计的关键问题。

2 业务模型

依照《核电厂核事故应急管理条例（HAF002）》以及《GB-T 17680核电厂应急计划与准备准则》，核电站核事故应急主要处理过程概括来说为：

当应急情况发生时，核电厂应按照应急计划中的基本程序，立即启动应急响应活动。在应急响应过程初期，判断应急响应等级，经相关部门批准，立即启动应急响应，应急过程中，间隔一定时间根据所搜集数据重新评估应急状态等级，并向上级报告，并在经过批准后，实施相应应急预案。当核事故已得到控制，而且几乎恢复到安全状态，并且满足相应条件，可以终止应急响应。应急终止后，需要对应急过程中的资料进行整理、总结及评价，必要时修订国家核应急预案。应急状态终止后，各有关部门和单位按有关规定及时做出书面总结报告。

当发生严重事故，需要进入场外应急（总体应急）状态时，核电厂营运单位向省核应急组织及时提出进入场外应急状态的建议；省核应急组织向国家核应急协调委提出请求批准进入场外应急状态报告；国家核应急协调委审批进入场外应急状态。在事故情景十分危急时，省核应急组织可先决定进入场外应急状态，而后立即向国家核应急协调委报告。国家核应急协调委及时向国务院报告进入场外应急状态，必要时请求协调应急响应。

针对上述分析，核电站应急响应过程的业务模型可以分为三个部分，如图1所示。

图1 应急响应过程业务模型

第一部分：应急信息监督，主要是数据通讯、数据存储和管理、人机界面显示等功能。

第二部分：应急辅助分析，主要涉及到电站事故分级、堆芯状态判断、操作干预水平判断、环境事故后果评价判断等专业的算法模块，各个模块之间需要互相通讯。

第三部分：应急响应支持，主要涉及核事故状态下的应急干预行动处理。

但是对于不同的核电站，应急业务还具有如下特点：

不同核电站具有不同的应急计划，系统所需功能及功能实现细节并不完全相同；

不同核电站具有不同的应急组织架构，使用人员数量及角色不确定；

应急系统通常用作数据采集与监控，仅在应急情况或应急演习时才启动响应；

3 技术环境

应急系统的技术环境有如下特点：

系统需要与核电站众多第三方系统进行通讯，这些第三方系统实时性要求不同，程序接口不同，数据类型多种多样；

系统常常需要集成一些专家系统，如堆芯损伤、机组诊断等，并与其进行数据交互；

系统通常运行在应急专用网，同时与核电站外部网、厂内专用数据网络（如生产网和KNS网等）进行通信；

系统一般规模不大，大多为几十台操作站（秦山约为20台、红沿河约30台），网络通常与厂级办公网隔离；

系统的软件架构设计必须针对上述特点进行考虑。

4 软件架构五视图

应急软件架构是实现功能需求的关键，多视图方法是业界广泛认同的一种架构设计思路，具体的多视图方法种类繁多：

SEI的3视图法：涉及视图为模块视图、组件-连接器视图、分配视图；

西门子的4视图法：涉及视图为概念视图、模块视图、代码视图、执行视图；

RUP的4+1视图法：涉及视图为用例视图、逻辑视图、开发视图、进程视图、物理视图；

其他…

本文采用的五视图方法是由温昱先生基于Philippe Kruchten于1995年提出的4+1视图方法而来[5]，包括五个方面，如图2所示。

逻辑架构：根据功能及非功能需求，对系统进行划分。

物理架构：描述系统软硬件之间的关系。

运行架构：描述系统软件的控制流。

数据架构：描述系统软件的数据存储方式。

开发架构：描述系统软件最终形成的软件单元模块，采用的编译语言及依赖关系。

4.1 逻辑架构

应急系统在不同的核电站常常要面对不同种类的操作系统，不同的第三方应用软件，不同的业务流程以及不同的组织架构。一个设计良好的系统应该能对这些变化做出快速的反应。

三层SOA（面向服务架构）具有松耦合的特性，可以按照模块化的方式来添加新服务或更新现有服务，以解决新的需要，并可以支持把企业现有的或已有的应用软件作为服务，能够比较好地满足应急系统需求，如表1所示。

SOA架构可以利用JAVA平台和.NET平台下的Web service或消息中间件的方式实现。

（1）JAVA平台

JAVA平台下实现SOA的技术有：JMS、EJB，JCA、RM I以及JBI模型，利用这些技术结合，可以在JAVA平台下开发出灵活强大的SOA架构，如图3所示。

（2）.NET架构

图3 JAVA平台下的SOA架构

微软对SOA的支撑技术有ASP.net、Enterprise Service、WCF等，其中WCF是最优的技术。它是由微软发展的一组数据通信的应用程序开发接口，是.NET框架的一部分，由.NET Framework3.0开始引入。WCF是一个统一的程序开发模型，对于数据通信提供了最基本最有弹性的支持。

从功能角度看，WCF可以看作是ASMX，.NET Remoting，Enterprise Service，WSE，MSMQ等技术的并集。利用WCF，可以解决包括安全、可信赖、互操作、跨平台通信等需求。开发者不需要再去分别了解.NET Remoting，ASMX等各种技术。WCF具有以下特点：

统一性：WCF是对于ASMX，.Net Remoting，Enterprise Service，WSE，MSMQ等技术的整合。由于WCF完全是由托管代码编写，因此开发WCF的应用程序与开发其它的.Net应用程序没有太大的区别。

互操作性：WCF最基本的通信机制是SOAP，只要支持标准的Web Service，可以跨进程、跨机器甚至于跨平台的通信，例如J2EE应用服务器。

安全与可信赖：添加到SOAP消息中，以用于用户认证，数据完整性验证，数据隐私等多种安全因素。

兼容性：WCF充分地考虑到了与旧有系统的兼容性。安装WCF并不会影响原有的技术如ASMX和.Net Remoting。即使对于WCF和ASMX而言，虽然两者都使用了SOAP，但基于WCF开发的应用程序，仍然可以直接与ASMX进行交互。

从技术的角度讲，JAVA和.NET没有优劣之分，根据Evans数据公司的调查结果，这两种技术在SOA总用量中“实际上不分胜负”，且采用JAVA和采用.NET开发的SOA均能够实现跨平台和跨系统的支持。

图4为基于.NET的SOA架构技术方案。

4.2 物理架构

图4 基于.NET的SOA架构技术方案

物理架构最重要的就是解决系统的部署问题，对于不同电站来说，其设备、网络等要求往往也不相同，例如有的要求双网通讯，有的要求单网通讯，有的要求服务器热备，有的要求服务器冷备等，基于三层SOA架构，一个典型的部署如图5所示：

图5 基于三层SOA架构的典型

每部分针对的功能如表2所示：

4.3 运行架构

基于三层SOA架构的应急系统活动流图如图6所示：

表2 典型部署中每部分针对的功能

图6 基于三层SOA架构的应急系统活动流程图

系统流程为：

（1）工程师组态

系统在工程师站进行数据库、算法、流程图等的配置，并将配置结果下装到web服务器与数据服务器。

（2）系统服务启动

web服务启动

web服务主要包含接口程序以及相关服务程序，部署在web服务器，系统启动后，IIS服务启动，服务端口开启监听，随时处理来自于客户端的请求。

数据服务启动

数据服务分关系数据库服务和实时数据库服务，部署在数据服务器，系统启动后，启动相关服务程序，接收客户端以及通讯程序的请求。

通讯服务启动

通讯服务主要负责与应急支持系统通讯，部署在通讯服务器上，系统启动后，与应急支持系统持续进行通讯，获取相关数据。

（3）客户端应用

客户端提供主要的人机界面应用程序，其应用过程如下：

在浏览器中输入地址，打开登录窗口，输入用户名和密码，web服务通过监听来自客户端的请求对其进行处理，如果是域用户，则连接域服务器进行验证，否则登录验证服务程序从数据库中读取数据，对用户名和密码进行验证，将验证结果返回客户端。

通过验证后，应急用户可以进行应急设施设备管理、应急组织管理、应急演习管理、应急培训管理、应急文档管理、应急行动水平查询及应急状态辅助判断操作，管理员可以进行维护及设置工作。

操作完成后，用户退出。

4.4 数据架构

数据架构要解决的是数据的存储问题，对于应急系统来说，它分为实时数据与非实时数据，需要根据情况分别保存在实时数据库与关系数据库。

4.5 开发架构

在开发架构层面，需要解决从用户需求到系统开发技术选择的问题，主要内容如下：

“逻辑职责”与“程序单元”的映射：将用户的业务需求分配到相应的程序单元上。

开发技术选型：根据业务需求及组织现状，确定开发语言、开发工具等。

“程序单元”间关系，确定系统架构，对公共部分进行整合，保证整体最优。

5 结束语

核电站应急系统在设计时面临接口众多，数据类型复杂，业务流程各有不同等特点，广利核公司基于上述架构设计方法设计的Em InfoSys应急指挥系统，具有易于组态、易于维护、易于修改、操作简便等优点，较好地满足了不同核电站的应用需要，并已经应用到福清核电站，还将应用到海阳、台山等，为应急状态下应急管理以及指挥决策提供有力的支持。

[1] HAF102,国家核安全局核电站设计安全规定 [S].

[2] HAF002/01,国家核安全局核电站营运单位的应急准备和应急响应[S].

[3] HAF002,国务院核电站核事故应急管理条例[S].

[4] GB-T 17680,核电厂应急计划与准备准则[S].

[5] 温昱,软件架构设计[M].北京:电子工业出版社 2007.