Note: Descriptions are shown in the official language in which they were submitted.
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
BUILDING AUTOMATION SYSTEM DATA MANAGEMENT
FIELD OF THE INVENTION
The present invention relates generally to building automation systems.
More
particularly, the present invention relates to data management techniques and
systems for
building automation system architectures, communications, and configurations.
BACKGROUND OF THE INVENTION
Building automation systems (BAS) are used to coordinate, manage, and automate
control of diverse environmental, physical, and electrical building
subsystems, particularly
HVAC and climate control but also including security, lighting, power, and the
like. Typical
existing BAS systems are hardwired or use a proprietary communication standard
or protocol to
link the various subsystems and provide system-wide user access and control.
Hardwiring and manual programming of BAS systems can create a robust fixed
system
customized for a particular installation. These systems, however, often
require extensive
customization for each building or site. Particular manual programming and
other installation
elements may not be applicable to other systems, contributing to the
costliness and time-
consuming installation associated with such systems.
Further, hardwired systems and those using proprietary communication standards
and
protocols are difficult or impossible to integrate with system components,
panels, and other
elements from different vendors or generations. For example, a campus of
buildings in which an
upgraded BAS is being installed may have existing previous generation (legacy)
systems and
systems from more than one vendor. Installing a BAS and making it compatible
with the
existing systems in such a situation is time-consuming, requiring extensive
manual service and
programming to integrate the existing devices and implement the custom BAS.
Manual service
is typically provided by systems integration personnel. While systems
integrators ate not
favorably viewed by BAS owners and managers because of the expense and
interruption,
systems integrators are a key aspect of the business models of many BAS
manufacturers and
vendors as revenue generation and on-site contact after the sale and initial
installation of BASs.
BAS manufacturers and vendors have therefore been reluctant to alter their
models and eliminate
systems integrators.
With the introduction of BACnetTM, an ASHRAE (American Society of Heating,
Refrigerating and Air-Conditioning Engineers) and ANSI (American National
Standards
Institute) protocol standard, and LonTalkTm, a protocol integration approach
developed by
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
Echelon, some uniformity of standards and communications has been achieved in
the industry.
BACnetTM was intended to standardize HVAC interoperability and serve as a
solution to
industry-wide issues. In use, however, BACnetTM exists in multiple versions
and includes
various non-standard feature functions available to vendors. Many vendors
dictate a particular
BACnetTM version that must be used in order to achieve system compliance,
forcing BAS users
to update. BACnetTM is therefore not completely interoperable across versions
and features.
Further, present BASs are typically single protocol architectures. Thus, while
a given BAS is
"compatible" with a protocol standard, the BAS is natively compatible with
only a single
protocol, such as BACnetTM, another standard protocol, or a proprietary
protocol.
In a simplified analogy, a BAS can be compared to a bound book. Each
installation of
the BAS is a different reader of the book. The book may contain multiple
chapters or sections
and must be custom written and professionally bound for each reader. The
chapters may each be
written in a different language, if the BAS is compatible with multiple
protocol versions or
vendors. To read the various different languages that are in the book, the
reader will need to
manually consult a dictionary to translate each chapter into the reader's
primary or preferred
language. Multiple dictionaries may be needed. The reader may not be able to
completely
translate each language, or may only be able to translate some chapters into
non-preferred
languages in which the reader is merely conversant but not fluent, and
therefore the reader may
only obtain a basic understanding of one or more chapters. For example, one
chapter of the book
might be a first language representing a particular vendor's preferred or
native version of
BACIIetTM for the BAS, while another chapter of the book represents another
vendor's version of
BACnetTM in a second language. If the second language is not one understood by
the reader, the
reader may only be able to become minimally proficient in the second language
using the
dictionary to translate. Without complete fluency, the book is not useful to
the reader for high-
level tasks or communicate effectively. Some languages may be untranslatable,
requiring the
reader to consult a translator to manually translate the chapter or chapters.
Manual translation in
particular is time-consuming and expensive, and if whole chapters are
translated, the entire book
must be professionally rebound to permanently incorporate the translated
material. Without
professional rebinding, the reader will need to repeat the manual translation
the next time the
book is read.
Additionally, BAS installation and maintenance are still generally labor-
intensive custom
tasks that vary with each system implementation. Upgrading, expanding, and
updating or
removing system components and services in particular are also complex tasks,
as the existing
BAS may or may not support new devices and must be manually reconfigured to
recognize and
2
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
incorporate changes. In a common scenario, a user managing a building site
with two control
units operating in an existing BAS wants to add a third control unit in a
newly constructed wing
of the building. The user must upgrade the existing control units to the new
version of the third
control unit in order for the system to be compliant because the system cannot
accommodate
multiple versions or integrate the new control unit.
Returning to the book analogy, then, when updates to chapters in the book are
necessary,
or when whole new chapters are added, the entire book must be returned to the
original author to
be rewritten and subsequently professionally rebound. Any dictionaries must
also be updated
accordingly and manual translations repeated. Updates and additions are
therefore labor-
intensive and time-consuming to accomplish.
Existing BASs also do not offer the accessibility, customization, and
management tools
desired by system users. Current BASs are difficult and communicatively
cumbersome to
manage on a large scale, such as by a regional or nationwide retailer or other
organization.
Further, while Internet-based and accessible systems are presently available
and in use, these
systems suffer from several drawbacks. Many current Internet BASs were created
as add-ons to
existing BASs and thus have integrated and proprietary designs. These systems
do not offer the
adaptability and extensibility necessary to interface with non-native systems
and sub-systems, a
particular issue with respect to large-scale systems implemented in existing
structures. Existing
system also do not provide higher-level extensibility, configurability, and
customization tools.
More recently, ASHRAE has released an XML and BACIIetTM web services interface
specification. According to ASHRAE, the interface is intended to be
communication protocol
neutral in that defined web services can be used with any underlying protocol.
This approach is
a least common denominator 'approach that can span multiple BACnetTM version
specifications,
wherein BAS services are supported by the intrinsic functionality of the
protocol. This
approach, however, still requires a gateway or translation to normalize
special or proprietary
functions and also requires translation or normalization between protocols
rather than more
smoothly running each protocol natively. Further, while the functions can be
translated or
normalized, data is often not given complete semantic meaning or context. In
other words, while
least common denominator systems can recognize data as red, blue, or green,
these systems
cannot recognize shades of these colors, and data loses some level of meaning
when generalized
to only the primary color.
For these and other reasons, a need remains for an intelligent BAS having a
flexible and
dynamic architecture and providing increased communication, management, and
control options,
particularly from a user perspective.
3
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
SUMMARY OF THE INVENTION
The present invention substantially addresses the aforementioned needs and
relates to
data management techniques and systems for building automation system (BAS)
architectures,
communications, and configurations.
In one embodiment, a BAS comprises a database and a relational directory. The
database
is adapted to store data definitions. The relational directory includes data
definitions for the
BAS, stored in the database, and includes a site level, a system level, a
device level, and an
extension level organized in a hierarchical relationship in the database. The
site level comprises
at least one site definition including a site description and a site
management description,
wherein the site description relates a site with at least one portion of the
BAS, and wherein the
site management description defines at least one site operation. The system
level comprises at
least one system definition, wherein the system definition describes an
association of a system
with a site and an interaction of the system with at least one device
comprising a portion of the
BAS. The device level comprises at least one device definition, wherein the
device definition
relates a device with at least one site recognized by the BAS. The extension
level comprises at
least one extension definition, wherein each extension definition is
associated with a device and
defines an association of a device with at least one of a system, a site, or
another device.
In another embodiment, a BAS comprises a database, a relational directory of
data
definitions for the BAS, and a server engine. The database is adapted to store
data definitions.
The relational directory includes at least one site definition comprising a
description of a site, the
site comprising at least a portion of the BAS, and at least one device
definition describing an
association of a device with the site, the at least one device comprising at
least a portion of the
BAS. The server engine is communicatively coupled to the database and is
adapted to manage
the relational directory by hierarchically organizing the at least one site
definition and the at least
one device definition within the relational directory.
The above summary of the invention is not intended to describe each
illustrated
embodiment or every implementation of the present invention. The figures and
the detailed
description that follow more particularly exemplify these embodiments.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention may be more completely understood in consideration of the
following
detailed description of various embodiments of the invention in connection
with the
accompanying drawings, in which:
4
CA 02620071 2014-03-04
FIG. 1 is a building automation system (BAS) according to one embodiment of
the
invention.
FIG, 2 is an object diagram according to one embodiment of the invention.
FIG. 3 is an architecture block diagram according to one embodiment of the
invention,
FIG. 4 is a data model block diagram according to one embodiment of the
invention.
FIG, 5 is a data model block diagram according to one embodiment of the
invention.
FIG, 6 is a data model example diagram according to one embodiment of the
invention.
FIG, 7 is a dynamic protocol support diagram according to one embodiment of
the
invention.
FIG. 8 is a site synchronization process flowchart according to one embodiment
of the
invention.
FIG, 9 is an outside object data block diagram according to one embodiment of
the
invention.
FIG, 10 is a data block diagram according to one embodiment of the invention.
FIG. 11 is a flowchart according to one embodiment of the invention.
FIG. 12 is an alarm block diagram according to one embodiment of the
invention.
While the invention is amenable to various modifications and alternative
forms, specifics
thereof have been shown by way of example in the drawings and will be
described in detail. It
'should be understood, however, that the intention is not to limit the
invention to the particular
embodiments described. On the contrary, the intention is to cover all
modifications, equivalents,
and alternatives falling within the scope of the invention as defined by the
appended
claims.
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
DETAILED DESCRIPTION OF THE INVENTION
The systems and methods of the invention can effectively prioritize and manage
data and
information within a locally or widely distributed building automation system
(BAS), from a
space or building level to an enterprise level, encompassing virtually any
structure, cluster,
campus, and area in between. The systems and methods are particularly suited
for a dynamically
extensible and automatically configurable BAS and architecture. The invention
can be more
readily understood by reference to FIGS. 1-12 and the following description.
While the
invention is not necessarily limited to the specifically depicted
application(s), the invention will
be better appreciated using a discussion of exemplary embodiments in specific
contexts.
The BAS is an automatically and intelligently scalable object-oriented system
in one
embodiment, providing multi-site management capabilities in a local or widely
distributed
geographic area. In one embodiment of the present invention, a BAS
architecture is anchored by
an enterprise server engine (ESE). The BAS and ESE comprise a versatile and
robust processor-
based control system with a communications protocol-agnostic head-end that
operably supports
the management of HVAC and other subsystems in one or more buildings from a
central location
internal to or remote from any of the buildings. The BAS is preferably
networked for user
accessibility. In one embodiment, the BAS is user-accessible via either or
both a computer
system on an Intranet or the Internet as a web-enabled application running on
a web server. The
web and network applications provide operational services for HVAC and other
subsystems.
In one embodiment, the BAS is capable of supporting and integrating legacy,
current, and
next generation components and subsystems. The BAS is further able to support
common
vendor or manufacturer systems as well as competitor systems by intelligently
identifying the
systems and/or subsystems and facilitating integration into the dynamically
extensible BAS
architecture. This flexibility enables the BAS architecture to support added
applications and new
control panel and subsystem types and versions without recompilation and
reissue, and to extend,
customize, and tailor the BAS to specific needs in a particular
implementation. Further, dynamic
extensibility enables a complex system to provide enhanced versatility and
usability.
Returning to the aforementioned book analogy, the BAS of the present invention
is a
library of books, rather than a single, inflexible, permanently bound book as
in the prior art.
Each end device of the BAS of the invention brings its own book to the
library. Each book is not
bound but is rather loose-leaf, easily able to accept additions or revisions.
A reader therefore
does not need to rely on a single, large, inflexibly bound book that must
repeatedly be rewritten
and rebound to accommodate update or additions and that comprises chapters in
multiple
languages requiring translation according to a potentially limited dictionary
or by a manual
6
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
translator. Instead, the library includes a multi-lingual librarian (the ESE)
to access individual
books as needed, wherein the books are always up-to-date. As new books are
added to the
library, existing books are automatically updated by the librarian to
incorporate information
gleaned from the newer material. Further, the library includes a card catalog
that not only
describes the individual books but references interrelations and similarities
among multiple
books in the library. The card catalog is also automatically updated as new
books are added to
the library. The BAS of the invention essentially creates an automated
librarian who can consult
an individual book, speak any necessary language, and learn new languages on
the fly, as
needed. This way the BAS of the invention can be thought of as an infinite or
universal Turing
machine, whereas previous BASs can only be classified as finite machines.
Referring to FIG. 1, a BAS 10 according to one embodiment of the invention
comprises
an ESE 20 preferably located at a central location 12, such as a headquarters
or control station.
ESE 20 comprises a single local device in one embodiment. In another
embodiment, ESE 20
comprises a multiple server configuration operating in a local or distributed
environment. ESE
20 may also comprise other single, multiple, and/or networked computers or
microprocessors;
single or multiple servers; hardware; software; firmware; software and
software instructions
comprising firmware; and/or any other combination of computing and storage
means, and
programming means, for establishing communications with and for controlling
distributed points
and devices within BAS 10, for selectively implementing a dynamic
extensibility capability and
an automatic configuration capability, and for accepting, storing, caching,
searching for,
requesting, serving, and/or loading data and information, as described in more
detail below.
ESE 20 is preferably locally networked at location 12 and communicatively
coupled to
the Internet 30, Intranet 30, and/or any other compatible communication means
for
communicatively coupling ESE 20 with one or more other points or devices
within BAS 10 and
for facilitating a dynamic extensibility capability and an automatic
configuration capability. ESE
20, via communication means such as the Internet 30 and/or Intranet 20,
therefore can provide
access and management control from virtually any location via a computer
system, internal or
external to a user's computer system. ESE 20 and BAS 10 need not be web-based
or
communicatively coupled to the Internet 30 as shown in FIG. 1, as other
compatible
communication means and options known to those skilled in the art exist.
Communication
means such as the Internet 30 and/or Intranet Ethemet/IP 32 or another local
area network (LAN)
or wide area network (WAN) facilitate communications between ESE 20 and other
system
components and devices. Some or all communications and connections may be
either wired or
wireless within portions of BAS 10 as needed or desired.
7
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
Each implementation of BAS 10 can vary substantially by size, composition of
devices,
and balance of present, legacy, and future generation devices. BAS 10 can also
vary by
vendor/manufacturer, type, physical layout of building and/or campus, user
needs, and other
characteristics. Therefore, each implementation of BAS 10 and ESE 20 in
particular is done on a
site-by-site basis in one embodiment. ESE 20 can recognize, communicate with,
and control a
variety of system devices, including present generation and common
manufacturer, legacy or
previous generation, and competitor controllers and building automation
panels. BAS 10, via
ESE 20, can also expand to integrate next-generation devices. Accordingly, ESE
20 comprises
microprocessor, computing, storage, and/or other compatible means for
accepting and storing
data and metadata descriptors from BAS 10 points, and microprocessor,
computing, storage,
and/or other compatible means for automatically requesting supplemental
manually programmed
data and descriptors if metadata descriptors are unavailable. Data and
metadata descriptors
within BAS 10 are described in more detail below.
As depicted in FIG. 1, for example, a present generation supervisory
controller 41, such
as a Building Control Unit manufactured by TRANE , the assignee of the present
application, or
a panel 40, can be directly communicatively coupled to the Internet 30 and/or
Intranet 32, while
legacy unit(s) 42 can be directly communicatively coupled to the Internet 30
and/or Intranet 32
or coupled via a media converter 48. Legacy unit(s) 42 can include, for
example, TRACER
SUMMIT and TRACKER units manufactured by TRANE , the assignee of the present
application. Media converter 48 is preferably a simple translator but may also
comprise other
more sophisticated devices as needed. Media converter 48 is preferably not but
may also be used
with competitive product(s) 44 and/or future product(s) 46 in various
embodiments. Competitive
products 44 are also preferably directly coupled to the Internet 30 and/or
Intranet 32. The term
"competitive" is used to generally refer to products manufactured by an
outside organization
with respect to ESE 20. Manufacturers of building comfort and control products
and systems
that may comprise competitive product(s) 44 include JOHNSON CONTROLS,
HONEYWELL,
TRIDIUM, YORK, GENERAL ELECTRIC, CARRIER, and others.
ESE 20 is further able to support future product(s) 46, such as updated
versions of current
controllers, newly developed products, and the like. Preferably, at least a
plurality of panels 40,
present controllers 41, legacy units 42, competitive products 44 or future
products 46 are
building automation, control or HVAC products, representative examples of
which include:
furnaces and heating systems; chillers, including mechanical and absorption;
air conditioners,
filters, and air purifiers; fire and life safety systems; security systems;
electrical system monitors
and controllers; lighting system monitors and controllers; ventilation system
monitors and
8
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
controllers; sensors, including smoke, light, occupancy, motion, humidity, and
others; pumps; air
handlers; fluid and air moving and handling equipment; terminal products and
devices; life
science and pharmacological control equipment and monitoring systems,
including positive and
negative pressure clean rooms; industrial automation and control equipment and
systems;
programmable logic controllers; and others. ESE 20 is also preferably able to
coexist and
cooperate with other similar but previous generation control and management
systems, as will be
described in more detail below.
Panel 40, supervisory controller 41, legacy units 42, competitive products 44,
and future
products 46 may be generally referred to herein as BAS end devices. In
accordance with the
descriptions herein of panels 40, supervisory controllers 41, legacy units 42,
competitive
products 44, and future products 46, BAS end devices can comprise input/output
points, binary
and analog devices, embedded controllers, sensors, and any other
control/sensor means for
measuring and communicating data about at least one of a point, a device, a
space, a system, or a
subsystem for at least a portion of a building or campus the like. The term
"end devices" is used
only as a convenient, generalized reference to points within BAS 10, and the
context of the term
"end" in particular is not intended to be limiting or to imply a point of
communicative or control
termination in any given instance from the perspective of BAS 10. For example,
end devices
such as supervisory controllers 41 can function as intermediaries between ESE
20 and additional
end device-side equipment.
Further, BAS 10 can comprise non-real end devices, or points, and virtual end
devices. A
non-real end device, in one embodiment, is a representation of a real, actual,
or physical end
device instantiated by ESE 20 and associated with or related to one or more
actual, real, or
physical BAS end devices. A real end device is an end device as depicted and
described herein
throughout, the term "real" used only to describe an end device relative to an
instantiated "non-
real" end device, as will be understood by those skilled in the art. Non-real
end devices can be
derived and instantiated by ESE 20 from algorithmic relationships among at
least a plurality of
real end devices, or end device points or values. One example of a non-real
end device or point
is a building efficiency. Building efficiency is related to both input and
output characteristics of
BAS end devices and BAS 10 equipment. Other examples include or are related to
set points
and comfort settings. ESE 20 is adapted to automatically update or redefine
the non-real end
devices in accordance with the dynamic extensibility and automatic
configurability of BAS 10.
BAS 10 can also treat a particular BAS end device differently for different
applications,
creating a virtual end device. A virtual end device is a custom or otherwise
altered definition or
treatment of an actual, real, or physical BAS end device. An actual end device
is an end device
9
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
as depicted and described herein throughout, the term "actual" used only to
describe an end
device relative to a "virtual" end device, as will be understood by those
skilled in the art. For
context or convenience, user might select that an end device be presented as a
first type, while
BAS 10 operates and communicates with an end device that comprises, in
reality, a second type.
To satisfy the user, to permit the user to view and interact with the end
device as an end device
the user is comfortable with, or for the sake of a consistent interface, BAS
10 can present the end
device to the user as a virtual end device of the first type even though the
end device is actually
implemented and controlled by BAS 10 as the second type. A user accesses and
interacts with
BAS 10 through a graphical user interface (GUI or "user interface") presented
on one or more
computer devices 22 in one embodiment. Each device 22 is communicatively
coupled with BAS
10. The user interface of BAS 10 may be provided by virtually any device 22
with a visual
display and a communicative connection to system 10. Some examples of such
devices are a
personal desktop, laptop, or portable computer (PC); a portable digital
assistant (PDA); a cellular
phone; and other similar devices. Typically, the connection between device 22
and BAS 10 is
provided by the Internet 30, an Intranet system 32, and/or some other local or
wide area
communickion network, although other means of connection and combinations of
connections
are also possible. For example, if an Internet-enabled cellular phone is used,
the connection
comprises, at least in part, a wireless cellular communication network.
Each BAS end device 40, 31, 42, 44, and 46 is modeled as an object in the
context of
BAS 10 of the invention. In object-oriented BAS 10 and ESE 20, efficiencies
are achieved by
modeling common objects for recognition and application to other similar
objects. An object,
simply put, is an instance of a class, or an encapsulation of descriptive
behaviors and
functionality of a group. A general object can then be made specific based
upon rules applied to
the object. Referring to BAS 10, an end device object may encompass virtually
any type or
piece of equipment, or any input or output point, in BAS 10, as well as any
application or data
structure relevant to BAS 10.
BAS 10 is able to reduce manual programming and integration of new devices by
taking
an object-oriented approach to system devices and components. BAS 10 is
further able to
identify and call attention to objects and object-related events that are not
recognized such that
manual service and attention can be delivered. Object orientation of data and
metadata
management within BAS 10 supports dynamic extension and automatic
configuration of BAS
10, including the components and architecture of BAS 10 and informational and
managerial
representations of the structure and status of BAS 10 in the user interface.
Dynamic extension
and automatic configuration create a circularly recursive system with the self-
descriptive objects
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
and system use of plastic and extensible metadata from and about the objects.
BAS 10 metadata
is therefore multi-level, redirectable, and extensible in one embodiment.
Further, the dynamic
extensibility of BAS 10 enables a user to utilize the user interface to
customize and control BAS
10, including the user interface itself, without the need for reprogramming or
recompiling code.
Accordingly, FIG. 2 is a diagram of an operating architecture of BAS 10
according to one
embodiment. In dynamically extensible and scalable BAS 10, objects exist in a
hierarchical or
class structure. For example, data objects, site objects, and panel objects
are interrelated and can
be relatively defined, with the objects including or associated with
respective object definitions
58, such as type, version, vendor, and the like, that are stored in a database
60 and interpreted by
BAS 10 within an application engine/framework 62 with ESE 20 to determine how
the particular
object is to be handled by BAS 10. Internal meta-object management 50, data
object
management 52, site management 54, and panel and communications management 56,
with
object definitions 58, represent the kernel of ESE 20 of BAS 10 and interface
application
engine/framework 62 with external sources and entities to manage objects
within BAS 10. The
kernel preferably comprises the p-code engine and is extensible. Application
engine/framework
62 with database 60 and ASP.NET applications 64 comprise graphical user
interface element
representations within an operating architecture of ESE 20. Database 60 is a
data store or sequel
server external to a graphical user interface program in one embodiment. A web
server 66 then
interfaces BAS 10 via application engine/framework 62 to an external
interface. In one preferred
but non-exclusive embodiment, the external interface comprises a GUI presented
via an Internet
30 or intranet 32 system using a web browser program. Web server 66 and web
browser 68 in
FIG. 2 are not client-side web server and web browser software elements but
rather
representations of ESE 20 operational architecture components.
The core engine, or ESE 20 in the embodiment of FIG. 1, forms a foundation or
platform
for BAS 10. Referring to FIG. 3, ESE 20 supports the operating architecture Of
BAS 10,
including applications 150 and user interface 160 within BAS 10. ESE 20 within
the system
architecture further defines and describes the whole of the engine support.
The main objects and classifications used by BAS 10 in one embodiment are
shown in
FIG. 4 with reference to FIG. 2. Data object management 52 includes a data
manager web
engine 100 and object management 101. Data manager web engine 100 includes a
data request
manager 102 and a data request object 104. Data request manager 102 is an
object for managing
incoming XML requests, and for creating data request objects 104, associated
data objects 120,
and the associated URL and identification for outside clients to use as a
reference. Data request
manager 102 is also a cache for data request object 104 and data object 120
from the user
11
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
interface and/or any client. Data request object 104 is an object that
contains a collection of read
requests. Object management 101 includes data object 120 and smart value 126.
Data object
120 is an object that encapsulates one or more objects that exist in each
panel, including both
equipment and application objects. Smart value 126 is an object that
encapsulates the properties
that exist in the data objects and is responsible for encoding/decoding raw
data into and out of
any external format and for performing conversions, if needed.
Site management 54 includes a site manager 108 and site 110. Site manager 108
is an
object responsible for managing all sites 110, starting, adding, and
operations that transcend
sites. Site 110 is an object that is central for interacting with a building,
which includes at least
one individual panel object 112. In one embodiment, a building is seen as a
site 110 by ESE 20.
A particular site 110, however, can be an individual building or a campus of
more than one
building. Conversely, a single building can include more than one site 110.
Referring again to FIG. 1, for example, panel 40, supervisory controller 41,
legacy unit(s)
42, competitive product(s) 44, and future product(s) 46 together may comprise
a single site 110,
or some or each of panel 40, supervisory controller 41, legacy unit(s) 42,
competitive product(s)
44, and future product(s) 46 may be located at more than one distinct site
110. ESE 20 in BAS
can default to a single building, single site view in one embodiment, which
can then be
customized or altered according to a user preference or a system
characteristic or discovery data.
In one particular example, a manufacturing facility includes a first user- and
system-defined site
110 consisting of a front office area and a second user- and system-defined
site 110 consisting of
the manufacturing floor. This plural site definition can make it more
convenient and intuitive
from a facility perspective to manage disparate spaces.
Meta-object management 50 includes a metadata manager 114, an objection
definition
122, and a property definition 128. Metadata manager 114 is an object for
parsing in metadata
XML files and managing metadata definitions and is preferably cached by panel
type, version,
and object type in one embodiment. Object definition 122 is a metadata object
that defines the
properties, services, and behaviors of data object(s) 120. Property definition
128 is a metadata
object that defines the attributes and behaviors for the properties of an
object.
Panel and communication management 56 includes communication manager 116,
panel
112, protocol stack 118 and protocol data unit (PDU) 124. Communication
manager 116 is an
object responsible for managing all the communication ports, threads, and
protocol stacks. Panel
object 112 is an object that represents the physical panel(s) and manages the
version of metadata
to use and services available for the protocol stack. PDU 124 is an object
responsible for an
encoding/decoding algorithm for the properties over the communication wire.
12
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
The main data entities are depicted in FIG. 5, and a related example is
depicted in FIG. 6.
At a very basic level, each site 110 is a collection of one or more panels 112
(panel objects), and
each panel 112 is a collection of one or more objects, which may need
extensions 130 for system
operability. Site 110 can be an individual site, i.e., building, or a list of
sites managed by ESE
20. In the college campus example of FIG.. 6, sites 110 managed by ESE 20
include the various
buildings on campus, such as Engineering, Library, Administration, and others.
Sites 110 also
include information for background tasks.
Panel(s) 112 is a single panel 112 or a list of panels known for each site 110
and the
information needed by ESE 20 to manage those particular panels. This
information can include
panel type, version, vendor, and ignore flags in one embodiment. In the
college campus example
of FIG. 6, each site 110 includes a panel 112. A system controller-level
single panel 112 is
depicted for each site 110, although a single site 110 can include multiple
panels 112.
Object(s) 120 is a list of objects that exist in each panel 112 and is used
for navigation,
display, and management. In FIG. 6, each panel 112 includes a plurality of
objects 120, which
may be equipment, sensors, receivers, machines, and other devices.
Object extension(s) 130 is information kept on ESE 20 that is specific for
each object 120
as described by the metadata associated with each object 120. Object
extensions 130 are used to
drive a user interface for determining things such as to which family a
specific object belongs
when an object is in a different family by the object configuration.
ESE 20 operably reads and writes data in BAS end devices 40, 41, 42, 44, and
46
(referring again generally to system 10 of FIG. 1) that support building
automation standard
protocols. In the context of FIG. 1 and herein, BAS end devices 42, 44, and 46
can be panels but
are distinguished by type in FIG. 1 to illustrate possible configurations and
compositions of BAS
10. For example, ESE 20 and BAS 10 as a whole are generally compatible with
the BACnetTM
protocol and/or XML at a minimum, although physical or virtual media
converters 48 may also
be needed for particular devices in various embodiments. In one embodiment,
ESE 20 reads and
writes data based upon provided metadata and definitions, where data read from
BAS end
devices 40 and 41, for example, is BACnetTM protocol formatted. ESE 20
operably converts the
read data to XML for use in ESE 20 applications. ESE 20 therefore can
communicate with
panels supporting a BACnetTM protocol through syntax conversion while
concurrently
supporting XML, such as for next-generation panels capable of supporting XML
directly. In
accordance with the dynamically extensible and automatically configuration
architecture of BAS
10, ESE 20 utilizes self-describing plastic and extensible metadata to
establish communications
and support with BAS end devices 40, 41, 42, 44, and 46 and other elements of
BAS 10.
13
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
While ESE 20 is compatible with and/or configurable for a wide variety of
protocols
and standards, particular examples herein will refer to the BACnetTM protocol,
Internet 30, and
Intranet 32 systems where appropriate, in the context of one non-limiting
embodiment of the
invention.
ESE 20 is structured, in one embodiment, to integrate various implementations
of
BACnetTM and other protocols as natively as possible. ESE 20 can operably and
concurrently
support multiple versions and implementations, e.g., services supported and
proprietary
information. This enables ESE 20 to integrate both "inside," i.e., common
vendor/manufacturer
or platform, and "outside," i.e., other vendor or competitor, devices without
requiring manual
programming of the object. Referring to FIG. 7, a representative and example
dynamic protocol
support algorithm table 170 illustrates various "levels" of identification and
communication that
can be established with a BAS end device in BAS 10. For example, protocol
support table 170
includes at least one available protocol 172, or PROTOCOLa/ in FIG. 7.
PROTOCOLa/ may be
a BACnetTM protocol or another suitable protocol as previously described.
PROTOCOLa/ then
more specifically includes at least one vendor 174. VENDORO may be a default
vendor,
VENDOR1 may be ASHRAE, VENDOR2 may be TRANE , and so on, these particularly
vendors used only for one example. At least one product 176 may then be
associated with each
vendor 174, and each product 176 may include at least one type or version 178.
When
establishing communications with a BAS end device, then, ESE 20 preferably
obtains metadata
to identify the BAS end device as specifically as possible to establish higher
level
communications. If ESE 20 is able to identify a first BAS end device to a
vendor level 174 and
second BAS end device to a type level 170, for example, ESE 20 will be able to
establish higher
level communications with the second BAS end device because ESE 20 will have
more detailed
and specific information. Contrast this with current methods of integration of
outside BAS end
devices in other systems, which require time- and labor-intensive manual
programming of the
data and relationship by field service technicians unique to each
installation, adding to the cost
and complexity of these other systems and reducing convenience.
For each BAS end device and in accordance with the dynamic protocol support
algorithm
of FIG. 7, BAS end device synchronization tasks are then performed. Referring
to FIG. 8, step
181 is determining whether a BAS end device is new. If the device is new, step
182 is
determining whether the BAS end device is supported, i.e., is metadata
available. If yes,
appropriate metadata for the BAS end device is wired in; the list of supported
services for the
BAS end device is read; a BAS end device object is created, and internal
values are set and
stored in the database; and objects are uploaded from the BAS end device and
appropriate tables
14
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
are updated. At step 183, any unsynchronized objects are deleted and the
synchronized panel is
labelled as such and updated with the latest synchronization date/time at step
184.
Returning to step 182, if a BAS end device is not supported, the end device
state is set to
"metadata not available" at step 185 and process 180 returns to step 183.
Returning to step 181,
if a BAS end device is not new and, at step 186, the vendor or version of the
BAS end device has
not changed, objects are uploaded from the BAS end device and tables are
updated at step 187
before returning to step 183. If the BAS end device vendor or version is found
to have changed
at step 186, step 188 determines whether the BAS end device is supported. If
the BAS end
device is not supported, process 180 advances to step 185. If the BAS end
device is supported,
process 180 advances to step 189, wherein existing BAS end device information
(metadata) is
replaced with new or updated information. In one embodiment, this is
accomplished by making
a copy of a row in a device table and any associated rows in object and
object_extension tables.
Referring to FIG. 9, ESE 20 provides extensible support to outside object 202
according
to object data 204 and object metadata 206. In one embodiment, ESE 20
discovers object 202 at
a location. The discovery can be user-initiated, such as by providing a
network address of object
202 to ESE 20 via the user interface in one embodiment, or automatic on behalf
of ESE 20 in
another embodiment. To integrate object 202, ESE 20 utilizes object metadata
206 to obtain a
general description of object 202 based upon a communications implementation
of the outside
vendor of object 202. In one embodiment, object metadata 206 is data
description code about
object 202 and object data 204. The communications implementation may include,
for example,
a specific revision and version. ESE 20 of BAS 10 also accommodates changes in
BAS 10 over
time, including BAS end device additions, removal, or changes, including
changes to particular
points. ESE 20 further handles versioning and dynamics over time, in contrast
to other systems
that assume a homogenous system and protocol.
Upon discovery of object 202, ESE 20 determines all available information
relevant to
operation of object 202 in system 10, including status and setpoints, data
collection, alarming,
scheduling, and the like, to establish communications with object 202. ESE 20
is not dependent
on systems integration activities to program specific data and information;
rather, if the
information conforms to standard data structures, ESE 20 reads object data 204
directly from
object 202. In other words, system objects, including outside object 202, are
preferably self-
describing as discussed herein and are interrogated for object metadata 206
without
programming intervention, such as manual mapping of points. Any specific
context given to
data 204 according to the vendor of object 202 can be provided by input to ESE
20 without
recompilation of production code or field programming of logic.
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
ESE 20 operably provides an interface for system installation, setup,
integration, and
support. For example, ESE 20 provides an interface for BAS end devices 40, 41,
42, 44, and 46
setup parameters, including IP address, subnet mask, gateway, and name of
server for each,
where applicable. ESE 20 further provides a methodology and/or utility to set
up and customize
web pages, which can include both templates and individual pages, and to serve
and publish
graphics to web pages. System 10 and ESE 20 also allow user definition of
attributes for a given
site for grouping purposes. In one embodiment, at a minimum, each site 110 is
associated with a
geographical and a type attribute and a search function is provided to allow
users to search for
sites or groups of sites. ESE 20 further preferably accommodates the addition,
removal, and
general management of entire sites 110 within BAS 10.
ESE 20 efficiently handles data and information to enable operation of BAS 10
and
support external interactions with BAS 10. In particular, ESE 20 utilizes data
management
techniques to enhance communicative performance of BAS 10. In one embodiment,
ESE 20
minimizes communication and data transfer related burdens on system 10 and
components of
system 10 through data caching. The user interface of BAS 10 provides static
and dynamic
information regarding the status and operation of BAS 10. Dynamic, real-time
data from objects
in system 10 is presented in the user interface and can be updated according
to a defined refresh
rate or manually on-demand by a user. Unscheduled real-time data events can
also occur at any
time, for example as an alarm. BAS 10 can efficiently handle scheduled updates
and
presentation of dynamic real-time data in order to accommodate unscheduled
data requests and
events.
Referring to FIG. 10, ESE 20 and applications 150 implement refresh cache and
multi-
step delivery processes in one embodiment for responding to user interface
requests, including
HTTP requests for user interface web-based pages that represent the building
automation
equipment in system 10. These algorithms enable users to navigate through user
interface 160,
and request and view both static and dynamic data and information about BAS
10, with as
minimal an impact on performance as possible. The refresh cache and multi-step
delivery
processes implemented by ESE 20 remove the burden from the panels and objects
203, which
have much slower information communication performance characteristics. In
particular, panels
and objects 203 are typically embedded controllers with limited buffers. ESE
20 can sample and
refresh data to relieve panels and objects 203 and improve the performance of
BAS 10. A
refresh or reinitiation rate can be based upon a characteristic of BAS 10 or
of a portion of BAS
10. In one embodiment, a refresh rate is related to an end device (panels and
objects 203)
characteristic, such as a type, version, location, status, user preference,
availability, and the like.
16
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
A refresh rate can also be based upon the data characteristic, such as a data
type, a rate of
change, a metadata descriptor, a user preference or attribute, and the like.
The refresh rate may
be related to a user specification or a default set for BAS 10. The refresh
rate can also be based
upon a logical combination, synthesis, or amalgamation of one or more refresh
rates by ESE 20.
For example, an overall refresh or reinitiation rate for an end device may
conflict with the refresh
rate of a particular end device element or a refresh rate based on a data rate
of change. ESE 20
can resolve any such conflict, which in one embodiment will be to select the
most frequent
refresh rate. In other embodiments, the resolution may be a logical
combination, a system
default, or some other selection or combination of a refresh or reinitiation
rate or frequency.
Referring to FIGS. 10 and 11, applications 150 use object metadata 204 to
determine
object information and data 206 discovered from object 204 to be maintained in
database 60 in
one embodiment. ESE 20 then receives and stores data 206 in database 60.
According to
process 208, when a user requests a page related to object 203 in user
interface 160 at step 210,
applications 150 initiate two processes. In a first process, ESE 20 and
application 150 determine
the page and content based upon object metadata 204 and information 206 stored
in database 60
at step 212. A page is then returned to the user with the information
available from database 60
at step 214. The initial page returned can include static information related
to object 203, BAS
in general, or some other object or information.
Concurrent to steps 212 and 214, to obtain the dynamic, real-time, or other
information
for the requested page that is only available directly from the panel, a read
request is generated
and processed to go over the wire to the panel at step 216. Due to the typical
performance
constraints of the specific panels, a read request may take some time to be
returned to the user
interface page and the information made available to the user. Accordingly,
the page initially
displayed at step 214 includes as much static and dynamic information as is
available, typically
that from the database received at step 212 and initial but incomplete
responses from the panel at
step 218. In one embodiment, the user interface page automatically and
periodically refreshes at
step 222 to provide additional dynamic information as it becomes available
from the panels at
step 218 until the page is complete at step 220.
To reduce the performance impact on BAS 10 of a user navigating off the
requested page
and then returning, which would require repetition of steps 210-220, ESE 20
can maintain the
page, complete or otherwise, in cache memory at step 224. In addition to
caching the page itself,
ESE 20 can also cache the dynamic input/output data received from the BAS end
devices at step
218. ESE 20 can periodically refresh the dynamic data for the page for a
period of time, even if
the page is not currently requested or viewed. The cache also handles
situations in which a
17
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
single object is relevant to multiple pages. Data associated with that object
can be requested for
a first page, then cached and accessed as necessary from the cache to load
subsequent pages that
include the some or all of the same data. A cache session can correspond to a
user session in one
embodiment. In other embodiments, cache session maintenance can be time,
object, or system
related,
ESE 20 implements a dual-stage periodic refresh in one embodiment of the
invention. A
first stage is a system (BAS 10) stage and comprises three refresh levels in
one embodiment. A
first level is a one-time refresh. A one-time refresh typically occurs only a
single time, such as
when a page is first requested and loaded. Data having a one-time refresh
metadata descriptor or
tag includes configuration data, for example. A second level is permanent
expiration. Some
page data and content expires immediately upon request and load because the
data is live and
real-time, such as a current temperature. Permanent expiration metadata tagged
data and content
is refreshed each time a page is requested or loaded, the finest refresh
granularity. A third
refresh level is intermediate the one-time refresh and the permanent
expiration and is periodic
expiration. Some content, including some real-time data, changes at a slow
rate, making
permanent expiration inappropriate. A periodic expiration may be refreshed,
for example, every
ten minutes in one embodiment. Other periods may also be set or may vary
according to a
metadata descriptor or tag, system-wide setting, or other criteria in other
embodiments.
In one embodiment, the cache is transaction-based, keeping the page for a
fixed period,
for example about fifteen minutes, as long as page hits continue. If a user
returns to the page
within the period of time, the page and its data are still available and could
be immediately
presented in user interface 160, instead of having to repeat the BAS end
device read request of
step 216 and wait for the complete response at step 218.
In another embodiment, the cache is location-based, which is a variation on
aging. In a
location-based cache, ESE 20 will effect a proactive data fetch time-stamp
configured based
upon a particular location. ESE 20 utilizes object metadata 204 to determine
when data for that
object (location) is expired. While the entire page is periodically refreshed
according to this
scheme, the burden on the object (BAS end device) is reduced because ESE 20
only read
requests the data on the page that has expired or that is changing more
frequently according to
metadata BAS end devices, which may begin to drop commands if barraged with
read requests,
rather than treating the BAS end devices as servers of data within system 10
from the perspective
of user interface 160.
Site management of ESE 20 is an important aspect of BAS 10 from an
implementation
perspective. Dynamic extensions, enhancements, and changes are intended to be
natural,
18
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
fundamental features of building automation system 10. Further, ESE 20, as a
core engine of
BAS 10, is designed to be used as the foundation for other systems and
devices, including next-
generation developments. Each implementation of ESE 20 and BAS 10 is designed
to keep site
and data management services separate from user interface 160 and applications
150 to ensure
that the core engine aspect is not compromised by building ESE 20 and user
interface 160 in
separate modules.
Data management services, user interface 160, and applications 150, however,
intersect
and cooperate in the ordinary operation of BAS 10 and ESE 20. For example, an
important
aspect of system 10 and ESE 20 is related to alarming. Referring to FIG. 12,
system 10 and
various objects 203 therein will, by their very function and purpose,
occasionally or
systematically generate alarms 250. Alarms 250 may be related to an operating
state of object
203, a service need status, a detected object or system characteristic, or
some other indicator or
condition. ESE 20 and alarm applications 252 operably receive alarms 250 from
objects 203
and, according to the invention, triage, manage, or otherwise appropriately
handle alarms 250.
ESE 20 can also store or archive alarms 250 and display an alarm log in user
interface 160.
In one embodiment, relevant to alarm triage, ESE 20 can automatically analyze
alarm
250 to notify and/or request service or otherwise ensure that the alarm will
receive the attention
it warrants. Alarm triage, sorting, and filtering can be provided based upon
an alarm and/or site
attribute and alarm rules 254. By way of example, it can be appreciated that
an alarm 250
related to a particular area or object 203 within a facility can a much
greater significance than an
alarm related to another area within the same facility. Similarly, one type of
alarm may require a
more rapid response than another type of alarm. Therefore, ESE 20 can
automatically assess an
incoming alarm according to alarm rules 254 related to an alarm type, source,
and/or relevant
object attribute and then handle alarm 250 appropriately.
For example, ESE 20 can forward a higher priority alarm via email 256 after
ascertaining
the relative importance of the alarm indicator according to alarm rules 254.
Within system 10,
alarm forwarding via email is a user interface 160 customization feature
implemented as an
administrative function and enables a user to specify to whom or what the
notification should be
sent. ESE 20 can also simply catalog lower priority alarms for later review by
a user in a
viewable alarm log.
ESE 20 provides alarm message assessment and diagnostics with respect to
alarms
received from within system 10 to develop alarm triage algorithms 256.
Algorithms 256 can be
developed in compliance with rules 254 and applied to match alarm patterns and
analyze alarm
timings in future events and consolidate messages or provide automated
actions. ESE 20 can
19
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
then intelligently identify patterns, sequences, and/or occurrences of alarms
250 to diagnose a
common source and respond appropriately and automatically. Preferred
embodiments of ESE 20
can identify, sort, sequence, and trend alarms 250 in order to identify a
common link, if any, and
reduce the number of alarm notifications 256 sent to a user for manual
attention.
For example, a loss of power for a given circuit in a building can create
multiple
diagnostics. ESE 20 can assess the pattern of diagnostics within BAS 10 and
report only the loss
of power and not the redundant and source-related alarm messages. ESE 20 can
also send only a
single alarm notice 256 including information about the common fault to a user
in a user-
identifiable format. Rather than sending a plurality of alarm notices 256 or
complex system-
driven information, ESE 20 can report the identified common fault in user-
identifiable and
defined terms for context. The user can then deal with the single source of
the alarms
expeditiously, rather than attempting to clear each of the plurality of alarm
notices.
ESE 20 can also maintain one or more alarm logs 258 and can catalog or archive
alarms
in an appropriate log 258. A user can then review log 258 and acknowledge or
delete the alarms
as desired. ESE 20 can also automatically and periodically purge alarm log(s)
258 as needed or
as defined by a user or administrator of BAS 10. Alarms are typically time-
stamp recorded
and/or sorted by some characteristic, such as object or type.
In one embodiment, alarms 250 are preferably received and handled by ESE 20 in
real
time. In another embodiment, such as one incorporating legacy panels and
devices, ESE 20
optionally collects alarms 250 from objects on a periodic basis, such as
hourly, daily, or more or
less frequently.
In addition to automatically handling and triaging alarms, BAS 10 and more
particularly
ESE 20 can trend alarms and other data. Trending within BAS 10 is an intuitive
and efficient
management and diagnostic tool. In one embodiment, trend data is collected by
ESE 20 from
one or more objects 40, 42, 44, and/or 46 at a maximum frequency of once per
minute or at
another lower frequency or on a specific scheduled basis as defined by a user
or administrator.
Trend data can then be stored in a database and, in one embodiment, is
available for sharing with
network peers.
Building automation system 10 is therefore an object-oriented system designed
with
algorithms that work with self-describing panels 40 or objects. Algorithms
implemented as part
of BAS 10 communicate with objects to determine whether the objects are
operating with
algorithms by which they can be identified and integrated. If BAS 10 cannot
determine whether
an object is operating with an algorithm, BAS 10 intelligently and
automatically defines the
object as an exception. Building automation system 10 is universally self-
describing in that BAS
CA 02620071 2008-02-21
WO 2007/024622
PCT/US2006/032141
applies concepts and captures algorithms based on object self-descriptions.
The algorithms
are then translated to accomplish associated mechanical aspects of the objects
and BAS 10.
The present invention further provides the ability to alter definitions of
objects in ESE 20
without having to recompile the production code. This provides for ease of
maintenance and
product support. Altered or updated definitions can then be input files to ESE
20, and complete
or more complex updates can be made separately. Contrast this update process
of the present
invention with current methods, in which in order to get an update to object
definitions to the end
user or customer, production code needs to be rebuilt, tested, and updated for
an installation.
This increases the amount of time required by an on-site technician and the
risk of failed
installations.
In one embodiment, a building automation system (BAS) according to the
invention
comprises a plurality of end devices each associated with at least one of a
space, a system, or a
subsystem for at least a portion of a building or a campus; at least one
communication network
communicatively coupling at least a portion of the plurality of end devices
and supporting a
plurality of communication protocols; and a protocol-independent server engine
communicatively coupled to the at least one communication network. The server
engine
includes programming means for selectively implementing a dynamic
extensibility capa.bility for
the BAS that establishes communications with and control of the plurality of
end devices over
the plurality of communication protocols; and programming means for
selectively implementing
an automatic configuration capability for the BAS that supports addition of
end devices to the
plurality of end devices by determining at least one characteristic of each
end device, the at least
one characteristic being selected from the set consisting of a self-describing
status and a non-
self-describing status. For an end device having a self-describing status, the
server engine
includes programming means for accepting and storing data and metadata
descriptors
communicated from the end device. For an end device having a non-self-
describing status, the
server engine includes programming means for searching a database of data and
metadata
descriptors for end devices maintained by the server engine for data and
metadata descriptors
based on the non-self-describing status of the end device and automatically
requesting
supplemental manually programmed data and metadata descriptors for the end
device if the non-
self-describing status of the device is not sufficient to retrieve data and
metadata descriptors for
the end device from the database.
In another embodiment, a method of establishing communications with unknown
end
devices in a building automation system (BAS) based upon metadata descriptors
provided by
known and unknown end devices comprises discovering an unknown end device on a
21
CA 02620071 2014-03-04
communication network, the unknown end device associated with at least one of
a point, a space,
a system, or a subsystem for at least a portion of a building or campus. The
unknown end device
is queried for a communication protocol metadata descriptor and classified as
a self-describing
end device if the unknown end device provides a communication protocol
metadata descriptor in
response to the query and selecting a communication protocol that corresponds
to the
communication protocol metadata descriptor for the unknown end device. The
unknown end
device is classified as a non-self-describing end device if the unknown end
device does not
provide a communication protocol metadata descriptor in response to the query
and
automatically requesting supplemental manually programmed communication
protocol
descriptors.
The scope of the claims should not be limited by particular embodiments set
forth herein,
but should be construed in a manner consistent with the specification as a
whole.
22
