一、车辆开发概述
汽车的开发流程中，首先会将汽车分割成动力总成、底盘、车身、多媒体和驾驶辅助等子系统（如图1）。
图1 车辆功能和控制器网络
然后再进一步将各子系统划分为次级子系统和组件。主机厂和供应商会按照分工并行开发这些组件并测试，随后再将各子系统集成为上级系统并再次测试，如此递进最终集成为整车。
但这样做的前提不仅是明确子系统和零部件的开发分工，同时还要确保在零部件安装空间、车辆功能、生产等方面便于开展对系统的分区和集成合作。此外，汽车行业的一大特点是主机厂和供应商之间的跨公司合作开发，因此不同的分工还必须在主机厂和供应商之间明确分配。
同一款车辆存在不同变形又给开发流程增加了另一个维度。这意味着主机厂和供应商在所有系统级别上很可能要面对多项目并行开发的情况。
无论哪种合作维度，都需要合作双方针对各问题及其解决方案带给系统的影响达成共识。同时，彼此在项目中的能力和责任也需定义清晰。这里向读者提供两种实践中常用的整体开发方法：从技术维度出发的机电一体化方法以及从项目组织管理维度出发的系统工程法。
除了上述维度，主机厂和供应商的合作还需考虑商务因素，尤其是产品追责和专利归属等法律问题。本文仅聚焦于技术维度，对此不做展开。
二、电子系统开发
车辆电子系统的开发与车辆开发类似。首先也需要将其划分为若干子系统，包括控制器（硬件和软件）、设定值发生器、传感器和执行器等，然后分工完成开发和测试，并逐步从局部集成至完整电子系统（图2）。同样的，在处理划分和集成问题时，也会涉及跨子系统的合作。
电子系统的开发流程设计需要遵循两个原则。
首先，这一流程应该建立在久经检验的基本流程模型之上，例如“能力成熟度模型集成”（CMMI®）、“软件过程改进和能力评定 （SPICE） ”、V-模型或敏捷开发方法。
从实践角度对上述四个概念进一步澄清。通常在一个汽车软件开发组织中，符合 ASPICE 的流程都可在符合 CMMI 的基础上继续深化其可追溯性的严苛程度而实现。而 V 模型（或瀑布模型）是一种通用的软件工程方法，而非标准，ASPICE 及 CMMI 流程均以 V 模型为核心理念。敏捷开发方法则强调开发效率，如经过精细流程设计，可与 CMMI/ASPICE 流程在同一项目中并存。
其次，该流程也应支持实现主流的汽车技术规范，如 AUTOSAR、JASPAR（、OSEK、ASAM等。其中，AUTOSAR 表示汽车开放系统架构，JASPAR 代表日本汽车软件标准化组织，OSEK代表汽车电子类开放系统和对应接口标准，ASAM 则代表自动化及测量系统标准化组织。
此外，还可在流程中穿插一些发展成熟的程序和方法用以提升开发效率和质量并降低开发成本，如仿真方法或快速原型方法等。
无论对整车开发、电子系统开发还是软件开发，都会牵扯到开发者之间的大量交互。
图2 电子系统开发概述
2.1 从硬件到软件的转变
电子系统的发展总体上遵循由硬件解决方案向软件解决方案转变的趋势。
软件解决方案在实现电子系统功能方面具有天然优势。通过软件实现对子系统的闭环、开环控制或监控，可以使子系统在诸如自适应/自学习算法、安全性保障方法及诊断等各方面具有最高的设计自由度。这是其他技术载体，尤其是那些直接受安装空间和制造工艺影响的技术方案所无法企及的。
因此，用软件来实现汽车功能为主机厂和供应商都带来了巨大的潜在商机，有助于它们在激烈的行业生态竞争中脱颖而出。事实上，在其他工业领域我们也能发现类似的趋势。
尽管软件开发者会考虑到内存的限制，但其并非主要制约因素。即使是当前具备最高数据和程序存储要求的豪华电动车型，其内存占整车 BOM成本也仅为 1%，常规的代码优化对整车成本的降低作用暂时十分有限。
2.3 产品生命周期
通常车辆的研发时长在 3 年左右，从批产到停产持续约7年，在最后一辆车下线后仍需继续 15 年左右的运营和售后服务。因此一款车的生命周期可长达25 年（图3）。
然而对于电子零部件，其技术的迭代速度远高于整车产品的生命周期。这为零部件的售后配件供应带来了极大挑战，通常需要在开发阶段就将售后运维因素纳入考量。同样，电子零部件的快速迭代也会影响到软件架构设计，车企为了让软件功能维系持久的生命力，就必须使软件和不同的硬件兼容。这一诉求推动了软件架构的标准化，也引发了业界对软硬件解耦这一话题的关注。
图3 车辆的产品生命周期
与硬件相比，软件的迭代周期更短。将软件刷新技术与控制器网络化技术相结合，即可完成现场（通过车辆 OBD 端口）或远程（OTA）程序刷新，从而避免了更换控制器的极高成本。更短的迭代周期也意味着在软件开发时也必须要考虑到车辆全生命周期相当长时间内的维护工作。
通常对软件功能的更新和缺陷修复将一直持续到车辆停产。除软件的兼容性挑战外，主机厂和供应商面临的两个最常见的现实问题是研发工具链的淘汰以及研发经验的传承。因此在软件开发之初选择工具时即需考虑到全生命周期的可维护性，同时也需做好版本变更管理和技术资料的传承。
2.4 安全要求
与机械或电信等其他行业相比，车辆功能对安全性的要求极高。这是因为在车辆出现事故时，人类（司机和乘客）位于事故发生区域内的概率为 100%，导致人员伤害的概率更高；而在一般机械工程领域，如果采取适当的阻隔措施或安全装置，即可持续保障人员远离事故发生地。
基本的安全注意事项在 ISO 26262或 IEC 61508等标准和 ECE 法规中已有明确规定。如今在乘用车领域，具备基础的功能安全保证已经成为车辆获批上路的前提条件。
电子系统和软件功能对车辆安全的影响在不断增加，从行驶情况分析（如车速显示）、情景评估（如结冰警告）、行动建议（如导航），再到行动执行（如加速或制动干预）几乎无所不包，甚至还涉及主动的驾驶干预（如主动转向）。
因此，功能安全分析以及安全概念设计已成为功能及软件开发的必须环节。但凡有较高的安全要求，就必须采取故障识别和故障响应措施。而系统冗余设计是故障识别和响应的最有效措施之一。因此我们可以认为，对功能安全的高要求加速了汽车分布联网式系统的演变。
此外，高安全性也对开发流程和工具提出了特殊的要求，包括开发流程、开发工具、标准化软件组件（例如适用于高功能安全等级的经典 AUTOSAR 操作系统）等。
三、电子系统和软件开发的核心流程
由于如上所述的车辆、电子系统和软件开发之间存在大量的相互影响，我们需要建立一套可衔接各环节的开发流程，以涵盖从用户需求分析到电子系统验收测试的所有步骤。
汽车工业中通常采用 V 模型来表述开发流程。V 模型对系统视图和部件视图做了区分，同时融入了质量措施，它兼顾了汽车电子系统开发的各类要求，因此被广泛应用。
V 模型因开发流程符合“V”字形而得名。事实上，在项目管理、系统、软件开发之间的接口都可以用 V 模型来表示。图4 展示了这一流程的全貌。
图4 电子系统和软件开发核心流程概述
V 模型的核心流程包含如下步骤：
1、分析用户需求并确定逻辑系统架构
该步骤的目标是基于用户需求制定逻辑系统架构，包括整车或子系统的功能网络、功能接口和功能间通信。在这一阶段，开发者不需对技术如何实现做出任何决策。
2、分析逻辑系统架构并确定技术系统架构
逻辑系统架构是制定具体技术系统架构规格说明的基础。这种基于统一的逻辑系统架构分析备选技术实施方案的方法在相关学科领域中十分常见。技术系统架构定义了哪些功能或子功能需要由软件实现，由此形成软件需求。
3、分析软件需求并确定软件架构
在该阶段，工程师会对上一步分解出的软件需求进行分析，并形成软件架构规格说明。其中定义了软件系统的边界和接口、所包含的软件组件、层级和运行状态。
4、确定软件组件
在该阶段，工程师将确定软件组件的规格说明。这一过程通常建立在理想化假设基础上，不会确定软件实施中的具体细节（例如是否采用整数型运算等）。
5、软件组件的设计、实施和测试
上一步中的理想化假设将在这里细化，软件详细开发中的所有细节都需在此时确定，从而指导完成软件组件的开发和测试。
6、软件组件的集成和集成测试
在所有软件组件并行完成开发和测试后，将集成为完整软件系统，并进行集成测试。
7、系统组件的集成和集成测试
通过上述测试的软件系统将嵌入控制器硬件，保障控制器正常运行。接着将控制器与其他部件集成为完整的电子系统，包括设定值发生器、传感器和执行器等，并开展系统集成测试评估系统和被控对象之间的相互作用。
8、标定
为了缩短开发时间，工程团队经常需要同时处理多个开发任务，这一现象也被称为“同步工程”。对于软件功能开发，同步工程意味着在一条线上将串行地开展对软件功能的分析、规格说明、设计、实施、集成、测试和校验，而在另一条线上，我们还要同步地对另一个软件功能完成上述串行过程。另外，不同的开发环境必须能够相互协调，即模拟环境、实验室、测试台架以及实车环境上的开发步骤必须尽可能保持一致并彼此同步，如图 7 所示。
End
分享不易，恳请点个【👍】和【在看】
联系客服
