第2章：相关项定义（Item Definition）——Item是什么、边界怎么划、功能与架构怎么初步识别

好，咱们进入功能安全概念阶段的第二步——相关项定义。

说实话，很多工程师一上来就急着做HARA（危害分析与风险评估），结果做到一半发现“哎？我这个系统到底管到哪？隔壁那个模块算不算我的？”——这就是Item定义没做清楚。我见过不止一个项目，因为Item边界没划明白，导致后期安全分析反复返工，浪费了好几周。

所以这一章，咱们把Item定义这件事彻底聊透。

2.1 到底什么是Item？

ISO 26262里对Item的定义很简洁：实现一个或多个功能的一组系统或组件。

但实际项目中，Item到底是什么？我个人的理解是——它是你进行功能安全分析的“最小独立单元”。你所有的安全活动，从HARA到安全需求，再到验证确认，都是围绕这个Item展开的。

举个例子：

• 一个EPS（电动助力转向）系统——可以是一个Item
• 一个BMS（电池管理系统）——可以是一个Item
• 一个ADAS摄像头模组——也可以是一个Item

但注意，Item不一定是单个ECU。它可以是多个ECU组成的系统，比如“自动紧急制动系统”可能包含摄像头、雷达、制动控制器——它们合起来算一个Item。

2.2 Item边界定义——划清楚你的“地盘”

Item边界定义，说白了就是回答三个问题：

1. 这个Item包含哪些硬件和软件？
2. 它和外部系统怎么交互？
3. 它的物理和功能边界在哪？

我记得有一次做某个线控制动项目，团队一开始把Item定义成了“制动踏板+制动控制器+执行器”。结果分析到一半发现，制动控制器和ESP（电子稳定程序）共用了一个传感器信号——这个传感器到底算谁的？

后来我们重新划边界，把传感器也纳入了Item，或者明确它是“假设条件”——即假设传感器是可信的，但要在接口协议里写明。这就是边界定义要干的事。

边界定义的核心要素

要素	说明	常见坑点
功能边界	Item实现哪些功能？不实现哪些？	功能重叠或遗漏
物理边界	哪些硬件属于Item？哪些不属于？	共享资源归属不清
接口边界	信号、总线、电源、机械接口	接口假设未文档化
假设条件	依赖外部系统提供什么？	假设不成立导致安全目标失效

2.3 功能与系统架构的初步识别

Item定义不是光画个框就完事了。你还需要初步识别这个Item的功能和系统架构。

注意我说的是“初步识别”——不是让你把架构设计做完，而是让你搞清楚：

• 这个Item有哪些主要功能？
• 这些功能大致由哪些子系统或组件实现？
• 它们之间怎么交互？

这一步是为后面的HARA打基础。你想想看，如果你连Item有哪些功能都不知道，你怎么分析危害？

功能识别的方法

我个人习惯用功能列表+功能树的方式：

1. 先列出Item的所有用户可见功能（比如“提供转向助力”）
2. 再分解为技术功能（比如“根据车速计算助力扭矩”）
3. 最后标注功能间的依赖关系

举个例子，一个EPS系统的功能初步识别：

功能层级	功能名称	说明
用户功能	提供转向助力	根据驾驶员转向输入提供辅助扭矩
技术功能	扭矩传感器信号采集	采集驾驶员施加的转向扭矩
技术功能	车速信号获取	从CAN总线获取当前车速
技术功能	助力扭矩计算	根据扭矩和车速查表计算助力值
技术功能	电机驱动控制	控制电机输出目标扭矩

系统架构初步识别

架构初步识别不需要画到信号级，但至少要画出主要组件和它们之间的连接关系。我一般用框图来表达：

下面这张图展示了一个典型的EPS系统在Item定义阶段的初步架构识别：

2.4 Item定义的输出物

这一阶段做完，你应该能拿出以下东西：

• Item定义文档：包含Item名称、版本、范围、边界、假设条件
• 功能列表：初步的功能清单，至少到技术功能层级
• 系统架构框图：主要组件和接口关系
• 接口清单：与外部系统的信号、协议、物理接口

2.5 常见问题与避坑

最后，我总结几个实际项目中经常遇到的问题：

问题	后果	建议
Item边界划得太小	遗漏关键交互，安全分析不完整	宁可大一点，后期再拆分
Item边界划得太大	分析复杂度爆炸，难以管理	按功能独立性拆分
假设条件没写清楚	安全目标依赖不存在的条件	每条假设都要可验证
功能识别不全	HARA遗漏危害场景	多找几个 stakeholder 评审

嗯，这一章的内容就到这。Item定义看起来简单，但它是整个功能安全活动的基石。划清楚边界，后面的路才好走。