基于AUTOSAR标准的TCU软件设计

李育

(上海汽车变速器有限公司，上海 201807)

基于AUTOSAR标准的TCU软件设计

李育

(上海汽车变速器有限公司，上海 201807)

基于AUTOSAR汽车电子软件架构标准提出了湿式双离合变速箱控制单元(TCU)的嵌入式软件架构，并对其软件组件与接口层实时环境的配置进行了详细设计。测试结果表明，接口层实时环境配置实现了应用层软件与底层基础软件的分离，并通过AUTOSAR操作系统对TCU任务进行调度。

AUTOSAR；湿式双离合变速箱控制单元；软件设计

0 引言

随着汽车电子产业的日益成熟，其内嵌的控制算法也越来越复杂，所以提高嵌入式软件的开发周期以及应用软件的可重用性，便成了各大汽车软件供应商急需解决的难题。为此，全球主流汽车制造商、零部件供应商以及半导体供应商、软件开发商在2003年联合成立了AUTOSAR(Automotive Open System Architecture)组织，建立了一种标准化的汽车电子软件平台，提出新的汽车电子开发理念来简化ECU(Electronic Control Unit,电子控制器)开发流程，即汽车电子系统开发过程中软件与硬件分离，使汽车电子开发从ECU硬件驱动转变为应用软件功能化驱动[1]。

随着AUTOSAR标准逐渐成为未来汽车软件架构的主流，作为汽车电子核心部件的双离合变速箱控制单元(Transmission Control Unit，TCU)，也将在今后的软件开发中遵循该标准。因此，作者在系统地分析AUTOSAR标准及开发方法的基础之上，研究了如何在TCU平台上设计符合AUTOSAR 标准的应用层软件系统架构、软件组件以及接口层配置，其中，重点阐述了应用层软件组件的设计方法。

1 AUTOSAR架构

基于TCU的系统需求，作者设计了符合AUTOSAR架构的TCU软件系统架构，如图1所示。

图1 AUTOSAR软件架构

为了实现软件功能的复用和标准化，AUTOSAR定义了层次化、模块化的体系架构，划分为以下3个模块[2-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(Basic Software)位于RTE之下、微控制器硬件之上，起到承上启下的作用。BSW主要为应用层提供硬件驱动、网络通信和实时任务调度等底层服务。BSW本身又包括微控制器抽象层、ECU抽象层、服务层以及复杂驱动层。 BSW每一层均向其上层软件组件提供服务，并屏蔽了其下层的实现细节。例如，微控制器抽象层为 ECU 抽象层提供服务，却并不涉及微控制器与外部设备具体的物理连接，如接口类型和引脚等。

系统结构设计需要根据系统需求来详细定义上述3个模块的拓扑结构，并定义各模块内功能子系统的接口属性[4]。

2 AUTOSAR应用层软件组件开发

应用层软件是由多个相互交互的SWC构成， SWC的设计除了定义自身的类型外，还需定义端口、接口、运行实体及触发运行实体所对应的RTE事件等属性，如图2所示。

图2 组件开发内容

2.1 SWC类型

AUTOSAR按功能属性将SWC划分为应用层、传感器/执行器、标定参数、服务层、ECU抽象层、复杂设备驱动等类型[5]。如图1中的InputOutput组件即为传感器/执行器类型的SWC，而Auxiliary Coordinator等组件则实现了TCU应用层控制策略，即为应用层类型的SWC。以下描述的属性设置都针对应用层SWC。

2.2 SWC属性设置

2.2.1 端口

端口(Port)定义了SWC与外界通信的传输方向以及所承载的接口。根据传输方向，端口分为供型端口(Provide-Port，对外提供某种数据或者某类操作)和需型端口(Receive-Port，请求从其他SWC获得所需数据或者操作)。要实现数据由供型端口传向需型端口，还需对这两个端口指定数据传输的接口类型。如图3所示，设置Motor Control的端口为供型端口，Input/Output的端口为需型端口，两者之间的数据通过这两个端口中的接口实现传输。

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

2.2.2 软件接口

端口只定义了软件组件间通信方向，其中的通信内容及交互方式则由AUTOSAR中定义的接口(Interface)来描述。对于应用层软件，接口有2种：发送者/接收者接口(Sender-Receiver：直接访问数据的n∶n交互方式，文中主要用于应用层各SWC间的交互)；客户端/服务器接口(Client-Server：通过参数调用访问数据的1∶n交互方式，文中主要用于应用层SWC与BSW之间的交互)。如图3所示，Motor Control与Output通过Sender-Receiver接口交互数据；Input/Output通过Client-Server接口与BSW的复杂驱动层(CDD)进行数据交互，复杂驱动层即为服务端。

2.2.3 运行实体

运行实体(Runnables)定义了SWC所需实现的功能函数及其输入输出信号，而TCU的功能函数是由基于Simulink开发的模型来实现。为生成符合AUTOSAR要求的SWC代码，需要将Simulink模型通过dSPACE公司提供的TargetLink工具封装成AUTOSAR架构模型。如图4所示，架构模型的封装包括：模型封装成运行实体，相应的输入输出封装成虚拟BUS，并从SWC的端口中提取所需的信号。此外，运行实体还提供了参数访问端口，通过该端口模型可以访问外部的标定参数。

图4 AUTOSAR架构转换

运行实体的运行是由触发事件来激活的， 为此AUTOSAR定义了多种触发类型，而对于实时性要求比较高的TCU应用层软件，运行实体都选择由周期性时间来触发运行。具体的触发周期需由运行实体的设计要求而定，如图1中的Auxiliary Coordinator的运行周期为5 ms，而控制要求更高的Motor Control，运行周期为2.5 ms。

2.3 组合

按上述方法设计完成的SWC只是独立的个体描述，要想将这些SWC关联起来并通过RTE来实现这些关联，则需将这些描述进行实例化并加载到一个容器里，此容器即称之为组合(Composition)。组合原则上可以有多个，这里只需创建一个即可。

在组合里，包含了SWC和BSW各模块的实例，通过关联实例之间的端口来创建彼此链接关系。需要注意的是，不同接口类型的端口之间不能创建链接，而且只能由Sender指向Receiver，或只能由Client调用Server，反之都无法链接。除了建立内部链接，还需定义外部端口来与外部系统通信，对于TCU，即实现与CAN总线的链接。文中通过dSPACE公司的SystemDesk工具创建了如图5所示组合。

图5 组合的内部连接图

3 RTE配置

前面描述了TCU的系统架构和软件组件，但如何将这些设计映射到具体的ECU中及其代码实现则需要通过配置RTE来完成。

SWC与BSW、SWC之间的交互都是通过RTE提供的虚拟功能总线通信机制(Virtual File System，VFS)来实现的，如图6所示。这样的设计抽象了应用层和基础层，能防止SWC直接访问BSW和OS，有利于监控数据传输并保证数据一致性，而且同时支持简单数据及复杂数据结构以及SWC的多途径应用。

图6 RTE实现的VFS通信机制

配置完成的RTE将自动生成C语言代码，上述的数据交互是通过函数调用的方式实现，而不是传统嵌入式C代码(ERT)中的变量直接赋值形式。两者间的差异如表1所示。

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

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