AGL Component Library By Precision AGL Academy

Final Approach Runway Occupancy Signal (FAROS)

An advanced airfield safety system that alerts pilots on final approach when the runway ahead is occupied. Rather than adding a new light fixture, FAROS drives the airport's existing Precision Approach Path Indicator (PAPI) into a flashing mode when a surface-surveillance system detects a conflict, giving pilots a direct visual go-around cue without waiting on an ATC radio call.

Final Approach Runway Occupancy Signal (FAROS)

Image disclaimer: For identification and illustration only. It may show a product by another manufacturer and may not depict the exact item described; it is not a statement of any product’s quality, approval or performance. Third-party image and trademark rights belong to their owners. See full notice.

Overview

What Is It?

The Final Approach Runway Occupancy Signal (FAROS) is an advanced airfield safety capability that provides visual alerts to pilots on final approach when a runway is occupied. Rather than being a standalone light fixture, FAROS is an add-on control function for the existing Precision Approach Path Indicator (PAPI): when surface surveillance detects that the runway's protected zone is occupied, the FAROS controller commands the PAPI light units to flash instead of burning steady, giving the approaching pilot a clear, unambiguous "runway not clear" cue without requiring any additional cockpit equipment or waiting on an ATC radio call.

Purpose

Purpose & Function

FAROS exists to close a specific, dangerous gap in runway safety: a pilot on short final has no reliable way to see for themselves whether the runway ahead is actually clear, since another aircraft, vehicle, or obstruction on the far end of a long runway may not be visible from the approach path, and radio communication about runway status can be delayed, missed, or misunderstood. By switching the PAPI — a light array the pilot is already looking at for glide-path guidance — into a flashing state exactly when the runway is occupied, the system gives a go-around decision cue that doesn't depend on air traffic control instruction or the pilot's own visual judgement of a runway they may not be able to fully see. Its purpose, in short, is to convert a hidden runway-occupancy hazard into a direct, self-evident visual warning at the single moment — final approach — when a wrong decision has the least time to be corrected.

Application

Where Is It Used?

FAROS systems are installed at busy airports with high traffic volumes and complex runway configurations where approach conflicts are a significant risk. They are typically used on:

  • Precision approach runways (CAT II and III) where safety margins are critical
  • Major international airports with intersecting runways and complex approach paths
  • Runways with high traffic density where incursion risk is significant
  • Airports implementing advanced safety management systems
  • Runways with limited visibility operations where visual cues are essential
Placement

Installation & Location

FAROS is retrofitted onto the runway's existing PAPI installation — typically a 4-box L-880 (or 2-box L-881) array sited beside the runway roughly 300 m (1,000 ft) from the threshold, on the same low, frangible-mounted ground stands used for standard PAPI. No new elevated light fixture or dedicated FAROS bar is required; the FAROS driver is added inline between the PAPI's own power/lamp-control unit and its light heads so it can switch the units into a flashing state without disturbing their aiming or glide-path calibration. The system is tied into the airport's surface surveillance source (ASDE-X, ASSC, or ADS-B-based tracking) via a FAROS controller that evaluates occupancy status for the defined activation zones and issues the flash command on detection of a conflict. The controller, its power supply, and its monitoring unit are usually housed in an equipment shelter near the PAPI site, and installation is coordinated closely with the surveillance system's own commissioning to validate accurate occupancy detection before activation is enabled.

Function

How Does It Work?

The FAROS system operates through an integrated surveillance and alert mechanism:

  • Surveillance: Surface surveillance data (ASDE-X, ASSC, or ADS-B-based tracking) tracks aircraft and vehicle positions on the airfield.
  • Detection: The FAROS processing system evaluates whether a defined runway activation zone is occupied by an aircraft or vehicle.
  • Activation: When an activation zone is occupied, the FAROS controller switches the runway's existing PAPI light units from steady-burning to a flashing state.
  • Alert: The flashing PAPI gives the approaching pilot a clear, unambiguous indication that the runway is not clear for landing.
  • Deactivation: When the activation zone is clear, the PAPI reverts to its normal steady glide-path indication and the pilot proceeds with the approach.
Architecture

System Architecture & Control Logic

Unlike a series-circuit AGL fixture, FAROS is not commanded by the tower or an ALCMS brightness step — it is a self-contained, sensor-driven system that decides its own state in real time and acts on the PAPI it is attached to, rather than on a fixture of its own. Surface surveillance feeds (ASDE-X, ASSC, or ADS-B-based tracking) are continuously ingested by the FAROS occupancy processor, which evaluates whether the protected runway segment is occupied and, on detecting a conflict, drives the PAPI's existing light heads into a flashing mode independent of any ATC action. Because a missed occupied-runway call is far more dangerous than an unnecessary flash, the logic is fail-safe by design: any loss of confidence in the surveillance feed, a processor fault, or a communications dropout defaults the system to the conservative "occupied" (flashing) state rather than reverting silently to steady-burning, and the fault is separately reported to the ALCMS/tower for maintenance action.

Surveillance Feed → Occupancy Processor → FAROS Driver → PAPI Light Heads Flash (fail-safe to "occupied")

SURVEILLANCE SENSOR NETWORK Radar · ADS-B · Surface Movement Radar FAROS OCCUPANCY PROCESSOR Safety-critical logic — acts independently of ATC FAROS DRIVER / POWER CONTROLLER Converts occupancy state into a flash command EXISTING PAPI LIGHT HEADS Ground-mounted beside the runway; switched steady ↔ flashing FAIL-SAFE TO "OCCUPIED" ON ANY FAULT Sensor dropout or processor fault never silently clears the light Fault is reported to ALCMS/tower separately for maintenance CONTINUOUS RE-EVAL Processor re-checks feed health on every cycle, not once per approach
Logic Flow

Detection-to-Alert Cycle

Surveillance Data FeedRadar · ADS-B · Surface Movement Radar
FAROS Processing SystemContinuously evaluates runway state
Runway Occupied?
Yes
PAPI Switched to FlashingSame beam, same intensity — flashing instead of steady
Pilot AlertedHolds or executes go-around
No
PAPI Stays SteadyNormal glide-path indication continues
Pilot ProceedsContinues approach and landing

Both outcomes feed back into continuous surveillance — the system re-evaluates runway status in real time for every approach, not just once per landing.

Construction

Physical Construction

FAROS does not introduce a new optical fixture: the light-emitting hardware remains the runway's existing PAPI light units (typically a sealed LED or halogen luminaire in a die-cast aluminium enclosure, anodised or powder-coated, with a red/white split beam behind a toughened glass lens), mounted low to the ground on frangible couplings beside the runway per standard PAPI siting. What FAROS adds is a driver/interface module — usually a card or unit built into or wired alongside the PAPI's power and control unit (PCU) — that can override the PAPI's normal steady output and switch the light units into a flashing pattern on command. This driver electronics package is potted or conformal-coated for moisture protection and connected via sealed, direct-burial-rated cable glands to a dedicated mains feed and UPS backup circuit, since the FAROS function must remain available even through a brief power interruption. A weatherproof junction box near the PAPI site houses the interface to the surface-surveillance/RWSL, A-SMGCS, or ALCMS control link, with corrosion-resistant fasteners and hardware used throughout given the fixture's exposed, low-lying siting near the runway environment.

Specification

Technical Parameters

ParameterTypical Value
Light SourceExisting PAPI light units (LED or halogen; the runway's own L-880/L-881 array — FAROS adds no new luminaire)
ColourStandard PAPI red/white split beam; flashes rather than burns steady when activated
Flash RateApprox. 60 flashes per minute (adjustable at the FAROS driver)
IntensitySame as the PAPI unit's normal steady-burning beam (no separate intensity spec)
Beam PatternUnchanged from PAPI — narrow vertical fan beam directed along the approach path
Mounting TypeGround-level, on the PAPI's own frangible-mounted stands beside the runway (not elevated)
Power SupplyFAROS driver on dedicated mains with UPS backup; PAPI light units powered as normal
IntegrationSurface surveillance (ASDE-X/ASSC/ADS-B), reported to RWSL, A-SMGCS, and ALCMS
Protection ClassIP65 / IP67 (weatherproof), matching standard PAPI enclosure ratings
Power Supply

Electrical Requirements

RequirementTypical Value
Circuit TypeDedicated mains branch circuit for the FAROS driver (not a series/CCR loop); PAPI light units remain on their own normal supply
Supply Voltage120V / 240V AC single-phase (regional variants available)
Backup PowerUPS backup circuit, sized for continued operation through a mains interruption
FAROS DriverPotted / conformal-coated interface module that overrides the PAPI's steady-burning output and regulates flash rate
Cable TypeDirect-burial-rated cable via sealed, weatherproof cable glands
Control InterfaceLow-voltage data link to RWSL, A-SMGCS, or ALCMS via weatherproof junction box
Earthing/GroundingPAPI light unit housings, driver enclosure, and junction box bonded to the airfield earth grid
Fault ProtectionDriver-level fault detection with UPS transfer and mains-loss monitoring
Power SourceDedicated mains feed with UPS backup, status monitored by the host control system
Optical Performance

Photometric Requirements

ParameterTypical Value
Peak Beam IntensityUnchanged from the underlying PAPI unit's certified steady-burning intensity (per FAA AC 150/5345-28H / ICAO Annex 14)
Flash RateApprox. 60 flashes per minute, adjustable at the FAROS driver/controller
Vertical Beam SpreadUnchanged from PAPI — narrow vertical fan beam split between the white (above glide path) and red (below glide path) sectors
Horizontal Beam SpreadUnchanged from PAPI — directed along the final approach path
ChromaticityStandard PAPI red/white boundaries per ICAO Annex 14 (CIE coordinates); FAROS does not alter colour, only cadence
DirectionalityUni-directional, aimed at approaching aircraft on final (as for the underlying PAPI)
Activation BehaviourPAPI switches from steady to flashing when the surveillance system reports the activation zone occupied; reverts to steady when clear
Effective IntensityGoverned by the PAPI unit's own certified photometrics; FAROS activation does not require a separate effective-intensity calculation
Aiming ToleranceSet by the underlying PAPI's own aiming/calibration procedure; FAROS retrofit must not disturb glide-path aim
Test MethodPhotometric verification that flashing mode preserves the PAPI's certified intensity and aim, plus flash-rate and activation-logic checks during commissioning and periodic checks
Compliance

Applicable Standards

ICAO Annex 14

Aerodrome visual aids requirements, including PAPI systems FAROS is built on

FAA AC 150/5345-28H

Precision Approach Path Indicator (PAPI) Systems — the underlying light units FAROS drives

FAA Order JO 6850.2C

Visual Guidance Lighting Systems (current edition) — siting/integration guidance for FAROS with ALS and RWSL

FAA AC 150/5345-53

Airport Lighting Equipment Certification Program — qualification listing for certified equipment

Prerequisites

Installation Requirements

Driver Module Retrofit
Mechanical

Fit the FAROS driver module inline with the existing PAPI power and control unit (PCU) per the manufacturer's retrofit kit, without disturbing the PAPI light units' mounting or aim.

Verify PAPI Aim Undisturbed
Mechanical

Confirm the underlying PAPI units remain within their certified glide-path aiming tolerance after the retrofit — FAROS must not require re-aiming the light heads.

Power Cable Route & Termination
Electrical

Run the dedicated mains feed to the driver module through sealed, direct-burial-rated cable glands, keeping the run separate from the PAPI's own PCU wiring.

UPS Backup Installation
Electrical

Install and wire the UPS backup near the driver module or equipment shelter, sized to carry the FAROS function through the required outage duration before mains power is restored.

Surveillance/Communication Interface Wiring
Systems

Terminate the RWSL, A-SMGCS, or ALCMS communication link at the weatherproof junction box per the system integration specification, keeping runs separated from power cabling.

Junction Box Weatherproofing
Mechanical

Seal the junction box near the PAPI site against wind-driven rain and dust, confirming cable glands and gaskets are fully seated before closing.

Controller Configuration Upload
Systems

Load the design flash rate and activation logic parameters into the FAROS controller before any pre-activation testing begins.

Pre-Activation Sign-off
Documentation

Record the PAPI's post-retrofit aiming check, cable/connector terminations, and driver configuration as-built before the system is energised for testing.

Verification

Testing & Commissioning

Surveillance Interface Validation
Pre-Activation

Confirm the system correctly receives runway occupancy data from the airport's surveillance source before enabling automated activation.

Activation Logic Test
Pre-Activation

Run scripted occupancy scenarios and confirm the flashing signal activates and deactivates correctly in each case.

Flash Rate & Intensity Verification
Final Acceptance

Measure flash rate and intensity with a calibrated photometer against applicable thresholds before handover.

Communication Link Verification
Pre-Activation

Confirm the link between the FAROS controller and the surveillance/communication source remains stable under load.

UPS Backup & Failover Test
Commissioning

Simulate a primary power loss and confirm the system continues operating without interruption on backup power.

Software & Logic Validation
Pre-Activation

Confirm the controller's occupancy-to-activation logic matches the design specification across all tested scenarios.

Mounting & Visibility Verification
Final Acceptance

Confirm the unit is correctly mounted and visible to pilots on final approach at the design decision point.

Documentation & As-Built Sign-off
Final Acceptance

Record activation logic, communication, and photometric test results in the commissioning dossier for handover.

Upkeep

Inspection & Maintenance

Flash Intensity & Rate Check
Annual

Verify peak candela output and flash rate against the design specification using a calibrated photometer, since dimming or an off-tempo flash pattern reduces conspicuity to arriving crews.

PAPI Lens & Optics Cleaning
Quarterly

Clean the PAPI light units' lenses of dust, insects, and weather film so the red/white split beam stays within its intended cone toward final approach — routine PAPI upkeep that also protects FAROS conspicuity.

Surveillance Interface Validation
Semi-annual

Confirm the data link from RWSL, A-SMGCS, or ALCMS surveillance sources is current and correctly triggering activation, since a stale feed causes late or missed alerts rather than a hardware fault.

Activation Logic Test
Annual

Run a simulated runway-occupancy scenario end-to-end to confirm the system activates and deactivates within its designed response window.

UPS & Power Supply Check
Semi-annual

Test the dedicated mains supply and UPS backup under simulated outage conditions to ensure uninterrupted operation during a mains failure.

Communication Link Inspection
Annual

Inspect network cabling, switches, and redundant communication paths between sensors, processing units, and light heads for degradation or single points of failure.

Housing & Mounting Structure Inspection
Annual

Check the PAPI ground stand, weatherproof housing seals, and fasteners for corrosion, looseness, or ingress that could compromise IP rating.

Software & Firmware Update Review
Annual

Confirm processing unit firmware and control software are on the manufacturer's supported version to close known calibration and false-alarm issues.

Field Notes

Common Field Issues

Surveillance Data Latency

Delays in surveillance data processing can cause the FAROS system to react slowly, potentially failing to alert pilots in time. Regular system performance monitoring and network optimization are essential.

False Alarms

The FAROS system can trigger false alarms due to surveillance errors or system faults. False alarms can desensitize pilots and reduce the effectiveness of the system. Regular calibration and system validation are critical.

Communication Infrastructure Failure

FAROS systems rely on network communication between surveillance sensors, processing units, and output devices. Network failures can result in system-wide loss of functionality. Redundant communication paths are essential.

Diagnostics

Troubleshooting Guide

System Fails to Activate on Runway Occupancy
Likely Cause
Stale or dropped surveillance feed from RWSL, A-SMGCS, or ALCMS, or the activation logic did not receive a valid trigger from the processing unit.
Diagnostic Steps
Check the surveillance interface for feed currency and correct target correlation; review the processing unit event log for a missed or rejected trigger; run a simulated occupancy scenario end-to-end.
Corrective Action
Restore or re-sync the surveillance data link, correct any feed configuration mismatch, and re-validate activation with a follow-up end-to-end test.
Frequent False Alarms / Nuisance Activations
Likely Cause
Surveillance target-correlation errors, drifted calibration, or outdated firmware producing spurious occupancy detections.
Diagnostic Steps
Review activation logs to identify the pattern and source of the false triggers; confirm surveillance sensor calibration; check processing unit firmware against the manufacturer's supported version.
Corrective Action
Recalibrate the surveillance source, update firmware/control software to close known false-alarm issues, and re-run validation testing before returning the system to service.
Delayed Activation / Slow Response
Likely Cause
Surveillance data processing latency or network congestion between sensors, the processing unit, and the light heads.
Diagnostic Steps
Monitor end-to-end response time against the designed activation window; inspect network switches and communication paths for congestion or degraded links.
Corrective Action
Optimize or reroute network traffic, replace degraded network hardware, and re-measure the response window to confirm it is back within tolerance.
System-Wide Loss of Function
Likely Cause
Failure of a shared communication path or network switch between surveillance sensors, processing units, and output devices, with no redundant path available.
Diagnostic Steps
Check network cabling, switches, and redundant communication paths for a single point of failure; confirm the processing unit is reachable from all connected sensors and light heads.
Corrective Action
Restore or replace the failed link/switch, verify redundant paths are active, and re-test system-wide activation before standing the system back up.
Single Light Head Dark or Dim
Likely Cause
Failed LED module or driver at that light head, or a corroded/loose connection at the housing.
Diagnostic Steps
Confirm the light head is receiving an activation command from the processing unit; inspect the housing seal and connector for corrosion or moisture ingress; check driver output at the fixture.
Corrective Action
Replace the failed LED module or driver, re-terminate corroded connections, and confirm the housing seal is restored to its IP rating.
System Drops Out on Mains Failure
Likely Cause
UPS battery has degraded or failed to transfer load, leaving the system without backup power during a mains interruption.
Diagnostic Steps
Test the UPS under a simulated outage; check battery health and transfer-switch operation; confirm the dedicated mains supply and its protective devices are functioning correctly.
Corrective Action
Replace a degraded UPS battery or faulty transfer switch, and re-verify uninterrupted operation with a follow-up simulated outage test.
Reliability

Failure Modes & Root Causes

Surveillance Feed Loss or Staleness
High Severity
Root Cause
Dropped or stale data link from the RWSL, A-SMGCS, or ALCMS surveillance source, or a target-correlation error at the interface into the processing unit.
Effect
System fails to activate on genuine runway occupancy — the most safety-critical failure mode for a system whose entire purpose is a timely visual alert to the landing aircraft.
Detection Method
Surveillance interface feed-currency and correlation checks, processing unit event log review, and end-to-end simulated occupancy testing.
Calibration Drift / Firmware Fault Causing False Alarms
Medium Severity
Root Cause
Surveillance sensor calibration drifting out of tolerance over time, or outdated processing-unit firmware producing spurious occupancy detections.
Effect
Repeated nuisance activations that desensitise pilots to the alert, undermining the system's effectiveness even when it later activates for a genuine occupancy event.
Detection Method
Activation log review to identify the pattern and source of false triggers, sensor calibration verification, and firmware version audit against the manufacturer's supported release.
Communication Path / Network Switch Failure
High Severity
Root Cause
Failure of a shared network link or switch between surveillance sensors, the processing unit, and the light heads, with no redundant path in place or available.
Effect
System-wide loss of function — every light head goes unreachable regardless of individual fixture health, since the entire system depends on this shared communication chain.
Detection Method
Network cabling and switch inspection for a single point of failure, and confirmation that the processing unit remains reachable from all connected sensors and light heads.
UPS Battery Degradation / Transfer-Switch Failure
Medium Severity
Root Cause
Aging or degraded UPS battery capacity, or a transfer switch that fails to hand load over cleanly during a mains interruption.
Effect
Complete system drop-out during a mains failure, at precisely the moment continuous surveillance-driven protection is most needed.
Detection Method
Simulated outage testing of the UPS, battery health checks, and verification of transfer-switch operation as part of scheduled maintenance.
Individual Light Head LED/Driver Failure
Low Severity
Root Cause
Failed LED module or driver at a specific light head, or a corroded/loose connection at the housing.
Effect
That light head stays dark or dim on an otherwise valid activation, reducing the alert's conspicuity without affecting the rest of the system.
Detection Method
Confirmation that the head received a valid activation command, housing seal and connector inspection, and driver output verification at the fixture.
Precautions

Safety & Operational Notes

Mains Circuit, Not a Series Loop
Electrical Safety

The FAROS driver runs on a dedicated mains branch circuit rather than the runway's CCR series loop; isolate and lock out at the FAROS driver's own supply point, and don't assume the PAPI is dead just because the FAROS circuit is isolated — the PAPI light units keep their own supply (mains for Style A, CCR series loop for Style B).

Surveillance Integration Dependency
Operational

The flashing indication is driven entirely by the surface surveillance feed (ASDE-X, ASSC, or ADS-B-based tracking); any work on the FAROS driver or the PAPI light units must be followed by an integration check confirming occupancy detection still correctly triggers flashing before returning the system to service.

PAPI Site Work Coordination
Operational

Because FAROS is retrofitted onto the PAPI's own hardware, work here follows the PAPI's own access, frangibility, and aiming-preservation procedures rather than a separate approach-lighting-structure procedure, coordinated with ATC and covered by a NOTAM for the affected runway.

Equipment Shelter Access
Electrical Safety

The FAROS controller, power supply, and monitoring unit are typically housed in an equipment shelter; follow standard electrical lockout procedure at the shelter's own supply before servicing the controller, independent of the field circuit isolation.

Verify Before Re-Energisation
Electrical Safety

After any field wiring or controller work, test the affected lights and confirm the surveillance interface still reports correctly before restoring the system to active monitoring.

Restore to Compliant State
Compliance

Do not return FAROS to service with an unverified occupancy trigger; confirm detection accuracy and flash synchronisation against the parent ALS system before closing out and cancelling the associated NOTAM.

Field Insight

Engineering & Expert Notes

Aiming Drift Is a PAPI Calibration Issue, Not a FAROS One
Mechanical

Because FAROS rides on the existing PAPI hardware rather than a fixture of its own, any azimuth/elevation drift is a PAPI aiming and pad-settlement issue — ground movement, frost heave, or a knocked stand — not something introduced by the FAROS retrofit. Re-verify PAPI aim against the extended runway centreline on the PAPI's own periodic schedule, and don't chase a "FAROS aiming" problem that is really a PAPI calibration problem.

Test the UPS as a Real Load Transfer, Not a Status Light
Electrical Safety

The safety case for FAROS depends on the mains-to-UPS backup circuit actually switching over correctly under a genuine mains loss. A healthy standby indicator doesn't confirm that — schedule an actual load-transfer test on the UPS circuit rather than relying on its status LED alone.

A Driver Swap Can Silently Change Cadence Without Touching Intensity
Retrofit

The FAROS driver only overrides the PAPI's steady/flashing state — it doesn't regulate beam intensity, which stays governed by the PAPI's own power and control unit. After swapping a FAROS driver module, confirm flash rate and duty cycle match spec; don't assume the retrofit affects intensity, and don't skip re-checking the PAPI's own photometrics if the PCU was touched during the same visit.

Validate Through the Real Control Interface
System Design

A FAROS fixture that flashes correctly on a manual bench test can still fail its intended function if the interface to RWSL, A-SMGCS, or ALCMS doesn't correctly trigger on actual runway occupancy. Validate through the live control interface, not just the fixture in isolation.

Frangible-Stand Vibration Loosens Fasteners Before It Damages Housings
Mechanical

PAPI/FAROS units sit on ground-level frangible stands exposed to jet-blast and continuous low-level vibration, which loosens fastener torque well before it produces any visible housing damage. Check fastener torque on a defined interval rather than waiting for a visual sign of movement to prompt a check.

Wind-Driven Rain at Ground Level Still Isn't a Bench Test
Durability

The IP65/67 rating on the PAPI/FAROS enclosure reflects rain driven horizontally by wind across open airfield terrain — angles a static bench seal-check never replicates. A gasket that seals fine on the bench can still leak in service, so don't treat a bench check as representative of in-service performance.

Quick Answers

Frequently Asked Questions

Short answers about FAROS (Final Approach Runway Occupancy Signal): what it is, how it works, specifications, standards, maintenance and common faults.

Q1What is FAROS?

The Final Approach Runway Occupancy Signal (FAROS) is an airfield safety capability that gives pilots on final approach a visual alert when the runway is occupied. It is an add-on control function for the existing PAPI rather than a standalone light fixture.

Q2How does FAROS alert pilots?

When surface surveillance detects that the runway's protected zone is occupied, the FAROS controller commands the PAPI light units to flash instead of burning steady. This gives the approaching pilot a clear runway-not-clear cue without extra cockpit equipment or waiting for an ATC radio call.

Q3What is the sequence of operation?

Surface surveillance (ASDE-X, ASSC or ADS-B-based tracking) tracks aircraft and vehicles, and the FAROS processing system checks whether a defined runway activation zone is occupied. If it is, the controller switches the PAPI from steady to flashing, and when the zone is clear the PAPI reverts to steady.

Q4Does FAROS add new lights?

No. It adds no new luminaire. It drives the runway's existing PAPI light units (the L-880/L-881 array), which keep their normal colour, beam pattern and intensity. Only the cadence changes, at about 60 flashes per minute adjustable at the FAROS driver.

Q5Where is FAROS installed?

At busy airports with high traffic and complex runway configurations where approach conflicts are a significant risk: precision approach runways (CAT II and III), major international airports with intersecting runways, and runways with high incursion risk.

Q6How is FAROS powered?

The FAROS driver runs on a dedicated mains branch circuit (120/240 V AC single-phase, regional variants available) with UPS backup, not a series CCR loop. The PAPI units stay on their own normal supply, and the driver has fault detection with UPS transfer and mains-loss monitoring.

Q7How does FAROS connect to other systems?

Through a low-voltage data link via a weatherproof junction box to RWSL, A-SMGCS or ALCMS, with the driver as a potted or conformal-coated interface module that overrides the PAPI's steady output and regulates flash rate. Enclosures are IP65 or IP67.

Q8Which standards apply?

The main references are ICAO Annex 14, FAA AC 150/5345-28H (PAPI systems), FAA Order JO 6850.2C (visual guidance lighting systems, including FAROS siting and integration) and FAA AC 150/5345-53 (equipment certification). Always verify the current edition and your aerodrome's approved requirements.

Q9How often should FAROS be maintained?

Typical intervals are quarterly for PAPI lens and optics cleaning, semi-annual for surveillance interface validation and UPS and power supply checks, and annual for flash intensity and rate, activation logic test, communication link inspection, housing and mounting inspection and software and firmware update review. Your airport's approved maintenance programme takes precedence.

Q10What are the common problems with FAROS?

Common problems are surveillance data latency or feed loss, false alarms from calibration drift or firmware faults, communication path failure, UPS battery degradation or transfer-switch failure, and individual light head LED or driver failure. Failure to activate on runway occupancy, frequent nuisance activations and delayed activation are the typical symptoms.

Explore Further

Related Components

Go Further

Go Beyond the Component. Understand the Complete AGL System.

You have explored the component. Now understand how it works within the complete Airfield Ground Lighting system.

Learn AGL from fundamentals to design, installation, testing, photometry, commissioning, maintenance and troubleshooting through structured technical training at Precision AGL Academy.

Build practical knowledge. Understand the circuit. Read the standards. Troubleshoot with confidence.

Your next step in AGL starts here.

The Learning Pathway
Learn Understand Design Test Maintain Document Apply Certify

Need expert guidance on FAROS system selection or installation?

Precision AGL Academy provides advice on system integration, surveillance optimization, and field testing of FAROS systems.