1. MBSE验证与确认工程导论
在传统系统工程中，验证与确认（Verification and Validation，V&V）往往被安排在研制流程的后半段：设计完成后再做评审、测试和试验。这种“先设计、后验证”的模式在需求相对稳定、系统复杂度可控时还能运转，但一旦系统涉及多学科耦合、软件与硬件深度集成、需求频繁变更，问题就会在集成后期集中爆发，返工代价极高。基于模型的系统工程（MBSE）改变了这一局面——它把系统从需求、功能、架构到行为、参数都用模型统一表达，使V&V不再只是末端环节，而成为贯穿生命周期的连续活动。
一、MBSE范式下V&V的定位
要理解MBSE中V&V的定位，先要区分两个常被混用的概念。验证（Verification）回答的是“我们是否正确地构建了系统”，即产品是否满足其设计规格与需求；确认（Validation）回答的是“我们是否构建了正确的系统”，即产品是否满足利益相关者的真实需要和预期使用场景。前者对照的是“需求—设计—实现”的一致性，后者对照的是“需求—使用—价值”的匹配性。二者方向不同、依据不同，缺一不可。
在MBSE范式下，V&V的定位发生了三点根本变化。第一，验证对象从文档转向模型：需求、架构、接口、状态机、参数约束都以模型元素存在，验证可以直接针对模型执行一致性检查、约束求解和仿真。第二，验证时机从末端前移：需求模型一旦建立，就可以检查其完整性、无歧义性和可验证性；架构模型一旦成型，就可以通过接口分析和行为仿真提前暴露冲突。第三，验证证据从人工记录转向可追溯链路：每个需求都能通过追溯关系关联到设计元素、分析模型、测试用例和验证结果，形成可查询、可审计的证据网络。
二、核心概念与关键术语
MBSE的V&V体系建立在几个相互关联的概念之上，理解它们之间的关系是后续所有工作的基础。
- 需求模型：以结构化方式表达利益相关者需求、系统需求、派生需求，并标注每条需求的来源、优先级、验证方法和验收准则。
- 架构模型：描述系统的组成、层次、接口和分配关系，是验证“设计是否覆盖需求”的主要对象。
- 行为模型：用状态机、活动图、序列图等表达系统在不同激励下的响应，是功能验证和场景验证的核心。
- 参数模型：用约束和方程表达性能、重量、功耗等指标之间的关系，支持参数验证和权衡分析。
- 追溯关系：连接需求、设计、分析、测试和结果的关系链，是V&V证据可审计的关键。
- 验证用例：描述“用什么激励、在什么条件下、观察什么输出、判定准则是什么”的可执行或可分析的验证单元。
这些概念不是孤立存在的。需求模型驱动架构模型，架构模型约束行为模型和参数模型，行为与参数模型又反过来验证需求是否可实现、是否自洽。追溯关系则像神经网络一样把这些模型元素连接起来，使任何一处变更都能被追踪到受影响的需求、设计和验证活动。
三、V&V与系统工程生命周期的关系
在典型的系统工程生命周期中，V&V活动与各阶段形成对应关系。概念阶段，V&V主要体现为需求确认——通过场景分析、利益相关者访谈和用例建模，确认需求是否真实反映使用需要。开发阶段，V&V体现为设计验证——通过模型一致性检查、接口分析、行为仿真和参数求解，验证设计是否满足需求。集成与测试阶段，V&V体现为产品验证——通过实物测试、半实物仿真和系统试验，验证实现是否与模型一致。运行与维护阶段，V&V体现为使用确认——通过现场数据、运行日志和用户反馈，确认系统在实际环境中是否达到预期效果。
需要强调的是，MBSE并不取代实物测试，而是让实物测试更有针对性。模型验证可以提前筛除大量设计缺陷，使实物测试聚焦于模型无法充分覆盖的物理效应、环境耦合和人为因素。模型与实物之间形成“模型预测—实物验证—模型修正”的闭环，这才是MBSE V&V的完整含义。
四、基于模型的V&V整体框架
下面这张图给出了MBSE V&V的整体框架。它从左侧的需求与场景出发，经过模型构建与验证准备，进入中间的验证执行层，最终在右侧形成确认结论与证据闭环。图中同时标出了验证与确认两条不同的对照路径，以及贯穿全程的追溯关系。
从图中可以看出，MBSE V&V框架有三个显著特征。第一，左侧需求与场景是整个验证活动的参照基准，没有清晰、可验证的需求，后续所有验证都失去意义。第二，中间三层构成验证执行的主干：模型构建提供验证对象，验证准备定义验证方法，验证执行产生验证结果。第三，右侧确认与证据形成闭环，验证结果经过确认活动转化为可归档的证据，并通过反馈路径修正需求和模型。底部的追溯关系带贯穿全程，确保每个验证结果都能回答“验证的是哪条需求、依据的是哪个设计、使用的是什么用例”。
五、从“文档驱动”到“模型驱动”的转变要点
对于刚开始接触MBSE V&V的团队，最容易犯的错误是把模型当成“另一种形式的文档”——建完模型就导出文档，然后按老办法评审和测试。这样做只是换了个工具，没有真正发挥模型的价值。真正的转变体现在三个方面。
其一，验证前移。在需求模型完成后，立即用模型检查需求的完整性、一致性和可验证性。例如，检查是否存在没有验证方法的需求、是否存在相互矛盾的需求、是否存在无法量化的验收准则。这些检查在文档模式下往往要等到评审会才被发现，而在模型模式下可以自动化执行。
其二，验证左移。在架构模型完成后，通过接口分析和行为仿真验证设计是否满足功能需求。例如，用状态机仿真验证模式切换逻辑是否覆盖所有场景，用参数模型求解验证性能指标是否在约束范围内。这些活动不需要等待实物件，可以在设计阶段就发现大量问题。
其三，证据链自动化。每次验证执行后，结果自动关联到对应的需求、设计元素和验证用例，形成可查询的证据链。当需求变更时，系统可以自动识别受影响的验证用例和已完成的验证结果，提示需要重新验证的范围。这是文档模式下几乎无法实现的。