Edge devices now have the intelligence and data storage they need for local analytics and machine decision-making. They'll soon be the thing that the rest of the BAS universe revolves around.
Anyone designing an IoT architecture must decide which tasks are best performed locally by a device at the network's edge versus remotely by a cloud-hosted application. Within the IT world, an edge device is defined as a gateway or global controller. Within the building automation world, a direct digital controller (DDC) can be considered an edge controller. Likewise, a global controller is an edge controller. Physically, the network's edge might be integrated into roof-top equipment, solar arrays, utility-owned equipment, data center infrastructure, etc. The EAC marks a new generation of edge-device in that they will come with tagged, preconfigured apps to automate the workloads typical at these edge locations.
One of the most revolutionary aspects of having robust compute resources at the DDC level is that edge devices like energy analytics controllers can do analytics processing of large data sets. Application developers are challenged to make the most of this new capability. The Buildings-IoT represents an opportunity to radically rethink the software architectures that define core workflows such as detecting and diagnosing faults in equipment, responding to occupant hot/cold calls, shifting energy loads to participate in demand response programs, and performing other building operations management tasks. Energy analytics controllers are capable of high-speed handling of the work involved in trending data, adding semantic tagging and generating analytics. Doing these tasks locally and sharing the results among other edge devices opens the path to a host of new applications.
The basic resources that an energy analytics controller should integrate include a powerful processor, on-board memory, flash storage and IP connectivity. The open Sedona Framework is the type of real-time controls engine that works well in a software architecture built to support EAC devices at the edge. Essentially, app assembly happens here. Using easy-to-learn graphical block programming methods, solution developers can define desired inputs and outputs to EACs. Tridium has opened the Sedona Framework to the public with an academic free license and it has self-sustaining community support.
Even with all the power of IP-enabled EAC edge devices, finding operational anomalies is a complex task. It starts with transferring streams of data into ahistorian, or high-speed database. This transfer of data is the preliminary requirement. Next the raw data needs to be structured in preparation for analysis. This step is being made easier by semantic tagging systems that enable the definition of models that are self-describing. The semantic system can be integrated with the analytics program for greater efficiency. BASSG utilizes the open-source Project-Haystack standard for semantic modeling. It also uses the Skyspark® Analytics engine from Skyfoundry in its EAC architectures. For visualizations and dashboards, BASSG uses it own branded software, Visualytik.
A Project-Haystack software stack is built upon multiple technologies such as the text-based open source file format Zinc. Zinc allows semantic tag definitions called markers. Multiple markers combine together to define what a BMS point means and does. There is also a web-services layer of the stack for querying data within the database.
Once a data management architecture like this is set up the power of the EAC can be brought forward. For example, in a data center optimization scenario, an EAC could be used for cooling optimization. The goal is to keep the environment sufficiently cool to not risk overheating processors and server failures, while not wastefully over-cooling the space. This balance is largely a function of the amount of heat that servers are generating, and this is highly dependent on their processing load. An EAC-enabled workflow set up for this challenge would have the edge devices capturing real-time CPU readings and calculating a cooling load value from this data. The EAC would then feed this value to the CRAC unit as a parameter. In response, the control system would deliver more or less cooling. All this would happen before the space was allowed to heat up to the point that a room thermostat detected the change in temperature. This proactive approach to cooling would decrease risk of server failure due to overheating, improving the reliability of the data center overall. The availability of EAC's at attractive price/performance points would make this a viable approach for data center operators.
EACs are a powerful addition to the smart building system integrator's tool case. Going forward, EACs will serve in the core functions of:
As described in the data center optimization example above, tagged, preconfigured apps to run on EACs will be the trend in the future. Real-time control, analytics and visuals will never be the same again. EACs are the way control will be done in the 21st Century.