伴随着智能手机的发展和普及，消费者对智能和互联网带来的变化已经有了充分的认识，然而如今的汽车却很难与“智能”联系起来；尤其是汽车里那块难用的屏幕，也让手机支架成为大部分车主必备的装备。这种奇怪的现象让我们不禁要问车载系统什么时候才能像手机一样方便智能？
再豪华的汽车也逃不掉被手机支架支配的恐惧
也正是这种疑问把已经发展百年的汽车推到了一个变革的时间点——智能化、网联化，让沉闷的汽车行业开始波涛汹涌。汽车企业和互联网企业开始尝试研发适合汽车的智能车联系统；尤其是在阿里巴巴和上汽基于AliOS系统开发的斑马智联车机受到市场认可以后，从吉利、长安这些自主汽车巨头，到百度、腾讯等互联网豪强都纷纷入局，大家都希望能在这一场变革中找到新的爆发点。
2016年，上汽与阿里合资的斑马推出基于AliOS的斑马系统
2017年，百度发布DuerOS系统，腾讯推出AI in car系统，蔚来推出NOMI系统
2018年，吉利推出GUKI生态系统，比亚迪推出DiLink系统，长安与腾讯合资开发车载系统……
那到底什么样的车联系统才是真正适合汽车的？哪个车联系统才能为消费者和驾驶员带来真正的方便和智能？我们来做一个详细的解析。
汽车与手机的差异
从Andriod到IOS，智能手机的普及让消费者对方便好用的系统已经有了一个基础的认知；也正是因为这类成熟的智能操作系统在前，大部分消费者在车载场景下也会很自然的有相同的需求。但其实我还是要说明，直接把手机和车机等价也确实有点难为汽车行业了。
车载系统远不是手机搬到汽车里这么简单。汽车级的系统在可靠性、成本、开发周期、交互上都有应该遵守的逻辑。
1. 汽车的可靠性要求高
汽车动辄十多年的使用寿命要求，又要面对高低温、振动等各种复杂环境，加上三年/十万公里的质保要求，让车内的电子零部件的要求相对手机平板都要高很多，我们可以对比一下中控车机和手机的可靠性测试差别。可以看到车机在各项指标中都比手机严格很多。这个基本的要求给车机的软硬件开发都带来了很多的要求，比如处理器要耐高温、屏幕模组要防撞击等等……
汽车系统与手机试验标准的差异
2. 处理器性能限制
在普通消费者心中，手机处理器的性能已经非常强大，这些消费级的处理器（例如华为麒麟980、高通845），性能确实一流，但其工作温度范围一般都只能在-10~50℃左右；但按照上面提到的车载使用环境，这些处理器却不合格，简言之，不满足车规级AEC-Q100标准。处理器要达到车载的使用要求，在工艺制程和性能上必须要妥协。这也导致同期的汽车级处理器性能都比同期的手机处理器要落后了约两代。
英特尔2017年发布的车载芯片Apollo Lake，工作温度范围-40℃~110℃，最高性能版本4核2.4GHz
3. 人机交互差异
手机的人机交互和界面设计并不适合汽车，如果仅仅是简单的将手机系统移植到汽车上，就会出现下图这样的情况，车机屏幕上整齐排列着app的图标和小小的字。这种偷懒的设计既不美观又不利于驾驶员操作，一股脑的把所有手机app堆到车机上也显然没有充分考虑用户使用场景，难道我会在硕大又不顺滑车机屏幕上发微信？
车联系统的关键要素
如今大部分的车联系统都是基于开源的Android或Linux经过二次开发而来的；针对汽车和手机的差异，除了沿用Android的部分层级和模块，还需要针对车载场景进行一些定制化开发和优化。
Android系统架构
具体而言，相比于手机操作系统，完整的车联操作系统一般应该满足以下几个关键要素：
1. 支持车辆控制
结合车辆原有的功能才能实现更好的体验，车载操作系统需要具有支持车辆控制的层级和模块；一般是需要包含车载CAN总线功能和相关控制权限。
2. 集成汽车专用服务
相比于手机，汽车还包含很多特有的服务功能，将这些功能集成到操作系统中能提高服务的实施效率和功能的安全性，例如与手机连接、车辆诊断、远程通信等功能。
3. 专门的电源管理
汽车启动时车载系统也需要迅速开机（几秒内），点火时造成供电系统异常电压波动和冲击问题（12V电源大范围跳变），这都要求车载操作系统具备专门的电源管理方案，需要在操作系统中对不必要的部分进行裁剪和优化，以保证电源异常时的正常运行。
4. 支持低成本硬件优化
由于车规级的要求和成本的限制，汽车上的处理器CPU性能都不及手机处理器，为了实现足够的效果，满足汽车长达十多年的使用周期，操作系统在这方面也具备相应的优化功能。
下图是完整的车载操作系统具备的层级和功能举例。一个汽车需要实现完整的车联功能，理论上除了包含Android/Linux的内核、应用层、系统层以外，至少还需要汽车服务、车辆控制的层级。
完整车联操作系统层级
业界解决方案对比
我们再回头来看这两年出现的各种“智能车联操作系统”，按照上一节严格的层级定义，其实很多系统并不都属于完整的操作系统，大部分都只包含了少数层级和模块，或者只重写了一部分模块来适应车载场景，只有极少数定制了所有的层级。这些系统按照深度定制的层级，大致可以分为三类，借用手机行业的说法分为超级app、ROM、定制操作系统。
1. 超级app
这一类虽然名叫系统，但其实只是将智能导航、语音交互、云服务等功能做成类似手机app的形式，在应用层通过调用系统已有的车辆服务接口实现相关功能；也没有支持汽车服务的层级和模块，其他部分沿用现有系统。典型代表有腾讯AI in car（最近更名为Tai）、百度DuerOS。
由于只开发了应用程序，这种方案的开发周期短，成本低，只需要车企提供相应的控制接口即可实现车联网功能。腾讯车联方案最快仅需要半年时间即可落地（2017年11月与广汽合作，2018年5月联合推出祺云智联系统）。当然缺点也比较明显，由于没有与系统下层深度整合，只能按需求调用相关资源，导致部分功能体验有瑕疵；另外在升级的时候，也只能在现有功能上升级，无法凭空调用新的下层接口，实现与车辆相关的新功能。这种方案比较适合车载系统开发基础薄弱，希望快速落地智能网联的车载系统的汽车企业。
2. ROM
基于自身需求对应用层、框架层和汽车服务层进行定制，更下层则沿用裁剪后的Android组件，类似于手机中的各种ROM。此方案更侧重框架层和汽车服务层，能提供灵活的车辆服务功能，是希望自研操作系统，而不被互联网绑架的汽车企业的首选。典型代表有吉利GKUI、比亚迪DiLike等。
这种解决方案针对汽车深度定制，与汽车本身功能进行整合，能提供较为完整的智能车联功能，汽车企业可根据自身的设计和需求对用户界面、车辆功能进行定制化开发，能掌握足够的主动权。但由于更底层的网络连接、安全管理等方面沿用Android系统，具有一定安全性和可靠性的隐患。而车企一般不具有互联网生态，在上层的云服务中多数还是需要与互联网企业进行合作。另外，因为对底层涉及的不多，在不同的车型搭载的时候需要重新适配和开发，无法直接复用。这个方案适合具备一定软件系统开发能力基础和人才储备的汽车企业，但这条路并不好走。
3. 定制操作系统
基于Android系统，对其内核、硬件驱动、系统服务等底层进行重构。重写硬件抽象层和相关的资源调度模块，并根据不同的底层硬件，对系统进行有针对性的优化。形成一个整体的打包解决方案。典型代表有AliOS、AGL（Automotive Grade Linux）、Android Auto等。
这种方案将硬件资源深度整合优化，集中调用，对汽车层面的硬件调度更为合理；作为整体的解决方案，在对底层硬件进行适配以后即可在全车型通用。但是，这种深度整合的系统，需要大量的时间和人力投入；比如阿里巴巴为克服Android系统的限制，经过手机、车机的迭代经过十年，投入超过百亿才完成了AliOS，今天更是将AliOS上升到集团战略；而谷歌基于Android开发的auto版本，现在还没有发布。所以这套方案一般的企业短期内无法模仿研发，但一旦成功也可以筑起较高的技术壁垒。
对比
汽车如何拥抱互联网
上述三种方案在现在这个汽车亟需提升车内互联体验的时间点来说，谈不上绝对的好与坏；各汽车企业的需求、战略和可支配资源都不一样，在选择车载系统的解决方案上也会有相应的差异和取舍；也就是看相关企业是为了迅速落地，赶上这波浪潮快速获利赚快钱，还是着眼于未来，长远规划深度布局。
虽然目前看来合作开发深度融合的上汽和阿里已经占得一丝先机，但其他企业也正调动资源追赶，依靠战略合作和合资迅速拉起战线，这场智能网联汽车的争夺战才刚刚开始。
在这种广泛的竞争中，消费者们也应该相信，有朝一日当我们进入车里的第一件事将会是语音唤醒智能车载智能助手，而不是把手机架到支架上。