功能安全量产落地的三座大山（四）

周期与成本（一）

交付周期的重要性

我们先来看一些汽车企业高管的公开言论：

在未来五年中，沃尔沃汽车公司将每年推出一款纯电动汽车，力争到2025年纯电动汽车占全球销量的50％，其余为混动车型。

——沃尔沃总裁兼首席执行官哈坎·萨缪尔森

未来5年，通用汽车在全球推出的30款电动车型……通用汽车将提前完成12款全球电动车型的开发工作。

——通用汽车首席执行官玛丽·博拉

以后，我们需要考虑新功能的发布周期，几天甚至几个小时，而不是几个月。

——戴姆勒研发部门首席信息官席格马尔·哈西

大家感受到了吗？市场的节奏早就不再是以前三、四年推一款新车的那种沉稳的风格了。现在各大车企都在加快推出新车型，纯电领域已经基本做到了一年一款甚至多款新车。

从2012年的Model S搭载整车OTA技术以来，到现在特斯拉已经通过OTA为其推送了二三十次的大版本软件升级，其中涉及了人机交互、动力系统、自动驾驶等众多方面，完成了钥匙卡漏洞修复、续航里程提升、提高最高速度、提升乘坐舒适度等功能调整。这在传统的汽车研发流程里几乎是不可想象的。从某种角度而言，Model S的研发在其量产之后一直持续进行着，而且研发交付周期很短，因为软件更新频率很高。

可能当初谁也不会想到，特斯拉，这家从美国硅谷横空出世的电动汽车制造商会以绝对领先的优势超越丰田、大众等传统车企巨鳄，成为全球市值最高的汽车制造商。不管你愿不愿意承认，事实上特斯拉已经取得了阶段性胜利，其采用的很多创新理念和技术正引领业界潮流。特斯拉从一个科技公司而非汽车公司的视角重新定义了电动汽车，使得各大车企感受到了巨大压力。

（截至北京时间11月24日9点）

市场竞争如此激烈，如果你不想被淘汰，就必须跟上节奏：

• 快速交付产品，抢占市场；

• 及时了解市场需求，根据用户偏好做出功能优化；

• 迅速修复软件bug，提升售后服务效率；

• ……

于是，我们今天要讨论的问题就出现了：产品研发周期这么短，连常规控制功能的交付压力都如此之大，还怎么做功能安全？

事实上交付周期对功能安全是一个巨大的挑战。众所周知，ISO 26262标准依照“V”模型将系统、软件、硬件等不同层面的工作组织到一起，严格来说在上一个阶段必须做足功课才能进入下一个阶段。这种模式很严谨，但也很死板。按部就班、步步为营的工作方式，可能真的无法适应需要快速交付产品的市场节奏。还记得笔者之前提到的悖论吗？如果你的产品失去了市场，那就意味着很少人会使用，于是也就不需要做什么功能安全了，因为人员伤亡风险很低。所以，功能安全也需要适应市场节奏，做到快速交付。

案例分享

在这几年的项目经历中，笔者已经不止一次遇到过由于赶不上SOP时间，暂缓或停止功能安全任务的事情了。这其实也能理解，先有常规控制，后有功能安全。如果连基本功能都不成熟的话，产品根本就达不到投放市场的条件，又怎么去抢占市场呢？所以产品交付肯定是第一位的。

坦率的说，基于传统“V”模型来实施功能安全，在面对周期只有一年、甚至更短的项目时，笔者也没有太好的办法。笔者曾经尝试过将不同的安全任务并行穿插，比如说TSC开发和硬件FMEDA同步进行、SSR开发和软件编码同步进行等方式。但总的来说效果并不明显，因为项目周期实在是太短了，而“V”模型又很死板，在这个框架内能够做出的调整非常有限。所以笔者认为，必须采用一种快速的、灵活的开发模式，才有可能适应项目的交付要求。

实施建议

“物竞天择，适者生存”。今天连丰田、大众这样的传统汽车巨头都已经开始转型，时代真的变了。作为一名功能安全的学习者、思考者、实践者，笔者认为传统的功能安全开发方式已经不太适应新的市场环境，需要做出调整。而且随着互联网、IT等科技企业不断涌入汽车行业，笔者有一种强烈的预感：敏捷开发将逐渐成为汽车软件开发的主流方式，也将逐渐成为功能安全软件开发的主流方式。通过敏捷开发，功能安全（主要是软件）可以做到快速交付。这是一个很有意思的话题，有机会再与大家展开讨论。

To Be Continued

说明：

* 文章仅代表作者个人观点，不代表'仨人谈起'立场