2、相关项定义（Item Definition）：什么是相关项、相关项边界与接口、功能清单与初步架构
好，我们进入HARA分析的第二步——相关项定义。这一步说白了，就是搞清楚你手里到底要分析什么东西。
很多新手工程师一上来就急着列危险，结果发现分析到一半，连分析对象都没说清楚。嗯，我当年也犯过这个错。所以今天咱们把这块掰开揉碎了讲。
2.1 什么是相关项（Item）
相关项，英文叫Item。ISO 26262里定义得很清楚：相关项是指实现一个或多个功能的一组系统或组件。
听起来有点绕？我换个说法。你想想看，一辆车上的转向系统、制动系统、动力系统，每个都可以是一个相关项。但有时候，一个相关项可能只是某个ECU里的一个软件模块。
我个人习惯这样判断：只要这个系统或组件能独立完成一个安全相关的功能，它就可以作为一个相关项。
关键点：相关项不是越大越好，也不是越小越好。它要满足两个条件：
- 功能上可独立定义
- 安全目标可独立分配
我在项目中遇到过这样一个案例：一个客户把整个ADAS系统定义为一个相关项，结果HARA分析做了三个月还没做完。后来我们拆成感知、决策、执行三个相关项，效率翻倍。
2.2 相关项边界与接口
定义完相关项，下一步就是画边界。边界是什么？说白了就是你的相关项从哪里开始，到哪里结束。
边界画不好，后面全是坑。我曾经见过一个项目，因为边界没定义清楚，导致两个团队对同一个信号的责任归属扯皮了两个月。
2.2.1 边界定义的原则
- 物理边界：硬件上从哪里分？比如ECU的引脚、传感器的安装位置
- 逻辑边界：功能上从哪里分？比如信号是输入还是输出
- 时间边界：什么时候开始工作？什么时候停止？
2.2.2 接口清单
接口就是相关项和外部世界打交道的地方。我建议你至少列出以下几类：
| 接口类型 | 示例 | 说明 |
|---|---|---|
| 电气接口 | 电源、CAN总线、LIN总线 | 物理连接 |
| 信号接口 | 车速信号、转向角信号 | 数据交互 |
| 机械接口 | 安装支架、连接器 | 物理固定 |
| 人机接口 | 仪表盘显示、报警音 | 与驾驶员交互 |
我的小技巧：画接口图时，用不同颜色区分输入和输出。红色代表输入，绿色代表输出。这样一眼就能看出信号流向。
2.3 功能清单
功能清单，就是把你相关项要干的事一条条列出来。注意，这里列的是功能，不是实现方式。
举个例子：
- ✅ 正确写法：「检测前方障碍物」
- ❌ 错误写法：「使用毫米波雷达检测前方障碍物」
为什么？因为HARA分析关注的是功能失效带来的危害，而不是某个具体传感器坏了。你想想看，如果后面换了摄像头方案，功能清单还得重写，那不是白干了吗？
2.3.1 功能清单模板
我一般用这个模板来列功能清单：
功能ID: F-001
功能名称: 检测前方障碍物
功能描述: 在车辆行驶过程中，实时检测前方200米范围内的障碍物
触发条件: 车辆上电且车速大于0
输出信号: 障碍物距离、障碍物类型
安全相关: 是
注意：不是所有功能都是安全相关的。比如「显示当前时间」这个功能，失效了也不会造成危害。但「显示当前车速」就是安全相关的，因为驾驶员依赖它控制车速。
2.4 初步架构
初步架构，就是把你刚才定义的相关项、边界、接口、功能，画成一个框图。这个框图不需要很详细，但必须能说清楚：
- 相关项内部有哪些主要模块？
- 模块之间怎么通信？
- 外部系统怎么接入？
2.4.1 架构的层次
我个人习惯分三层来画：
- 系统层：相关项与外部系统的关系
- 子系统层：相关项内部的主要模块
- 组件层：每个模块里的关键元器件或软件组件
举个例子，一个电动助力转向系统的初步架构：
系统层：
[驾驶员] ↔ [EPS相关项] ↔ [车辆CAN网络]
子系统层：
[扭矩传感器] → [ECU] → [电机驱动] → [电机]
组件层：
[扭矩传感器]：霍尔传感器、信号调理电路
[ECU]：主控芯片、电源管理、CAN收发器
[电机驱动]：MOSFET驱动、电流检测
[电机]：永磁同步电机、减速机构
2.5 避坑指南
最后，分享几个我踩过的坑：
我曾经犯过的错误：
- 边界画得太宽：把整个EE架构当做一个相关项，结果分析到一半发现工作量爆炸
- 接口遗漏：忘了考虑诊断接口，导致后面做FMEA时发现故障注入路径没覆盖
- 功能清单太细：把每个软件函数都列出来，结果功能清单比代码还长
嗯，说到这里，我想强调一点：相关项定义不是一次性的工作。随着项目推进，你可能会发现边界需要调整，功能需要补充。这很正常，关键是每次变更都要有记录、有评审。
好了，这一章就到这里。下一章我们讲危害识别与风险评估，那才是HARA分析的重头戏。