idnits 2.17.1 draft-martocci-6lowapp-building-applications-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 33 has weird spacing: '... months and ...' == Line 34 has weird spacing: '... at any time...' == Line 35 has weird spacing: '...ference mate...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 8, 2010) is 5034 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1045, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group J. Martocci 2 Internet-Draft Johnson Controls Inc. 3 Intended status: Informational Anthony Schoofs 4 Expires: January 8, 2011 University College Dublin 5 Peter van der Stok 6 Philips Research Laboratories 7 July 8, 2010 9 Commercial Building Applications Requirements 10 draft-martocci-6lowapp-building-applications-01 12 Abstract 14 Building management systems have evolved toward IP communication at 15 the enterprise level during the past decade. IP implementation at 16 the real-time control and sensor layers would provide a single 17 pervasive protocol usable across the entire system increasing 18 flexibility and code reuse. This document will describe the topology 19 of these building networks, the application protocols widely used in 20 their deployment and the application use cases. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet-Drafts 35 as reference material or to cite them other than as "work in 36 progress." 38 This Internet-Draft will expire on January 8, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. 52 Table of Contents 54 1. Terminology....................................................4 55 2. Overview.......................................................5 56 3. FMS Topology...................................................6 57 3.1. Introduction..............................................6 58 3.2. Sensors/Actuators.........................................8 59 3.3. Area Controllers..........................................8 60 3.4. Zone Controllers..........................................9 61 3.5. Building Controllers......................................9 62 4. FMS Communication Media........................................9 63 5. FMS Communication Protocols...................................10 64 5.1. Controller/Sensor/Actuator Communication Protocol........10 65 5.2. Enterprise Communication Protocol........................11 66 5.2.1. Peer-to-peer Controller Communication...............11 67 5.2.2. Enterprise Communication............................11 68 6. FMS Device Density............................................11 69 6.1. HVAC Device Density......................................12 70 6.2. Fire Device Density......................................12 71 6.3. Lighting Device Density..................................12 72 6.4. Physical Security Device Density.........................13 73 7. FMS Installation Methods......................................13 74 8. Building Application Use Cases................................14 75 8.1. Fire and Smoke Abatement.................................14 76 8.2. Evacuation...............................................15 77 8.3. Occupancy/shutdown.......................................16 78 8.4. Energy Management........................................17 79 8.5. Fault Detection and Diagnostics..........................17 80 9. Building Application Protocol Requirements....................18 81 9.1. Physical Layer Requirements..............................18 82 9.1.1. Wired and Wireless Implementations..................18 83 9.1.2. Cost Effective Wired Installation...................18 84 9.1.3. Cost Effective Wireless Installation................18 85 9.1.4. Global Wireless Applicability.......................18 86 9.1.5. Constrained Power Sensors...........................18 87 9.2. Network Layer Requirements...............................19 88 9.2.1. TCP/UDP.............................................19 89 9.2.2. Fragmentation.......................................19 90 9.2.3. Data Rate Performance...............................19 91 9.2.4. Interference Mitigation.............................19 92 9.2.5. Real-time Performance Measures......................19 93 9.2.6. Packet Reliability..................................19 94 9.2.7. Packet Routing......................................20 95 9.3. Installation and Commissioning Requirements..............20 96 9.3.1. Device Setup Time...................................20 97 9.3.2. Unavailability of an IT network.....................20 98 9.4. Application Layer Object/Node Requirements...............20 99 9.4.1. Object Model........................................20 100 9.4.2. Object Location.....................................20 101 9.4.3. Node Discovery......................................20 102 9.4.4. Object Discovery....................................20 103 9.4.5. Object List.........................................21 104 9.4.6. Property List.......................................21 105 9.4.7. Service List........................................21 106 9.4.8. Consistent Error Reporting..........................21 107 9.5. Application Layer Solicited Service Requirements.........21 108 9.5.1. Reading Datum.......................................21 109 9.5.2. Reading Data from an Object.........................21 110 9.5.3. Reading Data from Multiple Objects..................21 111 9.5.4. Reading Data with Wild Cards........................22 112 9.5.5. Reading Large Data Items............................22 113 9.5.6. Object Creation and Deletion........................22 114 9.5.7. Object Property Writing.............................22 115 9.5.8. Atomic Object Property Writing......................22 116 9.5.9. Object Property List Writing Addition...............22 117 9.5.10. Object Property List Writing Deletion..............23 118 9.5.11. Downloads..........................................23 119 9.6. Application Layer Unsolicited Service Requirements.......23 120 9.6.1. Property Value(s) Change Notification...............23 121 9.6.2. Alarm Notification..................................23 122 10. Traffic Pattern..............................................23 123 11. Security Considerations......................................24 124 12. IANA Considerations..........................................24 125 13. Acknowledgments..............................................24 126 14. References...................................................24 127 14.1. Normative References....................................24 128 14.2. Informative References..................................24 130 1. Terminology 132 Actuator: A field device that controls and/or modulates a flow 133 of a gas or liquid; or controls electrical 134 distribution. 136 BACnet: Building Automation Control Network. A ISO 137 application protocol used in building management 138 systems. 140 Channel: Radio frequency sub-band used to transmit a modulated 141 signal carrying packets. 143 DALI: Digital Addressable Lighting Interface. A protocol 144 used in lighting systems. 146 Fire: The term used to describe building equipment used to 147 monitor, control and evacuate an internal space in 148 case of a fire situation. Equipment includes smoke 149 detectors, pull boxes, sprinkler systems and 150 evacuation control. 152 FMS: Facility Management System. A global term applied 153 across all the vertical designations within a building 154 including, Heating, Ventilating, and Air Conditioning 155 also referred to as HVAC, Fire, Security, Lighting and 156 Elevator control. 158 HVAC: Heating, ventilation and air conditioning. This term 159 is broadly used to define anything in the building 160 that addresses air flow and occupant comfort. 162 Intrusion Protection: A term used to protect resources from 163 external infiltration. Intrusion protection systems 165 Lighting: The term used to describe building equipment used to 166 monitor and control an internal or external lighted 167 space. Equipment includes occupancy sensors, light 168 switches and ballasts. 170 Luminaire: Another term for a light fixture installed in a 171 ceiling. 173 MS/TP: Master Slave Token Passing; the EIA-485 data link used 174 in BACnet. This data link uses a software token 175 passing mechanism allowing for multiple multi-dropped 176 masters on the network. A master node can only access 177 the media while it secures the token. MS/TP also 178 supports slave nodes. These less complicated devices 179 never receive the token and can only address the media 180 when requested from a master node. 182 Security: The term used to describe building equipment used to 183 monitor and control occupant and equipment safety 184 inside a building. Equipment includes window tamper 185 switches, door access systems, infrared detection 186 systems, and video cameras. 188 2. Overview 190 Facility Management systems (FMS)are deployed in a wide variety of 191 commercial building topologies, including single buildings, multi- 192 building single site environments such as university campuses and 193 widely dispersed multi-building multi-site environments such as 194 franchise operations. These buildings range in size from 100K square 195 feet (10k square meters) structures (5 story office buildings), to 196 multi-million sqft skyscrapers (110 story Shanghai World Financial 197 Center) to complex government facilities (Pentagon). The described 198 topology is meant to be the model to be used in all these types of 199 environments, but clearly must be tailored to the building class, 200 building tenant and vertical market being served. 202 The following sections describe the FMS system architecture from the 203 lowest layer to the highest layers in the hierarchy. Each section 204 describes the basic functionality of the layer, its networking model, 205 power requirements and a brief description of the communication 206 requirements. The entire section references the block diagram noted 207 in Figure 1. This figure depicts six major subsystems comprising an 208 FMS. These subsystems all have layered solutions starting at the 209 sensor layer and moving upward in complexity toward the enterprise 210 network layer. While these six subsystems are common to many 211 facilities, they are by no means the exhaustive list - a chemical 212 facility may require a complete fume hood management system; a 213 manufacturing facility may require interfacing to the PLC subsystem; 214 or a multi-tenant facility might require a comprehensive power 215 management subsystem. The objective in the architecture is to 216 integrate all common functions into the system yet allow maximum 217 flexibility to modify these systems and add other subsystems as 218 dictated by the customer. 220 Commercial buildings have been fitted with pneumatic and subsequently 221 electronic communication pathways connecting sensors to their 222 controllers for over one hundred years. Pneumatics were displaced by 223 simple electronics and dry contacts in the 1960's. Smart processor 224 based sensors displaced simple contacts in the 1970's. Localized 225 digital control, introduced in the 1980's allowed applications to 226 operate independently from the upper layers of the system. Multi- 227 dropped twisted pair sensor/controller communication networks 228 displaced high cost cabled networks. 230 The 1990's ushered in the use of Ethernet IP networks at the 231 enterprise level. This transition allowed the previously independent 232 proprietary communication networks to coexist on the enterprise IP 233 LAN network. This migration reduced installation costs and allowed 234 pertinent building data to be injected onto the enterprise 235 application suite. Proprietary protocols were displaced by industry 236 standard application protocols such as BACnet and LON for HVAC; and 237 DALI for Lighting. 239 Recent economic and technical advances in wireless communication 240 allow facilities to increasingly utilize a wireless solution in lieu 241 of a wired solution; thereby reducing installation costs while 242 maintaining highly reliant communication. Wireless solutions will be 243 adapted from their existing wired counterparts in many of the 244 building applications including, but not limited to HVAC, Lighting, 245 Physical Security, Fire, and Elevator systems. These devices will be 246 developed to reduce installation costs; while increasing installation 247 and retrofit flexibility. Sensing devices may be battery, scavenged, 248 or mains powered. Actuators and area controllers will be mains 249 powered. Today, different networks based on their own standard (e.g. 250 BACnet, DALI) do not share cabling, sensors or actuators easily. The 251 arrival of IP for building control will coalesce these topologies. 253 The objective of this draft is to describe topologies, protocols and 254 application use cases. It will describe the application benefits and 255 concerns in converting to pervasive IP networks. It will further 256 describe the IP services required to operate these systems. Finally, 257 it will describe how the building data and IT data models might 258 converge to allow a free flowing of data on the converged FMS/IT 259 network. 261 3. FMS Topology 263 3.1. Introduction 265 To understand the network systems requirements of an FMS in a 266 commercial building, this document uses a framework to describe the 267 basic functions and composition of the system. An FMS is a 268 horizontally layered system of sensors, actuators, controllers and 269 user interface devices orchestrated to work together over selected 270 communication media. Additionally, an FMS may also be divided 271 vertically across alike, but different building subsystems such as 272 HVAC, Fire, Security, Lighting, Shutters and Elevator control systems 273 as denoted in Figure 1. These distinct areas are termed 'silos'. 274 Currently, the separation between the silos is rather sharp. Gateways 275 provide connections between the silos to support all encompassing 276 applications. With future IP deployment applications will have a flat 277 addressing space for accessing all nodes in any silo. 279 Much of the makeup of an FMS is optional and installed as required by 280 the customer. These systems are expensive and must be designed to 281 allow for incremental purchases as dictated by the customer's budget 282 cycle. 284 Sensors and actuators have no standalone functionality. All other 285 devices support partial or complete standalone functionality. These 286 devices can optionally be tethered to form a more cohesive system. 287 The customer requirements dictate the level of integration within the 288 facility. This architecture provides excellent fault tolerance since 289 each node is designed to operate independently but will accept 290 overrides from the higher layers when the higher layers are 291 available. 293 Heating, Ventilation and Air Conditioning (HVAC); Fire; Security and 294 Lighting are components that can be tethered together into a cohesive 295 set of all encompassing applications tailored to the customer's whim. 296 Shutter control is an emerging application domain prevalent in the 297 European market. These major subsystems are connected logically 298 through application software called Building Applications. 300 +------+ +-----+ +------+ +------+ +------+ +------+ 302 Bldg App'ns | | | | | | | | | | | | 304 | | | | | | | | | | | | 306 Building Cntl | | | | | S | | L | | S | | E | 308 | | | | | E | | I | | H | | L | 310 Zone Control | H | | F | | C | | G | | U | | E | 312 | V | | I | | U | | H | | T | | V | 314 Area Control | A | | R | | R | | T | | T | | A | 316 | C | | E | | I | | I | | E | | T | 318 Actuators | | | | | T | | N | | R | | O | 320 | | | | | Y | | G | | S | | R | 322 Sensors | | | | | | | | | | | | 324 +------+ +-----+ +------+ +------+ +------+ +------+ 326 Figure 1 - Building Systems and Devices 328 3.2. Sensors/Actuators 330 An FMS may be composed of many functional stacks or silos that are 331 interoperably woven together via Building Applications. Each silo 332 has an array of sensors that monitor the environment and actuators 333 that effect the environment as determined by the upper layers of the 334 FMS topology. The sensors typically are the leaves of the network 335 tree structure providing environmental data into the system. The 336 actuators are the sensors' counterparts modifying the characteristics 337 of the system based on the input sensor data and the applications 338 deployed. 340 3.3. Area Controllers 342 An area describes a small physical locale within a building, 343 typically a room. Public spaces such as hallways and atria are also 344 controlled by area controllers. The HVAC, Security and Lighting 345 functions within a building address area or room level applications 346 running in the area controllers. Area controls are fed by sensor 347 inputs that monitor the environmental conditions within the room. 348 Common sensors found in many rooms that feed the area controllers 349 include temperature, occupancy, lighting load, solar load and 350 relative humidity. Sensors found in specialized rooms (such as 351 chemistry labs) might include air flow, pressure, CO2 and CO particle 352 sensors. Room actuation includes temperature setpoint, lights and 353 blinds/curtains. 355 3.4. Zone Controllers 357 Zone Control supports a similar set of characteristics as the Area 358 Control albeit to an extended space. A zone is normally a logical 359 grouping or functional division of a commercial building. A zone may 360 also coincidentally map to a physical locale such as a floor. 362 Zone Control may have direct sensor inputs (smoke detectors for 363 fire), controller inputs (room controllers for air-handlers in HVAC) 364 or both (door controllers and tamper sensors for security). Like 365 area/room controllers, zone controllers are standalone devices that 366 operate independently or may be attached to the larger network for 367 more synergistic control. 369 3.5. Building Controllers 371 Building Controllers orchestrate the overall building control. These 372 devices provide higher level functionality such as web servers, 373 scheduling, time series data archival, energy monitoring and 374 reduction, and alarm management. Additionally they will cooperate 375 with the other silos to provide synergistic applications as noted in 376 the use case sections that follow. 378 4. FMS Communication Media 380 Today most FMSs communicate over four media; DALI, EIA-485, Ethernet 381 and wireless. 383 For HVAC instrumentation, sensors, actuators, area controllers, zone 384 controllers, and building controllers most often connect via EIA-485 385 3-wire twisted pair serial media operating nominally at 38400 to 386 76800 baud. This allows runs to 5000 ft without a repeater. With the 387 maximum of two repeaters, a single multi-dropped communication trunk 388 can serpentine 15000 ft. 390 For lighting the DALI standard provides a 5-wire cable containing 391 control and power-supply lines. Up to 64 control units can be 392 connected to one line. The maximum distance between two directly 393 connected DALI devices is 300m operating at 1200 bits/s. 395 The HVAC, Fire, Access, Intrusion and Lighting subsystems are 396 integrated using LAN based Ethernet technology. These enterprise 397 devices connect to standard Cat-5e through workgroup switches. WLAN 398 communications can replace the Ethernet connection if the application 399 can operate within the WLAN performance characteristics. Currently 400 building controllers typically support a RJ-45 connection. WLAN 401 connections require an external wireless bridge. Multi-building 402 sites can also connect onto the facility intranet if the intranet 403 performance matches the application requirements. 405 Recently sensors, area controllers and zone controllers have been 406 deployed on wireless mesh systems. 802.15.4 based mesh systems seem 407 to be the technology of choice by most manufacturers due to the cost 408 point of the radio technology and communication robustness. 410 5. FMS Communication Protocols 412 5.1. Controller/Sensor/Actuator Communication Protocol 414 The sensors, actuators, area controllers, zone controllers, and 415 building controllers all utilize BACnet, DALI, or LON protocol. 416 BACnet is an ISO world-wide Standard application layer protocol 417 designed to maximize interoperability across many products, systems 418 and vendors in commercial buildings. BACnet was conceived in 1987 419 and released in 1995 for the HVAC industry. Since that time Fire, 420 Security and Lighting functionality has been added. 422 BACnet supports six media types including Ethernet (802.3 and IP), 423 EIA-485, Arcnet, LON, RS-232 and ZigBee. 425 BACnet supports all expected network services including functions 426 such as device and object discovery; unicast and broadcast messaging; 427 full routing; flow control and fragmentation; and network security. 429 BACnet MS/TP is the BACnet data link for EIA-485 networks. MS/TP is 430 a token passing protocol (implemented in software) allowing 431 master/slave and peer-to-peer communication simultaneously. Devices 432 must designate themselves as slaves or masters on the network. Slave 433 devices may only access the network when solicited by a master 434 device. Masters may communicate to any node on the network whenever 435 it holds the token. BACnet MS/TP has a 1-octet MAC address allowing 436 for a maximum of 254 devices per network segment. (Address 255 is 437 reserved for broadcast designation). 439 BACnet/IP addressing currently supports IPv4 addressing only. An 440 IPv6 working group has been commissioned by the BACnet Committee to 441 develop the needed changes for BACnet to support IPv6. 443 The DALI standard was conceived in the late 1990 and consolidated in 444 the IEC 62386 standard (formerly IEC 60929). DALI network is ordered 445 in 16 groups of each maximally 64 devices. 16 scenes can be defined 446 grouping sets of devices together to receive the same command 447 sequences. A DALI network is usually a lighting subnet connected to 448 the building network with a LON DALI gateway. 450 5.2. Enterprise Communication Protocol 452 Multiple protocols are supported at the enterprise level of the FMS 453 since this layer supports both the embedded control operation and the 454 user interface. 456 5.2.1. Peer-to-peer Controller Communication 458 Building Controllers orchestrate the overall FMS system operations. 459 Control and data access functions implemented at this level utilize 460 BACnet IP. BACnet IP provides the complete building object model and 461 requisite services across all the FMS silos. Since BACnet is 462 deployed on the lower layers of the system, utilizing it to control 463 operations at the highest layer of the system is prudent. BACnet IP 464 implements UDP/IP with its own transport layer. It is designed to 465 operate efficiently and transparently on all IP networks. 467 5.2.2. Enterprise Communication 469 While BACnet and LON are the control protocols of choice; it is out 470 of scope for most enterprise applications. Web Services and SNMP 471 frequently is added to the enterprise layer to assist in integration 472 with end-user applications and Network Management Systems 473 respectively. The enterprise level also supports most ancillary IT 474 protocols such as SMTP, SNTP, DHCP and DNS. 476 6. FMS Device Density 478 Device density differs depending on the application and code 479 requirements. The following sections detail typical installation 480 densities for different applications. 482 6.1. HVAC Device Density 484 HVAC room applications typically have sensors and controllers spaced 485 about 50ft apart. In most cases there is a 3:1 ratio of sensors to 486 controllers. That is, for each room there is an installed 487 temperature sensor, flow sensor and damper controller for the 488 associated room controller. 490 HVAC equipment room applications are quite different. An air handler 491 system may have a single controller with upwards to 25 sensors and 492 actuators within 50 ft of the air handler. These sensors may include 493 a discharge air temperature, a static pressure sensor, a CO sensor, a 494 CO2 sensor, a return air temperature and a mixed air temperature. 496 A chiller or boiler is also controlled with a single equipment 497 controller instrumented with 25 sensors and actuators. Each of these 498 devices would be individually addressed. Air handlers typically 499 serve one or two floors of the building. Chillers and boilers may be 500 installed per floor, but many times service a wing, building or the 501 entire complex via a central plant. Sensors typically instrumented 502 on a chiller include chilled water temperature, condenser water 503 temperature, and pump status. 505 These numbers are typical. In special cases, such as clean rooms, 506 operating rooms, pharmaceuticals and labs, the ratio of sensors to 507 controllers can increase by a factor of three. Tenant installations 508 such as malls would opt for packaged units where much of the sensing 509 and actuation is integrated into the unit. Here a single device 510 address would serve the entire unit. 512 6.2. Fire Device Density 514 Fire systems are much more uniformly installed with smoke detectors 515 installed about every 75 feet. This is dictated by local building 516 codes. Fire pull boxes are installed uniformly about every 150 feet. 517 A fire controller will service a floor or wing. The fireman's fire 518 panel will service the entire building and typically is installed in 519 the atrium. 521 6.3. Lighting Device Density 523 Lighting is also very uniformly installed with ballasts installed 524 approximately every 10 feet. A lighting panel typically serves 48 to 525 64 zones. Wired systems typically tether many lights together into a 526 single zone. Wireless systems configure each fixture independently 527 to increase flexibility and reduce installation costs. 529 6.4. Physical Security Device Density 531 Security systems are non-uniformly oriented with heavy density near 532 doors and windows and lighter density in the building interior space. 533 The recent influx of interior and perimeter camera systems is 534 increasing the security footprint. These cameras are atypical 535 endpoints requiring upwards to 1mbps data rates per camera as 536 contrasted by the few kbps needed by most other FMS sensing 537 equipment. To date, camera systems have been deployed on a 538 proprietary wired high speed network or on enterprise VLAN. Camera 539 compression technology now supports full-frame video over wireless 540 media. 542 7. FMS Installation Methods 544 Wired FMS installation is a multifaceted procedure depending on the 545 extent of the system and the software interoperability requirement. 546 Unlike most IP installations, FMSs are installed from the outside-in. 547 That is the sensors, actuators and controllers are installed first. 548 Later the Zone Controllers are installed; and finally the system is 549 connected to the enterprise network. 551 At the sensor/actuator and controller level, the procedure is 552 typically a two or three step process. Most FMS equipment is 24 VAC 553 equipment that can be installed by a low-voltage electrician. He/she 554 arrives on-site during the construction of the building prior to the 555 sheet wall and ceiling installation. This allows him/her to allocate 556 wall space, easily land the equipment and run the wired controller 557 and sensor networks. The Building Controllers and Enterprise network 558 are not normally installed until months later. The electrician 559 completes his task by running a wire verification procedure that 560 shows proper continuity between the devices and proper local 561 operation of the devices. 563 For lighting networks this means that light sensor, presence sensor, 564 switches, and luminaires are all connected within a room and 565 sometimes already connected to a room controller. Commissioning is 566 for DALI executed with a laptop to map network addresses to physical 567 devices. 569 Later in the installation cycle, the higher order controllers are 570 installed, programmed and commissioned together with the previously 571 installed sensors, actuators and controllers. In most cases the IP 572 network is still not operable. The Building Controllers are 573 completely commissioned using a crossover cable or a temporary IP 574 switch together with static IP addresses. 576 Once the IP network is operational, the FMS may optionally be added 577 to the enterprise network. Wireless installation will necessarily 578 need to keep the same work flow. The electrician will install the 579 products as before and run continuity tests between the wireless 580 devices to assure operation before leaving the job. The electrician 581 does not carry a laptop so the commissioning must be built into the 582 device operation. 584 8. Building Application Use Cases 586 The Building Application layer is a software layer that binds the 587 various system silos into a cohesive systemic application. This 588 discussion in not meant to be inclusive. Rather it is meant to show 589 how these diverse systems can be coordinated to provide innovated 590 synergistic applications for the customer safety and comfort. 592 8.1. Fire and Smoke Abatement 594 Most local codes now require commercial buildings to incorporate 595 comprehensive fire and life/safety systems into a building. It is 596 well documented that loss of life in a building is mainly caused by 597 smoke inhalation rather than the fire itself. Agencies, such as UL 598 (in the US market), have developed fire certification programs that 599 govern fire and smoke operations in commercial buildings. These 600 programs require very rigorous interactive testing for certification. 601 In addition to the obvious need to minimize life/safety situations in 602 a building, facility operators are highly encouraged to implement 603 these systems due to insurance cost reductions. 605 The fire and smoke abatement application requires a highly 606 coordinated interaction between the fire silo and the HVAC silo. The 607 fire system detects the smoke or fire and reports it to the HVAC 608 system. While the fire system is issuing evacuation notices, 609 sounding the alarms and flashing the strobes; the HVAC system 610 automatically shuts down all fan systems in the immediate area (to 611 starve the fire) while simultaneously opening all external dampers 612 and ratcheting up the fans in the adjacent areas to purge the smoke. 614 Meanwhile, the lighting systems will immediately turn on all safety 615 lights in the area to assure safe passage for the occupants. It will 616 also create light trails to assist occupants to the doors. 618 The physical security system will unlatch all doors to assure 619 immediate egress of the occupants. 621 The elevator control system will either shut off entirely or bypass 622 normal operation to assist with the emergency responders. 624 The fire and smoke systems operate in either a manual or automatic 625 mode. The automatic mode is a preprogrammed set of events that 626 control the fire automatically. The manual mode provides critical 627 fire and smoke information at a centralized display to be controlled 628 by a Fire Marshal. In practice, the fire system will be set to 629 automatic mode and operate accordingly until the Fire Marshall 630 arrives. At that point the system is normally overridden to manual 631 mode so that the Fire Marshall can control operations from the 632 command center as deemed necessary. 634 While the smoke abatement operation could be the province of the fire 635 system alone, economics dictate that the fire system off-loads the 636 smoke abatement operation to the HVAC system. In practice, the fire 637 system will receive the initial fire indication by one or more of its 638 smoke detectors. It will then inform the HVAC system of the physical 639 locale of the fire. The HVAC system will then take charge of the 640 smoke abatement operation by automatically adjusting the air handlers 641 and dampers. The HVAC system must incorporate a comprehensive 642 prioritization scheme throughout its system. This prioritization 643 scheme must allow all smoke operations to take control precedence 644 over all other control operations including manual operator control. 645 All affected devices must support a supervision policy that assures 646 that all operations requested were executed properly. The system 647 must automatically return to well-defined normal operational state 648 once the smoke situation has abated. 650 8.2. Evacuation 652 Evacuation is another systemic operation that may be activated as 653 part of the Fire/Smoke Control application, or may be activated for 654 other reasons such as terrorist threats. Evacuation requirements 655 most often will activate subsystems of the Fire, Security and 656 Lighting silos. The Fire system normally supports the intercom 657 subsystem in the facility. The intercom system will then trigger the 658 recorded voice evacuation instructions. This may be in concert with 659 the fire system audio indications if a fire situation is active or 660 standalone. The lighting subsystem will be activated to turn on the 661 lights and evacuation paths to aid in the evacuation. The security 662 system will coincidentally open all doors to allow a smooth safe 663 egress from the building. If the building also supports elevator 664 control, the elevators will operates as directed by a preprogrammed 665 evacuation policy. 667 8.3. Occupancy/shutdown 669 A major energy saving technique in commercial buildings is to 670 automatically commence HVAC and lighting operations prior to building 671 occupancy. Conversely, building shutdown allows the systematic 672 reduction in HVAC and lighting operations as the building becomes 673 unoccupied. 675 The HVAC system is usually charged with defining occupied and 676 unoccupied times. The Fire and Security operations are always 677 operable and lighting is most often subservient to HVAC. 678 Occupied/unoccupied schedules are typically programmed into the 679 system by facility operations; however, it could be learned 680 adaptively by the security's access control system. The target 681 occupancy time drives the HVAC subsystem to turn on all ventilation 682 equipment at an optimal time so that each space is ready for 683 occupancy at the prescribed time. These algorithms will be adaptive 684 over time but also include systemic instrumentation such as outdoor 685 air and relative humidity to turn on the equipment at the last 686 possible moment yet still meet the target environmental needs just 687 before occupancy. 689 The lighting systems are turned on/off as a function of the overall 690 room light intensity and the presence of persons within the room. 691 Switching on is immediate on arrival of persons, switching off is 692 done with a suitable delay, possibly involving dimming of lights. 694 Conversely, the HVAC systems will also determine the earliest 695 possible time it can shut down heating/cooling yet still control the 696 setpoints to meet the requisite parameters. Lighting again gets off 697 easier since the lights can be extinguished as soon as they are not 698 needed. 700 Building owners may use the lighting systems to pace the janitorial 701 service providers by defining a strict timetable that the lights will 702 be on in a given area. Here, the janitorial service providers will 703 need to keep in step to complete their work prior to the lights being 704 turned off. 706 Facility Management Systems often include a telephone interface that 707 allows any late workers to override the normal HVAC and lighting 708 schedules simply by dialing into the system and specifying their 709 locale. The lights and fan system will continue to operate for a few 710 extra hours in the immediate vicinity. The same applies to occupancy 711 sensors in meeting rooms. Either by automatic sensing or a simple 712 push of the occupied switch, the HVAC and lighting schedules will 713 extend the normal schedule for the meeting room. 715 8.4. Energy Management 717 The occupancy/shutdown applications noted above optimize runtime of 718 large equipment. This in itself is a major component of energy 719 savings. However, even during occupancy large equipment can be 720 modulated or shutoff temporarily without affecting environment 721 comfort. This suite of applications run in the HVAC domain, however 722 the HVAC silo will interact with the lighting system to reduce the 723 lighting load to help in the overall reduction of energy. 725 The load rolling, demand limiting and demand response applications 726 allow for the sequencing of equipment to reduce the overall energy 727 profile or to shave off peak energy demands in the facility. The FMS 728 system will constantly monitor real-time energy usage and 729 automatically turn unneeded equipment off (or reduce the control 730 setpoint) to stave off peaking the facility's electrical profile. 731 Demand peaks set by commercial facilities are frowned upon heavily by 732 utilities and are often accompanied by huge energy charge increases 733 for upwards to 1 year. 735 Recently real-time pricing has furthered the ability to save energy. 736 This allows a facility to proactively either use or curtail energy 737 based on the price/KWH of the energy. Again, the HVAC subsystem 738 takes the lead in this application. It can either poll the price 739 structure from the Utility off the Internet, or the current pricing 740 will be forwarded to the facility by the Utility. The HVAC subsystem 741 can then automatically defer unneeded operation or temporarily reduce 742 the cooling or lighting load as the cost warrants. As always, the 743 HVAC subsystem is charged with seamlessly returning the components to 744 their normal operating conditions at the close of the energy event. 746 8.5. Fault Detection and Diagnostics 748 HVAC primary equipment such as air handlers or chillers often have 749 capital expenditure costs in the $100k range. These systems are 750 critical to operation of the building and comfort to its tenants. 751 Contemporary HVAC subsystems can track usage and performance 752 operation of these devices in time and trigger alarms if the 753 performance characteristics fall outside the expected statistic usage 754 profile. This fault detection application can be further enhanced by 755 adding automatic diagnostic modes that define the source problem. 756 The diagnostics evaluation may suggest changing clogged air filters, 757 inspecting a failed pump or even rebuilding the chiller mechanics due 758 to erratic vibration analysis. 760 9. Building Application Protocol Requirements 762 This section contains the overall set of building application 763 requirements as dictated by the previous discussion. 765 9.1. Physical Layer Requirements 767 9.1.1. Wired and Wireless Implementations 769 The protocol MUST support both wired and wireless IP implementations. 771 9.1.2. Cost Effective Wired Installation 773 The protocol MUST support wired media that is readily installable by 774 electricians. Its amortized per connection installed cost SHOULD NOT 775 exceed of the cost of the end device. That is, if the cost of the 776 device is $X; the total installed cost shall not exceed $2X, where X 777 is typically < $75. 779 9.1.3. Cost Effective Wireless Installation 781 The protocol MUST support wireless mesh that is readily installable 782 by electricians. Its amortized per connection installed cost SHOULD 783 NOT exceed of the cost of the end device. That is, if the cost of 784 the device is $X; the total installed cost shall not exceed $1.5X, 785 where X is typically < $75. 787 9.1.4. Global Wireless Applicability 789 Wireless devices MUST be supportable on unlicensed bands (such as the 790 2.4Ghz)that are applicable globally. 792 9.1.5. Constrained Power Sensors 794 The protocol MUST support wireless end devices that operate with 795 battery power or by energy scavenging. These devices will likely 796 sleep with a 99% duty cycle. 798 9.2. Network Layer Requirements 800 9.2.1. TCP/UDP 802 Connection based and connectionless services MUST be supported. 804 9.2.2. Fragmentation 806 Packet fragmentation must be supported. 808 9.2.3. Data Rate Performance 810 An effective data rate of 20kbps is the lowest acceptable operational 811 data rate acceptable on the control networks. 813 9.2.4. Interference Mitigation 815 The wireless network MUST automatically detect interference and 816 migrate the network to a better channel to improve communication. 817 Channel changes and nodes response to the channel change MUST occur 818 within 60 seconds. 820 9.2.5. Real-time Performance Measures 822 A node transmitting a 'request with expected reply' to another node 823 MUST send the message to the destination and receive the response in 824 not more than 120 msec. This response time SHOULD be achievable with 825 5 or less hops in each direction. This requirement assumes network 826 quiescence and a negligible turnaround time at the destination node. 828 9.2.6. Packet Reliability 830 Reliability MUST meet the following minimum criteria : 832 < 1% MAC layer errors on all messages; After no more than three 833 retries 835 < .1% Network layer errors on all messages; 837 After no more than three additional retries; 839 < 0.01% Application layer errors on all messages. 841 Therefore application layer messages will fail no more than once 842 every 100,000 messages. 844 9.2.7. Packet Routing 846 Unicast packets MUST be routable across any two nodes of the network. 848 9.3. Installation and Commissioning Requirements 850 9.3.1. Device Setup Time 852 Network setup by the installer MUST take no longer than 20 seconds 853 per device installed. 855 9.3.2. Unavailability of an IT network 857 Product installation and local commissioning MUST be performed by an 858 application engineer prior to the installation of the IT network 859 including switches, routers, DNS and DHCP servers. 861 9.4. Application Layer Object/Node Requirements 863 9.4.1. Object Model 865 The application protocol must adhere to a well defined object model. 866 This model must support generic objects (e.g. AI, BI, AO, BO) and 867 semantic objects (e.g. temperature sensor, pump, door lock, light 868 ballast) 870 9.4.2. Object Location 872 The protocol MUST optionally support determination of the physical 873 location of a device. 875 9.4.3. Node Discovery 877 The protocol MUST support the discovery and binding of other nodes 878 anywhere on the internetwork by name or address by using a single 879 broadcast or multicast request packet. 881 9.4.4. Object Discovery 883 The protocol MUST support the discovery and binding of two or more 884 objects anywhere on the internetwork by either name or address. 886 9.4.5. Object List 888 The protocol MUST support supplying the entire object list of all 889 objects created in a given node. 891 9.4.6. Property List 893 The protocol MUST support a node returning a complete property list 894 of all mandatory and optional properties defined for a given node. 896 9.4.7. Service List 898 The protocol MUST support supplying the entire list of services 899 supported for a given node. 901 9.4.8. Consistent Error Reporting 903 The protocol must support a rigorous error reporting mechanism that 904 is consistent across all objects and nodes. 906 9.5. Application Layer Solicited Service Requirements 908 9.5.1. Reading Datum 910 The application protocol MUST support a means to read a single piece 911 of data (property) from a targeted node and object. Read requests 912 must be validated via an ACL. The default ACL allows reading of any 913 property. 915 9.5.2. Reading Data from an Object 917 The application protocol MUST support a means to read multiple data 918 items from a targeted node and object with a single request. Read 919 requests must be validated via an ACL. The default ACL allows 920 reading of any properties. 922 9.5.3. Reading Data from Multiple Objects 924 The application protocol MUST support a means to read multiple data 925 items from multiple objects on the same node with a single request. 926 Read requests must be validated via an ACL. The default ACL allows 927 reading of any properties. 929 9.5.4. Reading Data with Wild Cards 931 The application protocol MUST support a means to read multiple data 932 items from multiple objects on the same node using a wild card 933 mechanism. Read requests must be validated via an ACL. The default 934 ACL allows reading of any properties. 936 9.5.5. Reading Large Data Items 938 Whenever an array or list can get larger than what is supported by 939 the MTU or fragmented packet; the object MUST support a means to 940 allow reading the data over multiple requests. 942 9.5.6. Object Creation and Deletion 944 The application protocol MUST support a means to create and delete 945 objects. Creation requests must be validated via an ACL. The default 946 ACL does not allow object creation or deletion. 948 9.5.7. Object Property Writing 950 The application protocol MUST support a means to write for the first 951 time or to modify the current value of a property. Property writing 952 requests must be validated via an ACL. The default ACL does not 953 allow object property writing. Properties are the province of the 954 server and hence, the server may at anytime and for any reason 955 prohibit property writing. 957 9.5.8. Atomic Object Property Writing 959 The application protocol MUST support a means to write for the first 960 time or to modify the current value of multiple properties 961 atomically. Property writing requests must be validated via an ACL. 962 The default ACL does not allow object property writing. Properties 963 are the province of the server and hence, the server may at anytime 964 and for any reason prohibit property writing. 966 9.5.9. Object Property List Writing Addition 968 The application protocol MUST support a means to write for the first 969 time or to modify the current value of a list property. Property 970 writing requests must be validated via an ACL. The default ACL does 971 not allow object list property writing. Properties are the province 972 of the server and hence, the server may at anytime and for any reason 973 prohibit property writing. 975 9.5.10. Object Property List Writing Deletion 977 The application protocol MUST support a means to delete an element 978 from an existing list. The service SHALL error out if the requested 979 list item to be removed is not a element of the list. 981 9.5.11. Downloads 983 The application layer MUST support a means to download data and 984 programs. Download requests are validated by an ACL. 986 9.6. Application Layer Unsolicited Service Requirements 988 9.6.1. Property Value(s) Change Notification 990 The application protocol MUST support a means to request data 991 callbacks on a change to a specified property or object. 992 Subscriptions may timeout at a periodic basis or may be cancelled by 993 the client at any time. Subscriptions must persist a reboot. 995 9.6.2. Alarm Notification 997 The application protocol MUST support clients requesting alarm 998 notification to selected objects. When the object transitions into 999 the 'alarm' state for a predefined time, nodes subscribing to this 1000 alarm will be notified of the state change. Alarm subscriptions may 1001 timeout at a periodic basis or may be cancelled by the client at any 1002 time. Subscriptions must persist a reboot. 1004 10. Traffic Pattern 1006 The independent nature of the automation systems within a building 1007 plays heavy onto the network traffic patterns. Much of the real-time 1008 sensor data stays within the local environment. Alarming and other 1009 event data will percolate to higher layers as alarm events occur. 1011 Systemic data may be either polled or event based. Polled data 1012 systems will generate a uniform packet load on the network. This 1013 architecture has proven not scalable. Most vendors have developed 1014 event based systems which passes data on event. These systems are 1015 highly scalable and generate low data on the network at quiescence. 1016 Unfortunately, the systems will generate a heavy load on startup 1017 since all the initial data must migrate to the controller level. 1019 They also will generate a temporary but heavy load during firmware 1020 upgrades. This latter load can normally be mitigated by performing 1021 these downloads during off-peak hours. 1023 Devices will need to reference peers for sensor data or to coordinate 1024 across systems. Data will migrate from the sensor level upwards 1025 through the local, area, then supervisory level. Bottlenecks will 1026 typically form at the funnel point from the area controllers to the 1027 supervisory controllers. 1029 11. Security Considerations 1031 TBD 1033 12. IANA Considerations 1035 This document includes no requirement to IANA. 1037 13. Acknowledgments 1039 This document was prepared using 2-Word-v2.0.template.dot. 1041 14. References 1043 14.1. Normative References 1045 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1046 Requirement Levels", BCP 14, RFC 2119, March 1997. 1048 14.2. Informative References 1050 [I-D.ietf-roll-terminology]Vasseur, J., "Terminology in Low power And 1051 Lossy Networks", draft-ietf-roll-terminology-00 (work in progress), 1052 October 2008. 1054 Authors' Addresses 1056 Jerry Martocci 1057 Johnson Controls 1058 507 E. Michigan Street 1059 Milwaukee, Wisconsin, 53202 1060 USA 1061 Phone: 414.524.4010 1062 Email: jerald.p.martocci@jci.com 1064 Anthony Schoofs 1065 CLARITY Centre for Sensor Web Technologies 1066 University College Dublin, 1067 Dublin 4 Ireland 1068 Phone: +353 1 7162488 1069 Email: anthony.schoofs@ucdconnect.ie 1071 Peter van der Stok 1072 Philips Research 1073 High Tech Campus 1074 Eindhoven, 5656 AA 1075 Netherlands 1076 Email: peter.van.der.stok@philips.com