Skip to content

CARMEN System Architecture: How Rave Fits In

To develop effectively in the airline optimization space, you must understand how your code interacts with the broader system architecture. The Jeppesen CARMEN Crew Pairing System relies on a highly modular and decoupled architecture.

The optimization engine itself is a heavy, mathematically intense solver written in lower-level languages (like C/C++). However, embedding the implementation of feasibility checking and cost calculation rules directly into the source code of the optimization engine is not a practical approach, because airline rules change frequently and require constant "what-if" scenario testing.

Jeppesen solves this by using Rave as an external rule modeling language.

1. The Decoupled Architecture

The architecture separates the mathematical search algorithms from the business logic.

flowchart TD
    subgraph Data Layer
        A[Flight Schedules / Timetables]
        B[Crew Requirements & Parameters]
    end

    subgraph Business Logic Layer
        C[Rave DSL Source Code]
        D[Rave Compiler]
        E[Compiled Dynamic Link Library]
    end

    subgraph Optimization Layer
        F[CARMEN Optimization Engine]
        G[Pairing Generator]
        H[Search Space / Tree Traversal]
    end

    A --> F
    B --> F
    C --> D
    D --> E
    E <-->|Queries Legality & Cost| G
    F --> H

The Workflow

  1. Rule Definition: The Rave Developer writes declarative rules modeling the airline's specific constraints and costs.

  2. Compilation: A compiler translates the Rave specification into a dynamic link library (DLL) or shared object.

  3. Execution: The optimization engine generates sequences of flights (pairings) from the given flight network.

  4. Interrogation: For each generated sequence, the optimization engine calls the compiled Rave library to check feasibility and calculate the pairing cost.

2. Separation of Concerns: The Generator vs. The Rule System

The system is carefully designed so that the external application (the optimizer/generator) supplies the raw input data. This modular separation of concerns means that a user may make adjustments to the rules, the external applications, and the input data completely separately.

When the generator builds a trip, it does not "know" why a trip is illegal; it relies entirely on the boolean responses (True/False) returned by the Rave rule system.