[汽车电子] AUTOSAR 基础知识

目录

• 概述：AUTOSAR
• 简介
• AUTOSAR成员
• 成员发展
• AUTOSAR的组织
• AUTOSAR带来了什么好处
• AUTOSAR开发流程
• AUTOSAR的发展
• 1 早期开发状态
• 2 基于封装思想的开发状态
• 3 使用AutoSAR作为解决办法
• 1 AUTOSAR的诞生
• 2 AUTOSAR软硬件隔离
• 3 Autosar的出现因素
• AUTOSAR架构
• 总思想:标准上合作、实现上竞争
• AUTOSAR的主要计划目标
• AUTOSAR架构分层
• 基础软件层（Base Software Layer/BSW）
• 详细划分
• 功能分组
• 微控制器抽象层（Microcontroller Abstraction Layer/MAL）
• 微控制器抽象层
• 特性
• 详细划分
• ECU抽象层（ECU Abstraction Layer/EAL）
• 任务
• 特性
• 服务层（Services Layer）
• 任务
• 特性
• 复杂驱动层（Complex Drivers Layer )
• 任务
• 特性
• 运行时环境层（Runtime Environment Layer）
• 任务
• 属性
• 总结：核心概念
• AUTOSAR的文档类型
• AUTOSAR文档之间的联系
• AUTOSAR分类： Classic Platform vs. Adaptive Platform
• Classic platform（经典平台）
• Adaptive AUTOSAR（自适应平台）
• AUTOSAR架构有哪几层？分别有什么作用？
• ASW层
• Application Layaer（ASW、Appl）应用软件层包括哪些内容？
• SWC具体指啥？好几种不同命名SWC说的是啥？
• Ports的作用是啥？不同类型之间有什么区别？
• Y 推荐文献
• X 参考文献

回到顶部(Back to Top)

概述：AUTOSAR

简介

• AUTOSAR是汽车和软件行业领先公司的全球合作联盟，为智能移动开发和建立标准化的软件框架以及开放的E/E系统架构。

考虑到目前和未来市场中不同的汽车E/E架构(Electrical/Electronic Architecture)，他们制定了一套专门用于汽车的开放性的框架和行业标准，它将用作管理将来的应用程序和标准软件模块中功能的基本基础结构。

• AUTOSAR的是AUTomotive Open System ARchitecture的缩写，是一种软件架构。

因此，AUTOSAR有两种含义：

• 代表AUTOSAR联盟
• 代表AUTOSAR软件架构

AUTOSAR成员

AutoSAR官网的成员的介绍界面，目前有7类合作伙伴(最近新增了premium plus)

• 核心合作伙伴（创始成员9个无法申请），战略合作伙伴一个电装
• 高级合作伙伴 +
• 高级合作伙伴
• 开发合作伙伴
• 关联合作伙伴
• 参与者
• 订阅者

AUTOSAR会员类型

注：目前已经有超过300+AUTOSAR合作伙伴。

成员发展

• 西门子VDO原本也是核心成员，被Continental 收购

因此，西门子VDO不再是AUTOSAR的核心成员

合作伙伴发展历史

AUTOSAR的组织

• AUTOSAR标准主要是由AUTOSAR Working Group组织制作的

• AUTOSAR还有一个用户组，用户组是变化的，当前主要有三个用户组：

  • UG-CN China，UG-CN的愿景是为中国市场启用AUTOSAR。
    • 为了实现此目标，用户组在AUTOSAR演示程序项目上工作，以提供用户指南“如何从AUTOSAR开始”和演示程序的启动配置。
  • UG-NA North America，UG-NA的愿景是增强北美用户在AUTOSAR方面的技能，以充分利用AUTOSAR带来的汽车EE体系结构开发的优势。
    • 为实现这一愿景，他们提供了一个协作环境，以促进AUTOSAR在北美地区的使用。
    • 开发关键文档以帮助理解AUTOSAR标准，并提供示例和配置以解决特定的用例。
  • UG-IE Improved Exploitation，UG-IE代表了更好地利用AUTOSAR工业标准。
    • 他们的任务是分享AUTOSAR的利用和开发经验。其他任务包括为战略方向准备提案，以提高AUTOSAR的可用性以及节省更多的精力。
    • UG-IE的总结结果创建了演示文稿和技术论文，对AUTOSAR战略，技术工作组和用户产生了推动作用。

• AUTOSAR软件框架，AUTOSAR分为CP和AP和合作平台

指标	CP	AP
开发工具	C	C++
开源程度	非开源	开源
适用环境	传统ECU、MCU	自动驾驶、V2X
实时方式	硬实时	软实时
通信方式	CAN、LIN	以太网
操作系统	OSEK-OS based	POSIX
升级方式	固定，不可升级	SOA
功能安全等级	ASIL D	ASIL B以上

AUTOSAR CP和AP对比

• AUTOSAR交付内容

  从“Foundation”出发的，扩展出Classic Platform（简称CP）和Adaptive Platform（简称AP）两大平台，继而定义各种接口和测试等。

  • CP交付了规范文档
  • AP提供示例代码和文档
  • 白色部分属于还在扩展中的部分标准

• Foundation(FO)主要作用是确保不同AUTOSAR标准的兼容性，因此包含了所有常见的Artifact和协议，例如

AUTOSAR带来了什么好处

• 对于OEM车厂

• 对于供应商

• 对于工具供应商

• 对于新入市场者

AUTOSAR开发流程

AUTOSAR的方法论从参与者角色分工来看，分别支撑不同的工作。

• Software Component Description
  • 该SWC用到或被用到的Operation和Data
  • SWC对基础构架(network)和对硬件(latency times, timing, etc.)的要求
  • SWC使用的资源 (memory, CPU time, etc.)
  • 运行机制(repetition rate)
  • SWC软件接口
• ECU Resource Description
  • Sensor, actuator 传感器，执行器
  • Memory 存储器
  • Processor 处理器
  • Communications periphery 通信外部设备（如 收发器）
  • Pin assignments 引脚分配
• System Constraint Description 系统约束申明
  • Information on network topologies 网络拓扑
  • Limitations (“Constraints”) 限制
  • Protocol 协议
  • K-matrix 通信矩阵
  • Baud rate, timing 波特率，定时
  • ECU映射

前面提到了TOOL供应商，autosar的创始成员里面也有比如大陆集团的EB，博世旗下的ETAS，还有一些国产厂商也做的非常棒东软睿驰、经纬恒润，华为等。

不过, 市场占有率最高的还是Vector，工具链最全，市场占有率最高，同样价格也是非常美丽。

回到顶部(Back to Top)

AUTOSAR的发展

首先思考一个问题，为什么需要AUTOSAR？

1 早期开发状态

裸写代码法，目前这种开发方式还是存在的，例如一些简单的ECU（锂电池管理单元BMS）在使用这种方式开发，缺点比较明显，软硬件耦合严重换颗芯片就要进行重新裸写。大致总结存在如下问题：

• 电子系统的复杂性不断增长，软件代码量急速上升
• 生命周期差别: 整车的生命周期往往长于ECU的生命周期
• 嵌入式系统不支持硬件抽象
• 有限的软件模块化
• 重用性差: 当硬件（处理器型号）更换后，软件往往要推倒重写
• 五花八门的硬件平台

2 基于封装思想的开发状态

裸写多了，程序员总会想着偷懒，通过有经验的架构师做出一套优化架构，并且结合一些操作系统（OS）对代码进行封装，这样一来便可以大大降低裸写代码法的很多弊端，极大的解决了软件的日益复杂化，可重用低的问题，不过缺点仍然有：

1. 对于不同的客户，由于各家客户需求不同，重用性依然不好
2. 软件耦合也会存在，同时该方法的优劣和架构师的能力直接挂钩，存在一定的安全隐患

参考Vector以前的解决方案:

为了解决行业内嵌人式软件开发所面临的问题,提高软件的开发效率和可重用性,降低软件的开发成本,全球主流的汽车整车厂、零部件供应商以及软件、半导体和电子工业的企业于2003年联合成立了汽车开放系统架构AUTOSAR联盟旨在推动建立汽车电气/电子(E/E)架构的开放式标准,使其成为汽车嵌人式应用功能管理的基础架构,并规范汽车电子产品、软件和元器件的互通性,使用户避免因为采用私有的协议和解决方案而导致开发成本日益增长

3 使用AutoSAR作为解决办法

AUTOSAR定义了一套支持分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案。从结构化概念设计阶段设计AUTOSAR软件组件及其在ECU间的分配,到定义通信和ECU间的配置,通过工具为软件开发流程提供通用的支持采用成熟的工具实现需求的结构化并进行相应的管理,同时建立相应的配置。

1 AUTOSAR的诞生

自从德国发明汽车后，在后来的岁月里，汽车不断地改进不断地演化，车内的系统和零部件越来越复杂和繁多。时至今日，汽车行业，变成了一个蓬勃发展的行业

作为汽车发源地的欧洲大地，准确地讲，德国，于2002年8月，有一群车企大佬（宝马、博世、大陆集团、戴姆勒克莱斯勒和大众汽车公司，后来西门子威迪欧也加入了）就共同的挑战和目标进行了讨论，成立一个联盟，制定标准，准备一统江湖。

很快，在2003年，他们就将AUTOSAR kickoff了，同时也制定了AUTOSAR Classic Platform的Draft版。

在后来几年，这个联盟吸引了无数车企和相关设备商加入，规模不断地发展壮大，所制定的标准框架也日益完善。

逐渐地，后来发现Classic Platform只覆盖了低端的设备，是基于微处理器之上的，上面更高端的系统或服务（有哪些？想想手机业务的发展情况），没有覆盖到。他们的野心是大大的，目标是宏伟的，到了2017年，一个Adaptive Platform就这样诞生了

2 AUTOSAR软硬件隔离

Android是一个非常优秀的架构设计，做到了分层软件，软硬件解耦、高度可重用

1) Android解决碎片化问题退出的Project Treble

大家明白，隔离后的好处就是不管你用NXP的还是英飞凌的亦或者是TI的；不管你的硬件是怎么设计的，我们都不用修改我们的代码，只需要配置一下AutoSAR，告诉它我换硬件了，然后AutoSAR帮你匹配硬件。

当然，实际操作起来还是需要对AuoSAR配置的熟练掌握的,因为要改很多

2) AUTOSAR的作用

旧实现各家方案是各搞各的，并且自己内部也是各项目各搞个的，也就意味着APP无法内外部复用，需要消耗大量的适配成本。

3 Autosar的出现因素

• 汽车电子系统复杂度和代码量的不断提升，当前整车控制系统的代码量都已达到千万行代码的级别，其复杂度远比高端的航空航天要高，只是安全性比他们要低些。

• 软件的复习用性差，由于软件依赖于固定的硬件开发，当硬件发生变更时功能往往需要推倒重来，无疑增加重复开发的工作量和周期，这都是血琳琳的投入和成本。

• 汽车行业里有众多的整车厂（OEM）和供应商。一般来说，每一家OEM会生产不止一种车型，每一家OEM对不同子系统和零部件会选择不止一个供应商，每个供应商也会向不止一家OEM供货。减少开发成本最有效的办法就是，尽可能让产品可重复利用，用数量来分摊开发成本。OEM希望可以让同一套系统和部件用在不同的车型上；同一辆车上来自不同供应商的的各个系统和部件可以相互兼容；而供应商希望开发出来的部件和算法可以通过简单的软件调整就供给不同的OEM。

另一方面，各个供应商的开发进度往往是不同步的。人们希望可以在供应商开发的过程中就可以测试该部件能否与整车上的其它系统正确配合。因此需要一种统一的、标准化的系统描述方法。

这便是AUTOSAR的初衷，即通过提升OEM以及供应商之间软件模块的可复用性和可互换性来改进对复杂汽车电子电气架构的管理。

对于此，汽车圈，德国为主的几个大佬拉倒一起讨论了300来回，并成为最初的九大核心成员（博世、BMW、大陆、福特、戴姆勒、PSA、通用、丰田和大众）。

回到顶部(Back to Top)

AUTOSAR架构

总思想:标准上合作、实现上竞争

AUTOSAR总的思想是，Cooperate on standards – Compete on implementation，标准上合作，实现上竞争。

意思就是汽车行业的整车厂和供应商共同合作开发一套汽车电子系统的软件开发标准，这样大家就可以专注于功能的开发，而无需顾虑目标硬件平台。

• 将汽车系统的基础软件标准化为一个跨OEM的 标准栈
• 集成不同供应商生产的功能模块
• 适用于不同的车辆及不同的车型

AUTOSAR的主要计划目标

• 规范分布式开发流程中的交换格式
• 为应用程序的开发提供方法论
• 制定各种应用接口规范

AUTOSAR架构分层

• AUTOSAR的应用范围：AUTOSAR专用于汽车ECU。此类ECU具有以下属性：

  • 与硬件（传感器和执行器）强交互

  • 与CAN、LIN、FlexRay或以太网等车辆网络的连接，

  • 具有有限计算能力和内存资源的微控制器（通常为16或32位）（与企业解决方案相比）

  • 实时系统和从内部或外部闪存执行程序。

• 分层架构是实现软硬件分离的关键，使汽车系统软件开发者摆脱了之前ECU软件开发与验证时对硬件系统的依赖,在AUTOSAR分层架构中，汽车嵌入式系统软件自上而下分别为：

  • 基础软件层（Basic Software Layer， BSW)

  • 应用软件层（Application Software ,ASW）

  • 运行时环境 （Runtime Environment，RTE）

  • 微控制器（Microcontroller）

基础软件层（Base Software Layer/BSW）

• 进一步，BSW 基础软件层（Basic Software Layer，BSW）又可分为四层:
  1. 微控制器抽象层（Microcontroller Abstraction Layer，MCAL）
  2. ECU抽象层（ECU Abstraction Layer）
  3. 服务层（Services Layer）
  4. 复杂驱动 （Complex Device Drivers ，CDD）

详细划分

• 基础软件层被进一步划分为功能组（functional groups）。服务层（Services Layer） 分为系统服务、内存服务和通信服务等。

功能分组

从上图可以看到，BSW这一层的划分有点乱，既有纵向的，也有横向的，CDD可以认为是纵向的独立的一个功能组，这些跨越多个层级的都是一些比较特殊的，比如左侧的系统服务跨越多个层级，并且包含了OS(AUTOSAR OS后面描述)；然后还有一个I/O硬件抽象。

每个功能组在纵向上都是一个分类，但这并不是说每个模块/功能组只能在自己所属纵向上使用。

比如SPI底层驱动可能划分在Communication Drivers里面。但是该模块的调用路径很可能是通过RTE → I/O Hardware Abstraction → SPI。

但是像CAN这种外设，它就是通过RTE → Communication Services → Communication Hardware Abstraction → Communication Drivers/CAN这条线来使用的。

微控制器抽象层（Microcontroller Abstraction Layer/MAL）

• 微控制器抽象层是基本软件中最低的软件层。它包含内部驱动程序，这是一种可以直接访问µC和内部外设的软件模块。

微控制器抽象层

任务

让MCAL层的上层软件独立于/不依赖微控制器。

特性

• 实现：依赖于µC的实现
• 接口：标准化和µC独立

举个例子：

例如我们现在有一个芯片A，基本开发完成了，但是为了cost down，，要求换个芯片吧（叫芯片B），芯片B不但便宜，还Pin2Pin兼容。这时候做应用及上面服务层的同事一片叫好（反正没他们啥事，吃瓜群众）。

做MCAL的人就苦逼了，他们得重新针对新的芯片B重新弄一遍。

这就是上面不依赖于芯片，有MCAL搞定。

详细划分

• 微控制器驱动（Microcontroller Drivers）
  • 内部外设的驱动程序（如看门狗、通用计时器）功能
  • 具有直接访问µC的函数（如核心测试）
• 存储器驱动 （Memory Drivers）
  • 芯片上存储设备（例如内部Flash、内部EEPROM)和内存映射的外部内存设备（例如外部闪存）的驱动程序
• 加密驱动
  • 如SHE(Secure Hardware Extension)或HSM(Hardware Secure Module)等芯片上加密设备的驱动程序
• 无线通信（Wireless Communication Drivers）
  • 无线网络系统的驱动（V2X、车内无线网络系统和非车载ECU通信系统）
• 通信驱动（Communication Drivers）
  • 车载ECU(如SPI)和车辆通信(如CAN)
  • OSI网络分层结构的数据链路层的一部分
  • SPIHandlerDriver
    • SPIHandlerDriver允许并行访问一个或多个SPI总线
    • 为了抽象专用于芯片选择的SPI微控制器引脚的所有特征，这些特征应由SPIHandlerDriver直接处理。这意味着这些引脚在DIO Driver中不可用。
• I/O驱动 （I/O Drivers）
• 模拟和数字I/O的驱动程序（如ADC、PWM、DIO)

ECU抽象层（ECU Abstraction Layer/EAL）

• ECU抽象层与微控制器抽象层的驱动程序接口。它还包含外部设备的驱动程序。它提供了一个API 用于访问外围设备和设备，无论其位置（µC内部/外部）以及与µC的连接（端口引脚、接口类型）

任务

使更高的软件层独立于ECU硬件布局

特性

实现：µC独立，依赖于ECU硬件

上层接口：独立与µC和ECU硬件

ECU抽象层（ECU Abstraction Layer）包括

• 板载设备抽象 （Onboard Devices Abstraction）
• 存储器硬件抽象 （Memory Hardware Abstraction）
• 通信硬件抽象 （Communication Hardware Abstraction）
• I/O硬件抽象 （Input/Output Hardware Abstraction）。

ECU抽象层有点类似于Android平台的AOSP 标准化的HAL层，ECU抽象层是MCAL层的接口，这一层里面有很多名为Xxx_If的模块，与MCAL层相应模块对应。实际上这一层也包含驱动程序，但是是针对外部设备的驱动，而前面提到的MCAL是针对微控制器内部外设的。

举个例子:

由于MCU的资源有限，有些时候我们需要使用外扩Flash，通常这种外扩Flash是通过SPI这种端口连接的。

我们知道芯片内部自带的Flash是由MCAL里面的Fls模块负责的，那现在这个外扩Flash就自能自己实现.

服务层（Services Layer）

• 服务层（Services Layer）可分为系统服务（System Services）、存储器服务 （Memory Services）以及通信服务（Communication Services）三大部分。
• 提供包括网络通信管理、存储管理、ECU模式管理和实时操作系统 （Real Time Operating System，RTOS）等服务。除了操作系统外，服务层的软件模块都是与ECU平台无关的。

服务层是基础软件的最高层，它提供了：

• 操作系统功能
• 车辆网络通信管理服务
• 内存服务（NVRAM管理）
• 诊断服务（包括UDS通信，内存错误和故障处理）
• ECU状态管理，模式管理
• 逻辑和程序时序流监控（Wdg管理）

任务

给应用层，RTE，BSW模块提供基础服务。

特性

实现：除了OS部分功能外,不依赖于µC和ECU

接口：µC和ECU硬件独立

注意：

对I/O信号的访问是由ECU抽象层实现的。上面提到服务层应用层，RTE提供服务比较号理解。

容易忽略的是也对BSW模块提供服务，其实也很好理解，比如其他BSW模块可能不可避免的需要使用OS服务。这又涉及到前面提到过的调用关系了。

总的来说大的原则是从上至下调用。但横向互相调用也是可以的。只有下面调用/通知上面这种情况，AUTOSAR使用callback机制。

复杂驱动层（Complex Drivers Layer )

如图所示，复杂驱动层从硬件直接跨越到RTE层。CDD为集成特殊功能提供了可能性。

任务

• 那些没有在AUTOSAR里面规定的外设驱动。
• 对时序约束很高的驱动。
• 或者用于迁移集成等。

特性

实现：可能是依赖于应用程序、µC和ECU的硬件的

上层接口：可能是依赖于应用程序、µC和ECU的硬件的

注意：

CDD虽然名字叫驱动，但它其实也可以是应用程序。例如vector的实现就是将CDD归类为SWC 与ECU硬件及MCU相关。

运行时环境层（Runtime Environment Layer）

• RTE是为应用软件提供通信服务的。
• 这些AUTOSAR软件组件之间/软件组件与服务之间的通信都由RTE来实现。
• 这里说的应用软件包含AUTOSAR软件组件/传感器/执行器组件等。
• 在RTE以上的软件架构风格由下面这种“层”的概念变为“软件组件”的风格。

任务

针对ECU进行映射以达到AUTOSAR组件完全独立/不依赖于ECU。

属性

实现：ECU和特定应用（为每个ECU单独生成）

接口：完全独立于ECU

回到顶部(Back to Top)

总结：核心概念

AUTOSAR的文档类型

先看看文档的名字，是不是好像有分类的，SRS、SWS、TR……

这些各代表什么意思呢？

缩写	全称	相关解释
CP	CLASSIC PLATFORMAUTOSAR	经典平台，相对于ADAPTIVE PLATFORM而言
EXP	EXPLANATORY DOCUMENTS	更详细的介绍论题MODMODEL介绍建模的原理
RS	REQUIREMENTS SPECIFICATION	详细描述需求
SRS	SOFTWARE REQUIREMENT SPECIFICATION	所有软件模块的规格描述
SWS	SOFTWARE SPECIFICATION	软件模块设计和实现的规格
TPS	TEMPLATE SPECIFICATION	模板详细介绍
TR	TECHNICAL REPORT	技术规格详细介绍

我们可能需要关注或者是用到比较多的是上面的 SWS 文档

AUTOSAR文档之间的联系

不同的人群关注的文档可能不一样，类如：

• 关注架构设计的读者应该阅读AUTOSAR Template Specification（TPSs）.

比如说，如果读者关注逻辑系统/ECU设计，他们应该关注Software Component template，以理解怎么去定义应用软件组件（Application Software components）以及数据交互点。

• 对于一些在各个Template都用的通用概念可以在Generic Structure Template中获取，但是最好通过索引参考的方式去Generic Structure Template里找，因为一下理解整个文档挑战太大。

• 使用UML定义的AUTOSAR Meta-model没有太大必要单独去看，因为所有相关信息和图表都会在AUTOSAR Template Specification里有。

• 关注AUTOSAR基础软件的读者应该去读相关基础软件模块的软件规范-Software Specification（SWS）。

比如说，如果读者对ECU诊断功能感兴趣，他们应该去都AUTOSAR Diagnostic Event Manager和Diagnostic Configuration Manager规范。

• 对所有的基础软件模块都适用的需求可在Basic Software Modules Specification里的General Requirements里获取到。

更高颗粒度层面，TPS规范里的设计需求可以追溯到需求规范文档（RS）的描述的更详细需求。
同样地，SWS Specification里定义的基础软件需求也从software requirements specifications（SRS）里追溯的到。
RS和SRS需求可以从更高层面的规范里追溯的到，描述General AUTOSAR features和AUTOSAR Objectives的规范就是High-level的一个例子。
然后，还是建议初学者要集中关注TPS和SWS Specification，至少在一开始，TPS和SWS包含很多解释和图形以助于更好的理解AUTOSAR Features。

AUTOSAR分类： Classic Platform vs. Adaptive Platform

进入AUTOSAR官网，会发现AUTOSAR分为Classic Platform和Adaptive Platform

这两者有什么区别呢？

• 在对比这两个平台之前，还要补充E/E架构（Electrical/Electronic）即电子电气架构相关知识。

• 传统E/E架构，多条CAN总线连接整个汽车的各个ECU，随着汽车功能和传感器的增加，ECU不断增加，传输的数据大小也在增加，我们会把功能类似的ECU集成到一起，形成域。
  即使这样，传统E/E架构难以满足ECU的大量增加和联网的需求（CAN通信被网络读取所有信息，行车不安全），于是便提出了新型E/E架构。

现在最新的架构是中央+区域集成。

• 回归到AUTOSAR，软件架构便逐渐由 Classic AutoSAR 向 Classic AutoSAR+Adaptive AutoSAR 混合式方向发展。Classic AutoSAR 基础软件分为四层，分别为:服务层ASW、 ECU 抽象层BSW、微控制器抽象层MCALL和运行时环境RTE

运行时环境使应用软件从底层软件和硬件平台相互独立。
除此之外还包括复杂驱动程序，由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，这部分暂时未被标准化。

• Adaptive AutoSAR 相较于 Classic AutoSAR 具有软实时、可在线升级、操作系统可移植等优势。
• Classic AutoSAR 是基于强实时性（微秒级） 的嵌入式操作系统上开发出来的软件架构， 可满足传统汽车定制化的功能需求，但受网络的延迟、干扰影响较大，无法满足强实时性。
• 随着自动驾驶、车联网等应用的复杂化， 软实时性的软件架构系统 Adaptive AutoSAR 诞生，其主要用于域控制器/中央计算平台，相对于 Classic AutoSAR的优点：

• 为软实时系统，偶尔超时也不会造成灾难性后果；
• 更适用于多核动态操作系统的高资源环境，如 QNX；
• 软件功能可灵活在线升级。

Classic platform（经典平台）

• Classic platform（经典平台）

AUTOSAR 针对传统车辆控制嵌入式系统的解决方案，具有严格的实时性和安全性限制。
从架构来看如下图所示，软件自上而下分别为应用软件层（Application Software Layer，ASW）、运行时环境（Runtime Environment，RTE）、基础软件层（Basic Software Layer，BSW）和微控制器（硬件）（Microcontroller/Hardware）。
为保证上层与下层的无关性，在通常情况下，每一层只能使用下一层所提供的接口，并向上一层提供相应的接口。

• Adaptive AUTOSAR（自适应平台）

是在异构多核（CPU/AI/GPU）高性能SOC处理器和更高带宽的以太通信技术驱动下，提出的一种新型汽车电子系统软件架构标准。
它除了继承大量经典平台CP标准内容外，还采用了面向对象高级编程C++语言、面向服务的SOA架构和基于 POSIX 标准的操作系统以适应异构处理的分布式并行处理需求；
同时在满足功能安全和信息安全的车规要求下，支持灵活的软件配置、动态部署以及持续的软件迭代更新。

Adaptive AUTOSAR（自适应平台）

• Adaptive AUTOSAR（自适应平台）

是在异构多核（CPU/AI/GPU）高性能SOC处理器和更高带宽的以太通信技术驱动下，提出的一种新型汽车电子系统软件架构标准。
它除了继承大量经典平台CP标准内容外，还采用了面向对象高级编程C++语言、面向服务的SOA架构和基于 POSIX 标准的操作系统以适应异构处理的分布式并行处理需求;
同时在满足功能安全和信息安全的车规要求下，支持灵活的软件配置、动态部署以及持续的软件迭代更新。

AUTOSAR架构有哪几层？分别有什么作用？

• 我们这里说的架构是classic autosar，也是现在普遍使用的架构。由ASW软件应用层（Application Layer，Appl）、RTE实时运行环境层（Runtime Environment）、BSW基础软件层（Basic Software）和微控制器层（Microcontroller）构成。

其中，应用层是执行用户代码的区域；实时运行环境层提供应用层所需要的资源，将应用层和底层分离管理同时调度SWC，将SWC与BSW之间做映射。
（SWC指应用层组件）；基础软件层将对硬件的操作封装成统一AutoSAR标准的接口，供上层RTE调用。
硬件层便是基础硬件资源了。
此外，BSW是比较庞大的，还有横向与纵向描述，在BSW层再详细描述。

回到顶部(Back to Top)

ASW层

Application Layaer（ASW、Appl）应用软件层包括哪些内容？

• 应用软件层内有多个软件组件（Software Component，SWC），软件组件之间通过端口（Port）交互。

每个SWC可以运行任意个实体（Runnable Entity，RE），实体中有相关控制算法，可由RTE事件触发。

SWC具体指啥？好几种不同命名SWC说的是啥？

• 软件组件（SWC）指应用程序的核心，也是一些抽象层、复杂驱动层等实现的载体。

可把每个SWC理解为一组.c和.h文件，其能实现了特定的功能，比如控制开关灯。

• SWC大体上可分为原子组件（Atomic SWC）和部件（Composition SWC）。

其中，部件可包含若干原子软件组件或部件。

• 原子组件可根据不同用途分为以下几种类型：
  1）应用软件组件（Application SWC）；
  2）传感器/执行器软件组件（Sensor/Actuator SWC）；
  3）标定参数软件组件（Parameter SWC）；
  4）ECU抽象软件组件（ECU Abstraction SWC）；
  5）复杂设备驱动软件组件（Complex Device Driver SWC）；
  6）服务软件组件（Service SWC）；

• 应用软件组件主要用于实现应用层控制算法。

• 传感器/执行器软件组件用于处理具体传感器/执行器的信号，可以直接与ECU抽象层交互。

• 标定参数软件组件主要提供标定参数值。

• ECU抽象软件组件提供访问ECU具体I/O的能力。

该软件组件一般提供引用C/S接口的供型端口，即Server端，由其他软件组件（如传感器/执行器软件组件）的需型端口（Client端）调用。

此外，ECU抽象软件组件也可以直接和一些基础软件进行交互。

• 复杂设备驱动软件组件推广了ECU抽象软件组件，它可以定义端口与其他软件组件通信，还可以与ECU硬件直接交互。

所以，该类软件组件灵活性最强，但由于其和应用对象强相关，从而导致其可移植性较差。

• 服务软件组件主要用于基础软件层，可通过标准接口或标准AUTOSAR接口与其他类型的软件组件进行交互。

Ports的作用是啥？不同类型之间有什么区别？

• Ports是用于SWC之间做接口（interface）通信使用，或者SWC通过RTE和BSW做接口通信使用。

可分三类，R-Ports、P-Ports和PR-Ports（Provide and Require Port,PR在AUTOSAR 4.1.1标准提出），分别是：
1）需型端口：用于从其他软件组件获得所需数据或所请求的操作；
2）供型端口：用于对外提供某种数据或某类操作；
3）供需端口：兼有需型端口与供型端口的特性。

• AUTOSAR软件组件端口：

• 由于端口仅定义了方向，所以AUTOSAR中用端口接口（Port Interface）来表征端口的属性。

端口接口类型主要有如下几种：
1）发送者-接收者接口（Sender-Receiver Interface， S/R）；
2）客户端-服务器接口（Client-Server Interface，C/S）；
3）模式转换接口（Mode Switch Interface）；
4）非易失性数据接口（Non-volatile Data Interface）；
5）参数接口（Parameter Interface）；
6）触发接口（Trigger Interface）；

最常用的端口接口是1）、2）。

如下图，软件组件SWC1具有2个端口：

其中一个引用的端口接口类型为发送者-接收者（S/R）接口，
另一个引用的端口接口类型为客户端-服务器（C/S）接口。

• 对于引用发送者-接收者接口的一组端口而言，需型接口为接收者（Receiver），供型端口为发送者（Sender）。

• 对于引用客户端-服务器接口的一组端口而言，需型端口为客户端（Client），供型端口为服务器（Server）。

• AUTOSAR软件组件端口接口：

回到顶部(Back to Top)

Y 推荐文献

• AUTOSAR

• https://www.autosar.org

• 《Autosar从入门到精通-实战篇》总目录 - CSDN

• AUTOSAR入门 - autosar.ltd 【推荐】

第三方网站，非官方

回到顶部(Back to Top)

X 参考文献

• AUTOSAR 学习笔记 - 博客园 【推荐】
• 【Autosar CP通用 1.如何阅读Autosar官方文档】 - CSDN 【推荐】