车载软件架构—CP和AP相同与不同

文章目录

• 前言
• 一、两者不同之处
• 二、两者架构设计原则
• 总结

---

前言

AUTOSAR(AUTmotive Open System ARchitecture) 是汽车电子E/E系统发展的一个重要的节点。该标准是由包括BMW、DAIMLER、GM、TOYOTA、福特等主机厂和包括博世、大陆等供应商牵头成立的一个标准发展组织定义的一个开放参考的ECU软件架构。

最初目的是为了避免反复重复开发功能相同相近的软件模块。使用独立于系统的标准软件平台，可缩短产品上市时间，减少开发工作，并可从同一组组件中开发出更多产品，提高产品质量，实现软件和硬件的解耦

无论是AP AUTOSAR还是CP AUTOSAR，提出该标准最初总体目标是一致的：

1、更好的管理数量增多，功能复杂度增加的汽车ECU; 

2、改善ECU软件质量和可靠性；

3、提升产品升级灵活性，缩短产品推向市场的时间；

4、可拓展的架构解决方案。

CP AUTOSAR与AP AUTOSAR标准提倡的内容是相同的：

1、汽车软件架构标准设计；

2、详细的底层软件模块设计；

3、汽车产品各域标准化数据描述；

4、适用于此架构的过程定义和软件工具链。

相同之处更多在于从宏观出发，落实到具体实现策略，则体现出不同之处。

---

一、两者不同之处

考量到两个软件架构主要的应用场景，对于芯片性能要求（实时性和算力）：

CP AUTOSAR一般运行在8bit、16bit、32bit的微控制器（MCU）中，运行CP AUTOSAR 的芯片算力一般低于1000 DMIPs

AP AUTOSAR可以运行在64bit的高性能处理器（MPU）、CPU等中，，AP AUTOSAR也可以运行在虚拟硬件上，AP AUTOSAR可以运行在算力高于20000 DMIPs的芯片上。

CP AUTOSAR软件架构是分层的，有较为明显的上下层关系，详细可参考如下图所示：

如上图，体现的分层架构实现不同的功能（从下往上）：

1、微控制器层（HW）；

2、基础软件层（BSW）：

• 微控制器抽象层

• ECU抽象层

• 服务层

• 复杂驱动

3、RTE层：体现了application的所有接口，软件模块间通过RTE交互，并通过RTE访问BSW；

4、Application层：不依赖于硬件。

 

对比CP AUTOSAR，AP AUTOSAR一般是指ARA（AUTOSAR Runtime for Adaptive Applications），主要由两部分组成：

1. Foundation；

2. Service。

具体示意如下图所示：

注：

所有的模块都称为功能集群（Functional Clusters, FC），蓝色的FC属于Foundation的部分，橘色的部分属于Service的部分。无论是Foundation部分的FC，还是Service部分的FC，都不是上下层关系。

 

二、两者架构设计原则

CP AUTOSAR架构设计原则为：

• CP AUTOSAR将与硬件相关的以及通用系统功能定义为BSW模块

• 应用功能定义为独立的软件组件SWC

• RTE分离SWC和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。

• P AUTOSAR一般应用在对实时性要求高、对功能安全要求高、对算力要求较低的场景中，如引擎控制、制动系统等。

  AP AUTOSAR一般应用在对实时性有一定要求、对功能安全有一定要求，对算力要求较高的场景中，如：

  1、传感器融合处理、运行时动态更新

  2、自动驾驶中：

• 与交通基础设施的通信

• 与云服务器进行通信

• 车身域

• 娱乐域

• 动力域

最近七八年，AUTOSAR软件架构这个topic一直很火，出现了很多基于该软件架构的解决方案供应商。靠着早入局，质量稳定等优势在业界大吃特吃。伴随着对协议解读越发通透，国内也出现了该方面的解决方案服务商，随着使用过程中不断优化（敏捷开发，快速迭代），早日实现关键技术不被卡脖子。话又说回来，特斯拉在电动车一骑绝尘，但是也没有采用AUTOSAR软件架构，基于自己团队软件能力，开发出属于自己的车载软件架构。车载软件嘛，只有基于自身软件架构实现其功能，又可以保证软件运行稳健性，就是王道。

 

---

总结

万里长征方起步，我辈需加倍努力。