"Table of Contents
1	GENERAL	1
1.1	Purpose	1
1.2	Scope	1
1.3	Applicability	1
1.4	Applicable Documents	2
1.4.1	Internal References	2
1.4.2	External References	2
1.5	Acronyms, Abbreviations and Symbols	3
2	HARDWARE VERIFICATION AND VALIDATION PLAN	6
2.1	Introduction	6
3	VALIDATION PROCEDURES	7
4	VALIDATION METHODS AND DATA	7
4.1	Validation Methods	7
4.2	Hardware Requirements Process Validation Activities and Data	8
4.2.1	Reviews Complete	9
4.2.2	Disposition of Review Comments	9
4.2.3	Documentation and Approval of Derived Requirements	9
4.2.4	Test Results	9
4.2.5	Acceptance Criteria	9
4.2.6	Validation Reports	9
4.2.7	Review Findings	10
5	VALIDATION ENVIRONMENT	10
5.1	Tools And Equipments	10
5.1.1	Tools	10
5.1.2	Equipments	11
6	VERIFICATION PROCEDURES	12
7	VERIFICATION METHODS AND DATA	12
7.1	Verification Methods	12
7.1.1	Reviews	12
7.1.2	Testing	14
7.1.2.1	Test Procedures	15
7.1.2.2	Test Results	16
7.1.3	Analysis	16
7.1.3.1	Thermal Analysis	16
7.1.3.2	Stress Analysis	16
7.1.3.3	Reliability Analysis	16
7.1.3.4	Functional Failure Path Analysis	17
7.2	Commercial Off-The-Shelf (COTS) Components Usage	17
7.2.1	Verification of COTS Components	17
7.2.1.1	Technical Documentation Review	17
7.2.1.2	Functional Tests	17
7.3	Verification Data	18
7.4	Hardware Planning Process Verification Activities and Data	18
7.4.1	Hardware Planning Process Inputs	19
7.4.2	Hardware Planning Process Reviews and Analyses	19
7.5	Hardware Requirements Verification Activities and Data	19
7.5.1	Hardware Requirements Process Verification Objectives	20
7.5.2	Hardware Requirements Process Inputs	20
7.5.3	Hardware Requirements Process Reviews and Analyses	21
7.6	Hardware Design Process Verification Activities and Data	21
7.6.1	Hardware Design Process Verification Objective	22
7.6.2	Hardware Design Process Inputs	22
7.6.3	Hardware Design Process Reviews and Analyses	22
7.7	Hardware Implementation Verification Process Activities and Data	23
7.7.1	Hardware Implementation Process Verification Objectives	24
7.7.2	Hardware Implementation Process Inputs	24
7.7.3	Hardware Implementation Process Reviews and Analyses	24
7.8	Hardware Testing Verification Activities and Data	25
7.8.1	Hardware Testing Verification Objectives	25
7.8.2	Hardware Testing Inputs	25
7.8.3	Hardware Testing Reviews and Analyses	26
7.8.4	Hardware Test Execution	26
7.8.5	Process-Specific Activities	26
7.8.5.1	Test Procedure Development	26
7.8.5.2	Test Procedure Verification	27
7.8.5.3	Testing Environment	27
7.8.5.4	Test Results Verification	27
7.9	Production Transition Process Verification Activities and Data	27
7.9.1	Production Transition Process Verification Objectives	28
7.9.2	Production Transition Process Inputs	28
7.9.3	Production Transition Process Reviews and Analyses	29
8	VERIFICATION INDEPENDENCE	29
9	VERIFICATION ENVIRONMENT	29
9.1	Tools	29
9.1.1	Qualification of Verification Tools	30
9.1.2	Test Procedure Structure	30
10	ORGANIZATIONAL RESPONSIBILITIES	30
10.1	Responsibilities	30

List of Tables
Table 1 Internal Reference Documents	2
Table 2 External Reference Documents	2
Table 3 Definitions	3
Table 4 Abbreviations	6
Table 5 Hardware Requirements Process Validation Activities and Data	8
Table 6 Validation and Verification Process Tools	10
Table 7 Validation and Verification Process Equipments	11
Table 8 Review Checklist	14
Table 9 Hardware Planning Verification Activities	18
Table 10 Hardware Requirements Verification Activities	19
Table 11 Design Phase Verification	21
Table 12 Hardware Imlementation Verification Activities	22
Table 13 Hardware Testing Verification Activities	24
Table 14 Hardware Testing Verification Activities	27
 
List of Figures
Figure 1 Hardware Test Flow	15
 
1	GENERAL
1.1	PURPOSE
This Hardware Validation and Verification Plan (HVVP) describes verification and validation activities of the hardware to be developed in accordance with RTCA/DO-254 within the scope of the Heavy Class Attack Helicopter Program. 
1.2	SCOPE
The Battery System development lifecycle depicts the interaction between the Development Team and the Verifier/Validator. In general, the Verifier/Validator performs reviews, analyses and/or tests on the artefacts created by the Development Team. The Verifier/Validator also performs reviews of the test procedures, analyses and test results produced within the team. All verification activities will be conducted by the Verifier with independence; refer to the Verification Independence section of this document for additional details.
1.3	APPLICABILITY
This plan can be used only for Heavy Class Attack Helicopter contracts made between TUSAŞ and ASPİLSAN Energy. In case of any incompatibility between this plan and the contract, the terms of the contract will be applied.
 
1.4	APPLICABLE DOCUMENTS
1.4.1	Internal References 
Table 1 Internal Reference Documents
#	Document No	Title
1	BL-SD-001-0002	System Description Document
2	BL-IC-001-0002	Interface Control Document
3	PL-DO-001-0003	Design Organization Interface Document
4	PL-HPA-001-0002	Hardware Process Assurance Plan
5	PL-HCM-001-0002	Hardware Configuration Management Plan
6	RP-RAR-001-0001 	Reliability Analysis Report
7	RP-SSA-001-0002 	System Safety Assessment
8	PR-AV-009	Hardware Validation and Verification Standards
1.4.2	External References 
The documents listed in Table 2 Reference Documents below is for reference only. Each document is applicable to this document only to the extent specified herein.
Table 2 External Reference Documents
#	Document No	Title	Rev/Date
2	RTCA/DO-254	Design Assurance Guidance for Airborne Electronic Hardware	April 19, 2000
3	AMC 20-152A	Development Assurance for Airborne Electronic Hardware	November 5, 2023
1.5	ACRONYMS, ABBREVIATIONS AND SYMBOLS
Definitions are shown in Table 3 Definitions.
Table 3 Definitions
Definitions	Description
Analysis	An evaluation based on decomposition into simple elements.
Assessment	An evaluation based upon engineering judgment.
Assurance	The planned and systematic actions necessary to provide adequate confidence and evidence that a product or process satisfies given requirements.
Authority	The organization or person responsible within the State (Country) concerned with the certification of compliance with applicable requirements.
Certification	The legal recognition that a product, service, organization or person complies with the applicable requirements. Such certification comprises the activity of technically checking the product, service, organization or person, and the formal recognition of compliance with the applicable requirements by issue of a certificate, license, approval or other document as required by national laws and procedures.
Compliance	Successful performance of all mandatory activities; agreement between the expected or specified result and the actual result.
CM Storage	The Hardware Configuration Management Plan designated repository for the artifact or data generated by the Verification/Validation Team as evidence of their activities
Derived Requirements	Additional requirements resulting from design or implementation decisions during the development process which are not directly traceable to higher-level requirements.
Entry Criteria	The conditions under which the Verification/Validation Team starts or reassesses their activities for the respective phase
Exit Criteria	The conditions under which the Verification/Validation Team completes their activities for the respective phase
Failure	An occurrence which affects the operation of a component, part or element such that it can no longer function as intended,
Hardware	An item that has physical being.
Implementation	The act of creating a physical reality from a specification.
Independence	Separation of responsibilities that assures the accomplishment of objective
Evaluation e.g. validation activities not performed solely by the developer of the requirement of a system or item.
Item	A hardware or software element having bounded and well-defined interfaces.
Normal Test Case	A test case that verifies functionality using inputs that are based on the associated requirement(s). Normal test cases use input stimuli that verify the values or levels specified in the requirements.
Phase	The lifecycle Phase in which the activity occurs
Reliability	The probability that a system or item will perform a required function under specified conditions, without failure, for a specified period of time.
Requirement	An identifiable element of a function specification that can be validated and against which an implementation can be verified.
Safety	The state in which risk is acceptable.
Specification	A collection of requirements which, when taken together, constitute the criteria that define the functions and attributes of a system, component or item.
System	A combination of inter-related items arranged to perform a specific function(s).
Test	A quantitative procedure to prove performance using stated objective criteria with pass or fail results.
Test Case	Test cases define a set of inputs and expected response based on the hardware requirements. Test cases can be considered the requirements specification for a test procedure.
Test Procedure	Test procedures describe the detailed step by step process to implement a test case on the test platform. The procedures are based on the test cases.
Verification	The evaluation of an implementation of requirements to determine that they have been met.
Validation	The process by which requirements are determined to be correct and complete.
Verifiable	A characteristic of a requirement that determines if it can be verified through test, analysis (or simulation), or review/inspection.
Verification	The process by which a hardware design is determined to correctly and completely satisfy its requirements.
V&V Activities	The reviews, analyses (including simulation) and tests performed by the Verification/Validation Team
V&V Artifact	The artifact or data generated by the Verification/Validation Team as evidence of their activities
V&V Tools	The software and/or hardware tools utilized by the Verification/Validation Team while they perform their activities
The following acronyms and abbreviations may have been used in this document.
Table 4 Abbreviations
Abbreviations, Acronyms or Terms	Definition
ANSYS	Analysis System
CM	Configuration Management
DOORS	Dynamic Object Oriented Requirements System
ECMP	Electronic Component Management Plan
HAS	Hardware Accomplishment Summary
HECI	Hardware Environment Configuration Index
HCI	Hardware Configuration Index
PSSA	Preliminary System Safety Assesment
RTCA	Radio Technical Commission for Aeronautics
HRD	Hardware Requirements Document
FFPA	Functional Failure Path Analysis
CCB	Configuration Control Board


  
2	HARDWARE VERIFICATION AND VALIDATION PLAN
2.1	INTRODUCTION
Hardware verification and validation activities check the hardware against its specifications and requirements. In Aspilsan Energy,
•	Each hardware element meets requirements.
•	Independence audits are conducted.
•	Efforts are made to ensure that the verification and validation process adequately demonstrates the suitability of each hardware component for operational and environmental use.
3	VALIDATION PROCEDURES
Validation procedures ensure compliance with DO-254 requirements by thoroughly evaluating the hardware design. This section defines the purpose, participants, and criteria for validation. It provides detailed instructions for validation activities, including acceptance and completion criteria. The validation plan outlines schedules and resources, while validation reports document and analyze results for stakeholders.
4	VALIDATION METHODS AND DATA
4.1	VALIDATION METHODS
Derived requirements are identified in the DOORS attributes for a requirement. The validation of derived requirements will be performed in the Requirements Capture phase during the requirements review activity. When the derived requirements cannot be validated by the review method, test and analysis methods in the verification methods section will be used. The objective of the validation is to ensure that:
o	Derived requirements are correct
o	Derived requirements are complete
o	Derived requirements are documented and is correct
o	Derived requirements based on design decisions from the circuit card design clearly document the related design decision
o	Errors in derived requirements are fed back to the development Team for correction.
o	Safety impact of derived requirements are analyses
Validation of the derived requirements in the Hardware Requirements Document (HRD) will be performed via reviews, analyses and tests.  The reviewer will make to review the derived requirements and associated tracking data against the checklists. The review checklist should clearly indicate the source of the data reviewed. During the review, the reviewer will assess whether the derived requirements is justified. The description of validation standards to be applied will be made according to the “PR-AV-009 Hardware Validation and Verification Standards Document.” 
Hardware Validation and Verification Standards provide a structured approach to ensure that hardware components and systems meet quality, reliability, and safety standards. They are used as a guide for planning, executing, and documenting hardware testing and validation activities, ultimately leading to improved hardware products and reduced risks.
Derived requirements omissions and errors are documented in the Hardware Configuration Management Plan (HCMP).
4.2	HARDWARE REQUIREMENTS PROCESS VALIDATION ACTIVITIES AND DATA
Validation of derived requirements will be performed in the Requirements Capture phase as shown in the Table 5. 
Table 5 Hardware Requirements Process Validation Activities and Data
Phase	Entry Criteria	V&V Activities	V&V artifact	V&V Tools	CM storage	Exit Criteria
Requirement Capture	•	Hardware Requirements Document controlled in CM
•	Hardware Requirements Document review checklist	Validate derived requirements with the review checklist  	Hardware Requirements Document review checklist completed	Excell
DOORS
JIRA	Hardware Requirements Document review checklist controlled in CM	Reviews complete
All review comments dispositioned
All derived requirements are identified, have rationales and approved by safety.

Evidence to be produced as a result of the hardware verification process;
4.2.1	Reviews Complete
Reviews will be conducted throughout the hardware validation process to ensure that every aspect is thoroughly reviewed and evaluated. 
4.2.2	Disposition of Review Comments
Addressing and resolving review comments is a crucial aspect of the validation process. This section outlines the systematic approach for managing and resolving feedback received during reviews. Each comment will be carefully reviewed, categorized based on its severity and impact on the hardware design, and dispositioned accordingly. Clear criteria and responsibilities for each disposition decision will be established to ensure that no critical issues or concerns remain unresolved.
4.2.3	Documentation and Approval of Derived Requirements
Derived requirements resulting from higher-level requirements are identified and documented. These derived requirements will be reviewed and approved by safety engineers. This step will emphasize the commitment to safety and validation of hardware design in accordance with DO-254 standards.
4.2.4	Test Results
Outcomes of the tests, which should include data, measurements, observations, and any deviations or issues encountered during testing.
4.2.5	Acceptance Criteria
Predefined criteria or standards that hardware must meet to pass the tests will be clearly defined.
4.2.6	Validation Reports
Detailed summaries of the validation process will be provided, including test results, compliance with acceptance criteria, and any identified issues or deviations.
4.2.7	Review Findings
If reviews as part of the validation process, the findings and outcomes of these reviews will be documented. This may include design reviews or other relevant assessments.
5	VALIDATION ENVIRONMENT
For this project, the validation environment is requirement management tool, the problem reporting system, the configuration management system. 
5.1	Tools And Equipments
The tools and equipment specified in Table 6 and Table 7 will be use in both verification and validation processes.
5.1.1	Tools
The tools to be used in the validation and verification process are as shown in Table 6.
Table 6 Validation and Verification Process Tools
Tools	Purpose of Usage
DOORS	DOORS is use to create hardware requirements for validation and verification activities.
JIRA	In the validation and verification process, JIRA is employed for reviews, tracking open problem reports, and managing Configuration Management activities.
QDMS	The Quality Document Management System (QDMS) is utilized for the organization, storage, retrieval, and management of quality-related documents and processes.
EXCEL	Excel is used for Checklists in the review process.
ANSYS	Ansys is used for mechanical analysis, using FEM method. Structural, thermal and some electrical analysis can be performed on this tool.
PTC WINDCHILL	Fault tree analysis is performed for functional failure path analysis. Ptc windchill is used for fault tree analysis.
Battery GUI	It is use to monitoring detailed technical information about the status of the battery.

5.1.2	Equipments
The test equipment to be used in the validation and verification process is shown in Table 7.
Table 7 Validation and Verification Process Equipments
Equipments	Purpose of Usage
Power Supply 	It is use to provide power the circuit boards.
DC Electronic Load	It is use to provide load to circuit boards and LRU.
High Precision Data Logger	It is use to record current, voltage and temperature data of the LRU.
Oscilloscope	It is use to monitoring and calculate voltage and current information of the circuit bords and LRU.
Current and Voltage Probes	It is use to measure the voltage and current of  circuit bords and LRU.
Logic Analyser	A logic  nalysed is an electronic test tool used to capture and  nalyse digital signals on circuit boards.
Multimeter	It is use to measure voltage, current, resistance and capacitance values. 
Insulation Tester	It is use to measure the insulation resistance of LRU.
Miliohmmeter	It is used to measure very low resistance values accurately.

6	VERIFICATION PROCEDURES
Verification procedures will be ensure that the hardware design meets the requirements specified in DO-254. It will be documented in detail in the “Hardware Review and Analysis Procedures” document. This document will be include:
1.	Purpose of review or analysis.
2.	Organizations to participate in the review.
3.	Review or analysis criteria.
4.	Detailed instructions for conducting the review or analysis.
5.	Review or analysis acceptability and completion criteria.
7	VERIFICATION METHODS AND DATA
7.1	Verification Methods
Hardware verification will start with a plan to organize the test strategy. Each hardware requirement will be assessed as to whether it is suitable for review, analysis and/or test. The optimal environment for verifying each requirement will be defined accordingly. Details of the verification standards will be described in the “PR-AV-009 Hardware Validation and Verification Standards” document.
7.1.1	Reviews
A review is a process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval.
Reviews should be held throughout the hardware design life cycle as identified in the Hardware Design Plan. 
Guidance for reviews may include:
1.	Participants should have the knowledge necessary to perform the reviews.
2.	Hardware review results may be used to permit or deny transitions between hardware design life cycle process activities
3.	Result of review should be documented, including decisions made and disposition of actions to be taken
Reviews are performed on all lifecycle data. The reviews will be documented in a checklist; the completed checklist will be check over Excel and JIRA system also these documents stored in the QDMS. 
When performing the review, all checklist questions will be answered. Any comments will be noted on the checklist and discussed with the document author or technical authority. Each comment will have an agreed corrective action documented. Following incorporation of agreed comments and actions, the reviewer will verify that the document has been updated appropriately.
Checklists will present a series of questions selected to ensure that the hardware design life cycle data has the following characteristics:
•	Unambiguous – the information and/or data is documented in such a manner that it only a permits a single interpretation.
•	Complete – the information and/or data includes all the necessary and relevant requirements and descriptive material consistent with the standards. The figures are clearly  nalysed, all terms are defined and units of measure specified.
•	Verifiable – the information and/or data can be reviewed,  nalysed or tested for correctness. 
•	Consistent – the information and/or data has no conflicts within the document or between multiple documents.
•	Modifiable – the information and/or data is structured in such a way that changes, updates or modifications can be completely, consistently and correctly made while retaining the structure.
•	Traceable – the origin or derivation of the information and/or data can be demonstrated.
The characteristics listed above and configuration control aspects of all life cycle documents will be verified by review. 
Table 8 lists the reviews to be performed and its associated review checklist.
Table 8 Review Checklist
Lifecycle Artifact Reviewed	Checklist
Plan for Hardware Aspects of Certification	FR-KYM-196
Hardware Design Plan	FR-KYM-201
Hardware Validation and Verification Plan	FR-KYM-202
Hardware Process Assurance Plan	FR-KYM-199
Hardware Configuration Management Plan	FR-KYM-198
Hardware Requirements Standards	FR-KYM-200
Hardware Design Standards	FR-KYM-226
Hardware Archive Standards	FR-KYM-225
Hardware Verification and Validation Standards	FR-KYM-232
Hardware Requirements Document	FR-KYM-223
Hardware Test Procedures	FR-KYM-230
Hardware Test Results 	FR-KYM-231
Hardware Review and Analysis Procedures	FR-KYM-228
Hardware Review and Analysis Results	FR-KYM-229
7.1.2	Testing
Testing is the verification of the actual hardware to show that the implementation meets the requirements. Testing is typically performed in-circuit with production or production equivalent hardware. Production equivalent means that the circuits and card layouts are the same as those that will be used in the aircraft. Any differences should be assessed for impact. Testing can be performed at the LRU level and board level tests. 

Requirements --> Test Procedure --> Test Results
  
         Figure 1 Hardware Test Flow
7.1.2.1	Test Procedures
A test procedure will be established for all requirements of the hardware item. Test procedures will be written to describe the step by step sequence to implement a test case. Test procedures will be include test cases and Pass/Fail criterias.
The test procedures file will be adequately commented to aid in comprehension and maintenance. Test procedure authors will maintain a Revision History in the file headers. 
The traceability data may be imported to a tool to facilitate reporting such as Excel or DOORS. Test procedures will include test setups, test equipment, test cables and calibration or settings of the test equipment. 
Test procedures will be dry run and debugged by the test procedure author before posting the test procedure for peer review. 
All test procedures will be stored in the QDMS.  The Hardware Test Procedures document will provide an index to the test procedures used for formal verification credit.
7.1.2.2	Test Results 
All data resulting a test procedure with in-circuit test will be collected and stored in the QDMS as a test results. A Hardware Test Results will summarize the verification results.
The actual results will be analyzed for compliance with the expected results in the test procedures. 
7.1.3	Analysis 
The designed circuits will be simulated with various techniques and programs. Their accuracy will be tested according to the hardware requirements. Related analysis will be reported.
Analaysis performed include:
•	Thermal Analysis
•	Stress Analysis
•	Reliability Analysis
•	Functional Failure Path Analysis
7.1.3.1	Thermal Analysis
During the hardware design process, thermal analysis will be made at the LRU, circuit board and component level. The design process will be continued by verifying the requirements by performing thermal analysis. The analysis equipment to be used in thermal analysis will be ANSYS and thermal camera. 
7.1.3.2	Stress Analysis
The hardware design will be tested under the requirement conditions. Stress analysis will be performed to ensure that the hardware components can withstand mechanical, thermal and environmental stresses without fail. Test requirements will ensure that the hardware is working under stress. The analysis equipment to be used in stress analysis will be ANSYS.
7.1.3.3	Reliability Analysis
The reliability of the hardware design will be ensured by tests to be carried out under requirement conditions. Details are in the “RP-RAR-001-0001 Reliability Analysis” document.
7.1.3.4	Functional Failure Path Analysis 
An FFPA is a structured, top-down, iterative analysis. It identifies the specific portions of the design which implement the function; that is, the assemblies, components and elements associated with each path; and the associated failure modes and effects to be analyzed to determine that the hardware architecture and implementation complies with the safety requirements. The analysis equipment to be used in Functional Failure Path Analysis analysis will be PTC windchill. Details are in the “RP-SSA-001-0002 System Safety Assessment” document.
7.2	COMMERCIAL OFF-THE-SHELF (COTS) COMPONENTS USAGE
Quality and if possible, aviation history will be the selection criterias for COTS components and they will be used and tested according to DO-254. Moreover, COTS materials will be managed according to the ASPILSAN ECMP. 
7.2.1	Verification of COTS Components
COTS components are used extensively in hardware designs and typically the COTS components design data is not available for review. Therefore, verification of COTS components will be verified on a requirement basis within the overall design process using the reviews and testing methods in section 7.1 Verification Methods.
7.2.1.1	Technical Documentation Review
•	The COTS device will be reviewed and verified to ensure it meets the technical specifications for the intended functions.
•	The performance adequacy of the COTS device for its intended functions will be verified by reviewing the related datasheets and application notes.
7.2.1.2	Functional Tests
•	COTS device functional verification will be performed during requirements-based verification tests.
•	All unused functions of the COTS device will be identified and ensured that they are appropriately disabled or terminated according to the manufacturer's instructions.
•	Tests will be performed to verify that disabling unused functions does not affect overall system behavior.
7.3	VERIFICATION DATA
Verification data will include the identification and description of evidence produced as a result of the hardware verification process. This encompasses test cases, test procedures, and test results managed in accordance with the PL HCMP-001-0002 Hardware Configuration Management Plan within the QDMS.
The verification data will detail the outcomes of verification activities, including which hardware requirements were validated and the extent of their successful verification. An index will be provided within the Hardware Test Results document to reference all test cases, procedures, results, checklists, and analysis outcomes. 
7.4	HARDWARE PLANNING PROCESS VERIFICATION ACTIVITIES AND DATA
Planning process activities include:
1.	The hardware design life cycle process, including transition criteria, if applicable, and the inter-relationships between the individual processes such as their sequencing and feedback mechanisms, should be defined.
2.	The proposed design methods should be defined and explained. This includes consideration of the expected hardware design and rationale of the proposed verification methods.
3.	If any hardware design standards are to be used for the project, including acceptable deviations from the standards should be identified. These may range from generic quality standards to company or program specific standards.
The verification activities for the Planning phase will be performed as shown in Table 9.

Table 9 Hardware Planning Verification Activities
Phase	Entry Criteria	V&V Activities	V&V artifact	V&V Tools	CM storage	Exit Criteria
Planning	•	Hardware Management Plans controlled in CM
•	Hardware Management Plan review checklists controlled in CM.	Review Hardware Management Plans with checklist	• PHAC checklist 
HDP checklist 
 • HVP checklist – verification 
 • HVP checklist – validation 
 • HPAP checklist  
• HCMP checklist 	Word
Excell
Doors

	Checklists  controlled in CM	Hardware Management plans updated 
• Reviews complete; all review comments dispositioned

7.4.1	Hardware Planning Process Inputs
•	Technical Requirements
•	Deadline 
7.4.2	Hardware Planning Process Reviews and Analyses
After initial hardware planning process is done, it will be reviewed and analyzed. This review and analysis will include why this process is done, who will be involved, what is sought, how it will be done, and when it will be considered complete.
7.5	HARDWARE REQUIREMENTS VERIFICATION ACTIVITIES AND DATA
The verification activities for the Requirements Capture phase will be performed as shown in Table 10 Hardware Requirements Verification Activities.

Table 10 Hardware Requirements Verification Activities
Phase	Entry Criteria	V&V Activities	V&V artifact	V&V Tools	CM storage	Exit Criteria
Requiremet Capture	•	Hardware Requirements Document controlled in CM
•	Hardware Requirements Document review checklist	Review Hardware Requirements Document with review sections	Hardware Requirements Document review sections	Excel
DOORS
	Hardware Requirements Document review checklist controlled in CM	Reviews complete
All review comments dispositioned
Audits complete
7.5.1	Hardware Requirements Process Verification Objectives
The objectives for the requirements process are:
•	Requirements are identified, defined and documented. This include allocated requirements from the PSSA and derived requirements from the hardware safety assessment.
•	Derived requirements produced are fed back to the appropriate process
•	Requirement omissions and errors are provided to the appropriate process for resolution.
7.5.2	Hardware Requirements Process Inputs
Hardware Requirements Process Input will be used as follows;
•	System Level Requirement 
•	Project Management
•	Tools
•	Safety 
•	CM 
It will be recorded hardware requirements document in CM and review checklist document.
7.5.3	Hardware Requirements Process Reviews and Analyses
The Systems Engineering Team will review the hardware requirements and associated trace data that have been produced for initial release or subsequently updated. The reviewer can elect to review the requirements and associated trace data in the DOORS tool environment or they can review the data exported to the CM. 
The requirements review should be performed as soon as the development team has produced a baselined set. The review checklist will be clearly indicating the source of the data reviewed. The hardware requirements and associated checklist are retrieved from the CM. The checklist and review process used is discussed in the Review section of this document. Independence audit and review will be recorded and applied by QAE (Quality Assurance Engineers). It can be found in HPAP (Hardware Process Assurance Plan - PL-HPA-001-0002). The review is considered complete when all review comments are dispositioned and incorporated to the satisfaction of the reviewer. Any unresolved comments will be documented on a problem report for disposition by the CCB (Configuration Control Board) in accordance with the HCMP (Hardware Configuration Management Plan) change review process.
Requirement Analysis action will be realized specific to requirements by the System Engineers. They will be implemented Validation Report.
7.6	HARDWARE DESIGN PROCESS VERIFICATION ACTIVITIES AND DATA
The verification activities for the Design phase will be performed as shown in Table 11 Design Phase Verification.


Table 11 Design Phase Verification
Phase	Entry Criteria	V&V Activities	V&V artifact	V&V Tools	CM storage	Exit Criteria
Design	- Requirements valid and complete
- Hardware Design Data controlled in CM
- Hardware Plan Process valid and complete	Review Hardware Design data with review section checklist	Hardware Design Data review checklist
completed	- MS Office
- Design Tools
- DOORS
- Analysis and Simulation Tools
	- Hardware Design data review checklist  controlled in CM	- Reviews complete
- All review comments dispositioned
7.6.1	Hardware Design Process Verification Objective
The Hardware design process verification objectives are:
1.	The design is developed from the hardware item requirements.
2.	Derived requirements are fed back to the conceptual design process or other appropriate process.
3.	Requirement omissions or errors are provided to the appropriate processes for resolution.
7.6.2	Hardware Design Process Inputs
Hardware Design Process Input will be include as follows:
•	System Requirements
•	System Architecture
•	Hardware Requirements
•	Safety Requirements
•	Environmental Requirements
7.6.3	Hardware Design Process Reviews and Analyses
Related Quality Assurance Engineers and Hardware Design Engineers will review the Hardware Design Data that has been produced or subsequently updated. The review checklist will be clearly indicating the source of the data reviewed. The Hardware Design Data and associated checklist are retrieved from the CM. The review process used is discussed in the Review section of this document. The review is considered complete when all review comments are dispositioned and incorporated to the satisfaction of the reviewer. Any unresolved comments will be documented on a problem report for disposition by the CCB in accordance with the HCMP change review process.
7.7	HARDWARE IMPLEMENTATION VERIFICATION PROCESS ACTIVITIES AND DATA
The verification activities for the Implementation phase will be performed as shown in Table 12.
Table 12 Hardware Implementation Verification Activities
Phase	Entry Criteria	V&V Activities	V&V artifact	V&V Tools	CM storage	Exit Criteria
Implementation	- Hardware Requirements Document controlled
- Design valid complete
- Hardware Process valid complete until this process
- Tools and units when using the implementation process will be ready.	- Create electrical test cases for all requirements that describe pin level behaviour
- Create simulation test benches for test cases
- Create electrical test procedures for device tests
- Create trace data for requirements to test case(s)
- Create trace data for test case(s) to test procedure(s)	- Hardware Verification Cases and Procedures
- Completed test case review section
- Completed test procedure/bench review section
- Dry run simulation results
- Dry run device test results	- Simulation tool
- In-circuit electrical test equipment
- Word
- Excel	Hardware Design data review controlled in CM	Hardware Verification Cases and Procedures released through CM
7.7.1	Hardware Implementation Process Verification Objectives
The objectives of the implementation process are:
•	A hardware item is produced which implements the hardware detailed design using representative manufacturing processes.
•	The hardware item implementation, assembly and installation data are complete.
•	Derived requirements are fed back to the detailed design process or other appropriate process.
•	Requirement omissions and errors are provided to the appropriate processes for resolution.
7.7.2	Hardware Implementation Process Inputs
The implementation process uses the detailed design data to produce the hardware item that is an input to the testing activity.
7.7.3	Hardware Implementation Process Reviews and Analyses
The Verifier/Validator will produce or update test procedures for device testing. The test procedures will be dry run and debugged by the test procedure author. Test procedure dry run results will be stored in the CM. The test procedures are managed with the CM. After the test procedures are reviewed and updated, they are referenced from the Hardware Test Procedures document. The Hardware Test Procedures document is released when a formal baseline is created.
The Verifier/Validator will review the test procedures and the dry run test results that have been produced or subsequently updated. The review checklist should clearly indicate the source of the data reviewed. The test procedures and associated checklist are retrieved from the CM. The checklist and review process used is discussed in the Review section of this document. Independent review will be conducted as indicated in the Verification Independence section of this document. The review is considered complete when all review comments are dispositioned and incorporated to the satisfaction of the reviewer. Any unresolved comments will be documented on a problem report for disposition by the CCB in accordance with the HCMP change review process.
7.8	HARDWARE TESTING VERIFICATION ACTIVITIES AND DATA
The verification activities for the test phase will be performed as shown in table 13.
Table 13 Hardware Testing Verification Activities
Phase	Entry Criteria	V&V Activities	V&V artifact	V&V Tools	CM storage	Exit Criteria
Testing	•	Hardware Test Procedures released through CM
•	Test equipment set up	•	Perform device electrical tests
•	Review test result with checklist
	•	Device test result
•	Problem reports for test failures
•	Complete checklist
	•	In-circuit electrical test equipment
•	Word
•	Excel	•	Device test result in CM
•	Problem reports in CM
•	Test result review checklist	•	Test complete
•	Problem reports dispositioned thru CCB
•	Hardware Verification Report released through CM
7.8.1	Hardware Testing Verification Objectives
The objectives of the testing process are:
1.	The test is completed according to test procedure by the Verifier/Validator
2.	Any unresolved comments or test failures reports are dispositioned by the CCB
3.	Hardware Verification Report document is released through CM.
7.8.2	Hardware Testing Inputs
The testing process uses the hardware test procedures and test equipment set up that is an input to the testing activity.
7.8.3	Hardware Testing Reviews and Analyses
The Verifier/Validator will run the test benches and test procedures for credit. Test for credit may commence after Process Assurance has audited the configuration of the test equipment and the test benches/procedures to ensure that the correct version of the tests are being run. Test for credit will use formally released test benches and test procedures.
The Verifier/Validator will review the test results from the hardware tests. The review checklist should clearly indicate the source of the data reviewed. The test results and associated checklist are retrieved from the CM. The checklist and review process used is discussed in the Review section of this document. Independent review will be conducted as indicated in the Verification Independence section of this document. The review is considered complete when all review comments are dispositioned and incorporated to the satisfaction of the reviewer. Any unresolved comments or test failures will be put on a problem report for disposition by the CCB in accordance with the HCMP change review and problem reporting process.
After the test results are reviewed, they are referenced from the Hardware Test Report document. The Hardware Test Report document is released when a formal baseline is created.
7.8.4	Hardware Test Execution
Test execution involves following the defined test procedures and executing them on the actual hardware. This step produces real-world results that verify the behavior of the hardware. During test execution, anomalies or unexpected behaviors may be discovered and documented for further analysis and resolution.
7.8.5	Process-Specific Activities
7.8.5.1	Test Procedure Development
Test procedure development involves crafting step-by-step instructions on how to execute the defined test cases. These instructions detail the necessary setup, inputs, actions to be taken, and expected results. The goal is to create clear and repeatable procedures that testers can follow to execute the tests.
7.8.5.2	Test Procedure Verification
Test procedure verification ensures that the developed test procedures accurately represent the corresponding test cases. This includes reviewing the procedures for clarity, correctness, and alignment with the intended tests. The verification process aims to identify any discrepancies or errors in the test procedures.
7.8.5.3	Testing Environment
The testing environment includes the hardware tools, and resources necessary to execute the test procedures. This environment should be representative of the intended operational conditions of the hardware. Verification of the testing environment ensures that it accurately simulates the intended operational environment.
7.8.5.4	Test Results Verification
Test results verification involves reviewing the outcomes of the test execution to ensure they match the expected results. Any discrepancies or deviations from expected behavior are investigated, documented, and potentially addressed through design adjustments or corrective actions.

7.9	PRODUCTION TRANSITION PROCESS VERIFICATION ACTIVITIES AND DATA
The verification activities for the production transition phase will be performed as shown in Table 14. 

Table 14 Hardware Testing Verification Activities
Phase	Entry Criteria	V&V Activities	V&V Artifact	V&V Tools	CM storage	Exit Criteria
Production Transition	•	Hardware Accomplishment summary controlled in CM
•	Hardware Configuration Index controlled in CM
•	Implementation result valid and complete	•	Review HAS, HECI and HCI with checklist 	•	HCI checklist 
•	HECI checklist
•	HAS checklist 	•	Work
•	Excel	•	Checklists	•	Reviews complete; all review comments dispositioned
7.9.1	Production Transition Process Verification Objectives
The objectives of this process are:
•	A baseline is established that includes all design and manufacturing data needed to support the consistent replication of the hardware item
•	Manufacturing requirements related to safety are identified and documented and manufacturing controls are established.
•	Derived requirements are fed back to the implementation process or other appropriate processes.
•	Errors and omissions are provided to the appropriate processes for resolution.
7.9.2	Production Transition Process Inputs
In this process, manufacturing data, test facilities and general resources should be examined to ensure availability and suitability for production. The production transition process uses the outputs from the implementation and verification processes to move the product into production.
7.9.3	Production Transition Process Reviews and Analyses
The Verifier/Validator will review the Hardware Accomplishment Summary, Hardware Configuration Index and Hardware Environment Configuration Index that have been produced for initial release or subsequently updated. The Hardware Configuration Index and Hardware Environment Configuration Index may be separate or combined documents. For the review of the initial release of the documents, all documents must be controlled in the CM prior to the review so that consistency in the documents can also be verified. The hardware documents and associated checklists are retrieved from the CM. The checklist and review process used is discussed in the Review section of this document. Independent review will be conducted as indicated in the Verification Independence section of this document. The review is considered complete when all review comments are dispositioned and incorporated to the satisfaction of the reviewer. Any unresolved comments will be documented on a problem report for disposition by the CCB in accordance with the HCMP change review process.

8	VERIFICATION INDEPENDENCE
•	The Verificaition/Validation Team performs review, analysis or tests on the outputs created by the Development Team.
•	The Verificaition/Validation Team also performs reviews of the test procedures, analyses and test results produced within the team.
•	All review of Verification/Validation Team work product will be performed by a person other than the author of the work product to ensure sufficient independence. 
•	Independence is also established by review of the Development Team work products by the Verification/Validation Team.
•	Designer created test benches can be used for formal credit, if and only if, the test benches are requirements based, traced to requirements and independently reviewed by the Verification/Validation Team.
9	VERIFICATION ENVIRONMENT
9.1	Tools
Verification tools are given in Table 9, Table 10, Table 11, Table 12, Table 13 and table 14.
9.1.1	Qualification of Verification Tools
The hardware verification process requires the qualification of design and verification tools to ensure their suitability and effectiveness. This section outlines the qualification process for verification tools in accordance with DO-254 standards. The qualification activities will include establishing operational requirements for each tool and developing a comprehensive set of test cases to verify their compliance. The qualification test cases and results will be documented to demonstrate the suitability and effectiveness of the tools in the verification process. 
9.1.2	Test Procedure Structure
Test procedure structure is explained in section 7.1.2.1 Test Procedure.
10	ORGANIZATIONAL RESPONSIBILITIES
10.1	RESPONSIBILITIES
Technical management is responsible for organising hardware verification and validation activities, the definition of hardware verification and validation, and the allocation of staff to those roles. Responsibilities are defined in PL-DO-001-0003 Design Organisation Interface Document.
The Verification/Validation Team responsibilities are as follows:
•	The Verification/Validation Team will complete the review checklists 
•	The Verification/Validation Team will perform the validation activities 
•	The Verification/Validation Team will perform the review activities 
•	The Verification/Validation Team will perform the analysis activities 
•	The Verification/Validation Team will perform the test activities 
•	The Configuration Management team will control and release any data in accordance with the Hardware Configuration Management Plan 
•	The Configuration Management team will review and process and Problem Reports generated by the Verification/Validation Team in accordance with the Hardware Configuration Management."
Bu hardware validation and verification plan (hvvp) dokumanı içeriğine göre aşağıdaki soruları cevapla. Aşağıdaki sorular dokuman içinde yer alıyorsa, dokuman içinde hangi sectionda olduğunu yaz. Sorular aşağıda;
1.7.1	If HVP is followed, will DO-254 validation and verification objectives be met?
1.7.2	Does the HVP adequately address the proposed contents described in DO-254, Section 10.1.3 & 10.1.4? If not, are the contents included in another plan?
1.7.3	 Will applicable aspects of the HVP plan, environment, tools, training and procedures be conveyed to any sub-tier suppliers of components of the system and subcontractors to ensure their compliance to the approved plans, standards, and procedures?
1.7.4	Does the HVP describe how independence will be achieved, when required?
1.7.5	"Does the HVP describe the verification method used for each hardware verification activity? Specifically:
• Are methods, checklists, tools and procedures described for conducting reviews of hardware requirements, design, coding, and integration?
• Are methods, checklists, tools and procedures described for conducting analyses of traceability, change impact, timing, verification coverage, normal range coverage, robustness test coverage, etc.?
Note: Robustness testing does not appear as an objective for DO-254, but its application has shown to be effective for other domains (e.g., software).
• Are methods, checklists, tools and procedures described for conducting reviews of test plans, test procedures, test cases, and test results?
• Are methods, checklists, tools and procedures described for conducting testing of hardware requirements, hardware derived requirements, hardware integration, hardware-software integration, normal range, and robustness?
• If hardware verification test credit will be claimed for testing conducted on system benches, laboratory, integrated system facilities, do the plans and procedures describe how those activities will be conducted and hardware test results and coverage analyses documented?
• Is there a well-defined process and procedure for ensuring that deficiencies detected during the testing process will be conveyed to and corrected by the hardware design process and team?"
1.7.6	"Does the HVP adequately describe the verification environment (e.g., tools, test equipment, etc.)? Consider the following questions:
• Are there any automated tools? If so, do any of the tools need to be qualified?
• Is there any overlap between various kinds of testing (e.g., overlap of system and hardware requirements-based testing)?
• Is the division of the testing task between suppliers and sub-contract suppliers adequately addressed and controlled?"
1.7.7	Are verification plans, including test plans, and procedures conveyed to suppliers and sub-contractors to ensure their activities and results will comply with the approved plans and procedures?
1.7.8	Does the HVP describe methods for test case selection? Does the HVP specify how each requirement will be tested (e.g., hardware component test, board level/hardware integration test, hardware/software integration test)?
1.7.9	Does the HVP or procedures specify who is allowed to perform verification tasks?
1.7.10	"If verification tools are used, has the tool assessment process as described in section 11.4 of DO-254 been followed?

Note: See section 11.4 of DO-254 for more information on tool assessment and qualification process."