Un skid puede superar la demostración en fábrica y seguir siendo inadecuado para la planta. El controlador ejecuta la secuencia, pero una interrupción deja incompleto el registro del lote; un operador modifica un parámetro sin una razón trazable; el servidor de sustitución no recupera la receta aprobada. Son fallos de requisitos antes de convertirse en hallazgos de validación. La especificación de requisitos de usuario, o URS, debe describir el resultado de fabricación, las condiciones de fiabilidad y la evidencia necesaria para aceptarlo.
Este artículo aborda la URS de ingeniería para PLC, DCS, SCADA, historian, MES y sus interfaces. Ayuda a proceso, operaciones, automatización, calidad e IT/OT a acordar qué debe conseguir el sistema antes de que el proveedor concrete el diseño. La arquitectura y la estrategia de validación siguen dependiendo del uso previsto y del contexto de la planta.
Definir el uso previsto y los límites
Describa familias de productos, etapas, modos de operación y decisiones apoyadas. Un controlador de temperatura y un historian utilizado para investigar excursiones tienen usos distintos, aunque manejen la misma medida. Identifique si cada función controla el proceso, informa, genera un registro, autoriza una actividad o transfiere información. Esa finalidad determina los controles y la evidencia de aceptación.
Separe límites físicos y lógicos. Los primeros incluyen instrumentos, entradas y salidas, controladores, estaciones, servidores y redes. Los segundos incluyen recetas, cálculos, permisos, interfaces, transformaciones y responsabilidades. Un servicio de identidad externo al suministro puede seguir siendo una dependencia del sistema cualificado. Asigne quién lo proporciona, configura, comprueba y mantiene.
Indique las exclusiones y su responsable receptor. Excluir la integración MES no resuelve cómo operará un skid que necesita una respuesta MES para cerrar una operación. Defina el comportamiento aprobado antes de disponer de la interfaz y las condiciones de su introducción posterior.
Separar resultados y decisiones de diseño
Un requisito expresa una necesidad verificable. Pedir servidores redundantes identifica una solución; pedir continuidad de funciones definidas ante un fallo de servidor, preservando los registros confirmados, describe un resultado. La redundancia puede ser la solución elegida, pero todavía habrá que justificar su alcance, conmutación y fallos restantes.
Algunas restricciones técnicas son legítimas: plataforma soportada por la planta, arquitectura de red aprobada, protocolo existente o competencias de mantenimiento disponibles. Identifíquelas como restricciones y explique su origen. Distinga obligaciones, preferencias y opciones futuras para que las ofertas no conviertan deseos secundarios en prioridades mientras omiten dependencias críticas.
Asigne a cada requisito un identificador estable, responsable y vía de aceptación. Evite reunir acceso, copias, firmas y alarmas en una sola afirmación de conformidad. Cada obligación debe poder evaluarse con criterios propios y una relación clara con la necesidad que pretende resolver.
Especificar control y operación anormal
Defina variables controladas, salidas manipuladas, rangos, estados y transiciones. La URS no necesita reproducir el código del PLC, pero sí explicar inicio, pausa, retención, aborto, reinicio y finalización. Determine quién puede solicitar cada transición, qué condiciones deben confirmarse y cómo se reconcilia una operación interrumpida.
Distinga una condición permisiva, un enclavamiento y una alarma que exige respuesta del operador. Una alarma no es automáticamente una función protectora. Tampoco una confirmación HMI demuestra que la válvula se movió físicamente. Los comandos relevantes necesitan realimentación, tratamiento de discrepancias y registros que expliquen el resultado real.
Diseñe expresamente los modos manuales y degradados. Identifique protecciones conservadas, restricciones y controles adicionales. La pérdida de comunicación no justifica una instrucción genérica de pasar a manual. La respuesta depende del estado, del equipo y de los peligros. Analice por separado energía, calidad de medida, comunicaciones y servicios auxiliares.
Asignar recetas, parámetros y aprobaciones
Separe la receta maestra aprobada de la receta de control instanciada para un lote. Una fórmula aporta valores, pero no necesariamente toda la estructura procedimental y de equipos. Determine dónde se crea, aprueba, descarga y ejecuta cada elemento. MES puede coordinar el flujo mientras el controlador ejecuta fases, siempre que la distribución sea explícita.
Especifique rangos permitidos, autoridad de cambio, versión efectiva y tratamiento de lotes en curso. Considere descargas incompletas, incompatibles con el equipo o anteriores a la versión aprobada. Defina nueva aprobación, nueva instancia o gestión de excepciones. Los valores proceden del conocimiento del proceso y su estrategia de control, no de parámetros predeterminados del proveedor.
En aplicaciones CIP y SIP, distinga la ejecución del ciclo de la evidencia de cumplimiento de sus criterios. Completar una secuencia no demuestra por sí solo eficacia de limpieza o esterilización. La automatización conserva la información necesaria para la evaluación correspondiente.
Identificar registros antes de elegir almacenamiento
Relacione cada clase de datos con su uso y responsable: medidas originales, calidad, tiempo, unidades, identificadores de lote, versiones de receta, acciones, excepciones, cálculos y decisiones de revisión. Un valor mostrado puede ser transitorio. Un registro GMP necesita contexto para reconstruir la actividad. Determine la fuente autorizada y cómo se identifican otras copias.
Configure adquisición y compresión según los eventos que deban distinguirse. Una ejecución rápida del controlador no garantiza igual resolución histórica. Compruebe si muestreo, agregación o banda muerta pueden ocultar una excursión breve. Defina valores ausentes, tardíos, inválidos y recuperados. No existe un intervalo de muestreo ni un plazo de conservación universal para todos los casos.
Distinga audit trail, registro de eventos y registro de alarmas. Identifique cambios y eliminaciones relevantes, identidad, cronología, motivo cuando corresponda, acceso de revisión y exportación. Activar una función denominada audit trail no demuestra cobertura suficiente de aprobaciones, cambios de configuración o acciones privilegiadas.
Responsabilizar las interfaces de la transacción
Para cada interfaz, defina propietarios emisor y receptor, identificadores, significado de campos, unidades, versiones, marcas temporales y estados de transacción. Un acuse de red puede confirmar entrega al servicio sin confirmar aceptación de una instrucción, resultado o consumo. Especifique la confirmación funcional y qué ocurre si falta o es negativa.
Diseñe repetición y duplicados conjuntamente. Tras una interrupción, el emisor puede ignorar si el mensaje ya tuvo efecto. Repetir sin identidad estable puede duplicar consumos o acciones. Defina cómo detectar omisiones, duplicados y estados contradictorios, quién los resuelve y cómo comprobar recuperación a través del recorrido completo.
OPC UA, API y middleware son opciones de implementación. Su disponibilidad no demuestra equivalencia semántica. Defina contrato de datos y configuración de seguridad independientemente de una declaración comercial de compatibilidad con protocolos estándar.
Relacionar cada requisito con evidencia concreta
La siguiente matriz es un ejemplo original de ingeniería. Sus criterios deben adaptarse al proceso aprobado y a la evaluación de riesgos; no constituyen especificaciones universales.
| Requisito | Razón | Impacto GMP | Riesgo | Criterio de aceptación | Verificación | Evidencia |
|---|---|---|---|---|---|---|
| Ejecutar la versión aprobada | Evitar parámetros no autorizados | Consistencia del proceso | Receta obsoleta en producción | Solo inicia una versión elegible y queda vinculada al lote | Probar versiones aprobadas, obsoletas e incompatibles | Configuración, ejecución y excepciones |
| Conservar identidad en reintentos | Evitar doble aplicación | Genealogía y cantidades | El mensaje repetido duplica consumo | La repetición produce un único efecto y los conflictos son visibles | Interrumpir respuesta después de confirmar el receptor | Registros de ambos sistemas y conciliación |
| Recuperar el registro definido | Mantener reconstrucción | Revisión y conservación | Faltan metadatos tras restaurar | El conjunto recuperado es completo, legible y asociado correctamente | Restaurar en entorno autorizado | Informe de recuperación y aceptación del revisor |
La trazabilidad sirve cuando enlaza con evidencia real. Distinga revisión, inspección, análisis y ensayo. Si una prueba cubre varios requisitos, explique la cobertura sin multiplicar guiones idénticos. Si queda un requisito sin verificar, mantenga visible la brecha hasta la decisión de liberación.
Coordinar acceso, cronología y seguridad OT
Defina roles a partir de tareas reales: operación, creación y aprobación de recetas, mantenimiento, administración y revisión. Identifique privilegios incompatibles y acceso de emergencia controlado. El acceso remoto del proveedor necesita solicitud, autorización, conexión, supervisión apropiada, registro y cierre. No puede tratarse como una cuenta ordinaria de operador.
Describa fuente horaria, dependencias de sincronización, representación de zona y comportamiento ante pérdida de sincronización. Distinga momento de ocurrencia y recepción, conservando ambos cuando sean relevantes durante almacenamiento temporal y reenvío. Una marca temporal técnica necesita reglas de interpretación para aportar cronología GMP.
Utilice inventario y riesgo OT para definir segmentación, comunicaciones permitidas, configuración segura, evaluación de parches y recuperación. Los controles de seguridad requieren valorar disponibilidad y limitaciones del equipo. A su vez, el estado validado no justifica dejar una vulnerabilidad conocida sin una gestión responsable.
Definir disponibilidad, recuperación y entrega
Disponibilidad significa continuidad del servicio; recuperación significa volver a un estado aceptable tras una interrupción. Comprar hardware redundante no demuestra ninguna de las dos. Identifique dependencias comunes de energía, almacenamiento, identidad y red. Determine qué pérdidas permiten continuar, requieren retener o exigen una parada controlada.
Separe copia de seguridad, archivo y recuperación ante desastres. La copia permite restaurar; el archivo mantiene registros recuperables; la recuperación coordina infraestructura, aplicaciones, datos, personas y reinicio. Derive tiempos y pérdida aceptable de datos de las consecuencias del proceso y continuidad. Incluya configuración, certificados, licencias, recetas y dependencias.
Exija una entrega mantenible: código y configuración aprobados, herramientas, límites de soporte, versiones compatibles, información de obsolescencia, repuestos y procedimientos de cambio. La evidencia de restauración y actualización debe existir antes de que desaparezca el equipo original del proyecto.
Elegir una estrategia de assurance proporcionada
[REQUISITO REGULATORIO] Para actividades sujetas a GMP de la UE, el Anexo 11 relaciona requisitos de usuario, impacto GMP, riesgo documentado y trazabilidad del ciclo de vida. El Anexo 15 aborda cualificación y validación. Traduzca estas obligaciones en evidencia pertinente, sin imponer una cantidad predeterminada de documentos. Los textos operativos siguen diferenciados de los borradores de consulta de 2025.
[GUÍA] GAMP 5, segunda edición, apoya un enfoque basado en riesgo. La guía FDA CSA final de febrero de 2026 trata software de producción y del sistema de gestión de calidad de dispositivos médicos; no sustituye de forma general la CSV farmacéutica. [NORMA] ASTM E2500-25 ofrece un marco de verificación basado en ciencia y riesgo. Justifique métodos sin presentar guías voluntarias como legislación.
[RECOMENDACIÓN GUIDEGXP] Acuerde qué evidencia del proveedor puede reutilizarse, cómo se acepta y qué brechas locales deben cerrarse. FAT puede demostrar funciones configuradas; SAT examina instalación e interfaces locales. Sus nombres no establecen cualificación automáticamente. La liberación identifica configuración, defectos resueltos, riesgos residuales justificados, responsables preparados y acciones pendientes con decisión explícita.
Revisar la URS mediante un fallo realista
Imagine un recipiente cuyo controlador continúa mientras falla la conexión al historian. Operaciones quiere continuidad, calidad necesita evidencia completa e IT propone reintentos. Recorra la interrupción desde la medida hasta la revisión. Determine qué se almacena temporalmente, cómo se vigila capacidad, cómo se conserva tiempo y calidad, qué ocurre al agotarse y cómo se concilian los datos recuperados.
El resultado útil es un conjunto de requisitos y escenarios relacionados. Escribir únicamente que no debe perderse información deja el diseño abierto. El análisis debe justificar si procede parar, continuar con registros alternativos aprobados o retener en un estado definido. La decisión pertenece al conocimiento del proceso y al riesgo de la planta, con aportación del proveedor.
- ¿Cada requisito crítico responde a una necesidad de fabricación o registro?
- ¿Están definidos operación normal, fallos, modo manual y recuperación?
- ¿Las interfaces confirman la transacción prevista?
- ¿Puede la planta obtener, revisar, restaurar y conservar la evidencia?
- ¿Están claras aceptación, propiedad y soporte durante el ciclo de vida?
Desarrolle estas decisiones desde Automation & Digital Systems. La URS está preparada para aprobación cuando el equipo puede explicar tanto el resultado requerido como la forma de demostrar que se ha conseguido.
Referencias primarias y estado
Revisado el 23 de septiembre de 2026: EudraLex, volumen 4, Anexo 11 y capítulo 4 de 2011 y Anexo 15; consulta europea de 2025, borradores distintos de requisitos vigentes; GAMP 5, segunda edición de julio de 2022; FDA CSA final de febrero de 2026; ASTM E2500-25; NIST SP 800-82r3. La revisión 4 de NIST sigue siendo un borrador en esta fecha. Las normas se utilizan según alcance e información del editor, sin reproducir contenido protegido.
