How to Monitor Important Airport Equipment (ILS/VOR)

DPS equipment is frequently used in life-and-death scenarios, but few are so immediate as in aviation. When NetGuardians monitor telecom networks, it's possible that someone might not be able to dial 911. In instrument conditions (zero visibility), a malfunctioning ILS (Instrument Landing System) can quite literally send airplanes into mountains.

Project: Collect alarms from ILS/VOR systems and report them immediately

My proposed monitoring system for this state department of transportaion (airports division), involving many NetGuardian DIN units reporting to a central T/Mon SLIM master station. ILS and other aeronautical systems will be monitored in this way.

"Life and death importance" was the context that brought this particular project to my doorstep. It all started with a nonspecific request for information on my website:

"Hello, Interested in RTU and monitoring software. In preliminary research. I am familiar with Asentria SiteBoss 550 in a previous position. Thank you."

This message led to a long phone call, where we reviewed the goals of the project. As I noted during the call:

1. It would be better for the ILS system to fail completely (deny information to pilots) than to broadcast incorrect location information (putting pilots at risk of crashing in zero visibility / IMC).
2. The ILS/VOR manufacturer makes a box, the RCSU (Remote Control Status Unit). This means that 600-baud FSK is available for collection monitoring data. This is only a "very simple bitstream".
3. This communication scheme requires login/interrogation. It might continue spitting out data indefinitely once enabled. More research is required.
4. A manual may exist describing protocol details (ex. "mark" & "space" concepts, hardcoded frequencies, dB level). At airports, it's typically just copper wire.
5. There's a threat of LEDs "lying" about status of the underlying system, so supeficially replicated LEDs present a risk.
6. Examples of system state:
   • On-air
   • Off-air
   • Bypass
   • Remote user
   • On batteries
7. Thales & Celex equipment would require two different panels
8. Other brands of LED panel exist, but they share the RCSU protocol.
9. Goal: Right-click OID in SNMP manager and see the history of the alarm point.
10. There will be a computer on-site for an engineer to log into equipment via remote desktop.
11. Monthly inspections are required for serial/ASCII equipment. Can serial terminal server be used to trigger ASCII alarm output? (this is typically straightforward with DPS equipment)
12. Data is same regardless of how you get it (serial/ASCII/...), but it will obviously be different from the FSK.
13. Goal: Capture the "Maint(enance) Alert" light - and whether it's the building temperature or another alarm point that's causing it.
14. We discussed the importance of detecting RTU failures promptly for compliance with strict FAA standards. (I discussed DCP polling, which is better able to detect a remote device failure than an asynchronous protocol like SNMP.)
15. We might be able to "prove" to the FAA that a DPS system means monitoring is as good or better than federal standards. Declaring site as a "monitored facility" is a huge benefit here. FAA rule: You can fly to an airport if it's designated as an unmonitored site. Your alternate airport (for ceiling below minimums) must be monitored. This is a great convenience for aircraft.
16. We'll probably only need a single central T/Mon server unless FAA regulations demand redundancy.
17. Goal: Use email notifications to trigger automatic NOTAM (Notice to Airmen) notifications

This client had a solid history with remote monitoring equipment

Working for a state government, this particular new client has had a long career in the industry since the mid 1990's. In the past, in another department, there used to be more staff than absolutely needed. In his new department, there are fewer people.

Where he used to work, Asentria equipment was being used for a statewide emergency radio network. It was based around SNMP for all of the tower sites. It was "like a network monitoring type tool".

Legacy equipment was posing a challenge

This client had a system that "seems to be stuck in another era."

The ILS is inspected on foot with hand equipment regularly. Every 18 months, there's a flight check to confirm that the ILS is correct and can turn itself off when it's significantly wrong. If the gear is left in "Bypass Mode", it can't turn itself off. That potentially puts pilots at risk.

This client had a specific vision for remote airport monitoring

For this project, the site count would probably be around 40 sites. The client would have to decide which ones we want to monitor and which ones we don't.

• There will be cellular VPN connections at each site (he will furnish these himself).
• Devices include: Navigation (VOR, DME, and ILS). These are "Non-Fed(eral)" because they're owned by State and don't have Federal inspection/monitoring requirements, but the client still wants to monitor this gear.
• Their old homebrew System would send ASCII commands to log in, go to an alarm screen, then capture status. Programming software is DOS based. "I just use Debian on an old Dell desktop and put XFC4 Desktop on it and run OpenVPN via DOSbox. When a contractor needs to program or check things (they have to inspect once per month since gear is so sensitive), they VPN or use a web-based remote desktop.
• An unlimited cellular data connection is the same as a POTS line, so why not?" It ran about 3x per day, automatically.
• "Beyond that, we want to get dry-relay contacts to indicate uptime. That's where DPS comes in, because we might want to capture contacts and analogs."
• "I was watching your videos on YouTube. DPS software is somewhat open-source" (he means the ability to edit code to write new Device Modules, etc).
• Goal: Program will get written into BASIC or something else. It will do the same thing as the previous script, but then render an SNMP trap. This is only necessary if the device only does ASCII and doesn't have "I'm online" contact closure. The old system was built to be only internal because it was public safety and looked at 24x7x365. "Now, we won't be doing that. We can look at it at any time, but it can email a few people, too."
• VPN would be fine, but maybe someone on the outside could look at a read-only status screen.

Many typical remote-site alarms would also be monitored

After you deploy RTUs and a central master station for remote monitoring, your next step is to use it effectively by monitoring everything you can. That includes many standard items that aren't specific to, in this case, airports or aviation.

Important items to be monitored include:

1. Device uptime status (some shelters have two pieces of equipment in them, so 2x discretes)
2. Temp sensor (building ambient)
3. Door open
4. Lights left on (photo sensor?)
5. AC power fail ("I'll know that I'm on battery")
6. Analogs ("Not sure if I really need to know battery voltage. There's no low-voltage disconnect. It'll just run until it's done. There are no generators. These are fairly robust +24v battery strings. Others are +48v, atypical compared to -48v.")
7. LED outputs on system panels that say "online", "bypass" (bad thing since executive control has been bypassed, manual override that makes it run all the time and can be accidentally left on), or "non-functional". Project consideration: "What's harder? Rewrite the code to make it spit out SNMP, or can we do the photo-diode thing?" Some systems demand no unauthorized modifications, because they were designed by the manufacturer and "blessed" by the FAA. If we can't find a relay closure and some way of knowing, it sounds odd, but a photo diode on the LED panel. Another idea would be to put a non-intrusive split-core current transducer on the transmitter power draw.
8. Equipment: On ILS equipment, one of them is called a Mk10, the other is a Mk20 by Thales. Selex 2100. VORs are Selex 1150, Thales 5850. VOR is declining (in favor of GPS).

What are the next steps in this project?

According to my client here, "We're preliminary. We're just figuring out what we can do. The phone lines in a lot of places are gone. We can't repair cable because it's on an airfield, so it becomes beyond economical repair because it's not the local telco's responsibility."

He's working on this project for Q2. Other projects are ahead, but he wants to get the ball rolling ("this is the stuff I love to do").

We planned a conference call a few days from now. The installer-contractor might be on next call to share his perspective. Currently, it's ungainly to access the system remotely.

My first quote reflected the major project goals

Here's what I wrote in my first proposal to this client:

Thank you again for contacting us regarding your upcoming project. Based on our conversation, I have prepared this proposal to include pricing for the T/Mon SLIM G2, the NetGuardian DIN, and accessory sensors.

By deploying the NetGuardian DIN, you will immediately gain the following benefits:

• The ability to collect 1200-baud 202 data from aeronautical equipment, then transmit the information to T/Mon for display, alerting, and history logging. This will bolster your case to demonstrate readiness to be a "monitored" airport that may be used as a bad-weather backup by pilots.

By deploying T/Mon, you will gain the following benefits:

• The ability to monitor up to 64 devices (including DPS NetGuardians) in a single, unified interface. Many users can connect simultaneously and navigate independently.

My client was pleased...

"At this point, DPS is the best solution we've come up with. It's a very reasonable price for the amount of equipment involved."

"I sent Ron the basic code that devices use. I wonder if it's a possibility for DPS RTU to run script in background and connect to actual code of equipment on site. It only needs to poll maybe once an hour. It would be the same method as over POTS but without POTS. The RTU is local."

(DPS co-founder Ron had a detailed conversation with him about technical methods of collecting alarms from 202). The client had proposed using the POTS connection locally as an option, but this would be delayed data compared to a real-time 202 method. I explained the DPS guarantee, even for custom work. We won't leave him hanging.

Projects like this always take time to get approved

"Our timeline has most likely shifted to fall as we are working on a Airport WiFi and ADS-B solution for multiple sites."

Waiting for the project to get funded, my client did extensive bench testing to further ensure success:

"I now have a working RCSU on my test bench connected to a MK10 Outer Marker System via a simple 2 wire connection. I have bridged a 600ohm audio transformer into the circuit to record the FSK audio for review. The RCSU polling rate was changed to 1 sec. from what I think was a 600ms default. This was to make recordings in Audacity easier to read. The timing had no effect on the response."

"The polling address has a value of 0-7 for this test I set the value to 1 and then matched the radios address to 1 as well. Attached are the Audacity audio files from recording the FSK from each style of event we are interested in reporting."

In particular, the Audacity recording was very helpful for DPS Engineering to verify that the 202 modem was putting out the signals we expect.

That style of communications would account for approximately 25-30 of RTU's and equipment we plan to monitor.

What can I help you monitor?

Do you work with airport navigation systems like ILS and VOR? Do you need to monitor something different?

Whatever you need to monitor, I can help you sort it out. Everything I've described above is pulled from my project notse, so you can tell I'm quite thorough. I'll do the same when you tell me about your project.

Just call me at 559-454-1600. You can also send me a quick email at sales@dpstele.com

Andrew Erickson

Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 17 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...