"Hardware Process Assurance Plan is created to achieve the goals, processes, and responsibilities which are required for implementation of the effective process assurance functions for the Turkish Light Helicopter Program Electrical Power System Lithium Ion Battery project. 
This plan aims to provide a consistent and objective approach to hardware quality assurance throughout the project lifecycle. 
This plan is working with the aim of achieving the HPA objectives. The HPA Plan includes Process Control, Organizational Responsibilities, Conformance, Process Assurance Activities, and Deviations according to RTCA/DO-254.
2	SCOPE
The hardware process assurance plan will be used to direct Quality Assurance tasks associated with the Turkish Light Helicopter Program Electrical Power System Lithium Ion Battery Project. This plan is presentation of procedures, methods and standards that will be applied throughout Turkish Light Helicopter Program Electrical Power System Lithium Ion Battery project. This plan complies with the documentation requirements of RTCA/DO-254.
3	APPLICABLE AND REFERENCE DOCUMENTS
3.1	Applicable Documents
This plan can be used only for Turkish Light Helicopter Program Electrical Power System Lithium Ion Battery contracts made between TA and ASPİLSAN Energy. In case of any incompatibility between this plan and the contract, the terms of the contract will be applied.
Table 1 Applicable Documents
Reference	Title
TL-ASP-006 	Duties, Authorities and Responsibilities Instruction
PR-KYM-005 	Receiving Inspection Procedure
PR-KYM-006	Control of Nonconforming Products
PR-KYM-008 	In-Process Inspection Procedure
PR-KYM-009	Final Inspection Procedure
PR-KYM-010 	Corrective Action Procedure
PR-KYM-011	Control of Subcontractors and Suppliers Procedure
PR-KYM-012 	Quality System Audit Procedure
PR-KYM-015	Record Keeping Procedure
PR-KYM-029 	Procurement Procedure
PR-AV-001	Design Procedure (Aviation)
FR-KYM-119	FAI Checklist
PL-HCM-001-0003	Hardware Configuration Management Plan
PL-DO-001-0004	Design Organization Interface Document
PL-PM-001-0015	Project Management Plan 
3.2	Reference Documents
Hardware Process Assurance Plan is in line with RTCA DO-254 chapter 10.1.6 and the contract deliverable documents.
Contract conditions and requirements are taken as basis in the preparation of the Hardware Process Assurance Plan. If there are issues that are not specified in the terms of the contract or that are in conflict with each other in practice, action is taken according to the order of priority in the contract documents.
Table 2 References
Reference	Title
QM ASP 001	ASPİLSAN Energy Quality Manual
-	ASPİLSAN Energy product specifications
-	Turkish Light Helicopter Program Electrical Power System Lithium Ion Battery Contract for Battery Subsystem, Technical Requirements
-	Customer Technical Specification / Agreement(s)
-	ASPİLSAN Energy product specifications
RTCA DO-254	Design Assurance Guidance for Airborne Electronic Hardware
3.3	Acronyms, Abbreviations and Symbols
Table 3 Definitions
Definitions 	Description
Acceptance	Acknowledgment by the certification authority that a submission of data, argument, or claim of equivalence satisfies applicable requirements.
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.
Conformance	Established as correct with reference to a standard, specification or drawing.
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.
Inspection	An examination of a system or item against a specific standard.
Item	A hardware or software element having bounded and well-defined interfaces.
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.
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.
The following acronyms and abbreviations may have been used in this document.
Table 4 Abbreviations
Abbreviations, Acronyms or Terms	Definition
AE	Aspilsan Energy
CDR	Critical Design Review
DOID	Design Organization Interface Document
FAI	First Article Inspection
HP	Hardware Process
HPAP	Hardware Process Assurance Plan
HAM	Hardware Assurance Management
IR	Initial Release
R&D	Research& Development
SOI	Stages of Involvement
TA	Turkish Aerospace
QA	Quality Assurance
QAE	Quality Assurance Engineer
QDMS	Quality Document Management System
 
4	PROCESS CONTROL
Hardware design processes will be controlled in terms of PR-AV-001 Design Procedure (Aviation). The role of quality assurance engineer and interfaces of QA engineer with other groups are given in Section 5.
4.1	Process Assurance Objectives
	Objective	Method of Compliance
1	Life cycle processes comply with the approved plans.
(Reference 8.1-1)	Integrated Compliance Management System(s)
Document Review Management System
Reviews and Analysis Management System
Documents Checklist(s)
Hardware Validation and Verification Results
Hardware Configuration Management records
Hardware Process Assurance Records
Review Checklist(s)
Transition Criteria Checklists
Hardware Planning Review (Pre-SOI 1)
Hardware Development Review (Pre-SOI 2)
Hardware Verification Review (Pre-SOI 3)
Hardware Final Review (Pre-SOI 4)

2	Hardware design life cycle data produced complies with the approved plans.
(Reference 8.1-2)	Integrated Compliance Management System(s)
Document Review Management System
Reviews and Analysis Management System
Documents Checklist(s)
Hardware Validation and Verification Results
Hardware Configuration Management records
Hardware Process Assurance Records
Review Checklist(s)
Transition Criteria Checklists
Hardware Planning Review (Pre-SOI 1)
Hardware Development Review (Pre-SOI 2)
Hardware Verification Review (Pre-SOI 3)
Hardware Final Review (Pre-SOI 4)

3	The hardware item used for conformance assessment is built to comply with the associated life cycle data.
(Reference 8.1-3)	Integrated Compliance Management System(s)
Document Review Management System
Reviews and Analysis Management System
Documents Checklist(s)
Hardware Configuration Index
Hardware Accomplishment Summary
Hardware Process Assurance Records
Review Checklist(s)
Conformity Review 

4.2	Hardware Design Life Cycle and Transition Criteria
The QAE shall evaluate the readiness for transitioning from one hardware life cycle phase to the next phase per entry and exit criteria will be defined in Hardware Development Plan. QA will verify transition criteria compliance at the Planning, Requirements, Design, Implementation and Test Reviews. QAE shall record transition evaluation results in QDMS. Transition shall be approved according to impact of the action items. Approval to the transition may be given in signatory management procedure which is sub part of PL-DO-001-0004 DOID. Transition records shall be updated. Approved transition audits shall be checked in a monthly period for updates. Transition approval decision will be recorded in JIRA.
Transition criteria will be applied as in INCOSE sebok and DO-254.
4.3	Standards
The following standards defined in DO-254 will be prepared and delivered within the scope of CDR.
•	Requirements standards
•	Hardware design standards
•	Validation and verification standards
•	Hardware archive standards
4.4	Team Members and Signature Authority
Team members list are given in PL-PM-001-015 Project Management Plan. Signature authority is given PL-DO-001-0004 Design Organization Interface Document.
4.4.1	Reviews and Analysis Management
Reviews are executed in MS Office and stored in QDMS. Detailed information is given in Section 7.
4.4.1.1	Meeting and Action Item Checklist
All meetings are recorded in QDMS. Action items that will directly affect the project are discussed in action item meetings held with TA. The result is shared with stakeholders in excel format.
4.4.2	Document Review Management
Detailed information is given in Section 7.1.
4.4.2.1	Document Review Checklist
The following checklists will be used and maintained during the project lifecycle:
•	Plan for Hardware Aspects of Certification Checklist
•	Hardware Development Plan Checklist
•	Hardware Validation and Verification Plan Checklist
•	Hardware Configuration Management Plan Checklist
•	Hardware Process Assurance Plan Checklist
•	Hardware Requirements Standards Checklist
•	Hardware Design Standards Checklist
•	Hardware Validation and Verification Standards Checklist
•	Hardware Coding Standards Checklist
•	Hardware Archive Standards Checklist
•	Hardware Requirements Document Checklist
•	Hardware Design Description Checklist
•	Hardware Verification Cases and Procedures Checklist
•	Hardware Verification Results Checklist
•	Hardware Lifecycle Environment Configuration Index Checklist
•	Hardware Configuration Index Checklist
•	Hardware Accomplishment Summary Checklist
 
5	ORGANIZATION, ROLES AND RESPONSIBILITIES
ASPILSAN design organization chart is given in Figure 1. The different color codes indicates that the units are individual from each other in Figure 1. Software & Hardware Quality Assurance, Configuration Management and Certification processes are operated under the Quality & Certification department. More detailed version of the OBS is defined in the PL-PM-001-015 Project Management Plan.
 
Figure 1 Organizational Break down Structure
ASPILSAN Battery Development Management, Battery Project Management and Process Development Management and Battery Production Management are working under Battery Development and Production Directorate which is reporting directly to General Manager. Battery Development Management, Battery Project Management and Process Development Management and Battery Production Management are also responsible for production, project management and timely coordination between those departments. The Battery Development Manager directly reports to Research and Development Director. Aviation Group defined in Figure 1 is working under the Battery Development Management. The Aviation Project Group Leader is defined as the Head of Design and directly reports to Battery Development Manager. 
Battery Project Management and Process Development Department is working under the Battery Development Management. Battery Development Management is responsible to report the status of design activities to Battery Project Management and Process Development for each project. There is also a functional relationship in the context of design activities between Battery Project Management and Process Development Department and Quality&Certificaton Departments. Audits and evaluation results during design and certification activities according to ADOM and referenced procedures are reported to both 
Quality Assurance Engineers work under the Quality&Certification department reporting to the Quality Manager. Quality Manager reports directly to General Manager and Quality Assurance Engineers report directly to Quality Manager. This reporting structure ensures the organizational independency of quality organization and establishes direct lines of communication to escalate issues to the executive management.
Quality Assurance Engineers work with system engineers on the technical side and with the project manager on the project side. There is also a functional relationship in the context of hardware design activities between Battery Project Management and Process Development Department and Quality&Certificaton Department. Audits and evaluation results during hardware design and certification activities according to DOID document and referenced procedures are reported to both Head of Design and General Manager by Quality&Certification Department to ensure that they can take necessary corrective actions. Quality&Certification Department supports Design Department in preparation and management of qualification test activities. Detail responsibilities of each groups are given in related procedures. 
Quality Assurance Engineers performs the activities and arrangements necessary to fulfil the process assurance objectives as specified in DO-254, according to the job descriptions in PL-DO-001-0004 DOID. 
QA engineer hardware ensures that the product conforms to applicable design data before it is released. Before the product is released, the following are checked by QAE:
•	Complete fulfilment of design and review steps
•	Compliance of design documents with contract requirements
•	Operation of control and approval processes for all design processes
•	Whether planned design verification and validation activities have been carried out
•	Conformance of Hardware Development Plans, Hardware Process Assurance Assurance Plan, DO-254.
Responsible personnel who ensure the fulfilment of contractual activities are determined in the relevant instructions and procedures. The duties and responsibilities of the departments shown in the organizational chart are also specified in TL-ASP-006 Duties, Authorities and Responsibilities Instruction document. 
For this project specific responsibilities are detailed within PL-DO-001-0004 Design Organization Interface Document.
 
6	CONFORMANCE
Process control has four main control stages named as incoming quality control (IQC), in process quality control (IPQC), final product quality control and first article inspection (FAI).
6.1	Receiving Quality Control& Counterfeit Product
To ensure compliance with contracts, standards and specifications of all receiving materials purchased, supplied by the customers or which any operation of them is performed by subcontractors to use in products which will be delivered to the customers. In order to prevent counterfeit/suspicious parts, it is essential that the material supply is made primarily from the original manufacturers of the parts, approved suppliers/distributors, approved sources that can show the traceability to the original manufacturer of the product, and no obsolete products are procured. Detailed information is given in PR KYM 029 Procurement Procedure. Receiving products are controlled according to the PR KYM 005 “Receiving Inspection” Procedure.
When a suspicious or counterfeit product is detected in the receiving inspection, it is not used in production and is processed according to the PR KYM 006 “Control of Nonconforming Products” Procedure, products are then relocated to the Rejected Area which is kept locked. According to the related procedure, in case the products are determined as waste or scrap they are physically destructed before being placed in the scrap warehouse.
6.2	In Process Quality Control
The in-process inspection is established in order to ensure the articles conform to the drawings and specifications throughout the process. This includes the characteristics which cannot be inspected or tested at a later stage, if applicable.
To verify that the product requirements/features and design specifications have been fulfilled, products are inspected during the appropriate periods of the process according to PR-KYM-008 In-Process Inspection Procedure.
Controls of products are performed by quality control personnel authorized by the Quality and Certification Manager.  The purposes of in-process inspections and tests are to verify that product meets requirements, to measure and to ensure that the products reach the final inspection stage without any defect.
In-process inspection steps from beginning to end of the process are specified in the quality plan.
The products found conforming during in-process inspections are approved and production monitoring and control forms of related product are defined on NETSIS ERP system.
6.3	Final Quality Control
At the end of the manufacturing phase, all articles, parts, prototype models and test specimens are subject to final inspection and testing for the conformity to the specified requirements. Final inspections and tests are performed according to the PR KYM 009 “Final Inspection” Procedure. Before proceeding to final inspections of finished products, recorded documents during in-process inspections and tests are analysed and if there is no non-compliance then final inspection is performed to demonstrate that product meets the specified conditions in customer requirements, technical specifications and the standards. However, electrical capacity tests for final inspection are applied to samples that selected by sampling method, other electrical parameters and size controls are applied to the whole party.
6.4	First Article Inspection
Quality and Certification Department performs FAI on new product representative of the first production run by using FR KYM 119 “FAI Checklist”. 
A representative item from the first production run of a new product is used to verify that the production processes, production documentation, and tooling have the capability to produce products that meet established requirements. FAI process is repeated, when changes occur that invalidate the original results (e.g., engineering changes, manufacturing process changes, tooling changes).
Quality and Certification Department plans FAI activities prior to the first production run. FAI planning addresses the activities to be performed throughout the FAI process and identify the responsible department/person for those activities. Detail FAI activities are defined in PR KYM 009 “Final Inspection” Procedure.
Quality Assurance Engineer will be responsible for planning of process control stages and their outputs review. It will be preparing reports for each stage.
7	PROCESS ASSURANCE ACTIVITIES
7.1	Walkthrough
Walkthroughs should be used for the early evaluation of documents, models, designs and code in different phases.
7.2	Peer Reviews
Peer reviews will be performed for each hardware product. FR-PM-010 Document Review Form will be used in hardware peer reviews.
All the hardware products will be under configuration control according to PL-HCM-001-0003 Hardware Configuration Management Plan after successful completion of peer reviews.
Following Table 5 states the hardware products that will be peer reviewed throughout the life cycle of the project.
Table 5 Items to be Peer Reviewed and Reviewers
Hardware Product	Reviewers
Hardware Development Plan	QAE, Hardware Engineers
Hardware Verification Plan	QAE, Hardware Engineers
Plan for Hardware Aspects of Certification	QAE, Hardware Engineers
Hardware Configuration Management Plan	Project Manager, QAE, Hardware Engineers
Hardware Quality Assurance Plan	Project Manager, HCM, Hardware Engineers
Hardware Requirements Standard	QAE, Hardware Engineers
Hardware Design Standard	QAE, Hardware Engineers
Hardware Requirements (High Level Requirements)	QAE, Hardware Engineers (including engineers responsible for verification activities), *SRMT Engineer, *Systems Engineer
Hardware Test Cases and Procedures	QAE, Hardware Engineers (including engineers responsible for development activities)
Hardware Test Results	QAE, Hardware Engineers
Hardware Configuration Index	QAE, Hardware Engineers
Hardware Design (Low Level Requirements)	QAE, Hardware Engineers (including engineers responsible for verification activities), *RMST Engineer, *Systems Engineer
Hardware Accomplishment Summary	QAE, Hardware Engineers
* For safety tagged and derived requirements.
Quality Assurance Engineer will assess the review products to assure that review packages are being developed according to the specified criteria, the review content is complete, accurate, and of sufficient detail, and requests for action are captured, reviewed, and tracked to closure.  In addition, Quality Assurance Engineer will assess the processes used to conduct the reviews to determine if appropriate personnel are in attendance, correct information is presented, entry and exit criteria are met, and appropriate documents are identified for update.
7.3	Test
Quality Assurance Engineer will assure that the test management processes and products are being implemented per the Hardware Development Plan and Hardware Validation Verification Plan. This includes all types of testing of hardware system components as described in the test plan.
Quality Assurance Engineer will monitor testing efforts to assure that test schedules are adhered to and maintained to reflect an accurate progression of the testing activities.   Quality Assurance Engineer will assure that tests are conducted using approved test procedures and appropriate test tools, and that test anomalies are identified, documented, addressed, and tracked to closure.  In addition, Quality Assurance Engineer will assure that assumptions, constraints, and test results are accurately recorded to substantiate the requirements verification/validation status.
Quality Assurance Engineer will review post-test execution related artefacts including test reports, test results, problem reports, etc.
7.4	Audits
Quality Assurance Engineer will responsible for the objectives described in 8.2. for monitoring, evaluating and auditing whether the project risk management and hardware design processes are working effectively. The objectives of the quality assurance audits are:
•	To ensure that necessary plans for product design and development activities are prepared according to internal procedures, approved hardware plans and standards
•	To ensure design and development activities and processes are conducted in accordance with those procedures, approved hardware plans and standards
•	To establish evidence by assessing periodically that the activities performed according to those procedures, approved hardware plans and standards
Quality and Certification Department is responsible to perform assurance activities by assessing the design and development process periodically according to PR KYM 012 Quality System Audit Procedure.
It carries out regular audits under the leadership of the Quality team before the milestones given in PMP. In addition, QAE can be ad hoc audits carried out according to the flow of the project. The dates of the audits to be held before the Milestones are published via e-mail.
 
8	CERTIFICATION CONSIDERATIONS
Certification activities shall be defined in Plan for Hardware Aspect for Certification.
9	SUPLLIER CONTROL
There is no suppliers within the project. In case of working with a supplier, information will be given and supplier control will be carried out according to PR KYM 011 Control of Subcontractors and Suppliers Procedure.
 
10	DEVIATIONS
10.1	Problem Reporting Process
The purpose of problem reporting, tracking and corrective action is to record problems and ensure disposition and resolution. Problems during design & development and certification processes of an article may include;
•	Deviation from the rules; non-compliance with the plans, development standards, applicable certification standards, etc.
•	Failure, malfunction or nonconformance of article
•	Inadequacy or deficiency of tools and technology processes.
Problems can be occurred any time during development of an article. Any discrepancies related to produced article will be managed by PR KYM 006 “Control of Nonconforming Product” procedure. Other problems will be recorded and tracked via FR KYM 080 “Problem Reporting Form”.
Following guidance will be followed:
•	Each reported problem will be covered by a problem report
•	Problem report will provide definition of affected process, product, test, etc.
•	Problem report will identify the configuration of the affected article and its item
•	Problem reports that require corrective action will invoke the change control process
•	All closed problem reports will include a description of action taken to close the problem report
•	The status of problem reports (change history, release status, etc.) including their approval and disposition will be tracked.
Open problem reports will be assessed for their impact on the intended function of article. Open problem reports impacting the equipment intended functions have to be communicated to article installer/user for final impact analysis at aircraft level.
Not all problem reports have to be closed in order to obtain article authorization. However, all problem reports should be evaluated and those that are determined to have safety or certification impact will be closed.
10.2	Nonconforming Item Control
ASPILSAN Energy ensures that articles and related parts and material which does not conform to specified requirements is identified and controlled to prevent its unintended use or delivery. The controls and related responsibilities and authorities related to nonconforming product are defined in PR KYM 006 “Control of Nonconforming Product” procedure. This procedure includes:
•	Identification of the nonconforming items 
•	Disposition for the nonconforming items
•	Appropriate action to eliminate the nonconformity 
•	Taking action to control the items, precluding its original use
•	Taking appropriate action when nonconforming product is detected after delivery.
The use and mixing with other materials of nonconforming materials those identified during incoming materials, in-process and final inspections and in storage, are prevented in ASPİLSAN. Product dispositioned for scrap is conspicuously and permanently marked, or positively controlled, until physically rendered unusable.
When a product is delivered to customer which was found not proper for intended use, the customer is informed in writing of the situation and coordination is ensured for corrective actions that are taken. In this context, all reports issued for non-conforming materials are preserved.
11	ENVIRONMENT AND PHASE TOOLS
The following tools will be used through the hardware life cycle of the project.
•	Microsoft Office Tools (i.e., Word, Excel, PowerPoint)
•	QDMS for Quality Document Management System
•	eBa for electronic information flow system
•	JIRA software for project management
•	IBM DOORS for requirement management
•	Windchill for Risk and Reliability Software
12	HARDWARE PROCESS ASSURANCE RECORDS
Quality Assurance Engineer will maintain records that document assessments performed on the project.  Maintaining these records will provide objective evidence and traceability of assessments performed throughout the project’s life cycle. 
Quality records are:
•	Audit reports
•	Peer review records
•	Deviation records
•	Test records
•	Transition approval records
Audit reports will be published in QDMS after audits using the RP-CYS-002 Audit Report Template. Peer reviews will done with FR-KYM-010 Review Checklist and other review checklist will be created and used. Deviation records will be kept by using FR-KYM-116 Waiver Deviation Form. Test records will be kept using by FR-KYM-081 Test Methods and Reports Form. After that Test Report will be published using the RP-ARGE-006 Test Report Template. These records will be kept in QDMS. 
Monitoring, distribution and keeping of quality records are carried out according to the PR-KYM-015 Record Keeping Procedure. 
"
Yukardaki metin neyi açıklamaktadır.Aşağıdaki sorunun cevabı kukardaki metinde mevcutmudur.
"Do you perform internal Design Reviews? If yes, do you have a procedure to define how they are planned, conducted and documented? [21.A.239(d)(1-2)]
How do you define your criteria for design reviews? Where do you keep them? Please provide evidence. [21A.239(d)(1-2)]
How history, tracking of all decision taken at each phase of the design process are managed and recorded? [21A.239(d)(1-2)]
How and by which procedure and organisation does sub-contractor designs are reviewed? [21A.239(d)3; GM1 21A.239 (d)3; GM2 21A.239 (d)3]
"