AUTOSAR

一、概论

1、是什么？

  • AUTOSAR全称为AUTomotive Open System ARchitecture（汽车开放系统架构）。

  • AUTOSAR是由汽车主机厂、零部件供应商、半导体厂商、软件服务商、工具提供商以及其他相关的厂商联合成立的一个组织。

1.1 来历

AUTOSAR官网将AUTOSAR的发展分成了5大阶段：

  1. AUTOSAR成立：Initialization（2002-2003）
  2. 第一阶段：Phase 1（2003-2006）
  3. 第二阶段：Phase 2（2007-2009）
  4. 第三阶段：Phase 3(2010-2012)
  5. 2013年开始不断更新完善：AUTOSAR continuous further development(since 2013)
  6. 2017年新的AUTOSAR自适应平台成立：AUTOSAR Adaptive Platform（since 2017）。

AUTOSAR的组织架构如下图所示。
image

2、做什么？

  • AUTOSAR的建立初衷是为了解决当前汽车电子电气架构复杂多样性，统一汽车电子电气架构标准。

  • AUTOSAR官网解释了其建立初衷和愿景：Considering the different automotive E/E architectures in the current and future markets, the partnership established a de-facto open industry standard for an automotive software architecture. It will serve as a basic infrastructure for the management of functions within both future applications and standard software modules.

3、AUTOSAR软件架构

  • AUTOSAR经常讨论的主要是指Classic platform（经典平台）。

  • AUTOSAR规范主要包含了软件架构、方法论、应用接口、一致性测试四部分。其中，软件架构是实现软硬件分离的关键，它使汽车嵌入式系统控制软件开发者摆脱了以往ECU软件开发与验证时对硬件系统的依赖。

  • AUTOSAR的最基本的理念就是分层：将软件根据功能分为不同层级，并将各个功能模块化、标准化。

  • 在AUTOSAR软件架构中，汽车嵌入式系统软件自上而下分别为应用软件层（Application Software Layer，ASW）、运行时环境（Runtime Environment，RTE）、基础软件层（Basic Software Layer，BSW）和微控制器（Microcontroller）。

  • AUTOSAR整体框架为分层式设计，以中间件RTE(Runtime Environment)为界，隔离上层的应用层（Application Layer）与下层的基础软件（Basic Software）。

image

3.1 应用软件层

  • 应用软件层（Application Software Layer，ASW）由若干个软件组件（Software Component，SWC）组成，软件组件间通过端口（Port）进行交互（软件组件之间的交互必须经过RTE层）

  • 每个软件组件（SWC）可以包含一个或者多个运行实体（Runnable Entity，RE）。

  • 运行实体（RE）可以简单的理解为软件中具体的逻辑控制、算法等函数，如控制大灯，空调等部件的运作，但与汽车硬件系统没有连接。

3.2.1 软件组件通信层面的新概念(VFB)

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

3.2.2 SWC与VFB

  • 软件组件(SWC)只需向VFB发送输出信号，VFB将信息传输给目标组建的输入端口，这样的方式使得在硬件定义之前，即可完成功能软件的验证，而不需要依赖于传统的硬件系统。
    image

3.2.3 RTE与VFB

  • 中间件RTE与面向对象OO（object oriented）的编程思想非常接近

  • 所有ECU所对应的RTE都是特定的，它负责软件构件间以及软件构件与基础软件之间的通信。对于软件构件来说，基础软件不能够直接访问，必须通过RTE进入。因而RTE也被理解成是VFB的接口实现。
    image

构件之间及构件与基础软件的通信关系如图所示：
image

3.2 运行时环境

  • 运行时环境（Runtime Environment，RTE）作为应用软件层（ASW）与基础软件层（BSW）交互的桥梁。

  • RTE主要的作用就是实现软件组件间、基础软件间以及软件组件与基础软件之间的通信。

  • RTE层是AUTOSAR标准化的关键： 因为RTE封装了基础软件层的通信和服务，为应用层软件组件提供了标准化的基础软件和通信接口，使得应用层可以通过RTE接口函数调用基础软件的服务。此外，RTE抽象了ECU之间的通信，即RTE通过使用标准化的接口将其统一为软件组件之间的通信。 这样解决了应用软件层和基础软件层之间的耦合性。比如，当底层硬件改动（如MCU更改），应用软件层也不再需要改动。

3.3 基础软件层

  • 基础软件层（Basic Software Layer，BSW）被抽象为四层，即服务层（Services Layer）``、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer，MCAL）和复杂驱动（Complex Drivers）
    image
    image

    • 服务层包括系统服务（System Services）、存储器服务（Memory Services）、通信服务（Communication Services）等；
    • ECU抽象层中封装了微控制器层及外围设备的驱动，并对微控制器内外设的访问进行了统一，实现了软件应用层与硬件系统的分离。
    • 微控制器抽象层位于基础软件的最底层，包含了访问微控制器的驱动（如I/O驱动、ADC驱动等），做到了上层软件与微控制器的分离，以便应用的后续的移植复用。
    • 复杂驱动由于其严格的时序为应用层通过RTE访问硬件提供支持。

  • 基础软件层(BSW)为应用软件层(ASW)提供基础软件服务：包括硬件驱动，通信协议（CAN、LIN），诊断服务（如UDS），系统服务（如任务调度，资源分配等）等。

  • 目前AUTOSAR规范定义最为详细的部分就是基础软件层。而且判断某个软件架构是否遵守AUTOSAR规范的主要依据就在于基础软件层。

服务层

3.3.1 系统服务（System Services）

  • 系统服务（System Services）又包括Csm(Crypto Service Manager)，SchM（BSW Scheduler Module），FiM（Function Inhibition Manager），Dem（Diagnostic Event Manager），Det（Development Error Tracer）,DLT(Diagnostic Log and Trace)，ComM（Communication Manager），BswM（BSW Module Manager），EcuM（ECU State Manager），StbM（Synchronized Time-base Manager），WdgM（Watchdog Manager），AUTOSAR OS（操作系统）。

  • 基本都是由第三方软件公司提供，也是目前最为标准化的软件模块

系统服务（System Services）如下图所示：
image

3.3.2 存储器服务（Memory Services）

  • 存储器服务（Memory Services）主要由三部分组成：NvM（NVRAM Manager），Fee（Flash EEPROM Emulation），MemIf（Memory Abstraction Interface）。

image

3.3.3 通信服务（Communication Services）

  • 通信服务（Communication Services）主要由Com（Communication），Dcm（Diagnostic Communication Manager），Dbg（Debugging），SM（State Manager，如CanSM），NM（Network Management，如CanNm），PduR（PDU Router），TP（Transport Layer），IpduM（IPDU Multiplexer），Xcp，SoAd（Socket Adaptor）等软件模块组成。

  • 这一层次的软件模块大部分由第三方公司提供，也有不少的软件模块是OEM或Tier 1开发的。

image

ECU抽象层（ECU Abstraction Layer）

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

  • ECU抽象层将ECU结构进行了抽象，负责提供统一的访问接口，实现对通信、存储器或者I/O的访问，从而不需要考虑这些资源是由微控制器片内提供的，还是由微控制器片外设备提供的。

  • ECU抽象层正如名字一样，和ECU硬件息息相关，但和MCU无关。这种无关性正是由微控制器抽象层来实现的。

微控制器抽象层（Microcontroller Abstraction Layer，MCAL）

  • 微控制器抽象层（Microcontroller Abstraction Layer，MCAL），是对MCU硬件的抽象，是实现不同硬件接口统一化的特殊层。

  • 微控制器抽象层分为微控制器驱动（Microcontroller Drivers）、存储器驱动（Memory Drivers）、通信驱动（Communication Drivers）以及I/O驱动（I/O Drivers）。这些驱动程序基本都是由MCU芯片厂商提供的。

  • 此层软件模块主要由各个驱动程序构成。其中有我们常见的SPI驱动程序，CAN驱动程序，LIN驱动程序，MCU驱动程序等。

复杂驱动层（Complex Drivers）

  • 由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，难以抽象，所以在AUTOSAR规范中这部分没有被标准化。

4、如何学习？

官网地址

image

官网链接如下：
https://www.autosar.org/

AUTOSAR Classic Release R22-11:
https://www.autosar.org/search?tx_solr[filter][0]=category%3AR22-11&tx_solr[filter][1]=platform%3ACP&tx_solr[q]=

标准文档命名

AUTOSAR的文档遵循下面的命名规则，了解这些可以更容易的理解其代表的含义：

  • EXP:
    "解释"，更详细的介绍论题
  • MMOD:
    "元模型"，介绍 AUTOSAR的元模型
  • MOD:
    "建模",介绍建模的原理
  • RS:
    "需求规格", 详细描述需求
  • SRS:
    "软件需求规格", 所有软件模块的规格描述
  • SWS:
    "软件规格", 软件模块设计和实现的规格
  • TPS:
    "模板规格", 元模型详细介绍
  • TR:
    "技术规格",技术规格详细介绍

对于终端使用者，关注以RS,SRS,SWS,TPS,TR命名的标准文档，在使用工具进行开发配置中，其配置工具手册中也都会介绍具体资料，所以在一开始阅读所有的文档对我们帮助不大，可以在使用时，按需要详细阅读对应的AUTOSAR规范文档

从Classic AUTOSAR 入门

  • 主要基于CLASSIC AUTOSAR，针对AUTOSAR的终端使用者，而非工具链开发商和平台开发人员。
    image

image

链接地址：https://www.autosar.org/standards/classic-platform

  • Classic AUTOSAR 适用于实时控制，资源有限的控制器上，目前大多数的跟传感器或者执行器相连的控制器都适用。
  • Adaptive AUTOSAR 适用于具有较强计算能力的芯片的控制器上，可以实现较大数据吞吐和计算能力的控制器上，一般不用于实时控制，如Domain/Zone控制器及“Vehicle Computer”。

从Adaptive AUTOSAR 深入

  • 针对Adaptive AUTOSAR的入门，也建议从Classic AUTOSAR入门，

  • Adaptive AUTOSAR规范中定义的很多中间件功能族或者服务都是从Classic AUTOSAR演化而来，如果有Classic AUTOSAR的基础，那么理解Adaptive AUTOSAR也会简单很多。

  • Adaptive AUTOSAR不同于Classic AUTOSAR，职责划分很明晰，Adaptive AUTOSAR更侧重于应用层的应用，故学习Adaptive AUTOSAR，着重学习：

  1. Adaptive AUTOSAR的方法论

  2. SOA的架构

  3. SOA的基于SOME-IP的实现机理

  4. Application的SWC设计

一、角色定位

  • 首先问问自己目前的角色是什么？即将成为什么角色。因为角色不同，那么AUTOSAR应用的场景也不同，自然AUTOSAR工程师要做的事情也是不同的，对AUTOSAR掌握的程度和角度也不一样。

  • AUTOSAR很多规范是给基础软件包/工具供应商或者半导体厂商参考去实现具体的BSW协议栈或者芯片对应的MCAL.

  • 针对不同工作职责，需要深入了解AUTOSAR的侧重有差别:

    • 针对架构工程师，仅仅需要深入了解AUTOSAR的方法论及SWC的设计方法及技巧。
    • 针对算法工程师，仅仅需要深入了解SWC的设计方法。
    • 针对底层芯片驱动工程师，仅仅需要深入了解芯片抽象层MCAL的各个功能模块的具体应用细节。
    • 针对BSW协议栈工程师，仅仅需要了解OS，ComStack，DiagStack，Memory Stack，WgdStack等协议栈的功能及应用细节。
    • 针对复杂设备驱动工程师，仅仅需要了解复杂设备驱动的AUTOSAR接口定义方式。
    • 针对集成工程师，仅仅需要深入了解RTE的运行集成及RTE相关的应用配置。

二 掌握技能Classic AUTOSAR、Linux和C++

  • Linux基础，毕竟Adaptive AUTOSAR是在Linux这种操作系统之上的中间件规范。

  • C++的基本编程经验，AUTOSAR是基于C++实现的。

posted @ 2023-05-12 23:31  登云上人间  阅读(239)  评论(0)  编辑  收藏  举报