Visual Paradigm Desktop | 
Visual Paradigm Online
工程复杂系统不仅需要设计组件，更需要在意图与实现之间建立严谨的联系。随着系统范围的扩大，集成软件、硬件、机械结构和操作逻辑，碎片化风险也随之增加。使用SysML的基于模型的系统工程（MBSE）提供了管理这种复杂性的框架，但前提是必须正确建立可追溯性。本指南探讨了在不同工程领域中保持系统定义一致性的必要结构模式。
SysML中的可追溯性不仅仅是报告功能；它是验证与确认的基石。如果没有需求、设计元素和测试之间的强关联，系统架构就会变成孤立的孤岛。工程师必须掌握如何利用该语言创建能够经受住设计迭代和领域交接考验的稳健连接。
在实施模式之前，必须理解语言内部的基本机制。SysML主要通过以下关系定义可追溯性：trace关系，该关系可应用于各种元素之间。此关系与标准的结构或行为链接不同。
需求元素： 这些定义了系统必须完成的功能。它们是可追溯性网络的锚点。
块定义图（BDD）： 定义物理和逻辑结构。
内部块图（IBD）： 定义内部接口和流程。
参数图： 定义约束和数学关系。
验证测试： 通常以需求类型或独立的验证需求形式表示。
可追溯性的核心原则是确保每个需求都由一个设计元素满足，并由一个测试用例验证。这形成了一个完整的证据闭环。在多领域系统中，这一闭环必须跨越不同的技术语言和工程学科。
不同的工程问题需要不同的可追溯性模式。一刀切的方法往往导致混乱或可见性不足。以下是用于组织系统信息的主要模式。
正向可追溯性从需求开始，向下游流向设计和实现。它回答的问题是：“哪些设计元素满足这一需求？”
方向： 需求 → 设计 → 实现。
应用场景： 确保没有需求被遗漏实现。
优势： 通过确认每个请求的功能都在架构中得到处理，防止范围蔓延。
实现： 使用 deriveReqt 或 refine 关系将需求与模块或用例关联起来。
反向可追溯性从设计元素向上游追溯到原始需求。它回答的问题是：“这个组件存在的原因是什么？”
方向： 设计/实现 → 需求。
用例： 识别模型中的冗余元素或无用代码。
优势： 通过展示修改特定组件时会影响哪些需求，支持变更管理。
实现： 将IBD中的模块链接回需求图中的特定需求。
此模式结合正向和反向链接，形成完整的验证链。它是安全关键系统中的黄金标准。
方向： 需求 ↔ 设计 ↔ 测试。
用例： 认证流程和法规合规性。
优势： 为审计和安全论证提供全面覆盖的保障。
在多领域系统中，软件需求必须链接到硬件模块，该模块再链接到机械约束。此模式弥合了不同工程语言之间的差距。
方向： 软件需求 → 固件 → 电气模块 → 机械约束。
用例： 行为依赖于物理特性的网络物理系统。
优势：确保软件功能不会违反物理限制。
组织这些模式需要一种结构化的方法。矩阵格式通常是可视化关系最有效的方式。下表概述了构建全面可追溯性矩阵时推荐的列。
|
需求ID |
需求文本 |
来源 |
设计元素ID |
设计元素类型 |
验证方法 |
测试用例ID |
状态 |
|---|---|---|---|---|---|---|---|
|
REQ-001 |
系统应启动启动序列 |
利益相关方 |
BLOCK-100 |
控制逻辑 |
分析 |
TEST-001 |
已验证 |
|
REQ-002 |
功耗 < 5W |
法规 |
PARAM-200 |
约束 |
仿真 |
TEST-002 |
进行中 |
|
REQ-003 |
外壳必须能承受冲击 |
环境 |
MECH-300 |
机械部件 |
物理测试 |
TEST-003 |
已批准 |
使用结构化矩阵可确保在评审过程中不会遗漏任何一列。它迫使工程师考虑每个单独需求的验证方法。
复杂系统很少仅由单一工程学科构成。它们涉及软件、电子、机械和运营之间的相互作用。每个领域都有其自身的生命周期和术语，使得可追溯性变得困难。
最常见的摩擦点出现在软件与硬件交汇处。一个软件需求可能表述为“系统应在50毫秒内响应”。这很抽象，必须追溯到定义处理器速度和内存延迟的硬件模块。
模式： 使用一个 细化 从软件需求到硬件定义中的功能模块的链接。
挑战： 时序约束通常在参数图中定义，而逻辑则在状态机中定义。
解决方案： 创建一个专用的 接口模块 明确定义时序属性，并将软件需求与此接口关联。
机械约束通常决定了运行限制。如果机械臂的最大扭矩有限，运行模式就必须反映这一限制。
模式： 将运行用例与它们所交互的机械模块关联起来。
挑战： 运行需求通常以自然语言编写，而机械模型则使用数学约束。
解决方案： 将运行限制转换为参数约束。将需求直接链接到参数图中的方程。
固件通常充当高层软件与底层物理信号之间的纽带。可追溯性必须确保固件驱动程序正确地暴露物理传感器的功能。
模式：使用分配关系将固件功能分配给特定的硬件驱动程序。
挑战：固件更新可以在不更改物理硬件的情况下发生。
解决方案：在可追溯性链接上保持版本管理策略。如果固件发生变化但需求仍得到满足，则更新链接状态，而不是断开连接。
实施可追溯性并非没有障碍。在复杂环境中会出现一些常见问题。及早识别这些问题有助于更好地规划。
随着时间推移，随着需求变化或设计演进，链接会变得过时。一个需求可能已被删除，但链接仍指向一个不存在的模块。
缓解措施：实施自动化验证脚本，在构建过程中检查孤立链接。
缓解措施：要求每个链接都带有状态标志（例如：活动、已弃用、待处理）。
有时一个需求层次过高，无法与单一组件关联；或者一个组件过于详细，无法与单一需求关联。这会形成难以管理的多对多关系。
缓解措施：将高层次需求分解为与系统模块对齐的低层次功能需求。
缓解措施：将多个低层次组件组合成一个复合模块并将其作为链接目标。
软件工程师使用的工具与机械工程师不同。他们可能无法看到相同的可追溯性上下文。
缓解措施：采用单一真实源模型仓库，支持与外部领域工具集成。
缓解措施：在所有领域中为所有可追溯元素建立统一的命名规范。
保持可追溯性需要纪律。这并非一次性的设置，而是一个持续的过程。
尽早开始：在概念阶段就定义可追溯性需求。不要等到设计阶段才添加链接。
标准化命名：使用一致的ID格式（例如：REQ-SYS-001、BLK-INT-001）。这使得自动化搜索和报告成为可能。
定期审计：安排每季度对可追溯性图进行审查。检查是否存在断裂的链接和孤立的需求。
尽可能实现自动化：使用内置的模型验证功能来标记不一致之处。避免手动验证链接。
记录模式：制定标准操作程序（SOP），明确链接应如何创建、标记和维护。
为确保可追溯性网络健康，应跟踪特定的度量指标。这些指标能够揭示系统定义的质量情况。
该度量指标计算至少具有一个下游链接（设计或测试）的需求所占比例。
目标：关键需求的覆盖率必须达到100%。
测量方法：（已链接需求数 / 总需求数）× 100。
该指标衡量与验证方法相关联的需求所占比例。
目标：所有需求都必须分配验证方法。
测量方法：（具有测试/分析的需求数 / 总需求数）× 100。
该指标跟踪链接随时间被破坏或更改的频率。
目标：变化率低表明需求稳定。
测量方法：（每月损坏链接数 / 总链接数）× 100。
在安全关键系统中，简单的链接通常不足以满足需求。需要采用分层的验证结构，以证明每个层级均符合要求。
层级 1： 系统需求（例如：“车辆应在100米内停止”）。
层级 2： 子系统需求（例如：“制动系统应产生500N的力”）。
层级 3： 零件需求（例如：“液压泵流量应为10L/min”）。
层级 4： 实现测试（例如：“泵流量测试结果”）。
该层级结构确保组件层级的故障可以追溯至系统层级的需求。这使工程师能够准确地定位逻辑链中故障发生的具体位置。
变更不可避免。当需求发生变化时，影响分析完全依赖于可追溯性链接。
影响分析： 当需求被修改时，遍历所有下游链接，以识别受影响的模块、接口和测试。
审批流程： 在修改需求前，必须获得所有受影响领域的批准。例如，若软件需求的更改会影响处理器负载，则可能需要硬件团队的批准。
版本控制： 保留可追溯性图的历史记录。如果删除了某个链接，必须记录删除原因。
现实系统通常从外部来源获取数据，例如供应商规范或仿真结果。SysML的可追溯性应整合这些来源。
供应商需求： 使用“细化”关系将内部需求与外部供应商文档关联。细化 关系。
仿真结果： 将仿真输出文件附加到参数化图的约束上，以证明该约束已满足。
问题跟踪： 将缺陷或问题跟踪器中的缺陷或问题直接链接到导致它们的需求。
大型项目通常涉及为不同子系统建立多个模型。必须在这些模型边界之间保持可追溯性。
模型导入： 使用参考包将一个模型中的模块导入到另一个模型中，同时保持其ID和可追溯性链接。
接口定义： 定义模型之间的严格接口。可追溯性不应通过模糊的引用跨越模型边界。
全局注册表： 维护所有需求及其唯一ID的中央注册表，以防止模型间的重复。
构建一个稳健的可追溯性网络是一项战略性投资。它能降低变更成本，提高验证信心，并清晰展现系统健康状况。通过应用上述模式，工程师可以在不丢失原始意图的情况下，有效管理多领域系统的复杂性。
在此领域取得成功取决于纪律性、自动化以及对需求、设计和验证之间关系的清晰理解。应将可追溯性图谱视为一个随系统不断生长和演化的活体资产。定期维护和验证可确保模型在整个项目生命周期中始终是可靠的真相来源。