基于AUTOSAR标准的TCU软件设计

基于AUTOSAR标准的TCU软件设计

随着AUTOSAR标准逐渐成为未来汽车软件架构的主流，作为汽

车电子核心部件的双离合变速箱控制单元(Transmission Control Unit,

TC∪),也将在今后的软件开发中遵循该标准。因此，作者在系统地 分

析AUTOSAR标准及开发方法的基础之上，研究了如何在TCU平台 上

设计符合AUTOSAR标准的应用层软件系统架构、软件组件以及接 口

层配置，其中，重点阐述了应用层软件组件的设计方法。

1. AUTOSAR

架构

基于TCU的系统需求，作者设计了符合AUTOSAR架构的TCU软

件系统架构，如图1所

示。

自适应学习

(AdaPtiOe LCarn)

同步㈱控制

(GcarControI)

应用层软

件组件

(ASW)

协调控制

—CtAuxiIiary Coordinator

电子泵控制

Motor Control}

—TT^

(Dia^nois∖Signal Process)

诊断及信号处理

信号解析和传输

tput)

I I J(RTE)

基础软

件层

(CDD)

(BSW)

操作系统殄断管理 内存管理Jl

系统(DEM) (MCmory) (COM)I (GPJO)

(OS)

微控制器(MiCrO Controller)

图1 AUTOSAR软件架构

为了实现软件功能的复用和标准化，AUToSAR定义了层次化、模

块化的体系架构，划分为以下3个模块:

1.1

应用软件层SWC

应用层代表着汽车电子软件中最核心的功能，控制功能设计都在

这一层进行。应用层最基本的组成是软件组件SWC ( Software

Component),包括图1中的信号处理、离合器控制、协调控制、同 步器控制、电子泵、自适应学习等功能组件。每个SWC都封装了单 个或多个运行体(RUnnableS),并通过实时环境实现软件组件之间的 通信、系统功能调用以及TCU硬件资源的访问。

1.2

实时环境

RTE如图1中的链接线，RTE ( Runtime Environment)实现了应用 层软件与底层基础软件之间的分离,上层的每个SWC都与RTE交互， 使得数据与事件传递到其他各个模块。RTE实现了对I/O、存储和其 他基本服务的访问。

1. 3基础软件层

BSW如图1所示,基础软件BSW(BaSiCSoftWare)位于RTE之 下、

微控制器硬件之上，起到承上启下的作用。BSW主要为应用层提供硬

件驱动、网络通信和实时任务调度等底层服务。BSW本身又包括微控

制器抽象层、ECU抽象层、服务层以及复杂驱动层。BSW每一层均向

其上层软件组件提供服务，并屏蔽了其下层的实现细节。例如，微控

制器抽象层为ECU抽象层提供服务,却并不涉及微控制器与外部设备

具体的物理连接，如接口类型和引脚等。

系统结构设计需要根据系统需求来详细定义上述3个模块的拓

扑结构，并定义各模块内功能子系统的接口属性。

2. AUTOSAR

应用层软件组件开发应用层软件是由多个相互交互的SWC构成,

SWC的设计除了定义自身的类型外，还需定义端口、接口、运行实体

及触发运行实体所对应的RTE事件等属性，如图2所示。

(软件组件，

< (SWC)

J

G≡□

C≡M)

2. 1 SWC

供型端口(P∙Port)

需型端口()

发送/接受型接LI

(Sender-Receiver)

I标定参数I

客户/服务型接口

(CIient-Servicer)

内部行为

(Internal

BehaViOr)

SinIUIink

模型

类型AUToSAR按功能属性将SWC划分为应用层、传感器/执行 器、标定参数、服务层、ECU抽象层、复杂设备驱动等类型。如图1

中的Input

∖0utput组件即为传感器/执行器类型的SWC,而Auxiliary

COOrdinatOr等组件则实现了

TCU应用层控制策略，即为应用层类型

的SWC。以下描述的属性设置都针对应用层SWC。

2. 2 SWC属性设置

2.1.1

端口

端口（POrt）定义了

SWC与外界通信的传输方向以及所承载的接

□。根据传输方向，端口分为供型端口

（ Provide-Port,对外提供某种

数据或者某类操作）和需型端口（

Receive-Port,请求从其他SWC获 得所需数据或者操作）。要实现数据由供型端口传向需型端口，还需 对这两个端口指定数据传输的接口类型。

ECU

图3 SWC之间端口和接口连接示意图

如图3所示，设置Motor Control的端口为供型端口，Input/OUtPUt

的端口为需型端口,两者之间的数据通过这两个端口中的接口实现

传输。

2.1.2

软件接口

端口只定义了软件组件间通信方向，其中的通信内容及交互方

式则由AUToSAR中定义的接口（InterfaCe）来描述。对于应用层软

件,接口有2种：发送者/接收者接口

（ Sender-Receiver:直接访问 数据的n:n交互方式，文中主要用于应用层各SWC间的交互)；客 户端/服务器接口(Cliem-SerVer:通过参数调用访问数据的l:n交互 方式，文中主要用于应用层SWC与BSW之间的交互)。如图3所 示，

Motor Control

与

Output

通过

Sender-Receiver

接 口交互数据;

Input

/0UtPUt

通过

Client-SerVer

接口与

BSW

的复杂驱动层(CDD)

进行数据交互，复杂驱动层即为服务端。

2.1.3

运行实体

运行实体(Runnables)定义了

SWe所需实现的功能函数及其 输入输出信号，而TCU的功能函数是由基于Simulink开发的模型来 实现。为生成符合AUToSAR要求的SWC代码，需要将SimUlink模 型通过dSPACE公司提供的TargetLink工具封装成AUTOSAR架构模 型。

图4 AUTOSAR架构转换

如图4所示，架构模型的封装包括:模型封装成运行实体，相应

的输入输出封装成虚拟BUS,并从SWC的端口中提取所需的信号。 此外，运行实体还提供了参数访问端口，通过该端口模型可以访问外 部的标定参数。

运行实体的运行是由触发事件来激活的，为此AUTOSAR定义了

多种触发类型，而对于实时性要求比较高的TCU应用层软件，运行实 体都选择由周期性时间来触发运行。具体的触发周期需由运行实

体的 设计要求而定,如图1中的Auxiliary Coor-dinator的运行周期为5ms,

而控制要求更高的Motor Control,运行周期为2.5mso

2.3组合

按上述方法设计完成的SWC只是独立的个体描述，要想将这些

SWC关联起来并通过RTE来实现这些关联，则需将这些描述进行实例

化并加载到一个容器里，此容器即称之为组合(COmPOSition)。组合 原则上可以有多个，这里只需创建一个即可。

在组合里，包含了

SWC和BSW各模块的实例，通过关联实例之

间的端口来创建彼此链接关系。需要注意的是，不同接口类型的端口

之间不能创建链接,而且只能由Sender指向Re-CeiVer,或只能由Client

调用SerVer,反之都无法链接。除了建立内部链接，还需定义外部端 口来与外部系统通信，对于TCU,即实现与CAN总线的链接。

文中通过dSPACE公司的SyStemDeSk工具创建了如图5所示组合。

TCU应用层软件基本功能

来自BSW的输入信号转化

行驶环境识别功能

自动换挡目标识别

离合器控制功能

同步器

控制功

能

j正常控制模式∣→

熄入故障控制模式i

防火控制预充控制

变速箱本体

保护功能

输信转一电信转白学习功能

出号换气号换信号换-Cm信转操系服

-C

自适应功能

杂动号换

主油路控制 冷却控制发动机扭矩协调

电子泵控制来自BSVV的电8区馈W号转换

作统务复驱信

图5组合的内部连接图

3. RTE配置

前面描述了

TCU的系统架构和软件组件,但如何将这些设计映射

到具体的ECU中及其代码实现则需要通过配置RTE来完成。

SWC与BSW、SWC之间的交互都是通过RTE提供的虚拟功能总线通

信机制(VirtuaIFiIe System, VFS)来实现的，如图6所示。

图6 RTE实现的VFS通信机制

这样的设计抽象了应用层和基础层，能防止SWC直接访问BSW

和OS,有利于监控数据传输并保证数据一致性，而且同时支持简单 数据及复杂数据结构以及SWC的多途径应用。

配置完成的RTE将自动生成C语言代码，上述的数据交互是通过

函数调用的方式实现，而不是传统嵌入式C代码(ERT)中的变量直接 赋值形式。两者间的差异如表1所示。

AUT0SAR ERT

函数定义

输入输

出信号

运行实体 信号名定义接口元素

输入输出信号通信都定

义成函数调用的方式

函数体

信号名定义变量

输入输出信号

为变量形式

表1 AUT0SAR代码与ERT代码的差异

RTE

定义的接口函数结构如下：Rte_lread__

_ ()

其中:Vre>为运行实体的名字;

为端□ ;

为端口接口中 的某个数据元素;为从端口读到的基本类型元素的值，或 是复杂类型元素的指针。

以变速箱的拨叉位置信号为例，RTE代码里定义了

Rte」Read_Run_AC_RP_SP_Positon()接口 函数，Auxiliary Coordinator

的运行实体只能通过调用该函数来读取拨叉位置信号值。

同样地，写入拨叉位置信号值，需要InPUt的运行实体调用

Rte」Write_Run」P_PP」P_Positon()来实现。

RTE还需配置运行实体与操作系统中任务(Tasks)的映射关系以及

ECU内部信号与系统信号（CAN信号）的映射关系，这些映射关系

也会在RTE代码中实现定义。

通过ETAS公司的ISOLAR-A工具完成RTE配置，如图7所示。

•运行体到操作系统任务的映射

• Flat映射

・应用层软件的嵌入

•CAN信号映射

RTEffdg

图7 RTE配置

4.测试验证

将上述设计的配置文件通过TargetLink. RTA-RTE等工具转换为真 实的C代码，同时嵌入各组件的功能代码以及BSW的目标代码文件， 再通过编译、链接等步骤生成十六进制文件（*.Hex）,最后，将 其下载到目标TCU中，并在硬件在环测试平台下进行测试，如图8

所示。

图

8硬件在环测试平台

该硬件在环平台可以通过dSPACE软件仿真整车环境并注入故障,

而TCU与电磁阀、传感器等真实负载相连。通过该平台可以真实有效

地测试TCU软件系统的接口功能,用以检验基于AUTOSAR标准的TCU

软件开发方法应用是否正确，能否达到预期目标。

软件组件SWC和RTE是AUTOSAR的重要概念之一，因此测试SWC

和RTE能否成功在TCU上运行，将是检验软件开发方法的重要标准。

4.1 RTE接口测试

以位置信号为例，该信号的原始值由底层GPIO的频率传感器模

块输出，并经由RTE传至应用层的InPUt软件组件中，再经过信号处

理组件处理后输出给AUXiliary CoOrdinator使用。测试结果如图9所示。

80 -

IOO

60 ∙

40 -

20 -

100 —

8() ■

60 ■

40 -

20 -

OJ

10.3

10.35 10.4 10.45

图9拨叉位置信号采集

10.5

时间∕ms

10.55 10.6 10.65

采 集 到 的

PositionRAW

即 为 通 过

Rte Call Run IP RP IP Positon(&

PositonRAW)接口函数调用到的位 置信号原始值，而Position则为经过信号处理⑸gnal Process)组件之 后的值，即通过Rte_lReacLRUn_AC_RP_SP_PoSiton()接口函数读取到 的值。显然，测试结果符合预期结果。

4.2 RTE任务调度测试

任务调度测试的主要目的是为了验证AUTOSAR操作系统的基本

功能是否正常运行。比如RTE是否成功配置SWC的运行实体与任务 的映射链接。测试结果如图10所示。

SaIs

1 Ol O1 Ol O 1

Oi O -nd≡

SE s

O-WPOU -OJJUO Jn≡∙no

SBJlSqeUUnH

足杰出

冲甲oB≡xnγ J20

二福弟仁四£」味中•二

雉林仁四时间∕ms

图10任务和运行实体的执行过程

y轴表示任务和运行实体的运行状态。Auxiliary Coordinator和

InPUt都放在5ms任务下运行，Input首先运行，执行完毕之后进入等 待状态,同时激活AUXiliaryCOordinate)r的运行。同样地,放在2.5ms

任务下的Motor Control首先激活，并在运行完毕后激活Out-put里的

RunnabIeJasto测试结果显示，TCU软件已经实现了操作系统的基本 调度功能。