6 Industrial Ethernet Family Design

Industrial Ethernet is not a single protocol. It is a family of Ethernet-based control and integration approaches that make different promises about timing, topology, device roles, diagnostics, configuration, and gateway boundaries.

The review question is not "which protocol is fastest?" The useful question is "which control behavior is proven for this machine, device set, topology, maintenance model, and integration boundary?"

For example, a packaging cell might need a 4 ms update for servo handoff, 20 ms status updates for remote IO, and dashboard publishing every second. The protocol decision should not collapse those into one speed number. The release record should show which traffic is cyclic control, which traffic is diagnostics, which data crosses the OPC UA or MQTT boundary, and what happens when a drive is replaced during maintenance. If PROFINET, EtherCAT, EtherNet/IP, or TSN is selected, the reviewer should be able to point to the timing trace, device role map, topology drawing, diagnostic path, gateway rule, and owner who will recheck the claim after firmware, device, or line-layout changes.

Before carrying Determinism is a release claim, not a protocol slogan. The record must show timing, topology, role, synchronization, diagnostics, and gateway evidence into the “Timing need” design record, view Figure 6.1. It makes “Timing need” and “control loop, jitter, grouping, safety boundary” separate, inspectable parts of the “timing need”–“control loop, jitter, grouping, safety boundary” decision.

Notice “Timing need” on Figure 6.1 as the condition under review. “control loop, jitter, grouping, safety boundary” marks the adjacent responsibility, while “Topology” leads to “line, ring, star, switch behavior”. Together they explain Determinism is a release claim, not a protocol slogan. The record must show timing, topology, role, synchronization, diagnostics, and gateway evidence; preserve that division when documenting the “timing need”–“control loop, jitter, grouping, safety boundary” decision.

The One-Minute Protocol-Family Map

Inspect Figure 6.2 with one question from the “siemens standard”–“profinet io” decision: how does “Siemens Standard” constrain “PROFINET IO”? The answer supports Industrial Ethernet families differ by role model, scheduling assumptions, topology behavior, tooling, and where gateway integration belongs.

Notice “Siemens Standard” on Figure 6.2 as the condition under review. “PROFINET IO” marks the adjacent responsibility, while “RT / IRT Layer” leads to “Ethernet”. Together they explain Industrial Ethernet families differ by role model, scheduling assumptions, topology behavior, tooling, and where gateway integration belongs; preserve that division when documenting the “siemens standard”–“profinet io” decision.

Overview Knowledge Check

A durable Industrial Ethernet decision separates control-network behavior from supervisory integration. The same machine may use an Industrial Ethernet family for cyclic control, OPC UA for information modeling, MQTT for event distribution, and a historian path for long-term review. The release record keeps those boundaries explicit.

The next choice in the “prove the family in the real machine and operations context, not from one marketing claim”–“1 · control behavior” decision depends on “timing, jitter, sync”, a boundary shown in Figure 6.3. Inspect “Prove the family in the real machine and operations context, not from one marketing claim”, then set it against “1 · Control behavior”, before judging Selection workflow: define control behavior, prove topology and devices, place gateways, run pilot evidence, and write the release record.

Map the responsibilities in Figure 6.3: “Prove the family in the real machine and operations context, not from one marketing claim” comes first, “1 · Control behavior” follows, and “timing, jitter, sync” resolves at “safety boundary”. This division makes Selection workflow: define control behavior, prove topology and devices, place gateways, run pilot evidence, and write the release record inspectable and tells the the “prove the family in the real machine and operations context, not from one marketing claim”–“1 · control behavior” decision record what to preserve after release.

Selection Workflow

1. Define control behavior. Record timing need, jitter tolerance, update grouping, synchronization, and safety boundary.
2. Define topology. Record machine layout, cable route, redundancy, maintenance access, switches, and segmentation.
3. Confirm device support. Check controller, device, drive, IO, safety, motion, and diagnostic capabilities for the deployed products.
4. Review family fit. Compare PROFINET, EtherCAT, EtherNet/IP, TSN, or hybrid architectures against the evidence, not a single marketing claim.
5. Place the gateway boundary. Decide what leaves through OPC UA, MQTT, historian, dashboard, or API paths and what must stay in control.
6. Run pilot evidence. Exercise load, topology changes, diagnostics, replacement, recovery, and security controls.
7. Write the release record. Include assumptions, unsupported cases, owners, change triggers, and recheck triggers.

Release Record Ledger

The next choice in the “speed-table choice”–“prove the machine timing evidence” decision depends on “Topology ignored”, a boundary shown in Figure 6.4. Inspect “Speed-table choice”, then set it against “Prove the machine timing evidence”, before judging Review risks to catch before release: speed-table selection, ignored topology, missing diagnostics, skipped TSN profile, blurred gateway boundary, and missing owner.

Trace Figure 6.4 by asking what “Speed-table choice” establishes and what “Prove the machine timing evidence” changes. Check “Topology ignored” next, ending at “Review layout, switches, and access”. That progression is the mechanism behind Review risks to catch before release: speed-table selection, ignored topology, missing diagnostics, skipped TSN profile, blurred gateway boundary, and missing owner and the evidence order needed for the “speed-table choice”–“prove the machine timing evidence” decision.

Practitioner Knowledge Check

Industrial Ethernet families are reviewed through different internal records. A good design does not flatten PROFINET, EtherCAT, EtherNet/IP, and TSN into a single ranking table. It records the specific behavior each family must prove in the deployed topology.

The evidence buckets differ because the mechanisms differ. A PROFINET review starts with roles, device description, cyclic data, and alarms. An EtherCAT review starts with the frame path, process image, working counter, and clock behavior. An EtherNet/IP review starts with CIP objects, assemblies, services, and connection behavior. A TSN review starts with selected IEEE 802.1 tools, profiles, schedules, bridge support, and configuration ownership. Mixing those records hides the real release risk.

PROFINET Role Record

To ground the “io controller”–“cyclic exchange owner” decision through “IO Device” in visible evidence about “IO Controller”, inspect Figure 6.5. Its named elements “IO Controller” and “cyclic exchange owner” frame the claim that PROFINET review centers on controller-device relationships, device descriptions, cyclic data, alarms, diagnostics, topology, and conformance evidence.

On Figure 6.5, inspect “IO Controller” before “cyclic exchange owner”. The subsequent hand-off from “IO Device” to “data and status” explains PROFINET review centers on controller-device relationships, device descriptions, cyclic data, alarms, diagnostics, topology, and conformance evidence. Carry that sequence into the “io controller”–“cyclic exchange owner” decision so “IO Controller” evidence, “cyclic exchange owner” decision, and “data and status” recheck remain distinguishable.

For PROFINET, document the IO Controller, IO Device, and IO Supervisor roles; module or submodule configuration; cyclic data layout; alarm and diagnostic behavior; topology assumptions; and change procedure for replacement or firmware drift.

EtherCAT Processing Record

The claim that EtherCAT review centers on the ordered frame path, process-image ownership, expected working counter, distributed-clock proof, topology diagnostics, and recovery evidence needs “Prove frame path, process image, working counter, clocks, topology, and recovery behavior” as a concrete check beside “Processing-on-the-fly frame path”. Inspect Figure 6.6 before continuing the “prove frame path, process image, working counter, clocks, topology, and recovery behavior”–“processing-on-the-fly frame path” decision, especially “Prove frame path, process image, working counter, clocks, topology, and recovery behavior” beside “Processing-on-the-fly frame path”.

Notice “Prove frame path, process image, working counter, clocks, topology, and recovery behavior” on Figure 6.6 as the condition under review. “Processing-on-the-fly frame path” marks the adjacent responsibility, while “Main device” leads to “owns frame cycle”. Together they explain EtherCAT review centers on the ordered frame path, process-image ownership, expected working counter, distributed-clock proof, topology diagnostics, and recovery evidence; preserve that division when documenting the “prove frame path, process image, working counter, clocks, topology, and recovery behavior”–“processing-on-the-fly frame path” decision.

For EtherCAT, document main device and subdevice order, process image ownership, expected working-counter behavior, clock synchronization evidence where required, cable or port diagnostics, and recovery when one segment is unavailable.

EtherNet/IP And CIP Boundary

To ground the “cip model”–“objects” decision through “assemblies” in visible evidence about “CIP Model”, inspect Figure 6.7. Its named elements “CIP Model” and “objects” frame the claim that EtherNet/IP brings CIP object, service, and connection concepts onto Ethernet/IP networks; gateway mapping should preserve context and authority.

Follow Figure 6.7 through four named stops: “CIP Model”, “objects”, “assemblies”, and “services”. Their order turns EtherNet/IP brings CIP object, service, and connection concepts onto Ethernet/IP networks; gateway mapping should preserve context and authority into a reviewable path. In the “cip model”–“objects” decision, use the same stops to locate evidence and assign the recheck.

For EtherNet/IP, document CIP objects, services, assemblies, explicit or implicit messaging purpose, multicast handling, diagnostics, and gateway mappings into OPC UA, MQTT, historians, or application APIs.

TSN Toolbox Record

A release decision about the “time sync”–“time domain owner” decision needs “Scheduled Traffic”, not a slogan. Inspect Figure 6.8 through “Time Sync” and “time domain owner” to check this claim: TSN is a toolbox. The design must state which tools, profile, schedules, bridges, end stations, and configuration owner are released.

Inspect “Time Sync” against “time domain owner” on Figure 6.8, then test the link between “Scheduled Traffic” and “gate and schedule plan”. The two comparisons clarify TSN is a toolbox. The design must state which tools, profile, schedules, bridges, end stations, and configuration owner are released. They also keep “Time Sync” in the running decision about the “time sync”–“time domain owner” decision, tied to labelled evidence.

For TSN, document time synchronization ownership, scheduled traffic or shaping choices, profile or application standard, bridge and end-station capability, configuration ownership, and separation between control traffic and ordinary IT traffic.

Under-The-Hood Knowledge Check