Connecting Siemens S7 and Allen-Bradley PLCs to Your SCADA Without Kepware

Here is a scenario every system integrator recognizes. You land a project at a manufacturing plant. The production line runs on a Siemens S7-1200. The packaging area uses an Allen-Bradley CompactLogix. The utilities building still has an old S7-300 chugging along. The client wants everything on one dashboard. Your SCADA software speaks Modbus TCP and OPC-UA natively. Neither Siemens nor Allen-Bradley speak either of those without translation.

So you buy Kepware. Or Matrikon. Or some other OPC server. And the protocol tax begins.

The Real Cost of PLC Connectivity

Most SCADA platforms do not speak Siemens S7 or Allen-Bradley EtherNet/IP natively. They speak OPC-UA, Modbus TCP, or MQTT. The PLCs speak their own proprietary protocols. Something has to sit in the middle and translate. That something is usually an OPC server like KEPServerEX from PTC (formerly Kepware).

KEPServerEX is a solid product. It does what it says on the box: it connects to hundreds of PLC brands and exposes their data via OPC-UA, OPC-DA, and other standard interfaces. But the pricing model is where integrators feel the pain.

KEPServerEX Pricing Structure

KEPServerEX sells protocol drivers individually. Each PLC brand is a separate driver, and each driver is a separate line item on the quote. Ballpark numbers from integrator reports:

• Base KEPServerEX license: $500 - $1,500 depending on tag count tier
• Siemens S7 Suite driver: $1,000 - $2,000
• Allen-Bradley EtherNet/IP driver: $1,000 - $2,000
• Modbus TCP/RTU driver: $800 - $1,500
• MQTT agent: $500 - $1,000
• OPC-UA server: included in base, but client access may require additional licensing

For a plant with Siemens and Allen-Bradley PLCs, you are looking at $3,000 to $5,000 in OPC server licensing alone, on top of whatever your SCADA software costs. And that is before annual maintenance fees, which typically run 15-20% of the purchase price.

Siemens S7 Protocol: What You Are Actually Talking To

Siemens PLCs communicate using the S7 protocol, which runs over ISO-on-TCP (RFC 1006). This is not plain TCP. It is not Modbus. It is a Siemens-specific session layer that establishes a connection, negotiates parameters, and then exchanges S7 telegrams for reading and writing PLC memory areas.

Supported Siemens PLC Families

The S7 protocol family covers the full range of Siemens controllers that most integrators encounter in the field. For a deeper technical breakdown of memory areas, addressing, and data types, see our S7 communication protocol guide.

• S7-300 and S7-400: The legacy workhorses. Still deployed in thousands of plants worldwide. S7-300s run everything from injection molding machines to baggage handling systems. They use the original S7 communication protocol over both MPI (Multi-Point Interface) and Ethernet via CP (Communications Processor) modules.
• S7-1200: The current compact controller line. S7-1200s are the go-to for small to mid-size applications: HVAC control, water treatment, packaging machines, conveyor systems. They support S7 communication natively over their built-in Ethernet port. No extra communication module needed.
• S7-1500: Siemens' flagship controller. The S7-1500 series supports both the classic S7 protocol and the newer optimized S7-1500 communication mode, which allows larger block reads and faster data transfer. If you are connecting to a modern Siemens plant, this is likely what you will find on the main production lines.

Connecting to any of these from a standard SCADA means either purchasing the Siemens S7 driver for your OPC server or using a SCADA platform that has the S7 protocol built in. Most do not. For integrators working on macOS, connecting to Siemens S7-1200 and S7-1500 PLCs without TIA Portal is possible using third-party S7 client libraries that implement the protocol directly.

Allen-Bradley EtherNet/IP: CIP Protocol in Practice

Allen-Bradley (Rockwell Automation) PLCs use EtherNet/IP, which is an industrial application of the Common Industrial Protocol (CIP) running over standard TCP/UDP. Despite the name similarity, EtherNet/IP has nothing to do with the internet protocol suite. It is Rockwell's proprietary (though now semi-open) protocol for accessing controller tags, reading/writing data, and managing controller state. For integrators who need to explore EtherNet/IP devices from macOS or Linux, understanding the CIP stack is essential.

Supported Allen-Bradley Controller Families

• ControlLogix (1756 series): The premium line. Found in automotive plants, pharmaceutical manufacturing, and large process control applications. ControlLogix controllers support tag-based addressing (you read tags by name, not by memory address), which makes integration cleaner but requires the SCADA to understand CIP tag services.
• CompactLogix (1768/5380/5480 series): The mid-range controller. CompactLogix is extremely common in machine building, packaging, and material handling. Same CIP protocol as ControlLogix, same tag-based addressing, smaller form factor. If you are doing Allen-Bradley integration, this is the controller you will see most often.
• MicroLogix (1100/1400 series): The small-footprint controller. MicroLogix uses an older addressing model based on data files (N7:0, F8:0, etc.) rather than named tags. The CIP protocol handles these differently, and some OPC servers charge for a separate MicroLogix/SLC driver on top of the standard EtherNet/IP driver.

The key technical detail for integrators: Allen-Bradley tag-based controllers expose their tag database over CIP. You do not need to know memory addresses. You connect to the controller, browse the tag list, and subscribe to the tags you need. This is elegant, but it means your SCADA or OPC server needs a full CIP stack implementation, including Forward Open/Close requests, unconnected message routing, and tag segment encoding. It is not something you build in a weekend.

Why Most SCADA Requires a Separate OPC Server

The reason most SCADA platforms do not include native S7 or EtherNet/IP drivers is straightforward: protocol implementation is expensive. Writing and maintaining a protocol driver requires deep knowledge of PLC programming patterns and controller behavior that most SCADA vendors would rather outsource to OPC server companies.

Each PLC protocol requires reverse-engineering or licensing proprietary communication stacks, maintaining compatibility across firmware versions, handling edge cases in every supported controller model, and providing technical support when a specific PLC firmware update breaks something. That engineering effort costs real money, and most SCADA vendors have decided it is more economical to let OPC server companies specialize in protocol translation while they focus on visualization and data management.

The result is an architecture that looks like this:

• Siemens S7-1200 running the production line
• Allen-Bradley CompactLogix running the packaging area
• Modbus TCP energy meters on the switchgear
• KEPServerEX running on a Windows box, translating all three protocols into OPC-UA
• SCADA software connecting to KEPServerEX via OPC-UA

It works. It is the standard approach. But it adds a Windows server license, OPC server licensing, another process to monitor, another point of failure, and another vendor to call when communication drops at 2 AM.

The Protocol Support Comparison

Here is how the main SCADA and connectivity options compare when it comes to PLC protocol support. This is the table you need when the client asks "what PLC brands do you need to connect to?"

How Protocol Support Affects Buying Decisions

When a plant manager or engineering lead evaluates SCADA software, the conversation almost always hits the same question: "What PLC brands do you need to connect to?"

This is not a casual question. It is the question. The answer determines whether the project budget absorbs $3,000-$6,000 in OPC server licensing or whether the SCADA handles it natively. For system integrators bidding on projects, protocol support directly affects your competitiveness. If your SCADA stack requires a separate Kepware license for every PLC brand, your bid includes that cost. The integrator using a SCADA with native multi-protocol support does not carry that line item.

Consider a realistic bid scenario: a food processing plant with a Siemens S7-1200 on the pasteurizer, an Allen-Bradley CompactLogix on the packaging line, and Modbus TCP flow meters on the utility water system. Three protocols. The client wants a single dashboard with live readings and historical trends.

Bid Comparison: Same Project, Different Stacks

The integrator using Voltrus Enterprise can bid $8,000 to $12,000 less on the same project and still maintain the same margin. Or they can match the competitor's price and keep the difference. Either way, native multi-protocol support is a structural cost advantage that compounds with every PLC brand the plant uses.

Voltrus Enterprise: Multi-Protocol Without the Middleware

Voltrus Enterprise is the license tier that includes native Siemens S7 and Allen-Bradley EtherNet/IP drivers alongside Modbus TCP, MQTT, and OPC-UA. It is $999 per deployment, lifetime. No per-protocol surcharges. No annual renewals. No separate OPC server to install, configure, and maintain.

The protocols are implemented as native drivers within the Voltrus binary. No Java runtime, no Windows dependency, no separate service to manage. The same process that polls your Modbus devices also connects to your Siemens S7-1200 and your Allen-Bradley CompactLogix. Configuration is done through the same interface. Data from all protocols flows into the same tag database and appears on the same dashboards.

What You Get for $999

• Modbus TCP: Poll registers from any Modbus TCP device. Energy meters, VFDs, temperature controllers, I/O modules.
• MQTT: Subscribe to MQTT topics from IoT gateways, wireless sensor networks, or cloud bridges. Publish SCADA data to MQTT brokers.
• OPC-UA Server: Expose all collected data as OPC-UA nodes. Other OPC-UA clients on the plant network can subscribe to your data without additional configuration.
• OPC-UA Client: Connect to any OPC-UA server on the network. Pull data from existing OPC-UA infrastructure.
• Siemens S7: Native ISO-on-TCP (RFC 1006) driver supporting S7-300, S7-400, S7-1200, and S7-1500 controllers. Read and write DB blocks, I/O areas, markers, and timers.
• Allen-Bradley EtherNet/IP: Native CIP driver supporting ControlLogix, CompactLogix, and MicroLogix controllers. Tag-based addressing for Logix controllers, data file addressing for MicroLogix.

All of this in a single binary. Deploy on Linux, deploy on ARM, deploy on a Raspberry Pi sitting inside a cabinet next to the PLC. No Windows server. No JVM. No middleware stack.

The Integration Reality

In a recent research interview with industrial automation professionals, one integrator put it plainly:

This is the lived experience of system integrators worldwide. Multi-protocol plants are the norm, not the exception. A single production line might have a Siemens PLC running the process, an Allen-Bradley PLC handling the packaging, Modbus energy meters on the power distribution, and an MQTT gateway bridging wireless vibration sensors. Expecting a plant to standardize on one PLC brand is unrealistic. The equipment comes from the OEM that won the bid for each machine, and each OEM has their preferred controller.

What integrators need is a SCADA that handles this reality without penalizing them for it. Not a SCADA that works great as long as you only use Modbus. Not a SCADA that requires a $3,000 middleware stack the moment a Siemens PLC appears on the network. A SCADA that connects to what is there, regardless of brand, and gets the data onto a dashboard without drama.

That is the design intent behind Voltrus Enterprise's multi-protocol architecture. Connect to what the plant has. Do not dictate what the plant should have.

Technical Notes: S7 and EtherNet/IP Implementation

For integrators who want to understand what happens under the hood, here are the relevant technical details.

Siemens S7 Connection

Voltrus connects to Siemens PLCs using ISO-on-TCP (RFC 1006) over port 102. The connection sequence follows the standard S7 communication handshake: TCP connect, COTP connection request, COTP connection confirm, S7 setup communication (negotiating PDU size and max AMQ), then S7 read/write job telegrams. The driver supports reading from and writing to all standard S7 memory areas: DB (data blocks), I (inputs), Q (outputs), M (markers), T (timers), and C (counters). S7-1500 optimized blocks are supported.

Allen-Bradley EtherNet/IP Connection

Voltrus connects to Allen-Bradley controllers using CIP over EtherNet/IP on port 44818 (TCP) and 2222 (UDP). For Logix-class controllers (ControlLogix, CompactLogix), the driver performs a Forward Open request to establish a session, then reads tag values using CIP tag services. For MicroLogix controllers, the driver uses unconnected messaging to access data files by type and offset. The driver handles the CIP connection path routing required for ControlLogix systems with multiple backplane modules.

Coexistence

All protocol drivers run concurrently within the same process. Modbus polling happens on one schedule. S7 reads happen on another. EtherNet/IP subscriptions run independently. MQTT messages arrive asynchronously. The tag database unifies data from all sources into a single namespace. Dashboards display mixed-source data without any indication of which protocol delivered which value. That is how it should be. The integrator should not have to care about protocol boundaries when building a dashboard.

Frequently Asked Questions

Do I need Kepware to connect Siemens S7 PLCs to SCADA?

Not necessarily. While KEPServerEX is the most common OPC server used to translate Siemens S7 protocol for SCADA systems, it adds $1,500-2,000 per driver plus a base license of $500-1,500. Voltrus Enterprise includes a native Siemens S7 driver supporting S7-300, S7-400, S7-1200, and S7-1500 controllers without requiring a separate OPC server. The total cost is $999 lifetime for all protocols combined.

What protocol do Allen-Bradley PLCs use for SCADA communication?

Allen-Bradley PLCs use EtherNet/IP, which is an industrial application of the Common Industrial Protocol (CIP) running over TCP/UDP on port 44818. ControlLogix and CompactLogix controllers support tag-based addressing where you read tags by name rather than memory address. MicroLogix controllers use an older data file addressing model (N7:0, F8:0, etc.). A SCADA connecting to Allen-Bradley controllers needs a full CIP stack implementation.

How much does it cost to connect both Siemens and Allen-Bradley PLCs to SCADA?

With Kepware plus a SCADA platform like Ignition, the total 5-year cost for connecting Siemens S7, Allen-Bradley EtherNet/IP, and Modbus TCP runs $9,200-$13,500 including software, drivers, Windows licensing, and server costs. With Voltrus Enterprise, all three protocols are included in a single $999 lifetime license with no separate OPC server, no Windows dependency, and no per-protocol surcharges.

Can SCADA connect to Siemens and Allen-Bradley PLCs simultaneously?

Yes. Multi-protocol plants are the norm in industrial environments. Voltrus Enterprise runs all protocol drivers concurrently within the same process. Modbus polling, S7 reads, EtherNet/IP subscriptions, and MQTT messages all operate independently. The tag database unifies data from all sources into a single namespace, so dashboards display mixed-source data without indicating which protocol delivered which value.

What Siemens PLC models are supported for SCADA integration?

The S7 protocol family covers S7-300 and S7-400 (legacy workhorses still in thousands of plants), S7-1200 (current compact controllers for HVAC, water treatment, packaging), and S7-1500 (Siemens flagship supporting both classic S7 protocol and optimized communication with larger block reads). Connection uses ISO-on-TCP (RFC 1006) over port 102.

Further Reading

• Voltrus vs Ignition: An Honest Comparison for System Integrators
• Lightweight SCADA Software: What It Actually Means
• SCADA Software Pricing: Why Lifetime Licenses Beat SaaS