Kleiner Einzelhändler
FootfallCam V9 Die Architektur ist mehrschichtig aufgebaut, sodass Flughäfen Integrationsfunktionen flexibel einführen, betreiben und erweitern können, ohne sich auf einen einzigen Integrationspfad festlegen zu müssen. Jede Schicht bietet klare Ein- und Ausgaben und kann unabhängig oder in Kombination mit anderen verwendet werden. Flughäfen können so mit einfachem Datenzugriff und Berichtswesen beginnen und die Integration erst bei Bedarf vertiefen.
FootfallCam V9 Unterstützt mehrere Integrationsschnittstellen, die die mehrschichtige Architektur mit bestehenden Flughafensystemen verbinden. Diese Schnittstellen veranschaulichen, wie Betriebsdaten ausgetauscht werden können, ohne bestehende Plattformen zu ersetzen oder zu beeinträchtigen. Gängige Integrationsbeispiele sind:
Flugreferenz
Tor- und Standbezug
ETA / ETD Fenster
Flugbankgruppierung
Stauzustände
Indikatoren für Schwellenwertüberschreitung
Prognostizierter Betriebsdruck
Benachrichtigungen
Dies sind beispielhafte Darstellungen und keine vollständige Liste. Dieselbe Architektur unterstützt auch andere Schnittstellen, darunter BI-Plattformen, Berichtssysteme und operative Tools von Drittanbietern.
FootfallCam Ermöglicht Flughäfen die Kontrolle sowohl über die Messebene als auch über die operative Auswertungsebene. Ein standardisierter, modularer Ansatz zur Verknüpfung von Passagierflussdaten mit Flughafensystemen, Displays und mobilen Anwendungen.
Whitepaper zum Datenaustausch-Controller
Die Zustandsüberwachung umfasst den Betrieb der Integration selbst. Sie bietet Einblick in die Frage, ob Datenpipelines, Schnittstellen und die Zustellung von Warnmeldungen über alle aktivierten Integrationsschichten hinweg wie konfiguriert funktionieren.
Die Überwachung umfasst:
Die Gesundheitsüberwachung unterstützt den Routinebetrieb, die Fehlerisolierung und die Überprüfung, ohne vorgelagerte Flughafensysteme zu beeinträchtigen.
Fallstudie
Fallstudie 1
Für ein Terminalerweiterungsprojekt war die Zustimmung mehrerer Interessengruppen erforderlich, darunter Fluggesellschaften, Aufsichtsbehörden und Investoren. Alle Beteiligten hinterfragten Annahmen zum zukünftigen Passagieraufkommen und zur möglichen Überlastung. Der Flughafen benötigte Daten, um sein Vorhaben zu untermauern, ohne sich vor der Finanzierungszusage auf eine langfristige Integration von Analysetools festzulegen.
FootfallCam Es wurde als temporäre Analyseebene eingesetzt, um Basis- und prognostizierte Abläufe zu erfassen. Der Datenzugriff erfolgte ausschließlich über Dashboards und Exporte. Integrationsumfang und Aufbewahrungsdauer waren explizit zeitlich begrenzt. Die Zustandsüberwachung wurde aktiviert, um die Vollständigkeit der Daten für die Prüfung sicherzustellen.
Der Flughafen lieferte überzeugende Belege zur Untermauerung der Expansionsannahmen. Die Beteiligten akzeptierten die Ergebnisse, da der Einsatz der Analysesoftware begrenzt, transparent und reversibel war. Nach Erhalt der Genehmigungen behielt der Flughafen die Option, die Analysesoftware ohne Nachbearbeitung zu erweitern oder zu entfernen.
Fallstudie 2
Ein öffentlicher Flughafen unterzog sich regelmäßigen Audits mit Fokus auf Daten-Governance, Abhängigkeit von externen Dienstleistern und operative Verantwortlichkeit. Frühere Integrationen waren aufgrund unklarer Datenhoheit und mangelnder Überwachung bei den Audits gescheitert. Jede neue Integration erforderte nachweisbare Kontrollmechanismen und Ausstiegsoptionen.
FootfallCam Die Integration wurde mithilfe eines mehrschichtigen Architekturmodells mit expliziten Grenzen und Überwachungsmechanismen dokumentiert. Systemprüfungen, Lieferprotokolle und SLA-Indikatoren wurden aktiviert, um die Nachweisführung im Audit zu unterstützen. Datenexporte und APIs wurden als Teil der Beschaffungsdokumentation erfasst.
Der Flughafen hat die Prüfung ohne Mängel im Zusammenhang mit der Integration von Analysetools bestanden. Die zuständigen Gremien haben die Implementierung als abgeschlossen und nachvollziehbar akzeptiert. Der Flughafen behält die Flexibilität, den Integrationsumfang ohne vertragliche oder architektonische Neuverhandlungen zu erweitern oder zu reduzieren.
Fallstudie 3
Ein großer Flughafen hatte mit früheren Anbietern Integrationsprobleme: unbemerkte Ausfälle, fehlende Daten und unklare Verantwortlichkeiten. Die betrieblichen Auswirkungen bestanden nicht immer im Ausfall selbst, sondern in der Zeit, die für die Fehlersuche (Gerät, Netzwerk, API, nachgelagertes System oder Konfigurationsänderung) verloren ging. Die Sorgfaltspflicht des Flughafens war daher eindeutig: Besteht eine Integration, muss diese nachvollziehbar und auditierbar sein.
Die Systemüberwachung wurde als integraler Bestandteil der Integration und nicht als Zusatzfunktion betrachtet. Sie umfasste die Verfügbarkeit der Pipeline, die Schnittstellenkonnektivität, den Status der Ereignisübermittlung und SLA-Indikatoren. Übermittlungsprotokolle und Vollständigkeitskennzeichnungen wurden zur Unterstützung der Priorisierung von Vorfällen bereitgestellt. Der Flughafen definierte Eskalationswege und Nachweisanforderungen für Integrationsvorfälle (was zuerst zu prüfen ist, was für die Prüfung exportiert werden muss).
Integrationsprobleme wurden diagnostizierbar statt politisch. Bei einer Beeinträchtigung der Datenversorgung konnte der Flughafen die betroffene Ebene isolieren und Korrekturmaßnahmen ergreifen, ohne vorgelagerte Systeme zu stören. Beschaffungs- und Verwaltungsteams akzeptierten die Integration bereitwilliger, da die operative Aufsicht von vornherein vorgesehen war und mit den revisionssicheren Betriebsabläufen übereinstimmte.
Fallstudie 4
Ein mittelgroßer Flughafen erlebte aufgrund von Flugclustern starke Stauwellen. Der Betrieb konnte zwar Staus feststellen, diese aber ohne manuelle Überprüfung nicht zuverlässig Flugplanänderungen, Standplatzverlegungen oder Gate-Umstrukturierungen zuordnen. Der Flughafen verfügte über ein automatisches Anzeigesystem (AODB) und ein Fluginformationssystem (FIDS), doch die Analyseinitiativen, die versuchten, alle Systeme zu integrieren, wurden abgelehnt, da sie Zuständigkeiten verwischten und zu internen Spannungen zwischen den Teams führten.
Der Flughafen ermöglichte schreibgeschützte Korrelations-Hooks: Flugreferenz, Gate-/Standplatzreferenz, ETA/ETD-Fenster und Flugbankfenster. FootfallCam Die Ausgaben blieben ereignis-/aggregatbasiert; AODB blieb die maßgebliche Datenquelle für Flugdaten. Korrelierte Felder wurden für Analyse- und Berichtszwecke hinzugefügt, jedoch nicht zur Steuerung des operativen Betriebs verwendet. Die Integration wurde als abgegrenzte Schnittstelle mit definiertem Mapping und kontrolliertem Änderungsprozess implementiert.
Der Flughafen erhielt eine nachvollziehbare Berichterstattung über Flugströme und deren Auswirkungen, ohne bestehende Systeme umschreiben zu müssen. Planungsteams konnten quantifizieren, welche Flugströme wiederkehrende Engpässe verursachten, und die Gate-/Standplatzrichtlinien anhand derselben Datensätze evaluieren. Die IT-Abteilung akzeptierte den Ansatz, da er schreibgeschützt, begrenzt und reversibel war.
Fallstudie 5
Ein Flughafen plante die Einrichtung eines APOC-Bereichs, verfügte jedoch nicht über die Ressourcen für die Implementierung eines vollständig integrierten Betriebsmodells. Die Führungsebene wünschte sich frühzeitige Vorteile, ohne sich auf ein umfangreiches Transformationsprogramm festzulegen. Das Risiko bestand darin, Tools einzusetzen, die später verworfen oder überarbeitet werden müssten.
Der Flughafen begann mit Dashboards und Regeln zur internen Definition von Auslastungszuständen. APOC-Feeds wurden zunächst nur für wenige Zonen als strukturierte Signale aktiviert. Die Überwachung der Feed-Zuverlässigkeit war von Anfang an integriert. Andere Bereiche nutzten weiterhin eigenständige Berichtssysteme.
Der Flughafen erreichte eine teilweise APOC-Fähigkeit, die seinem Entwicklungsstand und Budget entsprach. Erweiterungsentscheidungen wurden schrittweise auf Basis von Betriebserfahrung und nicht von bloßen Zielsetzungen getroffen. Dank der mehrschichtigen Architektur war bei zunehmendem Umfang keine Rekonfiguration erforderlich.
Fallstudie 6
Ein Flughafen verzeichnete während der Ankunftsspitzen wiederholt Engpässe in den Gepäckausgabehallen. Das Gepäckabfertigungssystem (BHS) lieferte zwar Informationen zum Bandstatus und gab Alarme aus, bot aber keine Einblicke in die Passagierdichte oder die Verweildauer. Frühere Vorschläge zur direkten Integration von Analysetools in die BHS-Workflows wurden aufgrund von Zertifizierungsrisiken und Einschränkungen seitens der Anbieter abgelehnt.
FootfallCam Das System wurde in den Rückgewinnungshallen eingesetzt, um Zonendichte, Verweildauer und Auslastungszustände zu erfassen. Die Integration beschränkte sich auf Dashboards und geplante Exporte. Eine Integration in das Gepäckfördersystem wurde nicht angestrebt. Die Betriebszonen wurden an den Rückgewinnungsbändern und Verkehrsflächen ausgerichtet, um die Relevanz ohne Systemkopplung zu gewährleisten.
Die Betriebsteams erhielten Einblick in die Rückholkapazitäten unabhängig von der Leistung des Gepäckfördersystems. Entscheidungen bezüglich Personaleinsatz, Bandzuweisung und Passagierführung wurden durch objektive Daten unterstützt. Die Zustimmung der Aufsichtsbehörden wurde erteilt, da keine zertifizierten Systeme verändert wurden und die Analysen rein beobachtend blieben.
Fallstudie 7
Die Warteschlangen an den Grenzkontrollen stellten einen wiederkehrenden Konfliktpunkt zwischen Flughafen, Behörden und Fluggesellschaften dar. Jede Partei stützte sich auf unterschiedliche Daten, oft basierend auf manuellen Stichproben oder anekdotischen Berichten. Der Flughafen benötigte konsistente und nachvollziehbare Daten, um die Diskussionen über Personalplanung und -gestaltung zu untermauern, ohne die Grenzkontrollsysteme zu beeinträchtigen.
FootfallCam Analysen wurden vor und nach den Grenzkontrollzonen eingesetzt. Der Datenzugriff beschränkte sich auf Dashboards und Exporte, abgestimmt auf vereinbarte Berichtszeiträume. Echtzeitwarnungen oder externe Datenfeeds wurden nicht aktiviert. Definitionen von Warteschlangen und Wartezeiten wurden im Vorfeld festgelegt und dokumentiert.
Der Flughafen erstellte einen neutralen Datensatz, der von allen Beteiligten akzeptiert wurde. Die Diskussionen verlagerten sich von strittigen Zahlen hin zur Bewertung verschiedener Personalszenarien. Da der Integrationsumfang begrenzt und beobachtend war, vermied die Maßnahme eine Eskalation durch die Regulierungsbehörden und wurde als Beleg und nicht als operative Kontrollmaßnahme akzeptiert.
Fallstudie 8
Ein Regionalflughafen verfügte über leistungsstarke operative Teams, aber eine kleine IT-Abteilung. Leistungsbeurteilungen basierten auf manuell erstellten Nachweisen: Screenshots, Stichproben und Tabellenkalkulationen verschiedener Abteilungen. Diskussionen über Warteschlangen scheiterten immer wieder an einem Problem: uneinheitliche Zeitfenster, fehlende Stunden und Uneinigkeiten über Definitionen (was als „Warteschlange“ gilt, wann eine Wartezeit beginnt/endet). Der Flughafen benötigte nutzbare Datensätze für die Jahresplanung und Budgetverteidigung, ohne ein neues Integrationsprojekt zu starten.
FootfallCam Die Software wurde ausschließlich als Berichtsquelle eingesetzt. Version 9 erstellte stündliche und tägliche Aggregatwerte auf Zonenebene und exportierte einen Standarddatensatz in den bestehenden BI-Arbeitsbereich des Flughafens. Die flughafeneigenen KPI-Definitionen (Warteschlangenbereiche, Spitzenzeiten, Terminal-Aggregationen) wurden als benannte Metriken konfiguriert, um eine monatsübergreifende Stabilität der Berichterstattung zu gewährleisten. Zu diesem Zeitpunkt waren weder AODB-Korrelationen noch APOC-Feeds aktiviert.
Der Flughafen standardisierte das Berichtswesen, ohne die Kernsysteme zu verändern. Die Überprüfung des Betriebsablaufs verlagerte sich von der Frage „Vertrauen wir den Zahlen?“ hin zu „Welche Maßnahmen ergreifen wir im nächsten Quartal?“. Das BI-Team erhielt reproduzierbare Datensätze, und der Flughafen vermied eine Eskalation im Governance-Bereich, da die Integration auf Exportebene blieb. Die Überwachung beschränkte sich auf den Exportstatus und die Vollständigkeit der Datensätze.
Fallstudie 9
Ein Flughafen lagerte mehrere operative Funktionen aus, darunter Reinigung und Warteschlangenmanagement. Die Leistungsbeurteilungen waren aufgrund fehlender konsistenter und objektiver Nachweise umstritten. Die bestehenden Systeme der Auftragnehmer entsprachen nicht den KPIs des Flughafens, und eine Integration wurde als nicht praktikabel erachtet.
FootfallCam Mithilfe von Analysen wurden unabhängige Messungen von Auslastung, Verweildauer und Nutzung in den Vertragsgebieten durchgeführt. Die Daten wurden im Rahmen der Überprüfungszyklen exportiert und ausgetauscht. Eine direkte Systemintegration oder Echtzeitwarnungen wurden nicht aktiviert. Die Kennzahlen wurden dokumentiert und für die vertraglichen Berichtszeiträume eingefroren.
Die Leistungsbeurteilungen wurden faktenbasiert und weniger konfrontativ. Die Auftragnehmer akzeptierten die Daten als neutral, da sie nicht an ihre eigenen Systeme gebunden waren. Der Flughafen stärkte seine Governance, ohne die Integrationskomplexität oder die operative Abhängigkeit zu erhöhen.
Fallstudie 10
Ein Flughafen sah sich wiederholt mit Beschwerden über lange Wartezeiten an der Sicherheitskontrolle konfrontiert, insbesondere während der saisonalen Spitzenzeiten. Mehrere Systeme waren bereits im Einsatz: Personalpläne, Tools zur Steuerung der Sicherheitsspuren und manuelle Meldeverfahren. Frühere Vorschläge zur tiefen Integration in die bestehenden Sicherheitssysteme wurden aufgrund regulatorischer Sensibilität und unklarer Verantwortlichkeiten abgelehnt. Der Flughafen benötigte eine fundiertere Entscheidungsgrundlage für Personal- und Layoutentscheidungen, ohne dabei auf zertifizierte Sicherheitsplattformen zurückzugreifen.
FootfallCam Das System wurde vor den Sicherheitskontrollpunkten eingesetzt, um zonenbezogene Daten zu Passagierfluss, Warteschlangenlänge und Wartezeiten zu erfassen. Die Daten wurden ausschließlich über Dashboards und geplante Exporte genutzt. Eine direkte Integration mit den Sicherheitssystemen erfolgte nicht. Die Kennzahlen wurden an die bestehenden Berichtszeiträume und die Terminologie des Flughafens angepasst, um eine Änderung der betrieblichen Terminologie zu vermeiden.
Der Flughafen erhielt konsistente und zeitlich abgestimmte Daten für Personal- und Spurkonfigurationsentscheidungen. Die Gespräche mit Aufsichtsbehörden und Auftragnehmern verlagerten sich von anekdotischen Rückmeldungen hin zu strukturierten Daten. Der Integrationsumfang blieb begrenzt, und die Zustimmung der zuständigen Behörden wurde unter der Voraussetzung erteilt, dass keine zertifizierten Systeme modifiziert oder miteinander verknüpft wurden.
Häufig gestellte Fragen
Mehr erfahren