ALCMS Database Server

The ALCMS Database Server is the core data management component of the Airfield Lighting Control and Monitoring System. It is a purpose‑built database system (typically SQL or time‑series based) that serves as the single source of truth for all AGL operational data. The Database Server stores and manages everything from static configuration data (airfield layout, circuit mappings, equipment inventory) to dynamic operational data (real‑time status, alarms, event logs, and operator actions), providing the data backbone for the entire ALCMS ecosystem.

Key characteristics of the ALCMS Database Server include:

• Centralised Data Repository: Consolidates all AGL data — configuration, real‑time status, historical events, alarms, operator logs, and maintenance records — into a single, consistent database.
• High Availability & Redundancy: Deployed in active‑passive or active‑active clustering configurations with automatic failover, ensuring continuous data access even during server failures.
• Scalable Performance: Optimised for high‑throughput write operations (thousands of events per second) and fast query responses (milliseconds), supporting large airfields with thousands of light fixtures and sensors.
• Data Integrity & Security: Implements robust transaction management, ACID compliance, encryption at rest, and role‑based access control to protect sensitive operational data.
• Comprehensive Data Model: Supports the full AGL data model — including circuits, CCRs, light fixtures, transformers, alarms, events, users, and maintenance activities — with relationships and metadata.
• Built‑in Archiving & Retention: Includes automated data archiving and purging policies to manage storage growth while preserving historical data for regulatory compliance.
• Integration APIs: Provides standard interfaces (SQL, ODBC, JDBC, REST API, OPC UA) for seamless integration with ALCMS workstations, SCADA systems, and enterprise asset management (EAM) platforms.

The ALCMS Database Server is typically deployed as a dedicated physical server or virtual machine in the airfield's control centre or data centre. It is the foundation upon which all ALCMS functionalities — monitoring, control, reporting, and analytics — are built. Its reliability, performance, and security are critical to the safe and efficient operation of the airfield lighting system.

The database server's purpose is to make sure every part of the ALCMS — every workstation, every operator, every report — is working from the same set of facts. Without a single authoritative store, it becomes possible for one screen to show a fixture as healthy while another still reflects a fault that was actually cleared minutes ago, which is exactly the kind of inconsistency that erodes an operator's confidence in what they're looking at during an active event. High availability and clustering matter for the same underlying reason: this database isn't just holding data, it is effectively the system's memory of the entire airfield's lighting state and history, and losing access to it — even briefly — means losing the ability to reliably monitor, control, or later account for what happened, not just losing one server's worth of information.

The ALCMS Database Server is deployed in every airfield with a modern AGL control and monitoring system, serving as the backbone for all data‑driven operations. Key applications include:

• ALCMS Core Infrastructure: Providing the data persistence layer for the ALCMS server, workstations, and operator consoles, ensuring that all status information, alarms, and commands are stored reliably.
• Real‑Time Status Management: Maintaining up‑to‑date status of every circuit, CCR, light fixture, and sensor, enabling the ALCMS to display current operational states to operators.
• Event & Alarm Logging: Storing all system events, alarm activations, and operator actions with precise timestamps, providing a complete audit trail for incident investigation and compliance.
• Configuration Management: Storing and version‑controlling all system configurations — including circuit assignments, brightness step mappings, alarm thresholds, and user permissions.
• Reporting & Analytics: Providing the data foundation for generating operational reports, maintenance dashboards, performance trends, and predictive analytics.
• SCADA & Enterprise Integration: Serving as the data interface for integration with airport‑wide SCADA systems, enterprise asset management (EAM) systems, and business intelligence platforms.
• Regulatory Compliance: Providing the data retention and audit capabilities required by FAA, ICAO, and other regulatory bodies for AGL system records.
• Maintenance & Asset Management: Tracking maintenance history, equipment lifecycles, and repair records to support predictive and preventive maintenance programs.

The database server is installed as a rack-mounted physical server or virtual machine in the airfield's main control centre or data centre, in a climate-controlled room alongside the ALCMS application server and core network equipment rather than out at any field location. Where high availability is specified, a second server is installed in a physically separate room, building, or site, connected by a dedicated replication link so that a fire, flood, or power event affecting one location cannot take down both database instances at once. Power is drawn from a UPS-protected, and ideally dual-fed, circuit, since an uncontrolled shutdown during a write operation risks database corruption rather than a mere loss of connectivity. Storage is sized and configured (RAID, SSD tiering) for the sustained high-throughput write load of continuous event logging, and the server's network connection ties into the same redundant core switching used by the rest of the ALCMS infrastructure so database access does not depend on a single network path.

The ALCMS Database Server operates as a high‑performance data management engine, handling both real‑time operational data and historical records. Key functional aspects include:

• Data Ingestion: The database receives data from multiple sources — the ALCMS server (which aggregates data from field devices), operator workstations (for configuration changes and commands), and external systems (SCADA, maintenance). Data is ingested via APIs, SQL statements, or message queues (e.g., MQTT, AMQP).
• Data Storage & Indexing: The database stores data in optimised tables or collections. For high‑volume time‑series data (events, alarms, status changes), a time‑series database engine (e.g., TimescaleDB, InfluxDB) may be used. Indexes are created on key fields (timestamp, device ID, event type) to support fast queries.
• Real‑Time Data Access: The database provides low‑latency access to real‑time data (current status, active alarms) via in‑memory caches or materialised views. This ensures that operators see near‑instantaneous updates on their consoles.
• Historical Query & Retrieval: For historical analysis, the database supports complex queries with time‑range filters, aggregations, and joins across multiple tables. Query performance is optimised through partitioning (by date), compression, and summarisation (pre‑aggregated views).
• Transaction Management: All write operations are wrapped in ACID transactions to ensure data consistency. This is critical for configuration changes and command execution, where partial updates could lead to inconsistent system states.
• Data Security & Access Control: The database enforces role‑based access control (RBAC) at the table, row, and column levels. All access attempts are logged for security auditing. Data at rest is encrypted using industry‑standard encryption (AES‑256).
• Backup & Recovery: Automated full and incremental backups are performed regularly. Point‑in‑time recovery capabilities allow restoration to any previous state, protecting against data corruption or accidental deletion.
• High Availability & Failover: In critical installations, the database is deployed in a cluster with automatic failover. The active node handles all read/write operations, while the passive node replicates data and takes over seamlessly in the event of a failure.
• Data Archiving & Retention: Configurable retention policies automatically archive or purge old data. For example, detailed event logs may be retained for 90 days, while aggregated summaries are kept for 10 years. Archived data can be moved to cheaper storage (tape, cloud) for long‑term preservation.

The Database Server is maintained by system administrators and database specialists. It is monitored continuously for performance, storage capacity, and health, with alerts generated for any anomalies. Regular maintenance tasks — such as reindexing, vacuuming, and statistics updates — are scheduled to ensure optimal performance.

The database server is built in a standard 19-inch rack-mount chassis, sized to the storage capacity required (typically 2U to 4U), with front-accessible hot-swap drive bays arranged in a RAID 10 array so any single drive can fail — or multiple drives, provided no two failed drives belong to the same mirrored pair — without interrupting data availability. Dual hot-swappable power supplies at the rear are fed from independent circuits so either can be pulled and replaced without powering down the server, and high-speed NVMe SSDs are used for the active database tier while larger-capacity HDDs handle long-term archive storage within the same chassis or an attached storage shelf. Dual 10 GbE network interfaces, optionally backed by fibre SFP modules, are mounted on expansion cards secured to the chassis rail system, keeping the high-throughput data path independent of the server's management network connection. The unit is designed to sit in a temperature- and humidity-controlled server room or data-centre rack, with a lockable front bezel restricting physical access to drive bays and power controls, and where clustering is used for high availability, the standby server is installed in a physically separate rack or room so a single point of failure cannot take out both nodes.