本发明涉及一种轨道交通车载控制器软件半形式化需求验证系统，尤其是涉及一种基于smt(可满足性模理论)的车载控制器软件半形式化需求验证系统及方法。
背景技术：
随着我国轨道交通行业高速发展，车载控制器软件的功能需求日益复杂，给相关的软件质量保证工作带来很的压力。工业数据显示大约50％的产品缺陷是由于需求的质量不到位造成的，大约80％的返工工作量可以追溯到需求缺陷，尤其是对轨道交通车载控制器这类高可信嵌入式软件而言，其需求规范的缺陷将造成不可估量的财产损失和人员伤亡；另一方面，需求的遗漏和错误往往具有很强的隐蔽性，需求分析阶段的缺陷如果不能得到及时纠正，将在后续阶段造成极大影响，缺陷发现得越晚，修改的代价就越高。
所以，软件需求规范的正确性验证对于整个软件质量保证体系显得尤为重要。目前，高可信嵌入式软件多以状态机、真值表、序列图、流程图为主的半形式化的描述方式，但是相应的需求验证方法主要是文档评审和原型示范等技术，对于验证人员的经验和责任心要求极高。
且此种人工验证需求的方法存在以下不足：(1)由于是人工检查，可能会存在检查不到位、出现遗漏的情况，乃至无法达到预期的验证效果。(2)人工验证本质还是经验行为，对验证人员能力要求极高，同时缺少统一的规范和标准，在质量和效率方面可以提升的空间有限。
因此，如何实现一种能解放验证人员的人力，同时又能高效地对车载控制器软件需求进行自动化的检查和分析方法就变得越来越紧迫。
技术实现要素：
本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种基于smt的车载控制器软件半形式化需求验证系统及方法，利用形式化理论工具对半形式化的软件需求进行准确、高效地验证。
本发明的目的可以通过以下技术方案来实现：
一种基于smt的车载控制器软件半形式化需求验证系统，包括：
半形式化软件需求规范化模块m1，用于对半形式化的车载控制器软件需求进行自动转换，生成能够被smt求解器识别的合取范式形式输入；
约束条件建立模块m2，用于根据上级系统需求和系统设计，抽取、归纳并建立针对软件功能的约束条件；
需求验证模块m3，用于对格式转换后的输入软件需求根据约束条件进行求解，验证软件需求的正确性以及与上级需求和设计的一致性。
所述的约束条件建立模块m2建立的约束条件能够被smt求解器识别，并通过结合了背景理论的一阶逻辑公式刻画出来，作为smt求解器的输入。
一种基于smt的车载控制器软件半形式化需求验证系统的方法，包括以下步骤：
步骤s1：在半形式化软件需求规范化模块中，将半形式化的车载控制器软件需求进行格式上的转换，生成合取范式；
步骤s2：在约束条件建立模块中，对车载控制器软件需求的上级需求和设计进行抽取、归纳后，建立约束条件；
步骤s3：需求验证模块利用smt求解器，对格式转换后的输入软件需求根据约束条件进行求解，检查软件需求是否能满足约束条件。
所述的步骤s3中：如果车载控制器软件需求经过系统求解满足约束条件，说明与上级需求和设计相符，不存在缺陷；反之，则说明软件需求存在缺陷。
对于没有通过验证的需求，根据得到解的性质，分析需求产生问题的根因，修改后重新放入本发明的验证系统中验证。
与现有技术相比，本发明具有以下优点：
1、以形式化理论为支撑，对轨道交通车载控制器软件半形式化的需求进行自动化验证，真正实现了计算机对需求内容正确性、一致性的实质检查。
2、相较于需求验证的人工检查，该技术方案极大地节约了人力和时间，提高工作效率。
3、实现对半形式化软件需求变更的快速影响分析，从而提早发现软件变更中所隐藏的缺陷，节省大量人力、物力。
4、相对于完全的形式化方法，该技术方案上手简单，便于系统分析、开发和测试人员掌握。
附图说明
图1为本发明的结构示意图；
图2为本发明的流程图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都应属于本发明保护的范围。
本实施例中，将基于smt的轨道交通车载控制器软件半形式化需求验证系统应用于车载软件需求的列车倒溜监控功能模块的验证中。
如图1所示，是本发明基于smt的轨道交通车载控制器软件半形式化需求验证系统的结构示意图。本实施例中基于smt的轨道交通车载控制器软件半形式化需求验证系统包括：半形式化软件需求规范化模块m1，约束条件建立模块m2以及需求验证模块m3。
其中，半形式化软件需求规范模块m1是对车载控制器的半形式化软件需求进行自动转换，例如，列车倒溜监控功能模块的半形式化需求转换为合取范式。约束条件建立模块m2是根据车载控制器软件需求的上级设计和谢秋，抽取、归纳并建立能被smt求解起所识别的约束条件，即，结合了背景理论的一阶逻辑公式。例如，对于列车倒溜监控功能的需求的上级需求和设计归纳出若干约束条件。需求验证模块m3是利用smt求解器，对合取范式形式的需求根据约束进行求解，验证车载控制器软件需求中倒溜监控功能模块的正确性以及与上级需求的一致性。
如图2所示，本实施例基于smt的轨道交通车载控制器软件半形式化需求验证系统用于验证车载控制器软件半形式化需求中倒溜监控功能模块的一具体过程，包括以下步骤：
步骤s1，在半形式化软件需求规范化模块m1中，将倒溜监控功能模块需求进行自动转换，生成合取范式形式的smt求解器输入；
步骤s2，对上级需求和设计归纳、抽取，建立约束条件；例如，在本实施例中，对于倒溜监控功能模块需求的上级需求，提取出一具体约束“列车在如何情况下发生倒溜，距离不能超过smax”，使用一阶逻辑公式将其刻画出来。
步骤s3，利用模块m3中的smt求解器，对合取范式形式的倒溜监控功能模块需求，根据步骤s2中建立的约束，进行求解，从而验证输入需求的正确性以及于上级需求的一致性；
其中，在模块m3中，先将合取范式形式的溜监控功能模块需求取反，之后smt求解器若能得出使得取反后的需求范式满足约束的解，那么输入需求通过了该约束条件下的验证；否则输入需求没有通过验证。
对于没有通过验证的需求，根据得到的解的性质，分析需求产生问题的根因，修改后重新放入本发明的验证系统中验证。
本实施例中，将已经通过人工验证后的一正式版本的车载控制器软件需求作为检测对象，运用本发明基于smt的轨道交通车载控制器软件半形式化需求系统验证，检测出该软件功能模块的需求还存在2处缺陷。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。