Software Design Specification

The #GMP-critical automation control system software must be fully documented, reviewed, and well structured, following good #programming practices to ensure, that the control system software is:

• Reliable,
• #Safe,
• Robust,
• Maintainable,
• #Testable,
• Modular,
• Well commented.

The Software #Design Specification is commonly written by the supplier of the automation control system, where the supplier describes in detail the automation control system software described in the #FDS.

Key objectives of the SDS:

• Define the constituent software components of the system, how they inter-communicate, and what constraints are applied to them,
• Enables the purchaser to determine the implementation strategy of the supplier,
• Allows the purchaser to ensure the correctness and completeness of the software design through cross-checking with the FDS,
• Provides input to the system integration test #specification,
• Ensures a structured approach to the presentation of information which can be carried forward into the module design and test specifications produced later in the system development.

GAMP Categories of software:

Category 1:

Established or commercially available #layered software, which are applications developed to run under the control of this kind of software. This includes operating systems, database managers, programming languages, middleware, ladder logic interpreters, statistical programming tools, and spreadsheet packages (but not applications developed using these packages).

Infrastructure software tools include such tools as network monitoring software, batch job scheduling tools, security software, anti-virus, and configuration management tools. Risk assessment should, however, be carried out on tools with potentially high impact, such as password management or security management, to determine whether additional control is appropriate.

Examples: Operating Systems, Database Engines, Middleware, Programming Languages, Statistical Packages, Network monitoring tools, Scheduling tools, Version Control Tools, and spreadsheets.

Typical approach: Record the Version Number, verify the correct installation

Category 3 - Non configured products,

This category includes off-the-shelf products used for business purposes. It includes both systems that cannot be configured to conform to business processes and systems that are configurable but for which only the default configuration is used. In both cases, configuration to run in the user's environment is possible (i.e., printer setup). Judgment based on risk and complexity should determine whether systems used with a default configuration only are treated as Category 3 or Category 4.

In the case of the category 3 products, the Supplier selection is non-necessary. Functional Design Specifications are not expected from the user, although there should be sufficient specifications to enable testing (Typically covered by the #URS and other relevant documentation. Verification typically consists of a single test phase.

All software changes should be controlled, including supplier-provided patches.

Examples: Firmware-based applications, #COTS software

Typical approach: Abbreviated Life-Cycle approach, URS, Risk-based approach to supplier assessment, Record Version Number, Verify Correct installation, Risk-based test against the requirements as dictated by use, Procedures in place for maintaining compliance and fitness for the intended use.

Category 4 - Configurable Products,

Configurable software products provide standard interfaces and functions that enable the configuration of user-specific business processes. This typically involves configuring predefined software modules.

Detailed URS is necessary. The approach to the assessment of the supplier and the configurable product should be risk-based and documented

While Functional Specifications (FS) may not be owned by the user, there should be adequate specifications available to ensure traceability and adequate test coverage. Verification should ensure that the software product meets the user requirements with a particular focus on the configured business process. Custom modules should be handled as Category 5 components.

Examples: #LIMS, #SCADA, ERP, MRPII, #DCS, EDMS, Building Management Systems, Simple HMI, Spreadsheets, #CDS

Typical approach: Life cycle approach, Risk-Based approach to supplier assessment, Demonstrate supplier had adequate QMS, Design Specifications, Record Version Numbers, Verify correct installation, Risk-based testing, Procedures in place for maintaining compliance and fitness for intended use, procedures for managing data.

Category 5 - Custom Applications,

These systems or subsystems are developed to meet the specific needs of the regulated company. The risk inherent in custom software is high. The life cycle approach and scaling decisions should be taken into account for this increased risk because there is no user experience or system reliability information available.

The supplier assessment should be risk-based and documented. A supplier audit is usually required to confirm that an appropriate #QMS is established to control the development and ongoing support of the application.

Examples: Internally or externally developed applications, process control applications, custom ladder logic, custom firmware, spreadsheets (Macro)

Typical approach: Same as for Category 4, plus more rigorous supplier assessment with possible supplier audit, Possession of full life cycle documentation ( #FDS, #HDS, #SDS, DS, Structural testing, etc.), and Design and Source Code Review.

The next articles will cover each category of software in detail, with a typical testing approach, so you are welcome to subscribe to get more information.