la fuente: https://www.f-16.net/forum/viewtopic.ph ... 0&start=45
Está traducido a machete online, y revisado muy rápidamente. El que necesite saber algo en inglés en concreto que vaya a la fuente original o escuche directamente el video.
- Así es, lo que diré es que es el futuro, es a donde tenemos que ir, pero también les digo que estamos batallando un poco con algunos de los procesos, el equipo para lograrlo y, honestamente, un poco. un poco de la cultura, pero nos adentraremos en algunas de esas cosas. Entonces, lo que quiero que piensen para todos es, aquí tengo un iphone, está bien, hay tres tipos de software en este teléfono, el primero es como si en tu teléfono, la cámara o el giroscopio dentro del teléfono tiene el firmware que dice lo que el sensor tiene hacer. La otra parte de software es el sistema operativo iOS cuando enciendes tu teléfono, administra la batería, tu wi-fi, que es lo que se llama programa de vuelo operativo de la aeronave y luego el último software son las aplicaciones que van dentro del sistema operativo iOS y, por lo tanto, esas aplicaciones son lo que se conocen como misión de datos. Entonces, los datos de la misión son nuestro grupo de guerra electrónica, el firmware es la IP del proveedor, por lo que no vemos parte del firmware de ese tipo de software, así que de lo que estamos hablando cuando decimos desarrollo de software ágil para aeronaves, estamos hablando del programa de vuelo operativo que es el iOS para el teléfono. Tan ágil es un marco y para simplificarlo a algo que pueda entender, piense en ello como un bucle OODA más rápido. Entonces, el desarrollo de software heredado es un ciclo lento realmente grande, el ágil es más rápido. Así que piénselo como correr alrededor de una pista y así no es más rápido porque la persona que corre alrededor de la pista está acelerando, es más rápido porque la pista es más corta y por lo tanto no tiene que correr un cuarto de milla, solo tiene que correr un octavo de milla. Entonces, debido a que es un ciclo más corto, responde mejor a las necesidades cambiantes, por lo que cuando tenemos requisitos emergentes, podemos integrarlos mucho más fácilmente y luego, debido a que está haciendo un desarrollo de software rápido, en teoría tiene menos cambios grandes y porque tiene menos cambios grandes tendrá problemas menos importantes, así que ese es el tipo de concepto general de lo que estamos tratando de lograr.
Ahora, para contarte la historia del F 35 c2d2, usaré un ejemplo del F-15, solo para que puedas ver la diferencia entre el avión legacy y el tipo de adónde todos intentan ir. Entonces, la suite del F-15 9.0 se está enviando al CAF en este momento y eso es hardware y software. Nosotros en el ala 53, en realidad estamos terminando la suite 9.1, que es 95% de software y una pequeña actualización de hardware al chip de radar que desbloquea algunas capacidades nuevas. Pero al final estamos en la decimocuarta revisión de ese software de prueba en el transcurso de 18 meses, y tenemos que hacerlo para hacerlo bien honestamente, y con eso quiero decir que tiene la estabilidad, tiene un rendimiento, y tiene la interfaz de vehículo piloto -pvi-, por lo que cuando presiono los botones, sé lo que va a pasar y es intuitivo. Ninguna de estas cosas viene con un gran manual de instrucciones y no debería necesitar uno, como su teléfono inteligente, debería ser muy intuitivo. Entonces, aproximadamente un año antes de ese ciclo de 18 meses, comenzamos el grupo de trabajo de requisitos y luego los mecanismos de contratación para establecer cuánto tiempo, cuánto esfuerzo y qué costo va a tomar hacer esto. Entonces, para cuando el software llega al caza, ese bucle OODA es de tres años desde el concepto hasta el combate.
En cuanto al software, es relativamente rígido y, en ese plazo de tres años, si surge algo más, tenemos cierta flexibilidad para insertar nuevas capacidades, pero no realmente, así que no es la forma de ganar, y no creo que tenga que explicarlo más. Es por eso que todas las plataformas están buscando salirse de eso, incluyendo el f-15, ellos tienen una cosa llamada CDNI. Para el F-35 tenemos el C2D2, que es el más avanzado de todas las plataformas, por eso nos gusta hablar de él por varias razones. Así que es el desarrollo de software. Es muy importante que la gente lo entienda. El c2d2 toma ese enorme ciclo del que acabamos de hablar y lo divide en cuatro trimestres, piensa como un partido de fútbol americano, tengo cuatro trimestres y cada trimestre es de seis semanas. Así que tengo el primer trimestre de seis semanas, el segundo trimestre, el tercer trimestre, el cuarto trimestre y después del cuarto trimestre el juego termina y se remite al CAF. Así que lo que se traduce es que tenemos cadencias de prueba de seis semanas para las actualizaciones de la cinta y luego cada seis meses la CAF recibe una actualización de su avión. Así es como funciona. La primera pregunta obvia es por qué no se puede ir más rápido y obtener una actualización 10 veces al mes en mi iphone. ¿Por qué no puedes ir más rápido? Así que te diré, hay un poco de historia aquí. Así que pasamos al c2d2 tercer trimestre para el f35 a mediados de 2019. Se probó el concepto y todo el mundo decidió que sí, esto es lo que tenemos que hacer. Sin embargo, cuando entramos en el 4º trimestre terminamos encontrando algunas fallas en el proceso y realmente se redujo a una mentalidad. Así que históricamente, recuerda que te dije antes que no tenemos un grupo de apoyo a la misión. Tampoco tenemos un grupo de mantenimiento, así que dependemos de los mantenedores de las unidades anfitrionas, que son las bases de entrenamiento y las bases operativas, y la razón por la que hacemos esto en el pasado es porque nos gusta tener un mantenimiento representativo de las operaciones, de modo que cuando enviamos algo a la flota queremos asegurarnos de que los mantenedores de la flota pueden hacerlo de la misma manera, en lugar de que esto no sea ejecutable para los aviadores en la línea de vuelo, pero el contratista con 30 años de experiencia puede hacerlo bien. Así que no queremos esa desconexión, pero lo que no se ha podido hacer es el mantenimiento para apoyar las pruebas operativas, y por eso parece un matiz. Pero es una gran diferencia, y como hemos utilizado a los encargados de la formación y de las operaciones, no tienen la misma autoridad que nuestro mantenimiento dedicado a las pruebas de desarrollo, donde tienen lo que llamamos órdenes técnicas de línea roja y pueden cargar cosas. Así que necesitamos nuevas aprobaciones, y lo que acaba ocurriendo es que, de ese ciclo de seis semanas, cada seis semanas perderíamos dos semanas sólo haciendo el papeleo para obtener la aprobación para poner el software en el avión para que puedan hacer las pruebas.
Así que en realidad terminamos con cuatro semanas de pruebas, cuatro semanas de pruebas, cuatro semanas de pruebas, cuatro semanas de pruebas. Todas estas políticas son autoimpuestas, sólo me gustaría decir que no es una cosa de contratistas, es una burocracia autoimpuesta por el servicio. Pero esa falta de tiempo para las pruebas condujo a algunas capturas serias en la hora 11. Al final de ese cuarto trimestre del que os hablé, una de ellas que puedo compartir, es que estábamos a punto de poner en marcha una cinta para el f-35 pero el radar literalmente no funcionaba y llegó hasta el final de las pruebas hasta que nos dimos cuenta de que el radar no funcionaba. Estaba transmitiendo, pero en realidad no estaba recibiendo y procesando las señales correctamente debido a un fallo de software. Así que lo que sucedió fue que en realidad no pusimos la cinta cuatro, en su lugar, fuimos a la prórroga. Así que ahora estamos en el fútbol sobre el tiempo más allá del cuarto trimestre, hicimos una cinta de emergencia para arreglar algunos de esos problemas y luego la pusimos en marcha y ese es el software que están en los f-35 de la fuerza aérea hoy. Luego pasamos a la cinta cinco, para abreviar, la cinta cinco tampoco salió al campo y eso se debió a algunos de los mismos problemas de los que hablamos con las autoridades de carga de software y realmente se redujo a problemas de estabilidad con el ofp. Así que incluso si tuviéramos un ofp más estable, incluso si tuviéramos menos tiempo para probar, podría no haber sido un problema, al final del día la confluencia de dos de esos factores juntos significó que no se puso en marcha la cinta cinco. Así que ahora estamos en la sexta cinta, voy a decir que tenemos las autoridades para cargar el software, nos tomó mucho más tiempo de lo que me gustaría admitir para obtener una firma en un pedazo de papel para hacerlo, pero lo tenemos, por lo que p6, que es lo que llamamos cinta de producción seis, va a campo a la CAF el próximo mes. Ahora bien, la belleza de esto es que, debido a la construcción c2d2, todas las capacidades que hicimos en la cinta cinco, que no se desplegaron, las hemos incluido en la cinta seis y, por lo tanto, el mes que viene, cuando empecemos a cargar los f35 operativos, van a tener la cinta 5 y la cinta 6 juntas. Así que va a ser un gran salto en la capacidad, por lo que los f35 que van a ver este verano o no los f35 que vieron el verano pasado. Muy bien, así que dos grandes cosas para hablar, la primera es una coartada que he destacado un poco, por lo que este es un ciclo de software y no incluye el hardware. El hardware cambia esto, ahora mismo, en el bloque cuatro del F-35 es al menos software y así es fácil. F35 siguiente, cuando llegamos a mediados de los años 20, cuando esto se cierra probablemente vamos a tener que hacer algo diferente. El F22 lo está viendo ahora mismo con el racer, que es su software ágil, hacen ocho semanas y ocho meses es su cadencia, pero tienen el hardware incorporado y por eso se están encontrando con un montón de problemas. Ahora el asterisco para el software ágil, para esto, no es exactamente ágil y voy a volver al teléfono.
Así que cuando tu teléfono tiene un problema, envía un informe al desarrollador. Tanto si se trata de la aplicación como del software, ellos hacen un seguimiento de la salud de la flota para su iOS, y así es como saben lo que hay que arreglar para las actualizaciones y luego las impulsan. En realidad, no tenemos información sobre el código que desplegamos en la flota operativa y, por tanto, cuando tenemos un escape de prueba, así es como lo llamamos, no tenemos el bucle en el bucle OODA para saber que es un escape y recoger esos datos casi en tiempo real. Es un proceso muy manual. En realidad no tenemos más aviones, no hay dinero para comprar más aviones para hacer más pruebas de regresión, que es cuando vamos a buscar errores, y no tenemos más dinero para la mano de obra para operar y mantenerlos. Así que lo que hemos ideado es lo que llamamos datos de vuelo crowdsource. Puede que hayas oído hablar un poco de ello, es básicamente tres cambios de juego en uno y permíteme explicarlo un poco. La primera es que el CAF se convierte en un sensor, por lo que estamos convirtiendo todas las aeronaves operativas en sensores y ahora podemos supervisar todo nuestro software desplegado en ellas y responder a los problemas que surjan. Así que podemos ver al instante los datos, podemos ver lo que está mal y podemos impulsar una solución y pasarla a la siguiente actualizcion c2d2. El segundo cambio de juego es que abre la puerta a lo que llamamos reconocimiento de operaciones, por lo que podemos hacer la captura de señales y el análisis para la reprogramación rápida, que es realmente en lo que nuestro grupo de guerra electrónica está interesado, y luego la última cosa es, mediante el uso de datos de vuelo de la fuente de la multitud, es el análisis de grandes datos. Voy a dar un par de ejemplos sólo para ampliar la mente de la gente un poco, de lo que estamos hablando. No voy a utilizar un ejemplo de prueba, voy a utilizar un ejemplo de entrenamiento, así que si usted recuerda que hace unos años tuvimos un F-22 en Fallon que había girado demasiado pronto en el despegue y se deslizó por la pista. Durante la investigación del accidente se observó una tendencia, una tendencia cultural, en la comunidad en la que, debido a que el f22 tenía tanta potencia, los pilotos giraban cada vez más temprano desviándose de algunos de los procedimientos de orden técnico. Eso no se detectó hasta después de que ocurriera este percance y volvieron a mirar las cintas de la gente despegando y aterrizando. Así que con este tipo de mecanismo, se puede pulsar un botón y analizar los datos de despegue y aterrizaje de todos los días. Puedes analizar las tendencias, puedes puntuarlas y así pensar en acelerar el entrenamiento de los pilotos acelerando el desarrollo de las tácticas. Sabes que puedo decirte que podrías desarrollar los algoritmos para evaluar los giros de los frenos de la gente en bfm, así que puedes automatizar muchas de estas cosas que ahora mismo consumen mucho tiempo y son manuales. Así que eso es una especie de ejemplo de entrenamiento, pero te digo que el CAF es un sensor, por lo que los datos de vuelo de crowdsource, no es un punto de poder, podemos hacerlo, lo estamos haciendo ahora, lo hemos estado haciendo colectivamente durante unos cuatro años y tenemos cerca de cuatro mil horas registradas en los f35 en nuestra ala con él. Así que es el cambio de juego que la fuerza aérea necesita, todavía no es un programa de registro, estamos trabajando en eso y estamos luchando en este momento para obtener los requisitos escritos y el tipo de presupuesto cerrado para eso, así que estamos pedaleando duro en eso, pero eso es una especie de desarrollo de software ágil, lo que necesita, para cerrar realmente ese bucle para que sea eficaz.
(...)