基于OSGi的智慧家庭應用控制架構研究與模型設計

萬 象

（中國電信股份有限公司上海研究院 上海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的智慧家庭應用控制架構能否幫助運營商最終實現業務發展，還面臨諸多挑戰，如終端成本較高、傳感設備不成熟等。因此，通過技術標準統一，進一步降低終端成本以及對傳感設備的可靠性、覆蓋范圍、干擾、時延、安全和隱私保護、電池續航時間等的進一步研究都是筆者后續重點關注的方向。相信，運營商涉足智慧家庭應用，將發揮積極作用。

圖5 基于OSGi的智慧家庭應用控制流程

1 TR-157.Component Objects for CWMP.Broadband Forum,2009

2 中國通信標準化協會.通信網支撐泛在物聯應用 智能家居系統 技術要求，2011