影像验证系统（精选7篇）
影像验证系统 篇1
利用影像引导技术(IGRT)的立体定向放射外科(SRS)治疗已逐渐成为放疗乃至精确放疗的发展方向。射波刀(CyberKnife)是将一台光子能量6MV的小型直线加速器安装在一个拥有6个自由度的机器人手臂上,利用先进的实时影像引导系统及同步追踪系统对患者进行自动摆位及跟踪治疗[1],治疗精度可达亚毫米,是目前世界上最为精确的放射治疗设备。
射波刀的治疗精度主要依赖于影像引导系统、同步追踪系统、机械臂运动系统。修正摆位误差及治疗过程中的实时追踪更是依赖于影像及同步追踪系统自动分析得出的数据[2]。其数据为计算机自动分析得出,不具有直观性。笔者决定利用模拟定位机对射波刀影像同步追踪系统自动分析得出的靶区运动数据进行分析,验证其追踪数据的准确性。
1 材料与方法
1.1 材料仪器
射波刀,美国Accuray公司,第四代(GⅣ);
模拟定位机,荷兰Nucletron公司,Oldelft Simulix HP;
Synchrony模体,美国Accuray公司,Synchrony Motion Table;
Xsight Lung模体,美国CIRS公司,LTT Dynamic Phantom。
1.2 方法
1.2.1 射波刀下Synchrony模体、Xsight Lung模体六维方向运动测量
将Synchrony模体摆放于射波刀治疗床,调用E2E对应Synchrong验证计划[3],曝光条件120 kV、100 mA,使六维方向摆位误差均≤0.2 mm/0.2°。对模体建立呼吸模型,采集呼吸周期中一、三、五、七相位时的运动数据。通过调整Synchrony模体运动速度获得不同呼吸速度下影像系统及同步追踪系统获得的运动数据。
Xsight Lung模体测量时,先进行Xsight Spine摆位,后转入Xsight Lung模式进行建模。获取靶区运动数据。
1.2.2 模拟机下Synchrony模体、Xsight Lung模体三维方向运动偏差
将Synchrony模体摆放于模拟定位机治疗床,曝光条件50 kV、10 mA,在机架分别处于0。及90°人工记录下模体内6粒金标(Fiducials)各自的的运动幅度,取其均值进行L/R、A/P、I/S方向运动分析。
将Xsight Lung模体放于模拟定位机下,观察模体内小球运动,进行数据测量。
2 结果
2.1 射波刀下Synchrony模体、Xsight Lung模体六维方向运动偏差
测量结果显示,改变Synchrony模体的运动速度对其运动幅度无影响,取均值后六维方向运动结果参见表1,运动幅度为I/S方向22.9 mm。Xsight Lung模体的六维方向运动结果参见表2,运动幅度为I/S方向29.1 mm。Synchrony模体及Xsight Lung模体的运动模式均为头脚方向(I/S)匀速运动。
2.2模拟机下Synchrony模体、Xsight Lung模体三维方向运动偏差
Synchrony模体的六维方向运动结果参见表3,运动幅度为I/S方向23.0 mm。Xsight Lung模体的六维方向运动结果参见表4,运动幅度为I/S方向30 mm。
Synchrony模体在模拟机下测得的数据与射波刀影像系统及同步追踪系统分析得出的运动数据误差别为0.1 mm,Xsight Lung模体下二者的误差为0.9 mm,均小于1 mm。
3 讨论
验证射波刀的影像引导系统和同步追踪系统的准确性对于开展临床治疗、做好射波刀质量控制与质量保证具有重要的指导意义。若对真实病患进行测量,受环境因素影响较大。模体受环境影响较小,所追踪的目标靶区刚性、重复性、周期性也较真实病患好,且呼吸波形均为正弦波,易于采集峰值数据,测量比对结果更加具有说服力。
射波刀影像引导系统由一对固定在患者两侧天花板处的诊断用X射线管及安置于地面上的非晶硅影像探测器组成,与患者形成45°与315°正交拍片,获得病人的空间数据[3]。以Synchrony模体为例,模体内分布6粒金标,构成一定空间结构。影像系统依据两张正交影像获得6粒金标的空间位置,与由定位CT获取得到的数字化重建影像(digitally reconstructed radiograph,DRR)进行比对,获取六维运动信息(三维平移数据、三维旋转数据)。模体运动仅存在I/S方向匀速运动,在模拟定位机环境下,采取0°与90°正交拍片,可以更加直观明了地寻找模体中心并观察运动,获得较准确的运动数据。
结果表明,使用Synchrony模体测量,模体内金标数目>3,构成立体空间结构,刚性程度高,射波刀影像引导系统获得的峰值相位六维方向的运动参数稳定,扰动误差均≤0.1 mm/0.1°。通过Xsight Spine摆位计划获得Xsight Lung模体旋转数据,而后期的肺追踪计划只获得追踪靶区的三维运动(1/R、A/P、I/S方向),且计算机分析获取的运动数据扰动较大,I/S运动方向扰动更是高达4.5 mm,需要通过拍摄多组峰值相位才能获得真正的运动极限值。由此可见,Xsight Lung追踪方式类似于1粒金标的Synchrong追踪方式,追踪空间数据不足,≥3粒金标的Synchrong追踪方式可获得更加理想精确的追踪治疗。同时亦说明,在使用Xsight Lung追踪方式进行呼吸建模时最好采取自动建模与手动建模相结合,拍摄多组数据,建立更加贴近肿瘤运动的真实模型。
因此利用模拟机测量所得数据与射波刀影像追踪系统分析所得数据相符,该测量方法具有可行性。
参考文献
[1]沈君姝,耿薇娜,王朋,等.射波刀追踪方式分析.生物医学工程与临床,2011;15(5):502-504
[2]王境生,李丰彤,袁智勇,等.射波刀Xsight患者六维方向数据分析.医疗卫生装备,2012;33(2):128-129
[3]沈君姝,耿薇娜,王朋,等.射波刀的物理质量保证和治疗控制.生物医学工程与临床,2012;16(2):193-196
[3]王朋.射波刀的影像引导放疗技术优势.医疗卫生装备,2010; 31(11):118-119
系统维修性验证概述 篇2
维修性是产品在规定的条件下和规定的时间内, 按规定的程序和方法进行维修时, 保持、恢复或改进其规定状态的能力。维修性对产品的完好性与工作持续能力是至关重要的, 是产品的一种质量特性, 属于产品的五性之一, 主要表现在产品的维修过程中, 可以用一些定性的特征和一些定量的参数来表达。维修性验证是指为确定产品是否达到规定的维修性要求, 由指定的试验机构进行的或由订购方与承制方联合进行的试验与评定工作。其目的是全面考核产品是否达到规定的维修性要求, 可分为定性指标验证和定量指标验证。
1 系统维修性验证概念模型
以产品各组成部分的设计参数、结构特征、故障分布规律、使用环境和条件等作为输入数据, 通过结构建模、功能建模、故障建模、维修分析、保障资源需求分析、专家评估等方法和手段, 以规定的分析和评价模型为基础, 由试验单位在规定的条件和环境下按照规定的程序进行维修性验证, 图1为系统维修性验证概念模型。
2 维修性验证方法研究现状
美军早在上世纪50年代就颁布了MIL-STD-470、MIL-STD-471等维修性标准体系, 制定了MTD系列车辆装备维修性试验规范, 形成了较为完善的车辆装备维修性试验与评定体系。英国和北约紧随其后, 在20世纪80年代初开始颁发Def Stan 00-40、00-41等标准和ARMP系列标准。20世纪90年代美军基于全寿命全系统而颁布的MTP 2-2-503《车辆维修试验》、MTP 2-2-502《维修性能试验》、MTP 2-3-527《维修工具和测试设备的评价》和MTP2-3-528《维修说明书和手册的评价》制定了一系列车辆维修性专用试验标准。随着科技的不断进步, 我国在上世纪80年代针对飞机使用和维修制定了我国第一套维修性方面的标准《飞机维修品质规范》, 后来引进美军的维修工程和维修性工程, 根据实际编制了《产品维修性通用规范》。随着改革开放进程的不断加快加深, 产品维修性验证的标准《维修性试验与评定》、《维修性设计与验证》等一系列专著发布对我国维修性工程理论和实践研究推动了我国维修性验证的进程。
2.1 基于经典数理统计学的验证方法
多年来, 美国在维修性领域一直处于领先地位。美军MIL-HD-BK-470A《维修性手册》中对维修性验证的规定主要包括维修性试验规划、验证指标、试验方法、验证环境和要求、作业抽样等内容, 并针对车辆提出了8种维修性验证方法, 如表1所示。其中很详细的规定了维修性验证的每一规程, 是美军实施维修性验证的规范。
目前国内最为成熟、应用最为广泛的方法均是在方差已知或能够进行估计的前提下进行, 而在实际操作中, 由于产品的日益复杂化导致产品各子系统工作方式、工作时间等存在着众多不同之处, 使得维修性验证中样本量的确定和样本的选取与分配都面临着很大的困境。
2.2 基于Bayes理论的小子样维修性指标验证方法
Bayes方法是基于总体信息、样本信息和先验信息进行的统计推断, 是一种解决小子样问题的方法, 起源于英国学者贝叶斯《论有关机遇问题的求解》论文, 现已在工业、经济、管理等领域内获得一批无可非议的成功应用。它与经典统计学的主要差别在于是否利用先验信息, 优势是可以很好地处理来自不同方面、不同层次的信息, 提取其中的有用信息并加以综合, 从而可以有效地降低现场试验样本量, 节省试验投入, 缩短试验周期, 且能保证足够的可信度。验证步骤一般如下:
(1) 确定维修时间总体分布;
(2) 确定检验前分布;
(3) 小子样维修性验证;
(4) 一致性检验与稳健性检验。
基于Bayes理论的小子样维修性验证方法是对经典维修性验证方法的改进, 很好的解决了样本需求量大、多层次样本难以选取的困难, 节省了时间和资金, 具有重要的研究价值。但是, 目前小子样维修性试验与评定仍然存在一定的问题, 其在获取先验分布中的超参数上有一定的困难, 如实际工程实践中, 怎样收集大量的相关数据来确定参数后验分布等情况。
2.3 基于相似学原理的维修性验证方法
针对现在产品的复杂程度日益提高, 产品的参数曲线多表现为一种双峰或多峰分布, 如图2所示。由于产品各子系统的独立性和复杂性, 利用简单的传统验证方法已经不能精确直接的进行维修性验证。郝建平等提出了一种依据MTTR曲线的相似程度将各系统分组、对组进行验证的方法——基于相似学原理的MTTR分组验证方法。该方法根据相似学原理确定各系统MTTR曲线的相似度, 再用分层重点分组方法对曲线进行分组, 再运用传统的验证方法对各组进行验证。虽然目前这种理论仅限于理论层次, 但是其可避开直接对多峰分布的MTTR曲线进行验证, 为复杂产品MTTR的验证提供了新的思路。
3 维修性指标样本获取研究现状
样本获取是维修性验证中最基础最重要的一环, 是决定验证准确度和有效性的根本。根据获取手段的不同, 样本获取可以分为统计试验获取、流程估算获取、建模仿真获取等。
3.1 采用实物试验获取
实物试验是维修性验证中应用最广泛也最成熟的一种技术手段, 从严格意义上讲应该通过产品全寿命周期试验来实现产品的试验环境真实性, 但无论从时间还是费用角度考虑这都是不现实的。目前应用最多的是在定性分析评估的基础上, 采用演示验证的方法, 以较少的样本量, 耗费较短的时间和较少的费用对产品维修性是否符合维修性要求做出判决, 图3为维修性试验的一般流程。利用实物试验的维修性验证的优点是贴近实际, 直观可靠, 劣势是耗费时间和费用相对较高, 受环境影响大, 样本选取困难。
3.2 通过流程估算分析获取
流程估算是指针对新产品的维修性特点, 将新产品的维修工作分解到要素级, 如分解、隔离、重新配装、调校检查等, 然后与已有的相似产品进行要素对比, 根据之间的差异和历史经验数据估算出新产品各个要素的消耗时间, 进而得到整车的维修性时间指标。将流程估算和演示验证相结合来进行新产品的维修性验证是目前大多采用的数据获取手段。该系统具有试验方法选择、分布类型选择、选择和分配维修作业样本、样本量计算、样本数据统计及维修性定量指标评定等功能。其优点是方便快捷, 节省资源, 涵盖面宽, 适于定性指标分析, 劣势是精准度不够高。
3.3 利用虚拟仿真获取
虚拟仿真是将系统模型用一组程序和数据来描述, 并使其在数字计算机上运行。英国索尔福德大学虚拟环境研究中心的Luis Marcelino等针对虚拟维修的特性开发了虚拟维修人员培训系统和维修保障设备管理系统。德国弗劳恩霍夫工业大学的Eberhard Bluemel等针对不同维修训练模式 (演示模式、指导模式、自由模式、探索模式) 开发出虚拟维修训练环境。2001年法国IRISA、CERV实验室和Nexter-Group这三个组织联合开发了一个通用的GVT虚拟训练平台 (Generic Virtual Training) 。2005年, 英国BAE系统公司在其“狂风航空训练设备” (Tornado Avionics Training Facility) 的基础上推出了一个可重用的虚拟训练框架VORTEX (Virtual Reality Training Executive) 。
近年来, 我国在数字计算机仿真研究越来越多, 但离世界先进水平仍有一定差距。北京理工大学的项昌乐教授等提出采用虚拟现实技术和维修工程力量, 搭建了装甲装备虚拟维修仿真平台, 实现了非沉浸式虚拟维修过程仿真, 为新产品方案论证和研制初期提供了维修性中的可达性等定性指标的定量化分析和验证的可行方法。南京航空航天大学的孙有朝教授等研究了民用飞机维修性指标虚拟评估与验证的基本方法和程序, 提出了虚拟环境中进行可达性分析、碰撞与干涉分析以及维修姿态分析的综合集成法。北京航天航空学院的刘瑞教授等开发出考虑人员因素分析的基于虚拟环境的维修性评估系统。同济大学的刘毅等从节能节时节费和提高航母维修性的角度开发了基于虚拟维修的航母仿真系统。于永利在《A maintainability analysis visualization system and its development under the Auto CAD environment》一文中提出在Auto CAD环境下建立维修性分析虚拟系统。北京科技大学可视化实验室的康荣丽等根据虚拟技术、Jack软件、硬件开发了虚拟维修性分析系统VMAS。
4 研究展望
综上所述, 已有的研究工作促进了维修性验证的发展, 但目前维修性验证在理论和实际应用研究中还存在一定的问题, 对维修性验证进一步的研究仍然具有很高的研究的价值, 主要体现在以下两个方面:
4.1 提高产品的效益价值
在产品设计与研制过程中, 对产品的维修性进行充分的验证, 有助于提高产品的维修性, 进一步提高产品的完好性与可靠性。产品的完好性与可靠性, 体现在实际之处, 就是在同等情况下, 维修性验证越充分的产品, 维修率更低, 维修更为方便, 对维修保障的要求的更低, 产生的效益更大, 产品的效益价值较高。
4.2 提高产品的使用价值
GSM-R系统功能验证 篇3
1 GSM-R系统网络构成
由于网络结构变化、设备升级, 以及设备故障处理等原因, 需要对GSM-R系统功能进行验证, 因此首先要了解系统构成 (见图1) 及各组成部分的功能。
1.1 移动交换子系统
移动交换子系统包括移动交换中心 (M S C) 、归属位置寄存器 (HLR) 、访问位置寄存器 (VLR) 、鉴权中心 (AuC) 、组呼寄存器 (GCR) 、自动确认中心 (AC) 、短消息业务中心 (SMSC) 、关口移动交换中心 (GMSC) 。
(1) MSC:具有呼叫建立、保持、释放、认证、呼叫转接、短信息、计费等功能。
(2) HLR:存储MSC中所有用户的数据和信息。
(3) VLR:用于存放漫游到此端局下的临时用户数据, 物理上与MSC合设。
(4) AuC:用于产生用户鉴权数据, 物理上与HLR合设。
(5) GCR:铁路GSM-R系统特有设备, 服务于广播呼 (VBS) 和组呼 (VGCS) , 用于存放组呼信息。
(6) AC:用户终端挂断紧急呼叫 (299) 后, 自动去AC进行登记, AC中记录参加此次紧急呼叫的成员信息。
(7) SMSC:通过SMSC将短消息发送到指定的手机。
(8) GMSC:主要负责互联其他通信网络, 物理上与MSC合设。
1.2 移动智能网子系统
移动智能网子系统包括业务控制点 (SCP) 、业务交换点 (SSP) 、业务管理点 (SMP) 。目前, 智能网在铁路中的应用主要是基于位置寻址、功能寻址和基于位置的呼叫限制等。
(1) SCP:具有业务控制和业务数据功能。
(2) SSP:具有呼叫控制和业务交换功能。
1.3 通用分组无线业务子系统
通用分组无线业务子系统包括业务支持节点 (S G S N) 、网关支持节点 (G G S N) 、域名服务器 (DNS) 、远端拨入用户认证服务器 (RADIUS) 、GPRS归属服务器 (GROS) 、GPRS接口服务器 (GRIS) 。
(1) SGSN:主要完成分组数据包的路由转发、移动性管理、会话管理、逻辑链路管理、鉴权和加密、话单产生和输出等。
(2) GGSN:主要是GPRS业务网关作用, 完成会话管理、话单产生和输出等。
(3) DNS:主要完成4类域名解析, 包括用于存储APN对应GGSN的IP地址解析、机车号对应的IP地址解析、路由区更新时路由区与SGSN地址解析、其他设备域名解析。
(4) RADIUS:用于对GPRS用户进行鉴权, 对合法机车用户分配固定IP地址。
(5) GROS:通过分析GPRS终端上传的消息, 判断终端应归属哪个GRIS管理。
(6) GRIS:是GPRS网络与其他应用系统的接口。终端CIR与CTC的通信由GRIS转发。
1.4 无线子系统
无线子系统包括基站控制器 (BSC) 、码型转换和速率适配单元 (TRAU) 、基站 (BTS) 、直放站、分组控制单元 (PCU) 。
(1) BSC:是基站收发台和移动交换中心之间的连接点, 也为基站收发台 (BTS) 和移动交换中心 (MSC) 之间交换信息提供接口。负责业务信道交换、信令信息处理和BSS系统监控。
(2) TRAU:负责对话音进行编解码, 对数据进行速率适配。
(3) BTS:负责与MS之间无线信号的接收和发射、无线接口上信令的处理。
(4) 直放站:属于同频放大设备, 在无线通信传输过程中增强信号的无线电发射中转设备。
(5) PCU:提供与GPRS核心网的接口, 并完成数据传输业务。
1.5 操作维护子系统
操作维护子系统包括网管系统、监控系统、SIM卡管理系统。
(1) 网管系统:完成设备数据配置、性能管理、告警监控等。
(2) 监控系统:具有对设备、业务运用过程实时监测功能, 如对漏缆、接口监测等。
(3) SIM卡管理系统:主要完成SIM卡日常申请、激活、停用、补卡等业务管理。
2 GSM-R系统承载的铁路主要业务
GSM-R系统网络运营初期, 由于网络建设进度不一致, 导致系统业务存在跨局使用情况。在制定功能验证方案时, 不仅要考虑业务类型与设备, 还要考虑影响范围。例如呼和浩特铁路局GSM-R系统核心网尚未建成, 包西线的无线网一部分连接至北京核心网, 一部分连接至西安核心网。在北京、西安核心网施工时, 不能仅考虑本局业务, 还要顾及到呼和浩特铁路局的业务应用, 跨局业务影响需在实际应用中结合具体问题进行分析。
2.1 列控业务 (电路域CSD业务含locotrol)
列控业务涉及的网络设备包括HLR、MSC/STP、TRAU、BSC、BTS、RBC/AN (信号设备) , 其业务流程见图2。
2.2 语音联控业务 (电路域语音业务含组呼)
语音联控业务涉及的网络设备包括SCP、HLR、TMSC/MSC/STP、AC、TRAU、BSC、BTS、FAS (调度通信系统) , 其业务流程见图3。
2.3 调度命令、进路预告、无线车次号校核信息 (分组域业务)
调度命令、进路预告、无线车次号校核信息涉及的网络设备包括HLR、STP、DNS、RADIUS、GROS、GRIS、GGSN、SGSN、BSC、PCU、BTS。
3 功能验证的不同阶段
GSM-R系统功能验证涵盖范围较广, 在系统建设和维护不同时期, 其功能验证的侧重点也不相同, 大致分为3个阶段。
3.1 新 (版本、型号) 设备入网功能验证
GSM-R系统是基于公网GSM技术发展起来的, 随着公网技术的发展演变, 各种新版本、新型号的设备将投入现网中应用。设备厂家减少原设备的研发技术力量, 并受旧版本设备备板不足等影响, GSM-R系统设备升级换代不可避免。由于GSM-R系统要求的安全性远高于公网, 因此设备厂家推出的新版本、新型号设备必须通过功能验证后才准许入网。
新版本、新型号设备的功能验证先在实验室进行, 验证内容根据设备实际情况制定。例如BSC等设备软件版本升级主要验证其升级后对铁路各种基本业务的影响, 以及该版本增加的新特性或解决的问题。又如某公司推出全新的软交换设备, 应依据铁道部相关技术规范对其进行全面测试, 包括与其他厂家间的互联互通测试。实验室功能验证是设备投入现网使用前的必要环节, 可为下一阶段功能验证打下良好基础。
3.2 工程期间网络互联功能验证
在GSM-R系统工程建设阶段, 新建网络必须与既有网络完成互联后才能进行联调联试, 功能验证重点是新建网络与既有网络互通性的测试。新建核心网络节点互联完成后与各既有核心网络节点间的功能验证, 是确保该核心网正式投入运营后跨局套跑机车业务正常使用的前提。在铁路工程建设过程中, 无论静态测试还是动态测试都是针对本条线路进行, 不包括与既有核心网络节点间的测试。随着新建线路的开通, 运输部门对列车运行图的调整将使跨局套跑机车逐渐增多, 在GSM-R系统核心网节点互联工程阶段, 其与既有网络的功能验证尤为重要。
3.3 运营期间网络结构调整、设备升级等功能验证
GSM-R系统正式投入运营后, 涉及现网设备的施工必须在“天窗”时间内完成, 功能验证的特点是在尽量短的时间内得到准确的验证结果。施工“天窗”内的功能验证是判断施工是否达到要求的主要手段, 通过对业务的拨测快速直观反映GSM-R系统通信业务正常与否。
4 功能验证测试环境
4.1 硬件配置要求
(1) 核心网机房内设置独立BTS设备, 并单独组成基站环。
(2) 核心网或调度机房设置FAS实验台。
(3) 核心网机房设置CIR (车载台) 终端设备。 (4) 手持终端2台以上。
(5) SIM卡 (机房测试卡) 。SIM卡测试用户在HLR中的业务开通状态见表1, 机房测试用的SIM卡状态见表2。
(6) 仪器仪表。信令仪表 (应能解析MAP、CAP、ISUP、BSSAP、PRI等信令消息) 、2 M误码测试仪、IP数据抓包工具。
(7) QoS测试系统 (包含CSD、GRPS地面测试服务器) 。
4.2 数据制作要求
(1) MSC、BSC中试验基站应分配单独的位置区 (LAC) +小区ID (CI) , 位置区应避免与现网数据重复。
(2) 核心网机房实验基站制作独立的组呼区域 (SA) , 制作299、210等组呼数据, 调度用户指向FAS实验台。
(3) 智能网SCP中制作试验基站1200、1300短号码数据, 调度和值班员用户均指向FAS实验台, 1612短号码指向AC确认中心。
(4) GGSN中制作本局测试用APN:TEST.XX, 并申请制作APN下的PDP激活测试用户名。
(5) MSC制作QoS测试系统地面服务器 (CSD) 测试号码。
(6) 分配QoS测试系统地面服务器测试用IP地址。
(7) 机房测试卡在HLR中的接入点名称 (APN) 应设置为“*”, 即无论终端填写任何APN用户都能正常使用。
5 GSM-R系统功能验证项目
(1) 互联电路状态检查。验证内容:检查互联局向中继电路、信令链路状态。验证结果:全部电路与信令链路状态应为激活可用状态。
(2) 使用MSISDN拨测。验证内容:手持台或CIR使用MSISDN号码进行拨测试验。验证结果:呼叫正常接通, 有回铃声, 双方通话正常, 且被叫方可以正确显示来电方MSISDN号码。
(3) 使用功能号码拨测。验证内容:手持台或CIR使用功能号码进行拨测试验。验证结果:呼叫正常接通, 有回铃声, 双方通话正常, 且被叫方可以正确显示来电方MSISDN号码及注册的功能号码。
(4) 功能号码测试。验证内容:手持台功能号码 (含车次功能号和机车功能号) 注册、注销、查询、强制注销。验证结果:注册为提示功能号码注册成功, 并在手持终端屏幕上显示已注册的功能号码;注销为提示功能号码注销成功;查询为正确显示查询用户注册的功能号码和MSISDN号码;强制注销为提示强制注销成功, 向被注销用户提示注册的功能号码已被注销。
(5) 与FAS台使用MSISDN互拨。验证内容:手持台或CIR使用MSISDN号码呼叫FAS台, FAS使用MSISDN号码呼叫手持台或CIR。验证结果:呼叫正常接通, 有回铃声, 双方通话正常, 且被叫方可以正确显示来电方MSISDN号码。
(6) 与FAS台使用功能号码互拨。验证内容:FAS台使用功能号码 (车次功能号、机车功能号) 呼叫CIR或手持台, CIR或手持台使用FAS台91功能号码呼叫FAS。验证结果:呼叫正常接通, 有回铃声, 双方通话正常, 且被叫方可以正确显示来电方MSISDN号码及注册的功能号码。
(7) 与铁路PSTN进行拨测。验证内容:手持台与铁路专用PSTN用户进行互拨。验证结果:呼叫正常接通, 有回铃声, 双方通话正常, 且被叫方可以正确显示来电方电话号码。
(8) 短消息测试。验证内容:手持台间互发短消息测试。验证结果:手持台发送短消息成功, 且接收方能够成功接收短消息。
(9) 短号码 (1200、1300) 呼叫测试。验证内容:手持台或CIR使用1200、1300短号码呼叫调度或值班员。验证结果:呼叫正常接通, 有回铃声, 双方通话正常, 且被叫方可以正确显示来电方电话号码 (手持台或CIR已注册功能号码的, FAS应能正确显示功能号) 。
(10) 分组域业务测试。验证内容:CIR进行分组域并附带与PDP激活测试。验证结果:CIR能够正确获取IP地址。
(11) 调度命令发送测试。验证内容:调度台给已成功PDP激活的终端发送调度命令。验证结果:CIR可以正确接收调度命令, 且调度台可以接收到手动签收回执。
(12) GRIS与GGSN Gi口互通性测试。验证内容:在GRIS上利用ping命令测试至北京与武汉DNS、GROS和各局GGSN Gi口的互通性。验证结果:ping测试数据包正常返回, 且平均延时在0.5 s以内。
(13) GGSN Gi口互通性测试。验证内容:在GGSN Gi口上利用ping命令测试至北京与武汉RADIUS和各局GRIS的互通性。验证结果:ping测试数据包正常返回, 且平均延时在0.5 s以内。
(14) GGSN Gn口互通性测试。验证内容:在GGSN Gn口上利用ping命令测试至北京与武汉DNS和各局SGSN的互通性。验证结果:ping测试数据包正常返回, 且平均延时在0.5 s以内。
(15) SGSN与GGSN Gn口互通性测试。验证内容:在SGSN上利用ping命令测试至各局SGSN和GGSN Gn口的互通性。验证结果:ping测试数据包正常返回, 且平均延时在0.5 s以内。
(16) 组呼功能测试 (299、210) 。验证内容:使用机房测试卡或联调联试测试卡发起299、210组呼 (注:FAS用户不能发起299组呼, 但可以接收;210组呼成员中不含调度员;涉及跨局组呼需要协调相关铁路局配合) 。验证结果:组呼正常发起, FAS用户通话正常, 手持台按PTT键可以正常抢占上行无线信道并通话。
(17) 语音切换测试。验证内容:保持语音长呼不挂断, 观察跨BTS、BSC、MSC时切换情况 (注:同一BSC下BTS调整时, 只测试跨BTS切换;同一MSC下2个BSC间无线网络调整时, 同时测试跨BSC及跨BTS切换;跨MSC无线网络调整时, 以上三种情况都需测试;测试条件不具备时, 切换测试可结合施工结束后的添乘工作一起进行) 。验证结果:语音呼叫保持正常, 未出现掉话等异常现象。
(18) 分组域路由区更新测试。验证内容:结合添乘工作进行, 首趟轨检车在通过跨路由区位置时, 核心网机房在Gb/Gn口抓包观察路由区更新情况。验证结果:抓包结果可以看到正常路由区更新消息, 且更新应在跨边界后的1～2个小区内完成。
(19) 话务统计功能验证。验证内容:在网管服务器上观察设备的话务统计原始文件采集是否正常, 并能生成话务统计报表。验证结果:文件采集正常, 报表统计功能正常。
(20) 计费功能验证。验证内容:用户进行呼叫等操作时, 观察设备是否计费。验证结果:经计费软件处理后的话单结果正常。
(21) 网管功能验证。验证内容:观察网管维护界面是否有异常, 执行命令情况和告警信息采集情况。验证结果:操作命令执行正常, 告警信息可正常采集, 且有声光告警提示。
(22) 漫游用户业务测试。验证内容: (2) — (11) , 使用漫游用户SIM卡进行测试。
6 功能验证测试案例
6.1 成都核心网互联功能验证
(1) 成都核心网为新建网络, 为工程期间的网络互联功能验证阶段。电路域完成与北京和武汉STP、武汉和西安TMSC互联, 分组域完成与北京、武汉数据网互联。
(2) 功能验证的主要内容。一是验证成都核心节点与其他各核心节点间电路域和分组域的业务互通性;二是验证成都节点与济南节点的漫游用户情况;三是验证核心网迂回路由可用性;四是验证成都核心网本地各基本业务使用情况。
(3) 功能验证中发现的问题。在互联完成后的功能验证过程中, 成都与武汉间进行MSISDN拨测时, 可正常振铃并接通呼叫, 但双方听不到对方讲话。在MSC上查看双方电路占用情况, 发现呼叫接通后, 成都和武汉MSC所占用的CIC (电路标识码) 不一致, 导致信令接通后双方话路没有占用同一个时隙, 重新制作数据后业务正常。
6.2 石太客运专线基站组网调整功能验证
(1) 石太客运专线太原局管内2个基站由石家庄BSC割接至太原BSC1, 属运营网络的无线网组网调整施工。
(2) 功能验证主要内容。一是被割接基站下的基本业务功能测试;二是跨局语音切换测试;三是跨局组呼业务测试。
(3) 功能验证中发现的问题。基站割接完成后, 在跨局界位置北京至太原方向的跨MSC语音切换失败, 出现掉话。分析信令跟踪结果, 因太原MSC开启了收号延时功能, 北京MSC在发送切换号码后太原MSC等待收号延时5 s, 导致北京MSC未收到ACM消息, 计时器超时引起切换失败。太原关闭MSC收号延时功能后业务恢复正常。
7 结束语
随着GSM-R系统维护逐步深入, 仅限于拨测的功能验证远远不够。目前应利用信令仪表进行功能验证, 并对功能验证拨测过程进行信令监测, 可抓取各项业务拨测的信令流程, 通过与标准通信协议对比, 发现网络中存在的隐患, 进一步提高功能验证质量。
在日常网络优化工作中, 调整网络参数后, 仅根据拨测无法直观反映优化效果, 必须结合话务统计功能和网络性能统计指标判断本次优化效果, 不但要观察优化项目的指标是否改善, 还要注意其他指标是否在优化后下降。应尽量完善GSM-R系统网络设备的性能统计分析功能, 并根据业务实际应用情况进行修订性能统计指标, 逐步完善功能验证方法。
参考文献
[1]铁道部.GSM-R无线网络覆盖和服务质量 (QoS) 测试方法 (V1.0) [S], 2008
[2]铁道部.铁路GSM-R数字移动通信工程施工质量验收暂行标准[S], 2007
工况软件模拟演示验证系统设计 篇4
在进行航天测量船海上测控工况设计时, 传统的工况设计软件计算结果不够形象直观, 且程序版本和计算精度也不完全统一, 不便于互相验证。为满足后续试验任务需求, 有必要研制一套试验任务模拟演示验证系统, 使用户能够对航天器的飞行状态和测量船执行任务的场景有直观全面的了解, 为决策指挥提供一定程度的可视化支持, 为型号总体人员提供验证海上测控方案正确与否的平台, 尤其可以对应急工况的设计提供及时准确的仿真验证手段。
试验任务模拟演示验证系统包括试验任务工况设计软件和模拟演示验证系统2个部分。其中试验任务工况设计软件用于进行海上测控任务的工况设计, 并以数据文件的形式输出设计结果。模拟演示验证系统采用基于卫生工具包软件 (Satellite Tool Kit, STK) 的可视化平台实现进行设计开发, 用于仿真验证工况设计结果并向用户提供试验任务过程的可视化支持。
1 系统设计
模拟演示验证系统利用STK软件的STK/X嵌入式软件开发技术实现。STK是美国分析图形有限公司 (Analytical Graphics Inc., AGI) 开发的航天领域中的商品化的卫星系统仿真分析软件[1,2]。STK/X是AGI公司使用4DX嵌入技术生成的STK整合模块。基于OpenGL技术的三维可视化技术, 可以逼真地再现空间视景环境、飞行器飞行姿态和关键动作等。
使用STK/X技术嵌入到程序中进行开发设计, 需要掌握大量的STK Command操作命令接口, 这为基于STX/X的程序开发带来很大的困难。鉴于此, 提出了开发STK/X操作驱动引擎的设计思路。STK/X操作驱动引擎的好处, 就是它隐藏了几乎所有复杂的STK Command操作命令, 使程序开发者能够更加专注于仿真演示验证系统软件本身的设计开发。利用STK/X操作驱动引擎方法, 把模拟演示验证软件分为4层, 如图1所示。
2 需要解决的问题
模拟演示验证系统软件的分层设计把不同的功能分在不同的层次进行设计开发, 每一层所涉及的开发技术都不相同。
2.1 STK/X嵌入控件层和驱动引擎层
嵌入控件层的技术特点是对象嵌入式程序开发, 需解决STK/X控件技术。
编写驱动引擎层需要掌握大量的STK Command操作命令, 还需要建立必须的STK三维模型供STK三维窗口控件使用。操作命令可以通过STK软件的Help文件查询和学习掌握, 该层需要解决的问题包括STK三维建模方法和STK三维模型的动作控制方法。
2.2 数据处理层和用户操作层
数据处理层实现工况设计用户数据和STK数据之间的转换。海上航天测控涉及的数据主要包括:任务总体参数、航天测量船工位参数、发射场工位参数、火箭弹道数据和卫星轨道姿态数据等。其中火箭和卫星的数据量大且较复杂, 因此需要解决的问题包括火箭位置速度姿态的转换和卫星轨道姿态的转换。
用户操作层的主要功能是向用户提供程序操作界面以获取用户输入的数据。根据STK所提供的对外接口的特点, 选择Microsoft Visual C#进行程序界面的设计开发。该层没有需要解决的问题。
3 关键技术
3.1 STK/X控件技术
STK/X主要使用AGI Map Control和AGI Globe Control 2个控件实现二维和三维界面的显示和刷新, 使用AgSTKXApplication完成在整个应用程序生命周期对STK对象的管理和调度[3]。应用STK/X控件技术, 用户可以根据需要开发独立的视景系统, 实现在不打开STK主程序的情况下使用STK的演示界面和计算函数库, 这使得开发模拟演示验证部分的软件成为可能。
3.2 STK三维建模技术
STK演示界面最基本的对象是STK三维模型。要实现对STK对象的操作, 首先就要建立STK模型。由于STK所使用的模型无法通过三维建模软件直接建模, 需要采用不同的方法间接获得STK模型。
STK模型文件采用.mdl格式, 是一种利用文本描述语言定义的模型格式, 易于学习和应用。但由于文本编写模型工作量大、效果不直观等原因, 很难使用文本工具直接编写出复杂的STK三维模型。因此, 需要采用其他三维模型软件建立三维模型, 再通过工具软件转换成为STK支持的.mdl模型格式。AGI公司官方发布的LwCoventer软件可以把使用LightWave软件[4,5]建立的三维模型 (.lwo格式) 直接转换成.mdl模型使用。如果用其他三维软件建立三维模型, 可以考虑先用Deep Exploration软件把三维模型转换为.lwo格式, 再用LwCoventer转换为STK的.mdl格式。
对于三维建模软件不方便建立的模型信息, 可以考虑先把模型转换成.mdl格式后再用文本工具单独编辑该部分。
3.3 STK三维模型控制技术
在STK控件提供的场景中使用三维模型可以实现三维对象飞行动作的仿真演示, 这就是STK的三维模型控制技术。
由于STK三维模型使用的是文本描述语言, 可以在语言中直接描述三维模型各部分之间的相对动作以及模型本身相对三维空间的平移、缩放和旋转等动作。实现该功能需要编写.**ma格式的动作操作文件 (火箭动作文件格式.lvma, 卫星动作文件格式.sama) 。该功能的实现过程为:用户输入三维对象的动作及时间节点 (如输入在120 s卫星太阳帆板开始展开) ;数据处理层把该输入转换为驱动引擎层需要的输入数据并通过函数接口传递给驱动引擎层;驱动引擎层编写.**ma动作文件, 并通过STK Command命令使STK加载该文件, 实现三维模型的动作过程。
3.4 火箭位置速度姿态的转换
在试验任务中弹道文件提供了火箭在发射坐标系中的位置 (x、y、z) 和速度 (Vx、Vy、Vz) , 需要把它转换到STK所需的地心固连系的位置速度, 并编写STK弹道 (STK数据文件, .e格式) 。火箭在发射坐标系的位置转换为地心固连系的位置可采用先旋转、再平移的方法。根据发射方位角把火箭在发射坐标系的坐标转换到测量坐标系, 再根据发射点的经纬度从测量坐标系转换到地心固连系;将坐标系原点从发射点平移至地心。发射点的经度、纬度、高程 (L、B、H) [6,7]转换为地心固连系公式如下:
式中, a为纬圈椭圆长半轴;
弹道文件还提供了发射坐标系的火箭姿态数据, 可以采用以下3种方法转换成STK姿态文件:
① 可以把火箭轨道参数中给出的火箭相对发射坐标系俯仰、偏航和滚转角转换到地固系。转换后的表示形式可以用四元素或者欧拉角表示;
② 可以把火箭轨道参数中给出的火箭的攻角和侧滑角转换为地固系中的火箭姿态, 这种方法计算简便, 但由于文件中没有给出火箭滚动的数据信息, 此方法计算的火箭姿态不能显示滚动情况;
③ 在发射工位建立发射坐标系, 可以利用直接编写.a格式的发射系火箭姿态文件。
利用STKCommand命令载入弹道和姿态文件, 可实现火箭在STK场景里的飞行仿真。
3.5 卫星轨道姿态的转换
目前任务中卫星的轨道一般以轨道六要素的形式给出。STK可以直接接受轨道六要素的输入, 仿真生成卫星轨道。因此, 可以直接在驱动引擎层编写输入卫星轨道的STK Command命令实现卫星轨道的仿真。
对于卫星姿态, 目前的总体文件中没有给出详细的数据供使用。因此, 需要通过仿真获取卫星的姿态数据, 生成卫星姿态数据文件, 再通过驱动引擎层加载姿态文件实现卫星姿态仿真演示。
卫星姿态文件的数据以姿态角的格式给出, 当取313转序[8]时的计算方法如下:
式中, θx为313转序下的3个欧拉角;ωx、ωy、ωz为卫星绕3轴转动的角速度。
卫星建立对日定向姿态的判断可以通过卫星太阳帆板的法向和卫星对太阳矢量的夹角来实现, 当2个矢量夹角为0° (方向重合) 时即实现对日定向。设太阳在惯性系中的矢量为
计算二者夹角余弦值Cz, sun为:
当Cz, sun=-1时, 表示卫星-Z轴对准太阳。
用以上方法仿真计算某卫星入轨后建立对日定向姿态的过程, 卫星体坐标系z轴与太阳的方向夹角余弦随时间的变化关系如图2所示。
4 结束语
试验任务模拟演示验证系统的实现, 使工况设计拥有了形象化手段和演示验证工具, 能够为决策指挥提供一定程度的可视化支持, 在海上航天测控任务中具有重要的应用价值。同时, 基于驱动引擎的分层设计思想为其他项目的开发也具有很好的借鉴意义。
摘要：为了给工况设计和指挥决策提供可视化平台和仿真验证手段, 设计模拟演示验证系统。根据STK/X整合模块的特点, 提出基于操作驱动引擎的软件分层设计, 把STK控件嵌入到应用程序中实现功能的集成。通过对软件各层设计分析, 梳理出系统实现所需要解决的问题。针对问题研究解决了STK/X应用技术、STK三维建模以及模型控制技术、火箭位置速度姿态的转换方法、卫星轨道姿态的转换方法等关键技术, 完成了系统设计开发工作。
关键词：模拟演示验证,STK/X,操作驱动引擎,嵌入式开发
参考文献
[1]黄洁.VC和STK集成的途径及其在仿真中的应用[J].计算机仿真, 2007 (24) :291-294.
[2]STK User's Manual Version 4.2.1.Analytical GraphicsINC (AGI) [S], 2000.
[3]Analytical Graphics Inc.STK/X Help.U.S.A., AnalyticalGraphics Inc.[S], 2004.
[4]黄剑.LightWave7.5高级实例教程[M].北京:中国电力出版社, 2003.
[5]刘光明.基于多种软件平台的卫星动力学仿真研究[J].系统仿真学报, 2007 (19) :308-311.
[6]孔祥元.大地测量学基础[M].武汉:武汉大学出版社, 2006.
[7]边少锋.大地坐标系与大地基准[M].北京:国防工业出版社, 2005.
某型飞机压力加油系统计算及验证 篇5
飞机压力加油的基本需求是提供安全、快速的再次飞行准备时间。飞机压力加油需要考量的因素包括:快速的加油时间及精确加进所需的油量, 同时确定燃油在飞机上的位置, 保证符合飞机的重心限制, 并防止燃油从机上溢出机外。
某型飞机压力加油接头安装在顺航向右侧机翼前缘, 左右机翼四组油箱对称分布, 本文以压力加油系统作为研究对象, 结合管路流速限制, 对压力加油管路进行计算, 并用流量模数法验证计算结果的正确性。
燃油系统设计要求
系统模型
某型飞机全机共四组燃油箱, 对称分布在飞机机翼两侧, 油箱的载油情况为:左I组4750kg, 左II组5750kg, 右I组4750kg, 右II组5750kg, 油箱局部布置见图1所示。
设计要求
飞机压力加油系统的加油时间不超过20min, 加油管径保证加油系统导管内的燃油流速不大于9m/s, 进入油箱的燃油流速不大于3m/s。压力加油接头处的最大加油压力为0.35MPa。
压力加油算法
计算模型
某型飞机压力加油系统的布置以D点为对称点, 两边对称。节点定义、管段符号及参数图见图2所示。定义管路BD、DE和DJ管径为60mm, 管路EH、JK管径为d1, 管路JL、EG管径为d2。
其中:λ—流体沿程阻力系数
ζ—流体局部阻力系数
∑ζ—流体总阻力系数
K—流量模数
Q—压力加油流量
∆P—压力差
t—时间
W—加油总容积。
计算方法推导
压力加油系统管径计算的原则是:各油箱组同时到达满油状态, 各油箱组加油时间的预估值相同。
假设油箱的加满油的时间为t:
式中
加油总容积, m3;
Q——加油管中的加油流量, m3/s。
每个油箱的容积加油量与加油时间内供给油箱的燃油容积成比例, 即:
由于压力加油系统左右机翼完全对称, 节点D、J、K、L间管路参数符号见图2所示。在节点J上, 管路JK和管路JL成并联连接, 其压差为:
由于某型飞机通气系统采用开式通气, 压力加油时各油箱与大气相通, 可认为系统内保持着相同的压力, 由此有:
推导可得
压力加油管径计算
在压力加油过程中, 每个油箱的加油总容积为确定值, 为了使加油过程中油箱内的燃油流场稳定, 减少燃油雾化、起泡、沸腾和油面扰动, 限制油箱入口的燃油流速不大于3m/s。
由于加油总容积和管路直径及燃油流速满足下列关系:
由此可得:
当流速v越大, 管径d越小;流速v越小, 管径d越大, 为减小系统重量, 燃油流速应尽量取大, 本文取v=2.5-3m/s, 压力加油总容积为26.923 m3, 可求得d2=0.054m。
分析管段JL和JK, 假设JK长度为2m, 管段JL长度为6m, 管段DJ长度为5m管段BD长度为5m。
对燃油系统进行工程计算时, 管路上所有的沿程摩擦阻力系数和局部阻力系数简化为不随流量变化, 且管路中各管段和附件的内径都相同, 如果有管段和燃油附件具有不同的内径, 则需转换到计算用的定性直径。
计算可得。
流量模数法校验
阻力系数计算
基本加油量计算模态中, 加油系统复合直路共有两个并联节点E和J, 且都为分流状态, 都是垂直分流模式, 分流角。
旁路分流阻力系数为:
直路分流阻力系数为:
计算可得各段管路阻力系数见表1。
串联和并联流量模数
流量模数法计算流体阻力公式:
流量模数可以由下式表示:
式中:*l—换算总长度,
lζ—将局部阻力系数总和换算成当量长度;
l0—沿程长度, m;
d—管段定性管径, m;
代入可得各段管路的流量及流量模数见表2。
加油时间计算
各油箱中加满油所用的时间见表3所示。
结束语
经验算, 燃油在BD段主管道中的燃油流速为8.96m/s, 小于9m/s, 油箱出口燃油流速分别为3.03m/s、2.8m/s, 最大值略大于3m/s, 加油时间为17.7min, 小于20 min, 从上述结果可知, 加油流量和燃油流动速度及加油时间均达到压力加油设计要求。
基于风险评估的制药用水系统验证 篇6
从原料的角度分类, 中国药典将制药用水分为饮用水 (Drinking Water) 、纯化水 (Purified Water) 和注射用水 (Water for Injection) ;欧洲药典和WHO GMP将其分为饮用水、纯化水、高纯水和注射用水;美国药典将其分为饮用水、纯化水、血液透析用水 (Water for Hemodialysis) 、注射用水和纯蒸汽 (Pure Steam) 。
从产品的角度分类, 制药用水分为抑菌注射用水 (Bacteriostatic Water for Injection) 、灭菌吸入用水 (Sterile Water for Inhalation) 、灭菌注射用水 (Sterile WaterforInjection) 、灭菌冲洗用水 (SterileWaterforIrrigation) 和灭菌纯化水 (Sterile Purified Water) 等。
2 制药用水系统的验证生命周期
ISPE良好实践指南的“制药用水和蒸汽系统调试与确认”曾尝试把项目管理、调试和确认、日常操作结合到验证生命周期这个概念内, 其基本包括: (1) 项目启动和概念设计; (2) 设计:初步设计和详细设计; (3) 采购和施工; (4) 调试和确认; (5) 日常操作; (6) 系统生命周期中的维护验证状态:日常监测、定期维护、周期性验证。
2.1 设计阶段
通常是在对制药用水系统的项目信息了解后进入设计阶段并形成文件。验证V模型描述了在确认过程中进行测试的3类文件:用户需求说明、功能设计说明、详细设计说明。根据项目执行的策略和大小, 这些文件可以合并在一起。然而, 测试需求仍然需要分成3个阶段, 在不同确认阶段的测试项目应重点考虑文件中描述的要求。
用户提出的其他技术要求同样需要进行测试。比如EHS管理体系或者其他不影响产品质量的项目, 都需要测试并形成文件记录以满足特定的要求。这些可能会是交付的调试测试计划和报告的一部分。GMP要求的测试项目必须包含在确认方案中。
2.2 用户需求说明
用户需求说明URS (User Requirement Specification) 在概念设计阶段形成, 并在整个项目生命周期内不断审核及更新。如果可能, URS应该在详细设计说明之前定稿。URS应避免在确认活动开始之后进行变更, 这样会浪费大量时间来修改确认方案及重复测试。在最终设计确认过程中应对URS进行详细审核以保证设计情况满足用户期望。URS的审核结果可以汇总到最终设计确认报告中。
URS应说明制药用水系统在生产和分配系统中的要求。一般来讲, URS应该说明整体要求、制药用水系统的性能要求。这些说明会定义出关键质量属性的标准, 包括制药用水的质量说明, 比如TOC、电导率、微生物及内毒素等。制药用水系统的设计要求有可能受供水质量、季节变化等因素的影响。供水的质量应该在FDS (功能设计说明) 、DDS (详细设计说明) 中注明。
URS应说明直接影响的制药用水系统的用途, 这些项目应该在PQ中测试和确认, 测试要求应该注明。
2.3 功能设计说明
FDS可以是一个或者多个文件, 描述直接影响的水和蒸汽系统如何来执行功能要求。一般来说, 进行采购和安装之后, FDS的功能应该在调试和OQ中测试和确认。
2.4 详细设计说明
DDS可以是一个或者多个文件, 用来描述如何建造直接影响的水和蒸汽系统。一般来说, 采购施工和安装完成后, DDS在IQ中测试及确认。
2.5 系统影响性评估
每一个系统都有它的功能作用, 根据图纸在物理上的可分割性对系统进行界限的划分。一般来说, 直接影响系统包括: (1) 纯化水制备系统; (2) 纯化水储存和分配管网系统。
间接影响系统为直接影响系统提供支持, 如饮用水系统 (饮用水的水质需要有长期的日常监测记录文件作支持) 。
2.6 部件关键性评估
组成系统的部件一般是在P&ID图上有唯一编号的, 部件也可能是操作单元或者小型设备。
关键部件是指部件的操作、接触、控制数据、报警或者失效对制药用水质量有直接影响的部件, 如纯化水制备系统中的RO/EDI最终工艺中与纯化水接触的部件。
非关键部件是指部件的操作、接触、控制数据、报警或者失效对水和蒸汽质量是间接或者无影响的部件。一般非关键部件包括: (1) 多介质过滤器排放管路的压力表; (2) 如果一个工艺步骤单元 (比如多介质、软化器) 是非关键工艺步骤, 那么所有组成部件被认为是非关键部件。如果某个工艺单元在其系统中的重要性越来越高, 那么这个工艺单元会包括更多的关键部件。
2.7 风险评估
风险评估用于确定所有潜在危险及其对患者安全、产品质量及数据完整性的影响, 应对药品生产全过程中的制药用水系统可能存在的潜在风险进行评估。
根据风险评估的结果, 决定验证活动的深度和广度, 将影响产品质量的关键风险因素作为制药用水系统验证活动的重点, 通过适当增加测试频率、延长测试周期或增加测试的挑战性等方式来证实系统的安全性、有效性、可靠性。
水系统数据的趋势分析可以作为风险评估的一部分。这些数据可以说明该直接影响的水系统处于验证的状态 (这些记录文件可以证明水质持续合格) 。不正常的或者不符合预期的水质趋势、实际数据的变化都说明该系统应该停止使用, 进行SOP审核和重新确认, 以纠正水质关键属性的超标趋势。
2.8 设计确认
在施工之前, 制药用水系统的设计文件 (URS、FDS、DDS等) 都要逐一进行检查以确保系统能够完全满足URS及GMP中的所有要求。设计确认应该持续整个设计阶段, 从概念设计到开始采购施工, 应该是一个动态的过程。设计确认的形式是多样的和不固定的, 会议记录、参数计算书、技术交流记录、邮件等都是设计确认的证明文件。但是, 目前的通用做法是在设计文件最终确定后总结一份设计确认报告, 其中包括对URS的审核报告。
2.9 采购和施工
采购和施工是在任何一个项目中都存在的管理活动。各公司应该有专门的部门进行管理以保证直接影响的水和蒸汽系统的项目采购和施工能够成功完成并有文件记录。
采购活动必须保证采购的材料符合设计文件说明。设备材料的接收应该对其质量及型号等进行检查, 并记录。一份良好的材料接收检查记录有利于调试和安装确认的执行。
施工方应该在施工过程中形成施工文件, 这些施工文件对于调试和确认都是很重要的。项目前的采购和施工文件计划会加速施工、调试和确认的进度。
2.1 0 调试
调试应该是一个有良好计划、文件记录和工程管理的, 用于设备系统启动和移交给最终用户的方法, 并且保证设备和系统的安全性能和功能性能均能够满足设计要求和用户期望。确认活动提供由质量部门审核通过的文件记录, 这些记录证明用户接收到的设备或者系统可以生产和分配符合一定质量标准的水和蒸汽系统。
制药用水系统的操作者应该特别关注调试和确认计划, 此计划可以提高调试和确认的效率, 并减少费用 (时间、人力、物力) 。调试和确认计划应该确保所有的确认活动全面而且不重复。质量部门应该参与调试和确认计划的建立。
2.1 1 安装确认
在安装确认中, 一般把制药用水的制备系统和储存分配系统分开进行。
2.1 1. 1 安装确认需要的文件
安装确认需要的文件主要有:
(1) 由质量部门批准的安装确认方案;
(2) 竣工文件包:工艺流程图、管道仪表图、部件清单及参数手册、电路图、材质证书、焊接资料、压力测试、清洗钝化记录等;
(3) 关键仪表的技术参数及校准记录;
(4) 安装确认中用到的仪表的校准报告;
(5) 系统操作维护手册;
(6) 系统调试记录, 如FAT和SAT记录。
2.1 1. 2 安装确认的测试项目
安装确认的测试项目主要有:
(1) 竣工版的工艺流程图、管道仪表图或其他图纸的确认;
(2) 部件的确认;
(3) 仪器仪表的校准;
(4) 部件和管路材质和表面光洁度;
(5) 焊接及其他管路连接方法的文件;
(6) 管路压力测试、清洗钝化的确认;
(7) 系统坡度和死角的确认;
(8) 公用工程的确认;
(9) 自控系统的确认。
2.1 2 运行确认
2.1 2.1 运行确认需要的文件
运行确认需要的文件主要有:
(1) 由质量部门批准的运行确认方案;
(2) 供应商提供的功能设计说明、系统操作维护手册;
(3) 系统操作维护标准规程;
(4) 系统安装确认记录及偏差报告。
2.1 2. 2 运行确认的测试项目
运行确认的测试项目主要有:
(1) 系统标准操作规程的确认;
(2) 检测仪器的校准;
(3) 储罐呼吸器确认;
(4) 自控系统的确认;
(5) 制备系统单元操作的确认;
(6) 制备系统的正常运行;
(7) 储存分配系统的确认。
2.1 3 性能确认
制药用水系统的性能确认一般采用3阶段法, 在性能确认过程中制备和储存分配系统不能出现故障和性能偏差。
第1阶段:连续取样2～4周, 按照药典检测项目进行全检。目的是证明系统能够持续产生和分配符合要求的纯化水或者注射用水, 同时为系统的操作、消毒、维护SOP的更新和批准提供支持。
第2阶段:连续取样2～4周, 目的是证明系统在按照相应的SOP操作后能够持续生产和分配符合要求的纯化水或者注射用水。对于熟知的系统设计, 可适当减少取样次数和检测项目。
第3阶段:根据已批准的SOP对纯化水或者注射用水系统进行日常监控。测试从第1阶段开始持续1年, 从而证明系统长期的可靠性能, 以评估季节变化对水质的影响。
3 制药用水系统的日常监测、定期维护及周期性验证
3.1 日常监测
在性能确认完成后, 应对系统进行综合评价, 并根据第3阶段的结果建立一个日常监测方案。在日常取样监测中, 使用点的取样频率 (通常为一些最小频率) 比在性能确认中已确定的采样频率小。对于注射用水系统, 必须保证每月所有的使用点都被检测到, 关键的取样点根据工艺需要进行日常监测。对于较大的分配系统, 可以轮流采样保证每个采样点每月可以采集1次。对于纯化水及纯蒸汽系统, 其系统影响性风险较低, 比注射用水的日常监测频次可适当降低。所有这些与日常监测的取样计划需记录在SOP中。
应当至少每年进行1次水系统质量回顾。系统年度审核帮助用户了解系统随时间的变化趋势, 还可以基于数据分析调整系统设定的报警限和行动限, 甚至调整相关SOP。系统质量回顾不能仅限于水质取样的结果, 应该是系统的综合回顾。
3.2 定期维护
应根据系统维护程序对制药用水系统进行维护, 主要包括:系统的维护频率、不同部件的维护的方法、维护的记录、合格备件的控制等。对系统进行定期维护后, 可不必进行再验证, 如有必要只需进行连续的水质检测。
3.3 周期性验证
要确保制药用水系统在整个使用周期内良好运行, 需要在一定时间的运行后定期进行再验证。这应包括系统的使用定期性能评估结果、系统变更的性质和程度、系统未来预期使用的变更, 以及公司合适的质量系统。
4 结语
本文介绍了典型的制药用水系统的基础知识和验证流程, 并举例进行了说明, 符合目前法规和指南的常规要求。对制药用水系统验证而言, 还需要考虑工艺对制药用水和纯蒸汽的具体要求、系统的关键性和复杂性以及用户的质量管理体系。
参考文献
[1]国家药典委员会编.中华人民共和国药典 (2010年版) [M].北京:中国医药科技出版社, 2010
[2]国家食品药品监督管理局.药品生产质量管理规范 (2010年修订) [S].北京:中国医药科技出版社, 2010
[3]United States Pharmacopoeia[S], 2010
[4]European Pharmacopoeia7th[S], 2011
[5]Guidelines to Good Manufacturing Practice Medi-cinal Products for Human and Veterinary Use[S], 2008
[6]FDA.Code of Federal Regulations (CFR) -Title21, Parts600[S], 2012
[7]WHO.Expert Committee on Specifications for Phar-maceutical Preparations, Annex3WHO Good Manu-facturing Practices:Water for Pharmaceutical Use[S], 2005
[8]FDA.Guide to Inspections of High Purity Water Systems[S], 1993
[9]ISPE.GPG-Commissioning and Qualification of Phar-maceutical Water and Steam Systems[S], 2007
计算机化系统验证基本要求的探讨 篇7
随着GMP(2010修订版)有关计算机化系统附录的生效日期的临近,计算机化系统验证的话题已经被人们经常提及,但大多对自己企业各类相关的计算机化系统应该如何验证感到困惑,应该遵从怎样的规范来实施验证,本文希望就上述话题与同行一起学习和探讨,分享我们多年来在工作实践中的成果。
1基本概念
GMP计算机化系统附录第4章就验证做出如下阐述:应使用科学的风险评估方法来决定计算机化系统的验证范围与程度,应当将验证看作计算机化系统生命周期的一个组成部分,这个生命周期包括计划、设定标准、编程、测试、试运行、文档管理、运行、监控、修改更新等阶段,要充分考虑计算机化系统的使用范围,确定其属于前验证还是回顾性验证,系统是否引入新的组件。
首先我们有必要将上述专业名词用ISPE GAMP 5《良好自动化生产实践指南》来做一下定义,以便明确其内涵。
1.1 风险评估方法
计算机化系统质量风险管理流程(图1),采用了ICH Q9的一般原则来说明风险管理的“5个步骤”,该流程是实现与维护系统不可或缺的部分,对于简单的低风险的系统可以进行组合。
1.2 计算机化系统
计算机化系统框图如图2所示,其是由硬件、软件、网络组件以及可控的功能和相关文件组成。它可以包括:生产资源计划系统、实验室信息管理系统、自动化生产设备系统、生产执行系统、仓储与配送系统、文件管理系统。
1.3 计算机化系统的生命周期
计算机化系统的生命周期由以下4个主要阶段组成:概念提出、项目实施、系统运行、系统退役。
概念提出阶段通常由监管公司根据自己的业务需求和收益来考虑阶段需要实现的业务流程,并考虑可能的解决方法。
项目实施是充分考虑了自己的业务需求和收益后,根据项目的活动中的计划,评估和选择供应商,规范各层级的需求,并进行配置、验证,直到项目的验收和系统投入使用。
系统运行是4个阶段中最长的阶段,是由确定的及时更新的具有可操作性的规程来对其进行管理,期望保持系统可控、符合预定用途及合规等都是非常关键的方面,重点是对系统的影响、范围和复杂性的变更进行管理。
当系统即将退出公司的业务不再使用时,就自然进入了退役阶段,该阶段决定对数据进行保留、迁移还是销毁。
2 验证实施
验证通常使用国际制药工程协会(ISPE)的《良好自动化生产实践指南》(GAMP5)的V字模型(图3),该模型是使系统在整个生命周期实现合规与符合预定用途的通用方法。该模型的验证过程包括用户需求规范、功能需求规范、设计规范、系统开发、安装确认、运行确认和性能确认。测试阶段的验证活动用来确认规范阶段的需求得到满足。
2.1 验证主计划(VMP)
在项目实施前首先需要定义验证计划,它可以作为既定的时间段内或工作流的总体计划,它应该是验证项目的概述文件,必须清晰精确地表述和涵盖设施、系统、流程的概述。验证过程是建立文件证据,为特定的计算机化流程可以持续地满足预先定义的质量要求规范提供高度保证。其主要目标是通过文件、记录系统可持续满足需求。此验证主计划的目的是定义该系统的验证活动,内容包含定义、验证范围、验证角色和职责以及主要验证产生文档的描述。
2.1.1 系统描述
系统是进行药品生产质量控制的技术平台,它是由多个子系统集成,主要涵盖生产管理、质量管理等模块。
2.1.2 功能范围
验证项目实施的范围有生产流程、质量管理流程,功能模块有生产管理模块、质量管理模块等。
2.1.3 系统的技术架构
系统主要由生产管理模块、质量管理模块以及其他业务模块组成,涵盖开发环境、验证环境、运行环境以及备份服务器的架构及配置文件的描述等。
2.1.4 验证方法
验证将使用国际制药工程协会(ISPE)的《良好自动化生产实践指南》(GAMP5)的V字模型,该模型是使系统在整个生命周期实现合规与符合预定用途的通用方法。该模型的验证过程包括用户需求规范、功能需求规范、设计规范、系统开发、安装确认、运行确认和性能确认等。
2.1.5 风险评估
作为验证方法的组成部分,企业将采取基于风险的方法,对系统功能的风险水平进行评估。风险评估将对系统验证范围内的流程或功能相关的法规和业务风险进行合理地评估并进行书面记录。编制风险评估报告递交决策层审批。
2.1.6 验证交付
验证交付的内容:验证主计划、设计需求规范、功能需求规范、用户需求规范、确认阶段(IQ、OQ、PQ)、标准操作程序、用户培训、偏差管理、验证总结报告。
2.1.7 项目的角色与职责
验证主管和信息系统质量保证主管需要对协议授权,对验证结果和验证总结报告进行审批。项目中需要对团队的角色做出定义,如执行决策者(ES)、项目经理(PM)、开发团队主管(DTL)、开发团队成员(DTM)、业务部门主管/团队成员(BTL/BTM)、验证主管(VTL)、验证团队成员(VTM)、信息系统质量保证主管(ISQA)等,并按照上述角色,确定审批矩阵。
2.2 风险评估
该系统为企业的生产、质量控制的业务流程提供有效的运作支持,企业将采取基于风险的方法,对业务环境面临的风险进行整体的风险评估。
2.2.1 目的
风险评估的目的是对系统功能的重要性和复杂性进行评价。风险评估对企业系统的相关功能的业务、技术和法规风险提供合理的评估结果,并进行文件记录。
对系统的功能性风险评估将考虑系统对企业质量管理体系、产品的质量、安全和效用以及数据完整性方面的潜在影响。此外,系统功能所支持的业务的重要性以及系统解决方案的技术复杂程度也是风险评估考虑的因素。
2.2.2 范围
文档的范围限于验证主计划中所列的业务流程涉及的各模块。
2.2.3 角色与职责
定义验证团队业务部门主管、信息技术主管、项目经理的职责。
2.2.4 风险评估
2.2.4.1 系统风险评估
(1)GMP评估:用来判断该系统是否应作为企业质量体系的一部分而被定义为一个GMP相关的系统。被判定与GMP相关就要求通过验证以满足GMP的要求。
(2)重要性评估:根据提出的问题所作的回答来判定其重要程度。
(3)复杂性评估:根据提出的问题所作的回答来判定其复杂程度。
(4)评估总结:对重要性和复杂性评估的结果作出判断。
2.2.4.2 功能风险评估
如果模块是与GMP相关的,则需要对每个功能进行进一步的评估。表1为功能风险评估表,功能风险评估方法参照ISPE GAMP5中的方法,由业务风险、技术风险、GMP风险3个维度组成。每个维度都有4个等级来表示风险的等级:高(3)、中(2)、低(1)、无(0)。每个功能最终的风险等级将由3个维度中风险等级最高的维度的风险等级决定。风险评估的结果将被用来定义验证范围和测试等级。验证范围将包括所有与GMP相关的功能。
评估结果为高、中风险,需要做正式归档测试,正式归档测试时,所有的测试实例会被预先审批,然后执行、审核以及批准。
评估结果为低、无风险,需要做非正式归档测试,在非正式归档测试时,测试实例无需预先审批,只会在执行后被审批,但是测试总结报告会被审核以及批复。
2.3用户需求规范
2.3.1目的
文档的目的是为了定义企业实施并使用系统的业务/用户需求。
2.3.2范围
文档的内容包括生产管理、质量管理业务流程的用户需求。
2.3.3用户需求定义
表2为用户需求定义,其包括子流程编号、用户需求编号以及用户需求描述。
2.4功能需求规范
2.4.1目的
文档的目的是为了定义企业实施并使用系统的功能需求。
2.4.2范围
文档的内容包括企业生产、质量管理业务流程的功能需求。
2.4.3 子流程功能需求定义
表3为子流程功能需求定义,其文档应该具备功能需求编号及详细描述。
2.5 设计需求规范
2.5.1 目的
文档的目的是描述系统模块的设计规范,简述模块中重要功能的输入、输出项及实现逻辑。
2.5.2 范围
文档的内容包括模块业务流程中识别的被评估为高风险的系统功能的设计需求。本文档记录的系统功能已对业务风险、技术风险、GMP风险进行了功能性风险评估,3个维度均被评估为高风险系统功能编写设计需求。
2.5.3 功能描述
表4为功能描述,其包括:(1)设计需求编号;(2)所实现的功能;(3) 功能的输入项目;(4) 功能的输出项目;(5) 逻辑流程描述;(6)其他功能的接口和限制条件;(7)功能所需达到的性能要求;(8)测试要点。
2.6 安装确认
安装确认是指检查、测试或其他核实,从而证明软件和硬件的安装、配置是正确的。
2.6.1 安装确认协议
2.6.1.1 目的
编写本安装确认协议的目的是为了描述系统进行安装确认将要执行的各项任务。
2.6.1.2 方法
针对系统应用的阶段,可以将验证分为前验证或回顾性验证,验证系统生产运行环境或验证环境范围内的硬件和软件是否符合IT基础设施和软件规范定义的标准。
2.6.1.3 范围
该安装确认协议适用范围为系统的验证环境和生产环境的基础设施和软件。
该安装确认协议的测试实例,在被执行之前,需要经过审批,审批通过之后将被用来检验验证。
该安装确认协议需要在进行安装确认测试活动开始之前被审批。完成安装确认测试之后,安装确认报告将会被撰写,其中将会包括安装的满意度和发现的问题。
2.6.1.4 风险评估
本风险估会在执行此协议时被执行。对于软硬件的风险评估,将基于该软硬件是否对运行确认测试和性能确认测试产生影响和该软硬件是否将应用于生产环境。如果符合以上2种情况中的任何一种,将判定该软硬件的风险等级为高。
2.6.1.5 角色与职责
定义项目参与人员及需要的角色,如质量职责、信息系统职责、测试职责、验证团队等。
2.6.1.6 测试实例内容
IT基础设施验证包括:(1)物理环境;(2)系统崩溃;(3)访问安全;(4)数据完整。
2.6.1.7 系统管理流程验证
系统管理流程验证包括:(1)服务器运行(时钟验证);(2)系统状态检查;(3)定期维护;(4)系统清理;(5)系统诊断,性能评估;(6)系统电力供应和后备电源。
2.6.1.8 物理安全流程验证
物理安全流程验证包括:(1)紧急情况条例;(2)访问者/承包商条例;(3)机房访问。
2.6.1.9 逻辑安全流程验证
逻辑安全流程验证包括:(1)系统访问控制;(2)密码变更方式和频率;(3)病毒防护/探查方法和频率;(4)自动注销功能;(5)访问复原要求流程。
2.6.1.10 培训
所有参加安装确认的人员,都应该参加足够的培训,以完成所分配的任务并明确培训的内容。
2.6.1.11 流程
在执行安装确认测试实例之前,以下工作必须完成:(1)安装确认协议需要被批准;(2)软硬件的风险评估需被确认;(3)每一个测试实例需要被批准。
2.6.1.12 测试执行
在正式测试前,需要对以下问题作出说明:系统访问、阅读测试实例、测试命令或数据输入、系统截屏、测试结果、测试者姓名以及测试日期、测试员错误、非预期结果。
2.6.1.13 测试偏差
如果某种测试结果不能满足之前提供的期望结果,测试员由于某种原因不能完成整个测试,或者验证团队主管决定某个测试结果不满足预期结果则验证团队主管需要记录该测试偏差,测试员需要填写测试偏差记录。内容应包括:测试偏差描述、偏差文档、测试偏差分类、测试偏差调查、重新测试说明、重新测试、测试审核和结束、测试事件汇报和跟踪。
2.6.1.14 测试结果审查
在每一个测试实例完成时,测试实例及其支持文档应被测试员和验证团队主管独立审查,以确保测试结果的完成,包括对于测试偏差报告的审核、安装确认测试实例的审核等。
2.6.1.15 安装确认报告
安装确认报告将在测试完成后被编制和审批,该报告包含:(1)安装确认测试的概要;(2)各安装确认测试实例的结果;(3)产生的偏差事件以及结果;(4)与原测试计划的偏离;(5)结果可接受性的结论。
2.6.2 安装确认测试脚本
安装确认测试脚本(表5)具体内容如下:
(1)需要明确测试的环境及服务器名称、环境名称等详细描述。
(2)测试记录应包括:规范描述、测试结果复核、步骤、操作/步骤描述、测试活动、预期结果、测试结果、测试结论、通过/不通过。
(3)总体测试结果:对测试结果作出判断通过、不通过、在条件下通过的结论。
(4)审批矩阵。
(5)测试支持文档:将测试过程中的主要结果以截图方式提供。
2.6.3安装确认报告
文档的目的是对安装确认测试活动以及结果作出综合性的评价。安装确认测试已经执行,安装确认的目的是确认系统的软硬件已经按照需求安装,并能支撑系统的运作。
2.6.3.1详细描述
记录安装测试脚本的实例汇总(表6),所有的测试脚本已经完成,并对所列项目以表格形式汇总测试结果,应包括:安装确认编号、测试实例名、生产环境(通过/不通过)、验证环境(通过/不通过)。
2.6.3.2偏差记录
测试员在IQ测试中发现的偏差已被记录,验证团队已经对偏差进行了评估,并针对评估的结果制定了偏差处理的解决方案。根据解决方案,验证团队已经对系统进行了相应的变更并进行了重新测试。
2.6.3.3偏差最终状态
安装协议中规定测试中出现的偏差需要重新测试,并在处理结果(表7)中显示偏差描述、处理结果、偏差最终状态,然后确认是否同意关闭。
2.6.3.4结论
安装确认已经按照安装确认协议完整执行。安装确认测试脚本已经完成编制,并经过审批和签署。所有的偏差已经被记录、报告、分析和处理,所有的偏差都已被关闭,可以进行运行确认测试。
2.7 运行确认
运行确认是指按照规范来进行的2.6.3安装确认报告系统测试或其他核实活动,用来证明功能的正确运行能够支持所有规定运行范围内的具体业务流程。
2.7.1 运行确认协议
2.7.1.1 目的
运行确认协议的目的是记录系统的运行与用户要求及功能描述相一致的验证过程。在批准和执行本运行确认协议并执行相关测试后,编制运行确认报告,管理层对运行确认报告的审批表示系统的功能运行已处于验证状态,可以进行下一步的性能确认。
2.7.1.2 范围
运行确认测试的功能范围为规范阶段定义的系统功能需求,包括生产管理模块、质量管理模块等。
2.7.1.3 运行确认方法
文件定义了运行确认的目标、范围、职责、方法、执行流程及验收标准。对于GMP风险归类被定义为“高”风险的功能需求,在运行确认测试中将进行重点测试。
(1)功能测试:运行确认单元功能测试是用来证明系统功能的运作符合项目的设计的,单元功能测试可以确认系统的运作功能是否能满足企业在功能需求文档中的要求。
(2)测试环境:运行确认单元测试会在信息系统的验证环境中执行,该环境需要包括所有系统功能以及运行确认范围下定制的对象。任何与单元测试、偏差/错误修复不相关的系统配置更新会被归档,且按照项目变更控制流程来评估。
(3)运行确认测试的建立和审批:每个编制完成的测试脚本会在执行之前被业务部门团队主管及验证团队主管审批。对于已经审批的文档如有任何更改,需要遵循文件控制流程。
(4)执行运行确认测试:经审批的运行确认测试脚本将被测试员执行测试,将执行运行确认单元测试脚本的结果以及相关的截屏打印出来,并在打印出的文件上签署名字和日期。
(5)验证:验证主管需在执行测试脚本前审查和批准运行确认协议以及每个运行确认测试脚本,验证团队应确保测试环境已被正确安全地建立,确保验证人员得到培训并熟悉协议中所确定的流程。验证主管需要评估运行确认的整体结果,来决定其是否满足验收标准。
(6)测试脚本的执行和审批:测试员需要遵循测试脚本中的测试步骤,记录测试的实际结果,按需要提供系统截屏。测试员需要评估测试的实际结果,并确定它们是否满足预期结果。如果满足了预期结果,测试员需要标注该步骤为“通过”,如果没有满足预期结果,测试员需要标注该步骤为“未通过”,并且记录为一个偏差。测试脚本应当在执行前由验证主管审批。
(7)测试脚本执行后的审查:职能团队主管需审查测试员的测试结果,也需要确认提供的相关文档与脚本执行的结论(通过/未通过)相符,并提交验证主管审查批准。
2.7.1.4 偏差管理
(1)偏差记录。当测试结果与预期结果或者功能规范不符时,测试员需要记录为一个偏差,并记录相关的测试步骤编号。
(2)偏差分类。偏差可以分为严重、高、中、低4类。
(3)测试偏差调查:系统管理员、测试员和验证团队主管会评估每一个测试事件及其成因。
(4)重新测试。如果测试事件报告的结论是需要重新测试,验证团队主管将发布运行确认重新测试副本,需包含相关的测试实例,标记并签名相关测试会被重新执行。测试完成后,测试人员将所有的文档递交给验证团队主管。
(5)最终协议审批及验收标准。在测试执行结束后且执行性能确认测试前,必须满足下列验收标准:此协议下的所有测试脚本都被执行,且相关的系统截屏或者其他支持文档都已提交。所有测试步骤被标注为“通过”,当标注为“未通过”时,相应的偏差被修复或已拥有合适的替代方案。偏差只有不影响用户使用系统时,在结束运行确认后,才可以允许维持“未关闭”状态。严重偏差和高偏差必须修复,或者至少有过渡时期的解决方案。中低偏差需要先确认分类是否准确,并提出相应的解决方案。
2.7.2 运行确认测试脚本
2.7.2.1 目的
文档的目的在于确认系统满足了功能需求,并且系统能够用来执行性能确认测试。
2.7.2.2 测试范围
文档包括生产管理、质量管理流程的功能需求。
2.7.2.3 测试接受标准
测试结果与预期结果一致为通过,否则不通过。
2.7.2.4 测试环境描述
说明服务器名称、测试环境、软件版本等。
2.7.2.5 测试脚本
测试脚本中申明功能需求的编号、测试结果的复核,以及测试的步骤、操作描述、测试数据、预期结果、测试结果和测试结论。
2.7.2.6 偏差记录
测试结果的审批。
2.7.3运行确认报告
文档目的是对运行确认测试活动以及结果给出综合性的评价。运行确认测试已经完成,运行确认的目的是确认系统的功能需求已得到满足,系统可以继续执行性能确认的测试。
2.7.3.1测试详述
测试实例汇总,所有测试已经执行完毕。
2.7.3.2偏差记录(略)
2.7.3.3结论
运行确认是已经按照运行确认协议被完整地执行。运行确认测试脚本已经完成编制,经过审批和签署。所有的偏差已经被记录、报告、分析和处理,所有的偏差都已被关闭,可以进行性能确认测试。
2.8 性能确认
通过测试和其他活动来证明系统符合预定用途,并允许按照所规定要求进行系统验收。
2.8.1 性能确认协议
2.8.1.1 目的
性能确认是指通过文件记录证明企业实施系统在业务流程和运行环境范围内,能够按照书面的预先已批准的用户需求规范正确运行所要求的业务流程活动。性能确认将使用集成的测试业务场景。性能确认使用的是真实的业务数据,针对用户角色安全功能的安全测试将被包含在性能确认中。
2.8.1.2 系统描述
系统包含生产管理模块和质量管理模块集成。
2.8.1.3 验证范围
验证范围仅限于在验证主计划(VMP-CN)中确定的企业实施的系统。性能确认测试的功能范围为规范阶段定义的用户需求规范。在规范阶段定义的用户需求涉及生产业务流程、QA业务流程以及生产管理模块、质量管理模块等系统模块。
2.8.1.4 性能确认方法(略)
2.8.1.5 测试数据需求
性能确认使用的是真实的业务数据,来确保每个单元模块联合起来操作后也能正常稳定地运作。
2.8.1.6 职责
定义性能确认的每个任务的执行和审核职责。
2.8.1.7 验收标准
当下列条件满足时,性能确认被认为满足验收标准:(1)用户需求已得到满足,系统能持续运作;(2)每个测试脚本的验收标准已得到满足;(3)所有性能确认的测试已经完成并圆满通过;(4)异常情况被归档且解决;(5)性能确认报告圆满完成,通过审核并得到审批。
2.8.1.8 测试的执行
(1)测试脚本审批:每个测试脚本在执行前需要得到职能团队主管和验证主管的批准。
(2)脚本执行:测试员需要遵循测试脚本中的测试步骤,记录测试的实际结果,按需要提供系统截屏。测试员需要评估测试的实际结果,并决定它们是否满足预期结果。如果满足了预期结果,测试员需要标注该步骤为“通过”,如果没有满足预期结果,测试员需要标注该步骤为“未通过”,并且记录为一个偏差。
(3)执行后审查:职能团队主管需要对测试员提供的文档以及测试结果进行审查。
2.8.1.9 偏差管理(略)
2.8.1.10 偏差记录
当测试结果与预期结果或者功能规范不符时,测试员需要记录为一个偏差,并记录相关的测试步骤编号。
2.8.1.11 偏差分类(同运行确认测试协议)
2.8.2 性能确认测试脚本
2.8.2.1 目的
文档的目的在于确认系统的生产管理、质量管理满足了性能需求。
2.8.2.2 测试范围
测试性能确认包括生产流程、质量管理流程系统性能需求。
2.8.2.3 测试条件的建立(略)
2.8.2.4 测试接受标准(略)
2.8.2.5 测试详述
测试环境说明服务器名称、测试环境、软件版本等。
2.8.2.6 测试脚本
测试脚本中应申明功能需求的编号、测试结果的复核以及测试的步骤、操作描述、测试数据、预期结果、测试结果和测试结论。
2.8.2.7 偏差记录(略)
2.8.2.8 测试结果审批(略)
2.8.3 性能确认报告
文档的目的是对性能确认测试活动以及结果作出综合性的评价,性能确认目的是确认系统的用户需求已经得到满足。
2.8.3.1 测试详述
列出性能测试脚本的实例汇总,列出所有的测试脚本并已经执行完毕。
2.8.3.2 偏差记录(略)
2.8.3.3 结论
性能确认已经按照性能确认协议被完整地执行。性能确认测试脚本已经完成编制,经过审批和签署。所有的偏差已经被记录、报告、分析和处理,所有的偏差都已被关闭。
2.9 验证总结报告
2.9.1项目概述(略)
2.9.2验证文件清单
验证主计划(VMP)、安装确认协议(IQP)、安装确认报告(IQR)、运行确认协议(OQP)、运行确认报告(OQR)、性能确认协议(PQP)、性能确认报告(PQR)。
2.9.3 人员与职责(略)
2.9.4 验证总结
验证方法依据国际制药工程协会(ISPE)的《良好自动化生产实践指南》(GAMP5)中类别软件产品(可配置软件产品)适用的V字模型。验证过程中编制的所有文档均经过审批。
2.9.5 验证主计划描述
验证主计划描述包括:(1)业务流程描述;(2)用户需求规范描述;(3)功能需求规范描述;(4)设计需求规范描述;(5)安装确认;(6)运行确认;(7)性能确认;(8)用户培训验证结果判定和结论。
3 结语
GMP附录就验证的定义可以看出,验证是计算机化系统生命周期的一个组成部分,是持续地贯穿于整个生命周期的活动,在每一阶段都需要产生验证活动,尤其进入运行阶段,从系统的变更管理活动而言,应更加注重基于风险评估的验证活动,只有如此,才能使系统永久处于可验证的良好运行状态。
摘要：以GMP(2010修订版)有关计算机化系统附录为切入点,阐述了风险评估方法、计算机化系统、计算机化系统的生命周期3个基本概念,并探讨了计算机化系统验证实施中验证主计划、风险评估、用户需求规范、设计需求规范、安装确认、运行确认、性能确认、验证总结报告等方面的基本要求。