1. 为什么功能安全是汽车电子的守护逻辑先从一个我亲历的场景说起。几年前参与一个车身控制器的预研项目测试工程师在实车上模拟了一个极端工况CAN总线被强制切断同时刹车踏板传感器信号漂移。结果控制器直接进入了疯子模式——雨刮疯狂摆动车窗全部降下转向助力突然丢失。虽然这个组合不会让车子立即失控但那一刻所有人的后背都凉了。问题不是出在某个器件坏了而是系统在故障状态下没有一个预设的安全落点。这就是功能安全Functional Safety简称FuSa要解决的核心问题当电子系统发生故障时系统应该做什么、不能做什么、在多长时间内完成响应才能保证不伤害驾乘人员和其他道路使用者。不是防止故障发生而是把故障的后果约束在可接受的范围内。很多人第一反应是功能安全就是冗余设计或者加个监控电路这其实把概念想窄了。冗余只是实现手段之一功能安全是一整套从定义、设计、验证到生产的系统性工程方法。为什么要专门写一篇关于FuSa概念的文章因为这个领域有个尴尬的现象项目里能熟练写出ISO 26262每个Part编号的人不少但真正能把功能安全到底在管什么、概念阶段要产出什么、系统层面怎么做讲清楚的很少。尤其在汽车电子嵌入式开发、电气架构设计、测试验证这几个方向上大量工程师接触过功能安全的词汇却对整套逻辑链条缺乏整体认知。这篇文章定位为系列开篇面向三类人。第一类是刚进入汽车电子领域、准备转行做功能安全的工程师需要先建立正确的思维框架。第二类是已经在做嵌入式开发或测试、工作中必须配合功能安全活动的工程师需要理解自己手头的活在整个流程里处于什么位置。第三类是项目经理或技术管理者需要明白功能安全不是一堆文档游戏而是要贯穿产品全生命周期的硬性约束。我在实际项目中观察到一个规律凡是功能安全做得顺的项目团队里至少有一个人能在一张纸上画出从危害识别到安全需求再到验证确认的完整链路。而做不顺的项目往往是各环节的人只管自己那一亩三分地上游不知道下游要什么下游不知道上游为什么这么定。所以这一篇先把概念阶段和系统层面这条主线讲透后续再逐步拆解硬件、软件、测试、生产等环节。先把地图摊开再谈具体走路。2. 从不炸就行到失效也有序功能安全的底层逻辑很多人把功能安全和被动安全混为一谈。被动安全安全带、气囊、车身吸能结构处理的是已经发生了碰撞怎么减少伤害功能安全处理的是电子系统自身疯掉了怎么保证不发疯或疯得不致命。二者关注的对象完全不同。要理解功能安全必须先抓住一个关键词风险。ISO 26262对功能安全的定义是不存在由电气/电子系统故障导致的不合理风险。这里有三层含义值得拆解。第一层风险来自系统性故障和随机硬件故障两个源头。系统性故障是设计缺陷导致的比如软件逻辑写错了、总线时序设计不合理这类故障一旦发生就会稳定复现随机硬件故障则源于器件的老化、辐射、工艺波动等物理因素不可能完全消除只能通过失效率来量化。功能安全问题大部分发生在随机硬件故障这条线上因为系统性故障理论上可以通过严格的开发流程尽量排除而随机硬件故障是概率问题必须靠架构手段去兜底。第二层不合理风险这个词很关键。不是所有故障都需要处理到同样的安全等级。如果故障发生后驾驶员有充足的时间反应并控制局面这个风险可能就是合理的做基本防护即可但如果故障发生在转向、制动这类直接决定车辆轨迹的系统上风险等级就完全不同了。合理与不合理由后面要讲的ASIL等级来量化。第三层功能安全关注的是功能层面的失效而不是产品质量层面的可靠度。举个例子收音机坏了是质量问题因为不涉及安全但如果收音机的娱乐屏幕出现黑屏同时倒车影像也被强制占用导致后视信息丢失这就上升到功能安全了——因为系统失效影响了安全相关功能。同样一颗芯片、一段代码放在不同位置对功能安全的重要性完全不同。用一句好记的话来概括普通可靠性关心的是这功能多久会坏功能安全关心的是它坏了之后怎么办、在什么时间内办。汽车功能安全的行业标准是ISO 26262脱胎于工业领域的IEC 61508。但汽车领域有个特殊的现实功能安全不是孤立于整车的某个模块的安全而是整车层面的系统性保障。所以ISO 26262特别强调相关项这个概念——它可以是一个完整的车辆级功能如自动紧急制动、一个ECU、或者一个子系统。范围由你定义但一旦定义了边界边界内的所有失效都必须在你的责任范围内被考虑到。3. ISO 26262整体框架一张图看懂12个Part在管什么ISO 26262在2018年的第二版中扩展到了12个Part很多初学者一上来就被这12个Part吓住了。实际上它们之间的逻辑关系非常清晰一句话就能概括前三个Part是规划和概念中间是产品开发后面是支持性和生产运营相关的流程。Part 1术语和Part 2管理是基础层。Part 2规定了功能安全的管理要求包括安全文化、项目计划、安全活动评审、生产发布等。很多人忽略Part 2的重要性但在实际项目中Part 2往往决定了你的安全活动有没有人授权、有没有资源、有没有被记录。没有管理层的支持Part 3到Part 10做得再漂亮也是空转。Part 3是概念阶段这是本文的核心内容之一。它要求从车辆层面出发明确系统的功能边界Item Definition、分析潜在危害HARA、制定功能安全概念FSC并为每条安全目标分配ASIL等级。这一阶段产出的安全目标和功能安全需求是后续所有技术活动的源头。Part 4到Part 6是产品开发阶段分别对应系统层面System level、硬件层面Hardware level和软件层面Software level。这里有个容易混淆的点Part 4系统层面和Part 5硬件、Part 6软件不是串行关系而是嵌套关系——系统层面将需求分别分配给硬件和软件硬件和软件并行开发最终在系统层面完成集成测试和验证。Part 7是生产与运营处理的是安全交付到客户手中之后的环节包括生产过程中的安全相关特性控制、售后阶段的失效响应等。Part 8支持流程、Part 9ASIL导向和安全分析、Part 10ISO 26262指南是贯穿全程的辅助性要求Part 11和Part 12分别是半导体和摩托车的应用指南。这12个Part本质上就是在讲一个完整的故事你打算造一个什么系统概念阶段→ 这个系统怎么设计系统、硬件、软件→ 怎么证明你的设计是对的集成测试、验证、确认→ 怎么保证量产和运行后依然安全生产运营→ 整个过程用哪些通用的方法和工具来支撑支持流程。概念阶段在整个流程中的位置怎么强调都不过分。它做出的每一个决定——安全目标定多高、ASIL是什么等级、采用什么安全机制——都会向下传递并放大到后续所有开发活动中。概念阶段出错后面花十倍百倍的代价都未必能纠正。我在项目里见过最典型的情况是HARA分析时漏了一种暴露场景结果安全目标定低了硬件方案已经选型完成并且投片了评审会议上才发现ASIL等级不满足要求整个项目的芯片被迫换型周期和成本全部失控。4. 概念阶段的三个核心产物Item Definition、HARA与FSC4.1 先定义清楚边界Item Definition相关项定义功能安全的第一步不是分析风险而是明确你在分析谁的风险。这个边界问题就是Item Definition要解决的。你不能笼统地说我在做一个制动系统就完事了必须详细定义这个系统的功能列表有哪些如常规制动、ABS防抱死、ESP车身稳定、自动驻车、它和外部环境有哪些接口传感器信号、执行器、总线、电源、它假设外部世界具备什么条件如驾驶员有正常的反应能力、路面存在附着系数下限、哪些功能不在本系统的管辖范围内。Item Definition做得好不好直接影响后续HARA的覆盖率。如果边界划小了漏掉了某个隐藏接口HARA就覆盖不到该接口失效导致的危害如果边界划大了你会把大量不属于自己的责任拉进来导致安全分析的范围爆炸式膨胀团队精疲力尽。实操层面有个技巧先画出系统上下文图System Context Diagram把系统与外部交互的所有实体列出来再逐个讨论每个交互链路失效后会怎样。这比从头就埋头写需求文档要高效得多。上下文图画完了Item Definition的骨架基本也就出来了。4.2 找到会伤人的失效场景HARA危害分析和风险评估HARA是概念阶段中信息量最大、也最考验经验的活动。它的目标是从整车层面出发找出系统所有可能的危害事件并对每个危害事件的风险程度进行分级。注意这里说的是整车层面而不是系统层面——你要想的是当这个系统失效时在什么驾驶场景下、会造成什么后果而不是这个传感器坏了会输出什么错误值。HARA的标准流程分三步。第一步做情景分析在正常行驶、低速泊车、高速巡航、雨雪天气、夜间行驶等不同场景下系统失效会导致什么情境。第二步做危害识别比如制动系统危害事件可能是车辆意外制动导致后车追尾或制动能力下降导致无法按预期停车。第三步做风险评估用三个参数给每个危害事件打分。三个参数分别是SSeverity严重度如果伤害发生有多严重S0是无伤害S1是轻伤S2是致死或重伤但可存活S3是危及生命或致命伤。EExposure暴露度乘客或道路使用者处于这个危害场景中的概率有多高E0到E4等级越高越常见。CControllability可控性驾驶员或相关人员能否通过及时反应避免伤害C1是可控C2是大部分可控C3是难以控制或不可控。三个参数组合查表就能得到ASIL等级A、B、C、D或QMQuality Management按普通质量管理处理即可。| 严重度S | 暴露度E | 可控性C | ASIL结果 | | S1 | E4 | C3 | ASIL A | | S2 | E4 | C2 | ASIL B | | S3 | E4 | C2 | ASIL C | | S3 | E4 | C1 | ASIL D | | S3 | E3 | C3 | ASIL B | | S2 | E2 | C1 | QM |这个表格是简化示例实际标准里是一个完整的3×5×3的三维矩阵但逻辑完全一致危害越严重、场景越常见、人越难应对安全等级就越高。做HARA时最容易犯的错误是直接在系统层面分析功能。比如你分析ABS模块的轮速传感器信号丢失这是系统层面的事情不是整车层面的危害事件。正确的危害事件应该是车辆在湿滑路面制动时因某轮轮速信号异常导致制动力分配错误引发车辆侧滑。同一个底层故障在不同的驾驶场景下会有完全不同的风险等级这正是HARA的粒度要求。4.3 把安全目标翻译成功能需求FSC功能安全概念HARA分析完成后你会得到一堆安全目标。所谓安全目标就是对某个危害事件的顶层安全要求。比如车辆在任何行驶速度下不得发生非预期的部分或完全制动丧失这就是一条安全目标通常带一个ASIL等级。但安全目标只是要什么还不是怎么要。把安全目标转化为更具体、可落实到系统架构上的功能安全需求这一步就是FSC的职责。FSC的核心内容是为每个安全目标定义一组功能安全需求Functional Safety RequirementsFSR每个FSR描述一项安全机制或约束。比如针对非预期制动丧失这条安全目标可能需要以下FSR当主制动通道失效时应在100ms内通过冗余通道提供至少50%的制动能力。制动踏板位置传感器信号应具备合理性校验当校验失败时系统应进入降级模式并点亮警告灯。系统中的故障应在FTTI容错时间间隔内被检测并响应FTTI由系统设计和相关约束确定。每一类FSR背后都对应着一个或多个安全机制检测机制发现有问题、缓解机制降低故障影响、降级机制切换到安全状态或降级模式。概念阶段做FSC时有一个原则非常重要不要过早陷入技术细节。FSC描述的是要做什么、达到什么效应而不是用哪颗芯片、走哪条总线来实现。技术选型是后面系统设计阶段Part 4的事。如果在概念阶段就把处理器型号、通信协议写死你会发现后续设计空间极其狭窄一旦硬件方案与安全概念冲突返工代价巨大。5. TSC到底属于26262的哪一步这个问题为什么总被反复问相关热词里有一个问题暴露了很多从业者的知识短板汽车功能安全中的TSC属于26262中哪一分析步骤包含了哪些内容。这个问题在技术社区被反复询问本质上是因为很多资料把概念阶段和系统阶段混为一谈导致读者分不清FSC和TSC的边界。直接回答TSC不属于分析步骤它属于Part 4产品开发系统层面里面系统设计System Design阶段的重要产出物。它的输入是Part 3概念阶段产生的FSC输出结果是整个系统架构的安全设计方案。为什么这个问题的热度这么高我分析有三个原因。第一ISO 26262对TSC的定义分散在Part 4的多个条款中没有集中在一章里讲清楚。需要读者自己去拼凑系统设计过程、技术安全需求、系统架构设计规范这几块内容才能理解全貌。标准条文本身是法规约束性的语言不是教材性的语言天然就不友好。第二TSC这个名字具有误导性。TSC是Technical Safety Concept的缩写直译是技术安全概念。名字带概念两个字很多人就误会它和概念阶段有关其实它是概念阶段成果的技术化下沉。FSC和TSC的真正区别在于抽象层次不同FSC在功能层面描述发生什么危害时系统要做什么TSC在技术层面描述具体的架构模块要做什么、用什么机制来实现。第三国内不少企业的功能安全体系并未严格区分概念阶段和系统阶段的文档很多项目直接跳过了FSC从HARA硬切到TSC导致工程师在实际工作中看到的模式与标准描述的模型不一致概念自然混乱。我个人的经验是在面试或带新人时用一句话检验对方是否真正理解FSC和TSC的区别请你对一个自动紧急制动系统定义一条FSC层面的需求和一条TSC层面的需求。能答上来的人屈指可数。多数人会给出两条完全同层的需求区别只是措辞不同。回答不出这个区别说明对功能安全的概念层级没有建立起正确的认知。现在我们把TSC从步骤定位和内容构成两个维度彻底拆开。5.1 定位TSC在ISO 26262中的明确位置从开发流程的纵向结构看TSC处于这么一个位置Part 3概念阶段完成Item Definition → HARA → 安全目标 → FSC功能安全需求FSR进入Part 4系统层面开发输入接手概念阶段的FSR和验证过的系统架构假设在系统设计过程中产出TSC也就是把FSR细化为技术安全需求TSR并将其分配给系统架构元素随后从TSR向下派生硬件安全需求HSR进入Part 5和软件安全需求SSR进入Part 6硬件、软件开发完成后回到Part 4做系统集成、验证和安全确认这样一来TSC在整条链路中就是一座桥上承功能安全概念FSC下启硬件和软件的安全需求。它既不是分析的终点也不是开发的终点而是把功能语义翻译成技术语义的关键译码器。没有这座桥硬件团队和软件团队会各自按自己的理解去实现安全需求最后做集成测试时才发现两者对接不上系统层面的安全机制形同虚设。5.2 TSC与其他关键概念的关系为了彻底理清这个概念我把与TSC容易混淆的几个概念放在一张表里逐一对照| 概念 | 所属阶段 | 抽象层次 | 核心输出 | | 安全目标Safety Goal | Part 3概念阶段 | 整车层面描述顶层安全要求 | 不发生非预期制动丧失 | | FSR功能安全需求 | Part 3概念阶段 | 功能层面描述系统应实现的安全行为 | 当主通道失效时提供冗余制动能力 | | TSC技术安全概念 | Part 4系统阶段 | 技术/架构层面描述安全需求的实现方案 | 双通道架构失效诊断模块切换逻辑 | | TSR技术安全需求 | Part 4系统阶段 | 技术层面可分配给软硬件元素的需求 | 安全控制器应在10ms内检测到主通道失效并发送切换指令 | | HSR / SSR | Part 5 / Part 6 | 硬件/软件子项层面 | 硬件监测电路的设计约束 / 软件定时器监控逻辑 |从这个表可以清楚看到FSC回答系统要做什么TSC回答系统架构怎么实现这些要做什么TSR则是TSC的形式化、可验证的需求表达。TSC是一种设计活动设计产物TSR是这个过程产出的正式需求条目。这两个概念经常被混用但在标准的严格定义下TSC是个更宽泛的概念TSR是其中的核心交付物。6. TSC里装了什么核心内容逐项拆解既然TSC是整个系统设计的安全骨架它的内容必须覆盖从故障发生到系统恢复或降级的全过程。标准没有给出TSC文档的固定模板但根据多份实际项目经验一份完整的TSC至少应该包含以下六个方面。6.1 技术安全需求TSR把FSR逐条转化为可分配的技术要求TSR是TSC最重要的输出。每条FSR都需要被细化为一条或多条TSR。TSR的写法比FSR更技术化必须满足三个条件原子性一条需求只描述一个技术点、可验证性能在测试中被有效检查、可分配性能落到某个具体架构元素上。举个例子。FSR说当主制动通道失效时应在100ms内提供冗余制动能力。到TSR层面它可能会被拆成TSR-1主制动控制器应通过独立看门狗监控自身状态当软件未在100ms内刷新看门狗时应判定为自身失效。TSR-2失效判定结果应通过冗余CAN通道发送给冗余制动控制器通信周期不超过10ms。TSR-3冗余制动控制器在接收到主控制器失效标志后应在50ms内接管制动阀的控制权。这三条TSR分别指向看门狗模块、通信模块和冗余执行器控制模块硬件团队和软件团队能直接拿着它们去开发。制定TSR时最常见的失败模式是需求模糊。比如系统应能快速检测传感器故障这就不算合格——快速是多久故障的定义是什么正确的写法是系统应在20ms内检测到轮速传感器输出值超出物理范围0~300km/h并将该信号置为无效标志。可验证、可测试、可量化才是一条合格的TSR。6.2 安全机制设计检测、预防、缓解三层屏障TSC的核心技术工作就是定义安全机制。安全机制可以按照其生效时序分为三类检测机制故障发生后的第一时间发现它。常见手段包括传感器信号合理性校验、双通道信号交叉比对、软件看门狗、内存ECC校验、通信数据CRC/E2E保护等。预防机制不让故障产生或不让故障产生影响。常见手段包括冗余设计、物理隔离、故障降级策略、解耦设计等。缓解机制故障确实发生了、也确实检测到了但系统的安全状态需要一定时间才能到达在这段时间里要尽量降低危害。常见的缓解手段有限制执行器的最大输出、切换到安全制动模式、点亮故障警告灯提示驾驶员接管等。在设计安全机制时一个容易被忽视的问题是机制之间的独立性。如果检测机制和缓解机制运行在同一颗芯片上而这个芯片本身是故障源那么检测和缓解就同时失效了。这就是为什么功能安全领域极度强调功能隔离和独立安全机制。例如一个系统的主功能由主MCU实现安全监控功能必须由一个独立的硬件模块如独立安全MCU、外部看门狗、集成在SoC中的锁步核来承担。6.3 安全状态定义故障后的系统落点几乎每个TSC都需要明确回答当系统检测到不可恢复的故障时系统应该进入什么状态这个状态就是安全状态Safe State。安全状态的设定不是越保守越好。如果系统一遇到轻微故障就全系统关闭本身可能就会导致危险场景——比如高速行驶时直接切断转向助力比保持降级状态更危险。安全状态的确定必须结合HARA危害分析时定义的场景逐条判断在这个故障模式下进入哪个状态是对驾驶员和车辆最有利的。举三类典型的安全状态完全降级系统部分功能关闭但保留基本安全功能。如制动系统的主通道故障后进入仅能提供有限制动力的降级制动模式。安全暂停系统停止对外输出控制信号执行机构回到默认安全位置。如线控转向系统故障后转向力矩回到机械连杆的默认状态。维持最后有效状态系统保持故障前的最后有效输出并持续监控。这个策略更激进通常只用于故障概率极低且不能随意变更输出的场景。需要特别提醒的是从故障发生到进入安全状态需要明确的时间上限。这个时间上限就是FTTIFault Tolerant Time Interval。如果说安全状态是落点FTTI就是你必须在这个时间内到达落点的时限。FTTI的取值不是拍脑袋定的它来源于整车层面的物理约束——比如驾驶员的反应时间、车辆制动距离、执行器的响应速度等。FTTI的分配是整个TSC设计中最头疼的环节之一。通常FTTI会被拆分为三段时间故障检测时间、系统反应时间、执行器执行时间。诊断设计必须让故障检测时间足够短给后续反应和执行留出余量。我在实际项目中见过太多因为检测时间定得太长、导致FTTI超标的案例。KPI式的越短越好也不对——检测时间越短往往意味着诊断方法越复杂、误报率越高、成本越大。合理的目标是在满足FTTI的前提下尽量给诊断模块留出宽松的实现空间。6.4 故障通知和降级策略把内部故障变成用户可理解的信息功能安全不能只盯着ECU内部还要考虑人机交互。TSC中必须定义故障发生后如何通知驾驶员和其他系统。常见的安全通知手段包括仪表盘故障灯、HMI提示信息、声音报警、视频图像提示等。这些通知本身也有安全要求——比如警告灯必须在系统检测到故障后的100ms内点亮灯本身还必须有自检功能通电瞬间点亮一下再熄灭让驾驶员知道这个灯没有坏。降级策略还必须考虑故障叠加的情况。系统在降级模式下运行时可能出现第二个故障。TSC中需要分析降级模式下的安全机制是否依然有效以及降级状态下又发生新故障时系统应该如何应对。这个分析过程在标准中被称为故障树分析FTA和失效模式与影响分析FMEA的组合应用是Part 4系统层面安全分析的核心内容。6.5 系统架构的分配从要做什么到谁来做TSC的落脚点是把TSR分配到具体的架构元素上。这里的架构元素可以是硬件模块、软件组件、通信通道、外部接口等任何系统组成部分。分配的过程就是系统架构设计的过程——安全需求会影响架构的选型和划分。举个例子如果一个自适应巡航系统的目标ASIL是D那么负责测距的毫米波雷达的数据链路可能需要冗余或者需要在软件层面增加路由级别的校验。架构设计阶段还可能引入新的架构元素——比如为了满足转向系统的安全目标需要额外添加一套转向角传感器冗余单元。TSC就是记录这些架构决策及其理由的地方。架构分配时始终要遵循一个原则每个TSR都要明确归属到一个架构元素不能有悬空的需求每个架构元素上的TSR集合要被该元素的开发活动完整承接。这里最常见的问题是孤儿需求——TSR定义得很好但没有分配负责人和实现单元最后在软硬件设计中被漏掉直到测试阶段才发现安全功能没实现返工成本极高。6.6 剪裁与ASIL分解如果所有需求都按最高ASIL等级执行系统成本会非常高。ISO 26262提供了两种手段在保证安全的前提下降低开发成本ASIL分解和需求剪裁。ASIL分解的核心思想是把一条ASIL D的安全需求分解为两条相互独立的ASIL C需求两条一起满足就等价于满足ASIL D。它依赖于冗余架构——两个独立元素各自承担一部分需求且各自失效不会互相影响。ASIL分解不是偷工减料它本质上要求你真正做到独立性标准对独立性的审核极为严格。如果你的两个独立模块共用了一块电源芯片或同一根通信总线评审时极大概率会被挑战。需求剪裁则是基于系统的某个部分是否真的承担安全相关功能来判断是否可以按更低等级要求甚至按QC来管理。比如一条TSR只涉及数据存储备份不涉及实时控制回路可能可以被剪裁到较低等级。剪裁必须有理有据不能为了省事随意降级审核时的挑战同样不小。7. TSC往下走从系统到硬件、软件的落地链路TSC设计完成后系统层面的开发并没有结束还需要完成向下分配和向上验证两个方向的工作。很多工程师在这里搞不清楚流程的先后关系我重点讲透这层逻辑。7.1 从TSR到HSR、SSR的分解TSR是系统层面的需求硬件团队和软件团队各自无法直接使用——它需要分别翻译成硬件安全需求HSR和软件安全需求SSR。以一条TSR为例制动控制器应在10ms内完成主通道故障检测并输出切换指令。这条TSR的硬件部分可能包括负责执行切换指令的安全继电器电路、监控主控芯片健康的独立电源轨、满足响应时间要求的硬件电路设计约束。它的软件部分可能包括看门狗刷新周期的实现、故障标志位的置位逻辑、状态机切换的算法实现。在项目实操中TSR分解到HSR和SSR是一件极容易产生歧义的工作。原因在于一条TSR往往同时包含硬件行为和软件行为分解时要求团队明确这条TSR的哪些部分由硬件执行、哪些部分由软件执行、哪些部分需要软硬协同。白纸黑字写清楚避免在集成阶段扯皮分解阶段的投入是值得的。7.2 在软硬件设计中保证独立性的实现细节独立性是TSC中反复出现的要求但落到软硬件实现上独立性往往被各种共享资源悄然破坏。我列几个实际项目中常见的独立性杀手电源供电耦合主功能MCU和安全监控MCU共用同一条电源轨一颗电源芯片短路会导致两个MCU同时失效。通信介质共享主功能数据和安全状态数据走同一条CAN总线总线故障会同时影响两路数据的正常传输。晶振共享两个MCU共用同一颗外部晶振晶振停振导致两个MCU同时失去时钟源。软件空间共享安全功能和安全监控功能运行在同一个MCU内共用了同一套中断向量表一个内存越界就能同时踩坏两块区域。针对这些耦合点TSC阶段就需要进行架构级的规避。比如给安全监控MCU独立供电轨、安全状态信号采用独立硬线而非总线、安全监控MCU使用自身内部晶振、在软件层面做内存分区保护和MPU配置。这些决策在TSC中就要定下来而不是等到详细设计阶段再临场发挥。7.3 安全分析FMEA/FTA如何反哺TSCTSC不是拍一下脑袋就能产出的它需要基于系统性的安全分析来驱动。在Part 4系统层面最常用的两种分析方法是FMEA和FTA。FMEA失效模式与影响分析是自下而上的归纳方法从系统组成元素的失效模式出发分析每种失效模式对系统功能和整车安全的影响。它的产出是哪些底层失效会导致顶层危害事件的清单。FTA故障树分析是自上而下的演绎方法从顶层的危害事件出发逐层倒推哪些底层故障组合会导致这个事件。这两者结合TSC设计的典型用法是先用HARA得到顶层安全目标再用FTA分析导致安全目标违背的故障条件再用FMEA分析系统组成元素的具体失效模式将两者比对后找出架构上不能覆盖的失效点然后在TSC中新增或调整安全机制。我在多个项目评审中发现不少团队把FMEA和FTA当作合规交作业来对待做完就锁在文件柜里。这是很可惜的浪费。安全分析真正的价值在于它能提前识别架构漏洞告诉你TSC中哪个安全机制是薄弱的、哪个环节还需要冗余。一份好的安全分析报告会让TSC的每条需求都显得不得不存在而不是为了写而写。7.4 验证安全需求有没有被正确实现TSC向下分解并完成软硬件开发后还要回到系统层面进行验证。这里的核心概念有两个验证Verification和确认Validation。验证回答我们是否正确地实现了需求——检查系统的实现是否满足系统设计规范和TSR。它主要通过评审、走查、测试、仿真等手段进行。例如针对TSR系统应在10ms内完成故障检测并输出切换指令验证活动就是在硬件在环HIL测试中注入故障测量从故障注入到安全状态输出之间的实际时间。确认回答我们是否实现了正确的需求——从整车安全和用户使用的视角确认系统在实际运行时能满足安全目标。比如在实车上制造一个真实的总线失效场景观察车辆是否能安全地降级运行而不是仅仅在实验室的理想条件下通过测试。验证和确认对TSC的评审方式经常被新人混淆。一个简单的记忆方法是验证是对照着我们设计时定的需求来检查确认是对照着整车层面的安全目标来检查。前者关注内部一致性后者关注外部有效性。两个都不能缺缺了其中一个安全论证链就不完整。8. 从架构到测试功能安全给整车电气架构与测试带来的改变TSC这个环节对整个汽车电子电气架构产生的影响远不止增加几个安全需求这么简单。做电气架构的工程师如果对功能安全没有感觉设计出来的架构往往会在安全评审时被反复打回。8.1 电气架构设计中的功能安全考量先看一个具体问题一辆车的中央计算单元域控制器集成了座舱娱乐、车身控制、高级驾驶辅助等多种功能其中ADAS功能的安全等级可能是ASIL B甚至ASIL D。在这种高集成架构下座舱娱乐系统的一个软件崩溃是不是有可能干扰到ADAS功能的执行环境如果这个风险不能被有效隔离整个域控制器都要按最高等级来开发成本急剧上升。这就是现代电气架构面临的核心矛盾集成度越高功能安全隔离的难度越大。当前SoC厂商的普遍做法是提供硬件级别的隔离机制比如ARM的虚拟化技术虚拟机的强分区、锁步核lockstep用于故障检测、以及复杂SoC内部的车规级Safety Island设计。Safety Island本身承担安全监控和管理功能独立于应用核运行类似一颗芯片中的独立MCU。电气架构师在设计系统框架时应该尽早把安全域Safety Domain从通用计算域中划分出来。安全域内的硬件资源、软件运行空间、通信链路必须是独立可控的。这个划分的决策在TSC阶段就要做出因为它直接影响后续的硬件选型和软件分区方案。8.2 通信架构与安全机制的协同整车通信层面TSC也会引入大量安全需求。以CAN/CAN FD总线为例常见的通信安全机制包括数据签名与校验通过CRC、E2E端到端保护防止数据在传输中被篡改或丢失。会话超时监控定期监控报文的时间戳如果某个ECU超过预定时间未发送报文则判定该ECU失效。冗余传输路径关键安全信号使用两条独立总线或冗余节点传输。这些通信层安全机制的设计同样需要在TSC阶段就规划清楚。因为总线的带宽分配、报文周期、帧ID的冲突仲裁等都是通信系统设计的基础参数。如果在TSC中没有明确这条报文需要满足怎样的安全等级通信团队就会默认所有报文按相同优先级处理最终关键安全报文可能因为调度延迟而超时导致FTTI不满足要求。整车的EEA电子电气架构规划在功能安全需求明确之前只能算是一个技术草案不能作为定稿投到量产。8.3 测试验证体系的重塑功能安全对测试体系的冲击是全面而深刻的。传统的测试主要验证功能是否正确功能安全测试则额外要求测试故障是否被正确处理。这意味着测试工程师的工作范围发生了三个明显变化。第一故障注入测试成为必选项。必须在系统/硬件/软件的不同层级人为注入故障信号短路、信号开路、数据篡改、时序抖动、内存翻转等验证系统是否能检测到故障并按设计进入安全状态。故障注入测试方法和覆盖率直接决定安全机制的验证充分性。第二安全机制的覆盖率需要度量。ISO 26262要求对安全机制在硬件失效分析Fault Injection Analysis中的覆盖率进行评估。比如你知道内存有ECC校验但ECC只能纠正单比特错误双比特错误呢测试必须验证这个边界。这个覆盖率指标直接关联到硬件失效率的量化评估PMHF每小时的随机硬件失效概率是ASIL C/D项目必须计算和分析的核心指标之一。第三测试活动要能追溯到安全需求。每一轮测试用例必须能追溯到具体的TSR/SSR/HSR上测试结果也要反过来影响安全分析的结论。如果某条安全机制在测试中验证失败你是修改实现还是调整需求这个过程要有正式的变更管理和影响分析不能由测试工程师自己凭经验决定。8.4 常用工具链与落地建议落地功能安全离不开工具链的支持。目前业界常用的工具包括需求管理工具如DOORS、Polarion、安全分析工具如medini analyze用于FMEA/FTA/HARA、建模工具如Simulink、System Weaver、测试管理工具如VectorCAST、ECU-TEST等。工具选型的核心原则是工具本身的置信度也需要被评估。ISO 26262 Part 8中提出了工具可信度等级TCL的概念——如果工具输出结果会被直接用于安全论证而你无法证明工具自身不会出错就需要按TCL等级要求补充额外的验证活动。很多团队忽视了这一点导致到了认证评审阶段才发现工具不合规被迫补做大量手工核验工作。对于刚起步的团队我的建议是不要一上来就追求大而全的商业工具链。先用手头的工具把流程跑通需求表格用Excel不算错缺陷跟踪用Jira也可以起步重要的是把每个活动都留痕、可追溯、可评审。流程跑顺了再逐步工具化、自动化否则工具反而成为负担。9. 写在TSC落地三个月之后的一点体会这个系列第一篇写的是概念最后就用我在实际项目中反复咀嚼出的几条经验来收尾。第一条功能安全文档写得再完美如果它不和代码、原理图、测试用例形成真实的追溯关系那就是一堆废纸。我在评审时经常做一件事随机挑一条TSR追问它对应的FSR是什么、安全目标是什么、HARA的危害事件是什么、在代码或硬件里如何实现、被哪些测试用例覆盖。能完整走通这条链的团队功能安全才算真的落地了。走不通的通常意味着文档和开发是两套人在各写各的。第二条功能安全是一个证据链工程不是一个设计工程。设计只是起点你需要为每一个安全决策留下充分的证据——为什么选这个架构、为什么定这个时间参数、为什么用这个安全机制。评审时最怕听到的回答是这是经验定的。经验不是不能定但你必须把经验的推导过程写出来才能让第三方信服。第三条一个人在项目里能做多少功能安全活动取决于他对整车级场景的理解有多深。纯做嵌入式开发的人第一次做HARA往往会写出一堆ECU内部功能故障而不是整车危害事件这就是视角没转过来。多跟整车集成团队聊、多读往年的安全分析报告、多参与实车的失效场景测试对建立功能安全的直觉非常有帮助。纸上谈兵是练不出这层感觉的。下一篇我会沿着这条主线继续往前走重点拆解系统层面开发Part 4中系统设计的具体方法和常见问题。概念阶段我们认识了地图下一章就开始真正走第一步路了。