ALCMS Server

The ALCMS Server (Airfield Lighting Control and Monitoring System Server) is the central computing and data management platform for the entire airfield ground lighting system. It is a high‑reliability industrial server that runs specialised software to communicate with field equipment—CCRs, remote I/O, PLCs, and smart fixtures—over various communication protocols (Ethernet, serial, fibre optic). The server provides a centralised point of control, monitoring, and data logging for all AGL assets across the airfield.

Key characteristics of the ALCMS server include:

• High Reliability: Designed for 24/7/365 operation in critical infrastructure environments, often with redundant power supplies, RAID storage, and hot‑swappable components.
• Industrial‑Grade Hardware: Built with industrial‑grade motherboards, processors, and memory that are tested for extended temperature ranges, vibration, and electromagnetic interference.
• Redundancy: Typically deployed in a primary‑backup or active‑active configuration to ensure uninterrupted operation in the event of a hardware failure.
• Secure Communication: Supports encrypted communication protocols (e.g., TLS, HTTPS) and role‑based access control (RBAC) to ensure that only authorised personnel can control or modify AGL settings.

Core functions of the ALCMS server include:

• Data Acquisition: Polling field equipment (CCRs, remote I/O, sensors) for status, current readings, alarm states, and fault conditions.
• Control Execution: Sending command signals to CCRs for brightness step changes, switching circuits on/off, and controlling stop bars and other field equipment.
• Alarm Management: Processing and prioritising alarms from field equipment, displaying them on operator workstations, and logging them for historical analysis.
• Logging and Reporting: Storing historical data on circuit status, current readings, alarm events, and operator actions for compliance, reporting, and trend analysis.
• User Interface: Serving the operator interface (HMI/SCADA) to workstations, presenting a visual representation of the airfield with real‑time status indicators.

The server is typically installed in a secure equipment room or control tower, connected to the airfield network via redundant fibre optic or Ethernet links. It is maintained by the airfield's IT and engineering teams, with regular backups, patches, and performance monitoring.

The ALCMS server exists as the single source of truth for the entire airfield lighting system's status, because without centralised data acquisition and control execution, every operator workstation, alarm panel, and remote HMI would need its own independent connection to hundreds of field devices — a fragile, inconsistent, and effectively unmanageable architecture. By consolidating polling, control commands, and historical logging into one authoritative platform, the server ensures every part of the AGL system sees the same, current picture of the field.

Its emphasis on redundancy and 24/7/365 reliability reflects what's actually at stake if it fails: since it's the platform that processes alarms, executes control commands, and serves the operator interface, a server outage doesn't just lose data — it can cut operators off from monitoring and controlling live runway and taxiway lighting, which is why hot-swappable components and active-active configurations are standard rather than optional for this role.

The ALCMS server is used in all airfields that have a modern AGL control and monitoring system, including:

• International Airports: Managing large‑scale AGL systems with multiple runways, taxiways, and approach lighting systems, often with redundant servers and distributed I/O.
• Regional Airports: Providing centralised control and monitoring for smaller but still critical AGL systems, often with a single server and a limited number of workstations.
• Military Air Bases: Supporting mission‑critical AGL operations with enhanced security features and redundant configurations.
• Heliports: Controlling and monitoring heliport lighting systems, often with a smaller‑scale ALCMS server.
• Airfield Equipment Shelters: The server may be installed in an airfield equipment shelter near the CCR room, or in the control tower, depending on the architecture.

The server is the core component of the ALCMS architecture, which typically includes:

• Field Equipment: CCRs, remote I/O modules, PLCs, smart transformers, and sensors.
• Communication Network: Fibre optic backbone, Ethernet switches, and communication gateways.
• Operator Workstations: Desktop PCs or thin clients running the ALCMS operator interface.
• Peripheral Systems: Printers for alarm logging, external displays for status boards, and integration with other airport systems (e.g., ATC, ground handling).

The server is typically specified with high‑availability features, including dual power supplies, RAID 1 or RAID 10 storage, and redundant network interfaces. The software is designed to be fault‑tolerant, with automatic failover to a backup server in the event of a primary server failure.

Servers are rack-mounted in the airport's main equipment room or a dedicated ALCMS server room with controlled access, conditioned power (UPS-backed), and adequate cooling for continuous operation, rather than in the operator-facing control room itself. Where the system is configured with redundant servers, the pair is split across separate racks or rooms on independent power feeds so a single electrical or physical fault cannot take down both; network cabling runs to the site's core switches on structured cabling rather than field cable, keeping the server room's cabling entirely separate from the field-device wiring that terminates at PLCs and Remote I/O out at the substations.

The ALCMS server functions as the central brain of the airfield lighting system, orchestrating all control, monitoring, and data management activities:

• Communication Engine: The server runs a communication engine that polls field equipment at configurable intervals (typically 1‑5 seconds). It uses protocols such as IEC 61850, MODBUS, DNP3, or proprietary protocols to communicate with CCRs, remote I/O, and smart fixtures. The engine handles time‑stamping, retries, and error handling to ensure reliable data exchange.
• Database Management: The server hosts a real‑time database that maintains the current state of all AGL equipment (on/off status, current level, alarm states). This database is continuously updated and serves as the source of truth for operator displays. Historical data is logged to a separate historian database for analysis and reporting.
• Alarm Processing: The server analyses incoming data for abnormal conditions, such as circuit faults, overcurrent, undercurrent, or communication loss. Alarms are categorised by severity (critical, major, minor) and displayed on operator workstations with clear visual and audible indicators. The server also logs all alarm events for later review.
• Command Execution: When an operator initiates a control action (e.g., changing brightness level, turning on a runway), the server validates the command (checking permissions, operational constraints), formats it into the appropriate protocol, and transmits it to the target field device. The server then confirms the successful execution and updates the operator interface.
• User Interface: The server hosts a web‑based or client‑server graphical user interface that is accessed by operator workstations. The interface provides a dynamic, geospatial representation of the airfield, with colour‑coded icons indicating the status of each circuit and fixture. Operators can click on any element to view detailed status, historical data, or to issue commands.
• Security Management: The server implements role‑based access control (RBAC), allowing different user levels (operator, supervisor, administrator) with different permissions. All user actions are logged for audit purposes. The server also supports encrypted communication (TLS/SSL) to protect against unauthorised access and eavesdropping.

The server is typically deployed in a client‑server architecture, with multiple workstations connecting to the server over the airfield network. In larger airports, a redundant server configuration is used, with a primary server and a hot‑standby backup server that automatically takes over in the event of a failure. The server also includes comprehensive diagnostics and self‑monitoring capabilities, alerting operators if the server itself experiences any issues.

The ALCMS server sits at the centre of the control hierarchy, one level above the field controllers and one level below the operator. Upstream, it exchanges real-time status and receives validated commands from PLCs, Remote I/O units, and CCRs, typically reaching them through an Ethernet switch and, where legacy or serial field devices are involved, a Communication Gateway or SCADA Interface performing protocol translation (Modbus, IEC 61850, OPC UA). Downstream, it serves one or more ALCMS Workstations (and Touchscreen HMIs at local panels), pushing map-based status updates and accepting operator commands after validating them against permissions and interlock conditions. Every status change and command is timestamped and written to the historian database, so the server is also the single point where the full operational picture and audit trail come together.

The server is built in a standard 19-inch rack-mount chassis, either 2U or 4U depending on storage and expansion needs, with a steel or aluminium enclosure designed for continuous airflow through front-to-rear cooling fans. Dual hot-swappable power supplies sit in the rear, each independently fed from the facility's redundant UPS circuits so either can fail without interrupting operation, and hot-swap drive bays at the front allow RAID array members to be replaced without powering down the server. Internal cabling and expansion cards (network interfaces, serial adapters, fibre SFP modules) are secured to the chassis rail system per rack-mount convention, and the unit is designed to sit in a temperature- and humidity-controlled equipment room or server rack rather than an outdoor cabinet. Front-panel status LEDs and a local console port allow basic diagnostics without needing to log in remotely, and the chassis is typically secured in the rack with a lockable front bezel to prevent unauthorised access to drive bays and power switches.