Apache PLC4X

Most industrial controllers speak proprietary protocols. A Siemens PLC speaks S7. A Beckhoff speaks ADS. A Rockwell speaks EtherNet/IP. If your application needs to read data from all three, you traditionally need three vendor-specific SDKs, three sets of documentation, and three integration codepaths.

PLC4X replaces that with one library and one API. You write your application once against the PLC4X API, swap out a connection string to talk to a different PLC type, and the library handles the protocol translation. It speaks the PLC's native protocol directly — no OPC-UA server required on the PLC side, no middleware, no gateway device.

Developed under the Apache Software Foundation since 2017, graduated to Top-Level Project in 2019.

Key features

• Unified API across 15+ industrial protocols — write once, connect to any supported PLC
• Native protocol drivers for S7 (Siemens), ADS (Beckhoff), EtherNet/IP (Rockwell/Allen-Bradley), Modbus TCP/RTU, OPC-UA, BACnet, KNX, CANopen, Firmata, and more
• Multi-language — Java (primary, most complete), Go, Python, and C available with varying protocol coverage
• Direct PLC access without requiring an OPC-UA server on the controller — lower latency, fewer moving parts
• Apache Kafka Connect adapter for streaming PLC data directly into Kafka topics
• Can also act as an OPC-UA server, exposing non-OPC-UA PLCs to OPC-UA clients

What Apache PLC4X does

PLC4X is a library, not a standalone application. You embed it in your software — a custom data collector, a Kafka Connect pipeline, an Apache StreamPipes adapter, or an Eclipse BaSyx data provider.

The core abstraction is a PlcConnection. You open a connection with a protocol-specific URL (s7://192.168.1.10/0/1 for a Siemens S7-1500, modbus-tcp://192.168.1.20 for Modbus), then read or write tags using a common API regardless of the underlying protocol. The library handles connection management, protocol encoding/decoding, and type conversion.

Protocol support varies by language. Java has the most drivers (15+). Go, Python, and C are catching up but currently support fewer protocols — check the compatibility matrix on the PLC4X website before committing to a non-Java implementation.

Performance advantage over OPC-UA

PLC4X reads data directly using the PLC's native protocol, which typically offers lower latency than going through an OPC-UA server layer. On many PLCs, the OPC-UA server is an afterthought — an application running on the same CPU that internally uses the native protocol anyway. PLC4X cuts out that intermediary. This matters for time-sensitive data collection at sub-second intervals.

Why choose Apache PLC4X

• No PLC-side changes required — reads data from controllers as-is, using protocols they already speak. No firmware updates, no OPC-UA server activation, no new software on the PLC
• Apache-2.0 license — permissive, embed in commercial products without copyleft concerns
• The integration backbone for other open-source IIoT tools: StreamPipes uses PLC4X for its S7 and Modbus connectivity, BaSyx uses it for data provider components
• Eliminates vendor-specific SDK dependencies — one library replaces Siemens SNAP7, Beckhoff TwinCAT SDK, Rockwell CIP libraries

Getting started

PLC4X is a library — you add it as a dependency, not install it as a service.

Java (Maven):

<dependency>
    <groupId>org.apache.plc4x</groupId>
    <artifactId>plc4j-driver-s7</artifactId>
    <version>0.12.0</version>
</dependency>

Minimal read example:

try (PlcConnection conn = PlcDriverManager.getDefault()
        .getConnectionManager()
        .getConnection("s7://192.168.1.10/0/1")) {
    PlcReadResponse response = conn.readRequestBuilder()
        .addTagAddress("temp", "%DB1.DBD0:REAL")
        .build().execute().get();
    float temperature = response.getFloat("temp");
}

If you don't want to write code, the Kafka Connect adapter lets you stream PLC data into Kafka by writing a JSON config file — no custom application needed. StreamPipes also uses PLC4X under the hood, providing a no-code UI on top.

Technical specs

• Java 11+ (primary SDK), Go, Python, C implementations with varying maturity
• Maven build system, modular driver architecture (include only the protocols you need)
• Each protocol driver is a separate Maven artifact — keeps dependencies minimal
• Connection pooling and auto-reconnection built into the connection manager
• Supports read, write, subscribe (where the protocol supports it), and browse operations

Limitations

• Protocol support varies significantly by language. Java has 15+ drivers. Python and Go have fewer, and some are experimental. Check the compatibility matrix before choosing a non-Java implementation.
• This is a library, not a turnkey solution. You need to write code (or use a tool like StreamPipes/Kafka Connect that wraps it). If you want a GUI for PLC data, look at Node-RED with the S7 or Modbus nodes instead.
• Some protocol drivers are more mature than others. S7, Modbus, and EtherNet/IP are production-ready. Newer drivers (KNX, CANopen, Firmata) are functional but less battle-tested.
• Documentation quality is uneven. The core concepts are well-documented, but individual driver docs range from thorough (S7) to sparse (newer protocols).
• The project has 109 contributors but the core team is small. Complex protocol issues may take time to get resolved.