车载平台创新Telematics设计详解

近年来车辆产业蓬勃发展，使得车载相关服务也更加多元，本篇文章的主角车载资通讯(Telematics)作业平台也是在这样的时空背景下所产生的一个平台技术。Telematics是一项创新应用，其结合电信(Telecommunication)、信息(Information)技术并将其衍生的信息服务应用于车辆，因此驾驶者可以在车内透过无线通信技术传递资料或者与其他车辆交换讯息。较常见的Telematics应用服务为行车导航服务、地区性服务导引、行车记录服务、车队管理系统等。

Telematics作业平台包含硬件与软件领域。硬件方面包括车用运算处理器、车辆控制网络、车辆感知组件、实体通讯网络建置，而软件部分涵盖车载操作系统建置、车载设备驱动器设计、应用服务程序设计。事实上，Telematics作业平台就是一个透过车辆硬件与系统软件，实现各种车辆创新服务类型的车载系统。
  
慎选合适的操作系统 

如上述，一般程序设计者可能会想到平台实作方式，就是使用如Windows XP、Linux等操作系统来实现Telematics相关服务，事实上的确如此，所以挑选合适的操作系统便是主要的关键。  
 
以平台特性而言，车辆是一个具备通讯能力并且会移动的个体，就如同手持装置一般，因此很直觉地可以把Telematics作业平台当成是一个放大版的手持装置。Android操作系统为Google所开发的一套基于Linux核心的操作系统，目前广泛使用于手持平台。此外，Google所拥有的大量云端资源，正是针对行动装置量身打造的，使用Android作为Telematics作业平台基础，将能加快信息系统的建置。
  
Telematics作业平台包含硬件与软件领域，仅以Android作为服务平台似乎略显不够，毕竟Android一开始是设计成手持装置的操作系统，因此开发车辆装置相关服务的责任就落在平台开发者的肩上。  
 
但棘手的是车辆拥有的装置与感测组件类型远大于手持装置，而每辆车所拥有的装置又不尽相同，要考虑到全部的装置类型，恐怕不是一两天的事情。如此，便需要一个能动态安装及移除服务的软件框架--OSGi框架(Framework)。  
 
OSGi Framework挑大梁 

OSGi最初是使用在数字家庭的网关(Gateway)，主要是在远程的服务供货商(Service Provider)与本地端的设备之间提供完整的点对点服务传送解决方案。OSGi定义了一个开放性的平台，使得远程软件服务供货商能视用户需求，将所提供的应用程序及加值服务随时下载至靠近用户的网关上，并且自动安装执行，而上述所提及的网关通常是连接家庭网络、办公室网络与广域网间的一个装置，如机顶盒(STB)、非对称用户回路(ADSL)调制解调器、电缆调制解调器(Cable Modem)、住宅区网关(Residential Gateway)等。透过OSGi框架，不同厂商所开发出的服务软件及设备都能互相沟通及搭配使用。
 
就技术层面来说，依循OSGi规范所开发出的服务称为Service Bundle，具备OSGi功能的装置称为Service Gateway，在OSGi框架底下所有的Service Bundle都必须在Service Gateway上执行，并且Service Gateway本身可以透过网络从软件服务供货商处下载不同的Service Bundle。
 
更深入地说明，Service Bundle是由许多独立且具备相同或不同的软件模块所组成，这一个个独立的软件模块在OSGi框架里称为Basic Service，每个Basic Service是可以被重复使用，也就是说，开发者开发的Service Bundle可以使用其他Basic Service，而本身提供的Service也可以供其他Service Bundle使用。
 
因此，在OSGi的车载应用方面，开发者可利用前面所描述的优点，动态的安装或解除某项车辆装置相关的Service Bundle，并且藉由OSGi开放服务的概念，不管车子的种类为何、拥有哪些感测组件都可以达到装置间的服务共享，进而开发出更多创新应用的车载服务。
 
就软件需求而言，OSGi框架是一个用Java撰写的软件框架，只要操作系统支持JVM(Java Virtual Machine)，OSGi框架就可以运作。
 
所幸，Android的应用程序框架使用与JVM类似的DVM(Dalvik Virtual Machine)作为软件层核心，因此便能在Android上建筑OSGi框架。接下来，以资策会所开发的Android车载装置服务平台做一介绍。

  
Android车载装置平台居间协调 

Android车载装置服务平台是一个内嵌OSGi框架的Android平台，其架构图1所示。由图中可发现，OSGi框架架在Android框架之上，并且在OSGi框架撰写许多Service Bundle，在这些Service Bundle里，有的使用Android软件开发工具包(SDK)建造拥有用户接口的服务，某些利用Android提供的系统服务，有的则利用Android NDK建造车载装置独有的服务，而最大的重点是，它们都可以动态地安装或卸除，各个Service Bundle也都可以互相使用。
 

举例来说，在OSGi框架内全球卫星定位系统(GPS)Service使用Android的GPS系统服务来提供GPS信息，而Vehicle Service可以使用GPS Service抓取现在车速，并且利用Android NDK抓取OBDII信息，人机接口(HMI)Service便负责使用Vehicle Service将所有信息显示在屏幕上，如此车载平台俨然成为Service Gateway。  

为了让车载平台可以透过网络从软件服务供货商处下载不同的Service Bundle，因而实作具备OMA-DM及TR069能力的Management Bundle作为远程供装的管理通讯协议。而所谓的远程供装是指由伺服端来管理所有的终端设备，包括网络的联机方式、带宽的使用、服务存取环境参数等，这些琐碎的设定与软件安装是用户无法亲自操作的，因此须藉由伺服端的自动供装服务来达成。
 
车载平台管理看好TR069/OMA-DM
 
OMA-DM与TR069原本是用来管理具备联网功能的通讯设备，OMA-DM多用于行动装置，TR069则常用于家庭网络设备。在未来的环境里，车辆具备联网功能是必然的趋势，因此OMA-DM与TR069非常适合用来作为车载平台的管理，整体架构如图2所示。  


图2主要说明TR069/OMA-DM与车载平台的互动关系，在伺服端的TR069/OMA-DM，管理人员可以透过网页的方式下命令给TR069/OMA-DM Server。
 
接着，TR069/OMA-DM便会把Service Bundle传送到车载平台上，并且自动安装与启用，这方面的例子可以像是驾驶者配带一个多媒体装置进入车内，而车载平台本身不支持播放多媒体装置的档案，因此透过电话或用其他方式请求管理中心给予相关的Service Bundle，而管理中心一旦接受请求，便把Multimedia Bundle传送到车载平台，而平台一旦接收到Service Bundle，便会自动安装服务，如此平台又多了一个新的功能。  
 
在其他方面，为了扩充平台更多的应用，则使用Google的APP Engine在云端架设行车信息管理平台，透过车载平台所取得的行车录像以及GPS与车上诊断系统(OBD)的信息，可以很容易地收集到行车信息，接着再透过Network Bundle将数据传送至云端平台，并且进行车辆诊断或行车记录。如此一来，便完成一个完整的Telematics使用情境。  
 
其实台湾拥有很强大的信息技术(IT)能量，因此开发Telematics作业平台并不是件困难的事情，最主要的还是需要IT产业与车辆产业的互助合作才能衍生出更多创新服务，并且发挥最大价值。