|
总说汽车软件不同于互联网软件，要区别对待，也有很多说法，比如：
...... 这些都没错，但又不怎么对。 一来是，在座舱、智驾、后台软件大举进入以及电子电气架构不断演化后，汽车软件的内涵已经有了比较大的扩展。 二来呢，这些都属于技术特性，技术差异点只能说明汽车的“软件”和互联网的“软件”，而非“汽车软件”与“互联网软件”。 我们希望能从整体的角度来看汽车软件，这就引出了今天的话题——集成，它也是汽车软件独特性的核心体现。 具体来看，集成可以分为以下5个层次：
1 第一层：将软件单元集成到一起 当我们讲软件集成时，软件自身的集成是其最典型和最狭义的含义。 简单说，软件集成就是将经过验证的软件单元集成为完整软件，操作层面的表现为将不同的.c或.h文件以及一些config文件通过集成工具集成构建成软件包。 当然，由于实际项目的复杂性，集成会作为整个软件项目管理链条的一个环节。 第一，开发工程师接受ALM工作流工具上的缺陷、变更或任务等的驱动，进行本地代码的修改，之后将代码push到代码仓库，把代码备好。 第二，集成工程师也最好通过工作流工具接受集成任务，任务中要明确集成的分支策略、交付目的、时间计划、各单元信息等，而后基于这些输入要完成软件的构建。 第三，集成工程师自然也需要对自身工作质量做一个确认，所以要完成静态或动态集成测试，相关结果可能会包括编译器的警告信息、代码扫描结果、资源消耗数据、堆栈分析内容、代码评审及冒烟测试情况等。 第四，集成工程师将包括可执行文件、测试报告、配置信息、问题清单、releasenotes 等一系列必要材料打包对外发布。 2 第二层：将软件集成到硬件上 当完整的软件包就绪后，我们需要将软件集成到硬件上，准确来说是将软件刷写到MCU等芯片里。 理论上讲，集成都是通过接口来完成的，软硬件集成也就是通过软硬件接口来进行，具体表现就是物理的芯片引脚和逻辑的传输数据的软件接口，具体方法如下：
另外，如果开发过程比较理想，这些接口应该在系统架构的部分进行过定义。 3 第三层：将硬件集成到机械壳体上 到这里，我们会得到一块有软件的电路板。 进一步地，还需要电路板与机械外壳、接插件、屏幕等的集成，只不过这步集成更多有着机械装配的意味，落在现实工作里就是打一批样件了，结果就是形成我们所说的ECU或者控制模块。 由于汽车电子需要面临各类复杂严苛的驾驶环境，所以这部分仍然对软件功能的发挥有很大影响，很典型的例子是内部传感器对安装环境有模态和尺寸要求。 4 第四层：将ECU集成到子系统中 ECU至少需要和一套传感器及一套执行器一起构成一套具备特定功能的系统，我们姑且称之为子系统，比如，驱动系统、刹车系统、转向系统、被动安全系统、照明系统、辅助驾驶系统等。 对于这个层级的集成，操作上就是通过线束连接ECU、传感器、执行器这三者，并且将ECU固定在整车上。后两者通常来源于不同组织，所以特定集成的意义就更明确。 至于集成效果，是需要通过在整车环境中完成布置确认、模态分析、传感信号校验、电子对手件联调、子系统功能确认、产线确认以及EMC、振动、冲击、水淋、盐雾、高低温等一系列的考验的。 对于软件来说，尤其要考虑对手件联调，越来越多的电子功能需要多模块协同，最常见的诊断、通信问题就是该环节频繁识别出来的。 另外，很多在子系统性能也是需要在整车环境下进行软件标定匹配的。 5 第五层：将子系统集成到整车上 传统汽车的各个子系统或者域通常是分离的，相互之间大体隔绝，所以涉及到的是装配，而非集成这个概念。 但是，电子电气架构在不断走向跨子系统、跨域、域融合、中央集中，现在车辆子系统之间的边界越来越模糊，越来越多的功能特性需要聚焦在更整车、更终端才能得到验证与确认。 6 写在最后 整体来说，在汽车行业里做软件，要意识到，所有的代码其实都是最终服务于整车里的表现。 另外一点，汽车的多层次集成其实是有历史原因的，主要是来源于汽车零部件全球模块化分工及采购这种模式。 这种分工与标准化的好处不言自明，但也增加了很多集成点，集成点多了就会造成沟通协调复杂或者解决方案整合困难等弊端，而这也是我们做汽车软件要充分考量的。 往长远看，我们现在从架构层面追求的中央化正在不断地减少集成点，同样也就会弱化集成的价值与必要性。 完 |
|
|
