首先，我们还是将汽车软件放在整车系统下来看。因此，我们会分离出3个层级的集成：
软件组件集成。
软件向硬件集成。
ECU向整车集成。
1、软件集成与分支划分
简单来说，软件集成就是创建一个边界明确、质量可靠的完整软件包。再扩充一些的话，就是基于源代码管理工具和分支管理策略，针对不同的单元（如.c或.h文件）逐级进行集成，并将相关的辅助文档、集成测试、配置文件等配置项进行配置管理。
1.1 “分支”的概念
由于汽车软件的平台化需求很高，所以，我们一般会进行“开发分支”和“交付分支”的区分。
开发分支侧重于维护新特性的上线和通用性技术方案的导入。
交付分支则关心的是基于特定项目要求（如标定参数、项目配置参数、bug修复等）的释放。
二者的区分也可以让“开发的技术完善性”和“交付的时间及时性”不至于直接冲突和互相干扰。
一般而言，软件集成的主要任务是识别、确认不同分支之间的公共组件，定义哪些组件应该从一条分支摘取到另一条分支上、哪些组件的变更需要单独释放以及哪个软件基线最终能够被用于哪个配置的交付上。
1.2 具体的集成
集成的策略取决于项目或平台释放的目的，而这又来源于项目的整体考量，所以，集成任务是需要项目经理类角色驱动的。简要集成流程如图1所示。
图1 软件集成简要流程
1.2.1 集成输入
尽管邮件也是一种输入，但对于繁杂的集成任务来说，通常最好使用ALM工作流类的工具来支撑，或是bug，或是变更，或是新特性需求，都可以通过相关工作项来驱动集成，比如，输入需求基线、变更范围、版本规则、工件、上一版本软件基线、交付日期等。
实际上，良好的集成更多来源于管理。
1.2.2 编译、测试、打包
集成工程师在任务驱动下，去完成相应的源代码编译和相关错误清除，并完成必要的接口、资源消耗、冒烟等静动态集成测试。最后，根据预定规则，完成可执行文件、配置信息、测试报告、架构模型、设计文档、遗留问题、释放清单等的打包释放。此时，一个常规的集成任务就完成了。
1.2.3 软件配置管理
不管是集成组件选择，还是文件打包，其实都可以归属为配置管理这个大的概念，第3章我们从项目层面解释了配置管理，这里进入软件包里看，主要讲两部分。
(1) 软件版本号
软件的名字，也就是软件版本号，这是我们日常交流的主体对象，最基本的逻辑是一个版本号唯一对应一版代码。
理论上，我们用V1、V2、V3也可以去描述软件，但为了增加软件的辨识度、可见性和交流的便利，我们会为软件版本号增加更多的信息，比如，项目名、车型名、客户名、硬件类别、芯片类别、架构类别、集成序列号、标定版本号、软件阶段（签名与否、适用工厂与否、ABCD级别等）等。
(2) 细化的分支概念
我们再细化讨论下分支的概念。注意，这是一个逻辑概念，并不真实存在。通俗理解，分支就是把组件的变更放在这个软件包里，而不是另一个，也就是不同的组件版本组合。
另外，前面我们说过可以把分支大体分为“开发分支”和“交付分支”。进一步地，二者都可以继续划分为更细化的分支概念，如图2所示。
图2 软件分支类型
1) 开发分支
“开发分支”可以细分为平台开发分支、特性开发分支与特定项目开发分支。
平台开发分支
平台开发分支是我们的平台化软件，是平台开发人员维护的、最具普适性的基础软件，是所有其他分支的源头，所有的变更、修改、提交应该严格审慎。如图3所示。
图3 平台开发分支示意图
特性开发分支
特性开发分支一般是，经过普遍分析后，认为有必要导入到平台的特性开发或复杂bug修复，而且，这样的变更需要一定的周期和工作量。
为了避免影响到平台软件的日常维护，这时就有必要单独拉出来分支进行开发。在开发过程中，需要定期地将平台开发分支的变更进行同步，并在新特性释放后，合入平台开发分支，以保证平台开发分支的最新状态和完整性。如图4所示。
图4 特性开发分支示意图
特定项目开发分支
对于特定项目开发分支来说，有些功能或特性的变更需求来源于特定项目，但需要动到平台开发分支，而由于其特殊性，又不需要永久合入平台开发分支的平台软件里，再加上二者团队的差异性，这时，就可以单独拉出来一个分支去完成这部分变更，但最终不会合入平台软件，而是合入到交付分支里。如图5所示。
图5 特定项目开发分支示意图
2) 交付分支
那么，“交付分支”也可以继续分为项目主干分支、项目释放分支等。
接着看交付分支，交付分支的意义整体在于，既能基于平台化软件加速开发，又能保持一定的项目释放独特性与灵活性。
项目主干分支
对于项目主干分支来说，道理与平台开发分支类似，对于特定的车型类别或客户群项目，往往有更相近的需求，可以维护一条项目交付层级的“平台”软件。
这条分支由项目团队精心维护，同时做好与平台的同步更新，保证其是一条构建和测试成功的“绿色“分支。如图6所示。
图6 项目主干分支示意图
项目释放分支
而对于更多的项目变体，即项目释放分支，就能够以这条“绿色”的项目主干分支为交付基础，而高效地从中摘取软件基线，并完成自身的配置，比如，传感器、MCU、零件号等配置参数。如图7所示。
图7 项目释放分支示意图
值得说明的是，以上仅给出了一种分支拆分的思路，基本逻辑是平台化和定制化的权衡。实际上，有些产品与项目甚至不需要分支，只在一条分支上开发下去，具体项目需根据软件的成熟度和复杂性以及变体的多寡等来综合考虑合适的分支策略。
2、软件向硬件集成
在完整软件交付出来之后，我们要做的就是将软件刷写到ECU硬件中（具体刷写方式可能通过OBD口或USB或直接连接芯片针脚，或者通过远程OTA），这其实就是我们所要讲的系统（软硬件）集成。
理论上讲，集成都是通过接口来完成的，系统集成也就是通过软硬件接口来进行，具体表现就是物理的芯片引脚和逻辑的传输数据的软件接口。如果开发流完整的话，这些接口应该在系统架构的部分进行过定义。
如果把系统集成再细分一些，我们再往上走，会有电路板与机械外壳、接插件、屏幕等的集成，只不过这步集成更多有着机械装配的意味，落在现实工作里就是打一批样件了。
当然，我们都知道一套完整的电控系统一般会包含传感器、ECU和执行器，处于中间的ECU是我们前述两步集成的结果。但传感器和执行器往往由外部其他组织提供，如果从系统的视角考虑，我们通过线束支撑的接口来完成这一级别的集成也是必要的。至少，内部开发中经常需要这样的环境来验证ECU的功能。
3、ECU向整车集成
整车集成基本是属于OEM的工作范围，也是它们的核心竞争力所在。
这一步的系统是从整车来看的，比如，驱动系统、刹车系统、转向系统、被动安全系统、照明系统、辅助驾驶系统等。
对于某一个电子控制器来说，在所有内部集成和验证完成后，必不可缺的一步是，在整车环境中完成布置确认、模态分析、传感信号校验、电子对手件联调、产线确认以及EMC、振动、冲击、水淋、盐雾、高低温等一系列的考验。
对于软件来说，尤其要考虑对手件联调，越来越多的电子功能需要多模块协同，最常见的诊断、通信问题就是该环节频繁识别出来的。另外，很多在整车层面的属性性能也是需要在整车环境下进行软件标定匹配的。在汽车行业里做软件，要意识到，所有的代码其实都是最终服务于整车里的表现。
但是，我们也要知道，我们并不期望在整车集成环节解决软件问题。毕竟，一台试验车动辄几十上百万，有些试验甚至是整车破坏性的，整车试验的成本通常都会比较高。当软件问题从开发团队一路逃逸到这个环节时，往往会带来比较大的成本。
本文摘编自《智能汽车电子与软件：开发方法、系统集成、流程体系与项目管理》，机械工业出版社出版，经出版方和作者授权发布，转载请标明文章来源。
