The Anatomy of an Edge Controller The reality is, none of these devices contain any parts that are truly proprietary or unavailable to the public. Part 1 of 4 Part of 4 - The Software Part 3 of 4 - The Hardware Part 2 of 4 - The Processor Part 1 of 4 - Introduction

Calvin Slater Member of Project Haystack  Project-Sandstar LinkedIn Contributing Editor

When you read through this whole series of articles you may ask:

1. Why are you telling me what’s inside a controller? Should I care?
   
2. Can’t I just buy a controller and use it? Are you telling me I should make one for myself?
   

Not necessarily. Although if you wanted to make your own controller, you could. The reality is, none of these devices contain any parts that are truly proprietary or unavailable to the public. At least not anymore. Most modern DDC controllers are composed of parts that are off-the-shelf items. Many of the various bits and pieces of these devices can be found in singles from large online retailers such as Digikey or Mouser. Components, boards, sub-assemblies, and starter kits can be found on hobbyist sites such as Adafruit and Sparkfun. Sample and low-volume prototype printed circuit boards can be inexpensively fabricated from places like OSH Park or Macrofab. It turns out that it’s completely possible to build your own edge controllers. Not only that, but it’s also possible to buy just enough pieces to make just one controller; if you are so inclined.

This is kind of a big deal. In the past, someone with a passing interest in electronics could not very easily experiment with these types of devices. They would have to commit to buying thousands of units as opposed to purchasing just one chip. Access to datasheets and reference manuals needed for evaluation and design required extensive legal agreements and signing of non-disclosure forms. Software and tools to compile, flash, and test various processors were often extremely proprietary, difficult to use, and prohibitively expensive (like thousands of dollars). These pricey development tools were of course not cross-compatible with other vendor’s chips. It was not very easy to test out and learn about products from different manufacturers.

All of these concerns have largely disappeared in the past decade. Many of the barriers to entry have been removed by several of these parts vendors. They have done this to make it easier for someone with a great idea to be able to evaluate and choose their chip to use in a new product. To make it even easier, most companies offer low-cost development boards for accessing a particular chip’s features much faster. The wide availability of these open components and supporting tools has enabled the growth of a movement in the electronics world. This is sometimes referred to the Maker Movement.

However, this series is not meant to be a how-to on building electronics for control. There are plenty of such resources already in books or online. The purpose of these articles is more of an architectural tour. The control devices that we will inevitably be installing in our buildings will be by necessity open-source, open-architecture, and extensible. It will become important to become familiar with the overall layout of these new systems so that the controls industry can be streamlined when entering this new era. Someone doesn’t have to be a professional hardware or software developer to be able to appreciate electronics and software. Just like someone can study building architecture without being involved in the construction industry. With the introduction of newer, powerful, and cost-effective embedded microprocessors, much of the tasks usually performed by global controllers, gateways, or BMS servers will be pushed out to the edge; to the field devices actually controlling and monitoring equipment. What’s needed is an understanding of what edge controllers can do and should be required to do. By studying edge controller architecture, one can develop an understanding of what should go where.

The Processor

Until now the question of what data and processing activity should go where was easy to answer. Field devices have to be low-cost products. In the past, it was only cost-effective for field controllers to be constructed using microcontrollers as the central component. These simple devices are limited in processing and storage capability. Because a microcontroller can do only a few things at once, that meant it would only run the DDC program for the equipment it’s attached to, and usually nothing else. Just a little bit of processing and data went into the controller; in many cases not even occupancy schedules or historical trends. All of that stuff normally went into a global controller or gateway/router. The schedules and histories would more easily be hosted there. But the vast majority of everything else went into the server, which is usually a desktop PC sitting on a folding table in the boiler room. In the era of edge control, everything has changed. That desktop PC now exists on a single piece of silicon, and its location is in the controller for every single zone.

[an error occurred while processing this directive] The Hardware

Board peripherals and controller form factor continues to be an important consideration. At the end of the day, having a complete personal computer on a chip is totally useless unless it’s connected to interact with the actual equipment we care about. Increasingly new controller products are being equipped with IP connectivity. Will we continue to see controllers daisy-chained together using serial ports? BMS network topology is destined for an inevitable overhaul. Will features such as PoE and Wireless help alleviate some concerns about installation costs? The most important issue for controls contractors is the installation workflow and device commissioning. How will we tackle the task of assigning IP addresses and commissioning hundreds of devices as opposed to doing just a few? Some things will probably remain constant, however. The way I/O is done will probably remain the same, but improvements can be made by standardizing how these points are brought into the system. For example, creating a uniform and streamlined way for I/O read-writes through OS kernel system calls. The underlying infrastructure in embedded Linux already exists to support this.

The Software

Finally, a discussion on platform software/firmware and User Applications. The reason for all of this focus on hardware is to guarantee support for all of the applications that will run on these devices, both at present, and in the future. Solid hardware is the foundation that future BMS applications will be built upon. One of the main reasons to transition from single-threaded devices using microcontrollers to multi-threaded operating systems is to future-proof these devices (at least as much as possible). Future controllers will still need to run DDC programs reliably and in real-time. In addition to doing what they always have done, these products will have to manage other processes without failing in their main purpose. They will have to do this in a secure manner and be capable of being upgraded/updated.

So, if you are interested in what goes inside an edge controller, stay tuned as we will explore each of these three topics in depth, starting next month with The Processor.