Meeting FDA Regulatory Requirements While Programming PLCs

Meeting FDA Regulatory Requirements While Programming PLCs

Programmable Logic Controllers (PLCs) are the components that are used for interfacing between multiple hardware devices or between a software and a hardware component. PLCs prove to be useful in mission-critical industries where a process is automated, facilitating increased productivity, reliability, and reduced or elimination of labor for device control. PLCs are used in numerous applications in the medical and health field including in the chemical and pharmaceutical industries.1 When used in health care services, these PLC-based devices should meet the FDA regulatory requirements before they are released in the market.

PLCs generally comprises of the I/O, power source, peripherals, and the CPU modules. These modules can be programmed in five programming variants such as Ladder Diagram (LD), Structured Text (ST), and Instruction List (IL). Being a part of the software, along with the hardware, the product should be documented, verified, validated, and tested from a quality and safety perspective. These regulatory practices are provided by FDA and manufacturers should follow protocols like Title 21 CFR Part 11 which regulates electronic records and signatures. Such protocols include elements of best manufacturing practice from a programming perspective and focus on shrewd software management practices such as design review, document control, risk management, and remediation activities.

Every software should be verified and validated irrespective of the device risk categorization class. In the case of PLCs, as they are built using hardware components, verification and validation are quite distinct. Verification applies to the regulation at the unit level such as verification of software requirements. These may include unit-level test cases along with the verification or review of the software architectural design. In Validation, the product may be tested at the system level, that is, when the product is completed and ready for system and integration testing. Risk related requirements indicate the safety-related measures and must be logged in documents such as hazard analysis and risk management plans. The major target of verification and validation is to achieve the intended use ensuring the manufacturer has added measures to ensure PLC device safety and efficiency.2

PLCs may require programming changes in which manufacturers should record the changes using document control strategies such as software versions and software change logs. Also, they should test if the changes in specific program files are affecting a group of program files or the entire system. Using Design Control methods and testing such as regression with integration testing, manufacturers can demonstrate the software meets the intended use.2 In the end, if the product is found to be FDA compliant, it may be approved through 510(k), Premarket Approval (PMA), or the De novo (low to moderate risk-based devices) pathway based on the class of the device.3

To summarize, PLCs make human life easier by automating the industrial process. Also, it is a platform that enables hardware communication with software and therefore should be FDA compliant, which involves design documentation and system verification/validation. Do you have a PLC-based system that needs FDA approval? Our software and regulatory experts at EMMA International can help ensure your system is FDA compliant. Contact us at 248-987-4497 or  for additional information.

1Daron Underwood. (August 2017). Understanding Software PLC Features and Requirements. Retrieved on 10/5/2020 from

2FDA (January 2002). General Principles of Software Validation; Final Guidance for Industry and FDA Staff. Retrieved on 10/07/2020 from

3FDA (November 2014). Computerized Systems in the Food Processing Industry. Retrieved on 10/8/2020 from


No Comments

Post A Comment