Una URS mal definida no se corrige con más programación ni con un PLC de mayor capacidad. Se convierte en cambios de alcance, decisiones tardías, pruebas extensas y riesgos durante la puesta en marcha. Saber cómo elaborar URS permite traducir una necesidad operativa de planta en requisitos verificables para ingeniería, automatización, instrumentación, sistemas eléctricos y validación.
La URS, o User Requirements Specification, establece qué debe lograr el sistema desde la perspectiva del usuario y del proceso. No describe todavía cómo se programará el PLC, qué marca de instrumento se instalará ni la lógica detallada de una secuencia. Es el documento que alinea a operaciones, mantenimiento, ingeniería, calidad, TI industrial y proveedores antes de desarrollar la especificación funcional, la arquitectura de control y la ingeniería de detalle.
Qué debe resolver una URS industrial
El punto de partida no es una lista de equipos. Es un problema de proceso u operación claramente identificado: un sistema de control obsoleto, una ampliación de capacidad, falta de trazabilidad de lotes, paros por fallas recurrentes, incorporación de un skid nuevo o migración de una red industrial.
Una buena URS define el resultado esperado y las restricciones para alcanzarlo. Por ejemplo, en lugar de indicar que se requiere una pantalla HMI Siemens, debe establecer que el operador necesita visualizar estados, alarmas, variables críticas y tendencias históricas desde una estación de operación, con niveles de acceso acordes con su función. La selección de WinCC, otro HMI o la arquitectura cliente-servidor se evaluará después, durante el diseño.
Esta distinción evita dos problemas frecuentes. El primero es limitar la solución antes de analizar la infraestructura existente y los riesgos técnicos. El segundo es dejar requisitos críticos implícitos, como la retención de datos, la disponibilidad de refacciones, el acceso remoto autorizado o la compatibilidad con una red PROFINET instalada.
Cómo elaborar URS: proceso de ingeniería
Elaborar una URS requiere entrevistas estructuradas, recorridos de campo, revisión documental y decisiones interdisciplinares. El documento debe construirse con información de quienes operan y mantienen el proceso, no únicamente a partir de una solicitud de compra o una cotización previa.
Delimite el alcance físico y funcional
Defina qué áreas, equipos, señales e interfaces están incluidos. Identifique los límites de batería del proyecto: dónde inicia y termina la responsabilidad del sistema, qué equipos permanecerán sin modificación y qué sistemas de terceros deberán intercambiar datos.
En una modernización de PLC, por ejemplo, el alcance puede considerar tableros existentes, tarjetas de I/O, motores, variadores, instrumentos de campo, estaciones HMI, SCADA, redes PROFIBUS o PROFINET y comunicación con MES o historiador. También debe declarar exclusiones. Si la sustitución de cableado de campo no forma parte del proyecto, debe indicarse expresamente; de lo contrario, esa condición puede convertirse en una desviación durante el I/O Check.
El alcance funcional debe describir modos de operación, como automático, manual, mantenimiento y paro seguro. Para un sistema de bombeo, señale las condiciones de arranque, paro, permissivos, interlocks, alarmas, alternancia, operación local/remota y respuesta ante pérdida de comunicación. Aún no es necesario definir cada red de escalera o bloque de función, pero sí el comportamiento que la planta espera.
Convierta necesidades en requisitos verificables
Cada requisito debe ser claro, único, medible y comprobable. La redacción útil sigue una estructura simple: el sistema debe realizar una acción, bajo una condición definida, con un resultado observable.
Una frase como “el sistema debe ser fácil de usar” no puede probarse de forma objetiva. Es preferible especificar que la HMI debe mostrar en una misma pantalla el estado de cada equipo, los permissivos activos y la causa de paro; que debe permitir consultar alarmas por fecha, prioridad y área; y que los usuarios de operación no podrán modificar parámetros de mantenimiento sin autenticación.
Asigne un identificador a cada requisito, por ejemplo URS-OP-025 o URS-ALM-010. Esta codificación facilita la trazabilidad entre la URS, la especificación funcional, listas de I/O, diagramas eléctricos, programación PLC/HMI, protocolos FAT, SAT y documentación As-Built. Cuando un requisito cambia, el equipo puede identificar con precisión qué documentos, pruebas y disciplinas deben actualizarse.
Documente el proceso, no solo la automatización
La URS debe incluir la información de proceso que condiciona el diseño. Revise P&ID disponibles, filosofía de control, diagramas de flujo, hojas de datos, diagramas causa-efecto, secuencias operativas y registros de fallas. Si esa información no existe o está desactualizada, documente las brechas y defina cómo se validarán durante la ingeniería.
Para cada variable crítica, indique rangos operativos, unidades, exactitud requerida cuando aplique, condiciones de alarma y consecuencias de una medición errónea. En un lazo PID de temperatura, no basta con pedir “control automático”. Conviene definir el rango del transmisor, punto de control, límites alto y bajo, acción ante falla de sensor, permisos para cambiar el setpoint y necesidad de registrar tendencias.
También deben quedar explícitos los requerimientos de desempeño. Estos pueden abarcar tiempos máximos de respuesta, capacidad de producción, número estimado de señales, disponibilidad requerida, tiempo aceptable de recuperación posterior a una falla y crecimiento futuro. El nivel de detalle depende del riesgo: una estación local aislada no exige los mismos criterios que un SCADA que controla una línea completa.
Incluya seguridad, mantenimiento e integración desde el inicio
La seguridad operacional no debe agregarse al final como una nota general. La URS debe identificar paros de emergencia, funciones instrumentadas de seguridad si existen, estados seguros ante pérdida de energía o comunicación, alarmas críticas y responsabilidades de operación. La definición final deberá apegarse al análisis de riesgos y a las normas aplicables al proyecto, como IEC, ISA, NOM o NFPA.
Desde mantenimiento, especifique necesidades concretas: diagnóstico de fallas, identificación de instrumentos, acceso controlado a parámetros, disponibilidad de respaldos, documentación de redes y compatibilidad con refacciones o plataformas ya instaladas. En una planta con SIMATIC S7 y TIA Portal, conservar la mantenibilidad puede ser un criterio tan relevante como el costo inicial de la migración.
La integración requiere el mismo rigor. Defina qué información se intercambiará con equipos o sistemas externos, quién es responsable de cada interfaz, el protocolo esperado cuando ya esté condicionado por la infraestructura y qué debe ocurrir si la comunicación se pierde. Para una conexión OPC UA, Ethernet/IP, Modbus TCP, PROFIBUS o PROFINET, indique las variables, frecuencia de actualización, propiedad de los datos y manejo de errores. Pedir solamente “integración con SCADA” deja demasiadas decisiones abiertas.
Requisitos regulatorios y de datos
En sectores farmacéutico, alimentos, bebidas o procesos sujetos a auditoría, la URS debe incorporar requisitos de calidad y trazabilidad desde su emisión. Cuando aplique, pueden incluirse perfiles de usuario, firmas electrónicas, audit trail, gestión de recetas, retención de registros, respaldo y restauración de datos, así como controles para cambios de parámetros críticos.
GAMP 5 y 21 CFR Part 11 no se resuelven por instalar un software determinado. Requieren definir el uso previsto, evaluar riesgos, documentar pruebas y demostrar que las funciones configuradas responden al requisito aprobado. Si un sistema debe registrar cambios de setpoint, la URS debe indicar qué variables están sujetas a registro, qué evento debe capturarse, qué datos debe contener el registro y quién puede revisarlo.
No todos los proyectos requieren el mismo nivel documental. Una actualización de variador para un transportador puede requerir una URS acotada; una línea de producción con trazabilidad de lote necesitará mayor profundidad, revisión de calidad y protocolos formales de prueba. Ajustar el esfuerzo al riesgo mantiene el documento útil y controlable.
Valide la URS antes de liberar ingeniería
Una URS debe revisarse en conjunto con operaciones, mantenimiento, ingeniería, seguridad, calidad y tecnología de información cuando intervenga infraestructura de datos. La revisión busca contradicciones, omisiones y requisitos que no pueden verificarse. También confirma que las condiciones actuales de planta coinciden con los documentos disponibles.
Antes de aprobarla, compruebe que cada requisito tiene un responsable de aceptación y un método de verificación. Algunos se demostrarán durante FAT, como secuencias de PLC, alarmas o pantallas HMI. Otros requieren validación en sitio durante SAT, I/O Check o comisionamiento, especialmente los relacionados con instrumentos, motores, comunicaciones de campo y comportamiento real del proceso.
La URS debe controlarse como documento vivo, con revisión, fecha, aprobadores e historial de cambios. Un cambio posterior no es necesariamente un error, pero debe evaluarse por su impacto en costo, plazo, seguridad, programación, tableros, procura y pruebas. Esta disciplina evita que los acuerdos verbales lleguen tarde al taller o a la puesta en marcha.
Errores que comprometen el proyecto
El error más costoso es copiar una URS anterior sin validar el proceso actual. Las plantas cambian: se sustituyen equipos, se modifican capacidades, aparecen redes no documentadas y se adoptan prácticas de operación que no figuran en los planos. Una base documental puede acelerar el trabajo, pero debe verificarse en campo.
También es riesgoso confundir la URS con la especificación funcional. La URS establece la necesidad y los criterios de aceptación; la especificación funcional explica cómo el sistema atenderá esos requisitos. Mezclarlas dificulta la revisión con usuarios y reduce la posibilidad de comparar alternativas de ingeniería.
Finalmente, no conviene llenar el documento con frases genéricas como “cumplir normas aplicables” o “proveer alta disponibilidad” sin definir qué significan para el proyecto. La ingeniería solo puede diseñar, probar y aceptar aquello que está delimitado.
Una URS bien elaborada no sustituye la ingeniería de detalle, pero le da dirección y evidencia. Para ProAIC Automatización, es el punto donde la necesidad de planta se convierte en un alcance técnico que puede diseñarse, integrarse, probarse y ponerse en marcha con trazabilidad. Cuando operaciones y proveedores comparten ese mismo criterio desde el inicio, la puesta en marcha deja de ser el momento para descubrir requisitos y se convierte en la confirmación de que el sistema responde al proceso.
