It’s a phrase heard often around the S4 offices: “Investigate Before You Integrate”. We like to think of it as the “Check yourself before you wreck yourself” of the integration world. Most of the support calls we receive can be resolved by one of the following three simple measures:
Here is an excerpt from a support call that we will never forget. The integrator started out doing all the right things: they took an inventory of existing equipment, they validated the field bus, and they made sure that all of the field devices were working. Everything tested perfectly when the project was started. This project looked like it was going to be a poster child success story. Then, the project was disrupted when Hurricane Sandy flooded the building. Upon resuming the integration process, the integrator reported that nothing was working reliably on three of the integrations. All of the others were doing fine. Our advice was to go back to basics and validate the bus again. The results were some of the most compromised field buses any of our partners have ever encountered, along with field devices that were not operable. We all overlooked the fact that the building went through a catastrophic event and anything that was true before the event would be subject to change. The necessary repairs were made and the project is now on its way to being the success story that we originally anticipated.
Those of you who know The S4 Group have probably noticed that I didn’t mention an integrator name, product name, or the field bus technology. That’s because the advice to Investigate Before You Integrate is a universal best practice. This is one of the main themes in our live demo / training sessions and in our Integration Boot Camps. Doing the right up front planning, documenting current conditions, and validation testing of the field bus and controllers all enable you to eliminate risks and mitigate problems in the most cost effective way possible.
Why am I concerned about this seemingly ancient technology in this age of wireless technology and Cloud-based systems? Because it’s relevant, and you can’t control what you can’t measure - no matter what generation technology you are working with. We are seeing more and more requests for our S4 Open: BACnet-N2 Router to act as an on-site agent for both local and cloud-based value added applications.
There is no difference in the technology that we deliver. The difference is that in the “agent” scenario the integrator wants to co-exist with the existing Metasys® supervisory controller and OWS for an extended period of time without changing the way the Metasys® system works. This puts a significantly heavier load on the legacy N2 bus: any pre-existing problems are going to bubble up when the system is stressed harder than ever before. If you’re building upon a legacy framework, you can’t ignore it.
Every successful integration starts the same way, say it with us now: “Investigate before you integrate!” Before starting the integration, you must:
Laying this groundwork means you understand the legacy environment that you are going to integrate into and you are ready to start the actual integration process. There is always risk involved in integrations, however, now you are approaching the integration process in a way that means you understand the weaknesses of the legacy system, you know the expected results, and you are ready to move forward, armed with the information you need to control and mitigate that risk. Your integration will proceed predictably and cost effectively, resulting in the highest value possible, whether you are doing a more traditional migration of a building to new technology or introducing new services and capabilities via the latest cloud based services.