Robotics, IoT and Industrial Automation Engineering

01Purpose and scope

• This manual supports the course Robotics, IoT and Industrial Automation Engineering, and it describes how the work is actually carried out in plants, test labs and integration shops. It is written for engineers, technicians, integrators and project leads who design, commission or support systems that combine programmable controllers, industrial robots, sensor networks and supervisory software.
• The scope covers the full life of an automated cell or line: defining the process, selecting hardware, writing control logic, connecting field devices to higher level systems, proving the installation works, and keeping it running. It does not cover consumer electronics, hobby projects or the research side of robot learning, although many of the same tools appear there.
• Stakeholders usually include production operations, maintenance, process engineering, controls and robotics engineers, IT and network staff, safety and environmental health officers, and equipment vendors. Each group holds a different piece of the risk, and most failed projects can be traced to one group learning about a requirement late.
• Machinery safety, electrical installation, cybersecurity and data handling are governed by rules that vary by country, state and sector. Where this manual refers to a standard, check the current edition and the local authority having jurisdiction. This guidance does not replace qualified professional judgment, approved site procedures or the formal authorization required before energizing equipment, isolating energy sources or connecting a control network to a plant system.

02Core principles

• Safety comes before throughput. A cell that stops reliably under fault conditions is worth more than one that runs faster but cannot be made safe to enter. Safety functions should be designed as their own layer, using certified safety controllers or safety rated devices where the risk assessment requires them, rather than being mixed into standard control logic.
• Separate control traffic from business traffic. Field buses and real time control loops should not share a flat network with office systems. A common pattern is a segmented architecture with a demilitarized zone between the plant network and the enterprise network, with data flowing out through a gateway that only passes approved message types. The ISA-95 model is a useful reference for thinking about levels from field devices up to planning systems.
• Design for deterministic behavior first and connectivity second. An IoT sensor that publishes data every few seconds is valuable for trend analysis but cannot replace a hardwired interlock. Use local control for anything that must react within a fixed time, and use cloud or enterprise platforms for analytics, reporting and remote diagnostics.
• Keep the I/O documented and the logic readable. Tag names, device addresses, alarm texts and program structure should follow a naming convention that a maintenance technician can understand at two in the morning. Reuse tested function blocks and modules instead of rewriting the same motor or valve logic for every machine.
• Accept trade-offs openly. Robot programs written offline save commissioning time but need careful calibration against the real cell. Wireless sensors reduce cabling cost but introduce interference, battery replacement work and security exposure. Edge computing lowers latency but moves maintenance responsibility onto the plant team. Record these choices and the reasons for them.

03Planning and preparation

• Start with the process, not the hardware. Write down the cycle time target, the part variants to be handled, the expected volume, the tolerances, the operator interaction points and the output records required by the customer or by internal quality procedures. These answers drive the choice of robot reach, payload, gripper design, controller platform and sensor types.
• Walk the site before finalizing the design. Measure floor space, power supply capacity, compressed air quality, ambient temperature, dust, vibration, lighting and existing network infrastructure. Photograph the current process and note where material sits, where people stand and where existing equipment interfaces with the new cell. Many commissioning delays come from a missing utility or a wall that was not on the drawing.
• Build the I/O list and the network architecture early. For each device, record signal type, voltage, wiring method, protocol, address, update rate and the function it supports. Draw the network with switch locations, IP ranges, gateway roles and firewall rules. These two documents become the reference for electricians, programmers and network staff, so they must agree with each other.
• Run a risk assessment before purchase orders are placed where possible. Use a recognized method such as the hazard identification and risk estimation approach described in ISO 12100 for machinery. For robot cells, identify pinch points, stored energy, collision zones, tool hazards and access points. The outputs define guarding, light curtains, safe speed limits, interlock requirements and training needs.
• Agree on acceptance criteria in writing. Define what counts as a successful factory acceptance test and site acceptance test, including cycle time, reject rates, alarm behavior, emergency stop response, data delivery and operator usability. Vague goals such as works reliably cannot be tested and will lead to disputes.

04Recommended workflow

1. 1
   : Define the functional specification. Document the sequence of operations, interlocks, modes of operation such as automatic, manual and maintenance, and the fault responses expected for each device. Get sign-off from operations and maintenance before any code is written.
2. 2
   : Select and size the hardware. Choose controllers, drives, robot models, grippers, sensors and network devices against the specification. Check spare parts availability and local service support, since a robot that needs a vendor visit for every fault may not suit a site with limited support.
3. 3
   : Design the electrical and control panels. Produce schematics, panel layouts, cable schedules and bills of materials. Separate power and signal wiring, label every terminal and conductor, and confirm that the panel layout meets the heat dissipation and access requirements of the components selected.
4. 4
   : Program the controllers and robots. Use the IEC 61131-3 languages where the platform supports them, structured text for calculations and state machines, ladder or function block diagrams for discrete logic that maintenance staff read often. Build the safety logic in a separate program on the safety controller. Write robot programs with named positions, tool frames and clear exit conditions.
5. 5
   : Integrate the IoT and data layer. Configure field gateways, select protocols such as OPC UA or MQTT where they fit the architecture, set publishing intervals and define the data model. Test the failure behavior by disconnecting the network and confirming that local control continues and buffered data is handled as specified.
6. 6
   : Perform the factory acceptance test. Run the system on the bench or at the integrator site with simulated inputs where real process signals are not available. Test each interlock, each alarm and each mode transition. Record results against the acceptance criteria, and log every deviation with an owner and a closure date.
7. 7
   : Commission on site and hand over. Install, verify wiring against the schematics, check motor rotation and robot calibration, run the cell at reduced speed, then increase toward production rate. Complete the site acceptance test with production operators present, then transfer the program, documentation, spare parts list and training records to the owning team.

05Quality checks, risk controls and compliance

• Verify each safety function with a defined test. Confirm that emergency stops remove power to the correct drives, that guard door interlocks stop motion before access is possible, and that safe speed or safe zone functions activate at the set limits. Record the measured stopping distances or times where they matter to the guarding design. These tests should be repeated after any change to the safety logic or hardware.
• Check the robot cell against the applicable robot safety requirements, such as the ISO 10218 series for industrial robots, and against the machinery directive or regulation that applies in your market. Your organization or a notified body may need to certify the installation. Confirm the requirements with the local authority and with your safety engineer before sign-off.
• Apply cybersecurity controls to the operational technology network. The IEC 62443 series is the most widely used framework for industrial automation and control systems. Common controls include network segmentation, role based access to engineering workstations, disabling unused ports and services, managed firmware updates, password policies for controllers, and backup of controller programs with checksums or version records.
• Test data quality before relying on it. Sensors drift, thermocouples are miswired and timestamps from different devices may not align. Compare sensor readings against a calibrated reference at set intervals, verify time synchronization across controllers and gateways, and flag values that fall outside the physical range of the process.
• Maintain electrical and lockout procedures. Energy isolation must follow the site lockout tagout program. Robot work envelopes, stored pneumatic energy and capacitor banks in drives can remain hazardous after power is removed. Anyone performing maintenance inside a cell should be trained and authorized for that task.
• Watch for regulatory and sector rules that apply to specific products or environments. Food, pharmaceutical, medical device and hazardous area installations add requirements for validation, materials, cleaning, electrical classification and record keeping. These rules differ by jurisdiction and sector, so consult the current authoritative source and the qualified professionals responsible for the site.

06Collaboration and documentation

• Keep one controlled set of documents for each system. This usually includes the functional specification, control narrative, I/O list, network diagram, electrical schematics, robot program listing, safety validation report, test records, alarm list, operator and maintenance manuals, and a change log. Store them in a version controlled location with a named owner for each document.
• Treat the control program as a managed document. Use a source control or archive system for PLC and robot programs, record who changed what and why, and require a review before a change is downloaded to a running machine. Many production incidents trace back to an untracked online edit made to fix a problem quickly.
• Hold regular reviews between disciplines. A weekly meeting between controls, mechanical design, network staff, maintenance and production is often enough during commissioning. Use the meeting to resolve open items from the punch list, confirm interface assumptions and agree on who will act on each change request.
• Write documentation for the reader who will need it. Operators need short procedures with pictures. Maintenance technicians need fault codes, troubleshooting trees and spare parts identifiers. Engineers need design rationale, such as why a particular interlock exists or why a value was chosen for a timer. Keep these as separate sections rather than one long manual that nobody reads.

07Measures and continuous improvement

• Choose indicators that reflect the purpose of the system. Common measures include overall equipment effectiveness, availability, cycle time against target, first pass yield, mean time between failures, mean time to repair, alarm count per shift, and the share of alarms that require operator action. Define each measure precisely, including its data source and calculation, before reporting it.
• Track alarm quality as well as alarm quantity. A cell that produces dozens of nuisance alarms per shift teaches operators to ignore alarms. Review the alarm log monthly or on a set schedule, remove duplicates, adjust thresholds with engineering approval and document the changes.
• Use fault data to guide improvements. When a robot stops repeatedly with the same error, check whether the cause is a mechanical issue, a sensor setting, a program timing problem or a material variation. Fix the root cause and record it in the change log, so the same problem does not return after the original engineer moves to another project.
• Revisit the risk assessment after changes. A new tool, a faster speed, a different part family or an added operator station can change the hazards. Repeat the relevant part of the assessment before the change goes into production, not after an incident.
• Compare performance across similar cells, but account for differences. Two lines producing the same part may have different cycle times because of layout, material handling or operator practice. Use comparisons to find questions to ask, not as a final judgment.

08Common mistakes and how to prevent them

• Commissioning from an incomplete I/O list. When wiring is done from memory or from a mark up drawing, mismatches appear during testing and the fix becomes slow and expensive. Prevent this by freezing the I/O list before panel fabrication and checking every field wire against it during installation.
• Mixing safety and standard logic. Placing safety interlocks in the same program as routine sequencing makes validation difficult and invites accidental changes. Use a separate safety program or controller with restricted edit access.
• Connecting IoT devices to the plant network without a security review. Default passwords, open remote access ports and unmanaged switches are frequent findings in audits. Involve the network and security team early, and require a documented approval before any new device joins the control network.
• Underestimating the time needed for site commissioning. Installation, debugging and operator training often take longer than the plan allows, especially when production must keep running in parallel. Build time for debugging, schedule downtime windows with the operations team, and agree on fallback procedures.
• Leaving documentation until the end. When drawings and programs are updated after handover, the records rarely match the installed system. Update documents at each change, and make the as-built review part of the acceptance criteria.
• Relying on one person's knowledge. When a single programmer or technician holds the only understanding of a machine, every fault becomes a dependency. Share responsibilities, write down design decisions and run cross training.

09Practical checklist

• Confirm the functional specification and acceptance criteria are signed by operations and maintenance.
• Verify the risk assessment is current and that each hazard has a named control measure.
• Check the I/O list matches the electrical schematics and the installed wiring.
• Separate safety logic from standard control logic and restrict edit access to both.
• Confirm the network diagram shows segmentation, gateway roles and approved remote access paths.
• Test every emergency stop, guard interlock and safe speed function and record the results.
• Back up controller and robot programs with version identifiers stored in a controlled location.
• Validate sensor readings against a calibrated reference and confirm time synchronization across devices.
• Confirm local control continues safely when the network or cloud connection is lost.
• Verify that lockout tagout procedures and training records cover the cell and its maintenance tasks.
• Review the alarm list for duplicates and nuisance alarms before handover.
• Hand over documentation, spare parts lists, fault guides and training records to the owning team.

★Learning sources

• Micro Degree: Robotics, IoT and Industrial Automation Engineering
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics