US20060206659A1 - Reducing Time to Load Device Description in Management of Field Devices - Google Patents
Reducing Time to Load Device Description in Management of Field Devices Download PDFInfo
- Publication number
- US20060206659A1 US20060206659A1 US11/306,389 US30638905A US2006206659A1 US 20060206659 A1 US20060206659 A1 US 20060206659A1 US 30638905 A US30638905 A US 30638905A US 2006206659 A1 US2006206659 A1 US 2006206659A1
- Authority
- US
- United States
- Prior art keywords
- fields
- values
- device description
- stored
- data structure
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 claims description 25
- 238000003860 storage Methods 0.000 claims description 17
- 238000007781 pre-processing Methods 0.000 claims description 8
- 238000004886 process control Methods 0.000 claims description 7
- 230000009471 action Effects 0.000 claims description 5
- 238000012545 processing Methods 0.000 description 18
- 238000005457 optimization Methods 0.000 description 14
- 238000010586 diagram Methods 0.000 description 9
- 238000013459 approach Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 5
- 230000008569 process Effects 0.000 description 4
- 238000012369 In process control Methods 0.000 description 3
- 238000010965 in-process control Methods 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 230000001934 delay Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 229920006395 saturated elastomer Polymers 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H01—ELECTRIC ELEMENTS
- H01L—SEMICONDUCTOR DEVICES NOT COVERED BY CLASS H10
- H01L21/00—Processes or apparatus adapted for the manufacture or treatment of semiconductor or solid state devices or of parts thereof
- H01L21/02—Manufacture or treatment of semiconductor devices or of parts thereof
- H01L21/04—Manufacture or treatment of semiconductor devices or of parts thereof the devices having potential barriers, e.g. a PN junction, depletion layer or carrier concentration layer
- H01L21/18—Manufacture or treatment of semiconductor devices or of parts thereof the devices having potential barriers, e.g. a PN junction, depletion layer or carrier concentration layer the devices having semiconductor bodies comprising elements of Group IV of the Periodic Table or AIIIBV compounds with or without impurities, e.g. doping materials
-
- H—ELECTRICITY
- H01—ELECTRIC ELEMENTS
- H01L—SEMICONDUCTOR DEVICES NOT COVERED BY CLASS H10
- H01L29/00—Semiconductor devices specially adapted for rectifying, amplifying, oscillating or switching and having potential barriers; Capacitors or resistors having potential barriers, e.g. a PN-junction depletion layer or carrier concentration layer; Details of semiconductor bodies or of electrodes thereof ; Multistep manufacturing processes therefor
- H01L29/66—Types of semiconductor device ; Multistep manufacturing processes therefor
- H01L29/66007—Multistep manufacturing processes
- H01L29/66075—Multistep manufacturing processes of devices having semiconductor bodies comprising group 14 or group 13/15 materials
- H01L29/66227—Multistep manufacturing processes of devices having semiconductor bodies comprising group 14 or group 13/15 materials the devices being controllable only by the electric current supplied or the electric potential applied, to an electrode which does not carry the current to be rectified, amplified or switched, e.g. three-terminal devices
- H01L29/66409—Unipolar field-effect transistors
- H01L29/66477—Unipolar field-effect transistors with an insulated gate, i.e. MISFET
- H01L29/66568—Lateral single gate silicon transistors
-
- H—ELECTRICITY
- H01—ELECTRIC ELEMENTS
- H01L—SEMICONDUCTOR DEVICES NOT COVERED BY CLASS H10
- H01L21/00—Processes or apparatus adapted for the manufacture or treatment of semiconductor or solid state devices or of parts thereof
- H01L21/70—Manufacture or treatment of devices consisting of a plurality of solid state components formed in or on a common substrate or of parts thereof; Manufacture of integrated circuit devices or of parts thereof
- H01L21/71—Manufacture of specific parts of devices defined in group H01L21/70
- H01L21/768—Applying interconnections to be used for carrying current between separate components within a device comprising conductors and dielectrics
- H01L21/76838—Applying interconnections to be used for carrying current between separate components within a device comprising conductors and dielectrics characterised by the formation and the after-treatment of the conductors
- H01L21/76885—By forming conductive members before deposition of protective insulating material, e.g. pillars, studs
-
- H—ELECTRICITY
- H01—ELECTRIC ELEMENTS
- H01L—SEMICONDUCTOR DEVICES NOT COVERED BY CLASS H10
- H01L21/00—Processes or apparatus adapted for the manufacture or treatment of semiconductor or solid state devices or of parts thereof
- H01L21/70—Manufacture or treatment of devices consisting of a plurality of solid state components formed in or on a common substrate or of parts thereof; Manufacture of integrated circuit devices or of parts thereof
- H01L21/71—Manufacture of specific parts of devices defined in group H01L21/70
- H01L21/768—Applying interconnections to be used for carrying current between separate components within a device comprising conductors and dielectrics
- H01L21/76897—Formation of self-aligned vias or contact plugs, i.e. involving a lithographically uncritical step
-
- H—ELECTRICITY
- H01—ELECTRIC ELEMENTS
- H01L—SEMICONDUCTOR DEVICES NOT COVERED BY CLASS H10
- H01L21/00—Processes or apparatus adapted for the manufacture or treatment of semiconductor or solid state devices or of parts thereof
- H01L21/70—Manufacture or treatment of devices consisting of a plurality of solid state components formed in or on a common substrate or of parts thereof; Manufacture of integrated circuit devices or of parts thereof
- H01L21/77—Manufacture or treatment of devices consisting of a plurality of solid state components or integrated circuits formed in, or on, a common substrate
- H01L21/78—Manufacture or treatment of devices consisting of a plurality of solid state components or integrated circuits formed in, or on, a common substrate with subsequent division of the substrate into plural individual devices
- H01L21/82—Manufacture or treatment of devices consisting of a plurality of solid state components or integrated circuits formed in, or on, a common substrate with subsequent division of the substrate into plural individual devices to produce devices, e.g. integrated circuits, each consisting of a plurality of components
- H01L21/822—Manufacture or treatment of devices consisting of a plurality of solid state components or integrated circuits formed in, or on, a common substrate with subsequent division of the substrate into plural individual devices to produce devices, e.g. integrated circuits, each consisting of a plurality of components the substrate being a semiconductor, using silicon technology
- H01L21/8232—Field-effect technology
- H01L21/8234—MIS technology, i.e. integration processes of field effect transistors of the conductor-insulator-semiconductor type
- H01L21/8238—Complementary field-effect transistors, e.g. CMOS
- H01L21/823828—Complementary field-effect transistors, e.g. CMOS with a particular manufacturing method of the gate conductors, e.g. particular materials, shapes
-
- H—ELECTRICITY
- H01—ELECTRIC ELEMENTS
- H01L—SEMICONDUCTOR DEVICES NOT COVERED BY CLASS H10
- H01L21/00—Processes or apparatus adapted for the manufacture or treatment of semiconductor or solid state devices or of parts thereof
- H01L21/70—Manufacture or treatment of devices consisting of a plurality of solid state components formed in or on a common substrate or of parts thereof; Manufacture of integrated circuit devices or of parts thereof
- H01L21/77—Manufacture or treatment of devices consisting of a plurality of solid state components or integrated circuits formed in, or on, a common substrate
- H01L21/78—Manufacture or treatment of devices consisting of a plurality of solid state components or integrated circuits formed in, or on, a common substrate with subsequent division of the substrate into plural individual devices
- H01L21/82—Manufacture or treatment of devices consisting of a plurality of solid state components or integrated circuits formed in, or on, a common substrate with subsequent division of the substrate into plural individual devices to produce devices, e.g. integrated circuits, each consisting of a plurality of components
- H01L21/822—Manufacture or treatment of devices consisting of a plurality of solid state components or integrated circuits formed in, or on, a common substrate with subsequent division of the substrate into plural individual devices to produce devices, e.g. integrated circuits, each consisting of a plurality of components the substrate being a semiconductor, using silicon technology
- H01L21/8232—Field-effect technology
- H01L21/8234—MIS technology, i.e. integration processes of field effect transistors of the conductor-insulator-semiconductor type
- H01L21/8238—Complementary field-effect transistors, e.g. CMOS
- H01L21/823871—Complementary field-effect transistors, e.g. CMOS interconnection or wiring or contact manufacturing related aspects
Definitions
- 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.
- 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.).
- a desired control process e.g., oil refinery, manufacturing operation, etc.
- field devices include valves, positioners and switches, which are controlled to implement the control process.
- 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.
- 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.
- 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).
- GUI graphical user interface
- Device description 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 110 A through 110 Z, control network 130 , control system 140 , central server 150 , database server 170 , and client systems 180 A through 180 Y. Each block is described below in detail.
- Control network 130 connects each of central server 150 and control system 140 with field devices 110 A through 110 Z.
- 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 110 A through 110 Z.
- 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 110 A through 110 Z perform various operations under the control of control system 140 to implement a desired manufacturing 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 110 A through 110 Z through control network 130 , and makes the information available to users via client systems 180 A through 180 Y. 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 180 A through 180 Y provides a user interface using which users may manage field devices 110 A through 110 Z.
- 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.
- DD device description
- client system 180 A displays the corresponding menu (after potentially retrieving any necessary values from the field devices).
- client system 180 A 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.
- DD portions corresponding to static portions as well as the portion which indicates the specific sub-portions which are dynamic
- client system 180 A 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 180 A such that responses can be quickly provided to users.
- DD portions corresponding to static portions as well as the portion which indicates the specific sub-portions which are dynamic
- FIG. 2 is a block diagram illustrating the manner in which a device description (DD) is loaded in a prior embodiment.
- 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 .
- 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.
- 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 .
- 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.
- 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 180 A 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.
- 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.
- 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 4 B (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.
- step 401 the flowchart begins in step 401 , in which control immediately passes to step 410 .
- 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.
- 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.
- 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.
- 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 .
- the creation of objects depends on the specific operating environment (including the system software implementing the programming environment and operating system).
- the retrieving step of 430 needs to be consistent with the storing of step 420 .
- 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.
- DD device description
- DDobject a single object
- Items a list of objects
- AttributeObject a list of further objects
- 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.
- 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 .
- each attribute 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.
- 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 .
- 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.
- 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 .
- optimization module 470 reads line 613 (corresponding to item type) creates a variable (corresponding to value 1) type object as represented in line 707 .
- 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.
- 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 .
- 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 .
- 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.
- 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 180 A 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 .
- 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 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.
- removable storage unit 840 includes a computer readable storage medium having stored therein computer software and/or data.
- 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.
Landscapes
- Engineering & Computer Science (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Power Engineering (AREA)
- Physics & Mathematics (AREA)
- Condensed Matter Physics & Semiconductors (AREA)
- General Physics & Mathematics (AREA)
- Manufacturing & Machinery (AREA)
- Computer Hardware Design (AREA)
- Ceramic Engineering (AREA)
- Metal-Oxide And Bipolar Metal-Oxide Semiconductor Integrated Circuits (AREA)
- Insulated Gate Type Field-Effect Transistor (AREA)
- Electrodes Of Semiconductors (AREA)
- Internal Circuitry In Semiconductor Integrated Circuit Devices (AREA)
- Semiconductor Memories (AREA)
- Non-Volatile Memory (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
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
- 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.
- 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.
- 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 ofFIG. 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. - 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 containingfield devices 110A through 110Z,control network 130,control system 140,central server 150,database server 170, andclient systems 180A through 180Y. Each block is described below in detail. -
Control network 130 connects each ofcentral server 150 andcontrol system 140 withfield 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 offield 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 ofcontrol 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 fromcentral 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 fromvarious field devices 110A through 110Z throughcontrol network 130, and makes the information available to users viaclient 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 managefield 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 tocentral server 150 for specific tree portion of interest (typically what a user has presently selected the tree portion), and receives the corresponding information fromcentral 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 byDD 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 ofFIG. 3 . As shown there, the DD element represents a variable lower_value with attributes HELP, CLASS, LABEL, VALIDITY, HANDLING, and TYPE inlines - Continuing with the manner in which
DD deciphering application 230 ofFIG. 2 may parse a DD file for the DD element ofFIG. 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 inFIG. 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 ofFIG. 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 causesclient system 180A to examine in-memory-object 250 to determine that the selected portion represents a dynamic menu and subscribes tocentral 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 toFIGS. 1 and 4 B (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 instep 401, in which control immediately passes to step 410. Instep 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 asDD 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 instep 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 withoptimization 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 inFIG. 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 inline 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 inline 310 ofFIG. 3 ). -
Line 531 indicates (though not shown) that there are 6 attribute for this element (consistent with the content of lines 315-360 ofFIG. 3 ), and accordingly 6 DD attribute objects follow. For illustration, only the description of object corresponding to attribute HELP inline 315 is described below in further detail. - Lines 541-558 contain the object definition for the first attribute HELP (
line 315 ofFIG. 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 withnumber 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 inline 552. Inline 556 the ConditionalObject field is shown set to null, since the attribute is inapplicable due to the value set inline 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 ofFIG. 3 ) is determined when the in-memory objects are created instep 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 inintermediate 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 ofFIG. 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 FIG. 5 .Line 617 further indicate the size of the item value (text) ofline 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 inlines lines line 631 indicating the number of characters (size) ofattribute 635. The data (line 611-650) may be stored inintermediate file 490. - By examining
FIGS. 5 and 6 , it will be readily appreciated that the order of storing inFIG. 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 toFIG. 6 ). Theoptimization 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 fromintermediate 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 inline 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 inline 707. Inline 709 the IDENTIFIER of the item is set to 16000 in accordance withline 615.Optimization module 470 reads line 617 (indicating size of the value) and sets the value of the item online 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 inline 718 and sets attribute type to 10 (HELP) in line 720. The IDENTIFIER, value, IsItAConditional, ConditionalObject fields are set inlines lines - 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 ofdigital 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 tocentral server 150 orclient 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 exceptdisplay unit 870 may communicate with each other overcommunication path 850, which may contain several buses as is well known in the relevant arts. The components ofFIG. 8 are described below in further detail. -
CPU 810 may execute instructions stored inRAM 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 fromsecondary memory 830 usingcommunication path 850, and also supports the objects while the user interface is provided. -
Graphics controller 860 generates display signals (e.g., in RGB format) todisplay unit 870 based on data/instructions received fromCPU 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 providinguser interface 210. For example,network interface 880 may enablecentral 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 andremovable storage drive 837.Secondary memory 830 may store the data and software instructions (e.g., methods instantiated by each of client system), which enabledigital processing system 800 to provide several features in accordance with the present invention. Some or all of the data and instructions may be provided onremovable storage unit 840, and the data and instructions may be read and provided byremovable storage drive 837 toCPU 810. Floppy drive, magnetic tape drive, CD_ROM drive, DVD Drive, Flash memory, removable memory chip (PCMCIA Card, EPROM) are examples of suchremovable storage drive 837. -
Removable storage unit 840 may be implemented using medium and storage format compatible withremovable storage drive 837 such thatremovable 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 inhard drive 835. These computer program products are means for providing software todigital 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 (20)
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:
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 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:
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.
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.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005-067154 | 2005-03-10 | ||
JP2005067154A JP2006253376A (en) | 2005-03-10 | 2005-03-10 | Semiconductor device and its manufacturing method |
Publications (1)
Publication Number | Publication Date |
---|---|
US20060206659A1 true US20060206659A1 (en) | 2006-09-14 |
Family
ID=36971551
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/306,389 Abandoned US20060206659A1 (en) | 2005-03-10 | 2005-12-27 | Reducing Time to Load Device Description in Management of Field Devices |
US11/306,386 Expired - Fee Related US7579264B2 (en) | 2005-03-10 | 2005-12-27 | Method for manufacturing an electrode structure of a MOS semiconductor device |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/306,386 Expired - Fee Related US7579264B2 (en) | 2005-03-10 | 2005-12-27 | Method for manufacturing an electrode structure of a MOS semiconductor device |
Country Status (4)
Country | Link |
---|---|
US (2) | US20060206659A1 (en) |
JP (1) | JP2006253376A (en) |
KR (1) | KR20060097540A (en) |
CN (1) | CN100490116C (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103218310A (en) * | 2012-01-19 | 2013-07-24 | 横河电机株式会社 | Cache device, communication apparatus, and computer program product |
US9182757B2 (en) | 2011-03-30 | 2015-11-10 | Fisher-Rosemount Systems, Inc. | Methods and apparatus to transmit device description files to a host |
US20160041743A1 (en) * | 2014-08-08 | 2016-02-11 | Endress + Hauser Gmbh + Co. Kg | Automated creation of suitable preference menus for field devices |
US10168867B2 (en) * | 2015-08-28 | 2019-01-01 | At&T Intellectual Property I, L.P. | System and method for generating a unified menu for multiple communication channels |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100833446B1 (en) | 2006-12-26 | 2008-05-29 | 주식회사 하이닉스반도체 | Flash memory device and manufacturing method thereof |
JP5709455B2 (en) * | 2010-10-12 | 2015-04-30 | キヤノン株式会社 | Development device |
JP2014160757A (en) * | 2013-02-20 | 2014-09-04 | Toshiba Corp | Nonvolatile semiconductor storage device and manufacturing method of the same |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5903455A (en) * | 1996-02-06 | 1999-05-11 | Fisher-Rosemount Systems, Inc. | Interface controls for use in a field device management system |
US20030004952A1 (en) * | 1999-10-18 | 2003-01-02 | Mark Nixon | Accessing and updating a configuration database from distributed physical locations within a process control system |
US20030109937A1 (en) * | 2001-12-06 | 2003-06-12 | Martin Zielinski | Intrinsically safe field maintenance tool |
US7117433B1 (en) * | 1998-09-29 | 2006-10-03 | International Business Machines Corporation | HTML mapping substitution graphical user interface for display of elements mapped to HTML files |
Family Cites Families (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS5032021B1 (en) * | 1970-08-11 | 1975-10-16 | ||
JPS5354489A (en) * | 1976-10-28 | 1978-05-17 | Seiko Epson Corp | Production of semiconductor device |
JPS58165368A (en) * | 1982-03-26 | 1983-09-30 | Hitachi Ltd | Manufacture of semiconductor device |
JP2554361B2 (en) * | 1988-07-13 | 1996-11-13 | 沖電気工業株式会社 | Method for manufacturing semiconductor device |
JPH03114267A (en) * | 1989-09-28 | 1991-05-15 | Hitachi Ltd | Semiconductor device and manufacture thereof |
JP2504306B2 (en) | 1990-07-16 | 1996-06-05 | 三菱電機株式会社 | Method for manufacturing semiconductor device |
JP3127455B2 (en) * | 1990-08-31 | 2001-01-22 | ソニー株式会社 | Semiconductor device manufacturing method |
JPH05267604A (en) * | 1991-05-08 | 1993-10-15 | Seiko Instr Inc | Manufacture of semiconductor device |
US5472887A (en) * | 1993-11-09 | 1995-12-05 | Texas Instruments Incorporated | Method of fabricating semiconductor device having high-and low-voltage MOS transistors |
JP3601612B2 (en) * | 1994-09-22 | 2004-12-15 | 富士通株式会社 | Semiconductor device and manufacturing method thereof |
JPH08139208A (en) * | 1994-11-04 | 1996-05-31 | Toyota Motor Corp | Manufacturing system of non-volatile memory and method of manufacturing the same |
JPH09205159A (en) * | 1996-01-26 | 1997-08-05 | Ricoh Co Ltd | Semiconductor device and its manufacture |
US6165880A (en) * | 1998-06-15 | 2000-12-26 | Taiwan Semiconductor Manufacturing Company | Double spacer technology for making self-aligned contacts (SAC) on semiconductor integrated circuits |
EP1039533A3 (en) * | 1999-03-22 | 2001-04-04 | Infineon Technologies North America Corp. | High performance dram and method of manufacture |
US6511883B1 (en) * | 1999-07-07 | 2003-01-28 | United Microelectronics Corp. | Method of fabricating MOS sensor |
DE10138648A1 (en) * | 2001-08-07 | 2003-03-06 | Infineon Technologies Ag | Method for producing a MOS transistor and a bipolar transistor in parallel |
JP3626734B2 (en) * | 2002-03-11 | 2005-03-09 | 日本電気株式会社 | Thin film semiconductor device |
KR100616498B1 (en) * | 2003-07-26 | 2006-08-25 | 주식회사 하이닉스반도체 | Fabricating method of semiconductor device with poly/tungsten gate electrode |
KR100488546B1 (en) * | 2003-08-29 | 2005-05-11 | 삼성전자주식회사 | Method for manufacturing transistor |
JP2006032542A (en) * | 2004-07-14 | 2006-02-02 | Seiko Instruments Inc | Method of manufacturing semiconductor device |
US6946335B1 (en) * | 2004-11-24 | 2005-09-20 | Bcd Semiconductor Manufacturing Limited | Method of manufacturing improved double-diffused metal-oxide-semiconductor device with self-aligned channel |
-
2005
- 2005-03-10 JP JP2005067154A patent/JP2006253376A/en active Pending
- 2005-10-11 KR KR1020050095767A patent/KR20060097540A/en not_active Application Discontinuation
- 2005-10-31 CN CNB2005101187887A patent/CN100490116C/en not_active Expired - Fee Related
- 2005-12-27 US US11/306,389 patent/US20060206659A1/en not_active Abandoned
- 2005-12-27 US US11/306,386 patent/US7579264B2/en not_active Expired - Fee Related
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5903455A (en) * | 1996-02-06 | 1999-05-11 | Fisher-Rosemount Systems, Inc. | Interface controls for use in a field device management system |
US7117433B1 (en) * | 1998-09-29 | 2006-10-03 | International Business Machines Corporation | HTML mapping substitution graphical user interface for display of elements mapped to HTML files |
US20030004952A1 (en) * | 1999-10-18 | 2003-01-02 | Mark Nixon | Accessing and updating a configuration database from distributed physical locations within a process control system |
US20030109937A1 (en) * | 2001-12-06 | 2003-06-12 | Martin Zielinski | Intrinsically safe field maintenance tool |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9182757B2 (en) | 2011-03-30 | 2015-11-10 | Fisher-Rosemount Systems, Inc. | Methods and apparatus to transmit device description files to a host |
CN103218310A (en) * | 2012-01-19 | 2013-07-24 | 横河电机株式会社 | Cache device, communication apparatus, and computer program product |
US20130191597A1 (en) * | 2012-01-19 | 2013-07-25 | Yokogawa Electric Corporation | Cache device, communication apparatus, and computer program product |
US9229871B2 (en) * | 2012-01-19 | 2016-01-05 | Yokogawa Electric Corporation | Cache device, communication apparatus, and computer program product |
US20160041743A1 (en) * | 2014-08-08 | 2016-02-11 | Endress + Hauser Gmbh + Co. Kg | Automated creation of suitable preference menus for field devices |
US10379722B2 (en) * | 2014-08-08 | 2019-08-13 | Endress+Hauser Se+Co.Kg | Automated creation of suitable preference menus for field devices |
US10168867B2 (en) * | 2015-08-28 | 2019-01-01 | At&T Intellectual Property I, L.P. | System and method for generating a unified menu for multiple communication channels |
Also Published As
Publication number | Publication date |
---|---|
CN100490116C (en) | 2009-05-20 |
US20060205153A1 (en) | 2006-09-14 |
KR20060097540A (en) | 2006-09-14 |
US7579264B2 (en) | 2009-08-25 |
JP2006253376A (en) | 2006-09-21 |
CN1832127A (en) | 2006-09-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7317952B2 (en) | Managing field devices having different device description specifications in a process control system | |
US11544257B2 (en) | Interactive table-based query construction using contextual forms | |
US11983166B1 (en) | Summarized view of search results with a panel in each column | |
US11983167B1 (en) | Loading queries across interfaces | |
US8019747B2 (en) | Facilitating flexible windows in data stream management systems | |
US7600200B2 (en) | Display of historical information related to field devices used in process control plants | |
US8103655B2 (en) | Specifying a family of logics defining windows in data stream management systems | |
US5854930A (en) | System, method, and computer program product for script processing | |
US10198425B2 (en) | Methods and apparatus for reusing report design components and templates | |
CN107102848B (en) | Specifying user interface elements | |
US7827494B1 (en) | Layout management using data-descriptive meta language documents | |
US20060206659A1 (en) | Reducing Time to Load Device Description in Management of Field Devices | |
EP2260413A1 (en) | Web content management | |
US7814123B2 (en) | Management of component members using tag attributes | |
US20050086201A1 (en) | Converting user interface panels | |
CN115082247B (en) | System production method, device, equipment, medium and product based on label library | |
US20120079508A1 (en) | Module Interrogation | |
EP1909170B1 (en) | Method and system for automatically generating a communication interface | |
JP2012190063A (en) | Data generation device and data generation program | |
US9037542B2 (en) | Reducing programming complexity in client applications when interfacing with database servers operating with different programming interfaces | |
US20150089404A1 (en) | Metadata-driven list user interface component builder | |
US20150347573A1 (en) | Information Processing Device and Method Therefor, and Non-Transitory Computer Readable Medium | |
WO2015156336A1 (en) | Term unification system, term unification program, and term unification method | |
JP5062499B2 (en) | Field device management device | |
US20240126573A1 (en) | Display control device, display control method, and display control program |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: HONEYWELL INTERNATIONAL, INC., NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ANNE, GOWTHAM;TANDON, VIBHOR;DEEPAK, BHANDIWAD S;AND OTHERS;REEL/FRAME:017100/0391 Effective date: 20051226 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |