车载软件架构—CP和AP相同与不同起源 AUTOSAR(AUTmotive Open System ARchitecture) 是汽车电子E/E系统发展的一个重要的节点。该标准是由包括BMW、DAIMLER、GM、TOYOTA、福特等主机厂和包括博世、大陆等供应商牵头成立的一个标准发展组织定义的一个开放参考的ECU软件架构。最初目的是为了避免反复重复开发功能相同相近的软件模块。使用独立于系统的标准软件平台，可缩短产品上市时间，减少开发工作，并可从同一组组件中开发出更多产品，提高产品质量，实现软件和硬件的解耦。相同之处 无论是AP AUTOSAR还是CP AUTOSAR，提出该标准最初总体目标是一致的：1、更好的管理数量增多，功能复杂度增加的汽车ECU;
CP AUTOSAR与AP AUTOSAR标准提倡的内容是相同的：
相同之处更多在于从宏观出发，落实到具体实现策略，则体现出不同之处。考量到两个软件架构主要的应用场景，对于芯片性能要求（实时性和算力）：CP AUTOSAR一般运行在8bit、16bit、32bit的微控制器（MCU）中，运行CP AUTOSAR 的芯片算力一般低于1000 DMIPs
AP AUTOSAR可以运行在64bit的高性能处理器（MPU）、CPU等中，，AP AUTOSAR也可以运行在虚拟硬件上，AP AUTOSAR可以运行在算力高于20000 DMIPs的芯片上。
CP AUTOSAR软件架构是分层的，有较为明显的上下层关系，详细可参考如下图所示：如上图，体现的分层架构实现不同的功能（从下往上）：3、RTE层：体现了application的所有接口，软件模块间通过RTE交互，并通过RTE访问BSW；对比CP AUTOSAR，AP AUTOSAR一般是指ARA（AUTOSAR Runtime for Adaptive Applications），主要由两部分组成：
具体示意如下图所示：注：所有的模块都称为功能集群（Functional Clusters, FC），蓝色的FC属于Foundation的部分，橘色的部分属于Service的部分。无论是Foundation部分的FC，还是Service部分的FC，都不是上下层关系。CP AUTOSAR架构设计原则为：- CP AUTOSAR将与硬件相关的以及通用系统功能定义为BSW模块
- BSW可配置，并且可以被多个产品线的ECU重复使用
AP AUTOSAR架构设计原则为：
遵循面向服务的架构SOA设计范式（该理念非新创概念，原互联网中已使用成熟的应用理念，只是将应用场景变化到车载中）充分利用其他领域软件成熟技术，重用软件市场成熟组件，缩短开发周期充分利用各种开源软件（对比CP的不开源）
开发流程来看，CP与AP都主要都包括以下三个阶段：设计阶段：设计ARXML;
代码生成：基于ARXML生成代码;
集成：集成Application，编译调试等
对于开发阶段，同样存在不同之处，详细如下：：AP AUTOSAR设计阶段，需要进行Service与Manifest的设计；CP AUTOSAR设计阶段，需要进行ECU配置设计，而AP没有ECU配置这个设计项。CP 与AP开发流程如下图所示：蓝色虚线框表示CP AUTOSAR的开发流程，绿色表示AP AUTOSAR的开发流程。CP AUTOSAR是基于信号的通信，主要包括CAN、Lin、FlexRay等。AP AUTOSAR是面向服务的通信，支持基于以太网的SOME/IP、IPC、RPC等。CP AUTOSAR虽然可以支持SOME/IP，但是CP AUTOSAR中SOME/IP只不过是把Sender-Receiver的CAN通信转换成了Client-Server的以太网通信，整个通信链路仍是静态配置的，并不是真正的面向服务的通信。PS: 传统嵌入式ECUs主要实现替代或增强电气系统的功能。这些ECUs中的软件主要根据输入的电气信号和来自车载网络上其他ECUs的输出信息来控制其输出的电气信号，它们在整个车辆寿命中往往不会发生明显变化。而下一代的车辆运用，比如自动驾驶，将需求更复杂、更高计算资源的软件，并满足更严苛的integrity和security要求。这些软件需要实现比如环境感知、行为计划等功能，并需要将车辆融入到外部后台系统和基建系统中。随着外部系统的不断发展或改进的功能，要求车辆中的软件能够不断被更新。Classic AUTOSAR(CP)满足了传统嵌入式ECU的需求，而上述ECU的需求无法满足。因此AUTOSAR指定了另外一个软件平台，即Adaptive AUTOSAR(AP)。AP更专注提供高性能计算和通讯机制，并提供灵活的软件配置，例如支持无线更新软件(FOTA)。Adaptive AUTOSAR优势：- ECU更加智能：基于SOA通信使得AP中ECU可以动态的同其他ECU提供或获取服务，动态同其他ECU进行连接；
- 更强大计算能力：基于SOA架构使得AP能够更好支持多核、多ECU、多SOCs并行处理，提供更强大的计算能力；
- 更加安全：基于SOA架构使得AP中各个服务模块独立，可独立加载，IAM管理访问权限；
- 敏捷开发：Adaptive AUTOSAR服务不局限于部署在ECU本地可分布于车载网络中，使得系统模块可灵活部署，并可后期灵活独立更新（FOTA）；
- 高通信带宽：基于Ethernet等高通信带宽的总线通信；
- 更易物联：基于以太网的SOA通信，更易实现无线、远程、云连接，部署Car-2-X应用；
- 系统兼容：通过SOME\IP等协议AP可以同CP/Non-AUTOSAR等ECU。
CP AUTOSAR一般应用在对实时性要求高、对功能安全要求高、对算力要求较低的场景中，如引擎控制、制动系统等。AP AUTOSAR一般应用在对实时性有一定要求、对功能安全有一定要求，对算力要求较高的场景中，如：最近七八年，AUTOSAR软件架构这个topic一直很火，出现了很多基于该软件架构的解决方案供应商。靠着早入局，质量稳定等优势在业界大吃特吃。伴随着对协议解读越发通透，国内也出现了该方面的解决方案服务商，随着使用过程中不断优化（敏捷开发，快速迭代），早日实现关键技术不被卡脖子。话又说回来，特斯拉在电动车一骑绝尘，但是也没有采用AUTOSAR软件架构，基于自己团队软件能力，开发出属于自己的车载软件架构。车载软件嘛，只有基于自身软件架构实现其功能，又可以保证软件运行稳健性，就是王道。万里长征方起步，我辈需加倍努力。愿你我相信时间的力量做一个长期主义者！-----------------------------------
|
