DDC master planning

‘Master planning” for direct digital control (DDC) conveys a number of meanings. In this article, we’ll use two perspectives.

The first is a need for a DDC system master plan that should exist for an institution, site, or logical group of buildings. This could be for a college campus, a local K-12 school system, a portfolio of commercial properties, a corporate site, a military base, or a national chain of retail stores. Any logical grouping of facilities maintained and operated by the same group of individuals would benefit from a similar design approach for the control of the HVAC systems in these buildings.

The second type is planning that should occur for almost every project. An engineer should not design the DDC system for a specific project without consideration for future expansion, existing DDC systems, preferences, and standardization—and numerous other considerations relative to that project.

System architecture

Start the project by asking some basic questions: How big is this project? How will future projects tie in to this network? How will this project tie in to the existing network?

The project could be a relatively simple stand-alone commercial building with packaged rooftop equipment. There is no planned expansion for this project in the foreseeable future. Or, the building could be a similar building, but it is on a university campus where there already exists a preferred vendor or multiple acceptable DDC systems. And instead of packaged equipment, the building systems now are connected to a campus steam and/or chilled water system.

So ask yourself: How sophisticated is the monitoring of this system going to be? Does an existing information technology (IT) infrastructure exist that the project can use locally? Can this project use that communication network? If so, what are the requirements or does that change the design? Does this system need to be seen from other sites on the existing system?

In the simple standalone project, this may require remote monitoring through the Internet. The campus project may require specific IT connection specifics based on the campus IT standards.

Many questions, and from a big-picture perspective the answers, depend on the specific project being considered. It would be ideal if all of the DDC systems available to us today were similar in their architectural robustness, but things are never that simple.

The design engineer should ensure that the system designed is robust for the applications being controlled and for the operator’s intended use of the system. Some of the criteria that impact DDC communication robustness include technical details like speed and communication protocols, but others are more difficult to pin down and specify across all manufacturers.

The physical number of nodes connected to the network or sub-network will impact performance along with the amount of traffic on the network at any given time. Specifying criteria, such as the length of time for specific tasks to occur, is a way to require performance without getting into too many specifics that vary from vendor to vendor. For example, you might consider how long it will take for a start/stop command to initiate the controlled device, or how long it will take for a critical alarm to enunciate at a central workstation. Another useful indicator of overall performance is how long it takes to refresh a graphic screen containing 20 points of information. These type of performance criteria are easy to specify and easy to measure. Details need to be specified on what else is happening (network-wise) while this testing is occurring. For example, normal trends should be running during this testing to simulate typical operational modes.

System controllers

Similar to the various system architecture choices, numerous types of hardware controllers for basic HVAC systems types are available. This fact should be relatively obvious because controller costs vary from less than $100 to more than $2,000. Typically, the “less than $100” controllers are meant for terminal equipment like variable air volume terminal boxes or fan coil units. The $2,000 controller is meant for more critical equipment like large built-up central air-handling units or chilled-water systems. Many controllers fall between these two cost extremes.

Is there a difference between Vendor A’s $650 controller and Vendor B’s $1,400 controller that appear to do the same thing? Do you know? Are you sure? Does it matter? What are the factors that might influence the cost of these devices, and will these things influence the performance of the system being designed?

If you were looking at similar costs for a notebook computer, you might expect to see less software on the less expensive model, and see more memory, a higher-resolution screen, faster hard drive, and more software bundled with the higher cost machine.

Similar variables make the difference in DDC controller hardware. Key issues include processor power, memory, clock accuracy, and communication capability. Limitations on the controller performance could impact the following:

• Accuracy and resolution of inputs and outputs

• The complexity of the logic that could be programmed locally

• Whether the programming is configurable or can be customized (and to what degree)

• Capacity to store data.

Depending on the application, this may be significant, and to most projects this is important criteria. Conversely, over-specifying controllers for a less critical system will drive costs higher unnecessarily. The engineer should be familiar with the various types of controllers offered in our industry and require the types of controllers appropriate for the application being designed.

System interfaces

DDC systems interface with other things in our buildings. Naturally, a DDC system by its nature interfaces with the HVAC system it is controlling through its inputs and outputs. It also connects to other building systems in different ways. The engineer needs to make some planning and design decisions as to how these interfaces take place.

A DDC system interfaces at the most basic level with the users or operators of the system. These operator interfaces can be a computer workstation, a portable workstation (notebook), a manufacture specific hand-held device, or a built-in keypad on the controller. These types of operator interfaces have different functions and capabilities and, as with everything else, their performances vary between manufacturers. Increasingly, larger applications use server-based systems, which add another level of design decisions and necessary considerations. The engineer needs to be familiar with the capabilities of the various user manufacturer interfaces and match these capabilities and functions to the needs of the owner/operator.

Other types of DDC interfaces are more networking-type interfaces. These could be between the overall building DDC system and the packaged equipment that might come with a major piece of equipment like a chiller. Increasingly, packaged equipment like heat recovery systems, pumping packages, humidifiers, 100% make-up air units with heat recovery, and computer room units may come with an option for their own control system.

This brings up more questions, however. If the project has lab controls, how do the two systems interface? If the building system interfaces with another system, how will that happen? Is an open-protocol standard part of this interface and, if so, what protocols are acceptable? What information should be accessible from the building system?

Typically, there may be much more detailed information available in the underlying system. Do you need to have all that information available at the building system? What is the impact to the cost and speed of the system if you require that all the information is transferred to the building system? What parameters would you like to change in the underlying system from the building system? Again, the answers are very project-dependent, but need to be clearly specified and planned for in the overall DDC system design.

A more complex system-to-system interface occurs when the engineer attempts to have multiple systems interoperate. This can be accomplished by using an open protocol allowing two different systems to share information. This also can occur between various “vintages” of one manufacturer’s versions or systems. Typically, the interfacing that occurs between various offerings of one manufacturer is handled by that manufacturer.

The questions that need to be asked to effectively integrate different manufacturers are many and relatively complex (and probably the subject for a different article). As with equipment interfaces, key factors include the level of visibility and functionality available across systems. It is relatively easy to make visible specific hardware point values across systems. It is another level to expose “parameter level” details such as alarm limits, calibration values, overrides, tuning parameters, and similar factors across systems. These details may not need to be displayed across systems, but if it’s desired or required, it needs to be specified as it has significant network bandwidth, hardware, and set-up time impacts.

Another detail to consider: What level of functionality would you expect? For example, can system A trend system B points? Can system A schedule system B equipment? Can system A alarm based on System B parameters? You should also consider the changing of set points, reset schedules, or other programming details between systems.

Other details

Training and documentation requirements are equally important factors in the design of the system. If this project is going on a site where the operators are inherently familiar with the system being installed, there may be the need for a demonstration and orientation-level training session only. More often, the DDC system may be new to the inheriting operators. This fact may require a brief assessment of DDC capabilities and needs as part of the project. If it’s a small project, the budget may not afford too much specialized training above and beyond what typically is provided. Conversely, a larger project may be the place to require advanced training on DDC systems for a given institution. Regardless, if system performance is to be maintained, operators need to be trained on the DDC system.

Documentation also needs to be covered in the planning of a DDC system. Documentation requirements can cover how submittals and shop drawings are organized and presented. It can cover details like addressing and point-naming conventions. Wouldn’t it be nice to see similar names for all the points on hundreds of air handlers across the same site or campus? Or to be able to look at a standard point addressing format and quickly know specifics about that point (such as building, system number, point type, etc.)?

Documentation requirements could also include details on how graphic pages are laid out, and could require that these graphics be made part of the submittal and approval process. The key is getting the graphics reviewed and approved early in the process. Most DDC application engineers don’t mind customizing graphics for an owner as long as they do it only once.

The above DDC criteria ideally would exist for every owner and could be used for every project. Unfortunately DDC master planning hasn’t received the same level of attention as IT infrastructure planning. Detailed planning documents exist to get a new building on the corporate, university, hospital, or county on local area network. If these details were not planned out, we would have less reliability, higher maintenance costs, and less secure networks—and ultimately business conducted through these networks would be less effective and efficient.

What’s at the other end of our DDC systems and the HVAC systems they control? A significant portion of the energy consumption of the building, the quality of the air we breathe while in the building, and the productivity of the most important assets in the majority of buildings—its occupants. Shouldn’t these systems have a similar level of planning as our information systems? With the increased focus on energy performance of buildings, our carbon impact on the environment, IAQ, and building performance and persistence, maybe this planning finally will get the attention it deserves.

Author Information

Santos is a principal and co-founder of Facility Dynamics Engineering. He has directed the development of DDC/control master plans for numerous institutions and organizations.

Master planning considerations

Current installed systems

• Manufacturer, vintage, quantities

• Interfaces (operator, specialty)

• Communication details

Anticipated future needs

• Buildings

• Obsolescence of existing systems

Procurement plan

• Sole Source

• Multiple vendors

• Pre-qualified

• Interoperating

Standards

• Point lists for equipment

• Sequences

• Accuracy requirements

• Alarming

• Trending, historical data

• Commissioning and demonstration

• Training

• Documentation

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.