WO2011103652A1 - System and method for facility management and operational monitoring and control - Google Patents

Abstract

A system and method for management of facilities including operational monitoring and control, is provided, which is particularly applicable to building management systems for monitoring and control of energy usage in multi-unit and multi-tenant buildings. The system provides a multi-process communication environment for distributed independent applications. It is also is scalable and provides for management of energy consumption, or usage of other services or utilities with increased granularity, e.g. on a per unit, per tenant basis, and/or to provide for aggregation of data from multiple sites or facilities.

Description

SYSTEM AND METHOD FOR FACILITY MANAGEMENT AND OPERATIONAL MONITORING AND CONTROL

TECHNICAL FIELD

[0001] This invention relates to systems and methods for management of facilities, including operational monitoring and control, and more particularly to building management systems for monitoring and control of energy consumption and usage of other utilities and services. BACKGROUND

[0002] Most dwellings and commercial buildings are supplied with several different services or utilities for heating, cooling and lighting, for example, electricity ("hydro" in North America), oil, natural gas or other fuel, as well as water and other metered services. With increasing energy costs, awareness of environmental issues and need for energy conservation, various systems are now available for automating metering, monitoring and control of individual systems for lighting systems, and heating, ventilation, air conditioning (HVAC) systems, and other utilities and services. Home automation systems may provide an individual homeowner with some capability to manage multiple systems locally or remotely, using wired or wireless enabled networks. However, systems for coordinating usage of multiple systems in large scale commercial buildings, such as multi-unit and multi-tenant business facilities are typically very complex to manage, limited in capabilities, or costly to retrofit in existing buildings.

[0003] As an example, in many large multi-tenant and multi-unit commercial buildings such as office buildings, or apartment buildings, metering of utilities to individual units is not generally available. The building is divided into e.g. east/west or north south zones, and HVAC services tend to be controlled on zone-by-zone basis or on a floor-by-floor basis, for example. Typically, lighting systems are separate from and managed independently from heating and cooling, and each system has its own proprietary monitoring and control interface, which must be centrally managed by the facilities manager. Building managers and tenants are unable to track or control energy usage of individual units. Moreover, floor plans of individual units and energy demand may be changed or modified when a tenant changes, expands occupation, or vacates the premises. Management systems do not readily provide for updates to the monitoring and control to accommodate such changes, or even to adapt to seasonal changes, or unpredictable changes in energy usage by one or more tenants.

[0004] A particular problem arises because existing building automation and control (BAC) systems for HVAC, lighting and other services are based on a variety of different communication protocols and network architectures, and require proprietary hardware. Known protocols for building automation and control systems include proprietary, standardized and open source communications protocols and networks. BACnet™ is an example of a standardized protocol; proprietary protocols include LonWorks™ and Echelon™ There are also open serial protocols such as ModBus™ and Metasys N2Bus™. However each system is typically requires each device or element to be compliant with a particular protocol or variants. Thus integration of different systems, and updating or maintenance of multiple systems operating with different protocols and using different network architectures poses a number of challenges and is very expensive.

[0005] Some known examples of building management systems ranging from individual home automation to management of large commercial buildings or groups of buildings, which attempt to address some of these problems, are disclosed, for example, in the following patent documents:

[0006] US patent 6598056 (Honeywell) discloses a building information system, method and client server architecture, which focuses on acquiring and storing information in a database for access by a building management system, based on an application that interfaces with the system through a standardized network services protocol such as BACnet™, an object and services oriented protocol. (See www.bacnet.org).

[0007] US Patent 6141595 (Johnson Controls) describes a software-based architecture for an application-centric building automation system, focusing on a software implementation for setting up an object-oriented building automation system, to overcome problems with device centric and controller centric systems, which are dependent on specific hardware implementations. This building automation system can be used to monitor, collect data and control a multitude of different facilities management devices and applications. In this architecture, all objects are inherited from a super-class that defines an object type, such as a command or view component, and each object is recognized by any component such as view or control. These functions are generic, so as to be hardware independent.

[0008] US Patent publication 2009/0150356 (Leviton) discloses a wireless home or building automation system, using automatic network discovery for discovering and mapping a building's wireless network topology.

[0009] US Patent 7135956 (Nxegen) discloses to a system and method for monitoring and control of energy consumption for load balancing amongst multiple facilities or buildings, using two-way wireless communications. In order to optimize both energy conservation and energy purchasing benefits in a deregulated environment, proprietary software within a centralized data center gathers real-time energy use data from end users. The data is analyzed to produce end-user load profiles on a portfolio basis with and compared with other end users having complimentary and offsetting load profile characteristics, in order to provide load balancing adjustments.

[0010] Referring to Figure 1, labeled PRIOR ART, a conventional system architecture for a building management system is illustrated. This architecture is similar to that described, for example, in the above referenced US patent no. 6,598,056. As shown in Figure 1, a plurality of monitoring or control devices 12, e.g. such as sensors or controllers of a building management system, communicate through a communications interface or data link 14 to send and receive information to one or more applications 16a, 16b... l6n, for example management and control applications, running on a computer or server, that manage power to one or more of the devices 12. Each application has an associated database 18, e.g. a SQL or other known type of database, for storing information and data in an appropriate format for access by a respective application 16n. In this architecture, each application must include the protocol structure for interfacing to the appropriate technology (i.e. protocols such as BACnet®, LonWorks®, ModBus®, or other known protocols), and the data link must pass received data to the application. Systems requiring specific and individual protocols are closed systems. As such, the hardware needed to interface between the application software system and building operations equipment must be compatible with the appropriate protocol. Where this protocol is proprietary, the required hardware is also proprietary and expensive, and the protocol stack limits use of low cost hardware alternatives. If there is a change to the protocol structure or system architecture, the system will need to be interrupted to perform system maintenance. Additionally, each application operates independently, in isolation from other systems, with no opportunity for utility efficiency gains or information sharing from interacting across multiple systems.

[0011] In practical terms, what this means is that, typically, a building comprises a number of distinct systems, such as lighting, emergency lighting, and heating cooling systems, ventilation, sprinkler systems, among others, which are operated and monitored independently requiring a separate interface and management system. For example, one application may be used to monitor and control heating, and another distinct system is used to control lighting, requiring building managers, operators and maintenance personnel to be familiar with a number of different systems. Often user interfaces are very different operationally, requiring specific knowledge and training of the underlying system.

[0012] Specifically, conventional thermostats may be used to control temperature zones on each floor within a building, perhaps providing for individual control of the east and west zones of each floor, and/or providing limited controlling of individual units by specific tenants. Additionally, lighting may be controlled for each zone on a timer to provide full lighting during office hours, and reduced lighting at night. However, there is no way to coordinate these two systems, for example, to reduce lighting during daylight hours on a bright sunny day, to reduce demand on air-conditioning systems, or increase lighting levels if illumination unexpectedly falls below an acceptable level. Also, unless tenant suites have individual metering of utilities, systems do not allow building managers or tenants to monitor usage by each tenant, whether they occupy one suite or multiple suites on multiple floors, or by areas smaller than controlling zones. Such an approach to building automation requiring multiple systems significantly reduces the flexibility of implementing these systems to achieve holistic monitoring, control and management of different utilities within a building. Existing systems do not have flexibility to account for tenant changes regarding occupied space, such as expansions, reductions or movements. There is also limited flexibility of existing systems for holistic monitoring, controlling and management of multiple utilities across multiple buildings.

[0013] Scalability is another issue with known systems for building automation and control. In conventional systems comprising a smart controller and a large number of sensing and control units, i.e. hundreds or thousands, each unit must be initially registered on the network. Then, a significant amount of communication bandwidth and processing power of the system is consumed by simply polling units at regular intervals, i.e. requesting "are you there/active?" Thus the number of units that can be added may be limited, or the system may be limited to monitoring a large number of units at more infrequent intervals, i.e. hourly or 15-minute intervals, which may not be sufficiently frequent for true real-time monitoring and control.

[0014] Therefore, known solutions have one or more limitations with respect to integration of multiple systems using different protocols; cost of proprietary solutions; limited scalability; and limited capability, flexibility or reconfigurability to manage usage or services on a real-time basis or on an individual user or tenant basis.

[0015] Thus, there is a need for improved systems and methods for management of facilities, including operational monitoring and control, and more particularly for building management systems for monitoring and control of energy usage and utilities in multi-unit and multi-tenant buildings.

SUMMARY OF INVENTION

[0016] The present invention seeks to overcome, or at least mitigate, disadvantages of known systems and methods, or at least provide an alternative.

[0017] According to one aspect of the present invention there is provided a system for operational management and control of equipment in a facility comprising: a plurality of control and sensor units (CSU) (120n) deployed at locations throughout the facility, each CSU comprising a communications interface to a plurality of sensors and controllers (122n) for receiving input data signals from sensors and sending output control signals to controllers; and each CSU, sensor and controller having a unique identifier or address, a processor means (server) for Data Aggregation and Communication (DACS) 124 comprising a communication interface for sending messages to and receiving messages from a corresponding communications interface of each CSU 120n,

each of the DACS and CSU further comprising means (i.e. hardware and/or firmware and/or software) for constructing and extracting messages communicated between the DACS and the CSUs, and the DACS comprising storage means comprising a database (144) for storage of data comprising sensor and controller data, and means (e.g. firmware) for generating database folders and files for storing said data, and wherein,

for monitoring, each CSU is operable to generate and send to the DACS messages generated by the CSU comprising at least: a unique address of the respective CSU; current (real-time) data associated with a sensor input linked to the CSU; and file location information indicative of a file storage location for storage by the DACS of said data in the said database;

for controlling, each DACS is operable to extract data from the said database and generate and send to a CSU messages generated by the DACS comprising at least: a CSU address, a command and data; and

the database further comprising an interface for (local or remote) access to the database by at least one management application.

[0018] In preferred embodiments of this first aspect of the invention, the system may be applied for monitoring and controlling of energy usage in a facility such as a single building, a multi-tenant or multi-unit building. An Embedded Management System (EMS), comprising hardware, firmware and/or software, running on the DACS provides for monitoring functions (acquiring operational data for example) from multiple sensors via one or more CSUs and management or controlling functions, e.g. for an application for managing energy consumption, via access to the data in a dedicated database.

[0019] Preferably each CSU comprises hardware including a low cost processor with minimal but sufficient processing power, with the appropriate software, or firmware, to provide wireless or wired communications with sensors, controllers and the associated DACS, and message generation capabilities. The CSU also preferably has capability for self-registration on the network, eliminating the need for continually polling for operational activity by the DACS.

[0020] Communications interfaces/links between the CSUs and sensors and controllers may be wired or wireless, and may comprise lower cost one-way wireless communications with low cost wireless sensors or controllers Communications interfaces/links between the DACS and an associated plurality of CSUs are preferably two-way wireless to enable sending and receiving of messages, and convenience of deployment, e.g. in retrofitting a building, or during moves and changes within a building.

[0021] The architecture and operation of the system is scalable for use with an almost unlimited plurality of DACSs, CSUs and associated Control/Sensors.

[0022] Preferably, the database comprises files organized in folders, section, key and data, wherein each key comprises a data string format. The method may comprise storing and updating real time data at a first location R: comprising a fast real-time temporary database, and archiving information at a second location C: comprising nonvolatile storage. Thus CSU messages are generated comprising a database identifier C: or R:, file, section, key information identifying a database location for storage of data

[0023] The database associated with each DACS preferably stores operational data with associated information such as local time and time zone, equipment identification and location in a protocol independent form which maybe accessed (read/write) by any number of applications, allowing for a multi process communication environment of distributed independent applications

[0024] When a facility comprises a multi unit, multi-tenant building for example, and the DACS may comprise another database storing building information, tenant information, and service information, and the management application comprises a graphical user interface for display of information comprising building, tenant and unit information, and sensor and control data from each associated CSU.

[0025] A tenant unit may comprise an area divided into a plurality of cells (c.f. wireless pico-cells), each cell comprising a respective CSU and corresponding plurality of associated sensors and controls deployed in the area of the [pico-]cell for monitoring and controlling equipment servicing the area or range of a respective cell.

[0026] When the facility comprises multiple buildings or sites, preferably each respective site n comprises a single respective site DACSn, and a corresponding plurality of CSU and associated sensors and controllers, each sensor, controller and CSU having a unique address, and each CSU being associated with a respective site location. For remote management, the system further comprising a remote site comprising a remote management server, the remote management server comprising storage means comprising a remote server database for storing data retrieved from each individual DACS database, and an interface to the remote database for access by a management application for managing aggregated data from one or more of the multiple sites. Preferably, the remote server comprises a web accessible remote management server and each DACS comprises means for sending and receiving communications with the remote management server.

[0027] When multiple sites are located in different time zones, the system comprises means for retrieving and storing local time information with individual site data in the database of the remote server database. Preferably, the remote server comprises a web accessible server comprising a (Webdisk) database, and the system further comprises means (i.e. web application) for remote upload of data from a database associated with a DACS at each site.

[0028] For energy management applications, the sensors and controllers may comprise various types of environmental sensors and controllers such as temperature and humidity sensors, light sensors, alarm sensors, and light controllers, relays, LED controllers and dimmers, sub-metering systems such as current transformer pulse metering devices, or other equipment for sensing environmental parameters such as CO, C0₂ and VOC gases, and controlling HVAC and lighting equipment for example, or other related services and utilities

[0029] According to a second aspect of the present invention, there is provided a corresponding method wherein operation of the system comprises: in monitoring mode, periodically receiving at each CSU sensor input data, and generating and sending to the DACS a message generated by the CSU comprising at least a unique address of the respective CSU; current (real-time) data associated with a sensor input linked to the CSU; and file location information indicative of a file storage location for storage by the DACS of said data in the said database; and in control mode, responsive to an event or requests received from the management application at the DACS extracting data from the said database, generating and sending to a respective CSU a message generated by the DACS comprising at least a CSU address, a command and data.

[0030] The method may comprise self-registering of each CSU on the network, periodic monitoring by the CSU of sensor or control data and generation of a message, e.g. at 1- minute intervals. Messages may be generated by the CSU in response to one or more of activity events, status changes and link status changes. The DACS may check periodically for the status of each registered CSU, and generate messages in response to one or more activity event, status changes and link status changes.

[0031] Other aspects of the invention provide a DACS, a CSU and a graphical user interface for implementing systems and methods of the embodiments.

[0032] The foregoing and other objects, features, aspects and advantages of the present invention will become more apparent from the following detailed description, taken in conjunction with the accompanying drawings, of preferred embodiments of the invention, which description is by way of example only. BRIEF DESCRIPTION OF DRAWINGS

[0033] In the drawings, identical or corresponding elements in the different Figures have the same reference numeral.

[0034] Figure 1, labeled PRIOR ART, illustrates a conventional system architecture of a known system for managing multiple devices or units using one or more applications;

[0035] Figure 2 illustrates a system architecture for implementing a system and method for multi-facility management and operational control through one or more applications, according to a first embodiment of the present invention;

[0036] Figure 3 illustrates schematically a cross-sectional view of a multi-story, multi- unit commercial building showing elements of the system shown in Figure 2 deployed through the building for energy management;

[0037] Figure 4 illustrates schematically a floor plan of part of one story of the building showing elements of the system illustrated in Figure 3 deployed in an individual tenant's suite;

[0038] Figure 5 shows schematically a block diagram of hardware components of an embodiment of a system as shown in Figure 3;

[0039] Figure 6 shows a block diagram illustrating schematically more details of monitoring, sensing and controlling units of the system according to the embodiment;

[0040] Figure 7 shows schematically a representation a graphical user interface (GUI) displaying information collected from tenant's suites, as illustrated in Figures 3 and 4, by a system according to the embodiment; [0041] Figure 8 shows schematically the communications path between the Control Sensor Units (CSU) and the Data Aggregation and Communication System (DACS) deployed in a commercial building as shown in Figure 4;

[0042] Figure 9 shows schematically the hardware components of a Control Sensor Unit;

[0043] Figure 10 shows schematically the firmware processes operating in the CSU of Figure 9;

[0044] Figures 11, 12 and 13 show different states of communications links between the DACS and CSU;

[0045] Figure 14 shows the CSU communications data path to the DACS;

[0046] Figure 15 shows the DACS communications data path with the CSU;

[0047] Figure 16 shows schematically the database structure and the process of updating the databases at the DACS;

[0048] Figure 17 shows the EMS data path between the CSU firmware and the DACS software;

[0049] Figure 18 shows the data path for presenting CSU data on a graphical user interface;

[0050] Figure 19A shows the transmission and receiving messages by a wireless sniffer;

[0051] Figure 19B shows the receiving messages at the DACS;

[0052] Figure 19C shows the receiving messages format saved in the database;

[0053] Figure 20 shows the protocol and structure of the messages sent from the CSU to the DACS;

[0054] Figure 21 shows the protocol and structure of the messages sent from the DACS to the CSU;

[0055] Figure 22 illustrates the creation and sending of notifications via SMS or email if operational thresholds are breached;

[0056] Figure 23 shows a block diagram of elements of the system for upload of data from a plurality of deployment sites to the remote server, and for implementation of multi-site control from any access point to the plurality of deployment sites;

[0057] Figure 24 shows a block diagram of elements of the system for synchronization and reporting of locally significant data between multiple deployment sites and access point time zones; [0058] Figure 25 shows block diagram of elements of the system for communications between a CSU and wireless sensors and controls;

[0059] Figure 26 shows a block diagram detailing the controlling hardware and mechanical components of the LED platform for lighting;

[0060] Figure 27 shows a block diagram detailing hardware components for electricity monitoring functions; and

[0061] Figure 28 shows a block diagram representing a process for implementing a firmware update. DESCRIPTION OF PREFERRED EMBODIMENTS

[0062] A network architecture for a remote management system (RMS) 2 for implementing a method for monitoring and operational control of equipment at a plurality of sites or buildings according to a first embodiment of the present invention is shown schematically in Figure 2. As illustrated, the RMS network 2 provides for remote monitoring and control of a plurality (n) deployment locations or sites 100, 200, 300 and 400, (update fig 2) (i.e. Site 1, Site 2,... Site n), from a remote server 510 at a remote hosting site 500, via a communication network 600. The network 600, i.e. the web (internet) or a private network, also provides an interface, e.g. via a web interface, for network access to the RMS system by a plurality of users User 1, ...User n.

[0063] At each site, a plurality of units comprising sensors and/or controls, i.e. sensors/controls 22, for monitoring and controlling energy usage of equipment or lighting or other building systems and operational parameters, communicate with a local Control Sensor Unit (CSU) 20, which will be described in more detail with reference to Figure 7. For simplicity, Figure 2 shows sensors and controls 22 for Site 1 only, although each site may typically have as many as hundreds or thousands of sensors and/or controls 22, and a number of CSUs 20. Each CSU 20 acts as an aggregation point at the site, and is designed to communicate with multiple sensors and controls 22 deployed throughout the building, as shown for example in Figure 2 for site 1 , and then pass information to a building Data Aggregation and Communication System (Server) (DACS) 24.

[0064] The DACS 24 is the main building/site management unit of the RMS network and will be described in more detail with reference to Figure 8. [0065] For each building or site 100, 200, 300...400, a single DACS 24 acts as a control point and comprises a computer with local user interface that is accessible via the internet 600, where the EMS and RMS applications (Figure 8) reside. The DACS 24 is therefore the main communications interface between a plurality of CSUs 20\ ...20_n and the remote server 510, via the communication network 600, that enables remote utilities monitoring, control and management functions.

[0066] Each DACS 24 is in communication, via the network 600, with the hosting site 500 to enable remote management from the Remote Management System (RMS) server 520 at the hosting site 500. Each DACS 24 collects utility or service operational data from a plurality of control and sensor units (CSU_n) 20_!....20_n associated with building systems, e.g. HVAC, lighting, security or other operational systems, and transmits that data to the remote server 510 at the hosting site 500.

[0067] The remote server 510 at the hosting site 500 comprises a plurality of data stores or databases 530, 540, 550 for storing of operational data received from DACS at a plurality of building or sites 100, 200, 300...400, that have deployed the RMS. Data may then be aggregated as required for analysis or presentation purposes. Additionally, all data information requests and operational commands from any user are communicated via the remote server 510 at the hosting site 500 to the appropriate deployment (site) location 100, 200, 300 or 400. A user, with appropriate permissions, in e.g. building site 1, can access the DACS directly using the local GUI or via the remote server from any internet connection. Local access allows greater controlling functionalities than remote access.

[0068] Each CSU 20 can communicate over a wired connection or wireless link (as will be described with reference to in Figure 25). The deployment of several CSUs 20 at each site is also designed to provide nodes or aggregation points to improve the communication efficiency between sensors and controls 22, and the main building management unit, the DACS 24.

[0069] Thus, as illustrated in Figure 2, the server 510 at the hosting site 500 can, via the CSUs 20„ and DACS 24_n, aggregate and store utility information from numerous sensors and controls 22 that have been deployed in a plurality of buildings. Based on the function of a hosting site, any building that has a DACS 24 running the EMS and RMS that is connected to the Internet can store and forward all sensor and control data from that building to the hosting site.

[0070] All sensor and control data for a building are collected and stored locally on the respective DACS 24 and also transmitted and via the Internet and stored on the remote server 510, which comprises a Webdisk database 530 for receiving and storing real-time data received from the DACs, a local system database 540 and a SQL database 550 for storing other information such as building information, and associated tenant information and customer information related to utilities and equipment for each site, as will be described in more detail below.

[0071] Via Internet/web access, any user with the appropriate authentication, e.g. log-on identification and password, can access utility data at the hosting site. Specifically, the user can access utility data from a plurality of buildings, displaying for example, aggregate utility consumption from all buildings, utility consumption from one tenant occupying one suite, or anything in between. Additionally, the user can also send utility control commands via the Internet and hosting site to all buildings associated with their log-on identification, or to a single tenant occupying one suite, or anything in between.

[0072] More particularly, the RMS system according to a second embodiment will now be described with reference to a building management application for monitoring and control of HVAC and lighting systems, in a multi-unit, multi-tenant building as illustrated in Figures 3 to 17, which facilitates monitoring and control for building managers, operators and tenants.

[0073] An RMS solution 3 according to the second embodiment, is similar to that shown in Figure 2, but is deployed within a single nine story building 100, which is shown schematically in cross-sectional view in Figure 3. The system comprises a DACS 124, which has an Internet connection to network 600 and communicates wirelessly with a plurality of CSUs 120, deployed throughout the building on each floor. Each CSU 120 communicates with a plurality of sensors and controls 122, associated with HVAC and lighting equipment on each floor. For simplicity, only two exemplary sensor/controls 122 for one tenant unit 900 of Floor 9 are shown in Figure 3, but it will be apparent that numerous sensors and controls 122, e.g. for temperature and lighting, are deployed throughout the building and in each tenant unit as illustrated in Figure 4. [0074] Figure 4, which represents the floor plan of one tenant unit 900, shows the deployment of the RMS solution 3 from a single tenant suite perspective, i.e. for a part 4 of the building 100. As is typical, the suite comprises a number of workspaces, e.g. offices 902, cubicle areas 904, hallways 908 and common areas 910, for example. Three CSU 120_! , 120₂, 120₃ are distributed through the tenant unit, each linked to a respective plurality of temperature, light and related control/sensors 122 of HVAC and lighting systems. A plurality of sensors and/or controls 122 are located in individual offices or workspaces throughout the suite as appropriate to meet tenants and building operator's requirements.

[0075] Each sensor/control 122 may comprise one or more sensor elements and/or control elements which may be implemented as separate elements or combined hardware elements. Sensors may comprise, for example, one or more of light sensors, temperature sensors, alarms sensors, motion sensors, current or voltage sensors, meters or pulse counters, or other environmental sensors relating to energy usage and consumption of utilities and related services in the building. Control elements may comprise associated control devices such as manual or automatic controls or switches, thermostats, relays and associated control units, lighting and light emitting diode (LED) control units, and other associated controllers.

[0076] The single DACS 24 in the building can communicates with any of the three CSUs 120i, 120₂, 120₃ located in a tenant suite and the CSUs communicate with respective associated sensors and controls 122 that are located throughout the tenant suite. Preferably, sensors/controls 122, CSUs 120 and DACS 24 are linked by wireless connections, although wired connections may be provided.

[0077] Referring to Figure 5, as described with respect to the system of the first embodiment illustrated in Figure 2, all sensor and control data are received from sensors/controls 122 via the CSUs 120_1? 120₂, 120_3> which, in this embodiment, are associated with a tenant unit 900, and stored on the respective DACS 124 for the building and also transmitted via the Internet 600 and stored on the remote server 510.

That is, as illustrated in Figure 5, elements of the system enclosed in dotted outline by the box 4 correspond to those deployed in the particular tenant unit 900 illustrated in

Figure 4. The DACS 124 for building 100 also interfaces with other CSUs in the same building which are deployed in other suites as shown in Figure 3. [0078] A remote hosting site 500 and a remote server 510 provides for management of DACs 124 for the building 100, as well as other DACs 224, 324 at other buildings, as illustrated in Figure 5. All utility operational data from all buildings associated with the RMS is aggregated on the remote server 510 located at the hosting site 500. Similar to the embodiment shown in Figure 2, the remote server 510 comprises a plurality of data stores, i.e. a Web disk 530 that stores the received data in real-time, the local system database 540 that stores received information per building, floor and tenant, and the SQL database 550 that comprises customer information (such as address, billing information, etc.).

[0079] Any User 1, 2...n, with the appropriate authentication, e.g. log-on identification and password can access the data on the remote server via the Internet 600, and display this data on any device capable of displaying a Web browser.

[0080] Control Sensor Unit (CSU) and sensor/control hardware

[0081 ] An exemplary hardware deployment of a CSU and sensors/controls of an RMS system for the multiple monitoring and controlling of such functions is illustrated in Figure 6, comprising a plurality of different types of sensors 26 and controllers 28. For simplicity only one of each type of sensor and control is illustrated, but as will be appreciated, a plurality of sensors and controls of one or more type and mixture may be deployed throughout each individual tenant suite. The flexibility of the RMS system allows monitoring and control functions to be implemented via wired 130, or wireless 132 connections, and for wireless connections, the communications may be two-way, or alternatively one-way to reduce costs.

[0082] For low-cost monitoring-only functions, one-way wireless communications 130 can be implemented for light, temperature, alarms and motion sensors 126, among others. The most cost effective implementation for these communications would be oneway wireless, from the sensor 126 to the CSU 120_1? however a wired link could also be implemented.

[0083] For manual controls, one-way communications is sufficient, to communicate between the control being operated manually, and the CSU to implement the command. Manual controls 128-1 would also be implemented for lighting control, for example, where a person needs to manually turn on or off lighting. These communications could be implemented wirelessly or via a wired connection as appropriate. [0084] For controlling functions, CSU \20_\ can communicate with controls 128 for thermostats, fluorescent lighting and LED lighting. These controlling functions would be implemented most cost effectively via one-way communications, either wirelessly or wired, sending commands from the CSU to a control relay, e.g. 128-3 or 128-4, for example.

[0085] For fluorescent and LED tube lighting, a number of relays, for example, can be deployed and simultaneously controlled from a relay control unit 128-3 or LED control unit 128-4 respectively. Thermostats 128-2 provide for commands to be sent to control heating, cooling and fan operations.

[0086] For electricity monitoring functions, a control/sensor would comprise a sub- meter 134 that collects consumption data at each monitoring point. Typically, the sub- meter 134 would communicate with the CSU via a wired connection 132. To facilitate energy management, a pico-cell is defined below, based on one CSU with as many controls and sensors as required.

[0087] The set of sensors and controls associated with each particular CSU 120_n covers a particular area of the tenant suite, which is referred to as a "pico-cell" of a grid comprising a number of sensors and controls 122 deployed in a particular area of the building. Each CSU 120n collects data from sensors in the pico-cell, and each CSU is identified by a unique identifier and is associated with a particular location (e.g. a floor number and an xy coordinate on the floor) in the building, which may also be associated with a particular tenant or other information.

[0088] Thus, in this embodiment data from the sensors received by the CSU 1 (120^ and communicated to the building DACS 124 includes identification of the CSU, the CSU location (e.g. floor and xy coordinates on the floor), and data from the sensors. Sensor data includes, for example temperature, light level, alarm status, motion sensor information, or current values associated with sub-meters. Control information sent from the DACS to the CSU may include commands for switching lighting on or off, changing lighting levels, adjusting heating or cooling levels, or other thresholds. Sensor data and other information are stored in the EMS database. The format and protocols for communications between CSUs and the DACS will be described in more detail in subsequent sections. [0089] Graphical User Interface

[0090] Figure 7 provides an example of how this data can be displayed via a local display screen in a graphical user interface (GUI) format 700. Such data can be displayed for a single tenant, a single building, multiple buildings or all buildings, wherever the RMS solution is deployed. In Figure 7, as an example, information relating to two tenant suites located on floor 7 of the building is displayed in the form of a customer dashboard 700, for tenants identified as customer FGH and customer IJK respectively. The display comprises several frames. Two frames 702, 704 to the right show graphical information representing the floor plan of each suite. For each customer, information relating to temperature, lighting and electricity consumption can be displayed, in a Customer box as shown in the frames 710,712 and 714 to the immediate left of the plan of the tenant suites 702, 704.

[0091] Thus, for example, for Customer FGH, displayed is the temperature in Celsius or Fahrenheit, lighting level, or other utility or real time energy consumption or status information and the location of each control.

[0092] Additionally, all information for the floor can be aggregated and is displayed, as shown in the frame 708 on the top left of the figure. Finally, total building information is displayed as shown in the frame 706 to the bottom left of the figure.

[0093] For the RMS floor plan screens (702,704), any floor plan may be imported from any suitable 2D or 3D image (e.g. an imported CAD drawing) to be used as the backdrop for the RMS. As an overlay on the floor plan, the positions of any RMS hardware or modules, including CSUs, 120, sensor units and controls 122 are also displayed.

[0094] Interactive features

[0095] As well as displaying graphical and numeric data, the user interface allows the operator or user to make changes or update information. Any tenant changes can also be entered into the system from the floor plan screen, such as a change in the name of the tenant. Additionally, as tenants increase or decrease the space occupied in a building, these changes can also be effected via the RMS floor plan screen.

[0096] Other controls

[0097] Within the building data section 706 are additional controls specific to all suites in the building. Hidden controls 720 controlled by a "hide ON/OFF" button allows for elements such as sensors, which do not need to be displayed, to be hidden. For example the hide button causes the sensors icons to be hidden from the display in windows 702, and 704.

[0098] For lighting control, Demand Response Management (DRM) 722 and Daylight Harvesting (DH) 724 states can be implemented on a suite-by-suite or floor-by-floor basis, or for the complete building. If the building is participating with a hydro provider in demand response programs, these functions can be set for the building and then implemented when a demand response request is sent from the hydro provider. Daylight Harvesting can also be implemented selectively to reduce lighting requirements in response to bright sunny days.

[0099] Move/Add functions

[00100] A move function 726 enables the sensors and controls 122 of the CSU units 120 to be moved and positioned at an appropriate position on a floor plan and of the appropriate floor level. Any units, hard-wired or wireless, can be moved on the plan with new coordinates selected and entered as required. If building plans are updated or modified, new drawings can be substituted, and the system updated for these physical moves, additions and changes. Beside the move function is an add function 728 so that CSU and sensor and control units can be added as required, to any suite in the building.

[00101] For reference, an image of the building 730 can be uploaded in this section.

[00102] Thus this single user interface provides a user, such as a building operator or manager, with an easy-to-use interface for set-up, management and control of multiple building systems.

[00103] The operation of elements of the system will now be described in more detail.

[00104] Data Aggregation and Communication System (DACS)

[00105] Figure 8 shows further details of elements of the DACS 124 and the communications of data between the DACS 124 and the CSUs 120_! , 120₂, 120n. In this embodiment, the DACS 124 comprises a computer on which resides the EMS software 142 with three associated applications 146^ 146₂... 146_3> of the RMS, which in this particular embodiment are related to energy management of the heating and lighting systems of the building 100. Additional RMS applications for other management functions, such as security, safety and asset tracking functions, could be added to this architecture, as required. [00106] The EMS 142 has an associated EMS database 144 that stores network-specific data locally within the DACS 124. Using the EMS application protocol interface (API) 140, the EMS 142 communicates with CSUs 120_l5 120₂, 120_n located in the building, via communications interface 150, which in this embodiment is a wireless interface, which may e.g. use ZigBee or other known RF protocol.

[00107] The Link 148 is a part of the EMS application, which is responsible for detection and making a decision if a CSU 120 unit is online. As such, Link 148 changes the CSU connection status between on and off, notifies the RMS applications about the connection link status, and allows the RMS applications to send refresh messages and detect reply messages.

[00108] Also shown in Figure 8 is an optional link 154 for providing an interface to bridge to other technologies 152, e.g. to integrate with existing standards such as BAS, if required.

[00109] Control and Sensing Unit (CSU)

[00110] Figure 9 details the hardware architecture of an exemplary CSU 120 wherein some of the sensors 126 and controls 128 are integrated and hardwired on the same card (board) 100 within the CSU, and some of the sensors 226 and controls 228 communicate wirelessly with the CSU using a wireless interface 153. The CSU 120 is designed to provide a communications interface between sensors 126/226 and controls 128/228, and the single DACS 124 for the building. As such, each CSU needs to communicate with the EMS 142 and RMS (i.e. RMS is the group of applications 146_1; 146₂... 146₃ in the DACS) on the DACS 124, but operates only with a kernel of these software systems as firmware. The CSU 120 comprises a CPU 160, where the EMS firmware resides and operates. Preferably the CPU 160, memory 162 and real-time clock 164 are provided as a compact single-board computer within the CSU 120. Communications from the CSU 120 is either to direct end points, e.g. sensors or controls 126 and 128, as a wired connection 168 or wirelessly 172 using a wireless interface, such as ZigBee 152, and 153 or any other cost effective appropriate wireless technology. The CSU 120 also communicates with the DACS 124 using the wireless interfaces 152 or 153, where 152 is an RF interface to the DACS, and 153 is an RF interface to wireless sensors and controls, which use different technologies (153 is a low cost) and different RF spectrum, allowing deployment of a short range and low power wireless Pico-cell. [00111] The CSU 120 provides the communications link to sensors 126, 226 and controls 128, 228. In this example, controls specifically provide electricity control to lighting systems and thermostats for heating and cooling systems.

[00112] Advantageously, two types of sensors 126 and 226 are provided:

a) Sensors 126 located on the CSU card to provide accurate information such as light level in lumens, temperature in Celsius or Fahrenheit and power consumption in watts. b). Wireless analog and digital sensors 226, allowing low cost extension.

[00113] For CSUs according to other embodiments (not illustrated in Figures), both types of sensors may alternatively or additionally comprise other sensors, such as gas sensors e.g. CO, C0₂ and VOCs among other, motion sensors e.g. to detect occupancy of an area, or photocells e.g. to detect light levels. Additionally, meters for monitoring natural gas (BTU) and water can be included if required.

[00114] As noted above, a plurality of such CSU units 120„ are distributed throughout a building. For identification, each CSU 120 has a unique identification/identifier and serial number, and is associated with a location, as shown in Figures 3 and 4, comprising a floor number, and location on a particular floor, e.g. an xy coordinate, or other similar position information.

[00115] Figure 10 shows schematically the firmware architecture of the CSU 120. A small kernel of the EMS software resides on the CSU 120 allowing the application to communicate with the RMS applications in the DACS. The CSU comprises an application firmware 82, EMS API 84, sensor firmware 86, control firmware 88, memory firmware 90, and real-time clock firmware 99 and provides the communications link via the wireless interface 94.

[00116] Operation

[00117] Initially, in set-up or registration mode, each CSU 120 is associated with a unique identifier such as [001], floor number and 'X' 'Y' location on the floor, such as floor 1 and [xxx34] to define the XY coordinates on the floor. Specifically, each CSU corresponds to a pico-grid, (A pico-grid is the physical area including the high power grid, 110/220/347 volts, that is being control by a Pico-cell which is the wireless network hardware and firmware.) representing a communications area associated with a specific area of the building, site or unit covered by sensors/and controls linked to the particular CSU, for managing consumption and measurement of utilities.

[00118] CSU and DACS communications link status

[00119] Figures 11 to 13 represent different link statuses of the data communications link between a CSU and a respective DACS. All the states are located in the DACS and handled by the link library. There is no direct connection between the link and the CSU, as the database and the EMS provide the DACS-to-CSU connection. The link library provides information to the application about the CSU link state.

[00120] Link management

[00121] Figure 11 represents the data communications link status between the CSU and the DACS. Upon power up the CSU 120 performs it own automatic network recovery, searching for the wireless system channel, which provides the date and time sent by the DACS. The CSU then registers itself on the network by sending an automatic registration.

[00122] After registration, the CSU starts sending message to the DACS (step 1001), and transmits identification and its status information to the database via the EMS located at the appropriate database 144 files (in R:\ems\mmi\DB\100004\ where the last folder is named according to the CSU number '00100004' below.

90000051 [00100004 ] sys =21

00000052 [001000041 app=50

90000053 [00100004 ] ut il=41

90000054 [00100004] Copyright =>- 2009 energWaue

90000055 [00100004] uer=090903

00000056 [001000041 cs =3942

[00123] The received data is aggregated automatically into a file defined by the CSU. Files created by the CSU on start-up are automatically populated with current data from the sensors and controls associated with the CSU, e.g. temperature data, light levels, control setting, etc. Referring to Figure 11, when the DACS receives a message from the CSU that the CSU is active (step 1002) the DACS saves received messages in the database (step 1003), reloads the timeout counter for each new received messages (step 1004), e.g. each minute or less. After registration, the link library updates the CSU status to on-line (step 1005).

[00124] Figure 12 represents the data communications link between the DACS and the CSU to ensure an active link. The DACS will communicate with each registered CSU in the building. Each CSU is identified as located in the building during the design process for the RMS deployment in the building, i.e. a list of identifiers for all registered CSUs will be stored in the RMS database. As indicated, if the CSU is not active, the DACS will re-attempt to communicate with the CSU with one of the RMS applications only if required, i.e. if decided by the RMS application. During this time, the CSU is identified as inactive (step 1006). Once the CSU has indicated that it is active this status information is listed in the link library 148 as described with reference to Figure 8. As an active unit, sensor and control information can be received by the CSU and commends can be sent by the CSU. Once active (step 1007), the CSU will start to continuously send a message every minute (or upon an event) that reloads the count-down process at the DACS (step 1008).

[00125] Figure 13 represents the communication between the RMS application and the CSU. When an RMS application sends a message to the CSU it checks if the CSU is active, than it sends the message. If CSU is not active it will show the CSU status as inactive on the GUI (step 1012).

[00126] The link library 148 as shown in Figure 8, allows the RMS application 146 to determine if the CSU is active by sending a message to the CSU requesting a reply (1010). It sends a refresh message that activates a reply from the CSU and changes to online status.

[00127] This function is used before sending a message to the CSU (1013), for example a command, to ensure that the CSU is active and can respond.

Figure 14 represents the data path from the CSU to the DACS. Sensor data is communicated from the sensors 126 (or 228) to the EMS application via firmware 82 on the CSU 120. The EMS application firmware 82 also communicates with the controls 128 (or 228) to implement commands. To enable communication between the CSU and the DACS, the EMS API 84 (application protocol interface) is the bridge between the application firmware 82 (see also Figure 17) and the communications medium 94 to the DACS. The EMS API 84 is a tiny kernel that can be incorporated into any application as software or as firmware. The communications medium 94 can be wireless or wired, RS232, IP or other. Any new wireless control or sensor that is added to the CSU's pico- cell network has its unique address with 2¹⁰ address options. Any local (non- wireless) sensor or control that is located on the CSU card does not need an address. [00128] Figure 15 describes the data path in the DACS 124 from the CSU 120. The EMS 142 operating on a personal computer or similar device, and comprises the EMS API 140, the INI API 141 and the EMS database 144, and interfaces to one or more RMS applications 1, 2, 3 146 as detailed in Figure 8. For the purposes of this embodiment, the three RMS applications 146 (1, 2, or 3) as illustrated in Figure 8, are energy management applications.

[00129] Figure 8 shows the software components of the DACS, while Figure 15 is focused on the datapath in relation to the software components of the DACS in more detail.

[00130] In Figure 15 boxes labeled kWh (kilowatt hours) measurement, load control, sensor monitoring, et al., are related to the RMS applications that are running independently and using the EMS database to communicate with the CSUs according to the application.

[00131] As shown in Figure 17, the EMS API 140 provides an interface to any type of layer at the CSU 120_nto communicate with the DACS such as status messages, firmware status, etc.

[00132] Referring now to figure 16, this figure represents the file structure of the EMS database 144. The file structure is created automatically by CSU as shown in Figure 11. The CSU's firmware decides what information to generate and sends this to the EMS system. As data is created, the files are updated and can be displayed in near real time on the GUI. The server's EMS receives information and locates it in the EMS database in the appropriate location, e.g. by file name, section, key and data. As illustrated schematically, the structure of the EMS database 144 of the embodiment comprises two separate databases, C: and R: To provide for fast real-time updating of data, the database comprises a temporary fast database (R:), and a permanent database (C:). Specifically, files are stored in either of the two locations, C: a permanent database or R: a temporary fast database. The temporary fast database provides for fast read and write for real time information and the permanent database stores permanent non-volatile (with power off) information (or archiving information), which does not need to be accessed or updated frequently.

[00133] Files in each database have a similar structure and are organized in folders, with files comprising a section, key and data, each key comprising a data string format. Data is received at an input such as RS232, IP or any other conventional input, and, the EMS API places the data according to the following message format 'files.section.key.data' in the appropriate location in the database.

[00134] Referring to Figure 14, the CSU 120 sends data that was read from the sensors 126 (e.g. current meter, temperature, light level, etc.) and the EMS 142 on the DACS places the received data into the appropriate files at the appropriate location as described previously with reference to Figure 16. The RMS application 146 (in Figure 17) can access and read the stored data from the EMS database 144 and convert it to meaningful information (such as temperature in Celsius, or electricity consumption in kWh) for presentation onto an output device 110 such as a computer screen 170, as shown in Figure 18 and more comprehensively in Figure 7.

[00135] Figure 17 shows the data path and main blocks that are being used to communicate between the CSU firmware and the DACS software.

[00136] On-line monitoring

[00137] Figure 18 (and Figures 19 to 21) shows schematically a display of database information associated with a particular embedded unit collecting data for use, such as for on-line monitoring. In figure 14 the CSU 120 sends data that was read from the sensors (current meter, temperature and light level, among others), the EMS at the DACS stores the received data into the appropriate files at appropriate location as will be described with reference to Figure 19. Messages containing data are passed between the firmware on CSU 120 and the software on the DACS 124 and then passed to the EMS database 144, either on the DACS 124 or on the remote server 510 and may be accessed locally or remotely for display on a GUI 170 of a user terminal 110. The RMS application reads the database, converts it to meaningful information (such as temperature in Celsius or energy in kWh) and presents it on screen, i.e. via graphical user interface 170 as shown in Figure 7.The structure of message cells containing data sampled at three different points A, B, and C, as shown in Figure 18, is represented in Figure 19A, 19B and 19C respectively:

19A: Rx messages at the EMS 142 from the CSU 120

19B: Rx messages at the EMS presented on screen

19C: Rx messages stored in the database [00138] As described with reference to Figure 7, the user interface provides the ability to display sensor data collected from the CSU, discretely or in aggregate, on a local computer 110 via a graphical user interface (GUI) 170.

[00139] Figure 20 details the protocol and structure of messages from the CSU to the EMS at the DACS, specifically:

Header: cell information such as cell length etc.

CSU Address: of the CSU

File name: where to locate the data in

Section: where to locate the data in the file

Key: where to locate the data in the section

Data: a string of information

End: a checksum

[00140] Figure 21 details the protocol and structure of messages sent from the EMS at the DACS to the CSU, specifically:

Header: cell information such as cell length etc.

CSU Address: of the CSU

Command: action to take by the CSU

Data: a string of information

End: a checksum

[00141] Electronic Messaging and Notifications

[00142] Figure 22 illustrates a low cost capability to send notifications to users via email or wireless SMS (short message service). Based on data received from a CSU 120, if such data breaches a pre-defined value threshold, the EMS 142 will send a message about the event to a designated user from the EMS database 144.

[00143] Figure 23 illustrates a high-level description of the RMS network architecture for another embodiment (similar to that shown in Figure 2) for remote management of a plurality of buildings or sites (Sitel, Site 2, ...Site n to illustrate the process of uploading data from multiple deployment locations as well as the control of these deployment locations from remote locations. From each deployment location or site n, the respective DACS n 124n can transfer a file to the remote server 510. The file contains different types of messages formatted as a buffer list of messages (e.g. as illustrated by the examples shown in Figures 19, 19B, 19C, 20 and 21). This data must be located at the appropriate location in the database, however the remote server does not need to know the meaning of the message. The extraction of the file is based on information that is embedded in the message, specifically the path and file name, section, key and data. This process is similar to the process of filing data that the DACS receives from the CSU as described with reference to Figures 15 and 16. The following shows an example format of a file sent from a DACS 124n to the remote server 510. l=cfg~Temp~ALFKI.1083₅~20 C

2=cfg~Temp~ALFKI.10692~18 C

3=cfg~Temp~ALFK.I.10702~18 C

4=ALFKJ\10692~Hour~1950~-l,51,52,53,54,55,56,57,58,59,

5=ALFKI\10692~day~19~5,15,2₅,38,4₅,₅₅,

6=ALF J\l₀692~month~1215~ l l l l l,-l lrl lrl, rl 6,32,36 7,36,36,37 l_rl _rl_rl_rl_rl,-l l l l,-l,

7=ALFKI\10692~year~12~ A0rlrlrl l l l,-l,3,₅rl,-1 ,8 l,-l,-l,-l ,-l,-l ,-l,-l ,-l,-l,-l,-l ,-l ,-l,-l,

8=ALFKJ\ 10692~Control~time~2009/ 12/ 1₅/20

9=ALFKm0702~Hour~1950~-l,51,52,53,54,55,56,57,58,59,

10=ALF I\10702~day~19~5,l 5,25,32,40,55,

l l=ALFKI\10702~monto~1215~l,-l,-l ,-l ,-l ^

12=ALFKI\10702~year~12 O,20,30,40,50,60,70,80,90,99,10,20,30,40,4,n_^

13=ALFKM ₀702~Control~time~2009/l 2/15/20

14=ALFKM0835~Hour~1950~-l,51,52,53,54,55,56,57,58,59,

15=ALFKI\10835~day~19~5,15,25,35,40,55,

16=ALF I\10835~month~1215~-l,-l,-l,-l,-l ,-l ,-l ,-l,-l ,-l,-l ,-l ,-l,37,37,36,37,36,37,35,-l,-l,-l,-l,

n=ALFKI\10835~year~12~-l,8,0,-l ,-l ,4,0^^

18=ALF I\10835~Control~time~2009/l 2/15/20

[00144] Multi-site implementations with 2-way communication interface

[00145] In a multi site embodiment of RMS such as shown in Figure 23 an authorized remote user 1, 2 or n has the capability to request data or send commands to a single deployment location, or a plurality of locations via the Web or private network 600.

[00146] Remote command to the DACS - A remote user may access the RMS system, for example via Internet access and a web browser to display a graphical user interface 170 such as described above with reference to Figure 7. When the user clicks a command button or changes an operating value such as temperature, the web application (located in the remote server 510) saves these commands in a selected *.ini file that is related to the specific location and DACS associated with the activity. In case of a broadcast request for multiple commands, the command is saved into a file that is related to all locations and DACSs. All DACSs are programmed to check every 2 seconds if there are any command files in the remote server 510. Upon detecting a new command file, the DACS reads the file and activate the commands. A confirm message is then sent back to the remote server and the web application presents the results on the web page to the remote user.

[00147] Message from the DACS to the remote Server- Every 1 minute the remote server 510 checks if a new file exists, reads the file from the remote Web disk database figure 2 530, deploys the data into the appropriate local system database according to tenant name/number, then deletes the file allowing reception of a new file.

[00148] At regular intervals, e.g. every 10 minutes, the DACS aggregates the received data into a "10 minute database" log. , creates a file that includes only the changes during the last 10 minutes and then transfers the file via FTP to the remote Web disk database 530 (see Figure 2) on the remote server 510.

[00149] Multiple Time-Zone implementation.

[00150] Figure 24 illustrates a High Level description of the RMS network architecture (similar to that shown in Figure 2 and 23) according to yet another embodiment similar to that shown in Figure 23, but deployed across a multiple time zones. The system provides for a process of establishing applicable time zones for correct reporting of local time, regardless of deployment location. For system-wide utilities management across a plurality of buildings, the RMS customer needs to accurately track operations specific to the local time of each deployment location. The individual building operations, managed by a respective DACS, are directly impacted by local times and local weather, with respect to automated lighting and temperature, and any manual adjustments.

[00151] Data collected from each building therefore needs to be presented to the operator with the local time at the location of the respective property regardless of where an operator or manager is located when accessing the data. For example, a building located in San Francisco needs to present its operational data in Pacific Time regardless of whether the property manager viewing the data is located in New York (Eastern Time), Frankfurt (Central European Time) or San Francisco. Additionally, the remote server 510 that is collecting the data for remote presentation may also be in a different time zone, and therefore must account for a plurality of time zones between deployment locations and users accessing the data. To account for this requirement, the RMS gathers building operational data based on the local operating time zone, and stores that locally time significant data, e.g. a local time-stamp, in Web disk database of the remote server 510 regardless of the time zone where that database exists. The interface, i.e. web page, then presents the localized data for the site regardless of where the user accessing that data is located based on the "time stamp" that has been collected with the data.

[00152] Figure 25 illustrates a wireless interface for data transmission between a CSU 120 and a wireless "control/sensor" unit 122 (also shown in figure 4). Communications is established using low-cost one-way receivers or transmitters 153 on the CSU 120 and the control/sensor unit 122. The use of low-cost one-way receivers and transmitters can reduce cost versus two-way wireless communications and also eliminate the need for a processor, and therefore are effective for establishing a short-range and low-power wireless pico-cell area.

[00153] Each CSU has both transmit and receive wireless units 153, and each allows one-way communication, for transmitting control commands and receiving event data respectively. These CSU transmit and receive units use a different frequency spectrum to avoid communication interferences.

[00154] Each wireless control/sensor unit 122 has a unique address associated with a CSU as a Pico-grid address.

[00155] Each control/sensor unit 122 used to implement control commands has a unique address allowing a CSU to direct the command data to the specific control units having that particular address. In such a deployment scenario, each CSU can control relays and implement light dimming actions, while receiving data from different types or analog and digital sensors.

[00156] Figure 26 illustrates the hardware and mechanical components of the lighting LEDs controlling platform, which allows for four levels of light dimming. The LED control unit 128₄ is linked to a CSU 120 and controls LED tubes 1 to n. The LED control unit and LED tubes are each associated with a Pico-grid address. Thus, one command from the CSU 120 can control simultaneously all the LED tubes within a Pico-grid address.

[00157] The LED tube is a platform that can replace existing fluorescent tubes and the requisite ballasts. The LED platform has its own local power supply allowing direct connection to the electrical grid of the building, which eliminates the need for a ballast. In addition the LED platform can have temperature sensors 300 that detect the LED tube temperature and reduce power if the temperature detected exceeds a specific threshold. The LED platform can also have a motion sensor 302 to allow for lighting level dimming when no motion is detected for a specified time interval. Lastly, the LED platform can have a light sensor 304 that detects the ambient lighting level using a hole pipe and make the appropriate light level adjustments. The hole pipe allows the light sensor to detects the ambient lighting level without be affected when the tube's LEDs are ON.

[00158] When the tube is dimmed to OFF, by the wireless control interface, and light sensor detects dark, then the motion sensor is activated. When the motion sensor detects a motion, it turns the light to ON and keeps it ON while motion is detected. When motion is not detected, the light level in dimmed slowly to OFF. In a lower cost tube without a control interface, when the motion sensor detects motion, it turns the light level to high. When motion is not detected, the light level in dimmed slowly to OFF. This version can be set to a minimum light level. Thus, the power consumption and operational temperature of the LED tube unit can be more effectively managed or reduced as far as possible, to extend the operational lifetime of the unit. The base of the LED housing unit also preferably has a shape that allows for airflow that can help minimize temperature levels in the fixture, and thereby also help control the operational temperature, which can extend the lifespan of the LEDs to 100,000 hours, almost twice as long as the tubes that are in the market. Most LED tubes are built like a fluorescent tube , some types have heat sink on that back side of the tube, allowing cooling the ambient temperature but not the LED base, which can reach a high temperature close to 100 Celsius, which shortens the LED life.

[00159] Figure 27 illustrates multi-tenant energy monitoring capabilities, with capability for 16, 32, or 64 sensors for Automatic Meter Reading (AMR). With these ARM units 134, data logging for electricity consumption is based on pulse inputs from an energy metering sensor. The multi-tenant AMR unit 134 is based on real-time parallel logging of these multiple energy metering sensors, which can have 16, 32 or 64 CT (current transformer) sensors. The AMR unit 134 converts the data received by the CT to pulses and increments an internal counter per CT .Each minute, the AMR unit 134 creates a data string that includes all CT channel data and sends it through the wireless interface to the CSU 120 and on to the DACS. The EMS software (at the DACS) saves the received data string (as described in Figure 16) into its local database in the appropriate location according to the received string directions, as described in Figures 15 and 16. At regular intervals, (as described with reference to Figure 23) the DACS updates the remote database consumption data, allowing for review by authorized users.

[00160] Firmware upgrade.

[00161] Firmware upgrade refers to replacement of the firmware on the remote hardware units, such as the CSU, with a newer version, in order to bring the system up to date, improve its characteristics or add new features. Common firmware upgrades include updating of a non- volatile FLASH memory that contains the embedded operating system. Although upgrades are for the purpose of improving a product, there are risks involved including the possibility that the upgrade will fail and corrupt the existing data in the FLASH memory. For the RMS providing real time data monitoring and control, there are potential problems or risks with the two popular firmware upgrade methods typically used.

[00162] In one known method, a small boot program runs independently with an RS232 serial port that communicates with an external host such as PC. Upon power up the boot checks if the FLASH program is valid and jumps to the operating code address. If the code is corrupted, the boot program will wait to communicate with a host and place the received data in the appropriate location in the FLASH. Using this method requires programming units one by one and might require a system shutdown during the new firmware download. The risk is that if the firmware upgrade fails the unit is OFF during this process.

[00163] In another known method, a small boot program that starts upon reset, it copies the memory from non volatile memory to an external RAM then jumps the address located in the RAM allowing the CPU to run from the RAM. The application can upgrade the non-volatile memory without interrupting the system operation since it runs from the RAM. Upon reset, the new version will be copied to the RAM. This architecture is expensive since it requires an additional RAM for the operating system code. The risk in this method is that if the non-volatile memory programming failed, the unit would lose the code in the non- volatile memory.

[00164] Figure 28 illustrates a preferred process for upgrading the CSU firmware, remote upgrade, based on a very low cost micro-controller 400 using serial RS232 connections and a serial interface such as PC (Inter-Integrated Circuit protocol) 412 to the EEPROM 410 without an Ethernet connection. The RMS approach for 'firmware upgrade' process allows the updating of all CSU's through a wireless interface, while the system is operating normally. This process can occur at any time, during live operation and without the need to shutdown the system and disrupt operations. If the upgrade process (of one or more CSUs) has failed, all CSUs will continue operating using the existing firmware. Upon a programming command, all the participating CSUs update their new firmware in their Application Code memory 406, safely, quickly, and preferably in less time than the regular intervals during which the CSU is generating or receiving data messages.

[00165] The benefits of a remote upgrade method include the use of low-cost standardized hardware with serial PC EEPROM 410. Additionally, the firmware upgrade programming process is done without affecting the operations of the over-riding RMS, as the EEPROM programming time is short and safe, the upgrade process can be implemented remotely.

[00166] The 'Firmware upgrade' application allows individual or parallel programming of the CSU's serial EEPROM 410. Individual programming is done by selecting one CSU that has the match address. Parallel programming is by broadcasting the data to address '00000000' Each CSU reads the received data and activates the appropriate command.

[00167] There are two types of program images, an application image and a programming image:

[00168] Application image-example of a line of data (the format is according to existing programming standards):

[00169] :040000000CEF00F011

[00170] :0C000800D8CFFFF5E0CF08F021EF29F081

[00171 ] : 1000180000EE09F010EE0AF03 AEC2EF000EEC AF00D

[00172] Programming image- example of a line of data:

[00173] :10740200FFFF5CEF3CF0FFFFFCD76800FFFFD96E87

[00174] :10741200D950D8B411D03F0EC716C66AC56AD95022

[00175] : 10742200C61200016851 C712C68 A080EC86E82864B [00176] Additionally, the DACS has a special upgrade program that can begin once a programming command is requested. When any type of data is received from the DACS, it is stored in the CSU's serial EEPROM 410. Each line in the image includes the buffer length (first 2 numbers) and the address (4 numbers) where this data is located in the FLASH memory 404. Upon a request, all CSUs send the new image checksum located in the serial EEPROM 410 to the EMS database and create a checksum list. The DACS 'upgrade program' compares the list and provides the appropriate information to proceed with the firmware upgrade. On a FLASH programming request the CSU firmware jumps to the 'firmware upgrade' program located currently at address 7400H in the FLASH upgrade code memory 408 and copies the image from the serial EEPROM 410 to the application code memory 406. This process is safe (internal process on the same card) and takes 5 to 10 seconds.

[00177] When the programming process is done, the watch dog (disabled at the programming process) is enabled and activates reset that starts the new firmware version. Programming of a new 'firmware upgrade' version can be done any time without affecting the CSU application.

[00178] Other alternative embodiments.

[00179] Embodiments have been described above with reference to an energy management solution applicable for automation and control of individual tenant suites in one or more individual buildings, as particularly applied to monitoring and control of HVAC and lighting systems. It will be apparent that alternative embodiments can provide for management of multiple buildings or facilities, e.g. multiple building on a campus or on geographically distributed sites, so that energy usage may be monitored, analyzed and/or controlled with various levels of granularity i.e. by building, floor, zone, suite, individual tenant or other selected parameter.

[00180] It will be also be apparent that management of energy usage consumption of other utilities and/or other services, and various environmental parameters or operating conditions may be similarly monitored and controlled. Such systems may be applicable to management of facilities comprising a number of buildings, on a single campus or at geographically distributed sites. Systems may also be provided for management individual units, or subunits, in a multi-tenant, multi-unit building with much finer granularity than conventional zone-by-zone building management systems. Systems may also be applicable to other facilities such as manufacturing, production or agricultural facilities, where consumption of energy and other utilities and services must be monitored and controlled. Moreover, systems may be retrofitted to existing buildings, and overlaid on existing systems, at reasonable cost.

[00181] Other embodiments of the invention may be more widely applicable to managing other systems, such as security systems, alarm systems, or asset tracking systems where monitoring and control of similar operational information, environmental and positional information and management systems is required.

[00182] Systems and methods according to embodiments of the invention described above provide one or more of the following advantages over known or alternative systems.

[00183] Self-Registration: the RMS provides for automatic registration of CSUs and does not require additional setup or pre-registration of new units. Any CSU, upon power up, sends its details directly into the RMS database and to the link file, and only association of a new CSU address with the GUIs images (icons) (see Figure 7) is required. The RMS application utilizes the link database to establish communication with the CSU. There is no need to register the CSU within the system beforehand.

[00184] Conventional polling is not required: in the current system, wireless communication is used only as needed for communication of information in the system. Thus data is sent only when it is required, for example, if a value has changed at a sensor, or in response to the occurrence of an event. Based on a simple function call from anywhere within RMS network, results any data type would be sent to the EMS database. This overcomes the problems of conventional systems in which most of the communication activities are status polling messages ("are you there?"). This approach is not scalable when dealing with hundreds or thousands of units.

[00185] Database structure: the database entry is created automatically for any new CSU that is registered to the system, at power up of the CSU. A reset command can be issued by the application (as required) to resend the CSU parameters again to re-register the CSU. Data acquisition and logging is automatic; any type of new message can be saved in the database.

[00186] Messages: Are located in the RMS database according to the type of content. These messages are placed into the database as a string format directly or into a cyclic buffer, and can include any type of content or new message without any requirement for code modification.

[00187] Multiprocessing: The RMS / EMS platform provides for simultaneous messaging, monitoring and controlling. It can record data frequently, e.g. every second, and data is located in local application memory, by the definition, size and type. In legacy systems, each new message type requires code modification.

[00188] Protocol: the application uses the database to communicate with the CSUs and a specific protocol is not required. The system provides a virtual interface, since the application works with the EMS database only. New features or data do not require protocol modifications, and because there is no protocol stack limitation, low cost controllers, with any standard CPU and OS may be used.

[00189] Only a very small amount of memory is required in the embedded application to communicate with the EMS.

[00190] Wireless technology: embodiments described above used ZigBee, but alternative embodiments may use any type of physical interface, and may include, e.g. frequency hopping for a more robust solution.

[00191] Traffic: collision detection is handled by the modem firmware.

[00192] Each radio/wireless CSU's radio has a self-recovery engine to be connected automatically to the system, for example, if one unit (or more) did not receive the new channel, in less than one minute, it will be automatically connected back to the system.

[00193] The system allows configuring of radio parameters during the system operating time, such as, channel changing, encryption, and power level.

[00194] INDUSTRIAL APPLICABILITY

[00195] As described above, systems and methods according to embodiments of the invention provide a system-based implementation for energy management, to allow for energy management at a plurality of deployment locations or building, while deploying a plurality of monitoring and controlling devices within each building.

[00196] Remote management systems are provided for applications such as operational monitoring and control of facilities ranging from individual tenant units, buildings at one or more sites, including geographically dispersed multi-site facilities, with particular application for energy management comprising monitoring and control of energy consumption and usage of other utilities and services.

[00197] Although embodiments of the invention have been described and illustrated in detail, it is to be clearly understood that the same is by way of illustration and example only and not to be taken by way of limitation, the scope of the present invention being limited only by the appended claims.

Claims

1. A system for operational management and control of equipment in a facility, comprising:

a plurality of control and sensor units (CSU) (120n) deployed at locations throughout the facility, each CSU comprising a communications interface to a plurality of sensors and controllers (122n) for receiving input data signals from sensors and sending output control signals to controllers; and each CSU, sensor and controller having a unique identifier or address,

a processor means for data aggregation and communication (DACS) 124 comprising a communication interface for sending messages to and receiving messages from a corresponding communications interface of each CSU 120n,

each of the DACS and CSU further comprising means for constructing and extracting messages communicated between the DACS and the CSUs, and

the DACS comprising storage means comprising a database (144) for storage of data comprising sensor and controller data, and means for generating database folders and files for storing said data,

wherein

for monitoring, each CSU is operable to generate and send to the DACS messages generated by the CSU comprising at least: a unique address of the respective CSU; current (real-time) data associated with a sensor input linked to the CSU; and file location information indicative of a file storage location for storage by the DACS of said data in the said database; and for controlling, each DACS is operable to extract data from the said database and generate and send to a CSU messages generated by the DACS comprising at least: a CSU address, a command and data; and

the database further comprising an interface for access to the database by at least one management application.

2. A system according to claim 1 wherein each CSU is operable, on power-up, for self registration with the DACS, and wherein the system further comprises a link 148 for monitoring and storing a current link status for communications between each registered CSU and the DACS.

3. A system according to claim 2, wherein for monitoring, each active CSU generates and sends messages periodically to the DACS.

4. A system according to claim 3 wherein messages are generated at regular intervals comprising 30second, lminute or 2 minute intervals.

5. A system according to claim 3 wherein messages are generated in response to one or more of activity events, status changes and link status changes.

6. A system according to claim 2 wherein the DACS checks periodically for the status of each registered CSU, and generates messages in response to one or more activity event, status changes and link status changes.

7. A system according to claim 1 wherein the database comprises a first storage location R: comprising a fast real-time temporary database for storing and updating real time data, and a second storage location C: of non- volatile storage for archiving information.

8. A system according to claim 7 where each database comprises files organized in folders, section, key and data, wherein each key comprises a data string format.

9. A system according to 8 wherein CSU messages comprise a database identifier C: or R:, file, section, key information identifying a database location for storage of data

10. A system according to claim 1 wherein the facility comprises a multi unit, multi- tenant building, and the DACS further comprises another database storing building information, tenant information, and service information, and the management application comprises a graphical user interface for display of information comprising building, tenant and unit information, and sensor and control data from each associated CSU.

11. A system according to claim 10 for energy monitoring and control wherein each tenant unit comprises an area divided into a plurality of pico cells, each cell comprising a respective CSU and corresponding plurality of sensors and controls deployed in the area of the cell for monitoring and controlling equipment servicing the respective cell area.

12. A system according to claim 11 wherein each CSU is associated with a location comprising a floor identifier and xy coordinates on the floor of the building, and graphical display of information comprises displaying a floor plan of at least one tenant unit, graphical representations of associated CSU, sensors and controls, together with display of corresponding sensor and control data.

13. A system according to claim 1 wherein the facility comprises multiple sites, each site having a respective site DACSn, and a corresponding plurality of CSUs and associated sensors and controllers, each sensor, controller and CSU having a unique address, and each CSU being associated with a respective site location; and

the system further comprising a remote site comprising a remote management server, the remote management server comprising storage means comprising a remote server database for storing data retrieved from each individual DACS database, and an interface to the remote database for access by a management application for managing aggregated data from one or more of the multiple sites.

14. A system according to claim 13 wherein the remote server comprises a web accessible remote management server and each DACS comprises means for sending and receiving communications with the remote management server.

15. A system according to claim 13 wherein sites are located in different time zones, and further comprising means for retrieving and storing local time information with individual site data in the database of the remote server database.

16. A system according to claim 13 wherein the remote server comprises a web accessible server comprising a database, and the system further comprises means for remote upload of data from a database associated with a DACS at each site.

17. A system according to claim 16 wherein the database comprises a Webdisk for remote access by a web application.

18. A system according to claim 1 wherein each CSU comprises wired and/or wireless links to one or more sensors and controllers.

19. A system according to claim 1 wherein each CSU comprises wired links to a first set of sensor and controllers, and a wireless link to another set of wireless sensors and controllers.

20. A system according to claim 1 wherein each CSU comprises a first wireless interface for one way communication of sensor input data and controller output data, and a second wireless interface for two-way communications with a DACS for sending and receiving messages.

21. A system according to claim 1 or 13 wherein operational management and control of equipment comprises management of energy consumption in a facility, and wherein sensors and controllers comprise one or more of temperature sensors, light sensors, current sensors, motion sensors, alarm sensors, manual controllers, relay control units light controllers, thermostats, LED controllers or dimmers, current transformer sub- metering devices or other sensors and controllers associated with HVAC and lighting systems.

22. A system according to claim 1 or 13 wherein operational management and control of equipment comprises management of energy usage and consumption of other utilities and services in a facility.

23. A system according to claim 18 wherein controllers comprises an LED control unit coupled to a plurality of LED lighting tube units, each unit having a unique address, and wherein the units are addressable by the CSU for independent control of units connected in parallel.

24. A system according to claim 23 further comprising thermal sensor and control means for managing the operational temperature of the LED lighting tube units for extended operation lifetime.

25. A system according to claim 24 wherein the LED lighting tube units further comprise a heat dissipating housing.

26. A system according to claim 18 wherein sensors comprise a multi-sensor parallel current transformer unit for sub-metering of electricity consumption at a plurality of locations. .

27. A system according to claim 26 wherein a plurality of multisensor current transformer units are serially coupled to one CSU.

28. A system according to claim 1 or 13 wherein each CSU comprises a memory (404), and serial EEPROM (410) to enable firmware upgrade during operation, the CSU further comprises:

means for receiving a programming command to initiate a upgrade program of the CSU requesting storage of data comprising a new programming image for the firmware upgrade received from the DACS;

means for storing the new programming image in the EEPROM during live operation of the CSU;

means for copying the stored image from the serial EEPROM into the control memory within the time interval between messages generated by the CSU.

29. A method for operational management and control of equipment in a facility, in a sensor and control network comprising a plurality of control and sensor units (CSU) (120n) deployed at locations throughout the facility, each CSU comprising a communications interface (168, 170, 172) to a plurality of sensors and controllers (122) and sensors for receiving input data signals from sensors and sending output control signals to controllers; and each CSU, sensor and controller having a unique address; a server/processor means (124) for data aggregation and communication (DACS) comprising a communication interface (154) for sending messages to and receiving messages from a corresponding communications interface of each CSU, the DACS comprising storage means comprising a database for storage of data comprising sensor and controller data, said database having an interface to a management application; the method comprising:

in monitoring mode, periodically receiving at each CSU sensor input data, and generating and sending to the DACS a message generated by the CSU comprising at least a unique address of the respective CSU; current (i.e. real-time) data associated with a sensor input linked to the CSU; and file location information indicative of a file storage location for storage by the DACS of said data in the said database; and

in control mode, responsive to an event or requests received from the management application at the DACS, extracting data from the said database, generating and sending to a respective CSU a message generated by the DACS comprising at least a CSU address, a command and data.

30. A method according to claim 29 further comprising a step of self-registering of each CSU on power up; monitoring a link status of communications between each registered CSU and the DACS, and updating a link library with the link status of registered CSUs.

31. A method according to claim 30, wherein each CSU periodically monitors data from sensors and controllers and periodically generates and senses a message to the DACS.

32. A method according to claim 30, wherein messages are generated by the CSU at regular intervals comprising 30-second, 1 -minute or 2-minute intervals or other predetermined intervals.

33. A methods according to claim 30 wherein messages are generated by the CSU in response to one or more of activity events, status changes and link status changes.

34. A method according to claim 30 wherein the DACS checks periodically for the status of each registered CSU, and generates messages in response to one or more activity event, status changes and link status changes.

35. A method according to claim 29 wherein storing data in the database comprises storing and updating real time data at a first location R: comprising a fast real-time temporary database, and archiving information at a second location C: comprising nonvolatile storage.

36. A method according to claim 35 comprising generating each database comprising files organized in folders, section, key and data, wherein each key comprises a data string format.

37. A method according to 35 wherein CSU messages are generated comprising a database identifier C: or R:, file, section, key information identifying a database location for storage of data

38. A method according to claim 29 wherein the facility comprises a multi unit, multi- tenant building, and the DACS further comprises another database storing building information, tenant information, and service information, and comprising displaying on the graphical user interface information comprising building, tenant and unit information, and sensor and control data from each associated CSU.

39. A method according to claim 38 for energy monitoring and control wherein each tenant unit comprises an area divided into a plurality of cells (pico cells), each cell comprising a respective CSU and corresponding plurality of sensors and controls deployed in the area of the cell for monitoring and controlling equipment servicing the respective cell area, and comprising displaying monitoring and controlling on a cell by cell basis.

40. A method according to claim 29 wherein the facility comprises multiple sites, each site having a respective site DACSn, and a corresponding plurality of CSU and associated sensors and controllers, each sensor, controller and CSU having a unique address, and each CSU being associated with a respective site location; and

the method further comprising at a remote management server, storing in a remote server database data retrieved from each individual DACS database, and remotely accessing the remote database via a web accessible interface for managing aggregated data from one or more of the multiple sites.