1、河南省食品药品监督管理局可视化应急指挥建设方案2022年10月10日北京华宇信息技术有限公司北京华宇信息技术有限公司BEIJING THUNISOFT INFORMATION TECHNOLOGY CORPORATION LIMITED河南省食药监可视化应急指挥建设方案目 录第一章 项目概述11.1 项目建设背景11.2 项目建设目标21.3 项目建设内容和范围2第二章 需求分析42.1 业务需求分析42.1.1 应急管理组织结构42.1.2 总体业务内容42.1.3 事件接报62.1.4 监管研判62.1.5 突发事件应急处置62.1.6 预测预警62.1.7 舆情监测处理62.2 技术需求
2、分析62.2.1 技术目标62.2.2 数据安全性要求72.2.3 系统技术路线要求72.2.4 可扩展性要求72.2.5 易用性要求72.3 安全需求分析72.3.1 物理安全需求82.3.2 计算环境安全需求82.3.3 区域边界安全需求92.3.4 通信网络安全需求9第三章 系统总体规划103.1 总体设计原则103.2 总体设计思路113.3 总体框架设计123.4 系统架构设计133.5 应用功能总体设计153.6 硬件部署总体设计163.7 关键技术路线选择173.7.1 基于面向服务的架构设计173.7.2 分层设计的思想173.7.3 采用J2EE开发集成框架203.7.4 遵
3、循XML标准的数据交换213.7.5 基于Web Services的接口集成213.7.6 移动互联技术22第四章 应急管理系统建设234.1 应用系统功能总体设计234.2 研判与预警子系统234.2.1 综合研判234.2.2 预警预测244.2.3 能力评估254.3 应急处置子系统254.3.1 信息接报264.3.2 指挥调度264.3.3 事件处置264.3.4 信息发布264.3.5 总结提高264.4 应急保障子系统264.4.1 应急资源保障264.4.2 监测数据保障274.4.3 地理信息保障274.5 应急管理子系统274.5.1 事件管理274.5.2 预案管理284
4、.5.3 值班管理284.6 查询统计子系统294.6.1 综合信息查询294.6.2 综合统计294.7 系统配置与管理子系统294.7.1 用户管理304.7.2 权限管理304.7.3 系统配置304.7.4 日志管理304.7.5 数据维护与管理30第五章 多媒体可视化协同指挥平台建设315.1 建设依据315.2 总体设计315.3 调度指挥中心后台设备建设设计325.3.1 多媒体协同平台建设335.3.2 高清集中解码建设345.3.3 高清视音频存储建设345.4 移动端设备建设345.4.1 可视化车载建设设计355.4.2 手持终端建设设计36第六章 调度指挥中心基础环境建
5、设396.1 建设依据396.2 显示大屏建设396.2.1 大屏显示系统396.2.2 中央控制系统建设406.2.3 数字讨论系统406.2.4 会议室扩音系统406.2.5 调度指挥中心效果样式图41第七章 主要支撑环境建设427.1 业务协同与共享交换平台427.2 地理信息平台437.3 视频会议平台437.4 视频监控平台447.5 工作流平台447.6 内容管理平台467.7 商业智能平台4747第一章 项目概述1.1 项目建设背景食品药品安全是重大民生问题，关系到广大人民群众的身体健康和生命安全，关系到经济健康发展和社会稳定。近几年，随着食品药品安全事件频发，如何加强食品药品安
6、全监管，有效解决食品药品安全突发事件，保障人民群众的生命健康，成为监管部门工作的重中之重。为建立健全应对食品药品安全事故运行机制，有效预防、积极应对食品药品安全事故，高效组织应急处置工作，最大限度地减少食品安全事故的危害，保障公众健康与生命安全，维护正常的社会经济秩序，国家先后出台一系列政策文件。2007年8月，第十届全国人大代表大会通过中华人民共和国突发事件应对法，提出了建立统一领导、综合协调、分类管理、分级负责、属地管理为主的应急管理体制。同年9月，国务院应急管理办公室出台国家应急平台体系技术要求(试行)，明确了国家应急平台体系建设结构，提出构建“国务院应急平台-省级应急平台-市（地）级应
7、急平台-县（市）级应急平台”四级应急联动平台，并构建部门应急平台，要求与同级政府应急平台和上级部门应急平台之间形成信息联动。2011年8月，国家食品药品监督管理局颁布修订了药品和医疗器械安全突发事件应急预案（试行），同年10月，国务院修订颁布国家食品安全事故应急预案，两项预案对于针对食品药品安全应急体系建设，从组织体系、监测预警、应急响应、信息发布、善后总结等方面提出了详细要求。随着新的食品安全法、药品管理法和医疗器械监督管理条例的修订颁布，国家对食品药品安全应急管理体系建设提出了政策指导完善意见。为了加强全省食品药品安全监管，有效解决食品安全突发事件，2013年河南省政府根据国务院关于地方改
8、革完善食品药品监督管理体制的指导意见(国发201318号)精神,设立河南省食品药品监督管理局（以下简称省食药监局），负责全省食品、药品、医疗器械、保健食品、化妆品(以下统称为食品药品)的监督管理工作。食药监局内设应急管理处，负责推动全省食品药品安全应急体系建设。根据河南省人民政府办公厅颁发河南省食品药品安全保障体系建设规划(20142016年)文件精神，全省要“强化食品药品应急救援体系建设。提高应急能力和水平,完善食品药品安全事故应急预案,组织开展应急演练,依托省级应急指挥信息系统,建立省、市、县分级负责、统一指挥、协调一致的食品药品安全事故应急救援体系;完善应急指挥协调和快速反应机制,提高应
9、急指挥决策和应急处置能力,提升事故响应、现场处置、医疗救治等应急处置水平。加强应急装备配备,强化应急风险评估、应急检验检测等技术支撑。加强应急队伍建设,形成一支以食品药品安全监管队伍为基本力量,以各级疾病预防控制和医疗救治队伍为专业力量的应急救援队伍。制订食品药品安全事故调查处理办法,进一步规范事故调查处理工作程序。组建事故应急处置专家咨询委员会,发挥事故核实、级别核定、事故隐患预警及应急响应等技术咨询作用”。省食品药品监管局积极响应落实省政府食品药品安全保障体系三年建设规划， 2016年2月印发河南省食品药品监督管理局2016年工作要点，指出要增强应急管理能力。建立横向协同、纵向贯通、运转高
10、效的应急管理组织体系，完善信息共享、协作联动机制。修订相关专项和单项预案，完善应急预案体系。各级食安办牵头组建食品安全突发事件处置专业队伍；以监管执法人员、检验检测人员和现场调查人员为主，组建省级食品药品安全应急骨干机动队伍和应急专家队伍；督促企业以食品安全员和执业药师为主，组建企业应急队伍。开展示范性应急演练，完善统一指挥、步调一致的应对处置机制。建设食品药品安全重大信息网络直报系统，加强舆情监测和信息研判，实现早预警、早处置。完善区域间、部门间信息通报机制，及时分析会商舆情信息。为了充分适应河南省食药监局省市县的多级组织结构，加强组织引导全省食品药品安全事故应急处置和调查处理工作，有效整合
11、调度全省食品药品安全资源，提高对全省食品药品安全的综合保障能力以及对突发事件的应对水平，推动全省食品药品安全事故应急体系建设，根据国务院和河南省政府相关政策文件要求，结合河南省食品药品监督管理局具体业务职责以及工作要点，特提出本项目建设方案。1.2 项目建设目标本项目构建全省食品药品安全可视化应急指挥平台，实现对食品药品安全突发事件处理的全面管理，全面掌握事故信息，同时实现面向应急车辆、单兵终端以及相关人员和设施等资源的全方位调度，有效提升全省对食品药品安全应急指挥保障能力和突发事件应对水平，提高综合调度的速率和效率。1.3 项目建设内容和范围食药监可视化应急指挥平台是以融合通信、移动互联等先
12、进技术为支撑，以应急管理流程为主线，覆盖事前应急防控和事后应急处置全环节应急管理链条，是软硬件相结合的食药监应急保障系统以及实施应急预案的工具，在一个平台上统一实现食药监应急处置与可视化调度指挥的无缝集成。在本项目中，建设内容主要包括两大部分：l 第一部分是应急管理系统建设；l 第二部分是多媒体可视化协同指挥平台建设。其中，多媒体可视化协同指挥平台建设又包括应急指挥中心基础设施及相关硬件运行环境的建设、多媒体融合通信核心后台与前端车辆和单兵等应急装备的建设。通过项目建设，实现了食药监事前应急防控和事后应急处置的全环节管理和可视化指挥，强化了食品药品安全突发事件的全流程一体化管理。第二章 需求分
13、析2.1 业务需求分析2.1.1 应急管理组织结构河南省食品药品监督管理局统一负责全省行政区域内的食品药品安全事件应急管理工作。对于应急事件的处理以及日常的管理，主要由河南省食药监局应急管理处牵头承担。河南省食药监局应急管理处工作职责：（1）组织拟订食品药品安全应急体系建设规划，推动应急体系建设和能力建设。（2）组织拟订食品药品安全应急管理工作制度，并监督实施。（3）组织编制食品药品安全事故应急预案，开展应急培训和演练。指导食品药品生产经营企业开展应急管理工作。（4）组织开展食品药品安全信息搜集和舆情监测，指导协调核查、应对工作。（5）建立食品药品重大信息直报制度，并监督实施。（6）核查领导批
14、示、媒体披露和公众举报的食品药品安全事故，及时报告或协调回应。（7）组织协调重大食品药品突发事件、安全事故的应急处置和调查处理工作，监督事故查处落实情况。（8）负责建立食品药品应急管理专家组，开展食品药品安全舆情和重大事故案例研究，分析相关风险趋势及突发事件发生态势，提出对策建议。（9）协调建立重大药品不良反应、重大医疗器械不良事件相互通报机制和联合处置机制。（10）协调建立完善应急检验检测体系，提升应急检验检测能力。（11）指导全省系统应急管理相关工作。（12）承办省局交办的其他事项。2.1.2 总体业务内容根据目前应急处的工作职责，应急管理总体业务情况为：食品药品突发事件分为7种，包括食物
15、中毒事件、食品污染事件、食源性疾病事件、药品事件、化妆品事件、医疗器械事件以及其他事件。应急处业务主要分为3部分，食品药品安全应急调度指挥、应急保障（包括医药储备管理）、围绕应急指挥调度的辅助业务，辅助业务包括应急预案、模拟演练、重大活动保障、宣传培训、考核评价等。食品药品安全应急调度指挥业务为应急管理的核心，包括事件接报、监管研判、突发事件应急处置、预测预警、舆情监测处理。应急保障是为了保证在应急事件发生时应急物资及设备的正常使用进行的日常采购、维护工作。2.1.3 事件接报在事件接报环节，河南省食药监局及市局需要接收食品药品安全事件信息，在接收多渠道信息后，需要对信息进行核实、汇总整理，并
16、根据信息来源不同进行分类，并根据不同来源的事件以及事件的程度进行处理。2.1.4 监管研判省食药监局和市局在接到事件信息后，通过提取事件模型，结合相关知识，组织业务专家进行初步研判，分析事件性质，确定事件等级，提出预警、控制和纠正措施，最后形成会议纪要，编发事件研判报告，供决策部署食品药品事件防控工作参考。以事件信息为基础，通过交流、分析、研究的形式，判断食品、药品领域的事件因素、事件程度，提出防控措施、消除安全隐患。基于监管研判的各类结果数据，提供信息的查询和研判数据的统计分析。2.1.5 突发事件应急处置突发事件处置实现对突发食品药品安全时间的应急处置管理，包括先期处置和食物中毒突发事件处
17、置、食品污染突发事件处置、食源性疾病突发事件事件、药品突发事件处置、医疗器械突发事件处置、化妆品突发事件处置。2.1.6 预测预警预测预警实现食品药品预警级别划分管理和预警信息发布取消管理。以食品安全预警级别管理为例，按照食品安全突发事件发生的紧急程度、发展势态和可能造成的危害程度分为一级、二级、三级和四级，分别用红色、橙色、黄色和蓝色标示。2.1.7 舆情监测处理食品药品舆情信息的分析研判由应急管理处组织，各相关单位要对舆情信息进行初步分析和研判。按照敏感程度、严重程度、紧急程度、影响范围等因素，将舆情信息划分为蓝色、黄色、橙色、红色四个警示级别。普通食品药品安全舆情信息按照正常公文程序流转
18、。2.2 技术需求分析2.2.1 技术目标1.确保平台实现7*24小时不间断运行，保证系统的稳定性、易用性。2.系统最大单表记录数至少支持1000万条。3.系统应支持至少2000用户的同时并发在线。4.系统数据库应支持至少高达5000G的数据容量。5.对千万级的数据简单查询速度小于10秒。6.对千万级的数据复杂查询速度小于30秒。2.2.2 数据安全性要求由于本项目数据的安全性非常重要，安全机制要支持集中和分散用户和安全管理。每个用户可以承担多个角色，而且每个角色都可以有多个控制菜单、页面、操作、字段和数据的访问的多个权限列表。安全机制应具备以下要点：应用访问安全（菜单安全）：每个角色对应一组
19、菜单项、页面和操作。每个用户都可以分配到一个或多个执行各种功能的角色。数据备份恢复：平台应支持前台手工及定时数据备份的功能，数据恢复的功能。处理安全：可以利用进程调度程序将处理定义分配给各种处理组。可以利用安全管理器授权用户访问或对其施加限制。2.2.3 系统技术路线要求要求采用J2EE标准的技术路线为主体技术，要求采用基于J2EE架构的开发平台，B/S结构，3层或多层的开发模型。2.2.4 可扩展性要求系统应适应部门的变更及扩展而不需要对程序做相应的修改。系统应能适应后续应用的添加，而不至于程序大量的修改或推翻重来。随着用户数的增长及功能应用的增长，软件系统通过硬件性能的调整而保持相对的稳定
20、性，维持正常的运行。2.2.5 易用性要求系统软件设计应充分考虑各个用户类和特征，提供适合各级操作人员的简便操作界面，采用通用的柜员操作平台，操作系统友好性强， 能够做到操作员通过简单的培训甚至自学就能掌握，具体有如下要求：系统应能支持方便的全键盘操作，任何按钮点击的操作或光标转移的操作都可以通过键盘来完成。要支持字段提示，可定制在线用户文档，用户可以在使用的任何时候获得及时帮助。2.3 安全需求分析根据信息安全等级保护二级的要求，为达到等保二级的标准，需要满足以下安全需求：2.3.1 物理安全需求物理安全是保护计算机网络设备、设施以及其他媒体免遭地震、水灾、火灾等环境事故以及人为操作失误或错
21、误及各种计算机犯罪行为导致的破坏过程。等保二级“物理安全”基本规定要求涉及的方面包括环境安全（防火、防水、防雷击等）设备和介质的防盗窃防破坏等方面。具体包括：物理位置的选择、物理访问控制、防盗窃和防破坏、防雷击、防火、防水和防潮、防静电、温湿度控制、电力供应和电磁防护等十个控制点。目前，在物理安全方面，食药监局的信息化基础设施的物理位置分别位于三个专业机房中，中环、槐柏树街机房为市政府IDC机房、已建成的大观园机房是按照IDC标准机房建设，因此满足上述要求。在通盘考虑安全风险时，应优先考虑物理安全风险。保证网络正常运行的前提是将物理层安全风险降到最低或是尽量考虑在非正常情况下物理层出现风险问题
22、时的应对方案。2.3.2 计算环境安全需求计算环境是包括服务器、终端/工作站等在内的计算机设备在操作系统及数据库系统层面的安全。终端/工作站是带外设的台式机与笔记本计算机，服务器则包括应用程序、网络、web、文件与通信等服务器。主机系统是构成信息系统的主要部分，其上承载着各种应用。计算环境安全需要从入侵防护、安全加固、病毒防范、安全审计几方面进行安全需求分析。身份鉴别需支持用户标识和用户鉴别，用户注册和登录系统时，需要强化管理身份鉴别；访问控制需要依托防火墙对服务器主机访问控制；服务器主机安全审计需要采用安全审计系统；需要部署防病毒系统实现对服务器主机恶意代码防范。身份鉴别：需要考虑主机和应用
23、两个方面。访问控制：需要考虑主机和应用两个方面。系统审计：需要考虑主机审计和应用审计两个方面。入侵防范：需要考虑主机操作系统的安装、使用和维护，防范针对系统的入侵行为。恶意代码防范：需要部署恶意代码防范软件进行防御，同时保持恶意代码库的及时更新。软件容错：需要提供足够的冗余信息和算法程序,使系统在实际运行时能够及时发现程序设计错误,采取补救措施。 数据安全：需要采取措施保证数据在传输过程中的完整性以及保密性，以及保护鉴别信息的保密性。备份与恢复：需要对关键数据建立数据备份机制，对网络的关键设备、线路均需进行冗余配置。资源合理控制：需要考虑主机和应用两方面。2.3.3 区域边界安全需求区域边界的
24、安全需求主要包括：边界访问控制、边界完整性检测、边界入侵防范以及边界安全审计等方面。边界访问控制：需要考虑各类边界的访问控制，对进出安全区域边界的数据信息进行控制，阻止非授权及越权访问。边界完整性检测：需要对内部网络中出现的内部用户未通过准许私自联到外部网络的行为进行检查，维护边界完整性。边界入侵防范：需要考虑外部网络针对信息系统的各种攻击，如病毒、木马、间谍软件、可疑代码、端口扫描、DoS/DDoS等，实现对网络层以及业务系统的安全防护。边界安全审计：在安全区域边界需要建立必要的审计机制，对进出边界的各类网络行为进行记录与审计分析。2.3.4 通信网络安全需求通信网络的安全需求主要包括：网络
25、结构安全、网络安全审计、网络设备防护、通信完整性与保密性等方面。网络结构安全：需要考虑一定的冗余性，带宽能够满足业务高峰时期数据交换需求，并合理的划分网段和VLAN。网络安全审计：需要进行基于网络行为的审计，以利于规范正常的网络应用行为。网络设备防护：需要考虑交换机、防火墙、入侵检测设备等网络设备自身的防护。通信完整性与保密性：需要确保信息内容在发送、接收及保存的一致性，并在信息遭受篡改攻击的情况下，应提供有效的察觉与发现机制，实现通信的完整性。第三章 系统总体规划3.1 总体设计原则l 实用性原则在尽量满足业务功能需求的前提下，适应各业务角色的工作特点，做到简单、实用、人性化，具有良好的人机
26、交互界面。l 先进性原则本项目在进行设计开发时，充分考虑一定时期内业务的增长和变化，在充分考虑技术上先进性的同时，尽量采用成熟技术，保证系统在具备先进性、前瞻性、扩充性的同时，具有良好的稳定性、可扩展性和安全性。l 高效性原则考虑用户数量庞大、数据量庞大，在对本项目信息系统进行设计时，确保系统运行的高效率和稳定运行，系统功能的响应时间短，处理速度快。l 安全性原则设计时，要考虑多用户接入、互联网接入的安全可靠性，确保系统可靠稳定运行。l 可伸缩性原则充分考虑将来业务和功能变化，采用科学合理的结构，在实现与现有系统无缝连接的基础上，为今后系统扩展和集成留有扩充余量。另外，确保当系统容量发生变化时
27、，应能通过在横向和纵向的各个层次的扩充，保证系统合理的响应时间和吞吐量。3.2 总体设计思路图 1 总体设计思路图本项目的总体建设思路是将覆盖事前应急防控和事后应急处置的全环节“应急”建设，与采用融合通信和移动互联技术的多媒体可视化协同“指挥”建设，通过“应急预案”将两部分紧密结合为统一的整体，在一个平台上统一实现食药监应急处置与可视化调度指挥的无缝集成。建设以“应急”和“指挥”两大部分建设为核心，其中，“应急”是指应急管理系统应用软件，其功能主要包括应急防控、应急研判、应急处置、应急监测和应急预警等几方面；“指挥”是指采用融合通信和移动互联技术的多媒体可视化协同指挥平台，其功能主要包括视音频
28、实时通信、视频会议、视频监控、多媒体协同指挥、资源定位跟踪等几方面。应急管理系统应用软件生成并管理应急预案，并通过多媒体可视化协同指挥平台实现应急预案的具体执行；协同指挥平台在实践中获取的数据和资料等，可以返回到应急管理系统，成为预案更新升级的重要依据。方案独创性地将事前应急防控和事后应急处置全环节应急管理，与多媒体可视化协同指挥结合起来，将结构化业务数据和视音频等多媒体非结构化数据整合起来，最终实现全环节、全融合、全数据和全接入的覆盖，从综合调度指挥层面实现了各类资源的统一展示、统一分析、统一管理、统一调度和统一控制，从而创新性地优化了食药监应急调度和远程指挥的工作模式，实现了食品药品应急指
29、挥工作的变革，打造了全方位、立体化的食药监应急调度指挥一体化平台。3.3 总体框架设计项目建设系统总体框架图如下所示：图 2 项目总体框架图结合食品药品安全应急调度指挥、应急保障（包括医药储备管理）、围绕应急指挥调度的辅助业务等三部分应急业务，本项目可视化应急指挥建设涉及的食药监应急接报的数据来源主要包括上级领导的批示的事件信息；内部部门上报的事件信息；不良反应监测中心的不良反应监测到的事件信息；投诉举报中心收到的事件信息；食品药品监督执法处室（食品生产监管处、食品流通监管处、食品市场监管处、餐饮服务监管处、药品生产监管处、医疗器械注册和监管处、药品医疗器械市场监管处、保健食品化妆品注册和监管
30、处）的日常监督执法过程中发现的事件信息；风险监测处的监测到的事件信息；国家食品药品监督管理总局、其他省市以及本市有关部门通报的事件信息、其他渠道得到的事件信息；舆情相关部门（市局办公室、网监中心、食品药品安全监控和风险评估中心、药品检验所、医疗器械检验所、药包材检验所、药品不良反应监测中心、医药信息研究所、投诉举报中心等）监测到的舆情信息。食品药品突发事件分为七种，包括食物中毒事件、食品污染事件、食源性疾病事件、药品事件、化妆品事件、医疗器械事件以及其他事件，每种事件的应急处置工作不同。本项目需要实现对全省范围内食药监上述七类应急事件的数据采集和数据共享，通过河南省食药监应急接报数据交换平台的
31、数据整合和交换共享，归集到我省食药监局，汇集形成河南省食药监应急指挥信息库中，分别为全省各级食药监局领导和基层现场工作人员提供服务。同时根据我省实际需要，面向国家食品药品监督管理总局将食药监应急指挥相关事件及信息上报到国家食药监总局事务直报、不良反应监测等平台，面向我省政府，实现与我省政府应急平台的对接，为国家食药监总局和我省政府的应急指挥服务。3.4 系统架构设计本项目的系统架构如下所示：图 3 总体技术框架图系统从下至上主要分为五个层次，分别为基础设施层、数据层、应用支撑层、业务应用层和展现层。设施层是在充分利用我省食药监局已有的网络和基础设施环境的基础上，通过增加多媒体可视化协同指挥平台
32、端和终端设备和相关安全防护系统来满足本项目各系统的运行需求。数据层主要是通过河南省食药监应急接报数据交换平台采集、共享交换过来的相关信息，构成了食药监基础信息库、食药监应急预案库、食药监应急资源库和食药监应急管理库的四大主题库；在主题库的基础上，根据共享需求，构建对各单位服务的共享库；此外还包括数据管理相关的元数据库。应用支撑层主要是支撑河南省食药监应急接报数据交换平台所需的支撑模块和接口，主要包括交换平台、权限管理、门户组件、内容管理等，以及其他的支撑平台。应用层由应急管理系统应用软件和多媒体可视化协同指挥平台等两大类应用组成。展现层主要是利用河南省食药监可视化应急指挥工作平台为全省各级食药
33、监局领导和基层现场工作人员提供服务。同时根据我省实际需要，面向国家食品药品监督管理总局实现信息上报，面向我省政府实现与我省政府应急平台的对接，为国家食药监总局和我省政府的应急指挥服务。此外还包括河南省食药监可视化应急指挥平台的三大体系建设，即技术标准规范体系、信息安全保障体系和运行维护保障体系的建设。3.5 应用功能总体设计本项目应用功能总体设计如下图所示：图 4 应用功能总体设计图根据河南省食品药品安全保障体系建设规划(20142016年)（豫政办2013105号）文件精神，结合河南省食药监局应急处具体业务职能需要，按照预防为主、预防与应急相结合的原则，以统一领导、综合协调、分类管理、分级负
34、责、属地管理为指导方针，食药监可视化应急指挥系统整合全省食药监局食品药品安全资源，从食品药品安全突发事件事前预测预警、事中研判处置、事后总结评估三个环节着手，通过应急处置、应急管理、研判与预警、应急保障、查询统计、系统配置与管理等子系统构建，打造全环节管理链条，实现一体化的应急处理流程模式。3.6 硬件部署总体设计图 5 硬件部署总体设计图本方案中，河南省食药监局应急指挥中心建设将依据“国家应急平台体系技术要求（试行）”的要求，建立一个部门级应急指挥平台，该平台共分为两部分，移动端建设和平台端建设，正个应急指挥平台将依托河南省食药监局的业务体制和工作机制，采用融合通讯、移动GIS和3G/4G等
35、无线通信技术，达到实时传输音视频信息，实现现场统一调度、统一指挥，将现场处置情况实时回传到应急指挥调度室，并达到“看的见、听的见、指挥的了”的效果。其中移动端建设将为河南省食药监局执法人员配备可视化移动执法指挥终端、单兵终端、软终端等移动终端软硬件产品。并将河南省食药监局现有的执法车辆进行改造，配置车载摄像头、车载视频终端设备，将执法车辆改造为应急执法指挥车辆。平台端即是调度指挥中心，将在平台端部署多媒体系统平台、一体化高清解码单元、拼接显示大屏等后台设备，建立一个用于应急指挥的指挥中心，实现现场统一调度、统一指挥，将现场处置情况实时回传到应急指挥调度室，并达到“看的见、听的见、指挥的了”的效
36、果。3.7 关键技术路线选择本项目平台建设应该是技术先进、成熟可靠、性能优良、扩展灵活、标准开放的建设，并且能够综合考虑到项目建设在后续的发展和调整、变化，因此在系统结构、模块功能、应用性能等各个方面需要适应未来管理及服务应用等发展需要，最大程度地保护已有的投资。3.7.1 基于面向服务的架构设计本子系统采用流行的三层应用体系架构，这种标准的体系结构以及其所支持的跨平台语言可以方便用户的应用开发以及应用集成。同时由于该应用支撑平台支持多种流行的开放工具，用户可以选择其熟悉的开发工具开发应用，缩短了开发部署以及应用移植的时间。面向服务的体系结构（service-oriented architec
37、ture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。3.7.2 分层设计的思想本系统按逻辑分为以下几层：图 6 系统层次图1.应用层：应用层为客户端提供人机交互操作的界面和界面逻辑。应用客户端由多个JSP页面组成。每个窗体都包含许多用于显示较低层的输出以及收集用户输入的字段。实现基于窗体的用户界面的两类组件是：用户界面组件和用户界面处理组件。用户界面组件。B/S模式采用WEB页
38、面组件C/S模式则采用相应的客户端开发工具所提供的用户界面组件，并支持将您自己的自定义组件插入到框架中。 用户界面处理组件。复杂的用户界面通常需要许多非常复杂的窗体。要增加可重用性、可维护性和可扩展性，可以创建单独的用户界面处理 (UIP) 组件，以便封装窗体之间的依赖性以及与窗体之间的导航关联的逻辑。其中的部分概念适用于一个窗体的组件之间的依赖性、验证和导航。2.业务层：业务层为表示层提供处理建档登记、监管等业务处理界面，做为隔离层，它将用户界面与各种业务功能的具体实现隔离开来。业务层代码的逻辑用来满足业务领域的需要,由运行在业务层上的enterprise bean 进行处理，服务接口通过W
39、eb Service发布。现有的业务逻辑可能已经使用 EJB 组件编写，通过 Web 服务公开它可能是实现从外界访问这些服务的最佳选择。EJB 端点是一种很好的选择，因为它使业务逻辑和端点位于同一层上。有三种企业级的bean: 会话(session) beans, 实体(entity) beans, 和消息驱动(message-driven) beans. 会话bean 表示与客户端程序的临时交互. 当客户端程序执行完后, 会话bean 和相关数据就会消失. 相反, 实体bean 表示数据库的表中一行永久的记录. 当客户端程序中止或服务器关闭时, 就会有潜在的服务保证实体bean 的数据得以保
40、存.消息驱动 bean 结合了会话bean 和 JMS的消息监听器的特性, 允许一个业务层组件异步接收JMS 消息。为了保证系统具有很好的可扩展性和可维护性，业务层采用组件化设计，将业务逻辑通过组件封装起来，开放接口供其它模块调用。业务处理是通过业务层中的大量组件、实体、代理和界面来处理的。业务层包含以下内容：业务组件。业务组件是业务概念的软件实现。在业务应用程序的生命周期中，它们是设计、实现、部署、维护和管理的主要单元。业务组件封装业务逻辑（也称业务规则）。这些规则约束业务概念的行为以匹配特定公司的需要。例如，确定某个指定无照经营录入的业务规则可以封装在小型解决方案的业务组件中。对于大型解决
41、方案，所有与主体有关的业务逻辑可能都封装在单独的一个户口组件中。 业务工作流。业务流程反映了业务执行的宏观级别的活动。这些业务流程由编排一个或多个业务组件以实现业务流程的业务工作流组件封装。可以使用Java语言来开发自定义的业务工作流组件。业务实体。业务实体是数据容器。它们封装并隐藏特定数据表示格式的细节。例如，业务实体最初可能封装从关系数据库中获得的记录集。之后，可以修改该业务实体，以便在编写 XML 文档时尽量减少将对应用程序余下部分所产生的影响。业务和业务工作流组件可以与独立的业务实体组件交互，或者使用业务实体以便设置它们自己的状态，然后丢弃该业务实体。业务实体通常用作 Data Tra
42、nsfer Objects。数据访问组件通常返回业务实体，而不是数据库特有的结构。这非常有助于将数据库特有的细节隔绝于数据层中。服务接口。应用程序可以将它的部分功能作为其他应用程序可以使用的服务进行公开。服务接口将该服务呈现给外部世界。理想情况下，它隐藏实现细节，并只公开粗粒度的业务接口。服务接口通常使用 XML Web Service 实现。3.数据访问层：数据访问层为业务层提供对业务逻辑处理所需要的数据的存取。通过数据访问组件，屏蔽和提供对数据层一致的访问方式。大多数业务应用程序必须访问存储在数据库中的数据。此数据访问层中的数据访问组件负责将存储在这些数据库中的数据公开给业务层。 数据访问
43、组件。数据访问组件将业务层与特定数据存储解决方案的细节隔离开来。这种隔离具有下列优点：尽量减少数据库提供方的更改所造成的影响。尽量减少数据表示的更改（例如，数据库架构的更改）所造成的影响。封装操作单个位置的特定数据项的所有代码。这极大地简化了测试和维护过程。JDBC可以直接用作简单应用程序的数据访问组件。 服务网关。业务组件通常必须访问内部和外部服务或应用程序。服务网关是封装使用此类服务所必需的接口、协议和代码的组件。服务网关使得更改外部服务提供方变得更为容易。4.数据层：数据层提供数据的持久化管理。数据层由数据库和非结构化数据组成。数据层支持目前主流的数据库系统，包括Oracle 、DB2、
44、SQL Server 、SYBASE等。3.7.3 采用J2EE开发集成框架当今主流的开发框架有微软公司的.Net技术和Sun公司的J2EE技术。对两项技术，从多个方面进行了慎重的方案比选。（1）系统整合及系统延展性跨平台的特性一直是J2EE的最大特点，它通过Java的虚拟机技术屏蔽了底层操作系统的细节。从而实现了所编写的代码可以在Windows、Linux、Unix等平台上使用。即所谓“一次编写，处处可用”。在J2EE规范里面又通过JDBC、JNDI等技术屏蔽了诸如数据库、目录访问等网络细节，而且效率也能够得到良好的保障。总体而言，J2EE技术是一套标准，它由诸多公司一起支持，所以技术的通用
45、性和标准性比较高，目前基本上成为企业级解决方案的事实标准。在各系统连接方面，J2EE也提供多种解决方案，例如J2CAJ2EE联接器体系结构，就是J2EE规范规定的如何使用Java技术与所谓遗留系统如ERP、CRM等的连接方法。当然J2EE也提倡使用Web Service等技术来进行系统互联。相比而言，.Net从本质上来讲不是一套标准，而是微软一系列产品的集合，所以，选择.Net技术，就选定了微软平台，对应的操作系统必须选择Windows，相应的对于数据库、底层的硬件也有相应的限制。综上，在多系统整合和系统延展性方面，J2EE有较为明显的优势，目前而言，.Net技术还很难望其项背。（2）I/O处
46、理和线程调度在这个方面，从应用的层面看，两者都能够达到企业级应用的需求。但是I/O处理和线程调度从本质上来讲应该由底层硬件和操作系统来解决。J2EE支持众多的硬件和操作系统，比.Net技术更有优势。大型计算机的I/O处理能力和线程调度能力是其他任何机种所无法企及的，目前只能运行J2EE，不能运行.Net。（3）产品成熟度等其他因素J2EE在1999年形成了其成熟的架构，并且到今天已经有相当成熟的经过检验的企业应用系统。而.Net究其渊源是源自微软以前开发企业应用程序的平台DNA（Distributed NetworkArchitecture），其中包括了许多已经被证实的技术，并且这些技术已经在
47、产品中得到实现，包括微软的事务服务器、COM+、消息队列、SQL Server数据库等。而对于扩展性，广为业界接受的事实是.NET平台的扩展思想是基于软件的横向扩展，而J2EE平台的扩展思想则是基于硬件的纵向扩展。基于以上比选，本项目谨慎选择J2EE技术作为应用系统开发框架。使系统具有更好的可移植性、安全性、可伸缩性、负载均衡和可重用性。3.7.4 遵循XML标准的数据交换XML即ExtensibleMarkupLanguage(可扩展标记语言)的缩写。系统的外部接口采用XML数据交换格式，降低系统间的藕合度，确保数据交换与具体应用平台无关。XML实际上是Web上表示结构化信息的一种标准文本格式，它没有复杂的语法和包罗万象的数据定义。XML同HTML一样，都来自SGML(标准通用标记语言)。SGML是一种在Web发明之前就早已存在的用标记来描述文档资料的通用语言。但SGML十分庞大且难于学习和使用。鉴于此，人们提出了HTML语言。但近年来
