Airport Control System FAT, SAT and UAT: A Practical Process Guide

A system can pass FAT and still be unready for an airport. Factory testing can’t prove that every site interface will work as intended or that operational teams can use the system effectively. That’s why the airport control system FAT SAT UAT process should be planned as a connected assurance chain, not three isolated sign-offs. Clear test boundaries and evidence matter, particularly when teams need to demonstrate readiness without disrupting live operations.

This guide explains how FAT, SAT and UAT fit together, what each stage should demonstrate, and how to agree responsibilities, acceptance criteria and defect management before testing begins. It also covers how to trace evidence from design requirements through to operational handover.

We’ll look at factory verification against agreed requirements, site testing of installed systems and interfaces, and user validation of operational workflows. We’ll also consider how relevant standards, operational scenarios and readiness activities can shape a test plan. The aim is a practical route from design intent to informed acceptance, with fewer gaps between technical completion and day-to-day use.

What does the airport control system FAT SAT UAT process involve?

Acceptance testing checks a system against agreed requirements and its intended use. In an airport control project, the airport control system FAT SAT UAT process provides separate opportunities to verify the system before deployment, in its installed environment and against users’ operational needs. Define the stages for the project rather than treating them as a universal template: the relevant parties need to agree scope, acceptance criteria, terminology and sign-off arrangements.

For a general introduction, Acceptance Testing describes the wider concept and includes factory, site and user acceptance testing. In practice, the value comes from clarifying what each stage is intended to prove, what evidence will be recorded and who will review it.

What do FAT, SAT and UAT mean in an airport project?

Factory Acceptance Testing (FAT) checks agreed functions and requirements at the factory stage, before equipment or systems are deployed to site. Site Acceptance Testing (SAT) examines the installed system in its airport environment, including relevant connections with other systems. User Acceptance Testing (UAT) is led by users assessing whether the system supports agreed operational requirements and scenarios. In short: FAT verifies before deployment, SAT checks the installed system and interfaces, and UAT assesses suitability for agreed user needs.

Why does an airport control system need staged acceptance?

Each stage can expose a different type of issue while there is still an opportunity to investigate and resolve it. A discrepancy in a PLC function may be identified during factory checks. A signal or alarm that behaves differently once connected to SCADA may only become visible on site. A technically correct display may still need to be assessed against a user’s working scenario.

For airport control systems, checks can involve interfaces between SCADA, PLCs and other connected operational systems. The precise scope depends on the design and project requirements. Planning tests around those boundaries helps teams avoid treating component-level results as proof of end-to-end behaviour. It also gives operational stakeholders a defined role in assessing relevant workflows, without assuming every project has the same systems, participants or test sequence.

Acceptance testing supports assurance, but it doesn’t replace commissioning, safety processes or the project’s wider readiness activities. Agree how test results relate to those activities, and how unresolved defects affect acceptance, before execution begins. A passed test records what was demonstrated under its stated conditions. Project governance determines what that evidence means for progression and handover.

How should FAT, SAT and UAT connect across the control system lifecycle?

A useful airport control system FAT SAT UAT process begins before equipment reaches site. It links each test to an agreed requirement, then carries the result, supporting evidence and any unresolved finding forward to the next relevant decision. Adapt the sequence to the project’s design, interfaces, contract and governance. It isn’t a universal script.

Agree acceptance criteria before testing begins, so every participant knows what success means, what evidence is needed and who can approve the result.

How do requirements become acceptance tests?

Start with the approved functional, interface and operational requirements within the project’s scope. Map each requirement to one or more test cases, with an objective expected result and pass criterion. For example, a requirement concerning an alarm path could be traced through its originating function, its presentation at the relevant interface and the response expected in an agreed scenario.

Document the mapping in a controlled test plan or equivalent record. Identify accountable reviewers, the evidence to capture and how changes to requirements or test cases will be assessed and approved. This makes omissions easier to identify before execution, rather than discovering late in the process that a key requirement has no corresponding test.

What evidence should carry from FAT through UAT?

Agree the evidence set for the project. It may include test scripts, actual results, deviations, defect records and approvals. Record configuration and version details too. Without knowing which software, settings or connected components were tested, later reviewers may struggle to interpret what a result proves.

• 1. Define the basis: confirm the applicable requirements, boundaries, stakeholders and acceptance criteria.
• 2. Prepare traceable tests: link requirements to test cases, expected results, evidence and accountable reviewers.
• 3. Record outcomes: capture results against the configuration tested, logging deviations and defects with clear ownership.
• 4. Review progression: determine which findings must be resolved, which require retesting and whether any can be carried forward under an agreed decision.
• 5. Reassess at later stages: use earlier findings to refine relevant site and user tests, while confirming that new environments and interfaces are assessed on their own terms.

A finding from FAT might prompt a revised or additional site check, while a site issue may need investigation before a user scenario can be meaningfully assessed. Defects don’t all follow the same route. The responsible parties should agree the owner, resolution plan, impact and retest decision. Airport-wide readiness also involves people and operational trials beyond control system acceptance. The Port of Seattle’s account of Operational Readiness, Activation, and Transition (ORAT) illustrates that broader context.

Where early requirements and interface planning would help make tests more coherent, consider airport control systems design and SCADA integration as part of the project’s engineering planning.

FAT vs SAT vs UAT: which airport acceptance test proves what?

The stages answer different questions, so a pass at one stage isn’t proof of readiness at another. In the airport control system FAT SAT UAT process, define what each test covers, who participates and what decision its evidence supports. The comparison below is a planning guide, not a universal allocation of duties.

Stage	Purpose	Typical environment	Participants	Evidence and decision
FAT	Verify agreed design and functional requirements before deployment.	Factory or other defined test environment; interfaces or signals may be simulated if in scope.	Supplier and project technical representatives, as agreed.	Test results, deviations and defect records support a decision on whether factory-stage criteria have been met.
SAT	Check installed equipment, configuration and agreed site interfaces.	Airport site, with testing planned around access, dependencies and operational constraints.	Integration and site teams, relevant system owners and other project representatives.	Site test results and records of interface issues inform acceptance against the agreed site criteria.
UAT	Assess whether agreed user workflows and operational scenarios are supported.	An agreed user-test setting using the relevant system configuration and scenarios.	Representative users and operational stakeholders, with technical support as required.	Scenario results and user findings inform the decision on acceptance against operational criteria.

Exact responsibilities and sign-off authority depend on the contract and project governance. Agree them in advance, including how defects affect progression and who may accept any outstanding findings.

What does FAT verify before the system reaches site?

FAT checks the system against agreed design and functional requirements in its defined test environment. Where included in scope, teams may exercise interfaces or use simulated signals to verify expected behaviour. This can identify issues before deployment, but it can’t reproduce every airport-specific condition, installed connection or live operational interaction. Passing FAT therefore doesn’t prove that the fully installed system is ready for use.

How do SAT and UAT differ once the system is installed?

SAT focuses on the installed system, its configuration and agreed site interfaces, such as connections between control equipment and a relevant operational system. UAT focuses on whether users can complete defined workflows and scenarios as intended. The two may overlap in timing, but their objectives remain distinct: user approval doesn’t replace technical verification, site testing or commissioning.

For example, a control system alarm might be technically present at an interface during SAT, while UAT considers whether it supports the agreed operational response. Systems and scenarios vary between airports. Coordinate site testing with relevant operational stakeholders to manage access and avoid unintended disruption.

How can airport teams plan acceptance testing without missing operational risks?

A sound airport control system FAT SAT UAT process depends on more than a list of test cases. Site access, interface availability and operational constraints can affect what is practical to test, when it can be tested and who needs to be involved. Confirm these conditions with airport operations and relevant system owners before booking site or user testing. Don’t assume every dependency will be available.

Who needs to contribute to airport system acceptance?

Set out project-defined roles for the client, integrator, supplier, operations and maintenance representatives. Agree who prepares and executes each test, who witnesses it, who investigates and resolves defects, and who approves results. Involve intended users in UAT scenario design so the workflows reflect agreed operational needs, not just the technical team’s assumptions.

What should the planning checklist cover?

• Scope: list the systems, functions, interfaces and scenarios included, along with exclusions and assumptions.
• Test windows and access: confirm site access, operational restrictions and the arrangements needed to carry out tests safely and with suitable coordination.
• Dependencies: verify that equipment, interfaces, data, system owners and supporting resources will be available for the planned checks.
• People and responsibilities: name those preparing, executing, witnessing and approving tests, and assign ownership for defect investigation and resolution.
• Evidence and decisions: define the required records, how results will be reviewed and who can approve acceptance or deferred actions.

These details are project-specific. For example, testing an interface may depend on another system being available, or a user scenario may need to be scheduled around operational activity. Confirming dependencies early helps teams decide whether to test in the intended environment, use an agreed alternative or reschedule. An unavailable dependency shouldn’t be treated as a pass.

How should defects and operational scenarios be managed?

Use project-agreed severity categories and acceptance rules. Don’t assume universal thresholds. Record each finding against the affected requirement and test, with a clear owner, resolution plan and retest decision. After correction, retest the relevant item and preserve evidence linked to the original requirement. If a test is deferred or a limitation remains, document the reason, impact, accountable decision-maker and any outstanding action. This keeps the acceptance record transparent.

Include representative operational scenarios where they fall within scope. For baggage handling, that might mean testing an agreed control function or interface across a defined scenario, with relevant system owners and users available to assess the result. The scenario should reflect project requirements, not imply a standard test that applies to every airport.

For support with airport control systems design and SCADA integration, discuss your project requirements with AAC.

How can an airport engineering partner support FAT, SAT and UAT readiness?

Acceptance planning is more effective when it starts during design, rather than being assembled just before tests begin. An engineering partner can help align requirements with system boundaries, interfaces and intended operational use, allowing the project team to define criteria that are specific enough to test. The airport control system FAT SAT UAT process remains project-specific, and the partner’s responsibilities should be agreed with the client and other parties.

What should an integrator contribute before testing starts?

Early integration planning can clarify which systems exchange information, what each interface is expected to do and which dependencies need to be available for a meaningful test. It can also help project teams identify who prepares, witnesses and approves each test, while leaving contractual authority with the parties appointed to hold it. For further context on airport operational technology and integration, see this airport SCADA integration guidance.

These decisions support a project-specific test strategy. Requirements can be mapped to proposed checks, criteria and evidence, with gaps or assumptions raised for resolution before execution. For instance, if a control system depends on data from another operational system, teams can identify whether that interface will be available for testing, how its behaviour will be assessed and who owns any resulting issue. This is planning support, not a claim that one test method or division of responsibility suits every airport project.

How does lifecycle design support an evidence-led handover?

Design choices shape what can be verified later. Clear system boundaries and interface requirements make it easier to determine whether a test result relates to the intended function, while commissioning activities can provide additional evidence about the installed arrangement. Together, these records can help project stakeholders understand what has been tested, against which requirements and with what outstanding actions. They don’t guarantee acceptance or replace project governance.

AAC provides control systems design consultancy from RIBA Stages 1 to 5, alongside airport-focused SCADA integration and commissioning consultancy. Involvement across these stages can help keep design intent, integration considerations and planned evidence connected, subject to the agreed project scope. The control systems design consultancy guide explores the wider design context.

If you’re defining responsibilities, interfaces or evidence for an airport control system project, discuss your airport control system requirements with AAC.

Plan acceptance as a route to operational confidence

A well-planned airport control system FAT SAT UAT process connects evidence at each stage to agreed requirements, interfaces and intended use. FAT, SAT and UAT have distinct purposes, so passing one stage shouldn’t be treated as proof that every later technical or operational check is complete.

Agree criteria, responsibilities and defect decisions before testing starts. Then coordinate site and user activities with airport operations and relevant system owners, recording results, limitations and outstanding actions clearly. This creates a traceable basis for acceptance and helps teams understand what the evidence does and doesn’t demonstrate.

AAC specialises in SCADA integration and mission-critical airport control systems, with control systems design and consultancy from RIBA Stage 1 through Stage 5 commissioning. If you’re considering how requirements, interfaces and acceptance planning fit together, discuss your airport control system requirements with AAC. A considered plan can help your project progress towards handover with greater clarity.

Frequently Asked Questions

What is the difference between FAT, SAT and UAT for an airport control system?

FAT, SAT and UAT assess different aspects of acceptance. FAT checks agreed requirements in a factory or defined test environment before deployment. SAT checks installed equipment, configuration and agreed site interfaces. UAT assesses whether users can complete agreed operational workflows and scenarios. In the airport control system FAT SAT UAT process, evidence from one stage doesn’t automatically prove the objectives of another, and the exact scope should be agreed for the project.

When should FAT, SAT and UAT take place in an airport control system project?

Typically, FAT takes place before equipment or systems are deployed, SAT follows installation at the airport, and UAT is carried out when users can assess the configured system against agreed operational scenarios. The sequence and any overlap depend on the project’s design, dependencies and governance. Plan each stage early, including the criteria for progression, required interfaces and stakeholder availability. Coordinate site and user testing with airport operations to account for access and operational constraints.

Can UAT replace SAT or commissioning for an airport control system?

No. UAT focuses on whether the system supports agreed user needs and workflows; it doesn’t establish that installed equipment and interfaces have passed site checks. Nor does it replace commissioning, which is a distinct project activity. These activities may inform one another, but each has its own scope and evidence. Define how UAT, SAT and commissioning relate in the project plan, and confirm what approvals or outstanding actions are required before handover.

Who is responsible for signing off FAT, SAT and UAT?

Sign-off authority is defined by the contract and project governance, so it shouldn’t be assumed to sit with one party for every stage. The project should identify who prepares and runs tests, who witnesses results, who reviews evidence and who has approval authority. Participants may include the client, supplier, integrator, operations representatives and relevant system owners. Record the named responsibilities and decision route in the acceptance plan before testing, including how unresolved findings affect approval.

What documents are needed for airport control system acceptance testing?

The project should agree its evidence requirements, which commonly include approved requirements, a test plan, test scripts, expected results, recorded outcomes and relevant approvals. Keep deviation and defect records, together with configuration and version information that identifies what was tested. Requirements traceability helps reviewers connect each result to the requirement it addresses. The exact document set depends on the contract and project governance, so confirm it before testing rather than relying on a generic checklist.

How should airport teams manage defects found during acceptance testing?

Record each defect against the relevant test and requirement, then assign an owner, an agreed severity or priority and a resolution plan. Project-specific acceptance rules should determine whether testing can proceed and whether a finding can remain open. After correction, decide what needs retesting, capture the new result and retain the link to the original evidence. If an item is deferred or accepted with a limitation, document the decision, rationale and any outstanding actions.

What happens if an airport control system fails a FAT or SAT test?

A failed test should be recorded as a deviation or defect, investigated and assessed against the agreed acceptance criteria. The responsible parties then determine corrective action, ownership and whether affected tests or dependent checks need to be repeated. A FAT failure may require resolution before deployment, while a SAT failure concerns the installed arrangement and may affect progression. The project’s contract and governance determine acceptance decisions; a failed result shouldn’t be treated as a pass without an agreed, documented disposition.