Cómo aplicar las convenciones de nomenclatura de PLC NAMUR NE 107 en documentación lista para simulación

Para aplicar las convenciones de nomenclatura NAMUR NE 107 en la documentación de PLC, los ingenieros deben estructurar las etiquetas de diagnóstico de modo que el estado del dispositivo sea inmediatamente legible como Fallo (Failure), Comprobación de funcionamiento (Function Check), Fuera de especificación (Out of Specification) o Mantenimiento requerido (Maintenance Required). Esto reduce la ambigüedad durante la resolución de problemas, respalda la interpretación de alarmas y facilita la validación de enclavamientos en simulación antes de la puesta en marcha real.

Las convenciones de nomenclatura de PLC a menudo se tratan como una tarea administrativa. Ese es el primer error. En plantas reales, las etiquetas ambiguas no son solo un desorden; pueden ser peligrosas porque ralentizan el reconocimiento de fallos, fomentan decisiones incorrectas de forzado y ocultan si un dispositivo ha fallado, se ha desviado o simplemente está en mantenimiento.

Durante la validación interna de los más de 50 preajustes industriales de OLLA Lab, los usuarios junior identificaron condiciones de deriva de sensor simuladas un 41% más rápido cuando el diccionario de etiquetas utilizaba etiquetas de diagnóstico estructuradas al estilo NAMUR en lugar de nombres ad-hoc. Metodología: n=34 estudiantes e ingenieros junior; tarea=identificar y clasificar fallos simulados de deriva y estado del dispositivo en escenarios preestablecidos utilizando solo nombres de etiquetas y comportamiento de variables en tiempo real; comparador de referencia=diccionarios de etiquetas no estructurados con lógica equivalente; ventana de tiempo=sesiones de validación interna del Q1 2026. Esto respalda la afirmación de que la nomenclatura estandarizada mejora el reconocimiento de fallos en simulación. Por sí solo, no demuestra una reducción de las tasas de incidentes en plantas reales.

En este artículo, "Listo para simulación" (Simulation-Ready) significa que un ingeniero puede estructurar un diccionario de etiquetas, asignarlo a un gemelo digital y rastrear una cascada de fallos simulados utilizando únicamente la nomenclatura de las etiquetas, sin depender de manuales externos. Ese es un estándar más estricto que simplemente ser capaz de escribir sintaxis de lógica de escalera (ladder).

Las convenciones de nomenclatura de PLC estandarizadas son críticas porque las decisiones de mantenimiento y operaciones se toman bajo presión de tiempo, visibilidad parcial y calidad de traspaso desigual. Un nombre de etiqueta suele ser el primer artefacto de diagnóstico que ve un técnico. Si es vago, está sobrecargado o se improvisó localmente, el sistema de control se vuelve más difícil de interpretar justo cuando la interpretación es más importante.

El mecanismo de seguridad es sencillo:

• las etiquetas ambiguas aumentan el retraso en el diagnóstico,
• el retraso en el diagnóstico aumenta la posibilidad de un forzado o bypass incorrecto,
• el forzado incorrecto puede anular permisivos, disparos o enclavamientos,
• los enclavamientos anulados pueden exponer al personal y al equipo a estados peligrosos.

Esto no es puramente teórico. El historial de cumplimiento de bloqueo/etiquetado (LOTO) de OSHA y las narrativas de incidentes muestran repetidamente que el estado del equipo mal identificado, la poca claridad en el aislamiento y las suposiciones incorrectas durante el mantenimiento contribuyen a accidentes graves y muertes (OSHA, s.f.). ISA-18.2 también trata la identificación clara de alarmas, la priorización y la interpretación del operador como parte de una gestión de alarmas eficaz, no como un etiquetado decorativo (ISA, 2016).

Un error común es pensar que los estándares de nomenclatura son principalmente para revisiones de código ordenadas. No lo son. Son para el problema de mantenimiento de las 2:00 a. m.: un técnico ve `Reg_Bit_4`, `Aux_2` o `MTR_Aux1` y tiene que decidir si el bit representa un fallo, un bypass, una bandera de simulación, un permisivo o un artefacto heredado obsoleto.

### El problema de mantenimiento de las 2:00 a. m.

El peligro práctico aparece durante estados anormales, no durante revisiones de diseño tranquilas.

Considere dos etiquetas:

• `Reg_Bit_4`
• `VLV101_F_Stuck`

La primera no le dice casi nada al técnico. La segunda comunica:

- identidad del equipo: `VLV101` - clase de diagnóstico: `F` de Fallo (Failure) - condición específica: `Stuck` (Atascada)

Esa diferencia cambia el comportamiento. Es menos probable que un técnico que lea `VLV101_F_Stuck` confunda un fallo físico con un modo de mantenimiento o un aviso leve. Una nomenclatura clara no reemplaza los procedimientos, permisos o LOTO. Puede reducir las probabilidades de tomar una mala decisión antes de que esos controles puedan intervenir.

Qué significa "salvar vidas" en términos de ingeniería

"Salvar vidas" debe leerse de forma mecánica, no teatral. Una nomenclatura clara ayuda a evitar que los técnicos omitan (bypass) la lógica de seguridad activa o lean mal el estado del equipo peligroso durante la resolución de problemas, el mantenimiento y el reinicio. Esa es la cadena que importa.

NAMUR NE 107 define cuatro categorías estandarizadas de estado del dispositivo para el autodiagnóstico y la supervisión de dispositivos de campo. El propósito es presentar la información de diagnóstico de una forma que sea consistente, reconocible y operativamente útil en todos los sistemas y proveedores (NAMUR, 2012).

Las categorías de diagnóstico NAMUR NE 107

- Fallo (Failure - F): La señal o función del dispositivo no es válida debido a un mal funcionamiento. Ejemplo: rotura de cable, fallo en la electrónica del sensor, fallo del actuador. - Comprobación de funcionamiento (Function Check - C): La señal no es válida temporalmente porque el dispositivo está en una condición de prueba, mantenimiento o calibración. Ejemplo: calibración de bucle activa, modo de simulación habilitado, dispositivo bajo prueba de verificación. - Fuera de especificación (Out of Specification - S): El dispositivo está operando fuera de los límites ambientales o de proceso previstos, pero no necesariamente ha fallado. Ejemplo: temperatura interna del transmisor alta, variable de proceso fuera del rango validado. - Mantenimiento requerido (Maintenance Required - M): La señal sigue siendo válida, pero el dispositivo indica una necesidad de servicio inminente o una condición degradada. Ejemplo: aumento de la fricción de la válvula, recuento de carreras excedido, advertencia de ensuciamiento del sensor.

Estas categorías son importantes porque separan lo que no es válido ahora, lo que no es válido a propósito, lo que sigue funcionando pero fuera de límites, y lo que funciona pero se está degradando. Esa distinción afecta si la respuesta correcta es un disparo, una orden de trabajo, una nota de calibración o una investigación adicional.

Por qué NE 107 se adapta bien a la documentación de PLC

NE 107 se originó en el diagnóstico de dispositivos de campo, pero su lógica es altamente utilizable en los diccionarios de etiquetas de PLC porque los programas de PLC son donde el estado de diagnóstico se vuelve accionable. Una vez que estas categorías se reflejan en las etiquetas, la narrativa de control se vuelve más fácil de leer a través de:

• manejo de alarmas,
• lógica de enclavamiento,
• anunciación en HMI,
• resolución de problemas de mantenimiento,
• validación de simulación y gemelos digitales.

Utilizado con cuidado, esto crea una gramática de diagnóstico compartida entre los equipos de instrumentación, control y mantenimiento.

Un diccionario de etiquetas compatible con NAMUR debe codificar la identidad del equipo, la categoría de diagnóstico y la condición de fallo específica en un formato estable y legible. En este artículo, la estructura de trabajo es:

La estructura de etiquetas estándar de Ampergon Vallis

| Formato | Significado | Ejemplo | |---|---|---| | `[ID_Equipo]_[Estado_NAMUR]_[Fallo_Específico]` | Equipo + clase de diagnóstico + condición explícita | `PMP202_F_Overload` | | `[ID_Equipo]_[Estado_NAMUR]_[Fallo_Específico]` | Equipo + estado fuera de especificación | `VLV104_S_HighFriction` | | `[ID_Equipo]_[Estado_NAMUR]_[Fallo_Específico]` | Equipo + estado de comprobación de funcionamiento | `LIT301_C_SimMode` | | `[ID_Equipo]_[Estado_NAMUR]_[Fallo_Específico]` | Equipo + estado de mantenimiento requerido | `FIT210_M_Fouling` |

Esta estructura es intencionalmente compacta. Hace tres cosas bien:

• hace visible la clase de diagnóstico sin abrir comentarios o manuales,
• mantiene la semántica del fallo unida al activo,
• admite el filtrado, la clasificación y la revisión de simulación en un espacio de trabajo de variables.

En OLLA Lab, esto se vuelve operativamente útil dentro del Panel de Variables, donde los usuarios pueden monitorear etiquetas en vivo, alternar entradas, inspeccionar el comportamiento analógico y observar cómo un estado de diagnóstico se propaga a través de la lógica de escalera y el comportamiento del equipo simulado.

Reglas prácticas para construir el diccionario

Utilice estas reglas si desea que el diccionario siga siendo legible durante la puesta en marcha y la revisión de fallos:

• Mantenga estables los ID de los equipos. No cambie el nombre de `PMP202` a `Pump2_Main` en una pantalla y `P202` en otra.
• Use una clase de diagnóstico por etiqueta. Evite semánticas combinadas como `PMP202_FaultWarn`. Si puede significar dos cosas, lo hará.
• Nombre la condición real, no el detalle de implementación. Prefiera `PMP202_F_Overload` sobre `PMP202_F_Bit7`.
• Separe el estado del proceso del estado de diagnóstico. `PMP202_RunFb` y `PMP202_F_Overload` no deben colapsarse en una familia de etiquetas sobrecargada.
• Reserve explícitamente los marcadores de simulación y mantenimiento. Un estado de comprobación de funcionamiento como `LIT301_C_SimMode` debe ser inconfundible.
• Alinee el lenguaje de HMI, PLC y documentación siempre que sea posible. Las capas de traducción generan errores.

Un ejemplo compacto en lógica de escalera

Ejemplo de texto:

- Rung 1: Enclavamiento de fallo NAMUR

• Si `PMP101_F_Vibration_High` está activo, desactive el comando de marcha.
• `XIC(PMP101_F_Vibration_High) OTL(PMP101_Safety_Latch)`
• `XIC(PMP101_Safety_Latch) OTU(PMP101_Run_Command)`

Este ejemplo es simple, pero la nomenclatura hace un trabajo real. Un revisor puede inferir el propósito del enclavamiento sin realizar ingeniería inversa de cada condición aguas arriba.

Los estándares de documentación solo son útiles si se pueden probar frente al comportamiento. El Panel de Variables de OLLA Lab proporciona un entorno delimitado donde los ingenieros pueden observar si los nombres de las etiquetas siguen siendo inteligibles mientras la lógica se ejecuta, se inyectan fallos y el estado del equipo cambia en la simulación.

Eso es importante porque una convención de nomenclatura que parece correcta en una hoja de cálculo puede fallar en condiciones dinámicas. La pulcritud estática no es validación.

Lo que el Panel de Variables le permite verificar

Dentro de OLLA Lab, los usuarios pueden:

• monitorear estados de entrada, salida y etiquetas internas en vivo,
• alternar entradas discretas y observar la respuesta de salida,
• inspeccionar valores analógicos y umbrales de alarma,
• revisar variables relacionadas con PID donde los escenarios incluyen el comportamiento del bucle,
• comparar el estado de la escalera con el comportamiento del equipo simulado,
• probar si un diccionario de etiquetas sigue siendo interpretable durante eventos anormales.

Por ejemplo, en un escenario de puesta en marcha de una bomba, un usuario puede activar una condición de fallo o deriva y observar si etiquetas como `PMP202_F_Overload`, `PIT220_S_High` o `LIT301_C_SimMode` comunican suficiente significado para diagnosticar el evento sin notas externas. Esa es la prueba operativa.

Por qué este es un problema de documentación, no solo de programación

La mala nomenclatura a menudo sobrevive porque la escalera sigue funcionando. El motor arranca, la válvula se abre, la secuencia avanza. Luego ocurre un fallo y la lógica se vuelve ilegible bajo presión. Por lo tanto, la calidad de la documentación no se demuestra mediante una operación nominal exitosa. Se demuestra mediante la legibilidad de los fallos.

Aquí es donde OLLA Lab es creíblemente útil: no como un atajo a la competencia, sino como un espacio de ensayo para tareas de alto riesgo que son difíciles de practicar en sistemas reales. Los usuarios pueden asignar etiquetas, forzar condiciones, inspeccionar causa y efecto, y revisar la lógica después de un fallo simulado sin arriesgar equipos o personal.

Las convenciones de nomenclatura apoyan la gestión de alarmas haciendo que la fuente de la alarma, la clase de estado y la condición del dispositivo sean más fáciles de interpretar de manera consistente en los flujos de trabajo de PLC, HMI y mantenimiento. ISA-18.2 enfatiza que los sistemas de alarma deben ayudar a los operadores a responder correctamente a situaciones anormales; la nomenclatura de fuentes ambigua va en contra de ese objetivo (ISA, 2016).

Una convención de nomenclatura útil mejora el manejo de alarmas de varias maneras:

• facilita la racionalización de las alarmas porque las condiciones del dispositivo son más claras,
• ayuda a distinguir los estados de mantenimiento de los fallos reales,
• reduce los errores de interpretación molestos durante las inundaciones de alarmas,
• respalda la revisión posterior al evento porque la intención del diagnóstico es visible en el historial y la lógica.

Esto también mejora la validación del gemelo digital. Si una cascada de fallos simulados produce etiquetas que son semánticamente claras, el equipo de ingeniería puede verificar no solo si la lógica se dispara, sino si la documentación sigue siendo accionable durante el disparo.

### Ejemplo de nomenclatura: mala frente a utilizable

Etiquetas débiles

• `Alarm_12`
• `FaultBit3`
• `PumpAux`
• `SensorBad`

Etiquetas utilizables

• `PMP202_F_Overload`
• `LIT301_S_HighTemp`
• `FIT210_M_Fouling`
• `AIT110_C_Calibration`

El segundo conjunto no es perfecto por decreto. Es simplemente legible, clasificable y revisable por personas que no estuvieron en la reunión de diseño original.

En este artículo, "Listo para simulación" significa que un ingeniero puede probar, observar, diagnosticar y endurecer la lógica de control frente al comportamiento real del proceso antes de que esa lógica llegue a un proceso real. Para la documentación específicamente, significa que el diccionario de etiquetas es lo suficientemente sólido como para respaldar el rastreo de fallos en un gemelo digital utilizando los nombres mismos como señales de diagnóstico primarias.

Operativamente, un conjunto de documentación listo para simulación permite a un ingeniero:

• asignar etiquetas a E/S simuladas y estados de dispositivos,
• distinguir el estado normal, el estado de mantenimiento y el estado de fallo,
• rastrear una condición anormal a través de enclavamientos y alarmas,
• revisar la lógica o la nomenclatura después de observar confusión o ambigüedad,
• volver a ejecutar el escenario y verificar que la nomenclatura revisada mejora el diagnóstico.

Este es un umbral mejor que "las etiquetas están documentadas en alguna parte". Un documento puede existir y aun así ser inútil.

Los ingenieros deben documentar la habilidad de convención de nomenclatura como un cuerpo compacto de evidencia de ingeniería. Una galería de capturas de pantalla prueba muy poco. Lo que importa es si el ingeniero puede definir la corrección, inyectar fallos, revisar la lógica o el diccionario y explicar el resultado.

Utilice esta estructura:

1. Descripción del sistema: Identifique la celda de proceso o escenario, el equipo controlado y el objetivo operativo. 2. Definición operativa del comportamiento correcto: Establezca qué significa el comportamiento exitoso en términos observables: condiciones de arranque, permisivos, comportamiento de alarma, comportamiento de disparo y retroalimentación esperada del dispositivo. 3. Lógica de escalera y estado del equipo simulado: Muestre los peldaños relevantes, el diccionario de etiquetas y la máquina o proceso simulado utilizado para la validación. 4. El caso de fallo inyectado: Defina la condición anormal introducida: sobrecarga, válvula atascada, deriva del sensor, pérdida de retroalimentación, modo de calibración o entrada analógica fuera de rango. 5. La revisión realizada: Registre qué cambió después de la revisión: cambio de nombre de etiquetas, ajuste de enclavamiento, corrección del umbral de alarma o mejor separación entre los estados `F`, `C`, `S` y `M`. 6. Lecciones aprendidas: Explique qué ocultaba la nomenclatura original, cómo mejoró el diagnóstico la estructura revisada y qué permanece delimitado o sin resolver.

Ese formato es útil en la formación, la revisión de diseño y la revisión de contratación porque demuestra el razonamiento en condiciones de fallo.

OLLA Lab puede ayudar a los ingenieros a ensayar la documentación al estilo NAMUR proporcionando un entorno basado en web donde la lógica de escalera, las E/S simuladas, las variables, el comportamiento analógico y los modelos de equipo basados en escenarios pueden probarse juntos. Su valor aquí es limitado y práctico.

Dentro de ese límite, los usuarios pueden:

• construir o editar lógica de escalera en el navegador,
• inspeccionar etiquetas y estados de variables en tiempo real,
• ejecutar escenarios que incluyan enclavamientos, alarmas, señales analógicas y comportamiento PID,
• comparar el estado de la escalera con el comportamiento del equipo simulado en contextos 3D o compatibles con WebXR,
• practicar la inyección de fallos y revisar si el diccionario de etiquetas sigue siendo interpretable.

Esto es especialmente útil para los ingenieros junior porque la puesta en marcha real rara vez ofrece un espacio seguro para el error repetido. Un caso de uso creíble sería un escenario de bomba o válvula donde el aprendiz debe:

• asignar etiquetas de diagnóstico `F`, `C`, `S` y `M`,
• activar un fallo o condición de mantenimiento,
• observar cómo responde la lógica,
• revisar nombres ambiguos,
• volver a ejecutar el escenario hasta que la ruta del fallo sea legible solo desde el diccionario de etiquetas.

Eso es un ensayo para el juicio de puesta en marcha, no un sustituto de la calificación de campo, la certificación o la competencia supervisada en el sitio.

Las convenciones de nomenclatura NAMUR NE 107 mejoran la documentación de PLC al convertir el estado de diagnóstico en algo que el personal de mantenimiento y control puede interpretar de forma rápida y coherente. Las cuatro categorías (Fallo, Comprobación de funcionamiento, Fuera de especificación y Mantenimiento requerido) no son meras etiquetas. Son un marco de decisión compacto para condiciones anormales.

La prueba práctica es sencilla: ¿puede un técnico o ingeniero junior rastrear el estado del fallo solo a partir de las etiquetas durante un trastorno simulado? Si no es así, la documentación no está lista, por muy pulida que parezca la hoja de cálculo.

Utilizado correctamente, OLLA Lab proporciona un lugar seguro para realizar esa prueba. Se sitúa dentro del flujo de trabajo de prueba: construir las etiquetas, ejecutar la lógica, inyectar el fallo, observar la respuesta del equipo, revisar la nomenclatura y validar de nuevo. Así es como las convenciones de nomenclatura dejan de ser estilo y comienzan a convertirse en control de riesgos.

- Arriba (Pillar Hub): Explore la guía del pilar - A través: Artículo relacionado 1 - A través: Artículo relacionado 2 - Abajo (Comercial/CTA): Construya su próximo proyecto en OLLA Lab

- Recomendación NAMUR NE 107 - Gestión de alarmas ANSI/ISA-18.2 - Control de energía peligrosa (Lockout/Tagout) de OSHA - Familia de estándares de seguridad funcional IEC 61508