MX2008010680A - Sistema programado de transportacion. - Google Patents
Sistema programado de transportacion.Info
- Publication number
- MX2008010680A MX2008010680A MX2008010680A MX2008010680A MX2008010680A MX 2008010680 A MX2008010680 A MX 2008010680A MX 2008010680 A MX2008010680 A MX 2008010680A MX 2008010680 A MX2008010680 A MX 2008010680A MX 2008010680 A MX2008010680 A MX 2008010680A
- Authority
- MX
- Mexico
- Prior art keywords
- demand
- resources
- time
- schedule
- demands
- Prior art date
Links
- 238000000034 method Methods 0.000 claims abstract description 123
- 239000012634 fragment Substances 0.000 claims abstract description 70
- 230000000295 complement effect Effects 0.000 claims description 3
- 230000004044 response Effects 0.000 claims description 2
- 230000008569 process Effects 0.000 abstract description 72
- 230000006870 function Effects 0.000 description 29
- 238000012423 maintenance Methods 0.000 description 23
- 230000010006 flight Effects 0.000 description 18
- 230000000694 effects Effects 0.000 description 7
- 230000008859 change Effects 0.000 description 6
- 238000013459 approach Methods 0.000 description 4
- 238000002367 polarised neutron reflectometry Methods 0.000 description 4
- 229920000636 poly(norbornene) polymer Polymers 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 238000012360 testing method Methods 0.000 description 3
- 108010078791 Carrier Proteins Proteins 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 230000033228 biological regulation Effects 0.000 description 2
- 230000007423 decrease Effects 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 238000009472 formulation Methods 0.000 description 2
- 230000014759 maintenance of location Effects 0.000 description 2
- 239000000203 mixture Substances 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000012797 qualification Methods 0.000 description 2
- 238000013468 resource allocation Methods 0.000 description 2
- 238000000926 separation method Methods 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 239000003102 growth factor Substances 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 239000003550 marker Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 230000001932 seasonal effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000032258 transport Effects 0.000 description 1
- 238000009966 trimming Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/02—Reservations, e.g. for tickets, services or events
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/40—Business processes related to the transportation industry
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Strategic Management (AREA)
- Economics (AREA)
- Tourism & Hospitality (AREA)
- Human Resources & Organizations (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Marketing (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Quality & Reliability (AREA)
- Entrepreneurship & Innovation (AREA)
- Operations Research (AREA)
- Development Economics (AREA)
- Game Theory and Decision Science (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Primary Health Care (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Métodos para programación de horarios de una operación de transportación tal como la operación de una aerolínea. El método selecciona deseablemente una demanda (100) de transportación que especifica un origen, destino, y tiempo de arribo o partida, y selecciona recursos tales como aeronaves (508), tripulación y puertas de salida. La selección de recursos es deseablemente conducida para optimizar una función de resultado tal como margen de contribución u otro resultado financiero a partir de la operación particular especificada en la demanda. Al desarrollar un fragmento de horario (108), los recursos especificados son comprometidos, y la base de datos de recursos disponibles es modificada (110) para indicar que los recursos no están ya disponibles en los tiempos relevantes. Luego, el sistema trata otra demanda y repite el proceso para desarrollar un horario completo. El sistema puede desarrollar un horario factible, incluso para una operación de transportación compleja en un corto tiempo, típicamente en minutos o menos. Los horarios pueden ser desarrollados utilizando estrategias alternativas y presupuestos, y ser probados una y otra vez.
Description
SISTEMA PROGRAMADO DE TRANSPORTACIÓN
Referencia Cruzada a las Solicitudes Relacionadas Esta solicitud reivindica el beneficio de los datos presentados en la Aplicación de Patente Provisional Nos 60/774,623, presentada el 11 de Enero del 2007, las divulgaciones de éstas están por la presente aquí incorporadas mediante referencia.
Campo de la Invención La presente invención se refiere a métodos y sistemas de programación de horarios de operaciones de transportación.
Antecedentes de la Invención
Las compañías de transportación tales como las aerolíneas enfrentan problemas de enormes proporciones para programar horarios. Un horario que especifica que vehículos y tripulación existe para hacer vuelos específicos a tiempos específicos debe tener en cuenta la disponibilidad de los vehículos a ser usados en la operación y las tripulaciones para operar los vehículos, así también la disponibilidad de los recursos arreglados tales como las puertas del aeropuerto. Cada uno de estos recursos es típicamente manejado mediante conjuntos complejos de reglas que toman en cuenta factores tales como la necesidad de establecer tiempos aparte para
el mantenimiento de aviones; los requisitos difieren entre limitaciones de tiempo de servicio de los miembros de la tripulación y pilotos diferentes establecidas por regulaciones de gobierno o acuerdos de sindicatos.
El sistema de programación de horarios puede empezar con una lista de operaciones, tal como una lista de vuelos a ser volados a tiempos específicos entre aeropuertos específicos, y trata de encontrar un horario que tenga un avión apropiado disponible para todas las operaciones, luego trata de programar las tripulaciones necesarias y sucesivamente. El proceso de establecer el horario actual está generalmente separado del proceso de determinar que rutas de vuelo a que tiempos. Ésto lleva típicamente al uso inadecuado de recursos. Por ejemplo, no hay típicamente retroalimentación que pueda dirigir a la aerolínea a reconocer que un pequeño cambio en un tiempo de salida de un vuelo puede permitir a la aerolínea usar un avión para otro vuelo, de manera que un avión permanece parado con un costo de mies de dólares por hora.
Puede ser deseable obtener un horario optimizado para una aerolínea u otra operación de transportación, tomando en cuenta tanto variables financieras tales como ingresos esperados de cada vuelo y obligaciones impuestas por los recursos tales como disponibilidad de aeronaves. Como primera consideración, debe ser visto que uno puede obtener un horario óptimo mediante aplicar
técnicas de programación lineal convencionales para tratar todas las variables del horario y encontrar el horario que proporcione el retorno financieramente máximo neto. Sin embargo, es posible determinar un horario óptimo para una aerolínea u otra compañía de transportación de cualquier tamaño mediante técnicas matemáticas convencionales. Para una aerolínea con 100 aviones que sirven para 200 vuelos por día, aún asumiendo que los horarios de vuelo son arreglados e ignorar los diferentes arreglos de tripulación posibles, hay 20,000 posibilidades para volar aeronaves particulares en vuelos particulares el primer día. Debido a la aeronave de reposición de vuelos del primer día en varios aeropuertos, cada posibilidad para el primer día produce un conjunto diferente de 20,000 posibilidades para el segundo día, de manera que un horario de dos días puede incluir (20.000)2 o 400,000,000 posibilidades, y un horario de tres días puede incluir (20.000)3 o 8,000,000,000 posibilidades y sucesivamente. Para seleccionar un horario óptimo de un mes o dos se requiere la examinación de un número esencialmente infinito de posibilidades, y está más allá de la capacidad de incluso las computadoras más poderosas. Establecido de otra forma, el problema para obtener un horario óptimo pertenece a una clase de problemas matemáticos referidos como "NP-complejo" tal que la carga computacional incrementa exponencialmente con el número de aeronaves, tripulación y otros elementos a ser tomados en cuenta por el horario.
A pesar del esfuerzo considerable unido al problema de programación de horarios para aerolíneas y otras compañías de transportación, no ha sido desarrollado hasta este momento ningún sistema realmente satisfactorio. En particular se estima que usando las mejores técnicas actuales, las aerolíneas desperdician aproximadamente _ por ciento de sus ingresos debido a las ineficiencias resultantes a partir de la programación de horarios insuficiente. De este modo, antes de la presente invención, han habido una necesidad sustancial desconocida de mejoramiento de programación de horario.
Breve Descripción de la Invención
Un aspecto de la invención proporciona métodos de computadora implementados para generar horarios para una operación de transportación. Un método de acuerdo con este aspecto de la invención utiliza deseablemente una lista ordenada de una pluralidad de demandas para transportación entre una pluralidad de orígenes y una pluralidad de destinos, siendo cada demanda asociada con un origen, una destinación y un tiempo de arribo y salida. El método utiliza deseablemente una computadora para establecer un fragmento de horario para satisfacer una de las demandas en la lista ordenada. El paso de establecer el fragmento de horario incluyendo asignar recursos de una u otra listas de recursos disponibles. Por ejemplo, en el caso de una aerolínea, el
paso de establecer un fragmento de horario comúnmente incluye asignar una puesta del aeropuerto, una tripulación y una aeronave particular. El método de acuerdo con este aspecto de la invención incluye deseablemente modificar una o más de las listas de recursos disponibles para indicar un estado revisado basado en la utilización de los recursos en el paso de establecer horario. El método con mayor preferencia incluye también el paso de repetir los pasos de establecer un fragmento de horario y modificar las listas de recurso disponibles que esos pasos han realizado para la pluralidad de demandas de acuerdo con el orden de las demandas en la lista y de este modo el paso de establecer un fragmento de horario para cada demanda es realizado usando el estado resultante a partir de modificar el paso para la demanda previa siguiente.
Otro aspecto de la invención proporciona métodos adicionales para generar horarios de operaciones de transportación. El método de acuerdo con este aspecto de la invención utiliza deseablemente una lista de una pluralidad de demandas de transportación entre una pluralidad de orígenes y una pluralidad de destinos, siendo cada demanda asociada con un origen, un destino y un tiempo de arribo o salida, y utiliza también una o más listas de vehículos incluyendo identidades de pluralidad de vehículos e información que especifica la localización de cada vehículo contra tiempo. El método de acuerdo con este aspecto de la invención utiliza deseablemente una computadora para seleccionar un vehículo a partir de uno o más
vehículos identificados en la lista de vehículos, seleccionar una de las demandas a partir de la lista de las demandas y establecer un fragmento de horario para satisfacer las demandas seleccionadas mediante asignar el vehículo seleccionado a la demanda seleccionada. Nuevamente aquí, el método incluye deseablemente modificar una o más de las listas de vehículos y lista de demandas para indicar un estado revisado basado en la utilización de vehículos y demandas en el paso de establecer un fragmento de horario. El método de acuerdo con este aspecto de la invención incluye deseablemente repetir estos pasos de manera que la selección y fragmento de horario que establecen pasos sean realizados para la pluralidad de demandas y de esta manera estos pasos sean realizados para cada repetición utilizando el estado resultante a partir del paso de modificación de la repetición previa siguiente.
Como se discute adicionalmente más adelante, modalidades preferidas de métodos de acuerdo con estos aspectos de la invención pueden producir rápidamente horarios utilizables, realísticos, aún para una operación de transportación compleja tal como una aerolínea grande.
Aspectos adicionales de la invención proporcionan sistemas de computadoras y elementos de programación de computadora para implementar métodos de programación de horarios como se discute
anteriormente, y sistemas de transportación que utilizan dichos métodos de programación de horarios.
Breve Descripción de los Dibujos
La FIG. 1 es una tabla de vuelo que representa esquemáticamente ciertos elementos en un método de acuerdo con una de las modalidades de la invención
La FIG. 2 es una tabla de vuelo parcial que representa otros elementos en el método de la FIG. 1.
La FIG. 3 es una representación gráfica de datos de carga de pasajeros histórica.
La FIG. 4 es una representación diagramática de datos de carga de pasajeros ciertamente predichos resumidos a partir de los datos de la FIG. 3.
La FIG. 5 es un tabla de vuelo parcial que representa pasos adicionales del método mostrado en las FIGS. 1 y 2.
La FIG. 6 es otra tabla parcial que representa uno de los pasos de la FIG. 5 en mayor detalle.
La FIG. 7 es una tabla de vuelo parcial adicional que representa otro paso mostrado en la FIG. 5 en mayor detalle.
La FIG. 8, es también otra tabla de vuelo parcial que representa otro paso mostrado en la FIG. 5 en mayor detalle.
La FIG. 9 es una gráfica diagramática de carga de pasajeros esperados contra tiempo de salida.
La FIG. 10 es una vista diagramática de un proceso usado en el método de las FIGS. 1-9.
La FIG. 11 es una tabla de vuelo parcial adicional que representa ciertos pasos utilizados en el método de las FIGS. 1-10.
La FIG. 12 es también otra tabla de vuelo parcial que representa uno de los pasos mostrados en la FIG. 11.
La FIG. 13 es una tabla de vuelo diagramática que representa un proceso de acuerdo con una modalidad adicional de la invención.
La FIG. 14 es una representación esquemática de un sistema de computadora y sistema de transportación utilizado en una modalidad de la invención.
Descripción Detallada
Un proceso de acuerdo con una modalidad de la presente invención es mostrado en forma general en la FIG. 1. El proceso inicia mediante formular un conjunto de nodos de demanda, i.e., demandas de operaciones de transportación asociadas con datos y tiempos particulares en el futuro. En el ejemplo aquí discutido, los nodos de demanda representan demandas de vuelos de aerolíneas de pasajeros, pero otras operaciones de transportación pueden ser tratadas similarmente. En adición a los datos, tiempo de salida, origen, destinación y número esperado de pasajeros en cada clase, los datos que definen cada nodo de demanda deben incluir deseablemente datos adicionales asociados con los resultados a ser alcanzados mediante hacer coincidir la demanda, como por ejemplo, un margen de contribución ideal para operar ("CTM") u otro resultado financiero de la aerolínea a partir de una operación que conoce la demanda utilizando la mejor aeronave posible en el tiempo exacto especificado en la demanda; ingreso esperado por pasajero en cada clase de servicio; e indicación en cuanto a si la operación denotado por el nodo de demanda sirve como un alimentador para tráfico de ruta para otras operaciones en el sistema; y otros factores discutidos más adelante. El sistema puede proporcionar resultados utilizables con nodos d demanda formulados de acuerdo con cualquier esquema razonable. Sin embargo, es altamente deseable para formular las demandas de acuerdo con un proceso tal como el proceso de
formulación de nodo de demanda discutido adicionalmente más adelante.
En el escenario 102 siguiente del proceso, las demandas son establecidas en un orden, aquí referido como orden "topológico". Este orden define el orden en el cual las demandas serán tratadas mediante el sistema en la operación de programación de horario. El paso de ordenar es realizado principalmente mediante sortear las demandas de acuerdo con una o más llaves de selección, estando cada una de dichas llaves de selección basadas en uno o más elementos de los datos asociado con los nodos de demanda. Por ejemplo, los nodos de demanda pueden ser sorteados mediante fechas de salida y tiempo, con o sin otros factores tales como CTM de contribución esperado. Alternativamente, el origen y el destino de los nodos de demanda pueden ser usados como llaves de selección, de manera que los vuelos entre ciudades particulares son establecidas en un grado más alto en el orden.
Una vez que las demandas han sido establecidas en el orden del paso 102, el sistema inicia con un estado de sistema inicial asumido. Este estado de sistema incluye datos que definen disponibilidad de recursos que son requeridos para realizar las operaciones de transportación. Estos recursos incluyen recursos móviles tales como aeronaves u otros vehículos usados en la operación; y miembros de tripulación, así como también recursos
arreglados que pueden estar asociados con puntos de origen o puntos de destino, así por ejemplo, puertas de aeropuerto. El sistema luego trata las demandas en orden de acuerdo con el ordenamiento topológico asignado al paso 102. De este modo, en el paso 106, el sistema simplemente elige la primera demanda que está a la cabeza de la lista ordenada, y trabaja con esta demanda en el paso 108 para calcular un fragmento de horario para esta demanda particular. El proceso para calcular el fragmento de horario involucra la selección de recursos a ser aplicados para hacer coincidir la demanda en tal manera para producir un resultado factible, y deseablemente, el mejor resultado alcanzable dado el estado del sistema. Por ejemplo, el sistema puede buscar para seleccionar una tripulación y aeronave particular que producirá el mejor resultado de operación, tal como el mejor CTM, para el segmento particular. Debe ser apreciado que la optimización del fragmento de horario para una operación particular es un problema relativamente simple; el número de posibilidades para un nodo de demanda dado es enlazado por ele número de recursos disponibles en el sistema, y no crece con el número de nodos de demanda. El proceso de calcular los fragmentos de horario puede incluir adaptación. Como se discute más adelante, el término "adaptación" como es aquí usado se refiere al ajuste de los supuestos iniciales aplicadas en una selección o proceso de optimización. Por ejemplo, mientras una demanda puede especificar una salida de vuelo de Cleveland a las 6:00 p.m con capacidad para 150 pasajeros, el proceso para establecer un fragmento de horario
incluye examinar los resultados que pueden ser alcanzados mediante la salida en tiempos ligeramente posteriores o con una aeronave más pequeña, o ambos.
Una vez que el sistema ha seleccionado un conjunto de recursos factibles, con mayor preferencia óptimo para ser aplicado a la demanda particular bajo consideración, los recursos son comprometidos a la demanda particular que está siendo tratada. Esto resulta en establecer un nuevo estado de sistema en el paso 110. De este modo, la lista de cual aeronave está disponible a qué tiempos es modificada para indicar que la aeronave asignada a la demanda tratada en ele paso 108 no puede ser ya considerada disponible en los datos y tiempo considerado en el paso 108. Similarmente, los miembros de la tripulación asignados a la demanda particular tratada en el paso 108 no estarán más disponibles, y así sucesivamente. El sistema luego retorna al paso 106, sobre el cual el sistema trata la próxima demanda ahora a la cabeza de la lista. De este modo, en cada nuevo ciclo, el sistema considera una demanda y trata de encontrar un conjunto factible de recursos para la demanda, y más deseablemente, un conjunto de recursos óptimos. Este proceso continúa hasta que todos los nodos de demanda han sido procesados, en el paso 112.
Como se establece anteriormente, durante el calculo del fragmento de horario para cada demanda, el sistema evalúa una
función del resultado, regularmente un resultado financiero tal como CTM asociado con el conjunto de recursos asignados a hacer coincidir el nodo de demanda. El sistema también registra este resultado como el resultado esperado para el fragmento de horario y agrega este resultado con los resultados asociados con todos los otros fragmentos de horario previamente calculados para producir un resultado esperado agregado, tal como CTM agregado para el horario como una totalidad. El resultado esperado tal como CTM en este estado de la operación es más exacto que el CTM ideal del nodo de demanda original. El resultado esperado después del cálculo del fragmento de horario refleja resultados que pueden ser alcanzados con recursos disponibles. En algunos casos, el sistema puede no ser capaz de encontrar un conjunto de recursos factible y en este caso, puede dar un resultado indicando que la demanda no será conocida. El sistema también puede llevar la cuenta de estas instancias.
Cuando el sistema ha procesado la última demanda en el paso 112, el sistema ha desarrollado un horario completo que define las asignaciones de recursos para todas las demandas, o al menos aquel subconjunto que puede ser usado mediante los recursos disponibles y que no está excluido por otros criterios discutidos más adelante. El número de cálculos a ser realizados en un ciclo completo a través de los pasos 106-112 para producir un horario completo está limitado y no incrementa exponencialmente con el tamaño de la operación a ser
programada. Todos estos cálculos requeridos para completar un horario completo pueden ser realizados en pocos minutos o menos en una computadora personal convencional programada para realizar las operaciones aquí discutidas. Debido a que la operación de programación de horarios puede ser rápidamente realizada, los supuestos utilizados en desarrollar un horario pueden ser cambiados, y el proceso de programación de horarios puede ser repetido. Como se indica en el paso 114, el sistema de computadora o un operador manual puede observar el resultado agregado a partir de la operación de programación de horarios, por ejemplo, mediante evaluar el CTM agregado, los números de demandas que no son conocidas o similares, y tomar una decisión para repetir el proceso de programación de horarios. Esa decisión puede incluir una decisión en el paso 116 para ajustar el nivel de los recursos hechos disponibles para la operación de programación de horarios, como por ejemplo, el número de aeronaves o tripulaciones, y repetir la operación de programación de horarios en el paso 104 y continuar hasta que el horario adicional completo ha sido completado.
Debido a esto es factible calcular rápidamente horarios, este ciclo puede ser repetido una y otra vez, hasta que un nivel óptimo de recursos que pueda dar el mejor resultado, tal como el CTM mayor o las demandas más bajas no conocidas, es encontrado. Alternativa o adicionalmente, el sistema o un operador manual puede instruir al sistema para cambiar ya sea los supuestos utilizados para formular
las demandas en el paso 100, o el orden del sorteo aplicado en el paso 102 de ordenación topológica. Por ejemplo, el sistema puede ser usado en conjunción con un módulo de predicción de ingresos que aplica un teoría del juego para probar varios niveles de tarifa, niveles o servicios complementarios (e.g., un permiso de equipaje o servicio de comida asociado a un vuelo) u otros factores contra la información conocida concerniente a la competencia. Los supuestos diferentes aplicados en la teoría de juego producen estimados diferentes de parte del mercado y por lo tanto diferentes números de pasajeros esperados y diferentes ingresos esperados por pasajero en los nodos de demanda. En la estrategia de cambio del paso 118, el sistema de teoría de juego (no mostrado) puede ser instruido para tratar un supuesto diferente que concierne tarifas a ser cargadas o servicios a ser ofrecidos por la aerolínea usando el sistema de programación de horarios y las respuestas de competidores para aquellas tarifas, y que resulta en predicciones diferentes de carga de pasajeros, y por lo tanto demandas diferentes en el paso 100. Los estimados diferentes de parte del mercado pueden ser aplicados a varias porciones de los cálculos de la demanda, como, por ejemplo, partes del mercado diferentes a lo largo de rutar servidas por competidores diferentes. Las llaves de selección y el orden de selección aplicado en el paso 102 de ordenación topológica puede variar también. De este modo, esencialmente cualquier elemento de la estrategia usada por la aerolínea puede ser cambiado. Nuevamente aquí, debido al sistema de programación de horarios
puede generar un horario completo por meses de operación en unos pocos minutos, es factible calcular horarios para numerosos supuestos estratégicos, y de este modo encontrar los mejores supuestos estratégicos.
Un proceso para formular las demandas (paso 100 de la FIG. 1) es mostrado en mayor detalle en las FIGS 1-9. El proceso inicia mediante cargar datos históricos describiendo ventas de boletos por todos los vehículos que sirven las ciudades a ser servidas por la aerolínea. Este dato de pasajeros típicamente es proporcionado en la forma de registros de nombres de pasajero o "PNRs," cada uno de los cuales refleja el viaje por un pasajero individual. Cada PNR refleja típicamente el origen del pasajero y el destino; el precio pagado por transportación entre el origen y destino; la clase de servicio como se definió por el vehículo que transporta al pasajero. Los datos de PNR están disponibles comercialmente dentro de la industria de las aerolíneas. Deseablemente, son utilizados los datos históricos de al menos un año.
En el escenario siguiente 152 del proceso, el sistema compila datos históricos de cada par de ciudades de origen y destino. El sistema puede hacer compilaciones separadas para diferentes conjuntos de días durante el periodo tratado. Por ejemplo, el sistema puede compilar un conjunto de datos para cada origen y destino con respecto a todos los fines días de la semana; o alternativamente, un
conjunto de datos para todos los Lunes durante el periodo histórico en cuestión, otro conjunto de datos para todos los Martes durante el mismo periodo, y así sucesivamente. Cada periodo histórico es deseablemente menos que un año completo como, por ejemplo, un mes, de manera que los conjuntos de datos compilados para diferentes periodos tales como meses diferentes pueden ser comparados uno con otro para detectar patrones de variación estacional. También, conjuntos de datos compilados para periodos históricos diferentes pueden ser comparados uno con otro para detectar tendencias de crecimiento en viajes entre ciudades de destino y origen particulares. Por ejemplo, si mas de un valor de un año de datos está disponible, el número de pasajeros transportado entre una ciudad de origen y una ciudad de destino en días de la semana en febrero de fines de año puede ser comparado con el número comparable para Febrero del año anterior para derivar un estimado de crecimiento año con año. La compilación para cada conjunto de días durante el periodo histórico incluye datos concernientes al número de pasajeros partiendo en cada tiempo de partida particular en cada clase de servicio ofrecido por los vehículos varios que sirven las ciudades durante el periodo histórico en cuestión, y también incluye datos sobre la tarifa promedio pagada por los pasajeros para cada una de dichas clases de servicio.
Los datos del tiempo de partida reflejan el comportamiento de los pasajeros con los horarios ofrecidos por las aerolíneas que sirven
el origen y el destino durante el periodo histórico en cuestión. Estos datos son representados gráficamente en la FIG. 3. Por ejemplo, la barra 154 representa el número de pasajeros que viajan en clase económica en un vuelo de la aerolínea A partiendo a las 8:30 a.m., mientras que la barra 156 representa el número promedio de pasajeros transportados en primera clase en el mismo vuelo de la aerolínea A, mientras que la barra 158 representa el número de pasajeros transportado en un vuelo de clase individual de la aerolínea B partiendo a las 8:45 a.m.
En un paso 160 adicional del proceso, la información histórica es resumida mediante agrupar junta la partida de pasajeros durante un intervalo de tiempo definido referido aquí como una ventana, como por ejemplo, una ventana de una hora o dos horas particular durante el día, y las clases de servicio ofrecido por las diferentes aerolíneas son planeadas para las clases más cercanamente comparables del servicio a ser ofrecido por la aerolínea que está programando horarios. De este modo, el sistema forma un demográfico par de ciudades histórico para cada clase de las aerolíneas siendo programadas para cada ventana. Por ejemplo, como gráficamente se muestra en la Fig. 4, la barra 162 representa el número promedio de pasajeros que parten del origen particular al destino particular en un día de la semana promedio y boletos adquiridos en clases de servicio en todos los vehículos correspondientes aproximadamente a la clase económica de los
vehículos que están siendo programados. Similarmente, la barra 164 representa el número promedio de pasajeros de primera clase durante la misma ventana en un día de la semana promedio. Si bien los procesos de compilación y abstracción 152 y 160 son mostrados como procesos separados para claridad de ilustración, estos procesos pueden ser encimados. Por ejemplo, cada registro de PNR es examinada, la clase de servicio puede ser trasladada a partir de la clase de servicio actualmente utilizado por el vehículo con la clase promedio de servicio del vehículo siendo programado.
En efecto, cada ventana representa un mercado de pasajeros potencial que es distinto, hasta cierto punto, de los mercados representados por otras ventanas durante el día. Los tamaños de las ventanas pueden variar de pares de ciudades diferentes mediante la selección manual o automática dependiendo de factores tales como el número de vuelos que sirven los pares de ciudades. Por ejemplo, donde dos ciudades están conectadas por únicamente dos vuelos por día, el tamaño de ventana puede ser de 12 horas; donde las ciudades están conectadas por docenas de vuelos por día (tal como Nueva York o Chicago), el tamaño de ventana puede ser menor de una hora.
El sistema puede asignar un tiempo de salida arbitrario dentro de la ventana usada en el proceso de abstracción, como por ejemplo el centro de la ventana. Con mayor preferencia, el sistema computa
el tiempo de partida principal de los pasajeros incluido en el demográfico basado en los tiempos de partida históricos incorporados en el demográfico, y asignar ese tiempo principal como el tiempo de partida del demográfico del par de ciudades. El sistema puede también obtener una medida de la variación de tiempo en el demográfico, Le., una medida de la relación entre tiempo dentro de la ventana y número de pasajeros.
El sistema también computa una tarifa histórica promedio en términos de las clases de servicio a ser ofrecidas mediante el vehículo que está siendo programado. De este modo, como la clase de viaje para cada registro de nombre de pasajero es igualado con una clase comparable al vehículo que esta siendo programado, una tarifa histórica pagada por el pasajero en cuestión es tomada como una tarifa la cual el mismo pasajero pudo haber pagado para un viaje en la clase comparable en el vehículo siendo programado. Estas tarifas son promediadas para todos los pasajeros incluidos en el demográfico para producir una tarifa histórica promedio asociada con la clase y ventana.
De este modo, en la conclusión de la compilación y proceso de abstracción, el sistema tiene un conjunto de demográficos de pares de ciudades históricos para cada para de ciudades de origen y destino. Cada demográfico de par de ciudad histórico incluye un tiempo de partida, un número de pasajeros, y una tarifa promedio
para cada clase de servicio del vehículo que está siendo programado, y puede incluir datos adicionales tales como una medida de la variación en el tiempo de partida.
Estos demográficos de pares de ciudades históricos son luego convertidos en demográficos de pares de ciudades predichas en un paso adicional 168 de este proceso. Como se discute anteriormente, el demográfico histórico para cada par de ciudades representa pasajeros transportados por todos los transportadores. El número de pasajeros en cada demográfico de par de ciudades histórico es multiplicado por un mercado predicho compartido por la aerolínea que está siendo programada en el mercado particular representado por el demográfico. Por ejemplo, si el demográfico de par de ciudades histórico indica que 600 pasajeros de clase turista y 100 pasajeros de primera clase parten de Seattle a Nueva York en un día de la semana promedio entre 6:00 p.m. y las 8:00 p.m., y la parte estimada del mercado alcanzado por el transportador que está siendo programado es 20%, luego el demográfico de par de ciudades predicho indicará que la aerolínea puede esperar 120 pasajeros de clase turista y 20 pasajeros de primera clase. Similarmente, un factor de crecimiento puede ser aplicado para tomar en cuenta el aumento (o disminución) de año a año en el tráfico entre las ciudades de origen y destino. Adicionalmente, una tarifa promedio predicha para cada clase de servicio que la aerolínea realizará está incluida en cada demográfico de par de ciudades. La predicción de parte del
mercado como una función de tarifa promedio puede ser hecha intuitivamente, pero de preferencia es elaborada mediante la aplicación de técnicas tales como teoría del juego que toma en cuenta los comportamientos de competitividad en el mercado. Alternativamente, los datos de tarifa histórica y parte del mercado histórico pueden ser usados basados en el presupuesto de que ninguna de las aerolíneas que sirven el mercado cambiarán su estrategia de establecimiento de precios.
Los demográficos de par de ciudades predichos que resultan del paso 168 son convertidos en nodos de demanda, i.e., demandas individuales para transportación entre orígenes y destinos a lo largo de las rutas cubiertas por la aerolínea que está siendo programada por el proceso mostrado en forma general en la FIG. 5. El en primer paso 180 de este proceso, cada demográfico de par de ciudades es convertido a un demográfico de ruta mediante los pasos mostrados en mayor detalle en la FIG. 6. El proceso de la FIG. 6 asume que la aerolínea ha determinado que pares de ciudades serán servidas por vuelos sin escala, directos, entre ciudades, y por lo tanto como una "ruta". Este sistema tiene una lista de demográficos de par de ciudades y luego trata cada demográfico de par de ciudades en orden. En el paso 185, el sistema selecciona el recorrido más corto a través de todas las rutas disponibles que conectan la ciudad de origen del demográfico de par de ciudades con la ciudad de destino. Por ejemplo, el sistema puede examinar todas las rutas que tienen
sus orígenes en la ciudad de origen del demográfico de par de ciudades y determinar si cualquiera de esas rutas tiene sus destinaciones en la ciudad de destino del demográfico de par de ciudades. Si es así, esa ruta es una ruta sin escala, directa, y por lo tanto la más corta. Si no es así, el sistema puede examinar la ciudad de destino de cada ruta que tiene su origen en la ciudad de origen del demográfico de par de ciudades y seleccionar un conjunto de ciudades que constituyen las ciudades de destino de esas rutas. El sistema puede luego considerar cada uno de dichos destinos por turno, y ver si hay una ruta que tiene su origen en dicha ciudad de destino y su destino en el destino del demográfico de par de ciudades. Si es así, el sistema registra la combinación de distancia agregada de dos rutas y continua dicha examinación hasta que todas éstas combinaciones de dos rutas han sido encontradas. El sistema luego considera las combinaciones disponibles de dos rutas y selecciona la combinación que tiene la distancia total más corta. Si no se encuentra una combinación de dos rutas, el sistema luego puede buscar una combinación de tres rutas de un modo directamente análogo.
En una variante de esta propuesta, el sistema puede tratar ciertas ciudades como ciudades centrales, de manera que si no hay un recorrido de ruta única, directa, el sistema buscará construir recorridos de dos y tres rutas usando vuelos que pasan a través de ciudades centrales. Esto reduce en gran medida el número de
posibilidades a ser consideradas en la formulación de recorridos de dos y tres rutas.
En una variante adicional, el sistema puede excluir rutas que recorren en la dirección equivocada desde la ciudad de origen o desde una ciudad central, i.e., rutas de las cuales la ciudad de destino de la ruta es más lejana desde la ciudad destino del demográfico de par de ciudades que desde la ciudad de origen de la ruta. Esto además limita el número de rutas a ser consideradas para encontrar recorridos de dos o tres rutas. La distancia de cada ruta considerada en este proceso puede ser el millaje geográfico actual entre las ciudades, o puede ser un marcador basado en el millaje geográfico y otros factores tales como tarifas de aterrizaje o congestión en aeropuertos particulares.
Una vez que el sistema ha encontrado el recorrido de ruta más corta para un demográfico de par de ciudades particular, el sistema crea un demográfico de ruta para cada ruta en este recorrido más corto en los pasos 187. Si la ruta más corta ocurre siendo un recorrido de ruta sencilla, i.e., una ruta sin escala, directa, entonces el demográfico de ruta es idéntico al demográfico de par de ciudades original. Sin embargo, si el recorrido es un recorrido multi-ruta, el sistema construye un primer demográfico de ruta que tiene su origen en la ciudad origen del demográfico de par de ciudades, que tiene un destino como el destino de la primera ruta, y que tiene un tiempo de
partida como el tiempo de partida del demográfico de par de ciudades. El ingreso esperado por pasajero para el primer demográfico de ruta es una porción del ingreso esperado por pasajero. La proporción de ingreso esperado puede estar hecho con base en la distancia de la ruta, i.e., el ingreso esperado para la primera ruta puede ser el ingreso esperado para el demográfico de par de ciudades dividido por la distancia total de todas las rutas en el recorrido y multiplicado por la distancia de la primera ruta en si misma. El sistema también crea un demográfico de ruta para la segunda ruta en el recorrido. Este demográfico de ruta tiene su ciudad de partida como la ciudad de destino de la primera ruta, su ciudad de destino como la ciudad de destino de la segunda ruta, y su tiempo de partida igual al tiempo de partida del demográfico de par de ciudades, más el tiempo de vuelo esperado a lo largo de la primera ruta y un descuento para tiempo transferido. Nuevamente aquí, el ingreso esperado para la segunda ruta es una porción del ingreso esperado por pasajero para el demográfico de par de ciudades como un todo, calculado por la distancia como se discute anteriormente para la primera ruta. En el caso de un recorrido multi-ruta, el demográfico de ruta para cada ruta en el recorrido puede ser anotado para indicar que la ruta es ya sea una ruta alimentadora (donde hay una ruta posterior en el recorrido), o una ruta recipiente (donde hay una ruta previa en el recorrido), o ambas.
Una vez que los demográficos de ruta han sido conjuntados para todas las rutas en el recorrido, el sistema vuelve al paso 181 y repite el proceso de los pasos 185 y 187 para el siguiente demográfico de par de ciudades, hasta que todos los demográficos de par de ciudades han sido tratados y convertidos a demográficos de ruta. Cada demográfico de ruta identifica sus fechas de aplicabilidad de la misma manera como un demográfico de par de ciudades. Por ejemplo, un demográfico de ruta derivado a partir de un demográfico de par de ciudades aplicable únicamente los Lunes en Febrero puede, asimismo, también ser aplicable solamente para los Lunes en Febrero.
Después de que los demográficos de ruta han sido formados, estos son usados en el siguiente paso 190 del proceso mostrado en la FIG. 5 para crear una lista inicial de nodos de demanda. Cada ruta es tomada por turno. Por cada ruta, una lista de demográficos de ruta que tienen origen y destinos que corresponden a la ruta en cuestión es compilada a partir de los demográficos de ruta formados en el paso 180. La lista de demográficos de ruta para cada ruta es convertida en un conjunto de nodos de demanda para cada día de aplicabilidad del demográfico de ruta en cuestión. Por ejemplo, un demográfico de ruta aplicable los Lunes en Febrero puede ser convertido en un nodo de demanda para la fecha correspondiente al primer Lunes en Febrero, otro nodo de demanda para la fecha que corresponde al segundo Lunes en Febrero, y así sucesivamente. El
sistema puede también tomar en cuenta un conocimiento a priori o intuitivo disponible para el operador. Por ejemplo, si los datos históricos son compilados para vuelos de la semana, el operador esta conciente de que una fecha particular será un día festivo religioso en el origen o destino, el sistema puede reducir el número de pasajeros para esa fecha particular. Después de que todos los demográficos de ruta que corresponden a una ruta particular han sido procesados, el sistema elige la siguiente ruta y procesa los demográficos de ruta para esa ruta en el mismo modo. Este proceso continúa hasta que todos los demográficos de ruta para todas las rutas han sido procesados. En este punto, hay una lista inicial de nodos de demanda para cada ruta. Cada uno de dicho nodo de demanda incluye todas las características del demográfico de ruta, tal como el origen, el destino, una fecha de partida y tiempo, un ingreso esperado por pasajero para cada clase, y un número esperado de pasajeros en cada clase.
En el siguiente escenario 200 del proceso, el sistema examina los nodos de demanda en la lista inicial como se muestra en mayor detalle en la FIG. 7. Esta examinación inicia con una lista de rutas del paso 202, y toma por turno a cada ruta en el paso 204. Para cada ruta, el sistema obtiene la lista de nodos de demanda para la ruta del paso 206. Esta lista no necesita estar en ningún orden en particular. Una vez que la lista de nodos de demanda para una ruta particular ha sido recuperada, el sistema inicia con un primer nodo de demanda
en la lista. El sistema toma el primer nodo de demanda en la lista en el paso 208 y procesa el nodo de demanda para seleccionar la mejor aeronave a utilizarse en un vuelo conociendo que ese nodo de demanda, i.e., un vuelo desde el origen al destino con un número esperado de pasajeros. El sistema examina todos los tipos de aeronave utilizados por la aerolínea que están siendo programados, y selecciona el tipo de aeronave que, si vuela de la ciudad de origen al destino con el número de pasajeros especificado en el nodo de demanda, producirá el mayor margen de contribución. En este escenario del proceso, la selección de un "mejor" tipo de aeronave es elaborada sin consideración de si una aeronave de este tipo estará en efecto disponible en el tiempo y fecha especificados por el nodo de demanda, y sin consideración del costo que puede implicar hacer que la aeronave esté disponible en el tiempo y fecha especificado, como por ejemplo, transportar la aeronave de una localización distante. De este modo, el margen de contribución caracterizado en este escenario del proceso presenta un límite superior al esperado a partir de conocer el nodo de demanda.
En el siguiente escenario 212 del proceso, el sistema compara el número de pasajeros especificado en el nodo de demanda contra el número de pasajeros que puede ser transportado mediante la mejor aeronave seleccionada en el paso 210. Si el número de pasajeros especificado en el nodo de demanda es menor que o igual a la capacidad de la mejor aeronave seleccionada, el sistema marca
el nodo de demanda como procesado, anota el nodo de demanda con un margen de contribución esperada, y vuelve al paso 208 para procesar el siguiente nodo de demanda. Sin embargo, si el número de pasajeros especificado en el nodo de demanda es mayor que la capacidad de transportación de la mejor aeronave seleccionada, el sistema borra el nodo de demanda original de la lista y separa el nodo de demanda en dos nodos de demanda menores en el paso 214 y adiciona los nodos de demanda más pequeños a la lista de nodos de demanda para la ruta, con lo cual el sistema nuevamente vuelve al paso 208 para tomar el siguiente nodo de demanda no procesado. Uno de los nuevos nodos de demanda más pequeños creados a partir de un nodo de demanda mayor son idénticos al nodo de demanda original, pero cada uno de los nuevos nodos de demanda más pequeños tiene la mitad del número de pasajeros especificado en el nodo de demanda original. Los nodos de demanda adicionales tienen el mismo tiempo de partida como el nodo de demanda original. Los nodos de demanda adicionales son procesados de la misma manera como los otros nodos de demanda en la lista. De este modo, un nodo de demanda mucho mayor pude ser separado en dos nodos de demanda en el primer paso a través del paso 212. Cuando cada uno de estos nodos de demanda más pequeños es procesado, uno o más puede ser nuevamente separado en nodos de demanda más pequeños. También cuando tal nodo de demanda más pequeño, separado es procesado en el paso 210, la mejor aeronave
seleccionada para ese nodo de demanda puede ser diferente de la mejor aeronave seleccionada para el nodo de demanda mayor.
El proceso continua de esta manera hasta que todos los nodos de demanda para la ruta (incluyendo cualquiera de los nodos de demanda más pequeños que resulten a partir de la división en el paso 214) han sido procesados, con lo cual el sistema toma la siguiente ruta en el paso 204 y la lista de nodos de demanda asociados con la nueva ruta y repite el mismo proceso. Esto continúa hasta que todas las rutas han sido procesadas de la misma manera.
La lista de rendimiento resultante de nodos de emana es pasada a un paso adicional 220 (FIGS. 5 y 6). En este paso, el sistema examina la lista de nodos de demanda para cada ruta y determina si un mejor CTM esperado puede ser encontrado mediante combinar nodos de demanda con uno y otro. Este paso selecciona una ruta particular a partir de la lista de rutas y sortea todos los nodos de demanda del paso 200 (FIG. 5) mediante el tiempo de partida. En el paso 224 del paso 220 (FIG. 8), el sistema selecciona un conjunto de nodos de demanda anteriores en la lista seleccionada. El sistema trata luego de crear en el paso 226 un nodo combinado a partir de los primeros dos de los tres nodos seleccionados.
Este proceso computa un rango de tiempos para cada uno de los dos nodos de demanda. Este rango de tiempo para cada nodo de demanda está basado en un estimado de la manera en que la carga de pasajeros variará con el tiempo si un vuelo es cambiado en el tiempo a partir del tiempo especificado en el nodo de demanda. Como se representa gráficamente en la FIG. 9, la variación en la carga de pasajeros con tiempo de partida para un nodo de demanda 250 puede estar representado mediante una función del paso mostrada por las barras rayadas como cruz. La función del paso tiene su valor máximo N250, igual al número de pasajeros en el nodo de demanda, en el tiempo de partida original T250 del nodo de demanda, y que tiene valores progresivamente inferiores para tiempos de partida anteriores y posteriores. El rango de significado para el nodo de demanda puede ser tomado como un tiempo anterior o posterior para el cual la función del paso tiene un valor mayor que algunos números arbitrarios de pasajeros. La función del paso puede estar basada en un supuesto global del sistema como un todo, o alternativamente, puede ser seleccionado basado en un conocimiento a priori asociado con rutas particulares. Por ejemplo, nodos de demanda que sirven destinos de negocios conocidos tales como la Ciudad de Nueva York o Washington, D.C. pueden ser asignados a una función del paso considerablemente limitada para reflejar un supuesto de que los viajeros de negocios generalmente están en un horario fuertemente restringido, mientras que los nodos de demanda que tiene un destino u origen en una locación de descanso tal como
Orlando, Florida, pueden ser asignados a una variación considerablemente más amplia basada en el supuesto de que los viajeros de vacaciones son relativamente insensibles al horario.
En otra modalidad, un estimado de la variación de carga de pasajeros con tiempo de partida puede ser obtenida a partir de datos históricos utilizados para generar los datos de pasajeros históricos y demográficos de par de ciudades. Por ejemplo, si los datos de pasajeros históricos muestran números substancialmente iguales de pasajeros partiendo en varios horarios diferentes, espaciados ampliamente a lo largo del punto medio de la ventana usada en el proceso de abstracción (paso 150), el demográfico de par de ciudades puede ser asignado a una variación grande, y esta variación puede ser asignada a cada uno de los demográficos de ruta derivados a partir de dicho demográfico de par de ciudades en el paso 180 y transportar en adelante en cada nodo de demanda creado a partir del demográfico de ruta. Adicionalmente, la variación para un nodo de demanda particular puede ser de una sola cara o asimétrica sobre el tiempo de partida del nodo de demanda. Por ejemplo, si un nodo de demanda particular es anotado con una indicación de que este nodo de demanda es derivado a partir de un demográfico de ruta que representa el segundo o posterior demográfico de ruta en una ruta multi-recorrido (paso 180), la variación o función del paso puede ser arreglado para declinar gradualmente para tiempos de partida después del tiempo de partida original del nodo de demanda,
pero puede caer abruptamente a cero pasajeros para todos los tiempos de partida antes del tiempo de partida original del nodo de demanda, reflejando la realidad de que si un vuelo que conecta parte temprano, los pasajeros del vuelo más temprano en la ruta no estarán disponibles.
La función que relata el número de pasajeros para el tiempo de cada nodo de demanda tiene un rango de significancia limitado por los tiempos anteriores y posteriores en los cuales cualquier número apreciable de pasajeros representado por el nodo de demanda puede ser deseado para viajar a lo largo de la ruta. Por ejemplo, la función del paso para el nodo de demanda 250 tiene un rango de significancia de tiempo T2SOE hasta el tiempo ?250?_· Otro nodo de demanda 250 que tiene el tiempo de partida T250 tiene una función de variación representada por las barras no sombreadas en la FIG. 9, con un rango de significancia de T252E a T252L. El sistema examina los rangos de significancia de los dos nodos de demanda y determina si los rangos de significancia se enciman. Si estos no se enciman, el intento de combinar estos dos nodos de demanda es abandonado, y el paso 226 está completo. Sin embargo, si estos rangos de significancia se enciman, el sistema selecciona un grupo de tiempos de partida posibles para un nodo de demanda combinado. El tiempo de partida posible más temprano es ya sea el tiempo de salida más temprano en el rango de tiempos abarcados por los rangos de significancia encimados de los dos nodos de demanda, o el tiempo
de partida del nodo de demanda posterior, el cual es más temprano. Por ejemplo, los rangos de significancia de los nodos de demanda 250 y 252 se enciman del tiempo T252E al tiempo T250L. De este modo, el tiempo de partida más temprano posible de un nodo combinado puede ser T252E y el tiempo de partida más tarde puede ser T250L. En realidad los rangos de significancia encimados de los dos nodos de demanda en la misma ruta y en el mismo día indican que un vuelo a lo largo de la ruta de partida durante el rango encimado puede atraer algunos pasajeros asociados con el nodo de demanda más temprana y algunos pasajeros asociados con el nodo de demanda de más tarde. El sistema puede también calcular uno o más tiempos de salida posibles intermedios entre tiempos de salida posibles más tempranos y más tarde. Por ejemplo, el sistema puede calcular un tiempo de salida intermedio como el punto medio entre los puntos de salida posible más tempranos y más tarde.
Para cada tiempo de salida posible, el sistema determina el número de pasajeros esperado para cada tiempo de partida. El sistema evalúa la función del paso para cada nodo de demanda en el tiempo de partida posible y adiciona el valor de las funciones del paso de ambos nodos de demanda para el tiempo de partida particular para producir un número esperado de pasajeros para un nodo combinado que opera a este tiempo de partida posible. Por ejemplo, el número esperado de pasajeros de un vuelo que parte al tiempo T252E es la suma de NA y NB (FIG.9).
El sistema luego calcula la mejor aeronave para el nodo de demanda en cada tiempo de partida posible y calcula el CTM para ese tiempo de partida posible. En el paso de combinar, si el número esperado de pasajeros excede la capacidad de la mejor aeronave, el número esperado de pasajeros es establecido igual a la capacidad de la aeronave. El sistema compara los CTMs para los tiempos posibles de salida y selecciona el mejor como el resultado de combinar los primeros dos nodos de demanda, con lo termina el paso 226. Luego, el sistema trata de combinar los segundos dos nodos de demanda en el paso 240 en exactamente la misma manera y trata de combinar todos los tres seleccionados en el nodo de demanda del paso 242. El proceso de combinar tres nodos de demanda puede suponer que esos nodos de demanda están para ser combinados en dos nodos de demanda que tienen dos tiempos de partida diferentes, y utiliza una pluralidad de tiempos de partida posibles dentro el rango del tiempo de partida del nodo de demanda más tarde o primero al tiempo de partida del nodo de demanda más tarde o tercero y calcula la carga de pasajeros combinada en cada tiempo de partida posible basado en las funciones del paso de las tres demandas seleccionadas, y una vez más selecciona la mejor aeronave y computa CTMs para la mejor aeronave para cada tiempo de partida posible. El mejor CTM agregado para los dos nodos de demanda es el dato de salida del resultado del paso 242.
En el paso 244, el sistema compara los CTMs que resultan de las combinaciones de dos nodos del paso 226 y 240 y la combinación de tres nodos del paso 242, y elige la mejor de esos CTMs y da como dato de salida un resultado que incluye el tiempo de partida posible, el CTM esperado para los nodos combinados, y la identidad de los nodos que serán combinados para producir los nodos combinados, i.e., los primeros dos, los segundos dos, o los tres de los nodos considerados. En el paso 246, el sistema compara el CTM para los datos de salida de los nodos combinados mediante el paso 244 con la suma de los CTMs para los nodos individuales que fueron usados para formar el nodo combinado. Si los nodos combinados producen CTM mayor que la suma de los CTMs para los modos individuales, el sistema se ramifica al paso 248 y remplaza los nodos individuales utilizados para formar el nodo de salida combinado con el nodo o nodos combinados, y luego vuelve al paso 224. Si no es así, el sistema vuelve directamente al paso 224 sin remplazar los nodos individuales. En el paso 224, el sistema toma otro conjunto de tres nodos de demanda, que incluye el último nodo de demanda en el conjunto procesado previamente y los dos nodos de demanda sucesivos. Luego, el sistema trata este nuevo conjunto de nodos de demanda de la misma manera. Esto continúa hasta que no hay más nodos de demanda a ser procesados, con lo cual el sistema se ramifica de vuelta al paso 221 y selecciona la siguiente ruta, que es procesada de la misma manera. Esto continúa hasta que todas las rutas han sido procesadas.
En este proceso de combinación, el sistema puede regresar algunas de las separaciones hechas en el subpaso 214 (FIG. 7) o el proceso de demanda residual 200. Por ejemplo, si un nodo de demanda muy grande fue separado en dos nodos de demanda, los dos nodos de demanda pueden ser combinados nuevamente en un nodo de demanda más grande en el paso 226 o paso 240.
En este punto del proceso, el paso de formular demandas (paso 100 en la FIG. 1) está completo. Luego, el sistema establece los nodos de demanda en un orden, referido aquí como orden topológico. Esto es hecho mediante seleccionar las demandas de acuerdo con una o más llaves de selección. Una llave de selección puede incluir cualquiera de las características de las demandas. Una llave de selección simple consiste de los datos y tiempo de partida especificados en las demandas, de manera que las demandas son establecidas en orden cronológico. Sin embargo, otras llaves de selección pueden ser usadas, como por ejemplo, sortear por CTMs esperados, de manera que los vuelos más redituables son los primeros en el orden topológico, o sortear por la distancia de las rutas, de manera que las demandas de recorrido largo son programadas primero o de manera que las demandas de recorrido corto son primero programadas. También, una aerolínea puede desear dar prioridad a los vuelos entre ciudades centrales designadas de manera que los nodos de demanda que tiene ciudades
centrales como ciudades de origen y de destino son primero tratadas. Como consta anteriormente, una demanda de ruta puede ser marcada como una demanda de ruta alimentadora de un recorrido de multi-ruta, y los nodos de demanda que resultan de la demanda alimentadora son primero tratados. En una variante adicional, estas y otras características de los nodos de demanda pueden ser factores de peso asignados, y una llave de selección compuesta puede ser calculada basada en las características plurales de cada nodo de demanda, elegida por dichos factores. La elección de llave de selección influenciará el resultado alcanzado en la programación de horarios en algún grado. Sin embargo, en la práctica, ha sido encontrado que seleccionar simplemente por fecha de partida y tiempo funciona tan bien o casi tan bien como esquemas más complejos.
El sistema mantiene una base de datos de los recursos necesitados para realizar las operaciones a ser programadas. Para una aerolínea, estos recursos incluyen aviones y miembros de tripulación, de los cuales ambos son móviles, así como también puertas de carga de pasajeros en aeropuertos particulares. Las bases de datos incluyen información acerca de las características de cada recurso, y también contienen información que concierne al estatus de cada recurso en cada tiempo futuro durante la duración del horario que está siendo generado. Para un avión, las características incluirán típicamente el tipo de avión; su capacidad
de asientos en cada clase de servicio; su rango máximo (que puede ser establecido como un tiempo de bloqueo máximo); y el costo de la utilización del avión, establecido típicamente como un costo por hora de vuelo. La información del estatus para un avión para cada tiempo en el horario puede incluir la localización, como por ejemplo, el estacionamiento en un aeropuerto particular o en ruta; una indicación como si el avión está fuera de servicio por mantenimiento; e información acerca de la historia de operación del avión, tal como el número de horas de operación y días calendarizados desde la última revisión de mantenimiento agendada y desde el último recorrido mayor. Para unos miembros de tripulación, las características pueden incluir calificaciones para servir en tipos particulares de aeronaves y lugar de residencia. La información del estatus de cada tiempo puede incluir información tal como si los miembros de la tripulación están en servicio o fuera de servicio; la localización de un miembro en servicio, el número de horas de servicio acumuladas en cada mes y año, y otros datos pertinentes para calcular la disponibilidad de los miembros de la tripulación para vuelos bajo las regulaciones del gobierno pertinentes, contratos sindicales, o políticas de personal de la aerolínea. Las características de un puerta incluyen la identificación de un aeropuerto donde la puerta está localizada, y también incluyen los tipos de aeronave que puede ser acomodada en puertas particulares. Una puerta puede también estar asociada con su costo de ocupación así como puede estar impuesta por partida retrasada de un avión. El estatus para una
puerta típicamente es simplemente una indicación de si la puerta está ocupada o desocupada en cada intervalo durante el horario.
La base de datos es establecida en un estado inicial que representa el estado esperado de los varios recursos en el inicio del horario.
El sistema toma los nodos de demanda en el conjunto ordenada o mediante el paso de ordenar topológicamente y busca calcular un fragmento de horario para cada nodo de demanda. Cada fragmento de horario incluye el origen y el destino del nodo de demanda y las condiciones especificadas para la operación del vuelo que satisfacerán el nodo de demanda. Estas condiciones incluyen una aeronave particular, miembros de tripulación particulares, y una puerta particular. Las condiciones especificadas son seleccionadas de manera que estas son factibles, i.e., de manera que la aeronave existe y no está ocupada; de manera que el espacio o puerta esté disponible; y los miembros de la tripulación estén calificados y disponibles. El sistema también busca los condiciones específicas para el fragmento de horario de manera que una función de resultado que representa una salida esperada para volar el vuelo de acuerdo con las condiciones, cubra un criterio. La función de resultado más común es la distribución del margen esperado a partir de la operación, y el sistema busca maximizar el.margen de contribución esperado a partir de la operación.
El problema de seleccionar las condiciones a ser especificadas en un fragmento de horario puede ser entendido con referencia a la FIG 10. La distancia Di entre la aeronave y las condiciones especificadas representa un margen de contribución negativo o costo asociado al vuelo de la aeronave a partir del origen especificado en la demanda del destino especificado en a demanda, y también incluye un costo, si es aplicable, por reposicionar la aeronave a partir de otro aeropuerto de ser necesario. La distancia D2 representa el costo de proporcionar la tripulación, que incluye ambos costos directos por hora y costo extraordinario tal como la recolocación de miembros de la tripulación, pago por horas extras de los miembros de la tripulación y similares. La distancia D3 entre las condiciones especificadas y los demográficos incorporados en el nodo de demanda representa efectos negativos en el ingreso que resulta de especificar un tiempo de partida diferente al tiempo de partida especificado en el nodo de demanda, como por ejemplo, donde la aeronave especificada no está disponible en la puerta de partida en el tiempo especificado en el nodo de demanda. La distancia D3 también incluye cualquier pérdida de ingreso que resulta de especificar una aeronave que es demasiado pequeña para acomodar la carga de pasajeros esperada. La distancia D4 representa un costo asociado con el espacio o puerta utilizado en el aeropuerto de origen y aeropuerto de destino. El sistema busca seleccionar condiciones tal como la suma de D1-D4 que son un
mínimo dado las restricciones impuestas por el estado en turno de la base de datos de recursos, i.e., disponibilidad de recursos como está indicado en la base de datos. La minimización o maximización no necesita ser una minimización o maximización estrictamente matemática. De otra manera establecido, el sistema no necesita considerar cada alternativa posible, pero puede de hecho considerar solamente algunas alternativas consistentes con los recursos disponibles para alcanzar un mínimo o máximo local. Sin embargo, es generalmente factible considerar la mayoría o todos los recursos disponibles.
Una implementación del proceso utilizado para seleccionar condiciones para fragmentos de horario es mostrada diagramaticamente en la FIG. 11. El proceso inicia mediante ingresar la lista ordenada de nodos de demanda, que resulta del orden topológico del paso anteriormente discutido, en el paso 300. En el paso 302, el sistema verifica para buscar si todos los nodos de demanda han sido tratados. Asumiendo que hay nodos de demanda no tratados, el sistema elige el primer nodo de demanda no tratado en la lista ordenada en el paso 304. En los pasos 306 y 308, el sistema trata de seleccionar la mejor avión entre los aviones que están disponibles para volar el vuelo especificado por el origen, destino y tiempo de partida de la demanda. En estos pasos, el sistema busca para encontrar un avión que, dado el estado actual de la base de datos de los recursos, es indicado como disponible en el
aeropuerto en donde el vuelo tiene su origen, o que puede ser volado del aeropuerto de origen y estar disponible para el vuelo. Entre estas aeronaves, el sistema busca una aeronave particular que tendrá el menor impacto negativo en CTM. Debido a que casi siempre es mejor utilizar una aeronave que ya está estacionada en el aeropuerto de origen, el sistema primero examina los aviones que estarán en el aeropuerto de origen en el tiempo de partida, en el paso 306. Si un avión satisfactorio es encontrado, el sistema se salta el paso 308, y de esta manera, no examina la posibilidad de utilizar aviones que estarán localizados en otros lugares en el tiempo de la operación.
Un proceso de selección utilizable en el paso 306 es mostrado esquemáticamente en la FIG 12. En el paso 309, el proceso selecciona una aeronave a partir de la flota. Si la base de datos de los recursos indica que la aeronave estará atracada en el aeropuerto de origen indicado en el nodo de demanda, ya sea en el tiempo de partida indicado en el nodo de demanda o dentro de alguna ventada predeterminada, tal como una hora después del tiempo de partida, el sistema procede al paso siguiente 312. De otra manera, el sistema descarta la aeronave y vuelve al paso 309 de selección de aeronave. En el paso 312, el sistema checa la base de datos de recursos para determinar si la aeronave ha estado comprometida para otro vuelo o para mantenimiento durante el tiempo requerido para el vuelo especificado en el nodo de demanda. Si la aeronave no está disponible, nuevamente, el sistema descarta la aeronave y vuelve al
paso 309. Si la aeronave está disponible, el sistema también verifica si la aeronave es una aeronave factible para utilizarse en el vuelo especificado en el nodo de demanda. Por ejemplo, el sistema verifica el rango del tipo de aeronave contra la distancia del vuelo entre los aeropuertos de origen y de destino. Si la aeronave no tiene suficiente rango, no es una aeronave factible para el vuelo. Otros factores pueden ser considerados para determinar la factibilidad. Por ejemplo, si el aeropuerto de destino no tiene pista de aterrizaje suficientemente larga para acomodar una aeronave de un tipo particular, cualquier aeronave de ese tipo estará excluida. Asumiendo que una aeronave no está excluida, el sistema en el paso 316 determina la diferencia o "delta" entre el tiempo en que la aeronave estará disponible en la puerta, de acuerdo con la base de datos de recursos, contra el tiempo de partida especificado en el nodo de demanda. Por supuesto, si la base de datos indica que la aeronave estará disponible en el tiempo de partida requerido, la delta podrá ser 0.
En un paso adicional 318, un sistema computa factores de puntuación para utilización de la aeronave seleccionada en el nodo de demanda. Un factor de puntuación está basado en la disponibilidad de la delta de tiempo computada en el paso 316. Este factor de puntuación puede estar basado en un valor arbitrario por minuto establecido por la aerolínea. Alternativamente, este factor de puntuación puede ser computado basado en una medida de variación
en los nodos de demanda, tal como la función del paso que relaciona el número de pasajeros con el tiempo de partida discutido anteriormente con referencia a la FIG. 9. De este modo, si el nodo de demanda incluye una función que relaciona el número de pasajeros con el tiempo de partida tal como la función del paso de la FIG. 9, el sistema puede calcular el número esperado de pasajeros basado en esa función de manera que refleje el efecto de cambio del tiempo de partida para emparejar el tiempo cuando la aeronave estará disponible. La diferencia entre el número de pasajeros en el nodo de demanda y el número de pasajeros que resulta a partir de evaluar la variación con el tiempo puede ser multiplicada por el ingreso por pasajero esperado para tener una puntuación o costo asociado con la disponibilidad retrasada.
Adicionalmente, el sistema computa una puntuación o costo basado en el costo por hora de vuelo del avión actualmente seleccionado. El sistema también computa un delta de asiento, i.e, la cantidad por la cual el número de pasajeros esperado excede el número de asientos en la aeronave. Este costo es simplemente producto de la diferencia entre el número de asientos y el número de pasajeros multiplicado por el ingreso esperado por pasajero en una clase particular. El sistema adiciona las distintas puntuaciones y computa una puntuación total. Esta puntuación total representa el efecto negativo en CTM del vuelo de la aeronave particular, y de este modo representa D† de la FIG. 10, y también representa el
efecto negativo en CTM de cualquier retraso en el tiempo de vuelo causado por la selección de una aeronave particular o cualquier falta de capacidad, y de este modo representa D3 en la FIG. 10. El sistema adiciona la aeronave a una lista de aeronaves factibles. La posición de la aeronave en la lista está basada en la puntuación. Por consiguiente, la lista está topológicamente ordenada de acuerdo a las puntuaciones de las diferentes aeronaves. El sistema vuelve al paso 309 para procesar la siguiente aeronave. Si no hay más aeronaves a ser procesadas, el sistema se ramifica al paso 322 y selecciona la aeronave con el menor puntaje en la lista y se ramifica para la selección de la tripulación al paso 324, FIG. 11. Si no son encontradas aeronaves en la lista, esto indica que no hay aeronaves factibles disponibles en el aeropuerto de origen especificado en el nodo de demanda y el sistema se ramifica al paso 308.
El paso 308 es substancialmente idéntico al paso 306, excepto porque el paso 308 considera solamente aeronaves las cuales no están indicadas como atracadas en el aeropuerto de origen, e incluye subpasos adicionales para determinar, basados en la información de la base de datos de recursos, si la aeronave puede volar al aeropuerto de origen a tiempo para coincidir con el tiempo de partida o dentro de una ventana especificada tal como una hora después del tiempo de partida. También, en el paso 308, la puntuación para cada aeronave incluye un costo por el vuelo del aeropuerto donde el avión está localizado en el tiempo pertinente al aeropuerto de origen. Si no
es encontrado ningún avión en el paso 308, esto indica que el nodo de demanda no puede coincidir con los recursos en el estado indicado por la base de datos. De este modo, no se genera fragmento de horario para el nodo de demanda. En lugar de esto, el nodo de demanda es simplemente marcado en el paso 326 para indicar que este nodo de demanda particular fue esquivado como resultado de que no se cuenta con un avión factible.
Cuando un avión ha sido seleccionado en el paso 306 o 308, el tiempo de partida de la operación del vuelo que sirve el nodo de demanda es ajustado al tiempo en el que la aeronave está disponible, si dicho tiempo es diferente del tiempo especificado en el nodo de demanda. Establecido de otra manera, el sistema adapta el fragmento de horario para hacer coincidir los recursos de la aeronave disponible.
Si un avión es seleccionado en el paso 306 o 308, el sistema pasa a la selección de tripulación del paso 324. El paso de selección de tripulación es realizado en una manera similar a los pasos de selección de avión 306 y 308, De este modo, el sistema examina las tripulaciones disponibles, selecciona aquellas que son factibles, y encuentra la tripulación factible de menor costo. El sistema también considera deseablemente balancear las horas de servicio de la tripulación, de manera que los miembros de la tripulación no excedan las horas máximas de servicio por mes o por año. Por ejemplo, un
costo adicional puede ser asignado a cualquier miembro de la tripulación referido directamente al número de horas de servicio programado previamente para cada miembro de la tripulación durante el mes que está siendo considerado. El paso de selección de tripulación utiliza el tiempo de partida y el tipo de aeronave encontrado en los pasos de selección del avión. De este modo, para ser factible, una tripulación debe estar calificada para volar a bordo del tipo de avión seleccionado en el paso 306 ó 308, y debe estar disponible en el aeropuerto de origen en el tiempo de partida establecido en el paso 306 ó 308. También, la tripulación debe tener suficientes horas de servicio restantes en el tiempo de partida para permitir a la tripulación completar el vuelo. El paso de selección de tripulación puede primero dirigirse a tripulaciones que, de acuerdo con la base de datos de recursos, estarán disponibles en el aeropuerto de origen, y luego se dirige a tripulaciones que pueden ser re-localizadas en el aeropuerto de origen. También, el paso de selección de tripulación puede procesar tripulaciones completas por el tipo de aeronave, y luego, si no puede ser encontrada una tripulación completa, el paso de selección de tripulación puede buscar para encontrar miembros de tripulación individual para formar una tripulación completa. Alternativa o adicionalmente, el paso de selección de tripulación puede tratar miembros de tripulación que no tienen una primera historia de servicio, y luego tratar aquellos miembros de tripulación quienes han tenido historia de servicio desde su último día de descanso anterior. Esto puede ser útil tanto
como el procesamiento de cómputo lo requiera para determinar si un miembro de tripulación particular tiene suficientes horas de servicio restantes dado todas las restricciones en horas de servicio que pueden ser consumidas.
Si no puede ser encontrada la tripulación, el sistema no forma un fragmento de horario, pero en su lugar se ramifica al paso 328 y marca el nodo como esquivado debido a que no hubo tripulación disponible. En una variante, si la falla para encontrar tripulación fue causada por la falta de un miembro de la tripulación con ciertas calificaciones específicas, como por ejemplo, la falla para encontrar un piloto calificado en volar un Boeing 747s, el sistema puede marcar el nodo con esa indicación específica.
Al asumir que una tripulación es encontrada, el sistema computa una puntuación que refleja el costo de la tripulación, como por ejemplo, una puntuación que refleja tanto el salario básico de la tripulación y cualquier pago en premio tal como horas extras, costos de tiempo de espera, y vuelos de re-localización que están asociados con la tripulación. Este puntaje representa D2 en la FIG. 10. Si la tripulación es encontrada, el sistema se ramifica al paso 330 y busca puertas factibles en el origen y destino. Nuevamente aquí, si no se encuentra una puerta, el sistema no forma un fragmento de horario, en su lugar marca el nodo como esquivado debido a la falta de disponibilidad de una puerta en un aeropuerto particular.
Al asumir que una puerta es encontrada, el sistema forma un fragmento de horario e implementa este fragmento de horario mediante marcar la base de datos de recursos para comprometer el avión, la tripulación, y puertas encontradas en los pasos anteriores. De este modo, los recursos son indicados como ocupados durante el tiempo requerido para completar el vuelo. También, el sistema marca la base de datos para indicar que los recursos móviles, incluyendo el avión y la tripulación serán posicionados en el aeropuerto de destino en el tiempo que corresponde al final del vuelo. El sistema además actualiza el estatus de la aeronave para indicar tiempo de vuelo adicional desde el último mantenimiento, y actualiza el estatus de los miembros de la tripulación para indicar el tiempo de servicio adicional que habrán dedicado al vuelo.
En este punto, el fragmento de horario individual está completo. El sistema puede también registrar el margen de contribución esperado del vuelo si voló de acuerdo con el fragmento de horario en el paso 336.
En una variante, el sistema puede probar el fragmento de horario propuesto contra uno o más criterios eliminados antes de comprometer los recursos en el paso 334. Por ejemplo, si el fragmento de horario propuesto puede resultar en un margen de contribución negativo, el sistema no deberá comprometer los
recursos, y en su lugar deberá marcar el nodo de demanda como esquivado debido a CTM negativo y regresar al paso 302. En otra variante, el sistema podrá hacer caso omiso del criterio eliminado si uno o más de los criterios de retención coinciden. Por ejemplo, el sistema puede estar arreglado para retener el fragmento de horario si el nodo de demanda está marcado como un alimentador para otra demanda. En una variante adicional, el criterio de retención puede incluir el servicio a ciudades particulares de importancia particular para la aerolínea. En otra variante más, el sistema puede re-examinar algunas asignaciones de recursos. Por ejemplo, si los resultados de los pasos de selección de aeronave 306 y 308 indican que no hay aeronaves disponibles que coincidan con la demanda, o que la única aeronave disponible que coincide con la demanda producirá resultados pobres debido a que es demasiado pequeña o demasiado larga para el número de pasajeros esperado, el sistema puede examinar aeronaves previamente asignadas a vuelos que arribarán al aeropuerto de origen entro de unas pocas horas después del tiempo de partida de la demanda siendo tratada y determinada si es factible reprogramar esos vuelos de manera que la aeronave arribe más temprano y, si es así cuál será el efecto en la CTM o que otros resultados puede tener. El sistema podrá también buscar reprogramar un vuelo previamente programado si el primer paso indica que la aeronave seleccionada estará disponible después del tiempo de partida en la demanda que está siendo considerada. En una variante adicional, el sistema puede probar el efecto de separar
o combinar las demandas en este estado. Por ejemplo, si hay una demanda con un primer tiempo de partida y 100 pasajeros esperados, y la mejor aeronave disponible tiene 200 asientos, el sistema puede buscar una demanda con otro tiempo de partida y determinar si puede ser más rentable combinar las dos demandas. Este estado puede utilizar un proceso similar como el que se discutió anteriormente con referencia a las FIGS. 7 y 8. Sin embargo, en este caso la examinación de una posible combinación y separación es realizada basada en aquellas aeronaves que pueden estar actualmente disponibles a tiempos de partida de las demandas combinadas o separadas en cuestión, más que en la mejor aeronave posible.
Después de que un fragmento de horario ha sido completado para un nodo de demanda o el nodo de demanda ha sido esquivado, el sistema checa si hay más nodos de demanda a ser tratados en el paso 302. Si es así, el sistema elige el nodo de demanda en el paso 304 y repite los pasos como se discutió anteriormente. Si no hay nodos de demanda adicionales, el horario está completo. El sistema puede dar salida a un CTM esperado total que resulta de adicionar todas los CTMs asociados con los fragmentos de horario individual.
Como se indica anteriormente con referencia a la FIG. 1, el sistema puede ajustar los recursos y repetir ya sea el proceso entero de programación de horarios o una porción del proceso de
programación de horarios. El ajustamiento de los recursos puede estar basado en la información acerca de las causas de es las demandas obtenidas cuando las demandas son marcadas en los pasos 324, 328, y 332. Por ejemplo, si las marcas indican que numerosas demandas están siendo esquivadas por el recortamiento de azafatas calificadas en aviones Embraer, y que este esquivamiento ocurre primariamente el 31 de Marzo o después, el sistema puede ajustar la base de datos de recursos para indicar que hay azafatas adicionales calificadas y señalar una indicación de que tales aeromozas adicionales deben ser contratadas y entrenadas a del 31 de Marzo en adelante. Alternativamente, si las demandas han sido ordenadas de acuerdo con el tiempo de partida y la fecha, el sistema puede recalcular solamente que porción del horario a partir del 31 de Marzo en adelante, y concatenar el horario recalculado con el primer horario calculado antes para el 31 de Marzo para formar un horario compuesto. El CTM total para el horario recalculado puede ser comparada con el CTM para el horario original para determinar si el cambio sugerido en los recursos es económicamente deseable. Asimismo, si las indicaciones de nodo esquivado sugieren que aviones adicionales de un tipo particular pueden hacerse disponibles, el sistema puede alterar la base de datos de recursos para indicar que tales aviones adicionales están disponibles, recalcular el horario de una porción del horario con dicha indicación, y comparar el CTM del horario recalculado con el CTM del horario
original para determinar la ventaja obtenible mediante la obtención o arrendamiento de más aviones.
Un proceso de acuerdo con otra modalidad de la invención, ¡lustrada esquemáticamente en la FIG. 13, utiliza demandas similares a aquellas discutidas anteriormente. Las demandas pueden ser formuladas en el paso 400 por el mismo proceso esencialmente como se discutió anteriormente con referencia a las FIGS. 2-9. Nuevamente aquí, cada demanda puede incluir un origen, un destino, y un tiempo de partida o tiempo de arribo deseado, y también deseablemente incluye información que especifica una carga estimada tal como una carga de pasajeros en cada clase de tarifa en el caso de una aerolínea de pasajeros. Nuevamente aquí, cada demanda puede incluir información relacionada a carga (tal como carga de pasajeros o carga de pasajeros en cada clase de tarifa) para el tiempo de partida o tiempo de arribo, Nuevamente aquí, el sistema mantiene una base de datos de recursos la cual incluye al menos una lista de vehículos, e incluye deseablemente una lista de vehículos que tienen información como se discutió anteriormente tal como el estatus de cada vehículo, como por ejemplo, disposición en una terminal particular tal como un aeropuerto o una ruta, para cada tiempo durante el intervalo futuro que es abarcado por el horario. La base de datos incluye también deseablemente otros recursos, como por ejemplos, puertas de terminal y tripulaciones, e incluye deseablemente la misma información que se discutió anteriormente.
Nuevamente aquí, en el inicio del procedimiento de programación de horarios, la base de datos está en un estado inicial.
El sistema selecciona un vehículo particular a partir de la base de datos del paso 404. Esta selección puede estar basada en una ordenación de vehículos por tipo o incluso por identidad del vehículo. Por ejemplo, una aerolínea puede elegir programar sus aviones más costosos primero, para hacer el mejor uso de estos aviones en particular, en cuyo caso los aviones más costosos pueden ser los primeros en el orden de los vehículos, y por lo tanto, uno de estos aviones más costosos puede ser primero seleccionado.
Habiendo seleccionado un vehículo particular, el sistema en el paso 406 evalúa el estado del vehículo, encuentra el siguiente tiempo cuando el vehículo estará disponible, y selecciona un conjunto de demandas factibles que posiblemente pueden hacerse coincidir mediante la utilización del vehículo seleccionado. Por ejemplo, si el vehículo seleccionado está listado en la base de datos como ocupado por estar en mantenimiento o en operaciones previamente programadas, el sistema puede seleccionar un conjunto factible de demandas mediante excluir aquellas demandas que tienen tiempos de partida largos antes de la fecha y tiempo particular cuando el vehículo se volverá disponible. También, el sistema en este estado puede excluir demandas que no son factibles para el vehículo particular, como por ejemplo, aquellas demandas que
requieren un aeropuerto de destino que tenga luces de pista más pequeñas que las requeridas por una aeronave en cuestión, o que tengan una distancia de vuelo más larga que el rango de una aeronave en cuestión. El sistema también puede excluir demandas que pueden ser técnicamente factibles pero altamente no deseadas para producir un resultado rentable si se sirve con este vehículo en particular, como por ejemplo, demandas con orígenes localizados a mas de una cierta distancia de la localización del vehículo como se indica por la base de datos. Es posible omitir este paso y utilizar como el conjunto de demandas todas las demandas de la base de datos; demandas no factibles pueden ser excluidas durante estados posteriores. Sin embargo, seleccionar un conjunto de demandas factibles reduce el número de cálculos.
En el paso 408, el sistema selecciona una de las demandas en el conjunto del paso 406, y luego, en el paso 410, calcula un fragmento de horario para la demanda basado en el supuesto de que el vehículo particular seleccionado en el paso 404 será utilizado para cubrir la demanda. El paso de calcular un fragmento de horario puede ser realizado utilizando pasos similares a aquellos discutidos anteriormente para seleccionar los mejores recursos, tal como tripulación y puertas, para completar el fragmento de horario y ajusfar el tiempo de partida, si es necesario, a un tiempo de partida del o después del tiempo de disponibilidad de la aeronave. Nuevamente aquí, el sistema calcula una función de resultado en el
paso 412 para el fragmento de horario posible que resulta del paso 410. Como se discutió anteriormente, la función de resultado puede incluir un resultado financiero tal como CTM para el fragmento de horario posible. La función de resultado puede incluir opcionalmente una penalidad por gastar tiempo sin servicio de la aeronave de su tiempo de disponibilidad para el tiempo de partida. En el paso 414, el sistema determina si todas las demandas en el conjunto de demandas del paso 406 han sido procesadas. Si no es así, el sistema vuelve al paso 408, selecciona otra demanda del conjunto, y repite los pasos 410 y 412 para esa demanda, para proporcionar un fragmento de horario posible y la función de resultado asociada para la siguiente demanda. Este proceso continúa hasta que todas las demandas factibles han sido procesadas para producir fragmentos de horario posibles y funciones de resultado asociadas. El sistema luego se ramifica al paso 416, donde selecciona la demanda particular que ha producido la mejor función de resultado, como por ejemplo, el CTM más alto de todas las demandas en el conjunto a partir del paso 406. En esta consideración, si el paso 406 fue omitido o fue utilizado un criterio muy amplio de manera que el conjunto incluyó demandas no factibles, el sistema puede determinar la factibilidad durante el paso de calcular un fragmento de horario posible (paso 410), y puede excluir cualquier demanda que resultó en infactibilidad a partir de la selección del paso 416.
Una vez que el mejor resultado ha sido seleccionado, un fragmento de horario es establecido mediante tomar las condiciones especificadas en el fragmento de horario posible asociado con el mejor resultado y los recursos comprometidos, incluyendo el vehículo seleccionado y otros recursos, para ese fragmento de horario. De este modo, la base de datos es actualizada en el paso 418 a un nuevo estado, que indica que el vehículo seleccionado y cualquier otro recurso utilizado en el conjunto de fragmento de horario está comprometido. Una vez que el nuevo estado ha sido establecido, el sistema vuelve nuevamente al paso 406 y selecciona un nuevo conjunto de demandas factibles para la aeronave seleccionada basado en el nuevo estado. Por ejemplo, si el último pase previo a través de los pasos 406-416 resultó en establecer un fragmento de horario que toma el vehículo de San Francisco como su destino, y que hace el vehículo disponible para utilizarse adicionalmente a las 3:00 p.m. en una fecha particular, el siguiente paso a través de los pasos 406-416 resultará en la selección de la demanda que mejor utilice la aeronave basada en su posición en San Francisco y su tiempo de disponibilidad a las 3:00 p.m en esa fecha. Este proceso continúa hasta el paso 420, el sistema determina que el vehículo está completamente programado a través del intervalo de tiempo a ser cubierto mediante el horario que está siendo generado. Si el vehículo ha sido completamente programado, el sistema checa en el paso 424 para determinar si este es el último vehículo a ser programado. Si no es así, el sistema se ramifica de vuela al paso
404, selecciona el siguiente vehículo y repite los pasos 406-420 con ese vehículo, para desarrollar un horario completo para el siguiente vehículo de la misma manera; y el proceso se repite hasta que todos los vehículos han sido programados, con lo cual el horario está completo.
La programación de horarios de esta manera utiliza, el mismo acercamiento general que se discutió anteriormente con referencia a la FIG. 10, I.E., eligiendo condiciones que minimizan el costo o maximizan algunos otros resultados para una operación de vuelo particular. En esta modalidad, sin embargo, las demandas son dirigidas en el orden en que estas se convierten en factibles para una aeronave en particular. Establecido de otra manera, esta modalidad sigue una aeronave a través del horario y encuentra la mejor utilización para esa aeronave en cualquier tiempo durante el horario, el proceso se repite hasta que la aeronave ha sido completamente programada para los intervalos de tiempo requerido. En una variante de este proceso, el sistema no puede computar el horario entero para cada vehículo antes de seleccionar el siguiente vehículo. Por ejemplo, después de establecer un nuevo estado que registra un fragmento de horario de un vehículo particular, el sistema puede ramificarse de vuelta al paso 404 y seleccionar otro vehículo. El paso de seleccionar un vehículo puede ser configurado en esta modalidad para seleccionar un vehículo de entre todos los vehículos de un tipo particular basado en el número de veces que el vehículo
ha sido seleccionado, de manera que el vehículo que ha sido una menor cantidad de veces seleccionado será elegido. De esta manera, el sistema encuentra esencialmente la mejor utilización para cada vehículo en una primera operación que inicia a partir del estado inicial. Luego, cuando el estado del sistema indica que cada vehículo ha sido programado para una primera operación, el sistema busca una vez más la mejor utilización de cada vehículo para una segunda operación. Este proceso continúa hasta que todos los vehículos han sido programados a lo largo del intervalo de tiempo completo a ser cubierto por el horario.
En cada una de estas modalidades, después de que un horario completo ha sido formulado, ya sea un operador humano o el sistema puede decidir ajusfar los recursos como se indica esquemáticamente en el paso 428, o cambiar la estrategia mediante la cual las demandas son formuladas como se indica esquemáticamente en el paso 430 y repetir el proceso para generar otros horarios. Nuevamente aquí, los horarios desarrollados con varios conjuntos de recursos, y estrategias diferentes pueden ser rápidamente generados y pueden ser comparados uno con otro.
En otra variante, el sistema puede utilizar el acercamiento para programación de horarios de vehículo ordenado discutido anteriormente con referencia a la FIG. 13 para establecer una porción del horario, y puede utilizar el acercamiento de demanda
ordenada discutida con referencia a la FIG 11 para establecer la otra porción del horario. En las modalidades discutidas anteriormente, el proceso de programación de horarios incluye otros recursos además de vehículos, i.e., tripulación y puertas de aeropuerto. En una variante más limitada, los procesos de programación de horarios aquí discutidos pueden ser usados para programar otros recursos. En esta variante más limitada, la base de datos puede incluir solamente información perteneciente a los vehículos.
Los sistemas discutidos anteriormente proporcionan deseablemente tiempos para mantenimiento de vehículos. Por ejemplo, las aeronaves típicamente deben tener un servicio al final de cada vuelo. El mantenimiento de este tipo típicamente requiere un intervalo arreglado y puede ser realizado en cualquier locación. Por lo tanto, el sistema de manera deseable adiciona simplemente un intervalo para mantenimiento al final de cada vuelo. Otro mantenimiento, referido comúnmente como mantenimiento "C" y "D", debe ser realizado en centros de mantenimiento especificados, que pueden o no estar en las terminales servidas por la aerolínea. El mantenimiento de este tipo debe ser realizado a intervalos establecidos por reglas que pueden incluir, por ejemplo, números especificados de horas de vuelo, despegues y aterrizajes, o días del calendario, o alguna combinación de éstos. Como se establece anteriormente , la base de datos de recursos mantenida por ele sistema contiene información del estatus para cada aeronave, que
incluye estos factores. El sistema puede revisar la base de datos o una porción de la base de datos perteneciente a una aeronave particular cada vez que la aeronave es incorporada en un fragmento de horario. Si el estatus de la aeronave al final del nuevo fragmento de horario será tal que la aeronave requiera mantenimiento, el sistema puede simplemente programar la aeronave antes para el mantenimiento particular requerido, marcar la base de datos de recursos para indicar que la aeronave estará fuera de servicio por el intervalo requerido (típicamente días o semanas), y pasar una señal a un sistema de control de mantenimiento o a un operador humano indicando cuando la aeronave estará disponible para mantenimiento y el tipo de mantenimiento requerido. En una variante adicional, si la información del estatus de una aeronave en particular indica que un plazo final para mantenimiento se acerca, el sistema puede establecer un bajo costo artificialmente para la aeronave para volar a un destino o acercar a la base de mantenimiento apropiada, incrementando de este modo la probabilidad de que la siguiente demanda programada llevará a la aeronave a o cerca de la base de mantenimiento. La habilidad para interactuar con los sistemas de mantenimiento y para programar la aeronave realistamente con conocimiento completo del mantenimiento requerido proporciona una ventaja significativa.
Cada uno de los sistemas anteriormente discutidos inicia el proceso de programación de horarios basado en un estado inicial de
la aeronave y otros recursos, y construye la base de datos de estados futuros en los cuales se espera la aeronave esté para generar los fragmentos de horario. Típicamente, el estado inicial es un estado predicho en un tiempo después de que la operación de programación de horarios es realizada. Por ejemplo, una aerolínea puede utilizar un sistema durante Enero para generar un horario para operaciones durante Julio y Agosto, tal horario estando basado en un estado inicial supuesto de la aeronave como de Julio 1. Sin embargo, debido a que el proceso de programación de horarios es extremadamente rápido, puede ser usado como una herramienta de programación de horarios de tiempo real, con un estado inicial que está siendo observado en la base de datos de la programación de horarios. De este modo, el proceso de programación de horarios puede permitir a la aerolínea reaccionar a eventos actuales tales como interrupciones por el clima mediante seleccionar el horario más eficiente para volar de esa fecha en adelante.
En la discusión anterior, la función del resultado ha sido establecida en términos de un resultado financiero, tal como CTM. Sin embargo, también pueden ser evaluados resultados no financieros. Por ejemplo, la función de resultado para una demanda particular puede incluir tiempo de espera para los pasajeros que se transfieren de vuelos alimentadores. El tiempo de espera puede ser independientemente evaluado o puede ser trasladado a un costo financiero que refleje las expectativas de la aerolínea de que un
pasajero que ha sido inconvenido por un tiempo de espera muy largo se convertirá en un cliente menos leal. Tal costo puede ser restado del CTM para producir una función de resultado final.
Los cómputos discutidos anteriormente pueden ser realizados utilizando una computadora 500 convencional para propósitos generales (FIG. 14) que incluye los elementos normales de una computadora, tal como un procesador, y una memoria para almacenar la base de datos de recursos y los fragmentos de horario. La computadora también incluye un elemento de programación que incluye un programador medio 502 de lectura de computadora y un programa almacenado en dicho medio, siendo el programa operativo para hacer que la computadora realice los pasos discutidos anteriormente. El medio 501 puede estar separado de la memoria utilizada para almacenar la base de datos de recursos y fragmentos de horarios, o puede estar integrada a ésta. Por ejemplo el medio 501 puede estar en un disco, memoria en estado sólido o cinta incorporada a la computadora. Como se muestra simbólicamente en la FIG. 14, un sistema para realizar estos cálculos incluye una computadora 500 programada para realizar las operaciones discutidas anteriormente, y también incluye uno o más nodos de entrada 502 para suministrar la información de entrada que al menos define parcialmente los servicios a ser proporcionados en la operación de transportación a ser programada. En la modalidad representada, los nodos de entrada 502 son mostrados como
terminales de entrada, y esos nodos pueden ser usados para suministrar cualquiera de los elementos de la información a ser procesada en los métodos discutidos anteriormente. El sistema incluye adicionalmente al menos un nodo de salida 506 arreglado para recibir información que representa al menos parte de los recursos asignados para fragmentos de horario a partir de la computadora 500. Deseablemente, cada nodo de salida 506 es arreglado para visualizar o sacar esta información en forma legible humanamente, como por ejemplo, en una visualización en pantalla o impresión. Si bien los nodos de entrada 502 y nodos de salida 506 son mostrados separadamente, estos nodos pueden estar combinados con algún otro. Los nodos de entrada y salida pueden estar conectados a una computadora 500 directamente si los nodos están en la misma localización que la computadora. Los nodos 502 y 506 pueden estar dispuestos en localizaciones distantes de la computadora 500, y pueden estar conectados con la computadora mediante cualquier medio adecuado de comunicación, como por ejemplo, mediante una conexión local a través de una red de trabajo tal como el internet 504, representado esquemáticamente en la FIG. 14, los elementos de la computadora 504 son mostrados como un elemento individual en la FIG. 14, los elementos de la computadora 500 pueden estar distribuidos en varias localizaciones conectadas una a otra mediante cualquier medio de comunicación adecuado. También, si bien los nodos de entrada y salida están ligados a la computadora 500 mediante una red de trabajo u otra forma de
comunicación instantánea, esto no es esencial; los nodos de entrada y salida pueden estar arreglados para proporcionar la información de entrada y recibir la información de salida en copia dura o en el medio electrónico adecuado que puede ser físicamente transportado entre los nodos y la computadora.
Los nodos de entrada de la computadora y nodos de salida forman parte de un sistema de transportación más grande que incluye vehículos tales como aeronave 508, y terminales 510 tal como aeropuertos. Como se discutió anteriormente, el horario define rutas entre terminales 510, que corresponden a rutas físicas 512. Los nodos de entrada y salida pueden estar localizados en una u otra de las terminales 510 o en otra localización.
Si bien la invención ha sido aquí descrita con referencia a modalidades particulares, debe de ser entendido que estas modalidades son meramente ilustrativas de los principios y aplicaciones de la presente invención. Por lo tanto, debe ser entendido que pueden ser hechas numerosas modificaciones a las modalidades ilustrativas y que pueden ser inventados otros arreglos sin dejar el espíritu y el alcance de la presente invención como se define mediante las reivindicaciones anexadas.
Claims (22)
1. Un método ¡mplementado de computadora para generar un horario para una operación de transportación, que comprende: a) proporcionar una lista ordenada de una pluralidad de demandas para transportación entre una pluralidad de orígenes y una pluralidad de destinos, estando cada demanda asociada con un origen, un destino y un tiempo de salida o tiempo de arribo; utilizando una computadora para: b) establecer un fragmento de horario para satisfacer una de las demandas en la lista ordenada, el paso de establecer el fragmento de horario que incluye asignar recursos a partir de una o más listas de recursos disponibles, y c) modificar una o más de las listas de recursos disponibles para indicar un estado revisado basado en la utilización de recursos en el paso (b); y d) repetir los pasos (b) y (c) de manera que los pasos (b) y (c) sean realizados para la pluralidad de demandas de acuerdo con el orden de demandas en la lista y de manera que el paso (b) para cada demanda sea realizado utilizando el estado que resulta a partir del paso (c) para la siguiente demanda previa.
2. Un método como se reivindica en la reivindicación 1, en donde el paso de establecer un fragmento de horario para una demanda incluye ajustar un tiempo de partida dentro de un rango de tiempos adyacentes para un tiempo de partida en la demanda.
3. Un método como se reivindica en la reivindicación 2, en donde el paso de establecer un fragmento de horario incluye determinar al menos un resultado basado en la información que se refiere al tiempo de partida para carga para la demanda.
4. Un método como se reivindica en la reivindicación 2, en donde el rango de tiempos es seleccionado basado al menos en parte de los fragmentos de horario previamente determinados para otras demandas.
5. Un método como se reivindica en la reivindicación 1 o la reivindicación 2, en donde el paso de establecer un fragmento de horario es realizado de manera que una función de resultado para el fragmento de horario hace coincidir uno o más criterios.
6. Un método como se reivindica en la reivindicación 1, en donde el paso de proporcionar una lista ordenada incluye establecer una pluralidad de llaves de selección y ordenar las demandas de acuerdo con la pluralidad de llaves de selección, incluyendo al menos uno de (i) un valor de continuidad indicativo de si una demanda particular es una de unas series de demandas a ser servidas exitosamente mediante un vehículo único; (ii) un valor financiero para la demanda y (ii) un tiempo de partida o tiempo de arribo para la demanda.
7. Un método para computadora implementado para generar un horario para una operación de transportación, que comprende: a) proporcionar una lista ordenada de una pluralidad de demandas para transportación entre una pluralidad de orígenes y una pluralidad de destinos, estando cada demanda asociada con un origen, un destino y al menos un tiempo de salida o tiempo de arribo, y una lista de recursos que incluye una pluralidad de vehículos e información que especifica la localización de cada vehículo contra tiempo; utilizando una computadora para: b) seleccionar un vehículo a partir de los vehículos identificados en la lista de recursos; c) seleccionar una de las demandas a partir de la lista de demandas, el paso de seleccionar una de las demandas que incluye evaluar una función de resultado para cada uno de los conjuntos de demandas basados en utilizar el vehículo seleccionado para hacer coincidir esa demanda, el paso de evaluar una función de resultado que incluye ajustar un tiempo de partida dentro de un rango de tiempos adyacente para un tiempo de partida asociado con la demanda basada al menos en parte en un tiempo de disponibilidad del vehículo seleccionado. d) establecer un fragmento de horario para satisfacer la demanda seleccionada mediante asignar el vehículo seleccionado a la demanda seleccionada, y e) modificar la lista de recursos y la lista de demandas para indicar un estado revisado basado en la utilización de vehículos y demandas en el paso (c); y f) repetir los pasos (b) hasta (e) de manera que los pasos (b) a (e) sean realizados para la pluralidad de demandas de manera que el paso (c) para cada repetición sea realizado utilizando el estado que resulta a partir del paso (e) para la siguiente repetición previa.
8. Un método como se reivindica en la reivindicación 7, en donde el paso de evaluar una función de resultado está basado en al menos parte de la información que se refiere a tiempo de partida para carga de la demanda.
9. Un método como se reivindica en la reivindicación 8, en donde el paso de seleccionar una demanda incluye seleccionar la demanda a partir del conjunto que produce la mejor función de resultado.
10. Un método como se reivindica en la reivindicación 5 o la reivindicación 7 o la reivindicación 8, o la reivindicación 9, en donde la función de resultado incluye uno o más valores financieros para el fragmento de horario, y en donde el método incluye adicionalmente el paso de agregar los valores financieros para los fragmentos de horario para derivar un valor financiero agregado para el horario.
11. Un método como se reivindica en la reivindicación 10, en donde cada demanda incluye una carga predicha, el método que incluye adicionalmente el paso de derivar las cargas predichas para las demandas basadas en al menos parte de uno o más estimados del comportamiento del mercado, el método que comprende adicionalmente los pasos de ajustar uno o más de los estimados del comportamiento del mercado, y repetir los pasos antes dichos utilizando los estimados ajustados del comportamiento del mercado.
12. Un método como se reivindica en la reivindicación 1 , en donde el paso de ajustar uno o más de los estimados del comportamiento del mercado incluye ajustar al menos un aspecto de un precio a ser cargado por la transportación y valor a ser ofrecido en dicha transportación y aplicar una relación estimada entre al menos un aspecto del precio y valor y demanda de transportación.
13. Un método como se reivindica en la reivindicación 12, en donde al menos un aspecto del precio y valor incluye al menos un aspecto del precio y valor seleccionado a partir del grupo que consiste de (i) la cantidad a ser pagada por un cliente por transportación; y (i¡) un nivel de servicio complementario proporcionado a un cliente a cambio de un cargo por transportación.
14. Un método como se reivindica en cualquiera de las reivindicaciones 10-13, que comprende adicionalmente los pasos de modificar recursos, repetir los pasos antes dichos para al menos algunas de las demandas utilizando los recursos modificados, y comparar los valores financieros agregados alcanzados con diferentes conjuntos de recursos.
15. Un método como se reivindica en las reivindicaciones 1-14, en donde la lista de recursos incluye una base de datos de recursos disponibles en locaciones y tiempos particulares y en donde el paso de establecer un fragmento de horario para una demanda particular incluye (i) deducir recursos a partir de los recursos disponibles en el origen asociados con la demanda particular, y (ii) adicionar recursos móviles a la base de datos de recursos disponibles en el destino asociado con la demanda para un tiempo que sigue un tiempo complementario esperado de la operación asociada con la demanda.
16. Un método como se reivindica en la reivindicación 15, que comprende adicionalmente el paso de determinar si los recursos disponibles en el origen asociado con la demanda para un tiempo de partida deseado asociado con la demanda son insuficientes para permitir la operación asociada con la demanda y, si así es, determinar a partir de la base de datos si los recursos móviles existen en otra localización y pueden ser re localizados en el origen a tiempo para una operación con el tiempo de partida deseado.
17. Un método como se reivindica en la reivindicación 16, que comprende adicionalmente el paso, si los recursos móviles no pueden ser re localizados en el origen a tiempo para una operación con el tiempo de partida deseado, determinar el tiempo de partida factible más temprano después del tiempo de partida deseado cuando todos los recursos pueden estar disponibles y establecer un tiempo de partida en el tiempo de partida factible más temprano.
18. Un método como se reivindica en la reivindicación 17, que comprende adicionalmente, regresar un mensaje de error indicando que no hay disponibilidad de un recurso particular descartando establecer un fragmento de horario para una demanda particular si no puede ser encontrado un tiempo de partida factible más temprano dentro de un rango de tiempos de partida aceptables, acumular información a partir de una pluralidad de mensajes de error indicativos de cuales recursos limitan la operación del sistema de transportación, ajustar los recursos sensibles para la información acumulada y repetir los pasos antes dichos utilizando recursos ajustados para al menos algunas de las demandas.
19. Un método como se reivindica en la reivindicación 1-14, que comprende adicionalmente compilar los fragmentos de horario para formar un horario y operar el sistema de transportación de acuerdo con el horario.
20. Un sistema de programación de horario para una operación de transportación que comprende: a) al menos un nodo de entrada operable para recibir información de entrada definiendo al menos parcialmente servicios a ser proporcionados en la operación de transportación; b) una computadora conectada a al menos un nodo de entrada de manera que la información de entrada recibida mediante el nodo de entrada será proporcionada a la computadora, siendo la computadora operable en respuesta a la información de entrada para realizar un método como se reivindica en cualquiera de las reivindicaciones 1-18: c) al menos un nodo de salida conectado a la computadora de manera que la información de salida que representa al menos algunos de los recursos asignados a los fragmentos de horario será proporcionada a al menos un nodo de salida.
21. Un sistema de transportación que comprende: a) una pluralidad de aviones; b) una pluralidad de aeropuertos; c) un sistema de programación de horarios como se reivindica en la reivindicación 20, en donde al menos un nodo de salida está disponible en uno o más de los aeropuertos.
22. Un elemento de programación para una computadora que comprende un medio de computadora legible que tiene un programa almacenado en la misma, siendo el programa operativo para hacer que una computadora realice un método como se reivindica en cualquiera de las reivindicaciones 1 a 18.
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US77462306P | 2006-02-21 | 2006-02-21 | |
US79741306P | 2006-05-03 | 2006-05-03 | |
US87983107P | 2007-01-11 | 2007-01-11 | |
PCT/US2007/004382 WO2007098161A2 (en) | 2006-02-21 | 2007-02-21 | Transportation scheduling system |
Publications (1)
Publication Number | Publication Date |
---|---|
MX2008010680A true MX2008010680A (es) | 2009-01-27 |
Family
ID=38437952
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
MX2008010680A MX2008010680A (es) | 2006-02-21 | 2007-02-21 | Sistema programado de transportacion. |
Country Status (9)
Country | Link |
---|---|
US (1) | US8260650B2 (es) |
EP (1) | EP1987482A4 (es) |
JP (1) | JP2009527857A (es) |
KR (1) | KR20080098538A (es) |
AU (1) | AU2007217832A1 (es) |
BR (1) | BRPI0708099A2 (es) |
CA (1) | CA2642742A1 (es) |
MX (1) | MX2008010680A (es) |
WO (1) | WO2007098161A2 (es) |
Families Citing this family (60)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1993260A (zh) * | 2005-02-09 | 2007-07-04 | 三菱电机株式会社 | 列车运行管理*** |
US7664596B2 (en) * | 2006-06-29 | 2010-02-16 | Lockheed Martin Corporation | Air traffic demand prediction |
US20120158441A9 (en) * | 2006-12-22 | 2012-06-21 | Richard Kane | Air taxi logistics system |
EP2122551A4 (en) * | 2007-03-13 | 2011-03-23 | Farecast Inc | TRANSACTION IDENTIFICATION SYSTEM |
US8073558B2 (en) | 2007-10-05 | 2011-12-06 | Honeywell International Inc | Critical resource notification system and interface device |
US8645177B2 (en) * | 2008-10-01 | 2014-02-04 | Accenture Global Services Limited | Single step flight schedule optimization |
US20100082394A1 (en) * | 2008-10-01 | 2010-04-01 | Accenture Global Services Gmbh | Flight Schedule Constraints for Optional Flights |
US9137050B2 (en) | 2009-07-17 | 2015-09-15 | Honeywell International Inc. | Demand response system incorporating a graphical processing unit |
US8782190B2 (en) | 2009-07-17 | 2014-07-15 | Honeywell International, Inc. | Demand response management system |
US8671167B2 (en) | 2009-07-17 | 2014-03-11 | Honeywell International Inc. | System for providing demand response services |
US9124535B2 (en) | 2009-07-17 | 2015-09-01 | Honeywell International Inc. | System for using attributes to deploy demand response resources |
US8671191B2 (en) | 2009-07-17 | 2014-03-11 | Honeywell International Inc. | Installation system for demand response resources |
US9818073B2 (en) | 2009-07-17 | 2017-11-14 | Honeywell International Inc. | Demand response management system |
US8667132B2 (en) * | 2009-07-17 | 2014-03-04 | Honeywell International Inc. | Arrangement for communication about and management of a resource using a mobile device |
US8676953B2 (en) | 2009-07-17 | 2014-03-18 | Honeywell International Inc. | Use of aggregated groups for managing demand response resources |
US20110161121A1 (en) * | 2009-12-25 | 2011-06-30 | International Business Machines Corporation | Method, System, and Article for Management of Travel |
CA2726165A1 (en) * | 2009-12-30 | 2011-06-30 | Trapeze Software Inc. | Method and system for planning paratransit runs |
EP2569752A4 (en) | 2010-05-11 | 2013-05-01 | Primair Inc | SYSTEMS, METHODS AND MACHINE-READABLE STORAGE MEDIA FOR INTERACTION WITH A FLIGHT COMPUTER SYSTEM |
JP5864847B2 (ja) * | 2010-10-28 | 2016-02-17 | 株式会社日立製作所 | 保守管理システム、及び保守管理方法 |
US8630744B2 (en) | 2011-01-28 | 2014-01-14 | Honeywell International Inc. | Management and monitoring of automated demand response in a multi-site enterprise |
US9153001B2 (en) | 2011-01-28 | 2015-10-06 | Honeywell International Inc. | Approach for managing distribution of automated demand response events in a multi-site enterprise |
US8626354B2 (en) | 2011-01-28 | 2014-01-07 | Honeywell International Inc. | Approach for normalizing automated demand response events in energy management control systems |
US20120253878A1 (en) * | 2011-03-29 | 2012-10-04 | Trapeze Software Inc. | Method and system for scheduling paratransit service |
GB2496884A (en) * | 2011-11-24 | 2013-05-29 | Ge Aviat Systems Ltd | System for controlling operation of an airline |
US20130226373A1 (en) * | 2012-02-27 | 2013-08-29 | Ge Aviation Systems Llc | Methods for in-flight adjusting of a flight plan |
US20130253965A1 (en) * | 2012-03-21 | 2013-09-26 | Roshin Joseph | Time dependent transaction queue |
WO2014016999A1 (ja) * | 2012-07-24 | 2014-01-30 | 日本電気株式会社 | データ出力装置、データ出力方法及びプログラム |
US20140081704A1 (en) | 2012-09-15 | 2014-03-20 | Honeywell International Inc. | Decision support system based on energy markets |
US9389850B2 (en) | 2012-11-29 | 2016-07-12 | Honeywell International Inc. | System and approach to manage versioning of field devices in a multi-site enterprise |
US9286801B2 (en) * | 2013-03-06 | 2016-03-15 | International Business Machines Corporation | Leveraging information for use in a traffic prediction scenario |
CN103164581B (zh) * | 2013-03-19 | 2015-06-24 | 天津市市政工程设计研究院 | 基于元胞自动机模型的航空枢纽微观仿真装置 |
US9691076B2 (en) | 2013-07-11 | 2017-06-27 | Honeywell International Inc. | Demand response system having a participation predictor |
US10346931B2 (en) | 2013-07-11 | 2019-07-09 | Honeywell International Inc. | Arrangement for communicating demand response resource incentives |
US9989937B2 (en) | 2013-07-11 | 2018-06-05 | Honeywell International Inc. | Predicting responses of resources to demand response signals and having comfortable demand responses |
US9665078B2 (en) | 2014-03-25 | 2017-05-30 | Honeywell International Inc. | System for propagating messages for purposes of demand response |
EP2927849A1 (de) * | 2014-04-02 | 2015-10-07 | Deutsche Lufthansa AG | Verfahren und Computerprogrammprodukt zur Analyse von Flugpassagier-Ticket-Massendatenbeständen |
US20160055275A1 (en) * | 2014-08-21 | 2016-02-25 | Mengjiao Wang | Large scale flight simulation |
US20160071044A1 (en) * | 2014-09-05 | 2016-03-10 | Amadeus S.A.S. | Flight schedule optimization |
US10671950B2 (en) * | 2014-09-29 | 2020-06-02 | The Boeing Company | Automated buffer setting |
WO2016065466A1 (en) * | 2014-10-27 | 2016-05-06 | Profusion Corp. | Competitive airline market data analysis |
US10748089B2 (en) | 2014-12-24 | 2020-08-18 | General Electric Company | Method and system for automatic evaluation of robustness and disruption management for commercial airline flight operations |
US10546260B2 (en) | 2014-12-24 | 2020-01-28 | General Electric Company | System and method for rule-based analytics of temporal-spatial constraints on noisy data for commercial airlineflight operations |
US9984580B2 (en) | 2015-01-09 | 2018-05-29 | General Electric Company | Method and system for robust network planning optimization of airline flight operations |
US9715695B2 (en) * | 2015-06-01 | 2017-07-25 | Conduent Business Services, Llc | Method, system and processor-readable media for estimating airport usage demand |
EP3314208A4 (en) * | 2015-06-26 | 2018-11-14 | Optibus Ltd. | System and method for real time scheduling |
WO2017026993A1 (en) * | 2015-08-07 | 2017-02-16 | Hewlett Packard Enterprise Development Lp | Airline resource management |
WO2017151087A1 (en) * | 2016-02-29 | 2017-09-08 | Hewlett Packard Enterprise Development Lp | Select recovery plan of subset |
US10277310B2 (en) | 2017-02-15 | 2019-04-30 | Viasat, Inc. | Dynamic spatial allocation of satellite capacity based on mobile vessel load forecasting |
US10541556B2 (en) | 2017-04-27 | 2020-01-21 | Honeywell International Inc. | System and approach to integrate and manage diverse demand response specifications for multi-site enterprises |
US10333987B2 (en) * | 2017-05-18 | 2019-06-25 | Bank Of America Corporation | Security enhancement tool for a target computer system operating within a complex web of interconnected systems |
CN107564269B (zh) * | 2017-08-28 | 2019-10-18 | 华南理工大学 | 一种基于支付意愿的半灵活公交调度方法 |
US11295622B2 (en) | 2018-04-24 | 2022-04-05 | Joby Aero, Inc. | Determining VTOL departure time in an aviation transport network for efficient resource management |
US11301887B2 (en) * | 2018-11-26 | 2022-04-12 | Capital One Services, Llc | Recommendation engine for rideshare system and vehicle routing |
CN110889610B (zh) * | 2019-11-18 | 2023-07-14 | 中国民航信息网络股份有限公司 | 一种旅客保护方法及*** |
CN111062541B (zh) * | 2019-12-27 | 2023-05-26 | 海南太美航空股份有限公司 | 闲置航班分配方法及*** |
CN111415034A (zh) * | 2020-03-11 | 2020-07-14 | 北京光速斑马数据科技有限公司 | 一种智能路线排划方法、***、终端及存储介质 |
US20210295224A1 (en) * | 2020-03-23 | 2021-09-23 | Lyft, Inc. | Utilizing a requestor device forecasting model with forward and backward looking queue filters to pre-dispatch provider devices |
US20230359963A1 (en) * | 2022-05-05 | 2023-11-09 | The Boeing Company | Validation of cost-optimal minimum turn times |
CN114927003B (zh) * | 2022-05-12 | 2023-08-01 | 华设设计集团北京民航设计研究院有限公司 | 一种民用机场机坪智能车辆调度方法和*** |
CN117689163B (zh) * | 2023-12-12 | 2024-06-04 | 中国铁路郑州局集团有限公司科学技术研究所 | 基于图论的铁路专用线作业调控方法 |
Family Cites Families (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5253165A (en) * | 1989-12-18 | 1993-10-12 | Eduardo Leiseca | Computerized reservations and scheduling system |
CA2112077C (en) * | 1993-09-15 | 1999-08-24 | Barry Craig Smith | Network architecture for allocating flight inventory segments and resources |
US6321158B1 (en) * | 1994-06-24 | 2001-11-20 | Delorme Publishing Company | Integrated routing/mapping information |
JP3495118B2 (ja) * | 1994-11-14 | 2004-02-09 | 本田技研工業株式会社 | ナビゲーション装置 |
US5918209A (en) * | 1996-01-11 | 1999-06-29 | Talus Solutions, Inc. | Method and system for determining marginal values for use in a revenue management system |
DE69703938T3 (de) * | 1996-11-22 | 2007-05-16 | (at)Road Ltd., Ipswich | Ressourcenzuordnung |
US5966126A (en) * | 1996-12-23 | 1999-10-12 | Szabo; Andrew J. | Graphic user interface for database system |
US6076067A (en) * | 1997-11-05 | 2000-06-13 | Sabre Inc. | System and method for incorporating origination and destination effects into a vehicle assignment process |
US6754634B1 (en) * | 1998-04-01 | 2004-06-22 | William P. C. Ho | Method for scheduling transportation resources |
US6263315B1 (en) * | 1998-11-02 | 2001-07-17 | Pricing Research Corporation | Revenue management system and method |
US6134500A (en) * | 1999-06-03 | 2000-10-17 | United Air Lines, Inc. | System and method for generating optimal flight plans for airline operations control |
US6408276B1 (en) * | 1999-07-30 | 2002-06-18 | Caleb Technologies Corp. | Crew optimization engine for repair of pairings during irregular airline operations |
US6314361B1 (en) * | 1999-07-30 | 2001-11-06 | Caleb Technologies Corp. | Optimization engine for flight assignment, scheduling and routing of aircraft in response to irregular operations |
US7110960B2 (en) * | 2000-06-09 | 2006-09-19 | Manugistics, Inc. | Event revenue management system |
US6240362B1 (en) * | 2000-07-10 | 2001-05-29 | Iap Intermodal, Llc | Method to schedule a vehicle in real-time to transport freight and passengers |
US20020065699A1 (en) * | 2000-09-14 | 2002-05-30 | Kalyan Talluri | General discrete choice model and optimization algorithm for revenue management |
US7191140B2 (en) * | 2001-05-29 | 2007-03-13 | Navitaire, Inc. | Method and system for generating optimal solutions for open pairings through one-way fixes and matching transformations |
US6804658B2 (en) * | 2001-12-14 | 2004-10-12 | Delta Air Lines, Inc. | Method and system for origin-destination passenger demand forecast inference |
US20030191678A1 (en) * | 2002-04-03 | 2003-10-09 | Shetty Ravindra K. | Disruption handling for scheduling system |
US20040107110A1 (en) * | 2002-12-02 | 2004-06-03 | Jens Gottlieb | Optimization of transport with multiple vehicles |
US7010494B2 (en) * | 2003-03-27 | 2006-03-07 | University Of Washington | Performing predictive pricing based on historical data |
US20050071206A1 (en) * | 2003-04-30 | 2005-03-31 | The Boeing Company | System, method and computer program product for schedule recovery |
US7957987B2 (en) * | 2004-04-30 | 2011-06-07 | Eds South Africa (Pty) Ltd. | Using software agents to schedule airline flights |
US7707056B1 (en) * | 2005-04-28 | 2010-04-27 | Southwest Airlines Co. | Generating and tuning an allocation of transportation resources |
-
2007
- 2007-02-21 JP JP2008556386A patent/JP2009527857A/ja not_active Withdrawn
- 2007-02-21 KR KR1020087023018A patent/KR20080098538A/ko not_active Application Discontinuation
- 2007-02-21 MX MX2008010680A patent/MX2008010680A/es not_active Application Discontinuation
- 2007-02-21 US US11/709,302 patent/US8260650B2/en active Active
- 2007-02-21 CA CA002642742A patent/CA2642742A1/en not_active Abandoned
- 2007-02-21 EP EP07751161A patent/EP1987482A4/en not_active Withdrawn
- 2007-02-21 WO PCT/US2007/004382 patent/WO2007098161A2/en active Application Filing
- 2007-02-21 BR BRPI0708099-9A patent/BRPI0708099A2/pt not_active Application Discontinuation
- 2007-02-21 AU AU2007217832A patent/AU2007217832A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
KR20080098538A (ko) | 2008-11-10 |
CA2642742A1 (en) | 2007-08-30 |
US20070214033A1 (en) | 2007-09-13 |
WO2007098161A3 (en) | 2008-02-21 |
US8260650B2 (en) | 2012-09-04 |
EP1987482A4 (en) | 2011-04-20 |
BRPI0708099A2 (pt) | 2011-05-17 |
AU2007217832A1 (en) | 2007-08-30 |
EP1987482A2 (en) | 2008-11-05 |
WO2007098161A2 (en) | 2007-08-30 |
JP2009527857A (ja) | 2009-07-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8260650B2 (en) | Transportation scheduling system | |
US20080059273A1 (en) | Strategic planning | |
Eltoukhy et al. | Airline schedule planning: a review and future directions | |
Kasirzadeh et al. | Airline crew scheduling: models, algorithms, and data sets | |
Gopalan et al. | Mathematical models in airline schedule planning: A survey | |
Ageeva | Approaches to incorporating robustness into airline scheduling | |
Barnhart et al. | Airline operations research | |
Birolini et al. | Integrated flight scheduling and fleet assignment with improved supply-demand interactions | |
US20030191678A1 (en) | Disruption handling for scheduling system | |
Jacobs et al. | Airline planning and schedule development | |
CN101421753A (zh) | 运输调度*** | |
Clarke et al. | Impact of operations research on the evolution of the airline industry | |
Belobaba | The airline planning process | |
Abdelghany et al. | Airline network planning and scheduling | |
Lohatepanont | Airline fleet assignment and schedule design: integrated models and algorithms | |
Shebalov | Practical overview of demand-driven dispatch | |
Wu et al. | Airline scheduling and disruption management | |
Ahmed et al. | An overview of the issues in the airline industry and the role of optimization models and algorithms | |
Liu et al. | Optimizing aircrew recovery considering long connections: a column generation based approach | |
Silverwood | Application of stochastic programming techniques to airline scheduling | |
Zhang | Tackling aircraft routing uncertainties: adjustable cruise speed and fuzzy modelling approach | |
Wu et al. | 12 Airline scheduling | |
da Silva Montoito | Application of the Simulated Annealing with Adaptive Local Neighborhood Search to the Tail Assignment Problem | |
Hottenrott | An adaptive large neighborhood search algorithm for the tail assignment problem of airlines | |
Ahmed | Integrating the fleet assignment model with uncertain demand |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
GB | Transfer or rights |
Owner name: INTELLIGENT IP CORP. |
|
FA | Abandonment or withdrawal |