Digitize and DPS Technology Supplies Reliable Monitoring For a Municipal Transportation Organization

Digitize has the privilege of many contracts with organizations in higher education, military, and government. Over the last year, we’ve worked with one of our large municipal clients to update their system, inquire about any problems they’ve encountered, and provide them with innovative technology solutions.

This client is a transportation organization that already uses Digitize and DPS technology to monitor the status of their metro system. In fact, it was largely working together for this client that led to the acquisition of Digitize by DPS in 2022.

Andrew Erickson, a Digitize and DPS engineer, initially visited them last summer to view the status of their monitoring system and see where improvements could be made.

“I was familiar with their system,” explained Erickson, “I always get excited when I see a system using DPS and Digitize technology. I knew however, that it was time for an upgrade. I love the old [Digitize] System 3505s, but it just didn’t make sense to keep using them when we’ve done so much work on the Prism LXs. I love any job that involves a headend unit upgrade to the [Prism] LX.”

At the time, their system consisted of two physical locations. The first location contained two Digitize System 3505s reporting to a DPS NetGuardian 832A and a DPS T/Mon LNX respectively, via RS485 serial. The second location housed a Secondary T/Mon LNX unit.

This Secondary T/Mon cannot receive direct RS485 traffic from the first location. Therefore, it has no direct interaction with the System 3505s. The NetGuardian 832A, which is connected to the first System 3505, is racked immediately above the Primary T/Mon.

All text-based alarms sent to the NetGuardian via RS485 were available to both the Primary and Secondary T/Mon via LAN. During normal T/Mon operation, the Primary T/Mon would collect alarms from the NetGuardian, display them, and mirror data to the Secondary T/Mon.

In the event of a Primary T/Mon failure, the Secondary T/Mon would take over and begin collecting alarms from the NetGuardian, among many other alarm sources. The Primary T/Mon received incoming alarms both directly via RS485 and indirectly via LAN from the NetGuardian unit. T/Mon was then able to intrinsically de-duplicate these alarms.

Whenever identical text was received, T/Mon’s ASCII Processor resolved the message to an identical alarm point. Any duplicate “alarm” or “clear” events for the same alarm point at the same time had no effect.

We were thrilled when this client wanted to upgrade their System 3505s to Digitize Prism LXs. After all, the Prisms were network-enabled and, therefore, able to communicate with the T/Mons without requiring the intermediary of a NetGuardian. However, updating their system with our latest technology gave rise to an unexpected problem.

As a municipal organization, the client was understandably very concerned with security. There was a complex process required to receive an IP allocation for a new device, and we wanted to ensure that they had state-of-the-art monitoring capabilities as soon as possible.

“It caught us off-guard,” confessed Erickson, “It’s easier for us to just directly connect [the Prism LX to an IP address]. We had to brainstorm a workaround for this, but that’s some of the fun too - encountering a problem and coming up with a fix.”

Digitize will work around your requirements

For the immediate future, both Digitize units would each report to the Primary T/Mon via a pair of isolated “one-cable networks” to two of the additional network interfaces on the T/Mon, each of which has 6 network interfaces. To handle this architecture properly, DPS refined the new T/Mon Device Module to support intelligent de-duplication of alarm messages received via LAN from the Upper and Lower Digitize units.

T/Mon devices could identify a Digitize unit as either “Primary” or “Secondary.” Alarms would be collected at all times from both Digitize units, but only the Primary’s alarms would be displayed. If no handshakes, which were sent every 15 seconds, were received from the Primary (“Lower”) Digitize for 60 consecutive seconds, new alarm events would be displayed from the Secondary (“Upper”) instead.

A dedicated new alarm point would indicate that T/Mon was “running on the Secondary Digitize”, and the “Device” field in T/Mon for each alarm would display “PrismLX Secondary” instead of the typical “PrismLX Primary”. This would make it easy to identify the current state of the two Digitize units.

The new Digitize units (“System 3505 Prism LX”) and many new cards were delivered to the main location on Monday afternoon and installed between 8 AM and roughly 8 PM Tuesday. The changeovers were staggered to eliminate system downtime. DPS was on-site for this 12-hour period to ensure a smooth interplay between the new Digitize units and our two T/Mons.

“The problem with this system,” elaborated Andrew, “is that, in the event of Primary T/Mon failure, neither Prism unit is able to remotely communicate with the Secondary T/Mon at the second location. Everything at the first location was communicating perfectly fine, but there was no way to relay that information to the second site in the event of a power failure. We need to account for all possible situations, especially with these municipal contracts.” He continued, “We’re honored to have the clients we do, and we don’t take our position lightly.”

At this point, we had identified the Primary T/Mon as the single point of failure, and set out to explore options to increase redundancy.

Digitize will adapt quickly to meet your requirements - even during the same visit

We looked into restoring RS485 serial alarm reporting as an alternate path. The client had anticipated this and worked with Digitize to build support for RS485 into the new PrismLX units.

After ensuring that the Prism and T/Mon units were outfitted to respectively send and receive RS485 data, we ran some preliminary tests. The testing showed that RS485 data was received by both the Primary T/Mon and, during simulated Primary failures, the Secondary T/Mon.

Andrew had caught something almost right away, “Something we had noticed during these tests is that, because the alarm format is somewhat different between RS485 and LAN on Digitize, the T/Mon cannot currently de-duplicate alarms received via both channels.” He continued, “The two existing LAN paths from both Prism units to the Primary T/Mon made duplicate alarms received via RS485 into unnecessary clutter. That could easily lead to duplicate alarms piling up and confusing operators. Fortunately, the solution was a pretty easy one.”

To eliminate the unnecessary duplication, the RS485 cable from the Upper Digitize unit was simply disconnected from the back of the Primary T/Mon at the main location.

Because the configuration databases are synched between Primary and Secondary T/Mon, it is currently necessary to tolerate limited alarm duplication on the Primary T/Mon for alarms received from the Lower Prism unit. As indicated by the above diagram, these alarms are received via NetGuardian RS485. If they don’t become an outright nuisance, it’s always better to have two alarms for the same event rather than zero.

If the NetGuardian-to-T/Mon interface was eliminated from the T/Mon configuration, the Secondary T/Mon would not use it during a failure of the Primary T/Mon. Fortunately, the increased alarm detail from Digitize’s LAN reporting means that only a small percentage of alarms are duplicated. It is also clear to operators which interface reported an alarm.

On Thursday morning, Andrew reviewed the system status and performed some verifications in the T/Mon web and VM interfaces. He then created a new T/Mon Alarm Group called “Digitize Down”. The new dedicated alarms that indicate a loss of communication with Digitize will now be displayed in this prominent location.

“I ran a series of tests to cover all of our bases,” explained Andrew, “I had to ensure that if any one piece of DPS or Digitize equipment failed, the system would catch it, report it, and most importantly, reorient itself in the moment to accommodate for it. I wanted to guarantee that this system is constantly aware of all of its parts, but also knows how to react and function without any one part of it.”

To test the efficacy of this system, the Lower Digitize unit was unplugged from LAN. The T/Mon detected this and began displaying alarms from the Upper Digitize unit.

Next, the Lower Digitize unit was plugged back into LAN. As expected, the T/Mon detected this and resumed normal operation. The Upper Digitize unit was then unplugged from LAN. The T/Mon detected this, displayed the dedicated alarm indicating it, and continued displaying alarms from the Lower Digitize unit.

Continuing on, the Upper Digitize unit was plugged back into LAN. The T/Mon cleared the dedicated alarm and continued normal operation. The Primary T/Mon was disconnected from LAN. The Secondary T/Mon took over. It correctly displayed alarms received via NetGuardian RS485. These results serve as proof that the system maintains the same functionality that was available before this project. All failures and restorations were simultaneously detected and displayed by the Digitize Computer Graphics Response Management System.

To summarize, there are four total alarm outputs from the Digitize units, three of which are being utilized. The active three are LAN from Lower Digitize to Primary T/Mon, LAN from Upper Digitize to Primary T/Mon, and RS485 from Lower Digitize to the NetGuardian 832A for LAN connectivity to both T/Mons. As described earlier, the fourth output, the RS485 from Upper Digitize, has been disconnected from the Primary T/Mon to eliminate alarm duplication without harming dual-redundancy.

After concluding these tests, Andrew conducted a training lesson and distributed fliers that describe the use of the modern T/Mon web interface instead of T/Windows, which is now necessary to view the LAN-based alarms from Digitize. A special screen that closely mimics the look of T/Windows has been created to ease this transition for the operators.

Digitize engineers avoid problems before they happen

At Digitize, we absolutely believe in pursuing any unusual readings down to their source. Anything left unexamined will only cause problems later. We had one such situation during this project.

Early in August, there was a sudden absence of any Emergency Exit alarms in the T/Windows T/Mon software. On Monday, August 9, Andrew visited the site to diagnose the problem.

Based on T/Mon’s logs, since about 11:12 PM on Thursday, July 29, T/Mon had been receiving and reporting alarms only from the Upper Digitize unit. This is a failover state, as T/Mon normally receives alarms from both Digitize units at all times.

As long as the Lower Digitize device shakes hands with T/Mon every 60 seconds, no alarms from the Upper Digitize are displayed by T/Mon. Digitize worked hand-in-hand with DPS to detect and resolve an issue with RS485 and alarm reporting.

Later, it was discovered that a small setting could be changed to ensure that both Prism LX units are sending alarms. Even without an IP allocation, Digitize quickly assembled a way for the newly upgraded system to function to the client’s specifications.

Give us a call to discuss your alarm monitoring project

As you can see, we specialize in custom alarm monitoring solutions. We have a dedicated support team ready to assist you with any questions you may have.

Give us a call at 1-800-523-7232 or email us at info@digitize-inc.com to discuss your project, receive a custom diagram, and get a detailed price quote.