7 Reasons to Use Modular Integration and Object Oriented Design in Data Centers

7 Reasons to Use Modular Integration and Object Oriented Design in Data Centers


By: Mike Kalkas

Don’t reinvent the wheel; use object oriented design for increased maintainability and sustainability.

Today’s growing gaps due to big data and fast-paced changes in co-location data center environments can easily be overcome by designing a data center through modularity and object-oriented principles.

The problem is, data center owners usually do not have a good handle on exactly what they need in an EPMS system, and leave the decision makers to make software package decisions based solely on initial cost without giving enough thought to if the software is the right tool for the job. The correct tool will always yield a faster payback period than the incorrect one. Not to mention the increased savings gained by ease of scalability and reduction in human errors.

Learn How We Helped QTS Data Center with Their EPMS.

Many data centers don’t immediately see the benefits of a good design plan that includes a modular design and specification of the proper object oriented software tools. Like using a key as a blade to cut something, many data center operators find themselves wishing their shiny new EPMS would meet their needs better and provide more control and profitability. It’s always an expensive route to go back and rebuild your systems after the fact, so this usually isn’t an option.


Object Oriented: What Does It Mean?

Object oriented design (OOD) and modular integration is a process of designing a system around software “objects” and blocks. Using one common language, similar equipment, and standard layouts, integration is broken into smaller, easily-managed blocks quickly and cheaply added through a cookie-cutter approach.

Object oriented design includes things like building an alarm tree where each “leaf” (group of alarms in an object) is the same for each branch (device/object alarm type), determining the critical device points needed for each generic device type and which ones need to be historized, as well as defining the standard communication protocols, standard configurations of equipment layout, etc.

The more modular and well planned the initial “block”, the easier it is to vet this block through commissioning and the better the savings as new blocks are added. Savings come from doing the majority of the engineering and design up front on the first block, so nothing should need to be changed in the following blocks. Making changes after the fact sets you back to square one and reduces any benefits you could have received.

Next, a control system integrator identifies each device to be represented in the software (e.g., meters, ties, transformers, PDUs, breakers, generators, UPS’, controllers, CAHUs, pumps, transformer temperature monitors, etc.) Then, he makes a master template for each type that includes all common components
(e.g., functionality, attributes, etc.).

By cloning (deriving) the template, he can reuse it with only minor changes to accommodate any changes between actual devices (e.g. two different models of a meter or even different meter manufacturers). By a similar method he will clone groups of objects to create each new block and then only need to modify the configurations to accommodate differences in name, physical location, etc.

The Importance of Templates
By using a templated approach, a data center can standardize a function (like a high alarm or smart temperature controls) and apply it across all blocks in the environment. This is due to a feature called inheritance. If I make a change to an attribute in the master template, that same changewindow-941625_1920 is then reflected in all “cloned” templates and associated objects. However, if I make a change in a “child” template, that change is only seen in the child and any objects associated with that child.

Is there a case when object oriented programming wouldn’t make sense or would be too restrictive to a data center environment? Absolutely. If each instance required over-customization beyond just a few fields (e.g., name, IP address, number of circuits, etc.), it’s probably not worth it.


Object Oriented Design Is NOT Copy/Paste

Contrary to popular belief, object oriented principles are not the same as copying and pasting.

The copy/paste approach doesn’t necessarily copy all attributes from the original application, due to versioning issues. You’ll still have to customize for variation in devices to make your copy an exact replica. However, modifying a device in non-object oriented packages can be costly, time consuming, and lead to human error and potential data integrity issues, especially when working under the pressures of a fast-paced new construction environment.

With object-oriented programming and inheritance, a human need only adjust the few parameters custom to each particular device because all other parameters and functions are part of that general device master template. If application-wide changes need to be made, the integrator adjusts the master template that reflects across all associated objects and instances. Copy and paste doesn’t provide this inheritance feature and relegates you to the drudgery of modifying each object individually.


7 Business Case Reasons for Object Oriented Design

There are dozens of reasons your data center should be using object oriented programming and design. Here are 7 of the most important:

1. Quickly make system changes
When one object inherits the characteristics from another object, data centers can easily execute changes within their environment on a very short time frame. If I created an instance of a PDU in a non-object oriented environment, I’d have to individually set up alarms, point it to the right IP address, add the web link, etc. Then repeat all that work for the next one. Since I use an object oriented program, I define all those parameters manually, but only in my template. Then as I create each instance, all I’ll have to change is the name, IP, and location attributes.

In addition, modular integration allows a large number of new devices to be integrated with minimal configuration changes, since each block is the same as the last and the group of objects that represent the block can be cloned.

2. Reduce engineering time on variances of installation
If you’ve done your object oriented design homework, you should only need to engineer for minor changes to your initial block rather than starting the design process from the ground up. For instance, if your original block included an electrical board that had 12 breakers but your current block needs 14 breakers, it is easy to just add two more breakers.

3. Lower lifecycle system costs
Having a single, customized template with the ability to be replicated across an entire data center allows for huge savings when it comes to monitoring and controls.

  • The cost of facility monitoring decreases as you increase the scale of your facility. While initial labor costs to make one master template are higher, any changes or maintenance completed after the fact will take a fraction of the time.
  • Because of the standard scope of each block and repetitive nature of developing and integrating each block, much of this work can be done using remote desktop and VPN, eliminating travel costs to and from facilities.
  • Because you know you’re going to create an instance of the same meter over and over again, you can buy your equipment in bulk and save on material costs.
  • Templates can even extend across multiple facilities, which lowers costs even more.

4. Manage complexity with easier reporting
Object oriented design ensures proper and consistent naming of key points of interest that reduces the effort needed to bring them into nodes for easier access across the entire enterprise. It helps whittle points down to only what is necessary to decrease data complexity and duplication, ultimately reducing bandwidth, storage, and management time costs.

Because of each piece of equipment is standardized at the template, pulling values for reporting purposes is easy. For example, RPP panels are in the electrical device family, and since I know everything in the electrical device family has a field for current, all I have to know is the name of the particular piece of equipment I want the current data from, and I have the fully qualified tag for pulling the data.

5. Keep the system standardized to avoid human error
It can be difficult to keep integrations standardized from one device to the next, let alone across locations. By using an object oriented approach, everything is virtually identical across similar devices and locations and human error is reduced, which ensures consistent and accurate data for when data center owners wish to bill their clients. (SEE ALSO: Submetering)

An increase in standardization also indicates less error. The way object oriented programming is designed actually forces the development through a consistent and purposeful architecture to consolidate data, which helps prevents data loss.

6. Agile scalability
Data center designs take time to think out properly, but most owners don’t have that luxury. If engineers didn’t formulate a well-defined design in the beginning and mistakes are found later into construction, modification will be difficult and time consuming (representing significant cost).

Luckily, OOD lends itself to speed in the rapid development, deployment, and integration of new facilities and maintenance of existing facilities.

Object oriented programming assists this by facilitating an agile design build process, even if you don’t have a fully vetted out design. Because the characteristics of OOP software make data flow consistent, creating and vetting a design is fast and simple.

7. Reduce time to commission and troubleshoot
Once you have your first instance integrated and tested against the monitoring system, you don’t have to worry about a full test on any of the other instances. It’s already been proven. Because of the cookie-cutter design, every other device should function the same way. A simple spot check of points should take care of the rest of commissioning new devices.

This means every time you use new equipment brands (say, a meter), all you have to do is create a new instance within the main template. If that meter has the same functionality and attributes as the old one, all that’s left is to customize the device registers. Congrats! You’ve cut your time by more than half.

System consistency makes troubleshooting problems much easier. Because nearly everything is the same, if there ever is an issue, more often than not, you will find either a device problem, network problem, or incorrect coding in device modification.

If it’s necessary to make changes during commissioning, object oriented design principles allow for quick modifications that blast out to each instance and all following instances, significantly decreasing commissioning interruption and ensuring the same issue isn’t seen in any future integration of these types of devices.


Michael Kalkas was an Application Engineer at Affinity Energy from 2012-2017, with responsibility for developing, deploying, and maintaining integrated SCADA (Supervisory Control and Data Acquisition) systems. Some of his daily responsibilities were automated process software design, hardware footprint bolstering, system functionality testing, and system monitoring.

With over 25 years of electrical engineering experience, Michael previously worked for GE Appliance and Lighting, Manpower Inc., and the U.S. Army. Prior to joining Affinity Energy, Michael spent 11 years at Cooper Lighting as a Senior Lab Technician, where he performed photometric testing/UL testing against various fixture designs and lamp sources, maintained a UL Lab Testing SCADA system, and developed custom tools and databases for data manipulation and filtering.

Michael received a B.S. in Computer Science from South University, AAS in Electrical Engineering Technology from Blue Ridge Community College and is licensed as a Microsoft Certified Professional and Microsoft Technology Associate.