区域计算机连锁系统（精选4篇）
区域计算机连锁系统 篇1
0 引言
近年各国对电力系统的安全保障能力重视不断加强,但世界范围内仍出现了十余次连锁故障导致的大停电[1]。除了基础建设不足、信息化程度不高、紧急控制不到位等因素外,缺乏适合在线应用的连锁故障研判工具,无法及时对系统薄弱点、故障传播特性与发展进行深度计算也是其主因,现有软件尚不具备针对性地解决这一问题的能力[2]。连锁故障模拟通常涉及稳态、准稳态、暂态等多个时间尺度,同时需考虑可能出现的保护不正确动作对后续状态的复杂影响[3]。 概率型事故链是应用较多的模型[4],以最优潮流模拟故障扩散中控制策略的方法也受到关注[5]。由于事件组合、触发因素、状态转移等不确定性,真实系统的连锁故障分析容易造成分枝庞大的“组合爆炸”,如某省级电网常规预置故障集(N-1)中有246种故障和45种组合故障(断面/N-2),若对每组故障可能引发的连锁模式进行分析,则会带来沉重的不确定计算负担。目前理论侧重于探索连锁故障本身机理,鲜有介绍应对其计算复杂性的策略。对于大规模连锁故障的仿真分析在开始之前,难以确定有多少可能的故障组合,在计算资源的调配上具有不可知性,因此,需要针对连锁故障仿真分析过程与数据特点研发高度灵活的新型计算框架。
云计算是面向服务的全新计算框架,高性能分布式计算是其后台关键技术。文献[6]指出云计算在智能电网中的应用前景与技术路线,数据中心、智能变电站、电网调度、孤岛重构等具体应用陆续被提出[7,8,9,10],国外也开展了类似研究[11]。但在具有超大运算需求的事故链组合计算与连锁故障分析领域仍鲜有解决方案报道。从软件工程角度看,面向连锁故障仿真分析的分布式计算框架应至少具备3个典型特征:①尽量复用稳定成熟的电力系统商业软件计算模块,减少基础功能开发工作,并保持现有应用良好的电力元件模型结构化数据;②整体具备跨平台功能,良好兼容异构环境;③软硬件部署方便,在对现有环境改动较小条件下实现计算资源即插即用。Hadoop是一种能对大规模数据及应用进行高性能分布式处理的Linux开源技术框架,是当前支撑各领域云计算发展的主流计算架构之一[12,13]。文献[14]在OpenStack和Hadoop架构下采用多目标粒子群算法优化虚拟机迁移策略,实现了具有通用计算功能的电力仿真云平台资源调度技术。本文针对电力系统连锁故障计算需求与事故链组合不可预知等特点,在Hadoop环境下结合常用的PSD-BPA软件研发了大规模连锁故障的分布式计算技术,首先开发了可并行处理的连锁故障计算分析模块,再通过MapReduce映射—归约配置与Hadoop分布式文件系统(HDFS)存储调度功能,实现连锁故障仿真分析中计算功能与场景数据的完全解耦,将事故链拆分为独立数个单一关联事故由HDFS中NameNode节点依据计算节点负载状态灵活调配,实现依据资源状态管理计算能力,以适应大量事故链组合分析中组合状态的不可预测性,并兼顾计算资源性能均衡。
1 电力系统连锁故障仿真分析
1.1 连锁故障驱动的参数设定
连锁故障模拟通常基于准稳态仿真及其安全分析计算,部分也考虑采用时域仿真校验连续扰动下的系统稳定。缺乏统一的算法和评判指标是连锁故障模拟建模尚缺少依据的重要原因。连锁故障计算的基本模式如图1所示。
事故链生成是驱动连锁故障模拟的关键,虚线框中是计算前未知的故障可能模式,经过评估分析后形成高风险事故链预警。由于故障维度的不可预测性,框中(含模拟生成算法)数据计算与处理过程的负担极重,即使是利用智能筛选算法[15],对于实际系统也难以实现快速分析,必须分布式处理。本文所采用的连锁故障模拟考虑以下5方面要素。
1)故障初始化为预想故障集与关键元件搜索的并集,关键元件搜索分为基态和N -1,后者又被考虑为独立故障与群发性故障2种方式[16]。
2)针对潮流转移,若线路负载超过其输电容量100%则立即开断,若处于85% ~100% 区间,则利用直流最优潮流(DC-OPF)模型模拟调度员进行发电再调度和切负荷操作(仅考虑控制部分常调机组出力与减载节点负荷),目标函数为机组出力调整总量与切负荷总量之和最小;若节点电压低于0.87(标幺值)则自动切除15%负荷以模拟低压减载。
3)对于线路考虑一轮确定性误动和拒动(对于220kV及以上系统延时开断故障线路以模拟近后备保护动作),设定不准确动作线路的次轮关联元件无误动和拒动;针对重要送电断面考虑安控装置动作逻辑,以确定是否存在下一轮开断元件。
4)单纯准稳态模拟易导致结果偏乐观,须考虑进行暂态稳定评估,原则为:①原发故障视为三相短路,0.15s内切除故障,后续线路过流保护和安全稳定控制装置动作分别设定为故障清除后第4s和0.4s的元件开断事件;②后备保护延时设定为0.1s;③总时长设定为10s,如多一轮过载速动事件,则增加5s;④DC-OPF调整过程不进行稳定校核。
5)仿真结束条件为:①次轮事件触发均未满足;②系统失稳(最大功角差超过180°);③潮流计算不收敛;此外,确定无次生事件后,自动增长10%负荷(发电机分区平衡),给出线路重载过载与电压偏低预警提示,明确系统静态安全水平。
1.2 连锁故障元件动作判定
继电保护与安全稳定控制动作是否准确直接关系到故障扩散模式[6]。动作逻辑判断用于确定某轮扰动前后相关参数是否满足动作条件,若满足则开断对应元件作为次轮事件。附录A图A1示意了某发电机安全稳定控制策略的动作逻辑判断。程序中利用If-then建立故障前后元件运行参数判别准则,以0-1整数变量Ci表征条件全集u中某分量uj的第i个测试逻辑,N为其该事件触发的全部测试条件个数,若满足以下逻辑与表达式:
则在次轮时域仿真中的规定时刻点加入事件uj,形成次级事件,以此类推,最终形成完整故障链。
1.3 故障集初始化
预想故障集通常根据经验和规程指定,一般包含母线、重要线路(断面)和重要机组的N -1、暂稳校核与少量组合故障,预想故障根据方式变化、一次设备投退进行小范围调整。本文预置故障集初始化方法如附录A图A2所示。在线部分的运行方式数据、故障告警与开断元件可通过能量管理系统(EMS)状态估计模块导出。*.dat和*.swi分别表示PSD-BPA潮流与稳定计算的数据配置文件。
1.4 连锁故障的判别与形成
对可能的事故序列进行逐一计算与评估是连锁故障风险分析的重要方法[5],但实际系统中的关联概率参数难以获取,限制了概率型算法的适用性,本文将单一事故链视为确定性计算,最终汇总后根据各类严重度排序,以进行风险提示,其完整流程如图2所示。
1.5 严重度评估
对于连锁故障的严重度评估不仅限于单纯的失负荷量,还应考虑潮流转移过程中元件重载水平、暂态受扰水平等,以对后果严重或风险极大的故障扩散进行排序、提示。从以下几个方面衡量既定事故链的严重度。
1)失负荷量(load shedding index,LSI)
当有线路出现85%~100%负载区间时,启动DC-OPF程序模拟调度行为,记录切负荷量,若出现孤岛则假设其负荷全部失去,因不是研究重点本文暂忽略低频减载配置问题。将负荷损失超过系统总负荷15%视为LSI指标严重。
2)静态安全水平(static security level,SSL)
静态安全水平的关键性能指标很多,本文中对于每阶段故障(事件),记录超过线路容量65%的线路条数及其平均负载率,统计电压低于0.9 (标幺值)节点个数及其平均值。这两类参数均以骨架网络中(对实际系统指220kV及以上网架)超过阈值的元件占相应元件总数的8%判定为严重。
3)暂态稳定指标(transient stability index,TSI)
依据1.1节中第④点原则对每个事故路径进行时域仿真后,基于功角轨迹采用TSI量化全局暂态受扰水平[17],表达式如下:
式中:δmax表示每个时步任意2 机间功角轨迹差的最大值。以任意2 机功角差360°为失稳判据,将TSI临界失稳的严重阈值定为15(轨迹最大功角差266.09°),值越小表明暂态冲击越严重,小于0则判定为失稳。
连锁故障逻辑判断、过程模拟与指标分析均采用面向对象思想编写专门类,扩展方便。本文目的是研发Hadoop架构下大规模连锁故障计算的分布式计算方法,因此采用一系列认可度高、逻辑层次清晰、计及最重要因素的搜索算法与计算规则,采用Java面向对象编程封装连锁故障基本计算功能,以兼容Hadoop计算资源配置、数据管理、分布式负载管理等环节的自动托管。
1.6 计算功能的集成实现
PSD-BPA软件使用广泛,但该软件并不具备计算大规模连锁故障计算功能,需编写专门程序。保留其.dat和.swi数据结构,针对每一个事故链生成一个包含两者的独立文件夹Case Package,并分配唯一Case ID,同时在Package中自动生成记录故障序列的Log文件。将上述功能通过Java与1.1至1.5 节中功能进行集成,实现适合并行处理的连锁故障计算软件PCFA (parallelizable cascading failures analyzer),其单机串行执行流程见图3。
PSD-BPA的数据结构与填卡模式满足数据的完全解耦,十分适合HDFS的数据本地化要求。但其机电暂态仿真尺度短(数十秒),难以计及励磁限制等慢动态过程,且存在仿真时长与动作特性匹配问题(本文固定初始化为10s)。 本文侧重研究Hadoop下大规模连锁故障分布式计算可行性,因此在故障仿真中忽略慢速元件动作行为,仅用时域仿真校核各时序故障发生后的暂态稳定水平。
图3中步骤①—步骤⑧按顺序执行,其中步骤③为从初始集中取某故障方式作为base case,步骤④—步骤⑥为连锁故障模拟程序产生的各级事件计算数据(*.dat/*.swi),图中共有M级故障,步骤⑦为PCFA中与PSD-BPA反复交互过程,步骤⑧为事故链终态数据与严重度评估结果输出与存储。
2 连锁故障计算的分布式架构与开发
2.1 MapReduce基本原理
MapReduce是近年提出的一种高性能分布式计算模型[18,19],其数据采用键值对建模。 附录A图A3展示了Map与Reduce协同工作过程。Hadoop使用Java构建MapReduce分布式模型以实现集群中的数据处理功能。集群中每台计算节点会提供其硬软件资源用以组成HDFS,该系统不但负责文件存储(连锁故障数据),也承担计算任务(PCFA)。节点按功能可分为一个NameNode与多个DataNode:前者负责任务管理以维护各种系统数据,并且调度分发数据;后者执行计算。计算开始后,计算程序被映射到各DataNode中,由本地Java虚拟机启动和执行。此后,NameNode通过遍寻集群中所有DataNode状态,获取集群中Mapper和Reducer可用性,并最终根据数据分布存储位置启动本地或相邻节点执行计算。
2.2 计算节点功能架构及其平台化
以DataNode作为计算节点,以PCFA作为分布式环境与连锁故障计算中间件,以NameNode作为分布式环境管理节点,系统配置结构如附录A图A4所示。计算平台实现步骤如下。
步骤1:搭建Hadoop计算环境。首先在计算节点中开启无密码登录SSH,将Hadoop文件夹放置于任意目录下,修改相关配置文件,设置端口、文件副本数量、轮询间隔等环境参数。然后通过脚本采用HDFS命令进行文件系统格式化,并启动计算环境,作为PCFA的分布式环境。
步骤2:实现连锁故障计算数据分布式处理与计算机制。在各节点Windows系统中部署PCFA,实现各节点核心计算功能,针对预置故障集,通过PCFA搜索形成树形事故链,并按1.6节数据规约形成可解耦计算的电网数据组合,通过Hadoop调度机制实现分布式计算(详见2.3节)。默认采用先入先出(FIFO)原则进行集群负载均衡。
步骤3:进行跨系统通信。 计算节点中,Windows和Fedora操作系统通过服务器信息块(SMB)共享协议,将电网计算数据进行跨系统传输;提交计算数据过程中,首先在各节点PCFA中形成单级事故链计算数据,其次在数据封装中封装有HDFS上传命令行,在数据达到Fedora操作系统后该命令会被解析并实现所携带的数据上传至HDFS,数据整体维护由Hadoop根据系统配置自动托管。 计算任务的分布式处理流程如附录A图A5所示。
2.3 HDFS文件调度功能实现
本文所设计HDFS调度包含以下4个过程:①建立HDFS与Fedora本地系统间传输通道;②建立本地Fedora与集群中Windows系统的连锁故障计算文件传输通道;③监视集群中DataNode节点系统资源使用率(CPU使用率,用于潮流计算或时域仿真);④根据DataNode资源使用情况,依据负载平衡原则发配某原发故障的某级连锁事故数据至集群中该节点并采用PCFA进行进一步处理。
在应用PCFA和Hadoop以及HDFS构建主要框架同时,采用jcifs1.3.14版本的Java开发库实现基于SMB协议的共享文件夹读写功能。 利用Linux与Windows、本地及异地的SMB共享文件夹,实现跨系统的文件传输能力,并针对PSD-BPA计算数据结构,专门开发数个Java类(如表1 所示),实现HDFS命令及接口封装,能够使计算平台通过标准Java程序完成对HDFS的电力系统计算文件输入及输出功能。此外,采用Hyperic与Sigar实现基于Java的Windows,Linux底层交互命令与计算节点资源获取。
HDFS调度功能实现流程如下:①原始数据文件首先被上传至HDFS某路径下进行存储;②根据某节点资源使用情况,决定该数据文件发送目的地;③根据Data Locality通过HDFS接口,将数据文件从HDFS读取至该数据块所在本地主机;④调度程序通过SMB协议,将PSD-BPA数据结构的连锁故障计算文件发送至远程目的地Windows环境路径下;⑤目的节点调用PCFA对数据进行故障链计算及生成新的故障数据;⑥新生成故障数据再次进入HDFS,进行下一步数据调度与计算。整体流程如图4所示。
图4(a)中箭头为HDFS中连锁故障计算数据发送与生成方向,其调配靠表1中的Java类实现,利用哪个DataNode计算何种原发故障的哪级故障具有数据调度不确定性,实现了连锁故障事故链计算在不同计算单元的解耦,如图4(b)所示。若A—K为多核CPU配置的DataNodes中不同计算资源,则单个DataNode可同时分析不同原发故障后的不同阶段故障,图4(b)中1—6示意了与图4(a)对应的某事故链的中间计算文件(*.dat/*.swi)由不同计算资源处理的过程。由于NameNode的集中管控与计算资源动态调配(Dispatch类),也解决了连锁故障组合事先未知的问题。所提计算架构相比于与图3结构,具备巨大计算优势。
所开发基于Hadoop架构的电力系统连锁故障分布式计算技术整体算法流程伪代码如下:
3 应用测试
3.1 系统环境配置
采用10台单核CPU计算机与千兆网络交换机搭建测试所提出计算系统的硬件环境,将其中1台笔记本计算机设定为NameNode,其余为计算处理单元DataNode,计算集群配置情况如表2所示。
连锁故障分析计算功能源于PCFA程序,各计算节点均安装Windows操作系统中,采用VirtualBox架设虚拟机,其中加载Fedora操作系统,分布式环境部署采用Hadoop 2.2.0。
3.2 测试分析
本文利用10机39节点、16机68节点和某省级电网数据进行原型系统测试分析,基本信息如表3所列,其中单机(Dell服务器)单次时域仿真为任意三相短路故障,总时长度为10s,仿真步长1个周期,耗时均为100次计算平均值。
由于标准算例系统缺乏某些关键参数,如线路热稳电流最大值、机组最大(小)出力、简单安全稳定控制策略等,因此需对10机和16机系统部分参数进行假设,以驱动后续的连锁故障判定条件响应。针对3个测试系统,利用第1节中分析过程,即内嵌于PCFA系统及其与基本功能模块交互功能,搜索各系统连锁故障事故链如表4所列,其中任意判据严重连锁故障不含失稳与潮流不收敛场景。
通过PCFA对某省电网自动搜索出的517 例事故链分析可知,导致该系统出现严重后果的连锁故障大部分属于动态安全问题,除43 例失稳与12例潮流不收敛场景外,严重度判据超过阈值的主要是TSI(38例),说明该电网故障扩大的主要风险并非是线路相继过载造成负荷损失,而在于若干元件故障退出后的系统稳定性难以保证,这和该电网静态裕度高但多处断面暂稳约束较为严重的运行经验一致。实际上通过DC-OPF模拟重载时的主动切负荷操作,能在连锁开断初期以较小的负荷损失代价极大地减少相继过载风险(测试中共有63个场景启动DC-OPF操作,均未造成严重后果)。
本文所研发的计算框架本质是提高了大规模事故链的分布并行计算与分析效率,在有效时间内仿真、评估、筛选可能造成严重后果的连锁故障场景。若在此过程中的某些环节(如安全稳定控制与保护装置动作概率、负荷异常波动)引入不确定性模型,则可以很方便地改造为连锁故障风险分析程序,但不确定性分析通常导致更多需要计算的场景,要求更多计算资源。通过记录3个算例在测试平台上的各环节耗时,对技术框架进行效率分析,共进行5轮测试,平均耗时参数分别如表5和表6所示。
表中:TC是指最后一个事故链评估完毕时间,即总耗时;TS为单个事故链场景仿真平均耗时;TP为解析仿真结果与严重度评估平均耗时;TD为系统其他资源开支,包括跨操作系统交互开销、计算平台内部多节点建立开销等耗时;α1和α2为效率系数,定义为总耗时与事故链场景总数之商。由性能参数测试结果可知,相比于单机PCFA系统,采用所研发框架测试平台均一定程度提高了连锁故障模拟与分析效率。需要指出的是,计算效率提高幅度并非与新增计算节点呈线性关系,定义参数β为计算性能提升幅度:β=α2/α1,如计算节点性能大致相当,则有β<N -1,其中N为计算节点。5轮测试3个系统β值如图5 所示。从其中数据可知,平台对于3个测试系统均能稳定地提升其大规模连锁故障仿真分析的计算能力,5轮测试其β的平均值分别为3.874,4.529 和6.714,均小于9(理想提升幅度,即为DataNode节点总数)。
需要指出的是,在本文测试中TD占据了TC较大比例,这和计算节点集群硬件性能(如是否采用固态硬盘)、网络性能(如是否是计算专用网络),以及软件工程优化均有一定关系。以测试中省级系统为例,该电网常规215个预置故障N-1要求在5min之内计算完毕,单个故障平均耗时要求1.39s,本例517个连锁故障在9 个计算节点上1 482s(约25min)内计算完毕,单个故障平均耗时2.87s,从单个故障平均处理耗时看相差并不太大,在与N -1扫描时间大致相当的要求下,可加设更多计算资源,通过简单配置较为容易地实现大规模连锁故障的仿真分析,且无需关心连锁故障计算中的故障组合与场景模式不确定性问题。此外,本例测试中TD平均占TC三分之一强,如果TD能通过改善运行环境性能大幅降低则该β还能进一步提高。随着目标电网的规模和计算复杂度增大,系统计算性能提升幅度随之增加,系统初始化、I/O读写、节点状态评估与任务分配、数据调度、网络通信等TD的时间开支在TC中比例将逐步缩小。
在执行连锁故障计算过程中,各计算节点资源由NameNode监测并视其状态通过HDFS发送某事故链单次数据文件作为次轮计算输入。 采用Hyperic和Sigar以1s为间隔获取计算节点CPU资源使用率,图6 为计算开始后某时段(3 min左右)中2个计算节点的CPU使用情况。
可以看出,2个CPU在HDFS的电网计算数据分发策略下,以较高执行密度均匀地持续进行电网数据处理与计算而没有产生计算资源闲置,也说明本文所采用的计算资源管理策略适用于所提技术框架。由于CPU是由虚拟机与物理机资源共享以及多进程共享,因此其使用率变化通常由多因素共同导致,具有较复杂的波动性。但可依据潮流计算和时域仿真的计算资源占用水平,大致推断A类尖峰(占用60%以上,持续不超过3s)是该DataNode正在进行电网潮流计算,B类尖峰(占用75%以上,持续不超过15s)是该DataNode正在进行时域仿真计算。
4 结语
针对具有高计算需求的连锁故障仿真分析应用,研发了基于Hadoop架构的分布式计算服务技术,利用标准算例与某实际电网数据验证了所提计算框架功能。该计算对各类连锁故障分析算法和评估指标兼容性良好,可通过面向对象编程自定义扩展一系列严重度、稳定水平的评估判据及综合判定方法,且新接入计算资源仅需简单软硬件配置即可,将事故链解耦成独立单一故障场景进行计算,无需受制于大规模连锁故障分析中的故障组合未知性。该技术有望为电网规划、方式校核、防御策略、薄弱环节挖掘提供深度计算能力。此外,所研发计算框架可作为电力系统大规模复杂故障分析的云计算引擎(相关技术特性分析参见附录A图A6),但在此应用领域实现真正的云计算,还需深入解决异构数据处理及其本地化、计算节点的互联网化(电力以太网)、用户接入模式及计算服务商业化原则等多个关键问题,这些均是值得深入的研究方向。
附录见本刊网络版(http://www.aeps-info.com/aeps/ch/index.aspx)。
区域计算机连锁系统 篇2
甲 方： 福州弘扬餐饮管理有限公司
地 址： 福州市鼓楼区中山路建发大厦3层
电 话：
以下称“特许人”
乙 方：
地 址：
电 话：
以下称“受许人”
双方经友好协商，本着诚实信用、互惠互利、共同发展的原则，依据《中华人民共和国合同法》及有关法律法规的规定，特许人授权受许人在指定区域进行“纽约客现磨咖啡”加盟代理和推广，并就相关事宜达成一致:
第1条 宗旨
1.1特许人依法拥有“纽约客现磨咖啡”系列产品和品牌的知识产权，受许人只有经过特许人的允许，才可以使用“” 的名称、商标、图案、色彩等受法律保护的知识产权（以下统称名称和商标）。
1.2 受许人愿意通过使用特许人的运营体系和操作系统，在接受根据合同条款和在本合同所规定的区域特许开设、推广“纽约客现磨咖啡”加盟连锁门店，销售特许人相关指定产品。
第2条 受许人的法律地位
2.1 受许人以自身名义，自付费用，作为独立的经营者进行其活动。因此，受许人须接受对所有经营者共同的法律要求，特别是有关资格的规则以及社会的、财务的和商业的要求。作为一个独立的经营者，受许人应就其活动自负一切风险和从中获利。
2.2 受许人不是特许人的代理人、买卖代表，也不是他的雇员或合伙人。
受许人不是作为特许人的佣金代理人，受许人无权以特许人的名义签订合同，使特许人在任何方面对第三人承担责任，或由特许人负担费用，承担任何义务。
第3条 授予的各项权利
为了使受许人正常经营，特许人授予受许人下列各项权利：
3.1使用“纽约客现磨咖啡”名称和商标的权利；
3.2在引进以及经营过程中从特许人处获得技术、商业、法律和经营等方面指导的权利；
3.3在经过核准区域和核准建筑物内，按本合同产品专利费及价格体系的约定，经营“纽约客现磨咖啡”专卖店相关指定产品的权利；
3.4享有本合同约定区域的独家加盟代理权的权利；
3.5享有核准区域内所开设/开拓门店特许使用费（含商标使用费、广告费）分成的权利。
第4条 区域
特许人授予受许人在 福建 省 福州 市（按合同生效日时的政府行政划分为界定区域）作为“纽约客现磨咖啡”加盟连锁经营的代理商，享有“纽约客现磨咖啡”专卖店加盟代理权,向以上地域内推广、销售、配送“纽约客现磨咖啡”相关指定产品；
4.1受许人在合同期内，自 2011 年 10月至2012 年 9月开设或发展不少于 2 间“纽约客现磨咖啡”专卖店；
在上述规定的任一内未完成开店数量的，特许人有权于次始在上述区域内引入具有与受许人相同权利的第三方经营、开设、推广“纽约客现磨咖啡”加盟连锁专卖店，或特许人有权单方面解除本合同，取消受许人该合同剩余时间的代理权。
在本合同期间，根据市场变化，双方可协商制定新的门店发展目标或规划，在双方达成一致意见，重新签订补充协议后按新的发展目标或规划执行。
4.2 受许人不得变更或超越授权经营的区域，如违反规定，特许人有权解除本合同，取消受许人该合同剩余时间的代理权。
第5条 授权期限
5.1授权特许经营代理推广期限为：2011 年 10 月 1 日至2013年 9 月 30 日。
本合同在双方签字/盖章之日生效。
5.2 合约期满，特许人将根据受许人的表现，决定是否续约；受许人必须于本同期限届满前至少3个月通知特许人是否续约，双方不发出续约通知将终止本合同。通知需用挂号信或任何其他书面传递手段，可借以确定收到通知的日期（该日期可用以计算通知期间）。
第6条 装修及设备要求
6.1 建筑物装饰
特许人不与受许人所代理区域内的加盟店签订装修协议，由加盟店直接按照统一设计与装饰公司签订门店装修合同。
6.2 受许人在本合同核准地域开设的门店实用面积不得少于 20平方米，且店址均须获得甲方书面同意。
6.3门店设备由受许人按清单报与特许人，由公司总部统一配送安装。
第7条品牌形象与管理
7.1 店铺的形象
受许人须按照“纽约客现磨咖啡设计图纸”和运营手册中所描述的标准来监督、维护所辖区域内各“纽约客现磨咖啡”门店的装饰、设备以及外观；当其不符合要求时，受许人有义务督促各门店按照特许人的要求对店铺进行重新调整和装修，包括更新老化的设备。
7.2受许人及其雇员要对客户及所辖区域内门店提供及时、礼貌、友好、有效的服务。并对顾客以及公众保持最大程度的诚实、公平以及遵守道德上的准则。受许人同意执行和监督符合本合同第6.1条所述开设的门店符合特许人在运营手册中所设立的以下条款：
A)正确的采购、陈列、储存、销售商品的方法和程序；
B)店铺的安全、维护、清洁、运行和外观；
C)受许人及其雇员统一形象及外表；
D)对所有名称与标志的使用；
E)运营时间的保证及对运营资金的保持；
F)对于标牌、商标、海报、陈列、标准配置以即相关产品的使用；
G)作为特许人认可的受许人以及受其管理下店主证明的使用；
H)受许人选择投放广告的内容、风格以及媒体的审批；
I)店内陈列或出售商品的来源、种类和牌子的标注与陈列；
J)受许人所保持的最低限量的库存保证；
K)特许人许可的礼物、赠券或者当地的促销活动的开展；
L)保证最佳数量的受训员工；
7.3 监督
受许人应严格执行特许人的关于“纽约客现磨咖啡”门店和推广的各项规章制度与政策，承担其所代理区域内各“纽约客现磨咖啡”门店的经营、卫生等监督管理责任，负责监督其所授权区域内各“纽约客现磨咖啡”门店的经营、装修、名称和商标标识的使用、营业人员的管理、培训、服务规范均要符合特许人的要求，对门店的违规行为及时通知纠正或向特许人提出处理建议。
第8条人员培训和聘用
8.1 特许人应保证受许人的初始的和后续的培训：
A)在任何活动开始前，受许人及其职工必须接受特许人的相关培训或指导，受许人应熟悉各种条款以及技术、商务和管理程序。同时受许人有义务将上述内容及方法传授给所辖区域内各门店中的有关人员。
B)在本特许有效期间，由受许人安排其雇员和所辖区域内各门店中的有关人员参加。日期和地点由受许人决定。
8.2 如果特许人决定改变某些实施的方法，他必须立即书面通知受许人。
第9条 食品卫生安全
9.1 受许人有义务监督其遵守本合同规定开设或发展的门店，在门店签约后的90日内必须自费申领由当地政府机关颁发的营业执照、卫生许可证等营运门店店必备的证照。
9.2 受许人对食品、半成品、成品、包装材料、食品调配设备发现有异常情况或者存在疑虑的，必须立即停止使用并上报特许人，经特许人确认或处理后，恢复正常或消除疑虑后，方可正常使用，否则，因此造成相关食品安全事故或纠纷的，受许人承担所有损失与法律责任，且特许人保留追究受许人因此而造成特许人相关经济损失的权利。
9.3 不管任何原因致使受许人管辖区域内各门店发生相关食品安全事故或纠纷的，受许人必须在事件发生30分钟内通报（以电话或传真的方式）特许人，且受许人必须立即妥善安置涉及人员，否则造成特许人名誉和相关经济损失的，特许人有权解除本合同，作为违约金受许人所缴纳的所有费用不予退回，且保留追究受许人因此而造成特许人相关经济损失的权利。
9.4所有产品必须在保质期限内销售，超过保质期限的产品受许人必须销毁处理，如受许人因销售过期产品导致发生食品安全事故或纠纷的，特许人有权解除本合同，作为违约金受许人所缴纳的所有费用不予退回，受许人承担所有损失与法律责任，且特许人保留追究受许人因此而造成特许人相关经济损失的权利。
第10条 管理费及其他费用
10.1 受许人符合本合同所述开设的门店(包括但不限于受许人直属店)，开业前必须与特许人另行签署《“纽约客现磨咖啡”加盟合同》，且特许人每店收取特许使用费人民币20000元整/3年（该特许使用费其中人民币10000元整为受许人分成款，剩余人民币10000元整由特许人收取），如发生受许人多收、瞒收、上报虚假金额等行为，特许人有权拒绝承认门店的合法地位，且特许人有权单方面解除本合同，取消受许人代理资格，特许人方有权重新选择该地区的代理商，并保留追究受许人造成特许人相关经济损失的权利。
上述门店，如为受许人开设的直营店，受许人开设每间直营店须支付给特许人特许使用费现金人民币20000元整。
上述特许使用费（即人民币20000元/店），汇入特许人指定账号。款到特许人帐号的 二 个工作日内，特许人在该加盟合同书上加盖公章。
10.2 受许人支付给特许人的以上费用，受许人必须以转帐或现金的形式向特许人缴纳，开户银行：
开户银行： 中国建设银行；银行帐号：622280***83 ；
10.3 受许人不得以任何理由要求返还上述费用。
10.4 根据市场和发展的需要，特许人有调整收取门店特许使用费、履约保证金、管理费、商标使用费、广告促销费的权利。
第11条 特许人的权利和义务
特许人保证：
11.1是名称与商标持有人；因而有资格授予受许人使用的权利。受许人对这些权利的使用并不妨碍任何第三方在按本合同规定的地区内的权利。
11.2特许人同意在任何特许经营开始之前向受许人提供下列服务：
向受许人提供包括场地装修和产品展示标准在内的说明；发展业务所需准备的清单；向受许人提供示范的装修条款和有关受许人许可范围内进行改制的建议； 就受许人开展特许经营而进行的任何广告宣传活动提出建议。
11.3 向受许人提供优质的产品方案，并对产品的品质负责。在销售、储存过程中，若因受许人原因导致产品质量责任，应受许人方承担。
第12条 受许人的权利和义务
12.1 特许人按本合同所述授予受许人以使用名称与商标的权利[非独家权利]，但此种使用权限于合同所规定的对产品(服务)之销售。
12.2 受许人应进一步发展他按本合同规定从特许人那里获得的专有技术。
12.3 受许人及其员工应参加按本合同组织的必要的初始训练班。
12.4 受许人应向特许人提供一切能改善网络的建议和他在经营特许活动中获得的经验。12.5 受许人不得向特许人核准区域外的特许人的第三方供货，否则特许人有权解除本合同，取消受许人代理的资格，受许人已缴纳的所有费用不退回，并且特许人有权重新选择该地区的代理商。
12.6 “纽约客现磨咖啡”门店使用的所有纸杯、塑料袋、工衣等用品。门店必须配备的全部用品及设备必须从特许人处购买。否则特许人有权单方面解除本合同，取消受许人代理资格，受许人已经缴纳的履约保证金及加盟费不退回，并且特许人有权重新选择该地区的代理商。12.7 受许人有义务监督所代理区域内所有“纽约客现磨咖啡”门店不得销售特许人指定商品以外的一切其他产品（特许人书面同意的除外），按照特许人提供的配方进行产品配制，从特许人或特许人书面指定的厂商处购买原材料。受许人对加盟店的违规行为应及时通知纠正或向特许人提出处理意见。
12.8 受许人一旦发现侵犯或滥用特许人商标，商业名称或者其他简称以及任何侵权或不正当竞争情况的应将此情况立即通知特许人。
12.9 受许人应就法律程序向特许人提供必要的帮助，以便在诉讼中成功地得出结论。此项帮助引起的费用应由特许人及受许人共同负担。
在事前书面通知后，受许人如果在法律上能这样做时，应进入任何有用的法律程序，以便特许人的权利得到确认。
第13条续约
在本合同期限届满时，受许人在满足下列条件的情况下，享有合同到期后同等条件下优先续约的权利：
13.1 较好地履行了本合同的义务，没有发生过比较重大的违约行为；
13.2 已经向特许人支付了到期的全部款项。
13.3 提前六个月书面提出续约申请。
13.4 如受许人于本合同期满后不再续约或合同期限内放弃履行本协议，须在本合同到期前六个月以书面形式通知甲方，受许人在收到特许人的回复后的一个月内，将区域内所有“纽约客现磨咖啡”门店的相关资料移交给特许人。
13.5如受许人于本合同期满前六个月不就是否继续履行本合同提出书面要求，特许人有权视受许人自己放弃优先续约的权利，特许人有权选择另一方替代受许人为该区域的代理商，且受许人在收到特许人的通知后的一个月内，必须将该区域内所有“纽约客现磨咖啡”门店的相关资料移交给特许人；受许人必须于本合同期满前的一个月内将原代理区域所有的“纽约客现磨咖啡”专卖店移交给特许人授权的另一方管理，需无条件配合特许人、特许人授权的另一方办理、完成移交（原受许人代理区域内所有“纽约客现磨咖啡”）所需的一切相关的法律程序、文件。
甲方（特许人）：福州弘扬餐饮管理有限公司
(盖章）
合同签署人：
签约时间：年月日
区域计算机连锁系统 篇3
2009年4月,《中共中央国务院关于深化医药卫生体制改革的意见》正式公布,提出建立实用共享的医药卫生信息系统,极力整合资源,加强信息标准化和公共服务信息平台建设,逐步实现统一高效、互联互通。加快建设医疗卫生信息系统和医疗保障系统。针对以上目标,卫生机构如采用现有的、分散式系统建设模式,即由各医疗卫生中心独立建设自己的系统,这样的建设体系存在着由于投资分散而导致的系统质量差、多点维护成本高,建设周期长,以及信息的准确性、可靠性等一系列问题。通过构建基于云计算的区域医疗平台,动态地部署、配置及回收计算机资源,实时监控资源使用情况,托管不同应用,为医患人员及相关机构提供共享的医疗数据和服务,能满足新医改环境下区域卫生信息系统的需求,帮助医疗机构提升服务水平,改善地区群众就医体验,特别是社区及乡镇等基层医疗机构能一步迈进区域大医疗信息体系,共享信息化技术成果。
1 医疗信息化建设现状及面临的挑战
我国医疗信息化建设大体经历了单机用户、部门级系统应用、医院级系统应用3个阶段,现在正处于区域医疗探索阶段[1]。随着医疗体制改革的深入推进,一些大型综合医院及有实力的机构开始探索区域卫生信息化,以实现一定区域内医疗机构间医疗信息交换和共享,跨医院的信息交换平台逐步建立起来。目前,福建厦门在区域医疗卫生信息平台建设方面走在全国前列[2]。
尽管我国卫生信息化建设已取得了一定的成绩,积累了一些经验,但仍存在一些问题。卫生信息化建设还不平衡,基础建设较为薄弱,信息化资源利用率低。当前,医疗信息化建设面临的挑战主要表现在:
(1)医院信息应用不断增长,各类系统越来越多,结构越来越复杂。
(2)电子图像的存储,医疗数据呈爆炸式增长,数量级越来越大。
(3)医疗范围的扩大,各类标准概念越来越多,标准的统一规范日趋复杂。
(4)需要实现信息共享的系统越来越多。
(5)数据分析和统计越来越复杂,数据挖掘程度低。
(6)系统和数据风险越来越大。
(7)对操作人员要求越来越高,系统维护人员需要掌握的技能也越来越多,工作量和压力暴增。
建立基于云计算的区域卫生信息平台,能有效地改善上述所面临的挑战。云计算平台模式与传统模式比较,见表1。
2 云计算概念及相关技术
2.1 云计算概念
狭义云计算是指IT基础设施的交付和使用模式,指通过网络以按需、易扩展的方式获得所需的资源;广义云计算是指服务的交付和使用模式,指通过网络以按需、易扩展的方式获得所需的服务。它是网格计算、分布式计算、并行计算、效用计算、网络存储、虚拟化、负载均衡等传统计算机技术和网络技术发展融合的产物。旨在通过网络把多个成本相对较低的计算实体整合成一个具有强大计算能力的完美系统,并借助Saa S、Paa S、Iaa S、MSP等先进的商业模式把这强大的计算能力分布到终端用户手中。
云计算的核心思想,是将大量用网络连接的计算资源统一管理和调度,构成一个计算资源池向用户按需服务。其基本原理是利用非本地或远程服务器(集群)的分布式计算机为互联网用户提供服务(计算、存储、软硬件等服务)。用户根据需求访问计算和存储系统。
2.2 云计算的特点
和传统的单机或网络应用模式相比,云计算具有以下显著特点:
(1)虚拟化。云计算建立在虚拟机(VM)技术之上,软件和服务都置于云中,基于各种标准和协议,实现不同设备间的数据与应用共享。
(2)高可靠性、安全性和可扩展性。用户数据、应用程序、计算统统由服务器端来处理。所有的服务分布在不同的服务器上,如果节点出问题就终止并启动另一个节点,保证了应用和计算的正常进行。设备和服务可动态伸缩。
(3)高性价比。云计算对用户端的硬件设备要求低,根据用户的需求来部署相应的资源、计算能力、服务及应用,大大降低前期资本投入。
(4)共享性。众多用户分享资源,避免单一用户承担较高的费用或者有限的资源无法被充分利用。
(5)超大的存储和计算能力。用户可采用任何设备登录云计算系统进行计算服务。云端由成千上万甚至更多服务器组成的集群具有超大存储能力和计算能力。
(6)数据、软件在云端。云计算模式下,用户数据存储在云端,并由服务商负责维护,当个人计算出现故障,不会影响该用户对其软件的使用。
2.3 云计算关键技术[3]
随着并行计算、虚拟化、面向服务架构(SOA)等技术的发展,计算方法、存储方式、服务模式不断创新,云计算得到快速推广。
(1)虚拟化作为云计算的核心特征,是云计算依托的基础。虚拟化技术是指计算元件在虚拟的基础上而不是真实的基础上运行,它可以扩大硬件的容量,简化软件的重新配置过程,减少软件虚拟机相关开销和支持更广泛的操作系统方面。
(2)Iaa S/Paa S/Saa S服务模式。服务模式创新是云计算的一个重要特性。云计算彻底实现了计算机软硬件都是服务的变革,用户所需要的仅是服务,包括:计算服务、网络服务、软件服务、平台服务、存储服务等。
(3)海量分布式存储技术。为保证高可用、高可靠和经济性,云计算采用分布式存储的方式来存储数据,采用冗余存储的方式来保证存储数据的可靠性,以高可靠软件来弥补硬件的不可靠,从而提供廉价可靠的分布式存储和计算系统。
(4)数据管理技术。云计算系统对大数据集进行处理、分析向用户提供高效的服务。云系统的数据管理采用列存储的数据管理模式,保证海量数据存储和分析性能。
(5)并行编程模式。云计算大部分采用Map Reduce编程模式,将任务自动分成多个子任务,将并行化、容错、数据分布、负载均衡等放在一个库中,通过Map和Reduce两步实现任务在大规模计算节点中的调度和分配。
3 基于云计算的区域卫生信息系统的架构实现
基于云计算的区域卫生信息系统构建能够满足海量医疗数据的存储和访问。采用多个服务器集群协同工作,系统高效稳定,数据安全性高,医院能在短时间内完成自身信息系统的部署,降低硬件成本和管理成本,减少由于本地误操作带来的数据丢失的风险。
基于云计算的区域卫生信息平台的组成,见图1。平台为每一个用户都创造了一个完全独立的虚拟系统环境,在每一个用户看来,自己都是云计算平台唯一的用户。用户可以通过多种不同的终端,例如:台式计算机、便携式计算机、手机甚至智能家电接入云计算平台。这让云计算平台的使用非常方便。特别是随着物联网的发展,云计算将在医疗信息化中体现出独有的优势。
基于云计算的区域卫生信息平台的架构,见图2。从系统架构的角度看,云计算平台主要由Web层、负荷分配层、数据管理层、计算逻辑层、物理计算设备层和物理存储设备层组成。
(1)Web层。Web层负责实现云计算平台的Web站点,该站点是用户访问云计算平台的唯一接口。负责用户访问、注册、服务订制,及服务状态查询等。用户可以通过电脑,手机等终端接入客户端服务器,选择合适的信息服务,注册活得授权后,可实时查询、订制、管理相关服务。
(2)负荷分配层。负荷分配层是云计算平台的核心部件。该层具有4个主要功能:(1)将用户的计算任务划分成若干部分,并决定执行每一个任务的计算设备;(2)将待存储的数据划分成若干部分,并决定相应的存储设备;(3)将计算逻辑层返还的计算结果整合后,再反馈给用户;(4)根据数据读取请求,指令数据管理层读取数据,并将数据整合后输出。
(3)数据管理层。数据管理层主要控制数据存储设备进行数据读写操作。它是各种数据在统一标准下的集合,包括健康档案基础数据、元数据、医学图像数据等。
(4)计算逻辑层。计算逻辑层负责根据负荷分配层确定的计算任务分配方式,控制具体的计算设备进行计算,并在计算完成后返还结果。
上述4层组成了云计算平台的软件部分。物理计算设备层和物理存储设备层代表了云计算平台所整合的所有物理设备,它们组成了云计算平台的硬件部分。最后通过HTML,用AJAX等客户端技术将管理和使用界面根据不同用户所具有的权限呈现给医疗卫生部门及患者等用户。
下面讨论几种可用于实现区域医疗信息化云计算平台的重要软件技术。
(1)面向服务架构[4]。面向服务架构(SOA)的软件体系,具有面向业务、粗粒度、基于服务、松散耦合和动态绑定等特点。能够支持用户对界面、业务逻辑、数据等方面的个性化需求,以满足不同医院之间的业务需求。SOA以服务为基本功能模块,根据用户需求,将每一种主要功能都包装成服务的形式,且各服务相互独立,仅以可扩展置标语言(XML)进行通信。当任何一种功能需要更新时,只需要更换相应的服务即可。基于SOA架构,可以将若干服务自由组合,极大地提高系统的灵活性和软件开发升级的速度。在服务架构时,遵循“自治性、松散耦合性、抽象性以及规范化的契约”等原则[5,6,7]。
(2)Apache。Apache由于其跨平台和安全性,成为目前应用最广泛的Web服务器端软件,其支持所有主流的Web服务器功能,如网站内容管理、服务器端编程、流量管理、网址重写、安全传输层和安全套接层加密等。由于Apache系开源软件,其源代码完全公开并可以免费使用,因此,可用于实现云计算平台的Web层功能。
(3)Google GFS。GFS系统由一个Master和大量块服务器构成。Master存放文件系统的所有元数据,包括名字空间、存取控制、文件分块信息、文件块的位置信息等。GFS中的文件切分为64MB的块进行存储。在GFS文件系统中,采用冗余存储的方式来保证数据的可靠性。每份数据在系统中保存3个以上的备份。为了保证数据的一致性,对于数据的所有修改需要在所有的备份上进行,并用版本号的方式来确保所有备份处于一致的状态。客户端不通过Master读取数据。避免了大量读操作使Master成为系统瓶颈。客户端从Master获取目标数据块的位置信息后,直接和块服务器交互进行读操作。
除上述讨论的几种技术外,目前还存在多种可用于实现云计算的商用或开源软件技术,如Google Map Reduce,Big Table,Hadoop的HBase等。各种新技术在医疗卫生信息中的应用需要我们进一步积极探索研究,努力提升医疗信息化水平。
4 总结
云计算的快速发展,为医疗卫生信息化建设带来了新的发展机遇。其智能管理算法和整合开发设计,为解决医疗信息化建设中信息资源的综合开发提供了崭新的思路。基于云计算的区域卫生信息系统管理方便、投资灵活、易扩展,对基层医疗单位技术人员要求低,适合我国当前卫生信息发展情况以及正在进行的医疗体制改革。充分发挥云计算的特点优势,迅速构建起以国家为主导、各省级为主要区域平台的卫生信息系统,对提升我国医疗系统信息化水平,提高医疗服务质量,实现为群众提供安全、有效、方便、价廉的医疗卫生服务的总体目标具有重要的意义。
摘要：在分析当前医疗卫生信息系统现状的基础上,对云计算的概念、特点及相关技术进行了简要概述。提出了基于云计算的区域卫生信息系统平台的架构;介绍了可用于实现区域医疗信息化云计算平台的重要软件技术。
关键词：云计算,区域卫生信息化,系统构建
参考文献
[1]竟博.中国医疗信息化现状分析[EB/OL].(2008-10-19)[2011-05-11].http://www.ccw.com.cn.
[2]孙卫.区域卫生信息化建设实践与体会[C].北京:2010中华医院信息网络大会,2010.
[3]张为民,唐剑峰,罗治国,等.云计算深刻改变未来[M].北京:科学出版社,2009.
[4]宫淑云.SOA在医院信息系统中的应用研究[D].武汉:武汉理工大学,2008.
[5]蒋笑欢,等.RIS-PACS系统社区卫生服务中心的应用[J].中国医疗设备,2010,25(6):55-56.
[6]黄祥国.医学图像在局域网中的多种传输方法[J].中国医疗设备,2010,25(9):37-39.
区域计算机连锁系统 篇4
基于云计算的区域教学资源公共服务模式的在线教育视频点播网站的开发将使视频检索模式转变成信息管理模式，通过调研之后，我们认真进行需求分析，对现有的管理模式进行改进，从中领悟系统开发的思想，掌握系统开发的流程和方法，并开发出一套新型的管理系统。事实上，在线教育的共享资源已经成为教育企业增加市场竞争力的一种重要手段，也是国内教育发展的一个方向，采用现代化远程教育模式将具有较高科研水平和丰富教学资源的高等院校与分散于各部门的人员联系起来，建立起可满足各种学习需求的“虚拟网校”，使天各一方的师生跨越时空的限制，进行学习和交流，在线教育视频网站必将是构建现代教育体系、实现终身教育和泛在学习的必由之路。、
1 视频点播简介
视频点播，指的是按照用户的具体要求播放相关的视频，包含娱乐、教育、商业等多领域的具体应用，如在线影片点播，节目直播、远程教学和电视会议等等。视频点播是一种由用户主导的视频分配业务，其实质是就是信息的使用者根据自我需求主动获得视频信息。但是与传统的电视播放不同的是，视频点播具有交互的特性，即用户可根据个人需求选择视频，何时播放。而传统电视播放是早已安排好的，用户在选择和观看视频方面是被动的，没有具体播放控制和其他操作的权利。还有不同的是，视频点播系统中的视频的信号是数字化的，而传统电视中的信号却是是模拟的。
2 系统设计方案
2.1 系统设计的基本思想
(1）使用B/S开发模式，使网站最大优势是前台与后台的交互方便，也符合大多数用户的网页浏览方式。
(2）本系统使用面向对象的设计思想和开发技术。面向对象技术前置条件是类型承担某些职责的时候需要一定的资源，后置条件是客户遵守了条件，类型必须兑现其承诺，以此来确保该系统很好框架模式，使产品更加的可靠、健壮以及高效率的运行。
(3）本系统采用模块化设计原则。它的设计要求会根据整个系统划分成更小的模块，帮助代码的加载，以便于系统过程的实施和简化。
(4）系统界面简洁大方。这个系统的设计比较简单，良好的视觉效果，用户运行系统会快速、容易的适应。
(5）速度优先原则。因为这个系统最主要的评估准则是运行速度，所以在开发过程中，尽可能地占用空间少，使速度更快。
(6）设计既要突出重点，又要细致周到。要符合设计需求，在有可能改进的地方进行扩充，使系统更适应用户的需要。
2.2 系统总体设计和要求
设计了一个基于云计算的区域教学资源公共服务模式的在线教育视频点播网站的B/S模式，该系统主要面向两类用户：注册用户和管理员。未注册的游客主要功能包括：注册用户、用户登录、浏览视频；而注册的用户可以搜索，观看，上传各种视频，搜索，提交留言等多项操作；管理员主要功能包括：视频课程信息增加，修改，删除，查看，浏览，会员管理，修改密码，留言管理、公告管理等。在B/S模式的技术上，使用SSH框架（Struts+Spring+Hibernate），根据目前工作流系统的主要特点构建一个跨平台的在线教育视频点播系统，可支持运行任何操作系统。要求学习掌握Java,JDBC,JSP技术、SSH框架技术、xml解析技术、html,java script客户端技术。系统能快捷有效、安全可靠的完成各种操作。客户端的界面简单易操作，服务器程序有利于维护。
2.2.1 前台功能模块设计
用户必须先注册才能进行登录。如果用户没有进行登录就进入网站，那么他就只能够以游客的方式播放视频的功能。只有当游客注册成为会员后，游客才能进行有关权限的操作。主要包含以下几个操作：（1）视频浏览：用户可以通过视频分类和点击排行以及最近更新来浏览最新的课程；（2）视频搜索：用户可以根据视频名称和作者进行查询；（3）视频上传：用户可以将自已的视频上传到网站；（4）视频播放：用户对有兴趣的课程视频可以通过播放器实现在线播放；（5）视频留言：用户可以对课程视频进行留言；（6）查看/修改信息：用户可以查看并修改自己的信息。
2.2.2 后台功能模块设计
这是本系统的重点，管理员是功能最多的一种用户角色，可以添加修改删除注册用户，并可以根据需要添加或删除视频。具体功能如下：（1）添加视频：可以在各个栏目进行课程视频的添加工作；（2）视频管理：可以对所有视频进行删除、修改、新增操作；（3）分类管理：可以在各个栏目进行类别的添加工作；（4）网站公告信息管理：可以网站公告进行添加和删除操作；（5）用户管理：对注册用户进行删除等操作；（6）留言管理：对视频的留言进行删除等操作。
2.3 系统开发工具及数据库设计
本系统主要基于SSH框架、采用JSP技术、JAVA语言编写和My SQL数据库技术，利用My Elpise开发工具和Tomcat本地服务器。系统利用Hibernate的数据库管理方式]。JDBC的对象封装被它运用，并且它的对象关系的映射框架是一款开源的，也就是说，程序编写人可以随时随地使用面向对象的编程思维来执行数据库。它不但提供了Java数据的查询与恢复方式，而且还可以提供类和表之间数据的映射关系。相对于使用写入SQL语句来进行手动操作，Hibernate在很大程度上降低了数据库的负载。进一步来说，Hibernate能够直接使用代理的方式，从而来简化加载类，在某种程度上就极大地降低了运用数据库的代码来得到数据的使用量，与此同时，就缩短了开发周期，节约了财力和物力。Hibernate可以跨平台，与不同类型的Web Server和Application Server结合的很好，现在，它支持各种在市场上比较受欢迎的数据库服务器数据库的设计是一般指据用户的需求来设计数据库结构并且应用数据库的过程。在通常情况下，数据库的设计流程可以分为五个阶段，即：需求分析设计、概要设计、逻辑结构设计、物理设计和实施运行。
本系统采用My SQL数据库管理，具体详细的表有：（1）视频信息表（Video），用来记录视频节目的各种相关的信息；（2）视频留言表（Liu Yan）,该表用来记录注册用户对视频留言的相关信息；（3）视频类别表（Categories），该表用来记录视频网站中，各种不同类别的视频信息；（4）管理员表（admin）,该表用来记录网站管理员的相关信息；（5）普通用户表（Users），该表用来记录网站注册用户的具体信息；（6）公告信息表（t＿gonggao），该表主要记录公告的基本信息。
3 系统功能实现
在项目的开发过程中，通过对系统的需求分析、概要设计、数据库设计后，系统的实现阶段就要开始了。在系统需要分析、概要设计和代码编写中，主要的工作是逻辑功能的实现，以上不同阶段的工作效果将被系统功能的实现阶段所承载。把技术上的设计转变为物理实施，所以，系统功能的实现是各个阶段的重要成果。
3.1 前台主要模块功能实现
3.1.1 在线教育视频点播系统首页
系统的主界面是网站首页，显示的主要内容有视频的详细信息、用户的注册和登录部分。视频的类别，用户可以根据自己的要求选择不同类型的课程从而进行浏览；视频的搜索，用户可以在搜索框中，对课程名称或者作者进行搜索，得到需要的信息；视频信息的显示，主要是显示用户选择课程的详细的信息；网站的公告，用户可以获知网站的通知等相关的最新动态；排行榜和点击榜，网站将最新发布的课程信息以及点击率最高的课程信息在页面发布，用户可快速浏览节目。首页面如图1所示：
3.1.2 用户的登录和注册
用户执行视频的观看等操作时，必须是网站的注册用户。首页的上面有登录和注册的按钮，通过点击跳转到相应的模块。如图2所示：
注册和登录的逻辑代码实现：
3.1.3 视频播放页面
进入该页面时，点击就可以播放视频，在实现视频播放的功能上，利用在页面中嵌入微软的Windows Media player播放控件的方法来实现，播放结束会自动停止，留在原系统，等待用户操作，如图3所示。
此外还有用户视频上传、用户搜索视频模块、用户评论模块、用户评论及留言、管理员后台管理、用户信息管理、留言信息管理等模块设计页面及逻辑代码实现等。
4 结束语
通过系统的分析设计，系统的开发工作已经完成。经过测试，基于云计算的区域教学资源公共服务模式的在线教育视频点播在系统的设计和开发基本达到预期的要求，基本实现了预期的各种功能。当然也有许多不足之处和需要改进完善的地方。在设计过程中，我们在收集整理相关参考文献的基础上，概述了视频点播的相关技术和概念，并通过对比等分析方法，做出了一些总结。讨论了该系统中的若干关键技术，分析了构建过程中的一些问题，并针对问题给出了比较合适的解决方案。但网系统仍然有许多不尽如人意的地方，如网站系统功能不够丰富强大，用户的界面不够美观方便等多方面问题，所以暂未对视频数据的传输，编码格式，多用户，高并发等方面做深入的研究。
参考文献
[1]冯玉琳,钟华.现代软件技术[M].化学工业出版社.2004.
[2]一个新型网络管理系统模型设计与实现[J].计算机工程与应用,2002,38(8):154-156.
[3]刘志成.Java程序设计案例教程[M].清华大学出版社.2006.
[4]李建中,王珊.数据库系统原理(第2版)[M].电子工业出版社.2004.
[5]郝玉龙.Java EE编程技术[M].北京:北京交通大学出版社.2009.
[6]邓子云.JSP网络编程从基础到实践[M].北京:电子工业出版社.2007.
[7]陈文兰.基于SSH集成架构的进销存管理系统的设计[J].农业网络信息,2010(7):44-45.
[8]王军豪,彭岩.Hibernate+Struts+spring整合技术在电子政务中的应用.计算机工程与设计,2008,29(6):1409-1412.
[9]艾灵仙.高校系级网站构建平台的设计与实现.[J].科技信息,2008(16).