Hardware Design Specification

Hardware Design Specification

In the previous article, I wrote about the Functional Design Specification, where the general rules were mentioned. In case, that the project is simple, the #Functional Design Specification document can cover the #Hardware Design #Specification and Software Design Specification. In case, that the project is large and complex, separate documents of the Hardware Design Specification and Software #Design Specification should be provided.

The Hardware Design Specification (#HDS) is a document written by the supplier. It details how the supplier intends to provide system hardware to implement the aims set out in the Functional Design Specification (#FDS). The HDS is a description of the #Control #System #Hardware, which will be supplied, and how it will be connected to other Control Systems or plant equipment. The HDS should describe more in detail the system hardware and other equipment identified in the FDS and as such should provide traceability back to statements in the FDS.

Once the HDS is produced and approved, it is possible to generate a Hardware Test Specification, which can be a separate document, or it can be a part of the #Software Test #Report - Depending on the system's complexity.

What are the two main uses of the HDS?

  • For use by the supplier as a working document during the design and development of the system,
  • For use after qualification of the system as support documentation by those responsible for the maintenance and future enhancement of the system hardware.

Any divergence between the Hardware Design Specification and Functional Design Specification should be clearly identified by the supplier of the #Automation #Control #System #Machine. These divergencies should be viewed and approved by both sides (Purchased and Supplier), and the outcome reflected in controlled changes to the FDS and/or HDS to ensure consistency.

In the Hardware Design Specification, the supplier can use many techniques and methodologies, which should be appropriate to the type of Control System, which will be implemented and agreed upon with the client. In addition to the use of text and natural language description, the document may include :

  • Block Diagrams,
  • Wiring Diagrams,
  • Network Diagrams,
  • Data Flow Diagrams.

What are the categories of the Hardware?

Category 1:

Standard hardware components should be documented including the manufacturer or supplier details, and version numbers. Correct installation and connection of components should be verified. The model, version number, and where available, serial number, or pre-assembled hardware should be recorded. Pre-Assembled hardware does not have to be disassembled. You can take information from the Siemens TIA portal for example.

No alt text provided for this image
Siemens TIA Portal Catalog Information

Category 2:

These requirements are in addition to those of standard hardware components. Custom items of hardware should have a Design Specification (DS) and be subjected to acceptance testing. The approach to supplier assessment should be risk-based and documented. In most cases, a Supplier Audit should be performed for custom hardware development.

要查看或添加评论,请登录

Erik D.的更多文章

  • Process Control System - Installation Qualification

    Process Control System - Installation Qualification

    What is Installation Qualification? If you are perusing this article, it is likely that you are already acquainted with…

  • Process Control System Risk-Based Validation

    Process Control System Risk-Based Validation

    On September 13th, the #FDA published a draft of "Computer Software Assurance for #Production and quality system…

    2 条评论
  • A Risk-Based approach for Software Category 5

    A Risk-Based approach for Software Category 5

    In previous articles, I wrote about A Risk-Based approach for Category 1, Category 3, and Category 4. If you missed…

  • A Risk-Based approach for Software Category 4

    A Risk-Based approach for Software Category 4

    In previous articles in 2022, I wrote about a Risk-Based approach for Software Category 1, and Software Category 3…

  • A Risk-Based approach for Software Category 3

    A Risk-Based approach for Software Category 3

    This article will cover a Risk-Based approach for Category 3 Devices, which includes devices, that can be mostly known…

  • A Risk-Based approach for Software Category 1

    A Risk-Based approach for Software Category 1

    As I mentioned in a previous article about the Software Design Specification #GAMP5 recognizes that software commonly…

    2 条评论
  • Software Design Specification

    Software Design Specification

    The #GMP-critical automation control system software must be fully documented, reviewed, and well structured, following…

    3 条评论
  • Functional Design Specification - The supplier's response to URS

    Functional Design Specification - The supplier's response to URS

    In previous articles, I wrote mainly about the User Requirement Specification, which is the Alfa&Omega of the Control…

  • Supplier Selection - The valuable CSV tool II

    Supplier Selection - The valuable CSV tool II

    In the previous #article, where I opened the Supplier Selection topic, you can read about the basics of #Supplier…

  • Supplier Selection - The valuable CSV tool

    Supplier Selection - The valuable CSV tool

    Did you hear about the supplier selection? Is it demand for the Control System Validation, or it's a valuable tool to…

    2 条评论

社区洞察

其他会员也浏览了