Layered Architecture
FootfallCam V9 is structured as a layered architecture to allow airports to adopt, operate, and extend integration capabilities without committing to a single integration path. Each layer exposes clear inputs and outputs and can be used independently or in combination with others. This allows airports to start with simple data access and reporting, and extend into deeper integration only when required.
Integration Interfaces
FootfallCam V9 supports multiple integration interfaces that connect the layered architecture to existing airport systems. These interfaces illustrate how operational data can be exchanged without replacing or encroaching on existing platforms.
Common integration examples include:
AODB / FIDS reference interfaces
- Flight reference
- Gate and stand reference
- ETA / ETD windows
- Flight bank grouping
APOC operational feeds
- Congestion states
- Threshold breach indicators
- Predicted operational pressure
- Alert notifications
These are representative examples rather than an exhaustive list. The same architecture supports other interfaces, including BI platforms, reporting systems, and third‑party operational tools.
Health Monitoring
Health monitoring covers the operation of the integration itself.
It provides visibility into whether data pipelines, interfaces, and alert delivery are functioning as configured, across all enabled integration layers.
Monitoring covers:
- Data pipeline availability
- Interface connectivity
- Event and alert delivery status
- SLA and service indicators
Health monitoring supports routine operation, fault isolation, and audit, without affecting upstream airport systems.
Case Study
Some of our deployments across various airports
Terminal Expansion Due Diligence
Audit-Driven Integration Review
Health Monitoring and SLA visibility
AODB/FIDS Correlation
Incremental APOC Enablement
Baggage Reclaim Congestion
Border Control Queue Evidence
Reporting-First Regional Airport
Contractor Performance Review
Security Checkpoint Optimisation
Terminal Expansion Due Diligence
Case Study 1
Multi-Stakeholder Due Diligence Before Terminal Expansion
Situation
A terminal expansion project required sign-off from multiple stakeholders, including airlines, regulators, and investors. Each party questioned assumptions about future passenger flow and congestion. The airport needed data to support its case without committing to long-term analytics integration before funding approval.
Implementation
FootfallCam was deployed as a temporary analytics layer to capture baseline and projected flow scenarios. Data was accessed via dashboards and exports only. Integration scope and retention were explicitly time-bound. Health monitoring was enabled to ensure data completeness for audit review.
Outcome
The airport provided credible evidence to support expansion assumptions. Stakeholders accepted the findings because the analytics deployment was bounded, transparent, and reversible. Once approvals were secured, the airport retained the option to extend or remove the analytics layer without rework.
Audit-Driven Integration Review
Case Study 2
Audit-Driven Integration Review for a Public-Sector Airport
Situation
A publicly owned airport underwent regular audits focusing on data governance, vendor dependency, and operational accountability. Previous integrations had failed audit reviews due to unclear data ownership and lack of monitoring. Any new integration required demonstrable controls and exit options.
Implementation
FootfallCam integration was documented using a layered architecture model, with explicit boundaries and monitoring. Health checks, delivery logs, and SLA indicators were enabled to support audit evidence. Data exports and APIs were documented as part of the procurement record.
Outcome
The airport passed audit review without remedial actions related to analytics integration. Governance teams accepted the deployment as bounded and observable. The airport retained flexibility to expand or reduce integration scope without contractual or architectural renegotiation.
Health Monitoring and SLA visibility
Case Study 3
“Integration You Can Operate”: Health Monitoring and SLA visibility
Situation
A large airport had experienced integration failures from previous vendors: silent breaks, missing feeds, and unclear accountability. The operational impact wasn’t always the outage itself, but the time wasted proving where the fault was (device, network, API, downstream system, or configuration change). The airport’s due diligence requirement was simple: if integration exists, it must be observable and auditable.
Implementation
Health monitoring was treated as part of integration, not an extra. Monitoring covered pipeline availability, interface connectivity, event delivery status, and SLA indicators. Delivery logs and completeness flags were made available to support incident triage. The airport defined escalation paths and evidence expectations for integration incidents (what to check first, what to export for audit).
Outcome
Integration issues became diagnosable rather than political. When a feed degraded, the airport could isolate the layer affected and take corrective action without disrupting upstream systems. Procurement and governance teams accepted the integration more readily because operational oversight existed by design, aligning with auditable operating procedures.
AODB/FIDS Correlation
Case Study 4
AODB/FIDS Correlation for Flight-Bank Analysis (read-only hooks)
Situation
A mid-size hub experienced sharp congestion waves driven by flight banks. Operations could see congestion, but could not reliably attribute it to schedule shifts, stand moves, or gate reassignments without manual cross-referencing. The airport had an AODB and FIDS, but the analytics initiatives that tried to “merge everything” were rejected because they blurred authority and created political friction between teams.
Implementation
The airport enabled read-only correlation hooks: flight reference, gate/stand reference, ETA/ETD windows, and flight-bank windows. FootfallCam outputs remained event/aggregate-based; AODB remained the authority for flight truth. Correlated fields were appended for analysis and reporting, not used to drive operational control. The integration was implemented as a bounded interface with a defined mapping and a controlled change process.
Outcome
The airport gained defensible “flight-bank vs congestion” reporting without rewriting existing systems. Planning teams could quantify which flight banks created repeatable pinch points and evaluate gate/stand policies using the same datasets. IT accepted the approach because it was read-only, bounded, and reversible.
Incremental APOC Enablement
Case Study 5
Incremental APOC Enablement in a Resource-Constrained Airport
Situation
An airport planned to establish an APOC function but lacked the resources to implement a full integrated operating model. Leadership wanted early benefits without committing to a large transformation programme. The risk was deploying tools that would later be discarded or require rework.
Implementation
The airport started with dashboards and rules to define congestion states internally. APOC feeds were enabled only for a small set of zones as structured signals. Health monitoring was enabled from the outset to track feed reliability. Other areas continued to use standalone reporting.
Outcome
The airport achieved partial APOC capability aligned with its maturity and budget. Expansion decisions were made incrementally, using operational evidence rather than aspiration. Because the architecture was layered, no reconfiguration was required as scope increased.
Baggage Reclaim Congestion
Case Study 6
Baggage Reclaim Congestion Without Touching BHS
Situation
An airport experienced recurring congestion in baggage reclaim halls during peak arrival banks. While the Baggage Handling System (BHS) provided belt status and alarms, it did not offer passenger density or dwell visibility. Previous proposals to integrate analytics directly into BHS workflows were rejected due to certification risk and vendor constraints.
Implementation
FootfallCam was deployed in reclaim halls to provide zone-level density, dwell time, and congestion states. Integration was limited to dashboards and scheduled exports. No BHS integration was attempted. Operational zones were aligned to reclaim belts and circulation areas to maintain relevance without system coupling.
Outcome
Operations teams gained visibility into reclaim congestion independent of BHS performance. Decisions around staffing, belt allocation, and passenger routing were supported by objective data. Governance approval was achieved because no certified systems were modified and analytics remained observational.
Improving Passenger Border Control Queue Evidence
Case Study 7
Border Control Queue Evidence for Staffing Negotiations
Situation
Border control queues were a recurring point of tension between the airport, government agencies, and airlines. Each party relied on different evidence, often based on manual sampling or anecdotal reporting. The airport needed consistent, defensible data to support staffing and layout discussions without interfering with border control systems.
Implementation
FootfallCam analytics were deployed upstream and downstream of border control zones. Data access was limited to dashboards and exports, aligned to agreed reporting windows. No real-time alerting or external feeds were enabled. Definitions of queues and wait times were agreed upfront and documented.
Outcome
The airport established a neutral dataset accepted by all stakeholders. Discussions shifted from disputing numbers to evaluating staffing scenarios. Because integration scope was limited and observational, the deployment avoided regulatory escalation and was accepted as supporting evidence rather than operational control.
Reporting-First Regional Airport
Case Study 8
“Reporting First” for a Regional Airport (BI export only)
Situation
A regional airport had strong operational teams but a small IT function. Performance reviews relied on manual evidence packs: screenshots, spot checks, and spreadsheets compiled by different departments. Queue discussions repeatedly stalled on one issue: inconsistent time windows, missing hours, and disagreements over definitions (what counts as a “queue”, when does a wait start/stop). The airport wanted usable datasets for annual planning and budget defence, without creating a new integration project.
Implementation
FootfallCam was deployed as a reporting source only. V9 produced zone-level hourly and daily aggregates and exported a standard dataset into the airport’s existing BI workspace. The airport’s own KPI definitions (queue buckets, peak hour windows, terminal rollups) were configured as named metrics so reporting remained stable across months. No AODB correlation and no APOC feeds were enabled at this stage.
Outcome
The airport standardised reporting without touching core systems. Ops reviews shifted from “do we trust the numbers” to “what actions do we take next quarter”. The BI team gained repeatable datasets, and the airport avoided a governance escalation because the integration stayed at export level. Monitoring was enabled only for export delivery status and dataset completeness.
Contractor Performance Review
Case Study 9
Contractor Performance Review Using Independent Data
Situation
An airport outsourced several operational functions, including cleaning and queue management. Performance reviews were contentious due to lack of consistent, objective evidence. Existing contractor systems did not align with airport KPIs, and integrating into them was not considered viable.
Implementation
FootfallCam analytics were used to provide independent measurements of congestion, dwell, and utilisation in contracted areas. Data was shared via exports during review cycles. No direct system integration or live alerts were enabled. Metrics were documented and frozen for contractual reporting periods.
Outcome
Performance reviews became evidence-based and less adversarial. Contractors accepted the data as neutral because it was not tied to their own systems. The airport strengthened governance without increasing integration complexity or operational dependency.
Security Checkpoint Optimisation
Case Study 10
Security Checkpoint Optimisation Without System Replacement
Situation
An airport faced recurring complaints about security wait times, particularly during seasonal peaks. Multiple systems were already in place: staffing rosters, security lane management tools, and manual reporting processes. Previous proposals to integrate deeply with security systems were rejected due to regulatory sensitivity and unclear accountability. The airport needed better evidence for staffing and layout decisions without touching certified security platforms.
Implementation
FootfallCam was deployed upstream of security checkpoints to provide zone-level flow, queue length, and wait-time aggregates. Data was used through dashboards and scheduled exports only. No direct integration with security systems was implemented. Metrics were aligned to the airport’s existing reporting periods and terminology to avoid redefining operational language.
Outcome
The airport gained consistent, time-aligned evidence for staffing and lane configuration decisions. Discussions with regulators and contractors shifted from anecdotal feedback to structured data. Integration scope remained limited, and governance approval was achieved noting that no certified systems were modified or coupled.
FAQs
Learn More