Neykos PMS v2

Propuesta de Nueva Arquitectura

Enero 2026

Agenda

  1. Contexto y Visión — Por qué un sistema nuevo
  2. Stack Tecnológico — Tecnologías seleccionadas
  3. Arquitectura General — Vista de alto nivel
  4. Modelado de Equipos — Flexibilidad en topología
  5. Lógica de Negocio — OEE, Paradas, Alertas
  6. Multi-tenancy — Un sistema, N clientes
  7. Plan de Implementación — Roadmap

¿Por qué un Sistema Nuevo?

Limitaciones actuales

  • 4 instancias separadas — infraestructura duplicada
  • Código acoplado — difícil de mantener y escalar
  • Modelo rígido — no soporta topologías complejas
  • Sin AI nativo — clasificación manual de paradas

Visión v2

  • Multi-tenant desde el día 1
  • AI integrado en el core
  • Topología flexible (grafo, no árbol)
  • 75% reducción en costos de infra

Principios de Diseño

Principio Descripción
SOLID + DRY Código mantenible, sin duplicación
Separación de concerns Servicios especializados y desacoplados
Event-driven Comunicación asíncrona entre componentes
API-first Frontend completamente desacoplado
Config over Code Cambios de negocio sin redespliegue
Simplicidad La solución más simple que funcione

Stack Tecnológico

Capa Tecnología Justificación
Core API Rails 8 + Ruby 3.3 Madurez, DRY, ecosistema
Ingesta Go + gRPC Alta performance, zero-downtime
Base de datos TimescaleDB Time-series nativo sobre PostgreSQL
Cache Dragonfly 25x más rápido que Redis
Frontend Vue 3 + Vite Moderno, reactivo, rápido
AI FastAPI + LangChain Ecosistema ML/AI de Python

Arquitectura General

¿Por qué Go para Ingesta?

Comparación de performance

Métrica Rails Go
Throughput ~10K req/s ~100K+ req/s
Memoria ~200 MB ~20 MB
Startup Segundos Milisegundos
Deploy Con downtime Zero-downtime

Beneficio clave

Si Rails cae por mantenimiento o error, la ingesta sigue funcionando.
Los datos nunca se pierden.

Capas de Datos (TimescaleDB)

TimescaleDB: Características Clave

  • Hypertables: Particionamiento automático por tiempo
  • Continuous Aggregates: Rollups incrementales
  • Compresión: 90%+ después de 7 días
  • Retención: Políticas automáticas de borrado

Política de retención propuesta

Capa Retención Uso
RAW 90 días Debugging, auditoría
Agregados 2 años Reportes operativos
KPIs 5+ años Análisis histórico

Modelado: El Problema

Modelo actual (jerárquico fijo)

Planta → Área → Línea → Máquina → Sensor

Limitaciones:

  • ❌ No soporta bifurcaciones (una máquina alimenta 2 líneas)
  • ❌ No soporta máquinas móviles (robots, AGVs)
  • ❌ Cambios de topología = cambios de código
  • ❌ Un sensor solo puede pertenecer a una máquina

Modelado: La Solución

Separación Física vs Lógica

Capa Contenido Características
Física Assets (máquinas, sensores) Cambia raramente
Lógica Topología (grafo de nodos) Configurable en UI
Asignación Asset → Nodo Puede ser temporal

Beneficios

  • ✅ Máquinas móviles: Se reasignan dinámicamente
  • ✅ Bifurcaciones: Un nodo conecta a múltiples
  • ✅ Sin código: Cambios de topología en configuración
  • ✅ Auditable: Historial de asignaciones

DataSource: Quién Emite Datos

Antes

Solo el modelo "Sensor" podía emitir datos

Ahora

Cualquier Asset con capacidad emits_data: true

Tipo de Asset Ejemplo Emite datos
Sensor físico Contador óptico ✅
Máquina con PLC Empacadora smart ✅
Gateway Agregador de señales ✅
Virtual OEE calculado ✅

OEE Engine

OEE: Mejoras en v2

Aspecto v1 v2
Ubicación Disperso en modelos Service dedicado
Fórmula Fija Configurable por línea
Parcial No Sí (A×P, solo A, etc.)
Benchmarking No Cross-tenant
Triggers Externos Integrados

Configuración ejemplo

oee_config = {
  formula: :standard,        # :standard, :teep, :custom
  target: 0.85,              # 85% objetivo
  alert_threshold: 0.70      # Alerta si < 70%
}

Gestión de Paradas

Paradas: Flujo Completo

  1. Detección automática: Stream detecta Δt > umbral
  2. Clasificación AI: Modelo ML predice razón probable
  3. Auto-asignación: Si confianza > 80%, se asigna sola
  4. Fallback manual: Operador valida o corrige
  5. Catálogo jerárquico: 3 niveles de razones
  6. Analytics: Pareto, predicción, tendencias

Métricas de clasificación

  • Accuracy target: 85%+
  • Reducción tiempo manual: 70%
  • Feedback loop: Correcciones mejoran el modelo

Sistema de Alertas

Alertas: Características v2

Fuentes de alerta

  • OEE bajo umbral
  • Parada excede duración máxima
  • Defectos de calidad detectados
  • Predicciones de falla (AI)

Escalamiento automático

Nivel Rol Timeout Canal
L1 Operador 5 min Push, Dashboard
L2 Supervisor 15 min Email
L3 Gerente 30 min SMS, WhatsApp

Multi-tenancy

Row Level Security (RLS)

Implementación

-- Habilitar RLS en la tabla
ALTER TABLE measurements ENABLE ROW LEVEL SECURITY;

-- Política de aislamiento
CREATE POLICY tenant_isolation ON measurements
  USING (tenant_id = current_setting('app.tenant_id')::INT);

-- En Rails, al inicio de cada request
ActiveRecord::Base.connection.execute(
  "SET app.tenant_id = #{current_tenant.id}"
)

Beneficios

  • Aislamiento a nivel DB (no solo aplicación)
  • Imposible acceder a datos de otro tenant
  • Performance: Índice en tenant_id

Multi-tenant: Comparación

Aspecto Antes (4 DBs) Ahora (1 DB + RLS)
Servidores 4 1 cluster
Costo mensual $400+ ~$100
Deploys 4 manuales 1 automatizado
Migraciones Por cliente Global
Backups 4 procesos 1 proceso
Monitoreo 4 dashboards 1 dashboard

Reducción de costos: ~75%

Módulo AI

Función Descripción Tecnología
Chat "¿Paradas sin justificar?" Claude + RAG
Clasificador Auto-justificación Custom ML
Analytics NL "OEE de ayer por línea" LangChain
Predicción Detección temprana Time-series ML

Stack AI

  • API: FastAPI (Python)
  • LLM: Claude (Anthropic)
  • Embeddings: pgvector
  • ML: scikit-learn, Prophet

Plan de Implementación

Fase Mes Entregables
1. Foundation 1-2 Setup, CI/CD, Rails 8, schemas
2. Core 2-4 Modelos, TimescaleDB, Go ingesta
3. Business 4-6 Multi-tenant, OEE, Paradas
4. UI 6-8 Vue frontend, Alertas
5. AI 8-10 Clasificador, Chat, Analytics
6. Migration 10-12 Datos históricos, Go-live

Timeline total: 12 meses

Resumen de Beneficios

Área Mejora
Infraestructura 75% reducción de costos
Operaciones 1 deploy vs 4
Escalabilidad N clientes sin límite
Flexibilidad Topología configurable
AI Clasificación automática 85%+
Time to market Nuevo cliente en horas

¿Preguntas?

Neykos PMS v2
Propuesta de Arquitectura

Enero 2026