IEC62304+软件国际标准中文翻译版.docx

1、IEC62304+软件国际标准中文翻译版微软中国IEC 62304 医疗器械软件 软件生存周期中文翻译版旭东2011-11-7 Monday国际标准IEC63240第一版2006年5月医疗设备软件软件生命周期程序刊物编号从1997年1月起，所有刊物都以60000系列命名发布。例如，IEC34-1现在是指IEC60034-1。统一版本现在，IEC的刊物以同一版本出版。例如，版本数字, , 分别指的是基础版，基础版与第一次修改版的合并，基础版与第一次、第二次修改版的合并。关于IEC刊物的更多信息IEC刊物的技术内容是被控制在IEC不断地检查之下的，从而保证其中内容反映了当今科技。与此出版物相关的信

2、息，包括它的有效期、新版本、修改处以及勘误处是可以出现在刊物目录中的（见下文）。有关正在思考和正在研究中的主题信息（该工作是由技术委员会承担的，他们准备了刊物）以及发布刊物的列表，也可以从如下渠道查询：IEC网站：刊物的目录：IEC网站的在线搜索功能（）使得您可以通过各种各样的标准来搜索，包括文本搜索、技术委员会搜索以及出版日期搜索。在线信息包括最近出版刊物，撤回信息，被替换的刊物以及勘误之处。IEC新出版刊物最新出版物的摘要（ news/justpub）可以通过电子邮件来查询。欲获得更多信息，请与客户服务中心（见下文）联系。客户服务中心如果您有任何有关此刊物的疑问或者需要更多帮助，请与客户服

3、务中心联系。电子邮件国际标准IEC63240第一版2006年5月医疗设备软件软件生命周期程序版权-版权所有未经出版商书面许可，本出版物的任何部分不可以以任何形式和方式被复制或使用，包括以电子或者机械的方式影印或者微缩拍摄。国际电工技术委员会邮政信箱：瑞士日内瓦电话：+41 22 919 02 11电传：+41 22 919 03 00电子邮件网站： 前言国际电工技术委员会是个为标准化而设立的世界性组织，包括所有国家的电工技术委员会。国际电工技术委员会的目标是在电气科学以及电子技术标准化的所有问题方面促进国际合作。为了这个目的以及其他活动，国际电工技术委员会出版国际标准，技术规格，技术报告，公开

4、提供规范和指导（从此以后被称为IEC出版物）。1.范围目的本标准为医疗设备软件生命周期下了定义。在本标准中描述的程序、活动、任务为医疗设备软件生命周期程序设定了一个普通的框架。应用领域本标准可应用于医疗设备软件开发与维护。当软件本身是个医疗设备时，或者当软件植入设备或成为最终设备的一个完整部分时，本标准可应用于医疗设备软件开发与维护。本标准不包括医疗设备的批准和最终版本发布，即使该医疗设备包括了整个软件。与其他标准的关系当研发一种医疗设备时，该医疗设备软件生命周期标准应当与其他适当的标准一起应用。附录C说明了本标准与其他相关标准之间的关系。标准的遵守本标准的遵守被定义为与软件安全等级一致，本标

5、准所确定的所有程序、活动以及任务的实施。注：软件安全等级所指的要求是由按要求的标准文件所确定的。标准的遵守是由本标准所需要的所有文件的检查来决定的，标准的内容包括风险管理文件，软件安全等级所需要的程序、活动以及任务的评估。注1：该审计可以由内部审计或者外部审计来实施；注2：尽管特定的程序、活动以及任务需要被实施，在实施这些程序、活动以及任务时，方法上是可以有弹性的。注3：当遇到任何列入有“酌情考虑“并且未被实施的要求时，该评估需要提交必要的解释性文件。注4：术语“一致性”曾用于ISO/IEC12207， 在这个文件中的术语“标准的遵守”被应用于此标准。2参考标准下面所参考的文件对于本文件的应用

6、来说是必不可少的。对于过时的参考文献来说，只有被引用的版本可以应用。对于更新的参考文献来说，所参考文献的最新版本（包括修改之处）可以应用。3术语与定义对于本文件的目的来说，下文的术语与定义可以被应用。 活动一组或多组相互联系相互作用的任务。 异常任何背离预期所基于的要求规格的状况、设计文件、标准等等，或者背离一些人的观念和经验的状况。异常状况可能出现于检查、测试、分析、编辑、使用软件产品、或者可实施文件的程序中，但不仅仅局限于这些程序中。 架构一个系统或组件的组织结构。变更请求对软件产品所做的备有证明文件的规格更改。配置条目在一个给定的参考点能够唯一分辨的实体。注：基于ISO/IEC 1220

7、7:1995，定义。可交付成果活动或者任务所需要的结果或产出（包括文件）。 评估一种范围的系统决定。在这个范围中，某种实体遇上它的具体标准。注：基于ISO/IEC 12207:1995，定义。 损害物理伤害、毁灭或者对人身体健康带来的这两种危害，或对财产环境带来的危害。注：ISO/IEC 指南51：1999，定义。 危险危害的潜在源头。注：ISO/IEC 指南51：1999，定义。 生产商对医疗设备设计、生产、包装、贴标签有责任和义务的自然人或法人；组装系统；在一种医疗设备上市或者投入使用之前改装该设备，不管该操作是由这个人实施的或者由代表此人的第三方实施的。注：ISO14971:2000，定

8、义。 医疗设备为人类一个或者多个具体目的，由制造商独立使用或者结合使用的任何工具、装置、器具、机器、器械、植入物、试管中的试剂或者校准器、软件、材料或者其他相似或相关的物品：疾病的诊断、阻止、监控、治疗或者缓；伤口的诊断、监控、治疗、缓和或者启动补偿机能；调查、更换、修正或者支持物理程序的剖析；支持或者延续生命；概念的控制医疗设施的消毒通过从人体获得的样本做试管实验，为医疗用途提供信息这些物品并没有通过药物学、免疫学或者新陈代谢的方法在人体上获得起初的意向功能，但是通过这些方法可以促进其功能的实现。注1：这个定义是由全球协调工作组织定下的。详情请看参考文献【15】（在ISO13485:2003

9、）【ISO 13485:2003， 定义】注2：当此定义应用于不同国家规定时，可能会产生一些差异。 医疗设备软件开发目的是合并入医疗设备中的软件系统，或者凭自身条件和用途可被用作医疗设备的软件系统。 问题报告用户或其他对此感兴趣的人所认为的对预期用途不安全、不合适的行为，或者与其规格相反的软件产品所出现的实际记录或者潜在行为。注1：本标准不要求软件产品对每一个问题报告都做出更改。生产商可以把问题报告当做误解、错误或者非重要事件而拒绝。注2：问题报告可以针对已发布的软件也可针对尚在开发中的软件。注3：本标准要求生产商问题报告相关的已发布产品实施额外的决策，制定步骤以确保管理行动被检验和实施。 程

10、序一系列相互联系相互作用把输入转为输出的活动。【ISO9000:2000， 定义】注：术语“活动”列入了财力的运用。 回归测试这个要求决定对一个系统组成做出改变的测试还没有对软件产品的功能性、可靠性或者性能产生不良影响，也尚未产生其他的缺陷。【ISO/IEC90030:2004，定义】 风险危害产生的可能性与危害的严重性的结合。【ISO/IEC 指南51:1999 定义】 风险分析有效信息的系统运用以检验故障，估计风险。【ISO/IEC 指南51:1999 定义】 风险控制制定决策和降低风险或者把风险控制在特定标准的程序。【ISO 14971:2000 定义，修改版】 风险管理分析、评估任务和

11、控制风险的程序中对管理政策、程序和实践的系统应用。【ISO 14971:2000 定义】 风险管理文件记录和其他文件的设置，不需要是连续的，是在风险管理程序中产生的。【ISO 14971:2000 定义】 安全性没有不可接受的风险【ISO/IEC 指南51:1999 定义】 保密性数据和信息的保护，非权威人士或系统不能够读取或修改数据和信息，也不会被拒绝接触它们。【ISO/IEC 12207:1995 定义】 严重损伤直接或间接的伤害或者疾病：威胁生命，对身体功能造成永久性损伤或对身体结构造成永久性伤害，或需要药物或外科手术介入去阻止对身体功能造成永久性损伤或对身体结构造成永久性伤害。注：永久

12、性损害指的是对身体结构或功能造成的不可逆转的损害或伤害，不包括无关紧要的损害或伤害。软件发展生命周期模型概念上的结构使得软件的生命跨度从它的要求定义到它的生产发布，它;识别软件开发程序中的程序、活动和任务，描述活动与任务之间的顺序和依赖关系，以及检验里程碑按规定可以交付使用的产品完成的检验。注：基于ISO/IEC12207：1995，定义 软件项目计算机项目的任何可识别部分【ISO/IEC90003:2004, 定义，修改版】注：三个术语识别软件的分解。最高等级是软件系统。最低等级尚未深层次分解的是软件单元。所有组成的等级包括最高等级和最低等级都可以被称作软件项目。那么软件系统是由一个或者多个

13、软件项目组成的，并且每个软件项目是由一个或者多个软件单元组成的或由可分解软件项目组成。责任留给生产商，为软件项目和软件单元提供定义和间隔尺寸。 软件产品电脑项目、程序以及可能相关的文件和数据装置【ISO/IEC 12207:1995 定义】 软件系统软件项目的有机结合以实现某个具体功能或者一系列功能。 软件单元不能再分成其它项目的软件项目。注：软件单元可以被用作来做软件配置管理或测试。 SOUP未知出处的软件（首字母缩略词）SOUP是一种软件项目。它已经被开发出来，是可行的，但并未为并入医疗设备的目的而研发（也被称作是现成的软件），或者是之前开发的软件，为此，单有充足的开发程序的记录是不够的。

14、 系统复合组成，包括一个或者多个程序，硬件，软件，设施和人，并提供性能来满足规定的要求和目标。【ISO/IEC 12207:1995，定义】 任务单件需要完成的工作 可追溯性开发程序的两个或多个产品之间建立关系的程度。【IEEE :1990】 检验通过监督具体要求被满足时的目标证据来检验。注1：“检验”用于标出相应的状态【ISO9000:2000， 定义】注2：在设计和开发的过程中，检验关系到检查已给定活动的程序，以决定与该活动一致的规定要求。 版本经鉴定的配置项的实例注1：对一个软件产品版本所做的修改，引发一个新的版本，需要软件配置管理功能。注2：基于ISO/IEC 12207:1995，定

15、义。4 基本要求 质量管理系统医疗设备软件的生产商应当证明其有能力提供一贯满足顾客需求并且适用相关规定要求的医疗设备软件。注1：可以用符合以下规定的质量管理体系来证明此能力：ISO134857；或者国家质量管理体系标准；或者国家法规所要求的质量管理体系。注2应用软件质量管理体系要求的指南可参阅 ISO/IEC9000311。风险管理生产商应当采用符合ISO14971的风险管理程序。软件安全级别分类（a）根据软件系统对病人、操作者或者其他人由于软件系统故障所造成的伤害，生产商应当为软件系统指定一个软件安全等级（A,B或者C）。最初的软件安全等级应当按照如下的严重程度来指定：A等级:不会对健康造成

16、损害或者伤害B等级：不会造成严重伤害C等级：可能造成严重损害甚至死亡如果按照说明操作软件系统造成的故障会引起危害，那么这种故障出现的几率应该是百分之百。如果通过硬件控制方法，由软件故障引起的死亡风险或者严重损伤随之降低到一个可接受的水平（正如ISO14971所定义的那样），或者降低故障所造成的影响，或者降低由故障引起的死亡风险或严重损害的几率，那么软件安全分类可以从C级到B级；如果通过硬件控制方法，由软件故障引起的非严重损害可以同样的降低到一个可以接受的水平，那么软件安全分类可以从B级到A级。（b）生产商应当为对风险控制措施的实施做出贡献的软件系统评级，基于风险控制措施在掌控之中的危险可能产生

17、的影响，为软件安全级别进行评定。（c）生产商应当在风险管理文档中用文件证明为各个软件系统所进行的安全级别评定。（d）当一个软件系统被分解成软件项目时，当一个软件项目被进一步分解成软件单元时，这样的软件单元应当继承了原软件项目(或软件系统)的安全级别分类，除非生产商用文件证明把它划分到其他软件安全类别的基本原理。这样的基本原理阐述应当解释新的软件项目是如何被隔离的，这样他它们就可以被分别分类。（e）如果软件项目的安全等级不同于分解之前软件项目的安全类别时，生产商应当用文件证明各个软件项目的安全级别分类。（f）为了符合本标准，在一个特定分类的软件项目需要程序的地方以及一组软件项目需要应用程序的地方

18、，生产商应当运用该组中的最高等级的软件项目分类需要程序和任务，除非生产商在风险管理文件中用提供用一个较低等级分类的原理解释。（g）至于每个软件系统，应当实施C等级要求直到软件安全等级被评定。注：在下文的要求中，要求必须被实施的软件安全级别分类是按照其类别检验的。5软件开发程序软件开发计划软件开发计划生产商应当为实施软件开发程序的活动建立一个软件开发计划，这个计划应当合乎即将要开发的软件系统的范围、量级和软件安全级别分类。软件开发生命周期应当被明确规定或者在计划中被引用。计划应当针对如下内容而发：在软件系统开发中将要用到的程序（见注4）；活动和任务可以交付使用的部分（包括文件）；在系统需求，软件

19、需求，软件系统测试以及在软件中所实施的风险控制措施之间的可追溯性；软件配置和更改管理，包括SOUP(未知出处软件)配置项目和为支持软件开发而做的软件；以及在软件生命周期的各个阶段，在软件产品，可交付使用产品以及活动中发现处理问题的软件问题分辨率。【A/B/C 等级】注1：按照软件系统的各个软件项目的软件安全级别分类，软件开发生命周期模型可以为不同的软件系统辨别不同的组成部分（程序，活动，任务和可交付使用产品）。注2：这些活动和任务能够重叠或者相互作用，也能够反复递回的运作。这并不意味着要用一个特定的生命周期模型。注3: 在本标准中其他程序的描述从开发程序中分离出来。这并不意味着它们必须按照分离

20、的活动和任务来实施。其他程序的活动和任务能够与开发程序融为一体。注4：软件开发计划可以引用现存的程序也可定义一个新的程序。注5：软件开发计划可以并入整个系统开发计划中。保持软件开发计划的更新生产商应当按照开发收益酌情更新该计划（A/B/C等级） 软件开发计划所涉及的系统设计和开发由于软件开发的投入，生产商应当在软件开发计划中参考系统需求。为满足的要求，协调软件开发和设计开发的生效，在软件开发计划过程中生产商应当包括或参考软件开发计划过程。（A/B/C等级）注：如果软件系统是一个单机系统（单一软件设备），在软件系统需求与系统需求上可能并无差异。 软件开发标准、方法和工具计划生产商应当列入或参考软

21、件开发计划：标准方法，以及工具与C级软件项目的开发结合起来【C级】 软件集成与集成测试计划生产商应当包括或者参考软件开发计划。这个计划可以使软件项目（包括SOUP未知出处软件）成为一体，并在融合的过程中实施检测。【B/C级】注：把合并测试与软件系统测试结合为一个独立计划和活动设置是可以接受的。 软件检验计划生产商应当列入或者参考软件开发计划中的如下检验信息：需要检验的可交付成果；每个生命周期活动所需要的检验任务；可交付物被检验的里程碑；和可交付物检验的验收准则。【A/B/C等级】 软件风险管理计划生产商应当包括或者参考软件开发计划。这个计划将实施软件风险管理程序的活动和任务，包括与SOUP(未

22、知出处软件)相关的风险管理。【B/C级】注：见条款7。文件材料计划生产商应当列入或者参考软件开发计划中的有关软件开发生命周期过程中引起的文件的信息。对于每一条经鉴定的文件或者文件类型，应当列入或者参考以下信息：标题，名字或者命名惯例；用途；文件阅读对象；以及开发，复审，批准以及修改的过程与责任。【A/B/C等级】 软件配置与管理计划生产商应当列入或者参考软件开发计划中的软件配置管理信息。软件配置管理信息应当包括或者参考：等级，类型，分类或者需要控制的项目列表；软件配置管理活动和任务；对实施软件配置管理和活动负责的系统；它们与其他系统的关系，例如软件开发或维护；当项目需要处在配置控制之下时；以及

23、当问题处理程序被应用。【A/B/C等级】 将要被控制的辅助项目需要被控制的项目应当包括工具、项目或者设置，用来开发医疗设备软件，这将对医疗设备软件产生影响。【B/C级】注：这类项目的样本包括编译/汇编，制作文件，批处理文件和特定的环境设置。 检验之前的软件配置项目监控在检验之前，生产商应当计划把配置项目放置于备有文件证明的配置管理监控之下。【B/C级】软件需求分析从系统需求定义和用文件证明软件需求对于医疗设备的每个软件系统，生产商应该从系统水平的需求定义和用文件证明软件需求 软件需求内容至于医疗设备软件，视情况而定，在软件需求中，生产商应当包括：功能要求和性能要求；注1 样本包括：性能（例如软

24、件的用途，时间要求），物理特性（例如代码语言，平台，操作系统），软件运行的计算机环境（例如硬件，内存大小吗，处理单元，时区，网络架构），以及对升级兼容性或多个SOUP（未命名软件）或其他设备版本的需求。软件系统输入和输出注2：样本包括：数据特征（例如，用数字表示的，文字数字式的，格式）级别，范围，以及预设值软件系统和其他系统之间的接口；软件驱动警报，警告和操作者信息；安全要求；注3：样本包括：与敏感信息妥协相关的；鉴定；授权；审查跟踪，以及通信完整。对人为误差和训练敏感的使用性工程要求；注4：样本包括与如下相关的：人工操作支持，手工设备干预；对个人的限制，以及需要人类关注的区域。注5：有关使用

25、性工程要求的信息科参阅IEC60601-1-6。数据定义和数据库要求；注6：样本包括：格式；一致；功能。在操作和维护点，已交付使用的医疗设备软件安装和验收要求；与操作和维护方法相关的要求；需要被开发的用户文件资料；用户的维护要求；以及法规要求。【A/B/C等级】注7：在软件开发初期，可能非所有要求都是可行的。注8：ISI/IEC 9126-1【8】在质量特征方面提供信息，这对给软件需求下定义可能是有用的。 软件需求中列入的风险控制措施制造商应在软件中列入风险控制措施的实施，由于在要求中硬件故障和软件潜在缺陷在医疗设备软件中是酌情存在的。【B/C级】注：在软件开发初期，可能非所有要求都是可行的。

26、并且，随着软件的设计和风险控制措施的进一步定义，这些要求是可以更改的。 再次评估医疗设备风险分析当软件需求确立和更新时，生产商应当酌情再次评估医疗设备风险分析。升级系统需求生产商应当确保现存的要求包括系统需求被酌情再次评估和升级，因此对软件需求分析活动也是同样。【A/B/C级】检验软件需求生产商应当检验并用文件证明软件需求：实施系统需求，包括与风险控制有关的；不要相互矛盾；用避免歧义的术语来表述；用术语陈述，该术语允许建立检验标准和实施测试来决定检验标准是否曾遇见过；能够被唯一分辨；以及对系统需求或其它资源可追溯。【A/B/C级】注：本标准不需要用标准规格语言。 软件体系设计把软件需求转变为一

27、个体系生产商应当把医疗设备软件需求转变成为一个备有文件证明的体系，用来描绘软件结构，区分软件项目。【B/C级】 为软件项目接口开发一个体系生产商应当为软件项目和软件项目之外的组件（软件和硬件皆有）的接口，以及软件项目之间，开发和用文件证明一个体系。【B/C级】 详细说明SOUP（未知软件项目）的功能和性能要求如果一个软件项目被定义为SOUP（未知软件项目），生产商应当详细说明SOUP（未知软件项目）的功能和性能要求，对于它的预期用途来说，这是很必要的。【B/C级】 详细说明SOUP（未知软件项目）的系统硬件和系统软件如果一个软件项目被定义为SOUP（未知软件项目），生产商应当详细说明必要的系统

28、硬件和系统软件来辅助SOUP（未知软件项目）的适当操作。【B/C级】注：样本包括处理器类型和速度，内存类型和大小，系统软件类型，通讯软件和显示软件需求。 分辨必要的风险控制隔离生产商应当分辨出对风险控制不可或缺的软件项目及怎样保证隔离状态的有效。【C级】注：隔离样本是使得软件项目在不同处理器上实施任务。隔离的有效性能够通过处理期间无共享资源来保证。 检测软件体系生产商应当检测并用文件证明如下内容：软件体系实施系统和软件需求，包括与风险控制相关的要求；软件体系能够支持软件项目之间、软件项目与硬件项目之间的接口；以及医疗设备软件支持任何SOUP（未知软件项目）的正确操作。【B/C级】软件详细设计把

29、软件体系细化为软件单元生产商应当细化软件体系知道它以软件单元的形式出现。【B/C级】为每一个软件单元开发详细设计生产商应当为每一个软件项目的软件单元开发一个详细设计并用文件证明。【C级】 为接口开发详细设计生产商应当为所有软件单元与软件单元之外的组件（硬件或者软件）的接口，以及软件单元之间的接口开发一个详细设计并用文件证明。【C级】 检测详细设计生产商应当检测软件详细设计并用文件证明：实施软件体系；以及不与软件体系相互冲突。【C级】 软件单元的实施和检验 实施各个软件单元生产商应当实施各个软件单元。【A/B/C级】建立软件单元检验程序生产商应当为检验检测各个软件单元建立策略方法和步骤。当通过测

30、试完成检测时，应当为其正确性而评估测试过程。【B/C级】注：验收标准样本为：软件编码实施要求包括风险控制措施吗软件编码与软件单元中所详细设计并用文件证明的接口相互冲突吗软件编码符合项目过程或者编码标准吗 软件单元验收标准在软件单元整合到较大的软件项之前，生产商应该适当的为软件单元建立验收准则，保证软件单元符合验收标准。 增加软件单元验收标准当以下项目出现在设计之中时，生产商应当酌情列入增加的验收标准：正确的时间顺序;数据流和控制流；有计划的资源分配；故障处理（错误鉴定，隔离与修复）；变量初始化；自我诊断；记忆管理与记忆溢出；以及边界状态。【C级】 软件单元检验生产商应当完成软件单元检测并用文件证明其结果。【B/C级】软件集成和集成测试 一体化软件单元生产商应当使软件单元一体化以与集成计划（见）一致【B/C级】 检测软件集成生产商应当按照集成计划，检测并记录软件集成的以下方面（见）：软件单元应当整合集成为软件项目和软件系统；以及系统的硬件项目，软件项目以及人工操作辅助项目（例如人类特征接口，在线帮助菜单，声音控制等）已被集成入该系统。【B/C级】注：检测仅指项目已经按照计划集成化，非他们按照意愿所