在安全关键实时系统领域，精确性不仅仅是一种偏好，更是生存的必要条件。无论是设计汽车控制单元、医疗设备还是航空航天航电系统，系统行为的可预测性决定了安全完整性等级。UML 时序图是该生态系统中至关重要的工件，用于可视化事件、信号和对象生命线之间的时间关系。然而，一张在视觉上看起来正确的图表可能无法捕捉认证所需的严格约束。
本指南为在安全关键环境中验证 UML 时序图提供了全面的框架。我们专注于结构完整性、时间准确性和可追溯性，而不依赖特定的商业工具。目标是确保模型准确反映硬件和软件执行环境的物理现实。
📋 为什么验证在安全关键环境中至关重要
汽车行业的 ISO 26262 和工业系统的 IEC 61508 等安全标准强制要求严格的验证流程。时序图通常用于定义最坏情况执行时间（WCET）、中断延迟和通信截止时间。如果时序图存在缺陷，后续的代码生成或仿真将不正确，可能导致系统故障，从而危及用户或环境。
验证与确认不同。验证询问的是：“我们是否正确地构建了产品？”（与设计进行核对）。确认询问的是：“我们是否构建了正确的产品？”（与用户需求和安全要求进行核对）。在时序图的背景下，确认确保所建模的时间约束实际上与处理器和通信总线的物理能力相符。
🔍 第一阶段：验证前准备
在检查图表本身之前，必须建立基础上下文。时序图不能孤立存在；它依赖于状态机中定义的行为以及系统架构中定义的时间预算。
- 需求对齐：确保图表上的每个约束都映射到特定的安全需求。不应存在无法追溯的时间约束。
- 上下文定义：定义图表的范围。它是单个功能、子系统还是整个系统？清晰性可防止范围蔓延和歧义。
- 时间参考系：确认时间是绝对的（墙钟时间）还是相对的（自触发以来）。若无明确标记而混合使用这两种时间，会导致计算错误。
- 执行环境：记录假设的处理器速度、时钟周期和中断优先级。图表必须反映特定的硬件配置。
🏗️ 第二阶段：结构验证
UML 时序图的结构决定了对象随时间如何交互。结构错误通常会导致逻辑死锁或竞态条件，而这些在测试中很难被发现。
2.1 对象生命线和实例名称
- 唯一性：每条生命线必须具有唯一的标识符。重复的名称会混淆可追溯性工具。
- 一致性：确保名称与系统架构文档完全一致。如果架构中将其称为“Sensor_Module”，则图表中不得使用“Sensor”。
- 激活条：验证激活条（生命线上的矩形）是否正确表示控制周期。它们应在操作被调用时开始，并在操作返回或信号发送时结束。
- 销毁事件：如果对象被销毁，请确保“X”标记放置正确。过早销毁可能导致生成的代码中出现空指针异常。
2.2 区域与并行性
实时系统通常并发处理多个任务。UML 通过组合片段（特别是并行区域）允许这种并发处理。
- 并行区域：验证并行区域（标记为“par”）是否准确表示硬件并发。确保并行度与实际可用的CPU核心数或中断上下文数量相匹配。
- 干扰：检查并行区域之间是否存在共享资源。如果两个并行进程在未同步的情况下访问同一内存地址，则该图表不安全。
- 守卫条件：如果在区域内使用了守卫条件，请确保其逻辑正确。始终为真或始终为假的守卫条件将违背条件流的目的。
⏱️ 阶段 3：时序验证
这是时序图验证的核心。时序错误是安全关键系统中非确定性最常见的来源。
3.1 时序约束与数值
- 计量单位：明确说明时间单位（毫秒、微秒、周期）。此处的歧义是导致关键缺陷的常见原因。
- 范围与点值：安全关键系统通常需要范围（最小值/最大值）。请确保图表支持区间表示法，而非在可能存在变化的情况下使用固定点。
- 最坏情况执行时间（WCET）分析：所示的每条执行路径都必须有文档记录的最坏情况执行时间。如果某条路径未经分析，则无法在认证图表中表示。
- 抖动：考虑通信中的抖动。如果信号预期每10毫秒出现一次，则应允许容差。图表应反映允许的最大偏差。
3.2 截止期限合规性
| 约束类型 | 验证检查 | 安全影响 |
|---|---|---|
| 硬截止期限 | 验证信号在时间T之前到达。 | 系统故障 / 功能丧失 |
| 软截止期限 | 验证信号到达时性能降级最小。 | 性能降级 |
| 周期性 | 验证重复间隔是否恒定。 | 时序漂移 / 振荡 |
| 延迟 | 验证从触发到执行的响应时间。 | 不稳定的控制回路 |
3.3 时间表达式
- 复杂表达式：避免在时序约束中使用过于复杂的数学表达式。保持其足够简单，以便能够进行数学验证。
- 依赖关系：如果时序约束依赖于另一个事件（例如，“时间 = T1 + T2″），请验证依赖链是否完整且已定义。”
- 溢出：确保时间值不超过底层数据类型的容量（例如，32 位整数）。这可能导致回绕错误。
📡 阶段 4：消息序列与交互验证
数据流决定状态变化。错误的消息序列可能导致系统状态不一致。
4.1 同步信号与异步信号
- 箭头类型：明确区分实线箭头（同步调用）和虚线箭头（异步信号）。错误地混合它们会暗示不存在的阻塞行为。
- 返回值：对于同步调用，请确保已考虑返回信号。缺少返回可能导致调用方无限期挂起。
- 发后即忘：对于异步信号，请确认发送方不会等待响应。这对于非阻塞实时任务至关重要。
4.2 丢失或重复的信号
- 通信介质：对通信介质（总线、网络、中断）进行建模。该图是否考虑了消息丢失的情况？
- 超时：如果信号可能无法到达，是否建模了超时机制？缺少超时是安全系统中常见的故障模式。
- 重传：对于关键消息，如果协议要求，请验证图中是否显示了重传逻辑。
⚠️ 阶段 5：异常处理与错误状态
标准操作只是故事的一部分。安全关键系统必须优雅地处理故障。
- 异常路径：每个操作都应具有关联的异常路径。如果函数失败，时序会发生什么变化？
- 恢复时间：对从错误中恢复所需的时间进行建模。这将增加整体延迟预算。
- 故障安全状态：确保图表显示在发生时序违规时系统进入安全状态（例如停止电机）。
- 看门狗定时器：验证是否已描绘与看门狗定时器的交互。如果图表的执行时间超过看门狗限制，系统必须重置。
🔗 第 6 阶段：可追溯性与文档
如果无法追溯至需求或向前映射至实现，则经过验证的图表毫无用处。
- 需求链接：每个时序约束都应链接到需求 ID。这使审计人员能够验证覆盖范围。
- 实现映射：确保图表映射到实际的源代码函数。图表中的函数名称应与代码签名匹配。
- 版本控制：时序图会不断演进。请确保版本管理得当，防止在生产代码中使用过时的模型。
- 变更日志：记录时序约束变更的原因。是由于硬件变更还是需求更新？
🛠️ 需避免的常见陷阱
即使是经验丰富的工程师在建模时间时也会陷入陷阱。请警惕这些常见问题。
- 忽略中断延迟：假设 CPU 始终可用。实际上，中断可能会将任务执行延迟数微秒。请对中断开销进行建模。
- 过于乐观的时序：使用最佳情况而非最坏情况。安全裕度必须基于最坏可能的条件进行计算。
- 忽略数据依赖关系：两个任务可能是并行的，但如果一个任务依赖于另一个任务的数据，则它们实际上是串行的。请正确建模依赖关系。
- 静态与动态：不要将静态时序分析与动态仿真假设混用。它们服务于不同的验证目的。
- 手动输入的人为错误：如果手动输入数值，请实施同行评审。时间值中的一个拼写错误就可能导致安全论证失效。
🔄 持续验证策略
验证不是一次性的事件。随着系统的演进，时序图也必须随之演进。
- 回归测试：当需求发生变化时，请在更新后的图表上重新运行验证清单。
- 硬件在环：将图表预测与实际硬件性能进行比较。必须解决任何差异。
- 定期审查：安排对时序图的定期审查，以确保它们仍反映当前的系统架构。
- 自动化检查：如果建模环境支持，请使用脚本自动验证语法和基本约束。
📊 验证清单摘要
为确保安全关键设计的稳健性，请在审查过程中使用以下摘要作为快速参考。
- ✅ 上下文：是否定义了作用域和时间单位？
- ✅ 结构：生命线（lifelines）和激活条是否准确？
- ✅ 并发：并行区域是否准确反映了硬件行为？
- ✅ 时序：是否已考虑最坏情况执行时间（WCET）和抖动？
- ✅ 截止时间：是否区分了硬截止时间和软截止时间？
- ✅ 信号：同步信号和异步信号是否清晰明确？
- ✅ 异常：是否已对故障路径和超时进行了建模？
- ✅ 可追溯性：需求是否与约束条件相关联？
- ✅ 评审：该图表是否经过同行评审？
遵循此全面检查清单可确保您的UML时序图不仅是图形表示，更是安全、确定性实时系统的可靠蓝图。通过严格验证每个元素，您可以降低运行时故障的风险，并使您的设计符合最高的安全标准。
请记住，该图表是设计与实现之间的契约。如果契约存在缺陷，执行也将存在缺陷。请为此验证阶段投入必要的时间和资源，因为它是系统可靠性的基础。