SAS data afdelingen

Check-in passagerer og bagage i luftfarten gennem 44 år

Begyndelsen:
De første år i SAS foregik det meste manuelt. Passagererne henvendte sig ved check-in skranken med deres bagage og afleverede deres billet. Bagagen blev vejet, antal stykker bagage og vægt blev noteret i billetten, og hvis der var ’seating’ på den pågældende rute (kun oversøiske), kaldte ekspedienten via et samtaleanlæg til ’manifesteringen’, opgav eventuelle ønsker til sædet og fik tildelt en plads, som blev noteret på billet og boardingpass. I manifesteringen blev passagerens navn plus eventuelle noter skrevet på en lille slip, som kunne sættes ind i en plastlomme i en seating mappe. Bagagen blev mærket med manuelt skrevet bagagetag, sat på transportbåndet, og passageren kunne nu gå gennem paskontrollen ind i ventesalen.

Billetkuponen blev med rørpost – befordret af trykluft – sendt til ’logbogen’, hvor en ’fordeler’ spredte kuponerne efter rute nummer til forskellige skriveborde i ’manifesteringen’ via et ’fordelingstransportbånd’.

Den ansvarlige for en given rute noterede passagerens køn, stykker bagage og vægt + evt. vægt af håndbagage på et ’passenger and bagage weight sheet’.

Kort før afgang lukkedes check-in til den pågældende rute, og manifesteringen fik travlt med at opsummere antal passagerer delt op i mænd, kvinder, børn og spædbørn pr. klasse, samt antal stykker bagage og deres vægt + evt. håndbagage, alt sammen selvfølgelig optalt per klasse og destination på ruten. Tallene blev hurtigt givet videre til den trafikmedarbejder, som var ansvarlig for udregning af flyets vægt- og balanceforhold, som blev dokumenteret på et ’loadsheet’. Samtlige dokumenter for flyet blev lagt i ’logtasken’, og trafikmedarbejderen bragte logtasken til flyet, evt. på cykel, henvendte sig til kaptajnen i cockpittet, hvor informationerne blev gennemgået og kaptajnen signerede. Så var der klar til afgang – med mindre der lige skulle tages højde for nogle sene passagerer, så der skulle laves nogle ’last minute changes’ (LMC) på loadsheetet.

Når flyet var rullet væk fra standpladsen, var der en hel del arbejde med at samle og videresende oplysninger til næste station på ruten: information om den totale last på flyet, hvilke lastrum bagage, fragt og post lå i til de forskellige destinationer, hvor mange passagerer der skulle rejse videre med andre fly, og på visse ruter skulle der sendes TPM eller TPS (navnelister med forskellige ekstra oplysninger), og endelig skulle billetkuponer og andre dokumenter samles i en kuvert til afregningen.

Første skridt i automatiseringen:
I begyndelsen af 60-erne kom den første fase af elektronisk hjælp på plads. Standard Electric Lorenz leverede en regnemaskine ’Zebra’ med radiorør, som blev installeret i ’logbogen’. Til denne regnemaskine blev koblet 3 såkaldte ’mastersets’ placeret i ‘logbogen’ sammen med printere for ’loading instruction’ og ’loadsheet’ til brug for vægt- og balance planering. Desuden blev et større antal ’keysets’ placeret ved check-in skranker i afgangshallen og transithallen forbundet til ’Zebraen’.

Ved hjælp af et antal ’matrix plader’ med forskellig udstansning i højre side kunne check-in ekspedienten vælge rute og segment for en ekspedition. Matrix pladen kunne skubbes ind i keysettet, og når ekspedienten med ’koordinattaster’ havde valgt rute og segment, kunne han/hun ved hjælp af få taster angive klasse, passagertype, bookingstatus, antal passagerer og stykker baggage (evt. vægt) og gennemføre registrering af check-in. Svaret til keysettet var en eller flere lysende lamper – grøn for OK, rød for afvist (flyet fuldt) og gult med et par tallamper angav ’standby’ og reference nummer.

Man behøvede ikke længere manuelt at notere og opsummere antallet af passagerer og mængden af bagage, men kunne kort før afgang ’lukke’ flyet og printe det færdige loadsheet ud.

Zebraen betjente kun København og kørte ikke i døgndrift, men blev hver morgen ’madet’ med dagens trafikprogram via papirtape, hvorefter ekspedition til dagens fly kunne påbegyndes.

Andet skridt.
Omkring 1965 blev Zebraen erstattet af en IBM 1410 maskine, som var blevet programmeret til at kunne det samme som Zebraen – og en hel del mere, bl.a. var automatiseret balanceberegning var kommet til.

IBM 1410-eren kørte stort set i døgndrift, og trafikprogrammet blev ikke – som med Zebraen – fyldt i computeren hver morgen, men kun to gange om året. Desuden kunne man med 1410-eren betjene andre lufthavne end København, så Stockholm og Oslo (og måske Göteborg) kom til.

Registrering af check-in skete fortsat via keysets og kun numerisk.

Allerede dengang var det muligt at checke-in til flere ruter i en omgang. København var udgangspunktet for de fleste ruter til byer i Europa, og ved check-in f.eks. i Stockholm på en lokal rute til København kunne ekspedienten kombinere check-in på SK403 STOCPH med SK635 CPHFRA, så SAS kunne ’spare’ på check-in personalet i CPH.

Denne form for numerisk check-in fortsatte efter IBM 1410 tiden fra 1969 på Univac 494. Univac 494 blev ikke videreudviklet af Univac (senere Unisys). Det blev 1100-serien, som fortsat blev udbygget med fremtiden for øje – Univac 494 blev dømt ude af drift i midten af 70-erne, men sådan skulle det ikke gå. Et nyt reservations system blev udviklet af Univac/Unisys i samarbejde med et antal luftfartsselskaber (heriblandt Lufthansa og SAS) på computere af 1100-typen, og det lykkedes v.h.a. software at få 1100 til at kunne operere i 494-mode. På den måde kunne metoden for numerisk check-in fortsætte med større og mindre ændringer og forbedringer.

Tredje skridt.
Undervejs blev keysets udskiftet med VDUer (Visual Display Units), men man fortsatte med kun numerisk registrering af passagerer og bagage – bl.a. for at bibeholde et minimum af taste anslag. Den langt mere fleksible terminaltype muliggjorde imidlertid, at ekspedienterne ved check-in skrankerne fik tilgang til meget mere information, både fra reservationssystemet og fra andre operationelle systemer.

Seating processen ændrede sig også i løbet af årene. Metoden med en seating coordinator i manifeste-ringen begrænsede seating til få (oversøiske) ruter. For at gøre dette mere fleksibelt (og spare mandskab) prøvede man med nogle store seatmaps opsat på stander ved gaten, hvor passagererne selv kunne vælge blandt ledige sæder, knipse seat stubben af og klæbe den på boardingpasset. Det medførte selvfølgelig, at der tæt på afgangstid stadig var et tilstrækkeligt antal ledige sæder, men det var enkelt sæder spredt over hele kabinen, så det var vanskeligt/umuligt at finde samlede seats til f.eks. familier med børn. I første omgang førte det til, at den ansvarlige ’gatemanager’ ’reserverede’ et antal seats samlet (tog bort seat stubs), så man stadig kunne tilgodese familier, som kom relativt sent til udgangen. Systemet med de store seatmaps blev erstattet af et med mindre seatmaps, som blev betjent af ’gatemanageren’ og ikke af passagererne selv.

I slutningen af 70-erne blev et system for automatisk seating og udskrivning af boardingpass udviklet og implementeret. Ved check-in skranken kunne ekspedienten sammen med den numeriske check-in transaktion angive sæde ønske (enten i form af en eller flere ’options’ eller som specifikt sæde). Systemet fandt så sæder svarende til de angivne options og ændrede status fra ’available’ til ’occupied’, alternativt verificerede at de angivne sæder var ledige med tilhørende ændring af status. Display af seatplan var også mulig på skærmen, så ekspedienten kunne vejlede passageren. Boardingpasses for en eller flere ruter med rutenummer, destination, seat o.s.v. blev så automatisk printet, og billetkuponen blev lagt ind i boardingpass, så passageren selv bar rundt på sit rejsedokument. Men der var stadig ikke nogen maskinel registrering af relationen mellem en navngiven passager og et specifikt seat.

Fjerde skridt.
Under trusselen om, at Unisys 1100 ikke kunne forventes at fortsætte emulering af Univac 494 blev udvikling af et nyt PALCO 2 system søsat i begyndelsen af 80-erne.

Computeren skulle være Tandem Non Stop, som Linjeflyg havde haft relativt stor succes med. Det krævede en del omskoling af os EDB-folk, og en projektgruppe bestående af repræsentanter for hovedstationerne og Data Services blev etableret i København. Det skulle være et system med fuld udnyttelse af informationerne fra reservationssystemet om passagerernes navne, sædeønsker, videre rejse, specielle noter o.s.v., og systemet skulle omfatte både check-in, loadcontrol, loadplanning og post departure håndtering – altså den ’forgyldte løsning’ på automatisering og rationalisering af håndteringen af passagerer, bagage, fragt og post i lufthavnene. Og systemet skulle kunne implementeres overalt, hvor det fandtes hensigtsmæssigt.

Efter et par år blev projektet imidlertid skrottet på beslutning af Jan Lapidoth. Vi havde fået beskrevet en masse god funktionalitet, men der var endnu lang vej til et kørende system. Nedlæggelsen af projektet fjernede dog ikke behovet for et mere moderne check-in system med registrering af passagerernes navne og tilhørende information til rationalisering af forretningsgangen i lufthavnene.

Så i stedet blev det besluttet at udvikle et midlertidigt og skrabet system på Unisys 1100 platformen, som skulle fungere i 1-2 år – indtil man havde fundet den endelige fremtidige løsning. De væsentligste funktioner på passager området fra PALCO 2 blev identificeret, og en ’skrabet’ udgave af et system til ’name check-in’ blev taget frem – stadig baseret på fuld udnyttelse af allerede registreret passager information fra reservationssystemet og med hele ’post departure’ håndteringen. Loadcontrol (vægt og balance) skulle fortsat køre uforandret som Univac 494 emuleret på 1100, mens ’name check-in’ skulle nyudvikles som et rigtigt 1100 system – med fuld integration til det gamle loadcontrol; men p.g.a. den skrabede model skulle mest mulig eksisterende funktionalitet bibeholdes. F.eks. forblev hele seating funktionaliteten i 494-emulering, så det blev nødvendigt at udvikle et program i 1100 mode (36 bits per ord), som kunne læse og opdatere en record i 494-mode (30 bits per ord).

Systemet havde en kort udviklingstid (omkring 1 år) og blev implementeret gradvis fra begyndelsen af 1985.

Og siden ….
Beslutningen om den endelige fremtidige løsning lod vente på sig, men det gjorde behovene for fornyelser og forbedringer ikke, så efterhånden ’glemte’ man målsætningen om en overgangsfase og meget kort levetid for ’name check-in’. Så nu i 2007 – 22 år senere – lever PCI stadig, om end som et meget udbygget og moderniseret check-in system.

Loadcontrol systemet er undervejs blevet genudviklet i forbedret form som et IBM system.

Følgende er en liste over funktionalitet, som – i tillæg til stadige forbedringer – er kommet til i PCI systemet siden implementeringen:

  • Seating funktionaliteten er blevet genudviklet i 1100 mode og væsentlig forbedret og moderniseret.
  • Automatisk printning af bagagetags med tilhørende afsendelse af BSM  til sorteringsanlæg.
  • Såkaldt ’retur check-in’ i forbindelse med endags rejser, så ’forretningsrejsende’ allerede ved check-in om morgenen blev forsynet med boardingpass til eftermiddagens returflyvning.
  • Registrering af Eurobonus kort ved check-in og efterfølgende afrapportering. Senere udvidet til at håndtere også andre selskabers ’frequent flyer programmer’.
  • Edifact kommunikation med andre selskabers check-in systemer i.f.m. rejseruter, som involverer flere selskaber med forskellige handling systemer.
  • Formidling af information til immigrationsmyndigheder om ankommende passagerer.
  • Det fulde ’license plate concept’, hvor systemet registrerer hver enkelt bagagetag med rejserute, ejer, og afsendelse af bagage relaterede meddelelser til sorteringssystemer og transfer stationer.
  • E-ticket funktionalitet (electronic ticketing) er kommet til, i første omgang med SAS’s egne E-tickets og senere udvidet til at dække andre selskabers E-tickets.
  • Understøttelse af en række ’Front-ends’ med deraf følgende muligheder for selvbetjening for passagererne, hvor de v.h.a. billetnummer, reservationsnummer, creditcard eller Eurobonus kort selv kan gennemføre check-in i automater, få udskrevet bagagetags og aflevere bagage ved et ’baggage drop’.

Reservation System History in SAS                                                                                                  CPH OCT89/OAS

1958 The first step into automation was taken that year.
SAS purchased an Availability System from Standard Electric Lorenz, which was ‘programmed’ by means of input from a large Master console keyboard.
The user terminal s were also of the push-button type, where an agent by inserting a selected metal-plate into the key-set, and by using the push-buttons to indicate month and date, and one button to indicate selected column and two buttons to indicate selected rows, could get information from the system if the selected flight on the selected segment was open for sale or not. The metal-plate was covered by a piece of paper, where in each row the Flight number and the stations flown were indicated.
The key-set reply was in the form of two lamps above each column, one GREEN and one RED. GREEN was ok to sell up to a maximum of 4 seats, RED was an indication, that the segment in question was fully-booked, and RED/GREEN was an indication, that there were a few number of seats available, and that a ‘NEED’ message was required
If a sale was acceptable, then the agent send a teletype message to Central Space Control indicating flight number, date, segment, number of seats sold, and specified the name of the passenger and other relevant information. If it was a ‘NEED’ message, then the Central Space Control had to reply by yes or no on teletype to the requestor.
Inventory was maintained by band on large Al-size cards, one card for each flight/day in the control period.
No reservation input was possible, the system was for information only
1961 That year SAS introduced a RAMAC 305 from IBM, which was programmable, and the Reservation System was programmed by SAS. The memory in the system consisted of a few working registers and a magnetic drum, on which the program statements were stored, and where a number of working tracks could be used. Each of the 20 program tracks on the drum contained 10 statements, which could be read into a register one statement at a time. It was possible to jump from one program step to another program step on another track be means of directing the jump through an external wiring-panel.
Storage of data was on a magnetic disk consisting of 25 magnetic plates where data was accessed by means of one ‘ARM’ which could be moved on command from disc-plate to disc-plate.
The system accepted input in form of Punch-Cards, which was automatica1ly produced on basis of the above mentioned Teletype Messages with information about seats sold by a particular agent. The Teletype Messages were punched on paper tape, which then were fed into an IBM 047 cardpunch machine for production of a punch-card. The punch-cards were then manually fed into the RAMAC system, where the flight inventory was updated. The System was online only for input from special terminal s at Space Control, where inquiries concerning status of the booking situation could be given, and where updates through the Master Keyboard on the Availability System were given.
The capacity of the System was in the neighborhood of 1500 cards per hour.
The same old push-button key-set were still in use.
 

 

The punch-cards were after use on the RAMAC system stored in a file cabinet, and used to produce name lists on the flights at request from Space Control.
1965 The follow-on System to the RAMAC 305, an IBM 1410 dual system, for Reservations as well as Load Control, was introduced. The system was programmed in Autocoder, and was a leap forward in technology, and for the first time it was possible from the same old Key-sets to book directly on the System, followed by a Teletype Message as before, but now fed directly into the system, where the Names were updated to the System automatically
The time lack between the booking of the seat from the keyset and later update of the Names, forced Central Space Control to frequently compare number of Names to number of seats sold.
Central memory consisted of 64 Kbytes, of which the operating system occupied approx 15 Kb. The major part of the reservation system was resident in memory and additional program modules could be added in 3 separate working areas.
Storage of DATA was performed on disk, where we now had one ‘ARM’ fixed per plate, and that reduced access time considerably. At this time we also introduced dual storage of safety reasons for the first time.
1967 On 08NOV that year, SAS ordered the follow-on System, based on UNIVAC 494. Three systems were ordered, one for Reservations, one for Load Control and one as fall-back.
The operating system was standard UNIVAC, but in order to introduce online processing, we had to have a Transaction Monitor System (TCS) developed. This was designed by SAS with assistance from a US-Consultancy firm, and developed by UNIVAC
Storage was now back again to DRUMS, where three different types were introduced. One type rather small in capacity with an access time in 4.5 msec, a medium size with an access time of 17.5 msec and the large size with access time about 35 msec.
We started development with the intention to convert the old system functions to the new technology, with very little additional functionality, in principle still an inventory system.
The system was finally introduced in JAN69, and was by SAS intended to be used for online as well as all batch applications in SAS. The intention was to utilize the surplus capacity during evenings, nights and weekends for this production.
The first system developed and implemented was the Batch Accounting System (ACS) for the entire company.
1974 The 494 RES-system was in this year enhanced with full-PNR capability by introducing VDU Screens as replacement for the old keysets. Replacement of key sets by VDU’s was performed over the next 3-4 years.
1975 In that year automatic Ticketing was developed and introduced.
1976 In this year SAS introduced an own developed Passenger Accounting System (PAS).
UNIVAC then, to our surprise, de-committed the 494 equipment-line in favor of the 1100 equipment-line. The 1100 equipment line was different from 494, so SAS was forced to start looking for a replacement to 494.
The decision by UNIVAC was bad for SAS but understandable seen from UNIVAC business point of view, as the 1100 line had proved more acceptable to the industry than the 494, even if the 1100 line in the beginning was intended for scientific use only.
1977 SAS decided to continue with UNIVAC on the 1100 line of equipment, but intended to have UNIVAC to develop the new reservation system based on requirements from the user community. SAS together with Lufthansa, North West Airlines and a few other smaller Airlines, developed a set of requirements based on which the USAS*systems should be developed
SAS had during the 3 year development period, data personnel stationed in Minneapolis participating in and monitoring this development
The system was moved to CPH late 1979 for final SAS enhancements and acceptance test and implemented in March 1980
The system has since been maintained and further developed by UNIVAC in Minneapolis, but no new versions of USAS*, except one for USAS*TKT, have ever been introduced in the SAS environment.
The reason for this was caused by OUT being the first to introduce the standard USAS*Systems. During the intense acceptance test period in CPH, all errors found was corrected by SAS and UNIVAC on site, and the error report was then forwarded to Minneapolis for inclusion into the standard system. We corrected several thousands errors but the majority of errors was rejected by Minneapolis, they said they could not reproduce the error on their own system. Therefore the difference between OUT version and their version grew to such proportions, that we didn’t dare to start all over again with the standard system.
During the following years, where the demand for compute power grew and grew, it created problems on several occasions for SAS. Every time we were on the brink of inadequate compute power, we had to use unorthodox methods to survive. The hardware plans in UNISYS were late and not always in time, and this has added to the determination to look for a replacement.

 

Hardware oversigt Udfærdiget af OAS
ÅR SYSTEM HARDWARE
1958 S E L ( A / S AVAIL) SPAS Standard Electric
1961 RAMAC (RTPR, NAMES ON CARD) Zebra, CHECK IN Standard Electric ,
I B M 3 O 5, Z E B R A computer
1965 SASCO I Implemented 01feb65 RTPR, names stored, ZEBRA A/S book/cnl IBM 1410
08nov67 S A S C O  I I  ordered UNIVAC 494
1969 S A S C O  I I   refinements UNIVAC 494
JUN 1969 till 1972 SOLAR, development (24 trips to ATL) implementation JAN/FEB 72. PNR system Mod. IBM 50 – 100 my UNIVAC 3 x 494 + 3 x 418
SEP 70 P 70 established
FEB 71 RFP IBM/CDC/UNIVAC (NW) SOLAR, SCM FEB/MAR, P. TORRA, SSM; MAGAR, PBE, BORL, EDB, FRANK
MAY1973 CRT’s SPC, CHANGE OLD SYS. GROUP ESTABLISHED IN 1972
DEC 1973 PNR (savings several mils.) 3 Phases: AIRIMP/SCR, 10 prgs. 5 6 / 2 0 PRGS./PNR 37/4 + 40/40. 17 OLD FILES CONVERTED TO 12 NEW FILES
JAN 1974 Sell. Off. B E F O R E scheduled day proj. grp. Max 20 (12 danes + 8 consulenter)
JUN 1974 START COOPER. With UNIVAC (since then I made 9 trips MSP + 2 mtgs CPH. MAY 75 PAD-MSP
MAY1976 PAS/CPH SASCO/UNIVAC 494
JUN 1976 1000 TERMINAL INCL. TA’s
SEP/OCT 1976 STO/OSL/BGO/GOT etc. TICS/PAS
SEP1977 DCP UNIVAC
SEP 1978 DCP 3760 UNIVAC 1100/83 TELCON
08MAR80 1180/USAS MODIFIED MUCH