Esta página describe sin código qué hace el motor de Sun Tech WCS: cómo representa la instalación, cómo elige las rutas, cómo dialoga con el WMS y qué expone a los demás sistemas. El detalle técnico está en la documentación del repositorio, en inglés.

La instalación como dato

La instalación está hecha de dispositivos (los puntos) y uniones (las flechas orientadas que los conectan), guardados en la base de datos del WCS. Al arrancar se convierten en un grafo sobre el que el motor calcula las rutas. Una máquina más es un punto más en el dibujo, no más código.

Hay siete tipos de dispositivo: automatización, carga, buffer, almacén, distribuidor circular, grupo de dispositivos automáticos, y carga y buffer juntos. Cómo se modela una instalación lo explica Modelling a plant.

Las rutas

Gana el recorrido con menos saltos; a igualdad de saltos, el menos concurrido. La prioridad de las uniones decide el orden en que el motor explora los caminos.
No usa tiempos estimados, por decisión: la ruta se recalcula en cada salto a partir del estado real de los dispositivos.
Se pueden imponer pasos obligados, grupos de dispositivos que se atraviesan una sola vez y niveles distintos de la misma instalación.
Los dispositivos fuera de línea se evitan. Si no hay alternativa, el motor lo vuelve a intentar teniéndolos en cuenta: una instalación degradada sigue trabajando en lugar de pararse.

Misiones y estados de los dispositivos

Una misión es una unidad de carga, un destino y un tipo: almacenamiento, extracción, cambio de ubicación, rechazo, desfragmentación y los demás que prevé el motor. Los pasos de la misión se crean salto a salto.

Cada dispositivo tiene un estado: listo, en movimiento, cargando, descargando, ocupado, en recuperación, fuera de línea, bloqueado, aviso, error. «Error» es un estado lógico, es decir, la última orden no tuvo éxito: no es una alarma de campo.

El diálogo con el WMS

El trabajo lo pide el WCS. Cuando el motor está en marcha, una vez por segundo pregunta al WMS qué hay que hacer: extracciones pendientes, notas de expedición. El WMS no empuja pedidos.

Los hechos físicos, como una unidad que ha llegado a su ubicación, vuelven al WMS desde colas duraderas: se entregan al menos una vez, con un recibo, y sobreviven a un reinicio y a un WMS apagado. Si el WMS no responde, el motor sigue funcionando: las misiones que dependen de él esperan, y los hechos salen cuando vuelve.

La lógica de almacén

El WCS gestiona la cola de extracción, las reservas de ubicaciones, las ubicaciones de varias profundidades, la desfragmentación, los grupos de dispositivos y los puntos de rechazo. Es la parte que va de «llevar un palé de A a B» a una instalación que trabaja todo el día.

API, eventos y contratos

Una API HTTP con 66 operaciones, protegida por una clave, para gobernar el motor, los dispositivos y las unidades de carga y leer su estado.
Un canal de eventos en tiempo real (SignalR): cambios de estado de los dispositivos, misiones, cola de extracción, órdenes.
Un cliente .NET tipado, con reconexión automática a los eventos.
Los contratos en formato OpenAPI 3.1, generados desde el código y verificados en cada cambio.

Operación

El WCS funciona como servicio de Windows y guarda sus datos en SQLite, sin un servidor de base de datos que instalar. Tiene una herramienta para la copia de seguridad, la verificación y la restauración incluso con el motor en marcha, un histórico mensual de operaciones y movimientos, y tres scripts de monitorización. El detalle está en la página seguridad y operación.

Qué no hay todavía

La biblioteca Viewer, que mantiene una copia de solo lectura del estado, es experimental. La lógica de un tipo de dispositivo nuevo hoy exige modificar el motor: hacerla ampliable es una dirección declarada por el proyecto, todavía no especificada. La lista completa está en las known limitations.

¿Quieren verlo funcionar? La instalación de ejemplo funciona en un equipo Windows en unos quince minutos, sin máquinas y sin un WMS propio. Primeros pasos

Qué hace Sun Tech WCS