第三章 HARA分析前的准备工作：系统定义、功能定义、边界定义、运行模式定义
各位同学，欢迎来到HARA分析实战的第三讲。
说实话，很多工程师做HARA分析翻车，不是不懂危害分析，而是准备工作没做扎实。我见过太多人上来就对着系统框图一顿猛分析，结果分析到一半发现——哎？这个功能到底归不归我管？那个边界到底算不算？
嗯，今天我们就来聊聊HARA分析前，那四件必须做好的准备工作。
3.1 系统定义：你得先搞清楚你分析的是个啥
系统定义，说白了就是给你的分析对象画个像。你得说清楚：
- 这个系统叫什么？
- 它由哪些部件组成？
- 它跟谁通信？
- 它装在车的哪个位置？
我个人习惯，在做系统定义时，会先画一张系统框图。这张图不需要太细，但必须把外部接口标清楚。
系统定义的核心要素：
- 系统名称与版本号
- 硬件架构（主控芯片、采样芯片、驱动芯片等）
- 软件架构（应用层、底层、通信协议栈）
- 外部接口（CAN、硬线、传感器、执行器）
- 供电方式（12V/24V/48V，是否隔离）
举个例子，我之前做的一个BMS项目，系统定义里就明确写了：
系统名称：BMS主控单元 V2.1
硬件平台：NXP S32K144 + LTC6813
通信接口：CAN 2.0B (500kbps)，隔离型
供电范围：9V~16V DC
工作温度：-40℃ ~ 85℃
防护等级：IP67为什么要写这么细？因为后面做危害分析时，每个接口、每个供电范围都可能成为故障源。你想想看，如果供电范围写的是9V~16V，那16.5V算不算过压？这个边界不清，后面分析全白做。
3.2 功能定义：把“这车能跑”拆成一个个具体动作
功能定义，是HARA分析里最容易出问题的一步。
很多新手会把功能定义写得太笼统。比如“电池管理系统”，这算功能吗？算，但太粗了。你得把它拆成：
- 单体电压采集
- 总电压采集
- 电流采集
- 绝缘检测
- SOC估算
- SOH估算
- 均衡控制
- 热管理
- 故障诊断
- 通信管理
我建议，每个功能都要写清楚：
- 功能名称：比如“单体电压采集”
- 功能描述：采集每个电芯的端电压，精度±5mV
- 触发条件：上电后自动执行，周期100ms
- 预期输出：电压值通过CAN发送给VCU
- 故障表现：采集值偏差、通信超时、采样芯片故障
我的小技巧：
做功能定义时，可以先用功能列表把所有的功能列出来，然后再逐个细化。我曾经在一个项目里，光功能列表就列了47项，最后发现漏了“预充电控制”这个关键功能——嗯，那次的HARA分析白做了，得重来。
3.3 边界定义：画清楚你的“一亩三分地”
边界定义，是HARA分析里最容易被忽略的一步。
你想想看，BMS系统不是孤立存在的。它跟VCU通信，跟充电机交互，跟热管理系统联动。那问题来了：
- VCU发来的错误扭矩请求，算不算BMS的故障？
- 充电机过压导致BMS损坏，这个责任算谁的？
- 热管理系统失效导致电池过热，BMS要不要负责？
边界定义，就是回答这些问题。
边界定义要明确：
- 物理边界：BMS的硬件范围（包括哪些PCB、哪些线束）
- 功能边界：BMS负责哪些功能，不负责哪些功能
- 信息边界：BMS接收哪些信号，发送哪些信号
- 时间边界：BMS的工作时序、响应时间要求
我记得有一次做评审，对方工程师非说“电池热失控”是BMS的责任。我说不对，BMS只能检测温度异常并报警，如果热管理系统没有响应，那是热管理系统的责任。边界不清，后面责任划分全是扯皮。
避坑指南：
我曾经在一个项目里，因为没有明确“通信超时”的边界定义，导致HARA分析时把VCU通信故障也算成了BMS的内部故障。结果ASIL等级定高了，成本翻了一倍。后来重新梳理边界，才发现很多故障根本不在BMS的控制范围内。
3.4 运行模式定义：别让系统“裸奔”
运行模式定义，就是搞清楚系统在什么状态下干活。
BMS不是一直全功率运行的。它有：
- 上电模式：系统初始化，自检
- 待机模式：低压供电，监控唤醒信号
- 工作模式：正常采集、计算、通信
- 充电模式：与充电机交互，监控充电过程
- 故障模式：检测到故障，进入安全状态
- 休眠模式：系统断电，低功耗
每个模式下的功能和安全目标都不一样。比如：
| 运行模式 | 主要功能 | 安全目标 |
|---|---|---|
| 上电模式 | 自检、初始化 | 自检失败不能进入工作模式 |
| 工作模式 | 电压/电流/温度采集 | 采集精度满足要求 |
| 充电模式 | 充电控制、通信 | 过充保护、通信超时处理 |
| 故障模式 | 故障处理、安全状态 | 故障响应时间<100ms |
| 休眠模式 | 低功耗监控 | 唤醒信号有效才能唤醒 |
为什么要分这么细？因为同一个故障，在不同模式下的危害等级可能完全不同。
举个例子：电流传感器故障。在待机模式下，系统不工作，这个故障可能只是个小问题。但在充电模式下，电流传感器故障可能导致过充，那就是严重危害了。
我的经验：
做运行模式定义时，最好画一张状态迁移图。把每个模式之间的切换条件、切换时间都标清楚。我曾经在一个项目里，就是因为没定义清楚“从故障模式恢复到工作模式”的条件，导致系统在故障恢复后直接进入了充电模式——嗯，那次差点出事故。
3.5 准备工作检查清单
好了，四个准备工作讲完了。最后给大家一个检查清单，做HARA分析前，先过一遍：
- 系统定义是否完整？有没有遗漏外部接口？
- 功能定义是否细化到每个具体动作？有没有笼统描述？
- 边界定义是否清晰？哪些是BMS的责任，哪些不是？
- 运行模式定义是否覆盖所有工作状态？状态迁移是否明确？
这四个问题都回答清楚了，HARA分析才能开始。否则，你分析得再漂亮，也是空中楼阁。
下一讲，我们正式进入HARA分析的核心——危害识别与危害事件定义。到时候我会拿一个真实的BMS案例，带大家一步步走完整个流程。
嗯，今天就到这里。有问题随时找我。