构建面向未来的灵活信息娱乐系统
时间:12-20
来源:互联网
点击:
车载信息娱乐系统正从特定用途的设备演变为可连接、可升级的平台,这的确也是大势所趋。从智能手机的集成上也可窥见一斑,几乎每个月都有新的智能手机上市,每个小时都有新的智能手机应用程序出台,然而信息娱乐系统则需实地运作十年甚至更久。那么今天的信息娱乐系统将如何配合明天,亦或是几年后的手机或应用程序?当然,没有单一的连接方案能解决这个问题。因此,信息娱乐系统的设计应该蕴含一定的灵活性来迎合移动市场不可逆转的进化,否则只能遭到淘汰。
信息娱乐系统自身运行的应用程序也面临类似的难题。尽管系统的用户体验很大一部分都来源于可连接的智能手机,系统本身仍要运行一组核心应用程序。通过这种方式,无论是何种智能手机,甚至没有智能手机,系统也能提供令人满意的用户体验。
问题是,系统是在何种应用程序环境下提供用户体验的?独家创制的应用程序环境鲜有用武之地,因为应用程序开发人员更倾向智能手机的大众市场环境。从另一方面说,智能手机应用程序的设计通常不会考虑汽车性能、可靠性以及安全性。那么,如何在保持“汽车级”同时提供内置应用程序?
本地化
要了解如何解决这些问题,就要考虑信息娱乐系统开发人员能选择哪些软件。对于许多开发人员来说,原生的C/C++ 工具包是一个久经考验的可信途径,如EB GUIDE、Qt 或Crank Storyboard。这些工具包确实提供了创造高质量用户体验的最佳途径:他们总体上启动更快、响应更迅速,相比安卓或HTML5 这样的“虚拟机”环境占用的内存更少。
本地工具包也能简化产品开发。例如, 有些工具包支持状态机,允许开发人员无需编写代码就能创建完整的人机界面,最终人机界面的测试也更为容易。开发人员还能用某些工具包在Photoshop 一类的程序中设计人机界面组件,并直接将这些组件植入到系统设计中,而不用花费几天甚至几周来重新编写组件代码。
问题在于,许多本地工具包都不支持安卓或HTML5 等流行的软件环境下编写的程序。那么,干脆用这些流行软件环境作为整个人机界面的基础是否能解决问题呢? 这样的解决方案在有些情况下的确可行。 移动化
以HTML5 为例,它提供了传统人机界面工具包的许多性能,包括渲染引擎、内容编辑工具和编程语言;还提供许多本地工具包还无法企及的优势。例如,HTML5 支持层叠式样表(CSS)清楚地区分业务逻辑和人机界面,使人机界面的定制或重置变得相对简单。另外, HMTL5 能在主机或移动电话上运行,允许开发人员创建统一的人机界面代码基底,无论车内有主机(人机界面在车内运行), 还是无主机电话辅助系统(人机界面在手机上运行)都能运行。HTML5 还支持“可执行人机界面规格”概念,汽车制造商按照这些规范提供以HTML5 编码的人机界面原型,而一级供应商负责把人机界面连接到所需的任何服务,从而完全避免了按照屏幕输出重建完整人机界面的繁琐而容易出错的过程。
尽管具备这些优势,HTML5 这样的移动应用程序环境并不总是内置人机界面的最佳基础。车外的世界充斥着不可预知的网络内容和安全隐患,对人机界面正常运行的威胁尤其令人担忧。从启动时间、性能、内存使用来看,这种环境与原生工具包仍然不可同日而语。
这是否意味着汽车公司必须从原生人机界面工具包和移动应用程序环境之间作出选择呢?其实不然。举例来说,下图显示基于QNX 车载信息娱乐平台的主机在原生工具包创建的人机界面上同时运行来自多种移动环境的应用程序。不同开发环境构建的组件在同一个显示屏上和平相处,而且彼此之间也没有明显的断层。 输出混合
要成功组合这些环境,软件平台需要支持多种关键技术。首当其冲的是构图——将来自多个应用窗口的输出合并到一个显示屏上。这些窗口可能需要横向排列、重叠、混合,或是其它一些类似的操作。为了快速有效地执行这种合并,平台的图像框架应该利用图像处理器(GPU) 的硬件加速。在这样设计得当的系统里,用户无需手动切换环境,就能与用不同环境创建的组件进行互动,组件的转换也天衣无缝。
提取服务
为了将这些环境组合起来,平台还必须提供一个提取层,实现多种工具和语言创建的应用程序与系统服务的互动。例如,在一个基于发布/ 订阅式消息传递的提取层上,应用程序通过数据对象获得多种服务,例如,多媒体引擎、数据引擎、声音识别引擎、车辆总线、智能手机、蓝牙应用规范、免提电话以及联系人数据库。这些数据对象具有多种属性, 每一种属性对应一个特征,例如当前广播电台的频率或是发动机的每分钟转速(RPM)。系统服务发布这些对象并修改其属性,其它程序随即订阅这些对象,就能及时接收这些属性的更新。
理想情况中,这一个信息层是与编程语言无关,用不同语言(C、C++、 HTML5、 Java、JavaScript 等) 编写的程序,无需了解彼此的特性,也能互相交流。因此, 在像HTML5 这样的高端环境下编写的应用程序很容易接入设备驱动器提供的服务,或其他用C 语言或C++ 语言编写的低端服务。
有效控制应用
来自移动世界的应用程序有助于丰富并延伸娱乐信息系统的用户体验。尽管如此,保护汽车安全,使其免受移动应用程序类似“西部荒蛮”时期突袭是十分重要的。因此,系统软件平台必须使用一个容器将这一类应用程序隔离,以免汽车遭受恶意编码应用程序的攻击。
与时俱进
一个信息娱乐系统要与时俱进,必须支持空中(OTA)软件升级。随着汽车与快速演进的云服务和移动设备日渐相连,该需求的重要性愈为突显。理想状况下,OTA 部署将使用汽车的内置调制解调器,也可以使用智能手机连接技术,如NFC 来简化汽车- 手机配对的任务,因为许多用户发现传统的蓝牙配对很困难,而且比较耗时。
基于可行性和经济因素,OTA 更新应尽可能少地耗费时间和网络带宽。理论上,一个信息娱乐系统应该支持细粒度更新,只下载新的或修改过的软件组件。发布/ 订阅结构使更新更易于部署,因为它为软件组件间提供了宽松、灵活的连接,能更新或替换任何组件, 同时不影响与之通信的组件。一个微内核操作系统还能使设备驱动、虚拟机、文件系统、网络站以及其它系统级服务像独立进程一样运行,可动态更新,从而简化了细粒度更新。
综上所述,维持信息娱乐系统的竞争力不能简单地靠堆砌应用程序来做到。在应用程序模式中,司机必须下意识地从一个应用转换到另一个应用,从而造成驾驶分心。因此,Pandora 或Slacker 等流行的音乐服务应被无缝整合到收音机用户界面上;同样地,兴趣点或基于位置的服务应用也应被整合到导航系统中。
因此,理想的汽车应用程序其实根本不是一个应用, 而是一个插件。插件结构赋予车内自然界面以新的内容和特性,使得用户更易理解应用程序并与之互动。
信息娱乐系统自身运行的应用程序也面临类似的难题。尽管系统的用户体验很大一部分都来源于可连接的智能手机,系统本身仍要运行一组核心应用程序。通过这种方式,无论是何种智能手机,甚至没有智能手机,系统也能提供令人满意的用户体验。
问题是,系统是在何种应用程序环境下提供用户体验的?独家创制的应用程序环境鲜有用武之地,因为应用程序开发人员更倾向智能手机的大众市场环境。从另一方面说,智能手机应用程序的设计通常不会考虑汽车性能、可靠性以及安全性。那么,如何在保持“汽车级”同时提供内置应用程序?
本地化
要了解如何解决这些问题,就要考虑信息娱乐系统开发人员能选择哪些软件。对于许多开发人员来说,原生的C/C++ 工具包是一个久经考验的可信途径,如EB GUIDE、Qt 或Crank Storyboard。这些工具包确实提供了创造高质量用户体验的最佳途径:他们总体上启动更快、响应更迅速,相比安卓或HTML5 这样的“虚拟机”环境占用的内存更少。
本地工具包也能简化产品开发。例如, 有些工具包支持状态机,允许开发人员无需编写代码就能创建完整的人机界面,最终人机界面的测试也更为容易。开发人员还能用某些工具包在Photoshop 一类的程序中设计人机界面组件,并直接将这些组件植入到系统设计中,而不用花费几天甚至几周来重新编写组件代码。
问题在于,许多本地工具包都不支持安卓或HTML5 等流行的软件环境下编写的程序。那么,干脆用这些流行软件环境作为整个人机界面的基础是否能解决问题呢? 这样的解决方案在有些情况下的确可行。 移动化
以HTML5 为例,它提供了传统人机界面工具包的许多性能,包括渲染引擎、内容编辑工具和编程语言;还提供许多本地工具包还无法企及的优势。例如,HTML5 支持层叠式样表(CSS)清楚地区分业务逻辑和人机界面,使人机界面的定制或重置变得相对简单。另外, HMTL5 能在主机或移动电话上运行,允许开发人员创建统一的人机界面代码基底,无论车内有主机(人机界面在车内运行), 还是无主机电话辅助系统(人机界面在手机上运行)都能运行。HTML5 还支持“可执行人机界面规格”概念,汽车制造商按照这些规范提供以HTML5 编码的人机界面原型,而一级供应商负责把人机界面连接到所需的任何服务,从而完全避免了按照屏幕输出重建完整人机界面的繁琐而容易出错的过程。
尽管具备这些优势,HTML5 这样的移动应用程序环境并不总是内置人机界面的最佳基础。车外的世界充斥着不可预知的网络内容和安全隐患,对人机界面正常运行的威胁尤其令人担忧。从启动时间、性能、内存使用来看,这种环境与原生工具包仍然不可同日而语。
这是否意味着汽车公司必须从原生人机界面工具包和移动应用程序环境之间作出选择呢?其实不然。举例来说,下图显示基于QNX 车载信息娱乐平台的主机在原生工具包创建的人机界面上同时运行来自多种移动环境的应用程序。不同开发环境构建的组件在同一个显示屏上和平相处,而且彼此之间也没有明显的断层。 输出混合
要成功组合这些环境,软件平台需要支持多种关键技术。首当其冲的是构图——将来自多个应用窗口的输出合并到一个显示屏上。这些窗口可能需要横向排列、重叠、混合,或是其它一些类似的操作。为了快速有效地执行这种合并,平台的图像框架应该利用图像处理器(GPU) 的硬件加速。在这样设计得当的系统里,用户无需手动切换环境,就能与用不同环境创建的组件进行互动,组件的转换也天衣无缝。
提取服务
为了将这些环境组合起来,平台还必须提供一个提取层,实现多种工具和语言创建的应用程序与系统服务的互动。例如,在一个基于发布/ 订阅式消息传递的提取层上,应用程序通过数据对象获得多种服务,例如,多媒体引擎、数据引擎、声音识别引擎、车辆总线、智能手机、蓝牙应用规范、免提电话以及联系人数据库。这些数据对象具有多种属性, 每一种属性对应一个特征,例如当前广播电台的频率或是发动机的每分钟转速(RPM)。系统服务发布这些对象并修改其属性,其它程序随即订阅这些对象,就能及时接收这些属性的更新。
理想情况中,这一个信息层是与编程语言无关,用不同语言(C、C++、 HTML5、 Java、JavaScript 等) 编写的程序,无需了解彼此的特性,也能互相交流。因此, 在像HTML5 这样的高端环境下编写的应用程序很容易接入设备驱动器提供的服务,或其他用C 语言或C++ 语言编写的低端服务。
有效控制应用
来自移动世界的应用程序有助于丰富并延伸娱乐信息系统的用户体验。尽管如此,保护汽车安全,使其免受移动应用程序类似“西部荒蛮”时期突袭是十分重要的。因此,系统软件平台必须使用一个容器将这一类应用程序隔离,以免汽车遭受恶意编码应用程序的攻击。
与时俱进
一个信息娱乐系统要与时俱进,必须支持空中(OTA)软件升级。随着汽车与快速演进的云服务和移动设备日渐相连,该需求的重要性愈为突显。理想状况下,OTA 部署将使用汽车的内置调制解调器,也可以使用智能手机连接技术,如NFC 来简化汽车- 手机配对的任务,因为许多用户发现传统的蓝牙配对很困难,而且比较耗时。
基于可行性和经济因素,OTA 更新应尽可能少地耗费时间和网络带宽。理论上,一个信息娱乐系统应该支持细粒度更新,只下载新的或修改过的软件组件。发布/ 订阅结构使更新更易于部署,因为它为软件组件间提供了宽松、灵活的连接,能更新或替换任何组件, 同时不影响与之通信的组件。一个微内核操作系统还能使设备驱动、虚拟机、文件系统、网络站以及其它系统级服务像独立进程一样运行,可动态更新,从而简化了细粒度更新。
综上所述,维持信息娱乐系统的竞争力不能简单地靠堆砌应用程序来做到。在应用程序模式中,司机必须下意识地从一个应用转换到另一个应用,从而造成驾驶分心。因此,Pandora 或Slacker 等流行的音乐服务应被无缝整合到收音机用户界面上;同样地,兴趣点或基于位置的服务应用也应被整合到导航系统中。
因此,理想的汽车应用程序其实根本不是一个应用, 而是一个插件。插件结构赋予车内自然界面以新的内容和特性,使得用户更易理解应用程序并与之互动。
信息娱乐系统QNX原生工 相关文章:
- Windows CE 进程、线程和内存管理(11-09)
- RedHatLinux新手入门教程(5)(11-12)
- uClinux介绍(11-09)
- openwebmailV1.60安装教学(11-12)
- Linux嵌入式系统开发平台选型探讨(11-09)
- Windows CE 进程、线程和内存管理(二)(11-09)