SCADA Integration FAT and SAT Checklist

Use this worksheet to define an acceptance agreement

This is a proposed engineering worksheet for a read-only monitoring integration. Adapt its tests and thresholds to the actual instruments, source system, approved network design and business report. It is intended to help the customer and integration team decide what evidence to retain. The signed project specification determines the final acceptance criteria.

Download the FAT/SAT worksheet as CSV and add project details, expected values, test conditions and responsible people. Keep account credentials and sensitive network information in the project's controlled records. The worksheet needs a reference to the relevant configuration, not a copy of the credential itself.

1. Establish the point dictionary and reporting boundary

Start with a versioned point list. For each point, identify the source, destination, description, data type, unit, scaling and expected update behaviour. Include the meaning of invalid, unavailable and stale data. A running signal and a healthy signal may both use binary values, but their business meaning differs. Verify that the report uses the interpretation approved by the source-system owner.

For cumulative values, define rollover, reset and replacement behaviour. For a shift report, define the shift boundary and how readings at the boundary are handled. For an event report, define how state transitions become events and which record closes the event. These definitions prevent a technically successful connection from producing an operationally misleading report.

2. Separate FAT evidence from SAT evidence

FAT checks the configuration using representative values, a simulator or an isolated source. It can demonstrate scaling, state mapping, missing-data handling and the expected report layout before the production connection exists. Label simulated inputs clearly in the evidence. An approved test value is a test fixture, not a customer operating result.

SAT checks the installed path using the authorised live sources and operating arrangements. Verify identities, timestamps, permissions, the actual data route and the workflow used by the receiving team. A test that passed with a simulator may still fail at site because an interface licence, account permission or timestamp assumption differs. Record the configuration used for each stage so the results can be compared.

3. Test normal values and the edge cases that change decisions

Avoid inventing one tolerance for every point. A level instrument, pulse counter and controller status have different reference methods. The specification should state how each is assessed and what happens when the reference itself is uncertain. For calculated values, retain enough input data to reconstruct the result. A screenshot can show the presentation, but the supporting records establish whether the calculation is correct.

4. Prove timestamps, replay and duplicate handling

Choose a small sequence of known events and follow it from source to report. Compare measurement time with arrival time, and confirm the time-zone treatment used by the receiving team. Then use an approved interruption test to create delayed records. The recovered history should retain its original meaning and place events in the intended reporting period.

Document the expected behaviour for duplicate and out-of-order inputs. An export imported twice should not silently double a consumption total. A late event should be distinguishable from a new current event. If the design cannot recover part of the history, the report should show the missing interval. Acceptance is about matching the agreed recovery behaviour, including its limitations, rather than assuming every component stores every sample.

5. Verify access without disrupting the control environment

Review the account privileges and approved network route with the OT and IT owners. Confirm that the configuration matches the read-only scope and that access can be removed through the agreed process. Use configuration evidence and safe test methods approved by the site. Write attempts, load tests and induced failures on operating equipment require a separate site-approved method and window.

NIST SP 800-82 Revision 3 describes OT security considerations including segmentation, least privilege and change management. Use that guidance with the site's own requirements when planning the connection. The site's designated authority separately approves its security requirements and the acceptance scope.

6. Test the report and the person receiving it

A point may arrive correctly while the end user's report remains unusable. Ask the report owner to reproduce a shift total, identify an incomplete period and trace an event back to its source. Where notifications are included, verify delivery to the agreed recipient, acknowledgement and the escalation route. Record whether a delayed historical event should trigger a fresh operational notification or appear only in history.

Include a handover exercise for a common maintenance change, such as a renamed asset or replaced meter. The operator should know who approves the change and how it is recorded. This makes the acceptance meaningful after the commissioning team leaves, when a normal site change might otherwise break an apparently finished data path.

7. Record defects and the acceptance decision explicitly

A failed test needs an owner and a clear retest condition. A test that could not be performed remains not tested; it should not be marked as passed because a similar row succeeded. If a limited handover is agreed with outstanding defects, record the accepted boundary and the restrictions that apply until they are resolved. Keep the defect history when the final result is signed.

A practical starting sequence

Begin with the point dictionary and one report whose owner can define the expected answer. Complete representative FAT checks, resolve mapping problems, and obtain the site's approved connection window. At SAT, verify the installed path, repeat the relevant data-quality and recovery checks, and have the operating team use the report. Finish with configuration, access ownership, export examples and the support process.

For delivery of this work, see SCADA data integration with addaNet. For the architecture of bringing new field telemetry into an existing control environment, use the LoRaWAN and SCADA integration guide. The worksheet here focuses on evidence and acceptance so those architectural choices can be tested at handover.

Frequently asked questions

Primary technical source

NIST SP 800-82 Revision 3, Guide to Operational Technology Security, September 2023. Access and change-management guidance supports the technical review above; the worksheet and proposed test sequence are addanode's project-planning guidance. Source checked 5 November 2026.

OPC Foundation, OPC UA Part 2 security model: threats provides additional context for reviewing unauthorised access, message handling and the effects on operational systems. Use the documentation for the actual configured interface during the project review.