基于SOA架构的热管理系统软件设计

整车热管理系统的发展历程

长久以来传统燃油车都是汽车产业的主角，热管理系统也相对简单，主要包含空调系统和发动机系统的热管理。

空调系统热管理可细分为乘员舱制冷和乘员舱制热。乘员舱制冷是由发动机带动压缩机，通过压缩机、冷凝器、膨胀阀、蒸发器形成的制冷剂回路，将经过蒸发器的空气降温后送入乘员舱，实现乘员舱制冷；乘员舱制热是利用发动机产生的废热加热冷却液后，通过冷却液回路，将经过暖风芯体的空气加热后送入乘员舱，实现乘员舱制热。

发动机系统的热管理主要是发动机的冷却需求，将吸收发动机热量的高温冷却液，经过前端模块散热降温后，循环流回发动机，进而实现发动机的冷却。

伴随汽车产业的发展，尤其是伴随着近年新能源汽车的普及，由此应运而生的纯电车热管理系统与传统燃油车相比发生了很大的变化。纯电车与传统燃油车热管理的差异主要包括以下三点：

1)两者均需要进行空调系统热管理，然而在空调制热的情况下，传统燃油车可以通过发动机的废热给乘员舱供热，而纯电车则必须要进行主动制热。

2)由于两者的动力系统不同，传统燃油车动力系统热管理主要针对发动机模块，而纯电车热管理主要针对电机模块。

3)纯电车相比传统燃油车增加了电池热管理，只有保证电池维持在一定的范围内，才能达到电池的使用寿命、充放电性能、驾驶安全性等的最佳平衡，因此需要对电池进行热管理。

图1-汽车热管理差异

纵观纯电车近十几年的迅猛发展过程，热管理系统大致经历了如下几个阶段：

第一阶段纯电车热管理系统： 采用单独转速可控的电动压缩机，在传统燃油车制冷剂回路的基础上，增加Chiller电池冷却回路。在电池水回路上装配水PTC，通过水PTC加热回路冷却液，进而实现电池的加热。在空调箱内装配空气PTC，通过空气PTC加热送入乘员舱的空气，实现乘员舱的加热。

第二阶段纯电车热管理系统： 与第一代相比系统复杂度明显增大。最主要的特点是将热泵技术应用到乘员舱制热，同时将电池回路、电机回路与制冷剂回路耦合，可实现电机、电池的余热利用。通过热泵技术可将环境中低品位的热量或电机、电池回路中的余热进行利用，在乘员舱制热时制热效率提高，增加冬季纯电车的续航里程。然而，此阶段的热泵系统一般使用制冷剂134a或1234yf，在低温环境下制热量能力衰减严重，无法满足纯电车低温条件下的制热量需求，因此还是需要配置水PTC或空气PTC进行辅助加热。而且，这一阶段的热管理系统，虽然将制冷剂、电机、电池回路系统进行了整合，但各执行器及系统换热器等分布分散，集成度不高，同时存在电机、电池余热未被充分利用的问题点。

第三阶段纯电车热管理系统： 针对上一阶段热管理系统存在的问题，此阶段进行了一系列的热管理系统改进措施。为提高低温制热效率和能力，大众ID4已研发成功将制冷剂由134a/1234yf替代为CO2的热管理系统。在集成化方面，有代表性的特斯拉已将热管理系统在整车上进行了高度化集成，并应用于Model Y车型上，同时此套系统的电机、电池余热利用效率也有了一定程度的提升。

下一阶段纯电车热管理系统： 虽然目前纯电车热管理已经取得了一定的进展与成果，但还是没有达到开发出一套集安全环保、低温高效、空间及轻量化、成本低廉等于一身的理想热管理系统。而且随着对尽量缩短充电时间的客户需求，满足超级快充时的高制冷能力也是热管理系统需要面对的一个挑战。并且，伴随汽车智能化技术的发展，开发适应不同用户需求的热管理功能，必将是未来的大势所趋。换句话说，就是我们要实现将热管理功能服务化，由用户自主选择喜好的功能体现。

接下来在下一章节中介绍这种面向服务开发的软件架构SOA。

面向服务的软件架构 (SOA)

简单了解了热管理系统的发展历程之后，接下来我们一起认识下什么是SOA。

自从进入智能汽车时代，软件定义汽车已被业内人事广接受。汽车产业也正在由电子时代向软件时代转变。软件已逐渐成为智能汽车差异化的核心。为了满足快速的软件和功能的开发，面向服务的软件架构（SOA）开始被业界所认可。

在SOA 架构下，所有的服务组件接口均被标准化，软件的部署不再依赖特定的硬件平台、操作系统等，其松耦合、灵活易于拓展的特点真正意义上实现了汽车的“软硬分离”。SOA能将车端不同功能及硬件能力划分为服务，并按整车的原子能力将服务拆分为颗粒度更小的接口。各服务组件的接口进行标准化封装，可通过既定协议互相访问、拓展组合；SOA的核心要素包括松耦合、标准化定义、软件复用等。SOA使应用层功能可在不同车型上复用，且能够基于标准化接口快速响应用户新的功能需求，软件工程师在修改或新增某一软件功能时，只需对上层相对应的服务组件进行代码编写，而无需进行基础软件层、运行环境层和其他软件组件的重新编译和重复开发，这极大地减少了软件升级的复杂度和成本，提高了效率。正因如此，SOA正成为软件定义汽车的软件趋势。

图2-SOA设计架构

目前众多主机厂及供应商都介入SOA软件开发，预计未来5年将迎来SOA的量产高峰。

汽车SOA是对整车智能化的底层能力进行组织。将车端的硬件能力和各种功能SOA化，划分为不同的服务，拆分成颗粒度更小的接口。这些服务根据SOA标准进行接口设计，基于SOA标准协议进行通信。这样，各服务组件之间就可以相互访问，从而扩展了服务的组合形式。为汽车出厂后的持续升级和服务降低难度、拓展出更多的可能性。

热管理与SOA的碰撞

SOA最早被使用于整车智驾及座舱，国内多家OEM已对其有所探索。而随着技术的不断发展，整车其他软件也势必需要顺应大势来满足SOA架构。

而当前阶段的热管理软件开发多依托于传统燃油汽车发展而来，大多数OEM热管理软件现阶段只满足Classic Autosar，甚至部分OEM热管理软件都不足以满足Classic Autosar架构。那么对于SOA架构，我们应该做什么？怎么做？

图3-不同软件格式差异

首先，需要明确的一点， Autosar软件架构和SOA软件架构并不是冲突的。 笔者认为，Autosar架构更多的是一种规范，统一了软件接口、交换格式、方法论标准。其中Auotsar所实现软硬件分离也正是SOA架构所需要的。但Autosar是一种面向信号的软件架构，而SOA是一种面向服务的软件架构。这也表明SOA更侧重一种架构策略层面的指导思想。可以理解成SOA在AUTOSAR的基础上对ASW进一步分层，以便实现更大的解耦。所以，如果现有热管理软件暂不满足Classic Autosar架构，需现对其进行改造以满足Classic Autosar架构。然后再进行以下转换。

其次，笔者认为为满足SOA，热管理软件需要实现以下两部分。

1)暴露能力

SOA的本质是由信号导向转变为服务导向。SOA软件既然需要面向服务，首先就需要暴露自己的能力以供其他服务调用。而热管理软件做为一个为空调及三电系统服务的软件模块，所以热管理软件的服务接口大部分面向于空调及三电系统。正是基于以上情况笔者建议将热管理软件大部分逻辑算法布置于SOA软件架构的基础服务层。

而鉴于热管理系统涉及到多部件控制策略的强耦合，所以热管理软件只有传感器和执行器可以置于元服务层释放服务接口以供诊断及后市场使用。即需要将热管理软件中传感器、执行器信号转换及硬件诊断部分从热管理主体软件中拆分出来。

注：因热管理系统强耦合性，执行器强制驱动需要考虑系统安全性，所以该部分服务接口笔者不建议直接释放。需添加算法并对其进行保护。

2)信号转换为服务

SOA的本质是由信号导向转变为服务导向。整车传统软件开发，模块交互通过信号的形式进行交互。为实现SOA的转变，模块间交互要变更为服务导向。好在AUTOSAR支持SOME-IP，能够实现交互形式的切换。

结语

最后总结一下基于SOA架构的热管理软件设计对热管理软件开发的影响：

1)可按需定制

现有软件开发多是基于开发人员的经验及车型定位进行设计。但是，毕竟千人千面。基于SOA 平台，开发者可以自由开发出海量的服务和应用，通过测试验证后上架；用户可以自由订阅服务，实现用车千人千面。由此热管理在实现SOA后也可通过把决策权释放给用户从而实现个性定制。例如，A更看中电池的安全，所以A选择电池热管理优先。B更在乎用车舒适性，所以B把乘客舱热管理优先级拉满。C在乎加速的畅快感，所以C更在乎电机时刻准备好以便下一秒动力的全力输出。

2)可实现软件快速迭代

基于SOA架构，我们可以提升软件迭代速度。新的功能开发可以不影响或尽可能少的影响已有软件。以后软件迭代将更多的以功能增加包的形式释放。

而且也将类似手机一样，吸引更多的软件开发人员依托于已释放的API接口进行二次开发。届时一定会有很多有趣的APP会开发出来。但是，各大OEM也要注意相关API接口的管理，加强信息安全及功能安全建设，以免被不法分子恶意使用。