概念阶段输入:系统定义、系统边界、系统功能清单、运行模式与场景分析
各位工程师朋友,咱们今天聊概念阶段的输入。说白了,就是做功能安全之前,你得先把「你到底要做什么」搞清楚。我见过不少项目,一上来就急着做 HARA,结果做到一半发现系统边界都没画清楚,又得回头改——那叫一个折腾。
系统定义:你到底在造什么?
系统定义不是写个产品名称就完事了。你得把系统的物理架构、逻辑架构、接口关系都摆出来。我个人习惯,先画一张系统框图,把所有的 ECU、传感器、执行器都标上去。
系统定义的核心要素:
- 物理架构:硬件模块、线束、连接器
- 逻辑架构:软件组件、信号流、数据交互
- 外部接口:与其他系统的通信、人机交互
- 供电与通信:电源网络、CAN/LIN/以太网拓扑
举个例子,你做一个电动尾门控制器。系统定义里就要写清楚:电机驱动芯片是哪颗?霍尔传感器装在哪?CAN 总线上的节点 ID 是多少?这些细节,后面做危害分析时全用得上。
我的经验:系统定义文档最好用版本控制。我遇到过项目做到一半,硬件换了颗 MCU,结果安全概念全得重来。要是没有版本记录,你都不知道什么时候改的。
系统边界:哪里是你的地盘?
系统边界决定了你的安全责任范围。边界画得太窄,漏了关键交互;画得太宽,分析工作量翻倍。怎么把握这个度?
我建议用「输入-输出-环境」三要素来界定:
| 边界类型 | 说明 | 示例(电动尾门) |
|---|---|---|
| 输入边界 | 系统接收的信号/能量来源 | 车身 CAN 总线、门开关信号、钥匙遥控信号 |
| 输出边界 | 系统对外部的影响 | 电机驱动电流、位置反馈信号、故障指示灯 |
| 环境边界 | 系统运行的外部条件 | 温度范围 -40°C~85°C、IP5K 防护等级 |
注意:边界定义要写清楚「什么不属于本系统」。我曾经有个项目,客户把线束的保险丝也算到系统里,结果安全分析时发现保险丝选型根本不在我们控制范围内——这就是边界没划清楚。
系统功能清单:把功能掰开揉碎
功能清单不是简单列几个功能名称。你得把每个功能拆到原子级。怎么拆?我一般用「功能树」的方法:
- 顶层功能:用户能感知的功能(如「一键开启尾门」)
- 子功能:实现顶层功能所需的步骤(如「检测门锁状态」「驱动电机」「监测防夹」)
- 基础功能:硬件/软件的最小功能单元(如「读取霍尔传感器」「PWM 输出控制」)
你想想看,如果不拆到基础功能,后面做 FMEA 时根本找不到失效点。我见过有人把「自动泊车」列为一个功能,结果分析时发现失效模式根本没法写——太粗了。
功能清单模板(示例):
功能ID: F-001
功能名称: 一键开启尾门
触发条件: 用户按下尾门开启按钮(长按 2 秒)
系统响应:
1. 检测车辆处于 P 挡
2. 检测尾门锁状态为「锁止」
3. 解锁尾门锁
4. 驱动电机正向旋转
5. 实时监测霍尔传感器脉冲
6. 到达上限位后停止电机
预期行为: 尾门在 8~12 秒内完全开启
安全约束: 防夹功能必须全程激活
运行模式与场景分析:别漏了「万一」
运行模式不是只有「上电-运行-下电」这么简单。你得考虑所有可能的状态组合。我习惯用状态机来建模:
场景分析就更关键了。你得问自己:这车会在什么情况下用?我列几个常见的场景维度:
- 驾驶场景:静止、低速行驶、高速行驶、倒车
- 环境场景:白天/夜晚、晴天/雨天/雪天、高温/低温
- 用户场景:正常操作、误操作、恶意操作、儿童操作
- 故障场景:单点故障、多点故障、通信中断、供电异常
避坑指南:我曾经漏了一个场景——用户在洗车时用高压水枪冲尾门按钮。结果水渗进去导致按钮短路,尾门自动开启了。后来我们在场景分析里加了一条「外部液体侵入」,安全概念里也增加了防水设计和按钮去抖逻辑。
把这些输入串起来
好了,现在你有了系统定义、边界、功能清单、运行模式和场景。这些东西不是孤立的,你得把它们整合成一份「概念阶段输入包」。我一般用这个结构:
| 文档 | 内容 | 输出给谁用 |
|---|---|---|
| 系统定义文档 | 架构图、接口表、供电拓扑 | HARA、系统设计 |
| 边界定义文档 | 输入/输出/环境边界、假设条件 | HARA、FMEA、FTI |
| 功能清单 | 功能树、功能描述、安全约束 | HARA、安全目标定义 |
| 运行模式与场景 | 状态机、场景矩阵、触发条件 | HARA、测试用例设计 |
嗯,这里要注意:这些文档不是写一次就完事了。随着项目推进,你会发现新的场景、新的功能边界。我建议每个迭代都回头看一眼概念阶段的输入,该更新就更新。
最后说一句:概念阶段的输入质量,直接决定了后面所有安全活动的质量。你花一周把系统定义做扎实了,后面省下的时间可能是一个月。别急着赶进度,先把地基打牢。