改变是一种蔓延的趋势

虽然数位视讯业界在过去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资深总监）