Required FDA and OSHA control system documentation?

I am interested in the types of control system documentation required in regulated industries, particularly FDA (pharmaceutical) and OSHA (plants under PSM regs).

Are written descriptions of logic and control loops required to be kept. For example, some PID loops have logic that forces it into manual under certain circumstances. Most were implemented when the control system was installed; others as a part of modifications. Does the plant have to have documentation of loops that have such features? What is the typical industry practice?

Any other comments are welcome.

Reply to
Anita Richards
Loading thread data ...

Hello Anita,

Can't say much about OSHA but since I work in medical electronics I know a bit about FDA. It's not pharmaceutical but we do have experience in the mass production of disposables.

Usually the whole process needs to be documented, including how machines work. An important part of this is the hazard analysis, such as 'what if the machine errs during the xyz process step', what the mitigation measures are and so on.

The FDA has a lot of information on their server, including guidelines that they expect to be followed.

Most of my work entails products that are shipped worldwide, including Europe, and that has always required ISO compliant documentation, validation of machine operations etc.

Bottomline is, yes, I believe such loops should be documented. Even if there wasn't any regulatory requirement I'd still do it because someone might have to debug it who hasn't been on the team when the algorithms were created or installed.

Regards, Joerg

formatting link

Reply to
Joerg

Anita Yes it should be well documented. In fact is 'should' be well documented Before the software is written. And if you have been making changes as you suggest the changes should be well controlled and documented. There is a whole 'industry' build around validation, see for example

formatting link
formatting link
Francis
formatting link

Reply to
Francis

Anita,

I have worked with several pharmaceutical manufacturers who have different attitudes about requirements for documentation, so I am not sure what the FDA requirements are. As for your question,

"some PID loops have logic that forces it into manual under certain circumstances... Does the plant have to have documentation of loops that have such features?"

I really haven't been able to find the answer.

My own opinion applies to all industries, regardless of regulation. Those loops and all others should be documented. For each control system there should be functional specification that list all loops, programs, and logic modules and their function. Every loop should be listed. A simple, "standard" loop could refer to a section of the spec describing the standard function. However, any exception needs to be specifically documented as to the function (not the implementation). For example "FIC-123 is forced into manual mode when pump PU-123 is not running. When PU-123 is running, FIC-123 will remain in manual until the operator places it into automatic."

The documentation may have tables listing the loops, their tags and descriptions, and a reference to a paragraph describing the function (either a generic description or a unique description for that loop). For every control loop the document should describe what the loop controls (maintains at set point) and what the loop manipulates (changes in order to carry out the control). For example, LIC-123 controls the level in tank T-123 by manipulating the flow (FI-122) into the tank.

Of course, this document may be very long and time consuming to prepare. But the process and its control strategy hve to be designed. When these are designed the document can also be prepared. After all, it has to be written down somewhere if anyone is going to implement it. And you will soon find that the functional description will pay off in the long run (often in the short run) whether or not it is required by any regulatory body.

John

Anita Richards wrote:

Reply to
John Shaw

The best job of documentation I did was the one really in-control project that I had the privilege of working on. I generated documents and two other people implemented my designs in software. If there was a question I answered it by revising the document, and they followed the document to implement.

That document is still used by the company, 5 years later.

John Shaw wrote:

Reply to
Tim Wescott

Tim Wescott wrote: That document is still used by the company, 5 years later.

Keeping the design document up to date and continuing to use it is one of the most important things. It can be rather difficult when I walk into a plant to do some work and find no documentation or out of date documents.

John

Reply to
John Shaw

Hello John,

My first boss said "If you didn't document it then it didn't happen".

Regards, Joerg

formatting link

Reply to
Joerg

Dear all, Thanks for your comments.

Now a DCS vendor (we are selecting a new DCS) has said that their system is self documenting and will produce the documentation of the control system design by dumping the configuration information and custom program code into one of several formats including Access data base, Word documents suitable for printing, drawings, etc.

Is this adequate? Will it take the place of spending time at the desk on the PC writing stuff in Word or building long loop lists in Excel? It looks like it will save a bunch of man-hours (or woman hours!).

Thanks

Reply to
Anita Richards

You still have to document how the DCS is hooked up -- the best you could hope for from the factory is a map of how input(1), input(2) etc., are connected to output(1), output(2), etc. Where those inputs come from and where the outputs go to will still need to be documented.

If you're planning on using this information I'd suggest that you get their salespeople to show you some example outputs, and to dig into detail on how the information is entered -- e.g. if there's an output that says "fan 1" then ask how it knows it's fan 1, how hard it is to move fan 1 from one output to another, etc.

Ultimately only you can decide if it's adequate. You should subject it to the beer truck test* -- if you walk out of work tonight and get run over by a beer truck, will your successor be able to understand the system?

  • I originally learned this from a guy from Milwaukie, WI.
Reply to
Tim Wescott

I would like to see them prove such a statement. There is much more to the documentation aspects than merely dumping the program code and configuration information. If the DCS is in control of potentially hazardous processes then I would expect that a full risk assessment, a task analysis and quite detailed operations manuals will also come with the system. Does your DCS provider really understand your process?

To answer your questions more simply; "No", "No" and "Not at all".

Reply to
Paul E. Bennett

Anita How is the DCS vendor supposed to know how to configure their system in the first place? They have to have specifications that provide that information, and that is where your validation should look before looking at the software documentation. I have seen this over and over in pharma (and non pharma) projects. The result is a system that you cannot trace back why it is the way it is, just what validation says should not happen. That is exactly what my software ControlDraw is about. Contact me directly if you like. Francis

Reply to
Francis

Hello Anita,

In my line of work this has never been sufficient. There has to be at least some prose that tells other engineers how something works and, most importantly, why it was designed the way it is. A golden rule is that someone of 'adequate skills' has to be able to understand everything without resorting to asking the original designers. Then there is tracking back of versions (version control): Say, a PID loop was changed a bit. What were the reasons? Is it backwards compatible? Where is the memo of the underlying design review?

Better to spend the woman hours now than scratching your head five years from now. "Why did I change this?". I often had to plough through oodles of source code, effectively reverse-engineering client's designs because the only 'documentation' available were some lines of comment in there. That's no fun and it was expensive for them.

Just to give you an example: Once a client called in a bit of panic. The head analog engineer had wrecked out on a motorcycle, badly. Not his fault, the frame had fractured and the machine literally disintegrated underneath him. But he was definitely out for weeks. However, he had started to write his module spec and everything else in the early conceptual phases of the design, just as I always do. I could hop into the design in under a day and when he came out of the hospital he could take the baton back as quickly. If he hadn't documented that way the whole system would have missed a major milestone. It didn't.

Regards, Joerg

formatting link

Reply to
Joerg

Anita,

Yes, some DCSs can, perhaps by providing data to a program in a PC, supply very good documentation of the software in the DCS. This includes listings of programs and block diagrams of control logic.

However, this is not sufficient documentation.

There are three types of control system software documentation that is needed. (1) Functional description of control logic -- what should be implemented, (2) Detailed implementation description based on the functional documentation - how it should be implemented, (3) Detailed implementation data that is actually in use on the DCS -- what actually was implemented. (This is what the DCS can automatically provide.)

Looking at each of those types of documentation:

(1) The functional requirements description, also known as control narrative, requirements description, and other terms, describes, in terms understood by operators and process engineers. The functional description is a plain language description of the desired function of each loop, interlock, batch phase, and other control function. In general, it is independent of the implementation but instead explains what shall be implemented. For each simple control loop, for example, there should be an explanation of which process is to be controlled and which process variable must be manipulated. Likewise, interlocks should explain what triggers the interlock and which loops are affected and how they are affected. This document will generally be reviewed and approved by the appropriate people before implementation.

(2) The detailed implementation description (known by many names) is an interpretation of the functional requirements description and is used to actually implement the control software. It has the specifics for the particular control system.

(3) The detailed implementation data that is actually in use on the DCS, and often can be printed from the DCS in various formats, shows not what is supposed to be in the DCS but what actually is in the DCS. This type of documentation can be used for debugging, and a comparison between this and the implementation details of type (2) can be used to find errors in the implementation.

While DCSs and other systems are producing better documentation of type (3), no system can produce the functional requirements (1) automatically. That document is based on intent. The system cannot determine the intent of the control engineer.

I know that it is comm> Dear all,

Reply to
John Shaw

Further to John's comments, -

in the IEC 61508 standard, there is reference to:

verification - checking the outcomes of each stage to ensure that they meet the requirements of the inputs

validation - checking the result of the whole design exercise to ensure it does the job that was originally intended.

In brief - verification asks - "Have we done the job right?" while validation asks "Have we done the right job?"

It's no use having a well-documented and "correct" implementation of a control or protection scheme if the original intention was flawed - and this should be the start for any design, and all documents ned to be traceable back to this original intention document.

On a lighter note ...

There are 4 ways of doing a job - The way the designer originally intended it to be done The way the manufacturer's instruction manual says it should be done. The way the site procedures say it should be done. The way it actually is done.

One of the first people I had to report to was the superintendent of a thermal power station. He told us young engineers how he got the job - in hiis previous position, he was in charge of a shift on another power station, and always managed to get the station up and running half an hour faster than any of the other shift charge engineers. How did he do it? He ignored the specified limit on the steam temperature during warm up - since he "knew he only had to go a couple of degrees over to make all the difference".

Bruce.

John Shaw wrote:

Reply to
Bruce Durdle

...

Yup! And back in the old days, Sonny, it was quite usual to tie down the boiler's safety valve when racing locomotives.

This has been a long thread filled with good advice and appropriate admonitions. It puzzled me from the start, though. The documentation that government agencies require is not, by and large. a matter of opinion or of accumulated experience. Those agencies publish regulations. Why doesn't the OP consult them?

Jerry

Reply to
Jerry Avins

Unfortunately, the regulations do not seem clear about the required control system documentation. 21CFR (FDA) and 29CFR chapter XVII (OSHA) give very little guidance.

FDA has a guidance document, "General Principles of Software Validation; Final Guidance for Industry and FDA Staff", January 11,

2002, that has some interesting discussion. It is very general and open to intrepretation. The closest it comes (that I could find) is a statement (sec. 4.1) "The software validation process cannot be completed without an established software requirements specification (Ref: 21 CFR 820.3(z) and (aa) and 820.30(f) and (g))." However, 21CFR 820 is part of the Medical Devices subchapter (H) and does not appear to apply to drug manufacturing. (As someone in a pharmaceuticals plant pointed out to me when I raised the issue). There is also a guidance document that source code for control software be made a part of the master batch record (there are specific requirements for maintaining batch records).

So far, the only thing I have seen in writing discussing requirements for such documentation is in this discussion and similar discussions elsewhere on the internet. I have not seen it in government regulations, organization standards, or books. Perhaps I am just looking in the wrong place.

There seems to be full agreement here and on other fora about the importance of functional requirements documentation for control software, and I am sure that there are many who actually put this into practice (I have seen numerous cases of excellent documentation--even in industries where there is not a regulatory need). Many of use who work in many different plants in many process industries have horror tales of either lack of documentation or documentation that was years out of date.

If anyone can point me to a regulation (U.S. or elsewhere), standard, or even discussion in a publication that requires or strongly recommends the use of functional requirements documentation for control system software, I would like to hear about it.

John Shaw Process Control Solutions

Reply to
John Shaw

It is a principle of the FDA not to proscribe a particular way. It's a sort of consultants charter really. I think there is a lot that "strongly recommends" it though: The first standard that I remember being adopted widely was the IEE Guidelines - I can't find a free copy on the web, but the following (just one example - there are many) is I believe based on that.

formatting link
TickIT guide is widely used here in the UK
formatting link
provide a long list of reference documents which includes the IEEE ones which are comparable
formatting link
there is GAMP - Good Automated Manufacturing Practise.

But, even disregarding the standards, it is just good engineering practise. Have you ever looked at the documentation that comes out of a DCS, or PLC/SCADA? Unless you understand the system well, it is very hard to follow, and it is massive. Thousand of pages of cross reference, long lists of parameters, if you are lucky some loop diagrams (but the loops may only be constructed by linking points through some configuration data) and sequence diagrams (again maybe not) The first thing I do when I see a system that is only documented internally is try to get an idea of it's structure and things like naming standards and then how it relates to such specifications as exist, at least P&ID's and maybe process descriptions - but these are often very poor from a control point of view.

Reply to
Francis

Shouldn't that be "prescribe"?

(That's my nit pick for the week) - but the IEE Guidelines (and I think the HSE before that) recomend a Functional Spec to be "complete, concise, and unambiguous". Add accurate to that as well.

Bruce.

Francis wrote:

Reply to
Bruce Durdle

That's only half a nit. :-) With complete freedom, nothing is either prescribed or proscribed.

With no official requirements document, nothing is prohibited. Neither can one claim to have met the requirements.

Jerry

Reply to
Jerry Avins

Yes, wrong word, sorry. I meant prescribe or enforce. And all you have to do to check is tap Define and the word into a search as I just did.

Reply to
Francis

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.