Preface
The Open Group
The Open Group is a global consortium that enables the achievement of business objectives through technology standards. Our diverse membership of more than 600 organizations includes customers, systems and solutions suppliers, tools vendors, integrators, academics, and consultants across multiple industries.
The Open Group aims to:
- Capture, understand, and address current and emerging requirements, establish policies, and share best practices
- Facilitate interoperability, develop consensus, and evolve and integrate specifications and open source technologies
- Operate the industry’s premier certification service
Further information on The Open Group is available at www.opengroup.org.
The Open Group publishes a wide range of technical documentation, most of which is focused on development of Open Group Standards and Guides, but which also includes white papers, technical studies, certification and testing documentation, and business titles. Full details and a catalog are available at www.opengroup.org/library.
This Document
This document is The Open Group Commercial Aviation Reference Architecture. It has been developed and approved by The Open Group as a Preliminary Standard.
This standard is being published initially as a Preliminary Standard since it addresses an emerging area of best practice; therefore, it may change before being published as a full-use standard of The Open Group. In such a case, it will be made as upwards-compatible as possible with the corresponding Preliminary Standard, but complete upwards-compatibility is not guaranteed.
An ArchiMate® model has been created by The Open Group as a supporting artifact for this Preliminary Standard. This is available online at: http://pubs.opengroup.org/aviation/comm-aviation-ra-preliminary/.
Trademarks
ArchiMate®, DirecNet®, Making Standards Work®, OpenPegasus®, Platform 3.0®, The Open Group®, TOGAF®, UNIX®, UNIXWARE®, and the Open Brand X® logo are registered trademarks and Boundaryless Information Flow™, Build with Integrity Buy with Confidence™, Dependability Through Assuredness™, Digital Practitioner Body of Knowledge™, DPBoK™, EMMM™, FACE™, the FACE™ logo, IT4IT™, the IT4IT™ logo, O-DEF™, O-PAS™, Open FAIR™, Open O™ logo, Open Platform 3.0™, Open Process Automation™, Open Trusted Technology Provider™, SOSA™, and The Open Group Certification logo (Open O and check™) are trademarks of The Open Group.
Amadeus® is a registered trademark of Amadeus IT Group, SA.
BPMN™ and Business Process Modeling Notation™ are trademarks of Object Management Group, Inc. in the United States and/or other countries.
CPLEX® is a registered trademark of IBM in the United States.
Etix® is a registered trademark of Etix.com, Inc.
IATA® is a registered trademark of International Air Transport Association.
Oracle® is a registered trademark of Oracle Corporation and/or its affiliates.
All other brands, company, and product names are used for identification purposes only and may be trademarks that are the sole property of their respective owners.
Acknowledgements
The Open Group gratefully acknowledges the contribution of the following people in the development of this standard:
- Meng Fei, Air China
- Christopher Frost, Fujitsu
- Garikoitz Garcia, IAG GBS Ltd.
- Liu Jingli, China Eastern Airlines
- Mercedes Pantoja, IAG GBS Ltd.
- Kai Schroeder, Capgemini
- Eldar Sultanow, Capgemini
Referenced Documents
The following documents are referenced in this standard.
(Please note that the links below are good at the time of writing but cannot be guaranteed for the future.)
Normative References
Normative references for this standard are defined in Section 1.4.
Informative References
- IATA® Cargo iQ Master Operating Plan (MOP): www.iata.org/whatwedo/cargo/cargoiq/Pages/master-operating-plan.aspx
-
IATA® Freight Forwarder – Carrier – Ground Handling Agent Communication Functional Specifications:
www.scribd.com/document/264494839/IATA-Agent-Carrier-handling-Comm -
IATA® Ground Operations Manual:
www.iata.org/publications/store/Pages/iata-ground-operations-manual.aspx -
IATA® Industry Data Model:
www.iata.org/whatwedo/passenger/Pages/industry-data-model.aspx -
IATA® New Distribution Capability:
www.iata.org/whatwedo/airline-distribution/ndc/Pages/default.aspx -
ICAO/TCB Procurement Procedures and Mechanisms:
www.icao.int/APAC/Meetings/2013%20CRVTF1/WP07_ICAO%20AI3%20-%20ICAO_Revised%20TCB%20Procurement%20Procedures%20and%20Mechanisms.pdf
1.1 Objective
This standard is the specification of The Open Group Commercial Aviation Reference Architecture, Version 1.0, a standard of The Open Group. It is being published as a Preliminary Standard. It describes a reference architecture that can be used to provide a common taxonomy and basis for Enterprise Architecture for the commercial aviation industry.
1.2 Overview
The Open Group Commercial Aviation Reference Architecture is a standard reference architecture for the commercial aviation industry, covering the following domains:
- Product
- Sales
- Network & Fleet Planning
- Ground Operations (Ops)
- Revenue Management & Pricing
- Flight Operations (Ops)
- Marketing & Customer Care
- Cargo
- Maintenance
- Support
The standard includes a metamodel and Business, Application, Data, and Technology Architecture descriptions for each of the domains.
1.3 Conformance
Readers are advised to check The Open Group website for any conformance and certification requirements referencing this standard.
1.4 Normative References
The following standards contain provisions which, through references in this standard, constitute provisions of The Open Group Commercial Aviation Reference Architecture. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. Members of IEC and ISO maintain registers of currently valid International Standards.
- The TOGAF® Standard, Version 9.2, a standard of The Open Group (C182), published by The Open Group, April 2018; refer to: www.opengroup.org/library/c182
1.5 Terminology
For the purposes of this standard, the following terminology definitions apply:
Can Describes a possible feature or behavior available to the user or application.
May Describes a feature or behavior that is optional. To avoid ambiguity, the opposite of “may” is expressed as “need not”, instead of “may not”.
Shall Describes a feature or behavior that is a requirement. To avoid ambiguity, do not use “must” as an alternative to “shall”.
Shall not Describes a feature or behavior that is an absolute prohibition.
Should Describes a feature or behavior that is recommended but not required.
Will Same meaning as “shall”; “shall” is the preferred term.
1.6 Future Directions
This document will be further revised to become a full-use standard.
The next version is anticipated to include (but not be limited to) the following improvements:
- Increased transparency of cross-domain aspects
Some capabilities, such as safety and security, span multiple domains. This will become more transparent by providing a better end-to-end view.
- Detailing domains
Aircraft security/safety will be considered across domains, since it is not only a pre-planning activity in Flight Operations. It will be included in Cargo (screening of cargo, load planning, etc.), in Ground Operations (to seal the aircraft for overnight stops), and in Maintenance, etc. Service quality will be treated as a cross-domain capability as well and therefore included in Sales and Marketing & Customer Care.
- Enhanced technology architectures
In the current version the Technology Architecture provides a basic simplified overview; the next version will include a detailed description.
For the purposes of this standard, the following terms and definitions apply. For Enterprise Architecture-related terms the TOGAF® standard should be referenced. All other terms are as defined in the Merriam-Webster’s Collegiate Dictionary.
This chapter describes the metamodel used throughout the standard to define the reference architecture. The metamodel is defined for each of the four architecture domains defined.
3.1 Business Architecture
Symbol |
Element |
Business Domain (top-level element) |
|
Subdomain (assigned to a Business Domain) |
|
Business Capability (assigned to a Subdomain) |
|
(BPMN[1]) Starting State and End State |
|
(BPMN) Activities of a business process (can be chained) |
|
(BPMN) An artifact (document, table, item, …) that is input or output of an activity and that relates to an Information Object |
3.2 Application Architecture
The Application Architecture (see the TOGAF standard, Section 2.3) “provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization”. This standard maps capabilities to the applications, which enable these capabilities.
Symbol |
Element |
Application covers/possesses one or more Business Capabilities |
3.3 Data Architecture
Symbol |
Element |
Entity describing a Data Object |
|
Information Object encompassing Entities |
|
Relations between Entities and Information Objects |
3.4 Technology Architecture
Symbol |
Element |
Technology (Infrastructure) Component; these can be nested hierarchically |
3.5 Business Domain Model (Top-Level)
The Business Domain Model is the modeling starting point and the highest-level model type. It shows the business domains and clusters the subdomains into these business domains.
3.5.1 Business Capability Map of Business Domain 4
For each business domain a Business Capability Map exists. This map assigns to each subdomain all belonging business capabilities.
3.5.2 Map of Subdomain 4.2 Capabilities to Applications
The business capabilities are mapped to the applications, which cover/possess these capabilities.
3.6 Technology Model
Technology Components (e.g., platforms, databases, infrastructure components, …) are clustered by subdomains and may be the underlying basis of applications.
3.7 Business Process Model
For each business domain a Business Capability Map exists. This map assigns to each subdomain all belonging business capabilities.
3.8 Entity Relationship Diagram
Entities (Data Objects) and Information Objects relate to each other. They can be nested hierarchically and have attributes.
The commercial aviation business domains consist of the following subdomains, as shown in Figure 1.
Figure 1: Overview of Business Domains
The Data Architecture is structured by means of a core model and extensions for specific business domains. The core model contains and describes the top-level business objects for the commercial aviation industry. Specific extensions add information objects to the core model for the sake of clarification and more detailed consideration. Figure 2 gives an overview of the core model entities.
Figure 2: Overview of Data Architecture Core Model Entities
Customers contact a point of sale, such as a travel agent, via sales channels in order to purchase commercial aviation products. Products can be tickets for passenger flights as well as contingents for cargo.
A passenger is a customer in person holding a valid ticket for a specific flight for which baggage is allowed. A flight is an abstract entity that consists of flight legs, the actual air travel between departure and arrival airport.
Airlines manage a network of flights in certain regions or globally. The network is periodically re-organized, reduced, or extended according to customers’ demand. Codeshares are used to organize co-operations between airlines.
An aircraft usually is part of a fleet operated by the airline and in case of passenger flights offers seats according to a given seat map. Crews are assigned to a flight which is serviced by a specific aircraft.
Table 1 provides a description of the Data Architecture entities.
Table 1: Data Architecture Entities
Entity |
Description |
Aircraft |
An aircraft is a machine that flies between airports carrying passengers and freight. |
Airport |
An airport is an aerodrome including a suitably large area for take-offs and landings of aircrafts as well as buildings to operate flights. |
Baggage |
Baggage or luggage is what a passenger is allowed to carry on a flight. |
Codeshare |
A codeshare is a commercial aviation business arrangement where two or more airlines share the same flight. |
Crew Rotation |
A crew rotation is a team of commercial aviation staff actually servicing a flight. |
Customer |
A customer is a company or human being doing business with the airline. |
Fleet |
A fleet is the sum of an airline’s operating, planned, and retired aircrafts. |
Flight |
A flight is a logical combination of flight legs. A passenger can have ticket for a flight. |
Flight Leg |
A flight leg or flight segment is a section of a flight that connects the departing and arriving airport. |
Freight |
Freight or cargo are goods stored in various containers being transported by an aircraft. |
Network |
The network is a list of all planned regularly operated flights of an airline. |
Passenger |
A passenger is a customer holding a specific valid ticket. |
Point of Sale |
The point of sale is the time and place where commercial aviation products are sold. |
Product |
A commercial aviation product is an airline’s service for which a customer is willing to pay a price. |
Sales Channel |
A sales channel is the communication and transaction mechanism for point of sales to sell products to customers. |
Seat |
A seat is a location for a passenger to sit during a flight. |
Seat Map |
A seat map represents the current arrangement of seats in an aircraft. |
Ticket |
A ticket or airline ticket is a travel document to confirm that a passenger has purchased and reserved a seat on a flight on an aircraft. |
This chapter describes each business domain (as shown in Figure 1), its subdomains, and the tasks within each subdomain.
6.1 Product
6.1.1 Subdomains
6.1.1.1 Product Management & Design
Product Management & Design is a subdomain of the Product domain.
Product Management & Design consists of several tasks related to air products, ground products, product strategy, ancillary services, corporate design, and the customer experience.
The following tasks are within the scope of this subdomain:
- Defining and develop the product portfolio and product strategy of Product Ground and Product Air
- Define and develop customer experience onboard for different product parts (i.e., cabin interior, seat and bed, services, In-Flight Entertainment (IFE), and multimedia)
- Define and develop customer experience for products on the ground
- Review and develop the customer experience of all kinds of products such as food and beverages
- Manage corporate design and branding of the company
6.1.2 Business Architecture
Figure 3: Business Capability Map of the Product Domain
Table 2: Product Domain Business Capabilities
Domain |
Service Name |
Objective |
Product Management & Design |
Manage Ancillary Services |
Handles and manages all ancillary systems and services. |
Manage Product Ground |
Manages all ground product-related activities such as lifecycle management, planning, forecasting, or marketing of products at all stages. |
|
Manage Product Air |
Manages all air product-related activities such as lifecycle management, planning, forecasting, or marketing of products at all stages. |
|
Define Product Portfolio Strategy |
Defines and develops product portfolio and product strategy. |
|
Manage Corporate Design |
Defines corporate design and branding. |
|
Manage Customer Experience |
Defines and develops customer experience onboard for cabin interior, seat and bed, services, and customer experience of food and beverage. |
Figure 4: Product Domain Business Process
In Figure 4 the business process and extracted information objects of the Product domain are depicted. The business process begins by defining the product strategy. For that product, data, requirements, and market information are composed. In the Product & Service Design phase all the necessary product components are designed and subsequently developed for production. In this phase the Customer Experience, Product & Service, and Corporate Design are defined. The Offering represents offered Air Products, Ground Products, and Services which are managed according to the Product Management catalog. Product & Services descriptions and guidelines help staff to maintain a high product quality to ensure superb customer experience. In the last step the Product domain is also responsible for Product Quality and creates several reports and monitors the systems data.
6.1.3 Data Architecture
Figure 5: Data Model of the Product Domain
Figure 5 describes the relationship of information objects and entities within the Product Management & Design domain. The data model of the Product domain places most information objects within the Product Management and Offering objects, where Product Management is directly related to Offering. Product & Service Descriptions are defined in the Service and Air/Ground Products entities.
6.1.4 Application Architecture
Figure 6: Mapping Capabilities to Applications
Note: Business capabilities may be covered by applications at a finer granularity level than the business capabilities summarized in the business view. In such a case this will lead to the Application Architecture having more detailed capabilities relating to the capabilities in the Business Architecture.
6.1.5 Technology Architecture
Figure 7: Technology and Platforms within the Product Domain
Regarding the Technology Architecture, the Product Management Applications have the following responsibilities. The Applications are applied for developing products and services. They receive corporate product strategy and include corporate design requirements, and are responsible for designing customer experience throughout the product and service lifecycle. Furthermore, they receive new services and products based on the corporate strategy and customer data based on requirements, which they receive from various departments. The reporting and communication is done using internal analytics and communication tools. Furthermore, the Media System is the tool for managing IFE and multimedia systems.
6.2 Sales
6.2.1 Subdomains
6.2.1.1 Inventory Management
Inventory Management is a subdomain of the Sales domain.
The following tasks are within the scope of this subdomain:
- Manage all flight-related inventory restrictions/allotments; e.g., available seats, capacity left for Special Service Requests (SSRs), such as special food requirements, wheelchair, seat at window, etc.
- Manage all flights with their available seats and divide seats into service classes and booking classes, for which different prices and booking conditions apply
- Distribute schedules
6.2.1.2 Sales Channel Management
Sales Channel Management is a subdomain of the Sales domain.
The following tasks are within the scope of this subdomain:
- Set up the sales channel strategy, including B2B, agent, direct sales, agencies, etc.
- Define sales channels, agents, company business, and group travel
- Responsible for Account Management, which analyzes and monitors B2B customer relationships, maintains B2B data, and provides the B2B customer care function and processes
6.2.1.3 Reservation Ticketing
Reservation Ticketing is a subdomain of the Sales domain.
The following tasks are within the scope of this subdomain:
- Provide interfaces to external Global Distribution Systems (GDS), such as Amadeus®[2] and independent online sites; the interfaces comprise technical functionality required to communicate with external systems, but not the GDS business functionality itself
- Enable call center agents to sell the airline’s product(s) and services, to inform customers, sell tickets to customers, and provide services, such as ticket/EMD issuing, rebooking, reissuing, refunding, etc.
- Manage reservations and ticketing; i.e., preparation of Etix® tickets, issuing of paper tickets, EMDs, rebooking, reissuing, refunding, and collection of payments
- Provide a direct connect interface to third parties
6.2.1.4 Direct Sales Channel & Shopping
Direct Sales Channel & Shopping is a subdomain of the Sales domain.
The following tasks are within the scope of this subdomain:
- Provide direct sales channels and be responsible for the search of products (i.e., flight products and bundles)
- Create offers (including ancillaries) and reservations and handle the (re)book and order
- Responsible for ancillary services, cross-selling, up-selling, product bundling, and providing a shopping cart
6.2.1.5 Sales Agent Channels
Sales Agent Channels is a subdomain of the Sales domain.
The following tasks are within the scope of this subdomain:
- Provide all sales channels and allow sales agents to sell products (indirect/direct sales, domestic/international, online/offline, and group sales)
- Allow the corporate sales account to sell products (to business, domestic/international, online/offline, and group sales)
- Provide sales data reports and statistics for agents
6.2.2 Business Architecture
Figure 8 depicts the business capabilities grouped by subdomains of the Sales domain.
Figure 8: Business Capability Map of the Sales Domain
Table 3 lists and describes the business capabilities of the Sales domain.
Table 3: Sales Domain Business Capabilities
Domain |
Service Name |
Objective |
Inventory Management |
Manage Seat Inventory |
Manages the seat inventory. |
Manage Wait Lists |
Manages the internal waiting lists. |
|
Distribute Schedule |
Distributes schedules to the various stations served by the airline. |
|
Manage Flight-related Availability Restrictions |
Manages all incoming flight-related availability restrictions. |
|
Reservation Ticketing |
Search Flight |
A flight search consist of search criteria and additional information, like personalized context, and returns availability, fares, and flight-related ancillaries. |
Search Basic Flight |
Collect and delegate search parameters to Flight Offer Component. |
|
Search Multistop Flight |
A multi-stop flight is simply a group of basic flights, excluding return and repeated flights. |
|
Search Rebook Flight |
Search for flights like basic search but added with information of rebooking to fare calculation. |
|
Create Reservation |
The user can book a refundable flight. |
|
Execute Book On Hold |
The user can select a flight for reservation. This process executes the debit and the creation of the reservation. |
|
Service List |
An IATA® NDC API-comparable service to provide ancillaries for the flight(s). |
|
Direct Sales Channel & Shopping |
Search And Offer Product |
Responsible for the search and availability of products. |
Create Reservation |
Based on a user’s inquiry, creates a reservation. |
|
Manage Order |
Manages the incoming order inquiries. |
|
Manage Booking |
Manages the incoming booking inquiries. |
|
Sales Agent Channels |
Define Sales Channel Strategy |
Defines the sales strategies for each channel. |
Manage Sales Channel |
Responsible for operations and overview of a sales channel. |
|
Report Sales Agent Statistics |
Provides relevant statistics and analytical reports. |
|
Manage Sales Agents |
Manages the responsible sales agents. |
|
Manage Sales Accounts |
Manages the sales account. |
Figure 9: Sales Domain Business Process
In Figure 9 the business process and extracted information objects of the Sales domain are depicted. The business process begins by defining the sales channel strategy. The required documentation, fare information, and account responsibilities are created there. Within the Inventory Management, seat inventory, waiting lists, and recurring ticket/booking statuses are produced. Subsequently, Sales channel Key Performance Indicators (KPIs) and coordination and sales guidelines are defined. Within the sales process, reports are created. The Sales domain is also responsible for the reservation of tickets. Therefore, it needs to overview the booking and ticket status.
6.2.3 Data Architecture
Figure 10: Data Model of the Sales Domain
Figure 10 describes the relation of information objects and entities within the Sales domain. The Fare and Price of the tickets are directly related to the offering. The Price also relates to the available booking and service classes. In this model the customer resolves to a passenger who is related to a reservation, booking, and the acquired Ticket. The Ticket is related to the Seat Map which includes Seats.
6.2.4 Application Architecture
Figure 11: Mapping Capabilities to Applications
6.2.5 Technology Architecture
Figure 12: Technology and Platforms within the Sales Domain
Note: Although the Technology Architecture and Application Architecture are similar, there is still a significant difference between the two – the Application Architecture shows applications and the Technology Architecture shows the underlying technologies that enable these applications to operate.
6.3 Network & Fleet Planning
6.3.1 Subdomains
6.3.1.1 Fleet Planning
Fleet Planning is a subdomain of the Network & Fleet Planning domain.
The following tasks are within the scope of this subdomain:
- Plan the future fleet size and the needed capacity and composition, as well as the configuration need and the delivery schedule
- Support processes around aircraft sourcing and Entry Into Service (EIS)
6.3.1.2 Network Management
Network Management is a subdomain of the Network & Fleet Planning domain.
The following tasks are within the scope of this subdomain:
- Design Network Management and optimize airline’s flight network regarding bases, destinations, routes, and frequency of flights between the destinations to optimize yield and profitability
- Evaluate partner potential and opportunities concerning network and slots, sales and markets, product, alliances
6.3.1.3 Network Data Analysis
Network Data Analysis is a subdomain of the Network & Fleet Planning domain.
The following tasks are within the scope of this subdomain:
- Analyze market and customer data and prepare database to facilitate network planning and scheduling process
- Gather data to allow analyses to understand and predict historic and future schedule preferences of customers
- Gather actual flight-related cost data and provide predictions of cost figures for subsequent analysis processes
- Create Origin and Destination (O&D) view on customers’ movements
- Feed data into revenue/yield management and network planning processes to improve various optimizers
6.3.1.4 Co-operations & Alliances
Co-operations & Alliances is a subdomain of the Network & Fleet Planning domain.
The following tasks are within the scope of this subdomain:
- Provide reporting and accounting for alliances and joint ventures
6.3.1.5 Scheduling Codeshare
Scheduling Codeshare is a subdomain of the Network & Fleet Planning domain.
The following tasks are within the scope of this subdomain:
- Define schedules including flights, timings, and aircraft type for periodical and fully dated flight schedules
- Manage slot assets and contracts with AOL
- Negotiate slots in IATA slot conference and enrich codeshare information
- Publish flight plan and distribute flight plan to various systems (CRS, internal)
6.3.2 Business Architecture
Figure 13: Business Capability Map of the Network & Fleet Planning Domain
Table 4: Network & Fleet Planning Domain Capabilities
Domain |
Service Name |
Objective |
Scheduling Codeshare |
Manage Slots |
Negotiates slots in IATA slot conference. |
Publish Flight Plan |
Makes the current flight plan available to internal and external consumers. |
|
Manage Codeshares |
Manages slot assets and contracts with AOL. |
|
Assign Fleet |
Assigns the appropriate fleet to the published flight plan. |
|
Optimize Schedule |
Optimizes the schedule with respect to customer satisfaction and profitability at the same time. |
|
Network Data Analysis |
Analyze Market Data |
Analyzes markets based on internal and external facts and sources. |
Gather Historic Sales Statistics |
Collects internal and external historic facts and figures on actual sales. |
|
Gather Flight Costs |
Collects the actual costs generated by individual flights. |
|
Model O&D Insights |
Analytical model of the flight plan. |
|
Provide O&D Insights |
Analyzes Flight Plan Data according to model to gather requirements for next flight plan schedule. |
|
Network Management |
Design Flight Network |
The process of designing a future flight network based on the current set-up and influenced by market demands and partners’ capabilities. |
Manage Commercial Partners |
Supports the process of managing existing partnerships, onboarding new ones, and hibernating less productive ones. |
|
Optimize Flight Network |
Optimizes plans for future flight networks by simulating variations and finding potential optimums. |
|
Co-operations & Alliances |
Report Alliances And Statistics |
Generates and publishes reports about operational and financial aspects of business with alliance members. |
Report Joint Venture Statistics |
Generates and publishes reports about operational and financial aspects of the business in joint ventures. |
|
Manage Co-operation Accounting |
Insures the correct accounting of the business with co-operation partners. |
|
Fleet Planning |
Support Aircraft Sourcing |
Supports the business process of aircraft sourcing by delivering the most current demand model for fleet size and time lines. |
Manage Fleet Size |
Determines the adequate size of the future fleet based on customer and market demands. Takes into account the contribution of partners and joint ventures. |
|
Manage Entry Into Service |
Manages the transition of aircrafts from the state of purchased to fully serviceable. |
Figure 14: Network & Fleet Planning Domain Business Process
In Figure 14 the business process and extracted information objects of the domain are depicted. The business process begins by defining the Network & Fleet Planning strategy. It defines the network requirements and calculates the optimal fleet sizes. Within Network Management it compares historical sales statistics and defines commercial partners. Network & Fleet Operations and Network Data Analysis create market data reports, gather flight costs, and several other reports. Within the code sharing process it creates the flight plan, and optimizes the schedule and a code sharing object.
6.3.3 Data Architecture
Figure 15 Data Model of the Network & Fleet Planning Domain
Figure 15 describes the relationship of information objects and entities within the Network & Fleet Planning domain. The Network is directly related to the Flight where the Network is extended by the Codeshare entity.
6.3.4 Application Architecture
Figure 16 illustrates the Application Architecture of the Network & Fleet Planning domain.
Figure 16: Mapping Capabilities to Applications
6.3.5 Technology Architecture
Figure 17: Technology and Platforms within the Network & Fleet Planning Domain
The Technology Architecture consists of multiple applications. Accounting is an application component which uses the transaction infrastructure service for the processing of monetary flows. It is a logical application component for the management of financial accounts of partners and suppliers. The Accounting applications include two infrastructure services, Managing Business Transactions and Managing Enterprise Resources. Managing Business Transactions is used to monitor and manage business transactions. Managing Enterprise Resources is used to effectively distribute resources where they are needed at the right time.
Another application component is Business Intelligence (BI). It is a logical application component for all BI functionality such as reports of historic business data and optional forecasts thereof. The BI applications include several infrastructure services like Data Warehousing, Predictive Analytics, and Providing Data Science. An intelligent business environment includes data warehousing, which is used to analyze data, to extract reports, and to store related data. Predictive Analytics is used to make predictions based on historical data. Lastly, Providing Data Science is an operation about extracting knowledge or gaining insights into various types ofinformation. It is often coupled with similar operations such as statistics, data mining, or predictive analytics and is similar to knowledge discovery in databases.
6.4 Ground Operations (Ops)
Ground Operations handle aircrafts, passengers, and freight on the ground, typically at an airport. The IATA Ground Operations Manual, however, specifically excludes “aircraft maintenance, fuelling, or de-icing tasks” from ground operations. One important effort of ground operation is, after the safety and the quality of service, minimizing the ground time of aircrafts. Since there are many types of ground operation, the reference architecture divides the business domain ground operations into the following subdomains.
6.4.1 Subdomains
6.4.1.1 Station Management
Station Management is a subdomain of the Ground Operations domain. According to the IATA Industry Data Model, station is just a generic term for airport. This subdomain handles the management services and processes at an airport.
The following tasks are within the scope of this subdomain:
- The Management ramp (agent) activity supervises handling of baggage, techniques, freight, food, and cleaning, boarding, deboarding, and (un)loading
- The Management airport information handles and provides information such as minimum ground times, connecting times, and airport master data
- Passenger Streams Management is dedicated to minimizing passenger transfer time and aircraft ground time at an airport
- Equipment Management handles the ground service equipment
- Information to ground handling staff provides global work instructions and irregular information
- Lounges Management handles and analyzes the using of passenger lounges at an airport
- Management of Irregularities recognizes, records, and resolves non-standard situations at an airport
6.4.1.2 Ground Staff Management
Ground Staff Management is a subdomain of the Ground Operations domain.
The following tasks are within the scope of this subdomain:
- Plan ground manpower and carry out shift planning
- Manage activities such as rostering and disposition
6.4.1.3 Passenger Check-In
Passenger Check-In is a subdomain of the Ground Operations domain. The subject of this subdomain is ground operations primarily related to the passenger until they enter the aircraft.
The following tasks are within the scope of this subdomain:
- Manage the check-in and boarding process, including check of reservation versus ticket, documents issuing for boarding pass, vouchers, Etix receipts, includes self-service check-in including baggage (kiosk, web, and mobile)
- Responsible for automatic check-in, interline through check-in processes
- Accept baggage and collect excess fees and fees for additional chargeable services (e.g., ASR)
- Handle passengers on a waiting list and irregularities such as over-bookings and checking documents required for checked-in segments (advanced passenger information, passport, and visa) and transmit data
- Issue vouchers (e.g., meal vouchers, lounge invitations) during regular and irregular operations
6.4.1.4 Load Planning
Load Planning is a subdomain of the Ground Operations domain. The IATA Ground Operations Manual defines ground operations related to loading of an aircraft: load planning, load control flow, and load reporting.
The following tasks are within the scope of this subdomain:
- Responsible for preparing and calculating the electronic load plan and optimizing load planning for aircrafts taking into consideration account load limitations, individual baggage priorities, and dangerous goods restrictions
- Align load process with all neighboring processes; e.g., boarding of aircraft
- Provide load information to ramp agents and to the flight crew
6.4.1.5 Airport Infrastructure
Airport Infrastructure is a subdomain of the Ground Operations domain.
The following tasks are within the scope of this subdomain:
- Provide specific airport infrastructure and processes; i.e., CUTE, CUSS, CUPPS, and QBG
6.4.1.6 Baggage Management
Baggage Management is a subdomain of the Ground Operations domain.
The following tasks are within the scope of this subdomain:
- Reconcile baggage and flights, track baggage, trace baggage, and reunite baggage with owner in case of losses
- Manage loading and unloading activities of the baggage to and from the aircraft
- Manage unloading of baggage of passengers who fail to board the flight
- Redirect baggage that missed a flight and interact with airport baggage management
- Monitor and quality assure baggage processes
6.4.2 Business Architecture
Figure 18 depicts the Business Capabilities grouped by subdomains of the Ground Operations domain.
Figure 18: Business Capability Map of the Ground Operations Domain
Table 5: Ground Operations Domain Business Capabilities
Domain |
Service Name |
Objective |
Passenger |
Check In Passenger |
Registers passenger for a flight. Creates Passenger Information List (PIL) and issues standard check-in messages. |
Board Passenger |
Registers passenger for entering aircraft. |
|
Handle Wait List |
Sets passenger on wait lists based on booking status and airline policy. |
|
Accept Baggage |
Registers checked baggage for a flight. |
|
Issue Vouchers |
Issues vouchers (e.g., meal vouchers, lounge invitations) during regular and irregular operations. |
|
Check Travel Documents |
Checks passenger’s travel documents and places passenger in departure control system according to the IATA Ground Operations Manual. |
|
Load Planning |
Control Load Process |
According to the IATA Ground Operations Manual, documents all load activities for each flight and issues load messages. |
Plan Load Process |
Plans aircraft load based on passenger, freight, fueling, and other information. |
|
Provide Load Information |
Creates load documentation for load staff and cabin crew. |
|
Station Management |
Manage Ground Handling |
Ensures all required ground operations are done. |
Manage Airport Information |
Holds airport information up-to-date (e.g., minimum ground times, connecting times, airport master data). |
|
Manage Passenger Streams |
Controls and optimizes the passenger stream on the ground. Transfers passenger with minimum waiting time. |
|
Manage Lounges |
Manages access control and analyzes use of lounges. |
|
Manage Irregularities On Station |
Recognizes, records, and resolves non-standard situations during ground operations. |
|
Manage Ramp Activities |
Manages onloading and offloading of an aircraft and provides cabin crew with load documents. |
|
Ground Staff Management |
Manage Rostering |
Creates and manages rosters for ground staff and ground equipment. |
Plan Staff Disposition |
Places ground staff at the right time in the right operating area and documents it. |
|
Plan Shifts |
Plans shifts of ground staff and equipment. |
|
Baggage Management |
Track Baggage |
Records baggage movements at the airport. |
Manage Baggage Loading |
Distributes pieces of baggage to Unit Load Devices (ULDs) before loading into aircraft. |
|
Manage Baggage Unloading |
Collects pieces of baggage from Unit Load Devices (ULDs) after unload from aircraft. |
|
Redirect Baggage |
Forwards baggage that missed a flight. |
|
Reconcile Baggage |
Ensures the baggage in the aircraft belongs to the boarded passenger. |
|
Airport Infrastructure |
Provide Airport Infrastructure |
Manages airport infrastructure; i.e., commonly used terminal, self-service kiosks, passenger processing system, etc. |
Figure 19: Ground Operations Domain Business Process
Figure 19 describes how the subdomains and services shown in Figure 18 work together. The process is basically divided into the four process sections: Ground Operations on Aircraft, Common Ground Operations, Operations on Baggage, and Operations on Passenger. Shipping processes are, as already mentioned, not part of this domain and thus explicitly out of scope.
After the Pre-Check-In, the process starts with Check-In Opened and Check-In Passenger with his Ticket. The baggage is then picked up and all information is passed on in order to plan the load in an automated way. The baggage is not declared until the guest’s actual boarding information is processed, and the aircraft is loaded according to the intelligent planning.
When boarding, the passenger data is recorded, stored, and forwarded. After these tasks are completed and all necessary information is available and consistent, the process is complete.
6.4.3 Data Architecture
Figure 20: Data Model of the Ground Operations Domain
Figure 20 illustrates important information objects, which are related to ground operations and their relationships. Regarding the business process of the Ground Operations domain, the derived sub-processes produce information objects; e.g., freight documents or a passenger list. The objects are modeled into entities and are represented in the data model above. In the center is the entity Aircraft, to which the entities Flight, Seat Map, Fleet, and Freight are directly connected. A crew rotation is assigned directly to a flight. Freight is related to Cargo/Mail, Freight Document, and Baggage. The Data Architecture describes the structure of the Ground Operations domain, whereas the business capabilities depict the behavior of the domain.
6.4.4 Application Architecture
Figure 21 shows the mapping of business capabilities to types of applications.
Figure 21: Mapping Capabilities to Applications
The Application Architecture is divided into applications, which integrate the services of the subdomains. The Load Planning Tool handles the loading processes of the aircraft. A Resource Planning Tool ensures that layers of employees are sorted in groups and tasks are distributed between them. With the Baggage Tracking System, an application is integrated, which allows you to track the location and the progress of the baggage at any time. In the Baggage Processing System, on the other hand, all baggage activities are tracked. The Airport Management System bundles and provides all airport infrastructure tasks. Finally, the passenger flows are guided, and information is collected, bundled, and evaluated in the Passenger and Departure Control System.
6.4.5 Technology Architecture
Figure 22 depicts the technology and platforms within the Ground Operations domain.
Figure 22: Technology and Platforms within the Ground Operations Domain
The Technology Architecture describes the infrastructure as well as the platform, database, and other technological components needed as the foundation for the applications in Figure 22. In the Ground Operations domain, the Technology Architecture is represented in four components. The first component, Common Enterprise Software Platform or Cloud Enterprise Platform, includes several tools for operationally managing resources and cargo, as well as providing a system for airport and airline management. The second component, Communication and Messaging Platform, is responsible for communication in the domain and includes applications such as Aircraft Communication and Reporting System (ACARS) or email. The third component, Common Use Passenger Processing System (CUPPS) Platform, includes applications for passenger and baggage systems and control systems. The last component of the Technology Architecture is the Tracking Platform. This includes applications for the tracking and administration of baggage and shipments.
6.5 Revenue Management & Pricing
6.5.1 Subdomains
6.5.1.1 Availability Management
Availability Management is a subdomain of the Revenue Management & Pricing domain.
The following tasks are within the scope of this subdomain:
- Manage booking class availability derived from outputs of Forecast & Optimization (demand and no-show forecasts, bid prices)
- Direct availability control (in case of irregularity management), decision support for revenue controlling, and availability for ancillary and special services (ASR, wheelchair, special meal, etc.)
6.5.1.2 Forecast & Optimization
Forecast & Optimization is a subdomain of the Revenue Management & Pricing domain.
The following tasks are within the scope of this subdomain:
- Forecasts of demand, bookings, cancellations, and buy-downs
- No-show figures based on historical, special, and expert data
- Control the forecast and optimization process, which are monitored here
- Optimize revenue (fare-mix, over-bookings) to steer capacity based on average earnings, the management of availability, inventory, and reservation data
6.5.1.3 Pricing
Pricing is a subdomain of the Revenue Management & Pricing domain.
The following tasks are within the scope of this subdomain:
- Provision and distribution of prices and conditions for each service and the booking class on each market
- Maximize the airline’s revenue, monitor competitor’s prices, and define the price concept and strategy
6.5.1.4 Group Bookings
Group Bookings is a subdomain of the Revenue Management & Pricing domain.
The following tasks are within the scope of this subdomain:
- Check the availability for groups and the determine group pricing; this is necessitated by the fact that the process for booking of groups slightly differs from the standard booking process
6.5.2 Business Architecture
The Business Architecture offers a management-oriented perspective onto the corporate structure, as it includes a business capability view that groups capabilities by subdomains. This includes a description of business capabilities, a business process that portrays the workflow, as well as the inputs and outputs of the relevant steps.
Figure 23: Business Capability Map of the Revenue Management & Pricing Domain
The business capabilities grouped by subdomains of the Revenue Management & Pricing domain are depicted in Figure 23. The business capabilities belonging to the Revenue Management & Pricing domain are described in Table 6. Several of these have to be transformed into the definitions from the IATA New Distribution Capability.
In general, business capabilities claim to be free of overlap, express abilities organizations require, or offer and provide a logical grouping of these services. A business capability answers the question of “what” a service carries out, clearly distinguishing from the analogous question of “how” something is being carried out. All business capabilities, especially when introduced into a reference architecture, must conform to these principles.
Table 6: Revenue Management & Pricing Domain Business Capabilities
Domain |
Service Name |
Objective |
Group Bookings |
Search Flights Multi PAX |
A flight search consists of search criteria including more than nine passenger criteria and returns availability, fares, and flight-related ancillaries. |
Check Seat Availability |
Checks the availability of more than nine seats for a specific flight and booking class. |
|
Search Flight Up 9 PAX |
If the user searches for flights with more than nine passengers, the seat availability has to be checked first. |
|
Availability Management |
Seat Availability |
A service to receive available seats by booking class. |
Manage Availability |
(Re)Calculates availabilities (to be presented to customers or published through the e-Commerce channel) based on relevant settings and stored sold bookings. |
|
Manage Influences |
Allows adjustment of the influence settings, which are used as input to the calculation of availabilities and result therefore in a modified output. |
|
Forecast & Optimization |
Calculate Forecast |
Calculates the expected demand of seats based on historical bookings and current booking trend. |
Optimize Availability |
Optimizes availabilities by utilizing forecasts and the current sold capacity to recalculate the inventory settings. |
|
Pricing |
Quote Fares |
A service to provide the fares fitting the search criteria (the available flights). |
Manage And Distribute Fares |
Provision and communication of the fare model including conditions to partners and fare filing. |
|
Calculate Prices |
Calculates the prices to be provided for the various fares. |
|
Monitor Competitor Prices |
Tracks and observes pricing models and current fares offered by competitors. |
Business process models provide a means of developing a behavioral view of the system under investigation. The business process of the Revenue Management & Pricing domain is depicted in Figure 23, which selectively illustrates the input and output of each activity.
As part of the initial step in this process, the strategy, objectives, and methods are defined. During the second step, the market is analyzed and tactics are selected, followed by creation of a proposal appropriately managed by the governance structures. The penultimate step is to govern capacity.
Figure 24: Revenue Management & Pricing Domain Business Process
6.5.3 Data Architecture
The Data Architecture offers an insight into the organizational data model. A suitable reference point for a data model fitting organizations of the commercial aviation industry is the IATA Industry Data Model, which facilitates the development and maintenance of messaging standards in the commercial aviation industry.[3]
Figure 25: Data Model of the Revenue Management & Pricing Domain
Here, a reasonably abstracted segment is displayed in Figure 25 illustrating fundamental business entities of the Revenue Management & Pricing domain and their relationships.
6.5.4 Application Architecture
Figure 26 depicts the mapping of business capabilities to applications. The main applications assigned to the Group Bookings domain are the Group Offer Manager, Group Sales Tool, and Group Reservation. A real-time-capable Availability Calculator represents the application, which forms the core of the Availability Management subdomain. Similarly, a Forecaster is part of the Forecast & Optimization subdomain. The Pricing subdomain is covered by the Fare Engine, which calculates prices and distributes fares. Also part of the Pricing subdomain is the Market Observation Engine that monitors published offers by competitors. Such an assignment of applications to the business capabilities within the relevant subdomain clarifies what kind of functionality a new application must cater for if it is to be considered to replace an existing application in future.
Figure 26: Mapping Capabilities to Applications
6.5.5 Technology Architecture
The technology layer of the Revenue Management & Pricing domain is subdivided into four technological areas, Bookings/Direct Sales, Forecast, Availability Optimization, and Availability Management. The first area includes an e-Commerce Web Portal backed by a Shop System. Within the second area, namely the Forecast area, a Data Loader, Integrator, Store, and Analyzer are located, which correspond to a typical BI architecture. Availability Optimization, the third area, is technologically represented by a Linear Optimization Problem Solver, such as IBM CPLEX®. An Availability Request Processor, which is high throughput-directed, forms the core part of the last area: Availability Management. Here, the critical aspect is the ability to process as many requests as possible in the shortest timeframe. Within this technology layer, essential platforms can be found, providing various services to applications, which are located in a layer above. Figure 27 depicts the technology and platforms within the Revenue Management & Pricing domain.
Figure 27: Technology and Platforms within the Revenue Management & Pricing Domain
6.6 Flight Operations (Ops)
6.6.1 Subdomains
6.6.1.1 Operational Flight Planning
Operational Flight Planning is a subdomain of the Flight Operations domain.
An operational flight plan is required to ensure an airplane meets all of the operational regulations for a specific flight, to give the flight crew information to help them conduct the flight safely, and to coordinate with Air Traffic Control (ATC).
A flight plan includes the route the crew will fly and specifies altitudes and speeds. It also provides calculations for how much fuel the airplane will use and the additional fuel it will need to carry to meet various requirements for safety. Minimum information on an operational flight plan includes:
- What speed to fly (possibly varying along the route)
- How much fuel the airplane will burn (“trip fuel”)
- Total departure fuel, and how it is allocated – fuel to alternate, contingency fuel, and other allocations that vary between airlines and regulatory rules
- What route (ground track) to fly
- What profile (altitudes along the route) to fly
By varying the route (i.e., ground track), altitudes, speeds, and amount of departure fuel, an effective flight plan can reduce fuel costs, time-based costs, overflight costs (to obtain the right to fly over a country’s airspace), and lost revenue from payload that can’t be carried. These variations are subject to airplane performance, weather, allowed route and altitude structure, schedule constraints, and operational constraints.
In summary, the following tasks are within the scope of this subdomain:
- Responsible for calculating the operational flight plan (flight path) under consideration of slots, information by ATC, over-flight rights, weather, costs, and flight time
- Announce operational flight plan to ATC and compute payload and minimum fuel
- Provide flight and navigation information to pilots
- Prepare and provide briefing documents to crew
6.6.1.2 Operations Control
Operations Control is a subdomain of the Flight Operations domain.
Ensuring that the aircraft and the pilot are in the right place at the right time, both currently qualified and serviceable, is what an operations manager does. Multiply that by the number of flights per day, and that’s what the operations control department does – it keeps the airline working from moment-to-moment despite disruption by weather and a thousand other possible occurrences or mishaps.
Taking so-called low cost carriers as (somewhat) simple examples, they can be big (300+ aircraft), but are designed for engineering and operations simplicity. They always aim to run single-type fleets with the cabin configuration completely standardized, so any aircraft in the fleet can perform any route, and all flight and cabin crew are type-rated on every aircraft. They are mainly short-haul, and if there are no mishaps every crew finishes each day going home rather than to a hotel. The operations departments can be rather small.
On the other hand, the operations staff at a big intercontinental carrier face a far more complex task. For example, big carriers have to deal with a lot of aircraft with various different basic types, both short and long-haul, and within those type groups there are multiple cabin configurations and – sometimes – different engine fits. Just because a route is normally served by a Boeing 777, if the scheduled one falls out, the operations department has to ensure that a schedule on which First Class tickets are sold is matched with a four-class configured 777 rather than a three-class version.
Operations control solves problems. It matches the airline’s assets – human and hardware – to the promised schedule, come what may. It takes just the smallest twitch of the weather somewhere in the world, or pilots and cabin crew reporting sick, or an unexpected component failure on an aircraft, for the carefully choreographed system to start tumbling unless a way can be found to arrest it.
It’s like juggling, but instead of balls, clubs, rings, etc., the props are aircrafts with their maintenance schedules, pilots with their rosters, duty time limitations and recurrent training requirements, cabin crew likewise, airports with curfews, notams and changing weather forecasts, down-route accommodation for crew, passenger management – especially in the case of delay or cancellation, onboard medical emergencies, cargo management, aircraft weight and balance, dispatch coordination, and diversions.
Big, intercontinental carriers have to manage thousands of departures per day around the globe, carrying hundreds of thousands of passengers. It doesn’t require a lot of imagination to understand that every decision, action, or inaction of the operations control department has a serious impact on the overall performance of an airline.
In summary, the following tasks are within the scope of this subdomain:
- Monitor flight plan, identify and evaluate irregularities; i.e., delays caused by ATC or weather
- Handle irregularities, keeping schedule deviation impact and costs as low as possible and interfere with flight plan to minimize disruptions (aircraft change, crew recovery)
- Responsible for optimizing fuel usage and coordinating ATC slots with Eurocontrol
- Plan emergency response and carry out the flight and crew dispatch
6.6.1.3 Crew Management
Crew Management is a subdomain of the Flight Operations domain.
Crew-related costs are second only to fuel costs, typically accounting for about 10% to 20% of an airline’s cost base. With such a large amount of money being spent on crew, even small improvements can result in significant savings. Of the several buckets that make up crew costs, crew supply chain performance (movement of crew from the upstream manpower planning process to training, scheduling, and tracking along with its critical interdependencies) is perhaps the only area which can be significantly optimized without pain. Schedule changes, both voluntary and involuntary, make the best laid plans go awry, resulting in inefficiencies in the crew supply chain (a swing from too many crew to too few). This leads to avoidable hidden costs and revenue leakages.
The following tasks are within the scope of this subdomain:
- Define company recruiting standards (soft and hard facts) for cockpit instruction and ready entries and cabin
- Define marketing for recruiting
- Execute recruiting process
- Derive crew demand from network capacity planning
- Optimize costs for crew with consideration for the overall network in crew-pairing step
- Map actual crews against each pairing in crew-rostering step
- Consider legal restrictions, crew training, and preferences from crew staff
- Ensure crew licensing and provide crew information
- Responsible for crew training management (simulator planning, cabin training, qualification request management), crew monitoring and tracking, and irregularities handling (e.g., check of crew duty limitations in terms of legal operation)
- Responsible for communication with crews; e.g., via crew portals and the preparation of all crew-related dispatch activities
6.6.1.4 Flight Support
Flight Support is a subdomain of the Flight Operations domain.
The major components needing to be coordinated for any given flight include the aircraft and support equipment, cockpit, and cabin crews (together known as the “flight crew”), maintenance, and ground service personnel. Although the maintenance and ground crew activities are critical to support flight operations, the emphasis in this subdomain is on the regulation and scheduling of the flight crews to conduct a given flight.
In many cases, crew members may have never worked together prior to a particular flight. In order to maintain a safe, smoothly functioning, and efficient operation, airlines and regulators have developed very detailed procedures to be executed by crew members that leave very little room for improvisation. These procedures, including normal, abnormal, and emergency conditions, are detailed in the crew member’s operating manuals and backed up through a system of checklists which are cross-checked between flight crew members. It is the responsibility of the training or flight standards department to establish crew member proficiency and currency. The Captain, however, is always ultimately responsible for the safe and efficient conduct of the flight and in extraordinary circumstances may deviate from a procedure or regulation under his or her command authority (Captain’s Emergency Authority).
The cabin crew is primarily responsible for passenger safety during the flight. Other duties include providing customer service products (meals, entertainment, etc.) and assistance with boarding. Flight attendants receive specialized training in aircraft emergencies, evacuation procedures, medical issues and health hazards, care of special needs passengers, flight regulations, and meal service. Supporting the passenger onboard is a cabin service that covers in-flight customer care activities. Since, these activities are covered and appear in-flight, they are related to (categorized under) the Flight Operations domain. Similarly, such services that are given on the ground at the airport (including access to lounges, etc.) are handled in the context of the Ground Operations domain.
Activities before take-off include flight planning, passenger processing, aircraft pre-flight, fueling, and other required ground processes. The pre-flight activities are orchestrated so as to achieve an “on-schedule” pushback from the departure gate, although any maintenance and gate hold issues must also be considered.
While taxiing to the departure runway, the cockpit crew prepares the aircraft for take-off and updates the take-off performance parameters with actual load data. In addition, any departure delays, aircraft icing, and environmental conditions such as runway contamination may need to be addressed.
The take-off is a highly critical maneuver where a number of factors must be taken into consideration including airport/runway, environmental, and emergency/abnormal contingencies. Departure from the terminal area, which may include route and speed restrictions, is followed by the climb to cruise altitude. The optimum cruise altitude is determined by a number of factors including efficiency, ride comfort, other traffic, and/or airspace limitations. During cruise flight, the cockpit crew must continually evaluate contingency options in the event of a passenger or mechanical disruption. In addition, some flight situations require adherence to specialized procedures including international routing, mountainous terrain, and extended overwater operations.
During descent, the crew begins preparing the cockpit and cabin for landing. In addition to conforming to ATC restrictions, the cockpit crew plans the approach to landing which includes consideration of the destination weather, the approach procedures available, and the equipment available on the aircraft to safely and legally complete the arrival. Factors include environmental conditions (visibility, presence of convective weather, runway conditions, etc.), availability of approach aids, aircraft mechanical condition, and, if necessary, available fuel for holding. In the event of an unsuccessful approach, diversion to a more suitable landing point may have to be considered.
After landing, the aircraft is taxied to the arrival gate while the crew readies the cockpit and cabin for parking. Once the aircraft is parked, passenger disembarkation is completed as well as baggage/cargo unloading. The flight crews proceed to the next departure gate, or to the ground transportation area if their duty day is complete.
The following tasks are within the scope of this subdomain:
- Responsible for cockpit and cabin onboard flight preparation, flight operation, and cockpit and cabin onboard communication
- Signature of the load sheet by the Captain
- Manage onboard flight reporting and onboard passenger support
6.6.2 Business Architecture
Figure 28 depicts the business capabilities grouped by subdomains of the Flight Operations domain.
Figure 28: Business Capability Map of the Flight Operations Domain
Table 7 lists and describes the business capabilities of the Flight Operations domain.
Table 7: Flight Operations Domain Business Capabilities
Domain |
Service Name |
Objective |
Operational Flight Planning |
Calculate Flight Plan |
Calculates and optimizes a flight plan for the airline’s fleets. |
Distribute Operational Flight Plan |
Distributes the operational flight plan to all required parties (e.g., ATC, crew members, etc.). |
|
Provide Crew Briefing |
Provides all necessary information required for the crew for a particular flight in a so-called briefing package (e.g., flight plan, maps, manuals, etc.). |
|
Provide Payload And Fuel |
Provides aircraft payload and fuel load calculations. |
|
Provide Navigation And Flight Information |
Provides navigational and flight-related information (e.g., current weather information, weather forecast, etc.). |
|
Flight Support |
Prepare Flight |
Supporting functionality for pre-flight preparation (e.g., updating of electronic flight bag, purser mobile device, checklists etc.) |
Report Flight And Incidents |
Any and all incidents related to a flight have to be reported. Each incident is rated according its severity and impact. |
|
Provide Onboard Communication |
Enable communication between crew members; especially between flight crew and cabin crew (especially important during sterile cockpit periods) . |
|
Support Passenger Onboard |
Support passengers onboard (e.g., ordering of meals and beverages, filing complaints, etc.). |
|
Sign Load Sheet |
Before departure, the cockpit receives the final load sheet showing critical information like total weight, weight distribution, total fuel, information on dangerous goods, etc. Wrong calculations on this sheet will prevent the aircraft from achieving the published certified performance that can lead to catastrophe. Depending on regulations, the cockpit crew is required to cross-check the load sheet. The captain has to document concurrence by signing the sheet and a copy of the signed sheet will remain on the ground and has to be retained for a defined period. |
|
Crew Management |
Manage Crew Resources |
Manages crew members and their rosters. |
Communicate With Crew |
Provides crew members with all necessary information in time (e.g., roster, training information, layover details, changes, etc.). |
|
Operations Control |
Manage Flight Plan |
Manage the flight plan as it is being flown and adapt to changes (e.g., as required by ATC). |
Coordinate Slots |
Monitor and manage available as well as owned slots; prevent slot loss. |
|
Handle Flight Irregularities |
React to and recover from disruptions. |
|
Dispatch Flight And Crew |
Manage the safe and efficient conducting of a flight from the ground. |
|
Optimize Fuel |
Optimize the fuel load of an aircraft. |
Figure 29 shows the processes and activities of the Operational Flight Planning, Operations Control, and Crew Management domains. Since these are closely related and interdependent as well as following a strict timeline, the figure uses the full BPMN™ to show these dependencies and time restrictions.
The whole process targets the so-called “day of operation”, which is the day a particular flight takes place. The day of operation is part of the operations control phase, which is a three-day window starting two days before and including the day of operation. For example, if the day of operation is September 5, then the time horizon of operations control is September 3, 00:00 UTC to September 5, 24:00 UTC. The main concerns during this phase are enabling the safe and efficient conduction of flights as well as keeping changes to schedules to an absolute minimum.
Before the Operations Control phase occurs, the Operational Flight Planning phase starts about nine weeks before the day of operation and encompasses the time until three days before the day of operation. The main concerns of this phase are to schedule flights taking all legal and commercial restrictions into account.
The main objects these processes work with are so-called “rotations” (either aircraft-related or crew-related). A rotation in this context is a sequence of flight legs that start at a station and end at that same station; usually, that station has to be a so-called “home base” (i.e., where crew members or the airline’s aircraft are “at home”) to qualify as rotation start or end.
Figure 29: Flight Planning, Crew Management, and Operations Control Processes
The processes, activities, and objects of Figure 29 are described in more detail in Section A.1.
The high-level processes and activities related to the conducting of a flight are shown in Figure 30. This diagram only considers flight crew processes – with the focus being placed on the cockpit crew (“flight deck”). In general, the main input to many of the processes is checklists that the crew members need to work through to ensure safe and efficient operation of the aircraft. Most, if not all, of these checklists don’t need to be kept afterwards.
Figure 30: Flight Crew Activities During a Flight
The processes, activities, and objects of Figure 30 are described in more detail in Section A.2.
6.6.3 Data Architecture
Figure 31 illustrates Business Objects and their relationships.
Figure 31: Data Model of the Flight Operations Domain
Figure 31 describes the data entities in the Flight Operations domain. The center of this architecture is the Flight entity, which is directly related to Flight Leg, Crew Rotation, Flight Plan, and Ticket. Other important entities within this domain are the Crew Rotation, Aircraft with the Aircraft Rotation, and the Customer. All business capabilities create information objects around those entities; i.e., a customer can for instance report an entry which consists of a debrief report. Information about the station which represents the home base of the aircraft and the crew member is also described within this Data Architecture.
6.6.4 Application Architecture
Figure 32 shows the mapping of business capabilities to applications.
Figure 32: Mapping Capabilities to Applications
Figure 32 depicts the mapping of business capabilities to applications. All business capabilities are managed by seven applications. The Flight Planning Tool is responsible for processes like crew briefing or calculating the flight plan. Within the subdomain Operations Control there are two applications, Operations Control System and the Slot Manager. The Crew Management system manages the crew resources and communications with the whole team. The subdomain Flight Support has three applications, the Flight Deck Support System, the Onboard Communication System, and the Cabin Crew Support System.
6.6.5 Technology Architecture
Figure 33 depicts the technology and platforms within the Flight Operations domain.
Figure 33 depicts the Technology Architecture of the Flight Operations domain. All applications are summarized here. There are four main technology components which comprise all applications: Operational Flight Planning, Operations Control, Crew Management, and Flight Support.
Figure 33: Technology and Platforms within the Flight Operations Domain
6.7 Marketing & Customer Care
6.7.1 Subdomains
6.7.1.1 Loyalty
Loyalty is a subdomain of the Marketing & Customer Care domain.
The following tasks are within the scope of this subdomain:
- Continually develop and manage the existing loyalty program for rewarding loyal customers
- Manage loyalty partners, which is the basis for a successful loyalty program
- Track customer collection and spend of miles in order to keep track of the customer’s current mile status
- Based on customer loyalty, manage the corresponding tier levels so that customers will be matched to the appropriate level
6.7.1.2 Feedback & Complaint
Feedback & Complaint is a subdomain of the Marketing & Customer Care domain. It ensures that service quality is measured and feedback is collected from the customer perspective. It forms a basis for improving the service quality based on the feedback.
The following tasks are within the scope of this subdomain:
- Manage feedback and complaints, including analysis of customer feedback, which is used as the basis for subsequently optimizing the satisfaction and loyalty of this customer
- Manage, track, and address claims for compensation, restitution, repayment, or any other remedy for loss or damage
6.7.1.3 Customer Profile Management
Customer Profile Management is a subdomain of the Marketing & Customer Care domain.
The following tasks are within the scope of this subdomain:
- Analyze and monitor the relationship data between the organization and the customer (B2C) to gain basic insights into customers
- Identify and create customer profiles, and deposit the corresponding values of the customer
- Track and save customer preferences to the profile
- Save and deposit in the profile both static customer data (address, etc.) and dynamic data (last ordered product, etc.) as well as other customer profiling functions
6.7.1.4 Direct Marketing
Direct Marketing is a subdomain of the Marketing & Customer Care domain.
The following tasks are within the scope of this subdomain:
- Manage, track, and save every advertising, sales promotion, campaign management, and similar in order to keep every direct marketing activity together
- Out of the customer profiles, generate new personalized offers based on existing data
- Depending on the context of the customer, tailor offers based on the data and values of the customer
- Enable the customer to personalize offers
- Enable services backing analyses and reports that direct or measure marketing initiatives, and that measure success of/reaction to sales actions; this comprises a sales cockpit, web tracking services (measuring/ensuring usability), and information gathered from social media content
6.7.1.5 Customer Communication
Customer Communication is a subdomain of the Marketing & Customer Care domain.
The following tasks are within the scope of this subdomain:
- Responsible for essential standard communications to the customer to be handled automatically, such as notifications about service fulfillment; e.g., flight status
- Manage social media communication via proactive postings, and reactions to comments and customer private messages
6.7.2 Business Architecture
Figure 34 depicts the business capabilities grouped by subdomains of the Marketing & Customer Care domain.
Figure 34: Business Capability Map of the Marketing & Customer Care Domain
Table 8: Marketing & Customer Care Domain Business Capabilities
Domain |
Service Name |
Objective |
Customer Communication |
Notify Service Disruption |
Notifies the customer via various channels such as email or SMS about irregularities concerning the booked flight; e.g., delays. |
Notify Service Fulfillment |
Notifies the customer about regular events such as the completed booking of a flight or check-in times. |
|
Connect Social Media |
Manages different social media accounts of the commercial aviation organization and communication with the community. |
|
Customer Profile Management |
Maintain Customer Master Data |
Maintains customer data such as name or birth date. |
Maintain Customer Preferences |
Handles customer preferences from either entered information by the customer or analyzed customer behavior. |
|
Manage Customer Profile |
Manages the customer profile and consolidates all information in one place. |
|
Analyze Customer Relationship |
Analyzes customer behavior towards the commercial aviation organization and preferred bookings. |
|
Direct Marketing |
Manage Campaigns |
Project management service for planned, ongoing, or bygone marketing campaigns. |
Provide Personalized Offers |
Service to examine customer preferences and provide personalized offers based on preferred products. |
|
Manage Sales Promotions |
Project management service for planned, ongoing, or bygone sales promotions. |
|
Feedback & Complaint |
Manage Customer Feedback |
Collects all the customer feedbacks and provides a place for communication to the customer and internal actions |
Manage Customer Claims |
Collects all the customer claims and provides a place for communication to the customer and internal escalations and reaction plans. |
|
Manage After Sales |
Manages after sales automated customer communication. |
|
Manage Customer Survey |
Manages regular customer surveys to retrieve customer feedback. |
|
Loyalty |
Earn Miles |
A service for crediting miles to a customer for each booking. |
Spend Miles |
A service for the customer to spent earned miles. |
|
Manage Loyalty Account |
Tracks customer loyalty and awards it via (status) upgrades. |
|
Book Awards |
Awards customer for frequent bookings for the airline. |
|
Provide Partnership Accrual |
Analyzes frequent customer bookings and provides recommendations for partnerships. |
Figure 35: Marketing & Customer Care Domain Business Process
The process depicted in Figure 35 shows which information objects are derived from the Marketing & Customer Care process. Within the first process step all communication channels are used to reach potential customers. Feedback & Complaints from pre-existing customers are collected and analyzed to create customer feedback documentation and results for customer surveys. Product is used to enhance existing customer profiles. One aspect of the customer profile is loyalty programs where loyalty accounts of customers are managed. From all analytical reports and marketing campaign data, direct marketing procedures and guidelines are created and used for further sales activities.
6.7.3 Data Architecture
Figure 36: Data Model of the Marketing & Customer Care Domain
Figure 36 describes the relationship of information objects and entities within the Marketing & Customer Care domain. All marketing-related information objects and entities are related to either the Customer or Passenger entity. Certain KPIs and data are collected from the passenger; i.e., loyalty data, feedback, or complaints. This data is used to create a loyalty data profile and help develop personalized marketing campaigns which are used to attract more customers.
6.7.4 Application Architecture
Figure 37: Mapping Capabilities to Applications
Figure 37 depicts the mapping of business capabilities to applications. The Customer Communication domain is composed of the Notifying Service, which informs the customer about important activities belonging to his bookings, and the Social Media Manager, which gives employees the ability to manage social media Accounts in one application.
The Customer Profile Management domain has two applications: the Customer Data Manager, which stores and manages all the data, and the Customer Profile Analyzer, which analyzes profiles in order to gain more insight.
The Direct Marketing domain consists of the Marketing Project Manager, which keeps track of every past, current, and future marketing campaign and helps to manage them, and the Personalized Offer Calculator, which automatically generates offers tailored to a specific customer.
The Feedback & Complaint domain consists of the Customer Feedback Managing Tool, which keeps track of every customer feedback sent to the company and helps to react, the Customer Survey Tool, which helps to act by asking the customer about specific topics directly, and the After Sales Handler, which helps to manage communication after a customer purchased services.
The Loyalty domain consists of the Miles Calculation Service and the Customer Loyalty Manager. The Miles Calculation Service helps to keep track of the miles of a customer – how much he earns, how much he spends. The Customer Loyalty Manager keeps track of loyal customers and manages different kinds of rewards for them.
6.7.5 Technology Architecture
Figure 38: Technology and Platforms within the Marketing & Customer Care Domain
The Customer Communication Manager includes a Campaign Management Tool for managing marketing promotions and campaigns. It also includes a Social Media Manager for managing all types of social media. This tool is concentrated on posts and managing the reaction of posts while excluding user message handling. The Customer Relationship Manager keeps all the relevant customer data together, analyzes the stored data of the customer, and provides reports about customer behavior. It includes a loyalty system which keeps track of customers’ miles as miles are earned and spent, and calculates the loyalty status of the customer. With this data it rewards customers due to his loyalty status with various kinds of benefits. The Support Ticket System is a gateway for a concentrated inbox for various types of communication (including email, social media, and non-digital), as well as every topic (e.g., complaints). The incoming messages will be centrally assigned to the responsible agent.
6.8 Cargo
Cargo operations handle items which are carried by an airline, usually by order of a forwarder. The operations on passengers’ baggage, however, are not seen as cargo handling, but rather as Ground Operations (see Section 6.4).
6.8.1 Subdomains
6.8.1.1 Forwarding
Forwarding is a subdomain of the Cargo domain. According to the IATA Cargo iQ Master Operating Plan, some cargo operations are the responsibility of the forwarder.
The following tasks are within the scope of this subdomain:
- Receives shipment and validates security and customs status of a shipment
- Unloads the trucks, screens the shipment, and places freight into a warehouse
- Responsible for the handover of the shipment to the forwarder, which includes verification of customs release status, handover documents, and preparing shipment for handover
6.8.1.2 Carrying
Carrying is a subdomain of the Cargo domain According to the IATA Cargo iQ Master Operating Plan, these cargo operations are the responsibility of the airline.
The following tasks are within the scope of this subdomain:
- Prepares freight for flight plans and flights, and collects freight for flights
- Responsible for departure activities, moving freight from warehouse to park position, loading it into an aircraft, and resolving all discrepancies between plan and actual load
- Takes care of arriving activities, unloads freight from aircraft, and stores it on destination
- Handles warehouse activities; i.e., the freight in the airline’s warehouse at departure and at arrival
6.8.1.3 Cargo Management
Cargo Management is a subdomain of the Cargo domain.
The following tasks are within the scope of this subdomain:
- Responsible for the strategy components within this domain
- Develops the Cargo domain strategy and develops the products and services which are needed to perform the tasks
- Manages the cargo network and scheduling relationships
6.8.2 Business Architecture
Figure 39: Business Capability Map of the Cargo Domain
Table 9: Cargo Domain Business Capabilities
Domain |
Service Name |
Objective |
Forwarding |
Receive Shipment |
Unload forwarder’s truck or receive shipment from another airline, validate status of the shipment, screen the shipment, store the shipment in the airline’s warehouse, and confirm to the forwarder. |
Handover Shipment |
Validate release status of the shipment, handover documents and shipments to the forwarder, or redirect it to another airline. |
|
Carrying |
Prepare Freight For Flight |
Clears the security of the freight, plans flights, and collects freight from airline’s warehouse. |
Cargo Departure Activities |
Moves shipment to the parking position, loads the aircraft, and documents and clears discrepancies between plan and actual freight. |
|
Cargo Arrival Activities |
Stores freight at destination and informs the forwarder. |
|
Warehouse Activities |
Stores freight, collects freight, and plans warehouse capacity. |
|
Cargo Management |
Cargo Strategy And Product Development |
Defines the cargo strategy and processes for cargo operations and product development. |
Cargo Network And Scheduling |
Manages the cargo network and partnerships and enables a high quality of service by customizing the cargo network. Schedules operations between the parties involved. |
Figure 40: Cargo Domain Business Process
The business process of the Cargo domain is separated in two main pools: airline and forwarder. The process starts with Receive Shipment from Shipper. The operations are responsible for enabling the airline to receive the shipment. All warehouse activities and freight preparation for the flight needs to be done before the departure. The departure activities send the flight manifest to the next station. After executing the arrival activities, all cargo is shipped to the forwarder. Finally, all operating cargo arrives at the destination.
6.8.3 Data Architecture
Figure 41: Data Model of the Cargo Domain
Figure 41 depicts the Data Architecture of the Cargo domain. All information objects related to this domain are included in this representation. Furthermore, Baggage, Unit Load Device, Aircraft, Freight Document, and Cargo are directly related to the Freight entity. All information objects which are generated during the execution of the process are included in entities or found in the Data Architecture shown above.
6.8.4 Application Architecture
Figure 42: Mapping Capabilities to Applications
Figure 42 depicts the mapping of business capabilities to applications. The Forwarding subdomain is composed of the Cargo Forwarding System application, which is responsible for tracking and tracing, messaging from and to the forwarder, and the receipt and handover of the shipment.
The subdomain Carrying has two applications: the Cargo Control System, which plans the freight and loads/unloads the freight for each flight, and the Warehouse Management System, which stores and collects the freight, plans the capacity, and is responsible for warehouse reporting.
The Cargo Management System is responsible for developing the domain’s strategy and products. The other task within this application is Cargo Network & Scheduling, which manages the cargo network and partnerships and enables a high quality of service by customizing the cargo network. One task is scheduling operations between with the parties involved.
6.8.5 Technology Architecture
Figure 43: Technology and Platforms within the Cargo Domain
The Technology Architecture represents a general view over all applications used within the Cargo domain. It contains four main features: the Common Enterprise Software Platform or Cloud Enterprise Platform, the Communication & Messaging Platform, the Tracking Platform, and the Common Use Passenger Processing System (CUPPS) Platform.
6.9 Maintenance
6.9.1 Subdomains
6.9.1.1 Maintenance & Testing
Maintenance & Testing is the only subdomain of the Maintenance domain.
The following tasks are within the scope of this subdomain:
- Defines the process for overall inspection, repair, overhaul, and maintenance of aircrafts, machines, and components
- Responsible for managing scheduling for compulsive viewing and maintenance and operations of compulsory quality assurances
- Maintains products onboard (IFE), on the ground, and the Internet onboard
- Manages scheduling
- Responsible for all product tests
6.9.2 Business Architecture
Figure 44: Business Capability Map of the Maintenance Domain
Table 10: Maintenance Domain Business Capabilities
Domain |
Service Name |
Objective |
Maintenance |
Maintenance Strategy And Planning |
Defines and manages all maintenance-related organizational tasks such as scheduling, calculating downtime, documentation, and organization. |
Maintenance Scheduling |
Defines and manages all compulsory quality assurances and scheduling of maintenance dates. |
|
Operational Maintenance |
Executes the process for overall inspection, repair, overhaul, and maintenance of aircrafts, machines, and components. Furthermore, it is responsible for planning operational resources such as skill management. |
|
Material Logistics |
Defines the process for parts procurement, logistics of spare parts, and overall material logistics within the Maintenance process. |
Figure 45: Maintenance Domain Business Process
The process depicted in Figure 45 shows which information objects are derived from the Maintenance process. Within the first process step all maintenance-related processes are planned and documented. Furthermore, data and requirements for different products are collected by the responsible team. Another essential process within this domain is scheduling all compulsory and regular tests. All reports are organized and reported to the responsible manager. Also product testing is done within this domain. Schedules and reports are derived from processes here. Finally, documentation of the whole process is constantly collected and updated to ensure a high level of product and service quality.
6.9.3 Data Architecture
Figure 46: Data Model of the Maintenance Domain
Figure 46 describes the relation of information objects and entities within the Maintenance domain. Most information objects within this domain are maintenance schedules and maintenance or testing reports. All reports are summed up in the Quality Reports entity which is related to the Testing Data. All schedules for compulsory testing, maintenance documentation, and testing requirements are included within the Maintenance information object.
6.9.4 Application Architecture
Figure 47: Mapping Capabilities to Applications
The Maintenance application has several responsibilities such as monitoring and analytics, testing, and maintenance. All business capabilities are executed mostly in support of IT systems. The Maintenance domain comprises one major application which is responsible for planning capabilities and tracking of all testing relevant data. It also manages the maintenance and monitoring processes for all products and services, depending on the structure.
6.9.5 Technology Architecture
Figure 48: Technology and Platforms within the Maintenance Domain
6.10 Support
6.10.1 Subdomains
Figure 49: Support Domain Business Process
6.10.1.1 IT Services
IT Services is a subdomain of the Support domain.
The following tasks are within the scope of this subdomain:
- Manages and controls the airline’s own equipment located at home and at foreign airports
- Provides services for communicating/interacting with external IT services and third-party services/IT systems that are made available for the airline’s own processes
- Responsible for the management of interfaces to third-party systems; for example, interfaces to baggage distribution and routing systems of other airlines
- Provides a middleware, messaging Enterprise Service Bus (ESB) and provides an infrastructure that supports the usual communication patterns: request/response, pub/sub, etc.
- Provides the enterprise application integration facilities
This subdomain shall be more technically-oriented and therefore shall not implement business services, but rather basic services used by several other domains. Knowing that the difference between technical and business services is somehow difficult to determine, Enterprise Architecture management is a crucial part for each organization.
User Data Management
Establish central/group-wide data access to customer data: a central user data model and common storage of user data does not imply sharing of airline-related customers to the group. Governance of Identity and Access Management (IAM) to common user data storage is a prerequisite for this concept.
User Data Management aims to derive a high-level target user data model from CUSTIS and SAMBA,[4] gather requirements from airline-individual personalization initiatives, and use existing customer data where available. It recognizes personalization initiatives supporting the idea of customer centricity – personalization depends, simply spoken, on the available information in a specific context (service). A common user data model should include all information which will be useful for providing personalized services.
6.10.1.2 HR
HR is a subdomain of the Support domain.
HR as a cross-sectional subdomain is primarily concerned with the management of people within organizations, focusing on policies and systems. HR departments and units in organizations typically undertake a number of activities, including employee benefits design, employee recruitment, training and development, performance appraisal, and reward (e.g., managing pay and benefit systems). In most organizations off-the-shelf services based on standard solutions are used. Anyhow, it is possible that HR delivers special services for staff of airlines for IAM.
6.10.1.3 Financial Accounting
Financial Accounting is a subdomain of the Support domain.
Financial Accounting, like HR, is a cross-sectional subdomain and is governed by both local and international accounting standards and mostly based on standard solutions.
Financial Accounting refers to accounting suppliers and business partners. This comprises services such as preparing remittance and refunding. The request for a refund includes the details of what is to be refunded. The details may contain the order ID, document number, and coupon number(s). In addition to the details of the refunded document(s), the response must contain accounting information to allow correct processing of the refund; e.g., a settlement authorization code.
6.10.1.4 Data Management & Analysis
Data Management & Analysis is a subdomain of the Support domain.
The following tasks are within the scope of this subdomain:
- Provides data warehouse, reporting, dashboard facilities, and tools to enable BI; it will be used for the following, for example:
— Reporting of operational data for quality management and provider Service-Level Agreement (SLA) monitoring
— Reporting of operational data due to legal requirements
— Duty report management
— Analysis of operational flight data for safety management and fuel optimization
— Collection and reporting of operational (flight) data due to legal requirements
6.10.1.5 Business Process Support
Business Process Support is a subdomain of the Support domain.
The following tasks are within the scope of this subdomain:
- Provides and manages reference data and supports the business processes
6.10.1.6 Contract Management & Procurement
Contract Management & Procurement is a subdomain of the Support domain.
The following tasks are within the scope of this subdomain:
- Administers the airline’s contracts with its vendors; this comprises contract creation, negotiation, adherence, and the definition of SLAs and KPIs for managing the day-to-day performance of the vendor
- Manages changes that may be required as the relationship changes and problems arise, documents changes that may have been agreed, and analyzes the benefits that accrue or may be available from the contract
The procurement refers, for example, to fuel for the aircraft, equipment, and required third-party services. Here, procurement guidelines are set, which describe the rules for procurement, such as target, statement of validity, fundamentals, and the ethics of procurement including interest, confidentiality, and fairness and competition compliance. Procurement includes supplier management as well.
Within the procurement process, sources of supply are investigated, price quotations obtained, negotiations with suppliers on price and delivery performed, contracts prepared (which is part of contract management), documentation, insurance and shipping arranged, and installation and commissioning of procured equipment monitored.
The International Civil Aviation Organization (ICAO) provides the ICAO/TCB Procurement Procedures and Mechanisms, which is a detailed standard for contract management and procurement in the commercial aviation industry.
The following procurement services (named by ICAO) belong to the Contract Management & Procurement domain:
- Identification of supply sources on a worldwide basis
- Call for tenders
- Commercial evaluation of tenders
- Commercial contract negotiations
- Drafting and award of purchase order/contract documentation
- Commercial administration of purchase order/contract
These include the following technical services:
- Preparation of detailed technical specifications
- Preparation of technical tender documentation
- Technical evaluation of tenders
- Technical contract negotiations
- Drafting of technical component of purchase order/contract document
- Review of system design document
- Site and equipment inspections
- Acceptance and commissioning activities, etc.
6.10.1.7 Catering Procurement
Catering Procurement is a subdomain of the Support domain.
Catering Procurement is to be considered as a concretization (special case) of the procurement described by the Contract Management & Procurement process. The subject of concretization is catering as a special product/service to be procured.
6.10.1.8 Marketing, Sales, & Quality
Marketing, Sales, and Quality is a subdomain of the Support domain.
The following tasks are within the scope of this subdomain:
- Enables services backing analyses and reports that direct or measure marketing initiatives, and that measure success of/reaction to sales actions; this comprises a sales cockpit, web tracking services (measuring/ensuring usability), and information gathered from social media content
Figure 50 shows the overall structure of the reference architecture.
A.1 Flight Planning, Crew Management, and Operations Control Processes
Fleet Assignment
After structuring and optimizing the flight network, the fleet assignment process is the first flight schedule implementation phase that applies precise operational rules. The fleet assignment process starts about nine weeks before the day of operation and provides flight and aircraft schedules (without specific aircraft relation) considering subfleet and crew aspects.
Crew Pairing
About eight weeks before the day of operation the fleet assignment results are handed over to the crew pairing process. Because the crew planning department has to publish the crew rosters for a period of an entire month, the fleet assignments have to be provided by the middle of every month for the whole month after the next. For example, the fleet assignment handover by mid-August must contain the whole month of October.
The pairing process “pairs” aircraft with matching crews considering crew capacity and qualifications at all of the airline’s stations. Actual crew members are not taken into consideration.
Crew Rostering
At least four weeks before the day of operation the crew pairing results are given to the crew rostering process. Because the crew pairings must also be provided for a period of an entire month, the results are provided by the beginning of every month for the whole next month. For example, the crew pairing results by beginning of September must contain the whole month of October.
The crew rostering and publication must be done by the last working day before the end of every month.
The rostering process assigns actual crew members to the rotations created by the pairing process, satisfying the rotation’s crew need (also called “crew complement”). Personal requirements of each crew member (e.g., training, medical examinations, visa applications, etc.) are taken into consideration as well.
Tail Assignment
About three weeks before the day of operation the fleet assignment results for an additional week are handed over to the tail assignment process. As this process is performed every week, the tail assignment process always receives fleet assignments for the latest appending calendar week. For example, the fleet assignment handover by calendar week 33 contains the assignments of calendar week 37.
The tail assignment process assigns the anonymous aircraft schedules to specific aircrafts (so-called “tails”).
Long-Term Maintenance Planning
Beside flight events, the fleet assignment process also considers the long-term maintenance requirements and provides aircraft schedules with placeholders for long-term maintenance events. Within the long-term maintenance planning process the placeholders are assigned to specific tails requiring long-term maintenance.
Short-Term Maintenance Planning
About three to five days before operation the short-term maintenance events must be planned to specific tails. All required maintenance events for specific tails are tracked and requested by the aircraft maintenance department. These requests are created and assigned to the specific tails.
Operations (Ops) Control Period Preparation
On a typical day of operation numerous changes to aircraft rotations have to be applied. These changes may lead to inconsistent aircraft rotations on transitions to the subsequent days. While these inconsistencies are maintained within the operations control window, additional inconsistencies may appear when the three-day operations control window moves to include the next day.
The main task of operations control period preparation is to minimize station breaks on transitions to the subsequent day when being added to the operations control period. In other words, the goal is to balance all station transitions considering crew, aircraft, and passenger-related aspects.
This task is processed every day during the night shift by the maintenance control department; e.g., during the night shift just before midnight on August 9th, the transition from August 11th to 12th will be balanced by changing assignments on August 12th.
Crew Tracking
Upon publication, the crew rosters and pairings are handed over to the crew tracking process. The crew tracking process covers both the crew roster administration and the crew pairing maintenance processes for the whole current month, including the operations control period.
Crew Pairing Maintenance
The crew pairing maintenance process works on recovering crew pairing issues caused by flight schedule changes; e.g., equipment changes, aircraft delays.
Crew Roster Administration
While the crew pairing maintenance focuses on repairing anonymous crew rotations, the crew roster administration process tries to recover crew roster issues caused by crew member irregularities; e.g., sickness and crew pairing changes caused by crew pairing maintenance.
Aircraft Rotation Refinement
Preparation of the upcoming day starts with the refinement of aircraft rotations. During the late shift on the day before the day of operation the maintenance control department prepares the aircraft rotations for the next two days.
The major task at this stage is to reduce crew changes on short-range aircraft for the upcoming day of operation considering aircraft maintenance aspects. For example, this task is processed on August 9th to reduce crew changes on August 10th and 11th with the focus placed on August 10th.
Fuel Optimization
Also during the late shift on the day before operation, after refining the aircraft rotations considering crew changes and maintenance requests, operations controllers apply (long-range) aircraft changes with regard to fuel performance aspects.
Crew Convenience Improvement
During the night shift, after publishing fuel-related changes, operations controllers improve crew convenience by reducing the number of necessary crew changes within short-range subfleets for the day of operation.
Station Break Elimination
Operations controllers usually do schedule changes without generating station breaks within the given operations control period. There may still be reasons like missing aircraft maintenance status or high workload on the day of operation that cause station breaks to appear. These inconsistencies are to be resolved during the night shift.
Disruption Management
Disruptions may be originated by temporary bottlenecks of any involved resources; e.g., fleet, crew, airport, airspace. In order to increase reliability, the responsible parties are holding reserve/spare capacities of their allocated resources; e.g., spare aircraft, reserve crew. These capacities may be utilized in minor operational disruptions. In case of heavy irregularities (e.g., heavy weather or crew strikes), internal or external resource capacities are insufficient which often results in major operational disruptions.
The challenge of managing major disruptions is both to minimize the impact on passengers during the irregularity and to go back to normal operation as quickly as possible.
Proactive Irregularity Handling
If a major operational disruption is predictable on the day before the day of operation (e.g., by weather forecasts or strike announcements), a crisis management group may decide on a flight schedule reduction; e.g., cancellation of 25%, 50%, or even 100%.
Usually the implementation of these decisions must be done by the operations control center on the late noon or evening before the day of operation. The task of handling predictable irregularities usually focuses on committing the right cancellations considering all passenger, crew, and fleet aspects during the irregularity and in the aftermath. For passenger and crew notification reasons solutions must be implemented within a short period of time.
Ad Hoc Irregularity Handling
If a major disruption had not been predictable before the day of operation or the impact had been underestimated, irregularities must be holistically evaluated and resolved in a very short period of time. The main task of handling major disruptions with small preparation time is to reassess the situation at hand and to implement solutions considering the necessary recovery.
Schedule and Fleet Recovery
The central visualization of flight operations at operations control centers combines the scheduled flights and their assigned tails. This means that irregularities are usually resolved from an aircraft rotation perspective respecting passenger and some less complex crew rotation aspects. If a recovery solution would have a more complex impact on aircraft maintenance or crew rotations, collaboration with maintenance and crew control is necessary.
Crew Recovery
In case of major disruptions crew recovery is mostly subsequently done after schedule and aircraft recovery. Crew recovery starts with the recovery of crew pairings (crew rotations) which have to follow the changed aircraft schedules. After changing the crew rotations the crew rosters also have to be recovered in an additional step.
A.2 Flight Crew Activities During a Flight
Flight Crew Check-In
Once assigned to a flight sequence, crew members are required to sign in at the station flight operations office (nominally) one hour prior to the departure of the first leg. Crews normally arrive earlier than one hour in order to accommodate international flight planning, publication/flight manual updating, or other administrative responsibilities. Once introductions between crew members are complete, the flight crew begins the planning tasks. In situations where the time available before departure is minimal, the First Officer may proceed to the aircraft to begin the pre-flight duties there.
Pre-Flight
During this stage, the flight deck crew receives the so-called briefing package (containing the flight plan, current weather and fuel information, etc.) and the cabin crew receives the passenger lists. This information is either printed out or, if available, electronic devices of the crew are updated with the information.
The crew must determine the airworthiness of the aircraft and address any open issues before departure. The term “pre-flight” is typically used to describe the interior and exterior inspections of the aircraft, but in a general sense can be used to describe any activity involved with preparing the aircraft for departure. The aircraft inspection is usually divided among the cockpit crew and includes an exterior walkaround examination, interior cockpit set-up, and systems checks. These pre-flight inspections are outlined in a checklist.
The pre-flight also includes verification that all required manuals and paperwork are onboard and complete. The aircraft mechanical logbook serves as a means for flight and cabin crews to convey mechanical discrepancies to station maintenance personnel and subsequent flight crews. Any discrepancy entered into the logbook must be balanced with an entry by a certified aircraft mechanic who either resolves the problem or defers it according to specified guidelines. Some items can be deferred based on time (hours of flight, or days/weeks), type of maintenance available, or whether they are listed in the Minimum Equipment List (MEL). The MEL identifies the components which may be inoperative on a given aircraft while still maintaining legality for dispatch as well as the deferral rules. Crew responses associated with MEL items range from simple awareness to complex critical procedural changes.
The Configuration Deviation List (CDL) is similar to the MEL, but references airframe components that are more structural in nature (e.g., missing flap track fairing).
Modern aircraft have extensive autoflight capabilities that allow many of the navigation and performance optimization tasks to be handled automatically if desired. Autoflight initialization and Flight Management System (FMS) programming are conducted during the pre-flight phase.
Some airlines have information systems which allow information required to initialize the autoflight systems to be uploaded automatically via an ACARS datalink unit. In general, the use of ACARS by air carriers satisfies the requirement that their aircraft are continuously able to be contacted by dispatch during the entire flight. Initialization of this system is also part of the cockpit set-up procedures.
Communication between the cockpit and cabin crew members is critical to the safety and efficiency of the flight. At some point during or before pre-flight activities and passenger boarding, the Captain conducts a briefing with the Purser or senior “#1” flight attendant. This includes standard information covering en route flight time and destination weather, as well as taxi-out time (in the case of a short taxi, the flight attendants must start the safety video/demonstration as early as practicable), security issues and alerts, ride conditions and turbulence, inoperative cabin components, requirement of overwater flight passenger life vest demonstrations, augmented crew, crew meal service, and any other relevant safety or operational issues. The Captain may also discuss adherence to the sterile cockpit period in which access to the flight deck is limited to reduce distractions during critical flight phases, nominally anytime the aircraft is below 10,000 feet above Mean Sea Level (MSL).
Pre-Departure
As the scheduled departure time approaches, the Captain, lead gate agent, and ground crew chief coordinate their efforts to see that all pre-departure requirements are met. The pilots finalize the FMS and autoflight parameters by obtaining an update on weather conditions and runway utilization through the Airport Terminal Information Service. In addition, the crew must receive confirmation of the flight’s routing from ATC. Prior to the scheduled departure (usually at least a few hours before), the airline’s dispatch office files a requested routing based on their flight plan optimization with ATC. Approximately 20 minutes prior to departure, the ATC route clearance is requested, preferably through an ACARS function. The ATC route clearance received by the crew may differ from the filed routing and the changes must be addressed (fuel/performance/dispatch considerations) and reprogrammed. In addition to possible routing changes, ATC may also adjust the planned departure time as a result of current airspace dynamics or weather conditions.
Latest at this stage, the cockpit will receive a signed load sheet from the loading agent. This typically includes finalized aircraft and fuel weights, stabilizer trim settings, center of gravity data, passenger count, cargo loading, and live animal and security information. The First Officer uses the updated information to calculate finalized take-off performance data. The First Officer will also reset the stabilizer trim and set take-off reference speeds. In cases where the load sheet weights are greater than planned, adjustments may have to be made to the flap and/or power settings, or an alternate runway may be required. The load sheet is a critical document, because errors on it can have catastrophic consequences (e.g., plane crash due to wrong trimmings). Therefore, in many countries, the crew is obliged to cross-check the calculations for gross errors and, depending on regulations, the Captain has to indicate concurrence with the figures by signing the load sheet. Often, copies of the signed load sheet are taken by various parties (e.g., load agent, airline, etc.) and kept for a defined period of time.
Once clearance is received, the crew can perform the “Before Starting Engines” checklist. At approximately 10 minutes prior to departure, the Captain turns on the Fasten Seat Belt sign which signals the Flight Attendants to ready the cabin for departure and deliver the requisite PA announcements.
In order to prepare the aircraft for movement, the ground crew completes the baggage and cargo loading, including late bags, and closes the cargo doors. If necessary, any required external power or air is removed from the aircraft, unless required for engine start. The tug is connected to the aircraft via a towbar unless a “powerback” is planned. The flight deck crew performs the “just prior to pushback” portion of the checklist which includes, among other things, confirmation that all the doors are closed and that the anti-collision (red flashing) beacon is operating. At this time the flight attendants arm the escape slide mechanism of the entry doors in case a ground evacuation becomes necessary. When the checks are complete and the aircraft is ready for gate departure, the ground crew becomes the pushback crew.
Gate Departure
Once the agent moves the jetbridge out of the way, the pushback crew advises the cockpit that the wheel chocks are removed and that it is safe to release the parking brake. The Captain acknowledges release of the parking brake and signals the First Officer to call ramp control (or ATC, depending on local requirements) for pushback clearance. Usually, the cockpit crew is advised by the pushback crew that the area is clear for engine start.
Under certain weather conditions, ice or frost may be present on the airframe or airfoil surfaces which require removal before take-off. In situations where de-icing or anti-icing is required, the Captain delays the engine start while the push crew positions the aircraft in a designated de-ice location. At many airports, secondary de-icing locations are established nearer to the departure runway in order to keep the time to take-off below the holdover time. The holdover time is the length of time (in minutes) that the anti-icing fluid is effective and is determined by the flight crew from tables in their flight manuals. The time may vary according to temperature, type, and intensity of precipitation, and type and concentration of fluid used. Once the anti-ice application is complete, the icing coordinator advises the cockpit crew when the holdover time begins. It is then the responsibility of the Captain to monitor the holdover time versus take-off time. If the delay before take-off is too long, the aircraft may have to return to a de-icing location to be re-treated.
After the engines are started and the towbar is disconnected, the Captain gives the guideman permission to disconnect the interphone headset. The guideman then steps into a position where he is visible from the flight deck, shows the nulling pin (used to disable the aircraft’s nosewheel steering system during pushback), and gives a salute which confirms the ramp area is clear to taxi. The Captain acknowledges the salute and the First Officer calls for taxi clearance. Once clearance is received, the Captain begins the taxi-out only after both pilots have visually checked outside and verbally announced “clear left” and “clear right”.
Taxi-Out
As in the case of pushback, anytime ground movement is initiated, permission must be received from the controlling authority. At some point before leaving the ramp area, the First Officer contacts ground control to get taxi clearance to the active runway.
At this stage, any Last Minute Changes (LMC) to the load sheet are received via ACARS or by radio. These may result in the reprogramming of affected parameters and too high take-off weight may dictate the request for a special runway which can result in a taxi and/or take-off delay while ATC works out a modified sequence. Once the load sheet information is processed, the crew completes the “taxi” and “before take-off” checklists.
At some point, the Captain conducts a take-off briefing which includes which pilot will be making the take-off, initial heading, altitude and departure procedure requirements, obstacle clearance and noise abatement issues, airport elevation, and the normal cleanup altitude. In addition, the briefing must address runway abort considerations, engine out procedures and associated cleanup altitudes, and emergency contingencies requiring a return to the departure point or other proximate landing options.
In situations where there will be a long taxi due to numerous departures ahead in sequence for take-off, it is desirable for the Captain to make a PA announcement informing the passengers and cabin crew of their best estimate of the length of the delay. This is typically done by counting the number of aircraft ahead in the take-off queue. If the delay is significant, the airline may have to be updated via ACARS or radio with a new Estimated Time of Departure (ETD). As the aircraft approaches the departure end of the runway, the Captain makes a departure PA announcement to inform the flight attendants that the take-off is imminent and they should secure themselves at their stations. The Captain must assure that the passenger briefing has been completed, which may be a factor in short taxi-out situations.
Take-Off
In order to make most efficient use of runway resources, the local tower controller often issues a “position and hold” clearance to an aircraft in preparation for final take-off clearance. This allows the aircraft to taxi into position and hold on the departure runway while waiting for other traffic, runway restrictions, or an ATC issued departure time. If this hold time is not required or a departure needs to be expedited, the tower may clear the flight for take-off without holding in position. At this time the crew makes final checks of the wind/weather and the presence of runway contamination. If the flight is following the departure of a large aircraft, adequate wake separation requirements must be assured by confirming that an acceptable interval of time has elapsed before commencing the take-off roll.
Once the take-off clearance is received, the pilots’ roles of Captain/First Officer change to Pilot-Flying/Pilot Not-Flying (PF/PNF) in order to accomplish the procedures commensurate with which pilot is flying the leg. At all times, however, the Captain is still Pilot-In-Command (PIC) and, since he/she remains responsible for the flight, may choose to assume the PF role at his/her discretion. Certain weather conditions (low visibility) or crew experience levels may dictate that the Captain remain PF during some or all of the flight.
During the take-off roll, the crew monitors the aircraft centerline tracking, engine parameters, and conditions both inside and outside of the aircraft. The PNF calls out each V-speed as part of the normal procedure. Should a critical problem occur before the abort decision speed, V1, the take-off is rejected and the aircraft is stopped on the runway.
An uneventful take-off is followed by a normal initial climb-out which includes “cleaning up” the aircraft (gear raised, flaps/slats retracted) while conforming to any noise and/or obstacle requirements.
Terminal Area Departure
The climb flight profile is determined by both ATC/airspace requirements, and performance characteristics which may be aircraft-specific. When clear of the immediate airport traffic area, the aircraft is accelerated to maximum low altitude climb speed unless a restriction has been issued by ATC. Terminal area airspace may be very complex and certain standard procedures have been developed for both departing and arriving flights at high-density locations. During climb-out the flight typically conforms to a standard Departure Procedure (DP).
As the aircraft climbs through approximately 1,500 feet Above Ground Level (AGL), the flight attendants are notified (by a chime) that they may commence their service duties. When 10,000 feet MSL is reached, the aircraft is accelerated to the optimal climb speed. In addition, the flight attendants are again chimed to indicate the end of the sterile cockpit period.
Climb
The dynamics of the flight environment, including accommodation of ATC directives, require the crew to continuously monitor aircraft performance in order to realize the best possible flight profile. At some point during the climb, the cockpit crew checks the FMS and/or performance charts to compare the optimal and maximum cruise altitudes with the planned data and desired cruise Mach. This information is used to coordinate an optimal cruise altitude with ATC. Other factors include wind data and ride (turbulence) conditions, en route convective weather, MEL contingencies, traffic-induced speed restrictions, and fuel consumption issues. Winds aloft notwithstanding, in most cases higher altitudes provide for more efficient engine operation. If the flight is restricted to a lower altitude due to weather or traffic, the crew must consider the effects on total fuel burn and reserves. In addition, some aircraft types are more fuel-sensitive to off-optimal cruise Mach than others, which may also limit the cruise altitude options.
Passenger-related activities during the climb include beginning the meal and/or beverage service, delivering any marketing PA announcements, and activating any entertainment systems. In addition, the Captain usually makes a PA describing en route flight time and weather conditions, points of interest, arrival estimate, destination weather, and, if applicable, any information concerning the presence of an augmented crew. Seat belt sign usage is at the Captain’s discretion and is typically activated in the presence of adverse ride conditions, or at the flight attendants’ request such as during the meal service. The segment of the Captain’s PA which informs the passengers that “while in their seats they are to keep their seatbelts fastened” is included by many airlines as a standard procedure and a mandatory disclaimer.
Cruise
As cruise altitude is reached, the power settings/Mach target are established, and the crews will report the level to ATC. The crew also performs various administrative duties, including downlinking any departure delay ACARS codes and recording the engine monitor log (if not automated).
During cruise, the crew must maintain a time/fuel log in order to compare planned time and fuel burn performance with the Actual Time of Arrival (ATA) and Fuel On Board (FOB) over each flight plan waypoint. The baseline departure time and take-off FOB is used to generate the ETA/EFOB (Estimated Time of Arrival/Estimated Fuel On Board) log which is usually very accurate. Consideration must be given by the cockpit crew to the possible causes of any deviations from the waypoint ETA/EFOB (including fuel imbalance) and the effect on the destination arrival time and fuel. Potential sources of time/burn variation include winds aloft greater or less than forecast, cruise speed or altitude different than planned, or mechanical problems such as a fuel leak. The cockpit crew also continuously evaluate altitude options. As the aircraft weight decreases due to fuel burn, the optimum cruise altitude typically increases due to better engine efficiency at higher altitudes. Available altitude options may be limited by ATC.
On international flights, transitioning through airspace boundaries under the jurisdiction of other national sovereignties may require supplementary procedures to address local restrictions. These Flight Information Region (FIR) boundaries normally require advance notification via the flight planning process (filed flight plan), and preliminary contact by the aircraft as the flight approaches the boundary. Generally, separate ATC clearances must be issued at each boundary crossing, including entering the oceanic airspace. Before entering such airspace, it is the responsibility of the crew to familiarize themselves with any specific procedural requirements including position reporting, use of datalink, radio communications, and any other airspeed or operational limitations (holding speeds, speed limit below a given altitude, etc.).
The need to deviate from the desired track due to adverse weather is always a possibility. The nature of hazardous weather en route varies with the geographical region (e.g., transcontinental, Caribbean, North Atlantic, etc.) as well as the type of aircraft and the equipment onboard. The procedures and available options for coping with adverse weather are also airspace-dependent.
As in other phases of flight, the crew must be constantly prepared for the possibility of contingencies requiring diversion of the aircraft to an en route alternate airport. In addition to the possible closure of the destination airport (due to weather, power outages, or other field situations), reasons for diverting include medical emergencies (sick passengers/crew), aircraft equipment problems, terrorist activities in-flight, unacceptable holding times, fuel diversion due to wind, or traffic delays. The decision to divert usually includes input from dispatch and must include a clearance from the controller – unless the Captain declares an emergency. If the situation warrants the declaration of an emergency, the flight is given priority handling en route, and the necessary ground and rescue services are assembled to meet the aircraft upon arrival.
Descent
The descent profile is determined by both ATC limitations and optimal aircraft performance. An aircraft operating at typical cruise altitudes (31,000 to 41,000 feet) will nominally initiate the descent at 100 to 130 nautical miles from the destination airport. The distance varies primarily due to ATC restrictions/procedures, but also may be influenced by equipment type and environmental conditions such as winds aloft and turbulence. The initial descent takes place with about 30 to 40 minutes remaining in the flight, at which time the crew begins their approach and landing preparations. An “In Range” message is often transmitted to the destination station either through ACARS or by VHF radio. This message includes the latest touchdown estimate, special passenger requests (wheelchairs/connections), and if not already transmitted, any maintenance discrepancies. The station transmits or uplinks the arrival gate assignment, ground power unit status, and any other relevant status message such as a “tow-in only” requirement for the assigned gate.
During the descent, ATC may issue crossing restrictions which can be part of a published standard arrival procedure or as a response to a traffic sequencing requirement. If the clearance is not issued as an immediate descent, it is the responsibility of the cockpit crew to determine a Top Of Descent (TOD) point which satisfies the crossing restriction.
Ride conditions notwithstanding, it is desirable from an efficiency standpoint to delay the descent as long as possible, then descend at or near engine idle at an optimum speed and meet the restriction within a few miles before the fix to give a margin to ensure the restriction is met. Factors which must be taken into consideration during descent planning include wind direction and intensity for the relevant altitudes, possibility of speed restrictions if not already assigned, high barometric local pressure at the transition level, and turbulence.
The FMS is the primary resource available to the crew for descent planning as restrictions can be programmed directly and a profile calculated. There are other ad hoc methods for determining the distance required to lose a given amount of altitude. The “3 to 1” rule is still used by most pilots to back up the FMS solution in which three miles are required for every 1,000 feet of altitude loss; e.g., 30,000 feet would require 90 miles. Adjustments are then made to accommodate headwinds/tailwinds and anticipated speed restrictions.
Destination weather and the expected approach/runway procedures are major considerations in planning the arrival. The primary source of this information is the Automatic Terminal Information Service (ATIS), although holding delays, weather conditions, and runway operations may be passed along via ATC and/or dispatch. The ATIS provides the current weather, instrument approach procedures in use, and active runways, as well as details concerning runway and taxiway closures, windshear reports, precise visibility values for individual runways, braking capability, bird activity, temporary obstructions (e.g., construction), land and hold short operations utilization, and any other relevant safety-related information.
Once the crew have received the destination weather and approach information, they begin setting up the navigation equipment for the expected arrival procedure. Of primary concern are the current weather conditions versus the available approach procedures. Low ceilings and visibility mandate specialized procedures which in turn require specific navigation equipment necessary for executing the approaches. If the current weather is below the minimums available for the procedure in use, or the necessary equipment is unavailable or inoperative, the crew must consider other options which include holding (if weather improvement is anticipated) or diverting to an alternate airport. Either course of action requires coordination with ATC and the airline’s dispatch office.
After the crew has programmed the navigation systems and FMS for the anticipated procedure, the PF briefs the approach, using the published approach procedure as a reference. Some low visibility weather situations may mandate that the Captain always perform the PF duties to meet standardization requirements during critical low visibility operations. In addition to designating the PF, the approach briefing includes information about the required navaids, key segment and crossing altitudes, approach minimums versus current weather, obstacles and terrain awareness, and the missed approach procedure.
The cabin crew activities during the descent include preparing the cabin and galleys for landing, forwarding connecting gate information to the passengers, completing customs-related documents, forwarding any cabin-related discrepancies to the cockpit, and verifying that seatbelt compliance requirements are satisfied. The Captain’s descent PA announcement usually includes updates of arrival estimates and weather conditions. Any anticipated adverse weather or delays are usually briefed to both cabin crew and passengers.
As the aircraft descends below the transition level, the PNF works on completing the descent checklist which includes monitoring the pressurization, correcting any accumulated fuel imbalance, and calculating and/or reviewing landing data (approach speeds, runway limits). While passing through 10,000 feet, the Captain alerts the cabin crew (by chime or PA) that the sterile cockpit period is in effect and that the final cabin preparations for landing should be completed.
Terminal Area Arrival
Terminal area maneuvering generally begins when the aircraft descends below 10,000 feet about 30 to 40 miles from the destination airport. At this point the flight path is defined by the vectors from ATC. Radar vectors consist of heading directives issued to the pilots and are used by ATC for the sequencing and/or spacing of air traffic. In non-radar environments, the flight is operated along established airways or feeder routes to an initial approach point defined by the approach procedure in use. In either case, the crew must keep a vigilant traffic watch and maintain terrain awareness (using electronic aids, charts, visual, etc.) especially in mountainous areas and/or areas of high traffic congestion
As the flight nears the position where it will commence the approach, the crew may be issued with additional real-time landing information or instructions. Braking action reports are given by previous arrivals and include a qualitative ranking of the braking effectiveness during rollout after touchdown. Certain braking action conditions may require the utilization of specified onboard systems such as autobrakes and/or autospoilers, or may dictate that the flight enter holding until the runway condition can be improved through plowing or chemical treatment. In low visibility conditions, real-time Runway Visual Range (RVR) reports are issued to the arriving flights for the purpose of determining approach legality, or applying other operating restrictions to the flight (e.g., crosswind limitations, autoland requirements, etc.). Microburst alerts and airspeed loss/gain reports from prior arrivals are also passed on to the crew. Adjustments may have to be made to reference landing speeds to operate under such conditions. In many cases, the flight will have to enter holding to wait out low visibility, poor braking, or windshear/microburst conditions.
Final Approach
The aircraft operated by most air carriers are usually equipped to satisfy the navigation requirements of a variety of approach procedures. Precision approaches include Global Positioning System (GPS) autoland, GPS LNAV/VNAV, and Category (CAT) I, II, and III Instrument Landing System (ILS) approaches. Many runways at larger airports utilize the ILS to provide guidance to pilots during instrument conditions along a well-defined path made up of lateral and vertical elements called the localizer and glide slope, respectively.
A non-precision approach is a procedure where lateral track information is provided by a local navigation aid (navaid) or satellite, but vertical guidance is received through barometric referencing or other means not directly associated with the specific runway. As expected, precision approaches provide for operations in much lower ceiling and visibility conditions.
When very low visibility conditions exist, CAT III approaches are mandated which require autoland or Heads Up Display (HUD) guidance. Arrival delays should be anticipated during these operations due to limited spacing and runway options. When Visual Flight Rules (VFR) conditions exist, pilots are encouraged to use all available navaids as a back-up even during visual approaches. In addition, many airfields employ instrument procedures during VFR conditions in order to manage aircraft sequencing or noise restrictions.
At some point during the vectoring or feeder segment, the flight will be “cleared for the approach”. An approach clearance by ATC authorizes the crew to execute the procedures for landing. As mentioned earlier, it is the cockpit crew’s responsibility to determine approach legality. The current weather conditions must be compared to the procedures and equipment available, both ground-based and airborne. Downgrades in onboard automation or displays may dictate higher landing minimums and/or unavailability of certain procedures. Likewise, the inoperative status of any ground components may result in additional landing restrictions. An adverse condition of any required approach facilities is usually reported by ATC or the ATIS, but also may be detected by onboard alerting systems.
Most authorities designate a specific location in the procedure where the current weather must be at or above weather minimums in order for the aircraft to continue on the approach. If the flight passes the designated position with reported weather at or above minimums, it may continue to the missed approach point or decision height, as applicable. If weather conditions are below minimums at the designated position, the procedure must be aborted and other alternatives considered; i.e., diversion, holding, etc.
Runway wind conditions must be addressed by the crew during the final approach and landing. Depending on the wind direction, intensity, and presence of gusts, adjustments may have to be made resulting in a higher planned approach speed. Maximum crosswind limitations vary among equipment type and weather conditions.
In the event the requirements for completing the approach and landing are not satisfied, a “go-around” is executed and a standardized “missed approach procedure” and/or ATC instructions must be followed. Options available following a missed approach include entering holding to wait out whatever unacceptable condition resulted in the aborted landing, diverting to an alternate airport, or, most commonly, accepting ATC vectors to initiate another approach. Many aborted landings are initiated by ATC or the cockpit crew due to traffic on the runway. In most cases a prior arrival failed to clear the runway in a timely manner, but a delayed take-off by an aircraft sitting in position at the threshold can also result in an aborted landing.
If the runway is in-sight and clear when at the decision point, the cockpit crew continues the descent until initiating the landing “flare” maneuver where the descent rate is reduced just before touchdown.
Landing and Rollout
After touching down on the runway, the PF uses reverse thrust, ground spoilers, and wheel braking to decelerate to taxi-speed and vacate the runway. As the aircraft slows to turnoff speed, the Captain and First Officer assume the taxi and communications tasks as per normal ground operations. Once clear of the runway, the crew reports any adverse wind or braking conditions to the tower (in low visibility conditions the crew may also be required to report clear of the runway). After exiting the runway, the First Officer contacts ground control for taxi-in instructions, completes the after landing-taxi checklist, and calls the local ramp control to confirm the arrival gate assignment and occupancy status.
Taxi-In
The pilots use taxiway charts of the destination airport to assist in the execution of taxi clearances given to them by ATC. Pilots must be diligent during ground operations at airports with which they are unfamiliar or that are undergoing construction. Operations during nighttime or heavy precipitation also require special consideration and may substantially impede the overall traffic movement on the airfield. At some point during taxi-in the Captain determines the necessity of starting the Auxiliary Power Unit (APU). In the interest of fuel conservation, an engine may be shut down which may require utilizing the APU, depending on the aircraft type. Normally the APU is started while the aircraft is a few minutes from the gate area, unless it has been determined that ground power will be used. In that case, the APU is not started and an engine is left running after gate arrival until the ground electric is connected by the guide crew.
If the arrival gate is occupied, the aircraft may be required to wait out the delay at a remote location. Occupied gates are often the result of a delayed departure or other operational issues with the aircraft currently positioned at the gate and the anticipated delay should be passed on to ATC and the passengers. Once clearance to the gate is received, the Captain taxis to the ramp area and visually acquires the marshallers. After the crew confirms the gate area is unobstructed, the marshallers utilize lighted wands to signal clearance to taxi to the stop point adjacent to the jetbridge. Often delays are encountered at this point due to the unavailability of the ground crew, carts, or vehicular traffic in the gate area, or a tow-in requirement for the assigned gate (in which the aircraft engines are shut down and a tug is used to tow the aircraft onto the gate position). Some stations utilize automatic parking systems which employ an arrangement of lights and/or signs that the Captain uses for lead-in line and stopping position guidance. In the absence of self-guidance, the marshaller uses wand signals to direct and stop the aircraft at the desired location. Once the brakes are parked, the agent moves the jetbridge into position at the entry door, or in the case of airstair disembarkation, positions the truck(s) under the appropriate exit door(s).
Parking
In most cases, setting the parking brake and opening a cabin door trigger the “IN” event. The “IN” time is used to determine a number of metrics including the length of the flight (which is used to calculate flight crew compensation and legality for subsequent trips), on-time arrival report card, customs and immigration data, and company-specific performance monitoring and scheduling adjustments.
Once a source of ground power is connected (APU or external power cable), the engines are shut down and the crew completes the engine shut-down checklist. The agent verifies the disarming of the doors with the flight attendants and opens the designated exit door(s) to commence passenger disembarkation. Usually any wheelchair passengers or unaccompanied minors are accommodated last. After engine shut down, the ground crew begin unloading and processing the baggage and freight. The flight crew secure the cockpit and cabin before departing the aircraft. At specified outstations, an exterior post-flight walkaround inspection may be required which is completed by the cockpit crew before leaving the gate area. Post-flight inspections are not as thorough as the pre-flight and are usually mandated after the last flight of the day at stations with limited or contract maintenance. Finally, for international operations, any customs/immigration requirements may need to be addressed.
Post-Flight
Upon completion of post-flight duties at the aircraft, the cockpit crew accomplish any required debrief reports while the flight attendants make liquor and duty-free deposits, usually at the station operations. Debriefs/reports are required by the cockpit crew in instances of a declared emergency or ATC violation, significant mechanical failures (including engine shut down), fuel dumping, illness, injury or death of a passenger or crew member, passenger misconduct/smoking, overweight landing, Hazardous Materials (HAZMAT) issues, diversions, high-speed aborts, lightning strikes, near midair collisions, and a number of other situations involving non-standard operations or issues. Once all cockpit and cabin obligations are fulfilled, the crew begins preparations for the next flight leg. In situations where the same aircraft is to be used, a new flight plan is pulled up and the pre-flight sequence starts all over. In most cases, however, the crew must change aircraft and relocate to the new departure gate where the planning/pre-flight duties are repeated. If this is the last flight of the day, the crew is released from duty and typically proceeds to the crew hotel limo in cases of out-of-base layovers, or the bus to the employee parking lot if the inbound flight was the last leg of a sequence.
If the aircraft is to be “turned around” for use in a subsequent leg, maintenance personnel will attempt to meet the flight upon gate arrival. Any discrepancies are discussed with the inbound flight crew and the necessary repairs are begun as soon as possible. If the discrepancy has been reported in-flight, the mechanics often meet the aircraft with replacement parts such as Line Replaceable Units (LRUs) which can often allow repair in the normally-scheduled turnaround window. If the aircraft is not to be used right away, required maintenance may be performed during periods of less demand. In situations where the aircraft is finished for the day, it may be towed or taxied to a remote location, or the hangar, where the requisite maintenance and/or inspections are completed. In addition to maintenance requirements, other post-flight activity conducted by ground personnel include aircraft cleaning and de-catering, security checks, and any required customs inspections. When customs or security inspections are required, delays are often incurred since the outbound crew cannot access the aircraft until the inspection is complete. In any event, it is desirable from an efficiency standpoint that ground service activities associated with the inbound flight such as catering, cleaning, and baggage handling should dovetail with the departure cycles of subsequent flight legs.
Glossary
Global Distribution System
A reservation tool that travel agents use when making an air, hotel, car, or other travel service booking.
Abbreviations and Acronyms
ACARS Aircraft Communication and Reporting System
ADL Additions and Deletions List
AGL Above Ground Level
AOL Air Operating License
API Application Programming Interface
APU Auxiliary Power Unit
ASR Advance Seat Reservation
ATA Actual Time of Arrival
ATC Air Traffic Control
ATIS Automatic Terminal Information Service
BI Business Intelligence
CDL Configuration Deviation List
CPM Container Pallet Distribution Message
CRS Central Reservation System
CUPPS Common Use Passenger Processing System
CUSS Common Use Self Service
CUTE Common Use Terminal Equipment
DP Departure Procedure
EFOB Estimated Fuel On Board
EIS Entry Into Service
EMD Electronic Miscellaneous Document
ESB Enterprise Service Bus
ETA Estimated Time of Arrival
ETD Estimated Time of Departure
ETL Electronic Ticket List
FIR Flight Information Region
FMS Flight Management System
FOB Fuel On Board
GDS Global Distribution Systems
GPS Global Positioning System
HAWB House Air Waybill
HAXMAT Hazardous Materials
HUD Heads Up Display
IAM Identity and Access Management
IATA International Air Transport Association
ICAO International Civil Aviation Organization
IFE In-Flight Entertainment
ILS Instrument Landing System
KPI Key Performance Indicator
LDM Load Distribution Message
LMC Last Minute Changes
LMS Loyalty Management Suite
LRU Line Replaceable Unit
MAWB Master Air Waybill
MEL Minimum Equipment List
MOP Master Operating Plan
MSL Mean Sea Level
NDC New Distribution Capability
O&D Origin and Destination
OADM Oracle Airline Data Model
OAL Other Airline
PF Pilot-Flying
PIC Pilot-In-Command
PIL Passenger Information List
PNF Pilot Not-Flying
PNL Passenger Name List
PSM Passenger Service Message
PTM Passenger Transfer Message
QBG Qurum Business Group
RVR Runway Visual Range
SAMBA Special Advanced Miles & More Business Architecture
SCP SWISS Customer Portal (Swiss.com)
SLA Service-Level Agreement
SPA Special Prorate Agreement
SSR Special Service Request
TOD Top Of Descent
TPM Teletype Passenger Manifest
UCM Unit Load Device Control Message
ULD Unit Load Device
VFR Visual Flight Rules
[1] Business Process Modeling Notation™ (BPMN™)
[2] Amadeus is a GDS owned by the Amadeus IT Group with headquarters in Madrid, Spain.
[3] The basis is a consistent model collaboratively developed and maintained by globally distributed industry working groups that use the Sparx Enterprise Architect tool, including the “industry-agreed vocabulary, data models, and message definitions, as well as the related business process context and requirements”. Oracle® provides a particularly detailed data model as well, the Oracle Airline Data Model (OADM). It is “a standards-based, industry-specific, prebuilt data warehouse database schema with associated analytic models and dashboard” and a key component of the Oracle Passenger Data Management Industry Solution.
[4] CUSTIS is the customer data warehouse of Swiss.com. It also has a front-end application, the SWISS Customer Portal (SCP).
SAMBA is a central system of Lufthansa for loyalty management and is based on the Loyalty Management Suite (LMS) standard solution from Loyalty Partner Solutions (www.loyaltypartner.com/en/press/releases/detail/loyalty-partner-solutions-lps-is-new-miles-more-programme-operator).