专利名称：提供诊断信息的广播接收器,数据结构和方法
技术领域：
本发明涉及内容广播技术，且更为具体地说涉及提供诊断信息的广播接收器，数据结构和方法。
背景技术：
总的来说，内容广播系统可包括广播站，其通过有线(例如，电话或电缆)或无线(例如，蜂窝或卫星)网络传送内容以及至少一个主机，例如广播接收器，其用于接收该内容。广播接收器可包括通信接口。其中广播接收器可以没有通信接口，为了和广播站接口连接，广播接收器可以采用通信卡。
在有线电视广播的情况下，有线电视广播站可以是系统操作器(SO)头端或多系统操作器(MSO)头端。SO可以是标准的有线广播提供商(例如，本地有线电视TV广播提供商)并且MSO可以是组合在一起的几个SO。
有线电视广播接收器可以是数字的内嵌TV，数字即用TV，等。有线电视广播接收器可以使用开放式有线电视系统也可以使用有线电视卡或包括条件接入(CA)系统的调度点(POD)模块。可选的，有线电视广播接收器可以具有内嵌模块，其与有线电视卡具有等效的功能。在这种情况下，该有线电视广播接收器可以接收软件的形式的CA系统，该CA系统是可以从SO或MSO下载的并且被存储在该有线电视广播接收器的存储器中。可下载的软件通常被看作是下载条件接入系统(DCAS)。这样，有线电视广播接收器可以具有可以需要或可以不需要独立的有线电视卡的配置。
当需要有线电视卡时，为了和有线电视广播接收器接口连接，有线电视卡可以使用个人计算机存储器卡国际联合会(PCMCIA)标准。有线电视卡可以被插入到有线电视广播接收器提供的插槽中。
同时，主机可以接收并且处理由头端提供的基于开放式有线电视应用平台(OCAP)的服务。
也就是说，主机必须下载OCAP Java(OCAP J)应用软件，例如电子节目指南(EPG)以及由安装在远程的头端通过有线电视网络传送的监视器应用软件，并且在其系统内驱动应用软件。
因此，主机包括具有性能上适于驱动当生产产品时确定的下载应用软件的中央处理单元(CPU)，或具有依据头端和制造者之间约定的合适的功能的CPU。
然而，因为头端在OCAP环境中提供的服务方面不具有限制，所以当开始提供服务时仅提供监视应用软件，仅包括基本功能的EPG，以及脉冲式按次付费(IPPV)服务，但是，将来当OCAP服务环境稳定之后将会提供多种服务。
因此，由于头端提供的服务逐渐变得复杂化和多样化，通常地驱动OCAP J应用软件需要的CPU的性能必须逐步提高。
发明内容
因此，本发明直接涉及能够提供充分地消除上述一个或多个问题的提供诊断信息的广播接收器，数据结构和方法。
例如，本发明公开了用于提供诊断信息的广播接收器和方法，通过该广播接收器和方法，主机的中央处理单元(CPU)状态信息可以被转发到头端。
本发明公开了一种诊断信息数据结构，通过其可以发送/接收广播接收器的CPU状态的诊断信息。
本发明的优点、目的和特征部分地将在随后的说明书中变得更加明显，以及对于本领域技术人员来说在随后的实验中或从本发明的实践中得知使得部分的优点、目的和特征变得更加明显。本发明的各种实施例的目的和其他优点可以通过记载的说明书，权利要求书和附图描述的结构和处理过程认识到和达到。
为了达到这些目的和其他的优点以及根据本发明的目的，如这里具体或概括描述的，主机包括被配置以接收主机外的请求的主机控制器，其中该请求用于与用于应用软件的CPU相关的诊断信息。主机控制器进一步被配置为收集所请求的诊断信息。
另一方面，被配置为与主机通信的通信设备，该通信设备包括被配置为接收通信设备之外的请求的控制器，其中该请求用于与用于应用软件的CPU相关的诊断信息。控制器被进一步配置为使用设置值请求来自主机的诊断信息。
另一方面，方法包括接收主机之外的请求，其中该请求用于与用于应用软件的CPU相关的诊断信息；根据该请求收集所请求的诊断信息；以及转发所收集的诊断信息。
另一方面，方法包括请求与用于应用软件CPU有关的诊断信息；根据该请求接收诊断信息；以及执行转发诊断信息以及显示诊断信息中的至少一个。
进一方面，数据结构包括定义用于应用软件的CPU的性能的信息。
可以理解，上述简述和下面的详细描述都是示例性的和说明性的，不应该看作是对权利要求的范围的限制。
所包括的提供本发明进一步理解的附图被并入并构成本申请的一部分。附图与说明书一起用于解释本发明的原理。在附图中附图1是有线电视广播网络的示例性框图；附图2是OCAP_CPU_status_report()对象语法的例子的框图；附图3是交换协议信息一般诊断协议的例子的框图；附图4是识别诊断信息以诊断主机CPU的状态的例子的框图；附图5是作为诊断响应协议传输来自主机的状态信息至头端的结构语法的例子的框图；附图6A和6B是CPU_Information_report()对象语法的例子的框图；附图7是示例性的有线电视广播接收器的框图；以及附图8是传输CPU状态诊断信息的方法的示例性的流程图。
具体实施例方式
现在详细介绍根据不同实施例的用于提供诊断信息的广播接收器，数据结构和方法，在附图中描述了不同实施例的例子。在整个附图中为了简便尽可能采用相同的附图标记表示相同或相似的部分。在这种情况下，开放式有线电视应用平台(OCAP)在描述不同公开的实施例时被作为数据广播平台的一个例子来描述。
首先描述OCPA中的广播网络。附图1是说明有线电视广播网络的示例性框图。参考图1，有线电视头端或平台可以通过不同的通信网络接收来自例如电视广播站的有线电视广播信号。有线电视头端可以通过包括多个节点的网络传递有线电视广播至有线电视广播接收器，该有线电视广播接收器可以包括有线电视卡。
有线电视广播接收器可以与有线电视头端双向通信。在这种情况下，数据的传输/接收通过具有双向传输数据功能的有线电视网络来实现。
有线电视广播接收器可以连接至各种设备，例如数字视频光盘(DVD)放映机，数字摄像机，置顶盒等。随着有线电视头端提供的服务增加，可能会感觉广播接收器中用来执行服务所需的存储器不够用。
有线电视广播接收器可以被配置为通过有线电视网络基础结构与有线电视头端双向通信，如附图1所示，允许数据双向传递。有线电视广播接收器可以下载应用软件，例如，监视器应用软件，比如执行管理应用软件，电子节目指南(EPG)，用于游戏应用的OCAP_J应用软件等，以及数据。
有线电视头端提供的服务正在持续增加。所以，主机应该能够支持正在增加的服务。例如，为了支持正在增加的服务，主机可能需要保证充足的中央处理单元(CPU)性能，以在主机上持续地工作。
附图2是用于请求和接收主机的诊断信息的示例性协议的框图。在这个实施例中，有线电视卡接收来自有线电视头端或用户的该有线电视卡所插入的主机的诊断信息的请求。参考图2，该有线电视卡可以接收来自有线电视卡或用户的主机的诊断信息的请求。有线电视卡可以根据预定的协议转发该请求至主机。
如果主机接收诊断信息的请求，该主机根据请求收集诊断信息。然后该主机可以根据预定的协议转发收集的诊断信息至有线电视卡。
预定的协议可以是一般诊断协议，其被用于例如开放式有线电视。一般诊断协议是可以用于实时监视与主机或与通过本地实体(例如用户)或远程实体(例如有线电视MSO)连接至主机的设备有关的多种类型的信息的协议。例如，通过使用该协议，该有线电视卡可以使用诊断请求协议请求主机的诊断信息并且该主机可以使用诊断信息协议转发该诊断信息至有线电视卡。
因此，在附图2中，如果在有线电视卡和主机之间使用的协议是一般诊断协议，那么，例如，该诊断请求协议和诊断响应协议可以分别由diagnostic_req()应用协议数据单元(APDU)和diagnostic_cnf()APDU表示。因此，如果主机收集并根据该诊断响应协议转发其诊断信息至有线电视卡，则有线电视卡可以转发所接收的诊断信息至安装在远程的有线电视头端或通过在有线电视卡和主机之间实现的有线电视菜单接口将其输出至主机的屏幕。在这种情况下，该有线电视菜单接口可以传输超文本链接标示语言(HTML)文件等的格式至主机，这使得在屏幕上显示有线电视菜单，这里用户从有线电视菜单中选择诊断项目。在这种情况下，有线电视菜单接口可以生成使得用户能够请求和接收诊断信息的用户接口。
如上面提到的，一般诊断协议是可以使用的协议的一个例子。然而，其他协议也可以用来请求和接收来自主机的诊断信息。例如，可以使用多种广播规范定义的诊断信息协议。实际上，不能传输诊断信息的协议可以被变更以传输这样的信息。因此，一般诊断协议是可以用于传输诊断信息的协议的一个例子。
在下文中，当在主机和有线电视卡之间使用一般诊断协议传输/接收诊断信息时，将根据本发明对诊断信息进行说明。
诊断信息包括CPU的状态信息，其是事先包含在主机里的。据此，主机的CPU的状态信息的诊断识别(ID)应该被作为诊断信息之一包含在用于传输/接收在主机和有线电视卡之间的诊断信息的一般诊断协议里。
附图3是可以包括不同的诊断信息和相应值的示例性表格的框图。参考图3，有线电视卡可以通过设置诊断ID值为“0x0F”来请求诊断信息。该值代表OCAP应用CPU信息诊断信息正被请求。ID值“0x0F”可以被使用诊断请求协议转发至主机。当主机接收到诊断ID值“0x0F”时，主机收集请求的OCAP应用CPU信息诊断信息。收集的诊断信息可以被通过诊断响应协议转发至有线电视卡。
例如，如果诊断ID值是“0x08”，意味着是有线电视卡正向主机请求DVI状态信息。同样，如果诊断ID值是“0x0A”，有线电视卡正请求主机检查高清多媒体接口(HDMI)端口的状态。总之，多个诊断ID可以被用来接收来自主机的各种信息(eCM，RDS状态，OCHD2网络地址)。
有线电视卡和主机之间的接口可以被分类为单流有线电视卡接口或多流有线电视卡接口。在单流有线电视卡接口中，有线电视卡可以解密单个广播流并且主机可以处理该单个广播流。在多流有线电视卡接口中，有线电视卡可以解密多个多路复用的广播流并且主机可以处理多个广播流。
因此，解密单流的有线电视卡可以被看作是一个“S-模式”有线电视卡，解密多流的有线电视卡可以被看作是“M-模式”有线电视卡。
附图4是用于接收单流(S-模式)转发诊断信息的诊断响应协议的语法的例子的框图。
如果有线电视卡设置诊断ID值为“0x0F”，并转发诊断信息至主机，则接收诊断请求信息的主机可以识别正被请求的用于PCAP应用的与CPU信息相关的诊断信息。主机可以收集请求的诊断信息，然后根据诊断响应协议转发所收集的结果至有线电视卡。
当有线电视卡接收到诊断信息，有线电视卡可以解析包含在诊断信息里的诊断内容的数目(number_of_diag)。有线电视卡可以解析具有设置为“0x0F”的诊断ID值的OCAP_CPU_information_report()对象。然后有线电视卡可以转发解析的诊断信息至有线电视头端。
附图5是诊断响应协议的语法的例子的框图，其中有线电视广播接收器可以接收并多路复用根据本发明的一个实施例的诊断信息中的多个广播流(M-模式)。
图5示出的语法与图4的语法的区别在于多个多路复用的流的每个都可以有值ID。因此，有线电视卡可以以接收由主机收集的CPU的状态诊断信息和解析具有设置为“0x0F”的诊断ID的OCAP_CPU_information_report()的方式获得CPU的状态诊断信息。
根据本发明的一个实施例的诊断信息可以包括用于例如下载应用，数据或类似应用的OCAP应用的CPU的功能信息。
附图6A和6B是包含在附图4或附图5中示出的示例性语法的OCAP_CPU_information_report()对象语法的实例的框图。在下面将参考图6A和6B对有线电视卡解析根据本发明的一个实施例的诊断信息发送方法中的诊断响应协议的语法的实例进行解释。
附图6A和6B是根据本发明的“CPU_information_report() ”对象语法的例子的框图。这时候，CPU的状态信息是关于CPU的性能的信息。
在本发明中，例如，将描述指示CPU性能的“CPU_information_report()”对象语法。对象语法可以采用不同的方式被定义用来指示CPU性能，但是，在本发明中，例如，将描述两个实施例。
首先，将描述附图6A。
“program_execution_time(程序_执行_时间)”字段指示程序执行时间。在这个时候，程序执行时间指示用于在主机的CPU上执行具体基准程序的时间的结果。该结果是基准程序执行时间并且其单位由毫秒(ms)表示。也就是说，主机里的CPU性能可以由基准程序执行时间确定。
根据该程序执行时间，头端执行基准OCAP_J应用用于计算主机的CPU性能。也就是说，头端允许通过有线电视网络连接的主机下载基准程序，执行基准应用，并且存储该基准结果。
为了存储该基准结果，有线电视卡传输包含“CPU_information_report()”的诊断ID的diagnostic_req()APDU至每个主机。当“CPU_information_report()”的诊断ID包含在diagnostic_req()APDU中时，每个主机获得来自OCAP_J应用的基准结果并且将该基准结果包含在“CPU_information_report()”对象中。
主机包括在diagnostic_cnf()APDU中的对象并传输其至有线电视卡。有线电视卡传输该信息至安装在远程的头端的管理服务器。
可选地，头端可以提供基准样本代码至主机厂商用于计算主机的CPU性能。也就是说，该主机厂商可以在开发主机的时候以基准样本代码实现基准程序。
有线电视卡传输包含“CPU_information_report()”的诊断ID的diagnostic_req()APDU至主机。当“CPU_information_report()”的诊断ID包含在diagnostic_req()APDU中时，主机执行基准程序并将结果值包含在“CPU_information_report()”对象中。
主机包括在diagnostic_cnf()APDU的对象并将其传输到有线电视卡。有线电视卡传输信息至安装在远程的头端的管理服务器。也就是说，主机可以提供具有包含在使用包含在主机的基准程序或允许在开发时由头端下载的基准OCAP_J应用的主机中的CPU性能的头端。
接下来，将描述图6B。和图6A类似，包括“program_execution_time”字段并且进一步包括“CPU_clock_speed(CPU_时钟_速度)”字段，“D_cache_size(D_高速缓存_大小)”字段，“I_cache_size(I_高速缓存_大小)”字段以及“MIPS”字段。
接下来，将详细描述这些字段。
“CPU_clock_speed”表示主机的CPU的时钟的速度。在这时，主机的CPU的时钟速度的单位可以是兆赫兹(MHz)。“D_cache_size”字段表示主机的CPU的高速数据高速缓存的大小。在这时，主机的CPU高速数据高速缓存的大小的单位可以是千位(KB)。“I_cache_size”表示主机的CPU的指令高速高速缓存的大小。在这时，主机的CPU的指令高速高速缓存的大小的单位可以是KB。“MIPS”字段表示主机的CPU每秒百万条指令数(MIPS)信息。在这时，主机的CPU的MIPS的单元可以是MIPS。
如上，当主机接收到来自有线电视卡的用于CPU性能的状态信息的诊断请求时，主机收集CPU性能的状态信息。主机根据诊断响应协议返回收集的CPU性能的状态信息至有线电视卡。有线电视卡提供主机的响应至安装在远程的头端。头端可以接收来自有线电视卡的主机的CPU性能的状态信息并正确地使用该状态信息。例如，头端可以定义并记录每个主机的CPU的状态信息作为应用数据库并管理通过该有线电视网络相连的每个主机。
在下文中，为了使用由有线电视卡传输到头端的每个主机的CPU的状态信息将详细描述头端的状态信息的管理。
头端可以通过上述过程从有线电视卡获得CPU的状态信息，其具有多种功能并且被包括在每个主机中。据此，头端可以预先确定可以被每个主机驱动的OCAP_J应用软件。如上，头端可以分别定义和管理作为应用数据库的每个主机的CPU性能的状态信息。
作为定义和管理应用数据库的例子，头端通过有线电视网络接收每个主机的CPU性能的状态信息并且定义被确定为具有采用有关接收到的每个主机的CPU性能的信息足以驱动所有的由头端提供的OCAP_J应用软件的CPU性能的主机为“完全OCAP_J应用代码图像”。相反的，被确定为具有不足以驱动所有的由头端提供的OCAP_J应用软件的CPU性能的主机被定义为“轻加权OCAP_J应用代码图像”。
作为形成“轻加权OCAP_J应用代码图像”的方法，例如，采用用于允许具有低性能的主机以牺牲图像质量来确定应用的外观和感觉的方法来正常地驱动代码图像的方法。可选的，可以使用用于删除请求高CPU性能或由图像组成的用户接口(UI)的服务或者改变操作该服务或UI的结构以减少CPU的使用的服务的方法。
据此，头端接收通过由头端管理的有线电视网络连接在一起的每个主机的CPU性能的状态信息。头端使用该状态信息在应用服务器上定义每个主机为“完全OCAP_J应用代码图像”和“轻加权OCAP_J应用代码图像”中的任意一个。头端将包括用于上述定义的应用数据库。
头端通过使用在应用数据库里定义的信息，可以选择适于每个主机的代码图像并且下载OCAP_J应用软件至通过有线电视网络连接的每个主机。
当头端定义应用数据库时，例如，每个主机被定义为“完全OCAP_J应用代码图像”或“轻加权OCAP_J应用代码图像”。然而，这并不意味着该应用被分成两个步骤。也就是说，数据库被分成的数目可以与主机的CPU性能在与头端的策略相关的协议中直接改变的次数或者与CPU性能相关的头端和厂商彼此一致的次数成正比。
CPU性能的各个状态诊断信息和用于状态诊断信息的值是示例性的并且可以很容易被本领域技术人员修改。
如前面描述的，可以定义用于OCAP应用软件的CPU性能的状态。有线电视头端可以根据预定的规范通过具有在主机和有线电视卡之间发送接收的信息以及通过从有线电视卡传输相应的信息至有线电视头端来使用所接收的定义的状态诊断信息。其中该主机不请求有线电视卡，主机直接与有线电视头端进行双向通信。
在不同的实施例中，主机可以使用与前述的一般诊断协议有关的主机诊断协议。
主机可以采用主机诊断信息诊断其CPU的状态信息并将其显示给用户。如果是这样，用户可以通过屏幕识别主机的CPU状态。用户可以通过比较将服务与由有线电视头端提供的服务的长度做比较来选择可下载至主机的服务。在相应的主机和有线电视头端之间的通信中，主机使用一般诊断协议，因特网协议等根据用户对于有线电视头端的选择来获得服务。
而且，上面说明的状态诊断信息可以被应用于卫星广播接收器，地面广播接收器，因特网协议电视(IPTV)第。
在卫星接收器时，有线电视卡被智能卡代替。在这种情况下，作为外部接口的接口模块例如有线电视卡可以被提供在外部或内部。
附图7是根据本发明的一个实施例的示例性的有线电视广播接收器的框图。现在参考图7对的有线电视广播接收器的工作进行描述。
参考图7，有线电视广播接收器700可以包括有线电视卡，其可以被独立地插入位于广播接收器700的插槽内。在一个可替换的实施例中，广播接收器可以包括内嵌模块，其具有与有线电视卡相同的功能。在这种情况下，广播接收器不需要单独的有线电视卡。一般来说，广播接收器能够只接收有线电视广播信息或至少一个有线电视广播，地面广播以及卫星广播的广播信息中的至少一个。
同时，有线电视广播接收器和广播站之间的双向通信系统可以被分成两种类型。对于开放式有线电视中的上行链路服务，带外(OOB)模式或DOCSIS置顶网关(DSG)模式是可用的。观看者可以选择以通过使用两种模式中的一种的主机来观看具体程序。用户可以直接参与广播程序或选择观看所需的信息。并且，可以通过OOB或DSG模式提供数据广播服务。
OOB模式是可以调整有线电视广播站(头端)和机顶盒，有线电视卡或广播接收器内的交叉设备之间的传输规范的基准。另一方面，DSG模式可以表示有线电视广播站的有线电视调制解调器控制系统和机顶盒，有线电视卡或广播接收器内的基于有线电视调制解调器的DOCSIS之间的传输模式。在这种情况下，DOCSIS可以使用有线电视调制解调器传输数据。
在本实施例中，将介绍使用混合OOB和DSG模式的有线电视广播接收器。有线电视广播接收器700，如附图7所示，可以包括第一调谐器701a，第二调谐器701b，第一解调单元702，多路复用单元703，解多路复用单元704，解码单元705，第二解调单元(DOCSIS)706，OOB接收单元707，开关单元708，第三解调单元709，控制单元7 10以及CPU信息控制单元720。
第一调谐器701a可以调谐至通过天线传输的地面音频/视频(A/V)广播或通过有线电视在带内传输的有线电视A/V广播的具体信道频率并且将其输出至第一解调单元702。
地面广播与有线电视广播不同。但是，第一解调单元702能够分别对不同调制方案的信号执行不同的解调。如果地面A/V广播通过残留边带调制(VSB)被调制并被传输以及如果有线电视A/V广播被通过正交幅度调制(QAM)调制并被传输，第一解调单元702可以根据由第一调谐器701a选择的信号通过VSB或QAM执行信号的解调。
由第一解调单元702解调的信号可以被多路复用单元703多路复用以输出有线电视广播至有线电视卡750和输出地面广播至解多路复用单元704。
在附图7所示的实施例中，有线电视卡750能够处理多数据流。因此，有线电视卡750可以使用户通过广播接收器700观看具有至少两个多路复用的流的输入广播。
解多路复用单元704可以接收多路复用的广播信号，然后解多路复用所接收的广播信号为多个流并输出。解码单元705可以接收并解码由解多路复用单元704解多路复用的广播信号。
第二调谐器701b可以调谐通过有线电视以DSG模式传输的数据广播的具体信道频率，然后将其输出至第二解调单元706。第二解调单元706可以解调DSG模式数据广播，然后输出所解调的广播信号至控制单元710。第三调谐器707可以调谐用于通过有线电视以OOB模式传输的下行链路数据广播的具体信道频率，然后将其输出至有线电视卡750。
如果有线电视广播站和有线电视广播接收器之间的双向通信是可能的，则可以以OOB或DSG模式传输从有线电视接收器传输至有线电视广播站的上行链路信号(例如，支付程序请求，主机的诊断信息，等)。因此，根据本发明的一个实施例的有线电视接收器可以包括用于选择多种模式中的一种来传输信号的开关单元708。
在OOB模式下，用户信息或系统诊断信息可以被通过有线电视卡750开关单元708输出至第三调制单元709。第三调制单元709可以通过正交相移键控(QPSK)调制等来调制输出信号，以及然后通过电缆传输所调制的信号至有线电视广播站。如果用户的广播信号是以DSG模式传输的，该信号可以被通过开关单元708输出至控制单元710和调制单元709以及然后可以被调制单元709根据QAM-16调制。调制的信号可以通过电缆被传输至有线电视广播站。
在接收来自控制单元710的CPU信息状态诊断请求的情况下，CPU信息控制单元720可以收集CPU的诊断信息，然后传输所收集的信息至控制单元710。控制单元710可以传输所收集的CPU的诊断信息至有线电视卡750。
在附图7所示的实施例中，如果接收的广播与地面广播相对于，有线电视卡750可以接收来自多路复用单元703的多流广播信号。如果广播信号是加密的，有线电视卡750可以对该加密广播信号解密以使得能够正常地查看相应的有线电视广播。
有线电视卡750可以通过使用主机状态的状态诊断请求协议向控制单元710做出有线电视广播接收器700的状态诊断的请求。控制单元710可以传输状态诊断信息至CPU信息控制单元720。然后CPU信息控制单元720收集CPU状态诊断信息。
控制单元710可从CPU信息控制单元720接收所收集的CPU状态诊断信息，然后根据诊断响应协议传输所接收的CPU状态诊断信息至有线电视卡750。在附图7，状态诊断请求协议的例子被表示为“diagnostic_req APDU”，并且状态诊断响应协议的例子被表示为“diagnostic_cnf APDU”。
有线电视广播接收器700可被设置为传输CPU710的状态诊断信息至有线电视卡750。如果这样，有线电视卡750可以通过有线电视网络传输状态诊断信息至有线电视头端。然后有线电视头端能够识别每个有线电视广播接收器的CPU710的状态。
附图8是根据本发明的一个实施例的传输CPU状态诊断信息的方法的示例性流程图。根据附图8，在步骤S800中，接收状态诊断信息的请求。在使用一般诊断协议的情况下，被传输的状态诊断请求可以是“diagnostic_req()APDU”。所接收的状态诊断请求被解析用于识别所请求的诊断信息的值。
接着在S810，确定是否请求与CPU有关的用于OCAP应用软件的诊断信息。如果没有请求与CPU有关的用于OCAP应用软件的诊断信息，过程继续以识别其他的诊断信息。
如果所解析的协议的诊断ID字段的值包括CPU的用于OCAP应用软件的状态诊断信息，则在S820中收集该诊断信息。接着在步骤S830中，所收集的与CPU有关的用于OCAP应用软件的诊断信息被转发至请求该信息的源节点。
因此，可获得以下优点。
可以通过有线电视头端获得与每一个主机相关的CPU的状态诊断信息。
如果扩展由作为一般诊断协议的这种预定的协议规定的模式，在该诊断信息传输方法中可保证用于有线电视卡的传输信息的兼容性。
已经采用数字广播接收器对本发明进行了描述，其中该广播数字接收器可以具有地面模拟/数字信道，以及有线电视模拟/数字信道。采用本领域技术人员所了解的修改，本发明可以在任何地面有线(例如，电话)和无线(例如，蜂窝)网络和卫星网络中实现。
应该理解，以上的各种公开以及其他特征和功能或其可替代的内容可以在可编程微处理器，微控制器，集成电路元件，例如ASIC，PLD，PLA，FPGA或PAL等，硬件电子或逻辑电路，或可编程逻辑设备中实现。
应该理解，所描述的流程处理，数据结构，协议或表格可以作为导致期望结果的可计算的步骤的自适应序列来实现。这些步骤可以和/或由存储在计算机可读介质中的一个或多个计算机指令定义，或者可以通过使用信号来完成，或作为至处理设备的软件指令来提供。这些步骤可通过执行定义这些步骤的指令的处理器来执行。进一步，该流程处理可通过处理器执行一个或多个类似的程序，通过为执行该方法而设计的特殊的硬件，或这样硬件，固件和软件元件的组合来执行。
应该理解，以上的各种公开以及其他特征和功能，或替代的内容可以理想地组合成其他许多种不同的设备或应用。并且，可以被本领域技术人员随后得出的各种目前不可预见或不可预料的替换物，修改，变更或改进，并且倾向通过下面的权利要求来保护。
权利要求
1.一种主机，包括主机控制器，其被配置以接收主机外部的请求，其中该请求用于与用于应用软件的中央处理单元(CPU)有关的诊断信息；以及该主机控制器被进一步配置以收集所请求的诊断信息。
2.如权利要求1的主机，其中该主机控制器被配置以通过通信接口接收外部请求。
3.如权利要求2的主机，其中该通信接口包括有线电视卡。
4.如权利要求3的主机，其中该主机被配置以使用一般诊断协议与有线电视卡通信。
5.如权利要求1的主机，其中该所请求的诊断信息包括表示驱动应用软件的CPU的性能的信息。
6.如权利要求5的主机，其中该表示CPU性能的信息包括关于程序执行时间的信息。
7.如权利要求6的主机，其中该表示程序执行时间的信息使用执行预先包含在主机中的基准程序的时间的结果。
8.如权利要求7的主机，其中该基准程序是通过从请求诊断信息的外部源下载用于计算程序执行时间的基准程序或实现由外部源提供的基准样本代码来获得的。
9.如权利要求5的主机，其中该表示CPU的性能的信息包括有关CPU的时钟速度的信息。
10.如权利要求5的主机，其中该表示CPU的性能的信息包括有关CPU的D高速缓存的大小的信息。
11.如权利要求5的主机，其中该表示CPU的性能的信息包括有关CPU的指令高速缓存的大小的信息。
12.如权利要求5的主机，其中该表示CPU的性能的信息包括有关CPU的每秒百万条指令数(MIPS)的信息。
13.如权利要求5的主机，其中该表示CPU的性能的信息包括有关程序执行时间的第一信息，有关时钟速度的第二信息，有关D高速缓存大小的第三信息，有关指令高速缓存的大小的第四信息，以及有关CPU的MIPS的第五信息。
14.如权利要求6的主机，其中该表示CPU的性能的信息进一步包括有关时钟速度的第一信息，有关D高速缓存大小的第二信息，有关指令高速缓存的大小的第三信息，以及有关CPU的MIPS的第四信息中的至少其中之一。
15.如权利要求1的主机，其中该应用软件包括开放式有线电视应用平台(OCAP)应用软件。
16.一种被配置以与主机通信的通信设备，该通信设备包括控制器，其被配置以接收通信设备外部的请求，其中该请求用于与用于应用软件的中央处理单元(CPU)有关的诊断信息；该控制器被进一步配置以通过使用设置的值从主机请求诊断信息。
17.如权利要求16的通信设备，其中该控制器被配置以从主机接收所请求的诊断信息，并且该通信设备被进一步配置以根据预定的协议解析所请求的诊断信息。
18.如权利要求16的通信设备，其中该控制器被配置以转发所解析的诊断信息至请求该诊断信息的源。
19.如权利要求16的通信设备，其中该应用软件包括开放式有线电视应用平台(OCAP)应用软件。
20.一种方法，包括步骤接收主机外部的请求，其中该请求用于与用于应用软件的中央处理单元(CPU)有关的诊断信息；根据该请求收集所请求的诊断信息；以及转发所收集的诊断信息。
21.如权利要求20的方法，进一步包括在主机接收适用于该应用软件的CPU的应用软件的版本的步骤。
22.如权利要求20的方法，进一步包括步骤解析对于值的请求；以及基于该值确定请求是否用于有关用于应用软件的CPU的诊断信息。
23.一种方法，包括步骤请求与用于应用软件的中央处理单元(CPU)相关的诊断信息；根据该请求接收该诊断信息；以及执行转发诊断信息和显示诊断信息中的至少其中之一。
24.如权利要求23的方法，进一步包括根据预定协议解析所请求的诊断信息的步骤。
25.如权利要求23的方法，进一步包括转发解析的诊断信息至请求该诊断信息的源的步骤。
26.如权利要求23的方法，进一步包括收集请求的诊断信息的步骤。
27.如权利要求23的方法，进一步包括接收适用于应用软件的CPU的应用软件版本的步骤。
28.一种数据结构，包括定义用于应用软件的中央处理单元(CPU)的性能的信息。
29.如权利要求28的数据结构，其中，该定义CPU的性能的信息包括有关程序执行时间的第一信息。
30.如权利要求29的数据结构，其中，该定义CPU的性能的信息进一步包括有关时钟速度的第二信息，有关D高速缓存的大小的第三信息，有关I高速缓存的大小的第四信息，以及有关CPU的每秒百万条指令数(MIPS)的第五信息中的至少其中之一。
全文摘要
主机包括被配置以接收主机外部的请求的控制器，其中该请求用于与用于应用软件的中央处理单元(CPU)有关的诊断信息。该控制器被进一步配置以收集所请求的诊断信息。
文档编号H04N7/16GK101087391SQ20071012810
公开日2007年12月12日 申请日期2007年5月23日 优先权日2006年5月23日
发明者车尚勋, 朴泰镇, 金俸奭 申请人:Lg电子株式会社