Johnson Service Company

Johnson Controls Technology Company

David E Rasmussen

Karen L Woest

James K Stark

Donald A Gottschalk

Michael E Wagner

Jeffrey J Gloudeman

Clay G Nesler

Gaylon M Decious

Robert R Singers

Gregory A Pascucci

Darrell E Standish

David L Koch

Otto M Mageland

Dan J Spacek

Paul W Madaus

Dennis E Burkhardt

Donald A Gottschalk, Jr

Vairavan Vairavan

Susan M Hyzer

James R Garbe

Barrett G Wainscott, Jr

Gregory B Cebasek

Anne M Kumor

Kirk H Drees

Radu M Dorneanu

Beth A Ray

Jeffrey Taylor

David S Eidson

Diana St John

C Richard Kraemer

Nicholas J Ruppert

Vairavan E Vairavan

A system for filtering items to be displayed on a graphical user interface provided to a client and for interaction by a user, the graphical user interface for a building automation system, is provided. The system includes a processor and memory communicably coupled to the processor. The memory includes computer code for allowing the user to create a filter definition via a computer based form. The memory further includes computer code for saving the created filter definition to memory and computer code for applying the saved filter definition to a set of building automation system data items. The memory yet further includes computer code for generating the graphical user interface, the graphical user interface including results of the applied filter definition.

System and method for filter creation and use for building automation systems

A building automation control system for use in a building having an IT network includes at least one BAS controller connected to the IT network and at least one BAS device located within the building and connected to the at least one BAS controller through the IT network. Further the system may be configured to use standards-based IT technologies over the IT network to manage the at least one BAS device. The standards-based IT technologies may include DHCP to obtain IP addresses and network parameters of the BAS devices, DNS to provide a mechanism for associating the BAS devices with human-friendly names, a distributed mechanism for storing the names, and a method for locating the BAS devices by resolving names and IP addresses, SNTP to synchronize time on the BAS devices, SNMP to monitor the BAS devices and report alarms, SMTP for delivery of e-mail alarms, web-services to provide Internet-friendly communications, and standards-based IT security mechanisms to protect software of the BAS devices.

Building automation system devices

A building automation control system for use in a building having an IT network is disclosed. The building automation control system includes at least one BAS controller connected to the IT network and at least one BAS device located within the building and connected to the at least one BAS controller through the IT network. Further the system may be configured to use standards-based IT technologies over the IT network to manage the at least one BAS device. The standards-based IT technologies may include DHCP to obtain IP addresses and network parameters of the BAS devices, DNS to provide a mechanism for associating the BAS devices with human-friendly names, a distributed mechanism for storing the names, and a method for locating the BAS devices by resolving names and IP addresses, SNTP to synchronize time on the BAS devices, SNMP to monitor the BAS devices and report alarms, SMTP for delivery of e-mail alarms, web-services to provide Internet-friendly communications, and standards-based IT security mechanisms to protect software of the BAS devices.

A computer-implemented building automation operating system for supporting applications that interact with building automation devices in different locations. A computer-human interface is provided for viewing data related to the applications. A master name data structure stores global identifiers and location specific names for each of the applications that interact with the building automation devices. The global identifiers uniquely identify the applications. A building automation master name processor is connected to the master name data structure and to the computer-human interface for providing to the computer-human interface a location specific name based upon its associated global identifier. These features significantly enhance the global distribution and use of new building automation software applications.

Language independent building automation architecture for worldwide system deployment

A computer-implemented building automation system is provided with an asynchronous communication architecture for supporting object-oriented applications that interact with distributed building automation devices. Standard application objects which need to be informed of changes to the value of another object's attributes use a connection object to establish an asynchronous link between standard objects. A source object has a control attribute that changes based upon the execution of this object's control method which in turn is linked to a second control attribute of a destination object. By linking these attributes, a connection object is defined to manage information being passed between these two objects. Upon instantiation of the connection object, it registers the second control attribute with the source object to receive 'significant' changes in the value of its control attribute. A 'significant' change is defined by a change sensitivity property associated with the control attribute, such that a message containing the value of the control attribute is transmitted to the connection object when the change in the value of the control attribute exceeds the value of the change sensitivity property. The connection object in turn writes the attribute's value from the source object to the second control attribute of the destination object. Thus, execution of the connection object happens independently from the destination object. This communication architecture also implements a reliability data structure to improve asychronous communication when the building automation system is distributed across various building automation devices.

Distributed object-oriented building automation system with reliable

A computer-implemented building automation system is provided with an asynchronous object-oriented operating environment that is able to provide support for synchronous object execution with respect to real time, including those used to maintain closed-loop control over a system. The operating environment for supporting standard objects includes a clock mechanism for maintaining time and a scheduling mechanism for initiating the methods associated with the standard objects. A control method (i.e. PID control method) of a first standard object is scheduled for execution at a predefined schedule time with the schedule mechanism, and at some later time is initiated by the schedule mechanism. Upon execution, the control method determines an actual time of initiation by reading the clock mechanism and adjusts its control method using this actual time when the actual time exceeds the schedule time. More specifically, the actual time is determined by reading an elapsed time from the clock mechanism and computing a difference between this elapsed time and a start time that was determined by reading the clock mechanism at the time the control method was scheduled.

Asynchronous distributed-object building automation system with support

An object-oriented building automation system architecture allows complex building automation applications to be developed and deployed as distributed objects across a network. Applications are distributed in the form of objects that may in turn be made up of other application objects, assembly objects and standard objects. All objects are inherited from a superclass that defines a command component and a view component. The command component identifies those methods within the object that may be executed by other objects, and ultimately by the user through the user interface. The view component identifies the attributes or data stored in the object that may be displayed on the user interface. The view component encapsulates the information needed to display the object's data, so that the user interface can be a generic browser. The standard objects encapsulate physically-constrained properties or human comfort-constrained properties. Applications constructed from these objects can be revised and enhanced more easily because the embedded knowledge is preserved through encapsulation.

Common object architecture supporting application-centric building

A computer-implemented building automation system provides a computer software architecture that supports object-oriented system development. An application engineer designs an application to perform a building automation function that solves a problem or customer need in the context of a building automation system. In the object-oriented paradigm, standard objects are the fundamental building block used to construct an application. Based on predetermined physical relationships defined by physical laws associated with building automation functions, the present invention defines a fundamental set of control-based standard objects for constructing an application. An additional set of information-type standard objects have also been defined for use in conjunction with this set of control-based standard objects. Standard objects are interconnected by 'pulling' or 'pushing' information from one standard object to another standard object using common communication methods. Assembly objects and application objects are two additional types of user-defined standard objects for interconnecting standard objects, thereby constructing a building automation application.

Software components for a building automation system based on a standard

A networked system having a wide variety of applications and particularly applicable to facilities management systems has multiple levels of software in processing nodes. The levels include a 'features' processing level which communicates requests for data to a software object level containing databases of processes and attributes and database managers. The database managers in the software object level operate to provide data to the high level features in the same format. The software object level communicates with a hardware object level which also contains databases and database managers to mask differences between operational hardware units. By categorizing operational units by type, additional units of a known type can be added with only low level hardware object database changes. Adding units of a new type is facilitated by software changes confined to the lower level hardware and software objects, avoiding software changes at high level features. Individual software objects are tailored for typical types of inputs and output devices encountered by facilities management systems. Universal drive circuitry also provides applicability to a broad range of devices.

Networked facilities management system

A distributed computer-implemented building automation system for supporting applications that interact with building automation devices. The building automation system has a first device and a second device interconnected across a network channel. A common object superclass stored in a computer readable memory defines a plurality of common objects through instantiation such that the common objects have attributes for storing data and have methods for processing stored data. A source object residing on the first device performs a first control method such that a first attribute of the source object is changed. A destination object residing on the second device performs a second control method using the first attribute of the source object. A surrogate object connected between the source object and the destination object has a value for the first attribute and represents the source object on the second device. The second object has access to the value of the first attribute for performing the second method.

Communication system for distributed-object building automation system

The building automation application framework defines an object-oriented class hierarchy in which a standard object superclass defines a plurality of different standard objects that may be assembled by a system designer into larger and more complex building automation systems. The standard objects include a view component that handles implementation details of displaying that object's contents on a standardized or generic user interface browser. The standard object also includes a command component that identifies to other objects what methods may be invoked by that object, thereby relieving the system developer from attending to this programming detail. The application framework defines a building automation model that is application-centric, as opposed to device-centric. Applications are constructed by interconnecting standard objects, assemblies formed from standard objects, and other application objects.

Application framework for constructing building automation systems

A networked system having a wide variety of applications and particularly applicable to facilities management systems has multiple levels of software in processsing nodes. The levels include a 'features' processing level which communicates requests for data to a software object level containing databases of processes and attributes and database managers. The database managers in the software object level operate to provide data to the high level features in the same format. The software object level communicates with a hardware object level which also contains databases and database managers to mask differences between operational hardware units. By categorizing operational units by type, additional units of a known type can be added with only low level hardware object database changes. Adding units of a new type is facilitated by software changes confined to the lower level hardware and software objects, avoiding software changes at high level features. Individual software objects are tailored for typical types of inputs and output devices encountered by facilities management systems. Universal drive circuitry also provides applicability to a broad range of devices. Data is stored with an aging time such that during a time period when a data item is valid, requests for that particular data item are serviced with the stored data. A request for the particular data item which occurs after the data item aging time is serviced with a new value of the data which is again valid for the aging time.

Networked facilities management system with updated data based on aging

A networked system having a wide variety of applications and particularly applicable to facilities management systems has multiple levels of software in processing nodes. The levels include a 'features' processing level which communicates requests for data to a software object level containing databases of processes and attributes and database managers. The database managers in the software object level operate to provide data to the high level features in the same format. The software object level communicates with a hardware object level which also contains databases and database managers to mask differences between operational hardware units. By categorizing operational units by type, additional units of a known type can be added with only low level hardware object database changes. Adding units of a new type is facilitated by software changes confined to the lower level hardware and software objects, avoiding software changes at high level features. Individual software objects are tailored for typical types of inputs and output devices encountered by facilities management systems. Universal drive circuitry also provides applicability to a broad range of devices. Nodes store restoration characteristics of loads controlled by the nodes. After being shed to limit energy consumption, software local to the node restores the loads under predefined circumstances independently of the load shed commands to achieve distributed load management.

Networked facilities management system having a node configured with

A networked system having a wide variety of applications and particularly applicable to facilities management systems has multiple levels of software in processing nodes. The levels include a 'features' processing level which communicates requests for data to a software object level containing databases of processes and attributes and database managers. The database managers in the software object level operate to provide data to the high level features in the same format. The software object level communicates with a hardware object level which also contains databases and database managers to mask differences between operational hardware units. By categorizing operational units by type, additional units of a known type can be added with only low level hardware object database changes. Adding units of a new type is facilitated by software changes confined to the lower level hardware and software objects, avoiding software changes at high level features. Individual software objects are tailored for typical types of inputs and output devices encountered by facilities management systems. Universal drive circuitry also provides applicability to a broad range of devices. An optical isolator is connected between signal line outputs from a node and a line driver connected to a pair of lines on a bus. Similarly, an optical isolator is connected between signal line receiving inputs and a line receiver. The signal lines can be biased to predetermined levels to reduce node sensitivity to noise.

Networked facilities management system with optical coupling of local

A networked system having a wide variety of applications and particularly applicable to facilities management systems has multiple levels of software in processing nodes. The levels include a 'features' processing level which communicates requests for data to a software object level containing databases of processes and attributes and database managers. The database managers in the software object level operate to provide data to the high level features in the same format. The software object level communicates with a hardware object level which also contains databases and database managers to mask differences between operational hardware units. By categorizing operational units by type, additional units of a known type can be added with only low level hardware object database changes. Adding units of a new type is facilitated by software changes confined to the lower level hardware and software objects, avoiding software changes at high level features. Individual software objects are tailored for typical types of inputs and output devices encountered by facilities management systems. Universal drive circuitry also provides applicability to a broad range of devices. Nodes are provided with ports which may accommodate a non-configured device. When a non-configured device is identified on a port, a drop identifier specifying the port is transmitted to the non-configured device for use in establishing a network address by which the non-configured device can be accessed.

Growing community of inventors

Wales, WI, United States of America

David E Rasmussen