基于AUT0SAR的车用控制器软件开发

引言

汽车自诞生百余年来,已经从纯粹的机械时代逐渐进化到了如今的智能、网联、电动、自动化时代,软件、芯片、计算能力等正变得越来越重要。当前汽车行业上的创新和发展趋势,绝大部分也都体现在电子电气领域。软件在汽车的总体价值中,所占比重正在逐步增长。对0EM而言,软件的可重用性、代码质量和开发效率显得至关重要,它可以帮助更好地平衡车型研发成本、开发周期和质量之间的关系。

AUT0SAR作为汽车电子行业的标准,致力于解决硬件平台不同带来的软件开发的困难。通过提供标准的软件接口定义,将应用层软件（SWC)和硬件平台解耦,软件组件可以按需分配到不同的ECU中,实现软件组件的可重用性,大幅提高开发效率,已被主机厂广泛采用。

1基于模型的功能开发

汽车上控制系统的软件架构包含运行环境和应用软件,运行环境包括操作系统、驱动程序、通信协议栈以及网络管理、诊断应用等服务。对主机厂而言,关心的是和功能挂钩的应用软件。为保证应用软件开发质量,尽快达到可靠的成熟度以及实现功能可重用性,同时减少功能开发对供应商的依赖性,通常采用以模型为基础（MOdel-BaSed)的功能软件架构开发方式。在功能模型的基础上,获得系统描述规范,进一步获得自动软件代码生成器。

以泊车辅助功能为例,利用内嵌在车后保险杠上的4个接近传感器（超声波传感器)探测后方障碍物,根据车辆接近障碍物的距离,发出不同频率的警告声。后视摄像头提供倒车可视画面,整个辅助系统可以由驾驶员使能（选择激活或者不激活)。采用基于模型的功能开发思路,将系统的功能拆解为各个小功能块,如传感器数据预处理模块、数据融合模块、泊车辅助算法等,分别对应不同的软件组件（SWC),各功能块之间通过AUT0SAR标准接口（如S/R、C/S接口等)进行数据交互。泊车辅助系统的功能模型如图1所示。

2控制器AUTOSAR软件开发

2.1AUTOSAR软件开发流程

功能模型开发是控制器软件开发的基础,控制器最终的软件开发取决于功能块的部署。一种基于AUT0SAR的车用控制器软件开发流程如图2所示。

第一步,采用基于模型的E/E架构开发工具PREEviSiOn进行功能模型开发,并部署到硬件控制器。基于功能模型,提取AUT0SAR系统描述文件和ECU抽取文件。

第二步,将系统描述文件（.arxml)导入MATLAB/Simulink中搭建功能控制算法模型,完成控制器应用层软件组件开发。

第三步,将ECU抽取文件(arxm1）导入到协议栈配置工具VectOrDaVinciCOnfiguratOr中,配置AUTOSAR运行环境,包括RTE、操作系统、通信协议栈、底层驱动程序、网络管理/诊断等服务模块。

四步,两部分代码集成编译以及调试,之后下载到控制器中,完成整个AUTOSAR软件开发过程。

2.2系统功能模型开发

针对泊车辅助功能,按图1在PREEviSiOn中搭建泊车辅助功能软件架构模型（SWC、端口、Interface/DE、数据类型等）,并进一步详细定义各SWC的内部行为,如RTEEvent、Runnab1e、变量等。这些软件组件属于AUTOSAR应用层,完全独立于硬件,可在不同项目、不同平台中实现复用。之后,将各功能部署到对应控制器并进行信号路由,完成通信层设计。表1是泊车辅助系统功能软件组件定义,图3是泊车辅助控制器（PAC）的功能部署实例。

2.3应用软件开发

MATLAB/Simu1ink提供了一个动态系统建模、仿真和分析的集成环境,在该环境中,无需大量手写程序,只需通过直观地构建算法模型便可构造出复杂的系统。EmbeddedCOder具有生成可读、紧凑且高效的C和C++代码的功能,以便用于各种嵌入式处理器和量产微处理器,同时,EmbeddedCOder支持生成AUTOSAR和ASAP2软件标准的代码。基于上述两个工具,可以实现控制器应用层软件控制算法的图形化设计和代码自动生成。

基于Simu1ink的软件组件开发主要是对AUTOSAR软件组件内部行为（Interna1BehaviOr）的实现,即实现运行实体（Runnab1eEntity）中的内部控制算法。PREEviSiOn/AUTOSAR中模型元素和MATLAB/Simu1ink元素对照如表2所示。

在PREEviSiOn中已经定义了泊车辅助控制系统中所有的软件组件（SWC）及其内部行为（如运行实体、RTE事件、运行实体间变量、变体等）,这些内容通过AUTOSAR标准接口arxm1文件直接转换为Simu1ink模型,这是一种"自上而下"的正向开发流程。其中,导入MATLAB中的语句如下:

//读取本地arxm1文件

impOrterObj=arxm1.impOrter('PAC)V2.l.arxm1'）

//创建SOftWareCOmpOSitiOn的Simu1ink模型impOrterObj.createCOmpOSitiOnASMOde1

('/SOftWareTypeS/COmpOnentTypeS/xCUEcuCOmp','MOde1PeriOdicRunnab1eSAS','FunctiOnCa11SubSyStem'）

图4是PAC中的数据融合软件组件导入到Simu1ink中生成的模型示意,其他软件组件模型类似。

在该模型的基础上,进一步完成各函数调用子系统的内部控制算法的实现,然后即可通过Bui1dMOde1生成符合AUTOSAR规范的软件组件代码（*.c和*.h文件）及arxm1描述文件。生成代码之前需要配置以下内容:

(1）AUTOSARPrOpertieS以及Simulink-AUTOSARMapping设置:

(2）系统目标文件设置为autOSar.tlc:

(3）配置求解器(SOlver）步长模式为定步长(Fixe4-Step）。

通过Simulink生成的AUTOSAR描述文件,反过来,也可以重新导入至PREEviSiOn中从而将软件开发人员在Simulink中对软件组件做出的修改同步到PREEviSiOn中完善功能架构模型。二者之间的数据传递交互过程如图5所示。

2.4基础软件及RTE开发

AUTOSAR软件体系架构中,在应用层(ApplicatiOnLayer）之下是与硬件相关的基础软件层(BaSicSOftWareBSW）,两者之间设立了一个运行时环境(RunTimeEnvirOnment,RTE）,从而形成分层体系架构。OEM专注于RTE上层和功能相关的应用层软件,而基础软件层则得到了标准化,可以由底层软件配置工具生成实现。

ECU底层软件配置包含RTE和基础软件层模块的配置。DaVinciCOnfiguratOrPrO是一个专门用于AUTOSAR规范ECU级的开发工具可以很方便地搭建符合AUTOSAR规范的实时操作系统,并对诸如通信、诊断、网络管理、硬件I/O等进行配置、验证和代码生成。

对于PAC控制器在DaVinciCOnfiguratOr新建一个AUTOSAR工程,加载从PREEviSiOn中导出的ECU提取文件(*.arxml）以CAN模块为例,其配置参数如下:

(1）CanCOntrOllerS通用配置。

BuSOffPrOceSSing:用于处理BuSOff事件中断或者轮询:

ClOckFreQuency[MqH]:设置CAN模块的时钟:

PzySicalNO4e:CAN节点:

Rx/TxPrOceSSing:接收/发送数据的处理方式,中断或者轮询。

(2）CanCOntrOllerS波特率配置。

COntrOllerBau4Rate:设置CAN波特率的值:

BRP:波特率预分频因子:

COntrOllerPrOpSeg/Seg1/Seg2:设置传播端时间/采样点时间:

COntrOllerSynchumpWi4tz:设置同步跳跃宽度,用于重同步。

(3）CanCOntrOllerS过滤器配置。

FilterCO4e/MaSkValue:过滤器设计成CO4e和MaSk两个部分通过条件为Receive4CANID&MaSk==CO4e。

(4）Canqar4WareObjectS配置。

COntrOllerRef:硬件MO所属的CAN节点:

I4Type:标准帧或者扩展帧:

I4Value:CANID:

ObjectType:设置接收还是发送。

(5）CanGeneral配置。

BaSeA44reSS:寄存器的基地址:

ClOckDivi4er:时钟分频器:

ClOckDivi4erMO4e:时钟分频器的模式,NOrmal:fCAN=fSYS*1/n。

PAC控制器中其他模块配置,如DCM&DEM(诊断模块）、EcuM(ECU管理模块）、RTE以及OS(Runnable和TaSk映射）等,此处不展开。

AUTOSARBSW中,微控制器抽象层(MCAL）是跟硬件强相关的。MCAL主要包含了硬件驱动程序,用来访问内存、通信和I/O这部分代码一般由芯片供应商提供MCAL配置工具生成.c和.z文件,如英飞凌MACL配置工具。

2.5编译与调试

在完成AUTOSAR系统级、ECU级以及软件组件相关开发与代码生成工作之后需进行代码集成与调试。完整的符合AUTOSAR规范的ECU代码包含以下四部分:

(1）应用层软件组件代码(由Simulink生成）:

(2）运行时环境RTE代码(由DaVinciCOnfiguratOr生成）:

(3）基础软件BSW代码(不含MCAL由DaVinciCOn-figuratOr生成的动态代码＋部分静态代码）:

(4）MCAL代码(由芯片供应商MCAL配置工具生成）。

代码集成编译的过程如图6所示,需要选择跟硬件匹配的编译器比如PAC控制器用的是AURIx系列单片机,可选择TASKING或者qigzTec。代码编译通过之后,使用调试器将可执行文件烧写到硬件中进行软件调试和优化。

3系统仿真

在前期系统功能设计过程中,可以辅助以仿真工具进行模拟及验证确保前期功能逻辑以及通信矩阵设计的正确性。仿真的通信数据库arxml文件由PREEviSiOn导出,导入CANOe中可自动生成整个网络模型。前期的功能逻辑可以由CAPL进行编写,也可以利用Simulink中搭建好的算法模型,转化为d11库文件。将d11文件导入CANOe仿真工程中对应的节点便可进行功能仿真,验证算法逻辑正确性。CANOe中系统仿真示意如图7所示。

4结语

本文提出了一种基于AUTOSAR的车用控制器软件开发流程和实现方法,结合当前最主流的基于模型的开发思路,从功能模型开发到应用软件设计、基础软件开发、集成与调试以及系统开发过程中的仿真验证,基于这一整套完善的方法和流程可以实现车内各功能应用的跨车型、跨平台的可重用性。同时,在充分的AUTOSAR工具链的支持下,可以大幅提高符合AUTOSAR标准的软件开发效率,同时保证软件开发的质量。