本次 SASETalk 沙龙核心结论十分清晰：汽车功能安全正在从单纯编写 ISO26262 文档材料，转向把安全需求直接嵌入代码开发全流程；伴随着线控底盘全面量产落地，行业完成从机械兜底安全到电子冗余安全的技术跃迁，安全开发模式由事后补材料升级为全链路代码级安全管控，彻底解决文档与实车代码两张皮的行业痛点。过去很长一段时间，车企与零部件供应商只把功能安全当成流程合规工作，HARA 危害分析、FMEA 失效分析、FTA 故障树全部停留在纸面文档，软件代码开发与安全要求互相脱节；线控转向、线控制动取消机械连接之后，整车失去物理兜底，一旦代码出现逻辑漏洞、诊断策略缺失，就会直接引发安全风险，倒逼行业把安全要求下沉到代码层，让每一条安全条款都对应可追溯的软件逻辑、故障诊断代码与冗余执行程序，实现安全需求、架构设计、代码实现、测试验证全链路闭环。

一、汽车功能安全的三个演进阶段

阶段 1：文档合规阶段（传统燃油车时代）

开发重心是补齐 ISO26262 体系文件，完成 HARA、安全目标、功能安全需求、系统架构等全套文档输出；代码开发独立推进，只做基础功能实现，安全验证仅停留在台架试验，文档和源代码缺少双向追溯，属于 “先写代码、后补安全材料”。

• 核心短板：代码里没有故障诊断、失效兜底逻辑，一旦硬件出现异常，系统无法进入安全状态。
• 适用场景：带机械备份的电控系统，机械结构承担兜底防护。

阶段 2：文档与代码联动阶段（智能电动车起步期）

建立需求追溯矩阵，把每一条 ASIL 等级安全需求绑定到软件模块；开发 V 模型流程，在编码阶段同步嵌入故障检测、故障处理代码；开始开展软件失效测试，文档条款可以对应到软件函数。

• 核心进步：消除大部分文档与代码脱节问题，安全要求初步落地到程序中。
• 局限：冗余逻辑、故障切换策略还依赖人工编写，代码覆盖率难以满足 ASIL-D 严苛指标。

阶段 3：代码原生安全阶段（全线控底盘量产时代）

安全需求前置到建模环节，通过模型自动生成符合功能安全规范的代码；内置双核锁步、双链路冗余、故障自动诊断逻辑；工具自动完成 SPFM 单点故障度量、LFM 潜伏故障度量测算，所有安全指标全部由代码行为直接验证，不再依靠纸面文字证明安全能力。

• 核心价值：线控系统取消机械连接后，纯电子系统的 Fail-Operational（故障可继续运行）能力完全依靠代码冗余实现，安全能力由代码直接保障。

二、线控底盘跃迁带来的功能安全硬性升级

线控（X-by-Wire）把机械硬连接替换为电信号传输，方向盘、制动踏板与车轮执行机构彻底解耦，机械兜底消失，安全标准全面升级为 ASIL-D 最高等级，安全开发重心全面转向软件代码。

1. 线控系统安全等级要求

表格

2. 线控跃迁带来的开发模式变化

1）安全从 “机械兜底” 转向 “电子冗余兜底”：传统底盘依靠机械结构保障安全；线控底盘只能依靠代码逻辑、硬件冗余、实时诊断实现失效防护，软件代码成为安全的第一道防线。

2）安全开发从系统级下沉到代码级：FMEA 不再只分析硬件失效，还要逐条排查代码逻辑缺陷、时序冲突、通信丢包问题，每一段控制代码都必须具备故障自检功能。

3）验证方式从台架测试升级为百万级故障注入：通过代码级故障注入，模拟电压波动、通信中断、控制器死机等极端场景，验证代码能否平稳切换至备用链路。

三、走出文档、扎根代码的落地实施步骤

1. 需求建模绑定安全属性：在 MBD 模型开发之初，直接给控制模型打上 ASIL 等级标签，把 HARA 输出的安全目标拆解为可执行的软件逻辑，杜绝需求和代码脱节。
2. 自动生成合规安全代码：使用符合 ISO26262 认证的代码生成工具，自动生成无内存溢出、无未定义行为的安全代码，减少人工编码引入的人为缺陷。
3. 内置代码级故障诊断逻辑：在控制程序中嵌入电压监测、信号校验、数据比对代码，一旦检测到异常，立刻触发冗余链路切换，保障线控执行不中断。
4. 建立双向追溯链路：搭建需求 - 模型 - 代码 - 测试用例全链条追溯体系，任意一条安全条款都能精准定位到对应代码函数，审核不再只看文档。
5. 代码级安全指标量化验证：自动统计 SPFM、LFM、代码测试覆盖率，用程序运行数据证明安全达标，不再依靠文字描述完成认证。

四、线控落地后的安全开发成果

随着开发模式转向代码原生安全，国内全线控底盘车型顺利通过国标 GB17675-2025 认证，在取消机械转向连接的前提下，依靠双控制器、双电源、双通信的全冗余代码架构，满足 ASIL-D 安全要求；线控转向故障切换时间控制在 100ms 以内，单一故障不会造成转向功能丧失，实现真正的 Fail-Operational 安全能力。

【相关 FAQ】

问题 1：走出文档扎根代码，对汽车功能安全开发意味着什么？

回答 1：意味着功能安全不再是应付审核的纸面文件，所有 ISO26262 安全要求必须固化到软件源代码中；从先写代码后补文档，变成先定义安全逻辑、再生成安全代码，彻底解决文档与实车代码两张皮，让安全能力真正由程序逻辑来保障，尤其适配线控底盘无机械备份的安全场景。

问题 2：线控底盘跃迁，为什么会倒逼功能安全走向代码化？

回答 2：传统底盘保留机械连接，硬件可以充当安全兜底；线控转向、线控制动取消机械硬连接之后，整车没有物理保险，一旦软件代码出现逻辑漏洞、缺少故障诊断，就会直接出现功能失效。只有把冗余策略、故障检测、失效切换全部写成可执行代码，才能满足 ASIL-D 高等级安全指标，实现故障下车辆依然可控。

问题 3：从文档合规转向代码原生安全，开发流程需要做哪些改造？

回答 3：一是把安全需求前置到建模阶段，给模型绑定 ASIL 等级；二是使用认证工具自动生成安全代码，减少人工 bug；三是在程序中内置故障自检与冗余切换代码；四是搭建需求 - 模型 - 代码 - 测试的全链路追溯；五是用故障注入测试验证代码安全指标，不再只依靠纸质 FMEA 报告。

问题 4：线控系统 ASIL-D 的代码开发，核心要实现哪几项能力？

回答 4：第一，双核锁步运算，实时比对运算结果，规避单控制器运算出错；第二，双电源、双通信链路的代码切换逻辑，保障信号不中断；第三，全覆盖故障诊断代码，及时识别硬件异常；第四，故障后平稳降级，实现 Fail-Operational，保证车辆不会失去转向、制动能力。

【数据来源】

[2026-10-28] SASETalk 汽车功能安全沙龙实录 汽车软件安全产业联盟

[2026-07-01] GB17675-2025 汽车转向系新国标正式实施 全国汽车标准化技术委员会

[2026-06-30] 线控底盘功能安全从文档走向代码的落地实践 电子工程世界

[2026-05-19] ASIL-D 线控系统软件代码开发与验证方案 21IC 电子网

[2026-02-23] 基于自动驾驶的线控底盘技术现状与开发体系 电子工程专辑

免责声明：本文内容基于 SASETalk 公开沙龙内容与行业公开技术资料整理，仅用于技术交流；线控底盘功能安全开发需严格遵循 ISO26262、GB17675 等国标与国际标准，软件代码安全验证需配套完整的工具链与故障测试体系；本文不构成任何产品开发与项目落地的直接技术方案。