当前整车架构多处于分布式阶段（下图），车内所有具备以太网通信能力的节点离散地挂在网关上，没有域控制器、中央处理器或者高性能处理节点等概念。如此实现SOC是没有问题的，但是以此实现SOA是有困难的。原因是功能太分散，每个节点的资源由于初期规划功能简单，而不可能预留丰富的资源供量产后新增功能使用和消耗，因此很难在此基础上实现功能重构。
SORS是基于下一代智能网联架构来实现的，主要是完成服务实现，并且体现服务复用性而进行的设计工作。使服务本身高内聚，服务之间能够低耦合，提高服务的可重用性，明确边界概念。
• Non-AUTOSAR（信息娱乐）的控制器：占用较大的硬件资源、不具有实时性、运行非车规级的操作系统上（比如Linux、Android）。
AP和CP都属于AUTOSAR家族，是亲兄弟的关系。CP推出的时间比较早，AP则是2017年才正式出现并有了初版AP规范集。正如大家所知道的，目前CP在各类车载ECU的开发实现中占有很大的使用比例，主要是应对嵌入式ECU的开发。这很符合上文所说的一个盒子一个功能的整车分布式E/E架构的需求，明确具体功能后可以精准地控制ECU本身的软硬件开发，并且CP软件架构的模块化方式配合AUTOSAR OS也可以充分满足一些特定功能对ECU本身运行时的实时性要求。
普通的OS例如Android，在某些场景下不能满足汽车的功能安全需求。此时AP登上历史舞台，作为HPC（High Performance Controller）类型ECU的重要组成部分，AP所做就是统一管理下属OS以及周边资源，使得系统运行时的一切调度、状态和资源消耗都处在一个可控的范围内，以满足车载安全性、确定性的要求。当资源丰富时，可选择的余地就会大一些，比如可以充分利用多核异构架构来处理复杂场景，使用Hypervisor等虚拟化技术，使CP、AP和非AUTOSAR系统共同存在于HPC中。
基于信号和基于服务这两种通信方式如何结合起来，是对新一代E/E架构提出的挑战。Adaptive AUTOSAR这个基于服务理念的中间件，是我们实现SOA的一种不错的选择。
