Tridium R2 to AX questions

[SoCalHVAC]

I have some questions about migrating from Tridium R2 to AX.

Some background on this project: This is a school district. The first school was renovated about 8 years ago with Johnson Controls (PMI). The next school was renovated about 5 years ago with Invensys DMS with Network 8000 (I think).

About 2 years ago they were sold an upgrade/integration from Network 8000 to Invensys UNC's (R2) and the JCI NCM (at school #1) was replaced with 2 JCI N-30's and an Invensys UNC so the JCI side could be integrated to the R2 side via BACnet. The upgrade consisted of 3 UNC's 2 N30's and a Web Supervisor plus all of the graphics.

Now the school district is building a brand new school with the intention of building another one in the next two years.

The question is, should the new schools be installed with R2, or AX. I'm inclined to say AX, so the N-30's could be swapped with FX-40 for a much less cumbersome integration to JCI, plus it seems a waste to install R2 in the new schools if AX is available.

Can R2 be integrated to AX? Is there a DMS driver available for AX to allow that part of the integration? Would it be possible to utilize at least the existing Web Supervisor?

Sorry for the long winded post. Any input is much appreciated.

[gnomethang]

As I understand it there is no out of the box interoperability between R2 and AX.
If you require data transfer between the two you have two options:

1) OBIX. Requires a License in each device (I believe that the R2 is in Beta testing but just about OK). I have played at a superficial level with OBIX in AX and it really is quite straightforward for basic data transfer. Caveat - I have only scratched the surface.

2) BACnet - Requires a Bacnet license for each device and then you can export each data point with a foreign device no. and away you go.

There would be a fair bit of engineering to achieve this if you want full data transfer/interoperability.
I guess we need to consider the shelf life of R2 support etc.

No Idea on DMS I'm afraid

Hope these musings help.

Barry

[SoCalHVAC]

Thanks for your input. I think I've seen OBIX talked about on this forum before. It's worth looking into. The owner is understandably worried about how long R2 will be supported, especially as it relates to this new construction.

He would like to know if he should replace what he currently has with AX, and subsequently anything new would then be AX. I guess he doesn't want to be told in 1 or 2 years that he needs to upgrade, and then have to upgrade two more schools then he currently has.

I think at this point I need to know if anyone is aware of a DMS driver for AX. If there is, then that's probably what we'll do.

[tshort]

Check out this website it may have what you need.

http://www.csicubed.com/csi3_gcm1.html

[SoCalHVAC]

Check out this website it may have what you need.

http://www.csicubed.com/csi3_gcm1.html

Thanks for the link. It looks like that driver only works if the Network 8000 GCM was still in place. That is long gone, replaced by UNC.

BACnet is still an option, I've just never been a big fan. Mostly because I haven't done a lot of it.

[davem]

Although there's not an incredible amount of BACnet love on this forum, you'll find that your case, it makes for the most straightforward r2-to-AX integration, until the oBIX driver comes of age.
I've just completed a UNC-to-AX BACnet Supervisor integration - while the tedious part is on the r2 side, it works great. A couple things to be aware of:
Because the DMS driver creates points that do not have the "foreign address" field, you cannot export a DMS point straight out as a BACnet point. For every DMS point that you want to read/write, you'll need a corresponding Tridium object, which you then address with a unique BACnet instance number (the "foreign address" field). The UNC, being an r2 device, has no automated means of generating the BACnet instance numbers, so even if you copy/paste a whole set of objects for a given type of controller (a common practice for the school environment you're integrating - lots of the same controller over and over), you'll still need to go into the config tab of each Tridium object and give it a foreign address. Tedious, but with the right routine, it moves quickly. You can get several hundred points built, addressed, and linked into the DMS points in a typical workday.

However, now you've created the need for the right type of AX Supervisor - you'll need the AX Supervisor BACnet/IP driver, plus as many 500-point blocks as required.

The pricing structure for a BACnet r2-to-AX integration looks to be about the same as an integration done using oBIX, yet the oBIX driver appears to come for free on the AX Supervisor side, as long as you're connecting only to Niagara (even r2, I'd imagine) devices. Another thing to watch for: the UNC will need to be at build 2.301.522 to be able to load the oBIX driver onto it. There may be some work involved there (if you can do it at all - it will likely require the Invensys guys to upgrade the UNC - more chefs in the kitchen...)
And do you have a workstation at the owner's site to be able to load software onto that UNC? It doesn't sound as though you provided the UNC, so your orgID won't allow you to connect and install software; the onsite Web Sup should suffice.

No new/upgraded software required on the UNC side, however, if you go with the BACnet integration.

[SoCalHVAC]

Although there's not an incredible amount of BACnet love on this forum, you'll find that your case, it makes for the most straightforward r2-to-AX integration, until the oBIX driver comes of age.
I've just completed a UNC-to-AX BACnet Supervisor integration - while the tedious part is on the r2 side, it works great. A couple things to be aware of:
Because the DMS driver creates points that do not have the "foreign address" field, you cannot export a DMS point straight out as a BACnet point. For every DMS point that you want to read/write, you'll need a corresponding Tridium object, which you then address with a unique BACnet instance number (the "foreign address" field). The UNC, being an r2 device, has no automated means of generating the BACnet instance numbers, so even if you copy/paste a whole set of objects for a given type of controller (a common practice for the school environment you're integrating - lots of the same controller over and over), you'll still need to go into the config tab of each Tridium object and give it a foreign address. Tedious, but with the right routine, it moves quickly. You can get several hundred points built, addressed, and linked into the DMS points in a typical workday.

However, now you've created the need for the right type of AX Supervisor - you'll need the AX Supervisor BACnet/IP driver, plus as many 500-point blocks as required.

The pricing structure for a BACnet r2-to-AX integration looks to be about the same as an integration done using oBIX, yet the oBIX driver appears to come for free on the AX Supervisor side, as long as you're connecting only to Niagara (even r2, I'd imagine) devices. Another thing to watch for: the UNC will need to be at build 2.301.522 to be able to load the oBIX driver onto it. There may be some work involved there (if you can do it at all - it will likely require the Invensys guys to upgrade the UNC - more chefs in the kitchen...)
And do you have a workstation at the owner's site to be able to load software onto that UNC? It doesn't sound as though you provided the UNC, so your orgID won't allow you to connect and install software; the onsite Web Sup should suffice.

No new/upgraded software required on the UNC side, however, if you go with the BACnet integration.

Great info, thanks. I worked for the Invensys rep that did the original install, and am very familiar with the site. I also already upgraded the entire site to 522. It sounds like maybe BACnet is the way to go, at least for the UNC doing the DMS system. The owner would probably be much happier upgrading the rest to AX Jaces.

I'm just now learning how to price things accordingly, so thanks for your input on time. I'm on my own now, so pricing has been quite interesting. I always seem to price myself too low.

[tlp261]

If I were the owner I would certainly not install any more R2, but I doubt I could handle the replacement of it with AX, considering the re-engineering needed. For now I'd integrate the R2 to AX and not replace the R2 Jaces until I had to.

[leaflying]

If I were the owner I would not integrate existing R2 to new AX frontend, just add a few links on Ax pointing to existing R2 web pages, and make new AX graphics as close as R2 graphics. I will only integrate some "global points" for global functions.