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

袁仲楠

（上海怿星电子科技有限公司，上海201908）

摘要：提出一种基于AUTOSAR的车用控制器软件开发流程与实现方法。E/E系统功能以模型为基础进行开发，并将功能部署到硬件控制器，通过功能模型提取AUTOSAR系统描述文件（*.arxml），导入到MATLAB/Simulink中进行应用层软件组件开发；通过ECU 提取文件（*.arxml）导入到协议栈配置工具DaVinci中生成RTE和基础软件（BSW）部分；最后，集成两部分代码进行调试和编译。开发过程中，同时可搭建虚拟仿真环境，对E/E系统设计模型进行仿真和验证。

关键词：AUTOSAR；软件组件；控制器开发；ARXML

0引言

汽车自诞生百余年来，已经从纯粹的机械时代逐渐进化到了如今的智能、网联、电动、自动化时代，软件、芯片、计算能力等正变得越来越重要。当前汽车行

业上的创新和发展趋势，绝大部分也

都体现在电子电气领域。软件在汽车

的总体价值中，所占比重正在逐步增

长。对OEM而言，软件的可重用性、代

码质量和开发效率显得至关重要，它

可以帮助更好地平衡车型研发成本、

开发周期和质量之间的关系。

AUTOSAR作为汽车电子行业的

标准，致力于解决硬件平台不同带来

的软件开发的困难。通过提供标准的

软件接口定义，将应用层软件（SWC）

和硬件平台解耦，软件组件可以按需分配到不同的ECU中，实现软件组件的可重用性，大幅提高开发效率，已被主机厂广泛采用。

1基于模型的功能开发

汽车上控制系统的软件架构包含运行环境和应用软件，运行环境包括操作系统、驱动程序、通信

协议栈以及网络管理、诊断应用等服务。

对主机厂而言，关心的是和功能挂钩的

应用软件。为保证应用软件开发质量，尽

快达到可靠的成熟度以及实现功能可重

用性，同时减少功能开发对供应商的依赖

性，通常采用以模型为基础（Model-Based）

的功能软件架构开发方式。在功能模型

的基础上，获得系统描述规范，进一步获

得自动软件代码生成器。

以泊车辅助功能为例，利用内嵌在

车后保险杠上的4个接近传感器（超声波

传感器）探测后方障碍物，根据车辆接近

障碍物的距离，发出不同频率的警告声。

后视摄像头提供倒车可视画面，整个辅

助系统可以由驾驶员使能（选择激活或者不激活）。采用基于模型的功能开发思路，将系统的功能拆解为各个小功能块，如传感器数据预处理模块、数据融合模块、泊车辅助算法等，分别对应不同的软件组件（SWC），各功能块之间通过AUTOSAR 标准接口（如S/R、C/S接口等）进行数据交互。泊车辅助系统的功能模型如图1所示。

2控制器AUTOSAR软件开发

2.1AUTOSAR软件开发流程

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

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

第二步，将系统描述文件（.arxml）导入MATLAB/Simulink 图1泊车辅助系统功能模型

图2AUTOSAR软件开发流

程

156

软件组件

ECU 部署类型

描述

SensorPreprocessingSWC1-4Sensor /Actuator SWC CAS 超声波传感器预处理1～4CameraPreprocessSWC

Sensor /Actuator SWC 后摄像头数据预处理PAC AlarmSWC

Sensor /Actuator SWC

接近警报发生器

BCM

SwitchSWC ECU Abstraction SWC I /O 硬件开关信号处理

BCM UltrasonicProcessSWC Application SWC 超声波处理CAS DataFusionSWC Application SWC 数据融合PAC ParkingAssitSWC Application SWC 泊车辅助控制算法

PAC DisplaySWC Sensor /Actuator SWC 泊车显示Display 中搭建功能控制算法模型，完成控制器应用层软件组件开发。

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

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

系统功能模型开发

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

2.3应用软件开发

MATLAB /Simulink 提供了一个动态

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

基于Simulink 的软件组件开发主要是

对AUTOSAR 软件组件内部行为（Internal Behavior ）的实现，即实现运行实体（RunnableEntity ）中的内部控制算法。PREEvision /AUTOSAR 中模型元素和MATLAB /Simulink 元素对照如表2所示。

在PREEvision 中已经定义了泊车辅助控制系统中所有的

软件组件（SWC ）及其内部行为（如运行实体、

RTE 事件、运行实体间变量、变体等），这些内容通过AUTOSAR 标准接口arxml 文件直接转换为Simulink 模型，这是一种“自上而下”的正向开发流程。其中，导入MATLAB 中的语句如下：

//读取本地arxml 文件

importerObj=arxml .importer ('PAC_V2.1.arxml')

//创建Software Composition 的Simulink 模型importerObj.createCompositionAsModel

('/SoftwareTypes /ComponentTypes /XCUEcuComp','ModelPeriodicRunnablesAs','FunctionCallSubsystem')

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

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

表1泊车辅助系统功能软件组件设计

图3泊车辅助控制器软件部署

表2AUTOSAR 与Simulink 元素对应关系

AUTOSAR 元素MATLAB /Simulink 元素Composition （部件

）

Virtual Subsystem （虚拟子系统）Inter Runnable

Variable （运行实体间变量）

Signal （信号）

Runnable Entity （运行实体）Function Call Subsystem （函数调用子系统）

C /S RPort （C /S 需型端口）

Function Caller （函数调用模块）

Atomic SW -C （原子软件组件）

Virtual /Non -virtual Subsystem （虚拟/非虚拟子系统）Sensor /Actuator SW -C （传感/执行软件组件）

Virtual Subsystem （虚拟子系统）RTE Event （RTE 事件）Function Call （函数调用）S /R PPort （S /R 供型端口）Outport （输出端口）S /R RPort （S /R 需型端口）Inport （输入端口）C /S PPort （C /S 供型端口）Simulink Function （函数模块）图4PAC 软件组件Simulink 模型

157

（1）AUTOSAR Properties 以及Simulink -AUTOSAR Mapping 设置；

（2）系统目标文件设置为autosar.tlc ；

（3）配置求解器（Solver ）步长模式为定步长（Fixed-step ）。通过Simulink 生成的AUTOSAR 描述文件，反过来，也可以重新导入至PREEvision 中，从而将软件开发人员在Simulink 中对软件组件做出的修改同步到PREEvision 中完善功能架构模型。二者之间的数据传递交互过程如图5所示。

2.4基础软件及RTE 开发

AUTOSAR 软件体系架构中，在应用层（Application Layer ）

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

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

对于PAC 控制器，在DaVinci Configurator 新建一个AUTOSAR 工程，加载从PREEvision 中导出的ECU 提取文件（*.arxml ），以CAN 模块为例，其配置参数如下：

（1）CanControllers 通用配置。

Busoff Processing ：用于处理Busoff 事件，中断或者轮询；

Clock Frequency [MHz ]：设置CAN 模块的时钟；Physical Node ：CAN 节点；

Rx /Tx Processing ：接收/发送数据的处理方式，中断或者轮询。

（2）CanControllers 波特率配置。

Controller Baud Rate ：设置CAN 波特率的值；BRP ：波特率预分频因子；

Controller Prop Seg /Seg1/Seg2：设置传播端时间/采样点时间；

Controller Sync Jump Width ：设置同步跳跃宽度，用于重同步。

（3）CanControllers 过滤器配置。Filter Code /Mask Value ：过滤器设计成Code 和Mask 两个部分，通过条件为Received CAN ID &Mask ==Code 。

（4）CanHardwareObjects 配置。

Controller Ref ：硬件MO 所属的CAN 节点；Id Type ：标准帧或者扩展帧；Id Value ：CAN ID ；

Object Type ：设置接收还是发送。（5）CanGeneral 配置。

Base Address ：寄存器的基地址；Clock Divider ：时钟分频器；

Clock Divider Mode ：时钟分频器的模式，Normal:fCAN =fSYS *1/n 。

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

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

编译与调试

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

（1）应用层软件组件代码（由Simulink 生成）；

（2）运行时环境RTE 代码（由DaVinci Configurator 生成）；（3）基础软件BSW 代码（不含MCAL ，由DaVinci Con -figurator 生成的动态代码+部分静态代码）；

（4）MCAL 代码（由芯片供应商MCAL 配置工具生成）。代码集成编译的过程如图6所示，需要选择跟硬件匹配的编译器，比如PAC 控制器用的是AURIX 系列单片机，可选择TASKING 或者HighTec 。代码编译通过之后，使用调试器将可执行文件烧写到硬件中进行软件调试和优化。

3系统仿真

在前期系统功能设计过程中，可以辅助以仿真工具进行

模拟及验证，确保前期功能逻辑以及通信矩阵设计的正确性。仿真的通信数据库arxml 文件由PREEvision 导出，导入CANoe 中可自动生成整个网络模型。前期的功能逻辑可以由CAPL 进行编写，也可以利用Simulink 中搭建好的算法模型，转化为dll 库文件。将dll 文件导入CANoe 仿真工程中对应的节点，便可进

图5基于标准接口———arxml 文件的工作流

程

图6AUTOSAR 软件代码集成流程

158

（上接第155页）

声信号和无人潜水器摄像头的可见光信号探测海床面存在的大型金属物体，判断海底电缆敷设路径上是否存在安全隐患。

搭载在潜水器上的声呐装置可以监测到大型外破物体的外形，进而使运维人员发现外破点的发生处；在电磁感应装置上加装的水下高清摄像头则可以发现外破装置的影像，这种从电磁感应平面发现外破点的方式降低了水下观测点遗漏了对外破物的观测的可能，在搜索到海底电缆路径的同时，可以在需要快速查找故障点时及时有效发现外破物。

4故障识别

当通过路径检测找到海底电缆路径后，逐步向对岸行驶

的过程中，会越来越靠近故障点，在接近故障点时，声呐可以探测到潜水器前进路程中的大型障碍物，在探测到大型障碍物后，使用金属探测摄像头能确定是否为故障点。因为在海底电缆路径上，所以可以保证发生外破故障后探测到的路径上的大型障碍物是后来插入该区域海床面的，也就一定是外破引发物，进而确定外破点，可以针对性地进行故障消缺工作。

5结语

综上所述，本文提出的海底电缆路径故障探测仪通过识

别海底电缆铠装层的方式，使用金属探测，配合海面端的控制器提示和微型无人潜水器，即可有效探寻到海底电缆的路径；通过声呐和搭载在电磁感应识别装置上的水下摄像头可以观

测到电缆路径上已发生的外破故障点情况，通过声呐定位和水下摄像头水平角度的探测、分析，可以定位故障点，实现精准定位消缺。本技术具有经济、轻便、操作难度低的优点，值得运用推广。

［参考文献］

[1]邱巍，鲍洁秋，于力，等.海底电缆及其技术难点[J].沈阳工

程学院学报（自然科学版），2012，8（1）：41-44.

[2]韩志军，陈光.海底电缆登陆点及路径选择研究[J].吉林电

力，2013，41（2）：7-8.

[3]朱晓光.海底电缆的故障检测及修复工艺探讨[J].科技创新

与应用，2014（2）：86.

[4]李西华，刘玉君.海底电缆故障原因分析与维修方法探究

[J].科研，2017（3）：177.

收稿日期：2019-11-12

作者简介：张羽（1990—），男，湖北宜昌人，硕士，工程师，从事输电线路运行与维护工作。

行功能仿真，验证算法逻辑正确性。CANoe 中系统仿真示意如图7所示。

4结语

本文提出了一种基于AUTOSAR 的车用控制器软件开发

流程和实现方法，结合当前最主流的基于模型的开发思路，从功能模型开发到应用软件设计、基础软件开发、集成与调试以及系统开发过程中的仿真验证，基于这一整套完善的方法和流程可以实现车内各功能应用的跨车型、跨平台的可重用

性。同时，在充分的AUTOSAR 工具链的支持下，可以大幅提高符合AUTOSAR 标准的软件开发效率，同时保证软件开发的

质量。

［参考文献］

[1]童年，周三国.整车电气架构设计方

法[J].上海汽车，2010（4）：13-15.[2]李震，刘敏.基于Autosar 的整车电子

电气架构设计方法[J].机电一体化，2012，18（11）：73-76.

[3]朱元，陆科，吴志红.基于AUTOSAR 规

范的车用电机控制器软件开发[M].上海：同济大学出版社，2017.[4]倪斌.汽车电子电气架构设计与优化

研究[J].电子技术与软件工程，2013（17）：270.

[5]伏军锋.汽车电气系统设计[J].汽

车电器，2010（1）：1-3.

收稿日期：2019-11-22

作者简介：袁仲楠（1990—），男，江西吉安人，助理工程师，从事整车电子电气架构设计的研究工作。

图7CANoe 仿真说明

图

159