1631

Get a Live Demo

You need to see DPS gear in action. Get a live demo with our engineers.

White Paper Series

Check out our White Paper Series!

A complete library of helpful advice and survival guides for every aspect of system monitoring and control.

DPS is here to help.

1-800-693-0351

Have a specific question? Ask our team of expert engineers and get a specific answer!

Learn the Easy Way

Sign up for the next DPS Factory Training!

DPS Factory Training

Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.

Reserve Your Seat Today

Top 3 Questions About The T/Mon Master Station

Industry conferences are very important at DPS. It's at these events that we can listen to you in person and share our knowledge of remote monitoring with you.

Chatting with you at our trade show booths, we've seen a few common questions about our master station (T/Mon).

1. How Does DPS Equipment Ensure Guaranteed Delivery of Alarms? How Do We Deal With Unreliable SNMP Managers?

Guaranteed delivery of alarms can take a few forms.

In the case of third-party equipment (Motorola Moscad, etc.), we'll commonly be using SNMP because it's an industry standard. Unfortunately, SNMP traps are an unconfirmed "fire and forget" asynchronous notification. If the trap doesn't make it back to your SNMP manager (ex. network error, manager rebooting), you have no way of knowing the trap was ever sent.

SNMP delivery can be confirmed in a few different ways. T/Mon can perform an "SNMP poll". It will use GET commands (originally intended for occasional, manual request of a device's status) at regular intervals to poll the device for its alarm state. In this way, a lost trap is only a problem for at most a few minutes. At the next GET poll, the true alarm condition will be discovered.

If we have more control over the SNMP agent device (ex. DPS NetGuardian reporting to an SNMP manager), we can implement repeating traps. For example, sending 3 traps for every event massively reduces the chance that an alarm is missed. The chance of losing 3 duplicate traps is 10,000x lower than losing a typical single trap. Remember that this method does increase overall network traffic, and SNMP is already a verbose protocol.

The limitations of SNMP are precisely why DPS uses DCP protocol for T/Mon-to-NetGuardian communication. DCP is polled and very compact, which eliminates the disadvantages of SNMP discussed above.

2.How Would a Service Provider Use T/Mon to Segregate Monitoring For Multiple Clients?

There are several ways to define and sort specific groups of alarms within the T/Mon graphical interface.

Alarms can be sorted into "windows", so you could have windows for each client (ex. "Client1-All", "Client1-Generators", "Client1-Doors", "Client2-All", etc).

You could also start your GFX layers with a group of "select a client" icons. Your operators would start at that top-level screen, see a client start blinking, then drill down into that client's network to pinpoint the alarm. This is exactly what a large company would do for its multiple regions. In this case, each "region" isn't a geographic area but rather a client's facilities.

If you want your clients to have access to their own (and ONLY their own) alarms, you build them user profiles in T/Mon with access to only certain windows and GFX screens. You could also set them up with similarly filtered email/SMS alerts.

3. What Protocols Does T/Mon Support?
How Would You Mediate Legacy/Proprietary Equipment?
How Can I Use T/Mon to Gradually Upgrade My Legacy Monitoring Equipment?

T/Mon supports over 30 legacy, proprietary, and standard protocols. It also outputs many different standard protocols, including SNMP, Modbus, and DNP3.

This multi-protocol I/O capability makes it easy for T/Mon to act as a legacy mediator in your network. You can, for example, convert alarms from you legacy RTUs to your SNMP manager.

You can also replace your aging legacy master with T/Mon to support your gradual upgrade to modern RTUs.

The first phase starts with replacing the first single point of failure: your master. In this strategy, you first upgrade your master station to T/Mon. It is fully compatible with both your old legacy remotes and new standard protocols used by modern RTUs.
In the second phase of this strategy, you would then upgrade your RTUs incrementally as budget permits, or simply upgrade site-by-site as each of your old remotes fail.

More info: Seamlessly transition master & RTUs as they die out.

A full list of supported protocols is available for the T/Mon. You should always call DPS about support for a protocol you need since this list is constantly evolving. All of our protocol support was initially developed for a specific client request. If you need a protocol that T/Mon doesn't currently handle, we'll generally add it for free as part of your T/Mon purchase.

Your next step: Get full T/Mon specs

Be Proactive: Get a Quote

At DPS, we receive many urgent quote requests after an earlier "Do Nothing" decision comes back to bite you. You have no reason not to be proactive (and maybe you'll manage to impress your boss).

Call us. Chat with an expert for 10 minutes. We'll email you a detailed quote with a custom application drawing. We'll even include a summary of business benefits you can use to justify your project budget.

Call 1-800-693-0351 now for your quote

(or send us a quick online message instead)