基于OSGi的智慧家庭应用控制架构研究与模型设计

2014-02-28万象

电信科学 2014年3期

万象

（中国电信股份有限公司上海研究院上海200122）

1 引言

作为基础网络提供者，电信运营商在家庭市场一直占据着优势地位。随着全业务运营的开展以及移动互联网、物联网等新兴技术的更新换代，家庭市场成为融合各种新型应用以及综合信息服务的阵地，为运营商孕育了新的市场空间。电信运营商在积极推进新一轮宽带升级的同时，期望通过拓展更多的智慧家庭应用，使用户能够更加方便快捷地享受到智能、舒适、高效与安全的家居生活，智能家居应用将成为运营商未来主推的智慧家庭应用。因此，本文所指智慧家庭应用不考虑目前模式较为成熟的IPTV、OTT等应用，重点关注于智能家居等新业务。

目前，由于智能家居市场分散、品牌集中度低、产业链复杂、缺乏主导者以及技术标准不统一造成不同厂商设备无法互联互通等诸多不利因素，导致运营商推进其应用开发和规模部署困难重重。因此，系统开放性和升级能力成为运营商发展智能家居应用的关键。本文结合笔者近年来的研究和实践，对运营商实现规模化、可运营、可管理的智慧家庭应用，提出了一种标准开放的平台架构，可以实现应用的动态加载及运行，将有助于运营商为用户提供更多第三方的智能应用和服务，推进智慧家庭业务发展，进而为智慧城市的建设与发展助力。

2 智慧家庭应用控制架构的关键要素

目前的智能家居通用系统架构如图1所示，包括家庭网络层、通信网络层、业务平台层、智能家居应用层以及针对业务平台和智能家居应用的网管系统。

在家庭网络层，传感网接入网桥通过有线或无线方式上联家庭网关用户侧网络接口，通过不同的短距通信技术，如ZigBee/Zwave、315/433等连接各类应用终端，其上运行相关智能家居应用程序，实现协议转换、状态控制、信息汇聚、终端寻址及认证等功能。因此，传感网接入网桥是智能家居应用实现的核心设备。通常情况下，传感网接入网桥及应用终端由各智能家居厂商提供，电信运营商提供的家庭网关仅为其提供连接业务平台的网络通道。在其他层，除通信网络层由电信运营商主导外，业务平台层和智能家居应用层都由智能家居厂商所掌控。

这种松耦合的业务提供模式不仅使运营商只能作为纯管道提供商，很难实现对业务的智能感知、智能控制与智能协同，而且使业务提供商只能提供垂直业务，不能为用户提供具有融合业务体验的应用与服务。因此，需要重新设计一种新的开放架构模型，实现智慧家庭（智能家居）应用的灵活开发、动态加载与有效控制。

智慧家庭实现的关键是物联化和互联化，而物联化和互联化的基础正是高速优质的网络，即家庭网络和通信网络。家庭网关作为连接家庭网络和通信网络的核心设备，必将成为运营商构建智慧家庭应用开放架构模型的核心组件。此外，为实现智慧家庭应用即插即用和可运营、可管理，需要有一套融合运营商现有平台的管理控制系统及流程。因此，支持开放架构平台的家庭网关和可运营的管理控制系统及流程是智慧家庭应用控制架构的两个核心要素。

3 智慧家庭应用控制架构的方案选择

家庭网关作为智慧家庭应用开发与部署的核心设备，其采用的开放架构平台方案是智慧家庭应用控制架构设计的关键。目前家庭网关采用Linux操作系统，在其上部署开放架构平台有两种不同的思路，一种是采用基于Linux的智能操作系统Android，另一种是采用国际主流的中间件技术OSGi。下文将对Android和OSGi的技术特点进行详细比较，确定在家庭网关上部署开放架构平台的实现方式。

如图2所示，Android和OSGi虽然都运行于虚拟机（VM）之上，服务都采用组件的形式提供，但两者仍然存在比较大的区别，具体见表1。

从表1可以看出，一方面，虽然Android是一款非常出色的开放的移动设备应用平台，但由于缺乏远程管理功能或组件版本信息，为大规模部署和管理服务带来困难；另一方面，由于家庭网关当前设备形态大多不支持多媒体处理芯片及显示屏，Android平台强大的多媒体处理能力及丰富的UI等优点无法在家庭网关设备上使用和体现，且基于OSGi开发的应用更为轻量级，因此，在网关设备形态和处理性能不出现大的变化的情况下，家庭网关使用Android系统的可能性很小。此外，家庭网关作为网络接入设备，其安全性也是运营商高度关注的，在家庭网关上部署Android存在一定的安全隐患。就目前情况而言，OSGi更适合作为家庭网关开放架构平台。

图1 智能家居通用系统架构

图2 Android和OSGi特性比较

表1 Android和OSGi详细比较

支持OSGi的家庭网关是基于现有家庭网关硬件架构实现的，其功能模块设计如图3所示。与现有家庭网关相比，主要区别体现在底层硬件配置和上层软件实现上。

（1）硬件配置

·主芯片。目前主流的PON/LAN芯片均可满足OSGi的部署需求。

·flash。目前主流的OSGi框架镜像容量约为14 MB，考虑到容错采用双镜像备份，flash需要额外增加28 MB的空间，需为bundle预留一定的存储空间以及兼顾未来的可扩展性，支持OSGi的家庭网关flash容量不少于128 MB。

图3 支持OSGi的家庭网关模块

·RAM。OSGi框架运行时需要占用的内存约为20 MB；根据bundle不同，内存占用也不同，需为每个bundle预留至少1 MB的内存，兼顾未来的可扩展性，支持OSGi的家庭网关RAM不少于128 MB。

（2）软件实现

从图3可以看出，支持OSGi的家庭网关底层采用的仍是Linux操作系统（内核版本Linux 2.6.30以上），与现有家庭网关不同，通过在底层操作系统基础上部署Java虚拟机和OSGi框架，并把家庭网关的本地服务模块进行JNI封装供上层应用软件bundle（即原来运行于网桥上的智能家居应用程序）进行调用，使应用可以基于Java组件开发，从而屏蔽了底层硬件的差异，使应用具备跨平台特性。根据JNI提供方式的不同，可以分为两大类。

·标准JNI。该类接口由OSGi框架提供，在编译Java运行环境的时候已经包含，如I/O、本地及远程管理服务等。由于实现细节对上层应用是透明的，因此，下面以Java中的I/O为例描述Java的读写文件是如何最终调用到底层read函数，以便清晰了解基于OSGi框架开发的应用软件bundle的实现机制。

步骤1上层应用软件bundle调用java.io来操作文件。

步骤2 java.io调用native read函数，Java查找本地lib中实现该接口的库，即libjavaio。

步骤3步骤1和步骤2都是Java代码，遇到native函数后，进入C代码的底层JNI实现。

步骤4 libjavaio.so的C代码调用read函数。

步骤5 read函数最终进入系统调用，调用内核里文件系统驱动的read函数读取文件内容。

·自定义JNI。有的应用软件bundle还需要和网关本地环境进行其他的交互，例如获取家庭网关动态IP地址实现业务平台与bundle的主动通信、获取用户逻辑ID用于业务平台与bundle间的用户认证鉴权、获取U盘的存储路径等，因此需要专门封装一些自定义JNI，该类接口由集成OSGi框架的家庭网关厂商根据bundle的特定开发需求封装实现。

以上介绍的都是底层软件向上封装的JNI，在实际开发中，OSGi还需要封装一些API供底层软件调用，以实现应用软件bundle将来自业务平台（通过OSGi-agent获取）或dongle（软件保护器）的信息通过TR069-agent发送给ITMS平台，如业务平台发起的bundle软件版本更新、ITMS获取dongle的运行状态等操作。

4 智慧家庭应用控制架构模型设计

为实现智慧家庭应用即插即用和可运营、可管理，需要有一套融合运营商现有平台的管理控制系统。BBF（Broadband Forum）制定的TR069系列协议是目前家庭网关与终端综合管理系统（ITMS）间采用的接口协议。在TR069系列协议中，TR-157是专门针对家庭网关加载的组件对象的管理协议。参考TR-157，结合运营商现有ITMS的管理架构，基于OSGi的智慧家庭应用控制架构如图4所示，分为终端设备域和网络应用域。

其中，终端设备域包括家庭网络内的所有设备，主要设备有：

·智能家庭网关+传感网接入dongle；

·智能控制终端（客户端）；

·智慧家庭应用终端（如各类传感设备）。

终端设备域实现家庭网络的组建和应用层的互通，支持智慧家庭应用和服务的本地控制和远程控制。与现有智能家居系统架构相比，传感网接入网桥的核心功能被拆分到智能家庭网关及其下挂的USB dongle设备中。应用终端通过支持不同短距通信技术的USB dongle连接智能家庭网关，USB dongle仅提供数据转发功能，不做任何数据处理。智能家庭网关不仅提供网络接入功能，还实现了对开放架构平台OSGi的支持。原有传感网接入网桥上运行的智能家居应用程序可以OSGi bundle的形式，在智能家庭网关上动态加载和运行。应用程序bundle负责完成智能家居业务平台及智能控制设备与应用终端之间的信息转换，并将转换后的信令发送至智能家居业务平台、智能控制设备或应用终端，以实现协议转换、状态控制、信息汇聚、终端寻址及认证等功能。

图4 基于OSGi的智慧家庭应用控制架构

网络应用域主要包括智能家居厂商提供的业务平台和运营商部署的业务运营平台（含bundle库）及ITMS等。智能家居业务平台主要实现智能家居业务的逻辑处理，并接受智能控制终端的远程控制指令。对运营商而言，业务运营平台和ITMS定位完全不同，业务运营平台主要负责业务数据的转发、为第三方提供bundle的审核/发布、为家庭网关提供bundle下载库以及为用户提供bundle运行状况查询等功能；而所有的管理控制流由ITMS发起，包括家庭网关动态加载bundle的鉴权、家庭网关上运行bundle的生命周期管理（启用、停用、更新等）、dongle及bundle的故障诊断及维护等。

5 可运营管理的应用控制流程设计

以典型的“业务开通”为例，分析了智慧家庭应用控制架构的使用流程，一方面便于更清晰地了解架构中各个子系统的功能，另一方面验证了基于设计的控制架构模型，构建智慧家庭应用的运营和管理是可行的。

图5是用户通过应用自助开通智能家居业务的流程，与运营商传统的业务开通流程不同，用户的业务数据最初不是在运营商的BOSS中生成，而是由智能控制终端上的应用发起业务申请，由OSGi业务运营平台和ITMS配合第三方业务平台实现业务开通后，反向同步给BOSS。

综上所述，基于OSGi的智慧家庭应用控制架构相比传统智能家居系统架构更加开放化和智能化，一方面支持OSGi的家庭网关使智能家居应用可以根据用户的需求动态加载和灵活部署，为智能家居应用部署拓展了运营商渠道，也使智能家居厂商可以更加专注于应用开发以便更好地满足用户需求；另一方面业务运营平台对智能家居应用的数据转发使运营商实现对业务的智能感知、智能控制与智能协同成为可能，运营商通过对智能家居应用的数据进行整合打包，可以为用户提供更多具有融合业务体验的应用，通过大数据分析，也可以开展更多有针对性的用户服务。

6 结束语

随着技术发展、竞争加剧，运营商渴望提供更多的应用来获得新的业务增长。智慧家庭生活提出了一个“4S”信息生活新标准，包括speed——极速、sharp——高清、share——分享、smart——智能。在4S中，前3个S无疑是运营商正在做且擅长做的，对于第4个S——智能，是运营商急于找到突破口的未来方向，基于OSGi的智慧家庭应用控制架构构建了全新的智能家居应用生态系统，为芯片制造商、终端厂商、网络运营商、服务提供商等产业链主要参与者带来全新的契机。当然，基于OSGi的智慧家庭应用控制架构能否帮助运营商最终实现业务发展，还面临诸多挑战，如终端成本较高、传感设备不成熟等。因此，通过技术标准统一，进一步降低终端成本以及对传感设备的可靠性、覆盖范围、干扰、时延、安全和隐私保护、电池续航时间等的进一步研究都是笔者后续重点关注的方向。相信，运营商涉足智慧家庭应用，将发挥积极作用。