PALLÁS

La FAO estima que en los últimos 30 años el mundo perdió US$ 3,8 billones en producción agrícola a causa de desastres, un promedio de US$ 123 mil millones por año, equivalente al 5% del PIB agrícola global anual. Solo en América Latina y el Caribe, entre 2008 y 2018, los desastres destruyeron US$ 29 mil millones en producción de cultivos y ganadería. La sequía fue la principal causa, responsable de US$ 13 mil millones en pérdidas solo en esa región durante ese período. Para tener una referencia de escala actual: solo en 2024, solo en Estados Unidos, las pérdidas agrícolas por desastres climáticos superaron los US$ 20,3 mil millones, según la American Farm Bureau Federation.

Lo que estos números ocultan es aún más revelador que lo que muestran: gran parte de esas pérdidas no era inevitable. Era el resultado de decisiones que no se tomaron a tiempo porque la alerta llegó tarde.

Cuando una sequía comienza a destruir el maíz en el Cerrado, cuando una inundación amenaza el arroz en el Valle del Cauca o cuando el estrés térmico empieza a comprometer la caña en el Nordeste brasileño, el ciclo convencional para generar una alerta útil recorre el siguiente camino: captura por el satélite Sentinel, downlink a la estación terrestre, procesamiento en la nube, análisis, generación del dashboard y, finalmente, la decisión del agricultor o gestor público. Ese ciclo tarda entre 6 y 72 horas, dependiendo de la ventana de downlink disponible, de la cola de procesamiento y de la cobertura de nubes, que es máxima exactamente en los momentos de mayor riesgo hídrico.

Los fenómenos climáticos extremos no esperan 72 horas. Se desarrollan en horas. La ventana en que una decisión todavía puede revertir una pérdida de cosecha se cierra antes de que llegue la alerta convencional.

PALLÁS resuelve ese problema de raíz: no acelerando el procesamiento en tierra, sino eliminando la necesidad de hacerlo.

Para dimensionar ese retorno en términos concretos, tomemos el evento de sequía detectado en el Semiárido Nordestino durante las pruebas de PALLÁS: NDVI de 0,050, anomalía de −2,3σ respecto al promedio histórico, déficit hídrico severo con reducción de accesibilidad logística. En ese escenario, el simulador orbital estimó una anticipación de alerta de entre 14 y 18 horas respecto al ciclo convencional de procesamiento terrestre. Para el cultivo de frijol, principal fuente de proteína y renta en la región, la ventana crítica de intervención hídrica en fase de floración es de aproximadamente 24 horas antes de que el daño foliar se vuelva irreversible. Una alerta que llega 14 horas antes del procesamiento convencional puede representar la diferencia entre activar irrigación de emergencia o registrar una pérdida total de la parcela. Con productividades regionales promedio de 800 kg/ha y precio de referencia de R$ 4,20/kg (CONAB, mayo 2026), cada hectárea salvada equivale a R$ 3.360 en ingreso preservado. Para un núcleo de 50 productores con 5 ha cada uno, esa anticipación de 14 horas representa hasta R$ 840.000 en pérdidas potencialmente evitadas, por evento, por alerta.

PALLÁS transforma observaciones de la Tierra en decisiones agrícolas en el momento en que todavía pueden evitar pérdidas. Utiliza datos del ecosistema Copernicus para entrenar modelos de inteligencia artificial capaces de identificar riesgos agrícolas como sequías, inundaciones, estrés térmico y anomalías en el desarrollo de los cultivos. La plataforma integra información de humedad del suelo, índices de vegetación, temperatura superficial, topografía e historial climático para transformar observaciones satelitales en alertas predictivas y recomendaciones prácticas para productores, cooperativas, agroindustrias y gobiernos.

Su principal diferenciador es la combinación de estos modelos con una arquitectura de inteligencia artificial embarcada en satélites, capaz de procesar información directamente en órbita y reducir significativamente la latencia entre la observación y la toma de decisiones. Para cuantificar este beneficio, PALLÁS utiliza el Índice de Criticidad Temporal (ICT), una métrica que mide cuánto tiempo queda para actuar antes de que una pérdida agrícola se vuelva irreversible y cuánto valor aporta la reducción de tiempo obtenida mediante el procesamiento orbital. El resultado es una plataforma que entrega información crítica más rápido, permitiendo actuar mientras aún existe una oportunidad real de proteger la producción, fortalecer la resiliencia agrícola y reducir pérdidas asociadas a eventos climáticos extremos.

La solución: inteligencia que actúa antes de que la ventana se cierre

PALLÁS está organizada en tres capas integradas que cubren todo el ciclo desde la captura del dato satelital hasta la entrega de una recomendación de acción al usuario final, sea un pequeño agricultor en el Corredor Seco Centroamericano, un ingenio azucarero en el interior de São Paulo o un ministerio de agricultura.

1) Motor Copernicus en tiempo casi real

La primera capa consume datos públicos del Copernicus Data Space Ecosystem en múltiples fuentes complementarias, elegidas por cubrir los principales vectores de riesgo agrícola en LAC con la máxima redundancia y confiabilidad.

El Sentinel-1, operando en banda SAR C, permite detectar inundaciones y medir humedad del suelo incluso bajo cobertura total de nubes, condición frecuente exactamente en los momentos de mayor riesgo agrícola, cuando sistemas de lluvia intensa cubren las regiones más vulnerables. El Sentinel-2 L2A provee series temporales de los principales índices de vegetación e hídricos: NDVI, NDWI, EVI y SAVI, calculados por parcela y por región, permitiendo identificar anomalías en el desarrollo vegetal semanas antes de que se conviertan en pérdidas visibles a simple vista. El Sentinel-3, a través de los sensores OLCI y SLSTR, entrega datos de temperatura de superficie terrestre esenciales para identificar estrés térmico en cultivos sensibles como soja, maíz y caña de azúcar. El ERA5, accedido vía Copernicus Climate Data Store, provee la línea base climática histórica de 2000 a 2025 que permite calcular anomalías respecto al comportamiento esperado para cada época del año y cada región. El Copernicus DEM GLO-30 completa la base con datos topográficos de alta resolución utilizados para modelar escorrentía superficial y mapear vulnerabilidad a inundaciones por cuenca hidrográfica.

La integración de estas cinco fuentes en un pipeline unificado es lo que permite a PALLÁS generar una visión coherente y multidimensional del riesgo agrícola: no apenas un índice de vegetación aislado, sino el cruce de humedad, temperatura, topografía e historial climático que otorga al alerta su precisión y su anticipación.

2) Motor de inteligencia orbital

Esta es la capa que define a PALLÁS. Un motor de inteligencia orbital diseñado para reducir la distancia entre la observación de la Tierra y la toma de decisiones agrícolas. Utilizando datos de Sentinel-1 y Sentinel-2, PALLÁS reproduce una arquitectura de procesamiento embarcado basada en los parámetros reales de hardware espacial desarrollados por la startup Epic of Sun y compara su desempeño con los flujos convencionales de procesamiento terrestre.

Para cada evento monitoreado, el sistema calcula cuánto tiempo puede ganarse al generar alertas mediante inteligencia artificial orbital y cómo esa anticipación impacta la capacidad de respuesta de productores, cooperativas y gobiernos. El objetivo no es únicamente detectar riesgos agrícolas, sino entregar la información mientras aún existe tiempo para actuar.

Este beneficio se cuantifica mediante el Índice de Criticidad Temporal (ICT), una métrica que combina indicadores agrícolas obtenidos por Copernicus, como anomalías de vegetación, humedad, inundaciones y estrés térmico, con la ganancia temporal proporcionada por el procesamiento orbital. El resultado es una estimación directa de cuánto tiempo queda para evitar una pérdida de producción y cuánto valor puede preservarse gracias a una alerta más temprana.

El motor analítico central, FAST-CROP (Food Alert by Satellite Temporal-Coverage Risk Optimization Protocol), fue entrenado con datos históricos públicos de Copernicus y validado contra eventos agrícolas documentados en América Latina y el Caribe. Su principal diferencial es cuantificar cuánto valor agrícola genera cada hora recuperada mediante inteligencia artificial embarcada.

El motor analítico central es el algoritmo FAST-CROP (Food Alert by Satellite Temporal-Coverage Risk Optimization Protocol):

ICT = f(ΔNDVI_anomalía, SAR_extensión_inundación, LST_estrés,        
      fenología_cultivo, gap_revisita_orbital,        
      ganancia_procesamiento_orbital)

3) Plataforma de decisión multiescala

Las capas 1 y 2 resuelven el problema técnico: detectar, con anticipación real, lo que está a punto de ocurrirle a un cultivo. La tercera capa resuelve el problema humano: convertir esa anticipación en decisión, en el momento justo, para quien la necesita, en la forma en que puede usarla.

La distinción importa. Anticipar un evento sin lograr entregar la información al tomador de decisión no evita ninguna pérdida. Por eso PALLÁS no proyecta interfaces de visualización de datos: proyecta rutas de decisión. Cada perfil de usuario recibe no un dato, sino una recomendación de acción con ventana temporal explícita: tienes X horas para actuar, y la acción recomendada es esta.

Para el productor rural, esto significa recibir, en el momento en que el ICT indica riesgo inminente, una instrucción objetiva, no un gráfico de NDVI. PALLÁS identifica el canal más confiable disponible para cada región monitoreada y entrega la información por él. El mensaje no dice "su cultivo tiene NDVI por debajo del promedio histórico". Dice "riesgo de pérdida de cosecha en 48 horas: active irrigación de emergencia o notifique a su aseguradora".

Para cooperativas, ingenios y agroindustrias, PALLÁS entrega visibilidad de portafolio: no el estado de una parcela, sino el mapa de exposición al riesgo de toda la operación simultáneamente, ordenado por urgencia y cuantificado en impacto financiero estimado. El gestor ve qué lotes están dentro de la ventana crítica, cuáles tienen margen y dónde concentrar recursos en las próximas horas. Esa visión consolidada es lo que permite tomar decisiones operacionales a escala, no monitorear sino gestionar.

Para gobiernos y ministerios, PALLÁS transforma datos satelitales en lenguaje de política pública: cuánta producción nacional está en riesgo en este momento, cuál es la proyección de impacto en toneladas y en valor de mercado, qué regiones necesitan respuesta inmediata y cuáles tienen margen para planificación. Los reportes se generan automáticamente en formato de briefing institucional, listos para despacho, no para análisis técnico. La API documentada permite que esos datos alimenten directamente los sistemas nacionales ya existentes como CONAB, UPRA y MIDA, sin crear dependencia de una nueva interfaz ni necesidad de reentrenar equipos.

Lo que unifica los tres perfiles no es la tecnología de entrega sino el principio: PALLÁS no informa lo que ocurrió. Anticipa lo que está a punto de ocurrir y dice qué hacer mientras todavía hay tiempo.

PALLÁS no muestra la Tierra, la hace hablar.

Modelo de Negocio

El mercado global de observación de la Tierra fue valorado en más de US$ 12,1 mil millones en 2024 y continúa creciendo impulsado por la demanda de información geoespacial en tiempo casi real para agricultura, infraestructura, defensa y gestión de riesgos. Dentro de este contexto, PALLÁS se posiciona en la intersección entre agricultura y monitoreo satelital, apuntando a un mercado direccionable estimado en US$ 400 millones solo en Brasil y con potencial de expansión a toda América Latina y el Caribe. Nuestra meta inicial es capturar una fracción de este mercado a través de contratos con productores agrícolas, cooperativas, aseguradoras y organismos públicos responsables por la seguridad alimentaria y la gestión de riesgos.

El modelo de negocio se basa en tres fuentes de ingresos complementarias: suscripción por área monitoreada para productores y cooperativas, licencias institucionales para gobiernos y ministerios, y acceso vía API para aseguradoras agrícolas, bancos, tradings y plataformas agroindustriales. La propuesta de valor es directa: transformar horas ganadas mediante procesamiento orbital en pérdidas evitadas, mayor resiliencia productiva y decisiones más rápidas frente a eventos climáticos extremos.

Además del potencial de mercado, el equipo de PALLÁS (en representación de la startup Epic of Sun) ya cuenta con señales concretas de demanda para tecnologías de monitoreo satelital e inteligencia orbital. La empresa posee cartas de intención de uso de su tecnología por parte de dos grandes empresas del sector agroindustrial brasileño, seis municipios interesados en apoyar a los agricultores de sus regiones mediante herramientas de monitoreo y alerta temprana, y la Marina de Brasil para aplicaciones de monitoreo territorial. Estas iniciativas demuestran que existe interés real por soluciones capaces de convertir datos espaciales en decisiones operativas de alto impacto.

En un escenario donde la FAO estima que cada US$ 1 invertido en acción anticipada puede generar hasta US$ 7 en pérdidas evitadas, PALLÁS busca convertir la anticipación en un activo económico medible, permitiendo que productores, cooperativas y gobiernos actúen antes de que una amenaza se transforme en pérdida de producción.

El horizonte: de la simulación a la ejecución orbital

PALLÁS fue diseñado desde el principio para operar en una arquitectura de inteligencia orbital. La versión actual valida el impacto de la reducción de latencia utilizando datos reales de Copernicus y parámetros reales de hardware espacial desarrollados por Epic of Sun, permitiendo cuantificar cómo la anticipación mejora la capacidad de respuesta frente a riesgos agrícolas.

El siguiente paso es llevar esta capacidad directamente al espacio. A medida que los próximos satélites de Epic of Sun entren en operación, el pipeline de inferencia de PALLÁS podrá migrar progresivamente desde la infraestructura terrestre hacia procesamiento embarcado, permitiendo generar alertas más rápidas y reducir aún más la distancia entre la observación y la toma de decisiones.

La financiación de USD 50.000 y las oportunidades de aceleración derivadas de esta competición representan una vía concreta para ejecutar esta transición tecnológica durante los próximos 12 meses. Estos recursos se destinarán a la adaptación y optimización de los modelos de IA de PALLÁS para hardware espacial, la integración del pipeline de inferencia en el computador de a bordo de un satélite de Epic of Sun, las pruebas de validación y rendimiento en entorno operativo, y las actividades de ingeniería necesarias para su despliegue. Nuestro objetivo es contar con los primeros módulos operativos de PALLÁS ejecutándose directamente en un satélite de Epic of Sun antes de mediados de julio 2027, convirtiendo una plataforma de inteligencia agrícola basada en datos satelitales en una solución con capacidad real de procesamiento orbital.

Este enfoque crea una ventaja competitiva difícil de replicar: mientras la mayoría de las plataformas dependen exclusivamente de infraestructura de terceros, PALLÁS evoluciona junto con los propios activos espaciales de Epic of Sun, aumentando progresivamente su capacidad de observación, procesamiento y generación de alertas tempranas para la seguridad alimentaria de América Latina y el Caribe.

Acerca del equipo

El equipo PALLÁS está liderado por Octávio Bogarim y Luiz Castro, ingenieros con experiencia en tecnología espacial, inteligencia artificial y observación de la Tierra. Ambos forman parte de Epic of Sun, una startup brasileña dedicada al desarrollo de satélites e inteligencia artificial a bordo para aplicaciones estratégicas en agricultura, monitoreo ambiental y gestión de riesgos.

En 2025, Epic of Sun lanzó el que se considera el primer satélite brasileño con inteligencia artificial a bordo. Octávio y Luiz participarán activamente en el desarrollo de esta misión, trabajando en sistemas satelitales, procesamiento de datos geoespaciales, inteligencia artificial y aplicaciones de monitoreo remoto.

Además de su experiencia en ingeniería espacial, el equipo ha desarrollado soluciones para monitoreo agrícola, análisis geoespacial y gestión de riesgos utilizando datos satelitales, acumulando conocimientos para programas de innovación y concursos tecnológicos. PALLÁS surge de esta experiencia práctica: no es una propuesta teórica, sino una evolución natural de tecnologías que se están desarrollando para operar en el entorno espacial.

PALLÁS es otro nombre para Atenea, la diosa de la sabiduría estratégica que nace completamente desarrollada y armada, lista para actuar. Eso es precisamente lo que hace esta plataforma: llega antes de que ocurra el desastre.

Actualizaciones: Desarrollado durante el Hackathon

                                               ### Primeira Fase ###

Código ejecutándose utilizando imágenes de Copernicus en una plataforma desarrollada durante el Hackathon.

Identificación de incendios forestales:

Las pruebas del modelo se llevaron a cabo en los incendios forestales que se produjeron en Morpará-BA en septiembre de 2021.

Identificación de inundaciones:

Las pruebas del modelo se llevaron a cabo durante las inundaciones que se produjeron en Porto Alegre, Rio Grande do Sul, en abril de 2024.

                                               ### Segunda Fase ###

Cómo PALLÁS accede a los datos de Copernicus

Toda la inteligencia de PALLÁS se basa en datos públicos del programa Copernicus de la ESA. Esta actualización explica con detalle cómo descargamos, preprocesamos y transformamos estas imágenes en mosaicos listos para la inferencia, incluyendo las decisiones técnicas que garantizan la robustez del proceso para su uso en producción.

¿Por qué Sentinel-2 L2A y no L1C? La primera decisión en el proceso es elegir el nivel de producto adecuado. Sentinel-2 produce dos niveles:

L1C: Reflectancia en la parte superior de la atmósfera (TOA): incluye los efectos de aerosoles, vapor de agua y otras perturbaciones atmosféricas.

L2A: Reflectancia en la superficie de la atmósfera (BOA): ya corregida por el algoritmo Sen2Cor de la ESA, que elimina los efectos atmosféricos.

Los modelos de aprendizaje automático entrenados con L1C tienden a aprender las condiciones atmosféricas del período de entrenamiento, no las características del terreno. Un modelo entrenado con L1C sobre el Cerrado en julio puede tener un rendimiento mucho peor en enero, simplemente porque la atmósfera ha cambiado. L2A elimina este problema: el modelo aprende lo que hay en la superficie, no lo que hay en la atmósfera entre el satélite y el suelo.

Las 5 bandas que utilizamos y por qué.

BANDS_OF_INTEREST = {    
   "B02": 10,   # Azul       490 nm  — útil para distinguir água e vegetação    
   "B03": 10,   # Verde      560 nm  — vigor da vegetação (plantas saudáveis refletem verde) 
   "B04": 10,   # Vermelho   665 nm  — clorofila (plantas sob estresse absorvem menos)       
   "B08": 10,   # NIR        842 nm  — estrutura celular da folha (NDVI usa B08 e B04)    
   "B11": 20,   # SWIR-1    1610 nm  — umidade do solo e detecção de incêndios ativos     
   "SCL": 20,   # Scene Classification Layer — máscara de nuvens
}

La banda SWIR-1 (B11) merece una mención especial: opera a una longitud de onda lo suficientemente larga como para penetrar el humo fino y detectar el calor de incendios activos, además de ser el principal indicador de la humedad del suelo. Es la banda más informativa para la detección de desastres y, por lo tanto, se incluyó a pesar de tener una resolución nativa de 20 m (remuestreada a 10 m en el proceso de desarrollo).

Autenticación y búsqueda de productos

El Ecosistema de Espacios de Datos de Copernicus (CDSE) reemplazó a SciHub en octubre de 2023. El acceso es gratuito previa inscripción en dataspace.copernicus.eu. Esta parte del código (sentinel_downloader.py) gestiona automáticamente la autenticación OAuth2 con renovación del token antes de su vencimiento:

class CDSEAuth:    
    def get_token(self) -> str:        
        """Retorna token válido, renovando se necessário."""        
        if time.time() > self._expires_at - 30:  # margem de 30 s            
             self._refresh()        
        return self._token

La búsqueda utiliza la API OData de CDSE con filtros por cuadro delimitador geográfico, rango de fechas, tipo de producto (S2MSI2A = L2A) y cobertura máxima de nubes:

# Exemplo: buscar cenas de seca no Cerrado com menos de 15% de nuvens
python sentinel_downloader.py \    
   --bbox      "-57.5,-20.5,-56.5,-19.5" \    
   --start     2021-07-01 \    
   --end       2021-09-30 \    
   --class_name seca \    
   --cloud_max  15 \    
   --max_scenes 10 \    
   --output_dir dataset/

La descarga utiliza reintentos con retroceso exponencial (10 s, 20 s, 40 s) para gestionar los fallos de red sin sobrecargar el servidor.

Máscara de nubes mediante SCL

La capa de clasificación de escenas L2A de Sentinel-2 clasifica cada píxel en 12 categorías. El proceso utiliza los valores 0, 3, 8, 9, 10 y 11 (sin datos, sombra, nube media, nube densa, cirros, nieve) para crear la máscara:

cloud_mask = np.isin(scl_arr, [0, 3, 8, 9, 10, 11])
stack[cloud_mask] = np.nan   # pixels inválidos viram NaN

Se descartan los mosaicos con más del 10 % de NaN después del enmascaramiento. Esto garantiza que el modelo nunca se entrene con píxeles de nubes que introducirían patrones espurios, ya que las nubes tienen una apariencia similar en todas las clases de desastres.

De la escena al mosaico

El satélite Sentinel-2 proporciona escenas de aproximadamente 100 × 100 km. El modelo CNN PALLÁS procesa mosaicos de 128 × 128 píxeles (equivalentes a 1,28 × 1,28 km en la superficie). La escena se divide mediante ventanas deslizantes con un paso de 96 píxeles; la superposición de ventanas garantiza que no se pierdan los eventos en los bordes de un mosaico.

tile_buf = np.empty((tile_size, tile_size, C), dtype=np.float32)  # alocado uma única vez

for y in range(0, H - tile_size + 1, stride):    
    for x in range(0, W - tile_size + 1, stride):        
        np.copyto(tile_buf, scene[y:y+tile_size, x:x+tile_size])  # cópia in-place        
        result = engine.infer(tile_buf) 

El único búfer preasignado no es un detalle menor; es una de las prácticas que permite ejecutar el proceso a bordo del satélite, donde las asignaciones dinámicas de memoria durante la inferencia son inaceptables. Hablaremos más sobre esto en la próxima actualización.

Inteligencia artificial integrada: Cómo construimos un modelo que se adapta a la órbita

Esta es la actualización más importante y compleja desde el punto de vista técnico, y la que más diferencia a PALLÁS de cualquier otro proyecto en esta competición. No solo procesamos datos de Copernicus en la Tierra, sino que desarrollamos el sistema para que funcione a bordo del satélite.

En diciembre de 2025, Epic of Sun lanzó el primer satélite brasileño con IA integrada. La idea es utilizar el proyecto desarrollado en este Hackathon en nuestro próximo satélite, que empleará una NVIDIA Jetson como unidad de procesamiento a bordo. El modelo PALLÁS fue diseñado desde el principio para funcionar en este entorno, con todas las restricciones que esto implica: memoria y energía limitadas, latencia determinista obligatoria y resistencia a fallos causados por la radiación cósmica.

Cada decisión de ingeniería que se describe a continuación tiene un impacto directo en la viabilidad orbital del sistema.

O fluxo completo: do treino ao satélite
[Copernicus CDSE]
      ↓ sentinel_downloader.py
      ↓ (Sentinel-2 L2A → tiles .npy)
      ↓
[Máquina com GPU - em terra]
      ↓ train.py
      ↓ (PyTorch → model.pt)
      ↓ jetson_inference.py export
      ↓ (model.pt → model.onnx)
      ↓
[No próprio Jetson - antes do lançamento]
      ↓ jetson_inference.py build --mode int8
      ↓ (model.onnx → model_int8.trt)
      ↓
[Onboard - Jetson em órbita]
      ↓ onboard.py
      ↓ sensor → pré-proc → TRT → NMS → telemetria
      ↓
[Estação terrestre]
      pacotes binários 19 bytes → alertas de desastre

El motor .trt se compila dentro de la propia Jetson antes de su lanzamiento, ya que TensorRT genera código específico para la GPU y la versión del controlador de ese dispositivo. No es portable, y esto es intencional. Significa máxima optimización para ese hardware específico.

Cuantización INT8: 4 veces menos memoria, latencia determinista 

Los modelos PyTorch entrenados en FP32 ocupan 4 bytes por parámetro. En hardware embebido sin GPU dedicada, esto resulta inviable. La cuantización INT8 comprime cada parámetro a 1 byte (una reducción de 4 veces en el tamaño del modelo y el uso de VRAM) manteniendo una pérdida de precisión generalmente inferior al 1 %.

La cuantización INT8 requiere calibración: TensorRT necesita medir los rangos reales de las activaciones del modelo con datos representativos para calcular los factores de escala correctos. Sin calibración, las activaciones fuera del rango [−128, 127] provocan desbordamiento y degradan gravemente la precisión.

# Calibração com dados representativos
python jetson_inference.py build \
    --onnx       model.onnx \
    --engine     model_int8.trt \
    --mode       int8 \
    --calib_data calib_data.npy   # (N, 4, 128, 128) float32 com amostras variadas

Buenas prácticas aplicadas en la calibración: un mínimo de 200 muestras, incluyendo imágenes con nubes parciales, sombras y bordes de escena; muestras de todas las estaciones (la variación radiométrica de Sentinel-2 es estacional); y almacenamiento en caché del resultado para evitar recálculos.

Un detalle crucial: el modelo utiliza ReLU6 en lugar de ReLU estándar en todas las capas de activación.

# ReLU padrão - sem limite superior, problema sério em INT8
torch.nn.ReLU()

# ReLU6 - limita ativações em [0, 6], quantiza com muito mais precisão
torch.nn.ReLU(max_value=6.0)

La función ReLU estándar no tiene límite superior. En INT8, los valores grandes provocan una saturación severa. ReLU6 garantiza un rango estrecho que el cuantificador puede representar con precisión.

Asignación de memoria cero durante la inferencia

En sistemas embebidos en tiempo real, las asignaciones dinámicas de memoria introducen latencia no determinista y fragmentación del montón. Un sistema que responde en 5 ms de media, pero que a veces tarda 50 ms debido a una asignación de memoria inoportuna, resulta inaceptable en un entorno orbital.

Todos los búferes se asignan una sola vez durante la inicialización del motor. Durante la inferencia, el código solo copia datos a los búferes existentes, sin asignar memoria nueva.

# No __init__() - alocado UMA VEZ
self._input_buf = np.empty(self._in["shape"], dtype=np.uint8)

# Em infer() - cópia in-place, zero malloc
np.copyto(self._input_buf[0], quantized)

En Jetson, se aplica el mismo principio con los búferes CUDA fijos: memoria asignada directamente al espacio de direcciones de la GPU, lo que permite la transferencia mediante DMA (sin la intervención de la CPU) con un rendimiento aproximadamente dos veces mayor que el de la memoria paginable normal:

# Alocado no __init__, nunca realocado
host_buf = cuda.pagelocked_empty(shape, dtype=dtype)
gpu_buf  = cuda.mem_alloc(nbytes)

Flujos asíncronos de CUDA: hasta un 30 % menos de latencia efectiva.

Sin flujos, la canalización es secuencial: la CPU permanece inactiva mientras la GPU procesa:

Frame N:  [H2D copy] → [GPU compute] → [D2H copy]   (CPU ociosa nos 3 passos)

Con los flujos asíncronos de CUDA, los fotogramas se superponen:

Frame N:    [H2D]→[compute]→[D2H]
Frame N+1:           [H2D]→[compute]→[D2H]

cuda.memcpy_htod_async(gpu_in, host_in, self.stream)
self.context.execute_async_v3(stream_handle=self.stream.handle)
cuda.memcpy_dtoh_async(host_out, gpu_out, self.stream)
self.stream.synchronize()

Telemetría binaria: 19 bytes por detección

Los enlaces descendentes de satélites en banda S suelen operar a velocidades de 1 a 10 Mbps, con ventanas de contacto de 5 a 10 minutos por órbita. Cada byte que se transmite por el enlace descendente debe estar en la cola correcta en el momento preciso. El formato JSON de una detección típica ocupa aproximadamente 180 bytes. El paquete binario PALLÁS ocupa 19 bytes, 9,5 veces más compacto, sin pérdida de información:

[timestamp f64: 8B][class_idx u8: 1B][confiança×100 u8: 1B]
[alert u8: 1B][lat f32: 4B][lon f32: 4B]
Total: 19 bytes

Para una detección por segundo durante una ventana de contacto de 10 minutos:

• Formato binario: 19 × 600 = 11,4 KB
• Formato JSON: 180 × 600 = 108 KB

El paquete binario se adapta a cualquier enlace descendente (banda S, UHF o LoRa) sin pérdida de información.

*Robustez frente a SEU (Single Event Upset)*

La radiación cósmica puede corromper aleatoriamente bits de memoria en el hardware en órbita. Un píxel corrompido por la radiación puede provocar que la función softmax genere altas probabilidades para cualquier clase, incluso si la imagen es completamente normal. Un sistema que emite alertas de incendio o inundación causadas por radiación cósmica resulta inútil.

La solución consiste en umbrales independientes por clase, calibrados según el coste relativo de cada tipo de error:

CONFIDENCE_THRESHOLDS = {
    "incendio":          0.60,   # mais sensível — não perder eventos
    "derramamento_oleo": 0.70,   # mais específico — mobilizar equipes custa caro
    "normal":            0.50,
}

class_name = name if conf >= threshold else "incerto"

Si el nivel de confianza no alcanza el umbral de la clase, el resultado se clasifica como "incierto" sin emitir ninguna alerta. Los píxeles afectados por la radiación suelen producir distribuciones de probabilidad dispersas, con baja confianza en todas las clases. El umbral filtra precisamente este patrón.

Arquitectura de CNN y resultados de entrenamiento

Arquitectura de la red neuronal y resultados del entrenamiento:

Sentinel-2 L2A (B02/B03/B04/B08/B11 · 10m · 128×128 pixels)
        ↓  quantização INT8 / normalização [0,1]
Stem Conv 3×3 → 8 canais
        ↓
DS-Conv ×2 → 16 canais   (128×128)
        ↓ stride 2
DS-Conv ×3 → 32 canais   (64×64)
        ↓ stride 2
DS-Conv ×2 → 64 canais   (32×32)
        ↓
Global Average Pooling → Dense 64 → Dropout → Dense 6 → softmax

6 clases de descarga: incendio, inundación, deforestación, sequía, derrame de petróleo, normal.

Dos decisiones arquitectónicas son fundamentales para la eficiencia del modelo:

Depthwise Separable Convolution (DS-Conv): una convolución estándar de 3×3 con 32 canales de entrada y 64 de salida requiere 32 × 64 × 9 = 18 432 operaciones por píxel. La versión separable la divide en dos pasos: una convolución en profundidad de 3×3 (32×9 = 288 MAC) y una convolución puntual de 1×1 (32×64 = 2 048 MAC), lo que suma un total de 2 336 MAC: aproximadamente 8 veces menos operaciones con una precisión comparable. Menos operaciones significan menor consumo de energía en órbita.

Global Average Pooling em vez de Flatten + Dense: una red que utiliza aplanamiento antes de la última capa transformaría el mapa de características (32×32×64) en un vector de 65 536 elementos, generando 65 536 × 6 = 393 216 parámetros solo en la última capa. GAP calcula el promedio espacial de cada canal, produciendo un vector de 64 elementos: solo 64 × 6 = 384 parámetros en la capa Dense final. Una reducción de 1024 en la última capa.

Métricas de entrenamiento

El modelo se evaluó en dos conjuntos independientes: validación (utilizado durante el entrenamiento para controlar el sobreajuste) y prueba final (datos que el modelo nunca vio en ninguna etapa).

El modelo se generaliza bien: las métricas de prueba son consistentemente iguales o superiores a las de validación, lo que indica la ausencia de sobreajuste. El valor de recall de 0,9034 en el conjunto de prueba es el resultado más importante para el contexto de PALLÁS, ya que significa que el modelo no detecta más del 10 % de los eventos reales, lo cual es crítico cuando una detección fallida puede representar hectáreas de bosque quemadas o una cosecha destruida sin previo aviso.

El IoU de 0,8063 en la prueba es particularmente relevante para el uso de satélites: mide la superposición geográfica entre el área detectada y el área del evento real. Un IoU superior a 0,80 significa que los polígonos de alerta generados por PALLÁS cubren fielmente la magnitud real del desastre, información directamente útil para la coordinación de la respuesta sobre el terreno.

Vale la pena señalar que la precisión ligeramente menor en la prueba (0,8823 frente a 0,8948 en la validación) es una compensación esperada y aceptable: el modelo se equivoca más por exceso de precaución que por omisión, que es el comportamiento correcto para un sistema de alerta temprana.

Lo que el modelo detecta y otros índices no

Los índices espectrales convencionales (NDVI, NDWI, NBR) son fórmulas matemáticas fijas que se aplican a bandas específicas. Son útiles, pero limitados: el NDVI detecta vegetación sana o estresada, pero no distingue si el estrés se debe a sequía, plagas, incendios recientes o deforestación reciente.

La CNN aprende combinaciones no lineales entre las 5 bandas simultáneamente, capturando patrones de textura espacial que los índices escalares ignoran. Un derrame de petróleo en el mar, por ejemplo, tiene una firma espectral y de textura específica que ningún índice de vegetación capturaría, pero que la CNN, entrenada con ejemplos reales de Sentinel-2, aprende a reconocer.

El Índice de Criticidad Temporal: de la detección a la ventana de acción

Detectar un desastre no es suficiente. La pregunta clave para quienes trabajan sobre el terreno no es "¿qué está pasando?", sino "¿cuánto tiempo tengo para actuar?".

El Índice de Criticidad Temporal (TCI) es la respuesta de PALLÁS a esta pregunta. Transforma la salida de la CNN (una clase y una puntuación de confianza) en información útil: una ventana de tiempo con una urgencia calibrada según el tipo de evento, la condición de detección y la posición orbital.

El índice combina tres variables:

1. Tasa de deterioro por clase: cada tipo de evento tiene un período de tiempo natural antes de la pérdida irreversible, calibrado empíricamente:

DETERIORATION_HOURS = {
    "incendio":          6,    # fogo se expande exponencialmente — janela curta
    "inundacao":         12,   # janela de evacuação e proteção de infraestrutura
    "desmatamento":      72,   # ainda há tempo de acionar fiscalização
    "seca":              168,  # processo gradual — semana para mobilizar irrigação
    "derramamento_oleo": 24,   # dispersão pelo vento e corrente oceânica
    "normal":            None, # sem janela crítica
}

2. Tiempo transcurrido desde la primera detección: PALLÁS registra el historial de detecciones por área geográfica. Una sequía detectada hoy por primera vez tiene un ICT diferente al de una sequía detectada hace 3 días en la misma región.

3. Ventana de paso orbital: si el siguiente paso útil del satélite sobre el área se produce después del final de la ventana de acción, el ICT recibe una penalización por urgencia; esto significa que no habrá nuevas observaciones antes del punto de no retorno.

def calcular_ict(
    classe: str,
    confianca: float,
    horas_desde_deteccao: float,
    next_pass_hours: float,
) -> dict:
    """
    Retorna o ICT normalizado [0, 1] e o nível de alerta (verde/amarelo/vermelho).

    Parâmetros:
        classe                — classe detectada pela CNN
        confianca             — score de confiança [0, 1]
        horas_desde_deteccao  — tempo desde a primeira detecção desta área
        next_pass_hours       — horas até a próxima passagem orbital útil
    """
    if classe in ("normal", "incerto"):
        return {"ict": 0.0, "nivel": "verde", "horas_restantes": None}

    janela = DETERIORATION_HOURS[classe]
    horas_restantes = max(0.0, janela - horas_desde_deteccao)

    # ICT base: 0 = início da janela, 1 = janela esgotada
    ict = 1.0 - (horas_restantes / janela)

    # Penalidade orbital: próxima passagem chega tarde demais para confirmar
    if next_pass_hours > horas_restantes:
        ict = min(1.0, ict + 0.2)

    # Escala pela confiança: detecção incerta reduz urgência do alerta
    ict *= confianca

    # Semáforo
    if ict < 0.35:
        nivel = "verde"    # tempo disponível — monitorar
    elif ict < 0.70:
        nivel = "amarelo"  # atenção — preparar resposta
    else:
        nivel = "vermelho" # ação imediata

    return {
        "ict": round(ict, 3),
        "nivel": nivel,
        "horas_restantes": round(horas_restantes, 1),
    }

Integración de tuberías

Las TIC se calculan inmediatamente después de la inferencia de CNN, tanto a bordo como en tierra:

from ict import calcular_ict

resultado = engine.infer(tile_buf)

ict_info = calcular_ict(
    classe=resultado["classe"],
    confianca=resultado["confianca"],
    horas_desde_deteccao=tile_history.horas_desde_primeira_deteccao(lat, lon),
    next_pass_hours=orbital_schedule.proxima_passagem_horas(lat, lon),
)

El valor ICT se codifica en un byte adicional en el paquete de telemetría binario (ict × 100 como uint8), lo que hace que el paquete tenga 20 bytes:

[timestamp f64: 8B][class u8: 1B][conf×100 u8: 1B][alert u8: 1B][lat f32: 4B][lon f32: 4B][ict×100 u8: 1B]
Total: 20 bytes  (+1 byte em relação ao pacote anterior, sem impacto significativo no downlink)