1. 课程导入与SysML需求建模全景

在基于模型的系统工程(MBSE)实践中,需求不再是散落在文档中的自然语言条目,而是模型中的一等公民。SysML(系统建模语言)为需求提供了可追踪、可验证、可演进的建模载体。本课程围绕“需求追踪与验证建模”这一主线,帮助你把需求从“写下来”推进到“连起来、验得了”。

先建立一个整体判断:SysML 的九种图中,需求图(req)负责表达需求本身及其派生、包含、验证关系;用例图(uc)把需求锚定到系统对外提供的价值;块定义图(bdd)与内部块图(ibd)定义系统结构与接口;活动图(act)与状态机图(stm)描述行为;参数图(par)约束性能指标;而追踪关系则像神经网络一样贯穿这些视图。理解这张全景图,是后续所有实操的前提。

SysML 需求追踪与验证建模全景 需求层 → 结构层 → 行为层 → 参数层 → 验证层,追踪关系贯穿始终 需求层 · 需求图(req) 系统需求 SR-01 派生需求 DR-01 接口需求 IR-01 性能需求 PR-01 «derive» «derive» «derive» «satisfy» / «verify» 追踪 结构层 · 块定义图(bdd)/ 内部块图(ibd) 系统块 System 传感器块 控制器块 执行器块 行为层 · 活动图(act)/ 状态机图(stm) 采集活动 处理活动 待机状态 运行状态 数据流 触发 参数层 · 参数图(par) 采样周期 T=10ms 响应时间 ≤ 50ms 约束 验证层 · 验证用例与追踪 验证用例 TC-01 验证用例 TC-02 结构/行为 → 参数约束 → 验证用例 追踪关系核心语义 «derive» 需求派生:从上层需求推导出下层需求,形成需求层级。 «satisfy» 满足关系:设计元素(块/活动/状态)声明满足某条需求。 «verify» 验证关系:验证用例声明对某条需求进行验证,并给出判定结果。

这张全景图揭示了 MBSE 中需求建模的基本逻辑:需求不是孤立文本,而是通过追踪关系与结构、行为、参数、验证四类模型元素建立可追溯的关联。需求图定义“要什么”,块定义图与内部块图定义“用什么实现”,活动图与状态机图定义“怎么运行”,参数图定义“性能边界在哪”,验证用例则回答“是否真的做到了”。

课程实战项目背景

本课程以一个简化的“智能温控系统”作为贯穿案例。该系统包含温度传感器、控制器、加热执行器三个主要部件,核心需求包括:SR-01 系统应在 0~50℃ 环境温度下正常工作;SR-02 系统温度控制精度应达到 ±0.5℃;SR-03 系统应在检测到温度超过 45℃ 时自动切断加热。这些需求将分别派生为接口需求、性能需求和功能需求,并在后续章节中逐步建立块定义、内部接口、活动流程、状态迁移、参数约束和验证用例。

以 SR-02 为例,它派生出一条性能需求 PR-01:“控制器响应时间不超过 50ms,采样周期为 10ms”。在参数图中,这表现为两个约束参数之间的依赖关系;在验证阶段,则对应一个验证用例 TC-01,通过注入阶跃温度信号并测量控制器输出延迟来判定是否满足。这种从需求到验证的完整链路,正是本课程要训练的核心能力。

学习建议:在进入后续章节前,先确认你使用的建模工具支持 SysML 需求图与追踪关系(如 Cameo Systems Modeler、Enterprise Architect、Capella 等)。不同工具对 «derive»、«satisfy»、«verify» 的语法支持略有差异,但语义一致。本课程示例以通用 SysML 语义为准,不绑定特定工具。

需要特别注意的是,追踪关系不是“画完图再补”的装饰,而是建模过程中持续维护的约束。每新增一条需求,就应同步考虑它由谁派生、由哪个设计元素满足、由哪个验证用例覆盖。这种“需求—设计—验证”三位一体的追踪习惯,是 MBSE 区别于传统文档工程的关键所在。

接下来的章节将依次展开:需求图的建模语法与派生规则、用例图如何锚定系统边界、块定义图与内部块图如何承载需求分配、活动图与状态机图如何描述行为需求、参数图如何约束性能指标,以及验证用例如何与需求建立 «verify» 关系并给出判定结论。每一部分都会回到智能温控系统这一案例,确保你不仅理解符号,更能完成从需求到验证的完整建模闭环。