Baggage reconciliation systems

Baggage Reconciliation Systems (BRS)  Background: 

According to the rules of most air transportation authorities, such as  the  U.S.  Federal  Aviation  Administration  and  the  European  Union's  Joint  Aviation  Authorities,  in  the  event  that  a  passenger  flying  internationally with checked‐in baggage fails to arrive at the departure  gate before the flight is closed, that person's baggage must be retrieved  from the aircraft hold before the flight is permitted to take off. Making  sure passengers board flights onto which they have checked baggage is  called  "passenger‐baggage  reconciliation"  and  is  accomplished  automatically  through  various  commercially  available  systems.  The  security presumption of passenger‐baggage reconciliation is that the  majority of bombers will not want to kill themselves, and will not board  an aircraft if they have caused a bomb to be placed in its hold. 

Furthermore any bag that is destined to be loaded onto a particular  flight must first be scanned and checked before loading to ensure that  there is record of that bag being checked‐in at the check‐in counter. If  no record is found the bag will be prevented from being put into a  loading  container  before  then  going  through  a  secondary  (manual)  procedure of checking/reconciliation. If that process also fails the bag  will not be loaded onto the plane. Every bag loaded must be shown to  be associated to a passenger. Unaccompanied baggage in the past has  led  to  the  downing  of  two  flights,  when  a  bomb  inside  the  bags  exploded: 

• 1985: Air India Flight 182   • 1988: Pan Am Flight 103  

Note: The information above is from Wikipedia. 

System Description:  A Baggage Reconciliation System (BRS) is used at airports to ensure that  the passenger count and bag count for any given flight matches. As  passengers  Check‐In,  the  airline  Departure  Control  System  (DCS)  generates  messages  called  Baggage  Source  Messages  (BSMs),  these  messages  are  subsequently  used  by  the  airport’s  Baggage  Handling  System (BHS) and the BRS.   The BHS uses the BSMs for sorting bags to the different collection  points (or Make‐Up Units) for departing flights.   The BRS uses BSMs for reconciling departing passengers and the bags  that are being loaded onto their departing flight.  A typical BRS works as follows:‐   A passenger  checks‐In for a flight, at  the check‐in counter where the airline staff or their handling agent  prints a boarding pass and a bag tag. The bag tag is attached to the bag  and the boarding pass is given to the passenger.  At the same time that  the bag tag and boarding pass are printed, a BSM is generated for that  passenger.  The generation of the data for the printing of Bag Tags & Boarding  Passes,  including  the  production  of  BSMs  is  all  performed  by  the  Departure Control System (DCS)  [Note: A BSM will contain information such as passenger name, flight  number  identifier,  destination,  transfer  information,  onward  information,  bag  tag  detail,  class  etc.  Although  a  unique  BSM  is  generated  for  each  passenger,  several  items  of  baggage  may  be  associated to a single BSM]. 

Once a BSM has been generated by a DCS, it is then sent to a central  messaging system such as SITA BagMessage or ARINC BagLink which in  turn will forward it onto the BRS and BHS at the airport where the  baggage was originally checked in. Centralized messaging systems such  SITA’s  and  ARINC’s  avoid  having  to  implement  multiple  interfaces  locally into the BRS and BHS. Imagine, if every airline DCS needed to be  directly  interfaced  to  an  airport’s  BRS  and  BHS,  it  would  create  a  nightmare especially in high capacity airports were a large number of  airlines operate.   A  centralized  messaging  system  (e.g.  SITA’s  BagMessage  or  Arinc’s  BagLink) is basically a ‘store’ and ‘forward’ service which offers a high  degree  of  resilience  and  reliability.  In  the  event  of  a  network  connection  failure,  the  centralized  message  system  will  buffer  all  received BSMs so that they can be re‐sent once the network connection  is restored.  The entire process of sending a BSM from a DCS to the BRS and BHS via  a  centralized  messaging  service  under  normal  operating  conditions  takes milliseconds to perform. On receipt of BSMs, the BRS will store  each in its database so that they can be subsequently retrieved and  used for processing as part of the BRS functionalities as and when  required.  Typically, the BRS is composed of the following elements; Application  Servers,  Web  Servers,  Operator  Workstations,  Printers,  Wireless  Scanners, Network Access Points, and a BRS Network.  Application  Servers  –  The  Application  Server  is  where  the  actual  application  software  resides,  normally  for  resiliency  a  primary  and  backup server are used. Additionally, databases are used for storing the 

system data such as data received from other systems through systems  interfaces  and  data  generated  by  the  system  itself.   A  common  database used for this type of system is an Oracle Database. In some  cases  these  databases  can  run  on  separate  servers  other  than  the  application servers. Other software running on the application servers  includes but is not limited to;  • Operating  System  software  –  this  would  be  an  OS  such  as  Microsoft Windows Server 2003  • Database Replication software – for data replication between the  primary & secondary servers  • Data  Backup  software  –  for  backing  up  the  data  within  the  database  • Oracle – database software  • Remote Monitoring & Management software – providing remote  access to the system (e.g. Net Support Manager)   Web  Servers  –  The  application