This question was originally posted on DCIM Support by Vineet K. Sarin on 2016-01-05
Many a times we have come across requirements where client wants to get rid of a typical BMS system for their data center and replace it with a Struxureware system or bridge existing BMS with Struxureware system. As per our discussions in similar cases clients are okay with only monitoring as long as they were able to poll infrastructure devices irrespective of protocol onto one common interface. The integration list at such sites may look as follows:
UPS devices : Modbus
Energy Meters : Modbus
Diesel Generator Panel : Modbus
All other devices given below were available to us over BACNET over IP accessible through Honeywell 600 controller.
The devices we integrated through this controller are as follows:
Honeywell T/H sensors mounted on Racks
CRAC units and TRIP panel breakers
Fire Alarm Panel
Access Control system
We were able to use the power of Automation Server to convert BACNET over IP data to Modbus TCP and integrated it back to DCE easily. In case any of your project requires help for such an integration feel free to reach us any time..
Few IO points summary snapshots have been attached below:
As an extension to the same we have also created PUE and DCie inside Struxureware Dce for regular trending and reporting. See snapshot below:
So finally after a lot of testing I would like to add another component to this discussion which is Temperature and Humidity sensors polled in from Third party devices like Honeywell sensors for that matter into DCE via Automation server over Modbus TCP channel. A key issue rightly pointed out by Ed Tarento below is asking for Integration of these sensors into DCO. So what really happens if you don't do that?
We tested this and found out that a normal Temperature Mapping for a Modbus DDF may have the following coding :
If you the Label here we are setting a Temperature sensor, now it works fine in DCE but the moment you try to view this in DCO , you can see the sensor through External device integration but you will not be able to map the same onto a rack and see that sensor mapped as a Temperature sensor icon. So when you drag ito to a Rack in DCO there will be greyed Rack meaning that association has been done but no Temperature sensor icon. The problem that it creates for you is you cannot now draw 2D or 3D maps with this information.
So what is the solution to this problem?
The answer has been set in a similar trail enclosed below:
First see the Detailed information here:http://sxwhelpcenter.ecostruxureit.com/display/public/DCIMDEVELOPER/DCE+Sensor+Mapping+to+DCO
As I'm writing this we are experimenting another custom DDF coding where we are using a different value for <sensorSet> which is Temperature Sensors in place of Temperature. Now how will this react to live site condition is still questionable since at one site using this has got the Temperature sensors becomes visible inside DCO as well like our very own Netbotz t/h sensors but same coding at another site is not responding the same way..
So finally we got the answers to this. The issue is DCO understands data from DCE sensors with a specific ID and typeset and especially if the DDF is created as a Typeset Generic for third party Temperature sensors it refuses to work inside DCO. So the correct way is to change the Device Type in the DDF header to cooling device and falls in place. So now we can map any Third Party Temperature sensor into DCE and then poll into DCO and also perform 3D Modelling and Thermal mapping wit the same.
See snapshot below:
But then what other areas have to be factored for these integrations:
a. All alarms and all devices pulled over Automation server will require one coding module inside DDF, which means at least 15-20 lines of code per Device Input Register Value and for every Coil status values around similar line count of coding inside DDF.
So work load for the DDF development team , for a site which has 36 energy meters with each meter having 15 register values to be shown inside DCE will be at least 225 lines of coding per Energy meter.
b. All devices pulled inside DCE using a single DDF will be visible under one AS device and all properties for all devices will show under one device, which means you cannot see it like a drop down list like a parent -child device hierarchy.
c. All devices pulled inside DCE if they require to be a separate device inside DCE would need a separate DDF creation.
d. Each DDF created inside DCE for polling a device will consume One Node Device License from DCE.
e. Moreover the polling of Modbus device register happens so fast that one has to create a longer poll cycle for these devices since you may see very frequent change in status of devices across a millisecond polling or even for that matter 30 second polling, we have experimented with a minute which seems to be just fine with many clients but again not a rule.
f. For Struxureware DCE web client display of these Modbus devices one has to ensure to get hard coded values for Device Type, location etc created inside the DDF. This helps in pulling the values as is in the SXW DCE thin client view or else client will go crazy with IP address identifiers which do not make sense at all.
So what is the final take on this integration. We have implemented this at many sites and in the end we have always moved the client to opt for either PME or SBO. This is more because no matter what we do in SXW DCE for Building side integration it can never do millisecond polling of building side devices , which most of the time is required like for breaker trip issues etc. So best bet is certainly to have PME and SBO in place.
In case any custom reporting is required we can always do through DCE or SBO any time.
This comment was originally posted on DCIM Support by AHMAD on 2016-01-10
Hi Vaneet, I have a BMS (Niagara Ax) Bacnet IP only , we need to integrate it with DCE , Do you have solution for this case ? Thanks, Ibech
This comment was originally posted on DCIM Support by Vineet K. Sarin on 2016-01-11
Hi Ahmad, Yes we have done integration with Honeywell WEB 600 controller using BACNET over IP. The polling device used to poll BACNET ver IP from Honeywell devices is SE Automain server. Within Automation server you ca map BACNET discovered devices into MODBUS Register Map which can be easily pulled into SXW DCE using custom DDF.
This comment was originally posted on DCIM Support by Vineet K. Sarin on 2016-01-11
All BACNET devices which you seeing above are pulled throug Honeywell controller over Bacnet ip.
This comment was originally posted on DCIM Support by AHMAD on 2016-01-13
Hi Vineet, Thank you for your reply... if you have user guide or steps, please can you provide me ? Best regards, Ibech
This comment was originally posted on DCIM Support by Ed Tarento on 2016-01-20
Just a foot note, if you also have DCO Capacity and want temp readings in the 2D and 3D views, specify this when you create your DCE DDF I hope that helps Cheers
This comment was originally posted on DCIM Support by Jorge Jimenez on 2016-01-21
One quesiton about this. What does Automation Server increase the price of DCE solution? In percentage... With this solution, if we change one register in Honeywell, Do we have to change DDF again?
This comment was originally posted on DCIM Support by Vineet K. Sarin on 2016-01-21
Hi Jorge, Any changes in Register will have an impact on DDF and that is the sacrifice one has to make. I remember we were working on a case where client had 35 Energy Meters polled via BACNET IP into AS converted to Modbus Register and then through customized DDF we pulled all of them into DCE. Now any small change that you want to do on any parameter means recreating those changes in DDF and reloading it again...
This comment was originally posted on DCIM Support by Winnie Chau on 2019-07-17
Just FYI - Thx Vineet K. Sarin, we are still getting help from your hints after 3 years!
Besides declaring the model as Cooling Device, the DDF definition of sensor type needs to follow DCO sensor mapping.
You will need try and error - I refer to inrow DDF to guess what actually works - because at least UNIT_TEMPERATURE and UNIT_HUMIDITY types are actually not working.
Daniel Kwong Fergus Wong ben lai Michael Lam
Discuss challenges in energy and automation with 30,000+ experts and peers.
Find answers in 10,000+ support articles to help solve your product and business challenges.
Find peer based solutions to your questions. Provide answers for fellow community members!