一种用于安全苛求系统软件升级的校验方法与流程

文档序号:17989024发布日期:2019-06-22 00:37阅读:177来源:国知局
一种用于安全苛求系统软件升级的校验方法与流程
本发明涉及软件领域,尤其涉及一种用于轨道交通的安全苛求系统软件升级的校验方法。
背景技术
:安全相关的安全苛求系统对于系统故障,尤其是安全相关的故障是零容忍的要求。安全苛求系统最重要的使命就是消灭系统故障。系统故障来源可以是由硬件随机性失效带来的随机性失效和系统设计或系统实现错误带来的系统性失效。对于系统性失效,目前主流方法是通过系统工程及数学模型的方法来控制。系统性失效很难根除,主要有两个方面的原因:1)系统模型与现实世界存在差异。建立模型过程,是对现实世界在特定视角下的简化。2)在系统模型实现成最终产品过程中,工程师在理解沟通及实现产品过程中的人为错误被带入最终产品中。对于第2点,系统工程及软件自动生成代码及数学验证等技术已经可以很好的控制,但对于第一点,必须通过大量的现实系统测试来保障。但是,对于未投运的系统可以通过大量现场调试来获得排查故障的时间资源,但对于已经投运的系统,现场调试时间是一个很宝贵的有限资源。比如地铁系统是城市的交通命脉,通常地铁收班在凌晨之后,但首列车出车在5点左右。为了调试新软件,需要对系统进行倒接,也就是新软件安装,以及调试后还原到旧系统并进行验证测试确保第二天正常运营。如果再扣除调试的安全管理,测试准备等环节,所剩调试时间非常有限。但安全苛求系统调试测试必须充分。技术实现要素:本发明的目的在于提供一种用于安全苛求系统软件升级的校验方法,解决运营系统现场调试有限时间与系统软件升级现场调试时间需求的矛盾。实现上述目的的技术方案是:一种用于安全苛求系统软件升级的校验方法,包括:在x乘n取m系统的冗余单元中,从硬件层面拓展至少一个新增计算单元;其中,x为正整数,n、m均大于等于2,且为整数;在冗余单元中的n个既有计算单元加载既有软件,在新增计算单元加载待升级软件;各既有计算单元和新增计算单元每个运算周期均基于本周期相同输入进行计算;根据各既有计算单元的运算结果决定实际输出,并将各既有计算单元的运算结果或由各运算结果产生的既有投票结果告知新增计算单元;将新增计算单元的运算结果与各既有计算单元的的运算结果或由各运算结果产生的既有投票结果进行比较,并根据比较结果记录比较日志为行为一致或行为不一致;离线识别既有软件针对待升级软件的变更而产生的预期行为变化;根据预期行为变化和比较日志,判断新增计算单元的行为是否符合预期。优选的,所述的预期行为变化包括:预期行为一致和预期行为不一致;所述的判断新增计算单元的行为是否符合预期,包括:比较日志记录为行为一致,并且预期行为一致,则判定新增计算单元的行为符合预期;比较日志记录为行为一致,并且预期行为不一致,则判定新增计算单元的行为不符合预期;比较日志记录为行为不一致,并且预期行为一致,则判定新增计算单元的行为不符合预期;比较日志记录为行为不一致,并且预期行为不一致,检查比较日志记录的行为不一致与预期行为不一致的方式是否相同,若是,则判定新增计算单元的行为符合预期;否则,判定新增计算单元的行为不符合预期。优选的,各既有计算单元决定的实际输出和新增计算单元输出隔离。优选的,待升级软件的版本比既有软件的版本高一级。优选的,新增计算单元与各既有计算单元的比较结果不参与实际输出。优选的,x、n、m均为2。本发明的有益效果是:本发明通过运用冗余校验原理,实现在运营时间内对新安全苛求系统软件的测试,从而可以在正常运营时间中,对新软件进行长期有效验证,以确保安全苛求系统软件升级过程中的质量,同时不影响既有系统的正常运营,有效缓解安全苛求系统现场测试需求与实际有限的运营后有限现场测试时间的矛盾。附图说明图1是本发明中新增计算单元计算结果与既有计算单元投票结果校验的示意图;图2是本发明中新增计算单元计算结果与既有计算单元运算结果校验的示意图;图3是本发明中新增计算单元与既有计算单元同步输入的示意图;图4是现有技术中2乘2取2系统架构的示意图。具体实施方式下面将结合附图对本发明作进一步说明。冗余提供系统的可用性,也就是系统a与b都能执行同一个任务,实现相同功能。正常情况下系统a工作,系统b时刻准备好接替系统a,但并不参与该任务执行。一旦系统a故障,系统b立刻接收任务,保障系统继续正常运行。校验目的是缓解随机性失效带来的安全性危害。同一个任务,安排具有相同功能的单元a1与单元a2同时独立去做。做完了把单元a1、a2分别计算的结果拿来投票,采取少数服从多数原则。随机性的衡量标准是概率,从概率角度,多个单元同时出现随机性失效且造成相同结果的概率极低,从而缓解了随机性失效的危害。在特殊情况下,独立单元投票结果正好均分,没有多数或少数,需要采用倒向安全侧策略,做一个稳妥的行动决定。比如判断一列车是否要刹车,只有单元a1与单元a2两个独立单元分别进行刹车结果计算。单元a1得出结果要刹车,单元a2得出不用刹车结果,系统最终采取一个安全的刹车行动。如下图4所示,举例典型的安全冗余校验架构:2乘2取2系统架构。该架构广泛应用于地铁控制系统。其中2乘冗余是为了可用性,2取2校验是为了安全性。要把上述冗余校验的原理,创新应用到苛求系统软件升级。需要做到:1)从原理上,要把既有软件(版本n)视作一个校验单元,把要升级的新软件(版本n+1,待升级软件)视作另外一个校验单元,对新旧软件计算结果进行比较。2)在对于实际系统控制角度,要把既有软件(版本n)与要升级的新软件(版本n+1)视作冗余系统,实现信息同步。但是新软件永远不参与实际控制,也就是永远不接管系统。软件升级是一个迭代的概念。1)即对于既有软件需要改进的功能,新软件行为应该不同,要达到改进目标。2)新软件其它的功能,应该与既有软件一致;即除目标修改以外的功能,系统行为不应受修改影响,应与既有软件一致。以上两个软件升级迭代测试目标,可以通过校验原理达到。如果能在系统运营时间进行校验测试,那么大部分的测试目标能在系统正常运营时触发覆盖。也就是既有软件运营现场本身,就是对新软件的测试调试现场。如果新系统与既有系统一起经过了数月的运营时间校验测试,确保软件质量,之后再升级软件时,人们信心度会大大增加。就如同把升级后未来的运营状况,提前到现在进行推演。但其中还有一个问题要解决,就是不能影响既有软件对实际运营的控制。因此,需要做到冗余但不接管。主备冗余系统中,后备系统具有两个特征:1)具备随时接管的能力,这点是通过与主用系统信息同步实现。2)接管前绝不控制系统,这点可以通过备用系统输出隔离实现。本发明中新软件可以视作装在备用系统上,但需要调整以上的策略:1)新软件安装系统具有接管能力,在新软件调试期间不接管实际运营,确保不会影响既有软件正常运营。2)该系统输出隔离的同时还需要知道既有系统的输出结果,用于校验测试。本发明适用于x乘n取m系统,x为正整数,n、m均大于等于2,且为整数。适用于每个冗余单元(主用或备用单元)。每个冗余单元采用相同方法。本发明的用于安全苛求系统软件升级的校验方法,包括下列步骤:一、在x乘n取m系统的冗余单元中,从硬件层面拓展至少一个新增计算单元;本实施例中,以2乘2取2系统为例。处于资源考虑,可以新增一个单元用于验证新软件逻辑。新增计算单元可能存在的硬件随机故障可以通过与既有计算单元的校验来监测。二、在冗余单元中的n个既有计算单元加载既有软件,在新增计算单元加载待升级软件(新软件)。三、为了进行新增计算单元与既有计算单元行为的校验,对于输入需进行输入信息同步。拓展后的系统信息同步与n取m冗余校验系统信息同步机制一致。本实施例中,2取2系统拓展后,采取3取2系统的信息同步机制,既有计算单元和新增计算单元每个运算周期都基于本周期相同输入进行计算。如图3所示。四、采集既有计算单元计算结果与新增计算单元进行校验,同时保障新增计算单元不会影响实际输出。由于新系统(由新增计算单元组成)从架构上与实际系统(由既有计算单元组成)控制隔离,也就永远不会真正接管系统,对实际系统在既有软件控制下的运行。具体地,根据各既有计算单元的运算结果决定实际输出,并将各既有计算单元的运算结果或由各运算结果产生的既有投票结果告知新增计算单元。将新增计算单元的运算结果与各既有计算单元的的运算结果或由各运算结果产生的既有投票结果进行比较,比较结果不参与实际输出,只作为校验测试结果,即根据比较结果记录比较日志为行为一致(即新增计算单元的运算结果与各既有计算单元的的运算结果或由各运算结果产生的既有投票结果相同)或行为不一致(即新增计算单元的运算结果与各既有计算单元的的运算结果或由各运算结果产生的既有投票结果不同)。如图1、2所示。具体地,校验判定原则如下:新增计算单元加载的软件为升级版本软件,对比既有软件有修改增量。离线识别既有软件的变更产生的预期行为变化:预期行为不一致,以及预期行为一致。预期行为变化与比较日志对比,判定新增计算单元的行为是否符合预期,不符合预期的地方需进行分析判定:是预期出错还是软件实施出错。具体参见下表1,分为四种情况:1)比较日志记录为行为一致,并且预期行为一致,则判定新增计算单元的行为符合预期。2)比较日志记录为行为一致,并且预期行为不一致,则判定新增计算单元的行为不符合预期,并进一步分析是预期出错还是软件实施出错。3)比较日志记录为行为不一致,并且预期行为一致,则判定新增计算单元的行为不符合预期,并进一步分析是预期出错还是软件实施出错。4)比较日志记录为行为不一致,并且预期行为不一致,检查两个不一致的方式是否相同,即:导致比较日志记录的行为不一致的原因方式,与预期行为不一致的原因方式,是否相同,若是,则判定新增计算单元的行为符合预期,若否,判定新增计算单元的行为不符合预期,并进一步分析是预期出错还是软件实施出错。预期行为一致预期行为不一致比较日志记录行为一致正常分析是预期出错还是软件实施出错比较日志记录行为不一致分析是预期出错还是软件实施出错检查不一致方式是否如预期表1因此,在既有系统运营过程中,新软件通过校验对比既有系统的行为,在正常运营过程中执行了新软件得到了充分有效的验证,大大降低了非运营时段软件现场测试压力。以上实施例仅供说明本发明之用,而非对本发明的限制,有关
技术领域
的技术人员,在不脱离本发明的精神和范围的情况下,还可以作出各种变换或变型,因此所有等同的技术方案也应该属于本发明的范畴,应由各权利要求所限定。当前第1页12
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1