Prensa de membrana FAT e SAT: Testes de automação e responsabilidades

A filtro prensa de membrana that passes every automation check at the supplier’s works can still arrive on site with alarms that never fire, interlocks tied to signals that do not yet exist, and a control sequence no one has confirmed against the installed plant. Deciding what FAT covers, what SAT must cover instead, and what neither test proves about cake or filtrate performance determines whether acceptance testing actually protects the project or just produces paperwork.

Acceptance Scope That Belongs to Automation Testing

Automation acceptance testing exists to confirm that a control system does what its design intends, within the boundaries of whatever test setup is available at the time. That scope is narrower than it sounds. A factory environment can demonstrate sequence logic, alarm behavior, and interlock responses that depend only on the automation platform and whatever inputs the test bench can simulate. It cannot demonstrate anything that depends on equipment, wiring, or process conditions that do not exist until the unit reaches site. This is why automation acceptance is conventionally split into a factory stage and a site stage, with a separate site integration test named where the project involves multiple interconnected systems.

The practical consequence for a buyer is that neither FAT nor SAT is a single checklist; each is bounded by what is physically available when the test runs. A sequence that behaves correctly against simulated inputs in a factory test does not confirm that the same sequence behaves correctly once it receives real signals from installed upstream feed equipment or downstream conveying equipment. Where a project’s automation depends heavily on interfaces with other installed systems, treating FAT as sufficient evidence of readiness creates a gap that only shows up after installation, when correcting it costs more coordination than naming the dependency up front would have cost.

This distinction matters specifically for a membrane filter press because its automation typically coordinates several functions — feed sequencing, membrane squeeze timing, plate shifting, cloth washing, cake discharge — some of which can be exercised meaningfully on a test bench and some of which cannot be fully exercised until the press is mechanically installed and connected to its actual air, water, and electrical services. Comissão Eletrotécnica Internacional 62381, the standard governing FAT, SAT, and site integration testing for process-industry automation, treats this as a matter of project-specific agreement: which functions are tested where, and by what checklist, is something the project parties define rather than something inherent to the equipment. That agreement needs to exist before either test begins, not be improvised during it.

The questions worth raising at the quotation or contract stage are: which automation functions does the supplier propose to verify at FAT, which are deferred to SAT, and is there any function that depends on an interface not yet installed at either point — in which case it needs its own named test rather than being silently assumed covered.

Factory Tests for Logic, Alarms, Interlocks, and Records

FAT work is bounded by what the factory test setup can produce as inputs and what it can observe as outputs. Sequence logic can be verified against simulated conditions that represent a cycle’s stages. Alarm functions can be verified by forcing the conditions that are supposed to trigger them, to the extent the test bench can generate those conditions artificially. Interlocks can be verified the same way, provided the interlock’s triggering condition does not depend on a physical state that only exists once the press is installed and connected to its actual utilities.

The boundary that matters here is not about the automation logic’s quality; it is about what the test environment can actually exercise. An interlock written to prevent plate movement during an unsafe condition can be demonstrated in a factory setting if that condition can be simulated electrically. An interlock that depends on a signal from site-installed safety equipment, or from a utility that is not connected until commissioning, cannot be meaningfully demonstrated at FAT regardless of how well the logic itself is written. Treating that interlock as “tested” because its code passed a factory check, without noting that its real trigger condition was never present, creates a false sense of completeness.

This is also where automation records deserve attention. A FAT that produces a clean pass on sequence logic, alarms, and interlocks should also produce a record of exactly what was demonstrated and under what simulated conditions — because that record is what determines whether a given function still needs to be retested at site or can be considered closed. A FAT record that only states “passed” without stating what was simulated leaves the project unable to tell later which gaps, if any, were carried forward.

Buyers preparing for FAT should confirm, before the test date, which specific interlocks and alarms are being demonstrated against simulated inputs versus real ones, since a factory pass on a simulated input says something true but narrower than it may appear to say. Where the fully automatic filter press configuration involves additional automated handling steps beyond manual or semi-automatic equivalents, that expanded automation scope increases the number of functions whose factory-stage demonstration depends on simulation fidelity, making the pre-test agreement on what is being simulated more consequential rather than less.

Site Tests for Installed Utilities and Interface Signals

SAT exists precisely because some automation functions cannot be honestly evaluated until the equipment is installed, wired, and connected to the utilities it will actually use. A function that depends on installed compressed air pressure, actual hydraulic supply behavior, or signals arriving from upstream and downstream equipment is not something a factory test bench can substitute for, no matter how well it simulates the expected input. The site test is where the control system’s response to real conditions — not modeled approximations of them — gets confirmed.

This creates a specific judgment point for the project team: which functions were left untested, or only partially tested, at FAT because their trigger conditions did not exist in the factory, and does SAT’s scope explicitly cover those functions now that the conditions do exist. If the FAT record was clear about what it simulated, this mapping is straightforward. If it was not, the project risks assuming a function is proven when it was only proven under artificial conditions that may not match the installed reality.

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

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 testes de aceitação do filtro-prensa, abrangendo a umidade do bolo, a qualidade do filtrado e o tempo de ciclo as their own subject.

Responsibility Matrix for Inputs, Witnesses, Issues, and Retests

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.

Perguntas frequentes

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.