Qué sistema operativo usan realmente los drones militares

Los drones militares se han convertido en una pieza clave de las operaciones modernas, pero detrás de sus cámaras, misiles y enlaces satelitales hay algo mucho menos vistoso y absolutamente crítico: el sistema operativo que los gobierna. Elegir qué software controla un dron de combate o vigilancia no es un simple detalle técnico, sino una decisión estratégica que afecta a la seguridad, los costes, la autonomía y hasta la ética de su uso.

Cuando alguien se pregunta qué sistema operativo usan los drones militares, la respuesta real es bastante más compleja que un simple “Windows” o “Linux”. En un mismo sistema entran en juego estaciones de control en tierra, enlaces de comunicaciones, pilotos automáticos, software embebido en tiempo real y capas de seguridad que deben resistir tanto fallos técnicos como ciberataques. Vamos a desgranar cómo funciona todo este ecosistema, qué está usando realmente la industria militar y por qué el código abierto está ganando un peso que hace años habría parecido impensable.

Conceptos básicos: UA, UAV, UAS, RPAS y “drones”

Antes de hablar de sistemas operativos conviene aclarar el vocabulario, porque en el mundo de los drones militares se usan siglas que muchas veces se mezclan como si fueran lo mismo, y no lo son exactamente.

UA (Unmanned Aircraft) hace referencia a la aeronave no tripulada en sí, es decir, al “avión” sin piloto a bordo. Cuando escuchas hablar de UAV (Unmanned Aerial Vehicle), el significado es muy similar: vehículo aéreo no tripulado. Ambos términos se centran en la plataforma que vuela, sin entrar todavía en el resto de componentes del sistema.

UAS (Unmanned Aerial System) es un concepto más amplio, porque ya no alude solo al dron, sino al conjunto formado por la aeronave, la estación de control en tierra y el enlace de comunicaciones que los une. Es decir, el UAS incluye tanto el “pájaro” como los ordenadores, antenas, software y operadores que permiten que la misión se lleve a cabo.

Cuando esa aeronave se pilota a distancia por una persona a través de un enlace de datos hablamos de RPA (Remotely Piloted Aircraft), y si incluimos todo el sistema (aeronave + estación de tierra + comunicaciones) lo correcto es usar RPAS (Remotely Piloted Aircraft System). Todos los RPAS son UAS, pero no todos los UAS tienen por qué ser RPAS, porque algunos pueden volar con una autonomía casi total siguiendo planes preprogramados.

El término “dron” se popularizó primero en el ámbito militar a mediados del siglo XX y hoy se usa de forma coloquial para casi cualquier aeronave no tripulada. La OACI (Organización de Aviación Civil Internacional) suele reservar “drone” o “dron” para referirse sobre todo a RPAS de menor tamaño, habitualmente por debajo de los 25 kg, aunque en el lenguaje diario acabamos llamando dron tanto a un cuadricóptero recreativo como a un MQ-9 Reaper armado.

Qué partes de un dron militar usan sistema operativo

Cuando pensamos en el “sistema operativo de un dron”, en realidad hablamos de varios niveles de software interactuando al mismo tiempo. En un dron militar moderno podemos distinguir, al menos, tres grandes bloques donde entran los sistemas operativos:

1. Estación de control en tierra. Es el conjunto de ordenadores, pantallas, consolas y redes desde donde los operadores monitorizan el vuelo, controlan la carga útil (sensores, cámaras, armas) y planifican misiones. Aquí se usan sistemas operativos de propósito general, como Linux o Windows, junto con software específico de mando y control desarrollado por las propias empresas de defensa.

2. Computadores de misión y aviónica a bordo. En el interior de la aeronave se integran sistemas de navegación, gestión de energía, comunicaciones, sensores y, en el caso de drones de combate, módulos de control de armamento. Estos subsistemas suelen apoyarse en sistemas operativos en tiempo real (RTOS) o variantes muy recortadas y endurecidas de Linux, diseñadas para responder con precisión y fiabilidad en milisegundos.

3. Autopiloto y control de vuelo. Es el “cerebro” que mantiene estable el dron, sigue rutas, gestiona alturas y, en algunos casos, toma decisiones de contingencia cuando se pierde la señal o el GPS. Aquí encajan plataformas como ArduPilot o PX4 en el ámbito abierto, y soluciones propietarias de fabricantes en las plataformas estrictamente militares o clasificadas.

Sobre esta arquitectura se suman capas de seguridad (cifrado, autenticación, hardening del sistema) que afectan también al sistema operativo. De ahí que la elección de OS no solo tenga que ver con rendimiento o compatibilidad, sino, sobre todo, con ciberseguridad y facilidad para certificar el sistema ante las autoridades de defensa.

Linux gana terreno en los drones militares

En los últimos años se ha producido un giro muy claro hacia Linux en el control de drones militares, especialmente en las estaciones de mando y en los sistemas de misión. Un caso emblemático es el cambio decidido por Raytheon en los sistemas de control de los UAV de la Marina de Estados Unidos.

Raytheon, uno de los grandes contratistas de defensa, abandonó el uso de Solaris en favor de distribuciones Linux en los sistemas de control de drones navales. El primer aparato afectado por este cambio fue el Northrop Grumman MQ-8C Fire Scout, un helicóptero no tripulado utilizado para misiones de vigilancia y apoyo a unidades navales.

Según la información difundida en medios especializados, Raytheon firmó un contrato de unos 15,8 millones de dólares para adaptar sus sistemas de control a Linux en el entorno de la Marina estadounidense. La compañía defendía que este cambio haría la interfaz de los sistemas más intuitiva para los operadores, simplificaría el despliegue de actualizaciones y reduciría costes de mantenimiento a largo plazo.

Esta migración no estuvo exenta de polémica. Oracle, propietaria de Solaris, había advertido en 2013 de que el software de código abierto representaba un riesgo de seguridad “inaceptable”. El movimiento de la Marina estadounidense, sin embargo, apuntaba en la dirección opuesta: confiar en Linux, reforzado y configurado adecuadamente, como base de sistemas críticos de defensa.

Además del caso Raytheon, otros episodios empujaron a abandonar plataformas menos robustas. Hubo incidentes documentados en los que sistemas que controlaban UAV de la Fuerza Aérea de Estados Unidos, basados en Windows, se vieron afectados por malware. En uno de ellos, un virus que habría llegado a través de un disco duro portátil con un juego infectado generó suficiente alarma como para acelerar migraciones a Linux en determinados entornos de defensa relacionados con drones y operaciones de vuelo.

Windows y otros sistemas en la cadena de control

A pesar del avance de Linux, Windows no ha desaparecido por completo de los ecosistemas que rodean a los drones militares. Durante años, muchas estaciones de control en tierra se apoyaron en sistemas Windows por inercia corporativa, disponibilidad de software de análisis y herramientas de integración con otros sistemas de mando.

El problema es que la superficie de ataque de un sistema Windows estándar es mayor si no se aplica un endurecimiento extremo. En contextos donde el riesgo de infección por malware o intrusión remota es elevado, cualquier vulnerabilidad del sistema operativo puede afectar a la capacidad de mando sobre los UAV. Los incidentes de la Fuerza Aérea de EEUU con virus en sus estaciones de control han sido un aviso muy claro en este sentido.

Más allá de Windows y Linux también entran en juego RTOS comerciales como VxWorks, QNX u otros desarrollos propietarios embebidos en la aviónica. Estos sistemas, pensados para certificación aeronáutica y respuesta determinista, resultan habituales en controladores de vuelo, sistemas de navegación y módulos críticos donde la prioridad absoluta es la fiabilidad y el cumplimiento estricto de tiempos.

En la práctica, muchos grandes drones militares combinan todo este abanico: estaciones de tierra con Linux endurecido (y en algunos casos aún Windows en tareas de soporte), RTOS en aviónica y control de sensores, y capas de software intermedio que integran comunicaciones cifradas, protocolos militares y aplicaciones específicas de planificación y ejecución de misiones.

ArduPilot, PX4 y el papel del código abierto en conflictos modernos

Si hay un ejemplo que ilustre el poder del software de código abierto en la guerra moderna, ese es el caso de ArduPilot en el conflicto entre Ucrania y Rusia. Lo que empezó como un proyecto “de garaje” para aficionados a los drones ha terminado convertido en el cerebro de operaciones de enorme impacto estratégico.

ArduPilot nació en 2007 cuando Chris Anderson, por entonces editor de la revista WIRED, combinó un kit de Lego Mindstorms con una placa Arduino para construir un primer piloto automático casero. Junto a Jordi Muñoz y Jason Short, posteriormente fundaron 3DR y en 2009 lanzaron las primeras versiones del software de autopilotaje.

Con el tiempo, ArduPilot se consolidó como una de las plataformas de piloto automático más versátiles del mundo, apta no solo para drones aéreos sino también para barcos, submarinos, vehículos terrestres y aplicaciones civiles como agricultura de precisión, cartografía o rescate. Todo sustentado por una comunidad global de desarrolladores y entusiastas.

El salto a la primera línea del conflicto llegó con la llamada “Operación Telaraña”, una ofensiva aérea ejecutada por Ucrania el 1 de junio de 2025. En ella se coordinaron 117 drones FPV (First Person View) tipo “kamikaze” que penetraron profundamente en territorio ruso, golpeando múltiples bases aéreas como Belaya, Olenya e Ivanovo.

Según el Servicio de Seguridad de Ucrania (SBU), en aquella operación se destruyeron o dañaron 41 aeronaves, incluyendo bombarderos estratégicos Tu‑95, Tu‑160 y Tu‑22M3, responsables de lanzar misiles de crucero contra Ucrania. El coste relativo de los drones usados, comparado con el valor de los aparatos destruidos, fue irrisorio: se estima que los daños ocasionados llegaron a los 7.000 millones de dólares.

La clave tecnológica estuvo en el uso de ArduPilot como software de autopiloto, integrando funciones de navegación autónoma capaces de mantener el rumbo incluso con pérdidas de señal o fuertes interferencias de GPS. Los drones se adaptaron con hardware comercial, a menudo montado sobre placas tipo Raspberry Pi y módulos de radio sencillos, ocultos en camiones con compartimentos secretos dentro del propio territorio ruso.

Los desarrolladores originales de ArduPilot nunca imaginaron este uso. El proyecto se diseñó para fines pacíficos y su código de conducta rechaza el uso militar, pero al ser software libre cualquiera puede descargarlo, modificarlo y reempaquetarlo sin restricciones legales. Uno de sus creadores llegó a declarar que jamás habría pensado que terminaría impulsando un ataque de esa magnitud.

Este caso ha reavivado el debate ético en torno al software libre: ¿debería limitarse su empleo en la guerra? Muchos defensores del open source sostienen que la esencia de la licencia es precisamente la libertad total de uso, también por parte de estados o ejércitos. Lo que sí es evidente es que, gracias a este tipo de software, países con presupuestos más reducidos pueden ejecutar operaciones asimétricas de gran impacto.

La nueva forma de hacer la guerra: barata, asimétrica y abierta

El uso de ArduPilot en Ucrania encaja en un patrón más amplio de transformación de la guerra. Frente a los sistemas masivos, extremadamente caros y tecnológicamente complejos, surge un modelo donde se prima la creatividad, el bajo coste y el aprovechamiento de tecnología comercial disponible para cualquiera.

En esta lógica, un enjambre de drones modestos, equipados con componentes civiles y software libre, puede poner en jaque a activos militares de miles de millones. La dificultad para defender instalaciones críticas frente a ataques coordinados, rápidos y lanzados desde muy lejos de las líneas de frente obligan a replantear doctrinas completas de defensa aérea.

Para muchos analistas de defensa, esto marca un cambio de paradigma. Ya no basta con tener más tanques, cazas o sistemas antiaéreos sofisticados: cualquier país, o incluso grupos no estatales con acceso a cierta base tecnológica, puede organizar ataques de largo alcance apoyándose en software gratuito y hardware barato.

Todo esto complica enormemente el trabajo de los defensores, que no pueden “protegerlo todo, en todas partes, todo el tiempo”. Cada hangar, almacén o pista de despegue puede convertirse en objetivo de un dron relativamente sencillo, pero con un sistema operativo y un software de control muy bien afinados.

En paralelo, surgen desarrollos defensivos igualmente avanzados, como sistemas láser de alta energía tipo Iron Beam, presentados por Israel, capaces de derribar drones y cohetes a un coste por disparo mucho menor que el de un misil tradicional. Aquí también el control de sensores, radares y armas energéticas se apoya en sistemas operativos robustos y software muy especializado.

El MQ-9 Reaper: un caso real de dron militar de gran tamaño

Para entender mejor dónde encajan los sistemas operativos en un dron militar grande, conviene mirar un ejemplo concreto: el General Atomics MQ‑9 Reaper, antaño conocido como Predator B. Se trata de un UAV de combate empleado por la Fuerza Aérea de Estados Unidos, la Fuerza Aérea Italiana, el Ejército del Aire y del Espacio de España y otros usuarios internacionales.

El MQ‑9 es un dron de mayor tamaño y capacidad que su predecesor MQ‑1 Predator. Cuenta con un motor turbohélice de unos 950 shp, frente al motor de pistón de 119 hp del Predator, lo que le permite transportar unas quince veces más carga útil y alcanzar una velocidad de crucero aproximadamente tres veces superior.

Su desarrollo comenzó con el prototipo Predator B‑001, que voló por primera vez el 2 de febrero de 2001. Basado en el fuselaje del MQ‑1 pero con fuselaje alargado y una envergadura ampliada de 14,6 a 20 metros, este prototipo alcanzaba alrededor de 444 km/h, podía cargar unos 340 kg a altitudes del orden de 15.200 metros y mantener autonomías de hasta 30 horas de vuelo.

General Atomics exploró varias variantes del diseño. Una de ellas, el Predator B‑002, montó un motor turbofán Williams FJ44‑2A, con mayor techo de servicio (en torno a 18.300 metros) pero menor autonomía, alrededor de 12 horas. Otra variante, el Predator B‑003 o “Altair”, aumentó la envergadura hasta unos 25,6 metros, con un peso al despegue cercano a 3.175 kg y capacidad de carga de 1.360 kg, empleando un turbohélice similar al B‑001 para alcanzar hasta 36 horas de autonomía.

El sistema operacional típico del MQ‑9 no se limita a la aeronave. Incluye varias plataformas aéreas, estaciones de control en tierra (donde se ejecutan sistemas operativos de propósito general, reforzados para uso militar), enlaces satelitales y tripulaciones de vuelo y mantenimiento que se reparten turnos a miles de kilómetros del área de operaciones, por ejemplo, en bases como Creech AFB en Nevada.

En términos de prestaciones, el MQ‑9 ronda velocidades máximas de unos 480 km/h, con cruceros típicos cercanos a 278-313 km/h. Su alcance operativo supera con holgura los 1.900 km, y en determinadas configuraciones con depósitos externos y cargas de armas específicas puede llegar a mantener vuelos de más de 40 horas, especialmente en misiones de vigilancia con carga bélica reducida.

El Reaper dispone de seis pilones o puntos de anclaje externos. Los internos pueden soportar hasta unos 680 kg, los medios alrededor de 270-340 kg y los exteriores aproximadamente 68-90 kg. Gracias a esta configuración puede portar depósitos de combustible adicionales, bombas guiadas por láser GBU‑12 Paveway, bombas JDAM GBU‑38 y misiles aire‑superficie AGM‑114 Hellfire, además de capacidades aire‑aire con misiles AIM‑9 Sidewinder o, según pruebas, AIM‑9X y Brimstone.

En cuanto a aviónica y sensores, el MQ‑9 monta suites avanzadas como la Raytheon AN/AAS‑52, que reúne cámaras de TV color/monocromo, sensores infrarrojos y designador/telemetro láser. Se ha mencionado incluso la capacidad de leer matrículas de vehículos a varios kilómetros de distancia, con la señal transmitida casi en tiempo real por enlaces satelitales de banda Ku u otras bandas dedicadas.

El mismo dron tiene variantes y usuarios civiles o mixtos. La NASA, por ejemplo, opera una versión desarmada apodada “Ikhana” centrada en misiones científicas y monitorización de incendios forestales, y empleó previamente la versión “Altair” en programas como ERAST para misiones de ciencia atmosférica. El Servicio de Aduanas y Protección Fronteriza de Estados Unidos (CBP) también opera varios MQ‑9 en versiones de vigilancia fronteriza y marítima, equipados con radar de apertura sintética Lynx y sensores electro‑ópticos/infrarrojos adaptados a su misión.

Usuarios internacionales y costes del MQ‑9 Reaper

El MQ‑9 Reaper se ha convertido en un estándar de facto entre los drones MALE (Medium Altitude Long Endurance) y su uso se ha extendido por varios países aliados de Estados Unidos. Esto ayuda a entender el tipo de infraestructuras de software y sistemas operativos que se despliegan alrededor de un dron de esta categoría.

En términos económicos, el programa MQ‑9 se ha valorado en miles de millones de dólares. Se estima un coste del sistema completo (incluyendo cuatro aeronaves, estaciones de control en tierra y enlaces satelitales) en torno a los 120 millones de dólares, lo que situaría cada aparato individual en algo más de 30 millones, según cifras aproximadas de la década de 2010. El coste por hora de vuelo ha oscilado en torno a los 3.600-4.700 dólares, dependiendo del periodo y las fuentes.

Entre los usuarios destacados encontramos a la Fuerza Aérea de Estados Unidos, el CBP, la Royal Air Force británica, la Aeronautica Militare italiana y el Ejército del Aire y del Espacio de España, entre otros. Muchos de ellos han optado por versiones o kits de armamento específicos, en ocasiones con acuerdos posteriores para integrar armas guiadas de precisión y ampliar su contribución a operaciones de coalición.

Bélgica, por ejemplo, seleccionó el MQ‑9B SkyGuardian principalmente para tareas de reconocimiento, adquiriendo varias aeronaves y estaciones de tierra. España adquirió cuatro MQ‑9 en versión Block 5 con equipamiento asociado, incluyendo kits de pre‑armado que permiten, llegado el caso, integrar sistemas de armas como los misiles Hellfire, algo que se ha confirmado en información posterior.

Francia, Países Bajos, Reino Unido, India y Marruecos también figuran entre los países que han obtenido o solicitado versiones del Reaper, ya sea para misiones de vigilancia, control marítimo o ataque. Marruecos, por ejemplo, acordó la compra de MQ‑9 SeaGuardian completamente armados, adaptados a misiones navales y costeras.

La NASA, además de sus versiones “Altair” e “Ikhana”, utiliza el MQ‑9 para misiones científicas que requieren largas autonomías y operar en espacio aéreo civil bajo control de la FAA, lo que implica certificaciones adicionales en materia de aviónica, comunicaciones y, cómo no, software y sistemas operativos que cumplen con normativas civiles y no solo militares.

Todos estos operadores comparten una misma idea de fondo: un dron como el MQ‑9 no es solo un avión teledirigido, sino un sistema de sistemas donde la combinación de hardware, sensores, enlaces y software de control —incluyendo los sistemas operativos en cada eslabón— marca la diferencia entre un simple “avión no tripulado” y una plataforma estratégica multifunción.

Programas nacionales y terminología en España: el caso del INTA

En España, además de la compra de plataformas como el MQ‑9, existe una larga trayectoria de desarrollo propio de RPAS a través del INTA (Instituto Nacional de Técnica Aeroespacial). Sus proyectos ilustran bien cómo se conciben estos sistemas y qué lugar ocupan dentro de la terminología oficial UA/UAV/UAS/RPAS.

El INTA inició su catálogo con el SIVA (Sistema Integrado de Vigilancia Aérea), un sistema táctico de tamaño medio orientado a misiones de observación y vigilancia en tiempo real. El SIVA actuó como demostrador tecnológico y “semilla” de toda una familia posterior de plataformas no tripuladas.

A partir de la experiencia con SIVA se desarrollaron otros sistemas como el ALO (Avión Ligero de Observación), concebido para misiones de reconocimiento, y el Diana, diseñado como blanco aéreo de bajo coste para entrenamiento de defensas antiaéreas. El trabajo realizado con el ALO derivó también en el ALBA (Avión Ligero Blanco Aéreo), empleado por las Fuerzas Armadas en el Centro de Experimentación de El Arenosillo.

Entre los programas más actuales destaca el MILANO, un dron de observación de altitud media y gran autonomía (clasificado como MALE) capaz de operar en todo tiempo y más allá de la línea de vista (BLOS, Beyond Line of Sight), apoyándose en enlaces satelitales. El vehículo aéreo MILANO, con un peso en servicio aproximado de 900 kg, está diseñado para misiones de hasta 20 horas, con una carga útil de alrededor de 150 kg.

En todos estos proyectos, la elección de sistemas operativos y arquitecturas de software sigue la misma lógica que en los grandes programas internacionales: RTOS y soluciones embebidas para aviónica crítica, y sistemas de propósito general —habitualmente basados en Linux reforzado— en estaciones de control y segmentación de redes, con fuertes requisitos de ciberseguridad y certificación para poder compartir espacio aéreo con aeronaves tripuladas.

La normativa española, alineada con la OACI, pone especial énfasis en el término RPAS para aquellas plataformas que deben integrarse en espacio aéreo no segregado junto a aviación convencional, lo que condiciona tanto el diseño del dron como la arquitectura de software, las comunicaciones y el sistema operativo que orquesta todo el conjunto.

Detrás de cada sigla y cada dron militar hay una capa invisible de código, sistemas operativos y decisiones tecnológicas que pueden parecer secundarias, pero que en realidad definen la seguridad, el coste, la capacidad de evolución y, en muchos casos, el propio éxito de las misiones que esos drones llevan a cabo.