Qué permite leer un historial Andon y qué no demuestra

Al leer un historial Andon, conviene ceñirse a lo que muestran la pantalla y sus campos en ese producto. En la app descrita por Tulip, un evento Andon afecta al estado de la estación y una alerta puede existir sin cambiarlo; su ejemplo funcional enumera campos requeridos y opcionales. Mitsubishi, en cambio, muestra por separado eventos de línea, alarmas del GOT y estado de llamada al líder.

Son registros distintos: leer uno no demuestra por sí mismo causa, respuesta efectiva ni resolución. La comparación se limita a estas documentaciones de producto; no establece un modelo universal. Tulip, “Andon Management”, líneas 169–178; Tulip, “Andon Functional Example”, líneas 96–148; Mitsubishi Electric, FA Application Package iQ Monozukuri ANDON, pp. 6 y 9.

Empieza por identificar la pantalla

La palabra «historial» puede hacer que dos listas parezcan comparables aunque cada una registre otra cosa. Un cambio de estado de estación, un evento de equipo, una alarma de software y un estado de llamada pueden aparecer en una instalación bajo el mismo entorno visual. Eso no los convierte en un mismo tipo de dato.

En los documentos examinados, Tulip describe una aplicación con tablas y vistas para los registros Andon; el catálogo de Mitsubishi describe plantillas de pantalla para un paquete iQ Monozukuri ANDON. La comparación útil es la que conserva la etiqueta de origen y la función que cada fabricante atribuye a su vista.

La distinción es una síntesis editorial, no una taxonomía de los fabricantes. Antes de leer una fila, identifica la pantalla, su entidad principal y los campos disponibles; si falta una etiqueta, deja la interpretación abierta.

Las descripciones proceden de los fabricantes; las preguntas son una guía editorial. Tulip, “Andon Management”, líneas 169–178; Mitsubishi Electric, catálogo, p. 9.

Leer un evento de Tulip sin convertir el ejemplo en estándar

El ejemplo funcional de Tulip presenta una tabla llamada “Log Downtime Events” y muestra cómo se pueden configurar consultas y análisis alrededor de ella. La guía advierte que el ejemplo no es una solución lista para usar y presupone familiaridad con tablas, consultas y analítica.

Esa condición cambia cómo debe leerse cualquier lista de campos: informa de una propuesta funcional documentada por el proveedor, no de los datos que necesariamente aparecerán en todos los sistemas que se llamen Andon. Tulip, “Andon Functional Example”, líneas 46–75.

En esa propuesta, el ejemplo enumera como campos requeridos el ID, la ubicación, el estado, la duración, la persona que informa y las fechas de informe y cierre. También señala como opcionales Source, responsable, comentarios y reason code. La lista separa los datos necesarios para el ejemplo de los que pueden añadirse. Source puede aportar información adicional sobre la causa del evento; los otros campos opcionales pueden indicar una asignación o incluir anotaciones, si la configuración concreta los utiliza.

La documentación no convierte esos elementos en propiedades que toda base de datos de producción deba contener.

Qué responde cada campo y qué queda abierto

El ID sirve para distinguir la fila de otras filas dentro de la tabla. No identifica automáticamente una causa técnica ni un activo, salvo que otra relación o campo lo establezca. La ubicación sitúa el evento en el modelo de la aplicación; su precisión depende de cómo se haya construido ese dato. El estado informa del estado guardado para el registro.

La guía no autoriza a reinterpretar el nombre de cada estado como una decisión de seguridad o como prueba de que una máquina estuviera físicamente parada.

En Tulip, Status depende de la tabla: Stations.Status muestra estados de estación (Running, Down, Idle o Paused); Actions.Status indica el de una acción (New, In progress o Closed). En el ejemplo funcional, Status del evento aparece en (Log) Downtime Events: IN PROGRESS/OPEN o CLOSED. Antes de comparar valores, identifica la tabla: las guías describen contextos distintos, no un ciclo común. Tulip, “Andon Management”, líneas 64–83 y 92–103; Tulip, “Andon Functional Example”, líneas 82–107 y 110–132.

La duración y las fechas permiten situar el registro temporalmente según la semántica implementada. No bastan por sí mismas para calcular el tiempo total de indisponibilidad de una línea: haría falta saber qué reloj representa la duración, cómo se generan las fechas, si se agregan eventos superpuestos y qué reglas de exclusión aplica el análisis. La documentación funcional muestra un campo y un ejemplo de análisis; no presenta una auditoría independiente de exactitud temporal ni una definición universal de disponibilidad.

La persona informante identifica quién registró o comunicó el evento en el ejemplo. No demuestra necesariamente quién observó el problema primero, quién lo investigó o quién tenía autoridad para actuar. El responsable opcional puede aportar una pista de asignación en una instancia configurada, pero una asignación no equivale a aceptación, diagnóstico ni resolución. Los comentarios pueden conservar texto contextual si se usan; su presencia tampoco demuestra que la descripción sea completa o verificada.

Source y Reason Code son también opcionales en el ejemplo. Tulip define Source como información adicional sobre la causa del evento y Reason Code como la causa del evento. Si esos campos aparecen rellenados, pueden acotar la lectura del registro conforme a las opciones que esa aplicación haya configurado. El lector debe consultar el significado local de cada valor: un código corto sin diccionario no basta para reconstruir qué ocurrió.

Si el campo no existe o está vacío, solo puede decirse que no aparece en la vista o ejemplo consultado; no que la información nunca se registró en otro lugar.

Tulip documenta además una diferencia funcional entre evento Andon y alerta: el evento afecta al estado de estación, mientras que una alerta puede existir sin cambiar ese estado. Sus vistas de historial cerrado pueden filtrarse por tipo, ubicación, reason code y fecha de creación.

De ahí se deduce una lectura acotada: las categorías de filtro ayudan a localizar registros en esa aplicación; no prueban que una búsqueda exhaustiva haya encontrado todos los eventos relacionados, ni que los filtros estén disponibles idénticamente en otro producto. Tulip, “Andon Management”, líneas 169–178.

El ejemplo funcional de Tulip añade un límite al campo «ubicación»: solo permite un evento Andon abierto por ubicación. Al seleccionar una ubicación, carga el último evento abierto si existe; el mismo botón crea un registro cuando no hay ninguno abierto o limpia el que ya está abierto. Es la lógica de ese ejemplo, no una regla general de Andon.

La guía no explica cómo representa varios avisos simultáneos en la misma ubicación, así que conviene comprobar la configuración local antes de leer una fila como el único registro posible. Tulip, “Andon Functional Example”, líneas 90–93 y 117–132.

Tres historiales que Mitsubishi mantiene separados

El catálogo de Mitsubishi llama “Event history screen” a una pantalla que presenta una lista de eventos ocurridos en la línea, con ejemplos como el inicio y la parada de operación de un equipo. La descripción identifica el foco como eventos de producción en la línea. No especifica en ese pasaje una taxonomía completa, los campos de cada fila, los criterios de retención ni una causa asociada a cada evento.

La lectura correcta se mantiene en ese límite: es la pantalla que el catálogo describe como historial de eventos de línea. Mitsubishi Electric, catálogo, p. 9.

La “System alarm history screen” tiene otro objeto: el catálogo indica que muestra el historial de alarmas del GOT, o servidor web, y presenta la lista de alarmas que han ocurrido en ese GOT. Aunque ambas pantallas se encuentren dentro del paquete Andon, no deben fusionarse semánticamente. Una alarma del GOT no es automáticamente un evento de arranque o parada de equipo. Para asociarlas harían falta claves, marcas temporales y reglas de relación que el pasaje citado no proporciona.

La tercera pantalla, “Leader notice screen”, muestra el estado de llamada del líder en un cliente o terminal de visualización; el catálogo remite a la descripción de la llamada en la página 6. Allí indica que una persona puede llamar al líder a través del GOT local y que las notificaciones se muestran en una tablet del líder o en un ordenador de oficina. El catálogo presenta esta capacidad dentro del paquete específico.

No dice que el estado mostrado registre quién leyó el aviso, qué diagnóstico emitió ni cuándo se resolvió una incidencia. Mitsubishi Electric, catálogo, pp. 6 y 9.

Un evento de equipo, una alarma del GOT y una llamada al líder son tres registros que el catálogo identifica. Que el trabajo se haya resuelto es otra cuestión. Las tres primeras corresponden a vistas identificadas en el catálogo. La cuarta no se demuestra solo por tener abierta una pantalla de llamada o por hallar una fila en cualquiera de las listas.

Un registro puede contribuir a una reconstrucción cuando se combina con otra evidencia, pero el catálogo no aporta aquí un procedimiento de reconstrucción ni afirma que las pantallas compartan una clave común.

Ejemplo hipotético: dos registros y una llamada

El siguiente caso es hipotético y sirve solo para ejercitar la lectura de categorías. No describe una planta real ni afirma que una de las configuraciones citadas se use allí. Supongamos que, al revisar una parada breve, una persona encuentra tres elementos: un registro de evento de línea con hora de inicio y fin; una alarma de GOT cercana en el tiempo; y una pantalla o registro con estado de llamada al líder.

La coincidencia temporal puede invitar a contar una sola historia, pero las fuentes citadas no bastan para enlazar automáticamente esos elementos.

Rama A: se conserva la separación. La persona que revisa anota qué pantalla contiene cada dato, la etiqueta exacta y la marca temporal visible. La lista Mitsubishi puede sostener que existe una pantalla de eventos de línea, otra de alarmas GOT y otra de llamada. Si esas vistas no presentan un identificador común en la evidencia consultada, la persona no afirma que la alarma causara la parada ni que la llamada se originara por ella.

Esta conclusión es prudente porque usa solo categorías y hechos visibles.

Rama B: se propone una relación, pero queda pendiente de verificar. Si en un entorno concreto existe un identificador compartido o una relación documentada por el propio sistema, ese dato podría permitir examinar si los registros se vinculan. Aun así, la relación temporal o de ID sería evidencia de asociación dentro de ese modelo; para afirmar causalidad harían falta datos que sostuvieran el vínculo causal.

En este caso hipotético no se inventan esos identificadores ni se atribuyen a Mitsubishi: son la pregunta que falta resolver antes de redactar una conclusión.

Ahora supongamos que el sistema muestra “llamada al líder” como un estado, pero no muestra acuse, comentario, responsable o cierre asociado. Puede afirmarse que el catálogo de Mitsubishi describe una pantalla para mostrar el estado de llamada. No puede decirse que el líder atendiera la petición, que inspeccionara el equipo o que la producción reanudara con autorización. El término “estado” no añade por sí solo una semántica más rica que la que la pantalla y su manual explican.

En una instancia de Tulip, el análisis sería diferente. Si la tabla de ejemplo muestra un registro con ubicación, estado, duración y persona informante, esos valores permiten describir qué contiene el registro de esa app. Si Source, responsable, comentarios o reason code no aparecen, el ejemplo los define como campos opcionales, pero no se debe concluir que la instalación carece de esos datos en cualquier otro sitio.

La ausencia en una fila observada y la opcionalidad del diseño son hechos distintos.

Lo que la comparación permite y lo que no

Las fuentes describen los campos y categorías de estas vistas; no prueban que los registros estén relacionados, que la llamada se atendiera o que un estado equivalga a resolución. Para sostener una relación haría falta un vínculo documentado; para afirmar causa o desenlace, evidencia adicional. No establecen un esquema común ni una política de respuesta entre Tulip y Mitsubishi. Tulip, “Andon Management”, líneas 169–178; Mitsubishi Electric, catálogo, pp. 6 y 9.

Preguntas frecuentes

¿Qué diferencia la app de Tulip entre un evento Andon y una alerta?

En la app documentada, el evento Andon afecta al estado de la estación; una alerta puede existir sin cambiarlo. Es una distinción de esa app de Tulip.

¿Qué campos incluye como requeridos el ejemplo funcional de Tulip?

Enumera ID, ubicación, estado, duración, persona informante y fechas de informe y cierre; Source (información adicional sobre la causa del evento), responsable, comentarios y reason code aparecen como opcionales.

¿Qué separa el catálogo Mitsubishi en sus pantallas de historial?

Distingue eventos de línea como arranque o parada de equipo, historial de alarmas del GOT y una pantalla con el estado de llamada al líder.

¿El estado de llamada al líder demuestra que el problema se resolvió?

No por sí solo. El catálogo describe una pantalla de estado de llamada; no dice que ese estado certifique diagnóstico o resolución.

Referencias primarias

• Tulip, “Andon Management”, actualizado el 1 de abril de 2026. Pasaje sobre evento Andon, alerta e historial cerrado: líneas 169–178; detalles de Stations y Actions: líneas 55–80.
• Tulip, “Andon Functional Example”, actualizado el 14 de agosto de 2026. Advertencia sobre el ejemplo configurable: líneas 46–75; campos requeridos y opcionales: líneas 96–148.
• Mitsubishi Electric, FA Application Package iQ Monozukuri ANDON, catálogo L(NA)08487ENG-B. Leader call/notice: p. 6; descripción de Event history, System alarm history y Leader notice: p. 9. Se trata del catálogo de un paquete concreto, no de una norma o un manual universal.