
Una lista de señales relaciona los puntos de campo con sus entradas, salidas y destinos en el sistema de control. Sirve para coordinar información entre instrumentación, tableros, programación y documentación. El proyecto debe acordar qué campos utiliza y cómo mantiene sus revisiones.
Una fila debe identificar una señal
El instrumento y la señal no siempre tienen una relación de uno a uno. La ficha EJX110A, por ejemplo, describe una salida analógica y opciones de salida de estado según configuración. Por eso, no conviene reservar una sola fila por equipo sin revisar qué información intercambia.
Proponemos una estructura original con identificación del equipo, descripción de la señal, tipo, sentido, rango y unidad cuando correspondan. Distinga una entrada analógica de una entrada digital o un dato adquirido por comunicación. Los nombres deben seguir la convención acordada por el proyecto; la tabla ilustrativa no impone códigos ISA.
Conecte campo, canal y variable
Para señales cableadas, documente gabinete, módulo, canal y referencia al plano que contiene el conexionado. Para datos por red, registre equipo, protocolo y referencia al mapa de datos. Una dirección o un canal no reemplaza la descripción de la función.
El esquema explicativo muestra una trazabilidad hipotética entre una señal de presión, una entrada analógica, una variable de programa y su visualización. No asigna canales reales ni representa equipos instalados en Paraguay.
| Campo propuesto | Pregunta que permite resolver |
|---|---|
| Identificación y descripción | ¿Qué equipo y qué información representa? |
| Tipo y sentido | ¿Es una entrada, salida o dato comunicado? |
| Rango y unidad | ¿Cómo debe interpretarse cuando es una magnitud? |
| Receptor o emisor | ¿Dónde se adquiere o genera? |
| Destino y referencia | ¿Qué lógica, pantalla o documento la utiliza? |
| Revisión y estado | ¿Qué está confirmado y qué falta definir? |

Evite confundir señales con funciones
Una lista de entradas y salidas no describe por completo una secuencia de control. Tampoco reemplaza planos, hoja de datos o especificación funcional. Debe permitir vincularse con esos documentos para que el mismo punto conserve su identidad a lo largo del proyecto.
En una entrada digital, «activo» puede tener significados distintos. El responsable debe describir el estado que informa y el tratamiento previsto si la señal no está disponible. Para variables analógicas, la unidad y la escala deben coincidir con los datos del instrumento y la configuración del receptor.
Defina la unidad de registro antes de completar filas
Una lista de señales funciona mejor cuando todos los participantes entienden qué representa una fila. Puede describir un punto cableado, una variable comunicada o una información derivada, según el alcance acordado. Esas clases deberían distinguirse para no contar recursos físicos y variables de programa como si fueran equivalentes.
Ejemplo hipotético: un instrumento entrega una magnitud analógica y un estado opcional. Si ambas señales forman parte del proyecto, cada una necesita su descripción y destino. La ficha EJX110A muestra que esa disponibilidad puede depender de configuración. La lista no debe agregar funciones solo porque aparecen en una familia de catálogo.
También conviene separar señales activas de reservas previstas. Una reserva no corresponde todavía a un instrumento operativo, y una variable calculada no implica necesariamente un canal adicional. La clasificación documental permite revisar qué utiliza hardware, qué utiliza comunicación y qué existe únicamente dentro del programa.
Tipo y sentido deben tener una referencia común
Al describir una entrada o salida, indique respecto de qué sistema se utiliza ese nombre. Lo que un equipo emite puede ser una entrada para el controlador. La lista necesita una convención que permita comprender esa relación sin interpretar el nombre desde perspectivas diferentes.
Para señales analógicas, documente la magnitud y la forma prevista de transmisión. Para señales discretas, describa el significado del estado. Para comunicación, remita al protocolo y al mapa de datos. La arquitectura presentada en NIST SP 800-82 permite entender la relación entre campo, control y supervisión, pero no impone esta estructura de tabla.
Un ejemplo de campo documental sería «entrada al controlador que informa disponibilidad de la unidad». Su función aún debe definirse en la especificación correspondiente. La lista identifica la información; no reemplaza la descripción de cómo la lógica utiliza ese estado.
Un nombre claro evita mezclar magnitudes y condiciones
La descripción debería permitir reconocer qué representa la señal sin depender solo de su código. «Presión de descarga» y «presión alta» pueden referirse a una magnitud y a una condición distinta. Si se incluyen ambas, documente el origen de cada una y evite tratarlas como duplicados por compartir equipo o palabra.
En una variable analógica, la unidad y la referencia forman parte de su interpretación. Una fila que indica únicamente un rango numérico puede dejar sin aclarar si representa presión relativa, absoluta o diferencial. La hoja de datos debe conservar el detalle técnico y la lista enlazarlo con el destino de control.
Para señales discretas, describa qué significa cada estado relevante según el diseño. La asociación entre un valor y una condición debe quedar validada por el responsable. Este artículo no prescribe contactos normalmente abiertos o cerrados ni tratamiento eléctrico de fallas.
Documente la trazabilidad sin convertir la lista en un plano
Una fila cableada puede remitir al gabinete, módulo, canal y dibujo de conexión. La finalidad es localizar el documento que contiene el detalle físico aprobado. La lista no debería inventar bornes cuando aún falta el plano ni reproducir parcialmente un conexionado que después cambie en otro archivo.
El manual EJX/EJA-E muestra que la conexión depende de configuración y opciones. La recomendación documental es conservar el vínculo con el diseño correspondiente. Si cambia la variante de un equipo, revise las filas afectadas y las referencias al dibujo para evitar una lista aparentemente completa pero incoherente.
Para datos por comunicación, identifique el equipo de origen y la referencia al mapa específico. Si se utiliza una pasarela, el proyecto debe documentar esa relación donde corresponda. Una dirección aislada no informa qué variable representa ni cómo debe interpretarse.
Los destinos pueden ser varios
Una señal puede utilizarse para control, visualización y registro. La lista puede remitir a esos destinos o a un documento que los describe. No conviene asumir que aparecer en una pantalla significa que también se conserva en un histórico o que participa en una alarma.
Como ejemplo hipotético, una presión adquirida por un canal analógico se vincula a una variable del controlador y a una indicación en una HMI. Si se solicita una tendencia, agregue el requisito o referencia que lo define. El ejemplo no asigna canales reales ni una frecuencia de adquisición.
La distinción entre dato disponible y función implementada permite revisar el alcance con el usuario. Si una información solo se necesita para diagnóstico, su destino puede diferir de una variable utilizada por una secuencia. Esa decisión pertenece a la especificación funcional.
Revise duplicados con criterio documental
Dos filas pueden coincidir en descripción y ser puntos diferentes; también pueden representar accidentalmente el mismo canal. Para revisar, compare identificación, origen, destino y asignación física. No elimine filas solo porque sus nombres se parecen.
Un canal asignado a más de una señal, una magnitud sin unidad o un dato comunicado sin mapa son observaciones que necesitan aclaración. Registre qué documento resolverá cada una y quién lo valida. La revisión puede realizarse sobre una copia controlada de la lista sin intervenir sobre el sistema.
Los conteos por tipo sirven para coordinar recursos cuando la clasificación está acordada. Debe quedar claro si incluyen reservas y qué versión describen. No se propone un porcentaje universal de reserva ni una cantidad de canales por instrumento.
Controle cambios que afectan distintas especialidades
Una modificación de rango puede afectar interpretación y visualización; una modificación de tipo de señal puede afectar hardware y planos. La lista debería identificar el cambio y remitir a los documentos revisados. Su fecha, autor y estado facilitan distinguir una propuesta de una asignación aprobada.
En un proyecto de Paraguay, los intercambios entre ingeniería, programación y compras pueden utilizar herramientas distintas. La propuesta es conservar una versión de referencia y definir cómo llegan a ella las respuestas. Compartir archivos con nombres semejantes sin estado de revisión puede dejar a cada área trabajando sobre datos diferentes.
Al cerrar una etapa, identifique las filas confirmadas y los pendientes que continúan abiertos. Un archivo sin celdas vacías no demuestra que todos sus datos fueron validados. El estado de cada decisión debe permitir reconocer quién la respaldó.
Prepare la lista para las pruebas y el mantenimiento
Una lista coherente permite vincular un punto a la evidencia de prueba correspondiente. Esa referencia debe indicar qué se evaluó, en qué versión y con qué resultado. El listado por sí solo no acredita que la señal haya sido probada ni que una función completa opere correctamente.
Para la entrega, conserve las referencias al conjunto documental vigente y a las modificaciones aceptadas. Mantenimiento podrá utilizarlo para identificar la señal y localizar su detalle sin deducirlo desde una pantalla. El artículo ofrece una estructura propia para esa trazabilidad; no reproduce una plantilla normativa ni establece códigos obligatorios.
Revisión antes de implementar
Como práctica documental propuesta, marque duplicados, canales sin asignar, unidades ausentes y puntos pendientes. Registre quién valida cada dato y las modificaciones que afectan hardware, programa o pruebas. La lista debe conservarse junto con la versión del proyecto que describe.
Para coordinar un proyecto en Paraguay, puede presentar este inventario a Ingeniería y Proyectos y consultar la integración de automatización de TECNICAT. El archivo de Ingeniería y proyectos reúne contenidos sobre definición y documentación.
Fuentes técnicas
- EJX-GS — Yokogawa Electric Corporation. EJX110A Differential Pressure Transmitter — GS 01C25B01-01EN. 41.ª edición, junio de 2026. Modelo/alcance: EJX110A; opciones según código. Apartado: pp. 1, 3–5 y Model and Suffix Codes. Consulta: 2026-10-02.
- EJX-IM — Yokogawa Electric Corporation. EJX and EJA-E Series — Installation Manual, IM 01C25A01-01EN. 19.ª edición, junio de 2026. Modelo/alcance: Familias EJX/EJA-E incluidas en el manual. Apartado: §1.1; §2.2–2.3; §3–4; §5.1–5.3 y §5.6, pp. 21–24 y 31. Consulta: 2026-10-02.
- NIST — National Institute of Standards and Technology. Guide to Operational Technology (OT) Security — NIST SP 800-82 Rev. 3. Edición final, septiembre de 2023; Rev. 4 en borrador público al consultar, no sustituye esta final. Modelo/alcance: Sin modelo; arquitectura OT. Apartado: §2.3, pp. 10–12; §2.3.2 SCADA Systems; §2.3.4 PLC-Based Topologies; glosario HMI/PLC; §6.2.4.2–6.2.4.3, pp. 111–113 (PDF 128–130), configuración y respaldos. Consulta: 2026-10-02.
Comentarios sobre este artículo
Comparta una pregunta u observación relacionada con el tema.