A filtro prensa de membrana Un sistema que supere todas las comprobaciones de automatización en las instalaciones del proveedor puede llegar a la obra con alarmas que nunca se activan, enclavamientos vinculados a señales que aún no existen y una secuencia de control que nadie ha contrastado con la planta instalada. Decidir qué abarca la prueba FAT, qué debe abarcar en su lugar la prueba SAT y qué aspectos del rendimiento del pastel o del filtrado no demuestran ninguna de las dos pruebas determina si las pruebas de aceptación protegen realmente el proyecto o si solo generan papeleo.
Ámbito de aceptación propio de las pruebas de automatización
Las pruebas de aceptación de la automatización tienen como objetivo confirmar que un sistema de control funciona según lo previsto en su diseño, dentro de los límites de la configuración de prueba disponible en ese momento. Ese alcance es más limitado de lo que parece. Un entorno de fábrica puede demostrar la lógica de secuencias, el comportamiento de las alarmas y las respuestas de los enclavamientos que dependen únicamente de la plataforma de automatización y de las entradas que pueda simular el banco de pruebas. No puede demostrar nada que dependa de equipos, cableado o condiciones del proceso que no existan hasta que la unidad llegue a la planta. Por eso, la aceptación de la automatización se divide convencionalmente en una fase de fábrica y una fase de planta, con una prueba de integración en planta específica cuando el proyecto implica múltiples sistemas interconectados.
La consecuencia práctica para un comprador es que ni la FAT ni la SAT son una simple lista de comprobación; cada una de ellas está limitada por lo que está físicamente disponible en el momento de realizar la prueba. Una secuencia que se comporte correctamente con entradas simuladas en una prueba de fábrica no garantiza que dicha secuencia se comporte correctamente una vez que reciba señales reales procedentes de equipos de alimentación instalados aguas arriba o de equipos de transporte instalados aguas abajo. Cuando la automatización de un proyecto depende en gran medida de las interfaces con otros sistemas instalados, considerar la FAT como prueba suficiente de que el sistema está listo crea una laguna que solo se pone de manifiesto tras la instalación, momento en el que corregirla requiere más coordinación de lo que habría costado señalar esa dependencia desde el principio.
Esta distinción es especialmente importante en el caso de una prensa de filtro de membrana, ya que su automatización suele coordinar varias funciones —secuencia de alimentación, sincronización del prensado de la membrana, desplazamiento de las placas, lavado de las telas y descarga de la torta—, algunas de las cuales pueden ponerse a prueba de forma significativa en un banco de pruebas, mientras que otras no pueden evaluarse plenamente hasta que la prensa esté instalada mecánicamente y conectada a sus suministros reales de aire, agua y electricidad. Comisión Electrotécnica Internacional 62381, la norma que regula las pruebas FAT, SAT y de integración in situ para la automatización de la industria de procesos, considera que se trata de una cuestión que debe acordarse específicamente para cada proyecto: qué funciones se prueban, dónde y según qué lista de comprobación, es algo que definen las partes del proyecto y no algo inherente al equipo. Ese acuerdo debe existir antes de que comience cualquiera de las pruebas, y no improvisarse durante las mismas.
Las preguntas que conviene plantear en la fase de presupuesto o de contrato son las siguientes: ¿qué funciones de automatización propone el proveedor verificar en la prueba FAT?, ¿cuáles se aplazan hasta la prueba SAT? y ¿hay alguna función que dependa de una interfaz que aún no se haya instalado en ninguno de los dos momentos? En tal caso, es necesario realizar una prueba específica para ella, en lugar de dar por sentado tácitamente que ya está cubierta.
Pruebas de fábrica de lógica, alarmas, enclavamientos y registros
| Área de automatización | Comprobación de FAT | Límite de la prueba |
|---|---|---|
| Lógica de secuencias | Demostrar la lógica de secuencia acordada en el entorno de pruebas de fábrica disponible | Registra únicamente lo que la configuración disponible pueda demostrar |
| Alarmas | Demostrar las funciones de alarma acordadas en el entorno de pruebas de fábrica disponible | Las entradas de alarma específicas de cada emplazamiento se mantienen para las pruebas in situ |
| Enclavamientos | Demostrar las funciones de enclavamiento acordadas en el entorno de pruebas de fábrica disponible | Los enclavamientos que dependen de equipos o señales instalados se mantienen para las pruebas in situ |
| Interfaces | Mostrar las interfaces acordadas que están disponibles en la configuración de fábrica | Las interfaces instaladas aguas arriba y aguas abajo se mantienen para SAT o para una prueba de integración con nombre propio |
| Registros de automatización | Confirmar los registros acordados generados por las funciones de automatización demostradas | Conservar los resultados en el registro FAT; esto no determina el rendimiento del proceso. |
El trabajo de FAT se limita a lo que el banco de pruebas de fábrica puede generar como entradas y a lo que puede observar como salidas. La lógica de secuencia puede verificarse frente a condiciones simuladas que representen las etapas de un ciclo. Las funciones de alarma pueden verificarse forzando las condiciones que se supone que deben activarlas, en la medida en que el banco de pruebas pueda generar dichas condiciones de forma artificial. Los enclavamientos pueden verificarse de la misma manera, siempre que la condición de activación del enclavamiento no dependa de un estado físico que solo exista una vez que la prensa esté instalada y conectada a sus servicios reales.
El límite que importa en este caso no tiene que ver con la calidad de la lógica de automatización, sino con lo que el entorno de pruebas puede poner realmente a prueba. Un enclavamiento diseñado para impedir el movimiento de una placa durante una condición de inseguridad puede demostrarse en un entorno de fábrica si dicha condición puede simularse eléctricamente. Un enclavamiento que dependa de una señal procedente de un equipo de seguridad instalado in situ, o de un servicio que no se conecte hasta la puesta en servicio, no puede demostrarse de forma significativa en la prueba FAT, independientemente de lo bien que esté escrita la lógica en sí. Considerar que ese enclavamiento está “probado” porque su código superó una comprobación en fábrica, sin tener en cuenta que su condición de activación real nunca se dio, crea una falsa sensación de exhaustividad.
Es aquí también donde los registros de automatización merecen especial atención. Una FAT que dé resultado “aprobado” en la lógica de secuencias, las alarmas y los enclavamientos también debe generar un registro de exactamente lo que se ha demostrado y en qué condiciones simuladas, ya que ese registro es lo que determina si una función concreta debe volver a someterse a pruebas in situ o si puede considerarse cerrada. Un registro de FAT que solo indique «aprobado» sin especificar qué se ha simulado impide que el proyecto pueda determinar posteriormente qué deficiencias, si las hubiera, se han trasladado a la fase siguiente.
Los compradores que se preparen para la prueba FAT deben confirmar, antes de la fecha de la prueba, qué enclavamientos y alarmas concretos se van a someter a prueba con entradas simuladas en lugar de reales, ya que una aprobación de fábrica basada en una entrada simulada indica algo cierto, pero con un alcance más limitado de lo que podría parecer. Cuando el Configuración de una prensa de filtro totalmente automática implica pasos de manipulación automatizados adicionales con respecto a sus equivalentes manuales o semiautomáticos; ese mayor alcance de la automatización aumenta el número de funciones cuya demostración en fase de fabricación depende de la fidelidad de la simulación, lo que hace que el acuerdo previo a la prueba sobre lo que se está simulando sea aún más importante, y no menos.
Pruebas in situ de los servicios instalados y las señales de interfaz
| Dependencia del emplazamiento | Qué puede comprobar el SAT | Límites del ámbito |
|---|---|---|
| Servicios públicos instalados | Funciones de automatización que dependen de los servicios disponibles en el lugar de instalación | Realiza la prueba únicamente cuando la instalación de servicios de la obra correspondiente esté disponible. |
| Cableado de la instalación | Funciones que dependen de que el cableado y las señales de la instalación estén completados | El resultado se aplica al cableado instalado y a las señales comprobadas. |
| Interfaces de entrada y de salida | Comportamiento de automatización acordado en todas las interfaces de los equipos instalados | Indica por separado cualquier prueba de integración del sitio de mayor alcance |
| Condiciones reales de funcionamiento | Funciones de automatización que solo pueden demostrarse en condiciones reales de funcionamiento en la planta | El resultado determina la función de control sometida a prueba, no el rendimiento del proceso. |
| Integración del sitio web | Funciones de integración específicas del proyecto identificadas para una prueba independiente | Mantén el ámbito de SIT de forma explícita, en lugar de tratarlo como una extensión sin nombre de SAT |
El SAT existe precisamente porque algunas funciones de automatización no pueden evaluarse de forma fiable hasta que el equipo esté instalado, cableado y conectado a los servicios que realmente va a utilizar. Una función que depende de la presión del aire comprimido instalada, del comportamiento real del suministro hidráulico o de las señales procedentes de equipos situados aguas arriba y aguas abajo no es algo que pueda sustituir un banco de pruebas de fábrica, por muy bien que simule la entrada esperada. La prueba in situ es donde se confirma la respuesta del sistema de control ante condiciones reales —y no ante aproximaciones modelizadas de las mismas—.
Esto plantea un punto de decisión concreto para el equipo del proyecto: qué funciones quedaron sin probar, o solo se probaron parcialmente, en la FAT porque sus condiciones de activación no existían en la fábrica, y si el alcance de la SAT cubre explícitamente esas funciones ahora que las condiciones sí existen. Si el informe de la FAT dejaba claro qué se simuló, esta correspondencia es sencilla. Si no fue así, el proyecto corre el riesgo de dar por sentado que una función está probada cuando en realidad solo se probó en condiciones artificiales que pueden no coincidir con la realidad de la instalación.
Site wiring introduces its own category of risk. A control sequence that is logically correct can still fail at commissioning if the physical wiring does not match the design intent — a wrong polarity, a swapped terminal, a sensor placed differently than assumed. SAT is where this class of problem surfaces, because it is testing the installed signal path rather than a simulated one. This is also why SAT results are specific to the installed wiring and the signals tested at that time; a SAT pass does not generalize to a hypothetical rewiring or a different signal configuration introduced later.
Interfaces with upstream and downstream equipment deserve particular attention because they frequently involve more than one supplier’s control system. Where a membrane filter press is one part of a larger line — receiving slurry from an upstream process, discharging cake to downstream handling — the automation behavior across that boundary is not fully owned by either supplier’s individual scope. This is the condition under which IEC 62381’s separate site integration test category becomes relevant: rather than treating cross-system behavior as an informal extension of SAT, the project should name it as its own test with its own agreed scope, inputs, and acceptance basis. Leaving it unnamed does not make the risk disappear; it just means no one has explicitly agreed who is responsible for resolving it when it appears.
Process-Performance Checks Kept Separate from Control Acceptance
| Acceptance track | What it checks | Agreed basis needed | What a pass establishes |
|---|---|---|---|
| Automation FAT or SAT | Sequence logic, alarms, interlocks, interfaces, and automation records | Agreed automation functions, test activities, responsibilities, and project-specific checks | The tested control functions passed within the available factory setup or installed site conditions; it does not establish process performance |
| Process-performance testing | Cake condition, filtrate quality, cycle behavior, and throughput | Agreed feed, sampling, methods, and acceptance basis | Only the process criteria measured under the agreed test basis; it does not replace control acceptance |
An automation pass answers a narrower question than it is sometimes assumed to answer. It confirms that the control system executed the sequence, triggered the alarms, and respected the interlocks it was tested against. It says nothing about whether the cake produced during that sequence meets a moisture target, whether the filtrate meets a clarity requirement, whether the cycle time is commercially acceptable, or whether throughput holds up under the feed characteristics the plant will actually supply.
This separation exists because the two kinds of acceptance depend on entirely different evidence. Control acceptance depends on demonstrating that logic, timing, and signal handling behave as specified — a matter of electrical and software verification. Process-performance acceptance depends on feed material, sampling method, and measurement technique applied to that specific material under stated conditions — a matter of process engineering verification. A filter press can execute its programmed sequence flawlessly while processing a feed that the equipment was never sized or configured for, producing a cake that fails a moisture requirement despite the control system doing exactly what it was told to do.
The risk this creates is procedural rather than technical: if a contract or project schedule treats “FAT complete” or “SAT complete” as equivalent to “acceptance complete,” the process-performance questions can be left without their own agreed test basis, discovered only once production is underway and a requirement is not being met. The EPA’s fact sheet on recessed-plate filter press technology treats representative testing as part of the design basis for this type of equipment — a signal that cake and filtrate behavior is something to be verified against the specific material in question, not inferred from a control system’s correct operation, and not transferred from general process-industry performance figures.
The practical implication is that a project needs two separate acceptance agreements, not one extended checklist: one covering the automation functions appropriate to FAT and SAT, and one covering the feed sample, sampling method, measurement approach, and acceptance basis for cake condition, filtrate quality, cycle behavior, and throughput. Where that second agreement does not exist yet, the automation test schedule should not be allowed to substitute for it — a point developed further in a companion discussion of pruebas de aceptación de la prensa de filtro, que abarcan la humedad de la torta, la calidad del filtrado y el tiempo de ciclo as their own subject.
Responsibility Matrix for Inputs, Witnesses, Issues, and Retests
| Test item | Responsibility to name before testing | Decisión protegida |
|---|---|---|
| Test material | Party supplying the agreed test material when a test requires it | Confirms who must make the agreed material available |
| Instrumentos | Party supplying the instruments required by the agreed test | Confirms ownership of the measurement setup |
| Witnesses | Parties required to witness each FAT and SAT activity | Confirms who must attend before the activity can be closed |
| Data sheets | Party preparing and completing each test data sheet | Gives every recorded result an accountable owner |
| Punch-list decisions | Party authorized to decide the disposition of test issues | Prevents issue ownership from remaining undefined |
| Retests | Party responsible for arranging and recording required retests | Establishes who carries an unresolved item through its next test |
| Final records | Party compiling and issuing the final FAT and SAT records | Establishes ownership of the closeout package |
Even a well-scoped FAT and SAT plan fails in practice if no one has assigned who supplies what before the test date arrives. Test material, where a test requires representative material rather than simulated signals, has to come from somewhere, and if neither party has confirmed who is responsible for providing it, the test gets delayed or run against an unrepresentative substitute. Instruments needed for measurement have the same problem: if the supplier assumes the buyer will provide a calibrated instrument and the buyer assumes the opposite, the test either stalls or proceeds with uncertain measurement quality.
Witnessing is a related but distinct question. A test result that no authorized party observed and signed off on is not an accepted result, regardless of whether the equipment performed correctly — because acceptance is a documented agreement, not just a technical outcome. The project needs to establish, before testing, who must be present for each FAT and SAT activity, since a witness requirement discovered mid-test creates scheduling conflict rather than clarity.
Data sheets and punch-list decisions are where ambiguity does the most damage after the fact. A data sheet with no clear owner invites disputes later about what was actually tested and what the result meant. An issue identified during testing — a minor deviation, a function that did not perform as expected — needs someone with the authority to decide its disposition: accept as-is, flag for correction, or carry forward to a retest. Without that authority assigned in advance, punch-list items accumulate without resolution, and the project loses track of what remains open between FAT and SAT or between SAT and final handover.
This is the stage at which the information a buyer supplies during project definition becomes operationally relevant again: the feed characteristics, the site utility conditions, and the interface details given during configuration and quotation review are what determine which test items even apply to a given project, which in turn determines who needs to be assigned to each one. A project that has not clarified its own site conditions at that earlier stage arrives at the responsibility-assignment stage with gaps that are harder to close under time pressure.
Final Records Needed to Close FAT and SAT
Closing FAT and SAT is not the same event as running them. A test that was executed but never formally closed leaves the project without a defensible record of what was accepted, under what conditions, and by whom. The final records package is what converts a set of individual test results into something the project can rely on for handover, warranty discussions, or later troubleshooting.
At minimum, that package needs to reconcile three things that earlier sections treat separately: the completed data sheets for each tested function, the disposition of every punch-list item raised during testing, and confirmation that every required retest was actually completed and recorded rather than left open. A punch-list item marked “to be retested” with no corresponding retest record is not closed, even if the project proceeds as though it were. The same applies to a data sheet that records a result without recording which conditions — simulated or real, factory or site — produced that result, since that distinction determines whether the result still needs to be revisited once the relevant installed condition exists.
The party responsible for compiling and issuing this final record needs to be the same party identified during the earlier responsibility assignment, not a role filled informally after the fact. Where FAT and SAT were treated as separate events with separate records, the final closeout package should make clear how the two relate — specifically, whether every function deferred from FAT to SAT was in fact picked up and completed at SAT, or whether some dependency was never addressed by either test and still needs its own resolution.
This closeout record is also where the earlier separation from process-performance acceptance needs to remain visible rather than blur. A final FAT/SAT package confirms that the automation functions tested were accepted; it should not be worded, structured, or filed in a way that implies cake, filtrate, or throughput requirements were also addressed, unless a separate process-performance acceptance record exists alongside it covering that ground on its own agreed basis.
Preguntas frecuentes
Q: Should a membrane press function be assigned to FAT or SAT if only part of it can be demonstrated at the factory?
A: Split the check at the dependency boundary. Record the portion demonstrated with the available factory setup in FAT, carry the parts that require installed utilities, wiring, signals, or operating conditions into SAT, and name a separate site integration test if the check extends across broader installed interfaces.
Q: What should be confirmed before witnesses are invited to an automation test?
A: Confirm the functions to be demonstrated, the available test setup, site-dependent items excluded from that session, required material and instruments, witness attendance, data-sheet ownership, and the agreed route for issues and retests. This makes the planned test scope and its prerequisites visible before the test date.
Q: Can an automation FAT or SAT accept cake condition, filtrate quality, cycle behavior, or throughput?
A: No. Those outcomes need a separate process-performance test with an agreed feed, sampling approach, methods, and acceptance basis; the automation result should close only the tested logic, alarms, interlocks, interfaces, and records within its stated conditions.
Q: Can FAT or SAT be closed while punch-list items remain open?
A: Only when the project’s agreed acceptance basis allows that disposition and each open item has an authorized decision owner, a defined next action, and a clear retest or record requirement. Otherwise, keep the affected test item open rather than treating an incomplete result as accepted.
Q: What should a retest record show to support final acceptance?
A: Link the retest to the original test item and issue, then record the action taken, the conditions used, the new result, required witnesses, and the final disposition. The closeout package should make the path from the first result through the retest decision traceable without implying that an automation retest proves process performance.
