OT Protocols — A Practical Map of Industrial Communication

A controller, a protective relay, a building-management system, and a historian all exchange information. They do not necessarily speak the same language, need the same timing, or attach the same meaning to a value.

Learning OT protocols is not an exercise in memorizing port numbers. Start with what is being communicated, between which roles, over which medium, and with what operational consequence. A command to a drive is not the same service as a manufacturing dashboard reading production counts.

This is an introductory map, not an exhaustive catalog or a configuration guide. Protocol features vary by edition, device, profile, and deployment. For the industry context, see where OT lives; for the rules surrounding it, see OT governance and compliance.

First separate the layers

• Medium and network: copper, fiber, radio, serial links, Ethernet, and IP describe different parts of the path. Ethernet does not mean Internet access, and not all Ethernet traffic uses IP.
• Communication service: polling values, cyclic input/output, sending events, transferring a file, or issuing a command.
• Information model: the meaning of the data. A register containing 250 is not useful until the team knows its type, scaling, units, quality, and timestamp.
• Security and operations: who may communicate, which actions are permitted, how identities are managed, and what happens when communications fail.

One installation can use several families at once. A gateway may translate a fieldbus into an Ethernet service, and a historian may collect data through OPC. Translation is not automatically a security boundary: it can introduce a new route for commands or remove information such as timestamps and quality.

Modbus: simple data exchange, application-specific meaning

Modbus exposes data through concepts such as coils, discrete inputs, input registers, and holding registers. Function codes identify operations such as reading values or writing supported data. Devices still need a documented register map: addressing conventions, multi-register word order, scaling, and units are frequent integration traps.

Modbus RTU and Modbus ASCII use serial framing; RTU is often encountered on RS-485 networks. Modbus TCP carries Modbus messages over TCP/IP. A serial-to-TCP gateway does not make the serial devices themselves IP endpoints.

Traditional Modbus does not provide native cryptographic authentication or encryption. The separate Modbus Security specification adds TLS and certificate-based protection. Do not assume a device advertising “Modbus TCP” implements that specification or that a secure gateway protects every downstream segment.

Ask: is this client only observing, or can it change outputs and setpoints? Which register map and security mode are actually deployed?

Source: Modbus Organization specifications.

PROFIBUS and PROFINET: related ecosystem, different networks

PROFIBUS is a fieldbus family used in factory and process automation. PROFIBUS DP commonly connects controllers and distributed peripherals; PROFIBUS PA supports process instrumentation with a process-oriented physical layer and device profiles. They are not interchangeable cable choices, even where the underlying communication concepts are related.

PROFINET is a separate industrial Ethernet technology from the same PI ecosystem. It supports automation communication with different real-time capabilities. Some real-time traffic operates directly over Ethernet rather than as ordinary TCP application traffic. A firewall inspecting routed IP alone cannot describe everything happening on a local automation network.

Ask: which device profiles, timing requirements, engineering files, and physical segments are needed to restore this network? A running Ethernet switch is not proof that cyclic I/O has recovered.

Sources: PI's PROFIBUS overview and technologies.

EtherNet/IP, ControlNet, and DeviceNet: the CIP family

ODVA's Common Industrial Protocol (CIP) provides an object-and-service model across several network technologies. Objects have attributes and services; messages can represent data access, configuration, or control.

CIP Security provides security capabilities for supported implementations, notably EtherNet/IP devices. It is not automatically enabled on every CIP device. CIP Safety serves a different purpose: functional-safety communication is not a substitute for cybersecurity authentication and access control.

Also, ODVA's CIP means Common Industrial Protocol. NERC CIP means Critical Infrastructure Protection. The shared acronym does not establish a technical or regulatory relationship.

Sources: ODVA's CIP overview, specification families, and CIP Security.

DNP3 and IEC 60870-5: supervisory communication over distance

DNP3, standardized in IEEE 1815, is widely associated with utility telemetry and supervisory control. Control-center systems exchange information with outstations, often at remote sites. Event reporting, timestamps, and quality information help explain what happened when a link was interrupted. DNP3 can operate over serial or IP-based communications.

DNP3 security extensions exist, including Secure Authentication. Treat authentication and confidentiality as separate questions, and verify the actual security version and implementation; older Secure Authentication deployments should not be assumed to encrypt all traffic.

The IEC 60870-5 series includes several telecontrol specifications. IEC 60870-5-101 is commonly associated with serial telecontrol; IEC 60870-5-104 provides network access using standard transport profiles over TCP/IP. They are not merely two port settings for the same installation.

Ask: which commands are allowed, how are old events distinguished from current state, and how does the control center behave when a remote link returns? A timestamp is useful only if its source and clock behavior are understood.

Sources: DNP Users Group overview and IEC's communication-security overview.

IEC 61850: more than one protocol

IEC 61850 is a standards series covering power-utility automation, including information models, communication services, and engineering configuration. Calling it simply “the substation protocol” hides important differences.

• MMS-based services support exchanges such as reporting and supervisory interactions.
• GOOSE supports event-oriented peer messaging, including time-sensitive protection and interlocking applications.
• Sampled Values carry sampled measurement information in relevant architectures.
• SCL, the System Configuration description Language, represents engineering configuration; it is not live process traffic.

Common local GOOSE and Sampled Values mappings use Ethernet frames rather than TCP connections. Other mappings exist, so examine the actual design instead of applying one network assumption to the whole series.

The IEC 62351 series addresses security for power-system communications, including relevant IEC 61850 and IEC 60870 profiles. Support must be checked per part and product. A label saying “IEC 61850 compliant” does not establish that the security features needed by a particular site are implemented, configured, or maintained.

Sources: IEC's 61850 technical principles and 62351 overview.

BACnet, KNX, and LonTalk: building automation is OT too

BACnet is a building-automation communication standard, published as ASHRAE 135 and ISO 16484-5. Its objects and services describe equipment information such as values, schedules, and alarms. BACnet/IP and BACnet MS/TP use different network arrangements; MS/TP is commonly associated with an RS-485 field network.

BACnet Secure Connect (BACnet/SC) adds a secure communication option using TLS and certificates. Connecting a BACnet/SC network to legacy BACnet segments does not extend encryption magically onto those segments. Routers, certificate renewal, and communication dependencies still need ownership.

KNX is used for distributed building functions such as lighting, blinds, and HVAC. Its ecosystem includes twisted-pair, radio, and IP communication. KNX IP Secure and KNX Data Secure protect different aspects of communication; product support, commissioning, and key handling determine what is protected in the actual installation.

LonTalk, associated with the LonWorks ecosystem, is a control-network protocol standardized within the ISO/IEC 14908 family. LonMark interoperability profiles and standardized network variables help devices exchange meaningful information. Existing building systems may rely on network bindings, engineering tools, and gateways that are not obvious from an IP asset inventory.

Ask: who owns the control logic, the engineering project, and the gateway—the facilities team, landlord, systems integrator, or IT? Can the building still maintain an appropriate local function when the supervisory system disappears?

Sources: BACnet/SC overview, KNX Data Secure, and LonMark standards.

OPC: software interoperability, not just a wire protocol

OPC often connects control-system data to operator applications, historians, and integration services. It helps to distinguish the specifications rather than treating them as sequential versions of the same product.

Classic DA, AE, and HDA rely on COM/DCOM. OPC UA is a different architecture, not simply “DA with a new port.” UA includes client/server and PubSub communication models, and companion specifications add shared domain meaning.

UA supports security mechanisms such as application certificates, message signing and encryption, and user authentication. The endpoint policy, trusted certificates, identities, and permissions still need deliberate configuration. “It uses OPC UA” does not prove that anonymous access or insecure modes are disabled.

Sources: OPC Foundation's Classic overview, Classic specifications, and Unified Architecture.

MTConnect and other names worth recognizing

MTConnect provides standardized manufacturing-equipment information, using a common vocabulary and data model. Its core monitoring model is for data collection, not commanding a machine to move. An adapter/agent path can still create dependencies and expose operational information; “read-only data” does not mean the surrounding software requires no security.

Other technologies you may meet include:

• HART and WirelessHART: process-instrument communication, including configuration and diagnostics; classic wired HART can coexist with a 4–20 mA signal.
• FOUNDATION Fieldbus: digital process instrumentation and control communication, with distinct H1 and High Speed Ethernet arrangements.
• EtherCAT: industrial Ethernet communication associated with high-performance machine and motion applications.
• IO-Link: point-to-point communication with sensors and actuators through a master, not a general-purpose Ethernet network.
• MQTT and Sparkplug: broker-based messaging and, for Sparkplug, conventions for industrial data and state. They do not replace every real-time controller network.
• ICCP / TASE.2: control-center information exchange in the IEC 60870-6 family, distinct from IEC 60870-5-104.
• Vendor-specific services, such as Siemens S7 communication: product family, generation, and engineering functions matter as much as the broad protocol label.

This list describes roles, not a ranking. A technology suited to supervisory data is not automatically a replacement for a time-sensitive protection or motion-control path. Start with the MTConnect Institute, the relevant technology association, and the installed product's documentation when investigating a specific implementation.

Where ISA/IEC 62443 fits

The ISA/IEC 62443 series—often shortened to ISA-62443—is cross-industry guidance and requirements for industrial automation and control-system cybersecurity. It is not another communication protocol.

Its lifecycle approach connects asset-owner programs, service-provider responsibilities, system risk assessment, and secure product development. Zones group assets with common security requirements; conduits describe controlled communication between zones. A VLAN alone does not establish a completed zone-and-conduit risk assessment.

Useful starting parts include 2-1 for asset-owner security programs, 2-4 for service providers, 3-2 for system-design risk assessment, 3-3 for system security requirements, 4-1 for secure product development, and 4-2 for component requirements. Read the applicable edition and scope rather than treating the series as one checklist.

The series helps ask which communication is necessary, who is responsible, and what protection is required. It does not make a legacy protocol secure simply because the network diagram mentions it. Whether a standard is mandatory depends on legal, contractual, and organizational adoption; that distinction is explored in the governance article.

Source: ISA/IEC 62443 series overview.

A practical way to investigate any protocol

For each communication path, record:

1. The physical function, endpoints, and accountable owner.
2. The medium, protocol edition/profile, and engineering dependencies.
3. Whether the path reads, writes, configures, or carries protection-related information.
4. Timing, stale-data behavior, quality indicators, and loss-of-communication behavior.
5. Actual authentication, authorization, encryption, and key/certificate lifecycle—not just advertised support.
6. What evidence would demonstrate recovery: correct values, timestamps, alarms, permissions, and process behavior.

Use approved documentation, engineering projects, and authorized passive observation first. Active discovery, test writes, and protocol changes on operating equipment need site approval and an engineering plan. This article is not permission to experiment on a live process.

The batch explorer demonstrates stale display information without sending any industrial traffic. It is a useful reminder of the underlying lesson: a message arriving is not the same as a trustworthy process picture.