改變是一種蔓延的趨勢

雖然數位視訊業界在過去15年中已經歷了顯著的變化，不過現在所呈現的革新速度更是大幅超越以往。數位視訊格式日趨成熟並持續改進中，不僅加速了視訊服務傳輸模式和擴充供應點，而且收看視訊的裝置也越來越朝向可攜式發展。

使用者希望完全掌控他們的娛樂經驗，因而促使系統更加複雜化。線性的電視節目已無法繼續掌握閱聽群，使用者現在希望的是能夠完全掌握觀看電視、影片或其他視訊內容的時間、地點和步調。越來越多觀眾選擇一次觀看多項節目，利用諸如子母畫面和個人錄影機（personal video recorder；PVR），一次同時享受多重視訊經驗。

Linux開發環境

開放原始碼標準發展，已從根本上改變底層的作業系統和韌體元件。大多數晶片包括使用於機上盒（Set Top Box）的晶片，可整合於不同版本的Linux。晶片所使用的Linux核心也持續改變，最近主要是從2.4.x轉移到2.6.x，預期未來仍會發展與革新。

Linux本身在開發設計上也遭遇挑戰。Linux發行版數量非常多，包括uClinux、kernel.org和商業Linux都會是機上盒所採用Linux軟體的可能來源。不同的發行版，可能使Linux程式碼產生品質不一致的問題，進一步增加開發的混亂度和複雜度。

Linux也比較難以在一個受限的嵌入式環境進行「驗證」和執行。許多Linux新手並不清楚核心空間和使用者空間的作業。對於比較熟悉傳統即時作業系統（real-time operating system；RTOS）的機上盒開發廠商而言，Linux的除錯能力和非決定性時序（non-deterministic timing）都是新的挑戰。

矽晶挑戰

矽晶廠商為自己平台所提供的工具並非全屬於商業層級，在很多情形下，矽晶廠商所提供的作業系統，僅提供最低限度功能的基本軟體開發工具。儘管幾乎所有開發的程式碼，都將在核心空間執行，但大多數廠商並未提供核心模式除錯能力。再者，矽晶供應商所提供的許多驅動程式，並不能保護關鍵性的記憶體領域和具備適當的控制機制。

矽晶平台的複雜度超乎想像，通常需要訴諸強韌的程式碼來啟動功能。矽晶廠商提供的程式碼，大多僅具有「展示」品質，其用意是為了指導如何為晶片設計程式，而並非針對商業用途所開發。然而由於只有很少數的系統整合與開發廠商，有時間和專業能力重新編寫功能程式碼，因此更多的開發商為了節省時間和成本，只好仰賴廠商提供的展示碼。

《圖一　具有DVR功能的機上盒解碼器方塊圖 》 資料來源：ST

一般而言，廠商所提供的驅動程式僅有少數經過驗證。系統組態的小幅變更，例如從快閃記憶體啟動系統、從硬碟機啟動或USB效能調校等，往往會產生一些整合上的問題，而大幅增加軟體開發時間，因為在開發或整合週期的後期，很難對這些問題進行除錯。

雖然在開發週期的後期，發現一至二個競態條件（race condition）並非不尋常，但通常都需要等應用開發接近完成時，才會展開測試與驗證週期。此種效率不彰的情形相當普遍，因為開發廠商不知道如何減少或排除設備開發所涉及的複雜性。

《圖二　數位電視機上盒結構圖 》 資料來源：富士通（Fujitsu）

上市時程

市場調查研究機構Venture Development Corporation（VDC）在「嵌入式軟體策略市場情報」報告中指出，72％的專案從設計到導入量產，僅需不到12個月的時間，整體市場不允許漫長的開發週期，而專案也不能因廠商供應的低品質軟體而延誤。

事實上，整個軟體堆疊都可能出現導致專案延誤的原因。傳輸層不見得都值得信任，產品開發後期可能發現驅動程式競態條件，而矽晶和中介軟體堆疊問題則導致無法在早期針對資料處理效能需求建立確切的設定。若欠缺一個可靠的堆疊，開發者則無法模擬系統需求、或根據系統需求產生自動化測試組。上述挑戰表明系統開發商須在整合上訴諸一個更強韌的測試階段。

標準可協助降低風險

主要的數位視訊標準能否定案目前仍處未定之天。有一些新標準被採納，包括DVB-H、DVI和DOCSIS3等DVB家族；IPTV則完全處於變動狀態，業界才剛開始對此標準達成共識。不確定的標準轉移，也造成系統整合難度提高。

定義標準是整合相關業界的必要條件，也是讓業界廣泛接受的機構定義規則，用以計量、評估價值或品質。單憑權責機構本身是不夠的，標準的接受性和被採納的程度才是決定成敗的最重要因素。業界對於軟體標準的接受和採納，也是反映新標準適切性和創新能力的最重要指標。開放原始碼計畫，可以透過社群認同和專家的投入，有利於加速標準被廣泛採納。

評估機上盒軟體設計

可靠性和穩定性

使用者需求擴充、裝置複雜性增加、以及開放原始碼標準採納率提高，已讓機上盒開發策略的風險也跟著提升。

基底環境的變遷速度，讓開發者的應用軟體比較難以維持穩定且完善測試的狀態。由於機上盒的預期開發和產品生命週期相當短，這些多變的軟體堆疊、環境和標準，都增加機上盒開發者的風險因素。為了讓這些風險降到最低，機上盒開發者需要簡易的方法，以便測試快速變遷元件的整合性，因此穩定的軟體平台便相當重要。

《圖三　機上盒結構示意圖 》 資料來源：ST

在設計方法學方面，定型且工具化的除錯方法可以協助開發者進行單元測試，包括提供單元測試案例和辨識實體裝置特性，以及了解在設計驗證上應提供何種保護等。整體系統測試是最能改善的領域，系統效能與強韌性的早期驗證，則可以為整體時程節省數月的時間。

未滿足的整合需求

軟體和標準穩定性問題，以及上市時程需求等，讓系統整合成為開發者的最大障礙。機上盒系統設計的結果，形成一大堆廠商軟體和系統元件混雜在一起的情況，只能仰賴機上盒製造商或廠商提供的少量功能元件進行整合，大量且複雜的系統程式碼層層相疊，業者需要真正的方法進行完整的作業行為測試。

測試階段穩定性的解決方案

為協助機上盒開發者克服穩定性與整合挑戰，業者特別提供一個機上盒開放原始碼測試平台開發架構，亦即數位視訊穩定性測試平台（Digital Video Stability Test Platform；DVSTP）。

DVSTP採開放原始碼貢獻模式，這個建議測試平台支援建立架構獨立的（architecture-independent）程式庫。以C語言編寫的DVSTP獨立於任何數位電視平台，採納物件導向概念，可以輕易移植到其他數位電視硬體。它同時也具備作業系統獨立性，目前可在Linux和Wind River的VxWorks RTOS之上執行，也能支援Windows上的模擬環境。

《圖四　電視機上盒的子母畫面》

DVSTP可當成開發初期建立測試平台的一種方法，以供測試系統之間的互通性和執行低階系統測試。再者，它可以在開發主機上建立測試平台，以得出更精確的結果。該平台也支援於開發程序初期執行互通性測試，並且可在完整系統測試之前供確認時序和內部資料傳輸。

DVSTP是一個可供設計初期確認可靠性、效能與整合的樣板，該平台採用實際的應用程式碼產生測試紀錄，測試用的應用程式採用完整的相同圖形化使用者介面（GUI），確保使用者經驗成為測試的一部分。這些方法的設計目的，是為了改善開發者對於測試結果的信任；一如其他開放原始碼計畫，社群成員可以貢獻、使用和修改DVSTP，期望讓這個測試平台將能成為業界的效能標準基礎。

《圖五　機上盒單晶片iDTV處理器硬碟架構 》 資料來源：ST

平台構成元件

DVSTP以一種可延展且可重新組態的架構，提供除錯支援，應用在供疊放於半導體軟體開發工具之上。現有的程式庫包括ATSC、DVB SI、DVR等等，將隨著社群對DVSTP接受性和使用率的提高而擴充。該平台利用原生的（native）事件和緩衝區，而且不會為事件、socket或其他已存在API的單元建立新的API。

DVSTP的基層功能包括：

DVSTP支援模組或相關技術集合，模組擷取出基底的硬體架構，並為應用程式提供一致的API模型。API語意於硬體和軟體初始化期間施行，以確保一致性。

三種模組提供核心服務，包括事件（event）、緩衝器（buffer）和除錯（debug）。事件模組採先進先出（first in／first out；FIFO）方式建立和管理事件；緩衝器模組建立和管理系統的資料緩衝器和資料流；除錯模組支援每一模組的工具性除錯（instrumental debugging），並為模擬器建立系統輸出、以及為測試分析儀建立輸出。

效益

DVSTP是一種可延伸的設計，能夠輕易地支援開放原始碼社群所貢獻的額外模組。它能為社群提供一個基層的功能基礎，支援建立可移植的跨平台應用程式。DVSTP是一種可移植的模組化架構，透過一個硬體抽象層支援快速針對任何硬體平台建立組態和提供變更控制（change control）。DVSTP是一種平台獨立的可延展架構，可延伸以支援標準化或專屬性的中介軟體平台。（本文作者為美商Wind River Professional Services資深總監）