在软件上，选用一个足够安全、稳定的操作系统非常重要。在这里不得不提一下 AGL（Automotive Grade Linux）这个组织，它是由 Linux 基金会发起，汇集了全球各大知名企业，旨在提供一个「汽车级」的 Linux 安全规范。

　　我们知道，Linux 世界里有成千上万种你想得到或者想不到的各种程序、组件，但是 AGL 并不允许所有的组件进入汽车领域。也就是说，一个对于电脑「可用的」软件，未经 AGL 认证的情况下，是不允许进入汽车级 Linux 系统的。AGL 界定了「足够安全的」各种组件，并在产品中只允许这些经过重重验证的组件，这样就在最根源处保证了系统的稳定与安全。

　　我们作为 AGL 成员，使用了汽车级的 Linux 作为核心，以此作为系统安全稳定的保障。另外，在软件研发的过程中，我们遵循了 CMMI 3 规范。为了应对各种极小概率事件，我们愿意付出更多的精力与资源，以保证系统的稳定性。

　　以上所述其实不是什么秘密，但是知易行难，只有在研发、量产的过程中摸爬滚打过才能知道怎样把这几点真正实施到每个细节中。

　　液晶仪表的毫秒级响应

　　快速响应一般是指仪表能在极短的时间内（毫秒级）将整车的状况反映到仪表上。

　　Android 手机是一个基于 Linux 的操作系统，由于各种原因，Android 手机冷启动的时间大约是 30-50 秒，这么长的时间对于仪表来说是个噩梦。主机厂对仪表的冷启动时间要求是 2 秒，我们基于 Linux 做了深度优化，将冷启动时间缩短到了 1.6 秒以内。

　　我们所说的 1.6 秒，并不是用一个 Linux Frame Buffer 的静态 Logo 图片来做视觉欺骗，而是将 3D 渲染的界面完整地呈现出来。虽然 0.4 秒的差距，普通人很难发现出其中的差别。但有一个现实状况：汽车从点火的瞬间就开始发送 CAN/LIN 信号，某些汽车的某些 CAN 信号，只在点火后 1-2 秒发送，如果仪表启动时间过长，会导致这些信号有机会丢失。

　　从操作系统的角度看，一般称之为「实时性」。传统的 Linux 的实时性不是很好，这也是众多需要 RTOS 的平台不选择 Linux 的主要原因。但是随着时间的推移，伟大的 Linux Kernel 也把 RTOS 的特性加进来了。

　　我们从两个层面来提升系统的实时性：内核层、应用层。得益于这两个层面的提升，我们的仪表响应速度比传统仪表更胜一筹。死机等问题的应对是一个很大的话题，也是业界关心的问题。死机分系统级死机和应用级死机。前面提到的 AGL，是应对系统级死机的方案之一。

　　同时，各种心跳机制、看门狗机制，可以应对各种小概率事件。从设计及实施上去预防，是更重要的解决办法。前面提到的 CMMI 3、系统测试，都是行之有效的预防手段。如果从用户的角度出发，万一发生了死机，系统会侦测到并在 2 秒内重新完成 HMI 加载。

　　JetCast协议

　　最后提一下我们的 JetCast 协议。JetCast 所支持的是 WiFi 连接、AVB、LVDS、车用以太网等各种汽车级多媒体总线连接方式。目前实现的是基于 WiFi 的连接。JetCast 是一种全新的流媒体传输协议，不是 AirPlay，也不是 Miracast。Airplay、Miracast 都只是单向的传输，JetCast 是双向传输。

　　我见到的众多驾驶者似乎都有这么一个习惯（包括我自己）：不爱使用车载导航，更愿意使用手机导航。

　　手机导航有几个好处：可以有实时路况、升级更方便。所以，大家都花了各种心思，设法把手机固定在车上的某个位置，以方便驾驶时观看。可是，问题来了，万一驾驶途中有电话来了，尽管可以用蓝牙来通话，但是导航界面就被切换到后台了，需要手动切换回来。

　　另一方面，液晶仪表这么大一块屏幕，又处于最易于观察的位置，如果能将手机导航的画面传输到液晶仪表上，那这件事就完美了：有实时路况、升级方便、无需设法固定手机。

　　液晶仪表与手机连接建立以后，手机以流媒体的形式将导航画面传输给仪表，在传输图片的过程中，手机处于完全解放状态：可以把手机屏幕关掉，可以打电话，甚至打游戏（驾驶员行车时可不能这么干）。

　　这种将手机导航投射到仪表的技术，目前众多德系车厂实现的只是将车载导航画面投射到仪表，并没有实现手机投射的功能。

　　精彩问答

　　问：目前液晶仪表会开发相应的应用吗？