CUPPS Recommended Practice...CUPPS could also be carried forward to provide services at other venues such as rental car agencies, bus terminals, seaports, and railway stations. The

Airports Council International

Recommended Practice 500A07

Air Transport Association

Recommended Practice 30.201

International Air Transport Association

Recommended Practice 1797

CUPPS Version: 01.00Document Issue: 00.00.5024Last Updated: 09JAN2008

CommonUse

PassengerProcessing

Systems

RecommendedPractice

*** FINAL ***

Airports Council International

Recommended Practice 500A07

Air Transport Association

Recommended Practice 30.201

International Air Transport Association

Recommended Practice 1797

CUPPS Version: 01.00Document Issue: 00.00.5024Last Updated: 09JAN2008

CommonUse

PassengerProcessing

Systems

RecommendedPractice

*** FINAL ***

c© 2005-2007, IATA. All rights reserved.

First edition: 03JUN2007

Acknowledgments:Acrobat R© is a registered trademark of Adobe Systems Incorporated.JavaTMand JRETM are trademarks of Sun Microsystems, Inc.Windows R©, Internet Explorer R©, Excel R©is a registered trademark of Microsoft Corporation.Windows VistaTM is a trademark of Microsoft Corporation.

This document was typeset using the LATEX system.

i

Brief Contents

Brief Contents i

Contents iii

List of Tables v

List of Figures vii

1 Common Use Passenger Processing Systems (CUPPS) 1

2 Overview 5

3 CUPPS Technical Documentation Summary 9

4 Roles and Responsibilities of CUPPS Parties 21

5 Applicable Industry Standards 23

Abbreviations 25

References 27

Index 29

CUPPS-RP — CUPPS Version 01.00 — Document Issue 00.00.5024 — *** FINAL ***

iii

Contents

Brief Contents i

Contents iii

List of Tables v

List of Figures vii

1 Common Use Passenger Processing Systems (CUPPS) 11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Overview 52.1 Benefits of CUPPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 CUPPS Product Strategy . . . . . . . . . . . . . . . . . . . . . . . . 62.3 CUPPS vs. CUTE Summary . . . . . . . . . . . . . . . . . . . . . . 62.4 CUPPS Platform Standards . . . . . . . . . . . . . . . . . . . . . . 62.5 CUPPS Management Oversight . . . . . . . . . . . . . . . . . . . . . 72.6 CUTE to CUPPS Migration . . . . . . . . . . . . . . . . . . . . . . . 7

3 CUPPS Technical Documentation Summary 93.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 Access to the CUPPS-TR and CUPPS-TS . . . . 93.1.2 CUPPS Technical Documentation Ownership . . 103.1.3 Data Privacy . . . . . . . . . . . . . . . . . . . . 103.1.4 Public Data . . . . . . . . . . . . . . . . . . . . 103.1.5 Personal Data . . . . . . . . . . . . . . . . . . . 103.1.6 Proprietary Data . . . . . . . . . . . . . . . . . . 113.1.7 Usage and/or Performance Data . . . . . . . . . 11

3.2 CUPPS Logical System Architecture . . . . . . . . . . . . . . . . . . 113.2.1 CUPPS Logical System Architecture Summary . 11

3.3 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4.1 Workstations . . . . . . . . . . . . . . . . . . . . 133.4.2 Servers . . . . . . . . . . . . . . . . . . . . . . . . 16

3.5 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.5.1 Workstations . . . . . . . . . . . . . . . . . . . . 16


iv CONTENTS

3.5.2 Servers . . . . . . . . . . . . . . . . . . . . . . . . 173.6 Logo Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Roles and Responsibilities of CUPPS Parties 214.1 Platform Providers Responsibility . . . . . . . . . . . . . . . . . . . . 214.2 Application Providers Responsibility . . . . . . . . . . . . . . . . . . 224.3 Establishment of Service Levels . . . . . . . . . . . . . . . . . . . . . 224.4 Management Information and Availability Figures . . . . . . . . . . 224.5 Certification and Deployment . . . . . . . . . . . . . . . . . . . . . . 22

5 Applicable Industry Standards 23

Abbreviations 25

References 27

Index 29


v

List of Tables

1.1 CUPPS Foundational Principles . . . . . . . . . . . . . . . . . . . . . . . 21.2 Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 CUTE vs. CUPPS Summary . . . . . . . . . . . . . . . . . . . . . . . . 82.2 CUTE to CUPPS Migration Considerations . . . . . . . . . . . . . . . . 8

3.1 Comparison of Data Privacy Rules . . . . . . . . . . . . . . . . . . . . . 103.2 CUPPS Device Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Required Workstation Components . . . . . . . . . . . . . . . . . . . . . 163.4 CUPPS Platform Server Software Components . . . . . . . . . . . . . . 173.5 CUPPS Platform Workstation Software Components . . . . . . . . . . . 19

5.1 IATA Recommend Practices Reference . . . . . . . . . . . . . . . . . . . 235.2 IATA/ARC Resolutions Reference . . . . . . . . . . . . . . . . . . . . . 235.3 IATA/ATA Resolutions Reference . . . . . . . . . . . . . . . . . . . . . . 245.4 Other Document References . . . . . . . . . . . . . . . . . . . . . . . . . 24


vii

List of Figures

3.1 Summary CUPPS Logical System Architecture . . . . . . . . . . . . . . 123.2 Detailed CUPPS Logical System Architecture . . . . . . . . . . . . . . . 18


1

Chapter 1

Common Use PassengerProcessing Systems (CUPPS)

Recommended Practice

RECOMMENDED that, when an organization plans to operate shared passengerprocessing systems in an airport or other common environment, for the purposes ofsupporting multiple airline processes, the specifications and standards as described inthis Recommended Practice shall be applied.

1.1 Introduction

Common Use Passenger Processing Systems (CUPPS) describes the range of services,specifications, and standards enacted to enable multiple airlines, service providers, orother users to share physical check-in or gate podium positions (whether simultaneouslyor consecutively). The CUPPS scenario assumes a circumstance whereby an airlineor employee other service provider interacts with a passenger for check-in and boardingprocesses. This Technical Specification describes agent platforms that will accommodate,but not be limited to, check-in and boarding activities. Future developments may providefor other functions, both business and technical.

Table 1.1 shows the CUPPS foundational principles.


2 CHAPTER 1. COMMON USE PASSENGER PROCESSING SYSTEMS (CUPPS)

1.2 Revision History

Table 1.2 shows the revision history for this document.

Table 1.1: CUPPS Foundational Principles

Principle DescriptionPlatform Independence Differences in legacy CUTE Platforms lead to ad-

ditional application complexities and CUTE vendor-specific versions that must be maintained over time.

Business Process Facilitation CUPPS provides a flexible Platform that facilitatesApplication functionality that may be used for a va-riety of business functions.

“Minimum, Defined” CUPPS Platforms must provide the functionality de-fined as required in the CUPPS Technical Specifica-tion.

Affordability CUPPS provides the tools and technologies that maylead to additional economies of scale and economiesof scope.

Predictability CUPPS provides enhanced predictability in termsof deployment and overall platform and applicationmaintenance (duration, cost, etc.)

Serviceability CUPPS provides the tools and technologies to in-crease efficiencies of application upgrades and main-tenance.


1.2. REVISION HISTORY 3

Table 1.2: Revision History

Issue Date Author Notes0.0.5002 03JUN2007 James McElhannon, SITA Continued initial draft


5

Chapter 2

Overview

This section provides an overview of the benefits of CUPPS, its strategy as a product,the management oversight of the ongoing CUPPS activities, and migration strategies.

2.1 Benefits of CUPPS

A CUPPS implementation will enable airlines to provide passenger services in the contextof a shared check-in, gate podium, or kiosk.

The major benefits of CUPPS are:

• Efficient use of expensive facilities on- and off-airport, thereby reducing the needfor facility expansion.

• Flexibility for accommodating flight segment additions or deletions by carriers inthe use of space.

• The ability for an Application Provider to maintain a single CUPPS-compliantapplication that will be seamlessly functional on any CUPPS platform, regardlessof the particular Platform Provider.

• A platform that can easily accommodate various peripheral devices in support ofbusiness processes.

• An enabler for improved customer service.

• A flexible architecture to easily accommodate alterations in the passenger process-ing flow.

• An accommodation of the flow of data between emerging and evolving airportand airline systems, as mutually agreed upon between the Platform Provider andApplication Provider.

• Improved flexibility for system upgrades and new versions of software and hard-ware.


6 CHAPTER 2. OVERVIEW

• Enhanced ease of access to new markets, with overall predictability of cost magni-tudes from a technology deployment standpoint.

2.2 CUPPS Product Strategy

The CUPPS product strategy is to deliver a common use Platform to support individualand shared airline processes at a shared workstation at check-in, gate, and other posi-tions, while maintaining the ability for users to maintain their brand images. The key tothe product strategy is an open architecture system where it is possible to use virtuallyany hardware or software that complies with CUPPS standards included in the CUPPSTechnical Specification (CUPPS-TS).

The functionality described is not exclusive; any future products and/or applications, asappropriate, may be introduced as business needs change.

The initial CUPPS strategy is focused on implementation in both the agent-assistedcheck-in and boarding environments on-airport and potentially in kiosk environments.CUPPS could also be carried forward to provide services at other venues such as rentalcar agencies, bus terminals, seaports, and railway stations.

The development of the CUPPS product will initially be done collaboratively with thecooperation of airlines and airports, platform providers, and platform suppliers.

2.3 CUPPS vs. CUTE Summary

There are many differences between the legacy CUTE environment and the new CUPPSforward-looking environment. Table 2.1 below provides a summary of the major differ-ences.

2.4 CUPPS Platform Standards

The CUPPS Platform comprises, at minimum, the hardware and software componentsdefined in the CUPPS-TS. The CUPPS Platform is envisaged to support a comprehen-sive range of airline and airport passenger processes and services. Initial focus of theproduct will be on passenger check-in (which could include baggage check-in) and board-ing. Devices within a CUPPS Platform shall only be used by applications initiated andoperated within the platform or diagnostic software.

Application Providers are responsible for the delivery of particular application function-ality required to support the business processes of its users.

All physical components located at a particular airport shall be equally usable by allparticipating Users.


2.5. CUPPS MANAGEMENT OVERSIGHT 7

2.5 CUPPS Management Oversight

A CUPPS Management Group (refer to Res. 706 [1] and/or ATA Res. 1.40) comprisedof airlines, airports, ACI/IATA World Business Partners and Associate Members willbe responsible for defining the certification process and amending the CUPPS standardsas published separately from this Recommended Practice, e.g., the CUPPS-TS. Formalterms of reference will be developed for the ongoing Governance of this body and itsdeliverables.

The CUPPS Management Group will be a standing body tasked with the continuedmaintenance of this RP and the CUPPS-TS.

2.6 CUTE to CUPPS Migration

With any next-generation standard or product, a mechanism must be provided to migratefrom the previous standard or product to the next-generation standard. This sectionprovides the migration considerations for moving from CUTE to CUPPS.

Given the wide array of variations between CUTE implementations combined with thedifferences that exist due to the local business and operational scenarios at each CUTElocation, there is no one migration strategy that is applicable across Suppliers. Therefore,each Platform Provider and/or Platform Supplier that proposes a CUPPS solution mustprovide a reasonable and realistic migration strategy.

Table 2.2 shows the general considerations that each Suppliers migration strategy willlikely address. Not every item will be applicable for a given situation nor will the listpresented in Table 2.2 constitute the entire list of considerations that every site mustcontemplate. These reflect examples of major considerations.

CUPPS Suppliers are not required to provide solutions to any or all of the considerationsgiven in Table 2.2, nor are the Suppliers prohibited from providing functionality that isoutside of the CUPPS specification. It is understood that CUPPS Suppliers will continueto offer solutions to customers based on mutually agreeable terms and conditions.

NOTE:

CUTE Suppliers are required to provide support for their ex-isting CUTE platforms for a period of three years from thedate of first publication of the CUPPS Technical Specifica-tion.


8 CHAPTER 2. OVERVIEW

Table 2.1: CUTE vs. CUPPS Summary

CUTE CUPPSProprietary peripheral interfaces perSupplier

Unified peripheral interface across Sup-pliers

Varying support for various peripheralsand varying functionality provided

Unified support for each device categorywith defined basic functionality

Built-in AEA support including ATB-IIwith propriety Supplier-specific exten-sions

Elimination of proprietary devicefirmware in favor of current formatssupporting barcodes; no ATB-IIoperations.

Proprietary management interfaceswith varying levels of functionality

Unified approach to system manage-ment, including remote administrationcapabilities.

Legacy CUTE may utilize a mixture ofworkstation operating systems and net-work protocols.

All CUPPS workstations will use a de-fined operating system and network pro-tocol (including network services).

Legacy CUTE implementations pro-vided a mixture of low- and high-levelperipheral interface technologies thatwere largely incompatible and Supplier-specific.

CUPPS defines a standard high-level in-terface standard between applicationsand the platform.

Table 2.2: CUTE to CUPPS Migration Considerations

Consideration ImpactPotential operatingsystem changes

For applications built on a non-supported operatingsystem, applications must be ported or rewritten forthe CUPPS supported operating systems.

Application changes Legacy CUTE applications must be adapted to workwith the CUPPS platform.

Elimination of propri-etary device firmware

Applications and business processes that rely onproprietary device firmware must be adapted to E-Tickets and barcode technologies. Proprietary pe-ripheral interfaces are eliminated in favor of a stan-dard high-level interface.


9

Chapter 3

CUPPS Technical DocumentationSummary

Major deliverables of the CUPPS process will be the creation and adoption of theCUPPS-TR and CUPPS-TS, which are overviewed below. The CUPPS-TR providesa formal requirements document used to guide the CUPPS-TS. CUPPS-TS providesdefinitions for the functionality and performance of the CUPPS platform and defines thefunctionality and performance of the interfaces between the application and platform.The CUPPS-TS will not, however, specify an implementation for that functionality orinterface. CUPPS Suppliers are free to implement their CUPPS products as the Supplierdeems appropriate provided that they meet the functionality and interfaces defined inCUPPS-TS. The CUPPS-TS also addresses the minimum operational characteristics forCUPPS applications.

3.1 General

The general considerations for CUPPS are provided below.

3.1.1 Access to the CUPPS-TR and CUPPS-TS

In accordance with the Governance terms of reference, ACI, ATA, and IATA shall pro-duce, update, and make available the CUPPS-TR and CUPPS-TS in electronic formatwhich shall set forth the standards and specifications for CUPPS. As a condition to cer-tification, Application Providers and Platform Providers shall be required to maintaina current subscription to the CUPPS-TR and CUPPS-TS. To enable them to defraythe costs incurred in developing and maintaining the CUPPS-TR and CUPPS-TS, ACI,ATA, and IATA shall establish an annual subscription fee for the documents. Access tothese documents, and the fee to be charged, will be non-discriminatory, i.e., all interestedparties, whether or not members of ACI, ATA, or IATA, will be afforded access to thedocuments on the same terms, and will pay an equal fee for such access.


10 CHAPTER 3. CUPPS TECHNICAL DOCUMENTATION SUMMARY

3.1.2 CUPPS Technical Documentation Ownership

The requirements, functional requirements, specifications, and interface descriptions asdescribed in CUPPS-TR and CUPPS-TS are owned by ACI, ATA, and IATA and aremaintained by the CUPPS Management Group.

3.1.3 Data Privacy

The rules governing the safeguards placed on data acquisition, retention, and accessibilityare defined below. Table 3.1 provides a summary comparison of Public Data, PersonalData, and Proprietary Data.

Additionally CUPPS recognizes and acknowledges the Payment Card Industry DataSecurity Standard v1.1 (PCIDSS) [2] as related to credit card data security which isfurther addressed in the CUPPS Technical Specification.

Table 3.1: Comparison of Data Privacy Rules

Data Type Acquisition Retention AccessibilityPublic Acquired as de-

siredPeriod defined bythe PP

Available to allusers or inter-faced systems.

Personal Only as allowedand appropriate

Only as allowedand appropriate


Proprietary Only as allowedand appropriate



Usage and/orPerformance

Automatically asCUPPS is used

Period defined bythe PP

To using entity(PP, PS, AS andUser)

3.1.4 Public Data

Public Data have no access controls placed on them. Public Data may be requested byand revealed to any CUPPS user or interfaced system. Public Data may be acquiredand/or retained for a period to be defined by the PP.

3.1.5 Personal Data

Acquisition, retention, and accessibility of Personal Data must be provided in accordancewith Recommended Practice 1774 (Protection of Privacy and Trans-border Data Flowsof Personal Data used in International Air Transport of Passengers and Cargo) andregulations defined by the applicable legal jurisdictions.


3.2. CUPPS LOGICAL SYSTEM ARCHITECTURE 11

3.1.6 Proprietary Data

Acquisition of, retention of, and accessibility of Proprietary Data is to be provided inaccordance with the rules defined by the originator of the Proprietary Data. In theabsence of superseding rules, the default rule implemented by CUPPS must be thatProprietary Data is acquired, retained, and accessed only with the permission of theoriginator of the data.

3.1.7 Usage and/or Performance Data

Acquisition, retention, and accessibility of Usage and/or Performance Data are to beprovided in accordance with the CUPPS-TS. In the absence of superseding rules, thedefault rule implemented by CUPPS must be that Usage Data is:

• Acquired automatically by CUPPS.

• Retained for a period defined by, and at the discretion of, the Platform Provider.

• Accessed only by:

– The using entity, i.e., the entity using CUPPS whose activity was recorded bythe platform. A using entity must not be able to access another using entitysdata.

– The Platform Provider.

– The Platform Supplier.

3.2 CUPPS Logical System Architecture

Unlike CUTE, whose logical system architecture varied across Suppliers, CUPPS pro-vides a unified logical architecture. The logical system architecture is overviewed below.Further information regarding the logical architecture will be available in the CUPPS-TS.

Note that this section provides information only on the logical architecture of CUPPS.Since each CUPPS Supplier is free to implement the CUPPS system as the Supplierdeems appropriate, it is not possible to define the physical architecture of a particularSuppliers implementation of CUPPS.

3.2.1 CUPPS Logical System Architecture Summary

Figure 3.1 shows a summary view of the logical architecture of a CUPPS implementation.Each block in the diagram is described below. Airline application server(s) or hostsystem(s) communicate to the airline CUPPS application using a mutually supportedcommunications protocol. The architecture and functionality of the airline back-end



Figure 3.1: Summary CUPPS Logical System Architecture

systems or airline application are outside of the scope of CUPPS and are therefore notdiscussed.

The CUPPS application communicates with the CUPPS platform utilizing the interfacedefined in the CUPPS-TS. Applications may only access CUPPS-defined peripherals viathe interface defined in the CUPPS-TS. Direct access to a CUPPS-defined peripheraldevice is not allowed. Applications may access workstation components (see Table 3.3)via basic operating system services.

The airline system manager or the platform providers system manager componentsmay communicate with a CUPPS platform using the management interface defined inCUPPS-TS.

Figure 3.2 shows a detailed view of the logical architecture.

NOTE:

Figure 3.1 and Figure 3.2 are presented here for illustrativepurposes only. Refer to the CUPPS-TS for actual architec-tural definitions.


3.3. NETWORK 13

3.3 Network

The network infrastructure for a CUPPS implementation will provide functions describedbelow. Technical specifications for these functions are described more fully in CUPPS-TS. It is understood that the provider of the network infrastructure may not be thesame entity as the provider of CUPPS. If a different entity provides the network, thenthe table below represents examples of service requirements that CUPPS expects.

• DNS DNS provides name-to-IP and IP-to-name address lookup functionality forcomputer addresses and names. DNS used by CUPPS must support multiple zone-to-zone transfers and multiple partial zone-to-zone transfers.

• NAT NAT translates one range of network addresses onto another range.

• NAPT NAPT hides the internal structure of the network by mapping all addresseson the network to a single address using different network ports.

• VPN A VPN provides for a secure tunnel between two points on a network.VPNs are often used to tunnel from a workstation on an external network into acorporate private network.

• Wireless Wireless infrastructure may be made available for use by the airlines,airports, and/or the general public. Appropriate security measures must be un-dertaken to ensure access is controlled and data is kept secure for CUPPS.

• SNMP SNMP provides a standard for remote management of network devices.

• MQoS Networks used for CUPPS must meet a MQoS standard.

• Business Continuity / Disaster Recovery The network underlying CUPPSshould provide BC/DR functionality, ensuring redundancy and resiliency.

• Standardized Procedures CUPPS networks must be managed with a set ofstandardized procedures, e.g., ITIL, ISO, etc.

• DHCP Dynamic Host Configuration Protocol (DHCP) may be used to managenetwork address allocation.

• Login/Logon A standardized login scheme will be used to gain access to networkresources.

3.4 Hardware

The CUPPS hardware standards are overviewed below. The details of the hardwarerequirements for CUPPS are defined in the CUPPS-TS.

3.4.1 Workstations

The hardware used by workstations is summarized below.



Vendors

Workstation hardware may be provisioned from any vendor provided that the hardwaremeets the requirements for a given implementation. The vendors that are appropriatefor a given implementation will vary depending upon the local implementation detailsand local preferences.

Device Interfaces

Table 3.2 summarizes the device functionality, i.e. the peripherals, which may be providedon a CUPPS Workstation. Note that a single hardware device may implement more thanone function described by the CUPPS documentation. Choices of specific hardware areleft to the individual CUPPS supplier. It is recognized that additional defined Devicesand functionality may be added in the future. [Req ID: ds1]

Table 3.2 shows the requirement level for each of the device functions.

Table 3.2: CUPPS Device Interfaces

Abbrev. Interface SupportBC Barcode reader Defined, RequiredBE Beep Device Defined, RequiredBG Boarding Gate Reader Defined, Not RequiredBS Baggage Scale Not Defined, Not RequiredDD Display Device Defined, RequiredDI Document Image Defined, RequiredID Information Display Defined, RequiredMS Magnetic Stripe Reader Defined, RequiredOC Optical Character Reader Defined, RequiredPO Point of Entry Not Defined, Not RequiredPR Printer Defined, RequiredRB RFID Baggage Tag Printer Defined, RequiredRF RFID Reader/Encoder Defined, Not RequiredRW Raw Defined, Required

• Bag Scales Baggage scale Device may be supported by the Platform. The char-acteristics of the Device can be used to determine the exact capabilities of theDevice. The basic interface allows for reading the weight and zeroing the scale.

• Barcode Readers Barcode readers must be supported by the Platform. Thereader’s characteristics will determine what symbologies it supports (Interleaved 2of 5, PDF-417, etc.) and other information.

• Biometrics Biometric Devices may be supported by a particular platform, buttheir support is not required.

• Display Devices (Signage) Display Devices may be supported by the Platform.The display may be used for branding purposes, check-in displays, gate displays,


3.4. HARDWARE 15

Device-related displays, or other purposes. Depending on the Device’s capabilities,the display may be capable of displaying text, graphics, movies, etc. The displaysmay be controlled through a Flight Information Management System (FIMS) com-pliant system or may be directly controlled by CUPPS. The characteristics of theDevice can be used to determine its exact capabilities. [Req ID: pss1] [Req ID: pss2] [Req

ID: pss2.a] [Req ID: pss2.b]

• Point of Entry Point of Entry Devices such as those used for automated boardinggates may be supported by the Platform. The basic interface will allow for genericfunctions such as open, close, etc.

• Optional Character Recognition OC devices must be implemented by thePlatform.

• Passport Full-page imaging passport readers have a defined interface but are notrequired to be implemented.

• Printer A printer Device, which may be capable of handling one or more stocktype(s) must be supported. The legacy differentiation between baggage tag printersand boarding pass printers is eliminated. Instead, both Devices are simply printerswith varying characteristics such as stock type(s).

• Raw Devices Raw Devices, which are Devices that have no high level CUPPS-defined API, must be allowed by the Platform. The raw Device interface is simplya mechanism to enable or disable an I/O port that is secured by the Platform.Once a physical I/O port is enabled, the API provided by the device is used tocommunicate with the Device. When use of the raw Device is completed, thephysical I/O port is secured. [Req ID: ds2]

• RFID RFID R/E Devices may be supported by the Platform. The characteristicsof the Device can be used to determine whether the Device is a reader, an encoder,or both, and other information.

• Still Cameras Still camera Devices may be supported by the Platform. Thebasic interface supports taking a snapshot to return to the Application. The char-acteristics of the Device can be used to determine its exact capabilities.

• Other Devices Any other Devices not specifically mentioned in Table 3.2 donot have a high-level interface and are not required to be supported by a CUPPSPlatform.

Table 3.3 shows the minimum components, e.g., the internal components that make upthe workstation and its operating system, used by CUPPS workstations. A CUPPS in-terface will not be defined for these components. These components are directly accessedby either CUPPS or COTS applications.

Workstation Ergonomics

The workstations should be designed to maximize utilization of limited counter-top sur-faces (e.g., trackball versus mouse, etc.). The counter design should be configured in



conjunction with ergonomically placed peripherals, to minimize time/motion activitiesin issuing/reading documents.

Consideration will be given to the occupational requirements related to accommodationfor physical challenges and overall occupational health and safety.

A repository will be established for counter design documents related to common useinstallations. This repository will tentatively be held by Airports Council InternationalWorld.

3.4.2 Servers

Server hardware may be provisioned from any vendor provided that the hardware meetsthe requirements for a given implementation. The vendors that are appropriate for agiven implementation will vary depending upon the local implementation details andlocal preferences.

3.5 Software

CUPPS software will be designed as described below.

3.5.1 Workstations

Table 3.5 shows the CUPPS software and design considerations for end-user workstations.The CUPPS-TS shall define the exact requirements for each of these functions.

The workstation requirements given below do not imply or require any particular imple-mentation by a CUPPS Supplier other than these functions must be accessible via thedefined interfaces from every CUPPS workstation in a given implementation. CUPPS

Table 3.3: Required Workstation Components

Function DescriptionComputer The computer and its internal components.

Keyboard A standard 101+-key keyboard is required for each end-userworkstation per local configurations.

Pointing Device A pointing device is required for each workstation.

Touch Screen A touch screen is required to support the check-in andboarding functionality required by airlines and airports.

Windows OperatingSystem Services

Windows provided print spooler, file access, memory man-agement, etc.


3.6. LOGO REPOSITORY 17

Suppliers are free to implement a software architecture that implements the standardCUPPS interfaces as they deem appropriate.

3.5.2 Servers

Table 3.4 shows the CUPPS software and design considerations used on application orplatform servers. The CUPPS-TS shall define the exact requirements for each of thesefunctions.

The server requirements given below do not imply or require any particular implemen-tation by a CUPPS Supplier. CUPPS Suppliers are free to implement a software archi-tecture that implements the standard CUPPS interfaces as they deem appropriate.

Table 3.4: CUPPS Platform Server Software Components

Function DescriptionCUPPS platform functionality CUPPS Suppliers may implement software com-

ponents on the CUPPS servers as they deem ap-propriate.

Operating System(s) CUPPS Suppliers are free to implement any op-erating system on the server hardware that sat-isfies CUPPS-TS.

3.6 Logo Repository

IATA may maintain a repository of carrier-approved logos, for use by approved IATAassociates or ACI member airports to enable the associates to find the latest approvedversion of carrier approved logos (or others, such as those used by ground handlers) foruse on systems including CUPPS, FIMS, etc. It is recommended that the repositorycontain a variety of logos for each carrier, with descriptions for proper use (for a lightbackground, for a dark background, for small logos on individual lines of FIMS displays,etc.). Additionally, each logo should be made available in a format scalable to a varietyof display sizes so that the logo can be viewed without distortion. Every effort shouldbe made to provide enough information about each logo and its intended use, so as toreasonably ensure the logo will be correctly displayed.



Figure 3.2: Detailed CUPPS Logical System Architecture


3.6. LOGO REPOSITORY 19

Table 3.5: CUPPS Platform Workstation Software Components

Function DescriptionApplication Management CUPPS platforms must implement application man-

agement functionality appropriate to support theCUPPS platforms.

Authentication Platforms must provide authentication services forusers onto the workstation and local network re-sources.

COTS Software COTS applications must be well-behaved and mustnot pose any unreasonable performance or securityimpacts to the platform or local network.

Application Requirements Applications must be well-behaved, with no unrea-sonable performance impacts, security risks to theplatform or local network.

Event Management Platform must implement an event managementfunctions for application and platform events.

Hardware AbstractionLayer (HAL)

Platforms must provide a HAL that shields applica-tions from the Supplier, firmware, and connectivityof the peripheral.

Logging Platforms must provide a logging interface appropri-ate for application support and debugging purposes.

Menus Platforms must provide a Menu system with appro-priate security.

Alerts Platforms must provide security alert distribution byauthorized administrators

Operating System Workstations must use an operating system as de-fined in the CUPPS-TS.

Permissions Platforms must manage and secure access to the plat-form, network resources, and user or airline data.

Platform Management Platforms must provide management functionality tofacilitate the administration, support, and usage.

Software Distribution Platforms must provide a mechanism to distributesoftware

Storage Platforms must provide an interface for secure stor-age of data in or persistent areas.

Supplier CUPPS applications work across CUPPS implemen-tations.

World-Wide NamingStandards

A world-wide naming convention for the naming ofCUPPS workstations and peripherals.

Performance Platform performance must meet or exceed definedparameters.


21

Chapter 4

Roles and Responsibilities ofCUPPS Parties

This section addresses the roles and responsibilities of the various CUPPS parties, asthey pertain to overall system provision and maintenance.

To ensure a consistent interpretation of the material below, please note these definitions:

• Supplier A supplier is the entity that creates the system. Suppliers market theirproducts and services to Providers.

• Provider A provider is the entity that acquires the system from a Supplier andprovides it to the user community.

4.1 Platform Providers Responsibility

The Platform Provider will, as defined in the SLA, ensure that:

• The CUPPS Platform is operational and usable during the specified operationalhours.

• The CUPPS Platform is functioning and certified according to CUPPS standards.

• Software levels and version control of the Platform are maintained for the site.

• Statistical and management information is available.

• Notification is made to the Application Provider of faults that cannot be resolved.

• That the ability exists to disable an application if it is deemed to be causing otherapplications and/or the CUPPS Platform to malfunction. If this is the case theywill endeavor to inform the Application Provider in advance.

• CUPPS Workstation locations are to be locally and mutually agreed upon.


22 CHAPTER 4. ROLES AND RESPONSIBILITIES OF CUPPS PARTIES

4.2 Application Providers Responsibility

The Application Provider is responsible for the application code, which must follow andpass the Certification and Deployment process as defined in the CUPPS-TS.

If the Application Provider decides to use a dedicated Application Server, either at theCUPPS site or a location that is under the control of the Application Provider, then thatApplication Provider is responsible for the maintenance, administration, and support ofthe Server.

The Application Provider is responsible for any communication lines to and from theApplication Providers server(s).

The Application Provider must provide the correct protocol and interfaces to allowconnection at the CUPPS site as mutually agreed between the Platform Provider andthe Application Provider.

4.3 Establishment of Service Levels

Minimum Service Levels, in the form of a Service Level Agreement (SLA) will be locallyand mutually agreed upon between the Platform Provider, the Platform Supplier, andthe Application Supplier. As a guideline, a sample SLA template is included in theCUPPS-TS.

4.4 Management Information and Availability Figures

The Platform Provider should be able to supply all Application Providers the Availabilityfigures and access to the management tool used for real time status of the CUPPSinstallation.

4.5 Certification and Deployment

The Platform and applications must be certified and deployed in accordance with theprocedures in the Certification and Deployment section of the CUPPS-TS.


23

Chapter 5

Applicable Industry Standards

CUPPS adheres to, references, and acknowledges the standards shown below.

Table 5.1: IATA Recommend Practices Reference

IATA ATA Title1008 100.15 Glossary of Commonly Used Air Passenger Terms1706 n/a Functional Specification for Standard Departure Control Sys-

tem1706e 30.102 Paper Specifications Documents to be Printed by a Gen-

eral Purpose Printer (GPP) In A Common Use Self-Service(CUSS) Kiosk

1720 n/a Seat Assignment Parameters1724 20.03 General Conditions of Carriage (Passenger and Baggage)1740a 30.42 Form of Interline Baggage Tag1796 Baggage System Interface1774 n/a Protection of Privacy and Transborder Data Flows of Personal

Data Used in International Air Transport of Passengers andCargo

1778 n/a Corporate Client Identification Service1784 * Electronic Reservation Services Providers (ERSPs)1797 n/a Common Use Terminal Equipment (CUTE) systems* ATA Electronic Marketplace Committee RP

Table 5.2: IATA/ARC Resolutions Reference

IATA ATA Title740 30.42 Form of Interline Baggage Tag800z n/a Electronic Ticketing898a n/a Electronic Reservation Services Providers


24 CHAPTER 5. APPLICABLE INDUSTRY STANDARDS

Table 5.3: IATA/ATA Resolutions Reference

IATA ATA Title722e xx xx722f 20.60 Electronic Ticket Airline722g 20.61 Electronic Ticket Neutral722h xx Electronic Ticket Ground Handling724 20.03 Passenger Ticket Notice and Conditions of Contract728 110.16 Code Designators for Passenger Ticket and Baggage Check735f xx Electronic Miscellaneous Documents Airline735g xx Electronic Miscellaneous Documents Neutral740 30.35 Form of Interline Baggage Tag791 20.204 Specifications for Airline Industry Integrated Circuit Card (ICC)

Table 5.4: Other Document References

ReferenceElectronic Reservation Services Providers Implementation guideElectronic Ticketing Implementation GuideIntegrated Circuit Card Implementation GuideWorkstation Ergonomics ACILogo Repository IATAPayment Card Industry Data Security Standards


25

Abbreviations

ACI Airports Council International.

AEA Association of European Airlines.

API Application Programming Interface.

AS Application Supplier.

ATA Air Transport Association.

ATB-II Automated Ticket and Boarding passprinter with magnetic stripe operations.

BC/DR Business Continuity / Disaster Recov-ery.

COTS Commercial Off-The-Shelf.

CUPPS Common Use Passenger ProcessingSystems.

CUPPS-TR CUPPS Technical Requirements.

CUPPS-TS CUPPS Technical Specification.

CUTE Common Use Terminal Equipment.

DHCP Dynamic Host Configuration Protocol.

DNS Domain Name System.

FIMS Flight Information Management Sys-tem.

IATA International Air Transport Association.

I/O Input/Output.

MQoS Minimum Quality of Service.

NAPT Network Address Port Translation.

NAT Network Address Translation.

OC Optical Character Recognition / Reader.

PCIDSS Payment Card Industry Data Secu-rity Standards.

PP Platform Provider.

PS Platform Supplier.

R/E Reader/Encoder.

RFID Radio Frequency Identification.

RP Recommended Practice.

SNMP Simple Network Management Proto-col.

VPN Virtual Private Network.


27

References

[1] IATA. Passenger Services Conference Manual.

[2] Payment Card Industry (PCI). Data security standard (DSS), version 1.1.


29

Index

ATA Res. 1.40, 7

boarding, 1, 6, 15, 16

check-in, 1, 5, 6, 14, 16

Menu, 19

Res706, 7


31

List of Corrections
