Captia Connect connectivity
Industrial protocols Captia Connect speaks
Captia Connect speaks the protocols already present on the plant floor. The acquisition layer adapts to the installed base instead of replacing it: the PLC, the power analyser, the meter or the building bus stay where they are and the data comes out of them exactly as they expose it.
Each page explains how Connect speaks that protocol in a real installation: which equipment exposes it, what configuration it takes, which signals are acquired and where the limits are.
Protocol index
One page per protocol, with its integration detailed
Modbus TCP and Modbus RTU on RS-485 share a page because they are the same register protocol over two transports. REST API, webhooks and CSV share a page because the real decision is choosing between the three.
- OPC UAOT standardThe OT standard with a typed information model. Connect browses the address space and subscribes to the nodes that matter.See the protocol in detail
- MQTTMessagingLightweight pub/sub messaging for telemetry. Connect subscribes to the relevant topics and normalises the payloads.See the protocol in detail
- Modbus TCP and Modbus RTU / RS-485FieldbusThe same register protocol over two transports: Ethernet for TCP and a multi-drop serial bus for RTU on RS-485.See the protocol in detail
- IEC 870-5-102EnergyIEC remote metering profile for electricity meters. Connect reads load curves and totalisers from the meter.See the protocol in detail
- OpenWebNetBuildingBuilding automation: lighting, climate and facility consumption in the same history as the plant.See the protocol in detail
- Standard integrations: REST API, webhooks and CSVIT / IntegrationFor ERP, MES, cloud applications and closed systems: endpoint polling, event reception and file ingestion.See the protocol in detail
Protocol coexistence
How to choose the route when several protocols coexist
A plant rarely speaks a single protocol. It is common for the same equipment to be readable in two ways and for each area to speak its own, so the question is not which one is better but which one suits each signal.
Start from what the equipment already exposes
The preferred route is the one the equipment already publishes without touching its program: the OPC UA server embedded in the PLC or the SCADA, the Modbus register map of the analyser or the topic the equipment already publishes to the MQTT broker.
Keep the information model where there is one
When the equipment exposes OPC UA, Connect preserves source types and timestamps while browsing the address space. With Modbus that semantics does not travel in the protocol and has to be declared: type and scaling factor per signal, with the timestamp applied at the edge.
Separate telemetry from polling
What the equipment emits on its own comes in over MQTT, with Connect subscribed to the topics and local buffering if the broker or the network uplink drops. What has to be fetched comes in by register polling at the configured frequency.
Systems without an industrial protocol come in through standard integration
ERP, MES, cloud applications and closed systems do not speak a plant protocol: they are integrated by polling REST endpoints, receiving webhooks or ingesting CSV files on a schedule. All three land in the same time series model.
When several routes coexist on the same equipment, each protocol page details the cases where that route is not the right one and which one to go to instead.
Where it fits
Acquisition is the first layer of the platform
Protocols are where data enters. What happens next (normalisation, history, visualisation and the AI modules) is explained in the platform hub.