2.1 标准全景与术语体系

第1章从哥德尔走到alpha粒子，给了你一套思考功能安全的哲学框架。但工程师最终需要面对的不是哲学命题，是标准条款。

你终于下定决心，从ISO官网把ISO 26262:2018全部12个Part下载下来了。12个PDF文件整整齐齐地排列在你的桌面上，像12扇紧闭的大门。你深吸一口气，双击了Part 1。

五分钟之后，你发现自己迷失在“item“、“element”、“fault”、“error”、“failure”、“hazard”、“hazardous event“这些术语的迷宫之中。每一个词的定义都引用了另一个词，像俄罗斯套娃一样层层嵌套。你翻开Part 3想看看HARA怎么做，却发现它引用Part 1的术语、依赖Part 2的管理流程、牵涉Part 9的ASIL裁剪。你看到的不是一篇独立的文档，而是一张巨大的蛛网上的一个节点。

这就是ISO 26262给每个新手的“下马威“：它不是一本可以从头读到尾的教材，而是一座需要你先理解整体架构才能进入的城市。

一座城：12个区

让我们把ISO 26262:2018想象成一座免疫之城。这座城市的12个区不是线性排列的，而是一个立体的V形结构：左边是“设计左侧“，右边是“验证右侧“，底部是共同的支撑。

Part 1：词典（词汇表）。这是城市的语言中心。所有其他区使用的术语都在这里定义。没有它，你在其他区寸步难行。它定义了什么是item、什么是element、什么是危害。就像免疫系统的“细胞识别手册“，T细胞必须先知道什么是“自体“、什么是“非自体“才能发挥作用。

Part 2：市政厅（功能安全管理）：城的管理中枢。它告诉你谁来负责安全、谁有签字权、安全文化如何建立、安全计划如何制定。就像免疫系统的“中枢调控“：没有管理，再多的免疫细胞也只是散兵游勇。

Part 3：侦察营（概念阶段）。这是安全活动的起点。HARA（危害分析与风险评估）在这里完成，安全目标在这里定义，功能安全概念在这里构思。相当于免疫系统的“病原体识别“阶段。你首先要搞清楚敌人是谁、多危险、从哪来。

Part 4：城墙防御（系统级产品开发）：系统架构设计、技术安全概念、安全机制集成在这里完成。就像城墙、护城河、瞭望塔共同构成的物理防线。系统集成测试也在这一部分展开，相当于防御工事的验收。

Part 5：细胞防御（硬件级产品开发）：硬件安全需求、硬件设计、硬件架构度量（SPFM/LFM）、随机硬件失效概率度量（PMHF）都在这里。这是免疫系统中最微观的层面：单个细胞如何抵御病原入侵。α粒子翻转一个SRAM位？这是细胞层面的“感染“，需要硬件机制来检测和修复。

Part 6：信号通路（软件级产品开发）：软件安全需求、软件架构设计、软件单元设计与实现、软件测试。软件是硬件之上的逻辑层，就像免疫信号通路：细胞因子的传递、信号级联反应。一个软件bug就像一条错误的信号：巨噬细胞本应吞噬病原体，却收到了“别动，这是朋友“的错误指令。

Part 7：出厂检验（生产、运行、服务和报废）：安全相关的生产流程、运行阶段的监控、维修后的安全保障、报废的安全要求。就像新生儿从母体出生后，免疫系统要在现实世界中经受考验。生产中的偏差可能让“合格的免疫系统“变成“看似正常的缺陷品“。

Part 8：后勤支援（支持过程）：贯穿整个安全生命周期的支持活动：接口管理、配置管理、变更管理、文档管理、软件工具鉴定。相当于免疫系统的“后勤保障“：骨髓持续造血、淋巴结维持免疫记忆。

Part 9：分级系统（ASIL导向与安全导向分析）：ASIL的分解、安全分析的裁剪规则、相关失效分析。这是“免疫响应的强度调节“：有些威胁需要全身动员（ASIL D），有些只需要局部防御（ASIL B）。

Part 10：旅行指南（指南）。它不是规范性要求，而是对Part 2-9的补充解释和示例。相当于“免疫之城旅游手册“：告诉你别人是怎么做的、常见误区有哪些。

Part 11：半导体专项（半导体指南）：针对半导体的特殊考虑：数字组件、模拟组件、存储器、传感器。放到免疫比喻中，这是“特定细胞类型的防御策略“：神经元和肝细胞面临的威胁不同，防御机制也不同。

Part 12：摩托车专项：ISO 26262原本只针对3.5吨以下乘用车，Part 12将其适配到摩托车。免疫原理相同，但“宿主“不同，防御策略需要调整。

V模型：免疫响应的两个阶段

ISO 26262的V模型是一个贯穿全书的核心结构。V的左臂代表“你要求的“（specification/design），右臂代表“你证明的“（verification/validation）。

想象免疫系统面对一种新型病毒：

左臂（向下）：识别与规划

1. 首先，免疫系统需要识别入侵者。这是“概念阶段“，也就是HARA。你要回答：敌人是谁（hazard identification）？威胁多大（severity）？传播多广（exposure）？我们能不能控制（controllability）？
2. 然后，制定防御策略。这是“功能安全概念“。宏观层面：我们需要中和抗体、激活T细胞。对应到汽车：我们需要“当检测到转向异常时进入安全状态“。
3. 接下来，将策略分解到器官层面：“系统级设计”。皮肤提供物理屏障，淋巴系统负责运输免疫细胞。对应到汽车：制动系统的架构设计、冗余方案、安全机制分配。
4. 再往下，分配到细胞和分子层面：“硬件级设计“和“软件级设计”。对应到具体的ECU硬件电路和嵌入式软件。

右臂（向上）：验证与确认

1. 最底层验证：“软件单元测试“和“硬件模块测试”。就像体外实验：这个抗体真的能结合病毒蛋白吗？
2. 集成验证：“软硬件集成测试“和“系统集成测试”。就像动物实验：整个免疫系统在活体中能否正常工作？
3. 整车验证。“整车集成与测试”。就像临床试验：在实际驾驶场景中，所有安全机制协同工作是否达到预期？
4. 最终确认：“安全确认“和“功能安全评估”。就像FDA批准：基于全部证据，我们确信这个系统是安全的。

V模型的美在于“追溯性“。右臂的每一项测试都必须回溯到左臂对应的需求。你不能说“我测过了“就完事。你必须证明你测的就是你当初要求的东西。免疫学同理：你不能说“我注射了疫苗“，你必须证明“接种者体内产生了针对特定病毒的有效抗体“。

安全生命周期：从诞生到退役

ISO 26262的安全生命周期覆盖了一个汽车电子系统的完整生命，划分为五个阶段：

1. 概念阶段：你做HARA、定义安全目标、构思功能安全概念。相当于胚胎发育期，免疫系统的基本架构在此奠定。
2. 产品开发阶段：系统/硬件/软件设计、实现、集成、测试。相当于免疫系统在个体出生后的成熟过程：遇到各种抗原，建立免疫记忆库。
3. 生产阶段：安全相关的生产过程控制。相当于确保每一个“新生儿“的免疫系统都符合设计：生产偏差可能导致某些人的免疫系统先天缺陷。
4. 运行阶段：车辆上路后的持续安全监控。相当于免疫系统在日常生活中的持续运转：遭遇新的病原体、修复日常损伤。
5. 报废阶段：车辆报废时的安全要求。相当于个体死亡：但“群体免疫“（车型的泛化安全数据）继续存留。

这五个阶段不是一次性的，而是一个循环。因为实际开发中会有变更：需求变了、设计改了、发现了新的失效模式：每一次变更都会触发安全生命周期的重新评估。就像你的免疫系统不是一成不变的：每一次感染、每一次疫苗接种都在更新你的“安全档案“。

术语体系：免疫之城的基础语法

理解了城市布局，我们来学习它的基础语法。以下术语是你在整个ISO 26262体系中会反复遇到的。我刻意用免疫系统的角度来帮你建立直觉。

Item（相关项）——器官

定义：实现车辆层面功能的一个系统或一组系统。

你的心脏是一个item。你的制动系统是一个item。你的EPS（电动助力转向）是一个item。一个item可以独立实现一个车辆级功能，比如“提供转向辅助力“。

在执行HARA时，你首先要定义item的边界：什么属于这个item？什么不属于？它的输入是什么？输出是什么？它与外部环境（其他ECU、驾驶员、道路）如何交互？

这就像你研究心脏时，需要定义：心脏包括左心室、右心室、瓣膜（属于item），但不包括肺（虽然它们紧密关联）。血液是输入/输出。神经信号是外部控制输入。

Element（要素/元素）——细胞

定义：item的组成单元。一个传感器、一个微控制器、一个软件模块、一个通信总线：都可以是element。

心脏由心肌细胞、传导细胞、内皮细胞构成。一个EPS系统由扭矩传感器、MCU、MOSFET功率桥、电机、CAN收发器构成。

Element是可以被独立开发和测试的最小单元。安全需求最终要分解到element层面。

Fault（故障）——感染

定义：可能引起item/element失效的异常条件。

α粒子轰击SRAM存储单元是一个fault。焊点老化开裂是一个fault。温度过高导致参数漂移是一个fault。

Fault是“物理源头的异常“，它不一定会立即产生可观测的后果。就像你吸入了一个流感病毒：病毒进入了你的呼吸道黏膜细胞。这是一个fault。但此时你可能没有任何症状，甚至免疫系统可能在fault层面就清除了威胁。

Error（错误）——症状

定义：计算值/观测值与真实值之间的偏差。

SRAM中存储的扭矩值本来应该是“3.5Nm“，α粒子翻转了一个bit，变成了“35.5Nm“。这是一个error。CAN总线上因为噪声导致CRC校验不匹配。这也是一个error。

Error是fault的“表现“，但仍然是系统内部的状态异常。就像病毒在细胞内开始复制：你体内的病毒载量正在上升。这是error。但你可能仍然没有主观症状。

关键区别：fault是原因，error是fault的表现。一个fault可能导致多个error，一个error可能由多个fault引起，error可能在没有fault的情况下由外部干扰直接产生。

Failure（失效）——器官功能丧失

定义：由于fault的显现，item/element终止了其预期的行为。

当扭矩传感器输出持续错误，EPS系统无法提供正确的转向辅助。这是failure。当制动ECU的CAN通信中断超过一定时间，整车失去制动助力。这是failure。

Failure是error积累到一定程度的“质变“。它是可被外部观测到的功能丧失。就像病毒复制到足够多，免疫系统开始产生全身反应：你发烧了、乏力了、无法正常工作了。这是failure。

Hazard（危害）——对宿主的威胁

定义：由 malfunctioning behaviour（故障行为）引起的潜在伤害源。

这里有一个极易混淆的陷阱，你必须牢记：hazard的定义必须发生在车辆层面，而不是系统层面。你要说的是：

• ✅ “在高速行驶中，意外的前轮转向导致车辆偏离车道”（hazard在车辆层面）
• ❌ “EPS扭矩传感器输出错误”（这不是hazard，这是malfunctioning behaviour/failure）

再强调一遍：HARA中的hazard定义必须是“对车辆乘员或交通参与者的潜在伤害“，而不是“对ECU的功能偏差“。这个区分是HARA中最核心的思维转换。

如果把人体比作车辆，hazard就是“病毒从鼻腔进入下呼吸道并扩散到肺部“。这是对人体的威胁。而“鼻腔黏膜上皮细胞的ACE2受体被病毒结合“是fault/error层面的问题。

Hazardous Event（危害事件）——具体场景中的威胁

定义：hazard与operational situation的组合。

同一个hazard在不同场景中的危害程度天差地别：

• 意外转向 + 高速公路120km/h雨天 → 致命威胁
• 意外转向 + 地库5km/h直行 → 剐蹭风险
• 意外转向 + 车辆静止维修中 → 夹伤维修工

这就是为什么要引入hazardous event。你不能脱离场景谈危害。就像同一种病毒，对一个免疫力低下的老年人和对一个健康的年轻人，威胁完全不同。

Safety Goal（安全目标）——免疫系统的核心任务

定义：从HARA中得出的、位于车辆层面的顶层安全需求。

安全目标不是技术方案。它是功能目标，不管你怎么实现它。

例如：“防止意外转向导致的非驾驶员预期的车辆横向偏移。”

注意，这个安全目标没有提到“扭矩传感器冗余“、“CAN信号超时监控”、“电机角度校验”。这些是技术安全需求（TSR），是你在Part 4里推导出来的，不是安全目标本身。安全目标停留在“要防止什么危害“的层面。

FTTI（故障容错时间间隔）——从感染到死亡的时间窗口

定义：无安全机制的系统中，从fault发生到可能出现hazardous event的最小时间跨度。

换算到免疫系统：从病毒进入呼吸道细胞到病毒性肺炎导致呼吸衰竭，在没有治疗（安全机制）的前提下，最小需要多长时间？这就是FTTI。

FTTI是一个系统固有属性，不由你的设计决定。它是危害事件物理过程的固有时间。比如：转向机架从正常位置打到底盘偏转极限最多需要200ms → 你的FTTI就是200ms级。制动液从储液罐漏光再加上制动失效可能持续数十秒 → FTTI在秒到分级。

FTTI是你设计安全机制的硬性截止时间：所有故障检测+故障响应必须在FTTI之内完成。

FHTI（故障处理时间间隔）= FDTI + FRTI

• FDTI（故障检测时间间隔）：从fault发生到被检测到的时间。用于故障检测机制的时隙。
• FRTI（故障响应时间间隔）：从故障检测到系统进入安全状态的时间。实现安全状态迁移所需的时间。

你必须保证：FDTI + FRTI < FTTI。否则当你的安全机制反应过来时，hazardous event已经发生了。

免疫系统类比：FDTI是免疫系统识别病原体的时间（从病毒进入细胞到树突状细胞呈递抗原）。FRTI是免疫系统发起攻击的时间（从T细胞激活到产生足够中和抗体）。FTTI是“从感染到多器官衰竭“的最小时间。如果FDTI + FRTI > FTTI，病人已经进ICU了，你的免疫响应才姗姗来迟：来不及了。

Fault → Error → Failure → Hazard 链：一个真实案例

让我们把抽象的术语链具象化。考虑一个真实的物理机制：

1. Fault：一个高能α粒子（来自芯片封装材料中的微量放射性杂质）击中SRAM单元的存储节点，导致电荷泄放，存储的bit从“1“翻转为“0“。

2. Error：这个翻转的bit恰好是CAN报文数据场中扭矩值的高位：原本代表“0x000C“（12，对应12Nm的转向扭矩需求），翻转为“0x800C“（32780，大得离谱的值）。于是你的系统认为驾驶员正疯狂地向右打方向盘。

3. Error propagates：这个错误的扭矩值通过软件处理后被填入CAN数据帧，加上看似正确的CRC（根据错误数据计算），发送到CAN总线上。EPS控制器收到后，认为驾驶员需要强大的转向辅助……向电动机输出大电流。

4. Failure：EPS系统根据错误数据向转向柱施加了远超驾驶员预期的扭矩。转向齿条开始移动。方向盘在没有驾驶员输入的情况下自己转动。EPS系统终止了其预期的行为：“按驾驶员意图提供辅助扭矩”。

5. Hazard：车辆产生“非驾驶员预期的横向偏移“。在高速公路上，这可能导致车辆偏离当前车道。

6. Hazardous Event：如果这发生在高速公路上、雨天、时速120km、旁边车道有大型货车。这就是S3（生命威胁，生存不确定）+ E4（高速行驶高频率）+ C3（极少驾驶员能控制意外转向）→ ASIL D级别的危害事件。

整个链条从一个α粒子开始，终止于潜在的致命车祸。而你的安全机制必须在FTTI之内打断这个链条的任何一个环节：比如ECC内存保护（在fault→error处打断）、端到端CAN通信保护（在error→failure处打断）、冗余扭矩传感器交叉校验（在failure→hazard处打断）。

免疫系统全景映射

现在，让我们把所有术语映射到免疫系统的完整画面：

Item-Element 层次结构

ISO 26262定义了一个明确的层次结构，用于将车辆功能逐步分解到最小的可开发单元。每往下一层，你的安全需求也需要相应细化。

Vehicle → Item → System → Component → Hardware Part → HW Subpart → HW Elementary Subpart

示例：
车辆
 └── 转向功能（Item）
       ├── EPS控制器（System）
       │    ├── MCU（Component）
       │    │    ├── Cortex-R5F Core（Hardware Part）
       │    │    │    └── FPU（HW Subpart）
       │    │    │          └── 加法器（HW Elementary Subpart）
       │    │    └── SRAM（Hardware Part）
       │    │          └── 存储单元（HW Elementary Subpart）
       │    └── CAN收发器（Component）
       └── 转向电机（System）
            ├── 位置传感器（Component）
            └── 电机绕组（Component）

这个层次结构的意义在于：当你在做硬件架构度量时（Part 5），你需要把安全机制分配到正确的层级。一个在HW Elementary Subpart层级的fault（α粒子翻转SRAM bit），可以由Hardware Part层级的ECC保护。如果ECC失效，可以由System层级的端到端保护兜底。这就是“分层防御“原则，完全对应免疫系统的“皮肤屏障→固有免疫→适应性免疫“三层防线。

车辆层面：不要陷在ECU的盒子里

ISO 26262反复强调两个关键概念：vehicle function（车辆功能）和vehicle operating state（车辆运行状态）。这两个概念是连接“系统工程师的思维“和“功能安全工程师的思维“的桥梁。

车辆功能不是某个ECU的功能。EPS提供转向辅助是“系统功能“。“车辆转向“才是车辆功能。“车辆制动“是车辆功能，“ESC液压调节“是系统功能。“车辆加速“是车辆功能，“发动机扭矩控制“是系统功能。

当你在做HARA时，你必须把你的思维从“我的ECU在做什么“切换到“这辆车在做什么“。因为驾驶员感知到的是车辆行为，不是ECU行为。一个驾驶员不会说“我的EPS的PWM占空比异常了“。他会说“方向盘自己动了“或者“车不听使唤了“。

车辆运行状态包括：静止、低速行驶、高速行驶、倒车、转弯、制动、加速、滑行、坡道驻车、维修模式、碰撞状态。每一种运行状态对应不同的风险轮廓：同一功能的失效在“高速转弯“和“静止维修“中是完全不同的两个问题。

Item定义的实战要点

除了边界和接口，Item定义中你必须回答的几个关键问题：

这个item有哪些工作模式？ 比如EPS：正常辅助模式、故障降级模式（limp-home）、停车辅助模式、维修/诊断模式。每个模式下的功能范围不同，malfunctioning behaviour也不同。你必须为每种模式分别做HARA。

这个item对哪些外部信号有依赖？ EPS依赖车速信号（决定助力曲线）、发动机转速信号、ESC状态信号。如果这些外部信号错误（不是因为EPS自己的故障，而是因为提供这些信号的其他ECU故障），EPS必须能检测并做出安全的响应。但你要注意：HARA中你评估的是“这个item的故障行为引起的危害“：外部信号故障对你的item的影响，你需要在功能安全概念中定义检测和响应机制，但external item的故障的HARA是那个item自己的责任。

这个item是否与其他item共享任何硬件资源？ 比如EPS和ESC共享同一个CAN网络？共享同一个电源域？如果共享资源。你需要在后续的相关失效分析（Part 9, DFA）中评估共享资源失效对两个item的共因影响。

安全档案：免疫接种记录

ISO 26262要求你最终构建一个“safety case“（安全档案）：一份完整的论证，证明你的系统对于所有已识别的危害都是足够安全的。

安全档案就像一份免疫接种记录+体检报告+基因测序报告的合订本：你不能只说“我们打了疫苗“：你必须提供抗体滴度检测结果、T细胞反应测试、长期跟踪数据。对于汽车同样如此：你不能只说“我们遵循了ISO 26262“。你必须用证据链证明：每一个安全目标都被满足了，每一个失效模式都被覆盖了，每一个安全机制都通过了验证。

安全档案的内容包括但不限于：HARA报告、安全目标清单、功能安全概念、技术安全概念、硬件架构度量报告、软件架构度量、测试报告、安全确认报告、功能安全评估报告。这些工作产品共同构成一个完整的论证体系。

本篇小结

1. ISO 26262:2018的12个Part分别做什么，它们之间的依赖关系
2. V模型如何将设计活动和验证活动对应起来
3. 安全生命周期的五个阶段
4. Fault → Error → Failure → Hazard 的因果链
5. Hazard必须定义在车辆层面
6. FTTI是安全机制的硬性截止时间
7. 安全档案是一份论证，不是一份清单

【下集预告】： 你刚认识了一座12区的城市，但城市需要治理规则。下一节走进Part 2（功能安全管理），回答一个灵魂拷问：当项目经理说“跳过安全评审先交样件“时，谁有权说“不“？更重要的是，为什么安全经理和项目经理必须是两个人？如果签字权没有独立性，安全文化就只是墙上的标语。