智能驾驶企业通过ASPICE CL2评估：从拼算法到拼工程化的供应链入场券

一条祝贺消息刷到的时候我正在跟一个准备做ASPICE评估的团队聊差距分析。对方问了个很实在的问题“拿到CL2到底意味着什么客户会因为这个多给我们订单吗”这个问题其实不难答但背后牵扯的东西不少。这两天恰好看到有咨询机构公开祝贺某智能驾驶企业通过ASPICE CL2评估圈里人都在转。很多人可能只把它当成一条普通的“喜报”但如果你了解智能驾驶供应链的准入逻辑就会明白这条消息的分量——这不只是一张评估报告而是一个行业从“拼算法、拼demo”转向“拼工程化、拼过程能力”的明确信号。这篇文章我想从几个维度来拆这件事包括ASPICE CL2的技术含义、智驾企业为什么非闯这道关不可、评估项目实施过程中的真实链路以及咨询方在其中到底提供了什么价值。给正在准备评估、或者还在犹豫要不要做的团队一些参考。1. 一条“通过CL2”的消息为什么值得被当回事先说结论在汽车供应链里ASPICEAutomotive Software Process Improvement and Capability Determination评估结果正在变成一张事实上的“准入门票”。尤其对做智能驾驶软件的企业来说没有这个你可能连主机厂的供应商名单都进不去。1.1 智能驾驶软件不是“跑通就行”是要“说得清楚”我见过不少做智驾的创业公司早期团队十几个人代码效率极高一个季度就能出一个demo版本。但到了量产阶段问题就来了——某个传感器标定参数改了影响哪些模块哪个版本的代码对应哪一轮测试这条需求是谁提的、为什么这么设计、验证结论是什么一旦需要向客户交代这些事情靠人脑记忆是撑不住的。ASPICE本质上就是一套“怎么把软件开发过程管理起来”的行业标准它不关心你某个算法的精度有多高它关心的是你的需求有没有被完整追踪你的设计是不是从需求推导出来的你的测试是不是能覆盖设计你发现问题之后有没有闭环处理机制一句话它检验的是“你能不能稳定、可预期地交付软件”而不是“你这一次交付得怎么样”。1.2 从CL0到CL3能力等级的差异到底在哪过程能力等级从CL0到CL5绝大多数智驾企业现在卡在CL1和CL2之间。CL1叫“已执行过程”意思是事情做了但可能是靠某个人的个人能力做成的换个负责人结果可能完全不同。CL2叫“已管理过程”要求项目的计划、进度、风险、工作产品都有明确的管理机制做一步、查一步、留痕一步。我一般喜欢用一个小饭馆和连锁餐饮来打比方。CL1是小饭馆菜好不好吃取决于掌勺师傅今天状态怎么样CL2是连锁餐饮每道菜有标准菜谱、有进货验收标准、有出品检查表随便哪个店做出来口味基本稳定。智驾软件体量大了以后不可能靠“师傅手感”必须靠“流程里的稳定性”。这就是CL2最核心的价值把个人能力沉淀成组织能力。1.3 为什么这次是“智驾”公司特别值得关注智能驾驶行业有一个特点软件更新极其频繁系统边界极其复杂。车端感知、融合、预测、规划、控制加上云端的数据回传、仿真训练、模型迭代整个软硬件链路是一张巨大的网。在这张网里任何一个开发环节“失管”都可能在量产阶段变成安全事故或召回的隐患。所以当一个智驾企业能把ASPICE CL2评估从头到尾走完至少说明它的项目管理和软件开发已经摆脱了“英雄主义模式”开始用流程来保障质量。这件事对客户的意义比任何榜单排名都更实在。2. ASPICE CL2的准确含义从“能把代码跑起来”到“能交出可信的代码”CL2不是一个模糊的“管理不错”的评价它有一组非常具体的评级指标。如果你准备做这场评估建议先把这层理解透不然很容易做着做着就走偏。2.1 CL2拆开看过程管理属性与工作产品管理属性在正式评估里CL2的判定主要看两个过程管理属性一个是PA 2.1过程管理属性一个是PA 2.2工作产品管理属性。PA 2.1关注的是“过程本身有没有被管理”——具体来说项目有没有定义开发计划有没有按计划分配资源进度有没有被定期跟踪有没有偏差分析计划调整有没有经过评审这些不是靠一两个文档模板就能通过的评估师会随机抽人员访谈问你“你现在的任务是什么你的计划是怎么排的你上个月的产出和计划有没有偏差”如果现场答不上来那写再漂亮的流程文件也没用。PA 2.2关注的是“工作产品有没有被管理”——需求文档、设计文档、代码、测试报告、评审记录这些东西必须放到配置管理之下有版本、有基线、有变更记录。说白了就是出了任何问题你要能查得出来“哪个版本、哪个人、在什么时候、改了什么东西”。这个在智驾行业尤其关键因为车端软件是软硬结合、多版本并行迭代的没有配置管理和变更管理出了事故都找不到对应版本。2.2 评估过程域怎么选VDA Scope里的典型组合做ASPICE评估不是所有过程域都要评。行业里通常按VDA Scope选比较典型的组合包括系统工程类SYS.1到SYS.5、软件工程类SWE.1到SWE.6、以及若干支持类和管理类过程域比如SUP.1质量保证、SUP.8配置管理、SUP.9问题解决管理、SUP.10变更请求管理、MAN.3项目管理等。一个基础的CL2评估范围一般会覆盖需求获取、系统需求分析、系统架构设计、软件需求分析、软件架构设计、软件详细设计与单元实现、软件集成测试、软件合格性测试再加上配置管理、问题管理、变更管理和项目管理。这些过程域基本就是一个智驾软件项目从需求到交付的完整主链路。评估师会逐一对每个过程域评级最终结论就是这个项目在所选范围内达到了CL2。2.3 评估里最常见的评级结果Largely Achieved还差在哪评级分为N未达成、P部分达成、L基本达成、F完全达成。CL2的要求是大部分过程域至少要达到F部分过程域L也不行因为“基本达成”意味着还有一些证据链缺口。我见过很多团队在第一次预评估时拿到一堆L和P缺的多半集中在配置管理、需求追溯性、以及评审记录上。这里有个容易忽略的点评估师看的不只是你写了多少文档而是“文档和实际行为是否一致”。你写了一套很完整的测试策略但是测试记录里的用例编号和需求矩阵对不上这在评估师眼里就是过程没有被真正执行评级直接往下压。所以别把精力花在美化文档上要把力气花在“让真实的做事方式符合流程定义”上。3. 智能驾驶企业为什么在CL2上较劲复杂度、安全性与供应链门槛有一部分团队觉得智能驾驶公司花大力气搞ASPICE是“形式主义”。但如果你真的深入到量产项目里就会理解这其实是被供应链和安全要求倒逼出来的必然选择。3.1 多传感器融合、多平台复用的复杂度靠人盯已经盯不住智驾软件栈通常包含感知、融合、预测、规划、控制等多个层级每个层级背后还有独立的模型训练、仿真验证和数据集管理。一个量产平台往往要适配多个车型每个车型又有不同的传感器配置和算力平台。如果没有结构化的需求管理和配置管理车型一多、版本一杂开发团队很快就会陷入“改一个模块、炸三个模块”的循环。我曾经参与过模拟项目X的复盘当时那个项目就是典型四百多条系统需求两千多条软件需求测试用例倒是写了三千多条但需求追踪矩阵完全是靠一个工程师手工维护的。结果某传感器供应商更换型号之后花了三周才排查出受影响的模块清单。如果当时有ASPICE体系下的双向追溯和影响分析机制这个工作量可以压缩到半天。3.2 功能安全、预期功能安全与ASPICE是“一套组合拳”做智能驾驶的团队对ISO 26262功能安全应该不陌生但很多人会问ISO 26262和ASPICE有什么关系简单说ISO 26262回答了“安全的异常场景怎么分析和验证”ASPICE回答了“开发过程怎么组织才能支撑这些分析验证”。两者是互补关系。此外智能驾驶还涉及预期功能安全ISO 21448就是处理那些“系统本身没故障但传感器局限或算法缺陷导致的危险行为”。这一块光靠安全分析是不够的它需要完整的开发过程来保证“已知的局限被识别、被传递到需求、被测试覆盖”。ASPICE CL2提供了一个最基本的抓手需求、设计、测试之间的可追溯性。没有这个预期功能安全的论证根本无从谈起。3.3 供应链准入主机厂用ASPICE给候选供应商“排雷”现在不少主机厂在引入智驾供应商之前会直接要求对方提供ASPICE评估报告。不是所有主机厂都强制要求CL3但CL2已经是很多新项目准入门槛的“起跑线”。原因很简单主机厂不可能派出足够多的人去现场审查每一个供应商的开发流程一份由独立评估机构出具的CL2报告可以大幅降低主机厂的审核成本。所以企业做ASPICE评估表面上是“给自己一个交代”实际上是“给客户一个信任的支点”。这也是为什么当某智能驾驶企业宣布通过CL2、咨询机构公开祝贺时供应链上下游会如此关注——它相当于告诉潜在客户这家公司的软件开发过程是经过独立审核的风险是可控的。4. 一个CL2评估项目的一线实战链路从差距分析到正式评估如果你所在的团队正准备启动ASPICE CL2评估这一节可能是你最有用的部分。我按自己带过和深度参与过的评估项目把完整链路拆给你看包括每个阶段的重心、投入和常见误区。4.1 差距分析先知道自己差在哪再决定怎么走评估第一步不是找评估师来“考一场”而是先做差距分析Gap Analysis。这个阶段通常是咨询机构和企业内部质量团队一起做对标VDA Scope选定的过程域逐条看现有的流程文件、项目记录、岗位角色、工具链建设给出一个总体现状地图。差距分析的产出不是一份“你好棒/你很差”的评分表而是一个改进优先级清单。比如有些团队工具链已经不错但流程文件缺失有些团队流程文件很完整但执行记录几乎为零还有些团队几个核心过程域已经可以到CL2但配置管理拖后腿。先做差距分析能避免后面把时间浪费在“已经做得不错”的地方集中火力补短板。这个阶段最容易犯的错是以为差距分析必须“等到项目差不多做完了再做”。我的建议恰恰相反最好在你的项目还处于需求阶段时就启动差距分析这样后面可以通过真实项目自然沉淀出符合ASPICE要求的工作产品。否则到了项目后期再补文档补出来的东西会跟实际脱节评估师一访谈就露馅。4.2 建立流程体系模板、角色、工具链三件套差距分析做完后通常会进入流程体系建设阶段。这一阶段的核心工作是把组织级的流程文件定义出来包括开发流程、质量管理流程、配置管理流程、问题解决流程、变更管理流程配套岗位角色和职责说明然后把流程落到实际的工具链里。工具链选择方面需求管理工具比如行业常见的ALM类工具、配置管理工具如Git配套的版本管理、问题跟踪工具缺陷和问题单的流转是三件套。我不建议在这个阶段追求“一步到位全上最重的平台”。对大多数智驾团队来说轻量起步、工具扎口、快速落地比选一个功能完整但实施周期长的平台更实际。你可以先用现有工具把流程跑起来再逐步迭代完善。模板的作用容易被低估。一个评审记录模板、一个需求变更影响分析模板、一个测试准入准出检查单看起来不起眼但对团队的“行为塑造”作用非常大。模板本身就是一种流程的物理载体工程师打开模板就知道“这一步要我做什么”。很多团队流程文件讲得头头是道落地时全靠一堆空白Word那执行必然走样。注意流程文件不要写得像天书。我见过一份配置管理流程二十多页各种术语堆砌连配置管理员自己都说不清“基线建立”和“快照”的区别。好的流程文件应该是“一个新人照着做也能做对”的程度而不是“写得越复杂显得越专业”。4.3 试点项目试运行用真实项目“养”证据体系建完后必须选一个真实项目作为试点来跑新流程。对ASPICE CL2评估来说证据都来自真实项目的执行记录计划会议纪要、任务跟踪记录、评审结论、测试报告、问题清单、变更请求单、配置基线记录……这些不会凭空产生必须依托真实项目去积累。试点项目选得巧不巧直接影响评估顺利程度。我的经验是选一个“开发节奏正常、参与成员稳定、时间窗口够用”的项目比选一个“最新最酷但天天救火”的项目要合适得多。因为评估看重的是过程执行的完整记录而不是技术难度有多高。项目再简单只要过程证据链完备评级一样能拿到F项目再复杂如果天天处理紧急插单过程被打断得七零八落记录自然很难完整。试点运行阶段通常会暴露出一堆“流程与实际冲突”的问题。比如开发团队嫌评审流程太重一个小改动也要走完整审批测试团队发现需求矩阵维护工作量过大干脆放在一边。这些冲突是需要企业内部过程改进组EPG和咨询团队共同去消化、调整、迭代的。流程不是越严越好而是“和实际工作方式咬合”才好。4.4 预评估与正式评估现场访谈里的“照妖镜”正式评估前通常会在前4到8周做一轮预评估Pre-assessment。预评估和正式评估的流程几乎一样评估师按评估计划访谈项目成员、抽查工作产品、核对客观证据然后逐过程域给出预估评级。预评估最大的价值在于“提前暴露问题”。很多团队第一次预评估拿到大量L和P的时候第一个反应是“哦我们文档还不够”第二个反应才是“原来我们真正的问题是过程执行不一致”。比如流程文件里写的是“编码前必须通过详细设计评审”但实际代码仓库里有一半模块根本没有对应的评审记录这种不一致在现场访谈里很致命——评估师不会因为你补了评审记录就放过他们要看到这个项目在“真实发生的时间点”上执行过这些评审。正式评估一般持续三到五天由拥有intacs认证资质的首席评估师带队按VDA评估模型逐条打分。过程域访谈通常采用“三角验证”评估师先看流程文件和计划再抽工作产品看执行痕迹最后面对面访谈不同角色的成员三者对得上才给F。所以我的建议永远是别临时突击补文档宁可如实承认“这个活动当时确实没做好”也不要让流程文件与实际执行之间出现逻辑矛盾。5. 咨询机构在其中的真正价值辅导“长肌肉”不是代笔“化妆”标题里另一家公司——那家高调祝贺的咨询机构——其实才是很多准备做评估的团队真正要研究的主体。你需要弄清楚咨询公司在一场ASPICE CL2评估里到底起什么作用以及怎么判断哪类咨询机构适合自己。5.1 为什么不能完全自评独立性与客观性要求ASPICE评估本身要求评估结论独立于被评估方。这不是“不信任你”的问题而是过程能力的判定必须基于一致的标准和没有利益干扰的视角。自己给自己评评估师和被评估方在一个组织里很难做到客观客户和主机厂看到一个自评报告也不会认。所以正规路径一定是引入独立的评估方来做正式评估。而评估方和咨询方往往是两个角色咨询方负责辅导企业改进评估方负责最终判定。行业内也有机构同时提供咨询和评估但正式评估必须有独立的评估师团队来执行确保评级结果的公信力。5.2 咨询机构的核心交付物流程体系、培训、陪跑、预评估咨询机构在CL2项目中的角色可以理解成“企业的过程能力陪练”。核心交付物通常包含四块第一流程体系文件。咨询团队根据企业现状和VDA Scope要求输出一套适配的流程文件和模板而不是给一套“通用的PPT模板库”。好的咨询师会先理解这个智驾团队的组织架构和产品特点再设计流程。第二专项培训。包括ASPICE标准解读、评估流程讲解、工具链使用方法、以及每个角色的过程职责。你经常能看到某些企业全员培训做完工程师依然不知道“评审记录写了交到哪”——这不是培训不到位而是培训内容与企业的实际流程脱节。第三EPG辅导与过程改进。咨询团队要和企业内部过程改进组一起工作每月或每双周回顾试点项目的执行情况分析偏差原因调整流程设计和工具配置。这个阶段最考验咨询师功力能不能看出“问题根源其实是某个开发经理从来没接受过流程管理训练”而不是简单地更新模板。第四预评估。在正式评估前组织一轮实战模拟评估给企业一个“考试彩排”。预评估的严格度直接影响正式评估的心态和补课方向一个负责的咨询机构绝不会在预评估里放水。5.3 怎么判断咨询团队靠不靠谱三个问题试探挑咨询机构的时候我建议面对面问三个问题。第一个你们对我们这种智能驾驶公司的业务流程熟悉到什么程度如果对方只是背ASPICE条款答不上来感知、预测、规划这些模块的开发协作边界那多半会把流程设计得很“教科书”很“通用”落地时团队会非常痛苦。第二个你们的咨询方法论是“给模板”还是“陪跑”这个问题的判断标准是合同里有没有包含定期的EPG辅导、预评估、以及评估后的整改支持。如果对方只给你一套模板让你自己去做那和买一本书没啥区别。第三个你们的评估师有没有智驾或嵌入式软件项目背景这不是说非要有但能极大降低沟通成本。评估师如果完全不懂智驾软件怎么开发他在访谈时可能会把大量时间浪费在理解“你们在做什么”而不是辨别“你们做得怎么样”。个人经验我见过最顺利的CL2项目咨询团队和企业EPG小组几乎是“坐在一起办公”的。咨询师不是每周来讲一次课而是在试点项目的例会里直接旁听、现场指出问题、当场调整模板和流程。这种方式磨合出来的流程文件最后评估师看了都要点头。6. 通过CL2之后怎么走维护、扩展与向CL3演进回到最开始那个团队的提问“通过CL2之后会怎样”我的回答是它会打开一些门但不会让所有事情一劳永逸。CL2是一次点检不是终身免检。6.1 证书只是入场券客户审核照样会来拿到CL2评估报告之后主机厂或大型Tier 1供应商在导入新项目时确实会缩短对候选供应商的过程审核流程。但注意是“缩短”不是“跳过”。客户通常还是会派一两个QE来做一次现场审核重点抽查你最近项目的执行记录、问题闭环情况和变更管理规范甚至会随机找工程师访谈验证你的过程是“活的”而不是“评估时临时表演的”。我自己吃过这个亏。某个项目通过CL2评估后团队以为万事大吉松懈了半年结果客户来现场审核时发现一个模块的评审记录缺失直接开了严重不符合项逼着我们补了一轮内部审计。后来我把“评估后的过程持续性维护”列为项目质量组的常设任务每个月抽一个过程域做内部合规性审视半年一次全范围的自我评估客户再也没挑出过硬伤。6.2 从CL2往CL3走组织级标准化才是真正的深水区CL2管的是一个项目“在管理状态下”运行CL3要求的是整个组织“有标准流程、有流程资产库、能在不同项目间复用和裁剪”。如果说CL2是从“人治”跨向“法治”那CL3就是从“项目治理”走向“组织治理”。对智驾企业来说CL3的难点通常不是流程本身而是多个项目并行时的经验复用机制。比如一个做矿山无人驾驶的项目和一个做城市NOA的项目虽然技术栈不同但软件开发过程里有大量共性的东西可以沉淀成组织级资产。CL3要求你把这些资产显性化过程的标准定义、性能指标、裁剪指南、经验教训库、工具链模板。这活儿是典型的“慢功夫”没个一年半载扎不下去。我接触过的团队里真正拿到CL3的智驾企业其实还不多。大多数企业的合理路径是先稳定CL2一段时间把组织级过程资产库搭起来再启动CL3的差距分析。硬要一步到位往往会在“量化分析”和“过程绩效指标”上卡很久。6.3 质量文化建设评估报告之外真正值钱的是团队的习惯最后想聊一个容易被忽略的点。很多团队评估前想的是“怎么凑够证据”评估后想的是“以后怎么少填点表”。但真正经历过评估、并且持续获益的团队慢慢会把流程里的动作内化成日常习惯。比如新需求进来时先想“影响分析怎么做”改代码之前先看“配置管理基线在哪”测试开始之前先问“需求可追溯矩阵更新了没有”。这些习惯一旦形成评估报告反而成了次要的东西。这也是为什么我一直强调寻找咨询机构时要挑那种“帮团队建立能力”的而不是“帮你造一批模板”的。评估证书有效期是短暂的但团队做事的方式会一直伴随组织往前走。CL2这个节点我更愿意把它理解成一个“过程能力体检日”——项目辛苦改进了一年由独立评估师来告诉你你们这套做法到底能不能撑起量产的复杂度。如果你所在的团队正准备启动这条路我的建议很简单别把它当成一次应付客户的闯关也别把它当成一场文档补写运动。它是重新梳理你团队“怎么做事”的机会。这个投入不管你以后做不做ASPICE评估都会在每一个跟质量有关的环节上回报你。