When an aircraft emergency is declared, the gap between declaration and full agency mobilization is measured in seconds. What determines how wide that gap is comes down to one thing: how the airport notifies responding agencies, and how fast and reliably that notification reaches every team simultaneously.
Most airports have historically managed that notification through crash phone protocols: a sequential call chain in which ATC contacts ARFF, then police, then medical, then airport operations, one agency at a time. The process works well enough under normal conditions. Under real emergency pressure, with the aircraft still active and the airspace still being managed, it is a manual process consuming controller attention that should be on the aircraft, producing a sequential notification record that cannot fully satisfy FAA documentation requirements, and relying on infrastructure that fails under exactly the conditions it is most needed.
Aircraft Emergency Systems replace that process with a single-action, simultaneous, documented notification platform. This guide covers how they work, what they deliver operationally, and what airport leaders need to understand before evaluating options.
An Aircraft Emergency System (AES) is a dedicated alerting platform that automates the notification process from the moment an emergency is declared. The controller or dispatcher enters incident data into a touchscreen interface and sends a single notification. Every responding agency (ARFF, police, medical, airport operations) receives the alert simultaneously, with identical information, in seconds.
The platform handles the notification chain that crash phone protocols assign to a controller working a live emergency. What previously required sequential manual calls now happens in a single action. The controller's attention returns to the aircraft before the first agency has finished reading the alert details.
Beyond the initial notification, AES platforms monitor the status of every alert in real time. Controllers and dispatchers can see, on the tower or operations interface, which agencies have confirmed receipt. The system logs every event with a timestamp automatically: declaration time, agencies notified, data entered, confirmation received. That record is complete, accurate, and produced without any additional documentation effort from tower staff.
Crash phones have been the standard airport emergency notification method for decades. They work. But they carry three structural limitations that AES is specifically designed to address.
The first is sequential notification. Crash phone protocols require ATC to contact agencies one at a time, which means the last agency notified receives the alert meaningfully later than the first. In a time-critical aircraft emergency, that sequential gap affects coordination from the first moment of response.
The second is infrastructure dependency. Crash phones rely on VoIP lines and in older installations copper infrastructure. Both are vulnerable to failure under the conditions that accompany a real emergency: network stress, potential physical damage to airfield infrastructure, and the kind of high-load operational pressure that surfaces latent hardware problems. A crash phone system that fails during a real emergency has no automatic backup.
The third is documentation. A sequential verbal call chain produces no automatic timestamped record. When an FAA audit or post-incident review asks for documented evidence that notification procedures met Part 139 requirements, the answer under a crash phone protocol depends on dispatcher recollection and whatever informal notes were kept. That is not the same as a system-generated log, and FAA auditors know the difference.
FAA Part 139 requires airports to maintain documented, multi-agency emergency notification procedures. The standard is specific: the right agencies must be notified, notification must happen within defined timeframes, and the process must be documented in a form that survives a post-incident review or certification audit.
AES platforms satisfy that requirement by design. Every declaration generates an automatic record: incident data entered, agencies notified, timestamps for each notification, confirmation received from each agency. The documentation builds itself as a byproduct of normal system operation, without any additional step from tower or operations staff.
For airports that have been through a Part 139 review under manual protocols, the difference is concrete. The FAA Part 139 airport alerting requirements article covers the specific documentation standards in detail, what a certification review asks for, and how the gap between what crash phone protocols produce and what the standard requires creates real compliance exposure.
Aircraft emergencies rarely involve a single department. ARFF, police, medical, airport operations, and in some cases mutual aid agencies from off-airport all play a role. The quality of coordination between those agencies in the first minutes of a response depends heavily on whether they received the same information at the same time.
Sequential crash phone notification means agencies start from different points in the timeline, with information that arrived at different moments and sometimes with varying details depending on how the call chain was managed. AES delivers identical data to every agency simultaneously. Every team reads the same incident type, runway, aircraft data, and declared emergency level from the first second of the response.
The multi-agency coordination in aircraft emergency response article covers how simultaneous notification changes the coordination picture in practice, including what the difference between sequential and simultaneous alerting looks like in a post-incident timeline review.
For ARFF Chiefs, the notification system is the starting point of the response clock. The time between aircraft emergency declaration and ARFF mobilization is where AES delivers its most direct operational impact. Removing the manual crash phone call chain from the notification process and replacing it with a single touchscreen action compresses that gap directly.
ARFF crews receive simultaneous notification through the station alerting system, with full incident data on bay displays before they have finished mounting apparatus. The controller who made the declaration is back on frequency managing the aircraft before the first unit has started moving. The agencies are moving in parallel rather than in sequence.
For the specific response time data and operational details from ARFF deployments, the how Westnet AES improves ARFF response times article covers the measurable differences between crash phone and AES notification timelines, and the Westnet AES rapid response case study documents a real deployment at a military airfield where notification time was reduced from minutes to seconds.
A reliable AES platform operates independently of the infrastructure most likely to fail under emergency conditions. Westnet's AES uses redundant notification paths that do not depend on VoIP or copper lines. If the primary alert path fails, a secondary path activates automatically. Agencies receive the notification regardless of what the primary communications infrastructure is doing.
That redundancy also extends to the CAD integration layer. Westnet's platform connects directly with airport and public safety CAD systems, passing call data automatically through the notification process. If the CAD connection fails, the system continues to operate through manual entry on the touchscreen interface without losing the automated notification and documentation functions.
For airports evaluating how AES fits into the broader dispatch and alerting architecture, the integrated CAD dispatch alerting guide covers CAD integration architecture in depth, including how to evaluate whether a vendor's integration has been validated against your specific platform.
For airport COOs and directors, the AES investment case rests on three pillars: regulatory compliance, liability exposure, and long-term cost structure.
A Part 139 finding that traces to inadequate notification documentation carries real consequences for airport certification status, insurance positioning, and institutional reputation. Manual crash phone protocols create a structural documentation gap that an AES closes. An airport that can produce a complete, timestamped notification record for every declared emergency is in a fundamentally different position in any FAA review or post-incident proceeding than one that relies on dispatcher recollection.
On the funding side, AES infrastructure qualifies for FAA Airport Improvement Program (AIP) grants as an airport safety system improvement, which can cover a substantial portion of the capital cost. ISO rating improvements from upgraded alerting infrastructure translate directly into lower insurance premiums over time. The making the case for aircraft emergency system investment article covers the full board-level financial and risk justification, including how to structure the AIP funding application and build the ISO cost model.
Airport leaders evaluating AES platforms should focus on five questions. First, has the platform been deployed at airports with comparable size, traffic type, and CAD infrastructure, and are peer references available? Second, what is the redundancy architecture, and has automatic failover been tested under production conditions with documented results? Third, what does the FAA documentation record look like for a real incident, and can the vendor show an example? Fourth, what is the training requirement for tower controllers, and how does the workflow change from current crash phone protocols? Fifth, what is the IT security posture, network footprint, and remote support model?
Those five questions separate platforms that have been built for real airport environments from platforms that perform in demonstrations. The answers should be provided in writing before any formal evaluation proceeds.
The supporting articles in this series address each dimension of the aircraft emergency alerting decision in depth. The FAA Part 139 compliance piece covers documentation requirements and audit preparation. The multi-agency coordination article covers simultaneous notification architecture. The ARFF response time piece covers mobilization impact. The investment case article covers AIP funding, ISO rating improvement, and board-level financial justification.
For airports ready to evaluate specific platform options, Westnet's aircraft emergency systems page covers the full platform architecture, touchscreen interface, CAD integration capabilities, and redundancy design.