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

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

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

1.1 网络架构定义

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

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

图1 整车SOA网络架构框图

1.2 通讯方式定义

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

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

图2 TMS信号通讯方式图

2.1 硬件架构设计

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

图3 热管理控制系统硬件架构图

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

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

2.2 软件架构设计

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

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

图4 热管理控制系统软件架构分层图

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

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

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

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

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

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

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

图5 空气净化案例开发逻辑图

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

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

参考文献

[1] 刘佳熙,丁峰.面向未来汽车电子电气架构的域控制器平台[J].中国集成电路,2019,28(9):87-92.

[2] 方伟家,张贵海,司华超,等.汽车SOA电子电器架构设计与实践[C]//中国汽车工程学会.2022中国汽车工程学会年会论文集(4).北京:机械工业出版社, 2022:1972-1975.

[3] 栾辉,刘聪.基于面向服务架构的软件开发方法研究[J].北京汽车,2022(2):43-46.

[4] AUTOSAR.Explanation of Adaptive Platform Design: AUTOSAR APR20-11[EB/OL].(2020-11-30)[2024-03- 26].https://download.csdn.net/download/hhfftt/2646994?utm_source=bbsseo.

[5] 高越,高健,周焕宇.基于SOMEIP协议的SOA设计[J].汽车实用技术,2023,48(17):71-75.

[6] 鲁涛.基于SOA面向服务架构的正向开发方法在汽车中的应用研究[J].装备制造技术,2021(12): 147-151.

来源： 汽车电子与软件

 end 

 精品活动推荐 

 专业社群 

部分入群专家来自：

新势力车企：

特斯拉、合众新能源-哪吒、理想、极氪、小米、宾理汽车、极越、零跑汽车、阿维塔汽车、智己汽车、小鹏、岚图汽车、蔚来汽车、吉祥汽车、赛力斯......

外资传统主流车企代表:

大众中国、大众酷翼、奥迪汽车、宝马、福特、戴姆勒-奔驰、通用、保时捷、沃尔沃、现代汽车、日产汽车、捷豹路虎、斯堪尼亚......

内资传统主流车企：

吉利汽车、上汽乘用车、长城汽车、上汽大众、长安汽车、北京汽车、东风汽车、广汽、比亚迪、一汽集团、一汽解放、东风商用、上汽商用......

全球领先一级供应商：

博世、大陆集团、联合汽车电子、安波福、采埃孚、科世达、舍弗勒、霍尼韦尔、大疆、日立、哈曼、华为、百度、联想、联发科、普瑞均胜、德赛西威、蜂巢转向、均联智行、武汉光庭、星纪魅族、中车集团、赢彻科技、潍柴集团、地平线、紫光同芯、字节跳动、......

二级供应商(500+以上)：

Upstream、ETAS、Synopsys、NXP、TUV、上海软件中心、Deloitte、奇安信、为辰信安、云驰未来、信大捷安、信长城、泽鹿安全、纽创信安、复旦微电子、天融信、奇虎360、中汽中心、中国汽研、上海汽检、软安科技、浙江大学......

人员占比

公司类型占比

更多文章

不要错过哦，这可能是汽车网络安全产业最大的专属社区！

关于涉嫌仿冒AutoSec会议品牌的律师声明

一文带你了解智能汽车车载网络通信安全架构

网络安全：TARA方法、工具与案例

汽车数据安全合规重点分析

浅析汽车芯片信息安全之安全启动

域集中式架构的汽车车载通信安全方案探究

系统安全架构之车辆网络安全架构

车联网中的隐私保护问题

智能网联汽车网络安全技术研究

AUTOSAR 信息安全框架和关键技术分析

AUTOSAR 信息安全机制有哪些？

信息安全的底层机制

汽车网络安全

Autosar硬件安全模块HSM的使用

首发!小米雷军两会上就汽车数据安全问题建言：关于构建完善汽车数据安全管理体系的建议