Required FDA and OSHA control system documentation?

Actually, it was not a typo, it was a misunderstanding of my language. I had heard the word Proscribed being used in a Must sense but not realised that it always meant 'Must not' to as opposed to just 'Must' where must could be Must do or Must not do. As in the logical sense of a limit switch does not change the meaning of the logic, if you follow. Francis

Francis, Yes, the FDA does not prescribe or proscribe any particular method. But they will inform you when you are wrong. (and inform you in writing!).

Actually, I see one of the important reasons for having a complete set of functional specifications at the loop level as a way of knowing what is supposed to be in the DCS or PLC, as opposed to what actually is in the DCS or PLC. (bugs happen)

My problem, working for a systems integrator/consultant is convincing the customer. We will not implement the control software (control blocks, ladder logic, and programs) without approved functional specifications, for our own protection. (client: "you should have known that what we really meant was for..."). However, when we talk about the need to keep the functional specifications up-to-date with every loop modification, the customer see it as a way for us to extract more money (we would do the updating when we do the software modification, and of course charge for the time). So any legal requirements, or at least industry standards, would help.

I have seen some very good documentation produced by DCSs (or by PCs using data from DCSs), however this shows what is on the DCS, not what should be on the DCS. It is very helpful for debugging, but does not replace the functional specifications.

I will take a look at GAMP. Also, I think ISA has a standard under development (maybe 5.6, I am not sure).

For those who are ISA members I just saw that there was a similar discussion on the "controls" list.

Thanks

Anita

Francis wrote:

The TickIT guide is widely used here in the UK

IEEE ones

...

...

Convincing the customer is easier if you present two alternatives:

1. The customer knows and acknowledges in writing that you will perform updates to the software or physical layout only when they are accompanied by corresponding updates to the documentation.

OR

1. The customer acknowledges in writing that she undertakes all responsibility for maintaining documentation and satisfying regulatory requirements.

In either case, you absolutely need a document that you can use to show that you have built what you promised to build. Writing software is the same in that respect as erecting an office building.

Jerry

You do, at least, have the right sort of attitude to documentation. I hope you manage to find the inner strength to follow through.

Wise move.

Consider every modification as a new project. This new project has an existing system (complete with specification and implementation documents) and the modification requirements. No doubt, if your client is needing something like FDA approval, he would want some form of certification from your company that the modifications do not increase the risk of operating the modified system. Remind them that such certification is dependent on your updating all the system documentation so that the next modifications required do not have to begin by reverse engineering the system.

As to cost, it should be inclusive of the modification and it seems you already had that angle covered (you are, after all charging for the time to do the update. Just don't separate the documentation update costs out of the inclusive price you give them).

Useful just for showing the "As Installed" status.

Take a look at AQAP150 which available online at

Section 2.2.5 might be the most pertinent but the rest is worth the read. It's OK. It is only about 30 pages.

...

Something seems to be amiss!

Jerry

Some very good points have been made in this thread.

I really like "you absolutely need a document that you can use to show that you have built what you promised to build Writing software is the same in that respect as erecting an office building."

Anita said "We will not implement the control software (control blocks, ladder logic, and programs) without approved functional specifications, for our own protection. " Be careful that you do not prevent any development by being dogmatic about that. Or frustrate the programmers. It may be that a lot can be done even before the client has agreed it. The client may not even fully undertand what you want them to approve, but you are the integrator and you should know what can be done safely and when. For example, the lowest levels of the software (Valves, motors etc, and even most of the graphics) can often be safely generated and even tested whilst the higher levels (procedural levels especially) are still being agreed. You may be able to spend the time developing tools to automatically generate these at the last moment, but that's another level.

"you should have known that what we really meant was for..." Here the issue is about : making sure that you understand what they meant getting the client who did not fully undertand to understand. And that is where really good documents are invaluable.

It does need some strength in managing the documentation, but good software tools can make that much easier

Most of my clients hand over the ongoing maintenance of their documentation to the users in the plant. The leading edge ones in fact make the changes to the documents before (and after) they make the changes to their systems. And I have just helped one to link the graphics in their Process Control System directly to the relevant part of their documentation. With this, operators will be able click a button on a Graphic to open up the design documents (for example to to find out how it is supposed to work,) and to add comments to the document that can then initiate a change process.

Not sure about that, after system acceptance most 'changes' are just a part of continuous improvement. But subjecting all changes to a new project life cycle would probably please the validation poeple but might slow down or prevent change. Have a structure to handle small improvements.

PS, I write, sell and depend on some software I have written to address these issues.

Francis

ControlDraw Ltd

It is an approach that does have a number of benefits.

1. The status of existing plant, equipment and systems is validated and verified before you begin modification work, so is a known base. 2. You and the client can agree on exactly what changes are to be made.
2. It can ease re-certification of the whole system. This is because you should be able to show that the modifications do not invalidate the original certification in un-expected ways.

The one dis-benefit is that it may point up that the exisiting system does not match with the original design documentation (especially if you are modifying a system developed by someone else). That can cause lots of extra (reverse engineering) work. However, if you produced the original system then you should not have a problem in that direction as you did it right the first time. Didn't you?

Reverse engineering work is a costly business. I have had to do more than my fair share of it when I have come to a system (developed by others) that needs an upgrade but the original documents have been lost, do not match the installed status or were poor quality to start with.

Ooops!! wrong NATO. the correct one is

Francis

about that. Or frustrate the programmers. It may be that a lot can be done even before the client has agreed it. The client may not even fully undertand what you want them to approve, but you are the integrator and you should know what can be done safely and when.