AUTOSAR CP （文章 2）

 Autosar概述

AUTOSAR：Automotive Open System Architecture（汽车开放系统架构）。

是由全球各大汽车整车厂(OEM)、汽车零部件供应商、汽车电子软件系统公司联合建立的一套标准协议，是对汽车技术开发一百多年来的经验总结。拟定了一个符合汽车电子软件开发的、开放的以及标准化的软件架构。该架构旨在改善汽车电子系统软件的更新与交换，同时更方便有效地管理日趋复杂的汽车电子软件系统。

■ 时间

     1. 在2003年AUTOSAR组织刚成立的时候，只有一个AUTOSAR标准，没有AP（Adaptive Platform）与CP（Classic Platform）之分。

     2. 在2005年，AUTOSAR组织推出了第一个AUTOSAR版本1.0。

     3. 在2017年，AUTOSAR组织推出了第一个AP AUTOSAR版本R1703，这是第一次外界看到AP AUTOSAR，AUTOSAR也是从这个时候起被分为AP与CP。此时，CP AUTOSAR版本命名为R4.x.x。

     4. 2019年11月份，将AP、CP以及FO（Foundation）版本号进行了统一命名：AP AUTOSAR R1911、CP AUTOSAR R1911等。

发布内容

     AP AUTOSAR方面，AUTOSAR组织除了发布相关的标准外，还为AUTOSAR会员提供了APD（Adaptive Platform Demonstration），APD中包含仅供参考的AP AUTOSAR工具、代码包等。

目标

     无论是AP AUTOSAR还是CP AUTOSAR，总体目标是一致的：

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

         ▪ 改善ECU软件质量和可靠性

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

         ▪ 可拓展的架构解决方案

倡议内容

CP AUTOSAR与AP AUTOSAR倡议内容是相同的：

         ▪ 汽车软件架构标准设计

         ▪ 详细的底层软件模块设计

         ▪ 汽车产品各域标准化数据描述

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

AUTOSAR中存在5种伙伴关系：

     1. 核心合作伙伴(9个)：宝马，博士，欧陆，戴姆勒，福特，通用，PSA集团，丰田，大众。

     2. 高级合作伙伴：华为，百度，EB，长城，本田，英特尔，英飞凌，英伟达等。

     3. 开发合作伙伴：劳德巴赫，Softing等

     4. 副合作伙伴：中国一汽，上汽，吉利汽车，江淮汽车，恒润。

     5. 参加者：各大学。

AutoSar的思想是将ECU的整个系统分层处理，将系统功能和硬件依赖性剥离开，通过AutoSar联系起来。

AutoSar提供标准的应用程序(SWC)接口，运行环境(RTE)，基础软件(BSW) ，总线通信和开发流程及数据交换格式。

AUTOSAR主要标准了三大方面：

1.软件接口

2.交换格式

3.方法论

整车软件系统可通过AUTOSAR架构对车载网络、系统内存及总线的诊断功能进行深度管理，它的出现有利于整车电子系统软件的更新与交换，并改善了系统的可靠性和稳定性。目前支持AUTOSAR标准的工具和软件供应商都已经推出了相应的产品，提供需求管理，系统描述，软件构件算法模型验证，软件构建算法建模，软件构件代码生成，RTE生成，ECU配置以及基础软件和操作系统等服务，帮助OEM实现无缝的系统软件架构开发流程。

AUTOSAR计划目标主要有三个：

1. 建立分层的体系架构。

2. 为应用程序的开发提供方法论。

3. 制定各种应用接口规范。

AUTOSAR提供了以下标准。

资料来源，官方网站：https://www.autosar.org/

标准	缩写	说明
Adaptive Platform	AP	自适应平台： AUTOSAR的高性能计算ecu解决方案，用于为高度自动化和自动驾驶等用例构建安全相关的系统
Classic Platform	CP	经典平台： AUTOSAR针对具有硬实时和安全约束的嵌入式系统的解决方案
Foundation	FO	基础平台： 加强AUTOSAR平台之间的互操作性。Foundation包含AUTOSAR平台之间可以互相共享的通用需求和技术规范(例如协议)。
ACCEPTANCE TESTS	AT	经典平台的验收测试： 总线级和应用程序级的系统测试
APPLICATION INTERFACE	AI	应用界面： AutoSar应用程序标准化接口，

名词解释：

名词	说明
EXP	即Explaination"解释"，详细介绍论题
MMOD	即Meta Model"元模型",介绍 AUTOSAR元模型
MOD	即Model"建模",介绍建模的原理
RS	即Requirement Specification"需求规范", 详细介绍需求
SRS	即Softeware Requirement Specification"软件需求规范", 描述所有软件模块的规范
SWS	即Softeware Specification"软件规范", 介绍软件模块设计和实现的规范
TPS	即Template Specification"模板规范", 详细介绍元模型
TR	即Technical Specification"技术规范",详细介绍技术规范
OEM	整车厂，奔驰、宝马等（做整车的装配工作）
TIER1	一级供应商，大陆、博世等（给OEM供应ECU等）
TIER2	二级供应商，英飞凌、NXP等（为TIER1供应零件，比如ECU上的芯片、电路板等）
VFB	虚拟功能总线
RTA-VRTE	车辆运行时环境

Autosar CP – 概要

在过去的30-40年中，在汽车环境中使用软件，无论是以功能的数量还是复杂性来衡量，已经从简单的发动机管理系统发展到在车辆平台中普及。

AUTOSAR Classic 平台是为了应对汽车软件日益复杂的需求而开发的。该平台的特点是支持硬实时性、高安全性、低资源拥有属性 ECUs，因此非常适合于传统的汽车用例。Classic 平台仍然是功能性汽车 ECUs 的明显选择，这些 ECUs 直接连接到传感器和执行器，依赖于低资源使用率和经典的实时性能。

经典平台AutoSar CP分为4层，包括：

1.应用层(Application Layer)，封装了部分或者全部汽车电子功能。

2.实时运行环境层(RTE)，中间件部分给应用层提供了通信手段，APP各模块通信/ APP和BSW通信。

3.基础软件层(Basic Software)，为各ECU服务而抽象出来的基础服务。

4.微控制器层(底层驱动)，基础服务是可以抽象出来的。

                             

正在上传…重新上传取消 

AutoSar CP 4层详细划分如下：

正在上传…重新上传取消

应用层中的功能由各软件组件SWC（software component）实现，组件中封装了部分或者全部汽车电子功能，包括对其具体功能的实现以及对应描述，如控制大灯，空调等部件的运作，但与汽车硬件系统没有连接。

应用层功能包括：软件组件SWC和端口PORT两部分。

■ 软件组件SWC分类：

     1. 原子，Atomic component（最小逻辑单元）。SWC由Atomic component组成。

         ▪ Application：算法实现类型，能在各ECU上自由映射；

         ▪ Sensor/actuator：

            ①为Application提供I/O端口类型 。

            ②用于与ECU绑定，但不可像Application那样能在各ECU上自由映射。

     2. 集合，Composition，数个SWC的逻辑集合。

SWC组成一

     ■ 端口Ports：

          1. 端口Ports是用来和其他SWC通信

          2. 通信内容：Data elements(S/R)与operations(C/S)。

              ▪ Data elements用Sender/Receiver通信方式

              ▪ operations用Client/Server通信方式

          3. 发送-接收端口，向底层发送或接收底层数据。

              ▪ 传送数据，一个port可以包含多种Data elements

              ▪ 如果一个Data elements要通过总线传输必须和一个signal对应起来

      

          4. 客户端-服务器端口，和其他SWC通信。

              ▪ 提供operation服务

              ▪ 通过或异步

              ▪ 一个C/S端口可以包含多个operation

              ▪ Operations可以被单独调用

SWC组成二

■ 可运行实体(就是SWC中的函数)，Runnable entities：

          1. 包含实际实现的函数（具体的逻辑算法和操作）

          2. Runables由RTE周期性，或事件触发调用。

2.3 Autosar CP – 实时运行环境层 RTE

应用软件层，封装了部分或全部汽车电子的功能和行为，但对外界仅仅开放了定义好的接口，称之为PortPrototypes，而所有ECU内部组件之间的通信及获取其他ECU资源的动作就都必须要通过接口来访问RTE来完成了。

中间件部分为应用层提供了通信接口，应用层通信关系如下：

1.软件组件能和同一个ECU上其他软件组件通信。

2.软件组件能和不同ECU上其他软件组件通信。

3.软件组件能和有端口并位于同一个ECU上的基础软件（BSW）进行通信。

●

而RTE就是这些交互使用的接口的集散地，它汇总了所有需要和软件体外部交互的接口。从某种意义上来看，设计符合AUTOSAR的系统其实就是设计RTE。

■ 虚拟功能总线VFB及运行环境RTE

     1. VFB：虚拟功能总线，是底层基础软件与网络拓扑结构的抽象，是AUTOSAR提供的所有通信机制的集合，在信息数据交互的过程中，应用程序被建模为组合组件。当系统进行配置时，软件组件就会被映射到指定ECU上，而同时组件间的 虚拟连接 也被 映射到 了CAN, FlexRay，MOST等总线上。最后软件组件利用 预先定义好的端口 ，通过VFB来实现通信。

      2. RTE：实时运行环境，即是具体单个ECU上对 VFB接口的实现 ，可以理解成是面向对象的编程语言中 对象的创建 。各软件组件之间不允许直接进行通信，由RTE封装好了下层如 OESK、COM等通信层BSW 后，为上层提供数据通信所需的RTE  API ，再使用端口或者Sender-Receiver通信和Client-Server通信的方式进行交互。

SW-C之间的通信是调用RTE API函数而非直接实现的，都在RTE的管理和控制之下。每个API遵循统一的命名规则且只和软件组件自身的描述有关。具体通信实现取决于系统设计和配置，都由工具供应商提供的RTE Generator自动生成的。

在设计开发阶段中，软件组件通信层面引入了一个新的概念，虚拟功能总线VFB（Virtual Functional Bus）。它是对AUTOSAR所有通信机制的抽象，利用VFB，开发工程师将软件组件的通信细节抽象，只需要通过AUTOSAR所定义的接口进行描述，即能够实现软件组件与其他组件以及硬件之间的通信，甚至ECU内部或者是与其他ECU之间的数据传输。