November 2008
Column -

AutomatedBuildings.com

BTL Mark: Resolve interoperability issues & increase buyer confidence
BACnet Testing Laboratories

(Click Message to Learn More)


Sequences of Operation

Generating concise, accurate Descriptions of Control
Part 2 of 2

An objective look at specified descriptions of control
(Part 1 of 2
)

Steven R. Calabrese
 

Steven R. Calabrese
Control Engineering Corp.

Contributing Editor

The “art” of writing a quality Sequence of Operation is a learned skill. We in the HVAC business typically are not writers, at least not in the literary sense. Yet many of us are often called upon to describe our HVAC systems, in terms of how they are designed to operate and how they should be controlled. We may know in our heads how these systems should operate, as we are the ones designing them, but translating that into prose is not everyone’s forte. Compound that with the complexity of many of the systems that we design, and you end up with a real challenge. To describe the operation of HVAC systems with precision, accuracy, and completeness is typically not a very simple thing to accomplish. Suffice it to say that generating descriptive Sequences of Operation for HVAC systems is not everyone’s cup of tea. For those bold enough to undertake the task of writing a Sequence of Operation, this column will provide some tips and guidelines that will hopefully make the process a little less painful and a little more structured.

Articles
Interviews
Releases
New Products
Reviews
Blogs
Sponsors
Archives
Past Issues
AutomatedBuildings.com

ABB

Sequence of Operation vs. Description of Control: A Tale of Two Terms

Although the above terms are often used interchangeably, there can be a distinction made between the two. For the purpose of this writing, we treat the terms separately, and define each term under this heading, starting with Description of Control.

When an engineer sets out to write about his mechanical systems design, as the first step he will account for all of the equipment that makes up the systems, and generate a basic framework from which he can develop a description. From there, he may choose to write simple “general narratives” of each piece of equipment and of how they operate within the systems. Without getting too detailed, the engineer accomplishes the task of accounting for all equipment, and of describing how each piece of equipment is to operate, individually and as part of a system. This is what is referred to (by this writing) as a Description of Control.

Descriptions of Control will tend to be fairly general, and are frequently created as the first step toward generating full-tilt Sequences of Operation. Descriptions of Control are what are typically generated for T/C submittal purposes, to be included in submittal packages (along with control diagrams, points lists, etc.). They can be fairly detailed, such as for “boilerplate” applications like packaged rooftop units and VAV boxes. However, they will generally be more streamlined, leaving out operational details such as exact setpoints, precise alarm limits, scheduling and time-of-day details, etc.

Sequences of Operation are generated as fully descriptive, detailed accounts of system operation. They will be developed during the design process, and finalized upon commissioning, when the operational details are initialized and validated. They will go into detail as much as they need to, in order to give the commissioning agent, service technician, end user, and anyone else involved with the systems a solid understanding of how the systems operate and how they are controlled. A Sequence of Operation is the final record of system operation, and is to be included on the control diagram “as builts”, and/or as part of the operation and maintenance (O&M) manuals that are turned over to the customer.

As the subtitle suggests, this writing describes more so how to generate a Description of Control than it does a Sequence of Operation. Nevertheless, generating Descriptions of Control is a good first step toward writing full-blown Sequences of Operation, and, depending upon how detailed you need to be, a well-written Description of Control can often pass for a Sequence of Operation.

Traditional Methods of Writing Control Descriptions

Of course, the first time an engineer set out to describe the operation of an HVAC system that he designed, he basically started from scratch, as there was no existing verbiage to call upon as reference. As engineers plow through their careers, they tend to run across similar applications, and they call upon past projects to help them with their present design challenges. Writing control descriptions is no different, for we tend to call upon some past sequence that was written from an earlier design, and try to fit it to a current application. While this method is quite valid, especially when you compare it to “starting from scratch” every time you write a sequence, it is sometimes difficult to remember just which job in your engineering past has the same or similar aspects of the job that you’re currently working on. Creating a “tracking system” by categorizing projects and keeping the listing in a spreadsheet or database form can simplify your efforts and narrow your search for the past project that’s similar to your current project.

Copying and pasting portions of old sequences into new ones is a process that has been popularized via the (not-so) recent developments in computer technology. It’s a simple task to “cut and paste” a chunk of text from an existing document into a new document. This method of generating control descriptions is valid, and has its merit. Yet care must be exercised so as to avoid redundancy, contradictory items, and inclusion of items that don’t apply to the current system that is being described.

Creating Your Own Description of Control

When a Description of Control needs to be created for a complete project consisting of many systems and equipment, the description of each individual system and each piece of equipment can be categorized as one of the following:

A system or piece of equipment whose description can be categorized as “Typical” is one whose operation is generally the same or similar in all applications, with little or no variance from application to application (with the exception of setpoints and other miscellaneous operational details). For Description of Control purposes, these types of systems and equipment can be described in a general manner, and these general descriptions can be used over and over again, for all applications consisting of such systems and equipment, with little modification to the descriptions, if any at all. Examples of such equipment falling under this category are packaged rooftop units (controlled by conventional thermostats/methods), VAV and fan powered boxes, exhaust fans, and various unitary heating equipment.

“Custom” descriptions must be created for those systems and equipment whose attributes prevent them from being accurately described in a generic, reusable form. These types of systems and equipment are generally larger and more complex than those of which are categorized as “Typical”. Yet they are common enough to where “base” descriptions can be created, and hence customized to fit future applications. A boiler plant is an example of a system of which this would apply to. A description of a two-boiler, two-pump hot water system can be written for a particular project, and then modified or “customized” to fit a future project similar in design. Most of the more popular HVAC systems and equipment can fall under this category.

The purpose of the above paragraphs is to demonstrate that many types of systems and equipment will have Typical descriptions that do not need to be written “From Scratch”. On the other hand, there will always be systems and equipment whose descriptions “must” be written From Scratch. And somewhere in the middle of this, there are systems and equipment whose descriptions can be written from a “baseline” description, by Customizing it for the specific application. The conclusion is that it is impossible to completely automate the process of generating a Description of Control. However, the process can be simplified, or “semi-automated”. Getting there is up to you, however the following can get you pointed in the right direction, and at least will stimulate your mind into thinking about it, and perhaps coming up with your own method.

The first step is to generate a framework, if you will, that is structured in such a way so as to be able to build upon it efficiently and accurately. You may want to start in simple outline form, and list out some general headings, which you can tailor to each specific project. Then list out headings for all major equipment types, in an order that’s meaningful to how you will be describing the systems. Finally, you can include some descriptions under some of the equipment headings that fall into that “Typical” category described earlier.

Your next step is to compile a library of Typical and Custom descriptions, either from past projects or from scratch. You can set up the library as a compilation of folders that are categorized by equipment type. Create subfolders (as required) that further categorize the main folders. Store your narratives in the subfolders, and be sure to name the subfolders with a clear description of the narratives stored. Assemble a binder containing printouts of all of the descriptions. You will find that having hardcopy printouts arranged in a binder will facilitate the selection of the appropriate narratives for your particular systems and equipment.

Now comes the fun part. Pick a project, and implement the process. Save the framework document as the project name, and customize it accordingly. Go through the framework and delete any equipment headings that don’t apply. For all of the Typicals and Customs that you require, go through your library and select the appropriate narratives. For any given narrative, copy the text from the narrative file, and paste it into the framework, under the appropriate heading. For the Typicals, ensure that the narrative accurately describes the equipment. For the Customs, revise as needed, to more closely match the equipment. And for those From Scratch narratives, I’m sorry to say that you have no choice but to start “from scratch”!

The method described herein is classic “copy/paste”, and is not without its drawbacks. However when tasked with the mission of generating a Sequence of Operation for an HVAC project, we need to start somewhere, and this sure as heck beats starting from square one!

Tip of the Month:
You can visit my website for my implementation of the above system at www.pcs-engineering.com. That gratuitous self-promotion aside, there’s a neat little “professional grade” online productivity tool that can facilitate the generation of control specs and sequences. And while I’m not here to endorse it, I have used it and have found it to be quite helpful in certain situations. The URL is www.ctrlspecbuilder.com, and it’s free, so go take a look at it and see for yourself if it’s something that you can use. No harm in trying, right? Especially at that price!
footer

opsys
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]

Events

Want Ads

Our Sponsors

Resources