智协慧同鲍鹏：车云计算与数据库技术在域控制器上的量产实践

8月26日，由盖世汽车主办的“2021行业首届智能汽车域控制器创新峰会”于上海汽车城瑞立酒店隆重召开。本次会议持续两天，将围绕智能汽车、智能驾驶域控制器、智能座舱域控制器、底盘及车身域控制器、智能驾驶计算平台、电子电器架构、软件定义汽车、车规芯片等行业焦点话题展开。会议期间，智协慧同联合创始人兼CEO鲍鹏发表了《车云计算与数据库技术在域控制器上的量产实践》的主题演讲。

以下为演讲实录：

大家好，非常感谢主办方提供这次机会跟大家分享一下智协慧同的实践。我们是一个小的创业公司，我们的产品是比较聚焦的，基本上是围绕着数据驱动为主机厂提供高性能的车载数据库，提供一套跨车云的计算框架和一套低代码的开发工具，当然这个数据指的就是车内的信号数据。

简单介绍一下公司，我们是2015年成立于北京，团队在硅谷、上海、长春都有分支，我们核心团队来自于IBM、Teradata、博世。我们的产品已经拿到了好几个量产的定点，比如说在客户量产车型上面的整车域控制器、中央计算域控制器、车身域控制器都有过配套，第一个量产车型今年已经SOP了。

前段时间行业里关于灵魂和躯体争辩的段子很流行，其实有另外一个段子前两天在我的朋友圈里面也很盛行，就是广大的程序员们被国家劳动社保部划为新一代农民工行列，我觉得国家的洞察力还是挺准的。打个比方吧，把种麦子、种苹果当作写个软件的话，那硬件是什么？硬件那就是土地，如果没有土地的话是种不到的。

在第一代和第二代硬件环境里面，“农民工们”，也即写软件的同事们已经是很高的效率去写了，说白了种地播种机收割机全自动，甚至种出麦子以后有非常多可能性做面条做面包，甚至做用户。就好比我们现在用手机下个APP就可以聊天了，它已经是非常高维封装了，这些都是效率工具。

这些效率工具最早第一代IBM、Teradata、ORACLE这些公司在做，第二代是谷歌、facebook、亚马逊，他们最早都是第一代公司的客户，但是突然有一天发现你的技术已经满足不了我了，再往后我做到很高的高点以后再给大家用，不小心就把IBM、ORACLE的命就革掉了，这是之前一个小段子的历史。

2017年我们又突然非常地兴奋，因为当时有一个大的辩论就是域控制器，当时我们看到早期的先行者，很坚定的在看不清楚这些计算成本的情况下，依然把这些大的MPU和存储放在零部件上，当时给了我们巨大的信心，再往下一想，第三代算力网的机会来了。

因为每一代新的算力网，是数字化对人类社会一波一波的侵蚀和深入，这种侵蚀和深入本质上是很难得的机会。比如说在云端没有任何原创机会了，所有基础软件几乎都是美国人写的，只有新的计算网出现才有机会。为什么呢？软件是非常残酷的，现在来看技术更迭的速度会越来越快，当然这里面一个很核心的本质是数据，为什么今天互联网公司都认为数据是最核心的资产呢？因为用海量的数据洞察超过你用经验积累的洞察。

计算架构永远受算力、通讯、存储这些方面的影响。我们很早就意识到在汽车算力网上这些东西优先级会发生变化。很多人认为车上有了计算机架构以后，我把云上的放在车上就可以用了，在我们来看不是这样的。

举个例子，我们当时为什么立刻想到要在车上做一个数据库？因为在云端数据的存储是优先级最低的，没有人关心硬件的寿命，硬件成本是极低的。但是回到今天的车上，Tesla的Model S，当时在2018年的时候黑屏，是写说明到期了，直接不到五年时间就把闪存写寿命直接写坏了。我们知道在汽车行业闪存写的寿命要求是十年。

在2017年我们就把今天看到的很多产品想明白了，然后就开始做，当时我们做这个东西的时候，对外讲可能很多人听不懂，车上为什么需要这个东西？现在回头看，我们是非常幸运的，因为大部分人最后你看到的东西都不会那么快出现，你基本上都会成为先烈。我们现在看可能当初预估保守了，今天车上算力增加的趋势是非常迅猛的，我们就非常有机会和早期客户建立一些关系。包括今天在尝试SOA的头部几家车企都跟我们合作。在合作过程中我们自己也慢慢总结，我们看到了未来面临的挑战。

第一个是研发周期缩短，在2012年，我当年曾经支持过手机行业，从一个传统的开发方式往敏捷方式转型，包括华为、OPPO都是我们的客户。当时手机行业是很关键的节点，因为当时手机研制周期从30多个月往12个月压缩的时候，比如说朗讯当时全球市场占领百分之十几的时候突然缴械了，为什么呢？你花30个月做功能机的时候，人家12个月做智能机，你完全就被淘汰了，本质上这个淘汰赛是你要把进化效率提高。

第二个是软件复杂度增加，现在新架构的车一旦做整车软件集成，你会发现上面大量新的软件技术栈，包括供应商的软件全部放在一起，这些东西合在一起还要建立大量新的功能，这些新的功能还要迭代，这就带来巨大复杂度的软件提升。管理复杂度在IT行业都有很丰富的经验，就是一层一层地封装，第二个是低代码，其实低代码，包括封装，就是今天我们做SOA很重要的原因。

在我们看来，车里面算力就分两块，一个是为人服务，一个是为车服务。为车服务将来迟早会走向软硬一体的路线，我们追求的是软硬分离的路线，基本上这种架构思考是对算力渴求是永远无止境的，意味着有大量新的需求将来要满足，在这个情况下，你要让更多的人在你平台上去做开发，所以这块有些基础的能力和过去基础的问题面临着挑战，这也是我们帮助客户在做的事情。

本质上围绕着数据驱动，我们帮助OEM利用数据的核心能力。到底数据驱动能干什么事？在我们来看，数字化面临着好几个维度，包括深度、广度，比如说设计从研发阶段到量产到数据阶段都可以串起来，包括To B和To C。举例来说，今天我们在跟早期客户做智能空调的算法，过去的空调控制器基本上是简单的公式，不会根据地域和天气来改变，今天有没有可能空调的出风策略和模式，风速可以根据地域不同，根据天气不同、季节不同有些多车的学习，可以有一些变化，将来可以持续学习每一个人的喜好，每个人的空调策略可能都不一样，这个想法怎么在量产车上去做，今天我们已经支持客户在做这样的尝试了。

其实我们自己总结了一下，我们把数据驱动的成熟度列了L1到L4，很多人讲数据驱动，眼睛一下子看到L4，其实回溯的时候会发现需要一步一步来，从数据获取能力开始，能不能给今天业务部门最短的路径就是研发，给他们高精度、高质量的、灵活的获得数据的能力，有了这些数据以后能不能不止做一些报告。再往后就是千人千面怎么去做，能不能把数据跟现在做的研发工作形成闭环迭代起来。今天我已经帮助早期客户在做从L1、L2、L3阶段的事情，L4是正在做。

早期我们跟客户去讲总是讲非常抽象的技术，你为什么需要这样的架构？你为什么需要高性能的数据库？当然我们现在给早期客户做了一些事情以后，我们发现了一些还值得讲的东西，这是其中一个，这个也是我们认为当下大部分主机厂做不到的地方。

今天我们把这个作为一个场景跟大家做一个详细的介绍，这里提出一个概念就是数据到桌面，如何提高你的研发效率？

你在一个新架构车上会发现整车软件集成的时候会面临着很多偶发性的故障，过去传统车上做完零部件和整车的HAL不会有太大的BUG，但今天不是了，今天BUG深度和维度会远超你所想，这些BUG隐藏特别深、特别复杂的时候，你会发现在这块的效率反而变得很慢。

怎么办？我们提出了一个口号叫数据到桌面，我们能不能像过去在家里面不用跟着车，不用拿着盒子去采数据就可以把数据拿回来，碰到偶发故障的时候能够把排故的思路前置到车里面，把分析结果直接带回来，我在家里面就可以做后续的分析，这个对数据有依赖，今天所有主机厂都花了很多成本采了很多数据，但是这些数据今天大部分都在那里闲置着，因为精度不够，维度也不够，工程师需要的大量内部信号都上不来，就在这样的情况下已经花了很大很大的成本，车联网每年光传这些数据、存这些数据、处理这些数据就花了很大的成本，反而出的报告就放在那里了，形不成真正的驱动。我们今天帮助客户在量产车上真正实现了数据到桌面这个事情。

我们车端的数据库支持毫秒级、上万个维度同时记录，在量产车上帮助我们的客户实现10毫秒、近5000个信号的上传。4个月当时罗列的信号是800个，就在这三四个月里面，他们发现数据到桌面能力以后，这个信号往外输出的范围在持续地增加。另外我们解决了一个巨大的成本和效率的问题，因为我们的数据库今天帮助主机厂建立了一套基于高清数据采集的方案，这个架构性方案现在准备向全行业开放，我们在客户那里基本上做完估算比过去车联网节省85%，包括传输成本、计算成本、存储成本。如果你把信号再增加到5000、10毫秒级别，那会省的更多。举个例子，我们传同样的数据，传10毫秒比今天车联网技术传1秒，我们比它的包还要小。本质上我们做到了今天在量产车上高精度、高质量以及具有灵活性的数据采集。

再讲一讲干这个事情中间碰到的一些坑。

第一个是灵活性。一套低代码环境支持业务人员自主建模，而且这种模型可以跨云端和车端部署，包括往车上下发的时候可以自动做一些转换。灵活的配置，过去三个月找数字化部门获得数据，今天当天自己就可以看到一些数据。

车一旦SOP之后可以建立一套灵活数采，比如说空调，我们有一个客户尝试空调功能改变的时候一天可以迭代10次，这在过去是非常难想象的。

第二个是高压缩。本质上高压缩是用我们数据库实现的，其实在中间最难的不是数据库，这个数据库跟域控制器做整合的时候其实碰到了大量的坑。两个控制器加在一块近5000个，10毫秒接入，对于整车到AUTOSAR协议栈都有巨大的压力，相当于给整车做了巨大的压力测试，测试完以后发现大量的问题，这就逼着控制器供应商改善，甚至是逼着协议栈德国那家供应商改他们的BUG。好处是经历这个以后，可以接入这个性能的时候，整个系统健壮性就很厉害了。

因为这个链路很长，还会出现很奇葩的情况，比如说全局的时钟同步，经常在10毫秒左右间隙里面会发生信号乱序，如果解决不了，数据记录下来就是有质量问题的，那我们的数据库里面有机制可以自动纠正它，本质上进了数据库以后就可以把数据以非常好的顺序记下来。

同时我们的数据库是内存加落盘的数据库，你可以完全不落盘，也可以选择性落盘。另外我们还有极高的压缩率，数据接入到内存就开始压，而且这种压缩率是动态压缩，如果采集的频率越高信号规模越大，本质上压缩率会越高。

VSW是我们数据库自己的数据格式，这个数据格式支持全链路不用解压缩，从车端数据库开始往外发数据，可以根据操作系统的其他约束条件自动切包，在小的包上往后台去传，在后台会核包。因为车联网是不稳定的，一定会乱序，那我们这些包里面都自带着校验，主机厂开发灵活的补传策略，最后在云端通过SDK获得完整高质量的数据，一直到落盘，整个过程都是在高压缩的二进制文件上去做的。

我们这个文件格式是自带VIN触发ID和时间戳，本质上存和算分离，这些压缩文件在用的时候随用随解，而且解的时候不用跟DBS做对应，我们是带自解析的。现在有好几个客户都在跟我们合作这个事情，节省成本的效率是巨大的，包括有些新势力的车单台车每年数据传输和存储成本是上千块钱，还是很吓人的，这块能给他们节省很多钱。

我们在云端多很多开放SDK，用我们的数据库，SDK、包括新的架构都会给到我们的客户。有能力的客户可以只买我们的中间件，在车端和云端完全自己开发，有的客户希望交钥匙工程，我们也会有现成的产品直接提供给它。

这个功能研制周期4个月，我们4个月在量产车上实现了高精灵活数采功能上线，为什么这么快？因为在车上提前预置了边缘计算框架和计算能力。

最后总结一下，我们有一个低代码算法开发工具，我们有一套跨车云的计算框架，用的代码工具写的所有算法会在VAnalyze和vCloud去跑。基于这些能力，主机厂可以开发数据驱动最基本的能力，比如说高精高质量灵活数采，在这之上我们给到了业务人员直接用低代码工具探索数据的能力，在这个基础之上可以做创新性数据驱动的算法开发，本质上它连接的就是千人千面的落地。

这就是我们产品简短的介绍。在早期两个项目里面我们经历了非常痛苦的跟硬件供应商集成的合作，我们也非常乐意跟更多的做控制器的供应商做深度合作，提前把一些技术栈打包，共同为客户服务，谢谢。