商販
分層架構
FootfallCam V9 該系統採用分層架構，使機場能夠靈活地採用、運行和擴展整合功能，而無需局限於單一的整合路徑。每一層都提供清晰的輸入和輸出，既可獨立使用，也可與其他層組合使用。這使得機場可以從簡單的數據存取和報告入手，僅在需要時才進行更深入的整合。
整合介面
FootfallCam V9 支援多種整合接口，可將分層架構與現有機場系統連接起來。這些介面展示如何在不替換或侵占現有平台的情況下交換運作資料。常見的整合範例包括：
AODB/FIDS 參考接口
航班參考
閘門和月台參考
預計到達時間/預計出發時間窗口
航班銀行分組
APOC 營運資訊
擁堵狀態
閾值突破指標
預測運轉壓力
警報通知
這些只是範例，並非完整清單。同一架構也支援其他接口，包括商業智慧平台、報表系統和第三方操作工具。
資料交換控制器
FootfallCam 使機場能夠同時掌控測量層和運作解讀層。這是一種標準的模組化方式，可將客流智慧資料與機場系統、顯示器和行動操作連接起來。
資料交換控制器白皮書
健康監測
健康監控涵蓋整合本身的運作。它能夠顯示所有已啟用整合層的資料管道、介面和警報傳遞是否按配置運作。
監測範圍包括：
- 數據管道可用性
- 介面連接
- 事件和警報交付狀態
- 服務等級協定和服務指標
健康監測支援日常運作、故障隔離和審計，且不會影響上游機場系統。
案例分析
碼頭擴建盡職調查
審計驅動的整合審查
健康監控和 SLA 可見性
AODB/FIDS 相關性
增量式 APOC 啟用
行李提取處擁堵
邊境管制排隊證據
報道-第一區域機場
承包商績效評估
安全檢查點優化
碼頭擴建盡職調查
案例研究1
碼頭擴建前的多方利害關係人盡職調查
情況
航站擴建工程需要獲得包括航空公司、監管機構和投資者在內的多方利害關係人的批准。各方都對未來客流量和擁塞情況的假設提出了質疑。機場需要數據來支持其方案，但又不想在獲得資金批准前承諾進行長期的分析整合。
實施
FootfallCam 該平台被部署為臨時分析層，用於捕獲基線和預測的流量場景。資料僅可透過儀錶板和匯出功能存取。整合範圍和資料保留時間均有明確的時限。啟用了運作狀況監控功能，以確保資料完整性，滿足稽核審查要求。
結果
機場提供了可信的證據來支持其擴建假設。利害關係人接受了這些結論，因為分析部署的範圍有限、透明且可逆。一旦獲得批准，機場即可選擇擴展或移除分析層，而無需返工。
審計驅動的整合審查
案例研究2
公共部門機場的審計驅動整合審查
情況
一家公有機場定期接受審計，重點關注資料治理、供應商依賴性和營運責任。先前的系統整合由於資料所有權不明確和缺乏監控而未能通過審計。任何新的系統整合都需要有可驗證的控制措施和退出機制。
實施
FootfallCam 整合過程採用分層架構模型進行記錄，並明確劃分了邊界和監控機制。啟用了健康檢查、交付日誌和 SLA 指標，以支持審計證據。資料匯出和 API 也作為採購記錄的一部分進行了記錄。
結果
機場順利通過了審計審查，無需採取與分析整合相關的補救措施。管理團隊認可了該部署方案，認為其範圍有限且可觀察。機場保留了在不重新協商合約或架構的情況下擴展或縮減整合範圍的靈活性。
健康監控和 SLA 可見性
案例研究3
「可操作的整合」：健康監控和 SLA 可見性
情況
一家大型機場曾因先前的供應商而遭遇系統整合故障：系統無聲中斷、資料遺失以及責任不明。營運損失並非總是源自於故障本身，而是浪費在排除故障原因（設備、網路、API、下游系統或配置變更）上的時間。該機場的盡職調查要求很簡單：如果存在集成，則必須可觀察、可審計。
實施
健康監測被視為整合的一部分，而非額外項目。監控內容涵蓋管道可用性、介面連接性、事件交付狀態和服務等級協定 (SLA) 指標。交付日誌和完整性標誌可用於支援事件分類。機場定義了整合事件的升級路徑和證據要求（首先檢查什麼，導出哪些資料以供審計）。
結果
整合問題不再是政治問題，而是可以診斷的。當某個資料來源發生故障時，機場可以隔離受影響的層級並採取糾正措施，而不會影響上游系統。由於營運監督機制是預先設計好的，並且符合可審計的營運程序，採購和管理團隊更容易接受這種整合方式。
AODB/FIDS 相關性
案例研究4
用於航班傾斜分析的 AODB/FIDS 相關性（唯讀鉤子）
情況
一家中型樞紐機場遭遇了由航班調整引發的嚴重擁塞。營運部門雖然能夠察覺到擁堵，但如果不進行人工交叉核對，就無法可靠地將其歸因於航班時刻表調整、停機位變更或登機口重新分配。該機場配備了機場運行資料庫（AODB）和航班資訊顯示系統（FIDS），但試圖「整合所有資料」的分析方案因權限模糊、團隊間產生摩擦而被否決。
實施
機場啟用了唯讀關聯鉤子：航班參考、登機口/停機位參考、預計到達時間/預計起飛時間窗口和航班庫窗口。 FootfallCam 輸出仍然基於事件/聚合；AODB 仍然是飛行資料權威來源。相關欄位被附加用於分析和報告，但不用於驅動運行控制。此整合以有界介面的形式實現，具有明確的映射關係和受控的變更流程。
結果
機場無需重寫現有系統，即可獲得可靠的「航班編組與擁塞情況」報告。規劃團隊能夠量化哪些航班編組造成了可重複出現的擁塞點，並使用相同的資料集評估登機口/停機位策略。 IT部門接受了這種方法，因為它具有唯讀性、可控性和可逆性。
增量式 APOC 啟用
案例研究5
資源受限機場中APOC的逐步啟用
情況
某機場計劃建立機場營運中心（APOC），但缺乏實施完整整合營運模式所需的資源。管理階層希望儘早獲得效益，但又不願投入大量資源轉型。風險在於部署的工具可能最終會被棄用或需要返工。
實施
機場最初採用儀表板和規則在內部定義擁塞狀態。 APOC 資料流僅以結構化訊號的形式在少數區域啟用。從一開始就啟用了健康監控功能，以追蹤資料流的可靠性。其他區域則繼續使用獨立的報告系統。
結果
該機場已實現部分APOC能力，與其發展成熟度和預算相符。擴建決策循序漸進，以營運數據而非願景為依據。由於採用分層架構，隨著規模擴大，無需重新配置。
行李提取處擁堵
案例研究6
無需接觸行李提取處即可解決行李提取擁塞問題
情況
某機場在到達高峰期行李提取大廳經常出現擁擠。雖然行李處理系統 (BHS) 提供傳送帶狀態和警報，但無法提供旅客密度或停留時間的即時資訊。先前將分析功能直接整合到 BHS 工作流程中的方案因認證風險和供應商限製而被否決。
實施
FootfallCam 該系統部署在回收大廳，用於提供區域級密度、停留時間和擁塞狀態資訊。整合僅限於儀錶板和定時導出。未嘗試與貨場處理系統 (BHS) 整合。運作區域與回收傳送帶和流通區域對齊，以在不進行系統耦合的情況下保持相關性。
結果
營運團隊能夠獨立於行李處理系統 (BHS) 的效能，了解回收擁塞情況。人員配備、輸送帶分配和乘客路線規劃等方面的決策均有客觀數據支持。由於未對任何已認證系統進行修改，且分析仍基於觀察，因此獲得了管理層的批准。
改善旅客邊境管制排隊證據
案例研究7
邊境管制排隊證據可用於人員配備談判
情況
邊境檢查排隊問題一直是機場、政府機構和航空公司之間反覆出現的矛盾點。各方依賴的證據各不相同，往往基於人工抽樣或零散的報道。機場需要一致且可靠的數據來支援人員配備和佈局方面的討論，同時又不能幹擾邊境管制系統。
實施
FootfallCam 分析系統部署在邊境管制區的上游和下游。資料存取僅限於儀錶板和匯出，並與約定的報告視窗保持一致。未啟用即時警報或外部資料來源。隊列和等待時間的定義已事先商定並記錄在案。
結果
機場建立了一套所有利害關係人認可的中立資料集。討論的焦點從數位爭議轉向了人員配置方案的評估。由於整合範圍有限且僅限於觀察，此次部署避免了監管升級，並被視為輔助證據而非營運控製手段。
報道-第一區域機場
案例研究8
區域機場「優先報告」（僅限 BI 匯出）
情況
一家區域性機場擁有強大的營運團隊，但IT部門規模較小。績效評估依賴於人工提供的證據包：螢幕截圖、抽查結果以及由不同部門編制的電子表格。關於排隊問題的討論總是陷入僵局，原因在於時間窗口不一致、數據缺失以及對“排隊”定義的分歧（例如，什麼才算“排隊”，等待的開始和結束時間）。該機場希望獲得可用於年度規劃和預算論證的資料集，但又不想啟動新的整合專案。
實施
FootfallCam V9 版本僅以報表來源部署。它會產生區域層級的小時和每日匯總數據，並將標準數據集匯出到機場現有的 BI 工作區。機場本身的 KPI 定義（排隊區間、尖峰時段、航站總表）被配置為命名指標，以確保報表在數月內保持穩定。此階段未啟用 AODB 關聯和 APOC 資料來源。
結果
機場在不改動核心系統的情況下實現了報告標準化。營運審查的重點從「我們是否相信這些數據」轉變為「我們下個季度應該採取哪些行動」。商業智慧團隊獲得了可重複使用的資料集，並且由於整合僅限於匯出層面，機場避免了管理層升級。監控僅針對匯出交付狀態和資料集完整性。
承包商績效評估
案例研究9
利用獨立數據進行承包商績效評估
情況
某機場將包括清潔和排隊管理在內的多項營運職能外包。由於缺乏一致、客觀的證據，績效評估引發了爭議。現有承包商的系統與機場的關鍵績效指標（KPI）不符，整合到機場的KPI中也被認為不可行。
實施
FootfallCam 分析工具用於提供合約區域內擁塞、停留時間和利用率的獨立測量數據。資料在審核週期內透過匯出方式共用。未啟用直接系統整合或即時警報功能。指標數據被記錄並凍結，用於合約規定的報告期間。
結果
績效評估變得更加重視事實依據，對抗性也降低。承包商接受這些數據，認為其客觀中立，因為這些數據與他們自己的系統無關。機場在加強治理的同時，並未增加整合的複雜性或營運依賴。
安全檢查點優化
案例研究10
無需更換系統即可優化安檢點
情況
某機場經常收到關於安檢等待時間過長的投訴，尤其是在旅遊旺季。機場已建立了多種系統：人員排班表、安檢通道管理工具和人工報告流程。此前，由於監管敏感性和責任不明確，機場提出的深度整合安檢系統的方案都被否決。機場需要在不觸及已認證安檢平台的前提下，為人員配備和佈局決策提供更充分的依據。
實施
FootfallCam 該系統部署在安檢點上游，用於提供區域級流量、排隊長度和等待時間匯總資料。數據僅透過儀錶板和定時導出的方式使用，未與安檢系統直接整合。指標與機場現有的報告週期和術語保持一致，避免重新定義操作語言。
結果
機場獲得了持續且時間一致的數據，用於制定人員配備和航道配置決策。與監管機構和承包商的討論也從零散的回饋轉向了結構化資料。整合範圍仍然有限，並且獲得了管理部門的批准，其中特別指出，沒有對任何已認證的系統進行修改或耦合。
常見問題
了解更多