The ep5 Educational Broadcasting Foundation

education in technology for schools and public broadcasting

The ep5BAS Manifesto

Automation is everywhere these days, and that is guaranteed to become more and more the case. We think of creating and programming this automation as the exclusive province of system-level software developers capable of writing impenetrably dense and complex code. Is the universe of automation closed to mere mortals?

The control room that just never credit unknown

Tell me again, what is ep5BAS?

We’re all familiar with electronic automation of a great many products, ranging from wristwatches to interplanetary space probes. Each of these runs software specifically designed, written, implemented, and – one hopes – thoroughly and comprehensively tested for a single purpose. The engine or electronic stabilization controller in one’s SUV may be immensely advanced and clever, but it couldn’t run a toaster oven if someone’s life depended upon that happening.

General-purpose automation intended to be applied to a variety of different end uses has existed for decades, but, like the single-purpose embedded systems, it has been limited to narrowly-defined classes of applications and has consisted of islands of automation. The controller from Manufacturer A cannot be used with the software from Manufacturer B, and there are far more than two vendors in this industry.

One general class of automation aims to replace manual and semi-automated control of building features with easily reprogrammable software running on hardware which can be connected to a wide variety of sensors and actuators. This enables it to turn lights on and off, change thermostat and humidistat settings for different times and days, monitor and record essential functions, and facilitate greater efficiency in the consumption of increasingly scarce and thus costly resources, including water, heat, and electric power. By its inherent nature, a building automation system (BAS) must accommodate as many different types of inputs and outputs as feasible, since more and more functions occurring inside a building fall within the purview of automation.

Additionally, some functions lend themselves to full control by the BAS. This might be lighting, with provision for selective manual override when required. Other functions, such as security and fire protection, may be off-limits to direct automated control. For these, the BAS provides additional services, such as logging, notification, and startup and shutdown of ancillary systems.

According to Schneider Electric...

  • Buildings use 42% of the world's total energy consumption
  • Of this energy, as much as half is wasted
  • Operating expense accounts for three quarters of a building’s total lifetime cost
  • Of all buildings with operating automation, only one in five uses as much as 80% of the system's ability

Clearly, there is a need for a building automation system which can be tailored exactly to the individual requirements of the building and allow the user to change control strategies quickly and easily.

The conventional BAS enables the user, to some degree, to alter its programming at will, without the involvement of the BAS OEM or distributor. To make this “easier”, the average BAS manufacturer devises its own programming tool and requires the user to learn how to use it. This began with the gruesome ladder logic of early programmable controllers and has advanced to somewhat less user-hostile products.

What do we propose to do about it?

We choose to provide an alternative. Although ostensibly serving as a C# programming exercise for our series, “The Art of Programming”, ep5BAS goes far beyond such modest scope. Open source has established its bona fides as a legitimate class of software, with some products usable across a broad range of undertakings. Our objective will be to create a fully open-source BAS which (a) uses a completely general-purpose programming language familiar all over the world, (b) runs on the broadest possible range of hardware, (c) will be maintainable by pretty much any qualified programmer, (d) is data-driven, (e) uses open protocols wherever feasible, and (f) accommodates the widest feasible range of input and output devices and systems.

Image courtesy of Paul Rivenberg and Mary Pat McNally, MIT Plasma Science and Fusion Center

The last of these criteria will be the most meaningful and important. Since the inputs (sensors) and outputs (actuators and effectors) will come from a bewildering variety of sources, almost all with their own means of connecting to control systems, it’s critically vital that there be a highly reliable and capable bridge connecting the BAS programming running on a desktop computer, embedded controller, or other processor with the I/O hardware directly bolted to the real world.

Some sensors and actuators are sold with their own dedicated device drivers, while others rely upon such well-established industry standards as RS-232/422/485, Modbus, Fieldbus, CANbus, 4-20ma current loop, 0-10vdc, and EtherCAT. In all events, to be utilizable in automation, each device requires its own means of communicating with the user’s program. Thus, the key to ensuring ep5BAS’s universality will necessarily be a means of reliably and easily linking programs written in C# with the device drivers supplied by the hardware OEM or the industry-standard equivalent.

What is the likeliest point of commonality between these two worlds?

Well, let’s begin with our criteria for it. It must be reliable: above and before all else, it must work predictably at all times. It must be universal, or as close to it as we can get. It needs to be programmer-friendly. The author recalls his first COBOL compiler, the manual for which provided this recommendation for the user whose mainframe terminal was not supported by the OS: “Write an assembly-language device driver for the terminal you are using.”

Yeah . . . right.

Can we talk?

It should communicate bidirectionally between the control computer and the I/O device as quickly as the technology allows, since control programs run event loops, and that means that the cumulative effect of delay multiplies with considerable rapidity. It must provide for a variety of physical communication media, such as Ethernet, direct connection, and serial links. In short, more than all else but reliable, it needs to be flexible.

The core of ep5BAS is real-time control, and that means intimate use of fieldbuses, connecting to digital and analogue I/O via couplers utilizing such technologies as Modbus and EtherCAT.

Various means exist to facilitate communication with SCADA-level systems, including MQTT, OPC/UA, and very likely other equally incomprehensible acronyms. We will be limited by both the availability of free/open-source implementations and the simple matter of what does the device in question actually use.

In some instances, communication means using C and C++ functions provided by OEMs or written for ep5BAS by appropriately capable volunteer programmers. These drivers, called by the user’s program perhaps at the top of the event loop, bring in inputs for the succeeding code and deliver outputs from the preceding code. The actual communication is managed by these drivers.

As ep5BAS gains popularity, I/O hardware OEMs should become more willing to at least assist in the creation of these product-specific drivers and to make them freely available. It should be noted that ep5BAS will not compete directly with consumer-grade systems such as Home Assistant, OpenHAB, and Domoticz, but it will strive to match their ubiquity and ability to use a broad range of sensors and effectors.

As the project matures, a major subset of ep5BAS will involve its interaction with existing environments, such as BACnet, LonTalk, IEEE 1905.1, and ZigBee. (Whether ep5BAS will be able to eavesdrop on the conversation when your smart toaster phones home remains to be seen.)

“The Killer App”

Traditionally, at least in the sense that advanced automation has had time to develop traditions, building automation found economically justifiable application in large and complex environments, such as multi-story office buildings. As high-capability BASes become more affordable and user-friendly, especially in terms of programming, they’ll find homes in, well, homes. Energy efficiency in residential buildings will demand and depend upon meticulous and reliable control of air infiltration, movement, temperature, humidity, and cleanliness, as well as extracting maximal value from costly energy inputs.

This will require a great deal more than slick wall thermostats, and ep5BAS represents one class of solution to this potentially massive challenge. Even a small contribution to reducing residential energy consumption will generate dividends. The goal of water conservation can also be served by home automation. This includes reuse based upon purpose and source, reduction of wasted hot water, and lessened total consumption.

Clearly, ep5BAS will have much of public benefit to offer. We have already begun development of the code for ep5BAS as well as clarified the hardware requirements specification.

But wait! There's more!

It should be noted that ep5BAS will certainly not be limited to automating buildings. Much of the power of a general-purpose programming language inheres in its universality, and this translates directly to control and automation programs written in the language. One of the underlying objectives of ep5BAS will be ensuring that it can be applied almost anywhere a good use for automation exists. ep5BAS might even be thought of as an API for the language.