IT and OT integration protocols: a working reference

1. Siemens S7comm and S7comm-Plus

Stack

S7 protocol over COTP (ISO 8073) over TPKT (RFC 1006) over TCP 102

Addressing

Rack and slot; typically rack 0 slot 1 for S7-1200/1500, rack 0 slot 2 for S7-300/400

Reads

DB, M, I, Q, T, C areas by byte offset

S7comm is the classic protocol used by S7-300 and S7-400. S7comm-Plus arrived with the S7-1200 and S7-1500 and adds session integrity checks, which is why older drivers fail against a 1500 unless optimised block access is disabled and PUT/GET communication is explicitly enabled in the CPU protection settings.

For integration, the practical choice on an S7-1500 is its built-in OPC UA server rather than S7comm. It is licensed, but it gives you a typed namespace instead of raw byte offsets, and it survives a DB structure change that would silently break an offset-based driver.

# Confirm S7 sessions and separate the two variants
s7comm || s7comm-plus

# Job requests only (read/write), useful for spotting driver polling load
s7comm.header.rosctr == 1

# Connection setup problems show up in COTP, not S7
cotp.type == 0x0d || cotp.type == 0x0e

# Count who is talking to the CPU
tcp.port == 102 && tcp.flags.syn == 1 && tcp.flags.ack == 0

2. PROFINET IO

Stack

Ethernet Layer 2, EtherType 0x8892, cyclic RT frames

Cycle

Typically 1-32 ms RT; IRT for motion

Discovery

DCP — how you find a device with no IP address

PROFINET carries I/O, not tags. You will not pull an energy value out of a PROFINET RT frame without the GSDML module layout, so treat it as a diagnostic protocol during integration rather than a data source. Where it matters is fault finding: a jittery RT cycle or repeated AR aborts explain SCADA dropouts that look like a network problem.

# All PROFINET real-time cyclic traffic
pn_rt

# Device discovery and naming (DCP) — finding an unconfigured device
pn_dcp

# Alarms and connection aborts
pn_io.alarm_type || pn_io

# Filter one device's cyclic frames by MAC
eth.src == 00:1b:1b:aa:bb:cc && eth.type == 0x8892

3. Rockwell EtherNet/IP and CIP

Explicit messaging

TCP 44818 — request/response, tag reads, MSG instruction

Implicit messaging

UDP 2222 — cyclic I/O connections, RPI-driven

Tag model

Symbolic, named tags — no byte offsets

EtherNet/IP is the easiest of the proprietary protocols to integrate because Logix controllers expose symbolic tags. A gateway reads Line15_Energy.kWh_Total directly, and tag names survive a program rebuild.

Watch connection limits. A ControlLogix has a finite CIP connection pool shared by HMIs, MES, gateways and engineering workstations. Multiple polling clients on the same controller is the most frequent cause of "the SCADA went grey for a minute" on a Rockwell site.

# All EtherNet/IP encapsulation and CIP payloads
enip || cip

# Explicit messaging only (tag reads and writes)
tcp.port == 44818

# Cyclic I/O — check RPI health and packet loss
udp.port == 2222

# CIP service errors: anything with a non-zero general status
cip.genstat != 0

# List Identity broadcasts — device discovery on the subnet
enip.command == 0x0063

4. Mitsubishi MC Protocol and SLMP

Formats

3E frame (Q/L/iQ-R), 4E frame with serial number, 1E legacy (A series)

Encoding

Binary or ASCII — set per connection, and mismatches are a common failure

Device areas

D, W, M, X, Y, R, ZR

SLMP is the open superset of MC Protocol that Mitsubishi promotes for CC-Link IE and third-party devices. Ports are assigned by the engineer in the built-in Ethernet port parameters, so the value in GX Works is the only authority. Binary 3E frame is the sensible default: it is compact and every gateway supports it.

32-bit values on a Mitsubishi CPU sit across two consecutive D registers, low word first. If you read a float and get a wild number, the word order is the first thing to check, not the meter.

# Where a recent Wireshark build has the SLMP dissector
slmp

# Otherwise filter by the configured port
tcp.port == 5007 || udp.port == 5562

# CC-Link IE Field Basic (cyclic, over UDP)
udp.port == 61450

# CC-Link IE Field (Layer 2)
eth.type == 0x890f

5. Schneider Modbus TCP and UMAS

Port

TCP 502, MBAP header, unit ID for gateway routing

Function codes

FC3 holding registers, FC4 input registers, FC16 write multiple

Proprietary layer

UMAS rides inside Modbus function code 0x5A (90)

Modbus TCP is the lowest common denominator and the workhorse of energy monitoring. It is also the least defended: no authentication, no encryption, and a register map that means nothing without documentation. Keep it below the DMZ and never expose port 502 outward.

UMAS is the Schneider-specific layer used by EcoStruxure Control Expert for program upload, download and monitoring. Seeing function code 90 in a capture tells you an engineering tool is connected, which is worth knowing during a change-control audit.

# All Modbus TCP
mbtcp

# Read holding registers only
mbtcp.modbus.func_code == 3

# Exception responses — the fastest way to find a bad register map
modbus.exception_code

# Schneider UMAS (engineering tool traffic)
mbtcp.modbus.func_code == 90

# One slave behind a gateway
mbtcp.unit_id == 7

6. ABB and IEC 61850 (MMS, GOOSE, Sampled Values)

MMS

TCP 102 — client/server reads, reports, file transfer

GOOSE

EtherType 0x88B8 — multicast Layer 2, sub-4 ms trip signals

Sampled Values

EtherType 0x88BA — digitised CT/VT streams, IEC 61850-9-2

Model

Logical devices and nodes described in SCL files (ICD, CID, SCD)

For an energy monitoring project on an HT side, 61850 MMS is where the real measurements live: MMXU logical nodes give you power, energy and power quality already scaled and time-stamped, which beats scraping a Modbus register map.

GOOSE and Sampled Values are Layer 2 multicast and do not route. If your capture shows nothing, you are on the wrong VLAN or the switch is not mirroring the right port. ABB's AC500 PLC range, by contrast, is usually integrated over plain Modbus TCP, EtherNet/IP or PROFINET, so identify which ABB family you are dealing with before planning the driver.

# Substation client/server traffic
mms

# Protection signalling — Layer 2 multicast
goose

# Sampled values stream
sv

# GOOSE state changes only (stNum increments on a real event)
goose.stNum

# Both 61850 Layer 2 types in one filter
eth.type == 0x88b8 || eth.type == 0x88ba

7. Omron FINS

Ports

UDP 9600 and TCP 9600

Addressing

Network / node / unit triplet, inherited from Controller Link

Memory areas

CIO, DM, WR, HR, AR, EM banks

FINS/UDP is connectionless and light, which makes it fast to bring up but easy to lose packets on a busy network. FINS/TCP adds a handshake that assigns the client node number and is the better choice for a gateway that must not drop samples.

On newer NJ and NX controllers, prefer EtherNet/IP or the built-in OPC UA server (NX102 and NJ501-1500 class). FINS is still supported but Omron has clearly moved its integration story to CIP and OPC UA.

# All FINS traffic, either transport
omron

# UDP variant only
udp.port == 9600

# TCP variant, including the node-address handshake
tcp.port == 9600

# Omron NJ/NX speaking EtherNet/IP instead
enip && ip.addr == 192.168.250.1

8. Beckhoff ADS / AMS

Port

TCP 48898; UDP 48899 for route and broadcast discovery

Addressing

AmsNetId (six octets, usually IP + .1.1) plus an AMS port — 851 for TwinCAT 3 PLC runtime

Access

By symbol name or by index group / index offset handle

ADS is a genuinely good integration protocol: symbolic access, notifications instead of polling, and free client libraries for .NET and Python. The catch is routing. Both sides need a static ADS route configured, and a gateway that cannot be added to the TwinCAT route table will not connect regardless of firewall rules.

Use ADS notifications rather than cyclic reads where you can. The runtime pushes on change, which cuts both network load and CPU load on the IPC.

# All ADS/AMS traffic
ams || ads

# The main runtime port
tcp.port == 48898

# Route discovery and broadcast search
udp.port == 48899

# Notification traffic only (push, not poll)
ads.cmd == 8

# ADS errors — non-zero result codes
ads.result != 0

9. EtherCAT

Stack

Layer 2 only, EtherType 0x88A4; a single frame processed on the fly by every slave

Cycle

Commonly 250 µs to 4 ms; distributed clocks for sub-microsecond sync

Mailbox

CoE (CANopen over EtherCAT), SoE, FoE, EoE for tunnelled Ethernet

EtherCAT is a fieldbus, not a network you integrate with. There is no IP address to point a gateway at, and the frame is a moving buffer rather than a set of addressable tags. The correct integration point is the master: TwinCAT, an Omron NJ or a CODESYS runtime, which exposes the process image upward over ADS, EtherNet/IP or OPC UA.

Capturing it needs a mirror port or a tap on the segment between master and first slave, and the volume is large. Filter hard or you will fill the buffer in seconds.

# All EtherCAT frames
ecat

# Mailbox traffic — CoE parameter access, firmware transfer
ecat_mailbox

# Raw EtherType if the dissector is not enabled
eth.type == 0x88a4

# EtherCAT tunnelled over UDP (rare, routed setups)
udp.port == 34980

10. BACnet/IP

Port

UDP 47808 (0xBAC0); additional networks often use 47809-47823

Objects

Analog Input, Analog Value, Binary Input, Trend Log, Device

Services

ReadProperty, ReadPropertyMultiple, COV subscription, Who-Is / I-Am

On an energy monitoring project, BACnet is where HVAC load lives — chiller kW, AHU status, pump speed. Ignoring it usually means ignoring the single biggest electrical load in the building.

Use ReadPropertyMultiple rather than individual reads; BACnet devices are slow and a per-object poll on a 300-point system will not complete inside a one-minute interval. Where the device supports COV, subscribe instead of poll.

# All BACnet application-layer traffic
bacapp

# Device discovery — Who-Is broadcasts
bacapp.type == 1 && bacapp.unconfirmed_service == 8

# Reads only
bacapp.confirmed_service == 12 || bacapp.confirmed_service == 14

# Change of value notifications
bacapp.confirmed_service == 1

# Everything on the BACnet port including BVLC forwarding
udp.port == 47808

11. CODESYS V3 runtime and gateway

Gateway

TCP 1217

Scan / discovery

UDP 1740-1743

Block driver

TCP 11740 upward where the gateway is bypassed

Web visualisation

TCP 8080 by default

CODESYS is not a vendor; it is the runtime inside a long list of vendors' controllers — WAGO, Schneider M262, Festo, Eaton, Bosch Rexroth, Beckhoff's older CoDeSys 2 products and dozens of OEM machines. If a controller's programming tool looks like CODESYS, you can often integrate through the runtime's own OPC UA server rather than hunting for a vendor driver.

That OPC UA server is the point of the exercise. CODESYS V3 ships a symbol-configuration-driven UA server, so you publish exactly the variables you choose, with real data types, and the IT side never touches a proprietary port.

# Gateway sessions from the development environment
tcp.port == 1217

# Controller discovery on the subnet
udp.port >= 1740 && udp.port <= 1743

# Direct block-driver connections
tcp.port == 11740

# What you actually want to see after commissioning
opcua && tcp.port == 4840

OPC UA — the conversion point

OPC UA is the only protocol on this page that belongs to both worlds. It speaks a machine-readable information model, so a client discovers what a server offers instead of being handed a register map in a spreadsheet, and it carries security as part of the specification rather than as a firewall rule bolted on afterwards.

Three things to specify on every project: security mode (SignAndEncrypt, not None, even inside the plant), a certificate trust process that someone owns, and subscription-based monitored items instead of cyclic reads. A publishing interval of one second with a deadband costs a fraction of the bandwidth of polling every tag every second.

Where the server sits matters more than which product it is. An aggregating server in the DMZ collects from ten controllers and presents one namespace upward, so the enterprise has one endpoint, one certificate and one firewall rule to manage.

# All OPC UA binary traffic
opcua

# Session and connection establishment
opcua.transport.type == "HEL" || opcua.transport.type == "ACK"

# Service faults — where certificate rejections show up
opcua.StatusCode != 0

# Standard and alternative endpoints
tcp.port == 4840 || tcp.port == 48010 || tcp.port == 62541

MQTT and Sparkplug B — the telemetry path

MQTT inverts the polling model. The gateway publishes on change to a broker, and any number of consumers subscribe without touching the controller. For sites on a metered cellular or shared WAN link this alone justifies the architecture.

Plain MQTT carries whatever payload you put in it, which in practice means every integrator invents a different JSON shape. Sparkplug B fixes that: a defined topic namespace, birth and death certificates so a consumer knows a device's full tag list and its online state, and a compact binary payload. If the platform supports it, use it.

Always run TLS on 8883 and use client certificates or per-device credentials. An MQTT broker on 1883 with anonymous access is a plant-wide data leak.

# All MQTT
mqtt

# Publish messages only
mqtt.msgtype == 3

# One topic branch
mqtt.topic contains "spBv1.0"

# Connection attempts and their return codes
mqtt.msgtype == 1 || mqtt.msgtype == 2

# Encrypted broker traffic — handshake only, payload is not readable
tcp.port == 8883 && tls.handshake.type == 11

REST over HTTPS and JSON

REST is the right tool for request/response integration: pulling a production order from MES, pushing a shift summary to ERP, querying an asset register. It is the wrong tool for high-rate telemetry, because every sample costs a full TLS-protected round trip.

Design the JSON contract before writing the gateway configuration. Fix the field names, the unit of every value, the timestamp format (ISO 8601 with offset, always) and whether a missing tag appears as null or is omitted. Changing this after the dashboard is live is expensive.

{
  "device": "EM-GRN-P1-01",
  "ts": "2026-09-19T14:32:00+05:30",
  "quality": "good",
  "metrics": {
    "kWh_import": 148237.45,
    "kW_total": 62.18,
    "pf_avg": 0.94,
    "V_ll_avg": 411.2,
    "I_avg": 87.4
  }
}

# API calls to the platform
http.request.method == "POST" && http.host contains "api"

# Error responses
http.response.code >= 400

# JSON bodies in the clear (HTTP, not HTTPS)
json

# A named field inside the payload
json.key == "kWh_import"

ODBC, JDBC and SQL Server TDS

ODBC and JDBC are driver layers, not wire protocols. What actually crosses the network is the database's own protocol — TDS for Microsoft SQL Server, and TDS is what you filter on when a historian insert is failing.

For an energy historian, the pattern that holds up is a narrow tall table (tag id, timestamp, value, quality) with a clustered index on timestamp, written by the gateway in batches, and read by reporting through stored procedures rather than by direct table access. Give the gateway an account with insert rights on one schema and nothing else.

Keep the gateway's database connection inside the DMZ or Level 3. A cloud service holding an open ODBC session into a plant database is a finding waiting to happen in any IEC 62443 assessment.

# SQL Server traffic
tds

# Login attempts (TDS7 pre-login and login packets)
tds.type == 18 || tds.type == 16

# SQL batches — see what the gateway is actually sending
tds.type == 1

# Instance discovery via SQL Browser
udp.port == 1434

AMQP, Kafka and WebSocket

AMQP gives you queues with acknowledgement and dead-lettering, which matters when a message must not be lost — a batch completion record, a quality result, a billing-grade energy reading. It is the native protocol for Azure Service Bus and RabbitMQ, and the natural next hop when MQTT telemetry has to become a durable business event.

Kafka is for volume and replay. If the analytics team wants to reprocess six months of one-second data with a new model, Kafka's retained log makes that possible; a broker that only forwards live messages does not.

WebSocket is the display layer. A browser dashboard that polls a REST endpoint every second is doing the wrong thing; upgrade the connection once and push.

# Message broker traffic
amqp
kafka

# WebSocket upgrade handshake, then the frames
http.upgrade == "websocket"
websocket

# Text frames only
websocket.opcode == 1

NTP, PTP and the supporting layer

Time synchronisation is the requirement everyone leaves out of the scope document and everyone needs. If the gateway, the SCADA server and the database disagree by thirty seconds, interval energy figures will not reconcile with the utility bill and nobody will be able to explain why.

NTP to a site server is sufficient for energy monitoring at one-minute resolution. PTP is needed where events must be ordered at sub-millisecond precision — sampled values in a substation, or high-speed sequence-of-events recording.

SNMP and Syslog sit underneath all of it. Poll the managed switches, the UPS and the gateway itself, and send logs to the same collector the IT team already watches. Most "data gaps" turn out to be a switch port flapping or a gateway rebooting, and neither is visible in the historian.

# Time sync
ntp
ptp

# Devices whose clock is drifting or unsynchronised
ntp.flags.mode == 4 && ntp.stratum > 4

# Infrastructure health
snmp
snmp.data.trap
syslog