[转载]AUTOSAR简介

  1. 简介
    AUTOSAR全称为“AUTomotive Open System ARchitecture”,译为“汽车开放系统体系结构”;
    AUTOSAR是一家由汽车电子、半导体和软件行业的汽车制造商、供应商、服务提供商等公司组成的全球开发合作伙伴组织;
    AUTOSAR定义了三个文档组:Classic Platform(CP)、Adaptive Platform(AP)和Foundation(FO),基于CP和AP的ECU基于共同标准FO实现彼此连接;

来自一个技术人的学习建议:
Q:初次学习AUTOSAR应该从哪些文件入手呢?
A:AUTOSAR是一个庞大的标准,包含了超过200份规范和20000个需求。建议从阅读标准中的Layed Software Architecture文档入手。接下来可以学习AUTOSAR方法论规范(Methodology)。在接下来就是有选择性的阅读AUTOSAR模板规范(TPS)和BSW的软件规范(SWS)了。

  1. AUTOSAR核心思想
    AUTOSAR提倡“在标准上合作,在实现上竞争”原则;
    AUTOSAR核心思想是“统一标准,分散实现、集中配置”,即统一的开放平台、软件系统层次化模块化,降低应用与平台耦合性、统一格式的配置信息,集中配置生成系统;
    一个汽车电子应用系统可包含多个相互关联的AUTOSAR组件。组件通过虚拟功能总线(VFB)提供标准通信机制与服务,实现平台无关性;

  2. AUTOSAR功能
    主要功能,如下图所示:
    在这里插入图片描述
    汽车功能可用性与安全性需求
    保持汽车电子系统一定冗余;
    可移植到不同汽车的不同平台;
    将标准的基本系统功能转化为标准软件模块;
    通过网络共享软件功能;
    集成多个开发商提供的软件模块;
    更好的进行软件维护;
    充分利用硬件平台处理能力;
    汽车电子软件的更新与升级;
    AUTOSAR在汽车领域的应用,如下图所示:
    在这里插入图片描述

AUTOSAR模块功能,如下图所示:
在这里插入图片描述

  1. AUTOSAR标准分类
    4.1 Classic Platform(CP)
    CP框架进行方法(软件开发作业的流程和输入输出的形式的定义)以及应用程序接口(API)的标准化;
    CP架构在最高抽象级别上区分了在微控制器上运行的三个软件层:应用程序、运行时环境 (RTE) 和基本软件 (BSW):

应用软件层大多独立于硬件;
软件组件之间的通信通过RTE访问BSW;
RTE表示应用程序的完整接口;
BSW分为三个主要层和复杂驱动因素:服务、ECU抽象、微控制器抽象,服务分为代表系统、内存、通信服务基础结构;
在这里插入图片描述

4.2 Adaptive Platform(AP)
AP实现了 AUTOSAR Runtime for Adaptive Applications (ARA);
Adaptive标准主要针对自动驾驶和娱乐系统应用相关的标准;
AP有两种类型的接口可用:服务和 API;
AP模块结构,如下图所示:
在这里插入图片描述

AP功能概述(图片来源于“搞一下汽车电子”):
在这里插入图片描述

4.3 Foundation(FO)
FO目的是在 AUTOSAR 平台之间实现互操作性;
FO包含AUTOSAR平台之间共享的常见要求和技术规范;
在这里插入图片描述

4.4 Acceptance Test Classic Platform(AT)
在这里插入图片描述

4.5 Application Interface(AI)
在这里插入图片描述

  1. AUTOSAR 软件架构
    在这里插入图片描述

5.1 应用层
应用层包括应用软件组件、传感器、执行器软件组件;
应用层软件组件通过RTE进行内部通信和ECU资源访问;

5.2 运行环境层
RTE层与ECU、具体应用相关,应该为每个ECU分别实现;
RTE层为组件之间的通信提供了支持;
RTE层实现应用软件与硬件的无关性;

5.3 系统服务层
系统服务层包括通信、服务、操作系统,如操作系统服务、汽车网络管理、管理服务、存储服务、诊断服务、ECU状态管理;
系统服务层的实现与微控制器、ECU、具体应用相关;

5.3.1 操作系统
AUTOSAR操作系统不但以OSEK/VDX系统作为基础,同时也做了功能扩展,如下:

核心功能添加了软硬件计数器、带有时间同步的任务表、堆栈监控功能;
保护功能添加了时间同步保障、内存保护、服务保护、操作系统应用(任务执行、中断、延时、确定功能)、确定与非确定代码功能;
->时间同步保障:实现系统任务表时间同步、对芯片时间片的静态分配;
->内存保护:堆栈、私有数据、代码端的保护,分离不同应用程序在内存的物理位置;
->服务保护:避免错误、破坏性的系统调用;
->确定与非确定代码功能:确定代码可五点调用系统应用,不确定代码只能在一定限制下调用;
操作系统的扩展属性分级,如下:

扩展等级1:运用于普通的实时操作系统,包括任务管理、事件触发机制、计数、定时、消息传递等;
扩展等级2:OSEK系统和时间同步保障,有响应快、延时少、精准度搞;
扩展等级3:OSEK系统和内存保护,保障系统运行中不发生内存冲突;
扩展等级4:OSEK系统和时间同步保障、内存保护系统组成;
操作系统实现要求,如下:

静态配置;
实时系统特性;
优先级机制;
运行可靠,有自维护功能;
系统开销小,不需要外部资源;
5.4 微控制器抽象层
微控制器抽象层实现的不同硬件接口的统一,实现了对硬件的封装;
微控制器抽象层包括控制器驱动、管理微控制器的外设,如DIO、ADC、PWM、EEPROM、Flash、CCU、SPI、I2C等驱动;

5.5 复杂驱动模块
复杂驱动模块是复杂传感器和执行器操作模块的映射;

  1. 软件框架
    软件框架包括SWC、RTE、BS三个模块,模块定义如下:
    SWC:应用层软件标准的定义;
    RTE:应用层和基础层的接口;
    BS:硬件驱动、网络通信、实时任务调度等底层服务程序,:BS又分为以下4个部分:

服务层
ECU抽象层
微控制器层
复杂驱动层
软件架构的详细划分,如下图所示:
在这里插入图片描述

6.1 SWC
6.1.1 SWC概念
SWC是封装的、规范的、可重用的软件模块;
SWC是组织系统的基础单位;
SWC由核心功能(构建功能执行代码)、端口(输入端口和输出端口)、接口(VFB支持的两种通信接口,C/S通信接口和S/R通信接口)组成,如下图所示:
在这里插入图片描述

AUTOSAR一个功能可由多个SWC组成;
每个SWC封装某个应用的部分功能;
所有的SWC都必须映射到唯一的物理ECU中;
SWC功能**<示例>**,如下图所示:
在这里插入图片描述

6.1.2 SWC要求
所需数据与所能提供数据
运行时需要的系统资源
对基础硬件和软件的要求
实现的功能
6.1.3 SWC独立性
MCU型号无关
映射方式无关
与其他SWC位置无关
与系统中的SWC个数无关
6.2 RTE
RTE是ECU内部和ECU之间的信息交互中心;
RTE提供了通信抽象层,相同的接口与服务让不同ECU内部模块及ECU之间实现信息共享;
RTE将针对特定的ECU或系统配置进行裁剪(具体要求视ECU而定);

6.3 BS
BS为SWC提供了基本服务;
BS处理标准规范和ECU自带功能模块,还包括服务(诊断协议、NVRAM、Flash和内存管理)、通信(网络框架(CAN、LIN、FlexRay)、I/O管理、网络管理)等;
BS结构,如下图所示:
在这里插入图片描述

注:OSEK基础标准包括:实时操作系统(OSEK-OS)、通信子系统(OSEK-COM)、网络管理系统(OSEK-NM);

6.4 VFB
VFB将软件构件间、软件构件与基础软件间的通信进行了抽象;
VFB是虚拟硬件和独立映射系统的集合;
VFB为构件提供了标准的通信机制和服务;
VFB包含SWC标准化接口、设备驱动(底层软件中实现)、ECU抽象层(底层软件中实现)、AUTOSAR服务(底层软件中实现);
VFE的特点,如下:

所有的VFB都连接在VFB上;
VFB保证SWC之间、SWC与ECU之间的可靠通信;
VFB是SWC独立于硬件的基础;
VFB简化了SWC的设计;
VFB通信方式,如下:
C-S通信
在这里插入图片描述

S-R通信
在这里插入图片描述

VFB结构原理图,如下所示:
在这里插入图片描述

  1. AUTOSAR接口分类
    AUTOSAR支持三种不同的接口,分别是AUOSAR接口、标准化AUTOSAR接口、标准化接口;如下图所示:
    在这里插入图片描述

AUOSAR接口:描述原件接收和发送的数据和服务;
标准AUOSAR接口:AUOSAR框架定义的接口;
标准化接口:软件中具有的API;

基于AUTOSAR的ECU软件结构,如下图所示:
在这里插入图片描述

  1. 规范与标准
    8.1 SOME/IP
    AUTOSAR_PRS_SOMEIPProtocol.pdf
    Scalable service-Oriented MiddlewarE over IP简称为SOME/IP,译为“基于IP可扩展的服务中间件”;
    属于AUTOSAR Foundation(FO)部分;
    该文档定义了SOME/IP协议规范,包括消息格式、传输标准等。

AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol.pdf
SOMEIP Service Discovery简称为SOME/IP-SD,译为“SOME/IP服务发现”;
属于AUTOSAR Foundation(FO)部分;
该文档定义了SOME/IP-SD协议规范,SOME/IP-SD是基于SOME/IP进行实现的。

AUTOSAR_SWS_SOMEIPTransportProtocol.pdf
SOME IP Transport Protocol简称为SOME/IP-TP,译为“SOME/IP传输协议”;
属于AUTOSAR Classic Platform(CP)部分;
该文档定义了大SOME/IP数据包的分段与重组规范,以及SOME/IP-TP实现方法与接口标准。

AUTOSAR_SWS_SOMEIPTransformer.pdf
SOME IP Transformer简称为SOME/IP Transformer,译为“SOME/IP装换器”;
属于AUTOSAR Classic Platform(CP)部分,是对“序列化”部分的一个补充;
该文档定义Transformer的实现,实现可配置的数据序列化和反序列化;

AUTOSAR_SWS_ServiceDiscovery.pdf
Service Discovery简称SD,译为“服务发现”;
属于AUTOSAR Classic Platform(CP)部分;
定义了AUTOSAR的SD软件规范;

AUTOSAR_PRS_TestabilityProtocolAndServicePrimitives.pdf
Test ability Protocol And Service Primitives译为“测试能力协议和服务原语”;
UpperTester简称为UT,译为“上限测试”;
属于AUTOSAR Classic Platform(CP)部分;
该文档定义了UT基于以太网传输的通信指令格式,该控制指令默认使用的是UDP:1000进行传输,指令格式使用类似SOME/IP的格式进行封装。
汽车以太网测试之UpperTester

参考文章
汽车电子与软件 - 系列分享
详解AUTOSAR分层架构与软件组件
该文章中的绝大部分内容来自:微信读书《汽车嵌入式系统原理、设计与实现》- AUTOSAR体系简介,此处仅仅作为一个知识的传播;
————————————————
版权声明:本文为CSDN博主「wuli娇娇」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qq_37748525/article/details/123731395

  • 1
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值