3 Cybersecurity Steps to Reduce Threats to your Electrical System

 3 Cybersecurity Steps to Reduce Threats to your Electrical System

When anyone mentions cybersecurity, you may automatically think they are referring to IT systems. That is because protecting IT networks – and their associated personal, financial, and other proprietary data – has been the responsibility of IT professionals for an exceptionally long time. But what about your operational technology (OT) infrastructures? Are they also at risk from cyberattacks? How can you protect them? In this post, we’ll discuss these questions, and three specific recommendations for protecting your electrical systems.

The electricity subsector cybersecurity Risk Management Process (RMP) guideline was developed by the Department of Energy (DOE), in collaboration with the National Institute of Standards and Technology (NIST) and the North American Electric Reliability Corporation (NERC).

OT Cyberattacks: An Increasing Threat

The Ponemon Institute emphatically states that, “Cyberattacks are relentless and continuous against OT environments.” In a survey of over 700 organizations from six countries they found that 50 percent had experienced a cyberattack against their OT infrastructure within the last two years that resulted in downtime. For large and critical operations, this can be devastating.

All you need to do is follow the news to see frequent examples of such attacks. For example, in early 2021, the fast action of a technician narrowly avoided the risk of thousands of people being poisoned due to a hacker gaining access to a Florida city’s water treatment plant. Going back a few years, a breach that came through the HVAC system caused international retailer Target to have 40 million credit and debit card accounts compromised, costing them $290 million.

 

The latter example is just one of many that show why building systems are now widely recognized as OT attack targets. The evolution toward smarter buildings is causing an explosion in the numbers of connected devices – already an estimated 200+ million in commercial buildings alone. With more devices comes more data that needs to be protected, but for facility and business management teams to extract the maximum value, data must be aggregated and shared across OT and IT systems.

This OT/IT interconnection means that a cyberattack on an OT system can:

·        Compromise operational safety or the health of building occupants

·        Impact productivity by taking down production lines or other equipment and processes; more about the relationship between Cybersecurity and Productivity.

·        Ultimately cause an IT threat by passing malware or a virus from the OT to IT infrastructure

The Attack Surface is Now Larger

Essentially, connected OT infrastructures have increased the ‘attack surface’ for hackers and, in many cases, have acted as an organization’s Achilles heel. Clearly, it is not enough anymore to focus attention only on protecting IT and data systems integrity. All organizations must ensure strong OT cybersecurity is in place.

But what OT systems are we talking about? Depending on your type of operation, these can include industrial automation systems (e.g. SCADA) and smart building systems like a building management system (BMS), building security, lighting systems, and the energy and power management system (EPMS) overseeing your facility’s electrical distribution. Navigant Research notes, “Cybersecurity issues are expected to grow in tandem with the digital transformation of real estate through intelligent building technologies.”

In this post, we will consider cybersecurity specifically for your EPMS and electrical distribution system. However, these recommendations and practices equally apply to other OT systems.

Connected Power Means Greater Vulnerability

Energy and power management systems are helping organizations boost efficiency and sustainability, optimize operating costs, maximize uptime, and get better performance and longevity from electrical assets. When combined with BMS, an EPMS can also help make the work environment healthier and more productive for occupants.

Enabling these EPMS benefits is a connected network of smart metering, analysis, control, and protection devices that share data continuously with onsite and/or cloud-based EPMS applications. The application provides extensive monitoring and analytics while providing mobile access to data and alerts to all facility stakeholders. Connection to the cloud also opens the door to expert power and asset advisory support that can augment a facility’s onsite team with 24/7 monitoring, predictive maintenance, energy management, and other services.

All these onsite, cloud, and mobile connections offer a potential target and entry for hackers so you can read our facility managers guide to building systems and cybersecurity.

 

Securing Your Electrical System: A Holistic Approach

A hacker only needs to find one ‘hole’ in one system, at one point of time, to be successful. What you need is a holistic approach to ensure that all potential vulnerabilities are secured. For new buildings, cybersecurity best practices should be a part of the design of all OT systems. For existing buildings, cybersecurity should be addressed when OT systems are starting to be digitized. For both scenarios, the following are three key considerations:

1. Seek Specialized, Expert Assistance

The priorities for IT systems are confidentiality, integrity, and availability. For OT, the top priorities are safety, resilience, and confidentiality. This means that OT security upgrades or problems need to be addressed in a different way from IT, with careful planning and procedures. For these reasons, you need to choose a cybersecurity partner who has proper OT experience, to help you comply with all relevant cybersecurity standards and best practices.

OT systems also use different communication protocols compared to IT systems, such as BACNet, Modbus, etc. If you had your IT team attempt to perform OT security system scans, those scanning tools might cause serious conflicts, risking an OT system shutdown.

Cyberthreats are also constantly evolving, so you should seek a partner who offers ongoing OT monitoring services, updates, system maintenance, and incident response. All of these should be available remotely.

2. Put the Right Controls in Place

An OT cybersecurity specialist will help audit your EPMS and electrical systems to assess the current vulnerabilities and risks, including the gaps in any procedures and protocols.

You and the specialist must determine how secure your electrical system needs to be. The IEC 62443 standard helps protect IoT-enabled OT systems by defining seven foundational requirements (e.g. access control, use control, availability, response, etc.), each of which are designated a security level. Increased security levels offer greater protection against more sophisticated attacks. Your cybersecurity partner will help you determine the level of security you need for each requirement.

An example of one technique for securing networked systems is to break up systems into ‘zones,’ with each secured individually. OT will be separated from IT, and within OT there may be further segregation. A special ‘demilitarized’ zone is typically included, which is a perimeter subnetwork that sits between the public and private networks for an added layer of security. This makes it harder for hackers to find a way in from one system or zone to another. Where required, connections between networks are provided by specially secured data ‘conduits.’

Your electrical system should also be physically secured, with no access by unauthorized personnel. This same strategy applies to EPMS communications network security by means of controlled, multi-tiered permission-based access.

3. Train your Staff

Many cyberattacks are successful because employees have caused unintended errors. It is important that your people become aware of, and vigilant against, cyberthreats. This includes giving your operations team specialized OT cybersecurity training.

This training will typically include multiple steps, including training all individuals to spot social engineering cues, such as phishing attempts or attempts to access protected areas using pretexting (i.e. someone pretending to be a vendor to gain access). This will also include establishing protocols around the use of passwords, multi-factor authorization, policies around WiFi access (e.g., guest network that remains isolated from OT networks), regular auditing of user accounts and permissions, etc.

While the horizontal cybersecurity framework provides a solid basis, specific characteristics of the energy sector such as the need for fast reaction, risks of cascading effects and the need to combine new digital technology with older technologies necessitate specific legislation.

Thanks to Felix Ramos & Khaled Fakhuri to write this article.

DDC in BMS System

 DDC or Direct Digital Controller in BMS System

What is DDC ?

To understand the DDC, we need to know a little bit of history about what was the things before the DDC invention and why it was invented? So that we can have a broader view of the primary purpose of DDCs.

The Programmable Logic Controller or PLC used to control and monitor the Process mainly in the industry like automobile and other manufacturing factories.

Richard Morley invented PLC in 1968 to fulfil the primary needs of control and protect the production capacity of machines and manufacturing lines in the industry, and this PLC used initially was in the area of transfer lines in automotive plants.

Due to these PLC or Programmable logic controllers were designed and invented mainly for controlling and monitoring or automating the productions in the industry.

But when it comes to buildings, this PLC cannot fulfil the exact needs in terms of tenants comfort, environmentally green or can say effective management system for buildings. And still, we can use PLC for Building automation whereas it will be an excessive investment and different performance.

So here DDC or direct digital controller invented in order the process and automated the building equipment needs almost which PLC can do with minimal investment from installation to engineering.

What is the Main Difference between PLC and DDC?

What is DDC or Direct Digital Controller?

In a nutshell, DDC is a controller which use the analogue or digital signals from various devices of a field sensor and actuators and then process and control the system based on the programme written inside the controllers and has the capability to sends the information to another controller or DDC.

Basic Features of DDC

·       DDC or Direct digital controller usually has the followings features

·       The Analogue Inputs is to monitors the fields sensors values.

·       Digital Inputs to monitors the on/off status from switches/contactors.

·       The analogue output is to control the field actuators devices.
Digital Output is to control relay or provide low voltages.

·       DDC must have internal ROM/RAM to store control logic and sensor values.

·       It must have networking protocols inbuilt to transfer the data between the devices.

·       Modern DDC controller should have the capability to implement BACnet protocols for communication.

Note that there are various DDC controllers available in the market from the different manufacturer and those DDCs are available with a variety of function and features based on the specific needs like controller has all inputs/outputs like Analog inputs, Digital input, analogue output and digital output and some controller has only digital/analogue inputs.

Let us see below DDC Controller

·       Eleven 10-bit universal inputs whereas we connect either analogue input or digital input using a jumper select, eight binary outputs, and eight analogue outputs.

·       Terminal 23,24 used to connect other DDC controller to communicate between devices through BACnet over MSTP.

·       It has non-volatile memory used to store program and work independently.

·       It has the 24vdc used to give power for field devices.

Now Let us see how DDC used to control the BMS System,

Consider the followings scenario which we need to control and monitor through above DDC.

Let us say in Building, we need to control Pump control and control filling sequence through DDC whereas we have 2 Booster pumpS, one is for filling the water tank and other is to pump the water to buildings purpose to tenants like toilet etc.

This two-pump motor is controlled through the pump control panel by manually and it should work automatically based on the following sequence 

·       Pump-1 should run if the water level below the high level and stops once above the high level.

·       Pump-2 should run if the pressure on the supply line lesser than the defines let us say 2.5bar.

·       Pump-2 Should not run if water lesser than the lower level switch even pressure lesser than defined.

So based on the above sequence we will have following parameters to monitor and control

·       Booster pump-1 Run status from control panel-Binary Input

·       Booster pump-1 Run command from control panel-Binary output

·       Booster pump-2 Run status from control panel-Binary Input

·       Booster pump-2 Run command from control panel-Binary output

·       Water Low-Level status-Binary Input

·       Water High-Level status-Binary input

·       Liquid pressure on supply line-Analog Input

Let us connect the above points in DDC Controllers as follows

BP-1 Run sts- IN-1

BP-2 Run sts- IN-2

Low-Level Sts- IN-3

High-Level Sts-IN-4

Liquid Pressure-IN-5

BP-1 Run Command-BO-0

Bp-2 Run Command-BO-1

 

Logic will be as follows to execute the above sequence

 

If IN4==1        ##(means lesser than high-level status)

then

BP1=1             ##(On Pump)

else                 ##(means above than high-level status)    

BP1=0             ##(Off-Pump)

endif

 

If (IN5<2.5 and IN4==1)    ##( if pressure lesser than 2.5bar and water above the low-level sts)

then BP2=1     ##(on Pump)

else

BP2=0             ##(Off-Pump)

endif

 

Note that this program may change for each vendor controllers.

Not only this small sequence but also DDC can execute complex and critical sequence in BMS System for HVAC.

SSA Integrate - Fire alarms and BAS

SSA Integrate - Fire alarms and BAS

The integration of Building Automation System and fire alarm systems can result in overall reduction in equipment, installation, and maintenance costs while still maintaining the level of safety required for these systems to operate. 

With the advent of smart building technology, heating, cooling, electrical, lighting, security, and other systems need monitoring and intercommunication for optimized efficiency and operation. With sophistication comes the need for a building automation system (BAS) to allow for nearly seamless operation of these various interrelated equipment.

When the fire alarm system takes control of equipment that is not a listed component of the fire alarm control unit, the fire alarm system must either override the natural operating mode of the building equipment or pass off that command via a simple switch or data communications to the building mechanical systems. Likewise, each manufacturer’s BAS has its own protocol for monitoring conditions and communicating operational commands to maintain the proper building environment and efficiency. There are also standard open communication protocols such as LonTalk and BACnet that can be used to communicate with a multitude of equipment from various manufacturers in order to achieve an integrated building system. 

The communication protocol for a fire alarm control unit to communicate to and from its indicating (input), initiating (output), and sometimes notification appliances is typically an analog or digital communications signal carried over what is referred to as a signaling line circuit (SLC). Because communications signals are typically proprietary protocol, each SLC is dedicated to a specific manufacturer’s equipment and cannot include connection of incompatible devices that use a different signal protocol.

Therefore, in order to integrate system alarm and control functions with the BAS in a manner other than relay logic, fire alarm system manufacturers had to also design and support the open communication protocols used for building automation, in a manner that would not compromise the integrity or the operation of the fire alarm system. This process of sharing information between both fire alarm and BAS came to be known as bridging, or open gateway processing. Because of the strict code and listing requirements of fire alarm systems, much of this communication has been primarily limited to one-way communication. However, some manufacturers of both fire alarm and BAS do produce equipment such as gateways that are listed for bi-directional communication with their equipment. 

Make a case of a building with separate building automation and fire alarm systems: When the building engineer receives a call from an occupant complaining about increased temperature or whistling air within the ductwork and finds that the fan is shut down or a damper is closed, the building engineer is more apt to call a controls contractor to investigate the problem before he calls their fire alarm service provider. Should the problem be related to an override of controls by the fire alarm systems, not only does the building engineer have to wait for the controls contractor to diagnose the problem, he also has to call the fire alarm contractor to come out and fix the problem. This process can take time to correct; meanwhile, building occupants are uncomfortable and inconvenienced.

Sometimes this can even lead to finger-pointing between the two service providers as to whose problem it really is. In this scenario, the fire alarm control of a fan or a damper is required to be ahead of the hand-off-auto switch for the power to the equipment so the inadvertent shutdown of the equipment does not inhibit the operation of the fire alarm feature. A failure of the fire alarm system control relay could shut down the fan or close the damper without an alarm being present on the fire alarm system or fault condition occurring on the fire alarm control unit. 

Because many components that affect air and smoke movement within a building are shared between HVAC and fire alarm systems, let’s take a step backward in the evolution of the building process. When building systems are being commissioned for proper operation by either an authority having jurisdiction (AHJ) or an independent third-party group, coordination must occur between multiple trades. At this point in the construction process, each trade is independently looking to complete its own scope of work and more often than not is under pressure to finish the specific scope in a designated timeframe. Sometimes this leaves a disconnect between the fire alarm and mechanical trades that results in disruption during start-up and commissioning. 

The integrated system approach allows for those individuals responsible for controlling air movement to be focused on proofing and balancing the mechanical system, while the fire alarm contractors focus on the detection and annunciation of the alarm events. Much in the same manner as referenced in the previous example, the problems can get resolved more expeditiously and the systems can be brought on-line. 

If we focus on the installation of a building management system (BMS) and a fire alarm system, we see many similarities. Each of these control systems is classified as low-voltage systems that communicate to their respected devices through an analog or digital signal. Their wiring methods and materials are similar, and often their respective equipment is located in the same general area and is performing the same basic functions with one significant difference: the fire alarm system uses individual point addressable monitor and control modules while the BAS uses digital input/output driver assemblies that communicate with different protocols. 

Why is this important? Because the BAS still requires individual pairs of conductors to each point being controlled or monitored by the digital input/output module, resulting in more wire being needed and longer installation time.

When considering SSA system integration, the ability of the BAS to control a smoke control system operation falls under the auspice of the jurisdiction’s building code, often based on the model building codes. The IBC has been adopted by a large portion of the United States and is used in this article as an example. IBC Section 909 covers smoke control systems, the procedures for determining system parameters, the acceptable methods that may be used to accomplish smoke control, and the requirements to document the system’s actual performance. It recognizes that the smoke control system is a life safety system and must maintain the same high level of reliability required for any type of fire protection or fire alarm system.

Section 909 requires smoke control systems to be initiated by sprinkler system or smoke detection system operation, depending on the type of system being designed. It also requires systems providing control input or output to the mechanical smoke control systems to comply with Section 907 (Fire Alarm and Detection Systems) and NFPA 72: National Fire Alarm and Signaling Code, and states that such systems must be equipped with a control unit that complies with UL 864 and has to be listed as smoke control equipment.

Using a fire/smoke damper that is part of an engineered smoke control system complying with International Building Code Section 909 as an example, at each damper location we have a smoke detector for detection of smoke, an actuator that controls the opening and closing of the damper, and an end switch to provide positive confirmation of the damper open and closed position. Because the fire alarm system already needs to have circuitry to this location for individual smoke or duct smoke detectors, that same pair of wires can be used to monitor the open and closed position of the damper, essentially eliminating two pairs of wires back to the BAS controller. The position status signals of the damper can then be transmitted from the fire alarm system, through the gateway, and into the BAS along with the active alarm point information. This leaves the wiring to the actuator as the only BAS wiring needed at the damper location.

As another example, let’s use a stairway pressurization fan that is being controlled by a variable frequency drive (VFD). Typically, a VFD would be connected to the BAS via a digital signal while the fire alarm system would provide override of the VFD using dry contacts to stop it or put it into a smoke mode condition. Allowing the BAS to perform all of the control functions permits the adjustment of the fan speed through the BAS to regulate for atmospheric conditions by employing other equipment connected to the BAS, such a digital differential pressure sensors. Using the BAS solely for control eliminates any connection to the fire alarm system, with the activation commands being sent through the gateway.

Taking advantage of the aforementioned efficiencies gained by integrating the BAS with the fire alarm system requires planning in the design process. This planning process is the same whether it is a design build or a design assist type of project delivery. The building owner and operator must be involved in the process of establishing the design criteria or at the least have influence over it. In a typical design build or design assist process, the integration of these two systems is an afterthought and often never considered. The end user must be made to understand that the efficiencies gained by integration will pay dividends long into the lifecycle of the building.

Integrated systems require enough time to test and to verify that the system interoperability is functioning properly. It is important that the engineer as well as the installing contractor and the equipment vendors understand the impact of these requirements on providing an approved and code compliant installation. 

Due to the complexity of these systems and the required integration, testing must confirm that the functions and sequences work correctly under both automatic and manual modes.

The inspection and testing of integrated systems is usually exasperating and time-consuming, and often requires multiple rounds of retesting before all the deficiencies are corrected. This is often caused due to all of these different systems being completed late in the schedule and not enough time to “get the kinks out” prior to final testing. Anything that can expedite the commissioning process is beneficial to the overall project. 

One of the advantages of using the BAS as an integrated part of the smoke control system is the system’s ability to modify operating conditions to accommodate actual ambient conditions through the use of VFDs. The design of smoke control systems is based on many variable conditions, including temperature, wind conditions, and the quality or “tightness” of the construction. These conditions tend to make testing and adjusting of the smoke control system difficult at best.

Integrating BAS can help minimize test stress by adjusting the fan speed of individual fans through programming. In a situation of excessive stair pressurization, the individual fan can be adjusted to limit its airflow to the stair, resulting in a lower level of pressure affecting door opening forces. Similarly, for individual zone smoke control system performance, the fan speed can be adjusted on a zone-by-zone basis, based on the fire alarm signal received by the BAS. 

The downside to this operation is that the BAS controls are typically located remotely to the fire alarm control panel and the firefighters’ smoke control panel, both of which normally reside in a fire command room. BAS controls and system components are usually located for the convenience of the building’s staff and HVAC equipment. Under test conditions, additional personnel may be required to monitor the BAS controls to make any required modifications. 

While modifying fan output for each smoke zone condition is a more expedient method to obtain approval, it also provides future opportunities to inappropriately change the settings, possibly making the system ineffective. Care must be taken to limit access to this programming and provide logging procedures to document when and why changes are made.

Take a note: Fire condition is determined by the Fire Alarm Control Panel. AHU will automatically shutdowns the whole system with associated interlocks.

Question: How can the reliability of the fire alarm system be maintained while mixing data with other non-emergency inputs?

Answer: In reality the fire alarm system reliability is unaffected by other integrated systems when using the BACnet protocol due to the required use of the gateway interface. The gateway keeps the other signals on the network form affecting the fire alarm system.

Question: Building automation systems are more and more residing on an owner's IT network. If a BACnet gateway is used to interface to the fire alarm system, instead of hardwired connections, this device would reside on the owner's network which is likely not UL listed. Have you come across this concern?

Answer: The BACnet gateway itself is required to be listed, but not the system. So the fire alarm system devices or zones would be connected to the listed gateway and then the other side of the gateway would be connected to the network allowing the objects to be transmitted to the BAS, for example. Once again we are still required to use the listed gateway as the interface but the balance of the non-fire alarm system equipment does not need to be listed for fire alarm use. Having said that there are changes proposed to NFPA 72-2019 that would allow direct connection to the Ethernet or a network under certain conditions. These proposed changes have not yet been officially adopted.

Question: Do you recommend integrating the building fire alarm system and the BAS in an office building that undergo tenant fit-outs on a continuous basis?

Answer: With any system design in any building or occupancy planning is imperative. Knowing beforehand that the occupancy is to be offices and knowing that tenant fit-out occur on a regular basis, it is incumbent on the original system designer to include system changes and expansion in his or her design. Just because frequent changes to a system are expected does not preclude integrating all of the systems. It does require more coordination and provided that happens the systems should remain reliable.

Question: Does OEO override designated and alternate recall operation?

Answer: No, just the opposite. All recall features (elevator lobby smoke detectors for example) would input to the OEO controller and it would relinquish OEO or those floors in recall.

Question: How would elevator shunt trip for a sprinkled hoistway or elevator equipment room operation work into the OEO sequence of operation?

Answer: As stated previously, when these types of operations occur during or prior to OEO, these operations would take priority over the OEO and all OEO for the affected elevators would cease and all signs and voice messages would revert to “Do Not Use The Elevators, Use The Stairs” operation. 

Question: How would the use of BACnet interface to emergency control systems, requiring supervision of control wiring, address this code requirement?

Answer: NFPA 72-2019 (and previous editions) require supervision to within 3 ft of the controlling device or no supervision if the device operation is fail-safe, meaning if the connection to the device is severed, the emergency device operates as required. The gateway could be determined as the connection to the controlling device and as long as that was within 3 ft of the controller it would be considered code-compliant. This is unlikely to happen and other design considerations will need to be considered to ensure that the performance of the emergency control system is code compliant. Given the many types of configurations, there can be no one definitive answer to the problem until the actual field condition is evaluated.

Procure BACnet System

Procure BACnet System

BACnet was designed to allow communication of building automation and controlsystems for applications such as heating, ventilating, and air-conditioning control (HVAC), lighting control, access control, and fire detection systems and their associated equipment.

The UDP port number 47808 (in hexadecimal, X'BAC0') identifies BACnet messages and is the UDP port used by PAD devices. BACnet/IP devices use this UDP port by default but may be configured to use a different number if necessary. An open protocol should be powerful and robust, capable of meeting all future communication needs, as well as the present needs throughout all system levels. Any communication protocol which doesn't meet these criteria should be eliminated from further consideration.

BACnet's open structure and object-oriented commands enables developers to provide enhancements or features, while still maintaining full interoperability for all core operations. If use of a new control feature becomes widespread and there is a need for it to be standardized among vendors. ASHRAE provides a procedure for it to be adopted as a standard BACnet object or service.

BACnet is a widely accepted, non-proprietary open protocol standard. Companies began announcing their support for BACnet even before the final draft of the standard was released. The fact that ASHRAE developed BACnet plays a significant role in this acceptance. ANSI perceived BACnet to be a significant development and adopted it as a protocol standard within months of acceptance by ASHRAE.

Components vs Systems

For many years the BACnet community has worked hard to ensure that BACnet is a global standard and that it’s implemented consistently across multiple supplier product lines.  BACnet International devotes substantial resources to the BACnet Testing Lab (BTL) and to annual device “plugfests” to support that objective.  We regularly point out that BACnet is a global consensus standard and we trumpet the value of standards.  We talk about component interoperability and in some cases even interchangeability.  All of this is good.  Users need to understand the power of standards and how specifying systems that incorporate BACnet can add value to their building automation investments.  However, by promoting BACnet as standard and then using the shortcut term “BACnet System” we invite the unschooled to mistakenly extend the concept of “standard” from the communications protocol to the system.  That seems to lead some of them to the conclusion that all “BACnet Systems” are essentially equivalent and can be procured like commodity products … even to the point of the “reverse auction” procurement process for an energy management system I recently encountered. 

Reverse Auction Procurement

Reverse auctions have been around for more than a decade.  They evolved as a “simple” way for buyers to drive down the cost of components.  The essence of reverse auctions is that suppliers bid back and forth for a well-defined piece of business on the basis of price.  Full-featured web platforms have evolved to support this purchasing model but, even so, it has its limitations.  One of the biggest limitations is that for it to be effective, the product and its associated transaction attributes (e.g. lead time, delivery date, etc.) need to be unambiguously defined in terms that can be readily measured.  And therein is the rub.  Energy management and building automation systems are complex so fully defining all of the important attributes is a huge challenge.  Leaving any important attribute undefined results in suppliers compromising on those unspecified attributes to achieve the lowest cost and win the business.  On the surface the result might look like a good deal for the buyer.  But those compromises might well come back to haunt the buyer in the long run.

Lessons Learned

It was an attempt to give people new to the BACnet community some insights based on the experience of people who have already designed and operated systems built around BACnet.  One of those “lessons learned” was that a “BACnet System” is still a system. The BACnet standard can make system integration faster, simpler and more effective but it is not a substitute for system expertise, creativity or design rigor.  Nor does BACnet provide any assurance of product quality or system effectiveness.  These come only through knowledge and experience.  So, I encouraged owner/operators to develop a partnership approach to working with suppliers who have that knowledge and experience. I saw first-hand what happens when complex systems procurement is driven from a “first cost” perspective without sufficient focus on supplier partnerships.

Benefits of BACnet Protocol

• Single operator workstation for all systems
• competitive system expansion.
• Eliminates fear of being an owner to be locked in with a single vendor.
• Possibility of integrating all BAC Functions.
  
• Interoperability

·         Data sharing

·         Alarm and event management

·         Trending

·         Scheduling

·         Remote device and network management

Summary

BACnet is a standard. All the necessary elements are in place: strong customer demand, a robust open standard and manufacturer's support of the standard. BACnet seems to provide a complete solution to interoperability issues for building procurement  team.  Understanding the difference is important in establishing a procurement process that builds positive supplier relationships and generates maximum value in acquiring an energy management or building automation system. SSA Integrate can guide how to utilize this.

Know about BMS technical protocols

BMS - What you should know about technical protocols

If you or a client is choosing a building management system (or BMS), it’s important to understand how it communicates information with digital devices such as controllers, meters, and input/output boards, and computers.

The details are important because some BMS use languages—or technical protocols—that lock you into using their vendor’s proprietary technology. Use of such protocols may force you and your client to pay higher prices for software and hardware available from only one vendor or its licensees.

This article describes common categories of BMS protocols. It recommends that you avoid proprietary protocols and favor more open ones.

A BMS communicates through protocols

To exchange data, digital devices must use a common data structure and a common channel or medium of communication.

The figure below shows a master BMS that communicates with devices that use microprocessors. They include a roof-top unit (or RTU), refrigeration controllers, energy meters, and other input/output boards within a building. The building controller also uses the Internet to share temperature, operating parameters, or energy data with remote users through enterprise servers or personal computers.

A BMS protocol defines the format and meaning of each data element, in much the same way a dictionary defines the spelling and meaning of words.

The data exchange often occurs through a physical wire such as a twisted-pair RS485 or an Ethernet CAT5 cable). It may also occur wirelessly over wi-fi network, through an internet protocol (or IP).

The phrase “BACNet over IP” means the BACNet protocol communicates through an IP network.

Some protocols are more open than others

Protocols fit in one of four categories, depending on their relative “openness:”

1.       Open. The protocol is readily available to everyone.

2.       Standard. All parties agree to a common data structure. The protocol may be an industry standard, such as BACnet and Modbus.

3.       Inter-operable. The protocol is vendor agnostic. A controller from one vendor can replace one from a different vendor.

4.       Proprietary. The data structure is restricted to the creator of the device.

Why you want BMS with open protocols

A BMS with proprietary protocols locks the system owner into using a single BMS vendor. For example, you can’t remotely change the set points of a proprietary BMS unless you use the vendor’s software.

In contrast, with open and standard BMS protocols you can shop for alternative providers of digital devices and enterprise software.

This is why use of proprietary protocols is inconsistent with best practice. The lesson is clear:

In choosing a BMS, be sure its protocols are not proprietary.

How to know whether a BMS protocol is open

To determine whether a BMS protocol is open, ask the vendor two simple questions:

1.       Can your competitors exchange data with your BMS?

2.   Is the system’s protocol published in such a way that it’s easily accessible to everyone (including competitors)?

Best open protocols: BACNet, Modbus, and XML

For a master controller that exchanges data with devices and meters within a building, prefer the BACNet, Modbus or any other standard protocol. Otherwise, make sure it’s at least open enough so anyone with proper security access can read and write information.

For remote enterprise access (protocol B in the figure), organizations often use BACnet over IP.

The current trend is toward use of additional Internet technologies. Companies like Honeywell Tridium (Niagara framework) and many others have exchanged data through standard internet eXtensible Markup Language (or XML) with web services.

Even the ASHRAE BACNet committee has convened a working group to define use of XML with BACnet systems. The group is also working to define web services that will enable data exchange between building automation and control systems and various enterprise management systems.

Put in short, use these criteria when you’re choosing devices and BMS:

·         For devices such as RTUs and refrigeration controllers, look for ones that use open protocols such as BACnet or Modbus.

·        Make sure these devices give you both “read” and “write” capabilities so you can change set points.

·         For easy enterprise access, choose a BMS with web services and XML capabilities.

·         Make sure the web services of the BMS allow both read and write capabilities.

·      Be sure the BMS supplier provides the XML dictionary and definitions of web services to anyone, including competitors.

 

This Artical published on April 2019 at Safe secure Magazine.