Departure Control System (DCS)
Check-in, boarding, weight and balance, and airport operations management. The DCS is a lightweight view of the OMS - no complex syncing required, just real-time status checks.
DCS as OMS View (Not Separate System)
Architecture Philosophy
The DCS is a READ VIEW of the Order Management System, not a separate data store. This eliminates sync issues and ensures real-time accuracy.
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Check-in Request │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ DCS │ │
│ │ │─────► Query OMS: GET /orders/{id}/status │
│ └─────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ IF Order.Status == 'PAID' { │ │
│ │ ALLOW check-in │ │
│ │ GENERATE_PKPASS(Passenger, Flight) │ │
│ │ } ELSE { │ │
│ │ RETURN Error('Payment Required') │ │
│ │ BLOCK check-in │ │
│ │ } │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Benefits: │
│ ✓ No complex PNR sync │
│ ✓ No data reconciliation issues │
│ ✓ Single source of truth (OMS) │
│ ✓ Real-time status always accurate │
│ ✓ Revenue protection built-in │
│ │
└─────────────────────────────────────────────────────────────────┘
Critical Business Rule
┌─────────────────────────────────────────────────────────────────┐
│ │
│ CRITICAL: Check-in PROHIBITED unless Order.Status == PAID │
│ │
│ This prevents revenue leakage. No passenger boards without │
│ confirmed payment. DCS queries OMS in real-time. │
│ │
└─────────────────────────────────────────────────────────────────┘
Scope
Check-in Processing
- Agent check-in (counter, gate)
- Web check-in (WOCI)
- Mobile check-in
- Kiosk check-in (CUSS)
- API check-in
- Advance Passenger Information (APIS)
Boarding Pass Generation
- BCBP standard (IATA Resolution 792, v8)
- PDF417 (printed), Aztec (mobile), QR Code
- PKPASS for Apple Wallet / Google Pay
- Gate reader compatibility
PKPASS Generation (Mobile Boarding)
┌─────────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────────────────────┐ │
│ │ Apple Wallet │ │
│ │ ┌───────────────────────┐ │ │
│ │ │ Boarding Pass │ │ │
│ │ │ │ │ │
│ │ │ PASSENGER │ │ │
│ │ │ JOHN DOE │ │ │
│ │ │ │ │ │
│ │ │ ┌─────────────────┐ │ │ │
│ │ │ │ [QR CODE] │ │ │ │
│ │ │ │ │ │ │ │
│ │ │ └─────────────────┘ │ │ │
│ │ │ │ │ │
│ │ │ FLIGHT SEAT GATE │ │ │
│ │ │ AS456 12A B7 │ │ │
│ │ │ │ │ │
│ │ │ DEPARTURE │ │ │
│ │ │ 14:30 │ │ │
│ │ └───────────────────────┘ │ │
│ └─────────────────────────────┘ │
│ │
│ Features: │
│ • Signed with airline certificate │
│ • Push updates for gate changes │
│ • Automatic display at airport │
│ • Works offline once downloaded │
│ │
└─────────────────────────────────────────────────────────────────┘
Seat Assignment
- Pre-reserved seats
- Auto-assignment algorithms
- Seat map management
- Seat attributes (window, aisle, exit row)
- Blocked seats (crew, operational)
Weight & Balance
- Passenger weights (AHM 560/565)
- Baggage distribution
- Cargo and mail loading
- Fuel load considerations
- Center of gravity calculation (%MAC)
- Load sheet generation
Boarding Control
- Boarding sequence management
- Zone/group boarding
- Priority boarding
- Gate reader processing
- Passenger reconciliation
Research Topics
- BCBP field specifications
- APIS requirements by country
- Weight and balance calculations
- Load sheet formats
- CUPPS/CUSS standards
- Baggage messaging (BSM/BPM/BTM)
- Airport integration protocols
- Irregular operations handling
Architecture Considerations
BCBP Structure
M1DESMARAIS/LUC EABC123 YULFRAAC 0834 226F001A0025 100
│ │ ││ │ │ │ │ │ │
│ │ ││ │ │ │ │ │ └─ Check-in sequence
│ │ ││ │ │ │ │ └────── Seat
│ │ ││ │ │ │ └────────── Julian date
│ │ ││ │ │ └───────────── Flight number
│ │ ││ │ └────────────────── Carrier
│ │ ││ └───────────────────────── Origin/Dest
│ │ │└──────────────────────────────── PNR
│ │ └───────────────────────────────── Electronic indicator
│ └───────────────────────────────────────────────────── Passenger name
└─────────────────────────────────────────────────────── Format code + segments
Data Model
CheckIn
├── FlightKey (Carrier, Number, Date)
├── Passenger
│ ├── Name, PaxType
│ ├── DocumentInfo (APIS)
│ └── FrequentFlyer
├── Seat
├── BoardingPass
│ ├── Barcode (BCBP string)
│ ├── Symbology
│ └── SecurityData
├── Bags[]
│ ├── TagNumber
│ ├── Weight
│ └── Destination
└── Status (CheckedIn, Boarded, NoShow)
Load Sheet Output
Dry Operating Weight (DOW)
+ Passengers × Standard Weight
+ Baggage Weight
+ Cargo Weight
= Zero Fuel Weight (ZFW) ≤ MZFW
+ Trip Fuel
= Takeoff Weight (TOW) ≤ MTOW
- Trip Fuel
= Landing Weight (LDW) ≤ MLW
Integration Points
| System | Direction | Data |
|---|---|---|
| OMS | Query | Order status, passenger data (real-time) |
| Inventory | Outbound | Checked-in counts |
| Flight Ops / Load Control | Bidirectional | Load data, flight status |
| Baggage | Outbound | BSM messages |
| Border Control | Outbound | APIS transmission |
| Airport (CUTE/CUPPS) | Bidirectional | Check-in transactions |
| Gate Readers | Inbound | Boarding scans |
OMS Integration Pattern
DCS does NOT store booking data locally.
For every check-in:
1. DCS calls OMS: GET /orders/{orderId}
2. OMS returns current Order state
3. DCS validates: Order.Status == PAID
4. If valid: proceed with check-in
5. Update Order: Status = CHECKED_IN
Airport Platform Standards
CUPPS (RP 1797)
- Common Use Passenger Processing Systems
- Platform-independent DCS deployment
- Cloud-ready architecture
- Replacing legacy CUTE
CUSS (RP 1706c)
- Common Use Self Service
- Kiosk hardware abstraction
- Standard peripheral APIs
- Document scanning, printing, payment