摘要：依据软件评估的具体条款，结合软件评估开展实例，系统介绍了软件评估的要求和软件评估的开展过程。
关键词：软件评估；可编程电子线路；故障/错误；B类软件；C类软件
引言
家电中带嵌入式软件的可编程控制器，有些是实现了正常情况下的控制功能，还有些是除了具备正常情况下的控制功能外，同时还具有非标下的保护功能，此类软件的失效如有可能导致火灾，触电或者人员损伤等危险状况，则需要进行软件评估。软件评估旨在通过软件和硬件结构的合理调整和布局，使软件具备发现和处理故障或者错误的能力，从而保证软件的可靠和安全性，保障电器可以安全使用。
本文根据相关标准和要求，结合实际的开展过程，介绍了软件评估的要求和具体的应用，主要针对的是软件方面的相关内容。
1.软件评估的必要性
软件评估可以为家电产品的制造商在保证产品安全的情况下节省成本，从而节约资源，对于家电行业的发展具有积极推动意义，是安全评价和认证不可缺少的部分。
2.软件评估相关标准和依据
IEC60335-1首次引入了软件评估概念，其中附录R是家电软件安全评测的详细要求；2008年欧盟指令要求所有进入欧洲市场的家电产品都需按照IEC60730-1附录H进行软件安全强制性评估；随后，2010年3C家电软件评估依据GB14536-2008.1在中国正式开展。IEC60730-1附录H是依据IEC60335-1附录R修改而成，IEC60730-1和GB14536.1是一一对应的关系。在实际应用中，电子控制器的硬件评估参照IEC60730-1执行，软件参照附录H执行，而IEC60730-1附录H中软件评估内容源自于UL1998 software in programmable components。
3.软件评估的范围和对象
适用于家电产品中使用的可编程电子控制器，这些控制器或其部分功能用于控制或防止家电产品出现危害使用者或环境的危险，如失效，过热，火灾，放射性或毒性危险，其他危险等。
评估对象主要是针对于安全相关的可能导致危险的功能的软件和硬件部分，包括输入输出单元，控制器的软件和硬件结构，软件和硬件接口以及与安全相关软件的功能，逻辑，可编程电子元件等各个方面，是对整个系统的评估。具体的评估对象请见IEC60730-1的附录H。
4.软件评估对象分类
根据IEC60730-1附录H，按照功能软件可分为A类，B类和C类，在控制器内，不同的软件分类可适用于具体的软件区段，也就是说，在同一个控制器中的软件中，会有属于A类的功能也有属于B类或者C类的功能，分类限定的仅仅是一个功能的软件区段。
A类软件是不用于决定受控设备安全的控制功能，也就是与安全无关的功能，只是用来满足基本使用的功能，比如房间控温器，湿度控制器，灯控制器，定时器和定时开关。
B类软件是用来防止被控设备的不安全操作的控制功能，此功能如失效则有可能出现不安全的动作，比如热切断器，洗衣机的门锁。
C类软件是用来预防特定的危害（如被控设备的爆炸）的控制功能，此功能如失效则可能出现危险，严重程序高于B类，如自动燃烧控制器和封闭的水加热器系统的热切断器。
对于A类软件，因为不涉及安全问题，标准无特殊要求，B类和C类软件与安全相关，需依据IEC60730-1附录H进行软件评估，附录H中对软件评估的术语定义和资料及相关控制器硬件和软件的要求有了一定的说明，针对软件评估软件部分的要求及具体的文档准备和开发指导还需参照UL1998。
期刊文章分类查询,尽在期刊图书馆
5.软件评估前的准备
在软件评估实际开展之前，需要软件开发人员和硬件开发人员对于标准的要求有一定的了解，这样有利于软件评估过程的顺利开展。软件评估是一个检测审核的过程，在项目开发中，如何提前应对各种风险故障的发生，这是在开发中最重要的内容，如评估预料不足，则有可能出现需要重新更改方案的情况，这就大大浪费了开发时间，应尽量避免。
首先，应和认证机构进行方案讨论，确定哪些功能是属于需评估范畴，因为整个评估过程都是基于需要评估的部分进行的，认为是无安全风险的功能是不在评估范畴的，也不会进行考察。然后，针对需评估的功能进行类别定位，确定是属于B类还是C类软件，最后根据软件类别，对照标准，找到详细的评估条款。
在硬件方面，需提前进行相关安全功能的电路和系统进行失效模式分析，包括各种输入输出模块异常，各种器件异常等等，如发现会存在安全风险的情况，则需调整硬件方案提供对策。和认证机构讨论评估时需做的实验项目，对各种情况做好提前评估。
在软件方面，以UL1998为指导，在开发中最重要的风险分析，针对提前分析出来的风险，只要有对策将其导向安全的情况，则认为是可以接受的，可以通过增加逻辑或者硬件的方式来处理。
微电子故障在附录H中，对需评估的对象和评估的故障形式及其可接受的措施都有详细的介绍。对照评估微电子的具体故障，参考可接受的措施，确定每种微电子故障的监测方式，具体的实现方式不是固定的，这里特别要注意的是，当监测到故障以后，还需要将产品导向稳定安全的状态。为了实现微电子故障的监测，无法完全通过硬件实现，需要在软件中增加相应的代码进行处理，虽然评估的对象是非安全的功能，但是对于微电子故障来说，评估的是整个程序，而非部分程序。为了实现微电子故障的监测，如无法完全通过软件来实现，也可通过更改硬件方案来进行一定的配合。
软件方案和硬件方案确认可以满足评估要求以后，可以开始文档初版的准备，事实上，文档的清单可以参考UL1998中的要求，根据项目的实际情况来确认需要哪些文档，每份文档也不需要固定的格式，可以体现需要的内容即可。
6.软件评估的开展
软件方面，基本的方案和文档初版准备好后，则可以进行软件评估的开展，认证人员会根据生产商提供的资料对当前方案进行静态分析，根据标准要求进行逐步审查，确认基本方案后，则开展动态测试，测试方式为借助软件开发测试的集成开发环境和工具来检查软件并需要通过向控制器注入故障来验证软件的执行结果。
硬件方面，按照标准要求制定试验验证项目清单，同时输出试验记录，提供给认证人员查看即可。
在整个评估开展中，文档是一个重要部分，里面体现了评估的整个过程的记录，也是评估人员评估的重要指导。文档内容的完整性直接决定了评估的效率。关于文档类型方面的要求，如下：
a.工作原理和安全需求规格说明文档
b.硬件和软件结构说明文档
c.模块设计和编程说明文档
d.相关部件的手册或数据单
e.评估相关的辅助性说明文档
f.制造商软硬件相关测试记录
在文档审核方面，要求应清晰，明确并如实反映系统的原理和结构以及安全相关细节，以便可以进行软件评估相关检查；应保证在系统整个生命周期内都是可追溯的，并且作为评审制造商软件和其开发过程的客观依据；并保证所有文档的唯一性和进行版本控制。
最后，评估人员会将软件评估的主要信息通过评估报告的方式体现出来，一方面对安全相关软件进行受控管理，另外一方面也是对整个评估工作的一个总结。
结语
软件评估可以开展的基础是硬件合格，硬件合格通过结构和部件合格来保证，通过试验来验证，软件合格也要通过结构和程序合格来保证，通过检查和测试来验证。软件质量与过程质量有关，过程质量得到有效控制，最终的软件质量将有保证，软件评估应贯穿整个软件生命周期的各个阶段。
参考文献：
[1]GB14536-2008.1，家用和类似用途电自动控制器[S].
论文作者:廖禛
论文发表刊物:《基层建设》2018年第20期
论文发表时间:2018/9/12
标签：软件论文; 功能论文; 硬件论文; 文档论文; 附录论文; 控制器论文; 故障论文; 《基层建设》2018年第20期论文;