Cut unplanned downtime on every machine.

Yes, and the mixed fleet is the design case rather than the exception. The ControlCom Edge Server speaks Modbus TCP/RTU, OPC-UA, BACnet, EtherNet/IP, and MQTT, so chillers, compressors, generators, packaged lines, and PLC-controlled equipment from different manufacturers land in the same platform through one gateway per site. Each machine becomes an asset with its variables attached, regardless of which device collected them, so dashboards, alarms, and reports are organized by equipment rather than by vendor. That is what removes the dozen-login problem: the compressor from one maker and the chiller from another appear on the same dashboard, alarm into the same groups, and show up in the same history. When a controller is later replaced with another brand, the asset and its history stay put; only the variable mapping behind it changes.

Condition monitoring is the data layer: continuously collecting readings such as temperatures, currents, pressures, and runtimes, and watching them against thresholds and learned baselines around the clock. Predictive maintenance is the practice built on top: servicing a machine because its measured condition changed, rather than because a calendar interval expired. The distinction matters when evaluating software, because a platform can only supply the first part. ControlCom Connect provides the monitoring: alarms with severity levels and notification routing, anomaly detection that learns each variable's normal pattern, occurrence counts that show whether a machine's alarms are getting more frequent, and the Data Explorer trends that planning meetings run on. The practice is a workflow change your team makes. The honest pitch is that the platform makes that change possible and visibly cheaper, not that it happens automatically.

No. The Edge Server installs on site as a container and reads equipment over the protocols already in use, so PLCs keep their logic, the BMS keeps running its buildings, and SCADA keeps its role. Monitoring is additive: the platform stores every reading in the cloud, evaluates alarms, learns anomaly baselines, and serves the dashboards, while the control layer is never asked to do anything new. This is also what keeps deployment out of the capital-project category: there is no rewiring, no controller replacement, and no downtime window to schedule, because the work is configuring protocol clients and attaching variables to assets. If a controller is later replaced anyway, the platform absorbs the change by remapping variables to the same asset, and the machine's history carries on unbroken, which is exactly what a long-running reliability program needs from its data layer.

It learns each variable's baseline from its own previous 14 days of hourly readings and compares hour band by hour band, so a 3am value is judged against other nights rather than against the working day. Three detectors run over the same data. Out of range scores how far the latest hourly value sits from the baseline mean, in standard deviations, and leaves anything within three and a half alone. Stuck sensor flags a value that stopped moving when its own history says it should move, and excludes duty-cycled equipment resting at idle, so a generator sitting at zero is not a fault. Data gap reports readings that stopped arriving, after enough missing hours to absorb ordinary ingestion lag. When most of an asset's variables go quiet together, the events group into one incident, and if a related asset steps up within hours, the incident is labeled a load switchover: the difference between a dead meter and a generator carrying the building.

Yes. Every connected site rolls into one organization, and the working views are built for the person who is not on site: the Map shows all monitored locations colored by alarm state, dashboards present live and historical data per asset or per facility, and alarm notifications reach subscribed people by SMS, email, and push wherever they are. A maintenance lead responsible for several plants runs the morning check from one login instead of a portal per site, and drills from the map into a specific machine's readings without changing systems. The same reach applies to investigation: an alarm at a remote plant opens into its event page, its variable plots in the Data Explorer alongside points from other sites, and the shortage of windshield time stops deciding which machines get watched.

The Edge Server keeps working through it. It runs on hardware at the site, continues reading equipment, buffers every reading locally, and keeps local views and alarms alive; when the connection returns, the buffered history reaches the cloud and the record stays complete. For a condition-monitoring program, that completeness is what matters most: anomaly baselines are learned from stored history, and trend analysis is only as good as the data underneath it, so a platform that dropped readings during every WAN blip would slowly corrupt its own picture of normal. Buffering on the gateway prevents that without any extra logger hardware. Alarms enabled for the Edge Server are also evaluated locally during the outage, so a bearing temperature crossing its threshold at a disconnected site still raises the event on site rather than waiting for the internet to come back.