Una tribuna de opinión publicada por Eurasian Times y firmada por Vijainder K Thakur reaviva en India la controversia sobre el acceso al software, la dependencia del fabricante y el verdadero alcance de la transferencia tecnológica en el programa Rafale
Redacción
El diario Eurasian Times publicaba hace sólo unos días una pieza de opinión firmada por Vijainder K Thakur, en la que se cuestiona la conveniencia de que India siga adelante con futuras adquisiciones del Rafale si Francia no garantiza un acceso suficiente al software de misión y a las interfaces necesarias para integrar sistemas propios.
La tesis central del artículo, presentado expresamente como opinión personal del autor, parte de una supuesta negativa francesa a entregar a India el código fuente de elementos sensibles del avión, entre ellos el radar Thales RBE2 AESA, la Unidad Modular de Procesamiento de Datos (MDPU) y el sistema de guerra electrónica SPECTRA. A partir de ahí, Thakur sostiene que el verdadero problema no reside únicamente en la compra de la plataforma, sino en la dependencia técnica e industrial que genera el control del software por parte del fabricante.
Vijainder K Thakur es piloto retirado de Jaguar de la Fuerza Aérea India, quien también es arquitecto de software, y buena parte de su argumento se apoya precisamente en la importancia del software dentro de un avión de combate moderno y en las consecuencias operativas de no controlar su evolución.
Lea aquí la columna del Eurasian Times
El núcleo de la queja: pagar el avión completo sin controlar una parte decisiva
En su artículo, Thakur afirma que entre el 30% y el 40% del coste total de un caza moderno como el Rafale puede atribuirse al desarrollo e integración del software. Desde esa premisa, concluye que si el comprador no recibe el código fuente o un acceso suficiente a las capas necesarias para modificar el sistema, en realidad paga el 100% de la aeronave pero sólo controla una parte limitada de sus capacidades.
Rafale. Dassault
Se trata, conviene insistir, de una valoración del articulista, no de una posición oficial francesa ni de una confirmación documental india aportada en la pieza. Pero sí puede decirse que esa formulación resume bien el tono de la polémica, ya que la discusión no gira únicamente en torno al precio del avión o a sus prestaciones, sino al grado real de soberanía de uso, adaptación e integración que conserva el país comprador una vez firmado el contrato.
Como puede observarse, se trata de un debate amplio y fuertemente generalizado en casi cualquier parte del mundo; en especial en Europa, donde, hablando del F-35 y su limitado acceso al software dirige una polémica continental desde hace año.
Más que una cuestión de propiedad intelectual
El texto del Eurasian Times pone el acento en un aspecto que suele quedar fuera del debate público sobre los cazas actuales, pero que lo centra en los análisis especializados: el software no es un complemento, sino una parte central de la capacidad de combate. Según explica Thakur, las distintas capas del sistema informático gobiernan desde la interacción con sensores, buses de datos y actuadores hasta funciones de misión como la fusión de sensores, el seguimiento de blancos, la gestión del armamento, las leyes de control de vuelo o la respuesta de los sistemas de guerra electrónica.
A juicio del autor, esa arquitectura explica por qué un operador puede disponer del avión físicamente y, sin embargo, seguir dependiendo del fabricante original para introducir cambios relevantes. Ahí es donde ubica el elemento más controvertido del caso Rafale: la capacidad de India para integrar armas nacionales, adaptar nuevas cargas de misión o responder a necesidades futuras sin quedar atada a la voluntad del OEM.
Dependencia del fabricante y límites a la integración
Otro de los argumentos de Thakur es que un cliente extranjero necesita acudir de forma continuada al fabricante para introducir modificaciones ligadas a la evolución de doctrinas, amenazas y sistemas de armas. En su planteamiento, esa dependencia puede traducirse no sólo en costes añadidos, sino también en restricciones operativas si el proveedor no autoriza determinadas integraciones.
Como ejemplo, el articulista menciona la posibilidad de que Dassault pudiera bloquear la integración de armamento de terceros, citando específicamente el misil ruso R-37M. Ese punto vuelve a formar parte de su razonamiento, no de una evidencia aportada por el texto sobre una decisión concreta ya adoptada. Aun así, ilustra la preocupación de fondo: en programas de alta complejidad, la discusión sobre transferencia tecnológica no se limita a la fabricación local o al mantenimiento, sino que alcanza el control efectivo de la evolución del sistema.
No todo pasa por entregar el código completo
Según su explicación, ningún fabricante entregará previsiblemente el código fuente completo de un caza moderno, dada la complejidad del software, su carácter crítico y el peso de las capas de bajo y medio nivel, que conectan directamente con sensores, procesadores, almacenamiento, sistemas operativos en tiempo real y librerías certificadas.
Por ello, el autor distingue entre una transferencia íntegra del código y el acceso a través de interfaces de programación o capas de abstracción que permitan desarrollar nuevas funciones sin exponer el núcleo completo del sistema. En ese punto, la polémica se desplaza del “todo o nada” a una cuestión más concreta: qué grado de acceso necesita realmente India para no quedar limitada en el futuro.
Ese es, probablemente, el apartado más interesante de la pieza, porque desplaza el debate desde la consigna política a un problema técnico muy concreto. Para Thakur, una interfaz inicialmente suficiente puede quedarse corta con el paso del tiempo si la Fuerza Aérea India quiere integrar nuevos sensores, armamento de desarrollo nacional, drones lanzados desde el propio caza o incluso capacidades vinculadas a futuros aviones de combate no tripulados colaborativos.
Riesgos de limitaciones no visibles
El artículo añade otra controversia al advertir que el acceso sólo mediante interfaz puede ocultar limitaciones accidentales o intencionadas en el código subyacente, desconocidas para el operador. Según el autor, esas restricciones podrían no detectarse hasta que aparece una necesidad operativa específica o una combinación concreta de empleo.
Para ilustrarlo, Thakur recuerda un episodio relacionado con las bombas perforantes Durandal adquiridas para los Jaguar de la Fuerza Aérea India. Según relata, tras años almacenadas como reserva, se descubrió durante una demostración prevista en Pokharan que los aparatos indios no podían lanzarlas por un problema de software, que posteriormente se resolvió mediante un ajuste. El ejemplo sirve al autor para reforzar su tesis de que la autonomía de software no es una cuestión teórica, sino un factor con consecuencias directas sobre el empleo real del sistema.
Una crítica que va más allá del Rafale
La conclusión del texto del Eurasian Times es abiertamente dura. Thakur sostiene que India no debería comprar más Rafale si Francia no se compromete a facilitar el acceso que la Fuerza Aérea India necesite a las partes relevantes del software, y añade que cualquier acceso adicional debería estar previsto desde el inicio a un coste simbólico o previamente pactado. En caso contrario, plantea incluso que debería entregarse el código fuente.
Esa posición, formulada en términos tajantes, se hace eco de un debate más amplio, que no afecta sólo al programa Rafale, sino, de modo general, a un cuestionamiento amplio: qué recibe realmente un país cuando compra un sistema de armas de última generación y qué margen conserva para adaptarlo sin permiso del fabricante.
La discusión sobre la transferencia tecnológica en programas de combate hace tiempo que no se limita a la producción bajo licencia, al montaje local o al reparto industrial. En plataformas cada vez más definidas por su arquitectura digital, el debate se traslada al terreno del software, las interfaces, la integración de armamento y la libertad de evolución futura.
Redacción
defensayseguridad.es
