软件功能安全验证活动的应用刘鹏辉,王淑玲(中国电子科技集团公司第三十二研究所,上海201808)摘要:软件功能安全验证活动对提高安全关键系统的安全性具有重要作用,它贯穿于软件安全生命周期的各个阶段㊂通过对各阶段输出文档的审查和分析,可尽早发现软件问题,降低软件修复成本㊂完整的问题闭环处理流程可有效解决软件验证活动中发现的问题,给出各方均满意的处理结果㊂关键词:功能安全;软件验证;问题反馈流程中图分类号:T P316.2文献标识码:AA p p l i c a t i o n o f S o f t w a r e F u n c t i o n a l S a f e t y V e r i f i c a t i o n A c t i v i t i e sL i u P e n g h u i,W a n g S h u l i n g(T h e32n d R e s e a r c h I n s t i t u t e o f C h i n a E l e c t r o n i c s T e c h n o l o g y G r o u p C o r p o r a t i o n,S h a n g h a i201808,C h i n a)A b s t r a c t:S o f t w a r e f u n c t i o n a l s a f e t y v e r i f i c a t i o n a c t i v i t i e s p l a y a n i m p o r t a n t r o l e i n i m p r o v i n g t h e s a f e t y o f s a f e t y-c r i t i c a l s y s t e m s,a n d i t r u n s t h r o u g h a l l s t a g e s o f t h e s o f t w a r e s a f e t y l i f e c y c l e.T h r o u g h t h e r e v i e w a n d a n a l y s i s o f t h e o u t p u t d o c u m e n t s a t e a c h s t a g e,s o f t w a r e p r o b l e m s c a n b e d i s c o v e r e d a s e a r l y a s p o s s i b l e a n d t h e c o s t o f s o f t w a r e r e p a i r c a n b e r e d u c e d.T h e c o m p l e t e p r o b l e m c l o s e d-l o o p p r o c e s s-i n g p r o c e s s c a n e f f e c t i v e l y s o l v e t h e p r o b l e m s f o u n d i n t h e s o f t w a r e v e r i f i c a t i o n a c t i v i t i e s a n d g i v e s a t i s f a c t o r y r e s u l t s t o a l l p a r t i e s. K e y w o r d s:f u n c t i o n a l s a f e t y;s o f t w a r e v e r i f i c a t i o n;p r o b l e m h a n d l i n g p r o c e s s0引言安全关键系统已成为关系国际民生的重要基础设施,一旦发生故障,将严重危害到人民生命和财产安全㊂为此国际电工委员会(I E C)于2000年发布了首个产品安全性标准 I E C61508:1998‘电气/电子/可编程电子安全相关系统的功能安全要求“,最新版本于2010年发布㊂标准制定的目标是保证电气㊁电子或可编程电子安全相关系统的安全可靠,当系统发生故障(包括硬件随机故障和软件故障)或错误时,安全相关系统会采取预先设定的措施,保证故障不会引起人员的伤亡㊁环境的破坏和设备财产的损失[1]㊂E N50128‘铁路应用通信㊁信号和处理系统 用于铁路控制和防护系统的软件“是欧洲电气委员会(C E N E L E C)下属的S C9X A委员会以I E C61508为基础,针对铁路应用安全相关软件制定的标准㊂在E N 50128:2011标准中,根据不同的安全完整性等级,对系统整个软件的软件计划㊁软件需求㊁软件架构设计㊁软件详细设计与开发㊁软件单元测试㊁软件集成测试㊁软件确认等阶段及阶段内的活动提出相应的流程和要求㊂其中,在软件开发生命周期中各个阶段进行验证和确认是非常重要的内容[2]㊂在轨旁安全平台验证和确认过程中的应用[3]描述在轨旁安全平台的开发过程中,其验证和确认流程对提高整个系统的安全性㊁可靠性有着极其重要的意义㊂功能安全的软件验证活动目标是针对安全完整性等级(S I L)要求的程度,测试和评估软件安全生命周期在给定阶段的输出,保证该阶段输出对于相应输入的正确性和一致性[4]㊂相对于传统的软件测试活动,功能安全的软件验证活动范围更广,不仅覆盖软件测试过程,还包括对输出文档的复审和分析㊂本文在对I E C61508和E N50128的研究基础上,结合某嵌入式实时操作系统(已通过I E C 61508的S I L3和E N50128的S I L4的TÜV南德功能安全认证)的软件功能安全验证活动实践,以软件安全生命周期模型为牵引,根据各个阶段输出的文档详细地阐述了软件验证活动在实际项目中开展的过程,并在文末说明软件验证活动中问题的闭环处理流程㊂1软件安全生命周期模型本文涉及的项目实践对象是一款适用于安全关键应用的嵌入式实时操作系统,它的开发以软件安全生命周期模型为基础,如图1所示㊂图中与软件验证活动相关的阶段为项目计划㊁软件需求分析㊁软件架构设计㊁软件详细设计㊁软件编程/实现㊁软件单元测试㊁软件集成测试和软件确认,贯穿于软件安全生命周期的各个阶段㊂图1 某操作系统软件安全生命周期模型2 各个阶段的软件验证活动软件功能安全验证活动是以软件安全生命周期模型为基础,其在各个阶段开展的活动㊂2.1 项目计划阶段为了满足I E C 61508和E N 50128功能安全标准要求,在软件开发的项目计划阶段就进行了一系列的计划编制工作,输出的计划类文档包括软件开发计划(S D P )㊁软件安全计划(S S P )㊁软件验证和确认计划(S V V P )㊁软件质量保证计划(S Q A P )㊁软件配置管理计划(S C M P )㊂软件验证活动主要针对S Q A P 和S S P 两份文档进行开展,输出文档为软件质量保证验证报告(S Q A V R )㊂S S P 文档用于说明项目的管理和技术活动如何满足I E C 61508和E N 50128标准的要求㊂S V V P 文档包括软件确认计划和软件验证计划,其中软件验证计划是用于说明如何对给定阶段的输出通过测试和评价的方式确保相对该阶段输入的正确性和一致性㊂S Q A P 文档描述了为使嵌入式实时操作系统的开发过程受控且符合所有必要的认证要求所采用的过程和方法㊂S Q A V R 是项目计划阶段的软件验证活动总结,它主要说明以下内容的验证结果:软件质量保证体系对标准要求的落实情况;人员的组织结构㊁人员能力和责任权限是否满足要求;对产品复审和过程审核时机安排的合理性;对项目进度安排的有效性和可行性;定义的软件安全生命周期模型的标准符合性;模型内各阶段的准入与退出条件㊁输入输出文档和人员角色描述的清晰性和完整性;计划使用的工具的齐全性以及资质认证是否符合要求;选择的技术措施与功能安全标准中相应S I L 等级所推荐的方法的一致性,同时对未采用的措施进行了合理的解释说明;问题报告和处理流程设计能否有效解决所提出的问题㊂2.2 软件需求分析阶段软件需求分析阶段以项目计划阶段的输出文档为基础,结合系统功能以及脆弱性分析结果,编制软件安全需求规范(S S R S )和软件整体测试规范(O S T S )㊂软件验证活动完成该两份文档的审查和分析,输出文档为软件需求验证报告(S R V R )㊂S S R S 文档详细说明了嵌入式实时操作系统软件的需求㊂O S T S 文档说明了基于软件需求的测试内容㊂S R V R 是软件需求分析阶段的软件验证活动总结,它主要说明以下内容的验证结果:软件安全需求规范的内容与软件安全计划以及软件验证和确认计划内容的一致性;软件需求表述是否完整㊁清晰㊁准确㊁无二义㊁可验证㊁可测试㊁可维护且可行,且能跟踪到所有上级需求;软件接口描述内容是否覆盖所有内㊁外部系统,且考虑接口数据定义的一致性㊁无效或不适时的值㊁最大负载条件下的响应时间和吞吐量㊁最好和最坏情况的执行时间㊁数据存储容量的上溢和下溢等;运行参数是否能防止非授权变更或损坏;是否清晰标识所有软件需求,且能区分安全性需求;软㊁硬件的相关约束是否说明;是否考虑软件自监视以及由软件执行的硬件检查;具有独立性要求的需求是否进行共因失效分析,且对识别的可信失效机制采取了相应的防御措施;软件需求分析阶段的所有问题是否全部解决;I E C615083:2010和E N 50128:2011中要求的技术和措施是否按S I L 等级全部实施,如采用其他替代的技术或措施,是否说明其合理性;所有软件需求是否被基于需求的测试用例覆盖,且能支撑双向跟踪关系的建立㊂2.3 软件架构设计阶段软件架构设计阶段依据软件需求进行软件结构设计,编制软件架构设计规范(S A D S )和软件集成测试规范(S I T S)㊂软件验证活动完成该两份文档的审查和分析,输出文档为软件架构设计验证报告(S A D V R )㊂S A D S 文档描述了嵌入式实时操作系统的架构和设计㊂S I T S 文档描述了软件集成测试内容㊂S A D V R 是软件架构设计阶段的验证活动总结,它主要说明以下内容的验证结果:所有软硬件的相互作用是否识别㊁分析且有详细说明;所有组件是否明确标识,并说明其确认状态和S I L 等级;软件架构描述是否完整㊁一致㊁清晰㊁准确㊁可验证㊁可测试㊁可维护且可行;设计是否考虑错误处理机制;是否建立软件架构设计与软件需求的双向跟踪关系;发现的所有问题是否均已归零或对存在的偏差有合理解释;在软件架构设计期间是否采用计划阶段定义的一组必要的技术或措施,对未使用的技术或措施应获得认可;软件组件间的接口以及软件外部接口是否全部覆盖且被处理;接口描述是否说明前置/后置条件㊁数据边界值及其行为㊁时间关键的输入和输出㊁正确运行的时间限制㊁异常的管理㊁接口缓冲的内存分配以及检测内存分配失败或缓冲区满的机制㊁功能之间存在的并发机制;接口输入输出涉及的所有数据是否均考虑有效等价类和无效等价类;是否建立软件集成测试与软件架构设计的双向跟踪关系㊂2.4 软件详细设计阶段软件详细设计阶段依据软件架构设计完成软件单元的详细设计,编制软件详细设计规范(S D D S )和软件单元测试规范(S U T S )㊂软件验证活动完成该两份文档的审查和分析,输出文档为软件详细设计验证报告(S D D V R )㊂S D D S 文档描述软件单元的详细设计,包含具体算法和数据结构㊂S U T S 文档详细描述了针对每个软件单元的测试内容㊂S D D V R 是软件详细设计阶段的软件验证活动总结,它主要说明以下内容的验证结果:是否覆盖软件架构设计中标识的所有软件单元;软件单元设计的一致性㊁可读性㊁可理解性和可测试性;是否说明与环境或其他单元的接口;软件单元内是否没有进一步分配的S I L 等级;算法描述和数据结构设计的正确性;是否设计相应的错误报告机制;是否建立软件组件与软件单元的双向跟踪关系;是否处理所有发现的问题;是否按规定的技术或措施完成软件单元设计;软件单元测试规范是否定义并说明可接受准则以及S I L 等级要求达到的测试覆盖度;是否建立软件详细设计与软件单元测试的双向跟踪关系;软件单元测试用例设计是否能支撑验证所有软件单元及软件单元间交互功能的实现㊂2.5 软件编码/实现阶段软件编码/实现阶段依据软件详细设计完成软件代码实现㊂软件验证活动完成源代码的审查和分析,输出文档为软件源代码验证报告(S S C V R )㊂S S C V R 是软件编码/实现阶段的软件验证活动总结,它主要说明以下内容的验证结果:源代码的可读性㊁可理解性和可测试性;源代码是否受控;源代码与软件需求及软件架构的一致性;源代码对编码规范的满足程度;源代码实现的正确性和一致性;源代码模块大小及复杂度是否满足要求㊂2.6 软件单元测试阶段软件单元测试阶段完成软件静态分析和软件单元测试用例的执行,编制软件静态分析报告(S S A R )和软件单元测试报告(S U T R )㊂软件验证活动完成该两份文档的审查和分析,输出文档为软件单元测试验证报告(S U T V R )㊂S S A R 文档描述了软件静态测试的测试过程及结果分析㊂S U T R 文档说明了软件单元测试的测试过程和结果分析㊂S U T V R 是软件单元测试阶段的软件验证活动总结,它主要说明以下内容的验证结果:软件单元测试报告是否说明测试责任人㊁测试结果㊁测试目标和准则的满足情况以及不通过情况的记录和分析;测试用例和测试结果是否以机器可读形式记录;测试执行是否可重复;自动化测试脚本是否经过验证;是否说明相关项的标识和配置情况(包括使用的硬件㊁软件㊁设备以及测试规范的版本等);是否说明测试覆盖和测试完成情况的评价以及任何偏离情况;是否陈述单元测试结论及对软件单元设计要求的满足情况;是否建立软件单元与软件详细设计的双向跟踪关系;软件单元测试结果是否经过复审㊂2.7 软件集成测试阶段软件集成测试阶段完成软件单元集成与测试,编制软件集成测试报告(S I T R ),软件验证活动完成软件集成测试报告的审查和分析,输出文档为软件集成测试验证报告(S U T V R )㊂S I T R 文档描述了软件集成测试的过程和结果分析㊂S U T V R 是对软件集成测试阶段的软件验证活动总结,验证内容与软件单元测试阶段相似㊂2.8 软件确认阶段软件确认阶段完成基于需求的用例执行,编制软件整体测试报告(O S T R ),软件验证活动完成软件整体测试报告的审查和分析,输出文档为软件整体测试验证报告(O S T V R )㊂O S T R 文档描述了软件确认阶段的测试过程和结果分析㊂O S T V R 是软件确认阶段的软件验证活动总结,验证内容与软件单元测试阶段相似㊂3 问题处理流程软件验证活动应由独立的软件验证人员按计划实施,如果在验证过程中发现实际结果与期望结果不一致,则应按规定的流程处理,如图2所示,执行步骤说明如下:步骤1(提交问题):由软件验证人员提交问题,并执行步骤2㊂步骤2(问题反馈):问题被反馈给相关责任人㊂由相关责任人和项目经理对问题的影响域进行分析并决定是否接受问题,如果问题接受则执行步骤3;否则反馈给软件验证人员㊂如果软件验证人员认可问题反馈,则关闭该问题,否则继续提交给更高层决策㊂如果更高层认可问题反馈,则关闭该问题,否则执行步骤3㊂步骤3(软件修改计划):由相关责任人员针对发现的问题制定软件修改计划,并提交给项目经理审核㊂如果审核通过,则执行步骤4,否则继续执行本步骤㊂步骤4(完成软件修改):由相关责任人员完成对软件图2 软件验证活动问题处理流程的修改工作,修改完成后执行步骤5㊂步骤5(重新验证):由软件验证人员对修改后的软件进行重新验证,验证结束后则完成问题的处理工作,流程结束㊂4 结 语本文以软件安全生命周期模型为基础,详细说明了某嵌入式实时操作系统在各阶段输出的文档,以及针对文档的审查和分析内容;对在软件验证活动中发现的问题还给出了完整的闭环处理流程,为软件功能安全验证活动的执行提供有效支撑㊂在整体软件测试结束后,还应由软件确认人员执行确认活动,对软件确认活动的总结将作为下一步研究内容㊂参考文献[1]杨春晖,刘奕宏.功能安全标准白皮书,2017.[2]王瑞,徐宁,王财进,等.安全软件验证确认在B TM 开发中的应用[J ].铁路技术创新,2015(2):8890,112.[3]郑琼,刘锦峰,陈晓轩.E N 50128:2011在轨旁安全平台验证和确认过程中的应用,2019,55(11):1114.[4]I E C 61508.F u n c t i o n a l s a f e t y o f e l e c t r i c a l /e l e c t r i c /p r o gr a m -m a b l e e l e c t r o n i c s a f e t y r e l a t e d s ys t e m s [S ].S w i t z e r l a n d :I E C ,2010.刘鹏辉(工程师),主要研究方向为嵌入式领域安全关键技术的测试与验证;王淑玲(工程师),主要从事军用嵌入式软件的第三方测评工作㊂(责任编辑:薛士然 收稿日期:2020-08-14)图8 点击一次 O o ps 命令的效果图备的功能,以及人工操作比较麻烦的功能,用于提高P C B 设计和检查效率㊂由于S k i l l 语言应用具有局限性,国内研究的人比较少,在进行带有F o r m 格式的功能开发时,开发者往往找不到一种合适的框架,并且开发的工具往往不带有完成㊁取消以及回滚功能,而完成㊁取消㊁回滚命令又是P C B 设计者常用的功能,工具如果不包含这几项功能,会导致P C B 设计者在使用该工具误操作时无法快速回滚以及取消操作,给设计者带来不便㊂本文提出的基于F o r m 格式的框架开发,能够在用户误操作D a t a b a s e 时,实现对操作的取消㊁回滚以及完成㊂另外,该框架也能避免因F o r m 嵌入循环语句导致软件进入死循环的现象发生㊂参考文献[1]凡亿p c b .P C B 设计主流软件分析[E B /O L ].[202009].h t -t p ://w w w.f a n y e d a .c o m /p c b x i n w e n /1285.h t m l .[2]十四_S I .P C B L a y o u t 软件分析对比(A D ㊁P a d s ㊁A l l e g r o )[E B /O L ].[202009].h t t p s ://w w w.ji a n s h u .c o m /p /6e 71972452d 9.[3]C a d e n c e .A l l e gr o S k i l l R e f e r e n c e ,2019.[4]C a d e n c e .C a d e n c e S k i l l L a n g u a ge R ef e r e n c e ,2019.[5]v i v i e n l u o .F O RM 创建函数a x l F o r m C r e a t e [E B /O L ].[202009].h t t p ://w w w.a l l e gr o s k i l l .c o m /t h r e a d 17911.h t m l .(责任编辑:薛士然 收稿日期:2020-09-14)。
