电动汽车不断内卷，天际汽车如何破局？

日前，天际汽车自主开发了VBU控制器，将VCU和BMS整合到一起，实现软硬件的自主开发应用。这不仅打破了专业技术的壁垒，同时在天际汽车目前上市的ME5增程车和纯电动车上都实现了量产。该系统架构实现了电池管理系统，从硬件上面脱离，不再跟随电池包，而是以VBU为主，变成了置身于电池包外的控制器，赋予了非凡的意义。

在传统控制系统中，不光是动力系统控制，VCU、EMS、MCU、BCM等等控制器都脱不开输入，中间逻辑处理，最后是输出的框架。输入典型包括数字量、模拟量采集、通讯输入；输出典型包括低边、高边驱动，以及通讯总线的输出。将来会不会存在一种专用于传感执行的控制卫星板的概念，卫星板可能分会为A/B/C型，每一型会根据最优配置的原则，在不浪费的情况下配置一些广泛使用的、特定数量的接口，具有一定的驱动能力，以及通讯的能力。基于该前提，就把逻辑算法，更多上提，提到核心板（高算力的SOC做异构的芯片）。

在这种划分下，电子电气构架上面中心控制器将更贴近于用户感知功能，卫星板则更多和硬件被控对象，如电池包、电机、OBC、DC等结合。

天际汽车认为将来对于车载的控制系统硬件技术趋势而言，从低速总线通讯会越来越多的向高速总线过渡，另外会从有线向无线过渡。硬件上会越来越多融合消费电子和工业领域的WIFI、4G、高速串行技术。

车辆控制功能融合和重新组织

过去燃油车没有VCU，所有都集成在EMS中，所有驾驶中的扭矩、油门、制动、档位，都通过EMS完成。发动机被电机替代后，增加了电池需要进行充放电模式及上下电过程的管理，以上功能需要一个控制器去实现，而VCU承担了这些功能。同时，电动车的的能量和功率协调也需要控制器进行计算，再叠加信息处理、安全监控系统等内容，最后就集成为VCU控制器。

而现在反过来想，例如VCU的纵向控制功能，是在驾驶员需求扭矩解析的基础上，对电驱动系统发控制指令实现。无论从VCU发出，还是从其它控制器发出，从单纯的纵向控制需求而言，完全可能被其它控制器取代，只需把驾驶员及其它纵向扭矩的的输入信息获取和解析。再如，热管理系统在电动车上更加复杂，乘员的空调舒适温度与关键部件的适宜温度诉求应相互协调而来，相关的泵、阀、风扇、压缩机、加热器等部件管理也具备与电池管理系统或其它控制器融合的可能性，而不需要绑定在VCU上。而像充放电模式、上下电过程等协调，本来就是跟着电池而来，自然是可以聚焦于电池管理的控制器上。VCU剩下的信息处理、安全监控、诊断系统，其实是每个控制器都需要，可以算平台功能。因此大胆预测，未来VCU控制器作为独立控制器存在的意义不大。

目前天际汽车将VCU和BMS两个控制器进行融合。对于电动车而言快充、慢充、放电、远程唤醒这几个模式本就是一体的，结合也显得非常自然。总而言之，将两个控制器相结合，能够创造出很多便利性，将原来大量需要通过交互和沟通的过程，变成控制器内部变量的传递，对整个提高系统的控制效率起到了极大的帮助。

随着车辆控制功能融合和重新组织，主机厂和供应商之间的关系将被重新定义。过去主机厂是找许多零部件厂商攒一个功能，基本上各个零部件会倾向于去用自身平台功能，不愿意修改，所以主机厂就要居中协调几家的厂商来合起来实现功能，过程非常的冗长和复杂，并且更改的自由度小，基本上基于现有的平台做小的调整。在域控制器模式下底层软硬件开发对于各个ECU之间的功能，提出更加精准有针对性的需求。

所以将来在产业链上的分化将会呈现主机厂越来越多的强调掌握接口，去差异化，与为用户创造价值，对于供应商而言，可能是更多的强调制造标准的接口，达到标准和可靠。

控制功能承载的主体往云端拓展

天际汽车现在车上都配备T-box，有自己的企标上传规则和服务器，把一些数据存下来，行业很多乘用车企业也是这么做的。

天际汽车计划在云端为每辆车建档，以每辆汽车的VIN码为标识。给每辆车分配每个控制器的数据储存单元。数据存储器里面存三类数据，第一类是周期性的重要数据，第二类是特定事件发生时的捕捉数据，此外还有第三类通过车载控制器进行边缘计算提炼出的关键特征数据。

有了数据之后，就是计算部分。基于云端数据进行计算，可以抽象驾驶员的驾驶风格，电池的健康状态等，之后甚至可以去下发标定，把当前控制器里的标定值进行修改，并且把变更存档在云端。从行业技术状态而言，目前各个环节的基础技术栈都已经具备，只需要进行贯通就可以实现。

天际汽车希望做到目标是出厂时有一致性标定，在每次运行的时候，有云端的信息过来就按照云端的信息进行调整，没有云端的信息过来它就是原来车上的控制器，只有把车上和云上结合到一起，才是一个完整的控制系统。每辆车随着使用，会调整一些特征的特性，最后实现一车一标定的概念。

SOA面向服务的架构

目前汽车行业内大部分还是非面向服务架构，控制系统里面在进行一个项目之前，要把开头给定义好，任何一方改一个信号，要涉及到多方去改矩阵，牵一发而动全身。现在倡导的SOA其实是一种不同的的开发思路，用规范的接口、标准的服务来定义控制器，方便灵活的变化升级。

虽然一直相提并论，但实际SOA的思路与现在以太网、DDS等概念没有必然的联系。传统汽车上最典型的面向服务思路就是OBD的车载诊断。只要满足14229的标准，用任何一款诊断仪插上OBD，就可以读它的故障信息或进行其它一些操作。这就是一种典型的面向服务的架构，所以面向服务并不是以太网的专利，在汽车行业一直就有，只不过现在随着以太网的兴起，将这个事情实现的便利性和它的可用性大大加强了。

将来对于控制软件的发展趋势：

第一是标准化，随着越来越多的开发，就像诊断协议一样，对于一些应用层要用的信号的命名、函数原语、调用方式都会有组织调出来形成标准化，尽量实现不同企业之间的标准化应用。

第二个是信号在车里会有多源。例如车速当下基本都从ESP这个控制器拿，将来车上SOA的话，电机转速可以换算一个车速，ESP可以根据轮速算一个，有卫星和导航的话，导航还可以算一个车速。当然这几个车速信号精度和刷新频率等是不一样的，但是如果作为一个控制功能的开发者而言，只要信号服务质量即QoS满足功能要求，其实从哪里来并不重要。

第三是功能的原子化，这是软件开发的常用定义，就是高内聚、低耦合，每个软件功能单元把自己包的越来越严实，越来越是独立的功能块，而尽可能减少相互之间的耦合关系。

最后第四就是分级分域，按照不同的层级、不同的权限、不同的时效，对车内所有服务化的信号流和调用关系做管控。

当SOA发展到一定程度后，车可能就是下一个智能终端实体。举个例子，将来车内可能会有这样一个APP，它获取了读取用户的驾驶习惯这个权限，就像安卓一样；它还可以读取电池的信息，可以获取电池的温度，可以获取驱动水泵和一定范围内PTC加热的权限。它就是一个独立的功能模块，甚至可以把它放到车企的应用商店里去下载。只要使用了这个应用，例如在冬天，如果用户上下班只是短途低速行驶，就可以根据实际行驶需求，控制电池的加热温度，而不是始终以一个固定的较高温度目标去加热。这个过程中可以大大的将实际使用能耗降下来，全过程把云、车构成一体，形成完整的闭环系统。