软件定义了当前和未来车辆的最先进功能，从智能座舱、信息娱乐到先进的驾驶辅助系统。随着越来越多的消费者期望这些功能时刻保持最新——就像他们智能手机上的应用程序一样，主机厂及其合作伙伴需要自由地通过OTA来满足这些期望，这些更新贯穿车辆的整个生命周期。
将软件与硬件分离解耦提供了这种自由。另外它还使 OEM 能够满足全球各地区和国家对使用售后软件更新的要求，以使车辆符合自动驾驶和其他功能的最新法规。
过去供应商开发的软件都是在特定的、专门的电子控制单元(ECU)上运行的。一辆汽车包含超过80个这样的ECU，由一个巨大的蜘蛛网般的线束连接电力和汽车总线系统，线束笨重(通常连起来有几公里长)，还通常需要手工组装。在生产过程中，线束必须手动放入车身，并通过工人手动连接到所有ECU。汽车售出后，几乎不可能再做任何改变。
ECU上运行的软件也是一样，当主机厂完成各个部件的验证后，这些部件就被认为是最终产品，除了常规维修外，不会再被碰触。
开发过程按顺序进行。首先是产品定义和需求阶段，该阶段至少在生产开始前五年开始——随后是硬件设计、软件设计、样件测试、和报价投标。中标后开始按照主机厂的企标进行软件修改，然后进行台架测试、耐久测试、DV测试、道路测试，最后是车辆公告和量产。每个开发阶段都必须在下一个开发阶段开始之前完成，也就是我们常用的瀑布开发模式。
另外如果硬件发生变化，开发人员必须为每个新硬件平台构建全新的软件，因为他们无法在这些平台之间有效地重用代码。
在解耦的体系结构中，硬件和软件可以按照各自独立的开发时间线和更新周期自由发展。此外，不同的软件模块使用不同的技术相互解耦，形成了我们所说的软件模块之间互不干扰的自由。这种分离将软件更改的影响降到最低，并且在可能的情况下，在进行更改时无需对整个车辆进行重新验证。通过解耦，软件模块可以在车辆的整个生命周期内更容易地接受更新，并且可以在不同的硬件平台上运行。
这种方法也意味着，开发人员可以更容易地整合或升级软件，也意味着方便将ECU的功能整合到大型的计算平台或者是域控制器上去。
在大型的计算平台或域控制器上，可以将传统 IT 服务器和云世界的好处引入车辆。在这些平台上，软件应用程序共享资源，有效地支持相同或更高的处理能力，实现软件和硬件不受干扰，同时允许制造商减少ECU的数量、外壳和布线，以降低成本、重量和复杂性。
随着软件与硬件的分离，主机厂可以更好地控制定义车辆的软件。例如主机厂和他们的合作伙伴今天指定的软件功能可以在几个月后用于生产中的车辆或使用不同硬件的领域，而不是提前3到5年指定要求，这相当于在消费电子领域处理方式。采用这种方式后更接近今天的智能手机应用程序的更新速度，功能更接近消费者的期望。当然，主机厂会在某些领域保持较低的更新频率，比如安全功能。还有一些领域需要非常快速的更新，比如安全补丁或自动驾驶中的一个小问题的修复，已获是座舱的新功能。
同样重要的是，解耦允许主机厂采用现代的DevOps方法和工具进行软件开发。持续集成和持续部署(CI/CD)，以及持续测试，是加速开发的关键，同时提高软件质量，并允许更多的团队贡献一个透明的过程。CI/CD使小型的、自主的团队能够通过频繁的迭代开发软件，尽早且经常地集成和测试代码，从而为快速添加特性和改进代码创造一个反馈循环。
此外，通过标准化工具链，oem可以使所有内部团队以及合作伙伴的开发实践保持一致。独立的团队可以创建、拥有和更新应用程序，标准api保持了这些应用程序的独立性，同时允许它们与其他团队的软件自动集成。
CI/CD之后，建立一个统一的、基于云的工具链，世界各地的开发人员可以在其中自动集成他们的最新代码并将其部署到硬件在环测试平台中或任何站点的测试汽车环境。原始设备制造商、供应商和其他第三方可以通过单一管理视图协作进入所有工具链，以实现治理和安全性。
另外拥有一个使用标准 API 的平台，允许公司在单一中央源中管理系统中所有内容的车辆功能。该平台包含车辆中所有模块的接口模型，以及到不同车辆硬件架构的映射。这意味着开发人员可以创建可以针对不同硬件配置进行编译的软件功能，而无需更改功能本身。
解耦还利用了OTA功能，允许开发人员将最强大的软件版本推送到该领域的所有车辆，以便消费者始终拥有车辆硬件可以支持的最佳功能。
开发人员甚至可以在现场使用车辆来帮助他们持续改进软件。通过“影子测试”，测试代码可以在每辆车上与生产代码并行运行，系统可以报告测试代码的执行情况，并将数据上传到云端。分析师可以将数据与来自其他车辆的数据相结合，使用结果通知测试代码的更改，并在云中预先验证更改。如果软件需要更广泛的验证——也许是因为它对安全至关重要——开发人员将在测试车队的车辆中运行代码。无论哪种方式，当验证完成时，更新将作为生产代码推送回车辆。
解耦是一个根本性的变化，但它可以从较小的计划开始——例如，组建小型自治团队来开发可以在同一域控制器上独立运行的软件。通过采用自动化工具，开发人员可以通过标准 API 逐步集成这些应用程序。
这种变化要求我们转变思维方式，在目前独立的硬件、软件和网络团队之间建立新的组织接口，来实现真正的软件即产品和软件即服务战略。
谈谈Bootloader自更新
谈谈对两家AUTOSAR工具看法
奥迪首款800V车型技术总览
CAN设计与应用指南
汽车软件需求是如何变成用户功能？
电子电气架构设计需要考虑哪些方面？
汽车E/E架构的网络安全分析
电子电气架构设计需要考虑哪些方面？
分享不易，恳请点个【👍】和【在看】
