家电软件评估软件标准UL1998解析

家电软件评估软件标准UL1998解析

廖禛

廖禛

珠海格力电器股份有限公司广东珠海519070

摘要：根据UL1998，按照具体章节，结合软件评估的实际开展，详细介绍了软件评估中对软件开发的所有要求。

关键词：软件评估；可编程电子线路；故障/错误；B类软件；C类软件

引言

家电软件评估应用越来越广泛，关于标准方面，相关资料经常提及IEC60730的附录H，实际上对于软件部分的开发来说，附录H的来源UL1998才是软件评估过程中软件部分重要的指导文件。

本文根据相关标准和要求，结合实际的开展过程的理解，详细解析了UL1998。

1.软件评估相关标准和依据

IEC60730-1附录H是依据IEC60335-1附录R修改而成，IEC60730-1和GB14536.1是一一对应的关系。在实际应用中，电子控制器的硬件评估参照IEC60730-1执行，软件参照附录H执行，而IEC60730-1附录H中软件评估内容完全是源自于UL1998。

2.软件评估软件标准解读

UL1998softwareinprogrammablecomponents是针对带与安全相关功能的可编程控制软件评估的标准，也就是说面向的是B类和C类软件，在UL1998中对应的是1类和2类软件，UL1998对软件评估所需的文档和评估条款都有详细介绍。

下面就UL1998进行详细解读：

（1）Chp1Scope&&Chp2DefinitionsofTermsUsed

解析：第一章范围和第二章术语定义顾名思义，不赘述。

（2）Chp3RiskAnalysis

解析：风险分析的对象为与安全相关的可编程控制器，注意包括软件也包括硬件；风险分析要能识别出可能产生的风险或将风险转移；综上，不论是软件还是硬件，与安全相关部分都要进行风险分析，且对风险要有监测和适当的措施处理，风险分析应尽量全面。

（3）Chp4ProcessDefinition

解析：软件开发过程的思路和要求。风险分析后才能开展软件工作，明确输入和输出及中间变量，变量传递时要考虑到安全相关部分的可靠性，比如增加软件滤波；与软件开发相关的内容都需以文档的形式输出，比如会议纪要，分析和测试结果，正式的受控文档等等。

（4）Chp5QualificationofDesign,Implementation,andVerificationTools

解析：软件的整个开发过程中保留有证据的任何文件，设计，实验或者验证中使用的所有工具需要和标准相符的文档证明工具是经过校准和确认的或者有第三方检测合格的证据；需提供开发和测试工具使用版本和已知的故障清单报告，针对这些已知的故障，需提供最新公开版本对之前版本的已知故障已校准和批准的证据或者确定与安全相关的软件处理中没有使用且不会导致危险的证据。

（5）Chp6SoftwareDesign

解析：软件的故障不能引发危险事件，程序需具备自我侦测和处理风险的能力，当侦测到风险时，应导向RA状态（RA状态：无风险的状态，具体形式没有规定，只需确认为安全状态即可）；设计时注意变量需设定初始值，避免、监测和解决死循环，程序跑飞和类似除数为0，溢出等可能影响软件正常运行的错误；分配资源时，应列出详细的计划，评估其危险程度和可利用的资源，及可能出现风险的影响。

（6）Chp7CriticalandSupervisorySectionsofSoftware

解析：软件应初始化为RA状态，软件中的关键监控部分间应尽可能的区分开，做好软件分割，模块相对独立，监测段需避免或者侦测和恢复存储区的使用和地址冲突，在软件的整个运行过程中应实时监测，当监测到异常情况时软件应导向到自动防故障装置或者自动故障强制运行状态。用于监控段的程序要放在ROM里，防止被更改。

（7）Chp8MeasuresToAddressMicroelectronicHardwareFailureModes

解析：微电子故障首先需考虑Chp3风险分析的各种失效，附录A列举了建议考虑的微电子故障和可接受的解决方法的例子。在风险分析失效时也应该考虑多种失效组合的可能性。

以下微电子硬件需考虑各种风险失效：

（8）Chp9ProductInterface

解析：软件应将产品初始化在RA状态。当出现电源中断，软件任何状况的终止工作或者可编程器件的停止工作都应该将产品维持在RA状态。

（9）Chp10UserInterfaces

解析：当涉及安全的内容可以由客户更改，有使用界面的需要考虑此章节内容。软件的限制时间和参数对使用者来说是不可更改的，而应该由有资质的服务人员进行确定，这样可以避免因为执行软件的关键或者监督部分时被改变的情况。在操作有可能导致危险的动作时，软件应采用两段或者更多的响应确认操作。当收到外部源的可能导致危险的输入命令时，没有操作介入时不能够确认执行，而需要有单一的使用者输入才能确认执行。不正确的输入不能影响关键部分软件的执行，软件需提供给用户取消当前操作的权利且可以回到RA状态，取消操作需用户通过单次输入的方式取消。

（10）Chp11SoftwareAnalysisandTesting

解析：软件的设计和代码的分析需证明以下内容，也是测试需验证的内容：a）可编程元件的安全需求的准确和完整；b）包含了可能有风险的每个判断和功能；c）失效后需处于安全状态的失效和失效后仍需运行的失效应该将产品导向RA状态；d）与安全相关的功能需满足风险时间的限制；e）监督和关键部分的软件和非关键部分的软件要区分开，相对独立，不受各种故障的影响。

软件的测试包括开发中的测试和投产前的测试，测试的报告需体现可以实现相关的功能且没有出现风险，测试基于风险分析的结果，测试报告需要体现软件的安全运行和软件的分析和硬件的搭配验证。以上涉及的内容都需体现在测试报告和相应的受控文件中。

测试需证明以下内容：a）可编程器件的相关安全要求的正确性和完整性；b）覆盖可能出现风险的所有功能和内容；c）失效自动保护程序和失效后正常运行程序将产品导向RA状态；d）风险时间的测试，监控段，关键段和非关键段的区分，数据处理的异常，控制异常，计时异常和资源的不正确使用不能影响其他部分e）数据的连续性和界面的流畅性。测试软件控制的硬件电路上的输出部分，和预设的结果进行比对。

除了正常模式的测试外，失效模式和过载模式的测试也是必须的，包括以下内容：a）错误的操作可以反过来影响可编程器件的执行或者控制；b）硬件器件的微电子故障；c）收到外部传感器或者其他的软件进程的错误数据；d）进入和执行监督和关键部分的软件的失效；e）非正常条件的分支和对软件执行有不利影响的进程和过程。

（下转第418页）

测试具体内容应该包括以下部分：a）超出范围；b）检测堆栈边界；c）参数值和类型的不匹配；

失效模式的测试需包括风险分析的结果中可预见性的失效。

（11）Chp12Documentation

解析：此章节将需备案的文档进行汇总介绍。a）使用手册。其内容需包括软件执行需要的数据和输入，输入的步骤和顺序，所有的故障信息及其解决方法等必须告知用户的内容。如软件不涉及使用者操作则无需提供。b）软件设计开发计划。其内容需包括软件从无到有的开发过程都需要描述，软件设计的方法，开发流程，逻辑依据，相关标准，使用到的工程系方法和技术和文档清单。c）风险评估的途径和结果。其内容需列出与产品相关的可预见的所有风险，表明会导致危险的风险事件或者事件的逻辑组合是如何发生的。d）结构管理计划。其内容包括OTS的软件，软件工具和生产商自制软件，具体的计划内容需描述软件和硬件的变更管理流程，包括变更请求，版本备份，版本管控，变更检查，实施操作，软件发布等。e）系统架构。其内容可采用文字&图的形式表现，系统架构包括可编程电子元件（作为处理单元），各种传感器和检测电路（作为输入单元），各种执行器件（作为输出单元）组成的完整的产品系统。f）可编程器件和软件相关的说明书和规格书，包括和安全相关内容的详细功能书。g）和软件设计相关的流程图，时序图等。h）软件测试相关文档。包括测试计划，白盒测试和黑盒测试详细过程和详细信息。

（12）Chp13Off-the-Shelf（OTS）Software

解析：对于直接采用封装好的部分程序需要有特殊要求，例如直接借用现成的库，宏类的软件，这部分程序需要单独评估，提供详细的相关信息用于证明其可靠性，包括名称，版本，版本记录，使用现成库的目的，详细的功能描述，等等。证明文档可参考制造商软件。提供第三方的测试结果或者证书来证明此库可靠，第三方必须是有相关资质的。提供准备用于产品的封装程序版本已知的程序bug清单，且需详细分析证明已知的bug对产品不会造成与安全相关的风险，否则认为不可接受。

（13）Chp14SoftwareChangesandDocumentControl

解析：程序和文档的变更管控流程的相关证明文档，要求受控，有追溯性。

（14）Chp15Identification

解析：软件和硬件都需要有唯一的身份识别和校验，当出现变更时，其身份信息需对应更新，且有相应的文档记录和说明。

3.结语

UL1998对软件评估中对B类和C类软件的要求有了详细的说明，根据应用实例，对软件来说，其重要性不言而喻，可以涵盖软件评估中对软件的所有评估要求，对其理解的深入直接影响到软件评估的开展，在开发的方案阶段就应将其要求分解，并贯穿整个开发过程。本文不当之处，敬请读者指正。

参考文献：

[1]GB14536-2008.1，家用和类似用途电自动控制器[S].