1、ICS 27. 120.99;35.080 F 82 备案号：158402005EJ 中华人民共和国核行业标准EJ/T 1058. 2-2005 核电厂安全系统计算机软件第2部分：预防软件导致的共因故障、软件工具和预开发软件的使用s。ftwarefor computers imp。tantto safety for nuclear power plants -Part2: S。ftwareaspects 。fdefence against common cause failure, use of software t。Isand 。fpre-developed software CIEC 60
2、880-2: 2000, MOD) 。已05310001332005一04一门发布2005一07一01实施国防科学技术工业委员会发布EJ/T 1058.2一2005目次前言. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II 1 范围.1 2 规范性引用文件电.1 3 术语和定义.1 4 要求和建议.3 4. 1 防止软件导致
3、的共因故障.3 4.2 用于软件开发的软件工具.5 4. 3 预开发软件的鉴定.9 附录A（资料性附录）共因故障应考虑的事项和多样性.17 附录B（资料性附录）EJ/T 1058-1998对软件工具使用和鉴定的要求.20 附录C（资料性附录）用于编制和检查技术规格书、设计文件和代码的工具.21 附录D（资料性附录）EJ /T 1058-1998关于预开发软件的要求.23 EJ/T 1058.2一2005前言本部分是核电厂安全系统计算机软件系列标准的第2项标准。本部分修改采用IEC60880-2:2000核电厂安全重要计算机软件。本部分与!EC60880-2:2000在技术内容上没有差异，但是为
4、在格式上符合GJB6000-2001标准编写规定的要求，进行了编辑性修改，主要有tII a) 对第1章按GJB6000的要求进行了修改：b) 对第3章的术语和定义重新进行了排序：c) 在规范性引用文件中将引用的国际标准和文件改为对应采标和合适的我国标准和文件。本部分与下列标准结合使用可以对计算机在核电厂中的应用提供一般指导z一-GB/T15474一1995核电厂仪表和控制系统及其供电设备安全分级：一EJ/T529-1990 用于核电厂安全重要系统数字计算机；-EJ /T 890-1994 核电厂安全有关计算机软件质量保证细则：一EJIT 1060-1998 数字计算机在核电厂仪表和控制中的应用
5、。本部分的附录A、附录B、附录C和附录D为资料性附录。本部分由中国核工业集团公司提出e本部分由核工业标准化研究所归口。本部分起草单ft!.z核工业标准化研究所。本部分主要起草人：魏杰、张京长核电厂安全系统计算机软件第2部分：预防软件导致的共因故障、软件工具和预开发软件的使用EJ/T 1058.2一20051 范围本部分规定了在核电厂安全重要计算机软件生产过程中的每个阶段（包括开发、设计、验证、确认与运行）以及每个阶段中的文件档案对于预防软件导致的共因故障、软件工具使用和预开发软件使用的基本要求以及应遵循的原则。本部分适用于核电厂安全系统中用于执行安全功能的计算机软件生产过程中的对软件导致共因故
6、障的预防、软件工具的使用和预开发软件的使用及其涉及到的数据准备和确认。2 规范性引用文件下列文件中的条款通过本部分的引用而成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单（不包含勘误的内容或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。GB/T 15474一1995核电厂仪表和控制系统及其供电设备安全分级盯IT1058一1998核电厂安全系统计算机软件HAF102 核电厂设计安全规定HAD102 核电厂设计总的安全原则ISO/IEC 9126: 1991 信息技术软件产品评估质量特性及其使用
7、指南IEC 61069-2: 1993 工业过程测量和控制一系统评估用系统特性的评定一一第2部分：评估方法IEC 61513: 2001 核电厂安全重要仪表和控制系统系统总要求3 术语和定义EJ/T 1058一1998确立的以及下列术语和定义适用于本标准。3. 1 直观显示animation 用规定的行为状态表达方式和某些输入值得出的实际值显示由相关文件定义的行为状态的过程。3.2 应用功能app I i cat i on funct i on 执行与受控过程有关任务而与系统本身功能无关的一个仪表与控制(l&C)系统的功能。3.3 通道channel 用于信息流通的通路，该通路可以包含冗余。3
8、.4 信号轨迹signal trajectory 决定系统输出的所有设备状态、内部状态、输入信号以及操纵员输入的时间历程。3.5 故障failure 故障是指实际达到的效能偏离了预期效能。EJ/T 1058.2一2005注z故障是硬件缺陷、软件缺陷、系统缺陷、操纵员错误或维修错误以及导致故障的相关信号轨迹的结果，3.6 缺陷fault 硬件、软件或系统部件的缺点。缺陷分为随机缺陷（如由硬件磨损导致的）和系统缺陷（如由设计引入的），对于软件包括编码错误和技术要求错误。3. 7 注z系统一个部分的缺陷（特别是设计缺陷）可能直到出现某些特定情况或影响到那个部分的信号轨迹才被发现，其结果是不能执行预期
9、的功能。这会导致系统的那个部分出现故障。共因故障commoncause fa川ure( CCF) 一种故障，它是一个或多个事件引起有多重通道的系统或多重系统中两个或更多分离通道同时故障导致系统故障的结果。注1：根据情况，共因故障可以认为是系统级的或构成一个安全组的系统级的。注2：见故障的定义（3. 5) 0 3.8 数据data 以适于通讯、分析或计算机处理的方式对信息或指令的表示。注：系统中用于定义参数和用示例说明应用与服务功能的数据称为应用数据。3.9 多样性diversity 以两种或更多的方式、方法达到一个特定目标的原则。多样性专门用于防止共因故障。它可以通过物理上相互不同的系统或功能
10、多样性的方式来实现，这里，相似的系统以不同的方式达到特定的目标。3. 10 功能多样性functional diversity 多样性在功能级的应用（例如，把压力限值和温度限值都作为紧急停堆触发）。3. 11 功能及其相关系统和设备functions, and associated systems and equipment (FSE) 为达到一个目标或目的而执行的功能，相关系统和设备是那些用于完成这些功能的部件集合。3. 12 动态分析dynamic analysis 根据一个系统或部件在运行期间的行为对其进行评价的过程。与静态分析相对应。3. 13 静态分析static analysis
11、根据一个系统或部件的形式、结构、内容或文件记录对其进行评价的过程。与动态分析相对应。3. 14 2 人为失误human error （。rmi stake) 导致非预期结果的人的行为或行动。注：下面的例子说明了“失误”、“缺陆”、“故障”和“信号轨迹”的划分。在生产某件产品时如果人或过程有“失误”，就会导致该产品中的“缺陷”。如果这个“缺陷”没有被改正，在使用该产品时就可能令人满意，也可能失效。如果使用时威胁到这个“缺陷”而且没有其他的防御“故障”的措施，该产品就会失效“故障”是“缺陷”受到威胁而没有其他防御措施的结果。就软件来说，对“缺陷”的威胁是“信号轨迹”给出的3. 15 库librar
12、y 在类别上组合在一起但却分别被选入最终软件产品内的相关软件元素的集合。3. 16 操作系统软件operational system software EJ/T 1058. 2-2005 运行期间在目标处理器上运转的软件，例如用于如下目的的软件：输入输出驱动、服务、中断管理、调度程序、通讯驱动、面向应用的库、在线诊断、冗余和适当的降级管理。3. 17 支持软件support software 用于帮助进行其他软件的开发、测试或维护的软件，例如：编译程序、代码生成器、模拟器、离线诊断软件、初始化软件。3. 18 系统软件system software 为一种或一类特定的计算机系统设计的用于计算机
13、系统及其相关程序的运行和维护的软件，例如，操作系统、编译程序等。系统软件通常由操作系统软件和支持软件组成。3. 19 预开发软件pre-developed software (PDS) 作为商用产品或专利产品己经存在的考虑用于基于计算机系统的软件。3.20 软件版本software version 对以前的软件产品进行修改或修正后得到的软件产品的样板。3. 21 多版本软件n-version or multi-version software 为满足一个共同要求和共同的验收试验而开发的不同程序，也就是通常说的版本的组合。通常在冗余硬件中同时并独立的执行这些版本。在试验系统中使用同样的输入或在冗
14、余系统中使用相一致的输入。采用预先确定的策略（例如表决对不同版本相互之间不一致的输出作出判定。3.22 假设始发事件postulated initiating event (PIE) 经鉴别可能引发预计运行事件或事故工况以及它们的后续故障效应的事件。3.23 可再使用的reuseable 描述软件模块可以在不止一个计算机程序或软件系统中使用的性质的限定词。4 要求和建议下面给出了要求和建议，其不同在于要求用“应”引出，而建议用“宜”引出。4. 1 防止软件导致的共因故障一些软件设计和编程的缺陷能够导致按照GB/T15474一1995划分的1E级功能的共因故障，本条给出对预防这些缺陷的要求。4.
15、 1. 1号言3 EJ/T 1058. 2-2005 共因故障可能发生在用来防御相同假设始发事件的不同序列的I&C结构内的系统和设备中（见IEC61513:2001的5.3. 1）。软件本身不存在共因故障模式。共因故障与由功能要求、系统设计或软件中的缺陷而引起的系统故障有关。纵深防御概念（见HAF102的2.2），应贯彻于安全有关的全部活动中，包括与组织、设计或人员行为有关的方面，以保证这些活动均置于重叠措施的防御之下，即使有一种防御失效，亦将得到补偿或纠正。单一故障准则（见HAF102的3.8. 2）要求安全系统的装置（或组合）在其任何部位发生单一随机故障时，仍能保持所赋予的功能。软件缺陷是
16、系统缺陷而不是随机缺陷，因此一个系统的软件设计不能以与在硬件中应用过的相同方式应用单一故障准则。在应用纵深防御概念时，应考虑每个防御层次内和冗余的防御层次之间由软件引起共因故障的可能影响，并在整个开发和评价过程中应采取恰当的防范措施，例如za) 在开发中，对每一单个防御层次进行验证和确认：b) 对冗余防御层次的独立性和多样性进行评价。增强某些系统可靠性和减少某些潜在共因故障的一个方法是采用多样性（见HAF102的3.8.3)4. 1. 1. 1 日IT1058-1998的要求按照、EJ/T1058一1998的4.2和A2.2的要求，应根据系统可靠性要求对计算机系统的结构进行说明。4. 1. 1
17、. 2指出了可用于避免共因故障的有关措施（包括纵深防御、功能退化、故障的管理、功能多样性、软件多样性、空间的隔离和模块化、解除祸合、逻辑隔离），但没有逐一说明全部措施。为此，在4.1中规定评价由软件引起的潜在共因故障的方法并规定避免共因故障发生的技术。4. 1. 1. 2 预防由软件引起的共因故障的基本原理任何软件缺陷在被探测到并改正前都存留在相关的系统或通道中，如受到特定信号轨迹的激励就会引起故障，这就是防御软件缺陷的理论依据。如果用于防御相同假设始发事件的不同序列中的两个或更多的系统或通道（见IEC61513:2001的5.3. 1. 5）有缺陷，在一个敏感时间段内受到特定信号轨迹的影响，
18、两个（或全部）系统或通道就会发生故障，这就是共因故障。A.2中对这种状况给出了更详细的描述。因而在设计期间宜考虑由软件导致的潜在共因故障。如果能够预见发生共因故障的假设条件，就可以考虑进行设计变更，采取防御措施包括采用软件多样性以预防由软件导致的共因故障。采用多样性能够达到的对防御共因故障的改善程度和对可靠性的改善程度是无法定量化的。要求根据对软件能够达到的可靠性的定量化的评价而作出判断。如在软件设计开始前发生了人为失误，它们就可能导致对系统的要求就存在缺陷，以及导致单靠软件开发设计不能进行防御的潜在的系统故障。IEC61513:2001的5.3. 1. 5在系统级别上对防御这样的共因故障进行
19、了讨论。如在软件开发设计过程中发生了人为失误，它们就可能导致软件缺陷和潜在的系统故障。在这里，这样的缺陷会导致多于一个保护列发生故障，就认为这种故障是共因故障。4. 1. 2 抗共因故障软件的设计开发最高质量的软件是预防由软件引起的共因故障的基本的和最重要的防御措施，就是说要把错误降低到最低程度。正如在盯IT1058一1998的51、6.1和A.2.8中所论述的，自监测特性所包含的内容（例如数据合理性检查、参数范围检查以及循环时序等是限制软件导致的潜在共因故障的一个更重要因素。在EJIT1058-1998以及下面的条文中给出了达到具有自监测特性的高可靠性软件的要求。对于软件的开发和验证，利用有
20、软件工具支持的已经开发完善的软件工程方法能够有助于减少进行设计决策的次数，进而可能减少已开发软件中缺陷的数目。4. 1. 3 软件导致的共因故障的来源和影晌4 EJ/T 1058. 2-2005 4. l. 3. l 应在系统级别和或在核电厂安全重要I&C系统的I&C总体结构级别上对软件导致的潜在共因故障进行分析并提供文件证明。注1:IEC 61513:2001的5.3. 1给出了对I&C总体结构的要求：注2:IEC 61513:2001的6.1. 2给出了对单个I&C系统结构的要求。4. 1. 3. 2 分析宣包括下列步骤：a) 鉴别用于I&C结构或系统中的软件组件：b) 分析在系统和I&C
21、结构内这些组件导致的潜在共因故障：c) 分析这些共因故障的影响。注：对缺陷的潜在影响进行分析不能免除在EJ厅1058-1998中要求的对验证和确认活动的要求。这种分析的目的是揭示设计中的弱点，从而进行设计变更和或改善软件设计的可靠程度。4. 1. 3. 3 如果在一个以上的系统中应用其用模块，应对这些模块进行鉴别并应对其可靠性进行分析。指导作出正确性论证的方法参见A.5。4. 1. 3. 4 应对基于计算机的系统内部或系统之间的数据传输进行鉴别。应进行分析以确定错误数据是否会导致接收数据的计算机或系统的共因故障。4. 1. 3. 5 应评估如下电厂状况的可能性，该状况受到产生同样的和同时的电厂
22、信号轨迹的不同硬件中运行的同一软件的影响，井因此揭示出在几个通道或功能路径中相同的软件缺陷。注：故障可能囱一些信号轨迹引起，而在单个通道或系统软件的设计、验证和确认期间没有考虑这些信号轨迹4. l. 3. 6 软件维修活动具有引起共因故障的潜在可能，因而直对更改软件或数据的过程进行评价以保证不会引入这样的缺陷。4. l. 3. 7 作为对I&C结构设计中防御共因故障评价的一部分（见IEC61513:2001的5.5.3），应对软件导致的潜在共因故障进行分析并提供文件证明。4. 1.3.8 如果分析说明软件导致的共因故障会引起不能接受的威胁就应改进软件或I&C结构的设计。支持实现防御共因故障的方
23、法参见A.4，支持实现多样性特性的方法参见A.604. 1. 4 多样性的实现4. 1. 4. 1 宜使用具有功能多样性的独立系统实现多样性。如果不适于或不可能采用功能多样性，宜考虑采用系统多样性、多种软件特性和多种设计方法。重要的多样性措施见A.6。根据己经作出的分析对所选择的防御共因故障的技术应提供文件进行证明。4. 1. 4. 2 在软件级别上，防御共因故障宣建立在选择合适技术的基础上，例如：a) 软件多种运行条件的保证：b) 防御错误和故障的传播：c) 减少共因故障的负面影响；d）通过为相同功能要求的不同实现来编制不同技术规格书的方法实施软件多样化。注1：设计与实现方法的不同直作为内含
24、而不是要求注2：不推荐使用多版本编程4. 1.5 与多样性应用有关的有利与不利因素的平衡如果声称使用多样化软件，直在上面分析的基础上对软件整体可靠性的有利与不利因素进行说明并提供文件资料（见HAF102的3.8.2和HAD102的4.6. 2）。A.7给出了潜在的有利与不利因素及其说明。4.2 用于软件开发的软件工具4. 2. 1 引言5 EJ/T 1058. 2-2005 本条扩充了盯IT1058一1998对用于核电厂安全系统计算机软件开发的软件工具的要求。4. 2. 1. 1 日T1058一1998对软件工具的要求附录B列出了EJ/T1058一1998中关于专门用于软件工具的使用、验证和评
25、价的要求。4. 2. 1. 2使用软件工具的基本原理使用合适的软件工具降低了在软件开发过程中引入缺陷的风险，能够增加软件开发过程的完整性，从而增强软件产品的可靠性。由于使用软件工具能够减少软件生产需要的时间和工作量，因而也具有经济利益。工具可用于自动检查与建造法规和标准的符合程度、以标准格式产生适当的档案和一致的文件以及支持变更控制。工具还能够减少测试和维护自动日志的工作量。由于一种特定的开发技术也需要使用工具，因而工具是必需的。把工具结合起来使用才是最有用的。应注意不能要求工具承担超出其实际能力的任务，例如在涉及到判断时工具不能代替人。在某些情况下，工具的支持比过程的完全自动化更适当。在选择
26、工具时，必须对照不使用工具的益处和风险来平衡使用工具的益处和风险。选择工具的重要原则是限制产生错误和引入缺陷的可能性，从而最大限度地探测缺陷。本标准的本部分范围内涉及的工具包括：一一用于支持收集要求的工具：一一用于把要求转换为最终的系统代码和数据（可能有许多中间步骤）的工具：一一用于直接支持进行验证、确认矛！测试的工具：一一用于准备和管理应用数据的工具（见4.2.3.5):一一用于软件开发涉及到的过程和产品的工具。在EJ/T10581998和本标准的范围内涉及的工具不包括：一一月于计算在安全重要设备的设计与分析期间使用的重要变量的离线工具：一一用于支持任务而与软件开发没有直接关系的文字处理工具
27、、工程管理工具和其他办公用的行政管理工具。4.2.2 工具的选择4. 2. 2. 1 为支持软件的设计过程，应选择用于安全系统软件开发的工具。4.2.3.1说明了工具选择应遵守的准则和方法。应鉴别并提供文件说明对所有工具适用性的限制。在没有预先论证时，对工具及其输出的使用不应超出其声明的范围。对核电厂安全系统软件开发用的工具，应按要求验证和评价其与工具的可靠性要求、工具的类型（见4.2.2.2）和工具引入缺陷的潜在可能处于相一致的级别。工具应具有足够的可靠性以保证它们不会对末端产品的可靠性造成危害。例如，由于工具可能引入错误、产生不可靠的输出、没有探测出已经存在的缺陷而对软件开发造成不利影响。
28、为降低对单个工具的可靠性要求，在选择工具时可以考虑采用纵深防御原则和多样性原则。4.2.2.2 对工具所要求的验证和评价的级别也依赖于工具的类型和工具的输出是否能够完全被验证或确认。工具的类型有：a) 转换工具，例如代码生成器、编译程序，以及那些把文本或图形从一个抽象级别转换为另一个抽象级别（通常为更低的级别）的工具：b) 验证与确认工具，例如静态代码分析器、测试覆盖范围监测器、法则验证助手以及模拟器：c) 用于对运行工况下的软件维护和监测的诊断工具：d) 基础构造工具，例如开发支持系统：e) 配置控制工具，例如版本控制工具。4. 2.3 对工具的要求6 EJ/T 1058. 2-2005 对
29、工具的要求分为如f主题：a) 软件工程环境；b) 工具的鉴定：c) 工具的配置管理：d) 翻译程序，编译程序：e) 应用数据工具：f) 测试自动化。4.2.3. 1 软件工程环境4. 2. 3. 1. 1 在通过使用工具得到有益结果和可以利用工具的地方都宜使用工具对软件生存周期的各个方面提供支持。应对软件工程环境和开发过程进行分析以确定提供软件支持的策略方针。宜对分析结果提供文件证明。如果没有适用的工具，可以考虑开发新的工具。能从工具支持得到益处的运作过程的例子有：a) 技术规格书、设计和代码的；编制与检查（参见附录C): b) 对语言或语言的一个子集进行剖解的工具（见4.2. 3. 4) ;
30、 c) 应用数据的准备、验证和确认（见4.2. 3. 5) ; d) 测试自动化（见4.2.3.6）。4. 2. 3. 1. 2 对用于软件工程环境的工具，宜编制选择和评价准则并区分先后次序以在使用前进行折中综合。宜根据ISO/IEC9126: 1991定义的下列软件品质特征组织准则的结构：功能性、可靠性、可用性、放率、可维修性和可移植性。准则可以包括其他的项目，例如为使用工具所需要的许可证申请事项与资料、工具开发所遵守的严格的质保大纲、工具供货商的历史、替代工具等。4. 2.3. 1.3 应对支持软件工程环境的工具进行分析并提供文件资料说明：a) 工具是如何对每一处理方法提供或不提供支持的：
31、b) 对工具的准确鉴别（例如名称、版本号）和它们可能的配置：c) 在工程中是如何使用每个工具的：d) 对每一工具的输出是如何对照其输入进行验证和或确认的：e) 其他的工具或处理方法是如何减轻工具中缺陷的后果的，包括在为在线应用而准备和制作数据期间对潜在错误的减缓：f) 工具是如何与其他工具接口的，即其他工具或知识库也需要工具以使用、处理和传送共享信息：g) 工具如何对用户和软件工程环境的其他部分提供一致的接同时工具是如何与所选择的软件工程方法相适合的：i) 工具对错误的探测与处理能力：j) 工具是如何满足应用（包括用户、设备、环境和用户任务）的要求而使用户效率最大化和用户错误的影响最小化的：k
32、) 工具是如何防止未经授权的使用和误用或修改的。4. 2. 3. 1.4 对工具进行维护、升级或替换的策略方针应提供文件资料证明。该策略方针是用来确保运转的软件在用于核电广的整个期间能够得到维护的运转软件维护策略方针的一部分。它还应确保工具转到新版本时要进行证明而且要对工具的新版本进行合适的鉴定，即按本标准的要求进行评价。4. 2. 3. 1. 5 对用于提供多样性的工具（例如用于开发多版本的不相同的软件系统的编译程序），直论证其不同。可以说明下列内容以进行论证：a) 每个工具的供货商是不同的（例如，一个工具可以是开发得到的而其他的工具可以购买得到）：b) 这些工具具有不同的输入和或输出语言：
33、c) 这些工具的要求和设计方法不同。7 EJ/T 1058. 2-2005 4.2.3.2 工具的鉴定4.2. 3.2. 1 应确定工具鉴定的策略方针井在对工具进行鉴定时遵照执行。该策略方针应考虑工具的可靠性要求和工具的类型。4.2. 3.2.2 确定工具的可靠性要求时应考虑如下因素：a) 工具的缺陷会导致什么后果：b) 工具引起或诱导执行安全功能软件中的缺陷的可能性：c) 是否有其他工具或方法能减轻工具中缺陷的后果。注：采用纵深防御原则和多样性原则可以降低对工具可靠性的要求。4.2.3.2.3 工具鉴定的策略方针应考虑：a) 对工具开发过程和工具供货商历史的分析：b) 足以保证对工具的输出进
34、行验证和便于学习用的工具文件适宣性：c) 对工具的测试或确认：d) 使用一段时间后对工具的评价：e) 工具使用经验反馈。注：4.3关于对预开发软件使用的鉴定要求也宜考虑作为工具鉴定策略方针。4.2.3.2.4 如果最终的软件要包括工具的输出，宜系统地对工具的输出进行验证（例如通过测试、分析或与功能相似软件的输出进行比较）。4.2. 3.2.5 如果工具的输出会引入缺陷到最终软件而且没有系统地对工具的输出进行验证，以及如果没有（通过多样性方法或系统设计）对工具缺陷采取减缓措施，就应按4.3的要求对软件工具进行验证和评价或按EJ/T1058一1998的要求进行工具开发。对于那些先前为在相同类别（即
35、有类似的故障后果的类似应用中使用而已经证明过的工具，在鉴定过程中可考虑以前使用这些工具的经验。4.2. 3.3 工具的配置管理4. 2. 3. 3. 1 全部工具都应处于配置管理之F以保证完全地鉴别所选择的工具（包括名称、版本、修改和可能的配置）和用于生成基准软件的工具参数。注z这一要求不只是对最终软件的一致性有用。它还有助于评价源代码、工具或工具参数中的缺陷的起源。可能还需要它来评价由软件工具导致的潜在共因故障。4.2.3.3.2 对于那些其输出会把缺陷引入最终软件的工具，应在工具的整个生存周期内对关于其错误历史和局限性的文件记录进行维护。4.2.3.3.3 对工具的任何修改都应进行验证和评
36、价。4.2.3.4翻译程序编译程序本条给出了与翻译程序编译程序有关的特殊要求。许多编译程序的大小和复杂性使得非常难以论证该编译程序能正确地工作。然而大量的使用经验能增强对该编译程序正确工作的信任。4. 2. 3. 4. 1 宜在本条说明的关于翻译程序编译程序的指导准则的基础上选择翻译程序编译程序（本条补充了EJ/T1058-1998附录D的要求）。4.2.3.4.2 翻译程序编译程序不应不给出警告提示就把程序设计者引进的防御程序或错误检查特性删除。4. 2. 3. 4.3 宣避免使用编译程序最优化。如果产生的目标代码非常难以理解、调试测试和确认测试就不应使用编译程序最优化。注：如由于受到硬件速
37、度和存储容量的限制可采用代码最优化以满足性能要求。在一些例外的情况下，除了改变硬件平台外可以考虑采用汇编代码作为替代4.2. 3.4.4 如果采用了最优化，应对最优化的代码进行测试、验证和或确认。8 EJ/T 1058. 2-2005 4.2.3.4.5 应把用于目标系统的库作为预开发软件组件的组成部分。对库中使用的组件应进行评价与鉴定井按与4.3对预开发软件鉴定相一致的要求来使用。4.2.3.4.6 为保证由翻译程序引入的不能直接用源代码行语句（例如错误检查代码、错误和异常处理代码、初始化代码）描述的附加代码（汇编指令）是正确的，应进行测试、验证和确认。4.2.3.5 应用数据工具基于计算机
38、的安全系统通常需要应用数据来定义应用功能和服务功能的信号、地址和功能参数。这些数据非常多，通常由如下信息组成：a) 信号标识、信号描述、信号源定位和电缆编号、测量类型、电信号范围或状态、工程单位、报警状态定义、报警和触发级别：b) 信号终端点、数据库地址和指针、信息地址和指针、硬件地址和特性、显示布置、显示符号和颜色信息、显示信号内容标识、日志和内部信息的格式和详细内容：c) 保护动作代码、报警优先权或逻辑、输出动作、逻辑操作和定时器的标识、故障时采用的输出状态。数据可以从电厂运行和过程仪表的设计图纸、清单和技术规格书中得到。为装载到系统的目标处理器要对数据进行转化，继而用于控制在线软件的运转
39、。下面给出为在线使用而对数据的准备、验证和确认、管理要求。4.2.3. 5. 1 应定义从电厂应用数据而来的软件系统应用数据的设计并形成文件。4.2.3.5.2 应识别那些在运行期间可以被操纵员改变的应用参数，以及识别用于控制改变这些参数的方法。4.2.3.5.3 对可修改的应用数据作出的更改不应使系统的其他数据和代码在运行时恶化。4.2.3.5.4 对数据验证和确认（包括鉴别和清除错误的程序应类似于对软件验证和确认的程序。应进行首尾相接的验证检查，这应包括从电厂设计信息中提取数据开始直到在线软件中数据结构合井的数据转换的每一阶段（包括了转换媒体的使用）。4.2.3.5.5 要装载到在线软件的
40、数据格式宣是一种能够被打印和验证的格式，或应是能用工具取出数据并存储为一种在验证时易于理解的格式。4.2.3.5.6 应提供一个软件设施用于对所有装载于现场的配置数据进行验证。4.2.3.5. 7 在用数据说明两个系统之间接口的地方，提供给每一系统的数据直从相同的数据库中自动产生（见IEC61513:2001的5.3.1.4）。4.2.3.5.8 在一些情况下，通过配置数据控制或修改软件功能性（包括方法、数据流、输入和输出连接关系，要求特别的文件证明以保证对这些数据进行了足够级别的评价和后续测试。对这些数据更改后可要求进行大量的系统再测试。4.2.3.6 测试自动化自动化使得在一给定时间内能完
41、成更多次测试。满足下列要求就可以达到自动化。4.2.3.6. 1 宜对生成测试数据、传输或转换测试数据和测试结果以及评价测试结果的自动化确认工具建立完整的测试日志。这对模块测试以及对电厂模拟都是适用的。4.2. 3.6.2 宣使用适当的工具对装载于目标系统的可执行代码的行为特性进行测试和或模拟。4.2.3.6.3 应使用适当的工具确保或验证正确的可执行代码被正确地装载于目标系统。4.2.3.6.4 直考虑使用下列附加工具：a) 测试发生器、覆盖范围测试分析器和测试驱动器：b) 带有转储检查和跟踪设施的在线诊断程序：c) 带有在源代码级别的调试设施的调试器：d) 便于回归测试的成套的自动化测试工
42、具。4.3 预开发软件的鉴定9 EJ/T 1058. 2 - 2005 4.3. 1 引言本条给出在基于计算机的I&C系统中使用预开发软件的要求。这些要求是作为对融合了预开发软件系统的鉴定要求的一部分而提出的（见IEC61513:2001的6.4）。用于I&C系统的预开发软件，其范围包括了从小的软件组件（例如，一个应用功能库模块）到大而复杂的软件产品（例如，操作系统的组成部分或通讯驱动器）。考虑到硬件，预开发软件可分为下面两种类型：a) 不是为特定硬件环境专门开发的通用预开发软件：b) 与硬件组件结合在一起只能与该硬件联合使用的预开发软件。如果预开发软件组件能在不同的计算机程序或系统中使用，例
43、如其作为一个设备族（设备平台）的部分时，则称这些预开发软件组件是可再利用的。那些独立于特定电厂应用细节的组件可能己经为其在执行1E级功能的系统中使用而进行了鉴定。4. 3. 1. 1 日T1058一1998对使用预开发的要求附录D.1扼要说明了EJ/T1058-1998中对预开发软件的使用要求，那些要求应与这里给出的要求一起使用。4.3. 1.2 使用预开发软件的基本原理新的安全系统的技术规格书经常要鉴别使用包括预开发软件的预开发设备，以部分或全部实现“新系统”（见IEC61513:2001的6.1. 2. 1）。当以合适的方式引入有合适品质的预开发软件项目时，使用预开发软件就会有益于提高生产
44、率和系统的可靠性。当预开发软件项目己经在许多类似于预期应用的应用软件中使用过，在对它们进行评价时可以说明这些运行经验中的有益之处。再使用已经确认过的预开发软件能增加对系统可靠性的信任。4. 3. 2 一般要求4.3.2. 1 如要选择一个预开发软件作为一个系统的部分而使用，应根据适合于欲实现功能的安全类别对照本标准的准则对其进行评价。4.3.2.2 对预开发软件的评价应：a) 确定预开发软件具有满足系统要求技术规格书（见IEC61513:2001的6.l. 1）的功能、性能和结构要求的能力，以及由此产生的适宜性：b) 鉴别对预开发软件进行改正或改写而需要的任何修改：c) 评价预开发软件的品质：
45、d) 在需要上面的评价时评价预开发软件的运行经验。4. 3.2.3 对评价结果应提供文件资料说明。注：本标准中所说的评价是由对基于计算机的系统开发负责的组织、（或代表该组织）作出的活动：这既不意味着也不需要评价是由执照颁发机构作出的，尽管他们也可以这么做。4.3. 3 评价过程10 对预开发软件的评价过程应包括：a) 对预开发软件和现有鉴定文件（见4.3. 3. 1）功能和性能的评价：垃：对于融合在产品内的预开发软件，其特性可以用产品的特性来表示，参见IEC61069-2. b) 对软件设计和开发过程的质量评价（见4.3. 3. 2) ; 注：对可再使用的己经评价过的软件，只需进行适直性评价：
46、对其确认就暗含着进行了质量评价。c) 如果需要补偿已经在a）和b）中论证的弱点，要对运行经验进行评价（见4.3. 3. 3) ; d) 对从上面评价中和相关的补充工作中得到的证据的综合性文件评价，这会使得预开发软件在系统中的使用得到接受。图l表示对预开发软件评价过程不同阶段之间的关系。图2表示该过程与系统鉴定之间的关系cEJ/T 1058. 2-2005 注：本条叙述的过程是一个现实的、简单的过程，因而没有说明评价活动之间以及这些过程和计算机化的系统技术规格书与开发活动之间的全部重复或重叠的衔接4.3.3. 1 适宜性评价该过程的目的是确认预开发软件的功能、性能和结构的技术要求遵守了系统技术规
47、格书所规定的对预开发软件的要求该过程鉴别那些直接用于电厂系统的组件，也鉴别那些需要修改的组件注2评价是在对技术要求和功能文件进行分析的基础上作出宜在系统技术规格书（见IEC61513: 2001的6.2）的早期阶段开始对预开发软件适宜性的评价并应完成评价以便于z一一在系统的结构设计中对设计者提供帮助：一一获得关于预开发软件的功能和性能满足系统要求的可审查的证据4. 3. 3. 1. 1 需要的输入文件4. 3. 3. 1. 1. 1 应能得到如下文件：一一鉴别系统结构框架中的预开发软件应实现的功能、接口和性能要求的系统技术规格书文件（见IEC 61513:2001的6.1.1和6.1. 2) ; 一一预开发软件技术规格书和用户文件这些文件宣明确地详细说明关于系统功能和性能技术要求的全部特性如果不能明确地详细说明这些特性，应进行分析或测试使其明确4. 3. 3. 1. 1. 2 应对预开发软件进行配置管理并准确了解预开发软件的版本、配置和运行环境4. 3. 3. 1. 2 对适宣性的评价要求对4.3.2.2的要求进行扩展4. 3. 3. 1. 2. 1 应对照系统需求技术规格书（见
