{"data":{"slug":"kepware-driver-selection-architecture","title":"Kepware Driver Selection and Channel/Tag Architecture","summary":"KEPServerEX is the most widely deployed industrial connectivity platform: it converts dozens of native protocols — Siemens, Allen-Bradley, Modbus, DNP3…","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/kepware-driver-selection-architecture","markdown_url":"https://wiki.aspotomasyon.com/article/kepware-driver-selection-architecture.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/kepware-driver-selection-architecture","published":"2026-08-11T13:05:19+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":921,"image":"https://wiki.aspotomasyon.com/assets/social/kepware-driver-selection-architecture-22591e1f10b4.png","html":"<p>KEPServerEX is the most widely deployed industrial connectivity platform: it converts dozens of native protocols — Siemens, Allen-Bradley, Modbus, DNP3, BACnet, and hundreds more — into OPC UA, OPC DA, MQTT, and REST interfaces for SCADA, MES, and IIoT applications. The architecture looks simple (channels → devices → tags), but the decisions made when creating channels and tags determine reliability, performance, and troubleshooting ease for the life of the integration. Getting the architecture right at the start is the single biggest success factor.</p><figure class=\"article-figure\"><img src=\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-context.svg\" width=\"1100\" height=\"460\" loading=\"lazy\" decoding=\"async\" alt=\"A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.\"><figcaption>A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do. <a href=\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-context.svg\" target=\"_blank\" rel=\"noopener\">View full size</a></figcaption></figure>\n\n<h2 id=\"driver-selection\">Driver Selection</h2>\n\n<p>Selecting the right driver is the first architecture decision. Consider in order:</p>\n\n<ol>\n  <li><strong>Native protocol availability</strong> — always prefer the device's native driver over a generic one. A Siemens S7 driver speaking the native S7 protocol beats a Modbus-TCP fallback in speed, diagnostics, and data coverage.</li>\n  <li><strong>Driver generation</strong> — current KEPServerEX drivers are grouped by protocol generation (e.g., Siemens TCP/IP Ethernet, Allen-Bradley ControlLogix Ethernet, Modbus TCP/IP); newer \"Suite\" drivers manage multiple device models in one channel. Use the compatibility tables in the driver help to pick the model that matches the firmware.</li>\n  <li><strong>Channel capacity</strong> — each channel is one communication task (one thread). Very fast polling needs a dedicated channel; a channel holding dozens of slow devices is fine.</li>\n  <li><strong>Redundancy options</strong> — if the device supports it (e.g., ControlLogix Redundancy, S7 with failover), configure it at channel level so the client sees one stable tag set.</li>\n  <li><strong>Diagnostics features</strong> — native drivers typically expose richer device-level status (communication health, counters) that the generic drivers cannot.</li>\n</ol>\n\n<h2 id=\"channel-design-rules\">Channel Design Rules</h2>\n\n<ul>\n  <li><strong>One channel per communication type</strong> — group devices by protocol, network segment, and polling characteristics. Mixing a fast motion controller and a slow metering device in one channel couples their performance.</li>\n  <li><strong>Separate critical and bulk traffic</strong> — a channel polling 2,000 register points at 100 ms starves nothing if it is alone; sharing that channel with slow serial devices forces compromise polling rates.</li>\n  <li><strong>Use request timeouts and retries deliberately</strong> — short timeouts on fast networks, longer on serial links; excessive retries on a dead device stall the channel's queue.</li>\n  <li><strong>Name channels meaningfully</strong> — the channel name propagates into every tag name and every downstream client. <code translate=\"no\" class=\"notranslate\">PLANT2-LINE1-PLC3</code> is a name; <code translate=\"no\" class=\"notranslate\">CH1</code> is a future support ticket.</li>\n  <li><strong>Serial channels</strong> — one device per channel for RS-232; RS-485 multi-drop is fine, but keep baud rates and parity consistent and terminate the bus properly.</li>\n</ul>\n\n<h2 id=\"tag-architecture\">Tag Architecture</h2>\n\n<p>Tag design determines what the clients see and how hard the system is to maintain:</p>\n\n<ul>\n  <li><strong>Use the model's native addressing</strong> — for S7 use DB/area syntax, for ControlLogix use the tag path; avoid address math in tag names.</li>\n  <li><strong>Group tags hierarchically</strong> — mirror the plant structure (Area → Unit → Equipment → Point). OPC UA browsing of the address space then matches the plant book, and client configuration is trivial.</li>\n  <li><strong>Create typed tags</strong> — use the driver's data types (Boolean, Word, DWord, Float) and let Kepware convert; avoid \"raw value + scaling in the client\" — use the driver's scaling features so every client sees engineering units.</li>\n  <li><strong>Array and block reads</strong> — where the driver supports array reads, map contiguous blocks to array tags instead of thousands of individual tags; performance improves dramatically.</li>\n  <li><strong>Avoid tag duplication</strong> — one tag per point, referenced by all clients. Duplicate channels reading the same PLC registers double the device load for zero benefit.</li>\n  <li><strong>Static vs dynamic tags</strong> — dynamic tags (addressed on the fly) are useful for prototypes; for production, static tags are deterministic and diagnosable.</li>\n</ul>\n\n<h2 id=\"performance-and-capacity-planning\">Performance and Capacity Planning</h2>\n\n<p>KEPServerEX scales well when planned: the polling engine batches requests per device, and the bottleneck is usually the device's own response time, not the server. Rules of thumb: keep the total tag count per channel within the driver's documented guidance; spread high-rate devices across channels; monitor the server's performance counters (poll requests/sec, latency, failures) in the OPC UA diagnostics; and cap client subscriptions so a misconfigured client cannot flood the device with reads. When in doubt, measure: the server exposes per-device statistics that show exactly where time is spent.</p>\n\n<h2 id=\"redundancy-and-failover-configuration\">Redundancy and Failover Configuration</h2>\n\n<p>For mission-critical paths, configure redundancy at the level that matches the hardware: channel-level driver redundancy for dual-CPU controllers, server-level redundancy (KEPServerEX Redundancy Master) for dual-server installations with automatic client failover, and device-level fallback channels where devices are reachable over two networks. Test the failover with the real client connected — switching must be transparent to the subscribing applications and the diagnostics must show which path is active.</p>\n\n<h2 id=\"summary\">Summary</h2>\n\n<p>KEPServerEX architecture is decided in the channel and tag configuration, not in the client. Pick native drivers, partition channels by protocol and performance, name everything for the plant structure, create typed, block-read tags once and reference them everywhere, and plan capacity with the server's own diagnostics. A clean channel/tag architecture makes every downstream integration trivial — a messy one makes it permanently fragile.</p><section class=\"engineering-check\"><h2 id=\"apply-this-to-your-project\">Apply this to your project</h2><ul><li>Record the endpoint, supported security policies, application identity, certificate expiry, and user permissions.</li><li>Verify the value, engineering unit, StatusCode, and source timestamp together at the receiving application.</li><li>Test disconnection and recovery with representative subscriptions; preserve evidence of any data gaps or repeated values.</li></ul><p><a href=\"https://wiki.aspotomasyon.com/guides\">Follow an ASP project guide</a> to connect the fundamentals with implementation and acceptance.</p></section><figure class=\"article-figure\"><img src=\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-review.svg\" width=\"1100\" height=\"460\" loading=\"lazy\" decoding=\"async\" alt=\"Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.\"><figcaption>Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration. <a href=\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-review.svg\" target=\"_blank\" rel=\"noopener\">View full size</a></figcaption></figure><h2 id=\"primary-references-and-further-reading\">Primary references and further reading</h2><p>Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.</p><ul><li><a href=\"https://reference.opcfoundation.org/specs/OPC-10000-4/\" rel=\"noopener noreferrer\" target=\"_blank\">OPC Foundation — OPC UA Part 4: Services</a></li><li><a href=\"https://reference.opcfoundation.org/specs/OPC-10000-2/\" rel=\"noopener noreferrer\" target=\"_blank\">OPC Foundation — OPC UA Part 2: Security Model</a></li></ul><!-- asp-editorial-202609 -->","markdown":"# Kepware Driver Selection and Channel/Tag Architecture\n\n> KEPServerEX is the most widely deployed industrial connectivity platform: it converts dozens of native protocols — Siemens, Allen-Bradley, Modbus, DNP3…\n\n- Canonical URL: https://wiki.aspotomasyon.com/article/kepware-driver-selection-architecture\n- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)\n- Category: OPC Solutions\n- Published: 2026-08-11 · Updated: 2026-09-13\n- Reading time: 5 min · Language: English\n\nKEPServerEX is the most widely deployed industrial connectivity platform: it converts dozens of native protocols — Siemens, Allen-Bradley, Modbus, DNP3, BACnet, and hundreds more — into OPC UA, OPC DA, MQTT, and REST interfaces for SCADA, MES, and IIoT applications. The architecture looks simple (channels → devices → tags), but the decisions made when creating channels and tags determine reliability, performance, and troubleshooting ease for the life of the integration. Getting the architecture right at the start is the single biggest success factor.\n\n![A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.](https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-context.svg)\n\n*A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.*\n\n## Driver Selection\n\nSelecting the right driver is the first architecture decision. Consider in order:\n\n1. **Native protocol availability** — always prefer the device's native driver over a generic one. A Siemens S7 driver speaking the native S7 protocol beats a Modbus-TCP fallback in speed, diagnostics, and data coverage.\n2. **Driver generation** — current KEPServerEX drivers are grouped by protocol generation (e.g., Siemens TCP/IP Ethernet, Allen-Bradley ControlLogix Ethernet, Modbus TCP/IP); newer \"Suite\" drivers manage multiple device models in one channel. Use the compatibility tables in the driver help to pick the model that matches the firmware.\n3. **Channel capacity** — each channel is one communication task (one thread). Very fast polling needs a dedicated channel; a channel holding dozens of slow devices is fine.\n4. **Redundancy options** — if the device supports it (e.g., ControlLogix Redundancy, S7 with failover), configure it at channel level so the client sees one stable tag set.\n5. **Diagnostics features** — native drivers typically expose richer device-level status (communication health, counters) that the generic drivers cannot.\n\n## Channel Design Rules\n\n- **One channel per communication type** — group devices by protocol, network segment, and polling characteristics. Mixing a fast motion controller and a slow metering device in one channel couples their performance.\n- **Separate critical and bulk traffic** — a channel polling 2,000 register points at 100 ms starves nothing if it is alone; sharing that channel with slow serial devices forces compromise polling rates.\n- **Use request timeouts and retries deliberately** — short timeouts on fast networks, longer on serial links; excessive retries on a dead device stall the channel's queue.\n- **Name channels meaningfully** — the channel name propagates into every tag name and every downstream client. `PLANT2-LINE1-PLC3` is a name; `CH1` is a future support ticket.\n- **Serial channels** — one device per channel for RS-232; RS-485 multi-drop is fine, but keep baud rates and parity consistent and terminate the bus properly.\n\n## Tag Architecture\n\nTag design determines what the clients see and how hard the system is to maintain:\n\n- **Use the model's native addressing** — for S7 use DB/area syntax, for ControlLogix use the tag path; avoid address math in tag names.\n- **Group tags hierarchically** — mirror the plant structure (Area → Unit → Equipment → Point). OPC UA browsing of the address space then matches the plant book, and client configuration is trivial.\n- **Create typed tags** — use the driver's data types (Boolean, Word, DWord, Float) and let Kepware convert; avoid \"raw value + scaling in the client\" — use the driver's scaling features so every client sees engineering units.\n- **Array and block reads** — where the driver supports array reads, map contiguous blocks to array tags instead of thousands of individual tags; performance improves dramatically.\n- **Avoid tag duplication** — one tag per point, referenced by all clients. Duplicate channels reading the same PLC registers double the device load for zero benefit.\n- **Static vs dynamic tags** — dynamic tags (addressed on the fly) are useful for prototypes; for production, static tags are deterministic and diagnosable.\n\n## Performance and Capacity Planning\n\nKEPServerEX scales well when planned: the polling engine batches requests per device, and the bottleneck is usually the device's own response time, not the server. Rules of thumb: keep the total tag count per channel within the driver's documented guidance; spread high-rate devices across channels; monitor the server's performance counters (poll requests/sec, latency, failures) in the OPC UA diagnostics; and cap client subscriptions so a misconfigured client cannot flood the device with reads. When in doubt, measure: the server exposes per-device statistics that show exactly where time is spent.\n\n## Redundancy and Failover Configuration\n\nFor mission-critical paths, configure redundancy at the level that matches the hardware: channel-level driver redundancy for dual-CPU controllers, server-level redundancy (KEPServerEX Redundancy Master) for dual-server installations with automatic client failover, and device-level fallback channels where devices are reachable over two networks. Test the failover with the real client connected — switching must be transparent to the subscribing applications and the diagnostics must show which path is active.\n\n## Summary\n\nKEPServerEX architecture is decided in the channel and tag configuration, not in the client. Pick native drivers, partition channels by protocol and performance, name everything for the plant structure, create typed, block-read tags once and reference them everywhere, and plan capacity with the server's own diagnostics. A clean channel/tag architecture makes every downstream integration trivial — a messy one makes it permanently fragile.\n\n## Apply this to your project\n\n- Record the endpoint, supported security policies, application identity, certificate expiry, and user permissions.\n- Verify the value, engineering unit, StatusCode, and source timestamp together at the receiving application.\n- Test disconnection and recovery with representative subscriptions; preserve evidence of any data gaps or repeated values.\n\n[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.\n\n![Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.](https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-review.svg)\n\n*Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.*\n\n## Primary references and further reading\n\nUse the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.\n\n- [OPC Foundation — OPC UA Part 4: Services](https://reference.opcfoundation.org/specs/OPC-10000-4/)\n- [OPC Foundation — OPC UA Part 2: Security Model](https://reference.opcfoundation.org/specs/OPC-10000-2/)\n\n---\n\nCite the canonical article: https://wiki.aspotomasyon.com/article/kepware-driver-selection-architecture (Kepware Driver Selection and Channel/Tag Architecture, ASP OTOMASYON, updated 2026-09-13).\n","headings":[{"id":"driver-selection","title":"Driver Selection"},{"id":"channel-design-rules","title":"Channel Design Rules"},{"id":"tag-architecture","title":"Tag Architecture"},{"id":"performance-and-capacity-planning","title":"Performance and Capacity Planning"},{"id":"redundancy-and-failover-configuration","title":"Redundancy and Failover Configuration"},{"id":"summary","title":"Summary"},{"id":"apply-this-to-your-project","title":"Apply this to your project"},{"id":"primary-references-and-further-reading","title":"Primary references and further reading"}],"faq":[],"references":[{"name":"OPC Foundation — OPC UA Part 4: Services","url":"https://reference.opcfoundation.org/specs/OPC-10000-4/"},{"name":"OPC Foundation — OPC UA Part 2: Security Model","url":"https://reference.opcfoundation.org/specs/OPC-10000-2/"}],"related":[{"slug":"kepware-kepserverex-configuration-guide","title":"Kepware KEPServerEX Configuration Guide","summary":"Kepware Server (formerly KEPServerEX) is one of the most widely deployed OPC servers, providing connectivity to over 150 industrial protocols and device…","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/kepware-kepserverex-configuration-guide","markdown_url":"https://wiki.aspotomasyon.com/article/kepware-kepserverex-configuration-guide.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/kepware-kepserverex-configuration-guide","published":"2026-05-12T12:47:31+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":928,"image":"https://wiki.aspotomasyon.com/assets/social/kepware-kepserverex-configuration-guide-eba1e4597a3a.png"},{"slug":"opc-ua-mqtt-bridge-patterns","title":"OPC UA to MQTT Bridge Patterns","summary":"Industrial automation environments increasingly demand a two-tier data strategy: OPC UA for real-time, deterministic plant-floor communication and MQTT for…","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-mqtt-bridge-patterns","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-mqtt-bridge-patterns.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-mqtt-bridge-patterns","published":"2026-05-13T12:01:15+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":8,"word_count":1649,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-mqtt-bridge-patterns-b71382141389.png"},{"slug":"advanced-kepware-alarms-history-redundancy","title":"Advanced Kepware: Alarms, Historical Data, and Redundancy","summary":"KEPServerEX from PTC/Kepware is the most widely deployed OPC server in industrial automation, and most users only scratch the surface of its capabilities.","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/advanced-kepware-alarms-history-redundancy","markdown_url":"https://wiki.aspotomasyon.com/article/advanced-kepware-alarms-history-redundancy.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/advanced-kepware-alarms-history-redundancy","published":"2026-05-13T12:01:15+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":8,"word_count":1689,"image":"https://wiki.aspotomasyon.com/assets/social/advanced-kepware-alarms-history-redundancy-a11e2ccb1483.png"},{"slug":"opc-ua-server-setup-with-kepware","title":"OPC UA Server Setup with Kepware","summary":"This guide walks through the complete process of configuring OPC UA server functionality in Kepware KEPServerEX. Once configured, OPC UA clients can securely…","category":{"slug":"technical-guides","name":"Technical Guides"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-server-setup-with-kepware","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-server-setup-with-kepware.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-server-setup-with-kepware","published":"2026-05-12T12:47:31+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":962,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-server-setup-with-kepware-34ec46e25fac.png"}],"citation":"ASP OTOMASYON. Kepware Driver Selection and Channel/Tag Architecture. Updated 2026-09-13. https://wiki.aspotomasyon.com/article/kepware-driver-selection-architecture"}}