Pablo Samuel García-Zarandieta Martínez
← Volver a proyectos

Airbus data internship: trade-off analytics

Data product for engineering trade-off analysis using A320 HTP/VTP BOMs, Palantir/Skywise pipelines, and a decision-ready dashboard.

2023-02 — 2023-08Data / Analytics InternPublic / Internal-safe

TL;DR

Durante mis prácticas en Airbus trabajé en un caso de data analytics orientado a la toma de decisiones de ingeniería: estimar impacto de cambios (especialmente reducción de peso) a partir de estructuras de producto (BOM) del A320 (componentes del HTP/VTP) filtradas por Manufacturing Serial Number (MSN) o por aplicabilidad/configuración. El resultado fue un dashboard (listo para pilotaje) apoyado por un pipeline (PySpark/SQL) que permitía consultar estructura de producto, contar instancias de estándares y calcular peso total y delta de peso en escenarios “antes/después”.

Decision flow

Role & Scope

Rol: Data / Analytics Intern (internship)
Ubicación: Getafe (Madrid)
Periodo: 02/2023 – 08/2023
Dominio: Ingeniería / Diseño (trade-offs de cambios, campañas de reducción de peso, impacto por aplicabilidad/MSN)
Stack (alto nivel): Palantir (Airbus Skywise) — pipelines tipo “bloques” + PySpark/SQL + dashboards

Profile relevance

  • Primary: Data Analyst (ETL + dashboards orientados a decisiones)
  • Secondary: Systems Engineering (trade-offs y trazabilidad de impacto)

Context

En ingeniería/diseño, para campañas de mejora (p.ej. reducción de peso) o decisiones de mantenimiento/reparación, es clave responder rápido a preguntas como:

  • “Si sustituyo este estándar por otro más ligero, ¿cuántas instancias afecta según la aplicabilidad/MSN?”
  • “¿Qué peso total representa este estándar dentro del HTP/VTP en una configuración concreta?”
  • “¿En qué subassembly aparece y cuántas veces?”

Objetivo del proyecto: construir un producto de datos (pipeline + dashboard) que habilitase trade-off analysis:

  1. Filtrar por MSN o por configuración/aplicabilidad.
  2. Extraer la BOM del HTP/VTP y navegar por niveles.
  3. Contar instancias de un standard part específico.
  4. Calcular peso total y comparativas antes/después ante sustituciones.

Deep dives

Deep dive — Data sources & model (sin detalles sensibles)

  • Los datos provenían de un PLM legacy interno (histórico del A320).
  • Airbus había generado un banco de bases de datos con información extraída/recreada a partir de ese sistema.
  • El proyecto usaba:
    • estructuras de producto físicas (BOM) del HTP/VTP,
    • relaciones padre-hijo para navegar assembly → subassembly → part → standard part,
    • información de aplicabilidad (MSN/configuración).

Enriquecimiento: catálogo de estándares

  • Tabla/catálogo de standard parts para obtener material, peso unitario y metadatos.

Data lineage BOM drill-down

Deep dive — Pipeline + dashboard

Pipeline (transformaciones / joins)

  • Pipelines estilo “bloques” con transformaciones en PySpark/SQL.
  • Filtrado por MSN o por aplicabilidad/configuración.
  • Reconstrucción de la estructura de producto del HTP/VTP.
  • Agregaciones y joins con catálogo de estándares (peso/material).
  • Publicación de datasets listos para el dashboard.

Pipeline blocks

Dashboard (cara a usuario)

  • Selección de MSN o configuración/aplicabilidad.
  • Visualización de BOM con navegación por niveles.
  • Búsqueda de standard parts por código.
  • Cálculo de conteos, peso total y comparativa antes/después.

User flow

Deep dive — Collaboration model

Trabajé en tándem con el responsable/owner del producto (colaboración 50/50 aprox.):

  • Reverse-engineering del modelo de datos legacy.
  • Implementación inicial de pipelines y migración a pipelines “de plataforma”.
  • Diseño del dashboard (filtros, vistas y métricas con foco en utilidad real).
  • Validación de resultados e inconsistencias.
  • Demos internas y handoff.

Collaboration model

Deep dive — Validación y detección de “missing data”

Situation: reconstrucción de la BOM del HTP/VTP desde la base “recreada”.

Task: validar que la estructura coincidía con la referencia legacy.

Action:

  • Extraje la BOM filtrada por un MSN desde la base recreada.
  • Exporté la estructura equivalente desde la herramienta legacy.
  • Crucé ambos CSV con un script y generé un informe de diferencias.
  • Escalé al equipo dueño del DB bank con informe + scripts reproducibles.

Result:

  • BOM total ~1000 ítems.
  • Faltaban ~10–15 instancias, concentradas en un tipo de estándar.
  • Riesgo real de sesgo en conteos y peso total.

Validation loop

Outcomes & Impact

  • Dashboard + pipeline implementados, testeados y listos para pilotaje.
  • Demos internas y presentación al departamento.
  • Mi etapa terminó antes de la fase de uso sostenido por usuarios finales; el entregable quedó transferido al owner.

Delivery timeline

Learnings

  • Data analytics aplicado a ingeniería: impacto de cambios, conteos por aplicabilidad y cálculo de peso.
  • ETL/pipelines + PySpark/SQL: joins, filtros, agregaciones y datasets listos para consumo.
  • Data quality & validation: comparación contra fuente legacy, repro cases, informes claros.
  • Data product thinking: construir algo usable (dashboard) con foco en el usuario y la decisión.
  • Colaboración con owner/mentor: iteración rápida + revisión/estandarización para entregar con calidad.

Media / Evidence

  • Diagramas: decision flow, data lineage, BOM drill-down, pipeline, user flow, validation loop.
  • Links de contexto:
    • https://spark.apache.org/docs/latest/api/python/
    • https://en.wikipedia.org/wiki/Bill_of_materials
    • https://www.palantir.com/platforms/foundry/