WO1998041912A2

WO1998041912A2 - Method and apparatus for adding new functionality to a headend

Info

Publication number: WO1998041912A2
Application number: PCT/US1998/002964
Authority: WO
Inventors: Vincent Aumont; Samuel V. Cirka; Mark R. A. Heieis
Original assignee: Scientific-Atlanta, Inc.
Priority date: 1997-03-17
Filing date: 1998-02-26
Publication date: 1998-09-24
Also published as: PE63599A1; WO1998041912A3

Abstract

A headend system can be adapted to include a third party device. The system includes a device for providing a function for the headend system, the device having protocol incompatible with the headend system, host computer (40), operatively coupled to the device, and user interface (50) for inputting a first high-level instruction and second high-level instruction to integrate the device with the headend system, first high-level instructions being higher than second high-level instructions and first high-level instructions identifying second high-level instructions corresponding to first high-level instructions. The headend system also includes a first memory (70) for storing first high-level instructions and a second memory (60) for storing second high-level instructions. The host computer (40) accesses memories (70, 60) and converts the first high-level instruction to the second high-level instruction and executes the second high-level instructions to control the device. The first high-level instructions may be in a text language and the second high-level instructions can be in a script language.

Description

METHOD AND APPARATUS FOR ADDING NEW FUNCTIONALITY TO A HEADEND

FIELD OF INVENTION

The invention generally relates to a headend management system. More particularly, the present invention is directed to a tool in the form of a data definition language which permits the addition of new functionality to an existing headend.

BACKGROUND OF INVENTION

In the past, to adapt new products into an existing headend system, software engineers were required to write new code and device drivers for the new product and integrate new code into the core product or headend. Existing headends are fixed so that new functions and devices cannot be integrated into the system without overhauling the system, resulting in significant changes to the core product or headend. Typically, functionality and devices are implemented statically into software applications. That is, the functionality is built into the system. Thus, customers have no ability to add, subtract, or otherwise manipulate the functionality of the headend. Illustrative conventional headends include the IH-2000 Intelligent Headend Manager and Headend Manager products manufactured by Scientific- Atlanta, Inc.

Conventionally, when a new function or device is integrated into a headend, it must be built into the system. Thus, the headend manufacturer must redesign and reconfigure the headend to implement the software and/or hardware necessary. Typically, such a task can take multiple months to complete. Absent such recompiling and reconfiguring, the headend will not know the device protocol for exchange of data and device control. Consequently, the desired functionality cannot be implemented. The headend requires software development units (SDUs) and tools to create graphic displays and device drivers for third party devices. SDUs with a compiler and library add the new functionality of the third party devices.

The continued rapid evolution of devices and functionality has made it difficult to keep up with the changing designs and functionalities. These new design modifications and revisions can be implemented during product development at undesirable times. Also, the new design modifications cause unplanned increases in manufacturing costs and delays in product roll out.

Customers commonly look at several different competing headend products and often desire a system that incorporates the best features and functionalities from each of the products. However, the devices of the various headend vendors are incompatible and cannot be integrated. Moreover, there is a reluctance among the various headend vendors to share their proprietary internal protocols so that their devices and functions can be incorporated in the headends of competitors. Consequently, customers are left with no choice, but to implement the fixed functionality of a single manufacturer's headend.

SUMMARY OF THE INVENTION

The present invention overcomes the problems associated with the prior art by providing a scheme which permits the rapid deployment of new devices and functionality in a headend regardless of the internal protocol of the headend and the device being deployed.

With the present invention, new devices and functionality can be integrated into a headend by using a text-based data definition language (DDL) and script language (e.g., tool command language (TCL)) in conjunction with a headend management system (HMS) and applications software. The HMS is a software program that allows users to integrate new devices into a system so that the headend operator can perform status monitoring and control of the new devices. The text-based language allows a user to dynamically create a device driver and a graphical user display. The implementation of the text-based language employs a text editor that creates ASCII files. A headend management system (HMS) contains a command interpreter to recognize text, access procedures in the script corresponding to the text, and execute the procedures to read third party devices.

Integration of new functionality and devices using the present invention is far less complex and faster than existing options. More importantly, the ability to modify the headend and add new functionality can readily be placed in the hands of the customer (e.g., the headend operator). The customer can modify and add new functionality into the HMS without being a programmer or having to recompile a program. For example, the customer does not need to be a full-fledged C++ interface programmer. Moreover, the customer has a tool which allows the entire headend to be integrated without the headend manufacturer having knowledge of proprietary protocols of devices manufactured by other vendors. The customer can add support in the field for new devices and functionality which the headend manufacturer knows nothing about, as long as the customer has knowledge of the internal protocol of the new device. Thus, the customer can go directly to the manufacturer of the device to be added and request the internal protocol associated with the device. Therefore, the device manufacturer can provide their proprietary protocol to the customer (e.g., under a non-disclosure agreement) so their devices can be implemented with another manufacturer's headend without the other manufacturer learning of the device manufacturer's protocol.

An illustrative headend system according to the present invention includes a device for providing a function for the headend system, the device having a protocol incompatible with the headend system, a host computer, operatively coupled to the device, and a user interface, operatively coupled to the host computer, for inputting a first high-level instruction and second high-level instructions to integrate the device with the headend system, the first high-level instruction being higher than the second high level instructions and the first high-level instruction identifying the second high-level instructions corresponding to the first high-level instruction. The headend system also includes a first memory, operatively coupled to the host computer, for storing the first high-level instruction and a second memory, operatively coupled to the host computer, for storing the second high-level instructions. The host computer accesses the first memory and second memory and converts the first high-level instruction to the second high-level instructions and executes the second high-level instructions to control the device.

The host computer can receive data from the device, interprets the data according to the second high-level instructions and modifies an attribute defined by the first high-level instruction. Also, the first high-level instruction can include plural first high-level instructions and the second high-level instructions can include sets of second high-level instructions corresponding to each of the first high-level instructions.

An exemplary method for adapting a device to a headend system having a protocol incompatible with the headend system includes several steps. The steps include inputting a first high-level instruction and second high-level instructions, the first high-level instruction being higher than the second high level instructions and the first high-level instruction identifying the second high-level instructions corresponding to the first high-level instruction, storing the first high-level instruction and the second high-level instructions, converting the first high-level instruction to second high-level instructions, and executing the second high- level instructions to control the device.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described in more detail with reference to preferred embodiments of the invention, given only by way of example, and illustrated in the Oaccompanying drawings in which:

Figure 1 is a functional block diagram of elements in a headend system according to an illustrative embodiment of the present invention.

Figure 2 is a flow diagram of an illustrative method for integrating a new device into a headend system according to the present invention.

Figure 3 is an illustrative graphical user interface according to the present invention.

DETAILED DESCRIPTION

The present invention is discussed below with reference to a headend for a cable or satellite television system. However, the present invention may be extended to applications such as power control systems and other systems where implementation of new devices or functionality requires substantial reconfiguration of the system. Exemplary functionality can include pure status monitoring and control at the simplest level to complex fault tolerance management and fault isolation. It should be understood that the present invention adapts to the new functionality and does not know what types of functionality may be integrated to the headend.

A module, typically of the plug-in type, is used to add a new device and/or function to a headend. The HMS (headend management system) integrates a device into the headend so that it can be controlled and otherwise adapted to function with the HMS and other devices in the headend. Until the present invention, many devices and functionality were incompatible with existing status monitoring/control software and required substantial reconfiguring, reprogramming, and recompiling to support new headend devices or functions in the headend. The present invention facilitates the addition of new modules, i.e., new devices and functionalities. In static procedural programs, new devices cannot be implemented. However, the HMS allows new devices to be implemented. Figure 1 shows an illustrative depiction of a portion of the headend system. Figure 2 shows a flow diagram of the steps for an illustrative method of the present invention.

According to the present invention, adding a new device 10 to the headend involves a series of steps. The new device must be plugged in or otherwise connected to the headend in step SI shown in figure 2. A new device (e.g., a third party device) 10 may be a circuit board which is adjacent to existing built-in (i.e., static) devices 20 and coupled to the host computer 40 (e.g., a motherboard) by a common bus 30 as shown in figure 1 or alternatively, a dedicated bus (not shown). The HMS including an assembly/interpreter forms part of the host computer 40. The HMS is a software program that allows users to integrate new devices into a system so that the headend operator can perform status monitoring and control of the new devices.

Before, or in the alternative after, connecting the device to the HMS. instructions defining the new device 10 in two high-level definition languages must be input through a user interface 50 to the HMS in the host computer 40. Exemplary user interfaces include, but are not restricted to, a keyboard, a mouse, trackball, and the like, and are implemented in conjunction with a display monitor in the user interface and display 50.

One high-level language is defined in the front end and a second is defined in a back end. According to an embodiment of the present invention, in the front end. a text-based language which employs a text editor that creates ASCII files can be used to dynamically create a device driver and a graphical user display for the new device. One exemplary text- based language is a data definition language (DDL) defined according to the present invention. Although the invention is described with reference to using the DDL, it should be understood that one skilled in the art could develop and employ another high-level language to define the text language for adding a new device.

In the front end, the DDL defines a graphic user interface (GUI), functionality, and attributes (those things which can be controlled by a headend operator) using a text file. The DDL text files are definition files which define the attributes of the new device. The front end basically defines what can be found in the new device. In the back end, the commonly known tool command language (TCL) may be employed. The user defines TCL code for implementing protocol conversion and functionality. The user inputs TCL script to provide instructions for controlling the new device and instructions including byte pattern information corresponding to the protocol of the device which allows the user to read the device or set command values for the device. The TCL script can then decode and encode the protocol. The DDL text files are high-level text (e.g., definition language) which point to addresses where TCL script is located and provide a template of what the new device can do and what type of data it has. The script defines high-level macros which provide control features for the new device including, but not limited to, the device attributes, the names, controls, and monitoring points of the attributes, the I/O interfacing, an on/off switch, and the presentation of the device on the user interface. The address of the TCL script is the beginning of a procedure (i.e., a series of instructions), which corresponds to the DDL text file.

A user defines the procedures for the new device in TCL script through the user interface 50 as shown in step S2. The HMS 40 reads the TCL script and places the script in memory in step S3, which may, illustratively, be a procedure table 60 as shown in the figure 1. The procedure table 60 maps high-level DDL text files to a series of instructions in TCL code corresponding to the DDL text files. The DDL text files are defined via the user interface 50 in step S4 and stored in memory 70 in step S5. It should be understood that steps S2 and S3 can either precede or follow steps S4 and S5.

The memory 60 may be RAM, ROM, erasable memory and the like, and can the take the form of a dynamic or static storage device. However, in the event that future modification of the TCL script may be desired, a memory type which can be overwritten or erased is preferably employed. According to the illustrative implementation of the present invention described above with respect to figure 1. the memory 60 is configured as a procedure table similar to a database. The memory 70, like the memory 60. may take on a variety of memory types.

After the instructions for the new device have been defined, when the HMS 40 polls the system or otherwise operates, it recognizes that a new script file associated with a new device has been added to the headend. Next, at step S6, the HMS of the host computer 40 retrieves the DDL text file from memory 70 and reads the DDL text file. Then, HMS 40 accesses the TCL script corresponding to the DDL text file stored in the procedure table 60. The assembly/interpreter in the HMS 40 parses the DDL text file and creates a C++ interface to a TCL procedure table 60.

At step S7. when HMS 40 accesses the procedure table 60, DDL text files are converted to TCL procedure. At step S8, the assembly/interpreter (e.g., a command interpreter) of the HMS 40 interprets the TCL script in the procedure table 60 corresponding to the DDL text file and executes the procedure defined by the TCL script to control and otherwise adapt the new device to the headend. Instructions are communicated to and from the new device over the communication bus 30. Thus, the device is integrated into the headend. The HMS 40 is a distributed object-oriented system, so the new device becomes publicly available across the system. Consequently, high-level macros in TCL and high-level text files in DDL can be written to control new or third party devices.

The HMS 40 serves as a "traffic cop" or conduit for communication to/from the DDL text from/to the TCL script and to/from the TCL script from/to the new device. In high-level terms, the HMS is similar to a word processor or spreadsheet in that the HMS knows nothing about the devices involved. The HMS has no knowledge about devices that are in the headend, such as how the devices are connected, the function of the devices, and the unique attributes of the device.

Illustratively, a new device may have on/off control, output loss control, input loss control, and power ON criteria which must be defined. The user defining the new device may create a DDL text file called POWER STATE. In TCL code, the user would create a procedure in TCL script. Thus, when the power state is defined in DDL text. POWER STATE refers to a procedure in TCL code defined in TCL script. When the HMS 40 recognizes that a new file exists (i.e., new device or functionality has been added), it retrieves the POWER STATE file from memory 70, reads the POWER STATE file and accesses the TCL script corresponding to POWER STATE stored in the procedure table 60. The assembly/interpreter of the HMS 40 interprets the TCL script in the procedure table 60 corresponding to POWER STATE and executes the procedure defined by the TCL script to control the power state of the new device. The TCL script corresponding to POWER STATE builds the appropriate bit map for the device protocol so that the power state attribute of the device can be manipulated. Thus, the TCL script when executed places the data defined in the DDL text in the appropriate place in the bit stream and creates the appropriate bit map to allow the device to be controlled.

Similarly, information can be received from the device performing the reverse process described with respect to the power state. For example, if the user requests status information from the device, for example using a READSTATUS command, the device acknowledges receipt and sends back a byte pattern representing the status state. Then, the assembly/interpreter in HMS would disassemble the bit pattern and interpret the read status information from the device in accordance with the READSTATUS script. Next, the assembly/interpreter presents the status state information to the DDL. That is, the appropriate values of the read status attribute are set in the DDL.

The DDL is a distributed object oriented database based on ASCII files with a variety of features. The DDL contains no functioning code. The DDL is used for parametrization (configuration), as a generic database for headend operators, and as a specialized database for devices, channels, alarms, backup, etc. Also, the DDL is used as a graphic user interface (GUI) definition language.

Associated with DDL are concepts and definitions. A resource is the most elementary piece of data in DDL. A resource is never declared independently of any other data. Rather, a resource is part of a more complex structure such as a class or singleton. A class is a group of resources that define a new type (a functional device such as a toaster, modulator, upconverter, etc.). A type defines all the attributes of a device (e.g., a modulator). An instance is an occurrence of a type, for example different instances of a modulator correspond to individual channels such as HBO, ESPN, etc. A group of channels may then all use the same class definition type, but they would represent different instances of the type. A singleton is a class that has one single instance and is a way to group related parameters. The single instance does not need to be declared because its name is the same as the class name. A device class is a specialized class to define devices. A schema is a class, device or singleton.

A resource may have four values including a real value, a temporary value, an initial value and a last value. A domain defines a set of values and can be a range (e.g., integers between 20 and 29), an enumeration (e.g., the floats 1.2, 4.67, and 4.0), or a regular expression. A tag is a free format string which is attached to each instance and resource.

The DDL provides several interesting features. In a dynamic data definition, schemas are interpreted, not compiled. The HMS provides a DDL-TCL bridge which enables the TCL scripts to manipulate DDL objects. A user of DDL can dynamically build GUI panels for data editing. The DDL also provides an IDL (interface definition language) interface which allows object (an object is an instance as described above) distribution on a CORBA (common object request broker architecture) bus. IDL and CORBA are defined in the OMG (object management group) CORBA 2.0 specification, and readily known and available to those of ordinary skill in the art.

The HMS contains a process called a DDL server that manages (reads, writes, distributes) DDL objects and executes TCL scripts to manipulate the objects. The DDL server can serve many classes, devices, and singletons. Each class, device and singleton is served by one DDL server.

As discussed previously, DDL is a text-based language which employs a text editor that creates ASCII files. In an illustrative embodiment, the DDL contains three types of DDL text files including declaration files, GUI files, and data files. Declaration files contain data definitions and their default value settings. The GUI files describe how the data is presented to the user for editing. Data files contain data and can be edited. Declaration and GUI files cannot be edited, and are manually created and maintained.

The syntax of DDL includes reserved words such as class, instance, int, string boolean, etc. DDL identifiers may contain letters (a to z or A to Z), numbers (0 to 9), and underlines and either start with a letter or an underline. The syntax for an identifier is "[a-zA-Z_].[a-zA- Z0-9J".

Domains can be defined as "range <min, max>" where min or max can be omitted. Some examples include "range <10,100>" (integer between 10 and 10), and "range <5.3,>" (float > 5.3). Also, a domain can be defined as an enumeration as "in {valuel, value2, ..., valueN}" or as a regular expression (regexp). Examples of enumerations include "in { 1, 3, 5, 9}" and "in {"toto", "titi", "tata"}".

There may be several basic scalar types such as int, float, string, multi-string, and boolean. The syntax for a scalar resource is "<type> <resource_name> [<validation_domain>] = <default_.value>". Some examples include "int AFC in {0, 1, 2} = 3", "float frequency range <0,100>", "int bar range <0,>", "string AFC in {"OFF". "AVG", "XXX"} = "no_. name"", and "boolean lets_go = true". Boolean scalars have no validation range.

List resources are a collection of scalar values with domain definitions. Lists are dynamic so the number of elements is not fixed. Examples of list resources include "list string users = {"toto", "titi", "tata"}" and "list int buttonstate {2, 4. 6, 8} = {4,8}".

The word "typedef introduces a new type that can be used anywhere in the DDL file. An example would be "typedef int freq_ range range <0,100> =0". The syntax for a typedef type is "like <type> name [ = <value>]" and examples include "like freq_. range freq =3" and "like freq_range freq". Typedefs are not GUI editable.

An example of a class definition is shown below. class user string name ^: int age =12;

An example of a singleton definition is depicted below. typedef phoneNumber regexp "([0-9] {3}) [0-9] {7}"; singleton fax { type phoneNumber number; string [] dest ist; }

A method is a behavior attached to a class by calling a TCL script. Before the TCL script is executed, a global TCL variable is set to the instance on which the method has been called so that the script can manipulate the state of the instance. An example of a method is shown below. class Foo { int i <0,100> = 40; method print executes "print foo.tcl";

};

An IDL interface exists to call a method on an instance, for example: "my_class->CallMethod

("meeting", "Sam Mark Vincent")"; where "Sam Mark Vincent" may be client data for the TCL script.

According to one embodiment of the DDL, an action can be attached to a resource. An action defines the behavior of the application whenever the (real) value of a resource changes.

If the action specifies a domain, it is executed only if the value enters or leaves the domain.

Several actions can be attached to the same value. When a real value is modified, all actions attached to it are examined and processed. An example is shown below. class Heater { int temp <0.100> = 12; float freq <0.123> = 2,21 action LT when temp crosses <0,10> executes "heater.alarm.tempLow"; action HT when temp crosses <90,100> executes "heater.alarm.tempHigh"; action NT when temp crosses <15,20> executes "heater.alarm.tempNorm"; action TEMP when freq changes executes "freq. alarm";

}; An instance declaration can override an 'action domain' definition, but cannot declare a new action.

Inheritance allows a new schema to be created by specializing an existing schema. An example is set forth below. class MODULATOR momjs SaDevice { freq

} ;

Multiple inheritance is not available in the above embodiment of DDL, so only one mom exists. However, one skilled in the art could design a text language where multiple moms exist. It is possible to provide for a schema extension by adding resources to a previously declared schema. In contrast to inheritance, schema extension does not result in the creation of a new schema. The schema extension feature allows a user to modify the DDL predefined classes without having to modify other DDL text files. An example of a schema extension is set forth below.

extend class USER { int salary <100 000, > = 150000;

};

When an instance is declared, all its resources are set to the default values specified in the class declaration. However, some values may be overridden in the instance declaration.

The syntax is shown below instance <class_name> [<instance_id>] [ { [<resource_name> = <value>;] } ];

The following code creates two instances of the class MODULATOR. instance MODULATOR { freq = 12;

} instance MODULATOR mod2 { freq = 12; }

For singletons, the syntax is the same, but an additional instance is not created. Instead, the mono-instance is overridden.

Devices are a special kind of class. In this illustrative embodiment of the present invention, all devices inherit from the class SADevice (e.g., a Scientific-Atlanta, Inc. device). Thus, for a Scientific-Atlanta, Inc. system SADevice may be defined as a standard schema.

In a class or device, if the word 'key' precedes a resource declaration, the resource becomes the key for that class or device. Two instances cannot have the same value for that resource and a class or device cannot have more than one key.

DDL objects can be accessed through an IDL interface. The granularity for the IDL interface is the instance/device/singleton. There is no IDL interface for resources which are accessed through their class. An example of IDL mapping and distribution is set forth below. interface Class {

Instance Getlnstance (I) Instance Getlnstance (ID)

} interface Interface {

Setlnt

SetString

SetBoolean \ I

If two or more users are looking at the same data and the value of the data changes, the change will affect each user concurrently.

The assembly/interpreter in the HMS 40 includes a DDL parser which parses DDL text files and creates the corresponding C++ and TCL object. The DDL parser tries to ignore errors in files. For data definition errors (e.g., wrong field name, variable), the parser ignores the errors, but issues a warning and continues parsing the file. When the parser finds a syntax error, it stops parsing the file.

A TCL interpreter is embedded in each DDL server. As discussed previously, the DDL server runs a TCL script that manipulates DDL objects. For each DDL object, the DDL interpreter creates C++ and TCL objects. Thus, a linkage is created from DDL to TCL via the

C++. Several examples are provided below in the table.

DDL object C++ instance TCL object class toto SaClass object 'toto' device toaster Device object 'toaster' singleton param Singleton object 'param' instance ... Instance object '<instance's internal id>'

In fact, a TCL command exists for each object. The command name is the object's id. Each

C++ instance has a unique ID of the form: "<class/singleton/device name><an_ unsigned long>". For each TCL class or device, the following TCL methods are defined: get nstances : return a list of TCL instances. The syntax is "<class_ id> getjnstances". For each of the instances and singletons, the following illustrative methods may be defined.

- set, get : to change/retrieve the real value

- seUmp, get_tmp

- set_last, geUast

- seUnitial, geunitial - tag

As noted earlier, the DDL can provide GUI files to define DDL panels or screens generated by HMS. A DDL panel is a graphical interface that allows displaying and editing of

DDL data. In a DDL panel, only one instance can be displayed and edited at a time. Since a

DDL resource has four values (default, initial, actual, intermediate), there are sixteen combinations of display/edit values which leads to sixteen possible DDL panels. Three relevant combinations are listed in the table below.

Display Edit Application Panel type real intermediate device control control panel initial initial device configuration config panel real real parameters, users, etc. edit panel

Figure 3 provides an illustrative representation of a DDL control panel.

A DDL panel is divided into four areas including panel identification, instance identification, edit area, and command area. The panel identification identifies the title of the panel. For example, in figure 3, the panel title is "control" displayed on the panel title bar.

The instance identification is the level at the top of the window that identifies which instance is being edited. The instance being edited in figure 3 is Status which is highlighted. The edit area is something that resembles a tab widget and is the area of the screen containing the resources and their present values as shown in figure 3. The number of tabs and their contents is defined by DDL GUI text. Each tab contains a subset of class resources. The tabs defined in figure 3 include status, info, options, misc setup, audio, video, etc. For each resource, a label for the name of the resource and a label for the value of the resource (for lists a list widget) is included. In figure 3, several resources are listed including RF, IF, VMOD, etc. and their values are 0.000000. If the resource is RW (i.e., read/write) then it can be edited using an edit widget. If the resource has a validation set, the edit widget is a combo box, and if it does not have a validation set, the edit widget depends on the resource's type and the user preferences. The table below shows the resource type and the available edit widget.

Resource type possible edit widget int text, slider float text, slider string Mono/multi line text editor boolean two radio buttons static lists a list widget dynamic lists a text for the number of elements

The command area provides a set of buttons at the bottom of the window as shown in Figure 3. Exemplary buttons include [ok] which sends the contents of the edit widgets to the DDL server, [cancel] which closes the panel, and [clear] which clears all edit widgets. In figure 3, the [ok] and [cancel] buttons are found in the command area.

A panel definition language in DDL describes the DDL panel layouts and behavior including what (real, default, intermediate, initial) are displayed/edited, how the tabs are organized, how the resources are displayed/edited (text, slider, toggle, etc.), and the resource mode. The resource mode may be read only (RO) or read/write (RW). An illustrative syntax for a modulator is shown below.

Interface control for Modulator {

PanellD "Control"; // the string displayed on the panel title bar

InstancelD name; // the name of the resource used to identify the instance displays REAL; // displays the real edits INTERMEDIATE; //

// tabs definition section AUDIO { left RW slider right RW editor mono RW editor

} section NOTES { notes RW multi lines section MISC { tmp RO }

For classes, a resource can be added to an already defined panel without having to modify the original file by using the extend feature.

As mentioned previously, DDL can be used to define classes. The DDL also can define panels as just discussed. The panel is built on top of the class and is a mirror image of the class.

As with the DDL text files described previously, the GUI definition files point to macros in TCL script. The TCL script through HMS generates the panels for the GUI. The panels will include all the DDL data defined in the DDL text field for the particular instance defined in the GUI data. As described, fields defined in the GUI will appear on the screen. For example, in figure 3, in the GUI definition, the user has defined the attribute RF for the instance status to appear. If the user modifies a field, the value of the attribute is then modified in the DDL text file.

The GUI can serve two functions. It provides an easy mechanism to allow the user to modify the values of attributes and it can display the current state of the attributes of a device.

In another embodiment, a schematic representation of the device functionality and interconnections could also be displayed and modified using a GUI.

While particular embodiments of the present invention have been described and illustrated, it should be understood that the invention is not limited thereto since modifications may be made by persons skilled in the art. The present application contemplates any and all modifications that fall within the spirit and scope of the underlying invention disclosed and claimed herein.

Claims

WHAT IS CLAIMED IS:

1. A headend system comprising: a device for providing a function for the headend system, said device having a protocol incompatible with said headend system; a host computer, operatively coupled to said device; a user interface, operatively coupled to said host computer, for inputting a first high- level instruction and second high-level instructions to integrate said device with said headend system, the first high-level instruction being higher than the second high level instructions and the first high-level instruction identifying the second high-level instructions corresponding to the first high-level instruction; a first memory, operatively coupled to said host computer, for storing the first high- level instruction; and a second memory, operatively coupled to said host computer, for storing the second high-level instructions, and wherein said host computer accesses said first memory and second memory and converts the first high-level instruction to the second high-level instructions and executes the second high- level instructions to control said device.

2. The headend system according to claim 1, wherein the second high-level instructions include a script file.

3. The headend system according to claim 1, wherein the first high-level instruction is a text file.

4. The headend system according to claim 1, wherein the second high-level instructions comprise tool command language (TCL) instructions.

5. The headend system according to claim 1, wherein said host computer includes an assembly interpreter for interpreting and executing the second high-level instructions.

6. The headend system according to claim 1 , wherein the device is a plug-in module.

7. The headend system according to claim 1, wherein the user interface provides a text editor that creates an ASCII file as the first high-level instruction which is stored in said first memory.

8. The headend system according to claim 1, wherein said second memory is a procedure table.

9. The headend system according to claim 1 , wherein the first high-level instruction points to the address where a procedure defined by the second high-level instructions are stored in said second memory.

10. The headend system according to claim 1, wherein the first high-level instruction is in a text language.

11. The headend system according to claim 1 , wherein said host computer receives data from said device, interprets the data according to the second high-level instructions and modifies an attribute defined by the first high-level instruction.

12. The headend system according to claim 1, wherein the first high-level instruction includes plural first high-level instructions and the second high-level instructions include sets of second high-level instructions corresponding to each of the first high-level instructions.