Client Portal

Computrols Webinar: CSI – I/NET Integration


Webinar transcript

[00:00:15.270] – Scott Holstein

Hi everybody Scott Holstein here with Computrols, welcome to our I/NET integration webinar.


For those of you who are familiar with I/NET, you know that I/NET has been around a very long time and most people have a very high opinion of their hardware and how their system works. There’s a reason why these obsolete systems essentially are still around today and people are still trying to maintain them. But today we’re going to talk about the I/NET infrastructure and some of the challenges of maintaining these systems now and then go into what Computrols does in terms of integration.


And as you all are familiar with, Computrols is primarily known for our integration solutions, along with our lifetime warranty hardware. But before we get into it today, we’ll first talk about some housekeeping items.


For those of you on the webinar today, we will ask that everybody keep your microphone on mute, keeps your camera off. We are planning on this, taking about 20 to 30 minutes. You can certainly ask questions as the presentation goes along. And we’ll answer everything we can as we go, if it’s appropriate. If not, we’ll address as many questions as possible at the end as well. There will be a recording of this webinar that will be sent out afterwards.


For those of you who do stick around to the end, we will send you the slide deck as well. But again, I tell you, if you have questions, use our chat bubble that you see on your Zoom screen there and you can address those questions either to the group or to one of the Computrols users.


So a little bit of Computrols history before getting into this. I think it might help you all understand where we come from in terms of integration. Computrols started off in 1983 as a service company servicing third party building automation systems. Our founders really saw an opportunity within the industry to write a lot of the wrongs that they had seen over the years. One of those things was really making the front end very simple to use and making that front end software so that facility managers go in and operate the systems as opposed to having to be completely dependent on whoever their service partner is.


So at that point in the late 80s, early 90s, Computrols released the first version of Computrols building automation software and began integrating to these third-party systems. At that point, wanted to solve another another wrong in the industry, which was planned obsolescence every 5 to 10 years. The majority of manufacturers are obsolete products and telling their customers it’s time to upgrade or we can’t support you anymore. So at that point, Computrols started manufacturing our very own line of hardware, creating a turnkey solution for our customers.


And since that time, we’ve provided the only lifetime warranty and building automation industry. So we started off with HVAC controls and that’s really still what we’re known best for today. But since that time, we’ve added on lighting control, access control, and fire alarm systems to our offerings. A little bit about Computrols, and this is something that if you’re familiar with us, you know why we do what we do. We believe in empowering our customers and partners to manage their own building automation systems, to give them all of the tools they want.


Now, certainly we have the ability to support from a service perspective. However, we want to empower our customers and we do that through lifetime warranty on our controllers, no planned obsolescence. So that’s a part of our lifetime warranty, is we’re not going to tell you one day that, look, this software doesn’t work with this hardware or you have to upgrade to this, this that or the other, we built backward and forward compatibility in our products for the last 30 years.


And then, like I mentioned before, we built a software system with the end-user in mind. We want our customers and partners to be able to operate that system independently. If they so choose what we’re going to be talking about today, unique integration solutions. Mike is going to get into great detail about our CSI I/NET integration. However, Computrols is known for our integration solutions to a variety of third-party manufacturers. So in addition to that, we also provide free remote tech support as a means of supporting our customers who want to operate their own systems.


We do provide free, remote tech support. We’re able to resolve probably 90 percent of issues. If we can’t, we’ll go out and have a local technician troubleshoot from there.


I just want to quickly introduce our host for today. Mike Clayton is Computrols Manager of Strategic Partnerships. Mike has been with the company for about twenty years now and has filled a lot of different roles. He helps me out on the sales and marketing side. Mike primarily works with our distribution partner network and Mike even goes out in the field. You’ll see Mike helping out the R&D team. He is really a jack of all trades when it comes to building automation.


Mike was also instrumental in developing this integration you’re going to see today. So he was a part of building the technology that you’re going to get to see a little bit of right now, so with that said, I’ll hand it over to you, Mike.

[00:05:24.540] – Mike Clayton

Thank you for your time today, everyone. What you’re seeing here is the LX Controller, this is our flagship D.D.C. controller, our bread and butter, so to speak, universal-style controller. And this is key to the integration process, because while we will leverage the power of the LX to perform integrations with third-party hardware, it’s certainly very capable of standing in and replacing any failed hardware.


So that’s kind of a unique twist to what we do, is that we’re not just an integration solution. We are a fully capable platform that can replace any of those failed components. So really gives the owner a nice, comfortable pathway forward in terms of how do we move from some old legacy hardware in a controlled manner to a new platform that has a lifetime warranty and the support that we offer and not wait till things fail and have to do these things, you know, on an emergency basis.


So the LX is key to that, as you can see, comes in for sizes. The only difference between those is the I/O count 8, 16, 32 and 64 points. And any one of those controllers can act as an integration piece to the I/NET, meaning they all have the same memory, same speed, etc.


Rounding out that line, we also have a lineup of VAV and Unitary controllers. These are available with or without the pressure pick-up, Belimo Motors five year warranty from them on a motor, the electronics under the hood, lifetime warranty from us. So again, we’ve got you covered from the parent level stuff all the way down to the sub LAN control as we have a full replacement for every one of those and could certainly replace failed hardware on the I/NET side.


So how do we leverage the LX for I/NET integration? I will show you some details of that architecture here in a moment. But just want to highlight a couple of additional things on the LX, as Scott touched on earlier, very user-friendly, user-centric approach to product design, putting things like data sheets to the product right on the front of the board, not making you have to go navigate a website to reach and find that data.


All of the I/O, as we mentioned, 4-in-1 analog input or output, digital input or output, software configurable. So there’s no jumpers or DIP switches in the field. Makes it very easy to apply this product. Just count up the I/O of what you’re trying to replace and size the controller accordingly. So at the top, the two RS45 ports allows us to host any combination of third party protocols. So while I may use one of the channels to accomplish the CSI I/NET integration, that still leaves me with a secondary port that I can use for Modbus power meters or BACnet lighting control or anything like that.


All of our boards are IP based, the LX is currently going through the BTL BACnet testing laboratory process that will have that listing here shortly.


You can accommodate that protocol as well at the IP level. And any IP based protocols naturally come directly from the front end. No additional gateways or adapters needed. The LX is also capable of doing wireless communications and Bluetooth for various sensory systems and things like that. So let’s talk about INET. Control Systems International was the original start of this, was eventually bought by T.A.C. and then Schneider Electric, the hardware that I’m going to show you, dates to the early 90s.


It’s fairly robust. Still out there, still working, has a couple of weaknesses that we’ll touch on. When you start looking at the software you might see I/NET 2000 or later I/NET 7. Doesn’t matter either one of these we can work with. It’s good to note that I.T. departments are actually driving some of these upgrade paths right now. That software is quite old, doesn’t run on on modern windows. So you’ll find old PCs that I.T. departments are just absolutely refusing to host on our network. So that’s a driver for integration in some cases. There’s also a handy pocket reference guide will include in the link when we send out, it’s got some good information about the CSI products and architecture and things like that kind of goes over some of the things we’re talking about today.


So the architecture of an I/NET system’s shown here. You have a PC running into that I/NET 2000 or I/NET 7. The controller LAN is what they call a high-speed LAN. PCUs and DCUs are the controller types and they’re typically found in the 7700 series meaning 7716, 7793, etc.


As I mentioned, they’re pretty robust, but they do have a volatile storage in that they have a battery on them that fails. And the symptom of this is that the controller run, find the building to lose power and then it comes back and you can’t communicate with the controller because it lost part of its firmware. So you’ll see guys with creative workarounds, you know, UPSs plugged into a control cabin and things like that. Underneath they have what’s called a sub LAN.


This is where your VAV controllers or, MR’s, which would be Micro Regulators. Those hang underneath, for example, a 7793 as shown here. The controller databases are represented in what we call SAV files. And those asterisks refer to the actual address of the controller. Those are key. We want to grab those if we can, if not no biggie. But really, we can leverage those to speed up the process of integration by importing those proprietary files and pulling relevant data out of them.


And you’ll find those on the CSI workstation in the I/NET folder. The PC can talk to the controller LAN via a couple of different methods. One is direct to a PCU or a DCU  via a serial cable. There might also be a network tap or which is a serial to twisted pair converter shown here on the bottom right or net plus router, which is an IP device. But all of these perform the same function. They allow the I/NET software to talk to a controller LAN.


So another note about that control LAN is that its high speed, but it’s not RS45 based. It’s a proprietary signal. This is where our ability to create or to design and create and manufacture hardware comes into play because we’re able to create an adapter to convert that signal from that high-speed proprietary signal into straight 45 so we can communicate with it. And we’re the only integrator currently that does that. As I mentioned, the 7700 series are shown here.


The 7793 which is in the middle would be the host for the VAV controllers and it can hold two channels of that. So you’ll often find one of those on every other floor. And you can see the giveaway on that is the bright orange blocks on the bottom right for the communication path. 7798 is basically a similar to ninety-three and that it can host VAVs, but it has a little keypad on it.


You’ll see that in some smaller places, possibly in lieu of a front end. What it’s important to note that the benefit of our integration, we’ll show that in a moment. Sitting on a high-speed LAN is where you want to be because we want the performance to be as least as good as what they had beforehand. Here you can see a CSI VAV controller are similar to an old Invensys controller. You can see an example wall sensor and the MR or Micro Regulator, as I mentioned, these are straight 45 based. They do communicate off of the parent LAN, which is typically how we’ll pick them up. And I’ll show you that in a graphic coming up.


So how do we integrate? As you can see here, everything remains our can remain on the I/NET side, we don’t have to remove any of the parent level controllers or anything like that. What you have is an LX and that adapter that we designed and manufactured that allows us to sit on the high-speed LAN. This gives you several benefits over competing solutions. Tridium and some others will actually integrate through the serial port, meaning its point limited. You can only pick up a few hundred points at a time.


And it’s also speed limited because by nature of a serial connection, it’s going to be slow. Because we can sit on that high speed LAN, there’s no limit to the point counts. You can accomplish about a thousand points per LX. So if you need additional points, you just add another LX.


Existing I/NET workstations, if the customer wants to keep them, can remain. We can exist right alongside of those. And this is good for those places that maybe are a little apprehensive or want to see a proof of concept. You can run our system in parallel with that I/NET front end and switch back and forth as you need.


As I mentioned, you can actually expose those I/NET points via BACnet IP at that LX Controller level. So you would CBAS to perform the integration and you can still share that via BACnet.


Those SAV files that I mentioned allow you to very quickly import thousands of points with just one click. So you’re not having to do a bunch of manual data entry, the process of integration could really go quite quickly and smoothly by leveraging those proprietary files. Our per-channel licensing module allows you to do a single controller LAN or multiple controller LANs if it’s a large enterprise-level facility. So you have some flexibility there and how you can approach those projects.


And also the sub LAN controllers and VAV controllers, as you can see here, they’re actually picked up by us integrating to that 7793. So we would pick up all sub LAN controllers by jumping on that controller LAN and grabbing everybody that’s underneath it.


So here’s a quick look at the CSI SAV Importer. And this is important to note, not just with I/NET, but any other protocols that we do. Whenever possible, we leverage that existing infrastructure and existing database files to try to speed up the process of integration.


Last thing we want to do and the last thing you want to do is sit there and do thousands of points of manual data entry. When we do the import, we even go the extra mile. We’ll pull in point names, point units of measure degree Fahrenheit, percent open, et cetera, and also alarm parameters. So if the existing system has alarms set, we can import those as well. All that will smoothly migrate into CBAS with just a few clicks and then you can, of course, selectively import just the ones you want.


For example, if I don’t need 30 of the VAV points, I just want three or four. I can speed up performance by just pulling just the points I want to present to the customer.


CSI I/NET has a special couple of features, such as you can put points in manual or test for override. They can indicate an old status that they haven’t updated. That functionality has been replicated in CBAS. You can see here there’s a special CSI, button when you do CSI integrations and when clicked it actually pulls up that other screen below where you can actually see those current statuses, you can also release those or put them in manually or test from CBAS.


So if an operator at an I/network station put something in manual, you’ll see it go to Yes in CBAS and you can also release it or send it back the other way. So again, it’s not just some polling up points and the ability to send commands. It’s a really tight, smooth, comprehensive integration that has a lot of extra bells and whistles built-in on top of it.


If you’re not familiar, CBAS features plain English logic programming. We actually prefer using point names, not variables or block programming, things like that.


One advantage of this is that it allows us to seamlessly stitch together points and programming and sequencing from a variety of protocols. And all the protocols we support get natively included in CBAS and able to be used as any part of a logic statement. So when you’re doing things like programming overlays, you can actually reference the point names and average points across all these different protocols or command points across those protocols. And the CBAS software will handle moving of the zeros and ones around behind the scenes, making sure that it’s a smooth process for you.


As I mentioned, or as I want to point out, all points of programming live in that LX that’s in the field, not in the front-end PC. So if the computer goes off all of your programming, any logic overlays, any schedule overlays, all of those are going to happen and function just fine. So it’s a very robust solution. Doesn’t require a PC to be running to execute that sort of program.


While we’re touching on a product line, we have additional solutions that can also be leveraged as well for fire and life safety card access, we have a wireless ecosystem that we’re just pulling out of beta right now, a cloud analytics platform.


All these, again, because they’re part of CBAS can be natively integrated along with that INET. For example, CSI has a line of access controllers. If you come across one of those jobs, we can actually pull the card information into seabass from the I/NET system, user’s, card numbers, areas, things like that. So that integration doesn’t just stop at HVAC.


And speaking of other protocols here’s a quick list of some of the variety of protocols we support, and as we’ve touched on today, our ability to create hardware can be leveraged as well. The CSI I/NET adapter we formed, we created a similar one for Staefa integration. The ability to import SAV files, we do that with Johnson Controls. You can import PRN or DMO files from from Metasys. With Siemens, we can run hardware trees and parse that information and enter it into CBAS as well.


So the take away from this is whenever possible. We go the extra mile to build out a toolset to speed up the process of integration. Also, if you’re looking to do integration, you’re not familiar with that product line. We have the expertise on staff to help guide you. So if it’s one of these and you want more information about it. Or if you have something that isn’t mentioned here, your Computrols rep is happy to help guide you through that process of what our capabilities are and show you the pathway forward.


So with that, that was a quick tour of our I/NET integration capabilities.

[00:19:34.060] – Scott Holstein

Appreciate everybody making time for this today and have a great day.

More to explore