[论文阅读] 人工智能 + 软件工程 | 当ISO 26262遇上AI：电动车安全标准的新玩法

当ISO 26262遇上AI：电动车安全标准的新玩法

论文信息

信息类别	具体内容
论文原标题	AI Safety Assurance in Electric Vehicles: A Case Study on AI-Driven SOC Estimation
主要作者	Martin Skoglund, Fredrik Warg, Aria Mirzai, Anders Thorsén, Karl Lundgren, Peter Folkesson, Bastian Havers-Zulka
研究机构	RISE Research Institutes of Sweden（瑞典RISE研究机构，Borås）
发表会议/场景	EVS38 Götteborg, Sweden, June 15-18, 2025（第38届瑞典哥德堡电动车研讨会）
arXiv编号	arXiv:2509.03270v1 [cs.SE] 3 Sep 2025
APA引文格式	Skoglund, M., Warg, F., Mirzai, A., Thorsén, A., Lundgren, K., Folkesson, P., & Havers-Zulka, B. (2025). AI Safety Assurance in Electric Vehicles: A Case Study on AI-Driven SOC Estimation. Proceedings of EVS38 Götteborg, Sweden. https://arxiv.org/pdf/2509.03270

一段话总结

这篇论文聚焦电动车中AI驱动的电池状态（SOC）估计安全问题，针对传统安全标准（如ISO 26262）无法覆盖AI“黑箱特性”和“数据依赖性”的缺口，提出将ISO 26262与新发布的AI安全标准ISO/PAS 8800整合，并以“安全笼（非AI监控器+AI组件）”作为标准衔接接口；通过故障注入实验（向电压、电流、温度数据注入stuck-at故障）测试LSTM-based SOC模型的鲁棒性，发现电压输入对SOC预测误差影响最大、数据指数位故障会引发显著偏差，最终为电动车AI组件的安全评估提供了“标准框架+实验验证”的完整方案。

思维导图

研究背景：为什么要做这个研究？

咱们先从“电动车电池安全”这个大话题切入——你买电动车时，最担心什么？除了续航，肯定还有电池起火、过充损坏这些安全问题。而电池的“状态估计（SOC）”就是防风险的关键：它像电池的“电量仪表盘”，告诉车机“还剩多少电”，一旦算错，可能导致过充（电池过热、甚至爆炸）或深度放电（电池永久损坏）。

以前，车企用“库仑计数”“开路电压”这些传统方法算SOC，但这些方法有个大问题：搞不定电池的“脾气”。比如冬天温度低、电池用久了老化，都会让电池的“电量-电压关系”变得非线性（像人感冒了体温不准一样），传统方法算出来的SOC经常偏差很大。

后来AI（比如LSTM神经网络）出现了，它能拟合复杂的非线性关系，算SOC更准——但新问题又来了：AI是个“黑箱”，安全怎么评估？
咱们知道，汽车行业有个“安全圣经”叫ISO 26262，专门管电子系统的功能安全，但它是为传统系统设计的，面对AI的两个“软肋”完全没辙：

1. 黑箱特性：AI怎么得出SOC结果的？没人能说清细节，出了故障没法追溯根源；
2. 数据依赖性：AI算得准不准，全看训练数据够不够全——如果训练时没覆盖“零下20度+电池老化3年”的场景，实际遇到这种情况，SOC估计可能直接“翻车”。

另外，虽然有个ISO 21448标准管自动驾驶的“功能不足”，但它只针对激光雷达这类复杂传感器，不管电池SOC这种AI组件。相当于行业里有个“真空地带”：电动车的AI组件，没人知道怎么评估它的安全性。

这篇论文就是要填这个坑——既要用AI的优势算准SOC，又要给它套上“安全枷锁”，让车主用得放心。

创新点：这篇论文的“亮点”在哪？

1. 首次把“双标准”捏合到一起，解决AI安全评估的“无章可循”
   以前大家要么只用ISO 26262（不管AI特性），要么只用AI标准（不管汽车行业规则），这篇论文明确划分了两个标准的“责任区”：ISO 26262管“非AI部分”（比如监控器），ISO/PAS 8800管“AI部分”（比如LSTM模型），让评估有了清晰的规则。

2. 提出“安全笼”架构，给AI加了个“安全兜底”
   AI怕出错？那就给它配个“监护人”——用一个简单、易验证的非AI监控器（高安全等级SIL）盯着AI的输出。一旦AI算的SOC超出安全范围（比如明明只剩10%却显示50%），监控器立刻“掐断”AI的输出，避免危险。这个架构既保留了AI的精度，又用传统安全组件解决了AI的黑箱风险。

3. 用“故障注入实验”量化AI的鲁棒性，不是“空谈安全”
   很多论文只说“AI要安全”，但没说“怎么证明安全”。这篇论文直接上实验：模拟传感器故障（比如电压数据卡住不动），看AI的SOC预测会偏差多少，还算出了“电压输入最敏感”“指数位故障影响最大”这些具体结论，让安全评估从“定性”变成了“定量”。

研究方法：论文是怎么做的？

这部分咱们分“标准整合”和“实验验证”两部分说，把复杂的方法拆成“一步步能看懂”的流程。

第一步：定规则——双标准整合的具体分工

先明确“谁管什么”，避免标准打架：

组件类型	负责标准	要做的事
整车功能（比如BMS）、非AI组件（比如电压传感器）	ISO 26262	按传统方法做故障分析、安全验证
AI系统（比如LSTM SOC模型）、AI组件（比如数据预处理模块）	ISO/PAS 8800	验证数据质量、测试AI鲁棒性、做可解释性分析
（如果有激光雷达等ADAS组件）	加ISO 21448	额外验证传感器功能不足的风险

第二步：搭架构——设计“安全笼”

1. 核心组件：AI-SOC估计器（LSTM模型）+ 非AI监控器；
2. 数据流向：电压、电流、温度传感器数据，同时传给AI和监控器；
3. 安全逻辑：监控器用简单规则（比如“电压过高时SOC不能超过80%”）判断AI输出是否合理，不合理就“抑制输出”，让车机用安全的备用值。

第三步：做实验——故障注入测试AI鲁棒性

这是最关键的一步，咱们拆成“实验准备→故障注入→结果分析”三小步：

1. 实验准备：

   • 模型：选LSTM网络（因为处理时序数据强，适合SOC估计），输入300步历史数据（电压、电流、温度），用“LG 18650HG2电池数据集”训练；
   • 故障模型：选“stuck-at故障”（模拟传感器卡住，比如电压数据一直显示3.7V），这是汽车电子里最常见的故障类型；
   • 数据格式：输入数据是64位浮点数（Float64），只注入3-64位（前2位是符号位和指数位起始，注入会导致代码崩溃，没法测AI）。

2. 故障注入：

   • 分两种故障：stuck-at-0（把某一位固定为0）、stuck-at-1（固定为1）；
   • 遍历测试：对电压、电流、温度的每一位（3-64位）都注入故障，计算SOC预测值与真实值的误差（用RMSE和绝对偏差衡量）。

3. 结果分析：

   • 看“哪个输入最敏感”“哪个数据位影响最大”“哪个SOC区间最危险”，得出具体结论。

主要成果和贡献：这篇论文到底有啥用？

重点看“对行业的实际价值”：

1. 核心实验成果

实验问题	结论	实际价值
哪个输入对SOC误差影响最大？	电压 > 电流 > 温度（电压故障RMSE达0.8）	车企可优先给电压传感器加冗余设计
数据的哪部分故障影响大？	指数位（2-12位）> 尾数位（13-64位）	数据预处理时重点校验指数位合理性
哪个SOC区间最敏感？	电压<44%、电流>72.6%、温度<32.9%时故障影响显著	针对这些区间优化AI模型或监控规则
归一化对故障有影响吗？	归一化后bits3-10恒为1，stuck-at-1对这些位无效	训练时可针对性处理数据位，减少无效故障

2. 对行业的贡献

• 给车企一个“安全评估模板”：以后做AI-SOC、AI电机控制这些组件，不用再“瞎琢磨”怎么评估安全，直接套用“ISO 26262+ISO/PAS 8800+安全笼”的框架就行；
• 量化了AI的安全风险点：不是只说“AI可能出错”，而是明确“哪里最容易错”“错了会有多严重”，方便车企针对性做防护；
• 填补了标准缺口：让AI组件的安全评估从“无标准”变成“有章可循”，推动电动车AI技术的落地（毕竟安全是第一位的）。

3. 开源资源

• 数据集：LG 18650HG2 Li-ion Battery数据集，可在Mendeley下载（https://data.mendeley.com/datasets/cp3473x7xv/3）；
• 模型参考：LSTM-based SOC估计器的Python实现，参考Wong等人2021年的研究（https://doi.org/10.1145/3462203.3475878）。

关键问题

问题1：为什么要同时用ISO 26262和ISO/PAS 8800？只用一个不行吗？

答：不行。ISO 26262是汽车行业的“老规矩”，管传统电子系统很拿手，但看不懂AI的“黑箱”；ISO/PAS 8800是专门为汽车AI设计的“新规矩”，但不懂传统安全的流程。比如非AI的监控器，用ISO 26262就能轻松验证安全等级；而AI模型的数据质量，必须靠ISO/PAS 8800来评估。两者结合才能“既懂传统安全，又懂AI特性”。

问题2：“安全笼”架构里，监控器为什么要用非AI的？用AI监控AI不行吗？

答：用AI监控AI会陷入“双重黑箱”——两个AI都看不懂，出了故障更难追溯。非AI监控器的优势是“简单、透明”：比如监控器的规则可以是“电压>4.2V时，SOC不能超过100%”，这个逻辑一眼能看懂，也容易用ISO 26262验证安全等级，相当于给AI加了个“靠谱的监护人”，而不是“另一个黑箱朋友”。

问题3：实验为什么选“stuck-at故障”？这种故障在实际车上常见吗？

答：很常见。stuck-at故障本质是“信号卡住不动”，比如传感器线路被电磁干扰、硬件老化，都可能导致电压/电流数据卡住。比如冬天开车时，电磁干扰可能让电压传感器一直显示3.5V，这时候如果AI没被监控，就会算错SOC。选这种故障做实验，就是为了模拟最真实的风险场景。

问题4：这篇论文的方法，除了SOC估计，还能用到电动车的其他AI组件上吗？

答：当然能。比如AI电机控制、AI能量回收系统这些组件，都有“黑箱特性”和“数据依赖性”，都可以套用“双标准整合+安全笼+故障注入”的框架。论文里也提到，未来会把这个方法扩展到更多电动车AI组件上。

总结

这篇论文的核心价值，在于“把模糊的AI安全问题，变成了可落地的解决方案”。它没有空谈“AI要安全”，而是：

1. 定了规则（双标准整合），让评估有依据；
2. 搭了架构（安全笼），让风险有兜底；
3. 做了实验（故障注入），让结论可验证。

对于车企来说，这篇论文是“拿来就能用”的安全评估指南；对于消费者来说，这意味着未来的电动车AI组件会更安全，不用再担心“AI算错电量”的风险。当然，论文也提到未来要优化“在役监控”（比如AI在实际使用中持续验证数据有效性），让AI的安全保障更完善。