Industrial Automation Explained: PLCs, CNC Machines, Robots, Sensors, and Factory Software

This is Part 6 of Inside the Physical AI Factory. Part 5 turned the rover production route into a plant. Now we open the factory nervous system: the devices and software that sense conditions, make decisions, create motion, protect people, coordinate work, and preserve evidence of what happened.

Industrial automation is easiest to understand from the machine outward. A sensor detects that a rover frame has reached a fixture. A controller evaluates the signal and the machine state. A drive regulates a motor. An actuator moves a clamp. A safety system watches a separate set of conditions. An operator interface explains what the cell is doing. Networks carry selected information to supervisory and production systems. The production record eventually receives the result.

The factory is not one computer with a large dashboard. It is a collection of control loops operating at different speeds, with different consequences, owners, and evidence requirements. A motion controller may update an axis far faster than an enterprise planning system needs to know that the work order has started. A safety function must reach a defined safe state without depending on a cloud service or a language model. A maintenance planner can tolerate minutes of delay that a servo loop cannot.

This report follows one illustrative rover production order from business planning to physical action and back into the production record. It also draws a boundary between conventional automation and physical AI. The goal is not to replace proven control. It is to see where perception, learning, planning, and adaptation can add value without weakening deterministic behavior, functional safety, traceability, or operating ownership.

Industrial automation uses sensing, logic, communication, and controlled energy to make a physical process repeatable. Sensors measure the world. Controllers compare those measurements with commands and permitted states. Actuators, motors, valves, and other final elements change the process. Feedback tells the controller whether the expected result occurred.

The most important design question is not whether a factory is automated. It is which decision belongs at which layer. Fast motion belongs close to the machine. Safety functions belong in validated safety related control. Cell sequencing belongs in the machine or cell controller. Production dispatch and genealogy belong in manufacturing operations systems. Orders, inventory value, purchasing, and financial commitments belong in enterprise systems. Data may cross these boundaries, but responsibility should remain explicit.

NIST defines a control loop as sensors, controller hardware, actuators, and communication of variables. The controlled condition is measured, compared with a set point or logic state, acted upon, and measured again. Disturbances make feedback necessary because a command is not proof of a result.

Consider a rover wheel torque station. The fixture reports that the rover is present. A clamp sensor confirms the part is secured. The controller permits the tightening sequence. A servo or tightening controller applies a commanded profile. Torque and angle feedback show whether the joint reached its acceptance window. The controller records pass, fail, or fault. If the guard opens or a safety device changes state, the safety function removes or controls hazardous energy according to the validated design.

Open loop control issues a command without using process feedback to correct the result. Closed loop control measures the result and adjusts the command. Both exist in factories. A timed indicator light may be open loop. Servo position, temperature regulation, pressure control, and web tension are usually closed loop. The correct choice depends on the process, required accuracy, dynamics, risk, and evidence.

A sensor is a claim about the physical world. It may report that a part is present, an axis is at a position, a tank has reached a level, a motor is hot, a tool produced the required torque, or an image contains a suspected defect. The usefulness of the claim depends on range, resolution, accuracy, repeatability, response time, mounting, environment, calibration, diagnostics, and the way the signal reaches the controller.

Discrete sensors usually represent states such as on or off. Analog sensors represent a continuous quantity such as pressure or temperature. Encoders measure position or speed. Vision systems convert light into images and derived measurements. Identification devices connect a physical item with an identity. Condition monitoring sensors observe vibration, current, temperature, sound, lubrication, or other health indicators.

Selection starts with the failure the process must detect. A shiny black rover enclosure, changing ambient light, dust, vibration, electromagnetic noise, cable damage, and target variation can all break an apparently simple presence check. Good automation engineering tests the sensing principle against real parts and abnormal conditions. It also makes failures visible. A sensor stuck on should not quietly look like a continuously present part.

An actuator converts energy into a physical change. Pneumatic cylinders create linear motion from compressed air. Hydraulic cylinders produce high force from pressurized fluid. Solenoid valves route flow. Electric motors rotate conveyors, pumps, fans, spindles, joints, and positioning axes. Contactors and solid state devices switch electrical loads. The controller requests action, but the actuator and mechanical transmission determine what force, torque, speed, travel, and stopping behavior are physically possible.

A motor is not selected by power alone. The load profile, speed range, starting torque, duty cycle, inertia, acceleration, ambient conditions, enclosure, efficiency, feedback, braking, and mechanical transmission all matter. The drive and motor should be treated as part of a system. The US Department of Energy recommends a system view of motor performance and variable speed control where demand varies.

Pneumatics can be simple and fast, but compressed air is not free and air compressibility affects precision. Hydraulics support high force but introduce fluid, heat, maintenance, and leak considerations. Electric motion offers clean and precise control, but it needs correct sizing, protection, feedback, tuning, and safe energy control. The cheapest component is not necessarily the lowest cost mechanism once utilities, controls, maintenance, downtime, and quality are included.

A programmable logic controller is an industrial computer built to execute control logic reliably around machines and processes. It reads inputs, executes a program, updates outputs, communicates with devices, and performs diagnostics. This simplified scan model is useful, although modern controllers also use periodic tasks, event tasks, motion tasks, communication services, and distributed I/O that do not all wait for one monolithic scan.

The current IEC 61131 Part 3 specifies structured text, ladder diagram, and function block diagram, with sequential function chart elements for organizing programs and function blocks. The language is only one part of a maintainable system. Naming, state models, reusable modules, alarm design, version control, simulation, test records, access control, backups, and change management determine whether the plant can support the code for years.

The rover cell PLC might own fixture sequencing, interlocks, mode management, recipe transfer, handshake with a tightening controller, pass or fail routing, alarms, and production system communication. It should not silently infer a safe state from ordinary process data when a validated safety function is required. It should also reject impossible or stale commands, identify which product variant it is running, and preserve enough context for recovery after a stop.

A standard control system is designed to make the process operate. A safety related control system performs safety functions that reduce risk. The two may share hardware families, networks, engineering tools, or enclosures, but the safety function has its own risk assessment, required performance, architecture, diagnostics, verification, validation, and change control.

ISO 13849 Part 1 provides a methodology for designing and integrating safety related parts of control systems. IEC 62061 addresses the design, integration, and validation of safety related control systems for machinery. OSHA also requires guarding methods that protect operators from points of operation, rotating parts, flying chips, and other machine hazards. The applicable legal and standards framework depends on the machine and jurisdiction, so qualified safety engineering is essential.

A safety PLC does not make an unsafe machine safe by itself. The complete function starts with the protective device or input, includes logic and diagnostics, ends at the power control elements, and depends on the mechanical system reaching the required safe condition. Emergency stop, guard interlocking, safe torque off, safe speed, light curtains, scanners, pressure release, braking, and restart prevention are different functions. Each needs a defined response and proof that the response works.

A human machine interface gives an operator a structured view of the machine or cell. It can show mode, state, commands, permissives, measurements, alarms, recipes, and maintenance information. A supervisory control and data acquisition system usually spans a wider process or site, collecting data, presenting status, managing alarms, and sometimes providing supervisory commands and history.

The screen should explain the process, not decorate it. Color needs a defined meaning. Alarm priority should reflect consequence and urgency. A stopped sequence should show which permissive is missing. Units, limits, quality, time, source, and communication status should be visible where they affect interpretation. Operator commands need role based permissions and clear feedback that the command was accepted or rejected.

An HMI is not the primary safety device unless the complete safety function is specifically designed and validated for that purpose. A screen can explain that a guard is open, but ordinary HMI communication should not be the only path that stops hazardous motion. The operator view, control logic, and safety logic should agree about machine state without confusing their responsibilities.

Computer numerical control coordinates machine axes, spindle behavior, tooling, offsets, and part programs to create a required geometry. The CNC interprets the machining program and manages motion, while a PLC function often handles machine sequencing, doors, clamps, coolant, tool change, auxiliaries, and interlocks. The boundary varies by machine architecture, but the CNC does more than turn a conventional PLC into a machine tool.

A robot system similarly combines several layers. The robot controller coordinates joint motion and kinematics. The application program defines paths, frames, tools, process steps, and handshakes. End effectors, vision, process equipment, guarding, safety functions, and the surrounding PLC make the robot useful as a cell. The robot arm alone is not the automation solution.

For the rover factory, a CNC might machine a low volume fixture plate or prototype bracket. A robot might load a test fixture, apply adhesive, present the rover to inspection, or move completed units. Both need product identification, tool and program control, safe interaction, recovery logic, quality evidence, maintenance access, and an owner who can support the complete cell.

A factory network is not one uniform pipe. Hardwired I/O can still be the right answer for simple or safety critical signals. Industrial Ethernet and field networks connect remote I/O, drives, instruments, robots, machine controllers, safety devices, and supervisory systems. Higher layers exchange production context, events, histories, files, and business transactions.

Network selection depends on timing, determinism, topology, device support, diagnostics, safety capability, cybersecurity, lifecycle, and the installed skill base. EtherNet/IP, PROFINET, EtherCAT, Modbus TCP, IO Link, CAN based networks, and vendor specific motion networks solve overlapping but different problems. Protocol names alone do not prove interoperability. A project must define the data model, update behavior, connection ownership, device profiles, diagnostics, failure state, version, and conformance evidence.

OPC UA provides platform independent services, security mechanisms, and information modeling for interoperable exchange from embedded devices toward enterprise systems. It can give data semantic context instead of exposing an unexplained list of tags. It does not remove the need to design identities, units, timestamps, quality, access, certificates, ownership, and lifecycle management.

The ISA 95 model describes activities from the physical process and sensing through control, manufacturing operations, and business planning. The model is useful because it organizes responsibility and information exchange. It should not be mistaken for a rule that every plant needs one product in every box or that every message must climb a rigid pyramid.

Enterprise resource planning manages business commitments such as sales orders, purchasing, inventory value, and financial records. Manufacturing operations management and manufacturing execution functions turn production demand into dispatched work, track status, enforce routes, preserve genealogy, and collect results. Quality systems manage specifications, inspections, nonconformance, and corrective action. Warehouse systems manage locations and movements. Maintenance systems manage assets, work, parts, and history. Product lifecycle systems manage product definitions and engineering change.

SCADA, historians, edge services, integration platforms, and data infrastructure move or preserve operating information. Their labels often overlap in the market. Buyers should define required activities, decisions, records, and interfaces before selecting products. A dashboard that visualizes downtime is not automatically an MES. A historian that stores process values is not automatically the authoritative product genealogy record.

Assume the business needs rover unit R1042 built to released product revision C. The example is illustrative. The exact systems, messages, and approval points differ by factory. The purpose is to show that one order changes form as it moves through planning, dispatch, control, physical work, verification, and completion.

The enterprise system creates or schedules the production requirement. Manufacturing operations verifies the route, material status, revision, resources, and due date, then dispatches work to the rover cell. The warehouse process delivers the kit. The operator identifies the order and unit. The cell checks that its program, recipe, tools, fixture, and connected devices are ready for revision C.

The PLC then owns the immediate sequence. It confirms safe and process permissives, clamps the rover, calls the correct tightening or robot program, and monitors feedback. Specialized controllers regulate the detailed motion or process. Sensors prove physical states. Each operation returns a result with identity, time, units, limits, status, and relevant context. A failure stops or routes the work according to released logic.

Manufacturing operations receives completion and result data, updates genealogy, and advances the unit only when required evidence exists. A quality failure creates a controlled exception rather than a green dashboard. When all required operations pass, the production record closes. Enterprise inventory and order status can then update from a trusted manufacturing event rather than from an operator retyping what the machine already knew.

Conventional automation is strongest when the task, inputs, states, and required response can be defined. It repeats a released sequence, executes motion, enforces interlocks, regulates variables, and records known outcomes. Physical AI becomes interesting when the environment contains meaningful variation that fixed rules cannot economically enumerate, such as variable object pose, visual ambiguity, unstructured movement, complex planning, or patterns across large operating histories.

The boundary should be based on authority and consequence. An AI model may propose a robot grasp, classify an image, forecast a bearing problem, recommend a schedule, or identify an unusual process pattern. The deterministic system can validate range, identity, readiness, collision constraints, process state, and permitted action before execution. A validated safety system remains responsible for the defined safety function.

Learning does not eliminate engineering. The AI function needs an operating design domain, representative evaluation data, confidence handling, latency limits, monitoring, version control, rollback, cybersecurity, and a safe fallback. Human review may be appropriate for rare or costly decisions. A model that performs well on average can still be unsuitable when the missed case creates injury, equipment damage, or an undetected product defect.

NIST SP 800 Part 82 Revision 3 emphasizes that operational technology security must account for performance, reliability, and safety requirements. An automation network cannot be secured by treating it as an ordinary office network, nor should operational urgency become an excuse for unmanaged remote access, shared accounts, unsupported systems, or flat connectivity.

Start with an asset inventory, architecture, data flows, trust boundaries, owners, supported versions, backups, and recovery procedures. Segment by risk and function. Control remote access. Use named identities and least privilege where the technology supports them. Manage removable media and engineering workstations. Monitor changes and unusual communication. Test backups by restoring them. Coordinate patching with vendors, operations, safety, and production windows.

Availability is not merely keeping the network online. The plant must recover the correct controller program, robot job, drive parameters, safety configuration, HMI application, recipe, certificate, and interface version. A backup without a tested device replacement process may still leave the line stopped. A secure design also protects the integrity of product identity and quality records, because false context can produce a physically correct operation on the wrong product.

Automation acceptance should begin before hardware arrives. Define the sequence, modes, states, interfaces, alarms, recipes, safety functions, data records, user roles, performance targets, and recovery cases. Simulate what can be tested early. A factory acceptance test can verify panels, code, devices, and representative sequences. Site acceptance adds installed utilities, real material, connected systems, operators, maintenance, production conditions, and final safety validation.

Test normal production and abnormal production. Remove a sensor. Interrupt communication. Present the wrong part. Lose power during a sequence. Open a guard at different moments. Reject a measurement. Restore from backup. Change a recipe with and without permission. Restart after the robot has moved but the production record has not updated. Verify that each layer reaches a known condition without duplicate work or lost genealogy.

The delivered system needs more than source code. It needs network drawings, electrical and pneumatic drawings, bills of material, safety documentation, risk assessment, programs, parameters, licenses, certificates, backups, version history, interface definitions, test records, calibration information, spare strategy, maintenance instructions, training, and named ownership. The plant buys a lifecycle, not only a successful demonstration.

The first mistake is automating an unstable or poorly understood process. The second is selecting components before defining the control and safety requirements. The third is treating a sensor signal as unquestionable truth. The fourth is assuming that a robot arm, PLC, or software license is a complete production system. The fifth is using one system as the ungoverned owner of every decision.

The sixth is designing only the normal automatic cycle and leaving manual mode, faults, restarts, rejects, and recovery to the end. The seventh is mixing ordinary control and safety responsibility without a validated architecture. The eighth is connecting systems without defining identity, time, units, quality, ownership, stale data, or failure behavior. The ninth is buying a dashboard before defining the operating action it should support.

The tenth is adding AI because variation exists without defining the allowed decision, consequence, evaluation evidence, fallback, monitor, and owner. Physical AI should enlarge the set of conditions the factory can handle while preserving a clear path back to deterministic control and safe operation.

You should now be able to trace a machine action from sensor through controller, drive, actuator, process, and feedback. You should be able to distinguish a standard PLC from a safety controller, a VFD from a servo drive, a CNC from a general machine sequence, an HMI from an MES, and an enterprise order from a real time control command.

The central idea is that automation is an architecture of decisions. Fast, consequential, and safety related decisions stay close to validated control. Production systems add identity, route, genealogy, and coordination. Enterprise systems add business commitments. Physical AI can perceive, recommend, plan, and adapt where variation justifies it, but only inside an engineered boundary with deterministic checks, monitored performance, and a safe fallback.

Part 7 will move from automation that repeats a defined sequence to physical AI that can interpret and adapt. We will connect robotics, machine vision, edge inference, digital twins, predictive maintenance, autonomous material movement, and intelligent production decisions without losing sight of safety, process capability, or economics.

The rover factory will return again. We will identify the applications where learning can outperform fixed rules, define the data and edge architecture each application needs, and examine how a factory can test adaptive behavior before granting it more authority over physical work.

This report uses NIST guidance for the control loop and operational technology security. IEC 61131 Part 3 supports the programmable controller language discussion. ISO 13849 Part 1 and IEC 62061 support the safety related control boundary. OSHA materials support the general guarding requirement. ISA 95 supports the enterprise and manufacturing activity model. OPC Foundation materials support the interoperability and information modeling discussion. US Department of Energy Better Plants materials support the motor and drive system view.

Protocol organizations and supplier documentation were reviewed to confirm terminology and representative architectures. Product names and protocol families are examples, not endorsements or claims that one technology fits every application. Capabilities described by vendors are treated as vendor claims unless independently verified in a specific deployment.

The rover order, cell sequence, program structure, interface questions, acceptance framework, and deterministic versus adaptive boundary are Black Scarab teaching frameworks. They do not describe a real factory, validated safety design, legal requirement, guaranteed performance, or recommended purchase. Industrial automation requires qualified control, electrical, mechanical, safety, cybersecurity, manufacturing, quality, operations, and maintenance review for the actual application and jurisdiction.