Choose how you want to explore this guide:
Documentation Receipt & Analysis
Phase 1 of 10 — The starting point of every project
Every automation project begins with the receipt of engineering documentation. The automation engineer must analyse, understand and validate these documents before taking a single step. This is the time to ask questions, detect inconsistencies and establish the true scope of the work.
Inputs
- FDS (Functional Design Specification) or URS
- P&ID (Piping & Instrumentation Diagram)
- Equipment list with specifications
- Preliminary I/O list
- Process narratives and flow diagrams
- Cause & Effect Matrix (if available)
Outputs
- Reviewed and annotated documentation
- RFI list (Requests for Information)
- Initial scope and hours estimate
- Requirements traceability matrix
- Technical feasibility report
Tips & Best Practices
- Always request the latest revision of each document — verify revision control.
- Cross-check the P&ID against the FDS: every instrument on the P&ID must be described in the FDS.
- Identify gaps and ambiguities now, not during programming.
- Use a document receipt checklist to ensure nothing is missed.
- Log every RFI with a number, date and assigned respondent.
Common Issues
- The FDS is incomplete or uses ambiguous terminology.
- The P&ID does not match the latest FDS revision.
- Missing specifications for critical equipment (drives, proportional valves).
- Process changes after document delivery without formal change control.
- The client assumes you "just know" requirements that were never written down.
Field Note
On a real project, dedicate at least 2 hours to reading the FDS without interruptions. Mark with colours: green = clear, yellow = doubt, red = missing info. After the first read, you'll have an RFI list that will save you weeks of rework.
Deliverables checklist:
- FDS reviewed and annotated
- P&ID verified vs FDS
- RFI list submitted
- Traceability matrix created
- Scope estimated and approved
- Kick-off meeting completed
Software Specification (SDS)
Phase 2 of 10 — Translating the process into control logic
With the documentation analysed, the automation engineer produces the Software Design Specification (SDS). This document bridges what the process needs and what the program will do. Control narratives, state diagrams, interlock matrices, alarm lists and PID loop definitions are all defined here.
Inputs
- Reviewed and validated FDS
- Annotated P&ID
- Equipment datasheets
- RFI responses
- Applicable standards (IEC 62443, GAMP5…)
Outputs
- SDS (Software Design Specification)
- Control narratives per equipment/area
- Interlock matrix (process and safety)
- Alarm list with priorities (ISA-18.2)
- PID loop definitions, set-points and ranges
- Batch recipes if applicable (ISA-88)
Tips & Best Practices
- Define naming conventions from day one (ISA-5.1 for tags).
- Use standard templates: a well-formatted control narrative saves hours of programming.
- Obtain formal sign-off on the SDS before starting to code.
- Classify alarms per ISA-18.2: not everything is "High Priority".
- Include state machine diagrams for complex sequences.
Common Issues
- Scope creep: "while you're at it, can you also add…?" without change control.
- Undefined or incomplete start/stop sequences.
- Missing failure-mode analysis (what happens if the sensor fails?).
- Alarm priorities assigned without formal rationalisation.
I/O List & Electrical Design
Phase 3 of 10 — Where software meets hardware
This phase is critical because it connects the software world with real hardware. The I/O list defines every signal entering or leaving the PLC: signal type, engineering range, rack/slot/channel assignment, cable number and terminal strip. Close coordination with the electrical design team is essential for panels, wiring and control architecture to fit together perfectly.
Inputs
- Approved SDS
- Instrument and equipment datasheets
- Electrical schematics (draft)
- Proposed network topology
- Tag naming standard
Outputs
- Final I/O list (tag, type, range, rack/slot/channel)
- PLC hardware BOM (CPUs, modules, PSUs, racks)
- Network address assignment
- Control architecture diagram
- I/O spare capacity specification (10-15%)
Tips & Best Practices
- Use a database or structured spreadsheet for the I/O list — avoid messy files.
- Verify each signal type: 4-20 mA, 0-10 V, NPN/PNP, dry contact, PT100, thermocouple…
- Plan 10-15% spare I/O capacity — signals always get added during commissioning.
- Identify long-lead-time items and order them as early as possible.
- Coordinate with the electrical team on panel layout and power/signal separation.
Common Issues
- Wrong signal type specified (voltage instead of current, or vice versa).
- Insufficient I/O: no spare capacity and now extra modules are needed.
- Module incompatibility with the selected CPU type.
- I/O list changes after panels have already been built.
- Cable numbering errors that go undetected until commissioning.
Instrumentation & Equipment Configuration
Phase 4 of 10 — Preparing the field before coding
Before PLC code makes real sense, every field instrument and device must be correctly configured. This includes transmitters, flow meters, variable frequency drives, smart valves, network switches and any device that interacts with the control system. A single misconfigured instrument can cause hours of debugging during commissioning.
Inputs
- Finalised I/O list
- Instrument and drive datasheets
- Network topology design
- Client parameterisation standards
Outputs
- Configured instruments (range, damping, comms)
- Drive parameter sheets
- Network diagram with IP addresses/nodes
- HART/Profibus PA/IO-Link configurations
- Calibration documentation
Tips & Best Practices
- Document all parameter changes from factory defaults.
- Keep a backup of the original configuration for every drive before modifying anything.
- Use structured IP addressing: a coherent scheme saves problems later.
- For VFDs: configure motor parameters first, then control parameters.
- Verify communication for each instrument before final field installation.
Common Issues
- Incorrect range on transmitters (0-10 bar when the process runs at 0-6 bar).
- Fieldbus addressing conflicts (Profibus, Modbus).
- Drive parameters causing overcurrent trips on first start-up.
- Network switches with default config generating broadcast storms.
PLC Programming
Phase 5 of 10 — The heart of automation
This is where all previous work takes shape as executable logic. The engineer develops the PLC program following the SDS narratives, using IEC 61131-3 standards and industry best practices. Motor control blocks, valves, PID loops, sequences, interlocks, communications and diagnostics are all programmed. Reusable libraries, well-structured code and proper documentation are essential.
Inputs
- Approved SDS with control narratives
- I/O list with final assignments
- PLC hardware configuration
- Standard block library (if available)
- Client/company programming standards
Outputs
- Complete PLC program (FBD/LAD/ST/SFC)
- Symbol tables / tag definitions
- Function block documentation
- Offline simulation results
- Version-controlled source code
Common platforms:
Tips & Best Practices
- Use structured programming: reusable FB libraries, UDTs, custom data types.
- Implement robust error handling: what does the system do if a sensor fails?
- Use version control (Git + TIA Portal Openness, L5X export, etc.).
- Comment your code: every block should explain its purpose, not just how it works.
- IEC 61131-3 — choose the right language for each task (SFC for sequences, ST for calculations, FBD for combinational logic).
Common Issues
- Scan time exceeding requirements due to inefficient programming.
- Data type mismatches between modules.
- Poorly initialised timers/counters causing erratic behaviour on start-up.
- "Reinventing the wheel" instead of using proven library blocks.
- Missing handling of transient states (what happens during the first scan?).
Field Note
Before writing a single line of code, create the complete project structure: folders, empty FBs, UDTs and symbol tables. It's like the foundations of a house. If you start programming without structure, you'll end up with spaghetti code nobody can maintain.
Deliverables checklist:
- Complete PLC program
- Documented symbol tables
- Standard FBs tested
- Offline simulation OK
- Code under version control
- Block documentation
HMI Development
Phase 6 of 10 — The operator's window to the process
The HMI is the interface between the operator and the process. Good HMI design improves operational efficiency, reduces human error and facilitates anomaly detection. Overview screens, equipment detail views, alarm management, historical trending and intuitive navigation are designed following ISA-101 principles and High Performance HMI guidelines.
Inputs
- SDS — HMI section
- P&ID (basis for overview screens)
- Rationalised alarm list
- Client operational requirements
- Corporate style guide (if available)
Outputs
- Complete HMI screens (overview, detail, alarms, trends)
- Alarm and event configuration
- Documented navigation structure
- Operator training guide
- Screen scripts and animations
Common platforms:
Tips & Best Practices
- Grey-scale backgrounds: reserve bright colours for abnormal states only.
- Minimise unnecessary animations: they distract and consume resources.
- Design for the operator's workflow, not to "look pretty".
- Implement a clear hierarchy: Overview → Area → Equipment Detail.
- ISA-18.2: manage alarms properly to avoid alarm flooding.
Common Issues
- Too much information on a single screen (information overload).
- Inconsistent colour coding between screens.
- Poorly managed alarms: alarm floods that operators just ignore.
- Slow or confusing screen navigation.
- Not consulting real operators during the design phase.
SCADA & Recording Systems
Phase 7 of 10 — Global visibility and data recording
In larger installations, the SCADA system provides centralised supervision of multiple PLCs and areas. The recording system stores historical process data for analysis, reporting and regulatory compliance. Correctly configuring client-server architecture, OPC UA/DA communications, redundancy and storage policies is fundamental for a robust system.
Inputs
- SCADA requirements from the SDS
- Tag list for historisation
- Storage and retention requirements
- Report templates (KPIs, batch reports)
- Server architecture
Outputs
- Configured and operational SCADA system
- Recording system collecting data
- Reports and dashboards
- Configured web/mobile access
- Architecture documentation
Platforms and tools:
Tips & Best Practices
- Plan the tag hierarchy with a future-proof mindset — restructuring later is painful.
- Define clear data retention policies (how long is data kept?).
- Optimise polling rates: not everything needs updating every 100 ms.
- Implement redundancy on critical servers (SCADA, recording server).
- Use OPC UA whenever possible — it is the future of industrial communications.
Common Issues
- Communication bottlenecks from too many tags or overly fast polling.
- Full disks from not planning data recording storage capacity.
- Excessive data compression losing relevant information.
- Licensing issues in distributed systems (nodes, tags, connections).
- IT blocking ports or breaking OPC communication without notice.
FAT (Factory Acceptance Test)
Phase 8 of 10 — Validate before going to site
The FAT is the opportunity to verify that everything works correctly before arriving at the plant. A simulation environment is set up to test all sequences, interlocks, alarms, communications and failure modes. The client witnesses the tests and signs off. A well-executed FAT drastically reduces issues during actual commissioning.
Inputs
- Complete PLC program
- Complete HMI/SCADA application
- FAT protocol (test document)
- Simulation environment (PLCSim, emulators)
- Acceptance criteria
Outputs
- Signed FAT report (pass/fail per test)
- Punch list (pending issues)
- Evidence: screenshots, videos
- Software ready for site deployment
- Corrective action list if applicable
Tips & Best Practices
- Prepare the simulation environment well in advance — not the day before the FAT.
- Document each test with screenshots and step-by-step descriptions.
- The client should sign each section of the FAT, not just the final document.
- Include failure tests: loss of communication, sensor failure, power cut.
- Record critical sequences on video as additional evidence.
Common Issues
- Incomplete simulation: not all real-world conditions can be tested in the office.
- Last-minute changes that invalidate tests already completed.
- FAT environment not reflecting the actual plant configuration (firmware versions, networks).
- Schedule pressure reducing test coverage.
- Unclear definition of acceptance criteria (what constitutes "OK"?).
Field Note
Prepare a test status table (pending / in progress / pass / fail / N/A) and project it on screen during the FAT. The client sees real-time progress, feels involved, and the sign-off process is much smoother.
Deliverables checklist:
- Signed FAT protocol
- Screenshots and videos
- Documented punch list
- I/O tests complete
- Sequence tests OK
- Software ready for site
Commissioning (SAT — Site Acceptance Test)
Phase 9 of 10 — The acid test
Commissioning is where all the office work faces reality. It is divided into sub-phases: pre-commissioning (panel inspection, point-to-point verification), cold commissioning (systems energised, no process) and hot commissioning (real process running). Coordination with installers, electricians, operators and safety managers is constant and demanding.
Inputs
- Installed hardware on site
- FAT-approved software
- Commissioning plan with schedule
- Loop check protocols
- Work permits and LOTO
Outputs
- Commissioned and operational system
- Signed SAT report
- Completed and documented loop checks
- PID loops tuned with real process
- Post-SAT punch list
- Updated as-built documentation
Tips & Best Practices
- Hold short daily stand-up meetings to coordinate with all trades.
- Always have your programming laptop, cables, adapters and basic tools at hand.
- Methodical loop checks: follow a logical order (panel → field → PLC → HMI) and document everything.
- PID loops need tuning with the real process, not theoretical values.
- Keep a daily log of issues and resolutions — it's your proof of work.
- Anticipate plant access issues (permits, schedules, security).
Common Issues
- Wiring errors discovered during loop checks (crossed cables, loose terminals).
- Faulty instruments or wrong ranges discovered in the field.
- "While you're here, can you also do this?" — scope creep on site.
- The process behaves differently than expected (times, flows, temperatures).
- Communication issues in a noisy industrial environment (EMI, distances).
- Scheduling conflicts with other trades (who has panel access now?).
Field Note
The commissioning engineer's bag: charged laptop + charger, Ethernet cables (2 min.), USB-serial cable, Profibus adapter, insulation tape, flat/Phillips screwdrivers, head torch, phone charger, PPE and a notebook. If you arrive on site missing any of these, you'll lose half a day looking for it.
Deliverables checklist:
- Loop checks complete
- Signed SAT report
- PIDs tuned
- Alarms adjusted
- Punch list updated
- As-built documentation
Validation & Handover
Phase 10 of 10 — Closing the project properly
The final phase ensures the system meets all requirements, is properly documented and is handed over to the production and maintenance teams. In regulated industries (pharmaceutical, food), this includes formal validation (IQ/OQ/PQ per GAMP5). Operator and maintenance training, along with complete as-built documentation, are essential for the project's long-term success.
Inputs
- SAT results
- Validation protocols (IQ/OQ/PQ)
- Process performance data
- Operations feedback
- Regulatory requirements (GMP, FDA, etc.)
Outputs
- Signed validation reports
- Complete as-built documentation
- SOPs (Standard Operating Procedures)
- Training records
- Recommended spare parts list
- Maintenance/support contract
- Final acceptance certificate
Tips & Best Practices
- As-built documentation must reflect the system's actual state, not the original design.
- Train operators on the real process, not just with presentations.
- Provide clear maintenance procedures: what to do if component X fails.
- Leave a contact list for post-handover technical support.
- Hold a lessons-learned session with the entire team.
Common Issues
- Documentation not updated with the latest commissioning changes.
- Insufficient training: operators don't feel comfortable with the system.
- Validation deviations requiring investigation and corrective actions.
- Resistance to change from production staff.
- Punch list items dragging on for weeks or months.