第2章相关项定义

第2章：相关项定义：Item Definition、功能边界、系统边界、运行场景与模式

好，咱们接着聊。上一章我们把HARA的整体框架搭起来了，这一章要落地了——相关项定义。说白了，就是搞清楚你到底要分析什么东西。

我见过不少新手，上来就急着找危险，结果连分析对象都没界定清楚。嗯，这就像你要修车，却连修哪辆车都没搞明白。所以，咱们先把「相关项」这个概念吃透。

相关项，就是你要实施功能安全活动的那个系统或功能集合。它可以是ECU、传感器、执行器，也可以是某个软件功能模块。

我个人习惯把相关项想象成一个「黑盒子」——我关心它的输入、输出、以及它对外界的影响。至于盒子里面怎么实现的，那是后面设计阶段的事。

关键点：相关项不是随便划的。它必须是一个可独立分析的功能单元。你想想看，如果边界划得太小，分析会漏掉交互风险；划得太大，分析又变得臃肿难控。

举个例子。我在做EPS（电动助力转向）项目时，相关项的定义就包含了：扭矩传感器、电机控制器、助力电机、以及它们之间的通信链路。为什么？因为这些组件共同实现了「提供转向助力」这个安全功能。

功能边界，就是回答一个问题：这个相关项到底负责做什么，不做什么？

我建议你用一句话来描述核心功能。比如：

边界定义不清，后面HARA分析就会出大问题。我曾经遇到一个项目，团队把「自动紧急制动」和「自适应巡航」放在同一个相关项里分析。结果呢？危险事件分析时，两个功能的失效模式混在一起，根本理不清。最后不得不拆开重做，浪费了两周时间。

我的小技巧：定义功能边界时，画一张简单的功能框图。把相关项放在中间，左边是输入（传感器、用户操作），右边是输出（执行器、显示），上面是外部系统（其他ECU、云端），下面是供电和通信。这张图能帮你一眼看出边界在哪。

系统边界比功能边界更「物理」一些。它关注的是：相关项在硬件和软件层面，跟外部世界怎么连接？

你需要明确：

这里有个坑，我提醒一下。很多人只关注「正常情况」下的边界，忽略了故障情况。比如，CAN总线断了怎么办？电源掉电了怎么办？这些都要在系统边界定义里说清楚。

注意：系统边界定义时，一定要考虑「相关项之外的假设」。比如，你假设供电系统是ASIL B的，那这个假设就要写进边界文档里。否则，后面安全分析时，别人会以为你考虑了供电故障，其实你没有。

这是HARA分析里最容易遗漏的部分。运行场景和模式，决定了你的危险事件在什么条件下发生。

我把它分成两个维度：

场景描述的是「车辆在什么环境下运行」。比如：

你想想看，同样是「转向助力突然丢失」，在高速上和在停车场里，危险程度能一样吗？所以，场景必须细化。

模式描述的是「相关项本身处于什么工作状态」。常见的有：

我记得有个项目，团队只分析了「正常激活模式」下的危险。结果呢？系统在降级模式下，某个传感器信号被屏蔽了，导致安全功能误触发。嗯，这就是模式没分析全的教训。

实战建议：做运行场景和模式分析时，我习惯用一张「场景-模式矩阵」。行是场景，列是模式，交叉点就是你要分析的工况。这样不会漏，也方便评审时跟别人对齐。

好了，说了这么多，最后咱们看看这一章要产出什么。一份完整的相关项定义文档，至少包含：

这一章的内容，说白了就是给HARA分析「画个圈」。圈画好了，后面的分析才能有的放矢。圈画歪了，后面全是白干。

下一章，咱们就要在这个圈里，开始识别危险事件了。到时候你会发现，今天定义得越清楚，明天分析起来就越顺手。