Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next 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
You've got alarms arriving from dozens or hundreds of remote sites, and no single screen that shows all of them at once. So you start evaluating centralized platforms, and two names land on the shortlist from completely different corners of the industry. T/Mon is an alarm master built for telecom sites, utility substations, and transportation systems. IBM Netcool/OMNIbus is an enterprise information technology (IT) event manager built to sit as an umbrella over very large, mixed software and network estates.
The decision usually comes down to what your alarms physically connect to. If most of them arrive as serial data, dry contacts, or protocols that predate widespread Internet Protocol (IP) networking, a purpose-built alarm master fits the job better. If most of them arrive as software events from virtualized infrastructure spread across a national estate, an enterprise event manager fits better.
At DPS Telecom we build both the T/Mon master and the Remote Telemetry Units (RTUs) that report to it, and we've put more than 172,800 devices into the field since 1986. That track record gives us a clear point of view on where each platform fits, and it's a view we've formed from our own experience. We think T/Mon earns its place in a lot of networks, and we're happy to say so.
IBM Netcool/OMNIbus is an enterprise IT event-management suite. IBM describes its core, the ObjectServer, as an "in-memory database server," meaning it holds its data in memory rather than on disk so it can process events quickly. That core is fed by software agents IBM calls probes. Each probe plugs into one type of system and translates its events into a single common format the ObjectServer can read. IBM positions the platform for very large, mixed environments (many servers, applications, and network devices) being consolidated into one console.
Our T/Mon is a purpose-built hardware alarm master. You rack it at your Network Operations Center (NOC), and it speaks the protocols that telecom, utility, and transportation equipment run on, using native modules instead of custom rules files. It also pairs directly with our NetGuardian RTUs in the field, so one manufacturer covers the whole signal path from the contact closure to the screen.
We're a strong fit when your alarms come from field and proprietary equipment rather than software events, when you want one vendor building both the master and the remotes, and when the hardware has to survive a remote site instead of a climate-controlled room. It also helps if you need a protocol that no catalog covers yet, since we add those. If your network matches most of that description, T/Mon belongs on your shortlist.
Around the ObjectServer core, those probes are spread across the network rather than sitting in one place. Each probe connects to a set of event sources, translates what it finds into that common format, and forwards it to the central server. Gateways then let the platform pass events to and from other tools, including databases, help-desk systems, and customer relationship management (CRM) software.
Our T/Mon alarm master platform comes at the same job as an appliance. Built-in modules cover the Simple Network Management Protocol (SNMP), Distributed Network Protocol 3 (DNP3), Modbus, Transaction Language 1 (TL1), our own DPS Communication Protocol (DCP), ASCII text streams (American Standard Code for Information Interchange), and any number of other older technologies still running in the field.
T/Mon comes in three sizes, so you're not buying capacity you won't use. T/Mon MINI provides centralized monitoring for up to 16 DPS alarm remotes and scales to 64. T/Mon SLIM monitors up to 64 network devices and adds third-party SNMP, ASCII, and TL1 gear. T/Mon LNX is the full-capacity master for larger networks.
Netcool/OMNIbus scales by adding software: more probes, more server capacity, and more containers (self-contained packages of software that can be started up as demand grows). It's built to sort very high volumes of events quickly. It groups related alarms and filters out duplicate copies of the same alarm, so operators see one clear signal instead of thousands. That speed helps most when a core failure throws thousands of downstream messages at you at once.
T/Mon scales by chassis. You size the appliance to your network, then connect it to the equipment you need to watch. What it connects to is physical: dry contacts, serial ports, generator and power-plant alarms, and the switching gear at a remote site.
From a telecom operations perspective, we prioritize direct hardware mediation and predictable, deterministic behavior over maximum flexibility across a wide range of IT event streams. That's a deliberate choice, because the networks we serve live at the physical edge, often in unstaffed huts.
| ConsiderationIBM Netcool/OMNIbusDPS Telecom T/Mon | ||
|---|---|---|
| Product type | Enterprise IT event-management software suite | Purpose-built hardware alarm master |
| Core architecture | Distributed, in-memory ObjectServer fed by software probes | Single-platform appliance with built-in protocol modules |
| Field and proprietary protocols | Handled through software probes and rules files, including a dedicated TL1 probe | Native modules for SNMP, DNP3, Modbus, TL1, ASCII, and DCP, more than 30 in total |
| Typical deployment | Containerized on Red Hat OpenShift and Kubernetes in IBM's current documented model | Rack-mounted appliance in a standard equipment rack |
| Licensing | Metric-based software licensing (managed devices, event volume, virtual cores) | One-time purchase, with capacity set by the chassis and the enabled modules |
| Support | Enterprise maintenance and support agreements | Free lifetime technical support from the DPS engineers who design the equipment |
| Build | Software, deployed on-premises or in the cloud | Designed and built in the USA (Fresno, CA), Network Equipment-Building System (NEBS) compliance tested in our own lab, ISO 9001 certified |
| Common fit | Very large national IT and network estates standardized on an enterprise event bus | Telecom, utility, transportation, and public-safety networks in the tens-to-hundreds-of-sites range |
The IBM Netcool/OMNIbus details above were gathered by reviewing IBM's published documentation. They may not capture every configuration or deployment option, and some information may have changed since it was reviewed.
T/Mon recognizes field and telecom devices through pre-built protocol modules rather than custom code. The library has grown past 30 protocols over the years, most of them added because a client asked for them. When a client needs a protocol T/Mon doesn't yet cover, we commonly develop it as part of the purchase, without a separate engineering charge on qualifying order sizes. Bringing many protocols under one console is the whole point of multiprotocol alarm aggregation, and it lets you mediate proprietary and older equipment into standard protocols without pulling out the underlying gear.
Netcool/OMNIbus monitors telecom equipment too, through those same probes. For TL1, IBM provides a dedicated TL1 probe that logs into the device, issues commands, and reads the responses with a rules file. That rules file is a configuration file that tells the probe how to pull apart the raw text a device sends back and file each piece into the right database field. That approach can handle many kinds of text-based equipment output. T/Mon handles TL1 through a software module built into the appliance instead, with no separate probe running on its own server.
The ASCII processor shows what native handling looks like day to day. Tim LaChance at National Grid, where T/Mon handles fiber ring alarm monitoring, described his experience with it in our book 100% Uptime.
"We can now use the ASCII processor on the T/Mon to Telnet into our devices to find out the root cause of a problem and report that directly to the alarm screen. This will allow our operators to get critical information much faster because they won't have to open the Telnet and issue the queries to get more detail. This shortens the time to dispatch, which is good for everybody."
His colleague Joel Beecher pointed to the setup side of the same feature set.
"The biggest feature improvements I've seen are auto-databasing ASCII and auto-databasing SNMP. For a lot of our alarms, we haven't been able to get them onto the screen. Now we can do that with those functions."
IBM describes the current model for its operations-insight platform as running on Red Hat OpenShift and Kubernetes, which run those containers across a cluster of servers. A management layer starts, stops, and balances them automatically and allocates storage as the workload needs it. Organizations often staff that with teams experienced in running these platforms and their storage. T/Mon installs in a standard equipment rack. You power it, connect your transport links, and enable the modules you need.
Licensing splits along the same line. Netcool/OMNIbus uses metric-based software licensing tied to factors like managed devices, monthly event volume, and virtual processor cores, and organizations commonly track their usage with the IBM License Metric Tool. T/Mon is typically a one-time capital purchase, with capacity set by the chassis you buy and the software modules you turn on. From our perspective, a fixed Capital Expenditure (CapEx) model tends to fit the decades-long budget cycles that utilities and telecom operators plan around.
Our support comes from the engineers who design and build the equipment, and free lifetime tech support is included with every purchase. We don't force upgrades, and our gear commonly runs 20 or more years in the field. That longevity is one reason many of our original clients from the 1980s are still running DPS equipment today.
T/Mon and our RTUs are built for the physical conditions of a remote site, including temperature extremes, wide voltage swings, and power surges. We run NEBS compliance testing in our own lab, using an anechoic EMI isolation chamber along with torture, drop, and vibration testing, and we can send units out for formal third-party NEBS certification when a central office requires it. Alarms that live in a climate-controlled data center rarely put that to the test. Alarms that live in an unstaffed hut on a mountaintop, in a substation yard, or in a trackside enclosure often do.
Over a 20-year deployment, the difference between those two environments shows up in how often somebody has to drive out and touch the equipment. Because we design, build, and test everything at our Fresno facilities, one company stays accountable for the master, the remotes, and the protocol path between them.
Plenty of networks are a better match for an enterprise event manager, and Netcool/OMNIbus is one of the strongest.
If your network is turning into a software-defined data center, Netcool is built for that world. In that model, computing, storage, and networking are delivered as software rather than as dedicated hardware. This is the shift to Network Functions Virtualization (NFV), where jobs that used to run on physical switches and routers run as software on standard servers, alongside cloud-hosted voice. IBM designed Netcool to collect events from that software-based infrastructure and track the health of virtual machines as they're created, moved, and removed. A hardware alarm master built for serial connections and contact closures isn't the right tool for following how software services depend on one another inside a cluster of virtualized applications.
If you're consolidating a NOC, a Security Operations Center (SOC), and an IT help desk into a single console across a national estate, Netcool's gateways are made for that. The platform pushes correlated, deduplicated alerts into IT service management (ITSM) and ticketing tools, and its in-memory engine scales to event volumes that a fixed-capacity appliance is not sized for.
And if your organization has already standardized on an enterprise event bus (a central pipeline that all your systems feed their events into) and your team runs it well, adding a separate master may not be worth it.
In a lot of real networks, T/Mon and an enterprise platform run side by side.
Our RTUs report over SNMP to third-party managers, so your IT team can keep its platform while your NOC or facilities team runs T/Mon for the field. Our NetGuardian RTU family can send SNMP traps directly to a third-party SNMP manager, whether over a standard IP network or a dial-up connection for a remote site. To read those traps, the IT team loads the NetGuardian Management Information Base (MIB) files into the manager and sets up the rules to interpret them.
T/Mon can also work as an edge mediator. It reads alarms from the proprietary, serial, and older field gear that an enterprise manager may not speak natively, converts them into standard SNMP traps, and forwards them up to the enterprise platform. That way the enterprise manager pulls everything together at the top level while T/Mon handles the field.
We've seen both approaches in production. South Central Communications used T/Mon to unify SNMP and RTU alarm monitoring under one platform. Dominion used T/Mon to bring three separate legacy alarm systems into a single platform without replacing the underlying field equipment.
Four things point toward T/Mon.
Three things point toward an enterprise event manager instead.
Yes. Our RTUs report to third-party SNMP managers, and T/Mon can forward mediated alarms up to an enterprise platform over SNMP. A common split has IT running the enterprise manager while the NOC or facilities team runs T/Mon for field monitoring.
No. Devices are recognized through pre-built protocol modules rather than custom rules files. If you need a protocol T/Mon doesn't yet support, tell us what you're trying to accomplish, and we'll often develop it as part of the order.
It can be. T/Mon MINI monitors up to 16 DPS alarm remotes and scales to 64, which suits a lot of rural telcos, small internet service providers, and county public-safety networks that want centralized monitoring without an enterprise-scale platform. If you also need to pull in third-party SNMP, ASCII, or TL1 equipment, T/Mon SLIM is the next size up.
The right platform depends on your specific mix of sites, protocols, and long-term plans, and that's exactly the conversation we like to have. Tell us what you're trying to monitor and what your network looks like, and we'll tell you whether T/Mon fits, whether an enterprise manager fits better, or whether the two should run together.
Talk to an Engineer | 800-693-0351
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 19 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...
