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 anterior | Volver al principio del trabajo | Página siguiente  |