基于AUTOSAR标准的TCU软件设计
2017-12-18李育
李育
(上海汽车变速器有限公司，上海 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定义的接口函数结构如下：
_ 为端口； RTE还需配置运行实体与操作系统中任务(Tasks)的映射关系以及ECU内部信号与系统信号(CAN信号)的映射关系，这些映射关系也会在RTE代码中实现定义。 作者通过ETAS公司的ISOLAR-A工具完成RTE配置，如图7所示。 图7 RTE配置 将上述设计的配置文件通过TargetLink、RTA-RTE等工具转换为真实的C代码，同时嵌入各组件的功能代码以及BSW的目标代码文件，再通过编译、链接等步骤生成十六进制文件(*.Hex)，最后，将其下载到目标TCU中，并在硬件在环测试平台下进行测试，如图8所示。该硬件在环平台可以通过dSPACE软件仿真整车环境并注入故障，而TCU与电磁阀、传感器等真实负载相连。通过该平台可以真实有效地测试TCU软件系统的接口功能，用以检验基于AUTOSAR标准的TCU软件开发方法应用是否正确，能否达到预期目标。 图8 硬件在环测试平台 软件组件SWC和RTE是AUTOSAR的重要概念之一，因此测试SWC和RTE能否成功在TCU上运行，将是检验软件开发方法的重要标准。 以位置信号为例，该信号的原始值由底层GPIO的频率传感器模块输出，并经由RTE传至应用层的Input软件组件中，再经过信号处理组件处理后输出给Auxiliary Coordinator使用。测试结果如图9所示，采集到的PositionRAW即为通过Rte_Call_Run_IP_RP_IP_Positon(&PositonRAW)接口函数调用到的位置信号原始值，而Position则为经过信号处理(Signal Process)组件之后的值，即通过Rte_IRead_Run_AC_RP_SP_Positon()接口函数读取到的值。显然，测试结果符合预期结果。 图9 拨叉位置信号采集 任务调度测试的主要目的是为了验证AUTOSAR操作系统的基本功能是否正常运行。比如RTE是否成功配置SWC的运行实体与任务的映射链接。测试结果如图10所示，y轴表示任务和运行实体的运行状态。Auxiliary Coordinator和Input都放在5 ms任务下运行，Input首先运行，执行完毕之后进入等待状态，同时激活Auxiliary Coordinator的运行。同样地，放在2.5 ms任务下的Motor Control首先激活，并在运行完毕后激活Output里的Runnable_fast。测试结果显示，TCU软件已经实现了操作系统的基本调度功能。 图10 任务和运行实体的执行过程 基于AUTOSAR标准的软件开发是未来汽车电子嵌入式系统发展的趋势。基于AUTOSAR标准对TCU软件进行模块化设计和实时环境接口配置，可实现应用层软件与底层基础软件的分离，从而便于实现软件的扩展、移植和复用，相对于传统的TCU软件开发模式，将提高TCU的可靠性，并缩短开发周期，提高维护效率。 [1]孙升,宋珂,章桐,等.AUTOSAR标准发展及应用现状[J].机电一体化,2014(12):33-38,44. SUN S,SONG K,ZHANG T,et al.Development and Application Status of AUTOSAR[J].Mechatronics,2014(12):33-38,44. [2]张培锋.参照AUTOSAR的汽油发动机ECU软件设计[D].杭州:浙江大学,2010. [3]王建俊.基于AUTOSAR规范的AMT系统软件开发[D].济南:山东大学,2014. [4]李震,刘敏.基于Autosar的整车电子电气架构设计方法[J].机电一体化,2012,18(11):73-76. LI Z,LIU M.Electric & Electrical Architecture Developing Method Based on Autosar[J].Mechatronics,2012,18(11):73-76. [5]龙荣深.基于AUTOSAR标准的系统配置工具[D].杭州:浙江大学,2010. TCUSoftwareDevelopmentBasedonAUTOSAR LI Yu (Shanghai Automobile Transmission Co.,Ltd., Shanghai 201807,China) A software architecture was proposed for wet dual clutch transmission control unit based on AUTOSAR. The detail designs of the component software and the real-time environment interface were described. The test results show that the application software can work independently upon the hardware, and the tasks of the transmission control unit can be scheduled by the operating system. AUTOSAR； Wet dual clutch transmission control unit； Software design 2017-03-30 李育(1970—)，女，大学本科，高级工程师，研究方向为自动变速器控制系统开发。E-mail：liyu@sagw.com。 10.19466/j.cnki.1674-1986.2017.08.006 U463.6 A 1674-1986(2017)08-026-05
4 测试验证
4.1 RTE接口测试
4.2 RTE任务调度测试
5 结论
