在功能安全的前期工作里，Item定义该怎么写，Item边界又该怎么去划分，这一步常常容易让人卡住。Item定义并不是给系统写一段普普通通的介绍，也不是把控制器、传感器、执行器都列成一张清单就算完事儿了；它真正要去说明的，是当前要分析的那个车辆功能到底是什么，这个功能需要依赖哪些对象，以及边界内外怎样互相交换信息。

　　一、ISO 26262 Item定义怎么写

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

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

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

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

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

　　在Item定义里面，光写正常运行这一种状态是不够的，像启动、关闭、降级、维修还有车辆静止这些情形，也都应该覆盖进去，因为很多问题并不是在车子平稳行驶的时候发生的，而是在状态切换的那一下子才冒出来的。比方说车辆刚上电的时候，外部的信号可能还没有完全建立好；等到系统进了降级状态以后，功能其实也没有全部退出，只是输出的能力受到了限制。要是这些状态没被写进定义里面，后面的危害场景就容易缺东少西。

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

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

　　处在概念阶段的框图，倒用不着一下子画到软件函数或者硬件引脚那个层面去，可是也不能只搁一个ECU的名称就撒手不管了。比较合适的情形是，读者顺着这张图就能够看清楚信号是从哪儿过来的，中间经过了哪些主要的处理环节，最后又作用到了哪一个对象的头上。外部系统所提供的车速、档位、制动状态这些信号，在图里边也应该把它们的源头保留下来。

　　二、ISO 26262 Item边界怎么划分

　　Item边界这个东西，并不是在框图外面随随便便画上一条线那么简单，线里边的那一坨表示当前Item负责的功能范围，而线外面则表示外部的那些系统、环境、驾驶员，或者是别的Item。边界要是划得太大了，分析起来就会变得很沉很重；可要是划得太小了，一些关键的故障又有可能被挡在外面漏不进来。

　　1、不要直接按照ECU切分

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

　　2、边界外对象也要保留

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

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

　　3、接口关系要写具体

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

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

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

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

　　1、用故障场景反向检查

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

　　2、用HARA输入检查完整性

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

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

　　3、变更后要回看边界

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

　　总结

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