Outsourcing PLC Programming: 6 Documents to Request

When you outsource PLC programming, the six documents you must request are: 1) the Functional Design Specification (FDS), 2) the I/O List, 3) the Control Narrative, 4) the PLC Program (with comments), 5) the HMI/SCADA Tag Database, and 6) the Test Documentation (FAT/SAT protocols and results). These documents ensure you can verify, maintain, and safely operate the system after the integrator hands it over.

Why Documentation Matters in PLC Outsourcing

PLC programs are often delivered as compiled or encrypted files. Without proper documentation, you cannot troubleshoot a fault, modify logic for a process change, or prove to an auditor that the system meets safety requirements. A well-documented project reduces downtime and protects your investment. The six documents listed above form the core package that any reputable integrator should provide, and they are also what you need to legally and practically own the system.

1. Functional Design Specification (FDS)

The FDS is the blueprint of what the system is supposed to do. It describes every mode (auto, manual, semi-auto), every sequence, and every alarm. It should be written in plain language with flowcharts or state diagrams. When you receive the FDS, check that it matches your original request and that all interlocks and safety functions are explicitly stated. Without an FDS, you have no way to prove that the delivered program does what you paid for.

2. I/O List

The I/O list is a table of every input and output: tag name, device connected, signal type (24V DC, 4-20mA, thermocouple), and the PLC address. This is critical for commissioning and for future expansion. A common mistake is to assume the I/O list is only for the electrician. You need it to map physical wiring to software tags. Request it in a searchable format (Excel or CSV), not just a PDF.

3. Control Narrative

The control narrative is a step-by-step description of how the process behaves under all conditions, including startup, normal operation, shutdown, and fault conditions. It explains the logic in words, so a process engineer can review it without reading code. For example, it should state: “When the tank level reaches 80%, the inlet valve closes and the agitator starts.” This document is your best defense against logic errors that are only discovered during operation.

4. PLC Program (Source Code with Comments)

You must request the source code in the native format (e.g., .ap for Siemens, .acd for Rockwell, .gxw for Mitsubishi) and with meaningful comments. Some integrators only provide a compiled file or a PDF printout. That is not acceptable. You need the editable source to make changes, even if you never do. Also ask for a list of all global variables and function blocks, and ensure that the program is structured (e.g., using routines or functions) so that a third party can navigate it.

5. HMI/SCADA Tag Database

If the project includes an HMI or SCADA, request the tag database: every tag name, data type, and the PLC address it maps to. This is often overlooked, but without it, you cannot connect a new HMI screen or modify an existing one. The tag database should be consistent with the I/O list and the PLC program. Ask for it in a spreadsheet format, and verify that the tag names match the comments in the PLC code.

6. Test Documentation (FAT/SAT Protocols and Results)

Factory Acceptance Test (FAT) and Site Acceptance Test (SAT) protocols show what was tested and what passed. They should include a checklist of each function, the expected result, the actual result, and the tester’s signature. This is your proof that the system works as specified. If the integrator cannot provide this, they likely did not do thorough testing. Request both the blank protocol (so you can see what was planned) and the filled results.

How to Request These Documents

Put the document list in your request for quotation (RFQ) and in the contract. Do not rely on a verbal promise. Specify the format (e.g., PDF for FDS, Excel for I/O list) and the deadline (e.g., with the final delivery). Also state that final payment is conditional on receiving all documents. If you are already mid-project, send a formal email requesting the missing items and set a deadline.

Common Pitfalls and Misconceptions

A common misconception is that the PLC program itself is enough. It is not, because programs are often encrypted or lack comments. Another pitfall is accepting a “final” version without revision history. Always ask for a revision table and a list of changes from the previous version. Also, beware of integrators who claim that documentation is “extra cost.” In most jurisdictions, the documentation is part of the delivered system, and you are paying for it.

Frequently Asked Questions

What if the integrator refuses to give the source code?

Refusal is a red flag. In most cases, the source code is your property if you paid for the development. If they refuse, you may need to escalate to a legal review, but first, check your contract. If the contract is silent, you can still insist, as it is standard practice in the industry. Without the source, you are locked into that integrator for any future changes.

Do I need all six documents for a small project?

Yes, even for a small project, but they can be simplified. For a single machine with 20 I/O points, the FDS can be a few pages, and the test documentation can be a simple checklist. The key is that the documentation exists and is accurate. Skipping it is how small problems become large ones.

How do I verify the documents are accurate?

Cross-check the I/O list against the electrical drawings. Then, on a simulated or offline test, compare the PLC program’s behavior to the control narrative. If you have the time, do a full FAT with your own engineer present. The documents are only useful if they match the actual system.

What is the difference between FAT and SAT?

FAT (Factory Acceptance Test) is done at the integrator’s workshop before shipping, using simulation or a test rig. SAT (Site Acceptance Test) is done at your site after installation, with the real field devices. Both should be documented. The FAT proves the logic works; the SAT proves the wiring and field devices work with the logic.

Can I use these documents to train my maintenance staff?

Yes, the FDS and control narrative are excellent training materials. The I/O list and tag database help electricians trace faults. The test documentation shows what was already verified, so your staff know what to trust. After training, your staff should be able to handle minor changes without calling the integrator.

Related

• Arc Raiders Trading: Item Swaps & Vendors Explained
• Social Media Terms: Key Definitions for Platforms, Content & Metrics
• Wandering Water Spirit: Myths and Meanings