4、系统定义与功能描述：定义系统功能边界、描述预期功能与非预期功能、识别系统运行场景
好，咱们进入第四讲。
说实话，系统定义这一步，是整个预期功能安全管理体系里最容易被低估的环节。很多人觉得「不就是写写功能嘛」，结果做到一半发现边界模糊、场景遗漏，回头再补，成本翻倍。我自己的经验是：这一步花多少时间，后面就省多少时间。
4.1 定义系统功能边界
什么叫功能边界？说白了，就是你的系统「管到哪，不管到哪」。
举个例子。你做一个自动紧急制动系统（AEB）。它的功能边界包括：
- 能检测什么目标？车辆、行人、自行车？动物呢？
- 速度范围是多少？0-80 km/h 还是全速域？
- 天气条件？雨雪天是否降级？
- 与其它系统的交互？比如是否受 ESP 状态影响？
我在项目中遇到过一件事：一个团队定义 AEB 时没写「不支持倒车场景」。结果测试时，倒车时触发了紧急制动，差点把测试员甩出去。嗯，这就是边界没划清楚。
边界定义的核心原则：
- 明确「包含」与「排除」：哪些场景是系统设计的，哪些不是
- 定义接口边界：系统与外部（传感器、执行器、人机交互）的交互点
- 定义性能边界：速度、距离、光照、温度等参数的上下限
- 定义状态边界：系统在什么状态下启用/禁用/降级
你想想看，如果边界没定义清楚，后面做危害分析和风险评估时，你根本不知道哪些场景该分析、哪些不该。我曾经见过一个项目，因为没定义「系统在隧道内是否工作」，导致危害分析漏掉了一个关键场景——隧道出口的强光切换。结果呢？路试时出了险情。
4.2 描述预期功能与非预期功能
这里有个容易混淆的点：预期功能和非预期功能到底怎么区分？
我个人的理解是这样的：
- 预期功能：系统设计时「打算」实现的功能。比如 AEB 的「检测前方车辆并制动」。
- 非预期功能：系统在特定场景下「意外」表现出来的行为。比如 AEB 把路边的金属广告牌误识别为车辆，然后急刹车。
注意，非预期功能不等于「故障」。故障是硬件坏了、软件崩了。非预期功能是系统本身没坏，但它的行为超出了用户的合理预期。这是预期功能安全（SOTIF）的核心关注点。
一个小技巧：描述预期功能时，用「系统应该...」；描述非预期功能时，用「系统可能...但用户不期望...」。
比如：
- 预期：系统应该在光照充足时正确识别行人
- 非预期：系统可能在强逆光下漏检行人，导致未制动
我记得有一次评审，一个工程师说「我们的系统没有非预期功能」。我当时就笑了——没有非预期功能，说明你还没找到它。非预期功能不是 bug，它是系统在复杂场景下的「认知盲区」。你越早识别出来，越早能通过设计或验证去覆盖它。
4.3 识别系统运行场景
场景识别，说白了就是回答一个问题：这车会在什么情况下用？
场景可以拆成几个维度：
| 维度 | 示例 |
|---|---|
| 道路类型 | 高速公路、城市道路、乡村道路、隧道、桥梁 |
| 天气条件 | 晴天、雨天、雪天、雾天、强逆光、夜间 |
| 交通参与者 | 车辆、行人、自行车、动物、施工区域 |
| 车辆状态 | 直行、转弯、变道、上下坡、静止起步 |
| 系统状态 | 正常、降级、故障、初始化、休眠 |
这里我建议用场景矩阵来做。把每个维度列出来，然后组合。比如：
- 场景 A：城市道路 + 雨天 + 行人横穿 + 直行
- 场景 B：高速公路 + 夜间 + 前车急刹 + 变道
- 场景 C：隧道出口 + 强光切换 + 前方静止车辆
避坑指南：我曾经见过一个团队，场景识别只做了「正常驾驶」场景。结果呢？系统在「车辆刚启动、传感器还在自检」时，误报了障碍物。这就是没考虑「系统状态」这个维度。记住：场景不是越多越好，而是越全越好。特别是边界场景和极端场景，往往是事故的高发区。
4.4 知识体系框架图
下面我用一张 SVG 图来总结本章的核心逻辑。你可以把它当作一个检查清单，做系统定义时对着看，不容易漏。
这张图你看懂了吗？三个分支其实是递进关系：先划边界，再描述功能，最后放到场景里去验证。缺一个，后面都会出问题。
本章小结：
- 功能边界要写清楚「管到哪、不管到哪」，别留模糊地带
- 预期功能是设计意图，非预期功能是意外行为——两者都要描述
- 场景识别要覆盖道路、天气、参与者、车辆状态等多个维度
- 边界场景和极端场景是事故高发区，别漏
嗯，这一讲就到这里。系统定义做好了，后面做危害分析和风险评估时，你才会心里有底。否则，你就是在沙子上盖楼。
公众号:蓝海资料掘金营，微信deep3321