Can the BAS industry evolve by removing things like value engineering?

In the HVAC and mechanical contracting industries, it's not unusual for cost-saving measures to influence system design compromises. Consider, for instance, a hospital during the design phase, where a meticulous plan was put forth by the mechanical engineer—a high-efficiency water-cooled chiller plant boasting multiple large centrifugal chillers, including a smaller chiller strategically designated for shoulder seasons to optimize low-load performance. However, these well-conceived designs often succumb to the red pen of "value engineering," which unfortunately leaves clients discontented when their cooling requirements go unmet when the big centrifugal just cannot run during low load conditions.

The thought that arises here is whether it's time to wield the red pen in the realm of HVAC controls, (see image below) just as the classic move of eliminating the shoulder-season chiller from a project. However, there are nuances, particularly that technology, at large, may need to evolve further, perhaps drawing inspiration from the Home Automation industry—exemplified by platforms like Home Assistant (HA) and other free and open-source projects designed for home automation setups. In my view, the Home Automation sector is progressing more rapidly than the BAS industry. Can BAS systems offer features like Alexa integration, machine learning capabilities, and a vibrant community-driven ethos that fosters inventive and ingenious solutions, akin to what's seen in the HA community? This article delves into the possibilities and potential for innovation and transformation within building automation technology. Personally, I am mesmerized that HA can just run on a raspberry pi computer at my house all for free and it just automatically discovers all my devices on my Wi-Fi network! Now if a BAS could do that in a large commercial building that would be a game changer for the industry IMHO especially if its free!

Imagine a BAS Lite option tailored for light commercial buildings, small structures, or simple systems, even in educational institutions, like K-12 schools for example with all simple systems. Such a solution could be implemented by the organization's IT department. In my experience with BAS contracting, IT departments tend to be less involved, but involving them could significantly enhance the cybersecurity of buildings which I like to promote even if the IT guys policies makes setting up OT harder and/or take longer. Having IT involved more from the get-go could be a valuable alternative to relying solely on operations technology (OT) contractors and manufacturers for cybersecurity measures especially hardening operating systems running on OT networks.

Going even deeper into this concept, the idea of removing supervisory controllers and BAS servers, which often come with substantial contracting costs, is worth considering. What remains is essentially a stripped-down BACnet network. Typically, devices within this network require a front end, like a supervisory controller, to manage scheduling objects for equipment and possibly share global logic, such as the building's outside air temperature sensor and sometime air handling unit systems require a global shared zone temperature to know if they need to run in unoccupied hours for nighttime heat or cooling. These sensors are typically shared globally by a supervisory-level controller but BACnet does support peer-to-peer communications which is a bitter trickier to setup and harder to troubleshoot thus getting one step closer to justifying the red pen. The data shared globally in a BAS system is crucial for HVAC systems inside the building to adjust their operations accordingly to meet the mechanical engineers' sequences, but it can be done through peer-to-peer, and I can imagine some HA inspired BAS Lite server app just design it for minimal global shared data for outside air temperature only and maybe some zone information to AHU systems if they need it.

In theory, a free and open-source project should be capable of handling tasks like equipment scheduling via BACnet and sharing global values like the outside air temperature sensor readings. If a BAS contractor insists on retaining the supervisory controller and cannot provide a solid reason for doing so, it may raise questions about what might be hidden within that supervisory controller. In some cases, it could indicate that there's a patchwork of programming designed as a quick fix like bandages on the HVAC systems, rather than revising the PLC or application-specific device itself. This could be due to factors like laziness or the lack of access to revise the PLC program directly. There are some applications that do require some overhead global logic which can when integrating older proprietary BAS platforms and protocols into a newer BAS some extra global logic was essential in that application which is outside the scope of this discussion.

In conclusion, the concept of a free and open-source project, inspired by the Home Automation industry, targeting small, simple systems such as schools, and administered by an organization's IT department holds significant potential. Drawing inspiration from the success of Home Assistant in seamlessly discovering home automation devices, implementing similar functionality in the BACnet realm through techniques like "who-is" commands doesn't appear to be an insurmountable challenge. This is how BACnet could be used to auto-discover everything like HA in fact some IoT platform auto-discovering devices is a common platform setup practice. This idea envisions a straightforward drop-down calendar interface for building automation, eliminating the need for supervisory controllers or expensive BAS servers and graphics...just do everything through BACnet on the OT LAN, right? I mean why not? And for free as BACnet is free, Linux, as well as most often the IT departments time and hardware! In my experience of setting up BAS and some IoT stuff these days I cannot really recall ever seeing a bill from the IT department in project assistance.

For building operators, we still need a user-friendly interface for viewing sensor values, adjusting setpoints, and managing equipment schedules—all at no cost... and why not just in a simple table view which the BAS already typically has on the home page for the control system which can viewed when the building operator logs in to see a quick glance if everything generally looks Okay. For simple systems just red X the common BAS graphics where those can be saved for the laboratory, hospital, or other complex HVAC.

BACnet devices managing HVAC systems become self-contained, relying minimally on external data, primarily occupancy and outside air temperature. Consulting engineer's specifications could be written this way which isn't too far off from current standards in a split specification of a "field" contractor and a "systems integrator" contractor. From a contractor's perspective, while they may see a decrease in immediate profits from not doing graphics, they gain a competitive edge by reducing costs, eliminating the need to invest in costly supervisory controllers, and streamlining labor for graphics.

While it's important to acknowledge that this approach may not suit complex HVAC systems found in laboratories, data centers, or hospitals, it presents an attractive solution for light commercial systems, schools, and medium-sized offices. By harnessing the power of open source and IT administration, this vision could make building automation more accessible and cost-effective for a broader range of users and projects.

I'm aware that BAS technician professionals in the field are deeply passionate about automating HVAC systems with PLC's, and this trade will endure as long as humans continue building structures. It's a testament to their dedication and expertise. (This is my old field specialization that came with a pocket protector with about 10 different types of precision screw drivers on the jobsites setting up BAS...)

Additionally, I almost forgot to mention the presence of MSTP devices in BAS networks—older twisted-pair RS485 networks, sometimes directly connected to supervisory controllers. These can be replaced with cost-effective BACnet routers for a $100, making the transition smoother and more budget-friendly Vs a probably $5k supervisory BACnet MSTP controller.

Expanding the scope beyond HVAC automation, why not explore the potential of free and open-source projects in managing other OT systems like AV, card access, elevators, and surveillance? Embracing this innovation can lead to transformative changes...something tailored to assisting the IT person in management all this OT equipment!

Creating this change requires thinking outside the box and prioritizing practicality over profit which IMHO why the BAS industry doesn't evolve very fast. Consider the mission statement of Home Automation: "It's a community of tinkerers." Yet, this level of innovation and experimentation is relatively rare in the BAS industry but yet a common practice in Home Automation.

I firmly believe that this can be achieved, with consulting engineers readily adapting to write specifications that ensure building HVAC still meets code requirements, such as ASHRAE 90.1 for equipment scheduling during unoccupied hours and 62.1 for ventilation when people are inside the building. By pushing the boundaries of what's possible, we can bring about positive changes in the industry while maintaining compliance with essential standards.

Another evident limitation of removing the supervisory controller from a BAS network is the inability to seamlessly integrate multiple supervisory controllers into a single server. Consider a hospital network as an example, where building operators rely on integrated supervisory controllers that utilize proprietary, non-BACnet protocols for secure internet access. It's worth noting that BACnet was never originally intended for internet-based communication, and its usage in this manner should be approached with caution. However, the practicality of viewing graphics from multiple buildings on the same BAS server is a rare requirement for most building operators. In reality, operators appear to me to primarily focus on their own building, only occasionally needing access to other facilities when covering for a colleague on vacation or sick leave.

Therefore, an architectural approach like this would involve deploying lightweight BACnet BAS servers in each building. When building operators need access to another site, they can do so by following established IT practices, such as using a VPN or adhering to IT networking policies set by the IT department to maintain network security.

It's also important to consider that heavy data logging for energy management purposes may be best suited for an IoT platform. This would allow data to be charted in the cloud and facilitate analytics and FDD (fault detection and diagnostics). In its native state, a BACnet IP-based front-end interface can seamlessly operate in the edge environment or an OT LAN, while IoT appliances collect data and transmit it to the cloud without interrupting the straightforward, Home Automation-inspired BACnet-based BAS interface. It's almost like a new acronym could be invented for OT GUI setup and management by the IT, but the buzzword IoT is more for reserved for specialist in getting data from the building to the cloud which is something that is beyond this idea but a project like this would definitely need to support IoT by design as a lot of good things are happening on the cloud with data science and HVAC telemetry data where new advanced optimization strategies are studied by the help of IoT.

(Eliminate building to building integration through supervisory controllers and use IoT for that...)

The distinguishing concept behind this BAS Lite Home Automation-inspired interface is its exclusive focus on empowering building operators with the tools to effortlessly oversee operations. This interface is tailored for monitoring, adjusting setpoints, scheduling equipment runs, and promptly responding to critical failure alarms. Additionally, it encourages a culture of "tinkering and DIY" within the industry, fostering innovation and hands-on involvement.

By involving IT professionals from the initial stages, concerns raised by manufacturers regarding security become irrelevant which I could see happening. The system is intentionally designed to be orchestrated by the IT department, harnessing their expertise in managing Linux applications within containers and the OT network. This approach ensures that the organization's IT team plays a pivotal role in guaranteeing security. Moreover, the wider open-source community adds an extra layer of scrutiny, as numerous experts continuously monitor the project. This collaborative effort helps maintain robust security practices.

On a related note, the topic of technology's impact on self-repair, like the challenges faced by farmers unable to fix their own tractors due to advancing technology, is a compelling subject that merits exploration in a future write-up on where the BAS industry hopefully goes down a path of allowing farmer to fix their own tractors, open source, DIY, tinkering, etc... Thanks for reading! Please let me know your thoughts, comments, and/or concerns!