Intelligent System Integration for Facility Dashboards and Green Kiosks

Transcription

1 ASHRAE Summer Meeting 2012 San Antonio, TX Intelligent System Integration for Facility Dashboards and Green Kiosks Ron Bernstein Chief Ambassador LonMark International

2 Learning Objectives: Define performance requirements for dashboard protocols. Discover additional sources of information associated with their buildings that can be displayed in a facility dashboard. Describe techniques to integrate several sources of data into a single front end display. Explain how facility operators and end users can use building performance dashboards to reduce energy use. Explain how building operators can interpret their energy usage profile information. Leverage web services as a means for end users to create custom dashboards to suit their needs. ASHRAE is a Registered Provider with The American Institute of Architects Continuing Education Systems. Credit earned on completion of this program will be reported to ASHRAE Records for AIA members. Certificates of Completion for non-aia members are available on request. This program is registered with the AIA/ASHRAE for continuing professional education. As such, it does not include content that may be deemed or construed to be an approval or endorsement by the AIA of any material of construction or any method or manner of handling, using, distributing, or dealing in any material or product. Questions related to specific materials, methods, and services will be addressed at the conclusion of this presentation.

3 Graphical User Interfaces The Old Standard One Size Fits All WYSIWIG What You See Is What You Get

4

5 How Many User Interfaces Do You See?

6 How Many User Interfaces Did You See? PC Monitors 3 Cell Phone Android Telephone 2 ipad Bluetooth Headset 2 Mouse, Keyboard (4), Mic, Video Camera Scanner, Speakers, AV Remote Clock

7 UNC Chapel Hill Control Center 12 UI Screens

8 Utility Monitoring & Control System One or more operator workstations (PC or laptop) for monitoring, management, programming, configuration, and/or O&M (UMCS) Ideally part of a base-wide system where building-level DDC systems are networked together Networked systems can transfer data between building DDC systems and UMCS computer(s) Source: US Army Corps Fort Hood / IMCOM BAS Workshop Slide 8

9 Multi-vendor DDC results in multiple software tools, laptops, and dongles Proprietary supervisory architecture What s The Problem? Multi-vendor DDC is inevitable due to the Government s Varied & incompatible building systems Non-interoperable systems Overall a great deal of complexity and significant challenges for O&M staff, construction inspectors, and end users competitive procurement rules. Fort Bragg s 12 O&M laptops (and counting) Source: US Army Corps Fort Hood / IMCOM BAS Workshop

10 What is the Solution? One (integrated, multi-vendor) system with no future dependence on any one contractor or controls vendor. in other words An OPEN System Source: US Army Corps Fort Hood / IMCOM BAS Workshop Slide 10

11 Open System Characteristics 1. One system. Multiple buildings with controls installed by multiple vendors are integrated into one system. 2. One common front-end that provides users with the capability to interface with all buildings (monitoring, supervisory control, etc.). 3. One common tool for network management. One common tool for device configuration. 4. No future need for the original (installing) contractor. Additions, modifications, and retrofits can be easily (without significant additional cost) made to the system without dependence on the original contractor nor require substantial engineering or other technical development. Source: US Army Corps Fort Hood / IMCOM BAS Workshop Slide 11

12 Information Access The Key Alarming Control Monitoring Setpoint changes Overrides Schedule changes Maintenance scheduling Event reporting Quality control Energy Management Enterprise wide consistency 12

13 Information Access The Key And I want it from my browser From any computer on my network Or from home With different access levels for different personnel needs With my full campus integrated into one system And all of my subsystems working together To simplify my facility management Alarming Control Monitoring Setpoint changes Overrides Schedule changes Maintenance scheduling Event reporting Quality control Energy Management Enterprise wide consistency And reduce my operating costs! 13

14 Total Facility Control Access to Data Layer Stakeholder Data level Data Types Examples Enterprise Campus/ District Premises/ System Zone Room Owner/Master integrator/facility Staff/Application Developer/Aggregator Owner/Master integrator/facility Staff/Application Developer/Aggregator Owner/Integrator/Facility Staff/Application Developer User/Occupant/ Manufacturer/Vendors/ Integrators User/Occupant/ Manufacturer/Vendors/ Integrators 5, 6 - Aggregate, Monitor, Report 4, 5 - Schedule, Report, Monitor 3, 4 - DR, Load shed, control, monitor, schedule 2, 3 - Status/Mode/Scene, schedule 2 Status Mode Scene Energy savings, pricing, reporting/monitoring, scheduling Alarms, Monitoring, Scheduling, Energy Data, Energy mode, ADR Signals, Alarming, Scheduling Occupied mode, Load Shed mode, Lighting scene Occupied mode, Load Shed mode, Lighting scene Device Manufacturer/Vendors Integrators 1 - on/off/control, low level data Temp, pressure, status, set points, mode, scene

15 WYSIWYNTS User Focus Interface What You See Is What You Need To See Nothing more, nothing less On any Platform

16 The Scope Enterprise GUI - USER APPS Alarms, Reports, Control, Monitoring, Load Shed, Demand Limiting, Financial Performance Campus Utility Indoor Facility Outdoor Facility Energy Building Demand Response HVAC Lights Parking Irrigation Street Lighting Metering Sub Billing

17 System Integration FIRE Functionality checks Detector service Valve Pressure Fire, Life, Safety SECURITY Doors PIR Integration ACCESS Doors Buildings Occupancy Feed Forward ENERGY Appliances Electronics Utility Monitoring (Elec/Water/Gas/Oil) Load Shedding Air/Water Heat Lighting Solar Generation Service Provider Application Interfaces E G W Remote Monitoring and Control LIGHTING Indoor/Outdoor: Schedules Occupancy Sensing Appliances Breakdown Maintenance Performance Home Electronics Audio Video Computers 24/7 Monitoring Service/Maintenance Demand Response Conditioned Monitoring Vehicle Charging HVAC Air-Handling Unit Boilers Pumps Fans Energy Control Hot Water Heaters Air Quality

18 Convergence Of Two Separate Worlds Control Data Internet IP FAX ERP Systems 18

19 With it you have One Complete System Control Data Control Networks LON BACnet Zigbee Modbus DALI Etc. Interoperability Standards IP FAX Internet Ethernet ERP Systems 19

20 A Single Cohesive Network Internet IP Routers Company WAN

21 Integration Examples Sharing data from sensors Occupancy sensor data used by HVAC, Lighting, and Security Energy consumption data Used by demand limiting control strategy Real time adjustments via control system Scheduling by office workers Direct control over environment Lighting, HVAC, Security Alarm management Single alarm, multiple recipients Remote acknowledgement and response Preventative maintenance based upon actual usage 21

22 Cross Platform Integration Project Enterprise Applications Any TCP/IP network Smart Access Control Smart Elevators Smart Lighting Smart Metering Smart Grid Smart Buildings Smart Renewables

23 Control Networking Platform For Smart Buildings Enterprise Applications PC, MAC, Android, iphone Any TCP/IP network Building to enterprise Interface: protocol agnostic Building to enterprise Interface: protocol agnostic Building to enterprise Interface: protocol agnostic Building to enterprise Interface: protocol agnostic Smart Buildings Smart Campuses Smart Buildings Smart Branches

24 Standards-based Communication Open at every level of the architecture IP Any TCP/IP network Enterprise Applications PC, MAC, Android, iphone IP/852 Modbus M-bus LonWorks BACnet/IP DALi EnOcean Zigbee SOAP/XML Modbus M-bus LonWorks Other IP-852 BACnet/IP ISO/IEC14908 Smart Buildings Smart Campuses Smart Buildings Smart Branches

25 Smart Building Grid-Aware Building Individual Control Smart Building Grid-Aware Building HVAC Control LonWorks Lighting Control BACnet Data Ops Building Control Stove-piped functions (silos) Multiple front-ends Proprietary Partial integration across silos Multiple open protocols Comms link to Internet Multi-protocol, cross-silo framework for new applications Dynamic load modulation Fine-grained load control

26 Platform Example in Smart Building Need: Open at every level From System to Device Enterprise Applications Energy Analytics Energy Asset Management Automatic Demand Response Peak Day Pricing Facility Management Any TCP/IP Any TCP/IP Network network Local IT Network Subsystem Interfaces Device Level Network LonWorks BACnet Modbus, KNX DALI, M-bus EnOcean

27 Local Hosted or Cloud Solution Analytics App Local Server Virtual Network Enterprise Server Reporting App O&M App Alarming App Remote GUIs/Apps Data Server Appliance XML/SOAP FTP/CSV Web Service L E V O T W G Modbus LON MBus Pulse Count PMU Pulse Count Pulse Count Apps Apps Apps Apps Local GUIs/Apps Standard data format via XML/SOAP Standard Profiles and Web Service Maintenance issues Ownership issues Scalability issues

28 Common App Model Mix and match best-in-class subsystems one App interface Integrate LonWorks, BACnet, DALI, Zigbee, Modbus systems across IP Define common App interface using LMI Profile model Enable App independence from control network Multiple device networks LonWorks, Modbus, M-bus Co-develop by LMI, ASHRAE, DALI, Zigbee, TC-247,??? App 1 App 2 App n Subsystem Driver Level Interface LonWorks DALI Modbus BACnet, Zigbee OpenLNS Device Network SOAP/XML Enterprise Common Profile Model BACnet Sub-System Zigbee Sub-System Enterprise Network Local IT Network Field Level Network

29 Enterprise Application Interface Standard Users Analytics App Standard profile model Start simple 10 profiles Reduce application interface complexity Reporting App XML/SOAP O&M App Common Profile Model Web Service Alarming App Host applications interface is protocol agnostic Commonality, normalization Unbundle the app from the controls Data Server Appliance Data Server Appliance Data Server Appliance LonWorks System Modbus System BACnet Sub-System Zigbee Sub-System EnOcean System DALI System KNX System

30 Top Down - User Perspective User allowed to pick and choose Apps based on need, not bells and whistles Solution is more open, less bundled Easier to specify multi-tier solutions App providers have common interface model to build to Lowers the cost for Apps Increases flexibility for integrators, installers Greater choices of Apps drives down cost Better scalability across subsystems

31 Standards Roadmap # Layer Name Status 11 Enterprise/Front End API Application Interface Web Services, SOAP/XML Proposed to TC-247 and BACnet Committee Chairs 10 Self Installation ISI ANSI in-process needs 9 9 Open Management API LonWorks Network Management Platform Propose an API Model for Any Protocol Open LNS 8 Guide Specification Two-tier system specification Working w/ashrae GPC-13 New work item at CEN 7 System Resources/Services 6 Device Resources/Services 5 Implementation Guidelines Scheduling, Alarming, Room, Trending, Overrides, DR, Standard Variables, Config. Props, DRFs LonMark Device Implementation Guidelines New work item LMI Services Task Group EN Approved, awaiting final EN Approved Submit to ISO after IP Connectivity IP-852 Routing/Tunneling Awaiting publication 2, 3 Media Free Topology, Powerline Awaiting publication 1 Protocol LonWorks Awaiting publication

32 CEN/ISO/LONMARK/ASHRAE +? Working Together To Create New Host App Interface Model Problem: Host App interface independence from control network protocol Enable App developers to work with any sub-system Protocol agnostic networks interface to host Apps Application independent interface model co-developed Scalable solutions for any application Support new interface and driver products from multiple suppliers Sub-system level drivers/interfaces implementing in local data servers Common data modeling Web Services using SOAP/XML Potential for network management tools for managing multiple protocols in one tool environment

33 Summary User interfaces should support the user System design from a Top Down approach Facilities are and will continue to be multiplatform, multi-protocol New open App standards are needed The greater the flexibility and interoperability the greater the usability and value Its not the technology, it s the people!