Tecnología espacial
Proyecto Instrumento Espacial CONTROL CALIDAD (Gp:) I.P. (Gp:) P.Manager (Gp:) Óptica (Gp:) Mecánica (Gp:) Electrónica (Gp:) SW (Gp:) AIV (Gp:) Comité Científico (Gp:) Térmica (Gp:) EGSE (Gp:) Test Ambientales (Gp:) Calibración (Gp:) Transporte etc. (Gp:) Fuentes (Gp:) DPU (Gp:) Adquisición (Gp:) Mecanismos Actuadores (Gp:) Electrónica Proximidad (Gp:) Detectores (Gp:) TC/TM (Gp:) Cables y Conectores
Consorcio Proyecto Espacial Los proyectos espaciales se suelen realizar con consorcios (internacionales) Cada grupo de trabajo tiene su IP y su PM Actividades AIV: Cada paquete de trabajo ha de hacer su integración (si procede), pruebas ambientales y calibraciones (funciones de transferencia) independientemente
Relación con Empresas Control de Calidad (INTA sí puede) Montaje Almacenaje de materiales y componentes Adquisición de materiales y componentes (cuando se puede CPP) TECNOLOGICA
Se puede hacer todo el proyecto en la empresa
Diferencias en Espacio Cualificación de los componentes Análisis y prevención de fallos y estudio de soluciones Radiación (fundamental en lógica) Masa Temperaturas Vacío Evacuación del calor Choque y vibraciones Control de Calidad PAPELES 40-50% del tiempo Costes
Diferencias en Espacio Redundancias Los interfaces entre los distintos subsistemas deben fijarse claramente. Especial mención: Fuentes y TC/TM por ser con el S/C Software: Una documentación férrea Es lo único modificable en vuelo Parcheable Un modo SEGURO Gestión de contingencias Siempre bajo configuración Plazos temporales muy estrictos, muchas veces solo hay una ventana.
Cosas a tener en cuenta Redundancias Sistemas de detección y corrección de errores Ej. EDAC Traza exterior Ej. Watch dog & after watch dog register Puerto de test El hw que no lo rompa el sw El sw que no lo rompa el hw Planetary Protection (los que aterrizan)
Filosofía de Modelos Prototipos funcionales no representativos Modelo de Ingeniería (EM) Modelo Térmico y Estructural (STM) Modelo de Calificación (QM) Modelo de Vuelo (FM o PFM) Modelo de Repuesto (FS)
FPGA Actel Xilinx Atmel Permiten el diseño en paralelo Reducción de masa, volumen y consumo Diseñar pensando en pulsos espurios Muchas de las ventajas de usar FPGA’s en usos comerciales se convierten a menudo en un problema al aplicar estos dispositivos a usos en el espacio. Parece que las FPGA’s se pueden modificar y corregir fácilmente, más tarde en el proceso del desarrollo FABRICANTES:
Flip-flops combinacionales DF1_CC DF1A_CC DF1B_CC DF1C_CC DFC1_CC DFC1A_CC DFC1B_CC DFC1D_CC DFE_CC DFE1B_CC DFE1C_CC DFEA_CC DFM_CC DFMA_CC DFM1B_CC DFM1C_CC DFP1_CC DFP1A_CC DFP1B_CC DFP1D_CC DFPC_CC DFPCA_CC
Vida del SW
Maestro Rafa Todas las fases/documentación del SW deben cumplir con los estándares de ESA/NASA Pensar a largo plazo: en la construcción de los requerimientos del SW hay que pensar en como validarlos Resolver los requerimientos con pocos recursos de computación El diseño del SW ha de realizarse para poder parchearlo en vuelo Intensa/frustrante interacción en la fase de integración con el HW Fase de validación agotadoras y estrictas
Maestro Rafa Mantenimiento de documentación consume muchos recursos Documentación desde el primer paso y en TODOS lo pasos Control de configuración a bajo nivel tanto en SW como en documentación Pocas veces hay soluciones ya existentes. Construcción de herramientas a medida para resolver problemas puntuales Viajes/teleconferencias/reuniones/mails constantes interrumpiendo el trabajo Exámenes periódicos por parte de ESA/NASA
Recomendaciones En la fase preliminar de los proyectos, debe haber una gran interacción entre los diseñadores de SW y HW para optimizar los requisitos para ambos. Prestar mucha atención a las diferencias de prestaciones, e incluso pinout, entre las versiones comerciales y espaciales de los componentes. No se deben reducir las prestaciones de las fuentes de alimentación por reducir masa, al final tienes problemas. El ruido debe filtrarse lo más cerca posible de la fuente donde se genera. Diseñar, sobre todo las FPGA’s, como un paranoico, es la forma de que falle menos.
Más Recomendaciones Debe de haber una gran interacción entre los equipos de trabajo, con modelos intermedios, para comprobar funcionalidades y prestaciones. Como la integración y caracterización se hace al final, aunque se planifica al principio, siempre falta tiempo y no se hace de la forma óptima. Las interfaces entre los distintos equipos deben de fijarse y quedar claramente definidas. No solo lo que hay que hacer si no también lo que NO se debe hacer.
Aunque las FPGA’s son flexibles no son de goma, en cualquier caso se requieren simulaciones exhaustivas
Tendencias en Espacio Eliminación de cables y conectores Bajar consumos Mayor potencia de cálculo embarcado en base a DSP FPGA’s para todo Nanotecnología, mayor integración SOC, (System On Chip) CPU integradas en FPGA Reconfiguración Dispositivos analógicos programables
DSP
¿Por qué DSP? Cada vez queremos obtener más datos Los formatos de los detectores son cada vez más grandes Los anchos de banda son iguales
Conclusión: comprimir más y mejor. Procesado abordo.
Telemetría Rosetta: Directamente a Tierra: entre 10 bps hasta 22 kbps. 12 h al día. Mass Memory de 25 Gbits. Exomars Orbital Relay: 256 kbps unos minutos 2 veces al día Directamente a Tierra: 100 kbps solo comunicaciones de emergencia
Otras soluciones Utilizar core de Leon-2 de ESA compatible con Sparc-V8 (hay una versión de ATMEL) Diseñar o adquirir cores, de funciones DSP necesarias para nuestra aplicación y empotrarlas en una FPGA.
| Página siguiente |