United States Patent [19]
`French et a1.
`
`[11] Patent Number:
`[45] Date of Patent:
`
`5,061,916
`Oct. 29, 1991
`
`[54] EVENT DRIVEN REMOTE GRAPHICAL
`REPORTING OF BUILDING AUTOMATION
`SYSTEM PARAMETERS ’
`
`[75] Inventors: Jonathan C. French, Rockford, 111.;
`David R. Rounds, Beloit, Wis; James
`R. Herdeman, Rockford; Brent S.
`Bernardi, Loves Park, both of I11.
`
`[73] Assignee: Barber-Colman Company, Rockford,
`
`Ill.
`
`'
`
`[21] Appl. No.: 529,945
`
`[22] Filed:
`
`May 29, 1990
`
`[51] Int. Cl.5 ....................... .. G08B 19/00; GOSB l/OO
`[52] US. Cl. .................................. .. 340/522; 340/506;
`340/525; 340/531; 358/400; 358/441; 358/442;
`364/550; 379/100
`[58] Field of Search ............. .. 340/522, 506, 525, 531;
`358/108, 400, 441, 442; 364/141, 138, 550;
`379/ 100
`
`[56]
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`4,644,478 2/1987 Stephens et al. .................. .. 340/506
`4,933,667 6/1990 Shaw et al. .... ..
`340/525
`4,977,390 12/1990 Saylor et al.
`340/506
`4,991,200 2/1991 Lin .................................... .. 358/441
`
`OTHER PUBLICATIONS
`Brochure entitled “Network 8000 System Overview”, .
`May 1989.
`“New Controls Gear Highlights Atlanta HVAC Expo
`sition”, Energy User News, Feb. 1990,
`Data Sheet on the Quadram JT-FAX9600.
`Primary Examiner-Donnie L. Crosland
`Attorney, Agent, or Firm—Leydig, Volt & Mayer
`[57]
`ABSTRACT
`A system and method for reporting of alarms (or other
`conditions) to a remote location, in a building automa
`tion system. The alarm is reported in graphical format
`which shows not only the information related directly
`to the alarm, but also additional information, including
`graphical information, intended to put the alarm in
`context. The system provides the user the ability to
`specify a transmittable alarm, and to de?ne a graphical
`message for that alarm which includes ?xed or static
`building parameters associated with real time building
`operating parameters. Upon occurrence of an alarm
`condition, the system assembles a graphical display for
`transmission which includes the speci?ed ?xed parame
`ters and measured data for the real time operating pa
`rameters. The system assures that data is collected and
`assembled into the graphic display for all speci?ed real
`time operating parameters, then initiates a facsimile
`transmission of the graphic display to a remote location.
`
`15 Claims, 4 Drawing Sheets
`
`[— —CE_i-\1-TF;;L— ?
`l
`P20
`CONTROL
`l
`l
`I
`‘
`
`‘22
`
`L“
`
`“E e
`
`K 32
`
`if
`GLOBAL "\30a
`CONTROL
`MODULE
`
`\
`
`\f
`GCM
`
`__
`30*’
`
`r
`
`l
`3on4 GCM
`
`T
`
`J
`
`35--< 12>
`:17- — 383-- _-46; |-——
`"’
`LOCAL
`,_ II
`153 CONTROL
`L MFLO
`9
`‘a, MODULE
`n; ——1
`441 1'_‘ w I
`:%
`LCM
`gMZONE m. ||
`
`-
`
`05
`
`‘I
`'
`
`GLOBAL £ONTROILI_\I_ET_WOLK__ __ _ _
`'1 I'-
`__|
`I
`|
`|
`I
`I
`|
`|
`l
`|
`|
`l
`I
`
`'
`'
`
`'
`'
`
`In:
`8
`I
`\
`| 39
`I
`
`FACILITY 1
`.312
`
`0|
`> GCS
`3 1
`PLC
`40, I-—— g |
`*- |
`> 6“
`1|,
`as
`
`FACILITY 2
`112
`
`||
`[I
`I
`II
`
`FACILITY 3
`11L
`
`I
`
`|
`1
`
`l. _ _ _ _ _ __”_‘J__ll_______._._.__tl___________l
`
`Page 1 of 13
`
`PETITIONERS' EXHIBIT 1006
`
`

`

`US. Patent
`
`Oct. 29, 1991
`
`Sheet 1 0f 4
`
`5,061,916
`
`npm
`
`I
`|
`|
`l
`l
`I
`_1
`1
`
`l
`I
`I
`
`L .
`
`F
`
`vfllllll
`
`FIIIIL
`
`8.1 _
`
`_ _ _
`
`Jim-0J0
`
`JOEPZOU
`
`m-EQOE
`
`V 56..
`
`P 5365 m
`
`\ ‘
`
`VAOmPZOU
`M33002
`
`Page 2 of 13
`
`PETITIONERS' EXHIBIT 1006
`
`

`

`US. Patent
`
`Oct. 29, 1991
`
`Sheet 2 0f 4
`
`5,061,916
`
`BUILDING AUTOMATION
`SYSTEM
`
`50
`
`‘I’
`
`/-52
`
`RT DATA
`COLLECTION
`
`54- FIXED DATA
`STORAGE
`
`56 i
`J
`
`PROCESSOR
`
`(
`
`58
`1
`
`USER
`SPECIFIED
`PARAMETERS
`
`64-’
`
`was
`
`ALARM
`DETECTION
`
`,60
`
`I.» 63
`
`(-62
`
`/
`
`GRAPHIC
`
`ASSEMBLY
`
`A
`
`‘9
`
`\
`
`FACSIMILE
`COMMUNICATION
`
`/~ 66
`
`V67
`
`T0 SELECTED
`REMOTE SITE
`
`Page 3 of 13
`
`PETITIONERS' EXHIBIT 1006
`
`

`

`US. Patent
`
`Oct. 29, 1991
`
`Sheet 3 0f 4
`
`5,061,916
`
`RETURN
`
`RETURN
`
`80
`I
`ENTER USER SPECIFIED
`PARAMETERS
`I
`l
`‘l’
`
`~
`
`88
`I
`
`DETE?MlNi?llsARM TYPE - - - - TABLE OF TRANSMITTABLE
`RETRIEVE DISPLAY FORMAT|('-—'— ELgl/ésysTgffésR?gglcAL
`89\
`DISPLAY FOR EACH TYPE
`
`ASSEMBLE FIXED DATA
`INCLUDING GRAPHICS
`
`I
`81
`
`I—————
`“H
`COLLECT RZiIIlbTIME DATA
`ENTER IN GRAPHICS
`
`92
`
`DATA COLLECTED
`AND ENTERED
`
`TRANSMIT ASSEMBLED
`GRAPHIC BY FACSIMILE
`
`94
`
`TRANS
`MISSION
`VERIFIED
`
`95
`
`I
`
`DO ALTERNATE
`REPORT ROUTINE
`
`F/G. 3
`
`Page 4 of 13
`
`PETITIONERS' EXHIBIT 1006
`
`

`

`US. Patent
`
`0a. 29, 1991
`
`Sheet 4 of 4
`
`5,061,916
`
`DEPT3383 LAB SYSTEM UNACK 1 IIALARM 8 ON ALARM MAIL @9385 AM
`SINGLE ZONE SUPPLY FAN
`DISPATCH SERVICE CREW
`HAS FAILED.
`IMMEIDATELY
`
`19.4.
`[IHOSPITAL UVARIANSYS [IPWR_SLS_BX7
`
`400 WING ROOM TEMPERATURES
`ZONE 2
`
`110
`
`I
`
`122
`
`ROOM 400
`
`ROOM 404
`
`ROOM 406
`
`ROOM 408
`
`59.3 DEG F
`
`60.3DEG F
`
`61 .3 DEG F
`
`ROOM402
`LAVS.
`
`57.3 DEG F I
`
`10o
`
`STORAGE ROOM 401 ROOM 403 ROOM 405 ROOM 407 ROOM 409
`
`57.3 DEG F
`
`56.3DEG F
`
`55.3DEG F
`
`58.3DEG F
`
`OUTSIDE AIR TEMP.
`
`@112
`
`PRINT THE SCREEN CONTENTS
`
`F/G4
`
`Page 5 of 13
`
`PETITIONERS' EXHIBIT 1006
`
`

`

`1
`
`EVENT DRIVEN REMOTE GRAPHICAL
`REPORTING OF BUILDING AUTOMATION
`SYSTEM PARAMETERS
`
`FIELD OF THE INVENTION
`This invention relates to building automation sys
`tems, and more particularly to reporting of speci?ed
`event information such as alarm conditions to a remote
`site.
`
`20
`
`35
`
`5,061,916
`2
`A second problem with such building automation
`systems is related to the ?rst, in that the person sta
`t'ioned at the central console is often not the one who is
`familiar with the details of maintaining the monitored
`equipment, and thus often is not in a position to fully
`appreciate the signi?cance of a true alarm. Oftentimes,
`the person attending the console is primarily responsible
`for transmitting alarm information to a remotely located
`service organization which then assumes the responsi
`bility for making the repair. Thus, communication of
`alarm conditions to the persons ultimately responsible
`for ?xing the conditions which caused the alarm often
`must be translated through the console operator who
`may be more or less adept at associating information
`which is very relevant to the ultimate user, i.e., the
`repair organization.
`Alphanumeric computer printouts are capable of
`conveying much information, but often in a format
`which is not readily assimilated by a reader, particularly
`in an emergency situation. Oftentimes it is possible after
`the conditions which caused the alarm have been recti
`?ed, to analyze the alphanumeric computer printout
`and demonstrate how the information on the printout
`pointed to the cause of the alarm. However, in real time,
`when the user is presented with a printout and asked to
`react immediately, without adequate time for reflection
`or analysis, the alphanumeric printout does not always
`trigger a response geared to the conditions which
`caused it.
`It might be thought useful to present alarm informa
`tion in a manner, such as a graphical manner, which is
`more easily assimilated in a high pressure emergency
`situation by a person charged with reacting to the emer
`gency. However, that approach has not apparently been
`taken with building automation systems. Instead, to the
`extent those systems have provided graphical displays
`of relevant information, those displays have apparently
`been limited to display at a central console for view by
`an operator, and the disadvantages of that have been
`explained above. With respect to remote site reporting,
`the primary consideration seems to have been the rapid,
`reliable and timely transmission of the condition of the
`parameters which are out of tolerance, possibly associ
`ated with additional data, but all in an alphanumeric
`format which can require substantial interpretation on
`the part of the receiver in order to anticipate the nature
`of the fault and type of equipment which might be re
`quired to repair it.'
`
`40
`
`BACKGROUND OF THE INVENTION
`Building automation systems are well known, and
`have advanced to the state of incorporating various
`sophisticated features such as the capability of reporting
`the fact that an alarm has occurred to an offsite location.
`In some cases, the systems are capable of reporting the
`actual alarm condition and may or may not report is
`generally alphanumeric, intended to go, for example,
`either to a printer coupled in the network of the build
`ing automation system, or via leased lines to the printer
`in an external service organization. Such building auto
`mation systems have been limited in their capacity to
`report adequate information to a remote serviceman,
`usually requiring that the Serviceman call into the sys
`tem (or to a person in the monitored building) to get
`more complete information as to the nature of the alarm
`condition. If a service person intending to respond to an
`alarm condition can arrive on site with the parts most
`likely needed to ?x the problem which caused the
`alarm, downtime should be minimized. The remote
`reporting systems have not been completely effective in
`providing adequate and related information, and often
`rely on the knowledge and experience of the service
`personnel to obtain adequate information during the
`course of responding to an alarm.
`As an alternative, the service personnel can respond
`to the alarm condition by making an onsite visit to the
`building to get a ?rst-hand view of the conditions. This
`approach suffers the consequences potentially having
`the parts or tools needed for repair unavailable on site.
`As a further complicating factor, the delay caused by
`inadequately equipped service personnel (inadequately
`equipped both with respect to information and repair
`parts) attempting to ?x a problem, can cause extended
`outages with potentially serious consequences if the
`failure is in building mechanical systems whose operat
`ing status is essential to one or more of the building
`functions.
`Building automation systems have the capacity to
`monitor numerous building operating parameters and
`also have the capacity to assemble comparatively huge
`amounts of data for display to an attendant at a console
`which is centrally located in the building automation
`system. These types of systems pose two main prob
`lems. The ?rst is an excess of information, in that there
`are so many sensors and so many parameters to be moni
`tored, and so many “minor“ alarm conditions that the
`console operator is inundated with information, poten
`tially slowing his response to a real alarm condition.
`Many systems are set up such that any parameter which
`varies outside its speci?ed limits will result in an alarm,
`even if that alarm has no signi?cant potential impact on
`the overall building or the associated automation sys
`tem. A console operator having become accustomed to
`such “alarms" may fail to recognize a true alarm when
`one occurs.
`
`45
`
`50
`
`55
`
`65
`
`SUMMARY OF THE INVENTION
`In view of the foregoing, it is a general aim of the
`present invention to provide a remote reporting facility
`for a building automation system which has the capabil
`ity of assembling and transmitting to a remote location
`information relevant to an alarm condition which in
`cludes both real time and ?xed parameters, and to in
`clude in a report to the remote location current and
`related real time data for the real time parameters.
`In that respect, an object of the present invention is to
`provide a building automation system with a remote
`reporting facility, capable of remotely reporting graphi
`cal displays relating to an alarm condition, and includ
`ing in the graphical display both real time and ?xed
`parameters in such a way that the system assures the
`integrity of the real time parameters before transmitting
`an alarm message. It is thus an object to provide a
`graphical report of an alarm condition in such a way
`that the report can be relied on as demonstrating not
`
`Page 6 of 13
`
`PETITIONERS' EXHIBIT 1006
`
`

`

`5,061,916
`
`3
`only the actual parameters which are in alarm. but also
`reliably reporting other parameters thought to be rele
`vant to the alarm condition and its repair.
`An object of the present invention is to provide a
`graphical reporting capability for a building automation
`system which is not only highly economical and thus
`?ts in with the overall objective of building automation
`systems, but which is also highly reliable in assuring
`that the data included in an alarm report has relevance
`(in terms of currency) to the alarm condition.
`A subsidiary object of the invention is to provide an
`alarm reporting system which is highly ?exible in the
`type of compatible equipment which can receive an
`alarm as well as in the manner of altering the identity of
`the person or persons to receive an alarm display.
`In another subsidiary aspect of the invention, an ob
`ject is to allow customization of the alarm reporting
`system to the particular needs of the building or build
`ing operator by allowing the operator to specify not
`only the conditions which give rise to the alarm, but all
`of the parameters which are to be reported, as well as
`the graphical format in which the report is to be made,
`thereby to allow the operator almost complete freedom
`in the manner in which an alarm is to be reported.
`It is a feature of the invention to provide a system for
`remote graphical reporting of alarm conditions which
`produces reports at the remote location which are more
`readily and rapidly understandable in that they associ
`ate alphanumeric and graphical information in such a
`way as to provide not only real time operating condi
`tions of the monitored building, but also to put those
`conditions in the context of the building system being
`monitored.
`In certain embodiments of the invention, the "in con
`text” feature provides the user with the capability to
`specify the context between actual conditions which are
`in the alarm state and related parameters, knowledge of
`which is believed to be useful to better understand the
`alarm state of the speci?ed alarm parameters. The user
`in addition has the ability to provide additional context
`by specifying ?xed parameters including graphical in
`formation from static ?les maintained in the building
`automation system which tends to put both the alarm
`parameters and the non-alarm but related parameters in
`an understandable context. As a result, the report trans
`mitted to the remote site is highly information bearing
`and is intended to provide a snapshot of the relevant
`factors for rapid diagnosis and repair of faulty equip
`ment at the building site.
`It is a further feature of the invention that the graphi
`cal reports delivered to the remote site are checked for
`integrity before transmission in that the system assures
`that all real time data for real time operating parameters
`is both current and assembled into the graphical repre
`sentation before transmission is accomplished. Thus, the
`opportunity to provide misleading graphical reports is
`minimized.
`Other objects and advantages will become apparent
`from the following detailed description when taken in
`conjunction with the drawings, in which:
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a block diagram illustrating a building auto
`mation system with remote graphical reporting capabil
`ity exemplifying the present invention;
`FIG. 2 is a block diagram better illustrating the cen
`tral controller of the system of FIG. 1;
`
`4
`FIG. 3 is a flowchart illustrating the process of as
`sembling and transmitting graphical reports in accor
`dance with the present invention; and
`FIG. 4 is a diagram illustrating an exemplary graphi
`cal display as received at a remote facsimile machine.
`While the invention will be described in connection
`with certain preferred embodiments, there is no intent
`to limit it to those embodiments. On the contrary, the
`intent is to cover all alternatives, modifications and
`equivalents included within the spirit and scope of the
`invention as de?ned by the appended claims.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`Turning now to the drawings, FIG. 1 is a block dia
`grammatic illustration of a building automation system
`which includes an event driven graphical facsimile in
`terface exemplifying the present invention. The remote
`reporting system is centered around a central control
`system 20 which preferably includes in a host computer
`22 which communicates with the remaining elements of
`the system, processes the programs and maintains the
`data necessary for remote graphical reporting, and
`when remote graphical reporting is required, utilizes
`communication lines 24 to send a graphical message to
`one or more facsimile receivers 25a—25n. The facsimile
`transmission is preferably initiated and accomplished
`via a standard facsimile communication board, available
`from a number of sources, which can be plugged di
`rectly into an expansion slot of a personal computer 22,
`which serves as the control element for the central
`control 20.
`Before referring in greater detail to the actual graphi
`cal reporting system, attention will ?rst be directed to
`the various features of a typical building automation
`system, in order to better illustrate the nature of the
`problem solved by the present invention. The exem
`plary building automation system is characterized by a
`number of digital controllers which are connected to
`gether, either in hardwired fashion, or by way of a
`network, to monitor mechanical and electrical equip
`ment in a building (or a collection of buildings), to re
`port status of the monitored equipment to a central
`location, and to report alarms to a central location when
`such alarms occur. Alarms may also be reported to the
`central location 20 from one or more remote facilities
`using dial-up telecommunications. The primary intent
`of the typical building automation system is to reduce
`costs of maintaining the building, both by reducing
`staffing costs for maintaining the mechanical equipment
`in the building, as well as the actual operating costs of
`the equipment (such as by minimizing energy usage and
`maximizing fuel ef?cient operation). Successful build
`ing automation systems are those which reduce the
`overall costs of maintaining and operating the building,
`along with providing the expected reliability to make it
`appear to building occupants that the building is being
`maintained onsite, even though maintenance has been
`transferred offsite for either all or part of each operating
`day.
`Building automation systems are implemented pri
`marily to reduce costs of operating mechanical and
`electrical equipment needed to control the environment
`in facilities such as of?ce buildings, school systems, and
`manufacturing facilities. Building automation systems
`typically use networks of distributed digital controllers
`which are responsible for controlling equipment in a
`speci?c zone, as well as sharing data with other control
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Page 7 of 13
`
`PETITIONERS' EXHIBIT 1006
`
`

`

`5,061,916
`
`30
`
`5
`
`5
`lers. These controllers must respond to events such as
`mechanical breakdown, temperature and humidity
`changes, and others, by initiating control changes and
`communicating those conditions, in the form of alarm
`messages, to a human operator. These alarm messages
`are used in conjunction with building automation sys
`tem reports to allow the operator to control the facility
`in a highly customized, cost-effective manner. Exam
`ples of building automation system reports are alarm
`histories, energy usage and cost histories, trend reports,
`maintenance time reminders, and others.
`Referring again to FIG. 1, it is seen that there are
`provided a plurality of global control modules 30a-30n
`connected together by means of a network 32. In the
`current state of technology, the network 32 is prefera
`bly implemented as a token passing ring, in order to
`provide reporting efficiency and speed much higher
`than has been possible using polling networks. The
`network 32 is also extended to the central control 20,
`such that the processor 22 in the central control 20 is
`also a member of the local area network. Alternatively,
`the connection between the processor 22 and the global
`control module 30a may be implemented via other com
`munication modalities, such as dial-up lines, telecommu
`nications, or other data transmission media. The global
`control modules can be located at different sites in a
`building, or in different buildings, and are the most
`general of the control modules adapted to parcel out
`tasks among a plurality of more specific digital control
`lers. The global control modules generally have a signif
`icant amount of programmable functionality such that
`they are relatively easily customized to the require
`ments of a particular facility or site (e.g., facilities
`31a-31n) in which they are located. Global control
`modules, as well as the more specific control modules to
`be discussed below, are commercially available ele
`ments of the Barber-Colman Network 8000 System.
`The facility 31a associated with global control mod
`ule 30a is illustrated in FIG. 1, it being appreciated that
`each of the other global control modules 30b-30n can
`have the same or a similar facility (31b-31n) associated
`with it. It is seen that the global controller 30a has a
`network 36 emanating therefrom which includes a num
`ber of different types of control elements. For example,
`connected to the network .36 are a plurality of local
`control modules 38a~38n which themselves are con
`nected to building equipment generally illustrated at 39.
`The local control modules also provide a degree of
`programmable functionality, but more signi?cantly
`include a plurality of input/output points for physical
`connection to monitored equipment. Thus, in the illus
`trated embodiment, the local control modules are repre
`sentative of the devices which provide actual monitor
`ing of building equipment for reporting measured real
`time values for the monitored variables.
`Other input/output points are provided by a global
`control satellite unit 40 and a further global control
`satellite unit 42. The units 40, 42 are similar to each
`other except that the unit 42 has the capability of com
`municating on the power lines whereas the module 40
`communicates only on the network. Both are connected
`to the network and thus can be controlled by the global
`control module 30a and also can report conditions back
`to that global control module for passing along the
`network 32. Both the modules 40 and 42 contain input
`/output points connected to physical equipment in a
`similar fashion to the connections of the local control
`
`6
`. module, and thus are a source of further real time oper
`ating data.
`' Other input/output points are provided by control
`lers 44, 46. The controller 44 is intended to be represen
`tative ofa microzone controller which is a unitary digi
`tal controller for a packaged unit, (such as a rooftop
`heating and cooling system) and has control functions ‘
`for controlling that unit, as well as sensing functions for
`monitoring sensors on the unit. The controller 46 is
`intended to represent a microflo controller which is
`representative of the type of units for monitoring and
`controlling a variable air volume (VAV) unit, and thus
`would typically control flow controllers as well as actu
`ators for controlling flow equipment such as fans,
`dampers and local heating coils in a VAV air terminal
`unit.
`It will now be appreciated that the control modules
`38-46 are located in the building (or buildings) to be
`automated, and thus can be included under a single roof
`or at widely distributed geographical points. The net
`works 32 interconnecting the global control modules as
`well as the networks 36 interconnecting a single global
`control module with its local controllers can take the
`form of hardwiring between physically proximate units,
`telephone lines for dial-up between units, leased lines,
`and the like. It is not unusual to include many forms of
`intercommunication in a single building automation
`system, such that it is difficult to assume that when a
`given set of data is to be collected it can all be done
`within a relatively short time since some modes of com
`munication can take longer than others, some are more
`or less reliable than others, etc. Thus, to assemble a
`given set of relevant data might require utilization of a
`global control satellite module 40 to secure operating
`data via direct wiring to its connected equipment, and
`communicate that information via a bus 36, which
`might be hardwired to a global control module; in addi
`tion, a global control module 30 might also need to
`collect information from, and also to poll, various local
`control modules 38a-38n at distributed sites, and re
`ceive reports back from those modules via leased lines
`in one case or telephone lines in another, before all of
`the relevant data is assembled. At that point, all of the
`relevant data may be available in one of the global con
`trol modules 300, but still unavailable to the host until it
`is communicated by the token passing ring 32 which can
`again be implemented in one or more of the available
`communication technologies. In short, it will be appre
`ciated that a massive amount of data can be collected by
`a building automation system, but assembling relevant
`elements of that data from remote sites (which may
`become relevant to each other only upon occurrence of
`a particular alarm) is not necessarily a trivial task.
`Turning now to FIG. 2, there is shown a breakdown
`of the elements of an event driven graphical facsimile
`interface and its association with a building automation
`system. The elements of FIG. 2 can be considered at
`primarily residing in the central control 20, which is
`typically con?gured as a unit on the main system net
`work along with the global control modules 300, 30n. If
`no major network is utilized, the central control 20 can
`be associated with the single global control module on
`the network, communicating to all of the subsidiary
`local modules arranged in the hierarchy below it.
`For purposes of FIG. 2, the major building related
`elements of the system are shown as resident in a build
`ing automation system block 50 which is intended to
`include all of the local modules illustrated in FIG. 1,
`
`55
`
`60
`
`65
`
`Page 8 of 13
`
`PETITIONERS' EXHIBIT 1006
`
`

`

`7
`much of the global control network 30, 32 ofthat ?gure,
`and the many monitored sensors in the building automa
`tion system. The dashed line closing the bottom of
`block 50 in FIG, 2 is intended to illustrate that the re
`maining elements illustrated below that block can also
`be assimilated into the overall building automation sys
`tem 50. It is for purposes of illustration that they are
`broken out in FIG. 2. It is seen that the building automa
`tion system 50 is interfaced to a pair of storage elements
`52, 54, the former being adapted to collect and store real
`time data from the building automation system, and the
`latter to store ?xed data relating to that system. Both
`are customizable for a particular automation system.
`The ?xed data storage 54 can typically be thought of
`as represented by floor plans or other diagrams for the
`building to be monitored, information relating to the
`mechanical equipment in the building (such as model
`numbers and speci?cations for heaters, chillers and the
`like), desired formats for periodic reports, dial-up num
`bers for reporting of alarm conditions, and a myriad of
`other relevant information which can be customized for
`a given installation but need not change regularly dur
`ing the operation of that installation. That information is
`sometimes referred to as “?xed” herein, in order to
`distinguish it from the real time data generated by moni-,
`toring sensors; the “?xed” data is naturally amenable to
`change from time to time.
`The real time data collection element 52, however, is
`intended to represent the ever changing variable data
`which is monitored by the system and which can serve
`to drive the automation system controls as the measured
`variables change. For example, as room temperature
`gets too high, the building cooling system can be ener
`gized to return the room temperature to within desired
`set points. The real time data collection element 52
`typically contains a relatively large amount of storage
`for maintaining the current status of the numerous sens
`ing transducers in the system. The storage elements are
`not necessarily relevant to each other, but selected ele
`ments of data relevant to a particular occurrence can be
`selected under the control of a processor 56 pro
`grammed ?rst of all to perform the building automation
`system functions, and secondly to perform the remote
`graphical reporting of the present invention.
`The details of the structure and operation of the pro
`cessor 56 in performing the building automation system
`functions will not be described in great detail, since they
`are known to those skilled in the art, and such a proces
`sor is readily available for purchase, such as in the afore
`mentioned Network 8000 system from Barber-Colman.
`Suf?ce it to say that the processor 56 monitors the real
`time data collected by element 52, compares that data
`against allowable limits, and operates controlled equip
`ment within the building automation system (not illus
`trated) to maintain the system within the established
`setpoints.
`With respect to remote reporting of system parame
`ters in general, and alarms in particular, the processor
`56 is associated with an element 58 which provides the
`user the opportunity to specify parameters for trigger
`ing a report in the first instance and for establishing the
`content of the report for transmission. Thus, the ele
`ment 58 will typically include an interactive inquiry
`software program (operated on the computer 22), and
`an element of memory programmed to query the user as
`to the need for and nature of certain reports. The user
`will answer the queries by inputting information into
`the processor 56 intended to specify trigger points
`
`5,061,916
`8
`which will generate a report. Such trigger points usu
`ally include alarm conditions which are intended to
`cause the transmission of an alarm report to a remote
`site, alerting a repairman that attention is needed within
`a predetermined time frame. Another type of trigger
`point often utilized is a "time trigger“. More particu
`larly, the processor within the system maintains a real‘
`time clock, and that clock can be utilized to trigger
`certain events. For example, during the portion of the
`day when the building is manned, no remote alarms
`need be generated, but the system can be set to be trig
`gered during the non-manned hours to transmit remote
`alarms. As a further example, alternate facsimile num
`bers can be associated with a particular alarm, and a
`time trigger utilized to establish which of the alternate
`numbers will be dialed at any given time of day. As a
`?nal example, status reports can be sent at particular
`times on speci?ed days to predetermined locations, all
`as triggered by the real time clock within the system.
`Other examples of transmittable reports, which can be
`speci?ed by the user through module 58 include peri
`odic reports such as the aforementioned maintenance
`reports and the like, intended to be generated at prede
`termined intervals or after the accumulation of a prede
`termined number of events in order to provide a desired
`set of operating conditions to a remote location.
`In addition to specifying the triggering events for
`remote transmission of reports, the user interface 58 also
`provides the means for tailoring each of the reports to
`the requirements of the building automation system.
`Thus, the user can, for example, specify a particular
`triggering event, such as a failed chiller unit, and then
`specify for that particular alarm event the elements of
`fixed and real time data which are to be reported to the
`remote location as the alarm report. For example, the
`user can specify with that particular alarm that the floor
`plan for the area served by the chiller is to be transmit
`ted along with the existing temperature in each room on
`the floor plan, the outside temperature, the air flow and
`temperature within particular ducts, and other informa
`tion which the user in his best judgment believes is
`relevant to the service man who will be dispatched to
`repair the chiller. The graphical information can also
`include catalog information on the chiller, a diagram
`showing the main repair elements in the particular
`chiller, and other information tailor