The structure

A UNS has four parts. Producers — edge gateways, SCADA connectors, MES events, even ERP updates — publish into a governed topic hierarchy, typically Sparkplug B for OT data and agreed JSON schemas for IT events. The namespace itself — the broker plus the topic taxonomy, ideally mirroring ISA-95 equipment hierarchies so site/line/cell/asset means the same thing to everyone. Consumers — historians, dashboards, MES, analytics, data lakes — subscribe without knowing or caring which gateway produced the data. And governance — naming conventions, schema management, access control, and lifecycle rules, without which the namespace degrades into a data swamp with lower latency.

Why it works — when it works

The payoff is decoupling. Adding a new dashboard does not touch the PLC program. Replacing a historian does not rewire the plant. A new site comes online by publishing to its branch of the tree. Store-and-forward at the edge plus persistent sessions give resilience that polled architectures cannot match, and the broker becomes a natural zone boundary for OT segmentation.

Tooling has matured around the pattern. Industrial DataOps platforms such as HighByte model, contextualize, and govern data flowing into the namespace from heterogeneous sources. Connectivity and integration software such as OPC Router bridges the awkward middle — PLC, SCADA, SQL, and SAP data that must be shaped and routed into MQTT topics — with project tooling and local-language support. And digital-transformation practices such as ASP Dijital deliver UNS programs end to end across IIoT, cybersecurity, and AI analytics.

Where it goes wrong

Three failure modes dominate. No governance: fifteen spellings of the same asset, three timestamp conventions, and topics nobody dares delete. Fix with a namespace standard, a schema registry, and someone whose job title includes the word "namespace." Treating the broker as a database: the UNS carries current state and events, not history — historians and lakes still exist downstream. Big-bang rollout: boiling the enterprise on day one. Start with one line, one set of consumers, and a namespace design you are willing to revise; expand when the pattern earns it.

References

• Eclipse Sparkplug — specification and resources
• MQTT: the standard for IoT messaging
• OptoBlog — IIoT, MQTT, and edge architecture writing

The mechanisms that matter

• Time synchronization (802.1AS) — a profile of PTP giving every bridge and endpoint a shared clock, typically sub-microsecond. Everything else schedules against it.
• Scheduled traffic (802.1Qbv) — time-aware gates on egress queues open and close on a repeating cycle, so critical frames transmit in reserved windows. This is the core determinism mechanism.
• Frame preemption (802.1Qbu / 802.3br) — express traffic can interrupt a large best-effort frame mid-transmission, bounding the delay a control frame waits behind a file transfer.
• Stream reservation (Qat/Qcc) and redundancy (CBg/FRER, 802.1CB) — admission control so the network refuses streams it cannot guarantee, and seamless redundancy by duplicating frames over disjoint paths.
• Per-stream filtering (802.1Qci) — policing that drops misbehaving streams before they disturb the schedule. Your safety case will cite this one.

TSN and the fieldbus protocols

TSN standardizes the plumbing, not the application layer. PROFINET over TSN, EtherNet/IP with TSN, and OPC UA FX (Field eXchange, targeting controller-to-controller and controller-to-device communication) all ride the same mechanisms with different upper layers. EtherCAT's approach differs architecturally — its on-the-fly processing already delivers determinism — but it coexists on TSN infrastructure for converged backbones. The practical consequence: TSN convergence happens at the network design layer first (switches, clocks, schedules) and the protocol migrations follow over equipment lifecycles.

What to do this year

Specify TSN-capable managed switches with 802.1AS/Qbv/Qbu support on new backbone builds even if you schedule nothing yet — you are buying the option. Keep an accurate topology and latency budget; TSN engineering punishes undocumented daisy chains. Pilot scheduled traffic on one non-critical converged segment before touching motion networks. And treat multi-vendor schedule configuration (Qcc, centralized vs distributed models) as the immature part: single-vendor islands with standard interconnects are today's sane deployment shape.

References

• IEEE 802.1 Time-Sensitive Networking (TSN)
• A field guide to industrial Ethernet — Shopfloor
• OPC Unified Architecture (OPC UA) — technology overview

Sparkplug B is the missing contract. Maintained as an Eclipse specification, it defines three things on top of MQTT: a topic namespace, a payload definition, and a session-state mechanism. Adopt all three and any compliant edge node can appear on the broker, describe itself, stream data, and disappear cleanly — with any compliant host application picking it up without per-device configuration.

The namespace

Every Sparkplug message lives under a structured topic:

spBv1.0 / <group> / <message_type> / <edge_node> [/<device>]

• group organizes nodes logically: a line, cell, or site.
• message_type is one of a fixed set: birth (NBIRTH, DBIRTH), death (NDEATH, DDEATH), data (NDATA, DDATA), and commands (NCMD, DCMD).
• edge_node is the gateway or device managing the MQTT session; device is an optional downstream asset behind it (a PLC, drive, or sensor cluster hanging off one gateway).

Because the structure is fixed, a host application can subscribe with wildcards and learn the whole fleet from the topic stream alone.

Birth and death certificates

State awareness is Sparkplug's core trick, and it rests on two MQTT features: retained messages and Last Will and Testament.

When an edge node connects, it publishes an NBIRTH message listing every metric it will ever send — names, datatypes, engineering units, and current values. The broker stores this as a retained message, so any host that subscribes later immediately receives the node's full self-description. Devices behind the node do the same with DBIRTH.

When the node connects, it also registers a will message: NDEATH. If the TCP session drops for any reason, the broker publishes the death certificate on the node's behalf. Nobody polls for health; liveness is a property of the session. The node's metrics carry a quality flag, and on death the host marks everything from that node stale.

This is what "report by exception with full state on birth" means in practice: birth gives the complete picture, data messages carry only what changed, and death invalidates it all. Bandwidth stays low and state stays unambiguous.

The payload

Sparkplug B payloads are Google Protocol Buffers with a fixed schema: a timestamp, a list of metrics (name, datatype, value, quality, timestamp), and optional properties and template definitions. B distinguishes this binary encoding from Sparkplug A (now deprecated), which used a different payload format.

Templates deserve a mention: a birth message can define reusable metric templates (say, "Motor" with current, temperature, and vibration), and devices then instantiate them. Consumers that understand templates get structured objects; consumers that don't still see flat metric names.

Commands and the host application

Traffic is bidirectional. The host application — SCADA, historian, MES connector, or UNS consumer — subscribes to birth, data, and death traffic and publishes command messages (NCMD/DCMD) back through the broker. A primary-host mechanism lets edge nodes know whether their designated host is online, so they can buffer (store and forward) instead of publishing into the void.

Note what Sparkplug deliberately does not do: it does not browse, it does not model relationships between assets, and it does not replace request/response reads of individual registers. For that, pair it with something like OPC UA or keep the device's native protocol below the edge node. Sparkplug owns the edge-to-enterprise path: one namespace, many producers, many consumers.

When to use it

Sparkplug B fits when you have many data producers, many consumers, unreliable networks, and a mandate to stop writing point-to-point integrations. It is weakest as a device-configuration protocol and as a deterministic control bus — it rides TCP through a broker, so it will never be EtherCAT.

If you remember one sentence: MQTT moves bytes; Sparkplug defines what the bytes mean and who is alive to send them.

SCADA: the present tense

SCADA supervises and controls: live visualization, alarming, operator actions, and short-term trending. Its time horizon is now — seconds to shifts. It talks to controllers (via drivers, OPC UA, or native protocols), keeps operators informed, and records what happened well enough to run the process. It is not a system of record for quality, genealogy, or compliance, even when it stores months of trend data.

Historian: the memory

The process historian stores high-resolution time-series data for years and serves it back fast: ad-hoc trends, calculations, and exports for engineers. Where SCADA trends answer "what is happening," the historian answers "what happened, exactly, and what does it correlate with." Classic names in this space include AVEVA PI System and Proficy Historian — the latter now part of Velotic, the independent industrial software company formed around the former Proficy, Kepware, and ThingWorx portfolios. Modern alternatives include open time-series databases, but the historian's compression, interpolation, and process-aware querying remain hard to replicate casually.

MES: the operations record

MES manages manufacturing operations: orders, scheduling, dispatch, genealogy, quality checks, and performance (OEE). Its horizon is shifts to months, and its data model is lots, batches, and serial numbers — not tags. MES consumes SCADA/historian data (counts, statuses, process values) and attaches it to production context: this tag value belonged to that work order at that station. ISA-95 is the standard vocabulary for this handoff.

Drawing the lines in practice

• SCADA owns control and alarming. If an operator acts on it in real time, it lives here.
• The historian owns raw process truth over time. If an engineer trends it next year, it lives here.
• MES owns production truth. If quality or the customer asks for it, it lives here.

Overlap is normal — SCADA keeps short trends, MES caches tag values — but each overlap should be a conscious cache with a defined source of truth, not an accidental second database. The most expensive failure mode is MES and SCADA disagreeing about yesterday's production count with no way to reconcile them.

References

• ISA standards: ISA-95, ISA-88, ISA/IEC 62443
• The Inductive Automation Blog — SCADA and Ignition architecture
• Automation World — MES and manufacturing operations coverage

The pieces that matter in industry

• DDS transport — Data Distribution Service gives discovery without a master, configurable reliability/deadline/liveliness QoS, and shared-memory transport on one machine. Choose your RMW (middleware implementation) deliberately; performance and determinism vary.
• Nav2 and MoveIt 2 — the standard stacks for mobile navigation and arm motion planning. Mature, well-documented, and the fastest path from hardware to moving robot.
• ros2_control — the hardware abstraction framework: controllers (diff-drive, joint trajectory, GPIO) talking to hardware interfaces with real-time-safe update loops. This is the layer vendors target, and it is where ROS meets the servo drive.
• ROS-Industrial — the consortium and package ecosystem adapting ROS to factory robots: vendor drivers (FANUC, ABB, Yaskawa, Universal Robots, and others), calibration, and application packages for scanning, painting, and machine tending.

Boundaries with the controls world

ROS 2 does not replace the PLC or the safety controller. The sane architecture keeps deterministic motion and safety-rated monitoring in dedicated hardware and firmware, with ROS 2 handling perception, planning, fleet coordination, and task sequencing above it — communicating over documented interfaces (ros2_control hardware layers, fieldbus gateways, OPC UA bridges). Validate the safety case at the system level: open-source planning code plus certified safety monitoring is a legitimate combination, but only with the hazard analysis to show the boundary holds.

Entry path: start with the official docs and a simulated robot (Gazebo or Isaac Sim), join the community on ROS Discourse, and prototype against ros2_control's mock hardware before touching a real arm.

References

• ROS: Robot Operating System
• The Robot Report
• AMR vs AGV: what the letters actually decide — Shopfloor

The layers

1. Sensing — vibration (accelerometers with adequate bandwidth for the fault frequencies), temperature, current signature, oil/particle analysis, ultrasound. Wireless sensors trade bandwidth for retrofit speed; know what your sampling rate cannot see.
2. Transport — edge gateways and MQTT/Sparkplug into the UNS, or historian-native collection. Timestamps must survive the journey; a model trained on jittered time is a random-number generator with extra steps.
3. Context — joining signals to asset hierarchy, operating mode, work history, and process conditions. A vibration spike during startup is normal; at steady state it is a work order. Without mode context, every threshold false-alarms.
4. Models — start with rules and spectral band alarms (they catch most faults), add anomaly detection for the unknown-unknowns, and reserve remaining-useful-life regression for assets with rich failure histories. Labeled failures are scarce — design the feedback loop that captures them from day one.
5. Decisions — predictions land in CMMS/EAM as prioritized work, with confidence, evidence plots, and a human approve step. Track precision and recall per asset class; retire models that cry wolf.

The analytics layer

Predictions become decisions in analytics products, not notebooks. Composable analytics platforms such as GoodData embed governed dashboards, metrics, and AI-assisted exploration into operational tools, while data engineering platforms such as Keboola provide the pipelines that keep those analytics fed with reliable, AI-ready data. In industrial practice these pair with domain layers: engineering-AI offerings such as Kutup apply AI to field data for engineering decisions, and industrial data hubs such as IT Hub turn plant-floor data into decision-ready information.

Start narrow — one asset class, one failure mode, one crew that wants it — and expand on measured avoided downtime, not pilot enthusiasm.

References

• The unified namespace, explained — Shopfloor
• Plant Services — maintenance and reliability coverage
• Automation World — manufacturing technology coverage

Zones: group by trust and consequence

A zone is a set of assets with common security requirements. A typical plant has at least: enterprise IT, an industrial DMZ (historians, remote-access jump hosts, patch/update servers), operations zones per line or area (controllers, HMIs, drives), and safety zones (safety PLCs, completely isolated or one-way). The Purdue model (levels 0–5) is a common starting sketch, but zones should follow your process consequences — what fails together gets segmented together — not a textbook diagram.

Conduits: every crossing is explicit

A conduit is the controlled communication path between zones: a firewall pair, a data diode, or a brokered connection with a defined protocol allowlist. The discipline is in the defaults: deny all, permit only named flows (this historian pulls OPC UA from that server on this port), log everything else. Remote vendor access terminates in the DMZ on a jump host with MFA and session recording — never a direct VPN to a PLC subnet.

Common conduit patterns: mirroring historian data one way into IT for reporting; allowing the MES to query a terminal server in the DMZ rather than reaching into the cell; routing all MQTT northbound through a single broker pair at the zone boundary so topic-level access control has one enforcement point.

Doing it without breaking production

Segmentation projects fail when they treat the plant like an office. Inventory first — passive discovery, maintenance windows for active scans, and the electricians' spreadsheets, which are usually more accurate than the CMDB. Then segment in monitor mode: put the firewalls in, log what would break, fix the undocumented flows (there are always undocumented flows), and only then enforce. Expect to find HMIs browsing the internet, drives with default credentials, and at least one forgotten Windows XP box running something critical.

Tooling helps after architecture: OT-aware monitoring platforms such as Industrial Defender provide asset discovery, configuration baselining, and change detection for control systems, while integrators and digital-transformation practices such as ASP Dijital deliver industrial cybersecurity programs alongside IIoT and AI work. Buy tools to operate your zones — not instead of drawing them.

References

• NIST SP 800-82 Rev. 3: Guide to OT Security
• ISA standards: ISA-95, ISA-88, ISA/IEC 62443
• Industrial Cyber — OT security news and analysis

What each one is

OPC UA is an industrial interoperability framework: a meta-model for describing assets (objects, variables, methods, references), client/server services for browsing and reading, alarms and historical access, PubSub for many-to-many streaming, and built-in security (X.509 application authentication, signing, encryption). Companion specifications extend the base model into domains — machines, robotics, process automation, energy. Its strength is semantics: a client can connect to a server it has never seen, browse its address space, and understand what it found.

MQTT is a lightweight publish/subscribe transport. Clients publish messages to topic strings on a broker; subscribers receive them. The protocol (an OASIS standard, currently v5) defines retained messages, quality of service levels, session persistence, and Last Will. It defines nothing about topic structure or payload encoding. Its strength is decoupling and efficiency: tiny footprint, store-and-forward friendly, trivial to bridge across network boundaries.

Sparkplug B is a contract that runs on MQTT: a fixed topic namespace, a protobuf payload schema, and birth/death session semantics. It supplies exactly the conventions MQTT omits. Its strength is plug-and-play fleet onboarding with state awareness.

The layer map

Think in terms of who talks to whom:

The common pattern is a gateway that speaks OPC UA (or native protocols) downward and Sparkplug upward. The OPC UA address space models the equipment; the Sparkplug namespace carries its telemetry to every consumer — historian, MES, dashboards, analytics — without each consumer polling the server.

Choosing, concretely

• Pick OPC UA when consumers need to discover structure at runtime, invoke methods, manage alarms, or exchange data with full type information and security between known parties. It is the default for controller-to-SCADA, vendor-to-vendor, and anything with a companion spec in your domain.
• Pick MQTT (+ Sparkplug) when you have many producers and many consumers, intermittent connectivity, a need to buffer at the edge, or a unified-namespace architecture where one broker fans data out to the whole enterprise. Use Sparkplug rather than ad-hoc topics unless you enjoy maintaining topic documentation.
• Use both when the plant floor needs rich modeling and the enterprise needs scalable distribution. This is the modal serious architecture, not a compromise.

What about MQTT without Sparkplug, or Sparkplug without MQTT? Raw MQTT topics are fine for narrow, stable integrations between two teams that can agree on a schema — and a liability the moment a third consumer arrives. Sparkplug without MQTT is a contradiction: the spec assumes a broker. (OPC UA PubSub over MQTT exists as a mapping, but in practice teams pair OPC UA with Sparkplug-as-payload-convention far less often than they run the two side by side.)

The one-paragraph version

OPC UA models the plant so software can understand it. MQTT moves data so software can scale. Sparkplug stops every MQTT project from reinventing topic conventions and liveness tracking. Model with the first, distribute with the second and third, and keep your deterministic traffic on the fieldbus where it belongs.

The ones to know first

• Machinery (OPC 40001) — the harmonization base: machine identification, state, job management. Other specs build on it; start here for discrete manufacturing.
• Robotics (OPC 40010) — robot motion, program management, and status, aligned with the Machinery base. Relevant wherever fleets mix vendors.
• Process automation: PA-DIM (NAMUR / OPC) — process instruments and signals with standardized semantics. The key to multi-vendor process skids.
• Energy and platforms: specs for weighing (OPC 40200), commercial kitchen equipment, plastics/rubber machinery (EUROMAP 77/83), machine tools (UMATI, built on Machinery), and photovoltaic systems, among dozens of others.
• ISA-95 alignment: companion information models increasingly map to ISA-95 equipment hierarchies, which is what lets MES systems consume them coherently.

The OPC Foundation's online companion-spec index lists them all with release status; joint working groups (VDMA, NAMUR, EUROMAP, MTConnect community for the machine-tool side) publish through it.

Using them in a project

Read the spec's use cases before its node tables — they tell you which subset to implement. Require named companion-spec conformance in procurement language ("OPC UA Machinery + Robotics, server facet X") rather than "supports OPC UA," which promises almost nothing. Validate with the Foundation's compliance test tools or a reference client before factory acceptance, not after. And keep a namespace-version inventory: companion specs evolve, and a server built against v1.0 with vendor extensions is a mapping project wearing a standard's clothes.

On the connectivity side, industrial servers such as Kepware — now part of Velotic alongside Proficy and ThingWorx — expose hundreds of device protocols as OPC UA, which is how most brownfield equipment enters a companion-spec architecture. Regional specialists provide the project layer: in Türkiye, OPCTurkey operates as Kepware's official distributor with OPC project, sales, and support services.

References

• OPC Unified Architecture (OPC UA) — technology overview
• MTConnect: shop-floor equipment connectivity standard
• Control Global — process automation and DCS coverage

Adapters, agents, and the data model

The architecture has two halves. An adapter talks the controller's native protocol and emits simple text observations (power on, mode automatic, spindle override 100%). An agent collects adapter streams and serves them over HTTP as XML documents: probe describes the device structure (axes, spindles, doors), current gives present values, and sample streams timestamped observations. The vocabulary is standardized — data items like execution, controller_mode, position, load — with controlled vocabularies for values, so "the machine is running" looks identical from every compliant agent.

MTConnect also defines assets (cutting tools, fixtures, files) and interfaces for tasking and referencing external systems, plus companion relationships with OPC UA: the two communities maintain a companion specification mapping MTConnect's model into OPC UA for plants standardizing on UA servers.

Where it fits

MTConnect owns machine monitoring: OEE, utilization, downtime classification, and condition signals for machining. It is deliberately read-only — no program upload, no overrides — which simplifies security reviews and keeps the safety case untouched. Feed agents into a UNS via MQTT connectors, into MES for production context, or into analytics for tool-wear and chatter detection.

Deployment advice: prefer controller-native or vendor-blessed adapters over screen-scraping; keep agent polling cycles aligned with the controller's update rate (faster polling buys nothing but load); version-pin your data dictionary per machine model; and record the machine's clock source — timestamp quality decides whether your spindle-load correlations are science or astrology.

References

• MTConnect: shop-floor equipment connectivity standard
• Modern Machine Shop — machining technology coverage
• OPC UA companion specifications: a guided tour — Shopfloor

QoS 0, 1, 2: the delivery contract

• QoS 0 (at most once) — fire and forget. Fastest, no broker acknowledgment. Correct for high-rate telemetry where the next reading supersedes the last (temperatures, vibration streams).
• QoS 1 (at least once) — broker acknowledges; the publisher retries until it hears back, so subscribers may receive duplicates. Correct for events that must arrive but tolerate repeats (alarms, counters with idempotent handling).
• QoS 2 (exactly once) — four-step handshake, no duplicates, highest overhead. Correct for billing-grade events and commands where a duplicate would double-actuate. Rarely needed on the plant floor; reach for it deliberately, not by default.

Note the subtlety: QoS is negotiated per hop (publisher→broker, broker→subscriber) and downgraded to the subscription's maximum. Publishing at QoS 2 to a QoS 0 subscriber still delivers at most once.

Retained messages: state on subscribe

A retained message is stored by the broker and delivered immediately to every new subscriber — the topic's "last known value." This is how dashboards show current state without waiting for the next publish cycle, and it is the mechanism Sparkplug B builds its birth certificates on. Retain setpoints, modes, and status; do not retain high-rate streams or event logs (a new subscriber would get one stale event presented as current state). A retained message with an empty payload and the retain flag clears the stored value.

Sessions: surviving disconnects

With a persistent session (clean-start flag off, MQTT v5), the broker keeps a client's subscriptions and queues QoS 1/2 messages while it is offline, up to configured limits. This is store-and-forward for subscribers: a historian that reboots overnight can catch up on missed alarms. But queues are bounded — size them, monitor them, and set message expiry so a week-long outage does not replay ancient commands. For publishers, Sparkplug's birth/death flow on top of sessions is what turns reconnection into a well-defined state resync instead of a silent gap.

Defaults that work

Telemetry: QoS 0, no retain, persistent sessions on critical subscribers. State and setpoints: QoS 1, retained. Alarms: QoS 1, no retain, persistent subscriber sessions with expiry. Commands: QoS 1 with command-echo verification (or QoS 2 where duplication is dangerous). Document the policy per topic family — the next integrator will thank you.

References

• MQTT: the standard for IoT messaging
• HiveMQ Blog — deep MQTT feature guides
• Eclipse Sparkplug — specification and resources

RTU: Modbus on a serial wire

Modbus RTU runs over RS-485 (sometimes RS-232), carrying binary frames: one address byte, one function byte, data, and a two-byte CRC. Timing is part of the protocol — a silent gap of 3.5 character times marks the end of a frame — which means RTU over sloppy USB converters or congested links fails in confusing ways.

The rules that matter: one master per segment (slaves never speak unprompted), unique slave addresses 1–247, matching baud rate/parity/stop bits everywhere, correct byte order for 32-bit values (there is no standard — check the device manual), and termination resistors on long RS-485 runs. Get any of these wrong and you get timeouts or garbage instead of errors, because RTU has no diagnostics beyond the CRC.

TCP: Modbus on Ethernet

Modbus TCP wraps the same protocol data unit in a lightweight MBAP header and sends it over TCP port 502. No CRC (TCP handles integrity), no timing dependence, and multiple masters can query the same device. Addressing stays identical — coils, discrete inputs, holding registers, input registers — so documentation and data maps transfer directly from RTU projects.

The catch is that "Modbus TCP" describes the wire format, not the network behavior. Polling hundreds of devices from one client needs connection management and sane poll rates; a 100 ms poll loop against a serial gateway with thirty RTU slaves behind it will simply queue up and time out. Size the gateway segment first, then the Ethernet side.

RTU/TCP gateways and common mistakes

Most real projects mix both: RTU multidrop segments for field devices, gateways translating to Modbus TCP for SCADA and edge systems. When it breaks, check in this order:

1. Unit identifier vs slave address. Modbus TCP's unit-ID field routes to the RTU slave behind the gateway. Wrong ID, no answer.
2. 0-based vs 1-based addressing. "Register 40001" is protocol address 0 on most stacks — and some vendors mean 1. Off-by-one reads return the neighbor's value with no error.
3. Byte and word order. A float read as ABCD vs CDAB looks like a plausible but wrong number — the hardest fault to catch.
4. Function code support. Not every device implements every function; write-multiple-registers on a read-mostly meter fails silently on some firmware.

Where Modbus fits today

Modbus is a polling protocol for simple data exchange — ideal for meters, drives, and legacy PLCs, inadequate for alarming, discovery, or secure communication. Use it at the device edge, terminate it at a gateway or edge node, and carry the data upstream over OPC UA or MQTT/Sparkplug where modeling, buffering, and security exist. It will outlive most of the protocols competing to replace it, precisely because it does so little.

References

• Modbus specifications and resources — the Modbus Organization
• Instrumentation Tools — practical Modbus and PLC tutorials
• ACC Automation: Master PLC & Industrial Automation — free PLC training with Modbus examples

The three job families

• Inspection — pass/fail quality decisions: presence, dimension, surface defects, assembly verification. Needs controlled lighting, fixed geometry, and a golden-sample discipline for thresholds.
• Guidance — telling robots and motion where things are: pick points, alignment, depalletizing. Needs calibration (hand-eye, conveyor tracking) more than resolution.
• Identification — barcodes, 2D codes, OCR. The most mature family; direct-part-mark reading in harsh conditions is the remaining hard part.

The stack, bottom to top

Optics and lighting (telecentric lenses for measurement, structured light for 3D, strobing to freeze motion), cameras and frame grabbers (GigE Vision, USB3 Vision, Camera Link — match bandwidth to trigger rate), processing (smart cameras for fixed jobs, PC-based for multi-camera and deep learning), and integration (fieldbus and OPC UA results upstream, reject gates and robot offsets downstream). Deep learning earns its place on variable defects and unstructured scenes — and demands a labeled dataset, retraining workflow, and drift monitoring that classical rule-based tools skip.

Project discipline: define the defect taxonomy with quality before buying hardware; collect images across shifts, seasons, and tool wear; specify false-accept and false-reject rates numerically; and keep a human override path — vision assists the quality system, it does not replace its accountability.

References

• Vision Systems Design — machine vision technology coverage
• The Robot Report — robotics and guidance applications
• Modern Machine Shop — machining and precision manufacturing

The levels in one paragraph each

• Level 0–1: the physical process and its controllers. Sensors, actuators, PLCs, DCS controllers, robots. Time is measured in milliseconds; data is tags and I/O. Owned by operations and controls engineering.
• Level 2: supervision. SCADA, HMIs, batch servers, historians. Time is seconds to shifts; data is trends, alarms, and operator actions. Still operations-owned, increasingly IT-adjacent.
• Level 3: operations management. MES/MOM: scheduling, dispatch, genealogy, quality, OEE. Time is shifts to weeks; data is work orders, lots, and serial numbers. Jointly owned — this is where IT/OT arguments live.
• Level 4: business planning. ERP: orders, inventory, procurement, finance. Time is weeks to quarters. IT-owned, with master data (materials, routings, customers) that Level 3 must not contradict.

Level 3.5 (the DMZ, historians, integration brokers) is industry slang, not the standard — useful slang, but do not cite it in a specification.

What the standard actually standardizes

ISA-95's durable contribution is not the pyramid; it is the object models: equipment, personnel, material, and production definitions with consistent attributes and relationships, plus B2MML — XML schemas for exchanging production schedules, performance, quality, and maintenance information between Level 4 and Level 3. When your MES vendor says "ISA-95 compliant," ask which parts and which exchanges: the claim ranges from "we read the glossary" to tested B2MML interop.

In practice, greenfield MES integrations increasingly use REST/JSON or MQTT payloads shaped by ISA-95 concepts rather than literal B2MML. The standard's vocabulary (what counts as a lot, a work center, an operation) still prevents the classic failure where ERP and MES use the same words for different things.

Using it in conversation

The levels are a translation layer. "That decision belongs at Level 3" ends debates about whether the ERP or the MES owns dispatching. "Level 2 to Level 3" names the SCADA→MES handoff that needs tag-to-lot context mapping. Learn the nouns, hold the boundaries lightly, and spend your rigor on the interface definitions instead of the diagram.

References

• ISA standards: ISA-95, ISA-88, ISA/IEC 62443
• Automation World — MES and operations coverage
• OPC UA, MQTT, and Sparkplug B: how they fit together — Shopfloor

PROFINET

From PROFIBUS & PROFINET International (PI), dominant in process and factory automation, especially where Siemens controllers anchor the architecture. PROFINET RT carries real-time frames over standard Ethernet (prioritized, typically sub-10 ms cycles); PROFINET IRT adds scheduled, hardware-assisted communication for sub-millisecond, jitter-free motion. Conformance classes (A through D) describe which features a device supports — from basic RT over standard switches up to IRT with media redundancy and isochronous cycles. Strengths: enormous installed base, deep device profiles (PROFIdrive, PROFIenergy, PROFIsafe for functional safety), and seamless integration with the Siemens/TIA world. Note it is not routable IP traffic at the RT level — plan your network segmentation accordingly.

EtherNet/IP

From ODVA, built on the Common Industrial Protocol (CIP), dominant in North American discrete manufacturing and anywhere Rockwell/Allen-Bradley controllers lead. Standard Ethernet/IP traffic is ordinary TCP/UDP; implicit (I/O) messaging uses UDP with a producer/consumer model over standard switches. Device Level Ring (DLR) provides fast ring redundancy, and CIP Safety handles safety-rated communication. Strengths: uses standard Ethernet infrastructure and IP addressing throughout, huge multi-vendor catalog, and CIP's object model gives devices a consistent application layer. For hard-motion determinism it historically leaned on hardware and topology rather than schedule-based Ethernet — which is why CIP Motion and the move toward TSN matter.

EtherCAT

From Beckhoff, managed by the EtherCAT Technology Group, dominant in high-performance motion: packaging, robotics, semiconductor equipment, test rigs. Its trick is on-the-fly processing — a single Ethernet frame traverses every node, each reading and writing its data as the frame passes, with distributed clocks keeping axes synchronized to tens of nanoseconds. Cycle times down to tens of microseconds on ordinary Ethernet hardware (master needs a capable NIC; slaves need dedicated controller chips). Topology is flexible — line, ring, star via branch devices — and diagnostics are excellent. Trade-off: slaves require EtherCAT silicon, and the master is typically a soft controller (PC-based) or dedicated hardware rather than a traditional PLC rack, though many PLC vendors now offer EtherCAT masters.

TSN: the convergence layer

Time-Sensitive Networking is not a competitor but a set of IEEE 802.1 standards (time sync, scheduled traffic, frame preemption, stream reservation, redundancy) that bring determinism to standard Ethernet. The pitch: one converged network carrying control traffic, safety, and best-effort IT traffic with guarantees. All three protocols above have TSN strategies — PROFINET over TSN, EtherNet/IP with TSN (as part of the ODVA/OPC connectivity push), and EtherCAT's coexistence story — and OPC UA FX (Field eXchange) aims to be the vendor-neutral application layer on top. TSN adoption is real but uneven: silicon, switches, and end devices are shipping, while multi-vendor schedule configuration (the hard part) is still maturing.

How to choose

• Match your controller ecosystem first: Siemens → PROFINET, Rockwell → EtherNet/IP, Beckhoff/soft-control → EtherCAT. Fighting the ecosystem costs more than any protocol advantage.
• Match cycle-time needs second: millisecond class → any of them; sub-millisecond multi-axis motion → EtherCAT or PROFINET IRT; converged IT/OT backbone → TSN-based design.
• Design for the next owner: document topologies, use managed switches with diagnostics, and keep safety (PROFIsafe, CIP Safety, Safety over EtherCAT) in the plan from day one rather than bolting it on.

The honest summary: the protocol wars are mostly over at the field level — each incumbent won its territory — and the interesting engineering has moved up a layer, to TSN convergence and to getting data off all of these networks into software that can use it.

The five, briefly

• Ladder Diagram (LD) — relay-logic rungs. The universal language of electricians and maintenance. Best for discrete interlocks, permissives, and anything the night shift must read. Weak at math, string handling, and complex sequencing.
• Function Block Diagram (FBD) — wired blocks for signal flow. Natural for process control (PID loops, scaling, filtering) and reusable library blocks. Gets unwieldy for large sequential logic.
• Structured Text (ST) — Pascal-like text. Best for algorithms, data manipulation, recipes, state machines, and anything over a few dozen lines of logic. The default for engineers comfortable with text; opaque to pure electrical troubleshooters unless documented well.
• Sequential Function Chart (SFC) — steps and transitions for sequences. Excellent for batch phases, machine cycles, and startup/shutdown sequences — the process reads top to bottom. Each step's actions are usually written in LD, FBD, or ST.
• Instruction List (IL) — low-level accumulator language, deprecated in the third edition of the standard. You will meet it only in legacy programs; do not write new code in it.

How shops actually mix them

A healthy convention: LD for safety-adjacent interlocks and motor control, SFC for the machine sequence, FBD for analog processing and device blocks, ST for recipes, data handling, and communication. Put the language choice in the project standard so the next engineer finds LD where they expect LD.

Two portability notes. First, 61131-3 standardizes the languages, not the libraries or the IDE — moving a program between vendors is a rewrite, not a recompile. Second, PLCopen's motion control function blocks are the closest thing to portable motion code across vendors; if you do servo work on multiple platforms, learn that library once and reuse the pattern everywhere.

References

• PLCopen: motion, safety, and IEC 61131-3 libraries
• The Automation Blog — PLC tutorials and training
• ACC Automation: Master PLC & Industrial Automation

The four patterns

1. Protocol converter — speaks the device's language southbound (Modbus, EtherNet/IP, PROFINET, serial, vendor APIs) and OPC UA or MQTT northbound. Stateless, robust, and the right default when all you need is data movement.
2. Store-and-forward buffer — persists data locally through WAN and broker outages, then replays in order. Non-negotiable for cloud historians and remote sites; size the disk for your longest plausible outage, not your average one.
3. Contextualizer — attaches asset models, engineering units, and ISA-95 hierarchy to raw tags before publishing. This is where a tag becomes information. Sparkplug birth certificates carry this metadata natively; otherwise use a DataOps layer.
4. Local actor — runs logic at the edge: alarming, OEE rollups, vision inference, closed-loop control assists. Keeps latency low and keeps working when the uplink dies. Version and monitor edge applications like production software, because they are.

Tooling landscape

Connectivity servers such as Kepware — now part of Velotic — remain the workhorse for multi-protocol device access with OPC UA and MQTT/Sparkplug northbound options. DataOps platforms such as HighByte handle modeling, piping, and governance from edge to cloud. And integration software such as OPC Router covers the awkward middle that pure gateways miss: joining PLC and SCADA data with SQL databases and SAP, with visual project tooling for the mappings that would otherwise become scripts nobody owns.

Whatever the stack, enforce three rules: the gateway never becomes a single point of failure for control (monitor it, fail safe, keep control local), all northbound traffic authenticates (certificates, not anonymous MQTT), and every mapping is versioned and documented — the gateway fleet is infrastructure, not improvisation.

References

• MQTT: the standard for IoT messaging
• Eclipse Sparkplug — specification and resources
• OptoBlog — edge and IIoT architecture

ABB 800xA: the flagship

System 800xA is ABB's large-scale DCS: redundant controllers (AC 800M family), a unified operations workplace, integrated batch (per ISA-88), historian, asset optimization, and safety (800xA High Integrity for SIL-rated loops) in one engineered environment. Its pitch is scale and lifecycle — thousands of I/O, multi-decade support horizons, and deep integration with ABB drives, motors, instrumentation, and electrical systems. It competes with Emerson DeltaV, Siemens PCS 7/PCS neo, and Honeywell Experion in the flagship tier, and selections turn on installed base, local support depth, and migration paths as much as on features.

Freelance: the compact DCS

ABB Freelance targets smaller process applications — skid builders, specialty chemical, food and beverage lines — that need DCS integration without flagship scale: compact controllers with built-in I/O, one engineering tool covering control, visualization, and trending, and a cost profile closer to high-end PLC systems. The honest comparison for Freelance is often "PLC + SCADA + historian quoted separately" rather than another DCS; it wins when engineering hours and integration risk dominate the hardware price.

DCS vs PLC/SCADA, decisively

Choose a DCS for continuous and large-batch processes where integrated alarming, historian, batch management, and operator environment outweigh flexibility — and where the vendor's lifecycle commitment protects a 20-year asset. Choose PLC/SCADA for discrete manufacturing, skids with heavy customization, multi-vendor best-of-breed strategies, and teams whose skills center on 61131-3. Hybrids are normal: DCS for the process island, PLCs for packaging and utilities, OPC UA between them.

Delivery matters as much as selection. Process automation specialists such as ASP Otomasyon — active since 2001 in turnkey automation design, modernization, installation, and commissioning — implement and modernize DCS and PLC installations end to end. ABB's portfolio overview lives under ABB Control Systems.

References

• ISA standards: ISA-95, ISA-88, ISA/IEC 62443
• Control Global — DCS and process automation coverage
• Chemical Processing — process industries publication

Capability comparison

• Routing: AGVs run deterministic loops; rerouting means moving infrastructure. AMRs accept goal points from a fleet manager and reroute around blocked aisles in real time.
• Deployment: AGVs need facility modification and commissioning per path. AMRs need mapping runs and traffic-rule configuration — faster to first vehicle, with the complexity moved into fleet software.
• Traffic: AGV crossings are engineered (zones, interlocks); AMR crossings are negotiated (fleet manager reservations plus onboard safety fields). Mixed fleets of both types are where traffic design gets genuinely hard.
• Payloads and precision: heavy AGVs (forklift-class and above) still dominate high-payload and precise docking niches, though heavy AMRs are closing the gap. Docking repeatability depends more on the specific vehicle and target design than on the acronym.
• Safety: both use laser scanners with protective fields and must satisfy machinery safety requirements (risk assessment per ISO 12100, and mobile-robot-specific standards such as ISO 3691-4 for driverless trucks). Autonomy does not relax the safety case — it moves it into software assurance and validation.

Choosing

Choose AGVs for fixed, high-volume, unchanging flows where determinism beats flexibility — and where the facility already has the infrastructure. Choose AMRs for dynamic environments, frequent layout changes, multi-stop workflows, and phased rollouts that start with two vehicles and grow. In both cases, budget more for the fleet manager, WMS/MES integration, and change management than for the vehicles: the robots are the easy part; the traffic rules, charging strategy, and operator trust decide whether the project survives month six.

References

• The Robot Report — robotics industry news and analysis
• ROS: Robot Operating System
• Automation World — material handling and manufacturing coverage