近年来车辆产业蓬勃发展，使得车载相关服务也更加多元，本篇文章的主角车载资通讯(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也都可以互相使用。
图1 基于Android的OSGi开放式框架技术架构
举例来说，在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 Telematics使用情境
图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产业与车辆产业的互助合作才能衍生出更多创新服务，并且发挥最大价值。
本篇文章藉由资策会所研发的Android/OSGi车载平台阐述Telematics使用情境，在未来将会以既有的能量，以更多、更创新的服务作为主要的发展目标。
(本文作者任职于资策会新兴智慧技术研究所)
