Method for displaying parameters of an electronic device, a computing device, and a system communicatively coupled to a field device - Patents.com

Abstract

To provide a method of and system for implementing a search function to bypass a sequential hierarchical menu selection path to access a device parameter, where hierarchical menus are generated based on an electronic device description (EDD) and interpreted using an EDD engine.SOLUTION: A search function provides a first parameter result set without rendering display characteristics to provide a user with a simple initial display of possible matches. A user selection of a desired device parameter is received and a device parameter view may be retrieved containing the desired device parameter and rendered on a user interface.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to process control systems and, more specifically, to methods and systems for accessing and displaying plant device parameters and capabilities using electronic device descriptions and electronic device description interpreters. [Background technology]

[0002] A process control system used in an industrial process may include at least one host or operator workstation communicatively coupled to one or more process controllers via one or more input / output (I / O) interface devices. The process controller may communicate with one or more field devices via analog, digital, or a combination of analog / digital buses. The field devices, which may be, for example, valves, valve positioners, switches, and transmitters / sensors (e.g., temperature, pressure, and flow sensors), perform functions within the process plant such as opening and closing valves and measuring process parameters. The process controller receives signals indicative of process measurements generated by the field devices and / or other information about the field devices, uses this information to implement control routines, and then generates control signals that are sent over a bus to the field devices to control the operation of the process. As described herein, the field devices, controllers, and other plant devices, such as input / output interfaces, are generally referred to as "process control devices" or "control devices."

[0003] Information from the process control device can be made available to one or more applications (i.e., routines, programs, etc.) executed by an operator workstation (e.g., a processor-based system) to enable an operator to perform desired functions related to the process, such as viewing the current state of the process (e.g., via a graphical user interface), evaluating the process, modifying the operation of the process (e.g., via a visual object diagram), etc. In some systems, the workstation application can be an Electronic Device Description (EDD) engine or EDD interpreter used to communicate with electronic devices, such as process control devices, based on the Electronic Device Description (EDD) file of the process control device. In this system, device parameters and functions can be accessed through a series of device parameter screens or views. The device parameter screens or views can be constructed as specified in the EDD file of the process control device and displayed as a user interface on the workstation or other computing device communicatively coupled to the workstation.

[0004] Generally, electronic device description (EDD) files, or sometimes described herein as EDDs, can be used within a process control system to provide a structured and / or standardized format for describing and specifying parameters and functions of process control devices. The Electronic Device Description Language (EDDL) is commonly used to create or write EDD files. An EDD engine or interpreter running, for example, on a workstation, controller, or other computing device, is software used to interpret or translate EDD files and facilitate access, control, and / or management of process control devices. Human machine interface or user interface software can be used to display graphical representations (e.g., views or device screens) of device parameter information from the process control device based on what is specified by the EDD file, interpreted by the EDD engine, and communicated to a user interface (sometimes referred to as a human machine interface or HMI) from the EDD engine. In this system, the EDD file can specify visualization of the process control information based on parameters associated with the device and based on communication between the EDD engine and the device.

[0005] A device parameter screen or view generated by an EDD engine may contain a set of parameters, as specified in the EDD, including links to other views with different sets of parameters. The device parameter screens may be organized in a hierarchical manner (e.g., hierarchical menus or menu trees), such that accessing a desired device parameter may include clicking through a series of device parameter screens to access the device parameter screen containing the desired parameter. This method of accessing process control device parameters may be cumbersome. In particular, an EDD may specify a large number of device screens, often requiring a user to navigate through multiple screens to reach a desired parameter. The number of screens or views for a device may be proportional to the number of parameters and the complexity of the particular device. Of course, a user may find a target parameter by chance on an initial first or second device screen, but typically multiple views or screens are traversed before reaching the desired screen or view containing the desired device parameter.

[0006] In some situations, an experienced user may know the path (i.e., sequence of screens) to access a particular parameter, making access more efficient. For example, to navigate to a particular device parameter screen, a user may know that the device can be located by selecting the third option in a first view, the fifth option in a second view, and the second option in a third view. In this case, knowing how to click through to the desired parameter may save time. However, for new or inexperienced users, finding the path to the target view generally requires reading each option on each device screen, thinking about which option is correct, and making the correct selection to navigate to the desired parameter. Even with careful consideration of the displayed view items or elements, the wrong option may be selected, thus resulting in additional time spent navigating to the correct device screen containing the desired device parameter. Summary of the Invention [Problem to be solved by the invention]

[0007] The claimed method and system includes querying a set of device parameters associated with an electronic device, applying a first search algorithm based on a first user input to an index of parameter identifiers to generate a first parameter result set, and displaying the first parameter result set without rendering a display characteristic of the first parameter result set. The claimed method and system includes receiving a user selection of a device parameter, searching a second parameter result set based on the user selection, and displaying the second parameter result set including rendering a display characteristic of the second parameter result set. [Means for solving the problem]

[0008] The second parameter result set may include a view of the device parameter screen as part of a manufacturer-provided menu screen as specified in the EDD file. In an embodiment, the second parameter result set may include identifiers, display attributes, and current values ​​of the user-selected device parameters. In an embodiment, the system may refrain from displaying the manufacturer-provided device parameter screen in favor of a simplified target device parameter screen. The simplified target device parameter screen may use different display attributes than those specified in the manufacturer-provided menu screen for the same target device parameter.

[0009] In embodiments, the methods and systems can be implemented using an Electronic Device Description Language specification in an EDD file. In embodiments, the methods and systems can be implemented in a user interface description portion of an EDD file. In embodiments, the methods and systems can be implemented in a user interface plug-in component of a system under the Field Device Integration Standard. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 illustrates a system for accessing an electronic device using an Electronic Device Description (EDD). [Diagram 2] Figure 2 shows the implementation of an EDD system in a process control plant using industry-standard field device integration (FDI). [Diagram 3] Figure 3 shows the device screen specified in the EDD file for a temperature sensor. [Figure 4] FIG. 4 shows a series of screens that can be navigated to arrive at the desired device parameters. [Diagram 5] FIG. 5 illustrates a user interface for navigating to a desired process control device parameter in a multiple device screen system using a search function. [Figure 6A] FIG. 6A shows a user interface screen for an exemplary search. [Figure 6B] FIG. 6B shows a possible search results and options screen. [Figure 7] FIG. 7 shows a device parameter screen searched based on the search function. [Figure 8] FIG. 8 shows the user interface of the auto-suggest search function. [Figure 9] FIG. 9 illustrates a user interface for filtering search results by parameter type or category. [Figure 10]FIG. 10 shows the user interface of the quick view search function. [Figure 11] FIG. 11 shows a block diagram of a method or process for finding desired device parameters. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] FIG. 1 illustrates a portion of a process control system 10 including a workstation 12 executing an electronic device description (EDD) host application 14. The host application 14 may include an EDD engine 16 or interpreter. As used herein, electronic device description and device description have similar or identical meanings and are generally created using the Electronic Device Description Language (EDDL). The host application 14 may be adapted to receive and manage EDD files 18 of one or more process control devices 20, 21, and 22 in the process control system 10. A user interface or human machine interface (HMI) 24 may communicate with the EDD engine or interpreter 16 to access process control devices such as input / output interfaces 20, process controllers 21, or field devices 22. The user interface 24 may communicate with the EDD engine 16 to receive visualization information that is rendered on a display 26 of the user interface 24 and may include a view of parameters and functions of the process control devices 20, 21, or 22. The displayed view may include a graphical representation of the parameters and their current values. The way the display is organized and the types of views available may be specified by an EDD 18 and provided to an HMI or user interface 24 by an EDD engine 16 of a host application 14. In some embodiments, a host application 14 may include both an HMI / user interface 24 and an EDD engine 16. (See FIG. 1 ). In other embodiments, a host application running on a first computing device may include an EDD engine, while a second host application on a second, different computing device may include an HMI, and the first computing device may function as a client and the second computing device may function as a server.In this model, multiple clients can access the same server to communicate with the process control devices using an EDD engine. The EDD engine can access and catalog the device descriptions and provide a common set of interfaces for accessing the process control devices modeled or specified by the EDD for the process control devices.

[0012] 1 may generate displays showing process control information from field devices 22 based on EDD files 18 managed by EDD engine 16. In this manner, a user of a workstation 12 implementing the HMI 24 may view process control information associated with field devices 22. To display the process control information, for example, the user interface 24 may receive requests from a user of the workstation 12 using an input device 25 (e.g., keyboard, mouse, etc.) to display information associated with the field devices 22 within the process control system 10.

[0013] The example user interface 24 can then communicate the request to the EDD engine or interpreter 16, which then accesses the corresponding EDD file 18 associated with the requested field device 22. In some embodiments, the EDD file may correspond to a process control device, such as one in a distributed process control system, such as a field device or a process controller, although it should be noted that an Electronic Device Description (EDD) can be used to describe any electronic device, and the methods and systems described herein can also be utilized for any electronic device that can be described using an EDDL, even devices that are not part of a process control system.

[0014] FIG. 1 shows that an EDD generally includes device data or device definitions 31, business logic (BL) 32, and user interface descriptions (UIDs) 33. An EDD engine or interpreter 16 can read an EDD file 18 for instructions on how the process control or device information is to be displayed. In some cases, an EDD file 18 can include instructions for displaying one or more views. Generally, as used herein, a view includes a set of parameters and display characteristics associated with the set of parameters, where the display characteristics are instructions on how to display the set of parameters. In some systems, each device parameter can have its own set of display characteristics, and a view can include one or more device parameters with their corresponding display characteristics. In some systems, each device parameter can have a set of display characteristics determined by the view that includes the device parameter. In some embodiments, the parameter information required for a device parameter screen can be obtained from a database view. In some cases, an EDD file 18 can include instructions for displaying a menu or view as part of a host application. An EDD file 18 can provide a description of the functionality of each item in a menu. An EDD file 18 can also include instructions that define how graphics are to be displayed within a view. For example, an EDD file may include instructions that define the dimensions, layout, format, and / or placement of parameter text. In another example, an EDD file 18 may include instructions that define the dimensions, layout, format, placement, data fields, and / or placement of an image or other graphical display object. In general, display characteristics may include commonly known graphical user interface (GUI) elements such as panels, menus, text boxes, and elements for displaying parameter values, such as graphs, tables, charts, and the like.

[0015] In another example, the EDD file 18 may include links and / or references to images that are displayed within the application 14. To display the images within a view, the example user interface 24 of FIG. 1 may use instructions in the EDD file 18 to structure, format, and / or arrange the images. In some examples, the EDD file 18 may include references and / or links to a database of images (not shown) that the display interface 24 accesses to find the referenced graphics. In this manner, the display interface 24 may display pre-made graphics (e.g., clip art, photographs, animations, etc.) that are referenced within the EDD file.

[0016] The example user interface 24 can also render the referenced graphics with corresponding live process control information for display within the application 14. In this example, the EDD engine 16 can communicate or query the field devices 22 for corresponding device parameter values ​​when the HMI is requesting a view that requires those parameters and parameter values ​​to be displayed. The example user interface 24 of FIG. 1 can combine graphics with process control information by processing control information stored within devices, such as the field devices 22, using references and / or links within the EDD file 18. For example, an EDD file describing a table graphic can include a reference for each table cell to a parameter (e.g., a parameter value). The reference can include a directory location in memory, a location within a hierarchical data scheme, an internet address of a server (e.g., an OPC UA associated server) that hosts the process control information, and / or a location within the field device 109 specified with a parameter that corresponds to the device information. The user interface 102 can insert and / or combine the process control information or parameter values ​​with the graphics or graphic objects using the links and / or references. For example, the user interface may initiate a query via the EDD engine 16 to retrieve current device parameter values ​​from the live field devices 22 for display. The display interface 24 may then render graphics with the process control information using instructions provided by the EDD engine 16 to graphically display the process control information or device information.

[0017] In some exemplary systems, the EDD engine 16 and / or associated elements of the EDD engine 16 can generate an Extensible Markup Language (XML) representation of a user interface as described by the EDD 18. In this exemplary system, the EDD engine 16 can read the EDD file 18 and interpret the EDD into a series of XML files that, when rendered on a display 26, provide a visual representation of a user interface for accessing a device corresponding to the EDD. For example, after reading an EDD file 18 corresponding to a field device, such as a temperature sensor, the EDD engine 16 can generate a main menu screen or view in the form of an XML page or document. This page can be retrieved and accessed by the HMI 24, which displays the XML on an attached monitor 26, similar to a web browser. A user can then interact with the displayed XML page, for example, by clicking on various parameters to retrieve additional views or screens specified in the EDD 18 and converted into an XML page via the EDD engine 16. In this model, the EDD engine 16 can act as a server, while the HMI 24 can act as a client. In one embodiment, the EDD engine can be adapted or modified to generate the visual representation of the user interface using Java Script Object Notation (JSON), in addition to or instead of using XML.

[0018] FIG. 2 illustrates a specific implementation of an EDD-based system for accessing process control devices within a process control system. The system of FIG. 2 can be used to describe an industry-standard EDD-based system called a Field Device Integration (FDI) system or model. The FDI system was developed in collaboration with major process automation suppliers and standards bodies. The FDI system can be designed to communicate with devices throughout a process plant over a variety of protocols to manage device information. In this system, a host can include an FDI server and an FDI client.

[0019] In an FDI system 70 as shown in FIG. 2, a device such as a field device 22 may have an EDD 18 similar (and similarly labeled) to that described in FIG. 1. The EDD 18 of a device may include at least a device definition 31, business logic 32, and a user interface description (UID) 33. In an FDI system, the EDD 18 of a device may be encapsulated in a standardized FDI device package 90. The FDI device package 90 may include the EDD 18, a user interface plug-in (UIP) 82, and an attachment 83 specific to the electronic device. In this system, each device 22 of the FDI system 70 is represented by an FDI device package 90. In general, the device 22 may be any device in a process plant that is described using the FDI package 90. The UIP 82 of the FDI device package 90 may enable host machine specific graphical and processing functionality beyond the functionality that can generally be described using only the UID 33 of the EDD 18. For example, the UIP 82 may enable host machine specific graphical and processing capabilities in addition to those specified in the UID 33 of the EDD 18 and that can be interpreted by the EDD engine. Attachments 83 of an FDI device package 90 may include device related graphics and images, registration certificates, data sheets, user manuals, and communication protocol specification files such as GSD (General Station Description), CFF (Common File Format), etc.

[0020] The EDD file 18 can include a user interface description (UID) 33 that uses current industry standard EDDL functions to specify the visual representation of a parameter set. The UID 33 can include basic visual elements such as windows, tabs, input fields, buttons, and some more complex elements such as trends, gauges, and bar graphs. More complex graphics outside the scope available as encoded via EDDL may be required. In these situations, an EDD-based device access system can enhance the graphics capabilities of the user interface description 33 defined in the EDDL using additional components or add-ons. In systems implementing the FDI system 70, extended device functionality or parameter presentation can be implemented using a user interface plug-in (UIP) 82 that can be host system specific and can take advantage of more powerful graphical rendering elements than specified by the UID 33. As the EDDL specification becomes more robust, additional functionality can be supported by the UID 33.

[0021] The FDI server 92 can be adapted to import and manage the FDI device packages 90, read and interpret the contents of the FDI device packages 90, and, when initiated, create a set of graphical instructions that enable an FDI client 94 communicatively coupled to the FDI server 92 to access process control device functions and read device parameter values. The FDI server 92 can include an FDI EDD engine 100 for reading the EDD 18 included in the FDI device packages 90, and the FDI server 92 can create a graphical user interface 102, such as a view, available to the FDI client 94. The FDI client 94 can communicate with the FDI server 92 to retrieve the graphical instructions, for example, in the form of an XML-based representation, and render those graphics to a user on a display device. In this respect, the FDI client 94 functions as an HMI similar to that shown in FIG. 1. The FDI client 94 can also import and execute a user interface plug-in (UIP) 82 of the FDI device package 90 for a particular device 22. As explained, certain functions and graphical interfaces may be implemented by UIP 82 that are outside of or provide extensions to those specified by UID 33.

[0022] In general, the FDI server 92 can be a workstation, a process controller, a field device, or any other computing device communicatively coupled to an electronic device described by the EDD 18 or FDI device package 90. In some cases, the FDI server 92 can have a direct communication link with the electronic device 22, as shown by the communication link 124 in FIG. 2. In other examples, the FDI server 92 can communicate with the electronic device 22, such as a process control device, via a communication interface or an input / output (I / O) device. For an FDI system 70 as shown in FIG. 2, the FDI server 92 can be adapted to communicate with various process control devices on different communication protocols or legacy systems that are generally not compatible with current industry standards using a universal communication platform with appropriate communication interfaces. The FDI communication platform can include an FDI communication server 110 coupled to the FDI server 92. The FDI communication server 92 can be used for integration of non-native field protocols and can support integration of communications with devices in heterogeneous hierarchical networks using heterogeneous communication hardware.

[0023] In general, an EDD for a device may specify parameters and methods or functions of a process control device or other electronic device. Importantly, the EDD may also include an organization of the parameters and functions of the electronic device. Because a field device may have too many parameters to all be displayed on one viewable screen, the EDD may specify that the parameters be organized by data screen or view. In some cases, the viewable screen may be determined by the physical type and size of the physical display of the workstation hosting the user interface or HMI 24. For example, a particular physical window size and corresponding minimum readable font size of the display monitor may be specified (e.g., by the EDD or the host application) that limits the number of items or parameters that can fit in a window, view, or screen. It is noted that window, view, or screen are used interchangeably herein. The manner in which parameters are organized by view may depend on many factors, including the type of process control device specified in the EDD file. One factor influencing the organization of the views may be the nature of the categories of data sets being used by the device, while another factor may be a programmer or operator bias where certain data sets are grouped by operator familiarity. In one example, the parameters can be grouped in a manner that corresponds to the way the parameters are recorded in a database used by the device. For example, the organization of the parameters can correspond to grouping based on type or function fields.

[0024] Accessing a process control device parameter typically requires traversing a hierarchical set of device view screens containing various parameter sets until the particular view screen containing the desired parameter is reached. This method of access via sequential view screens may also be a product of legacy systems in the industrial control industry, where older field devices are designed to be accessed, controlled, and managed using sequential menus.

[0025] FIG. 3 illustrates a device screen 201 specified by an EDD file for a process control field device. In this case, the field device is a temperature sensor, and more specifically, a Rosemount 644 temperature sensor manufactured by Fisher Rosemount Systems, Inc. The EDD file may typically specify a screen layout 201 as shown in FIG. 3. The layout 201 may include a menu of options 202 for accessing parameters and functions of the process control device. In particular, FIG. 3 illustrates a process variable root menu 210, a device root menu 212, and a diagnostics root menu 214. Generally, by clicking or selecting any of the options on the main screen 201, additional screens 216 with additional options 218 or parameters may be generated and displayed. If a user wishes to access parameters of the process control device or perform a function such as a diagnostic function on the process control device, the user may access this initial main menu 201 when browsing the EDD or XML equivalent rendering of the EDD reference / parameters via an EDD engine or interpreter. To access or search for a particular desired parameter or function, a user may need to click, select, and / or expand menus and containers (e.g., view screens such as submenus, subwindows, dialogs, pages, etc.) until the desired parameter is reached. As noted above, the organization of field device parameters and data can be the product of several different factors, but will generally vary from device to device, even among those of the same category, e.g., sensors.

[0026] FIG. 3 illustrates the Manual Setup option 220 under the Screen Layout menu 201, which is the primary path or selection a user can select to find the device tag parameter. The actual location of the desired device tag parameter can be Manual Setup 220 (second menu), Device (seventh option in the second menu), Identification (first option / group of the third menu options). FIG. 4 illustrates a set of screens 201, 202, and 203 that can be navigated by the user to reach the desired device parameter: Device Tag Parameter 230. FIGS. 3 and 4 are a short example of the process an inexperienced user may need to go through to access a particular device parameter of a process control device using an EDD file. Finding or accessing the desired parameter may involve a laborious process of reading through numerous options and sifting through many other variables until the user can reach the category or group (e.g., view) that contains the user's desired parameter.

[0027] FIG. 5 illustrates an embodiment of a method and system for navigating to a desired process control device parameter using a search function or feature. A search window, search dialog text box, or any other search display function 280 can be displayed on a user interface of a client device that inputs or prompts a user to input a search string or string specifier. As shown in FIG. 5, the search window can be integrated with a main menu console, such as element 280, or can be a floating window, such as element 282. After inputting the search string, the user can activate a first search function or a first search algorithm, for example, by pressing or selecting an enter or search button. The search string can then be used as an input to a search function interface, such as that shown in FIG. 5.

[0028] FIG. 6A shows that a user can enter a search string in a search text box 310. FIG. 6A shows entering the search string "sensor" 312 and then selecting a search button 314. The search function can have an intermediate screen 316 that indicates that a search is in progress. In one embodiment, a first or preliminary result set of parameters 318 can be output from the search function. This first parameter result set 318 can be a set of device parameters having identifiers 320 that match or partially match the search string entered by the user. From this preliminary result set, the user can select a desired parameter if present and readily visible within the first result set. For example, in the display screen of FIG. 6B (similar to FIG. 6A), if the user's search string is "sensor" 312 and the user's desired device parameter is a sensor type 330, the user can simply select the desired device parameter 330 to grind or open a corresponding screen, menu, or layout object that contains the desired device parameter. In one embodiment, retrieving a screen, menu, or view object may include activating a link, such as an index, shortcut, or address, that opens (e.g., renders) the actual device parameter menu, screen, view, or display layout that includes the desired device parameter. The menu screen, view, or display layout may be specified by the device's EDD file. In an embodiment, retrieving a screen or view may include querying for views that include parameters that have an identifier associated with or matching the device parameter selected from the first result set. For example, the temperature parameter of sensor 1 may have an identifier that links it to a particular view or device screen. The device parameter views may be queried or searched based on the parameter identifier. At the same time, the device parameter views may also have an identifier, and the query for views may include querying for view identifiers based on the parameter identifier.Figure 7 shows a view 360 resulting from a user selecting or clicking a desired parameter sensor type 330 in Figure 6B. In an embodiment, the resulting view can be adapted to highlight the selected device parameter, such as using an oval 361.

[0029] Especially for more complex field devices or controllers, the preliminary result set may return a large number of results, so that the desired parameter may not be easily found in the first search. For example, the user may activate a scroll function to scroll down the parameters of the first result set, so that the parameter may not be displayed on the first or second screen. In one embodiment, the user may be provided with additional search functions. In one embodiment, the user may continue to refine the search string. For example, the user may type "sensor 1" or "sensor temperature," thereby initiating a second search function or query to provide a second set of parameter results. In this configuration, a search or query may be initiated each time a new character is typed or entered into the search box. The activation or implementation of this feature may depend on the processing power to perform multiple searches and the latency in returning results from a query. In situations where the required processing power or latency is too high, an embodiment of the system may automatically disable the search function in response to this input and instead default to search upon input or activation of the search button (i.e., the user must click to activate a new search).

[0030] In some embodiments, the additional function can be programmed to auto-suggest results as shown in FIG. 8. In this function, the user search string can be recorded in a cache (e.g., memory). The display search function can include recursively searching the cache as the user is typing each character to match the user-entered search string. FIG. 8 shows an initial search interface 500 with no text entered. In this embodiment, when a user search string 501 is entered into a search box 510, the search function can provide matches 511 to previously entered cached search strings that are displayed to the user as term suggestions. The user can then click on the suggestion 511, which can then be used in the first search function.

[0031] In one embodiment, additional fields such as device parameter categories may be displayed to the user as part of the first parameter result set. In this situation, the user may have the option to initiate a second search function or query, with the second parameter result set displaying matching parameters by device parameter category. The second search function may be a filter that matches or groups parameters in the first result set by additional field identifiers such as a category field. As shown in FIG. 9, a Rosemount temperature sensor may have device parameter categories such as actions 561, parameters 562, groups 563, pages 564, charts 565, etc. In the embodiment shown in FIG. 9, selecting or clicking a parameter category 561-565 may initiate an additional search or filter 570, and only parameters belonging to that category may appear or be displayed in the search results box 580. In other embodiments, clicking a parameter category may reorganize the results so that the parameters are listed by category while still displaying all parameters. Similar to how a user finds a desired parameter in the first parameter result set, when a user selects one of the parameters from the second parameter result set, a corresponding view, screen, menu, and / or layout object containing the desired device parameter can be retrieved and displayed.

[0032] FIG. 10 illustrates an embodiment of a quick view or partial view function. In FIG. 10, a partial view 900 of a device parameter screen, or what is described herein as a quick view, can be displayed when a selected device parameter 901 of a first parameter result set 905 or a second parameter result set is displayed in list format. In some embodiments, hovering a display pointer (not shown) over a parameter in the parameter list result 905 can activate a quick view 900 of that single parameter 901. In other embodiments, the process can refrain from displaying the complete device parameter screen upon user selection of a device parameter and instead display a quick view 900 of the user selected device parameter 901. In this embodiment, a query can be made to find a limited set of display characteristics of a view that includes the selected parameter. For example, the display characteristics of the selected parameter can be queried or searched for and displayed instead of the display characteristics of the entire window, view, or screen. FIG. 10 illustrates a quick view 900 of a parameter of a sensor device. In this illustration, only the parameter identifier 907 and parameter value 908 of the selected sensor parameter are displayed. The display 900 of FIG. 10 may be the complete or only a portion of the complete view 360 that includes the same parameters (element 907 and element 360) as shown in FIG.

[0033] In an embodiment, display attributes may be used to display a quick view of parameters as shown in FIG. 10. The way in which a single parameter is displayed in FIG. 10 may depend on display attributes such as text placement, use of drop-down text boxes, etc. For example, the position of the parameter identifier 907 on the parameter value 908 and the use of drop-down text boxes 910 may be information contained in the set of display attributes of the parameter 907. In an embodiment, the display attributes of a selected device parameter may belong to a menu view that includes the selected device parameter. For example, the placement of the parameter label 907 and the use of drop-down boxes 910 may be the same as those of FIG. 7. In different embodiments, the display characteristics of a device parameter selected from a search result as described above may use a different set of display attributes.

[0034] Although the quick view 900 of FIG. 10 displays a single selected device parameter, if the selected device parameter has correlated parameters designated to be read or modified together, the set of correlated parameters may be displayed along with the selected device parameter in the quick view. In some embodiments, these correlated variables or parameters may be described as having a write-as-one relationship. However, it should be noted that the display of multiple write-as-one parameters may still represent only a portion of an entire screen or view of device parameters. Thus, displaying a quick view may require less rendering and latency than displaying an entire screen or view of device parameters.

[0035] FIG. 11 illustrates a block diagram of a method or process for locating desired device parameters specified by an EDD using a user interface search function. The method can be implemented in a system such as the system illustrated in FIG. 1 or the system illustrated in FIG. 2. In block 1101, a computing device can query a set of device parameters associated with an electronic device having an electronic device description (EDD). In some embodiments, the set of device parameters can include an index of a parameter identifier. The identifier can be a text character that uniquely identifies or names the parameter. In another embodiment, a getAllParameters() function can be created by modifying an existing set of EDD functions and / or by inserting a new set of functions into the EDD file. The getAllParameters() function can query an index of parameters stored in the EDD file of the electronic device. In another embodiment, the getAllParameters() function can query the electronic device for an index of all of its device parameters. In yet another embodiment, the getAllParameters() function can query a storage medium associated with the electronic device (such as a device database) for a set of device parameters. In general, the getAllParameters() function can provide a set of all primary text identifiers for each device parameter or function associated with a target device, as specified in the target device's EDD file or based on a query from a storage medium of the electronic device. In some embodiments, the storage medium can be a memory of the electronic device.

[0036] At block 1102, the method and system can apply a first search algorithm to the results of the getAllParameters() function based on a search string entered by the user. The first search algorithm can be adapted to find a character match between the user search string and an index of device parameters from the getAllParameters() function. The first search algorithm can output a first parameter result set including each parameter of the target device that has a text identifier that matches or partially matches the user search string. At block 1103, the method and system can display a simple list of the first parameter result set, and can display only simple text to indicate the first parameter result set.

[0037] In some implementations, calling the getAllParameters() function can provide attributes and parameters in addition to the device parameter identifier, such as a layout object or a set of display characteristics. As an example, calling the getAllParameters() function results in additional parameters and functions related to the device parameter view that are referenced or indexed to the device parameter. In another example, a device parameter such as a "sensor type" can intimately include graphical elements such as the location of the parameter on the GUI, the color, texture of how the parameter should be displayed, or whether it is displayed in a graphical object such as a graph, chart, table, image, etc. This can be the case in an embodiment where the getAllParameters() function is derived by modifying a set of existing EDD functions that are already programmed to return additional display parameters and functions. In some cases, the additional display data can be the result of how the electronic device communicates with the EDD engine to obtain parameter data. For example, the device can be programmed to always provide parameter or device capability data to the display characteristics data.

[0038] In block 1103, the claimed methods and systems can display a list of the first parameter result set without rendering any display characteristics resulting from or associated with the first parameter result set. In some embodiments, the first parameter result set can be displayed without rendering additional display components retrieved from the EDD file or retrieved from a query of device parameters. For example, the first parameter result set can include display attributes as part of the set of device parameters queried by the getAllParameters() function in block 1101. Block 1103 can refrain from rendering these display attributes in the first parameter result set. In general, the process of rendering can include processing one or more display characteristics of the elements, such as the color and texture of the manner in which the device parameters are displayed, to generate a visual representation of the elements. In these embodiments, the methods and systems can render a simple text list of the first parameter result set by using default system display characteristics used by the host system or default display attributes of the markup language used by the EDD engine (e.g., XML or JSON) to provide a visual representation of the EDD parameters and functions to the HMI.

[0039] Generally, rendering additional graphical or display characteristics of the first parameter result set may be problematic because rendering the additional display data requires additional processing power and may increase latency in providing search results to a user's display device. For example, an EDD file may contain highly complex graphical specifications of certain parameters. By refraining from rendering the additional display characteristics, the time required to retrieve the result set and provide a readable display of the first parameter result set may be significantly reduced.

[0040] In some embodiments, block 1103 can be performed by modifying the EDD engine or interpreter. In these embodiments, the method of block 1103 can display the list of the first parameter result set without rendering the display characteristics by programming the EDD engine to refrain from including the display characteristics in the results of the getAllParameters() function. In one embodiment, this can be performed by filtering out the additional display characteristics leaving only a bare set of textual parameter identifiers for display. Because some EDD interpreters may take a long time to generate results, process block 1103 can reduce the response time required to display the results of an initial device parameter query to the user. The user may need to identify the closest match in the first parameter result set for further investigation or final selection, which can be done using a simple textual list of the first parameter result set.

[0041] Furthermore, an EDD-based search or query may include communication between an EDD engine / interpreter and an electronic device (e.g., to request actual parameter values). The aforementioned rendering process to convert display characteristics may also impede communication with the device, which may increase delays. In other words, to render a particular view of a parameter, the EDD engine must communicate or query the electronic device to obtain a particular parameter or parameter value, or initiate or execute logic on the electronic device itself, which further delays the time required to send a query to the device (e.g., over a slow communication line) and the time of device processing required to respond to the communication or query.

[0042] At block 1104, the user may select a particular device parameter, and the described system may receive the user selection. In one embodiment, the user may select a single desired parameter from the first parameter result set. The user selection may be received by an input device of the user interface, such as a keyboard or mouse. In an embodiment, the user may click on the desired device parameter from the first parameter result set. For example, the user may select one of the parameters listed in FIG. 6A. In another embodiment, additional searches may be performed until the user selects a device parameter from an additional search result set, as shown in FIG. 9.

[0043] At block 1105, the described method and system may query a second parameter result set based on the user selection at block 1104. The query may return display attributes of the user-selected device parameters. The query may also request current parameter values ​​of the user-selected device parameters from the electronic device. Because of high latency in some connections to electronic devices such as field devices, in embodiments, only the attributes and values ​​of the user-selected device parameters may be queried or obtained from the electronic device. The query may return information to display the user-selected device parameters in a quick view, as shown in FIG. 10. The quick view may include the user-selected device parameters alone or with the user-selected device parameters' correlated write-as-one parameters. The quick view may be considered a device parameter view of a single device parameter that is part of the described process. This quick view may be separate from the sequential menu view specified by the EDD as part of the hierarchical menu driven access process described above. In embodiments, block 1105 may query display attributes of the selected device parameters associated with the device parameter menu screen. In another embodiment, block 1105 can query display attributes that are not associated with the device parameter menu screen. It should be noted that while the device parameter menu screen may be programmed or specified by the EDD as part of the manufacturer's default program, the methods described herein may be implemented as an add-on program to an existing EDD or as an additional EDD. Thus, in one implementation, the described search functionality can operate on existing functionality of the EDD provided by the manufacturer, and a quick view that represents a different view from the manufacturer-specified device screen can use display attributes that are not included in the manufacturer-specified device screen.

[0044] In embodiments, several conditions may be implemented to check whether to refrain from displaying the EDD-specified device parameter menu and instead display a minimally rendered view, such as a quick view. For example, in embodiments where network latency is determined to be high and / or electronic device processing power is determined to be low (e.g., legacy field devices), block 1105 automatically refrains from rendering a device parameter view from the existing EDD menu hierarchy when performing the described search function and terminating the search with just a quick view of the parameter or parameters and their write-as-one collaborative parameters instead of the standard menu-driven device parameter screen.

[0045] In an embodiment, block 1105 may include retrieving a menu device parameter screen or view specified by the EDD and a portion of the EDD-specified default set of menus, as described above. An EDD-specified device parameter view, such as that shown in FIGS. 3-4, may consist of a complete set of parameters and information on how to display those parameters in a graphical user interface (GUI). The EDD specification may include instructions or data showing the location, color, texture, shape, etc. of the device parameters in relation to one another, and may include additional graphical elements, such as graphs, charts, tables, etc., that display one or more device parameters. In an embodiment, the first parameter result set may include a link to the device parameter screen, thus reducing the need to search for the device parameter view from scratch. In an embodiment, the device parameter screen may be defined by a database view or database table, and the link may be an identifier of the view or table. In some embodiments, the parameter information required for the device parameter screen or view may be retrieved from a markup language file generated based on the EDD file. For example, in an embodiment, block 1105 may retrieve the display attributes of the selected device parameter by retrieving an XML or JSON file that represents a device menu that includes the selected device parameter. However, it should be noted that in some embodiments, additional parameters of the device parameter screen may need to be searched or queried to provide a complete view for display or rendering. In addition to performing the search for the device parameter view, block 1105 may query any additional parameters or current parameter values ​​required to render the device parameter view (e.g., communicate with a device corresponding to the EDD to obtain current parameter values ​​or initiate a method of calculation performed by the device to derive parameter values).In an embodiment, block 1105 may initiate an update of a database view that includes information designed to be displayed in a device parameter view. In an embodiment, block 1105 may query a view without updating the view, where updating the view may include communicating with the electronic device to read current parameter values ​​or to calculate and process specific parameter values. A query of a non-updated database view or a query of an updated database view may draw more processing power than a limited parameter query, such as a query based on the quick view described above (for a single parameter or a single parameter that includes write-as-one related parameters).

[0046] In block 1106, a rendering function or program may be used to render a device parameter screen including the selected or desired device parameters. In some embodiments, the desired parameters may be highlighted in the rendered device parameter screen, such as element 361 of FIG. 7. In some embodiments, only the user selected parameters are displayed in block 1106 (e.g., quick view). In this embodiment, block 1106 may retrieve from block 1105 and still render the display characteristics of the user selected parameters as shown in FIG. 10. In this embodiment, an additional process block may include receiving a user preference for a quick view of only the user selected device parameters in block 1106, or a view including a menu or other parameters including the user selected device parameters. In some embodiments, the user preference may determine whether the process of block 1105 queries information of only the user selected device parameters, or queries multiple device parameters and device parameter values ​​of an existing menu device parameter view including the user selected device parameters. It should be noted that for high latency devices or devices connected over slow communication lines, the described method can reduce response time for accessing user-selected device parameters by refraining from retrieving and rendering a view with other parameters of the standard hierarchical menu that the user may not be interested in. Instead, the process can only retrieve and render information to display only the user-selected device parameters.

[0047] As described above, the EDD file may include various instructions on how to display a set or menu of parameters. This may include the location of each parameter, GUI components such as containers: drop-down menus, list boxes, etc., as well as colors, textures, contrast between components, text fields, buttons, check boxes, combo boxes, labels, lists, text fields, etc. When an EDD engine or interpreter processes an EDD file, the EDD engine may generate a visual representation file of the device parameter screen specified in the EDD. In an embodiment, the visual representation file may be a set of pages written in a markup language, such as Extensible Markup Language (XML) pages or Java Script Object Notation (JSON) pages. In block 1106, the XML or JSON file may be displayed in a user interface similar to a web browser. In block 1106, the user interface device parameter screen may be displayed, including all images, graphs, charts, tables, and other display objects. The described search function may be used to bypass intermediate sequential hierarchical menu screens (e.g., Figures 3-4) to access the desired parameter or a device screen containing the desired parameter.

[0048] The described processes and methods can be implemented using one or more components of an EDD-based process control device access system. For example, some function blocks can be performed in one component of the EDD system, while other function blocks can be performed in another component of the EDD system. Below are example implementations of the above-described processes and methods.

[0049] In one embodiment, an existing EDD for a process control device can be modified, for example, by inserting programming code to implement the search function described above. In this embodiment, additional device parameter specifications, business logic and / or user interface description (UID) code can be inserted into the existing EDD to implement the search function. In this embodiment, the search function can become an integral part of the user interface specified by the EDD. In one particular embodiment using an FDI system, an existing EDD can be modified to include a search function as part of the EDD's user interface description (UID).

[0050] In one embodiment, the EDD engine can be modified to implement the described search functionality without modifying existing device manufacturer provided EDD files. In one example, the EDD engine can be programmed to execute additional program modules adapted to include the search functionality described above. For example, the EDD engine can be adapted to execute a function such as a getAllParameters() function for a particular device when that device's EDD is loaded or interpreted by the EDD engine. The EDD engine or interpreter can then proceed to execute the other process blocks described above to build a visual representation of the device's user search interface (e.g., via a series of XML or JSON pages).

[0051] In one embodiment, the search functionality can be implemented as a display overlay on a visual representation specified in the EDD file by the manufacturer. For example, in the display shown in FIG. 5, the device manufacturer specified user interface can include window elements 202-220, while the search window 280 or 282 is an overlay generated by the EDD engine. In this manner, the EDD engine can be adapted to perform the requested search process using the functionality exposed by the device's EDD. In other words, in one embodiment, the EDD engine can implement the search functionality by calling an EDD specified function, such as a getAllParameters() function, and then manipulating the result set as described in the methods and processes above, and generating a visual representation in the form of XML or JSON for display as a search user interface.

[0052] In an embodiment including an FDI system in a process control plant, the FDI device package can be modified to include a UIP component that performs the described search function. For example, if an existing EDD provides exposed functionality that can be accessed by a UIP or other host processor program, the described process and method can be implemented in the UIP. The UIP can, for example, initiate a getAllParameters() type function provided by the UID via a graphical user interface of the FDI client. The other blocks 1102-1106 can then be executed or initiated by a host process on a client computing device that is also running the UIP.

[0053] In another embodiment involving an FDI system, the described method can be implemented in the UID, the UIP, or a combination of both the UID and the UIP. For example, the search function can be partially implemented using the EDDL of the UID, and the remaining extended search function is written into the UIP. In an embodiment, the UID can include a function that initiates a getAllParameters() type function and provides a list of device parameters and functions within a generic container (e.g., a text box). In this embodiment, the UIP can be programmed to filter, query, and search parameters within the text box as described above.

[0054] The following additional considerations apply to the above discussion: Throughout this specification, actions described as being performed by any device or routine generally refer to the actions or processes of a processor that manipulates or transforms data according to machine-readable instructions. The machine-readable instructions may be stored on and retrieved from a memory device communicatively coupled to the processor. In other words, the methods described herein may be embodied by a series of machine-executable instructions stored on a computer-readable medium (i.e., on a memory device). The instructions, when executed by one or more processors of a corresponding device (e.g., a server, a user interface device, etc.), cause the processor to perform the method. When instructions, routines, modules, processes, services, programs, and / or applications are referred to herein as being stored or saved on a computer-readable memory or on a computer-readable medium, the terms "stored" and "saved" are intended to exclude transitory signals.

[0055] Additionally, the terms "operator," "personnel," "person," "user," "technician," and other similar terms are used to describe persons within a process plant environment who may use or interact with the systems, apparatus, and methods described herein, but these terms are not intended to be limiting. Where particular terms are used in the description, the terms are used in part for traditional activities engaged in by plant personnel, but are not intended to limit the personnel who may engage in a particular activity.

[0056] In addition, throughout this specification, multiple instances may implement the structures described as components, operations, or single instances. Although individual operations of one or more methods have been illustrated and described as separate operations, one or more of the individual operations may be performed simultaneously, and the operations need not be performed in the order illustrated. Structures and functions presented as separate components in the example configurations may be implemented as combined structures or components. Similarly, structures and functions presented as single components may be implemented as separate components. These and other variations, modifications, additions, and improvements are within the scope of the subject matter of this specification.

[0057] Unless specifically stated otherwise, discussions herein using words such as "processing," "computing," "calculating," "determining," "identifying," "presenting," "causing to present," "displaying," "displaying," and the like may refer to the actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electrical, magnetic, biological, or optical) quantities in one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.

[0058] When implemented in software, any of the applications, services, and engines described herein may be stored in any tangible, non-transitory computer-readable memory, such as a magnetic disk, laser disk, solid-state memory device, molecular memory storage device, or other storage medium, such as in the RAM or ROM of a computer or processor. It should be noted that while the exemplary systems disclosed herein are disclosed to include software and / or firmware running on hardware, among other components, such systems are merely exemplary and should not be considered limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components may be embedded solely in hardware, solely in software, or in any combination of hardware and software. Thus, one skilled in the art will readily appreciate that the examples provided are not the only ways to implement such a system.

[0059] Thus, while the invention has been described with reference to specific examples, it will be apparent to those skilled in the art that these examples are illustrative only and are not intended to be limitations of the invention, and that modifications, additions, or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the invention.

[0060] It should also be understood that unless a term is expressly defined in this patent using the sentence "As used herein, the term '______' is herein defined to mean ..." or a similar sentence, there is no intention to limit the meaning of the term, either expressly or by implication, beyond its plain or ordinary meaning, and such term should not be construed as being limited in scope based on any statement made in any section of this patent (other than the claim language). If any term recited in the final claim of this patent is referred to in this patent in a manner consistent with a single meaning, it is done merely for clarity so as not to confuse the reader, and it is not intended that such claim term be limited, by implication or otherwise, to that single meaning. Finally, unless a claim element is defined by the words "means" and a recitation of a function without any recitation of structure, the scope of any claim element is not intended to be construed based on application of 35 U.S.C. 112(f) and / or pre-AIA 35 U.S.C. 35 U.S.C. 112, paragraph 6.

[0061] Moreover, although the above text describes detailed descriptions of many different embodiments, it should be understood that the scope of this patent is defined by the language of the claims set forth at the end of this patent. The detailed description should be construed as merely exemplary and does not describe all possible embodiments, as describing all possible embodiments would be impractical, if not impossible. Many alternative embodiments could be implemented using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims.

Claims

1. A method for displaying parameters of an electronic device having an electronic device description (EDD) interpreted by an EDD interpreter executing on a computing device, the computing device being communicatively coupled to at least the electronic device, the method comprising: Querying a set of device parameters associated with the electronic device; applying a first search algorithm to the set of device parameters based on a first user search string to generate a first parameter result set; displaying the first parameter result set obtained from the query of the first set of device parameters without rendering display attributes associated with the first parameter result set; receiving user selected device parameters; Querying a second parameter result set based on the user selected device parameters; displaying the second parameter result set including display attributes associated with the second parameter result set.

2. The method of claim 1 , wherein querying the second parameter result set comprises querying display attributes of the user-selected device parameters and requesting current values ​​of the user-selected device parameters from the electronic device.

3. The method of claim 2 , wherein the display attributes are separate and distinct from display attributes of a sequential-based menu screen view.

4. 4. The method of claim 1, wherein querying the second parameter result set comprises querying a view for display attributes of the user-selected device parameters and requesting current values ​​of the user-selected device parameters from the electronic device, the display attributes describing a visual representation of the user-selected device parameters in the view, and the view including a plurality of device parameters.

5. The method of claim 4 , further comprising displaying the user-selected device parameter along with a view display attribute and the current value of the user-selected device parameter without rendering an entire view that includes the user-selected device parameter.

6. The method of any of claims 1 to 5, further comprising searching a view defined at least by a subset of the device parameters of the electronic device and a set of display attributes for each of the subset of device parameters, wherein the user-selected device parameter is one of the device parameters of the view, and querying the second parameter result set comprises sending a request to the electronic device for current values ​​of the set of device parameters included in the view.

7. 7. The method of claim 6, wherein the set of device parameters includes a set of attributes including a parameter name, a parameter type, and a parameter identifier, and searching the view includes querying an identifier of the view based on the parameter identifier associated with the user-selected device parameters.

8. The method of claim 7 , wherein displaying the second parameter result set includes displaying current values ​​of the user-selected device parameters.

9. 9. The method of claim 7 or claim 8, further comprising filtering the first parameter result set by a parameter type, the parameter type indicating one of a set of EDDL layout objects, the set of EDDL layout objects including a parameter, a window, a dialog, a group, a page, a chart, a graph, a menu, a grid, an action, and a user interface plug-in (UIP) control.

10. 10. The method of claim 1, wherein displaying the first parameter result set and displaying the second parameter result set comprises rendering one of an Extensible Markup Language (XML) page or a Java Script Object Notation (JSON) page generated by the EDD interpreter based on the EDD.

11. The method of claim 1 , wherein querying a set of device parameters associated with the electronic device comprises modifying the EDD interpreter to search for a markup language file generated based on the EDD.

12. 12. The method of claim 11, wherein displaying the first parameter result set without rendering display attributes associated with the first parameter result set comprises displaying text characters of parameter identifiers of the first parameter result set without rendering display characteristics specified in the markup language file.

13. 13. The method of claim 1, further comprising: storing the first user search string in a search string cache; applying a third search algorithm to the search string cache based on user input to generate a list of search suggestions; and displaying the list of search suggestions.

14. 1. A computing device for accessing parameters of an electronic device communicatively coupled to the computing device, comprising: an Electronic Device Description (EDD) file written using an Electronic Device Description Language (EDDL) and adapted to specify a sequence of device parameter views, each device parameter view including a set of parameters for said electronic device; an Electronic Device Description (EDD) interpreter adapted to communicate with the electronic device and to convert a set of views specified in the EDD into a set of markup language files, the markup language files including at least one of Extensible Markup Language (XML) pages or Java Script Object Notation (JSON) pages; a user interface adapted to communicate with the EDD interpreter, to receive the markup language file, to render a user interface on a display device based on the markup language file, and to receive input from a user; A rendering component, Querying a set of device parameters associated with the electronic device; applying a first search algorithm based on a first user input to the set of device parameters to generate a first parameter result set; displaying the first parameter result set retrieved from the query of the first set of device parameters without rendering display characteristics associated with the first parameter result set; receiving user selected device parameters; Querying a second parameter result set based on the user-selected device parameters; a rendering component adapted to display the second parameter result set including rendering display characteristics of parameters of the second parameter result set.

15. The computing device of claim 14 , wherein the EDD file is adapted to implement the rendering component as part of a User Interface Description (UID) of the Electronic Device Description (EDD).

16. 16. The computing device of claim 14 or 15, wherein the electronic device is a field device in a process plant, the electronic device description (EDD) is a component of an FDI device package that conforms to the Field Device Integration (FDI) standard, the EDD interpreter is an FDI EDD engine, and the user interface is adapted to execute the rendering component as part of a user interface plug-in (UIP) component received from the FDI EDD engine, the UIP component being adapted to be executed by an operating system of the computing device.

17. 17. A computing device as claimed in claim 14, wherein the rendering component is adapted to be executed in part by a User Interface Description (UID) of the Electronic Device Description (EDD), the UID being adapted to initiate the query for the set of device parameters.

18. 20. The computing device of claim 17, wherein the rendering component is adapted to execute in part in a user interface plug-in (UIP) executed by an operating system of the computing device, the UIP being adapted to apply the first search algorithm against the set of device parameters.

19. A computing device according to any of claims 14 to 18, wherein the EDD interpreter is adapted to execute the rendering component on the set of markup language files generated based on the EDD file.

20. 1. A system communicatively coupled to a field device, the system using an electronic device description to access field device parameters of a process control system and to specify a communication interface between the field device and a workstation remote from the field device, the system comprising: a server including an electronic device description engine (EDD engine) storing at least one electronic device description (EDD) of an electronic device corresponding to the field device, the workstation being adapted to receive a markup language file for rendering a view generated by the EDD engine based on the electronic device description, the view including a plurality of parameters to be rendered on a single viewable window; A rendering component, Querying a set of device parameters associated with the electronic device; applying a first search algorithm based on a first user input to the set of device parameters to generate a first parameter result set; displaying the first parameter result set retrieved from the query of the set of device parameters to a user without rendering display characteristics of the first parameter result set; receiving user selected device parameters; Querying a second parameter result set based on the user-selected device parameters; a rendering component adapted to display the second parameter result set including rendering display characteristics of the parameters of the second parameter result set.

Images