📚 课程目录第3章项目定义

3. 项目定义：把边界画清楚，后面才不吵架

项目定义，说白了就是回答三个问题：我们要做什么？做到什么程度算完？哪些事不归我们管？ 我见过太多项目，前期边界没划清楚，后期扯皮扯到天昏地暗。你想想看，功能安全最怕的就是「我以为你做了，你以为我做了」，结果谁都没做。

ISO 26262 第 3 部分明确要求：项目定义必须包含项目边界、系统功能、运行模式、系统配置，以及法律与法规要求。这五个要素，缺一个后面都补不回来。

核心原则：项目定义不是写文档，而是建立共识。所有相关方——系统工程师、硬件工程师、软件工程师、测试工程师、项目经理——必须在同一页上。

项目边界定义了系统与外部环境的接口。我个人习惯用一张图把边界画清楚，包括：

举个例子，我在做电动助力转向（EPS）项目时，边界定义就特别关键。EPS 接收车速信号、方向盘转角信号、扭矩信号，输出电机扭矩。但车速信号来自 ESP 系统，方向盘转角来自转角传感器——这些外部信号如果不可靠，EPS 的安全目标就白定了。

我的经验：边界定义时，把「外部系统依赖」单独列出来。我曾经因为没写清楚「车速信号由 ESP 提供，ESP 需满足 ASIL B」，导致后期安全分析时发现依赖链断了，返工了两个月。

系统功能不是写「转向功能」「制动功能」这种大词。要拆到每个功能场景，包括：

我建议用表格把功能清单列清楚，每项功能都要有唯一编号。这样后面做 HARA（危害分析与风险评估）时，每个危害场景都能追溯到具体功能。

功能编号	功能名称	功能描述	运行模式	安全相关？
F-001	正常助力	根据方向盘扭矩和车速提供助力	驾驶模式	是
F-002	主动回正	低速时自动回正方向盘	驾驶模式	是
F-003	故障降级	检测到故障时切换到机械转向	故障模式	是
F-004	诊断通信	通过 CAN 总线上报故障码	所有模式	否

运行模式定义了系统在不同阶段的行为。常见的运行模式包括：

嗯，这里要注意：每个运行模式都要明确进入条件和退出条件。我遇到过一个问题——某个系统在故障模式下没有定义「如何退出故障模式」，结果测试时发现系统一旦进入故障就永远卡死，只能断电重启。

避坑指南：我曾经在项目定义阶段漏掉了「运输模式」——车辆在产线上或运输途中，系统不能正常工作。结果第一批样车装车后，系统在运输过程中一直报故障，因为传感器没接。后来补了运输模式，所有安全机制在运输模式下静默。

系统配置定义了系统有哪些硬件变体和软件变体。为什么这个重要？因为不同的配置可能对应不同的安全等级。

举个例子，一个制动系统可能有：

如果项目定义里没写清楚配置差异，后面做安全分析时就会乱套。我建议用配置矩阵来管理：

配置编号	硬件版本	软件版本	传感器配置	目标 ASIL
C-001	HW 1.0	SW 1.0	单传感器	ASIL B
C-002	HW 2.0	SW 2.0	双冗余传感器	ASIL D

功能安全不是自己说了算，还要满足各国法规。常见的法规要求包括：

我个人习惯在项目定义阶段就拉一个法规清单，标注每个法规的适用范围和强制要求。这样后面做安全目标时，可以直接引用法规条款，省得审核时被挑战。

关键提醒：法规要求不是「参考一下」，而是必须满足。如果项目定义里没写清楚法规要求，后面认证时发现不满足，整个项目可能推倒重来。

下面这张图展示了项目定义的五个核心要素及其关系。我习惯把它贴在项目办公室的墙上，每次开会都看一眼。

项目定义阶段完成后，你应该有这些输出物：

我的习惯：项目定义文档不要超过 20 页。如果写得太厚，没人会认真看。关键是让所有相关方签字确认——签字意味着「我同意这个边界，后面别找我扯皮」。