Tag Archives: IQ

PLC/HMI IOQ – What to Test?

PLC

Hello good people of the world! Today’s post is on initial control system Installation and Operational Qualification (IOQ) of a simple system consisting of an Human/Machine Interface (HMI), Programmable Logic Controller (PLC), and any number of end devices (valves, pumps, sensors, etc.). The question is what should be tested?

Obviously there’s a ton of guidance out there (see e.g.: GAMP) that will have a lot more detail than this post. The purpose here is to list at a high level the tests that could be expected. So let’s get started!

Installation Qualification
IQ can be its own protocol or combined with OQ in an IOQ for cases without a ton of complexity. IQ is supposed to verify the installation of hardware, software, and any peripherals. You also want to check what documentation is available/applicable here. IQ tests may include:

  • Documentation Verification (e.g. SOPs, EREC/ESIG assessment, operating/maintenance manuals, panel and electrical drawings, etc.)
  • Hardware Verification: verify the make and model of major components at a minimum
  • Software Verification: verify/record software versions. You’ve got to know what you’ll be OQ’ing!
  • Configuration Verification: verify any hardware and/or software configuration. This could be two tests, one for hardware, one for software.
  • Loop Check Verification: verify loop checks are performed.
  • Alarm Configuration Verification: ideally alarms a setup in such a way that you don’t have to functionality test them all!
  • Any other critical installation items

Operational Qualification
OQ is the meat of your control qualification. Here you want to test critical functions, that hopefully you have identified earlier (see here for one approach). OQ may test:

  • Interlock Verification including e-stops. A lot of interlocks are safety/business related, but they’re often included in OQ due to how critical they are.
  • Functional Alarm Verification – be sure to include data loss/communication alarms
  • HMI Navigation and Layout Verification
  • Restart/Recovery Verification
  • Sequence of Operations Verification

What kinds of testing are you sure to cover in your control system IOQ protocols? Comment below.

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

Specifications: How to Write Them

GAMP V Model

Hello good people of the world! Today’s post is about the left side of GAMP’s V-model: specifications. Specifically, their purpose and how to write them.

Of course there are many variations of the V-model, and it is best to find what suits your organization and processes. For the purposes of this discussion, I’ll refer to the basic GAMP V-model, pictured above.

The specifications are: User Requirements Specification, Functional Specification, and Design Specification. In general each feeds in to the next. Also, Installation Qualification may test the details of the Design Specification, Operational Qualification may test the functional descriptions in the Functional Specification, and Performance Qualification may test the high-level requirement’s of the User Requirements Specification, although these boundaries are often blurred in practice.

Any new project should start with a User Requirements Specification which clearly defines the testable user requirements. It is important that requirements are testable, and often a SMART approach is applied: each user requirements should be Specific, Measurable, Achievable, Relevant, and Time-bound. It is also helpful to categorize user requirements upfront, since not all will be quality-related. This makes it easier to rationalize the requirements that are explicitly tested in qualification protocols versus commissioning or not at all. Typical categories include: business, safety, maintenance, and quality.

The Functional Specification is then a response to the User Requirements Specification, typically provided by the vendor, explaining in detail how automated components will function to fulfill the user requirements. Functional Specifications are often confused with Functional Requirements or Functional Requirements Specification, which may be another document defined by a process. GAMP’s V-model does not intend the Functional Specification to document new or further detail requirements, but to define the functionality employed to meet the requirements defined in the User Requirements Specification. The Functional Specification can describe sequence of operations, interlocks, alarms, etc.

The Design Specification should provide sufficient detail that an engineer could recreate the control system from scratch if need-be, to recreate the functionality described in the Functional Specification to meet the user requirements. The Design Specification is typically provided by the vendor and should contain such details as I/O list, alarm list, HMI security levels, sequence of operations details including device positions at each step and transition conditions. This should be a very detailed document, and if you’re working with 10-20 pages it is too light.

Documentation can be expensive and is maybe not fun to generate and review, but is critical to a highly effective validation program.

What do you like to see in specifications?

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

 

WHO’s Draft Guidelines on Validation May 2016

Hello good people of the world! On May 15, 2016, the World Health Organization released its draft Guidelines on Validation. It is available on the WHO website for download here.

This post covers my review of the guidance. Continue reading WHO’s Draft Guidelines on Validation May 2016