CN1139035C - 电子消费者设备的任务驱动控制系统 - Google Patents

Abstract

一种控制系统包括多个消费者电子设备及耦合在设备上的用于控制设备之间的交互作用的任务驱动的控制装置。该控制装置按各对应的消费者设备的各自的软件表示工作。至少将一个软件表示从对应的消费者设备上下载到控制装置上。通过将任务的可变的复杂性封装在软件表示中，便能根据需要简单或完善地将能力提高到共同的水平上。由于界面水平对于设备是共同的，应用便能统一地操纵体现非常不同的复杂水平的设备。

Description

电子消费者设备的任务驱动 控制系统

本发明涉及具有空间分布式信息处理功能的系统。本发明尤其是但不仅是涉及多媒体消费者系统。

随着娱乐系统从模拟领域进入数字领域，消费者电子工业正在开始巨大的转变。音响已随着诸如紧致盘及数字紧致盒式磁带的发展进入数字领域，在以后数年内影象也将快速进入数字领域。由于给人以深刻印象的数字处理能力正在以负担得起的价格上市，一种带数字音响及数字影象的全数字多媒体系统开始了面向消费者的新的可能性。下面举出这些新的可能性中的少许：实时视频处理已进入消费者装置可及的范围；消费者控制越来越多地依赖于系统的智能，从而使系统操作起来大为简化并解除了消费者监视系统的麻烦；多数字资源正在互相关联与集成到单一的家庭系统中。

本发明人意识到如果系统设计支持系统功能的分布、体系结构的伸缩性及闭环控制，则将不断增加数量的可能的交互作用功能集成到单一的系统中对于消费者与制造商都是有吸引力的。带有分布式功能的系统在系统部件之一中的硬件故障不一定影响其它部件这一意义上讲是能容忍故障的。功能分布还支持伸缩性。体系结构如果允许系统的无冲突的重新配置、升级或扩展便是可伸缩的或开放的。通过增加或去掉功能来与需求匹配，制造商或消费者便能优化系统性能同时降低成本。闭环控制意味着部件响应来自另一部件或消费者的激励，确认收到该激励。以这一方式，系统作为一个整体能跟踪其各部件的状态。

本发明的目的为提供具有分布式功能的系统。另一目的提供具有开放体系结构的控制系统。

为达到这目的，本发明提供了包括通过用于控制电子设备之间的交互作用的任务驱动的控制装置互连的多个电子设备的控制系统。控制装置作用在各个相应的设备的各自的软件表示上。最好，至少一个特定的电子设备例如在连接到控制装置上时将其相应的软件表示下载到控制装置上。最好，各相应的软件表示包括以对这些表示共同的语义级上表示该相应设备的设备抽象，并且至少一个特定的相应软件表示包括对该设备抽象的消费者界面的应用，该应用是在控制装置上运行的。

为了更具体，本发明在消费者电子设备领域内提供了包括通过用于控制电子设备之间的交互作用的任务驱动的控制系统互连的多个消费者电子设备(诸如电视接收机、VCR、CD播放机、DVD设备、还有电话机、照明控制系统、恒温器，甚至PC等)的控制系统。控制装置作用在各相应的消费者设备的各自的软件表示上。

转换到数字内容与媒体在发行质量与方便性上带来多种改进的同时，本发明还提供了在设备如何互相交互作用方面提供智能的机会，并且它向消费者提供系统级完整性特征。它使得提供对设备簇的真正的容易使用及全系统控制成为可能。本发明容许真正的即插即用。本发明允许设备自动配置自己，在系统的范围内发挥它们的最佳性能。为了达到这些高度希望的目的，设备必须互相协作，即，在它们之间共用一种共同的通信及消息交换方法，以便“说同一语言”。这一共同语言在消费者与(有可能多种)低级协议之间架起桥梁。共同语言至少包括三个不同方面的解决方案：消费者界面、设备抽象及通信。它既为消费者界面也为设备抽象、应用及系统服务(如通讯、注册及发现)提供标准化的执行环境，并为将这一环境通过诸如即插即用或其它装置动态延伸提供通信机制。

控制装置在其上操作的软件表示隐藏了实际消费者设备中相关的一个的特异性。软件表示为更高级的软件提供更统一的界面，类似于操作系统中的设备驱动程序。通过将任务的可变复杂性包装在软件表示中，便能如要求的那样简单与完善地将能力带到共同的水平上。由于界面级对于软件表示是共同的，应用便能以相同的方式操纵体现非常不同的复杂程度的实际设备。至于消费者界面方面，这些已成为任务驱动的，而与传统方法中的设备驱动特征相反。由于软件表示所提供的在共同层次上的统一性，消费者界面已成为可定制的及可扩展的。

实际消费者设备的这一软件表示提供了支持甚至尚未知道的设备及支持新的及各种基础网络协议及标准的能力。按照本发明的系统的总体目标是成为家庭环境的完整的解决方案。为了达到这一点，系统的协议必须定义消费者界面约定、设备抽象及连网协议以便即使尚待建立的设备能对最终消费者提供有价值的完整的端对端解决方案。本发明人认为建立达到这一目标的技术的先前的成果尚未受到很好的接受，只是因为它们只增加设备成本而不产生消费者看得见的好处。通过提供全面的解决方案，消费者将见到其好处与价值，而工业能再一次前进并在新的平台上革新。

本发明尤其与家庭娱乐环境中的消费者电子设备相关，但不仅限于此。例如，与日俱增地受到面向全数字控制与模块化体系结构的趋势的影响的技术领域的例子便是汽车应用。汽车制造商与供应工业正在将更多的努力放在允许在承受得起的价格上加入功能完善的数字控制系统上：电子控制仪表、防抱死刹车系统、电子燃料喷射、电子马达管理及排放控制、电子气候控制、自适应自动变速、汽车音响设备、导航设备等。这些功能具有完全不同的复杂性及操作类型。如果在组装线上，所安装的模块其功能互连取决于通过本发明所提出的软件表示的控制，则制造相当地简化。制造商对于电子设备不需要为各种选项的不同组合作出特殊的保留。此外，这些模块化子系统之间的交互作用在更高的层次上带来汽车的消费者友好性及高效率。

作为例子，音响设备的音量是根据测定的路速(风噪音)、引擎速度(引擎噪音)及气候控制的活动级(风扇噪音)控制的。作为另一例子，为了在需要较多或较少细节来引导司机时能够放大或缩小，使图形导航设备(诸如Philips电子公司的CARIN系统)能够根据测定的路速来控制。作为又另一例子，马达管理及自适应自动变速子系统是根据载重(通过灵敏悬挂装置测定的)细调的。

从而，为了消费者与制造商的利益，本发明提供了在单一系统中组合极为不同的功能的协议。

参照附图以示例方式更详细地说明本发明，附图中：

图1为按照本发明的带有消费者设备的系统方框图；以及

图2为图1所示的系统中D类设备的方框图。

在所有的图中，相同的参照数字表示类似的或对应的特征。应指出这些图将本发明的特征作为实现在软件中的独立项目表示。因此应相应地解释这些图。

系统硬件配置

图1为按照本发明的控制系统100的方框图。系统100包括多个消费者电子设备102、104、106、108、110、……及112。在所示的例子中，系统100还包括一个或多个控制装置，如控制装置114及116。设备102-108连接在控制装置114上。设备110及112连接到控制装置116上。控制装置114与116是互连的。下面更详细地讨论的系统100及其协议通过控制设备102-112的功能模式，提供控制信息数据的路由及处理的基础结构。控制数据控制设备102-112对诸如音频及视频信息等信息数据的处理。控制装置114与116也互相耦合。下面说明系统100的控制。控制是由具有可从各连接在其上的设备可以使用的软件表示的控制装置114及116启动的。

为了理解系统100的操作及多方面特征，首先讨论消费者电子设备102-112的通信能力的分类。虽然现实中存在着比这里所确认的设备能力更平滑的连续体，这一分类在理解系统100的模型中是非常有用的。这一通用实例中的设备102-112的通信能力具有不同级别的复杂性。取决于它们的通信能力，设备102-112属于下列各类之一：

类A：带有受限制的单向控制的传统设备；

类B：带有传统双向控制的可控制设备；

类C：带有编码的消费者界面抽象及设备抽象的智能设备；

类D：能为从类C设备下载的抽象提供执行环境的有知觉的设备。

类A：传统设备

设备102为属于传统消费者设备类A的设备。传统设备的控制功能局限于单向(未确认或未认可的)控制。传统设备的典型实例为由通过手持遥控器的红外线命令控制的良好安置的音频/视频设备。确认机制依赖于观察设备所执行的命令(频道改变、磁带开始播放等)的消费者。没有确认协议来向遥控器发布回已接收到第一命令的返回命令。设备102不能返回命令、报告状态或出错情况等。除了认为传输给传统设备102的命令是‘成功的’以外，系统100中的协议别无选择，并且在试图改变设备102的状态之前无法确定其状态。对于‘状态翻转开头’或者实现象‘电源开/关’或‘频道上升’等相对状态变化的命令，这是一个特殊的问题。为此，传统设备102只能在‘尽力尝试’的基础上得到支持。确定了落入传统设备类别中的设备的现有结构基础，必须尽可能好地加以支持。然而，应清楚升级到带有更好的通信支持的设备具有很大的收益。

类A设备可通过代理间接控制，诸如通过代理118控制设备102。例如，设备是当前由红外线发射器118控制的传统电视机，而118是通过类D设备114控制的。

类B：可控制设备

设备104属于可控制的消费者设备类B。存在着一些‘双向’协议来控制消费者电子设备，它们提供命令执行的确认、状态及出错报告。不幸的是，在消费者产品中它们很少有共同之处。这些协议是典型的‘全枚举的’协议，在于它们已经被完全定义并且提供很少或不支持以向前兼容的方式的协议的扩充。由于这一‘先验知识’要求，控制设备与受控设备必须存在于协议的范围内，并且由于‘先有鸡还是先有蛋’问题(增强受控设备而现有的控制器不能利用这些增强，或反过来)而抑制了创新。消费者电子工业已在这一类协议中投入了相当的力量。这些协议的例子有A/V CTS、Philips EasyLink/ESI及D2B、Sony的Control-L、LANC及S-Link/Control-A、CEBus/CAL、LonWorks等。

系统100及其控制协议用这一类可控制设备提供更先进的消费者经验。但是，系统100仍必须具有‘先验知识’。所使用的协议必须预装设有适当的支持，或者必须采用某种不透明的机制来装设对新设备与/或协议增强的支持。读过下面的下一类设备的定义之后，这一区别将更清楚。

和类A设备一样，类B设备必须通过代理(未示出在图1的实例中)控制。

类C：智能设备

设备106、108、110及112属于智能型的消费者设备类。设备106-112各提供向前兼容的‘即插即用’功能。主要是，各设备106-112包含一软件表示：一可选的消费者界面(见下面‘Applet’部分中)及一设备抽象(见下面‘抽象设备’部分中)，两者都编译成独立于机器的字节代码。已在各设备106-112的原来的协议上增加了简单的扩充以便另一设备能检测到它及检索编译的字节代码。该另一设备这时便能在本机上执行该字节代码并提供对设备106-112的控制。最好，下载的设备抽象与实际设备之间所使用的通信协议是专用的。系统100中的控制协议定义发现与下载协议，并为下载的字节代码提供执行环境。它还定义(按照惯例)给定类型的设备(如‘VCR’)的设备抽象应实现的核心功能集，以便第三方应用能利用该设备的能力。然而，已经回避了“先有鸡还是先有蛋”增强问题。由于已经与设备抽象一起下载了消费者界面，它们便能在核心功能集上实现增强以及超过该核心功能集，并且可不修订标准及处理‘已过时’的结构基础便能产生‘事实上的’标准。这一‘按照惯例定义’是计算工业与消费者电子设备工业的工作方式之间的巨大差别之一。它允许快速创新并且是商业与技术‘达尔文主义’的一种形式。

类D：有知觉的设备

在本例中，控制装置114及116属于有知觉的消费者设备类。有知觉的设备114及116为从类C设备106-112下载的字节代码提供执行环境。设备114及116可具有能支持从设备106-112下载的字节代码的消费者界面部分的消费者界面。类D设备114-116在松散地耦合的分布式系统中作为对等者互相通信。系统100中的通信协议的目标之一为能在家中分散控制(与PC为中心的集中控制、哑外围设备相对)，而无须在所有参加的设备上增加沉重的费用负担。在考虑的家庭模型中，存在着设备的‘簇’。智能是在一定程度上在簇内集中的，不会危及作为整体的系统100的分布式性质，并且不排除在这些系统的未来的代中更大程度的分散性。类D设备114及116通常包含比传统消费者电子设备的特征更多的智能及计算资源。然而，类D设备114-116比‘PC/TV’类设备通常具有少得多的资源，并在计算能力上表明更典型地类似于网络计算机(NC)。

注意类D设备114及116本身也可设置有消费者装置功能。

设备之间的交互作用

对类A设备102或类B设备104的支持要求在类D设备114或116中已存在它的设备抽象。措词‘需要先验知识’用来表示类D设备114或116不能支持新类型的类A设备102及类B设备104的向前兼容性及透明的热即插即用。注意并不从支持类B设备可能提供的任何‘即插即用’特征中排除设备抽象，诸如A/V CTS/P1394设备的‘装置信息(UnitInfo)’能力。本发明人认为这里所用的是作为‘自配置’的较低目标而不是在更狭义的特定意义上的真实的‘即插即用’。新的类C设备可以完全不为类D设备114或116所知，而将其集成进系统100中的过程除了物理上连接电缆之外不需要消费者参预。在这一意义上，类C设备及类D设备的组合所提供的‘即插即用’功能旨在提供的不只是前面知道的设备类型的自配置而是向前兼容性、自安装功能。

通过从新发现的类C设备传送字节代码及用它来扩展类D设备114或116内的环境便有可能达到这一真正的‘即插即用’。通过在字节代码中将消费者界面部分从设备抽象部分清楚地分开，并建立可按照惯例扩展的API(应用程序接口)，本发明人已建立了第三方也可在平台上增加功能的环境。例如，公司可建立支持‘VCR’核心API的视频编辑包，而在设备抽象支持‘编辑VCR’扩展时(可能是时间码支持、帧精确定位、预滚动等)增加功能。消费者界面、设备抽象及通信的分离允许对这些不同的问题以不同的步幅改进的解决方案，并允许有些问题的较先进的解决方案与对其它问题的较原始的解决方案并存。通过提供对大量公共问题的解决，方便与简化了对设备进行开发以对体系结构予以支持，借此降低制造商必须克服的应用上的障碍。

理解下载机制如何工作的另一重要概念为‘线团与线’连接模型。一旦将字节代码从诸如设备108等类C设备下载到了诸如设备114等类D设备，代码便被实例化而‘醒过来’，不知道它如何到达那里或者如何返回去与它来自的设备108通信。从而，实例化下载的字节代码的子系统的责任也是通知它从其下载的设备108的设备地址以与其进行通信，即允许它跨越通信介质找到返回到它所代表的设备的道路的‘线’。

对于给定的通信机构，在设备控制中可使用标准协议，例如用于P1394的A/VC。为了保持下载的字节代码短小起见，各所支持的用于下载的通信协议最好还定义支持适合于下载的设备抽象可影响的通信机构的控制协议的设备服务。

抽象设备与附属程序(Applet)。

图2为更详细地示出在诸如设备108等类C设备与诸如设备114等类D设备的交互作用中所涉及的软件功能。

对于带消费者功能的各实际设备102-116，存在着称作‘抽象设备’的设备抽象。图2示出从类C实际设备108下载到类D设备114的抽象设备202。抽象设备202负有将其接收的命令报文(见下面)翻译成它所代表的实际设备108上的动作。抽象设备202还负有作为事件报文(见下面)报告实际设备108中的状态改变的责任。

抽象设备隐藏实际设备的特异性并为高层软件提供比较一致的界面，类似于操作系统中的设备驱动程序。通过将任务的各种复杂性包装在设备抽象内，便能如要求那样简单或完善地将各种能力带到共同的层次上。由于界面的层次对于设备是共同的，应用便能以相同的方式操纵体现非常不同的复杂程度的设备。

抽象设备的消费者界面称作‘设备应用’或附属程序(‘Applet’)，或者在本文中只称作‘应用’。图2示出抽象设备202的附属程序204。附属程序可从相关的类C设备下载，或者可以已驻留在类D设备上。附属程序在与系统100交互作用的消费者正在使用的类D设备114或116上运行。附属程序可以不在正在接收该抽象设备的同一类D设备上运行。例如，由类D设备114接收的设备108的抽象设备的附属程序可在类D设备116上运行。这可能是在类D设备114没有诸如显示器等装置来支持需要图形消费者界面的设备108的附属程序的情况，而类D设备116的确拥有其自己的显示器或的确具有对带有显示器的诸如类C设备110的设备的直接访问。为此，附属程序通过报文发送系统与抽象设备通信，以便使抽象设备的实际位置对附属程序透明。更详细的细节见下面的‘报文发送’。还有用来以它们的属性定位抽象设备的注册处。更详细的内容见下面‘注册处’部分。在图2的实例中，Applet 204与诸如控制装置114的消费者界面206接口。

服务

系统100在全系统基础上提供多种服务。其中之一为设备的注册/注销，另一种为抽象设备与附属程序之间的报文传送以便允许将它们定位在不同的类D设备上而不要求它们有不同的表现。换言之，当位于同一类D设备中时，抽象设备也通过报文传送与附属程序通信。

图1的实例中设备114与116的执行环境提供‘注册’设施，对象能用它注册，从而以标准方式通报它们自己。在注册时对象提供若干属性值，然后其它对象便能通过执行‘按属性查询’找到它。一旦定位，便通过报文传送系统与该对象通信。这能使对象的实际位置透明，允许在一台设备中运行的附属程序以本机资源相同的方式控制另一设备提供的某些资源。通信协议利用‘事件’(根据它们此前声明的‘关注’发送给多个收件人的报文)来发布关于设备状态的重大改变的信息，并且它提供标准化的事件管理程序来支持想要通知系统的对象及对接到通知感兴趣的对象两者。下面更详细地讨论这些概念。

注册处

各类D设备114与116设备有注册处，在图2中，例如设备114设置有注册处208。注册处208在全系统的基础上用它们的属性提供服务以定位诸如抽象设备202等抽象设备，抽象设备以标准的方式向注册处208注册并从而通报它们自己。注册处208向可代表抽象设备接收报文的对象返回一个引用，这不应认为是对抽象设备本身的引用。即使抽象设备是本地的，在该引用的实现中它也永远不是。

注册处208为能接收报文的对象提供用于注册、注销与查询的API。它可用于向整个系统100提供服务的任何报文接收资源。它是旨在用在存在单一的全系统的实例及希望使该实例的实际位置透明时用于抽象设备及类似对象的(如下所见的单个事件管理程序)。

注册一个资源需要用于以注册实体名义接收报文的抽象设备或对象的一组属性及引用。注销需要将同一引用提供给接收报文的抽象设备或对象。

查询包含提供一部分属性组来匹配潜在的注册项目。还能将查询指定为‘只是本地的’。这样做的原因在于注册处可能必须与远程类D设备上的其它注册处通信，并可能为与远程抽象设备通信建立并不使用的‘代理’邮箱。

传送报文

附属程序与抽象设备之间的接口称作抽象设备接口(ADI)。基于单纯的传送报文，允许附属程序与抽象设备位于不同的类D设备上但不要求它们表现不同。换言之，附属程序与抽象设备总是通过传送报文通信，即使它们位于同一类D设备上时也一样。

报文是由目的地实例上的称作‘发送报文’方法传递的。有可能通过使每一个的‘发送报文’方法调用链中的下一对象上的‘发送报文’方法而‘堆积’报文处理抽象设备或对象。以这一方式，通过菊花链接简单的单功能报文处理对象来高效地执行任何复杂的处理，这是事件管理程序(见下面)广泛地采用的。

为了在类D设备之间传送报文，注册处建立‘远程邮箱’对象，该对象负责‘压扁’(flattening)(或‘串行化’)报文、寻址并将它们发送到远程机器，在那里注册处再一次重建(‘膨胀’)报文，并将其投递到真正的收件人。

‘发送报文’方法的实现必须执行得很快以便保持系统的性能及响应性。对于不能立即发生处理或可能要占用一定时间的情况，可利用‘排队邮箱’类。这将报文放在内部队列中，而分开的线程取出报文来投送它们。这将报文发送者与报文接收者分离，从而接收者能自由利用所需的时间来处理各报文。通常，系统100中有三类报文：命令、事件及出错。

命令

它们通常从一个附属程序流向一个抽象设备。它是执行某一动作的请求或查询某种状态信息，它只启动一个操作。操作的成功或失败是在某一稍后时刻作为另一报文发送的。

事件

事件是响应命令间接地或由于在一个或多个设备102-116上的某种外部条件(例如，消费者插入磁带)而异步地生成的。这一机制通常用于保持附属程序知道关于系统100中发生的事情。事件是‘多信道广播’的并可由系统100中任何地方的设备102-116中任何有关一方接收。支持多个Applet同时观察同一抽象设备是重要的。一个消费者的动作的后果应尽可能快地反映在各Applet的消费者界面中。

出错

出错通常是试图执行命令的后果，虽然它们可以不是。很可能是由于对另一类D设备的网络链路故障，而将一个错误广播到任何感兴趣者，见上面的‘事件’。在发送及执行命令中可能出现故障的任何阶段，如果命令不能进一步进行便可生成与返回出错报文。错误中包含在故障点上生成的关于故障的重大信息是重要的。否则，在诸如系统100等分布式系统中非常难于诊断问题，尤其是对于最终消费者。

出错在许多方面类似于事件，但一种差别特别重要。当响应命文报文生成出错报文时，直接将它发送回命令的始发者，并且还为了设备102-116中其它感兴趣方面的利益而广播它。将其直接发送给始发者必须保证始发者见到对命令的应答，即使他并未表示对这类报文感兴趣。同时参见下面同步传送报文的讨论。

同步传送报文

发送命令报文只启动操作。只有在某一稍后的时刻上返回应答报文时操作才完成。在这一意义上，系统根据其真实本质是真正异步的，并且在发布命令报文与接收应答的出错或事件之间可能存在长的(本质上可变的)时段。虽然异步传送报文对于环境是适当的，并且强烈地鼓励使用它，但它偏离了更常见的代码的线性执行路径。为了提供‘同步’传送报文的方便，即发送报文及等待到能返回应答，定义了一种服务，它维护挂起的执行路径直到接收到来自目的地的应答。为了支持这一服务，各命令报文印上全系统唯一的序列ID，将该ID传递给作为该命令报文的结果而建立的事件或出错报文，尤其是能将其标识为对该报文的应答。同步传送报文服务利用外出命令的序列ID来滤过进入的应答，并因此能识别对命令的第一次应答及将它作为结果返回给主叫者，使进程同步而不在整个系统上强制同步性。

事件管理程序

各类D设备(如设备114)具有如210的事件管理程序。事件管理程序建立在报文传送系统之上来分配整个系统100中的事件。抽象设备用它来报告重大状态改变事件，但一些其它子系统也用它来报告具有全系统重要性的事件，诸如检测到另一类D设备。在其中心为一专用的‘一对多’邮箱，它取出单一的报文并将其投送给潜在的大量接收者。各接收者很可能是一个或多个链接在一起的过滤器，它们将最终接收者不感兴趣的报文丢弃。

特别值得提出一种情况，各远程类D设备具有附着的过滤器，它只通过本地始发的报文，该过滤器依次附着在指向远程类D事件管理程序的输入。以这一方式，将本地事件广播给所有远程类D设备，后者又各自依次广播其本地事件。这些过滤器/邮箱对是在事件管理程序接收到检测到新的远程类D设备的事件公告时自己增加上的(并在该类D设备消失及本地广播对应的事件时去掉)。

事件管理程序在注册处注册‘一对多’邮箱，从而其它远程事件管理程序可定位它及提交它们本地生成的事件。但对于正常使用，事件管理程序提供公用静态方法，以便能允许不用注册处查找与存储本地邮箱柄来发送事件。其它公用方法允许感兴趣方从‘一对多’邮箱的输出上附加(或去掉)另一邮箱。

事件管理程序还为了其它子系统的利益包含若干有用的报文处理类，如各种报文过滤类。

通信

交互作用协议内的通信覆盖网络或其它通信介质上的设备之间的数据交换。报文传送系统在需要将报文传送到不在同一设备上的目的地时，依靠高层通信服务。高层服务隐藏协议之间的差别，并提供统一的寻址方案。

设备抽象在与它们的物理设备通信时可具有更多协议特定的需求，并因此更有可能需要一组低层的与协议相关的通信服务的服务。

低层服务还负责检测及通知出现在网络上的新设备的环境。这触发类C下载过程，它们还提供网络设备消失时的指示。这对于标记远程引用为失去时效的是有用的，并防止在消费者界面中提供不再可利用的选项。

与协议无关的通信

报文传送系统依靠高层的与协议无关的通信服务来与其它类D设备上的报文传送系统通信。其它服务利用报文传送系统与其它设备上它们的同类通信。报文传送系统利用高层通信服务提供的统一寻址方案。这对于报文传送系统内的一致性是所希望的并且也是必要的，由于有些网络协议采用动态分配的网络ID，它们可以在运行中重新分配(例如，在增加设备时P1394这样做)。高级通信服务即使在ID改变时也维护提供给报文传送系统与物理网络地址之间的可靠映射。

与协议相关的通信

由于认为设备抽象与被抽象的设备之间的通信是专用的，实现者可自由选择对该通信合适的任何协议或机制。

设备抽象通常需要它们所代表的实际设备的通信的更多的与协议相关的控制。虽然它完全取决于类C设备的实现者，希望设备抽象将采用低层的与协议相关的通信服务来与其物理设备对话(而不是高层的面向报文的服务)，虽然特定的通信协议服务可为协议定义高于报文传送系统的需要的某些附加支持。

对于集成进类D设备中的不是单纯的控制器的设备也可存在设备抽象。期望这些设备抽象直接与适合于控制集成的功能的任何原来的设备驱动程序或0S服务打交道。

附加的与协议相关的服务

对于给定的通信机制，可有用在设备控制中的标准协议，例如用于A/VC的P1394。为了有利于保持下载的字节代码短小，建议用于下载的各受支持的通信协议还定义用于支持适用于该通信机制的控制协议的设备服务，这些设备服务是下载的设备抽象可利用的。注意这些服务必须是保持向后及向前兼容的，以保证设备的连续可协作性，即一旦定义，它们便不能明显地改动。

支持即插即用

在它们所负责的网络上识别出新设备时，低层通信服务便提供通知。对于其协议检测节点的插入或消除的这些网络，使用这一能力。对于其它网络，则定期发送广播报文，邀请新节点回答。新节点可选择发送广播消息宣称它们的可利用性，虽然由于对大多数协议广播通常不保证投送，在原始广播失败时，轮询广播提供捕捉设备的安全网。

程序包下载程序捕捉‘新设备’事件，它询问设备来判定它是否支持类C扩展。由于类C程序包下载的约定随协议变化，它加入与协议相关的服务的协议。如果类C程序包存在，并具有这一环境尚未见过的制造商/型号属性，或具有见过的属性的更新的版本，便检索该程序包。然后将其传递到程序包加载程序上，后者将该程序包内容集成进环境中。

信号路由选择(‘交换’)

系统100集中在消费者电子设备控制上，但一部分控制为建立受控制的设备之间的信号路由选择。这一机制旨在是通用与可扩展的。  ‘交换’服务允许封装专门知识及全局状态，并将其与系统中更通用的应用隔离。它还允许在宏指令(macro)内建立信号路由选择；而无须宏为其嵌入一个显式详细的配置，这可能在将来由于不同的资源分配而失败的(例如，同步信道分配)。

命名的路由

‘命名的路由’类似于‘预置’从源设备到目的地设备的特定信号路由及配置。路由包含在源设备、任何中间信号处理块与目的地设备之间的连接。它也可包含这些信号处理块的配置信息。

可将建立特定的‘命名的路由’的命令嵌入宏中，或与源设备与/或介质类型关联。例如，将DVD影碟插入DVD驱动器可能触发一个宏指令去建立称作‘DVD电影’的命名的路由。在该路由中，将MPEG-2数据流的路由选择到MPEG解码器，然后视频信息通过线路倍增器(1inedoubler)及音频信息通过DSP块，DSP块是为AC-3配置的。将CD插入DVD驱动器中可能触发‘CD音乐’，它将音频的路由选择为通过为音乐环绕模式配置的DSP块，并通过视频子系统进行在屏显示。

建立命名的路由

为了方便消费者，高度希望能隐藏大部分包含在媒体流的路由选择及处理中的复杂性。人们必须能够改变系统的选择。然而，在每一种可能的情况中要求总能作出正确选择的系统智能必须是有限的。为此，消费者必须能在给定硬件制约的可能程度上建立与编辑‘命名的路由’。消费者建立或修正的命名的路由应优先于预配置的或在它们之间自动选择交换时动态生成的路由。

信息格式

设备可以在不同格式之间转换信息(或信号)，其中有些格式优于其它格式。此外，将来会出现新的格式，方法必须处理它们及它们的转换。系统100中的协议将信息定义为‘不透明’的信息格式标识符，对它的唯一合法操作为测试相等性。对于各信息格式标识符，有其相关的‘质量指标’，其目的为使交换设备在需要转换时在将信息转换成的格式之间进行选择。例如，VCR既可具有合成的也可具有S-Video连接。如果要录制的信号原来是来自DSS的MPEG-2流，则必须进行转换使其能录制在模拟的VCR上。较佳的选择会是S-Video，且由于其质量指标较高，交换设备会选择它。

信息格式标识符为另一领域，其中按惯例的标准化比试图广义化问题或试图用穷举来达到解决更受欢迎。

信号处理

散布在设备中的各种处理块可能能沿信号路径进行类似的或等价的转换。有些可能提供比其它的更好质量的转换(一个好的实例便是3-D梳齿滤波器的改进的质量比2-D的好)。在任何情况中，高度希望使转换次数最少。

因此，除了为信息格式提供质量指标，系统100中的协议需要与各可能的转换关联的指标。例如，这一值是零与一之间的小数，而各潜在的路由是通过将沿该路由的各转换的值依次相乘而‘评分’的。得分最高的路由一定提供‘最完美’的路由(即信息劣化最小的路由)。

相关信息流的汇总

存在着将单一信息流编码或解码成多个信息流的时候，例如将单一的MPEG-2流解码成视频、多声道音频甚至字幕信息。例如，为了保持音频对视频的同步，保持这些流之间的关系可能是重要的。系统100的协议具有当它们分裂与组合时‘汇总’相关的流在一起来保持关系的机制。

各汇总作为构成该汇总的内容格式标识符的分层容器工作。当将单一的信息格式标识符‘分裂’时，便在同一位置中用包含新的信息格式标识符的子汇总来取代它。当将子汇总‘合并’成单一信息格式标识符时，出现逆过程。

动态分析

在提供了有效的源设备与有效的目的地设备时，本体系结构允许全自动的路由选择。它也支持预配置的路由及消费者建立的路由。消费者也可编辑动态建立的路由，将其转换成作为消费者建立的路由对待的更静态的表示。如果编辑了预配置的路由，它也为了选择的目的成为‘消费者建立的’路由。

命名的路由可包含动态与静态信息的组合。人们可静态地定义音频DSP块的源与目的地设备及环绕模式，而将其余部分留给动态路由选择过程。这种路由与家庭影院型控制器的预配置的路由相当相象，其中某些细节是已知的，但单个系统的功能与连通性需要一定的灵活性。例如，是否只能得到模拟音频或只有S/PDIF连接？是否存在AC-3信号？应将命名的路由视为可以部分地聚集的结构，而交换设备将试图‘填充空白区’以建立适用于当前条件的路由。

即使在只有预配置的及消费者建立的路由的系统中，也可提供在路由中进行选择的交换设备。交换设备在面对二义性时不能建立路由应认为是不能接受的。它利用信息格式标识符及转换的质量指标来‘评分’各种选项，并选择具有最高分的一种(即最低程度劣化信息的那一种)。

查询可能的源与目的地

消费者界面需要一旦识别出源设备以及可能的源设备便能向消费者提供在可能的目的地设备中选择的能力，以及提供一个目的地设备。在音频/视频环境中，前者对录制有用，而后者对视/听有用。

交换设备确定可获得的路由(加上它们的得分)并将它们返回给主叫者。它将消除只在信息格式转换上不同的等效路由，而选择具有最高分的路由。期望消费者界面用默认来选择具有最高分的路由，并鼓励按递降的分数次序显示其余的路由。

为目的地确定当前的源及反过来

希望具有某些命令来为目的地影响‘当前的’源(或反过来)，而不是明确的设备或转换。对于消费者，与在屏控制或硬按钮关联的‘提高音量’或‘降低音量’动作应影响当前负责用户所在位置的音量的设备。在考虑多室音频/视频系统的情况中，这对记录的宏指令尤其是正确的-并不是要改变原来录制宏指令的室中的音量，而是消费者当前自己所在的室中的音量。

交换设备负责将‘当前’源或目的地设备的报文转发给执行该功能的实际设备。它也能提供当前源或目的地设备的邮箱的引用。改变信息流的报文应发送给当前源设备(播放、频道上调、等)，意在影响信息显示的报文应发送给目的地设备(对比度、音量、等)。

信息源的控制

用于控制信息流的统一与连续的模型是所希望的。虽然源设备之间术语不同，基本的基础结构是相当通用的。利用不同数目的‘维度’(一可变长度矢量)来指定‘位置’能以通用方式操纵信息源。简单的调谐器表示单一维度，能从宽带介质中选择信道的维度。更复杂的例子是带有一个以上驱动器的大型CD机。第一维可以是驱动器，第二维为盘，第三维为道，第四维为索引标记，第五维为时间偏移量。这一例子更有趣，由于存在着其它可能有用的说明，诸如‘驱动器/盘/道/时间偏移量’，或只是‘盘’，这蕴含设备可选择哪一个驱动器、盘开始处的位置，对于为播放命令指定盘是有用的。

设备可支持多个矢量以允许不同的说明。对于各维，设备可指示该维能指定绝对的、相对的、或用于指定象‘二倍正常速度’等‘走带’类型控制的‘动作’。还指定了在将它表示给消费者时这一维度使用的名词。

非本机信号路由

交换设备参与最多的是本机类D设备内信息路由选择。当存在着在设备之间传送信息流的装置时，交换设备可协助将路由从连接在一台类D设备上的源确定到连接在另一台上的目的地上。也可能是所要求的信息转换只能在另一类D设备上完成的情况，因此即使两台设备都连接在同一类D设备上也可能出现非本机的路由选择。

这一过程是由包含源设备的类D设备上的交换设备启动的。源设备可以是也可以不是请求建立路由的同一设备。它确定它所具有的能在本机上建立的路由部分的选项，并沿它所选择的路由将其余的路由发送给下一类D设备。然后该设备也一样进行，直到到达目的地设备。最后的类D设备确定最高得分并将其返回给倒数紧挨着第二台类D设备，后者将其乘以它的最佳得分，并将其返回给它的前一设备，以此类推，直到到达始发的类D设备。这时始发的类D设备便具有了能到达目的地设备的不同路由的一种或多种得分。它选择最高得分的一种并发送认可来建立该路由。对于其它的，它发送撤消，因为可能已有资源被保留以便在认可时能够建立路由。

通知管理程序

通知管理程序为用于消费者环境内的异步通信的服务。

系统100中的‘应用’主要参与消费者与基础子系统的界面。这样，它们的主要考虑是贡献系统的总体消费者界面的一部分。

由于类C设备也可与设备抽象一起嵌入该设备的消费者界面，应用是以使总体系统的消费者界面的知识最小的方式编写的，并且下载的应用能无缝地与类D设备在表示其界面中使用的现有‘风格’结合。这是通过提供高层的面向语义的消费者界面元素的库来达到的，这些元素用平台特定的表示提供标准化的功能。以这一方式，制造商便能竞争与区分他们的类D产品，而不会使从类C设备下载的应用‘与众不同’。

提供消费者界面

应用可在类D设备之间移动，以便为位于远程类D设备上的抽象设备提供消费者界面。这允许类D设备是‘无头的’，即不提供消费者界面，并依赖于提供与消费者交互作用的界面的其它类D设备。

存在着组织类D设备所提供的环境内的单个应用的应用框架。由于环境很可能是受资源制约的(如一次只能有一个应用活跃)，应用框架将随着消费者航行通过消费者界面根据需要将它们实例化。

由于抽象设备在需要通知消费者问题时不能依赖于其要实例化的应用及拥有的消费者界面资源(诸如显示设备及输入方法)，便需要设置另一机制来允许它报告需要通知消费者或消费者干预的情况。这是由作为类D设备的服务的通知管理程序提供的。通知管理程序永远是活跃与可获得的，它可独立于当前活跃的应用在任何时间上显示报文给消费者。

构筑在通知管理程序上方的有出错报告管理程序，它是能解释出错报文并以一致的方式将其报告给消费者的应用服务。这一服务的用处在于保证一致地高标准将出错报告给消费者而不将提供它的整个负担加在应用上。查找系统的故障对于不习惯有条不紊地解决问题的非专业消费者来说是个经常的问题，对于这样的消费者，简明的、精确的及可理解的出错报文是至关重要的(较高技术性倾向的消费者也仍然赞赏这样做)。

Claims (12)

1.一种控制系统，包括通过用于控制各个设备之间的交互作用的任务驱动的控制装置而互连的多个电子设备，该控制装置按各个对应的设备的各自的软件表示进行工作，其中所述多个电子设备中至少一个电子设备包括用于在连接到所述控制装置上时将其软件表示下载到控制装置中的装置及该控制装置包括用于接收所下载的软件表示的装置。

2.如权利要求1中所要求的控制系统，其中该软件表示包括用于以对这些表示共同的语义级表示各自的设备的设备抽象。

3.如权利要求2中所要求的控制系统，其中该软件表示包括对设备抽象的消费者界面的应用及该控制装置可进行操作来执行该应用。

4.如权利要求1中所要求的控制系统，其中该软件表示包括经过编译的代码。

5.如权利要求1中所要求的控制系统，其中至少一个电子设备包括消费者电子设备。

6.供在权利要求1的系统中使用的控制装置，该控制装置包括用于接收来自至少一个电子装置的软件表示并能通过按在对应的设备的各自的软件表示工作而启动多个电子设备之间的交互作用的装置。

7.如权利要求6中所要求的控制装置，其中该软件表示包括经过编译的代码。

8.如权利要求6中所要求的控制装置，包括另一个消费电子设备。

9.供在权利要求1的系统中使用的电子设备，其中该电子设备包括用于将其本身的软件表示下载到控制装置使该控制装置通过按该软件表示工作而控制该电子设备的装置。

10.如权利要求9中所要求的电子设备，其中该软件表示包括经过编译的代码。

11.启动多个电子设备之间的交互作用的方法，该方法包括：

多个电子设备中的至少一个电子设备在连接到所述控制装置上时下载其自己的软件表示到控制装置上；

控制装置接收下载的软件表示；以及

控制装置通过按它们各自的软件表示工作而控制电子设备之间的交互作用。

12.如权利要求11中所要求的方法，其中该软件表示包括经过编译的代码。

Images