Testing, FAT preparation and documentation for integrators

Test scripts

We write test scripts from the functional specification, the IO list, the alarm list and the screens. Each test has a clear step, an expected result and a place to record the actual result and sign off. Scripts are organized so the client can witness them in a sensible order: IO checks, then device control, then sequences and interlocks, then alarms, then reports and interfaces.

We send the scripts to you for review before FAT is scheduled, so gaps in the specification show up on paper and not in front of the client.

Simulation for factory acceptance tests

A good FAT needs the control system to behave as if the plant were connected. We build simulation that drives inputs and responds to outputs: motors that report running when started, valves that travel, levels that rise and fall, and faults that can be triggered on demand. The simulation runs against your controller program or an emulator, depending on the platform and what your team prefers.

Simulation also lets part of the FAT be witnessed remotely, with the client watching over video and screen sharing. Checks that need physical hardware, wiring or panel inspection still need people in the room.

What we deliver before FAT

• Test scripts with steps, expected results and sign off fields
• Simulation logic and a short guide on how to run it
• A traceability sheet linking each requirement to the tests that cover it
• A punch list template that your team uses during FAT

What we need from you

Good test scripts come from good inputs. The more of these you can share, under NDA, the fewer questions we send back.

• The functional specification or control narrative, even in draft
• IO list, alarm list and any cause and effect matrix
• The controller program export and HMI project, or access to a copy you control
• The client’s FAT procedure or a previous FAT record they accepted
• Any document templates the client requires

As built documentation

At the end of a project the as built documents usually lag behind the system. We update them from the final program, screens and configuration: IO lists, alarm lists, network and architecture drawings, functional descriptions, and operator guides. Where the client has a document template, we use it. The documents go out under your name.

How we keep this reviewable

Every deliverable is in a format your team can edit: the client’s document templates, spreadsheets for lists, and the native project files for simulation. Changes are tracked between versions so your reviewer sees what moved. You review, we fix what you ask, and you send it to the client.

We work only through the accounts and connections you set up, and we sign your NDA before you share any client details. All work product transfers to you or your client on payment.

Where to start

The easiest first package is usually test scripts for one area of a project that is already specified. It is small enough to review quickly and shows you how we write, how we ask questions, and how the Eastern hours handoff works in practice.