ASPICE 消亡倒计时
汽车ECU设计
一个菜鸟程序猿的成长之路。116篇原创内容
公众号
⚠ 全文总长约含2400字，预计您的阅读时间为6分钟公众号：汽车ECU设计 (ID: QCECUSJ)
01
ASPICE 疯狂
最近和身边的同事交流，发现去年上的 ASPICE 项目无一例外地都停滞了。没有什么原因，就是整车厂不想搞了。
这 让 我 想 起 了 快 四 年 前 ， 我 第 一 次 参 加 ASPICE 认 证 的 时 候 （ 工作思考ASPICE）。当时的我对这个流程比较好奇，毕竟是第一次接触，只知道是一个高级版的V流程。虽然我只涉及了其中的一个很小部分，但其中繁琐的流程让我十分头痛。这种感觉只有真正做过的人，才能体会。
印象中大约是三年前，国内似乎掀起了一场 ASPICE 热。各种 ASPICE 项目蜂拥而上，其认证机构更是赚得盆满钵满。如果哪个供应商没有 ASPICE 资质，你都不好意思跟别人打招呼。
02
ASPICE 与 V模型
ASPICE 全称 Automotive Software process improvement and capability determination ，汽车软件过程改进和能力测定。它是车载软件开发的过程标准，用于欧洲整车厂对供应商进行软件过程评估。不了解 ASPICE 的朋友可以先看看这两篇文章（Automotive SPICE 简介）以及（Automotive SPICE和Automotive SPICE评估的那些事）。可以看出 ASPICE 是在传统的汽车V模型开发流程上演化出来的。
ASPICE overview
Why V model ?
关于这个问题，没有所谓的标准答案。我试着说说我自己的理解。对于汽车控制器软件开发而言，其主要原因是 需求变更少
传统汽车控制器由于被控对象以及工作特点都是非常确定的，所以其需求也是非常明确。例如 ABS 控制器软件就是为了防抱死而设计的，TCU 控制器软件就是控制变速箱换挡的。这就意味着在开发前，整车厂就会对该控制器需要实现的软件功能有着明确的要求，同时提供明确的需求输入文档，这也是V模型开发的第一步。
另外，客户的需求文档一般也具有连续性，除非是那些需求不合理的地方，不然贸然的更改就会给终端消费者造成前后不一致的使用困扰。
ASPICE真的可以提高软件质量吗？
理论上，可能可以。能提高多少，不知道。因为除非是整车厂特意要求（付钱），否则供应商是不会主动使用 ASPICE 流程来进行开发的。
ASPICE 只是针对某一个项目的过程证书，借用这个项目可以间接证明研发部门有能力达到 ASPICE 所要求的标准。可以在每次获取新项目的时候秀一下，但并不表示每次都要按照此流程进行开发。
我个人一直对 ASPICE 的指导意义保持着怀疑的态度。因为其本身定位是整车厂期望供应商所采取的软件开发模式。是否有人质疑过这种方式真的能提升供应商的软件质量？是否是专门针对供应商所量身打造的？目前也没有任何数据支持这个观点。
相同一个工程师，分别使用公司内部的流程进行开发，和 ASPICE 流程开发的Bug 缺陷率有多大差别？不知道有没有有人统计过？如果没有的话，我对于其有效性就保持怀疑的态度。
别人怎么玩？
作为新入场的电动车新势力，你说它们也玩 ASPICE 吗？现在看来并没有。如果你要说他的软件不行，但也不是到处满地跑吗？新入场的玩家，没有传统汽车人的历史包袱，运用互联网的经验，通过不断地迭代与测试，依旧可以保证软件质量，甚至更高！
80/20 软件开发流程
我个人一直以来都是对于增加开发流程就可以提高软件质量的言论 ，持有反对态度！而真正适用的应该是80/20法则，即只有 20% 的关键流程，保证了 80%的软件质量，而这些关键的流程才是我们需要重点关注的！
那剩下的20%质量就不重要了吗？并不是，但我们绝不能够把主要的精力放在这20%上面。而是应该通过自动化工具，自动化测试等方法来保证，而这个过程是不需要让研发工程师亲力亲为的。
03
拥抱变化
当前汽车软件正在从固定的功能开发转向算力为主的超级电脑。简而言之，控制器在未来就是一个算力工具人，内部的软件种类决定了其工作特点。
工作场景的多样性，就意味着需求的多样性。在未来，软件的开发与变更将更为频繁，这也就是 OTA 在汽车行业突然兴起的主要原因。
让我们展开脑洞，大胆假设，小心求证：通过OTA，移动互联网 APP的开发更新模式，将有可能在汽车上实现 比如有一个软件功能包，其功能可能才完成了80%。整车厂就可以先推送给一些体验用户进行尝鲜体验，通过后台数据的不断收集，进行持续不断地迭代更新。等到最后验证完全了，再推送给所有车主，甚至还需要付费后才能体验！现在回头来看，ASPICE 遇冷和“软件定义汽车”的兴起似乎是同时发生的。火的时候，大家一起蜂拥而上。到最后…我之所以认为 ASPICE 会慢慢走向没落，是因为它是繁琐的，是抗拒变化的。而在未来，变化将会成为主流趋势。也许将来ASPICE 会融合敏捷或者其他开发模式从而获得新生，但起码不是现在。
04
不破不立
万事万物的存在都依赖着一个根基，就好比每一栋摩天大厦都无不例外地仰仗着其稳固的基石。基石就好比是数学中的公理，是不用也是无法证明的。这个基石保证了大厦的建立，但最终也会限制大厦的高度。对于身处行业中的我们来说，一般很难觉察到基石的存在，正所谓“不是庐山真面，只缘身在身在此山中”。只有当我们真正跳出这个行业，才有可能真正发现基石存在。很显然，特斯拉，互联网造车新势力的进入，给我们带来了新的思想。顺着他们的思路，看看他们的行为，我们才有机会窥探到自己的基石。
那汽车控制器软件开发的基石是什么？也许你也发现了，那就是V模型。从我们的开发模式，流程文档，组织架构，岗位设立等，无一例外都是按照V模型的指导思想来建立的。
你是否有过很多创新的想法，但是被这V流程的条条框框限制而无法实施？V模型陪伴了我们走过了20多年，它是否还能继续承载我们这座软件大楼？
毫无疑问，只有打破这个基石，我们可能才能建立新的一座崭新的大厦。互联网造车新势力给我们传统汽车人带来了敏捷开发，但这是否就是最终的答案？这一切还尚未可知。
References
[1] 工作思考 —— 敏捷开发（1）
[2] 工作思考：不可能三角
[3] 原理性知识🌏 微 信：@氨气中的战斗机✍🏻 知 乎：@吃完饭后不刷牙👬 公众号：@汽车ECU设计
历史精华文章集合：
汽车ECU设计
一个菜鸟程序猿的成长之路。116篇原创内容
公众号
工作思考 · 目录
上一篇 下一篇
2021年终总结 再谈 ASPICE
阅读原文