UL1998标准中文版-2018可编程软件UL中文版标准

参考中文标准2018年9月24日可编程组件中的软件-UL19983内容2所用术语的定义63风险分析104流程定义115设计，实施和验证工具的资格116软件设计127软件的关键和监督部分128解决微电子硬件故障模式的措施139产品界面1410用户界面1411软件分析与测试1511.1软件分析1511.2软件测试1511.3失效模式和压力测试1612文档1712.1用户文档1712.2软件计划1712.3风险分析方法和结果1712.4配置管理计划1712.5可编程系统架构1812.6可编程组件和软件需求规范1812.7软件设计文档1812.8分析和测试文档1913现成的(OTS)软件1914软件更改和文档控制2015鉴定20附录A(信息性)-解决微电子硬件故障模式的措施示例A6表A2.1A10的应用示例此页有意留为空白。2018年9月24日可编程组件中的软件-UL19981.1这些要求适用于驻留在执行安全相关功能的可编程组件中的非网络嵌入式软件，该软件的故障可能导致火灾，电击或人身伤害的风险。1.2这是一个参考标准，当其他标准或产品安全要求明确引用该要求时，将应用这些要求。1.3这些要求解决了由可编程组件中的软件控制的产品硬件所特有的风险。1.4这些要求旨在补充适用的产品或组件标准和要求，而不是作为调查火灾，电击或人身伤害风险的唯一1.5这些要求旨在解决软件或用于开发和维护软件的过程中发生的风险，例如：a)需求转换故障，导致可编程组件的规范和软件设计之间的差异；b)设计错误，例如错误的软件算法或接口；c)编码错误，包括语法，不正确的符号，无穷循环和其他编码错误；d)导致程序执行过早或延迟的时序错误；e)微电子内存故障，例如内存故障，内存不足或内存重叠；f)由微电子硬件故障引起的故障：g)潜在故障，用户故障，输入/输出故障，范围故障以及其他仅在给定状态发生时才可检测到的故障。和h)可编程组件根本无法执行任何功能。1.6产品标准要求可以酌情修改或取代本标准中的要求。1.7这些要求并非旨在解决网络安全问题。产品标准或其他参考标准(例如，可联网产品的软件网络安全标准，第1部分)应解决与未经授权的网络访问或攻击相关的风险。一般要求，UL2900-1。6可编程组件中的软件-UL19982013年12月18日2所用术语的定义2.1就本标准而言，以下定义适用。2.2特定于应用的集成电路(ASIC)-一种电子设备，由许多晶体管和其他半导体组件组成，这些组件将标准库和库中的阵列集成到一个特定用途的硅片中。2.3内置测试-一种设计方法，通过添加用于生成测试信号和分析测试结果的逻辑，产品可以进行2.4中央处理单元(CPU)-计算和控制系统的单元，包括控制指令解释及其执行的电路。2.5关键部分-软件的一部分，旨在执行解决或控制风险的功能。2.6数据-以适合存储，交流，解释或处理的方式表示事实，概念或说明。2.7设计-定义软件体系结构，组件，模块，接口，测试方法和数据以满足特定要求的过程。2.8电子可擦除可编程只读存储器(EEPROM)-一种可重新编程的只读存储器，其中的单元可以被电擦除，并且每个单元都可以被电重新编程。2.9嵌入式软件-物理上属于产品的软件，其主要目的是维护产品其他组件之间的某些属性或关系，以实现总体系统目标。2.10可擦除可编程只读存储器(EPROM)-一种可编程存储器，只能在正常使用下读取，不能更改。该存储器能够被紫外线擦除并重新编程。2.11错误-计算，观察或测量的值或条件与真实，指定或理论上正确的值或条件之间的差异。2.12FAIL-OPERATIONALPROCEDURE-在发生故障的情况下执行的过程，该过程可以继续产品操作，但会降低性能或降低功能。2.13失败安全程序-一种在过渡到非操作模式时维持产品的“已解决风险”状态的程序。2.14失败-产品或组件无法执行其指定功能。2.15故障模式-故障的物理或功能表现。2.16故障模式测试-根据可编程组件或产品中存在的故障模式专门开发的一套测试。节的增量。2.20危险-潜在的人身伤害来源。2.22完整性-系统或组件防止未经2.23微控制器-一种能够执行指令的微计算机芯片。2.30现货(OTS)软件-在市场上出售并打算广泛分发的软件，通常不需要其他定制，包括但不限于操作系统软件，运行时库，实时执行人员，内核原语，可共享的可重入库类型例程等。这包括由另一位开发2.31操作测试-使用代表其操作环境的输入配置文件对产品或组件进行评估。2.32参数设置-分配给变量的有限值集合，以选择，启用或禁用软件的已知预先存在的功能。2.33分区-将系统功能分离为可验证的独特且受保护的功能集合的行为。2.34发行后测试-所有发布的最终软件发布后进行的更改测试。2.35程序-执行任务所采取的行动过程。2.36过程-为产生给定结果而执行的一系列步骤。2.37产品-供个人，家庭，工业，实验室，办公室或运输使用的仪器，设备，工具或机器。2.38产品硬件-产品的一部分并且提供电气，机械和(或)机电功能的任何硬件。2.39可编程组件-可在设计中心，工厂或现场进行编程的任何微电子硬件。这里，术语“可编程的”被认为是可以改变软件的任何方式，其中可以改变组件的行为。2.40可编程组件配置-必须存在的微电子硬件和软件的配置，并且该软件可以正常运行以按预期操作和控制设备。该配置包括但不限于操作系统或执行软件，通信软件，微控制器，网络，输入/输出硬件，任何通用软件库，数据库管理和用户界面软件。2.41可编程只读存储器(PROM)-一种存储芯片，其内容可以由用户或制造商针对特定目的进2.42随机访问存储器(RAM)-数据存储，其中数据访问所需的时间与最近获取或放置在存储中的数据位置无关。2.43只读存储器(ROM)-数据存储，用于存储计算机指令无法更改的数据。2.44风险-与产品安全要求所指定的产品预期用途相关的火灾，电击或人身伤害的潜在危险。2.45潜在风险(RA)州-一种特征，即与要解决的产品的预期用途相关的所有合理可预见的风险，从风险的可能性。2013年12月18日可编程组件中的软件-UL199892.46安全相关功能-控制，保护和监视功能，旨在减少火灾，电击或人身伤害的风险。2.47软件-与可编程组件的操作有关的计算机程序，过程和数据，可提供以下与安全相关的功能：a)对微电子或产品硬件的状态进行直接控制。如果不执行，乱序执行或执行不正确，则此类程序，过程和数据可能会导致风险。b)监视微电子或产品硬件的状态。当不执行，乱序执行或执行不正确时，此类程序，过程和数据将提供可能导致风险的数据。c)对微电子或产品硬件的状态进行直接控制。如果不执行，不按顺序执行或执行不正确，则此类程序，过程和数据可能会与其他人为操作，产品硬件或环境故障结合在一起，从而导致风险。2.48软件代码-以编程语言或汇编器，编译器或其他翻译器输出的形式表示的计算机指令和数据定义。2.49软件设计-定义软件体系结构，组件，模块，接口，测试方法和数据的过程，以实现特定要求的软件实现。2.50状态-在给定的时间点通过一组变量定义的值，这些变量定义了产品或其组件的某些特定特征。2.51应力测试-为评估产品或组件达到或超出其指定要求的限制而进行的测试。2.52管理部分-控制软件的关键和非关键部分(例如，微处理器的操作系统)的执行的软件的主要部分。2.53测试配置-用于测试的测试和测量设备的详细标识和布局。测试配置通常直接记录在测试计划或测试过程中，并指定所有特殊的测试装置，辅助软件，软件工具和数据文件，以及对测试设置和任何准备活动的描述。2.54测试标准-产品或组件必须满足的目标才能符合给定的测试。2.55测试参数-用于更改和定义测试的变量。2.56测试计划-描述预期测试活动的范围，方法，资源和时间表的文件。它定义了测试项目，要测试的功能，测试任务，将执行每个任务的人员以及需要应急计划的任何风险。2.57测试程序-针对给定测试用例的结果的设置，执行和评估的详细说明。2.58工具-任何设备(例如逻辑分析仪，示波器，万用表，数字和模拟计算机),设备或软件程序(例如模拟器，计算机辅助软件/系统工程(CASE)工具，编译器，类型检查器，静态分析器，自动化测试脚本，调试器，链接器，加载器，汇编器，代码生成器，代码库管理员，编辑器和软件分析器],用于自动化或部分自动化软件开发活动，包括设计，实现和测试。2.59工具鉴定-接受分析，测试和所得证据，以证明他们对工具输出的正确性具有信心。2.60工具供应商-负责提供工具的组织。2.61UNIQUEIDENTIFIER(唯一标识符)-一个值，用于区别制造商的软件关键和监管部分的每个单独的版本或修订版。2.62USER-合格的服务人员或可编程组件的操作员。2.63验证-对集成计算机系统(硬件和软件)及其规格的测试和评估，以确定其是否实现了预期2.64验证-确定给定开发阶段的产品是否正确并与该阶段输入的产品和标准相一致的过程。3风险分析3.1应进行风险分析以确定：a)风险集合；和b)该软件解决了已识别的风险。3.2风险分析应基于可编程组件的安全要求。3.3必须进行分析以识别软件的关键，非关键和管理部分。3.4应当进行分析以识别可能导致风险的状态或过渡。2018年9月24日可编程组件中的软件-UL19984工艺定义4.1应描述所有软件过程活动(请参见第12节，文档)。4.2应使用不同的入口点，出口点和活动之间的转换标准来标识软件过程活动。4.3根据第3节“风险分析”的要求，软件过程应包括风险分析。风险分析应可追溯到《可编程组件和软件需求规范》(参见12.6)。4.4活动之间转换的标准应包括对可编程组件安全相关要求的考虑。4.5工作产品(例如会议记录，分析和测试结果，正式文档等)应予以标识并与软件过程活动相关联。4.6所有软件过程活动均应支持可能影响可编程组件安全相关功能的问题的沟通。4.7可编程组件的安全相关要求应可在整个软件过程活动中追溯，并应提供书面证据证明符合该标准。4.8软件过程中的验证，确认和测试活动应从源头上解决错误。5设计，实施和验证工具的资格5.1应使用以下至少一种形式，为在可编程组件中设计，实施和验证软件中使用的所有工具提供工具资格a)根据本标准11.1.1、11.2.1、11.2.4、12.1、12.2、12.4、12.8和第14和15节证明工具校准，验证和确认活动的文档。b)该工具已达到第三方工具认证程序正式定义的要求的证据。5.2当可从工具供应商或其他来源(例如，用户社区)获得时，制造商应提供制造商打算用于开发软件的工具的精确修订/版本的已知错误列表。对于工具已知错误报告中的每个已识别错误，在实施5.1(a)时应提供以下证据。a)导致错误的功能已由工具供应商在新版本中进行了修复，测试和批准，以供分发，该新版本已合并到工具制造商的版本中，或者b)导致错误的功能尚未被制造商用于与安全相关的软件的开发中，并且不会导致风6软件设计为初始值，则该工具的资格应包括对此的验证(请参阅第5节)。7软件的关键和监督部分2018年9月24日可编程组件中的软件-UL1998137.7当安全相关功能的启动可能导致危险时，除非产品安全要求中另有规定，否则至少应使用两个指令序列来验证安全相关功能的启动。7.8应有规定来控制专用于关键和监督部分功能的指令和数据的可访问性。7.9应有条文保护软件的关键和监督部分的指令和数据不受任何功能(关键和监督部分功能除外)的影响。7.10软件的监督和关键部分应驻留在非易失性存储器中。如果在操作过程中将软件的管理和关键部分转移到易失性存储器中，则应在第3节“风险分析”中考虑与从易失性存储器中转移和执行软件有关的风险。7.11必须采用手段来保持软件关键和监控部分所使用数据的完整性。7.12用于软件关键和监控部分的固定或一次性更改数据应驻留在非易失性存储器中。如果在操作过程中将用于软件关键部分和管理部分的固定或一次性更改数据转移到易失性存储器中，则应在第3节“风险分析”中考虑与从易失性存储器中转移和访问此数据相关的风险。8解决微电子硬件故障模式的措施8.1必须采取措施解决由第3节“风险分析”确定的所有微电子硬件故障模式。附录A包含微电子硬件可接受措施的示例。8.2应考虑以下微电子硬件的物理故障：a)CPU寄存器，指令解码和执行，程序计数器，寻址和数据路径；b)中断处理和执行；d)非易失性和易失性存储器以及存储器寻址；e)内部数据路径和数据寻址；f)外部通讯和数据，寻址和时序；g)输入/输出设备，例如模拟I/O,D/A和A/D转换器以及模拟多路复用器；h)监控装置和比较器；和i)专用集成电路(ASIC),门阵列逻辑(GAL),可编程逻辑阵列(PLA)和可编程门阵列(PGA)硬件。8.3微电子硬件故障，软件故障和其他可能导致危险的事件的可能组合应进行分析。例如，这包括微电子硬件故障，这些故障会导致软件故障，从而导致风险。8.4当可从可编程组件供应商或其他来源(例如用户社区)获得时，制造商应为制造商打算使用的可编程组件的精确修订/版本提供勘误表。对于勘误中的每个已识别错误，应提供以下证据：a)该错误已由可编程组件供应商以新版本修复，测试并批准分发，该新版本已合并到制造商版本的可编程组件中，或者b)制造商尚未在安全相关软件的开发中使用受错误影响的功能。9产品介面9.1对于任何持续时间的电源中断，软件均应保持记录在案的RA状态。9.2当初始化被分配为软件功能时，软件应将产品初始化为记录的RA状态。9.3在软件终止的任何情况下，产品均应保持记录在案的RA状态。9.4旨在中止可编程组件的过程或指令应保持产品的RA状态。10使用者介面10.1除非产品安全要求中另有规定，否则本节中的要求仅适用于接受用户输入的软件。10.2用户不得更改软件的时间限制和其他参数，以免对软件的关键部分和管理部分的预期执行产生不利影10.3应防止打算由合格的服务人员配置的软件的时间限制和其他参数，以免对软件的关键或监控部分的预期操作造成不良影响。10.4该软件应要求两个或多个用户响应才能启动可能导致风险的操作。10.5当从外部源接收到输入命令时，这些输入命令在执行时会导致危险，在没有操作员干预的情况下，不10.6对于10.5中所述的系统，任何可能导致风险的操作都不应由单个用户输入启动。10.7输入错误将不会对软件关键部分的执行产生不利影响。10.8如果产品安全要求要求这样做，并且由风险分析确定时，则软件应提供用户取消当前操作的功能，并使可编程组件返回RA状态。10.9用户取消当前操作应要求用户输入一次。10.10取消处理将使软件处于RA状态。此页面上没有文字11.1.1应进行软件设计和代码分析，以评估软件的关键部分和监督部分仅执行其打算执行的功能，并且不11.1.2进行软件设计和代码分析以证明：a)关于可编程组件安全要求的正确性和完整性；b)处理和纠正与异常操作相关的风险或涉及与其正常操作相关的风险的每个分支条件和功能c)故障安全和故障操作过程使产品进入RA状态。参见6.3、6.4和7.6;d)满足调度要求，并且安全相关功能满足可编程组件安全要求所规定的时序约束。见6.5;e)软件的管理，关键和非关键部分之间的分区的完整性。见7.2;f)不会发生由数据处理错误，控制错误，时序错误和资源滥用等事件引起的分区违规；和g)跨接口的数据和控制流的一致性。11.2软件测试11.2.1软件测试应包括开发和发布后测试。11.2.2应进行软件测试并记录测试结果，以评估该软件仅执行其预期的功能，不会造成任何风险。11.2.3应基于风险分析，软件操作和安全功能的书面说明(参见12.7.2)以及软件分析来开发测试用例。参见11.1。11.2.4应进行测试以证明：a)关于可编程组件安全要求的正确性和完整性；b)能够涉及风险的每个决策和功能的覆盖范围；c)故障安全和故障操作过程使产品进入RA状态。参见6.3、6.4和7.6;d)确保满足计划要求，并且与安全相关的功能满足可编程组件安全要求所规定的时序约束。e)软件的管理，关键和非关键部分之间的分区的完整性。见7.2;f)不会发生由数据处理错误，控制错误，时序错误和资源滥用等事件引起的分区违规：和g)跨接口的数据和控制流的一致性。11.2.5应测试软件为控制产品硬件而生成的输出，以根据预期的输出确定其对产品硬件的影响。11.3失效模式和压力测试11.3.1除了在正常使用下进行测试外，还应进行失效模式测试和压力测试。11.3.2失效模式和压力测试应考虑以下因素：a)能够严重影响可编程组件的预期操作或控制的操作员错误；b)微电子硬件组件故障；c)从外部传感器或其他软件过程接收到的数据中的错误：d)与软件的关键和监督部分的进入和执行有关的故障；e)与能够降低风险的决策和功能相关的故障，错误和其他异常情况，包括负面条件分支；和f)能够对软件的预期操作产生不利影响的其他过程和过程。11.3.3根据11.1.2(b)确定的测试用例应包括以下内容：a)超出范围；c)键入用于决策的参数的不匹配值。11.3.4失效模式测试应解决“风险分析”第3节中确定的所有可预见的故障。12文献资料12.1用户文件12.1.1除没有直接用户交互作用的嵌入式软件外，应准备用户文档(例如，手册，指南或其他文档)。12.1.2用户文档应描述所需的数据和控制输入，输入序列，选项，程序限制以及软件预期执行所需的其他12.1.3所有错误消息均应得到识别，纠正措施在用户文档中进行描述。12.2软件计划12.2.1应记录软件计划，该计划描述软件开发活动。12.2.2软件计划应包括对软件设计方法，开发原理，要收集的任何度量标准，适用的标准和采用的工程方法/技术的描述，以及在整个软件过程中产生的所有文档的逐项列出。12.3风险分析方法和结果12.3.1风险分析方法和结果(见第3节)应形成文件。12.3.2风险分析应说明事件或事件的逻辑组合如何导致已识别的危害。12.3.3风险分析应列出与产品相关的所有已识别风险。12.4配置管理计划12.4.1应记录适用于现成软件，软件工具和制造商提供的软件的配置管理计划。12.4.2配置管理计划应描述：a)如何管理软件和硬件的更改；b)差异报告和变更请求的发起，传输，审查，处置，实施和跟踪；和c)正式控制本节中确定的软件和所有文档的接收，存储和备份，处理和发布的方法和活动。12.5可编程系统架构12.5.1可编程系统架构应形成文件。12.5.2可编程系统架构应描述可编程组件，包括与用户，传感器，致动器，显示器，微电子硬件架构，顶级软件架构，软件到硬件的映射以及可编程系统框图，其中包括产品架构的高层视图。12.5.3可编程系统架构应描述软件到软件的接口和硬件到软件的接口。12.5.4应当确定与软件一起使用的可编程组件的配置。参见2.39。12.6可编程组件和软件需求规范12.6.1可编程组件和软件要求规范应形成文件。12.6.2可编程组件和软件要求规范应描述可编程系统和软件的功能，性能和接口要求。12.6.3规范应包括所有操作模式的描述，故障行为的识别和所需的响应。12.6.4可编程系统和软件要求规范应可追溯至12.3中记录的风险分析结果。12.7软件设计文件12.7.2软件设计文件应包括与预期功能有关的软件操作和安全功能的描述。12.7.3软件设计文件应包括输入和输出，功能，数据描述和关系，控制和数据流，故障处理和算法。12.7.4软件设计文档应描述软件设计如何满足系统和软件要求规范的详细信息。12.8分析和测试文档12.8.1所有分析和测试方法及结果均应形成文件。12.8.2测试计划应形成文件，涵盖可编程组件中使用的所有软件，包括现成的和第三方提供的软件(请参阅现成的软件，第13节)。12.8.3测试计划应包括或参考已记录的测试程序，这些程序用于验证可编程组件中软件的正确实施。12.8.4测试程序应包括对测试参数，测试标准，测试配置的描述，以及与测试用例的设置，执行和解释有关的任何特殊规定或假设(参见11.2.3、11.2.4和11.3)。2)。12.8.5测试用例应形成文件，并可追溯到软件实施。12.8.6测试结果应形成文件，并可追溯到产生它们的测试用例。13现成的(OTS)软件13.1对于与制造商提供的软件连接的所有OTS软件，应在软件计划中提供以下信息，请参阅12.2:c)对软件使用目的的描述；d)对软件提供的功能的清晰描述；e)显示所有控制和数据流进出OTS软件的接口规范；和f)与制造商软件连接的每个可调用例程的OTS软件文档参考。13.2对于OTS软件，至少应提供以下形式的证据之一：a)在解决涉及OTS软件的风险的范围内证明OTS软件的验证和测试活动的文档。b)OTS软件已通过独立的OTS软件认证程序满足正式定义的要求的证据。13.3当可从OTS软件开发人员或其他来源(例如，用户社区)获得时，制造商应提供制造商打算在嵌入式软件中使用的OTS软件的精确修订/版本的已知错误列表。对于OTS软件已知错误报告中的每个已识别错误，在实施13.2(a)时应提供以下证据：a)OTS软件开发人员已修复，测试并批准了导致错误的功能，并已分发给该软件的制造商版本中的新版本；要么b)导致错误的功能尚未被制造商用于与安全相关的软件的开发中，并且不会导致风13.4对于执行监督部分功能或被该监督部分使用的OTS软件，其6.5、11.1.2(d),11.1.2(e),11.1.2(f)和第7节中包含的要求本标准适用。14软件更改和文档控制14.1对参数设置和数据的更改，除非减少或消除，否则不会造成任何风险或影响先前已确定的风险。14.2除了减少或消除软件风险外，对软件的更改或补丁不得造成任何风险或影响先前已确定的风险。14.3为了确定符合性，所有变更均应根据该标准进行评估。14.4应检查文档，以确定其正确反映了软件中与安全相关的更改。14.5应有程序来维护和控制对可编程组件的配置以及软件的关键和管理部分进行的软件更改，以促进可追15身份证明15.1软件应可追溯到存储在非易失性存储器中的唯一标识符。15.2唯一标识符应反映对软件的关键和管理部分所做的更改。15.3每次将变更或补丁纳入软件的关键或监管部分时，均应分配一个新的唯一标识符。15.4文档应包括足够的信息，以识别使用该软件调查的每个项目。例如，软件元素的标识应包括版本号，发行号和日期。微电子硬件元素应包括组件供应商，零件编号和修订级别，以唯一标识可编程组件芯片。附录A(信息性)-解决微电子硬件故障模式的措施示例A1.1当产品标准，指令或法规对此进行说明时，应将附录A视为规范性文件。否则，附录A被视为提供信息。A1.2本附录的表A2.1提供了微电子硬件故障模式可接受的措施的示例，这些措施符合自动电气控制，第1部A1.3本附录提供了软件类定义和要求的示例。这些示例并未说明在应用UL1998要求的情况下可能开发的所有软件类别定义。当参考UL1998时，将基于与应用软件相关的风险识别方法来进一步确定软件类别，以执行产品中与安全相关的功能。A1.4本附录中还包括故障模型的描述，系统结构以及表A2.1的示例应用程序。A2微电子硬件故障模式可接受措施的示例A2.1下表提供了一些可接受的措施示例，这些措施涵盖了所选组件的各种故障模式。A2.2如果可以显示表A2.1中指定的故障/错误情况，则可以采用表A2.1中未指定的其他措施。微电子硬件故障模式的范围可接受措施的示例c.d.121.中央处理器q功能测试；要么定期使用以下任一方法进行自我测试：一其有一位冗余的字保护q比较冗余CPU的方式之一：-独立的硬件比较器：要么内部错误检测：要么比较的冗余内存；要么-透明加尔帕特试验：要么表A2.1下页续表A2.1续表可接受措施的示例c,d.12具有多位冗余的字保护：要么具有一位冗余的静态存储器测试和字保护行行q比较冗余CPU的方式之一：-独立的硬件比较器：要么内部错误检测；要么使用等效类测试的定期自测q功能测试；要么定期自检；要么独立的时隙监控：要么q定期自检和监视，使用以下任一方法：-内部错误检测：要么比较冗余功能通道：q比较冗余CPU的方式之一：-独立的硬件比较器：要么内部错误检测：要么使用地址线的测试模式进行定期自检：要么完整的总线冗余：要么多位总线奇偶校验，包括地址q比较冗余CPU的方式之一：-独立的硬件比较器：要么内部错误检测；要么使用测试模式进行定期自我测试：要么数据冗余：要么2018年9月24日可编程组件中的软件-UL1998A2表A2.1续表可接受措施的示例c.d.e12A2可编程组件中的软件-UL19982018年9月24日此页面上没有文字可接受措施的示例c.d.e12中断处理与执行没有中断或中断太频繁q功能测试；要么时隙监控繁的中断以及与不同来源相关的中断q比较冗余功能通道：-独立的硬件比较器：要么时钟q频率监控：要么时隙监控q频率监控：要么时隙监控：要么比较冗余功能通道：障q定期修改校验和：要么多重校验和要么具有一位冗余的字保护q比较任一冗余CPU:-独立的硬件比较器；要么比较的冗余内存：要么周期循环冗余检查，可以是：-双字要么具有多位冗余的字保护易失性记忆q定期的静态内存测试：要么可接受措施的示例c.d.e12具有一位冗余的字保护q比较冗余CPU的方式之一：一独立的硬件比较器：要么比较的冗余内存：要么一透明加尔帕特测试要么具有多位冗余的字保护储器有关)qq比较冗余CPU的方式之一；-独立的硬件比较器；要么测试模式要么周期循环冗余检查，可以是：-双字要么具有多位冗余(包括地址)的字保护内部数据路径q具有一位冗余的字保护q比较冗余CPU的方式之一：-独立的硬件比较器：要么具有多位冗余(包括地址)的字保护：要么数据冗余：要么12q具有单位冗余(包括地址)的字保护q比较冗余CPU:-独立的硬件比较器：要么具有多位冗余的字保护，包括地址：要么全总线冗余；要么q具有多位冗余的字保护：要么CRC-单字：要么传输冗余：要么qCRC-双字：要么数据冗余；要么比较冗余功能通道：q具有多位冗余的字保护，包括地址：要么CRC-单个字，包括地址；要么传输冗余：要么qCRC-双字，包括地址：要么数据和地址的完整总线冗余；要么比较冗余通信通道的方法之一：可接受措施的示例c.d.e12错误的时间点q时隙监控：要么q时隙和逻辑监控：要么比较冗余通信通道的方法之一：q逻辑监控；要么时隙监控：要么q时隙和逻辑监控；要么比较冗余通信通道的方法之一：围品标准中规定的qq比较冗余CPU的方式之一：-独立的硬件比较器；要么输入比较：要么多个并行输出：要么输出验证；要么测试模式要么A/D和D/A-品标准中规定的q表A2.1下页续可接受措施的示例c.d.e12q比较冗余CPU的方式之一：-独立的硬件比较器：要么输入比较：要么多个并行输出：要么输出验证：要么qq比较冗余CPU的方式之一：-独立的硬件比较器：要么输入比较：要么输出q经过测试的监控：要么多余的监视和比较：要么件1-8r例如ASIC,GAL,门阵列输出9定期自测q定期自检和监控：要么双通道(多样化)并进行比较);要么a对于故障/错误评估，某些组件分为其子功能。b软件类别确定是产品安全考虑。c对于表中的每个子功能，“软件2类”度量将涵盖“软件1类”的故障/错误。d公认一些可接受措施的例子提供了比本标准所要求的更大的覆盖范围。e如果为子功能提供了多个度量，则可以选择这些度由制造商根据需要分为子功能。A3软件类别A3.1软件1级-旨在控制功能以减少与设备相关的风险的可能性的软件部分。可以视为软件1类功能的A3.2软件2级-用于控制功能以减少与设备相关的特殊风险(例如爆炸)的可能性的软件部分。可以视为软b)双通道(同质),比较，A5.3;要么c)双通道(多样化),带比较，A5.2。A3.7使用双通道结构并进行比较的声明为软件等级2的软件部分，应具有附加的故障/错误检测手段(例如格式存储(见A7.1.22)。A3.11在故障/错误导致危险之前，应检测到故障/错误。A4故障模型说明A4.1直流故障模型-直流故障模型表示卡死的故障模型，其中包含信号线之间的短路。A4.2堵转故障模型-堵转故障模型表示代表断路或信号电平不变的故障模型。A5系统结构说明A5.1双通道-双通道表示一种结构，其中包含两个相互独立的功能部件来执行指定的操作。A5.2具有比较功能的双通道(分立)-具有比较功能的双通道(分立)表示包含两个不同且相互独立的功能部件的双通道结构，每个功能部件均能够提供明确的响应，其中比较输出信号是否有故障/错误识别。A5.3具有比较功能的双通道(均质)-具有比较功能的双通道(均质)表示包含两个相同且相互独立的功能部件的双通道结构，每种功能部件均能够提供明确的响应，其中内部信号或输出信号的比较为用于故障/错误识别。A5.4单通道-单通道表示一种结构，其中使用单个功能性手段执行指定的操作。A5.5具有功能测试的单通道-具有功能测试的单通道表示单通道结构，其中在操作之前将测试数据引入功能单元。A5.6具有定期自我测试的单通道-具有定期自我测试的单通道表示一种单通道结构，其中在操作过程中定期测试控件的组件。A5.7带有定期自我测试和监控的单通道-具有定期自检和监视表示具有周期性自检的单个通道结构，其中独立的装置(每个装置均能够提供所需的响应)监视诸如安全相关的时序，序列和软件操作之类的方面。A6表A2.1的应用举例A6.1表A6.1包含使用单片机(8位)软件Class2(具有自检和监视功能的单通道)来控制产品中的故障/错误的措施这些说明分为以下几类：易失性存储器的寻址1/O组件的寻址1/O测试涵盖的1/O地址线，请参阅7.1(此表)易失性存储器的数据路径1/O组件的数据路径测试易失性存储器，请参阅4.2(此表)1/O测试涵盖的内容，请参见7.1(此表)2中断处理与执行3时钟CRC-单个字(8位)易失性记忆外部通讯，数据和CRCv-包含数据的双字(16位),数字量输出输入比较(极性相反)89PAL(可编程逻辑阵列)2013年12月18日可编程组件中的软件-UL1998A11A7提供表A2.1中指定的所需故障/错误覆盖率的可接受措施的说明A7.1故障/错误控制技术的描述A7.1.1完整总线冗余-完整总线冗余表示一种故障/错误控制技术，其中通过冗余总线结构提供完整的冗余A7.1.2多位总线奇偶校验-多位总线奇偶校验表示一种故障/错误控制技术，其中总线扩展了两个或更多位，并且这些附加位用于错误检测。A7.1.3代码安全性-代码安全性是指故障/错误控制技术，其中通过使用数据冗余和/或传输冗余来提供针对输入和输出信息中的巧合和/或系统性错误的保护。(另请参阅A7.1.4和A7.1.5)。A7.1.4数据冗余-数据冗余表示一种代码安全形式，其中发生了冗余数据的存储。A7.1.5传输冗余-传输冗余表示一种代码安全性，其中至少连续两次传输数据，然后进行比较。A7.1.6比较器-比较器表示用于双通道结构中的故障/错误控制的设备。该设备比较两个通道的数据，如果检测到差异，则启动声明的响应。A7.1.7等效类测试-等效类测试表示旨在确定指令解码和执行是否正确执行的系统测试。测试数据来自CPU指令规范。A7.1.8错误识别装置-错误识别装置表示为识别系统内部错误而提供的独立装置。A7.1.9输入比较-输入比较表示一种故障/错误控制技术，通过该技术可以比较设计在指定公差范围内的输A7.1.10内部错误检测或纠正-内部错误检测或纠正是一种错误/错误控制技术，其中并入了附加电路来检测或纠正错误。A7.1.11频率监控-频率监控是一种故障/错误控制技术，其中将时钟频率与独立的固定频率进行比较。A7.1.12程序顺序的逻辑监视-程序顺序的逻辑监视是一种故障/错误控制技术，其中监视程序顺序的逻辑执A12可编程组件中的软件-UL19982013年12月18日A7.1.13程序序列的时隙监视-程序序列的时隙监视是一种故障/错误控制技术，其中定期触发具有独立时基的计时设备以监视程序功能和序列。A7.1.14时隙和逻辑监视-这是A7.1.12和A7.1.13的组合。A7.1.15多个并行输出-多个并行输出表示一种故障/错误控制技术，其中提供独立的输出以进行操作错误检测或独立的比较器。A7.1.16输出验证-输出验证表示一种故障/错误控制技术，其中将输出与独立输入进行比较。A7.1.17合理性检查-合理性检查表示一种故障/错误控制技术，其中检查程序执行，输入或输出的程序顺序，时序或数据是否不正确。A7.1.18协议测试-协议测试是一种故障/错误控制技术，其中，数据往返于计算机组件之间进行传输，以检测内部通信协议中的错误。A7.1.19相互比较-相互比较表示在双通道(同质)结构中使用的故障/错误控制技术，其中对在两个处理单元之间相互交换的数据进行比较。A7.1.20冗余监视-冗余监视表示可以使用两个或多个独立的工具(例