By Philip R. Juneau.
‘Interoperability is the ability of two or more systems to interact with each other, whereby the technical interfaces to each system are completely and bi-directionally recognised by each other.’ This is the pure technical definition, taken from the Information Technology (IT) or Operational Technology (OT) perspective. This does not, however, take into account the human social, economic and organisational interface factors that also affect system performance.
In the built environment context, OT is the non-business-related hardware and software that is designed to monitor and/or control discrete (end) field-devices in one or more building technology systems, providing multiple building functions, either independently or in unison.
Streamlining these interfaces to remove the siloed, independent control communications is the key to making the building intelligent. The aim is to provide a safe, operationally-efficient supply of energy whilst at the same time protecting and providing comfort to the areas and occupants they serve.
Edge computing
In order to do this, edge computing at the OT level now comes into play. Edge computing technology acquires, stores, and processes data and control functions closer to the source of the data, allowing faster, more secure decision making at the source of the application, rather than relying on the cloud. The use of edge technology provides industrial companies with sophisticated features and functionalities such as interoperability, security of data, low latency, and improved quality of service [Ref: Frost & Sullivan, Frost Perspectives article: Edge Computing: A Disruptive Technology for Industrial Manufacturing dated March 30, 2018]
This article will focus on the existing technical challenges to overcome, mainly in the form of the legacy OT infrastructure that is already in place, such as manufacturer-proprietary systems and construction trade divisions, coupled with the lightning development of Apps, IoT and cloud computing. By following some fundamental technical principles and matching customer applications with global, open-standard market solutions, we can ensure interoperability is sustained in the built OT-environment.
Field level – where the rubber hits the road
As edge computing depends upon field device interoperability, let’s break this down to its root form – the control communication. Not all open protocols are alike and have fundamental differences regarding hardware topology and software engineering and programming. BACnet, for example, makes all HVAC central processes and end-device data points available on the supervisory (building operator) level to provide monitoring and, to some extent, field level control. This control, however, is typically resident in the field hardware i.e. the controllers, which are programmed with the manufacturer’s proprietary software. This means that, in ‘edge” terms, the source to the field-level data points is directly through the manufacturer’s field-level controllers, which is localised control that is dependent upon their proprietary engineering and SCADA (Supervisory Control And Data Acquisition) software.
It’s the field interoperability that enables the discrete end-devices (the more intelligent the better) to operate on an open-communication level. The aim is to provide logic across the different trade systems such as electrical distribution, HVAC, LED lighting, daylighting, access, surveillance, etc, in order to provide intelligent monitoring and control, completely across your building operation.
That is why the KNX protocol is designed for field-level interoperability. Both the hardware and software are truly open and universal – ALL manufacturers follow both a communication (hardware) and engineering (software) standard rather than each manufacturer using proprietary programming software.
Trade Automation Level (TAL)
The Trade Automation Level (TAL) is where central controllers provide monitoring and control to a specific building system in a central location, such as a mechanical equipment room (MER). Both HVAC and electrical distribution are central systems providing air/water and power to the individual spaces, respectively. An example where central automation is applied is a central HVAC air-handling unit (AHU) that distributes treated air to the individual occupant zones. This is the perfect application for BACnet or Modbus protocols, whereby programming can be resident either on a dedicated controller or an IP-based server/controller connected to an overall supervisory SCADA system.
Another example is the main electrical distribution panel (MDP) that provides protection and control of HVAC equipment, lighting, IT, electrical receptacles etc. With the MDP, you can build-in intelligence to monitor the electrical distribution system down to each discrete load down to the miniature circuit breaker (MCB) level. Typically, the open protocols used for what is known as the Electrical Distribution Control System (EDCS) are Modbus, M-Bus or SNMP. The EDCS monitors the electrical system down to the discrete load level by trending and identifying anomalies in operation and significantly yielding both energy and operational savings.
Interoperable Automation Level (IAL)
When combining the data from TAL systems with HVAC and EDCS, you are able to provide cross-protocol edge computing, making it possible to have cross-system monitoring, analytics, machine learning and, with sophisticated algorithms, artificial intelligence across your building systems. For example, when you combine the HVAC AHU with the electrical distribution power data, you can provide such simple control strategies as peak demand limiting via load shedding, prioritisation and strategic scheduling of equipment, etc. Indeed, you can obtain 20 – 35% energy reduction, thus reducing your operating costs saving tangible dollars.
The Interoperable Automation Level is where the IP convergence happens, and cross-protocol control logic is applied across all building technology systems, making it a truly intelligent building. What is critical at this level is one’s knowledge and application of the open protocols; the protocol’s structure and rules need to be clearly understood on both a hardware (topology) and software (engineering, programming) level. This means for a system to become truly interoperable, the links and data structure need to be clearly understood, adhered to and defined on the IP level in order to provide robust, cross-protocol logic.
Summary
As you can see, streamlining the various protocol interfaces to remove the siloed, independent control communications is more than feasible today. By applying an open-protocol and IP-convergence approach to edge computing in OT, we equip building owners and operators with tools needed to be proactive in managing their facilities. This allows them to focus on optimisation and revenue-generating projects in order to continue to be competitive in their marketplace.
Once the technological building functions have streamlined OT implementation capability, the system integrator can focus on the applications; across protocols and, above all, across trades. This way, the interoperability barrier is removed, providing the highest levels of safety, comfort and efficiency, making it a truly intelligent building.
Philip R. Juneau is the Chief Commercial Officer for Automated Technology Company (ATC), and Vice President of the KNX USA National Group. ATC’s mission is to transform today’s buildings into tomorrow’s net-zero infrastructure by ensuring the highest levels of safety, comfort and efficiency for the overall well-being of its occupants and the overall environment.
