技术科普:汽车开放系统架构AUTOSAR

**01.AUTOSAR简介

汽车是现代人类实现"千里江陵一日还"的交通工具,而计算机则是使人脱离繁杂重复脑力劳动的生产技术,两者的结合催生了汽车电子产业的蓬勃发展。

21世纪初,随着汽车电子应用需求的不断增多与硬件资源不断丰富,软件系统也随之变得日趋复杂。汽车电子的主要任务本应是实现新的功能,然而越来越多的资源却被花费到【将现有解决方案移植到不同的环境中】。同时,互联组件数量的增加也使汽车电子的复杂性指数级提高,传统开发方法难以处理。为了充分发挥各个厂商的优势,分工合作共同完成复杂的ECU控制系统开发,越来越多的汽车整车与零部件厂商开始重视软件标准化。

为了处理汽车电子领域软件功能剧增的问题,通过工业范围内的标准化软件设施来大大减少结构上的复杂性,AUTOSAR协会于2003年夏天正式成立,并于次年启动了主要工作。AUTOSAR关注的范围覆盖了半导体工业、工具、软件厂商甚至汽车制造商本身,不仅可以给软件系统及车辆电子提供一个高效管理平台,也促进了两者之间的更新与交换。

AUTOSAR是AUTomotive Open System Architecture,即汽车开放系统架构的简称,定义了一套支持分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案,以便应用于不同的汽车和平台,提高软件复用、降低开发成本。 AUTOSAR提倡在汽车电子领域创造出一个标准:既是功能上、接口上的标准,也是方法上、流程上的标准,使得各个厂商可以在一个开放的平台下提供符合标准的不同实现。也就是说,在同样的标准下,谁实现得好,谁就可以赢得竞争。

具体来说,AUTOSAR的目的有:

  • 解决汽车功能可用性和安全性需求;
  • 保持汽车电子系统一定的冗余;
  • 方便移植到不同的汽车和平台;
  • 实现标准的基本系统功能作为汽车供应商的标准软件模块;
  • 通过网络共享软件功能;
  • 集成多个开发商提供的软件模块;
  • 贯穿整个产品生命期的软件维护;
  • 更充分地利用硬件平台的处理能力;
  • 进行汽车电子软件的更新和升级。

**02.AUTOSAR架构分析

AUTOSAR架构是AUTOSAR协会为了降低ECU软件开发的复杂度而提出的一套经过实践验证的软件架构,是汽车嵌入式应用功能管理的基础架构,也是开发可重用应用程序的基础。

为了实现基本系统功能及功能接口的标准化,使得功能易于继承和修改,切实提高软件的更新和升级能力,AUTOSAR将汽车电子软件架构的整体框架进行分层式设计,以中间件RTE(Runtime Environment)为界,隔离上层的应用层(Application Layer)与下层的基础软件(Basic Software)。

2.1 应用软件层

应用软件层包含若干个软件组件(Software Component,SWC),包括应用软件组件、传感器和执行器软件组件。软件组件间通过端口进行交互,再根据底层软件功能,合理地拆分为不同抽象层,这样每个抽象层都有不同的功能模块。每个软件组件可以包含一个或者多个运行实体(Runnable Entity,RE),运行实体中封装了相关控制算法,其可由RTE事件(RTE Event)触发。

从方法论上来说,应用层软件架构的基本框架为:

输入-->设定控制目标-->执行器控制-->输出-->RTE

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

2.2 运行时环境

运行时环境(Runtime Environment,RTE)为应用层软件组件提供通讯服务,抽象了ECU之间的通信,是单个ECU内部或者多个ECU之间信息交换的通讯中心,作为应用软件层与基础软件层交互的桥梁,为软硬件分离提供了可能。

RTE可以实现软件组件间、基础软件间以及软件组件与基础软件之间的通信,封装了基础软件层的通信和服务,为应用层软件组件提供了标准化的基础软件和通信接口,使得应用层可以通过RTE接口函数调用基础软件的服务,实现了对I/O、存储和其他基本服务的访问,使AUTOSAR软件组件独立于特定的ECU,开发人员得以屏蔽底层硬件的实现细节,进行应用软件的开发,并将应用软件应用在任何符合AUTOSAR标准的ECU中。

2.3 基础软件层

基础软件层(Basic Software Layer,BSW)是标准化的软件层,向AUTOSAR软件组件提供必要的服务,主要提供硬件驱动、网络通信、实时任务调度等底层服务。BSW本身又可分为四层,即服务层(Services Layer)、ECU抽象层(ECU Abstraction Layer)、微控制器抽象层(Microcontroller Abstraction Layer,MCAL)和跨越三个层次的复杂驱动(Complex Drivers),详见下图:

**服务层(Services Layer):**为应用层提供各种后台服务,比如网络管理、存储器管理、总线通信管理服务以及操作系统等。

**ECU抽象层(ECU Abstraction Layer,ECUAL):**在ECU相关硬件的基础上,为ECU提供外围设备的驱动程序,使应用层不用关心外设的位置,主要关心ECU硬件的布局和属性,与微控制器无关。ECU抽象层封装了微控制器层及外围设备的驱动,并对微控制器内外设的访问进行了统一,实现了软件应用层与硬件系统的分离,比如CAN报文内容的解析、网关报文的转发、存储器读写流程的控制等等。

**微控制器抽象层(Microcontroller Abstraction Layer,MCAL):**定义了内存接口、I/O驱动接口和通信接口,其实现与微控制器高度相关,是与硬件直接相关的驱动软件。

**复杂设备驱动(Complex Device Drivers,CDD):**可以直接访问微控制器,以实现一些复杂的传感器和控制器操作,如喷油控制、曲轴信号采集等有计时需求的特定操作。CDD为用户提供可以自行编写特殊设备驱动软件的可能,由于复杂驱动可能涉及严格的时序,所以应用层通过RTE直接访问硬件。复杂驱动层具有重要的意义,首先,它可以用于实现AUTOSAR不支持或者未标准化的硬件驱动,其次,它可以作为已经存在的应用程序向AUTOSAR过渡的接口。

详细内容见下图所示:

**03.总结

AUTOSAR概念的提出,为汽车电子系统开发模式从ECU驱动向功能驱动和架构集成的转变奠定了技术和方法学的基础。随着AUTOSAR的进一步完善和推广应用,不仅能够实现底层软件的解耦、模块化、可重用等功能,还能通过复杂驱动来实现特殊化的需求,保持一定的灵活性,实现一套代码适用多个项目,加快研发进程,降低研发成本。

相关推荐
武子康2 小时前
AI-调查研究-74-具身智能 机器人学习新突破:元学习与仿真到现实迁移的挑战与机遇
人工智能·程序人生·ai·职场和发展·系统架构·机器人·具身智能
文火冰糖的硅基工坊7 小时前
[硬件电路-170]:50Hz工频干扰:本质、产生机制与影响
嵌入式硬件·系统架构·电路·跨学科融合
码界奇点19 小时前
MongoDB vs MySQLNoSQL与SQL数据库的架构差异与选型指南
数据库·sql·mongodb·系统架构
qqxhb20 小时前
系统架构设计师备考第18天——信息安全基础知识
网络安全·信息安全·系统架构·数据安全·可用性·可控性
luoganttcc21 小时前
小鹏汽车 vla 算法最新进展和模型结构细节
人工智能·算法·汽车
准测仪器1 天前
新能源汽车中维修开关有什么作用?
汽车·电动汽车·仪器仪表·msd·维修开关·准测仪器
LabVIEW开发1 天前
LabVIEW汽车发动机振动测试
汽车·labview
yintele1 天前
智能AI汽车电子行业,EMS应用相关问题
人工智能·汽车
timmy-uav1 天前
MissionPlanner架构梳理之(十)-参数编辑器
系统架构·无人机·开源地面站·missionplanner
麦兜*1 天前
MongoDB 6.0 新特性解读:时间序列集合与加密查询
数据库·spring boot·mongodb·spring·spring cloud·系统架构