使设备驱动可跨操作系统平台移植的抽象设备驱动模型专利检索-模型驱动体系结构软件专利检索查询-专利查询网

使设备驱动可跨 操作系统平台移植的抽象设备驱动模型

阅读：673发布：2020-07-20

专利汇可以提供使设备驱动可跨操作系统平台移植的抽象设备驱动模型专利检索，专利查询，专利分析的服务。并且机顶终端中设备驱动程序的抽象接口模型，用于有线电视或卫星电视这样的用户网络。在分层的软件结构体系中，设备驱动程序抽象接口模型可以使客户(112，212)与设备驱动程序(154，254)之间进行通信，而不需要考虑设备驱动程序操作于何种操作系统 (OS)下。在第一实施例中，该体系结构包括了专用的(操作系统特定的)设备驱动程序接口(132)，一个代理使用一个第一抽象接口(122)将来自客户(112)的接口服务请求转换为操作系统特定的对设备驱动程序(154)的调用。对于直接存取专用(操作系统特定的)设备驱动程序接口(132)的客户，使用一个第二抽象接口(152)将接口服务请求转换为操作系统特定的对设备驱动程序(154)的调用。因此保留了对操作系统特定的设备驱动程序接口(132)的直接存取。，下面是使设备驱动可跨操作系统平台移植的抽象设备驱动模型专利的具体信息内容。

权利要求

1.一种使一客户和一终端中的设备驱动程序之间能够通信的方法，其中该终端有相关特定的操作系统，该设备驱动程序运行在该系统下，该方法包含以下步骤：提供第一抽象接口，将来自该客户具有与操作系统无关的格式的服务请求，转换为一个对具有兼容于该特定操作系统的格式的设备驱动程序的调用。
2.根据权利要求1的方法，包含进一步的步骤：
使用该第一抽象接口，该接口将来自于设备驱动程序具有该特定操作系统格式的信息，转换为该客户使用的一与操作系统无关的格式的相应信息。
3.根据权利要求1的方法，其中：
该终端是网络中的一用户电视终端。
4.根据权利要求1的方法，其中：
该终端在宽带通信网路中。
5.根据权利要求1的方法，其中：
该第一抽象接口适配为为设备驱动程序以兼容于各自相应的不同操作系统的多个格式的任何一种格式提供该调用。
6.根据权利要求1的方法，包含进一步的步骤：
通过该根据特定操作系统运行的设备驱动程序接口向该设备驱动程序提供该调用。
7.根据权利要求6的方法，其中：
该设备驱动程序接口适配为接收直接来自于其它客户一个具有兼容于该特定操作系统的格式的第二调用；以及
该设备驱动程序接口通过一第二抽象接口向该设备驱动程序提供该第二调用。
8.根据权利要求6的方法，其中：
该第一抽象接口适配为通过该设备驱动程序接口为设备驱动程序以兼容于各自相应的不同操作系统的多个格式的任何一种格式提供该调用。
9.根据权利要求6的方法，包含进一步的步骤：
提供一第二抽象接口，将来自于设备驱动程序一具有兼容于特定操作系统的格式的信息，转换为客户使用的与操作系统无关的格式的相应信息。
10.根据权利要求9的方法，包含进一步的步骤：
通过该第一抽象接口提供该客户使用的与该操作系统无关的该信息。
11.根据权利要求9的方法，其中：该第二抽象接口适配为将给该客户的信息从兼容于各自相应的不同操作系统的多个不同格式的任何一种格式，转换为客户使用的与操作系统无关的格式。
12.一种使一客户与一终端的设备驱动程序之间能够进行通信的仪器，该终端有相关的特定的操作系统，设备驱动程序运行于该系统下，包含：提供第一抽象接口将来自该客户具有与操作系统无关的格式的服务请求，转换为具有兼容于该特定操作系统格式的设备驱动程序的调用的装置。
13.一种使客户与终端的设备驱动程序之间能够进行通信的方法，该终端有相关的特定的操作系统，设备驱动程序运行于该系统下，包含以下步骤：提供第一抽象接口，将来自于该设备驱动程序一具有特定操作系统格式的信息，转换为客户使用的与操作系统无关的格式的相应信息。
14.根据权利要求13的方法，其中：该第二抽象接口适配为将给该客户的信息从兼容于各自相应的不同操作系统的多个不同格式的任何一种格式，转换为客户使用的与操作系统无关的格式。
15.一种使一客户与一终端的设备驱动程序之间能够进行通信的仪器，该终端有相关的特定的操作系统，设备驱动程序运行于该系统下，包含：提供第一抽象接口将来自于设备驱动程序具有该特定操作系统格式的信息，转换为客户使用的与操作系统无关的格式的相应信息。

说明书全文

本发明是关于数字视频转换 软件/固件领域，用于 有线电视或卫星电视这样的用户网络。它特别为机顶终端的设备驱动程序提供了抽象 接口模型。

最近，数字机顶终端的出现刺激了有线电视网络/卫星电视网络这样的用户电视网络的成长。这些终端可以使节目服务的层增加，并支持许多软件应用程序和功能，如电子节目单、股票或天气条幅(banner)、家中购物和银行服务、游戏等等。此外，这种趋势有望继续发展，与电话、电视和计算机网络汇合并促进家中计算机网络的增长。

每个终端包括多种硬件设备，例如，调谐器、解调器、MPEG-2译码器(如音频、视频和数据)、视频编码器、音频混合器等等，他们分别由各自的驱动过程控制。

另外，每个终端使用一个操作系统平台控制终端功能。操作系统有一个分层结构(hierarchical structure)，其中的功能根据抽象层的不同是独立的。在结构的底部，最低的抽象层(abstract level)或层次(layer) 是硬件层。上一层是设备驱动程序层。在结构的顶部，典型的最高抽象层是客户层。此外，每个层管理一组对象(object)，可以是硬件对象也可以是软件对象，并定义在对象上进行的操作。

但是，传统上必须对每个操作系统平台(例如，不同的视频转换厂商，或者同一厂商的不同视频转换模型)分别实现设备驱动程序。另外，为支持不同操作系统平台可能还会需要一个单独的硬件平台。甚至有可能同一网络的不同终端要有不同的操作系统。

机顶终端中操作系统的连续变更通常是由改进、成本降低、新组件以及第二来源厂商引起的。这就存在一个问题，因为即使每个网络都只使用单一的操作系统平台，终端厂商也必须为不同网络的不同操作系统生成不同的设备驱动程序。一个网络的操作系统的设备驱动程序不能很容易地移植(migrate)到另一个网络的操作系统中。

开发并提供更新的终端设备驱动程序软件/固件会额外增加终端厂商和网络供货商的费用。

具体地讲，特定操作系统的设备驱动程序与操作系统结合得十分紧密，这就意味着驱动程序在整个实现过程中包含了操作系统特定的详细信息，因此在每个操作系统平台下开发驱动程序都需要一个完整的开发周期。

随着技术的进步，终端不断的升级和更新，这个问题变得更加复杂。

因此，提供一个设备驱动程序抽象接口模型是符合需要的。此模型使我们能够开发单一一组设备驱动程序代码(code)和多种视频转换操作系统下编译并执行的设备用户代码。该接口应该可以让多个操作系统和视频转换平台下的设备驱动程序仅实现一次。DCT5000系列终端就是这样的一个合适的平台，由本文中的专利拥有人通用仪器公司(General Instrument Corporation)生产。

接口应该允许设备驱动程序与客户之间的双向通信。

无论硬件设备运行何种操作系统，接口应该保证硬件设备对终端客户看上去是相同的(例如，无论何种应用程序或其它实体(entity) 与设备进行通信)。相似地，无论使用何种操作系统，对于实际设备驱动程序来说，客户看上去也应该是相同的。

接口应该可以使跨越操作系统平台和硬件平台的体系结构 (architecture)和代码共享。

接口应该对所有操作系统可用，无论该系统是否具有专用的(操作系统特定的)设备驱动程序接口。

接口应该可以使用面向对象或面向过程的编程语言实现。

本发明提供的设备驱动程序抽象接口模型就具有以上优点以及其它优势。

发明概要

本发明讨论的是机顶终端中设备驱动程序的抽象接口模型。

本发明使驱动程序核心逻辑(core logic)只需开发一次。核心需要针对每个操作系统平台分别进行编译。

在一特别实施例中，本发明提供一种客户与终端的设备驱动程序之间进行通信的方法，在这里终端有相关特定的操作系统，设备驱动程序运行在该系统下。该方法包含提供第一抽象接口的步骤，该接口将具有与操作系统无关的格式的客户服务请求转换为具有兼容于特定操作系统格式的设备驱动程序的调用(call)。

特别地，第一抽象接口适配为可以为设备驱动程序提供任何格式 (每种格式兼容于各自相应的操作系统)的调用。

有了专用(操作系统特定)的设备驱动程序接口以后，设备驱动程序接口经过修改可以接收直接来自于其它客户(具有兼容于特定操作系统的格式)的第二调用。第二调用不通过第一抽象接口传递。进一步讲，设备驱动程序接口通过第二抽象接口向设备驱动程序提供第二调用。

使客户与终端的设备驱动程序之间能够进行通信的一种相关方法 (在这里终端有相关的特定的操作系统，设备驱动程序运行于该系统下)包含提供第一抽象接口的步骤，该接口将来自于设备驱动程序的信息(具有特定操作系统格式)转换为客户使用的相应信息(与操作系统无关的格式)。

第一抽象接口经过修改可以将信息从任何一种格式(每种格式兼容于各自相应的操作系统)转换为客户使用的与操作系统无关的格式。

本发明还说明相应的仪器。

附图说明

图1示例了本发明描述的带有专用设备驱动程序接口的操作系统使用的设备驱动程序抽象接口模型。

图2示例了本发明描述的不带有专用设备驱动程序接口的操作系统使用的设备驱动程序抽象接口模型。

具体实施方式

本发明讨论的是机顶终端中设备驱动程序的抽象接口模型。
著名的面向对象设计技术提供了一种抽象创建对象的方法。设计者可以创建提供抽象接口的对象而不需要直接了解对象例示 (instantiation)的详细信息。这是在软件运行时动态发生的。
本发明按以下方式延伸或修改了这个概念。为所有的操作系统只创建一个驱动程序接口。这在编译源代码时完成并仅进行一次(静态地)。
因此，当开发一个新的操作系统平台时，仅需要开发代理(proxy)、操作系统特定的驱动程序以及操作系统特定的驱动程序支持。典型情况下这只需要开发周期的十分之一或更少，因此会节约大量的时间和成本。
具体地讲，所有的设备驱动程序逻辑都位于设备驱动程序核心控制中或在其中实现。此模块(module)或子系统紧靠硬件设备层并与硬件设备直接通信，或者在操作系统特定的驱动程序支持子系统的协助下与硬件设备通信。注意，核心控制包括此体系结构中的大部分代码。
设备驱动程序核心控制实现在设备驱动程序抽象接口中定义的逻辑。此接口定义驱动程序必须提供的服务。核心控制包括需要提供这些服务的所有代码。
图1示例了本发明描述的带有专用设备驱动程序接口的操作系统使用的设备驱动程序抽象接口模型。该专用设备程序接口130可能是 Microsoft(tm)的Windows CE。
分层的设备驱动程序模型100包括110、120、130、140、150和 160等层次。典型情况下操作系统仅需要为其接口在一层上实现一个驱动程序。底层160是最低的抽象层，它包括机顶终端中硬件设备本身 162。
下一抽象层150包括第二设备驱动程序抽象接口152、设备驱动程序核心控制154和操作系统特定的驱动程序支持156。下一个抽象层 140包括操作系统特定的驱动程序实现142。下一个抽象层130包括操作系统设备驱动程序接口132。
下一抽象层120包括第一设备驱动程序抽象接口122和设备驱动程序代理124。
下一抽象层110是最高层，它包括使用设备驱动程序抽象接口122 的客户112和使用操作系统设备驱动程序接口132的用户114。
注意，虽然图中只显示了一个设备，本发明适用于机顶终端中任意数量的设备。
在图1的体系结构中，操作系统特定设备驱动程序142使用第二设备驱动程序抽象接口152来控制或驱动设备驱动程序核心控制154。特别地，带有操作系统特定设备驱动程序142的140这一层将操作系统特定的设备驱动程序调用(与特定的操作系统结合)，转换或变换为设备驱动程序抽象接口152定义的抽象设备驱动程序调用。
操作系统本身通过操作系统定义的驱动程序接口132调用 (invoke)操作系统特定的设备驱动程序142内的服务。例如，操作系统可能是Microsoft(tm)Windows CE。此操作系统调用Windows CE 设备驱动程序内格式为″xxx_IOCTL″的调用，其中″xxx″代表Windows CE设备名称。
Windows CE是一个关于驱动过程调用的例子，其中代理调用″设备输入输出控制″(″DeviceIoControl″)调用来传递Win CE设备名称。
对于客户112，设备驱动程序代理124使用抽象接口122代替了设备驱动程序154，该抽象接口在功能上与设备驱动程序核心控制154 实现的设备驱动程序接口152相同。这些客户包括中间件(middleware) 和应用程序等等。因此，看起来客户好象是与驱动程序核心本身之间直接存在接口。另外，代理124将来自客户112的接口服务请求转换或变换到与其关联的操作系统特定的系统设备。
此外，抽象接口122、152处理由驱动程序到客户的通信数据，该数据可以是同步的(synchronous)，也可以是异步的(asynchronous)。对于同步通信，驱动程序154仅在客户110、114请求时为其提供数据。在客户到驱动程序的通信连接中，数据像描述的那样跨过操作系统驱动程序边界进行传递。
异步通信在客户没有请求，而驱动程序又要发送客户数据(例如信息)时发生。注意驱动程序只通知客户它有这些数据，然后客户必须同步检索数据。可以概括为以下几步：
1.驱动程序要向客户传递数据。
2.驱动程序通过一个事件异步地向客户发送信号。
3.客户发出同步操作来检索(retrieve)数据或读取数据。
概括地讲，设备驱动程序代理124将来自于客户110的抽象接口请求转换为操作系统特定的设备驱动程序系统调用。然后操作系统接着调用(invoke)操作系统特定的驱动程序。操作系统特定的驱动程序 142将请求转换回驱动程序接口请求，即与客户初始执行的调用相同的接口调用。在设备驱动程序核心154中执行此请求。
最后，外部客户在访问驱动程序时可以选择两个接口路径。首先，抽象接口122、152可以以内部客户(例如视频转换厂商开发的客户) 的方式使用，例如图1中的客户112。其次，可以直接使用操作系统驱动程序接口，如图1中的客户114。
外部客户是指视频转换厂商的外部。外部客户包括需要使用厂商驱动程序的实体，例如像Liberate Technologies(tm)、美国加州的San Carlos这样的中间件开发商或像Microsoft这样的操作系统开发商。
图2示例了本发明描述的不带有专用设备驱动程序接口的操作系统使用的设备驱动程序抽象接口模型。
分层结构模型200包括层210、250和260。底层260包括硬件设备262。下一抽象层250包括设备驱动程序抽象接口252、设备驱动程序核心控制254和操作系统特定的驱动程序支持256。
下一层210包括使用抽象接口252的客户212。
特别地，图2指的是包含不带设备驱动程序接口的操作系统的视频转换系统。例如美国Oregon州Wilsonville的Mentor Graphics公司的VRTX操作系统。
当操作系统不需要使用专用操作系统特定接口时，这个分层的体系结构压缩了(例如，需要的层数更少)。在这里，又是客户212使用设备驱动程序抽象接口252检视设备驱动程序254。但是，客户直接与驱动程序核心254连接。不带专用驱动程序接口的操作系统下只有抽象接口252是可用的。
相似地，设备驱动程序254借助于接口252来检视(view)客户，实现双向通信。
因此可以看出，本发明为机顶终端的设备驱动程序提供了一个抽象接口模型。
本发明的优点如下。对于使用抽象接口的客户，设备驱动程序看上去是相同的。不需要为每个操作系统重新开发客户。另外，客户不能分辨或看到两个不同操作系统实现的区别(见图1和图2)。驱动程序看上去是相同的。关键的问题是驱动程序支持只开发一次客户的抽象接口，并可以跨越操作系统使用。
此外，对于驱动程序核心控制，客户看上去是相同的。核心逻辑不能分辨使用抽象接口/代理的客户、使用不带抽象接口/代理的操作系统驱动程序接口的客户或者直接存取核心的客户之间的不同，如图2。
驱动程序核心控制子系统是以独立于操作系统的方式实现的。典型情况下，这个子系统需要大量的开发工作(例如，全部驱动程序开发需要多达90％的工时)。但是，因为本发明的驱动程序核心控制子系统仅需要开发一次并可以跨越操作系统平台使用，所以此抽象设备驱动程序模型可以大大地缩短新视频转换产品进入市场的时间。
另外，本发明允许替代设备驱动程序用户接口的使用。
虽然关于本发明的描述是各种特定的具体方式，但是本领域的技术人员应当了解，可以根据在本发明权利要求中阐明的发明范围和实质内进行多种额外的修改和修正。
例如，虽然发明讨论的是关于有线电视或卫星电视宽带通信网络，但它也可以用于其它网络，如局域网(LAN)、城域网(MAN)、广域网(WAN)、网际网(internet)、内部网(intranet)以及国际互联网(Internet)或它们的组合。
此外，发明可以使用任何已知的硬件、固件和/或软件技术来实现。

标题	发布/更新时间	阅读量
一种基于神经网络的群机器人利用信息素通信实现协作觅食的方法	2020-05-11	794
一种基于SystemC的GPU软硬件交互TLM系统	2020-05-13	784
一种基于多视图深感知器框架的三维姿势估计方法	2020-05-15	471
一种支持动态配置的构件模型及构件工厂的装置	2020-05-19	245
一种基于数据驱动的仿真模块	2020-05-08	203
模型驱动的物联网应用开发方法	2020-05-19	505
一种基于SOA架构和模型驱动架构的数据资源管理系统	2020-05-24	220
一种用于彩色图像超分辨率重建的6维嵌入的去噪自编码先验信息算法	2020-05-12	779
一种基于业务流程设计的快速开发引擎系统	2020-05-11	100
Policy directed security-centric model driven architecture to secure client and cloud hosted web service enabled processes	2020-05-25	238

使设备驱动可跨操作系统平台移植的抽象设备驱动模型

本发明是关于数字视频转换软件/固件领域，用于有线电视或卫星 电视这样的用户网络。它特别为机顶终端的设备驱动程序提供了抽象 接口模型。

具体实施方式

发明背景

该功能需要专业版企业版VIP权限，您可以：

本发明是关于数字视频转换软件/固件领域，用于有线电视或卫星电视这样的用户网络。它特别为机顶终端的设备驱动程序提供了抽象接口模型。