电动汽车不断内卷天际汽车如何破局？( 二 )

　　所以将来在产业链上的分化将会呈现主机厂越来越多的强调掌握接口，去差异化，与为用户创造价值，对于供应商而言，可能是更多的强调制造标准的接口，达到标准和可靠。
　　控制功能承载的主体往云端拓展
　　天际汽车现在车上都配备T-box，有自己的企标上传规则和服务器，把一些数据存下来，行业很多乘用车企业也是这么做的。
　　天际汽车计划在云端为每辆车建档，以每辆汽车的VIN码为标识。给每辆车分配每个控制器的数据储存单元。数据存储器里面存三类数据，第一类是周期性的重要数据，第二类是特定事件发生时的捕捉数据，此外还有第三类通过车载控制器进行边缘计算提炼出的关键特征数据。
　　有了数据之后，就是计算部分。基于云端数据进行计算，可以抽象驾驶员的驾驶风格，电池的健康状态等，之后甚至可以去下发标定，把当前控制器里的标定值进行修改，并且把变更存档在云端。从行业技术状态而言，目前各个环节的基础技术栈都已经具备，只需要进行贯通就可以实现。
　　天际汽车希望做到目标是出厂时有一致性标定，在每次运行的时候，有云端的信息过来就按照云端的信息进行调整，没有云端的信息过来它就是原来车上的控制器，只有把车上和云上结合到一起，才是一个完整的控制系统。每辆车随着使用，会调整一些特征的特性，最后实现一车一标定的概念。
　　SOA面向服务的架构
　　目前汽车行业内大部分还是非面向服务架构，控制系统里面在进行一个项目之前，要把开头给定义好，任何一方改一个信号，要涉及到多方去改矩阵，牵一发而动全身。现在倡导的SOA其实是一种不同的的开发思路，用规范的接口、标准的服务来定义控制器，方便灵活的变化升级。
　　虽然一直相提并论，但实际SOA的思路与现在以太网、DDS等概念没有必然的联系。传统汽车上最典型的面向服务思路就是OBD的车载诊断。只要满足14229的标准，用任何一款诊断仪插上OBD，就可以读它的故障信息或进行其它一些操作。这就是一种典型的面向服务的架构，所以面向服务并不是以太网的专利，在汽车行业一直就有，只不过现在随着以太网的兴起，将这个事情实现的便利性和它的可用性大大加强了。
　　将来对于控制软件的发展趋势：
　　第一是标准化，随着越来越多的开发，就像诊断协议一样，对于一些应用层要用的信号的命名、函数原语、调用方式都会有组织调出来形成标准化，尽量实现不同企业之间的标准化应用。
　　第二个是信号在车里会有多源。例如车速当下基本都从ESP这个控制器拿，将来车上SOA的话，电机转速可以换算一个车速，ESP可以根据轮速算一个，有卫星和导航的话，导航还可以算一个车速。当然这几个车速信号精度和刷新频率等是不一样的，但是如果作为一个控制功能的开发者而言，只要信号服务质量即QoS满足功能要求，其实从哪里来并不重要。
　　第三是功能的原子化，这是软件开发的常用定义，就是高内聚、低耦合，每个软件功能单元把自己包的越来越严实，越来越是独立的功能块，而尽可能减少相互之间的耦合关系。
　　最后第四就是分级分域，按照不同的层级、不同的权限、不同的时效，对车内所有服务化的信号流和调用关系做管控。
　　当SOA发展到一定程度后，车可能就是下一个智能终端实体。举个例子，将来车内可能会有这样一个APP，它获取了读取用户的驾驶习惯这个权限，就像安卓一样；它还可以读取电池的信息，可以获取电池的温度，可以获取驱动水泵和一定范围内PTC加热的权限。它就是一个独立的功能模块，甚至可以把它放到车企的应用商店里去下载。只要使用了这个应用，例如在冬天，如果用户上下班只是短途低速行驶，就可以根据实际行驶需求，控制电池的加热温度，而不是始终以一个固定的较高温度目标去加热。这个过程中可以大大的将实际使用能耗降下来，全过程把云、车构成一体，形成完整的闭环系统。

电动汽车不断内卷 天际汽车如何破局？( 二 )

电动汽车不断内卷天际汽车如何破局？( 二 )