Programa interno de plataforma de hardware
Una sola fuente de verdad para la planeación de hardware entre EE, ME y FW
Un modelo YAML ahora impulsa vistas de arquitectura, resúmenes y validaciones de planeación para EE/ME/FW
El Reto
Resumen Ejecutivo
Este proyecto aborda un cuello de botella común en desarrollo de hardware: las decisiones de planeación se tomaban desde artefactos desconectados entre EE, ME y FW. La solución fue construir HardwareGraph (hwgraph), un sistema guiado por manifest donde un único modelo YAML impulsa diagramas de arquitectura, resúmenes de costo/energía, validaciones y flujos de revisión.
El resultado es una vista compartida, temprana y continuamente actualizada del sistema completo, mejorando la calidad de planeación, reduciendo ambiguedad entre equipos y detectando riesgos antes de que se conviertan en problemas de integración.
1) Contexto de negocio
En programas de hardware multidisciplinarios, cada área desarrolla naturalmente sus propias herramientas y vistas:
- EE trabaja con esquemas y mapas de interfaz
- ME trabaja con restricciones de envolvente/ensamble y estructura mecánica
- FW trabaja con estado de drivers, mapeo de pines y topología de buses
Esto es eficiente a nivel local, pero globalmente introduce fricción:
- Se duplican datos en distintos formatos
- Los cambios no se propagan de forma consistente
- Las juntas de planeación reconcilian supuestos distintos en lugar de evaluar tradeoffs
Para este proyecto, liderazgo necesitaba responder preguntas de planeación antes:
- ¿Vamos en línea con el costo objetivo de BOM?
- ¿El consumo energético está alineado con metas de vida de batería?
- ¿Las dependencias de FW y el estado de drivers son visibles antes de implementar?
- ¿Las dependencias EE/ME/FW son suficientemente claras para secuenciación y resourcing?
El requerimiento era claro: una sola fuente de verdad en la que todas las áreas pudieran confiar durante planeación, no solo en integración tardía.
2) Problema
Antes de hwgraph, la planeación sufría cuatro problemas base:
- Entendimiento fragmentado del sistema: no existía un artefacto único que representara el sistema completo entre EE/ME/FW.
- Visibilidad tardía de restricciones: costo/potencia/estado de drivers se revisaban tarde o manualmente.
- Alto costo de coordinación: los design reviews gastaban tiempo alineando hechos básicos.
- Riesgos detectados tarde: conflictos de interfaces, referencias a componentes eliminados y sobrecostos aparecían en ejecución, no en planeación.
Esto generaba retrabajo evitable y menor confianza en el roadmap.
Nuestro Enfoque
3) Objetivos y criterios de éxito
El proyecto buscó construir un sistema de planeación con estos resultados:
- Un modelo canónico editable y revisable por todas las disciplinas
- Una representación visual para entendimiento cross-team rápido
- Un resumen cuantitativo para análisis temprano de tradeoffs (costo, potencia, batería)
- Validaciones automáticas para detectar riesgos de planeación en CI
- Una experiencia de revisión usable por stakeholders que no editan draw.io
El éxito se definió como pasar de "múltiples verdades parciales" a "una sola imagen integrada del sistema", disponible de forma continua durante el desarrollo.
4) Vista general de la solución
La solución se implementó como hwgraph, un flujo CLI + viewer con una entrada canónica:
manifest.yaml como fuente de verdad para proyecto, componentes, topología, energía y layout.
Desde ese manifest, el sistema genera y mantiene:
- Arquitectura Draw.io multi-tab
- Pestañas EE, ME, FW y Summary
- Sincronización bidireccional
- Ediciones de layout sincronizables de vuelta a YAML
- Pipeline de validación
- Chequeos de restricciones y consistencia
- App de revisión en modo lectura
- Búsqueda, inspección de metadatos y navegación por subsistema/componente
Esta arquitectura equilibra dos necesidades:
- Colaboración visual amigable para humanos
- Datos de ingeniería versionados y verificables por máquina
5) Capacidades implementadas
A) Generación de diagramas guiada por modelo (generate)
Desde un solo manifest, la herramienta crea un .drawio con cuatro perspectivas:
- Tab EE: componentes coloreados por subsistema y estilos de conexión por bus
- Tab ME: contexto de envolvente mecánica (incluyendo relaciones entre gabinetes)
- Tab FW: contexto de integración de software (drivers, compatibilidad DTS, metadatos de pines)
- Tab Summary: métricas de planeación en formato dashboard
Esto entrega vistas por dominio y por programa sin duplicar captura de datos.
La Solución
B) Sincronización diagrama-modelo (sync-back)
Cuando los equipos ajustan layout en draw.io, esos cambios posicionales se escriben de regreso a layout.ee/me/fw dentro del manifest.
Esto mantiene alineados el diagrama y el modelo canónico en el tiempo, reduciendo deriva.
C) Validación de planeación (validate)
Chequeos listos para CI detectan riesgos como:
- Conflictos de direcciones I2C
- Conflictos de pines
- Sobrecosto vs objetivo
- Sobrecarga de reguladores
- Incumplimiento de meta de vida de batería
- Referencias en conexiones a componentes eliminados
Esto convierte supuestos arquitectónicos en compuertas explícitas de calidad.
D) Visualización orientada a revisión (serve)
Un viewer local en React ofrece una superficie de design review con:
- Navegación por tabs EE/ME/FW/Summary
- Inspector de componentes con metadatos ricos
- Búsqueda por ID/nombre/parte/subsistema
- Integración Draw.io para paridad exacta con el diagrama
Esto hace el modelo consumible para stakeholders más allá de quienes lo autoran.
6) Por qué funcionó la "fuente única de verdad"
El principio clave fue: escribir una vez, reutilizar en todas partes.
- Los hechos del sistema viven en un solo lugar (
manifest.yaml) - Cada salida (diagrama, resumen, experiencia de revisión, validación en CI) deriva del mismo modelo
- Las conversaciones cross-team se anclan a datos compartidos, no a snapshots divergentes
Esto redujo el "impuesto de traducción" entre EE/ME/FW y reemplazó discusiones de estatus por toma de decisiones.
Los Resultados
7) Resultados y valor entregado
Alineación entre departamentos
Todas las áreas de ingeniería pueden referenciar la misma arquitectura, componentes y metadatos de estado durante planeación. Esto mejora la calidad de reuniones y la claridad de dependencias.
Tradeoffs más tempranos
La capa Summary expone implicaciones de costo y energía lo suficientemente temprano para influir dirección de diseño, en lugar de convertirse en reportes post-hoc.
Menos retrabajo
Las validaciones automáticas detectan problemas estructurales antes de que se propaguen, evitando correcciones tardías costosas.
Mayor confianza de ejecución
Como los supuestos del roadmap se validan contra un modelo compartido, los artefactos de planeación quedan más cerca de la realidad de implementación.
8) Ejemplo representativo: proyecto BLE indicator
En el ejemplo BLE indicator incluido en el repositorio, el sistema demuestra visibilidad de planeación end-to-end:
- La arquitectura completa multi-tab se genera desde el manifest
- El tab Summary calcula métricas de costo y potencia/batería
- La validación destaca condiciones de riesgo contra objetivos (por ejemplo, tradeoffs de duty-cycle en batería)
- El modo review permite inspeccionar metadatos y dependencias rápidamente
Esto demuestra cómo los equipos pueden pasar de documentación estática a un modelo vivo que soporta decisiones reales de planeación.
9) Decisiones técnicas que habilitaron adopción
- YAML como fuente canónica: legible por humanos, versionable y amigable para merges
- Interoperabilidad con Draw.io: respeta hábitos existentes y minimiza disrupción
- Operación CLI-first: fácil de automatizar en flujo local y CI
- Modo reviewer de solo lectura: revisión accesible preservando integridad del modelo
- Entrega por fases: generación/sync primero, luego summary/validation, luego UI de review
Estas decisiones hicieron la solución práctica, no solo técnicamente correcta.
10) Lecciones aprendidas
- Una fuente de verdad solo funciona si sirve a todas las disciplinas, no solo a una.
- La visualización por sí sola no basta; debe combinarse con validación por máquina.
- La calidad de planeación mejora de forma drástica cuando costo y energía se integran a artefactos de arquitectura.
- La adopción es más fuerte cuando la herramienta nueva amplifica flujos conocidos en lugar de reemplazarlos.
11) Conclusión
Este proyecto transformó la planeación de un proceso fragmentado y cargado de documentos a un flujo de ingeniería guiado por modelo.
Al establecer una sola fuente de verdad entre EE, ME y FW, y conectarla con diagramas, métricas y validaciones, el equipo ganó visibilidad más temprana y más clara del diseño completo, junto con sus implicaciones de costo y energía.
El efecto neto es mejor toma de decisiones en planeación, menos sorpresas en etapas tardías y mayor alineación entre departamentos de ingeniería.
Reemplazamos discusiones por documentos contradictorios con decisiones más rápidas basadas en un modelo compartido.
Detalles del Proyecto
- Cliente
- Programa interno de plataforma de hardware
- Industria
- Sistemas embebidos e I+D de hardware
- Servicio
- Transformación Digital