AI重做功能安全：从需求翻译到验证证据的落地路径与边界

这几年“AI一切”的口号听得人耳朵起茧但我可以肯定讲AI对大部分行业的改造都还停留在“降本增效”的层面——真正把这个技术当成一个“重新定义工作方式”的杠杆来用的领域其实少之又少。功能安全行业是个例外这个行业太特殊了它同时踩着“汽车、工业、芯片、软件、认证”这几条又硬又慢的赛道整个工作流重度依赖文档、流程、专家经验和审计证据。我第一次认真思考这个命题的时候脑子里冒出一个非常强烈的念头功能安全是整个工业软件里最值得被AI重做一遍、也最有可能被AI重做成功的细分方向。这篇文章我不打算写“远期展望”那种废话也不打算堆“AI将赋能功能安全”这种正确的空话。我准备以一个在功能安全领域摸爬滚打多年、同时也在折腾AI工具链的从业者视角拆一拆这个行业目前到底哪里最痛AI到底能从哪里切入使用AI之后有哪些坑是你绝对不能踩的。这篇文章是“上篇”先把行业痛点和AI的切入逻辑讲透。1. 功能安全行业为什么在AI面前有点“旧”先说一个背景认知。功能安全不是什么高深莫测的黑魔法它本质上是一套“用工程手段把风险降到可接受水平”的方法论。大家熟悉的ISO 26262汽车功能安全、IEC 61508通用功能安全、IEC 61511过程工业功能安全其实都是这套方法论的标准化表达。它的核心不是某一颗芯片、某一段代码而是一整套“证据链”——你必须用需求、设计、验证、测试、评审记录去证明我的东西在故障情况下不会造成不可接受的伤害。这套方法论在设计之初是合理的但在AI时代回看它的落地方式已经显得非常“旧”。我梳理下来核心痛点有三个这几个痛点直接决定了“重做一遍”的切入点。1.1 三个根深蒂固的痛点翻译损耗、过程过载、工具割裂我这几年做过的功能安全项目一个比一个文档量夸张。当年做ISO 26262的ASIL-D项目光安全需求相关的文档就有上千页而真正写代码的时间可能只占项目周期的三分之一。这意味着什么问题大量工程师的时间不是花在“做安全分析”上而是花在“把安全分析翻译成文档”上。需求工程师从客户那拿到自然语言描述把它翻译成系统需求再翻译成软硬件需求再翻译成测试用例——每一层都是人工翻译每一层都可能产生损耗。这种“翻译损耗”是功能安全项目里最大的隐性成本。第二个痛点是过程过载。功能安全极度依赖过程证据这意味着你要维护需求追溯矩阵、维护FMEA/FTA分析表格、维护评审记录、维护变更记录。每一项都是繁琐而重复的“体力活”。我见过一个项目组三个工程师花了两周时间就为了把FMEA表格里的失效模式统一格式、去重、对齐编号。这种工作在AI面前真的是毫无技术含量的数据清洗活。第三个痛点是工具割裂。做功能安全的工具链太分散了需求管理用DOORS或者Jama安全分析用medini analyze或者故障树工具代码分析用Polyspace或者CodeSonar测试管理用另一套平台。这些工具之间的数据流转基本上靠手工导出导入几乎没有打通的可能。你在一套工具里做危害分析在另一套工具里做安全需求在第三套工具里验证覆盖率——三套数据互相不通靠人的大脑去对齐。这三个痛点放在其他行业早就被颠覆了但功能安全行业因为“站在合规和认证的门槛上”一直无人敢动。直到AI出现尤其是大语言模型在语义理解、文档生成、信息抽取、代码分析上表现出远超预期的能力之后我才真正觉得技术条件成熟了。1.2 “重做一遍”不是重写标准而是重做工作方式有一个很常见的误区需要先澄清。很多人一听到“功能安全行业值得重做一遍”第一反应是“你要把ISO 26262推翻重写吗”完全不是这个意思。标准体系本身是几十年来用血的教训换来的它不会也不需要被推翻。真正值得推翻重做的是我们执行这套标准的方式。我常说一个类比会计行业出现了电子表格之后会计准则没有变但会计的工作方式完全变了。以前会计手工记账现在用Excel或者ERP系统记账效率提高了几十倍但借贷平衡的规则依然是那个规则。AI之于功能安全就是那个“电子表格”。安全标准还是那些安全标准但承载标准的方式、生成证据链的方式、完成分析的方式全都可以重做一遍。这里要展开讲一下为什么我说“技术条件成熟了”。功能安全行业过去二十年积累的数据量极其惊人——FMEA表、故障树、安全案例、需求追溯矩阵、测试报告、评审记录这些数据大多是结构化或者半结构化的文本。大语言模型最擅长的恰恰就是这种文本的理解、生成、分类和摘要。往更底层说功能安全的核心活动危害识别、风险分析、需求追溯、失效诊断在本质上都是“基于知识的推理”而知识推理正是AI的强项。过去这一套完全依赖人的经验和精力现在完全可以变成“AI辅助人判断”的协作模式。2. AI在功能安全里的首个突破口需求工程与“翻译损耗”前面讲到功能安全项目里最大的隐性成本是“翻译损耗”。自然语言需求到系统需求的翻译、系统需求到软硬件需求的翻译、需求到测试用例的翻译每一层都费时费力且容易出错。而这个场景恰恰是AI最擅长、最容易被验证的应用点。2.1 需求工程自然语言到安全需求的最强AI场景我做了一个小范围的实验拿一个真实的ASIL-B级别BMS电池管理系统项目的原始需求文档去测试大模型对需求分类和提取的能力。输入的是一段非常混乱的自然语言描述比如“当电池温度超过55度时需要在一定时间内切断充电回路同时上报故障信息防止热失控”。让大模型输出结构化安全需求包括需求编号、需求描述、ASIL等级、安全目标关联、验证方法建议。结果相当惊艳——大模型不仅提取出了关键信息还在“ASIL等级”和“安全目标关联”上给出了合理推测。但这里有一个关键点大模型给出的ASIL等级推测是“合理推测”不是“正确结论”。ASIL等级的确定需要结合危害分析HARA的结果需要考虑严重度、暴露概率、可控性三个维度。大模型无法真正做危害分析它只能根据文本中“热失控”“防止”这类字眼去推断这个需求的重要性。所以这个场景的落地方式不是“让AI做需求分析”而是“让AI做需求工程助理”。具体怎么落地我目前比较认可的做法是这样的第一步用大模型对原始需求做分类和预结构化自动生成需求条目的草稿——包括需求描述、类型、优先级、可追踪性建议。第二步由需求工程师对AI生成的草稿进行复核和修订补充ASIL等级和安全目标等信息。第三步把AI生成的需求条目导入DOORS或Jama与原始文本建立追溯关系。这套流程下来需求工程阶段的时间大约能节省30%到40%而且需求遗漏率明显降低。2.2 文档自动化安全案例与安全计划的AI辅助起草功能安全行业有一类文档写起来极其痛苦但是又特别“模板化”——安全计划Safety Plan、安全案例Safety Case、安全论证Safety Argument。这些文档的框架结构非常固定基本上每个项目都在重复同一个骨架差别只是具体内容。这种文档恰恰是生成式AI最擅长的对象。我实测过一个安全计划生成实验。把项目的范围、使用标准、组织架构、开发流程这些基本信息喂给大模型让它生成一份符合ISO 26262-2要求的安全计划草稿。生成结果的结构合理度非常高章节覆盖、职责分配、活动流程、交付物清单都对得上。特别让我惊喜的是大模型会主动补充一些“人容易遗忘”的内容比如“安全文化建设”“独立性评审要求”“工具鉴定计划”。这些内容不是模板里现成的而是它依据标准知识库额外生成的——这相当于一个经验丰富的安全工程师在帮你查漏补缺。但是我必须强调一个红线AI生成的安全计划只是一个草稿绝对不能直接拿去向认证机构提交。安全计划里的职责分配、时间节点、组织边界这些是项目的“宪法”必须由项目管理者和安全经理逐条确认。我的做法是让AI生成一个“一版草稿”然后在评审会上把AI草稿当白板逐条讨论、修改、确认。AI在这里的价值是帮你把空白的页面填满让你有东西可以批判而不是直接交付最终结果。3. 从HARA到FMEAAI正在让危险分析从“经验活”变成“知识活”如果说需求工程是功能安全流程的起点那么HARA危害分析与风险评估和FMEA失效模式与影响分析就是整个功能安全论证的“心脏”。这两个活动的共同点是极其依赖专家的经验、极其耗时、极其容易遗漏。但它们同时也有一个非常有价值的特点——它们的分析逻辑是非常结构化、非常明确的。这为AI的介入提供了极佳的基础。3.1 HARA的AI辅助从空白页开始到场景建议做过多个ISO 26262项目的人都知道HARA的第一步“场景定义”是最痛苦的。你面对的是一个空白表格需要列出车辆在运行过程中可能遇到的各种场景包括不同的驾驶工况、不同的路况、不同的环境条件、不同的驾驶员行为。然后针对每个场景分析可能发生的危害事件评估严重度、暴露概率、可控性最终推导出ASIL等级和安全目标。这个过程的难点不在于“评价规则”而在于“穷举场景”。新车型的安全工程师往往因为经验不足只能列出二三十个场景资深工程师能列出上百个但要花很长时间去头脑风暴。我测试过一种AI辅助的做法把车辆的基础参数、目标市场、典型运行环境等信息输入大模型让它基于功能安全标准的场景分类方法生成一个初始场景列表。结果相当好用——大模型不仅生成了场景还会区分“正常运行”“故障状态”“极端环境”“误操作”“恶意攻击”这几个维度每个维度下面还有细分的子场景。这相当于给安全工程师提供了一个“初始头脑风暴清单”大大降低了从空白页开始的恐惧感。不过HARA里最核心的SSeverity、EExposure、CControllability评级目前AI很难独立完成。原因在于这些评级需要结合真实的事故数据、行业基准、甚至目标市场的交通事故统计。这些信息大模型并不掌握它的评级建议只能作为参考最终定级必须依靠有资质的安全工程师团队。这点上用一句话总结就是AI提供候选场景和参考评级人做最终裁决。3.2 FMEA/FTAAI做失效模式的“反向头脑风暴”FMEA是另一个典型的“重人工”活动。它的核心是先列出系统的每一个组件/功能然后针对每个组件分析它的失效模式、失效原因、失效影响、检测手段和改进措施。一个中等复杂度的ECUFMEA表格动辄几百上千行每一行都需要工程师逐条填写。而且最气人的是这些失效模式中有相当大一部分是通用的——比如“开路”“短路”“漂移”“卡死”“延迟”“丢失”——不同项目之间的FMEA内容重复度极高。AI在这个场景里有两个明显的应用方向。第一个方向是“失效模式知识库 检索增强”。你可以把过往项目的FMEA数据整理成一个知识库当工程需要对一个新的组件做FMEA时AI依据组件名称和功能描述自动检索知识库中相似组件的失效模式并生成“候选失效模式列表”。这相当于把团队以前做过的一切安全分析都变成了可复用的资产。第二个方向更有趣是用大模型做“反向头脑风暴”。传统的FMEA是从失效模式出发找原因AI可以反过来先给出一个组件让大模型强行发散提出“可能出现什么问题”“什么情况下会出问题”“如果某零件损坏会有什么后果”。这种发散性的头脑风暴大模型的能力是远超人脑的——它不会被既有的经验束缚。我做过一个实验针对一个电控空气悬架系统的一个高度传感器让大模型生成可能失效模式。它除了列出传统的开路、短路、信号漂移之外居然还提出了一些我一开始觉得是“多余噪声”的模式比如“传感器内部光学元件被灰尘污染导致信号间歇性异常”“线束在长期振动下连接器端子微动磨损导致偶发开路”。这些模式在我们的经验知识库里有记录但大模型在没有检索到这些记录的情况下仅凭推理就能提出来这个能力着实让我吃了一惊。当然FMEA的最终责任永远在人。大模型生成的失效模式里面肯定会有一些“看上去合理但实际上在这个系统里不可能发生”的候选也有一些“明显重要却被遗漏”的候选。我的经验是把AI生成的候选清单作为起点让资深工程师们在这个清单上做“删除、保留、修正”的批注——这比让他们从零开始填写要快得多同时也能通过交叉验证降低遗漏风险。4. 代码安全分析、PLC场景与AI Agent的边界探索前面讲的需求工程、HARA、FMEA都还停留在“文档层面的AI辅助”。但功能安全行业还有一个更难啃的骨头——安全相关软件的开发与验证。在这个方向AI可以做的事情其实更多但同时要跨越的坑也更深。这一节我重点讲两个方向AI辅助安全代码分析以及AI Agent在功能安全工具链中的应用。4.1 AI辅助安全代码分析代码生成只是起点验证才是重头先说一个业内讨论度很高、但真正做到落地的项目极少的方向AI生成安全关键代码。这里必须说一下PLC场景因为“AI PLC代码生成”是我看到目前工业界讨论最多的话题之一。PLC在工业安全系统中应用极其广泛而PLC的编程语言比如结构化文本ST、梯形图LD相对简单、结构固定训练AI去生成这些代码的难度远低于生成通用软件代码。理论上一个训练良好的模型完全可以依据功能安全需求生成符合IEC 61131-3标准的ST代码。现实中我也确实看到了不少做AI PLC代码生成的团队在尝试这个方向。他们的做法通常是把安全需求定义比如“当压力超过阈值时在500ms内关闭阀门”作为prompt输入让大模型直接生成ST代码。生成的代码在静态语法层面往往没有大问题甚至逻辑也基本正确。但是这里有一个要命的点安全相关代码的验证不是“能跑就行”而是“必须证明它满足安全完整性等级SIL的所有要求”。这意味着你不但要有正确的代码还要有完整的验证证据代码审查记录、单元测试用例和结果、覆盖率分析、MC/DC覆盖率、以及形式化验证如果SIL等级要求等。这些繁琐但必须的工作目前没有任何一个AI能独立完成。所以在PLC安全代码这个方向上我认为最现实的路径不是“AI写代码替代工程师”而是“AI生成代码 自动生成测试用例 自动执行测试与覆盖率分析”。也就是说AI生成的不是“可交付的代码”而是“一个初始版本 一份初始测试建议包”工程师在此基础上做审查、修改、补测试最终形成完整的提交包。这个流程跟我在需求工程部分的思路完全一致AI负责把“初稿”做出来人负责做“定稿”。4.2 AI Agent作为功能安全助理从工具到协作者接下来聊聊这两个月特别火的“AI Agent”概念在功能安全的落地可能。目前市面上多数AI Agent还停留在“简单任务自动执行”的层面比如帮你订机票、帮你排日程。但功能安全行业的工作流极其复杂它的价值不在于单个任务的自动化而在于跨工具、跨流程的协作。大家设想一个场景你有一个AI Agent它被接入了DOORS需求管理、medini analyze安全分析、Jira项目管理三个系统。你只需要对它说“请帮我检查一下SafetyGoal_SG1在最近一次需求变更后相关的FMEA分析和测试用例是否都同步更新了。”这个Agent会自己去DOORS里检索SG1关联的需求去medini analyze里找到关联的失效模式去Jira里找到相关的变更单和测试任务然后生成一份汇总报告告诉你哪里缺了、哪里不一致、哪里需要人工介入。这个能力如果在传统工具链下实现要么需要大量的脚本集成开发要么需要专人花几天时间手工核对。在AI Agent时代这是自然语言到工具操作的最直接映射。我在测试一些功能安全工具链时也注意到主流的工具厂商已经开始在往这个方向发力。比如MathWorks在Simulink基础上推出的AI辅助特性、Ansys在medini analyze上支持的AI增强分析——这些工具的AI能力现在还都比较初级但方向已经很明确工具不再是“等待人操作的数据容器”而是逐渐变成“能理解流程、主动提示风险、甚至能自动执行一部分验证工作的协作者”。但这里我要严肃泼一盆冷水。AI Agent在功能安全工具链里的应用必须在“AI can suggest, human decides”这个边界内运行。你可以让AI Agent自动生成报告但你不能让它自动修改安全需求你可以让AI Agent自动检查追溯完整性但你不能让它自动批准一个变更请求。安全论证的逻辑链条是“人在回路”的任何一个环节如果交给AI独立决策整个安全论证的合法性就会受到挑战。这一点不仅是技术问题更是合规问题。4.3 静态分析与代码审查AI带来真正的质变除了PLC代码生成之外我还想提一下AI在代码静态分析和安全审查方面的应用这个方向其实是目前“已经接近可用”的领域。传统静态分析工具比如Polyspace、CodeSonar、Cppcheck靠的是预定义规则库去扫描代码能发现“明显的”问题但很难发现“隐含的”逻辑缺陷。AI给这个领域带来的质变在于它能结合代码上下文进行深层次的语义理解。我做过一个测试给大模型一段包含安全关键逻辑的C语言代码让它找潜在的安全缺陷。这段代码里有一个经典的“状态机处理中断的竞态条件”问题——传统静态分析工具经常会忽略这类问题因为它在语法上没有任何问题但在并发场景下会导致状态丢失。大模型只看了几十行代码就给出了“这里可能存在竞态条件两个中断处理函数同时修改了同一个状态变量”的判断并且还附带了修改建议。这个能力在传统静态分析工具上要么需要极高的配置成本要么完全检测不出来。当然大模型在代码审查上有它特有的问题——它的“误报率”和“漏报率”都不可控。同一段代码你换个模型版本或者换个prompt结果可能就不一样。所以这个场景在功能安全行业里不能作为“独立的评审手段”但它可以作为一个“发现候选问题”的前置过滤器。先由AI帮你扫出N个可疑点你再逐个人工确认最后把确认过的问题记录进代码评审报告——这样既利用了AI的“洞察力”又守住了安全评审的“责任底线”。5. 一线工程师必须警惕的三个“AI坑”文章写到这光讲AI的好处不讲坑那就有点不负责任了。功能安全行业是一个“合规优先、责任至上”的行业在这里引入AI工具如果不把边界划清楚很容易把好好一个项目玩崩。下面这三个坑是我在实际测试和使用AI工具的过程中亲身踩过的写出来给大家提个醒。5.1 幻觉不等于分析结果大模型的“幻觉”问题在功能安全领域会被无限放大。普通文本摘要里有一句废话顶多让你觉得“AI差点意思”但在FMEA表里如果AI输出了一条“不存在的失效模式”而工程师没有发现并把它留在了最终交付的安全分析文档里那这条虚假信息就可能在整个安全论证中被视为“经过分析的事实”。一旦出事故后审计发现这条失效模式是AI编造的整个安全案例的可信度都会崩塌。应对方式无他就是“两个必须”。第一所有AI生成的内容必须在交付前经过“有资质的安全工程师逐条确认”。第二在内部流程中明确标注哪些内容由AI生成、AI生成的版本号、prompt记录和复核记录。这不是讲究而是功能安全审计的必然要求。AI生成的内容你可以用但你必须能证明你“审过”。5.2 把AI输出的当成最终交付物第二个坑是心态层面的。很多工程师刚开始用AI的时候会觉得“哇这个安全计划居然生成的这么好那我改改就能交了”。这个心态非常危险。我前面反复强调过AI生成的是“草稿”不是“交付物”。这个区分的本质在于功能安全的交付物不仅有“内容”还要有“过程证据”。你在评审会上讨论过什么、为什么修改某个ASIL等级、基于什么数据确定了某个S评级的假设——这些过程证据AI无法生成只有你自己知道。有一次我让AI生成了一份安全需求的初稿结果团队里一位同事直接把它当成正式文档发给了客户。客户那边立刻打回理由是“文档里的ASIL等级分配跟安全目标的推导关系不清晰缺少分析过程记录”。这件事让我深刻认识到AI生成的文档可能看起来很像最终版但它缺少的恰恰是整个功能安全论证的“灵魂”——分析过程的逻辑链条。这个链条AI给不了你它需要项目团队在安全分析活动中真实地推理、讨论和决策。5.3 AI自身也必须是安全论证的一部分最后一个坑也是目前业内讨论还不充分但极其重要的——你用AI辅助功能安全开发那么AI这个“工具”自身的安全与可靠也要被纳入到安全论证中。这听起来有点套娃但你想想本身用于开发安全关键系统的AI模型如果它本身存在偏见、样本外失效、数据漂移等问题你怎么相信它生成的建议是可靠的功能安全标准体系里对“工具的置信度”的要求已经很成熟——ISO 26262-8里就有工具鉴定Tool Qualification的内容。以前我们做工具鉴定针对的是编译器、静态分析工具、测试工具它们的特性是确定性的——相同的输入永远给出相同的输出。AI模型不是这样的它的输出具有概率性、随机性同一份需求你提交两次可能得到略有不同的分析结果。这就给工具鉴定带来了极大难度。目前行业内能给出的最可行方案是对AI工具采用“应用场景受限 人工复核 持续监控”的策略限制AI只在非决定性、辅助性的场景中使用比如头脑风暴、草稿生成对AI输出进行100%的人工复核监控AI模型在长期使用中的输出质量变化。我今天看到行业里已经有一个ISO/TC 22关于AI与汽车安全的标准化趋势后续肯定会有更明确的要求。现阶段如果你的项目决定引入AI辅助功能安全开发必须把这个逻辑写进你的安全计划里去提前跟认证机构对齐不要等到审计那天被打个措手不及。说句实在话我在功能安全行业干了这么多年见过太多“听起来很美但落不了地”的新名词。但AI这一次给我的感觉不同——它不是嘴上说说而是真真切切地改变了我的工作方式。我现在遇到一个新的功能安全项目第一反应不再是“赶紧把模板找出来”而是“先把原始需求整理好用AI过一遍看看哪里有遗漏”。这个习惯的改变是我认为“AI时代功能安全值得重做一遍”最真实、最底层的感受。这篇文章是上篇主要讲的是行业痛点、AI的切入逻辑和边界。下篇我打算写更多带代码和具体prompt的实操内容比如用大模型辅助HARA分析的完整prompt案例、FMEA知识库的搭建方法、AI辅助测试覆盖分析的实践路径以及如何跟认证机构沟通AI辅助项目的证据策略。如果你也正在尝试把AI引入到功能安全或者其他合规驱动的工程领域欢迎一起聊聊你踩过的坑和发现的机会。