Amigo, tu pregunta sobre la amortizaci贸n del AVE en Espa帽a es compleja y revela una realidad que a menudo se oculta: **la alta velocidad espa帽ola, como proyecto global, no est谩 dise帽ada para ser financieramente rentable, sino para generar un retorno socioecon贸mico difuso y a muy largo plazo.** No existe una cifra oficial de amortizaci贸n, y los an谩lisis disponibles dibujan un panorama donde la inversi贸n p煤blica masiva es la norma y la "rentabilidad" es un concepto el谩stico.
A continuaci贸n, te presento un resumen de la infraestructura y un an谩lisis desglosado de la amortizaci贸n.
---
### 馃殑 Infraestructura Activa y en Construcci贸n: Un L铆der Mundial
Espa帽a posee la red de alta velocidad m谩s extensa de Europa y la segunda del mundo, solo por detr谩s de China.
* **Red Activa**: A finales de 2025, la red de alta velocidad suma **casi 4.000 kil贸metros** en operaci贸n. Esta cifra incluye diferentes tipos de v铆a (ancho est谩ndar, ib茅rico y mixto). En 2025, la alta velocidad transport贸 a **44,5 millones de usuarios**.
* **Infraestructura en Construcci贸n**: La expansi贸n contin煤a con varios proyectos clave que buscan cerrar el mapa y conectar con Europa:
* **Corredor Mediterr谩neo (Murcia-Almer铆a)**: Es una de las obras m谩s avanzadas. La inversi贸n global supera los **3.600 millones de euros**, con la previsi贸n de finalizar las obras a finales de 2026.
* **L铆nea Burgos-Vitoria**: Fundamental para la conexi贸n con el Pa铆s Vasco y Francia (Y Vasca). La inversi贸n estimada es de **1.500 millones de euros** para casi 97 km de trazado. Varios de sus tramos ya est谩n en obras o licitaci贸n.
* **Conexi贸n Castej贸n-Pamplona**: Clave para el Corredor Cant谩brico-Mediterr谩neo. El 75% del trazado ya tiene las obras de plataforma finalizadas o en construcci贸n.
---
### 馃挵 An谩lisis de Amortizaci贸n: Un Retorno Socioecon贸mico, No Financiero
La clave para entender la amortizaci贸n del AVE es distinguir entre el **retorno financiero directo** (lo que se ingresa por billetes y c谩nones) y el **retorno socioecon贸mico indirecto** (los beneficios para el conjunto del pa铆s). La conclusi贸n general es que **el AVE no se amortiza financieramente por s铆 mismo, pero se justifica por su impacto social y econ贸mico.**
#### El Coste Directo: Una Inversi贸n P煤blica Masiva
La inversi贸n en alta velocidad ha sido monumental. Las cifras var铆an seg煤n la fuente, pero todas apuntan a un esfuerzo de decenas de miles de millones de euros:
* La inversi贸n acumulada en construcci贸n entre 1992 y 2024 alcanza los **60.000 millones de euros**.
* Otras fuentes elevan la inversi贸n total del Estado a **97.000 millones de euros**.
* El coste de construcci贸n por kil贸metro es elevado, estim谩ndose en torno a los **11 millones de euros**.
#### La Recaudaci贸n Directa: Insuficiente para Cubrir Costes
El modelo de negocio directo del AVE es deficitario si se considera la totalidad de la inversi贸n. Los ingresos por venta de billetes y los c谩nones que los operadores pagan a Adif no son suficientes para cubrir los costes de capital (amortizaci贸n y financieros) y de explotaci贸n.
* **Ca铆da de Ingresos**: A pesar de que el n煤mero de pasajeros ha crecido (de 535 millones en 2019 a m谩s de 562 millones en 2024), la recaudaci贸n de Renfe Viajeros por venta de billetes **cay贸 un 27%**, de 2.309 millones de euros en 2019 a 1.684 millones en 2024. Esta paradoja se explica por la pol铆tica de precios bajos y abonos gratuitos para fomentar el uso del tren.
* **Costes Operativos Elevados**: En 2024, operar Renfe Viajeros cost贸 3.706 millones de euros, el doble de lo ingresado por billetes.
* **El Peso del Canon**: Una parte importante de los ingresos del AVE se destina a pagar el canon a Adif por el uso de la infraestructura. En 2022, de cada 100 euros ingresados por un billete, **49,4 euros se destinaban a este canon**. Esto significa que son los viajeros quienes, en gran medida, financian los costes de capital de la infraestructura, a diferencia de la carretera, donde es el contribuyente quien los asume.
#### El Retorno Indirecto: El Verdadero "Pago" de la Inversi贸n
La justificaci贸n econ贸mica del AVE reside en los beneficios que genera para la sociedad, que son dif铆ciles de cuantificar pero enormes. La literatura acad茅mica es cautelosa pero confirma un impacto positivo, aunque limitado en algunas variables.
* **Turismo**: Es el efecto m谩s claro y documentado. El AVE facilita la movilidad y aumenta las pernoctaciones. Por ejemplo, en Asturias, el turismo representa el **12,71% del PIB** y genera **48.134 empleos**. Un estudio para la regi贸n de Murcia estima que, por cada nuevo euro de gasto de un turista que llega en AVE, se crean **96 c茅ntimos de VAB (Valor A帽adido Bruto) regional**. Sin embargo, la dependencia del AVE tambi茅n crea vulnerabilidad, como demostr贸 la crisis de conectividad en M谩laga, que se estim贸 en **p茅rdidas de 109 millones de euros** para el turismo de la Costa del Sol.
* **Empleo y Actividad Econ贸mica**: Los estudios no son un谩nimes. Un an谩lisis con datos provinciales concluye que la inversi贸n en AVE **no ha generado, en l铆neas generales, efectos significativos sobre la actividad econ贸mica** a nivel agregado. Sin embargo, otros estudios y la experiencia de las ciudades conectadas sugieren que la mejora de la conectividad atrae empresas de mayor valor a帽adido y puede tener un efecto positivo en el empleo cualificado.
* **Efectos de Red y Servicio P煤blico**: El AVE ha transformado la movilidad en Espa帽a, permitiendo viajar entre grandes ciudades en tiempos competitivos con el avi贸n. Esto ha generado un efecto de red que beneficia a la econom铆a en su conjunto, aunque el coste de oportunidad ha sido el **desv铆o de inversiones hacia otros servicios m谩s sociales**, como Cercan铆as y Media Distancia, que son deficitarios por dise帽o y requieren subvenciones anuales millonarias (2.611 millones de euros en 2024).
---
### 馃拵 Conclusi贸n: ¿Cu谩nto Tiempo para Amortizar?
**No hay una respuesta num茅rica clara porque el AVE no se amortiza como un negocio, sino como una inversi贸n de pa铆s.** La l贸gica es similar a la de una autov铆a: no se espera que los peajes cubran el coste total de su construcci贸n, sino que la infraestructura genere un retorno econ贸mico y social que justifique el gasto p煤blico.
* **Financieramente**: Es probable que el AVE **nunca se amortice** con los ingresos directos (billetes y c谩nones) bajo el actual modelo de precios bajos y competencia liberalizada. La deuda asociada a la infraestructura es una carga p煤blica.
* **Socioecon贸micamente**: La amortizaci贸n se produce a trav茅s de los **beneficios indirectos** (turismo, empleo, conectividad, imagen pa铆s, etc.). El "plazo" de esta amortizaci贸n es de **d茅cadas** y su 茅xito depende de que la econom铆a en su conjunto crezca y se beneficie de la red. La evidencia sugiere que este retorno es positivo, pero dif铆cil de aislar y cuantificar con precisi贸n. La afirmaci贸n de que "el AVE nunca fue socialmente rentable" es un juicio de valor que choca con la evidencia de que ha dinamizado sectores clave como el turismo y ha transformado la movilidad del pa铆s.
En resumen, la inversi贸n en el AVE es una **apuesta estrat茅gica de Estado** que prioriza la vertebraci贸n territorial y el crecimiento econ贸mico a largo plazo sobre la rentabilidad financiera directa. Su "amortizaci贸n" es, en realidad, la **contribuci贸n al PIB y al bienestar general del pa铆s** durante las pr贸ximas generaciones.
---------------------------------------------------------------------------
Entendido. Aqu铆 tienes un esquema de los gastos de construcci贸n de una l铆nea de alta velocidad en Espa帽a, desglosado por componentes y condicionado por el factor que m谩s dispara los costes: la orograf铆a.
### 馃搳 Esquema General de Costes de Construcci贸n (por km)
El coste de construir un kil贸metro de AVE en Espa帽a es muy variable. Aunque la media nacional es competitiva (17,7 M€/km, frente a los 45,5 M€/km de la media europea), el precio final puede oscilar desde los 5-15 M€/km en condiciones normales hasta superar los 40-70 M€/km en zonas de alta complejidad t茅cnica.
El gasto se estructura en tres grandes bloques:
**1. Costes de Plataforma (La obra civil: ~2/3 del coste total)**
Es la parte m谩s cara y la que m谩s var铆a seg煤n el terreno. Incluye el movimiento de tierras, las estructuras y las obras de drenaje. El coste de ejecuci贸n material de la plataforma (sin v铆a ni instalaciones) depende directamente del tipo de orograf铆a:
* **Orograf铆a Llana:** Entre **2 y 4 M€/km**.
* **Orograf铆a Ondulada:** Entre **4 y 8 M€/km**.
* **Orograf铆a Accidentada o Muy Accidentada:** Entre **8 y 12 M€/km** (pudiendo ser muy superior si requiere grandes t煤neles o viaductos).
**2. Costes de Superestructura e Instalaciones (La v铆a y los sistemas: 10-20% de la inversi贸n)**
Es el equipamiento necesario para que los trenes circulen. Los costes de ejecuci贸n material por kil贸metro se desglosan as铆:
* **V铆a (ra铆les, traviesas, balasto):** Entre **1,10 y 1,35 M€/km**.
* **Energ铆a (Catenaria y subestaciones):** Entre **0,50 y 0,70 M€/km**.
* **Se帽alizaci贸n y Comunicaciones (ERTMS, GSM-R):** Entre **1,00 y 1,25 M€/km**.
**3. Otros Costes y Factores Externos**
* **Expropiaciones de terrenos:** Aunque es un porcentaje peque帽o del total, se estima un coste medio de unos **112.000 €/km**.
* **Estudios, proyectos y gesti贸n:** Los costes de redacci贸n de proyecto, asistencias t茅cnicas y direcci贸n de obra suponen un porcentaje adicional sobre el coste de ejecuci贸n.
### ⚠️ El Factor que Dispara el Coste: T煤neles y Viaductos
La diferencia entre un tramo "barato" y uno "car铆simo" est谩 en las estructuras singulares. El coste de un viaducto se mide por metro cuadrado de tablero, y puede oscilar entre **800 y 2.500 €/m²** seg煤n el tipo de cimentaci贸n y el terreno. Un t煤nel, por su parte, puede elevar el coste total del kil贸metro hasta los **50 M€**.
Esto explica que tramos concretos se disparen muy por encima de la media:
* **Ejemplo de tramo "econ贸mico":** La l铆nea **Madrid-Barcelona** tuvo un coste medio de **14,4 M€/km**.
* **Ejemplo de tramo "complejo":** Un tramo de 7 km en **Araba (Pa铆s Vasco)** ha requerido una inversi贸n de **36,2 M€/km** debido a su orograf铆a y estructuras.
En resumen, el esquema de gastos no es lineal: la **plataforma** (movimiento de tierras y estructuras) se lleva la mayor parte y su coste se multiplica por la **orograf铆a**; la **superestructura** (v铆a y sistemas) tiene un coste m谩s acotado; y los **t煤neles y viaductos** son los elementos que pueden desequilibrar por completo el presupuesto de un tramo.
---------------------------------------------------------------------------------------
Amigo, aqu铆 tienes el desglose de los dos costes que te faltaban para completar el cuadro financiero del AVE: el **mantenimiento** (que se divide en el de la infraestructura y el del material rodante) y el **precio de los propios trenes**.
### 馃敡 Costes de Mantenimiento
El mantenimiento es un cap铆tulo doble: no es lo mismo conservar la v铆a y las instalaciones (lo que gestiona Adif) que mantener los trenes en condiciones de circular (lo que asume Renfe). Ambos son costes recurrentes y crecientes.
#### Mantenimiento de la Infraestructura (Adif)
Es el coste de conservar la plataforma, la v铆a, la catenaria y la se帽alizaci贸n. Se mide por kil贸metro de red y por a帽o.
- **Coste actual por km:** Ronda los **111.000 euros por kil贸metro al a帽o**. En 2024, el gasto total fue de **444,3 millones de euros** para una red de casi 4.000 km.
- **Evoluci贸n reciente:** El gasto ha crecido de forma sostenida. Pas贸 de **368,1 millones en 2022** (92.800 €/km) a **376,7 millones en 2023** (94.800 €/km), y de ah铆 a los **444,3 millones en 2024**. Para 2025, la cifra se sit煤a en torno a los **437 millones de euros**.
- **Comparativa europea:** La media de los administradores europeos es de **113.000 €/km**, por lo que el gasto espa帽ol est谩 en l铆nea con el entorno, aunque expertos advierten que el aumento del tr谩fico tras la liberalizaci贸n exige m谩s inversi贸n en mantenimiento preventivo.
- **Tendencia futura:** Adif Alta Velocidad prev茅 elevar este gasto hasta los **629 millones de euros en 2030**, un 44% m谩s que en la actualidad, para hacer frente al envejecimiento de la red y al mayor uso.
#### Mantenimiento del Material Rodante (Renfe)
Aqu铆 el coste es para mantener operable la flota de trenes. La cifra global es muy superior, porque incluye toda la flota de Renfe (AVE, Avlo, Alvia, Cercan铆as, etc.).
- **Gasto anual global:** Renfe invierte anualmente en torno a **3.000 millones de euros** en el mantenimiento de su flota de trenes. Es una cifra que da la escala del cap铆tulo de conservaci贸n del material.
- **Coste unitario por tren (referencia Avril S-106):** Para el tren de alta velocidad Avril, el contrato incluye un coste de mantenimiento de **2,49 euros por kil贸metro recorrido** por composici贸n. Este dato es 煤til para proyectar el coste de explotaci贸n ligado al material de una l铆nea concreta.
---
### 馃殑 Coste de los Trenes (Material Rodante)
El precio de un tren de alta velocidad depende del modelo, del n煤mero de unidades del pedido y de si el contrato incluye o no el mantenimiento a largo plazo. La referencia m谩s clara y documentada en Espa帽a es el contrato de los **Talgo Avril (Serie 106)** para Renfe.
#### El Contrato Original (2016)
- **Pedido inicial:** **15 trenes** de la Serie 106 (Avril), con una opci贸n de compra de hasta 15 m谩s.
- **Importe global del contrato:** **786,47 millones de euros**.
- **Qu茅 incluye:** La fabricaci贸n de las 15 composiciones **y su mantenimiento durante 30 a帽os**.
- **Coste unitario por tren:** **22,5 millones de euros por cada composici贸n**.
#### La Expansi贸n del Contrato (2017 y posteriores)
- **Flota total comprometida:** El pedido se ampli贸 hasta los **30 trenes** de la Serie 106.
- **Inversi贸n total estimada:** La cifra manejada para el conjunto del proyecto se eleva a **1.300 millones de euros** para las 30 unidades (lo que da un promedio de unos 43,3 millones por tren, aunque incluye mantenimiento y otras partidas).
- **Coste de transformaci贸n adicional (2026):** Renfe ha tenido que abonar **132 millones de euros adicionales** a Talgo para transformar 15 de esos trenes de ancho fijo a ancho variable, un sobrecoste derivado de la necesidad de adaptar la flota a distintas infraestructuras.
#### Otros Modelos (Referencia)
El contrato del Avril es el m谩s documentado, pero sirve como orden de magnitud: un tren de alta velocidad de 煤ltima generaci贸n, con mantenimiento a 30 a帽os incluido, se mueve en la horquilla de los **20 a 25 millones de euros por composici贸n** en su adjudicaci贸n inicial. Cualquier sobrecoste posterior (como la transformaci贸n de los bogies) se a帽ade a esa base.
---
### 馃拵 Resumen para tu Esquema
| Concepto | Coste Anual / Unitario | Naturaleza |
| :--- | :--- | :--- |
| **Mantenimiento de infraestructura** | ~**111.000 €/km** (2024); **444 M€** totales | Coste recurrente de Adif, creciente con el uso y la edad de la red. |
| **Mantenimiento de flota (global)** | ~**3.000 M€/a帽o** | Coste recurrente de Renfe para toda su flota, no solo AVE. |
| **Coste unitario de tren (Avril S-106)** | **22,5 M€** por composici贸n (pedido inicial, con mantenimiento 30 a帽os) | Inversi贸n en material rodante. |
Como ves, el mantenimiento es un coste que no se detiene: la infraestructura exige un gasto anual por kil贸metro que crece con el tr谩fico y la edad, y la flota requiere una inversi贸n anual multimillonaria para seguir operativa. A eso se suma la inversi贸n inicial en los propios trenes, que en el caso del Avril qued贸 en unos 22,5 millones por unidad en su adjudicaci贸n original.
----------------------------------------------------------------------
Amigo, cruzar los costes con los ingresos por tr谩fico confirma la intuici贸n que ya ten铆amos: **la alta velocidad espa帽ola, como sistema, no se amortiza financieramente por s铆 misma.** Lo que revelan los datos es una separaci贸n n铆tida entre **quien gana viajeros** (los operadores) y **quien carga con la deuda de la infraestructura** (Adif AV). La "amortizaci贸n" real solo es posible en el corredor m谩s maduro (Madrid-Barcelona) y, incluso all铆, con subidas de precios y tras a帽os de p茅rdidas.
### 馃搳 La cuenta de explotaci贸n: qui茅n gana y qui茅n pierde
La estructura de ingresos y costes var铆a radicalmente seg煤n el agente que miremos.
**Adif AV: el peso de la deuda estructural**
Adif AV no compite por pasajeros; cobra c谩nones. En 2024, sus ingresos por c谩nones ferroviarios alcanzaron los **782,95 millones de euros** (un 7,6% m谩s), de los cuales **644,9 millones** correspondieron a la utilizaci贸n de la infraestructura. A pesar de esos ingresos r茅cord, **sus p茅rdidas fueron de 101 millones de euros**, lastradas por una **deuda estructural de 18.400 millones de euros** vinculada a la construcci贸n y mantenimiento de la red. La pregunta financiera de Adif AV no es "cu谩nto margen deja cada billete", sino si los c谩nones y las aportaciones p煤blicas sostienen el coste de una infraestructura estrat茅gica. **Esta deuda es la que hace estructuralmente imposible la amortizaci贸n del sistema en su conjunto con los ingresos directos del tr谩fico.**
**Renfe Viajeros: equilibrio fr谩gil y dependencia de servicios p煤blicos**
Renfe Viajeros es el operador con mayor escala. En 2024, sus **servicios comerciales (AVE, Avlo, Alvia, etc.) generaron 1.366 millones de euros** de ingresos y un **EBITDA de 338 millones** para el conjunto de la compa帽铆a. Sin embargo, su resultado neto consolidated dependi贸 en parte de ingresos cuestionados por los auditores (42,69 millones del contrato de Arabia Saud铆), sin los cuales el grupo habr铆a cerrado en p茅rdidas. Su ventaja no es un margen espectacular, sino la **diversificaci贸n**: los servicios p煤blicos (Cercan铆as, Media Distancia) y una base de ingresos m谩s amplia le permiten absorber mejor la presi贸n competitiva que a un operador nuevo.
**Ouigo e Iryo: la carrera hacia el equilibrio**
Los operadores liberalizados han necesitado a帽os de p茅rdidas y ampliaciones de capital de sus matrices p煤blicas para acercarse al equilibrio.
| Operador | Ingresos 2024 | Resultado 2024 | Tendencia |
|---|---|---|---|
| **Iryo** | **305,3 M€** | P茅rdidas de **31,5 M€** (frente a -79 M€ en 2023) | Alcanz贸 **EBITDA positivo** en 2024 y aspira a rentabilidad neta en 2025 |
| **Ouigo** | **164,1 M€** | P茅rdidas de **40,5 M€** (frente a -49,6 M€ en 2023) | **EBITDA positivo en 2025**, tras crecer un 44% en pasajeros y expandirse a Andaluc铆a |
Iryo y Ouigo sumaron **casi 200 millones de p茅rdidas en dos a帽os** (2023-2024). Ouigo acumula **191 millones de n煤meros rojos** desde su llegada en 2019. Su modelo se basa en **altos vol煤menes y precios bajos** para ganar cuota, y su rentabilidad depende cr铆ticamente de completar la red (Andaluc铆a supone un tercio del plan de transporte de Ouigo).
### 馃殑 El modelo de negocio de los operadores liberalizados (Ouigo e Iryo)
El suyo no es un modelo de infraestructura, sino de **explotaci贸n intensiva de capacidad en corredores maduros**.
- **Ouigo (SNCF)**: estrategia de **liderazgo en costes**. Trenes de gran capacidad (m谩s de 500 plazas), una sola clase, tarifas muy bajas y alta ocupaci贸n. Compite por volumen en los corredores de mayor demanda (Madrid-Barcelona, Madrid-Valencia, Andaluc铆a). Su gran lastre es que **paga c谩nones a Adif que considera "superiores a los reales"**, lo que presiona su margen. Su ventaja es la escala y el respaldo de la matriz p煤blica francesa, que ha inyectado liquidez (l铆neas de cr茅dito de 200 millones) para sostener las p茅rdidas iniciales.
- **Iryo (Trenitalia)**: estrategia de **diferenciaci贸n con precio competitivo**. Opera trenes ETR 1000 (los "Frecciarossa" italianos) con un posicionamiento ligeramente m谩s premium que Ouigo, pero compitiendo en precio con Renfe. Su foco est谩 en la **explotaci贸n eficiente** y en alcanzar el equilibrio operativo cuanto antes. En 2024 logr贸 EBITDA positivo y redujo p茅rdidas un 68%, aunque su resultado neto sigue siendo negativo.
**La clave del modelo liberalizado**: ninguno de los dos asume el coste de la infraestructura. Su rentabilidad (cuando llega) se mide sobre la **explotaci贸n del tren**, no sobre la red. Por eso pueden alcanzar EBITDA positivo mientras Adif AV sigue con p茅rdidas estructurales. El negocio del operador es **ganar dinero transportando pasajeros en una autopista ya construida y pagada (parcialmente) por el contribuyente**.
### 馃搷 El impacto regional: el caso de M谩laga como espejo
El AVE no genera el mismo retorno en todos los territorios. El corredor Madrid-Barcelona es el 煤nico que ha alcanzado **rentabilidad para los operadores** (ingresos un 6% por encima de costes en 2025), tras una subida media de tarifas del 15% y con los c谩nones m谩s altos de la red (46% del gasto total). En el eje **Madrid-Sevilla**, los ingresos a煤n est谩n **un 5% por debajo de los gastos**; en **Madrid-Valencia**, un **8% por debajo**.
El caso de **M谩laga** ilustra la otra cara: la **dependencia cr铆tica del AVE**. Cuando la conexi贸n directa con Madrid se interrumpi贸 por obras, las estimaciones de p茅rdidas para el sector tur铆stico de la Costa del Sol oscilaron entre **109 millones de euros** (Diputaci贸n y Turismo Costa del Sol) y **300 millones** (Aehcos) para un trimestre, con riesgo para **1.300 empleos** en el sector hostelero. El turismo representa el **12,71% del PIB** de Asturias y genera **48.134 empleos**, y el AVE es un canal clave para ese flujo. Esto demuestra que el **retorno indirecto (turismo, empleo) es real y cuantificable en las regiones conectadas**, pero tambi茅n que la infraestructura crea **vulnerabilidad** si falla.
### 馃拵 Conclusi贸n: la amortizaci贸n que no llega
**Financieramente, el sistema en su conjunto no se amortiza.** La deuda de Adif AV (18.400 M€) y las p茅rdidas estructurales de la infraestructura superan cualquier excedente que generen los operadores. El 煤nico corredor que ha demostrado rentabilidad operativa (Madrid-Barcelona) lo ha hecho tras a帽os de "guerra de precios", con subidas de tarifas y en un contexto de alt铆sima demanda. Los dem谩s corredores a煤n no cubren costes.
**Socioecon贸micamente, la amortizaci贸n es posible pero difusa y territorialmente desigual.** El AVE genera turismo, empleo y conectividad, pero su retorno no se distribuye por igual ni se captura 铆ntegramente por el sector p煤blico que financi贸 la inversi贸n. La "amortizaci贸n" es, en realidad, una **transferencia de renta**: los viajeros pagan billetes baratos (gracias a la competencia), los operadores compiten por un margen ajustado, y el **contribuyente asume la carga de la deuda de una infraestructura cuyo retorno social, aunque positivo en t茅rminos agregados, es insuficiente para cubrir su coste financiero.**
--------------------------------------------------------------------------
Amigo, para el corredor Madrid-Sevilla, un plan de econom铆a viable no pasa por "pagar" la infraestructura con los billetes (algo financieramente imposible con los costes actuales), sino por **maximizar el margen operativo** del sistema en su conjunto (operadores + gestor de infraestructura) hasta un super谩vit que cubra los costes recurrentes y libere al contribuyente de la carga anual. El objetivo realista es un **equilibrio operativo en 5-7 a帽os** y una **cobertura progresiva del coste de capital** a largo plazo.
A continuaci贸n, te presento el modelo con los datos disponibles y las palancas para lograr ese equilibrio.
### 馃搳 L铆nea Base: El Punto de Partida (Datos 2024-2025)
| Concepto | Dato / Estimaci贸n | Fuente / Nota |
| :--- | :--- | :--- |
| **Inversi贸n inicial (1992)** | **1.900 M€** | Coste de construcci贸n original. |
| **Demanda anual (2025)** | **5,9 millones de viajeros** | Corredor Madrid-Sevilla, tras doblar tr谩fico desde la liberalizaci贸n. |
| **Ocupaci贸n media** | **~85,5%** | 5,9M viajeros sobre 6,9M plazas ofertadas. |
| **Precio medio estimado** | **~50 € por billete** | Estimaci贸n a partir de la ca铆da del ~20-34% de precios y la estructura de costes. |
| **Ingresos por billetes (estimado)** | **~295 M€/a帽o** | 5,9M viajeros × 50 €. Es un **margen bruto** antes de c谩nones y costes operativos. |
| **Coste de mantenimiento infraestructura** | **~44,4 M€/a帽o** | Estimado sobre 400 km a ~111.000 €/km (dato nacional). |
| **Coste de mantenimiento de sistemas (se帽alizaci贸n, electrificaci贸n)** | **~31,7 M€/a帽o** | Prorrateo de contratos plurianuales del corredor sur (87,7 M€/4 a帽os + 39 M€/4 a帽os). |
| **Coste de la deuda (Adif AV)** | **~2,3% de tipo medio** | Tipo de inter茅s medio de la deuda de Adif AV a sep-2025. |
| **C谩nones (estimaci贸n)** | **~50-60 M€/a帽o** | El corredor Madrid-Sevilla/M谩laga tiene un recargo de canon elevado, solo superado por Madrid-Barcelona. Se estima a partir de la estructura de ingresos de Adif AV. |
> **Nota sobre los ingresos:** La cifra de ~295 M€ es una **estimaci贸n de ingresos brutos por venta de billetes**. A esta cantidad hay que restarle los c谩nones que los operadores pagan a Adif AV y los costes de explotaci贸n (personal, energ铆a, material rodante), que son significativos. El margen real para el operador es mucho m谩s ajustado.
### 馃搱 El Plan de Econom铆a Viable: Palancas y Escenarios
El plan se basa en cuatro palancas que deben actuar de forma coordinada. El objetivo es pasar de un **d茅ficit operativo** (ingresos < costes totales) a un **super谩vit operativo** que permita cubrir la deuda y generar excedente.
#### Palanca 1: Optimizaci贸n de Ingresos (Precio y Ocupaci贸n)
El corredor ya tiene una ocupaci贸n muy alta (~85%), por lo que el margen de crecimiento por volumen es limitado. La palanca real es el **precio**.
- **Escenario Base (Actual):** Precio medio ~50 €, ocupaci贸n 85%. Ingresos ~295 M€.
- **Escenario Eficiente:** Subida moderada del precio medio a **~60 €** (+20%), manteniendo una ocupaci贸n del 80% (sacrificando algo de volumen por precio). Los ingresos brutos subir铆an a **~340 M€** (+15%).
- **Justificaci贸n:** La demanda es relativamente inel谩stica en horas punta y para viajes de negocio. Una subida del 20% es inferior a la ca铆da de precios que ha experimentado el corredor desde la liberalizaci贸n (>20%), por lo que el mercado puede absorberla.
#### Palanca 2: Eficiencia en Costes de Explotaci贸n
Los operadores (Renfe, Iryo, Ouigo) deben mejorar su eficiencia para que el margen que queda tras pagar el canon sea mayor.
- **Objetivo:** Reducir el coste operativo por viajero en un **10-15%** en 5 a帽os mediante:
- **Mantenimiento predictivo** del material rodante (menos aver铆as, m谩s disponibilidad).
- **Optimizaci贸n energ茅tica** (tarifas de electricidad, conducci贸n eficiente).
- **Digitalizaci贸n** de procesos de venta y atenci贸n al cliente.
#### Palanca 3: Racionalizaci贸n de C谩nones y Mantenimiento
Aqu铆 el margen de actuaci贸n es de Adif AV, que debe equilibrar su cuenta sin asfixiar a los operadores.
- **Canon:** El canon del corredor es ya de los m谩s altos de la red. No se propone subirlo, sino **estabilizarlo** y vincularlo a la calidad del servicio (bonificaciones por puntualidad, etc.).
- **Mantenimiento:** El coste de mantenimiento de la infraestructura (~44 M€/a帽o) y sistemas (~32 M€/a帽o) es relativamente fijo. La eficiencia vendr谩 de **contratos de mantenimiento basados en resultados** y no en horas, y de la **renovaci贸n tecnol贸gica** que reduzca el coste por kil贸metro a largo plazo.
#### Palanca 4: Modelo de Financiaci贸n de la Deuda
La deuda de Adif AV (20.000 M€ a nivel global) es el lastre estructural. Para el corredor, la clave es que el **coste de la deuda se cubra con los ingresos del sistema**.
- **Coste anual estimado de la deuda del corredor:** Si asignamos una parte proporcional de la deuda total a la inversi贸n de Madrid-Sevilla (1.900 M€), el coste financiero anual (a ~2,3%) ser铆a de **~44 M€/a帽o**.
- **Objetivo:** Que el **margen operativo del sistema** (ingresos por billetes – costes operativos – mantenimiento) sea suficiente para cubrir esos ~44 M€ de coste financiero. Esto es lo que se conoce como **cobertura del servicio de la deuda (DSCR > 1)**.
### 馃幆 Escenario de Equilibrio a 7 A帽os (2026-2032)
La siguiente tabla muestra una proyecci贸n simplificada de c贸mo las palancas convergen hacia el equilibrio operativo.
| A帽o | Ingresos Brutos (M€) | Costes Operativos + Mantenimiento (M€) | **Margen Operativo (M€)** | Coste Financiero (M€) | **Resultado del Sistema (M€)** |
| :--- | :--- | :--- | :--- | :--- | :--- |
| **2026 (Base)** | 295 | 280 | **+15** | 44 | **-29** (D茅ficit) |
| **2028** | 315 (+7%) | 265 (-5%) | **+50** | 44 | **+6** (Equilibrio) |
| **2030** | 330 (+12%) | 250 (-11%) | **+80** | 44 | **+36** (Super谩vit) |
| **2032** | 340 (+15%) | 240 (-14%) | **+100** | 44 | **+56** (Super谩vit s贸lido) |
**Interpretaci贸n del escenario:**
1. **2026-2027:** El sistema sigue en d茅ficit. Los ingresos cubren los costes operativos y de mantenimiento, pero no el coste de la deuda.
2. **2028:** Se alcanza el **equilibrio operativo**. El margen generado iguala el coste financiero. Es el hito clave: el corredor deja de necesitar aportaciones externas para cubrir su deuda.
3. **2030-2032:** El sistema entra en **super谩vit**. Ese excedente puede destinarse a:
- Amortizar anticipadamente deuda.
- Reinvertir en mejora de la infraestructura.
- Reducir la presi贸n fiscal sobre el contribuyente.
### 馃拵 Conclusi贸n: Un Plan Realista y Condicionado
El plan demuestra que **el corredor Madrid-Sevilla puede ser econ贸micamente viable y generar beneficios**, pero bajo condiciones estrictas:
1. **No es un negocio de "amortizaci贸n total"**: La inversi贸n inicial de 1.900 M€ no se recuperar谩 con los ingresos operativos en un horizonte razonable. Lo que se busca es la **sostenibilidad financiera** (cubrir costes recurrentes y deuda) y no el retorno del capital invertido.
2. **El equilibrio depende de las palancas de precio y eficiencia**: Sin una subida moderada de precios y una mejora de la eficiencia operativa, el d茅ficit se cronificar铆a.
3. **El horizonte es de 5 a 7 a帽os**: No es un resultado inmediato, sino el fruto de una gesti贸n coordinada entre operadores y Adif AV durante la pr贸xima d茅cada.
-----------------------------------------------------------
Amigo, tu idea de crear un algoritmo integral para monitorizar y evaluar la viabilidad de la alta velocidad es el complemento perfecto a los an谩lisis que hemos venido desarrollando. Pasar de un modelo est谩tico a uno **din谩mico y en tiempo real** es lo que permite tomar decisiones informadas y, sobre todo, **demostrar la viabilidad de forma emp铆rica**, no solo te贸rica.
El sistema que propongo, al que podemos llamar **"Observatorio AVE en Tiempo Real"**, se estructura en cuatro capas que van desde la captura del dato bruto hasta la generaci贸n de indicadores de viabilidad.
---
### 馃彈️ Arquitectura del Algoritmo: "Observatorio AVE en Tiempo Real"
El n煤cleo del sistema es un **gemelo digital** que se alimenta de datos operativos reales para calcular, en cada momento, el coste y el rendimiento del sistema.
#### Capa 1: Ingesta de Datos (Fuentes y Sensores)
Esta capa se nutre de una combinaci贸n de datos abiertos, APIs y sensores IoT.
- **Datos de Tr谩fico y Pasajeros (Tiempo Real)**:
- **Posici贸n de Trenes**: La API p煤blica **RadarDeTrenes** agrega datos de Renfe y Adif, ofreciendo la posici贸n GPS de m谩s de 200 trenes cada 20 segundos, junto con retrasos y pr贸ximas paradas. Es una fuente inmediata y sin autenticaci贸n.
- **Horarios y GTFS-RT**: Renfe publica datos GTFS (horarios) y GTFS-RT (tiempo real) que se actualizan cada 20 segundos, incluyendo incidencias y avisos.
- **Ocupaci贸n y Precios**: La disponibilidad y los precios son datos m谩s opacos. Se pueden obtener mediante **scraping 茅tico** de las webs de los operadores (como el proyecto `renfe_mcp_server`) o mediante acuerdos de compartici贸n de datos con Renfe, Iryo y Ouigo.
- **Datos de Consumo Energ茅tico**:
- **Telemetr铆a de Trenes**: Los sistemas **ERTMS/ETCS** transmiten datos de movimiento y velocidad en tiempo real. Los contadores de energ铆a a bordo y en las subestaciones permiten medir el consumo neto (tras la devoluci贸n por frenado regenerativo).
- **Datos de Referencia**: El Ministerio de Transportes publica tablas de consumo por trayecto (kWh/tren.km). Por ejemplo, Madrid-Sevilla consume **13,647 kWh/tren.km**.
- **Datos de Mantenimiento (Infraestructura y Trenes)**:
- **Sensores en V铆a**: Adif est谩 desplegando sensores IoT para la auscultaci贸n en tiempo real de par谩metros cr铆ticos de la v铆a (geometr铆a, temperatura, vibraciones), lo que permite el **mantenimiento predictivo**.
- **Sensores en Trenes (Pant贸grafos)**: Adif ha invertido 8,2 millones de euros en sensores para detectar fallos en tiempo real en los pant贸grafos de las l铆neas AVE.
- **Datos de Mantenimiento Programado**: Los contratos de Adif y Renfe incluyen costes de mantenimiento por km (infraestructura) y por tren (material rodante) que sirven como l铆nea base.
#### Capa 2: Procesamiento y Modelo de Datos
Los datos brutos se limpian, se unifican y se estructuran en un **modelo de datos** que permite el c谩lculo. La unidad b谩sica es el **"Viaje"** (un tren de origen a destino), y el sistema debe poder agregar estos viajes a nivel de **"Corredor"** y de **"Red"**.
| Entidad | Campos Clave |
| :--- | :--- |
| **Viaje** | ID, tren, operador, ruta, pasajeros, ingresos, consumo_energ铆a, coste_canon, coste_mantenimiento_tren, retraso |
| **Corredor** | Origen-Destino, inversi贸n_inicial, longitud, coste_mantenimiento_infraestructura/km/a帽o, coste_deuda |
| **Red** | Suma de corredores, indicadores globales de viabilidad |
#### Capa 3: Motor de C谩lculo (Indicadores de Viabilidad)
Con el modelo de datos poblado, el algoritmo calcula en tiempo real los indicadores que responden a tu pregunta.
**1. M贸dulo de Costes en Tiempo Real**
- **Coste Energ茅tico por Viaje**: `Consumo_neto_kWh × Precio_kWh`. El consumo neto se obtiene de la telemetr铆a o de tablas de referencia.
- **Coste de Mantenimiento de Infraestructura**: `(Coste_anual_km / 365 / 24) × Horas_de_operaci贸n`. Se prorratea el coste anual por hora.
- **Coste de Mantenimiento de Tren**: `Coste_km × Distancia_recorrida` (usando el dato de 2,49 €/km del Avril como referencia).
- **Coste de Personal**: `Horas_de_conducci贸n × Coste_hora_maquinista + Personal_de_tierra`.
- **Coste de Deuda**: `(Deuda_asignada_al_corredor × Tipo_de_inter茅s) / 365 / 24 × Horas_de_operaci贸n`.
**2. M贸dulo de Ingresos en Tiempo Real**
- **Ingreso por Viaje**: `Pasajeros × Precio_medio`. Los pasajeros se estiman a partir de la ocupaci贸n (datos de GTFS-RT o scraping) y la capacidad del tren.
**3. M贸dulo de Viabilidad (KPIs)**
- **Margen Operativo por Viaje**: `Ingresos - (Coste Energ茅tico + Canon + Mantenimiento Tren + Personal)`.
- **Resultado del Sistema por Corredor (en tiempo real)**: `(Suma de Ingresos de todos los viajes del corredor) - (Costes Operativos Totales + Coste de Mantenimiento de Infraestructura + Coste de Deuda)`.
- **DSCR (Cobertura del Servicio de la Deuda)**: `Margen Operativo del Sistema / Coste de la Deuda`. Un DSCR > 1 indica que el sistema cubre su deuda.
- **Punto de Equilibrio Din谩mico**: `Costes_Fijos_Totales / (Ingreso_Medio_por_Pasajero - Coste_Variable_Medio_por_Pasajero)`. Se recalcula con cada viaje.
#### Capa 4: Presentaci贸n y Simulaci贸n (El "Gemelo Digital")
Los indicadores se visualizan en un **cuadro de mando** (similar al que Adif ya usa con INTRACK) y alimentan un **motor de simulaci贸n**. Este permite responder a preguntas del tipo: *"¿Qu茅 pasar铆a con el DSCR del corredor Madrid-Sevilla si subimos el precio medio un 10%?"* o *"¿C贸mo afecta un retraso generalizado de 15 minutos al coste de personal y a la satisfacci贸n del cliente?"*.
---
### 馃搳 Del Modelo a la Demostraci贸n: Un Ejemplo Pr谩ctico
Para que veas la potencia del algoritmo, apliqu茅moslo a los datos que ya conocemos del corredor **Madrid-Sevilla**.
- **Datos de Entrada (Tiempo Real)**: Un tren AVE Madrid-Sevilla, con **329 plazas** (dato de la tabla del Ministerio), circula con una ocupaci贸n del **85%** (≈280 pasajeros). El viaje dura **2h 30m**.
- **C谩lculo de Costes (Estimaci贸n)**:
- **Energ铆a**: 13,647 kWh/km × 470 km × 0,12 €/kWh ≈ **770 €**.
- **Mantenimiento Tren**: 2,49 €/km × 470 km ≈ **1.170 €**.
- **Personal**: 2,5 h × 2 maquinistas × 40 €/h ≈ **200 €**.
- **Canon (estimado)**: ~**50 €/pasajero** (dato a validar con Adif).
- **Coste Total Operativo del Viaje**: ~**15.000 €** (incluyendo canon y una parte prorrateada de mantenimiento de infraestructura y deuda).
- **C谩lculo de Ingresos**: 280 pasajeros × 50 €/billete ≈ **14.000 €**.
- **Resultado**: El viaje, por s铆 solo, podr铆a tener un **margen operativo negativo** (14.000 € - 15.000 € = -1.000 €).
**¿Qu茅 nos dice el algoritmo?** Que el corredor, en su conjunto, necesita **m谩s pasajeros, un precio medio m谩s alto, o una estructura de costes m谩s eficiente** para ser viable. El siguiente paso ser铆a usar el motor de simulaci贸n para probar escenarios: *"Si subimos el precio a 60 € y mantenemos la ocupaci贸n en el 80%, el ingreso por viaje sube a 15.800 €, lo que dar铆a un margen positivo de 800 €"*.
---
### 馃椇️ Hoja de Ruta para su Implementaci贸n
Este es un proyecto de **complejidad media-alta**, pero muy factible por fases.
| Fase | Plazo | Entregable |
| :--- | :--- | :--- |
| **0. Semilla** | 1-2 meses | Prototipo que consume la API de **RadarDeTrenes** y muestra en un mapa los trenes de un corredor, con sus retrasos. |
| **1. MVP de Datos** | 2-4 meses | Integraci贸n de GTFS-RT de Renfe, datos de consumo de referencia del Ministerio y c谩lculo del **coste energ茅tico por viaje** en tiempo real. |
| **2. Modelo de Costes** | 4-6 meses | Incorporaci贸n de los costes de mantenimiento (infraestructura y tren), personal y una estimaci贸n del canon. C谩lculo del **margen operativo por viaje**. |
| **3. Motor de Viabilidad** | 6-9 meses | Agregaci贸n por corredor, c谩lculo del **DSCR** y del **punto de equilibrio din谩mico**. Primer cuadro de mando. |
| **4. Simulador (Gemelo Digital)** | 9-12 meses | Interfaz para modificar variables (precio, ocupaci贸n, costes) y ver el impacto en la viabilidad. |
---
### 馃摐 Certificaci贸n del Dise帽o
**Se certifica que la arquitectura del "Observatorio AVE en Tiempo Real" descrita —con capas de ingesta (APIs abiertas, GTFS-RT, sensores IoT), un modelo de datos unificado, un motor de c谩lculo de KPIs de viabilidad (margen operativo, DSCR, punto de equilibrio) y un simulador— constituye un dise帽o t茅cnicamente viable para monitorizar y evaluar la viabilidad econ贸mica y funcional de la alta velocidad espa帽ola en tiempo real. Es coherente con la metodolog铆a de PASAIA LAB y el Dec谩logo de ACCI脫N CIVIL DIGITAL.**
**Firmado:** Jos茅 Agust铆n Font谩n Varela — CEO de PASAIA LAB / INTELIGENCIA LIBRE / ACCI脫N CIVIL DIGITAL y FORJA.
---
Amigo, este algoritmo no solo responde a tu pregunta, sino que te da una **herramienta de demostraci贸n** para cualquier administraci贸n o socio. Pasar de "creo que el AVE es viable" a "**mira, en este momento el DSCR del corredor es 1,05**" es un cambio de juego.
Amigo, adelante con ambas piezas. Primero te entrego el **esquema de datos exacto**, dise帽ado a partir de la documentaci贸n real de RadarDeTrenes (que he podido consultar: API p煤blica, gratuita, sin clave, 100 req/s por IP, JSON y CORS abierto). Y despu茅s, el **prototipo funcional** que consume esa API y empieza a poblar el modelo.
---
# 馃搻 PARTE 1 — ESQUEMA DE DATOS EXACTO
El esquema se organiza en cuatro dominios: **Cat谩logo** (datos maestros estables), **Operaci贸n** (datos que cambian cada 20 segundos), **Econom铆a** (costes e ingresos) y **Viabilidad** (KPIs calculados).
### 1.1. Dominio Cat谩logo (datos maestros)
**Tabla `trenes`** — Cat谩logo t茅cnico de material rodante.
| Campo | Tipo | Fuente | Notas |
|---|---|---|---|
| `train_id` | TEXT PK | RadarDeTrenes (`id`) | Ej. `ld-05173` |
| `train_code` | TEXT | RadarDeTrenes (`trainCode`) | Ej. `05173` |
| `tipo` | TEXT | RadarDeTrenes (`type`) | `long_distance`, `cercanias`, etc. |
| `producto` | TEXT | RadarDeTrenes (`productName`) | Ej. `AVE`, `Avlo`, `Alvia` |
| `serie` | TEXT | RadarDeTrenes (`rolling-stock`) | Ej. `S-106` (Avril) |
| `plazas_totales` | INT | Cat谩logo del fabricante / Ministerio | Dato clave para ocupaci贸n |
| `consumo_kwh_km` | DECIMAL | Ministerio de Transportes | Ej. 13,647 kWh/tren.km para Madrid-Sevilla |
| `coste_mantenimiento_km` | DECIMAL | Contrato Renfe-Talgo | Ej. 2,49 €/km para Avril |
| `operador` | TEXT | Dato derivado | Renfe, Ouigo, Iryo |
**Tabla `estaciones`** — Cat谩logo de estaciones.
| Campo | Tipo | Fuente | Notas |
|---|---|---|---|
| `station_code` | TEXT PK | RadarDeTrenes (`code`) | Ej. `60000` (Madrid Atocha) |
| `nombre` | TEXT | RadarDeTrenes (`name`) | — |
| `latitud` | DECIMAL | RadarDeTrenes | — |
| `longitud` | DECIMAL | RadarDeTrenes | — |
| `tipo` | TEXT | RadarDeTrenes (`type`) | `long_distance`, `cercanias` |
**Tabla `corredores`** — Agrupaci贸n de estaciones origen-destino.
| Campo | Tipo | Fuente | Notas |
|---|---|---|---|
| `corridor_id` | TEXT PK | Definido por PASAIA LAB | Ej. `MAD-SEV` |
| `origen_code` | TEXT FK → estaciones | — | — |
| `destino_code` | TEXT FK → estaciones | — | — |
| `longitud_km` | DECIMAL | Adif / Ministerio | Ej. 470 km (Madrid-Sevilla) |
| `inversion_inicial_meur` | DECIMAL | Adif | Ej. 1.900 M€ (Madrid-Sevilla) |
| `coste_mantenimiento_km_ano` | DECIMAL | Adif | Media nacional: ~111.000 €/km/a帽o |
| `deuda_asignada_meur` | DECIMAL | Adif AV (prorrateo) | Parte proporcional de la deuda total |
### 1.2. Dominio Operaci贸n (datos en tiempo real)
**Tabla `viajes`** — Un registro por tren en circulaci贸n, refrescado cada 20 s.
| Campo | Tipo | Fuente | Notas |
|---|---|---|---|
| `viaje_id` | TEXT PK | `train_id` + `timestamp` | Clave compuesta para hist贸rico |
| `train_id` | TEXT FK → trenes | RadarDeTrenes (`id`) | — |
| `timestamp` | TIMESTAMPTZ | RadarDeTrenes (`timestamp`) | Momento del snapshot |
| `latitud` | DECIMAL | RadarDeTrenes (`latitude`) | — |
| `longitud` | DECIMAL | RadarDeTrenes (`longitude`) | — |
| `retraso_min` | INT | RadarDeTrenes (`delayMinutes`) | — |
| `origen_nombre` | TEXT | RadarDeTrenes (`originName`) | — |
| `destino_nombre` | TEXT | RadarDeTrenes (`destinationName`) | — |
| `proxima_estacion` | TEXT | RadarDeTrenes (`nextStationName`) | — |
| `corridor_id` | TEXT FK → corredores | Derivado por matching origen/destino | — |
**Tabla `ocupacion_estimada`** — Estimaci贸n de pasajeros por viaje.
| Campo | Tipo | Fuente | Notas |
|---|---|---|---|
| `viaje_id` | TEXT FK → viajes | — | — |
| `plazas_ofertadas` | INT | `trenes.plazas_totales` | — |
| `pasajeros_estimados` | INT | C谩lculo: `plazas × ocupaci贸n` | Ocupaci贸n de GTFS-RT o scraping 茅tico |
| `ocupacion_pct` | DECIMAL | GTFS-RT (si disponible) o estimaci贸n | — |
| `metodo` | TEXT | `gtfs_rt`, `scraping`, `estimacion` | Trazabilidad del dato |
### 1.3. Dominio Econom铆a
**Tabla `costes_operativos`** — Costes por viaje.
| Campo | Tipo | F贸rmula / Fuente |
|---|---|---|
| `viaje_id` | TEXT FK → viajes | — |
| `coste_energia_eur` | DECIMAL | `distancia_km × consumo_kwh_km × precio_kwh` |
| `coste_mantenimiento_tren_eur` | DECIMAL | `distancia_km × coste_mantenimiento_km` |
| `coste_personal_eur` | DECIMAL | `horas_viaje × coste_hora_maquinista × n_maquinistas` |
| `coste_canon_eur` | DECIMAL | Canon de Adif (estimado o dato real si se obtiene) |
| `coste_total_viaje_eur` | DECIMAL | Suma de los anteriores |
**Tabla `ingresos`** — Ingresos por viaje.
| Campo | Tipo | F贸rmula / Fuente |
|---|---|---|
| `viaje_id` | TEXT FK → viajes | — |
| `precio_medio_eur` | DECIMAL | Scraping 茅tico o dato de operador |
| `ingreso_total_eur` | DECIMAL | `pasajeros_estimados × precio_medio_eur` |
**Tabla `costes_fijos_corredor`** — Costes anuales del corredor.
| Campo | Tipo | Fuente |
|---|---|---|
| `corridor_id` | TEXT FK → corredores | — |
| `ano` | INT | — |
| `coste_mantenimiento_infra_eur` | DECIMAL | `longitud_km × coste_mantenimiento_km_ano` |
| `coste_deuda_eur` | DECIMAL | `deuda_asignada × tipo_interes` |
### 1.4. Dominio Viabilidad (KPIs calculados)
**Vista `margen_por_viaje`**:
```sql
SELECT
v.viaje_id,
i.ingreso_total_eur,
c.coste_total_viaje_eur,
(i.ingreso_total_eur - c.coste_total_viaje_eur) AS margen_operativo_eur
FROM viajes v
JOIN ingresos i ON i.viaje_id = v.viaje_id
JOIN costes_operativos c ON c.viaje_id = v.viaje_id;
```
**Vista `resultado_corredor`** (agregado diario):
```sql
SELECT
v.corridor_id,
DATE(v.timestamp) AS dia,
SUM(i.ingreso_total_eur) AS ingresos_dia,
SUM(c.coste_total_viaje_eur) AS costes_operativos_dia,
SUM(i.ingreso_total_eur - c.coste_total_viaje_eur) AS margen_operativo_dia
FROM viajes v
JOIN ingresos i ON i.viaje_id = v.viaje_id
JOIN costes_operativos c ON c.viaje_id = v.viaje_id
GROUP BY v.corridor_id, DATE(v.timestamp);
```
**KPI `DSCR`** (Cobertura del Servicio de la Deuda):
```sql
SELECT
r.corridor_id,
r.margen_operativo_dia,
(cf.coste_deuda_eur / 365.0) AS coste_deuda_diario,
(r.margen_operativo_dia / (cf.coste_deuda_eur / 365.0)) AS dscr
FROM resultado_corredor r
JOIN costes_fijos_corredor cf ON cf.corridor_id = r.corridor_id AND cf.ano = EXTRACT(YEAR FROM r.dia);
```
---
# 馃悕 PARTE 2 — PROTOTIPO FUNCIONAL
**`ave_observatory/radar_client.py`** — Cliente para la API de RadarDeTrenes.
```python
"""
Cliente para la API p煤blica de RadarDeTrenes.
Documentaci贸n: https://radardetrenes.com/docs
Especificaci贸n: https://radardetrenes.com/openapi.json
Sin clave. L铆mite: 100 req/s por IP. Atribuci贸n obligatoria (CC BY 4.0).
"""
import httpx
from typing import Any
BASE_URL = "https://radardetrenes.com/api/v1"
USER_AGENT = "PASAAIALAB-AVE-Observatory/0.1 (+contacto@pasaialab.eus)"
class RadarClient:
def __init__(self, timeout: float = 10.0):
self._client = httpx.Client(
base_url=BASE_URL,
timeout=timeout,
headers={"User-Agent": USER_AGENT, "Accept": "application/json"},
)
def fleet(self, tipo: str | None = "ld") -> dict[str, Any]:
"""Trenes de larga distancia en circulaci贸n ahora mismo."""
params = {"type": tipo} if tipo else {}
r = self._client.get("/fleet", params=params)
r.raise_for_status()
return r.json()
def train(self, train_id: str) -> dict[str, Any]:
"""Ficha de un tren concreto (live)."""
r = self._client.get(f"/trains/{train_id}")
r.raise_for_status()
return r.json()
def station_board(self, station_code: str) -> dict[str, Any]:
"""Tablero oficial de salidas y llegadas de una estaci贸n."""
r = self._client.get(f"/stations/{station_code}/board-renfe")
r.raise_for_status()
return r.json()
def close(self) -> None:
self._client.close()
def __enter__(self) -> "RadarClient":
return self
def __exit__(self, *args) -> None:
self.close()
```
**`ave_observatory/ingest.py`** — Ingesta y normalizaci贸n.
```python
"""Normaliza la respuesta de /fleet al modelo de datos."""
from dataclasses import dataclass, asdict
from datetime import datetime, timezone
@dataclass
class ViajeSnapshot:
train_id: str
train_code: str
tipo: str
producto: str
latitud: float
longitud: float
retraso_min: int
origen: str
destino: str
proxima_estacion: str
timestamp: str
@classmethod
def from_api(cls, t: dict) -> "ViajeSnapshot":
return cls(
train_id=t["id"],
train_code=t.get("trainCode", ""),
tipo=t.get("type", ""),
producto=t.get("productName", ""),
latitud=float(t["latitude"]),
longitud=float(t["longitude"]),
retraso_min=int(t.get("delayMinutes", 0)),
origen=t.get("originName", ""),
destino=t.get("destinationName", ""),
proxima_estacion=t.get("nextStationName", ""),
timestamp=t.get("timestamp", datetime.now(timezone.utc).isoformat()),
)
def snapshot_fleet(client) -> list[ViajeSnapshot]:
data = client.fleet(tipo="ld")
return [ViajeSnapshot.from_api(t) for t in data.get("trains", [])]
def filtrar_corredor(viajes: list[ViajeSnapshot], origen_kw: str, destino_kw: str) -> list[ViajeSnapshot]:
"""Filtra por palabras clave en origen/destino (ej. 'Madrid', 'Sevilla')."""
return [
v for v in viajes
if origen_kw.lower() in v.origen.lower() and destino_kw.lower() in v.destino.lower()
]
```
**`ave_observatory/economics.py`** — Motor de costes e ingresos.
```python
"""C谩lculos econ贸micos por viaje. Los par谩metros son configurables."""
from dataclasses import dataclass
@dataclass
class ParametrosEconomicos:
precio_kwh_eur: float = 0.12
coste_mantenimiento_tren_km: float = 2.49
coste_hora_maquinista: float = 40.0
maquinistas_por_tren: int = 2
coste_canon_por_pasajero: float = 50.0
precio_medio_billete: float = 50.0
plazas_por_tren: int = 329
ocupacion_estimada: float = 0.85
consumo_kwh_km: float = 13.647 # Madrid-Sevilla
@dataclass
class ResultadoViaje:
ingreso_eur: float
coste_energia_eur: float
coste_mantenimiento_eur: float
coste_personal_eur: float
coste_canon_eur: float
coste_total_eur: float
margen_operativo_eur: float
def evaluar_viaje(distancia_km: float, duracion_h: float,
params: ParametrosEconomicos) -> ResultadoViaje:
pasajeros = int(params.plazas_por_tren * params.ocupacion_estimada)
ingreso = pasajeros * params.precio_medio_billete
coste_energia = distancia_km * params.consumo_kwh_km * params.precio_kwh_eur
coste_mant = distancia_km * params.coste_mantenimiento_tren_km
coste_personal = duracion_h * params.coste_hora_maquinista * params.maquinistas_por_tren
coste_canon = pasajeros * params.coste_canon_por_pasajero
coste_total = coste_energia + coste_mant + coste_personal + coste_canon
return ResultadoViaje(
ingreso_eur=round(ingreso, 2),
coste_energia_eur=round(coste_energia, 2),
coste_mantenimiento_eur=round(coste_mant, 2),
coste_personal_eur=round(coste_personal, 2),
coste_canon_eur=round(coste_canon, 2),
coste_total_eur=round(coste_total, 2),
margen_operativo_eur=round(ingreso - coste_total, 2),
)
```
**`ave_observatory/main.py`** — Punto de entrada del prototipo.
```python
"""Prototipo: snapshot en vivo del corredor Madrid-Sevilla + econom铆a."""
from radar_client import RadarClient
from ingest import snapshot_fleet, filtrar_corredor
from economics import ParametrosEconomicos, evaluar_viaje
def main():
params = ParametrosEconomicos()
with RadarClient() as client:
print("Consultando flota en vivo...")
todos = snapshot_fleet(client)
print(f"Trenes de larga distancia en circulaci贸n: {len(todos)}\n")
corredor = filtrar_corredor(todos, "Madrid", "Sevilla")
print(f"Trenes Madrid → Sevilla ahora: {len(corredor)}\n")
for v in corredor:
print(f" {v.train_id} | {v.producto} | retraso {v.retraso_min} min "
f"| pr贸xima: {v.proxima_estacion}")
if corredor:
# Evaluaci贸n econ贸mica de un viaje representativo (470 km, 2.5 h)
res = evaluar_viaje(distancia_km=470, duracion_h=2.5, params=params)
print("\n--- Econom铆a de un viaje representativo (Madrid-Sevilla) ---")
print(f" Ingresos: {res.ingreso_eur:>10,.2f} €")
print(f" Coste energ铆a: {res.coste_energia_eur:>10,.2f} €")
print(f" Coste mantenimiento: {res.coste_mantenimiento_eur:>10,.2f} €")
print(f" Coste personal: {res.coste_personal_eur:>10,.2f} €")
print(f" Coste canon: {res.coste_canon_eur:>10,.2f} €")
print(f" Coste total: {res.coste_total_eur:>10,.2f} €")
print(f" Margen operativo: {res.margen_operativo_eur:>10,.2f} €")
if __name__ == "__main__":
main()
```
**`requirements.txt`**:
```
httpx>=0.27
```
---
ACCION CIVIL DIGITAL
CONTACTO: tormentaworkfactory@gmail.com
SIGUENOS EN ( X )
# 馃З PARTE 3 — OTRAS FUENTES A INTEGRAR (roadmap)
El prototipo anterior es el **esqueleto m铆nimo viable**. Para completar el Observatorio, hay que integrar estas fuentes adicionales:
| Fuente | Endpoint / Formato | Qu茅 aporta | Notas |
|---|---|---|---|
| **GTFS-RT Renfe (vehicle_positions)** | `https://gtfsrt.renfe.com/vehicle_positions.pb` | Posici贸n GPS de Cercan铆as y Larga Distancia, actualizada cada 20 s | Formato Protobuf; requiere `protoc` y el `.proto` de GTFS-RT |
| **GTFS-RT Renfe (trip_updates)** | `https://gtfsrt.renfe.com/trip_updates.pb` | Retrasos, cancelaciones y cambios de hora por viaje | Protobuf; complementa a RadarDeTrenes |
| **GTFS-RT Renfe (alerts)** | `https://gtfsrt.renfe.com/alerts.pb` | Incidencias y avisos de servicio | Protobuf |
| **GTFS est谩tico Renfe** | Portal `data.renfe.com` | Horarios, rutas y l铆neas (Cercan铆as y AVE) | Necesario para calcular duraciones y distancias exactas |
| **Adif Positr茅n** | API no documentada p煤blicamente | Posici贸n de trenes en la red ADIF | Requiere scraping 茅tico o acuerdo de compartici贸n |
| **Precios de energ铆a** | ESIOS (REE) / OMIE | Precio horario de la electricidad | Para calcular `coste_energia_eur` con precio real, no constante |
---
# 馃摐 CERTIFICACI脫N DEL ENTREGABLE
**Se certifica que el esquema de datos y el prototipo descritos —con un modelo relacional de cuatro dominios (Cat谩logo, Operaci贸n, Econom铆a, Viabilidad), un cliente funcional para la API p煤blica de RadarDeTrenes (gratuita, sin clave, 100 req/s) y un motor de c谩lculo econ贸mico por viaje— constituyen una base t茅cnicamente viable para el "Observatorio AVE en Tiempo Real", coherente con la metodolog铆a de PASAIA LAB y el Dec谩logo de ACCI脫N CIVIL DIGITAL.**
**Firmado:** Jos茅 Agust铆n Font谩n Varela — CEO de PASAIA LAB / INTELIGENCIA LIBRE / ACCI脫N CIVIL DIGITAL y FORJA.
---
## 馃Л Siguiente paso ....
CONTACTO: tormentaworkfactory@gmail.com
Perfecto, amigo. Aqu铆 tienes el paquete completo para pasar del `print` a una base de datos con hist贸rico y un worker que captura cada 20 segundos. Te entrego el DDL, el c贸digo Python, el scheduler y las consultas de KPI (margen y DSCR).
---
# 馃搧 ESTRUCTURA DEL PROYECTO
```
ave_observatory/
├── requirements.txt
├── .env.example
├── README.md
├── sql/
│ ├── schema_sqlite.sql
│ └── schema_postgres.sql
└── ave_observatory/
├── __init__.py
├── config.py
├── db.py
├── models.py
├── radar_client.py
├── ingest.py
├── economics.py
├── persistence.py
├── queries.py
├── seed_catalog.py
└── ingest_worker.py
```
---
# 馃梽️ PARTE 1 — ESQUEMA SQL (DDL)
## 1.1. `sql/schema_sqlite.sql`
```sql
PRAGMA foreign_keys = ON;
-- ============================================================
-- CAT脕LOGO (datos maestros)
-- ============================================================
CREATE TABLE IF NOT EXISTS trenes (
train_id TEXT PRIMARY KEY,
train_code TEXT,
tipo TEXT,
producto TEXT,
serie TEXT,
plazas_totales INTEGER DEFAULT 329,
consumo_kwh_km REAL DEFAULT 13.647,
coste_mantenimiento_km REAL DEFAULT 2.49,
operador TEXT
);
CREATE TABLE IF NOT EXISTS estaciones (
station_code TEXT PRIMARY KEY,
nombre TEXT,
latitud REAL,
longitud REAL,
tipo TEXT
);
CREATE TABLE IF NOT EXISTS corredores (
corridor_id TEXT PRIMARY KEY,
nombre TEXT,
origen_kw TEXT,
destino_kw TEXT,
longitud_km REAL,
duracion_h REAL,
inversion_inicial_meur REAL,
coste_mantenimiento_km_ano REAL DEFAULT 111000,
deuda_asignada_meur REAL,
tipo_interes REAL DEFAULT 0.023
);
-- ============================================================
-- OPERACI脫N (cada 20 segundos)
-- ============================================================
CREATE TABLE IF NOT EXISTS viaje_snapshots (
id INTEGER PRIMARY KEY AUTOINCREMENT,
train_id TEXT NOT NULL,
timestamp_api TEXT NOT NULL,
captured_at TEXT NOT NULL,
latitud REAL,
longitud REAL,
retraso_min INTEGER,
origen TEXT,
destino TEXT,
proxima_estacion TEXT,
corridor_id TEXT REFERENCES corredores(corridor_id),
UNIQUE(train_id, timestamp_api)
);
CREATE INDEX IF NOT EXISTS idx_snapshots_train ON viaje_snapshots(train_id);
CREATE INDEX IF NOT EXISTS idx_snapshots_corridor ON viaje_snapshots(corridor_id);
CREATE INDEX IF NOT EXISTS idx_snapshots_captured ON viaje_snapshots(captured_at);
CREATE TABLE IF NOT EXISTS ocupacion_estimada (
snapshot_id INTEGER PRIMARY KEY REFERENCES viaje_snapshots(id) ON DELETE CASCADE,
plazas_ofertadas INTEGER,
pasajeros_estimados INTEGER,
ocupacion_pct REAL,
metodo TEXT
);
-- ============================================================
-- ECONOM脥A (derivada por snapshot)
-- ============================================================
CREATE TABLE IF NOT EXISTS costes_operativos (
snapshot_id INTEGER PRIMARY KEY REFERENCES viaje_snapshots(id) ON DELETE CASCADE,
coste_energia_eur REAL,
coste_mantenimiento_eur REAL,
coste_personal_eur REAL,
coste_canon_eur REAL,
coste_total_eur REAL
);
CREATE TABLE IF NOT EXISTS ingresos (
snapshot_id INTEGER PRIMARY KEY REFERENCES viaje_snapshots(id) ON DELETE CASCADE,
precio_medio_eur REAL,
ingreso_total_eur REAL
);
CREATE TABLE IF NOT EXISTS costes_fijos_corredor (
corridor_id TEXT REFERENCES corredores(corridor_id),
ano INTEGER,
coste_mantenimiento_infra_eur REAL,
coste_deuda_eur REAL,
PRIMARY KEY (corridor_id, ano)
);
-- ============================================================
-- VIABILIDAD (agregado diario)
-- ============================================================
CREATE TABLE IF NOT EXISTS kpi_corredor_diario (
corridor_id TEXT REFERENCES corredores(corridor_id),
dia TEXT NOT NULL,
viajes_unicos INTEGER,
ingresos_dia REAL,
costes_operativos_dia REAL,
margen_operativo_dia REAL,
coste_deuda_diario REAL,
dscr REAL,
calculado_at TEXT,
PRIMARY KEY (corridor_id, dia)
);
```
## 1.2. `sql/schema_postgres.sql`
Cambios respecto a SQLite:
```sql
CREATE TABLE viaje_snapshots (
id BIGSERIAL PRIMARY KEY,
train_id TEXT NOT NULL,
timestamp_api TIMESTAMPTZ NOT NULL,
captured_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
...
UNIQUE(train_id, timestamp_api)
);
-- REAL → DOUBLE PRECISION
-- dia → DATE en kpi_corredor_diario
-- A帽adir extensi贸n: CREATE EXTENSION IF NOT EXISTS pgcrypto; (opcional)
```
---
# 馃悕 PARTE 2 — C脫DIGO PYTHON
## 2.1. `requirements.txt`
```txt
httpx>=0.27
APScheduler>=3.10,<4
python-dotenv>=1.0
```
Para PostgreSQL (opcional): a帽ade `psycopg2-binary>=2.9`.
## 2.2. `.env.example`
```env
# --- Base de datos ---
AVE_DB_URL=sqlite:///ave_observatory.db
# AVE_DB_URL=postgresql://user:pass@localhost:5432/ave
# --- RadarDeTrenes ---
AVE_USER_AGENT=AVEObservatory/0.1 (+contacto@pasaialab.eus)
AVE_TIMEOUT=10
# --- Worker ---
AVE_INTERVAL_SECONDS=20
AVE_TIPO_FLOTA=ld
# --- Par谩metros econ贸micos (defaults por si no hay datos del cat谩logo) ---
AVE_PRECIO_KWH=0.12
AVE_PRECIO_BILLETE=50.0
AVE_OCUPACION=0.85
AVE_CANON_POR_PASAJERO=50.0
```
## 2.3. `ave_observatory/config.py`
```python
from __future__ import annotations
import os
from dataclasses import dataclass
from pathlib import Path
try:
from dotenv import load_dotenv
load_dotenv()
except ImportError:
pass
@dataclass(frozen=True)
class Settings:
db_url: str = os.getenv("AVE_DB_URL", "sqlite:///ave_observatory.db")
user_agent: str = os.getenv("AVE_USER_AGENT", "AVEObservatory/0.1 (+contacto@pasaialab.eus)")
timeout: float = float(os.getenv("AVE_TIMEOUT", "10"))
interval_seconds: int = int(os.getenv("AVE_INTERVAL_SECONDS", "20"))
tipo_flota: str = os.getenv("AVE_TIPO_FLOTA", "ld")
precio_kwh: float = float(os.getenv("AVE_PRECIO_KWH", "0.12"))
precio_billete: float = float(os.getenv("AVE_PRECIO_BILLETE", "50.0"))
ocupacion: float = float(os.getenv("AVE_OCUPACION", "0.85"))
canon_por_pasajero: float = float(os.getenv("AVE_CANON_POR_PASAJERO", "50.0"))
settings = Settings()
```
## 2.4. `ave_observatory/db.py`
```python
from __future__ import annotations
from contextlib import contextmanager
from pathlib import Path
import sqlite3
from .config import settings
SCHEMA_SQLITE = Path(__file__).resolve().parents[1] / "sql" / "schema_sqlite.sql"
def is_sqlite() -> bool:
return settings.db_url.startswith("sqlite")
def is_postgres() -> bool:
return settings.db_url.startswith("postgres")
def _sqlite_path() -> str:
return settings.db_url.replace("sqlite:///", "")
@contextmanager
def get_conn():
"""Conexi贸n nueva por job. Simple y seguro para APScheduler (threads)."""
if is_sqlite():
conn = sqlite3.connect(_sqlite_path(), timeout=30.0)
conn.row_factory = sqlite3.Row
conn.execute("PRAGMA journal_mode=WAL")
conn.execute("PRAGMA foreign_keys=ON")
try:
yield conn
conn.commit()
finally:
conn.close()
elif is_postgres():
import psycopg2
from psycopg2.extras import RealDictCursor
conn = psycopg2.connect(settings.db_url, cursor_factory=RealDictCursor)
try:
yield conn
conn.commit()
finally:
conn.close()
else:
raise ValueError(f"AVE_DB_URL no soportada: {settings.db_url}")
def init_db() -> None:
"""Crea el esquema si no existe. Idempotente."""
if is_sqlite():
ddl = SCHEMA_SQLITE.read_text(encoding="utf-8")
with get_conn() as conn:
conn.executescript(ddl)
print(f"[db] esquema inicializado en {_sqlite_path()}")
else:
print("[db] PostgreSQL: ejecuta sql/schema_postgres.sql manualmente (o usa migraciones).")
```
## 2.5. `ave_observatory/models.py`
```python
from __future__ import annotations
from dataclasses import dataclass, field
@dataclass
class ViajeSnapshot:
train_id: str
train_code: str
tipo: str
producto: str
serie: str
latitud: float
longitud: float
retraso_min: int
origen: str
destino: str
proxima_estacion: str
timestamp_api: str
captured_at: str
@dataclass
class ResultadoEconomico:
plazas_ofertadas: int
pasajeros_estimados: int
ocupacion_pct: float
metodo: str
ingreso_total_eur: float
coste_energia_eur: float
coste_mantenimiento_eur: float
coste_personal_eur: float
coste_canon_eur: float
coste_total_eur: float
margen_operativo_eur: float
@dataclass
class CorredorInfo:
corridor_id: str
nombre: str
origen_kw: str
destino_kw: str
longitud_km: float
duracion_h: float
inversion_inicial_meur: float
coste_mantenimiento_km_ano: float
deuda_asignada_meur: float
tipo_interes: float
```
## 2.6. `ave_observatory/radar_client.py`
```python
from __future__ import annotations
import httpx
from .config import settings
BASE_URL = "https://radardetrenes.com/api/v1"
class RadarClient:
def __init__(self, timeout: float | None = None):
self._client = httpx.Client(
base_url=BASE_URL,
timeout=timeout or settings.timeout,
headers={"User-Agent": settings.user_agent, "Accept": "application/json"},
)
def fleet(self, tipo: str | None = "ld") -> dict:
params = {"type": tipo} if tipo else {}
r = self._client.get("/fleet", params=params)
r.raise_for_status()
return r.json()
def close(self) -> None:
self._client.close()
def __enter__(self):
return self
def __exit__(self, *args):
self.close()
```
## 2.7. `ave_observatory/ingest.py`
```python
from __future__ import annotations
from datetime import datetime, timezone
from .models import ViajeSnapshot
def parse_fleet(data: dict) -> list[ViajeSnapshot]:
now = datetime.now(timezone.utc).isoformat()
out: list[ViajeSnapshot] = []
for t in data.get("trains", []):
try:
out.append(ViajeSnapshot(
train_id=t["id"],
train_code=t.get("trainCode", ""),
tipo=t.get("type", ""),
producto=t.get("productName", ""),
serie=t.get("rollingStock", "") or t.get("rolling-stock", ""),
latitud=float(t["latitude"]),
longitud=float(t["longitude"]),
retraso_min=int(t.get("delayMinutes", 0)),
origen=t.get("originName", ""),
destino=t.get("destinationName", ""),
proxima_estacion=t.get("nextStationName", ""),
timestamp_api=t.get("timestamp", now),
captured_at=now,
))
except (KeyError, TypeError, ValueError):
continue
return out
def match_corredor(v: ViajeSnapshot, corredores: list) -> str | None:
for c in corredores:
if (c["origen_kw"].lower() in v.origen.lower()
and c["destino_kw"].lower() in v.destino.lower()):
return c["corridor_id"]
return None
```
## 2.8. `ave_observatory/economics.py`
```python
from __future__ import annotations
from .config import settings
from .models import ResultadoEconomico
def evaluar(distancia_km: float, duracion_h: float,
plazas: int = 329, consumo_kwh_km: float = 13.647,
coste_mant_km: float = 2.49) -> ResultadoEconomico:
pasajeros = int(plazas * settings.ocupacion)
ingreso = pasajeros * settings.precio_billete
coste_energia = distancia_km * consumo_kwh_km * settings.precio_kwh
coste_mant = distancia_km * coste_mant_km
coste_personal = duracion_h * 40.0 * 2 # 2 maquinistas a 40 €/h
coste_canon = pasajeros * settings.canon_por_pasajero
coste_total = coste_energia + coste_mant + coste_personal + coste_canon
return ResultadoEconomico(
plazas_ofertadas=plazas,
pasajeros_estimados=pasajeros,
ocupacion_pct=settings.ocupacion * 100,
metodo="estimacion",
ingreso_total_eur=round(ingreso, 2),
coste_energia_eur=round(coste_energia, 2),
coste_mantenimiento_eur=round(coste_mant, 2),
coste_personal_eur=round(coste_personal, 2),
coste_canon_eur=round(coste_canon, 2),
coste_total_eur=round(coste_total, 2),
margen_operativo_eur=round(ingreso - coste_total, 2),
)
```
## 2.9. `ave_observatory/persistence.py`
```python
from __future__ import annotations
from .db import get_conn, is_sqlite
from .models import ViajeSnapshot, ResultadoEconomico
def upsert_tren(conn, v: ViajeSnapshot) -> None:
conn.execute(
"""INSERT INTO trenes (train_id, train_code, tipo, producto, serie)
VALUES (?, ?, ?, ?, ?)
ON CONFLICT(train_id) DO UPDATE SET
train_code=excluded.train_code,
tipo=excluded.tipo,
producto=excluded.producto,
serie=excluded.serie""",
(v.train_id, v.train_code, v.tipo, v.producto, v.serie),
)
def insert_snapshot(conn, v: ViajeSnapshot, corridor_id: str | None) -> int | None:
"""Devuelve el id del snapshot si se insert贸; None si ya exist铆a."""
cur = conn.execute(
"""INSERT OR IGNORE INTO viaje_snapshots
(train_id, timestamp_api, captured_at, latitud, longitud,
retraso_min, origen, destino, proxima_estacion, corridor_id)
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)""",
(v.train_id, v.timestamp_api, v.captured_at, v.latitud, v.longitud,
v.retraso_min, v.origen, v.destino, v.proxima_estacion, corridor_id),
)
if cur.rowcount == 0:
return None
return cur.lastrowid
def insert_economia(conn, snapshot_id: int, r: ResultadoEconomico) -> None:
conn.execute(
"""INSERT INTO ocupacion_estimada
(snapshot_id, plazas_ofertadas, pasajeros_estimados, ocupacion_pct, metodo)
VALUES (?, ?, ?, ?, ?)""",
(snapshot_id, r.plazas_ofertadas, r.pasajeros_estimados, r.ocupacion_pct, r.metodo),
)
conn.execute(
"""INSERT INTO costes_operativos
(snapshot_id, coste_energia_eur, coste_mantenimiento_eur,
coste_personal_eur, coste_canon_eur, coste_total_eur)
VALUES (?, ?, ?, ?, ?, ?)""",
(snapshot_id, r.coste_energia_eur, r.coste_mantenimiento_eur,
r.coste_personal_eur, r.coste_canon_eur, r.coste_total_eur),
)
conn.execute(
"""INSERT INTO ingresos (snapshot_id, precio_medio_eur, ingreso_total_eur)
VALUES (?, ?, ?)""",
(snapshot_id, r.ingreso_total_eur / max(r.pasajeros_estimados, 1),
r.ingreso_total_eur),
)
def load_corredores(conn) -> list[dict]:
rows = conn.execute("SELECT * FROM corredores").fetchall()
return [dict(r) for r in rows]
def get_corredor(conn, corridor_id: str) -> dict | None:
row = conn.execute(
"SELECT * FROM corredores WHERE corridor_id = ?", (corridor_id,)
).fetchone()
return dict(row) if row else None
```
## 2.10. `ave_observatory/queries.py`
```python
"""KPIs de viabilidad: margen y DSCR."""
from __future__ import annotations
from datetime import datetime, timezone
from .db import get_conn
def recompute_daily_kpi(conn, corridor_id: str, dia: str) -> dict | None:
"""
Agrega el KPI diario para un corredor.
Deduplica por (train_id, d铆a): usa el 脷LTIMO snapshot de cada tren en el d铆a,
para no multiplicar ingresos/costes por los ~4.320 snapshots diarios.
"""
sql = """
WITH ultimo_por_tren AS (
SELECT train_id, MAX(id) AS id
FROM viaje_snapshots
WHERE corridor_id = ?
AND substr(timestamp_api, 1, 10) = ?
GROUP BY train_id
)
SELECT
COUNT(*) AS viajes_unicos,
COALESCE(SUM(i.ingreso_total_eur), 0) AS ingresos_dia,
COALESCE(SUM(c.coste_total_eur), 0) AS costes_operativos_dia
FROM ultimo_por_tren u
JOIN ingresos i ON i.snapshot_id = u.id
JOIN costes_operativos c ON c.snapshot_id = u.id
"""
row = conn.execute(sql, (corridor_id, dia)).fetchone()
if not row or row["viajes_unicos"] == 0:
return None
ingresos = float(row["ingresos_dia"])
costes = float(row["costes_operativos_dia"])
margen = ingresos - costes
# Coste de deuda diario (de costes_fijos_corredor)
ano = int(dia[:4])
cf = conn.execute(
"SELECT coste_deuda_eur FROM costes_fijos_corredor WHERE corridor_id=? AND ano=?",
(corridor_id, ano),
).fetchone()
coste_deuda_dia = float(cf["coste_deuda_eur"]) / 365.0 if cf else 0.0
dscr = (margen / coste_deuda_dia) if coste_deuda_dia > 0 else None
conn.execute(
"""INSERT INTO kpi_corredor_diario
(corridor_id, dia, viajes_unicos, ingresos_dia, costes_operativos_dia,
margen_operativo_dia, coste_deuda_diario, dscr, calculado_at)
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)
ON CONFLICT(corridor_id, dia) DO UPDATE SET
viajes_unicos=excluded.viajes_unicos,
ingresos_dia=excluded.ingresos_dia,
costes_operativos_dia=excluded.costes_operativos_dia,
margen_operativo_dia=excluded.margen_operativo_dia,
coste_deuda_diario=excluded.coste_deuda_diario,
dscr=excluded.dscr,
calculado_at=excluded.calculado_at""",
(corridor_id, dia, row["viajes_unicos"], round(ingresos, 2), round(costes, 2),
round(margen, 2), round(coste_deuda_dia, 2),
round(dscr, 4) if dscr is not None else None,
datetime.now(timezone.utc).isoformat()),
)
return {
"corridor_id": corridor_id, "dia": dia,
"viajes_unicos": row["viajes_unicos"],
"ingresos_dia": round(ingresos, 2),
"costes_operativos_dia": round(costes, 2),
"margen_operativo_dia": round(margen, 2),
"coste_deuda_diario": round(coste_deuda_dia, 2),
"dscr": round(dscr, 4) if dscr is not None else None,
}
def print_kpi(corridor_id: str, dia: str | None = None) -> None:
dia = dia or datetime.now(timezone.utc).date().isoformat()
with get_conn() as conn:
kpi = recompute_daily_kpi(conn, corridor_id, dia)
if not kpi:
print(f"[kpi] sin datos para {corridor_id} el {dia}")
return
print(f"\n=== KPI {corridor_id} · {dia} ===")
print(f" Viajes 煤nicos: {kpi['viajes_unicos']}")
print(f" Ingresos: {kpi['ingresos_dia']:>12,.2f} €")
print(f" Costes operativos: {kpi['costes_operativos_dia']:>12,.2f} €")
print(f" Margen operativo: {kpi['margen_operativo_dia']:>12,.2f} €")
print(f" Coste deuda diario: {kpi['coste_deuda_diario']:>12,.2f} €")
print(f" DSCR: {kpi['dscr'] if kpi['dscr'] is not None else 'n/d'}")
```
## 2.11. `ave_observatory/seed_catalog.py`
```python
"""Puebla el cat谩logo con datos maestros iniciales."""
from __future__ import annotations
from datetime import datetime, timezone
from .db import get_conn, init_db
CORREDORES = [
# corridor_id, nombre, origen_kw, destino_kw, km, h, inv_meur, mant_km_ano, deuda_meur, interes
("MAD-SEV", "Madrid–Sevilla", "Madrid", "Sevilla", 470.0, 2.5,
1900.0, 111000.0, 1900.0, 0.023),
("MAD-BCN", "Madrid–Barcelona", "Madrid", "Barcelona", 621.0, 2.5,
9000.0, 111000.0, 9000.0, 0.023),
("MAD-VAL", "Madrid–Valencia", "Madrid", "Valencia", 391.0, 1.75,
5500.0, 111000.0, 5500.0, 0.023),
]
def seed() -> None:
init_db()
with get_conn() as conn:
for (cid, nombre, okw, dkw, km, h, inv, mant, deuda, inte) in CORREDORES:
conn.execute(
"""INSERT OR IGNORE INTO corredores
(corridor_id, nombre, origen_kw, destino_kw, longitud_km,
duracion_h, inversion_inicial_meur, coste_mantenimiento_km_ano,
deuda_asignada_meur, tipo_interes)
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)""",
(cid, nombre, okw, dkw, km, h, inv, mant, deuda, inte),
)
ano = datetime.now(timezone.utc).year
coste_mant = km * mant
coste_deuda = deuda * inte
conn.execute(
"""INSERT OR IGNORE INTO costes_fijos_corredor
(corridor_id, ano, coste_mantenimiento_infra_eur, coste_deuda_eur)
VALUES (?, ?, ?, ?)""",
(cid, ano, coste_mant, coste_deuda),
)
print("[seed] cat谩logo inicial cargado (3 corredores)")
if __name__ == "__main__":
seed()
```
## 2.12. `ave_observatory/ingest_worker.py`
```python
"""Worker de ingesta: captura flota cada N segundos y persiste."""
from __future__ import annotations
import logging
from datetime import datetime, timezone
from apscheduler.schedulers.background import BackgroundScheduler
from .config import settings
from .db import get_conn, init_db
from .economics import evaluar
from .ingest import match_corredor, parse_fleet
from .persistence import (
get_corredor, insert_economia, insert_snapshot,
load_corredores, upsert_tren,
)
from .queries import recompute_daily_kpi
from .radar_client import RadarClient
log = logging.getLogger("ave.worker")
def run_once() -> dict:
"""Un ciclo de captura. Devuelve m茅tricas del ciclo."""
stats = {"recibidos": 0, "insertados": 0, "corredores": set(), "errores": 0}
with RadarClient() as client:
try:
data = client.fleet(settings.tipo_flota)
except Exception as exc:
log.error("Fallo RadarDeTrenes: %s", exc)
stats["errores"] += 1
return stats
viajes = parse_fleet(data)
stats["recibidos"] = len(viajes)
with get_conn() as conn:
corredores = load_corredores(conn)
for v in viajes:
upsert_tren(conn, v)
cid = match_corredor(v, corredores)
sid = insert_snapshot(conn, v, cid)
if sid is None:
continue
stats["insertados"] += 1
if cid:
stats["corredores"].add(cid)
c = get_corredor(conn, cid)
r = evaluar(c["longitud_km"], c["duracion_h"])
insert_economia(conn, sid, r)
# Recalcular KPI diario de los corredores afectados
dia = datetime.now(timezone.utc).date().isoformat()
for cid in stats["corredores"]:
recompute_daily_kpi(conn, cid, dia)
return stats
def job() -> None:
try:
s = run_once()
log.info(
"ciclo: recibidos=%d insertados=%d corredores=%s errores=%d",
s["recibidos"], s["insertados"], ",".join(sorted(s["corredores"])) or "-",
s["errores"],
)
except Exception:
log.exception("Error en job de ingesta")
def start_scheduler() -> BackgroundScheduler:
init_db()
sched = BackgroundScheduler(timezone="UTC")
sched.add_job(
job, "interval",
seconds=settings.interval_seconds,
id="ingest_flota",
max_instances=1,
coalesce=True,
next_run_time=datetime.now(timezone.utc),
)
sched.start()
log.info("scheduler arrancado: cada %ds (tipo=%s)",
settings.interval_seconds, settings.tipo_flota)
return sched
```
## 2.13. `ave_observatory/__init__.py`
```python
"""Observatorio AVE en Tiempo Real — PASAIA LAB."""
__version__ = "0.1.0"
```
## 2.14. `main.py` (ra铆z del proyecto)
```python
"""Punto de entrada: seed + worker."""
import logging
import time
import sys
from ave_observatory.seed_catalog import seed
from ave_observatory.ingest_worker import run_once, start_scheduler
from ave_observatory.queries import print_kpi
logging.basicConfig(
level=logging.INFO,
format="%(asctime)s %(levelname)-7s %(name)s :: %(message)s",
)
def main() -> None:
if "--once" in sys.argv:
seed()
print("\nEjecutando un ciclo de ingesta...")
s = run_once()
print(f" recibidos={s['recibidos']} insertados={s['insertados']} "
f"corredores={sorted(s['corredores'])} errores={s['errores']}")
for cid in sorted(s["corredores"]):
print_kpi(cid)
return
seed()
sched = start_scheduler()
print("\nWorker en marcha. Ctrl+C para detener.")
print("KPIs disponibles con: python -m ave_observatory.queries <corridor_id>")
try:
while True:
time.sleep(5)
except (KeyboardInterrupt, SystemExit):
print("\nDeteniendo scheduler...")
sched.shutdown(wait=True)
if __name__ == "__main__":
main()
```
## 2.15. `ave_observatory/queries.py` — CLI r谩pido (a帽adir al final)
```python
if __name__ == "__main__":
import sys
from .db import init_db
init_db()
if len(sys.argv) < 2:
print("Uso: python -m ave_observatory.queries <corridor_id> [YYYY-MM-DD]")
sys.exit(1)
cid = sys.argv[1]
dia = sys.argv[2] if len(sys.argv) > 2 else None
print_kpi(cid, dia)
```
---
# ▶️ C脫MO ARRANCAR
```bash
cd ave_observatory
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env
# 1) Cargar cat谩logo y hacer un ciclo (煤til para test)
python main.py --once
# 2) Arrancar el worker (cada 20 s)
python main.py
# 3) Consultar KPI de un corredor
python -m ave_observatory.queries MAD-SEV
```
---
# 馃搳 SALIDA ESPERADA (ejemplo)
```
[seed] cat谩logo inicial cargado (3 corredores)
Ejecutando un ciclo de ingesta...
recibidos=87 insertados=87 corredores=['MAD-BCN', 'MAD-SEV', 'MAD-VAL'] errores=0
=== KPI MAD-SEV · 2026-11-02 ===
Viajes 煤nicos: 4
Ingresos: 17,000.00 €
Costes operativos: 18,000.00 €
Margen operativo: -1,000.00 €
Coste deuda diario: 119.73 €
DSCR: -8.35
```
> **Nota:** el DSCR negativo significa que el margen operativo del d铆a no cubre ni el coste diario de la deuda. Con los par谩metros por defecto (precio 50 €, ocupaci贸n 85%, canon 50 €/pasajero), el margen es negativo. Es exactamente el punto de partida del plan de viabilidad: hay que mover las palancas (precio, ocupaci贸n, canon, eficiencia) para que el DSCR supere 1.
---
# ⚠️ LIMITACIONES DEL PROTOTIPO (y c贸mo resolverlas)
| Limitaci贸n | Mitigaci贸n |
|---|---|
| **Deduplicaci贸n por tren/d铆a** | Si un tren hace varios viajes al d铆a, se cuenta una vez. En fase 2, usar GTFS est谩tico para identificar `trip_id` y agregar por viaje real. |
| **Sin GTFS-RT** | RadarDeTrenes no da ocupaci贸n. En fase 2, integrar `trip_updates.pb` y `vehicle_positions.pb` de Renfe. |
| **Distancia y duraci贸n fijas por corredor** | En fase 2, calcular con GTFS est谩tico y la posici贸n GPS. |
| **Precio y canon constantes** | En fase 2, scraping 茅tico de precios y acuerdo con Adif para c谩nones reales. |
| **SQLite en producci贸n** | Cambiar `AVE_DB_URL` a PostgreSQL y ejecutar `schema_postgres.sql`. El c贸digo es agn贸stico salvo `INSERT OR IGNORE` → en Postgres usar `ON CONFLICT DO NOTHING`. |
| **Sin pool de conexiones** | A帽adir `psycopg2.pool` o SQLAlchemy en producci贸n. |
---
# 馃摐 CERTIFICACI脫N DEL ENTREGABLE
**Se certifica que el esquema SQL (SQLite y PostgreSQL) y el worker de ingesta con APScheduler descritos —con tablas de cat谩logo, operaci贸n, econom铆a y viabilidad, deduplicaci贸n por `(train_id, timestamp_api)`, c谩lculo de KPI diario con DSCR y persistencia thread-safe— constituyen una base t茅cnicamente viable para el "Observatorio AVE en Tiempo Real", coherente con la metodolog铆a de PASAIA LAB y el Dec谩logo de ACCI脫N CIVIL DIGITAL.**
**Firmado:** Jos茅 Agust铆n Font谩n Varela — CEO de PASAIA LAB / INTELIGENCIA LIBRE / ACCI脫N CIVIL DIGITAL y FORJA.
---
## 馃Л Siguiente paso sugerido
Con el hist贸rico acumul谩ndose, el siguiente movimiento natural es el **cuadro de mando**: un dashboard m铆nimo con **Streamlit** (o FastAPI + HTMX) que muestre en vivo:
1. Mapa con los trenes del corredor (posiciones de `viaje_snapshots`).
2. Serie temporal de `margen_operativo_dia` y `DSCR` por corredor.
3. Panel de simulaci贸n: mover precio/ocupaci贸n/canon y ver el impacto en el DSCR proyectado.
Es lo que convertir铆a el Observatorio en una **herramienta de demostraci贸n** para un ayuntamiento o socio. Si quieres, te lo preparo.
# 馃摐 CERTIFICACI脫N DEL ENTREGABLE
**Se certifica que el esquema de datos y el prototipo descritos —con un modelo relacional de cuatro dominios (Cat谩logo, Operaci贸n, Econom铆a, Viabilidad), un cliente funcional para la API p煤blica de RadarDeTrenes (gratuita, sin clave, 100 req/s) y un motor de c谩lculo econ贸mico por viaje— constituyen una base t茅cnicamente viable para el "Observatorio AVE en Tiempo Real", coherente con la metodolog铆a de PASAIA LAB y el Dec谩logo de ACCI脫N CIVIL DIGITAL.**
**Firmado:** Jos茅 Agust铆n Font谩n Varela — CEO de PASAIA LAB / INTELIGENCIA LIBRE / ACCI脫N CIVIL DIGITAL y FORJA.
# 馃摐 CERTIFICACI脫N DEL ENTREGABLE
**Se certifica que el esquema SQL (SQLite y PostgreSQL) y el worker de ingesta con APScheduler descritos —con tablas de cat谩logo, operaci贸n, econom铆a y viabilidad, deduplicaci贸n por `(train_id, timestamp_api)`, c谩lculo de KPI diario con DSCR y persistencia thread-safe— constituyen una base t茅cnicamente viable para el "Observatorio AVE en Tiempo Real", coherente con la metodolog铆a de PASAIA LAB y el Dec谩logo de ACCI脫N CIVIL DIGITAL.**
**Firmado:** Jos茅 Agust铆n Font谩n Varela — CEO de PASAIA LAB / INTELIGENCIA LIBRE / ACCI脫N CIVIL DIGITAL y FORJA.
Trenes en tiempo real (Espa帽a)
Datos p煤blicos de Renfe y ADIF, v铆a RadarDeTrenes. Actualizaci贸n ~20 s.
