FAT vs SAT What to Test and Why

Factory Acceptance Testing (FAT) and Site Acceptance Testing (SAT) are two of the most important control points in the lifecycle of a ground station system, yet they are often misunderstood or treated as checklist formalities. Together, they define the boundary between vendor responsibility and operational ownership, and they determine how much risk is carried forward into live operations. FAT validates that equipment and systems behave correctly in a controlled environment before shipment, while SAT confirms that those same systems perform as intended once installed in their real operational context. Skipping rigor in either phase almost guarantees expensive troubleshooting later, when time, access, and documentation are limited. FAT and SAT are not redundant; they answer different questions about readiness and fitness for purpose. When designed properly, they reduce commissioning time, protect schedules, and establish baseline performance that can be trusted. This page explains the difference between FAT and SAT, what to test in each phase, and why each test exists from an operational risk perspective.

Why FAT and SAT Matter
Defining FAT and SAT
Risk Boundaries and Responsibility
What to Test During FAT
What to Test During SAT
Functional vs Performance Testing
Environmental and Integration Constraints
Documentation, Evidence, and Signoff
Common FAT and SAT Failures
FAT vs SAT FAQ
Glossary

Why FAT and SAT Matter

FAT and SAT exist to manage risk before a system becomes operationally critical. Ground station systems combine RF, mechanical, electrical, software, and networking elements, each of which can fail in subtle ways. Discovering defects after commissioning often means troubleshooting in harsh environments, under time pressure, and during live mission windows. FAT and SAT reduce this risk by moving failure discovery earlier, when fixes are cheaper and responsibility is clear. They also establish shared expectations between vendors, integrators, and operators. Without structured acceptance testing, disputes over responsibility become common and resolution slows. FAT and SAT are therefore not just technical exercises, but contractual and operational safeguards.

Defining FAT and SAT

Factory Acceptance Testing is performed in a controlled environment, typically at the vendor or integrator facility. Its purpose is to verify that equipment and systems meet specifications before shipment. FAT focuses on correctness, completeness, and repeatability under known conditions. Site Acceptance Testing occurs after installation at the operational site and validates that the system works as intended in its real environment. SAT accounts for site-specific factors such as power quality, environmental exposure, interference, and integration with existing infrastructure. While FAT answers the question “does it work as built,” SAT answers “does it work here.” Both definitions are essential to avoid misplaced expectations.

Risk Boundaries and Responsibility

One of the most important functions of FAT and SAT is defining where responsibility shifts. FAT typically represents the last point at which the vendor is fully responsible for system behavior in isolation. SAT marks the point at which the operator assumes responsibility for operation in a specific environment. Clear test scope prevents arguments about whether an issue is a manufacturing defect, an integration problem, or a site condition. Tests should be mapped explicitly to responsibilities to avoid ambiguity. When acceptance boundaries are unclear, unresolved defects often persist into operations. Properly defined FAT and SAT protect all parties by making risk visible and manageable.

What to Test During FAT

FAT should focus on verifying that each component and subsystem meets its functional specification. RF equipment should be tested for frequency coverage, gain, noise figure, output power, linearity, and control interfaces. Mechanical systems such as antenna drives should be exercised through full range of motion under safe conditions. Control software and automation logic should be validated against documented requirements. Redundancy switching, alarms, and fault responses should be simulated deliberately. FAT is the right time to test edge cases and failure modes that would be risky or impractical on site. The goal is confidence that the system behaves correctly before environmental variables are introduced.

What to Test During SAT

SAT validates system behavior in the presence of real-world constraints. RF testing during SAT should confirm link performance, interference resilience, and compliance under actual antenna, cabling, and environmental conditions. Mechanical systems must be tested under expected wind, temperature, and loading conditions where possible. Integration with site power, grounding, timing, and network infrastructure is a central SAT objective. Operational workflows such as pass execution, failover, and alarm response should be exercised end to end. SAT also verifies that monitoring, logging, and safety systems function correctly in practice. The focus is not theoretical capability, but operational readiness.

Functional vs Performance Testing

Both FAT and SAT must distinguish between functional correctness and performance under load. Functional tests confirm that systems do the right thing, such as switching paths or tracking satellites. Performance tests determine how well they do it, such as margin, stability, and recovery time. FAT often emphasizes functional testing because performance is easier to control in factory conditions. SAT places greater emphasis on performance because real-world conditions expose limitations. Both types of testing are necessary to avoid surprises. A system that functions correctly but performs poorly is not operationally acceptable.

Environmental and Integration Constraints

Environmental and integration factors are often the dominant sources of SAT failures. Power quality issues, grounding differences, cable losses, and RF interference rarely appear during FAT. Environmental exposure such as wind, ice, and temperature variation can reveal mechanical or RF weaknesses. Integration with existing networks, timing systems, and operational tooling often exposes assumptions made during design. SAT must be designed to surface these constraints explicitly rather than treating them as exceptions. Testing under realistic conditions provides confidence that the system will survive day-to-day operations. Environment is not noise; it is a defining variable.

Documentation, Evidence, and Signoff

Acceptance testing is incomplete without clear documentation and evidence. Test procedures, expected results, and acceptance criteria must be defined before execution. Results should be recorded with timestamps, measurements, and observer signoff. Deviations and waivers must be documented explicitly to avoid future dispute. FAT and SAT reports form the baseline against which future performance and troubleshooting are judged. Signoff should represent informed acceptance, not pressure-driven approval. Proper documentation transforms testing into institutional knowledge rather than transient activity.

Common FAT and SAT Failures

A common FAT failure is testing only nominal scenarios while skipping fault conditions. Another is relying on vendor demonstration rather than independent verification. In SAT, common failures include insufficient time allocation, testing outside realistic operational windows, and incomplete integration checks. Treating SAT as a formality rather than a validation exercise often leads to unresolved issues entering operations. Poor coordination between teams creates gaps in coverage. These failures are procedural, not technical, and can be avoided with discipline. Acceptance testing fails most often when its purpose is misunderstood.

FAT vs SAT FAQ

Can SAT replace FAT? No. SAT cannot safely or efficiently replicate the controlled testing environment of FAT.

Should operators attend FAT? Yes. Operator involvement improves understanding and increases confidence in later acceptance.

What happens if SAT reveals issues not seen in FAT? That is expected. SAT exists specifically to expose site-specific and integration-related issues.