Overview of Direct Digital Controls

For Building Automation Systems

Part 4 – Controller Types

This document is meant to be a continuation of the brief introduction to the ideas behind
Direct Digital Control (DDC) of Building Automation Systems (BAS).

In parts 2 and 3of this series I discussed controller inputs and outputs. And discussed
briefly some details of what the various kinds are, what they do, and how they’re used.
Not in any significant detail, as this overview is aimed at introducing the various ideas
and concepts of direct digital control, as applied to building automation systems (and
EMS, energy management systems). The details are the subjects of whole books in their
own right.

Before I continue on, I ask any readers … IF there are any readers … to please be tolerant
of my poor writing skills; and my feeble and faulty attempts to create something that is
both understandable and worth the time to read. My free time is limited. These
documents I am creating are free for anyone to read, or discard, or to use and modify as
they see fit. And as one can readily tell by a quick glance, the contents are off the cuff,
so to speak; my thoughts as they occur to me with no attempt to edit them, re-organize
them, clean up the sloppy sentence structures, nor anything else. I think, I type, and what
gets typed stays “AS IS”. Sloppy grammar, mistakes, displays of my own ignorance, and
all. I am not a professional educator. Nor am I an expert in the subject of direct digital
controls systems for building automation. I claim expert status in nothing. I’m just a guy
who works in the field, who apparently produces results that are adequate enough so that
the powers above me see fit to sign my paycheck. I am producing this series of
documents simply because I often get asked by folk who MIGHT be interested in this
field, to explain a little about it. Enough so that they can understand what we in this field
of work do, how we do it, and what tools and equipment we work with.

Explaining ALL of it, would require an entire library of books. But I’m hoping that I can
give the readers here, if any, at least a brief overview.

Some Background Information

In the field of Direct Digital Controls for Building Automation Systems we usually use
controllers specifically designed for the kind of tasks one would expect to encounter
when controlling electrical, electro-mechanical, and mechanical equipment that might be
found in office buildings, retail stores, government buildings, hospitals, schools, and so
forth. That is to say; heating, ventilation, and air conditioning, refrigeration equipment,
boilers, pumps of various kinds, hot water heaters, lighting, electrical power distribution,
backup power supplies, etc.

In addition we integrate with, or sometimes directly control, fire detection and protection
systems, door access controls, intrusion detection systems, CCTV, and other life and
safety equipment.

Commonly, fire system, security, and such things as elevator controls are each installed
by specialists and each have their own specialized types of controllers and programming.
Which can and will function independently of the building’s main automation and energy
management system. The reasons for this are multiple. Depending upon the
geographical location of the site and local rules and regulations, it is common to find that
to design, layout, and install such things as fire safety equipment and elevators (and their
controls) one must have very specific licensing and certifications. And that the
controllers used for these purposes be specifically certified, tested, and approved for the
purposes. In addition, one line of thought among building architects and design
engineers is that one should NOT put all of one’s eggs in one basket. That is to say,
failure of one system, for whatever reason, should not necessarily shut down everything
all at once. In addition one does not necessarily want ONE person sitting at a single
control and monitoring station to have direct access and control of all functions and to be
able to make changes and modifications to systems that person may, or may not be
competent in and knowledgeable about. Or to inadvertently through simple typo,
mistake, or shear ignorance to change the wrong control parameter.

Thus, commonly, specialized systems of the type I mentioned above are installed by
specialists using specialized controllers. Usually capable of operating independently of
anything else. But are then interfaced with and integrated with the building’s general
automation and energy management system. Although, all of it MAY be installed by one
company. For instance, the firm for whom I work has fire system and security
specialists. Fully licensed and certified in those specialties, from engineers to technicians
and installers. As well as having engineers, technicians, and installers who are fully
qualified for general building automation system controls. And in some cases we’re the
sole contractor who provides all the above services. However, this is not the norm. Few
firms have all the qualified specialists on staff. And even if they do, customers like to
diversify which piece of the overall contract as to be awarded to which contractor. For
various reasons. To encourage more competitive bidding. To be not reliant upon a single
contractor for everything. And so forth.

When I speak of interfacing with, or integrating one independent control system with
another, I’m speaking about the ability of these systems to share information between
them and to interact in a coordinated fashion. Even though one system does NOT
directly command or control the other. I’m also speaking about a
customer/owner/operator being able to sit down at a single interface (front end, usually a
desktop or laptop computer) and being able to see data, retrieve it, and so forth that may
be generated from several independent controls systems. Presented all in one place, even
on one screen display. Said operator might also be able to issue a single command, such
as a time scheduling command, which would be acknowledged and obeyed by any or all
of these independent systems. Or management or the accountants can retrieve, from a
single interface, any relevant or needed data for some management or accounting
purpose. With the data originating from what may be otherwise independent systems
within a building. Or even, from independent systems located in many different
buildings, each geographically separated by long distances from any other.

Why might one want integration between control systems within a building? For many
reasons. But here are a few examples.

An office building that is normally open for business (occupied) from 8 a.m. until 7 p.m.,
5 days a week. Its fire, security, lighting, and HVAC control systems are four separate,
independent systems.

But suppose an authorized worker/occupant has a need of coming in early in the morning
to get some work done. And uses an electronic door access card to gain entry. Being that
this is a normally “unoccupied” period, the building would be in “sleep” mode. Non-
essential services shut down to conserve energy usage. The security system notes that the
person is authorized and grants entry. But more than that, it then notifies other relevant
systems. The building’s lighting system controllers lights up a suitable path down
hallways leading towards the elevators, and from the expected floor of destination
elevator lobby to the worker’s office. The elevator system is notified and immediately
dispatches an elevator to pick up the worker, and allows ONLY service to the appropriate
floor. In the meantime, notification has been passed to the specific air handler that serves
that office area and it kicks into operation. The air handler notes the current temperature
within the destination office spaces and decides that it needs to heat up those spaces from
a “set-back” (unoccupied) temperature level of 60 degrees that it has been maintaining,
up to the occupied setpoint of 70 degrees. So it notifies the building’s heating boiler of
this requirement, and a boiler fires up and starts heating the heating water loop, heating
water circulating pumps kick on. Etc. At this stage, ONLY the relevant air handler for
the appropriate office spaces is operating, and the boiler system is only firing a the lowest
possible level of activity needed to provide adequate heating for the need. The rest of the
building would still be in set-back mode (sleep mode). And would be operating only
intermittently, in short spurts, as needed to ensure that no space temperature drops below
some minimum, set-back, temperature. And would do so until the normally scheduled
wake-up (occupied) time. Which, BTW, would not be 8 a.m. The control system, if
properly programmed, would be constantly tracking the outdoor air temperature, and
would know from previously collected data the needed information for calculating an
appropriate “start-up” time (morning warm-up). And would be expected to start up at
this calculated time in such fashion so that those office spaces would be warmed up to the
normal setpoint, let’s say 70 degrees, at 8 a.m. Thus, energy would be used only as
needed, in the amounts needed.

Now let’s suppose that in this same building has a fire detector which detects fire. The
detector reports this to the main fire system control. Which, besides executing its own
pre-programmed instructions, passes this information on to other control systems. For
instance, the HVAC system might broadcast to all of its member controllers the
information that there was a fire reported, and in what specific fire control Zone. In that
relevant area air handlers might shut down, fire/smoke dampers would slam shut, select
smoke exhaust fans would start up, etc. In other areas dampers and fan speeds might be
adjusted to over pressure selected areas to prevent any possible intrusion of smoke. Or to
at least retard the spread rate. In addition, the security system might unlock otherwise
locked doors to facilitate faster evacuation. The elevator system might go into some pre-
programmed mode to facilitate evacuation. Lighting on selected routes for evacuation
might go into full brightness. And so forth. In addition, besides the “fire panel”
sounding audible and visual alarms, and dialing the local fire department, the building
automation system might, following pre-programmed instructions, start sending out
emails and/or text messages to all occupants or only to selected persons such as the
facility maintenance and management personnel alerting them as to the specific alarm, as
to it’s nature and exact location. So that this staff might take appropriate actions. It
might even notify upper level management located at some headquarters office half the
planet away, or even at their homes.

Get the idea?

Types of Controllers
There really isn’t any such thing in this industry as some “Official” classification for the
various types of controllers used in building automation systems. I have read documents
and web sites whose authors have asserted that there are specific classifications. But
their claim is more opinion than fact. Manufacturers of the controllers don’t generally,
necessarily agree and often enough produce devices that are not easily classified as being
one type or another. So what follows is to be taken with a grain of salt, and ensure you
are wearing your hip waders as you read as you’ll find that my opinions are no better than
any other and the BS could be piled wide and deep.

Generally speaking, by conventional usage, controllers COULD be classified as being

either unitary or non-unitary, and further classified as being an ASC (application specific
controller) or freely programmable. They could also be referred to as specific purpose
controllers, or general purpose controllers.

There are also classes of controllers which might be called management (or supervisory)
controllers, and a class that might be called INTEGRATION controllers.

This does not even include devices that might be more properly called repeaters, routers,
bridges, gateways, web servers, and so forth. Some of which perform multiple functions,
can do any or all of the above, but which might be used only for a single purpose.

But, I’m going to keep things simple here. This is, after all, only an overview.
As a note … generally speaking those devices designed IAW the generally accepted
methods, materials, and built-in functionality so as to be called PLCs (programmable
logic controllers) are not used in the Building Automation Systems world for controlling
HVAC systems, lighting, and so forth. That is not to say PLCs are NEVER used in
building automation systems.

The reasons are many. PLCs were originally designed to replace relay logic using
discrete relays and their design and common usage was aimed at utilization in the
industrial and commercial process control world. i.e. In factories to control automated
production processes, in chemical processing plants, in industrial robots, and so forth.
Design of their internals and the programming languages for them favors very high speed
input signal processing; fast program scan times (fast looping thru the program code); bit-
wise data manipulation; heavily binary oriented logic; weaker analog logic capabilities;
sturdier and more robust electronics and hardware suitable for operating in harsh
environments, and so forth.

None of which is always true of all devices labeled as being PLCs, but which is generally
true.

Net result, are devices which tend to be more expensive per control point (an input or an
output), and whose programming language and methodology tends to be hard for the
average HVAC technician, for instance, to grasp and understand.

That said, you will find occasional instances where PLCs are indeed used in building
automation systems. For instance, a factory which already uses many PLCs to control its
manufacturing machines, whose owners have decided to automate the building’s HVAC
system, might elect to have PLCs used for that purpose given that they already have an
in-house maintenance staff who’re familiar with those types of devices and their
programming. In other cases, I’ve seen PLCs used for single, specialized control purpose
employed as a boiler (only) control, or as the built-in controls for a VFD (variable
frequency/speed motor drive). However, as a generality building automation system
technicians and engineers won’t be dealing much with devices called PLCs.

Within the building automation system world, what are generally used are controllers
designed and built for the purpose. Their scan and program execution rates need not be
as fast as that of a controller that is controlling an automatic packaging machine that’s
performing 101 actions every 5 milliseconds. And while they’re generally built to much
sturdier and robust standards than what would be required for an ordinary desktop or
laptop computers, they usually don’t need the rugged construction of a PLC that might be
located within the production area of a metal smelting plant.

In addition, the electronics, built-in firmware, and programming languages are generally
designed to better suit the needs of the types of equipment they are expected to control
and the kinds of tasks they’ll be programmed to be performed.
Net result, building automation system controllers, designed to be such, tend to be
cheaper per point (per input and output), and their programming languages tend to be
easier to understand by those expected to program them and more suitable to the intended
purposes as concerns types of commands, statements, functions, and so forth. There will
be a bit (a little bit) more on this programming language issue later.

Generally, controllers for building automation systems usage can be broadly classified as
either unitary or non-unitary.

A UNITARY controller is generally understood to be one which can be wired and

programmed to control an entire machine or system and which will merrily go about
doing its job without the need of anything else. Such as any other controller, or
information or commands originating from outside of itself and the sensors directly wired
to it. In short, it’s a “stand alone” type of controller.

For instance, what is called a model GX controller, made by one manufacturer, could
have all the required input sensors and outputs wired to it that are needed to constitute a
complete, independent control system for a rooftop air handler. Then a suitably designed
program dumped into its computer brain. And it’d perform its task day in and day out
with no outside intervention or interaction just like it was a more conventional control
system specifically made for the purpose and built up of discrete electrical/electronic
components such as relays, cycle timers, and so forth. The difference being, that with
this DDC controller, one could make major changes and revisions to virtually every
function without having to rewire a thing or replacing/adding components. Or only
minimal changes to those items would need to be accomplished.

A NON-UNITARY controller is one that is somewhat and somehow more limited.

Perhaps it has no, or only limited, electronic “brains” such that it can not alone hold all
the necessary programming to fully control our example rooftop air handler. For
instance, the device connected directly to the rooftop unit might simply be a “remote” I/O
unit. Simply a device to which local inputs and outputs can be connected. But which
otherwise has only the ability to communicate over a data network with a “controller with
brains” located elsewhere, sending it the information received by its inputs. In turn, the
controller with the brains, which contains the operating program, sends back the data
telling the remote I/O unit how to manipulate its outputs.

The obvious problem with this scheme is that if the network wiring is cut or otherwise
faulted out, then the rooftop unit won’t operate correctly, and may in fact continue doing
something which will cause failure or damage to its components. In other words, to use
the old Navy parlance with which I am all too familiar, being retired from that service,
the rooftop unit becomes DIW (dead in the water). Just an expensive collection of metal
doing nothing useful.

Another consideration is that in the case of using non-unitary controllers, as in the

example above, is that you have now multiplied your possible points and causes of
failures. In more than a simple arithmetic progression. Consider that you are now reliant
upon TWO electronic devices in order to adequately control that rooftop unit. Internal
electronic failure of either results in a failure of the whole system. A faulty data network
connection between the two can result in total failure. And power failures of the power
supply for either the remote I/O unit OR the power supply for the master controller (the
one with the brains and the program) can result in total failure.

Another example of a non-unitary controller type installation would be the use of two
controllers, both having inputs and outputs, and both having at least some “brains”, but
neither having adequate amounts of any of the above to accomplish all the control
functions of that rooftop unit alone. Thus requiring 2 or more controllers. Same
problems as with the first example.

Non-unitary controllers have their useful applications. But use with caution. Myself, I
generally avoid their usage whenever possible and follow the old rule of KISS (Keep It
Simple, Stupid). The fewer the possible points and causes of failure, the better IMHO.
My tendency is to use non-unitary controllers only for unimportant and non-critical
applications.

The next way in which controllers tend to be generally classified is as either an ASC
(application specific controller) or as a GPC (general purpose controller).

ASC (Application Specific Controller) refers to a type of controller manufactured for

use for a specific purpose and application. As a general rule, this type of controller will
have a certain, suitable number of inputs and outputs to fit the average intended
application of the type for which it was designed to control. And will come with built-in
(to firmware) programming pre-setup and targeted at the type of control that might be
used by the average device-of-type which it is to control. For instance, typical ASCs
found in the building automation world are manufactured to control VAVs, small air
handlers, roof top air conditioning units, furnaces, fan coil units, heat pumps, lighting
panels, pumping units, a boiler or pair of boilers, etc.

Generally, each input and output of an ASC type device is dedicated to a specific usage.
Its program is of a fixed type, unalterable, and the “programming” of it upon installation
simply consists of filling in the blanks, so to speak, where one is simply changing
setpoints and other operating data, as allowed … and ONLY as allowed … by the built-in
programming.

ASCs are handy devices. Easily employed and utilized for a project, easily setup and
“programmed”. Fairly easily wired in that the installer knows that for a certain ASC
controller that he has installed in the past, Input 1 is always Space Temperature, Input 2 is
always Discharge Air Temperature, Input 2 is always Mixed Air Temperature, and so
forth.

But ASCs have their disadvantages, also. For instance, the manufacturer of one of these
type of devices may have (and usually has) pre-programmed the device to only allow a
certain Sequence of Operation. (Those programming steps and functions that makes up
the entire control program) If we’re talking about a small roof-top unit, for example,
what this means is that it will operate ONLY in the way the controller manufacturer
dictates that it operate. It is possible, and not at all uncommon, for the roof-top unit
possess features and to be capable of additional functions/modes of operation which the
ASC manufacturer did not make provisions for utilizing. In addition, the controller’s
manufacturer might have one idea of how a particular roof-top unit should operate, but
the HVAC system design engineer for a whole building might have modifications or
additions to this sequence of operation he or she wishes to be implemented. Which might
not be possible to do (or at least not adequately) with the “pre-packaged” software
residing within that ASC. Thus necessitating the use of a general purpose, freely
programmable device with a custom made program or resorting to the method of using
another controller, with custom programming residing within it, located elsewhere, to
monitor the ASC and its inputs which would selectively override the built-in
programming of the ASC to FORCE an output to some value other than that which the
internal program was dictating. In which case the otherwise unitary ASC controller has
been reclassified by usage, to a non-unitary device. And would be subject to the inherent
disadvantages and problems of such type installations.

Another possible disadvantage might be simply a matter of customer preference. In some

cases we have projects that we work on where the customer specifically wants as few
different kinds of controller as possible installed, and prefers freely programmable
devices. Additionally, the customer may specify that a certain amount of extra inputs and
outputs, initially unused, be designed into the overall system.

Such customers are usually the savvier and more technically competent sorts, usually
with adequately trained in-house maintenance and repair staff. Their thinking and
planning being that if a project can be done using, for instance, 3 types of general purpose
controllers and one type of ASC, as versus a mix of 3 types of general purpose controllers
plus a half dozen (or more) types of ASCs, they can stock a total of 4 controllers on the
shelf for the making of quick repairs in-house. As versus stocking 9 or more different
kinds. Such type customers, of course, insist upon copies of the custom programs that
were dumped into each controller. And they want extra controllers installed over what
might be absolutely necessary, or controllers of “just the right number of inputs and
outputs for the purpose” replaced with controllers having spare and unused inputs and
outputs, to provide for easy, later expansion. That is, adding extra devices to be
controlled at a later time. Often done by in-house staff.

In such cases, initial purchase and installation costs are higher. But addition of extra
devices to be controlled is easy; sequences of operation modification can be
accomplished by simple program rewrites as versus controller replacement and perhaps
rewiring, and the stocking of repair parts is simplified. I’ve had customers who’ve gone
so far as to specify that the total number of different types of sensors, actuators, relays,
and such be kept to a minimum, and that they be of a type that’s commonly available
almost anywhere within the industry.
Above is a snapshot on one type of ASC device made by one manufacturer.
Above is a CAD drawing of the same controller, showing that it has 5 universal type
inputs, an input dedicated to being connected to a particular type of space temperature
sensor (marked SSB), two digital (only) inputs marked OIA and OIB, 4 analog outputs,
and 5 relay type (actually Triac) digital outputs.

This particular type of ASC controller is actually made to serve any one of three possible,
specific applications. It has 3 modes of operation. In each case the hardware is the same.
But, depending on intended usage special software and procedures are used to FLASH
the unit’s EEPROM memory, in order to install an application specific program within its
firmware. In this case, the controller can be made into an ASC for controlling RTUs,
heat pumps, or FCUs. (Other ASCs, made by this or other manufacturers may or may not
have this ability. i.e. They may be made to control one thing, and one thing only)

Using the appropriate communications and configuration software for this line of devices,
let’s look at its internal firmware.
Here we’re looking at one of the screens for configuring this controller in its heat pump
unit control mode. Look at the tabs and note some of the other screens that would be
available where you’d “fill-in-the-blanks” to configure the operation of this device.

Above I’ve changed to a different screen and you can see where a person would set up
the settling delay for the reversing valve, and where you’d tell the controller that when
the reversing valve output is energized, whether that’d be the heating or cooling mode.
The screen shot above is showing that for this controller, in the heat pump control mode,
it’s digital output #1 is dedicated to starting and stopping a heat supply air fan, digital
output #2 always controls energizing or de-energizing the reversing valve, digital output
3 is always stage one heating/cooling, and output #4 is always stage 2 heating/cooling.

I’m not going to make any attempt to show all of the configuration screens or control
parameters that could be modified. There are something over 1700 possible parameters
that might be set/changed. But most or all of the blocks would be filled in with factory
default settings and typically the technician or engineer would only change a relative few
of them.

Now, let us consider the very same piece of hardware, but a situation where we’ve
flashed its memory to hold a factory made program for controlling an RTU (roof top unit
- air handler).

I’m not even going to show the first, temperature control screen as I did above in the case
of the controller being used for a heat pump application. It’d look virtually identical.

Here I’m showing one of the Equipment setup screens. Notice it looks different right
away as compared to the same hardware in heat pump mode. We have the fan control.
But no tab for configuring a reversing valve, since there isn’t one. And there are two
different outputs EACH, used for cooling and heating.
The above just shows one of the heating configurations screens.

But note that in either the heat pump or the RTU modes, the outputs are definite purpose
and to be used only for the specifically listed purpose.

These are the type of things that distinguish application specific controllers, ASCs, from
general purpose controllers. They’re handy, they’re easily used and set up. But you have
little to no options and abilities other than what the manufacturer has provided within the
fixed programming.

GENERAL PURPOSE controllers are just what the name implies. They are controllers
which may be used for almost any number of purposes.

These can be sub-classed as being either freely programmable, or not.

The ones that are not freely programmable, generally come with built-in firmware,
programming, from the factory that consists of routines that allow the inputs and outputs
to be configured in different ways, and some number of fixed, built-in control loops and
functions. Such as multiple time-of-day on-off scheduling controls, time delays,
thermostatic control loops, PID loops, floating point motor control loops, built in math
functions for counting and averaging and/or Boolean logic functions, and so forth.

One performs the setup and configuration (sometimes called –programming-) of such
controllers in a method similar to examples I’ve previously shown in the section of the
Overview, and in the section about Outputs. One fills in the blanks, checks the
appropriate selections and so forth. To link a selected input (whichever you wish), or
inputs, to the particular type of control loop you wish to use, and then link the output of
the control loop to whichever physical output (digital or analog) you wish to use.

Very flexible, very useful, and easy. Such controllers can be used to control just about
anything. Or one controller might be used to control 2, or 3, or more different kinds of
devices all at the same time. Anything from pumps and air handlers (if the required
control sequences aren’t too demanding), to simple exhaust fans, lighting, security
devices, and so forth. The equipment such a controller has been removed? No problem,
re-use the controller for some other control purpose that is needed. Re-configuration and
“re-programming” for the new usage is usually a matter of minutes.

Freely programmable, general purpose controllers are somewhat different. Some types,
from some manufacturers include firmware for accomplishing certain, standard functions
easily. But also contain free memory area(s) designed to hold compiled, custom made
programs which can be created that can do things that built-in firmware can not do.

Others are a blank slate, for which you write custom programming for everything.

General purpose, freely programmable controllers are available in numerous, varied

sizes; as concerns the number of possible inputs and outputs, as well as the amount of
programming memory space they have. In some cases, program and variable data
holding space is all contiguous memory. Which would be able to hold ONE program,
and a number of variables and their data contents but one would have to be cautious not
to inadvertently reuse variable names for different purposes. In other cases, the
controller’s memory space can de divided into separate areas, each capable of holding it’s
own program and associated variables and data. All of which can run independently of
the others. So a freely programmable controller could in fact be running multiple
customized control programs simultaneously, doing various and different control
functions using different sets of inputs and outputs.

Below is an example CAD drawing of one such type, made by one manufacturer. If the
drawing looks familiar, you’ve seen it before in section of this overview that discussed
inputs and outputs.
On the top, left hand side of this controller is a terminal board which represents the
physical connections for the 4 analog outputs this particular controller has. They’re
marked AO1 through AO4. On the right hand side, top to bottom, are shown 8 single
pole, double throw relays; marked K1 through K8. Which are the digital (or binary)
outputs of this particular controller. To the right of them are two terminal boards which
are the connection points for wiring the contacts of these relays to something you might
wish to turn off or on. Lower left hand side shows the terminals for the 8 universal inputs
this particular controller has. This particular controller has both built-in control
firmware, and is also capable of being freely programmable and holding more than one
simultaneously running program.

If one needed even more inputs and outputs, models are available with many more built-
in I/O points, plus there are models that use one or another scheme that enables them to
be connected to external (or remote) I/O modules or expansion boards.

As I mentioned before, there are other types and classifications of digital controllers for
building automation systems. Commonly mentioned in literature, and commonly used in
many or most large systems is some sort of “System Supervisor” or “Building
Management” controller. Such controllers usually have a rather specialized function/set
of functions. And often do not themselves have built-in input and output terminals or
electronics for the purpose. Instead, they usually serve the function of being a central
communications hub, able to talk to any or all other controllers on the control network, or
at least those on the same network segment where the System Supervisor resides.
(Depends on the system installed. Some have a system supervisor on each network
segment. Others might have a single system supervisor with multiple communications
ports capable of talking to any other controller on any one of the ports, and whose
individual ports might be configured for different network communications protocols.)

In addition to being communications hubs, capable of sending data or commands to, or

retrieving information from any controller on any connected network port it has, system
supervisor type controllers might serve as routers and gateways. And often contain
sizeable ram memories for holding custom written programs to accomplish things that
individual controllers out on its network can not accomplish on their own for one reason
or another. They often also contain programmable means to perform data collection and
storage, analyze collected data and display trend graphs, and so forth. I have job sites
I’ve worked where one supervisory controller is simultaneously sending data to, or
collecting data from literally hundreds of other controllers connected to one or another of
its network communications ports, with some ports utilizing one communications
protocol while others use different ones. While at the same time it’s running a couple or
3 dozen custom programs to accomplish this or that task. AND actively maintaining and
updating a dozen or two energy usage trend logs (data stored to a hard drive). And
simultaneously talking over a standard Ethernet LAN connection to a standard desktop
PC where a building maintenance supervisor is viewing graphic screens showing
operating air handlers, pumps, boilers, so on and so forth. And as that maintenance
supervisor looks at each screen, the software on his PC requests from that supervisory
controller that it retrieve relevant, current data from the controllers out in the field to fill
in the blanks for the current screen with the appropriate information.

With some systems, from certain manufacturers, that System Supervisor (or Building
Management) controller might also include suitable programming and the facilities to
itself generate graphic screens for monitoring the system, or even for it to create Web
pages in HTML format with graphics, and act as a server. But usually, these last two
functions are separated out and handled by a specialized, for the purpose, controller or
it’s handled by software running on a desktop PC that has a communications link to one
or more supervisory controllers.

Desktop PCs, or their equivalents, are NOT usually used for direct digital control of
building automation systems. For many reasons. Which is a whole discussion by itself
which I’m not going to address in this overview.

As stated before, there are specialized controllers serving functions as dedicated routers,
bridges, gateways, and web servers. And still others that serve some multiple selection of
the before mentioned functions. And still others that are really hard to classify in one or
another category.

None of which I’m going into any detail about at this time.
I’ve mentioned the making of custom control programs many times now. Programs
that’ll reside with-in freely programmable, general purpose controllers. Or programs that
will reside within Supervisory Controllers (or Building Management Controllers).

How is this done?

In various ways.

Generally speaking, the person who is writing and creating control programs for
controllers that are part of a building automation system will NOT be using one of the
standard programming languages and compilers that most, who are familiar with such
things, have heard about. Or, not exactly the same programming language with which
one might be familiar.

The reason for this is that the microprocessor selected for use in this or that make and
model of controller is unlikely to be the very same type that’s in your home computer.
Although it may well be similar. And microprocessors ONLY execute, directly, machine
language instructions. And machine language instruction sets are very specific to the
particular microprocessors used.

For instance, one manufacturer with whom I’m familiar favors Motorola microprocessors
from a particular family line of microprocessors which Motorola makes. These are
industrialized microprocessors, built to withstand ambient environmental working
conditions that the microprocessor within your desktop or laptop computer would not be
able to tolerate for long.

Now, whereas this manufacturer has created a programming language for their line of
controllers which takes text based source code that looks a heck of a lot like ordinary
BASIC; with some extra functions, keywords, statements, and so forth added that would
be specific to control logic for building automation control functions. It has a compiler,
which compiles executables that are ONLY useable by that line of controllers. And no
others. The form of Basic used was specifically created by THAT manufacturer, and is
not exactly line for line, statement by statement, compatible with any other Basic
compiler.

But, it is close. If one already knows some form of Basic, learning the version used by
this manufacturer would be simplicity itself.

Many manufacturers of controllers used for building automation systems use a line
oriented method of programming, with a high level language that’s similar to some form
of Basic. Some are similar to GWBasic or QBasic, some have more resemblance to
Visual Basic and have object oriented programming features. Etc. Source code is made
using a standard text editor, and then it is compiled into machine useable form,
downloaded into the controller, and away yah go.
A sample of a single subroutine of a custom control program created for certain
controllers made by one manufacturer …
;-----------------------------------------------------------------------------
;Fan control sub-routine for GX/DX AHU program
;
;Sub-routine Attributes
; ;AM=2 0=off,1=on,2=auto & occ=ON,3=auto & occ=stat control
; ;FH=? fan heating setpoint
; ;FC=? fan cooling setpoint
; ;FF=0 value for fan status failure
;
FANCL:
on ;AM goto FANOF,FANON,FANAU,FANAU
FANAU:
;schedule flag
if (;SF == 2) then FANOC
;optimum start flag
if (;OF == 1) then FANON
;night setback/setup flag
if (;NF == 1) then FANON
goto FANOF
FANOC:
;occupied
if (;AM == 2) then FANON
if (;FH >= ;FC) then FANON
A = ;FH + 2.0
B = ;FC - 2.0
if (FANMVH < ;FH) then FANON
if (FANMVC > ;FC) then FANON
if ((FANMVH >= A) and (FANMVC <= B)) then FANOF
goto FANRT
FANOF:
FAN = 0
;ZF = 0
goto FANRT
FANON:
;check shutdown flag
if (;SD == 1) then FANOF
FAN = 1
FANRT:
return

Doesn’t look like much, does it? And it really isn’t given that it’s simply a small
subroutine within a much larger program, and any readers probably don’t know what the
variable names represent. If you did, you’d spot the line that compares a selected
temperature input to this controller to a heating setpoint, and if the sensed temperature is
less, turns on the digital output that starts the unit fan. Then, once the temperature has
increased to that setpoint, plus 2 degrees, as checked in another line, the fan is turned off.

The above code is a sample of coding done in SPL (Sage Programming Language), for
American Automatrix products. SPL is Basic-like, and a minimal version of Basic.

A more complete form of Basic might be something like Andover Control’s Plain
English Programming language. Below is a sample listing of the keywords for that
programming language.
And the above list does not include the list of readily accessible and useable system and
environmental variables and constants. Which would take at least another 8 pages of
very small print to list.
Some manufacturers offer only line code programming tools. Others offer what is called
Drag and Drop Graphical Programming … also known as Function Block Programming.
And some offer both.

Function Block programming is a visual programming method. With function block

programming, typically the manufacturer provides a program development environment
that’s visual in nature, and one selects appropriate function blocks (in icon form) from
whole libraries of various objects to accomplish one or another type of programming task
or function. Then one drags and drops what you want onto a blank canvas. Usually right-
clicking on the function block will bring up a form Window where-in you can set
parameters and attributes for the function block, fill-in-the-blank fashion. After you’ve
selected the items you want and need to accomplish your control function, and have
arranged them on screen in some logical, orderly fashion, you then commence drawing
lines between your function blocks, connecting them, to represent the flow of data,
sequence of decision making, and so forth. An example screen …

There are I/O setup and configuration blocks, network function control blocks, display
blocks, system information blocks, timers, conversions, decision makers, relay logic,
limit blocks, log keeping blocks, mathematics blocks, multiple selection blocks, time and
date blocks, counter blocks, so on and so forth.

Some samples of the screens you might see upon activating a block so as to be able to set
the blocks parameters and attributes.
A delay on make function block
A floating point motor control block.
A math block, in this case a multiply function.

A zone setpoint control function block.

At first function block programming can be a bit confusing and daunting, especially to an
old line coder like myself. But I jumped in with both feet, and once I got my feet wet and
figured out the major quirks with this sort of programming, it was a piece of cake.

I STILL prefer line coding. More flexible, more fine control. But function block
programming works well for relatively novice programmers. Especially those not
experienced with some form of line coding.

Folks in building automation systems work might also have a need to learn Java; and
HTML, XML, and Javascript. Depends on your specific assignment and job within the
building automation world. Some supervisory controllers, integration devices, BAS web
servers, and such can utilize custom programming functions written in Java and/or
Javascript. And while specialized tools are usually used to create the pages for control
system information and control screens to be “web enabled”, sometimes it’s handy to
know how to hand code your own web pages.

But does anyone interested in building automation systems control work HAVE to learn
Java, Javascript, etc? Nope. It varies from company to company, but generally speaking
those who do front end graphic screen creation and setups, and who work with
integrating multiple control systems, and the making of web pages that operate as
monitoring and control screens … tend to be specialists. Who do that sort of work pretty
much full time. It pretty much takes that to gain and maintain adequate speed and
proficiency at the tasks in order to turn a profit.
I myself, only occasionally do the HMI (human-machine interface) graphic screens. I
can do them, even do them pretty well. But I’m WAYYYY slow. It might take me 30
minutes to get one screen of graphics and data display just the way I want it, complete
with screen navigation buttons. A guy I work with could do the same in about 5 or 10
minutes. Depending on complexity. I let him do it.

Likewise I can program. But again, I’m slower than our full time programmers. Who
can whiz through program code almost faster than the eye can follow.

My niche in life and this business is primarily one of supervising installers and doing
testing and system startup and commissioning. My normal programming needs are a
matter of finding and fixing errors in programs, if any, created by our full time
programmers. I generally do this in the field, as I detect the errors, doing a re-write, then
I recompile the program, download it into the controller and do more testing. Likewise,
at some point I’ll start reviewing front end graphic screens created by someone else,
looking for errors, omissions, etc, and fix those. This, along with the usual things like
making sure the actual machines and devices work as expected, or making the fix to
ensure they do, sensor calibration, etc.

And then, of course, there are those who are full time installers. I know men who like
doing that, can do but hate doing controller programming or system testing. And there
are the system design engineers (who usually, but not always also do programming). So
there are many different areas within the field for one to work. And usually one ends up
becoming very good at the specific part of the job that one’s own personality enjoys the
most.

Next, I’ll discuss control data networks.