钛马信息云技术中心总监姚振：汽车为什么要上云 —— 车联网云平台之路
2017 年 12 月 25 日，EGO 北京分会会员、钛马信息云技术中心总监姚振作为 EGO 线上分享第四季的嘉宾，以直播的形式分享了车联网云平台之路。本文根据当天直播内容整理。
大家好，我是钛马信息云技术中心总监姚振，同时也是 EGO 北京分会第 14 组的组长，今天分享的主题是车联网云平台之路。我在 2008 年之前一直在系统集成商做网络项目，后来做运维管理，现在在钛马负责云平台建设、开发、以及运维管理。
钛马是以车联网业务为基础的公司，国内首家汽车 B2B 互联网公司。目前核心业务是车联网，同时也提供互联网营销、新一代 DMS 解决方案等产品。
如果我们用百度搜索车联网，一般会搜索到的都是 IOV 这个名词 —— Internet of Vehicle ，大家似乎认为 IOV 就是车联网。但实际上在上世纪 90 年代，On Star（安吉星）在美国就已经提供了车联网服务，车联网的英文也是在那个时期出现的 —— Telematics 其实更为准确。所以围绕车联网行业的公司和产品一般都会以 T 开头：
车联网服务提供商——TSP ；
车联网的通讯终端——T-Box ；
车联网服务——T-Service 。
随着 09 年丰田 G-book 进入中国市场，中国才慢慢开始有了车联网的概念。之所以前些年发展缓慢，去年才开始逐渐上量，主要是两方面原因，一是前些年消费者的消费观念停留在汽车仅为代步工具，再就是 2G 时代的网络不能带来很好的体验。
车内电子设备主要分为前装和后装两种。
在车主买车后，加装或替换车内的电子产品，我们称之为后装。比如智能后视镜、倒车雷达、倒车影像这些都属于后装产品。总体来说，后装产品不属于典型的车联网，应该称之为车载信息娱乐互动，因为这些产品不能跟车辆本身做数据的交互。
前装是车辆出厂时就预装的硬件设备，车联网就是最典型的前装产品，车联网的通讯主要是依赖 T-Box 作为核心。
T-Box 中有通讯模块连接服务器后台，同时可以连接车辆的 CAN 总线，从而与车辆本身进行交互，除了可实现只读的远程故障诊断等功能，还可以完成可交互操作，如远程开关车门、空调等。
除此之外，现在不少车型前装支持的苹果 CarPlay 和百度的 Carlife 等，虽然本质上是前装，但其实更多的也是车载信息娱乐互动，按我的理解不能算是严格意义上的车联网（或者说让汽车上云）。
对于整个汽车产业链来说，车联网是提供所有车主服务的基础设施，并提供基础的控车等车辆交互服务，这些交互本身就能带来很好的体验；除此之外，在之上可以衍生出很多应用和业务，包括 OTA 升级、驾驶行为分析、UBI 保险、乘用车租赁等等。
对于所有的车联网服务来说，让汽车上云是基础，之后才能有更多的业务创新和可能。
相比来说，如果只让手机、车机这些上云，可拓展的业务就会少很多，只是移动互联网的场景再造。所以，通过让汽车本身上云，才能给车主带来更好的体验，对 B 端也能产生更多的价值。
车辆运行中的 GPS 信息、车辆和车况信息数据量非常大，一般都储存在非关系型数据库中，对云平台的读写操作、IOV 平台、车企数据的安全性、可靠性都有着很高的要求。
车联网系统的网络非常复杂，这里以专线为例。一般来说，车联网至少包含 3 种专线：
云平台到联通 GGSN 的 APN 私有专线。考虑到安全和稳定性的问题，大部分车联网都是采用物理专线来承载私有 APN 。在 T-Box 上一般又分为私有和公有两个通道，但只有核心的控车数据会走私有通道；
车联网振铃用的 E1 线路。对于电瓶耗电和数据信号稳定性问题，唤醒 T-box 一般有短信和振铃两种方式；如果选择振铃的方式，还需要用物理服务器安装语音卡来实现；
云平台到车企各个系统的点到点专线。整个汽车产业链是非常庞大的，已有的传统服务如 DMS 、CRM 等都比较成熟，暂时没有上云或只会部分上云，但车联网服务是典型的 To C 业务，对 SLA 和服务窗口要求都比传统服务高的多，同时又需要跟车企内部的系统做频繁的数据交互，所以一般需要点到点专线进行数据传输。因此，仅仅网络角度，就需要在架构上需要做性能规划、线路余冗、路由、安全、QoS 等统一设计。
因为车联网系统的复杂性、定制性和灵活性的需求，钛马现在主要使用的是自建的车联网云平台。除了基础的 IaaS 层的 VM ，分布式存储、云数据库等基础 PaaS 服务，还有自主开发的车联网 PaaS 模块，如振铃平台服务、专线管理、运维管理平台和 CMDB 等。
总体来说，细分领域的云，技术不是最难的。为了让车联网服务在云上稳定运行，单单提供云是远远不够的。随着项目的增多，暴露出来的问题也会越来越多，这主要是由于用户的快速增长，以及客户的时间压力造成的。
在有限的人力下，怎么让各个项目顺利落地到云，团队的组织架构和任务设计也很重要，如下是站在任务导向的组织架构设计角度，经过反复的试错和探索总结的一些经验：
云产品落地架构设计是最容易被忽略的，尤其是公有云为主的情况。所以不管是自建云还是公有云，一定要了解所使用的云，从业务数据流向入手，在安全、性能、可扩展性等方面一定要形成体系化的解决方案，而不只是满足于功能实现。
针对多个 To-B 项目的运维，为了更快的交付和响应项目需求，系统运维人员往往是独立的，这种情况就会导致运维人员之间的信息严重不同步。
在这种情况下，可以找一个重大的项目作为改革标杆，把各项规范，比如自动化脚本，配置和备份规范、日志方案发布流程等规范并转换成标准，再逐步推给各个项目研发。一定要保持运维角度的平台化、产品化思路，当时机成熟时，也可以单独成立团队来做。
在项目前期架构设计阶段，运维就需要参与，将运维最关注的各方面，比如稳定性，安全性和可运维性的要求融入架构设计中。所以需要以项目的形式，将每个运维项目全生命周期单独管理起来，尤其是针对多个 ToB 客户的业务更有必要。
加入 EGO 后收获很多，尤其是在小组里学到了不同行业的知识，甚至各个技术领域还能互相帮助，弥补了自己的很多不足。在 2018 年也希望 EGO 能有更多小组之外的活动，让大家收获更多。
在 2G 和 3G 时代，车联网的使用体验是有一定影响的。但到了 4G 时代，三大运营商的 4G 网络基本都能满足车联网的基础需求。
难点在于整合多个车企的需求并逐渐迭代解决方案。车联网目前还在发展过程中，标配车联网的车辆数量还是很小的比例。目前后装市场基本不可能解决连车的问题，也很难发展成标准化，所以主要更多的还是依赖于跟车企的合作情况。
目前付费方式有很多，有的车企会收取基本套餐费用；还有的基础流量免费，超出流量需要付费；也有车企与运营商合作的不限流量套餐。总体来说，如果汽车不能联网，所有增值服务都会受到影响，所以现在基础的车联网服务免费，是一个大的趋势。