Suppose you have a customer that wants you to do a software validation on
his production equipment, operated by PLC software. They lack Functional and
Design SPECS, and even User Requirements SPECS for most of them.
The customer has requested FS/DS to the manufacturer; some of them are
asking to much ($5,000.00 USD) and others are not willing to give or even
sell anything. A good alternative is to generate the SPECS ourselves.
What is your recommendation to create those needed pieces of documentation?
Most of the equipment is precisely current technology (between 4 to 7 years
old).
You have your customer create specific user requirements including upper
and lower limits for specific functionality they will use in their
process. Then you verify the equipment will support these requirements
by testing to these requirements. Therefore, the system will then be
validated for use.
They do not need to validate to design since many of the functions and
features may never be used by your customer.
or
You can create the 2 spec documents in-house, tailored to your customer’s
specific needs. I would not use the Mfr. because chances are the customer
is not using all functionality and the specs would be way too voluminous.
You only need User Requirements Spec and Functional Requirements Spec; you
do not need Design Spec for this project. That should make your
traceability matrix much more concise also.
You cannot validate without specifications or requirements to test to. Your customer must tell how they intend to use the system(s) (user requirements) and then you must figure out what functionality is required to meet those needs functional requirements). The Operational Qualification test scripts are then written to test the functional requirements and the Performance Qualification will address the user requirements.
They purchased their equipment without URS and it’s already being used in production. I could figure out the functional requirements, but before doing that, I guess I would need first (along with the customer) to apply a kind “reverse requirements engineering” to figure out their intended URS, right?
You are correct. You would reverse engineer the user requirements and proceed from there. Manufacturers cannot provide user requirements since they do not know your intended use of the system.
Since I would be using the GAMP4 VALIDATION approach, how do I justify (in the validation documentation) not using the Design Specifications, which are related to IQ in the GAMP4 Validation Model? If the customer wants to be compliant with regards to software validation, the documented evidence could carry-out a handicap if you are not fully following a methodology, and you don’t know how tough an auditor/inspector could be.
My recommendation would be to include a design spec section in the Requirements document. The design spec should include hardware and software manufacturer recommendations for minimum requirements. Then you have included the design docs in the validation. The design specs would be tested in the IQ.
The client company should have SOPs in place that define how much testing is needed for different levels of systems. The full range of validation documentation is not always necessary nor efficient.
I have been involved in multiple remediation activities over the years. Retrospectively creating Functional Specification is a good approach. It describes the user agreed functionality in a single document (both user requirements and functional design).
If the vendor is supporting the source code you should not need a Detailed Design spec for the structure of the code. If you are supporting the architecture of the application (e.g. wiring), you should have some elements of design documented(e.g. wiring diagrams or an a brief architecture spec in the Functional Specification).
You did not mention testing in your original email. If testing did occur before, you will need to ensure that that previous testing adequately tested key functional Specification elements (maybe through a Traceability Matrix). This could be a tool to address the risk assessment mentioned earlier.
If the system has been in operation for years and was tested, then you should confirm (via the TM) that the key functions were tested.
If the system was never tested, then you may want to do some high level testing of key functions. You should have a retrospective Validation Report, assuming none exists and assuming this is a regulated application. If the system was never tested, you should analyze the last couple years of incidents that have occurred in production and summarize (in the Validation Report) that the system has been operating in a stable mode (e.g. mainly password resets and normal production issues).
So, Functional Spec, Testing and Validation Report are key. A Traceability Matrix can be part of the package and can be used to document key functionality and how it was tested or why not tested.
5,000 US isn’t bad…$125/hr for 5 days. a really complex document can take a couple of weeks. I am used to the 3000/document range but I have seen them cost over 15,000. We used to laugh amongst ourselves “What are you doing John?” …John’s response “Printing money, printing money.” ah the good ole days.
All kidding aside…why don’t you just black box it? Why is your client concerned about the software? Something they read? What I am getting at is that equipment driven by a PLC typically has a real world output, open/close, on/off or some other measurable output. ie. sterilization. A lot of equipment with PLC could be considered off the shelf and the PLC is really insignificant. Washers autoclaves, refrigerators; things that a company makes a lot of. Do these really need GAMP type deliverables.? Or can you just point to a picture in a catalog and say…I want? You may be applying GAMP to something that just isn’t needed. It seems like the same struggles that went on with COTS software.
PLC validation is not hard, and it doesn’t have to be painful. It can, at times, be tedious or frustrating, but it doesn’t have to be hard. If you organize your validation program and have the proper things in place before you get started, you can get through it. And, when you’re done, you can actually have a validation package that people can look at, understand, and get something from. It can be done.
Much of what I’m going to discuss is generally applicable to computer validation. PLCs and computers are interchangeable in terms of the way they are developed and the way they are put into place.