Industrial Automation and Smart Manufacturing

01Purpose and scope

• This manual supports the course Industrial Automation and Smart Manufacturing. It is written for controls engineers, automation technicians, process engineers, production supervisors, and maintenance leads who take part in designing, installing, or improving automated equipment and the data systems that connect it to the plant.
• The scope covers machine and line automation built on programmable logic controllers, motion control, robots, machine vision, and industrial sensors, along with the networks and software that link equipment to supervisory control, manufacturing execution systems, and enterprise planning. It does not cover product design, materials selection, or the business case for capital investment in depth, although those decisions shape what gets automated.
• Practice changes a great deal by context. A discrete parts plant building automotive subassemblies works with fast cycle times, many robots, and frequent changeovers. A batch chemical or food plant works with recipes, cleaning cycles, and regulatory records. A small job shop may have a handful of machines and a single controls person who also handles maintenance. The same principles apply in each setting, but the tools, staffing, and acceptable risk look different. Treat this manual as a reference for how the work is usually organized, then adapt it to the plant in front of you.

02Core principles

• Automation should follow the process, not the other way around. Before writing any logic, the team needs a clear description of what the machine or line must do in each normal state, each fault state, and each stop. Most rework in automation projects comes from sequences that were never defined clearly enough to test.
• Design for safe states first. Every output that can move something, heat something, or release energy needs a defined condition when power is lost, communications drop, or an operator opens a guard. Safety functions should be handled by certified safety hardware and logic rather than standard control logic, and the separation between the two should be visible in the architecture.
• Keep the control structure modular. Reusable function blocks for common devices such as valves, drives, and pneumatic cylinders reduce errors and make later changes easier to review. A library that is poorly maintained can cause more harm than having no library, so each block needs an owner, documentation, and a version history.
• Treat data as a product of the process, not a side effect. Tags, timestamps, alarm states, and production counts are only useful if their meaning is agreed upon. A count of parts that pass a sensor is not the same as a count of good parts, and the difference matters for every metric built on top of it.
• Plan for people who will operate and maintain the system after commissioning. The control logic has to make sense to a technician at two in the morning. Naming conventions, consistent alarm text, and clear HMI screens are part of the engineering work, not decoration added at the end.

03Planning and preparation

• Start with a functional specification that describes inputs, outputs, sequences, interlocks, alarms, operator actions, and performance targets such as cycle time, first-pass yield, and changeover duration. Review it with operations and maintenance before any hardware is ordered. A specification signed off only by engineering often misses the manual workarounds that operators already rely on, and those workarounds usually need to be designed in or deliberately removed.
• Build a process and instrumentation inventory. List every actuator, sensor, drive, network device, and safety component with its location, signal type, and power requirements. Confirm which devices already exist, which are being reused from another line, and which will need replacement. Reused equipment frequently carries old firmware, undocumented wiring, or legacy protocols, so budget time to verify it on the bench.
• Define the network and information architecture early. Many plants use a layered model similar to the one described in ISA-95 and IEC 62264, which separates control devices, supervisory systems, and business systems. Decide which data leaves the machine network, how it is secured, and which system is the source of truth for recipes, work orders, and genealogy. Changes to this architecture after installation are expensive.
• Establish the cybersecurity baseline. IEC 62443 is the widely used series for industrial control system security, and its concepts of zones, conduits, and security levels give a useful vocabulary for planning. Identify which remote access paths exist, who approves them, and how software and firmware updates are tested and approved before they reach the floor.
• Prepare the test environment. Where possible, build a virtual commissioning model, a simulator, or a bench setup with the same PLC model and firmware as the production system. Even a partial simulation of the sequence logic will expose timing problems and interlock gaps that are hard to find on a running machine. Plan for the limits: simulation rarely reproduces friction, wear, sensor noise, or the actual timing of pneumatic valves, so physical tests still have to happen.

04Recommended workflow

1. 1
   : Confirm the requirements with the people who will use the machine. Walk the line with operators and maintenance, record the current manual steps, and identify where the new automation must match or improve on them. Write the acceptance criteria in measurable terms, such as a maximum cycle time, a required fault recovery method, or a defined reject rate.
2. 2
   : Complete the electrical and mechanical design review. Check power distribution, grounding, motor sizing, pneumatic supply, and enclosure ratings against the site conditions. Review the drawings for consistent tag numbers and wire labels. Electrical design for industrial machinery is governed by local rules and by standards such as NFPA 79 in North America, so confirm the applicable requirements with the authority having jurisdiction and the plant electrical engineer.
3. 3
   : Develop the control program in small, testable units. Write the logic for one station or one device at a time, use the standard programming languages described in IEC 61131-3 where the platform supports them, and keep the sequence structure visible through state machines or equivalent step logic. Each unit should have a clear entry condition, exit condition, and fault path.
4. 4
   : Build the operator interface and alarm structure. Define the screens, buttons, and permissions. Give every alarm a unique identifier, a plain description, a probable cause list, and a recommended first action. Alarms that cannot be acted on should be reviewed for removal, because operators learn to ignore them quickly.
5. 5
   : Test the safety functions and the basic sequences on the bench. Verify each emergency stop, light curtain, safety door, and two-hand control against its specified response. Record the test results, including the failures and how they were corrected. Safety validation should follow the approved procedure for the plant and the applicable machinery safety standards, and the results should be reviewed by a qualified safety professional.
6. 6
   : Commission on the physical equipment in stages. Start with manual mode and single-axis or single-device movements, then move to single-cycle operation, and only then to automatic production. Check each interlock by deliberately creating the condition it guards against. Keep a log of every change made during commissioning, because undocumented on-machine edits are one of the most common sources of later trouble.
7. 7
   : Run a supervised production period and collect data. Compare actual cycle time, stoppage causes, and quality results with the acceptance criteria. Hold a review with operators and maintenance at the end of the period to decide which issues require program changes, mechanical adjustments, or training.
8. 8
   : Hand over the system with complete documentation. Deliver the final program, drawings, network maps, backup files, spare parts list, and training records. Store the backup in a controlled location and confirm that it can be restored onto a spare controller before the project is closed.

05Quality checks, risk controls and compliance

• Quality checks in automation projects happen at several levels. Program reviews check logic against the functional specification, looking for missing interlocks, unhandled faults, and states that cannot be exited. Peer review of logic is one of the most effective checks available, and it works best when the reviewer has a checklist tied to the specification rather than a general impression of the code.
• Risk assessment is required for machinery in most jurisdictions, and it should be done systematically. ISO 12100 describes the general method for risk assessment and risk reduction for machinery, and ISO 10218 addresses safety requirements for industrial robots and robot systems. Use these as the basis for the assessment, record each identified hazard, and show how each risk is reduced through design, guarding, or procedures. Confirm the current editions and any regional adoption with the relevant authority.
• Functional safety requires a defined target level and evidence that the safety-related parts of the control system meet it. IEC 62061 and ISO 13849 are the common frameworks for machinery safety control functions. Their application requires specialist judgment about component reliability, diagnostic coverage, and architecture, so the work should be performed or reviewed by qualified functional safety personnel.
• Data quality checks matter as much as machine checks. Verify that counters reset at the right points, that timestamps are synchronized across devices, and that production records reflect the real parts processed. A test run with a known number of parts is a simple and effective way to confirm that the data path is correct.
• This guidance does not replace qualified professional judgment, approved procedures, or required authorization. Electrical work, safety system validation, changes to regulated production records, and remote access to critical systems must follow the plant's documented approvals and any applicable legal or industry requirements. Where a regulation is involved, such as food, pharmaceutical, or medical device manufacturing, check the current requirements for computerized systems and electronic records with the quality function.

06Collaboration and documentation

• Automation projects involve many roles that rarely share the same vocabulary. Controls engineers, mechanical designers, process engineers, IT staff, safety personnel, quality teams, and maintenance technicians each hold part of the picture. Regular short reviews with a fixed agenda work better than one large review at the end. Invite operators to at least some of these reviews, since they often see problems that the drawings do not show.
• Responsibilities should be written down. A simple responsibility matrix that names who owns the specification, the program, the network, the safety validation, the HMI, and the spare parts list prevents the common situation where everyone assumes someone else has handled a critical item. Keep the matrix current as people change roles.
• Documentation is part of the product. The minimum useful set includes the functional specification, the revised electrical and pneumatic drawings, the I/O list, the program with comments on each sequence, the alarm list, the network diagram, the backup files, and the test records. Store these in a version-controlled system with clear naming. A project folder full of files named final, final2 and revised is a maintenance hazard.
• Change control is essential once a line is running. Every change to logic, setpoints, or hardware should be requested, reviewed, approved, tested where feasible, and logged. Emergency fixes happen, but they should be documented after the fact and reviewed within a short time. Where the plant uses a formal management of change process, the automation changes should go through it without exception.
• Vendors and integrators bring useful expertise, but their documentation and support terms need to be checked. Confirm who owns the source code, what remote access they have, how long they will support the hardware, and what happens if the integrator is no longer available. These questions are easier to answer before the contract is signed.

07Measures and continuous improvement

• Overall equipment effectiveness is the most common single measure of machine performance, combining availability, performance, and quality. It is useful for trend tracking but can mislead when the inputs are inconsistent, such as when planned stops are counted differently from line to line or when cycle time standards are set without an agreed method. Define each term, record how it is calculated, and apply the same definition across comparable lines.
• Other useful indicators include mean time between failures and mean time to repair for critical equipment, first-pass yield, changeover time, unplanned stop count by cause, alarm frequency per shift, and the number of manual interventions required per hundred cycles. Pick a small set that the team will actually review. A dashboard with forty measures tends to be ignored.
• Continuous improvement in automated lines usually comes from examining stop data. Pareto analysis of stop causes often reveals that a few recurring faults account for most lost time. Address these with targeted changes, such as sensor repositioning, improved part presentation, or better fault recovery logic, and then check whether the stop frequency changed.
• Data collection can become a burden if it is not designed carefully. Automatic collection from the controller is more reliable than manual logs, but it still requires validation. Set a review frequency that matches the process, weekly for many lines and daily for those with high variability, and assign a named owner for each metric.
• The limits of automation metrics should be acknowledged. A line with high measured output may still be creating downstream rework, unsafe workarounds, or hidden maintenance debt. Pair production measures with safety observations, maintenance backlog, and operator feedback to get a fuller picture.

08Common mistakes and how to prevent them

• Writing logic before the sequence is defined is the most frequent error. The program ends up encoding assumptions that nobody checked, and the team spends weeks fixing edge cases during commissioning. Prevent this by requiring a signed functional specification with state diagrams before programming starts.
• Skipping the physical verification of sensors and actuators causes many late surprises. A proximity sensor that works on the bench may fail when it sees a metal fixture or a reflective surface on the floor. Verify each device in its installed location, under the actual lighting, temperature, and vibration conditions.
• Allowing uncontrolled changes on the machine creates a version problem that lasts for years. The controller in the cabinet no longer matches the files in the project folder, and nobody can restore the line confidently after a failure. Enforce a rule that the controller is backed up after each approved change and that the backup is logged.
• Treating alarms as an afterthought leads to nuisance alarms and operator fatigue. Review alarm frequency regularly, remove or reclassify alarms that do not require action, and make sure every remaining alarm has a documented response.
• Underestimating network and security work often delays projects. Plan the network segmentation, firewall rules, and remote access approvals early, and test them with the actual devices. Do not rely on the assumption that a plant network is isolated from the internet.
• Neglecting training for maintenance and operations shifts the burden to the original programmers, who are often unavailable. Include hands-on training, written troubleshooting guides, and a simulator or bench exercise in the handover plan.

09Practical checklist

• Confirm the functional specification, including sequences, faults, and acceptance criteria, has been reviewed by operations and maintenance.
• Verify the process and instrumentation inventory matches the installed equipment and that reused devices have been tested.
• Confirm the network architecture, zone boundaries, and remote access approvals are documented and reviewed.
• Check that the risk assessment is complete and that each hazard has a recorded reduction measure.
• Verify safety functions against their specified responses and retain the signed test records.
• Review the control program with a peer reviewer using a checklist tied to the specification.
• Confirm the alarm list has unique identifiers, clear descriptions, and a documented first action for each alarm.
• Perform staged commissioning in manual, single-cycle, and automatic modes with each change logged.
• Validate production data by running a known count of parts and comparing the recorded results.
• Back up the controller and HMI, test restoration on a spare, and store the files in a controlled location.
• Hand over drawings, program, network maps, training records, and the spare parts list to the owning team.
• Schedule the first metric review and assign a named owner for each measure.

★Learning sources

• Micro Degree: Industrial Automation and Smart Manufacturing
• Micro Degree: Solar Power Systems
• Micro Degree: Energy Management and Audit
• Micro Degree: Industry 4.0 Technologies