目前主流的汽车软件架构
现在你能在路上看到的所有车，几乎都是这样的架构（域架构），根据不同的功能进行划分，各个具备各自功能的ECU相连，再通过网关进行连接，如果需要链接互联网，还可以由T-Box连接移动数据（4G&5G）。
如果后期希望加什么功能，可以继续加ECU，只要能通过CAN/LIN/Ethernet连接就行。
这个时候你可能会有一个疑问，如果这么干的话，岂不是ECU越来越多？
你的想法很对，其实现在的车辆有十几个，几十个，高级车甚至上百个ECU的情况都是有的，毕竟每个功能块都有各自的任务需求，同时大部分汽车ECU的性能其实并不高，几M的Flash，几百K的Ram，其实都不算小了，考虑到成本与功能安全，ECU的性能够用就行，所以ECU的数量只能越来越多。另外一个副作用就是，由于汽车ECU的数量变多，他们相互连接所用到的线束也越来越长，这也就意味着，汽车的负重更多了。（手动狗头，更耗油了）
对于制造来说，各个OEM可以把不同的ECU交给不同的Tier1去完成，自己再去完成一个整车级别的集成，测试与验收。这样的分工模式也良好运行至今，你好我好大家好。
未来的潮流
现在的人们对于汽车拥有的功能，有了越来越多的期待，甚至座舱娱乐的体验也会在很多购买汽车的年轻人当中占据非常重要的地位，而这些体验都是需要非常之多的应用，并保持常态化更新来完成的。以往的汽车虽然已经具备互联网更新的能力，但是每次更新还需要完整重新刷一遍软件，也做不到动态部署，所以有人在思考能不能把Linux这样的操作系统引入进来，运行在更高性能的例如A53, A57这样的核心上，去代替过往好多个ecu才能具备的完整功能，并且以Linux作为基础，能够实现App的动态更新与部署呢？
而由于引入高性能计算芯片之后，能处理的功能非常多，还能够做传统域的域融合，减少ECU的数量。
再往后，就是车内可以只拥有一个中心计算单元，连接几个区域控制器，区域控制器连接执行机，整个电子电气架构比当前的要优化许多。
同时，不用于以往的软硬件结合（即使用了autosar），当OEM基于POSIX系统完成了汽车OS，就能实现真正的软硬分离，汽车厂商（+Tier1）做操作系统，App开发人员专注应用开发。
汽车SOA架构以及技术要点
SOA的核心是服务，一切皆服务。比如开发知乎这个平台，既有PC网页版，也有Android或者IOS版，想必你也知道，获取热榜列表，你肯定不会为这三个平台分别写三种Api，最终的解决方案肯定是以服务的形式，用同样一个接口为三个平台提供同样的内容，至于以什么样的UI展示，才是各自平台要考虑的事情。
S2S：SOA服务都是基于以太网的，但是为了和其他使用CAN、LIN总线的MCU通信，仍旧需要收发很多基于信号的消息，如何做到信号转服务、服务转信号，必须要考虑，实现上不是问题，重点在于如何降低对芯片资源的消耗。
核间通信：最早的HPC架构，由于芯片没有提供专门为核间通信的硬件通道或者驱动，需要自己分别在MCU端和MPU端写虚拟以太网驱动，利用共享内存来实现。不过现在新出的芯片基本都自带解决方案，会方便很多。
Hypervisor：假如做域融合，很有可能要考虑部署多个VM跑各自的OS，hypervisor的运行效率？占用多少资源？VM间通信效率？
OS: 容易吗？说起来也容易，不就是Linux部署到MPU上吗？车载娱乐系统做了多少年了，但是问题是现在要在车身控制，自动驾驶等等都要用Linux，更多的是需要考虑稳定性，安全性，如果不是做汽车软件出身，在这一块儿不一定很容易上手。复杂的不说，就处理Misra C++就够让人吐了。。。（此处有怨言哈哈哈）
AP：相对于CP，Autosar组织还建立了AP的标准，但是Linux上的解决方案可以有太多种，也有很多厂商对AP持保留态度，比如会不会搞得太复杂了，或者是不是又会陷入跟着欧洲节奏的玩法（毕竟CP就是这样），况且现在AP的规范并不是很成熟。就我个人观点而言，我认为AP的规范仍然是在趟过了很多坑后总结出来的，即使不跟随AP规范，实际上那些功能仍旧需要自己开发出来，或者很多第三方中间件供应商也是借鉴AP规范开发的中间件，因此AP仍然是很有意义的。
SOA层：其实，对于OS或者AP这类更偏向于平台化的东西，SOA层才是关键中的关键，你需要在这一层考虑各种系统级的管理功能，例如电源管理，时间管理，状态管理，日志管理等等，你还需要考虑如何封装汽车功能并提供权限访问的限制，给到上层App使用，当然你也要考虑如何更新App，如何更新自身固件等等。太多了，这也是为什么SOA喊了这么久，实际上现如今也没有谁能说自己的架构是符合构思的。（号称的有，但是，没病走两步？）不过就我交流过的客户来说，我认为国内厂商进步非常快，而且很有想法，我相信今年年底就会陆续发布各自的SOA平台。
会遇到哪些挑战
汽车OS会遇到哪些挑战？到底有多少坑？抛开特斯拉不说，目前刚刚上市的大众ID.4(欧洲为ID.3)，就是运用了这样的架构，整个项目就花了三四年，在上市之前还爆出系统升级的问题，可见这样的系统对于汽车厂商是多么大的挑战。
• 复杂度：目前大多数考虑的是S32G或者TDA4这样的异构SoC，如何将CP和Linux部署上去，如何保证核间通信，信号转服务，多VM管理，动态部署及更新等等，复杂度方面比过去单纯在MCU上部署CP要复杂太多
• 时间性：汽车科技感越来越足，如果无法在新的HPC架构实现SOA，很有可能就会被市场淘汰，如何更快地实现SOA并且投入使用，对于后续的市场占有率还是有相当大的联系的
• 功能安全：汽车安全非常重要，和在服务器上玩SOA不同，汽车如果无法保证功能安全，则是要人命的事情，用开源Linux如何保证功能安全？即使用了满足功能安全条件的其他商用Linux，你又如何保证系统级的功能安全呢？
• 网络安全：未来的汽车计算单元必然会连接互联网，如何做到主动监测或者被动处理呢？或者，即使黑客不会谋财害命故意发出非法加速命令，但是偷取你的驾驶数据或者秘密使用车载摄像头呢？
• 差异性：架构都差不多，系统做出来如何能做到生态的差异性，以保证和其他竞争对手有差异性呢？
• 长期支持：SOA是需要做到持续更新的，而一个车型的生命周期可能是十几年，一套汽车软件涉及太多组件和供应商，如何保证这样的长期支持呢？
国内现状（软件平台、基础软件）
CP不说了，份额基本就是Vector和EB瓜分了，ETAS也有一部分，然后国内也有使用本地方案，例如东软，华为之类的。
AP方面，都还在起步阶段，EB做的最早，也已经和大众合作将SOA平台应用在了ID.3(4)上，但是Vector在国内的市场做的很好，不过像Linux方面还有很多其他商用Linux供应商，竞争还是很激烈的，中间件更是，各种各样的供应商，都号称能实现SOA。而和国外OEM不同，国内OEM还无法像大众或者宝马能够做到完全自主定义自己的HPC平台，所以还需要和各个供应商配合来定义。
来源：汽车电子与软件
作者：KimChan
