本技术介绍了一种利用大语言模型辅助的SysML状态机图功能需求静态校验技术。该技术通过以下步骤实现:步骤S1,对需求文本进行统一化表示,基于需求语句结构化处理;步骤S2,利用大语言模型对需求文本进行语义分析,提取关键信息;步骤S3,将提取的关键信息与SysML状态机图进行对齐验证,确保功能需求的一致性。该方法提高了SysML状态机图功能需求验证的准确性和效率。
背景技术
在系统工程(SE)领域,从基于文档的系统开发到基于模型的系统开发的范式转换已经发生。基于模型的系统工程(MBSE)为系统工程实践引入了增强的能力,INCOSE将其定义为“将建模形式化应用于支持系统需求、设计、分析、验证和确认活动,从概念设计阶段开始,并贯穿开发和后续生命周期阶段”。在航空航天和天文学领域,系统工程模型的正确性至关重要。这是由于这些系统的高昂设计、开发和运营成本,系统的长期使用,以及其安全关键属性。状态机图是用于描述系统动态行为的图形化表示,通过展示状态、转换和事件来实现。验证SysML状态机图与需求之间的对应关系对于确保系统设计准确反映其预期功能和行为至关重要。这一目标导向的活动侧重于将模型与系统需求对齐,确认它们准确描述了系统的预期结果。系统工程实践和经验表明,随着开发的推进,解决故障和错误的成本迅速增加,这明确显示出将验证和确认(V&V)活动提前而不是推后的强烈动机。
基于此,功能性需求与SysML状态机图之间的对齐与验证变得尤为重要,特别是在复杂系统如雷达系统的开发中。为了验证设计,有几种技术可供使用。在手动审查过程中,工程师会检查模型和文档。静态验证规则用于检查模型的结构一致性,而仿真则用于评估行为或测试用例的执行。仿真的主要结果是一个或多个执行轨迹,这些轨迹可用于分析不同的定性和定量属性。仿真方法也可依赖于形式化验证技术,这类方法可以被视为一种通过声明式指定目标驱动的自动化、高度优化的探索性仿真。传统上,这种方法的目标是通过适当的执行(即证据)来证明需求的满足或违反。然而,这种方法存在以下几个显著问题:
(1)形式化验证对测试人员的专业技能提出了较高要求。测试人员不仅需要具备深入的系统工程知识,还必须精通形式化验证工具的特定语言和规则。这种学习曲线较陡,且由于形式化语言的抽象性和复杂性,容易导致模型开发和验证过程中出现理解偏差或误用。同时,在实际应用中,不同工具的规则和使用方式可能各异,这无形中增加了验证过程的复杂性和成本。
(2)形式化验证工具在处理基础性需求时,往往表现出局限性。以“系统应具有工作态和维护态”这样的需求为例,形式化工具难以有效验证这类相对简单的功能需求。原因在于,形式化工具通常擅长于验证复杂的逻辑和算法,而对这种高层次的结构性要求,其验证能力有限。这使得形式化工具在一些情境下显得不够灵活,特别是在处理诸如状态存在、模式切换等功能性需求时,测试人员可能需要依赖其他手段或采取人工检查的方式来完成验证。
(3)形式化验证的流程通常较为冗长,涉及模型转换、编写形式化语言和工具配置等多个步骤。对于需求量较大的复杂系统,方法效率较低,并且在面对频繁需求变更时,形式化模型的维护成本也相对较高。尤其是在像雷达系统这样的复杂工程中,系统功能模块多、交互频繁,形式化工具虽然可以验证部分复杂逻辑,但无法覆盖所有需求层面,尤其是那些与具体业务场景密切相关的操作模式和状态转换,因此大多数解决方案仅处理部分建模元素。
针对这些问题,亟需探索一种更加直观、高效的方法来对齐和验证SysML状态机图与功能性需求的对应关系。
实现思路