车联网云平台建设之路

1、 车联网云平台建设之路本文介绍的主题是车联网云平台之路。钛马是以车联网业务为基础的公司，国内首家汽车 B2B 互联网公司。目前核心业务是车联网，同时也提供互联网营销、新一代 DMS 解决方案等产品。什么是车联网？ 如果我们用百度搜索车联网，一般会搜索到的都是 IOV 这个名词 Internet of Vehicle ，大家似乎认为 IOV 就是车联网。但实际上在上世纪 90 年代，On Star（安吉星）在美国就已经提供了车联网服务，车联网的英文也是在那个时期出现的 Telematics 其实更为准确。所以围绕车联网行业的公司和产品一般都会以 T 开头：车联网服务提供商TSP ；车联网的通讯终

2、端T-Box ；车联网服务T-Service 。随着 09 年丰田 G-book 进入中国市场，中国才慢慢开始有了车联网的概念。之所以前些年发展缓慢，去年才开始逐渐上量，主要是两方面原因，一是前些年消费者的消费观念停留在汽车仅为代步工具，再就是 2G 时代的网络不能带来很好的体验。车内电子设备的类型 车内电子设备主要分为前装和后装两种。在车主买车后，加装或替换车内的电子产品，我们称之为后装。比如智能后视镜、倒车雷达、倒车影像这些都属于后装产品。总体来说，后装产品不属于典型的车联网，应该称之为车载信息娱乐互动，因为这些产品不能跟车辆本身做数据的交互。前装是车辆出厂时就预装的硬件设备，车联网就是最

3、典型的前装产品，车联网的通讯主要是依赖 T-Box 作为核心。T-Box 中有通讯模块连接服务器后台，同时可以连接车辆的 CAN 总线，从而与车辆本身进行交互，除了可实现只读的远程故障诊断等功能，还可以完成可交互操作，如远程开关车门、空调等。除此之外，现在不少车型前装支持的苹果 CarPlay 和百度的 Carlife 等，虽然本质上是前装，但其实更多的也是车载信息娱乐互动，按我的理解不能算是严格意义上的车联网（或者说让汽车上云）。我们为什么需要让汽车上云？ 对于整个汽车产业链来说，车联网是提供所有车主服务的基础设施，并提供基础的控车等车辆交互服务，这些交互本身就能带来很好的体验；除此之外，在

4、之上可以衍生出很多应用和业务，包括 OTA 升级、驾驶行为分析、UBI 保险、乘用车租赁等等。对于所有的车联网服务来说，让汽车上云是基础，之后才能有更多的业务创新和可能。相比来说，如果只让手机、车机这些上云，可拓展的业务就会少很多，只是移动互联网的场景再造。所以，通过让汽车本身上云，才能给车主带来更好的体验，对 B 端也能产生更多的价值。车联网落地云平台的一些挑战 海量数据 车辆运行中的 GPS 信息、车辆和车况信息数据量非常大，一般都储存在非关系型数据库中，对云平台的读写操作、IOV 平台、车企数据的安全性、可靠性都有着很高的要求。网络的复杂性 车联网系统的网络非常复杂，这里以专线为例。一般

5、来说，车联网至少包含 3 种专线：云平台到联通 GGSN 的 APN 私有专线。考虑到安全和稳定性的问题，大部分车联网都是采用物理专线来承载私有 APN 。在 T-Box 上一般又分为私有和公有两个通道，但只有核心的控车数据会走私有通道；车联网振铃用的 E1 线路。对于电瓶耗电和数据信号稳定性问题，唤醒 T-box 一般有短信和振铃两种方式；如果选择振铃的方式，还需要用物理服务器安装语音卡来实现；云平台到车企各个系统的点到点专线。整个汽车产业链是非常庞大的，已有的传统服务如 DMS 、CRM 等都比较成熟，暂时没有上云或只会部分上云，但车联网服务是典型的 To C 业务，对 SLA 和服务窗口

6、要求都比传统服务高的多，同时又需要跟车企内部的系统做频繁的数据交互，所以一般需要点到点专线进行数据传输。因此，仅仅网络角度，就需要在架构上需要做性能规划、线路余冗、路由、安全、QoS 等统一设计。因为车联网系统的复杂性、定制性和灵活性的需求，钛马现在主要使用的是自建的车联网云平台。除了基础的 IaaS 层的 VM ，分布式存储、云数据库等基础 PaaS 服务，还有自主开发的车联网 PaaS 模块，如振铃平台服务、专线管理、运维管理平台和 CMDB 等。车联网项目落地云平台优化思路 总体来说，细分领域的云，技术不是最难的。为了让车联网服务在云上稳定运行，单单提供云是远远不够的。随着项目的增多，暴

7、露出来的问题也会越来越多，这主要是由于用户的快速增长，以及客户的时间压力造成的。在有限的人力下，怎么让各个项目顺利落地到云，团队的组织架构和任务设计也很重要，如下是站在任务导向的组织架构设计角度，经过反复的试错和探索总结的一些经验：不能忽视云产品相关的架构设计工作 云产品落地架构设计是最容易被忽略的，尤其是公有云为主的情况。所以不管是自建云还是公有云，一定要了解所使用的云，从业务数据流向入手，在安全、性能、可扩展性等方面一定要形成体系化的解决方案，而不只是满足于功能实现。系统的运维工作需要横向的产品化输出 针对多个 To-B 项目的运维，为了更快的交付和响应项目需求，系统运维人员往往是独立的，

8、这种情况就会导致运维人员之间的信息严重不同步。在这种情况下，可以找一个重大的项目作为改革标杆，把各项规范，比如自动化脚本，配置和备份规范、日志方案发布流程等规范并转换成标准，再逐步推给各个项目研发。一定要保持运维角度的平台化、产品化思路，当时机成熟时，也可以单独成立团队来做。运维也需要单独项目制管理 在项目前期架构设计阶段，运维就需要参与，将运维最关注的各方面，比如稳定性，安全性和可运维性的要求融入架构设计中。所以需要以项目的形式，将每个运维项目全生命周期单独管理起来，尤其是针对多个 ToB 客户的业务更有必要。对 EGO 的期望 加入 EGO 后收获很多，尤其是在小组里学到了不同行业的知识，甚至各个技术领域还能互相帮助，弥补了自己的很多不足。在 2018 年也希望 EGO 能有更多小组之外的活动，让大家收获更多。Q&A 车联网行业对于移动网络的要求是什么？ 在 2G 和 3G 时代，车联网的使用体验是有一定影响的。但到了 4G 时代，三大运营商的 4G 网络基本都能满足车联网的基础需求。车联网的痛点主要有哪些？ 难点在于整合多个车企的需求并逐渐迭代解决方案。车联网目前还在发展过程中，标配车联网的车辆数量还是很小的比例。目前后装市场基本不可能解决连车的问题，也很难发展成标准化，所以主要更