Best Practices for Integrating RMU Data with PCS - Virtual Brew 06/26/25

This Virtual Brew discussed practical strategies for integrating Remote Monitoring Unit (RMU) data into PCS—accurately, efficiently, and with fewer headaches.

✅ Ensure timely, reliable data transfers

✅ Streamline your integration process

✅ Avoid common pitfalls and errors

Speakers

David Gautier, Product Manager

Transcript

Introduction

David Gautier
Good morning, everyone. Welcome to Virtual Brew by American Innovations. If you’re just getting settled in, welcome — thanks for joining us this morning. My name is David Gautier. I’m a product manager, and I primarily look after our PCS platform as well as Survey Manager, and a lot of the points where our applications either integrate with each other or integrate with other applications.

So today we’re going to talk about that topic specifically — around integrating remote monitor data. We’re going to walk through things — I like to think about things from a mental model perspective, so we’re going to follow the steps you should take. The initial steps, as far as aligning a remote monitor to a facility in PCS — what does that mean, how do you do it? How do you align the channels in that monitor to fields in PCS? What does the import look like, what’s required, where do you need to make some decisions?

Then we’ll focus a bit on repeatability — how to automate your bridges and ensure you’re getting the right records in each month or each day, however often. At the very end, we’ll talk about one of the places where we see problems — around unit swaps. It’s very common for misalignments to happen there.

So, without further ado, let’s talk about linking remote monitors to facilities.

Linking Remote Monitors to PCS Facilities

I’ll start by talking about PCS in general, to get everyone up to speed. PCS has what we think of as a facility-centric view of the world — the places you’re required to visit: the test points, the rectifiers, the bonds, those places you’re going to on an ongoing basis, either annually, monthly, or bimonthly. We call those facilities in PCS.

Because PCS is a database, it really does not like to have duplicates — duplicates are a big problem with databases; they make it really hard to query your data, run reports, find what you’re looking for. So we have IDs on the back end that help with that from a technical perspective, which we’re not really going to talk about. But for folks using PCS, we have what we call intel key fields — you can see them in the screenshot in the top right corner: row code, mile post, and facility ID. That’s a screenshot of the data grid from PCS, and those column headers are bolded to indicate they’re intel key fields.

What the intel key fields do is combine to make something unique in the application. The standard way this happens is through test points, foreign bonds, or galvanic anodes — it’s a combination of the row code or segment code (what pipeline you’re associated with) and where along that pipeline you are — your mile post. The combination of those two things, along with the facility type, makes a facility unique. If you’re familiar with adding data to PCS, you might see a window appear that says, “Hey, you’re making a duplicate facility — are you sure you want to do that?”

The same idea applies to rectifiers, but rectifiers are a little different, because they’re what we’d describe as a many-to-many relationship — they can influence the potentials of multiple pipelines, either directly through negatives, through electrically continuous pipeline segments, or even through bonds. Because of that many-to-many relationship, we also require a facility ID for rectifiers — that’s why it’s bolded on the screenshot.

So, a facility ID — what it really is, is just a description that allows you to describe where a particular facility lives. The focus isn’t on the rectifier’s make and model, which may change over time, and it’s not the RMU itself — it’s the geographic location where that rectifier lives, and then you’re attaching a remote monitor to that.

The reason I’m giving all this context is because, in order to link a remote monitor to a PCS facility, what you’re going to do is make sure the facility ID in PCS matches your facility ID on your remote monitoring website. It’s as simple as that — once those two are linked, we know what facility we’re at.

There are some parameters and best practices around facility IDs. It’s an alphanumeric field, so it can have numbers and letters, and it has the capability of including some special characters, like hyphens, underscores, and plus signs — you can use those as well. The big thing is that it should be unique across all facility types — we’ll help in a lot of respects, we’ll tell you if you’re inputting a facility ID that’s not unique — but it’s really important, when you’re thinking about other facility types (rectifiers, test points, and bonds), that the facility IDs are unique across those types too. That comes into play when we talk about facility key bridging, which we’ll get to in a bit.

Facility IDs should also just be descriptive — they should describe the thing they’re attached to, generally, so it’s clear when you’re looking at one what it is. Actually, now that I’m looking at it — this is a terrible example. This facility ID is a serial number of the remote monitor, which really doesn’t tell me much — I’d have to rely on things like the location description to determine which facility it is. That’s so important, because when you’re mapping these together, it’s really helpful to have descriptions, so you can properly place the remote monitor with the right facility.

Mapping Channels to PCS Fields

Okay, so we have an understanding of how we’re associating remote monitors with PCS facilities through the facility ID. Now we have to understand the channels on those remote monitors — how do we associate those to PCS fields?

Channels aren’t smart — they’re not self-aware, they’re just capturing what they’re told, and they don’t really understand what they’re capturing. Sometimes it’s easy to label a channel, because remote monitors can be preconfigured — my channel one is always volts, my channel two is always amps, so I just need to make sure I’m wiring it up correctly when installing it, to make sure my volts are in channel one and amps are in channel two. But other times, remote monitors aren’t prescriptive about which channel is which — there could be cases where channel one is volts and channel two is amps, or the opposite. You can also have times where you blow a channel — it breaks down, and you have to switch to channel three or channel four.

In any case, PCS needs to understand what kind of measurement data the channel is reporting on. So how do we do that? With Bullhorns, we use something called the engineering unit — you can see that in the top right corner. We have default engineering units that already align with PCS — for volts, rectifier volts, it’s going to be DC volts, and that same label is applied to the corresponding field in PCS, Rectifier Output Volts Found. So when we’re pulling in the report from Bullhorn over the API, we recognize this measurement has the engineering unit DC volts that matches the engineering unit on this field, and now PCS knows exactly where that data should live.

That’s how we do it with Bullhorns. Now, if you’re importing other types of RMU data, you’re not going to use an engineering unit — you’re actually going to use an Excel spreadsheet, either a CSV or an XLS format. We’ll talk about the format we require in a bit.

The structure of that spreadsheet is really important — and specifically around your RMU channels, the most critical thing is that all of your volts readings are in the same column, and all of your amps readings are in the same column. Because, similar to how we map with engineering units, when you’re manually importing from a spreadsheet, we’re going to say, this column with my volts maps to my Rectifier Output Volts Found, and this one with my amps maps to Rectifier Output Current Found. That’s how PCS understands where those readings should live. So, in order to have all of your data in one go, you need to have all your volts in a single column — they can’t be split over multiple columns, because there’s a one-to-one relationship between a PCS field and a column in the Excel spreadsheet.

Either way — whether you’re doing it manually or using engineering units within Bullhorn — moral of the story, you need to label your channels, and you should be consistent about how they’re labeled, so it’s easy to integrate with PCS.

Verify Before You Bridge

Okay, we have an understanding of how to map an RMU to a facility, and how to map channels to PCS fields. Before we do anything else — always, always, always verify your alignment before you do any sort of bridge import. Think about it: over the last month, you swapped these two units out, or installed a new RMU — go through and double-check that they’re aligned before you generate any reports or run any bridges, because it’s so much easier to make changes ahead of time than after the fact.

If you’ve already imported the data to PCS and then realize it’s misaligned, you not only need to go back and clean up the systems so subsequent imports are correct, but you’re also going to have to go through and clean up the data in PCS, because it could be mapped to the wrong spot. And if we extrapolate that — a lot of times PCS is connected to other systems, so if I’m pushing data to GIS every single night and I don’t catch the problem, I now have bad data in GIS that I have to go clean up and figure out. The problem can expand really quickly. The solution is just to be diligent about making sure your alignment verification is done before any of the integration actually occurs.

Types of Bridges

Okay, shifting gears — let’s talk about the flavors of bridges we have. The way we import Bullhorn data is a little different than the way we import through the standard bridge with Excel spreadsheets. In PCS 2.5, we included a ton of enhancements around importing Bullhorn data to PCS over a new API — it’s too much detail to cover in this presentation, but definitely get in touch with your point of contact at AI, who can walk you through the enhancements.

Some of the high points, how we’re doing things today: we’re aligning things smartly. If your facility IDs match on both sides — Bullhorn and PCS — then we know which rectifier the RMU is associated with, and if your channels are labeled correctly, we also know where the measurements should go. If all of that is done ahead of time, we auto-map everything, and everything’s great. But we’re humans, and that doesn’t actually happen — so in cases where the facility IDs don’t match, we offer recommendations, like, “Hey, notice that the latitude and longitude on this remote monitor is really close to this rectifier you have on PCS — maybe they’re the same facility, do you want to map them?”

We also provide a single place for you to align the facilities on either side — the PCS facilities with the remote monitors — rather than having to switch between two systems to see a facility ID, copy and paste it, run a report to make sure you got it right. There’s potential for errors there — extra spaces, fat-fingering things. With PCS, you’re pointing and clicking, and your alignments are saved for posterity.

It’s fully automated on the Bullhorn bridge — because we understand the data on both sides, where it lives and where it should live, we’re able to make requests and pull data in a fully automated fashion. You don’t even have to think about it.
And the last thing is, we’re proactively identifying misalignment issues, to make it easy for you to correct. So if you had a remote monitor with facility ID “123,” and that was attached to a facility in PCS with facility ID “ABC,” we’re going to call that out and let you know — hey, these facility IDs don’t match, are you sure they should be linked together? It’s okay if they are, we’ll let you do it, but we’re going to call it out and make it easy to highlight those places where you might have problems.

The Standard Bridge (Excel)

Now, thinking about importing remote monitor data from the standard PCS bridge — you’re going to use a flat file in Excel. A flat file has a pretty rigid format: the first row has column headers, and the columns match to PCS fields, so my first row identifies the name of the column and what field it should map to. Below that, you’ll have rows and rows of data, with no gaps.

We know we have to have our measurements in the same column — volts and amps all need to be grouped in the same column. The other things you need are your facility ID, so we know which facility it’s associated to, and inspection date and time. You can add other things if you want — a lot of times, when we import data with the Bullhorn bridge, we include something in Inspection Remarks that says, “this reading came from a Bullhorn,” just to make it easier in reports to know which readings were captured manually versus imported from a remote monitor.

So the format is really important — fortunately, you can use the same format over and over again, and that’s how you build the automation piece on the standard bridge side of things.

As far as aligning the data, it’s kind of manual — there are some things that will help you, though. For example, using facility key bridging — facility key bridges are a special kind of manual bridge that let you validate based only on facility IDs, so you don’t have to have the pipeline and mile post information; it just says, if my facility IDs match, I’m good to go. We also have a bridge preview that will highlight, in a nice color-coded way, places where your facility IDs don’t match, or where you have readings that are out of range — but then you still have to go through and manually clean those up in the other system and rerun your exports.
And because we’re talking about reports, files that are created — they’re snapshots in time. The files have to be moved to a place where PCS can access them, which is typically behind your firewalls, managed by your IT. There’s a manual nature to getting the report data where it needs to be, to really get full automation.

Choosing Which Records to Include

Okay, we have an idea of which bridge you’re going to use — if you’re using Bullhorns, you’re going to use the Bullhorn API; if you’re using other RMUs, or you just prefer Excel, you’re welcome to use the standard bridge. Now we have to think, from the remote monitoring side, which records you want to include in your report.

Really, you can boil this down to a couple of use cases. The thing to focus on is how often you need the readings. Most of the time, when we’re reporting data on rectifiers, you’re looking for compliance readings — either monthly or bimonthly, depending on your O&M — if you assess monthly, then it’s monthly. You don’t want every reading from that month, because it’s just noisy — typically, you’re going to get the latest good reading from that month, and that’s all you want to include in the import.

Now, if you’re doing a separate use case — for example, an AC current density study — you probably don’t just want the one reading, because it’s not going to give you all the information you need to understand how your AC is influenced throughout the day or week, or however long you’re doing the study for. You probably want all of the readings, all of the measurement readings. Those would be two separate reports, or two separate extracts, with two separate bridges run in PCS — it’s important to think about that ahead of time, so you know you need to build these reports on the remote monitoring side to import to PCS.
Automation

So we have an understanding of how to generate reports for remote monitors and why you would do that. Let’s talk about automation really quickly. First things first — with the Bullhorn API, you can fully automate based on an interval of your choosing. Typically, like the example I gave on the last slide, for rectifiers — for monthly or bimonthly readings, you’re going to run those every month or every two months, however often you need, and your automation is going to align with that. And then for AC-type readings, where you need more data, you’re going to run that maybe even on a daily or weekly basis, as often as you need the data.

It’s important to think about your exports, though, and group them together from a verification standpoint. So if I have monthly rectifier imports — every single month I’m importing 241 rectifiers — and maybe I also have annual test points I’m going to import as well, the one time a year you’re importing test points, don’t mix that in with your rectifier imports. Because when you’re looking at record counts, you’re going to look each month for 241 records — it’s good, it’s good, it’s good — and then when the test point ones come in, you’re going to have a ton more records, and it’ll make it hard to understand if all of the rectifiers made it in. So keep those things separate, so you have a good understanding of your verification on a month-to-month basis.
Unit Swaps

And then lastly, just at a high level — talking about unit swaps. This is where we see most of the problems with misalignments occur. The scenario is: I go out to the field because my RMU stopped reporting, it’s got a problem, I need to send it in for repair — so I’m going to put in a new RMU. If you don’t go through the steps of reassociating the new RMU to the facility ID it’s attached to, and then removing the old facility ID from the old RMU, you can run into problems where units are reporting on the wrong data, because the facility IDs haven’t been updated.

So we have some tools in Bullhorn Web that you can see here — the Replace tool is how we do that, and it swaps all the data, makes it super easy. You should definitely do it before you go out to the field, though, so those initial packets that are captured report to the right place.

And that’s it — sorry for the technical difficulties, everyone, but I had to finish up pretty quick there at the end.