基本介紹
- 中文名：多媒體家庭平台
- 外文名：Multimedia Home Platform
- 別名：MHP
- 所屬地區：歐洲
- 始於：1997年
發展歷史,定義及意義,技術特點,構架,核心,主要系統模組功能,套用層次,MHP系統基本結構,關鍵技術,存在問題,向MHP遷移及未來的前景,套用實例,
發展歷史
多媒體家庭平台（MHP）是由一個叫UNITEL的歐洲組織提出的，其目標是開發一個可接入多種數字多媒體服務的通用平台。
1993年，在數位電視的互動平台上提出該方案；
1997年，被列入DVB計畫中；
1998年7月，Sun Java虛擬機技術被加到MHP核心中；
2000年2月，Steering Board(EIGT指導委員會)第28屆大會批准在DVB中加入MHP1.0標準；
2000年7月，MHP1.0成為ETSI標準系列中的TS101 812；
2001年4月，DVB發布MHP1.0.1一致性測試和版本文檔，DVB和ETSI中心達成MHP管理協定。MHP專家組著手開發MHP Test Suite;
2001年10月，ETSI發布MHP1.0.1為TS101 812 V1.1.2；
2001年11月，ETSI發布MHP1. 1為TS101 812 V1.1.1；
2002年4月，芬蘭成為世界上第一個通過使用MHP來實現無線實況轉播互動服務的國家；
2002年11月，Streering Board通過根據CableLabs OCAP（美國有線電視實驗室互動式服務的有線電視產業軟體標準）而制訂的GEM（Globally Executable MHP）第一個版本;
2002年12月，DVB通過MHP Test Suite 1.0.2b――第一個完整的MHP測試包；
2003年1月，ETS發布GEM為標準TS102 819；
2003年4月，DVB批准MHP1.0.3,MHP1.1.1，並遞交給ETSI，分別進行作為標準TS101 812V1.3.1和標準TS102 812V1.2.1標準化工作；
2003年6月，ARIB（日本DTV標準）宣告在日本的數據廣播中接受基於GEM的套用環境；
2003年7月，ETSI就批准發布標準ES201 812 V1.1.1(一個ETSI的MHP標準版本)徵詢意見。
定義及意義
多媒體家用平台(MHP，Multimedia Home Platform) 項目定義了互動數字應用程式和運行這些應用程式的終端之間的通用接口。它是由DVB組織於1997年提出的。它的目標是在家用平台建立標準的互動多媒體應用程式，實現從純數位電視廣播向互動電視套用的平穩過渡，徹底取代模擬電視廣播。整個項目不僅包括應用程式編程接口(API)，還涉及用戶數字接入網等各個方面。2000年2月，DVB組織通過了MHP標準(MHP1.0)，2000年7月，歐洲電信標準化研究所(ETSI，European Telecommunications Standards Institute)正式接受了這一標準，編號TS 101 182，為正式部署標準鋪平了道路，更新的MHP1.1標準正在討論中。MHP項目的實施將有利於廣播、電信和計算機技術的進一步融合，並為運營商提供更全面、更強大、更靈活的技術解決方案。
DVB組織是由全世界30多個國家超過260個成員組成的合作組織，核心機構是DVB指導委員會(the DVB Steering Board)，對所有DVB標準和技術規範進行最後認證。MHP項目遵循DVB的慣例，將項目分解成兩個模組即技術模組和商業模組。分別制定技術解決方案和商業解決方案。
MHP項目組針對兩個模組建立了兩個工作組：
① 面向市場的工作組，主要定義基於本地網進行增強和互動電視廣播的用戶和市場需求(包括網際網路訪問等)。
② 面向技術的工作組—DVB-TAM(Technical Issues Associated with MHP)，解決DVB編程接口(API，Application Programming Interface)的規範等問題。
數位電視軟體平台—中間件由於各個廠家提出互不兼容的解決方案，尚無統一的定義和標準。一般認為：中間件指居於數位電視機頂盒內部實時作業系統與應用程式中間的軟體部分，它以應用程式接口API的形式存在，整個API集合被存儲在機頂盒的快閃記憶體FLASH中。MHP項目組就是致力於出台統一的中間件標準。表1列出一些典型數位電視系統和中間件提供商，其中的數據統計至2001年初。
表1 部分公司中間件情況比較
公 司 | OpenTV | Canal+ | NDS | 天柏寬網 | |
定位 | 中間件提供商 | 集成商 | 集成商 | 集成商 | |
網路數 | 43個 | 20個 | 不詳 | 不詳 | |
提供的套用軟體 | 視音頻、遊戲、股票、網頁廣播、中文電子節目指南等 | 視音頻、開機界面、遊戲、電子節目指南股票信息、網頁廣播等 | 不詳 | 視音頻、電子節目指南、股票信息、網頁廣播等 | |
CA | Nagra Vision的CAS | MediaGuard | Open VideoGuard | Nagra Vision的CAS | |
中間件及相關部分 | 中間件 | EN2 | MediaHighway | 與其他中間件提供商集成 | 無 |
開發語言 | 標準C語言 | 專用腳本語言 | 標準C語言 | ||
有無虛擬機 | 有 | 有 | 無 | ||
提供的開發工具 | OpenAuthor Pro and SDK | Studio+ | I-Frame Editor | ||
發展方向 | MHP Java | MHEG-5 Java | Java | ||
MHP項目組考慮以下幾個參考API候選方案：
· MHEG-5
· Mediahighway+
· OpenTV
· HTML/Java
· JavaTV
多媒體和超媒體專家系統(MHEG-5)是進行增強廣播服務的一種格式，能在擁有有限資源的終端上運行基本類型應用程式，它採用開放態度描繪編程對象，以便這些對象既能套用於標準化編程又能滿足特定的編程需求。
Mediahighway+和OpenTV系統在本文套用實例部分中將有詳細介紹，這裡不再重複。
HTML是網際網路上通用的標準語言。它是一種純解釋性語言，需要在本機上運行解釋器。
ava是由SUN公司開發的新一代程式語言，本來是想套用於智慧型型家電產品，但目前卻成為網際網路程式語言的主流。它是面向對象的程式語言，類似於C++，但摒棄了C++語言中少用且不好用的部分，它的特徵有跨平台、多執行緒、分散式等，使用它可在各式各樣不同種機器、不同種操作平台的網路環境中開發軟體 “一次編譯，到處運行”。它徹底改變應用程式的開發模式，帶來了自PC機以來又一次技術革命。
Java應用程式必須通過與作業系統密切相關的Java虛擬機，才能實現其功能。針對實時作業系統(例如HOPEN 、VXWORKS、PSOS)開發的嵌入式Java虛擬機可以為Java程式提供支持環境。實時作業系統支持面向消費類電子產品的Personal Java套用環境。這意味著不論在家庭、辦公室，還是在旅行途中，普通消費者能通過Java虛擬機技術，在實時作業系統和Java API上體會互動式電視機、電冰櫃、烤麵包箱、防盜設備等方面豐富多彩的生活模式，通過TCP/IP進行信息的交流，實現家庭信息化、智慧型化。
Java TV API是由SUN公司和各大數位電視公司通過開放式研究在Java平台的基礎上開放的產品，是計算機界的巨頭之一。SUN公司進軍數位電視廣播領域的拳頭產品。它藉助Java這一跨平台語言，針對增強電視和互動電視進行加強和最佳化，主要電子消費型產品生產廠家已公開聲明他們的產品將支持 Java TV API並將其作為全球數位電視軟體平台標準。
Java TV API 是針對數位電視接收機獨有的功能而設計的，這些功能有：
·音頻/視頻媒體控制
· 廣播數據訪問
· 服務信息數據訪問
· 調諧器和解碼器控制
· 螢幕圖形處理
DVB組織在考慮API候選方案時採用開放的態度，能適應不同層次運營商(稱為水平市場)的要求，API的選擇是與條件接收系統無關的，但同時能支持多密套用。
技術特點
MHP主要定義了機頂盒中間件的整體結構、傳送協定、內容格式、Java虛擬機和DVB-J APIs、安全性、各層的細節、套用狀態和表現、套用的自動啟動等，還定義了專用的套用信令。
構架
MHP被定義成三層：資源層，系統軟體層和套用層。典型的資源層包括：MPEG處理，I/O設備，CPU，存儲和圖形系統。系統軟體層給套用層提供一個抽象的可視的平台，通過執行一個套用管理器（亦被稱作navigator）來管理MHP和MHP上的套用。
現有的每個MHP系統都提出了不同的參考模型。DVB-TAM工作組運用面向對象，工具定義了應用程式類和函式，結合MHP系統需求的軟硬體資源(模型見圖1) 最終建立了一個整體參考模型，如圖2所示。整體參考模型包括5個層次(見圖3)：
圖1 MHP 軟硬體資源
圖2 整體參考模型
圖3 系統層次模型
應用程式(內容、腳本)和多媒體部件(視頻、音頻、字幕)；
· 編程接口API。
· 平台/系統軟體或中間件，包括互動式套用引擎、實時引擎或虛擬機，應用程式管理器等。
軟硬體資源和相關軟體。
主要系統功能有。
· 應用程式傳送和控制功能、事件管理功能。
· 條件接收功能。
· 內容下載功能。
· 導航功能。
· 內容顯示控制功能
· 通信和I/O控制功能。
· 底層驅動管理功能。
根據這一參考模型，用戶能夠獲得以下服務。
· 增強的廣播服務。
· 互動式廣播服務。
· 網際網路服務。
核心
MHP的核心部分——系統軟體的本質就是一個中間件。與其它的中間件不同的是，MHP中間件不是一個私有的中間件，它是一個開放的、統一的中間件。MHP標準只是定義了一些API接口，它沒有給出實現MHP的方法，因此，實現MHP的具體方案主要由中間件廠商和機頂盒廠商給出。
許多軟體包提供了該平台的常用API。MHP套用只需通過這些指定的API訪問平台。在指定API跟底層資源和系統軟體之間需要一個映射。
MHP建立在DVB－J的基礎上。DVB－J包括Sum Mircosystems公司的Java虛擬機。
主要系統模組功能
（1）應用程式（Application）
由參考模型提供的環境能很方便地對應用程式進行測試和認證，完全依照參考模型設計的應用程式一般能順利運行。而對應用程式提供商來說，他們的權益也受到保護。因為他們能設計出靈活的應用程式，可以廣泛套用於不同的平台，而不受機頂盒底層的限制。
DVB-TAM對應用程式的定義是：能用軟體模組實現互動式服務的功能性套用。一個應用程式也可以看作是一系列能激活MHP軟硬體資源的函式。
一個互動式的應用程式由以下兩大基本部分組成：
· 應用程式腳本(解釋型的或過程型的)；
· 內容/場景(用戶圖形接口和媒體流)。
用戶圖形接口(GUI)是用戶與機頂盒互動的接口，包括場景設計、選擇按鈕、靜止圖像、文本等。整個用戶圖形接口可以說由許多幕場景組成，每幕場景又是由一系列小部件、編程對象和屬性構成。而各場景之間、各個編程對象的聯繫則由特別的機制完成。
過程型的應用程式，是基於低端函式和類庫的程式，通常用於需要對主機資源進行最佳化時(如對傳輸網路資源進行最大化利用等)。它一般是平台相關性的，因此當移植到不同的主機平台時需要進行相應的變化。
解釋型應用程式由高端函式和類庫組成。這就允許我們能用平台無關性的參考模型來檢驗應用程式是否具有平台兼容性。
實際上，應用程式不一定全是解釋型的或全是過程型的。例如，我們可以在解釋型應用程式中嵌入過程型的代碼，這樣可以極大地減少代碼長度和程式執行效率。而平台無關性的問題則由主機內嵌的實時引擎、虛擬機來解決。當然如果在平台設計時沒有考慮兼容性的問題，那么要想實現不同平台的良好移植性是很困難的。
應用程式是可標識的，它可以自動運行或在受請求後運行。應用程式的顯示模式是大小可調的，或在後台運行。對應用程式的管理包括：中斷、錯誤處理、優先權模式、動態資源管理。在退出應用程式時，應該釋放系統資源。
（2）應用程式傳送機制（Application delivery mechanisms）
程式腳本和相關內容打包成應用程式對象後，轉換成DSM-CC對象。DSM-CC標準是由MPEG組織制定的，與網路通信協定類似，數據廣播的前端和數據廣播接收裝置之間必須有一套通信協定來保證數據的傳輸和解碼，MPEG-2標準的第6部分DSMCC就是這樣的一種開放協定。與其他協定相比較，DSMCC主要考慮的是在接收端設備資源有限的情況下如何實現快速的數據傳輸。DSM-CC UU是一種接口，允許我們從廣播流中或從遠端伺服器中獲取DSM-CC格式的對象。
DSM-CC對象允許一個數據環模組攜帶一個或多個程式對象。對象是模組化的，這樣可以最佳化記憶體使用性能。DSM-CC也提供壓縮工具來格式化程式對象和數據環對象，傳送機制還確保數據環對象下載的安全性。
（3）編程接口定義（API）
DVB-TAM對API的定義是：它是一系列高端函式、數據結構和協定，用來表示有關平台獨立性軟體的標準接口。它套用面向對象的語言，並能靈活地再復用已有的函式。
一個應用程式根據高端API的定義描述一系列的對象。它定義了應用程式與本機硬體資源、軟體資源之間的接口。
對API定義了以下的要求。
· 繼承性：它是可復用的。對於面向對象的語言來說，可繼承性是一個很重要的特性，父類(super class)中的數據或方法其子類(subclass)可繼承使用，子類的子類也可繼承使用，從而實現數據重複使用(reuse)，極大的提高了編程效率。
· 開放性：它能被其他接口實例引用。
· 抽象性：利用抽象數據類型將低端的特性封裝起來，不能被直接運用。只有通過授權的行為才能與外部互動，從而保證原始碼的完整性和安全性。
· 靈活性：它是硬體獨立的，在將來由於硬體升級和換用不同的硬體系統時，API也能升級。如可以通過下載增加新的類庫等。
根據應用程式的不同格式，低端API用來處理進程型函式，同時高端API用來處理解釋型函式。
· 低端API對應於進程型程式。此類API不僅需要闡明套用函式，還要關心資源的情況。
· 高端API對應於解釋型程式。用於抽象解釋層的級別越高，系統的獨立性就越強。API只需要闡明套用函式，不需要關心資源是否被激活。開放API定義的制定將保證DVB機頂盒實現硬體無關性功能。
DVB-MHP對API的功能表述如下。
· 支持本機存儲的或實時下載的應用程式。
· 支持所見即所得。
· 支持對資料庫的訪問(如DVB-SI表單)。
· 兼容性。
作為MHP項目的核心部分，一個開放的、有發展前途的API標準應該是模組化的、可移植的、靈活的、可擴展的。它允許內容和服務提供商套用不同的但相互兼容的平台提供服務。
（4）導航系統（Navigation/Selection）
當機頂盒啟動後，內嵌的導航函式通過調用相應的API運行第一層的導航程式。API也能用來對TS流進行控制，如瀏覽頻道和節目。
導航也能直接由可執行代碼運行，而不需要運用API和相關解釋器。在DVB-TAM推薦的模型中，導航系統模組與API位於在同一層次，以便能方便的從數據管道和TS流取得數據。
基本的導航系統包括以下兩個功能。
· 列出全部可用的節目清單。
· 提供快捷鍵方便用戶訪問節目內容。
增強型的導航系統由電子節目指南(EPG)實現，增強功能包括用戶資料夾和書籤等。
（5）應用程式啟動和控制（Application Launch and Control）
一個應用程式的運行包括啟動、套用和表現幾個部分。程式代碼可駐留在機頂盒中或從遠端伺服器中下載。如果是從遠端伺服器中下載的，應用程式能自動升級。
應用程式管理器的功能是。
· 獲取和釋放系統資源。
· 錯誤管理和例外處理。
· 初始和中斷會話(Session)。
· 檢驗代碼和數據的完整性。
· 同步指令和信息。
· 調整顯示圖形格式以適應不同平台的要求。
· 允許對內容和變數的共享。
· 擁有有序和整潔的表現式樣。
（6）加密功能（Security Functions）
雖然加密模組的定義尚未完成，DVB還是定義了涉及加密的API的要求。
· 應該使用通用的加密模組，以保證不同廣播運營商和內容提供商在交換節目時的兼容性。
· 涉及加密的API應該是與條件接收系統無關的。如果有必要的話，MHP 的API應該對CA相關函式開放。
重要的安全方面的考慮還涉及：
· 對系統資源的保護以防濫用，如對記憶體的過量訪問。
· 對專用數據的保護以防未授權的訪問。
（7）中間件（Middleware）
節目服務商將各種服務項目以應用程式的形式通過傳輸信道(例如，寬頻多媒體數據網，有線電視網路)發布(如，EPG)，用戶打開電視機通過機頂盒瀏覽。用戶的需求信息(例如，視頻點播VOD)通過上傳信道(例如，電話線Modem或有線電視電纜)傳輸到視頻伺服器，並根據請求選擇相應的服務項目以應用程式的形式通過傳輸信道下載到用戶終端－機頂盒的快閃記憶體Flash中。應用程式調用機頂盒Flash內的中間件所包含的API，執行應用程式，完成用戶請求的功能。
中間件的目的是使機頂盒基本的和通用的功能以API的形式提供給機頂盒生產廠家，以實現數位電視互動式功能的標準化，同時使服務項目(以應用程式的形式通過傳輸信道)下載到用戶終端－機頂盒的數據量減小到最低限度。中間件產品一般由非節目提供商和非機頂盒廠家的第三方提供，對於使節目提供商製作節目和廠家生產機頂盒的進一步簡化和標準化都是非常有利的。這正是知識經濟時代市場更加細分的具體表現。
中間件的實現直接取決於應用程式的格式(是解釋型的還是進程型的)以及套用高端還是低端的API。每個成功的中間件實現都是根據本機平台的特點量體裁衣。
實現互動和實時引擎有不同的方法，但通常需要有以下幾大模組。
· 庫函式；
· 腳本和內容解釋器；
· 事件管理器(處理遙控器和其他設備、用戶回響、標識、定時、錯誤處理)；
· 自舉(Loader)。
依靠使用API，實時引擎提供與系統硬體和軟體低層接口。實時引擎能喚醒駐留在本機內的程式，而駐留本機程式則可以是與平台相關的，從而在解釋性應用程式層面提高系統性能和減少操作性的限制(如壓縮下載應用程式對象的大小) 。實時引擎是可執行代碼，參照參考模型並根據各個平台特點最佳化。
虛擬機通常用來運行過程型函式(例如複雜的計算、信息和文本處理、數據壓縮)或駐留程式，以加強解釋性應用程式的性能。
由於實時引擎和虛擬機的套用，使得API能實現與平台無關性的應用程式。
（8）軟硬體資源（Hardware and Software Resources）
MHP應該是有友好的用戶界面的。對於周邊設備來說，顯示設備、輸入設備如(遙控器)是必須的，另外可以選擇使用鍵盤，本地的內置或外置的存儲設備。而這些周邊設備的連線應該是“即插即用”的。
對於一台基於MHP的機頂盒來說，內部硬體資源包括：前端、解復用、解碼、濾波、通用接口、通訊接口、CA系統、記憶體和相關的驅動等。
要實現目前DVB的標準功能，需要機頂盒有至少1MB快閃記憶體和1MB記憶體，同時需要CPU的速度達到20MIPS。如果有16MB快閃記憶體和32MB記憶體及100MIPS的CPU的話，就能做到遊刃有餘。硬體資源可特別分配，如指定70%的CPU處理時間用於運行應用程式，而餘下的30%的時間用於系統管理。
在記憶體中存儲了如下內容：
· API的解釋器；
· 庫函式；
· 實時引擎和虛擬器；
· 自舉(Loader)；
· 系統工具；
· 檔案系統；
· 固件(firmware)；
· 作業系統(包括啟動、記憶體管理、任務管理、資源管理、時針等)；
· 驅動；
· 導航系統。
在快閃記憶體中允許下載多個版本的應用程式。同時對記憶體的管理也是相當靈活的，採用分塊管理，用於不同程式的記憶體段有不同的標識，可以只對某一記憶體段的程式進行刷新。
由DSM-CC循環傳送下來的應用程式存儲在RAM中，同時RAM可用於存儲視音頻解碼的數據緩衝，用於動態平台管理(如堆疊、過程排隊等)，用於存儲應用程式中用到的變數。
最基本的系統設定和出廠設定通常存儲在EEPROM中(一般不超過10KB)。
套用層次
MHP把所有的互動作用按照套用領域劃分成三個層次：增強廣播，互動廣播和Internet訪問。
（1）Internet訪問
該層次是互動廣播的超集，它提供了網際網路服務（E-mail,Web瀏覽和chat等）。
（2）增強廣播
該層次的套用不需要回傳信道，只需下載套用後，在本地與視音頻實現互動；
（3）互動廣播
該層次是增強廣播的超集，套用需要回傳信道，能夠實現真正的互動；
MHP系統基本結構
（1）傳輸協定（DSM-CC Object Carousel, DVB Object Carousel 和IP等）；
（2）內容格式
關鍵技術
Java TV API是基於Personal Java套用環境的應用程式接口，是Java平台面向 MHP終端的擴展，它提供了對MHP終端特有功能的控制，包括對業務信息資料庫的訪問、業務選擇、TV上的媒體播放器控制等。Java TV API是針對終端媒體及接收功能的，不包括其他電子設備共有的API。由於Java TV API是獨立於硬體和物理線纜傳輸協定的更抽象的高層協定，因此也可以在一些現存的標準中使用。此外，MHP終端中各種套用的生命周期由Java TV API的Xlet套用模型定義。Xlet運行時可以進行資源的申請和釋放，顯示內容的存取、發現和選擇業務。
存在問題
在MHP中，幾種不同類型的程式包交織在一起成為一個混合體，主要的程式包有pJava、 DAVIC、DVB、 JavaTV和Havi等。Personal Java標準包是由Sun公司定義的基於pJava 1.1.8的標準包。DVB是由DVB/MHP技術委員會提供的程式包，它主要是對DAVIC 程式包及一些Java標準包的補充。在這些程式包中，有不少存在著嚴重的設計缺陷。例如，相對於 DAVIC/DVB程式包而言，JavaTV程式包的作用並不大。JavaTV程式包主要由JavaTV Consortium提供，Sun系統公司掌握著其智慧財產權，其內容幾乎含蓋所有的DAVIC和DVB程式包，但它並沒有一個明顯的資源管理模式，如果幾個應用程式同時需要同一個資源時，不同的實現模型便會有不同的結果。
Havi圖形包也有其缺陷，它建立在java.awt基礎之上，可利用AWT的 lightweight component重建一套與AWT一樣的二維圖形widget體系。但由於它不能完全取代AWT，因而造成了兩種圖形包共存的局面。另外，DVB-HTML標準也不是很成功。在MHP標準的形成過程中，對HTML的定義也一直存在著激烈的爭論。
在MHP中存在的種種問題已為人們所認識，它的1.0更正版（1.0.1）就提出1000多條修改和重建程式包的意見，而且其測試程式包也遲遲不能完成，這些都說明了其繁雜的程度 。
當然，DVB/MHP也有不少可取之處，主要有兩點：一是應用程式下載後的標識和運行模式；二是套用數據認證，以及機頂盒內部資源的許可權管理和X.509認證書的套用，這使得它與目前網際網路傳輸數據的認證取得一致。
向MHP遷移及未來的前景
向MHP遷移的過程是整個機頂盒軟體系統向通用MHP系統遷移的過程，重點在於API。DVB-MHP的說法是：“只有當服務商開始提供與MHP兼容的解決方案時，移植過程才算正式開始。”
DVB標準機頂盒已經採用了許多通用標準，包括調製、復用、MPEG-2視音頻、DSM-CC UU接口和協定、通用接口(用於針對條件接收和其他套用)，以及DVB-SI。
然而，不同的系統在很多地方存在不同的格式：
· 組合應用程式腳本和源碼、數據和內容的方式；
· 解壓縮工具；
· 記憶體分配和管理(應用程式排隊機制和垃圾收集機制)；
· 進程型函式格式；
· 庫函式(進程型函式擴展、圖形)；
· 數據環或其他循環數據傳送機制；
· 下載過程和工具；
· 互動機制；
· 變數格式；
· 加密格式。
DVB要求在多服務提供商或多應用程式環境中，基於MHP的解決方案應該是數據可分離的。這就保證只要是通過認證的應用程式，採用通用數據格式，它們之間能利用相同的數據，特別是運用不同的應用程式完成相同任務，而為特定的應用程式保存部分數據也是能夠實現的。
從系統層面上看，應該仔細考慮如何實施遷移以便充分利用DVB-TAM的API。這將有助於機頂盒的可移植性和機動性。特別是對於數字地面廣播來說，面對水平零售市場，如果增加內容是有限的，用戶不願意投資購買多個機頂盒。
遷移的過程可能不會一帆風順，需要處理好與現有使用平台兼容性的關係。
通用API的廣泛使用將帶來廣闊的前景，給服務提供商的經營和運作帶來顯著的變化。為了適應不同的平台套用，在運用通用API時，一般應遵循以下規則：
· 應該採用相同的數據環對象格式，在廣播流中傳輸這些對象也應該套用相同的機制。
· 應該採用通用的壓縮方式。
· 應用程式必須是可下載的，在應用程式未被激活時，不需要依靠永久存儲設備。
· 通用庫函式(進程型擴展、圖形等)和駐留程式應該是內嵌的以縮減程式的大小。
· 應用程式、數據和解釋接口應該根據通用方案組織。
· 應該採用相同的啟動和結束應用程式進程的方式。
MHP平台將不停發展，來支持越來越多靈活的、複雜的應用程式。這就需要對API進行更多的擴展。未來的方向是加大這些系統部件和進程的通用性，這將提高系統的性價比，並能有效延長設備的使用周期。
套用實例
目前，世界上流行的數位電視中間件產品主要有: Canal+ MediaHighway ；OpenTV；NDS等。而國內從事數位電視開發的公司也積極推出自己的產品，如深圳迪科是國內較早進入互動電視領域的公司，目前在市場上已有一席之地；天柏寬網與國外廠商合作，推出了基於Java的中間件產品，其技術水平同步於國外先進水平。現試取較典型的產品進行分析。
（1）Canal+ MediaHighway
Canal+ Technologies的定位既是運營商又是系統集成商，提供除前端設備以外的軟體產品，包括：CA(MediaGuard)；中間件(MediaHighway)以及套用軟體，包括機頂盒開機界面(Mediastart)、頻道列表、遊戲、EPG、股票信息、HTML廣播等；開發工具(Studio+)。由於作為運營商，積累了大量經驗，這對解決系統在涉及運行中出現的問題很有幫助。
Canal+有20多個網路，但由於系統全線採用自己的產品，開放性較差。
（2）OpenTV系統
OpenTV是世界上運用最多的互動電視解決方案之一，銷售到世界各地的數位電視接收機中有930多萬台安裝了OpenTV的系統軟體。到目前為止，OpenTV的軟體方案已經被世界上的30家電視網路所使用。其中包括英國空中廣播(BSkyB)、法國的TPS、美國的EchoStar的DISH網路。OpenTV是數字視頻廣播(DVB)項目組的成員，並且擁有Sun公司的Personal Java™ 的使用許可。
OpenTV系統為創作和傳送可下載的互動式套用提供了工具，這些互動式套用包括電子節目嚮導(EPG)，家庭購物、家庭銀行、股市行情、電子郵件、互動式廣告和遊戲。使用OpenTV軟體，觀看現場直播體育比賽的電視觀眾能及時獲取其他賽場上當時的統計數字和得分情況，而不需要等待電視台來向觀眾提供這些信息。這些套用都可以通過遙控來實現，而並不需要鍵盤。
OpenTV也提供了用於創建、廣播和接受互動式電視業務的端到端的產品系列，包括軟體開發包(SDK) 是一個強有力的創作工具包，讓掌握C編程的開發人員可以在NT或者Solaris系統下使用包括編譯器、流調試器、編輯器在內的一整套開發工具來開發電子節目單程式或其他的互動電視應用程式。OpenAuthor針對非編程人員。它是一種基於GUI(圖形用戶界面)的拖曳式開發環境，給互動式工具和套用的開發提供了模板及可擴展的結構。OpenTV STUDIO是集成的互動式套用開發工具，包括OpenAuthor和SDK。在廣播前端系統中，OpenStreamer能實現實時廣播數據流的更新，使得股市行情、體育比賽及時報導以及類似的一些套用可以在次秒量級上更新數據。可以說OpenTV的作業系統/運行環境為互動數位電視提供了較為完整的系統解決方案。
