Cómo preparar un listado de señales PLC útil para todo el proyecto

En muchos proyectos, el listado de señales aparece como un archivo aislado creado por automatización. El ingeniero recibe un P&ID, varias hojas de datos y correos con decisiones parciales, y traduce todo a una tabla propia. Esa tabla puede servir para contar E/S, pero no siempre conserva el contexto necesario para el resto del proyecto.

El enfoque más robusto consiste en tratar el listado como una vista de la base técnica del proyecto. Cada señal debe poder relacionarse con un equipo, una función, una comunicación, una ubicación y un destino.

1. Qué debe resolver un listado de señales

Antes de decidir columnas, conviene definir para qué se utilizará. Una lista madura debería responder, como mínimo, a estas preguntas:

• ¿Qué equipo o función origina la señal?
• ¿Es una señal física, interna o comunicada?
• ¿Cuál es su tipo de dato?
• ¿Entra o sale del PLC?
• ¿La HMI la muestra, la escribe o no interviene?
• ¿Necesita un cable y una conexión de campo?
• ¿Está asignada a una tarjeta y canal?
• ¿Forma parte de una comunicación como MODBUS?
• ¿Qué revisión y estado tiene?

Si una señal no puede rastrearse hasta su función y su equipo, el listado solo traslada el problema a la programación.

2. Empezar por equipos y variables tipo

La definición de equipos ofrece un origen estable. Un motor, una válvula de control o un transmisor tienen conjuntos de variables recurrentes, aunque cada proyecto introduzca excepciones.

Por ejemplo, una bomba puede necesitar órdenes, estados, alarmas y disponibilidad. Un instrumento analógico puede incorporar valor de proceso, fallo, calidad o simulación. Definir estas variables por tipología ayuda a mantener un estándar sin copiar filas de proyectos anteriores.

El procedimiento recomendado es:

1. Crear la lista de equipos con tag y descripción únicos.
2. Asignar una tipología funcional y física.
3. Aplicar las variables tipo de la empresa.
4. Eliminar las que no procedan y añadir excepciones justificadas.
5. Revisar el resultado con proceso, electricidad y automatización.

3. Campos recomendados

No todos los proyectos necesitan las mismas columnas, pero esta estructura cubre la mayoría de las decisiones iniciales:

4. Criterios que evitan ambigüedades

Señal física, interna o comunicada

Una variable interna no ocupa una entrada o salida física. Una señal comunicada tampoco debe contarse automáticamente como canal cableado. Separar estas categorías desde el principio evita sobredimensionar el rack o dejar sin tratar el mapa de comunicaciones.

Dirección desde el punto de vista del PLC

«Entrada» y «salida» deben definirse siempre desde la misma perspectiva. En una lista PLC, una orden hacia una válvula es una salida; una confirmación de fin de carrera es una entrada. La descripción debe impedir interpretaciones opuestas.

Tipo de dato y representación

No basta con indicar que una señal es analógica. Deben acordarse el tipo de dato, escala, unidad, resolución y tratamiento de fallo cuando afecten a PLC, HMI o comunicación.

Nombres estables

Los nombres deben poder mantenerse durante todo el proyecto. Cambiar convenciones después de asignar canales, HMI y código genera trabajo cruzado. Conviene validar una pequeña muestra antes de generar cientos de filas.

5. Revisión antes de diseñar el rack

Antes de seleccionar tarjetas, realizar una revisión por bloques:

1. Integridad de equipos: no faltan actuadores ni instrumentos.
2. Coherencia funcional: cada variable tiene sentido para su tipología.
3. Comunicación: señales cableadas y comunicadas están separadas.
4. Clasificación: ED, SD, EA y SA son coherentes con campo.
5. Seguridad: las funciones de seguridad se identifican y tratan con el proceso y metodología adecuados.
6. Reservas: el margen de E/S se define como criterio explícito, no como filas ficticias.

Solo entonces conviene asignar rack, tarjeta, canal y dirección. De este modo, una modificación funcional se detecta antes de comprometer hardware.

6. Errores frecuentes

• Usar el mismo tag para la orden, el estado y la alarma.
• Mezclar señales internas con E/S físicas.
• Contar una variable MODBUS como canal analógico cableado.
• Dejar descripciones como «marcha» sin indicar equipo ni dirección funcional.
• Asignar canales antes de cerrar la lista de equipos.
• No revisar la relación con el conexionado y las hojas de datos.
• Crear columnas que nadie mantiene o cuyo significado no está definido.
• Modificar nombres después de iniciar HMI y programación sin control de cambios.

7. De la tabla al proyecto conectado

El listado gana valor cuando no termina en sí mismo. Las mismas señales deberían alimentar la disposición del PLC, el mapa MODBUS y la base de programación, y conservar relación con el cableado y los equipos.

INELVIA utiliza este enfoque: las señales nacen de la definición del proyecto y se reutilizan en automatización y documentación. La exportación CSV sigue disponible para revisiones externas, pero ya no es la única fuente de verdad.