ES2876010T3 - System and method for naming objects automatically in a building automation system - Google Patents

Abstract

A method of designing and naming building automation devices (304a, 304b, 304c) and field devices of a building automation system by automatically naming a plurality of building automation objects in a model (302, 502 , 602, 702, 802, 900) of the building automation system, the method comprising: providing a building automation device (304a, 304b, 304c); provide a building automation model (302, 502, 602, 702, 802, 900) comprising a parent view node object (20, 70, 504, 512) representing the building automation device (304a, 304b, 304c) building automation and a child view node object (30, 80, 90, 506, 612) logically linked to a field device, where the child view node object (30, 80, 90, 506, 612) it is logically linked to the parent view node object (20, 70, 504, 512) forming a hierarchical structure; assigning an object-name (310a-316a) to the parent view node object (20, 70, 504, 512) representing a name of the building automation device (304a, 304b, 304c); and assigning an object-name (310a-316a) to the child view node object (30, 80, 90, 506, 612) comprising the object-name (310a-316a) of the object (20, 70, 504, 512 ) parent view node and a name representing the field device, where the hierarchical structure is made up of a logical tree of one or more parent-child-grandchild nodes such that each child is logically linked to a parent corresponding and each grandchild is logically linked to a corresponding child, forming a logically linked list, where a control program instructs and interacts with the building automation model object hierarchy to name the objects, where the program Iterates through the one or more parent view node objects and the one or more child view node objects logically linked to the one or more parent view node objects and reads and/or writes data into any of them. objects of such such that it communicates with one or more field devices logically linked to one or more child view node objects.

Description

DESCRIPTION

System and method for naming objects automatically in a building automation system

Technical field

The present invention relates generally to building systems and, more particularly, to systems, processes, and methods for efficiently communicating with a plurality of field devices in a hierarchical structure.

Background

A building automation system is an arrangement for monitoring, open loop control and / or closed loop control of process variables in complex technical systems in a building, or on a campus comprising a number of buildings. A building automation system typically operates heating, ventilation, and air conditioning systems, lighting and shading devices, as well as access control, security, and fire surveillance systems. In the building automation system, process variables are detected, evaluated, monitored, influenced or generated - such as room air conditioning variables or events for example - being the energy consumption of the building or campus also advantageously optimized by the system of building automation.

Generally, a building automation system encompasses and operates a plurality of what are known as field devices, such as sensors and actuators. Examples of typical field devices are temperature and humidity sensors, air quality sensors, pressure sensors, flow meters, electricity meters, heat meters, brightness sensors, fire alarms, intrusion alarms, alarm devices or sprinklers, hot water valve drives, thermostat valves, vents or louvers, light switches, smart card readers or devices to detect biometric data. The building automation system typically comprises a plurality of software modules, processes or programs, and in general a number of computers or processors for their activation and also as a rule a plurality of open loop and closed loop control devices as well as devices additional, for example devices for linking the building automation system to external communication networks, device displays for video signal analysis.

The elements (objects or field devices) of a building automation system are widely dispersed throughout an installation. For example, an HVAC system includes temperature sensors and vent damper controls as well as other elements that are located in virtually every area of a facility. Similarly, a security system can have intrusion detection, motion sensors, and alarm triggers scattered throughout a building or campus. Additionally, fire safety systems include smoke alarms and trigger stations scattered throughout the facility. To achieve efficient and effective building automation system operation, there is a need to monitor the operation of, and often communicate with, the various dispersed elements of a building automation system.

Electric or wireless communication means are used in a building automation system for data exchange of individual devices or parts of systems, as a rule there are a number of communication networks, with cables, optical data communication channels, connections of ultrasound, near electromagnetic fields or radio networks that can be used, including fiber optic networks or cellular networks for example. Examples of technologies or standards that can be used for such data exchange are BACnet, LON or LonWorks® from the company ECHELON, the European installation bus EIB, KONNEX, ZigBee or PROFIBUS defined by the German standard DIN 19245.

Building automation systems typically have one or more centralized control stations in which data for each of the elements in the system can be monitored and in which various aspects of system operation can be controlled and / or monitored. . The control station typically includes a computer having processing equipment, data storage equipment, and a user interface. To enable monitoring and control of dispersed control system elements, building automation systems often employ multi-level communication networks to communicate operational and / or alarm information between operational elements, such as sensors and actuators, and the station. centralized control.

An example of a building automation system control station is the APOGEE® INSIGHT® Workstation, available from Siemens Industry, Inc. of Buffalo Grove, Ill., Which can be used with the Model APOGEE building automation system. ®, also available from Siemens Industry, Inc. (APOGEE and INSIGHT are federally registered trademarks in the United States of Siemens Industry, Inc.) In this system, several control stations, connected via Ethernet or other types of network, can be distributed across one or more building locations, each having the ability to monitor and control system operation. As a result, different people at different locations in the facility can monitor and control building operations.

The typical building automation system (including those using the APOGEE® Insight® Workstation) has a plurality of field panels and / or controllers that are in communication with a workstation. In addition, the building automation system also includes one or more field devices connected to the field panels and / or controllers. Each field device is typically operative to measure and / or monitor various building automation system parameters. In particular, each field device can include one or more sensors and / or actuators to measure and / or monitor corresponding "points" within the respective building and / or building automation system. As referenced herein, a "point" can be (i) any physical input or output to or from a respective controller, field device, sensor, or actuator, or (ii) any virtual point associated with a control application. or logical object within a controller or field panel that is measured, monitored or controlled. Although the workstation is generally used to make modifications and / or changes to one or more of the various components of the building automation system, a field panel can also be operative to enable certain modifications and / or changes to one or more system parameters. This typically includes parameters such as a temperature set point or other set points on a field device controller or directly on a field device. In addition, the workstation can be configured to modify a control program or the like on a field panel to control a field device.

Adding components to the building automation system is inefficient and time consuming. Each of the individual field devices, components, and subcomponents (collectively objects) needs to be manually entered and assigned a name in the building automation system so that the building automation system can communicate with the object. The naming of individual objects is time consuming and error prone for at least these reasons. First, the name needs to be retrievable so that the system can find the stored object. Second, names are often duplicates of other names, thus causing a system error when having two or more devices that share the same name.

US 2005/0289467 A1 discloses an arrangement for coordinating data representative of a building system that includes a memory-connected process. The memory stores a plurality of building space objects and at least one building automation device object. At least one building space object includes a reference to at least one of the group consisting of a parent building space object and a child building space object, a reference to at least one graphic file containing an image representation building space graph, and a reference to information regarding one or more building automation devices associated with the building space object.

Therefore the object of the present invention is to provide a more efficient solution to the problems mentioned above.

Short summary

In a first aspect, a design and naming method of building automation devices and field devices of a building automation system by automatically naming a plurality of building automation objects of a building automation model of the system. of building automation, the method comprising: providing a building automation device; provide a building automation model comprising a parent view node object representing the building automation device and a child view node object logically linked to a field device, wherein the child view node object is logically linked to the parent view node object forming a hierarchical structure; assigning an object-name to the parent view node object that represents a name of the building automation device; and assign an object-name to the child view node object that comprises the object-name of the parent view node object and a name that represents the field device, where the hierarchical structure is formed by a logical tree of one or more parent-child-grandchild nodes such that each child is logically linked to a corresponding parent and each grandchild is logically linked to a corresponding child, forming a logically linked list, where a control program instructs and interacts with the hierarchy building automation model objects to name the objects, where the control program iterates through the one or more parent view node objects and the one or more child view node objects logically linked to the one or more parent view node objects and read and / or write data within any of the objects in such a way that it communicates with one or more link field devices two logically to the one or more child view node objects.

In a second aspect, a design system for designing and naming building automation devices and field devices of a building automation system, the design system configured to automatically naming a plurality of building automation objects of a building automation model of the building automation system and to represent a hierarchical structure representing one or more building automation devices (304a, 304b, 304c) and one or more field devices, the design system comprising: a parent view node object representing a building automation device and logically linked to a plurality of child view node objects, wherein each of the plurality of child view node objects is logically linked to a child view node object countryside; wherein the parent view node object comprises an object-name, and wherein each of the plurality of objects The child view node object comprises an object-name of the parent view node object and a name representing the field device to which each of the plurality of child view node objects is logically linked, where the hierarchical structure is formed by a logical tree of one or more nodes of parent-child-grandchild in such a way that each child is logically linked to a corresponding parent and each grandchild is logically linked to a corresponding child, forming a logically linked list, where a program The control program instructs and interacts with the building automation model object hierarchy to name the objects, where the control program iterates through the one or more parent view node objects and the one or more parent view node objects. child view node logically linked to the one or more parent view node objects and reading and / or writing data within any of the objects in such a way as to communicate with one or more field devices logically linked to the one or more child view node objects.

In a third aspect, a computer-readable storage medium that has stored in it data that represent executable instructions by a processor programmed to iterate through a hierarchical structure that represents one or more building automation devices and one or more devices. of a building automation system, and to automatically nomenclature a plurality of building automation objects of a building automation model of the building automation system, the storage medium comprising instructions for: accessing an object from parent view node; access a child view node object; Logically bind the child view node object to the parent view node object; assign an object-name to the parent view node object; and assign an object-name to the child view node object that comprises the object-name of the parent view node object and a name that represents a field device logically linked to the child view node object, where the hierarchical structure is formed by a logical tree of one or more nodes of parent-child-grandchild in such a way that each child is logically linked to a corresponding parent and each grandchild is logically linked to a corresponding child, forming a logically linked list, where a control program is adapted to instruct and interact with the building automation model object hierarchy to name objects, wherein the control program is adapted to iterate through the one or more parent view node objects and the one or more child view node objects logically linked to the one or more parent view node objects and read and / or write data within any Line of objects in such a way that it communicates with one or more field devices logically linked to the one or more child view node objects.

Brief description of the drawings

The embodiments will be further described in connection with the accompanying drawing figures. The drawings included as a part of this specification are intended to be illustrative of example embodiments and are in no way to be construed as limiting the scope of the invention. In fact, the present disclosure specifically contemplates other embodiments not illustrated but intended to be included in the claims. Furthermore, it is understood that the figures are not necessarily drawn to scale.

Figure 1 illustrates a functional block diagram of a building automation system structure for operating a section of a building;

Figure 2 illustrates a functional diagram for modeling a further building section, having a number of rooms or zones, that can be operated by the building automation system;

Figure 3 illustrates a functional block diagram of a plurality of building automation devices that collectively implement a building automation model;

Figure 4 further illustrates the functional block diagram of a plurality of building automation devices that collectively implement a building automation model illustrated in Figure 3;

Figure 5 illustrates a hierarchical nomenclature structure of a building automation model;

Figure 6 illustrates another hierarchical nomenclature structure of a building automation model;

Figure 7 illustrates another hierarchical nomenclature structure of a building automation model;

Figure 8 illustrates another hierarchical nomenclature structure of a building automation model;

Figure 9 illustrates a method of inserting and naming building automation objects to form a building automation model;

Figure 10 illustrates the partition of the object name and possible optional and mandatory entries to construct an object name.

Figure 11 illustrates part field delimiters and part field length rules for constructing an object name;

Figure 12 illustrates a graphical user interface system for defining naming rules; and

Figure 13 illustrates a graphical user interface system that has naming rules applied.

Detailed Description of Currently Preferred Embodiments

The example embodiments provided are illustrative. The present invention is not limited to the embodiments described herein, but the disclosure includes all equivalents. The systems, processes, and methods can be used in any field that benefits from configurable dynamic controllers.

Unless otherwise defined, all technical and scientific terms used in this document have the same meaning as commonly understood by one of ordinary skill in the art. In case of conflict, this document will prevail, including definitions. Preferred methods and materials are described below, although apparatus, methods, and materials similar or equivalent to those described herein may be used in practice or in testing. All publications, patent applications, patents, and other references cited herein are incorporated by reference in their entirety to the extent permitted by law. The materials, methods, and examples disclosed in this document are illustrative only and are not intended to be limiting.

The terms "comprise", "include", "having", "has", "may", "contains", and variants thereof, as used in this document, are intended to be expressions, terms, or words. transitional areas that do not exclude the possibility of additional acts or structures. The present disclosure also contemplates other embodiments "comprising", "consisting of" and "consisting essentially of", the embodiments or elements presented herein, whether or not they are explicitly stated.

A more detailed description of the embodiments will now be given with reference to Figures 1-13. Throughout the disclosure, like reference numbers and letters refer to like items. The present disclosure is not limited to the illustrated embodiments; rather, the present disclosure specifically contemplates other embodiments not illustrated but intended to be included in the claims.

Because naming each object in a building automation system, including field devices and related components, is time consuming and error prone, what is needed is a system and method to provide for automatically naming objects. , such as those that comprise a portion of a building automation system. Such a method and system reduces complexity and improves efficiency when adding an object to a building automation system. Additionally, such a method and system reduces human naming errors and duplication of already used names. Additional advantages and benefits will be evident.

Figure 1 illustrates an enclosure 1 of a building section that can be operated by a building automation system by controlling and / or monitoring field devices therein. Assigned to enclosure 1 are a number of field devices, through the use of which for example a desired comfort for users and a required security for users and infrastructure can be achieved with optimized operating costs. Typically assigned to enclosure 1 are an enclosure unit 2, a light switch 3, an air conditioning register 4, a heating element 5, a heating register 6, and a louver drive 7, although other configurations are contemplated. Enclosure Unit 2 serves as the user interface for the building automation system, including but not limited to, entering a nominal ambient temperature range and displaying the current ambient temperature as well as displaying an order of magnitude of costs of the energy consumed by the enclosure 1.

The devices operated in the enclosure 1 are advantageously modeled in the software of the building automation system as necessary and the corresponding models are preferably implemented using an object-oriented approach. Typically models are connected via input / output modules (or building automation objects, also referred to as BA objects) to field devices. For example, the enclosure unit 2 is mapped by an enclosure unit model (or BA object) 10, the light switch 3 by a light switch model (or BA object) 11, the air conditioning register 4 by a air conditioning register model (or BA object) 12, lighting element 5 by means of a lighting element model 13, heating register 6 by a heating register model (or BA object) 14 and drive 7 of shutter using a shutter drive model (or BA object) 15 in the building automation system.

An overview of all of the functionality of the automation functions available for enclosure 1 is stored in a first overview node 20 (also referred to as a parent view node object). The first overview node 20 is a building automation system object and presents an overview list (also referred to as a view node item list) 21, which has at least one semantic information unit. The semantic information unit identifies an automation function, which is provided in the enclosure 1 represented by the first overview node 20. Advantageously, the semantic information unit contains at least one suitable identifier for identification and a relationship with the automation function involved. Advantageously the name is a string data type with a fixed or variable length. A collection of units of semantic information (also called a list of node items of view) may include a logically linked list of semantic information units to one or more parent or child nodes.

A specific relationship between two nodes or objects in the building automation system is designated in this text by the term relationship in such a way that they form one or more parent-child relationships. The relationship has a predefined type range that comprises at least two different relationship types. In the present case what is known as a relationship of contacts (or connections) and what is known as a "property" relationship or a logically linked / connected relationship. The contact relationship is here identical to the relationship with the value "contacts" and here means that this relationship is implemented in such a way that the relationship is suitable for a two-way data exchange between the nodes or objects in question. The property relationship is here identical to the relationship with the value "property" and here means that this relationship is implemented in such a way that the relationship is suitable on the one hand for a bidirectional data exchange between the nodes or objects in question, for On the other hand, the nodes or objects with the property relationship are advantageously existentially linked to each other in such a way that they can only be copied, moved and deleted together, by means of a design tool for example.

In the present example embodiment the overview list 21 has space for nine units 21.1 to 21.9 of semantic information collectively form a collection of semantic information units (also referred to as a list of view node items).

A unit 21.3 of semantic information that can be identified by the identifier "HVAC" - that is heating, ventilation and air conditioning - has a property relation 24, which is applied between the first overview node 20 (also referred to as an object view node parent) and a second overview node 30 (also referred to as a child view node object). The semantic information in the parent item list can be taken, at least in part, from a logically linked / connected child object (eg its part name). In addition, similar information sharing from a parent object logically connected to one or more child objects can share a number of other types of information, including but not limited to semantic information. Consequently, information can be shared, transferred, and reused between parent and child objects.

A semantic information unit 21.2 that can be identified by the identifier "light-ctr" - that is to say light control - has a property relation 23, which is applied between the first overview node 20 and a third vision node 40 general (also referred to as a child view node object).

A unit 21.4 of semantic information that can be identified by an identifier " room-u " - that is to say unit of enclosure - has a property relation 25, which is applied between the first overview node 20 and the model 10 of unit of enclosure.

A semantic information unit that can be identified by an identifier "light-f - ie light input - has a property relationship 26, which applies between the first overview node 20 and the light switch model 11.

A semantic information unit that can be identified by a "chilled ceiling" identifier has a property relationship 27, which is applied between the first overview node 20 and the air conditioning register model 12.

A semantic information unit that can be identified by a "light-o" identifier - ie light output - has a property relationship 28, which is applied between the first overview node 20 and the lighting element model 13 .

A semantic information unit that can be identified by an identifier " radiator " has a property relationship 29 that applies between the first overview node 20 and the air conditioning register model 14.

Finally, a semantic information unit that can be identified by a "blind" identifier has its property relationship 9, which is applied between the first overview node 20 and the blind drive model 15.

An overview of an automation functionality designated "HVAC" - ie heating, ventilation and air conditioning, is stored in the second overview node 30. The second overview node 30 is a building automation system object and has an overview list 31 for storing units 31.1 to 31.4 of semantic information (also referred to as a list of view node items).

A semantic information unit 31.1 that can be identified by an identifier "SS" - that is, state - has a property relationship 33, which is applied between the second overview node 30 and a first variable 35 advantageously implemented as an object, in which, for example, current information about the operating status of the "HVAC" automation functionality can be stored.

A semantic information unit 31.2 that can be identified by an identifier "Ts" - that is, temperature set point value - has a property relationship 34, which is applied between the second viewing node 30 general and a second variable 36 advantageously implemented as an object, in which for example the temperature set point value "Ts" applicable for the automation functionality "HVAC" can be stored.

A semantic information unit 31.3 that can be identified by an identifier "chilled ceiling " has a contact relationship 38, which is applied between the second overview node 30 and the air conditioning register model 12.

A semantic information unit that can be identified by an identifier " radiato r" has a contact relationship 39, which is applied between the second overview node 30 and the heating register pattern 14.

The second overview node 30 has an additional property relationship 37, which applies between the second overview node 30 and an open loop and / or closed loop control program 32. The automation function required for the heating, ventilation and air conditioning of the building section is programmed in program 32 for open loop and / or closed loop control. The open loop and / or closed loop control program 32, the second overview node 30, and additional objects 35 and 36, linked by property relationships to the overview node 30, form a functional unit through the said ownership relationship. Through the option of action of the available relationships, access for reading and writing data is made possible between the open loop and / or closed loop control program 32 on the one hand and the objects connected through relationships with the node. Overview 30 on the other hand indirectly via overview node 30. The described structure of the functional unit makes it possible for the field devices to be incorporated into and replaced in the building automation system without the program code in the open loop and / or closed loop control program 32 in question having to be adapted for this purpose.

An overview of an automation functionality designated by "light-ctrl" - ie light control - is stored in the third overview node 40. The third overview node 40 is a building automation system object and has an overview list 41 for storing units 41.1 to 41.4 of semantic information.

A semantic information unit 41.1 that can be identified by a "light-i" identifier - ie light input - has a contact relationship 38, which is applied between the third overview node 40 and the switch model 11. light.

A semantic information unit 41.2 that can be identified by a "light-o" identifier - that is, light output - has a contact relationship 39, which is applied between the third overview node 40 and the model element 13. illumination.

The third overview node 40 has a property relationship 47, which is applied between the third overview node 40 and an open loop and / or closed loop control program 42. The automation function required for light control in the assigned building section is programmed in program 42 for open loop and / or closed loop control. The open loop and / or closed loop control program 42 and the third overview node 40 form a functional unit through said ownership relationship 47. The opportunity of the available relationships to have an effect makes it possible to access data read and write, between the open loop and / or closed loop control program 42 on the one hand and the objects connected through relationships with the third node 40 overview on the other hand, indirectly through overview node 40. The described structure of the functional unit makes it possible to include and replace field devices in the building automation system, without the program code in the open loop and / or closed loop control program 42 in question having to be adapted for this purpose.

The semantic information units stored in the overview list 21, 31 or 41 can be advantageously identified through predefined or standardized designations. This allows operator views, for a building automation system management system or control center for example, to be generated in a user-friendly way and with relatively little effort. By using predefined designations by means of the string data type for the semantic information units a currently installed building automation system can be documented with relatively little effort.

In a variant embodiment of the overview node 20, 30 or 40, the overview list 21, 31 or 41 is ordered or classified according to certain rules.

Advantageously the device models will be provided with a designation that can be evaluated in generating or verifying a relationship. If for example, as shown in figure 1, the semantic information unit 21.9 of overview list 21 1 assigned to room 1 is identified by the character string "blind" and also the corresponding blind drive model 15 is marked with the same identifier, the generation or verification of the property relation 9 will be simplified and can be automated.

By using a markup with the data type string or string in a device model, an automatic binding of the device model to the associated function unit is made possible through the corresponding overview node without the code of program has to be modified in the assigned open-loop or closed-loop control program.

According to the building structure the building sections to be operated by the building automation system are typically divided into rooms with - under some circumstances - very different requirements, or by a grid with grid elements with similar requirements or identical. Overview nodes are advantageously used in the advantageous modeling of enclosures and grid elements. The grid elements are typically produced by an arrangement of support structures or window structures in the building section. Flexible building modeling is achieved through the use of two different types of overview nodes, a first type for an enclosure and a second type for grid elements. Overview nodes of the type designed for an enclosure are typically labeled "RM", ie enclosure, in the drawing, overview nodes of the type designed for grating elements are labeled "GD", that is to say grating or enclosure element. rack. The overview node 20 shown in FIG. 1 for enclosure 1 is therefore of the "RM" type. Overview nodes of type "GD" can be dynamically linked to an overview node of type "RM".

In Figure 2 a building section divided into the grid is labeled 60, having a first grid element 62 and a second grid element 61. The grid structure of the building section 60 is provided here by support structures 63 for example. The devices assigned to the two grid elements 62 and 61 are here reduced to a minimum for the sake of simplicity, since only the principle of advantageous modeling is to be presented. The louver element 62 or 61 thus comprises an enclosure unit 65 or 64, a heating register 69 or 68, and a louver drive 67 or 66.

The devices that operate the grid element 62 or 61 are advantageously modeled in the software of the building automation system as necessary and the corresponding models are advantageously implemented using an object-oriented approach. Models are typically connected via input / output modules to field devices. For example enclosure unit 65 or 64 will be mapped by enclosure unit model 85 or 95 respectively and blind drive 67 or 66 by blind drive model 86 or 96 respectively in the building automation system.

A fourth overview node (which is referred to as a parent view node object) 70 of the "RM" type, ie enclosure, describes the building section 60 comprising the two grid elements 62 or 61 respectively. The fourth overview node 70 has an overview list 71 for storing units 71.1, 71.2, 71.3 and 71.4 of semantic information that can be logically linked to one or more child view node objects (such as objects 80, 90 child view node). A semantic information unit 71.2 that can be identified by the identifier "HVAC" - ie heating, ventilation and air conditioning - has a 75 ownership relationship, which is between the fourth overview node 70 and a functional unit is not shown in the diagram, through which for example the functionality of heating, ventilation and air conditioning is guaranteed to the entire building section. Additionally the overview list 71 comprises a semantic unit 71.3 that can be identified with the identifier "bld-A-1" and a semantic unit 71.4 that can be identified with the identifier "bld-A-2".

A current grid division of the building section 60 is stored by means of semantic information units of the overview list 71. The semantic information unit 71.3 has a contact relationship 73 that is applied between the fourth overview node 70 describing the building section 60 and a fifth overview node 80. The semantic information unit 71.4 has a contact relationship 74 that is applied between the fourth overview node 70 and a sixth overview node 90.

The fifth overview node 80 and the sixth overview node 90 of the "GD" type, ie grating or grating element. According to the first overview node 20 in Figure 1, which describes all of the automation functions available specifically for enclosure 1, all of the automation functions available specifically for the first grid element 62 are listed under the fifth overview node 80, and all of the automation functions available specifically for the second grid element 61 in the sixth overview node 90. The semantic information related to the first grid element 62 is stored in the overview list 81 in the fifth overview node 89. The corresponding semantic information related to the second grid element 61 is stored in the overview list 91 in the sixth overview node 90.

The structure and method of operation that are made possible by the overview nodes (also referred to as the view node objects), overview lists (also referred to as the view node item list), relationships, and units Functional functions in particular produce at least the following advantages in the design, commissioning and maintenance phases: nodes can be copied during design, relationships can be verified with the help of suitable identifiers using a design tool or in time run automatically; and field devices, grids and scope of available functionality of building sections can be changed without having to make modifications to the program code of open loop and / or closed loop control programs since closed loop control programs and / or open loop access field devices directly through the overview nodes.

Figure 3 illustrates a functional block diagram of a plurality of building automation devices 304a-304c that together implement the building automation model 302 together forming the system 300. The building automation devices 304a-304c include one or more node 310-316 objects view devices that collectively comprise a collection of view node objects 308 within each building automation device 304a-304c. As also illustrated in Figure 3, some objects are illustrated as binary output objects (for example 310) and some are illustrated as binary input objects (for example 312 314) such that the object provides a binary output or receives binary input, respectively from a respective field device or sub-controller of a respective field device (not illustrated in Figure 3). Other types of inputs and outputs are contemplated, including but not limited to, analog inputs and outputs, multi-state inputs and outputs, value objects, and any combination thereof from a respective field device or sub-controller of a respective field device. .

Each view node object 310-316 includes at least one object-name 310a-316a that designates the view node objects 310 316 within the respective building automation device 304a-304c. Thus, the namespace of object-name 310-316 encompasses a single automation device 304a-304c. The building automation model 302 does not enforce any fixed syntactic or semantic naming scheme, predefined in object-name 310a-316a. However, a hierarchical or free naming convention can be applied to automatically configure object-names during design.

Each building automation device 304a-304c also features a device-name 306a-306c that uniquely designates the building automation device 304a-304c within the complete building automation model 302. Thus, the 306a-306c device-name namespace 308 encompasses the entire building automation model 302. No fixed, predefined syntactic or semantic naming scheme is imposed on a 306a-306c device-name. However, a hierarchical or free naming convention can be applied to automatically configure device-names 306a-306c during design.

For example, the view node object 304 illustrates a technical naming designation where the object name follows some predefined technical scheme. The view node object 304b illustrates a user designation naming criteria, where the naming scheme is decided by a user often on a whim. The view node object 304c illustrates a free designation naming scheme where the object name can be anything such that it does not meet any established criteria or scheme. As you can see, object-names 310a-316a can be used to refer to view node objects 310-316. However, the integrity of object-names 310a-310c of view node objects 310-316 as a reference may not be ensured because: (1) an object-name can be modified by design functions; (2) an object name can be configured as a standardized technical designation or as a project-specific user designation; or (3) a user designation such as an object-name can be configured at a later project phase or even by the end customer. Thus, by not having the system configured to automatically naming objects, errors such as duplications, incorrect naming format, or other problems can occur.

FIG. 4 further illustrates a functional block diagram of a plurality of building automation devices 304a-304c that together implement the building automation model 302, together forming the system 300 illustrated in FIG. 3.

Referring to FIG. 4, each view node object 310-316 has an object-identifier 310b-316b that uniquely identifies view node object 310-316 within the building automation device 304a-304c. Each building automation device 304a-304c also features a device-identifier 406a-406c that uniquely identifies the building automation device 304a-304c within the building automation model 302.

Object-identifiers 310b-316b and device-identifiers 406a-406c can be used to refer to a building automation device 304a-304c. The integrity of each of the object identifiers 310b-316b and device identifiers 406a-406c references will be ensured, since these identifiers may not be modified by design functions as illustrated in Figures 5-7 as they can be used. in a design tool 1400 (illustrated in figure 4) to initially configure or commission the building automation devices and object identifiers for the view node objects 310-316 to be used in each automation device of buildings. Consequently, design functions will assign a standardized technical designation to object-name 310a-310c. To designate the view node object, the technical designation will be derived from the standardized design representation of the technical view. Depending on design conventions, the applied namespace of technical designations can either encompass one or more building automation devices (local namespace) or the entire building automation model (global namespace). However, within the system, the assigned object-name will be treated as a separate technical view from the user-specified view and the namespace as local.

For example, as described in this document, a building automation device and / or building automation model may include processing circuitry / logic configured to access and execute a control program that is stored in memory (such as random access memory, cache memory, or other volatile memory storage device or computer-readable medium) or secondary storage (such as read-only memory, non-volatile flash memory, hard disk, memory stick, or other storage device). non-volatile memory storage or computer-readable medium). The control program can be a separate program or a program module of the building automation device. The control program can include an operating system (such as Linux or other conventional operating system). The control program instructs and interacts with a hierarchy of objects representing building automation objects throughout the building automation model represented as a plurality of view node objects configured in a hierarchical structure, such as one or more parents view node object number and one or more view node object children, to assign a name to the object. Accordingly, the control program can iterate through the one or more parent view node objects and the one or more child view node objects logically linked to the one or more parent view node objects and read and / or write. data within any object such that it communicates with one or more field devices (including but not limited to sensors and actuators) logically linked to the one or more child view node objects.

Figure 5 illustrates a hierarchical nomenclature structure 500 of a building automation model 502 that includes a field device that corresponds to an air handling unit represented by the view node object 504. The building automation model 502 includes a plurality of view node objects 504-518, similar to those illustrated in Figures 3-4. The hierarchical system forms a logical tree of parentchild nodes in such a way that each child is logically linked to its parent forming a logically linked list. Therefore, by iterating from the parent node, each of the children, grandchildren, and so on can be discovered.

As illustrated in Figure 5, view node objects 504-518 are arranged in a hierarchy such that view node object 504 is a view node object parent 506, which is a parent of objects. View node object 508-512, wherein view node object 512 is the parent of view node objects 514-518. Accordingly, view node objects 514-518 are children of view node object 512, which is a child of view node object 506, which is a child of view node object 504. In the example illustrated in Figure 5, object 514 is a pump field device binary output object identified by view node object 512 having the object-name of AHU1.Hcl.Pu such that it provides output data in binary format, and objects 516-518 are binary input objects such that they accept binary data. Other types of inputs and outputs are contemplated, including but not limited to, analog inputs and outputs, multi-state inputs and outputs, value objects, and any combination thereof from a respective field device or sub-controller of a field device. respective. The last one or more children in the hierarchical chain are logically linked to a field device such that data mapped to the field device, including data to operate the field device, can be read or written to it.

As you can see, the object name of each child view node object has been appended to it, the appended object name of its parent, which together comprise a string that represents the name of the field device to which it is logically linked. For example, view node object 506 has an object-name of AHU1.Hcl, where AHU1 is the name of the parent view node object 504 of the child view node object 506. AHU1 designates the field device air handling unit 1; Hcl designates the preheat coil. The view node object 514 has an object-name composed of its name, the object-name of its parent view node object 512 (comprising the object-name of its parent 506 and the object-name of its parent 504). The individual portion of a name that represents a specific object may follow a naming scheme, including but not limited to: AHU1 designating air handling unit 1; Hcl which designates preheating coil; PU that designates pump; Cmd that designates command; FrPrt which designates frost protection air temperature; Vlv which designates valve; Fb that designates feedback; ThOvrld which designates thermal overload; SuB designating supply air box; R1 designates room control 1; MntSwi which designates maintenance switch; RC that designates room control; OccSens that designates occupancy sensor; HVAC designates an HVAC device; Other object names are contemplated and are not limited to the example names illustrated in this document. Accordingly, the view node object 514 object-name is AHU1.Hcl.Pu.Cmd where AHU1 designates the air handling unit 1 (eg view node object 504); Hcl designates preheating coil (eg view node object 506); Pu designates pump (eg view node object 512), and Cmd designates command (eg view node object 514). Similar naming formats are contemplated. For example, AHU1.Hcl.Pu.MntSwi can designate: air handling unit 1 / preheating coil / pump / maintenance switch. R1.HVAC.SuB.Cmd can designate: Enclosure 1 / HVAC Control / Supply Air Box / Command Supply Air. Furthermore, although an air handling unit is illustrated herein, other devices are contemplated throughout the embodiments, including but not limited to other objects and functionalities, including but not limited to, lighting, shading, HVAC functions, and combinations thereof.

Figure 6 illustrates another hierarchical nomenclature structure 600 of the building automation model 602 having a room control with a variable air volume ("VAV") system logically linked to one or more field devices. The view node object 604, which represents a venue control device, is the parent object of the view node object 606, which represents an occupancy sensor, and the view node object 608, which represents a view device. HVAC, is the parent of view node object 610, representing a supply air box device, which is the parent of view node object 612, representing field device command supply air object . As illustrated in FIG. 6, the child view node object 612 has an object name comprised of its parent hierarchical tree structure.

FIG. 7 illustrates another hierarchical nomenclature structure 700 of the building automation model 702 wherein the view node object 718 represents an air handling unit building automation device. A project may require dedicated structured user appointments specified by the customer. Typically, such user designations include structured geographic and / or functional information to identify and nomenclature view node objects. For example, in some locations, such as European countries, customers may apply a naming scheme based on DIN 6779-12 standards in relation to DIN 6779-1, DIN EN 61346-1 and DIN EN 61346-2, which standardize functional, product-oriented, and geographic designators for technical objects, and documentation in the area of construction and technical building infrastructure.

If user designations are applied to naming view node objects, design functions will configure a hierarchical structured naming scheme and derive user designations to naming those view node objects that require a user designation project specific. Depending on design conventions, the applied namespace of user names can either span a building automation device (local namespace) or the entire building automation model (global namespace). However, the view node objects that represent the standardized technical view can retain their technical designations. Additionally, user appointments can be configured at a later project phase or even by the end customer. However, within such a system, the assigned object-name will be considered as the technical view independent of the user-specified view and the namespace as local.

For example, as illustrated in FIG. 7, the building automation model 702 includes a plurality of view node objects 704-718 arranged in a hierarchical tree structure. Object 712 is named Bld3.Floor2.Pump which designates: building 3 / floor 2 / pump. Other naming schemes are contemplated, such as the name + 46.U1.L16.02-TL001.G01; E01 which can designate: building 46 / floor U1 / geographic sweep L16 / enclosure 2 / air conditioning plant 001 / supply fan 1 / binary command 1 / according to DIN 6779-12, DIN 6779-1, DIN EN 61346- 1 and DIN EN 61346-2. A similar structure can be formed for other devices, such as the VAV and room control which is the parent object.

Figure 8 illustrates another hierarchical nomenclature structure 800 of the building automation model 802 wherein the view node object 804 represents a building, the view node object 806 represents an air handling unit, and the view node object 808 represents a view node represents a sandbox control. View node objects 810, 811, representing floor objects, are children of view node object 804. View node object 812, representing a preheat coil, is a child of view node object 806. View node object 814 representing an HVAC device is a child of view node object 808. Each of the 810-814 objects is logically linked to the 816-828 objects and their children 830-832 objects. As illustrated in Figure 8, the hierarchically defined naming scheme of user designations can be mapped during design to view node objects to provide a customized user view to the customer as an addition to the standardized technical view. Such a project-specific user view may be independent of the technical view and would enable the user to navigate according to user designations. Accordingly, as illustrated in Figure 8, the user would see a customer customized view of a room controlled air handling unit with a VAV system. Other configurations are contemplated.

Figure 9 illustrates a method of inserting and naming building automation objects to form a building automation model 900 that can be implemented using a design tool that can be used to configure and commission a building automation model to implementation in building automation devices as illustrated. At block 902 the method starts. At block 904, a parent building automation object, such as a parent view node object, is defined and assigned an object-name, such as one representing a building automation device. At block 906 it is determined whether the child building automation objects need to be entered into the building automation model. If so, the process continues at block 908; if not, the process continues to block 912. If so, the process continues to block 908 where a child building automation object is inserted into the building model and is logically linked to the parent. In block 910, the object-name of the parent building object is appended to the name of the child building automation object that represents a field device to which it is logically linked, forming a child object-name. The process then returns to block 906 to determine if there are additional children. If not, the process continues to block 912 where it ends.

Figure 10 illustrates the partition of the object name and possible optional and mandatory entries to construct an object name. The naming construct 1000 is a graphical representation made of the example construct expressed as: Object-Name = [Delimiter] [(External-Structure | Part-Name-Prefix)] Object-Part-Name [User-Defined-Extension ]. The example nomenclature construct 1000 is expressed in Backus-Naur Extended Form (EBNF) such that the brackets ([]) illustrate that the item is optional, and the parentheses ({}) indicate one or more (as in the case of {character} expressing a string). As illustrated in Figure 10, the dotted boxes illustrate that the item is optional, while the solid line boxes indicate that the item is not optional. Therefore, Prefix Delimiter 1002, External Structure 1004, Delimiter 1006, Prefix Part Name 1008, Delimiter 1010, Extension Delimiter 1022, and User Defined Extension 1024 are optional, while Object Part Name 1016 is not. it is.

The Prefix Part Name 1008 may comprise the Grandparent-Object-Name 1012 (eg, the object name of the parent of the object's parent thereby omitting the name of the immediate parent of the object); the Parent-Object-Name 1014 (thus reusing the parent's name) or no party name at all.

The Object Part Name 1016 may comprise the Alias-Name 1018 (eg a user-defined name representing the part) or the Part-Name 1020 if there is no defined alias name.

As long as there is more than one object that has the same 1016 Object Part Name, an optional Extension 1022 Delimiter and User Defined Extension 1024 can be added (for example to represent that the object is one of two or more ).

Additionally, as illustrated herein, the example nomenclature construct 1000 is defined such that:

Delimiter = character (* dedicated character, not used in names *);

Outer-Structure = {character} [Delimiter {character}] Delimiter;

Prefix-Part-Name = (Parent-Object-Name | Grandfather-Object-Name) Delimiter;

Parent-Object-Name = Object-Name (* parent object is defined by property relation *);

Name-Part-Object = Name-Part | Name-Alias;

User-Defined-Extension = Delimiter {character};

The character used as a delimiter is preferably one that is not used in any portion of the name. For example, as illustrated in Figure 8, the delimiter is a period. Other characters are contemplated.

Figure 11 illustrates the part field delimiters and part field length rules for constructing an object name. Level 1 is the highest level in the object hierarchy, typically representing a building level, but other representations are contemplated. Levels 2 through N are intermediate levels, and level N + 1 is the lowest child object. For example, Level 1 can represent a building, Level 2 can represent a floor in the building, Level 3 can represent an enclosure (or grid or segment), Level 4 can represent a function or application device, and Level 5 can represent an analog input or output object (or other types, including but not limited to binary inputs or outputs, multi-state inputs and outputs, value objects, and any combination thereof from a respective field device or subcontroller of a respective field device).

As illustrated in Figure 11, each level can include a delimiter that is the same as or different from any other delimiter. Thus, the delimiters used in the optional Outer Structure 1104 construct may be the same as or different from the delimiter used in the optional Prefix 1102 Delimiter, which may be the same or different from the delimiter used in the optional Part Name 1106 construct. Prefix, which can be the same or different from the extension delimiter used in the optional 1110 User Defined Extension construct. Therefore, a delimiter that separates the optional Prefix Part Name construct 1106 from the required Object Part Name 1108 may be a period, while another delimiter used elsewhere may be a $.

As long as there is more than one object that has the same 1108 Object Part Name and connected to the same parent object (through a property relationship), an optional User Defined 1110 Construct can be added (for example for represent that the object is one of two or more).

The naming construct 1100 also includes fields of variable length that can be defined by the operator. For example, as illustrated in FIG. 11, Object Part Name 1108 is illustrated with a defined length set because the maximum length equals the minimum length. However, the Prefix Part Name must have a certain minimum length but cannot be longer than the maximum length.

For example, Figure 12 illustrates a design tool graphical user interface system 1200 that can be used to configure and commission a building automation model for implementation in building automation devices as illustrated. The graphical user interface system or design tool 1200 is operatively configured to define and implement naming rules, such as the naming constructs illustrated in Figures 10-11. Referring to Figure 12, the graphical user interface 1200 includes the Use Parent Name check box 1202 where a user can check the box if the user wants the object name to include the parent's name, forming this mode a hierarchy of nomenclature. The user can also enter the total length 1204 of the naming construct name. The user can enter which prefix delimiter 1208 is to be used to naming objects. The user can also enter a series of delimiters, minimum length, and maximum length for each level 1208 of the naming construct. After establishing the nomenclature construction criteria, the system automatically applies the naming criteria to a hierarchy of objects, such as the one illustrated in Figure 13.

Figure 13 illustrating graphical user interface system 1300 having naming rules applied. The graphical user interface system 1300 includes a table 1302 of objects that includes in columns from left to right, the object type, part name, object name constructed using the method and system illustrated in Figures 10-12, and a user-defined description; Other column types and configurations are contemplated.

As can be seen in the fourth row of table 1302, using the criteria defined in figure 12, the system generated a nomenclature of switch 1 that resides in building 1, floor 1, room 1, zone UP286, which has the name from 3 $ Swi1. If the user wants to use the alias name instead as illustrated in figure 10, the user can type the alias name in the naming properties box 1306 illustrated in figure 13. If the user wants to have different rules of Naming for a single object, in addition to the default rules of the project setting (as illustrated in Figure 12), the user can select another option 1308, such as reuse the parent, omit the parent, or add a new root. Other naming constructs and graphical user interfaces are contemplated.

An advantageous embodiment of the invention is a computer-readable storage medium that has stored in it data representing instructions executable by a processor programmed to iterate through a hierarchical structure representing one or more devices (304a, 304b, 304c). automation system and one or more field devices, the storage medium comprising instructions for:

accessing a parent view node object (20, 70, 504, 512);

access a child view node object (30, 80, 90, 506, 612);

logically bind the child view node object to the parent view node object (20, 70, 504, 512);

assigning an object-name (310a-316a) to the parent view node object (20, 70, 504, 512); and

assign an object-name (310a-316a) to the child view node object (30, 80, 90, 506, 612) that represents a field device logically linked to the object (30, 80, 90, 506, 612) of child view node.

An advantageous embodiment for a computer-readable storage medium is that the assignment of an object-name (310a-316a) to the parent view node object (20, 70, 504, 512) and the assignment of an object-name (310a- 316a) to the child view node object (30, 80, 90, 506, 612) further comprises an object-name construct comprising [Delimiter] [(External-Structure | Part-Prefix-Name)] Part-Name- [User-Defined-Extension] object.

An advantageous embodiment for a computer-readable storage medium is that the computer-readable storage medium further comprises instructions to iterate through the parent view node object (20, 70, 504, 512) and the object (30, 80 , 90, 506, 612) of the child view node and read data stored in it.

An advantageous embodiment for a computer-readable storage medium is that the computer-readable storage medium further comprises instructions for rendering a graphical user interface for defining a nomenclature construct.

An advantageous embodiment for a computer-readable storage medium is that the field device is a sensor or actuator.

The methods, processes, and systems illustrated in this document and equivalents thereof provide numerous benefits including, but not limited to, support for a uniform nomenclature and address system that globally harmonizes and standardizes a uniform nomenclature and address concept for all building automation objects that reduces errors and improves efficiency in modeling a building automation system. There are numerous other benefits.

Those skilled in the art will appreciate that embodiments not expressly illustrated herein may be practiced within the scope of the present invention, including that features described herein for different embodiments may be combined with each other and / or with currently known technologies. or developed in the future while remaining within the scope of the claims made herein. Therefore, the above detailed description is intended to be considered illustrative rather than limiting. It is understood that the following claims, including all equivalents, are intended to define the scope of this invention. Additionally, the advantages described above are not necessarily the only advantages of the invention, and it is not necessarily expected that all the advantages described will be achieved with each embodiment of the invention.

Claims (16)

1. A method of design and nomenclature of building automation devices (304a, 304b, 304c) and field devices of a building automation system by automatically naming a plurality of building automation objects of a model (302 , 502, 602, 702, 802, 900) of building automation of the building automation system, comprising the method: providing a building automation device (304a, 304b, 304c); provide a building automation model (302, 502, 602, 702, 802, 900) comprising a parent view node object (20, 70, 504, 512) representing the device (304a, 304b, 304c) of building automation and a child view node object (30, 80, 90, 506, 612) logically linked to a field device, where the child view node object (30, 80, 90, 506, 612) it is logically linked to the parent view node object (20, 70, 504, 512) forming a hierarchical structure; assigning an object-name (310a-316a) to the parent view node object (20, 70, 504, 512) representing a name of the building automation device (304a, 304b, 304c); and assign an object-name (310a-316a) to the child view node object (30, 80, 90, 506, 612) comprising the object name (310a-316a) of the node object (20, 70, 504, 512) parent view and a name that represents the field device, where the hierarchical structure is formed by a logical tree of one or more nodes of parent-child-grandchild in such a way that each child is logically linked to a corresponding parent and each grandchild is logically linked to a corresponding child, forming a linked list logically, where a control program instructs and interacts with the building automation model object hierarchy to name the objects, wherein the control program iterates through the one or more parent view node objects and the one or more child view node objects logically linked to the one or more parent view node objects and reading and / or writing data within of any of the objects in such a way that it communicates with one or more field devices logically linked to one or more child view node objects. The method of claim 1, wherein assigning the object-name (310a-316a) to the parent view node (20, 70, 504, 512) and assigning the object-name (310a-316a) to the node (30, 80, 90, 506, 612) of child view comprises forming each of the object-name (310a-316a) as a construction defined as [Delimiter] [(External-Structure | Name-Part-Prefix)] Name- Part-Object [User-Defined-Extension]. The method of claim 2, wherein the Object-Part-Name is constructed from an alias-name or a part-name. The method of claim 2, wherein the Name-Part-Prefix is constructed from a grandparent name or a parent-object-name. The method of claim 1, wherein the field device comprises a sensor or an actuator. The method of claim 1, wherein the child view node object (30, 80, 90, 506, 612) comprises a plurality of child view node objects (30, 80, 90, 506, 612) , wherein each of the plurality of child view node objects (30, 80, 90, 506, 612) is logically linked to a field device and to the view node object (20, 70, 504, 512) progenitor. The method of claim 6, further comprising iterating through the parent view node object (20, 70, 504, 512) and each of the plurality of objects (30, 80, 90, 506, 612) child view node and read data stored within each of the plurality of child view node objects (30, 80, 90, 506, 612). The method of claim 6, further comprising iterating through the parent view node object (20, 70, 504, 512) and each of the plurality of objects (30, 80, 90, 506, 612) child view node and write data stored within each of the plurality of child view node objects (30, 80, 90, 506, 612). The method of claim 6, further comprising assigning an object-name (310a-316a) to each of the plurality of child view node objects (30, 80, 90, 506, 612) each as one construct defined as [Delimiter] [(External-Structure | Prefix-Part-Name)] Object-Part-Name [User-Defined-Extension]. 10. A design system for designing and naming building automation devices (304a, 304b, 304c) and field devices of a building automation system, the design system configured to automatically naming a plurality of objects building automation of a model (302, 502, 602, 702, 802, 900) of building automation of the building automation system and to represent a hierarchical structure representing one or more building automation devices (304a, 304b, 304c) and one or more field devices, the design system comprising: a parent view node object (20, 70, 504, 512) representing a building automation device (304a, 304b, 304c) and logically linked to a plurality of objects (30, 80, 90, 506, 612) child view node, wherein each of the plurality of child view node objects (30, 80, 90, 506, 612) is logically linked to a field device; wherein the parent view node object (20, 70, 504, 512) comprises an object-name (310a-316a), and wherein each of the plurality of child view node objects (30, 80, 90, 506, 612) comprises an object name (310a-316a) of the parent view node object (20, 70, 504, 512) and a name representing the field device to which each of the plurality of child view node objects (30, 80, 90, 506, 612) is logically linked, where the hierarchical structure is formed by a logical tree of one or more nodes of parent-child-grandchild in such a way that each child is logically linked to a corresponding parent and each grandchild is logically linked to a corresponding child, forming a linked list logically, where a control program is adapted to instruct and interact with the hierarchy of objects of the building automation model to assign a name to the objects, wherein the control program is adapted to iterate through the one or more parent view node objects and the one or more child view node objects logically linked to one or more parent view node objects and read and / or write data within any of the objects in such a way that it communicates with one or more field devices logically linked to the one or more child view node objects. The system of claim 10, wherein the system further comprises a graphical user interface for defining a nomenclature construct for the parent view node object (20, 70, 504, 512) and the plurality of objects (30 , 80, 90, 506, 612) of child view node. The system of claim 11, wherein the nomenclature construct is defined as object-name = [Delimiter] [(External-Structure | Part-Name-Prefix)] Object-Part-Name [User-Defined-Extension ]. The system of claim 12, wherein the Object-Part-Name is constructed from an alias-name or a part-name. The system of claim 12, wherein the Name-Part-Prefix is constructed from a grandparent name or a parent-object-name. 15. A computer-readable storage medium that has stored in it data representing executable instructions by a processor programmed to iterate through a hierarchical structure representing one or more building automation devices (304a, 304b, 304c) and one or more field devices of a building automation system, and for automatically naming a plurality of building automation objects of a building automation model of the building automation system, the storage medium comprising instructions for: accessing a parent view node object (20, 70, 504, 512); access a child view node object (30, 80, 90, 506, 612); logically bind the child view node object to the parent view node object (20, 70, 504, 512); assigning an object-name (310a-316a) to the parent view node object (20, 70, 504, 512); and assign an object-name (310a-316a) to the child view node object (30, 80, 90, 506, 612) comprising the object name (310a-316a) of the node object (20, 70, 504, 512) view parent and a name representing a field device logically linked to the child view node object (30, 80, 90, 506, 612), where the hierarchical structure is formed by a logical tree of one or more nodes of parent-child-grandchild in such a way that each child is logically linked to a corresponding parent and each grandchild is logically linked to a corresponding child, forming a linked list logically, where a control program instructs and interacts with the building automation model object hierarchy to name the objects, wherein the control program iterates through the one or more parent view node objects and the one or more child view node objects logically linked to the one or more parent view node objects and read and / or write data within any of the objects in such a way that it communicates with one or more field devices logically linked to the one or more child view node objects. 16. The computer-readable storage medium of claim 15, wherein the storage medium further comprises instructions for rendering a graphical user interface for defining a nomenclature construct.