Business Requirements Document. BCBP Passenger Data exchange using the 2D Barcode. Version March 2009

Transcription

1 Business Requirements Document BCBP Passenger Data exchange using the 2D Barcode Version March

2 Business Requirement Document BCBP Airport Data Exchange 1 Introduction Message Types and Data Flows Originator send a request message to Airline/Ground Handlers DCS to validate 2D barcode data Airline/Ground Handlers response message Process Flow overview References Terms and Definitions Scope Field Of Application Principles Functional Requirements Functional Requirements for message Request to Airline Data from the sender for DCS application Functional Requirements for message Response from airline Examples of Messages...14

3 Subject: Owner: Business Requirements: BCBP Airport Data Exchange BCBP Working Group Revision History: Version Reason Date 1 st draft Draft functional requirements by Eric Léopold / Yngvar Sundsfjord June 5 th, nd draft Modifications following the BCBP Working Group conference call December 16 th, rd draft Modifications following the BCBP Working Group meeting February 18 th, th draft Reviewed with Yngvar Sundsfjord February 26 th, th draft Updated with XMLWG comments by Yngvar Sundsfjord March 20 th,

4 1 Introduction Following a decision at IATA Annual General Meeting 2006, all airlines implement Bar Coded Boarding Passes (BCBP) according to PSC Resolution 792. BCBP enables industry standard boarding passes to be delivered through web check-in and mobile check-in. Off-airport issued boarding passes may require scanning of the BCBP at the airport, for the airline to know when the passenger arrives at the airport, or for the airline to confirm the validity of the data in the 2D barcode of the BCBP against its system. Subsequent to issuance of the BCBP, the BCBP may be scanned. The scanned bar code will be interpreted into the data that is used to compose the bar code and the data may be transmitted to an airline or other entity using XML schemas. The actual 2D barcode is not transmitted in the schema. The objective of this process is to be able to pass the encoded data of the BCBP to the airline or other entity and for the receiver to perform agreed verifications or checks according to agreed business practices. The scanning of BCBP within the airport has already been implemented by individual airlines, e.g. JAL and ANA in Japan. The scanners are provided by the airlines before entering the security screening or the airline lounge. The bar code data are sent directly to the airline host Departure Control System (DCS) for validation. Individual airports, e.g. airports in the UK, have also implemented the scanning of BCBP. The airport authorities provide scanners at security to check duplicate BCBP. The solutions that are implemented today (airline or airport driven) are designed and implemented locally due to the fact that there is no industry standard enabling the exchange of bar code data with airlines DCS hosts in a common use environment. The purpose of this document is to identify the business requirements for an XML standard format of BCBP data exchange between airport scanners and airlines DCS hosts. The XML standard will use the 2D Barcode data as created by the entity issuing the 2D barcode according to IATA Resolution 792. The XML schema can only be used to validate the structure and not the content within the 2D barcode; values will be passed as issued by the entity that created the 2D Barcode and the scanning entity sending the XML message. (Validation of data contents shall be done by these entities and the entity receiving the XML Message). The benefits of scanning a BCBP at various airport checkpoints and provide the data to the airline are: (1) to confirm the validity of the BCBP (which can also be achieved by using the digital signature), (2) to enable the tracking of passengers through various processing steps and (3) to improve on-time departure. This document does not address any security issue. It only covers the format of bar code data to be exchanged with an airline DCS host. Examples in this document are for illustrative purposes only and do not reflect actual data for any airline or airport. 4

5 2 Message Types and Data Flows 2.1 Originator send a request message to Airline/Ground Handlers DCS to validate 2D barcode data Sender Receiver Entity scan 2d barcode 2d barcode data sent Airline/Ground Handler s DCS validate data 5

6 2.2 Airline/Ground Handlers response message The response to the request will either be a confirmation or a reject with an agreed error code according to requirements Originator receive OK response from Airline/Ground Handler s DCS Response data Yes Valid 2D barcode data No Received Inhibit/Reject Inhibit/Reject Sent With defined error code The response is sent to the initiator of the message by the Airline/Ground Handler s DCS. 2.3 Process Flow overview 6

7 3 References IATA Passenger Service Conference (PSC) Resolution 792: Bar Coded Boarding Passes June 2008 BCBP Case study ANA Maximizing the benefits of BCBP April 2008 IATA Airline Coding Directory 4 Terms and Definitions 2D bar code (2DBC): The BCBP standard defines the data to be encoded and the symbology in which the data is encoded. The symbology is either PDF417 on paper or Aztec, Damatrix or QR on mobile phones. 2DBC refers to any of those bar codes compliant with the BCBP standard. Bilateral Interface Agreement: A documented agreement made between the sender and the receiver prior to the live operation of each message interface. Carrier/airline: The term carrier is used interchangeable with the term airline in this Business Requirement Document. Departure Control System (DCS): The airline, or ground handler, system that manages the check-in and boarding applications. Common Use Terminal Equipment (CUTE): The platform that connects the DCS hosts with the hardware, such as boarding pass printers and boarding gate readers, in a multi-user environment. Common Use Passenger Processing Systems (CUPPS): The platform that connects the DCS hosts with the hardware, such as boarding pass printers and boarding gate readers, in a multi-user environment. 7

8 5 Scope 5.1 Field Of Application It is assumed that the airport has agreed to provide airlines with the bar code data scanned from passenger s Bar Coded Boarding Passes at various airport checkpoints. This business document provides the framework for airlines and airport coordinators to exchange information contained into the IATA 2D bar code. The receiving system involved with the interface is primarily a DCS, but could be any system, for example a Frequent Flyer system. The airline or ground handler DCS are running on the airport s CUTE, CUPPS platform or any other platform used by the airport or single DCS system. The scanners are provided either by the airport, the airlines or a ground handler. They are located either before or after the central search area, at the bag drop counters, at the lounge front desk or any other appropriate location. These requirements reflect the airlines position on data privacy. According to these requirements, there is no need to store passenger data locally at the airport and no need for airlines to send passengers data to the airport. This document does not address security issues. This document is intended to address how BCBP data should be exchanged between Airport entities scanning the 2D barcode and the receiving airline. 5.2 Principles The bar code data is defined into the BCBP standard, IATA Resolution 792. A table mapping the airline flights with the DCS system used for the flights must be implemented at the airport. It enables the airport to send the bar code data to the right host, even in case of code-share flights or multiple DCS used for same airline (but still one DCS per flight). The message sent to the airline DCS host must contain the bar code data, as well as some contextual data. The contextual data may include: the airport code, the date and time, the scanner identification (reply-to), Airport terminal and others date defined in this document. The airport code is the IATA 3-letter code. It enables the DCS to find the right data in the bar code, which may contain several segments. The date/time provided must be indicated in UTC. It enables the DCS to compare the actual time with the flight departure or closing time. The scanner identification enables the airline DCS to select a type of message adapted to the need of the location where the BCBP was scanned. A message interface defined between the airline and sending entity will handle the message. The airline code available in the bar code data is used to route the message to the right DCS host, either the airline s host, or the ground handler s host if the airline does not use its own DCS at the airport. 8

9 The response types are defined in this document. The DCS host can either send an approval message OK, a reject message NO or an error message E#, where # is the error code. The list of error codes is included in this document. In addition to any schemas used to fulfill these Requirements and in order to define details of the message exchange, it is suggested that a Bilateral Interface Agreement is made between the sender and recipient prior to implementation. 9

10 6 Functional Requirements 6.1 Functional Requirements for message Request to Airline Data from the sender for DCS application Message Header Field Name M / O Description TRANSACTION_DATE_TIME M Message creation date/time (includes seconds and sub-seconds) Example Format Subtype Note xsd:datetime Expressed in UTC time or local time. AIRPORT_CODE M Airport 3 letter code where the BCBP is scanned LHR string TERMINAL_CODE O Local code identifying an airport terminal T3 string Terminal identification where multiple terminals exist under one airport code ORIGINATOR_TYPE M Type of entity that scanned the BCBP and is sending the message Security string IATA codeset Airport, Security, Ground Handler, Lounge, Parking, Hotel ORIGINATOR LOCATION O Location of entity performing the scan functions DELIVERING_SYSTEM O Identifier of the delivering system of the data if different from the originator (e.g. same system provided to two carriers on different contracts, need to identify which participant is sending the message) TRANSACTION IDENTIFIER M A unique identifier to relate all messages within a transaction Point A 1-70an e.g., Lufthansa Senator Lounge TBD TBD Inverted form of the domain name. ex: gov.ca.sfo or com.united Integer > 0 String 32 Used by sender to uniquely identify each message sent AGENT ID O Agent sign id This would be the agent signed in using the system doing the scanning,when available 10

11 BARCODE_DATA M Data contained in the barcode Base64binary Some non printable data 11

12 BCBP data as defined in IATA Resolution 792 In addition for references to above data, see separate attachment B to agenda item 10 12

13 6.2 Functional Requirements for message Response from airline The carriers can optionally provide errors codes for the following reasons: 1. Not valid (does not exist in the airline s passenger list, or modified from what is in the passenger s list) 2. Valid but not checked in (if scanned itinerary with 2d barcode and not B/P) 3. Valid but already scanned (duplicate check at DCS level) 4. Valid but do not allow through security (to cater for wrong terminal, or for further processing required by the airline) 5. Valid but flight cancelled 6. Valid but flight already gone please contact the airline desk These requirements only provide optional reason codes. It is decided in a bilateral agreement whether the airline is providing a reason and whether the security agent is communicating the reason to the passenger (or simply sending the passenger back to a service desk). Of course it is the security decision to let the passenger go through. The airline reply is an indication whether the barcode is valid in the airline system. Message Field Name M / O Description Example Format Subtype Note Reply M Yes or No Boolean Reason code M* Code for the reason of a no reply Integer Free text O Free text provided by the airline String M* = Mandatory when reply is No and optional free text 13

14 7 Examples of Messages See examples in separate excel spreadsheet filed as attachment C 14