US20060206659A1

US20060206659A1 - Reducing Time to Load Device Description in Management of Field Devices

Info

Publication number: US20060206659A1
Application number: US11/306,389
Authority: US
Inventors: Gowtham Anne; Vibhor Tandon; Deepak Bhandiwad; Raghavendra Prasad
Original assignee: Honeywell International Inc
Current assignee: Honeywell International Inc
Priority date: 2005-03-10
Filing date: 2005-12-27
Publication date: 2006-09-14
Also published as: CN100490116C; JP2006253376A; US7579264B2; US20060205153A1; KR20060097540A; CN1832127A

Abstract

According to an aspect of the present invention, a device description is pre-processed to determine the values of various fields of objects needed while providing the user interface. The values are then stored in an intermediate file according to a pre-specified order such that the objects can be loaded quickly when needed (without substantial parsing of the content of the intermediate file).

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention
The present invention generally relates to process control systems, and more specifically to a method and apparatus for reducing time to load device description in management of field devices in process control plants.
2. Related Art
A process control plant generally contains several field devices, which are operable to implement a desired control process (e.g., oil refinery, manufacturing operation, etc.). Examples of field devices include valves, positioners and switches, which are controlled to implement the control process.
There is a general need to manage field devices provided in a process control plant. Management generally refers to tasks such as monitoring and configuration of the devices, and generally entails communication to field devices, viewing various status/configuration information related to the field devices etc.
The status information could provided data related to aspects such as temperature, pressure, extent of opening of a valve, light intensity, whether the device is malfunctioning (e.g., output saturated, input open), configuration values, calibration status, etc., of the field devices. On the other hand, configuration generally causes some parameters in the devices to be set, which in turn may cause the configured device to operate differently consistent with the changed configuration.
A user interface is generally provided to facilitate the management of field devices in process control plants. The user interface provides a convenient interface using which a user can interface with the system and perform desired management tasks. Often, the user interface is based on graphical screens for ease of use, and is in such instances referred to as a graphical user interface (GUI).
Device description (DD) is often provided by a vendor associated with a field device, with the device description indicating the manner in which the status information (or results of execution of the management commands) can be viewed and management commands can be sent (communication to field device). The device description is often provided as a content of a file, which is referred to as a device description (DD) file.
Accordingly, at least in management of field devices consistent with the specification of the corresponding DD, the DD often needs to be loaded (typically, read into appropriate data structures supported in a random access memory) by a program providing various management features. At least to provide quick responses to users, the loading needs to occur quickly.
What is therefore needed is a method and apparatus for reducing time to load device description in the management of field devices in process control plants.

SUMMARY

An aspect of the present invention reduces the time to load description in the management of field devices by pre-processing the device description to determine values corresponding to each attribute, and storing the values in an intermediate file provided on a secondary storage. Thus, the values can be quickly retrieved from the intermediate file and stored in a data structure in a memory, for the field devices of interest.
In an embodiment, the data stored in the intermediate file contains only values corresponding to the attribute, and the values are stored in a specific order such that the values in said second file can be retrieved in that order and stored in a memory to load the device description.
Further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be described with reference to the accompanying drawings, which are described briefly below.
FIG. 1 is a block diagram illustrating an example environment in which various aspects of the present invention can be implemented.
FIG. 2 is a block diagram illustrating the manner in which device description (DD) is loaded in one prior embodiment.
FIG. 3 contains the definition of a variable in a DD, which is used to illustrate various features of the present invention.
FIG. 4A is a flowchart illustrating the manner in which the time to load device description is reduced in an embodiment of the present invention.
FIG. 4B is a block diagram illustrating the manner in which the time to load device description is reduced in an embodiment of the present invention.
FIG. 5 contains the object definition corresponding to the DD portion of FIG. 3.
FIG. 6 illustrates the data stored for a DD portion in an embodiment of the present invention.
FIG. 7 illustrates the manner in which a DD object is constructed from intermediate file.
FIG. 8 is a block diagram of an example digital processing system in which various features of the present invention are operative by execution of software instructions.

DETAILED DESCRIPTION

1. Overview
According to an aspect of the present invention, the device description (DD) available in a DD file is pre-processed to determine the values of various fields (of data structures used in providing various management features such as user interface, communication to field device), and the values are stored in another file. The field values can be quickly retrieved and stored to create the data structures when needed (e.g., soon after a user action requires the data structure). Due to the avoidance of need for extensive processing (for parsing and determining the values) when the data structures are needed, the DD can be quickly loaded.
In one embodiment, values are stored according to a specific sequence such that the data values can be retrieved and stored associated with the corresponding attributes in the same sequence. Due to the use of such pre-specified sequence, the overhead associated with parsing task is further reduced.
Several aspects of the invention are described below with reference to examples for illustration. It should be understood that numerous specific details, relationships, and methods are set forth to provide a full understanding of the invention. One skilled in the relevant art, however, will readily recognize that the invention can be practiced without one or more of the specific details, or with other methods, etc. In other instances, well known structures or operations are not shown in detail to avoid obscuring the invention.
2. Example Environment
FIG. 1 is a block diagram illustrating the details of an example environment in which several aspects of the present invention can be implemented. The block diagram is shown containing field devices 110A through 110Z, control network 130, control system 140, central server 150, database server 170, and client systems 180A through 180Y. Each block is described below in detail.
Control network 130 connects each of central server 150 and control system 140 with field devices 110A through 110Z. Control network 130 may contain network devices (e.g., multiplexers, modems, termination panels, etc.,) operating according to one or more protocols such as HART, Control Net, and Foundation Field Bus well known in the relevant arts.
Control system 140 issues commands to control the operation of field devices 110A through 110Z. The field devices are controlled to implement a desired control process (e.g., oil refinery, manufacturing plant). Database server 170 provides a central repository for storing information related to configuration of field devices, status of field devices, maintenance schedules, historic status/menu information, etc.
Field devices 110A through 110Z perform various operations under the control of control system 140 to implement a desired manufacturing process. In addition (or as a part of supporting such a process), each field device may be implemented to support various management commands received from central server 150. Some of the management commands may merely request information (e.g., measured pressure), and some of the commands cause the configuration to be altered (e.g., a valve might be caused to be opened).
Central server 150 receives status information from various field devices 110A through 110Z through control network 130, and makes the information available to users via client systems 180A through 180Y. Commands may be issued to the field devices to retrieve the desired information. In an embodiment, information corresponding to only the subscribed information elements (including those covered by subscribed tree portions) is retrieved.
Client systems 180A through 180Y provides a user interface using which users may manage field devices 110A through 110Z. Broadly, each client system accesses the device description (DD) for a corresponding device type to determine the initial display menu to be generated for each selected device. As the user navigates the menu, the next menu portion to display is again determined based on the DD.
In case the DD indicates that the menu portion to be displayed is static (i.e., which does not change), client system 180A displays the corresponding menu (after potentially retrieving any necessary values from the field devices). In case the DD indicates that the menu portion to be displayed is dynamic (i.e., the structure itself depends on the present/then value of a variable(s)), client system 180A subscribes to central server 150 for specific tree portion of interest (typically what a user has presently selected the tree portion), and receives the corresponding information from central server 150. The received information may contain the menu/tree to display as well as values of information elements accessible by the tree. The received information is displayed using a suitable user interface.
At least in such situations, it may be desirable to quickly load desired DD portions (corresponding to static portions as well as the portion which indicates the specific sub-portions which are dynamic) in client system 180A such that responses can be quickly provided to users. Various aspects of the present invention enable quick loading of the DD information, as described in sections below. The features of the invention will be cleared by comparison to a prior embodiment which does not use one or more features of the present invention. Accordingly, the description is continued with respect to the details of a prior embodiment.
3. Prior Embodiment
FIG. 2 is a block diagram illustrating the manner in which a device description (DD) is loaded in a prior embodiment. As shown there, DD file 210 is parsed by DD deciphering application 230 and the retrieved data is stored in in-memory-objects 250 (data structure). The problems with such a parsing approach are illustrated with respect to the example of FIG. 3. As shown there, the DD element represents a variable lower_value with attributes HELP, CLASS, LABEL, VALIDITY, HANDLING, and TYPE in lines 315, 320, 330, 340, 350 and 360 respectively.
Continuing with the manner in which DD deciphering application 230 of FIG. 2 may parse a DD file for the DD element of FIG. 3 while loading the information into in-memory-object 250, it may be noted that some level of parsing may be needed to identify the desired DD element. Additional parsing may be performed as described below.
DD deciphering application 230 identifies the type of the DD element as a variable type by recognizing the extension VARIABLE in line 311. As a part of loading, an object of type Variable, containing a list of fields corresponding to a attribute (specified in FIG. 3), are created and the corresponding value is stored, as described below.
DD deciphering application 230 parses the attribute 315 (information) and identifies it as a help item, having a value of “Meter lower value”. Thus, a field with a value type of STRING is created, and the field is set to the parsed value. Similarly, each line of FIG. 3 is parsed, a field is created, and the corresponding value is stored in the created field.
Once the parsing is complete, in-memory-Object 250 contains the information of the DD. This in-memory-Object is used for further references in processing various user requests. For example, (user) selection of menu portions representing dynamic menus causes client system 180A to examine in-memory-object 250 to determine that the selected portion represents a dynamic menu and subscribes to central server 150 for updated information on the dynamic menu.
It should be appreciated that a DD contains many such items, which need to be parsed and stored into data structures, as explained above. Such processing may require extensive processing power and thus time in responding to various user actions. The resulting delays may not be acceptable at least in some environments. The manner in which such delays can be avoided is described below with respect to various aspects of the present invention.
4. Reducing Loading Time
FIG. 4A is a flowchart illustrating the manner in which a device description can be loaded into a memory according to various aspects of the present invention. The flowchart is described with respect to FIGS. 1 and 4B (which is a block diagram illustrating the processing of DD information) merely for illustration. At least some of the features can be implemented in various other environments, as will be apparent to one skilled in the relevant arts by reading the description provided herein.
Continuing with combined reference to FIGS. 4A and 4B, the flowchart begins in step 401, in which control immediately passes to step 410. In step 410, DD deciphering application 480 parses device description (DD) file 460 to create in-memory-objects 450. DD file 460, DD deciphering application 480 and in-memory-objects 450 may respectively have similar characteristics as DD file 210, DD deciphering application 230 and in-memory-objects 250, and the description is not repeated in the interest of conciseness.
It should be understood that the parsing operation represents a pre-processing step in which the values of the attribute are pre-determined such that the values are available for creating the objects quickly when actually required for providing the user interface. While the objects are created in this example, for determining the values of attribute, it should be understood that alternative approaches can be used to determine the attribute values during the pre-processing operation.
In step 420, optimization module 470 stores data representing only the values of the fields of the in-memory-objects in an intermediate file in a specific order. The order definition specifies the specific fields with which each of the values is associated.
In step 430, optimization module 470 retrieves values of the fields from the intermediate file, and stores associated with the corresponding according to the order used in step 420. Due to the use of such order, the processing requirements (and thus time delay) are substantially reduced. Accordingly, the remaining parts of the management may be designed to interface with optimization module 470 when specific objects need to be created. The flowchart ends in step 449.
Also, in general, the creation of objects depends on the specific operating environment (including the system software implementing the programming environment and operating system). However, the retrieving step of 430 needs to be consistent with the storing of step 420. As noted above, only the attribute values are stored according to an aspect of the present invention. The manner in which such storing can be performed in an embodiment is described below in further detail.
5. Storing Attribute Values
To appreciate the manner in which values (contained in fields of the data structure) of attribute are stored in an embodiment, it is helpful to first note that the device description (DD) is first processed to assign a unique identifier to each element (including sub-element, defined as an attribute of the element). The unique identifier is then used to match the elements across the DD.
Also, in an embodiment, to determine the values corresponding to the attribute during pre-processing, a single object (DDobject) is created for each DD file, with the DDobject containing a list of objects (Items), with each object representing an item of the corresponding device description. Each Item in turn contains a list of further objects (AttributeObject), with each AttributeObject containing the information corresponding to each attribute of the items.
The object representation corresponding to the device description (DD) of FIG. 3 is contained in FIG. 5, assuming that the DD element there is the only element in the DD (for conciseness of explanation). It may be appreciated that each field (in each of lines 525-531, 546-556) is characterized by a name and a corresponding value (among other properties of the field/attribute). The object representation is briefly described below.
Lines 510-517 represent a DD object containing list of all the items in the entire device description. In this example the item list is assumed to contain one item (lower_value in FIG. 3 and the content of the item are described in further detail below.
Lines 521-533 (object type of Item) contain the start of object definition of variable lower_value of FIG. 3. It is assumed that the element (variable) was assigned an identifier of 16000 as shown in line 525. The item type is shown equaling 1 assuming a convention of 1 for variable, 2 for method, and 3 for menu. Line 529 indicates that the name of this item equals lower_value (consistent with the definition in line 310 of FIG. 3).
Line 531 indicates (though not shown) that there are 6 attribute for this element (consistent with the content of lines 315-360 of FIG. 3), and accordingly 6 DD attribute objects follow. For illustration, only the description of object corresponding to attribute HELP in line 315 is described below in further detail.
Lines 541-558 contain the object definition for the first attribute HELP (line 315 of FIG. 3). Line 546 indicates that the corresponding object identifier equals 100 and the type is set to 10 assuming a value of 10 is used for help (other fields such as handling are assigned with number 11, which can have the values like READ_ONLY, READ_WRITE, WRITE_ONLY. Etc.).
The value is set equal to “Meter lower value” in line 550. Since this is not a conditional attribute (unlike in line 340), IsItAConditional field is set equal to false in line 552. In line 556 the ConditionalObject field is shown set to null, since the attribute is inapplicable due to the value set in line 552.
For conciseness, the details of the remaining attribute of the DD Item are not shown and described in further detail. However, it should be appreciated that the value of each attribute (including the complex attribute such as conditional attribute 340 of FIG. 3) is determined when the in-memory objects are created in step 410. The description is continued with the manner in which the above described information is stored in an intermediate file in an embodiment of the present invention.
FIG. 6 contains the data which is stored in intermediate file 490 according to one convention. The text in the parenthesis is merely for explanation, and not actually stored in the file. Thus, line 611 indicates there is only one object corresponding to the entire DD file. The remaining lines of FIG. 6 contain the fields and values stored for that one object for the DD item.
Lines (fields) 613, 615 and 619 contain values corresponding to lines 525, 527 and 529 of FIG. 5. Line 617 further indicate the size of the item value (text) of line 619. Line 625 indicates that there are 6 attribute for this DD item, and lines 627-650 contain the values for the first attribute. The values in lines 627, 629, 635, 640 and 650 are respectively set according to lines 548, 546, 535, 552 and 556, with line 631 indicating the number of characters (size) of attribute 635. The data (line 611-650) may be stored in intermediate file 490.
By examining FIGS. 5 and 6, it will be readily appreciated that the order of storing in FIG. 6 determines the specific attribute with which each value is associated. Accordingly, optimization module 470 can be designed to create the objects (and also retrieve the values (from the fields) accordingly) taking advantage of such a convention. Using storage techniques such as those above, optimization module 470 may reduce the time to load device description, as described in further detail below.
6. Optimization Module
It may be readily appreciated that optimization module 470 may use storage techniques such as those described above to store only the attribute values for the entire device description of any field device. It may be further appreciated that the encoding approach of the stored data contains sufficient information to create the general structure of the entire objects due to the use of the specific sequence (as described above with respect to FIG. 6). The optimization module 470 may construct DD objects (In memory DD Object) from the specific sequence stored in a short interval. The manner in which the stored data is retrieved and a DD object is constructed is illustrated below in further detail.
FIG. 7 illustrates the manner in which a DD object is constructed from intermediate file 490. Optimization module 470 reads line 611 (corresponding to size of item list) and construct line number 701-704 representing item list. Since the item list value represents 1 (from line 611), optimization module 470 begin a first loop (typically, the number of time loops are executed corresponds to the value in line 611) executed in line 706.
Within the first loop, optimization module 470 reads line 613 (corresponding to item type) creates a variable (corresponding to value 1) type object as represented in line 707. In line 709 the IDENTIFIER of the item is set to 16000 in accordance with line 615. Optimization module 470 reads line 617 (indicating size of the value) and sets the value of the item on line 711 equal to following 11 bytes accessed subsequently.
Number of attributes for the item lower_value is indicated in field (size of ListOfAttributess) in line 625. Accordingly, optimization module 470 begins second loop (in line 715). Second loop is repeated 6 times corresponding to each attribute. However lines 718-746 represent a object corresponding to attribute HELP encoded in lines 627-649.
Corresponding to line 627, optimization module 470 creates a object new AttributeObject illustrated in line 718 and sets attribute type to 10 (HELP) in line 720. The IDENTIFIER, value, IsItAConditional, ConditionalObject fields are set in lines 732, 738,742, and 746 respectively from lines 629, 631 and 635,640 and 650.
Similarly the other attribute of the of item lower_values are constructed from intermediate file 490. Since only the attribute values are retrieved according to the convention (specific sequence) described above, the parsing overhead is substantially reduced compared to the prior approach described above. As a result, the response to time for various user actions is reduced.
While the above description is provided with respect to a simple DD file portion for illustration, it should be appreciated that the approaches above can be extended to complex content in file portions as well, as will be apparent to one skilled in the relevant arts by reading the disclosure provided herein. For example, in case of file portions containing objects which further reference other objects, techniques such as object serialization (commonly used in Java-type environments) can be used to store the objects in the form of intermediate data, and the intermediate data can be de-serialized (in a known way) to re-form the in-memory objects 450.
It should be appreciated that various aspects of the present invention are described with respect to storing (attribute values) in a single file merely for illustration. However, multiple files can be stored depending on the design choices/requirements, without departing from the scope and spirit of various aspects of the present invention. In addition, while the user interface is described as being provided within client system 180A merely for illustration, the same can potentially be implemented even in other systems (e.g., central server 150), as will be apparent to one skilled in the relevant arts by reading the disclosure provided herein.
It should be further appreciated that the features described above can be implemented in various digital processing systems. The description is continued with respect to an embodiment in which various features are operative when software instructions are executed.
7. Digital Processing System
FIG. 8 is a block diagram illustrating the details of digital processing system 800 in which various aspects of the present invention are operative by execution of appropriate software instructions. Digital processing system 800 may correspond to central server 150 or client system 180A in which various features of the present invention can be implemented.
Digital processing system 800 may contain one or more processors such as central processing unit (CPU) 810, random access memory (RAM) 820, secondary memory 830, graphics controller 860, display unit 870, network interface 880, and input interface 890. All the components except display unit 870 may communicate with each other over communication path 850, which may contain several buses as is well known in the relevant arts. The components of FIG. 8 are described below in further detail.
CPU 810 may execute instructions stored in RAM 820 to provide several features of the present invention. CPU 810 may contain multiple processing units, with each processing unit potentially being designed for a specific task. Alternatively, CPU 810 may contain only a single general purpose processing unit. RAM 820 may receive instructions from secondary memory 830 using communication path 850, and also supports the objects while the user interface is provided.
Graphics controller 860 generates display signals (e.g., in RGB format) to display unit 870 based on data/instructions received from CPU 810. Display unit 870 contains a display screen to display the images defined by the display signals. Input interface 890 may correspond to a key_board and/or mouse. The display unit and input interface can be used to provide a suitable interface to manage field devices according to various aspects of the present invention.
Network interface 880 may contain one or more physical interfaces, which provide connectivity to various control networks as well as client systems providing user interface 210. For example, network interface 880 may enable central server 150 to interface with both the control network and a LAN on which client systems are connected.
Secondary memory 830 (characterized by non-volatile storage) may contain hard drive 835, flash memory 836 and removable storage drive 837. Secondary memory 830 may store the data and software instructions (e.g., methods instantiated by each of client system), which enable digital processing system 800 to provide several features in accordance with the present invention. Some or all of the data and instructions may be provided on removable storage unit 840, and the data and instructions may be read and provided by removable storage drive 837 to CPU 810. Floppy drive, magnetic tape drive, CD_ROM drive, DVD Drive, Flash memory, removable memory chip (PCMCIA Card, EPROM) are examples of such removable storage drive 837.
Removable storage unit 840 may be implemented using medium and storage format compatible with removable storage drive 837 such that removable storage drive 837 can read the data and instructions. Thus, removable storage unit 840 includes a computer readable storage medium having stored therein computer software and/or data.
In this document, the term “computer program product” is used to generally refer to removable storage unit 840 or hard disk installed in hard drive 835. These computer program products are means for providing software to digital processing system 800. CPU 810 may retrieve the software instructions, and execute the instructions to provide various features of the present invention described above.
8. Conclusion
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

1. A method of facilitating loading of a device description into a data structure in a memory in the management of a plurality of field devices in a process control plant, said data structure containing a plurality of fields to store information contained in said device description, said method comprising:

pre-processing said device description to determine values corresponding to said plurality of fields; and

storing said values in an intermediate file provided on a secondary storage,

wherein said values can be retrieved from said intermediate file and stored in said data structure in said memory.

2. The method of claim 1, wherein each field is characterized by a name and a value, wherein data stored in said intermediate file comprises only values corresponding to said plurality of fields, wherein said values are stored in a specific order such that said values in said intermediate file can be retrieved and associated with corresponding fields while loading said device description.

3. The method of claim 2, wherein said device description is represented by a plurality of data structures stored in said memory, wherein each of said plurality of data structures comprises a corresponding set of fields, wherein said set of fields are contained in said plurality of fields.

4. The method of claim 3, wherein each of said plurality of data structures comprises a corresponding one of a plurality of objects.

5. The method of claim 4, wherein said pre-processing comprises loading said device description into said plurality of objects, and then performing said storing into said second file from the values stored in said plurality of objects.

6. The method of claim 5, wherein a client system provides said user interface using said second file.

7. A method of loading a device description into a data structure in a memory in the management of a plurality of field devices in a process control plant, said data structure containing a plurality of fields to store information contained in said device description, said method comprising:

retrieving a plurality of values corresponding to said plurality of fields from an intermediate file, wherein said plurality of values are generated by pre-precessing said device description before said device description needs to be loaded into said data structure; and

storing said values associated with corresponding fields of said data structure when said device description needs to be loaded into said data structure.

8. The method of claim 7, wherein each field is characterized by a name and a value, wherein data stored in said intermediate file comprises only values corresponding to said plurality of fields, wherein said values are stored in a specific order such that said values in said intermediate file can be retrieved and associated with corresponding fields while loading said device description.

9. The method of claim 8, wherein said device description is represented by a plurality of data structures stored in said memory, wherein each of said plurality of data structures comprises a corresponding set of fields, wherein said set of fields are contained in said plurality of fields.

10. The method of claim 9, wherein each of said plurality of data structures comprises a corresponding one of a plurality of objects.

11. A computer readable medium carrying one or more sequences of instructions for causing a system to load a device description into a data structure in a memory in the management of a plurality of field devices in a process control plant, said data structure containing a plurality of fields to store information contained in said device description, wherein execution of said one or more sequences of instructions by one or more processors contained in said system causes said one or more processors to perform the actions of:

storing said values in an intermediate file provided on a secondary storage,

wherein said values can be retrieved from said intermediate file and stored in said data structure in said memory during said management.

12. The computer readable medium of claim 11, wherein each of said plurality of fields is characterized by a name and a value, wherein data stored in said intermediate file comprises only values corresponding to said plurality of fields, wherein said values are stored in a specific order establishing corresponds to said name and said value, such that said values in said second file can be retrieved in said specific order and stored in said memory to load said device description.

13. The computer readable medium of claim 12, wherein said device description is represented by a plurality of data structures stored in said memory, wherein each of said plurality of data structures comprises a corresponding set of fields, wherein said set of fields are contained in said plurality of fields.

14. The computer readable medium of claim 13, wherein each of said plurality of data structures comprises a corresponding one of a plurality of objects.

15. The computer readable medium of claim 14, wherein said pre-processing comprises loading said device description into said plurality of objects, and then performing said storing into said second file from the values stored in said plurality of objects.

16. The computer readable medium of claim 15, wherein a client system provides said user interface using said second file.

17. A computer readable medium carrying one or more sequences of instructions for causing a field device to load a device description into a data structure in a memory in the management of a plurality of field devices in a process control plant, said data structure containing a plurality of fields to store information contained in said device description, wherein execution of said one or more sequences of instructions by one or more processors contained in said system causes said one or more processors to perform the actions of:

18. The computer readable medium of claim 17, wherein each attribute is characterized by a name and a value, wherein data stored in said intermediate file comprises only values corresponding to said plurality of fields, wherein said values are stored in a specific order such that said values in said second file can be retrieved and associated with corresponding fields while loading said device description.

19. The computer readable medium of claim 18, wherein said device description is represented by a plurality of data structures stored in said memory, wherein each of said plurality of data structures comprises a corresponding set of fields, wherein said set of fields are contained in said plurality of fields.

20. The computer readable medium of claim 19, wherein each of said plurality of data structures comprises a corresponding one of a plurality of objects.