Machine Control Software Development in Thailand: Acceptance Guide 2026

When outsourcing machine control software development in Thailand, the decisive issue is not simply the PLC brand or programming language. Buyers must agree how the machine moves between states, how it recovers from each abnormal condition, what is guaranteed at the safety and system boundaries, and what evidence will prove acceptance during FAT and SAT. This guide brings together PLC software design, state-transition design, abnormal recovery, safety boundaries, logs and time, version control, simulation, FAT/SAT, source code, licences and maintenance handover as one procurement discipline. It does not repeat general explanations of PLC programming, HMI screens, control-panel engineering or robot selection; it focuses on interfaces and auditable acceptance evidence.

Executive answer: buy a provable specification, not a successful demonstration

A video of one automatic cycle does not prove that a machine can be supported in production. A useful RFP and acceptance plan should cover at least eight deliverables:

1. Operating states and the complete state-transition list.
2. Detection, stop behaviour and recovery conditions for each abnormal event.
3. Responsibility boundaries between safety functions and standard control.
4. Interface contracts among the PLC, robot, HMI, inspection and MES/ERP systems.
5. Log fields, time basis, retention and export method.
6. Version control connecting source, configuration, libraries and the physical machine.
7. Simulation, FAT and SAT cases, pass criteria and evidence.
8. Handover conditions for source code, engineering tools, licences and maintenance information.

These points reduce the risk of receiving a machine that “runs” but cannot be recovered safely, traced to an approved release or maintained by another team. Before comparing prices, make sure every bidder has priced the same scope, evidence and handover package.

Five expectation gaps in outsourced machine control software

“Automatic operation” may mean only the nominal cycle

The factory usually expects the system to handle material shortages, repeated commands, communications loss, emergency stops, power interruptions and work-in-process recovery. A supplier may have estimated only a clean nominal cycle. Separate the nominal cycle from the intended operational envelope, and enumerate the exceptions included in that envelope.

An I/O list does not define behaviour

Sensor and actuator names do not define debounce, delays, mutual exclusion, timeouts, retries or conditions for manual operation. An I/O list is necessary, but it is not a complete machine control software specification.

Safety responsibility disappears between contracts

Even when another contractor designs the safety circuit, standard control logic still has to recognise the safety state, inhibit unintended restart and guide recovery. Separate responsibility for the safety function from the signals, permissions and restart conditions consumed by standard control.

FAT approval is mistaken for production readiness

FAT is acceptance in the supplier environment; SAT is acceptance at the installed site. Real products, plant networks, production time synchronisation, upper-level systems, utilities and local access control may only be available onsite. Define the responsibility of each test stage and which items may be carried over.

“Source code handover” is treated as a file transfer

A project may open but still be impossible to reproduce without the correct IDE, patch, device descriptions, libraries, licences, passwords and build procedure. The goal is for an authorised third party to reproduce the approved baseline, explain differences and restore it from backup.

Begin requirements definition with a boundary matrix

Before expanding a function list, define who owns each side of an interface and what evidence will be accepted.

Record ownership, send conditions, acknowledgements, initial values, timeout behaviour, retry policy and power-cycle behaviour—not only tag names. For screen-level design, see our HMI development guide for Thailand factories. For the electrical boundary, see control panel design in Thailand. The software RFP should concentrate on the hand-off points and acceptance conditions.

State-transition design: put normal, stop, fault and recovery on one map

IEC 61131-3:2025 specifies the syntax and semantics of Structured Text (ST), Ladder Diagram (LD) and Function Block Diagram (FBD), as well as Sequential Function Chart (SFC) elements used to structure programs and function blocks. Whichever notation is used, procurement documentation must expose the machine state model and its transition conditions; naming a language is not enough.

Use state names that operators understand

At minimum, distinguish power-up, pre-check, homing, idle, ready, executing, controlled stop, stopped, fault stop, recovery confirmation and maintenance. Map the HMI state, log code and program enumeration to the same vocabulary so operations and engineering can discuss the same condition.

Give every transition four attributes

For each transition, specify the start conditions, completion conditions, timeout and failure destination. A transfer start may require downstream readiness, workpiece presence, axis home and safety permission. Arrival alone may not be completion if clamping or identification must also succeed. Define whether a timeout causes a hold, a retreat to a safe mechanical position, a retry or escalation.

Define recovery as a work procedure, not a reset bit

For every alarm, define clear conditions, residual-energy checks, treatment of work in process, replacement material, quality disposition and restart point. Resuming the previous step can double-process a part; evacuating everything may create excessive scrap. Assess machine state and product state separately, then state who must confirm what before restart.

Test power and communications interruptions independently

Specify what happens to retained values, axis position, pending production results and in-process IDs after a short or long outage. If power is lost after a result is sent but before its acknowledgement arrives, retransmission must not create a duplicate record. Define local autonomous operation from buffer design and quality risk, not from an arbitrary fixed quantity.

Make the abnormal-recovery matrix the core of the RFP

Suppliers differ more in exception handling than in the nominal sequence. Replace a mere alarm-number list with a recovery matrix.

Turn each matrix row into one or more test cases. “Test all alarms” is not comparable across bids; input conditions and expected outcomes make test effort and acceptance explicit.

Safety boundary: do not assign safety ambiguously to the standard PLC

ISO 13849-1:2023 covers a methodology and associated requirements, recommendations and guidance for designing and integrating safety-related parts of control systems (SRP/CS), including software design. Its public abstract also says it does not specify the safety functions or required performance levels for a particular application. A one-line statement of “ISO 13849-1 compliant” therefore does not define machine-specific safety functions.

After risk assessment and confirmation of applicable standards, separate at least these responsibilities:

• Scope of safety circuits, safety controllers and safety components.
• Safety status and diagnostic information visible to the standard PLC.
• Difference between a safety reset and a standard alarm reset.
• Conditions that prevent automatic restart after safety recovery.
• Permitted action, speed and range in manual or maintenance modes.
• Owner, author and approver of safety validation evidence.

Where a robot cell is involved, connect this boundary to our industrial robot implementation and ISO 10218 guide. The current project deliverable should be evidence for cell status, PLC handshakes and recovery order—not another generic robot overview.

Interface contracts: move from a tag list to a time-based specification

A sound PLC software design agrees the sequence of interactions. After a start request, does the peer respond with accepted, busy and complete? What happens if the request disappears during execution? Can another request be issued before completion is acknowledged? How is a stale completion bit rejected after the peer restarts? Capture these rules in timing diagrams or sequence diagrams.

A protocol name does not guarantee correct behaviour. Use the same test data on both sides, and capture transmitted values, received values, machine action and stored result as one acceptance case.

Logs and time: specify enough detail to reconstruct an incident

More logs are not automatically better. The goal is to correlate machine state, operator action, alarm, communication, software release and workpiece on one timeline.

Minimum useful log model

• Event timestamp and status of the time source.
• Machine, station and unit identifiers.
• Previous and next state.
• User or permission role for an action.
• Alarm occurrence, acknowledgement and clearance.
• Major request/response records with correlation IDs.
• Recipe, software and configuration releases.
• Work ID or another traceable production unit.
• Result and reason code.

If PLC, IPC, robot and server clocks disagree, investigators can infer the wrong order of causes. Define the synchronization source, diagnostics when synchronization is lost, and storage of UTC versus local time. During FAT or SAT, deliberately remove time synchronization and confirm the diagnostic response. Retention should be based on investigation needs, quality obligations, storage, privacy and customer requirements—not an invented universal duration.

Version control: connect source, settings, recipes and hardware in one baseline

A shared folder called latest.zip cannot prove that source matches the machine. Identify at least:

• PLC, HMI, robot and IPC source.
• Compiler/IDE release and required add-ons.
• External libraries and licences.
• Hardware configuration and device descriptions.
• I/O, network and safety-boundary settings.
• Recipe and parameter defaults.
• FAT-approved, SAT-approved and production-approved baselines.

Each change request should link purpose, impact, changed files, test scope, rollback and approval. PLCopen publishes industrial-control guidance on coding rules, libraries and SFC structuring, and published guidance on software quality metrics in 2023. Do not turn these into an arbitrary claim that one numeric threshold equals quality. Translate them into project rules for naming, structure, complexity review, reuse and peer review.

IEC’s public description of IEC 61131-3:2025 notes the addition of UTF-8 strings and associated functions. If the project handles multilingual messages or recipe names, verify round-trip behaviour across the actual PLC runtime, HMI, interfaces and CSV/database path. A new standard edition does not prove that an installed controller supports every feature.

Simulation: expose specification gaps before the machine is complete

The goal is not a perfect virtual machine. It is early testing of state transitions, interfaces and exceptions. Divide the scope into three layers.

Include missing sensors, delayed responses, duplicate messages, reversed order and out-of-range settings. Simulation cannot prove mechanical clearance, wiring noise or actual safety performance, so it does not replace FAT or SAT. It does bring many integration defects forward before expensive onsite work.

FAT and SAT for software: turn a test sheet into an evidence package

FAT scope

FAT should cover approved I/O, states, major cycles, abnormal recovery, roles, alarms, communications, logs, backup and restoration. If actual products or systems are unavailable, document substitutes and the reason for SAT carry-over. Freeze the release for every case, and rerun affected cases after a correction.

SAT scope

SAT uses installed wiring, plant networks, production systems, actual workpieces, factory time sources, users, peripherals and utilities. Not every FAT test must be repeated, but any item affected by shipping, installation or settings changes must be rechecked.

Evidence package

Evidence must identify the case and release, not merely state that someone watched a video. Acceptance criteria should cover recoverability, log completeness and baseline reproducibility as well as cycle performance.

Reflect secure development and maintenance in the contract

IEC’s description of IEC 62443-4-1:2018 covers secure development life-cycle activities for IACS products, including security requirements, secure design and implementation, verification and validation, defect management, patch management and product end-of-life. The same description states that these requirements apply to product developers and maintainers, not to integrators or users. Do not impose an inaccurate certification statement on every custom-machine supplier; translate relevant lifecycle controls into contract requirements.

• Approval, authentication, logging and closure for remote access.
• Separation of development and production accounts.
• Removal of default passwords and temporary accounts.
• A contact for dependent libraries and known vulnerabilities.
• Priority, mitigation and corrective-release process for security defects.
• Pre-patch assessment, backup, rollback and regression tests.
• Notice of end-of-life for products, components and tools.

ISA describes the ISA/IEC 62443 series as requirements and processes for implementing and maintaining secure IACS, with shared responsibility among asset owners, product suppliers, integrators and service suppliers. The factory therefore retains responsibilities for assets, accounts, backups and change approval; security cannot be delegated entirely to the supplier.

Acceptance conditions for source code, licences and maintenance handover

Verify handover through a reproduction test, not a file inventory.

Distinguish ownership, rights to modify, reusable supplier libraries, third-party components and permission to appoint another maintenance company. Delivery of source code is not automatically a transfer of copyright. Remove private keys and personal credentials from source, and transfer secrets to a factory-controlled vault.

Compare machine control software estimates through effort drivers

A fixed price before requirements are known hides assumptions. Break estimates down by:

• Number of states, stations, axes, devices and concurrent movements.
• Product variants, recipes, changeovers and traceability complexity.
• Number of robot, inspection and MES interfaces and maturity of peer specifications.
• Abnormal scenarios, recovery policies, manual and maintenance modes.
• Safety responsibility and support for validation.
• Logging, audit, user roles and languages.
• Simulation scope, FAT/SAT case count and actual-product preparation.
• Onsite hours, holidays, interpretation, travel and waiting conditions.
• Source, licences, documentation, training, warranty and maintenance.
• Legacy-machine analysis and contingency for unknown behaviour.

For each driver, record included, excluded, customer-supplied and the change mechanism when an assumption fails. Compare effort assigned to review, testing, documentation and handover, not only headline price.

Execution in Thailand: include local conditions in acceptance design

BOI/OSOS reported in July 2026 that Thailand received 82 investment applications worth about THB 13.1 billion in machinery, automation and robotics during the first half of 2026. It also reported 132 applications worth about THB 17.2 billion under the Smart and Sustainable Industry initiative for machinery upgrades, digital technology, and automation/robotics integration. These figures do not prove eligibility or returns for a specific project; they provide context for continued industrial modernization.

The BOI page for an automotive automation measure describes the treatment of software integrated with machinery to manipulate, control and support manufacturing. However, that page also states a 2025 application deadline. Do not present an expired deadline as a current 2026 incentive. Check the latest BOI announcement, eligible activity, timing and certification conditions with BOI or a qualified adviser for each project.

Create one acceptance team covering the regional equipment owner, Thailand operations and maintenance, local SI, machine builder and IT/MES owner. At kickoff, fix the controlling document language, interpretation responsibility, units, date format, holiday/night work, spares and approval for remote access.

Selecting an outsourcing partner: evaluate answers, not only demonstrations

Give every candidate the same abnormal scenario and compare how they define design, test and handover.

1. What artifact is used to review state transitions?
2. How are non-nominal cases counted in the estimate?
3. Who agrees the boundary with safety control?
4. How are interface changes governed?
5. What can and cannot be simulated?
6. How will FAT/SAT evidence be packaged?
7. How is source matched to the physical machine?
8. What rights and support conditions apply to standard libraries?
9. Can a new engineer reproduce the release from documentation?
10. Who receives notices about defects, vulnerabilities and end-of-life?

A strong answer gives assumptions, artifacts, exceptions and a test method. The ability to expose undecided items early is as important as implementation skill.

RFP checklist

Requirements and design

• [ ] Equipment scope, exclusions and responsibility matrix.
• [ ] State list, transitions and timeouts.
• [ ] Detection, stop, recovery and work-in-process disposition.
• [ ] Manual, maintenance, changeover and permissions.
• [ ] Boundary between safety and standard control.
• [ ] Owners and time sequence for every interface.
• [ ] Logging, clock synchronization, retention and export.

Development and testing

• [ ] Coding rules, review and release control.
• [ ] Simulation scope and test data.
• [ ] FAT/SAT cases, equipment, workpieces and responsibilities.
• [ ] Nonconformance, change, retest and conditional-acceptance process.
• [ ] Minimum secure-development and remote-support controls.

Handover and support

• [ ] Source, settings, toolchain and licence inventory.
• [ ] Release reproduction and backup restore test.
• [ ] IP, modification, third-party maintenance and secret handling.
• [ ] Training, warranty, incident triage and EOL notice.
• [ ] Open-item list and post-production improvement channel.

FAQ about outsourced machine control software

Where should machine control software requirements start?

Start with boundaries, operating states, abnormal recovery and external interfaces, then turn each state and boundary into acceptance tests. For legacy equipment, record whether source exists, the installed release, available downtime and behaviour that cannot yet be reproduced.

Is “IEC 61131-3 compliant” enough for PLC software design?

No. IEC 61131-3 gives a common foundation for programming-language syntax, semantics and structuring elements. The project must still define states, recovery, naming, libraries, review, testing and the controller’s supported edition and features.

Does a small machine need state-transition design?

The level of detail varies, but even a small machine has power-up, idle, run, stop, fault and recovery. A table is sufficient if a diagram is unnecessary. The important point is making hidden recovery assumptions testable.

How should outsourced control software costs be compared?

Compare effort drivers for states, exceptions, interfaces, tests, onsite work, documents, handover and support. Align customer-supplied inputs and exclusions, and define when an unresolved assumption becomes a change order.

How should software FAT and SAT be divided?

Bring forward logic, states, exceptions, communication, logs and restoration that can be reproduced at the supplier. Use SAT for installed wiring, actual products, plant networks, production systems, clocks and installation effects. Keep release identification and evidence at both stages.

What must be checked in a source-code handover?

Check the IDE and patch, device definitions, dependencies, licences, build/download procedure, settings, secret transfer and change history in addition to source. Require a clean-environment open/build and comparison with the approved installed release.

How is the boundary between safety functions and standard PLC control set?

Use risk assessment and applicable standards to design the safety-related scope, then define safety status, reset, restart permission and diagnostics visible to standard control. Confirm machine-specific functions and required performance with qualified machinery-safety specialists.

Conclusion: work backward from evidence to obtain maintainable software

An effective machine control software contract combines normal sequence, state transitions, abnormal recovery, safety boundaries, interfaces, logs and time, version control, simulation, FAT/SAT and complete source/licence/maintenance handover. Connect every RFP requirement to a test and an evidence artifact, and accept a baseline that an authorised third party can reproduce. That is the most practical way to reduce extended downtime and dependency on one programmer.

If your Thailand machine control project is still at the stage of scattered notes rather than state models and test sheets, TOMAS TECH can help structure the boundary matrix, RFP, FAT/SAT and handover package before implementation. Contact us through the TOMAS TECH enquiry page with the equipment scope and what is currently known.

References

• IEC 61131-3:2025
• ISO 13849-1:2023
• IEC 62443-4-1:2018
• ISA/IEC 62443 series overview
• PLCopen Software Construction Guidelines
• PLCopen Guideline on Software Quality Metrics
• Thailand BOI automation measure page
• Thailand BOI/OSOS 1H 2026 investment update