Subscribing is a smart move!
You can subscribe to this board after you log in or create your free account.
Invite a Co-worker
Send a co-worker an invite to the portal.Just enter their email address and we'll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel
Link copied. Please paste this link to share this article on your social media post.
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
VESDA Panels
Fire Alarm Panel
SMOKE Sensors
Access Control system
PA 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
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.
Link copied. Please paste this link to share this article on your social media post.
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.
https://sxwhelpcenter.ecostruxureit.com/display/public/DCIMDEVELOPER/DCE+Sensor+Mapping+to+DCO
Daniel Kwong Fergus Wong ben lai Michael Lam
Link copied. Please paste this link to share this article on your social media post.
This question is closed for comments. You're welcome to start a new topic if you have further comments on this issue.
Create your free account or log in to subscribe to the board - and gain access to more than 10,000+ support articles along with insights from experts and peers.