Open Protocol for BAS Engineers and Owners?
Common Protocols in HVAC
BACnet TCP or BACnet IP
LonWorks (LON, Echelon)
MODBUS (Master, Slave, RTU, TCP/IP
What is MODBUS?
MODBUS was developed by Modicon (now Schneider Electric) in 1979 as a means for communicating with many devices over a single twisted pair wire. The original scheme ran over RS232, but was adapted to run on RS485 to gain faster speed, longer distances and a true multi-drop network. MODBUS quickly became a defacto standard in the automation industry, and Modicon released it to the public as a royalty free protocol
MODBUS is a “master-slave” system, where the “master” communicates with one or multiple “slaves.” The master typically is a PLC (Programmable Logic Controller), PC, DCS (Distributed Control System) or RTU (Remote Terminal Unit). MODBUS RTU slaves are often field devices, all of which connect to the network in a multidrop configuration, Figure 1. When a MODBUS RTU master wants information from a device, the master sends a message that contains the device’s address, data it wants, and a checksum for error detection. Every other device on the network sees the message, but only the device that is addressed responds.
Slave devices on MODBUS networks cannot initiate communication; they can only respond. In other words, they speak only when spoken to. Some manufacturers are developing “hybrid” devices that act as MODBUS slaves, but also have “write capability,” thus making them pseudo-Masters at times.
The three most common MODBUS versions used today are:
- MODBUS ASCII
- MODBUS RTU
All MODBUS messages are sent in the same format. The only difference among the three MODBUS types is in how the messages are coded.
In MODBUS ASCII, all messages are coded in hexadecimal, using 4-bit ASCII characters. For every byte of information, two communication bytes are needed, twice as many as with MODBUS RTU or MODBUS/TCP. Therefore, MODBUS ASCII is the slowest of the three protocols, but is suitable when telephone modem or radio (RF) links are used. This is because ASCII uses characters to delimit a message. Because of this delimiting of the message, any delays in the transmission medium will not cause the message to be misinterpreted by the receiving device. This can be important when dealing with slow modems, cell phones, noisy connections, or other difficult transmission mediums.
MODBUS RTU, data is coded in binary, and requires only one communication byte per data byte. This is ideal or use over RS232 or multi-drop RS485 networks, at speeds from 1,200 to 115Kbaud. The most common speeds are 9,600 and 19,200 baud. MODBUS RTU is the most widely used industrial protocol. MODBUS/TCP is simply MODBUS over Ethernet. Instead of using device addresses to communicate with slave devices, IP addresses are used. With MODBUS/TCP, the MODBUS data is simply encapsulated inside a TCP/IP packet. Hence, any Ethernet network that supports TCP/ IP should immediately support MODBUS/TCP.
What is oBIX?
oBIX stands for Open Building Information eXchange, and it is an industry wide initiative to define XML – and Web Services-based mechanisms to Building Control Systems.
oBIX came from the Continental Automated Buildings Association (CABA) which created a committee in April 2003 at BuilConn in Dallas, TX. This committee – the XML/Web Services Guideline Committee started the work on what is now known as oBIX.
oBIX is working with both BACnet and LonMark groups to enable oBIX to be the vehicle that allows these systems can be taken to the TCP/IP layer in a consistent manner, and can be integrated with legacy/proprietary systems as well as future native TCP/IP control systems.
The purpose of the OASIS Open Building Information Exchange (oBIX) TC is to define a standard web services protocol to enable communications between building mechanical and electrical systems, and enterprise applications. This protocol will enable facilities and their operations to be managed as full participants in knowledge-based businesses.
The oBIX specification will utilize web services for exchange of information with the mechanical and electrical systems in commercial buildings.
Presently most mechanical and electrical systems are provided with embedded digital controls (DDC). Most of these devices are low cost and not enabled for TCP/IP. They are installed with dedicated communications wiring. Larger DDC controllers provide network communications for these dedicated controllers. There are several well established binary protocols (BACnet, LonTalk, Modbus, etc.) that are used on these dedicated networks in addition to numerous proprietary protocols. While these binary protocols can be used over TCP/IP networks - they have challenges with routers, firewalls, security, and compatibility with other network applications. There is an added challenge in that the industry is split between several largely incompatible protocols.
Because oBIX integrates with the enterprise, it will enable mechanical and electrical control systems to provide continuous visibility of operational status and performance, flagging problems and trends for system analysis or human attention.
oBIX provides a technology that enables facilities operators, owners and tenants to make decisions based on a fully integrated consideration of all life-cycle, environmental, cost, and performance factors.
The scope of the oBIX TC is to develop a publicly available web services interface specification that can be used to obtain data in a simple and secure manner from HVAC, access control, utilities, and other building automation systems, and to provide data exchange between facility systems and enterprise applications. In addition, the TC will develop implementation guidelines, as needed, to facilitate the development of products that use the web service interface. Work outside of the above will be considered out of scope for the TC.
Who is behind oBIX?
oBIX is currently a Technical Committee of OASIS. OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards. The consortium produces more Web services standards than any other organization along with standards for security, e-business, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 3,000 participants representing over 600 organizations and individual members in 100 countries.
Open Protocol Integrations
Trane CVHE (UCM II, CH-530) integrated via BACnet IP to Niagara Framework.
Carrier Air Cooled Chiller (2003) integrted via software Driver to Niagara Framework
Titus VAV box with Schneider Electric DDC Controls integrated via LonWorks to Niagara
Carrier AHU with Invensys DDC Controls integrated via LonWorks to Niagara
Trane CVHE Centrifugal Chiller Integrated via BACnet MS/TP to Niagara. (Field selectable for LonWorks, MODBUS or BACnet MS/TP.)
York Centrifugal Chiller integrated vai MODBUS to Niagara.
rane CVHE Centrifugal Chiller integrated via LonWorks to Niagara
McQuay Centrifugal Chiller integrated via OPM Module to Niagara
Onicon Flow Meters integrated via BACnet IP to Niagara
Trane Intellipak RTU integrated via LonWorks to Niagara.
Boiler with Honeywell Controlls integrated via LonWorks to Niagara
Staefa Talon Controls integrated via JAVA to Niagara
Carrier 75 Ton RTU integrated via Carrier Driver to Niagara
BACnet IP-Honeywell, BACnet MS/TP- McQuay RTU, MODBUS TCP-Allen Bradley, LON-Honeywell, LON-McQuay, MODBUS-Square D, MODBUS-Veris, MODBUS-AMTEK, MODBUS-Mitsubishi, BACnet MS/TP-Schneider Electric
ADI Firefighter Smoke Control to Niagara
Riverbend Chiller Graphic
Sample Time of Day Programming Screen
Riverbend Chiller Graphic
Phoenix Fume Hood Graphic
VAV Box Graphic
Hot Water System Graphic
AHU Graphic LON Controls
Time of Day Control
Scheduling of equipment or systems is a simple as swiping across the hours or days to add/delete or modify operating schedules.
Trane BACnet IP, Veris MODBUS, Onicon BACnet IP Architecture
|Integration to Trane (BACnet IP), Veris (MODBUS), Onicon Metering (BACnet IP) by Niagara Framework|
|Original System: 1990 thru 2000||Trane Tracer 100 w/BMN Software, PCM's, UPCM's, SCP's, Centravac's chillers, Series R chillers Voyager RTU's. Proprietary Comm 3, Comm 1. (proprietary)|
|Expanded: 2005||Trane Summit BCU and Software added with 1 centrifugal chiller Comm 4 as separate system in parallel with Tracer 100 (proprietary).|
|Integration: 2006||Niagara Framework installed and integrated to Centrifugal chillers, UPCM's controllers on proprietary Trane Comm 4 link.|
|Integration: 2007||Invensys MNB-1000s replaced proprietary controls on towers, pumps and VFD's using open protocol BACnet IPcontrollers, communicating over the plant (IP) Ethernet network.|
|Integration: 2008 thru 2010||MNB-1000's replace proprietary controls on AHU's with BACnet IP controllers, installed Veris Power Meters on 12 Process Air Systems with MODBUS communication, BACnet IP controllers installed on Sterilizer Heat Recovery Systems, Onicon Flow Meters installed with BACnet IP integration. Plant Ethernet used for all communications to BAS.|
|Open Protocol Integrations via LonWorks, MODBUS and OPM to Centrifugal Chillers.|
|Original Systems: 1990's||Invensys Signal Software and 8000 ASD proprietary controls over AHU's, pumps, towers. OPM to McQuay chiller, MODBUS to York chiller, LonWorks to Trane chiller.|
|Upgrade: 2000||Niagara Framework .|
|Integration: 2009||Driver installation that replaced proprietary Signal software and integrated ASD proprietary controls and chillers to Niagara Framework.|
General architecture for three separate centrifugal chiller integrations to Niagara Framework.
York Centrifugal Chiller
Some of the information integrated via a communications interface from 1990's York chiller to Niagara Framework.
Trend Log Space Temp
Each and every data points most recent 72 hours of history is immediately available by clicking on the point on the graphic screen. Long term historical archives of this data are stored so all data is trended and stored for evaluation or export to other databases.
LonWorks RTU Integration to Niagara
|Open Protocol Integration with Trane Comm 5 (LonWorks) to Niagara Framework|
|Standalone Original Equipment : 2003||LonWorks controls on standalone RTU Voyager and MP Series controller on pumps, boiler and heat exchanger.|
|Upgrade: 2000||Niagara Framework installed on Campus|
|ntegration: 2009||LonWorks Commuincaiton extended from Niagara Controls to Trane RTU, MP controller and Invensys LonWorks controls on AHU's.|
Communication Architecture of LonWorks (Trane HVAC) and Invensys LonWorks integrated to Niagara Framework.
McQuay Chiller Integration
York Chiller MODBUS Integration
|Open Protocol Integration with MODBUS to York Centrifugal Chiller|
|Original System 1990's||Invensys Signal Software and Network 8000 proprietary controls on AHU's, pump's tower's, boiler's.|
|Upgrade to 2000||Driver installation that replace Signal Software and integrated York chiller via MODBUS and Network 8000 driver.|
Graphic Screen with data from York Centrifugal chiller via MODBUS integration.
Graphic screen with expanded data from York Centrifugal chiller via MODBUS Integration.
Carrier Driver, Trane BACnet IP and LonWorks Integration
|Integration using LON, BACnet IP and Carrier Driver:|
|Original System:||Trane Tracer 100 with BMN Software|
|nstalled in Early 1990's||Comm 3 Link with PCM's, FCU and CGA (air cooled chiller)|
|System Upgrade: 2003||Replaced Tracer 100 with Summit System for BACnet IP Integration to Niagara Framework.|
|Integrated System: 2003||Invensys Niagara Framework (Enterpriser Server) with:|
|BACnet IP to Summit System, Carrier Driver integration to Carrier air cooled chiller and 75 ton RTU,|
|LonWorks integration to Invensys AHU controls, LonWorks Integration to Invensys VAV controls.|
|LonWorks integration to Invensys controls on VFD's and air rotation unit.|
York Chiller OPC Integration
|Open Protocol Integration with OPC to York Centrifugal Chiller|
|Original System Mid 90's||Invensys Signal Software and Network 8000 controls on AHU's, Pump's, towers' and VAV|
|Upgrade 2008||Driver installation that replaced Signal Software and integrated Network 8000 Controls into Niagara Framework.|
Graphic Screen with data from OPM integration to McQuay chiller and Network 8000 integration to DDC pump and tower controls.
Graphic Screen with expanded data from OPM integration to McQuay Chiller.
MODBUS Integration to Boilers
MODBUS Integration to Boilers via Niagara Framework
Smoke Control Systems
What is the UL 864 UUKL/UUKL7 Listing?
How do you apply these requirements in a shared BAS/Smoke Control System?
According to Underwriters Laboratories, the UL 864 UUKL/UUKL7 is a category that has been established for Smoke-Control System Equipment.
"The products covered by this category are intended to be installed in conjunction with heating-ventilating-air conditioning (HVAC) equipment to form a system for controlling the flow of smoke in a building during a fire condition in accordance with Smoke-Control Systems, NFPA 92A or 92B".
In need of integrating Building Automation with UL rated Smoke Control Systems. Trying to deal with the myriad of control or code issues related to UL/UUKL 864 in commercial buildings.
Let CS3 help with UL864 Systems!
Sample of a fire fighters smoke control panel per UUKL with shared HVAC and smoke control elements. (CHW/HW RTU AHU's with smoke dampers in unit and on each floor and VAV units on distribution side. Monitored end switches on all dampers, monitored control relays, manual override switches, color coded status lights, Ethernet network with required timing elements for all control actions).