How to Introduce Ethernet-APL into Brownfield Process Automation: Audit, Cable, Topology, Coexistence, and Commissioning
Consider a typical brownfield scenario. The pilot segment works: a handful of PROFINET transmitters on one APL field switch in a utilities area, a fiber uplink to the control room, clean device diagnostics in the asset management tool. The plan for the next turnaround looks straightforward: repeat the pattern across two process units and reuse the installed instrument cable wherever the drawings say "fieldbus Type A."
Then the shutdown starts. A large share of the "Type A" runs turns out to be cable of mixed age and origin, spliced in junction boxes that the records no longer match. Several homeruns go through a multicore bulk cable to the marshalling room. The DCS needs a firmware and license update before it can host the new devices, and that update carries its own validation step nobody scheduled. The Ex documentation still describes the old intrinsically safe loops, not 2-WISE segments. A few days into the window, the team is deciding which part of the scope to put back.
None of that is an Ethernet-APL failure. The physical layer behaves exactly as specified. What fails is the working assumption that a brownfield plant is a greenfield design with some cable already in the ground. Scenarios like this are common enough to plan against from the first audit.
Teams typically assume: once Ethernet-APL works on a test bench or a pilot skid, rolling it out into the existing plant is mostly a matter of buying switches and reusing cable.
In reality: a brownfield migration succeeds only when the new field-level architecture can coexist with the installed system, the cable has been proven by measurement, the path to the control system is known and licensed, hazardous-area constraints are closed on paper, and every cutover has a defined rollback.
Quick Overview
Problem: An Ethernet-APL pilot that works in isolation stalls or slips when it meets the installed cable, the existing DCS, the Ex documentation, and a fixed shutdown window.
Common causes: cable reuse assumed from drawings, homeruns routed through multicore bulk cable, an unplanned controller upgrade, power budgets calculated without voltage drop, 2-WISE treated as a device label, and no rollback path inside the turnaround.
Where it appears: chemical, pharmaceutical, oil and gas, and water plants running 4–20 mA/HART with central or remote I/O, and installations on PROFIBUS PA or FOUNDATION Fieldbus H1.
Engineering focus: installed-base audit, a well-bounded migration unit, measured cable qualification, an explicit control-system path, coexistence rules, and staged commissioning.
Plant-wide migration is typically owned by the plant, EPC, and DCS teams. Here we focus on the brownfield constraints that directly affect field-device architecture and integration — the layer where Promwad works.
Where This Guide Starts — and What It Leaves to Other Articles
This is an implementation playbook, so it assumes the decision to consider Ethernet-APL has already been made. If the business case is still open, start with our analysis of Ethernet-APL vs 4–20 mA brownfield economics. The cost model is deliberately not repeated here.
One short paragraph of background. 10BASE-T1L is the IEEE 802.3cg-2019 physical layer: 10 Mbit/s full-duplex Ethernet over a single twisted pair, up to 1,000 m. Ethernet-APL builds on it with what process plants need: port profiles with defined power classes and segment types (standardized as IEC TS 63444, second edition published in June 2026), power and data on the same pair, and an intrinsic-safety concept for hazardous areas, 2-WISE, defined in IEC TS 60079-47. Every APL device is a 10BASE-T1L device; the reverse is not true. For the PHY, power, and protocol basics, see our explainer on 10BASE-T1L physical layer and migration basics. For the device side — MAC-PHY, MCU, PCB, firmware — see designing an Ethernet-APL field device.
Brownfield Starts With the Installed Base, Not With the New Technology
In a running plant you cannot design an ideal APL network on a blank sheet. The existing DCS, the cable in the trays, the Ex dossier, and the maintenance routine all set boundary conditions before the first switch is selected. The audit is where those boundaries are found — and where most later surprises can still be removed cheaply.
A useful audit records five things, and records them per loop, not per area:
| What to record | Detail that matters | Why it matters later |
|---|---|---|
| Field devices and signals | 4–20 mA with HART actually used vs. not used; PROFIBUS PA / FF H1; discrete signals; safety-related loops; Ex vs. non-Ex | Decides which loops can move, which must stay, and which still need remote I/O |
| Control system | DCS/PLC model, firmware and license level, available Industrial Ethernet interfaces and protocol support | An unplanned controller upgrade is one of the most common schedule breakers |
| Field infrastructure | Junction boxes, marshalling, remote I/O cabinets, auxiliary power in the field, fiber and copper backbone | Determines whether a powered trunk or Ethernet to the field switch is realistic |
| Cable records | Type, shield, age, length, route, splices, bonding, quality of documentation | Cable reuse is a measurement result, not an assumption from drawings |
| Operational constraints | Turnaround windows, hot-work rules, redundancy requirements, permitted downtime per unit | Sets the size of the migration unit and the rollback window |
The HART column deserves attention. Many plants run 4–20 mA loops where HART is wired but never read. Those loops may have more to gain from richer digital access — and they are also the ones where nobody yet owns the device-parameter workflow that Ethernet-APL makes possible.
Choose the Migration Unit Before You Choose Hardware
"Migrate the plant" is not a work package. The practical question is: what is the smallest piece that can be cut over, tested, and — if necessary — reverted inside one window? Four boundaries work in practice:
- By unit or area. Fits planned shutdowns and dense clusters of instruments. Easy to schedule, but every loop in the area moves at once.
- By loop or device family. Fits end-of-life replacement and phased product rollouts. Smallest blast radius, longest period of mixed architectures.
- By junction box or field cabinet. Fits when an APL field switch replaces local infrastructure. The topology boundary is physical and easy to document.
- By fieldbus segment. The strongest scenario for PROFIBUS PA and FOUNDATION Fieldbus H1, where the segment already has trunk-and-spur structure. Cable reuse still has to be confirmed by measurement.
Decision rule: a migration unit is valid only if it has a named owner, a clear topology boundary, a cutover window that fits the turnaround, and a rollback path that does not depend on the new equipment working.
Map the Existing Architecture to One of Three Migration Patterns
The Ethernet-APL Engineering Guideline (v1.14, Chapter 8) treats brownfield migration through three starting points. They are worth using as a classification, because each one fails in a different place.
| Installed base | Typical brownfield move | Main engineering question |
|---|---|---|
| Central I/O + marshalling + 4–20 mA | Keep untouched loops; introduce APL by area or extension. The guideline is explicit: APL signals must not be routed through multicore bulk cable, so the bulk cable section is replaced | Where does the Industrial Ethernet/APL path enter, and which individual device cables pass requalification? |
| Remote I/O + 4–20 mA | Coexist with remote I/O while selected instruments move to APL field switches. Auxiliary power is usually already in the field, so field switches fed by Ethernet/fiber are a natural fit | Can cabinets, power, and the network carry both architectures through the transition? The PROFIBUS DP bus cable itself cannot be reused for APL — its impedance differs |
| PROFIBUS PA / FF H1 | Reuse suitable Type A cable and replace couplers, power conditioning, and devices in stages | Does the installed cable pass APL qualification, and do existing enclosures fit the field-switch and power concept? |
In all three patterns, the guideline notes that the controller typically needs a version with an Industrial Ethernet interface. That line item belongs in the plan from the start, not in the punch list.
A wording rule that saves arguments later: never write "reuse existing cable" as a benefit. Write "candidate cable, to be measured and requalified against APL cable categories and installation conditions." The difference shows up in the change-order log.
Qualify the Cable Before You Design the Topology Around It
This is the block that decides whether the schedule holds. Ethernet-APL needs shielded, twisted-pair cable with a characteristic impedance of 100 Ω ±20% across 0.1–20 MHz; conductor sizes from 26 AWG to 14 AWG are allowed. The reference cable is fieldbus Type A per IEC 61158-2 — the same cable family used for PROFIBUS PA and FF H1. That is why fieldbus segments are the strongest reuse candidates, and why typical unshielded 4–20 mA wiring usually is not.
For installed cable, the guideline makes the check mandatory: transmission performance has to be verified per ISO/IEC 11801-3, with the trunk insertion-loss limits applied directly and a 0.2 correction factor applied for spurs. Cable that performs worse is not automatically rejected — it simply supports a shorter segment:
| APL cable category | I | II | III | IV |
|---|---|---|---|---|
| Maximum trunk length | 250 m | 500 m | 750 m | 1,000 m |
| Maximum spur length | 50 m | 100 m | 150 m | 200 m |
What this means on site:
- Measure length, continuity, shorts, and the electrical parameters of each candidate run. Drawings tell you where a cable should be; the measurement tells you what category it actually is.
- Treat cable age as a variable. The guideline explicitly asks to consider it; insulation and shield condition degrade, and twenty-year-old fieldbus cable may be fine or may not.
- Check shield continuity, bonding at both ends, and existing surge protection. Splices and terminal boxes count as inline connections, and those are limited per segment (see below).
- Never route APL through a multicore bulk cable "because the pairs are there." The migration architecture must follow the guideline, not the existing tray layout.
- If cable qualification fails, make cable replacement its own work package. Hiding it inside "APL installation" turns a known cost into a surprise and makes the APL scope look late when it is not.
Design the Target Topology and Power Path
There is no single correct brownfield topology. There are two basic structures, and the installed base usually decides between them.
| Design aspect | Powered APL trunk | Industrial Ethernet to the field switch |
|---|---|---|
| How it works | An APL power switch in the control room or Zone 2 feeds the trunk; field switches and devices are powered over it | Fiber or copper Ethernet runs to field switches with auxiliary power; spurs power the devices |
| Reach | Trunk segments up to 1,000 m (category IV), reduced by voltage drop and load | Multimode fiber typically up to ~2,000 m; copper up to 100 m |
| Data rate toward the controller | 10 Mbit/s shared on the trunk | Typically 100 Mbit/s to each field switch |
| Brownfield fit | No auxiliary power in the field; central I/O areas | Remote I/O areas where field power and cabinets exist; plants with separate bonding networks |
| Watch for | Voltage-drop calculation, bonding along long trunks; the trunk does not support ring redundancy | Power and enclosure space per field switch; line depth of the Ethernet network |
Details that tend to get skipped:
- Power classes. Spur ports and device ports carry power classes (A, B, C on intrinsically safe spurs; per the guideline, Class A is 15 V / 0.54 W and Class C 15 V / 1.1 W at the source). Source and load classes must be compatible. The 2026 edition of IEC TS 63444 added a further APL power class, so check device data sheets against the switch you actually plan to buy.
- Voltage drop on powered trunks. Allowed trunk length depends on power-switch output, number of field switches, device load, conductor cross-section, and cable temperature. In the guideline's worked example with maximum trunk and spur lengths, only two or three devices fit per field switch, depending on conductor cross-section. Calculate; do not extrapolate from the pilot.
- Redundancy. Where availability matters, the usual pattern is an Industrial Ethernet ring between field switches (for example MRP) and PROFINET system redundancy (S2) at the controller. NAMUR NA 195 covers ring and star structures, participant limits, MRP, and S2 — but support depends on the specific DCS and switches, so treat it as something to verify, not a given.
- Inline connections and auxiliary devices. Per segment: at most two auxiliary devices (a surge protector counts as one), and at most four inline connections on a spur or ten on a trunk. Brownfield junction boxes eat into this budget quickly.
- Ports and headroom. Plan spare spur ports and a power reserve, and keep at least one free, labeled port for diagnostic tools. For network load, the guideline's rule of thumb is: under 20% cyclic load needs no action, 20–50% should be checked, above 50% needs fixing. At typical process cycle times this is rarely the limit — 150 devices at a 1 s cycle produce roughly 1.1% load.
- Bonding. If two plant areas sit on separate bonding networks, connect their field switches by fiber rather than forcing one shared reference over a long copper trunk.
Make the Control-System Path Explicit
Field devices are only one side of the migration. The other side is the path from the field switch to the controller, the engineering station, and the asset management system — and in brownfield plants that path is often the least documented part of the project.
Questions to close before commissioning, not during it:
- Does the existing DCS or PLC support the required protocol over Ethernet (PROFINET with the PA profile, EtherNet/IP, HART-IP, or another) at the needed device count?
- Is a firmware, software, license, or hardware-module upgrade required? Who validates it, and does that validation fit the window?
- How are device names, addresses, and parameters commissioned, backed up, and restored after a device swap?
- How do diagnostics reach operators and maintenance — NE 107 status signals, the asset management tool, both?
- Where is protocol conversion still needed during coexistence, and who maintains those gateways until they are removed?
- Who owns network configuration — OT, automation, IT, the DCS vendor, or the EPC? Write it down per migration unit.
Multi-vendor interoperability is no longer theoretical. In a 2025 load test defined by BASF and run at Endress+Hauser, nearly 240 field devices were integrated through a ring of APL field switches from three vendors into an Emerson DeltaV system with PROFINET S2 redundancy. That is strong evidence the stack works at scale. It is not evidence that your controller version, your device mix, and your naming conventions work together — that still has to be proven on a representative segment.
Plan Coexistence Instead of Rip-and-Replace
Analog/HART, fieldbus, remote I/O, and Ethernet-APL will share most brownfield plants for years. The engineering task is to make that coexistence boring.
- Leave loops that work and have no lifecycle trigger untouched.
- Introduce APL first on new extensions, end-of-life replacements, and selected high-value instruments where richer diagnostics change maintenance decisions.
- Keep one source of truth that records which loop belongs to which architecture. Mixed plants fail on documentation before they fail on physics.
- Separate process continuity from network modernization. A device's measurement or control function must never depend on the digitalization rollout being finished.
- Define rollback per window: what happens if a field switch, a device firmware, or the controller integration fails during the shutdown? The same staged, reversible thinking we describe for migrating legacy controllers without stopping production applies at the field level.
Protocol choice can ease the human side of coexistence. HART-IP over Ethernet-APL keeps the HART data model, so existing HART tools and work processes carry over; PROFINET with the PA profile offers generic device integration for PROFIBUS PA users. Either way, the protocol decision is a site-standard decision and should be made before the first device order.
Hazardous Areas: Treat 2-WISE as an Engineering Constraint, Not a Label
2-WISE (IEC TS 60079-47) simplifies intrinsic-safety verification for APL spurs. It does not make every APL device intrinsically safe, and it does not replace Ex engineering.
What the concept actually covers: a 2-WISE spur is considered intrinsically safe when it consists of one 2-WISE source port, one 2-WISE load port, and up to two 2-WISE auxiliary devices, connected by cable no longer than 200 m that stays within defined parameter ranges (resistance 15–150 Ω/km, inductance 0.4–1 mH/km, capacitance 45–200 nF/km). Even then:
- The level of protection of the spur is set by the weakest port. An Ex ic switch port with an Ex ia device gives an Ex ic spur.
- IEC TS 60079-47 requires a descriptive system document for each 2-WISE segment — protection level, equipment group, temperature classes, and cable parameters. In a brownfield plant, that document has to be written; it does not exist yet.
- Trunks are not intrinsically safe: in the guideline examples they are increased safety (Ex eb) for Zone 1, or nonincendive for Class I, Division 2.
- Shield grounding at both ends inside the Ex area is only permitted where potential equalization is highly ensured (IEC 60079-14). Otherwise one end is connected through a capacitor.
- National installation rules still apply. Where exact Ex claims are needed, defer to the certified switch and device documentation and to the site Ex specialist.
Commissioning: Test the Network, Then the Process Function
Keep two acceptances apart: "the installation is correct" and "the plant function is preserved." Mixing them is how a cable fault gets debugged as a DCS configuration problem.
Installation Acceptance — Before the Control System Is Involved
The guideline structures this in three steps that can be done with simple tools:
- Visual inspection: routing as planned, cable type and gauge as specified, connectors, bend radius, crossings with power cables, strain relief, sealed unused entries, bonding and shield connections, labels, the free diagnostic port, and the count of inline connections and auxiliary devices per segment.
- Cable measurements: spur lengths within 200 m (category IV), powered trunk lengths as calculated, cable integrity, and electrical parameters — especially on reused cable. Store the results.
- Basic check without the control system: switches powered with link status, all devices visible in a network tool, and — on powered trunks — the supply voltage at each field switch with margin above its minimum.
Functional Commissioning — With the Control System
- Device commissioning: naming and addressing, parameterization, diagnostics, controller behavior, and asset-management access.
- Redundancy behavior: pull an uplink and confirm the ring and the controller behave as designed.
- Process functional checks: the measurement and control function still meets the original plant requirement.
- A firmware and update plan before go-live, not after the first field issue.
- A baseline record per segment, so maintenance can later tell cable or network degradation from an instrument failure.
Cybersecurity and Operations After Go-Live
Ethernet down to the transmitter adds operational capability and attack surface at the same time. The operational basics are not exotic, but someone has to own them:
- An asset inventory of IP-enabled field devices, with owners.
- Patch and firmware responsibility, maintenance windows, and backup/restore of device configuration.
- Certificates and credentials where the protocol or application layer requires them.
- Segmentation and controlled access aligned with the plant security architecture; retention of logs and diagnostics.
NAMUR has published a working-group practice, "Ethernet-APL Security Advisory," aimed at plant operators. On the device side, the requirements come from IEC 62443-4-1 and -4-2; we cover what that means in hardware and firmware in field-level Ethernet cybersecurity under IEC 62443.
A Brownfield Rollout Sequence That Holds Up
- Inventory the installed base and classify signals, devices, Ex zones, and safety relevance.
- Confirm the DCS/PLC and Industrial Ethernet path, required upgrades, and ownership boundaries.
- Choose a migration unit with a defined cutover window and rollback.
- Measure and requalify candidate cable; do not assume reuse from drawings.
- Design the target topology, power budget, and field-switch placement; write the 2-WISE documentation.
- Validate one representative segment against the real controller, real devices, and real naming conventions.
- Document coexistence rules and the commissioning procedure.
- Roll out unit by unit, and keep legacy infrastructure wherever replacement brings no value.
- Update asset, security, and maintenance processes after each migration wave.
Where Promwad Fits: The Device That Has to Live in Both Worlds
Most of the work above belongs to the plant owner, the EPC, and the DCS vendor. One part does not: the field device that must keep its original function while gaining an Ethernet-based interface. That is where brownfield constraints turn into firmware and hardware requirements.
Promwad has engineered this coexistence at device level. In one electromagnetic flow meter program, a single STM32F7-based device combined PROFINET, HART, and Modbus RTU, with an MCUboot-based bootloader for field updates — the kind of mixed-interface device a plant in transition actually needs. In another project, we integrated the Analog Devices ADIN1110 10BASE-T1L MAC-PHY into an industrial predictive-maintenance sensor, from schematic and bring-up to a working PROFINET and OPC UA stack.
What brownfield adds to the device specification is concrete: legacy behavior that must not change, diagnostics that map to NE 107, parameter backup and restore for device swaps, an update path the operator can schedule, and a power budget that fits the spur class the plant can actually supply. Validation also has to run against the controller the customer already owns, which is where structured firmware testing — as in our industrial controller firmware QA project — pays off.
Full scope of our device-side work: → Ethernet-APL & 10BASE-T1L field device engineering
What Promwad Can — and Cannot — Own in This Scenario
For plant-wide rollout and commissioning, Promwad works alongside the client's DCS vendor, EPC, or system integrator. Our core responsibility is the field-device engineering and connectivity layer.
| Promwad can credibly support | Owned with client / DCS / EPC / integrator | Outside Promwad scope |
|---|---|---|
| Field-device architecture and modernization; 10BASE-T1L MAC-PHY and PHY integration; PCB and firmware; PROFINET and OPC UA integration; device diagnostics; validation against the customer's controller | Plant topology decisions; DCS/PLC integration boundaries; Ex and site rules; commissioning interfaces | Complete plant migration ownership; certified APL/2-WISE system delivery; full DCS or EPC scope |
| Legacy/new interface coexistence at device level, based on project experience with 4–20 mA, HART, Modbus, and PROFINET | Cable and site survey; plant documentation; field-switch infrastructure and cabinet scope | Plant-wide network design and on-site installation |
You May Be Facing This If
- Your APL pilot works, but the rollout plan relies on cable "per drawings."
- Homeruns in the target area pass through multicore bulk cable to a marshalling room.
- Nobody has confirmed whether the DCS needs a firmware, license, or module upgrade.
- The powered-trunk design was sized from the pilot device count, not a voltage-drop calculation.
- The Ex dossier describes the old IS loops, and no 2-WISE descriptive system documents exist yet.
- There is no written rollback for the shutdown window.
- Your product line still ships 4–20 mA/HART devices, and customers have started asking for an APL variant.
Real Trade-Offs to Expect
- Cable reuse vs. cable replacement. Reuse saves material and pulling labor, but only after measurement; a failed requalification found during the shutdown costs more than a planned replacement.
- Powered trunk vs. Ethernet to the field switch. A powered trunk avoids field power but shares 10 Mbit/s, needs a voltage-drop budget, and does not form a ring. Ethernet to the switch adds power and enclosures in the field but gives bandwidth, reach on fiber, and ring options.
- Large vs. small migration units. Large units finish sooner; small units fail smaller. Plants with short turnarounds usually pay more for a failed large unit than for a long mixed period.
- One protocol vs. site flexibility. A single site protocol simplifies engineering and spares; supporting several keeps vendor choice open but multiplies validation.
- Native APL devices vs. adapters. Adapters or gateways bridge legacy devices quickly but add components to maintain; native devices are cleaner but depend on device availability for every measuring principle.
Modernizing a field device for an installed process plant?
Promwad can help define the device-side architecture, 10BASE-T1L connectivity, embedded software, PROFINET/OPC UA integration, and validation while preserving the product function customers already rely on.
FAQ
Can an existing two-wire cable be reused for Ethernet-APL?
Do we need to migrate every 4–20 mA loop?
What is the easiest installed base to migrate?
Can Ethernet-APL and 4–20 mA/HART coexist in one plant?
Does Ethernet-APL remove the need for remote I/O?
Who should own a plant-wide Ethernet-APL rollout?
Related Promwad Expertise
- Ethernet-APL & 10BASE-T1L Field Device Engineering — the main service page: MAC-PHY selection, PCB, firmware, PROFINET and OPC UA integration, diagnostics.
- Single-Pair Ethernet (10BASE-T1L) for Industrial Field Devices — PHY, power delivery, protocol stack, and migration basics.
- Electromagnetic Flow Meter Design — one device combining PROFINET, HART, and Modbus RTU.
- Firmware Development for Industrial Protocols — industrial protocol firmware for automation devices.
- Industrial Sensor Development — sensor electronics and firmware with Ethernet-APL, HART, 4–20 mA, and PROFINET interfaces.
- IEC 62443 in Practice: Embedded Security Architecture — device-level security once Ethernet reaches the field.
Tell Us About Your Field Device
Share the device, the interfaces it carries today, the plants it ships into, and where the Ethernet-APL transition gets stuck. We will help define the next engineering step on the device side.