A Smart Digital Platform for Airport ServicesImproving Passenger Satisfaction

Sonke Knoch, Philipp StaudtGerman Research Center for Artificial Intelligence (DFKI)

Campus D3.2, 66123 Saarbrucken, Germany

Bruno Puzzolante, Andrea MaggiCefriel - Politecnico di Milano

Viale Sarca 226, 20126 Milano, Italy

Abstract—Airport management companies are facing increas-ing passenger numbers and the pressure to provide high-qualityground services to satisfy the passengers’ needs and expectations.A new kind of information system is required, monitoringpassenger figures in real time to estimate the time and locationwhen and where a service must be provided and responsiblestaff scheduled. We suggest an event processing platform whichis built upon an industry-proven technology and aggregatesstreams of information about passenger frequency occurring inheterogeneous formats and with different frequencies to a keyperformance indicator reflecting the current state of selectedareas at the airport. Following the design research principle, weconducted a requirements analysis and developed a prototypicalsystem which efficiently fuses the data streams and generatesalerts to notify staff if passenger satisfaction threatens to drop.The system was evaluated with historical data from one of the20 largest airports in Europe. The evaluation is based on asimulation and provides evidence that the system has the potentialto improve customer satisfaction. In addition, due to the event-based architecture, a generic API allows a smooth integrationof new data sources, the parametrization of the event rulesaggregating and processing all data, and thus, an intuitive usageby the airport operator. The final tool consists of the eventprocessing module and a dashboard supporting airport managersin keeping track of the important quality attribute passengersatisfaction and scheduling staff in the right spot at the righttime.

I. INTRODUCTION

Today, the airport is a complex, multi-functional travel cen-

tre offering a wide range of services. It is a broad ecosystem

of different business units: commercial aviation, non-aviation

and operations. Each of them is aiming to reach its goals

of increasing revenues, optimizing resources, reducing costs,

and increasing the passenger satisfaction. Across the globe,

passengers are demanding higher levels of service, and the

competition among airports aims to increase the passenger

satisfaction in order to be able to attract more and more airline

companies; see for instance [1].

Airports themselves usually compare through global bench-

marking approaches, like the industry group airport councils

international’s (ACI) airport service quality (ASQ) program

which measures passengers’ satisfaction while they are travel-

ling through an airport. This type of benchmark gives each

airport a ranking with respect to competitors, highlighting

which areas are to be improved. According to a recent report

of the ACI on Airport Service Quality, airport cleanliness

(especially in restrooms) recently had the greatest effect on

travelers’ airport ratings [2], [3].

In this context, Smart DPA addresses the restroom use case

by providing an event-driven architecture integrating available

systems already available at the airport, including solutions for

queue monitoring, boarding pass scans and air quality sensors.

It is shown that a dynamic scheduling of cleaning operations

based on a KPI aggregating streaming data increases the

customers’ satisfaction compared to static schedules.

We conducted a requirements analysis at one of Europe’s

20 largest airports and developed a rule-based event process-

ing system. The system fuses heterogeneous data streams

efficiently since it is based on the industry-proven event

processing engine Apache Flink [4]. Events are mapped to

a KPI reflecting the passenger satisfaction. Based on this KPI,

alerts and forecasts are generated when restroom cleaning

becomes or probably will become necessary. A Web-based

dashboard visualizes all data and allows fast reactions to

unforeseen events, such as a sudden drop in satisfaction. The

system was evaluated based on historical data from the airport.

Due to organizational changes, a deployment at the airport was

not possible before the time of paper submission.

The paper starts with a discussion of related work including

scientific papers and commercial solutions in Section II. In

Section III, the requirements elicitation and the use case are

described. The concept for Smart DPA is presented in Section

IV and followed by the implementation in Section V. In

Section VI, the analysis of historical data and the evaluation of

the proposed system based on simulated passenger feedback

illustrates a potential improvement of passenger satisfaction.

The paper concludes in Section VII.

II. RELATED WORK

Related work is divided into scientific papers and commer-

cial solutions. Papers include similar approaches addressing

complex event processing and decision support, or analyze the

need for performance measurement and service improvement

at the airport. Commercial vendors provide solutions for

specific problems such as queue management, passenger flow

and restroom monitoring.

A. Scientific Work

Bezerra and Gomes [5] provide an overview about literature

in the field of performance measurement at the airport. 380

250

2020 IEEE 22nd Conference on Business Informatics (CBI)

2378-1971/20/$31.00 ©2020 IEEEDOI 10.1109/CBI49978.2020.00034

documents were analyzed, dating between 1970 and 2015.

Three stages were identified illustrating the evolution of the

airport business from predominantly government ownership, to

privatization and deregulation, to a complex business model

with diverse services for customers and stakeholders. The

authors conclude that benchmarking of performance improve-

ment at the airport should address the identification of or-

ganizational practices which lead to high performance and

service quality, such as the antecedents and consequences of

passengers’ satisfaction. Smart DPA was conceptualized to

satisfy exactly this requirement.

For the improvement of operational performance in an

organization, a helpful tool to handle big data and derive

conclusions in real time provides complex event processing

(CEP). One explanation is provided by Lundberg [6], who

argues that business operations typically consist of micro-

events which may be produced with high frequency from a

heterogeneous IT environment. Such events can be handled

efficiently by an event-driven architecture where a CEP en-

gine aggregates and combines such events and allows for a

mapping to key performance indicators (KPIs) reflecting the

effects on revenue, cost, and risk. The Smart DPA Restroom

Passenger Satisfaction Index (PSI) is such a KPI which is

related to the cleaning services at the airport and influenced by

several micro-events, e.g. from security control and passenger

feedback buttons.

Already in 2002, Boyer et al. [7] published a patent targeting

the event driven airport. They describe a system which notifies

entities of events and includes a source system tracking

changes in travel schedules, a publish-subscribe communi-

cation, and a receiving system notifying other applications.

Stanford’s David Luckham, known as the originator of CEP,

states in his book that the airport industry and transportation

sector was an early adopter of the event processing technology

and describes a baggage system checking transport times,

passenger connection times and flight gate assignments [8,

p. 66–67]. Both the patent and the example from Luckham’s

book also aim for service improvements and provide solutions

for specific problems such as changes in the travel schedule

and in-time baggage delivery. Similarly, Smart DPA addresses

the specific problem of scheduling cleaning activities and in

parallel aims to provide a more general and extensible solution.

In [9] Pestana et al. propose a decision support system

(DSS) with an event-driven architecture integrating multiple

sensor technologies to provide a comprehensive picture of

ground operations. The architecture is organized in different

layers and includes alerts, business rules, and map and KPI

views. The work is use case-driven and lacks an evaluation,

but a field trial was planned at the Faro airport. Smart

DPA provides a similar concept, but recent developments in

event processing, data handling and Web-based user interfaces

allowed us to provide a leaner, more flexible and scalable

architecture.

Zografos et al. [10] describe a decision-oriented modeling

framework of a DSS for the management and planning of air-

port operations. A classification into airside and landside types

of analysis and a procedure to develop a DSS are presented.

Finally, a use case focusing on capacity management and the

configurable presentation of flight data (arrivals, departures,

delays, traffic, queue length etc.) is illustrated and was built on

industry tools to foster acceptance. The approach was tested at

four European airports. The work provides interesting concepts

and focusses more on DSS. The Smart DPA system could be

combined with the suggested control mechanisms and improve

decisions at run-time.

The study by Hong et al. [1] investigates appropriate at-

tributes to measure user satisfaction at the airport. The study

was conducted using a questionnaire and showed that inter-

actional (self-service, interpersonal services, remote), physical

environment (e.g. seating arrangements, size, cleanliness), and

outcome (e.g. time delays and crowding) service quality are

supported for the passenger terminal, exemplified at the In-

cheon International Airport. The result supports the conclusion

that high service quality is a key factor for service providers to

achieve an outstanding position in the marketplace, but at the

same time is difficult to measure. Smart DPA aims to provide

a solution for this challenge.

B. Commercial Solutions

An increasing number of airports are looking for an easy so-

lution to improve passenger satisfaction. Most of the solutions

on the market are essentially vertical systems addressing the

core-business activities of the airport, such as the monitoring

of queues at security and passport control, or the estimation of

passenger flows. In this category there are solutions working

with proprietary sensors (e.g. Xovis [11], I-Sense [12]), solu-

tions able to integrate multiple sources like Wi-Fi and boarding

pass scans (e.g. SITA Queue management [13], Smart Flows

[14]) and general-purpose solutions applied to the airport and

with a specific application for passenger flow monitoring (e.g.

TIBCO [15]) leveraging the integration of multiple sources

such as ad-hoc cameras and Wi-Fi.

Recently, new solutions focusing on the monitoring of

restroom usage have also been launched on the market. These

solutions use a set of deployed ad-hoc technologies such

as counting passengers entering and exiting the restrooms

(e.g. Infax SmartRestroom [16]), smart latches and lights

(e.g. Tooshlights [17]), and a digital touchscreen monitor

(e.g. Restroomapp [18], Saniori [19]) for staff checklists and

passengers’ feedback.

All these solutions monitor the restrooms’ usage using

ad-hoc deployed devices, without providing any additional

insight. On the other hand, the Smart DPA solution integrates

with systems already deployed in the airport (through APIs)

and provides insights for the optimization of staff coordination

and for a better passenger satisfaction.

III. REQUIREMENTS ENGINEERING

The airport departments of IT, Customer Care and Opera-

tions, at one of the 20 largest airports in Europe, were con-

sulted to collect information on the passengers’ satisfaction,

inputs for the definition of the use case, and details about

251

Fig. 1: Landside check-in and airside departure areas.

solutions deployed or to be deployed in the near future that

would deliver relevant data. For this, interviews with the air-

port’s stakeholders, passenger surveys, and an analysis of the

data collected from existing airport systems were conducted. In

addition, a one-day workshop on the passenger experience was

held with more than twenty people from different departments

of the airport. The aim was to identify passengers’ “pains

and gains” and to work on the ideation of new services for

improving the passenger experience.

As a result, it was confirmed that a passenger’s time in

queue and the level of cleanliness of the restrooms are the

two main indicators that are affecting passengers’ satisfaction.

From an operational point of view, it was determined that

the management of staff in accordance with the status of the

services, i.e. the restroom cleanliness and queue at security

control, is one of the main challenges for airport managers.

As confirmed by the competition analysis in related work, the

queue management at security and passport control is widely

covered by market solutions, which lead the focus on the staff

management.

During the discussions the idea was made concrete to design

a solution able to (1) improve restroom quality service for

the passengers, (2) predict the status of the restrooms, and

(3) proactively provide information to the cleaning staff to

maintain a high level of cleanliness in all the restrooms. This

led to the following use case which forms the basis for the

evaluation. The data sources Smart DPA relies on, such as

the functional and architectural requirements, are described in

Sections III-B, III-C, and III-D.

A. Use Case

Different restroom types have been identified depending on

where the restroom is located with respect to the surrounding

area. Public airports are divided into landside and airside areas.

The landside area is open to everyone, while access to the

airside area is tightly controlled. The airside area includes

all parts of the airport around the aircraft, and the parts of

the buildings that are only accessible to passengers and staff.

Passengers and staff must be checked by security before being

permitted to enter the airside area. Conversely, passengers

arriving from an international flight (Extra-Schengen in the

case of EU airports) must pass through border control and

customs to access the landside area, where they can exit the

airport.

For the following conception, we will focus on the departure

area of an airport with segregated departure and arrival areas.

Figure 1 provides an overview of this area and divides the

restrooms into four possible types for departures, namely

landside, airside, Schengen flights and Extra-Schengen flights.

B. Data Sources

The available data sources at the airport were checked and

analyzed, which led to the following types of solutions being

identified to support the staff in the management of cleaning

services:

1) Boarding pass scanning: real-time but also statistical data

on the passengers entering the security control area.

2) Queue management: solution to estimate waiting time and

count the number of passengers passing through the metal

detectors at security control.

3) Passenger forecasting: numbers of passengers who are

departing and landing in coming hours and are to be

expected at the security gates.

4) Passenger feedback button: solution to monitor passenger

satisfaction at every touch point using a “smiles terminal”

ranging from sad to happy and providing the feedback in

the form of good, average, or bad ratings.

5) Restroom air quality monitoring: measures the air quality

in the restroom using odor sensors.

6) Restroom cleaning service monitoring: solution used to

certify the start and end of a restroom cleaning task

performed by the staff. It is usually done through a RFID

tag located in the restroom that cleaning staff scans when

they start and end a cleaning task.

C. Functional Requirements

During requirements elicitation it had become clear that

a KPI is needed to monitor service performance and to

indicate required actions if the performance has decreased or

will decrease: the location-based passenger satisfaction index(PSI). The following capabilities were identified:

• Provide an overview of the overall cleaning status of the

restrooms monitored

• Provide clear indications of the restroom blocks with the

lowest PSI

252

Fig. 2: Plot and trend of the passenger satisfaction index (PSI).

• Visualize on a map the overall cleaning status of the

restrooms monitored

This means for each location monitored:

• Visualize the PSI KPI (updated at least every 15 minutes)

• Visualize information about the last time a cleaning

activity has been performed

• Send automatic alerts to recommend a cleaning activity

• Provide an estimation of the next cleaning time

• Provide access through APIs to KPI and alerts

• Visualize the trend of PSI KPI (15-minute granularity)

• Visualize the historical data of recorded events

D. Architectural Requirements

To deploy the solution, additional static data is required,

such as a list of all restrooms at the airport with information

about location, type, and size. In addition, real-time events

about the restroom cleaning activities are necessary to reset

the PSI to 100% per restroom; see Section IV-A.

In a similar way, the system needs up-to-date information

about the passenger feedback rating per restroom, and the

number of passengers passing through metal detectors and

scanning their boarding pass at the security check as described

in Section III-B. The passenger satisfaction thereby will be

monitored, and rough information about the number of people

at the security check is known. In addition, a forecast about the

expected number of passengers departing in the coming hours

can be used. Finally, the air quality sensor delivers detailed

data with high frequency. To integrate all these various data

sources, the system needs to provide an API that allows the

ingestion of that kind of data.

IV. CONCEPT

Based on the requirements analysis which led to the func-

tional, architectural, and API requirements presented in the

previous section, a KPI was defined and is described in Section

IV-A. The required architecture is described in Section IV-B

enabling the event processing engine handling real-time and

historical events to automatically find patterns in the event

streams, as described in Section IV-C.

A. Key Performance Indicator

It is the goal of the Smart DPA platform to generate an easy-

to-understand indicator which represents the current customer

satisfaction at a certain location. Therefore, we introduce the

passenger satisfaction index (PSI), a value between 0 and

100%. It can be plotted as a time series and allows the

recommendation of actions in the future following a trend

estimation. Figure 2 shows a graph plotting this index. At

initialization, the plot always starts with 100% per restroom.

Two factors were identified during requirements engineering

as decreasing factors for this index: (1) information from data

sources, such as air quality monitoring and passenger feedback

buttons, will be aggregated to a weighted score decreasing the

current index; (2) a standard decreasing slope is introduced

reflecting the assumption that satisfaction decreases over time

if no actions are performed. This decreasing factor can be

configured and set differently for day and night. If an action

(i.e. a cleaning task) occurs, the index is reset to 100%.

The importance of predicting the next process event for

run-time management in order to identify processes at risk

has been discussed by [20], which introduced the use of

deep learning for predicting process behavior. In our case,

the recommendation of actions in the future assumes that the

threshold when the PSI reaches a critical point is known. In

Figure 2 the intersection between the index plot and a defined

cleaning threshold depicts this point. Computing the trend of

the index at an index position above the threshold allows the

forecast of the next action estimating a future intersection.

Those forecasts for different locations can be used to optimize

the action scheduling, i.e. cleaning tasks. Nevertheless, if the

index crosses the threshold line—the forecast was ignored or

false—an alert is generated warning the operator that a critical

point was reached. A second, lower cleaning threshold allows

a separation between the threshold used for trend estimation

and the threshold used for alerts.

B. Architecture

Figure 3 shows the high-level architecture for Smart DPA.

The API ingestion provides the interface to the airport systems

and the entry point to the event processing module used by

external systems. Event data ingested via the API is pre-

processed and forwarded to the event processing module. In

addition, selected data sets are written to the database for later

visualization in the web application. Two different usages of

the API are relevant in the Smart DPA use case: (1) real-time

data ingestion of live data exposed by the Airport Systems to

receive and process real-time events; and (2) historical data

from static files, such as CSV and XLSX, recorded by the

airport systems and streamed to simulate real-time events.

The latter data ingestion was used to evaluate the system as

described in Section VI.

The core of the solution is the event processing module that

contains the following three components: the event processingengine, event sources and sinks. The event processing engineis responsible for the processing of real-time and historical

events. It is used to efficiently aggregate data and to automati-

cally find patterns in the event streams. If necessary, streaming

data is enhanced with additional information, e.g. information

about the passenger’s destination. The results of the engine are

the PSI KPI, complex cleaning alerts and a forecast about the

next cleaning. Details about the event rules and algorithms are

provided in Section V-A. Event sources are used to ingest data

253

real-time stream-data ingestion via API

historical data ingestion via API (CSV

and XLSX)

airport systems Smart DPA platform

pub/subsink

DBsink

eventbroker

DB

publishsubscribe

event processing module

web application

back-end front-end

DB

API

inge

stio

n

…eventsource

data enhancement

writeread

event processing engine

airport management

Fig. 3: Design of the Smart DPA event-based architecture.

into the event processing engine. Sinks are used to stream or

persist processed data and are subdivided into pub/sub sinkswhich publish processed data to the event broker to provide it

to appropriate subscribers (e.g. the live monitoring dashboard),

and DB sinks which store data to a database for monitoring

and analytics applications.

Regarding the data storage and publishing to the web

application, the following components are used: The databaseon the right of Figure 3 stores all the data collected and

generated by the event processing engine. The database on

the left (inside the event process module) provides additional

information that is correlated to the data from sources during

event processing. The event broker is responsible for distribut-

ing messages to its clients. It is the handler of communication

between publishers and subscribers. The web application is

the end-user application showing the Smart DPA KPIs. The

web application consists of a back- and front-end. The back-

end acts as middleware between the front-end on one side

and the database and the event broker on the other. By

exposing a series of APIs, it deals with login authentication

and provides the list of restrooms with the KPIs’ actual values,

KPIs’ historical data and the history of restroom passenger

satisfaction.

C. Event Processing

The event processing engine must handle heterogeneous

data streams which occur with different frequencies. The

following will describe how these streams are fused and

aggregated to one single index, the PSI KPI. For example,

passenger feedback occurs at creation time, while the air

quality sensor delivers a measurement every ten seconds. The

content of the two messages is totally different. Figure 4 shows

how data streams from different sources (1 to N), with different

content (ty1 to tyN ), and in a different frequency (indicated by

the dotted line of the arrows) are aggregated to an individual

score, respectively. Such a score computation is common

when ranking an item, as for example suggested by [21] for

a running route recommendation system in the health and

fitness domain balancing between different route properties

such as length, slope, and location which are available offline.

Transferred to the event processing domain, where streams of

data need to be handled online, such a score is restricted to a

specific time window as follows.

A score is a numerical value between zero and one. All

scores are computed with the same frequency. The frequency

is defined by the user and defines the time in which events

from the respective source are aggregated. Each score has an

individual formula which defines the score computation. All

scores are aggregated by calculating the weighted mean. A

default decreasing slope, set by the user, specifies the decrease

per hour, since it is assumed that the cleanliness decreases over

time. Thus, the index always decreases with one exception,

which occurs when the restroom was cleaned, as indicated by

an event from data source 6 in Section III-B. In this case, the

index is immediately reset to 100%. The resulting cleanliness

index is used internally and further processed to generate alert

streams, predictions, and the final PSI output stream.

In total, four score streams are generated. The PSI streamrepresents the final PSI and is continuously streamed to the

event broker and persisted to the database. The cleaning alertstream delivers data if and as long as the cleanliness index

lies under a user defined threshold. In the same way, the lowcleaning alert stream delivers data if the cleanliness index lies

under a second user defined threshold. Finally, the predictionstream continuously streams the predicted time when the

index will probably drop under the threshold indicating the

next cleaning time based on the index trend. All streams are

repeated in a frequency defined by the user.

The internal cleanliness index used in these output streams

is based on the following scores related to the data sources

listed in Section III-B:

Boarding pass scans score (data source 1): gathers the

number of boarding passes that were scanned in front of the

security checkpoint, which affects the restrooms in front of

the security checkpoint. To estimate a score, the maximum

passenger capacity per hour must be defined by the user for

the respective area of interest.

Metal detectors score (data source 2): metal detectors de-

liver the number of people who were scanned. The number is

used to estimate the usage of restrooms behind the security

checkpoint using the maximum passenger capacity per hour,

254

Source 1 Aggregate 1 Score 1

raw streams individual scorestreams

Source 2 Aggregate 2 Score 2

Source N Aggregate N Score N

… … …

internal passenger satisfaction index stream

fixed window of size *

keye

d pe

r loc

atio

n

cleaning

fixed window of size *

default decreasing slope

reset index = weighted mean, * = time interval in which satisfaction percentage index is aggregated

Fig. 4: Resampling and aggregation of heterogeneous event streams to the KPI in the event processing module.

which is defined by the user for the respective area of interest.

Passengers planned score (data source 3): the estimated

number of passengers departing in the following hours is

used to estimate the number of passengers arriving at the

security checkpoint. The source is used to calculate a score

for restrooms before and after the security checkpoint using

the maximum passenger capacity per hour, which is defined

by the user for the respective area of interest.

Passenger feedback score (data source 4): uses the feedback

of users who can rate a restroom in the categories good,

average and bad. The score normalizes these ratings between

1 (100% good ratings) and 0 (100% bad ratings). A minimum

number of ratings is necessary within a time window to avoid

a strong impact of, for example, one bad rating within four

hours.

Air quality score (data source 5): delivers a value reflecting

the quality of air of the restroom in which the sensor is

installed. A formula maps the proprietary measurement to the

score.

All sources are combined using weights defining the impact

of the respective source and computing the weighted mean.

User-defined properties can be configured easily in a separate

file.

V. IMPLEMENTATION

The following describes how the event processing (V-A)

and the web application (V-B) were implemented. The actual

deployment of the ecosystem is explained in Section V-C.

A. Event Processing

The event processing engine, which was developed using

the open source stream processing framework Apache Flink

[4], is the core part of the event processing module (see Figure

3). It allows stateful computations over multiple data streams

in parallel and can evaluate complex event patterns on these

streams. Events are ingested by so-called event sources. These

sources can handle arbitrary kinds of data and serve as an

adapter interface for data ingestion into the engine. Currently,

the engine supports sources for REST (representational state

transfer) and MQTT (message queuing telemetry transport)

sources which cover state-of-the-art data transfer protocols in

the Web and in the IoT (Internet of Things) area. During

ingestion of events, which can happen in parallel and, due to

multiple sources of event emitters, even non-deterministically,

events are aggregated in equidistant time frames.The PSI is computed using multiple event sources and thus

multiple event scores per time frame of evaluation. For each

event source and time frame, a score is calculated expressing

the positiveness of the event stream according to location-

based passenger satisfaction. The following describes the score

computation of the restroom passenger feedback:For each restroom i, take all passenger feedback xi1 to xin

for each equidistant time interval tk to tk+1 and aggregate

them according to f(i, xi1, .., xin), for f(I, xi1, .., xin) =((good(xi1, .., xin) ∗ 100.0 + avg(xi1, .., xin) ∗ 25.0 +bad(xi1, .., xin) ∗ 0.0)/n)/100.0.

These scores are summed together, calculating the weighted

mean using a pre-defined weighting per score. The post-

processing function reflecting the standard decay over time

is applied afterwards. The result is the PSI KPI stream that

forms the basis for alerts. Alerts and the KPI are uniformly

emitted through a set of pre-defined event sinks. Currently

available sinks include Elasticsearch, MQTT and RabbitMQ,

but the engine is not limited to these.The database where the processed data is stored is Elas-

ticsearch, which is a NoSQL document-based database. This

database is hosted in Amazon Web Services (AWS) as a

service along with a Kibana dashboard that enables one to

browse the data in the indices where it is stored. The data

is organized in different indices, e.g., psi-index, psi-threshold,

and psi-time-to-clean-prediction.Processed events are also sent in realtime to a RabbitMQ

message broker on specific channels. The data itself is format-

ted according to the JSON format.

B. Web ApplicationThe restroom cleaning dashboard (Figures 5 and 6) has been

designed to show the restrooms’ status at a glance allowing the

255

(a) Home page.

(b) Restroom PSI.

Fig. 5: Home page and PSI visualization.

dashboard end-user (e.g. the airport manager) to organize the

cleaning teams accordingly. The home page (Figure 5a) shows,

in the top section, a summary of the average PSI KPI for all

the restrooms as well as the number of restrooms with a high,

medium and low index (respectively, “high” corresponds to a

PSI above the cleaning threshold; “low” corresponds to a PSI

below the low cleaning threshold; “medium” corresponds to

a cleanliness index between the two previous thresholds). The

remaining part of the home page provides a table summarizing,

for each restroom, the PSI KPI, the forecast for the next

cleaning time, and possible alarm raised. A filter panel on the

left allows the restrooms to be filtered according to terminal,

floor, area, restroom, gender and team. Alarms raised for a low

PSI violating the thresholds are displayed in the restrooms

table for each restroom as well as in a separate notification

area accessed by clicking on the relevant toolbar icon in the

header. By clicking on the name of the restroom in the table,

it is possible to access a pop-up page (Figure 5b) that shows

the trend of the PSI.

The map view page (Figure 6a) connects with the map

system of the customer to display, on the airport map, the

restrooms with their status (high, medium and low PSI) as

well as the other details in the pop-up window. The restroom

passenger satisfaction page (Figure 6b) shows a dashboard

with the last three weeks of restroom passenger satisfaction

indices related to the restrooms and estimated according to

the passenger feedback system (updated to the previous day).

For each week, in addition to a daily chart, the worst and

best restrooms are shown in relation to the satisfaction index.

(a) Airport map.

(b) Passenger feedback.

Fig. 6: Map overview and historical data about passenger

feedback.

From this page, the airport manager can see at a glance the

ongoing trend of the index and the restrooms performing best

and worst.

C. Deployment

The various software components are integrated with each

other in a Kubernetes cluster. The cluster is hosted in a

virtual machine on AWS and comprises a master node that

also enables the execution of docker containers. There is

a deployed pod for every software component, namely: air

quality API data extraction, API module for data ingestion,

event processing engine, RabbitMQ and Smart DPA web

application.

Elasticsearch and Kibana are not hosted inside the Kuber-

netes cluster, but rather on AWS as a managed service. The

pods can interact with each other in a private network inside

the cluster. Each pod exposes an endpoint for communication

with the other pods. The web application pod is also exposed

publicly because it needs to be accessed from outside the

cluster in order to display the Smart DPA dashboard to the

end user.

VI. EVALUATION

In the following, Section VI-A describes the evaluation

approach. Section VI-B provides some reflections on the data

which was identified as crucial for the implementation and

evaluation of the system. The underlying models for the

simulation are developed in Section VI-C, followed by the

results in Section VI-D.

256

A. Approach

To test the implemented event processing module, the

logged data that was received from the airport was replayed.

To do this, the static files were read and streamed to the

Smart DPA solution through the API ingestion. The stream-

ing process was accelerated, but the relative time distance

between the events was kept. In the evaluation, we target a

comparison between the PSI based on recorded data (cleaning

operations as they occurred) and the PSI that is achieved

using the Smart DPA solution (simulated cleaning operations).

Simulated cleaning activities are scheduled when alerts have

been triggered based on the PSI. Artificial passenger feedback

is generated based on trends discovered in historical feedback

logs. We thereby focus on the impact of cleaning activities

on PSI represented by passenger feedback (good, average and

bad), computed as described in Section V-A. The following

approach for the validation has been followed:

1) Analysis of logged restroom passenger feedback data

before and after cleaning, aiming to identify a function

able to estimate the trend of restroom passenger feedback.

2) Simulation of new cleaning activities with the Smart DPA

solution and estimation of the new Restroom Passenger

Feedback using the trend function defined in 1.

3) Comparison of the new restroom passenger satisfaction

against the logged restroom passenger satisfaction.

B. Data Assessment and Preparation

Before simulation, the data was checked for correlations

which potentially affect the event processing. The following

possible relations were considered and investigated in the

available data sets as potential candidates for the evaluation:

1) Cleaning duration and restroom size: For the analysis

of a correlation between the duration of a cleaning activity

and the size of the restroom, we had a data set ranging

from January 2018 to February 2019 from 147 restrooms. In

this data, the correlation between rising cleaning duration and

restroom size was analyzed to improve the alert timing taking

into account the probable duration. Only a weak positive

correlation (corr=0.25) between these data points was found.

Restroom size is one factor which affects cleaning time. It

would be interesting to include information about the physical

room layout, and the number of people moving in and out, in

this calculation.

2) Air quality comfort and effective passengers: The air

quality sensor delivers a comfort value according to the

current air conditions every ten seconds. A high comfort value

means good air quality. This comfort value was compared to

the effective number of passengers who passed through the

security gates. The data set ranges from January to August

2019. The results can be seen in Figures 7a and 7b. The scatter

chart shows high variance. In the heat map, a correlation

between the two properties is shown. A high comfort means

few passengers, and vice versa, supporting the assumption that

air quality decreases when the number of people increases.

(a) Scatter. (b) Heat map.

(c) Scatter. (d) Heat map.

Fig. 7: a and b plot normalized air quality (x-axis) against

the number of passengers (y-axis) at the security checkpoint

close to the measured restroom; c and d plot the normalized

time after cleaning (x-axis) against the accumulated passenger

feedback (y-axis).

3) Time after cleaning and accumulated passenger feed-back: The development of the passenger feedback over time

after a cleaning activity is of interest since it is closely related

to whether passengers are satisfied with the cleaning service

at the airport. The assumption was that there is a negative

correlation between a rising time after one cleaning with no

cleaning in between and a declining accumulated passenger

feedback.

A data set covering the time frame from the beginning of

January 2019 to the end of February 2019 containing data

about 15 restrooms of the selected airport area was available.

Complete data showing a good coverage of the selected data

properties was only available for this subset. The correlation

between time after cleaning, i.e. the accumulated seconds after

a recent cleaning without additional cleaning, was compared

to the accumulated passenger feedback in that time period.

Positive feedback was counted as +1, negative feedback -1

and neutral feedback as 0. The result is shown in Figures

7c and 7d. In the figures it can be seen that feedback is

tendentially negative (around a normalized 0.4, where 0.5

indicates neutral feedback) and occurs with higher frequency

briefly after cleaning due to the fact that cleanings were in

most cases separated by a normalized time smaller than 0.2.

In the charts it can be seen that a negative trend was not found

in the whole data set. Only selected restrooms showed such a

trend. The reason lies in missing data points, because many

cleaning events were not properly recorded, or were recorded

with wrong data, e.g. a cleaning duration of zero seconds.

257

Since the trend after cleaning was not approved, we ex-

amined the change of feedback, having a look at the trend

before and after cleaning. Figure 8 shows passenger feedback

aggregated from the same 15 restrooms in 10-minute buckets

before and after a cleaning activity. Data in the interval

between 10 and 15 minutes after cleaning was resampled due

to a lack of data in this time window. In the chart, the good

feedback slightly increases and the average and bad feedback

clearly drops, which indicates a positive impact of the cleaning

activities on passenger feedback.

Fig. 8: Mean number and trend of passenger ratings in 10-

minute buckets 30 minutes before and after cleaning

C. Simulation Model

Since it was not possible to deploy the Smart DPA so-

lution due to ongoing organizational changes at the airport,

we had to simulate the customer behavior in order to test

the hypothesis that dynamically scheduled cleaning based on

the PSI improves the passenger satisfaction. Thus, the event

processing engine was tested in isolation by using the historic

data of restroom passenger satisfaction events as above. Two

simulation approaches were checked, machine learning and

regression analysis.

1) Machine Learning: In the learning approach, we wanted

to simulate passenger feedback through a machine learning

approach. This included the construction of a neural network

machine learning model using logistic regression, of a k-

nearest neighbors algorithm (k-NN classifier), and of a random

forest classifier based on decision trees. The available data set

of passenger feedback was divided into a training set (70%

of the available data) and a test set (30% of the available

data). For training purposes, AWS (Amazon Web Services)

and scikit-learn was used.

During testing, the machine learning models turned out to be

not very precise. The neural network using logistic regression

provided a precision of 54%, the k-NN classifier 52% (k = 5),

and the random forest classifier 57% (n estimators = 500) for

this three-class problem. Due to our experiment, we assume

that the amount of training data is too low. The models tend

to overfit due to a lack of variation in the data set (it was

dominated by good ratings). More data needs to be collected

that has an impact on the passenger feedback to train the

model.

2) Regression Analysis: Since the machine learning ap-

proach based on the available data set did not provide good

results, we decided to use a trend and forecast estimation based

on the same set of restrooms accepting the lack of variance.

For this, we used the least squares method to compute the trend

of existent data and to forecast the trend for non-existing data,

a standard approach in regression analysis.

The average number of passenger ratings was computed in

buckets of 30 minutes after cleaning. The resulting trend of

passenger feedback was estimated for buckets between 0 and

270 minutes on existing numbers and continued into a forecast

for buckets between 270 and 1050 minutes. Figure 9 shows

the results.

Fig. 9: Trend and forecast for average restroom passenger

satisfaction numbers after a restroom was cleaned.

3) Simulation Parameters: In simulation mode, one hour

corresponds to 0.5 seconds, which allows us to simulate two

months in twelve minutes. Passenger feedback was linearly

distributed from the three categories good, average and bad

within a 30-minute bucket. The cleaning threshold on the

restroom cleanliness index (used to estimate the next cleaning

activity) was set to 85% in the first and to 90% in the second

simulation run. Once a necessary cleaning was detected,

restroom passenger satisfaction was reset to the beginning of

the respective trend line.

We selected the restroom with the air quality sensor for

the simulation, a restroom in the landside check-in area, since

it provides a complete log and an interesting test case with

variation between the three passenger feedback categories with

a correlation between feedback and the time passed after a

cleaning activity of corr=-0.55.

D. Result

In Table I the results from both simulation runs are sum-

marized and compared against the logged data of the selected

restroom.

Simulation 1: In the first simulation, 153 cleaning activities

were generated, cleaning on average 3 times a day. Compared

to the recorded data of the selected restroom, that is 3 times

less. Nevertheless, the restroom passenger satisfaction, based

on the formula described in V-A, was 48% compared to 42%,

i.e. six percentage points better.

258

Data set Cleaning Decreasing Cleaning Avg. Pax.thresh. slope activities index satisf.

Rec. data 0.85 (w=1) 0.05 (w=0.1) 312 0.57 42%Simulation1 0.85 (w=1) 0.05 (w=0.1) 153 0.82 48%Simulation2 0.90 (w=1) 0.05 (w=0.5) 296 0.66 51%

TABLE I: Comparison between the simulation runs and

recorded data from the restroom used as reference.

Simulation 2: Increasing the threshold to 90% and the

weight of the standard decreasing slope from 0.1 to 0.5 in

the second simulation run, we achieved a higher frequency

of cleaning activities. In this run, a satisfaction of 51%

was achieved with 296 generated cleaning activities. With

an almost equal number of cleanings, the simulated restroom

passenger satisfaction was nine percentage points higher with

an almost equal number of cleaning activities.

It is important for the scope of this analysis to focus on

the percentage increase we measured rather than the absolute

percentage value of this data that depends on the airport

and on the selected restrooms, i.e. apart from the cleanliness

of the restroom, there could be other reasons behind the

feedback given by customers, for example the size, fixtures

and crowdedness of the restroom.

The outcome of the simulation supports the hypothesis that

cleaning at the appropriate time has the potential, even if

conducted less frequently, to improve the restroom passenger

satisfaction. The Smart DPA solution enables such an improve-

ment and supports the improvement of satisfaction and the

effective scheduling of cleaning activities.

VII. CONCLUSION

Smart DPA provides a configurable event-driven architec-

ture efficiently processing and mapping heterogeneous data

streams occurring with different frequencies at the airport.

Based on historical data from the airport, it was shown that

the platform has the potential to improve passenger satisfaction

when services are scheduled according to the alerts generated

by the platform.

For monitoring restrooms, it would have been helpful to

integrate a system counting passengers entering and exiting

restrooms, which was not available. A system integration with

the airport infrastructure was started and could be used in the

future to show the effect of the approach in real life. This

would allow a study gathering qualitative feedback, e.g. neg-

ative feedback due to a restroom being closed at the moment.

A new situation is the detection of people infected with a

virus, indicated e.g. by fever based on a temperature-sensitive

camera. The detection of one such person would make clean-

ing immediately necessary again even it was cleaned minutes

before. In our system a respective score computation and

weighting may lend emphasis to the importance of such a

data source, but a new challenge arises for staff scheduling

when dealing with such exceptions. A transfer of the solution

to other domains, for example manufacturing, would be quite

interesting and is supported due to the reusable and extensible

design of the software.

ACKNOWLEDGMENT

This research was funded in part by the EIT Digital Tech

Activity 19194 (project SmartDPA) and by the German Fed-

eral Ministry of Education and Research under grant number

01IS19022E (project BaSys4.2).

REFERENCES

[1] S.-J. Hong, D. Choi, and J. Chae, “Exploring different airport users’service quality satisfaction between service providers and air travelers,”Journal of Retailing and Consumer Services, vol. 52, p. 101917, 2020.

[2] R. Curley. (2018) Airports turn to technology to keep airport toiletscleaner. [Online]. Available: https://www.businesstraveller.com/business-travel/2018/10/09/airports-turn-to-technology-to-keep-airport-toilets-cleaner/

[3] S. Vora. (2018) Believe it or not, airport bath-rooms are getting better (and cleaner). [Online]. Avail-able: https://www.nytimes.com/2018/10/05/travel/airport-bathrooms-cleanliness-apps.html

[4] P. Carbone, A. Katsifodimos, S. Ewen, V. Markl, S. Haridi, andK. Tzoumas, “Apache flink: Stream and batch processing in a singleengine,” Bulletin of the IEEE Computer Society Technical Committeeon Data Engineering, vol. 36, no. 4, 2015.

[5] G. C. Bezerra and C. F. Gomes, “Performance measurement inairport settings: A systematic literature review,” Benchmarking: AnInternational Journal, vol. 23, no. 4, pp. 1027–1050, Jan 2016.[Online]. Available: https://doi.org/10.1108/BIJ-10-2015-0099

[6] A. Lundberg, “Leverage complex event processing to improve opera-tional performance,” Business Intelligence Journal, vol. 11, no. 1, p. 55,2006.

[7] S. G. Boyer, J. R. Offutt, and K. P. Farrow, “Event driven airport,”U.S. Patent 20 020 198 747, December, 2002. [Online]. Available:http://www.freepatentsonline.com/y2002/0198747.html

[8] D. Luckham, Event Processing for Business: Organizing the Real-TimeEnterprise. Wiley, 01 2012.

[9] G. Pestana, S. Heuchler, A. Casaca, P. Reis, and J. Metter, “Complexevent processing for decision support in an airport environment,” Inter-national Journal on Advances in Software Volume 6, Number 3 & 4,2013, 2013.

[10] K. G. Zografos, M. A. Madas, and Y. Salouras, “A decision supportsystem for total airport operations management and planning,” Journalof Advanced Transportation, vol. 47, no. 2, pp. 170–189, 2013. [Online].Available: https://onlinelibrary.wiley.com/doi/abs/10.1002/atr.154

[11] Xovis AG. (2020) Xovis PTS. [Online]. Avail-able: https://www.xovis.com/fileadmin/dam/documents/Xovis-brochure-Airports.pdf

[12] ANA Aeroportos de Portugal. (2017) I-sense. [Online].Available: https://www.routesonline.com/airports/8214/ana-aeroportos-de-portugal/routes-tv/5597756299001/

[13] Sita. (2020) Sita QueueAnalyzer. [Online]. Available:https://www.sita.aero/pressroom/news-releases/orlando-international-airport-eases-stress-at-security-with-sita-tech

[14] Smart Flows. (2020) Make customer-driven decisions to improve yourbusiness based on the flow within your airport. [Online]. Available:http://www.smart-flows.com/p/solutions-details/airport/

[15] Tibco. (2018) Airports: How to get insights from passengers. [On-line]. Available: https://www.tibco.com/sites/tibco/files/resources/WP-airports-how-to-gain-insights-from-passengers-final.pdf

[16] Infax. (2020) TRAX SmartRestroom. [Online]. Available:https://www.infax.com/solutions-airports.html#air-trax

[17] Tooshlights. (2020) Smart restrooms. [Online]. Available:https://tooshlights.com/modus-systems-software/

[18] RestroomApp. (2020) Real-time monitoring of restrooms. [Online].Available: http://restroomapp.com/

[19] Saniori. (2020) Digital toilet monitor. [Online]. Available:https://www.saniori.com/

[20] J. Evermann, J.-R. Rehse, and P. Fettke, “A deep learning approach forpredicting process behaviour at runtime,” in International Conferenceon Business Process Management. Springer, 2016, pp. 327–338.

[21] A. Emrich, A. Theobalt, F. Leonhardt, S. Knoch, D. Werth, and P. Loos,“A pervasive mobile assistance system for health and fitness scenarios,”in 2014 47th Hawaii International Conference on System Sciences.IEEE, 2014, pp. 2898–2907.

259