Why an FDS, an I/O list and a PLC program drift apart

A functional design spec describes what a system should do. An I/O list says which physical point maps to which tag. A PLC program is the code that actually runs. On paper these three documents describe the same system. In practice they are edited separately, by different people, at different times. They drift apart within weeks.

The usual cause is not carelessness. It's the format. Each document lives in its own file, often its own tool: the FDS in Word, the I/O list in Excel, the program in Studio 5000 or a similar environment. A tag renamed in one place has no way to reach the other two. Nothing checks that a device described in the FDS actually has an I/O point, or that every I/O point is used somewhere in the program. The three documents agree with each other only for as long as someone remembers to keep them in step by hand.

This often surfaces at commissioning, the most expensive place to find it. A tag changed in the I/O list but missed in the FDS looks fine on paper right up until someone tries to match the two documents against the running system. By then the fix is costly: a site visit, a delay, a client asking why the documents they signed off don't match what was built.

The fix is not more discipline. It's removing the retyping. If the FDS, the I/O list and the program are all generated from one structured record instead of copied between three separate files, a tag can only exist once. Rename it and every reference updates with it. There is nothing left to drift, because there is nothing left to keep in step by hand.

That's what FDSIQ and ScaffIQ do. FDSIQ holds the structured record: the I/O, the sequences and the interlocks. ScaffIQ compiles that record into the I/O framework, tag declarations and PLC code.

You can see it running against a real clean-in-place system, read-only, with no sign-up. Explore a real project.

An engineer reviews and tests everything FDSIQ and ScaffIQ generate before it goes anywhere near a running system.