在功能安全的前期，Item定义到底该怎么写，Item边界又该怎么去划分，这一步经常让人卡住。Item定义不是给系统写一段普普通通的介绍，更不是把控制器、传感器、执行器拉一张清单就算完事；它真正要去说明的，是当前要分析的那项车辆功能到底是什么，这个功能需要依赖哪些对象，以及边界内外怎样互相交换信息。ISO 26262-3:2018覆盖的是概念阶段，其中包含了Item Definition、危害分析与风险评估、功能安全概念等内容；而ISO 26262这个标准本身关注的，是安全相关电子电气系统因异常行为造成的危害，也包含系统之间交互带来的影响。

　　一、ISO 26262 Item定义怎么写

　　Item这个东西，可以把它看成是功能安全分析的对象，它可能是一个单独的系统，也可能是好几个系统凑在一起才实现的一项车辆级功能。写Item Definition的时候，重点不是把所有的细节都填满，而是要让后面的HARA可以顺着这个范围接着往下分析。

　　1、先把车辆级功能说清楚

　　结合【车辆级功能】、【触发条件】和【功能输出】，说明Item在车辆上到底负责什么。

　　拿电动助力转向系统来举例子，光写一句“提供转向助力”是不够的；更合适的写法，是把驾驶员转动方向盘之后，系统如何接收转矩、转角、车速这些信息，再计算并输出助力的整个过程给讲明白。而且车辆在低速泊车、高速行驶，或者系统故障降级的时候，它的表现也可能不一样，这些功能的过程写清楚了，后面分析助力丢失、助力过大、方向错误时，才会有一个明确的对象。

　　2、运行场景不能只写正常工作

　　在Item定义里面，不能只盯着正常运行这一种状态，像启动、关闭、降级、维修和车辆静止这些情形，也一样要覆盖进去，因为很多问题并不是在车子平稳跑着的时候才发生，而是在状态切换的那个当口冒出来的；比方说车辆刚一上电，外部的信号可能还没有完全建立好，又或者系统进到降级状态之后，功能并没有全部退出，只是输出的能力受到了限制。要是这些状态没有被写进定义，后面的危害场景就容易漏掉。

　　3、功能组成要能看出关系

　　通过【功能框图】标出输入来源、控制单元、执行对象和反馈路径。

　　在概念阶段，这个框图倒用不着画到软件函数或者硬件引脚那个层面去，可也不能只放一个ECU的名字就完事；比较合适的程度是，让读者顺着图就能看出来信号是从哪里进来的，中间经过了哪些主要的处理环节，最后又作用到了哪个对象头上。像外部系统提供的车速、档位、制动状态这些信号，在图里边也应该把它们的来源保留下来。

　　4、假设条件要单独留下

　　在写Item定义的时候，经常会冒出一些暂时还没法完全确认的事情，比如外部的信号可不可靠、驾驶员需不需要去接管、不同车型的配置是不是都一致。这些内容不适合混在正文里一笔带过，最好是把它们单独放进假设或者待确认的条目里去；这样一来，等到后面架构变了、接口改了，或者车型换成另外一款的时候，才能知道哪些内容要回过头来重新检查。

　　二、ISO 26262 Item边界怎么划分

　　Item边界并不是在框图外面随随便便画一条线那么简单，线里面的部分表示当前Item负责的功能范围，线外面的部分则表示外部的系统、环境、驾驶员或者其他Item。边界要是划得太大，分析起来就会变得很重；可要是划得太小，一些关键的故障又可能被排除在外头。

　　1、不要直接按照ECU切分

　　在划分Item边界的时候，应当先去看功能的链路，而不是先盯着控制器的数量；因为一个车辆上的功能，有可能分散在好几个ECU上头，反过来一个ECU也可能同时承担好几样功能。就拿自动紧急制动功能来说，它可能牵扯到环境感知、目标判断、制动请求和制动执行这一连串的环节，当前的Item可以把整条链路都覆盖进去，也可以只覆盖中间的某一段，不过边界以外的部分一定得交代明白。

　　2、边界外对象也要保留

　　绘制【Item边界图】时，应把外部控制器、驾驶员、车辆环境、机械连接和电源输入等对象保留下来。

　　这些对象虽然不属于当前的Item，可它们会影响故障带来的后果；比如驾驶员能不能接手，就会影响到对可控性的判断，车速的高和低会改变危害的程度，外部的信号要是丢失了、延迟了或者出错了，也可能搅乱Item的控制结果。边界外的对象要是不画出来，后面做分析的时候就很容易默认它们一直处在正常的状态里。

　　3、接口关系要写具体

　　对照【接口清单】整理信号方向、数据含义、更新周期、有效范围和异常表现。

　　接口可不单单指CAN、LIN或者以太网这些报文，像电源、接地、机械连接、传感器输入，还有执行器的反馈，都应当算到里面去。跟安全相关的接口，还要去考虑信号超时了怎么办、数值突然跳变了怎么办、范围超出边界了怎么处理，以及反馈丢失这类情形，光写一个接口的名字是不够的，关键是要讲清楚一旦出了异常，系统打算怎么去识别，又打算怎么去处理。

　　4、车型差异不能直接合并

　　同一个功能放到不同车型上，Item的边界不一定就是一模一样的；低配的车型可能少装一个传感器，高配的车型执行器的能力更强，又或者某一个信号换成了另外的来源，这些情况都有可能让故障传播的路径跟着改变。如果差异仅仅是参数上的一些变动，那在适用范围里面做个说明就行了；可要是差异已经牵动了安全分析，那就需要单独去检查一下原先的边界还能不能继续成立。

　　三、Item定义和边界划分怎样保持一致

　　Item定义和边界划分这两个东西是要互相对得上的；定义里面写了某一项功能，边界图里面就应该能看到跟它相关的输入、输出，还有外部的依赖，边界图里保留了某一个接口，接口清单里也得能找到对应的说明。两边要是各写各的，后面的HARA很容易就会冒出范围对不上的问题。

　　1、用故障场景反向检查

　　可以先挑上几类常见的故障试着往里面代入，像功能整个丢失、输出不是预期的、输出的方向反了、响应延迟了这些；拿转向助力来说，助力突然没了、助力过大、助力方向搞反，这几样给车辆带来的影响都是不尽相同的。代入这些场景以后，要是还分不清楚故障到底发生在边界的里面还是外面，那就说明Item的范围还没有被写明白。

　　2、用HARA输入检查完整性

　　对照【运行场景】、【故障行为】和【外部依赖】，检查HARA是否有足够输入。

　　打个比方，Item定义里头要是没有讲清楚车辆会在哪些状态下工作，HARA就很难去判断暴露的概率和可控性；再比如，边界那边要是没把外部信号的来源交代明白，故障行为的描述也容易写得模模糊糊的。Item Definition的价值就体现在这个地方，它不是一篇孤零零的说明文字，而是后面做风险分析时的一项基础输入。

　　3、变更后要回看边界

　　每当系统架构、接口的来源、传感器的数量，或者执行器的能力发生变化的时候，Item的定义和边界都应该重新去检查一次；新增一个传感器，或者换掉某个报文的来源，看起来好像只是个普通的设计变动，可它说不定已经悄悄把故障的传播路径给改掉了。前面的Item范围要是不同步更新，后面的安全目标和安全需求也可能会找不到可以依靠的根据。

　　总结

　　总的说来，Item定义该怎么写，Item边界该怎么划分，关键都是要把车辆级功能、运行场景、内部组成、外部依赖，连同接口的关系给说明白。Item定义负责回答“要分析的东西到底是什么”，边界划分负责回答“分析要到哪里为止”；这两者对齐以后，HARA才能围绕着一个明明白白的对象开展下去，后面的安全目标和安全需求也才更容易落到实际的系统上面去。