ARTICLE · 1202876
车辆开发流程——软件时代,质量人必须读懂的底层逻辑:
导读：
前面我们用10篇文章，把车辆电子系统的概念、构成、五大子系统和系统架构过了一遍。从这一篇开始，我们进入车辆开发流程。你会发现，所有谈“质量”的底层逻辑，都藏在这个流程里。为什么汽车行业要“分而治之”？为什么软件越来越重要？为什么成本、生命周期和安全，会把软件开发逼到极限？
一、驾驭复杂性的基本思路：分而治之
随着车辆功能数量增加、网联化趋势、车辆可靠性/可用性/安全性要求的不断提高，以及变体和可扩展性的不断丰富，汽车研发的复杂性也在不断提升。
为了驾驭复杂性，必须在开发过程中植入一套确定的程序。
业界长期以来采用的思路是：“分而治之”。
二、车辆开发概述：从子系统到整车
汽车的开发流程中，首先会将汽车分割成动力总成、底盘、车身、多媒体和驾驶辅助等子系统（图1.13）。
然后再进一步将各子系统划分为次级子系统和组件。
主机厂和供应商会按照分工并行开发这些组件并测试，随后再将各子系统集成为上级系统并再次测试，如此递进，最终集成为整车。
但这样做的前提不仅是明确子系统和零部件的开发分工，同时还要确保在零部件安装空间、车辆功能、生产等方面便于开展对系统的分区和集成合作。
此外，汽车行业的一大特点是主机厂和供应商之间的跨公司合作开发，因此不同的分工还必须在主机厂和供应商之间明确分配。
同一款车辆存在不同变型，又给开发流程增加了另一个维度。这意味着主机厂和供应商在所有系统级别上，很可能要面对多项项目并行开发的情况。
无论哪种合作维度，都需要合作双方针对各问题及其解决方案带给系统的影响达成共识。同时，彼此在项目中的能力和责任也需定义清晰。
这里向读者提供两种实践中常用的整体开发方法：
从技术维度出发的机电一体化方法；
从项目组织管理维度出发的系统工程方法。
除了上述维度，主机厂和供应商的合作还需考虑商务因素，尤其是产品追责和专利归属等法律问题。
三、电子系统开发概述：同样的逻辑，更细的颗粒度
车辆电子系统的开发与车辆开发类似。
首先也需要将其划分为若干子系统，包括：
控制器（硬件和软件）
设定值发生器
传感器和执行器
然后分工完成开发和测试，并逐步从局部集成至完整电子系统（图1.15）。
同样的，在处理划分和集成问题时，也会涉及跨子系统的合作。
电子系统的开发流程设计需要遵循两个原则：
第一，流程应该建立在久经检验的基本流程模型之上。 例如：
能力成熟度模型集成（CMMI）
软件过程改进和能力评定（SPICE）
V模型
敏捷开发方法
第二，流程也应支持实现主流的汽车技术规范。 如：
AUTOSAR（汽车开放系统架构）
JASPAR（日本汽车软件标准化组织）
OSEK（汽车电子类开放系统和对应接口标准）
ASAM（自动化及测量系统标准化组织）
此外，还可在流程中穿插一些发展成熟的程序和方法，用以提升开发效率和质量并降低开发成本，如仿真方法或快速原型方法等。
无论进行整车开发、电子系统开发还是软件开发，都会牵扯到开发者之间的大量交互。
四、从硬件到软件：为什么软件成了主角？
电子系统的发展，总体上遵循由硬件解决方案向软件解决方案转变的趋势。
软件解决方案在实现电子系统功能方面具有天然优势。
通过软件实现对于系统的闭环、开环控制或监控，可以使子系统在诸如：
自适应/自学习算法
安全性保障方法
诊断
等各方面具有最高的设计自由度。
这是其他技术载体，尤其是那些直接受安装空间和制造工艺影响的技术方案所无法企及的。
因此，用软件来实现汽车功能，为主机厂和供应商都带来了巨大的潜在商机，有助于它们在激烈的行业生态竞争中脱颖而出。事实上，在其他工业领域我们也能发现类似的趋势。
为呼应这一趋势，本书重点关注软件功能开发及汽车电子系统部件的集成。
与其他工业应用领域相比，车辆控制器的软件开发有着截然不同的要求和边界条件。
一个典型例子是：撰写软件功能规格说明（specification）和实现软件功能之间的区别。
前者的目标，是尽早在最大范围内明确用于车辆运行的功能；
后者则需要考虑控制器的所有技术参数，并对照规格说明进行测试，同时还需考虑生产和售后服务的问题（例如支持售后软件诊断和刷新的功能等）。
五、成本：为什么软件开发者要优化到“整数算法”？
考虑到汽车规模化生产的特点，单车成本主体上取决于单车的零部件成本。
因此整车的价格压力，最终会传递到零部件的成本节降上。
这意味着车企会对控制器内存空间和算力严格限制，进而要求软件开发者必须考虑到代码的执行效率优化，比如用整数算法来替代浮点功能。
六、产品生命周期：一款车25年，软件怎么办？
通常车辆的研发时长在3年左右，从投产到停产持续约7年，在最后一辆车下线后仍需继续15年左右的运营和售后服务。
因此，一款车的生命周期可长达25年（图1.16）。
然而对于电子零部件，其技术的迭代速度远高于整车产品的生命周期。
这为零部件的售后配件供应带来了极大挑战，通常需要在开发阶段就将售后运维因素纳入考量。
同样，电子零部件的快速迭代也会影响到软件架构设计。车企为了让软件功能维持持久的生命力，就必须使软件和不同的硬件兼容。
这一诉求推动了软件架构的标准化，也引发了业界对软硬件解耦这一话题的关注。
与硬件相比，软件的迭代周期更短。
将软件刷新技术与控制器网络化技术相结合，即可完成：
现场刷新（通过车辆OBD端口）
远程刷新（OTA）
从而避免了更换控制器的极高成本。
更短的迭代周期，也意味着在软件开发时必须要考虑到车辆全生命周期相当长时间内的维护工作。
七、安全要求：为什么汽车软件的安全门槛这么高？
与机械或电气等其他行业相比，车辆功能对安全性的要求极高。
这是因为在车辆出现事故时，人类（驾驶员和乘客）位于事故发生区域内的概率为100%，导致人员伤害的概率更高；
而在一般机械工程领域，如果采取适当的阻隔措施或安全装置，即可持续保障人员远离事故发生地。
基本的安全注意事项在 ISO 26262 或 IEC 61508 等标准和 ECE法规 中已有明确规定。
如今在乘用车领域，具备基础的功能安全保证，已经成为车辆获批上路的前提条件。
电子系统和软件功能对车辆安全的影响在不断增加，从：
行驶情况分析（如车速显示）
情景评估（如结冰警告）
行动建议（如导航）
行动执行（如加速或制动干预）
几乎无所不包，甚至还涉及主动的驾驶干预（如主动转向）。
因此，功能安全分析以及安全概念设计，已成为功能及软件开发的必需环节。
但凡有较高的安全要求，就必须采取故障识别和故障响应措施。
而系统冗余设计，是故障识别和响应的最有效措施之一。
因此我们可以认为，对功能安全的高要求，加速了汽车分布式网联系统的演变。
此外，高安全性也对开发流程和工具提出了特殊的要求，包括：
开发流程
开发工具
标准化软件组件（例如适用于高功能安全等级的经典AUTOSAR操作系统）
八、写在最后：质量人的五个思考
这一篇内容很密，但我建议每一位汽车质量人，重点思考五件事：
分而治之是基础，但集成才是难点。 质量策划不能只盯着零部件，必须盯着集成。
软件成为主角，但规格说明和实现是两回事。 质量验证必须覆盖这两层。
成本压力会直接传导到软件代码。 内存、算力、执行效率，都是质量风险点。
25年生命周期 vs 快速迭代的电子件。 软硬件解耦、OTA、售后刷新，都是质量新战场。
安全要求极高，功能安全不是可选项。 ISO 26262、冗余设计、故障识别与响应，必须进入开发流程。
下一期，我们继续深入开发流程中的具体方法和模型。
我们下篇见。
