The monitoring layer your PLCs, BMS and SCADA already speak.

Modbus TCP and Modbus RTU, OPC UA, BACnet/IP and BACnet MS/TP, EtherNet/IP for Allen-Bradley and Omron PLCs, and MQTT with Sparkplug B. Each protocol runs as a client on the Edge Server, configured from the platform in the device's SDK Configuration editor rather than in a file on the box. A Modbus client, for example, carries four tabs: Connection for the endpoint IP, port, polling interval and timeout, Units for slave IDs and the bigEndian and swapWords decoding toggles, Settings, and Tags, where each register or coil is mapped to a named platform variable with its data type. The OPC UA client reads nodes from Kepware, Ignition, Siemens, B&R or any other compliant server, and BACnet clients poll object properties the same way. The Edge Server picks up configuration changes on its next restart, so adding a point to a remote site never requires a site visit.

No, and it is not trying to. SCADA keeps the control room: operator graphics, setpoint changes, interlocks and the fast local loop. ControlCom Connect takes over the work SCADA handles poorly: long-term trending, comparison across sites, alarm notifications that reach a phone by SMS or push, and reports that email themselves as PDFs on a schedule. The practical integration path is the OPC UA client, which reads tags from Kepware, Ignition, Siemens, B&R or any other compliant server, so the points SCADA already exposes reach the platform without anyone touching PLC programs. The two systems then share the same data with different jobs: SCADA acts on it in real time at the site, and the platform stores it, analyzes it across the whole estate, and routes it to the people who are not standing at the console.

As a Docker container on hardware you already have at the site; the Edge Server alone needs 384 MB of memory and 250 MB of disk, so a small industrial PC is plenty. A single docker run command starts it, and its web interface comes up on port 3041 on the local network. Onboarding registers the container as a ControlCom Gateway in your organization and installs its certificates in one step, and from that point every protocol client is created and edited from the platform rather than on the box. The container makes outbound connections only, so nothing opens an inbound port into the OT network. A replacement gateway is rebuilt by running the same container and onboarding it again, because the client configuration lives in the platform rather than on the hardware that failed.

The Edge Server keeps polling. Readings are buffered locally and sync to the cloud when the WAN returns, so the stored history carries no gap for the outage. Alarms with Enable for Edge Server checked are evaluated on the gateway itself, and the events they raise are distributed to any Edge HMIs connected to it, so screens on site keep showing live state and active alarms while the internet is down. Edge virtual variables continue computing and triggers continue evaluating locally, which is what makes local protective actions such as energizing an alarm relay dependable. For diagnosis during the outage, the Edge Server's Health pages read local endpoints rather than the cloud, so an engineer standing at the panel still sees connection status, client health and live values from the equipment.

Start with the five diagnostic tools that run on the Edge Server itself. Ping and TCP tests answer whether the device is reachable at all. The ad-hoc Modbus poller reads coils, discrete inputs and holding or input registers against any host and unit ID, with per-unit byte order and word swap toggles, so a wrong data type or a zero-based addressing mismatch shows up in the live values within a minute. BACnet Who-Is discovers what is actually answering on the network, and the MQTT Explorer inspects topics on the embedded broker. Live Logs stream the gateway's own logging with runtime-adjustable levels, and the same logs are readable remotely from the platform, the first stop when the gateway is three hours away. All five tools are ad-hoc by design, so probing a device never touches the production pipeline or writes into historical data.

Yes, and most controls teams have built at least one version of it. The honest accounting is what the stack costs after it works: protocol drivers with per-device quirks handled by hand (byte order, word order, zero-based addressing), local buffering for WAN drops, per-person notification routing across SMS, email and push, PDF reports on a schedule, user accounts and access control, and documentation good enough that a second engineer can maintain any of it. That is a product's worth of upkeep attached to one person's employment. In ControlCom Connect those pieces are configuration rather than code: a protocol client is stored in the platform and reproduced on a replacement gateway by onboarding it. Custom work stays possible where it earns its place, through the REST API and a documented Node-RED integration path, instead of being the foundation everything else rests on.