Asset register
Every item described by identifier, position, type, manufacturer, installation date, intervention history and lifecycle stage. Without it, no analysis means anything.
Home / Platform
ANTARES AGL-CMS
AGL-CMS installs on what is already there — whoever built it — and starts by watching without acting. Control comes later, tier by tier, once safety has been demonstrated.
Differences between airports are carried by configuration, never by code variants. One product to patch, to qualify and to keep alive.
Lighting topology, circuits, equipment and permissions are described in a versioned data model — importable, exportable and under configuration control.
Containerised, fully restorable from backup in under four hours. A site can be updated without interrupting operations, with rollback available.
Complete, usable export at any time, including at the end of the contract. Software bill of materials maintained and delivered. No non-substitutable proprietary dependency.
Functional requirements
The requirements below come from our product specification. Mandatory gates acceptance. Important requires a written waiver. Optional is a differentiator.
| Ref. | Criticality | Requirement |
|---|---|---|
| EF-01 | Mandatory | Real-time acquisition of every circuit's status: on/off, brightness step, output current, voltage, fault, local/remote mode. |
| EF-02 | Mandatory | Acquisition of the insulation resistance of every series circuit, historised, with alert thresholds configurable per circuit. |
| EF-03 | Mandatory | Geographic synoptic of the aerodrome: runways, taxiways, aprons, approach, with status colour-coded per circuit and per section. |
| EF-04 | Mandatory | Electrical synoptic per substation: cubicles, regulators, selectors, outgoing feeders, incoming supplies, standby generators, UPS units. |
| EF-05 | Mandatory | Supply monitoring: normal source, standby source, changeover time measured and compared with the maximum permitted for the site's operating category. |
| EF-07 | Important | Consolidated "operational capability" view per runway: the operating category genuinely holdable at this instant, given the lights out of service. |
| Ref. | Criticality | Requirement |
|---|---|---|
| EF-10 | Mandatory | Alarm management in at least three tiers — urgent, alert, information — with named acknowledgement, timestamping and suppression reason. |
| EF-11 | Mandatory | Dedicated alarm on adjacent lights out of service: the operating rule prohibiting two contiguous unserviceable lights is evaluated automatically and reported. |
| EF-12 | Mandatory | Alarm on availability threshold breaches per lighting system, configurable per runway and per operating category. |
| EF-13 | Mandatory | Avalanche suppression: causal grouping of alarms arising from a single root fault, without ever masking an urgent alarm. |
| EF-15 | Important | Contextual alarm help: probable cause, operational consequence, applicable procedure, history of occurrences. |
| Ref. | Criticality | Requirement |
|---|---|---|
| EF-21 | Mandatory | Ingestion of individual lamp data from existing ILCMS systems — power line carrier or otherwise — with unique light identifier, position, type, status and operating hours counter. |
| EF-22 | Mandatory | A failed light located on the synoptic with its exact operational designation, in fewer than three clicks from the alarm. |
| EF-23 | Important | Calculation and display of the availability rate per lighting system — runway, approach, taxiways, stop bars — measured against the applicable regulatory thresholds. |
| EF-24 | Important | Automatic generation of a replacement work list, optimised by geographic zone and by available closure window. |
| EF-25 | Optional | Correlation between ILCMS data and photometric measurements, to anticipate a light dropping below the permitted intensity threshold before outright failure. |
These requirements apply only to tiers P2 and P3, and can only be enabled once the corresponding safety gate has been passed. At tier P1, the control layer is absent from the delivered product, not merely disabled by configuration.
| Ref. | Criticality | Requirement |
|---|---|---|
| EF-30 | Mandatory | On/off control and brightness step setting per circuit, individually or through a pre-set runway configuration. |
| EF-31 | Mandatory | Pre-programmed operating configurations, callable in one action: runway in use, landing direction, night operations, low visibility operations, works, runway closed. |
| EF-32 | Mandatory | Safety interlocks preventing any command combination incompatible with a safe runway configuration — lighted crosses and runway lighting active simultaneously, opposing directions at once, and so on. |
| EF-33 | Mandatory | Individual and group control of stop bars and runway guard lights, with mandatory positive status feedback before the order is confirmed to the operator. |
| EF-34 | Mandatory | Management of control priority and ownership between workstations — tower, visual control room, electrical room, standby panel — with explicit handover, logged and notified to all positions. |
| EF-35 | Important | Follow-the-Greens guidance: taxi route construction, sequential illumination of centreline lights, extinction behind the aircraft, route conflict management. |
| EF-36 | Important | Automatic brightness control slaved to measured visibility conditions, with operator validation and immediate manual override available. |
| Ref. | Criticality | Requirement |
|---|---|---|
| EF-40 | Mandatory | National console presenting the consolidated status of every connected airport: active alarms, availability, work in progress, end-of-life equipment. |
| EF-41 | Mandatory | Hierarchical permission model: a site operator sees and acts only on their own site; a network operator views the whole estate with no local control capability. |
| EF-42 | Important | Cross-site comparison on standardised indicators: failure rate per thousand hours, mean time to restore, energy consumption per runway. |
| EF-43 | Important | Centralised management of the equipment estate and spare parts, with alerts on critical stock-outs at network level. |
| Ref. | Criticality | Requirement |
|---|---|---|
| EF-50 | Mandatory | Lockout regime: declared removal from service of a circuit or item of equipment, with controlled suppression of the associated alarms, reason, responsible person and expiry date. |
| EF-51 | Mandatory | Intervention log attached to each item of equipment: nature, operator, parts fitted, duration, result of return-to-service tests. |
| EF-52 | Important | Mobile field application working offline, with deferred synchronisation: reading work orders, entering readings and photographs, validating replacements. |
| EF-53 | Important | Preventive maintenance plan with tasks triggered on operating-hours, cycle or measured-drift thresholds. |
Interfaces
Every equipment family is integrated through an isolated driver, documented and testable independently of the core. That is what lets you change hardware supplier without changing supervision system.
| Ref. | Criticality | Interface |
|---|---|---|
| INT-01 | Mandatory | Manufacturer abstraction layer. One driver per equipment family, isolated and testable. Adding a manufacturer never changes the core. |
| INT-02 | Mandatory | Native support for Modbus TCP and RTU, OPC UA client, and digital I/O through a controller. |
| INT-03 | Mandatory | Acquisition drivers for the ALCMS and ILCMS systems of the main manufacturers, through the documented exchange interfaces they expose. |
| INT-04 | Mandatory | Interface to aerodrome meteorological data: runway visual range, visibility, ceiling, wind. |
| INT-05 | Important | A-SMGCS interface, consuming the surface situation and, at tier P3, publishing lighting states. |
| INT-06 | Important | CMMS interface: automatic creation of work orders from faults, with progress fed back. |
| INT-07 | Important | Feed into the aeronautical information process: unserviceabilities likely to warrant a NOTAM are identified, timestamped and exportable. Publication remains a human act. |
| INT-08 | Mandatory | Documented read-only API — REST over HTTPS, authenticated, versioned — exposing states, alarms and indicators to the operator's third-party systems. |
| INT-09 | Important | Standardised export of historised data and compliance reports in CSV, JSON and signed PDF. |
Non-functional requirements
A requirement without a measurable value is not a requirement. These are the ones we accept having written into the contract.
| Ref. | Characteristic | Required value |
|---|---|---|
| ENF-01 | On-screen refresh | ≤ 1 s between a field state change and its display on the synoptic, under nominal load. |
| ENF-02 | Command response time | ≤ 1 s between operator action and field execution; status feedback confirmed ≤ 2 s. Stop bars: in line with the delay imposed by the site's operating procedure. |
| ENF-03 | Supervision availability | ≥ 99.9 % annually excluding planned maintenance. ≥ 99.99 % for sites operated in CAT II/III. |
| ENF-04 | Redundant server failover | Automatic, ≤ 10 s, with no alarm or historised data lost, and no operator action. |
| ENF-05 | Capacity per site | ≥ 200 circuits · ≥ 20,000 addressed lights · ≥ 50,000 data points · ≥ 20 concurrent client workstations, with no degradation of response times. |
| ENF-06 | Network capacity | ≥ 30 airports aggregated on the national console. |
| ENF-07 | Historisation | Online retention ≥ 3 years for events and alarms, ≥ 1 year for high-frequency measurements, archiving ≥ 10 years. No operational event can be deleted or modified. |
| ENF-08 | Timestamping | NTP synchronisation to a reference source, accuracy ≤ 100 ms, timestamped at source, UTC in the database and local time on display. |
| ENF-09 | Disaster recovery | Recovery time objective ≤ 4 h, recovery point objective ≤ 15 min, tested annually. |
| ENF-10 | Environment | Substation hardware qualified for −10 °C to +60 °C, Saharan dust and coastal salt atmosphere. |
| ENF-11 | Maintainability | A site can be updated without interrupting operations, rollback available, version log viewable from the HMI. |
| ENF-12 | Longevity | No dependency on a non-substitutable proprietary third-party component; software bill of materials maintained and delivered. |
HMI & human factors
The interface is used at night, under time pressure, by operators whose attention is divided between several systems. Its design is a human factors matter as much as a graphic one — and it is validated with real operators, not in a meeting room.
Illustrative view of how information is laid out. Real synoptics are built on each airport's drawings and phraseology.
Data & analytics
Airfield lighting analytics are immature across most of the market: handsome dashboards, few maintenance actions actually triggered. Our rule is simple — a recommendation that cannot explain itself is not shipped.
Every item described by identifier, position, type, manufacturer, installation date, intervention history and lifecycle stage. Without it, no analysis means anything.
On insulation resistance, current and operating hours: identification of degrading circuits before outright failure, with the trend that justifies it.
Measurement, threshold, trend and history are shown alongside the recommendation. No opaque recommendation is accepted — including by us.
Availability per lighting system over a period, threshold breaches, supply changeover times. Exportable and signed for the authority and for audits.
Lighting consumption per circuit and per runway, with an indicator of the savings achieved after conversion to LED fittings.
Estimated per light family, feeding the multi-year renewal budget. Offered as a differentiator option.
Demonstration
We routinely reproduce regulators, controllers and faults on our test bench, then replay operating and failure scenarios: power loss, adjacent lights out, loss of the national centre, rollback. It is the best way to judge a supervision system.