在汽车行业里，经常听到的两个词“车规级”和“量产”，似乎达到了这两个境界就能羽化成仙。不可否则，达到车规级和量产水平说明在质量方面达到了行业成熟水平，可以批量生产供用户使用，经受住了行业多年沉淀经验的考验与历练，但是针对智能汽车的基础软件智能驾驶操作系统，其本身是智能网联汽车行业发展诞生的新产物，又是软件化的无形产品，不涉及生产制造等工艺流程，如何证明它的质量达标呢。
经常听到各种质疑的声音“智能驾驶操作系统满足车规级要求吗”“智能驾驶操作系统能达到量产水平吗”……首先，严格的说，“车规级”这个词不能乱用（如果只是为了表达符合汽车行业基本规定，作为一个广义词汇在非正式场合下的随便说说勉强可接受），真正的车规级是聚焦硬件器件及设备，按照相应标准进行一系列严苛实验达到标准要求，经过车规级认证才能配得上“车规级”这个词，所以对于智能驾驶操作系统，今天不谈车规级，而来聊聊如何达到量产水平，即对于纯粹的基础软件什么是量产水平。最不能接受的一类观点是一边指责这个软件不能满足量产，一边又无法说明什么样的软件才叫满足量产；其次不能接受的观点是“只有已经量产过的产品或有大量量产车型应用多年的产品才算满足量产水平”，因为永远不能让默守陈规的思想将一个新生事物扼杀在摇篮中，但是作为多年的安全质量从业者，本身对安全级产品有着无比的敬畏之心，团队成员们经常自嘲“我们是在各种产品评审及发布审核中签字最谨慎的人”，在别人看来好像总要找点茬似的，但在我们自己看来每一次给出的结论都是承担着责任，需要真正把客观情况具体说明。所以对于智能驾驶操作系统如何达到量产水平这一话题，我们一直在思考与总结，本文仅代表个人见解，抛砖引玉。
如果对于一个汽车零部件或一个控制器而言，如何达到量产要求目前行业有成熟的经验、成熟的法律法规、成熟的标准规范可借鉴参考，是否达到量产要求也便于衡量。但是对于智能驾驶操作系统，首先它是一款软件，软硬解耦，所以一切基于硬件有形产品的量产水平度量经验都无法借鉴；另外，它作为一款基础软件，与应用解耦，所以基于实车应用功能、性能的量产水平度量也不能完全客观证明其量产水平。那么，如何衡量智能驾驶操作系统软件达到量产水平呢。基于最近的思考与实践，总结了以下度量维度：
终端用户的满意度及反馈数据基准对标。
满足相应法律法规标准规范要求。
符合上级客户的需求，功能、性能、接口满足应用要求。
软件开发流程的质量保障，通过流程的规范性保证功能、性能、接口高质量的设计与实现。
01 终端用户的满意度及反馈数据基准对标
这个终端用户指的是消费者，从消费者使用体验的反馈数据中积累有效数据和经验，这是一切产品质量度量的出发点和落脚点。一切所谓的达到量产水平，不过是说明批量生产售出后，产品质量能够满足终端用户期望的需求而已。
从终端用户获取的反馈数据比较宏观，这些数据还要进一步分解到智能驾驶操作系统层面，真正形成智能驾驶操作系统产品的量产合格的经验数据积累，基于终端用户满意度的底线得出智能驾驶操作系统的质量基准，作为相关法律法规或标准的最低要求，用于后续智能驾驶操作系统产品质量的对标分析与评价。智能驾驶操作系统是否达到量产水平，终究是考验其质量水平是否能达到终端客户满意，但是这个衡量维度需要全行业长时间的积累与沉淀。
所以针对智能驾驶操作系统的质量水平衡量，“终端用户的满意度及反馈数据基准对标”这个衡量维度个人认为很关键，但是现阶段不可作为智能驾驶操作系统的质量衡量标准或是否达到量产水平的标准，因为永远不能假想一个可能不合理的指标来制约牵绊一个正在快速发展的产品。
02 满足相应法律法规标准规范要求
法律法规标准规范是一个行业的智慧精华体现和长期经验总结，针对一款量产产品，满足相应的法律法规及标准规范要求是必不可少的。对于智能驾驶操作系统，目前相关法律法规及标准规范暂时还不健全，因为一切的标准规范也应是源于实践积累，仍然需要时间沉淀，所以只能随着法律法规及标准规范的逐步发布与健全，逐步纳入为智能驾驶操作系统量产的度量指标，但是当相应制度还不具备时，默认为无约束放行，只有这样才能保障一种新型产品进入市场，再从市场落地化实践中补充法律法规标准规范的不足。
以上两个关于智能驾驶操作系统是否满足量产的度量指标，现阶段并无法真正作为衡量基准来推行，那么现阶段对智能驾驶操作系统是否满足量产就无法评判吗？当然不是。只是这种度量一定要从智能驾驶操作系统的本质特性出发，真正从本质上去挖掘它的质量水平，而不能盲目的用传统车企衡量tier1产品的教条主义去看待，不同的事物有不同的属性。如果用评判传统控制器或应用功能的角度方法来评判智能驾驶操作系统的质量水平是有失偏颇的，就像河流最终会汇聚成大海，但是我们不能拿大海潮起潮落的规律来评估河流，也不能通过评判大海的波涛澎湃程度来质疑河流的力量。
03 符合上级客户的需求，满足应用要求
智能驾驶操作系统的上级客户是tier1或OEM，其核心使命在于满足上级客户快速自主开发应用软件的需求，并且对于一个产品来说，最重要的价值就是满足客户需求，这里的需求不光是功能需求，还包括性能需求，接口需求等一切能够代表客户对产品的期望内容。
智能驾驶操作系统作为基础软件，支持L2到L4级自动驾驶应用。因此，对于智能驾驶操作系统符合上级客户需求，满足应用要求是一项极其巨大的工程，决定这个工程成败的是需求管理。
首先是识别需求，产品定位要准确符合客户的要求，如果客户想要一个产品A，在产品需求转化时变成了A’或直接变成了B，那么后面做的再好也是徒劳，不仅如此，智能驾驶操作系统不是为单一客户开发的定制化产品，而是基础软件产品，需要同时支持满足多种客户多种应用要求。因此，在需求上如果投机取巧一定不会创造出好产品，最重要的是潜心探索客户需求，深入了解客户要什么，思考清楚自己做什么，并且竞品能做到什么程度，在需求符合度上如何超越竞品。
对于智能驾驶操作系统这样的新概念新产品，前期无明确的客户需求时，需求不稳定是在所难免的，在不断的摸索和试错中寻求需求的逐步明朗，但无论如何，产品需求一定要站在客户的角度去思考，而不能站在营销或研发的角度去制定，不然是无法创造一个好产品的。
近两年来，随着智能驾驶操作系统的逐步推广，大家对其认知理解加深，产品需求随着产品迭代逐步明确化，与OEM和Tier 1的合作方式也逐渐清晰化，所以满足客户应用软件开发对基础软件的要求，支持在此基础上开发的应用能够达到量产水平，是智能驾驶操作系统达到量产水平的准则。
需求明确后就是要确保需求准确无误的落地化实现，双向追溯是确保需求正确实现的有力手段，这里的双向追溯不是指形式主义的一个追溯表或追溯矩阵，而是从需求到设计到测试真正对应匹配，确保每条有效的需求都落到实处掷地有声。
测试验证是衡量产品是否满足需求的重要方式，但是智能驾驶操作系统又会面临一个问题，作为基础软件，其本身并不带有应用功能，在此基础上开发应用功能后，在实车测试验证过程中的性能表现并不能归结为智能驾驶操作系统的优劣。
那么如何评判智能驾驶操作系统的质量是否满足量产要求呢？
基础软件层面全面、充分的逐级软件测试结果是很重要的依据！
由于智能驾驶操作系统的复杂和庞大，结合ICT行业经验，建立全面高效的自动化测试也是提升质量的一种高效手段。
智能驾驶操作系统与应用软件开发的适配性也极其重要！保证在此基础软件基础上可以实现各种应用功能开发，并且在功能、性能、接口上都能满足应用功能对平台基础软件的要求。这同样也需要大量的测试验证结果才能有结论。
结合应用功能的实车测试验证必不可少，实车表现也是智能驾驶操作系统是否能够满足量产水平的重要依据，但前提是确保应用功能软件的质量水平以及其他接口设备是满足量产要求的，这样才能准确衡量智能驾驶操作系统的质量水平。千万不要陷入评判误区，把应用功能的不足归结为智能驾驶操作系统的质量问题。
04 软件开发流程的质量保障
软件作为无形产品，规范化流程是软件质量的重要保障。
一些高科技类软件企业的通病是重技术轻流程，认为质量是可以完全通过技术保障的，而忽略了软件的属性。软件的特质在于错误无规律可循，且不可量化和预测，只有通过流程保障才能将错误和失效降低，所以流程是软件质量保障的关键要素。
另外，在小规模团队做小规模产品开发时，有时候没有通过质量流程保障，也依然可以开发出高质量产品，达到不错的效果，因此有时候会有一个误区，认为质量是可以靠人的能力靠技术本身保障，而不需要强调流程。但是这种经验一旦用在智能驾驶操作系统这种大规模软件开发，往往前期刚起步时还能够有序开展，但随着规模增大，业务增加，如果流程强化意识没有深入人心，整体开发节奏一定会变得杂乱无章，尤其对于智能驾驶操作系统这种基础软件，作为平台产品开发主线的同时，可能会并行工程项目同步实施，不同项目交错，产品需求交织，研发团队庞大，跨部门跨团队协同事务众多，代码量巨大，只有通过高效、细致、严密的过程管控才能保障智能驾驶操作系统的质量达到量产要求。
永远没有一个团队全部都是顶尖一流的人才，在一个团队中，一定具有能力梯队，而流程就是能够帮助在混有二流、三流工程师的团队中依然可以开发出一流产品必不可少的武器。
近年来ASPICE在汽车行业得到广泛推崇，在真正深入接触ASPICE前，我曾经也存在误解，以为它是一个纸老虎，以为它很刻板，并且感觉有些要求过于繁琐。但是在后面彻底的深入实践中，越来越感受到它是能够有效保障软件质量满足量产水平的。但这也不意味着ASPICE中所有的要求都要毫厘不差，基于我们的实践经验总结，智能驾驶操作系统的质量流程应该是在ASPICE基础上取其精华取其糟粕，ASPICE的灵魂在于保障需求的正确实现与落地，保障整个项目团队目标一致，ASPICE并不是刻板的要求，对于怎样设计开发也没有固定的标准，它需要研发人员真正理解自己所做的每一步活动，真正在每一步活动中把控好产品的质量。
近几年来，敏捷开发也很火热，经常有人把ASPICE与敏捷开发做对比，但是在我看来，它们并没有本质的冲突，只是敏捷开发更适用于互联网，而ASPICE更适用于汽车行业。他们其实也都是V模型，只是ASPICE是一个大V模型，敏捷开发是一个一个小V模型；ASPICE也是允许需求的多轮迭代的，敏捷开发也要保证关键文档输出的，不能把ASPICE作为刻板繁琐的代名词，也不能把敏捷作为偷懒不负责任的遮羞布。
针对智能驾驶操作系统，基于实践经验，我更推荐ICT和智能汽车行业融合的软件质量保障流程，我们践行的是ASPICE精神而不是纯粹ASPICE标准，取ASPICE标准精华作为软件开发流程基础，同时可借鉴其他行业其他流程的先进性，在流程上增加灵活性和高效性改良，并且在实践中不断改进，这一定是智能驾驶操作系统满足量产要求的必要条件。
写在最后
关于投稿
如果您有兴趣给《九章智驾》投稿（“知识积累整理”类型文章），请扫描右方二维码，添加工作人员微信。
注：加微信时务必备注您的真实姓名、公司、岗位
以及投稿意向等信息，谢谢！
“知识积累”类稿件质量要求：
A：信息密度高于绝大多数券商的绝大多数报告，不低于《九章智驾》的平均水平；
B：信息要高度稀缺，需要80%以上的信息是在其他媒体上看不到的，如果基于公开信息，需要有特别牛逼的独家观点才行。多谢理解与支持。
