MECHANISM FOR CONSTRUCTING GENERIC CONTROL LOGIC INCLUDING VERSIONS IN VARIOUS PROTOCOLS

Abstract

A mechanism for constructing generic control logic with versions of the logic automatically generated and stored for one or more protocols. The complexity of the one or more protocols may be hidden under a hood of the mechanism from the view of engineers, programmers and users so as to improve their productivity relative to control logic designs and applications.

Description

BACKGROUND

The invention pertains to programming and particularly to various communication protocols of applications. More particularly, the invention pertains to knowledge of numerous protocols needed by application engineers.

SUMMARY

The invention is a mechanism for minimization or elimination of a need by application design engineers to have knowledge of one or more protocols while designing control logic applications. The mechanism may provide generic control logic applications that have versions automatically made to be used in controllers of various protocols.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a diagram of a workbench for opening an application library;

FIG. 2 is a diagram of control logic with data points and function blocks;

FIG. 3 is a diagram of the workbench for invoking a configuration of a data point;

FIG. 4 is a diagram of the workbench for configuring general properties of the data point;

FIG. 5 is a diagram of the workbench for configuring specific properties of a certain protocol;

FIG. 6 is a diagram of the workbench for configuring specific properties of a another protocol; and

FIG. 7 is a diagram of the workbench for viewing the mapping of a data point to a network interface.

DESCRIPTION

Programming tools used by HVAC (heating, ventilation and air conditioning) application engineers may be quite complex and often expose details of the underlying communication protocols to users. This may force the application engineers to be protocol experts apart from being HVAC experts. This is not necessarily practical for an application engineer as there may be several communication protocols used in HVAC automation. Some protocols may involve those of LonTalk™ (LonTalk, Lon™, Lon), LonWorks™ (LonWorks), and BACnet (Bacnet). LonTalk and Lon are trademarks of Echelon Corp. BACnet is a communications protocol for building automation and control networks.

A Spyder™ (Spyder) programming tool may support programming of Lon Spyder controllers. Spyder is a trademark of Honeywell International Inc. Often, users may need to create the same control application twice, one for Lon Spyder and one for BACnet Spyder which can be time consuming and prone to mistakes. The applications may need to be replicated for the Lon and BACnet versions. Also, any small changes to a Lon application may need to be replicated in the BACnet version of the application.

The Spyder tool may have an application library that is used to create, modify and store Spyder applications for later use. This tool may allow engineers to design a generic application feature in the application library. When a user creates an application, the tool may automatically generate two network interface views (e.g., Lon and BACnet). The user may simply add points on the wire sheet, and tool can automatically create corresponding backend Lon network variables and BACnet objects. This way, one may keep applications generic for Lon and BACnet versions of the applications, and thus applications need not be replicated and any changes to the application may be reflected in both Lon and BACnet versions of the application.

A generic application may improve productivity of field engineers and keep the complexity of communication protocol hidden under the hoods of the system. Figures noted herein show steps that an engineer may go through to create generic applications reusable with various protocols. When an engineer drops a data point in the tool for the purpose of using it in the control logic, the tool may automatically create an underlying protocol object and maintain a mapping/reference between the point and the protocol object. The tool may maintain a reference for every protocol supported; that is, since Lon and BACnet are supported, the tool may maintain two references for every data point dropped by the user into the control logic. This approach may allow the tool to do automatic translation when the control logic is used in a target Spyder device.

The present approach may concern creating generic control applications for Spyder. The first step may be an opening the Spyder application library. This may be achieved by clicking on “window” 12 of a Niagara workbench as shown by screen 11 of FIG. 1. “Side Bars” 13 may be clicked on to show a drop-down menu with “Spyder Library” 14 listed. “Spyder Library” 14 may be clicked on to open a Spyder application library. A control program 58 may be shown as indicated by a Nav (navigation) palette 59 menu. As a second step, control logic may be created by using data points and function blocks as shown by screens 11 and 15 of FIGS. 1 and 2, respectively. As examples for an illustration, input points may include space temp 16, set point 17, AV4 Software 18 and an output point 19 for a damper. Function blocks may include PID 21, priority override 22 and life safety app 23. The Figures may also relate to VAV (variable air volume) aspects.

The space temp input point 16 may be connected to function block 21 with a link 38. Setpoint input point 17 may be connected to function block 21 with a link 39. An output of the PID (proportional-integral-derivative) function block 21 may be connected to an input of priority override 22 with a link 46 and life safety app may be connected to another input of priority override 22 with a link 48. An output of priority override 22 may be connected to damper output point 19.

A third step may invoke a configuration screen or menu 25 of the space temperature data point 16 by clicking on data point 16. This step and resulting menu 25 are shown by screen 24 of FIG. 3. “Configure Properties” of menu or screen 25 may be clicked on to get a dialog box or screen 27 for configuring general properties of data point 16, as a fourth step shown by screen 26 of FIG. 4. The properties may include point name 43, point type 52, type 57, point category 61 and unit 62. Input state box 63 may have entries spaces 64, 65, 66 and 67 for input low, output low, input high and output high, respectively. Box 27 may include a “Help” button 68, “Sensor Limits” button 69, “Advanced” button 28, “OK” button 71 and “Cancel” button 72.

“Advanced” button 28 of box 27 may be clicked on to get a dialog box or menu 31 to configure network interface specific properties. A fifth step may include configuring BACnet specific properties by selecting the respective tab 32 of dialog box 31 to get a box 81 for selection of the properties, as shown in screen 29 of FIG. 5. These properties may include object name 73, object instance 74, object type 75 and significant event notification delta 76. A box 77 may provide for GPU (guaranteed periodic update) selection and “Send Heart Beat” indication. Selected properties may be accepted by clicking on the “OK” button 78 or rejected by clicking on a “Cancel” button 79.

The sixth step may include configuring Lon specific properties by selecting the respective tab 33 of dialog box 31 to get a box 82 for selection of the properties, as shown in screen 34 of FIG. 6. Box 82 indicates NV (network variable) composition with specific properties for Lon. Such properties may include NV name copied from a standard list 85 or a custom selection 86. Field properties 87 may include field name 88, data category 89, network data type 91, internal data type 92 and value 93 may be selected and edited. The selections and edits may be saved under a UNVT (user network variable type) name 94 such as SNVT_temp_p. “SNVT” may be regarded as a standard network variable type. The “OK” button 35 or “Cancel” button 83 may be clicked on to accept the configured specific properties.

The seventh step may include viewing a mapping of a data point to the network interface by accessing corresponding views as shown by screen 36 of a wiresheet in FIG. 7. Drop down menu 37 may be available for a selection of various views such as a NV configuration view (Lon) or an object configuration view (BACnet).

The Spyder tool may offer a graphical environment to program the Spyder controller. One may use a wiresheet view in the engineering mode (such as an example shown in screen 36 of FIG. 7) to use physical points, software points, and function blocks to build an application in the control program. The physical points, software points, and function blocks may be accessed using a palette 40. One may drag these items on to the wiresheet and connect them, based on one's need, to develop application logic like that in screen 36. The logic that one creates may then be stored in a Spyder library for reuse. Upon being satisfied with the logic one has created, one may download the same to the controller. The logic thus created may be tested for correctness by selecting simulation and online debugging modes.

One may note that changing NCI (network configuration input) values, configuration of a schedule block, or daylight savings option, puts the application in a quick download pending state. As long as the application has been downloaded at least once to the controller, these changes just trigger a quick download to the controller.

One may use the control program option to program the Spyder tool. To do this, one may expand Lon Spyder or BACnet Spyder in the Nav palette and double-click control program to display the wiresheet view; display the palette (from the menu bar, select Window>Sidebars>Palette to display the palette).

The palette may appear on the left pane with the following items. Lon Spyder is a device that one may drag on to the Lon network in the Nav palette 59 to create a new device. Note that one cannot drop this on to the wiresheet of any macro or control program or application. BACnet Spyder is a device that one may drag on to the BACnet network in the Nav palette 59 to create a new device. It may be noted that one cannot drop this on to the wiresheet of any macro or control program or application. Physical points may be modulating and binary inputs or outputs. Software points may be used to create a network input, network setpoints, or a network output.

Additional items may include analog function blocks, logic function blocks, math function blocks, control function blocks, data-function function blocks, zone arbitration function blocks, and built-in function blocks.

It may be noted that a macro may be a group of functional blocks grouped together that define a specific functionality. Commonly used program elements may be defined as macros so that they could be reused across applications. An application may include macros and logic that one can define and use in applications. Standard applications may be provided for the Spyder used to build application logic.

One may drag any of these noted items on to the wiresheet of a control program in its engineering mode and make the connections between physical points, software points, and function blocks to create a control program or an application.

A wiresheet view may be used to drag the physical points and function blocks to build the application logic. One may save a logic created to be used later and also shared with other users. One may build several applications and store them in a Spyder library along with standard applications.

After one has created the application logic and tested the logic using the simulation feature, the application logic may be downloaded to the controller. To download the application logic, one may: 1) on the Nav palette, right-click the device and select Actions>Download (the download dialog box may appear); and 2) select True under full download for a full download or false for a quick download. One may note that a quick download just downloads the modified items from a previous download where as with a full download the entire configuration may be downloaded to the controller replacing the existing configuration. However, if changes have been made to the sensor bus (SBus) wall module by an operator/tenant locally from the display on the wall module, and a full download is performed, the Spyder tool may download the entire configuration to the controller except the SBus (Sylk or sensor bus) wall module configuration. This may be done to avoid losing any changes made locally on the SBus wall module during a download operation. Then at 3), one may click OK. The application logic may be downloaded to the controller based on one's selection.

In the present specification, some of the matter may be of a hypothetical or prophetic nature although stated in another manner or tense.

Although the present system has been described with respect to at least one illustrative example, many variations and modifications will become apparent to those skilled in the art upon reading the specification. It is therefore the intention that the appended claims be interpreted as broadly as possible in view of the prior art to include all such variations and modifications.

Claims

1. A method for constructing a generic control logic, comprising: opening an application library;constructing a control logic in a generic version; andwherein:a library tool automatically saves the control logic in versions of one or more protocols supported by the tool; andthe control logic is accessible from the library in a generic version or a version of the one or more protocols.

2. The method of claim 1, wherein the one or more protocols have a complexity that is hidden from the method of constructing the control logic under a hood.

3. The method of claim 1, wherein: the control logic comprises components being one or more function blocks and data points; andas each component is added to the control logic, the tool maintains a reference of the component in each of the one or more protocols.

4. The method of claim 3, further comprising: for each component, invoking a configuration screen for the component;configuring general properties of the component;configuring specific properties of the component for a first protocol for a network interface; andconfiguring specific properties of the component for a second protocol for the network interface.

5. The method of claim 4, further comprising viewing a mapping of the components to the network interface.

6. The method of claim 5, wherein the viewing is of a first protocol view.

7. The method of claim 5, wherein the viewing is of a second protocol view.

8. The method of claim 5, wherein the viewing is of a wiresheet.

9. The method of claim 4, further comprising configuring specific properties for one or more additional protocols for a network interface.

10. The method of claim 4, wherein: the first protocol is BACnet; andthe second protocol is LonWorks.

11. The method of claim 10, wherein the library is a Spyder application library.

12. The method of claim 4, wherein the invoking a configuration screen of the component, the configuring general properties of the component, the configuring specific properties for a first protocol for a network interface, and the configuring specific properties for a second protocol for the network interface occur automatically while constructing the control logic comprising components.

13. A method for obtaining an application, comprising: constructing a control logic comprising function blocks and data points; andproviding a tool that automatically generates protocol interfaces upon the constructing of the control logic.

14. The method of claim 13, wherein as data points are added to a wiresheet, the tool automatically provides corresponding backend entities of each protocol for the data points.

15. The method of claim 14, wherein since changes to the control logic are reflected in the protocol versions of the control logic, the control logic need not be replicated for the either protocol.

16. The method of claim 13, wherein when a data point is dropped in the control logic, the tool automatically creates an underlying protocol entity and maintains a mapping or reference between the data point and the protocol entity.

17. The method of claim 16, wherein: the protocols comprise Lon and BACnet protocols;the Lon and BACnet protocols are supported by the tool;the tool maintains a mapping or reference for each protocol supported;the tool maintains at least two mappings or references for each data point dropped into the control logic; andthe tool does an automatic translation for each protocol when the control logic is used in a Spyder controller.

18. The method of claim 17, wherein the translation for each protocol is hidden under a hood of the controller.

19. A system for creating a generic control application, comprising: an application library;control logic constructed from data points and function blocks;a configuration menu for each data point;a first dialog box for configuring general properties of each data point;a second dialog box for configuring network interface specific properties for each protocol used; anda map of each data point to a network interface with a corresponding view for each protocol.

20. The system of claim 19, further comprising: a tool for automatically generating protocol interfaces for the control logic; andwherein when a data point is dropped in the control logic, the tool automatically provides an underlying protocol entity and maintains a mapping or reference between the data point and the protocol entity.