基于SOA架构的汽车热管理控制系统设计

随着汽车电子软硬件研发技术的不断发展和进步，越来越多的主机厂在其内部车型研发过程中将整车电子电气架构（ElectronicandElectricalArchitecture,EEA）偏向于智能化和数字化开发方向。尤其是软件定义汽车已成为当前各主流车企技术研发的热点，其主要目的是将车辆所提供的用户服务由原来传统的硬件集成方式变革为提供产品生命周期内的软件升级服务，通过汽车各个控制模块的应用层软件迭代更新来实现。

本文将重点介绍一种面向服务化架构（ServiceOrientedArchitecture,SOA），其用于汽车热管理控制系统开发，相比较传统面向信号的软件集成架构，这种新型SOA软硬件架构主要包含两大特点：1）将热管理控制系统中负责各个传感器采样、电机驱动等输入输出功能的控制器进行软硬件解耦，规避后期应用层软件功能升级而影响硬件系统产生变化；2）将原先集成式一体化开发的应用层软件打散，按照各个子功能进行原子化定制服务开发，方便其他控制模块进行调用，大幅度缩减后期热管理功能的软件迭代和更新周期，同时减少因底软造成的重复性测试工作量。

1 整车SOA架构设计

1.1 网络架构定义

奇瑞全新EEA5.0电子电气架构在设计定义开发初期，摒弃传统的控制器局域网（ControllerAreaNetwork,CAN）或内部本地网络（LocalInterconnectNetwork,LIN）通讯交互的方式，直接采用基于SOA的软件分层设计开发的思路，将热管理系统（ThermalManagementSystem,TMS）相关的所有应用层软件上移至整车中央域控制单元（VehicleCenterController,VCC）中集成，方便整车其他模块调用热管理各项服务化子功能[2]。    

整车其他控制模块同样遵循SOA架构设计原则，将其应用层软件打散并同步上移至VCC中，以原子服务形式允许其他节点模块进行访问和调用[3]，面向服务化的SOA网络架构详细构成如图1所示。

1.2 通讯方式定义

整车一级域控制器之间的通讯方式在EEA5.0架构平台上均为以太网Ethernet通讯，车载以太网相比传统CAN/LIN网络通讯，具备众多优点。其中最主要的优势集中在数据传输速度快、数据传输安全和传输可靠这三个方面，重点表现为能够支持主动监控（ActiveIntelligentMonitoring,AIM）和安全传输模型（SafetyTransmitModeling,STM）的抗干扰机制，其最大传输速度可达1000Mbps。

以热管理控制单元为例，整车热管理所有功能都以原子服务化的形式将应用层软件TMS上移至VCC中，汽车其他模块，如中控大屏主机（Inst-rumentCenterController,ICC）等在调用或激活热管理某项功能时，首先通过以太网将需求功能发送至VCC，由VCC底软进行应用程序编程接口（ApplicationProgrammingInterface,API）信号转换，转换后的API信号再经过热管理软件进行功能逻辑处理，最后由VCC转换成CAN信号下发至热管理控制模块（ThermalDriveUnit,TDU）来驱动对应的负载输出，如鼓风机转速、模式风门电机等，详细通讯方式如图2所示。 

2 热管理系统架构设计

2.1 硬件架构设计

按照SOA架构设计的核心理念，本文重点将热管理控制系统的软件和硬件进行分离。热管理控制系统应用层软件上移至VCC中集成，硬件驱动控制下移至TDU中进行采样输入和负载输出，控制系统的硬件整体架构如图3所示。

与传统控制系统中的控制器不同，SOA架构下的TDU作为热管理控制器不再具备热管理应用层功能逻辑，仅支持底层信号采样和负载驱动输出，真正实现应用层上移。TDU在各类子部件输入和输出控制过程中，主要分为LIN通讯控制和PIN输入输出硬脚控制两种类型。    

LIN通讯控制主要针对一些复杂驱动部件，如电动压缩机/无刷鼓风机等。在设计开发过程中，TDU作为LIN通讯主节点，首先将通讯波特率统一定义成19.2kb/s，再通过分配不同的ID地址下发至各从节点子部件，最后对每个子部件释放唯一的LIN通讯协议进行双向开发。

PIN脚硬线控制主要针对一些相对简单的温湿度/阳光采样和直流电机驱动输出。以温度传感器采样为例，本文中车内和车外温度传感器均采用Casco（凯斯库）公司生产的负温度系数热敏电阻，其正常测量范围为-50～100℃，且精度可达±0.1℃，适用于汽车空调标定测试场景。

2.2 软件架构设计

基于行业标准AutoSar架构设计要求，将底层软件（BaseSoftware,BSW）和应用层软件APP集成在一起烧录至控制器EEROM是传统嵌入式软件开发的典型特征。本文所描述的热管理控制系统软件架构最大的特点就是遵循SOA架构的核心理念，将原先集成在控制器内部的应用层软件单独剥离出来，上移至整车VCC域控制单元中，同步开放所有接口信号。

本文设计的热管理控制系统软件架构在分层设计过程中将底层软件相关的复杂驱动（ComplexDeviceDriver,CDD）、I/O（Input/Output）抽象层、通信服务等单元模块连同运行时环境（RunTimeEnvironment,RTE）一起集成至控制器硬件中。而应用层从低到高分为基础原子服务SWC（SoftwareComponent）、组合服务、上层应用功能三个模块一起上移至VCC中，并对整车其他模块开放访问权限。层与层之间进行解耦，各个层级同时可以独立升级版本，降低了各子模块之间的耦合性，有助于实现整体热管理控制系统的高内聚。详细的热管理控制系统软件架构分层如图4所示。  

本文基于SOA架构将热管理应用层软件进行上移，这种开发方案的优势主要表现为以下两方面：

1）能够真正实现将热管理控制系统中各个传感器采样、电机驱动等输入输出功能进行软硬件解耦，规避后期应用层功能升级或底层I/O被控对象硬件升级，对双方造成相互影响和变化。

2）将原先嵌入式一体化开发的应用层软件打散，按照各个输入输出功能进行原子化定制服务开发，方便其他控制模块应用层软件进行调用，大幅度缩减后期热管理控制功能的软件迭代和更新周期，同时减少因底软造成的重复性测试工作。

3 实际案例开发

本文以汽车中控大屏激活车内空气净化功能为例，重点描述基于汽车SOA软件架构下如何实现热管理控制系统的功能应用场景，具体软件功能逻辑实现过程如图5所示。

首先，模拟用户在中控大屏中点击车内空气净化按键，中控大屏主机ICC模块基于整车定义的SOME/IP通讯矩阵将功能激活请求的以太网信号发送至VCC，VCC将接收到的Ethernet空气净化按键信号HMI_Active（eHMI_PM25Adjust_notifyPM25/0xA95C）=0x1（ON）有效值转换为API接口信号传递至热管理应用层软件TMS模型中。    

其次，TMS软件会再将空气净化功能对应的各个组合服务（座舱通风&座舱制冷&座舱采暖）进行分层和优先级排序，按照“高内聚、低耦合、复用性”原则再向下调用“循环控制”和“风量控制”等一系列单元原子服务。详细逻辑过程总结为TMS首先需要进行车内玻璃起雾风险概率计算，在保证在无起雾风险前提下，再调用空调系统内外循环风门指令eHMI_CirculationAdjust_notifyREC，强制驱动空调箱内外循环风门进入内循环状态，并同步激活实时鼓风机转速使能信号eHMI_BlowerSpdLvlFrontAdjust_notifyBlower。

再次，在各原子服务被成功组合和调用之后，

通过VCC实现热管理应用层功能由API接口信号转换成热管理控制模块TDU所能接收的CANFD控制信号。TDU作为终端驱动控制器，最终完成鼓风机风量大小调节和内外循环风门切换控制，让用户实际体验到空气净化功能已被有效激活。

最后，在终端用户进行OTA远程软件升级过程中，针对空气净化这一项场景功能发生软件迭代，就可以直接通过云端将空气净化功能的软件更新要求发送至整车VCC，由VCC重新进行调用和组合热管理应用层软件TMS中的相关原子和组合服务，而不需要再对终端热管理控制模块TDU进行软件刷新或硬件升级。这一方面真正体现了软硬解耦的特点，另一方面也减少了由于硬件或底软更新带来的重复性测试，实现了工作量大幅降低的目标。             

4 结束语

本文设计了一种基于SOA架构的汽车热管理控制系统，将原先传统的嵌入式一体化控制器按照软硬分离的原则，将热管理应用层软件上移至整车域控制单元VCC中集成，并对该应用层软件进行分层和分模块化开发。这样的设计方案将车辆所提供的用户服务由原来传统的硬件集成方式变革为提供产品生命周期内的软件升级服务，真正实现了软件定义汽车的目标。最终通过奇瑞公司某个实际车型项目的开发应用，从实践上证明了面向服务化开发的SOA架构在汽车设计研发过程中，真正具备软件“高内聚、低耦合、复用性”等优点，必将是未来汽车电子电气架构发展的方向和行业趋势。