PLC Program Development Outsourcing: Scope, FAT/SAT, Handover

When you outsource PLC program development, a request defined only by the number of I/O points, HMI screens and PLCs does not produce comparable quotations. One supplier may assume only normal automatic operation. Another may include abnormal recovery, investigation of the existing machine, communications testing, backup, commissioning and operator training. A lower price may represent genuine efficiency—or simply a smaller and hidden scope.

The buyer should procure more than code that runs on the acceptance day. The deliverable should be a control asset whose intended behavior can be tested, whose changes can be traced, which can be restored after failure and which another qualified engineer can maintain. This guide converts I/O, state transitions, interlocks, the safety boundary, abnormal and recovery behavior, modes, permissions, logs, HMI and communications into an RFP, FAT/SAT evidence and a reproducible as-built handover.

The primary-source scan performed immediately before drafting found no announcement in the preceding 48 hours that directly changes PLC outsourcing specifications. Versions and dates of relevant standards and guidance are identified below. Every cost and benefit figure is a TOMAS TECH illustrative assumption, not a market price or a promised result.

Define the outcome of outsourced PLC program development first

Convert “it works” into observable acceptance conditions

“The machine shall run automatically” is too coarse to test. It does not identify the start condition, states traversed, inputs that stop motion, prerequisites for reset, restart position or retained state after loss of power. The supplier must fill these gaps with assumptions, and the interpretation gap usually appears during FAT.

Write each behavior as input, current state, condition, output, next state, abnormal response and recorded evidence. For example: the clamp may start only when the workpiece is confirmed in position, the guard condition is valid and upstream permission is present; if the required position is not reached, progression is blocked and the alarm is latched; after the cause is removed, an authorized reset returns the sequence to a defined safe waiting state. This wording is testable.

Procure four linked layers of deliverables

I/O and screen counts indicate part of the implementation size. They do not describe behavior complexity, existing-machine investigation, test volume, recovery conditions or handover quality. Therefore, never compare prices using only screen counts and I/O counts.

Specification 1 — connect I/O and state transitions in one control vocabulary

Add control meaning to the electrical I/O list

An I/O list is not merely an address book. Include signal name, type, normal and fail state, electrical characteristic, source, scaling, unit, filtering, update condition, simulation method and relationship to alarms. NC/NO alone does not explain whether a broken wire leads to a safe state, whether logic is inverted or how the HMI represents normality.

For analog signals, define the raw range, engineering conversion, out-of-range and wire-break behavior, and treatment of bad quality. For communicated values, preserve connection health and freshness; a stale retained value must not appear as current truth. For outputs, describe authorization during automatic operation, manual operation, forcing and maintenance.

Use a state-transition table as the sequence contract

Flowcharts can conceal concurrency, waiting, timeouts, re-entry and restart behavior. Define states by machine or function and record entry conditions, sustained actions, exit conditions, timeout, prohibited transitions and logged events.

The names matter less than shared understanding. Operations, production engineering, electrical design, software and test personnel should describe the same example as the same transition. The state table then becomes the common index for HMI status, alarms, logging and FAT cases.

Specification 2 — interlocks, safety boundary, abnormal operation and recovery

Do not stop at a list of interlock conditions

For every interlock, identify what it protects, the enabling condition, monitored state, output response, latching behavior, release condition, reset authority, display, logging and whether bypass is ever permitted. An aggregate “safety OK” bit often hides the condition that failed and the checks required before recovery. Preserve diagnosable cause signals where practicable.

Separate process protection, equipment protection, quality protection and machine safety. Material shortage and a safety function intended to reduce harm to people carry different design, verification and approval responsibilities.

Treat safety PLCs and safety functions as a specialist boundary

Safety PLCs, emergency stops, guards, light curtains, safe speed and safe stopping functions are not convenient extensions of standard PLC programming. They require risk assessment, defined safety functions, applicable laws and standards, an appropriate architecture, verification, validation and reassessment after modification. Use qualified, authorized specialists and the legal, regulatory, standards and site requirements applicable to the machine and jurisdiction.

Passing a standard-control FAT does not prove functional or machine safety. The RFP should name the safety-responsible party, supplied records, test boundary, required internal or independent approval and signal boundary with normal PLC/HMI logic. This article is procurement guidance, not safety certification or legal advice.

Specify the stopped machine, not only the running machine

The abnormal-condition register should include detection logic, delay, priority, stop scope, latching, immediate response, cause removal, pre-restart checks, resume point and linked logs. Include communication failure, sensor disagreement, actuator timeout, material absence, quality deviation, upper-system outage and power failure.

“Reset and resume” is insufficient. An interrupted machine may contain work in process, disagree with physical positions, conflict with a completion already sent upstream or have no confirmed product identity. Define whether each case uses automatic recovery, operator confirmation, maintenance authority, controlled ejection, reprocessing or scrapping.

Specification 3 — modes, permissions, logs and HMI screen development

Define each mode by permitted actions

For automatic, manual, setup, maintenance, adjustment and simulation modes, define controllable outputs, speeds, active interlocks, transition conditions, concurrent actions, remote-operation rights and event logs. A manual mode that can move every output without conditions may accelerate commissioning but leave unacceptable operating risk.

Clarify the relationship among physical key switches, HMI login and upper-level approval. Define roles for recipe changes, alarm resets, maintenance screens and forcing. Operations that require personal accountability should not rely on a shared password.

Accept HMI behavior, not a screen count

An HMI screen development quotation for “overview, manual, alarms and settings” says little about usability. For every screen, define the decision made by its user, required status, operating prerequisites, confirmation, reason for rejection and navigation to supporting detail.

• Show operating state, stop reason and required next action in one context.
• Do not use color as the sole carrier of meaning; represent state consistently.
• Connect alarms to likely cause, impact, immediate action and recovery conditions.
• Show unit, range, current value, change and authority for important settings.
• Confirm the target and outcome of critical operations and handle duplicate commands safely.
• Never display lost communications or stale values as healthy current data.
• Verify that localization preserves meaning, units, layout and searchability.

Review screens through normal, abnormal, recovery, insufficient-authority and communication-loss scenarios, not only static appearance. The handover should include the editable HMI project, fonts, images, libraries, alarm/text register and localization dictionary.

Select logs by the questions they must answer

Consider state transitions, alarm occurrence/clearance/acknowledgement, mode changes, important parameter and recipe-version changes, manual actions, access actions, communication status, PLC/HMI startup, time changes and program download or change. Define the required granularity, clock source, destination, retention and export. High-frequency collection of everything is not a substitute for an investigation design.

PLC evidence has a different role from the manufacturing context discussed in MES implementation for Thailand factories. PLC/HMI systems hold immediate control context; MES holds business context such as orders, lots and reported production. The interface specification should assign the record of authority and describe replay and reconciliation after failure.

Put communications, networks and remote support inside the scope

A tag map is not a complete communications specification

Define counterpart, protocol, connection initiator, update method, data type, byte order, scaling, handshake, timeout, retry, duplication, ordering, startup, disconnection and recovery. One-time events such as production completion are vulnerable to loss and duplicate processing when implemented as a simple bit. Use sequence identifiers, acknowledgement, retry and idempotent handling where the risk requires it.

The network drawing should show devices, ports, segments, addresses, management boundaries, time synchronization, upstream connections and remote paths. It should also identify who approves change, how replacement settings are restored and what monitoring confirms healthy operation.

Apply cybersecurity with OT constraints in view

NIST SP 800-82 Rev. 3, finalized in September 2023, explains that OT cybersecurity must account for performance, reliability and safety requirements. Do not apply general IT controls without evaluating operational impact. Design asset visibility, communication paths, access, change, monitoring, backup and response around the machine constraints. Citing NIST in a proposal does not itself make the system secure.

On 24 June 2026, NIST announced final SP 1800-45, a secure-remote-access reference design for water and wastewater systems. Its approach can inform authentication, separation and monitoring, but it is sector-specific guidance—not a legal requirement for every factory. Assess your own risk and applicable requirements.

If remote support is permitted, specify approval, time-limited enablement, individual authentication, least privilege, destination restriction, recording and monitoring, emergency disconnection and session closure. Do not make permanent access from a shared vendor account or an unmanaged computer the contractual default.

Make the backup, restore and engineering environment transferable

A CPU upload may not recreate the complete project

The statement “the program is inside the PLC, so it is backed up” can be wrong. Depending on manufacturer, model, protection and functions, uploading or decompiling from the CPU may not recreate the complete engineering project, comments, symbols, hardware configuration, libraries, HMI or network settings.

Siemens’ July 2024 PLC Basic Program Function Manual provides a manufacturer-specific example: saving the project may be necessary for complete restoration, while decompilation from the CPU alone can be insufficient. This should not be generalized to every product. It does demonstrate why the buyer should not assume a CPU upload is enough and should demand a restore test using the official method for the selected system.

Version and licensing of the development environment are deliverables

The handover register should list the engineering-software name, exact version and update level, required options, library versions, device descriptions, drivers, OS conditions, licensing model and owner, and reinstall procedure. Otherwise a future replacement PC may be unable to open the source legally or reproducibly.

The official STEP 7 page is one vendor example covering configuration, programming, testing, diagnosis and reuse. The lesson is not that every buyer must select one brand; it is that configuration, test, diagnostic and reuse assets outside executable code depend on an engineering environment. Check equivalent dependencies for the selected platform.

Pair every backup claim with a restore test

The NIST NCCoE manufacturing page lists the OT Backup Quick Start Guide, NIST SP 1339, posted on 17 June 2026, which addresses considerations for an OT backup strategy. The CISA-led Secure by Demand guide dated 13 January 2025 asks buyers to question suppliers about configuration and engineering-logic change tracking and authenticated backup and restore.

Specify backup content, record of authority, frequency, generations, storage, encryption, access, integrity checks, offline or separated copies and restore ownership. Restore to a spare controller or test environment and verify hardware configuration, logic, retained parameters, HMI, communications, alarms, permissions and logs. Opening an archive file is not a completed restore test.

Compare outsourced PLC software development quotations fairly

Give every bidder the same assumptions

Differences in outsourced PLC software development quotations often come from scope assumptions. State whether current source exists and is readable, electrical drawings are as-built, production downtime is available, simulation hardware is supplied, local-language coverage and night work are required, and who pays travel, spares, training and warranty support.

Ask suppliers to expose hidden complexity

One hundred independent conveyor I/O points are not equivalent to one hundred points across parallel machines with recipe changes, tracking, re-entry, upstream interfaces and complex recovery. Ten display-only screens are not equivalent to ten screens with recipes, audit, localization, authorization and trends.

Ask each bidder to explain effort in terms of states, transitions, interlocks, recovery cases, external interfaces, product variants, roles, test cases and uncertainty in the existing machine—not only I/O. Compare deliverables, exclusions, buyer-supplied work and the mechanism for pricing change as carefully as rates.

The broader allocation of electrical and controls work is covered in production engineering outsourcing in Thailand. This article concentrates on acceptance and recoverability of the control software.

Close the boundary between outsourced electrical design and PLC development

Treat circuit, BOM, terminals and I/O as one change chain

Even if outsourced electrical design and PLC work use separate contracts, the responsibility chain must remain joined. Adding one sensor can affect the circuit, BOM, terminal, cable, I/O address, PLC logic, HMI, alarm and test. Name who updates each artifact and who approves final consistency.

The BOM should include part number, specification, quantity, approved substitution, supplier and installed location as needed. Check network hardware, communication modules, license tokens and memory cards that are essential to restore but often omitted from a main panel BOM.

Make as-built documentation an acceptance item

If field changes remain on paper or an individual’s computer, source, panel drawing, I/O, HMI and network design diverge. Control interim versions throughout commissioning, align all artifacts at SAT completion and connect submission of the final as-built package to commercial acceptance. The buyer should open and search the files and trace representative I/O through circuit, logic, screen and test evidence.

Use IEC 61131-3 as a shared vocabulary, not a quality label

IEC 61131-3:2025 was published on 22 May 2025 and covers PLC programming languages including ST, LD and FBD, with SFC concepts. It is useful for specifying language and structure, but writing “IEC 61131-3 compliant” does not by itself guarantee readability, modularity, testability, safety or recoverability.

Define naming, comment language, symbols, module boundaries, side effects, state handling, alarm IDs, constants and recipes, reusable blocks, exception behavior, dead code, forcing and bypass, and change history. Select expressions appropriate to the controller, process and maintainer rather than forcing one language in every context.

The review should trace requirement IDs into code and test. A buyer should be able to find where an interlock is implemented and which FAT cases demonstrate its valid, invalid and recovery behavior.

Make FAT/SAT acceptance evidence, not a demonstration

FAT should emphasize boundaries, faults and recovery

FAT should record approved requirement, prerequisite, procedure, input, expected result, actual result, evidence, deviation, disposition and signoff. When real equipment is unavailable, define how a signal is simulated and carry the unverified physical portion explicitly into SAT.

Verification of safety functions must follow its own responsible specialist and applicable requirements. Adding a safety row to a standard interlock sheet is not functional-safety validation.

SAT closes factory-specific uncertainty

SAT uses actual power, panel, wiring, sensors, actuators, network, upper systems, product and operators. Confirm signals simulated at FAT, site installation, inter-machine timing, performance, extended operation, power and communication recovery and the real restore procedure.

Replace “works without issue” with observable acceptance conditions. Every open item needs impact, controlled workaround, owner, due date, retest case and production-release decision. Define final payment and warranty commencement against closure criteria rather than verbal agreement.

Handover checklist for a reproducible control asset

Editable implementation

• Complete PLC engineering project with version or verification checksum.
• Editable HMI project, images, fonts, dictionaries and alarm register.
• Comments, symbols, variables, data types, libraries and dependencies.
• Hardware configuration, communication settings and required firmware.
• Approved compile/download method and controller mapping.
• Engineering-tool version, updates, options, licenses and installer information.

As-built design and acceptance records

• I/O, state-transition, interlock and abnormal/recovery registers.
• Electrical drawings, panel layout, terminal/cable records and BOM.
• Network topology, address/port list, communication map and time sync.
• HMI list, role matrix, settings/recipe and logging specifications.
• Safety boundary and references to separately governed safety evidence.
• FAT/SAT specification, actual results, deviations, corrections and approval.

Operation, restoration and learning

• Operating, setup, abnormal, recovery, backup and restore procedures.
• Account/access, remote support, planned and emergency change procedures.
• Spares and configuration restoration or revalidation after replacement.
• Buyer-performed restore exercise and training evidence.
• Warranty, response definitions, site support, exclusions and escalation.

When control events and parameters feed a long-term evidence system, see the process parameter recording system RFP and FAT/SAT guide. PLC handover preserves source and machine behavior; the upper recording layer preserves event and manufacturing-history context. Their versions and identifiers must connect.

Define warranty, support and change control at contract time

Agree on examples of defect versus scope change

“Programming defects will be corrected free of charge” does not classify interpretation gaps, existing-device failures, newly requested behavior or third-party changes. Define whether a reproducible deviation from an approved requirement and acceptance result is a defect, and whether new inputs or operating policies are change requests. Use examples.

Separate receipt, initial response, start of remote diagnosis, temporary recovery, site arrival and permanent correction. “24-hour support” must identify coverage hours, languages, channel, buyer-provided access, parts, travel and production-stop authority.

Synchronize source, documents, backups and tests after every change

A change request should state purpose, scope, risk, affected I/O, states, HMI, communications and safety boundary, implemented version, rollback, test and approval. If online or emergency changes are permitted, set a deadline to reconcile the controller version, master source, as-built documents and backups.

The Secure by Demand questions on tracking configuration and engineering-logic changes and authenticated backup/restore are useful in a support questionnaire. They become effective only when the contract states who detects and approves changes, which evidence is kept and when restoration is tested.

TOMAS TECH illustrative cost and benefit model

This is not a price benchmark or benefit guarantee. It assumes that a controlled specification and handover reduce part of response labor and prolonged recovery loss. Replace every input with your stop history, contribution economics and maintenance model.

Base case

• Initial development estimate: 1,850,000 THB
• Annual maintenance: 240,000 THB
• Current stop/change-response labor: 6/month × 4 people × 3.5 h × 220 THB/h × 12 = 221,760 THB/year
• Current prolonged-recovery loss: 8/year × 9 h × 32,000 THB/h = 2,304,000 THB/year
• Assumed improvement: response labor 40%; prolonged-recovery loss 30%

Response-labor benefit:

221,760 × 40% = 88,704 THB/year

Recovery-loss benefit:

2,304,000 × 30% = 691,200 THB/year

Gross benefit:

88,704 + 691,200 = 779,904 THB/year

Net benefit:

779,904 - 240,000 = 539,904 THB/year

Simple payback:

1,850,000 ÷ 539,904 = 3.4265... ≈ 3.43 years

Sensitivity

The assumed improvement in downtime loss dominates this model. The 221,760 THB line represents human response effort; the 2,304,000 THB line represents unavailable-production loss. In your model, do not double-count the same stopped-hour cost in both. Measure improvement through restore drills, spares, support and actual operations—not the mere existence of a specification.

The unofficial English translation of BOI Announcement 15/2565 discusses treatment of software, programs and IT expenditure integrated with machinery, but this article cannot establish its current applicability. BOI’s eligible-activities page shows a last update of 28 October 2025, and its 2026 private machinery/equipment investment index is background context only. Neither proves incentive eligibility or ROI. Confirm the current, project-specific position directly with BOI.

Practical checklist before inquiry, contract and acceptance

Before inquiry

• Confirm machine scope, existing modifications, downtime and buyer responsibilities.
• Cross-reference I/O, states, interlocks, abnormal behavior and recovery.
• Define safety responsibility, applicable requirements, specialist and boundary.
• Include modes, access, logs, HMI, communications and network behavior.
• Make tools, licenses, backup and restore contractual deliverables.

Before contract

• Give every supplier the same assumptions, simulation and FAT/SAT conditions.
• Compare complexity and exclusions beyond I/O and screen counts.
• Define the format of source, comments, symbols, BOM, drawings and as-built files.
• Define change pricing, warranty, support response and third-party modification.
• Connect payment milestones to design approval, FAT, SAT and final handover.

Before acceptance

• Test normal, boundary, fault, recovery, communication loss, restart and access.
• Demonstrate restoration from the approved project, not merely a CPU upload.
• Align versions across PLC, HMI, drawings, I/O, network and BOM.
• Give every punch item an impact, workaround, owner, due date and retest.
• Ensure buyer personnel can locate, open and explain the restore package.

FAQ — outsourced PLC software, electrical design and HMI screens

What should a buyer provide first for PLC program development?

Provide the machine purpose, product scope, existing drawings, I/O, states, interlocks, safety boundary, abnormal/recovery behavior, modes, HMI, communications and acceptance conditions. List undecided matters with their decision owner, due date and quotation-adjustment mechanism.

How should outsourced PLC software development prices be compared?

Compare survey, design, state and recovery complexity, interfaces, FAT/SAT, commissioning, editable source, engineering environment, backup restoration, as-built records, training and warranty—not only I/O or screens. Put exclusions and buyer-supplied work beside the price.

Can electrical design and PLC development use different suppliers?

Yes, provided one controlled change chain joins circuit, BOM, terminals, I/O, PLC, HMI, alarms and tests, with a named party responsible for final consistency. If the buyer cannot manage the boundary, appoint an integration owner.

What should be accepted in HMI screen development?

Accept whether users can correctly identify state, stop cause, next action, insufficient authority and communication failure in realistic scenarios. Include the editable project, images/fonts, alarm register, localization dictionary and access matrix.

Is uploading the program from the CPU a sufficient backup?

Not always. Comments, symbols, hardware configuration, libraries, HMI or other project assets may not be completely recreated, depending on the selected platform. Preserve the approved engineering project and prove restoration in a separate environment using the official product procedure.

What is the difference between FAT and SAT?

FAT verifies logic, HMI, communications and recovery against requirements at the supplier or test environment using real or simulated signals. SAT verifies the same evidence chain with the factory’s actual wiring, equipment, network, product and users. Passing FAT does not automatically mean passing SAT.

Can a safety PLC be accepted through the same standard PLC FAT?

Interfaces can be checked, but this does not replace safety validation. Qualified specialists must plan and perform the work under the applicable law, standards, risk assessment and safety requirements for the machine and jurisdiction.

What cybersecurity terms apply when source and remote access are shared?

Define transfer, encryption, storage, users, redistribution, confidential content, service computers, remote paths, logs and return or deletion. Use approved, time-limited, individually authenticated and monitored access with least privilege, while evaluating performance, reliability and safety impacts.

Conclusion — buy a restorable control asset, not code that runs once

The core discipline in PLC program development outsourcing is alignment among requirements, implementation, test and handover. Turn I/O and state transitions, interlocks, the safety boundary, abnormal/recovery behavior, modes, access, logs, HMI and communications into observable conditions. FAT/SAT should test boundaries, faults, restarts and restoration as well as normal operation.

Receive editable source, comments, symbols, hardware configuration, libraries, HMI, BOM, network drawings, exact engineering-tool versions and licenses, backups, as-built documents and the warranty, support and change process. Compare acceptance evidence and future recoverability—not only screen and I/O counts.

Even before every signal is finalized, the survey scope, RFP structure, FAT/SAT cases and handover register can be developed in stages. If you are evaluating outsourced PLC and HMI development for a Thailand factory, you can discuss the planning stage through our English contact form.